On Tue, Aug 26, 2014 at 12:55:06PM +0200, Thierry Reding wrote:

On Tue, Aug 26, 2014 at 11:06:12AM +0100, Mark Brown wrote:

quoted

On Tue, Aug 26, 2014 at 11:18:54AM +0200, Thierry Reding wrote:

quoted

On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:

quoted

quoted

quoted

We can't assume that the "proper" setup is that the supply should be
left on.

quoted

quoted

Right, we can't assume it, but if we're given appropriate hints I think
it's fair to keep resources set up by firmware untouched.

quoted

I really can't see any sensible way to do that in an OS neutral thing
like DT.

It should be possible to simply define a property for this that the
firmware can add to the device tree.

There are other subsystems for example where we don't touch resources
unless they are explicitly accessed. GPIO and pinmux are two examples of
those. The reason is precisely so that we don't undo anything that the
firmware already set up and that may be needed during boot.

GPIOs and pinmuxes are quite different in both how they get set up (you
don't typically have their configuration set in ROM and shoehorned into
the board which is what we're dealing with for a lot of PMICs) and in
the consequences of leaving them alone.

I really don't think defining a custom property to work around a timing
issue in a particular OS startup sequence is the best way forwards here
- we should solve our startup sequencing issue rather than layer on
hacks, otherwise we're adding fragility and work to the system.  The
flag would need to be explicitly added and then it means we're stuck
with the behaviour even if the system gets smarter.

Before booting the kernel it will modify the DTB and insert a node that
contains information about the framebuffer that was set up. The node
contains properties that define the resolution, the format and the
physical address of the framebuffer memory. An in-kernel driver will
then be able to use that information very early in the boot process to
show the console (to replace the serial console that's usually not
available on consumer devices). Later on when a real driver can be
loaded it should take over the resources from simplefb and remove it.

OK, so this is not meaningfully different to just loading the driver
normally - it's exactly the same scenario.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/57d05d8e/attachment.sig>