WIP: tegra: Use driver model for GPIO driver

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

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.

arch/arm/dts/tegra20.dtsi +0 -0

index 3805750..10065da 100644

Quoted 8 lines · Simon Glass

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

Quoted 5 lines

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?

Quoted 10 lines

arch/arm/dts/tegra20.dtsi +1 -0

index 3805750..10065da 100644
@@ -143,6 +143,148 @@
              interrupts = < 64 65 66 67 87 119 121 >;
              #gpio-cells = <2>;
              gpio-controller;
+             #address-cells = <1>;

arch/arm/dts/tegra20.dtsi line 152

Quoted 6 lines

arch/arm/dts/tegra20.dtsi +6 -0

+             #size-cells = <0>;
+             port at 0 {
+                     reg = <0>;
+                     compatible = "nvidia,tegra20-gpio-bank";
+                     gpio-bank-name = "a";
+             };

We definitely shouldn't add these port child nodes.

Hi Stephen,

Quoted 15 lines · Stephen Warren

Quoted 8 lines · Simon Glass

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

Quoted 3 lines

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.

Quoted 11 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 22 lines · Simon Glass

Hi Stephen,

Quoted 18 lines · Stephen Warren

Quoted 8 lines · Simon Glass

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

Quoted 2 lines

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.

Quoted 13 lines

Quoted 13 lines

Quoted 5 lines

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.

Quoted 6 lines

Quoted 2 lines

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?