Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijm...@topicproducts.com W: www.topicproducts.com Please consider the environment before printing this e-mail On 07-09-2020 09:44, Felipe Balbi wrote: Hi, Mike Looijmans writes: Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijm...@topicproducts.com W: www.topicproducts.com Please consider the environment before printing this e-mail On 27-07-2020 12:23, Mark Brown wrote: On Sun, Jul 26, 2020 at 09:10:39AM +0200, Mike Looijmans wrote: On 23-07-2020 13:05, Mark Brown wrote: Does the device actually support running without power so that's a thing that can happen? _get_optional() should only ever be used for supplies that may be physically absent. It's the 5V VBUS power for the USB "plug" that's being controlled here. It must turned on when the controller is in "host" mode. Some boards arrange this in hardware through the PHY, and some just don't have any control at all and have it permanently on or off. On a board where the 5V is controlled using a GPIO line or an I2C chip, this patch is required to make it work. That sounds like the driver should not be using _get_optional() then. Making it mandatory would break most (read: all except Topic's) existing boards as they won't have it in their devicetree. I'm perfectly okay with that, but others might disagree. you're perfectly okay with break all existing users of the driver? That's a bit harsh It turned out that "optional" when used for regulators means the opposite of when used in clk context. For regulators, "optional" means "don't supply a dummy regulator if there's none provided". So get_optional will just fail when the supply isn't defined, while get_regulator will just return a dummy in that case. So the v4 patch which doesn't use "_get_optional" works for both cases and doesn't break existing use(r)s. -- Mike Looijmans
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
Hi, Mike Looijmans writes: > Met vriendelijke groet / kind regards, > > Mike Looijmans > System Expert > > > TOPIC Embedded Products B.V. > Materiaalweg 4, 5681 RJ Best > The Netherlands > > T: +31 (0) 499 33 69 69 > E: mike.looijm...@topicproducts.com > W: www.topicproducts.com > > Please consider the environment before printing this e-mail > On 27-07-2020 12:23, Mark Brown wrote: >> On Sun, Jul 26, 2020 at 09:10:39AM +0200, Mike Looijmans wrote: >>> On 23-07-2020 13:05, Mark Brown wrote: >> Does the device actually support running without power so that's a thing that can happen? _get_optional() should only ever be used for supplies that may be physically absent. >> >>> It's the 5V VBUS power for the USB "plug" that's being controlled here. It >>> must turned on when the controller is in "host" mode. Some boards arrange >>> this in hardware through the PHY, and some just don't have any control at >>> all and have it permanently on or off. On a board where the 5V is controlled >>> using a GPIO line or an I2C chip, this patch is required to make it work. >> >> That sounds like the driver should not be using _get_optional() then. >> > > Making it mandatory would break most (read: all except Topic's) existing > boards as they won't have it in their devicetree. I'm perfectly okay with > that, but others might disagree. you're perfectly okay with break all existing users of the driver? That's a bit harsh -- balbi signature.asc Description: PGP signature
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijm...@topicproducts.com W: www.topicproducts.com Please consider the environment before printing this e-mail On 27-07-2020 13:53, Mark Brown wrote: On Mon, Jul 27, 2020 at 01:50:26PM +0200, Mike Looijmans wrote: Met vriendelijke groet / kind regards, Mike Looijmans System Expert You probably want to remove your signature when replying to the list... On 27-07-2020 12:23, Mark Brown wrote: On Sun, Jul 26, 2020 at 09:10:39AM +0200, Mike Looijmans wrote: It's the 5V VBUS power for the USB "plug" that's being controlled here. It must turned on when the controller is in "host" mode. Some boards arrange this in hardware through the PHY, and some just don't have any control at all and have it permanently on or off. On a board where the 5V is controlled using a GPIO line or an I2C chip, this patch is required to make it work. That sounds like the driver should not be using _get_optional() then. Making it mandatory would break most (read: all except Topic's) existing boards as they won't have it in their devicetree. I'm perfectly okay with that, but others might disagree. No, it wouldn't break them at all - they'd get a dummy regulator provided. Ah, so *not* using _get_optional will yield the behaviour that I'd want. I'll test and make a v4 patch.
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
On Mon, Jul 27, 2020 at 01:50:26PM +0200, Mike Looijmans wrote: > > Met vriendelijke groet / kind regards, > > Mike Looijmans > System Expert You probably want to remove your signature when replying to the list... > On 27-07-2020 12:23, Mark Brown wrote: > > On Sun, Jul 26, 2020 at 09:10:39AM +0200, Mike Looijmans wrote: > > > It's the 5V VBUS power for the USB "plug" that's being controlled here. It > > > must turned on when the controller is in "host" mode. Some boards arrange > > > this in hardware through the PHY, and some just don't have any control at > > > all and have it permanently on or off. On a board where the 5V is > > > controlled > > > using a GPIO line or an I2C chip, this patch is required to make it work. > > That sounds like the driver should not be using _get_optional() then. > Making it mandatory would break most (read: all except Topic's) existing > boards as they won't have it in their devicetree. I'm perfectly okay with > that, but others might disagree. No, it wouldn't break them at all - they'd get a dummy regulator provided. signature.asc Description: PGP signature
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijm...@topicproducts.com W: www.topicproducts.com Please consider the environment before printing this e-mail On 27-07-2020 12:23, Mark Brown wrote: On Sun, Jul 26, 2020 at 09:10:39AM +0200, Mike Looijmans wrote: On 23-07-2020 13:05, Mark Brown wrote: Does the device actually support running without power so that's a thing that can happen? _get_optional() should only ever be used for supplies that may be physically absent. It's the 5V VBUS power for the USB "plug" that's being controlled here. It must turned on when the controller is in "host" mode. Some boards arrange this in hardware through the PHY, and some just don't have any control at all and have it permanently on or off. On a board where the 5V is controlled using a GPIO line or an I2C chip, this patch is required to make it work. That sounds like the driver should not be using _get_optional() then. Making it mandatory would break most (read: all except Topic's) existing boards as they won't have it in their devicetree. I'm perfectly okay with that, but others might disagree.
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
On Sun, Jul 26, 2020 at 09:10:39AM +0200, Mike Looijmans wrote: > On 23-07-2020 13:05, Mark Brown wrote: > > Does the device actually support running without power so that's a thing > > that can happen? _get_optional() should only ever be used for supplies > > that may be physically absent. > It's the 5V VBUS power for the USB "plug" that's being controlled here. It > must turned on when the controller is in "host" mode. Some boards arrange > this in hardware through the PHY, and some just don't have any control at > all and have it permanently on or off. On a board where the 5V is controlled > using a GPIO line or an I2C chip, this patch is required to make it work. That sounds like the driver should not be using _get_optional() then. signature.asc Description: PGP signature
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On 23-07-2020 13:05, Mark Brown wrote:
On Thu, Jul 23, 2020 at 09:56:14AM +0200, Vincent Whitchurch wrote:
On Fri, Jun 19, 2020 at 04:25:12PM +0200, Mike Looijmans wrote:
+void dwc3_set_vbus(struct dwc3 *dwc, bool enable)
+{
+ int ret;
+
+ if (enable != dwc->vbus_reg_enabled) {
+ if (enable)
+ ret = regulator_enable(dwc->vbus_reg);
+ else
+ ret = regulator_disable(dwc->vbus_reg);
dwc->vbus_reg is set to NULL when the regulator is not present. These
regulator_* functions expect a non-NULL pointer so a NULL check is
required before calling them.
Does the device actually support running without power so that's a thing
that can happen? _get_optional() should only ever be used for supplies
that may be physically absent.
It's the 5V VBUS power for the USB "plug" that's being controlled here.
It must turned on when the controller is in "host" mode. Some boards
arrange this in hardware through the PHY, and some just don't have any
control at all and have it permanently on or off. On a board where the
5V is controlled using a GPIO line or an I2C chip, this patch is
required to make it work.
--
Mike Looijmans
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
On Thu, Jul 23, 2020 at 09:56:14AM +0200, Vincent Whitchurch wrote:
> On Fri, Jun 19, 2020 at 04:25:12PM +0200, Mike Looijmans wrote:
> > +void dwc3_set_vbus(struct dwc3 *dwc, bool enable)
> > +{
> > + int ret;
> > +
> > + if (enable != dwc->vbus_reg_enabled) {
> > + if (enable)
> > + ret = regulator_enable(dwc->vbus_reg);
> > + else
> > + ret = regulator_disable(dwc->vbus_reg);
> dwc->vbus_reg is set to NULL when the regulator is not present. These
> regulator_* functions expect a non-NULL pointer so a NULL check is
> required before calling them.
Does the device actually support running without power so that's a thing
that can happen? _get_optional() should only ever be used for supplies
that may be physically absent.
signature.asc
Description: PGP signature
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
On Fri, Jun 19, 2020 at 04:25:12PM +0200, Mike Looijmans wrote:
> +void dwc3_set_vbus(struct dwc3 *dwc, bool enable)
> +{
> + int ret;
> +
> + if (enable != dwc->vbus_reg_enabled) {
> + if (enable)
> + ret = regulator_enable(dwc->vbus_reg);
> + else
> + ret = regulator_disable(dwc->vbus_reg);
dwc->vbus_reg is set to NULL when the regulator is not present. These
regulator_* functions expect a non-NULL pointer so a NULL check is
required before calling them.
> + if (!ret)
> + dwc->vbus_reg_enabled = enable;
> + }
> +
> + if (dwc->usb2_phy)
> + otg_set_vbus(dwc->usb2_phy->otg, enable);
> +}
> +
> static void __dwc3_set_mode(struct work_struct *work)
> {
> struct dwc3 *dwc = work_to_dwc(work);
> @@ -164,8 +182,7 @@ static void __dwc3_set_mode(struct work_struct *work)
> if (ret) {
> dev_err(dwc->dev, "failed to initialize host\n");
> } else {
> - if (dwc->usb2_phy)
> - otg_set_vbus(dwc->usb2_phy->otg, true);
> + dwc3_set_vbus(dwc, true);
> phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
> phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
> }
> @@ -173,8 +190,7 @@ static void __dwc3_set_mode(struct work_struct *work)
> case DWC3_GCTL_PRTCAP_DEVICE:
> dwc3_event_buffers_setup(dwc);
>
> - if (dwc->usb2_phy)
> - otg_set_vbus(dwc->usb2_phy->otg, false);
> + dwc3_set_vbus(dwc, false);
> phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_DEVICE);
> phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_DEVICE);
>
> @@ -1183,8 +1199,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
> case USB_DR_MODE_PERIPHERAL:
> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>
> - if (dwc->usb2_phy)
> - otg_set_vbus(dwc->usb2_phy->otg, false);
> + dwc3_set_vbus(dwc, false);
> phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_DEVICE);
> phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_DEVICE);
>
> @@ -1198,8 +1213,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
> case USB_DR_MODE_HOST:
> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
>
> - if (dwc->usb2_phy)
> - otg_set_vbus(dwc->usb2_phy->otg, true);
> + dwc3_set_vbus(dwc, true);
> phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
> phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
>
> @@ -1470,6 +1484,14 @@ static int dwc3_probe(struct platform_device *pdev)
>
> dwc3_get_properties(dwc);
>
> + dwc->vbus_reg = devm_regulator_get_optional(dev, "vbus");
> + if (IS_ERR(dwc->vbus_reg)) {
> + if (PTR_ERR(dwc->vbus_reg) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
Some drivers seem to do it this way, but I think it would be more
correct to return all errors that aren't ENODEV, like
drivers/gpu/drm/exynos/exynos_hdmi.c does. That way you would allow the
regulator to not be present, but you also wouldn't silently ignore other
errors such as ENOMEM.
> +
> + dwc->vbus_reg = NULL;
> + }
> +
