- 24 8月, 2012 1 次提交
-
-
由 Jakob Bornecrantz 提交于
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 22 8月, 2012 5 次提交
-
-
由 Sachin Kamat 提交于
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: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This turns off the crtc when its been disabled, fixes it not turning off properly the whole time. Signed-off-by: NDave Airlie <airlied@redhat.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Damien Lespiau 提交于
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alan Cox 提交于
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: NAlan Cox <alan@linux.intel.com> Reviewed-by: NJakob Bornecrantz <jakob@vmware.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
When checking if a pll is in use. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 21 8月, 2012 3 次提交
-
-
由 Alex Deucher 提交于
This reverts commit d1c7871d. 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: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Guenter Roeck 提交于
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: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Daniel Vetter 提交于
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=53393Tested-by: NBen Widawsky <ben@bwidawsk.net> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 8月, 2012 8 次提交
-
-
由 Alex Deucher 提交于
There are systems that use ATRM, but not ATPX. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41265 V2: fix #ifdefs as per Greg's comments V3: fix it harder Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Allows us to verify the table size. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 David Lamparter 提交于
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: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org
-
由 Tvrtko Ursulin 提交于
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: NTvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Marek Olšák 提交于
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: NMarek Olšák <maraeo@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Marek Olšák 提交于
MSAA is impossible without them. Signed-off-by: NMarek Olšák <maraeo@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com>
-
由 Christian König 提交于
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: NChristian König <deathsimple@vodafone.de> cc: stable@vger.kernel.org Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
-
由 Jerome Glisse 提交于
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: NJerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 18 8月, 2012 1 次提交
-
-
由 Seth Forshee 提交于
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: NSeth Forshee <seth.forshee@canonical.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 17 8月, 2012 5 次提交
-
-
由 Jani Nikula 提交于
GMBUS was enabled over bit-banging as the default in commits: commit c3dfefa0 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 0fb3f969 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=45881Signed-off-by: NJani Nikula <jani.nikula@intel.com> Tested-by: NAlex Ferrando <alferpal@gmail.com> Cc: stable@vger.kernel.org (for 3.4+3.5) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Refactor the connector update part of intel_ddc_get_modes() into a separate intel_connector_update_modes() function for reuse. No functional changes. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881Tested-by: NAlex Ferrando <alferpal@gmail.com> Cc: stable@vger.kernel.org (for 3.4+3.5) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
They've changed it ... for no apparent reason. Meh. V2: remove unused 'is_hsw' field. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
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=52429Tested-by: NGuang A Yang <guang.a.yang@intel.com> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
The EDID returned by drm_get_edid() was never freed. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 8月, 2012 8 次提交
-
-
由 Chris Wilson 提交于
When invalidating the TLBs it is documentated as requiring a post-sync write. Failure to do so seems to result in a GPU hang. Exposure to this hang on IVB seems to be a result of removing the extra stalls required for SNB pipecontrol workarounds: commit 6c6cf5aa Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 20 18:02:28 2012 +0100 drm/i915: Only apply the SNB pipe control w/a to gen6 Note: Manually switch the pipe_control cmd to 4 dwords to avoid a (silent) functional conflict with -next. This way will get a loud (but conflict with next (since the scratch_addr has been deleted there). Reported-and-tested-by: yex.tian@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322Acked-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: added note about merge conflict with -next.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
eDP is tons of fun. It turns out that at least the new MacBook Air 5,1 model absolutely doesn't like the new force vdd dance we've introduced in commit 6cb49835 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel But that patch also tried to fix some neat edp sequence issue with the force_vdd timings. Closer inspection reveals that we've raised force_vdd only to do the aux channel communication dp_sink_dpms. If we move the edp_panel_off below that, we don't need any force_vdd for the disable sequence, which makes the Air happy. Unfortunately the reporter of the original bug that the above commit fixed is travelling, so we can't test whether this regresses things. But my theory is that since we don't check for any power-off -> force_vdd-on delays in edp_panel_vdd_on, this was the actual root-cause of this failure. With that force_vdd dance completely eliminated, I'm hopeful the original bug stays fixed, too. For reference the old bug, which hopefully doesn't get broken by this: https://bugzilla.kernel.org/show_bug.cgi?id=43163 In any case, regression fixers win over plain bugfixes, so this needs to go in asap. v2: The crucial pieces seems to be to clear the force_vdd flag uncoditionally, too, in edp_panel_off. Looks like this is left behind by the firmware somehow. v3: The Apple firmware seems to switch off the panel on it's own, hence we still need to keep force_vdd on, but properly clear it when switching the panel off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671Tested-by: NRoberto Romer <sildurin@gmail.com> Tested-by: NDaniel Wagner <wagi@monom.org> Tested-by: NKeith Packard <keithp@keithp.com> Cc: stable@vger.kernel.org Cc: Keith Packard <keithp@keithp.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Maxim Levitsky 提交于
This fix is a backport from the reworked nouveau driver. It masks off the engines we're not expecting to use before attempting a channel kickoff. Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Henrik Rydberg 提交于
The copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. Signed-off-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Maarten Lankhorst 提交于
Fixes screen being black after changing performance level. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com> Cc: stable@vger.kernel.org [3.5+] Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
At least partially fixes DP output detection on W530. Not sure if more issues remain, or if my adaptor is just behaving weirdly (it does that sometimes). In any case, this patch is necessary. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Christoph Bumiller 提交于
Signed-off-by: NChristoph Bumiller <e0425955@student.tuwien.ac.at> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Jani Nikula 提交于
i2c_add_adapter() may do i2c transfers on the bus to detect supported devices. Therefore the adapter needs to be all set before adding it. This was not the case for the bit-banging fallback, resulting in an oops if the device detection GMBUS transfers timed out. Fix the issue by calling i2c_add_adapter() only after intel_gpio_setup(). LKML-Reference: <5021F00B.7000503@ionic.de> Tested-by: NMihai Moldovan <ionic@ionic.de> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 13 8月, 2012 9 次提交
-
-
由 Dmitrii Cherkasov 提交于
Signed-off-by: NDmitrii Cherkasov <DCherkasov@luxsoft.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Marek Olšák 提交于
Returns a snapshot of the GPU clock counter. Needed for certain OpenGL extensions. v2: agd5f - address Jerome's comments - add function documentation Signed-off-by: NMarek Olšák <maraeo@gmail.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Marek Olšák 提交于
Most of the checking seems to be in place already. As you can see, log2(number of samples) resides in LAST_LEVEL. This is required for MSAA support (namely for depth-stencil resolve and blitting between MSAA resources). Signed-off-by: NMarek Olšák <maraeo@gmail.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Marek Olšák 提交于
Signed-off-by: NMarek Olšák <maraeo@gmail.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jerome Glisse 提交于
Virtual address need to be fenced to know when we can safely remove it. This patch also properly clear the pagetable. Previously it was serouisly broken. Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking. v2: For to update pagetable when unbinding bo (don't bailout if bo_va->valid is true). v3: Add kernel 3.5/3.4 comment. v4: Fix compilation warnings. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Better safe than sorry. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com>
-
由 Alex Deucher 提交于
No functional change, but re-order the cases so they evaluate properly due to the way the DCE macros work. Noticed by kallisti5 on IRC. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jerome Glisse 提交于
It seems we can not update the crtc scanout address. After disabling crtc, update to base address do not take effect after crtc being reenable leading to at least frame being scanout from the old crtc base address. Disabling crtc display request lead to same behavior. So after changing the vram address if we don't keep crtc disabled we will have the GPU trying to read some random system memory address with some iommu this will broke the crtc engine and will lead to broken display and iommu error message. So to avoid this, disable crtc. For flicker less boot we will need to avoid moving the vram start address. This patch should also fix : https://bugs.freedesktop.org/show_bug.cgi?id=42373 Cc: <stable@vger.kernel.org> Signed-off-by: NJerome Glisse <jglisse@redhat.com>
-
由 Alex Deucher 提交于
Handle the 16 bank case. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-