All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn@kryo.se>
To: "Ivan T. Ivanov" <iivanov@mm-sol.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bjorn Andersson <bjorn.andersson@sonymobile.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Mark Brown <broonie@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH RESEND v2 1/4] pinctrl: Update Qualcomm pm8xxx GPIO parameters definitions
Date: Sun, 10 Aug 2014 22:40:36 -0700	[thread overview]
Message-ID: <CAJAp7OiaJBHCHFDO5AF_Dsd8NZE4RYp763V7sSRb7uH8StwuVw@mail.gmail.com> (raw)
In-Reply-To: <1407337366.2475.108.camel@iivanov-dev>

On Wed, Aug 6, 2014 at 8:02 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote:
> On Fri, 2014-07-25 at 18:15 +0300, Ivan T. Ivanov wrote:
>> On Thu, 2014-07-24 at 17:23 -0700, Stephen Boyd wrote:
>> > On 07/24/14 08:40, Linus Walleij wrote:
>> > > On Thu, Jul 24, 2014 at 1:47 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> > >
>> > >>> Please add these constants to the table of valid power-source values and use
>> > >>> something like I did to translate them to register values - it makes the DT
>> > >>> much more readable.
>> > >> The DT could be similarly readable if we had a bunch of #defines for the
>> > >> different VIN settings that resolved to the final register value for
>> > >> that pmic. Something like PM8921_GPIO1_14_VPH, PM8921_GPIO19_36_VPH,
>> > >> etc. There would be a lot of them, but then the driver could be really
>> > >> simple and just jam whatever value is in the DT into the register
>> > >> without having to bounce through a mapping table in software to figure
>> > >> out the register value.
>
> This is ok.
>

I'm not sure I think the "optimization" is worth the cluttered names
of these defines, but I will give it a spin and see how it looks!

>> If we did this for the functions also then I
>> > >> believe we achieve readability without requiring a bunch of drivers for
>> > >> each and every single pmic?
>

Either we have a table like the other pinctrl drivers, or we just go
with custom parsing where we shove the register value straight into
devicetree. Although the latter would reduce the number of mapping
tables we need in the kernel, it seems to not follow the general way
of doing things with pinctrl.

[...]
>
> Furthermore meaning of number 2 and 3, which represent PMIC GPIO Special
> Function 1 and 2 are not consistent across PMIC chips. For example KEYPD
> function in PM8038 is encoded with 3, but in PM8058 it is 2.
>
> I tend to agree with Bjorn that "function" property should be "normal",
> "paired", "func1", "func2","dtest1", "dtest2", "dtest3", "dtest4" and we
> can add new property "qcom,mode" which will select between digital/analog
> input/output.
>

