On 12/05/2011 02:56 PM, Simon Glass wrote: > Hi Stephen, > > On Mon, Dec 5, 2011 at 1:46 PM, Stephen Warren <swar...@nvidia.com> wrote: >> On 12/02/2011 07:11 PM, Simon Glass wrote: >>> This adds some support into fdtdec for reading GPIO definitions from >>> the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO >>> is of the form: >>> >>> gpio-function-name = <phandle gpio_num flags>; >>> >>> where: >>> >>> phandle is a pointer to the GPIO node >>> gpio_num is the number of the GPIO (0 to 223) >>> flags is some flags, proposed as follows: >>> >>> bit meaning >>> 0 0=input, 1=output >>> 1 for output only: inital value of output >>> 2 0=polarity normal, 1=active low (inverted) >> >> The meaning of the flags (and even whether there are any flags any if so >> how many cells there are to contain them) is defined by the GPIO >> controller's binding. It's not something that can be interpreted in >> isolation by a generic DT parsing function. See for example #gpio-cells >> in tegra20.dtsi's gpio node and kernel file >> Documentation/devicetree/bindings/gpio/gpio_nvidia.txt. > > I see this in my version: > > Required properties: > - compatible : "nvidia,tegra20-gpio" > - #gpio-cells : Should be two. The first cell is the pin number and the > second cell is used to specify optional parameters: > - bit 0 specifies polarity (0 for normal, 1 for inverted) > - gpio-controller : Marks the device node as a GPIO controller. > > so how do I go about adding the other two bits?
I don't think you would. Input vs. output and output value are set up by APIs such as gpio_direction_input/output based on what the driver wants to do with the GPIOs. >>> +/* For now we allow 224 GPIOs. We can extend this later if required */ >>> +enum { >>> + FDT_GPIO_NONE = 255, /* an invalid GPIO used to end our list */ >> >> Can't you use 0 for that? (the kernel currently uses -1, but it seems >> there's agreement that was a mistake). If you use 255, the number will >> have to keep getting bumped as more complex systems become supported. If >> not 0, perhaps U32_MAX or whatever the relevant ${type}_MAX is? > > But 0 is a valid GPIO isn't it? Well, it depends how you define your numbering scheme. It may well be! There are many ways of representing a GPIO: * GPIO n on a specific controller (of which there may be many). This is what DT GPIO bindings use. * A system-wide GPIO ID, in which case the numbering is "virtual" (e.g. a concatenation of the GPIOs on all the present controllers), and you can choose to start the first controller's GPIOs at 0, 1, 1000 etc., thus leaving -1, 0, -n..999 etc. as invalid GPIOs. This is what the Linux kernel's gpiolib uses (and some say this global numbering scheme was a mistake). > I currently use the max value available to the u8. We can change it at > will when we update the u8 type to u16 which is why I made it a > constant. include/asm-generic/gpio.h seems to use an int to represent a GPIO. I'd suggest these APIs do the same, rather than use a u8. -- nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot