On Tue, 2014-07-15 at 17:23 -0700, Bjorn Andersson wrote:

On Mon, Jul 14, 2014 at 11:35 PM, Ivan T. Ivanov [off-list ref] wrote:

quoted

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

[..]

quoted

quoted

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

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".

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