[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Wed, Aug 27, 2014 at 6:35 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>> On 08/27/2014 11:31 AM, Thierry Reding wrote:

snip

> In another mail in this thread you've mentioned 2 uses for simplefb:
>
> 1) Serving as *the* fb until a kms driver is present
> 2) Allowing for output of early kernel boot messages.
>
> I agree that those are the 2 use-cases we're dealing with here.
>
> Note that the whole discussion we're having hear about disabling the clocks
> once hardware probing is "done", is moot for 1. One possible way mentioned
> of dealing with 1. is to mark these clocks as always on for now, and then we
> need to drop this hack (I cannot call this anything else then a hack), once
> we get kms, meaning interdependencies between the dropping patch and the kms
> adding patches, etc. All not very pretty.
>
> For 2. We have what you call "mostly integration issues". Allow me to copy
> and paste in another bit of this thread here:

These are two independent problems.

> 1) Serving as *the* fb until a kms driver is present

Why can't we whip together a real device specific fbdev driver and
quit trying to run without a device specific driver in place? History
has shown that to be bad idea except during early boot when there
isn't a choice.

fbdev drivers are pretty simple things and you don't have to make one
that implements every feature. fbdev driver don't even have to
implement mode setting. They can just live with the mode initially
provided and refuse to change it. Communicating this initial mode info
on the kernel command line is already supported so we don't even need
a device tree change. This is the transition tool until KMS gets
written.

But it needs to be a device specific fbdev implementation, not
simplefb. That's because the device specific driver is going to claim
those clocks and regulators.

> 2) Allowing for output of early kernel boot messages.

For this to work the kernel needs to know two things - address of the
framebuffer and the x/y layout. Then just nuke this display when the
kernel finishes the boot process.

One of two things will happen.
1) the fbdev driver has been loaded. It has claimed the clocks, taken
care of memory, etc. If KMS is around, load it instead. When kernel
tries to nuke the display nothing will happen.
2) Your display goes blank because the kernel has disabled clocks and
reclaimed the memory. Take that as a hint to write a fbdev driver.

pages more snipped....

-- 
Jon Smirl
jonsmirl at gmail.com