Support VBUS power control using regulator framework. Enables the regulator
while the port is in host mode.
The "vbus-supply" property can be provided using a usb-connector child node
and standard devicetree bindings.
Signed-off-by: Mike Looijmans <[email protected]>
---
v2: Add missing devm_regulator_get call which got lost during rebase
v3: Remove devicetree binding, use standard usb-connector
Fix probe fail when vbus-supply is not present
drivers/usb/dwc3/core.c | 38 ++++++++++++++++++++++++++++++--------
drivers/usb/dwc3/core.h | 4 ++++
drivers/usb/dwc3/drd.c | 6 ++----
3 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc17155cb2b..42e804ede1b3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -25,6 +25,7 @@
#include <linux/of.h>
#include <linux/acpi.h>
#include <linux/pinctrl/consumer.h>
+#include <linux/regulator/consumer.h>
#include <linux/reset.h>
#include <linux/usb/ch9.h>
@@ -112,6 +113,23 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
dwc->current_dr_role = mode;
}
+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);
+ 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;
+
+ dwc->vbus_reg = NULL;
+ }
+
dwc->reset = devm_reset_control_array_get(dev, true, true);
if (IS_ERR(dwc->reset))
return PTR_ERR(dwc->reset);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c171a8e215f..cee2574d7bf4 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1085,6 +1085,9 @@ struct dwc3 {
bool phys_ready;
+ struct regulator *vbus_reg;
+ bool vbus_reg_enabled;
+
struct ulpi *ulpi;
bool ulpi_ready;
@@ -1397,6 +1400,7 @@ struct dwc3_gadget_ep_cmd_params {
/* prototypes */
void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode);
+void dwc3_set_vbus(struct dwc3 *dwc, bool enable);
void dwc3_set_mode(struct dwc3 *dwc, u32 mode);
u32 dwc3_core_fifo_space(struct dwc3_ep *dep, u8 type);
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 7db1ffc92bbd..45fdec2d128d 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -384,8 +384,7 @@ void dwc3_otg_update(struct dwc3 *dwc, bool ignore_idstatus)
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);
if (dwc->usb2_generic_phy)
phy_set_mode(dwc->usb2_generic_phy,
PHY_MODE_USB_HOST);
@@ -398,8 +397,7 @@ void dwc3_otg_update(struct dwc3 *dwc, bool ignore_idstatus)
dwc3_event_buffers_setup(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, false);
+ dwc3_set_vbus(dwc, false);
if (dwc->usb2_generic_phy)
phy_set_mode(dwc->usb2_generic_phy,
PHY_MODE_USB_DEVICE);
--
2.17.1
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;
> + }
> +
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.
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: [email protected]
W: http://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
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.
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: [email protected]
W: http://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.
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.
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: [email protected]
W: http://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.
Hi,
Mike Looijmans <[email protected]> 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: [email protected]
> W: http://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
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: [email protected]
W: http://www.topicproducts.com
Please consider the environment before printing this e-mail
On 07-09-2020 09:44, Felipe Balbi wrote:
> Hi,
>
> Mike Looijmans <[email protected]> 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: [email protected]
>> W: http://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