[PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Yangbo Lu]

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.

Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com>
---
 drivers/mmc/host/sdhci-esdhc.h    |  5 +++++
 drivers/mmc/host/sdhci-of-esdhc.c | 18 ++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
index 3497cfa..5174233 100644
--- a/drivers/mmc/host/sdhci-esdhc.h
+++ b/drivers/mmc/host/sdhci-esdhc.h
@@ -47,4 +47,9 @@
 
 #define ESDHC_HOST_CONTROL_RES	0x05
 
+unsigned int esdhc_errata;
+
+/* Incorrect host version in T4240 HOSTVER register */
+#define ESDHC_ERRATA_T4240_ERROR_HOSTVER		(1<<0)
+
 #endif /* _DRIVERS_MMC_SDHCI_ESDHC_H */
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 1295a96..c0ad765 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -59,6 +59,11 @@ static u16 esdhc_readw(struct sdhci_host *host, int reg)
 		ret = in_be32(host->ioaddr + base) & 0xffff;
 	else
 		ret = (in_be32(host->ioaddr + base) >> shift) & 0xffff;
+
+	if ((reg == SDHCI_HOST_VERSION) &&
+			(esdhc_errata & ESDHC_ERRATA_T4240_ERROR_HOSTVER))
+		ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
+
 	return ret;
 }
 
@@ -352,6 +357,9 @@ static void esdhc_get_property(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
 	struct sdhci_host *host = platform_get_drvdata(pdev);
+	struct device_node *cpus;
+	const u32 *prop;
+	u8 rev = 0xff;
 
 	sdhci_get_of_property(pdev);
 
@@ -359,6 +367,11 @@ static void esdhc_get_property(struct platform_device *pdev)
 	mmc_of_parse(host->mmc);
 	mmc_of_parse_voltage(np, &host->ocr_mask);
 
+	cpus = of_find_node_by_path("/cpus");
+	prop = of_get_property(cpus, "cpu-rev", NULL);
+	if (prop)
+		rev = *(u8 *)prop;
+
 	if (of_device_is_compatible(np, "fsl,p5040-esdhc") ||
 	    of_device_is_compatible(np, "fsl,p5020-esdhc") ||
 	    of_device_is_compatible(np, "fsl,p4080-esdhc") ||
@@ -373,6 +386,11 @@ static void esdhc_get_property(struct platform_device *pdev)
 		 */
 		host->quirks2 |= SDHCI_QUIRK2_BROKEN_HOST_CONTROL;
 	}
+
+	esdhc_errata = 0;
+
+	if (of_device_is_compatible(np, "fsl,t4240-esdhc") && rev <= 0x20)
+		esdhc_errata |= ESDHC_ERRATA_T4240_ERROR_HOSTVER;
 }
 
 static int sdhci_esdhc_probe(struct platform_device *pdev)
-- 
2.1.0.27.g96db324

[PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Yangbo Lu]

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.

Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com>
---
 drivers/mmc/host/sdhci-esdhc.h    |  5 +++++
 drivers/mmc/host/sdhci-of-esdhc.c | 18 ++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
index 3497cfa..5174233 100644
--- a/drivers/mmc/host/sdhci-esdhc.h
+++ b/drivers/mmc/host/sdhci-esdhc.h
@@ -47,4 +47,9 @@
 
 #define ESDHC_HOST_CONTROL_RES	0x05
 
+unsigned int esdhc_errata;
+
+/* Incorrect host version in T4240 HOSTVER register */
+#define ESDHC_ERRATA_T4240_ERROR_HOSTVER		(1<<0)
+
 #endif /* _DRIVERS_MMC_SDHCI_ESDHC_H */
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 1295a96..c0ad765 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -59,6 +59,11 @@ static u16 esdhc_readw(struct sdhci_host *host, int reg)
 		ret = in_be32(host->ioaddr + base) & 0xffff;
 	else
 		ret = (in_be32(host->ioaddr + base) >> shift) & 0xffff;
+
+	if ((reg == SDHCI_HOST_VERSION) &&
+			(esdhc_errata & ESDHC_ERRATA_T4240_ERROR_HOSTVER))
+		ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
+
 	return ret;
 }
 
