lkml.org 
[lkml]   [2018]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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&#39;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&#39;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 &lt;<a href="mailto:digetx@gmail.com">digetx@gmail.com</a>&gt; 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>
&gt; On 07/26/2018 01:36 PM, Stefan Agner wrote:<br>
&gt; &gt; On 26.07.2018 18:39, Peter Geis wrote:<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; I finally got around to testing this on the Ouya (Tegra 3).<br>
&gt; &gt;&gt;&gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt;&gt;&gt; Thanks for testing!<br>
&gt; &gt;&gt;&gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; I found that the &quot;Got command interrupt 0x00010000 even though no<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; command operation was in progress.&quot; error occurred when the interface<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; is unstable.<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; I&#39;ve had a lot of problems with sdmmc4 stability on the Ouya above 34<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Mhz, probably due to the fact that they are using the internal cmd<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; and<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; clock pull-up resistors, against the TRM&#39;s instruction.<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; At 39Mhz, I saw the error this patch corrects.<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; With the patch, the error went away, but the interface is still<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; unstable under load.<br>
&gt; &gt;&gt;&gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt;&gt;&gt; How does this instability manifest exactly?<br>
&gt; &gt;&gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt;&gt; At the very edge of stability, you see write errors under heavy load.<br>
&gt; &gt;&gt;&gt;&gt; As clock rate increases, the write errors occur more frequently.<br>
&gt; &gt;&gt;&gt;&gt; At a certain point, you start getting read errors.<br>
&gt; &gt;&gt;&gt;&gt; Following that you get constant io errors during card probing.<br>
&gt; &gt;&gt;&gt;&gt; Eventually the emmc will fail to initialize, with errors 87 or 110.<br>
&gt; &gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt; What mode are you running at actually? E.g. what is the ios file saying?<br>
&gt; &gt;&gt;&gt; cat /sys/kernel/debug/mmcX/ios<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; This is the best functionality I&#39;ve been able to get prior to the<br>
&gt; &gt;&gt; patches:<br>
&gt; &gt;&gt; root@ouya:~# cat /sys/kernel/debug/mmc0/ios<br>
&gt; &gt;&gt; clock:          30000000 Hz<br>
&gt; &gt;&gt; actual clock:   29142858 Hz<br>
&gt; &gt;&gt; vdd:            21 (3.3 ~ 3.4 V)<br>
&gt; &gt;&gt; bus mode:       2 (push-pull)<br>
&gt; &gt;&gt; chip select:    0 (don&#39;t care)<br>
&gt; &gt;&gt; power mode:     2 (on)<br>
&gt; &gt;&gt; bus width:      3 (8 bits)<br>
&gt; &gt;&gt; timing spec:    9 (mmc HS200)<br>
&gt; &gt;&gt; signal voltage: 1 (1.80 V)<br>
&gt; &gt;&gt; driver type:    0 (driver type B)<br>
&gt; &gt; <br>
&gt; &gt; Yeah HS200 is definilty not supported by the controller and really<br>
&gt; &gt; should not be used.<br>
&gt; &gt; <br>
&gt; &gt;&gt; Now I am trying DDR, but even with the patches I&#39;m not able to remain<br>
&gt; &gt;&gt; stable above 17Mhz (34Mhz clock).<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; I&#39;ve also tried just straight mmc-hs mode, but even that makes no<br>
&gt; &gt;&gt; difference.&gt; <br>
&gt; &gt; So you tried timing spec 1 (mmc HS)?<br>
&gt; &gt; <br>
&gt; &gt; How did you exactly enable mmc-hs mode?<br>
&gt; <br>
&gt; cap-mmc-highspeed;<br>
&gt; <br>
&gt; &gt; I suggest to *not set* vqmmc and apply patch 1. It will report that<br>
&gt; &gt; signaling voltage is 3.3V, but that did not really matter in our case.<br>
&gt; &gt; This was our baseline and always worked stable on mainline. I also would<br>
&gt; &gt; use that mode when tweaking pinmux etc...<br>
&gt; <br>
&gt; Will do, thanks.<br>
&gt; <br>
&gt; &gt;&gt;&gt;&gt; I&#39;ve been tweaking the pull up/down values to try and improve the<br>
&gt; &gt;&gt;&gt;&gt; stability, but without access to anything but the TRM it&#39;s a lot of<br>
&gt; &gt;&gt;&gt;&gt; trial and error.<br>
&gt; &gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt; Hm, maybe Marcel&#39;s recent fixes in our device tree are helpful?<br>
&gt; &gt;&gt;&gt; <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>
&gt; &gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt; Also make sure to have a complete pinmux such that alternative pins for<br>
&gt; &gt;&gt;&gt; sdmmc4 are *not* muxed as sdmmc4.<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; That was my first issue, which was preventing sdmmc4 from working at all.<br>
&gt; &gt;&gt; Just double checked all of the spare function pins, they are all<br>
&gt; &gt;&gt; assigned elsewhere.<br>
&gt; &gt; <br>
&gt; &gt; Ok.<br>
&gt; &gt; <br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Lowering down to 32Mhz, without the patch there are no errors.<br>
&gt; &gt;&gt;&gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt;&gt;&gt; So the patch does not make it less stable right?<br>
&gt; &gt;&gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt;&gt; No, it did not affect stability.<br>
&gt; &gt;&gt;&gt;&gt; Although I&#39;d conduct some performance testing to check for degradation.<br>
&gt; &gt;&gt;&gt;&gt; Of course I&#39;m nowhere near the limits of the controller, so it is<br>
&gt; &gt;&gt;&gt;&gt; doubtful I&#39;d see a hit.<br>
&gt; &gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt; Ok, and this is with the complete patchset applied correct?<br>
&gt; &gt;&gt;&gt; <br>
&gt; &gt;&gt;&gt; Btw, what device tree are you using? Ouya is not upstream as far as I<br>
&gt; &gt;&gt;&gt; can tell?<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; Indeed, I have the full patchset.<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; Ouya is an old android game console that I&#39;ve been working on getting<br>
&gt; &gt;&gt; mainline working on.<br>
&gt; &gt; <br>
&gt; &gt; I know, I have one sitting here too. I only tried to tinker a bit at the<br>
&gt; &gt; very beginning...<br>
&gt; <br>
&gt; It runs Xubuntu very well now with mainline.<br>
&gt; I&#39;ve got most everything roughly supported with the exception of audio.<br>
&gt; <br>
&gt; &gt;&gt; I&#39;ve written most of the device tree, with contributions from Matt<br>
&gt; &gt;&gt; Merhar.<br>
&gt; &gt;&gt; It&#39;s almost bit for bit a cardhu dev board, but with everything not<br>
&gt; &gt;&gt; necessary to function removed.<br>
&gt; &gt;&gt; They cut a lot of corners with the board design.<br>
&gt; &gt;&gt; Last stable kernel was 3.2, but it ran fine at 52mhz, mind you it<br>
&gt; &gt;&gt; reported it was running mode 5.<br>
&gt; &gt; <br>
&gt; &gt; That is what we saw too. With Apalis/Colibri T30 L4T downstream kernel<br>
&gt; &gt; (which is 3.1 with quite some patches) 52MHz DDR worked fine,<br>
&gt; &gt; surprisingly even with ACMD23. However, speed is slightly slower than<br>
&gt; &gt; mainline 52MHz without ACMD23...<br>
&gt; <br>
&gt; I noticed the same thing, speed with the original kernel on the MMC was<br>
&gt; worse at 52Mhz than it was at 34Mhz in HS-200 mode on mainline.<br>
&gt; I&#39;d be happy with it where it is, but the fact that it worked at 52Mhz<br>
&gt; before makes me believe something isn&#39;t quite there yet.<br>
&gt; I selected HS-200 mode just to force 1.8v mode.<br>
<br>
What&#39;s the card model your Ouya&#39;s eMMC has?<br>
<br>
<br>
<br>
<br>
</blockquote></div>
\
 
 \ /
  Last update: 2018-07-27 22:21    [W:0.069 / U:2.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site