archive mirror
 help / color / mirror / Atom feed
From: Thomas Abraham <>
To: Tomasz Figa <>
Subject: Re: [PATCH v3 1/4] pinctrl: add samsung pinctrl and gpiolib driver
Date: Wed, 5 Sep 2012 20:49:09 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <k27lbg$hrj$>

On 5 September 2012 19:20, Tomasz Figa <> wrote:
> Hi Thomas,
> Thomas Abraham wrote:
>> Add a new device tree enabled pinctrl and gpiolib driver for Samsung
>> SoC's. This driver provides a common and extensible framework for all
>> Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This
>> driver supports only device tree based instantiation and hence can be
>> used only on those Samsung platforms that have device tree enabled.
>> This driver is split into two parts: the pinctrl interface and the gpiolib
>> interface. The pinctrl interface registers pinctrl devices with the
>> pinctrl subsystem and gpiolib interface registers gpio chips with the
>> gpiolib subsystem. The information about the pins, pin groups, pin
>> functions and gpio chips, which are SoC specific, are parsed from device
>> tree node.
>> Cc: Linus Walleij <>
>> Cc: Kukjin Kim <>
>> Signed-off-by: Thomas Abraham <>
> Does the driver provide any kind of compatibility with current gpiolib
> users?
> Let me show an example of what I mean. We have a fixed voltage regulator
> defined in device tree of an imaginary board
>         vemmc_reg: voltage-regulator@0 {
>                 compatible = "regulator-fixed";
>                 regulator-name = "VMEM_VDD_2.8V";
>                 regulator-min-microvolt = <2800000>;
>                 regulator-max-microvolt = <2800000>;
>                 gpio = <&gpk0 2 1 0 0>;
>                 enable-active-high;
>         };
> The gpio pin used to control status of the regulator is defined using the
> gpio property and regulator-fixed driver uses of_get_named_gpio to get the
> pin number from device tree.
> Is this kind of setup also valid when using your pinctrl driver?

Hi Tomasz,

It is possible to get the pin number using of_get_named_gpio()
function with the gpiolib support included in the Samsung pinctrl
driver. The following are the steps on how this can be done. Please
note that, the old Samsung gpio binding will change when we switch the
pinctrl driver. But that was inevitable.

1. The gpio binding will now follow the standard gpio binding.
    Which means, it will be something like

           uart@13800000 {
                         <the usual bindings here>
                         gpios = <&pinctrl_0 10 0>;

   Note that,

   A. First cell: the pin-controller instance is used as the phandle
(i.e &pinctrl_0).
   B. Second cell: the pin number __local__ to the pin controller instance.
   C. Third cell: Flags associated with the gpio pin (as per standard binding).

   The pin number specified in the second cell is local to the
pin-controller instance.

   For example, the Exynos4210 GPJ1[1] pin, which belongs to pinctrl instance 1,
   will have pin number (pin number local to pinctrl instance 1) as 10.

   That is because, the number of pins in GPJ0 is 8. So GPJ1[1] =
nr_pins(GPJ0) + 2
   = 8 + 2 = 10.

   Yes, I understand that this is hard to derive the pin number like
this and write
   in the dts(i) files, but while writing the pinctrl driver, there
were two thoughts.

   A. The pin numbers for all the pins included in a pinctrl instance
will be documented
        in the device tree binding documentation. So it can be easily looked up.

   B. How many instances of listing gpio number like this will ever be
needed for a
       board dts file. Not much, maybe atmost 10.

   Considering the two points above, it seemed okay to derive the pin
numbers for
   the gpio as listed in the above example.

2. The client driver can now lookup the pin number using

            gpio = of_get_gpio(dev->of_node);

    which returns the pin number in the linux gpio space.

So, it is possible to lookup the pin number using Samsung pinctrl driver.

But, I have missed adding the #gpio-cells property in the three
instances of the pinctrl driver. If you are trying this, please add

          #gpio-cells = <2>;

line in all the three instances of the pinctrl controller nodes. I
will send this change as a separate patch.


  reply	other threads:[~2012-09-05 15:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23 11:15 [PATCH v3 0/4] pinctrl: add support for samsung pinctrl driver Thomas Abraham
2012-08-23 11:15 ` [PATCH v3 1/4] pinctrl: add samsung pinctrl and gpiolib driver Thomas Abraham
2012-08-23 23:12   ` Stephen Warren
2012-08-24  4:25     ` Thomas Abraham
2012-09-03 11:14   ` Linus Walleij
2012-09-04 19:47     ` Thomas Abraham
2012-09-04 21:45       ` Kukjin Kim
2012-09-05  6:20         ` Thomas Abraham
2012-09-06 17:33           ` Stephen Warren
2012-09-06 22:03             ` Kukjin Kim
2012-09-05 13:50   ` Tomasz Figa
2012-09-05 15:19     ` Thomas Abraham [this message]
2012-08-23 11:15 ` [PATCH v3 2/4] pinctrl: add exynos4210 specific extensions for samsung pinctrl driver Thomas Abraham
2012-09-03 11:16   ` Linus Walleij
2012-08-23 11:15 ` [PATCH v3 3/4] gpio: exynos4: skip gpiolib registration if pinctrl driver is used Thomas Abraham
2012-08-23 11:15 ` [PATCH v3 4/4] ARM: EXYNOS: skip wakeup interrupt setup " Thomas Abraham
2012-09-03 11:17   ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).