* [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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: Tomi Valkeinen, linux-kernel 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. 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 ^ permalink raw reply [flat|nested] 154+ messages in thread
* [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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 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. 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 ^ permalink raw reply [flat|nested] 154+ messages in thread
* [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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: Tomi Valkeinen, linux-kernel 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. 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 ^ permalink raw reply [flat|nested] 154+ messages in thread
* [RFC PATCH 1/3] staging: remove xgifb 2016-11-23 8:03 ` Tomi Valkeinen (?) @ 2016-11-23 8:03 ` Tomi Valkeinen -1 siblings, 0 replies; 154+ 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: Tomi Valkeinen, linux-kernel 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] 154+ messages in thread
* [RFC PATCH 1/3] staging: remove xgifb @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* [RFC PATCH 1/3] staging: remove xgifb @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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: Tomi Valkeinen, linux-kernel 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC PATCH 2/3] staging: remove sm750fb 2016-11-23 8:03 ` Tomi Valkeinen (?) @ 2016-11-23 8:03 ` Tomi Valkeinen -1 siblings, 0 replies; 154+ 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: Tomi Valkeinen, linux-kernel 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] 154+ messages in thread
* [RFC PATCH 2/3] staging: remove sm750fb @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* [RFC PATCH 2/3] staging: remove sm750fb @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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: Tomi Valkeinen, linux-kernel 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC PATCH 3/3] staging: remove fbtft 2016-11-23 8:03 ` Tomi Valkeinen (?) @ 2016-11-23 8:03 ` Tomi Valkeinen -1 siblings, 0 replies; 154+ 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: Tomi Valkeinen, linux-kernel 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] 154+ messages in thread
* [RFC PATCH 3/3] staging: remove fbtft @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* [RFC PATCH 3/3] staging: remove fbtft @ 2016-11-23 8:03 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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: Tomi Valkeinen, linux-kernel 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft 2016-11-23 8:03 ` Tomi Valkeinen (?) @ 2016-11-23 17:26 ` Noralf Trønnes -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft @ 2016-11-23 17:26 ` Noralf Trønnes 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft @ 2016-11-23 17:26 ` Noralf Trønnes 0 siblings, 0 replies; 154+ 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft @ 2016-11-24 8:36 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft @ 2016-11-24 8:36 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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.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 #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft 2016-11-23 8:03 ` Tomi Valkeinen @ 2016-11-23 20:12 ` Drew Fustini -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 3/3] staging: remove fbtft @ 2016-11-23 20:12 ` Drew Fustini 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-11-23 8:03 ` Tomi Valkeinen (?) @ 2016-11-23 8:19 ` Daniel Vetter -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-11-23 8:19 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel, dri-devel, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:19 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:19 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-11-23 8:19 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel, dri-devel, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-11-23 8:19 ` Daniel Vetter @ 2016-11-23 8:21 ` Tomi Valkeinen -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:21 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-11-23 8:19 ` Daniel Vetter (?) @ 2016-11-23 8:25 ` Geert Uytterhoeven -1 siblings, 0 replies; 154+ messages in thread From: Geert Uytterhoeven @ 2016-11-23 8:25 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, Tomi Valkeinen, linux-kernel@vger.kernel.org, DRI Development, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:25 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ messages in thread From: Geert Uytterhoeven @ 2016-11-23 8:25 UTC (permalink / raw) To: Daniel Vetter Cc: Arnaud Patard, linux-kernel@vger.kernel.org, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:25 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ messages in thread From: Geert Uytterhoeven @ 2016-11-23 8:25 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, Tomi Valkeinen, linux-kernel@vger.kernel.org, DRI Development, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-11-23 8:45 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, Tomi Valkeinen, linux-kernel@vger.kernel.org, DRI Development, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:45 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-11-23 8:45 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Arnaud Patard, linux-kernel@vger.kernel.org, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:45 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-11-23 8:45 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, Tomi Valkeinen, linux-kernel@vger.kernel.org, DRI Development, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-11-23 8:03 ` Tomi Valkeinen (?) @ 2016-11-23 8:52 ` Greg Kroah-Hartman -1 siblings, 0 replies; 154+ messages in thread From: Greg Kroah-Hartman @ 2016-11-23 8:52 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, dri-devel, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:52 ` Greg Kroah-Hartman 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 8:52 ` Greg Kroah-Hartman 0 siblings, 0 replies; 154+ messages in thread From: Greg Kroah-Hartman @ 2016-11-23 8:52 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, dri-devel, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Tomi Valkeinen @ 2016-11-23 9:12 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, dri-devel, Sudip Mukherjee, Arnaud Patard [-- 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 9:12 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 9:12 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ messages in thread From: Tomi Valkeinen @ 2016-11-23 9:12 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, dri-devel, Sudip Mukherjee, Arnaud Patard [-- Attachment #1.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 #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Greg Kroah-Hartman @ 2016-11-23 9:49 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, dri-devel, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 9:49 ` Greg Kroah-Hartman 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 9:49 ` Greg Kroah-Hartman 0 siblings, 0 replies; 154+ messages in thread From: Greg Kroah-Hartman @ 2016-11-23 9:49 UTC (permalink / raw) To: Tomi Valkeinen Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, dri-devel, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-11-23 9:12 ` Tomi Valkeinen @ 2016-11-23 10:05 ` Thomas Petazzoni -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-11-23 10:05 ` Thomas Petazzoni 0 siblings, 0 replies; 154+ 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] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Andy Shevchenko @ 2016-12-22 20:36 UTC (permalink / raw) To: Thomas Petazzoni Cc: linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-22 20:36 ` Andy Shevchenko 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-22 20:36 ` Andy Shevchenko 0 siblings, 0 replies; 154+ messages in thread From: Andy Shevchenko @ 2016-12-22 20:36 UTC (permalink / raw) To: Thomas Petazzoni Cc: linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-11-23 9:12 ` Tomi Valkeinen (?) @ 2016-12-08 22:00 ` Sudip Mukherjee -1 siblings, 0 replies; 154+ messages in thread From: Sudip Mukherjee @ 2016-12-08 22:00 UTC (permalink / raw) To: Tomi Valkeinen, Greg Kroah-Hartman Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, dri-devel, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 22:00 ` Sudip Mukherjee 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 22:00 ` Sudip Mukherjee 0 siblings, 0 replies; 154+ messages in thread From: Sudip Mukherjee @ 2016-12-08 22:00 UTC (permalink / raw) To: Tomi Valkeinen, Greg Kroah-Hartman Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, dri-devel, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-11-23 8:03 ` Tomi Valkeinen @ 2016-12-08 1:01 ` Benjamin Herrenschmidt -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 1:01 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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] 154+ 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 -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 8:01 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 8:01 ` Tomi Valkeinen 0 siblings, 0 replies; 154+ 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.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 #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:23 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:23 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:43 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:43 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 8:13 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:13 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:13 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 8:13 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-08 21:23 ` Benjamin Herrenschmidt @ 2016-12-13 7:36 ` Gerd Hoffmann -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-13 7:36 ` Gerd Hoffmann 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-08 1:01 ` Benjamin Herrenschmidt (?) @ 2016-12-08 10:10 ` Daniel Vetter -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-08 10:10 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 10:10 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 10:10 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-08 10:10 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 12:15 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 12:15 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-08 14:02 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:02 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:02 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-08 14:02 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:22 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ 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 -1 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:37 ` Thomas Petazzoni 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Geert Uytterhoeven @ 2016-12-08 14:44 UTC (permalink / raw) To: Thomas Petazzoni Cc: Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:44 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:44 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ messages in thread From: Geert Uytterhoeven @ 2016-12-08 14:44 UTC (permalink / raw) To: Thomas Petazzoni Cc: Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-08 15:21 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard [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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 15:21 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org [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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 15:21 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-08 15:21 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard [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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-08 21:34 UTC (permalink / raw) To: Daniel Vetter, Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:34 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:34 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-08 21:34 UTC (permalink / raw) To: Daniel Vetter, Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-08 21:57 UTC (permalink / raw) To: Daniel Vetter, Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:57 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:57 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-08 21:57 UTC (permalink / raw) To: Daniel Vetter, Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 8:34 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:34 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:34 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 8:34 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:41 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:41 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 11:48 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 11:48 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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 > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 13:35 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 13:35 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 13:35 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 13:35 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-09 20:27 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 20:27 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 20:27 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-09 20:27 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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 > -- _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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@vger.kernel.org, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-13 7:18 ` Michel Dänzer 0 siblings, 0 replies; 154+ 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@vger.kernel.org, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-13 7:18 ` Michel Dänzer 0 siblings, 0 replies; 154+ 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@vger.kernel.org, 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-09 8:34 ` Daniel Vetter (?) @ 2016-12-09 11:44 ` Benjamin Herrenschmidt -1 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-09 11:44 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 11:44 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 11:44 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-09 11:44 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Geert Uytterhoeven @ 2016-12-09 12:33 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 12:33 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 12:33 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ messages in thread From: Geert Uytterhoeven @ 2016-12-09 12:33 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-09 11:44 ` Benjamin Herrenschmidt (?) @ 2016-12-09 13:19 ` Lucas Stach -1 siblings, 0 replies; 154+ messages in thread From: Lucas Stach @ 2016-12-09 13:19 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 13:19 ` Lucas Stach 0 siblings, 0 replies; 154+ 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@vger.kernel.org, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 13:19 ` Lucas Stach 0 siblings, 0 replies; 154+ messages in thread From: Lucas Stach @ 2016-12-09 13:19 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-09 11:44 ` Benjamin Herrenschmidt (?) @ 2016-12-09 13:33 ` Daniel Vetter -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 13:33 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 13:33 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 13:33 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 13:33 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 13:57 ` David Herrmann 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 13:57 ` David Herrmann 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 14:04 UTC (permalink / raw) To: David Herrmann Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 14:04 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 14:04 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-09 14:04 UTC (permalink / raw) To: David Herrmann Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Geert Uytterhoeven, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-09 13:57 ` David Herrmann (?) @ 2016-12-09 20:29 ` Benjamin Herrenschmidt -1 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 20:29 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 20:29 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-08 15:21 ` Daniel Vetter (?) @ 2016-12-09 8:30 ` Daniel Vetter -1 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:30 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:30 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-08 14:22 ` Geert Uytterhoeven (?) @ 2016-12-08 14:59 ` Jani Nikula -1 siblings, 0 replies; 154+ 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, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:59 ` Jani Nikula 0 siblings, 0 replies; 154+ 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@vger.kernel.org, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:59 ` Jani Nikula 0 siblings, 0 replies; 154+ 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, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-08 14:02 ` Daniel Vetter (?) @ 2016-12-08 14:22 ` Daniel Vetter -1 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-08 14:22 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:22 ` Daniel Vetter 0 siblings, 0 replies; 154+ 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@vger.kernel.org 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 14:22 ` Daniel Vetter 0 siblings, 0 replies; 154+ messages in thread From: Daniel Vetter @ 2016-12-08 14:22 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen, Greg Kroah-Hartman, Sudip Mukherjee, Arnaud Patard 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-08 10:10 ` Daniel Vetter (?) @ 2016-12-08 21:28 ` Benjamin Herrenschmidt -1 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-08 21:28 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:28 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-08 21:28 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-08 21:28 UTC (permalink / raw) To: Daniel Vetter Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman, linux-kernel, dri-devel, Tomi Valkeinen, Sudip Mukherjee, Arnaud Patard 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ messages in thread From: Dave Airlie @ 2016-12-09 0:08 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 0:08 ` Dave Airlie 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 0:08 ` Dave Airlie 0 siblings, 0 replies; 154+ messages in thread From: Dave Airlie @ 2016-12-09 0:08 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ 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 -1 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 8:04 ` Geert Uytterhoeven 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-09 0:08 ` Dave Airlie (?) @ 2016-12-09 11:40 ` Benjamin Herrenschmidt -1 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-09 11:40 UTC (permalink / raw) To: Dave Airlie Cc: 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 11:40 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-09 11:40 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 154+ messages in thread From: Benjamin Herrenschmidt @ 2016-12-09 11:40 UTC (permalink / raw) To: Dave Airlie Cc: 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-09 0:08 ` Dave Airlie (?) @ 2016-12-13 7:33 ` Gerd Hoffmann -1 siblings, 0 replies; 154+ messages in thread From: Gerd Hoffmann @ 2016-12-13 7:33 UTC (permalink / raw) To: Dave Airlie Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, LKML, dri-devel, Tomi Valkeinen, Greg Kroah-Hartman, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-13 7:33 ` Gerd Hoffmann 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-13 7:33 ` Gerd Hoffmann 0 siblings, 0 replies; 154+ messages in thread From: Gerd Hoffmann @ 2016-12-13 7:33 UTC (permalink / raw) To: Dave Airlie Cc: Thomas Petazzoni, Linux Fbdev development list, Teddy Wang, LKML, dri-devel, Tomi Valkeinen, Greg Kroah-Hartman, 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers 2016-12-08 10:10 ` Daniel Vetter (?) @ 2016-12-13 15:17 ` Laurent Pinchart -1 siblings, 0 replies; 154+ messages in thread From: Laurent Pinchart @ 2016-12-13 15:17 UTC (permalink / raw) To: dri-devel Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, Tomi Valkeinen, Greg Kroah-Hartman, 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-13 15:17 ` Laurent Pinchart 0 siblings, 0 replies; 154+ 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] 154+ messages in thread
* Re: [RFC PATCH 0/3] staging: remove fbdev drivers @ 2016-12-13 15:17 ` Laurent Pinchart 0 siblings, 0 replies; 154+ messages in thread From: Laurent Pinchart @ 2016-12-13 15:17 UTC (permalink / raw) To: dri-devel Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, linux-kernel, Tomi Valkeinen, Greg Kroah-Hartman, 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 154+ messages in thread
end of thread, other threads:[~2016-12-22 20:36 UTC | newest] Thread overview: 154+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 ` 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 ` 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 8:03 ` Tomi Valkeinen 2016-11-23 8:03 ` [RFC PATCH 3/3] staging: remove fbtft Tomi Valkeinen 2016-11-23 8:03 ` Tomi Valkeinen 2016-11-23 8:03 ` Tomi Valkeinen 2016-11-23 17:26 ` Noralf Trønnes 2016-11-23 17:26 ` Noralf Trønnes 2016-11-23 17:26 ` Noralf Trønnes 2016-11-24 8:36 ` Tomi Valkeinen 2016-11-24 8:36 ` Tomi Valkeinen 2016-11-24 8:36 ` Tomi Valkeinen 2016-11-23 20:12 ` Drew Fustini 2016-11-23 20:12 ` Drew Fustini 2016-11-23 8:19 ` [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter 2016-11-23 8:19 ` Daniel Vetter 2016-11-23 8:19 ` Daniel Vetter 2016-11-23 8:21 ` Tomi Valkeinen 2016-11-23 8:21 ` Tomi Valkeinen 2016-11-23 8:25 ` Geert Uytterhoeven 2016-11-23 8:25 ` Geert Uytterhoeven 2016-11-23 8:25 ` Geert Uytterhoeven 2016-11-23 8:45 ` Daniel Vetter 2016-11-23 8:45 ` Daniel Vetter 2016-11-23 8:45 ` Daniel Vetter 2016-11-23 8:52 ` Greg Kroah-Hartman 2016-11-23 8:52 ` Greg Kroah-Hartman 2016-11-23 8:52 ` Greg Kroah-Hartman 2016-11-23 9:12 ` Tomi Valkeinen 2016-11-23 9:12 ` Tomi Valkeinen 2016-11-23 9:12 ` Tomi Valkeinen 2016-11-23 9:49 ` Greg Kroah-Hartman 2016-11-23 9:49 ` Greg Kroah-Hartman 2016-11-23 9:49 ` Greg Kroah-Hartman 2016-11-23 10:05 ` Thomas Petazzoni 2016-11-23 10:05 ` Thomas Petazzoni 2016-12-22 20:36 ` Andy Shevchenko 2016-12-22 20:36 ` Andy Shevchenko 2016-12-22 20:36 ` Andy Shevchenko 2016-12-08 22:00 ` Sudip Mukherjee 2016-12-08 22:00 ` Sudip Mukherjee 2016-12-08 22:00 ` Sudip Mukherjee 2016-12-08 1:01 ` Benjamin Herrenschmidt 2016-12-08 1:01 ` Benjamin Herrenschmidt 2016-12-08 8:01 ` Tomi Valkeinen 2016-12-08 8:01 ` Tomi Valkeinen 2016-12-08 8:01 ` Tomi Valkeinen 2016-12-08 21:23 ` Benjamin Herrenschmidt 2016-12-08 21:23 ` Benjamin Herrenschmidt 2016-12-08 21:23 ` Benjamin Herrenschmidt 2016-12-08 21:43 ` Benjamin Herrenschmidt 2016-12-08 21:43 ` Benjamin Herrenschmidt 2016-12-08 21:43 ` Benjamin Herrenschmidt 2016-12-09 8:13 ` Daniel Vetter 2016-12-09 8:13 ` Daniel Vetter 2016-12-09 8:13 ` Daniel Vetter 2016-12-13 7:36 ` Gerd Hoffmann 2016-12-13 7:36 ` Gerd Hoffmann 2016-12-08 10:10 ` Daniel Vetter 2016-12-08 10:10 ` Daniel Vetter 2016-12-08 10:10 ` Daniel Vetter 2016-12-08 12:15 ` Geert Uytterhoeven 2016-12-08 12:15 ` Geert Uytterhoeven 2016-12-08 12:15 ` Geert Uytterhoeven 2016-12-08 14:02 ` Daniel Vetter 2016-12-08 14:02 ` Daniel Vetter 2016-12-08 14:02 ` Daniel Vetter 2016-12-08 14:22 ` Geert Uytterhoeven 2016-12-08 14:22 ` Geert Uytterhoeven 2016-12-08 14:37 ` Thomas Petazzoni 2016-12-08 14:37 ` Thomas Petazzoni 2016-12-08 14:44 ` Geert Uytterhoeven 2016-12-08 14:44 ` Geert Uytterhoeven 2016-12-08 14:44 ` Geert Uytterhoeven 2016-12-08 15:21 ` Daniel Vetter 2016-12-08 15:21 ` Daniel Vetter 2016-12-08 15:21 ` Daniel Vetter 2016-12-08 21:34 ` Benjamin Herrenschmidt 2016-12-08 21:34 ` Benjamin Herrenschmidt 2016-12-08 21:34 ` Benjamin Herrenschmidt 2016-12-08 21:57 ` Benjamin Herrenschmidt 2016-12-08 21:57 ` Benjamin Herrenschmidt 2016-12-08 21:57 ` Benjamin Herrenschmidt 2016-12-09 8:34 ` Daniel Vetter 2016-12-09 8:34 ` Daniel Vetter 2016-12-09 8:34 ` Daniel Vetter 2016-12-09 8:41 ` Daniel Vetter 2016-12-09 8:41 ` Daniel Vetter 2016-12-09 8:41 ` Daniel Vetter 2016-12-09 11:48 ` Benjamin Herrenschmidt 2016-12-09 11:48 ` Benjamin Herrenschmidt 2016-12-09 11:48 ` Benjamin Herrenschmidt 2016-12-09 13:35 ` Daniel Vetter 2016-12-09 13:35 ` Daniel Vetter 2016-12-09 13:35 ` Daniel Vetter 2016-12-09 20:27 ` Benjamin Herrenschmidt 2016-12-09 20:27 ` Benjamin Herrenschmidt 2016-12-09 20:27 ` Benjamin Herrenschmidt 2016-12-13 7:18 ` Michel Dänzer 2016-12-13 7:18 ` Michel Dänzer 2016-12-13 7:18 ` Michel Dänzer 2016-12-09 11:44 ` Benjamin Herrenschmidt 2016-12-09 11:44 ` Benjamin Herrenschmidt 2016-12-09 11:44 ` Benjamin Herrenschmidt 2016-12-09 12:33 ` Geert Uytterhoeven 2016-12-09 12:33 ` Geert Uytterhoeven 2016-12-09 12:33 ` Geert Uytterhoeven 2016-12-09 13:19 ` Lucas Stach 2016-12-09 13:19 ` Lucas Stach 2016-12-09 13:19 ` Lucas Stach 2016-12-09 13:33 ` Daniel Vetter 2016-12-09 13:33 ` Daniel Vetter 2016-12-09 13:33 ` Daniel Vetter 2016-12-09 13:57 ` David Herrmann 2016-12-09 13:57 ` David Herrmann 2016-12-09 13:57 ` David Herrmann 2016-12-09 14:04 ` Daniel Vetter 2016-12-09 14:04 ` Daniel Vetter 2016-12-09 14:04 ` Daniel Vetter 2016-12-09 20:29 ` Benjamin Herrenschmidt 2016-12-09 20:29 ` Benjamin Herrenschmidt 2016-12-09 20:29 ` Benjamin Herrenschmidt 2016-12-09 8:30 ` Daniel Vetter 2016-12-09 8:30 ` Daniel Vetter 2016-12-09 8:30 ` Daniel Vetter 2016-12-08 14:59 ` Jani Nikula 2016-12-08 14:59 ` Jani Nikula 2016-12-08 14:59 ` Jani Nikula 2016-12-08 14:22 ` Daniel Vetter 2016-12-08 14:22 ` Daniel Vetter 2016-12-08 14:22 ` Daniel Vetter 2016-12-08 21:28 ` Benjamin Herrenschmidt 2016-12-08 21:28 ` Benjamin Herrenschmidt 2016-12-08 21:28 ` Benjamin Herrenschmidt 2016-12-09 0:08 ` Dave Airlie 2016-12-09 0:08 ` Dave Airlie 2016-12-09 0:08 ` Dave Airlie 2016-12-09 8:04 ` Geert Uytterhoeven 2016-12-09 8:04 ` Geert Uytterhoeven 2016-12-09 11:40 ` Benjamin Herrenschmidt 2016-12-09 11:40 ` Benjamin Herrenschmidt 2016-12-09 11:40 ` Benjamin Herrenschmidt 2016-12-13 7:33 ` Gerd Hoffmann 2016-12-13 7:33 ` Gerd Hoffmann 2016-12-13 7:33 ` Gerd Hoffmann 2016-12-13 15:17 ` Laurent Pinchart 2016-12-13 15:17 ` Laurent Pinchart 2016-12-13 15:17 ` Laurent Pinchart
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.