Switch bcm283x platform to use OF_CONTROL

This patch adds device tree support for the bcm2835 GPIO driver.

Signed-off-by Fabian Vogt <[email protected]>

---
 doc/device-tree-bindings/gpio/bcm2835-gpio.txt |  5 +++++
 drivers/gpio/bcm2835_gpio.c                    | 24 ++++++++++++++++++++++++
 2 files changed, 29 insertions(+)
 create mode 100644 doc/device-tree-bindings/gpio/bcm2835-gpio.txt

This patch adds device tree support for the bcm2835 GPIO driver.

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This patch adds device tree support for the bcm283x mini-uart driver.

Signed-off-by Fabian Vogt <[email protected]>

---
 .../serial/bcm2835-aux-uart.txt                    | 10 ++++++++
 drivers/serial/serial_bcm283x_mu.c                 | 28 ++++++++++++++++++++++
 2 files changed, 38 insertions(+)
 create mode 100644 doc/device-tree-bindings/serial/bcm2835-aux-uart.txt

This patch adds device tree support for the bcm283x mini-uart driver.

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

To be able to represent the skip-init platdata element with OF_CONTROL, it needs to be read from the device tree as well and put into the platform data.

Cc Eric Anholt <[email protected]>

Signed-off-by Fabian Vogt <[email protected]>

---
 doc/device-tree-bindings/serial/pl01x.txt | 3 +++
 drivers/serial/serial_pl01x.c             | 2 ++
 2 files changed, 5 insertions(+)

To be able to represent the skip-init platdata element with OF_CONTROL, it needs to be read from the device tree as well and put into the platform data.

Cc Eric Anholt <[email protected]>

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This patch adds dt-bindings as used by the linux kernel device trees for the bcm283x family.

Albert Aribaud <[email protected]>

Signed-off-by Fabian Vogt <[email protected]>

---
 include/dt-bindings/clock/bcm2835-aux.h       | 17 +++++++
 include/dt-bindings/clock/bcm2835.h           | 66 +++++++++++++++++++++++++++
 include/dt-bindings/pinctrl/bcm2835.h         | 27 +++++++++++
 include/dt-bindings/power/raspberrypi-power.h | 41 +++++++++++++++++
 4 files changed, 151 insertions(+)
 create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
 create mode 100644 include/dt-bindings/clock/bcm2835.h
 create mode 100644 include/dt-bindings/pinctrl/bcm2835.h
 create mode 100644 include/dt-bindings/power/raspberrypi-power.h

This patch adds dt-bindings as used by the linux kernel device trees for the bcm283x family.

Albert Aribaud <[email protected]>

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This patch adds device trees for the bcm283x platform to be used with OF_CONTROL. The version 4.8-rc7 of the linux kernel was used as source.

Cc Albert Aribaud <[email protected]>

Signed-off-by Fabian Vogt <[email protected]>

---
 arch/arm/dts/Makefile                  |   9 +
 arch/arm/dts/bcm2835-rpi-a-plus.dts    |  35 ++++
 arch/arm/dts/bcm2835-rpi-a.dts         |  28 +++
 arch/arm/dts/bcm2835-rpi-b-plus.dts    |  36 ++++
 arch/arm/dts/bcm2835-rpi-b-rev2.dts    |  29 +++
 arch/arm/dts/bcm2835-rpi-b.dts         |  23 +++
 arch/arm/dts/bcm2835-rpi.dtsi          |  86 +++++++++
 arch/arm/dts/bcm2835.dtsi              |  25 +++
 arch/arm/dts/bcm2836-rpi-2-b.dts       |  40 ++++
 arch/arm/dts/bcm2836.dtsi              |  78 ++++++++
 arch/arm/dts/bcm2837-rpi-3-b.dts       |  30 +++
 arch/arm/dts/bcm2837.dtsi              |  76 ++++++++
 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi |  19 ++
 arch/arm/dts/bcm283x-rpi-smsc9514.dtsi |  19 ++
 arch/arm/dts/bcm283x.dtsi              | 321 +++++++++++++++++++++++++++++++++
 15 files changed, 854 insertions(+)
 create mode 100644 arch/arm/dts/bcm2835-rpi-a-plus.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-a.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-b-plus.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-b-rev2.dts
 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 arch/arm/dts/bcm2836-rpi-2-b.dts
 create mode 100644 arch/arm/dts/bcm2836.dtsi
 create mode 100644 arch/arm/dts/bcm2837-rpi-3-b.dts
 create mode 100644 arch/arm/dts/bcm2837.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi-smsc9514.dtsi
 create mode 100644 arch/arm/dts/bcm283x.dtsi

