[patch 1/2] Add dt_compat field to struct gpio_chip

[Grant Likely]

On Thu, Apr 7, 2011 at 1:41 PM, Domenico Andreoli <cavokz at gmail.com> wrote:
> On Thu, Apr 7, 2011 at 7:17 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>>
>> On Thu, Apr 07, 2011 at 06:39:30PM +0200, Domenico Andreoli wrote:
>> > From: Domenico Andreoli <cavokz at gmail.com>
>> >
>> > This new field allows easy creation of GPIO chips in base of struct arrays.
>> >
>> > Signed-off-by: Domenico Andreoli <cavokz at gmail.com>
>> >
>> > ---
>> >  drivers/of/gpio.c          |    3 +++
>> >  include/asm-generic/gpio.h |    1 +
>> >  2 files changed, 4 insertions(+)
>> >
>> > Index: b/drivers/of/gpio.c
>> > ===================================================================
>> > --- a/drivers/of/gpio.c       2011-04-07 18:19:20.000000000 +0200
>> > +++ b/drivers/of/gpio.c       2011-04-07 18:20:31.000000000 +0200
>> > @@ -212,6 +212,9 @@
>> >
>> >  void of_gpiochip_add(struct gpio_chip *chip)
>> >  {
>> > +     if ((!chip->of_node) && (chip->dt_compat))
>> > +             chip->of_node = of_find_compatible_node(NULL, NULL, chip->dt_compat);
>> > +
>>
>> Hi Domenico,
>
> Hi Grant,
>
>> From what I can tell, this patch attempts to adapt to the way that
>> arch/arm/plat-samsung/gpio.c registers gpios with the kernel.  Each
>> platform seems to have its own static table of gpio banks which are
>> registered without any regard to the Linux device model.  It works,
>> but it isn't really the way things should be done.
>
> About the independent models of the ARM platforms, I can't say
> anything. I only wanted to explore the DT concepts and import them on
> the s3c24xx. While this could look only as the latest individual
> attempt, the DT interface is not and cannot be of any harm if ARM
> deploys it a little more.
>
>> The design of gpiolib right now is such that the of_node pointer
>> should be known *before* of_gpiochip_add() gets called.  This is very
>> important because the code that registers the gpio is the only place
>> that can truly know which node is actually associated with the gpio.
>
> This explains why a so simple patch has never been proposed before.
>
>> To solve your problem, the best solution would be to rework
>> arch/arm/plat-samsung-gpio.c to properly use the driver model and
>> register platform_devices which can be attached to dt nodes.  This
>> change should probably be done anyway, even ignoring the dt needs, but
>> I'm not going to force you to make this change to get dt support added
>> for samsung gpios.
>
> Indeed my plan is to not rework it, not in the next future, not before
> I switched all its users to DT ;)
>
> I'd like to follow the path towards a pure dts platform definition so
> the next step would be to DT-fy something like the s3c
> sdi/sdhci/whatever, which already uses some GPIO. Then something else
> like audio or network and so on. I would be very glad to arrive sooner
> or later to a s3c24xx FDT.
>
>> Alternately, what you should do is make sure that the chip->of_node
>> pointer is correctly populated before calling gpiochip_add(), possibly
>> in s3c_gpiolib_add().
>
> I already restored it to the previous state, with .dt_compat in struct
> s3c_gpio_chip and the the call of of_find_compatible_node() in
> s3c_gpiolib_add(), this way it stays out of gpiolib.
>
>> Also, be careful about the way that 'compatible' is being used.
>> Remember that compatible describes the /interface/ to a device, but
>> not the /instance/.  Many systems have multiple instances of the same
>> device, and compatible doesn't provide any help for differentiating
>> between them.
>
> I needed some clarification here, I already suspected that my way to
> encode banks in the compatible property was somehow fishy. And I
> needed a working patch to get some attention before digging further..
> ;)
>
>> Typically, when trying to find a specific instance of a
>> device, it should be resolved with a property in the /aliases node, or
>> it should be matched up against the resolved base address of the
>> device.
>
> This is what I'll try next. This alone seems to imply the rework you
> said above, let's see.

It doesn't actually depend on the rework.  You already have the
register information in s3c gpio.  You could use the same compatible
value for all, and then add another comparison against the base
address to figure out exactly which one is the correct one.

g.