@@ -352,6 +357,9 @@ static void esdhc_get_property(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
 	struct sdhci_host *host = platform_get_drvdata(pdev);
+	struct device_node *cpus;
+	const u32 *prop;
+	u8 rev = 0xff;
 
 	sdhci_get_of_property(pdev);
 
@@ -359,6 +367,11 @@ static void esdhc_get_property(struct platform_device *pdev)
 	mmc_of_parse(host->mmc);
 	mmc_of_parse_voltage(np, &host->ocr_mask);
 
+	cpus = of_find_node_by_path("/cpus");
+	prop = of_get_property(cpus, "cpu-rev", NULL);
+	if (prop)
+		rev = *(u8 *)prop;
+
 	if (of_device_is_compatible(np, "fsl,p5040-esdhc") ||
 	    of_device_is_compatible(np, "fsl,p5020-esdhc") ||
 	    of_device_is_compatible(np, "fsl,p4080-esdhc") ||
@@ -373,6 +386,11 @@ static void esdhc_get_property(struct platform_device *pdev)
 		 */
 		host->quirks2 |= SDHCI_QUIRK2_BROKEN_HOST_CONTROL;
 	}
+
+	esdhc_errata = 0;
+
+	if (of_device_is_compatible(np, "fsl,t4240-esdhc") && rev <= 0x20)
+		esdhc_errata |= ESDHC_ERRATA_T4240_ERROR_HOSTVER;
 }
 
 static int sdhci_esdhc_probe(struct platform_device *pdev)
-- 
2.1.0.27.g96db324

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Ulf Hansson]

On 21 July 2015 at 11:45, Yangbo Lu <yangbo.lu@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?

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. This DT property will then
be parsed by the esdhc driver.

>
> Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com>
> ---
>  drivers/mmc/host/sdhci-esdhc.h    |  5 +++++
>  drivers/mmc/host/sdhci-of-esdhc.c | 18 ++++++++++++++++++
>  2 files changed, 23 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
> index 3497cfa..5174233 100644
> --- a/drivers/mmc/host/sdhci-esdhc.h
> +++ b/drivers/mmc/host/sdhci-esdhc.h
> @@ -47,4 +47,9 @@
>
>  #define ESDHC_HOST_CONTROL_RES 0x05
>
> +unsigned int esdhc_errata;
> +
> +/* Incorrect host version in T4240 HOSTVER register */
> +#define ESDHC_ERRATA_T4240_ERROR_HOSTVER               (1<<0)
> +
>  #endif /* _DRIVERS_MMC_SDHCI_ESDHC_H */
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index 1295a96..c0ad765 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -59,6 +59,11 @@ static u16 esdhc_readw(struct sdhci_host *host, int reg)
>                 ret = in_be32(host->ioaddr + base) & 0xffff;
>         else
>                 ret = (in_be32(host->ioaddr + base) >> shift) & 0xffff;
> +
> +       if ((reg == SDHCI_HOST_VERSION) &&
> +                       (esdhc_errata & ESDHC_ERRATA_T4240_ERROR_HOSTVER))
> +               ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
> +
>         return ret;
>  }
>
> @@ -352,6 +357,9 @@ static void esdhc_get_property(struct platform_device *pdev)
>  {
>         struct device_node *np = pdev->dev.of_node;
>         struct sdhci_host *host = platform_get_drvdata(pdev);
> +       struct device_node *cpus;
> +       const u32 *prop;
> +       u8 rev = 0xff;
>
>         sdhci_get_of_property(pdev);
>
> @@ -359,6 +367,11 @@ static void esdhc_get_property(struct platform_device *pdev)
>         mmc_of_parse(host->mmc);
>         mmc_of_parse_voltage(np, &host->ocr_mask);
>
> +       cpus = of_find_node_by_path("/cpus");
> +       prop = of_get_property(cpus, "cpu-rev", NULL);
> +       if (prop)
> +               rev = *(u8 *)prop;
> +
>         if (of_device_is_compatible(np, "fsl,p5040-esdhc") ||
>             of_device_is_compatible(np, "fsl,p5020-esdhc") ||
>             of_device_is_compatible(np, "fsl,p4080-esdhc") ||
> @@ -373,6 +386,11 @@ static void esdhc_get_property(struct platform_device *pdev)
>                  */
>                 host->quirks2 |= SDHCI_QUIRK2_BROKEN_HOST_CONTROL;
>         }
> +
> +       esdhc_errata = 0;
> +
> +       if (of_device_is_compatible(np, "fsl,t4240-esdhc") && rev <= 0x20)
> +               esdhc_errata |= ESDHC_ERRATA_T4240_ERROR_HOSTVER;
>  }
>
>  static int sdhci_esdhc_probe(struct platform_device *pdev)
> --
> 2.1.0.27.g96db324
>

