user/sven/linux.git/include/video, branch v4.18.12

udlfb: make a local copy of fb_ops

2018-09-09T08:32:40Z

commit 2c29cfc3eaf11779176bf41475cfca49bccba11c upstream. The defio subsystem overwrites the method fb_osp->mmap. That method is stored in module's static data - and that means that if we have multiple diplaylink adapters, they will over write each other's method. In order to avoid interference between multiple adapters, we copy the fb_ops structure to a device-local memory. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

udlfb: set optimal write delay

2018-09-09T08:32:40Z

commit bb24153a3f13dd0dbc1f8055ad97fe346d598f66 upstream. The default delay 5 jiffies is too much when the kernel is compiled with HZ=100 - it results in jumpy cursor in Xwindow. In order to find out the optimal delay, I benchmarked the driver on 1280x720x30fps video. I found out that with HZ=1000, 10ms is acceptable, but with HZ=250 or HZ=300, we need 4ms, so that the video is played without any frame skips. This patch changes the delay to this value. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

udlfb: don't switch if we are switching to the same videomode

2018-09-09T08:32:40Z

commit 564f1807379298dfdb12ed0d5b25fcb89c238527 upstream. The udlfb driver reprograms the hardware everytime the user switches the console, that makes quite unusable when working on the console. This patch makes the driver remember the videomode we are in and avoid reprogramming the hardware if we switch to the same videomode. We mask the "activate" field and the "FB_VMODE_SMOOTH_XPAN" flag when comparing the videomode, because they cause spurious switches when switching to and from the Xserver. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

udlfb: fix semaphore value leak

2018-09-09T08:32:40Z

commit 9d0aa601e4cd9c0892f90d36e8488d79b72f4073 upstream. I observed that the performance of the udl fb driver degrades over time. On a freshly booted machine, it takes 6 seconds to do "ls -la /usr/bin"; after some time of use, the same operation takes 14 seconds. The reason is that the value of "limit_sem" decays over time. The udl driver uses a semaphore "limit_set" to specify how many free urbs are there on dlfb->urbs.list. If the count is zero, the "down" operation will sleep until some urbs are added to the freelist. In order to avoid some hypothetical deadlock, the driver will not call "up" immediately, but it will offload it to a workqueue. The problem is that if we call "schedule_delayed_work" on the same work item multiple times, the work item may only be executed once. This is happening: * some urb completes * dlfb_urb_completion adds it to the free list * dlfb_urb_completion calls schedule_delayed_work to schedule the function dlfb_release_urb_work to increase the semaphore count * as the urb is on the free list, some other task grabs it and submits it * the submitted urb completes, dlfb_urb_completion is called again * dlfb_urb_completion calls schedule_delayed_work, but the work is already scheduled, so it does nothing * finally, dlfb_release_urb_work is called, it increases the semaphore count by 1, although it should increase it by 2 So, the semaphore count is decreasing over time, and this causes gradual performance degradation. Note that in the current kernel, the "up" function may be called from interrupt and it may race with the "down" function called by another thread, so we don't have to offload the call of "up" to a workqueue at all. This patch removes the workqueue code. The patch also changes "down_interruptible" to "down" in dlfb_free_urb_list, so that we will clean up the driver properly even if a signal arrives. With this patch, the performance of udlfb no longer degrades. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org [b.zolnierkie: fix immediatelly -> immediately typo] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

Merge tag 'fbdev-v4.18' of git://github.com/bzolnier/linux

2018-06-16T20:00:24Z

