| Message ID | 20180712073904.4705-3-stefan@agner.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/12/2018 03:39 AM, Stefan Agner wrote: > It seems that SD3.0 advertisement needs to be set for higher eMMC > speed modes (namely DDR52) as well. The TRM states that the SD3.0 > advertisement bit should be set for all controller instances, even > for those not supporting UHS-I mode... > > When specifying vqmmc-supply as a fixed 1.8V regulator on a Tegra > SD/MMC instance which is connected to a eMMC device, the stack > enables SD3.0. However, enabling it has consequences: If SDHCI 3.0 > support is advertised the stack enables Auto-CMD23. Unfortunately > Auto-CMD23 seems not to work well with Tegra 3 currently. It leads > to regular warnings: > mmc2: Got command interrupt 0x00010000 even though no command operation was in progress. > > It is not entirely clear why those errors happens. It seems that > a Linux 3.1 based downstream kernel which has Auto-CMD23 support > does not show those warnings. > > Use quirk SDHCI_QUIRK2_ACMD23_BROKEN to prevent Auto-CMD23 being > used for now. With this the eMMC works stable on high-speed mode > while still announcing SD3.0. > > This allows to use mmc-ddr-1_8v to enables DDR52 mode. In DDR52 > mode read speed improves from about 42MiB/s to 72MiB/s on an > Apalis T30. > > Signed-off-by: Stefan Agner <stefan@agner.ch> > --- > drivers/mmc/host/sdhci-tegra.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c > index 888a1ad511db..11c0b2069c7c 100644 > --- a/drivers/mmc/host/sdhci-tegra.c > +++ b/drivers/mmc/host/sdhci-tegra.c > @@ -336,7 +336,15 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = { > SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC | > SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN, > .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN | > - SDHCI_QUIRK2_BROKEN_HS200, > + SDHCI_QUIRK2_BROKEN_HS200 | > + /* > + * Auto-CMD23 leads to "Got command interrupt 0x00010000 even > + * though no command operation was in progress." > + * > + * The exact reason is unknown, as the same hardware seems > + * to support Auto CMD23 on a downstream 3.1 kernel. > + */ > + SDHCI_QUIRK2_ACMD23_BROKEN, > .ops = &tegra_sdhci_ops, > }; > I finally got around to testing this on the Ouya (Tegra 3). I found that the "Got command interrupt 0x00010000 even though no command operation was in progress." error occurred when the interface is unstable. I've had a lot of problems with sdmmc4 stability on the Ouya above 34 Mhz, probably due to the fact that they are using the internal cmd and clock pull-up resistors, against the TRM's instruction. At 39Mhz, I saw the error this patch corrects. With the patch, the error went away, but the interface is still unstable under load. Lowering down to 32Mhz, without the patch there are no errors. -- 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 26.07.2018 15:56, Peter Geis wrote: > On 07/12/2018 03:39 AM, Stefan Agner wrote: >> It seems that SD3.0 advertisement needs to be set for higher eMMC >> speed modes (namely DDR52) as well. The TRM states that the SD3.0 >> advertisement bit should be set for all controller instances, even >> for those not supporting UHS-I mode... >> >> When specifying vqmmc-supply as a fixed 1.8V regulator on a Tegra >> SD/MMC instance which is connected to a eMMC device, the stack >> enables SD3.0. However, enabling it has consequences: If SDHCI 3.0 >> support is advertised the stack enables Auto-CMD23. Unfortunately >> Auto-CMD23 seems not to work well with Tegra 3 currently. It leads >> to regular warnings: >> mmc2: Got command interrupt 0x00010000 even though no command operation was in progress. >> >> It is not entirely clear why those errors happens. It seems that >> a Linux 3.1 based downstream kernel which has Auto-CMD23 support >> does not show those warnings. >> >> Use quirk SDHCI_QUIRK2_ACMD23_BROKEN to prevent Auto-CMD23 being >> used for now. With this the eMMC works stable on high-speed mode >> while still announcing SD3.0. >> >> This allows to use mmc-ddr-1_8v to enables DDR52 mode. In DDR52 >> mode read speed improves from about 42MiB/s to 72MiB/s on an >> Apalis T30. >> >> Signed-off-by: Stefan Agner <stefan@agner.ch> >> --- >> drivers/mmc/host/sdhci-tegra.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c >> index 888a1ad511db..11c0b2069c7c 100644 >> --- a/drivers/mmc/host/sdhci-tegra.c >> +++ b/drivers/mmc/host/sdhci-tegra.c >> @@ -336,7 +336,15 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = { >> SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC | >> SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN, >> .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN | >> - SDHCI_QUIRK2_BROKEN_HS200, >> + SDHCI_QUIRK2_BROKEN_HS200 | >> + /* >> + * Auto-CMD23 leads to "Got command interrupt 0x00010000 even >> + * though no command operation was in progress." >> + * >> + * The exact reason is unknown, as the same hardware seems >> + * to support Auto CMD23 on a downstream 3.1 kernel. >> + */ >> + SDHCI_QUIRK2_ACMD23_BROKEN, >> .ops = &tegra_sdhci_ops, >> }; >> > > I finally got around to testing this on the Ouya (Tegra 3). Thanks for testing! > > I found that the "Got command interrupt 0x00010000 even though no > command operation was in progress." error occurred when the interface > is unstable. > I've had a lot of problems with sdmmc4 stability on the Ouya above 34 > Mhz, probably due to the fact that they are using the internal cmd and > clock pull-up resistors, against the TRM's instruction. > At 39Mhz, I saw the error this patch corrects. > With the patch, the error went away, but the interface is still > unstable under load. How does this instability manifest exactly? > > Lowering down to 32Mhz, without the patch there are no errors. So the patch does not make it less stable right? -- Stefan -- 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 07/26/2018 10:47 AM, Stefan Agner wrote: > On 26.07.2018 15:56, Peter Geis wrote: >> On 07/12/2018 03:39 AM, Stefan Agner wrote: >>> It seems that SD3.0 advertisement needs to be set for higher eMMC >>> speed modes (namely DDR52) as well. The TRM states that the SD3.0 >>> advertisement bit should be set for all controller instances, even >>> for those not supporting UHS-I mode... >>> >>> When specifying vqmmc-supply as a fixed 1.8V regulator on a Tegra >>> SD/MMC instance which is connected to a eMMC device, the stack >>> enables SD3.0. However, enabling it has consequences: If SDHCI 3.0 >>> support is advertised the stack enables Auto-CMD23. Unfortunately >>> Auto-CMD23 seems not to work well with Tegra 3 currently. It leads >>> to regular warnings: >>> mmc2: Got command interrupt 0x00010000 even though no command operation was in progress. >>> >>> It is not entirely clear why those errors happens. It seems that >>> a Linux 3.1 based downstream kernel which has Auto-CMD23 support >>> does not show those warnings. >>> >>> Use quirk SDHCI_QUIRK2_ACMD23_BROKEN to prevent Auto-CMD23 being >>> used for now. With this the eMMC works stable on high-speed mode >>> while still announcing SD3.0. >>> >>> This allows to use mmc-ddr-1_8v to enables DDR52 mode. In DDR52 >>> mode read speed improves from about 42MiB/s to 72MiB/s on an >>> Apalis T30. >>> >>> Signed-off-by: Stefan Agner <stefan@agner.ch> >>> --- >>> drivers/mmc/host/sdhci-tegra.c | 10 +++++++++- >>> 1 file changed, 9 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c >>> index 888a1ad511db..11c0b2069c7c 100644 >>> --- a/drivers/mmc/host/sdhci-tegra.c >>> +++ b/drivers/mmc/host/sdhci-tegra.c >>> @@ -336,7 +336,15 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = { >>> SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC | >>> SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN, >>> .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN | >>> - SDHCI_QUIRK2_BROKEN_HS200, >>> + SDHCI_QUIRK2_BROKEN_HS200 | >>> + /* >>> + * Auto-CMD23 leads to "Got command interrupt 0x00010000 even >>> + * though no command operation was in progress." >>> + * >>> + * The exact reason is unknown, as the same hardware seems >>> + * to support Auto CMD23 on a downstream 3.1 kernel. >>> + */ >>> + SDHCI_QUIRK2_ACMD23_BROKEN, >>> .ops = &tegra_sdhci_ops, >>> }; >>> >> >> I finally got around to testing this on the Ouya (Tegra 3). > > Thanks for testing! > >> >> I found that the "Got command interrupt 0x00010000 even though no >> command operation was in progress." error occurred when the interface >> is unstable. >> I've had a lot of problems with sdmmc4 stability on the Ouya above 34 >> Mhz, probably due to the fact that they are using the internal cmd and >> clock pull-up resistors, against the TRM's instruction. >> At 39Mhz, I saw the error this patch corrects. >> With the patch, the error went away, but the interface is still >> unstable under load. > > How does this instability manifest exactly? > At the very edge of stability, you see write errors under heavy load. As clock rate increases, the write errors occur more frequently. At a certain point, you start getting read errors. Following that you get constant io errors during card probing. Eventually the emmc will fail to initialize, with errors 87 or 110. I've been tweaking the pull up/down values to try and improve the stability, but without access to anything but the TRM it's a lot of trial and error. >> >> Lowering down to 32Mhz, without the patch there are no errors. > > So the patch does not make it less stable right? > No, it did not affect stability. Although I'd conduct some performance testing to check for degradation. Of course I'm nowhere near the limits of the controller, so it is doubtful I'd see a hit. > -- > Stefan > -- 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 26.07.2018 17:12, Peter Geis wrote: > On 07/26/2018 10:47 AM, Stefan Agner wrote: >> On 26.07.2018 15:56, Peter Geis wrote: >>> On 07/12/2018 03:39 AM, Stefan Agner wrote: >>>> It seems that SD3.0 advertisement needs to be set for higher eMMC >>>> speed modes (namely DDR52) as well. The TRM states that the SD3.0 >>>> advertisement bit should be set for all controller instances, even >>>> for those not supporting UHS-I mode... >>>> >>>> When specifying vqmmc-supply as a fixed 1.8V regulator on a Tegra >>>> SD/MMC instance which is connected to a eMMC device, the stack >>>> enables SD3.0. However, enabling it has consequences: If SDHCI 3.0 >>>> support is advertised the stack enables Auto-CMD23. Unfortunately >>>> Auto-CMD23 seems not to work well with Tegra 3 currently. It leads >>>> to regular warnings: >>>> mmc2: Got command interrupt 0x00010000 even though no command operation was in progress. >>>> >>>> It is not entirely clear why those errors happens. It seems that >>>> a Linux 3.1 based downstream kernel which has Auto-CMD23 support >>>> does not show those warnings. >>>> >>>> Use quirk SDHCI_QUIRK2_ACMD23_BROKEN to prevent Auto-CMD23 being >>>> used for now. With this the eMMC works stable on high-speed mode >>>> while still announcing SD3.0. >>>> >>>> This allows to use mmc-ddr-1_8v to enables DDR52 mode. In DDR52 >>>> mode read speed improves from about 42MiB/s to 72MiB/s on an >>>> Apalis T30. >>>> >>>> Signed-off-by: Stefan Agner <stefan@agner.ch> >>>> --- >>>> drivers/mmc/host/sdhci-tegra.c | 10 +++++++++- >>>> 1 file changed, 9 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c >>>> index 888a1ad511db..11c0b2069c7c 100644 >>>> --- a/drivers/mmc/host/sdhci-tegra.c >>>> +++ b/drivers/mmc/host/sdhci-tegra.c >>>> @@ -336,7 +336,15 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = { >>>> SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC | >>>> SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN, >>>> .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN | >>>> - SDHCI_QUIRK2_BROKEN_HS200, >>>> + SDHCI_QUIRK2_BROKEN_HS200 | >>>> + /* >>>> + * Auto-CMD23 leads to "Got command interrupt 0x00010000 even >>>> + * though no command operation was in progress." >>>> + * >>>> + * The exact reason is unknown, as the same hardware seems >>>> + * to support Auto CMD23 on a downstream 3.1 kernel. >>>> + */ >>>> + SDHCI_QUIRK2_ACMD23_BROKEN, >>>> .ops = &tegra_sdhci_ops, >>>> }; >>>> >>> >>> I finally got around to testing this on the Ouya (Tegra 3). >> >> Thanks for testing! >> >>> >>> I found that the "Got command interrupt 0x00010000 even though no >>> command operation was in progress." error occurred when the interface >>> is unstable. >>> I've had a lot of problems with sdmmc4 stability on the Ouya above 34 >>> Mhz, probably due to the fact that they are using the internal cmd and >>> clock pull-up resistors, against the TRM's instruction. >>> At 39Mhz, I saw the error this patch corrects. >>> With the patch, the error went away, but the interface is still >>> unstable under load. >> >> How does this instability manifest exactly? >> > > At the very edge of stability, you see write errors under heavy load. > As clock rate increases, the write errors occur more frequently. > At a certain point, you start getting read errors. > Following that you get constant io errors during card probing. > Eventually the emmc will fail to initialize, with errors 87 or 110. What mode are you running at actually? E.g. what is the ios file saying? cat /sys/kernel/debug/mmcX/ios > > I've been tweaking the pull up/down values to try and improve the > stability, but without access to anything but the TRM it's a lot of > trial and error. > Hm, maybe Marcel's recent fixes in our device tree are helpful? https://lkml.org/lkml/2018/7/22/165 Also make sure to have a complete pinmux such that alternative pins for sdmmc4 are *not* muxed as sdmmc4. >>> >>> Lowering down to 32Mhz, without the patch there are no errors. >> >> So the patch does not make it less stable right? >> > > No, it did not affect stability. > Although I'd conduct some performance testing to check for degradation. > Of course I'm nowhere near the limits of the controller, so it is > doubtful I'd see a hit. Ok, and this is with the complete patchset applied correct? Btw, what device tree are you using? Ouya is not upstream as far as I can tell? -- Stefan > >> -- >> Stefan >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" 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
>>>> I finally got around to testing this on the Ouya (Tegra 3). >>> >>> Thanks for testing! >>> >>>> >>>> I found that the "Got command interrupt 0x00010000 even though no >>>> command operation was in progress." error occurred when the interface >>>> is unstable. >>>> I've had a lot of problems with sdmmc4 stability on the Ouya above 34 >>>> Mhz, probably due to the fact that they are using the internal cmd and >>>> clock pull-up resistors, against the TRM's instruction. >>>> At 39Mhz, I saw the error this patch corrects. >>>> With the patch, the error went away, but the interface is still >>>> unstable under load. >>> >>> How does this instability manifest exactly? >>> >> >> At the very edge of stability, you see write errors under heavy load. >> As clock rate increases, the write errors occur more frequently. >> At a certain point, you start getting read errors. >> Following that you get constant io errors during card probing. >> Eventually the emmc will fail to initialize, with errors 87 or 110. > > What mode are you running at actually? E.g. what is the ios file saying? > cat /sys/kernel/debug/mmcX/ios This is the best functionality I've been able to get prior to the patches: root@ouya:~# cat /sys/kernel/debug/mmc0/ios clock: 30000000 Hz actual clock: 29142858 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 9 (mmc HS200) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) Now I am trying DDR, but even with the patches I'm not able to remain stable above 17Mhz (34Mhz clock). I've also tried just straight mmc-hs mode, but even that makes no difference. > >> >> I've been tweaking the pull up/down values to try and improve the >> stability, but without access to anything but the TRM it's a lot of >> trial and error. >> > > Hm, maybe Marcel's recent fixes in our device tree are helpful? > https://lkml.org/lkml/2018/7/22/165 > > Also make sure to have a complete pinmux such that alternative pins for > sdmmc4 are *not* muxed as sdmmc4. That was my first issue, which was preventing sdmmc4 from working at all. Just double checked all of the spare function pins, they are all assigned elsewhere. > >>>> >>>> Lowering down to 32Mhz, without the patch there are no errors. >>> >>> So the patch does not make it less stable right? >>> >> >> No, it did not affect stability. >> Although I'd conduct some performance testing to check for degradation. >> Of course I'm nowhere near the limits of the controller, so it is >> doubtful I'd see a hit. > > Ok, and this is with the complete patchset applied correct? > > Btw, what device tree are you using? Ouya is not upstream as far as I > can tell? Indeed, I have the full patchset. Ouya is an old android game console that I've been working on getting mainline working on. I've written most of the device tree, with contributions from Matt Merhar. It's almost bit for bit a cardhu dev board, but with everything not necessary to function removed. They cut a lot of corners with the board design. Last stable kernel was 3.2, but it ran fine at 52mhz, mind you it reported it was running mode 5. To get this speed, I have the pins all driven down at 4, and up at 24. Default is 2 down and 18 up from driver init. The pin pull ups are exactly as the original kernel, all pins pulled up except reset, which is pulled down. > > -- > Stefan > >> >>> -- >>> Stefan >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-tegra" 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
On 26.07.2018 18:39, Peter Geis wrote: >>>>> I finally got around to testing this on the Ouya (Tegra 3). >>>> >>>> Thanks for testing! >>>> >>>>> >>>>> I found that the "Got command interrupt 0x00010000 even though no >>>>> command operation was in progress." error occurred when the interface >>>>> is unstable. >>>>> I've had a lot of problems with sdmmc4 stability on the Ouya above 34 >>>>> Mhz, probably due to the fact that they are using the internal cmd and >>>>> clock pull-up resistors, against the TRM's instruction. >>>>> At 39Mhz, I saw the error this patch corrects. >>>>> With the patch, the error went away, but the interface is still >>>>> unstable under load. >>>> >>>> How does this instability manifest exactly? >>>> >>> >>> At the very edge of stability, you see write errors under heavy load. >>> As clock rate increases, the write errors occur more frequently. >>> At a certain point, you start getting read errors. >>> Following that you get constant io errors during card probing. >>> Eventually the emmc will fail to initialize, with errors 87 or 110. >> >> What mode are you running at actually? E.g. what is the ios file saying? >> cat /sys/kernel/debug/mmcX/ios > > This is the best functionality I've been able to get prior to the patches: > root@ouya:~# cat /sys/kernel/debug/mmc0/ios > clock: 30000000 Hz > actual clock: 29142858 Hz > vdd: 21 (3.3 ~ 3.4 V) > bus mode: 2 (push-pull) > chip select: 0 (don't care) > power mode: 2 (on) > bus width: 3 (8 bits) > timing spec: 9 (mmc HS200) > signal voltage: 1 (1.80 V) > driver type: 0 (driver type B) > Yeah HS200 is definilty not supported by the controller and really should not be used. > Now I am trying DDR, but even with the patches I'm not able to remain > stable above 17Mhz (34Mhz clock). > > I've also tried just straight mmc-hs mode, but even that makes no difference. > So you tried timing spec 1 (mmc HS)? How did you exactly enable mmc-hs mode? I suggest to *not set* vqmmc and apply patch 1. It will report that signaling voltage is 3.3V, but that did not really matter in our case. This was our baseline and always worked stable on mainline. I also would use that mode when tweaking pinmux etc... >> >>> >>> I've been tweaking the pull up/down values to try and improve the >>> stability, but without access to anything but the TRM it's a lot of >>> trial and error. >>> >> >> Hm, maybe Marcel's recent fixes in our device tree are helpful? >> https://lkml.org/lkml/2018/7/22/165 >> >> Also make sure to have a complete pinmux such that alternative pins for >> sdmmc4 are *not* muxed as sdmmc4. > > That was my first issue, which was preventing sdmmc4 from working at all. > Just double checked all of the spare function pins, they are all > assigned elsewhere. > Ok. >> >>>>> >>>>> Lowering down to 32Mhz, without the patch there are no errors. >>>> >>>> So the patch does not make it less stable right? >>>> >>> >>> No, it did not affect stability. >>> Although I'd conduct some performance testing to check for degradation. >>> Of course I'm nowhere near the limits of the controller, so it is >>> doubtful I'd see a hit. >> >> Ok, and this is with the complete patchset applied correct? >> >> Btw, what device tree are you using? Ouya is not upstream as far as I >> can tell? > > Indeed, I have the full patchset. > > Ouya is an old android game console that I've been working on getting > mainline working on. I know, I have one sitting here too. I only tried to tinker a bit at the very beginning... > I've written most of the device tree, with contributions from Matt Merhar. > It's almost bit for bit a cardhu dev board, but with everything not > necessary to function removed. > They cut a lot of corners with the board design. > Last stable kernel was 3.2, but it ran fine at 52mhz, mind you it > reported it was running mode 5. That is what we saw too. With Apalis/Colibri T30 L4T downstream kernel (which is 3.1 with quite some patches) 52MHz DDR worked fine, surprisingly even with ACMD23. However, speed is slightly slower than mainline 52MHz without ACMD23... -- Stefan > > To get this speed, I have the pins all driven down at 4, and up at 24. > Default is 2 down and 18 up from driver init. > The pin pull ups are exactly as the original kernel, all pins pulled > up except reset, which is pulled down. > >> >> -- >> Stefan >> >>> >>>> -- >>>> Stefan >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" 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
On 07/26/2018 01:36 PM, Stefan Agner wrote: > On 26.07.2018 18:39, Peter Geis wrote: >>>>>> I finally got around to testing this on the Ouya (Tegra 3). >>>>> >>>>> Thanks for testing! >>>>> >>>>>> >>>>>> I found that the "Got command interrupt 0x00010000 even though no >>>>>> command operation was in progress." error occurred when the interface >>>>>> is unstable. >>>>>> I've had a lot of problems with sdmmc4 stability on the Ouya above 34 >>>>>> Mhz, probably due to the fact that they are using the internal cmd and >>>>>> clock pull-up resistors, against the TRM's instruction. >>>>>> At 39Mhz, I saw the error this patch corrects. >>>>>> With the patch, the error went away, but the interface is still >>>>>> unstable under load. >>>>> >>>>> How does this instability manifest exactly? >>>>> >>>> >>>> At the very edge of stability, you see write errors under heavy load. >>>> As clock rate increases, the write errors occur more frequently. >>>> At a certain point, you start getting read errors. >>>> Following that you get constant io errors during card probing. >>>> Eventually the emmc will fail to initialize, with errors 87 or 110. >>> >>> What mode are you running at actually? E.g. what is the ios file saying? >>> cat /sys/kernel/debug/mmcX/ios >> >> This is the best functionality I've been able to get prior to the patches: >> root@ouya:~# cat /sys/kernel/debug/mmc0/ios >> clock: 30000000 Hz >> actual clock: 29142858 Hz >> vdd: 21 (3.3 ~ 3.4 V) >> bus mode: 2 (push-pull) >> chip select: 0 (don't care) >> power mode: 2 (on) >> bus width: 3 (8 bits) >> timing spec: 9 (mmc HS200) >> signal voltage: 1 (1.80 V) >> driver type: 0 (driver type B) >> > > Yeah HS200 is definilty not supported by the controller and really > should not be used. > >> Now I am trying DDR, but even with the patches I'm not able to remain >> stable above 17Mhz (34Mhz clock). >> >> I've also tried just straight mmc-hs mode, but even that makes no difference. >> > > So you tried timing spec 1 (mmc HS)? > > How did you exactly enable mmc-hs mode? cap-mmc-highspeed; > > I suggest to *not set* vqmmc and apply patch 1. It will report that > signaling voltage is 3.3V, but that did not really matter in our case. > This was our baseline and always worked stable on mainline. I also would > use that mode when tweaking pinmux etc... Will do, thanks. > >>> >>>> >>>> I've been tweaking the pull up/down values to try and improve the >>>> stability, but without access to anything but the TRM it's a lot of >>>> trial and error. >>>> >>> >>> Hm, maybe Marcel's recent fixes in our device tree are helpful? >>> https://lkml.org/lkml/2018/7/22/165 >>> >>> Also make sure to have a complete pinmux such that alternative pins for >>> sdmmc4 are *not* muxed as sdmmc4. >> >> That was my first issue, which was preventing sdmmc4 from working at all. >> Just double checked all of the spare function pins, they are all >> assigned elsewhere. >> > > Ok. > >>> >>>>>> >>>>>> Lowering down to 32Mhz, without the patch there are no errors. >>>>> >>>>> So the patch does not make it less stable right? >>>>> >>>> >>>> No, it did not affect stability. >>>> Although I'd conduct some performance testing to check for degradation. >>>> Of course I'm nowhere near the limits of the controller, so it is >>>> doubtful I'd see a hit. >>> >>> Ok, and this is with the complete patchset applied correct? >>> >>> Btw, what device tree are you using? Ouya is not upstream as far as I >>> can tell? >> >> Indeed, I have the full patchset. >> >> Ouya is an old android game console that I've been working on getting >> mainline working on. > > I know, I have one sitting here too. I only tried to tinker a bit at the > very beginning... It runs Xubuntu very well now with mainline. I've got most everything roughly supported with the exception of audio. > >> I've written most of the device tree, with contributions from Matt Merhar. >> It's almost bit for bit a cardhu dev board, but with everything not >> necessary to function removed. >> They cut a lot of corners with the board design. >> Last stable kernel was 3.2, but it ran fine at 52mhz, mind you it >> reported it was running mode 5. > > That is what we saw too. With Apalis/Colibri T30 L4T downstream kernel > (which is 3.1 with quite some patches) 52MHz DDR worked fine, > surprisingly even with ACMD23. However, speed is slightly slower than > mainline 52MHz without ACMD23... I noticed the same thing, speed with the original kernel on the MMC was worse at 52Mhz than it was at 34Mhz in HS-200 mode on mainline. I'd be happy with it where it is, but the fact that it worked at 52Mhz before makes me believe something isn't quite there yet. I selected HS-200 mode just to force 1.8v mode. > > -- > Stefan > >> >> To get this speed, I have the pins all driven down at 4, and up at 24. >> Default is 2 down and 18 up from driver init. >> The pin pull ups are exactly as the original kernel, all pins pulled >> up except reset, which is pulled down. >> >>> >>> -- >>> Stefan >>> >>>> >>>>> -- >>>>> Stefan >>>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" 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
On Thursday, 26 July 2018 20:48:55 MSK Peter Geis wrote: > On 07/26/2018 01:36 PM, Stefan Agner wrote: > > On 26.07.2018 18:39, Peter Geis wrote: > >>>>>> I finally got around to testing this on the Ouya (Tegra 3). > >>>>> > >>>>> Thanks for testing! > >>>>> > >>>>>> I found that the "Got command interrupt 0x00010000 even though no > >>>>>> command operation was in progress." error occurred when the interface > >>>>>> is unstable. > >>>>>> I've had a lot of problems with sdmmc4 stability on the Ouya above 34 > >>>>>> Mhz, probably due to the fact that they are using the internal cmd > >>>>>> and > >>>>>> clock pull-up resistors, against the TRM's instruction. > >>>>>> At 39Mhz, I saw the error this patch corrects. > >>>>>> With the patch, the error went away, but the interface is still > >>>>>> unstable under load. > >>>>> > >>>>> How does this instability manifest exactly? > >>>> > >>>> At the very edge of stability, you see write errors under heavy load. > >>>> As clock rate increases, the write errors occur more frequently. > >>>> At a certain point, you start getting read errors. > >>>> Following that you get constant io errors during card probing. > >>>> Eventually the emmc will fail to initialize, with errors 87 or 110. > >>> > >>> What mode are you running at actually? E.g. what is the ios file saying? > >>> cat /sys/kernel/debug/mmcX/ios > >> > >> This is the best functionality I've been able to get prior to the > >> patches: > >> root@ouya:~# cat /sys/kernel/debug/mmc0/ios > >> clock: 30000000 Hz > >> actual clock: 29142858 Hz > >> vdd: 21 (3.3 ~ 3.4 V) > >> bus mode: 2 (push-pull) > >> chip select: 0 (don't care) > >> power mode: 2 (on) > >> bus width: 3 (8 bits) > >> timing spec: 9 (mmc HS200) > >> signal voltage: 1 (1.80 V) > >> driver type: 0 (driver type B) > > > > Yeah HS200 is definilty not supported by the controller and really > > should not be used. > > > >> Now I am trying DDR, but even with the patches I'm not able to remain > >> stable above 17Mhz (34Mhz clock). > >> > >> I've also tried just straight mmc-hs mode, but even that makes no > >> difference.> > > So you tried timing spec 1 (mmc HS)? > > > > How did you exactly enable mmc-hs mode? > > cap-mmc-highspeed; > > > I suggest to *not set* vqmmc and apply patch 1. It will report that > > signaling voltage is 3.3V, but that did not really matter in our case. > > This was our baseline and always worked stable on mainline. I also would > > use that mode when tweaking pinmux etc... > > Will do, thanks. > > >>>> I've been tweaking the pull up/down values to try and improve the > >>>> stability, but without access to anything but the TRM it's a lot of > >>>> trial and error. > >>> > >>> Hm, maybe Marcel's recent fixes in our device tree are helpful? > >>> https://lkml.org/lkml/2018/7/22/165 > >>> > >>> Also make sure to have a complete pinmux such that alternative pins for > >>> sdmmc4 are *not* muxed as sdmmc4. > >> > >> That was my first issue, which was preventing sdmmc4 from working at all. > >> Just double checked all of the spare function pins, they are all > >> assigned elsewhere. > > > > Ok. > > > >>>>>> Lowering down to 32Mhz, without the patch there are no errors. > >>>>> > >>>>> So the patch does not make it less stable right? > >>>> > >>>> No, it did not affect stability. > >>>> Although I'd conduct some performance testing to check for degradation. > >>>> Of course I'm nowhere near the limits of the controller, so it is > >>>> doubtful I'd see a hit. > >>> > >>> Ok, and this is with the complete patchset applied correct? > >>> > >>> Btw, what device tree are you using? Ouya is not upstream as far as I > >>> can tell? > >> > >> Indeed, I have the full patchset. > >> > >> Ouya is an old android game console that I've been working on getting > >> mainline working on. > > > > I know, I have one sitting here too. I only tried to tinker a bit at the > > very beginning... > > It runs Xubuntu very well now with mainline. > I've got most everything roughly supported with the exception of audio. > > >> I've written most of the device tree, with contributions from Matt > >> Merhar. > >> It's almost bit for bit a cardhu dev board, but with everything not > >> necessary to function removed. > >> They cut a lot of corners with the board design. > >> Last stable kernel was 3.2, but it ran fine at 52mhz, mind you it > >> reported it was running mode 5. > > > > That is what we saw too. With Apalis/Colibri T30 L4T downstream kernel > > (which is 3.1 with quite some patches) 52MHz DDR worked fine, > > surprisingly even with ACMD23. However, speed is slightly slower than > > mainline 52MHz without ACMD23... > > I noticed the same thing, speed with the original kernel on the MMC was > worse at 52Mhz than it was at 34Mhz in HS-200 mode on mainline. > I'd be happy with it where it is, but the fact that it worked at 52Mhz > before makes me believe something isn't quite there yet. > I selected HS-200 mode just to force 1.8v mode. What's the card model your Ouya's eMMC has? -- 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
Kingston KE4CN3K6A. Though I am pretty sure I've figured out the instability. Brought it in to work and hooked it to a scope. Couldn't find clock, but cmd and all eight bits are running at 1.2 volts. Repeated the results with the bootloader, the original kernel, and my mainline. Also noticed that even on the slowest slew rate there is significant ringing and overshoot of .15 volts. On Fri, Jul 27, 2018, 15:52 Dmitry Osipenko <digetx@gmail.com> wrote: > On Thursday, 26 July 2018 20:48:55 MSK Peter Geis wrote: > > On 07/26/2018 01:36 PM, Stefan Agner wrote: > > > On 26.07.2018 18:39, Peter Geis wrote: > > >>>>>> I finally got around to testing this on the Ouya (Tegra 3). > > >>>>> > > >>>>> Thanks for testing! > > >>>>> > > >>>>>> I found that the "Got command interrupt 0x00010000 even though no > > >>>>>> command operation was in progress." error occurred when the > interface > > >>>>>> is unstable. > > >>>>>> I've had a lot of problems with sdmmc4 stability on the Ouya > above 34 > > >>>>>> Mhz, probably due to the fact that they are using the internal cmd > > >>>>>> and > > >>>>>> clock pull-up resistors, against the TRM's instruction. > > >>>>>> At 39Mhz, I saw the error this patch corrects. > > >>>>>> With the patch, the error went away, but the interface is still > > >>>>>> unstable under load. > > >>>>> > > >>>>> How does this instability manifest exactly? > > >>>> > > >>>> At the very edge of stability, you see write errors under heavy > load. > > >>>> As clock rate increases, the write errors occur more frequently. > > >>>> At a certain point, you start getting read errors. > > >>>> Following that you get constant io errors during card probing. > > >>>> Eventually the emmc will fail to initialize, with errors 87 or 110. > > >>> > > >>> What mode are you running at actually? E.g. what is the ios file > saying? > > >>> cat /sys/kernel/debug/mmcX/ios > > >> > > >> This is the best functionality I've been able to get prior to the > > >> patches: > > >> root@ouya:~# cat /sys/kernel/debug/mmc0/ios > > >> clock: 30000000 Hz > > >> actual clock: 29142858 Hz > > >> vdd: 21 (3.3 ~ 3.4 V) > > >> bus mode: 2 (push-pull) > > >> chip select: 0 (don't care) > > >> power mode: 2 (on) > > >> bus width: 3 (8 bits) > > >> timing spec: 9 (mmc HS200) > > >> signal voltage: 1 (1.80 V) > > >> driver type: 0 (driver type B) > > > > > > Yeah HS200 is definilty not supported by the controller and really > > > should not be used. > > > > > >> Now I am trying DDR, but even with the patches I'm not able to remain > > >> stable above 17Mhz (34Mhz clock). > > >> > > >> I've also tried just straight mmc-hs mode, but even that makes no > > >> difference.> > > > So you tried timing spec 1 (mmc HS)? > > > > > > How did you exactly enable mmc-hs mode? > > > > cap-mmc-highspeed; > > > > > I suggest to *not set* vqmmc and apply patch 1. It will report that > > > signaling voltage is 3.3V, but that did not really matter in our case. > > > This was our baseline and always worked stable on mainline. I also > would > > > use that mode when tweaking pinmux etc... > > > > Will do, thanks. > > > > >>>> I've been tweaking the pull up/down values to try and improve the > > >>>> stability, but without access to anything but the TRM it's a lot of > > >>>> trial and error. > > >>> > > >>> Hm, maybe Marcel's recent fixes in our device tree are helpful? > > >>> https://lkml.org/lkml/2018/7/22/165 > > >>> > > >>> Also make sure to have a complete pinmux such that alternative pins > for > > >>> sdmmc4 are *not* muxed as sdmmc4. > > >> > > >> That was my first issue, which was preventing sdmmc4 from working at > all. > > >> Just double checked all of the spare function pins, they are all > > >> assigned elsewhere. > > > > > > Ok. > > > > > >>>>>> Lowering down to 32Mhz, without the patch there are no errors. > > >>>>> > > >>>>> So the patch does not make it less stable right? > > >>>> > > >>>> No, it did not affect stability. > > >>>> Although I'd conduct some performance testing to check for > degradation. > > >>>> Of course I'm nowhere near the limits of the controller, so it is > > >>>> doubtful I'd see a hit. > > >>> > > >>> Ok, and this is with the complete patchset applied correct? > > >>> > > >>> Btw, what device tree are you using? Ouya is not upstream as far as I > > >>> can tell? > > >> > > >> Indeed, I have the full patchset. > > >> > > >> Ouya is an old android game console that I've been working on getting > > >> mainline working on. > > > > > > I know, I have one sitting here too. I only tried to tinker a bit at > the > > > very beginning... > > > > It runs Xubuntu very well now with mainline. > > I've got most everything roughly supported with the exception of audio. > > > > >> I've written most of the device tree, with contributions from Matt > > >> Merhar. > > >> It's almost bit for bit a cardhu dev board, but with everything not > > >> necessary to function removed. > > >> They cut a lot of corners with the board design. > > >> Last stable kernel was 3.2, but it ran fine at 52mhz, mind you it > > >> reported it was running mode 5. > > > > > > That is what we saw too. With Apalis/Colibri T30 L4T downstream kernel > > > (which is 3.1 with quite some patches) 52MHz DDR worked fine, > > > surprisingly even with ACMD23. However, speed is slightly slower than > > > mainline 52MHz without ACMD23... > > > > I noticed the same thing, speed with the original kernel on the MMC was > > worse at 52Mhz than it was at 34Mhz in HS-200 mode on mainline. > > I'd be happy with it where it is, but the fact that it worked at 52Mhz > > before makes me believe something isn't quite there yet. > > I selected HS-200 mode just to force 1.8v mode. > > What's the card model your Ouya's eMMC has? > > > > > <div dir="auto"><span style="color:rgb(85,85,85);font-family:lato,arial,sans-serif;font-size:16px">Kingston </span><span style="font-size:16px;color:rgb(85,85,85);font-family:lato,arial,sans-serif">KE4CN3K6A.</span><div dir="auto"><font color="#555555" face="lato, arial, sans-serif"><span style="font-size:16px">Though I am pretty sure I've figured out the instability.</span></font></div><div dir="auto"><font color="#555555" face="lato, arial, sans-serif"><span style="font-size:16px">Brought it in to work and hooked it to a scope.</span></font></div><div dir="auto"><font color="#555555" face="lato, arial, sans-serif"><span style="font-size:16px">Couldn't find clock, but cmd and all eight bits are running at 1.2 volts.</span></font></div><div dir="auto"><font color="#555555" face="lato, arial, sans-serif"><span style="font-size:16px">Repeated the results with the bootloader, the original kernel, and my mainline.</span></font></div><div dir="auto"><font color="#555555" face="lato, arial, sans-serif"><span style="font-size:16px">Also noticed that even on the slowest slew rate there is significant ringing and overshoot of .15 volts.<br></span></font><div dir="auto"><div dir="auto"><span style="color:rgb(85,85,85);font-family:lato,arial,sans-serif;font-size:16px"><br></span></div><div dir="auto"><span style="color:rgb(85,85,85);font-family:lato,arial,sans-serif;font-size:16px"><br></span></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 27, 2018, 15:52 Dmitry Osipenko <<a href="mailto:digetx@gmail.com">digetx@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 26 July 2018 20:48:55 MSK Peter Geis wrote:<br> > On 07/26/2018 01:36 PM, Stefan Agner wrote:<br> > > On 26.07.2018 18:39, Peter Geis wrote:<br> > >>>>>> I finally got around to testing this on the Ouya (Tegra 3).<br> > >>>>> <br> > >>>>> Thanks for testing!<br> > >>>>> <br> > >>>>>> I found that the "Got command interrupt 0x00010000 even though no<br> > >>>>>> command operation was in progress." error occurred when the interface<br> > >>>>>> is unstable.<br> > >>>>>> I've had a lot of problems with sdmmc4 stability on the Ouya above 34<br> > >>>>>> Mhz, probably due to the fact that they are using the internal cmd<br> > >>>>>> and<br> > >>>>>> clock pull-up resistors, against the TRM's instruction.<br> > >>>>>> At 39Mhz, I saw the error this patch corrects.<br> > >>>>>> With the patch, the error went away, but the interface is still<br> > >>>>>> unstable under load.<br> > >>>>> <br> > >>>>> How does this instability manifest exactly?<br> > >>>> <br> > >>>> At the very edge of stability, you see write errors under heavy load.<br> > >>>> As clock rate increases, the write errors occur more frequently.<br> > >>>> At a certain point, you start getting read errors.<br> > >>>> Following that you get constant io errors during card probing.<br> > >>>> Eventually the emmc will fail to initialize, with errors 87 or 110.<br> > >>> <br> > >>> What mode are you running at actually? E.g. what is the ios file saying?<br> > >>> cat /sys/kernel/debug/mmcX/ios<br> > >> <br> > >> This is the best functionality I've been able to get prior to the<br> > >> patches:<br> > >> root@ouya:~# cat /sys/kernel/debug/mmc0/ios<br> > >> clock: 30000000 Hz<br> > >> actual clock: 29142858 Hz<br> > >> vdd: 21 (3.3 ~ 3.4 V)<br> > >> bus mode: 2 (push-pull)<br> > >> chip select: 0 (don't care)<br> > >> power mode: 2 (on)<br> > >> bus width: 3 (8 bits)<br> > >> timing spec: 9 (mmc HS200)<br> > >> signal voltage: 1 (1.80 V)<br> > >> driver type: 0 (driver type B)<br> > > <br> > > Yeah HS200 is definilty not supported by the controller and really<br> > > should not be used.<br> > > <br> > >> Now I am trying DDR, but even with the patches I'm not able to remain<br> > >> stable above 17Mhz (34Mhz clock).<br> > >> <br> > >> I've also tried just straight mmc-hs mode, but even that makes no<br> > >> difference.> <br> > > So you tried timing spec 1 (mmc HS)?<br> > > <br> > > How did you exactly enable mmc-hs mode?<br> > <br> > cap-mmc-highspeed;<br> > <br> > > I suggest to *not set* vqmmc and apply patch 1. It will report that<br> > > signaling voltage is 3.3V, but that did not really matter in our case.<br> > > This was our baseline and always worked stable on mainline. I also would<br> > > use that mode when tweaking pinmux etc...<br> > <br> > Will do, thanks.<br> > <br> > >>>> I've been tweaking the pull up/down values to try and improve the<br> > >>>> stability, but without access to anything but the TRM it's a lot of<br> > >>>> trial and error.<br> > >>> <br> > >>> Hm, maybe Marcel's recent fixes in our device tree are helpful?<br> > >>> <a href="https://lkml.org/lkml/2018/7/22/165" rel="noreferrer noreferrer" target="_blank">https://lkml.org/lkml/2018/7/22/165</a><br> > >>> <br> > >>> Also make sure to have a complete pinmux such that alternative pins for<br> > >>> sdmmc4 are *not* muxed as sdmmc4.<br> > >> <br> > >> That was my first issue, which was preventing sdmmc4 from working at all.<br> > >> Just double checked all of the spare function pins, they are all<br> > >> assigned elsewhere.<br> > > <br> > > Ok.<br> > > <br> > >>>>>> Lowering down to 32Mhz, without the patch there are no errors.<br> > >>>>> <br> > >>>>> So the patch does not make it less stable right?<br> > >>>> <br> > >>>> No, it did not affect stability.<br> > >>>> Although I'd conduct some performance testing to check for degradation.<br> > >>>> Of course I'm nowhere near the limits of the controller, so it is<br> > >>>> doubtful I'd see a hit.<br> > >>> <br> > >>> Ok, and this is with the complete patchset applied correct?<br> > >>> <br> > >>> Btw, what device tree are you using? Ouya is not upstream as far as I<br> > >>> can tell?<br> > >> <br> > >> Indeed, I have the full patchset.<br> > >> <br> > >> Ouya is an old android game console that I've been working on getting<br> > >> mainline working on.<br> > > <br> > > I know, I have one sitting here too. I only tried to tinker a bit at the<br> > > very beginning...<br> > <br> > It runs Xubuntu very well now with mainline.<br> > I've got most everything roughly supported with the exception of audio.<br> > <br> > >> I've written most of the device tree, with contributions from Matt<br> > >> Merhar.<br> > >> It's almost bit for bit a cardhu dev board, but with everything not<br> > >> necessary to function removed.<br> > >> They cut a lot of corners with the board design.<br> > >> Last stable kernel was 3.2, but it ran fine at 52mhz, mind you it<br> > >> reported it was running mode 5.<br> > > <br> > > That is what we saw too. With Apalis/Colibri T30 L4T downstream kernel<br> > > (which is 3.1 with quite some patches) 52MHz DDR worked fine,<br> > > surprisingly even with ACMD23. However, speed is slightly slower than<br> > > mainline 52MHz without ACMD23...<br> > <br> > I noticed the same thing, speed with the original kernel on the MMC was<br> > worse at 52Mhz than it was at 34Mhz in HS-200 mode on mainline.<br> > I'd be happy with it where it is, but the fact that it worked at 52Mhz<br> > before makes me believe something isn't quite there yet.<br> > I selected HS-200 mode just to force 1.8v mode.<br> <br> What's the card model your Ouya's eMMC has?<br> <br> <br> <br> <br> </blockquote></div>
On Friday, 27 July 2018 23:19:53 MSK Peter Geis wrote: > Kingston KE4CN3K6A. > Though I am pretty sure I've figured out the instability. > Brought it in to work and hooked it to a scope. > Couldn't find clock, but cmd and all eight bits are running at 1.2 volts. > Repeated the results with the bootloader, the original kernel, and my > mainline. > Also noticed that even on the slowest slew rate there is significant > ringing and overshoot of .15 volts. Okay, but eMMC is working fine with the original kernel, isn't it? -- 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 7/28/2018 6:13 AM, Dmitry Osipenko wrote: > On Friday, 27 July 2018 23:19:53 MSK Peter Geis wrote: >> Kingston KE4CN3K6A. >> Though I am pretty sure I've figured out the instability. >> Brought it in to work and hooked it to a scope. >> Couldn't find clock, but cmd and all eight bits are running at 1.2 volts. >> Repeated the results with the bootloader, the original kernel, and my >> mainline. >> Also noticed that even on the slowest slew rate there is significant >> ringing and overshoot of .15 volts. > > Okay, but eMMC is working fine with the original kernel, isn't it? > > Correct, at roughly double the speed of the mainline kernel. According to the mmc spec, in high voltage mode it should have 2.7-3.3 volts in, and the minimum signal voltage should be .75 of that, which equates to a minimum voltage of over 2 volts. For low voltage mode, it should be 1.8 volts in, with the signals being between .3 and .7 volts. Signal voltage of 1.3 volts is .75 of 1.8, which means we have low voltage in, but high voltage signaling. This is even with HS-200 or DDR-1.8 assigned in the controller mode, so for some reason we aren't switching modes. The original kernel was running in SDR 25 signaling, but didn't try to switch either. Digging through the old code and the TRM, there are three ideas stuck in my head. The original pinmux driver had settings such as low voltage divider and two values for each pull direction. The pinmux driver is io resetting specifically the pads we are using, dumping any values the bootloader had set. Is it possible the tap configuration is not working? -- 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-tegra.c b/drivers/mmc/host/sdhci-tegra.c index 888a1ad511db..11c0b2069c7c 100644 --- a/drivers/mmc/host/sdhci-tegra.c +++ b/drivers/mmc/host/sdhci-tegra.c @@ -336,7 +336,15 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = { SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC | SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN, .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN | - SDHCI_QUIRK2_BROKEN_HS200, + SDHCI_QUIRK2_BROKEN_HS200 | + /* + * Auto-CMD23 leads to "Got command interrupt 0x00010000 even + * though no command operation was in progress." + * + * The exact reason is unknown, as the same hardware seems + * to support Auto CMD23 on a downstream 3.1 kernel. + */ + SDHCI_QUIRK2_ACMD23_BROKEN, .ops = &tegra_sdhci_ops, };
It seems that SD3.0 advertisement needs to be set for higher eMMC speed modes (namely DDR52) as well. The TRM states that the SD3.0 advertisement bit should be set for all controller instances, even for those not supporting UHS-I mode... When specifying vqmmc-supply as a fixed 1.8V regulator on a Tegra SD/MMC instance which is connected to a eMMC device, the stack enables SD3.0. However, enabling it has consequences: If SDHCI 3.0 support is advertised the stack enables Auto-CMD23. Unfortunately Auto-CMD23 seems not to work well with Tegra 3 currently. It leads to regular warnings: mmc2: Got command interrupt 0x00010000 even though no command operation was in progress. It is not entirely clear why those errors happens. It seems that a Linux 3.1 based downstream kernel which has Auto-CMD23 support does not show those warnings. Use quirk SDHCI_QUIRK2_ACMD23_BROKEN to prevent Auto-CMD23 being used for now. With this the eMMC works stable on high-speed mode while still announcing SD3.0. This allows to use mmc-ddr-1_8v to enables DDR52 mode. In DDR52 mode read speed improves from about 42MiB/s to 72MiB/s on an Apalis T30. Signed-off-by: Stefan Agner <stefan@agner.ch> --- drivers/mmc/host/sdhci-tegra.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)