[PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value
Ulf Hansson
ulf.hansson at linaro.org
Tue Aug 25 22:04:17 AEST 2015
On 27 July 2015 at 17:57, Scott Wood <scottwood at freescale.com> wrote:
> On Mon, 2015-07-27 at 09:58 +0200, Ulf Hansson wrote:
>> On 25 July 2015 at 04:27, Scott Wood <scottwood at freescale.com> wrote:
>> > On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote:
>> > > On 21 July 2015 at 11:45, Yangbo Lu <yangbo.lu at freescale.com> wrote:
>> > > > For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
>> > > > version value and sdhc spec version value. This will break down
>> > > > the ADMA data transfer. So add workaround to get right value
>> > > > VVN=0x13, SVN = 0x1.
>> > >
>> > > So T4240-R1.0-R2.0 is the version of the controller, right?
>> > >
>> > > If I understand correct you are checking what CPU/SoC you are running
>> > > on, to figure out which controller version you are using, as that
>> > > can't be fetched (trusted) from the registers of the esdhc controller
>> > > itself!?
>> > >
>> > > Instead, you could deal with this directly in the DTS files. I assume
>> > > you have some DTS file for each SoC/board variant, right?
>> >
>> > No, we do not have a separate DTS file for each revision of an SoC -- and
>> > if
>> > we did, we'd constantly have people using the wrong one.
>> >
>> > > In principle, in your DTS file specific for the board/SoC that holds
>> > > the T4240-R1.0-R2.0 version of the controller, should add a specific
>> > > esdhc DT property to indicate this errata.
>> >
>> > No, because (in addition to the above issue about chip revisions) the
>> > device
>> > tree is stable ABI and errata are often discovered after device trees are
>> > deployed.
>>
>> Fair enough. Then what is your suggestion for the solution here?
>
> As I said in my comment on patch 2/3, read SVR from the device-config/guts
> MMIO block, which works on both PPC and ARM.
>
That's okay, as long as don't have include sections of non generic
header files in the driver.
To be more clear, this is not okay to have:
#include <mach/*>
Kind regards
Uffe
More information about the Linuxppc-dev
mailing list