Pull fbdev updates from Bartlomiej Zolnierkiewicz: "There is nothing really major here, few small fixes, some cleanups and dead drivers removal: - mark omapfb drivers as orphans in MAINTAINERS file (Tomi Valkeinen) - add missing module license tags to omap/omapfb driver (Arnd Bergmann) - add missing GPIOLIB dependendy to omap2/omapfb driver (Arnd Bergmann) - convert savagefb, aty128fb & radeonfb drivers to use msleep & co. (Jia-Ju Bai) - allow COMPILE_TEST build for viafb driver (media part was reviewed by media subsystem Maintainer) - remove unused MERAM support from sh_mobile_lcdcfb and shmob-drm drivers (drm parts were acked by shmob-drm driver Maintainer) - remove unused auo_k190xfb drivers - misc cleanups (Souptick Joarder, Wolfram Sang, Markus Elfring, Andy Shevchenko, Colin Ian King)" * tag 'fbdev-v4.18' of git://github.com/bzolnier/linux: (26 commits) fb_omap2: add gpiolib dependency video/omap: add module license tags MAINTAINERS: make omapfb orphan video: fbdev: pxafb: match_string() conversion fixup video: fbdev: nvidia: fix spelling mistake: "scaleing" -> "scaling" video: fbdev: fix spelling mistake: "frambuffer" -> "framebuffer" video: fbdev: pxafb: Convert to use match_string() helper video: fbdev: via: allow COMPILE_TEST build video: fbdev: remove unused sh_mobile_meram driver drm: shmobile: remove unused MERAM support video: fbdev: sh_mobile_lcdcfb: remove unused MERAM support video: fbdev: remove unused auo_k190xfb drivers video: omap: Improve a size determination in omapfb_do_probe() video: sm501fb: Improve a size determination in sm501fb_probe() video: fbdev-MMP: Improve a size determination in path_init() video: fbdev-MMP: Delete an error message for a failed memory allocation in two functions video: auo_k190x: Delete an error message for a failed memory allocation in auok190x_common_probe() video: sh_mobile_lcdcfb: Delete an error message for a failed memory allocation in two functions video: sh_mobile_meram: Delete an error message for a failed memory allocation in sh_mobile_meram_probe() video: fbdev: sh_mobile_meram: Drop SUPERH platform dependency ...

video: fbdev: remove unused sh_mobile_meram driver

2018-05-14T13:47:30Z

Since commit a521422ea4ae ("ARM: shmobile: mackerel: Remove Legacy C board code") MERAM functionality is unused. Remove it. Reviewed-by: Simon Horman Reviewed-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Acked-by: Daniel Vetter Signed-off-by: Bartlomiej Zolnierkiewicz

video: fbdev: sh_mobile_lcdcfb: remove unused MERAM support

2018-05-14T13:47:30Z

video: fbdev: remove unused auo_k190xfb drivers

2018-05-14T13:47:30Z

auo_k1900fb and auo_k1901fb drivers have been introduced six years ago by following commits: commit 2c8304d3125b ("video: auo_k190x: add code shared by controller drivers") commit 96b1d500e028 ("video: auo_k190x: add driver for AUO-K1900 variant") commit 53027cdf2a67 ("video: auo_k190x: add driver for AUO-K1901 variant") They never had any in-kernel user so just remove them (since they are platform drivers they need corresponding platform devices to be registered by kernel and it has never happened). Reviewed-by: Heiko Stuebner Signed-off-by: Bartlomiej Zolnierkiewicz

media: include/video/omapfb_dss.h: use IS_ENABLED()

2018-05-05T15:45:51Z

Just checking for ifdefs cause build issues as reported by kernel test: config: openrisc-allmodconfig (attached as .config) compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental) All errors (new ones prefixed by >>): drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 'omapfb_init_connections': >> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:8: error: implicit declaration of function 'omapdss_find_mgr_from_display' [-Werror=implicit-function-declaration] mgr = omapdss_find_mgr_from_display(def_dssdev); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion] mgr = omapdss_find_mgr_from_display(def_dssdev); ^ drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 'omapfb_find_default_display': >> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:13: error: implicit declaration of function 'omapdss_get_default_display_name' [-Werror=implicit-function-declaration] def_name = omapdss_get_default_display_name(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:11: warning: assignment makes pointer from integer without a cast [-Wint-conversion] def_name = omapdss_get_default_display_name(); ^ So, use IS_ENABLED() instead. Fixes: 771f7be87ff9 ("media: omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP") Cc: Bartlomiej Zolnierkiewicz Cc: Randy Dunlap Cc: tomi.valkeinen@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab

media: omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

2018-05-04T13:54:47Z

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'. That allows building such driver(s) with COMPILE_TEST. Signed-off-by: Mauro Carvalho Chehab Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Mauro Carvalho Chehab