Re: [PATCH 2/3] pinctrl: Device tree bindings for Qualcomm pm8xxx gpio block

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx> wrote:
> >>>> On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> >>>>> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson
> >>>>> <bjorn.andersson@xxxxxxxxxxxxxx> 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



--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux