Messages in this thread | | | From | Peter Geis <> | Date | Fri, 27 Jul 2018 16:19:53 -0400 | Subject | Re: [PATCH 3/3] mmc: tegra: prevent ACMD23 on Tegra 3 |
| |
<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>
| |