Switch bcm283x platform to use OF_CONTROL
Get series with b4
b4 am 20161007204240.GK4884@bill-the-catVersions newest first
- v1 Latest9 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/9 | gpio: bcm2835: add device tree support | +0 | 0 replies | |
| 2/9 | serial: bcm283x_mu: add device tree support | +0 | 0 replies | |
| 3/9 | serial: pl01x: expose skip_init platdata option in DT | +0 | 0 replies | |
| 4/9 | fdt: add dt-bindings for bcm2835 | +0 | 0 replies | |
| 5/9 | fdt: import bcm283x device tree sources from the linux kernel tree | +0 | 0 replies | |
| 6/9 | fdt: adjust bcm283x device tree for u-boot | +0 | 0 replies | |
| 7/9 | serial: bcm283x_mu: support disabling after initialization | +0 | 0 replies | |
| 8/9 | board: rpi: move uart deactivation to board_init | +0 | 0 replies | |
| 9/9 | ARM: bcm283x: use OF_CONTROL for bcm283x | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 0/9] Switch bcm283x platform to use OF_CONTROL
Quoted 36 lines · Eric Anholt
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_CONTROLand 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 8 lines
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.
That would also be a good thing, yes.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161007/69ea4530/attachment.sig>