This patch adds device trees for the bcm283x platform to be used with OF_CONTROL. The version 4.8-rc7 of the linux kernel was used as source.

Cc Albert Aribaud <[email protected]>

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

The information currently set via platdata has to be represented in the device tree now. bcm283x-uboot.dtsi adds the u-boot specific "skip-init" property to the serial nodes and enables initialization in the pre-reloc phase.

Cc Albert Aribaud <[email protected]>

Signed-off-by Fabian Vogt <[email protected]>

---
 arch/arm/dts/bcm283x-uboot.dtsi | 22 ++++++++++++++++++++++
 arch/arm/dts/bcm283x.dtsi       |  4 +++-
 2 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/bcm283x-uboot.dtsi

The information currently set via platdata has to be represented in the device tree now. bcm283x-uboot.dtsi adds the u-boot specific "skip-init" property to the serial nodes and enables initialization in the pre-reloc phase.

Cc Albert Aribaud <[email protected]>

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

For the Raspberry Pi 3 it needs to be possible to disable the serial device after initialization happens, as only after the GPIO device is available it is known whether the mini uart is usable.

Signed-off-by Fabian Vogt <[email protected]>

---
 drivers/serial/serial_bcm283x_mu.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

For the Raspberry Pi 3 it needs to be possible to disable the serial device after initialization happens, as only after the GPIO device is available it is known whether the mini uart is usable.

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

When using OF_CONTROL, the disabled value of the mini UART platdata gets reset after board_early_init_f. So move detection and disabling to board_init and remove board_early_init_f.
This uses the first device using the mini uart driver, as this method works reliably with different device trees or even no device tree at all.

Signed-off-by Fabian Vogt <[email protected]>

---
 board/raspberrypi/rpi/rpi.c | 40 ++++++++++++++++++++++++++--------------
 include/configs/rpi.h       |  1 -
 2 files changed, 26 insertions(+), 15 deletions(-)

When using OF_CONTROL, the disabled value of the mini UART platdata gets reset after board_early_init_f. So move detection and disabling to board_init and remove board_early_init_f.
This uses the first device using the mini uart driver, as this method works reliably with different device trees or even no device tree at all.

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This patch removes use of U_BOOT_DEVICE in board/raspberrypi/rpi/rpi.c, enables OF_CONTROL in the config and adjusts the rpi_*defconfig configs.

Signed-off-by Fabian Vogt <[email protected]>

---
 arch/arm/Kconfig            |  1 +
 board/raspberrypi/rpi/rpi.c | 37 -------------------------------------
 configs/rpi_2_defconfig     |  2 ++
 configs/rpi_3_32b_defconfig |  2 ++
 configs/rpi_3_defconfig     |  2 ++
 configs/rpi_defconfig       |  2 ++
 6 files changed, 9 insertions(+), 37 deletions(-)

This patch removes use of U_BOOT_DEVICE in board/raspberrypi/rpi/rpi.c, enables OF_CONTROL in the config and adjusts the rpi_*defconfig configs.

Signed-off-by Fabian Vogt <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Quoted 4 lines

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Is there a user-visible or developer-visible benefit to this change? In general, converting to use DT to instantiate devices simply ends up using more code (and hence complexity and time) to get to the exact same state afterwards.

Hi,

Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:

Quoted 10 lines · Fabian Vogt

