Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 3/3] mmc: tegra: prevent ACMD23 on Tegra 3
To:     Stefan Agner <stefan@agner.ch>
Cc:     adrian.hunter@intel.com, ulf.hansson@linaro.org,
        thierry.reding@gmail.com, jonathanh@nvidia.com,
        marcel.ziswiler@toradex.com, linux-mmc@vger.kernel.org,
        linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-tegra-owner@vger.kernel.org
References: <20180712073904.4705-1-stefan@agner.ch>
 <20180712073904.4705-3-stefan@agner.ch>
 <430c718d-9ede-d47a-44c0-b8e47e297720@gmail.com>
 <1553c44e99b96a813af129d1c4169222@agner.ch>
 <553f9ed6-8f7c-775b-d731-fd9732f74b07@gmail.com>
 <7edc8c666dbbc0743221c86286ff583a@agner.ch>
 <12ae1da9-cd09-b15d-9a81-461ca9cc06d7@gmail.com>
 <24fffc2c52b58301c37d95fe5d1ad355@agner.ch>
From:   Peter Geis <pgwipeout@gmail.com>
Message-ID: <3a970d5d-4f18-0167-ab22-2032e8bf743d@gmail.com>
Date:   Thu, 26 Jul 2018 13:48:55 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <24fffc2c52b58301c37d95fe5d1ad355@agner.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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