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

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@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.