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

[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@7e200000
 serial      [ + ]    |   |-- uart@7e201000
 usb         [ + ]    |   `-- usb@7e980000
 usb_hub     [ + ]    |       `-- usb_hub
 usb_hub     [ + ]    |           `-- usb_hub
 eth         [ + ]    |               `-- smsc95xx_eth
 simple_bus  [   ]    `-- clocks

Changes in v3:
- Drop applied patches from series
- Drop patch to introduce usbethaddr for driver model
- Rename binding file to pl01x.txt

Changes in v2:
- Add support for Raspberry Pi 2

Simon Glass (11):
  dm: serial: Update binding for PL01x serial UART
  arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info
  arm: rpi: Bring in kernel device tree files
  arm: rpi: Device tree modifications for U-Boot
  arm: rpi: Add device tree files for Raspberry Pi 2
  arm: rpi: Enable device tree control for Rasberry Pi
  arm: rpi: Enable device tree control for Rasberry Pi 2
  arm: rpi: Drop the UART console platform data
  arm: rpi: Drop the GPIO platform data
  arm: rpi: Move to driver model for USB
  arm: rpi: Use driver model for Ethernet

 arch/arm/dts/Makefile                             |   3 +
 arch/arm/dts/bcm2835-rpi-b.dts                    |  24 ++++
 arch/arm/dts/bcm2835.dtsi                         |  35 +++++
 arch/arm/dts/bcm2836-rpi-2-b.dts                  |  30 +++++
 arch/arm/dts/bcm2836.dtsi                         |  42 ++++++
 arch/arm/dts/bcm283x-common.dtsi                  | 157 ++++++++++++++++++++++
 arch/arm/dts/bcm283x-rpi.dtsi                     |  49 +++++++
 arch/arm/dts/stv0991.dts                          |   2 +-
 arch/arm/mach-bcm283x/include/mach/gpio.h         |   5 -
 board/raspberrypi/rpi/rpi.c                       |  24 ----
 configs/rpi_2_defconfig                           |   6 +
 configs/rpi_defconfig                             |   6 +
 doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt |   8 ++
 doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt |  10 ++
 doc/device-tree-bindings/serial/pl01x.txt         |  55 +++++++-
 drivers/gpio/bcm2835_gpio.c                       |  20 +++
 drivers/serial/serial_pl01x.c                     |   6 +-
 include/configs/rpi-common.h                      |   6 +-
 include/dt-bindings/pinctrl/bcm2835.h             |  27 ++++
 19 files changed, 474 insertions(+), 41 deletions(-)
 create mode 100644 arch/arm/dts/bcm2835-rpi-b.dts
 create mode 100644 arch/arm/dts/bcm2835.dtsi
 create mode 100644 arch/arm/dts/bcm2836-rpi-2-b.dts
 create mode 100644 arch/arm/dts/bcm2836.dtsi
 create mode 100644 arch/arm/dts/bcm283x-common.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi.dtsi
 create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt
 create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt
 create mode 100644 include/dt-bindings/pinctrl/bcm2835.h

-- 
2.5.0.rc2.392.g76e840b

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

Changes in v3:
- Rename binding file to pl01x.txt

Changes in v2: None

 arch/arm/dts/stv0991.dts                  |  2 +-
 doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
 drivers/serial/serial_pl01x.c             |  6 ++--
 3 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
index fa3fd64..d20c87a 100644
--- a/arch/arm/dts/stv0991.dts
+++ b/arch/arm/dts/stv0991.dts
@@ -18,7 +18,7 @@
 	uart0: serial@0x80406000 {
 		compatible = "arm,pl011", "arm,primecell";
 		reg = <0x80406000 0x1000>;
-		clock = <2700000>;
+		clock-frequency = <2700000>;
 	};
 
 	aliases {
diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt
index 61c27d1..4483553 100644
--- a/doc/device-tree-bindings/serial/pl01x.txt
+++ b/doc/device-tree-bindings/serial/pl01x.txt
@@ -1,7 +1,54 @@
-* ARM AMBA Primecell PL011 & PL010 serial UART
+* ARM AMBA Primecell PL011 serial UART
 
 Required properties:
-- compatible: must be "arm,primecell", "arm,pl011" or "arm,pl010"
+- compatible: must be "arm,primecell", "arm,pl011"
 - reg: exactly one register range with length 0x1000
-- clock: input clock frequency for the UART (used to calculate the baud
-  rate divisor)
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl:
+	   When present, must have one state named "default",
+	   and may contain a second name named "sleep". The former
+	   state sets up pins for ordinary operation whereas
+	   the latter state will put the associated pins to sleep
+	   when the UART is unused
+- clocks:
+	   When present, the first clock listed must correspond to
+	   the clock named UARTCLK on the IP block, i.e. the clock
+	   to the external serial line, whereas the second clock
+	   must correspond to the PCLK clocking the internal logic
+	   of the block. Just listing one clock (the first one) is
+	   deprecated.
+- clocks-names:
+	   When present, the first clock listed must be named
+	   "uartclk" and the second clock listed must be named
+	   "apb_pclk"
+- dmas:
+	   When present, may have one or two dma channels.
+	   The first one must be named "rx", the second one
+	   must be named "tx".
+- auto-poll:
+	   Enables polling when using RX DMA.
+- poll-rate-ms:
+	   Rate at which poll occurs when auto-poll is set,
+	   default 100ms.
+- poll-timeout-ms:
+	   Poll timeout when auto-poll is set, default
+	   3000ms.
+- clock-frequency:
+	   Input clock frequency for UART. This is optional in Linux but required
+	   in U-Boot.
+
+See also bindings/arm/primecell.txt
+
+Example:
+
+uart@80120000 {
+	compatible = "arm,pl011", "arm,primecell";
+	reg = <0x80120000 0x1000>;
+	interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+	dmas = <&dma 13 0 0x2>, <&dma 13 0 0x0>;
+	dma-names = "rx", "tx";
+	clocks = <&foo_clk>, <&bar_clk>;
+	clock-names = "uartclk", "apb_pclk";
+};
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index ad503af..ae6fc0e 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -365,13 +365,15 @@ static int pl01x_serial_ofdata_to_platdata(struct udevice *dev)
 	struct pl01x_serial_platdata *plat = dev_get_platdata(dev);
 	fdt_addr_t addr;
 
-	addr = fdtdec_get_addr(gd->fdt_blob, dev->of_offset, "reg");
+	addr = dev_get_addr(dev);
 	if (addr == FDT_ADDR_T_NONE)
 		return -EINVAL;
 
 	plat->base = addr;
-	plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "clock", 1);
+	plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+				     "clock-frequency", 1);
 	plat->type = dev_get_driver_data(dev);
+
 	return 0;
 }
 #endif
-- 
2.5.0.rc2.392.g76e840b

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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@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.

Re: [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-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> On 08/07/2015 07:42 AM, Simon Glass wrote:
>> This binding differs from that of Linux. Update it and change existing
>> users.
>
> Is that meant to imply that this patch fixes the copy of the binding doc
> in U-Boot so it does match the kernel's copy?
>
>> Changes in v3:
>> - Rename binding file to pl01x.txt
>
> The file is named pl011.txt in the kernel. Shouldn't U-Boot's copy be
> named the same?

In the previous discussion a reviewed asked for this change, since it
covers both drivers.

>
>
>> diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
>
>>       uart0: serial@0x80406000 {
>>               compatible = "arm,pl011", "arm,primecell";
>>               reg = <0x80406000 0x1000>;
>> -             clock = <2700000>;
>> +             clock-frequency = <2700000>;
>
> I don't see either "clock" or "clock-frequency" mentioned in the Linux
> binding doc.

This was also discussed on the previous patch thread, and I thought
this was the outcome of the discussion.

>
>> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt
>
>>  Required properties:
>> -- compatible: must be "arm,primecell", "arm,pl011" or "arm,pl010"
>> +- compatible: must be "arm,primecell", "arm,pl011"
>
> It'd be worth mentioning which version of Linux this binding doc came
> from; that text has changed in linux-next since v4.1 which is what I
> assume you're importing.

OK
>
>> diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
>
>> @@ -365,13 +365,15 @@ static int pl01x_serial_ofdata_to_platdata(struct udevice *dev)
>>       struct pl01x_serial_platdata *plat = dev_get_platdata(dev);
>>       fdt_addr_t addr;
>>
>> -     addr = fdtdec_get_addr(gd->fdt_blob, dev->of_offset, "reg");
>> +     addr = dev_get_addr(dev);
>>       if (addr == FDT_ADDR_T_NONE)
>>               return -EINVAL;
>
> That looks like an unrelated change.

Yes, it is not needed in this patch.

Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:

> This binding differs from that of Linux. Update it and change existing
> users.
>
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>
>> This binding differs from that of Linux. Update it and change existing
>> users.
>>
>> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>>
>>> This binding differs from that of Linux. Update it and change existing
>>> users.
>>>
>>> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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:-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Tom Rini]

[-- Attachment #1.1: Type: text/plain, Size: 2057 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > >>On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> > >>
> > >>>This binding differs from that of Linux. Update it and change existing
> > >>>users.
> > >>>
> > >>>Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>> On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>>>>>
>>>>>> This binding differs from that of Linux. Update it and change existing
>>>>>> users.
>>>>>>
>>>>>> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-h+KGxgPPiopAfugRpC6u6w@public.gmane.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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-h+KGxgPPiopAfugRpC6u6w@public.gmane.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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > >>On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> > >>
>> > >>>This binding differs from that of Linux. Update it and change existing
>> > >>>users.
>> > >>>
>> > >>>Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-h+KGxgPPiopAfugRpC6u6w@public.gmane.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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [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-h+KGxgPPiopAfugRpC6u6w@public.gmane.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.
-----------------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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-h+KGxgPPiopAfugRpC6u6w@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> Hi Linus,
>
> On 11 August 2015 at 07:00, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>>
>>> This binding differs from that of Linux. Update it and change existing
>>> users.
>>>
>>> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html