[U-Boot] [PATCH v3 00/11] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi

[U-Boot] [PATCH v3 00/11] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi

[Simon Glass]

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 at 7e200000
 serial      [ + ]    |   |-- uart at 7e201000
 usb         [ + ]    |   `-- usb at 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

-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Simon Glass]

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 at 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 at 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
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Stephen Warren]

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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Simon Glass]

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 at 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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Stephen Warren]

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.

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Linus Walleij]

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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Simon Glass]

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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Stephen Warren]

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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150813/72970d1a/attachment.sig>

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Ian Lepore]

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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Stephen Warren]

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.

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Geert Uytterhoeven]

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 at 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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Linus Walleij]

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 at 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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Rob Herring]

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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Ian Lepore]

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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Stephen Warren]

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.

-- 
nvpbulic

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Linus Walleij]

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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Pantelis Antoniou]

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/e02880fb68295cb61db71c94800b04c1656b10ba
 
> 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

[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Rob Herring]

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

[U-Boot] [PATCH v3 02/11] arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info

[Simon Glass]

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
 
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 02/11] arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info

[Stephen Warren]

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>

[U-Boot] [PATCH v3 02/11] arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info

[Simon Glass]

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.

[U-Boot] [PATCH v3 03/11] arm: rpi: Bring in kernel device tree files

[Simon Glass]

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 at 7e003000 {
+			compatible = "brcm,bcm2835-system-timer";
+			reg = <0x7e003000 0x1000>;
+			interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
+			clock-frequency = <1000000>;
+		};
+
+		dma: dma at 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 at 7e00b200 {
+			compatible = "brcm,bcm2835-armctrl-ic";
+			reg = <0x7e00b200 0x200>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		watchdog at 7e100000 {
+			compatible = "brcm,bcm2835-pm-wdt";
+			reg = <0x7e100000 0x28>;
+		};
+
+		rng at 7e104000 {
+			compatible = "brcm,bcm2835-rng";
+			reg = <0x7e104000 0x10>;
+		};
+
+		mailbox: mailbox at 7e00b800 {
+			compatible = "brcm,bcm2835-mbox";
+			reg = <0x7e00b880 0x40>;
+			interrupts = <0 1>;
+			#mbox-cells = <0>;
+		};
+
+		gpio: gpio at 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 at 7e201000 {
+			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
+			reg = <0x7e201000 0x1000>;
+			interrupts = <2 25>;
+			clock-frequency = <3000000>;
+			arm,primecell-periphid = <0x00241011>;
+		};
+
+		i2s: i2s at 7e203000 {
+			compatible = "brcm,bcm2835-i2s";
+			reg = <0x7e203000 0x20>,
+			      <0x7e101098 0x02>;
+
+			dmas = <&dma 2>,
+			       <&dma 3>;
+			dma-names = "tx", "rx";
+			status = "disabled";
+		};
+
+		spi: spi at 7e204000 {
+			compatible = "brcm,bcm2835-spi";
+			reg = <0x7e204000 0x1000>;
+			interrupts = <2 22>;
+			clocks = <&clk_spi>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		i2c0: i2c at 7e205000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e205000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		sdhci: sdhci at 7e300000 {
+			compatible = "brcm,bcm2835-sdhci";
+			reg = <0x7e300000 0x100>;
+			interrupts = <2 30>;
+			clocks = <&clk_mmc>;
+			status = "disabled";
+		};
+
+		i2c1: i2c at 7e804000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e804000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		usb at 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 at 0 {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-output-names = "mmc";
+			clock-frequency = <100000000>;
+		};
+
+		clk_i2c: clock at 1 {
+			compatible = "fixed-clock";
+			reg = <1>;
+			#clock-cells = <0>;
+			clock-output-names = "i2c";
+			clock-frequency = <250000000>;
+		};
+
+		clk_spi: clock at 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__ */
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 04/11] arm: rpi: Device tree modifications for U-Boot

[Simon Glass]

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 at 7e003000 {
 			compatible = "brcm,bcm2835-system-timer";
@@ -92,7 +94,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		uart at 7e201000 {
+		uart: uart at 7e201000 {
 			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
 			reg = <0x7e201000 0x1000>;
 			interrupts = <2 25>;
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 04/11] arm: rpi: Device tree modifications for U-Boot

[Stephen Warren]

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.

[U-Boot] [PATCH v3 04/11] arm: rpi: Device tree modifications for U-Boot

[Simon Glass]

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

[U-Boot] [PATCH v3 04/11] arm: rpi: Device tree modifications for U-Boot

[Stephen Warren]

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.

[U-Boot] [PATCH v3 04/11] arm: rpi: Device tree modifications for U-Boot

[Simon Glass]

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

[U-Boot] [PATCH v3 05/11] arm: rpi: Add device tree files for Raspberry Pi 2

[Simon Glass]

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 at 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 at 7e00b200 {
-			compatible = "brcm,bcm2835-armctrl-ic";
-			reg = <0x7e00b200 0x200>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		watchdog at 7e100000 {
-			compatible = "brcm,bcm2835-pm-wdt";
-			reg = <0x7e100000 0x28>;
-		};
-
-		rng at 7e104000 {
-			compatible = "brcm,bcm2835-rng";
-			reg = <0x7e104000 0x10>;
-		};
-
-		mailbox: mailbox at 7e00b800 {
-			compatible = "brcm,bcm2835-mbox";
-			reg = <0x7e00b880 0x40>;
-			interrupts = <0 1>;
-			#mbox-cells = <0>;
-		};
-
-		gpio: gpio at 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 at 7e201000 {
-			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
-			reg = <0x7e201000 0x1000>;
-			interrupts = <2 25>;
-			clock-frequency = <3000000>;
-			arm,primecell-periphid = <0x00241011>;
-		};
-
-		i2s: i2s at 7e203000 {
-			compatible = "brcm,bcm2835-i2s";
-			reg = <0x7e203000 0x20>,
-			      <0x7e101098 0x02>;
-
-			dmas = <&dma 2>,
-			       <&dma 3>;
-			dma-names = "tx", "rx";
-			status = "disabled";
-		};
-
-		spi: spi at 7e204000 {
-			compatible = "brcm,bcm2835-spi";
-			reg = <0x7e204000 0x1000>;
-			interrupts = <2 22>;
-			clocks = <&clk_spi>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		i2c0: i2c at 7e205000 {
-			compatible = "brcm,bcm2835-i2c";
-			reg = <0x7e205000 0x1000>;
-			interrupts = <2 21>;
-			clocks = <&clk_i2c>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		sdhci: sdhci at 7e300000 {
-			compatible = "brcm,bcm2835-sdhci";
-			reg = <0x7e300000 0x100>;
-			interrupts = <2 30>;
-			clocks = <&clk_mmc>;
-			status = "disabled";
-		};
-
-		i2c1: i2c at 7e804000 {
-			compatible = "brcm,bcm2835-i2c";
-			reg = <0x7e804000 0x1000>;
-			interrupts = <2 21>;
-			clocks = <&clk_i2c>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		usb at 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 at 0 {
-			compatible = "fixed-clock";
-			reg = <0>;
-			#clock-cells = <0>;
-			clock-output-names = "mmc";
-			clock-frequency = <100000000>;
-		};
-
-		clk_i2c: clock at 1 {
-			compatible = "fixed-clock";
-			reg = <1>;
-			#clock-cells = <0>;
-			clock-output-names = "i2c";
-			clock-frequency = <250000000>;
-		};
-
-		clk_spi: clock at 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 at 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 at 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 at 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 at 7e00b200 {
+			compatible = "brcm,bcm2835-armctrl-ic";
+			reg = <0x7e00b200 0x200>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		watchdog at 7e100000 {
+			compatible = "brcm,bcm2835-pm-wdt";
+			reg = <0x7e100000 0x28>;
+		};
+
+		rng at 7e104000 {
+			compatible = "brcm,bcm2835-rng";
+			reg = <0x7e104000 0x10>;
+		};
+
+		gpio: gpio at 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 at 7e201000 {
+			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
+			reg = <0x7e201000 0x1000>;
+			interrupts = <2 25>;
+			clock-frequency = <3000000>;
+			arm,primecell-periphid = <0x00241011>;
+		};
+
+		i2s: i2s at 7e203000 {
+			compatible = "brcm,bcm2835-i2s";
+			reg = <0x7e203000 0x20>,
+			      <0x7e101098 0x02>;
+
+			dmas = <&dma 2>,
+			       <&dma 3>;
+			dma-names = "tx", "rx";
+			status = "disabled";
+		};
+
+		spi: spi at 7e204000 {
+			compatible = "brcm,bcm2835-spi";
+			reg = <0x7e204000 0x1000>;
+			interrupts = <2 22>;
+			clocks = <&clk_spi>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		i2c0: i2c at 7e205000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e205000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		sdhci: sdhci at 7e300000 {
+			compatible = "brcm,bcm2835-sdhci";
+			reg = <0x7e300000 0x100>;
+			interrupts = <2 30>;
+			clocks = <&clk_mmc>;
+			status = "disabled";
+		};
+
+		i2c1: i2c at 7e804000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e804000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		usb at 7e980000 {
+			compatible = "brcm,bcm2835-usb";
+			reg = <0x7e980000 0x10000>;
+			interrupts = <1 9>;
+		};
+	};
+
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_mmc: clock at 0 {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-output-names = "mmc";
+			clock-frequency = <100000000>;
+		};
+
+		clk_i2c: clock at 1 {
+			compatible = "fixed-clock";
+			reg = <1>;
+			#clock-cells = <0>;
+			clock-output-names = "i2c";
+			clock-frequency = <250000000>;
+		};
+
+		clk_spi: clock at 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";
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi

[Simon Glass]

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"
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi

[Stephen Warren]

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.

[U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi

[Simon Glass]

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

[U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi

[Stephen Warren]

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.

[U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi

[Simon Glass]

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

[U-Boot] [PATCH v3 07/11] arm: rpi: Enable device tree control for Rasberry Pi 2

[Simon Glass]

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
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 08/11] arm: rpi: Drop the UART console platform data

[Simon Glass]

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;
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 09/11] arm: rpi: Drop the GPIO platform data

[Simon Glass]

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),
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 10/11] arm: rpi: Move to driver model for USB

[Simon Glass]

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
-- 
2.5.0.rc2.392.g76e840b

[U-Boot] [PATCH v3 11/11] arm: rpi: Use driver model for Ethernet

[Simon Glass]

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
-- 
2.5.0.rc2.392.g76e840b