There was some merge conflicts in -next and they weren't so pretty, so
backmerge now to avoid them.
Conflicts:
drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/intel_modes.c
If we have a 266MHz part we set core_freq to 0 in several spots
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Another reference to raw_edid field of struct drm_display_info was added in
gma500 while the whole field was being removed, causing build
failure. Remove the hopefully last references to raw_edid.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Fixes the following sparse warning:
drivers/gpu/drm/drm_fb_helper.c:239:6: warning:
symbol 'drm_fb_helper_force_kernel_mode' was not declared. Should it be static?
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes the following sparse warning:
drivers/gpu/drm/drm_irq.c:1239:6:
warning: symbol 'drm_handle_vblank_events' was not declared. Should it be static?
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.
Also remove the suspend function since all it does is log.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Neither the drm core nor any of the drivers really need the raw_edid field
of struct drm_display_info for anything. Instead of being useful, it
creates confusion about who is responsible for freeing the memory it points
to and setting the field to NULL afterwards, leading to memory leaks and
dangling pointers.
Remove the raw_edid field, and fix drivers as necessary.
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The EDID returned by drm_get_edid() was never freed.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The EDID returned by drm_get_edid() was never freed.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We should be making this call not praying that the values are right.
In addition as noted by Josiah Standing we should be calling this
for eDP as well.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The private gem_create_mmap_offset() function is now implemented in the
DRM core as drm_gem_create_mmap_offset(). Use it and kill the private
copy.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I don't know why the DP/eDP is affected by the clock gating. But the test
shows that it really fixes the DP/eDP clock issue during enabling DP/eDP.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[Updated to only apply the workaround if the device has DP. We don't want
to do this on netbooks]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Introduce the eDP support into the driver.
This has been reworked a bit because kernel driver proper uses encoder/connectors
while the legacy Intel driver uses the old output stuff.
It also diverges on the backlight handling. The legacy Intel driver adds a panel
abstraction based upon the i915 one. It's only really used for backlight bits
and we have a perfectly good backlight abstraction which can extend instead.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[ported to upstream driver, redid backlight abstraction]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Based on bits from Yakui <yakui.zhao@intel.com>
We can import various little bits of code before we plumb it all
in and hopefully this way catch any regressions more easily.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Import the pieces we need in order to do DisplayPort. Don't wire them
up yet as there is work to do to integrate them.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Based on the spec, the CRT output doesn't use the lane. And the HDMI B output
uses the Lane0/1 while the HDMI C output uses the Lane 2/3. But currently
it will program all the four lanes for the CRT/HDMI.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[Ported to the in-kernel driver]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Currently when trying to call the DPMS off again for one CRTC with DPMS off,
it will firstly disable the SR and can't enable it again because of the
incorrect check/logic. In such case the self refresh is still disabled
although one CRTC pipe is active. This is wrong.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[Ported to in kernel driver]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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
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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAlAyjj4ACgkQMUfUDdst+yn8gQCgkNpc92Ux5hBYJIX/AQYoBrTB
ktAAoLiXxIhVP+D4C42R1VLw9vGeB1QH
=+8kb
-----END PGP SIGNATURE-----
Merge tag 'usb-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
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>
This is required for pure UEFI systems. The vbios is stored
in ACPI rather than at the legacy vga location.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891
V2: fix #ifdefs as per Greg's comments
V3: fix it harder
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
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>
MSAA is impossible without them.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.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>
GMBUS was enabled over bit-banging as the default in commits:
commit c3dfefa0a6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Feb 14 22:37:25 2012 +0100
drm/i915: reenable gmbus on gen3+ again
and
commit 0fb3f969c8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Mar 2 19:38:30 2012 +0100
drm/i915: enable gmbus on gen2
Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging
fallback to CRT EDID reads.
LKML-Reference: <201207251020.47637.maciej.rutecki@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Alex Ferrando <alferpal@gmail.com>
Cc: stable@vger.kernel.org (for 3.4+3.5)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
