On 08/13/2014 02:49 AM, David Herrmann wrote:
Hi
On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
<grant.likely@xxxxxxxxxxxx> wrote:
On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@xxxxxxxxx> wrote:
The next commit will handle clocks correctly, so that these do not get
automatically disabled on certain SoC simplefb implementations. As a
result, the removal of this simplefb driver, and the release of the
clocks, is rather final, and only a full display driver can work after
this. So, it makes sense to also flag the dt node as disabled, even
though it has no real value today.
Signed-off-by: Luc Verhaegen <libv@xxxxxxxxx>
Please, no.
Drivers should not be modifying the device tree without and
exceptionally good reason for doing so. Drivers are to treat the DT as
immutable.
* the exception is an overlay driver which add new devices to the
kernel. Definitely not the case here.
Why? I think we have exactly that case:
* DT describes the real hw properly and those parts are immutable
* Additionally, bootloaders create firmware-framebuffers and
create simple-framebuffer devices for them. Those are
valid as long as no driver reconfigured the real hw.
* Once a real hw-driver loads, it might destroy the existing
framebuffers, thus, it should also destroy the platform device.
* If the real hw-driver is unloaded, it might re-create the FB
and thus create a new (or enable the old) platform device.
My intention was always that a bootloader's addition of a simplefb node
to the DT would be user-configurable or driven by the original DT
content. As such, there shouldn't ever be both a DT node describing the
"real" HW and simplefb. In other words, if the DT already has the "real"
DT node, the bootloader should automatically (or under user command) not
add the simpefb node.
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
