Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: [PATCH v4] arm64: dts: rockchip: Fix SD card init on
 rk3399-nanopi4
From:   =?utf-8?Q?Christian_Kohlsch=C3=BCtter?= 
        <christian@kohlschutter.com>
In-Reply-To: <daf3b61c-d886-98eb-0443-de233d742041@arm.com>
Date:   Sat, 16 Jul 2022 00:33:28 +0200
Cc:     wens@kernel.org, =?utf-8?Q?Heiko_St=C3=BCbner?= <heiko@sntech.de>,
        Markus Reichl <m.reichl@fivetechno.de>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Linux MMC List <linux-mmc@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDF716FC-F6CF-44A9-84D9-B48C46E6AC2C@kohlschutter.com>
References: <C639AD88-77A1-4485-BAEA-2FF8FC15A844@kohlschutter.com>
 <12878108.O9o76ZdvQC@diego> <103b714c-b07c-f016-1062-84bd94786b22@arm.com>
 <9AF1E75F-5947-49B0-887D-82C426527B99@kohlschutter.com>
 <590f7a08-a6ca-be54-4254-363343642a52@arm.com>
 <A6B896E5-CD25-4441-B6A5-0BE1FA284B2C@kohlschutter.com>
 <A9634366-A012-43D2-B253-8BB9BF6005C7@kohlschutter.com>
 <CAGb2v65Ehbu1wrib2CzF1fDZuD3fHZQDhKfVusyUF9KnxTvi+Q@mail.gmail.com>
 <5ca9bd94-54d9-04f8-0098-a56ffb6f5fe1@arm.com>
 <502b3fbe-3077-407e-6010-a8cb3ffce7d6@arm.com>
 <449292CA-CE60-4B90-90F7-295FBFEAB3F8@kohlschutter.com>
 <73F9AED0-D2A8-4294-B6E1-1B92D2A36529@kohlschutter.com>
 <115AD6A4-021B-4879-BFB5-BC7689A0203E@kohlschutter.com>
 <17a4c6f6-d79c-a7b2-860f-e5944b778f9f@arm.com>
 <9405b97a-6758-ad4e-ccff-eed072096539@arm.com>
 <BF7CC548-88C9-4889-8A41-8E99C31EF81C@kohlschutter.com>
 <daf3b61c-d886-98eb-0443-de233d742041@arm.com>
To:     Robin Murphy <robin.murphy@arm.com>
Precedence: bulk

> Am 15.07.2022 um 21:38 schrieb Robin Murphy <robin.murphy@arm.com>:
>=20
> On 2022-07-15 20:04, Christian Kohlsch=C3=BCtter wrote:
>> Am 15.07.2022 um 20:57 schrieb Robin Murphy <robin.murphy@arm.com>:
>>>=20
>>> On 2022-07-15 19:11, Robin Murphy wrote:
>>>> On 2022-07-15 18:16, Christian Kohlsch=C3=BCtter wrote:
>>>>> OK, this took me a while to figure out.
>>>>>=20
>>>>> When no undervoltage limit is configured, I can reliably trigger =
the initialization bug upon boot.
>>>>> When the limit is set to 3.0V, it rarely occurs, but just after I =
send the v3 patch, I was able to reproduce...
>>>> Well this has to be in the running for "weirdest placebo ever"... =
:/
>>>> All it actually seems to achieve is printing an error[1] (this is =
after all a tiny 5-pin fixed-voltage LDO regulator, not an intelligent =
PMIC), and if that makes an appreciable difference then there has to be =
some kind of weird timing condition at play. Maybe regulator_register() =
ends up turning it off and on again rapidly enough that the card sees a =
voltage brownout and glitches, and adding more delay by printing to the =
console somewhere in the middle gives it enough time to act as a proper =
power cycle with no ill effect?
>>>=20
>>> ...and apparently the answer is yes, it seems to be doing exactly =
that (see attached). But seemingly my SD cards don't mind, or maybe my =
T4 board happens to have more capacitance than Christian's R4S so my =
voltage dip isn't as bad, or both.
>>>=20
>>> So it seems like the solution here might indeed simply be to remove =
the regulator-always-on which doesn't seem to have any reason to be here =
anyway. Without that, the enable stays low until the MMC driver probes =
and claims it, which is then massively longer than the time it takes for =
VCC3V0_SD to ramp down completely.
>>>=20
>>> Robin.
>> Removing "regulator-always-on" has the effect that the system freezes =
upon reboot.
>=20
> Ah, right (can we fast-forward to a world where everyone has a =
reliable bootloader in SPI flash or similar?). Is that more glitching, =
or a firmware bug not resetting the GPIOs to their default state on warm =
reset, I wonder.
>=20
>> There may well be another bug slumbering in the codebase that is =
circumvented by 1. adding a delay in the code and 2. not turning the =
regulator off upon shutdown.
>=20
> Yes, it seems suboptimal that the regulator core allows this glitch =
where an always-on regulator which is already on gets turned off at all, =
but I guess that's its own problem. In the meantime, off-on-delay-us =
sounds like the most likely property to bandage this locally. I'm seeing =
a fall time in the order of milliseconds (attached), so we'd probably =
want a fair chunk of that to be safe.
>=20
> Robin.<SDS00003.png>

I think we have a way where there's no need to pick a delay value that =
may ultimately not work in all cases.
Following up with "[PATCH] regulator: core: Resolve supply name earlier =
to prevent double-init" [1]

Thank you so much for helping me getting that far! It would be great if =
you'd keep following the thread.

Best,
Christian

[1] https://www.spinics.net/lists/kernel/msg4440365.html