[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFBinCBhg+dije+3DvV_V_kqHv9q+r4EPxXCYFti6KuA4mK7KQ@mail.gmail.com>
Date: Sun, 18 Jul 2021 13:37:04 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Anand Moon <linux.amoon@...il.com>
Cc: linux-phy@...ts.infradead.org,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-amlogic@...ts.infradead.org,
Linux Kernel <linux-kernel@...r.kernel.org>,
Matt Corallo <oc2udbzfd@...tcorallo.com>,
Rob Herring <robh+dt@...nel.org>,
Neil Armstrong <narmstrong@...libre.com>,
Kevin Hilman <khilman@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>,
Kishon Vijay Abraham I <kishon@...com>,
Vinod Koul <vkoul@...nel.org>,
Emiliano Ingrassia <ingrassia@...genesys.com>,
Brian Kim <brian.kim@...dkernel.com>,
devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCHv2 1/4] ARM: dts: meson8b: odroidc1: Add usb phy power node
Hi Anand,
On Sun, Jul 18, 2021 at 5:38 AM Anand Moon <linux.amoon@...il.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@...00000/phy@...0 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@...hl-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
Powered by blists - more mailing lists