Kind regards
Uffe

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Scott Wood]

On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote:
> On 21 July 2015 at 11:45, Yangbo Lu <yangbo.lu@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.

-Scott

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Ulf Hansson]

On 25 July 2015 at 04:27, Scott Wood <scottwood@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@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 understand it, you can't update the already deployed DTB. Shall
we make Linux patch the DTB during boot instead, depending on the chip
revision?

Kind regards
Uffe

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Scott Wood]

On Mon, 2015-07-27 at 09:58 +0200, Ulf Hansson wrote:
> On 25 July 2015 at 04:27, Scott Wood <scottwood@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@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.

-Scott

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Ulf Hansson]

On 27 July 2015 at 17:57, Scott Wood <scottwood@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@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@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

RE: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Lu Y.B.]

> > > > > 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.
> 
> -Scott

Thanks, Scott.
I checked the device nodes of device-config/guts, finding all the platforms has not a uniform compatible name.
Could I add a compatible name called "fsl, dcfg"("fsl, guts" if using guts) for PowerPC P series, T series, B series boards, so that I could get this device node by compatible without knowing platform? 

Or Do you know there is another method to get this device node in code easily without knowing platform?

Best regards,
Yangbo Lu







_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Lu Y.B.]

PiA+ID4gPiA+IEZvciBUNDI0MC1SMS4wLVIyLjAsIHRoZSBIT1NUVkVSIHJlZ2lzdGVyIGhhcyBp
bmNvcnJjZXQgdmVuZGVyDQo+ID4gPiA+ID4gdmVyc2lvbiB2YWx1ZSBhbmQgc2RoYyBzcGVjIHZl
cnNpb24gdmFsdWUuIFRoaXMgd2lsbCBicmVhayBkb3duDQo+ID4gPiA+ID4gdGhlIEFETUEgZGF0
YSB0cmFuc2Zlci4gU28gYWRkIHdvcmthcm91bmQgdG8gZ2V0IHJpZ2h0IHZhbHVlDQo+ID4gPiA+
ID4gVlZOPTB4MTMsIFNWTiA9IDB4MS4NCj4gPiA+ID4NCj4gPiA+ID4gU28gVDQyNDAtUjEuMC1S
Mi4wIGlzIHRoZSB2ZXJzaW9uIG9mIHRoZSBjb250cm9sbGVyLCByaWdodD8NCj4gPiA+ID4NCj4g
PiA+ID4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3QgeW91IGFyZSBjaGVja2luZyB3aGF0IENQVS9T
b0MgeW91IGFyZQ0KPiA+ID4gPiBydW5uaW5nIG9uLCB0byBmaWd1cmUgb3V0IHdoaWNoIGNvbnRy
b2xsZXIgdmVyc2lvbiB5b3UgYXJlIHVzaW5nLA0KPiA+ID4gPiBhcyB0aGF0IGNhbid0IGJlIGZl
dGNoZWQgKHRydXN0ZWQpIGZyb20gdGhlIHJlZ2lzdGVycyBvZiB0aGUgZXNkaGMNCj4gPiA+ID4g
Y29udHJvbGxlciBpdHNlbGYhPw0KPiA+ID4gPg0KPiA+ID4gPiBJbnN0ZWFkLCB5b3UgY291bGQg
ZGVhbCB3aXRoIHRoaXMgZGlyZWN0bHkgaW4gdGhlIERUUyBmaWxlcy4gSQ0KPiA+ID4gPiBhc3N1
bWUgeW91IGhhdmUgc29tZSBEVFMgZmlsZSBmb3IgZWFjaCBTb0MvYm9hcmQgdmFyaWFudCwgcmln
aHQ/DQo+ID4gPg0KPiA+ID4gTm8sIHdlIGRvIG5vdCBoYXZlIGEgc2VwYXJhdGUgRFRTIGZpbGUg
Zm9yIGVhY2ggcmV2aXNpb24gb2YgYW4gU29DDQo+ID4gPiAtLSBhbmQgaWYgd2UgZGlkLCB3ZSdk
IGNvbnN0YW50bHkgaGF2ZSBwZW9wbGUgdXNpbmcgdGhlIHdyb25nIG9uZS4NCj4gPiA+DQo+ID4g
PiA+IEluIHByaW5jaXBsZSwgaW4geW91ciBEVFMgZmlsZSBzcGVjaWZpYyBmb3IgdGhlIGJvYXJk
L1NvQyB0aGF0DQo+ID4gPiA+IGhvbGRzIHRoZSBUNDI0MC1SMS4wLVIyLjAgdmVyc2lvbiBvZiB0
aGUgY29udHJvbGxlciwgc2hvdWxkIGFkZCBhDQo+ID4gPiA+IHNwZWNpZmljIGVzZGhjIERUIHBy
b3BlcnR5IHRvIGluZGljYXRlIHRoaXMgZXJyYXRhLg0KPiA+ID4NCj4gPiA+IE5vLCBiZWNhdXNl
IChpbiBhZGRpdGlvbiB0byB0aGUgYWJvdmUgaXNzdWUgYWJvdXQgY2hpcCByZXZpc2lvbnMpDQo+
ID4gPiB0aGUgZGV2aWNlIHRyZWUgaXMgc3RhYmxlIEFCSSBhbmQgZXJyYXRhIGFyZSBvZnRlbiBk
aXNjb3ZlcmVkIGFmdGVyDQo+ID4gPiBkZXZpY2UgdHJlZXMgYXJlIGRlcGxveWVkLg0KPiA+DQo+
ID4gRmFpciBlbm91Z2guIFRoZW4gd2hhdCBpcyB5b3VyIHN1Z2dlc3Rpb24gZm9yIHRoZSBzb2x1
dGlvbiBoZXJlPw0KPiANCj4gQXMgSSBzYWlkIGluIG15IGNvbW1lbnQgb24gcGF0Y2ggMi8zLCBy
ZWFkIFNWUiBmcm9tIHRoZSBkZXZpY2UtDQo+IGNvbmZpZy9ndXRzIE1NSU8gYmxvY2ssIHdoaWNo
IHdvcmtzIG9uIGJvdGggUFBDIGFuZCBBUk0uDQo+IA0KPiAtU2NvdHQNCg0KVGhhbmtzLCBTY290
dC4NCkkgY2hlY2tlZCB0aGUgZGV2aWNlIG5vZGVzIG9mIGRldmljZS1jb25maWcvZ3V0cywgZmlu
ZGluZyBhbGwgdGhlIHBsYXRmb3JtcyBoYXMgbm90IGEgdW5pZm9ybSBjb21wYXRpYmxlIG5hbWUu
DQpDb3VsZCBJIGFkZCBhIGNvbXBhdGlibGUgbmFtZSBjYWxsZWQgImZzbCwgZGNmZyIoImZzbCwg
Z3V0cyIgaWYgdXNpbmcgZ3V0cykgZm9yIFBvd2VyUEMgUCBzZXJpZXMsIFQgc2VyaWVzLCBCIHNl
cmllcyBib2FyZHMsIHNvIHRoYXQgSSBjb3VsZCBnZXQgdGhpcyBkZXZpY2Ugbm9kZSBieSBjb21w
YXRpYmxlIHdpdGhvdXQga25vd2luZyBwbGF0Zm9ybT8gDQoNCk9yIERvIHlvdSBrbm93IHRoZXJl
IGlzIGFub3RoZXIgbWV0aG9kIHRvIGdldCB0aGlzIGRldmljZSBub2RlIGluIGNvZGUgZWFzaWx5
IHdpdGhvdXQga25vd2luZyBwbGF0Zm9ybT8NCg0KQmVzdCByZWdhcmRzLA0KWWFuZ2JvIEx1DQoN
Cg0KDQoNCg0KDQoNCg==

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Scott Wood]

On Wed, 2015-08-26 at 02:49 -0500, Lu Yangbo-B47093 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.
> > 
> > -Scott
> 
> Thanks, Scott.
> I checked the device nodes of device-config/guts, finding all the platforms 
> has not a uniform compatible name.
> Could I add a compatible name called "fsl, dcfg"("fsl, guts" if using guts) 
> for PowerPC P series, T series, B series boards, so that I could get this 
> device node by compatible without knowing platform? 

No.  It's too vague.  Linux should keep a list of all the nodes it can match 
against for this.  Centralize it in one place rather than having each driver 
that cares about SVR do it.

-Scott