dm: omap: Provide access to driver model for am335x, and move boards

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

---

 drivers/serial/serial-uclass.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/serial/serial-uclass.c +0 -0

index aeaf2d2..522e551 100644

Select serial0 as the console.

Signed-off-by Simon Glass <[email protected]>

---

 arch/arm/dts/am335x-bone-common.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/dts/am335x-bone-common.dtsi +0 -0

index 2f66ded..e70b4d1 100644

Quoted 13 lines · Simon Glass

Select serial0 as the console.

Signed-off-by Simon Glass <[email protected]>

---

 arch/arm/dts/am335x-bone-common.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/dts/am335x-bone-common.dtsi +0 -0

index 2f66ded..e70b4d1 100644

arch/arm/dts/am335x-bone-common.dtsi line 19

Quoted 10 lines

arch/arm/dts/am335x-bone-common.dtsi +4 -0

@@ -10,6 +10,10 @@
      model = "TI AM335x BeagleBone";
      compatible = "ti,am335x-bone", "ti,am33xx";
 
+     chosen {
+             stdout-path = &uart0;
+     };
+
      cpus {
              cpu at 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 <[email protected]>

--
Tom

Hi Tom,

Quoted 27 lines · Tom Rini

Quoted 13 lines · Simon Glass

Select serial0 as the console.

Signed-off-by Simon Glass <[email protected]>

---

 arch/arm/dts/am335x-bone-common.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/dts/am335x-bone-common.dtsi +0 -0

index 2f66ded..e70b4d1 100644

arch/arm/dts/am335x-bone-common.dtsi line 19

Quoted 10 lines

arch/arm/dts/am335x-bone-common.dtsi +4 -0

@@ -10,6 +10,10 @@
      model = "TI AM335x BeagleBone";
      compatible = "ti,am335x-bone", "ti,am33xx";
 
+     chosen {
+             stdout-path = &uart0;
+     };
+
      cpus {
              cpu at 0 {
                      cpu0-supply = <&dcdc2_reg>;

So here's where I worry. The reason we have a Kconfig for CONS_INDEX is

Quoted 8 lines

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?

Quoted 39 lines · Simon Glass

Hi Tom,

Quoted 27 lines · Tom Rini

Quoted 13 lines · Simon Glass

Select serial0 as the console.

Signed-off-by Simon Glass <[email protected]>

---

 arch/arm/dts/am335x-bone-common.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/dts/am335x-bone-common.dtsi +0 -0

index 2f66ded..e70b4d1 100644

arch/arm/dts/am335x-bone-common.dtsi line 19

Quoted 10 lines

arch/arm/dts/am335x-bone-common.dtsi +4 -0

@@ -10,6 +10,10 @@
      model = "TI AM335x BeagleBone";
      compatible = "ti,am335x-bone", "ti,am33xx";
 
+     chosen {
+             stdout-path = &uart0;
+     };
+
      cpus {
              cpu at 0 {
                      cpu0-supply = <&dcdc2_reg>;

So here's where I worry. The reason we have a Kconfig for CONS_INDEX is

Quoted 8 lines

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).

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

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.

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 <[email protected]>

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 <[email protected]>

Provide suitable platform data for am33xx boards, so that these boards can use driver model for GPIO access.

Signed-off-by Simon Glass <[email protected]>

Provide suitable platform data for am33xx boards, so that these boards can use driver model for serial.

Signed-off-by Simon Glass <[email protected]>

drivers/serial/serial_omap.c new file +4 -0

+
+U_BOOT_DRIVER(serial_omap_ns16550) = {
+	.name	= "serial_omap",
+	.id	= UCLASS_SERIAL,

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 <[email protected]>

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 <[email protected]>

---

 configs/am335x_boneblack_defconfig       | 2 +-
 configs/am335x_boneblack_vboot_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

configs/am335x_boneblack_defconfig +1 -1

index 38450c0..b631c41 100644
@@ -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

configs/am335x_boneblack_vboot_defconfig +0 -0

index 00317c4..e6c5ee3 100644

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 <[email protected]>

Quoted 7 lines · Simon Glass

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 <[email protected]>

What's missing for doing this in SPL as well?

Hi Tom,

Quoted 8 lines · Tom Rini

Quoted 6 lines · Simon Glass

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.

Quoted 3 lines

Quoted 1 line

Signed-off-by Simon Glass <[email protected]>

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.

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.

Hi,

Quoted 13 lines · Simon Glass

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

Quoted 6 lines

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?

Quoted 20 lines · Simon Glass

Hi,

Quoted 17 lines · Simon Glass

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.

Quoted 4 lines

Quoted 2 lines

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.