linux-stable.git/drivers/gpu/drm/udl, branch linux-3.4.y

udl: handle EDID failure properly.

2013-04-17T04:27:26+00:00

commit 1baee58638fc58248625255f5c5fcdb987f11b1f upstream.

Don't oops seems proper.

Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/udl: disable fb_defio by default

2013-02-28T14:59:03+00:00

commit 677d23b70bf949f75746c80cbae92c233c6b5e2a upstream.

There seems to be a bad interaction between gem/shmem and defio on top,
I get list corruption on the page lru in the shmem code.

Turn it off for now until we get some more digging done.

Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/udl: make usage as a console safer

2013-02-28T14:59:03+00:00

commit bcb39af4486be07e896fc374a2336bad3104ae0a upstream.

Okay you don't really want to use udl devices as your console, but if
you are unlucky enough to do so, you run into a lot of schedule while atomic
due to printk being called from all sorts of funky places. So check if we
are in an atomic context, and queue the damage for later, the next printk
should cause it to appear. This isn't ideal, but it is simple, and seems to
work okay in my testing here.

(dirty area idea came from xenfb)

fixes a bunch of sleeping while atomic issues running fbcon on udl devices.

Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

udldrmfb: udl_get_edid: drop unneeded i--

2013-01-17T16:50:55+00:00

commit 7b4cf994e4c6ba48872bb25253cc393b7fb74c82 upstream.

This is a left-over from when udl_get_edid returned the amount of bytes
successfully read, which it no longer does.

Signed-off-by: Hans de Goede 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

udldrmfb: udl_get_edid: usb_control_msg buffer must not be on the stack

2013-01-17T16:50:55+00:00

commit 242187b362555849e8c971dfbbfd55f8bd9fa717 upstream.

The buffer passed to usb_control_msg may end up in scatter-gather list, and
may thus not be on the stack. Having it on the stack usually works on x86, but
not on other archs.

Signed-off-by: Hans de Goede 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

udldrmfb: Fix EDID not working with monitors with EDID extension blocks

2013-01-17T16:50:54+00:00

commit c930812fe5ebe725760422c9c351d1f6fde1502d upstream.

udldrmfb only reads the main EDID block, and if that advertises extensions
the drm_edid code expects them to be present, and starts reading beyond the
buffer udldrmfb passes it.

Although it may be possible to read more EDID info with the udl we simpy don't
know how, and even if trial and error gets it working on one device, that is
no guarantee it will work on other revisions. So this patch does a simple fix
in the form of patching the EDID info to report 0 extension blocks, this
fixes udldrmfb only doing 1024x768 on monitors with EDID extension blocks.

Signed-off-by: Hans de Goede 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/udl: fix stride issues scanning out stride != width*bpp

2012-11-17T21:16:03+00:00

commit 3916e1d71b62b120888aa50bcc8d9a6200fc19a7 upstream.

When buffer sharing with the i915 and using a 1680x1050 monitor,
the i915 gives is a 6912 buffer for the 6720 width, the code doesn't
render this properly as it uses one value to set the base address for
reading from the vmap and for where to start on the device.

This fixes it by calculating the values correctly for the device and
for the pixmap. No idea how I haven't seen this before now.

Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/udl: limit modes to the sku pixel limits.

2012-10-02T17:30:48+00:00

commit 3a75885848996baab5276ff37ebf7295c3c753f0 upstream.

Otherwise when X starts we commonly get a black screen scanning
out nothing, its wierd dpms on/off from userspace brings it back,

With this on F18, multi-seat works again with my 1920x1200 monitor
which is above the sku limit for the device I have.

Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/udl: only bind to the video devices on the hub.

2012-06-22T18:36:53+00:00

commit e5a867a51d9b009f90d5dca6a320608e4e8a37ec upstream.

This is ported from udlfb.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=832188
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

mm, drm/udl: fixup vma flags on mmap

2012-04-02T10:08:17+00:00

There should be VM_MIXEDMAP, not VM_PFNMAP, because udl_gem_fault() inserts
pages via vm_insert_page(). Other drm/gem drivers already do this.

Signed-off-by: Konstantin Khlebnikov 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie