Message ID | 1449621618-11900-1-git-send-email-tim.bird@sonymobile.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Andy Gross |
Headers | show |
On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: > Add a binding for the regulator which controls the OTG chargepath switch. > The OTG switch gets its power from pm8941_5vs1, and that should be > expressed as a usb-otg-in-supply property in the DT node for the > charger driver. The regulator name is "otg". > > Signed-off-by: Tim Bird <tim.bird@sonymobile.com> > --- > Changes since v1 > - switch supply name to have dashes instead of underscores > - remove superfluous DT explanations in the otg node description > --- > .../devicetree/bindings/power_supply/qcom_smbb.txt | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt > index 65b88fa..28b6da7 100644 > --- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt > +++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt > @@ -105,6 +105,22 @@ PROPERTIES > regulation must be done externally to fully comply with > the JEITA safety guidelines if this flag is set. > > +- usb-otg-in-supply: > + Usage: optional > + Value type: <phandle> > + Description: Reference to the regulator supplying power to the USB_OTG_IN > + pin. > + > +child nodes: > +- otg: > + Usage: optional > + Description: This node defines a regulator used to control the direction > + of VBUS voltage - specifically: whether to supply voltage > + to VBUS for host mode operation of the OTG port, or allow > + input voltage from external VBUS for charging. In the > + hardware, the supply for this regulator comes from > + usb-otg-in-supply. Doesn't this regulator need to have a name defined? Disabling this regulator (along with other setup) will enable charging? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/08/2015 08:11 PM, Rob Herring wrote: > On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: >> Add a binding for the regulator which controls the OTG chargepath switch. >> The OTG switch gets its power from pm8941_5vs1, and that should be >> expressed as a usb-otg-in-supply property in the DT node for the >> charger driver. The regulator name is "otg". >> >> Signed-off-by: Tim Bird <tim.bird@sonymobile.com> >> --- >> Changes since v1 >> - switch supply name to have dashes instead of underscores >> - remove superfluous DT explanations in the otg node description >> --- >> .../devicetree/bindings/power_supply/qcom_smbb.txt | 19 +++++++++++++++++++ >> 1 file changed, 19 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt >> index 65b88fa..28b6da7 100644 >> --- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt >> +++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt >> @@ -105,6 +105,22 @@ PROPERTIES >> regulation must be done externally to fully comply with >> the JEITA safety guidelines if this flag is set. >> >> +- usb-otg-in-supply: >> + Usage: optional >> + Value type: <phandle> >> + Description: Reference to the regulator supplying power to the USB_OTG_IN >> + pin. >> + >> +child nodes: >> +- otg: >> + Usage: optional >> + Description: This node defines a regulator used to control the direction >> + of VBUS voltage - specifically: whether to supply voltage >> + to VBUS for host mode operation of the OTG port, or allow >> + input voltage from external VBUS for charging. In the >> + hardware, the supply for this regulator comes from >> + usb-otg-in-supply. > > Doesn't this regulator need to have a name defined? I'm not sure what you mean. The regulator name is "otg", defined by the DT node name. The code requires that the DT node name be "otg", and defines a regulator with the same name. As far as I know, you have to define a DT label for the node, in order to reference this regulator with a phandle. Is that what you are referring to? I usually use "chg_otg" as the label. Are you asking that this be reflected in the example? > Disabling this regulator (along with other setup) will enable charging? Yes. Enabling it allows the device to power the USB VBUS line for host mode, and disabling it allows power to flow the other way (into the device) for charging, when the USB port is in gadget mode. -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 9, 2015 at 6:55 AM, Tim Bird <tim.bird@sonymobile.com> wrote: > On 12/08/2015 08:11 PM, Rob Herring wrote: >> On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: >>> Add a binding for the regulator which controls the OTG chargepath switch. >>> The OTG switch gets its power from pm8941_5vs1, and that should be >>> expressed as a usb-otg-in-supply property in the DT node for the >>> charger driver. The regulator name is "otg". [...] >>> +child nodes: >>> +- otg: >>> + Usage: optional >>> + Description: This node defines a regulator used to control the direction >>> + of VBUS voltage - specifically: whether to supply voltage >>> + to VBUS for host mode operation of the OTG port, or allow >>> + input voltage from external VBUS for charging. In the >>> + hardware, the supply for this regulator comes from >>> + usb-otg-in-supply. >> >> Doesn't this regulator need to have a name defined? > > I'm not sure what you mean. The regulator name is "otg", defined by the DT node > name. The code requires that the DT node name be "otg", and defines a regulator > with the same name. > > As far as I know, you have to define a DT label for the node, in order > to reference this regulator with a phandle. Is that what you are referring to? > I usually use "chg_otg" as the label. Are you asking that this be reflected > in the example? You need a regulator-name property. Also, should should define valid values for regulator-min-microvolt and regulator-max-microvolt. Thinking about this some more, the node name should be generic, so just "regulator". The label does not need to be generic. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/09/2015 06:36 AM, Rob Herring wrote: > On Wed, Dec 9, 2015 at 6:55 AM, Tim Bird <tim.bird@sonymobile.com> wrote: >> On 12/08/2015 08:11 PM, Rob Herring wrote: >>> On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: >>>> Add a binding for the regulator which controls the OTG chargepath switch. >>>> The OTG switch gets its power from pm8941_5vs1, and that should be >>>> expressed as a usb-otg-in-supply property in the DT node for the >>>> charger driver. The regulator name is "otg". > > [...] > >>>> +child nodes: >>>> +- otg: >>>> + Usage: optional >>>> + Description: This node defines a regulator used to control the direction >>>> + of VBUS voltage - specifically: whether to supply voltage >>>> + to VBUS for host mode operation of the OTG port, or allow >>>> + input voltage from external VBUS for charging. In the >>>> + hardware, the supply for this regulator comes from >>>> + usb-otg-in-supply. >>> >>> Doesn't this regulator need to have a name defined? >> >> I'm not sure what you mean. The regulator name is "otg", defined by the DT node >> name. The code requires that the DT node name be "otg", and defines a regulator >> with the same name. >> >> As far as I know, you have to define a DT label for the node, in order >> to reference this regulator with a phandle. Is that what you are referring to? >> I usually use "chg_otg" as the label. Are you asking that this be reflected >> in the example? > > You need a regulator-name property. Also, should should define valid > values for regulator-min-microvolt and regulator-max-microvolt. All of those are listed as optional properties in Documentation/devicetree/bindings/regulator/regulator.txt. The regulator-name seems redundant, since the name of the DT node becomes the regulator name in the Linux system. This is not currently used anywhere, as the node is "connected up" via phandle, which uses the label. That is, there's no code in the kernel that looks up this regulator by name, although it does get a name. As for the microvolt references, I'm a little stumped what to do with those. I could use regulator-min-microvolt of 0 and a regulator-max-microvolt of 500000, but that's not exactly right. This is actually representing a voltage switch, which is being represented in the regulator framework in Linux, because it seems to fit there best. It has regulators it's related to, which should be adjusted when this one is. However, it intrinsically does not have a voltage of it's own, so it's a bit of a weird case. And the voltage can either be going "out" or "in". I'm CC-ing Mark Brown, who may know how these types of things are supposed to be expressed. I believe he saw an earlier version of this patch last year. Or maybe our power maintainers will chime in with some wisdom. I can't be the first person to be adding a charge pathway switch to mainline, so I'm open to doing it the "right way". :-) > Thinking about this some more, the node name should be generic, so > just "regulator". The label does not need to be generic. There are other switches in the charger block that are not exposed yet. This one handles the the OTG (vbus) charge pathway. Others handle other charge pathways (some of which are used on phones and some are not - they're used, e.g., on the dragonboard). I'd rather not give it a generic name, because eventually the driver should expose those other switches as something as well. -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 09, 2015 at 09:42:09AM -0800, Tim Bird wrote: > On 12/09/2015 06:36 AM, Rob Herring wrote: > > You need a regulator-name property. Also, should should define valid > > values for regulator-min-microvolt and regulator-max-microvolt. > All of those are listed as optional properties in > Documentation/devicetree/bindings/regulator/regulator.txt. I have to say I'm also a bit confused about why a binding using a regulator would need to do anything other than reference that document except in cases where using some functionality enabled by the generic bindings is a key part of the functionality of the device (which do tend to be rare). > The regulator-name seems redundant, since the name of the DT > node becomes the regulator name in the Linux system. This is The purpose of the regulator-name property is to allow you to put in a descriptive name for the supply which would normally correspond to the name the supply is given on the schematic and may not fit into the DT conventions. It is entirely optional but strongly recommended to aid people in understanding how both the DT and the running kernel relate to the schematic. > not currently used anywhere, as the node is "connected up" via > phandle, which uses the label. That is, there's no code in > the kernel that looks up this regulator by name, although it > does get a name. The name is purely for use by humans in logs and/or userspace, it is not used in the kernel. > As for the microvolt references, I'm a little stumped what > to do with those. I could use regulator-min-microvolt of 0 > and a regulator-max-microvolt of 500000, but that's not > exactly right. You should only specify voltages if the intention is to either allow consumers to vary voltages at runtime or have the kernel set a specific voltage for the regulator (eg, if the hardware defaults are wrong). > This is actually representing a voltage switch, which is being > represented in the regulator framework in Linux, because it > seems to fit there best. It has regulators it's related > to, which should be adjusted when this one is. However, it > intrinsically does not have a voltage of it's own, so it's a > bit of a weird case. And the voltage can either be going > "out" or "in". If you want consumers of the supply to be able to vary the voltage you need to permit that on the child supply as well as the parent supply so we know we can pass requests up.
On Wed 09 Dec 06:36 PST 2015, Rob Herring wrote: > On Wed, Dec 9, 2015 at 6:55 AM, Tim Bird <tim.bird@sonymobile.com> wrote: > > On 12/08/2015 08:11 PM, Rob Herring wrote: > >> On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: > >>> Add a binding for the regulator which controls the OTG chargepath switch. > >>> The OTG switch gets its power from pm8941_5vs1, and that should be > >>> expressed as a usb-otg-in-supply property in the DT node for the > >>> charger driver. The regulator name is "otg". > > [...] > > >>> +child nodes: > >>> +- otg: > >>> + Usage: optional > >>> + Description: This node defines a regulator used to control the direction > >>> + of VBUS voltage - specifically: whether to supply voltage > >>> + to VBUS for host mode operation of the OTG port, or allow > >>> + input voltage from external VBUS for charging. In the > >>> + hardware, the supply for this regulator comes from > >>> + usb-otg-in-supply. > >> > >> Doesn't this regulator need to have a name defined? > > > > I'm not sure what you mean. The regulator name is "otg", defined by the DT node > > name. The code requires that the DT node name be "otg", and defines a regulator > > with the same name. > > > > As far as I know, you have to define a DT label for the node, in order > > to reference this regulator with a phandle. Is that what you are referring to? > > I usually use "chg_otg" as the label. Are you asking that this be reflected > > in the example? > > You need a regulator-name property. Also, should should define valid > values for regulator-min-microvolt and regulator-max-microvolt. > The regulator has a name, derived from the node name, and this is significant. If the developer wants an additional human readable name for some reason they can use the optional regulator-name property. The regulator is a simple switch and as such inherits voltage properties from its supply. It should therefor not have any specified voltage range. > Thinking about this some more, the node name should be generic, so > just "regulator". The label does not need to be generic. > The name of the node is significant, as it's used for matching the regulator to an implementation. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 9, 2015 at 1:59 PM, Bjorn Andersson <bjorn.andersson@sonymobile.com> wrote: > On Wed 09 Dec 06:36 PST 2015, Rob Herring wrote: > >> On Wed, Dec 9, 2015 at 6:55 AM, Tim Bird <tim.bird@sonymobile.com> wrote: >> > On 12/08/2015 08:11 PM, Rob Herring wrote: >> >> On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: >> >>> Add a binding for the regulator which controls the OTG chargepath switch. >> >>> The OTG switch gets its power from pm8941_5vs1, and that should be >> >>> expressed as a usb-otg-in-supply property in the DT node for the >> >>> charger driver. The regulator name is "otg". >> >> [...] >> >> >>> +child nodes: >> >>> +- otg: >> >>> + Usage: optional >> >>> + Description: This node defines a regulator used to control the direction >> >>> + of VBUS voltage - specifically: whether to supply voltage >> >>> + to VBUS for host mode operation of the OTG port, or allow >> >>> + input voltage from external VBUS for charging. In the >> >>> + hardware, the supply for this regulator comes from >> >>> + usb-otg-in-supply. >> >> >> >> Doesn't this regulator need to have a name defined? >> > >> > I'm not sure what you mean. The regulator name is "otg", defined by the DT node >> > name. The code requires that the DT node name be "otg", and defines a regulator >> > with the same name. >> > >> > As far as I know, you have to define a DT label for the node, in order >> > to reference this regulator with a phandle. Is that what you are referring to? >> > I usually use "chg_otg" as the label. Are you asking that this be reflected >> > in the example? >> >> You need a regulator-name property. Also, should should define valid >> values for regulator-min-microvolt and regulator-max-microvolt. >> > > The regulator has a name, derived from the node name, and this is > significant. If the developer wants an additional human readable name > for some reason they can use the optional regulator-name property. > > The regulator is a simple switch and as such inherits voltage properties > from its supply. It should therefor not have any specified voltage > range. > >> Thinking about this some more, the node name should be generic, so >> just "regulator". The label does not need to be generic. >> > > The name of the node is significant, as it's used for matching the > regulator to an implementation. Ah yes, you are right. I forget what an oddball the regulator binding is. And if voltage switches don't need min and max properties, then it is fine as is. Still, the empty node with no properties seems odd to me. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Wed, Dec 09, 2015 at 09:42:09AM -0800, Tim Bird wrote: > Or maybe our power maintainers will chime in with some wisdom. I > can't be the first person to be adding a charge pathway switch to > mainline, so I'm open to doing it the "right way". :-) I don't think there is a standard way for this so far. Another otg charger coming to my mindis bq2415x, which basically just exposes the enable bit via sysfs. Exposing the switch as regulator would be fine for me. > > Thinking about this some more, the node name should be generic, so > > just "regulator". The label does not need to be generic. > > There are other switches in the charger block that are not > exposed yet. This one handles the the OTG (vbus) charge pathway. > Others handle other charge pathways (some of which are used on phones > and some are not - they're used, e.g., on the dragonboard). I'd > rather not give it a generic name, because eventually the driver > should expose those other switches as something as well. otg_regulator: regulator@0 { } other_regulator: regulator@1 { } -- Sebastian
On Wed, Dec 09, 2015 at 11:20:45PM +0100, Sebastian Reichel wrote: > On Wed, Dec 09, 2015 at 09:42:09AM -0800, Tim Bird wrote: > > There are other switches in the charger block that are not > > exposed yet. This one handles the the OTG (vbus) charge pathway. > > Others handle other charge pathways (some of which are used on phones > > and some are not - they're used, e.g., on the dragonboard). I'd > > rather not give it a generic name, because eventually the driver > > should expose those other switches as something as well. > otg_regulator: regulator@0 { } > other_regulator: regulator@1 { } No, if this is a device with multiple regulators we have a standard way of exposing that - have a regulators subnode with a collection of named regulator subnodes in that. There's support for parsing this in the framework.
On Wed, Dec 9, 2015 at 3:08 PM, Rob Herring <robh@kernel.org> wrote: > On Wed, Dec 9, 2015 at 1:59 PM, Bjorn Andersson > <bjorn.andersson@sonymobile.com> wrote: >> On Wed 09 Dec 06:36 PST 2015, Rob Herring wrote: >> >>> On Wed, Dec 9, 2015 at 6:55 AM, Tim Bird <tim.bird@sonymobile.com> wrote: >>> > On 12/08/2015 08:11 PM, Rob Herring wrote: >>> >> On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: >>> >>> Add a binding for the regulator which controls the OTG chargepath switch. >>> >>> The OTG switch gets its power from pm8941_5vs1, and that should be >>> >>> expressed as a usb-otg-in-supply property in the DT node for the >>> >>> charger driver. The regulator name is "otg". >>> >>> [...] >>> >>> >>> +child nodes: >>> >>> +- otg: >>> >>> + Usage: optional >>> >>> + Description: This node defines a regulator used to control the direction >>> >>> + of VBUS voltage - specifically: whether to supply voltage >>> >>> + to VBUS for host mode operation of the OTG port, or allow >>> >>> + input voltage from external VBUS for charging. In the >>> >>> + hardware, the supply for this regulator comes from >>> >>> + usb-otg-in-supply. >>> >> >>> >> Doesn't this regulator need to have a name defined? >>> > >>> > I'm not sure what you mean. The regulator name is "otg", defined by the DT node >>> > name. The code requires that the DT node name be "otg", and defines a regulator >>> > with the same name. >>> > >>> > As far as I know, you have to define a DT label for the node, in order >>> > to reference this regulator with a phandle. Is that what you are referring to? >>> > I usually use "chg_otg" as the label. Are you asking that this be reflected >>> > in the example? >>> >>> You need a regulator-name property. Also, should should define valid >>> values for regulator-min-microvolt and regulator-max-microvolt. >>> >> >> The regulator has a name, derived from the node name, and this is >> significant. If the developer wants an additional human readable name >> for some reason they can use the optional regulator-name property. >> >> The regulator is a simple switch and as such inherits voltage properties >> from its supply. It should therefor not have any specified voltage >> range. >> >>> Thinking about this some more, the node name should be generic, so >>> just "regulator". The label does not need to be generic. >>> >> >> The name of the node is significant, as it's used for matching the >> regulator to an implementation. > > Ah yes, you are right. I forget what an oddball the regulator binding is. > > And if voltage switches don't need min and max properties, then it is > fine as is. Still, the empty node with no properties seems odd to me. Thinking some more about this, what bothers me is just having "otg {};" gives no clue as to what the node is for w/o the documentation. "otg" alone could mean several things. I think minimally, it needs either a node name that gives some indication it is a regulator or Vbus supply, a required regulator-name or even a comment. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt index 65b88fa..28b6da7 100644 --- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt +++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt @@ -105,6 +105,22 @@ PROPERTIES regulation must be done externally to fully comply with the JEITA safety guidelines if this flag is set. +- usb-otg-in-supply: + Usage: optional + Value type: <phandle> + Description: Reference to the regulator supplying power to the USB_OTG_IN + pin. + +child nodes: +- otg: + Usage: optional + Description: This node defines a regulator used to control the direction + of VBUS voltage - specifically: whether to supply voltage + to VBUS for host mode operation of the OTG port, or allow + input voltage from external VBUS for charging. In the + hardware, the supply for this regulator comes from + usb-otg-in-supply. + EXAMPLE charger@1000 { compatible = "qcom,pm8941-charger"; @@ -128,4 +144,7 @@ charger@1000 { qcom,fast-charge-current-limit = <1000000>; qcom,dc-charge-current-limit = <1000000>; + usb-otg-in-supply = <&pm8941_5vs1>; + + otg {}; };
Add a binding for the regulator which controls the OTG chargepath switch. The OTG switch gets its power from pm8941_5vs1, and that should be expressed as a usb-otg-in-supply property in the DT node for the charger driver. The regulator name is "otg". Signed-off-by: Tim Bird <tim.bird@sonymobile.com> --- Changes since v1 - switch supply name to have dashes instead of underscores - remove superfluous DT explanations in the otg node description --- .../devicetree/bindings/power_supply/qcom_smbb.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)