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

From: Martin Blumenstingl
Date: Sun Apr 06 2025 - 16:36:38 EST


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.

> >
> > [...]
> > > +&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.
Thank you for the onboard usb device patches (for those who are curious: [0])!


[0] https://lore.kernel.org/lkml/20250403-rtl-onboard-v1-0-10ca9a6a4ee0@xxxxxxxxxx/