arm: rpi: Enable USB and Ethernet driver model Raspberry Pi

For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically.

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

---

Hi Simon,

Quoted 3 lines · Simon Glass

For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically.

I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev->seq? It should already be unique in the DM, right? I was really looking forward to that all going away.

+Hans

Hi Joe,

Quoted 7 lines · Joe Hershberger

Hi Simon,

Quoted 3 lines · Simon Glass

For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically.

Quoted 4 lines

I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev->seq? It should already be unique in the DM, right? I was really looking forward to that all going away.

Ah, OK, sorry. Do you think we need a way of specifying the eth interface # as we do with aliases at present? We did have one but Han has just removed it :-)

Otherwise we'll just end up counting up from the last 'fixed' ethernet interface. Maybe that is good enough.

Hi Simon,

Quoted 12 lines · Simon Glass

+Hans

Hi Joe,

Quoted 7 lines · Joe Hershberger

Hi Simon,

Quoted 3 lines · Simon Glass

For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically.

Quoted 8 lines

Quoted 4 lines

I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev->seq? It should already be unique in the DM, right? I was really looking forward to that all going away.

Ah, OK, sorry. Do you think we need a way of specifying the eth interface # as we do with aliases at present? We did have one but Han has just removed it :-)

Can you reference where this happened. A quick search didn't turn it up for me.

Quoted 2 lines

Otherwise we'll just end up counting up from the last 'fixed' ethernet interface. Maybe that is good enough.

That's probably good enough, but some may prefer more explicit control.

Hi Joe,

Quoted 24 lines · Joe Hershberger

Hi Simon,

Quoted 12 lines · Simon Glass

+Hans

Hi Joe,

Quoted 7 lines · Joe Hershberger

Hi Simon,

Quoted 3 lines · Simon Glass

For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically.

Quoted 8 lines

Quoted 4 lines

I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev->seq? It should already be unique in the DM, right? I was really looking forward to that all going away.

Ah, OK, sorry. Do you think we need a way of specifying the eth interface # as we do with aliases at present? We did have one but Han has just removed it :-)

Quoted 6 lines

Can you reference where this happened. A quick search didn't turn it up for me.

Quoted 2 lines

Otherwise we'll just end up counting up from the last 'fixed' ethernet interface. Maybe that is good enough.

That's probably good enough, but some may prefer more explicit control.

The thread is here:

http://patchwork.ozlabs.org/patch/485637/

Before, we could I think add USB devices to the device tree and give them a specific number (although I never actually tested it), but that won't work now.

Hi Joe,

Quoted 36 lines · Simon Glass

Hi Joe,

Quoted 24 lines · Joe Hershberger

Hi Simon,

Quoted 12 lines · Simon Glass

+Hans

Hi Joe,

Quoted 7 lines · Joe Hershberger

Hi Simon,

Quoted 3 lines · Simon Glass

For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically.

Quoted 8 lines

Quoted 4 lines

I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev->seq? It should already be unique in the DM, right? I was really looking forward to that all going away.

Ah, OK, sorry. Do you think we need a way of specifying the eth interface # as we do with aliases at present? We did have one but Han has just removed it :-)

Quoted 6 lines

Can you reference where this happened. A quick search didn't turn it up for me.

Quoted 2 lines

Otherwise we'll just end up counting up from the last 'fixed' ethernet interface. Maybe that is good enough.

That's probably good enough, but some may prefer more explicit control.

The thread is here:

Quoted 5 lines

http://patchwork.ozlabs.org/patch/485637/

Before, we could I think add USB devices to the device tree and give them a specific number (although I never actually tested it), but that won't work now.

What are you thoughts on this? I'd like to bring this series in soon (the parts without rpi anyway).

Hi Simon,

Quoted 45 lines · Simon Glass

Hi Joe,

Quoted 41 lines · Simon Glass

Hi Joe,

Quoted 24 lines · Joe Hershberger

Hi Simon,

Quoted 12 lines · Simon Glass

+Hans

Hi Joe,

Quoted 7 lines · Joe Hershberger

Hi Simon,

Quoted 3 lines · Simon Glass

For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically.

Quoted 8 lines

Quoted 4 lines

I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev->seq? It should already be unique in the DM, right? I was really looking forward to that all going away.

Ah, OK, sorry. Do you think we need a way of specifying the eth interface # as we do with aliases at present? We did have one but Han has just removed it :-)

Quoted 6 lines

Can you reference where this happened. A quick search didn't turn it up for me.

Quoted 2 lines

Otherwise we'll just end up counting up from the last 'fixed' ethernet interface. Maybe that is good enough.

That's probably good enough, but some may prefer more explicit control.

The thread is here:

http://patchwork.ozlabs.org/patch/485637/

Before, we could I think add USB devices to the device tree and give them a specific number (although I never actually tested it), but that won't work now.

Quoted 2 lines

What are you thoughts on this? I'd like to bring this series in soon (the parts without rpi anyway).

I don't mind just having "one past wired Eth" as the starting point. If someone cares about specifying it in the device tree that can be added later without redoing what you are adding here, right?