Quoted 4 lines

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Is there a user-visible or developer-visible benefit to this change? In general, converting to use DT to instantiate devices simply ends up using more code (and hence complexity and time) to get to the exact same state afterwards.

There are various reasons, like:

- The device tree describes the platform, so it can also be used by the linux kernel for configuration (no separate dtb needed)
- Properties are not hardcoded in the u-boot code
- Slightly different hardware deviations do not require significant code changes (like #ifdef or even new platdatas), just a new dts and Kconfig adjustments

It's also mentioned in Simon Glass's talk about DM:
https://events.linuxfoundation.org/sites/events/files/slides/Order%20at%20last%20-%20U-Boot%20driver%20model%20slides%20(2).pdf

Am 05.10.2016 um 18:48 schrieb Fabian Vogt <[email protected]>:

Hi,

Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:

Quoted 10 lines · Fabian Vogt

Quoted 4 lines

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Is there a user-visible or developer-visible benefit to this change? In general, converting to use DT to instantiate devices simply ends up using more code (and hence complexity and time) to get to the exact same state afterwards.

There are various reasons, like:

- The device tree describes the platform, so it can also be used by the linux kernel for configuration (no separate dtb needed)

Quoted 16 lines

Am 05.10.2016 um 18:48 schrieb Fabian Vogt <[email protected]>:

Hi,

Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:

Quoted 10 lines · Fabian Vogt

Quoted 4 lines

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Is there a user-visible or developer-visible benefit to this change? In general, converting to use DT to instantiate devices simply ends up using more code (and hence complexity and time) to get to the exact same state afterwards.

Quoted 4 lines

There are various reasons, like:

- The device tree describes the platform, so it can also be used by the linux kernel for configuration (no separate dtb needed)

With a bit of lobbying, we might even be able to get a working dt from the rpi firmware. That again would enable awesome things like hat support in u-boot :).

Quoted 18 lines · Alexander Graf

Quoted 18 lines

Am 05.10.2016 um 18:48 schrieb Fabian Vogt <[email protected]>:

Hi,

Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:

Quoted 10 lines · Fabian Vogt

Quoted 4 lines

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Is there a user-visible or developer-visible benefit to this change? In general, converting to use DT to instantiate devices simply ends up using more code (and hence complexity and time) to get to the exact same state afterwards.

There are various reasons, like:

Quoted 7 lines

Quoted 3 lines

- The device tree describes the platform, so it can also be used by the

linux kernel for configuration (no separate dtb needed)

With a bit of lobbying, we might even be able to get a working dt from the rpi firmware. That again would enable awesome things like hat support in u-boot :).

I can't imagine the firmware handing any DT off to the kernel other than the one that's being shipped from whatever kernel is being loaded. Being able to update the DT in lockstep with the kernel is very much part of their process. (This makes linux insisting that DT is ABI that must maintain backwards compat quite painful for upstreaming)

Given that the firmware already hands the kernel's DT back to the kernel, it seems like we should be able to load the kernel's DT too if we wanted that.

Quoted 33 lines · On Donnerstag, 6. Oktober 2016 12:32:12 CEST Eric Anholt wrote:

Quoted 18 lines · Alexander Graf

Quoted 18 lines

Am 05.10.2016 um 18:48 schrieb Fabian Vogt <[email protected]>:

Hi,

Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:

Quoted 10 lines · Fabian Vogt

Quoted 4 lines

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Is there a user-visible or developer-visible benefit to this change? In general, converting to use DT to instantiate devices simply ends up using more code (and hence complexity and time) to get to the exact same state afterwards.

There are various reasons, like:

Quoted 7 lines

Quoted 3 lines

- The device tree describes the platform, so it can also be used by the

linux kernel for configuration (no separate dtb needed)

With a bit of lobbying, we might even be able to get a working dt from the rpi firmware. That again would enable awesome things like hat support in u-boot :).

I can't imagine the firmware handing any DT off to the kernel other than the one that's being shipped from whatever kernel is being loaded. Being able to update the DT in lockstep with the kernel is very much part of their process. (This makes linux insisting that DT is ABI that must maintain backwards compat quite painful for upstreaming)

Quoted 3 lines

Given that the firmware already hands the kernel's DT back to the kernel, it seems like we should be able to load the kernel's DT too if we wanted that.

You mean the DT modified by the firmware according to config.txt, at least applying the specified DT overlays?

Quoted 34 lines · Stefan Bruens

Quoted 33 lines · On Donnerstag, 6. Oktober 2016 12:32:12 CEST Eric Anholt wrote:

Quoted 18 lines · Alexander Graf

Quoted 18 lines

Am 05.10.2016 um 18:48 schrieb Fabian Vogt <[email protected]>:

Hi,

Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:

Quoted 10 lines · Fabian Vogt

Quoted 4 lines

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Is there a user-visible or developer-visible benefit to this change? In general, converting to use DT to instantiate devices simply ends up using more code (and hence complexity and time) to get to the exact same state afterwards.

There are various reasons, like:

Quoted 7 lines

Quoted 3 lines

- The device tree describes the platform, so it can also be used by the

linux kernel for configuration (no separate dtb needed)

With a bit of lobbying, we might even be able to get a working dt from the rpi firmware. That again would enable awesome things like hat support in u-boot :).

I can't imagine the firmware handing any DT off to the kernel other than the one that's being shipped from whatever kernel is being loaded. Being able to update the DT in lockstep with the kernel is very much part of their process. (This makes linux insisting that DT is ABI that must maintain backwards compat quite painful for upstreaming)

Quoted 6 lines

Quoted 3 lines

Given that the firmware already hands the kernel's DT back to the kernel, it seems like we should be able to load the kernel's DT too if we wanted that.

You mean the DT modified by the firmware according to config.txt, at least applying the specified DT overlays?

Yeah, that.

Quoted 45 lines · Eric Anholt

Quoted 44 lines · Stefan Bruens

Quoted 42 lines · On Donnerstag, 6. Oktober 2016 12:32:12 CEST Eric Anholt wrote:

Quoted 24 lines · Alexander Graf

Quoted 24 lines

Am 05.10.2016 um 18:48 schrieb Fabian Vogt <[email protected]>:

Hi,

Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:

Quoted 7 lines · Fabian Vogt

Quoted 5 lines

This patch series modifies the used drivers to work with OF_CONTROL
and switches the board code and configs to use it. The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Quoted 6 lines

Is there a user-visible or developer-visible benefit to this change? In
general, converting to use DT to instantiate devices simply ends up using more code (and hence complexity and time) to get to the exact same
state afterwards.

There are various reasons, like:

- The device tree describes the platform, so it can also be used by the

Quoted 6 lines

Quoted 1 line

linux kernel for configuration (no separate dtb needed)

With a bit of lobbying, we might even be able to get a working dt from
the rpi firmware. That again would enable awesome things like hat support in u-boot :).

I can't imagine the firmware handing any DT off to the kernel other than
the one that's being shipped from whatever kernel is being loaded. Being able to update the DT in lockstep with the kernel is very much part of their process. (This makes linux insisting that DT is ABI that must maintain backwards compat quite painful for upstreaming)

Given that the firmware already hands the kernel's DT back to the kernel, it seems like we should be able to load the kernel's DT too if we wanted that.

Quoted 5 lines

Quoted 3 lines

You mean the DT modified by the firmware according to config.txt, at least
applying the specified DT overlays?

Yeah, that.

