linux.git/drivers/video/fbmem.c, branch master

video: move fbdev to drivers/video/fbdev

2014-04-17T05:10:19+00:00

The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.

Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.

No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
Acked-by: Geert Uytterhoeven 
Acked-by: Rob Clark 
Acked-by: Jingoo Han 
Acked-by: Daniel Vetter

fbdev: Make the switch from generic to native driver less alarming

2014-04-03T09:47:16+00:00

Calling this "conflicting" just makes people think there's a problem
when there's not.

Signed-off-by: Adam Jackson 
Reviewed-by: David Herrmann 
Signed-off-by: Tomi Valkeinen

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

2014-01-30T04:49:12+00:00

Pull drm updates from Dave Airlie:
 "Been a bit busy, first week of kids school, and waiting on other trees
  to go in before I could send this, so its a bit later than I'd
  normally like.

  Highlights:
   - core:
      timestamp fixes, lots of misc cleanups
   - new drivers:
      bochs virtual vga
   - vmwgfx:
      major overhaul for their nextgen virt gpu.
   - i915:
      runtime D3 on HSW, watermark fixes, power well work, fbc fixes,
      bdw is no longer prelim.
   - nouveau:
      gk110/208 acceleration, more pm groundwork, old overlay support
   - radeon:
      dpm rework and clockgating for CIK, pci config reset, big endian
      fixes
   - tegra:
      panel support and DSI support, build as module, prime.
   - armada, omap, gma500, rcar, exynos, mgag200, cirrus, ast:
      fixes
   - msm:
      hdmi support for mdp5"

* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (595 commits)
  drm/nouveau: resume display if any later suspend bits fail
  drm/nouveau: fix lock unbalance in nouveau_crtc_page_flip
  drm/nouveau: implement hooks for needed for drm vblank timestamping support
  drm/nouveau/disp: add a method to fetch info needed by drm vblank timestamping
  drm/nv50: fill in crtc mode struct members from crtc_mode_fixup
  drm/radeon/dce8: workaround for atom BlankCrtc table
  drm/radeon/DCE4+: clear bios scratch dpms bit (v2)
  drm/radeon: set si_notify_smc_display_change properly
  drm/radeon: fix DAC interrupt handling on DCE5+
  drm/radeon: clean up active vram sizing
  drm/radeon: skip async dma init on r6xx
  drm/radeon/runpm: don't runtime suspend non-PX cards
  drm/radeon: add ring to fence trace functions
  drm/radeon: add missing trace point
  drm/radeon: fix VMID use tracking
  drm: ast,cirrus,mgag200: use drm_can_sleep
  drm/gma500: Lock struct_mutex around cursor updates
  drm/i915: Fix the offset issue for the stolen GEM objects
  DRM: armada: fix missing DRM_KMS_FB_HELPER select
  drm/i915: Decouple GPU error reporting from ring initialisation
  ...

fbmem: really support wildcard video=options for all fbdev drivers

2014-01-17T08:57:45+00:00

Documentation/fb/modedb.txt states that video=option should be
considered a global option. But video_setup and fb_get_options are not
coded that way. Instead its required to boot with video=driver:option to
set a given option in drvier.  This is cumbersome because it requires to
know in advance which driver will be active for a given board/kernel.

The following patch implements the documented catchall for the fbdev
drivers. It is now possible to boot with video=XxY without the need to
know the active driver in advance. The specific case it tries to fix is
syslinux in the SUSE installer which offers a menu to set a display
resolution. Right now this just appends the vga= option the kernel. But
in addition to vga= it should be possible to pass a generic video=XxY
for all framebuffer/drm drivers. With this change forcing a certain
window size of VM displays is now much easier.

Today the video= option is stored in a global fb_mode_option. But
unfortunately only drm uses it.

Note: this change introduces a small memleak if video=option is actually
used because fb_mode_option is const. Most drivers use strsep to get to
individual options. This could be fixed in a followup patch which always
releases the option string in every caller of fb_get_options.

Signed-off-by: Olaf Hering 
Signed-off-by: Tomi Valkeinen

video/fb: Propagate error code from failing to unregister conflicting fb

2013-12-18T00:56:13+00:00

If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.

Signed-off-by: Chris Wilson 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie

fb: reorder the lock sequence to fix potential dead lock

2013-11-11T13:52:59+00:00

Following commits:

50e244cc79 fb: rework locking to fix lock ordering on takeover
e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
054430e773 fbcon: fix locking harder

reworked locking to fix related lock ordering on takeover, and introduced console_lock
into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
a potential dead lock as following:

[  601.079000] ======================================================
[  601.079000] [ INFO: possible circular locking dependency detected ]
[  601.079000] 3.11.0 #189 Not tainted
[  601.079000] -------------------------------------------------------
[  601.079000] kworker/0:3/619 is trying to acquire lock:
[  601.079000]  (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x26/0x60
[  601.079000]
but task is already holding lock:
[  601.079000]  (console_lock){+.+.+.}, at: [] console_callback+0x13/0x160
[  601.079000]
which lock already depends on the new lock.

[  601.079000]
the existing dependency chain (in reverse order) is:
[  601.079000]
-> #1 (console_lock){+.+.+.}:
[  601.079000]        [] lock_acquire+0xa1/0x140
[  601.079000]        [] console_lock+0x77/0x80
[  601.079000]        [] register_framebuffer+0x1d8/0x320
[  601.079000]        [] efifb_probe+0x408/0x48f
[  601.079000]        [] platform_drv_probe+0x43/0x80
[  601.079000]        [] driver_probe_device+0x8b/0x390
[  601.079000]        [] __driver_attach+0xab/0xb0
[  601.079000]        [] bus_for_each_dev+0x5d/0xa0
[  601.079000]        [] driver_attach+0x1e/0x20
[  601.079000]        [] bus_add_driver+0x117/0x290
[  601.079000]        [] driver_register+0x7a/0x170
[  601.079000]        [] __platform_driver_register+0x4a/0x50
[  601.079000]        [] platform_driver_probe+0x1d/0xb0
[  601.079000]        [] efifb_init+0x273/0x292
[  601.079000]        [] do_one_initcall+0x102/0x1c0
[  601.079000]        [] kernel_init_freeable+0x15d/0x1ef
[  601.079000]        [] kernel_init+0xe/0xf0
[  601.079000]        [] ret_from_fork+0x7c/0xb0
[  601.079000]
-> #0 (&fb_info->lock){+.+.+.}:
[  601.079000]        [] __lock_acquire+0x1e18/0x1f10
[  601.079000]        [] lock_acquire+0xa1/0x140
[  601.079000]        [] mutex_lock_nested+0x7a/0x3b0
[  601.079000]        [] lock_fb_info+0x26/0x60
[  601.079000]        [] fbcon_blank+0x29b/0x2e0
[  601.079000]        [] do_blank_screen+0x1d8/0x280
[  601.079000]        [] console_callback+0x64/0x160
[  601.079000]        [] process_one_work+0x1f5/0x540
[  601.079000]        [] worker_thread+0x11c/0x370
[  601.079000]        [] kthread+0xed/0x100
[  601.079000]        [] ret_from_fork+0x7c/0xb0
[  601.079000]
other info that might help us debug this:

[  601.079000]  Possible unsafe locking scenario:

[  601.079000]        CPU0                    CPU1
[  601.079000]        ----                    ----
[  601.079000]   lock(console_lock);
[  601.079000]                                lock(&fb_info->lock);
[  601.079000]                                lock(console_lock);
[  601.079000]   lock(&fb_info->lock);
[  601.079000]
 *** DEADLOCK ***

so we reorder the lock sequence the same as it in console_callback() to
avoid this issue. And following Tomi's suggestion, fix these similar
issues all in fb subsystem.

Signed-off-by: Gu Zheng 
Signed-off-by: Tomi Valkeinen

fbmem: move EXPORT_SYMBOL annotation next to symbol declarations

2013-08-30T08:44:24+00:00

Just a cosmetic thing to bring that file in line with others in the
tree.

Signed-off-by: Daniel Mack 
Signed-off-by: Tomi Valkeinen

Merge tag 'fbdev-3.11-2' of git://gitorious.org/linux-omap-dss2/linux into fbdev/for-next

2013-06-28T10:01:28+00:00

Various fbdev changes for 3.11

* xilinxfb updates
* Small cleanups and fixes to multiple drivers

fb: make fp_get_options name argument const

2013-06-27T08:53:30+00:00

drm_get_connector_name now returns a const value, which causes the following
compilation warning:

  drivers/gpu/drm/drm_fb_helper.c: In function ‘drm_fb_helper_parse_command_line’:
  drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of ‘fb_get_options’ discards ‘const’ qualifier from pointer target type [enabled by default]
  In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
  include/linux/fb.h:627:12: note: expected ‘char *’ but argument is of type ‘const char *’

As fb_get_options uses its name argument as read only, make it const. This
fixes the aforementioned compilation warning.

Signed-off-by: Vincent Stehlé 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Dave Airlie 
Cc: trivial@kernel.org
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD

fbmem: return -EFAULT on copy_to_user() failure

2013-06-26T13:03:36+00:00

copy_to_user() returns the number of bytes remaining to be copied.
put_user() returns -EFAULT on error.

This function ORs a bunch of stuff together and returns jumbled non-zero
values on error.  It should return -EFAULT.

Signed-off-by: Dan Carpenter 
Signed-off-by: Tomi Valkeinen