lkml.org 
[lkml]   [2019]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 3/3] arm64: dts: meson: Add minimal support for Odroid-N2
From
Date
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
>

\
 
 \ /
  Last update: 2019-05-22 10:21    [W:0.077 / U:3.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site