Re: No more new fbdev drivers, please

[Dave Airlie]

On 27 September 2015 at 06:49, Rob Clark <robdclark@xxxxxxxxx> wrote:
> On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
>> Hi David,
>>
>> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
>>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>>> <geert@xxxxxxxxxxxxxx> wrote:
>>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
>>>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>>>> <geert@xxxxxxxxxxxxxx> wrote:
>>>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>>>> to these existing really simple drivers?
>>>>>
>>>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>>>
>>>> Thanks for the list!
>>>>
>>>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>>>> several fbdev drivers that have less than 200 LoC.
>>>> Granted, these really small ones support a single fixed video mode only, but
>>>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>>>
>>>> I'm sure DRM can do better?
>>>
>>> Is counting lines really the level of the discussion to go here?
>>
>> LoC is not the most important. But if the smallest DRM driver needs an order
>> of magnitude more LoC than the smallest fbdev driver, I start to wonder.
>
> I think most of the drm/kms drivers are bigger due to more features..
> iirc original tilcdc was ~2k loc (compared to ~1.6kloc for da8xx-fb),
> but it already supported multiple modes, page flipping, vblank
> notification, etc.  It has grown since then.  Although still probably
> smaller than downstream da8xx-fb + tda998x hdmi bridge (and re-using
> the same tda998x bridge code with several other drivers too, compared
> to downstream solution for the same)..
>
> Probably there is room for more helpers for even more restrictive hw.

My main worry for having helpers for "simple" hw, is that people start
using them
to have a minimal 400loc driver, but once they add any feature outside
the helper
they have to rewrite their driver to avoid the helpers.

Most of the drm driver is boilerplate, we could possibly reduce the boilerplate,
but I'm not sure it's worth the effort to save somebody a small bit of
trouble at
bringup.

loc is a pointless tool for measuring this, a small drm driver will be as simple
as a small fbdev driver, and will likely provide more features that people need.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/