That would also be a good thing, yes.

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Fabian Vogt (9):
gpio: bcm2835: add device tree support
serial: bcm283x_mu: add device tree support
serial: pl01x: expose skip_init platdata option in DT
fdt: add dt-bindings for bcm2835
fdt: import bcm283x device tree sources from the linux kernel tree
fdt: adjust bcm283x device tree for u-boot
serial: bcm283x_mu: support disabling after initialization
board: rpi: move uart deactivation to board_init
ARM: bcm283x: use OF_CONTROL for bcm283x

 arch/arm/Kconfig                                   |   1 +
 arch/arm/dts/Makefile                              |   9 +
 arch/arm/dts/bcm2835-rpi-a-plus.dts                |  35 +++
 arch/arm/dts/bcm2835-rpi-a.dts                     |  28 ++
 arch/arm/dts/bcm2835-rpi-b-plus.dts                |  36 +++
 arch/arm/dts/bcm2835-rpi-b-rev2.dts                |  29 ++
 arch/arm/dts/bcm2835-rpi-b.dts                     |  23 ++
 arch/arm/dts/bcm2835-rpi.dtsi                      |  86 ++++++
 arch/arm/dts/bcm2835.dtsi                          |  25 ++
 arch/arm/dts/bcm2836-rpi-2-b.dts                   |  40 +++
 arch/arm/dts/bcm2836.dtsi                          |  78 +++++
 arch/arm/dts/bcm2837-rpi-3-b.dts                   |  30 ++
 arch/arm/dts/bcm2837.dtsi                          |  76 +++++
 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi             |  19 ++
 arch/arm/dts/bcm283x-rpi-smsc9514.dtsi             |  19 ++
 arch/arm/dts/bcm283x-uboot.dtsi                    |  22 ++
 arch/arm/dts/bcm283x.dtsi                          | 323 +++++++++++++++++++++
 board/raspberrypi/rpi/rpi.c                        |  77 ++---
 configs/rpi_2_defconfig                            |   2 +
 configs/rpi_3_32b_defconfig                        |   2 +
 configs/rpi_3_defconfig                            |   2 +
 configs/rpi_defconfig                              |   2 +
 doc/device-tree-bindings/gpio/bcm2835-gpio.txt     |   5 +
 .../serial/bcm2835-aux-uart.txt                    |  10 +
 doc/device-tree-bindings/serial/pl01x.txt          |   3 +
 drivers/gpio/bcm2835_gpio.c                        |  24 ++
 drivers/serial/serial_bcm283x_mu.c                 |  46 ++-
 drivers/serial/serial_pl01x.c                      |   2 +
 include/configs/rpi.h                              |   1 -
 include/dt-bindings/clock/bcm2835-aux.h            |  17 ++
 include/dt-bindings/clock/bcm2835.h                |  66 +++++
 include/dt-bindings/pinctrl/bcm2835.h              |  27 ++
 include/dt-bindings/power/raspberrypi-power.h      |  41 +++
 33 files changed, 1152 insertions(+), 54 deletions(-)
 create mode 100644 arch/arm/dts/bcm2835-rpi-a-plus.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-a.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-b-plus.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-b-rev2.dts
 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 arch/arm/dts/bcm2836-rpi-2-b.dts
 create mode 100644 arch/arm/dts/bcm2836.dtsi
 create mode 100644 arch/arm/dts/bcm2837-rpi-3-b.dts
 create mode 100644 arch/arm/dts/bcm2837.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi-smsc9514.dtsi
 create mode 100644 arch/arm/dts/bcm283x-uboot.dtsi
 create mode 100644 arch/arm/dts/bcm283x.dtsi
 create mode 100644 doc/device-tree-bindings/gpio/bcm2835-gpio.txt
 create mode 100644 doc/device-tree-bindings/serial/bcm2835-aux-uart.txt
 create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
 create mode 100644 include/dt-bindings/clock/bcm2835.h
 create mode 100644 include/dt-bindings/pinctrl/bcm2835.h
 create mode 100644 include/dt-bindings/power/raspberrypi-power.h

Hi,

any news on this? As far as I can tell nothing happened after my last reply to this thread, so: Ping!

Thanks,
Fabian

Am Montag, 26. September 2016, 14:26:42 CET schrieben Sie:

Quoted 63 lines

This patch series modifies the used drivers to work with OF_CONTROL and switches the board code and configs to use it.
The added device trees are directly from the linux kernel tree and can thus be used for booting the (upstream) kernel.