This is required on some platforms, so add it.

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

---

 drivers/usb/eth/usb_ether.c | 1 +
 1 file changed, 1 insertion(+)

Put all global data in a structure and move (what will be) common code into common functions. This will make the driver-model conversion much easier.

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

---

 drivers/usb/host/dwc2.c | 150 ++++++++++++++++++++++++++++++++----------------
 1 file changed, 100 insertions(+), 50 deletions(-)

Add driver model support to this driver so it can be used with the new USB stack.

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

---

 drivers/usb/host/dwc2.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)

Tidy up the include file order before adding more.

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

---

 drivers/usb/eth/smsc95xx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

The AX_ prefix comes from the Asix driver. Since this is not that, we should avoid this confusing prefix.

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

---

 drivers/usb/eth/smsc95xx.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

Instead of returning -1 on error, we should use a proper error number. Fix the code to conform to this.

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

---

 drivers/usb/eth/smsc95xx.c | 48 +++++++++++++++++++++++++---------------------
 1 file changed, 26 insertions(+), 22 deletions(-)

At present struct eth_device is passed around all over the place. This does not exist with driver model. Add explicit arguments instead, so that with driver model we can pass the correct things.

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

---

 drivers/usb/eth/smsc95xx.c | 270 +++++++++++++++++++++++++--------------------
 1 file changed, 149 insertions(+), 121 deletions(-)

Add support for driver model, so that CONFIG_DM_ETH can be defined and used with this driver.

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

---

 drivers/usb/eth/smsc95xx.c | 142 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 142 insertions(+)

-----Original Message-----
From: Simon Glass [mailto:sjg at google.com] On Behalf Of Simon Glass
Sent: Tuesday, July 07, 2015 7:54 PM
To: U-Boot Mailing List
Cc: Stephen Warren; Stephen Warren; Joe Hershberger; Masahiro Yamada; Simon Glass; Linus Walleij; Masahiro Yamada; Marek Vasut; Tom Rini; Albert Aribaud; Vikas MANOCHA; Pavel Herrmann
Subject: [PATCH 11/20] dm: serial: Update binding for PL01x serial UART

This binding differs from that of Linux. Update it and change existing users.

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

---

 arch/arm/dts/stv0991.dts                  |  2 +-
 doc/device-tree-bindings/serial/pl011.txt | 53
+++++++++++++++++++++++++++++++  doc/device-tree-
bindings/serial/pl01x.txt |  7 ----
 drivers/serial/serial_pl01x.c             |  6 ++--
 4 files changed, 58 insertions(+), 10 deletions(-)  create mode 100644
doc/device-tree-bindings/serial/pl011.txt
 delete mode 100644 doc/device-tree-bindings/serial/pl01x.txt

arch/arm/dts/stv0991.dts index renamed from arch/arm/dts/stv0991.dts +0 -0

b25c48b..fd425b4 100644

arch/arm/dts/stv0991.dts +0 -0

 	};
 };

doc/device-tree- renamed from doc/device-tree-bindings/serial/pl011.txt +0 -0

bindings/serial/pl011.txt
new file mode 100644
index 0000000..af66272

doc/device-tree-bindings/serial/pl011.txt new file +43 -0

@@ -0,0 +1,53 @@
+* ARM AMBA Primecell PL011 serial UART
+
+Required properties:
+- compatible: must be "arm,primecell", "arm,pl011"
+- reg: exactly one register range with length 0x1000
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl:
+	   When present, must have one state named "default",
+	   and may contain a second name named "sleep". The former
+	   state sets up pins for ordinary operation whereas
+	   the latter state will put the associated pins to sleep
+	   when the UART is unused
+- clocks:
+	   When present, the first clock listed must correspond to
+	   the clock named UARTCLK on the IP block, i.e. the clock
+	   to the external serial line, whereas the second clock
+	   must correspond to the PCLK clocking the internal logic
+	   of the block. Just listing one clock (the first one) is
+	   deprecated.
+- clocks-names:
+	   When present, the first clock listed must be named
+	   "uartclk" and the second clock listed must be named
+	   "apb_pclk"
+- dmas:
+	   When present, may have one or two dma channels.
+	   The first one must be named "rx", the second one
+	   must be named "tx".
+- auto-poll:
+	   Enables polling when using RX DMA.
+- poll-rate-ms:
+	   Rate at which poll occurs when auto-poll is set,
+	   default 100ms.
+- poll-timeout-ms:
+	   Poll timeout when auto-poll is set, default
+	   3000ms.
+- clock-frequency:
+	   Input clock frequency for UART.
+
+See also bindings/arm/primecell.txt
+
+Example:

doc/device-tree- renamed from doc/device-tree-bindings/serial/pl01x.txt +0 -0

bindings/serial/pl01x.txt
deleted file mode 100644
index 61c27d1..0000000

drivers/serial/serial_pl01x.c index renamed from drivers/serial/serial_pl01x.c +0 -0

ad503af..ae6fc0e 100644

drivers/serial/serial_pl01x.c +4 -2

