Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1416637

Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF

From Rob Herring <robherring2@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF
Date 2016-06-07 23:10 +0200
Message-ID <rHwq6-7Ly-19@gated-at.bofh.it> (permalink)
References <rG3Tb-7Tx-11@gated-at.bofh.it> <rG3Tc-7Tx-29@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


+Mark R

On Fri, Jun 3, 2016 at 3:26 PM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
> In certain cases it makes sense to create cascaded GPIO which
> are not real GPIOs, merely point to the real backend GPIO chip.

In what cases? Make it clear what this is for. Connectors of course,
but are there any other use cases you have in mind.

> In order to support this, cascaded of_xlate lookup need to be
> performed.
>
> For example let's take a connector that we want to abstract
> having two GPIO pins from different GPIO controllers, connector
> pin #0 connected to gpioA controller with offset 10 and gpioB
> with 4.

A connector's GPIO number may or may not be related to connector pins.

> In pseudo DT form this is analogous to:
>
>         gpioA: gpioa@80000 {
>                 compatible = "foocorp,gpio";
>                 ...
>         };
>
>         gpioB: gpiob@80800 {
>                 compatible = "foocorp,gpio";
>                 ....
>         };
>
>         gpioC: controller_gpio {
>                 compatible = "cascaded-gpio";

This compatible is kind of meaningless. I'd expect this to be a
connector compatible.

>                 gpios = <&gpioA 10>, <&gpioB 5>;

As we discussed at ELC, I think this should be modeled after
interrupt-map property like this:

gpio-map = <0 0 &soc_gpio 10 0>, <1 0 &soc_gpio 5 0>;
gpio-map-mask = <0xff 0>;

This is more flexible, a known pattern, and allows remapping of flag cells.

Also, we will likely have interrupt capable GPIOs, so they are going
to need interrupt-map anyway.

Rob

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 0/2] gpio: of: Support cascaded GPIO Pantelis Antoniou <pantelis.antoniou@konsulko.com> - 2016-06-03 22:30 +0200
  [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF Pantelis Antoniou <pantelis.antoniou@konsulko.com> - 2016-06-03 22:30 +0200
    Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF Rob Herring <robherring2@gmail.com> - 2016-06-07 23:10 +0200
      Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF Pantelis Antoniou <pantelis.antoniou@konsulko.com> - 2016-06-08 15:50 +0200
        Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF Rob Herring <robherring2@gmail.com> - 2016-06-08 17:20 +0200
          Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF Pantelis Antoniou <pantelis.antoniou@konsulko.com> - 2016-06-08 17:40 +0200
  [PATCH 1/2] gpio: Remove const from gpiospec in of_xlate Pantelis Antoniou <pantelis.antoniou@konsulko.com> - 2016-06-03 22:30 +0200

csiph-web