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

[Sascha Hauer]

On Sat, Feb 04, 2012 at 11:21:34AM +0000, Dave Airlie wrote:
> 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

midlayer is a tainted word and I regret calling it like this right
after sending my mail. Let's call it helper then ;)

> , btw what
> is going to count as a simple framebuffer device? 1 crtc/connector?

It's not limited in the count of crtcs/connectors/encoders.

> 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.

My goal is to write a driver for the i.MX IPU driver. I realized that
I had to duplicate most of the exynos driver. Having written several
framebuffer drivers (for i.MX1, netx, i.MX28) I know that all these
devices are not very different, so my code is written with having
these kind of devices in my mind.

Anyway, my code does not need this particular patch, so we can delay
(or drop) it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |