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

["J. Neuschäfer" <j.ne@posteo.net>]

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@kernel.org> 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)


> 
> [...]
> > +&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?

> 
> [...]
> > +&usb1 {
> > +       status = "okay";
> > +       dr_mode = "host";
> > +       /*
> > +        * This bus features a Realtek RTL8188 2.4GHz WiFi module, with a
> > +        * 3.3V supply voltage that must be enabled before use.
> > +        */
> > +       vbus-supply = <&wifi_3v3>;
> If you want to go for perfection then you can use
> Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml as
> reference.
> It's also an "onboard" USB device which requires toggling a GPIO and regulators.
> The driver side is super easy to manage as it's generic (meaning: it
> parses any GPIO and regulator as long as the USB ID is registered):
> drivers/usb/misc/onboard_usb_dev.c

I considered using onboard_usb_dev, but then came to the conclusion that
I don't need it because I don't need reset sequencing, only power.

> That way you can just describe the RTL8188 on the USB bus and assign
> it's vd33-supply without having to (ab)use vbus-supply of the USB
> controller.

This does sound reasonable. I'll reconsider the onboard_usb_dev
approach.

> 
> [...]
> > +               sdxc_c_pins: sdxc-c {
> > +                       mux {
> > +                               groups = "sdxc_d0_c", "sdxc_d13_c",
> > +                                       "sdxc_clk_c", "sdxc_cmd_c",
> > +                                       "sdxc_d47_c";
> > +                               function = "sdxc_c";
> > +                               bias_pull_up;
> This has to be bias-pull-up (dashes instead of underscores).

Oh, good catch, I'll fix it.


Thanks for your review,
J. Neuschäfer