[U-Boot] [PATCH] WIP: tegra: Use driver model for GPIO driver

[Simon Glass]

Hi Stephen,

On 5 May 2014 10:10, Stephen Warren <swarren at wwwdotorg.org> wrote:
>
> On 05/02/2014 10:25 PM, Simon Glass wrote:
> > Hi Stephen,
> >
> > On 2 May 2014 16:43, Stephen Warren <swarren at wwwdotorg.org> wrote:
> >> On 05/02/2014 02:51 PM, Simon Glass wrote:
> >>> This is an implementation of GPIOs for Tegra that uses driver model.
> >>> It is written for comment and need work and testing before it is ready
> >>> to use.
> >>>
> >>> Specific points for discussion:
> >>>
> >>> 1. I can't find much in the way of GPIO device tree bindings, so ended up
> >>> just creating the GPIO devices
> >>
> >> The binding is already defined in the Linux kernel at:
> >>
> >> Documentation/devicetree/bindings/gpio/gpio.txt
> >> Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt
> >>
> >> An example is in:
> >>
> >> arch/arm/boot/dts/tegra20.dtsi
> >
> > Yes but all the parameters are hard-coded in the driver, not in the
> > device tree. I ended up doing the same thing, as you probably noticed.
>
> To be honest, since I saw all the DT binding changes and mentions of
> "banks", I didn't look at the driver, since I assumed it'd have to be
> re-written to solve those issues first. If the driver doesn't actually
> use any of that stuff, then perhaps I should take another look at the patch.

Well...you could :-) I sent an updated and cleaned-up version that has
actually been tested.

>
>
> >>> 3. Driver model understand the concept of a bank of GPIOs, but this is
> >>> equivalent to 'port' in Tegra. So it is somewhat confusing. Need to think
> >>> about this.
> >>
> >> There's no need at all to expose the banks separately. This is purely an
> >> implementation detail of the internal register layout of the HW, and not
> >> something that anyone outside the GPIO driver need concern itself with.
> >> Tegra simply has N GPIOs numbered 0..n-1. Admittedly the GPIOs also have
> >> textual names derived from the banked register layout, but this has no
> >> practical consequence, and need not be represented anywhere.
> >>
> >> I would imagine this is true of any GPIO controller. Why does the driver
> >> model know/care about GPIO banks?
> >
> > For naming - A, B, C, etc. Each of these is considered a 'bank'. At
> > present each is a separate GPIO device, also. This will allow us to
> > support I2C extenders and other ways of adding GPIOs.
>
> I don't think individual GPIO controllers have to be broken down into
> banks in order for U-Boot to support multiple GPIO controllers. U-Boot
> should know that multiple controller instances exist. U-Boot shouldn't
> dictate the internal structure of each controller; if it wants to expose
> 1000 GPIOs in a flat naming space, that should be OK.
>
> Or, when you mentioned "bank", did you mean "HW module" or "GPIO
> expander chip" i.e. what the Linux kernel calls a struct gpio_chip,
> rather than a "bank" being a sub-division of a whole HW module or GPIO
> expander chip?

I suppose I mean a conceptual 'bank', such as is used to name GPIOs in
the datasheet. The current GPIO uclass implementation uses one device
per bank, which has the virtue of simplicity, and it's easy to use 'dm
tree' to see the available GPIO banks. But it remains to be seen
whether this fits best with actual SOCs.

Regards,
Simon