From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 11 May 2016 13:05:49 +0200 From: =?utf-8?Q?=C3=81lvaro_Fern=C3=A1ndez_Rojas?= Message-ID: In-Reply-To: <3359834.V76Y1cJiRU@debian64> References: <535f785bf6116c0fb6f46afbb77e6d4bd3ef5f60.1462543458.git.chunkeey@googlemail.com> <3359834.V76Y1cJiRU@debian64> Subject: Re: [PATCH v8 2/3] gpio: mmio: add DT support for memory-mapped GPIOs MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="57331219_643c9869_b59" To: Linus Walleij , Christian Lamparter Cc: "=?utf-8?Q?linux-gpio=40vger.kernel.org?=" , "=?utf-8?Q?devicetree=40vger.kernel.org?=" , "=?utf-8?Q?linux-kernel=40vger.kernel.org?=" , "=?utf-8?Q?linux-arm-kernel=40lists.infradead.org?=" , Kumar Gala , Alexander Shiyan , Ian Campbell , Mark Rutland , Pawel Moll , Rob Herring , Alexandre Courbot , Andy Shevchenko List-ID: --57331219_643c9869_b59 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello everyone, =46irst of all thanks Christian for persisting in adding generic device t= ree support for memory-mapped gpios. =46or the brcm63xx case we could probably do something like this: https://gist.github.com/Noltari/fd34aedafd427d25467697ec6799d15a Notice that I'm doing something similar to what's already done for non de= vice tree with basic-mmio-gpio vs basic-mmio-gpio-be: https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-generic.c= =23L634 P.S: excuse me for not using an interleaved reply, but I'm sending this f= rom my phone :) Regards, =C3=81lvaro. El 10 may 2016 21:55 +0200, Christian Lamparter, escribi=C3=B3: > On Tuesday, May 10, 2016 02:08:45 PM Linus Walleij wrote: > > On Sun, May 8, 2016 at 3:08 PM, Christian Lamparter > > wrote: > > =20 > > > =46rom: =C3=81lvaro =46ern=C3=A1ndez Rojas > > =20 > > > This patch adds support for defining memory-mapped GPIOs which > > > are compatible with the existing gpio-mmio interface. > > =20 > > Overall very nice, just waiting for the next version. > =20 > K, will deliver. I noticed that you sent a mail in which you stated > that you applied the dt binding already. Can you update your devel > branch on git.kernel.org's linux-gpio=3F Then, I'll simply rebase my > series and sent the remaining two patches. > (unless you tell me otherwise). > =20 > > > The first user for this binding is =22wd,mbl-gpio=22. > > =20 > > And that binding defines that we have a register named =22dat=22. > =20 > Yeah, I had to remove all non wd related bits. But since this > series was posted (over and over :D) on a public mailing-list > the original =22generic=22 linux-mmio binding is available for > everybody to perusal=5B0=5D and study. I think what we can make > would be something like a devicetree template out of it. This > way people can remove unused flags and regnames for their > compatible device tree binding. (But first: need to finish > that ppc-gpio.txt). > =20 > > > + if (of=5Fproperty=5Fread=5Fbool(dev->of=5Fnode, =22no-output=22))= > > =20 > > And then this too. > > =20 > > Do we want these generic MMIO bindings (dat, no-output) > > in a special document like > > Documentation/devicetree/bindings/gpio/gpio-mmio.txt=3F > > =20 > > Going forward=3F > Ah, I was thinking about Documentation/gpio... Since there's no > way it would go in the devicetree/bindings without having a compatible=3F= > (And there's technically none). As far as I know the problem here is no= t > that it would be impossible to do that (updating a .dts file is =22easy= =22...), > but updating .dtb to a tiny flash-rom on the device might not be. So we= > have to make every effort to preserve compatibility for those devices > (and old/incomplete/broken dtbs) as long as the device is supported. > =20 > About adding new device: > This will work in the following way: > 1. new drives will need to supply their hardware-specific devicetree > binding file to the dt maintainers (This =22vendor,device.txt=22 file > will be like the wd,mbl-gpio.txt - but modified for the hardware > (this is where the template would be handy) > =20 > 2. Make a one-liner patch which adds a compatible string to > gpio-mmio.c's bgpio=5Fof=5Fmatch table: > =20 > + =7B .compatible =3D =22vendor,device=22, .data =3D bgpio=5Fbasic=5Fmm= io=5Fparse=5Fdt =7D, > =20 > (Of course, not having parses for the =22ngpio=22 property and the flag= s like > big-endian, reg-output-reg,set, unreadable-reg-dir, ... properties from= > the get-go is sad, these can add back once a driver/binding needs it). > =20 > I think brcm63xx will be following shortly. So we can test the > procedure. > > This patch set mainly deals with refactorings, but in the > > long run we want to slim things down a bit and use standard > > bindings I think. > Well, to do that, I think we need to collect enough devices to > make it a real =22class=22 of devices first. > =20 > Regards, > Christian > =20 > =5B0=5D
Hello everyone,

