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

[Julian Calaby]

Hi Thierry,

On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
>> Hi Thierry,
>
> If you address people directly please make sure they are in the To:
> line. Or at least Cc.

Sorry about that, the mailing list I received this through (Google
Groups based) generally strips to: and CC: lines, so my mail client
(Gmail) doesn't do it automatically. I'm still getting used to it.

>> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> <thierry.reding at gmail.com> wrote:
>> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> > [...]
>> >> > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> > firmware has set up, which is the only reason why it will work for many
>> >> > people. What is passed in via its device tree node is the minimum amount
>> >> > of information needed to draw something into the framebuffer. Also note
>> >> > that the simplefb device tree node is not statically added to a DTS file
>> >> > but needs to be dynamically generated by firmware at runtime.
>> >>
>> >> Which makes the whole even simpler, since the firmware already knows
>> >> all about which clocks it had to enable.
>> >
>> > It makes things very complicated in the firmware because it now needs to
>> > be able to generate DTB content that we would otherwise be able to do
>> > much easier with a text editor.
>>
>> As far as the kernel is concerned, this is a solved problem.
>
> It's not completely solved. There's still the issue of no generic way to
> specify regulators like you can do for clocks, resets or power domains.
> But the kernel isn't the real issue here. The issue is the firmware that
> now has to go out of its way not only to initialize display hardware but
> also create device tree content just to make Linux not turn everything
> off.

My point is that the firmware is going to be doing complicated stuff
already, adding and using some helpers to configure a device tree node
is relatively simple in comparison to dealing with the actual
hardware. It wouldn't surprise me if u-boot, for example, ended up
with a set of functions to handle this exact case as more graphics
hardware gets brought up.

>> Firmware is going to be doing some dark magic to set up the hardware
>> to be a dumb frame buffer and some other stuff to add the simplefb
>> device node - so by this point, adding the clocks (or whatever)
>> required by the hardware should be fairly uncomplicated - the firmware
>> already knows the hardware intimately. As for the actual device tree
>> manipulations, U-boot (or whatever) will probably just grow some
>> helper functions to make this simple.
>
> Have you looked at the code needed to do this? It's not at all trivial.
> And the point is really that all this information is there already, so
> we're completely duplicating this into a dynamically created device tree
> node and for what reason? Only to have one driver request all these
> resources and have them forcefully released a few seconds later.
>
>> Alternatively, it could simply add the relevant data to an existing
>> device node and munge it's compatible property so simplefb picks it
>> up.
>
> Yes, I think that'd be a much better solution. Of course it's going to
> be very difficult to make that work with a generic driver because now
> that generic driver needs to parse the DT binding for any number of
> "compatible" devices.

Not necessarily.

The patch that started this discussion can work with any number of
clocks specified in a "clocks" property. Therefore all that needs to
happen is that the final hardware binding specifies it's clocks that
way. This is how, for example, the ahci_platform driver's clock code
works.

I'm sure that as hardware diversifies, the other subsystems will grow
in similar directions and eventually be dealt with using similarly
generic code.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/