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

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 10/02/2014 03:34 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
>> On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> ...
>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>
>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>
>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>
>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>> and everything will just work.
>>>>>>>>>
>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>
>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>
>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>
>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>
>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>> won't have video output until quite late into the boot process.
>>>>>
>>>>> You need both.
>>>>>
>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>> process -- the same thing happens with the early printk UART driver.
>>>>> EARLYPRINTK on the command line enables this.
>>>>>
>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>> set_console() but it's been a while.
>>>>
>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>>
>>> Trying to indefinitely extend the life of the earlyprintk or
>>> earlyframeuffer is what causes problems.  Doing that forces you to
>>> basically turn them into device specific drivers which do things like
>>> claiming device specific resources and gaining device specific
>>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>>
>>
>> No. When initrd is running boot has already finished as far as kernel
>> is concerned.
>>
>> And you have to extend the life of the simplefb from the time boot has
>> finished through the time kernel mounts initrd (or other root) and
>> hands over to userspace found on the initrd, through the time this
>> userspace searches for the kms driver and until the time it has
>> finally loaded if that ever succeeds.
> 
> Does the clock and regulator cleanup happen before drivers can load
> off from initrd? I didn't think it did but I might be wrong.

Yes the cleanup happens before the first userspace process starts, be
that the fake /sbin/init from the initrd, or the real /sbin/init if
no initrd is used.

> So maybe a solution to this is to delay that cleanup until after
> initrd drivers have a chance to load. Of course it is not possible to
> delay it indefinitely (like for disk based loading) but delaying over
> initrd is a fixed limit.

And delaying over the initrd is not helpful. Not having the real driver
load for whatever reasons, is not necessarily a boot blocking event,
and if it us just missing will not lead to any error messages.

So the boot will continue normally with a black screen, and things are
still impossible to debug.

Regards,

Hans