Best Regards Jerry Huang > -----Original Message----- > From: Kumar Gala [mailto:galak@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, September 13, 2012 8:48 PM > To: Huang Changming-R66093 > Cc: Chris Ball; linuxppc-dev@xxxxxxxxxxxxxxxx list; linux- > mmc@xxxxxxxxxxxxxxx; Anton Vorontsov > Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23 > > > On Sep 12, 2012, at 9:02 PM, Huang Changming-R66093 wrote: > > >>> > >>>> -----Original Message----- > >>>> From: Chris Ball [mailto:cjb@xxxxxxxxxx] > >>>> Sent: Wednesday, September 12, 2012 4:59 AM > >>>> To: Kumar Gala > >>>> Cc: Huang Changming-R66093; linuxppc-dev@xxxxxxxxxxxxxxxx list; > >>>> linux- mmc@xxxxxxxxxxxxxxx; 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. > > Based on this, why don't we use the HOSTVER register to detect instead of > device tree: > > > #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 > > unsigned int vendor_version; > > vendor_version = sdhci_readw(host, SDHCI_HOST_VERSION); vendor_version = > (vendor_version & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT; > > if ((vendor_version == FSL_SDHC_VER_1_1) || (vendor_version == > FSL_SDHC_VER_2_2)) > host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23; > I once thought about it, but if the future silicon does not support this feature, then we continue to modify these codes for new silicon? -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
