Re: [PATCH 0/2] drm: add SimpleDRM driver

[Daniel Vetter]

On Thu, Aug 04, 2016 at 05:59:42PM +0200, Luc Verhaegen wrote:
> On Thu, Aug 04, 2016 at 05:44:23PM +0200, David Herrmann wrote:
> > On Thu, Aug 4, 2016 at 5:34 PM, Luc Verhaegen <libv@xxxxxxxxx> wrote:
> > > Do we really want to recreate a 400+ email thread again, or are we
> > > capable of learning from the past?
> > 
> > No we don't. And no-one intends to. I am fully aware of the discussion
> > that introduced the clock-dependencies to simplefb, and I gladly
> > accept patches that add such support to SimpleDRM. Did anyone say
> > otherwise? This series adds initial support for the devices _we_ know
> > and can test (which is x86 and RPi, in my case). If someone wants
> > support for more devices, please send patches. Why does this have to
> > be included (or even discussed) as part of this submission?
> 
> You're right, it does not have to be included until there is a usecase.
> 
> But on the otherhand i have become pretty allergic to this as that other 
> discussion was completely useless and pointless and stemmed only from 
> the fact that people had been kidding themselves all along that simplefb 
> was going to be simple and not would need anything extra.
> 
> If we can avoid fooling ourselves to the same extent as we did before, 
> then putting this off until there is a real usecase is perfectly fine by 
> me.
> 
> If not, just add this trivial generic addition straight from an existing 
> example. 

I stand corrected on this, seems indeed we need this to avoid issues. I
guess on x86 we don't need this since a pci device is a mostly
well-defined entity, and as long as we stop vesa/uefi for simpledrm before
the real driver loads it'll be all fine.

But on arm it's indeed different with clocks (and I guess sooner or later
some power domains too, or whatever else really). I think as long as it
doesn't go beyond "grab resource on load, drop it again on unload" I'm
prefectly fine with adding all that's needed to simpledrmfb. And totally
up to the folks enabling this whether it should be there upfront or only
once needed for a given platform.
-Daniel

> 
> Luc Verhaegen.
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch