Re: [PATCH 3/3] ARM: dts: amlogic: Add TCU Fernsehfee 3.0

[J. Neuschäfer]

On Sun, Apr 06, 2025 at 10:36:18PM +0200, Martin Blumenstingl wrote:
> On Tue, Apr 1, 2025 at 3:00 PM J. Neuschäfer <j.ne@xxxxxxxxxx> wrote:
> >
> > On Sun, Mar 30, 2025 at 11:10:28PM +0200, Martin Blumenstingl wrote:
> > > Thanks for your patch!
> > >
> > > On Sun, Mar 23, 2025 at 1:38 PM J. Neuschäfer via B4 Relay
> > > <devnull+j.ne.posteo.net@xxxxxxxxxx> wrote:
> > > [...]
> > > > +               eth_phy0: ethernet-phy@0 {
> > > > +                       /* IC Plus IP101A (0x02430c54) */
> > > > +                       reg = <0>;
> > > Does reg = <1> also work on your board?
> > > 0 is the broadcast address. It's unfortunately something that we still
> > > have incorrect in a lot of .dts files.
> >
> > Unfortunately not. I tried addresses 1 to 31 without success, which
> > seems strange; my guess was that the PHY should respond to one of them.
> > I get this error:
> >
> > # ip l set eth0 up
> > [    6.806847] meson6-dwmac c9410000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > [    6.810609] meson6-dwmac c9410000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> Thanks for testing. Let's keep it at zero then.
> 
> > >
> > > [...]
> > > > +&i2c_AO {
> > > > +       status = "okay";
> > > > +       pinctrl-0 = <&i2c_ao_pins>;
> > > > +       pinctrl-names = "default";
> > > > +
> > > > +       pmic@32 {
> > > > +               compatible = "ricoh,rn5t618";
> > > > +               reg = <0x32>;
> > > > +               system-power-controller;
> > > Here I'm a bit surprised:
> > > Aren't some of the outputs used to drive VCCK (CPU power rail) and
> > > VDDEE (everything else power rail, which also powers the GPU)?
> >
> > Unfortunately I don't have schematics and I wasn't able to trace the
> > connections on the board because they're so tiny. So it's quite possible that
> > you're right, but I can't be sure.
> >
> > Are there voltage sensors in the Meson8 SoC that I could use to establishs the
> > relation between PMIC outputs and SoC supplies?
>
> There aren't any sensors (that I'm aware of). But you can check
> /sys/kernel/debug/regulator/regulator_summary and compare the values
> with the ones from arch/arm/boot/dts/amlogic/meson8m2-mxiii-plus.dts
> Also the vendor u-boot and kernel logs may provide some information.

The values in /sys/kernel/debug/regulator/regulator_summary do indeed
match the values in meson8m2-mxiii-plus.dts:

 DCDC1                            0    0      0 unknown  1100mV     0mA     0mV     0mV
 DCDC2                            0    0      0 unknown  1150mV     0mA     0mV     0mV
 DCDC3                            0    0      0 unknown  1500mV     0mA     0mV     0mV
 LDO1                             0    0      0 unknown  2900mV     0mA     0mV     0mV
 LDO2                             0    0      0 unknown  1800mV     0mA     0mV     0mV
 LDO3                             0    0      0 unknown  1800mV     0mA     0mV     0mV
 LDO4                             0    0      0 unknown  2850mV     0mA     0mV     0mV
 LDO5                             0    0      0 unknown  1800mV     0mA     0mV     0mV
 LDORTC1                          0    0      0 unknown  2700mV     0mA     0mV     0mV
 LDORTC2                          0    0      0 unknown   900mV     0mA     0mV     0mV

After I copy the regulator table from meson8m2-mxiii-plus.dts, I can indeed
observe the effect of regulators being on/off. I will use that to further
investigate how the regulators are used.

The vendor u-boot/kernel aren't very useful, unfortunately.
The downstream devicetree includes these settings:

	rn5t618 {
		status = "okay";
		ddr_voltage   = <1500000>; // 1.5V
		vddao_voltage = <1200000>; // 1.2V
		[...]
	};

The corresponding driver seems to associate ddr_voltage with DCDC2 and
vddio_voltage with DCDC3, although this part of the code[1] is "#if 0"'d.

[1] https://github.com/endlessm/linux-meson/blob/master/drivers/amlogic/power/ricoh/ricoh_pmu.c#L127


Best regards,
J. Neuschäfer