| Message ID | 1348223135-6435-1-git-send-email-r66093@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 21 September 2012 15:55, <r66093@freescale.com> wrote: > From: Jerry Huang <Chang-Ming.Huang@freescale.com> > > CMD23 causes lots of errors in kernel on some freescale SoCs > (P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used, > which is because these controllers does not support CMD23, > even on the SoCs which declares CMD23 is supported. > Therefore, we'll not use CMD23. > > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> > Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com> > CC: Anton Vorontsov <cbouatmailru@gmail.com> > CC: Chris Ball <cjb@laptop.org> > --- > changes for v3: > - move the limitation detect function to eSDHC file > - add the callback funtion to do this limitation detect > changes for v2: > - discard the property mode and add the processor detection > > drivers/mmc/host/sdhci-of-esdhc.c | 30 ++++++++++++++++++++++++++++++ > drivers/mmc/host/sdhci-pltfm.c | 3 +++ > drivers/mmc/host/sdhci.c | 3 +++ > drivers/mmc/host/sdhci.h | 1 + > include/linux/mmc/sdhci.h | 1 + > 5 files changed, 38 insertions(+) > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c > index f8eb1fb..2f40a7f 100644 > --- a/drivers/mmc/host/sdhci-of-esdhc.c > +++ b/drivers/mmc/host/sdhci-of-esdhc.c > @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host *host) > } > #endif > > +static const u32 non_cmd23_processor_table[] = { > + /* P1020 Dual/Single core */ > + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, > + /* P1021 Dual/Single core */ > + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, > + /* P1022 Dual/Single core */ > + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, > + /* P1024 Dual/Single core */ > + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, > + /* P1025 Dual/Single core */ > + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, > + /* P4080 and P4040 */ > + 0x820000, 0x820800, 0x820100, 0x820900 > +}; > + > +void esdhc_of_detect_limitation(struct sdhci_host *host) > +{ > + u32 svr = mfspr(SPRN_SVR) >> 8; > + u32 table_size = ARRAY_SIZE(non_cmd23_processor_table); > + int i; > + > + for (i = 0; i < table_size; i++) { > + if (non_cmd23_processor_table[i] == svr) { > + host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23; > + break; > + } > + } > +} > + > static struct sdhci_ops sdhci_esdhc_ops = { > .read_l = sdhci_be32bs_readl, > .read_w = esdhc_readw, > @@ -158,6 +187,7 @@ static struct sdhci_ops sdhci_esdhc_ops = { > .platform_suspend = esdhc_of_suspend, > .platform_resume = esdhc_of_resume, > #endif > + .platform_limitation = esdhc_of_detect_limitation, > }; > > static struct sdhci_pltfm_data sdhci_esdhc_pdata = { > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c > index d9a4ef4..864bedd 100644 > --- a/drivers/mmc/host/sdhci-pltfm.c > +++ b/drivers/mmc/host/sdhci-pltfm.c > @@ -185,6 +185,9 @@ int sdhci_pltfm_register(struct platform_device *pdev, > > sdhci_get_of_property(pdev); > > + if (host->ops->platform_limitation) > + host->ops->platform_limitation(host); > + In your Soc specific sdhci-xxxx.c probe function you need to call sdhci_pltfm_register function. And before calling this function you can check for the above inserted code. this will keep the sdhci-pltfm.c unchanged and also avoids the additional callback in the generic header file > ret = sdhci_add_host(host); > if (ret) > sdhci_pltfm_free(pdev); > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index 9a11dc3..6208a8b 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -2795,6 +2795,9 @@ int sdhci_add_host(struct sdhci_host *host) > if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA)) > mmc->caps |= MMC_CAP_4_BIT_DATA; > > + if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23) > + mmc->caps &= ~MMC_CAP_CMD23; > + > if (caps[0] & SDHCI_CAN_DO_HISPD) > mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; > > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h > index 97653ea..4296bef 100644 > --- a/drivers/mmc/host/sdhci.h > +++ b/drivers/mmc/host/sdhci.h > @@ -278,6 +278,7 @@ struct sdhci_ops { > void (*hw_reset)(struct sdhci_host *host); > void (*platform_suspend)(struct sdhci_host *host); > void (*platform_resume)(struct sdhci_host *host); > + void (*platform_limitation)(struct sdhci_host *host); > }; > > #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS > diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h > index ac83b10..97c73f5 100644 > --- a/include/linux/mmc/sdhci.h > +++ b/include/linux/mmc/sdhci.h > @@ -91,6 +91,7 @@ struct sdhci_host { > unsigned int quirks2; /* More deviations from spec. */ > > #define SDHCI_QUIRK2_HOST_OFF_CARD_ON (1<<0) > +#define SDHCI_QUIRK2_HOST_NO_CMD23 (1<<1) > > int irq; /* Device IRQ */ > void __iomem *ioaddr; /* Mapped address */ > -- > 1.7.9.5 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Fri, Sep 21 2012, r66093@freescale.com wrote: > --- a/drivers/mmc/host/sdhci-of-esdhc.c > +++ b/drivers/mmc/host/sdhci-of-esdhc.c > @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host *host) > } > #endif > > +static const u32 non_cmd23_processor_table[] = { > + /* P1020 Dual/Single core */ > + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, > + /* P1021 Dual/Single core */ > + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, > + /* P1022 Dual/Single core */ > + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, > + /* P1024 Dual/Single core */ > + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, > + /* P1025 Dual/Single core */ > + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, > + /* P4080 and P4040 */ > + 0x820000, 0x820800, 0x820100, 0x820900 I don't see how this method improves on either of the previous two we've discussed. If anything, Kumar's suggested method seems better than this one: it detected the MMC IP revision, which I'd expect to be more reliable than building a list of which SoCs contain that IP. Why is this better than using DT or detecting the MMC revision? Thanks, - Chris.
On Sep 21, 2012, at 11:08 AM, Chris Ball wrote: > Hi, > > On Fri, Sep 21 2012, r66093@freescale.com wrote: >> --- a/drivers/mmc/host/sdhci-of-esdhc.c >> +++ b/drivers/mmc/host/sdhci-of-esdhc.c >> @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host *host) >> } >> #endif >> >> +static const u32 non_cmd23_processor_table[] = { >> + /* P1020 Dual/Single core */ >> + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, >> + /* P1021 Dual/Single core */ >> + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, >> + /* P1022 Dual/Single core */ >> + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, >> + /* P1024 Dual/Single core */ >> + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, >> + /* P1025 Dual/Single core */ >> + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, >> + /* P4080 and P4040 */ >> + 0x820000, 0x820800, 0x820100, 0x820900 > > I don't see how this method improves on either of the previous two we've > discussed. If anything, Kumar's suggested method seems better than this > one: it detected the MMC IP revision, which I'd expect to be more > reliable than building a list of which SoCs contain that IP. > > Why is this better than using DT or detecting the MMC revision? > > Thanks, I feel like I missed this patch, but I'd rather we go with the version I sent since the # of IP versions we have is 3 or 4, instead of the 30 or 40 SoCs we have. - k-- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Chris Ball [mailto:cjb@laptop.org] > Sent: Saturday, September 22, 2012 12:09 AM > To: Huang Changming-R66093 > Cc: linux-mmc@vger.kernel.org; Huang Changming-R66093; Xie Shaohui-B21989; > Anton Vorontsov; Kumar Gala > Subject: Re: [PATCH v3] powerpc/esdhc: disable CMD23 for some Freescale > SoCs > > Hi, > > On Fri, Sep 21 2012, r66093@freescale.com wrote: > > --- a/drivers/mmc/host/sdhci-of-esdhc.c > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c > > @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host > > *host) } #endif > > > > +static const u32 non_cmd23_processor_table[] = { > > + /* P1020 Dual/Single core */ > > + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, > > + /* P1021 Dual/Single core */ > > + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, > > + /* P1022 Dual/Single core */ > > + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, > > + /* P1024 Dual/Single core */ > > + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, > > + /* P1025 Dual/Single core */ > > + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, > > + /* P4080 and P4040 */ > > + 0x820000, 0x820800, 0x820100, 0x820900 > > I don't see how this method improves on either of the previous two we've > discussed. If anything, Kumar's suggested method seems better than this > one: it detected the MMC IP revision, which I'd expect to be more > reliable than building a list of which SoCs contain that IP. > > Why is this better than using DT or detecting the MMC revision? > The first version, I use the DT, but someone don't like it. MPC8536 and P4080 have the same version: VVN1.0, but MPC8536 supports CMD23, P4080 can't support. no anyone can make sure all future silicones can support CMD23. So, I think if DT can't be used, it is the better way to detect the processor. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Kumar Gala [mailto:galak@kernel.crashing.org] > Sent: Saturday, September 22, 2012 2:36 AM > To: Chris Ball > Cc: Huang Changming-R66093; linux-mmc@vger.kernel.org; Huang Changming- > R66093; Xie Shaohui-B21989; Anton Vorontsov > Subject: Re: [PATCH v3] powerpc/esdhc: disable CMD23 for some Freescale > SoCs > > > On Sep 21, 2012, at 11:08 AM, Chris Ball wrote: > > > Hi, > > > > On Fri, Sep 21 2012, r66093@freescale.com wrote: > >> --- a/drivers/mmc/host/sdhci-of-esdhc.c > >> +++ b/drivers/mmc/host/sdhci-of-esdhc.c > >> @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host > >> *host) } #endif > >> > >> +static const u32 non_cmd23_processor_table[] = { > >> + /* P1020 Dual/Single core */ > >> + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, > >> + /* P1021 Dual/Single core */ > >> + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, > >> + /* P1022 Dual/Single core */ > >> + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, > >> + /* P1024 Dual/Single core */ > >> + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, > >> + /* P1025 Dual/Single core */ > >> + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, > >> + /* P4080 and P4040 */ > >> + 0x820000, 0x820800, 0x820100, 0x820900 > > > > I don't see how this method improves on either of the previous two > > we've discussed. If anything, Kumar's suggested method seems better > > than this > > one: it detected the MMC IP revision, which I'd expect to be more > > reliable than building a list of which SoCs contain that IP. > > > > Why is this better than using DT or detecting the MMC revision? > > > > Thanks, > > I feel like I missed this patch, but I'd rather we go with the version I > sent since the # of IP versions we have is 3 or 4, instead of the 30 or > 40 SoCs we have. > MPC8536 and P4080 have the same IP version (VVN1.0), but MPC8536 support CMD23, P4080 can't, how to handle these two silicones? For the future silicones, no one can make sure all silicones support CMD23. don't say almost 0%, which just is the assumption, otherwise, why p4080 can't support it and mpc8536 can? -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Best Regards Jerry Huang > -----Original Message----- > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc- > owner@vger.kernel.org] On Behalf Of Huang Changming-R66093 > Sent: Monday, September 24, 2012 10:37 AM > To: Kumar Gala; Chris Ball > Cc: linux-mmc@vger.kernel.org; Xie Shaohui-B21989; Anton Vorontsov > Subject: RE: [PATCH v3] powerpc/esdhc: disable CMD23 for some Freescale > SoCs > > > > > -----Original Message----- > > From: Kumar Gala [mailto:galak@kernel.crashing.org] > > Sent: Saturday, September 22, 2012 2:36 AM > > To: Chris Ball > > Cc: Huang Changming-R66093; linux-mmc@vger.kernel.org; Huang > > Changming- R66093; Xie Shaohui-B21989; Anton Vorontsov > > Subject: Re: [PATCH v3] powerpc/esdhc: disable CMD23 for some > > Freescale SoCs > > > > > > On Sep 21, 2012, at 11:08 AM, Chris Ball wrote: > > > > > Hi, > > > > > > On Fri, Sep 21 2012, r66093@freescale.com wrote: > > >> --- a/drivers/mmc/host/sdhci-of-esdhc.c > > >> +++ b/drivers/mmc/host/sdhci-of-esdhc.c > > >> @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host > > >> *host) } #endif > > >> > > >> +static const u32 non_cmd23_processor_table[] = { > > >> + /* P1020 Dual/Single core */ > > >> + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, > > >> + /* P1021 Dual/Single core */ > > >> + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, > > >> + /* P1022 Dual/Single core */ > > >> + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, > > >> + /* P1024 Dual/Single core */ > > >> + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, > > >> + /* P1025 Dual/Single core */ > > >> + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, > > >> + /* P4080 and P4040 */ > > >> + 0x820000, 0x820800, 0x820100, 0x820900 > > > > > > I don't see how this method improves on either of the previous two > > > we've discussed. If anything, Kumar's suggested method seems better > > > than this > > > one: it detected the MMC IP revision, which I'd expect to be more > > > reliable than building a list of which SoCs contain that IP. > > > > > > Why is this better than using DT or detecting the MMC revision? > > > > > > Thanks, > > > > I feel like I missed this patch, but I'd rather we go with the version > > I sent since the # of IP versions we have is 3 or 4, instead of the 30 > > or > > 40 SoCs we have. > > > MPC8536 and P4080 have the same IP version (VVN1.0), but MPC8536 support > CMD23, P4080 can't, how to handle these two silicones? > For the future silicones, no one can make sure all silicones support > CMD23. > don't say almost 0%, which just is the assumption, otherwise, why p4080 > can't support it and mpc8536 can? MPC837x has the same VVN1.0 as the MPC8536 and p4080, which supports CMD23, too. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sep 23, 2012, at 10:13 PM, Huang Changming-R66093 wrote: > > > Best Regards > Jerry Huang > > >> -----Original Message----- >> From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc- >> owner@vger.kernel.org] On Behalf Of Huang Changming-R66093 >> Sent: Monday, September 24, 2012 10:37 AM >> To: Kumar Gala; Chris Ball >> Cc: linux-mmc@vger.kernel.org; Xie Shaohui-B21989; Anton Vorontsov >> Subject: RE: [PATCH v3] powerpc/esdhc: disable CMD23 for some Freescale >> SoCs >> >> >> >>> -----Original Message----- >>> From: Kumar Gala [mailto:galak@kernel.crashing.org] >>> Sent: Saturday, September 22, 2012 2:36 AM >>> To: Chris Ball >>> Cc: Huang Changming-R66093; linux-mmc@vger.kernel.org; Huang >>> Changming- R66093; Xie Shaohui-B21989; Anton Vorontsov >>> Subject: Re: [PATCH v3] powerpc/esdhc: disable CMD23 for some >>> Freescale SoCs >>> >>> >>> On Sep 21, 2012, at 11:08 AM, Chris Ball wrote: >>> >>>> Hi, >>>> >>>> On Fri, Sep 21 2012, r66093@freescale.com wrote: >>>>> --- a/drivers/mmc/host/sdhci-of-esdhc.c >>>>> +++ b/drivers/mmc/host/sdhci-of-esdhc.c >>>>> @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host >>>>> *host) } #endif >>>>> >>>>> +static const u32 non_cmd23_processor_table[] = { >>>>> + /* P1020 Dual/Single core */ >>>>> + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, >>>>> + /* P1021 Dual/Single core */ >>>>> + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, >>>>> + /* P1022 Dual/Single core */ >>>>> + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, >>>>> + /* P1024 Dual/Single core */ >>>>> + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, >>>>> + /* P1025 Dual/Single core */ >>>>> + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, >>>>> + /* P4080 and P4040 */ >>>>> + 0x820000, 0x820800, 0x820100, 0x820900 >>>> >>>> I don't see how this method improves on either of the previous two >>>> we've discussed. If anything, Kumar's suggested method seems better >>>> than this >>>> one: it detected the MMC IP revision, which I'd expect to be more >>>> reliable than building a list of which SoCs contain that IP. >>>> >>>> Why is this better than using DT or detecting the MMC revision? >>>> >>>> Thanks, >>> >>> I feel like I missed this patch, but I'd rather we go with the version >>> I sent since the # of IP versions we have is 3 or 4, instead of the 30 >>> or >>> 40 SoCs we have. >>> >> MPC8536 and P4080 have the same IP version (VVN1.0), but MPC8536 support >> CMD23, P4080 can't, how to handle these two silicones? >> For the future silicones, no one can make sure all silicones support >> CMD23. >> don't say almost 0%, which just is the assumption, otherwise, why p4080 >> can't support it and mpc8536 can? > MPC837x has the same VVN1.0 as the MPC8536 and p4080, which supports CMD23, too. So I checked on actual boards and got: MPC8536 - 00000001 MPC837x - 00000001 P4080 - 00001201 So I don't think you are correct about them reporting the same version number. (I think the manual for P4080 may be incorrect). Here's the other SoCs that I verified: 8536 = 00000001 2020 = 00000101 8569 = 00000101 4080 = 00001201 1021 = 00001201 1022 = 00001201 5040 = 00001301 2041 = 00001301 5020 = 00001301 1010 = 00001301 9131 = 00001301 - k-- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>> Hi, > >>>> > >>>> On Fri, Sep 21 2012, r66093@freescale.com wrote: > >>>>> --- a/drivers/mmc/host/sdhci-of-esdhc.c > >>>>> +++ b/drivers/mmc/host/sdhci-of-esdhc.c > >>>>> @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host > >>>>> *host) } #endif > >>>>> > >>>>> +static const u32 non_cmd23_processor_table[] = { > >>>>> + /* P1020 Dual/Single core */ > >>>>> + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, > >>>>> + /* P1021 Dual/Single core */ > >>>>> + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, > >>>>> + /* P1022 Dual/Single core */ > >>>>> + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, > >>>>> + /* P1024 Dual/Single core */ > >>>>> + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, > >>>>> + /* P1025 Dual/Single core */ > >>>>> + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, > >>>>> + /* P4080 and P4040 */ > >>>>> + 0x820000, 0x820800, 0x820100, 0x820900 > >>>> > >>>> I don't see how this method improves on either of the previous two > >>>> we've discussed. If anything, Kumar's suggested method seems > >>>> better than this > >>>> one: it detected the MMC IP revision, which I'd expect to be more > >>>> reliable than building a list of which SoCs contain that IP. > >>>> > >>>> Why is this better than using DT or detecting the MMC revision? > >>>> > >>>> Thanks, > >>> > >>> I feel like I missed this patch, but I'd rather we go with the > >>> version I sent since the # of IP versions we have is 3 or 4, instead > >>> of the 30 or > >>> 40 SoCs we have. > >>> > >> MPC8536 and P4080 have the same IP version (VVN1.0), but MPC8536 > >> support CMD23, P4080 can't, how to handle these two silicones? > >> For the future silicones, no one can make sure all silicones support > >> CMD23. > >> don't say almost 0%, which just is the assumption, otherwise, why > >> p4080 can't support it and mpc8536 can? > > MPC837x has the same VVN1.0 as the MPC8536 and p4080, which supports > CMD23, too. > > So I checked on actual boards and got: > > MPC8536 - 00000001 > MPC837x - 00000001 > P4080 - 00001201 > > So I don't think you are correct about them reporting the same version > number. (I think the manual for P4080 may be incorrect). > > Here's the other SoCs that I verified: > > 8536 = 00000001 > > 2020 = 00000101 > 8569 = 00000101 > > 4080 = 00001201 > 1021 = 00001201 > 1022 = 00001201 > > 5040 = 00001301 > 2041 = 00001301 > 5020 = 00001301 > 1010 = 00001301 > 9131 = 00001301 > Thank, I double check the version on p4080, it is 0x00001201. Then, I will send the patch to check the IP version. BTW: It is 0x00000001 in p4040 RM, I think the RM should be checked carefully before releasing to customer. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c index f8eb1fb..2f40a7f 100644 --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -143,6 +143,35 @@ static void esdhc_of_resume(struct sdhci_host *host) } #endif +static const u32 non_cmd23_processor_table[] = { + /* P1020 Dual/Single core */ + 0x80EC00, 0x80E400, 0x80ED00, 0x80E500, + /* P1021 Dual/Single core */ + 0x80EC01, 0x80E401, 0x80ED01, 0x80E501, + /* P1022 Dual/Single core */ + 0x80EE00, 0x80E600, 0x80EF00, 0x80E700, + /* P1024 Dual/Single core */ + 0x80EC02, 0x80E402, 0x80ED02, 0x80E502, + /* P1025 Dual/Single core */ + 0x80EC03, 0x80E403, 0x80ED03, 0x80E503, + /* P4080 and P4040 */ + 0x820000, 0x820800, 0x820100, 0x820900 +}; + +void esdhc_of_detect_limitation(struct sdhci_host *host) +{ + u32 svr = mfspr(SPRN_SVR) >> 8; + u32 table_size = ARRAY_SIZE(non_cmd23_processor_table); + int i; + + for (i = 0; i < table_size; i++) { + if (non_cmd23_processor_table[i] == svr) { + host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23; + break; + } + } +} + static struct sdhci_ops sdhci_esdhc_ops = { .read_l = sdhci_be32bs_readl, .read_w = esdhc_readw, @@ -158,6 +187,7 @@ static struct sdhci_ops sdhci_esdhc_ops = { .platform_suspend = esdhc_of_suspend, .platform_resume = esdhc_of_resume, #endif + .platform_limitation = esdhc_of_detect_limitation, }; static struct sdhci_pltfm_data sdhci_esdhc_pdata = { diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index d9a4ef4..864bedd 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -185,6 +185,9 @@ int sdhci_pltfm_register(struct platform_device *pdev, sdhci_get_of_property(pdev); + if (host->ops->platform_limitation) + host->ops->platform_limitation(host); + ret = sdhci_add_host(host); if (ret) sdhci_pltfm_free(pdev); diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 9a11dc3..6208a8b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2795,6 +2795,9 @@ int sdhci_add_host(struct sdhci_host *host) if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA)) mmc->caps |= MMC_CAP_4_BIT_DATA; + if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23) + mmc->caps &= ~MMC_CAP_CMD23; + if (caps[0] & SDHCI_CAN_DO_HISPD) mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index 97653ea..4296bef 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -278,6 +278,7 @@ struct sdhci_ops { void (*hw_reset)(struct sdhci_host *host); void (*platform_suspend)(struct sdhci_host *host); void (*platform_resume)(struct sdhci_host *host); + void (*platform_limitation)(struct sdhci_host *host); }; #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h index ac83b10..97c73f5 100644 --- a/include/linux/mmc/sdhci.h +++ b/include/linux/mmc/sdhci.h @@ -91,6 +91,7 @@ struct sdhci_host { unsigned int quirks2; /* More deviations from spec. */ #define SDHCI_QUIRK2_HOST_OFF_CARD_ON (1<<0) +#define SDHCI_QUIRK2_HOST_NO_CMD23 (1<<1) int irq; /* Device IRQ */ void __iomem *ioaddr; /* Mapped address */