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

[Stephen Warren]

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.

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