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

[Luc Verhaegen]

On Wed, Oct 01, 2014 at 12:12:20PM -0600, 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.

Define "resource management".

Simplefb should never alter resources. It should never alter anything 
that $bootloader set up. It should however claim resources to prevent 
them from being altered.

Perhaps the word "managing" should be split up in "claiming" and 
"altering" here.

Luc Verhaegen.