Fabian Vogt (9):
gpio: bcm2835: add device tree support
serial: bcm283x_mu: add device tree support
serial: pl01x: expose skip_init platdata option in DT
fdt: add dt-bindings for bcm2835
fdt: import bcm283x device tree sources from the linux kernel tree
fdt: adjust bcm283x device tree for u-boot
serial: bcm283x_mu: support disabling after initialization
board: rpi: move uart deactivation to board_init
ARM: bcm283x: use OF_CONTROL for bcm283x

 arch/arm/Kconfig                                   |   1 +
 arch/arm/dts/Makefile                              |   9 +
 arch/arm/dts/bcm2835-rpi-a-plus.dts                |  35 +++
 arch/arm/dts/bcm2835-rpi-a.dts                     |  28 ++
 arch/arm/dts/bcm2835-rpi-b-plus.dts                |  36 +++
 arch/arm/dts/bcm2835-rpi-b-rev2.dts                |  29 ++
 arch/arm/dts/bcm2835-rpi-b.dts                     |  23 ++
 arch/arm/dts/bcm2835-rpi.dtsi                      |  86 ++++++
 arch/arm/dts/bcm2835.dtsi                          |  25 ++
 arch/arm/dts/bcm2836-rpi-2-b.dts                   |  40 +++
 arch/arm/dts/bcm2836.dtsi                          |  78 +++++
 arch/arm/dts/bcm2837-rpi-3-b.dts                   |  30 ++
 arch/arm/dts/bcm2837.dtsi                          |  76 +++++
 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi             |  19 ++
 arch/arm/dts/bcm283x-rpi-smsc9514.dtsi             |  19 ++
 arch/arm/dts/bcm283x-uboot.dtsi                    |  22 ++
 arch/arm/dts/bcm283x.dtsi                          | 323 +++++++++++++++++++++
 board/raspberrypi/rpi/rpi.c                        |  77 ++---
 configs/rpi_2_defconfig                            |   2 +
 configs/rpi_3_32b_defconfig                        |   2 +
 configs/rpi_3_defconfig                            |   2 +
 configs/rpi_defconfig                              |   2 +
 doc/device-tree-bindings/gpio/bcm2835-gpio.txt     |   5 +
 .../serial/bcm2835-aux-uart.txt                    |  10 +
 doc/device-tree-bindings/serial/pl01x.txt          |   3 +
 drivers/gpio/bcm2835_gpio.c                        |  24 ++
 drivers/serial/serial_bcm283x_mu.c                 |  46 ++-
 drivers/serial/serial_pl01x.c                      |   2 +
 include/configs/rpi.h                              |   1 -
 include/dt-bindings/clock/bcm2835-aux.h            |  17 ++
 include/dt-bindings/clock/bcm2835.h                |  66 +++++
 include/dt-bindings/pinctrl/bcm2835.h              |  27 ++
 include/dt-bindings/power/raspberrypi-power.h      |  41 +++
 33 files changed, 1152 insertions(+), 54 deletions(-)
 create mode 100644 arch/arm/dts/bcm2835-rpi-a-plus.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-a.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-b-plus.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-b-rev2.dts
 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 arch/arm/dts/bcm2836-rpi-2-b.dts
 create mode 100644 arch/arm/dts/bcm2836.dtsi
 create mode 100644 arch/arm/dts/bcm2837-rpi-3-b.dts
 create mode 100644 arch/arm/dts/bcm2837.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi-smsc9514.dtsi

Quoted 10 lines

 create mode 100644 arch/arm/dts/bcm283x-uboot.dtsi
 create mode 100644 arch/arm/dts/bcm283x.dtsi
 create mode 100644 doc/device-tree-bindings/gpio/bcm2835-gpio.txt
 create mode 100644 doc/device-tree-bindings/serial/bcm2835-aux-uart.txt
 create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
 create mode 100644 include/dt-bindings/clock/bcm2835.h
 create mode 100644 include/dt-bindings/pinctrl/bcm2835.h
 create mode 100644 include/dt-bindings/power/raspberrypi-power.h

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