Re: [PATCH 3/3] mmc: tegra: prevent ACMD23 on Tegra 3

[Peter Geis]

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@xxxxxxxxxxxxxxx
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html