@@ -365,13 +365,15 @@ static int pl01x_serial_ofdata_to_platdata(struct
 udevice *dev)
 	struct pl01x_serial_platdata *plat = dev_get_platdata(dev);
 	fdt_addr_t addr;
 
-	addr = fdtdec_get_addr(gd->fdt_blob, dev->of_offset, "reg");
+	addr = dev_get_addr(dev);
 	if (addr == FDT_ADDR_T_NONE)
 		return -EINVAL;
 
 	plat->base = addr;
-	plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "clock",
 1);
+	plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+				     "clock-frequency", 1);
 	plat->type = dev_get_driver_data(dev);
+
 	return 0;

}
#endif
--
2.4.3.573.g4eafbef

This binding differs from that of Linux. Update it and change existing users.

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

+- clock-frequency:
+          Input clock frequency for UART.

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

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

I'm confused by this. Isn't [email protected] the place to discuss device tree bindings? This is sent only to the U-Boot list, does this mean
that there will now be *two* ontologies for DT bindings? That sounds like
a recepie for ... something not good.

Quoted 2 lines

+- clock-frequency:
+          Input clock frequency for UART.

This is the real trick is it not?

Is the real commit blurb for this patch something like:

"we want a simple way to look up the clock frequency for our serial ports during early boot, and following clocks = <&...> phandles is too much trouble and might imply having to implement a whole clock framework in U-Boot so we just see a lot of trouble, instead provide a default frequency here"

I suggest in that case, instead do this:

- boot-frequency:
input clock frequency at boot time, to be used by boot loaders and other early access.

This would be good for early Linux stuff as well I believe and I do not think it's very controversial.

The CHRP ISA binding defines that a 8250 compatible UART must have this property:

"clock-frequency" S

Standard property, encoded as with encode-int, that shall be the baud-rate generator's clock input frequency (in hertz).
Typically, the clock frequency is nominally 1,843,200 Hz. Some devices generate the baud rate input clock by dividing a higher-frequency clock source that is not an exact multiple of 1,843,200 Hz, resulting in a small but acceptable error in the nominal clock frequency. In such cases, the "clock-frequency" shall report the actual nominal frequency. For example, if the baud rate input clock is generated by dividing a 24 MHz clock by 13, the value of the "clock-frequency" property shall be 1846153.

Quoted 5 lines · Arnd Bergmann

The CHRP ISA binding defines that a 8250 compatible UART must have this property:

"clock-frequency" S

Quoted 9 lines

Standard property, encoded as with encode-int, that shall be the baud-rate generator's clock input frequency (in hertz).
Typically, the clock frequency is nominally 1,843,200 Hz. Some devices generate the baud rate input clock by dividing a higher-frequency clock source that is not an exact multiple of 1,843,200 Hz, resulting in a small but acceptable error in the nominal clock frequency. In such cases, the "clock-frequency" shall report the actual nominal frequency. For example, if the baud rate input clock is generated by dividing a 24 MHz clock by 13, the value of the "clock-frequency" property shall be 1846153.

Isn't that for the case where the clock frequency will never change at runtime?

The problem (I think) with many systems using PL011 is that they can actually change the serial port clock at runtime (software controlled clock), so providing a "clock-frequency" would imply that they cannot, and the clock frequency is fixed to that value.

I think it's better to use boot-clock-frequency or so to indicate that a richer OS will provide more refined clocks. For example that frequency can typically change if the SoC changes operating point or so, though it would be awkward to handle in the driver, admittedly and I haven't seen a piece of code that actually go and change the UART input frequency.

Still for completion it is better for the UART to tie into the clk framework as the OS gets up, and just providing clock-frequency seems to imply that it need not do that or something. The semantical effect of providing both clock-frequency = and clocks =< &..> must be clarified in any case. Like the latter overrides the former if clock phandles can be handled by the environment. (And this should be stated in the binding.)

Quoted 30 lines · On Wednesday 15 July 2015 12:08:05 Linus Walleij wrote:

Quoted 5 lines · Arnd Bergmann

The CHRP ISA binding defines that a 8250 compatible UART must have this property:

"clock-frequency" S

Quoted 9 lines

Standard property, encoded as with encode-int, that shall be the baud-rate generator's clock input frequency (in hertz).
Typically, the clock frequency is nominally 1,843,200 Hz. Some devices generate the baud rate input clock by dividing a higher-frequency clock source that is not an exact multiple of 1,843,200 Hz, resulting in a small but acceptable error in the nominal clock frequency. In such cases, the "clock-frequency" shall report the actual nominal frequency. For example, if the baud rate input clock is generated by dividing a 24 MHz clock by 13, the value of the "clock-frequency" property shall be 1846153.

Isn't that for the case where the clock frequency will never change at runtime?

The problem (I think) with many systems using PL011 is that they can actually change the serial port clock at runtime (software controlled clock), so providing a "clock-frequency" would imply that they cannot, and the clock frequency is fixed to that value.

I think it's better to use boot-clock-frequency or so to indicate that a richer OS will provide more refined clocks. For example that frequency can typically change if the SoC changes operating point or so, though it would be awkward to handle in the driver, admittedly and I haven't seen a piece of code that actually go and change the UART input frequency.

Quoted 6 lines

Still for completion it is better for the UART to tie into the clk framework as the OS gets up, and just providing clock-frequency seems to imply that it need not do that or something. The semantical effect of providing both clock-frequency = and clocks =< &..> must be clarified in any case. Like the latter overrides the former if clock phandles can be handled by the environment. (And this should be stated in the binding.)

Ah right. I don't think that naming is super critical though, as a lot of properties in the DT just describe how things are at boot time.

Quoted 2 lines

Ah right. I don't think that naming is super critical though, as a lot of properties in the DT just describe how things are at boot time.

Hence those don't describe the hardware...
Shouldn't they be in /chosen instead?

The 'ranges' property can be used to specify a translation from the system address to the bus address. Add support for this using the dev_get_addr() function, which devices should use to find their address.

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

---

 drivers/core/device.c        | 17 +++++++++++------
 drivers/core/simple-bus.c    | 30 ++++++++++++++++++++++++++++++
 include/dm/device-internal.h | 12 ++++++++++++
 3 files changed, 53 insertions(+), 6 deletions(-)

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

Quoted 3 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

Quoted 3 lines

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

absolutely must be done, please note that there are many more RPi models than there are currently DT files for in the upstream kernel. I keep meaning to add a complete set of DT files to the kernel, but haven't gotten around to it yet. Take a look at board/raspberrypi/rpi/rpi.c:models[] for a likely list of the different DTs we'd need.

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

Quoted 4 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Quoted 11 lines · Simon Glass

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

Quoted 8 lines

Quoted 4 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

With a DT, we either have to:

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

Neither of those options seem like a good idea to me.

Hi Stephen,

Quoted 32 lines · Stephen Warren

Quoted 11 lines · Simon Glass

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

Quoted 8 lines

Quoted 4 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

With a DT, we either have to:

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

Quoted 1 line

Neither of those options seem like a good idea to me.

How about:

c) Leave the code as is, and not add a whole lot more device tree files.

After all the kernel only has files for rpi and rpi_2. Why should we add one for each variant? If you don't want to do it, why do it?

Quoted 35 lines · Simon Glass

Hi Stephen,

Quoted 32 lines · Stephen Warren

Quoted 11 lines · Simon Glass

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

Quoted 8 lines

Quoted 4 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

With a DT, we either have to:

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

Quoted 8 lines

Quoted 1 line

Neither of those options seem like a good idea to me.

How about:

c) Leave the code as is, and not add a whole lot more device tree files.

After all the kernel only has files for rpi and rpi_2. Why should we add one for each variant? If you don't want to do it, why do it?

For the kernel I do expect to add a DT file for each variant. That makes sense since we expect a single kernel binary to run unmodified on all HW, parameterize the HW setup via the DTB, and have an infrastructure to pass the different DTs to the kernel easily.

For U-Boot, I'd like to continue to have a single-binary that runs on all RPis (well, one for RPi 1, another for RPi 2). That's a very nice usage model for users. That's not possible if U-Boot pulls everything from DT and we have a different DT for each system (which only makes sense so that we don't lie in the DT, or fail to represent the differences between the models) since a single DT is embedded into the U-Boot binary; there's no infra-structure to passing 1 of n DTBs to U-Boot.

Quoted 60 lines · Stephen Warren

Quoted 44 lines · Simon Glass

Hi Stephen,

Quoted 31 lines · Stephen Warren

Quoted 20 lines · Simon Glass

Hi Stephen,

Quoted 9 lines · Stephen Warren

Quoted 7 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following: - Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of u-boot.bin)

Quoted 6 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Quoted 3 lines

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

With a DT, we either have to:

Quoted 8 lines

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

Neither of those options seem like a good idea to me.

Quoted 8 lines

How about:

c) Leave the code as is, and not add a whole lot more device tree files.

After all the kernel only has files for rpi and rpi_2. Why should we add one for each variant? If you don't want to do it, why do it?

For the kernel I do expect to add a DT file for each variant. That makes sense since we expect a single kernel binary to run unmodified on all HW, parameterize the HW setup via the DTB, and have an infrastructure to pass the different DTs to the kernel easily.

Quoted 8 lines

For U-Boot, I'd like to continue to have a single-binary that runs on all RPis (well, one for RPi 1, another for RPi 2). That's a very nice usage model for users. That's not possible if U-Boot pulls everything from DT and we have a different DT for each system (which only makes sense so that we don't lie in the DT, or fail to represent the differences between the models) since a single DT is embedded into the U-Boot binary; there's no infra-structure to passing 1 of n DTBs to U-Boot.

So my question is, for what U-Boot needs, can we have 1 DT for RPi 1 (that's not lying about what the HW can do) and 1 DT for RPi 2? This is the kind of question I'm frankly strugling with right now on converting more of the TI boards to be DT based as well.

Quoted 70 lines · Tom Rini

Quoted 60 lines · Stephen Warren

Quoted 44 lines · Simon Glass

Hi Stephen,

Quoted 31 lines · Stephen Warren

Quoted 20 lines · Simon Glass

Hi Stephen,

Quoted 9 lines · Stephen Warren

Quoted 7 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following: - Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of u-boot.bin)

Quoted 6 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Quoted 3 lines

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

With a DT, we either have to:

Quoted 8 lines

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

Neither of those options seem like a good idea to me.

Quoted 8 lines

How about:

c) Leave the code as is, and not add a whole lot more device tree files.

After all the kernel only has files for rpi and rpi_2. Why should we add one for each variant? If you don't want to do it, why do it?

For the kernel I do expect to add a DT file for each variant. That makes sense since we expect a single kernel binary to run unmodified on all HW, parameterize the HW setup via the DTB, and have an infrastructure to pass the different DTs to the kernel easily.

Quoted 8 lines

For U-Boot, I'd like to continue to have a single-binary that runs on all RPis (well, one for RPi 1, another for RPi 2). That's a very nice usage model for users. That's not possible if U-Boot pulls everything from DT and we have a different DT for each system (which only makes sense so that we don't lie in the DT, or fail to represent the differences between the models) since a single DT is embedded into the U-Boot binary; there's no infra-structure to passing 1 of n DTBs to U-Boot.

Quoted 4 lines

So my question is, for what U-Boot needs, can we have 1 DT for RPi 1 (that's not lying about what the HW can do) and 1 DT for RPi 2? This is the kind of question I'm frankly strugling with right now on converting more of the TI boards to be DT based as well.

This would be possible iff all the HW that U-Boot interacts with is identical on all relevant systems and we simply leave out all the other details that U-Boot doesn't care about (or any differences that exist can be probed via standard protocols such as USB).

Right now, I think that's possible on the RPi.

However, this limits U-Boot's ability to support all HW. If we wanted U-Boot to fully support all features of the HW, this limited DT wouldn't be sufficient. Examples of potential issues are:

a) On RPis that contain the USB hub + Ethernet chip, there's a GPIO that feeds into that chip's enable pin. Right now, U-Boot relies on either the HW default being sufficient to turn that pin on, or perhaps the binary FW that runs before U-Boot does this. However, U-Boot really should set the GPIO itself so that it doesn't rely on HW state set up before it runs. It should also do this only on systems with the USB+LAN chip; we don't have the full schematics for all RPi boards so there's no guarantee the same GPIO doesn't do something else on some boards, especially in the future.

b) I2S (digital audio) output is present on some boards. Someone might want U-Boot to play a startup sound, or make a warning beep under certain error conditions. It's not /that/ likely, but similar features have been implemented on other boards. The availability of I2S outputs varies from model to model.

c) If we want to expose the GPIOs on the expansion header, the set of GPIOs that it's useful to expose varies between boards.

We could probably think of other issues too.

To handle all of these, we'd either have to have separate DTs for the different cases, or represent the differences in code. Having multiple DTs has the issues I mentioned previously. By the time we represent part of the HW structure in code, it's far simpler to just represent it all in that one place. C structs are (currently at least) better than DT for representing this information anyway; the C compiler does a lot more error-checking when initializing structs than dtc can do for example, and code-sharing between boards is easier.

Quoted 76 lines · Stephen Warren

Quoted 70 lines · Tom Rini

Quoted 60 lines · Stephen Warren

Quoted 44 lines · Simon Glass

Hi Stephen,

Quoted 31 lines · Stephen Warren

Quoted 20 lines · Simon Glass

Hi Stephen,

Quoted 9 lines · Stephen Warren

Quoted 7 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following: - Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of u-boot.bin)

Quoted 6 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Quoted 3 lines

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

With a DT, we either have to:

Quoted 8 lines

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

Neither of those options seem like a good idea to me.

Quoted 8 lines

How about:

c) Leave the code as is, and not add a whole lot more device tree files.

After all the kernel only has files for rpi and rpi_2. Why should we add one for each variant? If you don't want to do it, why do it?

For the kernel I do expect to add a DT file for each variant. That makes sense since we expect a single kernel binary to run unmodified on all HW, parameterize the HW setup via the DTB, and have an infrastructure to pass the different DTs to the kernel easily.

Quoted 8 lines

For U-Boot, I'd like to continue to have a single-binary that runs on all RPis (well, one for RPi 1, another for RPi 2). That's a very nice usage model for users. That's not possible if U-Boot pulls everything from DT and we have a different DT for each system (which only makes sense so that we don't lie in the DT, or fail to represent the differences between the models) since a single DT is embedded into the U-Boot binary; there's no infra-structure to passing 1 of n DTBs to U-Boot.

Quoted 4 lines

So my question is, for what U-Boot needs, can we have 1 DT for RPi 1 (that's not lying about what the HW can do) and 1 DT for RPi 2? This is the kind of question I'm frankly strugling with right now on converting more of the TI boards to be DT based as well.

Quoted 4 lines

This would be possible iff all the HW that U-Boot interacts with is identical on all relevant systems and we simply leave out all the other details that U-Boot doesn't care about (or any differences that exist can be probed via standard protocols such as USB).

Exactly.

Quoted 1 line

Right now, I think that's possible on the RPi.

That's good..

Quoted 25 lines

However, this limits U-Boot's ability to support all HW. If we wanted U-Boot to fully support all features of the HW, this limited DT wouldn't be sufficient. Examples of potential issues are:

a) On RPis that contain the USB hub + Ethernet chip, there's a GPIO that feeds into that chip's enable pin. Right now, U-Boot relies on either the HW default being sufficient to turn that pin on, or perhaps the binary FW that runs before U-Boot does this. However, U-Boot really should set the GPIO itself so that it doesn't rely on HW state set up before it runs. It should also do this only on systems with the USB+LAN chip; we don't have the full schematics for all RPi boards so there's no guarantee the same GPIO doesn't do something else on some boards, especially in the future.

b) I2S (digital audio) output is present on some boards. Someone might want U-Boot to play a startup sound, or make a warning beep under certain error conditions. It's not /that/ likely, but similar features have been implemented on other boards. The availability of I2S outputs varies from model to model.

c) If we want to expose the GPIOs on the expansion header, the set of GPIOs that it's useful to expose varies between boards.

We could probably think of other issues too.

Quoted 8 lines

To handle all of these, we'd either have to have separate DTs for the different cases, or represent the differences in code. Having multiple DTs has the issues I mentioned previously. By the time we represent part of the HW structure in code, it's far simpler to just represent it all in that one place. C structs are (currently at least) better than DT for representing this information anyway; the C compiler does a lot more error-checking when initializing structs than dtc can do for example, and code-sharing between boards is easier.

Maybe examples like these are why we will need (and want) to keep platform data as a possibility in our DM work. There's value in keeping the DT that we use as minimal as possible (so that it can work as broadly as possible) and then do run-time fixups. The other option here might be something like device tree overlays or at least exposing the running DT (... more readily, I bet you could kludge it today) so that the existing cli infrasturcture can modify it).

On 28 July 2015 at 07:55, Tom Rini <[email protected]> wrote:

Quoted 7 lines

Maybe examples like these are why we will need (and want) to keep platform data as a possibility in our DM work. There's value in keeping the DT that we use as minimal as possible (so that it can work as broadly as possible) and then do run-time fixups. The other option here might be something like device tree overlays or at least exposing the running DT (... more readily, I bet you could kludge it today) so that the existing cli infrasturcture can modify it).

I really like the idea of keeping the DT minimal rather than slavishing adding a whole lot of detail for every board. If things can be probed then I think it is acceptable to probe them to avoid an explosion of DTs. We can do run-time fix ups even if they are currently not very efficient. The 'fdt' command can modify the running FDT I think, but it currently breaks everything since by then we have devices and have recorded the DT offsets. We could add a DT library to fix this, but for now fix-ups need to be done before relocation.

Quoted 79 lines · Stephen Warren

Quoted 72 lines · Tom Rini

Quoted 61 lines · Stephen Warren

Quoted 45 lines · Simon Glass

Hi Stephen,

Quoted 32 lines · Stephen Warren

Quoted 20 lines · Simon Glass

Hi Stephen,

Quoted 9 lines · Stephen Warren

Quoted 7 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following: - Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of u-boot.bin)

Quoted 6 lines

I'd strongly prefer not to do this. For one thing, it
means we'd need different U-Boot builds for each of
the different RPi models, and we currently don't need that (or perhaps we require users to create their own
u-boot-dtb.bin by choosing the right DTB to append).
If it

Quoted 4 lines

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It
doesn't look like rpi_board_rev is used anywhere
else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external
influence.

With a DT, we either have to:

Quoted 8 lines

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

Neither of those options seem like a good idea to me.

Quoted 8 lines

How about:

c) Leave the code as is, and not add a whole lot more device tree files.

After all the kernel only has files for rpi and rpi_2. Why
should we add one for each variant? If you don't want to
do it, why do it?

For the kernel I do expect to add a DT file for each variant.
That makes sense since we expect a single kernel binary to
run unmodified on all HW, parameterize the HW setup via the DTB, and have an infrastructure to pass the different DTs to the kernel easily.

Quoted 8 lines

For U-Boot, I'd like to continue to have a single-binary that
runs on all RPis (well, one for RPi 1, another for RPi 2).
That's a very nice usage model for users. That's not possible if U-Boot pulls everything from DT and we have a different DT for each system (which only makes sense so that we don't lie in the DT, or fail to represent the differences between the models) since a single DT is embedded into the U-Boot binary; there's no infra-structure to passing 1 of n DTBs to U-Boot.

Quoted 5 lines

So my question is, for what U-Boot needs, can we have 1 DT for RPi 1 (that's not lying about what the HW can do) and 1 DT for RPi 2? This is the kind of question I'm frankly strugling with right now on converting more of the TI boards to be DT based as well.

Quoted 5 lines

This would be possible iff all the HW that U-Boot interacts with is identical on all relevant systems and we simply leave out all the other details that U-Boot doesn't care about (or any differences that exist can be probed via standard protocols such as USB).

Exactly.

Quoted 1 line

Right now, I think that's possible on the RPi.

That's good..

Quoted 27 lines

However, this limits U-Boot's ability to support all HW. If we wanted U-Boot to fully support all features of the HW, this limited DT wouldn't be sufficient. Examples of potential issues are:

a) On RPis that contain the USB hub + Ethernet chip, there's a GPIO that feeds into that chip's enable pin. Right now, U-Boot relies on either the HW default being sufficient to turn that pin on, or perhaps the binary FW that runs before U-Boot does this. However, U-Boot really should set the GPIO itself so that it doesn't rely on HW state set up before it runs. It should also do this only on systems with the USB+LAN chip; we don't have the full schematics for all RPi boards so there's no guarantee the same GPIO doesn't do something else on some boards, especially in the future.

b) I2S (digital audio) output is present on some boards. Someone might want U-Boot to play a startup sound, or make a warning beep under certain error conditions. It's not /that/ likely, but similar features have been implemented on other boards. The availability of I2S outputs varies from model to model.

c) If we want to expose the GPIOs on the expansion header, the set of GPIOs that it's useful to expose varies between boards.

We could probably think of other issues too.

Quoted 9 lines

To handle all of these, we'd either have to have separate DTs for the different cases, or represent the differences in code. Having multiple DTs has the issues I mentioned previously. By the time we represent part of the HW structure in code, it's far simpler to just represent it all in that one place. C structs are (currently at least) better than DT for representing this information anyway; the C compiler does a lot more error-checking when initializing structs than dtc can do for example, and code-sharing between boards is easier.

Maybe examples like these are why we will need (and want) to keep platform data as a possibility in our DM work. There's value in keeping the DT that we use as minimal as possible (so that it can work as broadly as possible) and then do run-time fixups. The other option here might be something like device tree overlays or at least exposing the running DT (... more readily, I bet you could kludge it today) so that the existing cli infrasturcture can modify it).

Quoted 11 lines · Simon Glass

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

Quoted 8 lines

Quoted 4 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

With a DT, we either have to:

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

Neither of those options seem like a good idea to me.

Quoted 21 lines · Stephen Warren

Quoted 11 lines · Simon Glass

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

Quoted 8 lines

Quoted 4 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Quoted 7 lines

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

With a DT, we either have to:

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

Is that an option? I mean... if you can tolerate incorrect values for something, perhaps that something should not be in the dtb in the first place?

Quoted 2 lines

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

d) Build U-Boot + set of DTB images, then pick up the right one at the runtime?

Quoted 1 line

Neither of those options seem like a good idea to me.

Stuff that can be autodetected does not belong to the device tree...

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Quoted 24 lines · Stephen Warren

Quoted 11 lines · Simon Glass

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

Quoted 8 lines

Quoted 4 lines

I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it

Why does device tree change how things work now? The get_board_rev() function currently deals with this. It doesn't look like rpi_board_rev is used anywhere else.

Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.

Quoted 4 lines

With a DT, we either have to:

a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.

Is that an option? I mean... if you can tolerate incorrect values for something, perhaps that something should not be in the dtb in the first place?

Quoted 2 lines

b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.

d) Build U-Boot + set of DTB images, then pick up the right one at the runtime?

Quoted 1 line

Neither of those options seem like a good idea to me.

Stuff that can be autodetected does not belong to the device tree...

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

- Remove GPIO platform data (now uses device tree)
- Remove serial platform data (now uses device tree)
- Add 'ranges' support to simple-bus
- Convert the DWC2 USB driver to support driver model
- Convert the SMSC95XX USB Ethernet driver to support driver model
- Enable CONFIG_DM_ETH and CONFIG_DM_USB on Raspberry Pi

With Ethernet active the device list looks something like this:

U-Boot> dm tree
Class Probed Name
----------------------------------------

 root        [ + ]    root_driver
 simple_bus  [ + ]    |-- soc
 gpio        [   ]    |   |-- gpio at 7e200000
 serial      [ + ]    |   |-- uart at 7e201000
 usb         [ + ]    |   `-- usb at 7e980000
 usb_hub     [ + ]    |       `-- usb_hub
 usb_hub     [ + ]    |           `-- usb_hub
 eth         [ + ]    |               `-- smsc95xx_eth
 simple_bus  [   ]    `-- clocks

Raspberry Pi 2 is not converted as I do not have one to test at present.

Simon Glass (20):
dm: net: Support usbethaddr environment variable
dm: usb: Allow USB Ethernet whenever CONFIG_DM_ETH is not defined
dm: usb: Add an errno.h header to usb_ether.c
dm: usb: Prepare dwc2 driver for driver-model conversion
dm: usb: Add driver-model support to dwc2
net: smsc95xx: Sort the include files
net: smsc95xx: Rename AX_RX_URB_SIZE to RX_URB_SIZE
net: smsc95xx: Correct the error numbers
net: smsc95xx: Prepare for conversion to driver model
net: smsc95xx: Add driver-model support
dm: serial: Update binding for PL01x serial UART
dm: Support address translation for simple-bus

arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info
arm: rpi: Bring in kernel device tree files
arm: rpi: Device tree modifications for U-Boot
arm: rpi: Enable device tree control for Rasberry Pi
arm: rpi: Drop the UART console platform data
arm: rpi: Drop the GPIO platform data
arm: rpi: Move to driver model for USB
arm: rpi: Use driver model for Ethernet

Quoted 45 lines · Simon Glass

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

- Remove GPIO platform data (now uses device tree)
- Remove serial platform data (now uses device tree)
- Add 'ranges' support to simple-bus
- Convert the DWC2 USB driver to support driver model
- Convert the SMSC95XX USB Ethernet driver to support driver model
- Enable CONFIG_DM_ETH and CONFIG_DM_USB on Raspberry Pi

With Ethernet active the device list looks something like this:

U-Boot> dm tree
Class Probed Name
----------------------------------------

 root        [ + ]    root_driver
 simple_bus  [ + ]    |-- soc
 gpio        [   ]    |   |-- gpio at 7e200000
 serial      [ + ]    |   |-- uart at 7e201000
 usb         [ + ]    |   `-- usb at 7e980000
 usb_hub     [ + ]    |       `-- usb_hub
 usb_hub     [ + ]    |           `-- usb_hub
 eth         [ + ]    |               `-- smsc95xx_eth
 simple_bus  [   ]    `-- clocks

Raspberry Pi 2 is not converted as I do not have one to test at present.

Simon Glass (20):
dm: net: Support usbethaddr environment variable
dm: usb: Allow USB Ethernet whenever CONFIG_DM_ETH is not defined
dm: usb: Add an errno.h header to usb_ether.c
dm: usb: Prepare dwc2 driver for driver-model conversion
dm: usb: Add driver-model support to dwc2
net: smsc95xx: Sort the include files
net: smsc95xx: Rename AX_RX_URB_SIZE to RX_URB_SIZE
net: smsc95xx: Correct the error numbers
net: smsc95xx: Prepare for conversion to driver model
net: smsc95xx: Add driver-model support
dm: serial: Update binding for PL01x serial UART
dm: Support address translation for simple-bus

Quoted 8 lines

arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info
arm: rpi: Bring in kernel device tree files
arm: rpi: Device tree modifications for U-Boot
arm: rpi: Enable device tree control for Rasberry Pi
arm: rpi: Drop the UART console platform data
arm: rpi: Drop the GPIO platform data
arm: rpi: Move to driver model for USB
arm: rpi: Use driver model for Ethernet

I could really use the DM part of this patchset on SoCFPGA, can you maybe drop the rpi part and repost it, so that part can be mainlined please ?

Hi Marek,

Quoted 60 lines · Simon Glass

Quoted 58 lines

Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.

This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of

     u-boot.bin)

- Remove GPIO platform data (now uses device tree)
- Remove serial platform data (now uses device tree)
- Add 'ranges' support to simple-bus
- Convert the DWC2 USB driver to support driver model
- Convert the SMSC95XX USB Ethernet driver to support driver model
- Enable CONFIG_DM_ETH and CONFIG_DM_USB on Raspberry Pi

With Ethernet active the device list looks something like this:

U-Boot> dm tree

Class Probed Name

----------------------------------------

 root        [ + ]    root_driver
 simple_bus  [ + ]    |-- soc
 gpio        [   ]    |   |-- gpio at 7e200000
 serial      [ + ]    |   |-- uart at 7e201000
 usb         [ + ]    |   `-- usb at 7e980000
 usb_hub     [ + ]    |       `-- usb_hub
 usb_hub     [ + ]    |           `-- usb_hub
 eth         [ + ]    |               `-- smsc95xx_eth
 simple_bus  [   ]    `-- clocks

Raspberry Pi 2 is not converted as I do not have one to test at present.

Simon Glass (20):
dm: net: Support usbethaddr environment variable
dm: usb: Allow USB Ethernet whenever CONFIG_DM_ETH is not defined
dm: usb: Add an errno.h header to usb_ether.c
dm: usb: Prepare dwc2 driver for driver-model conversion
dm: usb: Add driver-model support to dwc2
net: smsc95xx: Sort the include files
net: smsc95xx: Rename AX_RX_URB_SIZE to RX_URB_SIZE
net: smsc95xx: Correct the error numbers
net: smsc95xx: Prepare for conversion to driver model
net: smsc95xx: Add driver-model support
dm: serial: Update binding for PL01x serial UART
dm: Support address translation for simple-bus
arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info
arm: rpi: Bring in kernel device tree files
arm: rpi: Device tree modifications for U-Boot
arm: rpi: Enable device tree control for Rasberry Pi
arm: rpi: Drop the UART console platform data
arm: rpi: Drop the GPIO platform data
arm: rpi: Move to driver model for USB
arm: rpi: Use driver model for Ethernet

Quoted 2 lines

I could really use the DM part of this patchset on SoCFPGA, can you maybe drop the rpi part and repost it, so that part can be mainlined please ?

Half of this series in in dm/master - please rebase on top of that.

I hope to get a pull request out by Friday,