From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
To: Bjorn Andersson <bjorn@kryo.se>
Cc: Mark Rutland <mark.rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Stephen Boyd <sboyd@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Bjorn Andersson <bjorn.andersson@sonymobile.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/3] pinctrl: Device tree bindings for Qualcomm pm8xxx gpio block
Date: Wed, 16 Jul 2014 11:18:14 +0300 [thread overview]
Message-ID: <1405498694.31919.20.camel@iivanov-dev> (raw)
In-Reply-To: <CAJAp7OjU=FFdGKHPqovz+qrEhDCZ3E=uOSAOFbgYyLE01C9cPg@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: iivanov@mm-sol.com (Ivan T. Ivanov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] pinctrl: Device tree bindings for Qualcomm pm8xxx gpio block
Date: Wed, 16 Jul 2014 11:18:14 +0300 [thread overview]
Message-ID: <1405498694.31919.20.camel@iivanov-dev> (raw)
In-Reply-To: <CAJAp7OjU=FFdGKHPqovz+qrEhDCZ3E=uOSAOFbgYyLE01C9cPg@mail.gmail.com>
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
next prev parent reply other threads:[~2014-07-16 8:18 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-08 1:26 [PATCH 0/3] Qualcomm pm8xxx gpio driver Bjorn Andersson
2014-07-08 1:26 ` Bjorn Andersson
2014-07-08 1:26 ` Bjorn Andersson
[not found] ` <1404782785-1824-1-git-send-email-bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
2014-07-08 1:26 ` [PATCH 1/3] mfd: pm8921: Expose pm8xxx_read_irq_status Bjorn Andersson
2014-07-08 1:26 ` Bjorn Andersson
2014-07-08 1:26 ` Bjorn Andersson
2014-07-08 23:20 ` Stephen Boyd
2014-07-08 23:20 ` Stephen Boyd
2014-07-08 23:43 ` Bjorn Andersson
2014-07-08 23:43 ` Bjorn Andersson
2014-07-09 7:24 ` Ivan T. Ivanov
2014-07-09 7:24 ` Ivan T. Ivanov
2014-07-09 7:59 ` Linus Walleij
2014-07-09 7:59 ` Linus Walleij
2014-07-09 14:13 ` Bjorn Andersson
2014-07-09 14:13 ` Bjorn Andersson
2014-07-08 1:26 ` [PATCH 2/3] pinctrl: Device tree bindings for Qualcomm pm8xxx gpio block Bjorn Andersson
2014-07-08 1:26 ` Bjorn Andersson
2014-07-08 1:26 ` Bjorn Andersson
2014-07-09 8:53 ` Linus Walleij
2014-07-09 8:53 ` Linus Walleij
2014-07-09 21:18 ` Bjorn Andersson
2014-07-09 21:18 ` Bjorn Andersson
2014-07-10 9:53 ` Linus Walleij
2014-07-10 9:53 ` Linus Walleij
2014-07-12 1:56 ` Stephen Boyd
2014-07-12 1:56 ` Stephen Boyd
2014-07-14 13:58 ` Ivan T. Ivanov
2014-07-14 13:58 ` Ivan T. Ivanov
2014-07-14 21:20 ` Stephen Boyd
2014-07-14 21:20 ` Stephen Boyd
2014-07-15 6:35 ` Ivan T. Ivanov
2014-07-15 6:35 ` Ivan T. Ivanov
2014-07-16 0:23 ` Bjorn Andersson
2014-07-16 0:23 ` Bjorn Andersson
2014-07-16 8:18 ` Ivan T. Ivanov [this message]
2014-07-16 8:18 ` Ivan T. Ivanov
2014-07-14 13:24 ` Ivan T. Ivanov
2014-07-14 13:24 ` Ivan T. Ivanov
2014-07-08 1:26 ` [PATCH 3/3] pinctrl: Introduce pinctrl driver for Qualcomm pm8xxx Bjorn Andersson
2014-07-08 1:26 ` Bjorn Andersson
2014-07-08 1:26 ` Bjorn Andersson
[not found] ` <1404782785-1824-4-git-send-email-bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
2014-07-09 9:32 ` Linus Walleij
2014-07-09 9:32 ` Linus Walleij
2014-07-09 9:32 ` Linus Walleij
2014-07-14 22:48 ` Bjorn Andersson
2014-07-14 22:48 ` Bjorn Andersson
2014-07-23 8:45 ` Linus Walleij
2014-07-23 8:45 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1405498694.31919.20.camel@iivanov-dev \
--to=iivanov@mm-sol.com \
--cc=bjorn.andersson@sonymobile.com \
--cc=bjorn@kryo.se \
--cc=devicetree@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.