From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 05 May 2014 10:10:41 -0600 Subject: [U-Boot] [PATCH] WIP: tegra: Use driver model for GPIO driver In-Reply-To: References: <1399063905-31123-1-git-send-email-sjg@chromium.org> <53641F79.5020809@wwwdotorg.org> Message-ID: <5367B801.4070901@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 05/02/2014 10:25 PM, Simon Glass wrote: > Hi Stephen, > > On 2 May 2014 16:43, Stephen Warren 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?