Messages in this thread | | | Subject | Re: [PATCH v3 3/3] arm64: dts: meson: Add minimal support for Odroid-N2 | From | Neil Armstrong <> | Date | Wed, 22 May 2019 10:19:20 +0200 |
| |
On 21/05/2019 20:01, Martin Blumenstingl wrote: > Hi Neil, > > On Tue, May 21, 2019 at 5:20 PM Neil Armstrong <narmstrong@baylibre.com> wrote: > [...] >> + hub_5v: regulator-hub_5v { >> + compatible = "regulator-fixed"; >> + regulator-name = "HUB_5V"; >> + regulator-min-microvolt = <5000000>; >> + regulator-max-microvolt = <5000000>; >> + vin-supply = <&vcc_5v>; >> + >> + gpio = <&gpio GPIOH_5 GPIO_ACTIVE_HIGH>; > I missed this in the review of v1: > according to the schematics GPIOH_5 is routed to GL3523 (soldered down > USB hub) CHIP_EN signal. > The datasheet [0] mentions that this will "Disable whole chip and keep > hub in lowest power state (standby mode)"
In the v1, we didn't have the schematics, so it was all a wild guess.
> > do you know if this is a similar case as GPIOH_4 (USB hub reset line, > we configure this using a gpio-hog)?
We have 3 signals for USB : - GPIOH_5: goes to CHIP_EN to CHIPENABLE to the Hub - GPIOH_4: goes to RST_N to RESETJ to the Hub - GPIOH_6: goes to PWREN for the OTG connector PWREN
As you said, the datasheet mentions : " Disable whole chip and keep hub in lowest power state (standby mode "
I modeled it as a regulator since when enabled it actually enables the power on the USB3 ports using the post-Hub VBUSCTRL signal.
Since I can't model these post-hub power enable signals, I can only model the hub CHIPENABLE as a regulator to handle power. I can't model the hub as a device subnode inside the dwc3 since when CHIPENABLE is low, it won't appear...
We could model it as a Hog, but we won't be able to power down the usb3 ports.
> > [...] >> +&ext_mdio { >> + external_phy: ethernet-phy@0 { >> + /* Realtek RTL8211F (0x001cc916) */ >> + reg = <0>; >> + max-speed = <1000>; >> + eee-broken-1000t; > are we in the same situation that we have on the X96 Max where network > dies without eee-broken-1000t?
I assume, let me run more tests to be sure.
> > [...] >> +&usb2_phy0 { >> + phy-supply = <&usb_pwr_en>; > is usb_pwr_en really the phy-supply or is it the vbus-supply of the > USB top control block (&usb node)? You're right, now we have the schematics, it's not the phy supply.
I'll move it to vbus-supply since it's connected to the pwrenable of the otg port.
> > if these three questions are answered then you can add my: > Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
I'll ask you to review the next version before !!!
Thanks. Neil
> > > Regards > Martin > > > [0] https://datasheet.lcsc.com/szlcsc/GL3523-OV3S1_C157363.pdf >
| |