[U-Boot] [PATCH 0/14] dm: omap: Provide access to driver model for am335x, and move boards
This series adjusts the serial and GPIO drivers, used by Beaglebone for example, to work with driver model. Since there are still boards using these drivers but not driver model, this adds new functionality rather than replacing what exists.
Several patches tweak and fix the existing driver model serial and GPIO implementation.
There are two Beaglebone Black configurations:
- Device tree control with verified boot - No device tree control
The first uses device tree to select the serial console and provide information needed by the serial driver (similar to how things work on Tegra). The second uses platform data provided by a common board file.
Both are converted, so this is a good example of how to support both device tree and platform data if needed.
Simon Glass (14): dm: gpio: Support numbered GPIOs dm: serial: Reset the watchdog while waiting in getc() dm: serial: ns16550: Correct logic for checking for character dm: ns16550: Use an address instead of a pointer for the uart base dm: ns16550: Correct the probe logic for platform data dm: serial: Support CONFIG_CONS_INDEX if available dm: dts: omap: Select correct console for beaglebone dm: omap: gpio: Put _get_gpio_value() logic into its own function dm: omap: gpio: Support driver model dm: am33xx: Provide platform data for GPIOs dm: am33xx: Provide platform data for serial dm: omap: serial: Add driver model support dm: am335x: Remove serial options from CONFIG_SYS_EXTRA_OPTIONS dm: am33xx: Move to driver model for GPIO and serial
arch/arm/cpu/armv7/am33xx/board.c | 61 +++++++ arch/arm/dts/am335x-bone-common.dtsi | 4 + arch/arm/include/asm/omap_gpio.h | 19 +- configs/am335x_boneblack_defconfig | 2 +- configs/am335x_boneblack_vboot_defconfig | 2 +- drivers/gpio/gpio-uclass.c | 37 ++-- drivers/gpio/omap_gpio.c | 297 +++++++++++++++++++++++++++---- drivers/mmc/omap_hsmmc.c | 15 +- drivers/serial/Makefile | 1 + drivers/serial/ns16550.c | 13 +- drivers/serial/serial-uclass.c | 16 +- drivers/serial/serial_omap.c | 49 +++++ include/configs/ti_am335x_common.h | 11 ++ include/ns16550.h | 2 +- 14 files changed, 465 insertions(+), 64 deletions(-) create mode 100644 drivers/serial/serial_omap.c
At present banks must be named and it is not possible to refer to GPIOs by number in driver model. Some boards use numbering - e.g. OMAP. It is fairly easy to support by detecting the absense of a bank name (which starts with a letter).
Add support for numbered GPIOs in addition to the existing bank support.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/gpio/gpio-uclass.c | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c index f1bbc58..a5ffd85 100644 --- a/drivers/gpio/gpio-uclass.c +++ b/drivers/gpio/gpio-uclass.c @@ -8,6 +8,7 @@ #include <dm.h> #include <errno.h> #include <asm/gpio.h> +#include <linux/ctype.h>
/** * gpio_to_device() - Convert global GPIO number to device, number @@ -43,35 +44,47 @@ static int gpio_to_device(unsigned int gpio, struct udevice **devp, int gpio_lookup_name(const char *name, struct udevice **devp, unsigned int *offsetp, unsigned int *gpiop) { - struct gpio_dev_priv *uc_priv; + struct gpio_dev_priv *uc_priv = NULL; struct udevice *dev; + ulong offset; + int numeric; int ret;
if (devp) *devp = NULL; + numeric = isdigit(*name) ? simple_strtoul(name, NULL, 10) : -1; for (ret = uclass_first_device(UCLASS_GPIO, &dev); dev; ret = uclass_next_device(&dev)) { - ulong offset; int len;
uc_priv = dev->uclass_priv; + if (numeric != -1) { + offset = numeric - uc_priv->gpio_base; + /* Allow GPIOs to be numbered from 0 */ + if (offset >= 0 && offset < uc_priv->gpio_count) + break; + } + len = uc_priv->bank_name ? strlen(uc_priv->bank_name) : 0;
if (!strncasecmp(name, uc_priv->bank_name, len)) { - if (strict_strtoul(name + len, 10, &offset)) - continue; - if (devp) - *devp = dev; - if (offsetp) - *offsetp = offset; - if (gpiop) - *gpiop = uc_priv->gpio_base + offset; - return 0; + if (!strict_strtoul(name + len, 10, &offset)) + break; } }
- return ret ? ret : -EINVAL; + if (!dev) + return ret ? ret : -EINVAL; + + if (devp) + *devp = dev; + if (offsetp) + *offsetp = offset; + if (gpiop) + *gpiop = uc_priv->gpio_base + offset; + + return 0; }
/**
On Mon, Sep 22, 2014 at 09:48:41AM -0600, Simon Glass wrote:
At present banks must be named and it is not possible to refer to GPIOs by number in driver model. Some boards use numbering - e.g. OMAP. It is fairly easy to support by detecting the absense of a bank name (which starts with a letter).
Add support for numbered GPIOs in addition to the existing bank support.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
We have moved the busy-wait loop out of drivers and into the uclass. This means that we must reset the watchdog when busy-waiting.
Note: some drivers may still have a busy-wait even with driver model, as a transition mechanism. Driver model will tolerate this, and is can be cleaned up when all users of the driver use driver model. An example is ns16550.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/serial/serial-uclass.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index e93c624..aeaf2d2 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -11,9 +11,12 @@ #include <os.h> #include <serial.h> #include <stdio_dev.h> +#include <watchdog.h> #include <dm/lists.h> #include <dm/device-internal.h>
+#include <ns16550.h> + DECLARE_GLOBAL_DATA_PTR;
/* The currently-selected console serial device */ @@ -119,6 +122,8 @@ static int serial_getc_dev(struct udevice *dev)
do { err = ops->getc(dev); + if (err == -EAGAIN) + WATCHDOG_RESET(); } while (err == -EAGAIN);
return err >= 0 ? err : 0;
On Mon, Sep 22, 2014 at 09:48:42AM -0600, Simon Glass wrote:
We have moved the busy-wait loop out of drivers and into the uclass. This means that we must reset the watchdog when busy-waiting.
Note: some drivers may still have a busy-wait even with driver model, as a transition mechanism. Driver model will tolerate this, and is can be cleaned up when all users of the driver use driver model. An example is ns16550.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
There is a bug in the logic which checks for an available character. This can cause invalid characters to be received - this was noticed on beaglebone. Fix it.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/serial/ns16550.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 63a9ef6..fe6cc26 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -253,7 +253,7 @@ static int ns16550_serial_getc(struct udevice *dev) { struct NS16550 *const com_port = dev_get_priv(dev);
- if (!serial_in(&com_port->lsr) & UART_LSR_DR) + if (!(serial_in(&com_port->lsr) & UART_LSR_DR)) return -EAGAIN;
return serial_in(&com_port->rbr);
On Mon, Sep 22, 2014 at 09:48:43AM -0600, Simon Glass wrote:
There is a bug in the logic which checks for an available character. This can cause invalid characters to be received - this was noticed on beaglebone. Fix it.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
It is inconvenient to have to use casts when specifying platform data. Also it is not strictly correct, since we should use map_sysmem() to convert an address to a pointer.
Adjust the platform data to use an address.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/serial/ns16550.c | 6 +++--- include/ns16550.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index fe6cc26..2301f0a 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -61,7 +61,7 @@ static void ns16550_writeb(NS16550_t port, int offset, int value) unsigned char *addr;
offset *= 1 << plat->reg_shift; - addr = plat->base + offset; + addr = map_sysmem(plat->base, 0) + offset; /* * As far as we know it doesn't make sense to support selection of * these options at run-time, so use the existing CONFIG options. @@ -85,7 +85,7 @@ static int ns16550_readb(NS16550_t port, int offset) unsigned char *addr;
offset *= 1 << plat->reg_shift; - addr = plat->base + offset; + addr = map_sysmem(plat->base, 0) + offset; #ifdef CONFIG_SYS_NS16550_PORT_MAPPED return inb(addr); #elif defined(CONFIG_SYS_NS16550_MEM32) && !defined(CONFIG_SYS_BIG_ENDIAN) @@ -291,7 +291,7 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev) if (addr == FDT_ADDR_T_NONE) return -EINVAL;
- plat->base = (unsigned char *)addr; + plat->base = addr; plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "reg-shift", 1); com_port->plat = plat; diff --git a/include/ns16550.h b/include/ns16550.h index 5784cfd..0607379 100644 --- a/include/ns16550.h +++ b/include/ns16550.h @@ -53,7 +53,7 @@ * @clock: UART base clock speed in Hz */ struct ns16550_platdata { - unsigned char *base; + unsigned long base; int reg_shift; int clock; };
On Mon, Sep 22, 2014 at 09:48:44AM -0600, Simon Glass wrote:
It is inconvenient to have to use casts when specifying platform data. Also it is not strictly correct, since we should use map_sysmem() to convert an address to a pointer.
Adjust the platform data to use an address.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
The probe logic sets up the pointer to the platform data in the device tree decode method. It should be done in the probe() method, and anyway the device tree decode method can't be used when CONFIG_OF_CONTROL is not enabled.
Fix these two problems.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/serial/ns16550.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 2301f0a..0799aa4 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -276,14 +276,15 @@ int ns16550_serial_probe(struct udevice *dev) { struct NS16550 *const com_port = dev_get_priv(dev);
+ com_port->plat = dev_get_platdata(dev); NS16550_init(com_port, -1);
return 0; }
+#ifdef CONFIG_OF_CONTROL int ns16550_serial_ofdata_to_platdata(struct udevice *dev) { - struct NS16550 *const com_port = dev_get_priv(dev); struct ns16550_platdata *plat = dev->platdata; fdt_addr_t addr;
@@ -294,10 +295,10 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev) plat->base = addr; plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "reg-shift", 1); - com_port->plat = plat;
return 0; } +#endif
const struct dm_serial_ops ns16550_serial_ops = { .putc = ns16550_serial_putc,
On Mon, Sep 22, 2014 at 09:48:45AM -0600, Simon Glass wrote:
The probe logic sets up the pointer to the platform data in the device tree decode method. It should be done in the probe() method, and anyway the device tree decode method can't be used when CONFIG_OF_CONTROL is not enabled.
Fix these two problems.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
Try to use this option to select the correct uart for the console. This mimics the behaviour of drivers/serial.c.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/serial/serial-uclass.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index aeaf2d2..522e551 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -50,13 +50,22 @@ static void serial_find_console_or_panic(void) } #endif /* + * Try to use CONFIG_CONS_INDEX is available (it is numbered from 1!). + * * Failing that, get the device with sequence number 0, or in extremis * just the first serial device we can find. But we insist on having * a console (even if it is silent). */ - if (uclass_get_device_by_seq(UCLASS_SERIAL, 0, &cur_dev) && +#ifdef CONFIG_CONS_INDEX +#define INDEX (CONFIG_CONS_INDEX - 1) +#else +#define INDEX 0 +#endif + if (uclass_get_device_by_seq(UCLASS_SERIAL, INDEX, &cur_dev) && + uclass_get_device(UCLASS_SERIAL, INDEX, &cur_dev) && (uclass_first_device(UCLASS_SERIAL, &cur_dev) || !cur_dev)) panic("No serial driver found"); +#undef INDEX }
/* Called prior to relocation */
On Mon, Sep 22, 2014 at 09:48:46AM -0600, Simon Glass wrote:
Try to use this option to select the correct uart for the console. This mimics the behaviour of drivers/serial.c.
Signed-off-by: Simon Glass sjg@chromium.org
drivers/serial/serial-uclass.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index aeaf2d2..522e551 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -50,13 +50,22 @@ static void serial_find_console_or_panic(void) } #endif /*
* Try to use CONFIG_CONS_INDEX is available (it is numbered from 1!).
"if it is available" or "if available". Otherwise:
Reviewed-by: Tom Rini trini@ti.com
Select serial0 as the console.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/arm/dts/am335x-bone-common.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/am335x-bone-common.dtsi b/arch/arm/dts/am335x-bone-common.dtsi index 2f66ded..e70b4d1 100644 --- a/arch/arm/dts/am335x-bone-common.dtsi +++ b/arch/arm/dts/am335x-bone-common.dtsi @@ -10,6 +10,10 @@ model = "TI AM335x BeagleBone"; compatible = "ti,am335x-bone", "ti,am33xx";
+ chosen { + stdout-path = &uart0; + }; + cpus { cpu@0 { cpu0-supply = <&dcdc2_reg>;
On Mon, Sep 22, 2014 at 09:48:47AM -0600, Simon Glass wrote:
Select serial0 as the console.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/dts/am335x-bone-common.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/am335x-bone-common.dtsi b/arch/arm/dts/am335x-bone-common.dtsi index 2f66ded..e70b4d1 100644 --- a/arch/arm/dts/am335x-bone-common.dtsi +++ b/arch/arm/dts/am335x-bone-common.dtsi @@ -10,6 +10,10 @@ model = "TI AM335x BeagleBone"; compatible = "ti,am335x-bone", "ti,am33xx";
- chosen {
stdout-path = &uart0;- };
- cpus { cpu@0 { cpu0-supply = <&dcdc2_reg>;
So here's where I worry. The reason we have a Kconfig for CONS_INDEX is that there are boards it's NOT uart0. Setting aside the people with a "uart cape" (or otherwise breadboarding out another uart to a real connector), the industrial EVM is uart2 I want to say and we had been happily supporting this board with just a different build target (then defconfig). What can we do here? And yes, I see this is the bone DT not the EVM dt, but I'd rather not have to, if we don't have to at least, default to just not supporting the board (which is at least on the table, there's no DT for it in the kernel either).
As it stands however, it's right for what it's modifying so:
Acked-by: Tom Rini trini@ti.com
Hi Tom,
On 22 October 2014 09:59, Tom Rini trini@ti.com wrote:
On Mon, Sep 22, 2014 at 09:48:47AM -0600, Simon Glass wrote:
Select serial0 as the console.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/dts/am335x-bone-common.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/am335x-bone-common.dtsi b/arch/arm/dts/am335x-bone-common.dtsi index 2f66ded..e70b4d1 100644 --- a/arch/arm/dts/am335x-bone-common.dtsi +++ b/arch/arm/dts/am335x-bone-common.dtsi @@ -10,6 +10,10 @@ model = "TI AM335x BeagleBone"; compatible = "ti,am335x-bone", "ti,am33xx";
chosen {stdout-path = &uart0;};cpus { cpu@0 { cpu0-supply = <&dcdc2_reg>;So here's where I worry. The reason we have a Kconfig for CONS_INDEX is that there are boards it's NOT uart0. Setting aside the people with a "uart cape" (or otherwise breadboarding out another uart to a real connector), the industrial EVM is uart2 I want to say and we had been happily supporting this board with just a different build target (then defconfig). What can we do here? And yes, I see this is the bone DT not the EVM dt, but I'd rather not have to, if we don't have to at least, default to just not supporting the board (which is at least on the table, there's no DT for it in the kernel either).
I think we are looking for a build-time way to change the console. Is that right? I suppose we could use a #define in the device tree, set from some sort of include file / option, but that seems pretty ugly.
It would not be hard to modify the DT in the binary after it is built, if that helps.
We can certainly support a different build target with a different 'default' device tree. We would then have several .dts files all including the .dtsi for their main body.
Also there is a patch that I have not tidied/sent yet which builds all the .dtb files for a class of boards, so you can add the .dtb that you prefer to U-Boot with 'cat'.
I'm open to various options here, but I'm not sure which is best for this use case.
I wonder how the kernel deals with this issue?
As it stands however, it's right for what it's modifying so:
Acked-by: Tom Rini trini@ti.com
-- Tom
Regards, Simon
On Wed, Oct 22, 2014 at 09:19:08PM -0600, Simon Glass wrote:
Hi Tom,
On 22 October 2014 09:59, Tom Rini trini@ti.com wrote:
On Mon, Sep 22, 2014 at 09:48:47AM -0600, Simon Glass wrote:
Select serial0 as the console.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/dts/am335x-bone-common.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/am335x-bone-common.dtsi b/arch/arm/dts/am335x-bone-common.dtsi index 2f66ded..e70b4d1 100644 --- a/arch/arm/dts/am335x-bone-common.dtsi +++ b/arch/arm/dts/am335x-bone-common.dtsi @@ -10,6 +10,10 @@ model = "TI AM335x BeagleBone"; compatible = "ti,am335x-bone", "ti,am33xx";
chosen {stdout-path = &uart0;};cpus { cpu@0 { cpu0-supply = <&dcdc2_reg>;So here's where I worry. The reason we have a Kconfig for CONS_INDEX is that there are boards it's NOT uart0. Setting aside the people with a "uart cape" (or otherwise breadboarding out another uart to a real connector), the industrial EVM is uart2 I want to say and we had been happily supporting this board with just a different build target (then defconfig). What can we do here? And yes, I see this is the bone DT not the EVM dt, but I'd rather not have to, if we don't have to at least, default to just not supporting the board (which is at least on the table, there's no DT for it in the kernel either).
I think we are looking for a build-time way to change the console. Is that right? I suppose we could use a #define in the device tree, set from some sort of include file / option, but that seems pretty ugly.
It does, yeah.
It would not be hard to modify the DT in the binary after it is built, if that helps.
We can certainly support a different build target with a different 'default' device tree. We would then have several .dts files all including the .dtsi for their main body.
Also there is a patch that I have not tidied/sent yet which builds all the .dtb files for a class of boards, so you can add the .dtb that you prefer to U-Boot with 'cat'.
We'll need that at some point, sooner rather than later since "am335x_evm" works on 4 distinct platforms, not counting the one where console is on a different UART than expected.
I'm open to various options here, but I'm not sure which is best for this use case.
I wonder how the kernel deals with this issue?
I think the answer for how the kernel deals with it is "out of tree". Maybe that's the good enough for now answer here too. It's just a matter of providing the correct device tree for the EVM in question, so maybe we just punt.
Hi Tom,
On 23 October 2014 14:45, Tom Rini trini@ti.com wrote:
On Wed, Oct 22, 2014 at 09:19:08PM -0600, Simon Glass wrote:
Hi Tom,
On 22 October 2014 09:59, Tom Rini trini@ti.com wrote:
On Mon, Sep 22, 2014 at 09:48:47AM -0600, Simon Glass wrote:
Select serial0 as the console.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/dts/am335x-bone-common.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/am335x-bone-common.dtsi b/arch/arm/dts/am335x-bone-common.dtsi index 2f66ded..e70b4d1 100644 --- a/arch/arm/dts/am335x-bone-common.dtsi +++ b/arch/arm/dts/am335x-bone-common.dtsi @@ -10,6 +10,10 @@ model = "TI AM335x BeagleBone"; compatible = "ti,am335x-bone", "ti,am33xx";
chosen {stdout-path = &uart0;};cpus { cpu@0 { cpu0-supply = <&dcdc2_reg>;So here's where I worry. The reason we have a Kconfig for CONS_INDEX is that there are boards it's NOT uart0. Setting aside the people with a "uart cape" (or otherwise breadboarding out another uart to a real connector), the industrial EVM is uart2 I want to say and we had been happily supporting this board with just a different build target (then defconfig). What can we do here? And yes, I see this is the bone DT not the EVM dt, but I'd rather not have to, if we don't have to at least, default to just not supporting the board (which is at least on the table, there's no DT for it in the kernel either).
I think we are looking for a build-time way to change the console. Is that right? I suppose we could use a #define in the device tree, set from some sort of include file / option, but that seems pretty ugly.
It does, yeah.
It would not be hard to modify the DT in the binary after it is built, if that helps.
We can certainly support a different build target with a different 'default' device tree. We would then have several .dts files all including the .dtsi for their main body.
Also there is a patch that I have not tidied/sent yet which builds all the .dtb files for a class of boards, so you can add the .dtb that you prefer to U-Boot with 'cat'.
We'll need that at some point, sooner rather than later since "am335x_evm" works on 4 distinct platforms, not counting the one where console is on a different UART than expected.
OK I'll see what I can do with this.
I'm open to various options here, but I'm not sure which is best for this use case.
I wonder how the kernel deals with this issue?
I think the answer for how the kernel deals with it is "out of tree". Maybe that's the good enough for now answer here too. It's just a matter of providing the correct device tree for the EVM in question, so maybe we just punt.
Well let's see if multi-dtb gets us somewhere towards the goal and then revisit it.
Regards, Simon
Add a separate internal helper function to get a GPIO value, so that we will be able to call it with the driver model version and avoid code duplication.
Also move gpio_get_bank() and check_gpio() down below the helper functions as these won't be needed with driver model.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/gpio/omap_gpio.c | 78 ++++++++++++++++++++++++++---------------------- 1 file changed, 42 insertions(+), 36 deletions(-)
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c index 13dcf79..d2d2640 100644 --- a/drivers/gpio/omap_gpio.c +++ b/drivers/gpio/omap_gpio.c @@ -26,11 +26,6 @@ #define OMAP_GPIO_DIR_OUT 0 #define OMAP_GPIO_DIR_IN 1
-static inline const struct gpio_bank *get_gpio_bank(int gpio) -{ - return &omap_gpio_bank[gpio >> 5]; -} - static inline int get_gpio_index(int gpio) { return gpio & 0x1f; @@ -41,15 +36,6 @@ int gpio_is_valid(int gpio) return (gpio >= 0) && (gpio < OMAP_MAX_GPIO); }
-static int check_gpio(int gpio) -{ - if (!gpio_is_valid(gpio)) { - printf("ERROR : check_gpio: invalid GPIO %d\n", gpio); - return -1; - } - return 0; -} - static void _set_gpio_direction(const struct gpio_bank *bank, int gpio, int is_input) { @@ -118,6 +104,46 @@ static void _set_gpio_dataout(const struct gpio_bank *bank, int gpio, __raw_writel(l, reg); }
+static int _get_gpio_value(const struct gpio_bank *bank, int gpio) +{ + void *reg = bank->base; + int input; + + switch (bank->method) { + case METHOD_GPIO_24XX: + input = _get_gpio_direction(bank, gpio); + switch (input) { + case OMAP_GPIO_DIR_IN: + reg += OMAP_GPIO_DATAIN; + break; + case OMAP_GPIO_DIR_OUT: + reg += OMAP_GPIO_DATAOUT; + break; + default: + return -1; + } + break; + default: + return -1; + } + + return (__raw_readl(reg) & (1 << gpio)) != 0; +} + +static inline const struct gpio_bank *get_gpio_bank(int gpio) +{ + return &omap_gpio_bank[gpio >> 5]; +} + +static int check_gpio(int gpio) +{ + if (!gpio_is_valid(gpio)) { + printf("ERROR : check_gpio: invalid GPIO %d\n", gpio); + return -1; + } + return 0; +} + /** * Set value of the specified gpio */ @@ -139,32 +165,12 @@ int gpio_set_value(unsigned gpio, int value) int gpio_get_value(unsigned gpio) { const struct gpio_bank *bank; - void *reg; - int input;
if (check_gpio(gpio) < 0) return -1; bank = get_gpio_bank(gpio); - reg = bank->base; - switch (bank->method) { - case METHOD_GPIO_24XX: - input = _get_gpio_direction(bank, get_gpio_index(gpio)); - switch (input) { - case OMAP_GPIO_DIR_IN: - reg += OMAP_GPIO_DATAIN; - break; - case OMAP_GPIO_DIR_OUT: - reg += OMAP_GPIO_DATAOUT; - break; - default: - return -1; - } - break; - default: - return -1; - } - return (__raw_readl(reg) - & (1 << get_gpio_index(gpio))) != 0; + + return _get_gpio_value(bank, get_gpio_index(gpio)); }
/**
On Mon, Sep 22, 2014 at 09:48:48AM -0600, Simon Glass wrote:
Add a separate internal helper function to get a GPIO value, so that we will be able to call it with the driver model version and avoid code duplication.
Also move gpio_get_bank() and check_gpio() down below the helper functions as these won't be needed with driver model.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
Add driver model support to this driver, while retaining support for the legacy system. Driver model GPIO support is enabled with CONFIG_DM_GPIO as usual.
Since gpio_is_valid() no longer exists, we can use the -EINVAL error returned from gpio_request().
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/arm/include/asm/omap_gpio.h | 19 +++- drivers/gpio/omap_gpio.c | 221 +++++++++++++++++++++++++++++++++++++++ drivers/mmc/omap_hsmmc.c | 15 ++- 3 files changed, 248 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/omap_gpio.h b/arch/arm/include/asm/omap_gpio.h index 5d25d04..839af54 100644 --- a/arch/arm/include/asm/omap_gpio.h +++ b/arch/arm/include/asm/omap_gpio.h @@ -23,6 +23,21 @@
#include <asm/arch/cpu.h>
+enum gpio_method { + METHOD_GPIO_24XX = 4, +}; + +#ifdef CONFIG_DM_GPIO + +/* Information about a GPIO bank */ +struct omap_gpio_platdata { + int bank_index; + ulong base; /* address of registers in physical memory */ + enum gpio_method method; +}; + +#else + struct gpio_bank { void *base; int method; @@ -30,8 +45,6 @@ struct gpio_bank {
extern const struct gpio_bank *const omap_gpio_bank;
-#define METHOD_GPIO_24XX 4 - /** * Check if gpio is valid. * @@ -39,4 +52,6 @@ extern const struct gpio_bank *const omap_gpio_bank; * @return 1 if ok, 0 on error */ int gpio_is_valid(int gpio); +#endif + #endif /* _GPIO_H_ */ diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c index d2d2640..a4651bc 100644 --- a/drivers/gpio/omap_gpio.c +++ b/drivers/gpio/omap_gpio.c @@ -19,6 +19,7 @@ * Written by Juha Yrjölä juha.yrjola@nokia.com */ #include <common.h> +#include <dm.h> #include <asm/gpio.h> #include <asm/io.h> #include <asm/errno.h> @@ -26,6 +27,20 @@ #define OMAP_GPIO_DIR_OUT 0 #define OMAP_GPIO_DIR_IN 1
+#ifdef CONFIG_DM_GPIO + +#define GPIO_NAME_SIZE 20 +#define GPIO_PER_BANK 32 + +struct gpio_bank { + char label[GPIO_PER_BANK][GPIO_NAME_SIZE]; + /* TODO(sjg@chromium.org): Can we use a struct here? */ + void *base; /* address of registers in physical memory */ + enum gpio_method method; +}; + +#endif + static inline int get_gpio_index(int gpio) { return gpio & 0x1f; @@ -130,6 +145,8 @@ static int _get_gpio_value(const struct gpio_bank *bank, int gpio) return (__raw_readl(reg) & (1 << gpio)) != 0; }
+#ifndef CONFIG_DM_GPIO + static inline const struct gpio_bank *get_gpio_bank(int gpio) { return &omap_gpio_bank[gpio >> 5]; @@ -226,3 +243,207 @@ int gpio_free(unsigned gpio) { return 0; } + +#else /* new driver model interface CONFIG_DM_GPIO */ + +/** + * gpio_is_requested() - check if a GPIO has been requested + * + * @bank: Bank to check + * @offset: GPIO offset within bank to check + * @return true if marked as requested, false if not + */ +static inline bool gpio_is_requested(struct gpio_bank *bank, int offset) +{ + return *bank->label[offset] != '\0'; +} + +static int omap_gpio_is_output(struct gpio_bank *bank, int offset) +{ + return _get_gpio_direction(bank, offset) == OMAP_GPIO_DIR_OUT; +} + +static int check_requested(struct udevice *dev, unsigned offset, + const char *func) +{ + struct gpio_bank *bank = dev_get_priv(dev); + struct gpio_dev_priv *uc_priv = dev->uclass_priv; + + if (!gpio_is_requested(bank, offset)) { + printf("omap_gpio: %s: error: gpio %s%d not requested\n", + func, uc_priv->bank_name, offset); + return -EPERM; + } + + return 0; +} + +/* set GPIO pin 'gpio' as an input */ +static int omap_gpio_direction_input(struct udevice *dev, unsigned offset) +{ + struct gpio_bank *bank = dev_get_priv(dev); + int ret; + + ret = check_requested(dev, offset, __func__); + if (ret) + return ret; + + /* Configure GPIO direction as input. */ + _set_gpio_direction(bank, offset, 1); + + return 0; +} + +/* set GPIO pin 'gpio' as an output, with polarity 'value' */ +static int omap_gpio_direction_output(struct udevice *dev, unsigned offset, + int value) +{ + struct gpio_bank *bank = dev_get_priv(dev); + int ret; + + ret = check_requested(dev, offset, __func__); + if (ret) + return ret; + + _set_gpio_dataout(bank, offset, value); + _set_gpio_direction(bank, offset, 0); + + return 0; +} + +/* read GPIO IN value of pin 'gpio' */ +static int omap_gpio_get_value(struct udevice *dev, unsigned offset) +{ + struct gpio_bank *bank = dev_get_priv(dev); + int ret; + + ret = check_requested(dev, offset, __func__); + if (ret) + return ret; + + return _get_gpio_value(bank, offset); +} + +/* write GPIO OUT value to pin 'gpio' */ +static int omap_gpio_set_value(struct udevice *dev, unsigned offset, + int value) +{ + struct gpio_bank *bank = dev_get_priv(dev); + int ret; + + ret = check_requested(dev, offset, __func__); + if (ret) + return ret; + + _set_gpio_dataout(bank, offset, value); + + return 0; +} + +static int omap_gpio_get_state(struct udevice *dev, unsigned int offset, + char *buf, int bufsize) +{ + struct gpio_dev_priv *uc_priv = dev->uclass_priv; + struct gpio_bank *bank = dev_get_priv(dev); + const char *label; + bool requested; + bool is_output; + int size; + + label = bank->label[offset]; + is_output = omap_gpio_is_output(bank->base, offset); + size = snprintf(buf, bufsize, "%s%d: ", + uc_priv->bank_name ? uc_priv->bank_name : "", offset); + buf += size; + bufsize -= size; + requested = gpio_is_requested(bank, offset); + snprintf(buf, bufsize, "%s: %d [%c]%s%s", + is_output ? "out" : " in", + _get_gpio_value(bank, offset), + requested ? 'x' : ' ', + requested ? " " : "", + label); + + return 0; +} + +static int omap_gpio_request(struct udevice *dev, unsigned offset, + const char *label) +{ + struct gpio_bank *bank = dev_get_priv(dev); + + if (gpio_is_requested(bank, offset)) + return -EBUSY; + + strncpy(bank->label[offset], label, GPIO_NAME_SIZE); + bank->label[offset][GPIO_NAME_SIZE - 1] = '\0'; + + return 0; +} + +static int omap_gpio_free(struct udevice *dev, unsigned offset) +{ + struct gpio_bank *bank = dev_get_priv(dev); + int ret; + + ret = check_requested(dev, offset, __func__); + if (ret) + return ret; + bank->label[offset][0] = '\0'; + + return 0; +} + +static int omap_gpio_get_function(struct udevice *dev, unsigned offset) +{ + struct gpio_bank *bank = dev_get_priv(dev); + + if (!gpio_is_requested(bank, offset)) + return GPIOF_UNUSED; + + /* GPIOF_FUNC is not implemented yet */ + if (_get_gpio_direction(bank->base, offset)) + return GPIOF_OUTPUT; + else + return GPIOF_INPUT; +} + +static const struct dm_gpio_ops gpio_omap_ops = { + .request = omap_gpio_request, + .free = omap_gpio_free, + .direction_input = omap_gpio_direction_input, + .direction_output = omap_gpio_direction_output, + .get_value = omap_gpio_get_value, + .set_value = omap_gpio_set_value, + .get_function = omap_gpio_get_function, + .get_state = omap_gpio_get_state, +}; + +static int omap_gpio_probe(struct udevice *dev) +{ + struct gpio_bank *bank = dev_get_priv(dev); + struct omap_gpio_platdata *plat = dev_get_platdata(dev); + struct gpio_dev_priv *uc_priv = dev->uclass_priv; + char name[18], *str; + + sprintf(name, "GPIO%d_", plat->bank_index); + str = strdup(name); + if (!str) + return -ENOMEM; + uc_priv->bank_name = str; + uc_priv->gpio_count = GPIO_PER_BANK; + bank->base = (void *)plat->base; + bank->method = plat->method; + + return 0; +} + +U_BOOT_DRIVER(gpio_omap) = { + .name = "gpio_omap", + .id = UCLASS_GPIO, + .ops = &gpio_omap_ops, + .probe = omap_gpio_probe, + .priv_auto_alloc_size = sizeof(struct gpio_bank), +}; + +#endif /* CONFIG_DM_GPIO */ diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index 5b0c302..ef2cbf9 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -67,14 +67,19 @@ static int mmc_write_data(struct hsmmc *mmc_base, const char *buf, #ifdef OMAP_HSMMC_USE_GPIO static int omap_mmc_setup_gpio_in(int gpio, const char *label) { - if (!gpio_is_valid(gpio)) - return -1; + int ret;
- if (gpio_request(gpio, label) < 0) +#ifndef CONFIG_DM_GPIO + if (!gpio_is_valid(gpio)) return -1; +#endif + ret = gpio_request(gpio, label); + if (ret) + return ret;
- if (gpio_direction_input(gpio) < 0) - return -1; + ret = gpio_direction_input(gpio); + if (ret) + return ret;
return gpio; }
On Mon, Sep 22, 2014 at 09:48:49AM -0600, Simon Glass wrote:
Add driver model support to this driver, while retaining support for the legacy system. Driver model GPIO support is enabled with CONFIG_DM_GPIO as usual.
Since gpio_is_valid() no longer exists, we can use the -EINVAL error returned from gpio_request().
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
Provide suitable platform data for am33xx boards, so that these boards can use driver model for GPIO access.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/arm/cpu/armv7/am33xx/board.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c index 828d10b..7aa8198 100644 --- a/arch/arm/cpu/armv7/am33xx/board.c +++ b/arch/arm/cpu/armv7/am33xx/board.c @@ -9,6 +9,7 @@ */
#include <common.h> +#include <dm.h> #include <errno.h> #include <spl.h> #include <asm/arch/cpu.h> @@ -36,6 +37,31 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_DM_GPIO +static const struct omap_gpio_platdata am33xx_gpio[] = { + { 0, AM33XX_GPIO0_BASE, METHOD_GPIO_24XX }, + { 1, AM33XX_GPIO1_BASE, METHOD_GPIO_24XX }, + { 2, AM33XX_GPIO2_BASE, METHOD_GPIO_24XX }, + { 3, AM33XX_GPIO3_BASE, METHOD_GPIO_24XX }, +#ifdef CONFIG_AM43XX + { 4, AM33XX_GPIO4_BASE, METHOD_GPIO_24XX }, + { 5, AM33XX_GPIO5_BASE, METHOD_GPIO_24XX }, +#endif +}; + +U_BOOT_DEVICES(am33xx_gpios) = { + { "gpio_omap", &am33xx_gpio[0] }, + { "gpio_omap", &am33xx_gpio[1] }, + { "gpio_omap", &am33xx_gpio[2] }, + { "gpio_omap", &am33xx_gpio[3] }, +#ifdef CONFIG_AM43XX + { "gpio_omap", &am33xx_gpio[4] }, + { "gpio_omap", &am33xx_gpio[5] }, +#endif +}; + +#else + static const struct gpio_bank gpio_bank_am33xx[] = { { (void *)AM33XX_GPIO0_BASE, METHOD_GPIO_24XX }, { (void *)AM33XX_GPIO1_BASE, METHOD_GPIO_24XX }, @@ -49,6 +75,8 @@ static const struct gpio_bank gpio_bank_am33xx[] = {
const struct gpio_bank *const omap_gpio_bank = gpio_bank_am33xx;
+#endif + #if defined(CONFIG_OMAP_HSMMC) && !defined(CONFIG_SPL_BUILD) int cpu_mmc_init(bd_t *bis) {
On Mon, Sep 22, 2014 at 09:48:50AM -0600, Simon Glass wrote:
Provide suitable platform data for am33xx boards, so that these boards can use driver model for GPIO access.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
Provide suitable platform data for am33xx boards, so that these boards can use driver model for serial.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/arm/cpu/armv7/am33xx/board.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c index 7aa8198..29b1d73 100644 --- a/arch/arm/cpu/armv7/am33xx/board.c +++ b/arch/arm/cpu/armv7/am33xx/board.c @@ -11,6 +11,7 @@ #include <common.h> #include <dm.h> #include <errno.h> +#include <ns16550.h> #include <spl.h> #include <asm/arch/cpu.h> #include <asm/arch/hardware.h> @@ -60,6 +61,38 @@ U_BOOT_DEVICES(am33xx_gpios) = { #endif };
+# ifndef CONFIG_OF_CONTROL +/* + * TODO(sjg@chromium.org): When we can move SPL serial to DM, we can remove + * the CONFIGs. At the same time, we should move this to the board files. + */ +static const struct ns16550_platdata am33xx_serial[] = { + { CONFIG_SYS_NS16550_COM1, 2, CONFIG_SYS_NS16550_CLK }, +# ifdef CONFIG_SYS_NS16550_COM2 + { CONFIG_SYS_NS16550_COM2, 2, CONFIG_SYS_NS16550_CLK }, +# ifdef CONFIG_SYS_NS16550_COM3 + { CONFIG_SYS_NS16550_COM3, 2, CONFIG_SYS_NS16550_CLK }, + { CONFIG_SYS_NS16550_COM4, 2, CONFIG_SYS_NS16550_CLK }, + { CONFIG_SYS_NS16550_COM5, 2, CONFIG_SYS_NS16550_CLK }, + { CONFIG_SYS_NS16550_COM6, 2, CONFIG_SYS_NS16550_CLK }, +# endif +# endif +}; + +U_BOOT_DEVICES(am33xx_uarts) = { + { "serial_omap", &am33xx_serial[0] }, +# ifdef CONFIG_SYS_NS16550_COM2 + { "serial_omap", &am33xx_serial[1] }, +# ifdef CONFIG_SYS_NS16550_COM3 + { "serial_omap", &am33xx_serial[2] }, + { "serial_omap", &am33xx_serial[3] }, + { "serial_omap", &am33xx_serial[4] }, + { "serial_omap", &am33xx_serial[5] }, +# endif +# endif +}; +# endif + #else
static const struct gpio_bank gpio_bank_am33xx[] = {
On Mon, Sep 22, 2014 at 09:48:51AM -0600, Simon Glass wrote:
Provide suitable platform data for am33xx boards, so that these boards can use driver model for serial.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@ti.com
Add driver model support to this driver, while retaining support for the legacy system. Driver model serial support is enabled with CONFIG_DM_SERIAL as usual.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/serial/Makefile | 1 + drivers/serial/serial_omap.c | 49 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+) create mode 100644 drivers/serial/serial_omap.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index 853a8c6..9ac3496 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -39,6 +39,7 @@ obj-$(CONFIG_FSL_LPUART) += serial_lpuart.o obj-$(CONFIG_MXS_AUART) += mxs_auart.o obj-$(CONFIG_ARC_SERIAL) += serial_arc.o obj-$(CONFIG_TEGRA_SERIAL) += serial_tegra.o +obj-$(CONFIG_OMAP_SERIAL) += serial_omap.o
ifndef CONFIG_SPL_BUILD obj-$(CONFIG_USB_TTY) += usbtty.o diff --git a/drivers/serial/serial_omap.c b/drivers/serial/serial_omap.c new file mode 100644 index 0000000..6866b21 --- /dev/null +++ b/drivers/serial/serial_omap.c @@ -0,0 +1,49 @@ +/* + * Copyright (c) 2014 Google, Inc + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <common.h> +#include <dm.h> +#include <fdtdec.h> +#include <ns16550.h> +#include <serial.h> + +DECLARE_GLOBAL_DATA_PTR; + +#ifdef CONFIG_OF_CONTROL +static const struct udevice_id omap_serial_ids[] = { + { .compatible = "ti,omap3-uart" }, + { } +}; + +static int omap_serial_ofdata_to_platdata(struct udevice *dev) +{ + struct ns16550_platdata *plat = dev_get_platdata(dev); + int ret; + + ret = ns16550_serial_ofdata_to_platdata(dev); + if (ret) + return ret; + plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset, + "clock-frequency", -1); + plat->reg_shift = 2; + + return 0; +} +#endif + +U_BOOT_DRIVER(serial_omap_ns16550) = { + .name = "serial_omap", + .id = UCLASS_SERIAL, +#ifdef CONFIG_OF_CONTROL + .of_match = omap_serial_ids, + .ofdata_to_platdata = omap_serial_ofdata_to_platdata, +#endif + .platdata_auto_alloc_size = sizeof(struct ns16550_platdata), + .priv_auto_alloc_size = sizeof(struct NS16550), + .probe = ns16550_serial_probe, + .ops = &ns16550_serial_ops, + .flags = DM_FLAG_PRE_RELOC, +};
Hi Simon,
One minor comment from me.
On Mon, 22 Sep 2014 09:48:52 -0600 Simon Glass sjg@chromium.org wrote:
+U_BOOT_DRIVER(serial_omap_ns16550) = {
- .name = "serial_omap",
- .id = UCLASS_SERIAL,
+#ifdef CONFIG_OF_CONTROL
- .of_match = omap_serial_ids,
- .ofdata_to_platdata = omap_serial_ofdata_to_platdata,
+#endif
- .platdata_auto_alloc_size = sizeof(struct ns16550_platdata),
- .priv_auto_alloc_size = sizeof(struct NS16550),
- .probe = ns16550_serial_probe,
- .ops = &ns16550_serial_ops,
- .flags = DM_FLAG_PRE_RELOC,
+};
U_BOOT_DRIVER(serial_omap_ns16550) = { .name = "serial_omap", .id = UCLASS_SERIAL, .of_match = of_match_ptr(omap_serial_ids), .ofdata_to_platdata = of_match_ptr(omap_serial_ofdata_to_platdata), .platdata_auto_alloc_size = sizeof(struct ns16550_platdata), .priv_auto_alloc_size = sizeof(struct NS16550), .probe = ns16550_serial_probe, .ops = &ns16550_serial_ops, .flags = DM_FLAG_PRE_RELOC, };
is cleaner though you need to apply the following first: http://patchwork.ozlabs.org/patch/397088/
Best Regards Masahiro Yamada
On Mon, Sep 22, 2014 at 09:48:52AM -0600, Simon Glass wrote:
Add driver model support to this driver, while retaining support for the legacy system. Driver model serial support is enabled with CONFIG_DM_SERIAL as usual.
Signed-off-by: Simon Glass sjg@chromium.org
Assuming you'll make the change Masahiro pointed out,
Reviewed-by: Tom Rini trini@ti.com
With these options in place it is not possible to change the serial port using 'make menuconfig' or similar. It seems to result in duplicate defines.
For example:
In file included from include/linux/kconfig.h:4:0, from <command-line>:0: include/generated/autoconf.h:20:0: note: this is the location of the previous definition #define CONFIG_CONS_INDEX 2 ^
The default option seems to be 1 anyway, in board/ti/am335x/Kconfig.
Remove the options so that we can adjust the serial port if required.
Signed-off-by: Simon Glass sjg@chromium.org ---
configs/am335x_boneblack_defconfig | 2 +- configs/am335x_boneblack_vboot_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig index 38450c0..b631c41 100644 --- a/configs/am335x_boneblack_defconfig +++ b/configs/am335x_boneblack_defconfig @@ -1,4 +1,4 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,EMMC_BOOT" +CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT" +S:CONFIG_ARM=y +S:CONFIG_TARGET_AM335X_EVM=y diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig index 00317c4..e6c5ee3 100644 --- a/configs/am335x_boneblack_vboot_defconfig +++ b/configs/am335x_boneblack_vboot_defconfig @@ -1,4 +1,4 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,EMMC_BOOT,ENABLE_VBOOT" +CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT,ENABLE_VBOOT" +S:CONFIG_ARM=y +S:CONFIG_TARGET_AM335X_EVM=y
On Mon, Sep 22, 2014 at 09:48:53AM -0600, Simon Glass wrote:
With these options in place it is not possible to change the serial port using 'make menuconfig' or similar. It seems to result in duplicate defines.
For example:
In file included from include/linux/kconfig.h:4:0, from <command-line>:0: include/generated/autoconf.h:20:0: note: this is the location of the previous definition #define CONFIG_CONS_INDEX 2 ^
The default option seems to be 1 anyway, in board/ti/am335x/Kconfig.
Remove the options so that we can adjust the serial port if required.
Signed-off-by: Simon Glass sjg@chromium.org
configs/am335x_boneblack_defconfig | 2 +- configs/am335x_boneblack_vboot_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig index 38450c0..b631c41 100644 --- a/configs/am335x_boneblack_defconfig +++ b/configs/am335x_boneblack_defconfig @@ -1,4 +1,4 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,EMMC_BOOT" +CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT" +S:CONFIG_ARM=y +S:CONFIG_TARGET_AM335X_EVM=y diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig index 00317c4..e6c5ee3 100644 --- a/configs/am335x_boneblack_vboot_defconfig +++ b/configs/am335x_boneblack_vboot_defconfig @@ -1,4 +1,4 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,EMMC_BOOT,ENABLE_VBOOT" +CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT,ENABLE_VBOOT" +S:CONFIG_ARM=y +S:CONFIG_TARGET_AM335X_EVM=y
Whoops, those should have been deleted when I deleted the rest of them from am335x*.
Acked-by: Tom Rini trini@ti.com
Adjust the configuration for the am33xx boards, including beaglebone black to use driver model.
This can be extended to other OMAP boards once platform data is provided for them.
Signed-off-by: Simon Glass sjg@chromium.org ---
include/configs/ti_am335x_common.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h index 80976e7..5ed86d9 100644 --- a/include/configs/ti_am335x_common.h +++ b/include/configs/ti_am335x_common.h @@ -19,12 +19,23 @@ #define CONFIG_SYS_TIMERBASE 0x48040000 /* Use Timer2 */ #define CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC
+#ifndef CONFIG_SPL_BUILD +# define CONFIG_DM +# define CONFIG_CMD_DM +# define CONFIG_DM_GPIO +# define CONFIG_DM_SERIAL +# define CONFIG_OMAP_SERIAL +# define CONFIG_SYS_MALLOC_F_LEN (1 << 10) +#endif + #include <asm/arch/omap.h>
/* NS16550 Configuration */ #define CONFIG_SYS_NS16550 +#ifdef CONFIG_SPL_BUILD #define CONFIG_SYS_NS16550_SERIAL #define CONFIG_SYS_NS16550_REG_SIZE (-4) +#endif #define CONFIG_SYS_NS16550_CLK 48000000
/* Network defines. */
On Mon, Sep 22, 2014 at 09:48:54AM -0600, Simon Glass wrote:
Adjust the configuration for the am33xx boards, including beaglebone black to use driver model.
This can be extended to other OMAP boards once platform data is provided for them.
Signed-off-by: Simon Glass sjg@chromium.org
What's missing for doing this in SPL as well?
Hi Tom,
On 22 October 2014 10:00, Tom Rini trini@ti.com wrote:
On Mon, Sep 22, 2014 at 09:48:54AM -0600, Simon Glass wrote:
Adjust the configuration for the am33xx boards, including beaglebone black to use driver model.
This can be extended to other OMAP boards once platform data is provided for them.
Signed-off-by: Simon Glass sjg@chromium.org
What's missing for doing this in SPL as well?
The SPL series has been sent but not enabled for OMAP yet. I'll need to look at it, but it should be minor.
Regards, Simon
On Wed, Oct 22, 2014 at 10:14:39AM -0600, Simon Glass wrote:
Hi Tom,
On 22 October 2014 10:00, Tom Rini trini@ti.com wrote:
On Mon, Sep 22, 2014 at 09:48:54AM -0600, Simon Glass wrote:
Adjust the configuration for the am33xx boards, including beaglebone black to use driver model.
This can be extended to other OMAP boards once platform data is provided for them.
Signed-off-by: Simon Glass sjg@chromium.org
What's missing for doing this in SPL as well?
The SPL series has been sent but not enabled for OMAP yet. I'll need to look at it, but it should be minor.
OK, thanks.
Acked-by: Tom Rini trini@ti.com
Hi,
On 22 September 2014 17:48, Simon Glass sjg@chromium.org wrote:
This series adjusts the serial and GPIO drivers, used by Beaglebone for example, to work with driver model. Since there are still boards using these drivers but not driver model, this adds new functionality rather than replacing what exists.
Several patches tweak and fix the existing driver model serial and GPIO implementation.
There are two Beaglebone Black configurations:
- Device tree control with verified boot
- No device tree control
The first uses device tree to select the serial console and provide information needed by the serial driver (similar to how things work on Tegra). The second uses platform data provided by a common board file.
Both are converted, so this is a good example of how to support both device tree and platform data if needed.
Are there any comments on this series please?
Regards, Simon
On Tue, Oct 14, 2014 at 09:26:51AM +0200, Simon Glass wrote:
Hi,
On 22 September 2014 17:48, Simon Glass sjg@chromium.org wrote:
This series adjusts the serial and GPIO drivers, used by Beaglebone for example, to work with driver model. Since there are still boards using these drivers but not driver model, this adds new functionality rather than replacing what exists.
Several patches tweak and fix the existing driver model serial and GPIO implementation.
There are two Beaglebone Black configurations:
- Device tree control with verified boot
- No device tree control
The first uses device tree to select the serial console and provide information needed by the serial driver (similar to how things work on Tegra). The second uses platform data provided by a common board file.
Both are converted, so this is a good example of how to support both device tree and platform data if needed.
Are there any comments on this series please?
As part of settling back into the groove, I need to fire these up on my am335x boards and go from there.
Hi Tom,
On 20 October 2014 09:13, Tom Rini trini@ti.com wrote:
On Tue, Oct 14, 2014 at 09:26:51AM +0200, Simon Glass wrote:
Hi,
On 22 September 2014 17:48, Simon Glass sjg@chromium.org wrote:
This series adjusts the serial and GPIO drivers, used by Beaglebone for example, to work with driver model. Since there are still boards using these drivers but not driver model, this adds new functionality rather than replacing what exists.
Several patches tweak and fix the existing driver model serial and GPIO implementation.
There are two Beaglebone Black configurations:
- Device tree control with verified boot
- No device tree control
The first uses device tree to select the serial console and provide information needed by the serial driver (similar to how things work on Tegra). The second uses platform data provided by a common board file.
Both are converted, so this is a good example of how to support both device tree and platform data if needed.
Are there any comments on this series please?
As part of settling back into the groove, I need to fire these up on my am335x boards and go from there.
Thanks for the comments. I plan to apply the v2 series to dm/master soon.
Regards, Simon
participants (3)
-
Masahiro Yamada -
Simon Glass -
Tom Rini