On Wed, Oct 01, 2014 at 12:12:20PM -0600, Stephen Warren wrote: > On 10/01/2014 11:54 AM, jonsmirl@xxxxxxxxx wrote: >> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
