On Sun, Aug 03, 2014 at 01:53:56PM +0200, Maxime Ripard wrote:
> Hi,
> 
> You forgot to Cc the linux-arm-kernel mailing-list and Emilio.

This was deliberate, as the contents of the patch is still 
controversial.

> That looks wrong. Why doesn't simplefb claim the clocks itself?

The code up there uses clock names, and a set of three names which 
requires the code to know which clocks are needed to make u-boot happy. 
This is fundamentally wrong, as it spreads the u-boot graphics driver 
over both u-boot and the kernel, and this sort of detachment and lack 
of segmentation is totally unacceptable.

So, to have simplefb claim these clocks, as is, simplefb would need to 
know the names of the relevant clocks. Adding platform and u-boot 
version specific code to the simplefb driver directly is even more 
fundamentally wrong.

The solution for that is to have u-boot create the list of relevant 
clocks in the dt node for simplefb. Which then runs straight into the 
clocks being referenced as <&label register-bit-offset>, and the whole 
discussion around that again.

As stated, i will be working on writing up the code for that, and it 
will nicely show how contrived this is. Time will further show how the 
lack of abstraction with respect to clocks will come back to bite us.

The most obvious sign is that our clock code is spread over 3 places:
* once in the dts, to have other nodes claim the clock, by
  <&label register-bit offset>
* once in the dts where the clock register is given a list of bit names 
  but no bit definitions.
* once in the clock driver where bitmasks exist (but no names) which 
  must match the list of names in the dts perfectly.
If simplefb not claiming the clocks felt fundamentally wrong, then the 
above should've made your hair stand on end. It is pure luck that that 
works today, but that sort of luck will run out very quickly.

Luc Verhaegen.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to