[PATCH 09/20] drm fb_helper: use lists for crtcs.

[Dave Airlie]

On Sat, Feb 4, 2012 at 10:47 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Fri, Feb 03, 2012 at 10:04:27AM +0000, Dave Airlie wrote:
>> On Wed, Feb 1, 2012 at 10:38 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
>> > The fb helper uses fixed size arrays for the associated crtcs.
>> > This is an unnecessary limitation, so instead use a list to
>> > store the crtcs and allocate them dynamically.
>>
>> I need more reasons on why this is a unnecessary limitation, for what?
>>
>> Its a lot less cache friendly to use a linked list here for not much gain,
>
> How often do you change modes? This code is run when the user changes
> virtual terminals, which is not very performance critical.

But why make it worse unless you have a good reason?

> I am working on a mid layer to connect simple framebuffer devices to
> kms and it would be convenient to just add a crtc to a drm device once
> it appears. This works fine for connectors and encoders, why not also
> for crtcs?

I'd like to see the midlayer before changing the core too much, I hate
midlayers as they always cause more pain in the long run than they
solve,
the DRM is one of the worst examples of midlayer design and I'd rather
not propogate it any further.

Hopefully you meant to say you are working on a set of helper
functions that kms drivers for simple framebuffers can use, btw what
is going to count as a simple framebuffer device? 1 crtc/connector?
I've got to write a bunch of "simple" kms drivers but I'd really
rather this developed the other way. Write a drivers for two simple
devices, then carve the common code into helpers.

Dave.