On 07/02/2013 03:00:43 AM, Zhang Haijun-B42677 wrote:
Regards
Haijun.
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 02, 2013 8:05 AM
> To: Zhang Haijun-B42677
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Zhang
> Haijun-B42677; Fleming Andy-AFLEMING
> Subject: Re: [PATCH] DTS: Add compatible list for eSDHC
>
> On 07/01/2013 12:21:50 AM, Haijun Zhang wrote:
> > Add compatible of esdhc for below board:
> > p2041 p3041 p4080 p5020 p5040
> >
> > Signed-off-by: Haijun Zhang <haijun.zh...@freescale.com>
> > CC: Scott Wood <scottw...@freescale.com>
> > CC: Fleming Andrew-AFLEMING <aflem...@freescale.com>
> > ---
> > arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 +
> > arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 1 +
> > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 1 +
> > arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 1 +
> > arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 1 +
> > 5 files changed, 5 insertions(+)
>
> Is there something specific that depends on this, or are you just
trying
> to conform to other examples?
>
> I don't think we need the SoC name here, given that eSDHC has a
version
> register that you can read (and an SVR in the unlikely case that
that
> isn't adequate). If you did end up relying on this device tree
change,
> you'd be broken if an older device trees is used.
>
[Haijun Wrote:] Yes, in mmc driver (sdhci-pltfm.c)some quirks depends
on Soc name and its Soc version (sdhci-of-esdhc.c), even if they had
the same eSDHC version.
Then please use SVR for applying errata workarounds to these chips,
rather than rely on the device tree being updated. The SVR approach
also lets you deal with cases where the erratum is present in one rev
of an SoC but not another.
Is SDHCI_QUIRK_BROKEN_TIMEOUT_VAL present on these chips? If so, which
chips (of the same eSDHC version) is it not present on?
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
