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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1405498694.31919.20.camel@iivanov-dev>
Date:	Wed, 16 Jul 2014 11:18:14 +0300
From:	"Ivan T. Ivanov" <iivanov@...sol.com>
To:	Bjorn Andersson <bjorn@...o.se>
Cc:	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/3] pinctrl: Device tree bindings for Qualcomm pm8xxx
 gpio block

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/