[PATCH 6/6] gpio: tegra: Parameterize the number of banks

[Stephen Warren]

Rob Herring wrote at Thursday, January 05, 2012 10:25 AM:
> On 01/04/2012 04:00 PM, Grant Likely wrote:
> > On Wed, Jan 4, 2012 at 1:00 PM, Stephen Warren <swarren at nvidia.com> wrote:
> >> Rob Herring wrote at Wednesday, January 04, 2012 12:54 PM:
> >>> On 01/04/2012 12:39 PM, Stephen Warren wrote:
> >>>> Tegra20's GPIO controller has 7 banks, and Tegra30's controller has 8
> >>>> banks. Allow the number of banks to be configured at run-time by the
> >>>> device tree.
> >> ...
> >>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt
> >> ...
> >>>>  Required properties:
> >>>>  - compatible : "nvidia,tegra20-gpio"
> >>>>  - reg : Physical base address and length of the controller's registers.
> >>>> +- nvidia,num-banks : The number of GPIO banks. This should be 7 for
> >>>> +  Tegra20 and 8 for Tegra30. This must match the number of interrupt
> >>>> +  specifiers in the interrupts property.
> >>>
> >>> You can determine the number of banks based on the compatible property
> >>> rather than needing an additional property.
> >>
> >> That's certainly possible.
> >>
> >> However, if say nvidia,tegraNNN-gpio has 9 banks, we then have to
> >> explicitly edit the driver to know that, whereas by using a property,
> >> we wouldn't have to change the driver at all to support a future GPIO
> >> controller. So, isn't it better to explicitly represent this in DT?
> >>
> >> Note that I have no idea how many GPIO banks our future chips will have,
> >> so this might not turn out to save any work at all, but perhaps.
> >
> > It's an engineering/design decision that requires taste and instinct.
> > Either approach is fine, you decide which one will be the best in the
> > long term.
> 
> Agreed. I'm really fine with it either way.
> 
> Trying to predict future h/w is a bit pointless IMO. H/w designers
> always find new ways to do things differently. i.MX family has gpio
> interrupts hooked up 3 different ways for example. How would you handle
> the case that the banks are sparsely implemented?
> 
> Is adding support for a different number of banks every couple of years
> really an issue? It's much more important to have properties for which
> change with every board.

Thinking about this some more, I'm tempted to rework this patch to remove
the extra DT property and just "detect" the number of banks based on the
length of the interrupts property, (well, actually the number of IRQ
resources that the platform device has) since each bank has its own
interrupt. Does anyone disagree with doing that?

-- 
nvpublic