| Message ID | 20220125202118.63362-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | fbtft: Unorphan the driver for maintenance | expand |
Hi 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? But why? We already have DRM drivers for some of these devices. 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. Best regards Thomas > > Andy Shevchenko (4): > fbtft: Unorphan the driver > fbtft: Move driver out from staging > fbtft: Kill outdated documentation > fbtft: Replace 'depends on FB_TFT' by 'if FB_TFT ... endif' > > MAINTAINERS | 6 ++-- > drivers/staging/Kconfig | 2 -- > drivers/staging/Makefile | 1 - > drivers/staging/fbtft/README | 32 ------------------ > drivers/staging/fbtft/TODO | 3 -- > drivers/video/Kconfig | 1 + > drivers/video/Makefile | 1 + > drivers/{staging => video}/fbtft/Kconfig | 33 +++---------------- > drivers/{staging => video}/fbtft/Makefile | 0 > .../{staging => video}/fbtft/fb_agm1264k-fl.c | 0 > .../{staging => video}/fbtft/fb_bd663474.c | 0 > .../{staging => video}/fbtft/fb_hx8340bn.c | 0 > drivers/{staging => video}/fbtft/fb_hx8347d.c | 0 > drivers/{staging => video}/fbtft/fb_hx8353d.c | 0 > drivers/{staging => video}/fbtft/fb_hx8357d.c | 0 > drivers/{staging => video}/fbtft/fb_hx8357d.h | 0 > drivers/{staging => video}/fbtft/fb_ili9163.c | 0 > drivers/{staging => video}/fbtft/fb_ili9320.c | 0 > drivers/{staging => video}/fbtft/fb_ili9325.c | 0 > drivers/{staging => video}/fbtft/fb_ili9340.c | 0 > drivers/{staging => video}/fbtft/fb_ili9341.c | 0 > drivers/{staging => video}/fbtft/fb_ili9481.c | 0 > drivers/{staging => video}/fbtft/fb_ili9486.c | 0 > drivers/{staging => video}/fbtft/fb_pcd8544.c | 0 > drivers/{staging => video}/fbtft/fb_ra8875.c | 0 > drivers/{staging => video}/fbtft/fb_s6d02a1.c | 0 > drivers/{staging => video}/fbtft/fb_s6d1121.c | 0 > drivers/{staging => video}/fbtft/fb_seps525.c | 0 > drivers/{staging => video}/fbtft/fb_sh1106.c | 0 > drivers/{staging => video}/fbtft/fb_ssd1289.c | 0 > drivers/{staging => video}/fbtft/fb_ssd1305.c | 0 > drivers/{staging => video}/fbtft/fb_ssd1306.c | 0 > drivers/{staging => video}/fbtft/fb_ssd1325.c | 0 > drivers/{staging => video}/fbtft/fb_ssd1331.c | 0 > drivers/{staging => video}/fbtft/fb_ssd1351.c | 0 > drivers/{staging => video}/fbtft/fb_st7735r.c | 0 > drivers/{staging => video}/fbtft/fb_st7789v.c | 0 > drivers/{staging => video}/fbtft/fb_tinylcd.c | 0 > drivers/{staging => video}/fbtft/fb_tls8204.c | 0 > drivers/{staging => video}/fbtft/fb_uc1611.c | 0 > drivers/{staging => video}/fbtft/fb_uc1701.c | 0 > .../{staging => video}/fbtft/fb_upd161704.c | 0 > drivers/{staging => video}/fbtft/fbtft-bus.c | 0 > drivers/{staging => video}/fbtft/fbtft-core.c | 0 > drivers/{staging => video}/fbtft/fbtft-io.c | 0 > .../{staging => video}/fbtft/fbtft-sysfs.c | 0 > drivers/{staging => video}/fbtft/fbtft.h | 0 > drivers/{staging => video}/fbtft/internal.h | 0 > 48 files changed, 10 insertions(+), 69 deletions(-) > delete mode 100644 drivers/staging/fbtft/README > delete mode 100644 drivers/staging/fbtft/TODO > rename drivers/{staging => video}/fbtft/Kconfig (89%) > rename drivers/{staging => video}/fbtft/Makefile (100%) > rename drivers/{staging => video}/fbtft/fb_agm1264k-fl.c (100%) > rename drivers/{staging => video}/fbtft/fb_bd663474.c (100%) > rename drivers/{staging => video}/fbtft/fb_hx8340bn.c (100%) > rename drivers/{staging => video}/fbtft/fb_hx8347d.c (100%) > rename drivers/{staging => video}/fbtft/fb_hx8353d.c (100%) > rename drivers/{staging => video}/fbtft/fb_hx8357d.c (100%) > rename drivers/{staging => video}/fbtft/fb_hx8357d.h (100%) > rename drivers/{staging => video}/fbtft/fb_ili9163.c (100%) > rename drivers/{staging => video}/fbtft/fb_ili9320.c (100%) > rename drivers/{staging => video}/fbtft/fb_ili9325.c (100%) > rename drivers/{staging => video}/fbtft/fb_ili9340.c (100%) > rename drivers/{staging => video}/fbtft/fb_ili9341.c (100%) > rename drivers/{staging => video}/fbtft/fb_ili9481.c (100%) > rename drivers/{staging => video}/fbtft/fb_ili9486.c (100%) > rename drivers/{staging => video}/fbtft/fb_pcd8544.c (100%) > rename drivers/{staging => video}/fbtft/fb_ra8875.c (100%) > rename drivers/{staging => video}/fbtft/fb_s6d02a1.c (100%) > rename drivers/{staging => video}/fbtft/fb_s6d1121.c (100%) > rename drivers/{staging => video}/fbtft/fb_seps525.c (100%) > rename drivers/{staging => video}/fbtft/fb_sh1106.c (100%) > rename drivers/{staging => video}/fbtft/fb_ssd1289.c (100%) > rename drivers/{staging => video}/fbtft/fb_ssd1305.c (100%) > rename drivers/{staging => video}/fbtft/fb_ssd1306.c (100%) > rename drivers/{staging => video}/fbtft/fb_ssd1325.c (100%) > rename drivers/{staging => video}/fbtft/fb_ssd1331.c (100%) > rename drivers/{staging => video}/fbtft/fb_ssd1351.c (100%) > rename drivers/{staging => video}/fbtft/fb_st7735r.c (100%) > rename drivers/{staging => video}/fbtft/fb_st7789v.c (100%) > rename drivers/{staging => video}/fbtft/fb_tinylcd.c (100%) > rename drivers/{staging => video}/fbtft/fb_tls8204.c (100%) > rename drivers/{staging => video}/fbtft/fb_uc1611.c (100%) > rename drivers/{staging => video}/fbtft/fb_uc1701.c (100%) > rename drivers/{staging => video}/fbtft/fb_upd161704.c (100%) > rename drivers/{staging => video}/fbtft/fbtft-bus.c (100%) > rename drivers/{staging => video}/fbtft/fbtft-core.c (100%) > rename drivers/{staging => video}/fbtft/fbtft-io.c (100%) > rename drivers/{staging => video}/fbtft/fbtft-sysfs.c (100%) > rename drivers/{staging => video}/fbtft/fbtft.h (100%) > rename drivers/{staging => video}/fbtft/internal.h (100%) >
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi > > 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? Thanks for sharing yours, my answers below. > But why? We already have DRM drivers for some of these devices. No, we do not (only a few are available). > 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). 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.
On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Am 25.01.22 um 21:21 schrieb Andy Shevchenko: ... > > But why? We already have DRM drivers for some of these devices. > > No, we do not (only a few are available). Sorry, I missed your word 'some'. Some == almost none from the list (I don't remember exact numbers but something like 2 out of 10 are supported by tiny DRM and see about interfaces).
On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote: > On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > Am 25.01.22 um 21:21 schrieb Andy Shevchenko: > > ... > > > > But why? We already have DRM drivers for some of these devices. > > > > No, we do not (only a few are available). > > Sorry, I missed your word 'some'. Some == almost none from the list (I > don't remember exact numbers but something like 2 out of 10 are > supported by tiny DRM and see about interfaces). Could we get an exact list? regards, dan carpenter
On Wed, Jan 26, 2022 at 11:03 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > Hi > > > > 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? > > Thanks for sharing yours, my answers below. > > > But why? We already have DRM drivers for some of these devices. > > No, we do not (only a few are available). > > > 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. If we go with "way too complex" no one should try writing good linux drivers in general, because with the bazillion of helpers, different subsystems and specific solution for pretty much any possible problem you might ever have, the linux kernel overall is "way too complex". Yes it's overwhelming and also dri-devel is a chaotic firehose, but let's try to address these issues instead of creating tiny little corners where nothing happens, but at least things are simple. Maybe Greg needs to expand his "I'll help you upstream your drivers" project to drm? We're trying to do that but sometimes it's a bit too much chaos, and also no one is actually paid in drm to do that kind of work even part time (except contracting for specific customers, but that's not the problem here I think). -Daniel > 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). > > 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. > > -- > With Best Regards, > Andy Shevchenko
On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote: > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > Hi > > > > 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? > > Thanks for sharing yours, my answers below. > > > But why? We already have DRM drivers for some of these devices. > > No, we do not (only a few are available). > > > 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. Great, then let's just move the 2 models that you do not have support for in DRM, not the whole lot. When we have real users for the drivers, we can move them out of staging, but until then, dragging all of them out does not make sense. thanks, greg k-h
On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote: > > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > > > Hi > > > > > > 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? > > > > Thanks for sharing yours, my answers below. > > > > > But why? We already have DRM drivers for some of these devices. > > > > No, we do not (only a few are available). > > > > > 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. > > Great, then let's just move the 2 models that you do not have support > for in DRM, not the whole lot. When we have real users for the drivers, > we can move them out of staging, but until then, dragging all of them > out does not make sense. Can't we create drm drivers for these 2-3 models? Like we have drivers which are below 300 lines with all the helpers taking care of everything, this shouldn't be too tricky. And if no one cares enough for that, then imo let's just keep this in staging and let it quietly&slowly pass away. At least from the people who've been active in any kind of display development the past 6+ years (which is roughly when Tomi abandoned fbdev as last active maintainer) the consensus _is_ that drm drivers are simpler, quicker to type (once you got hold of the subsystem and all its helpers at least), and adding new fbdev drivers just makes no sense at all. -Daniel
On 1/26/22 11:02, Andy Shevchenko wrote: > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.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
On Wed, Jan 26, 2022 at 11:52:16AM +0100, Daniel Vetter wrote: > On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote: > > > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > > > > > Hi > > > > > > > > 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? > > > > > > Thanks for sharing yours, my answers below. > > > > > > > But why? We already have DRM drivers for some of these devices. > > > > > > No, we do not (only a few are available). > > > > > > > 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. > > > > Great, then let's just move the 2 models that you do not have support > > for in DRM, not the whole lot. When we have real users for the drivers, > > we can move them out of staging, but until then, dragging all of them > > out does not make sense. > > Can't we create drm drivers for these 2-3 models? Like we have drivers > which are below 300 lines with all the helpers taking care of > everything, this shouldn't be too tricky. Agreed, having the hardware to test this with is the hardest part. Andy, this should be better to do in the longrun than trying to keep these other drivers "alive". thanks, greg k-h
On 1/26/22 11:59, Helge Deller wrote: > On 1/26/22 11:02, Andy Shevchenko wrote: [snip] >> 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). > But that will never happen if we keep moving the goal post. At some point new fbdev drivers should not be added anymore, otherwise the number of existing drivers that need conversion will keep growing. Best regards,
On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas <javierm@redhat.com> wrote: > > On 1/26/22 11:59, Helge Deller wrote: > > On 1/26/22 11:02, Andy Shevchenko wrote: > > [snip] > > >> 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). > > > > But that will never happen if we keep moving the goal post. > > At some point new fbdev drivers should not be added anymore, otherwise > the number of existing drivers that need conversion will keep growing. And that point was about 5 years ago, and has been discussed at some plumbers meanwhile, resulting in the staging TODO patches to make these drm drivers to destage them. Fixing bugs in fbdev is all fine, reopening it for merging new drivers is not. -Daniel
On 1/26/22 12:18, Javier Martinez Canillas wrote: > On 1/26/22 11:59, Helge Deller wrote: >> On 1/26/22 11:02, Andy Shevchenko wrote: > > [snip] > >>> 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). >> > > But that will never happen if we keep moving the goal post. > > At some point new fbdev drivers should not be added anymore, otherwise > the number of existing drivers that need conversion will keep growing. Good point, and yes you are right! I think the rule should be something like: New graphics devices (e.g. max. 3 years old from now) usually are capable to be ported to DRM. For those graphics cards we should put a hard stop and not include them as new driver into the fbdev framework. Inclusion for those will only happen as DRM driver. In the same manner there are old graphic cards or very specific devices (e.g. more than 3 years old or only used in niche-use cases) which have limitations and thus can't easily be ported to DRM. For those it's still acceptable to include them as legacy fbdev driver, because the work needed in DRM to support such cards or to be able that they run fast enough with DRM just doesn't pay off the efforts which are needed to keep them as DRM driver. Would that be acceptable? Helge
On 1/26/22 12:24, Daniel Vetter wrote: > On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas > <javierm@redhat.com> wrote: >> >> On 1/26/22 11:59, Helge Deller wrote: >>> On 1/26/22 11:02, Andy Shevchenko wrote: >> >> [snip] >> >>>> 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). >>> >> >> But that will never happen if we keep moving the goal post. >> >> At some point new fbdev drivers should not be added anymore, otherwise >> the number of existing drivers that need conversion will keep growing. > > And that point was about 5 years ago, and has been discussed at some > plumbers meanwhile, resulting in the staging TODO patches to make > these drm drivers to destage them. > > Fixing bugs in fbdev is all fine, reopening it for merging new drivers is not. We are on the same page! I'm not at all proposing to include new drivers for (relatively) new hardware into fbdev, which is capable to be written as DRM driver. Helge
On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote: > On 1/26/22 12:18, Javier Martinez Canillas wrote: > > On 1/26/22 11:59, Helge Deller wrote: > >> On 1/26/22 11:02, Andy Shevchenko wrote: > > > > [snip] > > > >>> 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). > >> > > > > But that will never happen if we keep moving the goal post. > > > > At some point new fbdev drivers should not be added anymore, otherwise > > the number of existing drivers that need conversion will keep growing. > > Good point, and yes you are right! > > I think the rule should be something like: > > New graphics devices (e.g. max. 3 years old from now) usually are > capable to be ported to DRM. > For those graphics cards we should put a hard stop and not include them > as new driver into the fbdev framework. Inclusion for those will only > happen as DRM driver. We made this rule 6 years ago already. thanks, greg k-h
Hi Am 26.01.22 um 11:59 schrieb Helge Deller: > On 1/26/22 11:02, Andy Shevchenko wrote: >> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.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) FYI it's ili9163 and hx8357d. Both of those are of the same size ('wc -l') on DRM and fbdev: 200 to 300 loc. >>> 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. It's always for the same reason: the hw is old and devs have moved on. Best regards Thomas
Helge Deller <deller@gmx.de> writes: > On 1/26/22 12:24, Daniel Vetter wrote: >> And that point was about 5 years ago, and has been discussed at some >> plumbers meanwhile, resulting in the staging TODO patches to make >> these drm drivers to destage them. >> >> Fixing bugs in fbdev is all fine, reopening it for merging new drivers is not. > > We are on the same page! > I'm not at all proposing to include new drivers for (relatively) new > hardware into fbdev, which is capable to be written as DRM driver. In my opinion that should be decided depending on the main usecase: If it's X11 or similar, it should go to DRM. If its main use case is kernel text console, it should go to fbdev. I think the main concern/trouble about fbdev is the userspace interface, and i personally would be totally fine seeing that go away (except the ability to change video mode with fbset). For me its important as kernel console for old systems, and don't want to run X11 on them. Given the ongoing discussion about performance and drm, i don't expect DRM gaining HW acceleration capabilities for text consoles. So i think both should exist, just for different usecases.
Hi Am 26.01.22 um 12:31 schrieb Helge Deller: > On 1/26/22 12:18, Javier Martinez Canillas wrote: >> On 1/26/22 11:59, Helge Deller wrote: >>> On 1/26/22 11:02, Andy Shevchenko wrote: >> >> [snip] >> >>>> 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). >>> >> >> But that will never happen if we keep moving the goal post. >> >> At some point new fbdev drivers should not be added anymore, otherwise >> the number of existing drivers that need conversion will keep growing. > > Good point, and yes you are right! > > I think the rule should be something like: > > New graphics devices (e.g. max. 3 years old from now) usually are > capable to be ported to DRM. > For those graphics cards we should put a hard stop and not include them > as new driver into the fbdev framework. Inclusion for those will only > happen as DRM driver. > > In the same manner there are old graphic cards or very specific devices > (e.g. more than 3 years old or only used in niche-use cases) > which have limitations and thus can't easily be ported to DRM. > For those it's still acceptable to include them as legacy fbdev driver, > because the work needed in DRM to support such cards or to be able that > they run fast enough with DRM just doesn't pay off the efforts which are > needed to keep them as DRM driver. > > Would that be acceptable? No. As we've said several times, there's nothing stopping any device from being supported by DRM. If something's missing or slow, it's because no one has had that issue so far. We welcome patches patches to fix such problems. Best regards Thomas > > Helge
On 1/26/22 12:38, Greg Kroah-Hartman wrote: > On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote: >> On 1/26/22 12:18, Javier Martinez Canillas wrote: >>> On 1/26/22 11:59, Helge Deller wrote: >>>> On 1/26/22 11:02, Andy Shevchenko wrote: >>> >>> [snip] >>> >>>>> 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). >>>> >>> >>> But that will never happen if we keep moving the goal post. >>> >>> At some point new fbdev drivers should not be added anymore, otherwise >>> the number of existing drivers that need conversion will keep growing. >> >> Good point, and yes you are right! >> >> I think the rule should be something like: >> >> New graphics devices (e.g. max. 3 years old from now) usually are >> capable to be ported to DRM. >> For those graphics cards we should put a hard stop and not include them >> as new driver into the fbdev framework. Inclusion for those will only >> happen as DRM driver. > > We made this rule 6 years ago already. Very good. Was there any decision how to handle drivers which can't use DRM, or for which DRM doesn't make sense? So the best way forward regarding those fbtft drivers is probably what you suggested: Split them and move those DRM-capable drivers to DRM, the others to fbdev, right? Helge
On Wed, Jan 26, 2022 at 12:51:46PM +0100, Helge Deller wrote: > On 1/26/22 12:38, Greg Kroah-Hartman wrote: > > On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote: > >> On 1/26/22 12:18, Javier Martinez Canillas wrote: > >>> On 1/26/22 11:59, Helge Deller wrote: > >>>> On 1/26/22 11:02, Andy Shevchenko wrote: > >>> > >>> [snip] > >>> > >>>>> 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). > >>>> > >>> > >>> But that will never happen if we keep moving the goal post. > >>> > >>> At some point new fbdev drivers should not be added anymore, otherwise > >>> the number of existing drivers that need conversion will keep growing. > >> > >> Good point, and yes you are right! > >> > >> I think the rule should be something like: > >> > >> New graphics devices (e.g. max. 3 years old from now) usually are > >> capable to be ported to DRM. > >> For those graphics cards we should put a hard stop and not include them > >> as new driver into the fbdev framework. Inclusion for those will only > >> happen as DRM driver. > > > > We made this rule 6 years ago already. > > Very good. > > Was there any decision how to handle drivers which can't use DRM, > or for which DRM doesn't make sense? We fix up DRM to handle such devices. > So the best way forward regarding those fbtft drivers is probably what > you suggested: Split them and move those DRM-capable drivers to DRM, > the others to fbdev, right? No, port those that work to DRM and just delete the rest as no one is using them. thanks, greg k-h
On 1/26/22 11:28, Dan Carpenter wrote: > On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote: >> On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko >> <andy.shevchenko@gmail.com> wrote: >>> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>> Am 25.01.22 um 21:21 schrieb Andy Shevchenko: >> >> ... >> >>>> But why? We already have DRM drivers for some of these devices. >>> >>> No, we do not (only a few are available). >> >> Sorry, I missed your word 'some'. Some == almost none from the list (I >> don't remember exact numbers but something like 2 out of 10 are >> supported by tiny DRM and see about interfaces). > > Could we get an exact list? > The list AFAICT is the following. I'm not familiar with these so please feel free to correct anything I got wrong here. I've marked with '?' if found references to the device supported by the fbdev driver in a DRM driver, but it's not clear if support the same HW. Drivers in drivers/staging/fbtft: fb_agm1264k-fl.c fb_bd663474.c fb_hx8340bn.c fb_hx8347d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) fb_hx8353d.c fb_hx8357d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) fb_ili9163.c (DRM driver in drivers/gpu/drm/tiny/ili9163.c) fb_ili9320.c fb_ili9325.c fb_ili9340.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) fb_ili9481.c fb_ili9486.c (DRM driver in drivers/gpu/drm/tiny/ili9486.c) fb_pcd8544.c fb_ra8875.c fb_s6d02a1.c fb_s6d1121.c fb_seps525.c fb_sh1106.c fb_ssd1289.c fb_ssd1305.c fb_ssd1306.c fb_ssd1325.c fb_ssd1331.c fb_ssd1351.c fb_st7735r.c (DRM driver in drivers/gpu/drm/tiny/st7735r.c) fb_st7789v.c (DRM driver in drivers/gpu/drm/panel/panel-sitronix-st7789v.c) fb_tinylcd.c fb_tls8204.c fb_uc1611.c fb_uc1701.c fb_upd161704.c fb_watterott.c Best regards,
On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote: > On 1/26/22 11:28, Dan Carpenter wrote: > > On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote: > >> On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko > >> <andy.shevchenko@gmail.com> wrote: > >>> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>> Am 25.01.22 um 21:21 schrieb Andy Shevchenko: > >> > >> ... > >> > >>>> But why? We already have DRM drivers for some of these devices. > >>> > >>> No, we do not (only a few are available). > >> > >> Sorry, I missed your word 'some'. Some == almost none from the list (I > >> don't remember exact numbers but something like 2 out of 10 are > >> supported by tiny DRM and see about interfaces). > > > > Could we get an exact list? > > > > The list AFAICT is the following. I'm not familiar with these so please > feel free to correct anything I got wrong here. > > I've marked with '?' if found references to the device supported by the > fbdev driver in a DRM driver, but it's not clear if support the same HW. > > Drivers in drivers/staging/fbtft: > > fb_agm1264k-fl.c > fb_bd663474.c > fb_hx8340bn.c > fb_hx8347d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) > fb_hx8353d.c > fb_hx8357d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) > fb_ili9163.c (DRM driver in drivers/gpu/drm/tiny/ili9163.c) > fb_ili9320.c > fb_ili9325.c > fb_ili9340.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) > fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) > fb_ili9481.c > fb_ili9486.c (DRM driver in drivers/gpu/drm/tiny/ili9486.c) > fb_pcd8544.c > fb_ra8875.c > fb_s6d02a1.c > fb_s6d1121.c > fb_seps525.c > fb_sh1106.c > fb_ssd1289.c > fb_ssd1305.c > fb_ssd1306.c > fb_ssd1325.c > fb_ssd1331.c > fb_ssd1351.c > fb_st7735r.c (DRM driver in drivers/gpu/drm/tiny/st7735r.c) > fb_st7789v.c (DRM driver in drivers/gpu/drm/panel/panel-sitronix-st7789v.c) I'll gladly take a patch that deletes the fb_* files that are already handled by a DRM driver like you list here. thanks, greg k-h
> > 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? Here's a driver I have been working on: drm/panel: Add MIPI DBI compatible SPI driver https://lore.kernel.org/dri-devel/20220125175700.37408-1-noralf@tronnes.org/ It should replace the SPI part of these fbtft drivers if accepted: $ grep -lr MIPI_DCS drivers/staging/fbtft/ | grep -v "-" | uniq | sort drivers/staging/fbtft/fb_hx8340bn.c drivers/staging/fbtft/fb_hx8353d.c drivers/staging/fbtft/fb_hx8357d.c drivers/staging/fbtft/fb_ili9163.c drivers/staging/fbtft/fb_ili9340.c drivers/staging/fbtft/fb_ili9341.c drivers/staging/fbtft/fb_ili9481.c drivers/staging/fbtft/fb_ili9486.c drivers/staging/fbtft/fb_s6d02a1.c drivers/staging/fbtft/fb_st7735r.c drivers/staging/fbtft/fb_st7789v.c drivers/staging/fbtft/fb_tinylcd.c There's no support for the parallel interface on these controllers in drm. Support could be added to drivers/gpu/drm/drm_mipi_dbi.c. Here's a status report I wrote 2 years ago: fbtft: 5 years in staging https://lore.kernel.org/dri-devel/a6cef26c-0f4b-47f0-d249-71f53891526b@tronnes.org/ Noralf.
On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote: > On 1/26/22 11:28, Dan Carpenter wrote: > > On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote: > >> On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko > >> <andy.shevchenko@gmail.com> wrote: > >>> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>> Am 25.01.22 um 21:21 schrieb Andy Shevchenko: > >> > >> ... > >> > >>>> But why? We already have DRM drivers for some of these devices. > >>> > >>> No, we do not (only a few are available). > >> > >> Sorry, I missed your word 'some'. Some == almost none from the list (I > >> don't remember exact numbers but something like 2 out of 10 are > >> supported by tiny DRM and see about interfaces). > > > > Could we get an exact list? > > > > The list AFAICT is the following. I'm not familiar with these so please > feel free to correct anything I got wrong here. > > I've marked with '?' if found references to the device supported by the > fbdev driver in a DRM driver, but it's not clear if support the same HW. > > Drivers in drivers/staging/fbtft: Thanks! Note, there is no support for the devices with parallel interface in the DRM. So, basically we can't kill even a single one from fbtft if there is a user for it. > fb_agm1264k-fl.c > fb_bd663474.c > fb_hx8340bn.c > fb_hx8347d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) > fb_hx8353d.c > fb_hx8357d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) > fb_ili9163.c (DRM driver in drivers/gpu/drm/tiny/ili9163.c) > fb_ili9320.c > fb_ili9325.c > fb_ili9340.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) Not sure. > fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) Yes and for the fact there are two drivers for the same chip in the DRM. Overall there are three different drivers for Ilitek 9341. > fb_ili9481.c > fb_ili9486.c (DRM driver in drivers/gpu/drm/tiny/ili9486.c) > fb_pcd8544.c > fb_ra8875.c > fb_s6d02a1.c > fb_s6d1121.c > fb_seps525.c > fb_sh1106.c > fb_ssd1289.c > fb_ssd1305.c > fb_ssd1306.c > fb_ssd1325.c > fb_ssd1331.c > fb_ssd1351.c > fb_st7735r.c (DRM driver in drivers/gpu/drm/tiny/st7735r.c) > fb_st7789v.c (DRM driver in drivers/gpu/drm/panel/panel-sitronix-st7789v.c) > fb_tinylcd.c > fb_tls8204.c > fb_uc1611.c > fb_uc1701.c > fb_upd161704.c > fb_watterott.c
On Wed, Jan 26, 2022 at 01:56:11PM +0100, Greg Kroah-Hartman wrote: > On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote: > > On 1/26/22 11:28, Dan Carpenter wrote: ... > > fb_hx8347d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) > > fb_hx8357d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) > > fb_ili9163.c (DRM driver in drivers/gpu/drm/tiny/ili9163.c) > > fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) > > fb_ili9486.c (DRM driver in drivers/gpu/drm/tiny/ili9486.c) > > fb_st7735r.c (DRM driver in drivers/gpu/drm/tiny/st7735r.c) > > fb_st7789v.c (DRM driver in drivers/gpu/drm/panel/panel-sitronix-st7789v.c) > > I'll gladly take a patch that deletes the fb_* files that are already > handled by a DRM driver like you list here. None of the DRM driver supports parallel interface for these devices.
On 1/26/22 13:56, Greg Kroah-Hartman wrote: [snip] >> fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) This was a copy and paste error. It should had been: (DRM driver in drivers/gpu/drm/tiny/ili9341.c) >> fb_ili9481.c >> fb_ili9486.c (DRM driver in drivers/gpu/drm/tiny/ili9486.c) >> fb_pcd8544.c >> fb_ra8875.c >> fb_s6d02a1.c >> fb_s6d1121.c >> fb_seps525.c >> fb_sh1106.c >> fb_ssd1289.c >> fb_ssd1305.c >> fb_ssd1306.c >> fb_ssd1325.c >> fb_ssd1331.c >> fb_ssd1351.c >> fb_st7735r.c (DRM driver in drivers/gpu/drm/tiny/st7735r.c) >> fb_st7789v.c (DRM driver in drivers/gpu/drm/panel/panel-sitronix-st7789v.c) > > I'll gladly take a patch that deletes the fb_* files that are already > handled by a DRM driver like you list here. > Sure, I'll post a patch later today. If there's something missing in the DRM driver, anyone can get the needed bits from the git history. Best regards,
On Wed, Jan 26, 2022 at 02:15:29PM +0100, Noralf Trønnes wrote: > > > > 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? > > Here's a driver I have been working on: > > drm/panel: Add MIPI DBI compatible SPI driver > https://lore.kernel.org/dri-devel/20220125175700.37408-1-noralf@tronnes.org/ > > It should replace the SPI part of these fbtft drivers if accepted: This is good news, but... > $ grep -lr MIPI_DCS drivers/staging/fbtft/ | grep -v "-" | uniq | sort Hint: git grep -lw MIPI_DCS -- drivers/staging/fbtft > drivers/staging/fbtft/fb_hx8340bn.c > drivers/staging/fbtft/fb_hx8353d.c > drivers/staging/fbtft/fb_hx8357d.c > drivers/staging/fbtft/fb_ili9163.c > drivers/staging/fbtft/fb_ili9340.c > drivers/staging/fbtft/fb_ili9341.c > drivers/staging/fbtft/fb_ili9481.c > drivers/staging/fbtft/fb_ili9486.c > drivers/staging/fbtft/fb_s6d02a1.c > drivers/staging/fbtft/fb_st7735r.c > drivers/staging/fbtft/fb_st7789v.c > drivers/staging/fbtft/fb_tinylcd.c > > There's no support for the parallel interface on these controllers in > drm. Support could be added to drivers/gpu/drm/drm_mipi_dbi.c. ...as I said and you confirmed that parallel interface support is missing. > Here's a status report I wrote 2 years ago: > > fbtft: 5 years in staging > https://lore.kernel.org/dri-devel/a6cef26c-0f4b-47f0-d249-71f53891526b@tronnes.org/ Thanks for sharing!
On Wed, Jan 26, 2022 at 11:52:16AM +0100, Daniel Vetter wrote: > On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote: > > > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.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? > > > > > > Thanks for sharing yours, my answers below. > > > > > > > But why? We already have DRM drivers for some of these devices. > > > > > > No, we do not (only a few are available). > > > > > > > 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. > > > > Great, then let's just move the 2 models that you do not have support > > for in DRM, not the whole lot. When we have real users for the drivers, > > we can move them out of staging, but until then, dragging all of them > > out does not make sense. > > Can't we create drm drivers for these 2-3 models? Like we have drivers > which are below 300 lines with all the helpers taking care of > everything, this shouldn't be too tricky. For a few years there is no news about it. Okay, in this thread Noralf revealed a new idea to replace pile of the drivers in FBTFT. > And if no one cares enough for that, then imo let's just keep this in > staging and let it quietly&slowly pass away. At least from the people > who've been active in any kind of display development the past 6+ > years (which is roughly when Tomi abandoned fbdev as last active > maintainer) the consensus _is_ that drm drivers are simpler, quicker > to type (once you got hold of the subsystem and all its helpers at > least), and adding new fbdev drivers just makes no sense at all.
On Wed, Jan 26, 2022 at 12:15:48PM +0100, Greg Kroah-Hartman wrote: > On Wed, Jan 26, 2022 at 11:52:16AM +0100, Daniel Vetter wrote: > > On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> wrote: > > > On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote: > > > > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.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? > > > > > > > > Thanks for sharing yours, my answers below. > > > > > > > > > But why? We already have DRM drivers for some of these devices. > > > > > > > > No, we do not (only a few are available). > > > > > > > > > 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. > > > > > > Great, then let's just move the 2 models that you do not have support > > > for in DRM, not the whole lot. When we have real users for the drivers, > > > we can move them out of staging, but until then, dragging all of them > > > out does not make sense. > > > > Can't we create drm drivers for these 2-3 models? Like we have drivers > > which are below 300 lines with all the helpers taking care of > > everything, this shouldn't be too tricky. > > Agreed, having the hardware to test this with is the hardest part. > Andy, this should be better to do in the longrun than trying to keep > these other drivers "alive". I see, I'm not objecting the place, I'm objecting blind removal, so as far as the drivers, for which there is no alternative in the tree, are in the tree (even in the staging) it's fine. Let's keep a status quo then.
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote: > On 1/26/22 11:59, Helge Deller wrote: > > On 1/26/22 11:02, Andy Shevchenko wrote: > > [snip] > > >> 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). > > > > But that will never happen if we keep moving the goal post. > > At some point new fbdev drivers should not be added anymore, otherwise > the number of existing drivers that need conversion will keep growing. This thread is not about adding a new driver.
On Wed, Jan 26, 2022 at 12:38:09PM +0100, Helge Deller wrote: > On 1/26/22 12:24, Daniel Vetter wrote: > > On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas > > <javierm@redhat.com> wrote: > >> On 1/26/22 11:59, Helge Deller wrote: > >>> On 1/26/22 11:02, Andy Shevchenko wrote: ... > >>>> 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). > >> > >> But that will never happen if we keep moving the goal post. > >> > >> At some point new fbdev drivers should not be added anymore, otherwise > >> the number of existing drivers that need conversion will keep growing. > > > > And that point was about 5 years ago, and has been discussed at some > > plumbers meanwhile, resulting in the staging TODO patches to make > > these drm drivers to destage them. > > > > Fixing bugs in fbdev is all fine, reopening it for merging new drivers is not. > > We are on the same page! > I'm not at all proposing to include new drivers for (relatively) new > hardware into fbdev, which is capable to be written as DRM driver. Agree. The point here is neither in opening it for new comers nor for expanding, the drivers in question are all in the kernel in different folder that is not suitable for them, but I gave up. I see that nobody wants maintainers to be appearing for the old _working_ code, as it was shown already by the DVB case few month ago.
On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote: > Am 26.01.22 um 11:59 schrieb Helge Deller: ... > It's always for the same reason: the hw is old and devs have moved on. It's pity to have a working system with an old hardware that no one in the kernel community gives a shit about because simply they are not in the same boat. Try to be on the people's position...
On Wed, Jan 26, 2022 at 02:19:37PM +0100, Javier Martinez Canillas wrote: > On 1/26/22 13:56, Greg Kroah-Hartman wrote: > >> fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) > > This was a copy and paste error. It should had been: > > (DRM driver in drivers/gpu/drm/tiny/ili9341.c) They both fit.
On 1/26/22 14:18, Andy Shevchenko wrote: > On Wed, Jan 26, 2022 at 01:56:11PM +0100, Greg Kroah-Hartman wrote: >> On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote: >>> On 1/26/22 11:28, Dan Carpenter wrote: > > ... > >>> fb_hx8347d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) >>> fb_hx8357d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c) >>> fb_ili9163.c (DRM driver in drivers/gpu/drm/tiny/ili9163.c) >>> fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?) >>> fb_ili9486.c (DRM driver in drivers/gpu/drm/tiny/ili9486.c) >>> fb_st7735r.c (DRM driver in drivers/gpu/drm/tiny/st7735r.c) >>> fb_st7789v.c (DRM driver in drivers/gpu/drm/panel/panel-sitronix-st7789v.c) >> >> I'll gladly take a patch that deletes the fb_* files that are already >> handled by a DRM driver like you list here. > > None of the DRM driver supports parallel interface for these devices. > Thanks for the info. Then we can't remove any of these drivers indeed. Best regards,
On 1/26/22 14:27, Andy Shevchenko wrote: > On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote: >> On 1/26/22 11:59, Helge Deller wrote: >>> On 1/26/22 11:02, Andy Shevchenko wrote: >> >> [snip] >> >>>> 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). >>> >> >> But that will never happen if we keep moving the goal post. >> >> At some point new fbdev drivers should not be added anymore, otherwise >> the number of existing drivers that need conversion will keep growing. > > This thread is not about adding a new driver. > It was about adding a new drivers to drivers/video/ (taken from staging). Best regards,
On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote: > On 1/26/22 14:27, Andy Shevchenko wrote: > > On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote: > >> On 1/26/22 11:59, Helge Deller wrote: > >>> On 1/26/22 11:02, Andy Shevchenko wrote: ... > >>>> 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). > >> > >> But that will never happen if we keep moving the goal post. > >> > >> At some point new fbdev drivers should not be added anymore, otherwise > >> the number of existing drivers that need conversion will keep growing. > > > > This thread is not about adding a new driver. > > It was about adding a new drivers to drivers/video/ (taken from staging). Does it mean gates are open to take any new fbdev drivers to the staging? If not, I do not see a point here.
On 1/26/22 15:11, Andy Shevchenko wrote: > On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote: >> On 1/26/22 14:27, Andy Shevchenko wrote: >>> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote: >>>> On 1/26/22 11:59, Helge Deller wrote: >>>>> On 1/26/22 11:02, Andy Shevchenko wrote: > > ... > >>>>>> 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). >>>> >>>> But that will never happen if we keep moving the goal post. >>>> >>>> At some point new fbdev drivers should not be added anymore, otherwise >>>> the number of existing drivers that need conversion will keep growing. >>> >>> This thread is not about adding a new driver. >> >> It was about adding a new drivers to drivers/video/ (taken from staging). > > Does it mean gates are open to take any new fbdev drivers to the staging? > If not, I do not see a point here. > Good question. I don't know really. But staging has always been more flexible in what's accepted there and that's why some distros avoid to enable CONFIG_STAGING=y in the kernel. Best regards,
On Wed, Jan 26, 2022 at 03:18:14PM +0100, Javier Martinez Canillas wrote: > On 1/26/22 15:11, Andy Shevchenko wrote: > > On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote: > >> On 1/26/22 14:27, Andy Shevchenko wrote: > >>> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote: > >>>> On 1/26/22 11:59, Helge Deller wrote: > >>>>> On 1/26/22 11:02, Andy Shevchenko wrote: > > > > ... > > > >>>>>> 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). > >>>> > >>>> But that will never happen if we keep moving the goal post. > >>>> > >>>> At some point new fbdev drivers should not be added anymore, otherwise > >>>> the number of existing drivers that need conversion will keep growing. > >>> > >>> This thread is not about adding a new driver. > >> > >> It was about adding a new drivers to drivers/video/ (taken from staging). > > > > Does it mean gates are open to take any new fbdev drivers to the staging? > > If not, I do not see a point here. > > > > Good question. I don't know really. > > But staging has always been more flexible in what's accepted there and > that's why some distros avoid to enable CONFIG_STAGING=y in the kernel. And that's why if you load a staging driver, it enables TAINT_CRAP in your runtime flags :)
The other advantage of staging is the I don't think syzbot enables it. I guess it's easier to persuade Dmitry to ignore STAGING than it was to get him to disable FBDEV. :P The memory corruption in fbdev was a real headache for everyone because the stack traces ended up all over the kernel. regards, dan carpenter
Hi Am 26.01.22 um 14:32 schrieb Andy Shevchenko: > On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote: >> Am 26.01.22 um 11:59 schrieb Helge Deller: > > ... > > >> It's always for the same reason: the hw is old and devs have moved on. > > It's pity to have a working system with an old hardware that no one in > the kernel community gives a shit about because simply they are not in > the same boat. Try to be on the people's position... Yes, I do care about old hardware. I made helpers for converting fbdev drivers to DRM. I even made the initial commits for those drivers where I could find the HW on Ebay. [1] I made sure that every single of them at least gets fbcon onto the screen. So interested devs could start immediately. Yet, no one ever showed up to convert even a single driver. As it stands, 90s PCI hardware is currently supported by DRM's simpledrm as long as the device has VESA. The performance is at least usable on AthlonXP-era computers. Now the owners of these devices at least have a chance of using modern graphics userspace. That userspace is important: graphics drivers don't live in a vacuum. There's no point in having one if it requires extra support from all other components. And there's more: * Occasionally, fbdev gets in the way of DRM. Just this week, we fixed a related bug. [2] * Fbdev's mmap semantics is the reason why it's hard to do fast in DRM. * Maintaining both stacks, DRM and fbdev, adds work to kernel, userspace and distro devs. Therefore, anything we do that keeps fbdev alive is a step backwards and a burden on the overall Linux graphics community. Please excuse my ranting, but fbdev proponents seem to be ignorant to all these points. It's apparently all about 'my console is slow'. Best regards Thomas [1] https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/fbconv-plus-drivers [2] https://lore.kernel.org/dri-devel/16f9e064-99cc-4205-d03e-ae41ed034309@redhat.com/T/#t >
On Wed, Jan 26, 2022 at 04:02:23PM +0100, Thomas Zimmermann wrote: > Am 26.01.22 um 14:32 schrieb Andy Shevchenko: > > On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote: > > > Am 26.01.22 um 11:59 schrieb Helge Deller: > > > It's always for the same reason: the hw is old and devs have moved on. > > > > It's pity to have a working system with an old hardware that no one in > > the kernel community gives a shit about because simply they are not in > > the same boat. Try to be on the people's position... > > Yes, I do care about old hardware. I made helpers for converting fbdev > drivers to DRM. I even made the initial commits for those drivers where I > could find the HW on Ebay. [1] I made sure that every single of them at > least gets fbcon onto the screen. So interested devs could start > immediately. Thanks for doing that, I at least appreciate it. > Yet, no one ever showed up to convert even a single driver. I have helper in a limited way to test / enable drivers on some platforms where it wasn't possible before (you can easily see what I have done by running `git log --oneline --author="Andy Shevchenko" -- drivers/video drivers/gpu/drm drivers/staging/fbtft`), but DRM is completely new subsystem to me if we talk about driver conversion or so.
On 1/26/22 16:02, Thomas Zimmermann wrote: > Hi > > Am 26.01.22 um 14:32 schrieb Andy Shevchenko: >> On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote: >>> Am 26.01.22 um 11:59 schrieb Helge Deller: >> >> ... >> >> >>> It's always for the same reason: the hw is old and devs have moved on. >> >> It's pity to have a working system with an old hardware that no one in >> the kernel community gives a shit about because simply they are not in >> the same boat. Try to be on the people's position... > > Yes, I do care about old hardware. Yes, I know. I saw various articles about it. > I made helpers for converting fbdev drivers to DRM. I even made the > initial commits for those drivers where I could find the HW on Ebay. [1]> [1] https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/fbconv-plus-drivers Just out of curiosity, does the tgui driver you patched there is now supported by DRM? I couldn't find it (just the tridentfb fbdev driver), so I assume it's somehow handled by simpledrm instead? > I made sure that every single of them at least gets fbcon onto the > screen. So interested devs could start immediately. Yet, no one ever > showed up to convert even a single driver. Both Geert wrote about that he was trying to convert a driver. The same is true for Sven where he came up with a prelimarary visualizefx driver... Both had issues which currently prevent that those drivers get finished. > As it stands, 90s PCI hardware is currently supported by DRM's > simpledrm as long as the device has VESA. Good. Some of the drivers in fbdev are for non-x86 architectures and don't have a VESA BIOS. Is is possible that simpledrm could (theoretically) support those too? > The performance is at least usable on AthlonXP-era computers. Now the > owners of these devices at least have a chance of using modern > graphics userspace. Yes. > That userspace is important: graphics drivers don't live in a vacuum. > There's no point in having one if it requires extra support from all > other components. And there's more: > > * Occasionally, fbdev gets in the way of DRM. Just this week, we fixed a related bug. [2] > > * Fbdev's mmap semantics is the reason why it's hard to do fast in DRM. > > * Maintaining both stacks, DRM and fbdev, adds work to kernel, userspace and distro devs. > > Therefore, anything we do that keeps fbdev alive is a step backwards and a burden on the overall Linux graphics community. That's understood and I don't disagree. The earlier drivers are converted to DRM the better. I probably don't even have any issues with dropping fbdev & drivers for the x86, ARM64, s390x & ppc64 platforms - I think many older cards aren't used either used (anymore), or your simpledrm may cover the most common cards. I think the patches we currently jointly develop to disable fbcon acceleration is exactly going into this direction. The problems I see are mostly on non-x86 architectures or corner-case usages like embedded devices or special machines. They may be oldish, but still being used. Those machines would completely loose their console without fbdev. > Please excuse my ranting, but fbdev proponents seem to be ignorant to > all these points. It's apparently all about 'my console is slow'. Your ranting is fair, but I wouldn't say I'm ignorant to your arguments. Of course performance is relevant, or would you exchange your car which today is capable to drive 100 mph with another car which only drives a maximum 10 mph? (Yes, that's around the factor of speed decrease I see). Or even worse: suddenly not being allowed/able to drive your car at all? Helge
dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > The other advantage of staging is the I don't think syzbot enables it. > I guess it's easier to persuade Dmitry to ignore STAGING than it was to > get him to disable FBDEV. :P > > The memory corruption in fbdev was a real headache for everyone because > the stack traces ended up all over the kernel. Uh Dmitry disabled all of FBDEV? That's a bit too much, since there's still a lot of distros shipping things. I don't recommend enabling neither fbdev nor fbcon and some hardening checks look for these (forgot which one). But if syzbot stops checking fbcon and fbdev stuff on top of drm drivers (where most of the problems should be gone because you can't change the resolution through the current fbdev emulation) then that essentially means fbdev really needs to be disabled in distros asap. Disabling the entire pile of hw drivers makes sense, because that's pretty hopeless imo. Adding Dmitry to confirm. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Wed, Jan 26, 2022 at 3:24 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Wed, Jan 26, 2022 at 03:18:14PM +0100, Javier Martinez Canillas wrote: > > On 1/26/22 15:11, Andy Shevchenko wrote: > > > On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote: > > >> On 1/26/22 14:27, Andy Shevchenko wrote: > > >>> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote: > > >>>> On 1/26/22 11:59, Helge Deller wrote: > > >>>>> On 1/26/22 11:02, Andy Shevchenko wrote: > > > > > > ... > > > > > >>>>>> 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). > > >>>> > > >>>> But that will never happen if we keep moving the goal post. > > >>>> > > >>>> At some point new fbdev drivers should not be added anymore, otherwise > > >>>> the number of existing drivers that need conversion will keep growing. > > >>> > > >>> This thread is not about adding a new driver. > > >> > > >> It was about adding a new drivers to drivers/video/ (taken from staging). > > > > > > Does it mean gates are open to take any new fbdev drivers to the staging? > > > If not, I do not see a point here. > > > > > > > Good question. I don't know really. > > > > But staging has always been more flexible in what's accepted there and > > that's why some distros avoid to enable CONFIG_STAGING=y in the kernel. > > And that's why if you load a staging driver, it enables TAINT_CRAP in > your runtime flags :) fwiw I'm fine with adding new fbdev drivers to staging, that really doesn't hurt anyone. Adding drm drivers to staging tends to be pain, least because if we need to do any changes to helpers there's a cross-tree cordination problem usually, and the benefit of staging hasn't in the past really outweighted that. Plus I try for us to land new drivers when they're good enough directly into drivers/gpu, and not aim for perfect. -Daniel
On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote: > dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > > The other advantage of staging is the I don't think syzbot enables it. > > I guess it's easier to persuade Dmitry to ignore STAGING than it was to > > get him to disable FBDEV. :P > > > > The memory corruption in fbdev was a real headache for everyone because > > the stack traces ended up all over the kernel. > > Uh Dmitry disabled all of FBDEV? No that's the opposite of what I meant. STAGING is disabled in syzbot and FBDEV is enabled. regards, dan carpenter
On Wed, Jan 26, 2022 at 03:30:35PM +0200, Andy Shevchenko wrote: > On Wed, Jan 26, 2022 at 12:38:09PM +0100, Helge Deller wrote: > > On 1/26/22 12:24, Daniel Vetter wrote: > > > On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas > > > <javierm@redhat.com> wrote: > > >> On 1/26/22 11:59, Helge Deller wrote: > > >>> On 1/26/22 11:02, Andy Shevchenko wrote: > > ... > > > >>>> 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). > > >> > > >> But that will never happen if we keep moving the goal post. > > >> > > >> At some point new fbdev drivers should not be added anymore, otherwise > > >> the number of existing drivers that need conversion will keep growing. > > > > > > And that point was about 5 years ago, and has been discussed at some > > > plumbers meanwhile, resulting in the staging TODO patches to make > > > these drm drivers to destage them. > > > > > > Fixing bugs in fbdev is all fine, reopening it for merging new drivers is not. > > > > We are on the same page! > > I'm not at all proposing to include new drivers for (relatively) new > > hardware into fbdev, which is capable to be written as DRM driver. > > Agree. The point here is neither in opening it for new comers nor for > expanding, the drivers in question are all in the kernel in different folder > that is not suitable for them, but I gave up. I see that nobody wants > maintainers to be appearing for the old _working_ code, as it was shown > already by the DVB case few month ago. I mean, the main reason fbtft was in staging all this time has never been about fbdev. It was about the device tree bindings that have never been documented, reviewed and agreed upon. And given its bindings, we're very far from it. That's what Noralf has been mostly working on all this time, and yeah, it takes time but we're getting there. Maxime
On Thu, 27 Jan 2022 at 07:30, Dan Carpenter <dan.carpenter@oracle.com> wrote: > > On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote: > > dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > > > > The other advantage of staging is the I don't think syzbot enables it. > > > I guess it's easier to persuade Dmitry to ignore STAGING than it was to > > > get him to disable FBDEV. :P > > > > > > The memory corruption in fbdev was a real headache for everyone because > > > the stack traces ended up all over the kernel. > > > > Uh Dmitry disabled all of FBDEV? > > No that's the opposite of what I meant. STAGING is disabled in syzbot > and FBDEV is enabled. Is there still any problem with syzbot config? syzbot configs are stored here: https://github.com/google/syzkaller/tree/master/dashboard/config/linux
On Thu, Jan 27, 2022 at 11:32:58AM +0100, Dmitry Vyukov wrote: > On Thu, 27 Jan 2022 at 07:30, Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > > On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote: > > > dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > > > > > > The other advantage of staging is the I don't think syzbot enables it. > > > > I guess it's easier to persuade Dmitry to ignore STAGING than it was to > > > > get him to disable FBDEV. :P > > > > > > > > The memory corruption in fbdev was a real headache for everyone because > > > > the stack traces ended up all over the kernel. > > > > > > Uh Dmitry disabled all of FBDEV? > > > > No that's the opposite of what I meant. STAGING is disabled in syzbot > > and FBDEV is enabled. > > Is there still any problem with syzbot config? > syzbot configs are stored here: > https://github.com/google/syzkaller/tree/master/dashboard/config/linux CONFIG_FB and CONFIG_FRAMEBUFFER_CONSOLE are set, which are the things I care about. The one exception is upstream-kcsan.config, which doesn't have fbcon enabled. Also looking through your fbdev drivers, really the only ones you want to ever enable are: CONFIG_FB_VGA16=y CONFIG_FB_VESA=y CONFIG_FB_VIRTUAL=y The following isn't enabled, but I guess if you don't have EFI doesn't make sense, otherwise you really want it: CONFIG_FB_EFI=y The below are enabled in some configs and should be ditched CONFIG_FB_SIMPLE=y (use CONFIG_DRM_SIMPLEDRM instead, at least on kernels that have it) CONFIG_FB_I740=y (you don't have this hw or I'm blown away, this last shipped 20 years ago) CONFIG_FB_UDL=y (use CONFIG_DRM_UDL instead) CONFIG_FB_UVESA=y (does modesets by calling into a userspace helper to run x86 vbios code, just don't) CONFIG_FB_SMSCUFX=y (if you really have these then someone should port this to drm asap) CONFIG_FB_CIRRUS=y (use CONFIG_DRM_CIRRUS_QEMU instead since I'm pretty sure you don't have a real cirrus pci card) Also note that the simpledrm driver will eat all the firmware fbdev drivers and unload them. So you need to run two configs to really cover both sets of drivers in all cases. Cheers, Daniel
On Thu, 27 Jan 2022 at 12:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, Jan 27, 2022 at 11:32:58AM +0100, Dmitry Vyukov wrote: > > On Thu, 27 Jan 2022 at 07:30, Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > > > > On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote: > > > > dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > > > > > > > > The other advantage of staging is the I don't think syzbot enables it. > > > > > I guess it's easier to persuade Dmitry to ignore STAGING than it was to > > > > > get him to disable FBDEV. :P > > > > > > > > > > The memory corruption in fbdev was a real headache for everyone because > > > > > the stack traces ended up all over the kernel. > > > > > > > > Uh Dmitry disabled all of FBDEV? > > > > > > No that's the opposite of what I meant. STAGING is disabled in syzbot > > > and FBDEV is enabled. > > > > Is there still any problem with syzbot config? > > syzbot configs are stored here: > > https://github.com/google/syzkaller/tree/master/dashboard/config/linux > > CONFIG_FB and CONFIG_FRAMEBUFFER_CONSOLE are set, which are the things I > care about. The one exception is upstream-kcsan.config, which doesn't have > fbcon enabled. > > Also looking through your fbdev drivers, really the only ones you want to > ever enable are: > CONFIG_FB_VGA16=y > CONFIG_FB_VESA=y > CONFIG_FB_VIRTUAL=y > > The following isn't enabled, but I guess if you don't have EFI doesn't > make sense, otherwise you really want it: > CONFIG_FB_EFI=y > > The below are enabled in some configs and should be ditched > CONFIG_FB_SIMPLE=y (use CONFIG_DRM_SIMPLEDRM instead, at least on kernels that have it) > CONFIG_FB_I740=y (you don't have this hw or I'm blown away, this last shipped 20 years ago) > CONFIG_FB_UDL=y (use CONFIG_DRM_UDL instead) > CONFIG_FB_UVESA=y (does modesets by calling into a userspace helper to run x86 vbios code, just don't) > CONFIG_FB_SMSCUFX=y (if you really have these then someone should port this to drm asap) > CONFIG_FB_CIRRUS=y (use CONFIG_DRM_CIRRUS_QEMU instead since I'm pretty sure you don't have a real cirrus pci card) > > Also note that the simpledrm driver will eat all the firmware fbdev > drivers and unload them. So you need to run two configs to really cover > both sets of drivers in all cases. Thanks! I've sent PR to update these configs as you suggest: https://github.com/google/syzkaller/pull/2993
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? Andy Shevchenko (4): fbtft: Unorphan the driver fbtft: Move driver out from staging fbtft: Kill outdated documentation fbtft: Replace 'depends on FB_TFT' by 'if FB_TFT ... endif' MAINTAINERS | 6 ++-- drivers/staging/Kconfig | 2 -- drivers/staging/Makefile | 1 - drivers/staging/fbtft/README | 32 ------------------ drivers/staging/fbtft/TODO | 3 -- drivers/video/Kconfig | 1 + drivers/video/Makefile | 1 + drivers/{staging => video}/fbtft/Kconfig | 33 +++---------------- drivers/{staging => video}/fbtft/Makefile | 0 .../{staging => video}/fbtft/fb_agm1264k-fl.c | 0 .../{staging => video}/fbtft/fb_bd663474.c | 0 .../{staging => video}/fbtft/fb_hx8340bn.c | 0 drivers/{staging => video}/fbtft/fb_hx8347d.c | 0 drivers/{staging => video}/fbtft/fb_hx8353d.c | 0 drivers/{staging => video}/fbtft/fb_hx8357d.c | 0 drivers/{staging => video}/fbtft/fb_hx8357d.h | 0 drivers/{staging => video}/fbtft/fb_ili9163.c | 0 drivers/{staging => video}/fbtft/fb_ili9320.c | 0 drivers/{staging => video}/fbtft/fb_ili9325.c | 0 drivers/{staging => video}/fbtft/fb_ili9340.c | 0 drivers/{staging => video}/fbtft/fb_ili9341.c | 0 drivers/{staging => video}/fbtft/fb_ili9481.c | 0 drivers/{staging => video}/fbtft/fb_ili9486.c | 0 drivers/{staging => video}/fbtft/fb_pcd8544.c | 0 drivers/{staging => video}/fbtft/fb_ra8875.c | 0 drivers/{staging => video}/fbtft/fb_s6d02a1.c | 0 drivers/{staging => video}/fbtft/fb_s6d1121.c | 0 drivers/{staging => video}/fbtft/fb_seps525.c | 0 drivers/{staging => video}/fbtft/fb_sh1106.c | 0 drivers/{staging => video}/fbtft/fb_ssd1289.c | 0 drivers/{staging => video}/fbtft/fb_ssd1305.c | 0 drivers/{staging => video}/fbtft/fb_ssd1306.c | 0 drivers/{staging => video}/fbtft/fb_ssd1325.c | 0 drivers/{staging => video}/fbtft/fb_ssd1331.c | 0 drivers/{staging => video}/fbtft/fb_ssd1351.c | 0 drivers/{staging => video}/fbtft/fb_st7735r.c | 0 drivers/{staging => video}/fbtft/fb_st7789v.c | 0 drivers/{staging => video}/fbtft/fb_tinylcd.c | 0 drivers/{staging => video}/fbtft/fb_tls8204.c | 0 drivers/{staging => video}/fbtft/fb_uc1611.c | 0 drivers/{staging => video}/fbtft/fb_uc1701.c | 0 .../{staging => video}/fbtft/fb_upd161704.c | 0 drivers/{staging => video}/fbtft/fbtft-bus.c | 0 drivers/{staging => video}/fbtft/fbtft-core.c | 0 drivers/{staging => video}/fbtft/fbtft-io.c | 0 .../{staging => video}/fbtft/fbtft-sysfs.c | 0 drivers/{staging => video}/fbtft/fbtft.h | 0 drivers/{staging => video}/fbtft/internal.h | 0 48 files changed, 10 insertions(+), 69 deletions(-) delete mode 100644 drivers/staging/fbtft/README delete mode 100644 drivers/staging/fbtft/TODO rename drivers/{staging => video}/fbtft/Kconfig (89%) rename drivers/{staging => video}/fbtft/Makefile (100%) rename drivers/{staging => video}/fbtft/fb_agm1264k-fl.c (100%) rename drivers/{staging => video}/fbtft/fb_bd663474.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8340bn.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8347d.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8353d.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8357d.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8357d.h (100%) rename drivers/{staging => video}/fbtft/fb_ili9163.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9320.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9325.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9340.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9341.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9481.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9486.c (100%) rename drivers/{staging => video}/fbtft/fb_pcd8544.c (100%) rename drivers/{staging => video}/fbtft/fb_ra8875.c (100%) rename drivers/{staging => video}/fbtft/fb_s6d02a1.c (100%) rename drivers/{staging => video}/fbtft/fb_s6d1121.c (100%) rename drivers/{staging => video}/fbtft/fb_seps525.c (100%) rename drivers/{staging => video}/fbtft/fb_sh1106.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1289.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1305.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1306.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1325.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1331.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1351.c (100%) rename drivers/{staging => video}/fbtft/fb_st7735r.c (100%) rename drivers/{staging => video}/fbtft/fb_st7789v.c (100%) rename drivers/{staging => video}/fbtft/fb_tinylcd.c (100%) rename drivers/{staging => video}/fbtft/fb_tls8204.c (100%) rename drivers/{staging => video}/fbtft/fb_uc1611.c (100%) rename drivers/{staging => video}/fbtft/fb_uc1701.c (100%) rename drivers/{staging => video}/fbtft/fb_upd161704.c (100%) rename drivers/{staging => video}/fbtft/fbtft-bus.c (100%) rename drivers/{staging => video}/fbtft/fbtft-core.c (100%) rename drivers/{staging => video}/fbtft/fbtft-io.c (100%) rename drivers/{staging => video}/fbtft/fbtft-sysfs.c (100%) rename drivers/{staging => video}/fbtft/fbtft.h (100%) rename drivers/{staging => video}/fbtft/internal.h (100%)