Hi Stephen, On Mon, Dec 5, 2011 at 2:22 PM, Stephen Warren <swar...@nvidia.com> wrote: > 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.
Fair enough. I am wanting to create a way for more information to be provided about a GPIO so that it can be set up automatically ready for use (reduces code size). > >>>> +/* 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). Well maybe it was a mistake, but it seems painful for the user to translate GPIO numbers in this way. U-Boot's GPIO command takes a GPIO number, which starts at zero. > >> 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. Do you mean the fdt_gpio_state structure? I have not used u8 for any function calls and would not. This adds 3 bytes for every entry. What is the benefit? People get upset when we waste memory! Regards, Simon > > -- > nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot