On Mon, 2014-07-14 at 14:20 -0700, Stephen Boyd wrote:

On 07/14/14 06:58, Ivan T. Ivanov wrote:

quoted

On Fri, 2014-07-11 at 18:56 -0700, Stephen Boyd wrote:

quoted

On 07/10/14 02:53, Linus Walleij wrote:

quoted

On Wed, Jul 9, 2014 at 11:18 PM, Bjorn Andersson [off-list ref] wrote:

quoted

On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij [off-list ref] wrote:

quoted

On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson
[off-list ref] 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.

quoted

 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