linux/drivers/gpu/drm, branch v3.5-rc6

drm/i915: kick any firmware framebuffers before claiming the gtt

2012-07-03T10:18:48Z

Especially vesafb likes to map everything as uc- (yikes), and if that mapping hangs around still while we try to map the gtt as wc the kernel will downgrade our request to uc-, resulting in abyssal performance. Unfortunately we can't do this as early as readon does (i.e. as the first thing we do when initializing the hw) because our fb/mmio space region moves around on a per-gen basis. So I've had to move it below the gtt initialization, but that seems to work, too. The important thing is that we do this before we set up the gtt wc mapping. Now an altogether different question is why people compile their kernels with vesafb enabled, but I guess making things just work isn't bad per se ... v2: - s/radeondrmfb/inteldrmfb/ - fix up error handling v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky. v4: Jani Nikula complained about the pointless bool primary initialization. v5: Don't oops if we can't allocate, noticed by Chris Wilson. v6: Resolve conflicts with agp rework and fixup whitespace. This is commit e188719a2891f01b3100d in drm-next. Backport to 3.5 -fixes queue requested by Dave Airlie - due to grub using vesa on fedora their initrd seems to load vesafb before loading the real kms driver. So tons more people actually experience a dead-slow gpu. Hence also the Cc: stable. Cc: stable@vger.kernel.org Reported-and-tested-by: "Kilarski, Bernard R" Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie

drm: edid: Don't add inferred modes with higher resolution

2012-07-03T10:18:10Z

When a monitor EDID doesn't give the preferred bit, driver assumes that the mode with the higest resolution and rate is the preferred mode. Meanwhile the recent changes for allowing more modes in the GFT/CVT ranges give actually more modes, and some modes may be over the native size. Thus such a mode would be picked up as the preferred mode although it's no native resolution. For avoiding such a problem, this patch limits the addition of inferred modes by checking not to be greater than other modes. Also, it checks the duplicated mode entry at the same time. Reviewed-by: Adam Jackson Signed-off-by: Takashi Iwai Signed-off-by: Dave Airlie

drm/radeon: fix rare segfault

2012-07-03T10:17:09Z

In gem idle/busy ioctl the radeon object was derefenced after drm_gem_object_unreference_unlocked which in case the object have been destroyed lead to use of a possibly free pointer with possibly wrong data. Signed-off-by: Jerome Glisse Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Dave Airlie

drm/radeon: fix VM page table setup on SI

2012-06-29T14:13:07Z

Cayman and trinity allow for variable sized VM page tables, but SI requires that all page tables be the same size. The current code assumes variablely sized VM page tables so SI may end up with part of each page table overlapping with other memory which could end up being interpreted by the VM hw as garbage. Change the code to better accomodate SI. Allocate enough space for at least 2 full page tables and always set last_pfn to max_pfn on SI so each VM is backed by a full page table. This limits us to only 2 VMs active at any given time on SI. This will be rectified and the code can be reunified once we move to two level page tables. Signed-off-by: Alex Deucher Reviewed-by: Jerome Glisse Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie

Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

2012-06-27T18:56:20Z

Daniel writes: "Two tiny patches and one revert: - Kill a bogus error message introduced in 3.4, further Bspec reading indicates that this is how the hw is supposed to work. - Reorder one backlight register restore, fixing broken backlight on some machines after resume. - Revert a hack from Jesse for ivb backlight control - it breaks the backlight controls on my shiny new ivb laptop." * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: Revert "drm/i915: allow PCH PWM override on IVB" drm/i915: Fix eDP blank screen after S3 resume on HP desktops drm/i915: rip out the PM_IIR WARN

Revert "drm/i915: allow PCH PWM override on IVB"

2012-06-27T18:26:30Z

This reverts commit f82cfb6bcda164ef3a66b8c3fc549b1f9bdd09ad. This breaks the backlight controls on my IVB asus zenbook with an eDP panel. I guess the right fix would be to read this bit and use either the pch or the cpu register to frob the backlight values. But that is stuff for -next. Cc: Jesse Barnes Signed-Off-by: Daniel Vetter

drm/nouveau: add license header to prime.

2012-06-27T08:27:35Z

Just forgot this when I posted it, and yes I'm the only person to have changed the file since. Signed-off-by: Dave Airlie

drm/nouveau/fbcon: using nv_two_heads is not a good idea

2012-06-26T11:16:43Z

nv_two_heads() was never meant to be used outside of pre-nv50 code. The code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific chipsets to 1 CRTC based on (pci_device & 0x0ff0). The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing memory corruption because there's actually 2 CRTCs.. This switches fbcon to use the CRTC count directly from the mode_config structure, which will also fix the same issue on Kepler boards which have 4 CRTCs. Signed-off-by: Ben Skeggs Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie

drm/udl: Make sure to get correct endian keys from vendor descriptor

2012-06-25T06:43:12Z

This is a port of commit b49f184b640dcfab7ede394cf2a1ff4fe3d154f5 Author: Ben Collins from udlfb to udl kms driver. The driver was not using le16_to_cpu when reading keys from the vendor descriptor, causing incorrect parsing. Mainly, sku_pixel_limit was not being parsed on big-endian systems. This would result in a blank screen on big-endian CPUs where the DL chips's max mode was smaller than the monitor's native mode. Signed-off-by: Dave Airlie

drm/i915: Fix eDP blank screen after S3 resume on HP desktops

2012-06-22T22:01:42Z

This patch fixes the problem on some HP desktop machines with eDP which give blank screens after S3 resume. It turned out that BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these SNB machines. Tested with 3.5-rc3 kernel. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Daniel Vetter