All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Povlsen <lars.povlsen@microchip.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Lars Povlsen <lars.povlsen@microchip.com>,
	Rob Herring <robh+dt@kernel.org>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH v5 1/3] dt-bindings: pinctrl: Add bindings for pinctrl-microchip-sgpio driver
Date: Fri, 9 Oct 2020 12:00:43 +0200	[thread overview]
Message-ID: <87d01ryb04.fsf@soft-dev15.microsemi.net> (raw)
In-Reply-To: <CACRpkdaFYoXFUuWow5s9TitrRDhMW=wiaxgfMcY6sQkYYgC-Lw@mail.gmail.com>


Linus Walleij writes:

> Hi Lars!
>
> This is overall looking fine. Except for the 3 cell business. I just can't
> wrap my head around why that is needed.
>
> On Thu, Oct 8, 2020 at 3:05 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
>
>> +      '#gpio-cells':
>> +        const: 3
>
> So at the very least needs a description making it crystal clear why each
> cell is needed, and used for since the standard bindings are not used.
>
> +      sgpio_in2: gpio@0 {
> +        reg = <0>;
> +        compatible = "microchip,sparx5-sgpio-bank";
> +        gpio-controller;
> +        #gpio-cells = <3>;
> +        ngpios = <96>;
> +      };
>
> So here reg = 0 and the out port has reg 1. Isn't that what you also put
> in the second cell of the GPIO phandle? Then why? The driver
> can very well just parse its own reg property and fill that in.

Linus,

NO! The second cell is the second dimension - NOT the direction. As I
wrote previously, the direction is now inherent from the handle, ie. the
"reg" value of the handle.

The hardware describe a "port" and a "bit index" addressing, where the
second cell in

  gpios = <&sgpio_in2 11 0 GPIO_OUT_LOW>;

is the "bit index" - not the "reg" from the phandle.

In the example above, note

  ngpios = <96>;

As the "port" is [0; 31], this defines "bit index" to be [0; 2], so the
(input) GPIO cells will be:

p0b0, p0b1, p0b2
...
p31b0, p31b1, p31b2 

being identical to 

<&sgpio_inX 0 0 GPIO_OUT_LOW>
<&sgpio_inX 0 1 GPIO_OUT_LOW>
<&sgpio_inX 0 2 GPIO_OUT_LOW>
...
<&sgpio_inX 31 0 GPIO_OUT_LOW>
<&sgpio_inX 31 1 GPIO_OUT_LOW>
<&sgpio_inX 31 2 GPIO_OUT_LOW>

('X' being the SGPIO controller instance).

So no, there *really* is a need for a 3-cell GPIO specifier (or whatever
its called).

Hope this is clearer now...

---Lars

>
> When you obtain a phandle like that:
>
> gpios = <&sgpio_in2 11 0 GPIO_OUT_LOW>;
>
> Isn't that 0 just duplicating the "reg"? Just parse reg when you set up
> your driver state and put it as variable in the state container for your
> driver state for this particular gpio_chip. No need to get it from
> the phandle.
>
> Yours,
> Linus Walleij

-- 
Lars Povlsen,
Microchip

WARNING: multiple messages have this Message-ID (diff)
From: Lars Povlsen <lars.povlsen@microchip.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Lars Povlsen <lars.povlsen@microchip.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 1/3] dt-bindings: pinctrl: Add bindings for pinctrl-microchip-sgpio driver
Date: Fri, 9 Oct 2020 12:00:43 +0200	[thread overview]
Message-ID: <87d01ryb04.fsf@soft-dev15.microsemi.net> (raw)
In-Reply-To: <CACRpkdaFYoXFUuWow5s9TitrRDhMW=wiaxgfMcY6sQkYYgC-Lw@mail.gmail.com>


Linus Walleij writes:

> Hi Lars!
>
> This is overall looking fine. Except for the 3 cell business. I just can't
> wrap my head around why that is needed.
>
> On Thu, Oct 8, 2020 at 3:05 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
>
>> +      '#gpio-cells':
>> +        const: 3
>
> So at the very least needs a description making it crystal clear why each
> cell is needed, and used for since the standard bindings are not used.
>
> +      sgpio_in2: gpio@0 {
> +        reg = <0>;
> +        compatible = "microchip,sparx5-sgpio-bank";
> +        gpio-controller;
> +        #gpio-cells = <3>;
> +        ngpios = <96>;
> +      };
>
> So here reg = 0 and the out port has reg 1. Isn't that what you also put
> in the second cell of the GPIO phandle? Then why? The driver
> can very well just parse its own reg property and fill that in.

Linus,

NO! The second cell is the second dimension - NOT the direction. As I
wrote previously, the direction is now inherent from the handle, ie. the
"reg" value of the handle.

The hardware describe a "port" and a "bit index" addressing, where the
second cell in

  gpios = <&sgpio_in2 11 0 GPIO_OUT_LOW>;

is the "bit index" - not the "reg" from the phandle.

In the example above, note

  ngpios = <96>;

As the "port" is [0; 31], this defines "bit index" to be [0; 2], so the
(input) GPIO cells will be:

p0b0, p0b1, p0b2
...
p31b0, p31b1, p31b2 

being identical to 

<&sgpio_inX 0 0 GPIO_OUT_LOW>
<&sgpio_inX 0 1 GPIO_OUT_LOW>
<&sgpio_inX 0 2 GPIO_OUT_LOW>
...
<&sgpio_inX 31 0 GPIO_OUT_LOW>
<&sgpio_inX 31 1 GPIO_OUT_LOW>
<&sgpio_inX 31 2 GPIO_OUT_LOW>

('X' being the SGPIO controller instance).

So no, there *really* is a need for a 3-cell GPIO specifier (or whatever
its called).

Hope this is clearer now...

---Lars

>
> When you obtain a phandle like that:
>
> gpios = <&sgpio_in2 11 0 GPIO_OUT_LOW>;
>
> Isn't that 0 just duplicating the "reg"? Just parse reg when you set up
> your driver state and put it as variable in the state container for your
> driver state for this particular gpio_chip. No need to get it from
> the phandle.
>
> Yours,
> Linus Walleij

-- 
Lars Povlsen,
Microchip

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-09 10:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08 13:05 [PATCH v5 0/3] pinctrl: Adding support for Microchip/Microsemi serial GPIO controller Lars Povlsen
2020-10-08 13:05 ` Lars Povlsen
2020-10-08 13:05 ` [PATCH v5 1/3] dt-bindings: pinctrl: Add bindings for pinctrl-microchip-sgpio driver Lars Povlsen
2020-10-08 13:05   ` Lars Povlsen
2020-10-09  9:44   ` Linus Walleij
2020-10-09  9:44     ` Linus Walleij
2020-10-09 10:00     ` Lars Povlsen [this message]
2020-10-09 10:00       ` Lars Povlsen
2020-10-13 13:36       ` Linus Walleij
2020-10-13 13:36         ` Linus Walleij
2020-10-13 14:39         ` Lars Povlsen
2020-10-13 14:39           ` Lars Povlsen
2020-10-12 18:55   ` Rob Herring
2020-10-12 18:55     ` Rob Herring
2020-10-08 13:05 ` [PATCH v5 2/3] pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for Microsemi Serial GPIO Lars Povlsen
2020-10-08 13:05   ` Lars Povlsen
2020-10-08 13:05 ` [PATCH v5 3/3] arm64: dts: sparx5: Add SGPIO devices Lars Povlsen
2020-10-08 13:05   ` Lars Povlsen

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=87d01ryb04.fsf@soft-dev15.microsemi.net \
    --to=lars.povlsen@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.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.