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

[Michal Suchanek]

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.

>From the point of view of kernel once it has handed over to init in
initrd the boot is finished. The init is normal userspace running off
normal filesystem backed by a device-specific driver (initrd).

That some systems do not continue to run off this filesystem
indefinitely and in fact go out of their way to expunge the initrd
filesystem and reclaim its resources by exercising some syscalls
specifically devised for that use case is not relevant to the kernel.
It cannot know when the userspace considers the boot finished enough.
Sometimes even manual steps are required to finish booting when the
automatic scripts fail.

simplefb as early console is meant exactly for diagnosing and fixing
such failures in absence of an uart.

Thanks

Michal