Hi Martin,

Thanks for your valuable feedback,

On Sun, 18 Jul 2021 at 17:07, Martin Blumenstingl
[off-list ref] wrote:

Hi Anand,

On Sun, Jul 18, 2021 at 5:38 AM Anand Moon [off-list ref] wrote:
[...]

quoted

quoted

quoted

enable input power to USB ports, set it to Active Low.

[    1.253149] phy phy-c1108820.phy.0: Looking up phy-supply from device tree
[    1.253166] phy phy-c1108820.phy.0: Looking up phy-supply property
                in node /soc/cbus@c1100000/phy@8820 failed

high prio:
Can you please describe how I can test this patch?
My concern is that previously I have tested your patch with ACTIVE_LOW
and ACTIVE_HIGH polarity.
In both cases USB is working and I cannot observe any change (apart
from this debug message being gone).

In the Odroid-C1 schematics (page 1) GPIOAO.BIT5 is connected to USB_OTG *only*.
I cannot give my Acked-/Reviewed-/Tested-by without a description of
how I can actually test the GPIO potion of this patch.

This question is still open.
Even with all your explanations below I am missing a way to verify if
GPIOAO_5 is the correct GPIO to use.

From the schematics [1]
https://dn.odroid.com/S805/Schematics/odroid-c1+_rev0.4_20160226.pdf

You could find references to PWREN  <--- GPIOAO.BIT5
The second reference is USB HOST Power Switch
The third reference is USB HOST POWER.

Hope I am clean in my thought process now.
.

quoted

quoted

[...]

quoted

+               /*
+                * signal name from schematics: PWREN - GPIOAO.BIT5
+                */
+               gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;

low prio:
Even though it's strictly not necessary I think this is confusing to read.
Since there's no "enable-active-high" property the GPIO will be
considered as "active low".
My suggestion is to change GPIO_ACTIVE_HIGH to GPIO_ACTIVE_LOW

My apologies, I might have sent the wrong set of patches its
GPIO_ACTIVE_LOW I meant
I have formatted with and in the course of testing and verifying It
might have got SKIPPED.
I didn't do this intentionally it happen with a mistake with my two
repositories.
I don't intend to repeat my mistake, again and again, *sorry for the trouble*.

no worries, that's why I mentioned that it's low priority

quoted

quoted

Also if you have any extra information since you last pinged me on IRC
then it would be great if you could document it.
I am referring to these IRC message, where you are stating that the
correct polarity should be "active high":
<armoon> xdarklight I have a question on USB GPIO Polarity on Odroid C1+

 > <armoon> As per the

quoted

https://dn.odroid.com/S805/Schematics/odroid-c1+_rev0.4_20160226.pdf
<armoon> MP62551DGT-LF IC controls the power for the USB PORTS
<armoon> https://www.mouser.com/datasheet/2/277/MP62550-1384050.pdf is
MP62551DGT datasheet
<armoon> As per the data sheet in section ORDERING INFORMATION  Active
enable signal is set below MP62551DGT Active High

[1] https://www.mouser.com/datasheet/2/277/MP62550-1384050.pdf

I have read the datasheets MP62551DGT EN*  pin its Enable input. Active Low:
       *EN I Enable input. Active Low: (MP62550), Active High: (MP62551).*

I have tested with ACTIVE_LOW and followed all the steps invalidating
 this with debugfs output.

Last login: Tue Jul 13 00:02:49 2021 from 10.0.0.14
[alarm@archl-c1e ~]$ sudo cat /sys/kernel/debug/gpio | grep usb
 gpio-1953 (USB_HUB_RST_N       |usb-hub-reset       ) out hi
 gpio-1954 (USB_OTG_PWREN       |regulator-usb-pwr-en) out lo ACTIVE LOW

This means that whatever is configured in the .dts is also showing up
in debugfs.
It doesn't mean that the correct GPIO or polarity is used -> that is
why I want to understand how to actually test this patch.
Technically I can write a patch that makes GPIOAO_13 (which is
connected to the status LED) show up as being used by
regulator-usb-pwr-en in debugfs.

