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.120.41.1.3\))
Subject: Re: [PATCH] MIPS: DTS: CI20: Raise VDDCORE voltage to 1.125 volts
From:   "H. Nikolaus Schaller" <hns@goldelico.com>
In-Reply-To: <62577492be3665a9a4ba66077d13fa1bef5e6ee3.camel@crapouillou.net>
Date:   Fri, 23 Jun 2023 22:21:42 +0200
Cc:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>, linux-mips@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        list@opendingux.net
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3B433F7-08E1-4AF4-8853-C001FEEF9CA2@goldelico.com>
References: <20230622175934.71601-1-paul@crapouillou.net>
 <59F0E1F0-C518-48D8-8AB9-97CA143DD36E@goldelico.com>
 <62577492be3665a9a4ba66077d13fa1bef5e6ee3.camel@crapouillou.net>
To:     Paul Cercueil <paul@crapouillou.net>
Precedence: bulk

Hi Paul,

> Am 23.06.2023 um 18:31 schrieb Paul Cercueil <paul@crapouillou.net>:
>=20
> Hi Nikolaus,
>=20
> Le vendredi 23 juin 2023 =C3=A0 18:13 +0200, H. Nikolaus Schaller a =
=C3=A9crit :
>> Hi Paul, Thomas,
>> here are my test results.
>>=20
>>> Am 22.06.2023 um 19:59 schrieb Paul Cercueil
>>> <paul@crapouillou.net>:
>>>=20
>>> Commit 08384e80a70f ("MIPS: DTS: CI20: Fix ACT8600 regulator node
>>> names") caused the VDDCORE power supply (regulated by the ACT8600's
>>> DCDC1 output) to drop from a voltage of 1.2V configured by the
>>> bootloader, to the 1.1V set in the Device Tree.
>>>=20
>>> According to the documentation, the VDDCORE supply should be
>>> between
>>> 0.99V and 1.21V; both values are therefore within the supported
>>> range.
>>>=20
>>> However, VDDCORE being 1.1V results in the CI20 being very
>>> unstable,
>>> with corrupted memory, failures to boot, or reboots at random.
>>=20
>> ... and damaging the file system on SD card.
>>=20
>>> The
>>> reason might be succint drops of the voltage below the minimum
>>> required.
>>=20
>> 1. with your patches (except this one) on top of upstream v6.4-rc7
>> and
>> ci20_defconfig I can still not boot with 1.100V.
>>=20
>> 2. but also not at 1.125V as by this patch.
>> [    0.647637] DCDC1: Bringing 1200000uV into 1125000-1125000uV
>>=20
>> 3. my board needs 1.150V as minimum, reporting:
>> [    0.647627] DCDC1: Bringing 1200000uV into 1150000-1150000uV
>=20
> Heh. I was fearing this would be the case.
>=20
>>=20
>> That is good news that it does not need 1.200V at the upper limit.
>>=20
>> 4. next, with this setup I can see the bluetooth chip (with default
>> MAC
>> address 43:30:B1:00:00:00), but it is not useable (maybe my user
>> space).
>>=20
>> And there no WiFi. Rather, I have to disable the brcmfmac driver or
>> otherwise I can't even complete boot (hangs in a later stage) at all.
>=20
> Most likely it's because of an invalid firmware file. It happened to =
me
> with every single firmware file (including the one in the linux-
> firmware repository at that time) except the one found on the CI20's
> Debian image.
>=20
> Since then Broadcom guys updated the firmware in linux-firmware to the
> newest one they had, which works fine.

Well, I have used exactly the same /lib/firmware directory in both =
cases.
Even the same SD card... Nothing removed, replaced or changed with the
firmware file.

I.e. I have just swapped kernel, dtb and modules on the same SD card.

So the difference is inside one of these, not the firmware but I have =
not
yet searched for the detail...

>=20
>> 5. finally the mysterious result:
>>=20
>> With all this merged with the letux-os kernel (and manually fixing
>> minor
>> merge conflicts) and using letux_defconfig I can boot. Even with
>> 1.100V
>> in the device tree, checked with /sys/kernel/debug):
>>=20
>> root@letux:~# cat /sys/kernel/debug/regulator/regulator_summary=20
>>  regulator                      use open bypass  opmode voltage
>> current     min     max
>> ---------------------------------------------------------------------
>> ------------------
>>  regulator-dummy                  3    2      0 unknown     0mV   =20
>> 0mA     0mV     0mV=20
>>     13500000.usb-vusb_a           1                               =20
>> 0mA     0mV     0mV
>>     13500000.usb-vusb_d           1                               =20
>> 0mA     0mV     0mV
>>  eth0_power                       1    1      0 unknown  3300mV   =20
>> 0mA  3300mV  3300mV=20
>>     16000000.dm9000-vcc           1                               =20
>> 0mA     0mV     0mV
>>  otg_power                        1    2      0 unknown  5000mV   =20
>> 0mA  5000mV  5000mV=20
>>     1000003c.usb-phy-vcc          1                               =20
>> 0mA     0mV     0mV
>>     usb_phy-vcc                   0                               =20
>> 0mA     0mV     0mV
>>  vcc_33v                          8    9      0 unknown  3300mV   =20
>> 0mA  3300mV  3300mV=20
>>     13450000.mmc-vqmmc            1                               =20
>> 0mA     0mV     0mV
>>     13450000.mmc-vmmc             1                               =20
>> 0mA  3300mV  3400mV
>>     DCDC1                         1    0      0 standby  1100mV   =20
>> 0mA  1100mV  1100mV=20
>>     DCDC2                         1    0      0 standby  1500mV   =20
>> 0mA  1500mV  1500mV=20
>>     DCDC3                         1    0      0 unknown  3300mV   =20
>> 0mA  3300mV  3300mV=20
>>     LDO5                          1    0      0 unknown  2500mV   =20
>> 0mA  2500mV  2500mV=20
>>     LDO6                          1    1      0  normal  1800mV   =20
>> 0mA  1800mV  1800mV=20
>>        13460000.mmc-vqmmc         1                               =20
>> 0mA     0mV     0mV
>>     LDO7                          0    0      0 unknown  2800mV   =20
>> 0mA  2800mV  2800mV=20
>>     LDO8                          0    0      0 unknown  1500mV   =20
>> 0mA  1500mV  1500mV=20
>>  SUDCDC_REG4                      2    1      0  normal  5000mV   =20
>> 0mA  5000mV  5000mV=20
>>     bt_power                      2    1      0 unknown  3300mV   =20
>> 0mA  3300mV  3300mV=20
>>        wifi_power                 2    1      0 unknown  3300mV   =20
>> 0mA  3300mV  3300mV=20
>>           13460000.mmc-vmmc       1                               =20
>> 0mA  3300mV  3400mV
>>  LDO_REG9                         1    0      0 unknown  3300mV   =20
>> 0mA  3300mV  3300mV=20
>>  LDO_REG10                        1    0      0 unknown  1200mV   =20
>> 0mA  1200mV  1200mV=20
>> root@letux:~# uname -a
>> Linux letux 6.4.0-rc7-letux-ci20+ #13881 SMP PREEMPT Fri Jun 23
>> 17:23:42 CEST 2023 mips GNU/Linux
>> root@letux:~#=20
>>=20
>> And I there have WiFi working fine.
>>=20
>> But no Bluetooth interface at all (although driver is compiled).
>>=20
>> A potential hint could be that DCDC1 is enabled a little later during
>> boot than with ci20_defconfig:
>>=20
>> [    1.077926] DCDC1: Bringing 1200000uV into 1100000-1100000uV
>> [    1.096997] DCDC1: 1100 mV, enabled
>>=20
>> And another test with trying 1.000V hangs immediately after this:
>>=20
>> [    1.032846] DCDC1: Bringing 1200000uV into 1000000-1000000uV
>>=20
>> Maybe it is a too big step during operation.
>=20
> 1.0V is about as low as you can get with theorically perfect power
> supply, I doubt that you can use this voltage in the real world.

Indeed. There may be some more mV drop. I haven't tried 1.050V (yet).

>=20
> It's strange that your letux kernel can set 1.1V and be stable, while
> you need 1.15V with the upstream kernel. I wonder what could be the
> cause.

Yes, that is a mysterium...

>=20
>>=20
>> For the records:
>>=20
>> - I just swapped the clean compiled uImage, kernel modules and
>> ci20.dtb
>>   between all these tests (and fsck the SD card before).
>>=20
>> - we have some experimental SMP patches by Yanjie Zhou (and other
>> nice
>>   stuff not pushed upstream) in the Letux kernel so that any of thes
>>   may have an influence.
>>=20
>> So I'd say let's postpone this 1.125V patch until your other patches
>> arrive upstream. Then I will rebase our Letux kernel anyways and then
>> I can analyse a little easier what makes all these differences
>> (because
>> then no merge and manual conflict resolution is involved any more and
>> there are better chances for a bisect to be helpful).
>=20
> Thomas already merged it, so I guess we have 1.125V now.
>=20
> Which is better than nothing; instead of not working on both our
> boards, at least now v6.4 will work on one of them ;)

And it will not break LetuxOS if rebased. That is what we need for =
further
analysis.

>=20
> Note that I was testing my patches on top of the vanilla kernel,
> without any local patches.

I do the same but have a better result with adding my local patches.
So they must improve something even more (except than making Bluetooth =
worse)...
But I don't know what it is.

Something for future analysis.

BR and thanks for building a basis,
Nikolaus