Pull drm fixes from Dave Airlie:
"Intel: edid fixes, power consumption fix, s/r fix, haswell fix
Radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better
MSAA validation, lockup timeout fixes, modesetting fixes
One udl dpms fix, one vmwgfx fix, a couple of trivial core changes.
There is an export added to ACPI as part of the radeon bios fixes.
I've also included the fbcon flashing cursor vs deinit race fix, that
seems the simplest place to start"
Trivial conflict in drivers/video/console/fbcon.c due to me having
already applied the fbcon flashing cursor vs deinit race fix, and Dave
had added a comment in there too.
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (22 commits)
fbcon: fix race condition between console lock and cursor timer (v1.1)
drm: Add missing static storage class specifiers in drm_proc.c file
drm/udl: dpms off the crtc when disabled.
drm: Remove two unused fields from struct drm_display_mode
drm: stop vmgfx driver explosion
drm/radeon/ss: use num_crtc rather than hardcoded 6
Revert "drm/radeon: fix bo creation retry path"
drm/i915: use hsw rps tuning values everywhere on gen6+
drm/radeon: split ATRM support out from the ATPX handler (v3)
drm/radeon: convert radeon vfct code to use acpi_get_table_with_size
ACPI: export symbol acpi_get_table_with_size
drm/radeon: implement ACPI VFCT vbios fetch (v3)
drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping
drm/radeon: fix checking of MSAA renderbuffers on r600-r700
drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700
drm/radeon: init lockup timeout on ring init
drm/radeon: avoid turning off spread spectrum for used pll
drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
drm/i915: extract connector update from intel_ddc_get_modes() for reuse
drm/i915: fix hsw uncached pte
...
Fixes the following sparse warning:
drivers/gpu/drm/drm_proc.c:92:5:
warning: symbol 'drm_proc_create_files' was not declared. Should it be static?
drivers/gpu/drm/drm_proc.c:175:5:
warning: symbol 'drm_proc_remove_files' was not declared. Should it be static?
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This turns off the crtc when its been disabled,
fixes it not turning off properly the whole time.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
If you do a page flip with no flags set then event is NULL. If event is
NULL then the vmw_gfx driver likes to go digging into NULL and extracts
NULL->base.file_priv.
On a modern kernel with NULL mapping protection it's just another oops,
without it there are some "intriguing" possibilities.
What it should do is an open question but that for the driver owners to
sort out.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel writes:
" Nothing too major:
- A few fixes around the edid handling from Jani, also fixing a regression
in 3.5 due to us using gmbus by default.
- Fixup hsw uncached pte flags.
- Fix suspend/resume crash when using hw contexts, from Ben.
- Try to tune gpu turbo a bit better, seems to help with some oddball
power regressions."
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: use hsw rps tuning values everywhere on gen6+
drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
drm/i915: extract connector update from intel_ddc_get_modes() for reuse
drm/i915: fix hsw uncached pte
drm/i915/contexts: fix list corruption
drm/i915: fix EDID memory leak in SDVO
This reverts commit d1c7871ddb.
ttm_bo_init() destroys the BO on failure. So this patch makes
the retry path work with freed memory. This ends up causing
kernel panics when this path is hit.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Pull more USB patches from Greg Kroah-Hartman:
"Here are 10 more USB patches for 3.6-rc3. They all fix reported
problems (build problems for one of them, and easily repeatable oopses
for the others.)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'usb-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
gpu/mfd/usb: Fix USB randconfig problems
USB: CDC ACM: Fix NULL pointer dereference
USB: emi62: remove __devinit* from the struct usb_device_id table
USB: winbond: remove __devinit* from the struct usb_device_id table
USB: vt6656: remove __devinit* from the struct usb_device_id table
USB: rtl8187: remove __devinit* from the struct usb_device_id table
USB: p54usb: remove __devinit* from the struct usb_device_id table
USB: spca506: remove __devinit* from the struct usb_device_id table
USB: jl2005bcd: remove __devinit* from the struct usb_device_id table
USB: smsusb: remove __devinit* from the struct usb_device_id table
Fix config warning:
warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies
(USB_SUPPORT && USB_ARCH_HAS_HCD)
and build error:
ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined!
by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB.
This exposes:
drivers/video/Kconfig:36:error: recursive dependency detected!
drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI
drivers/usb/Kconfig:16: symbol USB_ARCH_HAS_OHCI depends on I2C
drivers/i2c/Kconfig:5: symbol I2C is selected by FB_DDC
drivers/video/Kconfig:86: symbol FB_DDC is selected by FB_CYBER2000_DDC
drivers/video/Kconfig:385: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
drivers/video/Kconfig:373: symbol FB_CYBER2000 depends on FB
which is due to drivers/usb/Kconfig:
config USB_ARCH_HAS_OHCI
...
default y if ARCH_PNX4008 && I2C
Fix by dropping I2C from the above dependency; logic is that this is not a
platform dependency but a configuration dependency: the _architecture_ still
supports USB even is I2C is not selected.
This exposes:
drivers/video/Kconfig:36:error: recursive dependency detected!
drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI
drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB
drivers/mfd/Kconfig:396: symbol MFD_TC6393XB depends on GPIOLIB
drivers/gpio/Kconfig:35: symbol GPIOLIB is selected by FB_VIA
drivers/video/Kconfig:1560: symbol FB_VIA depends on FB
which can be fixed by having MFD_TC6393XB select GPIOLIB instead of depending on
it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Bottomley reported [1] a massive power regression, due to the
enabling of semaphores by default in 3.5. A workaround for him is to
again disable semaphores. And indeed, his system has a very hard time
to enter rc6 with semaphores enabled.
Ben Widawsky run around with a kill-a-watt a lot and noticed:
- There are indeed a few rare systems that seem to have a hard time
entering rc6 when desktop-idle.
- One machine, The Indestructible Toshiba regressed in this behaviour
between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
current setting seems to be highly timing dependent and not robust
at all.
- The behaviour James reported wrt semaphores seems to be a freak
timing thing that only happens on his specific machine, confirming
that enabling semaphores shouldn't reduce rc6 residency.
Now furthermore the Google ChromeOS guys reported [2] a while ago that
at least on some machines a simply a blinking cursor can keep the gpu
turbo at the highest frequency. This is because the current rps limits
used on snb/ivb are highly asymmetric.
On the theory that gpu turbo and rc6 tuning values are related, we've
tried whether the much saner looking (since much less asymmetric) rps
tuning values used for hsw would also help entering rc6 more robustly.
And it seems to mostly work, and we don't really have the resources to
through-roughly tune things in any better way: The values from the
ChromeOS ppl seem to fare a bit worse for James' machine, so I guess
we better stick with something vpg (the gpu hw/windows group)
provided, hoping that they've done their jobs.
Reference[1]: http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
Reference[2]: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
Tested-by: Ben Widawsky <ben@bwidawsk.net>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is a more recent APU stepping with a new PCI ID
shipping in the same board by Fujitsu which needs the
same quirk to correctly mark the back plane connectors.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The MSAA checking was mostly unimplemented on r600-r700. The userspace
submits GPU commands and the kernel driver computes how much memory
the GPU will access and checks if it's all within buffer bounds the
userspace allocated. This patch fixes the computations of the size of
MSAA surfaces in memory.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reset the lockup timeout on ring (re-)initialisation.
Otherwise we get error messages like this on gpu resets:
[ 1559.949177] radeon 0000:01:00.0: GPU lockup CP stall for more than 1482270msec
Signed-off-by: Christian König <deathsimple@vodafone.de>
cc: stable@vger.kernel.org
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If spread spectrum is enabled and in use for a given pll we
should not turn it off as it will lead to turning off display
for crtc that use the pll (this behavior was observed on chelsea
edp).
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This callback is a no-op in nouveau, and the upcoming apple-gmux
switcheroo support won't require it either. Rather than forcing drivers
to stub it out, just make it optional and remove the callback from
nouveau.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
vga_switcheroo assumes that the handler will be registered before the
last client, otherwise switching will not be enabled. Likewise it's
assumed that the handler will not be unregistered without at least one
client also being unregistered, otherwise switching will remain enabled
despite no longer having a handler. These assumptions cannot be enforced
if the handler is in a separate driver from both clients, as with the
gmux found in Apple laptops. Remove this assumption.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
After reset we unconditionally reinitialize lists. If the context switch
hasn't yet completed before the suspend, the default context object will
end up on lists that are going to go away when we resume.
The patch forces the context switch to be synchronous before suspend
assuring that the active/inactive tracking is correct at the time of
resume.
References: https://bugs.freedesktop.org/show_bug.cgi?id=52429
Tested-by: Guang A Yang <guang.a.yang@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
