[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl at gmail.com]

On Thu, Aug 14, 2014 at 8:45 PM, Henrik Nordström
<henrik at henriknordstrom.net> wrote:
> tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl at gmail.com:
>
>> So what are the rules going to be? Once the OS is up and starts
>> changing things the state in the DT and the OS are going to diverge.
>> How does this get handled for a kernel driver that can load/unload?
>> Should the kernel remove those state nodes as soon as it alters the
>> state?
>
> hardware that is no longer there should also not be represented/active
> in DT.
>
> A simple fb that have been torn down is no more, no different from never
> having been there. It can be argued that it never was in the first place
> (i.e. that it is not actually hardware) but that it another can of worms
> and both have their benefits and drawbacks. One thing is certain
> however, as far as simplefb is concerned it is hardware, not really any
> different from a persistent framebuffer with hardwired settings in
> hardware.

How does the kernel know what clocks to protect? A list in the
simplefb node?  This list of clocks is a reason for adding simplefb to
the compatible list for the real hardware.  That way it won't be
duplicated.

The issues with parameter conflicts between simplefb and the real
hardware can be dealt with.  If the real hardware wants to add the
simplefb compatible field it will need to get its parameters sorted
out so that they don't conflict. Clock syntax is standardized in the
DTS so it shouldn't be a problem.

You can also argue that simplefb should never occur in a DTS file. It
is something that uboot will add. And then the kernel will remove when
simplefb loads KMS.

That logic should apply to all of these dynamic fields. You don't want
stale state data in the DT.

>
> Regarding kexec, it's the responsibility of the kernel doing kexec to
> make sure DT and hardware matches for the next started kernel. With
> hardware that can be reconfigured it is not safe to assume that the DT
> can be passed as-is from before the kernel reconfigured hardware. If the
> currently running kernel wants to set up a framebuffer for simplefb use
> by the next kernel than it's free to do so, but in either case it needs
> to provide the right information to next kernel.
>
> If it was given a simplefb node, but then killed the simplefb then no
> simplefb node should be provided to the next kernel. If it was not given
> a simplefb node, but have configured the hardware suitable for simplefb
> node then it may provide a simplefb node.
>
> A UART that have changed rate no longer have that rate.
>
> Same applies to numerous other items as well. If a kernel remaps IRQs,
> bus addresses, or whatever in hardware aspects where such changes is
> possible then DT needs to be updated as well. A bit less common than a
> simplefb being destroyed by driver reconfiguring the framebuffer, but if
> you look at it from a little distance then the problem is exactly the
> same. Hardware is not 100% static, and therefore hardware description
> also can not be 100% static. And hardware is getting more and more
> dynamically reconfigurable.
>
> A DT that contains false information is generally worse than no DT / not
> having that information at all.
>
> Regards
> Henrik
>



-- 
Jon Smirl
jonsmirl at gmail.com