* [RFC PATCH 1/3] staging: remove xgifb
2016-11-23 8:03 [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen
@ 2016-11-23 8:03 ` Tomi Valkeinen
2016-11-23 8:03 ` [RFC PATCH 2/3] staging: remove sm750fb Tomi Valkeinen
` (4 subsequent siblings)
5 siblings, 0 replies; 54+ messages in thread
From: Tomi Valkeinen @ 2016-11-23 8:03 UTC (permalink / raw)
To: linux-fbdev, dri-devel, Greg Kroah-Hartman, Thomas Petazzoni,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard
Cc: linux-kernel, Tomi Valkeinen
Since the fbdev framework is in maintenance mode and all new display
drivers should be made with the DRM framework, remove xgifb from
staging. Especially as xgifb has been in staging for 6 years...
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
MAINTAINERS | 5 -
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/xgifb/Kconfig | 11 -
drivers/staging/xgifb/Makefile | 4 -
drivers/staging/xgifb/TODO | 13 -
drivers/staging/xgifb/XGI_main.h | 377 ---
drivers/staging/xgifb/XGI_main_26.c | 2100 -------------
drivers/staging/xgifb/XGIfb.h | 108 -
drivers/staging/xgifb/vb_def.h | 256 --
drivers/staging/xgifb/vb_init.c | 1363 ---------
drivers/staging/xgifb/vb_init.h | 6 -
drivers/staging/xgifb/vb_setmode.c | 5529 -----------------------------------
drivers/staging/xgifb/vb_setmode.h | 23 -
drivers/staging/xgifb/vb_struct.h | 164 --
drivers/staging/xgifb/vb_table.h | 2511 ----------------
drivers/staging/xgifb/vb_util.h | 45 -
drivers/staging/xgifb/vgatypes.h | 50 -
18 files changed, 12568 deletions(-)
delete mode 100644 drivers/staging/xgifb/Kconfig
delete mode 100644 drivers/staging/xgifb/Makefile
delete mode 100644 drivers/staging/xgifb/TODO
delete mode 100644 drivers/staging/xgifb/XGI_main.h
delete mode 100644 drivers/staging/xgifb/XGI_main_26.c
delete mode 100644 drivers/staging/xgifb/XGIfb.h
delete mode 100644 drivers/staging/xgifb/vb_def.h
delete mode 100644 drivers/staging/xgifb/vb_init.c
delete mode 100644 drivers/staging/xgifb/vb_init.h
delete mode 100644 drivers/staging/xgifb/vb_setmode.c
delete mode 100644 drivers/staging/xgifb/vb_setmode.h
delete mode 100644 drivers/staging/xgifb/vb_struct.h
delete mode 100644 drivers/staging/xgifb/vb_table.h
delete mode 100644 drivers/staging/xgifb/vb_util.h
delete mode 100644 drivers/staging/xgifb/vgatypes.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 851b89b9edcb..b97f18d2e93d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11564,11 +11564,6 @@ L: linux-wireless@vger.kernel.org
S: Supported
F: drivers/staging/wilc1000/
-STAGING - XGI Z7,Z9,Z11 PCI DISPLAY DRIVER
-M: Arnaud Patard <arnaud.patard@rtp-net.org>
-S: Odd Fixes
-F: drivers/staging/xgifb/
-
STARFIRE/DURALAN NETWORK DRIVER
M: Ion Badulescu <ionut@badula.org>
S: Odd Fixes
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 58a7b3504b82..2afd7466cfde 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -54,8 +54,6 @@ source "drivers/staging/iio/Kconfig"
source "drivers/staging/sm750fb/Kconfig"
-source "drivers/staging/xgifb/Kconfig"
-
source "drivers/staging/emxx_udc/Kconfig"
source "drivers/staging/speakup/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 2fa9745db614..31c1054ace20 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -18,7 +18,6 @@ obj-$(CONFIG_VT6656) += vt6656/
obj-$(CONFIG_VME_BUS) += vme/
obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_FB_SM750) += sm750fb/
-obj-$(CONFIG_FB_XGI) += xgifb/
obj-$(CONFIG_USB_EMXX) += emxx_udc/
obj-$(CONFIG_SPEAKUP) += speakup/
obj-$(CONFIG_MFD_NVEC) += nvec/
diff --git a/drivers/staging/xgifb/Kconfig b/drivers/staging/xgifb/Kconfig
deleted file mode 100644
index bb0ca5974ea0..000000000000
diff --git a/drivers/staging/xgifb/Makefile b/drivers/staging/xgifb/Makefile
deleted file mode 100644
index 964a843c4521..000000000000
diff --git a/drivers/staging/xgifb/TODO b/drivers/staging/xgifb/TODO
deleted file mode 100644
index 7eb99140a399..000000000000
diff --git a/drivers/staging/xgifb/XGI_main.h b/drivers/staging/xgifb/XGI_main.h
deleted file mode 100644
index 85079fea7152..000000000000
diff --git a/drivers/staging/xgifb/XGI_main_26.c b/drivers/staging/xgifb/XGI_main_26.c
deleted file mode 100644
index 0c78491ff5a1..000000000000
diff --git a/drivers/staging/xgifb/XGIfb.h b/drivers/staging/xgifb/XGIfb.h
deleted file mode 100644
index af50362395d5..000000000000
diff --git a/drivers/staging/xgifb/vb_def.h b/drivers/staging/xgifb/vb_def.h
deleted file mode 100644
index 94e2e3c7c264..000000000000
diff --git a/drivers/staging/xgifb/vb_init.c b/drivers/staging/xgifb/vb_init.c
deleted file mode 100644
index 062ece22ed84..000000000000
diff --git a/drivers/staging/xgifb/vb_init.h b/drivers/staging/xgifb/vb_init.h
deleted file mode 100644
index 500cabe41a3c..000000000000
diff --git a/drivers/staging/xgifb/vb_setmode.c b/drivers/staging/xgifb/vb_setmode.c
deleted file mode 100644
index d8010c5c1a70..000000000000
diff --git a/drivers/staging/xgifb/vb_setmode.h b/drivers/staging/xgifb/vb_setmode.h
deleted file mode 100644
index 6f082a7a5a4a..000000000000
diff --git a/drivers/staging/xgifb/vb_struct.h b/drivers/staging/xgifb/vb_struct.h
deleted file mode 100644
index 2fd1a5935e1d..000000000000
diff --git a/drivers/staging/xgifb/vb_table.h b/drivers/staging/xgifb/vb_table.h
deleted file mode 100644
index c801deb142f6..000000000000
diff --git a/drivers/staging/xgifb/vb_util.h b/drivers/staging/xgifb/vb_util.h
deleted file mode 100644
index 08db58b396b2..000000000000
diff --git a/drivers/staging/xgifb/vgatypes.h b/drivers/staging/xgifb/vgatypes.h
deleted file mode 100644
index de80e5c108dc..000000000000
--
2.7.4
^ permalink raw reply related [flat|nested] 54+ messages in thread* [RFC PATCH 2/3] staging: remove sm750fb
2016-11-23 8:03 [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen
2016-11-23 8:03 ` [RFC PATCH 1/3] staging: remove xgifb Tomi Valkeinen
@ 2016-11-23 8:03 ` Tomi Valkeinen
2016-11-23 8:03 ` [RFC PATCH 3/3] staging: remove fbtft Tomi Valkeinen
` (3 subsequent siblings)
5 siblings, 0 replies; 54+ messages in thread
From: Tomi Valkeinen @ 2016-11-23 8:03 UTC (permalink / raw)
To: linux-fbdev, dri-devel, Greg Kroah-Hartman, Thomas Petazzoni,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard
Cc: linux-kernel, Tomi Valkeinen
Since the fbdev framework is in maintenance mode and all new display
drivers should be made with the DRM framework, remove sm750fb from
staging.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
MAINTAINERS | 8 -
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/sm750fb/Kconfig | 14 -
drivers/staging/sm750fb/Makefile | 4 -
drivers/staging/sm750fb/TODO | 16 -
drivers/staging/sm750fb/ddk750.h | 24 -
drivers/staging/sm750fb/ddk750_chip.c | 403 ---------
drivers/staging/sm750fb/ddk750_chip.h | 79 --
drivers/staging/sm750fb/ddk750_display.c | 186 ----
drivers/staging/sm750fb/ddk750_display.h | 102 ---
drivers/staging/sm750fb/ddk750_dvi.c | 60 --
drivers/staging/sm750fb/ddk750_dvi.h | 59 --
drivers/staging/sm750fb/ddk750_help.c | 17 -
drivers/staging/sm750fb/ddk750_help.h | 21 -
drivers/staging/sm750fb/ddk750_hwi2c.c | 254 ------
drivers/staging/sm750fb/ddk750_hwi2c.h | 11 -
drivers/staging/sm750fb/ddk750_mode.c | 220 -----
drivers/staging/sm750fb/ddk750_mode.h | 41 -
drivers/staging/sm750fb/ddk750_power.c | 165 ----
drivers/staging/sm750fb/ddk750_power.h | 50 -
drivers/staging/sm750fb/ddk750_reg.h | 1458 ------------------------------
drivers/staging/sm750fb/ddk750_sii164.c | 410 ---------
drivers/staging/sm750fb/ddk750_sii164.h | 174 ----
drivers/staging/sm750fb/ddk750_swi2c.c | 516 -----------
drivers/staging/sm750fb/ddk750_swi2c.h | 71 --
drivers/staging/sm750fb/readme | 38 -
drivers/staging/sm750fb/sm750.c | 1248 -------------------------
drivers/staging/sm750fb/sm750.h | 202 -----
drivers/staging/sm750fb/sm750_accel.c | 388 --------
drivers/staging/sm750fb/sm750_accel.h | 225 -----
drivers/staging/sm750fb/sm750_cursor.c | 183 ----
drivers/staging/sm750fb/sm750_cursor.h | 17 -
drivers/staging/sm750fb/sm750_hw.c | 557 ------------
34 files changed, 7224 deletions(-)
delete mode 100644 drivers/staging/sm750fb/Kconfig
delete mode 100644 drivers/staging/sm750fb/Makefile
delete mode 100644 drivers/staging/sm750fb/TODO
delete mode 100644 drivers/staging/sm750fb/ddk750.h
delete mode 100644 drivers/staging/sm750fb/ddk750_chip.c
delete mode 100644 drivers/staging/sm750fb/ddk750_chip.h
delete mode 100644 drivers/staging/sm750fb/ddk750_display.c
delete mode 100644 drivers/staging/sm750fb/ddk750_display.h
delete mode 100644 drivers/staging/sm750fb/ddk750_dvi.c
delete mode 100644 drivers/staging/sm750fb/ddk750_dvi.h
delete mode 100644 drivers/staging/sm750fb/ddk750_help.c
delete mode 100644 drivers/staging/sm750fb/ddk750_help.h
delete mode 100644 drivers/staging/sm750fb/ddk750_hwi2c.c
delete mode 100644 drivers/staging/sm750fb/ddk750_hwi2c.h
delete mode 100644 drivers/staging/sm750fb/ddk750_mode.c
delete mode 100644 drivers/staging/sm750fb/ddk750_mode.h
delete mode 100644 drivers/staging/sm750fb/ddk750_power.c
delete mode 100644 drivers/staging/sm750fb/ddk750_power.h
delete mode 100644 drivers/staging/sm750fb/ddk750_reg.h
delete mode 100644 drivers/staging/sm750fb/ddk750_sii164.c
delete mode 100644 drivers/staging/sm750fb/ddk750_sii164.h
delete mode 100644 drivers/staging/sm750fb/ddk750_swi2c.c
delete mode 100644 drivers/staging/sm750fb/ddk750_swi2c.h
delete mode 100644 drivers/staging/sm750fb/readme
delete mode 100644 drivers/staging/sm750fb/sm750.c
delete mode 100644 drivers/staging/sm750fb/sm750.h
delete mode 100644 drivers/staging/sm750fb/sm750_accel.c
delete mode 100644 drivers/staging/sm750fb/sm750_accel.h
delete mode 100644 drivers/staging/sm750fb/sm750_cursor.c
delete mode 100644 drivers/staging/sm750fb/sm750_cursor.h
delete mode 100644 drivers/staging/sm750fb/sm750_hw.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b97f18d2e93d..772330b38212 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11528,14 +11528,6 @@ M: Florian Schilhabel <florian.c.schilhabel@googlemail.com>.
S: Odd Fixes
F: drivers/staging/rtl8712/
-STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER
-M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
-M: Teddy Wang <teddy.wang@siliconmotion.com>
-M: Sudip Mukherjee <sudip@vectorindia.org>
-L: linux-fbdev@vger.kernel.org
-S: Maintained
-F: drivers/staging/sm750fb/
-
STAGING - SLICOSS
M: Lior Dotan <liodot@gmail.com>
M: Christopher Harrer <charrer@alacritech.com>
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 2afd7466cfde..fcfe8fcea441 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -52,8 +52,6 @@ source "drivers/staging/vt6656/Kconfig"
source "drivers/staging/iio/Kconfig"
-source "drivers/staging/sm750fb/Kconfig"
-
source "drivers/staging/emxx_udc/Kconfig"
source "drivers/staging/speakup/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 31c1054ace20..585eb34020a1 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_VT6655) += vt6655/
obj-$(CONFIG_VT6656) += vt6656/
obj-$(CONFIG_VME_BUS) += vme/
obj-$(CONFIG_IIO) += iio/
-obj-$(CONFIG_FB_SM750) += sm750fb/
obj-$(CONFIG_USB_EMXX) += emxx_udc/
obj-$(CONFIG_SPEAKUP) += speakup/
obj-$(CONFIG_MFD_NVEC) += nvec/
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
deleted file mode 100644
index ccebc25c2ec1..000000000000
diff --git a/drivers/staging/sm750fb/Makefile b/drivers/staging/sm750fb/Makefile
deleted file mode 100644
index dcce3f487ed5..000000000000
diff --git a/drivers/staging/sm750fb/TODO b/drivers/staging/sm750fb/TODO
deleted file mode 100644
index a3a877d90066..000000000000
diff --git a/drivers/staging/sm750fb/ddk750.h b/drivers/staging/sm750fb/ddk750.h
deleted file mode 100644
index 2c10a08ed964..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
deleted file mode 100644
index 839d6730bde9..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_chip.h b/drivers/staging/sm750fb/ddk750_chip.h
deleted file mode 100644
index 14357fd1cc6b..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_display.c b/drivers/staging/sm750fb/ddk750_display.c
deleted file mode 100644
index 4023c476b9e4..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_display.h b/drivers/staging/sm750fb/ddk750_display.h
deleted file mode 100644
index e3fde428c52b..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
deleted file mode 100644
index 8252f771ef9e..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_dvi.h b/drivers/staging/sm750fb/ddk750_dvi.h
deleted file mode 100644
index 677939cb5130..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_help.c b/drivers/staging/sm750fb/ddk750_help.c
deleted file mode 100644
index 9637dd30d037..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_help.h b/drivers/staging/sm750fb/ddk750_help.h
deleted file mode 100644
index 009db9213a73..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c b/drivers/staging/sm750fb/ddk750_hwi2c.c
deleted file mode 100644
index d391c127ead7..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h b/drivers/staging/sm750fb/ddk750_hwi2c.h
deleted file mode 100644
index 46e22dce2570..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_mode.c b/drivers/staging/sm750fb/ddk750_mode.c
deleted file mode 100644
index 05b83646c2d5..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_mode.h b/drivers/staging/sm750fb/ddk750_mode.h
deleted file mode 100644
index e846dc2c3d5c..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
deleted file mode 100644
index 7cc6169f884e..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_power.h b/drivers/staging/sm750fb/ddk750_power.h
deleted file mode 100644
index 5963691f9a68..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_reg.h b/drivers/staging/sm750fb/ddk750_reg.h
deleted file mode 100644
index 4ed6d8d7712a..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
deleted file mode 100644
index 99a8683e6383..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
deleted file mode 100644
index 664ad089f753..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
deleted file mode 100644
index 72a42330e7a1..000000000000
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.h b/drivers/staging/sm750fb/ddk750_swi2c.h
deleted file mode 100644
index b53629cda095..000000000000
diff --git a/drivers/staging/sm750fb/readme b/drivers/staging/sm750fb/readme
deleted file mode 100644
index cfa45958b9d2..000000000000
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
deleted file mode 100644
index 7d90e250142c..000000000000
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
deleted file mode 100644
index ff31c5c9cc6f..000000000000
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
deleted file mode 100644
index 38adae6b5d83..000000000000
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
deleted file mode 100644
index d59d005e0add..000000000000
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
deleted file mode 100644
index d622d65b6cee..000000000000
diff --git a/drivers/staging/sm750fb/sm750_cursor.h b/drivers/staging/sm750fb/sm750_cursor.h
deleted file mode 100644
index 6c4fc9b73489..000000000000
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
deleted file mode 100644
index 7dd208caa5eb..000000000000
--
2.7.4
^ permalink raw reply related [flat|nested] 54+ messages in thread* [RFC PATCH 3/3] staging: remove fbtft
2016-11-23 8:03 [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen
2016-11-23 8:03 ` [RFC PATCH 1/3] staging: remove xgifb Tomi Valkeinen
2016-11-23 8:03 ` [RFC PATCH 2/3] staging: remove sm750fb Tomi Valkeinen
@ 2016-11-23 8:03 ` Tomi Valkeinen
2016-11-23 17:26 ` Noralf Trønnes
2016-11-23 20:12 ` Drew Fustini
2016-11-23 8:19 ` [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter
` (2 subsequent siblings)
5 siblings, 2 replies; 54+ messages in thread
From: Tomi Valkeinen @ 2016-11-23 8:03 UTC (permalink / raw)
To: linux-fbdev, dri-devel, Greg Kroah-Hartman, Thomas Petazzoni,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard
Cc: linux-kernel, Tomi Valkeinen
Since the fbdev framework is in maintenance mode and all new display
drivers should be made with the DRM framework, remove fbtft from
staging.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
MAINTAINERS | 6 -
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/fbtft/Kconfig | 210 -----
drivers/staging/fbtft/Makefile | 40 -
drivers/staging/fbtft/README | 32 -
drivers/staging/fbtft/fb_agm1264k-fl.c | 456 ---------
drivers/staging/fbtft/fb_bd663474.c | 184 ----
drivers/staging/fbtft/fb_hx8340bn.c | 234 -----
drivers/staging/fbtft/fb_hx8347d.c | 169 ----
drivers/staging/fbtft/fb_hx8353d.c | 157 ----
drivers/staging/fbtft/fb_hx8357d.c | 210 -----
drivers/staging/fbtft/fb_hx8357d.h | 70 --
drivers/staging/fbtft/fb_ili9163.c | 273 ------
drivers/staging/fbtft/fb_ili9320.c | 278 ------
drivers/staging/fbtft/fb_ili9325.c | 277 ------
drivers/staging/fbtft/fb_ili9340.c | 149 ---
drivers/staging/fbtft/fb_ili9341.c | 166 ----
drivers/staging/fbtft/fb_ili9481.c | 112 ---
drivers/staging/fbtft/fb_ili9486.c | 112 ---
drivers/staging/fbtft/fb_pcd8544.c | 176 ----
drivers/staging/fbtft/fb_ra8875.c | 318 -------
drivers/staging/fbtft/fb_s6d02a1.c | 166 ----
drivers/staging/fbtft/fb_s6d1121.c | 194 ----
drivers/staging/fbtft/fb_ssd1289.c | 191 ----
drivers/staging/fbtft/fb_ssd1305.c | 216 -----
drivers/staging/fbtft/fb_ssd1306.c | 217 -----
drivers/staging/fbtft/fb_ssd1325.c | 205 ----
drivers/staging/fbtft/fb_ssd1331.c | 196 ----
drivers/staging/fbtft/fb_ssd1351.c | 238 -----
drivers/staging/fbtft/fb_st7735r.c | 190 ----
drivers/staging/fbtft/fb_st7789v.c | 265 ------
drivers/staging/fbtft/fb_tinylcd.c | 112 ---
drivers/staging/fbtft/fb_tls8204.c | 169 ----
drivers/staging/fbtft/fb_uc1611.c | 340 -------
drivers/staging/fbtft/fb_uc1701.c | 179 ----
drivers/staging/fbtft/fb_upd161704.c | 197 ----
drivers/staging/fbtft/fb_watterott.c | 302 ------
drivers/staging/fbtft/fbtft-bus.c | 252 -----
drivers/staging/fbtft/fbtft-core.c | 1467 -----------------------------
drivers/staging/fbtft/fbtft-io.c | 238 -----
drivers/staging/fbtft/fbtft-sysfs.c | 219 -----
drivers/staging/fbtft/fbtft.h | 421 ---------
drivers/staging/fbtft/fbtft_device.c | 1597 --------------------------------
drivers/staging/fbtft/flexfb.c | 619 -------------
drivers/staging/fbtft/internal.h | 25 -
46 files changed, 11847 deletions(-)
delete mode 100644 drivers/staging/fbtft/Kconfig
delete mode 100644 drivers/staging/fbtft/Makefile
delete mode 100644 drivers/staging/fbtft/README
delete mode 100644 drivers/staging/fbtft/fb_agm1264k-fl.c
delete mode 100644 drivers/staging/fbtft/fb_bd663474.c
delete mode 100644 drivers/staging/fbtft/fb_hx8340bn.c
delete mode 100644 drivers/staging/fbtft/fb_hx8347d.c
delete mode 100644 drivers/staging/fbtft/fb_hx8353d.c
delete mode 100644 drivers/staging/fbtft/fb_hx8357d.c
delete mode 100644 drivers/staging/fbtft/fb_hx8357d.h
delete mode 100644 drivers/staging/fbtft/fb_ili9163.c
delete mode 100644 drivers/staging/fbtft/fb_ili9320.c
delete mode 100644 drivers/staging/fbtft/fb_ili9325.c
delete mode 100644 drivers/staging/fbtft/fb_ili9340.c
delete mode 100644 drivers/staging/fbtft/fb_ili9341.c
delete mode 100644 drivers/staging/fbtft/fb_ili9481.c
delete mode 100644 drivers/staging/fbtft/fb_ili9486.c
delete mode 100644 drivers/staging/fbtft/fb_pcd8544.c
delete mode 100644 drivers/staging/fbtft/fb_ra8875.c
delete mode 100644 drivers/staging/fbtft/fb_s6d02a1.c
delete mode 100644 drivers/staging/fbtft/fb_s6d1121.c
delete mode 100644 drivers/staging/fbtft/fb_ssd1289.c
delete mode 100644 drivers/staging/fbtft/fb_ssd1305.c
delete mode 100644 drivers/staging/fbtft/fb_ssd1306.c
delete mode 100644 drivers/staging/fbtft/fb_ssd1325.c
delete mode 100644 drivers/staging/fbtft/fb_ssd1331.c
delete mode 100644 drivers/staging/fbtft/fb_ssd1351.c
delete mode 100644 drivers/staging/fbtft/fb_st7735r.c
delete mode 100644 drivers/staging/fbtft/fb_st7789v.c
delete mode 100644 drivers/staging/fbtft/fb_tinylcd.c
delete mode 100644 drivers/staging/fbtft/fb_tls8204.c
delete mode 100644 drivers/staging/fbtft/fb_uc1611.c
delete mode 100644 drivers/staging/fbtft/fb_uc1701.c
delete mode 100644 drivers/staging/fbtft/fb_upd161704.c
delete mode 100644 drivers/staging/fbtft/fb_watterott.c
delete mode 100644 drivers/staging/fbtft/fbtft-bus.c
delete mode 100644 drivers/staging/fbtft/fbtft-core.c
delete mode 100644 drivers/staging/fbtft/fbtft-io.c
delete mode 100644 drivers/staging/fbtft/fbtft-sysfs.c
delete mode 100644 drivers/staging/fbtft/fbtft.h
delete mode 100644 drivers/staging/fbtft/fbtft_device.c
delete mode 100644 drivers/staging/fbtft/flexfb.c
delete mode 100644 drivers/staging/fbtft/internal.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 772330b38212..466a86a3b2fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4839,12 +4839,6 @@ S: Supported
F: Documentation/fault-injection/
F: lib/fault-inject.c
-FBTFT Framebuffer drivers
-M: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-M: Noralf Trønnes <noralf@tronnes.org>
-S: Maintained
-F: drivers/staging/fbtft/
-
FCOE SUBSYSTEM (libfc, libfcoe, fcoe)
M: Johannes Thumshirn <jth@kernel.org>
L: fcoe-devel@open-fcoe.org
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index fcfe8fcea441..69a62eac7bbf 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -86,8 +86,6 @@ source "drivers/staging/unisys/Kconfig"
source "drivers/staging/clocking-wizard/Kconfig"
-source "drivers/staging/fbtft/Kconfig"
-
source "drivers/staging/fsl-mc/Kconfig"
source "drivers/staging/wilc1000/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 585eb34020a1..33a768c0942d 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -32,7 +32,6 @@ obj-$(CONFIG_GS_FPGABOOT) += gs_fpgaboot/
obj-$(CONFIG_CRYPTO_SKEIN) += skein/
obj-$(CONFIG_UNISYSSPAR) += unisys/
obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clocking-wizard/
-obj-$(CONFIG_FB_TFT) += fbtft/
obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
obj-$(CONFIG_WILC1000) += wilc1000/
obj-$(CONFIG_MOST) += most/
diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
deleted file mode 100644
index 6f5e82464d78..000000000000
diff --git a/drivers/staging/fbtft/Makefile b/drivers/staging/fbtft/Makefile
deleted file mode 100644
index 2725ea9a4afc..000000000000
diff --git a/drivers/staging/fbtft/README b/drivers/staging/fbtft/README
deleted file mode 100644
index ba4c74c92e4c..000000000000
diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c
deleted file mode 100644
index 7561385761e9..000000000000
diff --git a/drivers/staging/fbtft/fb_bd663474.c b/drivers/staging/fbtft/fb_bd663474.c
deleted file mode 100644
index 6010e6cbbd72..000000000000
diff --git a/drivers/staging/fbtft/fb_hx8340bn.c b/drivers/staging/fbtft/fb_hx8340bn.c
deleted file mode 100644
index 9970ed74bb38..000000000000
diff --git a/drivers/staging/fbtft/fb_hx8347d.c b/drivers/staging/fbtft/fb_hx8347d.c
deleted file mode 100644
index 450a61e3f99c..000000000000
diff --git a/drivers/staging/fbtft/fb_hx8353d.c b/drivers/staging/fbtft/fb_hx8353d.c
deleted file mode 100644
index 72e4ff8c5553..000000000000
diff --git a/drivers/staging/fbtft/fb_hx8357d.c b/drivers/staging/fbtft/fb_hx8357d.c
deleted file mode 100644
index 32e6efe1d0a7..000000000000
diff --git a/drivers/staging/fbtft/fb_hx8357d.h b/drivers/staging/fbtft/fb_hx8357d.h
deleted file mode 100644
index e281921d4a97..000000000000
diff --git a/drivers/staging/fbtft/fb_ili9163.c b/drivers/staging/fbtft/fb_ili9163.c
deleted file mode 100644
index 6b8f8b17e9a3..000000000000
diff --git a/drivers/staging/fbtft/fb_ili9320.c b/drivers/staging/fbtft/fb_ili9320.c
deleted file mode 100644
index 278e4c7e95e5..000000000000
diff --git a/drivers/staging/fbtft/fb_ili9325.c b/drivers/staging/fbtft/fb_ili9325.c
deleted file mode 100644
index c31e2e051d4a..000000000000
diff --git a/drivers/staging/fbtft/fb_ili9340.c b/drivers/staging/fbtft/fb_ili9340.c
deleted file mode 100644
index 0711121c303c..000000000000
diff --git a/drivers/staging/fbtft/fb_ili9341.c b/drivers/staging/fbtft/fb_ili9341.c
deleted file mode 100644
index ff35c8624ca3..000000000000
diff --git a/drivers/staging/fbtft/fb_ili9481.c b/drivers/staging/fbtft/fb_ili9481.c
deleted file mode 100644
index 242adb3859bd..000000000000
diff --git a/drivers/staging/fbtft/fb_ili9486.c b/drivers/staging/fbtft/fb_ili9486.c
deleted file mode 100644
index fa38d8885f0b..000000000000
diff --git a/drivers/staging/fbtft/fb_pcd8544.c b/drivers/staging/fbtft/fb_pcd8544.c
deleted file mode 100644
index a4710dc067ef..000000000000
diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
deleted file mode 100644
index 308a244972aa..000000000000
diff --git a/drivers/staging/fbtft/fb_s6d02a1.c b/drivers/staging/fbtft/fb_s6d02a1.c
deleted file mode 100644
index 774b0ff69e6d..000000000000
diff --git a/drivers/staging/fbtft/fb_s6d1121.c b/drivers/staging/fbtft/fb_s6d1121.c
deleted file mode 100644
index 9b1d70b218df..000000000000
diff --git a/drivers/staging/fbtft/fb_ssd1289.c b/drivers/staging/fbtft/fb_ssd1289.c
deleted file mode 100644
index 25f9fbe1e76f..000000000000
diff --git a/drivers/staging/fbtft/fb_ssd1305.c b/drivers/staging/fbtft/fb_ssd1305.c
deleted file mode 100644
index 4b38c3fadd60..000000000000
diff --git a/drivers/staging/fbtft/fb_ssd1306.c b/drivers/staging/fbtft/fb_ssd1306.c
deleted file mode 100644
index 80fc57029fee..000000000000
diff --git a/drivers/staging/fbtft/fb_ssd1325.c b/drivers/staging/fbtft/fb_ssd1325.c
deleted file mode 100644
index 15078bf2aa4b..000000000000
diff --git a/drivers/staging/fbtft/fb_ssd1331.c b/drivers/staging/fbtft/fb_ssd1331.c
deleted file mode 100644
index 1d74ac1343a8..000000000000
diff --git a/drivers/staging/fbtft/fb_ssd1351.c b/drivers/staging/fbtft/fb_ssd1351.c
deleted file mode 100644
index 200aa9ba98f9..000000000000
diff --git a/drivers/staging/fbtft/fb_st7735r.c b/drivers/staging/fbtft/fb_st7735r.c
deleted file mode 100644
index 6670f2bb62ec..000000000000
diff --git a/drivers/staging/fbtft/fb_st7789v.c b/drivers/staging/fbtft/fb_st7789v.c
deleted file mode 100644
index 085e9872c46d..000000000000
diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
deleted file mode 100644
index 097e71cfef62..000000000000
diff --git a/drivers/staging/fbtft/fb_tls8204.c b/drivers/staging/fbtft/fb_tls8204.c
deleted file mode 100644
index ea2ddacb9468..000000000000
diff --git a/drivers/staging/fbtft/fb_uc1611.c b/drivers/staging/fbtft/fb_uc1611.c
deleted file mode 100644
index b33b73f17da4..000000000000
diff --git a/drivers/staging/fbtft/fb_uc1701.c b/drivers/staging/fbtft/fb_uc1701.c
deleted file mode 100644
index b78045fe5393..000000000000
diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c
deleted file mode 100644
index 970b8430eccf..000000000000
diff --git a/drivers/staging/fbtft/fb_watterott.c b/drivers/staging/fbtft/fb_watterott.c
deleted file mode 100644
index a52e28a48825..000000000000
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
deleted file mode 100644
index ec45043c0830..000000000000
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
deleted file mode 100644
index 587f68aa466c..000000000000
diff --git a/drivers/staging/fbtft/fbtft-io.c b/drivers/staging/fbtft/fbtft-io.c
deleted file mode 100644
index 4dcea2e0b3ae..000000000000
diff --git a/drivers/staging/fbtft/fbtft-sysfs.c b/drivers/staging/fbtft/fbtft-sysfs.c
deleted file mode 100644
index 8d8bd12b90a1..000000000000
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
deleted file mode 100644
index 89c4b5b76ce6..000000000000
diff --git a/drivers/staging/fbtft/fbtft_device.c b/drivers/staging/fbtft/fbtft_device.c
deleted file mode 100644
index e9211831b6a1..000000000000
diff --git a/drivers/staging/fbtft/flexfb.c b/drivers/staging/fbtft/flexfb.c
deleted file mode 100644
index ce0d254148e4..000000000000
diff --git a/drivers/staging/fbtft/internal.h b/drivers/staging/fbtft/internal.h
deleted file mode 100644
index eea0ec5ff4d3..000000000000
--
2.7.4
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [RFC PATCH 3/3] staging: remove fbtft
2016-11-23 8:03 ` [RFC PATCH 3/3] staging: remove fbtft Tomi Valkeinen
@ 2016-11-23 17:26 ` Noralf Trønnes
2016-11-24 8:36 ` Tomi Valkeinen
2016-11-23 20:12 ` Drew Fustini
1 sibling, 1 reply; 54+ messages in thread
From: Noralf Trønnes @ 2016-11-23 17:26 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Sudip Mukherjee, Teddy Wang, Arnaud Patard
Cc: linux-kernel
Den 23.11.2016 09:03, skrev Tomi Valkeinen:
> Since the fbdev framework is in maintenance mode and all new display
> drivers should be made with the DRM framework, remove fbtft from
> staging.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
FYI:
I'm working on a drm version of fbtft: https://github.com/notro/tinydrm
I have just picked it up after a 4 month break.
It is ready for a new review, except that I want to test how it would
perform as a drm userspace driver first (for spi that would mean adding
dma-buf support to spidev). If this performs well, then all the fbtft
drivers could move to userspace. If it doesn't, then at least (very slow)
i2c and e-ink displays could be userspace drivers.
Noralf.
> ---
> MAINTAINERS | 6 -
> drivers/staging/Kconfig | 2 -
> drivers/staging/Makefile | 1 -
> drivers/staging/fbtft/Kconfig | 210 -----
> drivers/staging/fbtft/Makefile | 40 -
> drivers/staging/fbtft/README | 32 -
> drivers/staging/fbtft/fb_agm1264k-fl.c | 456 ---------
> drivers/staging/fbtft/fb_bd663474.c | 184 ----
> drivers/staging/fbtft/fb_hx8340bn.c | 234 -----
> drivers/staging/fbtft/fb_hx8347d.c | 169 ----
> drivers/staging/fbtft/fb_hx8353d.c | 157 ----
> drivers/staging/fbtft/fb_hx8357d.c | 210 -----
> drivers/staging/fbtft/fb_hx8357d.h | 70 --
> drivers/staging/fbtft/fb_ili9163.c | 273 ------
> drivers/staging/fbtft/fb_ili9320.c | 278 ------
> drivers/staging/fbtft/fb_ili9325.c | 277 ------
> drivers/staging/fbtft/fb_ili9340.c | 149 ---
> drivers/staging/fbtft/fb_ili9341.c | 166 ----
> drivers/staging/fbtft/fb_ili9481.c | 112 ---
> drivers/staging/fbtft/fb_ili9486.c | 112 ---
> drivers/staging/fbtft/fb_pcd8544.c | 176 ----
> drivers/staging/fbtft/fb_ra8875.c | 318 -------
> drivers/staging/fbtft/fb_s6d02a1.c | 166 ----
> drivers/staging/fbtft/fb_s6d1121.c | 194 ----
> drivers/staging/fbtft/fb_ssd1289.c | 191 ----
> drivers/staging/fbtft/fb_ssd1305.c | 216 -----
> drivers/staging/fbtft/fb_ssd1306.c | 217 -----
> drivers/staging/fbtft/fb_ssd1325.c | 205 ----
> drivers/staging/fbtft/fb_ssd1331.c | 196 ----
> drivers/staging/fbtft/fb_ssd1351.c | 238 -----
> drivers/staging/fbtft/fb_st7735r.c | 190 ----
> drivers/staging/fbtft/fb_st7789v.c | 265 ------
> drivers/staging/fbtft/fb_tinylcd.c | 112 ---
> drivers/staging/fbtft/fb_tls8204.c | 169 ----
> drivers/staging/fbtft/fb_uc1611.c | 340 -------
> drivers/staging/fbtft/fb_uc1701.c | 179 ----
> drivers/staging/fbtft/fb_upd161704.c | 197 ----
> drivers/staging/fbtft/fb_watterott.c | 302 ------
> drivers/staging/fbtft/fbtft-bus.c | 252 -----
> drivers/staging/fbtft/fbtft-core.c | 1467 -----------------------------
> drivers/staging/fbtft/fbtft-io.c | 238 -----
> drivers/staging/fbtft/fbtft-sysfs.c | 219 -----
> drivers/staging/fbtft/fbtft.h | 421 ---------
> drivers/staging/fbtft/fbtft_device.c | 1597 --------------------------------
> drivers/staging/fbtft/flexfb.c | 619 -------------
> drivers/staging/fbtft/internal.h | 25 -
> 46 files changed, 11847 deletions(-)
> delete mode 100644 drivers/staging/fbtft/Kconfig
> delete mode 100644 drivers/staging/fbtft/Makefile
> delete mode 100644 drivers/staging/fbtft/README
> delete mode 100644 drivers/staging/fbtft/fb_agm1264k-fl.c
> delete mode 100644 drivers/staging/fbtft/fb_bd663474.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8340bn.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8347d.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8353d.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8357d.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8357d.h
> delete mode 100644 drivers/staging/fbtft/fb_ili9163.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9320.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9325.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9340.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9341.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9481.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9486.c
> delete mode 100644 drivers/staging/fbtft/fb_pcd8544.c
> delete mode 100644 drivers/staging/fbtft/fb_ra8875.c
> delete mode 100644 drivers/staging/fbtft/fb_s6d02a1.c
> delete mode 100644 drivers/staging/fbtft/fb_s6d1121.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1289.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1305.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1306.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1325.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1331.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1351.c
> delete mode 100644 drivers/staging/fbtft/fb_st7735r.c
> delete mode 100644 drivers/staging/fbtft/fb_st7789v.c
> delete mode 100644 drivers/staging/fbtft/fb_tinylcd.c
> delete mode 100644 drivers/staging/fbtft/fb_tls8204.c
> delete mode 100644 drivers/staging/fbtft/fb_uc1611.c
> delete mode 100644 drivers/staging/fbtft/fb_uc1701.c
> delete mode 100644 drivers/staging/fbtft/fb_upd161704.c
> delete mode 100644 drivers/staging/fbtft/fb_watterott.c
> delete mode 100644 drivers/staging/fbtft/fbtft-bus.c
> delete mode 100644 drivers/staging/fbtft/fbtft-core.c
> delete mode 100644 drivers/staging/fbtft/fbtft-io.c
> delete mode 100644 drivers/staging/fbtft/fbtft-sysfs.c
> delete mode 100644 drivers/staging/fbtft/fbtft.h
> delete mode 100644 drivers/staging/fbtft/fbtft_device.c
> delete mode 100644 drivers/staging/fbtft/flexfb.c
> delete mode 100644 drivers/staging/fbtft/internal.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 772330b38212..466a86a3b2fc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4839,12 +4839,6 @@ S: Supported
> F: Documentation/fault-injection/
> F: lib/fault-inject.c
>
> -FBTFT Framebuffer drivers
> -M: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> -M: Noralf Trønnes <noralf@tronnes.org>
> -S: Maintained
> -F: drivers/staging/fbtft/
> -
> FCOE SUBSYSTEM (libfc, libfcoe, fcoe)
> M: Johannes Thumshirn <jth@kernel.org>
> L: fcoe-devel@open-fcoe.org
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index fcfe8fcea441..69a62eac7bbf 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -86,8 +86,6 @@ source "drivers/staging/unisys/Kconfig"
>
> source "drivers/staging/clocking-wizard/Kconfig"
>
> -source "drivers/staging/fbtft/Kconfig"
> -
> source "drivers/staging/fsl-mc/Kconfig"
>
> source "drivers/staging/wilc1000/Kconfig"
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index 585eb34020a1..33a768c0942d 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -32,7 +32,6 @@ obj-$(CONFIG_GS_FPGABOOT) += gs_fpgaboot/
> obj-$(CONFIG_CRYPTO_SKEIN) += skein/
> obj-$(CONFIG_UNISYSSPAR) += unisys/
> obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clocking-wizard/
> -obj-$(CONFIG_FB_TFT) += fbtft/
> obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
> obj-$(CONFIG_WILC1000) += wilc1000/
> obj-$(CONFIG_MOST) += most/
> diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
> deleted file mode 100644
> index 6f5e82464d78..000000000000
> diff --git a/drivers/staging/fbtft/Makefile b/drivers/staging/fbtft/Makefile
> deleted file mode 100644
> index 2725ea9a4afc..000000000000
> diff --git a/drivers/staging/fbtft/README b/drivers/staging/fbtft/README
> deleted file mode 100644
> index ba4c74c92e4c..000000000000
> diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c
> deleted file mode 100644
> index 7561385761e9..000000000000
> diff --git a/drivers/staging/fbtft/fb_bd663474.c b/drivers/staging/fbtft/fb_bd663474.c
> deleted file mode 100644
> index 6010e6cbbd72..000000000000
> diff --git a/drivers/staging/fbtft/fb_hx8340bn.c b/drivers/staging/fbtft/fb_hx8340bn.c
> deleted file mode 100644
> index 9970ed74bb38..000000000000
> diff --git a/drivers/staging/fbtft/fb_hx8347d.c b/drivers/staging/fbtft/fb_hx8347d.c
> deleted file mode 100644
> index 450a61e3f99c..000000000000
> diff --git a/drivers/staging/fbtft/fb_hx8353d.c b/drivers/staging/fbtft/fb_hx8353d.c
> deleted file mode 100644
> index 72e4ff8c5553..000000000000
> diff --git a/drivers/staging/fbtft/fb_hx8357d.c b/drivers/staging/fbtft/fb_hx8357d.c
> deleted file mode 100644
> index 32e6efe1d0a7..000000000000
> diff --git a/drivers/staging/fbtft/fb_hx8357d.h b/drivers/staging/fbtft/fb_hx8357d.h
> deleted file mode 100644
> index e281921d4a97..000000000000
> diff --git a/drivers/staging/fbtft/fb_ili9163.c b/drivers/staging/fbtft/fb_ili9163.c
> deleted file mode 100644
> index 6b8f8b17e9a3..000000000000
> diff --git a/drivers/staging/fbtft/fb_ili9320.c b/drivers/staging/fbtft/fb_ili9320.c
> deleted file mode 100644
> index 278e4c7e95e5..000000000000
> diff --git a/drivers/staging/fbtft/fb_ili9325.c b/drivers/staging/fbtft/fb_ili9325.c
> deleted file mode 100644
> index c31e2e051d4a..000000000000
> diff --git a/drivers/staging/fbtft/fb_ili9340.c b/drivers/staging/fbtft/fb_ili9340.c
> deleted file mode 100644
> index 0711121c303c..000000000000
> diff --git a/drivers/staging/fbtft/fb_ili9341.c b/drivers/staging/fbtft/fb_ili9341.c
> deleted file mode 100644
> index ff35c8624ca3..000000000000
> diff --git a/drivers/staging/fbtft/fb_ili9481.c b/drivers/staging/fbtft/fb_ili9481.c
> deleted file mode 100644
> index 242adb3859bd..000000000000
> diff --git a/drivers/staging/fbtft/fb_ili9486.c b/drivers/staging/fbtft/fb_ili9486.c
> deleted file mode 100644
> index fa38d8885f0b..000000000000
> diff --git a/drivers/staging/fbtft/fb_pcd8544.c b/drivers/staging/fbtft/fb_pcd8544.c
> deleted file mode 100644
> index a4710dc067ef..000000000000
> diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
> deleted file mode 100644
> index 308a244972aa..000000000000
> diff --git a/drivers/staging/fbtft/fb_s6d02a1.c b/drivers/staging/fbtft/fb_s6d02a1.c
> deleted file mode 100644
> index 774b0ff69e6d..000000000000
> diff --git a/drivers/staging/fbtft/fb_s6d1121.c b/drivers/staging/fbtft/fb_s6d1121.c
> deleted file mode 100644
> index 9b1d70b218df..000000000000
> diff --git a/drivers/staging/fbtft/fb_ssd1289.c b/drivers/staging/fbtft/fb_ssd1289.c
> deleted file mode 100644
> index 25f9fbe1e76f..000000000000
> diff --git a/drivers/staging/fbtft/fb_ssd1305.c b/drivers/staging/fbtft/fb_ssd1305.c
> deleted file mode 100644
> index 4b38c3fadd60..000000000000
> diff --git a/drivers/staging/fbtft/fb_ssd1306.c b/drivers/staging/fbtft/fb_ssd1306.c
> deleted file mode 100644
> index 80fc57029fee..000000000000
> diff --git a/drivers/staging/fbtft/fb_ssd1325.c b/drivers/staging/fbtft/fb_ssd1325.c
> deleted file mode 100644
> index 15078bf2aa4b..000000000000
> diff --git a/drivers/staging/fbtft/fb_ssd1331.c b/drivers/staging/fbtft/fb_ssd1331.c
> deleted file mode 100644
> index 1d74ac1343a8..000000000000
> diff --git a/drivers/staging/fbtft/fb_ssd1351.c b/drivers/staging/fbtft/fb_ssd1351.c
> deleted file mode 100644
> index 200aa9ba98f9..000000000000
> diff --git a/drivers/staging/fbtft/fb_st7735r.c b/drivers/staging/fbtft/fb_st7735r.c
> deleted file mode 100644
> index 6670f2bb62ec..000000000000
> diff --git a/drivers/staging/fbtft/fb_st7789v.c b/drivers/staging/fbtft/fb_st7789v.c
> deleted file mode 100644
> index 085e9872c46d..000000000000
> diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
> deleted file mode 100644
> index 097e71cfef62..000000000000
> diff --git a/drivers/staging/fbtft/fb_tls8204.c b/drivers/staging/fbtft/fb_tls8204.c
> deleted file mode 100644
> index ea2ddacb9468..000000000000
> diff --git a/drivers/staging/fbtft/fb_uc1611.c b/drivers/staging/fbtft/fb_uc1611.c
> deleted file mode 100644
> index b33b73f17da4..000000000000
> diff --git a/drivers/staging/fbtft/fb_uc1701.c b/drivers/staging/fbtft/fb_uc1701.c
> deleted file mode 100644
> index b78045fe5393..000000000000
> diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c
> deleted file mode 100644
> index 970b8430eccf..000000000000
> diff --git a/drivers/staging/fbtft/fb_watterott.c b/drivers/staging/fbtft/fb_watterott.c
> deleted file mode 100644
> index a52e28a48825..000000000000
> diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
> deleted file mode 100644
> index ec45043c0830..000000000000
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> deleted file mode 100644
> index 587f68aa466c..000000000000
> diff --git a/drivers/staging/fbtft/fbtft-io.c b/drivers/staging/fbtft/fbtft-io.c
> deleted file mode 100644
> index 4dcea2e0b3ae..000000000000
> diff --git a/drivers/staging/fbtft/fbtft-sysfs.c b/drivers/staging/fbtft/fbtft-sysfs.c
> deleted file mode 100644
> index 8d8bd12b90a1..000000000000
> diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
> deleted file mode 100644
> index 89c4b5b76ce6..000000000000
> diff --git a/drivers/staging/fbtft/fbtft_device.c b/drivers/staging/fbtft/fbtft_device.c
> deleted file mode 100644
> index e9211831b6a1..000000000000
> diff --git a/drivers/staging/fbtft/flexfb.c b/drivers/staging/fbtft/flexfb.c
> deleted file mode 100644
> index ce0d254148e4..000000000000
> diff --git a/drivers/staging/fbtft/internal.h b/drivers/staging/fbtft/internal.h
> deleted file mode 100644
> index eea0ec5ff4d3..000000000000
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft
2016-11-23 17:26 ` Noralf Trønnes
@ 2016-11-24 8:36 ` Tomi Valkeinen
0 siblings, 0 replies; 54+ messages in thread
From: Tomi Valkeinen @ 2016-11-24 8:36 UTC (permalink / raw)
To: Noralf Trønnes, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Sudip Mukherjee, Teddy Wang, Arnaud Patard
Cc: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 924 bytes --]
On 23/11/16 19:26, Noralf Trønnes wrote:
>
> Den 23.11.2016 09:03, skrev Tomi Valkeinen:
>> Since the fbdev framework is in maintenance mode and all new display
>> drivers should be made with the DRM framework, remove fbtft from
>> staging.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> FYI:
> I'm working on a drm version of fbtft: https://github.com/notro/tinydrm
> I have just picked it up after a 4 month break.
>
> It is ready for a new review, except that I want to test how it would
> perform as a drm userspace driver first (for spi that would mean adding
> dma-buf support to spidev). If this performs well, then all the fbtft
> drivers could move to userspace. If it doesn't, then at least (very slow)
> i2c and e-ink displays could be userspace drivers.
Alright, sounds good to me.
So let's keep the staging fbdev drivers there until we have replacements.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft
2016-11-23 8:03 ` [RFC PATCH 3/3] staging: remove fbtft Tomi Valkeinen
2016-11-23 17:26 ` Noralf Trønnes
@ 2016-11-23 20:12 ` Drew Fustini
1 sibling, 0 replies; 54+ messages in thread
From: Drew Fustini @ 2016-11-23 20:12 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, dri-devel, Greg Kroah-Hartman, Thomas Petazzoni,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard,
linux-kernel, Jason Kridner, Robert Nelson, Tony DiCola,
Jason Kridner
On Wed, Nov 23, 2016 at 2:03 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Since the fbdev framework is in maintenance mode and all new display
> drivers should be made with the DRM framework, remove fbtft from
> staging.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
I'd request that fbtft please be kept in staging until a successor is
ready, such as Noralf's tinydrm.
fbtft is a popular way to connect small TFT LCDs over SPI to single
board computers like BeagleBone and Raspberry Pi. It became simpler
for users to get fbtft drivers working once Thomas Petazzoni added it
to staging at the end of 2014. I would like to avoid going back to
the scenario where the fbtft drivers have to be added as a patch
before compiling the kernel.
thanks,
drew
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 8:03 [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen
` (2 preceding siblings ...)
2016-11-23 8:03 ` [RFC PATCH 3/3] staging: remove fbtft Tomi Valkeinen
@ 2016-11-23 8:19 ` Daniel Vetter
2016-11-23 8:21 ` Tomi Valkeinen
2016-11-23 8:25 ` Geert Uytterhoeven
2016-11-23 8:52 ` Greg Kroah-Hartman
2016-12-08 1:01 ` Benjamin Herrenschmidt
5 siblings, 2 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-11-23 8:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, dri-devel, Greg Kroah-Hartman, Thomas Petazzoni,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard,
linux-kernel
On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
> Hi,
>
> Since the fbdev framework is in maintenance mode and all new display drivers
> should be made with the DRM framework, remove the fbdev drivers from staging.
>
> Note: the patches are created with git format-patch -D, so they can't be
> applied. Only for review.
+1 from my side. Now that we have the simple pipe helpers in drm-kms, and
a few drivers starting to use them, there's really no reasons left anymore
to have fbdev drivers.
And if anyone wants to use the code as hw documentation, git will keep it
forever.
-Daniel
>
> Tomi
>
> Tomi Valkeinen (3):
> staging: remove xgifb
> staging: remove sm750fb
> staging: remove fbtft
>
> MAINTAINERS | 19 -
> drivers/staging/Kconfig | 6 -
> drivers/staging/Makefile | 3 -
> drivers/staging/fbtft/Kconfig | 210 --
> drivers/staging/fbtft/Makefile | 40 -
> drivers/staging/fbtft/README | 32 -
> drivers/staging/fbtft/fb_agm1264k-fl.c | 456 ---
> drivers/staging/fbtft/fb_bd663474.c | 184 -
> drivers/staging/fbtft/fb_hx8340bn.c | 234 --
> drivers/staging/fbtft/fb_hx8347d.c | 169 -
> drivers/staging/fbtft/fb_hx8353d.c | 157 -
> drivers/staging/fbtft/fb_hx8357d.c | 210 --
> drivers/staging/fbtft/fb_hx8357d.h | 70 -
> drivers/staging/fbtft/fb_ili9163.c | 273 --
> drivers/staging/fbtft/fb_ili9320.c | 278 --
> drivers/staging/fbtft/fb_ili9325.c | 277 --
> drivers/staging/fbtft/fb_ili9340.c | 149 -
> drivers/staging/fbtft/fb_ili9341.c | 166 -
> drivers/staging/fbtft/fb_ili9481.c | 112 -
> drivers/staging/fbtft/fb_ili9486.c | 112 -
> drivers/staging/fbtft/fb_pcd8544.c | 176 -
> drivers/staging/fbtft/fb_ra8875.c | 318 --
> drivers/staging/fbtft/fb_s6d02a1.c | 166 -
> drivers/staging/fbtft/fb_s6d1121.c | 194 --
> drivers/staging/fbtft/fb_ssd1289.c | 191 --
> drivers/staging/fbtft/fb_ssd1305.c | 216 --
> drivers/staging/fbtft/fb_ssd1306.c | 217 --
> drivers/staging/fbtft/fb_ssd1325.c | 205 --
> drivers/staging/fbtft/fb_ssd1331.c | 196 --
> drivers/staging/fbtft/fb_ssd1351.c | 238 --
> drivers/staging/fbtft/fb_st7735r.c | 190 -
> drivers/staging/fbtft/fb_st7789v.c | 265 --
> drivers/staging/fbtft/fb_tinylcd.c | 112 -
> drivers/staging/fbtft/fb_tls8204.c | 169 -
> drivers/staging/fbtft/fb_uc1611.c | 340 --
> drivers/staging/fbtft/fb_uc1701.c | 179 -
> drivers/staging/fbtft/fb_upd161704.c | 197 --
> drivers/staging/fbtft/fb_watterott.c | 302 --
> drivers/staging/fbtft/fbtft-bus.c | 252 --
> drivers/staging/fbtft/fbtft-core.c | 1467 --------
> drivers/staging/fbtft/fbtft-io.c | 238 --
> drivers/staging/fbtft/fbtft-sysfs.c | 219 --
> drivers/staging/fbtft/fbtft.h | 421 ---
> drivers/staging/fbtft/fbtft_device.c | 1597 ---------
> drivers/staging/fbtft/flexfb.c | 619 ----
> drivers/staging/fbtft/internal.h | 25 -
> drivers/staging/sm750fb/Kconfig | 14 -
> drivers/staging/sm750fb/Makefile | 4 -
> drivers/staging/sm750fb/TODO | 16 -
> drivers/staging/sm750fb/ddk750.h | 24 -
> drivers/staging/sm750fb/ddk750_chip.c | 403 ---
> drivers/staging/sm750fb/ddk750_chip.h | 79 -
> drivers/staging/sm750fb/ddk750_display.c | 186 -
> drivers/staging/sm750fb/ddk750_display.h | 102 -
> drivers/staging/sm750fb/ddk750_dvi.c | 60 -
> drivers/staging/sm750fb/ddk750_dvi.h | 59 -
> drivers/staging/sm750fb/ddk750_help.c | 17 -
> drivers/staging/sm750fb/ddk750_help.h | 21 -
> drivers/staging/sm750fb/ddk750_hwi2c.c | 254 --
> drivers/staging/sm750fb/ddk750_hwi2c.h | 11 -
> drivers/staging/sm750fb/ddk750_mode.c | 220 --
> drivers/staging/sm750fb/ddk750_mode.h | 41 -
> drivers/staging/sm750fb/ddk750_power.c | 165 -
> drivers/staging/sm750fb/ddk750_power.h | 50 -
> drivers/staging/sm750fb/ddk750_reg.h | 1458 --------
> drivers/staging/sm750fb/ddk750_sii164.c | 410 ---
> drivers/staging/sm750fb/ddk750_sii164.h | 174 -
> drivers/staging/sm750fb/ddk750_swi2c.c | 516 ---
> drivers/staging/sm750fb/ddk750_swi2c.h | 71 -
> drivers/staging/sm750fb/readme | 38 -
> drivers/staging/sm750fb/sm750.c | 1248 -------
> drivers/staging/sm750fb/sm750.h | 202 --
> drivers/staging/sm750fb/sm750_accel.c | 388 ---
> drivers/staging/sm750fb/sm750_accel.h | 225 --
> drivers/staging/sm750fb/sm750_cursor.c | 183 -
> drivers/staging/sm750fb/sm750_cursor.h | 17 -
> drivers/staging/sm750fb/sm750_hw.c | 557 ---
> drivers/staging/xgifb/Kconfig | 11 -
> drivers/staging/xgifb/Makefile | 4 -
> drivers/staging/xgifb/TODO | 13 -
> drivers/staging/xgifb/XGI_main.h | 377 --
> drivers/staging/xgifb/XGI_main_26.c | 2100 ------------
> drivers/staging/xgifb/XGIfb.h | 108 -
> drivers/staging/xgifb/vb_def.h | 256 --
> drivers/staging/xgifb/vb_init.c | 1363 --------
> drivers/staging/xgifb/vb_init.h | 6 -
> drivers/staging/xgifb/vb_setmode.c | 5529 ------------------------------
> drivers/staging/xgifb/vb_setmode.h | 23 -
> drivers/staging/xgifb/vb_struct.h | 164 -
> drivers/staging/xgifb/vb_table.h | 2511 --------------
> drivers/staging/xgifb/vb_util.h | 45 -
> drivers/staging/xgifb/vgatypes.h | 50 -
> 92 files changed, 31639 deletions(-)
> delete mode 100644 drivers/staging/fbtft/Kconfig
> delete mode 100644 drivers/staging/fbtft/Makefile
> delete mode 100644 drivers/staging/fbtft/README
> delete mode 100644 drivers/staging/fbtft/fb_agm1264k-fl.c
> delete mode 100644 drivers/staging/fbtft/fb_bd663474.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8340bn.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8347d.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8353d.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8357d.c
> delete mode 100644 drivers/staging/fbtft/fb_hx8357d.h
> delete mode 100644 drivers/staging/fbtft/fb_ili9163.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9320.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9325.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9340.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9341.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9481.c
> delete mode 100644 drivers/staging/fbtft/fb_ili9486.c
> delete mode 100644 drivers/staging/fbtft/fb_pcd8544.c
> delete mode 100644 drivers/staging/fbtft/fb_ra8875.c
> delete mode 100644 drivers/staging/fbtft/fb_s6d02a1.c
> delete mode 100644 drivers/staging/fbtft/fb_s6d1121.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1289.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1305.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1306.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1325.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1331.c
> delete mode 100644 drivers/staging/fbtft/fb_ssd1351.c
> delete mode 100644 drivers/staging/fbtft/fb_st7735r.c
> delete mode 100644 drivers/staging/fbtft/fb_st7789v.c
> delete mode 100644 drivers/staging/fbtft/fb_tinylcd.c
> delete mode 100644 drivers/staging/fbtft/fb_tls8204.c
> delete mode 100644 drivers/staging/fbtft/fb_uc1611.c
> delete mode 100644 drivers/staging/fbtft/fb_uc1701.c
> delete mode 100644 drivers/staging/fbtft/fb_upd161704.c
> delete mode 100644 drivers/staging/fbtft/fb_watterott.c
> delete mode 100644 drivers/staging/fbtft/fbtft-bus.c
> delete mode 100644 drivers/staging/fbtft/fbtft-core.c
> delete mode 100644 drivers/staging/fbtft/fbtft-io.c
> delete mode 100644 drivers/staging/fbtft/fbtft-sysfs.c
> delete mode 100644 drivers/staging/fbtft/fbtft.h
> delete mode 100644 drivers/staging/fbtft/fbtft_device.c
> delete mode 100644 drivers/staging/fbtft/flexfb.c
> delete mode 100644 drivers/staging/fbtft/internal.h
> delete mode 100644 drivers/staging/sm750fb/Kconfig
> delete mode 100644 drivers/staging/sm750fb/Makefile
> delete mode 100644 drivers/staging/sm750fb/TODO
> delete mode 100644 drivers/staging/sm750fb/ddk750.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_chip.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_chip.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_display.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_display.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_dvi.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_dvi.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_help.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_help.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_hwi2c.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_hwi2c.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_mode.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_mode.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_power.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_power.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_reg.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_sii164.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_sii164.h
> delete mode 100644 drivers/staging/sm750fb/ddk750_swi2c.c
> delete mode 100644 drivers/staging/sm750fb/ddk750_swi2c.h
> delete mode 100644 drivers/staging/sm750fb/readme
> delete mode 100644 drivers/staging/sm750fb/sm750.c
> delete mode 100644 drivers/staging/sm750fb/sm750.h
> delete mode 100644 drivers/staging/sm750fb/sm750_accel.c
> delete mode 100644 drivers/staging/sm750fb/sm750_accel.h
> delete mode 100644 drivers/staging/sm750fb/sm750_cursor.c
> delete mode 100644 drivers/staging/sm750fb/sm750_cursor.h
> delete mode 100644 drivers/staging/sm750fb/sm750_hw.c
> delete mode 100644 drivers/staging/xgifb/Kconfig
> delete mode 100644 drivers/staging/xgifb/Makefile
> delete mode 100644 drivers/staging/xgifb/TODO
> delete mode 100644 drivers/staging/xgifb/XGI_main.h
> delete mode 100644 drivers/staging/xgifb/XGI_main_26.c
> delete mode 100644 drivers/staging/xgifb/XGIfb.h
> delete mode 100644 drivers/staging/xgifb/vb_def.h
> delete mode 100644 drivers/staging/xgifb/vb_init.c
> delete mode 100644 drivers/staging/xgifb/vb_init.h
> delete mode 100644 drivers/staging/xgifb/vb_setmode.c
> delete mode 100644 drivers/staging/xgifb/vb_setmode.h
> delete mode 100644 drivers/staging/xgifb/vb_struct.h
> delete mode 100644 drivers/staging/xgifb/vb_table.h
> delete mode 100644 drivers/staging/xgifb/vb_util.h
> delete mode 100644 drivers/staging/xgifb/vgatypes.h
>
> --
> 2.7.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 8:19 ` [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter
@ 2016-11-23 8:21 ` Tomi Valkeinen
2016-11-23 8:25 ` Geert Uytterhoeven
1 sibling, 0 replies; 54+ messages in thread
From: Tomi Valkeinen @ 2016-11-23 8:21 UTC (permalink / raw)
To: linux-fbdev, dri-devel, Greg Kroah-Hartman, Thomas Petazzoni,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard,
linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 703 bytes --]
On 23/11/16 10:19, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> Since the fbdev framework is in maintenance mode and all new display drivers
>> should be made with the DRM framework, remove the fbdev drivers from staging.
>>
>> Note: the patches are created with git format-patch -D, so they can't be
>> applied. Only for review.
>
> +1 from my side. Now that we have the simple pipe helpers in drm-kms, and
> a few drivers starting to use them, there's really no reasons left anymore
> to have fbdev drivers.
Well, I think there's the MMU problem. If I recall right, someone said
DRM doesn't compile/work without MMU.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 8:19 ` [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter
2016-11-23 8:21 ` Tomi Valkeinen
@ 2016-11-23 8:25 ` Geert Uytterhoeven
2016-11-23 8:45 ` Daniel Vetter
1 sibling, 1 reply; 54+ messages in thread
From: Geert Uytterhoeven @ 2016-11-23 8:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: Arnaud Patard, linux-kernel, Sudip Mukherjee,
Noralf Trønnes, Teddy Wang, Greg Kroah-Hartman,
DRI Development, Thomas Petazzoni, Linux Fbdev development list,
Tomi Valkeinen
Hi Daniel,
On Wed, Nov 23, 2016 at 9:19 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
>> Since the fbdev framework is in maintenance mode and all new display drivers
>> should be made with the DRM framework, remove the fbdev drivers from staging.
>>
>> Note: the patches are created with git format-patch -D, so they can't be
>> applied. Only for review.
>
> +1 from my side. Now that we have the simple pipe helpers in drm-kms, and
> a few drivers starting to use them, there's really no reasons left anymore
> to have fbdev drivers.
I haven't been following this that closely, so can you please point me to a
sample DRM driver using this simple pipe helper?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 8:25 ` Geert Uytterhoeven
@ 2016-11-23 8:45 ` Daniel Vetter
0 siblings, 0 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-11-23 8:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnaud Patard, linux-kernel, Sudip Mukherjee,
Noralf Trønnes, Teddy Wang, Greg Kroah-Hartman,
DRI Development, Thomas Petazzoni, Linux Fbdev development list,
Tomi Valkeinen
On Wed, Nov 23, 2016 at 9:25 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Daniel,
>
> On Wed, Nov 23, 2016 at 9:19 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
>>> Since the fbdev framework is in maintenance mode and all new display drivers
>>> should be made with the DRM framework, remove the fbdev drivers from staging.
>>>
>>> Note: the patches are created with git format-patch -D, so they can't be
>>> applied. Only for review.
>>
>> +1 from my side. Now that we have the simple pipe helpers in drm-kms, and
>> a few drivers starting to use them, there's really no reasons left anymore
>> to have fbdev drivers.
>
> I haven't been following this that closely, so can you please point me to a
> sample DRM driver using this simple pipe helper?
Bummer, they still haven't landed. But afaik there's at least 4 of
them floating around in various places ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 8:03 [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen
` (3 preceding siblings ...)
2016-11-23 8:19 ` [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter
@ 2016-11-23 8:52 ` Greg Kroah-Hartman
2016-11-23 9:12 ` Tomi Valkeinen
2016-12-08 1:01 ` Benjamin Herrenschmidt
5 siblings, 1 reply; 54+ messages in thread
From: Greg Kroah-Hartman @ 2016-11-23 8:52 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, linux-kernel
On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
> Hi,
>
> Since the fbdev framework is in maintenance mode and all new display drivers
> should be made with the DRM framework, remove the fbdev drivers from staging.
>
> Note: the patches are created with git format-patch -D, so they can't be
> applied. Only for review.
I only want to remove these drivers if we have the same functionality in
mainline for their hardware. If not, that's a bit rude to those who
actually use them today, don't you think?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 8:52 ` Greg Kroah-Hartman
@ 2016-11-23 9:12 ` Tomi Valkeinen
2016-11-23 9:49 ` Greg Kroah-Hartman
` (2 more replies)
0 siblings, 3 replies; 54+ messages in thread
From: Tomi Valkeinen @ 2016-11-23 9:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1277 bytes --]
On 23/11/16 10:52, Greg Kroah-Hartman wrote:
> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> Since the fbdev framework is in maintenance mode and all new display drivers
>> should be made with the DRM framework, remove the fbdev drivers from staging.
>>
>> Note: the patches are created with git format-patch -D, so they can't be
>> applied. Only for review.
>
> I only want to remove these drivers if we have the same functionality in
> mainline for their hardware. If not, that's a bit rude to those who
> actually use them today, don't you think?
What does it mean for a driver to be in staging? I thought it's
basically the same as the driver being out-of-tree, with the difference
that the code is in a central git repository for easier co-operation.
If that's what staging means, then I would reject the staging fbdev
drivers the same way as I'd reject new fbdev drivers sent as patches to
the list.
Or do you mean that we should keep the drivers in staging until there's
a matching DRM driver, but drop any plans to move the drivers from
staging to drivers/video/? If so, I'm fine with that. This is an RFC,
mostly to raise some discussion and push people to actually write those
DRM drivers =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 9:12 ` Tomi Valkeinen
@ 2016-11-23 9:49 ` Greg Kroah-Hartman
2016-11-23 10:05 ` Thomas Petazzoni
2016-12-08 22:00 ` Sudip Mukherjee
2 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2016-11-23 9:49 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, linux-kernel
On Wed, Nov 23, 2016 at 11:12:32AM +0200, Tomi Valkeinen wrote:
> On 23/11/16 10:52, Greg Kroah-Hartman wrote:
> > On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> Since the fbdev framework is in maintenance mode and all new display drivers
> >> should be made with the DRM framework, remove the fbdev drivers from staging.
> >>
> >> Note: the patches are created with git format-patch -D, so they can't be
> >> applied. Only for review.
> >
> > I only want to remove these drivers if we have the same functionality in
> > mainline for their hardware. If not, that's a bit rude to those who
> > actually use them today, don't you think?
>
> What does it mean for a driver to be in staging? I thought it's
> basically the same as the driver being out-of-tree, with the difference
> that the code is in a central git repository for easier co-operation.
Yes, but it also allows people to use their hardware, for drivers that
are not "quite ready".
> If that's what staging means, then I would reject the staging fbdev
> drivers the same way as I'd reject new fbdev drivers sent as patches to
> the list.
Rejecting valid drivers for hardware that people have today is not a
nice thing. If you want to just move them into staging so that people
can get their hardware working while people port to the new apis, I will
be glad to take them.
> Or do you mean that we should keep the drivers in staging until there's
> a matching DRM driver, but drop any plans to move the drivers from
> staging to drivers/video/? If so, I'm fine with that. This is an RFC,
> mostly to raise some discussion and push people to actually write those
> DRM drivers =).
I do not want to move these to drivers/video/ and they should just stay
where they are until a matching DRM driver is present in the tree.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 9:12 ` Tomi Valkeinen
2016-11-23 9:49 ` Greg Kroah-Hartman
@ 2016-11-23 10:05 ` Thomas Petazzoni
2016-12-22 20:36 ` Andy Shevchenko
2016-12-08 22:00 ` Sudip Mukherjee
2 siblings, 1 reply; 54+ messages in thread
From: Thomas Petazzoni @ 2016-11-23 10:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Greg Kroah-Hartman, linux-fbdev, dri-devel, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, linux-kernel
Hello,
On Wed, 23 Nov 2016 11:12:32 +0200, Tomi Valkeinen wrote:
> > I only want to remove these drivers if we have the same functionality in
> > mainline for their hardware. If not, that's a bit rude to those who
> > actually use them today, don't you think?
>
> What does it mean for a driver to be in staging? I thought it's
> basically the same as the driver being out-of-tree, with the difference
> that the code is in a central git repository for easier co-operation.
>
> If that's what staging means, then I would reject the staging fbdev
> drivers the same way as I'd reject new fbdev drivers sent as patches to
> the list.
>
> Or do you mean that we should keep the drivers in staging until there's
> a matching DRM driver, but drop any plans to move the drivers from
> staging to drivers/video/? If so, I'm fine with that. This is an RFC,
> mostly to raise some discussion and push people to actually write those
> DRM drivers =).
The very reason why I submitted those drivers for staging is because
lots and lots of people were using out of tree kernel modules for these
drivers, which was really a pain.
If you now remove those drivers from staging, then those folks will be
back in the situation they originally were, using annoying out of tree
modules.
I'm all for removing fbtft drivers progressively as a matching
DRM-based driver is available for the same hardware. However, if there
is no DRM-based support for a given piece of hardware supported by
fbtft, I'd prefer if we kept the fbtft driver for this hardware.
Of course, at some point, we'll have a bunch of left-over fbtft drivers
that nobody will have converted, and we'll have to take the decision to
remove them all. But to me, the DRM-based solution for those displays
is still very young, so it makes sense to leave a bit of time for
people to convert the drivers over to the new DRM-based solution.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 10:05 ` Thomas Petazzoni
@ 2016-12-22 20:36 ` Andy Shevchenko
0 siblings, 0 replies; 54+ messages in thread
From: Andy Shevchenko @ 2016-12-22 20:36 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Tomi Valkeinen, Greg Kroah-Hartman, linux-fbdev, dri-devel,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard,
linux-kernel
On Wed, Nov 23, 2016 at 12:05 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Wed, 23 Nov 2016 11:12:32 +0200, Tomi Valkeinen wrote:
>> Or do you mean that we should keep the drivers in staging until there's
>> a matching DRM driver, but drop any plans to move the drivers from
>> staging to drivers/video/? If so, I'm fine with that. This is an RFC,
>> mostly to raise some discussion and push people to actually write those
>> DRM drivers =).
>
> The very reason why I submitted those drivers for staging is because
> lots and lots of people were using out of tree kernel modules for these
> drivers, which was really a pain.
>
> If you now remove those drivers from staging, then those folks will be
> back in the situation they originally were, using annoying out of tree
> modules.
>
> I'm all for removing fbtft drivers progressively as a matching
> DRM-based driver is available for the same hardware. However, if there
> is no DRM-based support for a given piece of hardware supported by
> fbtft, I'd prefer if we kept the fbtft driver for this hardware.
Too many people are playing with big things, I vote +1 to *leave*
fbtft for people who prefer small on big.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 9:12 ` Tomi Valkeinen
2016-11-23 9:49 ` Greg Kroah-Hartman
2016-11-23 10:05 ` Thomas Petazzoni
@ 2016-12-08 22:00 ` Sudip Mukherjee
2 siblings, 0 replies; 54+ messages in thread
From: Sudip Mukherjee @ 2016-12-08 22:00 UTC (permalink / raw)
To: Tomi Valkeinen, Greg Kroah-Hartman
Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Noralf Trønnes,
Teddy Wang, Arnaud Patard, linux-kernel
On Wednesday 23 November 2016 09:12 AM, Tomi Valkeinen wrote:
> On 23/11/16 10:52, Greg Kroah-Hartman wrote:
>> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> Since the fbdev framework is in maintenance mode and all new display drivers
>>> should be made with the DRM framework, remove the fbdev drivers from staging.
>>>
<snip>
>
> Or do you mean that we should keep the drivers in staging until there's
> a matching DRM driver, but drop any plans to move the drivers from
> staging to drivers/video/? If so, I'm fine with that. This is an RFC,
> mostly to raise some discussion and push people to actually write those
> DRM drivers =).
I already have plans to convert my drivers to DRM. But it will be great
if you can point me to a simple driver which will help me to understand
how DRM works.
Regards
Sudip
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-11-23 8:03 [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen
` (4 preceding siblings ...)
2016-11-23 8:52 ` Greg Kroah-Hartman
@ 2016-12-08 1:01 ` Benjamin Herrenschmidt
2016-12-08 8:01 ` Tomi Valkeinen
2016-12-08 10:10 ` Daniel Vetter
5 siblings, 2 replies; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-08 1:01 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard
Cc: linux-kernel
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> Hi,
>
> Since the fbdev framework is in maintenance mode and all new display drivers
> should be made with the DRM framework, remove the fbdev drivers from staging.
>
> Note: the patches are created with git format-patch -D, so they can't be
> applied. Only for review.
I missed the discussion where this decision was made, I admit I am
unimpressed by it.
DRM drivers don't strike me as suitable for small/slow cores with dumb
framebuffers or simple 2D only accel, such as the one found in the ASpeed
BMCs.
With drmfb you basically have to shadow everything into memory & copy
over everything, and locks you out of simple 2D accel. For a simple text
console the result is orders of magnitude slower and memory hungry than
a simple fbdev.
At least that was the case last I looked at the DRM stuff with Dave,
maybe things have changed...
Not everything has a powerful 3D GPU.
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 1:01 ` Benjamin Herrenschmidt
@ 2016-12-08 8:01 ` Tomi Valkeinen
2016-12-08 21:23 ` Benjamin Herrenschmidt
2016-12-08 10:10 ` Daniel Vetter
1 sibling, 1 reply; 54+ messages in thread
From: Tomi Valkeinen @ 2016-12-08 8:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linux-fbdev, dri-devel,
Greg Kroah-Hartman, Thomas Petazzoni, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard
Cc: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1164 bytes --]
On 08/12/16 03:01, Benjamin Herrenschmidt wrote:
> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> Since the fbdev framework is in maintenance mode and all new display drivers
>> should be made with the DRM framework, remove the fbdev drivers from staging.
>>
>> Note: the patches are created with git format-patch -D, so they can't be
>> applied. Only for review.
>
> I missed the discussion where this decision was made, I admit I am
> unimpressed by it.
>
> DRM drivers don't strike me as suitable for small/slow cores with dumb
> framebuffers or simple 2D only accel, such as the one found in the ASpeed
> BMCs.
Then the DRM framework should be improved to be suitable.
> With drmfb you basically have to shadow everything into memory & copy
> over everything, and locks you out of simple 2D accel. For a simple text
> console the result is orders of magnitude slower and memory hungry than
> a simple fbdev.
I don't think that's true. You can have a single fbdev buffer and blit
there all you want, afaik.
> Not everything has a powerful 3D GPU.
We don't use GPU on OMAPs (except for 3D).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 8:01 ` Tomi Valkeinen
@ 2016-12-08 21:23 ` Benjamin Herrenschmidt
2016-12-08 21:43 ` Benjamin Herrenschmidt
2016-12-13 7:36 ` Gerd Hoffmann
0 siblings, 2 replies; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-08 21:23 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, airlied
Cc: linux-kernel
On Thu, 2016-12-08 at 10:01 +0200, Tomi Valkeinen wrote:
>
> > DRM drivers don't strike me as suitable for small/slow cores with dumb
> > framebuffers or simple 2D only accel, such as the one found in the ASpeed
> > BMCs.
>
> Then the DRM framework should be improved to be suitable.
Dave ? :-)
> > With drmfb you basically have to shadow everything into memory & copy
> > over everything, and locks you out of simple 2D accel. For a simple text
> > console the result is orders of magnitude slower and memory hungry than
> > a simple fbdev.
>
> I don't think that's true. You can have a single fbdev buffer and blit
> there all you want, afaik.
Well, I had that argument with Dave Airlie which I CCed. The "dumb" ones like
bochsdrmfb, cirrusdrmfb, astdrmfb ... all use shadowing, meaning they use a
lot more memory and cannot do any 2D acceleration for fbcon.
>From memory, David claimed you cannot directly work on the fb with a "proper"
DRM driver. Maybe I misunderstood but then the DRM shines by its complete
absence of useful documentation mixed with bazillion layers of APIs and helpers
so it's pretty hard to get ones head around it without wasting very large amounts
of time which I don't have at the moment.
> > Not everything has a powerful 3D GPU.
>
> We don't use GPU on OMAPs (except for 3D).
The CPU in an OMAP is order of magnitude faster than what I have in an
Aspeed BMC though.
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 21:23 ` Benjamin Herrenschmidt
@ 2016-12-08 21:43 ` Benjamin Herrenschmidt
2016-12-09 8:13 ` Daniel Vetter
2016-12-13 7:36 ` Gerd Hoffmann
1 sibling, 1 reply; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-08 21:43 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, airlied
Cc: linux-kernel
On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote:
> > From memory, David claimed you cannot directly work on the fb with a "proper"
>
> DRM driver. Maybe I misunderstood but then the DRM shines by its complete
> absence of useful documentation
That sentence should have been in the past, it does look like
documentation has been landing in the tree this year ! yay ! I'll go
off read it.
> mixed with bazillion layers of APIs and helpers
> so it's pretty hard to get ones head around it without wasting very large amounts
> of time which I don't have at the moment.
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 21:43 ` Benjamin Herrenschmidt
@ 2016-12-09 8:13 ` Daniel Vetter
0 siblings, 0 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-12-09 8:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Tomi Valkeinen, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, airlied, linux-kernel
On Fri, Dec 09, 2016 at 08:43:13AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote:
> > > From memory, David claimed you cannot directly work on the fb with a "proper"
> >
> > DRM driver. Maybe I misunderstood but then the DRM shines by its complete
> > absence of useful documentation
>
> That sentence should have been in the past, it does look like
> documentation has been landing in the tree this year ! yay ! I'll go
> off read it.
We've been building up that documentation for years now, not sure where
exactly you've looked in the past ;-)
And to make sure you're looking at the right stuff: Please run
$ make DOCBOOKS="" htmldocs
and then look at Documentation/output/gpu. Otherwise all the kerneldoc
stuff isn't pulled in, and a lot of the overview sections (not just
abi/struct docs) are in there.
And if something looks fishy or doesn't make sense, please raise it here
or on #dri-devel on freenode so that we can improve the docs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 21:23 ` Benjamin Herrenschmidt
2016-12-08 21:43 ` Benjamin Herrenschmidt
@ 2016-12-13 7:36 ` Gerd Hoffmann
1 sibling, 0 replies; 54+ messages in thread
From: Gerd Hoffmann @ 2016-12-13 7:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Tomi Valkeinen, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, airlied, linux-kernel
Hi,
> Well, I had that argument with Dave Airlie which I CCed. The "dumb" ones like
> bochsdrmfb, cirrusdrmfb, astdrmfb ... all use shadowing, meaning they use a
> lot more memory and cannot do any 2D acceleration for fbcon.
Well, at least for cirrusdrmfb using 2d accel is kida pointless as this
only shifts the software bitblit from the kernel to qemu ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 1:01 ` Benjamin Herrenschmidt
2016-12-08 8:01 ` Tomi Valkeinen
@ 2016-12-08 10:10 ` Daniel Vetter
2016-12-08 12:15 ` Geert Uytterhoeven
` (2 more replies)
1 sibling, 3 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-12-08 10:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Tomi Valkeinen, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, linux-kernel
On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> > Hi,
> >
> > Since the fbdev framework is in maintenance mode and all new display drivers
> > should be made with the DRM framework, remove the fbdev drivers from staging.
> >
> > Note: the patches are created with git format-patch -D, so they can't be
> > applied. Only for review.
>
> I missed the discussion where this decision was made, I admit I am
> unimpressed by it.
>
> DRM drivers don't strike me as suitable for small/slow cores with dumb
> framebuffers or simple 2D only accel, such as the one found in the ASpeed
> BMCs.
We have a helper for simple drivers now, if you take into account the
massive helper libraries for everything that comes along with drm I expect
if even dumb panels behind slow spi buses drm is now the more suitable
subsytem.
> With drmfb you basically have to shadow everything into memory & copy
> over everything, and locks you out of simple 2D accel. For a simple text
> console the result is orders of magnitude slower and memory hungry than
> a simple fbdev.
Not true, we have full fbdev emulation, and drivers can implement the 2d
accel in there. And a bunch of them do. It's just that most teams decided
that this is pointless waste of their time.j
> At least that was the case last I looked at the DRM stuff with Dave,
> maybe things have changed...
>
> Not everything has a powerful 3D GPU.
That's correct, and drm can cope. And compared to fbdev there's a very
active community who improves&refactors it every kernel release to make it
even better. Since about 2 years (when atomic landed) we merge new drivers at
a rate of 2-3 per kernel release, and those new drivers get ever simpler
and smaller thanks to all this work.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 10:10 ` Daniel Vetter
@ 2016-12-08 12:15 ` Geert Uytterhoeven
2016-12-08 14:02 ` Daniel Vetter
2016-12-08 21:28 ` Benjamin Herrenschmidt
2016-12-13 15:17 ` Laurent Pinchart
2 siblings, 1 reply; 54+ messages in thread
From: Geert Uytterhoeven @ 2016-12-08 12:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Tomi Valkeinen,
Linux Fbdev development list, DRI Development,
Greg Kroah-Hartman, Thomas Petazzoni, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, linux-kernel
On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
>> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
>> > Since the fbdev framework is in maintenance mode and all new display drivers
>> > should be made with the DRM framework, remove the fbdev drivers from staging.
>> >
>> > Note: the patches are created with git format-patch -D, so they can't be
>> > applied. Only for review.
>>
>> I missed the discussion where this decision was made, I admit I am
>> unimpressed by it.
>>
>> DRM drivers don't strike me as suitable for small/slow cores with dumb
>> framebuffers or simple 2D only accel, such as the one found in the ASpeed
>> BMCs.
>
> We have a helper for simple drivers now, if you take into account the
> massive helper libraries for everything that comes along with drm I expect
> if even dumb panels behind slow spi buses drm is now the more suitable
> subsytem.
This has been going on your years:
1. Fbdev is obsolete, everybody should use DRM instead!
2. Can you please point me to a small sample driver for a dumb frame buffer?
3. Several are being written, but none of them is upstream yet.
4. Goto 1.
>> With drmfb you basically have to shadow everything into memory & copy
>> over everything, and locks you out of simple 2D accel. For a simple text
>> console the result is orders of magnitude slower and memory hungry than
>> a simple fbdev.
>
> Not true, we have full fbdev emulation, and drivers can implement the 2d
> accel in there. And a bunch of them do. It's just that most teams decided
> that this is pointless waste of their time.j
>
>> At least that was the case last I looked at the DRM stuff with Dave,
>> maybe things have changed...
>>
>> Not everything has a powerful 3D GPU.
>
> That's correct, and drm can cope. And compared to fbdev there's a very
> active community who improves&refactors it every kernel release to make it
> even better. Since about 2 years (when atomic landed) we merge new drivers at
> a rate of 2-3 per kernel release, and those new drivers get ever simpler
> and smaller thanks to all this work.
You mean the kind of refactoring that causes severe merge conflicts between
drm-next and Linus' tree about every single day?
(sorry, couldn't resist ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 12:15 ` Geert Uytterhoeven
@ 2016-12-08 14:02 ` Daniel Vetter
2016-12-08 14:22 ` Geert Uytterhoeven
2016-12-08 14:22 ` Daniel Vetter
0 siblings, 2 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-12-08 14:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Benjamin Herrenschmidt, Tomi Valkeinen,
Linux Fbdev development list, DRI Development,
Greg Kroah-Hartman, Thomas Petazzoni, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, linux-kernel
On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
> >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> >> > Since the fbdev framework is in maintenance mode and all new display drivers
> >> > should be made with the DRM framework, remove the fbdev drivers from staging.
> >> >
> >> > Note: the patches are created with git format-patch -D, so they can't be
> >> > applied. Only for review.
> >>
> >> I missed the discussion where this decision was made, I admit I am
> >> unimpressed by it.
> >>
> >> DRM drivers don't strike me as suitable for small/slow cores with dumb
> >> framebuffers or simple 2D only accel, such as the one found in the ASpeed
> >> BMCs.
> >
> > We have a helper for simple drivers now, if you take into account the
> > massive helper libraries for everything that comes along with drm I expect
> > if even dumb panels behind slow spi buses drm is now the more suitable
> > subsytem.
>
> This has been going on your years:
> 1. Fbdev is obsolete, everybody should use DRM instead!
> 2. Can you please point me to a small sample driver for a dumb frame buffer?
> 3. Several are being written, but none of them is upstream yet.
> 4. Goto 1.
Wut. We have like 20+ small atomic drivers nowdays.
> >> With drmfb you basically have to shadow everything into memory & copy
> >> over everything, and locks you out of simple 2D accel. For a simple text
> >> console the result is orders of magnitude slower and memory hungry than
> >> a simple fbdev.
> >
> > Not true, we have full fbdev emulation, and drivers can implement the 2d
> > accel in there. And a bunch of them do. It's just that most teams decided
> > that this is pointless waste of their time.j
> >
> >> At least that was the case last I looked at the DRM stuff with Dave,
> >> maybe things have changed...
> >>
> >> Not everything has a powerful 3D GPU.
> >
> > That's correct, and drm can cope. And compared to fbdev there's a very
> > active community who improves&refactors it every kernel release to make it
> > even better. Since about 2 years (when atomic landed) we merge new drivers at
> > a rate of 2-3 per kernel release, and those new drivers get ever simpler
> > and smaller thanks to all this work.
>
> You mean the kind of refactoring that causes severe merge conflicts between
> drm-next and Linus' tree about every single day?
> (sorry, couldn't resist ;-)
Yeah, for a subsystem that only consists of 10% of the overall kernel (by
patch count) we do an extremly shitty job. Maybe we should just all slow
down and stop merging support for new hw, and fuck Android and CrOS and
the billions of devices that don't ship upstream, who cares about those
folks.
If you're this good at mainting gpu and display subsystems, maybe you want
to take over?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 14:02 ` Daniel Vetter
@ 2016-12-08 14:22 ` Geert Uytterhoeven
2016-12-08 14:37 ` Thomas Petazzoni
2016-12-08 14:59 ` Jani Nikula
2016-12-08 14:22 ` Daniel Vetter
1 sibling, 2 replies; 54+ messages in thread
From: Geert Uytterhoeven @ 2016-12-08 14:22 UTC (permalink / raw)
To: Daniel Vetter
Cc: Benjamin Herrenschmidt, Tomi Valkeinen, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
Hi Daniel,
On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
>> >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
>> >> > Since the fbdev framework is in maintenance mode and all new display drivers
>> >> > should be made with the DRM framework, remove the fbdev drivers from staging.
>> >> >
>> >> > Note: the patches are created with git format-patch -D, so they can't be
>> >> > applied. Only for review.
>> >>
>> >> I missed the discussion where this decision was made, I admit I am
>> >> unimpressed by it.
>> >>
>> >> DRM drivers don't strike me as suitable for small/slow cores with dumb
>> >> framebuffers or simple 2D only accel, such as the one found in the ASpeed
>> >> BMCs.
>> >
>> > We have a helper for simple drivers now, if you take into account the
>> > massive helper libraries for everything that comes along with drm I expect
>> > if even dumb panels behind slow spi buses drm is now the more suitable
>> > subsytem.
>>
>> This has been going on your years:
>> 1. Fbdev is obsolete, everybody should use DRM instead!
>> 2. Can you please point me to a small sample driver for a dumb frame buffer?
>> 3. Several are being written, but none of them is upstream yet.
>> 4. Goto 1.
>
> Wut. We have like 20+ small atomic drivers nowdays.
That's fast! Only two weeks ago you said:
| Bummer, they still haven't landed. But afaik there's at least 4 of
| them floating around in various places ...
>> > That's correct, and drm can cope. And compared to fbdev there's a very
>> > active community who improves&refactors it every kernel release to make it
>> > even better. Since about 2 years (when atomic landed) we merge new drivers at
>> > a rate of 2-3 per kernel release, and those new drivers get ever simpler
>> > and smaller thanks to all this work.
>>
>> You mean the kind of refactoring that causes severe merge conflicts between
>> drm-next and Linus' tree about every single day?
>> (sorry, couldn't resist ;-)
>
> Yeah, for a subsystem that only consists of 10% of the overall kernel (by
> patch count) we do an extremly shitty job. Maybe we should just all slow
> down and stop merging support for new hw, and fuck Android and CrOS and
> the billions of devices that don't ship upstream, who cares about those
> folks.
My apologies. In hindsight, my comment sounded much more insulting than it
was meant to be.
> If you're this good at mainting gpu and display subsystems, maybe you want
> to take over?
No please ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 14:22 ` Geert Uytterhoeven
@ 2016-12-08 14:37 ` Thomas Petazzoni
2016-12-08 14:44 ` Geert Uytterhoeven
2016-12-08 14:59 ` Jani Nikula
1 sibling, 1 reply; 54+ messages in thread
From: Thomas Petazzoni @ 2016-12-08 14:37 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Daniel Vetter, Benjamin Herrenschmidt, Tomi Valkeinen,
Greg Kroah-Hartman, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
Hello,
On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
> > Wut. We have like 20+ small atomic drivers nowdays.
>
> That's fast! Only two weeks ago you said:
>
> | Bummer, they still haven't landed. But afaik there's at least 4 of
> | them floating around in various places ...
You're not talking about the same thing I believe.
When Daniel says "small atomic drivers", he talks about the relatively
small DRM drivers for SoC display controllers, such as the ones you can
find in ARM SoCs.
When you say "small driver", you're thinking about drivers for I2C or
SPI connected displays.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 14:37 ` Thomas Petazzoni
@ 2016-12-08 14:44 ` Geert Uytterhoeven
2016-12-08 15:21 ` Daniel Vetter
0 siblings, 1 reply; 54+ messages in thread
From: Geert Uytterhoeven @ 2016-12-08 14:44 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Daniel Vetter, Benjamin Herrenschmidt, Tomi Valkeinen,
Greg Kroah-Hartman, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
Hi Thomas,
On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
>> > Wut. We have like 20+ small atomic drivers nowdays.
>>
>> That's fast! Only two weeks ago you said:
>>
>> | Bummer, they still haven't landed. But afaik there's at least 4 of
>> | them floating around in various places ...
>
> You're not talking about the same thing I believe.
>
> When Daniel says "small atomic drivers", he talks about the relatively
> small DRM drivers for SoC display controllers, such as the ones you can
> find in ARM SoCs.
>
> When you say "small driver", you're thinking about drivers for I2C or
> SPI connected displays.
No, I wasn't thinking about I2C or SPI connected displays, but about simple
dumb memory-mapped frame buffers, which is what fbdev was initially
developed for.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 14:44 ` Geert Uytterhoeven
@ 2016-12-08 15:21 ` Daniel Vetter
2016-12-08 21:34 ` Benjamin Herrenschmidt
2016-12-09 8:30 ` Daniel Vetter
0 siblings, 2 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-12-08 15:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Petazzoni, Daniel Vetter, Benjamin Herrenschmidt,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
[back from my walk, the sunset here is stellar ;-)]
On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
> >> > Wut. We have like 20+ small atomic drivers nowdays.
> >>
> >> That's fast! Only two weeks ago you said:
> >>
> >> | Bummer, they still haven't landed. But afaik there's at least 4 of
> >> | them floating around in various places ...
> >
> > You're not talking about the same thing I believe.
> >
> > When Daniel says "small atomic drivers", he talks about the relatively
> > small DRM drivers for SoC display controllers, such as the ones you can
> > find in ARM SoCs.
> >
> > When you say "small driver", you're thinking about drivers for I2C or
> > SPI connected displays.
>
> No, I wasn't thinking about I2C or SPI connected displays, but about simple
> dumb memory-mapped frame buffers, which is what fbdev was initially
> developed for.
Yeah, small drivers like these we have piles now, things exploded a lot
after atomic landed two years ago. And they seem to shrink with every
release a bit more (since lots more drivers gives you lots more insight
into what other refactorings would make sense). Those we have a big pile
of, and nowadays (at least with developers expirienced with upstream, but
not necessarily with drm) it takes but a few weeks from initial submission
to getting them merged.
What we don't yet have a nice tidy example driver of is the even simpler
"dumb framebuffer behind a slow bus with explicit/manual upload", for like
small i2c/spi panels (and conceptually also usb, even though there bw and
panel size are a bit scaled up). We've gained some really nice helpers for
this this year, and there's 3 drivers in-flight to make use of it. But
since that's right now just a hobbyist effort it's moving a bit slower
(and I was mistaken a few weeks back where I assumed that one of them
landed already).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 15:21 ` Daniel Vetter
@ 2016-12-08 21:34 ` Benjamin Herrenschmidt
2016-12-08 21:57 ` Benjamin Herrenschmidt
2016-12-09 8:30 ` Daniel Vetter
1 sibling, 1 reply; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-08 21:34 UTC (permalink / raw)
To: Daniel Vetter, Geert Uytterhoeven
Cc: Thomas Petazzoni, Tomi Valkeinen, Greg Kroah-Hartman,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard,
DRI Development, Linux Fbdev development list, linux-kernel
On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote:
> Yeah, small drivers like these we have piles now, things exploded a lot
> after atomic landed two years ago. And they seem to shrink with every
> release a bit more (since lots more drivers gives you lots more insight
> into what other refactorings would make sense). Those we have a big pile
> of, and nowadays (at least with developers expirienced with upstream, but
> not necessarily with drm) it takes but a few weeks from initial submission
> to getting them merged.
>
> What we don't yet have a nice tidy example driver of is the even simpler
> "dumb framebuffer behind a slow bus with explicit/manual upload", for like
> small i2c/spi panels (and conceptually also usb, even though there bw and
> panel size are a bit scaled up). We've gained some really nice helpers for
> this this year, and there's 3 drivers in-flight to make use of it. But
> since that's right now just a hobbyist effort it's moving a bit slower
> (and I was mistaken a few weeks back where I assumed that one of them
> landed already).
What I find usually confusing is the interaction with the TTM and
overall fb memory management, when trying to plumb in simple 2d accel
to speed up fbcon mostly (but I don't mind making it available to user
space via ioctls, though that's not a priority).
As I mentioned earlier, probably 1 or 2 years ago, Dave made the
argument that shadowing through memory was necessary and precluded 2D
accel, though I don't fully remember the root of the argument. If that
is indeed not the case, then my main objection is lifted.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 21:34 ` Benjamin Herrenschmidt
@ 2016-12-08 21:57 ` Benjamin Herrenschmidt
2016-12-09 8:34 ` Daniel Vetter
0 siblings, 1 reply; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-08 21:57 UTC (permalink / raw)
To: Daniel Vetter, Geert Uytterhoeven
Cc: Thomas Petazzoni, Tomi Valkeinen, Greg Kroah-Hartman,
Noralf Trønnes, Sudip Mukherjee, Teddy Wang, Arnaud Patard,
DRI Development, Linux Fbdev development list, linux-kernel
On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> argument that shadowing through memory was necessary and precluded 2D
> accel, though I don't fully remember the root of the argument. If that
> is indeed not the case, then my main objection is lifted.
Things seem to change quickly as Daniel pointed out.
So ast and cirrus seem to still use a manual dirty tracking and
shadowing (though I'm not sure why), but the infrastructure for
that has moved from the drivers to the helpers.
bochs (qemu) doesn't seem to anymore from what I can see as it
doesn't have a ->dirty callback.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 21:57 ` Benjamin Herrenschmidt
@ 2016-12-09 8:34 ` Daniel Vetter
2016-12-09 8:41 ` Daniel Vetter
2016-12-09 11:44 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-12-09 8:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Daniel Vetter, Geert Uytterhoeven, Thomas Petazzoni,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, Dec 09, 2016 at 08:57:29AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> > As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> > argument that shadowing through memory was necessary and precluded 2D
> > accel, though I don't fully remember the root of the argument. If that
> > is indeed not the case, then my main objection is lifted.
>
> Things seem to change quickly as Daniel pointed out.
>
> So ast and cirrus seem to still use a manual dirty tracking and
> shadowing (though I'm not sure why), but the infrastructure for
> that has moved from the drivers to the helpers.
>
> bochs (qemu) doesn't seem to anymore from what I can see as it
> doesn't have a ->dirty callback.
Yeah if you have discrete vram then your dumb display driver isn't all
that pretty. We essentially just have the few drivers Dave hacked up to be
able to boot some servers. And there's definitely lots of room for more
shared code for those, and also some better infrastructure and helpers to
share more cod and make them better.
The massive pile of dumb framebuffers we all merged over the past 2 years
all use system/dma memory for scanout, and for those we have the very nice
cma helpers that take care of everything for you. So it is possible, only
reason vram dumb buffers look worse is that there's only 3 and no one
cares about them, vs about 20 and a very active community of contributors
(also for core drm improvements) for the other case.
Althought the MXSFB driver that just landed does use ttm and vram, so
maybe that's now improving too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 8:34 ` Daniel Vetter
@ 2016-12-09 8:41 ` Daniel Vetter
2016-12-09 11:48 ` Benjamin Herrenschmidt
2016-12-09 11:44 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 54+ messages in thread
From: Daniel Vetter @ 2016-12-09 8:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Geert Uytterhoeven, Thomas Petazzoni,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, Dec 09, 2016 at 09:34:42AM +0100, Daniel Vetter wrote:
> On Fri, Dec 09, 2016 at 08:57:29AM +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> > > As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> > > argument that shadowing through memory was necessary and precluded 2D
> > > accel, though I don't fully remember the root of the argument. If that
> > > is indeed not the case, then my main objection is lifted.
> >
> > Things seem to change quickly as Daniel pointed out.
> >
> > So ast and cirrus seem to still use a manual dirty tracking and
> > shadowing (though I'm not sure why), but the infrastructure for
> > that has moved from the drivers to the helpers.
> >
> > bochs (qemu) doesn't seem to anymore from what I can see as it
> > doesn't have a ->dirty callback.
>
> Yeah if you have discrete vram then your dumb display driver isn't all
> that pretty. We essentially just have the few drivers Dave hacked up to be
> able to boot some servers. And there's definitely lots of room for more
> shared code for those, and also some better infrastructure and helpers to
> share more cod and make them better.
And since I failed to make this clear: There's not really a fundamental
reason ast and cirrus use the dirty tracking for fbdev. It's just that
doing it that way was the fastest way to get those servers booting, and
ever since no one cared. It's a bit tricky to do right because fbdev
assumes it always own the framebuffer and that it never moves, whereas drm
has a multi-master model and proper isolation. IIrc we've hacked up
something once, and if there's indeed more interest into vram dumb buffer
drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
fb helpers we have) to make it all pretty and nice and fast and
essentially plug-in-and-forget from a driver authors pov.
Cheers, Daniel
> The massive pile of dumb framebuffers we all merged over the past 2 years
> all use system/dma memory for scanout, and for those we have the very nice
> cma helpers that take care of everything for you. So it is possible, only
> reason vram dumb buffers look worse is that there's only 3 and no one
> cares about them, vs about 20 and a very active community of contributors
> (also for core drm improvements) for the other case.
>
> Althought the MXSFB driver that just landed does use ttm and vram, so
> maybe that's now improving too.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 8:41 ` Daniel Vetter
@ 2016-12-09 11:48 ` Benjamin Herrenschmidt
2016-12-09 13:35 ` Daniel Vetter
0 siblings, 1 reply; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-09 11:48 UTC (permalink / raw)
To: Daniel Vetter, Geert Uytterhoeven, Thomas Petazzoni,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote:
>
> And since I failed to make this clear: There's not really a
> fundamental
> reason ast and cirrus use the dirty tracking for fbdev. It's just that
> doing it that way was the fastest way to get those servers booting, and
> ever since no one cared. It's a bit tricky to do right because fbdev
> assumes it always own the framebuffer and that it never moves,
That can be worked around from my memories of hacking fbdev many years
ago. Basically fbdev only owns it if it's the current VT and you can
make it release it if the user switches to KD_GRAPHICS which userspace
should always do before taking over.
As for multi userspace client, well, swapping an mmap between HW and
memory backing store is a somewhat solved problem already.
> whereas drm has a multi-master model and proper isolation. IIrc we've hacked up
> something once, and if there's indeed more interest into vram dumb buffer
> drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
> fb helpers we have) to make it all pretty and nice and fast and
> essentially plug-in-and-forget from a driver authors pov.
That would be nice. I don't have the bandwidth to swap-in enough
understanding of TTM guts right now but I might look into it some time next
year if nobody beats me to it.
> Cheers, Daniel
>
> > The massive pile of dumb framebuffers we all merged over the past 2 years
> > all use system/dma memory for scanout, and for those we have the very nice
> > cma helpers that take care of everything for you. So it is possible, only
> > reason vram dumb buffers look worse is that there's only 3 and no one
> > cares about them, vs about 20 and a very active community of contributors
> > (also for core drm improvements) for the other case.
> >
> > Althought the MXSFB driver that just landed does use ttm and vram, so
> > maybe that's now improving too.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 11:48 ` Benjamin Herrenschmidt
@ 2016-12-09 13:35 ` Daniel Vetter
2016-12-09 20:27 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 54+ messages in thread
From: Daniel Vetter @ 2016-12-09 13:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Daniel Vetter, Geert Uytterhoeven, Thomas Petazzoni,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, Dec 09, 2016 at 10:48:07PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote:
> >
> > And since I failed to make this clear: There's not really a
> > fundamental
> > reason ast and cirrus use the dirty tracking for fbdev. It's just that
> > doing it that way was the fastest way to get those servers booting, and
> > ever since no one cared. It's a bit tricky to do right because fbdev
> > assumes it always own the framebuffer and that it never moves,
>
> That can be worked around from my memories of hacking fbdev many years
> ago. Basically fbdev only owns it if it's the current VT and you can
> make it release it if the user switches to KD_GRAPHICS which userspace
> should always do before taking over.
>
> As for multi userspace client, well, swapping an mmap between HW and
> memory backing store is a somewhat solved problem already.
Hm, I didn't know that, but then all existing drm drivers have fairly
simplistic fbdev mmap implementations.
> > whereas drm has a multi-master model and proper isolation. IIrc we've hacked up
> > something once, and if there's indeed more interest into vram dumb buffer
> > drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
> > fb helpers we have) to make it all pretty and nice and fast and
> > essentially plug-in-and-forget from a driver authors pov.
>
> That would be nice. I don't have the bandwidth to swap-in enough
> understanding of TTM guts right now but I might look into it some time next
> year if nobody beats me to it.
Probably best would be to first extract some helpers for ttm based vram
dumb buffer management, and then start to implement some of the
improvements so that all drivers can benefit. Like you've said it's not
rocket science, it just needs to be done ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 13:35 ` Daniel Vetter
@ 2016-12-09 20:27 ` Benjamin Herrenschmidt
2016-12-13 7:18 ` Michel Dänzer
0 siblings, 1 reply; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-09 20:27 UTC (permalink / raw)
To: Daniel Vetter
Cc: Geert Uytterhoeven, Thomas Petazzoni, Tomi Valkeinen,
Greg Kroah-Hartman, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
> > As for multi userspace client, well, swapping an mmap between HW and
> > memory backing store is a somewhat solved problem already.
>
> Hm, I didn't know that, but then all existing drm drivers have fairly
> simplistic fbdev mmap implementations.
Hrm, I though the TTM did it ... I remember talking with Thomas
Hellstrom about that back in the day... you use unmap_mapping_range
to unmap the existing mappings basically so you can take new faults
and route them to a different page, but I can't see a call in there
so maybe he ended up not doing it.
We used to do that on Cell to "context switch" the local memory of
the SPU engines between the real SPU and the backing store. It's not
very hard to do.
The main issue is that the mapping attributes change between cached
and non-cached under the hood, so users have to be careful not to do
things like use instructions that only work on one type of mapping
(or do things like misaligned accesses).
> > > whereas drm has a multi-master model and proper isolation. IIrc we've hacked up
> > > something once, and if there's indeed more interest into vram dumb buffer
> > > drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
> > > fb helpers we have) to make it all pretty and nice and fast and
> > > essentially plug-in-and-forget from a driver authors pov.
> >
> > That would be nice. I don't have the bandwidth to swap-in enough
> > understanding of TTM guts right now but I might look into it some time next
> > year if nobody beats me to it.
>
> Probably best would be to first extract some helpers for ttm based vram
> dumb buffer management, and then start to implement some of the
> improvements so that all drivers can benefit. Like you've said it's not
> rocket science, it just needs to be done ;-)
Right :-)
Though getting ones head around the infrastructure in the DRM does take
time :-) There's a lot of stuff in there, between TTM, GEM etc... and
not all of it completely "obvious" ...
Cheers,
Ben.
> -Daniel
> --
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 20:27 ` Benjamin Herrenschmidt
@ 2016-12-13 7:18 ` Michel Dänzer
0 siblings, 0 replies; 54+ messages in thread
From: Michel Dänzer @ 2016-12-13 7:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Daniel Vetter
Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang,
Greg Kroah-Hartman, linux-kernel, DRI Development,
Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee,
Arnaud Patard
On 10/12/16 05:27 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
>>> As for multi userspace client, well, swapping an mmap between HW and
>>> memory backing store is a somewhat solved problem already.
>>
>> Hm, I didn't know that, but then all existing drm drivers have fairly
>> simplistic fbdev mmap implementations.
>
> Hrm, I though the TTM did it ... I remember talking with Thomas
> Hellstrom about that back in the day... you use unmap_mapping_range
> to unmap the existing mappings basically so you can take new faults
> and route them to a different page, but I can't see a call in there
> so maybe he ended up not doing it.
I think he did, it was working fine for userspace mappings when I tried
making radeon use a non-pinned BO for fbdev years ago (the problem was
fbcon potentially trying to access the framebuffer at the most
inconvenient times). There's still ttm_fbdev_mmap, but I'm not sure
everything to make this fully work for userspace fbdev mappings is still
there.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 8:34 ` Daniel Vetter
2016-12-09 8:41 ` Daniel Vetter
@ 2016-12-09 11:44 ` Benjamin Herrenschmidt
2016-12-09 12:33 ` Geert Uytterhoeven
` (2 more replies)
1 sibling, 3 replies; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-09 11:44 UTC (permalink / raw)
To: Daniel Vetter
Cc: Geert Uytterhoeven, Thomas Petazzoni, Tomi Valkeinen,
Greg Kroah-Hartman, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> Yeah if you have discrete vram then your dumb display driver isn't all
> that pretty. We essentially just have the few drivers Dave hacked up to be
> able to boot some servers. And there's definitely lots of room for more
> shared code for those, and also some better infrastructure and helpers to
> share more cod and make them better.
>
> The massive pile of dumb framebuffers we all merged over the past 2 years
> all use system/dma memory for scanout, and for those we have the very nice
> cma helpers that take care of everything for you.
Do they work if the system/DMA memory has to be physically contiguous
and at a fixed address ? The AST "ARM side" GPU is like that.
> So it is possible, only reason vram dumb buffers look worse is that there's
> only 3 and no one cares about them, vs about 20 and a very active community
> of contributors (also for core drm improvements) for the other case.
Well, we could move offb to drm while at it I suppose that would be another
one (offb is the "dumb driver based on pre-programmed output by firmware).
> Althought the MXSFB driver that just landed does use ttm and vram, so
> maybe that's now improving too.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 11:44 ` Benjamin Herrenschmidt
@ 2016-12-09 12:33 ` Geert Uytterhoeven
2016-12-09 13:19 ` Lucas Stach
2016-12-09 13:33 ` Daniel Vetter
2 siblings, 0 replies; 54+ messages in thread
From: Geert Uytterhoeven @ 2016-12-09 12:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Daniel Vetter, Thomas Petazzoni, Tomi Valkeinen,
Greg Kroah-Hartman, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
Hi Ben,
On Fri, Dec 9, 2016 at 12:44 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>> So it is possible, only reason vram dumb buffers look worse is that there's
>> only 3 and no one cares about them, vs about 20 and a very active community
>> of contributors (also for core drm improvements) for the other case.
>
> Well, we could move offb to drm while at it I suppose that would be another
> one (offb is the "dumb driver based on pre-programmed output by firmware).
That would indeed be a great example.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 11:44 ` Benjamin Herrenschmidt
2016-12-09 12:33 ` Geert Uytterhoeven
@ 2016-12-09 13:19 ` Lucas Stach
2016-12-09 13:33 ` Daniel Vetter
2 siblings, 0 replies; 54+ messages in thread
From: Lucas Stach @ 2016-12-09 13:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Daniel Vetter, Thomas Petazzoni, Linux Fbdev development list,
Teddy Wang, Greg Kroah-Hartman, linux-kernel, DRI Development,
Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee,
Arnaud Patard
Am Freitag, den 09.12.2016, 22:44 +1100 schrieb Benjamin Herrenschmidt:
> On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> > Yeah if you have discrete vram then your dumb display driver isn't all
> > that pretty. We essentially just have the few drivers Dave hacked up to be
> > able to boot some servers. And there's definitely lots of room for more
> > shared code for those, and also some better infrastructure and helpers to
> > share more cod and make them better.
> >
> > The massive pile of dumb framebuffers we all merged over the past 2 years
> > all use system/dma memory for scanout, and for those we have the very nice
> > cma helpers that take care of everything for you.
>
> Do they work if the system/DMA memory has to be physically contiguous
> and at a fixed address ? The AST "ARM side" GPU is like that.
Yes, CMA is exactly the solution for that. It provides contiguous memory
that doesn't need to be removed from the normal Linux memory handling
and allows for the CMA region to be at specific places if needed. It's
just a matter of describing the constraints properly.
Regards,
Lucas
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 11:44 ` Benjamin Herrenschmidt
2016-12-09 12:33 ` Geert Uytterhoeven
2016-12-09 13:19 ` Lucas Stach
@ 2016-12-09 13:33 ` Daniel Vetter
2016-12-09 13:57 ` David Herrmann
2 siblings, 1 reply; 54+ messages in thread
From: Daniel Vetter @ 2016-12-09 13:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Daniel Vetter, Geert Uytterhoeven, Thomas Petazzoni,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, Dec 09, 2016 at 10:44:16PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> > Yeah if you have discrete vram then your dumb display driver isn't all
> > that pretty. We essentially just have the few drivers Dave hacked up to be
> > able to boot some servers. And there's definitely lots of room for more
> > shared code for those, and also some better infrastructure and helpers to
> > share more cod and make them better.
> >
> > The massive pile of dumb framebuffers we all merged over the past 2 years
> > all use system/dma memory for scanout, and for those we have the very nice
> > cma helpers that take care of everything for you.
>
> Do they work if the system/DMA memory has to be physically contiguous
> and at a fixed address ? The AST "ARM side" GPU is like that.
Yeah, if you wire up the dma_alloc_coherent to cma you'll get a contiguous
buffer pinned into place.
> > So it is possible, only reason vram dumb buffers look worse is that there's
> > only 3 and no one cares about them, vs about 20 and a very active community
> > of contributors (also for core drm improvements) for the other case.
>
> Well, we could move offb to drm while at it I suppose that would be another
> one (offb is the "dumb driver based on pre-programmed output by firmware).
One of the still in-flight drm drivers is the simpledrm thing meant for
all kinds of firmware drivers like efifb and similar things on arm for
pre-programmed output set up by firmware. I.e. no modeset support and
otherwise a lot of fake to make it work as drm driver, but the idea that
it's good enough until your real drm driver takes over.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 13:33 ` Daniel Vetter
@ 2016-12-09 13:57 ` David Herrmann
2016-12-09 14:04 ` Daniel Vetter
2016-12-09 20:29 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 54+ messages in thread
From: David Herrmann @ 2016-12-09 13:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Geert Uytterhoeven, Thomas Petazzoni,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
Hey
On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > So it is possible, only reason vram dumb buffers look worse is that there's
>> > only 3 and no one cares about them, vs about 20 and a very active community
>> > of contributors (also for core drm improvements) for the other case.
>>
>> Well, we could move offb to drm while at it I suppose that would be another
>> one (offb is the "dumb driver based on pre-programmed output by firmware).
>
> One of the still in-flight drm drivers is the simpledrm thing meant for
> all kinds of firmware drivers like efifb and similar things on arm for
> pre-programmed output set up by firmware. I.e. no modeset support and
> otherwise a lot of fake to make it work as drm driver, but the idea that
> it's good enough until your real drm driver takes over.
The x86 platform device fixups for SimpleDRM went in some weeks ago,
so maybe I should resend the patches. The driver could easily do
'offb'-like devices as well. Trivial to add.
Anyway, Benjamin is right, we always do shadow buffering for trivial
drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or
dirty-ioctl. Reason is that we cannot easily expose the real
framebuffer in DRM via FB-objects. But I also never saw a use-case for
it, since all trivial devices I worked with were only either used as
fallback or nobody cared for performance.
The generic DRM API is designed for dynamic FB allocation. If your
hardware does not allow you to change the scanout source, you will
have a hard time trying to expose the static buffers via the dynamic
FB-object API. Furthermore, all DRM user-space expects dynamic FB
management to work, preferably without a ridiculously low memory
limit. That's also why I never bothered changing the drivers.
Despite all of this I still see no reason why a driver could not
expose the static, real frambuffers via private ioctls. You can get
all your fancy acceleration that way. Then fix user-space to use this
API. If enough drivers end up with something similar, move it into the
core. Just like we always do in DRM.
Thanks
David
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 13:57 ` David Herrmann
@ 2016-12-09 14:04 ` Daniel Vetter
2016-12-09 20:29 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-12-09 14:04 UTC (permalink / raw)
To: David Herrmann
Cc: Benjamin Herrenschmidt, Geert Uytterhoeven, Thomas Petazzoni,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, Dec 09, 2016 at 02:57:24PM +0100, David Herrmann wrote:
> Hey
>
> On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> > So it is possible, only reason vram dumb buffers look worse is that there's
> >> > only 3 and no one cares about them, vs about 20 and a very active community
> >> > of contributors (also for core drm improvements) for the other case.
> >>
> >> Well, we could move offb to drm while at it I suppose that would be another
> >> one (offb is the "dumb driver based on pre-programmed output by firmware).
> >
> > One of the still in-flight drm drivers is the simpledrm thing meant for
> > all kinds of firmware drivers like efifb and similar things on arm for
> > pre-programmed output set up by firmware. I.e. no modeset support and
> > otherwise a lot of fake to make it work as drm driver, but the idea that
> > it's good enough until your real drm driver takes over.
>
> The x86 platform device fixups for SimpleDRM went in some weeks ago,
> so maybe I should resend the patches. The driver could easily do
> 'offb'-like devices as well. Trivial to add.
>
> Anyway, Benjamin is right, we always do shadow buffering for trivial
> drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or
> dirty-ioctl. Reason is that we cannot easily expose the real
> framebuffer in DRM via FB-objects. But I also never saw a use-case for
> it, since all trivial devices I worked with were only either used as
> fallback or nobody cared for performance.
>
> The generic DRM API is designed for dynamic FB allocation. If your
> hardware does not allow you to change the scanout source, you will
> have a hard time trying to expose the static buffers via the dynamic
> FB-object API. Furthermore, all DRM user-space expects dynamic FB
> management to work, preferably without a ridiculously low memory
> limit. That's also why I never bothered changing the drivers.
>
> Despite all of this I still see no reason why a driver could not
> expose the static, real frambuffers via private ioctls. You can get
> all your fancy acceleration that way. Then fix user-space to use this
> API. If enough drivers end up with something similar, move it into the
> core. Just like we always do in DRM.
Well, we don't need a private abi. If we dynamically remap the mmaps and
fixup fbdev to do the same then we could redirect frontbuffer rendering
for the currently displaying buffer to the static, real framebuffer. That
would fix the perf issues Ben is fearing I think.
And if we do some nice ttm helpers to hide this all to the level the cma
helpers are just plug-in-and-go then it'd be real nice I think. But thus
far no one has cared enough yet to make that happen.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 13:57 ` David Herrmann
2016-12-09 14:04 ` Daniel Vetter
@ 2016-12-09 20:29 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-09 20:29 UTC (permalink / raw)
To: David Herrmann, Geert Uytterhoeven, Thomas Petazzoni,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Fri, 2016-12-09 at 14:57 +0100, David Herrmann wrote:
> Despite all of this I still see no reason why a driver could not
> expose the static, real frambuffers via private ioctls. You can get
> all your fancy acceleration that way. Then fix user-space to use this
> API. If enough drivers end up with something similar, move it into the
> core. Just like we always do in DRM.
I don't care so much about userspace in my specific use case, more
about fbcon, which I think can be solved without too many hoops.
As for FB objects, my thinking is we could just use
unmap_mapping_ranges() to effectively change the mapping under the hood
of the app so it alternatively maps a bit of fb or a bit of memory...
Cheers,
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 15:21 ` Daniel Vetter
2016-12-08 21:34 ` Benjamin Herrenschmidt
@ 2016-12-09 8:30 ` Daniel Vetter
1 sibling, 0 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-12-09 8:30 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Petazzoni, Benjamin Herrenschmidt,
Tomi Valkeinen, Greg Kroah-Hartman, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, DRI Development,
Linux Fbdev development list, linux-kernel
On Thu, Dec 08, 2016 at 04:21:34PM +0100, Daniel Vetter wrote:
> [back from my walk, the sunset here is stellar ;-)]
>
> On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:
> > Hi Thomas,
> >
> > On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
> > <thomas.petazzoni@free-electrons.com> wrote:
> > > On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
> > >> > Wut. We have like 20+ small atomic drivers nowdays.
> > >>
> > >> That's fast! Only two weeks ago you said:
> > >>
> > >> | Bummer, they still haven't landed. But afaik there's at least 4 of
> > >> | them floating around in various places ...
> > >
> > > You're not talking about the same thing I believe.
> > >
> > > When Daniel says "small atomic drivers", he talks about the relatively
> > > small DRM drivers for SoC display controllers, such as the ones you can
> > > find in ARM SoCs.
> > >
> > > When you say "small driver", you're thinking about drivers for I2C or
> > > SPI connected displays.
> >
> > No, I wasn't thinking about I2C or SPI connected displays, but about simple
> > dumb memory-mapped frame buffers, which is what fbdev was initially
> > developed for.
>
> Yeah, small drivers like these we have piles now, things exploded a lot
> after atomic landed two years ago. And they seem to shrink with every
> release a bit more (since lots more drivers gives you lots more insight
> into what other refactorings would make sense). Those we have a big pile
> of, and nowadays (at least with developers expirienced with upstream, but
> not necessarily with drm) it takes but a few weeks from initial submission
> to getting them merged.
>
> What we don't yet have a nice tidy example driver of is the even simpler
> "dumb framebuffer behind a slow bus with explicit/manual upload", for like
> small i2c/spi panels (and conceptually also usb, even though there bw and
> panel size are a bit scaled up). We've gained some really nice helpers for
> this this year, and there's 3 drivers in-flight to make use of it. But
> since that's right now just a hobbyist effort it's moving a bit slower
> (and I was mistaken a few weeks back where I assumed that one of them
> landed already).
Correction, MXSFB just landed, which is the first driver using the simple
display pipe helpers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 14:22 ` Geert Uytterhoeven
2016-12-08 14:37 ` Thomas Petazzoni
@ 2016-12-08 14:59 ` Jani Nikula
1 sibling, 0 replies; 54+ messages in thread
From: Jani Nikula @ 2016-12-08 14:59 UTC (permalink / raw)
To: Geert Uytterhoeven, Daniel Vetter
Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang,
linux-kernel, DRI Development, Tomi Valkeinen,
Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard
On Thu, 08 Dec 2016, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> If you're this good at mainting gpu and display subsystems, maybe you
>> want to take over?
>
> No please ;-)
Now that is indeed the right answer, and the attitude we're looking for!
Being able to say "no", especially wrt fbdev drivers, is a must have
quality. You're hired! ;D
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 14:02 ` Daniel Vetter
2016-12-08 14:22 ` Geert Uytterhoeven
@ 2016-12-08 14:22 ` Daniel Vetter
1 sibling, 0 replies; 54+ messages in thread
From: Daniel Vetter @ 2016-12-08 14:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Benjamin Herrenschmidt, Tomi Valkeinen,
Linux Fbdev development list, DRI Development,
Greg Kroah-Hartman, Thomas Petazzoni, Noralf Trønnes,
Sudip Mukherjee, Teddy Wang, Arnaud Patard, linux-kernel
Dear dri-devel folks,
My sincere apologies for hitting send on that mail. I got real mad and
angry and typed a mail I shouldn't have submitted - pouring oil into
flames for shit and giggles just doesn't help anyone, and it detracts from
moving things forward and improving the code and drivers and everything in
a friendly and constructive fashion. I want to be part of a great
community, this wasnt :(
/me out and off for a walk
Thanks, Daniel
On Thu, Dec 08, 2016 at 03:02:10PM +0100, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
> > On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
> > >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> > >> > Since the fbdev framework is in maintenance mode and all new display drivers
> > >> > should be made with the DRM framework, remove the fbdev drivers from staging.
> > >> >
> > >> > Note: the patches are created with git format-patch -D, so they can't be
> > >> > applied. Only for review.
> > >>
> > >> I missed the discussion where this decision was made, I admit I am
> > >> unimpressed by it.
> > >>
> > >> DRM drivers don't strike me as suitable for small/slow cores with dumb
> > >> framebuffers or simple 2D only accel, such as the one found in the ASpeed
> > >> BMCs.
> > >
> > > We have a helper for simple drivers now, if you take into account the
> > > massive helper libraries for everything that comes along with drm I expect
> > > if even dumb panels behind slow spi buses drm is now the more suitable
> > > subsytem.
> >
> > This has been going on your years:
> > 1. Fbdev is obsolete, everybody should use DRM instead!
> > 2. Can you please point me to a small sample driver for a dumb frame buffer?
> > 3. Several are being written, but none of them is upstream yet.
> > 4. Goto 1.
>
> Wut. We have like 20+ small atomic drivers nowdays.
>
> > >> With drmfb you basically have to shadow everything into memory & copy
> > >> over everything, and locks you out of simple 2D accel. For a simple text
> > >> console the result is orders of magnitude slower and memory hungry than
> > >> a simple fbdev.
> > >
> > > Not true, we have full fbdev emulation, and drivers can implement the 2d
> > > accel in there. And a bunch of them do. It's just that most teams decided
> > > that this is pointless waste of their time.j
> > >
> > >> At least that was the case last I looked at the DRM stuff with Dave,
> > >> maybe things have changed...
> > >>
> > >> Not everything has a powerful 3D GPU.
> > >
> > > That's correct, and drm can cope. And compared to fbdev there's a very
> > > active community who improves&refactors it every kernel release to make it
> > > even better. Since about 2 years (when atomic landed) we merge new drivers at
> > > a rate of 2-3 per kernel release, and those new drivers get ever simpler
> > > and smaller thanks to all this work.
> >
> > You mean the kind of refactoring that causes severe merge conflicts between
> > drm-next and Linus' tree about every single day?
> > (sorry, couldn't resist ;-)
>
> Yeah, for a subsystem that only consists of 10% of the overall kernel (by
> patch count) we do an extremly shitty job. Maybe we should just all slow
> down and stop merging support for new hw, and fuck Android and CrOS and
> the billions of devices that don't ship upstream, who cares about those
> folks.
>
> If you're this good at mainting gpu and display subsystems, maybe you want
> to take over?
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 10:10 ` Daniel Vetter
2016-12-08 12:15 ` Geert Uytterhoeven
@ 2016-12-08 21:28 ` Benjamin Herrenschmidt
2016-12-09 0:08 ` Dave Airlie
2016-12-13 15:17 ` Laurent Pinchart
2 siblings, 1 reply; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-08 21:28 UTC (permalink / raw)
To: Daniel Vetter
Cc: Tomi Valkeinen, linux-fbdev, dri-devel, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Trønnes, Sudip Mukherjee,
Teddy Wang, Arnaud Patard, linux-kernel
On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
> > With drmfb you basically have to shadow everything into memory & copy
> > over everything, and locks you out of simple 2D accel. For a simple text
> > console the result is orders of magnitude slower and memory hungry than
> > a simple fbdev.
>
> Not true, we have full fbdev emulation, and drivers can implement the 2d
> accel in there. And a bunch of them do. It's just that most teams decided
> that this is pointless waste of their time.j
Ok so my knowledge might be outdated here. I was complaining to Dave about
how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
buffered everything, and Dave made the point that you basically had to do
that for security reasons that I mostly forgot the details of.
It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
then cool. Can you point me to a drmfb driver that is a good (and not too
complex) example with simple 2d accel ? I'm thinking mostly of color
expansion, bitblt and solid fill for fbcon, the way I used to do it in
radeonfb for example.
> > At least that was the case last I looked at the DRM stuff with Dave,
> > maybe things have changed...
> >
> > Not everything has a powerful 3D GPU.
>
> That's correct, and drm can cope. And compared to fbdev there's a very
> active community who improves&refactors it every kernel release to make it
> even better. Since about 2 years (when atomic landed) we merge new drivers at
> a rate of 2-3 per kernel release, and those new drivers get ever simpler
> and smaller thanks to all this work.
Yeah it's hard to follow from outside :-) As I said above, it would
help if you could point to a good modern example driver to use as
reference.
Thanks !
Cheers,
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 21:28 ` Benjamin Herrenschmidt
@ 2016-12-09 0:08 ` Dave Airlie
2016-12-09 8:04 ` Geert Uytterhoeven
` (2 more replies)
0 siblings, 3 replies; 54+ messages in thread
From: Dave Airlie @ 2016-12-09 0:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Daniel Vetter, Thomas Petazzoni, Linux Fbdev development list,
Teddy Wang, Greg Kroah-Hartman, LKML, dri-devel, Tomi Valkeinen,
Sudip Mukherjee, Arnaud Patard
On 9 December 2016 at 07:28, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
>> > With drmfb you basically have to shadow everything into memory & copy
>> > over everything, and locks you out of simple 2D accel. For a simple text
>> > console the result is orders of magnitude slower and memory hungry than
>> > a simple fbdev.
>>
>> Not true, we have full fbdev emulation, and drivers can implement the 2d
>> accel in there. And a bunch of them do. It's just that most teams decided
>> that this is pointless waste of their time.j
>
> Ok so my knowledge might be outdated here. I was complaining to Dave about
> how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
> buffered everything, and Dave made the point that you basically had to do
> that for security reasons that I mostly forgot the details of.
>
> It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
> then cool. Can you point me to a drmfb driver that is a good (and not too
> complex) example with simple 2d accel ? I'm thinking mostly of color
> expansion, bitblt and solid fill for fbcon, the way I used to do it in
> radeonfb for example.
What are people using fbcon for that needs acceleration, this is where I get
a bit lost.
It's a console, if you aren't sshing into the machine.
It's main purpose should just be for gathering oopses and you've a lot better
chance of getting an oops if you don't have some sketchy gpu accel in the way.
The acceleration that most of the 2D things provide isn't ever that
great, and shadowing is a lot more effective if done properly. It's a feature
that kernel ppl obsess over but I don't get a lot of real world feedback,
(booting 9000 scsi nodes with debug on takes a long time was possibly
something I heard once, and I think we resolved).
Dave.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 0:08 ` Dave Airlie
@ 2016-12-09 8:04 ` Geert Uytterhoeven
2016-12-09 11:40 ` Benjamin Herrenschmidt
2016-12-13 7:33 ` Gerd Hoffmann
2 siblings, 0 replies; 54+ messages in thread
From: Geert Uytterhoeven @ 2016-12-09 8:04 UTC (permalink / raw)
To: Dave Airlie
Cc: Benjamin Herrenschmidt, Daniel Vetter, Thomas Petazzoni,
Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman,
LKML, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard
Hi Dave,
On Fri, Dec 9, 2016 at 1:08 AM, Dave Airlie <airlied@gmail.com> wrote:
> On 9 December 2016 at 07:28, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
>>> > With drmfb you basically have to shadow everything into memory & copy
>>> > over everything, and locks you out of simple 2D accel. For a simple text
>>> > console the result is orders of magnitude slower and memory hungry than
>>> > a simple fbdev.
>>>
>>> Not true, we have full fbdev emulation, and drivers can implement the 2d
>>> accel in there. And a bunch of them do. It's just that most teams decided
>>> that this is pointless waste of their time.j
>>
>> Ok so my knowledge might be outdated here. I was complaining to Dave about
>> how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
>> buffered everything, and Dave made the point that you basically had to do
>> that for security reasons that I mostly forgot the details of.
>>
>> It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
>> then cool. Can you point me to a drmfb driver that is a good (and not too
>> complex) example with simple 2d accel ? I'm thinking mostly of color
>> expansion, bitblt and solid fill for fbcon, the way I used to do it in
>> radeonfb for example.
>
> What are people using fbcon for that needs acceleration, this is where I get
> a bit lost.
>
> It's a console, if you aren't sshing into the machine.
>
> It's main purpose should just be for gathering oopses and you've a lot better
> chance of getting an oops if you don't have some sketchy gpu accel in the way.
Unless you're using the console as a text console, and don't run e.g. X on top.
> The acceleration that most of the 2D things provide isn't ever that
> great, and shadowing is a lot more effective if done properly. It's a feature
> that kernel ppl obsess over but I don't get a lot of real world feedback,
> (booting 9000 scsi nodes with debug on takes a long time was possibly
> something I heard once, and I think we resolved).
It all depends on the complex balance between GPU performance, CPU performance,
CPU-to-frame buffer bandwidth, and amount of available system RAM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 0:08 ` Dave Airlie
2016-12-09 8:04 ` Geert Uytterhoeven
@ 2016-12-09 11:40 ` Benjamin Herrenschmidt
2016-12-13 7:33 ` Gerd Hoffmann
2 siblings, 0 replies; 54+ messages in thread
From: Benjamin Herrenschmidt @ 2016-12-09 11:40 UTC (permalink / raw)
To: Dave Airlie
Cc: Daniel Vetter, Thomas Petazzoni, Linux Fbdev development list,
Teddy Wang, Greg Kroah-Hartman, LKML, dri-devel, Tomi Valkeinen,
Sudip Mukherjee, Arnaud Patard
On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote:
> What are people using fbcon for that needs acceleration, this is where I get
> a bit lost.
>
> It's a console, if you aren't sshing into the machine.
>
> It's main purpose should just be for gathering oopses and you've a lot better
> chance of getting an oops if you don't have some sketchy gpu accel in the way.
There are other uses for systems running Linux than being a server or desktop :-)
> The acceleration that most of the 2D things provide isn't ever that
> great, and shadowing is a lot more effective if done properly.
Not with a 400Mhz ARM9 processor on a fairly high res display. In these
case basic old things like color expansion for font rendering, bit
blits and solid fills for scrolls work beautifully. Anyway I just
realized that the ARM side of the AST GPU doesn't have the accel bits
at all anyway, only the host side, so I'm back to just a dumb FB. I
still want to avoid the copies though.
> It's a feature
> that kernel ppl obsess over but I don't get a lot of real world feedback,
> (booting 9000 scsi nodes with debug on takes a long time was possibly
> something I heard once, and I think we resolved).
Ben.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-09 0:08 ` Dave Airlie
2016-12-09 8:04 ` Geert Uytterhoeven
2016-12-09 11:40 ` Benjamin Herrenschmidt
@ 2016-12-13 7:33 ` Gerd Hoffmann
2 siblings, 0 replies; 54+ messages in thread
From: Gerd Hoffmann @ 2016-12-13 7:33 UTC (permalink / raw)
To: Dave Airlie
Cc: Benjamin Herrenschmidt, Thomas Petazzoni,
Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman,
LKML, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard
Hi,
> The acceleration that most of the 2D things provide isn't ever that
> great, and shadowing is a lot more effective if done properly.
That is probably true for anything pci-ish, because those devices are
optimized for memory writes and reads are horribly slow. So you surely
want avoid device memory reads and shadowing is a effective way to do
this.
On arm hardware the tradeoff may look quite different, the cpus are
relatively slow and I think most arm gpus don't have dedicated device
memory ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers
2016-12-08 10:10 ` Daniel Vetter
2016-12-08 12:15 ` Geert Uytterhoeven
2016-12-08 21:28 ` Benjamin Herrenschmidt
@ 2016-12-13 15:17 ` Laurent Pinchart
2 siblings, 0 replies; 54+ messages in thread
From: Laurent Pinchart @ 2016-12-13 15:17 UTC (permalink / raw)
To: dri-devel
Cc: Daniel Vetter, Benjamin Herrenschmidt, Thomas Petazzoni,
linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel,
Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard
Hi Daniel,
On Thursday 08 Dec 2016 11:10:05 Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> > > Hi,
> > >
> > > Since the fbdev framework is in maintenance mode and all new display
> > > drivers should be made with the DRM framework, remove the fbdev drivers
> > > from staging.
> > >
> > > Note: the patches are created with git format-patch -D, so they can't be
> > > applied. Only for review.
> >
> > I missed the discussion where this decision was made, I admit I am
> > unimpressed by it.
> >
> > DRM drivers don't strike me as suitable for small/slow cores with dumb
> > framebuffers or simple 2D only accel, such as the one found in the ASpeed
> > BMCs.
>
> We have a helper for simple drivers now, if you take into account the
> massive helper libraries for everything that comes along with drm I expect
> if even dumb panels behind slow spi buses drm is now the more suitable
> subsytem.
>
> > With drmfb you basically have to shadow everything into memory & copy
> > over everything, and locks you out of simple 2D accel. For a simple text
> > console the result is orders of magnitude slower and memory hungry than
> > a simple fbdev.
>
> Not true, we have full fbdev emulation, and drivers can implement the 2d
> accel in there. And a bunch of them do. It's just that most teams decided
> that this is pointless waste of their time.j
And I'd argue that a better use of time would be to implement an accelerated
console that does not use fbdev at all.
> > At least that was the case last I looked at the DRM stuff with Dave,
> > maybe things have changed...
> >
> > Not everything has a powerful 3D GPU.
>
> That's correct, and drm can cope. And compared to fbdev there's a very
> active community who improves&refactors it every kernel release to make it
> even better. Since about 2 years (when atomic landed) we merge new drivers
> at a rate of 2-3 per kernel release, and those new drivers get ever simpler
> and smaller thanks to all this work.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 54+ messages in thread