[U-Boot] [PATCH v3 00/11] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Driver model support for these was recently merged.
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) - 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@7e200000 serial [ + ] | |-- uart@7e201000 usb [ + ] | `-- usb@7e980000 usb_hub [ + ] | `-- usb_hub usb_hub [ + ] | `-- usb_hub eth [ + ] | `-- smsc95xx_eth simple_bus [ ] `-- clocks
Changes in v3: - Drop applied patches from series - Drop patch to introduce usbethaddr for driver model - Rename binding file to pl01x.txt
Changes in v2: - Add support for Raspberry Pi 2
Simon Glass (11): dm: serial: Update binding for PL01x serial UART 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: Add device tree files for Raspberry Pi 2 arm: rpi: Enable device tree control for Rasberry Pi arm: rpi: Enable device tree control for Rasberry Pi 2 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
arch/arm/dts/Makefile | 3 + arch/arm/dts/bcm2835-rpi-b.dts | 24 ++++ arch/arm/dts/bcm2835.dtsi | 35 +++++ arch/arm/dts/bcm2836-rpi-2-b.dts | 30 +++++ arch/arm/dts/bcm2836.dtsi | 42 ++++++ arch/arm/dts/bcm283x-common.dtsi | 157 ++++++++++++++++++++++ arch/arm/dts/bcm283x-rpi.dtsi | 49 +++++++ arch/arm/dts/stv0991.dts | 2 +- arch/arm/mach-bcm283x/include/mach/gpio.h | 5 - board/raspberrypi/rpi/rpi.c | 24 ---- configs/rpi_2_defconfig | 6 + configs/rpi_defconfig | 6 + doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt | 8 ++ doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt | 10 ++ doc/device-tree-bindings/serial/pl01x.txt | 55 +++++++- drivers/gpio/bcm2835_gpio.c | 20 +++ drivers/serial/serial_pl01x.c | 6 +- include/configs/rpi-common.h | 6 +- include/dt-bindings/pinctrl/bcm2835.h | 27 ++++ 19 files changed, 474 insertions(+), 41 deletions(-) create mode 100644 arch/arm/dts/bcm2835-rpi-b.dts create mode 100644 arch/arm/dts/bcm2835.dtsi create mode 100644 arch/arm/dts/bcm2836-rpi-2-b.dts create mode 100644 arch/arm/dts/bcm2836.dtsi create mode 100644 arch/arm/dts/bcm283x-common.dtsi create mode 100644 arch/arm/dts/bcm283x-rpi.dtsi create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt create mode 100644 include/dt-bindings/pinctrl/bcm2835.h
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Rename binding file to pl01x.txt
Changes in v2: None
arch/arm/dts/stv0991.dts | 2 +- doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++--- drivers/serial/serial_pl01x.c | 6 ++-- 3 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts index fa3fd64..d20c87a 100644 --- a/arch/arm/dts/stv0991.dts +++ b/arch/arm/dts/stv0991.dts @@ -18,7 +18,7 @@ uart0: serial@0x80406000 { compatible = "arm,pl011", "arm,primecell"; reg = <0x80406000 0x1000>; - clock = <2700000>; + clock-frequency = <2700000>; };
aliases { diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt index 61c27d1..4483553 100644 --- a/doc/device-tree-bindings/serial/pl01x.txt +++ b/doc/device-tree-bindings/serial/pl01x.txt @@ -1,7 +1,54 @@ -* ARM AMBA Primecell PL011 & PL010 serial UART +* ARM AMBA Primecell PL011 serial UART
Required properties: -- compatible: must be "arm,primecell", "arm,pl011" or "arm,pl010" +- compatible: must be "arm,primecell", "arm,pl011" - reg: exactly one register range with length 0x1000 -- clock: input clock frequency for the UART (used to calculate the baud - rate divisor) +- 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. This is optional in Linux but required + in U-Boot. + +See also bindings/arm/primecell.txt + +Example: + +uart@80120000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x80120000 0x1000>; + interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&dma 13 0 0x2>, <&dma 13 0 0x0>; + dma-names = "rx", "tx"; + clocks = <&foo_clk>, <&bar_clk>; + clock-names = "uartclk", "apb_pclk"; +}; diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c index ad503af..ae6fc0e 100644 --- a/drivers/serial/serial_pl01x.c +++ b/drivers/serial/serial_pl01x.c @@ -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
On 08/07/2015 07:42 AM, Simon Glass wrote:
This binding differs from that of Linux. Update it and change existing users.
Is that meant to imply that this patch fixes the copy of the binding doc in U-Boot so it does match the kernel's copy?
Changes in v3:
- Rename binding file to pl01x.txt
The file is named pl011.txt in the kernel. Shouldn't U-Boot's copy be named the same?
diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
uart0: serial@0x80406000 { compatible = "arm,pl011", "arm,primecell"; reg = <0x80406000 0x1000>;
clock = <2700000>;
clock-frequency = <2700000>;
I don't see either "clock" or "clock-frequency" mentioned in the Linux binding doc.
diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt
Required properties: -- compatible: must be "arm,primecell", "arm,pl011" or "arm,pl010" +- compatible: must be "arm,primecell", "arm,pl011"
It'd be worth mentioning which version of Linux this binding doc came from; that text has changed in linux-next since v4.1 which is what I assume you're importing.
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
@@ -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;
That looks like an unrelated change.
HI Stephen,
On 10 August 2015 at 21:57, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
This binding differs from that of Linux. Update it and change existing users.
Is that meant to imply that this patch fixes the copy of the binding doc in U-Boot so it does match the kernel's copy?
Changes in v3:
- Rename binding file to pl01x.txt
The file is named pl011.txt in the kernel. Shouldn't U-Boot's copy be named the same?
In the previous discussion a reviewed asked for this change, since it covers both drivers.
diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
uart0: serial@0x80406000 { compatible = "arm,pl011", "arm,primecell"; reg = <0x80406000 0x1000>;
clock = <2700000>;
clock-frequency = <2700000>;I don't see either "clock" or "clock-frequency" mentioned in the Linux binding doc.
This was also discussed on the previous patch thread, and I thought this was the outcome of the discussion.
diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt
Required properties: -- compatible: must be "arm,primecell", "arm,pl011" or "arm,pl010" +- compatible: must be "arm,primecell", "arm,pl011"
It'd be worth mentioning which version of Linux this binding doc came from; that text has changed in linux-next since v4.1 which is what I assume you're importing.
OK
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
@@ -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;That looks like an unrelated change.
Yes, it is not needed in this patch.
Regards, Simon
On 08/10/2015 10:11 PM, Simon Glass wrote:
HI Stephen,
On 10 August 2015 at 21:57, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
This binding differs from that of Linux. Update it and change existing users.
Is that meant to imply that this patch fixes the copy of the binding doc in U-Boot so it does match the kernel's copy?
Changes in v3:
- Rename binding file to pl01x.txt
The file is named pl011.txt in the kernel. Shouldn't U-Boot's copy be named the same?
In the previous discussion a reviewed asked for this change, since it covers both drivers.
I think it's more important to match the DT docs in the Linux kernel since they are a shared resource, and should eventually be split off into a separate project at some point, forking from whatever Linux has at that time.
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Yours, Linus Walleij
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Is there any plan to move them out of Linux and put them in a separate place?
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
Regards, Simon
On 08/13/2015 09:59 AM, Simon Glass wrote:
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Is there any plan to move them out of Linux and put them in a separate place?
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)
On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
On 08/13/2015 09:59 AM, Simon Glass wrote:
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Is there any plan to move them out of Linux and put them in a separate place?
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)
This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.
On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
On 08/13/2015 09:59 AM, Simon Glass wrote:
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Is there any plan to move them out of Linux and put them in a separate place?
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)
This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.
As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.
The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.
-- Ian
On 08/13/2015 01:04 PM, Ian Lepore wrote:
On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
On 08/13/2015 09:59 AM, Simon Glass wrote:
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Is there any plan to move them out of Linux and put them in a separate place?
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)
This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.
As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.
The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.
In fairness, that's got nothing to do with Linux, but it's a general decision re: the level of detail to put into DT. There's always a discussion about which level of detail to represent in DT when new bindings are created.
The type of an I2C device completely defines all of its properties; the model name/... is enough to fully describe its behaviour. That's a good reason to put just that information into DT, to avoid redundancy.
In some cases, bindings have tended towards placing just the compatible value into the DT (e.g. your example). This does require drivers to be able to look up that information from the compatible value.
That case tends to be more common since what's really important about DT is cleanly representing the resource interactions between devices; let the drivers know all the details of the device's internals, and let DT describe any point where the device/driver has to interact with the system or other devices/drivers around it.
Often when a driver supports a ton of devices, it needs explicit code to deal with each individual device's quirks, so it may as well have the table of quirks inside it too, rather than having the table in DT, and the code to handle them in the driver, and have to do work to link the two together.
In other cases there's a much more generic description in DT, with all the device-specific quirks described in DT. This would allow completely generic drivers.
This case is less popular, and I'll admit I'm having a hard time quickly finding an example in the DT files I deal with day-to-day.
On Thu, Aug 13, 2015 at 9:37 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/13/2015 01:04 PM, Ian Lepore wrote:
As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.
The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything
^^^ This is the important "etc" below.
claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.
In fairness, that's got nothing to do with Linux, but it's a general decision re: the level of detail to put into DT. There's always a discussion about which level of detail to represent in DT when new bindings are created.
The type of an I2C device completely defines all of its properties; the model name/... is enough to fully describe its behaviour. That's a good reason to put just that information into DT, to avoid redundancy.
In some cases, bindings have tended towards placing just the compatible value into the DT (e.g. your example). This does require drivers to be able to look up that information from the compatible value.
That case tends to be more common since what's really important about DT is cleanly representing the resource interactions between devices; let the drivers know all the details of the device's internals, and let DT describe any point where the device/driver has to interact with the system or other devices/drivers around it.
Exactly.
The important part in your i2c eeprom example is the "etc". Suppose you use a generic compatible value, and lots of properties to describe the device.
Over time, when adding support for new devices with new features, you will add new properties. No problem, you can assume default values if a property is missing. One day, when adding new features, you will discover a slight difference in behavior between two different i2c eeproms that were described the same before. Oops.
P.S. I'd ike to point people to my presentation "Engaging Device Trees" at ELC2014 (http://elinux.org/File:Engaging_Device_Trees_0.pdf).
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Thu, Aug 13, 2015 at 9:04 PM, Ian Lepore ian@freebsd.org wrote:
As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.
This is the first time I hear a story like this, tell us more!
This is exactly the kind of stuff we want to see posted on devicetree@vger.kernel.org.
The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.
I have complained before that since the bindings are often merged through the Linux kernel tree subsystem maintainers, they ultimately decide on bindings. Unsurprisingly, they are as unlikely to notice linuxisms as the Windows people designing ACPI are unlikely to notice Windowsisms. But atleast we know we are flawed and want to improve.
The best way to improve is to have people from other OSes on the devicetree mailinglist and review the bindings there from other-OS point of view.
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
I bet Wolfram and other I2C people can comment on this, state and future directions. Wolfram is known to care deeply about the problem with DT contracts.
All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.
Let's maker this better.
Yours, Linus Walleij
On Thu, Aug 13, 2015 at 2:04 PM, Ian Lepore ian@freebsd.org wrote:
On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
On 08/13/2015 09:59 AM, Simon Glass wrote:
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Is there any plan to move them out of Linux and put them in a separate place?
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)
This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.
As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.
Sadly, we see little non-Linux participation on DT lists. We've tried to separate core (devicetree-spec) and driver lists, but pretty much everything still goes to one list and it is a fire hose. I'm open for ideas on how to get more non-Linux participation.
The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.
Think of compatible as a PID/VID pair like USB or PCI. It is simply a unique identifier. You don't get any more information with PCI or non-class USB devices. DT was originally only solving the problem of finding the non-probeable h/w. It's grown to be a lot more with today's SOCs.
The more we put into DT the more chance it can be wrong and then we have to work around not h/w quirks, but DT quirks.
That said we can always add to the bindings. It would have to be worded something like "optional, but required for new dts's". You would have to have a new DTB if the OS is dependent on the new properties.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
Don't you already have these drivers w/o using DT? If you did, you would have this information already in the drivers. It wouldn't be a question of the binding being Linux specific, but rather can we move more of the data out of drivers and into DT. That is fundamentally a different issue than is a binding Linux specific.
Rob
On Fri, 2015-08-14 at 09:27 -0500, Rob Herring wrote:
On Thu, Aug 13, 2015 at 2:04 PM, Ian Lepore ian@freebsd.org wrote:
On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
[...]
This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.
As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.
Sadly, we see little non-Linux participation on DT lists. We've tried to separate core (devicetree-spec) and driver lists, but pretty much everything still goes to one list and it is a fire hose. I'm open for ideas on how to get more non-Linux participation.
I've been lurking on the 3 devtree lists I know about for over a year. This was the first time something came up that I could make a useful reply to. I think part of that has to do with us being years behind in DT adoption in FreeBSD, and not having the resources to catch up quickly (or, probably to keep up if we ever caught up).
[...]
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.
Think of compatible as a PID/VID pair like USB or PCI. It is simply a unique identifier. You don't get any more information with PCI or non-class USB devices. DT was originally only solving the problem of finding the non-probeable h/w. It's grown to be a lot more with today's SOCs.
The more we put into DT the more chance it can be wrong and then we have to work around not h/w quirks, but DT quirks.
That said we can always add to the bindings. It would have to be worded something like "optional, but required for new dts's". You would have to have a new DTB if the OS is dependent on the new properties.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
Don't you already have these drivers w/o using DT? If you did, you would have this information already in the drivers. It wouldn't be a question of the binding being Linux specific, but rather can we move more of the data out of drivers and into DT. That is fundamentally a different issue than is a binding Linux specific.
This last paragraph most eloquently illustrates the point I was trying to make: From the point of view of someone who only knows about the existing linux driver and how it is written, the current DT data is perfect. It's exactly what that existing driver needs to know, and from that position you can argue that it is thus the ONLY thing any driver written by anyone would need to know. That assumes that everyone wants to just clone the linux drivers (or in our case, because of licensing, rewrite the drivers in a completely linux-compatible way that somehow isn't simply copying them in violation of the GPL).
Until now we've always used an older sideband metadata mechanism, "device hints". It basically consists of putting strings into the kernel environment in a structured way that allows drivers to find the ones they need at runtime (dev.driver.unitnum.attribute="whatever"). So our i2c eeprom driver has never before had any idea what type of eeprom it was servicing. All it knows is what it needs to know to work with the chip: the addressing, the page sizes, the capacity, etc.
I don't consider it especially onerous to have to hard-code a table of eeprom chip attributes into a driver. All in all, it'll be easier than parsing the equivelent DT data. But for me, this dichotomy between the goal of "an OS-agnostic description of the hardware" and reality of "exactly the data the linux driver needs, no more, no less" was pefectly illustrated by the very simple i2c eeprom case.
Imagine how much more harder the problem is for us to deal with for devices more complex than a 2-wire eeprom.
-- Ian
Ian Lepore wrote at Friday, August 14, 2015 11:46 AM:
On Fri, 2015-08-14 at 09:27 -0500, Rob Herring wrote:
On Thu, Aug 13, 2015 at 2:04 PM, Ian Lepore ian@freebsd.org wrote:
On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
... (Replying from my NVIDIA address, since one of the mail servers in the path to you bounced my last reply. Apologies for any formatting issues.)
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard- coded in tables in the driver source.
Think of compatible as a PID/VID pair like USB or PCI. It is simply a unique identifier. You don't get any more information with PCI or non-class USB devices. DT was originally only solving the problem of finding the non-probeable h/w. It's grown to be a lot more with today's SOCs.
The more we put into DT the more chance it can be wrong and then we have to work around not h/w quirks, but DT quirks.
That said we can always add to the bindings. It would have to be worded something like "optional, but required for new dts's". You would have to have a new DTB if the OS is dependent on the new properties.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded
in source.
Don't you already have these drivers w/o using DT? If you did, you would have this information already in the drivers. It wouldn't be a question of the binding being Linux specific, but rather can we move more of the data out of drivers and into DT. That is fundamentally a different issue than is a binding Linux specific.
This last paragraph most eloquently illustrates the point I was trying to make: From the point of view of someone who only knows about the existing linux driver and how it is written, the current DT data is perfect. It's exactly what that existing driver needs to know, and from that position you can argue that it is thus the ONLY thing any driver written by anyone would need to know. That assumes that everyone wants to just clone the linux drivers (or in our case, because of licensing, rewrite the drivers in a completely linux- compatible way that somehow isn't simply copying them in violation of the GPL).
I believe this is nothing to do with encoding Linuxisms into the DT. It's part of DT itself. DT practice is generally to encode the device model name/number into DT (perhaps with a few properties for extra details) rather than to encode a completely generic device type (e.g. "I2C EEPROM") along with all the possible information anyone could ever want to know about that device.
As Rob and Geert mentioned before, "all the possible information" is something that's generally not possible to enumerate fully and/or correctly.
If DT weren't an ABI, that might not be a problem; we'd just change the schema, fix the bug and move on. However since DT is an ABI, we can't just go back and fix mistakes.
The fact the way DT represents devices aligns well with some aspects of the Linux driver model is nice, but in no way a Linuxism; I believe DT was like this well before Linux used DT.
On Fri, Aug 14, 2015 at 7:45 PM, Ian Lepore ian@freebsd.org wrote:
On Fri, 2015-08-14 at 09:27 -0500, Rob Herring wrote:
Ian:
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
Don't you already have these drivers w/o using DT? If you did, you would have this information already in the drivers. It wouldn't be a question of the binding being Linux specific, but rather can we move more of the data out of drivers and into DT. That is fundamentally a different issue than is a binding Linux specific.
This last paragraph most eloquently illustrates the point I was trying to make: From the point of view of someone who only knows about the existing linux driver and how it is written, the current DT data is perfect. It's exactly what that existing driver needs to know, and from that position you can argue that it is thus the ONLY thing any driver written by anyone would need to know. That assumes that everyone wants to just clone the linux drivers (or in our case, because of licensing, rewrite the drivers in a completely linux-compatible way that somehow isn't simply copying them in violation of the GPL).
For some reason I just get the feeling that the relationship between *BSD and Linux is lacking in communication. Or that the timing is wrong. The OS:es don't hate each other but they don't really understand each other either.
So whenever some shared asset needs management there is a statement like "if you really love me, you should involve me more", from either side.
And yes, it is the common human mistake of simply assuming everyone else in the world works exactly like me (and in worst case we assume others are plain stupid or a lesser imperfect version of ourselves if they don't). But as always, they are usually just thinking differently, smart in another way.
So I think these communities need some relationship therapy.
Yours, Linus Walleij
Hi Ian,
On Aug 13, 2015, at 22:04 , Ian Lepore ian@freebsd.org wrote:
On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
On 08/13/2015 09:59 AM, Simon Glass wrote:
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Is there any plan to move them out of Linux and put them in a separate place?
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)
This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.
As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.
The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.
As one that had to suffer under an alternative OS’s definition of what DT is, and how bindings work (VxWorks) I would like to have some concrete example about any cases like that.
In my experience the mismatch may come from exactly two things:
1) From the lack of involvement in the DT process that’s going on devicetree. True, there’s a very big Linux bias but the maintainers are reasonable and they are open on any kind of collaboration in that area.
2) From the completely half-assed way that internally DT has been implemented in other OSes besides Linux. I am still scared by the VxWorks stuff, but things are not much better in u-boot either. You just can’t slap in libfdt in there and expect all the modern bindings to work (like clock tree, pinmuxing, etc.) I would hope we’ll get things better in u-boot and I would certainly like to coordinate with FreeBSD or whoever to get something done with a reasonable API (and license) that anyone can use.
Due to this, DT bindings end up OS specific which is rather insane if you think about it.
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
I would like to point out that picking i2c eeproms as an example is rather disingenuous. i2c eeproms until recently were in the land of drivers/misc where all the oddballs are located.
I’m very happy to point out that Linux does now have (in -next) an EEPROM (nvmem) framework that _is_ sane.
http://www.gossamer-threads.com/lists/linux/kernel/2224053?page=last
I even have ported the ubiquitous at24 driver to it and I’m happy to report that it is painless port.
https://github.com/pantoniou/linux-beagle-track-mainline/commit/e02880fb6829...
All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.
Why not make it easier then?
-- Ian
Regards
— Pantelis
On Thu, Aug 13, 2015 at 10:59 AM, Simon Glass sjg@chromium.org wrote:
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Yes, please!
Is there any plan to move them out of Linux and put them in a separate place?
There is a tree generated from the kernel tree which is only bindings and dts files[1]. The path in for changes though is still thru the kernel.
Actually splitting it out to an independent repo will require someone stepping up to do that. Perhaps as an intermediate step, we could take patches against the generated tree, apply path fixups, and merge thru the kernel tree.
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
Certainly, having driver binding related changes decoupled from binding documentation makes things harder to review.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
I went and looked at it. I don't have a big problem with "u-boot,?" in principle, but like any linux,? property they are a red flag and get extra scrutiny. You didn't explain what the binding was for, so I've got no idea on the one in question.
Rob
[1] http://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.g...
This shows a proper progress display and the total amount of data transferred. Enable it for Raspberry Pi.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
include/configs/rpi-common.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index 1012cdd..733d1ab 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -89,6 +89,7 @@ #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_SMSC95XX +#define CONFIG_TFTP_TSIZE #define CONFIG_MISC_INIT_R #endif
On 08/07/2015 07:42 AM, Simon Glass wrote:
This shows a proper progress display and the total amount of data transferred. Enable it for Raspberry Pi.
Acked-by: Stephen Warren swarren@wwwdotorg.org
On 10 August 2015 at 21:58, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
This shows a proper progress display and the total amount of data transferred. Enable it for Raspberry Pi.
Acked-by: Stephen Warren swarren@wwwdotorg.org
Applied to u-boot-dm.
Bring in the device tree files from Linux v4.1.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
arch/arm/dts/Makefile | 2 + arch/arm/dts/bcm2835-rpi-b.dts | 23 ++++ arch/arm/dts/bcm2835-rpi.dtsi | 51 +++++++++ arch/arm/dts/bcm2835.dtsi | 192 ++++++++++++++++++++++++++++++++++ include/dt-bindings/pinctrl/bcm2835.h | 27 +++++ 5 files changed, 295 insertions(+) create mode 100644 arch/arm/dts/bcm2835-rpi-b.dts create mode 100644 arch/arm/dts/bcm2835-rpi.dtsi create mode 100644 arch/arm/dts/bcm2835.dtsi create mode 100644 include/dt-bindings/pinctrl/bcm2835.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 2df957c..949048c 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -52,6 +52,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ zynq-zc770-xm013.dtb dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb
+dtb-$(CONFIG_ARCH_BCM283X) += bcm2835-rpi-b.dtb + dtb-$(CONFIG_ARCH_SOCFPGA) += \ socfpga_arria5_socdk.dtb \ socfpga_cyclone5_socdk.dtb \ diff --git a/arch/arm/dts/bcm2835-rpi-b.dts b/arch/arm/dts/bcm2835-rpi-b.dts new file mode 100644 index 0000000..ee89b79 --- /dev/null +++ b/arch/arm/dts/bcm2835-rpi-b.dts @@ -0,0 +1,23 @@ +/dts-v1/; +#include "bcm2835-rpi.dtsi" + +/ { + compatible = "raspberrypi,model-b", "brcm,bcm2835"; + model = "Raspberry Pi Model B"; + + leds { + act { + gpios = <&gpio 16 1>; + }; + }; +}; + +&gpio { + pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>; + + /* I2S interface */ + i2s_alt2: i2s_alt2 { + brcm,pins = <28 29 30 31>; + brcm,function = <BCM2835_FSEL_ALT2>; + }; +}; diff --git a/arch/arm/dts/bcm2835-rpi.dtsi b/arch/arm/dts/bcm2835-rpi.dtsi new file mode 100644 index 0000000..46780bb --- /dev/null +++ b/arch/arm/dts/bcm2835-rpi.dtsi @@ -0,0 +1,51 @@ +#include "bcm2835.dtsi" + +/ { + memory { + reg = <0 0x10000000>; + }; + + leds { + compatible = "gpio-leds"; + + act { + label = "ACT"; + default-state = "keep"; + linux,default-trigger = "heartbeat"; + }; + }; +}; + +&gpio { + pinctrl-names = "default"; + + gpioout: gpioout { + brcm,pins = <6>; + brcm,function = <BCM2835_FSEL_GPIO_OUT>; + }; + + alt0: alt0 { + brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>; + brcm,function = <BCM2835_FSEL_ALT0>; + }; + + alt3: alt3 { + brcm,pins = <48 49 50 51 52 53>; + brcm,function = <BCM2835_FSEL_ALT3>; + }; +}; + +&i2c0 { + status = "okay"; + clock-frequency = <100000>; +}; + +&i2c1 { + status = "okay"; + clock-frequency = <100000>; +}; + +&sdhci { + status = "okay"; + bus-width = <4>; +}; diff --git a/arch/arm/dts/bcm2835.dtsi b/arch/arm/dts/bcm2835.dtsi new file mode 100644 index 0000000..301c73f --- /dev/null +++ b/arch/arm/dts/bcm2835.dtsi @@ -0,0 +1,192 @@ +#include <dt-bindings/pinctrl/bcm2835.h> +#include "skeleton.dtsi" + +/ { + compatible = "brcm,bcm2835"; + model = "BCM2835"; + interrupt-parent = <&intc>; + + chosen { + bootargs = "earlyprintk console=ttyAMA0"; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x7e000000 0x20000000 0x02000000>; + dma-ranges = <0x40000000 0x00000000 0x20000000>; + + timer@7e003000 { + compatible = "brcm,bcm2835-system-timer"; + reg = <0x7e003000 0x1000>; + interrupts = <1 0>, <1 1>, <1 2>, <1 3>; + clock-frequency = <1000000>; + }; + + dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16>, + <1 17>, + <1 18>, + <1 19>, + <1 20>, + <1 21>, + <1 22>, + <1 23>, + <1 24>, + <1 25>, + <1 26>, + <1 27>, + <1 28>; + + #dma-cells = <1>; + brcm,dma-channel-mask = <0x7f35>; + }; + + intc: interrupt-controller@7e00b200 { + compatible = "brcm,bcm2835-armctrl-ic"; + reg = <0x7e00b200 0x200>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + watchdog@7e100000 { + compatible = "brcm,bcm2835-pm-wdt"; + reg = <0x7e100000 0x28>; + }; + + rng@7e104000 { + compatible = "brcm,bcm2835-rng"; + reg = <0x7e104000 0x10>; + }; + + mailbox: mailbox@7e00b800 { + compatible = "brcm,bcm2835-mbox"; + reg = <0x7e00b880 0x40>; + interrupts = <0 1>; + #mbox-cells = <0>; + }; + + gpio: gpio@7e200000 { + compatible = "brcm,bcm2835-gpio"; + reg = <0x7e200000 0xb4>; + /* + * The GPIO IP block is designed for 3 banks of GPIOs. + * Each bank has a GPIO interrupt for itself. + * There is an overall "any bank" interrupt. + * In order, these are GIC interrupts 17, 18, 19, 20. + * Since the BCM2835 only has 2 banks, the 2nd bank + * interrupt output appears to be mirrored onto the + * 3rd bank's interrupt signal. + * So, a bank0 interrupt shows up on 17, 20, and + * a bank1 interrupt shows up on 18, 19, 20! + */ + interrupts = <2 17>, <2 18>, <2 19>, <2 20>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + uart@7e201000 { + compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell"; + reg = <0x7e201000 0x1000>; + interrupts = <2 25>; + clock-frequency = <3000000>; + arm,primecell-periphid = <0x00241011>; + }; + + i2s: i2s@7e203000 { + compatible = "brcm,bcm2835-i2s"; + reg = <0x7e203000 0x20>, + <0x7e101098 0x02>; + + dmas = <&dma 2>, + <&dma 3>; + dma-names = "tx", "rx"; + status = "disabled"; + }; + + spi: spi@7e204000 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204000 0x1000>; + interrupts = <2 22>; + clocks = <&clk_spi>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + i2c0: i2c@7e205000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205000 0x1000>; + interrupts = <2 21>; + clocks = <&clk_i2c>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + sdhci: sdhci@7e300000 { + compatible = "brcm,bcm2835-sdhci"; + reg = <0x7e300000 0x100>; + interrupts = <2 30>; + clocks = <&clk_mmc>; + status = "disabled"; + }; + + i2c1: i2c@7e804000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e804000 0x1000>; + interrupts = <2 21>; + clocks = <&clk_i2c>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + usb@7e980000 { + compatible = "brcm,bcm2835-usb"; + reg = <0x7e980000 0x10000>; + interrupts = <1 9>; + }; + + arm-pmu { + compatible = "arm,arm1176-pmu"; + }; + }; + + clocks { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <0>; + + clk_mmc: clock@0 { + compatible = "fixed-clock"; + reg = <0>; + #clock-cells = <0>; + clock-output-names = "mmc"; + clock-frequency = <100000000>; + }; + + clk_i2c: clock@1 { + compatible = "fixed-clock"; + reg = <1>; + #clock-cells = <0>; + clock-output-names = "i2c"; + clock-frequency = <250000000>; + }; + + clk_spi: clock@2 { + compatible = "fixed-clock"; + reg = <2>; + #clock-cells = <0>; + clock-output-names = "spi"; + clock-frequency = <250000000>; + }; + }; +}; diff --git a/include/dt-bindings/pinctrl/bcm2835.h b/include/dt-bindings/pinctrl/bcm2835.h new file mode 100644 index 0000000..6f0bc37 --- /dev/null +++ b/include/dt-bindings/pinctrl/bcm2835.h @@ -0,0 +1,27 @@ +/* + * Header providing constants for bcm2835 pinctrl bindings. + * + * Copyright (C) 2015 Stefan Wahren stefan.wahren@i2se.com + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +#ifndef __DT_BINDINGS_PINCTRL_BCM2835_H__ +#define __DT_BINDINGS_PINCTRL_BCM2835_H__ + +/* brcm,function property */ +#define BCM2835_FSEL_GPIO_IN 0 +#define BCM2835_FSEL_GPIO_OUT 1 +#define BCM2835_FSEL_ALT5 2 +#define BCM2835_FSEL_ALT4 3 +#define BCM2835_FSEL_ALT0 4 +#define BCM2835_FSEL_ALT1 5 +#define BCM2835_FSEL_ALT2 6 +#define BCM2835_FSEL_ALT3 7 + +#endif /* __DT_BINDINGS_PINCTRL_BCM2835_H__ */
This updates the device tree from the kernel version to something suitable for U-Boot:
- Add stdout-path alias for console - Mark the /soc node to be available pre-relocation so that the early serial console works (we need the 'ranges' property to be available)
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
arch/arm/dts/bcm2835.dtsi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/bcm2835.dtsi b/arch/arm/dts/bcm2835.dtsi index 301c73f..bd6bff6 100644 --- a/arch/arm/dts/bcm2835.dtsi +++ b/arch/arm/dts/bcm2835.dtsi @@ -8,6 +8,7 @@
chosen { bootargs = "earlyprintk console=ttyAMA0"; + stdout-path = &uart; };
soc { @@ -16,6 +17,7 @@ #size-cells = <1>; ranges = <0x7e000000 0x20000000 0x02000000>; dma-ranges = <0x40000000 0x00000000 0x20000000>; + u-boot,dm-pre-reloc;
timer@7e003000 { compatible = "brcm,bcm2835-system-timer"; @@ -92,7 +94,7 @@ #interrupt-cells = <2>; };
- uart@7e201000 { + uart: uart@7e201000 { compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell"; reg = <0x7e201000 0x1000>; interrupts = <2 25>;
On 08/07/2015 07:42 AM, Simon Glass wrote:
This updates the device tree from the kernel version to something suitable for U-Boot:
- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial
console works (we need the 'ranges' property to be available)
If you can get these changes into the kernel's copy of the DT, then this patch is fine. If not, I don't think we should take this patch. The very definition of DT is a SW-stack-agnostic data structure. Modifying it on a per-SW-stack basis means we aren't doing DT, but rather something that looks like DT but isn't. In that case, we shouldn't call it DT.
Hi Stephen,
On 10 August 2015 at 22:00, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
This updates the device tree from the kernel version to something suitable for U-Boot:
- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial
console works (we need the 'ranges' property to be available)
If you can get these changes into the kernel's copy of the DT, then this patch is fine. If not, I don't think we should take this patch. The very definition of DT is a SW-stack-agnostic data structure. Modifying it on a per-SW-stack basis means we aren't doing DT, but rather something that looks like DT but isn't. In that case, we shouldn't call it DT.
The "u-boot," prefix is intended to indicate that it is U-Boot-specific. Linux has "linux," and 800+ uses of it in the ARM device tree source files.
I can certainly send this patch to Linux. Given your comment above, will you take it?
Regards, Simon
On 08/10/2015 10:17 PM, Simon Glass wrote:
Hi Stephen,
On 10 August 2015 at 22:00, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
This updates the device tree from the kernel version to something suitable for U-Boot:
- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial
console works (we need the 'ranges' property to be available)
If you can get these changes into the kernel's copy of the DT, then this patch is fine. If not, I don't think we should take this patch. The very definition of DT is a SW-stack-agnostic data structure. Modifying it on a per-SW-stack basis means we aren't doing DT, but rather something that looks like DT but isn't. In that case, we shouldn't call it DT.
The "u-boot," prefix is intended to indicate that it is U-Boot-specific. Linux has "linux," and 800+ uses of it in the ARM device tree source files.
I can certainly send this patch to Linux. Given your comment above, will you take it?
Review of that change would have to be by the DT bindings maintainers on the DT mailing list. Lee Jones (or perhaps Eric Anholt) owns applying any RPi patches within Linux.
Hi Stephen,
On 10 August 2015 at 22:25, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/10/2015 10:17 PM, Simon Glass wrote:
Hi Stephen,
On 10 August 2015 at 22:00, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
This updates the device tree from the kernel version to something suitable for U-Boot:
- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial
console works (we need the 'ranges' property to be available)
If you can get these changes into the kernel's copy of the DT, then this patch is fine. If not, I don't think we should take this patch. The very definition of DT is a SW-stack-agnostic data structure. Modifying it on a per-SW-stack basis means we aren't doing DT, but rather something that looks like DT but isn't. In that case, we shouldn't call it DT.
The "u-boot," prefix is intended to indicate that it is U-Boot-specific. Linux has "linux," and 800+ uses of it in the ARM device tree source files.
I can certainly send this patch to Linux. Given your comment above, will you take it?
Review of that change would have to be by the DT bindings maintainers on the DT mailing list. Lee Jones (or perhaps Eric Anholt) owns applying any RPi patches within Linux.
As you saw I sent a patch to that mailing list. Let's see how it goes.
Regards, Simon
These are taken from Eric Anholt's April series here:
https://patchwork.kernel.org/patch/6252531/
I doubt they final. We can update then here or bring in the kernel version when it lands.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: - Add support for Raspberry Pi 2
arch/arm/dts/Makefile | 3 +- arch/arm/dts/bcm2835-rpi-b.dts | 3 +- arch/arm/dts/bcm2835.dtsi | 161 +-------------------- arch/arm/dts/bcm2836-rpi-2-b.dts | 30 ++++ arch/arm/dts/bcm2836.dtsi | 42 ++++++ arch/arm/dts/bcm283x-common.dtsi | 157 ++++++++++++++++++++ .../arm/dts/{bcm2835-rpi.dtsi => bcm283x-rpi.dtsi} | 2 - doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt | 8 + doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt | 10 ++ 9 files changed, 252 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2836-rpi-2-b.dts create mode 100644 arch/arm/dts/bcm2836.dtsi create mode 100644 arch/arm/dts/bcm283x-common.dtsi rename arch/arm/dts/{bcm2835-rpi.dtsi => bcm283x-rpi.dtsi} (96%) create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 949048c..8d25596 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -52,7 +52,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ zynq-zc770-xm013.dtb dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb
-dtb-$(CONFIG_ARCH_BCM283X) += bcm2835-rpi-b.dtb +dtb-$(CONFIG_ARCH_BCM283X) += bcm2835-rpi-b.dtb \ + bcm2836-rpi-2-b.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += \ socfpga_arria5_socdk.dtb \ diff --git a/arch/arm/dts/bcm2835-rpi-b.dts b/arch/arm/dts/bcm2835-rpi-b.dts index ee89b79..58d3520 100644 --- a/arch/arm/dts/bcm2835-rpi-b.dts +++ b/arch/arm/dts/bcm2835-rpi-b.dts @@ -1,5 +1,6 @@ /dts-v1/; -#include "bcm2835-rpi.dtsi" +#include "bcm2835.dtsi" +#include "bcm283x-rpi.dtsi"
/ { compatible = "raspberrypi,model-b", "brcm,bcm2835"; diff --git a/arch/arm/dts/bcm2835.dtsi b/arch/arm/dts/bcm2835.dtsi index bd6bff6..dd2ce18 100644 --- a/arch/arm/dts/bcm2835.dtsi +++ b/arch/arm/dts/bcm2835.dtsi @@ -1,5 +1,6 @@ #include <dt-bindings/pinctrl/bcm2835.h> #include "skeleton.dtsi" +#include "bcm283x-common.dtsi"
/ { compatible = "brcm,bcm2835"; @@ -26,169 +27,9 @@ clock-frequency = <1000000>; };
- dma: dma@7e007000 { - compatible = "brcm,bcm2835-dma"; - reg = <0x7e007000 0xf00>; - interrupts = <1 16>, - <1 17>, - <1 18>, - <1 19>, - <1 20>, - <1 21>, - <1 22>, - <1 23>, - <1 24>, - <1 25>, - <1 26>, - <1 27>, - <1 28>; - - #dma-cells = <1>; - brcm,dma-channel-mask = <0x7f35>; - }; - - intc: interrupt-controller@7e00b200 { - compatible = "brcm,bcm2835-armctrl-ic"; - reg = <0x7e00b200 0x200>; - interrupt-controller; - #interrupt-cells = <2>; - }; - - watchdog@7e100000 { - compatible = "brcm,bcm2835-pm-wdt"; - reg = <0x7e100000 0x28>; - }; - - rng@7e104000 { - compatible = "brcm,bcm2835-rng"; - reg = <0x7e104000 0x10>; - }; - - mailbox: mailbox@7e00b800 { - compatible = "brcm,bcm2835-mbox"; - reg = <0x7e00b880 0x40>; - interrupts = <0 1>; - #mbox-cells = <0>; - }; - - gpio: gpio@7e200000 { - compatible = "brcm,bcm2835-gpio"; - reg = <0x7e200000 0xb4>; - /* - * The GPIO IP block is designed for 3 banks of GPIOs. - * Each bank has a GPIO interrupt for itself. - * There is an overall "any bank" interrupt. - * In order, these are GIC interrupts 17, 18, 19, 20. - * Since the BCM2835 only has 2 banks, the 2nd bank - * interrupt output appears to be mirrored onto the - * 3rd bank's interrupt signal. - * So, a bank0 interrupt shows up on 17, 20, and - * a bank1 interrupt shows up on 18, 19, 20! - */ - interrupts = <2 17>, <2 18>, <2 19>, <2 20>; - - gpio-controller; - #gpio-cells = <2>; - - interrupt-controller; - #interrupt-cells = <2>; - }; - - uart: uart@7e201000 { - compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell"; - reg = <0x7e201000 0x1000>; - interrupts = <2 25>; - clock-frequency = <3000000>; - arm,primecell-periphid = <0x00241011>; - }; - - i2s: i2s@7e203000 { - compatible = "brcm,bcm2835-i2s"; - reg = <0x7e203000 0x20>, - <0x7e101098 0x02>; - - dmas = <&dma 2>, - <&dma 3>; - dma-names = "tx", "rx"; - status = "disabled"; - }; - - spi: spi@7e204000 { - compatible = "brcm,bcm2835-spi"; - reg = <0x7e204000 0x1000>; - interrupts = <2 22>; - clocks = <&clk_spi>; - #address-cells = <1>; - #size-cells = <0>; - status = "disabled"; - }; - - i2c0: i2c@7e205000 { - compatible = "brcm,bcm2835-i2c"; - reg = <0x7e205000 0x1000>; - interrupts = <2 21>; - clocks = <&clk_i2c>; - #address-cells = <1>; - #size-cells = <0>; - status = "disabled"; - }; - - sdhci: sdhci@7e300000 { - compatible = "brcm,bcm2835-sdhci"; - reg = <0x7e300000 0x100>; - interrupts = <2 30>; - clocks = <&clk_mmc>; - status = "disabled"; - }; - - i2c1: i2c@7e804000 { - compatible = "brcm,bcm2835-i2c"; - reg = <0x7e804000 0x1000>; - interrupts = <2 21>; - clocks = <&clk_i2c>; - #address-cells = <1>; - #size-cells = <0>; - status = "disabled"; - }; - - usb@7e980000 { - compatible = "brcm,bcm2835-usb"; - reg = <0x7e980000 0x10000>; - interrupts = <1 9>; - }; - arm-pmu { compatible = "arm,arm1176-pmu"; }; };
- clocks { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <0>; - - clk_mmc: clock@0 { - compatible = "fixed-clock"; - reg = <0>; - #clock-cells = <0>; - clock-output-names = "mmc"; - clock-frequency = <100000000>; - }; - - clk_i2c: clock@1 { - compatible = "fixed-clock"; - reg = <1>; - #clock-cells = <0>; - clock-output-names = "i2c"; - clock-frequency = <250000000>; - }; - - clk_spi: clock@2 { - compatible = "fixed-clock"; - reg = <2>; - #clock-cells = <0>; - clock-output-names = "spi"; - clock-frequency = <250000000>; - }; - }; }; diff --git a/arch/arm/dts/bcm2836-rpi-2-b.dts b/arch/arm/dts/bcm2836-rpi-2-b.dts new file mode 100644 index 0000000..fe1c1bf --- /dev/null +++ b/arch/arm/dts/bcm2836-rpi-2-b.dts @@ -0,0 +1,30 @@ +/dts-v1/; +#include "bcm2836.dtsi" +#include "bcm283x-rpi.dtsi" + +/ { + compatible = "raspberrypi,2-model-b", "brcm,bcm2836"; + model = "Raspberry Pi 2 Model B"; + leds { + act { + gpios = <&gpio 47 0>; + }; + + pwr { + label = "PWR"; + gpios = <&gpio 35 0>; + default-state = "keep"; + linux,default-trigger = "default-on"; + }; + }; +}; + +&gpio { + pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>; + + /* I2S interface */ + i2s_alt0: i2s_alt0 { + brcm,pins = <18 19 20 21>; + brcm,function = <BCM2835_FSEL_ALT0>; + }; +}; \ No newline at end of file diff --git a/arch/arm/dts/bcm2836.dtsi b/arch/arm/dts/bcm2836.dtsi new file mode 100644 index 0000000..a3d7b67 --- /dev/null +++ b/arch/arm/dts/bcm2836.dtsi @@ -0,0 +1,42 @@ +#include <dt-bindings/pinctrl/bcm2835.h> +#include "skeleton.dtsi" +#include "bcm283x-common.dtsi" + +/ { + compatible = "brcm,bcm2836"; + model = "BCM2836"; + interrupt-parent = <&intc>; + + chosen { + bootargs = "earlyprintk console=ttyAMA0"; + stdout-path = &uart; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x7e000000 0x3f000000 0x01000000>; + dma-ranges = <0x40000000 0x00000000 0x20000000>; + u-boot,dm-pre-reloc; + + timer@7e003000 { + compatible = "brcm,bcm2835-system-timer"; + reg = <0x7e003000 0x1000>; + interrupts = <1 0>, <1 1>, <1 2>, <1 3>; + clock-frequency = <1000000>; + }; + }; + + cpus: cpus { + #address-cells = <1>; + #size-cells = <0>; + + v7_cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0xf00>; + clock-frequency = <800000000>; + }; + }; +}; diff --git a/arch/arm/dts/bcm283x-common.dtsi b/arch/arm/dts/bcm283x-common.dtsi new file mode 100644 index 0000000..b868ff5 --- /dev/null +++ b/arch/arm/dts/bcm283x-common.dtsi @@ -0,0 +1,157 @@ +/ { + soc { + dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16>, + <1 17>, + <1 18>, + <1 19>, + <1 20>, + <1 21>, + <1 22>, + <1 23>, + <1 24>, + <1 25>, + <1 26>, + <1 27>, + <1 28>; + + #dma-cells = <1>; + brcm,dma-channel-mask = <0x7f35>; + }; + + intc: interrupt-controller@7e00b200 { + compatible = "brcm,bcm2835-armctrl-ic"; + reg = <0x7e00b200 0x200>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + watchdog@7e100000 { + compatible = "brcm,bcm2835-pm-wdt"; + reg = <0x7e100000 0x28>; + }; + + rng@7e104000 { + compatible = "brcm,bcm2835-rng"; + reg = <0x7e104000 0x10>; + }; + + gpio: gpio@7e200000 { + compatible = "brcm,bcm2835-gpio"; + reg = <0x7e200000 0xb4>; + /* + * The GPIO IP block is designed for 3 banks of GPIOs. + * Each bank has a GPIO interrupt for itself. + * There is an overall "any bank" interrupt. + * In order, these are GIC interrupts 17, 18, 19, 20. + * Since the BCM2835 only has 2 banks, the 2nd bank + * interrupt output appears to be mirrored onto the + * 3rd bank's interrupt signal. + * So, a bank0 interrupt shows up on 17, 20, and + * a bank1 interrupt shows up on 18, 19, 20! + */ + interrupts = <2 17>, <2 18>, <2 19>, <2 20>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + uart: uart@7e201000 { + compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell"; + reg = <0x7e201000 0x1000>; + interrupts = <2 25>; + clock-frequency = <3000000>; + arm,primecell-periphid = <0x00241011>; + }; + + i2s: i2s@7e203000 { + compatible = "brcm,bcm2835-i2s"; + reg = <0x7e203000 0x20>, + <0x7e101098 0x02>; + + dmas = <&dma 2>, + <&dma 3>; + dma-names = "tx", "rx"; + status = "disabled"; + }; + + spi: spi@7e204000 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204000 0x1000>; + interrupts = <2 22>; + clocks = <&clk_spi>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + i2c0: i2c@7e205000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205000 0x1000>; + interrupts = <2 21>; + clocks = <&clk_i2c>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + sdhci: sdhci@7e300000 { + compatible = "brcm,bcm2835-sdhci"; + reg = <0x7e300000 0x100>; + interrupts = <2 30>; + clocks = <&clk_mmc>; + status = "disabled"; + }; + + i2c1: i2c@7e804000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e804000 0x1000>; + interrupts = <2 21>; + clocks = <&clk_i2c>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + usb@7e980000 { + compatible = "brcm,bcm2835-usb"; + reg = <0x7e980000 0x10000>; + interrupts = <1 9>; + }; + }; + + clocks { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <0>; + + clk_mmc: clock@0 { + compatible = "fixed-clock"; + reg = <0>; + #clock-cells = <0>; + clock-output-names = "mmc"; + clock-frequency = <100000000>; + }; + + clk_i2c: clock@1 { + compatible = "fixed-clock"; + reg = <1>; + #clock-cells = <0>; + clock-output-names = "i2c"; + clock-frequency = <250000000>; + }; + + clk_spi: clock@2 { + compatible = "fixed-clock"; + reg = <2>; + #clock-cells = <0>; + clock-output-names = "spi"; + clock-frequency = <250000000>; + }; + }; +}; diff --git a/arch/arm/dts/bcm2835-rpi.dtsi b/arch/arm/dts/bcm283x-rpi.dtsi similarity index 96% rename from arch/arm/dts/bcm2835-rpi.dtsi rename to arch/arm/dts/bcm283x-rpi.dtsi index 46780bb..e68cb6e 100644 --- a/arch/arm/dts/bcm2835-rpi.dtsi +++ b/arch/arm/dts/bcm283x-rpi.dtsi @@ -1,5 +1,3 @@ -#include "bcm2835.dtsi" - / { memory { reg = <0 0x10000000>; diff --git a/doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt b/doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt new file mode 100644 index 0000000..ac68348 --- /dev/null +++ b/doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt @@ -0,0 +1,8 @@ +Broadcom BCM2835 device tree bindings +------------------------------------------- + +Boards with the BCM2835 SoC shall have the following properties: + +Required root node property: + +compatible = "brcm,bcm2835"; diff --git a/doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt b/doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt new file mode 100644 index 0000000..5e255ec --- /dev/null +++ b/doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt @@ -0,0 +1,10 @@ +Broadcom BCM2836 device tree bindings +------------------------------------------- + +Raspberry Pi 2 Model B +Required root node properties: +compatible = "raspberrypi,2-model-b", "brcm,bcm2836"; + +Generic BCM2836 board +Required root node properties: +compatible = "brcm,bcm2836";
Enable device tree control so that we can use driver model fully and avoid using platform data.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
configs/rpi_defconfig | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index db8da68..d22ed78 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -6,3 +6,6 @@ CONFIG_TARGET_RPI=y # CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set CONFIG_PHYS_TO_BUS=y +CONFIG_CMD_NET=y +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-b"
On 08/07/2015 07:42 AM, Simon Glass wrote:
Enable device tree control so that we can use driver model fully and avoid using platform data.
I'm still not convinced about this change.
Re: the commit message about: What about the driver model is not being fully used without DT?
Overall: What advantage does using DT have to either a developer or an end-user?
I don't believe this patch fixes and bugs or enables any new features for an end-user.
From the maintainer perspective: It seems to me that it's far simpler to
have a tiny struct for each device in the C code than to pull in a whole slew of DT parsing cruft just to work out the same struct at run-time. As such, this patch can only make it harder to maintain the code since there's more of it, and it's more complex.
I just don't see the advantage of switching to DT for U-Boot control.
Hi Stephen,
On 10 August 2015 at 21:47, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
Enable device tree control so that we can use driver model fully and avoid using platform data.
I'm still not convinced about this change.
Re: the commit message about: What about the driver model is not being fully used without DT?
Device tree control?
Overall: What advantage does using DT have to either a developer or an end-user?
I don't believe this patch fixes and bugs or enables any new features for an end-user.
From the maintainer perspective: It seems to me that it's far simpler to have a tiny struct for each device in the C code than to pull in a whole slew of DT parsing cruft just to work out the same struct at run-time. As such, this patch can only make it harder to maintain the code since there's more of it, and it's more complex.
I just don't see the advantage of switching to DT for U-Boot control.
It allows us to share configuration with the kernel (same device tree file). This should be more familiar to people coming from there than our own configuration system. It's nice to have all the configuration in one place. We can then avoid using platform data in U-Boot unless it is necessary.
I really don't like the idea of filling up the code with platform data when that approach has already been rejected by Linux.
Regards, Simon
On 08/14/2015 01:20 PM, Simon Glass wrote:
Hi Stephen,
On 10 August 2015 at 21:47, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
Enable device tree control so that we can use driver model fully and avoid using platform data.
I'm still not convinced about this change.
Re: the commit message about: What about the driver model is not being fully used without DT?
Device tree control?
I am not convince about that argument. It seems rather self-fulfilling, and irrelevant to me.
The fact that a feature exists shouldn't necessarily mean that it absolutely must be used in all cases. There needs to be some benefit from using the feature. What stability, performance, ... benefit does DT give to a maintainer or user?
On a system that sources device information from ACPI, must DT still be used because DM has that feature and without using it, DM isn't being fully used?
I would strongly hope that DM is not tied to any particular source of device information. A device model should be generic. The actions of enumerating what devices exist (via C structures, DT, ACPI, ...) should be completely independent from the process that then manages all of those devices once they're enumerating/instantiated.
Overall: What advantage does using DT have to either a developer or an end-user?
I don't believe this patch fixes and bugs or enables any new features for an end-user.
From the maintainer perspective: It seems to me that it's far simpler to have a tiny struct for each device in the C code than to pull in a whole slew of DT parsing cruft just to work out the same struct at run-time. As such, this patch can only make it harder to maintain the code since there's more of it, and it's more complex.
I just don't see the advantage of switching to DT for U-Boot control.
It allows us to share configuration with the kernel (same device tree file). This should be more familiar to people coming from there than our own configuration system. It's nice to have all the configuration in one place. We can then avoid using platform data in U-Boot unless it is necessary.
But at the cost of extra complexity in the U-Boot code that I don't think is warranted. Equally, U-Boot's DT support is built on some assumptions about DT structure and parsing rules that are inaccurate (e.g. not honoring #address-cells, not parsing the DT in a hierarchical manner thus not ensuring correct driver "probe" ordering, missing features such as clock frameworks with pushback on supporting the standard clock bindings rather than implementing U-Boot-specific properties, etc.). It's not quite DT, but almost. It's quite unlikely that any Linux DT will "just work". Once it doesn't always just work, the advantage of similarity with kernel DTs is lost. As someone who's ported U-Boot to various Tegra and RPi SoCs/boards, I honestly don't think that using DT rather the C structures would have saved me any time, and likely has caused me to spend more time debugging and fixing DT issues in U-Boot.
I really don't like the idea of filling up the code with platform data when that approach has already been rejected by Linux.
The Linux situation is entirely different from U-Boot.
Linux distros want to distribute a single generic Linux kernel binary (and indeed generic install media, etc.) that runs on arbitrary systems without having to worry about system-specific details. Ideally, the distro can ship a single OS image which will work on arbitrary systems, provided the system vendor ships the DT as part of the firmware and provides it to the kernel. Of course, that hasn't actually happened yet since the DTs are still in the kernel source tree and DT ABI isn't anywhere near universal.
A bootloader or firmware is by definition system-specific. There's no concept of a single image working across *arbitrary* systems. (Of course, some U-Boot builds run on a small number of boards via runtime detection, but by no means is any U-Boot binary entirely generic). There's no need for it to be generic, since system vendors or enterprising users build and install the firmware for a specific known board/system.
As such, any arguments about Linux having chosen to use DT are likely irrelevant to whether a firmware or bootloader should use it.
Hi Stephen,
On 14 August 2015 at 21:32, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/14/2015 01:20 PM, Simon Glass wrote:
Hi Stephen,
On 10 August 2015 at 21:47, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/07/2015 07:42 AM, Simon Glass wrote:
Enable device tree control so that we can use driver model fully and avoid using platform data.
I'm still not convinced about this change.
Re: the commit message about: What about the driver model is not being fully used without DT?
Device tree control?
I am not convince about that argument. It seems rather self-fulfilling, and irrelevant to me.
The fact that a feature exists shouldn't necessarily mean that it absolutely must be used in all cases. There needs to be some benefit from using the feature. What stability, performance, ... benefit does DT give to a maintainer or user?
On a system that sources device information from ACPI, must DT still be used because DM has that feature and without using it, DM isn't being fully used?
I would strongly hope that DM is not tied to any particular source of device information. A device model should be generic. The actions of enumerating what devices exist (via C structures, DT, ACPI, ...) should be completely independent from the process that then manages all of those devices once they're enumerating/instantiated.
So far driver model uses device tree. Devices come into existence because of nodes in the device tree. We are trying to avoid platform data (C structures) and encourage people to standardize on device tree. The ACPI support that is being added is just tables for Linux to use - there is no plan at present for U-Boot to make use of it for its own configuration.
I don't see the benefit of additional configuration mechanisms. By using a single one we reduce confusion across boards and architectures.
Overall: What advantage does using DT have to either a developer or an end-user?
I don't believe this patch fixes and bugs or enables any new features for an end-user.
From the maintainer perspective: It seems to me that it's far simpler to have a tiny struct for each device in the C code than to pull in a whole slew of DT parsing cruft just to work out the same struct at run-time. As such, this patch can only make it harder to maintain the code since there's more of it, and it's more complex.
I just don't see the advantage of switching to DT for U-Boot control.
It allows us to share configuration with the kernel (same device tree file). This should be more familiar to people coming from there than our own configuration system. It's nice to have all the configuration in one place. We can then avoid using platform data in U-Boot unless it is necessary.
But at the cost of extra complexity in the U-Boot code that I don't think is warranted. Equally, U-Boot's DT support is built on some assumptions about DT structure and parsing rules that are inaccurate (e.g. not honoring #address-cells, not parsing the DT in a hierarchical manner thus not ensuring correct driver "probe" ordering, missing features such as clock frameworks with pushback on supporting the standard clock bindings rather than implementing U-Boot-specific properties, etc.). It's not quite DT, but almost. It's quite unlikely that any Linux DT will "just work". Once it doesn't always just work, the advantage of similarity with kernel DTs is lost. As someone who's ported U-Boot to various Tegra and RPi SoCs/boards, I honestly don't think that using DT rather the C structures would have saved me any time, and likely has caused me to spend more time debugging and fixing DT issues in U-Boot.
I think this is taking a rather negative view of the development process. U-Boot had device tree on Tegra before it existed in Linux, and before we had driver model.
#address-cells is supposed to describe the size of addresses on the platform. My push back here was that we added an extremely inefficient function to read the address (scan entire device tree for parent node, etc.) when we need that function to work in SPL quickly and with minimal code. Your new approach looks good to me so I hope that can be put to bed.
Hierarchical parsing is how driver model works, and as things convert over we drop the fdtdec parsing.
A basic clock framework was merged recently - perhaps you could take a look at supporting this on Tegra and seeing how it helps with the issues you raise? Also you will have seen Masahiro's series to support pinctrl. But nothing gets done unless people work on it. Sometimes infrastructure is harder because the effort to get agreement and convert over existing users becomes substantial
I think we have to look to board /SoC maintainers to keep the device tree files in sync. It would be great if we could get to the point where it could be scripted and then perhaps the fdt maintainer (currently me) could do it each cycle.
I really don't like the idea of filling up the code with platform data when that approach has already been rejected by Linux.
The Linux situation is entirely different from U-Boot.
Linux distros want to distribute a single generic Linux kernel binary (and indeed generic install media, etc.) that runs on arbitrary systems without having to worry about system-specific details. Ideally, the distro can ship a single OS image which will work on arbitrary systems, provided the system vendor ships the DT as part of the firmware and provides it to the kernel. Of course, that hasn't actually happened yet since the DTs are still in the kernel source tree and DT ABI isn't anywhere near universal.
A bootloader or firmware is by definition system-specific. There's no concept of a single image working across *arbitrary* systems. (Of course, some U-Boot builds run on a small number of boards via runtime detection, but by no means is any U-Boot binary entirely generic). There's no need for it to be generic, since system vendors or enterprising users build and install the firmware for a specific known board/system.
As such, any arguments about Linux having chosen to use DT are likely irrelevant to whether a firmware or bootloader should use it.
I have found it *much* easier to support platform features across multiple boards using device tree. For example, I was recently updating the TPM support to move it to driver model. I was able to add TPM support to Nyan and several exynos and x86 boards just by copying in the tpm node and enabling the driver.
Similarly a downstream board can start by making device tree changes to match their board, and expect to get basic functionality without a lot of effort.
Many of the boards in U-Boot are very similar to each other and a device tree is enough to capture the differences. This gives people the option to go this way. It helps reduce the proliferation of code paths and builds which is often seen in firmware. Even if the build produces separate binaries, perhaps the only difference might be the device tree.
I have heard arguments that firmware is always hard-coded and run-time configuration is pointless. But to a point, injecting the data into generic code is much easier to manage then #ifdefs and conditional build-time configuration code.
I really like where U-Boot has got to with device tree. It fits really nicely with driver model and things are pretty clean and ordered. We are in a much better place now I think.
Regards, Simon
Enable device tree control so that we can use driver model fully and avoid using platform data.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: - Add support for Raspberry Pi 2
configs/rpi_2_defconfig | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index 139189d..1945a7d 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -6,3 +6,9 @@ CONFIG_TARGET_RPI_2=y # CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set CONFIG_PHYS_TO_BUS=y +CONFIG_CMD_NET=y +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="bcm2836-rpi-2-b" +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_DM_ETH=y
We can rely on the device tree to provide the UART information.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
board/raspberrypi/rpi/rpi.c | 15 --------------- 1 file changed, 15 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 96fe870..7de1921 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -28,21 +28,6 @@ U_BOOT_DEVICE(bcm2835_gpios) = { .platdata = &gpio_platdata, };
-static const struct pl01x_serial_platdata serial_platdata = { -#ifdef CONFIG_BCM2836 - .base = 0x3f201000, -#else - .base = 0x20201000, -#endif - .type = TYPE_PL011, - .clock = 3000000, -}; - -U_BOOT_DEVICE(bcm2835_serials) = { - .name = "serial_pl01x", - .platdata = &serial_platdata, -}; - struct msg_get_arm_mem { struct bcm2835_mbox_hdr hdr; struct bcm2835_mbox_tag_get_arm_mem get_arm_mem;
We can rely on the device tree to provide the GPIO information.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
arch/arm/mach-bcm283x/include/mach/gpio.h | 5 ----- board/raspberrypi/rpi/rpi.c | 9 --------- drivers/gpio/bcm2835_gpio.c | 20 ++++++++++++++++++++ 3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/gpio.h b/arch/arm/mach-bcm283x/include/mach/gpio.h index c8ef8f5..7b4ddc9 100644 --- a/arch/arm/mach-bcm283x/include/mach/gpio.h +++ b/arch/arm/mach-bcm283x/include/mach/gpio.h @@ -9,11 +9,6 @@ #ifndef _BCM2835_GPIO_H_ #define _BCM2835_GPIO_H_
-#ifdef CONFIG_BCM2836 -#define BCM2835_GPIO_BASE 0x3f200000 -#else -#define BCM2835_GPIO_BASE 0x20200000 -#endif #define BCM2835_GPIO_COUNT 54
#define BCM2835_GPIO_FSEL_MASK 0x7 diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 7de1921..39f451f 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -19,15 +19,6 @@
DECLARE_GLOBAL_DATA_PTR;
-static const struct bcm2835_gpio_platdata gpio_platdata = { - .base = BCM2835_GPIO_BASE, -}; - -U_BOOT_DEVICE(bcm2835_gpios) = { - .name = "gpio_bcm2835", - .platdata = &gpio_platdata, -}; - struct msg_get_arm_mem { struct bcm2835_mbox_hdr hdr; struct bcm2835_mbox_tag_get_arm_mem get_arm_mem; diff --git a/drivers/gpio/bcm2835_gpio.c b/drivers/gpio/bcm2835_gpio.c index fbc641d..f571b0b 100644 --- a/drivers/gpio/bcm2835_gpio.c +++ b/drivers/gpio/bcm2835_gpio.c @@ -114,9 +114,29 @@ static int bcm2835_gpio_probe(struct udevice *dev) return 0; }
+#ifdef CONFIG_OF_CONTROL +static int bcm2835_gpio_ofdata_to_platdata(struct udevice *dev) +{ + struct bcm2835_gpio_platdata *plat = dev_get_platdata(dev); + + plat->base = dev_get_addr(dev); + if (plat->base == FDT_ADDR_T_NONE) + return -EINVAL; + + return 0; +} + +static const struct udevice_id bcm2835_gpio_id[] = { + {.compatible = "brcm,bcm2835-gpio"}, + {} +}; +#endif + U_BOOT_DRIVER(gpio_bcm2835) = { .name = "gpio_bcm2835", .id = UCLASS_GPIO, + .of_match = of_match_ptr(bcm2835_gpio_id), + .ofdata_to_platdata = of_match_ptr(bcm2835_gpio_ofdata_to_platdata), .ops = &gpio_bcm2835_ops, .probe = bcm2835_gpio_probe, .priv_auto_alloc_size = sizeof(struct bcm2835_gpios),
Start using driver model for USB on the Raspberry Pi. The dwc2 supports this now so this is just a config change.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
configs/rpi_defconfig | 2 ++ include/configs/rpi-common.h | 5 ----- 2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index d22ed78..43f5fdd 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -9,3 +9,5 @@ CONFIG_PHYS_TO_BUS=y CONFIG_CMD_NET=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-b" +CONFIG_USB=y +CONFIG_DM_USB=y diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index 733d1ab..8d85e93 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -81,11 +81,6 @@ #define CONFIG_CMD_USB #ifdef CONFIG_CMD_USB #define CONFIG_USB_DWC2 -#ifdef CONFIG_BCM2836 -#define CONFIG_USB_DWC2_REG_ADDR 0x3f980000 -#else -#define CONFIG_USB_DWC2_REG_ADDR 0x20980000 -#endif #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_SMSC95XX
Enable CONFIG_DM_ETH so that driver model is used for the USB Ethernet device.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Drop applied patches from series - Drop patch to introduce usbethaddr for driver model
Changes in v2: None
configs/rpi_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index 43f5fdd..d523e81 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -11,3 +11,4 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-b" CONFIG_USB=y CONFIG_DM_USB=y +CONFIG_DM_ETH=y
participants (9)
-
Geert Uytterhoeven -
Ian Lepore -
Linus Walleij -
Pantelis Antoniou -
Rob Herring -
Simon Glass -
Stephen Warren -
Stephen Warren -
Tom Rini