Yep, you are correct, If I used GPIOAO_13 wrong pin, it will not
enable the USB power. See below.
[alarm@archl-c1e ~]$ sudo cat /sys/kernel/debug/gpio | grep usb
 gpio-1953 (USB_HUB_RST_N       |usb-hub-reset       ) out hi

So correct way with  gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_LOW>;

[alarm@archl-c1e linux-amlogic-5.y-devel]$ sudo cat
/sys/kernel/debug/gpio | grep usb
 gpio-1953 (USB_HUB_RST_N       |usb-hub-reset       ) out hi
 gpio-1954 (USB_OTG_PWREN       |regulator-usb-pwr-en) out lo ACTIVE LOW

The reason for USB ports has power without this patch is applied.
Please check schematics S805 USB2 SDB
USB_VDD33 is powered with VDDIO_AO3V3 regulator directly along with SD CARD.

[...]

quoted

quoted

quoted

 &usb1_phy {
        status = "okay";
+       phy-supply = <&usb_pwr_en>;

medium priority:
I have raised the following concern in one of my previous emails on this topic:

quoted

The mistake I made before is considering USB VBUS as PHY power supply.
I believe the USB PHY is actually powered by the AVDD18_USB_ADC and
USB33_VDDIOH signals. See the S905 datasheet [0], page 25
These are 1.8V and 3.3V signals while you are adding a 5V regulator.

you replied with:

quoted

OK, thanks.

so I don't understand what "OK, thanks" means.
If it means "Martin, you are wrong" then please provide a description
so I can also learn something!

Yes, I understood your inputs. But from the logs below is seen to
looking for phy-supply

This sentence is correct

quoted

This is the reason I went ahead with phy-supply as the core phy node
needs this property.

This sentence is not correct
From drivers/phy/phy-core.c:
    phy->pwr = regulator_get_optional(&phy->dev, "phy");

As you can see, the "phy-supply" regulator is marked as optional in
the PHY subsystem.
This matches with
Documentation/devicetree/bindings/phy/phy-bindings.txt where
"phy-supply" is marked as an optional property.

quoted

Please check below commit
e841ec956e53 ("ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply")

That commit is from 2017. You'll also find some commits where I am
also using the phy-supply property (I didn't know better back then).
However, in 2018 things changed when the dwc2 driver gained a
vbus-supply property in commit 531ef5ebea9639 ("usb: dwc2: add support
for host mode external vbus supply")

OK.

So for new .dts support phy-supply should not be used anymore for VBUS
because phy-supply (described as "Phandle to a regulator that provides
power to the PHY." in
Documentation/devicetree/bindings/phy/phy-bindings.txt) and
vbus-supply are two different things.

It just came to my notice your email on this issue sees below.
[0] https://patchwork.kernel.org/project/linux-usb/patch/20190306212431.5779-1-martin.blumenstingl@googlemail.com/
[1] https://patchwork.kernel.org/patch/10868515/
[2] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=d8b475212bbf9e5f80c1c923a9701dca5ceb23e2

From the openwrt commit  d8b475212bbf9e5f80c1c923a9701dca5ceb23e2
and binding yaml  [3]
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/usb/dwc2.yaml#L87

USB DWC2 power is linked to vbus-supply, so it should be moved to usb node.
Now I am getting your point correctly.

[    1.260460] dwc2 c90c0000.usb: Looking up vusb_d-supply property in
node /soc/usb@c90c0000 failed
[    1.260490] dwc2 c90c0000.usb: supply vusb_d not found, using dummy regulator
[    1.260606] dwc2 c90c0000.usb: Looking up vusb_a-supply from device tree
[    1.260620] dwc2 c90c0000.usb: Looking up vusb_a-supply property in
node /soc/usb@c90c0000 failed
[    1.260641] dwc2 c90c0000.usb: supply vusb_a not found, using dummy regulator
[    1.260717] dwc2 c90c0000.usb: registering common handler for irq35
[    1.260772] dwc2 c90c0000.usb: Looking up vbus-supply from device tree
[    1.260784] dwc2 c90c0000.usb: Looking up vbus-supply property in
node /soc/usb@c90c0000 failed

Thanks for the input, I will update the vbus-supply in the next
version to USB nodes.

Best regards,
Martin

Thanks
-Anand

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel