From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B117BC433E7 for ; Tue, 13 Oct 2020 21:24:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4D2FE21582 for ; Tue, 13 Oct 2020 21:24:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EM7psXP9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D2FE21582 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=siol.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uuTYrKoF1dzfvxf7M/eFH+GAmWE01TqWgKwG9ZL/I6U=; b=EM7psXP9dvkEVspeApGX+KCj9 yf8P4mao5g/RFRRSbCLbUuXjy7cPTB+IAlCfWW5jIjkgls4cJeCMOs0GHi8CxYN/wMUwL/JIK1+Zb jmOB2jShMNxu4K81IbSr34x9N3ZrU2r2/zFVnL/jwLimz/fuK8vT/UmX640TKakDMZej9oskDYNzD dXYCflzrbTzu16O9NZ/YjzFZYfyBBIXFSFsFH8ph5XGsA0D6aPpCTQcQHNqRUndoZ0IllMckgMd89 GobU6hiszMcNdTmttyUC2HHm6WVjJGSgk3Uy9CW1IhdSNW9cvprQyppe3Uu+YZjdLtSVJ0VrII0Lg LjdYtuyUA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSRkY-00077E-Gw; Tue, 13 Oct 2020 21:22:26 +0000 Received: from mailoutvs47.siol.net ([185.57.226.238] helo=mail.siol.net) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSRkU-00076m-VM for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 21:22:24 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.siol.net (Postfix) with ESMTP id CF05C526150; Tue, 13 Oct 2020 23:22:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at psrvmta11.zcs-production.pri Received: from mail.siol.net ([127.0.0.1]) by localhost (psrvmta11.zcs-production.pri [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id prebWZDhw8fy; Tue, 13 Oct 2020 23:22:18 +0200 (CEST) Received: from mail.siol.net (localhost [127.0.0.1]) by mail.siol.net (Postfix) with ESMTPS id EABF2526102; Tue, 13 Oct 2020 23:22:17 +0200 (CEST) Received: from kista.localnet (cpe1-5-97.cable.triera.net [213.161.5.97]) (Authenticated sender: jernej.skrabec@siol.net) by mail.siol.net (Postfix) with ESMTPA id 2179552615A; Tue, 13 Oct 2020 23:22:16 +0200 (CEST) From: Jernej =?utf-8?B?xaBrcmFiZWM=?= To: =?ISO-8859-1?Q?Cl=E9ment_P=E9ron?= , Maxime Ripard Subject: Re: Re: [PATCH v2] arm64: dts: allwinner: h6: add eMMC voltage property for Beelink GS1 Date: Tue, 13 Oct 2020 23:27:33 +0200 Message-ID: <2745255.UFgyrzHpml@kista> In-Reply-To: <20201009073651.izvvjpqiqiivhknl@gilmour.lan> References: <20201003092001.405238-1-peron.clem@gmail.com> <20201009073651.izvvjpqiqiivhknl@gilmour.lan> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201013_172223_131046_ABBC1882 X-CRM114-Status: GOOD ( 43.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree , Chen-Yu Tsai , linux-kernel , linux-sunxi , Rob Herring , linux-arm-kernel Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Dne petek, 09. oktober 2020 ob 09:36:51 CEST je Maxime Ripard napisal(a): > On Thu, Oct 08, 2020 at 10:00:06PM +0200, Cl=E9ment P=E9ron wrote: > > Hi Maxime, > > = > > Adding linux-sunxi and Jernej Skrabec to this discussion. > > = > > On Thu, 8 Oct 2020 at 17:10, Maxime Ripard wrote: > > > > > > Hi Cl=E9ment, > > > > > > On Mon, Oct 05, 2020 at 08:47:19PM +0200, Cl=E9ment P=E9ron wrote: > > > > On Mon, 5 Oct 2020 at 11:21, Maxime Ripard wrot= e: > > > > > > > > > > Hi Cl=E9ment, > > > > > > > > > > On Sat, Oct 03, 2020 at 11:20:01AM +0200, Cl=E9ment P=E9ron wrote: > > > > > > Sunxi MMC driver can't distinguish at runtime what's the I/O = voltage > > > > > > for HS200 mode. > > > > > > > > > > Unfortunately, that's not true (or at least, that's not related t= o = your patch). > > > > > > > > > > > Add a property in the device-tree to notify MMC core about this > > > > > > configuration. > > > > > > > > > > > > Fixes: 089bee8dd119 ("arm64: dts: allwinner: h6: Introduce Beel= ink = GS1 board") > > > > > > Signed-off-by: Cl=E9ment P=E9ron > > > > > > --- > > > > > > arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 + > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink- gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts > > > > > > index 049c21718846..3f20d2c9bbbb 100644 > > > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts > > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts > > > > > > @@ -145,6 +145,7 @@ &mmc2 { > > > > > > vqmmc-supply =3D <®_bldo2>; > > > > > > non-removable; > > > > > > cap-mmc-hw-reset; > > > > > > + mmc-hs200-1_8v; > > > > > > bus-width =3D <8>; > > > > > > status =3D "okay"; > > > > > > }; > > > > > > > > > > I'm not really sure what you're trying to fix here, but as far as= MMC > > > > > goes, eMMC's can support io voltage of 3.3, 1.8 and 1.2V. Modes u= p = until > > > > > HS DDR (50MHz in DDR) will use an IO voltage of 3.3V, higher spee= d = modes > > > > > (HS200 and HS400) supporting 1.8V and 1.2V. > > > > > > > > Some users report that the eMMC is not working properly on their > > > > Beelink GS1 boards. > > > > > > > > > The mmc-hs200-1_8v property states that the MMC controller suppor= ts = the > > > > > HS200 mode at 1.8V. Now, I can only assume that since BLDO2 is se= t = up at > > > > > 1.8V then otherwise, the MMC core will rightfully decide to use t= he > > > > > highest supported mode. In this case, since the driver sets it, i= t = would > > > > > be HS-DDR at 3.3V, which won't work with that fixed regulator. > > > > > > > > > > I can only assume that enabling HS200 at 1.8V only fixes the issu= e = you > > > > > have because otherwise it would use HS-DDR at 3.3V, ie not actual= ly > > > > > fixing the issue but sweeping it under the rug. > > > > > > > > > > Trying to add mmc-ddr-1_8v would be a good idea > > > > > > > > Thanks for the explanation, this is indeed the correct one. > > > > So It looks like the SDIO controller has an issue on some boards wh= en > > > > using HS-DDR mode. > > > > > > > > Is this patch acceptable with the proper commit log? > > > > > > If HS-DDR works, yes, but I assume it doesn't? > > = > > After discussing with Jernej about this issue, I understood that: > > - Automatic delay calibration is not implemented > > - We also miss some handling of DDR related bits in control register > > = > > So none of H5/H6 boards should actually work. > > (Some 'lucky' boards seem to work enough to switch to HS200 mode...) > > = > > To "fix" this the H5 disable the HS-DDR mode in sunxi mmc driver : > > https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sunxi-mm= c.c#L1409 > = > I find it suspicious that some boards would have traces not good enough > for HS-DDR (50MHz in DDR) but would work fine in HS200 (200MHz in SDR). > If there's some mismatch on the traces, it will only be worse in HS200. FYI, similar situation is also with Tanix TX6 board. Mine works well in HS-= DDR = mode, but some people reported that it doesn't work for them. The only = possible difference could be different eMMC IC. I'll try to confirm that. Anyway, I did some tests on OrangePi 3 board which also have eMMC. Both mod= es = (HS-DDR and HS200) are supported and work well. Interesting observation is = that speed test (hdparm -t) reported 80.58 MB/sec for HS-DDR mode and 43.40 = MB/sec for HS200. As it can be seen here, HS-DDR is quicker by a factor of = 2, = but it should be the other way around. Reason for this is that both modes u= se = same base clock and thus HS-DDR produces higher speed. If I change f_max to 150 MHz (max. per datasheet for SDR @ 1.8 V) then = naturally HS200 mode is faster (124.63 MB/sec) as HS-DDR as it should be. T= his = would be actually correct test for problematic boards but unfortunately I = don't have it. I also hacked in support for HS400 (~143 MB/s) and this mode= is = the only one which really needs calibration on my board. = Two observations from BSP driver: 1. Module clock is disabled before adjusting DDR bit and afterwards it's re- enabled . That could fix some kind of glitches. 2. SDMMC peripheral runs on higher clock than on mainline. > = > And for the delay calibration, iirc, that's only necessary for HS400 > that we don't support? According to BSP driver and its DT, HS200 also needs calibration. However, = it = seems that using it on lower speed it isn't needed. Best regards, Jernej > = > > I'm not sure about A64 but it looks like the property "mmc-hs200-1_8v" > > for the PineBook shows the same issue. > > = > > The proper way would of course be to implement the missing feature > > mentioned above. > > But this could take some time and as the eMMC driver is actually > > broken wouldn't it be better to disable the HS-DDR for H6 in the mmc > > driver like it's done for H5 ? > = > Have you tested with only the mmc-ddr-1_8v property? > = > Maxime > = _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel