Re: [PATCH 0/9] MIPS: CI20: Add WiFi / Bluetooth support
From: Paul Cercueil
Date: Sun Jun 18 2023 - 07:51:10 EST
Hi Nikolaus,
Le samedi 17 juin 2023 à 12:45 +0200, H. Nikolaus Schaller a écrit :
> Hi Paul,
>
> > Am 16.06.2023 um 22:21 schrieb H. Nikolaus Schaller
> > <hns@xxxxxxxxxxxxx>:
>
> > - But renaming the DT nodes (e.g. SUDCDC1 -> DCDC1) (with or
> > without regulator_name) makes
> > boot hang with strange errors which indicate that the processor
> > power supply is not stable.
> > Once a while it did even automatically reboot. In most cases there
> > are some EXT4 errors
> > afterwards.
>
> I am coming closer, I think. I have now touched only the DCDC1 node
> name.
>
> a) with "SUDCDC1" -> "DCDC1" (bad bood):
>
> regulator_of_get_init_node() returns the child node
>
> Then:
> [ 0.666962] act8865 0-005a: Looking up vp1-supply from device tree
> [ 0.673191] DCDC1: supplied by vcc_33v
> [ 0.727070] DCDC1: Bringing 1200000uV into 1100000-1100000uV
> [ 0.739398] DCDC1: 1100 mV, enabled
>
> b) without patch/series or reverted (good boot):
>
> regulator_of_get_init_node() returns NULL
>
> Then:
> [ 1.016487] DCDC1: at 1200 mV, enabled
> [ 1.020578] act8865 0-005a: Looking up vp1-supply from device tree
> [ 1.026917] DCDC1: supplied by vcc_33v
>
> So at least for my board the patched series seems to reduce DCDC1
> voltage
> to 1.1V which may trigger the boot and stability problems on my board
> while
> it is fine for yours. This could explain the hardware dependency.
>
> Now I have no data sheets or information which voltages are the right
> ones
> and where the 1200mV come from (most likely some default programmed
> into the PMU chip).
>
> And the issue seems to be that without matching the node names the
> voltages in the device tree may have been ignored completely all the
> time... Now it sets up voltages, which should happen. But different
> ones for my board which breaks boot.
So the node names fix caused the driver to actually use the info from
DT, which doesn't allow the board to boot. Nice.
> Finally I did risk (I have no replacement CI20 board and they are no
> longer
> on sale... RS part# was 125-3305 Mouser 456-VL-62851) to run a test
> with
> rename to "DCDC1" but changing the voltage to 1200mV. And this
> version boots.
Looking at the JZ4780_DS.PDF file, the SoC actually wants 1.1V so the
DT is not wrong - in theory. But in practice it does not work, as you
experienced yourself. However, if the ACT8600 defaults to 1.2V, or if
the bootloader configures it to 1.2V, I would think that this is
actually a voltage that the SoC can handle - otherwise the SoC would be
overvolted until the kernel starts, and the board design would be
flawed.
I measured that the old 3.x kernel keeps the SoC voltage at 1.2V, so it
sounds like a better default. Therefore the fix here would be to raise
the DCDC1 regulator to 1.2V.
I'll send a patch later today.
Cheers,
-Paul
> Still without WiFi/Bluetooth but that may be related to missing
> rename
> of the other regulators.
>
> So I tried renaming all regulators as by your [PATCH 2/9], and now I
> see something from WiFi (haven't installed firmware yet) and the
> Bluetooth chip:
>
> [ 1.977876] mmc1: new high speed SDIO card at address 0001
>
> [ 11.341994] Bluetooth: hci0: BCM: chip id 62
> [ 11.348811] Bluetooth: hci0: BCM: features 0x0f
> [ 11.376698] Bluetooth: hci0: BCM4330B1
> [ 11.380662] Bluetooth: hci0: BCM4330B1 (002.001.003) build 0000
> [ 11.392053] Bluetooth: hci0: BCM4330B1 'brcm/BCM4330B1.hcd' Patch
>
> [ 12.145330] brcmfmac mmc1:0001:1: Direct firmware load for
> brcm/brcmfmac4330-sdio.img,ci20.bin failed with error -2
> [ 12.208001] brcmfmac mmc1:0001:1: Direct firmware load for
> brcm/brcmfmac4330-sdio.clm_blob failed with error -2
>
> Unfortunatley systemd bailed out starting Bluetooth service but
> failed to provide a login:
>
> In summary it looks like a potential fix could be to replace the
> DCDC1
> min/max range by 1.0 - 1.2V instead of 1.1 - 1.1V but we need deeper
> understanding first. Usually this has something to do with dynamic
> voltage
> scaling depending on processor clock and lower voltages are only
> allowed
> for lower frequencies but max. clock requires the highest possible
> voltage.
> AFAIK we have no cpufreq integrated and therefore always run at max.
> speed.
>
> BR,
> Nikolaus
>
> PS: here is what I read back from the regulator voltages (for DCDC1
> min/max = 1.2V):
>
> root@letux:~# cat /sys/kernel/debug/regulator/regulator_summary
> regulator use open bypass opmode voltage
> current min max
> ---------------------------------------------------------------------
> ------------------
> regulator-dummy 1 0 0 unknown 0mV
> 0mA 0mV 0mV
> eth0_power 1 1 0 unknown 3300mV
> 0mA 3300mV 3300mV
> 16000000.dm9000-vcc 1
> 0mA 0mV 0mV
> otg_power 0 0 0 unknown 5000mV
> 0mA 5000mV 5000mV
> vcc_33v 4 9 0 unknown 3300mV
> 0mA 3300mV 3300mV
> 13450000.mmc-vqmmc 1
> 0mA 0mV 0mV
> 13450000.mmc-vmmc 1
> 0mA 3300mV 3400mV
> DCDC1 1 0 0 standby 1200mV
> 0mA 1200mV 1200mV
> DCDC2 0 0 0 standby 1500mV
> 0mA 0mV 0mV
> DCDC3 0 0 0 unknown 3300mV
> 0mA 0mV 0mV
> LDO5 0 0 0 unknown 2500mV
> 0mA 0mV 0mV
> LDO6 0 0 0 normal 1800mV
> 0mA 1800mV 1800mV
> LDO7 0 0 0 unknown 3300mV
> 0mA 0mV 0mV
> LDO8 0 0 0 unknown 3300mV
> 0mA 0mV 0mV
> SUDCDC_REG4 0 0 0 normal 5000mV
> 0mA 0mV 0mV
> LDO_REG9 1 0 0 unknown 3300mV
> 0mA 3300mV 3300mV
> LDO_REG10 1 0 0 unknown 1200mV
> 0mA 1200mV 1200mV
> bt_power 0 0 0 unknown 3300mV
> 0mA 3300mV 3300mV
> root@letux:~#
>
> This matches device tree except DCDC1, LDO7 and LDO8 (camera).
>