Message-ID: <3877516e-3db3-f732-b44f-7fe12b175226@gmx.de>
Date:   Wed, 26 Jan 2022 11:59:52 +0100
From:   Helge Deller <deller@....de>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Thomas Zimmermann <tzimmermann@...e.de>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Phillip Potter <phil@...lpotter.co.uk>,
        Lee Jones <lee.jones@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Carlis <zhangxuezhi1@...ong.com>, linux-kernel@...r.kernel.org,
        linux-staging@...ts.linux.dev, linux-fbdev@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        Michael Hennerich <michael.hennerich@...log.com>,
        Andy Shevchenko <andy@...nel.org>
Subject: Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

On 1/26/22 11:02, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@...e.de> wrote:
>> Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
>>> Since we got a maintainer for fbdev, I would like to
>>> unorphan fbtft (with the idea of sending PRs to Helge)
>>> and move it out of staging since there is no more clean
>>> up work expected and no more drivers either.
>>>
>>> Thoughts?

Personally I'm in favour of this proposal and would be happy
to take patches for it through the fbdev git tree.
Reasoning below...

>> But why? We already have DRM drivers for some of these devices.
>
> No, we do not (only a few are available).

seems to be 2 out of 10 (according to the other mails)
>> Porting the others to DRM is such a better long-term plan.  OTOH,
>> as no one has shown up and converted them, maybe they should be
>> left dead or removed entirely.
>
> As I mentioned above there are devices that nobody will take time to
> port to a way too complex DRM subsystem. But the devices are cheap and
> quite widespread in the embedded world. I'm in possession of 3 or 4
> different models and only 1 is supported by tiny DRM.
>
> On top of that the subtle fact people forgot about FBTFT is that it
> does support parallel interface (yes, I know that it's not performant,
> but one of the displays I have is with that type of interface).

I don't know those devices, but it seems they are still being used.

And the reasons why they have not been ported to DRM yet is
likely because either lack of man-power, a slow-down with DRM (due to
slow bus connections or increased memory usage with DRM), or
simply that it's used in embedded-like scenarios with a limited
set of userspace applications for which existing fbdev access is sufficient.

Again, I don't know the reason for this specific devices, but I know
of other devices for which those reasons above are valid.
Just the example I posted yesterday where a simple "time dmesg" needed
unaccelerated 19 seconds compared to 2 seconds with acceleration.
So, as long as acceleration isn't possible with that driver in
DRM, DRM isn't a preferred target where the driver should be ported.

So, I'd be fine to take it into fbdev tree.

Interestingly there is another fbdev driver in staging (sm750fb) with
similiar issues. The TODO mentions a porting to DRM which happens at
https://gitlab.com/sudipm/sm750/tree/sm750
but the last commit there is 3 years ago. I don't know why it wasn't
continued yet.

> P.S. For the record, I will personally NAK any attempts to remove that
> driver from the kernel. And this is another point why it's better not
> to be under the staging.

I agree. Same as for me to NAK the disabling of fbcon's acceleration
features or even attempting to remove fbdev altogether (unless all
relevant drivers are ported to DRM).

Helge

Powered by blists - more mailing lists