| Message ID | 1404782785-1824-3-git-send-email-bjorn.andersson@sonymobile.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson <bjorn.andersson@sonymobile.com> wrote: > This introduced the device tree bindings for the gpio block found in > pm8018, pm8038, pm8058, pm8917 and pm8921 pmics from Qualcomm. > > Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> (...) > +- interrupts: > + Usage: required > + Value type: <prop-encoded-array> > + Definition: Must contain an array of encoded interrupt specifiers for > + each available gpio So each GPIO has its own interrupt line looped back from the PMIC and into some other SoC or so handling the actual interrupt? This seems expensive? (Albeit efficient and fast.) (...) > +Please refer to pinctrl-bindings.txt in this directory for details of the > +common pinctrl bindings used by client devices, including the meaning of the > +phrase "pin configuration node". > + > +The pin configuration nodes act as a container for an abitrary number of > +subnodes. Each of these subnodes represents some desired configuration for a > +pin or a list of pins. This configuration can include the > +mux function to select on those pin(s), and various pin configuration > +parameters, s listed below. *is* listed below? > +The following generic properties as defined in pinctrl-bindings.txt are valid > +to specify in a pin configuration subnode: > + > +- pins: > + Usage: required > + Value type: <string-array> > + Definition: List of gpio pins affected by the properties specified in > + this subnode. Valid pins are: > + gpio1-gpio6 for pm8018 > + gpio1-gpio12 for pm8038 > + gpio1-gpio40 for pm8058 > + gpio1-gpio38 for pm8917 > + gpio1-gpio44 for pm8921 I usually name pins with CAPITAL LETTERS so would be "GPIO1", "GPIO2" etc, lowercase may be confusing as these are names not functions or groups. > +- function: > + Usage: optional > + Value type: <string> > + Definition: Specify the alternative function to be configured for the > + specified pins. Valid values are: > + "normal", > + "paired", > + "func1", > + "func2", > + "dtest1", > + "dtest2", > + "dtest3", > + "dtest4" These are a bit ambigous, why doesn't the driver present functions that are more specific than "func1", "func2"? Or "dtest1"? I guess the following just redefines or extends the generic pinconf bindings (which is fully OK). > +- bias-disable: > + Usage: optional > + Value type: <none> Isn't the type simply bool? > +- bias-pull-down: > + Usage: optional > + Value type: <none> bool? > +- bias-pull-up: > + Usage: optional > + Value type: <u32> (optional) > + Definition: The specified pins should be configued as pull up. An > + optional argument can be used to configure the strength. > + Valid values are; as defined in > + <dt-bindings/pinctrl/qcom,pm8xxx-gpio.h>: > + 1: 30uA (PM8XXX_GPIO_PULL_UP_30) > + 2: 1.5uA (PM8XXX_GPIO_PULL_UP_1P5) > + 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) > + 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) Hm, I don't know of the internal kernel API or so, but I'm thinking that for the DT bindings, this definition should be generic in Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt and put in SI units like uA. So I would prefer: bias-pull-up = <30>; for 30 uA. Maybe we want nA even? I'm uncertain about the proper granularity here :-/ Magic enumerators 1,2,3,4 doesn't seem so good, that seems more like it's trying to match the magic value that is to be poked into a register or something like that. > +- bias-high-impedance: > + Usage: optional > + Value type: <none> bool > +- input-enable: > + Usage: optional > + Value type: <none> bool > +- output-high: > + Usage: optional > + Value type: <none> bool > +- output-low: > + Usage: optional > + Value type: <none> bool > +- power-source: > + Usage: optional > + Value type: <u32> > + Definition: Selects the power source for the specified pins. Valid > + power sources are, as defined in > + <dt-bindings/pinctrl/qcom,pm8xxx-gpio.h>: > + 0: bb (PM8XXX_GPIO_VIN_BB) > + valid for pm8038, pm8058, pm8917, pm8921 > + 1: ldo2 (PM8XXX_GPIO_VIN_L2) > + valid for pm8018, pm8038, pm8917,pm8921 > + 2: ldo3 (PM8XXX_GPIO_VIN_L3) > + valid for pm8038, pm8058, pm8917, pm8921 > + 3: ldo4 (PM8XXX_GPIO_VIN_L4) > + valid for pm8018, pm8917, pm8921 > + 4: ldo5 (PM8XXX_GPIO_VIN_L5) > + valid for pm8018, pm8058 > + 5: ldo6 (PM8XXX_GPIO_VIN_L6) > + valid for pm8018, pm8058 > + 6: ldo7 (PM8XXX_GPIO_VIN_L7) > + valid for pm8058 > + 7: ldo8 (PM8XXX_GPIO_VIN_L8) > + valid for pm8018 > + 8: ldo11 (PM8XXX_GPIO_VIN_L11) > + valid for pm8038 > + 9: ldo14 (PM8XXX_GPIO_VIN_L14) > + valid for pm8018 > + 10: ldo15 (PM8XXX_GPIO_VIN_L15) > + valid for pm8038, pm8917, pm8921 > + 11: ldo17 (PM8XXX_GPIO_VIN_L17) > + valid for pm8038, pm8917, pm8921 > + 12: smps3 (PM8XXX_GPIO_VIN_S3) > + valid for pm8018, pm8058 > + 13: smps4 (PM8XXX_GPIO_VIN_S4) > + valid for pm8921 > + 14: vph (PM8XXX_GPIO_VIN_VPH) > + valid for pm8018, pm8038, pm8058, pm8917 pm8921 These are more apropriate to have in custom format selectors I think, so this is OK. > +- drive-strength: > + Usage: optional > + Value type: <u32> > + Definition: Selects the drive strength for the specified pins. Value > + drive strengths are: > + 0: no (PM8XXX_GPIO_STRENGTH_NO) > + 1: high (PM8XXX_GPIO_STRENGTH_HIGH) > + 2: medium (PM8XXX_GPIO_STRENGTH_MED) > + 3: low (PM8XXX_GPIO_STRENGTH_LOW) I would really prefer to have these in mA, because the genric pinconf bindings say they should be! SI units are so much more understandable. > +- drive-push-pull: > + Usage: optional > + Value type: <none> bool > +- drive-open-drain: > + Usage: optional > + Value type: <none> bool > +Example: > + > + pm8921_gpio: gpio@150 { > + compatible = "qcom,pm8921-gpio"; > + reg = <0x150>; > + interrupts = <192 1>, <193 1>, <194 1>, > + <195 1>, <196 1>, <197 1>, > + <198 1>, <199 1>, <200 1>, > + <201 1>, <202 1>, <203 1>, > + <204 1>, <205 1>, <206 1>, > + <207 1>, <208 1>, <209 1>, > + <210 1>, <211 1>, <212 1>, > + <213 1>, <214 1>, <215 1>, > + <216 1>, <217 1>, <218 1>, > + <219 1>, <220 1>, <221 1>, > + <222 1>, <223 1>, <224 1>, > + <225 1>, <226 1>, <227 1>, > + <228 1>, <229 1>, <230 1>, > + <231 1>, <232 1>, <233 1>, > + <234 1>, <235 1>; So this looks a bit weird. But if I just get to understand the hardware I guess it won't anymore. So there is an interrupt parent to which the IRQ lines from the PMIC are routed back through external lines to IRQ offsets 192 thru 235? Yours, Linus Walleij
On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson > <bjorn.andersson@sonymobile.com> wrote: > >> This introduced the device tree bindings for the gpio block found in >> pm8018, pm8038, pm8058, pm8917 and pm8921 pmics from Qualcomm. >> >> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> > (...) >> +- interrupts: >> + Usage: required >> + Value type: <prop-encoded-array> >> + Definition: Must contain an array of encoded interrupt specifiers for >> + each available gpio > > So each GPIO has its own interrupt line looped back from the PMIC > and into some other SoC or so handling the actual interrupt? > This seems expensive? (Albeit efficient and fast.) > > (...) Almost. The pmic have a shared interrupt and the pm8921-core driver has a chained irq handler. Each gpio get it's own interrupt on that level. >> +Please refer to pinctrl-bindings.txt in this directory for details of the >> +common pinctrl bindings used by client devices, including the meaning of the >> +phrase "pin configuration node". >> + >> +The pin configuration nodes act as a container for an abitrary number of >> +subnodes. Each of these subnodes represents some desired configuration for a >> +pin or a list of pins. This configuration can include the >> +mux function to select on those pin(s), and various pin configuration >> +parameters, s listed below. > > *is* listed below? > *as* >> +The following generic properties as defined in pinctrl-bindings.txt are valid >> +to specify in a pin configuration subnode: >> + >> +- pins: >> + Usage: required >> + Value type: <string-array> >> + Definition: List of gpio pins affected by the properties specified in >> + this subnode. Valid pins are: >> + gpio1-gpio6 for pm8018 >> + gpio1-gpio12 for pm8038 >> + gpio1-gpio40 for pm8058 >> + gpio1-gpio38 for pm8917 >> + gpio1-gpio44 for pm8921 > > I usually name pins with CAPITAL LETTERS so would be > "GPIO1", "GPIO2" etc, lowercase may be confusing as these are > names not functions or groups. > I was hoping to be able to follow the pattern used in pinctrl-msm; can I say something nice to have you agree on this? There's no difference between pins and groups here. >> +- function: >> + Usage: optional >> + Value type: <string> >> + Definition: Specify the alternative function to be configured for the >> + specified pins. Valid values are: >> + "normal", >> + "paired", >> + "func1", >> + "func2", >> + "dtest1", >> + "dtest2", >> + "dtest3", >> + "dtest4" > > These are a bit ambigous, why doesn't the driver present functions that > are more specific than "func1", "func2"? Or "dtest1"? > I agree, unfortunately I have only seen traces of the actual function matrix; for pm8xxx I have no documentation and for pm8x41 they are only listed as func[1-2] and dtest[1-4]. Maybe if someone at Qualcomm could release such a list we could provide a proper table instead. > I guess the following just redefines or extends the generic pinconf > bindings (which is fully OK). > >> +- bias-disable: >> + Usage: optional >> + Value type: <none> > > Isn't the type simply bool? > No, the property is bool but the actual value is void. But looking an extra time in the epapr I see that it's supposed to be "empty" - so will update. [...] >> +- bias-pull-up: >> + Usage: optional >> + Value type: <u32> (optional) >> + Definition: The specified pins should be configued as pull up. An >> + optional argument can be used to configure the strength. >> + Valid values are; as defined in >> + <dt-bindings/pinctrl/qcom,pm8xxx-gpio.h>: >> + 1: 30uA (PM8XXX_GPIO_PULL_UP_30) >> + 2: 1.5uA (PM8XXX_GPIO_PULL_UP_1P5) >> + 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) >> + 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) > > Hm, I don't know of the internal kernel API or so, but I'm thinking that > for the DT bindings, this definition should be generic in > Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt > and put in SI units like uA. > Totally agree with you; and this is already specified in pinctrl-binding.txt as being Ohm. So I first did a spin with the strength as a separate property, but as that because the only part that pinconf-generic didn't parse for me I merged it and wanted your comment on it. > So I would prefer: > > bias-pull-up = <30>; > Yeah, but that's the easy one ;) How do you say 1.5 or 31.5 and how do you differ that from 1.5 + 30 boot? > for 30 uA. Maybe we want nA even? I'm uncertain about the proper granularity > here :-/ > > Magic enumerators 1,2,3,4 doesn't seem so good, that seems more like it's > trying to match the magic value that is to be poked into a register or > something like that. > The stuff going into the hardware is a value 0-3 for pull up; so these values are "only" an enum with the additional benefit of saying "bias-pull-up;" results in 30uA pull up which is the most commonly used form (hence being optional). [...] >> +- drive-strength: >> + Usage: optional >> + Value type: <u32> >> + Definition: Selects the drive strength for the specified pins. Value >> + drive strengths are: >> + 0: no (PM8XXX_GPIO_STRENGTH_NO) >> + 1: high (PM8XXX_GPIO_STRENGTH_HIGH) >> + 2: medium (PM8XXX_GPIO_STRENGTH_MED) >> + 3: low (PM8XXX_GPIO_STRENGTH_LOW) > > I would really prefer to have these in mA, because the genric pinconf > bindings say they should be! SI units are so much more understandable. > This is all the information to be found in the available documentation and code. Maybe someone from Qualcomm can shed some light on it? [...] >> + >> + pm8921_gpio: gpio@150 { >> + compatible = "qcom,pm8921-gpio"; >> + reg = <0x150>; >> + interrupts = <192 1>, <193 1>, <194 1>, >> + <195 1>, <196 1>, <197 1>, >> + <198 1>, <199 1>, <200 1>, >> + <201 1>, <202 1>, <203 1>, >> + <204 1>, <205 1>, <206 1>, >> + <207 1>, <208 1>, <209 1>, >> + <210 1>, <211 1>, <212 1>, >> + <213 1>, <214 1>, <215 1>, >> + <216 1>, <217 1>, <218 1>, >> + <219 1>, <220 1>, <221 1>, >> + <222 1>, <223 1>, <224 1>, >> + <225 1>, <226 1>, <227 1>, >> + <228 1>, <229 1>, <230 1>, >> + <231 1>, <232 1>, <233 1>, >> + <234 1>, <235 1>; > > > So this looks a bit weird. But if I just get to understand the hardware > I guess it won't anymore. > > So there is an interrupt parent to which the IRQ lines from the PMIC > are routed back through external lines to IRQ offsets 192 thru 235? > The pm8921-core exposes 256 interrupts, the listed 44 interrupts here are what comes out of that. I was really reluctant to list all the interrupts, but I think it turned out nicer than any of my other attempts; like only providing a base and then relying on interrupts being consecutive. Suggestions on how this "should" be solved are welcome, as we have the same setup for the newer pmics (Ivan's patches) and the TLMM hardware (pinctrl-msm) supports using dedicated interrupts for certain gpio pins (instead of passing through the chain handler). Regards, Bjorn
On Wed, Jul 9, 2014 at 11:18 PM, Bjorn Andersson <bjorn@kryo.se> wrote: > On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson >> <bjorn.andersson@sonymobile.com> wrote: >>> +The following generic properties as defined in pinctrl-bindings.txt are valid >>> +to specify in a pin configuration subnode: >>> + >>> +- pins: >>> + Usage: required >>> + Value type: <string-array> >>> + Definition: List of gpio pins affected by the properties specified in >>> + this subnode. Valid pins are: >>> + gpio1-gpio6 for pm8018 >>> + gpio1-gpio12 for pm8038 >>> + gpio1-gpio40 for pm8058 >>> + gpio1-gpio38 for pm8917 >>> + gpio1-gpio44 for pm8921 >> >> I usually name pins with CAPITAL LETTERS so would be >> "GPIO1", "GPIO2" etc, lowercase may be confusing as these are >> names not functions or groups. > > I was hoping to be able to follow the pattern used in pinctrl-msm; can I say > something nice to have you agree on this? There's no difference between pins > and groups here. That's OK. >>> +- function: >>> + Usage: optional >>> + Value type: <string> >>> + Definition: Specify the alternative function to be configured for the >>> + specified pins. Valid values are: >>> + "normal", >>> + "paired", >>> + "func1", >>> + "func2", >>> + "dtest1", >>> + "dtest2", >>> + "dtest3", >>> + "dtest4" >> >> These are a bit ambigous, why doesn't the driver present functions that >> are more specific than "func1", "func2"? Or "dtest1"? > > I agree, unfortunately I have only seen traces of the actual function matrix; > for pm8xxx I have no documentation and for pm8x41 they are only listed as > func[1-2] and dtest[1-4]. > > Maybe if someone at Qualcomm could release such a list we could provide a > proper table instead. I guess Stephen Boyd can help us. (?) >> Isn't the type simply bool? >> > > No, the property is bool but the actual value is void. But looking an extra > time in the epapr I see that it's supposed to be "empty" - so will update. OK. >>> +- bias-pull-up: >>> + Usage: optional >>> + Value type: <u32> (optional) >>> + Definition: The specified pins should be configued as pull up. An >>> + optional argument can be used to configure the strength. >>> + Valid values are; as defined in >>> + <dt-bindings/pinctrl/qcom,pm8xxx-gpio.h>: >>> + 1: 30uA (PM8XXX_GPIO_PULL_UP_30) >>> + 2: 1.5uA (PM8XXX_GPIO_PULL_UP_1P5) >>> + 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) >>> + 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) >> >> Hm, I don't know of the internal kernel API or so, but I'm thinking that >> for the DT bindings, this definition should be generic in >> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt >> and put in SI units like uA. > > Totally agree with you; and this is already specified in pinctrl-binding.txt as > being Ohm. > > So I first did a spin with the strength as a separate property, but as that > because the only part that pinconf-generic didn't parse for me I merged it and > wanted your comment on it. Yeah. And thinking of it.... how can it be uA? It has to be Ohms... it's a pull up resistor thing after all. I suspect the uA value is just something like the maximum current drawn through the pullup given a certain voltage? >> So I would prefer: >> >> bias-pull-up = <30>; >> > > Yeah, but that's the easy one ;) > > How do you say 1.5 or 31.5 and how do you differ that from 1.5 + 30 boot? It needs to be set using Ohms. >> for 30 uA. Maybe we want nA even? I'm uncertain about the proper granularity >> here :-/ >> >> Magic enumerators 1,2,3,4 doesn't seem so good, that seems more like it's >> trying to match the magic value that is to be poked into a register or >> something like that. > > The stuff going into the hardware is a value 0-3 for pull up; so these values > are "only" an enum with the additional benefit of saying "bias-pull-up;" > results in 30uA pull up which is the most commonly used form (hence being > optional). What is the nominal voltage of these pins? GIven that you can figure out the Ohms. And I suspect it to be something very close to N times the resistance of a depleted transistor in this technology. >>> +- drive-strength: >>> + Usage: optional >>> + Value type: <u32> >>> + Definition: Selects the drive strength for the specified pins. Value >>> + drive strengths are: >>> + 0: no (PM8XXX_GPIO_STRENGTH_NO) >>> + 1: high (PM8XXX_GPIO_STRENGTH_HIGH) >>> + 2: medium (PM8XXX_GPIO_STRENGTH_MED) >>> + 3: low (PM8XXX_GPIO_STRENGTH_LOW) >> >> I would really prefer to have these in mA, because the genric pinconf >> bindings say they should be! SI units are so much more understandable. > > This is all the information to be found in the available documentation and > code. Maybe someone from Qualcomm can shed some light on it? Stephen? >>> + <234 1>, <235 1>; >> >> >> So this looks a bit weird. But if I just get to understand the hardware >> I guess it won't anymore. >> >> So there is an interrupt parent to which the IRQ lines from the PMIC >> are routed back through external lines to IRQ offsets 192 thru 235? > > The pm8921-core exposes 256 interrupts, the listed 44 interrupts here are what > comes out of that. I get it. It makes sense to handle all IRQs in the core rather than spawning yet another irqchip for the pin control driver. > I was really reluctant to list all the interrupts, but I think it turned out > nicer than any of my other attempts; like only providing a base and then > relying on interrupts being consecutive. I agree. Yours, Linus Walleij
On 07/10/14 02:53, Linus Walleij wrote: > On Wed, Jul 9, 2014 at 11:18 PM, Bjorn Andersson <bjorn@kryo.se> wrote: >> On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij <linus.walleij@linaro.org> wrote: >>> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson >>> <bjorn.andersson@sonymobile.com> wrote: >>> >>> +- function: >>> + Usage: optional >>> + Value type: <string> >>> + Definition: Specify the alternative function to be configured for the >>> + specified pins. Valid values are: >>> + "normal", >>> + "paired", >>> + "func1", >>> + "func2", >>> + "dtest1", >>> + "dtest2", >>> + "dtest3", >>> + "dtest4" >>> These are a bit ambigous, why doesn't the driver present functions that >>> are more specific than "func1", "func2"? Or "dtest1"? >> I agree, unfortunately I have only seen traces of the actual function matrix; >> for pm8xxx I have no documentation and for pm8x41 they are only listed as >> func[1-2] and dtest[1-4]. >> >> Maybe if someone at Qualcomm could release such a list we could provide a >> proper table instead. > I guess Stephen Boyd can help us. (?) Ok. "normal" is pretty much gpio mode, i.e. don't mux anything. "paired" is where we take the output of the gpio next to it and loop it back into this gpio (and vice versa). So gpio1 is paired with gpio2, gpio 3 is paired with gpio 4, etc. This allows us to make level translators by choosing different supply voltages for the paired gpios. "func1" and "func2" are used for muxing things internally. "dtest" is used to mux specific things out for testing purposes, not really used in any end-products but still useful while debugging. I can provide the function to pin mapping if necessary. There are lots of pmics. > >>>> +- bias-pull-up: >>>> + Usage: optional >>>> + Value type: <u32> (optional) >>>> + Definition: The specified pins should be configued as pull up. An >>>> + optional argument can be used to configure the strength. >>>> + Valid values are; as defined in >>>> + <dt-bindings/pinctrl/qcom,pm8xxx-gpio.h>: >>>> + 1: 30uA (PM8XXX_GPIO_PULL_UP_30) >>>> + 2: 1.5uA (PM8XXX_GPIO_PULL_UP_1P5) >>>> + 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) >>>> + 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) >>> Hm, I don't know of the internal kernel API or so, but I'm thinking that >>> for the DT bindings, this definition should be generic in >>> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt >>> and put in SI units like uA. >> Totally agree with you; and this is already specified in pinctrl-binding.txt as >> being Ohm. >> >> So I first did a spin with the strength as a separate property, but as that >> because the only part that pinconf-generic didn't parse for me I merged it and >> wanted your comment on it. > Yeah. And thinking of it.... how can it be uA? It has to be Ohms... it's a pull > up resistor thing after all. I suspect the uA value is just something like the > maximum current drawn through the pullup given a certain voltage? > >>> So I would prefer: >>> >>> bias-pull-up = <30>; >>> >> Yeah, but that's the easy one ;) >> >> How do you say 1.5 or 31.5 and how do you differ that from 1.5 + 30 boot? > It needs to be set using Ohms. > >>> for 30 uA. Maybe we want nA even? I'm uncertain about the proper granularity >>> here :-/ >>> >>> Magic enumerators 1,2,3,4 doesn't seem so good, that seems more like it's >>> trying to match the magic value that is to be poked into a register or >>> something like that. >> The stuff going into the hardware is a value 0-3 for pull up; so these values >> are "only" an enum with the additional benefit of saying "bias-pull-up;" >> results in 30uA pull up which is the most commonly used form (hence being >> optional). > What is the nominal voltage of these pins? GIven that you can figure > out the Ohms. And I suspect it to be something very close to N times > the resistance of a depleted transistor in this technology. I believe the nominal voltage changes depending on which supply you choose (power-source in this document). Basically the gpio can be connected to different regulators on the pmic so you can choose different voltages, i.e. 1.8V, 3.0V, 3.3V etc. Furthermore, some of the regulators you can choose have variable voltage, although it may not be variable enough to have much effect on this. So it would seem that the pull-up resistance would be directly affected by which power-source is chosen. Maybe we just shouldn't use the generic properties for this? BTW, I see that power-source has made a comeback. What are the units? Is that in mV? If it is I'm slightly concerned that we're not accurately describing the hardware in cases where the voltage can actually be different. And I worry about configurations where we may have the same power source muxed into the gpio twice from different places on the pmic. Sometimes we do this and actually need to choose the "right" power source even though they're technically running at the same voltage (one may be slightly cleaner signal or something). >>>> +- drive-strength: >>>> + Usage: optional >>>> + Value type: <u32> >>>> + Definition: Selects the drive strength for the specified pins. Value >>>> + drive strengths are: >>>> + 0: no (PM8XXX_GPIO_STRENGTH_NO) >>>> + 1: high (PM8XXX_GPIO_STRENGTH_HIGH) >>>> + 2: medium (PM8XXX_GPIO_STRENGTH_MED) >>>> + 3: low (PM8XXX_GPIO_STRENGTH_LOW) >>> I would really prefer to have these in mA, because the genric pinconf >>> bindings say they should be! SI units are so much more understandable. >> This is all the information to be found in the available documentation and >> code. Maybe someone from Qualcomm can shed some light on it? > Stephen? I've emailed the hardware engineers. I'm pretty sure this is the same story as the pull-up though. It varies depending on the input voltage. I hope to get more information soon.
On Wed, 2014-07-09 at 14:18 -0700, Bjorn Andersson wrote: > On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > > On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson > > <bjorn.andersson@sonymobile.com> wrote: > [...] > >> + > >> + pm8921_gpio: gpio@150 { > >> + compatible = "qcom,pm8921-gpio"; > >> + reg = <0x150>; > >> + interrupts = <192 1>, <193 1>, <194 1>, > >> + <195 1>, <196 1>, <197 1>, > >> + <198 1>, <199 1>, <200 1>, > >> + <201 1>, <202 1>, <203 1>, > >> + <204 1>, <205 1>, <206 1>, > >> + <207 1>, <208 1>, <209 1>, > >> + <210 1>, <211 1>, <212 1>, > >> + <213 1>, <214 1>, <215 1>, > >> + <216 1>, <217 1>, <218 1>, > >> + <219 1>, <220 1>, <221 1>, > >> + <222 1>, <223 1>, <224 1>, > >> + <225 1>, <226 1>, <227 1>, > >> + <228 1>, <229 1>, <230 1>, > >> + <231 1>, <232 1>, <233 1>, > >> + <234 1>, <235 1>; > > > > > > So this looks a bit weird. But if I just get to understand the hardware > > I guess it won't anymore. > > > > So there is an interrupt parent to which the IRQ lines from the PMIC > > are routed back through external lines to IRQ offsets 192 thru 235? > > > > The pm8921-core exposes 256 interrupts, the listed 44 interrupts here are what > comes out of that. > > I was really reluctant to list all the interrupts, but I think it turned out > nicer than any of my other attempts; like only providing a base and then > relying on interrupts being consecutive. > > Suggestions on how this "should" be solved are welcome, as we have the same > setup for the newer pmics (Ivan's patches) and the TLMM hardware (pinctrl-msm) > supports using dedicated interrupts for certain gpio pins (instead of passing > through the chain handler). This is something that is already known in the driver, numbers did not change at run time, right? Could we hard-code IRQ base in driver, like "ti,palmas-gpio" did? reg property is also not strictly required, but this is different story :-). Regards, Ivan
On Fri, 2014-07-11 at 18:56 -0700, Stephen Boyd wrote: > On 07/10/14 02:53, Linus Walleij wrote: > > On Wed, Jul 9, 2014 at 11:18 PM, Bjorn Andersson <bjorn@kryo.se> wrote: > >> On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > >>> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson > >>> <bjorn.andersson@sonymobile.com> wrote: > >>> > >>> +- function: > >>> + Usage: optional > >>> + Value type: <string> > >>> + Definition: Specify the alternative function to be configured for the > >>> + specified pins. Valid values are: > >>> + "normal", > >>> + "paired", > >>> + "func1", > >>> + "func2", > >>> + "dtest1", > >>> + "dtest2", > >>> + "dtest3", > >>> + "dtest4" > >>> These are a bit ambigous, why doesn't the driver present functions that > >>> are more specific than "func1", "func2"? Or "dtest1"? > >> I agree, unfortunately I have only seen traces of the actual function matrix; > >> for pm8xxx I have no documentation and for pm8x41 they are only listed as > >> func[1-2] and dtest[1-4]. > >> > >> Maybe if someone at Qualcomm could release such a list we could provide a > >> proper table instead. > > I guess Stephen Boyd can help us. (?) > > Ok. "normal" is pretty much gpio mode, i.e. don't mux anything. "paired" > is where we take the output of the gpio next to it and loop it back into > this gpio (and vice versa). So gpio1 is paired with gpio2, gpio 3 is > paired with gpio 4, etc. This allows us to make level translators by > choosing different supply voltages for the paired gpios. "func1" and > "func2" are used for muxing things internally. "dtest" is used to mux > specific things out for testing purposes, not really used in any > end-products but still useful while debugging. I can provide the > function to pin mapping if necessary. There are lots of pmics. Thank you Stephen. If understand it right, this is more like option for the pin when it is GPIO. Next generation of PMIC's have support for pin acting like analog-input/output and current sink. So I will like to keep "function" property for selecting one of the above functions. Choosing between "normal", "paired"... options in QPNP pinctrl driver is supported trough passing values, defined in DT header file, to "output-high" property. Please don't kill me :-). > > > > >>>> +- bias-pull-up: > >>>> + Usage: optional > >>>> + Value type: <u32> (optional) > >>>> + Definition: The specified pins should be configued as pull up. An > >>>> + optional argument can be used to configure the strength. > >>>> + Valid values are; as defined in > >>>> + <dt-bindings/pinctrl/qcom,pm8xxx-gpio.h>: > >>>> + 1: 30uA (PM8XXX_GPIO_PULL_UP_30) > >>>> + 2: 1.5uA (PM8XXX_GPIO_PULL_UP_1P5) > >>>> + 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) > >>>> + 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) > >>> Hm, I don't know of the internal kernel API or so, but I'm thinking that > >>> for the DT bindings, this definition should be generic in > >>> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt > >>> and put in SI units like uA. > >> Totally agree with you; and this is already specified in pinctrl-binding.txt as > >> being Ohm. > >> > >> So I first did a spin with the strength as a separate property, but as that > >> because the only part that pinconf-generic didn't parse for me I merged it and > >> wanted your comment on it. > > Yeah. And thinking of it.... how can it be uA? It has to be Ohms... it's a pull > > up resistor thing after all. I suspect the uA value is just something like the > > maximum current drawn through the pullup given a certain voltage? > > > >>> So I would prefer: > >>> > >>> bias-pull-up = <30>; > >>> > >> Yeah, but that's the easy one ;) > >> > >> How do you say 1.5 or 31.5 and how do you differ that from 1.5 + 30 boot? > > It needs to be set using Ohms. > > > >>> for 30 uA. Maybe we want nA even? I'm uncertain about the proper granularity > >>> here :-/ > >>> > >>> Magic enumerators 1,2,3,4 doesn't seem so good, that seems more like it's > >>> trying to match the magic value that is to be poked into a register or > >>> something like that. > >> The stuff going into the hardware is a value 0-3 for pull up; so these values > >> are "only" an enum with the additional benefit of saying "bias-pull-up;" > >> results in 30uA pull up which is the most commonly used form (hence being > >> optional). > > What is the nominal voltage of these pins? GIven that you can figure > > out the Ohms. And I suspect it to be something very close to N times > > the resistance of a depleted transistor in this technology. > > I believe the nominal voltage changes depending on which supply you > choose (power-source in this document). Basically the gpio can be > connected to different regulators on the pmic so you can choose > different voltages, i.e. 1.8V, 3.0V, 3.3V etc. Furthermore, some of the > regulators you can choose have variable voltage, although it may not be > variable enough to have much effect on this. So it would seem that the > pull-up resistance would be directly affected by which power-source is > chosen. Maybe we just shouldn't use the generic properties for this? +1 for custom property. "current-generator"? > > BTW, I see that power-source has made a comeback. What are the units? Documentation states it is "a custom format" :-). Regards, Ivan
On 07/14/14 06:58, Ivan T. Ivanov wrote: > On Fri, 2014-07-11 at 18:56 -0700, Stephen Boyd wrote: >> On 07/10/14 02:53, Linus Walleij wrote: >>> On Wed, Jul 9, 2014 at 11:18 PM, Bjorn Andersson <bjorn@kryo.se> wrote: >>>> On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij <linus.walleij@linaro.org> wrote: >>>>> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson >>>>> <bjorn.andersson@sonymobile.com> wrote: >>>>> >>>>> +- function: >>>>> + Usage: optional >>>>> + Value type: <string> >>>>> + Definition: Specify the alternative function to be configured for the >>>>> + specified pins. Valid values are: >>>>> + "normal", >>>>> + "paired", >>>>> + "func1", >>>>> + "func2", >>>>> + "dtest1", >>>>> + "dtest2", >>>>> + "dtest3", >>>>> + "dtest4" >>>>> These are a bit ambigous, why doesn't the driver present functions that >>>>> are more specific than "func1", "func2"? Or "dtest1"? >>>> I agree, unfortunately I have only seen traces of the actual function matrix; >>>> for pm8xxx I have no documentation and for pm8x41 they are only listed as >>>> func[1-2] and dtest[1-4]. >>>> >>>> Maybe if someone at Qualcomm could release such a list we could provide a >>>> proper table instead. >>> I guess Stephen Boyd can help us. (?) >> Ok. "normal" is pretty much gpio mode, i.e. don't mux anything. "paired" >> is where we take the output of the gpio next to it and loop it back into >> this gpio (and vice versa). So gpio1 is paired with gpio2, gpio 3 is >> paired with gpio 4, etc. This allows us to make level translators by >> choosing different supply voltages for the paired gpios. "func1" and >> "func2" are used for muxing things internally. "dtest" is used to mux >> specific things out for testing purposes, not really used in any >> end-products but still useful while debugging. I can provide the >> function to pin mapping if necessary. There are lots of pmics. > Thank you Stephen. If understand it right, this is more like option for > the pin when it is GPIO. Next generation of PMIC's have support for pin > acting like analog-input/output and current sink. Isn't this document only for the gpios? I think you're talking about the MPPs, which also exist on these generation of pmics. We should probably avoid mixing the two (gpios and mpps) in one binding because they're really different hardware. > So I will like > to keep "function" property for selecting one of the above functions. > Choosing between "normal", "paired"... options in QPNP pinctrl driver > is supported trough passing values, defined in DT header file, to > "output-high" property. Please don't kill me :-). Overloading output-high to choose the MPP mode doesn't seem to follow the generic pinconfig binding. Does output-high even take a value? Why can't we use the function property? >> BTW, I see that power-source has made a comeback. What are the units? > Documentation states it is "a custom format" :-). > > Ah, I was looking in the binding document. It looks like the code comment around PIN_CONFIG_POWER_SOURCE says custom format. It's concerning though. From what I can tell commit 5b81d55c4ccf (pinctrl: remove bindings for pinconf options needing more thought, 2013-06-25) removed this option along with slew-rate because they specifically didn't have any units associated with them. But then slew-rate came back in commit 8ba3f4d00078 (pinctrl: Adds slew-rate, input-enable/disable, 2013-12-11) even though it didn't have units and then power-source came back without units too. Linus, what's going on?
On Mon, 2014-07-14 at 14:20 -0700, Stephen Boyd wrote: > On 07/14/14 06:58, Ivan T. Ivanov wrote: > > On Fri, 2014-07-11 at 18:56 -0700, Stephen Boyd wrote: > >> On 07/10/14 02:53, Linus Walleij wrote: > >>> On Wed, Jul 9, 2014 at 11:18 PM, Bjorn Andersson <bjorn@kryo.se> wrote: > >>>> On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > >>>>> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson > >>>>> <bjorn.andersson@sonymobile.com> wrote: > >>>>> > >>>>> +- function: > >>>>> + Usage: optional > >>>>> + Value type: <string> > >>>>> + Definition: Specify the alternative function to be configured for the > >>>>> + specified pins. Valid values are: > >>>>> + "normal", > >>>>> + "paired", > >>>>> + "func1", > >>>>> + "func2", > >>>>> + "dtest1", > >>>>> + "dtest2", > >>>>> + "dtest3", > >>>>> + "dtest4" > >>>>> These are a bit ambigous, why doesn't the driver present functions that > >>>>> are more specific than "func1", "func2"? Or "dtest1"? > >>>> I agree, unfortunately I have only seen traces of the actual function matrix; > >>>> for pm8xxx I have no documentation and for pm8x41 they are only listed as > >>>> func[1-2] and dtest[1-4]. > >>>> > >>>> Maybe if someone at Qualcomm could release such a list we could provide a > >>>> proper table instead. > >>> I guess Stephen Boyd can help us. (?) > >> Ok. "normal" is pretty much gpio mode, i.e. don't mux anything. "paired" > >> is where we take the output of the gpio next to it and loop it back into > >> this gpio (and vice versa). So gpio1 is paired with gpio2, gpio 3 is > >> paired with gpio 4, etc. This allows us to make level translators by > >> choosing different supply voltages for the paired gpios. "func1" and > >> "func2" are used for muxing things internally. "dtest" is used to mux > >> specific things out for testing purposes, not really used in any > >> end-products but still useful while debugging. I can provide the > >> function to pin mapping if necessary. There are lots of pmics. > > Thank you Stephen. If understand it right, this is more like option for > > the pin when it is GPIO. Next generation of PMIC's have support for pin > > acting like analog-input/output and current sink. > > Isn't this document only for the gpios? I think you're talking about the > MPPs, which also exist on these generation of pmics. We should probably > avoid mixing the two (gpios and mpps) in one binding because they're > really different hardware. I don't know. For me "gpio" looks like function of the pin hardware. > > > So I will like > > to keep "function" property for selecting one of the above functions. > > Choosing between "normal", "paired"... options in QPNP pinctrl driver > > is supported trough passing values, defined in DT header file, to > > "output-high" property. Please don't kill me :-). > > Overloading output-high to choose the MPP mode doesn't seem to follow > the generic pinconfig binding. Does output-high even take a value? Why > can't we use the function property? No, no. using value of the output-high|low" is just to select "normal", "paired"... thing. Function selection is via "function" property. Currently QPNP support following functions "gpio", "mpp-ain", "mpp-aout", "mpp-cs". Regards, Ivan
On Mon, Jul 14, 2014 at 11:35 PM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > On Mon, 2014-07-14 at 14:20 -0700, Stephen Boyd wrote: [..] >> Isn't this document only for the gpios? I think you're talking about the >> MPPs, which also exist on these generation of pmics. We should probably >> avoid mixing the two (gpios and mpps) in one binding because they're >> really different hardware. > > I don't know. For me "gpio" looks like function of the pin hardware. > >> >> > So I will like >> > to keep "function" property for selecting one of the above functions. >> > Choosing between "normal", "paired"... options in QPNP pinctrl driver >> > is supported trough passing values, defined in DT header file, to >> > "output-high" property. Please don't kill me :-). >> >> Overloading output-high to choose the MPP mode doesn't seem to follow >> the generic pinconfig binding. Does output-high even take a value? Why >> can't we use the function property? > > No, no. using value of the output-high|low" is just to select > "normal", "paired"... thing. Function selection is via "function" > property. Currently QPNP support following functions "gpio", "mpp-ain", > "mpp-aout", "mpp-cs". > Hi Ivan, From your comment I presume that you don't have access to the documentation for these blocks. The pmic sports two types of pins; gpios and mpps (multi-purpose-pin). These are different hardware blocks; i.e. not a configuration thing. The gpios can be input, output or both and they can be configured as gpio, paired, function 1 or function 2 (+ some test modes). So here it makes sense to have the functions "gpio", "paired" and the valid function combinations. The mpps can be input, output or both; in either digital or analog mode. Or they can be a current sink. When configured as analog input you select which adc the pin should be routed to. Here it makes sense to have the functions "digital", "analog" and "current-sink" I think. Regards, Bjorn
On Tue, 2014-07-15 at 17:23 -0700, Bjorn Andersson wrote: > On Mon, Jul 14, 2014 at 11:35 PM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > > On Mon, 2014-07-14 at 14:20 -0700, Stephen Boyd wrote: > [..] > >> Isn't this document only for the gpios? I think you're talking about the > >> MPPs, which also exist on these generation of pmics. We should probably > >> avoid mixing the two (gpios and mpps) in one binding because they're > >> really different hardware. > > > > I don't know. For me "gpio" looks like function of the pin hardware. > > > >> > >> > So I will like > >> > to keep "function" property for selecting one of the above functions. > >> > Choosing between "normal", "paired"... options in QPNP pinctrl driver > >> > is supported trough passing values, defined in DT header file, to > >> > "output-high" property. Please don't kill me :-). > >> > >> Overloading output-high to choose the MPP mode doesn't seem to follow > >> the generic pinconfig binding. Does output-high even take a value? Why > >> can't we use the function property? > > > > No, no. using value of the output-high|low" is just to select > > "normal", "paired"... thing. Function selection is via "function" > > property. Currently QPNP support following functions "gpio", "mpp-ain", > > "mpp-aout", "mpp-cs". > > > > Hi Ivan, > > From your comment I presume that you don't have access to the > documentation for these blocks. > > The pmic sports two types of pins; gpios and mpps (multi-purpose-pin). > These are different hardware blocks; i.e. not a configuration thing. I am looking on GPIO's hardware blocks as stripped down MPP's. > > The gpios can be input, output or both and they can be configured as > gpio, paired, function 1 or function 2 (+ some test modes). So here it > makes sense to have the functions "gpio", "paired" and the valid > function combinations. I believe that MPP's also support these 'functions'. > > The mpps can be input, output or both; in either digital or analog > mode. Or they can be a current sink. When configured as analog input > you select which adc the pin should be routed to. Here it makes sense > to have the functions "digital", "analog" and "current-sink" I think. My understanding is that MPP's are supporting everything which GPIO's does, plus analog functionality. I don't want at the end MPP's functions to be something like: analog-normal, analog-paired, analog-function-1, analog-function-2, digital-normal, digital-paired... So better to leave normal/paired stuff as separate parameter (qcom,pair). Plain GPIO hardware will just support 'gpio' function, while MPP's will have 'gpio', 'analog-in', 'analog-out', 'current-sink' I am fine to split driver to two drivers (GPIO and MPP), which will make code a little more clean, but I am pretty sure there will be lot of duplication. Regards, Ivan
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt new file mode 100644 index 0000000..0035dd8 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt @@ -0,0 +1,230 @@ +Qualcomm PM8XXX GPIO block + +This binding describes the GPIO block(s) found in the 8xxx series of pmics from +Qualcomm. + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8018-gpio" + "qcom,pm8038-gpio" + "qcom,pm8058-gpio" + "qcom,pm8917-gpio" + "qcom,pm8921-gpio" + +- reg: + Usage: required + Value type: <u32> + Definition: Register base of the gpio block + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: Must contain an array of encoded interrupt specifiers for + each available gpio + +- gpio-controller: + Usage: required + Value type: <none> + Definition: Mark the device node as a GPIO controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: Must be 2; + the first cell will be used to define gpio number and the + second denotes the flags for this gpio + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin or a list of pins. This configuration can include the +mux function to select on those pin(s), and various pin configuration +parameters, s listed below. + + +SUBNODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio1-gpio6 for pm8018 + gpio1-gpio12 for pm8038 + gpio1-gpio40 for pm8058 + gpio1-gpio38 for pm8917 + gpio1-gpio44 for pm8921 + +- function: + Usage: optional + Value type: <string> + Definition: Specify the alternative function to be configured for the + specified pins. Valid values are: + "normal", + "paired", + "func1", + "func2", + "dtest1", + "dtest2", + "dtest3", + "dtest4" + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull down. + +- bias-pull-up: + Usage: optional + Value type: <u32> (optional) + Definition: The specified pins should be configued as pull up. An + optional argument can be used to configure the strength. + Valid values are; as defined in + <dt-bindings/pinctrl/qcom,pm8xxx-gpio.h>: + 1: 30uA (PM8XXX_GPIO_PULL_UP_30) + 2: 1.5uA (PM8XXX_GPIO_PULL_UP_1P5) + 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) + 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) + +- bias-high-impedance: + Usage: optional + Value type: <none> + Definition: The specified pins will put in high-Z mode and disabled. + +- input-enable: + Usage: optional + Value type: <none> + Definition: The specified pins are put in input mode. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + +- power-source: + Usage: optional + Value type: <u32> + Definition: Selects the power source for the specified pins. Valid + power sources are, as defined in + <dt-bindings/pinctrl/qcom,pm8xxx-gpio.h>: + 0: bb (PM8XXX_GPIO_VIN_BB) + valid for pm8038, pm8058, pm8917, pm8921 + 1: ldo2 (PM8XXX_GPIO_VIN_L2) + valid for pm8018, pm8038, pm8917,pm8921 + 2: ldo3 (PM8XXX_GPIO_VIN_L3) + valid for pm8038, pm8058, pm8917, pm8921 + 3: ldo4 (PM8XXX_GPIO_VIN_L4) + valid for pm8018, pm8917, pm8921 + 4: ldo5 (PM8XXX_GPIO_VIN_L5) + valid for pm8018, pm8058 + 5: ldo6 (PM8XXX_GPIO_VIN_L6) + valid for pm8018, pm8058 + 6: ldo7 (PM8XXX_GPIO_VIN_L7) + valid for pm8058 + 7: ldo8 (PM8XXX_GPIO_VIN_L8) + valid for pm8018 + 8: ldo11 (PM8XXX_GPIO_VIN_L11) + valid for pm8038 + 9: ldo14 (PM8XXX_GPIO_VIN_L14) + valid for pm8018 + 10: ldo15 (PM8XXX_GPIO_VIN_L15) + valid for pm8038, pm8917, pm8921 + 11: ldo17 (PM8XXX_GPIO_VIN_L17) + valid for pm8038, pm8917, pm8921 + 12: smps3 (PM8XXX_GPIO_VIN_S3) + valid for pm8018, pm8058 + 13: smps4 (PM8XXX_GPIO_VIN_S4) + valid for pm8921 + 14: vph (PM8XXX_GPIO_VIN_VPH) + valid for pm8018, pm8038, pm8058, pm8917 pm8921 + +- drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins. Value + drive strengths are: + 0: no (PM8XXX_GPIO_STRENGTH_NO) + 1: high (PM8XXX_GPIO_STRENGTH_HIGH) + 2: medium (PM8XXX_GPIO_STRENGTH_MED) + 3: low (PM8XXX_GPIO_STRENGTH_LOW) + +- drive-push-pull: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in push-pull mode. + +- drive-open-drain: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in open-drain mode. + + +Example: + + pm8921_gpio: gpio@150 { + compatible = "qcom,pm8921-gpio"; + reg = <0x150>; + interrupts = <192 1>, <193 1>, <194 1>, + <195 1>, <196 1>, <197 1>, + <198 1>, <199 1>, <200 1>, + <201 1>, <202 1>, <203 1>, + <204 1>, <205 1>, <206 1>, + <207 1>, <208 1>, <209 1>, + <210 1>, <211 1>, <212 1>, + <213 1>, <214 1>, <215 1>, + <216 1>, <217 1>, <218 1>, + <219 1>, <220 1>, <221 1>, + <222 1>, <223 1>, <224 1>, + <225 1>, <226 1>, <227 1>, + <228 1>, <229 1>, <230 1>, + <231 1>, <232 1>, <233 1>, + <234 1>, <235 1>; + + gpio-controller; + #gpio-cells = <2>; + + pm8921_gpio_keys: gpio-keys { + volume-keys { + pins = "gpio20", "gpio21"; + function = "normal"; + + input-enable; + bias-pull-up; + drive-push-pull; + drive-strength = <PM8XXX_GPIO_STRENGTH_NO>; + power-source = <PM8XXX_GPIO_VIN_S4>; + }; + }; + }; diff --git a/include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h b/include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h new file mode 100644 index 0000000..6b66fff --- /dev/null +++ b/include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h @@ -0,0 +1,34 @@ +/* + * This header provides constants for the pm8xxx gpio binding. + */ + +#ifndef _DT_BINDINGS_PINCTRL_QCOM_PM8XXX_GPIO_H +#define _DT_BINDINGS_PINCTRL_QCOM_PM8XXX_GPIO_H + +#define PM8XXX_GPIO_PULL_UP_30 1 +#define PM8XXX_GPIO_PULL_UP_1P5 2 +#define PM8XXX_GPIO_PULL_UP_31P5 3 +#define PM8XXX_GPIO_PULL_UP_1P5_30 4 + +#define PM8XXX_GPIO_VIN_BB 0 +#define PM8XXX_GPIO_VIN_L2 1 +#define PM8XXX_GPIO_VIN_L3 2 +#define PM8XXX_GPIO_VIN_L4 3 +#define PM8XXX_GPIO_VIN_L5 4 +#define PM8XXX_GPIO_VIN_L6 5 +#define PM8XXX_GPIO_VIN_L7 6 +#define PM8XXX_GPIO_VIN_L8 7 +#define PM8XXX_GPIO_VIN_L11 8 +#define PM8XXX_GPIO_VIN_L14 9 +#define PM8XXX_GPIO_VIN_L15 10 +#define PM8XXX_GPIO_VIN_L17 11 +#define PM8XXX_GPIO_VIN_S3 12 +#define PM8XXX_GPIO_VIN_S4 13 +#define PM8XXX_GPIO_VIN_VPH 14 + +#define PM8XXX_GPIO_STRENGTH_NO 0 +#define PM8XXX_GPIO_STRENGTH_HIGH 1 +#define PM8XXX_GPIO_STRENGTH_MED 2 +#define PM8XXX_GPIO_STRENGTH_LOW 3 + +#endif
This introduced the device tree bindings for the gpio block found in pm8018, pm8038, pm8058, pm8917 and pm8921 pmics from Qualcomm. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> --- .../bindings/pinctrl/qcom,pm8xxx-gpio.txt | 230 ++++++++++++++++++++ include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h | 34 +++ 2 files changed, 264 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt create mode 100644 include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h