| Message ID | 20210716103651.1455-2-linux.amoon@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Meson-8b and Meson-gxbb Fix some missing code | expand |
Hi Anand, On Fri, Jul 16, 2021 at 12:37 PM Anand Moon <linux.amoon@gmail.com> wrote: > > Add missing usb phy power node for phy mode fix below warning. > P5V0 regulator suppy input voltage range to USB host controller. low prio - typo: suppy -> supply > As descriped in the C1+ schematics, GPIO GPIOAO_5 is used to low prio - typo: descriped -> described > 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. [...] > + /* > + * 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 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 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 [...] > &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: > 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: > 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! Best regards, Martin
Hi Martin, Thanks for the review comments. On Sun, 18 Jul 2021 at 01:16, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Anand, > > On Fri, Jul 16, 2021 at 12:37 PM Anand Moon <linux.amoon@gmail.com> wrote: > > > > Add missing usb phy power node for phy mode fix below warning. > > P5V0 regulator suppy input voltage range to USB host controller. > low prio - typo: suppy -> supply > > > As descriped in the C1+ schematics, GPIO GPIOAO_5 is used to > low prio - typo: descriped -> described > I definitely run checkpatch with the spellcheck option but I need to improve on this aspect. > > 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. > > [...] > > + /* > > + * 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*. > 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 > 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 > [...] > > &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: > > 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: > > 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 is the reason I went ahead with phy-supply as the core phy node needs this property. Please check below commit e841ec956e53 ("ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply") [ 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 [ 1.255031] pwm-regulator regulator-vcck: Failed to get PWM, deferring probe [ 1.256730] pwm-regulator regulator-vddee: Failed to get PWM, deferring probe [ 1.260300] dwc2 c90c0000.usb: mapped PA c90c0000 to VA (ptrval) [ 1.260446] dwc2 c90c0000.usb: Looking up vusb_d-supply from device tree [ 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 [ 1.261949] dwc2 c90c0000.usb: Core Release: 3.10a (snpsid=4f54310a) > > > Best regards, > Martin -Anand
Hi Anand, On Sun, Jul 18, 2021 at 5:38 AM Anand Moon <linux.amoon@gmail.com> wrote: [...] > > > 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. > > [...] > > > + /* > > > + * 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 > > 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 > > 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. [...] > > > &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: > > > 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: > > > 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 > 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. > 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") 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. Best regards, Martin
Hi Martin, Thanks for your valuable feedback, On Sun, 18 Jul 2021 at 17:07, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Anand, > > On Sun, Jul 18, 2021 at 5:38 AM Anand Moon <linux.amoon@gmail.com> wrote: > [...] > > > > 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. . > > > > [...] > > > > + /* > > > > + * 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 > > > > 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 > > > 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. > > [...] > > > > &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: > > > > 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: > > > > 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 > > > 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. > > > 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
Hi Anand, On Sun, Jul 18, 2021 at 3:29 PM Anand Moon <linux.amoon@gmail.com> wrote: > > Hi Martin, > > Thanks for your valuable feedback, > > On Sun, 18 Jul 2021 at 17:07, Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > Hi Anand, > > > > On Sun, Jul 18, 2021 at 5:38 AM Anand Moon <linux.amoon@gmail.com> wrote: > > [...] > > > > > 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. Can you please point out the page numbers for me? What I am seeing on page 1 is: GPIOAO_5 (called GPIOAO.BIT5) is connected as an INPUT to the USB_OTG PWREN signal (that's the green box with the label "USB_OTG.SchDoc" above it). Below (still on page 1) there's a whole section for USB_HOST_PWR_SW.SchDoc and USB_HUB_GL852G-OHG.SchDoc. This box also uses a PWREN signal, but from my understanding it's a different one: - PWREN in this area is an OUTPUT on the USB hub (USB_HUB_GL852G-OHG.SchDoc). This is confirmed by the PWREN signals on page 14 of the GL852 datasheet: [4] - Then PWREN is an INPUT for the overcurrent switches (USB_HOST_PWR_SW.SchDoc) This section does not mention GPIOAO_5 (or GPIOAO.BIT5) at all. For better illustration I have attached a screenshot with some annotations from the schematics. This is how I understand the whole USB setup. This doesn't mean that I am right though. [...] > > 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 Did you also delete the "leds" node from meson8b-odroidc1.dts? [...] > > 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. Yes, I think we're now on the same page on this topic I totally forgot about some of these patches - great that you found them and added them here for further documentation of this topic! Best regards, Martin [4] https://datasheet.lcsc.com/szlcsc/Genesys-Logic-GL852G-HHG12_C136618.pdf
Hi Anand, On Sun, Jul 18, 2021 at 4:01 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: [...] > > 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. > Can you please point out the page numbers for me? > > What I am seeing on page 1 is: > GPIOAO_5 (called GPIOAO.BIT5) is connected as an INPUT to the USB_OTG > PWREN signal (that's the green box with the label "USB_OTG.SchDoc" > above it). I unfortunately missed your question on IRC on this topic: <armoon> xdarklight: just want to understand the confusion on PWREN, either is INPUT / OTPUT to usb hub am I correct My understanding of the INPUT/OUTPUT direction in the Odroid-C1 schematics (which you linked) above is that the arrow direction shows whether it's an input or output. For example (all on page one): - HDMI_HPD is an input to the Meson8b SoC, arrow direction is: HDMI => S805 - IR_IN is an input to the Meson8b SoC, arrow direction is: S805 <= GPIOAO.BIT7 IR_IN - PWM is an output, arrow direction is: S805 => PWM.C VCCK_PWM - 3.3V/1.8V switch for the SD card is an output, arrow direction is: S805 => GPIOAO.BIT3 TF_3V3N_1V8_EN That tells me: the arrow direction shows which connections are inputs or outputs. Some pins can be input and output at the same time (HDMI_CEC). But let's keep it simple for now any only look at inputs/output. Based on this information I am looking at the arrow direction for USB_OTG: GPIOAO.BIT5 PWREN <= S805 So this confirms that GPIOAO_5 is an output to the SoC. Please note though that this part is not linked with any USB host connector, it's only linked to the USB OTG path. For the next part the S805 SoC is not involved: USB1 USB_HOST_PWR_SW PWREN <= PWREN USB_HUB_GL852G USB2 USB_HOST_PWR_SW PWREN <= PWREN USB_HUB_GL852G This tells me that the PWREN signal for the two USB_HOST_PWR_SW (USB host power switches / current limiters) is driven by the GL852G USB hub. The GL852G USB hub datasheet [0] mentions on page 14: pin name: PWREN1#~4 I/O type: O (which stands for: OUTPUT) description: Active low. Power enable output for DSPORT1~4 PWREN1# is the only power-enable output for GANG mode. This seems to confirm my understanding of the Odroid-C1 schematics, where the PWREN signal of the current limiters is coming from the USB hub (so the Meson8b SoC is not involved directly). <armoon> sorry I am not the expert in schematics interpretation, but what I understand is PWREN (GPIOAO.BIT5) is input signal to MP62551DGT-LF-Z which controls the VBUS signal power to USB HUB to pin V5 on GL852G IC That part is unfortunately hard to say because the author of the Odroid-C1 schematics decided to two different signals called PWREN. Now it's not clear if this refers to the USB_OTG PWREN or USB_HOST PWREN signal. Based on page 1 I *assume* that it's linked to the USB_HOST PWREN signal. <armoon> plz check the GL852G power section. it has 5V Power input. It need be NC if using external regulator <armoon> 5V and V33 are the regulator for GL852G IC HUB, Looking at page 27 of the Odroid-C1 schematics I can see that PSELF, PGANG, V33, AVDD1, AVDD2, AVDD3 and DVDD are supplied by a 3.3V power supply called HUB_AVDD. V5 is a 5V signal which is not connected (there's a red cross next to it). <armoon> I feel setting GPIOAO.BIT5 setting to Active Low just enable the 5V via external regulator MP62551DGT-LF-Z My understanding is that GPIOAO.BIT5 enables or disables VBUS for the USB_OTG port (&usb1 in our .dts) See page 28 of the schematics, the RT9715EGB power switch uses a PWREN signal for it's ENABLE pin based on page 1 of the schematics. MP62551DGT-LF-Z would then be getting it's PWREN signal from the GL852G hub. Having different power switches for USB HOST and USB OTG makes sense because for USB OTG the VBUS signal needs to be disabled when in peripheral/device mode (for example when connecting the Odroid-C1 via micro-USB cable to a computer). <armoon> I don't know much on internal IC signal apart from this, may be I need to check with the board designer Odroid / Hardkernel for more details That would be great actually. Unfortunately Brian Kim's email address (which you had Cc'ed in the beginning of this conversation) is not valid anymore. If you have any other contact at Hardkernel then it would be great if you could add them to the loop so they can clear our questions. Best regards, Martin [0] https://datasheet.lcsc.com/szlcsc/Genesys-Logic-GL852G-HHG12_C136618.pdf
On Sun, Jul 18, 2021 at 9:09 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Anand, > > On Sun, Jul 18, 2021 at 4:01 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > [...] > > > 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. > > Can you please point out the page numbers for me? > > > > What I am seeing on page 1 is: > > GPIOAO_5 (called GPIOAO.BIT5) is connected as an INPUT to the USB_OTG > > PWREN signal (that's the green box with the label "USB_OTG.SchDoc" > > above it). > I unfortunately missed your question on IRC on this topic: > <armoon> xdarklight: just want to understand the confusion on PWREN, > either is INPUT / OTPUT to usb hub am I correct > My understanding of the INPUT/OUTPUT direction in the Odroid-C1 > schematics (which you linked) above is that the arrow direction shows > whether it's an input or output. > For example (all on page one): > - HDMI_HPD is an input to the Meson8b SoC, arrow direction is: HDMI => S805 > - IR_IN is an input to the Meson8b SoC, arrow direction is: S805 <= > GPIOAO.BIT7 IR_IN > - PWM is an output, arrow direction is: S805 => PWM.C VCCK_PWM > - 3.3V/1.8V switch for the SD card is an output, arrow direction is: > S805 => GPIOAO.BIT3 TF_3V3N_1V8_EN > > That tells me: the arrow direction shows which connections are inputs > or outputs. > Some pins can be input and output at the same time (HDMI_CEC). But > let's keep it simple for now any only look at inputs/output. > > Based on this information I am looking at the arrow direction for > USB_OTG: GPIOAO.BIT5 PWREN <= S805 > So this confirms that GPIOAO_5 is an output to the SoC. > Please note though that this part is not linked with any USB host > connector, it's only linked to the USB OTG path. > > For the next part the S805 SoC is not involved: > USB1 USB_HOST_PWR_SW PWREN <= PWREN USB_HUB_GL852G > USB2 USB_HOST_PWR_SW PWREN <= PWREN USB_HUB_GL852G > This tells me that the PWREN signal for the two USB_HOST_PWR_SW (USB > host power switches / current limiters) is driven by the GL852G USB > hub. Hardkernel team responded on the Odroid forums to the request from Anand: "Power-Enable signal to the USB load switch ICs is connected to the USB hub controller. It is not connected the CPU GPIO." The regulator from Anand's patch is therefore connected to the micro USB port. This means that the patch needs updating in case Anand wants to have it included. Best regards, Martin [0] https://forum.odroid.com/viewtopic.php?p=332217#p332217
Hi Martin, On Thu, 5 Aug 2021 at 03:28, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > On Sun, Jul 18, 2021 at 9:09 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > Hi Anand, > > > > On Sun, Jul 18, 2021 at 4:01 PM Martin Blumenstingl > > <martin.blumenstingl@googlemail.com> wrote: > > [...] > > > > 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. > > > Can you please point out the page numbers for me? > > > > > > What I am seeing on page 1 is: > > > GPIOAO_5 (called GPIOAO.BIT5) is connected as an INPUT to the USB_OTG > > > PWREN signal (that's the green box with the label "USB_OTG.SchDoc" > > > above it). > > I unfortunately missed your question on IRC on this topic: > > <armoon> xdarklight: just want to understand the confusion on PWREN, > > either is INPUT / OTPUT to usb hub am I correct > > My understanding of the INPUT/OUTPUT direction in the Odroid-C1 > > schematics (which you linked) above is that the arrow direction shows > > whether it's an input or output. > > For example (all on page one): > > - HDMI_HPD is an input to the Meson8b SoC, arrow direction is: HDMI => S805 > > - IR_IN is an input to the Meson8b SoC, arrow direction is: S805 <= > > GPIOAO.BIT7 IR_IN > > - PWM is an output, arrow direction is: S805 => PWM.C VCCK_PWM > > - 3.3V/1.8V switch for the SD card is an output, arrow direction is: > > S805 => GPIOAO.BIT3 TF_3V3N_1V8_EN > > > > That tells me: the arrow direction shows which connections are inputs > > or outputs. > > Some pins can be input and output at the same time (HDMI_CEC). But > > let's keep it simple for now any only look at inputs/output. > > > > Based on this information I am looking at the arrow direction for > > USB_OTG: GPIOAO.BIT5 PWREN <= S805 > > So this confirms that GPIOAO_5 is an output to the SoC. > > Please note though that this part is not linked with any USB host > > connector, it's only linked to the USB OTG path. > > > > For the next part the S805 SoC is not involved: > > USB1 USB_HOST_PWR_SW PWREN <= PWREN USB_HUB_GL852G > > USB2 USB_HOST_PWR_SW PWREN <= PWREN USB_HUB_GL852G > > This tells me that the PWREN signal for the two USB_HOST_PWR_SW (USB > > host power switches / current limiters) is driven by the GL852G USB > > hub. > Hardkernel team responded on the Odroid forums to the request from Anand: > "Power-Enable signal to the USB load switch ICs is connected to the > USB hub controller. > It is not connected the CPU GPIO." > > The regulator from Anand's patch is therefore connected to the micro USB port. > This means that the patch needs updating in case Anand wants to have > it included. > Yes, I will send a corrected version of the patches soon. > > Best regards, > Martin > > > [0] https://forum.odroid.com/viewtopic.php?p=332217#p332217 Thanks -Anand
Hi Martin, On Thu, 5 Aug 2021 at 23:48, Anand Moon <linux.amoon@gmail.com> wrote: > > Hi Martin, > > On Thu, 5 Aug 2021 at 03:28, Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > On Sun, Jul 18, 2021 at 9:09 PM Martin Blumenstingl > > <martin.blumenstingl@googlemail.com> wrote: > > > > > > Hi Anand, > > > > > > On Sun, Jul 18, 2021 at 4:01 PM Martin Blumenstingl > > > <martin.blumenstingl@googlemail.com> wrote: > > > [...] > > > > > 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. > > > > Can you please point out the page numbers for me? > > > > > > > > What I am seeing on page 1 is: > > > > GPIOAO_5 (called GPIOAO.BIT5) is connected as an INPUT to the USB_OTG > > > > PWREN signal (that's the green box with the label "USB_OTG.SchDoc" > > > > above it). > > > I unfortunately missed your question on IRC on this topic: > > > <armoon> xdarklight: just want to understand the confusion on PWREN, > > > either is INPUT / OTPUT to usb hub am I correct > > > My understanding of the INPUT/OUTPUT direction in the Odroid-C1 > > > schematics (which you linked) above is that the arrow direction shows > > > whether it's an input or output. > > > For example (all on page one): > > > - HDMI_HPD is an input to the Meson8b SoC, arrow direction is: HDMI => S805 > > > - IR_IN is an input to the Meson8b SoC, arrow direction is: S805 <= > > > GPIOAO.BIT7 IR_IN > > > - PWM is an output, arrow direction is: S805 => PWM.C VCCK_PWM > > > - 3.3V/1.8V switch for the SD card is an output, arrow direction is: > > > S805 => GPIOAO.BIT3 TF_3V3N_1V8_EN > > > > > > That tells me: the arrow direction shows which connections are inputs > > > or outputs. > > > Some pins can be input and output at the same time (HDMI_CEC). But > > > let's keep it simple for now any only look at inputs/output. > > > > > > Based on this information I am looking at the arrow direction for > > > USB_OTG: GPIOAO.BIT5 PWREN <= S805 > > > So this confirms that GPIOAO_5 is an output to the SoC. > > > Please note though that this part is not linked with any USB host > > > connector, it's only linked to the USB OTG path. > > > > > > For the next part the S805 SoC is not involved: > > > USB1 USB_HOST_PWR_SW PWREN <= PWREN USB_HUB_GL852G > > > USB2 USB_HOST_PWR_SW PWREN <= PWREN USB_HUB_GL852G > > > This tells me that the PWREN signal for the two USB_HOST_PWR_SW (USB > > > host power switches / current limiters) is driven by the GL852G USB > > > hub. > > Hardkernel team responded on the Odroid forums to the request from Anand: > > "Power-Enable signal to the USB load switch ICs is connected to the > > USB hub controller. > > It is not connected the CPU GPIO." > > > > The regulator from Anand's patch is therefore connected to the micro USB port. > > This means that the patch needs updating in case Anand wants to have > > it included. > > > > Yes, I will send a corrected version of the patches soon. I have a small query regarding GPIO polarity As per the datasheet of *MP62551DGT-LF-Z* [0] https://www.mouser.in/datasheet/2/277/MP62550-1384050.pdf USB power enables EN signal need to be Active High. PIN Fucntion > Enable input. Active Low: (MP62550), Active High: (MP62551). So the correct option in dts + /* + * signal name from schematics: PWREN - GPIOAO.BIT5 + */ + gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>; + enable-active-high; which gives me the below output. $ 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 hi Please clear this small query so that I can send the update patch. Thanks -Anand > > > > > Best regards, > > Martin > > > > > > [0] https://forum.odroid.com/viewtopic.php?p=332217#p332217 > > Thanks > -Anand
diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts b/arch/arm/boot/dts/meson8b-odroidc1.dts index c440ef94e082..26e8f91e0950 100644 --- a/arch/arm/boot/dts/meson8b-odroidc1.dts +++ b/arch/arm/boot/dts/meson8b-odroidc1.dts @@ -32,6 +32,24 @@ emmc_pwrseq: emmc-pwrseq { reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; }; + usb_pwr_en: regulator-usb-pwr-en { + compatible = "regulator-fixed"; + + regulator-name = "USB_PWR"; + + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + /* + * signal name from schematics: USB_POWER - P5V0 + */ + vin-supply = <&p5v0>; + + /* + * signal name from schematics: PWREN - GPIOAO.BIT5 + */ + gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>; + }; + leds { compatible = "gpio-leds"; blue { @@ -378,6 +396,7 @@ &uart_AO { &usb1_phy { status = "okay"; + phy-supply = <&usb_pwr_en>; }; &usb1 {
Add missing usb phy power node for phy mode fix below warning. P5V0 regulator suppy input voltage range to USB host controller. As descriped in the C1+ schematics, GPIO GPIOAO_5 is used to 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 Fixes: 2eb79a4d15ff (ARM: dts: meson: enabling the USB Host controller on Odroid-C1/C1+ board) Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> --- V1 > Fix the Input GPIO polarity from HIGH to LOW. previous version [0] https://patchwork.kernel.org/project/linux-amlogic/patch/20190113181808.5768-1-linux.amoon@gmail.com changes fix the vbus-suppy to phy-supply, drop enable usb0 USB_PWR 2 1 0 unknown 5000mV 0mA 5000mV 5000mV phy-c1108820.phy.0-phy 2 0mA 0mV 0mV --- arch/arm/boot/dts/meson8b-odroidc1.dts | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)