RE: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23

[Huang Changming-R66093 <r66093@freescale.com>]

Best Regards
Jerry Huang


> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, September 13, 2012 8:48 PM
> To: Huang Changming-R66093
> Cc: Chris Ball; linuxppc-dev@lists.ozlabs.org list; linux-
> mmc@vger.kernel.org; Anton Vorontsov
> Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23
>=20
>=20
> On Sep 12, 2012, at 9:02 PM, Huang Changming-R66093 wrote:
>=20
> >>>
> >>>> -----Original Message-----
> >>>> From: Chris Ball [mailto:cjb@laptop.org]
> >>>> Sent: Wednesday, September 12, 2012 4:59 AM
> >>>> To: Kumar Gala
> >>>> Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
> >>>> linux- mmc@vger.kernel.org; Anton Vorontsov
> >>>> Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the
> >>>> CMD23
> >>>>
> >>>> Hi,
> >>>>
> >>>> On Tue, Sep 11 2012, Kumar Gala wrote:
> >>>>> thanks for the info.  Do you know what's required on controller
> >>>>> side to handle cards that support CMD23?
> >>>>>
> >>>>> I'm trying to figure out if older controller's on FSL SoCs are
> >>>>> missing some feature to allow CMD23 to work (vs Auto-CMD23).
> >>>>
> >>>> It seems plausible that it's just not implemented on these
> controllers.
> >>>> It's a little strange, since the command's been specified for so
> >>>> long and we haven't seen any other controllers with problems.  The
> >>>> patch would be correct if this is true.
> >>>>
> >>>
> >>> I didn't find any description about it, but after testing on FSL
> >> silicones, I got this result:
> >>> Some silicones support this command, and some silicones don't
> >>> support
> >> it, which will cause I/O error.
> >>
> >> Can you list out which SoCs support it and which don't.  Having this
> >> list will be useful in understanding which controller versions
> supported it.
> >>
> > P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
> > Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041)
> support it.
>=20
> Based on this, why don't we use the HOSTVER register to detect instead of
> device tree:
>=20
>=20
> #define FSL_SDHC_VER_1_0	0x00
> #define FSL_SDHC_VER_1_1	0x01
> #define FSL_SDHC_VER_2_0	0x10
> #define FSL_SDHC_VER_2_1	0x11
> #define FSL_SDHC_VER_2_2	0x12
> #define FSL_SDHC_VER_2_3	0x13
>=20
> unsigned int vendor_version;
>=20
> vendor_version =3D sdhci_readw(host, SDHCI_HOST_VERSION); vendor_version =
=3D
> (vendor_version & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
>=20
> if ((vendor_version =3D=3D FSL_SDHC_VER_1_1) || (vendor_version =3D=3D
> FSL_SDHC_VER_2_2))
> 	host->quirks2 |=3D SDHCI_QUIRK2_HOST_NO_CMD23;
>=20

I once thought about it, but if the future silicon does not support this fe=
ature,
then we continue to modify these codes for new silicon?