Hello everyone,

First of all thanks Christian for persisting in adding generic device tree support for memory-mapped gpios.

For 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 device tree with basic-mmio-gpio vs basic-mmio-gpio-be:
https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-generic.c#L634

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

Regards,
Álvaro.


El 10 may 2016 21:55 +0200, Christian Lamparter[off-list ref], escribió:

On Tuesday, May 10, 2016 02:08:45 PM Linus Walleij wrote:

quoted

On Sun, May 8, 2016 at 3:08 PM, Christian Lamparter
[off-list ref]wrote:
 

quoted

From: Álvaro Fernández Rojas<noltari@gmail.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? Then, I'll simply rebase my
series and sent the remaining two patches.
(unless you tell me otherwise).
 

quoted

quoted

The first user for this binding is "wd,mbl-gpio".

 
And that binding defines that we have a register named "dat".

 
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 "generic" linux-mmio binding is available for
everybody to perusal[0] 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).
 

quoted

quoted

+ if (of_property_read_bool(dev->of_node, "no-output"))

 
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?
 
Going forward?

Ah, I was thinking about Documentation/gpio... Since there's no
way it would go in the devicetree/bindings without having a compatible?
(And there's technically none). As far as I know the problem here is not
that it would be impossible to do that (updating a .dts file is "easy"...),
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 "vendor,device.txt" 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_of_match table:
 
+ { .compatible = "vendor,device", .data = bgpio_basic_mmio_parse_dt },
 
(Of course, not having parses for the "ngpio" 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.

quoted

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 "class" of devices first.
 
Regards,
Christian
 
[0]<https://lkml.org/lkml/2016/4/28/921