diff --git a/drivers/staging/fbtft/Kconfig b/drivers/video/fbtft/Kconfigsimilarity index 100%rename from drivers/staging/fbtft/Kconfigrename to drivers/video/fbtft/Kconfigdiff --git a/drivers/staging/fbtft/Makefile b/drivers/video/fbtft/Makefilesimilarity index 100%rename from drivers/staging/fbtft/Makefilerename to drivers/video/fbtft/Makefilediff --git a/drivers/staging/fbtft/README b/drivers/video/fbtft/READMEsimilarity index 100%rename from drivers/staging/fbtft/READMErename to drivers/video/fbtft/READMEdiff --git a/drivers/staging/fbtft/TODO b/drivers/video/fbtft/TODOsimilarity index 100%rename from drivers/staging/fbtft/TODOrename to drivers/video/fbtft/TODOdiff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/video/fbtft/fb_agm1264k-fl.csimilarity index 100%rename from drivers/staging/fbtft/fb_agm1264k-fl.crename to drivers/video/fbtft/fb_agm1264k-fl.cdiff --git a/drivers/staging/fbtft/fb_bd663474.c b/drivers/video/fbtft/fb_bd663474.csimilarity index 100%rename from drivers/staging/fbtft/fb_bd663474.crename to drivers/video/fbtft/fb_bd663474.cdiff --git a/drivers/staging/fbtft/fb_hx8340bn.c b/drivers/video/fbtft/fb_hx8340bn.csimilarity index 100%rename from drivers/staging/fbtft/fb_hx8340bn.crename to drivers/video/fbtft/fb_hx8340bn.cdiff --git a/drivers/staging/fbtft/fb_hx8347d.c b/drivers/video/fbtft/fb_hx8347d.csimilarity index 100%rename from drivers/staging/fbtft/fb_hx8347d.crename to drivers/video/fbtft/fb_hx8347d.cdiff --git a/drivers/staging/fbtft/fb_hx8353d.c b/drivers/video/fbtft/fb_hx8353d.csimilarity index 100%rename from drivers/staging/fbtft/fb_hx8353d.crename to drivers/video/fbtft/fb_hx8353d.cdiff --git a/drivers/staging/fbtft/fb_hx8357d.c b/drivers/video/fbtft/fb_hx8357d.csimilarity index 100%rename from drivers/staging/fbtft/fb_hx8357d.crename to drivers/video/fbtft/fb_hx8357d.cdiff --git a/drivers/staging/fbtft/fb_hx8357d.h b/drivers/video/fbtft/fb_hx8357d.hsimilarity index 100%rename from drivers/staging/fbtft/fb_hx8357d.hrename to drivers/video/fbtft/fb_hx8357d.hdiff --git a/drivers/staging/fbtft/fb_ili9163.c b/drivers/video/fbtft/fb_ili9163.csimilarity index 100%rename from drivers/staging/fbtft/fb_ili9163.crename to drivers/video/fbtft/fb_ili9163.cdiff --git a/drivers/staging/fbtft/fb_ili9320.c b/drivers/video/fbtft/fb_ili9320.csimilarity index 100%rename from drivers/staging/fbtft/fb_ili9320.crename to drivers/video/fbtft/fb_ili9320.cdiff --git a/drivers/staging/fbtft/fb_ili9325.c b/drivers/video/fbtft/fb_ili9325.csimilarity index 100%rename from drivers/staging/fbtft/fb_ili9325.crename to drivers/video/fbtft/fb_ili9325.cdiff --git a/drivers/staging/fbtft/fb_ili9340.c b/drivers/video/fbtft/fb_ili9340.csimilarity index 100%rename from drivers/staging/fbtft/fb_ili9340.crename to drivers/video/fbtft/fb_ili9340.cdiff --git a/drivers/staging/fbtft/fb_ili9341.c b/drivers/video/fbtft/fb_ili9341.csimilarity index 100%rename from drivers/staging/fbtft/fb_ili9341.crename to drivers/video/fbtft/fb_ili9341.cdiff --git a/drivers/staging/fbtft/fb_ili9481.c b/drivers/video/fbtft/fb_ili9481.csimilarity index 100%rename from drivers/staging/fbtft/fb_ili9481.crename to drivers/video/fbtft/fb_ili9481.cdiff --git a/drivers/staging/fbtft/fb_ili9486.c b/drivers/video/fbtft/fb_ili9486.csimilarity index 100%rename from drivers/staging/fbtft/fb_ili9486.crename to drivers/video/fbtft/fb_ili9486.cdiff --git a/drivers/staging/fbtft/fb_pcd8544.c b/drivers/video/fbtft/fb_pcd8544.csimilarity index 100%rename from drivers/staging/fbtft/fb_pcd8544.crename to drivers/video/fbtft/fb_pcd8544.cdiff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/video/fbtft/fb_ra8875.csimilarity index 100%rename from drivers/staging/fbtft/fb_ra8875.crename to drivers/video/fbtft/fb_ra8875.cdiff --git a/drivers/staging/fbtft/fb_s6d02a1.c b/drivers/video/fbtft/fb_s6d02a1.csimilarity index 100%rename from drivers/staging/fbtft/fb_s6d02a1.crename to drivers/video/fbtft/fb_s6d02a1.cdiff --git a/drivers/staging/fbtft/fb_s6d1121.c b/drivers/video/fbtft/fb_s6d1121.csimilarity index 100%rename from drivers/staging/fbtft/fb_s6d1121.crename to drivers/video/fbtft/fb_s6d1121.cdiff --git a/drivers/staging/fbtft/fb_seps525.c b/drivers/video/fbtft/fb_seps525.csimilarity index 100%rename from drivers/staging/fbtft/fb_seps525.crename to drivers/video/fbtft/fb_seps525.cdiff --git a/drivers/staging/fbtft/fb_sh1106.c b/drivers/video/fbtft/fb_sh1106.csimilarity index 100%rename from drivers/staging/fbtft/fb_sh1106.crename to drivers/video/fbtft/fb_sh1106.cdiff --git a/drivers/staging/fbtft/fb_ssd1289.c b/drivers/video/fbtft/fb_ssd1289.csimilarity index 100%rename from drivers/staging/fbtft/fb_ssd1289.crename to drivers/video/fbtft/fb_ssd1289.cdiff --git a/drivers/staging/fbtft/fb_ssd1305.c b/drivers/video/fbtft/fb_ssd1305.csimilarity index 100%rename from drivers/staging/fbtft/fb_ssd1305.crename to drivers/video/fbtft/fb_ssd1305.cdiff --git a/drivers/staging/fbtft/fb_ssd1306.c b/drivers/video/fbtft/fb_ssd1306.csimilarity index 100%rename from drivers/staging/fbtft/fb_ssd1306.crename to drivers/video/fbtft/fb_ssd1306.cdiff --git a/drivers/staging/fbtft/fb_ssd1325.c b/drivers/video/fbtft/fb_ssd1325.csimilarity index 100%rename from drivers/staging/fbtft/fb_ssd1325.crename to drivers/video/fbtft/fb_ssd1325.cdiff --git a/drivers/staging/fbtft/fb_ssd1331.c b/drivers/video/fbtft/fb_ssd1331.csimilarity index 100%rename from drivers/staging/fbtft/fb_ssd1331.crename to drivers/video/fbtft/fb_ssd1331.cdiff --git a/drivers/staging/fbtft/fb_ssd1351.c b/drivers/video/fbtft/fb_ssd1351.csimilarity index 100%rename from drivers/staging/fbtft/fb_ssd1351.crename to drivers/video/fbtft/fb_ssd1351.cdiff --git a/drivers/staging/fbtft/fb_st7735r.c b/drivers/video/fbtft/fb_st7735r.csimilarity index 100%rename from drivers/staging/fbtft/fb_st7735r.crename to drivers/video/fbtft/fb_st7735r.cdiff --git a/drivers/staging/fbtft/fb_st7789v.c b/drivers/video/fbtft/fb_st7789v.csimilarity index 100%rename from drivers/staging/fbtft/fb_st7789v.crename to drivers/video/fbtft/fb_st7789v.cdiff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/video/fbtft/fb_tinylcd.csimilarity index 100%rename from drivers/staging/fbtft/fb_tinylcd.crename to drivers/video/fbtft/fb_tinylcd.cdiff --git a/drivers/staging/fbtft/fb_tls8204.c b/drivers/video/fbtft/fb_tls8204.csimilarity index 100%rename from drivers/staging/fbtft/fb_tls8204.crename to drivers/video/fbtft/fb_tls8204.cdiff --git a/drivers/staging/fbtft/fb_uc1611.c b/drivers/video/fbtft/fb_uc1611.csimilarity index 100%rename from drivers/staging/fbtft/fb_uc1611.crename to drivers/video/fbtft/fb_uc1611.cdiff --git a/drivers/staging/fbtft/fb_uc1701.c b/drivers/video/fbtft/fb_uc1701.csimilarity index 100%rename from drivers/staging/fbtft/fb_uc1701.crename to drivers/video/fbtft/fb_uc1701.cdiff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/video/fbtft/fb_upd161704.csimilarity index 100%rename from drivers/staging/fbtft/fb_upd161704.crename to drivers/video/fbtft/fb_upd161704.cdiff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/video/fbtft/fbtft-bus.csimilarity index 100%rename from drivers/staging/fbtft/fbtft-bus.crename to drivers/video/fbtft/fbtft-bus.cdiff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/video/fbtft/fbtft-core.csimilarity index 100%rename from drivers/staging/fbtft/fbtft-core.crename to drivers/video/fbtft/fbtft-core.cdiff --git a/drivers/staging/fbtft/fbtft-io.c b/drivers/video/fbtft/fbtft-io.csimilarity index 100%rename from drivers/staging/fbtft/fbtft-io.crename to drivers/video/fbtft/fbtft-io.cdiff --git a/drivers/staging/fbtft/fbtft-sysfs.c b/drivers/video/fbtft/fbtft-sysfs.csimilarity index 100%rename from drivers/staging/fbtft/fbtft-sysfs.crename to drivers/video/fbtft/fbtft-sysfs.cdiff --git a/drivers/staging/fbtft/fbtft.h b/drivers/video/fbtft/fbtft.hsimilarity index 100%rename from drivers/staging/fbtft/fbtft.hrename to drivers/video/fbtft/fbtft.hdiff --git a/drivers/staging/fbtft/internal.h b/drivers/video/fbtft/internal.hsimilarity index 100%rename from drivers/staging/fbtft/internal.hrename to drivers/video/fbtft/internal.h
--
2.34.1
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-25 20:21:28
Replace 'depends on FB_TFT' by 'if FB_TFT ... endif'
for the sake of deduplication.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/video/fbtft/Kconfig | 33 ++++-----------------------------
1 file changed, 4 insertions(+), 29 deletions(-)
@@ -10,87 +10,75 @@ menuconfig FB_TFTselectFB_DEFERRED_IOselectFB_BACKLIGHT+ifFB_TFT+configFB_TFT_AGM1264K_FLtristate"FB driver for the AGM1264K-FL LCD display"-depends onFB_TFThelpFramebuffersupportfortheAGM1264K-FLLCDdisplay(twoSamsungKS0108compatiblechips)configFB_TFT_BD663474tristate"FB driver for the BD663474 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforBD663474configFB_TFT_HX8340BNtristate"FB driver for the HX8340BN LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforHX8340BNconfigFB_TFT_HX8347Dtristate"FB driver for the HX8347D LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforHX8347DconfigFB_TFT_HX8353Dtristate"FB driver for the HX8353D LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforHX8353DconfigFB_TFT_HX8357Dtristate"FB driver for the HX8357D LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforHX8357DconfigFB_TFT_ILI9163tristate"FB driver for the ILI9163 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforILI9163configFB_TFT_ILI9320tristate"FB driver for the ILI9320 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforILI9320configFB_TFT_ILI9325tristate"FB driver for the ILI9325 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforILI9325configFB_TFT_ILI9340tristate"FB driver for the ILI9340 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforILI9340configFB_TFT_ILI9341tristate"FB driver for the ILI9341 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforILI9341configFB_TFT_ILI9481tristate"FB driver for the ILI9481 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforILI9481configFB_TFT_ILI9486tristate"FB driver for the ILI9486 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforILI9486configFB_TFT_PCD8544tristate"FB driver for the PCD8544 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforPCD8544
@@ -108,62 +96,52 @@ config FB_TFT_S6D02A1configFB_TFT_S6D1121tristate"FB driver for the S6D1211 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforS6D1121configFB_TFT_SEPS525tristate"FB driver for the SEPS525 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforSEPS525SayYifyouhavesuchadisplaythatutilizesthiscontroller.configFB_TFT_SH1106tristate"FB driver for the SH1106 OLED Controller"-depends onFB_TFThelpFramebuffersupportforSH1106configFB_TFT_SSD1289tristate"FB driver for the SSD1289 LCD Controller"-depends onFB_TFThelpFramebuffersupportforSSD1289configFB_TFT_SSD1305tristate"FB driver for the SSD1305 OLED Controller"-depends onFB_TFThelpFramebuffersupportforSSD1305configFB_TFT_SSD1306tristate"FB driver for the SSD1306 OLED Controller"-depends onFB_TFThelpFramebuffersupportforSSD1306configFB_TFT_SSD1331tristate"FB driver for the SSD1331 LCD Controller"-depends onFB_TFThelpFramebuffersupportforSSD1331configFB_TFT_SSD1351tristate"FB driver for the SSD1351 LCD Controller"-depends onFB_TFThelpFramebuffersupportforSSD1351configFB_TFT_ST7735Rtristate"FB driver for the ST7735R LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforST7735RconfigFB_TFT_ST7789Vtristate"FB driver for the ST7789V LCD Controller"-depends onFB_TFThelpThisenablesgenericframebuffersupportfortheSitronixST7789Vdisplaycontroller.Thecontrollerisintendedforsmallcolor
@@ -173,30 +151,27 @@ config FB_TFT_ST7789VconfigFB_TFT_TINYLCDtristate"FB driver for tinylcd.com display"-depends onFB_TFThelpCustomFramebuffersupportfortinylcd.comdisplayconfigFB_TFT_TLS8204tristate"FB driver for the TLS8204 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforTLS8204configFB_TFT_UC1611tristate"FB driver for the UC1611 LCD controller"-depends onFB_TFThelpGenericFramebuffersupportforUC1611configFB_TFT_UC1701tristate"FB driver for the UC1701 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforUC1701configFB_TFT_UPD161704tristate"FB driver for the uPD161704 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforuPD161704++endif
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-25 20:21:30
The driver is in maintenance mode, i.e. no new drivers will be accepted,
and for a long time it is part of the kernel, means no need to clone any
separate sources.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/video/fbtft/README | 32 --------------------------------
drivers/video/fbtft/TODO | 3 ---
2 files changed, 35 deletions(-)
delete mode 100644 drivers/video/fbtft/README
delete mode 100644 drivers/video/fbtft/TODO
@@ -1,32 +0,0 @@- FBTFT-=========--Linux Framebuffer drivers for small TFT LCD display modules.-The module 'fbtft' makes writing drivers for some of these displays very easy.--Development is done on a Raspberry Pi running the Raspbian "wheezy" distribution.--INSTALLATION- Download kernel sources-- From Linux 3.15- cd drivers/video/fbdev/fbtft- git clone https://github.com/notro/fbtft.git-- Add to drivers/video/fbdev/Kconfig: source "drivers/video/fbdev/fbtft/Kconfig"- Add to drivers/video/fbdev/Makefile: obj-y += fbtft/-- Before Linux 3.15- cd drivers/video- git clone https://github.com/notro/fbtft.git-- Add to drivers/video/Kconfig: source "drivers/video/fbtft/Kconfig"- Add to drivers/video/Makefile: obj-y += fbtft/-- Enable driver(s) in menuconfig and build the kernel---See wiki for more information: https://github.com/notro/fbtft/wiki---Source: https://github.com/notro/fbtft/
@@ -1,3 +0,0 @@-* convert all these over to drm_simple_display_pipe and submit for inclusion- into the DRM subsystem under drivers/gpu/drm - fbdev doesn't take any new- drivers anymore.
From: Randy Dunlap <rdunlap@infradead.org> Date: 2022-01-25 20:40:44
On 1/25/22 12:21, Andy Shevchenko wrote:
quoted hunk
Replace 'depends on FB_TFT' by 'if FB_TFT ... endif'
for the sake of deduplication.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/video/fbtft/Kconfig | 33 ++++-----------------------------
1 file changed, 4 insertions(+), 29 deletions(-)
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-01-26 08:52:16
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
@@ -84,13 +84,11 @@ config FB_TFT_PCD8544configFB_TFT_RA8875tristate"FB driver for the RA8875 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforRA8875configFB_TFT_S6D02A1tristate"FB driver for the S6D02A1 LCD Controller"-depends onFB_TFThelpGenericFramebuffersupportforS6D02A1
From: Andy Shevchenko <hidden> Date: 2022-01-26 10:03:16
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
Hi
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
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.
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <hidden> Date: 2022-01-26 10:05:28
On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
[off-list ref] wrote:
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
...
quoted
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).
--
With Best Regards,
Andy Shevchenko
From: Dan Carpenter <hidden> Date: 2022-01-26 10:30:00
On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
[off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
...
quoted
quoted
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
I'm ok with the files moving if the dri developers agree with it. It's
up to them, not me.
On one hand I'm happy anytime someone volunteers to help out.
On the other hand ... why does it have to be resurrecting fbdev?
There's an entire community of people who really know graphics and
display and spent considerable amount of effort on creating useful and
documented helpers for pretty much anything you might ever want to do.
And somehow we have to go back to typing out things the hard way, with
full verbosity, for an uapi that distros are abandoning (e.g. even for
sdl the direction is to run it on top of drm with a compat layer,
afaiui fedora is completely ditching any userspace that still even
uses /dev/fb/0). And yes I know there's still some gaps in drm,
largely for display features which were really en vogue about 20 years
ago. And we're happy to add that support, if someone who still has
such hardware can put in the little bit of work needed ...
I don't get this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Daniel Vetter <hidden> Date: 2022-01-26 10:43:36
On Wed, Jan 26, 2022 at 11:03 AM Andy Shevchenko
[off-list ref] wrote:
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Hi
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
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.
quoted
But why? We already have DRM drivers for some of these devices.
No, we do not (only a few are available).
quoted
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 [off-list ref] wrote:
quoted
Hi
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
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.
quoted
But why? We already have DRM drivers for some of these devices.
No, we do not (only a few are available).
quoted
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
From: Daniel Vetter <hidden> Date: 2022-01-26 10:52:31
On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman
[off-list ref] wrote:
On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Hi
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
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.
quoted
But why? We already have DRM drivers for some of these devices.
No, we do not (only a few are available).
quoted
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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
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...
quoted
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)
quoted
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
[off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Hi
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
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.
quoted
But why? We already have DRM drivers for some of these devices.
No, we do not (only a few are available).
quoted
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
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-26 11:18:40
On 1/26/22 11:59, Helge Deller wrote:
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
I'm ok with the files moving if the dri developers agree with it. It's
up to them, not me.
On one hand I'm happy anytime someone volunteers to help out.
On the other hand ... why does it have to be resurrecting fbdev?
There's an entire community of people who really know graphics and
display and spent considerable amount of effort on creating useful and
documented helpers for pretty much anything you might ever want to do.
And somehow we have to go back to typing out things the hard way, with
full verbosity, for an uapi that distros are abandoning (e.g. even for
sdl the direction is to run it on top of drm with a compat layer,
afaiui fedora is completely ditching any userspace that still even
uses /dev/fb/0). And yes I know there's still some gaps in drm,
largely for display features which were really en vogue about 20 years
ago. And we're happy to add that support, if someone who still has
such hardware can put in the little bit of work needed ...
I don't get this.
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
Helge
From: Daniel Vetter <hidden> Date: 2022-01-26 11:24:20
On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas
[off-list ref] wrote:
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
quoted
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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
I'm ok with the files moving if the dri developers agree with it. It's
up to them, not me.
On one hand I'm happy anytime someone volunteers to help out.
On the other hand ... why does it have to be resurrecting fbdev?
There's an entire community of people who really know graphics and
display and spent considerable amount of effort on creating useful and
documented helpers for pretty much anything you might ever want to do.
And somehow we have to go back to typing out things the hard way, with
full verbosity, for an uapi that distros are abandoning (e.g. even for
sdl the direction is to run it on top of drm with a compat layer,
afaiui fedora is completely ditching any userspace that still even
uses /dev/fb/0). And yes I know there's still some gaps in drm,
largely for display features which were really en vogue about 20 years
ago. And we're happy to add that support, if someone who still has
such hardware can put in the little bit of work needed ...
I don't get this.
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
All of those should be handled by the drm layer, as Daniel keeps
pointing out. If not, then the tinydrm layer needs to be enhanced to do
so.
Anyone have a pointer to hardware I can buy that is one of these fbtft
drivers that I could do a port to drm to see just how much work is
really needed here?
thanks,
greg k-h
I'm ok with the files moving if the dri developers agree with it. It's
up to them, not me.
On one hand I'm happy anytime someone volunteers to help out.
On the other hand ... why does it have to be resurrecting fbdev?
There's an entire community of people who really know graphics and
display and spent considerable amount of effort on creating useful and
documented helpers for pretty much anything you might ever want to do.
And somehow we have to go back to typing out things the hard way, with
full verbosity, for an uapi that distros are abandoning (e.g. even for
sdl the direction is to run it on top of drm with a compat layer,
afaiui fedora is completely ditching any userspace that still even
uses /dev/fb/0). And yes I know there's still some gaps in drm,
largely for display features which were really en vogue about 20 years
ago. And we're happy to add that support, if someone who still has
such hardware can put in the little bit of work needed ...
I don't get this.
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
This patchset isn't about killing existing support.
This is about adding new drivers to a subsystem where consensus the
past 6 years or so was that it's closed for new drivers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
I'm ok with the files moving if the dri developers agree with it. It's
up to them, not me.
On one hand I'm happy anytime someone volunteers to help out.
On the other hand ... why does it have to be resurrecting fbdev?
There's an entire community of people who really know graphics and
display and spent considerable amount of effort on creating useful and
documented helpers for pretty much anything you might ever want to do.
And somehow we have to go back to typing out things the hard way, with
full verbosity, for an uapi that distros are abandoning (e.g. even for
sdl the direction is to run it on top of drm with a compat layer,
afaiui fedora is completely ditching any userspace that still even
uses /dev/fb/0). And yes I know there's still some gaps in drm,
largely for display features which were really en vogue about 20 years
ago. And we're happy to add that support, if someone who still has
such hardware can put in the little bit of work needed ...
I don't get this.
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
And none of those examples is out-ruled by DRM. In fact we do support
devices that fall in those categories.
This is last week's discussion all over again.
Best regards
Thomas
Helge
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
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 Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote:
On 1/26/22 12:18, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
quoted
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
On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
quoted
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
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-01-26 11:41:45
Hi
Am 26.01.22 um 11:59 schrieb Helge Deller:
On 1/26/22 11:02, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
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...
quoted
quoted
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.
quoted
quoted
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
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-01-26 11:51:25
Hi
Am 26.01.22 um 12:31 schrieb Helge Deller:
On 1/26/22 12:18, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
quoted
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
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote:
quoted
On 1/26/22 12:18, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
quoted
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:
quoted
On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote:
quoted
On 1/26/22 12:18, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
quoted
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
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-26 12:37:09
On 1/26/22 11:28, Dan Carpenter wrote:
On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
[off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
...
quoted
quoted
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote:
On 1/26/22 11:28, Dan Carpenter wrote:
quoted
On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
[off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
...
quoted
quoted
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
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-26 13:08:05
On Wed, Jan 26, 2022 at 11:31:45AM +0100, Daniel Vetter wrote:
On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
[off-list ref] wrote:
quoted
On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote:
...
quoted
I'm ok with the files moving if the dri developers agree with it. It's
up to them, not me.
On one hand I'm happy anytime someone volunteers to help out.
On the other hand ... why does it have to be resurrecting fbdev?
There's an entire community of people who really know graphics and
display and spent considerable amount of effort on creating useful and
documented helpers for pretty much anything you might ever want to do.
Why nobody has converted these drivers to be DRM based?
For all these years no new conversion happens except couple, which
I don't even have a hardware to see. But I have the hardware that
is supported exclusively by fbtft driver.
And somehow we have to go back to typing out things the hard way, with
full verbosity, for an uapi that distros are abandoning (e.g. even for
sdl the direction is to run it on top of drm with a compat layer,
afaiui fedora is completely ditching any userspace that still even
uses /dev/fb/0). And yes I know there's still some gaps in drm,
largely for display features which were really en vogue about 20 years
ago. And we're happy to add that support, if someone who still has
such hardware can put in the little bit of work needed ...
I don't get this.
I don't get how Fedora is related here.
It's not useful to bury the /dev/fbX out for the devices that
the use of are black-and-white output on small embedded systems.
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-26 13:08:54
On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
On 1/26/22 11:31, Daniel Vetter wrote:
quoted
On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
[off-list ref] wrote:
...
quoted
On the other hand ... why does it have to be resurrecting fbdev?
There's an entire community of people who really know graphics and
display and spent considerable amount of effort on creating useful and
documented helpers for pretty much anything you might ever want to do.
And somehow we have to go back to typing out things the hard way, with
full verbosity, for an uapi that distros are abandoning (e.g. even for
sdl the direction is to run it on top of drm with a compat layer,
afaiui fedora is completely ditching any userspace that still even
uses /dev/fb/0). And yes I know there's still some gaps in drm,
largely for display features which were really en vogue about 20 years
ago. And we're happy to add that support, if someone who still has
such hardware can put in the little bit of work needed ...
I don't get this.
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
Exactly, I am on the same side here.
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-26 13:14:45
On Wed, Jan 26, 2022 at 12:31:40PM +0100, Thomas Zimmermann wrote:
Am 26.01.22 um 12:17 schrieb Helge Deller:
...
And none of those examples is out-ruled by DRM. In fact we do support
devices that fall in those categories.
This is last week's discussion all over again.
Fine, write a driver or accept existing solution.
While there is no other solution, let's go with the existing.
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-26 13:15:16
On Wed, Jan 26, 2022 at 12:27:19PM +0100, Daniel Vetter wrote:
On Wed, Jan 26, 2022 at 12:18 PM Helge Deller [off-list ref] wrote:
quoted
On 1/26/22 11:31, Daniel Vetter wrote:
...
quoted
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
This patchset isn't about killing existing support.
This is about adding new drivers to a subsystem where consensus the
past 6 years or so was that it's closed for new drivers.
You mean fbdev?
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-26 13:15:28
On Wed, Jan 26, 2022 at 12:26:36PM +0100, Greg Kroah-Hartman wrote:
On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
quoted
On 1/26/22 11:31, Daniel Vetter wrote:
...
quoted
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
All of those should be handled by the drm layer, as Daniel keeps
pointing out. If not, then the tinydrm layer needs to be enhanced to do
so.
Anyone have a pointer to hardware I can buy that is one of these fbtft
drivers that I could do a port to drm to see just how much work is
really needed here?
I have bought myself (for other purposes, I mean not to convert the driver(s))
SSD1306 based display (SPI), SSD1331 (SPI), HX88347d (parallel).
Each of them costed less than $10 with delivery to EU (nowadays maybe a bit
more expensive). I believe it's very easy to find the links on AliExpress.
--
With Best Regards,
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?
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.
From: Andy Shevchenko <hidden> Date: 2022-01-26 13:18:42
On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote:
On 1/26/22 11:28, Dan Carpenter wrote:
quoted
On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
[off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
...
quoted
quoted
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.
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-26 13:19:46
On 1/26/22 13:56, Greg Kroah-Hartman wrote:
[snip]
quoted
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)
quoted
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-26 13:22:57
On Wed, Jan 26, 2022 at 02:15:29PM +0100, Noralf Trønnes wrote:
quoted
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?
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.
From: Daniel Stone <hidden> Date: 2022-01-26 13:23:07
Hi,
On Wed, 26 Jan 2022 at 13:08, Andy Shevchenko
[off-list ref] wrote:
It's not useful to bury the /dev/fbX out for the devices that
the use of are black-and-white output on small embedded systems.
It's not useful to decide that such systems should only be supported
by a subsystem which has been deprecated for a long time and which has
little userspace support. It's also not useful to spend time working
on that subsystem, rather than the one everyone has agreed on for the
last 15 years, is supported by userspace, is expressive, and has a
kernel subsystem which isn't a forest of CVEs and broken locking.
Cheers,
Daniel
From: Andy Shevchenko <hidden> Date: 2022-01-26 13:25:18
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
[off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
quoted
quoted
quoted
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.
quoted
But why? We already have DRM drivers for some of these devices.
No, we do not (only a few are available).
quoted
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.
From: Andy Shevchenko <hidden> Date: 2022-01-26 13:27:14
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:
quoted
On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman
[off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann [off-list ref] wrote:
quoted
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
quoted
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.
quoted
But why? We already have DRM drivers for some of these devices.
No, we do not (only a few are available).
quoted
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.
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <hidden> Date: 2022-01-26 13:28:51
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
quoted
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.
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <hidden> Date: 2022-01-26 13:31:49
On Wed, Jan 26, 2022 at 12:38:09PM +0100, Helge Deller wrote:
On 1/26/22 12:24, Daniel Vetter wrote:
quoted
On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
...
quoted
quoted
quoted
quoted
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.
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <hidden> Date: 2022-01-26 13:34:06
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...
--
With Best Regards,
Andy Shevchenko
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-26 13:46:14
On 1/26/22 14:12, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 12:26:36PM +0100, Greg Kroah-Hartman wrote:
quoted
On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
quoted
On 1/26/22 11:31, Daniel Vetter wrote:
...
quoted
quoted
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
All of those should be handled by the drm layer, as Daniel keeps
pointing out. If not, then the tinydrm layer needs to be enhanced to do
so.
Anyone have a pointer to hardware I can buy that is one of these fbtft
drivers that I could do a port to drm to see just how much work is
really needed here?
I have bought myself (for other purposes, I mean not to convert the driver(s))
SSD1306 based display (SPI), SSD1331 (SPI), HX88347d (parallel).
I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM
driver using drivers/staging/fbtft/fb_ssd1306.c as a reference.
I didn't find one with a SPI interface but we can later add a transport for
that if I succeed.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-26 13:47:41
On 1/26/22 14:27, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
quoted
quoted
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-26 14:09:46
On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
On 1/26/22 14:12, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 12:26:36PM +0100, Greg Kroah-Hartman wrote:
quoted
On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
quoted
On 1/26/22 11:31, Daniel Vetter wrote:
...
quoted
quoted
You are describing a transitioning over to DRM - which is Ok.
But on that way there is no need to ignore, deny or even kill usage scenarios
which are different compared to your usage scenarios (e.g. embedded devices,
old platforms, slow devices, slow busses, no 3D hardware features,
low-color devices, ...).
All of those should be handled by the drm layer, as Daniel keeps
pointing out. If not, then the tinydrm layer needs to be enhanced to do
so.
Anyone have a pointer to hardware I can buy that is one of these fbtft
drivers that I could do a port to drm to see just how much work is
really needed here?
I have bought myself (for other purposes, I mean not to convert the driver(s))
SSD1306 based display (SPI), SSD1331 (SPI), HX88347d (parallel).
I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM
driver using drivers/staging/fbtft/fb_ssd1306.c as a reference.
You should take ssd1307fb.c instead. And basically create a MIPI based driver
for I2C. Then we won't go same road again for other similar devices.
I didn't find one with a SPI interface but we can later add a transport for
that if I succeed.
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-01-26 14:11:45
On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 14:12, Andy Shevchenko wrote:
...
quoted
I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM
driver using drivers/staging/fbtft/fb_ssd1306.c as a reference.
You should take ssd1307fb.c instead. And basically create a MIPI based driver
for I2C. Then we won't go same road again for other similar devices.
For the record it supports your device:
static const struct i2c_device_id ssd1307fb_i2c_id[] = {
{ "ssd1305fb", 0 },
{ "ssd1306fb", 0 },
{ "ssd1307fb", 0 },
{ "ssd1309fb", 0 },
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <hidden> Date: 2022-01-26 14:12:57
On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
On 1/26/22 14:27, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
...
quoted
quoted
quoted
quoted
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.
--
With Best Regards,
Andy Shevchenko
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-26 14:15:59
On 1/26/22 15:10, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 14:12, Andy Shevchenko wrote:
...
quoted
quoted
I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM
driver using drivers/staging/fbtft/fb_ssd1306.c as a reference.
You should take ssd1307fb.c instead. And basically create a MIPI based driver
for I2C. Then we won't go same road again for other similar devices.
For the record it supports your device:
static const struct i2c_device_id ssd1307fb_i2c_id[] = {
{ "ssd1305fb", 0 },
{ "ssd1306fb", 0 },
{ "ssd1307fb", 0 },
{ "ssd1309fb", 0 },
Thanks a lot for the pointer. I was only looking at drivers/staging
and didn't check drivers/video. I'll try to convert that one then
once I get the display.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-26 14:18:21
On 1/26/22 15:11, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 14:27, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
...
quoted
quoted
quoted
quoted
quoted
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On Wed, Jan 26, 2022 at 03:18:14PM +0100, Javier Martinez Canillas wrote:
On 1/26/22 15:11, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 14:27, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
...
quoted
quoted
quoted
quoted
quoted
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 :)
From: Dan Carpenter <hidden> Date: 2022-01-26 14:46:24
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
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-01-26 15:02:28
Hi
Am 26.01.22 um 14:32 schrieb Andy Shevchenko:
On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
quoted
Am 26.01.22 um 11:59 schrieb Helge Deller:
...
quoted
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
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
From: Andy Shevchenko <hidden> Date: 2022-01-26 15:34:37
On Wed, Jan 26, 2022 at 04:02:23PM +0100, Thomas Zimmermann wrote:
Am 26.01.22 um 14:32 schrieb Andy Shevchenko:
quoted
On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
quoted
Am 26.01.22 um 11:59 schrieb Helge Deller:
quoted
quoted
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.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
quoted
Am 26.01.22 um 11:59 schrieb Helge Deller:
...
quoted
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...
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
From: Daniel Vetter <hidden> Date: 2022-01-26 22:31:17
dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter [off-list ref] 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
From: Daniel Vetter <hidden> Date: 2022-01-26 22:37:24
On Wed, Jan 26, 2022 at 3:24 PM Greg Kroah-Hartman
[off-list ref] wrote:
On Wed, Jan 26, 2022 at 03:18:14PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 15:11, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 14:27, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
...
quoted
quoted
quoted
quoted
quoted
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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Dan Carpenter <hidden> Date: 2022-01-27 06:30:45
On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote:
dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter [off-list ref] wrote:
quoted
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
From: Maxime Ripard <hidden> Date: 2022-01-27 09:18:33
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:
quoted
On 1/26/22 12:24, Daniel Vetter wrote:
quoted
On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 1/26/22 11:59, Helge Deller wrote:
quoted
On 1/26/22 11:02, Andy Shevchenko wrote:
...
quoted
quoted
quoted
quoted
quoted
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 [off-list ref] wrote:
On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote:
quoted
dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter [off-list ref] wrote:
quoted
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.
From: Daniel Vetter <hidden> Date: 2022-01-27 11:11:11
On Thu, Jan 27, 2022 at 11:32:58AM +0100, Dmitry Vyukov wrote:
On Thu, 27 Jan 2022 at 07:30, Dan Carpenter [off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote:
quoted
dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter [off-list ref] wrote:
quoted
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.
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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 27 Jan 2022 at 12:11, Daniel Vetter [off-list ref] wrote:
On Thu, Jan 27, 2022 at 11:32:58AM +0100, Dmitry Vyukov wrote:
quoted
On Thu, 27 Jan 2022 at 07:30, Dan Carpenter [off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote:
quoted
dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter [off-list ref] wrote:
quoted
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.
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.
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-31 08:29:42
On 1/26/22 15:15, Javier Martinez Canillas wrote:
On 1/26/22 15:10, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 14:12, Andy Shevchenko wrote:
...
quoted
quoted
I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM
driver using drivers/staging/fbtft/fb_ssd1306.c as a reference.
You should take ssd1307fb.c instead. And basically create a MIPI based driver
for I2C. Then we won't go same road again for other similar devices.
For the record it supports your device:
static const struct i2c_device_id ssd1307fb_i2c_id[] = {
{ "ssd1305fb", 0 },
{ "ssd1306fb", 0 },
{ "ssd1307fb", 0 },
{ "ssd1309fb", 0 },
Thanks a lot for the pointer. I was only looking at drivers/staging
and didn't check drivers/video. I'll try to convert that one then
once I get the display.
I got some time this weekend and was able to port the ssd1306 fbdev driver
to DRM [0]. I'm not that familiar with the simple display pipe helpers, so
there may be some wrong things there. But it does work and all the fbtests
from https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git pass.
There are some hacks in the driver though. For example it exposes an XRGB8888
format even thought the OLED display is monochromatic and has 1 bit per pixel.
The driver then goes and converts the XRGB8888 pixels first to grayscale and
then to reverse mono. I took that idea from the repaper driver but that gives
us the multiple copies that Geert was complaining about.
Another hack is that I am just hardcoding the {width, height}_mm, but I don't
know what DPI could be used for these panels nor how I could calculate the mm.
Best regards,
Javier
[0]:
From 5ec4b468b66022d4c48ae6bec8a68926a01a6785 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javierm@redhat.com>
Date: Sun, 30 Jan 2022 12:16:34 +0100
Subject: [RFC] drm/tiny: Add driver for Solomon SSD130X OLED displays
Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
controllers that can be programmed via an I2C interface. This is a port
of the ssd1307fb driver that already supports these devices.
A Device Tree binding is not added because the DRM driver is compatible
with the existing binding for the ssd1307fb driver.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
MAINTAINERS | 7 +
drivers/gpu/drm/tiny/Kconfig | 12 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ssd130x.c | 944 +++++++++++++++++++++++++++++++++
4 files changed, 964 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ssd130x.c
@@ -157,6 +157,18 @@ config TINYDRM_REPAPERIfMisselectedthemodulewillbecalledrepaper.+configTINYDRM_SSD130X+tristate"DRM support for Solomon SSD130X OLED displays"+depends onDRM&&OF&&I2C+selectDRM_KMS_HELPER+selectDRM_GEM_SHMEM_HELPER+selectBACKLIGHT_CLASS_DEVICE+help+DRMdriverfortheSSD1305,SSD1306,SSD1307andSSD1309Solomon+OLEDcontrollersthatcanbeprogrammedviaanI2Cinterface.++IfMisselectedthemodulewillbecalledssd130x.+configTINYDRM_ST7586tristate"DRM support for Sitronix ST7586 display panels"depends onDRM&&SPI
@@ -0,0 +1,944 @@+// SPDX-License-Identifier: GPL-2.0-only+/*+*DRMdriverforSolomonSSD130XOLEDdisplays+*+*Copyright2022RedHatInc.+*+*Basedondrivers/video/fbdev/ssd1307fb.c+*Copyright2012FreeElectrons+*+*/++#include<linux/backlight.h>+#include<linux/delay.h>+#include<linux/gpio/consumer.h>+#include<linux/i2c.h>+#include<linux/module.h>+#include<linux/property.h>+#include<linux/pwm.h>+#include<linux/regulator/consumer.h>++#include<drm/drm_atomic_helper.h>+#include<drm/drm_damage_helper.h>+#include<drm/drm_drv.h>+#include<drm/drm_fb_cma_helper.h>+#include<drm/drm_fb_helper.h>+#include<drm/drm_format_helper.h>+#include<drm/drm_gem_atomic_helper.h>+#include<drm/drm_gem_framebuffer_helper.h>+#include<drm/drm_gem_shmem_helper.h>+#include<drm/drm_managed.h>+#include<drm/drm_modes.h>+#include<drm/drm_rect.h>+#include<drm/drm_probe_helper.h>+#include<drm/drm_simple_kms_helper.h>++#define DRIVER_NAME "ssd130x"+#define DRIVER_DESC "DRM driver for Solomon SSD130X OLED displays"+#define DRIVER_DATE "20220130"+#define DRIVER_MAJOR 1+#define DRIVER_MINOR 0++#define SSD130X_DATA 0x40+#define SSD130X_COMMAND 0x80++#define SSD130X_SET_ADDRESS_MODE 0x20+#define SSD130X_SET_ADDRESS_MODE_HORIZONTAL (0x00)+#define SSD130X_SET_ADDRESS_MODE_VERTICAL (0x01)+#define SSD130X_SET_ADDRESS_MODE_PAGE (0x02)+#define SSD130X_SET_COL_RANGE 0x21+#define SSD130X_SET_PAGE_RANGE 0x22+#define SSD130X_CONTRAST 0x81+#define SSD130X_SET_LOOKUP_TABLE 0x91+#define SSD130X_CHARGE_PUMP 0x8d+#define SSD130X_SEG_REMAP_ON 0xa1+#define SSD130X_DISPLAY_OFF 0xae+#define SSD130X_SET_MULTIPLEX_RATIO 0xa8+#define SSD130X_DISPLAY_ON 0xaf+#define SSD130X_START_PAGE_ADDRESS 0xb0+#define SSD130X_SET_DISPLAY_OFFSET 0xd3+#define SSD130X_SET_CLOCK_FREQ 0xd5+#define SSD130X_SET_AREA_COLOR_MODE 0xd8+#define SSD130X_SET_PRECHARGE_PERIOD 0xd9+#define SSD130X_SET_COM_PINS_CONFIG 0xda+#define SSD130X_SET_VCOMH 0xdb++#define MAX_CONTRAST 255++structssd130x_deviceinfo{+u32default_vcomh;+u32default_dclk_div;+u32default_dclk_frq;+intneed_pwm;+intneed_chargepump;+};++structssd130x_device{+structdrm_devicedrm;+structdrm_simple_display_pipepipe;+structdrm_display_modemode;+structdrm_connectorconnector;+structi2c_client*client;++conststructssd130x_deviceinfo*device_info;++unsignedarea_color_enable:1;+unsignedcom_invdir:1;+unsignedcom_lrremap:1;+unsignedcom_seq:1;+unsignedlookup_table_set:1;+unsignedlow_power:1;+unsignedseg_remap:1;+u32com_offset;+u32contrast;+u32dclk_div;+u32dclk_frq;+u32height;+u8lookup_table[4];+u32page_offset;+u32col_offset;+u32prechargep1;+u32prechargep2;++structbacklight_device*bl_dev;+structpwm_device*pwm;+structgpio_desc*reset;+structregulator*vbat_reg;+u32vcomh;+u32width;+/* Cached address ranges */+u8col_start;+u8col_end;+u8page_start;+u8page_end;+};++structssd130x_array{+u8type;+u8data[];+};++staticinlinestructssd130x_device*drm_to_ssd130x(structdrm_device*drm)+{+returncontainer_of(drm,structssd130x_device,drm);+}++staticstructssd130x_array*ssd130x_alloc_array(u32len,u8type)+{+structssd130x_array*array;++array=kzalloc(sizeof(structssd130x_array)+len,GFP_KERNEL);+if(!array)+returnNULL;++array->type=type;++returnarray;+}++staticintssd130x_write_array(structi2c_client*client,+structssd130x_array*array,u32len)+{+intret;++len+=sizeof(structssd130x_array);++ret=i2c_master_send(client,(u8*)array,len);+if(ret!=len){+dev_err(&client->dev,"Couldn't send I2C command.\n");+returnret;+}++return0;+}++staticinlineintssd130x_write_cmd(structi2c_client*client,u8cmd)+{+structssd130x_array*array;+intret;++array=ssd130x_alloc_array(1,SSD130X_COMMAND);+if(!array)+return-ENOMEM;++array->data[0]=cmd;++ret=ssd130x_write_array(client,array,1);+kfree(array);++returnret;+}++staticintssd130x_set_col_range(structssd130x_device*ssd130x,+u8col_start,u8cols)+{+u8col_end=col_start+cols-1;+intret;++if(col_start==ssd130x->col_start&&col_end==ssd130x->col_end)+return0;++ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_COL_RANGE);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,col_start);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,col_end);+if(ret<0)+returnret;++ssd130x->col_start=col_start;+ssd130x->col_end=col_end;+return0;+}++staticintssd130x_set_page_range(structssd130x_device*ssd130x,+u8page_start,u8pages)+{+u8page_end=page_start+pages-1;+intret;++if(page_start==ssd130x->page_start&&page_end==ssd130x->page_end)+return0;++ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_PAGE_RANGE);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,page_start);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,page_end);+if(ret<0)+returnret;++ssd130x->page_start=page_start;+ssd130x->page_end=page_end;+return0;+}++staticintssd130x_update_display(structssd130x_device*ssd130x,u8*buf,+u32width,u32height)+{+structssd130x_array*array;+unsignedintline_length=DIV_ROUND_UP(width,8);+unsignedintpages=DIV_ROUND_UP(height,8);+u32array_idx=0;+intret,i,j,k;++array=ssd130x_alloc_array(width*pages,SSD130X_DATA);+if(!array)+return-ENOMEM;++/*+*Thescreenisdividedinpages,eachhavingaheightof8+*pixels,andthewidthofthescreen.Whensendingabyteof+*datatothecontroller,itgivesthe8bitsforthecurrent+*column.I.e,thefirstbytearethe8bitsofthefirst+*column,thenthe8bitsforthesecondcolumn,etc.+*+*+*Representationofthescreen,assumingitis5bits+*wide.Eachletter-numbercombinationisabitthatcontrols+*onepixel.+*+*A0A1A2A3A4+*B0B1B2B3B4+*C0C1C2C3C4+*D0D1D2D3D4+*E0E1E2E3E4+*F0F1F2F3F4+*G0G1G2G3G4+*H0H1H2H3H4+*+*Ifyouwanttoupdatethisscreen,youneedtosend5bytes:+*(1)A0B0C0D0E0F0G0H0+*(2)A1B1C1D1E1F1G1H1+*(3)A2B2C2D2E2F2G2H2+*(4)A3B3C3D3E3F3G3H3+*(5)A4B4C4D4E4F4G4H4+*/++ret=ssd130x_set_col_range(ssd130x,ssd130x->col_offset,width);+if(ret<0)+gotoout_free;++ret=ssd130x_set_page_range(ssd130x,ssd130x->page_offset/8,pages);+if(ret<0)+gotoout_free;++for(i=0;i<pages;i++){+intm=8;++/* Last page may be partial */+if(8*(i+1)>ssd130x->height)+m=ssd130x->height%8;+for(j=0;j<width;j++){+u8data=0;++for(k=0;k<m;k++){+u8byte=buf[(8*i+k)*line_length++j/8];+u8bit=(byte>>(j%8))&1;++data|=bit<<k;+}+array->data[array_idx++]=data;+}+}++ret=ssd130x_write_array(ssd130x->client,array,width*pages);++out_free:+kfree(array);+returnret;+}++staticvoidssd130x_gray8_to_mono_reversed(u8*buf,u32width,u32height)+{+u8*gray8=buf,*mono=buf;+inty,xb,i;++for(y=0;y<height;y++)+for(xb=0;xb<width/8;xb++){+u8byte=0x00;++for(i=0;i<8;i++){+intx=xb*8+i;++byte>>=1;+if(gray8[y*width+x]>>7)+byte|=BIT(7);+}+*mono++=byte;+}+}++staticintssd130x_fb_blit_rect(structdrm_framebuffer*fb,conststructdma_buf_map*map,+structdrm_rect*rect)+{+structssd130x_device*ssd130x=drm_to_ssd130x(fb->dev);+void*vmap=map->vaddr;/* TODO: Use mapping abstraction properly */+intidx,ret=0;+u8*buf=NULL;++if(!drm_dev_enter(fb->dev,&idx))+return-ENODEV;++buf=kmalloc_array(fb->width,fb->height,GFP_KERNEL);+if(!buf){+ret=-ENOMEM;+gotoout_exit;+}++drm_fb_xrgb8888_to_gray8(buf,0,vmap,fb,rect);++ssd130x_gray8_to_mono_reversed(buf,fb->width,fb->height);++ssd130x_update_display(ssd130x,buf,fb->width,fb->height);++kfree(buf);+out_exit:+drm_dev_exit(idx);++returnret;+}++staticvoidssd130x_display_pipe_enable(structdrm_simple_display_pipe*pipe,+structdrm_crtc_state*crtc_state,+structdrm_plane_state*plane_state)+{+structssd130x_device*ssd130x=drm_to_ssd130x(pipe->crtc.dev);+intidx;++if(!drm_dev_enter(pipe->crtc.dev,&idx))+return;++backlight_enable(ssd130x->bl_dev);++ssd130x_write_cmd(ssd130x->client,SSD130X_DISPLAY_ON);+}++staticvoidssd130x_display_pipe_disable(structdrm_simple_display_pipe*pipe)+{+structssd130x_device*ssd130x=drm_to_ssd130x(pipe->crtc.dev);++ssd130x_write_cmd(ssd130x->client,SSD130X_DISPLAY_OFF);++backlight_disable(ssd130x->bl_dev);+}++staticvoidssd130x_display_pipe_update(structdrm_simple_display_pipe*pipe,+structdrm_plane_state*old_plane_state)+{+structdrm_plane_state*state=pipe->plane.state;+structdrm_shadow_plane_state*shadow_plane_state=to_drm_shadow_plane_state(state);+structdrm_rectrect;++if(!pipe->crtc.state->active)+return;++if(drm_atomic_helper_damage_merged(old_plane_state,state,&rect))+ssd130x_fb_blit_rect(state->fb,&shadow_plane_state->data[0],&rect);+}++staticconststructdrm_simple_display_pipe_funcsssd130x_pipe_funcs={+.enable=ssd130x_display_pipe_enable,+.disable=ssd130x_display_pipe_disable,+.update=ssd130x_display_pipe_update,+DRM_GEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS,+};++staticintssd130x_connector_get_modes(structdrm_connector*connector)+{+structssd130x_device*ssd130x=drm_to_ssd130x(connector->dev);+structdrm_display_mode*mode;++mode=drm_mode_duplicate(connector->dev,&ssd130x->mode);+if(!mode){+DRM_ERROR("Failed to duplicate mode\n");+return0;+}++connector->display_info.width_mm=mode->width_mm;+connector->display_info.height_mm=mode->height_mm;+connector->display_info.bpc=32;++drm_mode_set_name(mode);+mode->type|=DRM_MODE_TYPE_PREFERRED;+drm_mode_probed_add(connector,mode);++return1;+}++staticconststructdrm_connector_helper_funcsssd130x_connector_helper_funcs={+.get_modes=ssd130x_connector_get_modes,+};++staticconststructdrm_connector_funcsssd130x_connector_funcs={+.reset=drm_atomic_helper_connector_reset,+.fill_modes=drm_helper_probe_single_connector_modes,+.destroy=drm_connector_cleanup,+.atomic_duplicate_state=drm_atomic_helper_connector_duplicate_state,+.atomic_destroy_state=drm_atomic_helper_connector_destroy_state,+};++staticconststructdrm_mode_config_funcsssd130x_mode_config_funcs={+.fb_create=drm_gem_fb_create_with_dirty,+.atomic_check=drm_atomic_helper_check,+.atomic_commit=drm_atomic_helper_commit,+};++staticconstuint32_tssd130x_formats[]={+DRM_FORMAT_XRGB8888,+};++DEFINE_DRM_GEM_FOPS(ssd130x_fops);++staticconststructdrm_driverssd130x_drm_driver={+DRM_GEM_SHMEM_DRIVER_OPS,+.name=DRIVER_NAME,+.desc=DRIVER_DESC,+.date=DRIVER_DATE,+.major=DRIVER_MAJOR,+.minor=DRIVER_MINOR,+.driver_features=DRIVER_ATOMIC|DRIVER_GEM|DRIVER_MODESET,+.fops=&ssd130x_fops,+};++staticintssd130x_pwm_enable(structssd130x_device*ssd130x)+{+structpwm_statepwmstate;++ssd130x->pwm=pwm_get(&ssd130x->client->dev,NULL);+if(IS_ERR(ssd130x->pwm)){+dev_err(&ssd130x->client->dev,"Could not get PWM from device tree!\n");+returnPTR_ERR(ssd130x->pwm);+}++pwm_init_state(ssd130x->pwm,&pwmstate);+pwm_set_relative_duty_cycle(&pwmstate,50,100);+pwm_apply_state(ssd130x->pwm,&pwmstate);++/* Enable the PWM */+pwm_enable(ssd130x->pwm);++dev_dbg(&ssd130x->client->dev,"Using PWM%d with a %lluns period.\n",+ssd130x->pwm->pwm,pwm_get_period(ssd130x->pwm));++return0;+}++staticintssd130x_init(structssd130x_device*ssd130x)+{+u32precharge,dclk,com_invdir,compins;+intret;++/* Set initial contrast */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_CONTRAST);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->contrast);+if(ret<0)+returnret;++/* Set segment re-map */+if(ssd130x->seg_remap){+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SEG_REMAP_ON);+if(ret<0)+returnret;+}++/* Set COM direction */+com_invdir=0xc0|ssd130x->com_invdir<<3;+ret=ssd130x_write_cmd(ssd130x->client,com_invdir);+if(ret<0)+returnret;++/* Set multiplex ratio value */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_MULTIPLEX_RATIO);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->height-1);+if(ret<0)+returnret;++/* set display offset value */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_DISPLAY_OFFSET);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->com_offset);+if(ret<0)+returnret;++/* Set clock frequency */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_CLOCK_FREQ);+if(ret<0)+returnret;++dclk=((ssd130x->dclk_div-1)&0xf)|(ssd130x->dclk_frq&0xf)<<4;+ret=ssd130x_write_cmd(ssd130x->client,dclk);+if(ret<0)+returnret;++/* Set Area Color Mode ON/OFF & Low Power Display Mode */+if(ssd130x->area_color_enable||ssd130x->low_power){+u32mode;++ret=ssd130x_write_cmd(ssd130x->client,+SSD130X_SET_AREA_COLOR_MODE);+if(ret<0)+returnret;++mode=(ssd130x->area_color_enable?0x30:0)|+(ssd130x->low_power?5:0);+ret=ssd130x_write_cmd(ssd130x->client,mode);+if(ret<0)+returnret;+}++/* Set precharge period in number of ticks from the internal clock */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_PRECHARGE_PERIOD);+if(ret<0)+returnret;++precharge=(ssd130x->prechargep1&0xf)|(ssd130x->prechargep2&0xf)<<4;+ret=ssd130x_write_cmd(ssd130x->client,precharge);+if(ret<0)+returnret;++/* Set COM pins configuration */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_COM_PINS_CONFIG);+if(ret<0)+returnret;++compins=0x02|!ssd130x->com_seq<<4|ssd130x->com_lrremap<<5;+ret=ssd130x_write_cmd(ssd130x->client,compins);+if(ret<0)+returnret;++/* Set VCOMH */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_VCOMH);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->vcomh);+if(ret<0)+returnret;++/* Turn on the DC-DC Charge Pump */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_CHARGE_PUMP);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,+BIT(4)|(ssd130x->device_info->need_chargepump?BIT(2):0));+if(ret<0)+returnret;++/* Set lookup table */+if(ssd130x->lookup_table_set){+inti;++ret=ssd130x_write_cmd(ssd130x->client,+SSD130X_SET_LOOKUP_TABLE);+if(ret<0)+returnret;++for(i=0;i<ARRAY_SIZE(ssd130x->lookup_table);++i){+u8val=ssd130x->lookup_table[i];++if(val<31||val>63)+dev_warn(&ssd130x->client->dev,+"lookup table index %d value out of range 31 <= %d <= 63\n",+i,val);+ret=ssd130x_write_cmd(ssd130x->client,val);+if(ret<0)+returnret;+}+}++/* Switch to horizontal addressing mode */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_ADDRESS_MODE);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,+SSD130X_SET_ADDRESS_MODE_HORIZONTAL);+if(ret<0)+returnret;++/* Turn on the display */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_DISPLAY_ON);+if(ret<0)+returnret;++return0;+}++staticintssd130x_update_bl(structbacklight_device*bdev)+{+structssd130x_device*ssd130x=bl_get_data(bdev);+intbrightness=bdev->props.brightness;+intret;++ssd130x->contrast=brightness;++ret=ssd130x_write_cmd(ssd130x->client,SSD130X_CONTRAST);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->contrast);+if(ret<0)+returnret;++return0;+}++staticintssd130x_get_brightness(structbacklight_device*bdev)+{+structssd130x_device*ssd130x=bl_get_data(bdev);++returnssd130x->contrast;+}++staticconststructbacklight_opsssd130xfb_bl_ops={+.update_status=ssd130x_update_bl,+.get_brightness=ssd130x_get_brightness,+};++staticvoidssd130x_reset(structssd130x_device*ssd130x)+{+/* Reset the screen */+gpiod_set_value_cansleep(ssd130x->reset,1);+udelay(4);+gpiod_set_value_cansleep(ssd130x->reset,0);+udelay(4);+}++staticvoidssd130x_parse_properties(structssd130x_device*ssd130x)+{+structdevice*dev=&ssd130x->client->dev;++if(device_property_read_u32(dev,"solomon,width",&ssd130x->width))+ssd130x->width=96;++if(device_property_read_u32(dev,"solomon,height",&ssd130x->height))+ssd130x->height=16;++if(device_property_read_u32(dev,"solomon,page-offset",&ssd130x->page_offset))+ssd130x->page_offset=1;++if(device_property_read_u32(dev,"solomon,col-offset",&ssd130x->col_offset))+ssd130x->col_offset=0;++if(device_property_read_u32(dev,"solomon,com-offset",&ssd130x->com_offset))+ssd130x->com_offset=0;++if(device_property_read_u32(dev,"solomon,prechargep1",&ssd130x->prechargep1))+ssd130x->prechargep1=2;++if(device_property_read_u32(dev,"solomon,prechargep2",&ssd130x->prechargep2))+ssd130x->prechargep2=2;++if(!device_property_read_u8_array(dev,"solomon,lookup-table",+ssd130x->lookup_table,+ARRAY_SIZE(ssd130x->lookup_table)))+ssd130x->lookup_table_set=1;++ssd130x->seg_remap=!device_property_read_bool(dev,"solomon,segment-no-remap");+ssd130x->com_seq=device_property_read_bool(dev,"solomon,com-seq");+ssd130x->com_lrremap=device_property_read_bool(dev,"solomon,com-lrremap");+ssd130x->com_invdir=device_property_read_bool(dev,"solomon,com-invdir");+ssd130x->area_color_enable=+device_property_read_bool(dev,"solomon,area-color-enable");+ssd130x->low_power=device_property_read_bool(dev,"solomon,low-power");++ssd130x->contrast=127;+ssd130x->vcomh=ssd130x->device_info->default_vcomh;++/* Setup display timing */+if(device_property_read_u32(dev,"solomon,dclk-div",&ssd130x->dclk_div))+ssd130x->dclk_div=ssd130x->device_info->default_dclk_div;+if(device_property_read_u32(dev,"solomon,dclk-frq",&ssd130x->dclk_frq))+ssd130x->dclk_frq=ssd130x->device_info->default_dclk_frq;+}++staticvoidssd130x_set_mode(structssd130x_device*ssd130x)+{+structdrm_display_mode*mode=&ssd130x->mode;+structdrm_device*drm=&ssd130x->drm;++mode->type=DRM_MODE_TYPE_DRIVER;+mode->clock=1;+mode->hdisplay=mode->htotal=ssd130x->width;+mode->hsync_start=mode->hsync_end=ssd130x->width;+mode->vdisplay=mode->vtotal=ssd130x->height;+mode->vsync_start=mode->vsync_end=ssd130x->height;+mode->width_mm=27;+mode->height_mm=27;++drm->mode_config.min_width=ssd130x->width;+drm->mode_config.max_width=ssd130x->width;+drm->mode_config.min_height=ssd130x->height;+drm->mode_config.max_height=ssd130x->height;+drm->mode_config.preferred_depth=32;+drm->mode_config.funcs=&ssd130x_mode_config_funcs;+}++staticintssd130x_probe(structi2c_client*client)+{+structdevice*dev=&client->dev;+structssd130x_device*ssd130x;+structbacklight_device*bl;+structdrm_device*drm;+charbl_name[12];+intret;++ssd130x=devm_drm_dev_alloc(dev,&ssd130x_drm_driver,+structssd130x_device,drm);+if(IS_ERR(ssd130x))+returnPTR_ERR(ssd130x);++drm=&ssd130x->drm;++ret=drmm_mode_config_init(drm);+if(ret)+returnret;++ssd130x->client=client;++ssd130x->device_info=device_get_match_data(dev);++ssd130x_parse_properties(ssd130x);++ssd130x_set_mode(ssd130x);++ssd130x->reset=devm_gpiod_get_optional(dev,"reset",GPIOD_OUT_LOW);+if(IS_ERR(ssd130x->reset)){+dev_err(dev,"failed to get reset gpio: %ld\n",+PTR_ERR(ssd130x->reset));+returnPTR_ERR(ssd130x->reset);+}++ssd130x->vbat_reg=devm_regulator_get_optional(dev,"vbat");+if(IS_ERR(ssd130x->vbat_reg)){+ret=PTR_ERR(ssd130x->vbat_reg);+if(ret==-ENODEV){+ssd130x->vbat_reg=NULL;+}else{+dev_err(dev,"failed to get VBAT regulator: %d\n",ret);+returnret;+}+}++drm_connector_helper_add(&ssd130x->connector,&ssd130x_connector_helper_funcs);+ret=drm_connector_init(drm,&ssd130x->connector,&ssd130x_connector_funcs,+DRM_MODE_CONNECTOR_Unknown);+if(ret)+returnret;++i2c_set_clientdata(client,ssd130x);++if(ssd130x->reset)+ssd130x_reset(ssd130x);++if(ssd130x->vbat_reg){+ret=regulator_enable(ssd130x->vbat_reg);+if(ret){+dev_err(dev,"failed to enable VBAT: %d\n",ret);+returnret;+}+}++ret=ssd130x_init(ssd130x);+if(ret)+gotoregulator_disable;++if(ssd130x->device_info->need_pwm){+ret=ssd130x_pwm_enable(ssd130x);+if(ret)+gotoregulator_disable;+}++snprintf(bl_name,sizeof(bl_name),"ssd130x%d",drm->primary->index);+bl=backlight_device_register(bl_name,dev,ssd130x,&ssd130xfb_bl_ops,+NULL);+if(IS_ERR(bl)){+ret=PTR_ERR(bl);+dev_err(dev,"unable to register backlight device: %d\n",ret);+gotopwm_disable;+}++bl->props.brightness=ssd130x->contrast;+bl->props.max_brightness=MAX_CONTRAST;+ssd130x->bl_dev=bl;++ret=drm_simple_display_pipe_init(drm,&ssd130x->pipe,&ssd130x_pipe_funcs,+ssd130x_formats,ARRAY_SIZE(ssd130x_formats),+NULL,&ssd130x->connector);+if(ret)+gotopwm_disable;++drm_plane_enable_fb_damage_clips(&ssd130x->pipe.plane);++drm_mode_config_reset(drm);++ret=drm_dev_register(drm,0);+if(ret)+gotobacklight_unregister;++drm_fbdev_generic_setup(drm,0);++return0;++backlight_unregister:+backlight_device_unregister(ssd130x->bl_dev);+pwm_disable:+if(ssd130x->device_info->need_pwm){+pwm_disable(ssd130x->pwm);+pwm_put(ssd130x->pwm);+}+regulator_disable:+if(ssd130x->vbat_reg)+regulator_disable(ssd130x->vbat_reg);+returnret;+}++staticintssd130x_remove(structi2c_client*client)+{+structssd130x_device*ssd130x=i2c_get_clientdata(client);++drm_dev_unplug(&ssd130x->drm);++ssd130x_write_cmd(ssd130x->client,SSD130X_DISPLAY_OFF);++backlight_device_unregister(ssd130x->bl_dev);++if(ssd130x->device_info->need_pwm){+pwm_disable(ssd130x->pwm);+pwm_put(ssd130x->pwm);+}+if(ssd130x->vbat_reg)+regulator_disable(ssd130x->vbat_reg);++return0;+}++staticvoidssd130x_shutdown(structi2c_client*client)+{+structssd130x_device*ssd130x=i2c_get_clientdata(client);++drm_atomic_helper_shutdown(&ssd130x->drm);+}++staticstructssd130x_deviceinfossd130x_ssd1305_deviceinfo={+.default_vcomh=0x34,+.default_dclk_div=1,+.default_dclk_frq=7,+};++staticstructssd130x_deviceinfossd130x_ssd1306_deviceinfo={+.default_vcomh=0x20,+.default_dclk_div=1,+.default_dclk_frq=8,+.need_chargepump=1,+};++staticstructssd130x_deviceinfossd130x_ssd1307_deviceinfo={+.default_vcomh=0x20,+.default_dclk_div=2,+.default_dclk_frq=12,+.need_pwm=1,+};++staticstructssd130x_deviceinfossd130x_ssd1309_deviceinfo={+.default_vcomh=0x34,+.default_dclk_div=1,+.default_dclk_frq=10,+};++staticconststructof_device_idssd130x_of_match[]={+{+.compatible="solomon,ssd1305fb-i2c",+.data=(void*)&ssd130x_ssd1305_deviceinfo,+},+{+.compatible="solomon,ssd1306fb-i2c",+.data=(void*)&ssd130x_ssd1306_deviceinfo,+},+{+.compatible="solomon,ssd1307fb-i2c",+.data=(void*)&ssd130x_ssd1307_deviceinfo,+},+{+.compatible="solomon,ssd1309fb-i2c",+.data=(void*)&ssd130x_ssd1309_deviceinfo,+},+{},+};+MODULE_DEVICE_TABLE(of,ssd130x_of_match);+++staticstructi2c_driverssd130x_i2c_driver={+.driver={+.name=DRIVER_NAME,+.of_match_table=ssd130x_of_match,+},+.probe_new=ssd130x_probe,+.remove=ssd130x_remove,+.shutdown=ssd130x_shutdown,+};++module_i2c_driver(ssd130x_i2c_driver);++MODULE_DESCRIPTION(DRIVER_DESC);+MODULE_AUTHOR("Javier Martinez Canillas <javierm@redhat.com>");+MODULE_LICENSE("GPL v2");
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-01-31 09:18:08
Hi
Am 31.01.22 um 09:29 schrieb Javier Martinez Canillas:
On 1/26/22 15:15, Javier Martinez Canillas wrote:
quoted
On 1/26/22 15:10, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
quoted
On 1/26/22 14:12, Andy Shevchenko wrote:
...
quoted
quoted
I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM
driver using drivers/staging/fbtft/fb_ssd1306.c as a reference.
You should take ssd1307fb.c instead. And basically create a MIPI based driver
for I2C. Then we won't go same road again for other similar devices.
For the record it supports your device:
static const struct i2c_device_id ssd1307fb_i2c_id[] = {
{ "ssd1305fb", 0 },
{ "ssd1306fb", 0 },
{ "ssd1307fb", 0 },
{ "ssd1309fb", 0 },
Thanks a lot for the pointer. I was only looking at drivers/staging
and didn't check drivers/video. I'll try to convert that one then
once I get the display.
I got some time this weekend and was able to port the ssd1306 fbdev driver
to DRM [0]. I'm not that familiar with the simple display pipe helpers, so
there may be some wrong things there. But it does work and all the fbtests
from https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git pass.
Awesome!
There are some hacks in the driver though. For example it exposes an XRGB8888
format even thought the OLED display is monochromatic and has 1 bit per pixel.
The driver then goes and converts the XRGB8888 pixels first to grayscale and
then to reverse mono. I took that idea from the repaper driver but that gives
us the multiple copies that Geert was complaining about.
This requires to update the console code for 1-bit BW output. The fbcon
side already supports this AFAIK. DRM's fbdev needs a few more branches
and something like a DRM_FORMAT_C1 fourcc. The XRGB8888 is really a
userspace requirement that is imposed by modern desktops. If DRM's
console has been updated, you could leave it out entirely.
I could imagine that some simple userspace, such as Weston, comes with
support for palette formats and BW. Or there could be an entirely
separate program that puts graphics onto these displays.
Best regards
Thomas
quoted hunk
Another hack is that I am just hardcoding the {width, height}_mm, but I don't
know what DPI could be used for these panels nor how I could calculate the mm.
Best regards,
Javier
[0]:
From 5ec4b468b66022d4c48ae6bec8a68926a01a6785 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javierm@redhat.com>
Date: Sun, 30 Jan 2022 12:16:34 +0100
Subject: [RFC] drm/tiny: Add driver for Solomon SSD130X OLED displays
Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
controllers that can be programmed via an I2C interface. This is a port
of the ssd1307fb driver that already supports these devices.
A Device Tree binding is not added because the DRM driver is compatible
with the existing binding for the ssd1307fb driver.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
MAINTAINERS | 7 +
drivers/gpu/drm/tiny/Kconfig | 12 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ssd130x.c | 944 +++++++++++++++++++++++++++++++++
4 files changed, 964 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ssd130x.c
@@ -157,6 +157,18 @@ config TINYDRM_REPAPERIfMisselectedthemodulewillbecalledrepaper.+configTINYDRM_SSD130X+tristate"DRM support for Solomon SSD130X OLED displays"+depends onDRM&&OF&&I2C+selectDRM_KMS_HELPER+selectDRM_GEM_SHMEM_HELPER+selectBACKLIGHT_CLASS_DEVICE+help+DRMdriverfortheSSD1305,SSD1306,SSD1307andSSD1309Solomon+OLEDcontrollersthatcanbeprogrammedviaanI2Cinterface.++IfMisselectedthemodulewillbecalledssd130x.+configTINYDRM_ST7586tristate"DRM support for Sitronix ST7586 display panels"depends onDRM&&SPI
@@ -0,0 +1,944 @@+// SPDX-License-Identifier: GPL-2.0-only+/*+*DRMdriverforSolomonSSD130XOLEDdisplays+*+*Copyright2022RedHatInc.+*+*Basedondrivers/video/fbdev/ssd1307fb.c+*Copyright2012FreeElectrons+*+*/++#include<linux/backlight.h>+#include<linux/delay.h>+#include<linux/gpio/consumer.h>+#include<linux/i2c.h>+#include<linux/module.h>+#include<linux/property.h>+#include<linux/pwm.h>+#include<linux/regulator/consumer.h>++#include<drm/drm_atomic_helper.h>+#include<drm/drm_damage_helper.h>+#include<drm/drm_drv.h>+#include<drm/drm_fb_cma_helper.h>+#include<drm/drm_fb_helper.h>+#include<drm/drm_format_helper.h>+#include<drm/drm_gem_atomic_helper.h>+#include<drm/drm_gem_framebuffer_helper.h>+#include<drm/drm_gem_shmem_helper.h>+#include<drm/drm_managed.h>+#include<drm/drm_modes.h>+#include<drm/drm_rect.h>+#include<drm/drm_probe_helper.h>+#include<drm/drm_simple_kms_helper.h>++#define DRIVER_NAME "ssd130x"+#define DRIVER_DESC "DRM driver for Solomon SSD130X OLED displays"+#define DRIVER_DATE "20220130"+#define DRIVER_MAJOR 1+#define DRIVER_MINOR 0++#define SSD130X_DATA 0x40+#define SSD130X_COMMAND 0x80++#define SSD130X_SET_ADDRESS_MODE 0x20+#define SSD130X_SET_ADDRESS_MODE_HORIZONTAL (0x00)+#define SSD130X_SET_ADDRESS_MODE_VERTICAL (0x01)+#define SSD130X_SET_ADDRESS_MODE_PAGE (0x02)+#define SSD130X_SET_COL_RANGE 0x21+#define SSD130X_SET_PAGE_RANGE 0x22+#define SSD130X_CONTRAST 0x81+#define SSD130X_SET_LOOKUP_TABLE 0x91+#define SSD130X_CHARGE_PUMP 0x8d+#define SSD130X_SEG_REMAP_ON 0xa1+#define SSD130X_DISPLAY_OFF 0xae+#define SSD130X_SET_MULTIPLEX_RATIO 0xa8+#define SSD130X_DISPLAY_ON 0xaf+#define SSD130X_START_PAGE_ADDRESS 0xb0+#define SSD130X_SET_DISPLAY_OFFSET 0xd3+#define SSD130X_SET_CLOCK_FREQ 0xd5+#define SSD130X_SET_AREA_COLOR_MODE 0xd8+#define SSD130X_SET_PRECHARGE_PERIOD 0xd9+#define SSD130X_SET_COM_PINS_CONFIG 0xda+#define SSD130X_SET_VCOMH 0xdb++#define MAX_CONTRAST 255++structssd130x_deviceinfo{+u32default_vcomh;+u32default_dclk_div;+u32default_dclk_frq;+intneed_pwm;+intneed_chargepump;+};++structssd130x_device{+structdrm_devicedrm;+structdrm_simple_display_pipepipe;+structdrm_display_modemode;+structdrm_connectorconnector;+structi2c_client*client;++conststructssd130x_deviceinfo*device_info;++unsignedarea_color_enable:1;+unsignedcom_invdir:1;+unsignedcom_lrremap:1;+unsignedcom_seq:1;+unsignedlookup_table_set:1;+unsignedlow_power:1;+unsignedseg_remap:1;+u32com_offset;+u32contrast;+u32dclk_div;+u32dclk_frq;+u32height;+u8lookup_table[4];+u32page_offset;+u32col_offset;+u32prechargep1;+u32prechargep2;++structbacklight_device*bl_dev;+structpwm_device*pwm;+structgpio_desc*reset;+structregulator*vbat_reg;+u32vcomh;+u32width;+/* Cached address ranges */+u8col_start;+u8col_end;+u8page_start;+u8page_end;+};++structssd130x_array{+u8type;+u8data[];+};++staticinlinestructssd130x_device*drm_to_ssd130x(structdrm_device*drm)+{+returncontainer_of(drm,structssd130x_device,drm);+}++staticstructssd130x_array*ssd130x_alloc_array(u32len,u8type)+{+structssd130x_array*array;++array=kzalloc(sizeof(structssd130x_array)+len,GFP_KERNEL);+if(!array)+returnNULL;++array->type=type;++returnarray;+}++staticintssd130x_write_array(structi2c_client*client,+structssd130x_array*array,u32len)+{+intret;++len+=sizeof(structssd130x_array);++ret=i2c_master_send(client,(u8*)array,len);+if(ret!=len){+dev_err(&client->dev,"Couldn't send I2C command.\n");+returnret;+}++return0;+}++staticinlineintssd130x_write_cmd(structi2c_client*client,u8cmd)+{+structssd130x_array*array;+intret;++array=ssd130x_alloc_array(1,SSD130X_COMMAND);+if(!array)+return-ENOMEM;++array->data[0]=cmd;++ret=ssd130x_write_array(client,array,1);+kfree(array);++returnret;+}++staticintssd130x_set_col_range(structssd130x_device*ssd130x,+u8col_start,u8cols)+{+u8col_end=col_start+cols-1;+intret;++if(col_start==ssd130x->col_start&&col_end==ssd130x->col_end)+return0;++ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_COL_RANGE);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,col_start);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,col_end);+if(ret<0)+returnret;++ssd130x->col_start=col_start;+ssd130x->col_end=col_end;+return0;+}++staticintssd130x_set_page_range(structssd130x_device*ssd130x,+u8page_start,u8pages)+{+u8page_end=page_start+pages-1;+intret;++if(page_start==ssd130x->page_start&&page_end==ssd130x->page_end)+return0;++ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_PAGE_RANGE);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,page_start);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,page_end);+if(ret<0)+returnret;++ssd130x->page_start=page_start;+ssd130x->page_end=page_end;+return0;+}++staticintssd130x_update_display(structssd130x_device*ssd130x,u8*buf,+u32width,u32height)+{+structssd130x_array*array;+unsignedintline_length=DIV_ROUND_UP(width,8);+unsignedintpages=DIV_ROUND_UP(height,8);+u32array_idx=0;+intret,i,j,k;++array=ssd130x_alloc_array(width*pages,SSD130X_DATA);+if(!array)+return-ENOMEM;++/*+*Thescreenisdividedinpages,eachhavingaheightof8+*pixels,andthewidthofthescreen.Whensendingabyteof+*datatothecontroller,itgivesthe8bitsforthecurrent+*column.I.e,thefirstbytearethe8bitsofthefirst+*column,thenthe8bitsforthesecondcolumn,etc.+*+*+*Representationofthescreen,assumingitis5bits+*wide.Eachletter-numbercombinationisabitthatcontrols+*onepixel.+*+*A0A1A2A3A4+*B0B1B2B3B4+*C0C1C2C3C4+*D0D1D2D3D4+*E0E1E2E3E4+*F0F1F2F3F4+*G0G1G2G3G4+*H0H1H2H3H4+*+*Ifyouwanttoupdatethisscreen,youneedtosend5bytes:+*(1)A0B0C0D0E0F0G0H0+*(2)A1B1C1D1E1F1G1H1+*(3)A2B2C2D2E2F2G2H2+*(4)A3B3C3D3E3F3G3H3+*(5)A4B4C4D4E4F4G4H4+*/++ret=ssd130x_set_col_range(ssd130x,ssd130x->col_offset,width);+if(ret<0)+gotoout_free;++ret=ssd130x_set_page_range(ssd130x,ssd130x->page_offset/8,pages);+if(ret<0)+gotoout_free;++for(i=0;i<pages;i++){+intm=8;++/* Last page may be partial */+if(8*(i+1)>ssd130x->height)+m=ssd130x->height%8;+for(j=0;j<width;j++){+u8data=0;++for(k=0;k<m;k++){+u8byte=buf[(8*i+k)*line_length++j/8];+u8bit=(byte>>(j%8))&1;++data|=bit<<k;+}+array->data[array_idx++]=data;+}+}++ret=ssd130x_write_array(ssd130x->client,array,width*pages);++out_free:+kfree(array);+returnret;+}++staticvoidssd130x_gray8_to_mono_reversed(u8*buf,u32width,u32height)+{+u8*gray8=buf,*mono=buf;+inty,xb,i;++for(y=0;y<height;y++)+for(xb=0;xb<width/8;xb++){+u8byte=0x00;++for(i=0;i<8;i++){+intx=xb*8+i;++byte>>=1;+if(gray8[y*width+x]>>7)+byte|=BIT(7);+}+*mono++=byte;+}+}++staticintssd130x_fb_blit_rect(structdrm_framebuffer*fb,conststructdma_buf_map*map,+structdrm_rect*rect)+{+structssd130x_device*ssd130x=drm_to_ssd130x(fb->dev);+void*vmap=map->vaddr;/* TODO: Use mapping abstraction properly */+intidx,ret=0;+u8*buf=NULL;++if(!drm_dev_enter(fb->dev,&idx))+return-ENODEV;++buf=kmalloc_array(fb->width,fb->height,GFP_KERNEL);+if(!buf){+ret=-ENOMEM;+gotoout_exit;+}++drm_fb_xrgb8888_to_gray8(buf,0,vmap,fb,rect);++ssd130x_gray8_to_mono_reversed(buf,fb->width,fb->height);++ssd130x_update_display(ssd130x,buf,fb->width,fb->height);++kfree(buf);+out_exit:+drm_dev_exit(idx);++returnret;+}++staticvoidssd130x_display_pipe_enable(structdrm_simple_display_pipe*pipe,+structdrm_crtc_state*crtc_state,+structdrm_plane_state*plane_state)+{+structssd130x_device*ssd130x=drm_to_ssd130x(pipe->crtc.dev);+intidx;++if(!drm_dev_enter(pipe->crtc.dev,&idx))+return;++backlight_enable(ssd130x->bl_dev);++ssd130x_write_cmd(ssd130x->client,SSD130X_DISPLAY_ON);+}++staticvoidssd130x_display_pipe_disable(structdrm_simple_display_pipe*pipe)+{+structssd130x_device*ssd130x=drm_to_ssd130x(pipe->crtc.dev);++ssd130x_write_cmd(ssd130x->client,SSD130X_DISPLAY_OFF);++backlight_disable(ssd130x->bl_dev);+}++staticvoidssd130x_display_pipe_update(structdrm_simple_display_pipe*pipe,+structdrm_plane_state*old_plane_state)+{+structdrm_plane_state*state=pipe->plane.state;+structdrm_shadow_plane_state*shadow_plane_state=to_drm_shadow_plane_state(state);+structdrm_rectrect;++if(!pipe->crtc.state->active)+return;++if(drm_atomic_helper_damage_merged(old_plane_state,state,&rect))+ssd130x_fb_blit_rect(state->fb,&shadow_plane_state->data[0],&rect);+}++staticconststructdrm_simple_display_pipe_funcsssd130x_pipe_funcs={+.enable=ssd130x_display_pipe_enable,+.disable=ssd130x_display_pipe_disable,+.update=ssd130x_display_pipe_update,+DRM_GEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS,+};++staticintssd130x_connector_get_modes(structdrm_connector*connector)+{+structssd130x_device*ssd130x=drm_to_ssd130x(connector->dev);+structdrm_display_mode*mode;++mode=drm_mode_duplicate(connector->dev,&ssd130x->mode);+if(!mode){+DRM_ERROR("Failed to duplicate mode\n");+return0;+}++connector->display_info.width_mm=mode->width_mm;+connector->display_info.height_mm=mode->height_mm;+connector->display_info.bpc=32;++drm_mode_set_name(mode);+mode->type|=DRM_MODE_TYPE_PREFERRED;+drm_mode_probed_add(connector,mode);++return1;+}++staticconststructdrm_connector_helper_funcsssd130x_connector_helper_funcs={+.get_modes=ssd130x_connector_get_modes,+};++staticconststructdrm_connector_funcsssd130x_connector_funcs={+.reset=drm_atomic_helper_connector_reset,+.fill_modes=drm_helper_probe_single_connector_modes,+.destroy=drm_connector_cleanup,+.atomic_duplicate_state=drm_atomic_helper_connector_duplicate_state,+.atomic_destroy_state=drm_atomic_helper_connector_destroy_state,+};++staticconststructdrm_mode_config_funcsssd130x_mode_config_funcs={+.fb_create=drm_gem_fb_create_with_dirty,+.atomic_check=drm_atomic_helper_check,+.atomic_commit=drm_atomic_helper_commit,+};++staticconstuint32_tssd130x_formats[]={+DRM_FORMAT_XRGB8888,+};++DEFINE_DRM_GEM_FOPS(ssd130x_fops);++staticconststructdrm_driverssd130x_drm_driver={+DRM_GEM_SHMEM_DRIVER_OPS,+.name=DRIVER_NAME,+.desc=DRIVER_DESC,+.date=DRIVER_DATE,+.major=DRIVER_MAJOR,+.minor=DRIVER_MINOR,+.driver_features=DRIVER_ATOMIC|DRIVER_GEM|DRIVER_MODESET,+.fops=&ssd130x_fops,+};++staticintssd130x_pwm_enable(structssd130x_device*ssd130x)+{+structpwm_statepwmstate;++ssd130x->pwm=pwm_get(&ssd130x->client->dev,NULL);+if(IS_ERR(ssd130x->pwm)){+dev_err(&ssd130x->client->dev,"Could not get PWM from device tree!\n");+returnPTR_ERR(ssd130x->pwm);+}++pwm_init_state(ssd130x->pwm,&pwmstate);+pwm_set_relative_duty_cycle(&pwmstate,50,100);+pwm_apply_state(ssd130x->pwm,&pwmstate);++/* Enable the PWM */+pwm_enable(ssd130x->pwm);++dev_dbg(&ssd130x->client->dev,"Using PWM%d with a %lluns period.\n",+ssd130x->pwm->pwm,pwm_get_period(ssd130x->pwm));++return0;+}++staticintssd130x_init(structssd130x_device*ssd130x)+{+u32precharge,dclk,com_invdir,compins;+intret;++/* Set initial contrast */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_CONTRAST);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->contrast);+if(ret<0)+returnret;++/* Set segment re-map */+if(ssd130x->seg_remap){+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SEG_REMAP_ON);+if(ret<0)+returnret;+}++/* Set COM direction */+com_invdir=0xc0|ssd130x->com_invdir<<3;+ret=ssd130x_write_cmd(ssd130x->client,com_invdir);+if(ret<0)+returnret;++/* Set multiplex ratio value */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_MULTIPLEX_RATIO);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->height-1);+if(ret<0)+returnret;++/* set display offset value */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_DISPLAY_OFFSET);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->com_offset);+if(ret<0)+returnret;++/* Set clock frequency */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_CLOCK_FREQ);+if(ret<0)+returnret;++dclk=((ssd130x->dclk_div-1)&0xf)|(ssd130x->dclk_frq&0xf)<<4;+ret=ssd130x_write_cmd(ssd130x->client,dclk);+if(ret<0)+returnret;++/* Set Area Color Mode ON/OFF & Low Power Display Mode */+if(ssd130x->area_color_enable||ssd130x->low_power){+u32mode;++ret=ssd130x_write_cmd(ssd130x->client,+SSD130X_SET_AREA_COLOR_MODE);+if(ret<0)+returnret;++mode=(ssd130x->area_color_enable?0x30:0)|+(ssd130x->low_power?5:0);+ret=ssd130x_write_cmd(ssd130x->client,mode);+if(ret<0)+returnret;+}++/* Set precharge period in number of ticks from the internal clock */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_PRECHARGE_PERIOD);+if(ret<0)+returnret;++precharge=(ssd130x->prechargep1&0xf)|(ssd130x->prechargep2&0xf)<<4;+ret=ssd130x_write_cmd(ssd130x->client,precharge);+if(ret<0)+returnret;++/* Set COM pins configuration */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_COM_PINS_CONFIG);+if(ret<0)+returnret;++compins=0x02|!ssd130x->com_seq<<4|ssd130x->com_lrremap<<5;+ret=ssd130x_write_cmd(ssd130x->client,compins);+if(ret<0)+returnret;++/* Set VCOMH */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_VCOMH);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->vcomh);+if(ret<0)+returnret;++/* Turn on the DC-DC Charge Pump */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_CHARGE_PUMP);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,+BIT(4)|(ssd130x->device_info->need_chargepump?BIT(2):0));+if(ret<0)+returnret;++/* Set lookup table */+if(ssd130x->lookup_table_set){+inti;++ret=ssd130x_write_cmd(ssd130x->client,+SSD130X_SET_LOOKUP_TABLE);+if(ret<0)+returnret;++for(i=0;i<ARRAY_SIZE(ssd130x->lookup_table);++i){+u8val=ssd130x->lookup_table[i];++if(val<31||val>63)+dev_warn(&ssd130x->client->dev,+"lookup table index %d value out of range 31 <= %d <= 63\n",+i,val);+ret=ssd130x_write_cmd(ssd130x->client,val);+if(ret<0)+returnret;+}+}++/* Switch to horizontal addressing mode */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_SET_ADDRESS_MODE);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,+SSD130X_SET_ADDRESS_MODE_HORIZONTAL);+if(ret<0)+returnret;++/* Turn on the display */+ret=ssd130x_write_cmd(ssd130x->client,SSD130X_DISPLAY_ON);+if(ret<0)+returnret;++return0;+}++staticintssd130x_update_bl(structbacklight_device*bdev)+{+structssd130x_device*ssd130x=bl_get_data(bdev);+intbrightness=bdev->props.brightness;+intret;++ssd130x->contrast=brightness;++ret=ssd130x_write_cmd(ssd130x->client,SSD130X_CONTRAST);+if(ret<0)+returnret;++ret=ssd130x_write_cmd(ssd130x->client,ssd130x->contrast);+if(ret<0)+returnret;++return0;+}++staticintssd130x_get_brightness(structbacklight_device*bdev)+{+structssd130x_device*ssd130x=bl_get_data(bdev);++returnssd130x->contrast;+}++staticconststructbacklight_opsssd130xfb_bl_ops={+.update_status=ssd130x_update_bl,+.get_brightness=ssd130x_get_brightness,+};++staticvoidssd130x_reset(structssd130x_device*ssd130x)+{+/* Reset the screen */+gpiod_set_value_cansleep(ssd130x->reset,1);+udelay(4);+gpiod_set_value_cansleep(ssd130x->reset,0);+udelay(4);+}++staticvoidssd130x_parse_properties(structssd130x_device*ssd130x)+{+structdevice*dev=&ssd130x->client->dev;++if(device_property_read_u32(dev,"solomon,width",&ssd130x->width))+ssd130x->width=96;++if(device_property_read_u32(dev,"solomon,height",&ssd130x->height))+ssd130x->height=16;++if(device_property_read_u32(dev,"solomon,page-offset",&ssd130x->page_offset))+ssd130x->page_offset=1;++if(device_property_read_u32(dev,"solomon,col-offset",&ssd130x->col_offset))+ssd130x->col_offset=0;++if(device_property_read_u32(dev,"solomon,com-offset",&ssd130x->com_offset))+ssd130x->com_offset=0;++if(device_property_read_u32(dev,"solomon,prechargep1",&ssd130x->prechargep1))+ssd130x->prechargep1=2;++if(device_property_read_u32(dev,"solomon,prechargep2",&ssd130x->prechargep2))+ssd130x->prechargep2=2;++if(!device_property_read_u8_array(dev,"solomon,lookup-table",+ssd130x->lookup_table,+ARRAY_SIZE(ssd130x->lookup_table)))+ssd130x->lookup_table_set=1;++ssd130x->seg_remap=!device_property_read_bool(dev,"solomon,segment-no-remap");+ssd130x->com_seq=device_property_read_bool(dev,"solomon,com-seq");+ssd130x->com_lrremap=device_property_read_bool(dev,"solomon,com-lrremap");+ssd130x->com_invdir=device_property_read_bool(dev,"solomon,com-invdir");+ssd130x->area_color_enable=+device_property_read_bool(dev,"solomon,area-color-enable");+ssd130x->low_power=device_property_read_bool(dev,"solomon,low-power");++ssd130x->contrast=127;+ssd130x->vcomh=ssd130x->device_info->default_vcomh;++/* Setup display timing */+if(device_property_read_u32(dev,"solomon,dclk-div",&ssd130x->dclk_div))+ssd130x->dclk_div=ssd130x->device_info->default_dclk_div;+if(device_property_read_u32(dev,"solomon,dclk-frq",&ssd130x->dclk_frq))+ssd130x->dclk_frq=ssd130x->device_info->default_dclk_frq;+}++staticvoidssd130x_set_mode(structssd130x_device*ssd130x)+{+structdrm_display_mode*mode=&ssd130x->mode;+structdrm_device*drm=&ssd130x->drm;++mode->type=DRM_MODE_TYPE_DRIVER;+mode->clock=1;+mode->hdisplay=mode->htotal=ssd130x->width;+mode->hsync_start=mode->hsync_end=ssd130x->width;+mode->vdisplay=mode->vtotal=ssd130x->height;+mode->vsync_start=mode->vsync_end=ssd130x->height;+mode->width_mm=27;+mode->height_mm=27;++drm->mode_config.min_width=ssd130x->width;+drm->mode_config.max_width=ssd130x->width;+drm->mode_config.min_height=ssd130x->height;+drm->mode_config.max_height=ssd130x->height;+drm->mode_config.preferred_depth=32;+drm->mode_config.funcs=&ssd130x_mode_config_funcs;+}++staticintssd130x_probe(structi2c_client*client)+{+structdevice*dev=&client->dev;+structssd130x_device*ssd130x;+structbacklight_device*bl;+structdrm_device*drm;+charbl_name[12];+intret;++ssd130x=devm_drm_dev_alloc(dev,&ssd130x_drm_driver,+structssd130x_device,drm);+if(IS_ERR(ssd130x))+returnPTR_ERR(ssd130x);++drm=&ssd130x->drm;++ret=drmm_mode_config_init(drm);+if(ret)+returnret;++ssd130x->client=client;++ssd130x->device_info=device_get_match_data(dev);++ssd130x_parse_properties(ssd130x);++ssd130x_set_mode(ssd130x);++ssd130x->reset=devm_gpiod_get_optional(dev,"reset",GPIOD_OUT_LOW);+if(IS_ERR(ssd130x->reset)){+dev_err(dev,"failed to get reset gpio: %ld\n",+PTR_ERR(ssd130x->reset));+returnPTR_ERR(ssd130x->reset);+}++ssd130x->vbat_reg=devm_regulator_get_optional(dev,"vbat");+if(IS_ERR(ssd130x->vbat_reg)){+ret=PTR_ERR(ssd130x->vbat_reg);+if(ret==-ENODEV){+ssd130x->vbat_reg=NULL;+}else{+dev_err(dev,"failed to get VBAT regulator: %d\n",ret);+returnret;+}+}++drm_connector_helper_add(&ssd130x->connector,&ssd130x_connector_helper_funcs);+ret=drm_connector_init(drm,&ssd130x->connector,&ssd130x_connector_funcs,+DRM_MODE_CONNECTOR_Unknown);+if(ret)+returnret;++i2c_set_clientdata(client,ssd130x);++if(ssd130x->reset)+ssd130x_reset(ssd130x);++if(ssd130x->vbat_reg){+ret=regulator_enable(ssd130x->vbat_reg);+if(ret){+dev_err(dev,"failed to enable VBAT: %d\n",ret);+returnret;+}+}++ret=ssd130x_init(ssd130x);+if(ret)+gotoregulator_disable;++if(ssd130x->device_info->need_pwm){+ret=ssd130x_pwm_enable(ssd130x);+if(ret)+gotoregulator_disable;+}++snprintf(bl_name,sizeof(bl_name),"ssd130x%d",drm->primary->index);+bl=backlight_device_register(bl_name,dev,ssd130x,&ssd130xfb_bl_ops,+NULL);+if(IS_ERR(bl)){+ret=PTR_ERR(bl);+dev_err(dev,"unable to register backlight device: %d\n",ret);+gotopwm_disable;+}++bl->props.brightness=ssd130x->contrast;+bl->props.max_brightness=MAX_CONTRAST;+ssd130x->bl_dev=bl;++ret=drm_simple_display_pipe_init(drm,&ssd130x->pipe,&ssd130x_pipe_funcs,+ssd130x_formats,ARRAY_SIZE(ssd130x_formats),+NULL,&ssd130x->connector);+if(ret)+gotopwm_disable;++drm_plane_enable_fb_damage_clips(&ssd130x->pipe.plane);++drm_mode_config_reset(drm);++ret=drm_dev_register(drm,0);+if(ret)+gotobacklight_unregister;++drm_fbdev_generic_setup(drm,0);++return0;++backlight_unregister:+backlight_device_unregister(ssd130x->bl_dev);+pwm_disable:+if(ssd130x->device_info->need_pwm){+pwm_disable(ssd130x->pwm);+pwm_put(ssd130x->pwm);+}+regulator_disable:+if(ssd130x->vbat_reg)+regulator_disable(ssd130x->vbat_reg);+returnret;+}++staticintssd130x_remove(structi2c_client*client)+{+structssd130x_device*ssd130x=i2c_get_clientdata(client);++drm_dev_unplug(&ssd130x->drm);++ssd130x_write_cmd(ssd130x->client,SSD130X_DISPLAY_OFF);++backlight_device_unregister(ssd130x->bl_dev);++if(ssd130x->device_info->need_pwm){+pwm_disable(ssd130x->pwm);+pwm_put(ssd130x->pwm);+}+if(ssd130x->vbat_reg)+regulator_disable(ssd130x->vbat_reg);++return0;+}++staticvoidssd130x_shutdown(structi2c_client*client)+{+structssd130x_device*ssd130x=i2c_get_clientdata(client);++drm_atomic_helper_shutdown(&ssd130x->drm);+}++staticstructssd130x_deviceinfossd130x_ssd1305_deviceinfo={+.default_vcomh=0x34,+.default_dclk_div=1,+.default_dclk_frq=7,+};++staticstructssd130x_deviceinfossd130x_ssd1306_deviceinfo={+.default_vcomh=0x20,+.default_dclk_div=1,+.default_dclk_frq=8,+.need_chargepump=1,+};++staticstructssd130x_deviceinfossd130x_ssd1307_deviceinfo={+.default_vcomh=0x20,+.default_dclk_div=2,+.default_dclk_frq=12,+.need_pwm=1,+};++staticstructssd130x_deviceinfossd130x_ssd1309_deviceinfo={+.default_vcomh=0x34,+.default_dclk_div=1,+.default_dclk_frq=10,+};++staticconststructof_device_idssd130x_of_match[]={+{+.compatible="solomon,ssd1305fb-i2c",+.data=(void*)&ssd130x_ssd1305_deviceinfo,+},+{+.compatible="solomon,ssd1306fb-i2c",+.data=(void*)&ssd130x_ssd1306_deviceinfo,+},+{+.compatible="solomon,ssd1307fb-i2c",+.data=(void*)&ssd130x_ssd1307_deviceinfo,+},+{+.compatible="solomon,ssd1309fb-i2c",+.data=(void*)&ssd130x_ssd1309_deviceinfo,+},+{},+};+MODULE_DEVICE_TABLE(of,ssd130x_of_match);+++staticstructi2c_driverssd130x_i2c_driver={+.driver={+.name=DRIVER_NAME,+.of_match_table=ssd130x_of_match,+},+.probe_new=ssd130x_probe,+.remove=ssd130x_remove,+.shutdown=ssd130x_shutdown,+};++module_i2c_driver(ssd130x_i2c_driver);++MODULE_DESCRIPTION(DRIVER_DESC);+MODULE_AUTHOR("Javier Martinez Canillas <javierm@redhat.com>");+MODULE_LICENSE("GPL v2");
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-01-31 10:19:10
Hello Thomas,
On 1/31/22 10:18, Thomas Zimmermann wrote:
[snip]
quoted
There are some hacks in the driver though. For example it exposes an XRGB8888
format even thought the OLED display is monochromatic and has 1 bit per pixel.
The driver then goes and converts the XRGB8888 pixels first to grayscale and
then to reverse mono. I took that idea from the repaper driver but that gives
us the multiple copies that Geert was complaining about.
This requires to update the console code for 1-bit BW output. The fbcon
side already supports this AFAIK. DRM's fbdev needs a few more branches
and something like a DRM_FORMAT_C1 fourcc. The XRGB8888 is really a
userspace requirement that is imposed by modern desktops. If DRM's
console has been updated, you could leave it out entirely.
I could imagine that some simple userspace, such as Weston, comes with
support for palette formats and BW. Or there could be an entirely
separate program that puts graphics onto these displays.
Yes, I understand the rationale of why the repaper driver is doing that way
but was just pointing out because Geert mentioned that is not efficient.
Maybe in the meantime we can add a drm_fb_gray8_to_mono_reversed() helper to
drivers/gpu/drm/drm_format_helper.c since there is more than one driver that
does the same ?
It's not a big issue for this device really since the I2C bus is slow anyways
and the multiple copies are not a bottleneck AFAICT.
I believe is worth to propose this driver as is and then try to optimize later.
Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for
now a DRM_MODE_CONNECTOR_Unknown.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat