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

[jonsmirl at gmail.com]

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.

>
> This is also the reason why we're working on adding hdmi console support
> to u-boot in the first place, to debug boot problems.
>
> So the whole "write a HW specific driver" answer just does not cut it. Just
> like we have vgacon / efifb on x86, we need something similar on ARM, and
> since ARM does not have a generic hw interface like vga, we need a firmware
> solution like efifb.
>
> So as said the whole "write a HW specific driver" just will not work, so
> that means using something like simplefb. Now I can take simplefb, copy
> it to rename it to firmwarefb or ubootfb or something, and then add the clocks
> support, but that is just silly.
>
> You indicate that you don't have the time for this discussion, and I note that
> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
> my responsibility (and in my own benefit) to stop this from growing into
> a monster ?
>
> To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
> which will be just a copy with the clocks added.
>
> Regards,
>
> Hans



-- 
Jon Smirl
jonsmirl at gmail.com