Note that for GPIOs we have normal/gpio, paried and a set of functions
(if we ignore the dtest ones). And for MPPs we have digital and analog
as paired and unpaired. Input/output should be controlled with the
separate means already available (gpio api, output-{low,high}.

> In DT include file we can still have something like this:
>
> /* To be used with "function = <>" */
> #define QCOM_GPIO_FUNC_NORMAL           "normal"
> #define QCOM_GPIO_FUNC_PAIRED           "paired"
> #define QCOM_GPIO_FUNC_FUNC1            "func1"
> #define QCOM_GPIO_FUNC_FUNC2            "func2"
> ...
>
> #define PM8038_GPIO1_2_LPG_DRV          QCOM_GPIO_FUNC_FUNC1
> #define PM8038_GPIO3_5V_BOOST_EN        QCOM_GPIO_FUNC_FUNC1
> #define PM8038_GPIO4_SSBI_ALT_CLK       QCOM_GPIO_FUNC_FUNC1
> #define PM8038_GPIO5_6_EXT_REG_EN       QCOM_GPIO_FUNC_FUNC1
> #define PM8038_GPIO10_11_EXT_REG_EN     QCOM_GPIO_FUNC_FUNC1
> #define PM8038_GPIO6_7_CLK              QCOM_GPIO_FUNC_FUNC1
> #define PM8038_GPIO9_BAT_ALRM_OUT       QCOM_GPIO_FUNC_FUNC1
> #define PM8038_GPIO6_12_KYPD_DRV        QCOM_GPIO_FUNC_FUNC2
>
> #define PM8058_GPIO7_8_MP3_CLK          QCOM_GPIO_FUNC_FUNC1
> #define PM8058_GPIO7_8_BCLK_19P2MHZ     QCOM_GPIO_FUNC_FUNC2
> #define PM8058_GPIO9_26_KYPD_DRV        QCOM_GPIO_FUNC_FUNC1
> #define PM8058_GPIO21_23_UART_TX        QCOM_GPIO_FUNC_FUNC2
> #define PM8058_GPIO24_26_LPG_DRV        QCOM_GPIO_FUNC_FUNC2
> #define PM8058_GPIO33_BCLK_19P2MHZ      QCOM_GPIO_FUNC_FUNC1
> #define PM8058_GPIO34_35_MP3_CLK        QCOM_GPIO_FUNC_FUNC1
> #define PM8058_GPIO36_BCLK_19P2MHZ      QCOM_GPIO_FUNC_FUNC1
> #define PM8058_GPIO37_UPL_OUT           QCOM_GPIO_FUNC_FUNC1
> #define PM8058_GPIO37_UART_M_RX         QCOM_GPIO_FUNC_FUNC2
> #define PM8058_GPIO38_XO_SLEEP_CLK      QCOM_GPIO_FUNC_FUNC1
> #define PM8058_GPIO38_39_CLK_32KHZ      QCOM_GPIO_FUNC_FUNC2
> #define PM8058_GPIO39_MP3_CLK           QCOM_GPIO_FUNC_FUNC1
> #define PM8058_GPIO40_EXT_BB_EN         QCOM_GPIO_FUNC_FUNC1
>
> #define PM8917_GPIO9_18_KEYP_DRV        QCOM_GPIO_FUNC_FUNC1
> #define PM8917_GPIO20_BAT_ALRM_OUT      QCOM_GPIO_FUNC_FUNC1
> #define PM8917_GPIO21_23_UART_TX        QCOM_GPIO_FUNC_FUNC2
> #define PM8917_GPIO25_26_EXT_REG_EN     QCOM_GPIO_FUNC_FUNC1
> #define PM8917_GPIO37_38_XO_SLEEP_CLK   QCOM_GPIO_FUNC_FUNC1
> #define PM8917_GPIO37_38_MP3_CLK        QCOM_GPIO_FUNC_FUNC2
> ...

If we're going to maintain this "table" in the kernel then I would
greatly prefer that we just stick with the standard way of
representing it in the pinctrl drivers. My concern is still related to
me lacking the appropriate documentation to create these tables.

I introduced the necessary tables for pm8058 and pm8921 and it looks
reasonable. I'll try to finish it up tomorrow and send out a copy for
you to have a look.

Regards,
Bjorn

  reply	other threads:[~2014-08-11  5:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17 15:25 [PATCH v2 0/4] New Qualcomm PMIC pin controller drivers Ivan T. Ivanov
2014-07-17 15:25 ` [PATCH v2 1/4] pinctrl: Update Qualcomm PMXXX GPIO parameters definitions Ivan T. Ivanov
2014-07-17 15:25 ` [PATCH v2 2/4] pinctrl: qpnp: Qualcomm PMIC pin controller driver Ivan T. Ivanov
2014-07-21 11:13   ` kiran.padwal
2014-07-21 11:29   ` kiran.padwal
2014-07-21 11:29     ` kiran.padwal
     [not found]   ` <1405610748-7583-3-git-send-email-iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
2014-07-21 16:02     ` divya ojha
2014-07-21 16:02       ` divya ojha
2014-07-21 16:15       ` pramod gurav
2014-07-21 16:16       ` Ivan T. Ivanov
2014-07-23 15:27   ` Linus Walleij
2014-07-23 16:11     ` Ivan T. Ivanov
2014-07-26  1:43   ` David Collins
2014-07-28  8:39     ` Ivan T. Ivanov
2014-08-05  1:36       ` Stephen Boyd
     [not found]         ` <53E0350C.4020003-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-08-05 11:55           ` Ivan T. Ivanov
2014-08-05 11:55             ` Ivan T. Ivanov
2014-07-17 15:25 ` [PATCH v2 3/4] pinctrl: qcom: Add documentation for pinctrl-qpnp driver bindings Ivan T. Ivanov
2014-07-17 15:25 ` [PATCH v2 4/4] ARM: dts: qcom: Add PM8941 and PM8841 pinctrl nodes Ivan T. Ivanov
2014-07-17 19:41   ` [PATCH RESEND v2 1/4] pinctrl: Update Qualcomm pm8xxx GPIO parameters definitions Ivan T. Ivanov
2014-07-22 14:51     ` Ivan T. Ivanov
     [not found]     ` <1405626085-14069-1-git-send-email-iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
2014-07-22 21:46       ` Bjorn Andersson
2014-07-22 21:46         ` Bjorn Andersson
2014-07-23 12:47         ` Ivan T. Ivanov
2014-07-23 16:05           ` Ivan T. Ivanov
2014-07-23 16:05             ` Ivan T. Ivanov
2014-07-23 21:46             ` Stephen Boyd
2014-07-23 23:47         ` Stephen Boyd
2014-07-24 15:40           ` Linus Walleij
2014-07-25  0:23             ` Stephen Boyd
2014-07-25 11:29               ` Linus Walleij
2014-07-25 15:15               ` Ivan T. Ivanov
2014-08-06 15:02                 ` Ivan T. Ivanov
2014-08-11  5:40                   ` Bjorn Andersson [this message]
2014-07-23 12:47 ` [PATCH v2 0/4] New Qualcomm PMIC pin controller drivers 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=CAJAp7OiaJBHCHFDO5AF_Dsd8NZE4RYp763V7sSRb7uH8StwuVw@mail.gmail.com \
    --to=bjorn@kryo.se \
    --cc=bjorn.andersson@sonymobile.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=iivanov@mm-sol.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@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.