=46irst of all thanks Christian for persisting in adding generic device t= ree support for memory-mapped gpios.

=46or the brcm63xx case we could probably do something like this:
https://gist.github.com/Noltari/fd34aedafd427d25467697ec6799d15a
Notice that I'm doing something similar to what's already done for non de= vice tree with basic-mmio-gpio vs basic-mmio-gpio-be:
https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-generic.c= =23L634

P.S: excuse me for not using an interleaved reply, but I'm sending this f= rom my phone :)

Regards,
=C3=81lvaro.


El 10 may 2016 21:55 +0200, Christian Lamparter <chunkeey=40googlemail= .com>, escribi=C3=B3:
On Tuesday, May 10, 2016 02:08:45 PM Linus = Walleij wrote:
On Sun, May 8, 2016 at 3:08 PM, Christian L= amparter
<chunkeey=40googlemail.com> wrote:

=46rom: =C3=81lvaro =46ern=C3=A1ndez Rojas = <noltari=40gmail.com

This patch adds support for defining memory-mapped GPIOs which
are compatible with the existing gpio-mmio interface.

Overall very nice, just waiting for the next version.

K, will deliver. I noticed that you sent a mail in which you stated
= that you applied the dt binding already. Can you update your devel
branch on git.kernel.org's linux-gpio=3F Then, I'll simply rebase my
series and sent the remaining two patches.
(unless you tell me otherwise).

The first user for this binding is =22wd,mb= l-gpio=22.

And that binding defines that we have a register named =22dat=22.

Yeah, I had to remove all non wd related bits. But since this
series was posted (over and over :D) on a public mailing-list
the original =22generic=22 linux-mmio binding is available for
everybody to perusal=5B0=5D and study. I think what we can make
would be something like a devicetree template out of it. This
way people can remove unused flags and regnames for their
compatible device tree binding. (But first: need to finish
that ppc-gpio.txt).

+ if (of=5Fproperty=5Fread=5Fbool(dev->o= f=5Fnode, =22no-output=22))

And then this too.

Do we want these generic MMIO bindings (dat, no-output)
in a special document like
Documentation/devicetree/bindings/gpio/gpio-mmio.txt=3F

Going forward=3F
Ah, I was thinking about Documentation/gpio... Since there's no
way it would go in the devicetree/bindings without having a compatible=3F=
(And there's technically none). As far as I know the problem here is not<= br /> that it would be impossible to do that (updating a .dts file is =22easy=22= ...),
but updating .dtb to a tiny flash-rom on the device might not be. So we have to make every effort to preserve compatibility for those devices
(and old/incomplete/broken dtbs) as long as the device is supported.

About adding new device:
This will work in the following way:
1. new drives will need to supply their hardware-specific devicetree
binding file to the dt maintainers (This =22vendor,device.txt=22 file
will be like the wd,mbl-gpio.txt - but modified for the hardware
(this is where the template would be handy)

2. Make a one-liner patch which adds a compatible string to
gpio-mmio.c's bgpio=5Fof=5Fmatch table:

+ =7B .compatible =3D =22vendor,device=22, .data =3D bgpio=5Fbasic=5Fmmio= =5Fparse=5Fdt =7D,

(Of course, not having parses for the =22ngpio=22 property and the flags = like
big-endian, reg-output-reg,set, unreadable-reg-dir, ... properties from the get-go is sad, these can add back once a driver/binding needs it).
I think brcm63xx will be following shortly. So we can test the
procedure.
This patch set mainly deals with refactorin= gs, but in the
long run we want to slim things down a bit and use standard
bindings I think.
Well, to do that, I think we need to collect enough devices to
make it a real =22class=22 of devices first.

Regards,
Christian

=5B0=5D <https://lkml.org/lkml/2016/4/28/921
--57331219_643c9869_b59--