Hi all,
When moving functionality from C code to DT, we're regularly faced with
stable DT issues: old DTBs should keep on working. This requires keeping
workaround code in the kernel.
An alternative solution to having workaround C code, would be to
dynamically modify the DT, to add missing device nodes and phandle links.
This has several advantages:
- All workarounds are kept together,
- Workarounds can be enabled/disabled using a single Kconfig option,
- Individual driver code is not polluted by workaround code.
Examples of missing support in DT are:
- A device node for the R-Car RST (Reset Controller), which a.o.
provides access to the Mode Pins (currently handled using an
hardcoded address in platform/driver code), cfr. the series
"[PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for
obtaining mode pin state" I've just sent
(http://www.spinics.net/lists/linux-renesas-soc/msg04289.html),
- A device node for the R-Car SYSC (System Controller), to link CPUs
to their respective power domains (On R-Car Gen2 CPUs can be
auto-detected, as there's a register indicating which CPU cores are
present),
- Add a device node for the R-Car Gen2 APMU (Advanced Power
Management Unit), for modern CPU bringup using "enable-method".
Note that the method from this RFC doesn't work for
"enable-method", as that is parsed in arm_dt_init_cpu_maps(),
immediately after unflatten_device_tree(), long before initcalls
run.
However, there are other possible uses:
- Workarounds for hardware bugs: early engineering samples of an SoC
may have non-functional devices. This would allow to describe the
latest (functional) hardware in the .dtsi, knowing that the fixup
code will disable non-functional devices when running on an early
engineering sample, based on reading the PRR (Product Revision
Register).
- Handle other differences between SoC versions, e.g. change
compatible values for an early engineering sample that needs special
handling, or limit the features of a device.
- Add SoC-specific compatible values to all device nodes (e.g. add
"renesas,r8a7795-wdt" to a node already having
"renesas,rcar-gen3-wdt" when running on r8a7795). This would make
it easier to share .dtsi files within the same SoC family, without
relying on e.g. C preprocessor tricks.
This proof-of-concept implements this for the missing R-Car RST (Reset
Controller) node. This poc is not suitable for all of the above, as some
DT structures (e.g. the CPU's "enable-method) are parsed long before
early_initcall(), and would need a different workaround.
What do you think?
Should this be handled at another level? E.g. operate on the FDT?
Thanks!
Geert Uytterhoeven (1):
soc: renesas: Add DT fixup code for missing r8a7791 RST
drivers/soc/renesas/Makefile | 4 +
drivers/soc/renesas/renesas-dt-fixup.c | 159 +++++++++++++++++++++++++++++++++
2 files changed, 163 insertions(+)
create mode 100644 drivers/soc/renesas/renesas-dt-fixup.c
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
