linux-toradex.git/drivers/gpu, branch v2.6.32.21

drm: stop information leak of old kernel stack.

2010-08-26T23:41:56+00:00

commit b9f0aee83335db1f3915f4e42a5e21b351740afd upstream.

non-critical issue, CVE-2010-2803

Userspace controls the amount of memory to be allocate, so it can
get the ioctl to allocate more memory than the kernel uses, and get
access to kernel stack. This can only be done for processes authenticated
to the X server for DRI access, and if the user has DRI access.

Fix is to just memset the data to 0 if the user doesn't copy into
it in the first place.

Reported-by: Kees Cook 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: fix typo in radeon_compute_pll_gain

2010-08-26T23:41:55+00:00

commit 0537398b211b4f040564beec458e23571042d335 upstream.

Looks like this got copied from the ddx wrong.

Cc: Benjamin Herrenschmidt 
Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: add 'reclaimable' to i915 self-reclaimable page allocations

2010-08-26T23:41:46+00:00

commit cd9f040df6ce46573760a507cb88192d05d27d86 upstream.

The hibernate issues that got fixed in commit 985b823b9192 ("drm/i915:
fix hibernation since i915 self-reclaim fixes") turn out to have been
incomplete.  Vefa Bicakci tested lots of hibernate cycles, and without
the __GFP_RECLAIMABLE flag the system eventually fails to resume.

With the flag added, Vefa can apparently hibernate forever (or until he
gets bored running his automated scripts, whichever comes first).

The reclaimable flag was there originally, and was one of the flags that
were dropped (unintentionally) by commit 4bdadb978569 ("drm/i915:
Selectively enable self-reclaim") that introduced all these problems,
but I didn't want to just blindly add back all the flags in commit
985b823b9192, and it looked like __GFP_RECLAIM wasn't necessary.  It
clearly was.

I still suspect that there is some subtle reason we're missing that
causes the problems, but __GFP_RECLAIMABLE is certainly not wrong to use
in this context, and is what the code historically used.  And we have no
idea what the causes the corruption without it.

Reported-and-tested-by: M. Vefa Bicakci 
Cc: Dave Airlie 
Cc: Chris Wilson 
Cc: KOSAKI Motohiro 
Cc: Hugh Dickins 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix hibernation since i915 self-reclaim fixes

2010-08-26T23:41:46+00:00

commit 985b823b919273fe1327d56d2196b4f92e5d0fae upstream.

Since commit 4bdadb9785696439c6e2b3efe34aa76df1149c83 ("drm/i915:
Selectively enable self-reclaim"), we've been passing GFP_MOVABLE to the
i915 page allocator where we weren't before due to some over-eager
removal of the page mapping gfp_flags games the code used to play.

This caused hibernate on Intel hardware to result in a lot of memory
corruptions on resume.  See for example

  http://bugzilla.kernel.org/show_bug.cgi?id=13811

Reported-by: Evengi Golov (in bugzilla)
Signed-off-by: Dave Airlie 
Tested-by: M. Vefa Bicakci 
Cc: Chris Wilson 
Cc: KOSAKI Motohiro 
Cc: Hugh Dickins 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drm/i915/edp: Flush the write before waiting for PLLs

2010-08-26T23:41:42+00:00

commit 5ddb954b9ee50824977d2931e0ff58b3050b337d upstream.

Signed-off-by: Chris Wilson 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Use RSEN instead of HTPLG for tfp410 monitor detection.

2010-08-13T20:19:52+00:00

commit f458823b864c6def488f951a79986fa205aba4f1 upstream.

Presence detection of a digital monitor seems not to be reliable using
the HTPLG bit.

Dave Müller 
Signed-off-by: Greg Kroah-Hartman

drm/edid: Fix the HDTV hack sync adjustment

2010-08-13T20:19:47+00:00

commit a4967de6cbb260ad0f6612a1d2035e119ef1578f upstream.

We're adjusting horizontal timings only here, moving vsync was just a
slavish translation of a typo in the X server.

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

drm/i915: parse child device from VBT

2010-08-10T17:20:48+00:00

commit 6363ee6f496eb7e3b3f78dc105e522c7b496089b upstream.

On some laptops there is no HDMI/DP. But the xrandr still reports
several disconnected HDMI/display ports. In such case the user will be
confused.
 >DVI1 disconnected (normal left inverted right x axis y axis)
 >DP1 disconnected (normal left inverted right x axis y axis)
 >DVI2 disconnected (normal left inverted right x axis y axis)
 >DP2 disconnected (normal left inverted right x axis y axis)
 >DP3 disconnected (normal left inverted right x axis y axis)

This patch set is to use the child device parsed in VBT to decide whether
the HDMI/DP/LVDS/TV should be initialized.

Parse the child device from VBT.

The device class type is also added for LFP, TV, HDMI, DP output.

https://bugs.freedesktop.org/show_bug.cgi?id=22785

Signed-off-by: Zhao Yakui 
Reviewed-by: Adam Jackson 
Signed-off-by: Eric Anholt 
Acked-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix LVDS presence check

2010-08-10T17:20:48+00:00

Combined patches from 2.6.33 for fixing LVDS detection.
7cf4f69d3f4511f443473954456cb91d5514756d
    drm/i915: Don't set up the LVDS if it isn't in the BIOS device table.
38b3037ee47fbd65a36bc7c39f60a900fbbe3b8e
    drm/i915: Fix LVDS presence check
6e36595a2131e7ed5ee2674be54b2713ba7f0490
    drm/i915: Declare the new VBT parsing functions as static
11ba159288f1bfc1a475c994e598f5fe423fde9d
    drm/i915: Don't check for lid presence when detecting LVDS

Acked-by: Takashi Iwai 
Cc: Matthew Garrett 
Cc: Adam Jackson 
Cc: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: fix legacy LVDS dpms sequence

2010-08-02T17:20:49+00:00

commit 15cb02c0a0338ee724bf23e31c7c410ecbffeeba upstream.

Add delay after turning off the LVDS encoder.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16389

Tested-by: Jan Kreuzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman