| Message ID | 1399306150-932-14-git-send-email-sjg@chromium.org |
|---|---|
| State | RFC |
| Headers | show |
On 05/05/2014 10:09 AM, Simon Glass wrote: > This is an implementation of GPIOs for Tegra that uses driver model. It has > been tested on trimslice and also using the new iotrace feature. > > The implementation uses a top-level GPIO device (which has no actual GPIOS). > Under this all the banks are created as separate GPIO devices. I don't think that dividing the GPIOs into banks is appropriate. While the textual naming of Tegra GPIOs is based on the bank concept, I think that division should only apply to the textual naming, and not any data structures or device registration, etc. In fact, I often refer to Tegra GPIOs using their integer ID rather than their name, and dividing the controller into separate banks probably technically disallows this, since there would be no architected guarantee that the numbering of the banks would be sequential. Contiguous numbering of all GPIOs within the controller is also useful for correlation with pinmux numbering of pins. ... > Since driver model is not yet available before relocation, or in SPL, a > special function is provided for seaboard's SPL code. Perhaps we should just remove that code from Seaboard, since sharing the UART/SPI pins really isn't a useful feature. Still, we will need to maintain some low-level APIs so that the SPL can initialize GPIOs at boot, since doing so is part of Tegra's HW-defined pinmux initialization mechanism. For reference, see the series I posted: https://www.mail-archive.com/u-boot@lists.denx.de/msg136607.html In particular: ARM: tegra: add GPIO initialization table function ARM: tegra: make use of GPIO init table on Jetson TK1 > diff --git a/drivers/gpio/tegra_gpio.c b/drivers/gpio/tegra_gpio.c > +struct tegra_gpio_platdata { > + struct gpio_ctlr_bank *bank; > + const char *port_name; /* Name of port, e.g. "B" */ > + int base_port; /* Port number for this port (0, 1,.., n-1) */ > +}; I'm not sure what "platdata" means. Would "tegra_gpio_bank" be a better name? Oh, looking later in the patch, this seems to be about passing data to probe(). It would be better to get rid of the bank concept, have a single device, and just pass the GPIO count or SoC type to probe. > +/* Information about each port at run-time */ > +struct tegra_port_info { > + char label[TEGRA_GPIOS_PER_PORT][GPIO_NAME_SIZE]; > + struct gpio_ctlr_bank *bank; > + int base_port; /* Port number for this port (0, 1,.., n-1) */ > +}; It seems odd to have two data-structures with Tegra-specific data related to a struct gpio_ctrl_bank. Perhaps these can be combined into one? > +#define GPIO_NUM(state, offset) \ > + (((state)->base_port * TEGRA_GPIOS_PER_PORT) + (offset)) It's not clear whether "state" is supposed to be a "tegra_gpio_platdata" or a "tegra_port_info". I guess the macro works with either, but that seems a bit dangerous. > /* Return config of pin 'gpio' as GPIO (1) or SFPIO (0) */ > +static int get_config(struct tegra_port_info *state, int offset) Hmm. I guess the name "state" for the GPIO_NUM() macro parameter comes from the fact that the functions in this file have a parameter named "state". That seems nasty; it'd be better to name that port_info so it represents that type it contains. Still, that's a pre-existing issue unrelated to this patch. That said, naming a macro parameter "state" and using it in functions that typically have a parameter named "state" seems dangerous. Perhaps prefix and suffix the macro parameter name with _ to make the distinction obvious - i.e.. _state_. That's typical good practice for macros. > +static int tegra_gpio_get_state(struct device *dev, unsigned int offset, > + char *buf, int bufsize) > + is_gpio = get_config(state, offset); /* GPIO, not SFPIO */ Typo in SFIO there. > + size = snprintf(buf, bufsize, "%s%d: ", > + uc_priv->bank_name ? uc_priv->bank_name : "", offset); > + buf += size; > + bufsize -= size; size can be larger than bufsize if the string would have overflowed. Do the later calls to snprintf() handle negative size arguments correctly? > +static char *gpio_port_name(int base_port) > { > + char *name, *s; > + > + name = malloc(3); It seems like this should be statically allocated (e.g. as part of *plat in gpio_tegra_bind() or something?). Still, if we stop splitting things into banks, we can completely get rid of this. > +static int gpio_tegra_bind(struct device *parent) > + /* > + * This driver does not make use of interrupts, other than to figure > + * out the number of GPIO banks > + */ > + if (!fdt_getprop(gd->fdt_blob, parent->of_offset, "interrupts", &len)) > + return -EINVAL; > + bank_count = len / 3 / sizeof(u32); > + ctlr = (struct gpio_ctlr *)fdtdec_get_addr(gd->fdt_blob, > + parent->of_offset, "reg"); It's dangerous to assume that #interrupt-cells of the GIC is 3. The GIC driver is the only thing that can define/parse GIC IRQ specifiers... > diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h > #define CONFIG_DM > +#define CONFIG_DM_GPIO > +#define CONFIG_CMD_DM I think the second of those lines should be part of patch 12/13 shouldn't it?
Hi Stephen, On 5 May 2014 11:29, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/05/2014 10:09 AM, Simon Glass wrote: >> This is an implementation of GPIOs for Tegra that uses driver model. It has >> been tested on trimslice and also using the new iotrace feature. >> >> The implementation uses a top-level GPIO device (which has no actual GPIOS). >> Under this all the banks are created as separate GPIO devices. > > I don't think that dividing the GPIOs into banks is appropriate. While > the textual naming of Tegra GPIOs is based on the bank concept, I think > that division should only apply to the textual naming, and not any data > structures or device registration, etc. In fact, I often refer to Tegra > GPIOs using their integer ID rather than their name, and dividing the > controller into separate banks probably technically disallows this, > since there would be no architected guarantee that the numbering of the > banks would be sequential. Contiguous numbering of all GPIOs within the > controller is also useful for correlation with pinmux numbering of pins. This is how the GPIO uclass works at present. Do you think that should change also? It would mean enhancing the uclass to support multiple GPIO bank names, with each having a number of GPIOs attached. This is the sort of complexity that adds to code size. On the other hand it's something that we may want to do anyway as more SOC's GPIO drivers are converted. An alternative might be to leave most the Tegra driver (the static functions at the top) using an absolute GPIO number, but have a separate device for each bank. That would be easy enough and would not add to code. > > ... >> Since driver model is not yet available before relocation, or in SPL, a >> special function is provided for seaboard's SPL code. > > Perhaps we should just remove that code from Seaboard, since sharing the > UART/SPI pins really isn't a useful feature. saveenv to SPI won't work without it though. > > Still, we will need to maintain some low-level APIs so that the SPL can > initialize GPIOs at boot, since doing so is part of Tegra's HW-defined > pinmux initialization mechanism. For reference, see the series I posted: > > https://www.mail-archive.com/u-boot@lists.denx.de/msg136607.html > > In particular: > ARM: tegra: add GPIO initialization table function > ARM: tegra: make use of GPIO init table on Jetson TK1 OK. > >> diff --git a/drivers/gpio/tegra_gpio.c b/drivers/gpio/tegra_gpio.c > >> +struct tegra_gpio_platdata { >> + struct gpio_ctlr_bank *bank; >> + const char *port_name; /* Name of port, e.g. "B" */ >> + int base_port; /* Port number for this port (0, 1,.., n-1) */ >> +}; > > I'm not sure what "platdata" means. Would "tegra_gpio_bank" be a better > name? > > Oh, looking later in the patch, this seems to be about passing data to > probe(). It would be better to get rid of the bank concept, have a > single device, and just pass the GPIO count or SoC type to probe. Probably better to improve the name - I wanted to distinguish between platform data and run-time data. > >> +/* Information about each port at run-time */ >> +struct tegra_port_info { >> + char label[TEGRA_GPIOS_PER_PORT][GPIO_NAME_SIZE]; >> + struct gpio_ctlr_bank *bank; >> + int base_port; /* Port number for this port (0, 1,.., n-1) */ >> +}; > > It seems odd to have two data-structures with Tegra-specific data > related to a struct gpio_ctrl_bank. Perhaps these can be combined into one? One is static platform data (not supposed to be changed). It is created before the device is bound. The other is the run-time information, that only exists when the device is active / probed. > >> +#define GPIO_NUM(state, offset) \ >> + (((state)->base_port * TEGRA_GPIOS_PER_PORT) + (offset)) > > It's not clear whether "state" is supposed to be a "tegra_gpio_platdata" > or a "tegra_port_info". I guess the macro works with either, but that > seems a bit dangerous. Should probably be a function. > >> /* Return config of pin 'gpio' as GPIO (1) or SFPIO (0) */ >> +static int get_config(struct tegra_port_info *state, int offset) > > Hmm. I guess the name "state" for the GPIO_NUM() macro parameter comes > from the fact that the functions in this file have a parameter named > "state". That seems nasty; it'd be better to name that port_info so it > represents that type it contains. Still, that's a pre-existing issue > unrelated to this patch. > > That said, naming a macro parameter "state" and using it in functions > that typically have a parameter named "state" seems dangerous. Perhaps > prefix and suffix the macro parameter name with _ to make the > distinction obvious - i.e.. _state_. That's typical good practice for > macros. OK > >> +static int tegra_gpio_get_state(struct device *dev, unsigned int offset, >> + char *buf, int bufsize) > >> + is_gpio = get_config(state, offset); /* GPIO, not SFPIO */ > > Typo in SFIO there. > >> + size = snprintf(buf, bufsize, "%s%d: ", >> + uc_priv->bank_name ? uc_priv->bank_name : "", offset); >> + buf += size; >> + bufsize -= size; > > size can be larger than bufsize if the string would have overflowed. Do > the later calls to snprintf() handle negative size arguments correctly? Should do - I checked that when I upstreamed that code. > >> +static char *gpio_port_name(int base_port) >> { >> + char *name, *s; >> + >> + name = malloc(3); > > It seems like this should be statically allocated (e.g. as part of *plat > in gpio_tegra_bind() or something?). Still, if we stop splitting things > into banks, we can completely get rid of this. No, we still need the name so that 'gpio input T3' works corrrectly. > >> +static int gpio_tegra_bind(struct device *parent) > >> + /* >> + * This driver does not make use of interrupts, other than to figure >> + * out the number of GPIO banks >> + */ >> + if (!fdt_getprop(gd->fdt_blob, parent->of_offset, "interrupts", &len)) >> + return -EINVAL; >> + bank_count = len / 3 / sizeof(u32); >> + ctlr = (struct gpio_ctlr *)fdtdec_get_addr(gd->fdt_blob, >> + parent->of_offset, "reg"); > > It's dangerous to assume that #interrupt-cells of the GIC is 3. The GIC > driver is the only thing that can define/parse GIC IRQ specifiers... Which GIC driver would that be? :-) > >> diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h > >> #define CONFIG_DM >> +#define CONFIG_DM_GPIO >> +#define CONFIG_CMD_DM > > I think the second of those lines should be part of patch 12/13 > shouldn't it? > Yes, will move it. Thanks for looking at this. BTW if we decide to change the bank approach later I'm happy to adjust this driver. Regards, Simon
On 05/05/2014 01:53 PM, Simon Glass wrote: > Hi Stephen, > > On 5 May 2014 11:29, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 05/05/2014 10:09 AM, Simon Glass wrote: >>> This is an implementation of GPIOs for Tegra that uses driver model. It has >>> been tested on trimslice and also using the new iotrace feature. >>> >>> The implementation uses a top-level GPIO device (which has no actual GPIOS). >>> Under this all the banks are created as separate GPIO devices. >> >> I don't think that dividing the GPIOs into banks is appropriate. While >> the textual naming of Tegra GPIOs is based on the bank concept, I think >> that division should only apply to the textual naming, and not any data >> structures or device registration, etc. In fact, I often refer to Tegra >> GPIOs using their integer ID rather than their name, and dividing the >> controller into separate banks probably technically disallows this, >> since there would be no architected guarantee that the numbering of the >> banks would be sequential. Contiguous numbering of all GPIOs within the >> controller is also useful for correlation with pinmux numbering of pins. > > This is how the GPIO uclass works at present. Do you think that should > change also? It would mean enhancing the uclass to support multiple > GPIO bank names, with each having a number of GPIOs attached. This is > the sort of complexity that adds to code size. On the other hand it's > something that we may want to do anyway as more SOC's GPIO drivers are > converted. Surely this means simplifying the core to completely remove any concept of GPIO banks. I really don't see any need for a 2-level hierarchy. Just have one struct/object/... that represents a GPIO controller/module/chip/... Each of those has N GPIOs numbered 0..N. Linux has managed to get away without a 2-level controller/bank approach, so there's certainly evidence it works in practice. >> ... >>> Since driver model is not yet available before relocation, or in SPL, a >>> special function is provided for seaboard's SPL code. >> >> Perhaps we should just remove that code from Seaboard, since sharing the >> UART/SPI pins really isn't a useful feature. > > saveenv to SPI won't work without it though. The environment is stored in eMMC. SPI simply doesn't work sanely on Seaboard, and we should just rip out any support for it at all. On Seaboard itself, people can just set the jumpers to ignore SPI completely. On Springbank, something similar can be done with the pull-up/down resistors. I've been using my Springbank without any of the resistors present, while disables SPI completely, for years without issue... >>> +static char *gpio_port_name(int base_port) >>> { >>> + char *name, *s; >>> + >>> + name = malloc(3); >> >> It seems like this should be statically allocated (e.g. as part of *plat >> in gpio_tegra_bind() or something?). Still, if we stop splitting things >> into banks, we can completely get rid of this. > > No, we still need the name so that 'gpio input T3' works corrrectly. Why do we need GPIO names at all? "gpio input 155" works just as well, and to be honest is often a lot more convenient that trying to maps things back to a name.
HI Stephen, On 5 May 2014 15:14, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/05/2014 01:53 PM, Simon Glass wrote: >> Hi Stephen, >> >> On 5 May 2014 11:29, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> On 05/05/2014 10:09 AM, Simon Glass wrote: >>>> This is an implementation of GPIOs for Tegra that uses driver model. It has >>>> been tested on trimslice and also using the new iotrace feature. >>>> >>>> The implementation uses a top-level GPIO device (which has no actual GPIOS). >>>> Under this all the banks are created as separate GPIO devices. >>> >>> I don't think that dividing the GPIOs into banks is appropriate. While >>> the textual naming of Tegra GPIOs is based on the bank concept, I think >>> that division should only apply to the textual naming, and not any data >>> structures or device registration, etc. In fact, I often refer to Tegra >>> GPIOs using their integer ID rather than their name, and dividing the >>> controller into separate banks probably technically disallows this, >>> since there would be no architected guarantee that the numbering of the >>> banks would be sequential. Contiguous numbering of all GPIOs within the >>> controller is also useful for correlation with pinmux numbering of pins. >> >> This is how the GPIO uclass works at present. Do you think that should >> change also? It would mean enhancing the uclass to support multiple >> GPIO bank names, with each having a number of GPIOs attached. This is >> the sort of complexity that adds to code size. On the other hand it's >> something that we may want to do anyway as more SOC's GPIO drivers are >> converted. > > Surely this means simplifying the core to completely remove any concept > of GPIO banks. I really don't see any need for a 2-level hierarchy. Just > have one struct/object/... that represents a GPIO > controller/module/chip/... Each of those has N GPIOs numbered 0..N. > Linux has managed to get away without a 2-level controller/bank > approach, so there's certainly evidence it works in practice. I think you have it backwards...the current implementation has a single level of hierarchy. Each driver handles one bank (or 'port' in the case of Tegra). What you are talking about is having a single driver handle multiple banks, thus requiring that the driver have a second level to deal with banks, over and above the device. We might end up with that, but I would prefer to move to it when we have evidence that it is a general need. > >>> ... >>>> Since driver model is not yet available before relocation, or in SPL, a >>>> special function is provided for seaboard's SPL code. >>> >>> Perhaps we should just remove that code from Seaboard, since sharing the >>> UART/SPI pins really isn't a useful feature. >> >> saveenv to SPI won't work without it though. > > The environment is stored in eMMC. > > SPI simply doesn't work sanely on Seaboard, and we should just rip out > any support for it at all. On Seaboard itself, people can just set the > jumpers to ignore SPI completely. On Springbank, something similar can > be done with the pull-up/down resistors. I've been using my Springbank > without any of the resistors present, while disables SPI completely, for > years without issue... OK, how about you submit a patch to do that, and then I can drop my special case (or maybe not if your other patch goes in)? > >>>> +static char *gpio_port_name(int base_port) >>>> { >>>> + char *name, *s; >>>> + >>>> + name = malloc(3); >>> >>> It seems like this should be statically allocated (e.g. as part of *plat >>> in gpio_tegra_bind() or something?). Still, if we stop splitting things >>> into banks, we can completely get rid of this. >> >> No, we still need the name so that 'gpio input T3' works corrrectly. > > Why do we need GPIO names at all? "gpio input 155" works just as well, > and to be honest is often a lot more convenient that trying to maps > things back to a name. Eh? We need to support named GPIOs in U-Boot. 155 is a meaningless number which drivers people back and forth to the datasheets, their calculators, a long table, etc. Even the Tegra device tree has moved away from numbers to GPIO names, I notice. Regards, Simon
On 05/05/2014 03:30 PM, Simon Glass wrote: ... > I think you have it backwards...the current implementation has a > single level of hierarchy. Each driver handles one bank (or 'port' in > the case of Tegra). What you are talking about is having a single > driver handle multiple banks, thus requiring that the driver have a > second level to deal with banks, over and above the device. We might > end up with that, but I would prefer to move to it when we have > evidence that it is a general need. Sigh. This is getting silly. All the APIs in SW need to just take a GPIO ID in the flat range 0..N (N==223 for Tegra20) and deal with it. Anything that expose banks anywhere, either as a parameter to public functions exported from the GPIO controller driver, or as the existence of separate drivers for separate banks, or as a command-line argument that the user sees, or ..., whether it be the U-Boot GPIO core or the Tegra GPIO driver itself that causes this, is just pointless. Please take a look at what the Linux driver does, and just model that. It's very trivial. The following is the entire implementation of gpio_set(): > // helper macros used by all register accesses: > #define GPIO_BANK(x) ((x) >> 5) > #define GPIO_PORT(x) (((x) >> 3) & 0x3) > #define GPIO_BIT(x) ((x) & 0x7) > > #define GPIO_REG(x) (GPIO_BANK(x) * tegra_gpio_bank_stride + \ > GPIO_PORT(x) * 4) > > // one define per register > #define GPIO_MSK_OUT(x) (GPIO_REG(x) + tegra_gpio_upper_offset + 0x20) > > // helper used by a lot of set/clear functions > static void tegra_gpio_mask_write(u32 reg, int gpio, int value) > { > u32 val; > > val = 0x100 << GPIO_BIT(gpio); > if (value) > val |= 1 << GPIO_BIT(gpio); > tegra_gpio_writel(val, reg); > } > > static void tegra_gpio_set(struct gpio_chip *chip, unsigned offset, int value) > { > tegra_gpio_mask_write(GPIO_MSK_OUT(offset), offset, value); > } i.e. a single register write with a calculated register address, using just a few shifts/masks. >>>> It seems like this should be statically allocated (e.g. as part of *plat >>>> in gpio_tegra_bind() or something?). Still, if we stop splitting things >>>> into banks, we can completely get rid of this. >>> >>> No, we still need the name so that 'gpio input T3' works corrrectly. >> >> Why do we need GPIO names at all? "gpio input 155" works just as well, >> and to be honest is often a lot more convenient that trying to maps >> things back to a name. > > Eh? We need to support named GPIOs in U-Boot. 155 is a meaningless > number which drivers people back and forth to the datasheets, their > calculators, a long table, etc. Even the Tegra device tree has moved > away from numbers to GPIO names, I notice. The GPIO names are meaningless. I say this because all the Tegra schematics (and documentation that drives them) use the pin/pad name, which is almost always entirely different from the GPIO name. You have to map the pin name back to either the GPIO name or ID using a lookup table (such as the kernel's drivers/pinctrl/pinctrl-tegra20.c). Given the need for a lookup table, we should just use the simpler GPIO ID and not worry about GPIO names. There's no point screwing around with text names when we can just use simple numbers. In DT, GPIOs are specified by integer ID too. Admittedly we have macros that calculate those IDs from the bank/port/offset, but that was probably a mistake, since the bank/port/offset names aren't meaningful.
Hi Stephen, On 5 May 2014 16:07, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/05/2014 03:30 PM, Simon Glass wrote: > ... > > I think you have it backwards...the current implementation has a > > single level of hierarchy. Each driver handles one bank (or 'port' in > > the case of Tegra). What you are talking about is having a single > > driver handle multiple banks, thus requiring that the driver have a > > second level to deal with banks, over and above the device. We might > > end up with that, but I would prefer to move to it when we have > > evidence that it is a general need. > > Sigh. This is getting silly. All the APIs in SW need to just take a GPIO > ID in the flat range 0..N (N==223 for Tegra20) and deal with it. > Anything that expose banks anywhere, either as a parameter to public > functions exported from the GPIO controller driver, or as the existence > of separate drivers for separate banks, or as a command-line argument > that the user sees, or ..., whether it be the U-Boot GPIO core or the > Tegra GPIO driver itself that causes this, is just pointless. > For exynos, the banks are not contiguous and there is quite a bit of fiddling to make this all work. You may have seen the series going in at the moment to number the GPIOs properly. I understand that Tegra is very straightforward though. > Please take a look at what the Linux driver does, and just model that. > It's very trivial. The following is the entire implementation of > gpio_set(): > > > // helper macros used by all register accesses: > > #define GPIO_BANK(x) ((x) >> 5) > > #define GPIO_PORT(x) (((x) >> 3) & 0x3) > > #define GPIO_BIT(x) ((x) & 0x7) > > > > #define GPIO_REG(x) (GPIO_BANK(x) * tegra_gpio_bank_stride + > \ > > GPIO_PORT(x) * 4) > > > > // one define per register > > #define GPIO_MSK_OUT(x) (GPIO_REG(x) + tegra_gpio_upper_offset + > 0x20) > > > > // helper used by a lot of set/clear functions > > static void tegra_gpio_mask_write(u32 reg, int gpio, int value) > > { > > u32 val; > > > > val = 0x100 << GPIO_BIT(gpio); > > if (value) > > val |= 1 << GPIO_BIT(gpio); > > tegra_gpio_writel(val, reg); > > } > > > > static void tegra_gpio_set(struct gpio_chip *chip, unsigned offset, int > value) > > { > > tegra_gpio_mask_write(GPIO_MSK_OUT(offset), offset, value); > > } > > i.e. a single register write with a calculated register address, using > just a few shifts/masks. > > >>>> It seems like this should be statically allocated (e.g. as part of > *plat > >>>> in gpio_tegra_bind() or something?). Still, if we stop splitting > things > >>>> into banks, we can completely get rid of this. > >>> > >>> No, we still need the name so that 'gpio input T3' works corrrectly. > >> > >> Why do we need GPIO names at all? "gpio input 155" works just as well, > >> and to be honest is often a lot more convenient that trying to maps > >> things back to a name. > > > > Eh? We need to support named GPIOs in U-Boot. 155 is a meaningless > > number which drivers people back and forth to the datasheets, their > > calculators, a long table, etc. Even the Tegra device tree has moved > > away from numbers to GPIO names, I notice. > > The GPIO names are meaningless. I say this because all the Tegra > schematics (and documentation that drives them) use the pin/pad name, > which is almost always entirely different from the GPIO name. You have > to map the pin name back to either the GPIO name or ID using a lookup > table (such as the kernel's drivers/pinctrl/pinctrl-tegra20.c). Given > the need for a lookup table, we should just use the simpler GPIO ID and > not worry about GPIO names. There's no point screwing around with text > names when we can just use simple numbers. > > In DT, GPIOs are specified by integer ID too. Admittedly we have macros > that calculate those IDs from the bank/port/offset, but that was > probably a mistake, since the bank/port/offset names aren't meaningful. > U-Boot provides a friendly named interface for GPIOs. I see that as a requirement for driver model too. As someone who has spent a lot of time at the command line fiddling with hardware, I don't want to go backwards in the driver model conversion. Similarly, using numbers in the DT is very unfriendly and painful IMO. If we can agree on the friendly names, then let's talk about how to simplify things. Regards, Simon
On 05/05/2014 05:00 PM, Simon Glass wrote: > Hi Stephen, > > On 5 May 2014 16:07, Stephen Warren <swarren@wwwdotorg.org > <mailto:swarren@wwwdotorg.org>> wrote: > > On 05/05/2014 03:30 PM, Simon Glass wrote: > ... > > I think you have it backwards...the current implementation has a > > single level of hierarchy. Each driver handles one bank (or 'port' in > > the case of Tegra). What you are talking about is having a single > > driver handle multiple banks, thus requiring that the driver have a > > second level to deal with banks, over and above the device. We might > > end up with that, but I would prefer to move to it when we have > > evidence that it is a general need. > > Sigh. This is getting silly. All the APIs in SW need to just take a GPIO > ID in the flat range 0..N (N==223 for Tegra20) and deal with it. > Anything that expose banks anywhere, either as a parameter to public > functions exported from the GPIO controller driver, or as the existence > of separate drivers for separate banks, or as a command-line argument > that the user sees, or ..., whether it be the U-Boot GPIO core or the > Tegra GPIO driver itself that causes this, is just pointless. > > > For exynos, the banks are not contiguous and there is quite a bit of > fiddling to make this all work. You may have seen the series going in at > the moment to number the GPIOs properly. > > I understand that Tegra is very straightforward though. Sure, HW that truly is designed as separate banks should be represented as such. However, the existence of such HW shouldn't force *other* HW to artificially expose banks of GPIOs when there's no need/desire to. > > Eh? We need to support named GPIOs in U-Boot. 155 is a meaningless > > number which drivers people back and forth to the datasheets, their > > calculators, a long table, etc. Even the Tegra device tree has moved > > away from numbers to GPIO names, I notice. > > The GPIO names are meaningless. I say this because all the Tegra > schematics (and documentation that drives them) use the pin/pad name, > which is almost always entirely different from the GPIO name. You have > to map the pin name back to either the GPIO name or ID using a lookup > table (such as the kernel's drivers/pinctrl/pinctrl-tegra20.c). Given > the need for a lookup table, we should just use the simpler GPIO ID and > not worry about GPIO names. There's no point screwing around with text > names when we can just use simple numbers. > > In DT, GPIOs are specified by integer ID too. Admittedly we have macros > that calculate those IDs from the bank/port/offset, but that was > probably a mistake, since the bank/port/offset names aren't meaningful. > > > U-Boot provides a friendly named interface for GPIOs. I see that as a > requirement for driver model too. As someone who has spent a lot of time > at the command line fiddling with hardware, I don't want to go backwards > in the driver model conversion. Similarly, using numbers in the DT is > very unfriendly and painful IMO. > > If we can agree on the friendly names, then let's talk about how to > simplify things. To be honest, I disagree that meaningless names are friendly. Almost everything else deals with numbers. The values in DT are numbers. The debugfs files in Linux are numbers. The sysfs ABI in Linux is numbers. The current GPIO interface in U-Boot is numbers. The correlation with pinctrl pins is numbers. If the following happens, then I could live with a (part-time) name-based API: * The U-Boot commands accept either a name or a number. That would allow people to use what they want. * The API implemented by U-Boot GPIO drivers uses numbers exclusively. Note that when I say numbers above, all the numbering should be relative to a particular controller. So, I don't mean something like: gpio set 1056 ... where 1056 is 1000 (Tegra GPIO controller base) + 56 (Tegra GPIO ID). Instead, I would expect the command-line interface to be: gpio set tegra 56 gpio set tegra PH0 ... where tegra is the name of the GPIO controller instance, and 56/PH0 is the GPIO ID within that one GPIO controller. The controller name could be pca9555-0 (0th instance of a pca9555 device) or i2c-0-56 (I2C bus 0 device address 0x56) or whatever naming style you want. To support this, I would expect the GPIO driver API to contain just two APIs that know about the GPIO names: int name_to_gpio_id(const char *gpio_name); const char *gpio_id_to_name(int gpio_id); All the other GPIO driver APIs would take "int gpio_id" (controller-relative integer ID).
HI Stephen, On 6 May 2014 11:34, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/05/2014 05:00 PM, Simon Glass wrote: > > Hi Stephen, > > > > On 5 May 2014 16:07, Stephen Warren <swarren@wwwdotorg.org > > <mailto:swarren@wwwdotorg.org>> wrote: > > > > On 05/05/2014 03:30 PM, Simon Glass wrote: > > ... > > > I think you have it backwards...the current implementation has a > > > single level of hierarchy. Each driver handles one bank (or 'port' > in > > > the case of Tegra). What you are talking about is having a single > > > driver handle multiple banks, thus requiring that the driver have a > > > second level to deal with banks, over and above the device. We > might > > > end up with that, but I would prefer to move to it when we have > > > evidence that it is a general need. > > > > Sigh. This is getting silly. All the APIs in SW need to just take a > GPIO > > ID in the flat range 0..N (N==223 for Tegra20) and deal with it. > > Anything that expose banks anywhere, either as a parameter to public > > functions exported from the GPIO controller driver, or as the > existence > > of separate drivers for separate banks, or as a command-line argument > > that the user sees, or ..., whether it be the U-Boot GPIO core or the > > Tegra GPIO driver itself that causes this, is just pointless. > > > > > > For exynos, the banks are not contiguous and there is quite a bit of > > fiddling to make this all work. You may have seen the series going in at > > the moment to number the GPIOs properly. > > > > I understand that Tegra is very straightforward though. > > Sure, HW that truly is designed as separate banks should be represented > as such. However, the existence of such HW shouldn't force *other* HW to > artificially expose banks of GPIOs when there's no need/desire to. > OK, well that's mostly an implementation issue, will take a look. > > > > Eh? We need to support named GPIOs in U-Boot. 155 is a meaningless > > > number which drivers people back and forth to the datasheets, their > > > calculators, a long table, etc. Even the Tegra device tree has > moved > > > away from numbers to GPIO names, I notice. > > > > The GPIO names are meaningless. I say this because all the Tegra > > schematics (and documentation that drives them) use the pin/pad name, > > which is almost always entirely different from the GPIO name. You > have > > to map the pin name back to either the GPIO name or ID using a lookup > > table (such as the kernel's drivers/pinctrl/pinctrl-tegra20.c). Given > > the need for a lookup table, we should just use the simpler GPIO ID > and > > not worry about GPIO names. There's no point screwing around with > text > > names when we can just use simple numbers. > > > > In DT, GPIOs are specified by integer ID too. Admittedly we have > macros > > that calculate those IDs from the bank/port/offset, but that was > > probably a mistake, since the bank/port/offset names aren't > meaningful. > > > > > > U-Boot provides a friendly named interface for GPIOs. I see that as a > > requirement for driver model too. As someone who has spent a lot of time > > at the command line fiddling with hardware, I don't want to go backwards > > in the driver model conversion. Similarly, using numbers in the DT is > > very unfriendly and painful IMO. > > > > If we can agree on the friendly names, then let's talk about how to > > simplify things. > > To be honest, I disagree that meaningless names are friendly. Almost > everything else deals with numbers. The values in DT are numbers. The > debugfs files in Linux are numbers. The sysfs ABI in Linux is numbers. > The current GPIO interface in U-Boot is numbers. The correlation with > pinctrl pins is numbers. > > If the following happens, then I could live with a (part-time) > name-based API: > > * The U-Boot commands accept either a name or a number. That would allow > people to use what they want. > > * The API implemented by U-Boot GPIO drivers uses numbers exclusively. > > Note that when I say numbers above, all the numbering should be relative > to a particular controller. So, I don't mean something like: > > gpio set 1056 > > ... where 1056 is 1000 (Tegra GPIO controller base) + 56 (Tegra GPIO > ID). Instead, I would expect the command-line interface to be: > > gpio set tegra 56 > gpio set tegra PH0 > > ... where tegra is the name of the GPIO controller instance, and 56/PH0 > is the GPIO ID within that one GPIO controller. > > The controller name could be pca9555-0 (0th instance of a pca9555 > device) or i2c-0-56 (I2C bus 0 device address 0x56) or whatever naming > style you want. > > To support this, I would expect the GPIO driver API to contain just two > APIs that know about the GPIO names: > > int name_to_gpio_id(const char *gpio_name); > const char *gpio_id_to_name(int gpio_id); > > All the other GPIO driver APIs would take "int gpio_id" > (controller-relative integer ID). > See gpio_lookup_name() which is where this lives. The GPIO uclass does sequentially number GPIOs, but be aware that on platforms with multiple GPIO controllers (e.g. an I2C GPIO extender) you might hit a problem where the tegra GPIOs are not first, so might start at 8 or 16, for example. However I think that probably can be resolved when we come to it. It was always my intention to support numbered GPIOs, but the current function doesn't do that except for anonymous banks - I'll update that as a separate patch. OK? Regards, Simon
On 05/06/2014 02:28 PM, Simon Glass wrote: ... > The GPIO uclass does sequentially number GPIOs, but be aware that on > platforms with multiple GPIO controllers (e.g. an I2C GPIO extender) you > might hit a problem where the tegra GPIOs are not first, so might start > at 8 or 16, for example. However I think that probably can be resolved > when we come to it. That fact shouldn't be exposed to the user. If all the GPIO IDs are relative to a specific named GPIO device, then the user will never see the internal offset. Indeed, the GPIO driver for a particular GPIO HW module/chip wouldn't ever see the offset either. In fact, we shouldn't have/introduce a flat/global GPIO numbering space at all. The Linux community has learned that doesn't work very well, and is moving away from it in the more recent "gpiod" API for example. Everything should be identified as a tuple (GPIO controller handle, GPIO ID within that GPIO controller).
Hi Stephen, On 6 May 2014 14:37, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/06/2014 02:28 PM, Simon Glass wrote: > ... > > The GPIO uclass does sequentially number GPIOs, but be aware that on > > platforms with multiple GPIO controllers (e.g. an I2C GPIO extender) you > > might hit a problem where the tegra GPIOs are not first, so might start > > at 8 or 16, for example. However I think that probably can be resolved > > when we come to it. > > That fact shouldn't be exposed to the user. If all the GPIO IDs are > relative to a specific named GPIO device, then the user will never see > the internal offset. Indeed, the GPIO driver for a particular GPIO HW > module/chip wouldn't ever see the offset either. In fact, we shouldn't > have/introduce a flat/global GPIO numbering space at all. The Linux > community has learned that doesn't work very well, and is moving away > from it in the more recent "gpiod" API for example. Everything should be > identified as a tuple (GPIO controller handle, GPIO ID within that GPIO > controller). > > Well that would be fairly easy to add my modifying the gpio command. Nothing we have talked about here precludes that, and driver model of course supports it. We should be able to make it backwards compatible too. Regards, Simon
diff --git a/arch/arm/include/asm/arch-tegra/gpio.h b/arch/arm/include/asm/arch-tegra/gpio.h index d97190d..80e4a73 100644 --- a/arch/arm/include/asm/arch-tegra/gpio.h +++ b/arch/arm/include/asm/arch-tegra/gpio.h @@ -6,6 +6,8 @@ #ifndef _TEGRA_GPIO_H_ #define _TEGRA_GPIO_H_ +#define TEGRA_GPIOS_PER_PORT 8 +#define TEGRA_PORTS_PER_BANK 4 #define MAX_NUM_GPIOS (TEGRA_GPIO_PORTS * TEGRA_GPIO_BANKS * 8) #define GPIO_NAME_SIZE 20 /* gpio_request max label len */ @@ -14,11 +16,13 @@ #define GPIO_FULLPORT(x) ((x) >> 3) #define GPIO_BIT(x) ((x) & 0x7) -/* - * Tegra-specific GPIO API +/** + * tegra_spl_gpio_direction_output() - set the output value of a GPIO + * + * This function is only used from SPL on seaboard, which needs to enable a + * GPIO to get the UART running. It could be done in U-Boot rather than SPL, + * but for now, this gets it working */ +int tegra_spl_gpio_direction_output(int gpio, int value); -void gpio_info(void); - -#define gpio_status() gpio_info() #endif /* TEGRA_GPIO_H_ */ diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c index ef4e481..e27efcd 100644 --- a/board/nvidia/seaboard/seaboard.c +++ b/board/nvidia/seaboard/seaboard.c @@ -22,7 +22,7 @@ void gpio_early_init_uart(void) #ifndef CONFIG_SPL_BUILD gpio_request(GPIO_PI3, NULL); #endif - gpio_direction_output(GPIO_PI3, 0); + tegra_spl_gpio_direction_output(GPIO_PI3, 0); } #endif diff --git a/drivers/gpio/tegra_gpio.c b/drivers/gpio/tegra_gpio.c index 82b30d5..4cca266 100644 --- a/drivers/gpio/tegra_gpio.c +++ b/drivers/gpio/tegra_gpio.c @@ -12,10 +12,17 @@ */ #include <common.h> +#include <dm.h> +#include <malloc.h> +#include <errno.h> +#include <fdtdec.h> #include <asm/io.h> #include <asm/bitops.h> #include <asm/arch/tegra.h> #include <asm/gpio.h> +#include <dm/device-internal.h> + +DECLARE_GLOBAL_DATA_PTR; enum { TEGRA_CMD_INFO, @@ -24,24 +31,30 @@ enum { TEGRA_CMD_INPUT, }; -static struct gpio_names { - char name[GPIO_NAME_SIZE]; -} gpio_names[MAX_NUM_GPIOS]; +struct tegra_gpio_platdata { + struct gpio_ctlr_bank *bank; + const char *port_name; /* Name of port, e.g. "B" */ + int base_port; /* Port number for this port (0, 1,.., n-1) */ +}; -static char *get_name(int i) -{ - return *gpio_names[i].name ? gpio_names[i].name : "UNKNOWN"; -} +/* Information about each port at run-time */ +struct tegra_port_info { + char label[TEGRA_GPIOS_PER_PORT][GPIO_NAME_SIZE]; + struct gpio_ctlr_bank *bank; + int base_port; /* Port number for this port (0, 1,.., n-1) */ +}; + +#define GPIO_NUM(state, offset) \ + (((state)->base_port * TEGRA_GPIOS_PER_PORT) + (offset)) /* Return config of pin 'gpio' as GPIO (1) or SFPIO (0) */ -static int get_config(unsigned gpio) +static int get_config(struct tegra_port_info *state, int offset) { - struct gpio_ctlr *ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE; - struct gpio_ctlr_bank *bank = &ctlr->gpio_bank[GPIO_BANK(gpio)]; + int gpio = GPIO_NUM(state, offset); u32 u; int type; - u = readl(&bank->gpio_config[GPIO_PORT(gpio)]); + u = readl(&state->bank->gpio_config[GPIO_PORT(gpio)]); type = (u >> GPIO_BIT(gpio)) & 1; debug("get_config: port = %d, bit = %d is %s\n", @@ -51,32 +64,32 @@ static int get_config(unsigned gpio) } /* Config pin 'gpio' as GPIO or SFPIO, based on 'type' */ -static void set_config(unsigned gpio, int type) +static void set_config(struct tegra_port_info *state, int offset, int type) { - struct gpio_ctlr *ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE; - struct gpio_ctlr_bank *bank = &ctlr->gpio_bank[GPIO_BANK(gpio)]; + int gpio = GPIO_NUM(state, offset); u32 u; debug("set_config: port = %d, bit = %d, %s\n", - GPIO_FULLPORT(gpio), GPIO_BIT(gpio), type ? "GPIO" : "SFPIO"); + GPIO_FULLPORT(gpio), + GPIO_BIT(gpio), + type ? "GPIO" : "SFPIO"); - u = readl(&bank->gpio_config[GPIO_PORT(gpio)]); + u = readl(&state->bank->gpio_config[GPIO_PORT(gpio)]); if (type) /* GPIO */ u |= 1 << GPIO_BIT(gpio); else u &= ~(1 << GPIO_BIT(gpio)); - writel(u, &bank->gpio_config[GPIO_PORT(gpio)]); + writel(u, &state->bank->gpio_config[GPIO_PORT(gpio)]); } /* Return GPIO pin 'gpio' direction - 0 = input or 1 = output */ -static int get_direction(unsigned gpio) +static int get_direction(struct tegra_port_info *state, int offset) { - struct gpio_ctlr *ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE; - struct gpio_ctlr_bank *bank = &ctlr->gpio_bank[GPIO_BANK(gpio)]; + int gpio = GPIO_NUM(state, offset); u32 u; int dir; - u = readl(&bank->gpio_dir_out[GPIO_PORT(gpio)]); + u = readl(&state->bank->gpio_dir_out[GPIO_PORT(gpio)]); dir = (u >> GPIO_BIT(gpio)) & 1; debug("get_direction: port = %d, bit = %d, %s\n", @@ -86,161 +99,349 @@ static int get_direction(unsigned gpio) } /* Config GPIO pin 'gpio' as input or output (OE) as per 'output' */ -static void set_direction(unsigned gpio, int output) +static void set_direction(struct tegra_port_info *state, int offset, + int output) { - struct gpio_ctlr *ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE; - struct gpio_ctlr_bank *bank = &ctlr->gpio_bank[GPIO_BANK(gpio)]; + int gpio = GPIO_NUM(state, offset); u32 u; - debug("set_direction: port = %d, bit = %d, %s\n", - GPIO_FULLPORT(gpio), GPIO_BIT(gpio), output ? "OUT" : "IN"); + debug("%s: port = %d, bit = %d, %s\n", __func__, + GPIO_FULLPORT(gpio), GPIO_BIT(gpio), output ? "OUT" : "IN"); - u = readl(&bank->gpio_dir_out[GPIO_PORT(gpio)]); + u = readl(&state->bank->gpio_dir_out[GPIO_PORT(gpio)]); if (output) u |= 1 << GPIO_BIT(gpio); else u &= ~(1 << GPIO_BIT(gpio)); - writel(u, &bank->gpio_dir_out[GPIO_PORT(gpio)]); + writel(u, &state->bank->gpio_dir_out[GPIO_PORT(gpio)]); } /* set GPIO pin 'gpio' output bit as 0 or 1 as per 'high' */ -static void set_level(unsigned gpio, int high) +static void set_level(struct tegra_port_info *state, int offset, int high) { - struct gpio_ctlr *ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE; - struct gpio_ctlr_bank *bank = &ctlr->gpio_bank[GPIO_BANK(gpio)]; + int gpio = GPIO_NUM(state, offset); u32 u; - debug("set_level: port = %d, bit %d == %d\n", - GPIO_FULLPORT(gpio), GPIO_BIT(gpio), high); + debug("%s: port = %d, bit %d == %d\n", __func__, + GPIO_FULLPORT(gpio), GPIO_BIT(gpio), high); - u = readl(&bank->gpio_out[GPIO_PORT(gpio)]); + u = readl(&state->bank->gpio_out[GPIO_PORT(gpio)]); if (high) u |= 1 << GPIO_BIT(gpio); else u &= ~(1 << GPIO_BIT(gpio)); - writel(u, &bank->gpio_out[GPIO_PORT(gpio)]); + writel(u, &state->bank->gpio_out[GPIO_PORT(gpio)]); +} + +/* read GPIO OUT value of pin 'gpio' */ +static int get_output_value(struct tegra_port_info *state, int offset) +{ + int gpio = GPIO_NUM(state, offset); + int val; + + debug("gpio_get_output_value: pin = %d (port %d:bit %d)\n", + gpio, GPIO_FULLPORT(gpio), GPIO_BIT(gpio)); + + val = readl(&state->bank->gpio_out[GPIO_PORT(gpio)]); + + return (val >> GPIO_BIT(gpio)) & 1; } +#ifdef CONFIG_SPL +/* set GPIO pin 'gpio' as an output, with polarity 'value' */ +int tegra_spl_gpio_direction_output(int gpio, int value) +{ + struct gpio_ctlr *ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE; + struct tegra_port_info state; + + state.bank = &ctlr->gpio_bank[GPIO_BANK(gpio)]; + state.base_port = GPIO_FULLPORT(gpio); + + /* Configure GPIO output value. */ + set_level(&state, GPIO_BIT(gpio), value); + + /* Configure GPIO direction as output. */ + set_direction(&state, GPIO_BIT(gpio), value); + + return 0; +} +#endif /* CONFIG_SPL */ + /* * Generic_GPIO primitives. */ -int gpio_request(unsigned gpio, const char *label) +static int check_reserved(struct device *dev, unsigned offset, + const char *func) { - if (gpio >= MAX_NUM_GPIOS) - return -1; + struct tegra_port_info *state = dev_get_priv(dev); + struct gpio_dev_priv *uc_priv = dev->uclass_priv; - if (label != NULL) { - strncpy(gpio_names[gpio].name, label, GPIO_NAME_SIZE); - gpio_names[gpio].name[GPIO_NAME_SIZE - 1] = '\0'; + if (!*state->label[offset]) { + printf("tegra_gpio: %s: error: gpio %s%d not reserved\n", + func, uc_priv->bank_name, offset); + return -EPERM; } - /* Configure as a GPIO */ - set_config(gpio, 1); - return 0; } -int gpio_free(unsigned gpio) +static int tegra_gpio_request(struct device *dev, unsigned offset, + const char *label) { - if (gpio >= MAX_NUM_GPIOS) - return -1; + struct tegra_port_info *state = dev_get_priv(dev); + + if (*state->label[offset]) + return -EBUSY; + + strncpy(state->label[offset], label, GPIO_NAME_SIZE); + state->label[offset][GPIO_NAME_SIZE - 1] = '\0'; + + /* Configure as a GPIO */ + set_config(state, offset, 1); - gpio_names[gpio].name[0] = '\0'; - /* Do not configure as input or change pin mux here */ return 0; } -/* read GPIO OUT value of pin 'gpio' */ -static int gpio_get_output_value(unsigned gpio) +static int tegra_gpio_free(struct device *dev, unsigned offset) { - struct gpio_ctlr *ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE; - struct gpio_ctlr_bank *bank = &ctlr->gpio_bank[GPIO_BANK(gpio)]; - int val; - - debug("gpio_get_output_value: pin = %d (port %d:bit %d)\n", - gpio, GPIO_FULLPORT(gpio), GPIO_BIT(gpio)); + struct tegra_port_info *state = dev_get_priv(dev); + int ret; - val = readl(&bank->gpio_out[GPIO_PORT(gpio)]); + ret = check_reserved(dev, offset, __func__); + if (ret) + return ret; + state->label[offset][0] = '\0'; - return (val >> GPIO_BIT(gpio)) & 1; + return 0; } /* set GPIO pin 'gpio' as an input */ -int gpio_direction_input(unsigned gpio) +static int tegra_gpio_direction_input(struct device *dev, unsigned offset) { - debug("gpio_direction_input: pin = %d (port %d:bit %d)\n", - gpio, GPIO_FULLPORT(gpio), GPIO_BIT(gpio)); + struct tegra_port_info *state = dev_get_priv(dev); + int ret; + + ret = check_reserved(dev, offset, __func__); + if (ret) + return ret; /* Configure GPIO direction as input. */ - set_direction(gpio, 0); + set_direction(state, offset, 0); return 0; } /* set GPIO pin 'gpio' as an output, with polarity 'value' */ -int gpio_direction_output(unsigned gpio, int value) +static int tegra_gpio_direction_output(struct device *dev, unsigned offset, + int value) { - debug("gpio_direction_output: pin = %d (port %d:bit %d) = %s\n", - gpio, GPIO_FULLPORT(gpio), GPIO_BIT(gpio), - value ? "HIGH" : "LOW"); + struct tegra_port_info *state = dev_get_priv(dev); + int ret; + + ret = check_reserved(dev, offset, __func__); + if (ret) + return ret; /* Configure GPIO output value. */ - set_level(gpio, value); + set_level(state, offset, value); /* Configure GPIO direction as output. */ - set_direction(gpio, 1); + set_direction(state, offset, 1); return 0; } /* read GPIO IN value of pin 'gpio' */ -int gpio_get_value(unsigned gpio) +static int tegra_gpio_get_value(struct device *dev, unsigned offset) { - struct gpio_ctlr *ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE; - struct gpio_ctlr_bank *bank = &ctlr->gpio_bank[GPIO_BANK(gpio)]; + struct tegra_port_info *state = dev_get_priv(dev); + int gpio = GPIO_NUM(state, offset); + int ret; int val; - debug("gpio_get_value: pin = %d (port %d:bit %d)\n", - gpio, GPIO_FULLPORT(gpio), GPIO_BIT(gpio)); + ret = check_reserved(dev, offset, __func__); + if (ret) + return ret; + + debug("%s: pin = %d (port %d:bit %d)\n", __func__, + gpio, GPIO_FULLPORT(gpio), GPIO_BIT(gpio)); - val = readl(&bank->gpio_in[GPIO_PORT(gpio)]); + val = readl(&state->bank->gpio_in[GPIO_PORT(gpio)]); return (val >> GPIO_BIT(gpio)) & 1; } /* write GPIO OUT value to pin 'gpio' */ -int gpio_set_value(unsigned gpio, int value) +static int tegra_gpio_set_value(struct device *dev, unsigned offset, int value) { + struct tegra_port_info *state = dev_get_priv(dev); + int gpio = GPIO_NUM(state, offset); + int ret; + + ret = check_reserved(dev, offset, __func__); + if (ret) + return ret; + debug("gpio_set_value: pin = %d (port %d:bit %d), value = %d\n", - gpio, GPIO_FULLPORT(gpio), GPIO_BIT(gpio), value); + gpio, GPIO_FULLPORT(gpio), GPIO_BIT(gpio), value); /* Configure GPIO output value. */ - set_level(gpio, value); + set_level(state, offset, value); return 0; } -/* - * Display Tegra GPIO information +static int tegra_gpio_get_state(struct device *dev, unsigned int offset, + char *buf, int bufsize) +{ + struct gpio_dev_priv *uc_priv = dev->uclass_priv; + struct tegra_port_info *state = dev_get_priv(dev); + const char *label; + int is_output; + int is_gpio; + int size; + + label = state->label[offset]; + is_gpio = get_config(state, offset); /* GPIO, not SFPIO */ + size = snprintf(buf, bufsize, "%s%d: ", + uc_priv->bank_name ? uc_priv->bank_name : "", offset); + buf += size; + bufsize -= size; + if (is_gpio) { + is_output = get_direction(state, offset); + + snprintf(buf, bufsize, "%s: %d [%c]%s%s", + is_output ? "out" : " in", + is_output ? + get_output_value(state, offset) : + tegra_gpio_get_value(dev, offset), + *label ? 'x' : ' ', + *label ? " " : "", + label); + } else { + snprintf(buf, bufsize, "sfpio"); + } + + return 0; +} + +static const struct dm_gpio_ops gpio_tegra_ops = { + .request = tegra_gpio_request, + .free = tegra_gpio_free, + .direction_input = tegra_gpio_direction_input, + .direction_output = tegra_gpio_direction_output, + .get_value = tegra_gpio_get_value, + .set_value = tegra_gpio_set_value, + .get_state = tegra_gpio_get_state, +}; + +/** + * Returns the name of a GPIO port + * + * GPIOs are named A, B, C, ..., Z, AA, BB, CC, ... + * + * @base_port: Base port number (0, 1..n-1) + * @return allocated string containing the name */ -void gpio_info(void) +static char *gpio_port_name(int base_port) { - unsigned c; - int type; + char *name, *s; + + name = malloc(3); + if (name) { + s = name; + *s++ = 'A' + (base_port % 26); + if (base_port >= 26) + *s++ = *name; + *s = '\0'; + } + + return name; +} + +static const struct device_id tegra_gpio_ids[] = { + { .compatible = "nvidia,tegra30-gpio" }, + { .compatible = "nvidia,tegra20-gpio" }, + { } +}; + +static int gpio_tegra_probe(struct device *dev) +{ + struct gpio_dev_priv *uc_priv = dev->uclass_priv; + struct tegra_port_info *priv = dev->priv; + struct tegra_gpio_platdata *plat = dev->platdata; + + /* Only child devices have ports */ + if (!plat) + return 0; + + priv->bank = plat->bank; + priv->base_port = plat->base_port; - for (c = 0; c < MAX_NUM_GPIOS; c++) { - type = get_config(c); /* GPIO, not SFPIO */ - if (type) { - printf("GPIO_%d:\t%s is an %s, ", c, - get_name(c), - get_direction(c) ? "OUTPUT" : "INPUT"); - if (get_direction(c)) - printf("value = %d", gpio_get_output_value(c)); - else - printf("value = %d", gpio_get_value(c)); - printf("\n"); - } else - continue; + uc_priv->gpio_count = TEGRA_GPIOS_PER_PORT; + uc_priv->bank_name = plat->port_name; + + return 0; +} + +/** + * We have a top-level GPIO device with no actual GPIOs. It has a child + * device for each Tegra port. + */ +static int gpio_tegra_bind(struct device *parent) +{ + struct tegra_gpio_platdata *plat = parent->platdata; + struct gpio_ctlr *ctlr; + int bank_count; + int bank; + int ret; + int len; + + /* If this is a child device, there is nothing to do here */ + if (plat) + return 0; + + /* + * This driver does not make use of interrupts, other than to figure + * out the number of GPIO banks + */ + if (!fdt_getprop(gd->fdt_blob, parent->of_offset, "interrupts", &len)) + return -EINVAL; + bank_count = len / 3 / sizeof(u32); + ctlr = (struct gpio_ctlr *)fdtdec_get_addr(gd->fdt_blob, + parent->of_offset, "reg"); + for (bank = 0; bank < bank_count; bank++) { + int port; + + for (port = 0; port < TEGRA_PORTS_PER_BANK; port++) { + struct tegra_gpio_platdata *plat; + struct device *dev; + + plat = calloc(1, sizeof(*plat)); + if (!plat) + return -ENOMEM; + plat->bank = &ctlr->gpio_bank[bank]; + plat->base_port = bank * TEGRA_PORTS_PER_BANK + port; + plat->port_name = gpio_port_name(plat->base_port); + + ret = device_bind(parent, parent->driver, + plat->port_name, plat, -1, &dev); + if (ret) + return ret; + dev->of_offset = parent->of_offset; + } } + + return 0; } + +U_BOOT_DRIVER(gpio_tegra) = { + .name = "gpio_tegra", + .id = UCLASS_GPIO, + .of_match = tegra_gpio_ids, + .bind = gpio_tegra_bind, + .probe = gpio_tegra_probe, + .priv_auto_alloc_size = sizeof(struct tegra_port_info), + .ops = &gpio_tegra_ops, +}; diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 3943249..7222ba6 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -20,6 +20,8 @@ #include <asm/arch/tegra.h> /* get chip and board defs */ #define CONFIG_DM +#define CONFIG_DM_GPIO +#define CONFIG_CMD_DM #define CONFIG_SYS_TIMER_RATE 1000000 #define CONFIG_SYS_TIMER_COUNTER NV_PA_TMRUS_BASE
This is an implementation of GPIOs for Tegra that uses driver model. It has been tested on trimslice and also using the new iotrace feature. The implementation uses a top-level GPIO device (which has no actual GPIOS). Under this all the banks are created as separate GPIO devices. The GPIOs are named as per the Tegra datasheet/header files: A0..A7, B0..B7, ..., Z0..Z7, AA0..AA7, etc. Since driver model is not yet available before relocation, or in SPL, a special function is provided for seaboard's SPL code. This series is marked RFC since the Tegra driver may need further discussion. Signed-off-by: Simon Glass <sjg@chromium.org> --- Changes in v2: - Split out driver model changes into separate patches - Correct bugs found during testing arch/arm/include/asm/arch-tegra/gpio.h | 14 +- board/nvidia/seaboard/seaboard.c | 2 +- drivers/gpio/tegra_gpio.c | 393 +++++++++++++++++++++++++-------- include/configs/tegra-common.h | 2 + 4 files changed, 309 insertions(+), 102 deletions(-)