Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1225943imm; Fri, 27 Jul 2018 13:22:15 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfNZo3lhKd+Uj5YiM0nDsnHvCpuEEqHEZfpvdw36XRONPaL9HzW9FFq9sBL23siqD3FM1kp X-Received: by 2002:a63:4924:: with SMTP id w36-v6mr7433297pga.143.1532722935245; Fri, 27 Jul 2018 13:22:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532722935; cv=none; d=google.com; s=arc-20160816; b=EnVdQ93vlDK6DPMWvvtDNevlZx8SmOFsXgIpD0REn/vwdcN59ZzMRHBHXfO/jFI/oh 2jmvMONHd/wIkz3GcsoLdo0uANj5BdrR+K/3Kl83KYvlP2v6oXlfzZxktF2eNkb34o02 Rzwhjomw0z6YzPdqgFuWeuOC+hKEgoJf0RG+Ettn4gRT55FRKhqSf0nrAOjxYteiuz45 9xBFN/fxfbozbAx//altWGsjeMFrylg5D2RRPw1jo89sFoNMmDhULWFounGC1tkoSt5f l2fiwKiDdQDRBN81U9MGRi17yPT8tKFzJd3aNjwwauEyTnxDFgXY/cxuAs2Z/viGMBYw zTsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=WA2wuii8ERkYYtSrFZlNxrgYl3XKpEmGyGLVGfkkU4A=; b=RII1PmeqIP0b2NNrQVrqGlD+fU8zJIghmgPwTptkplhLCbWWHI065UZViwQrlKTDCa xHmqU0JjIUl/B2M4tfX8il9nWth2/Fuv+SfL6/AJxLQer4I2+YHPDsiUYxTJ9f2nOewc OZEDD45AFYfhQpynirBMurTngOY0en4K4OGo5grdO2N2KExEqGA2BkLslk94lzclg+RB wle6IyvE6TyE1AO72GvzW/I8j+kJUzK1MtilC7Fl/YzoPSwreJOwaO/MhuuUkqMAUybD s8wY1KEDME12RXFzbLEwlQ4vw77ecpL6llJYCuBE+NHRX1GbnWRCbaO9GUh1oMI7pAdD XdHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cK7+gJ9E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d1-v6si4168320pld.515.2018.07.27.13.22.00; Fri, 27 Jul 2018 13:22:15 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cK7+gJ9E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389613AbeG0VoB (ORCPT + 99 others); Fri, 27 Jul 2018 17:44:01 -0400 Received: from mail-qt0-f194.google.com ([209.85.216.194]:38379 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389392AbeG0VoB (ORCPT ); Fri, 27 Jul 2018 17:44:01 -0400 Received: by mail-qt0-f194.google.com with SMTP id y19-v6so6357045qto.5; Fri, 27 Jul 2018 13:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WA2wuii8ERkYYtSrFZlNxrgYl3XKpEmGyGLVGfkkU4A=; b=cK7+gJ9Eo2JHxezzxuHzo+T8jOHM4tyPc/V4faCoOQS584UCJGBk+ymHQDru7OGFUj ejyohkhRQmIS9GAUO8bVDXEllx7pjBaxsBnbVLdq7rc61bGXsME7a9QWmAW6ZangaFC9 gdBvz0sj7P1W411yjIH6SNs7JWoQILt4u0dR3OeOtcdf5hMT+ng4fUY64d4anHtwyeiP 41pS4sokSO1kUui+MTLXpj13EkgVFE08rTPGGrlmggKsra1zlUOB4vt3HRHZZIvmzF5G acFECNRYz6GB52Lk2sIqEPuGC8i5WYTOD5jDdhayL+SHE9hI9GvAIGTQPDkRxfRVHmIX jQFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WA2wuii8ERkYYtSrFZlNxrgYl3XKpEmGyGLVGfkkU4A=; b=H3De6Mj3z7udbN4nOKTH6CY/H9hkBVKwRl6ZHhfBiuHlZPinp59oNpXzZFgU+F3Pmd DK3qYAwvlRdgrMzGu8YoUekI4KkI+ec2fb57M0q2t/Umw5K/42U9xV7zaeZVcmToB3Y7 QFd8MA+vRnW/Y29PgZGSqaLuEyQYlxKJ71m0GKmY+oQgJDuZkQPfcYJSgSexFb/gUzZw ldGHq/6pmwbfIxWvqLWmbsxZEQB3KFqOWqGo1pQ1O1sV6JKdJ05ch8+6FSQYRFw7Cv6A zhz94Q3fARhtTFC8qXZT9U9oJcv85SzhMinn2YdGFD9J5CZObsddxq0q69lB/wyaU9Kw X0aQ== X-Gm-Message-State: AOUpUlGTu7dUhejMu7PZor0ddkfjkVZqSOBtVYfuk7YbR3UfpCpbZpk9 ez0vgdpOAREylSZKnloS31qH0GM1k2pJyKAMgVg= X-Received: by 2002:aed:21ac:: with SMTP id l41-v6mr7811159qtc.293.1532722830867; Fri, 27 Jul 2018 13:20:30 -0700 (PDT) MIME-Version: 1.0 References: <20180712073904.4705-1-stefan@agner.ch> <24fffc2c52b58301c37d95fe5d1ad355@agner.ch> <3a970d5d-4f18-0167-ab22-2032e8bf743d@gmail.com> <4098188.Bd2NGYzoJE@dimapc> In-Reply-To: <4098188.Bd2NGYzoJE@dimapc> From: Peter Geis Date: Fri, 27 Jul 2018 16:19:53 -0400 Message-ID: Subject: Re: [PATCH 3/3] mmc: tegra: prevent ACMD23 on Tegra 3 To: Dmitry Osipenko Cc: Stefan Agner , Adrian Hunter , 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 Content-Type: multipart/alternative; boundary="000000000000df8132057200d7f2" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --000000000000df8132057200d7f2 Content-Type: text/plain; charset="UTF-8" Kingston KE4CN3K6A. Though I am pretty sure I've figured out the instability. Brought it in to work and hooked it to a scope. Couldn't find clock, but cmd and all eight bits are running at 1.2 volts. Repeated the results with the bootloader, the original kernel, and my mainline. Also noticed that even on the slowest slew rate there is significant ringing and overshoot of .15 volts. On Fri, Jul 27, 2018, 15:52 Dmitry Osipenko wrote: > On Thursday, 26 July 2018 20:48:55 MSK Peter Geis wrote: > > 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. > > What's the card model your Ouya's eMMC has? > > > > > --000000000000df8132057200d7f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kingston=C2=A0KE4CN3K6A.
Though I am pretty sure I've figured ou= t the instability.
Brough= t it in to work and hooked it to a scope.
Couldn't find clock, but cmd and all eight bits are ru= nning at 1.2 volts.
Repea= ted the results with the bootloader, the original kernel, and my mainline.<= /span>
Also noticed that even on= the slowest slew rate there is significant ringing and overshoot of .15 vo= lts.


On Fri, Jul 27, 2018, 15:52 D= mitry Osipenko <digetx@gmail.com= > wrote:
On Thursday, 26 July 20= 18 20:48:55 MSK Peter Geis wrote:
> 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 O= uya (Tegra 3).
> >>>>>
> >>>>> Thanks for testing!
> >>>>>
> >>>>>> I found that the "Got command interrupt = 0x00010000 even though no
> >>>>>> command operation was in progress." erro= r occurred when the interface
> >>>>>> is unstable.
> >>>>>> I've had a lot of problems with sdmmc4 st= ability on the Ouya above 34
> >>>>>> Mhz, probably due to the fact that they are u= sing 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 u= nder 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 err= ors 87 or 110.
> >>>
> >>> What mode are you running at actually? E.g. what is the i= os file saying?
> >>> cat /sys/kernel/debug/mmcX/ios
> >>
> >> This is the best functionality I've been able to get prio= r to the
> >> patches:
> >> root@ouya:~# cat /sys/kernel/debug/mmc0/ios
> >> clock:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 30000000 Hz
> >> actual clock:=C2=A0 =C2=A029142858 Hz
> >> vdd:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21 (3.3 ~ 3.4 V= )
> >> bus mode:=C2=A0 =C2=A0 =C2=A0 =C2=A02 (push-pull)
> >> chip select:=C2=A0 =C2=A0 0 (don't care)
> >> power mode:=C2=A0 =C2=A0 =C2=A02 (on)
> >> bus width:=C2=A0 =C2=A0 =C2=A0 3 (8 bits)
> >> timing spec:=C2=A0 =C2=A0 9 (mmc HS200)
> >> signal voltage: 1 (1.80 V)
> >> driver type:=C2=A0 =C2=A0 0 (driver type B)
> >
> > Yeah HS200 is definilty not supported by the controller and reall= y
> > should not be used.
> >
> >> Now I am trying DDR, but even with the patches I'm not ab= le 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 th= at
> > 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 als= o 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 ar= e helpful?
> >>> https://lkml.org/lkml/2018/7/22/165<= /a>
> >>>
> >>> Also make sure to have a complete pinmux such that altern= ative pins for
> >>> sdmmc4 are *not* muxed as sdmmc4.
> >>
> >> That was my first issue, which was preventing sdmmc4 from wor= king at all.
> >> Just double checked all of the spare function pins, they are = all
> >> assigned elsewhere.
> >
> > Ok.
> >
> >>>>>> Lowering down to 32Mhz, without the patch the= re are no errors.
> >>>>>
> >>>>> So the patch does not make it less stable right?<= br> > >>>>
> >>>> 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 cont= roller, so it is
> >>>> doubtful I'd see a hit.
> >>>
> >>> Ok, and this is with the complete patchset applied correc= t?
> >>>
> >>> 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 workin= g 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 a= udio.
>
> >> 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 ever= ything 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 yo= u it
> >> reported it was running mode 5.
> >
> > That is what we saw too. With Apalis/Colibri T30 L4T downstream k= ernel
> > (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 wa= s
> 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 5= 2Mhz
> before makes me believe something isn't quite there yet.
> I selected HS-200 mode just to force 1.8v mode.

What's the card model your Ouya's eMMC has?




--000000000000df8132057200d7f2--