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

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 9:40 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:34 PM, jonsmirl at gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach at gmail.com> wrote:
>>> On 2 October 2014 14:56, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede at 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.

Does that init have to be running to get device drivers off from
initrd? I thought the kernel was able to load them directly from
initrd earlier.


>
>> 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
>



-- 
Jon Smirl
jonsmirl at gmail.com