Messages in this thread | | | Subject | Re: [PATCH 3/3] mmc: tegra: prevent ACMD23 on Tegra 3 | From | Peter Geis <> | Date | Thu, 26 Jul 2018 13:48:55 -0400 |
| |
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
| |