[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-vjWFFWvo1gesCe@probook>
Date: Tue, 1 Apr 2025 13:00:08 +0000
From: J. Neuschäfer <j.ne@...teo.net>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: j.ne@...teo.net, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Jerome Brunet <jbrunet@...libre.com>,
Kevin Hilman <khilman@...libre.com>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-amlogic@...ts.infradead.org
Subject: Re: [PATCH 3/3] ARM: dts: amlogic: Add TCU Fernsehfee 3.0
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@...nel.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
Powered by blists - more mailing lists