- 23 11月, 2012 1 次提交
-
-
由 Jani Nikula 提交于
commit 500a8cc4 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Wed Jan 13 11:19:52 2010 +0800 drm/i915: parse eDP panel color depth from VBT block originally introduced parsing bpp for eDP from VBT, with a default of 18 bpp if the eDP BIOS data block is not present. Turns out that default seems to break the Macbook Pro with retina display, as noted in commit 4344b813 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 10 11:10:20 2012 +0200 drm/i915: ignore eDP bpc settings from vbt Since we can't ignore bpc settings from VBT completely after all, get rid of the default. Do not clamp eDP to 18 bpp by default if the eDP BDB is missing from VBT. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Tested-by: NHenrik Rydberg <rydberg@euromail.se> [danvet: paste in the updated commit message from irc.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 11月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
After the recent pile of disable-cloning patches, e.g. commit e3b86d69 Author: Egbert Eich <eich@suse.de> Date: Sat Oct 13 14:30:15 2012 +0200 DRM/i915: Don't clone SDVO LVDS with analog and a bug report from Chris Wilson indicating that cloning doesn't even work for DVI-SDVO and native VGA, let's just disable cloning on sdvo encoders completely. v2: Update the comment in the code as discussed with Paulo Zanoni. Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29259Tested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 16 11月, 2012 3 次提交
-
-
由 Akinobu Mita 提交于
It is unnecessary to disable preemption explicitly while calling copy_highpage(). Because copy_highpage() will do it again through kmap_atomic/kunmap_atomic. Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Zhao Yakui 提交于
The TTM page can be allocated from high memory. In such case it is wrong to use the page_address(page) as the virtual address for the high memory page. bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50241Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Cc: stable@vger.kernel.org Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dan Carpenter 提交于
copy_to_user() returns the number of bytes remaining to be copied, but we want to return a negative error code here. I fixed a couple of these last year, but I missed this one. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 15 11月, 2012 1 次提交
-
-
由 Alex Deucher 提交于
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=50431Reported-by: NDavid Binderman <dcb314@hotmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
-
- 13 11月, 2012 2 次提交
-
-
由 Jani Nikula 提交于
There are laptops out there that need the eDP bpc from VBT. This is effectively a revert of commit 4344b813 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 10 11:10:20 2012 +0200 drm/i915: ignore eDP bpc settings from vbt but putting the VBT check after the EDID check to see them both in dmesg if this clamps more than the EDID. We have enough history with bpc clamping to warrant the extra debug info. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47641 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56401Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call left behind ghost connectors, attached (with a dangling pointer) to the sdvo that has been cleaned up and freed. Properly destroy any connectors attached to the encoder. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46381 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Tested-by: bjo@nord-west.org [danvet: added a comment to explain why we need to clean up connectors even when sdvo_output_setup fails.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 11月, 2012 7 次提交
-
-
由 Thomas Hellstrom 提交于
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NDmitry Torokhov <dtor@vmware.com> Cc: stable@vger.kernel.org Cc: linux-graphics-maintainer@vmware.com Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
The device would not reset properly when resuming from hibernation. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NDmitry Torokhov <dtor@vmware.com> Cc: stable@vger.kernel.org Cc: linux-graphics-maintainer@vmware.com Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Maarten Lankhorst 提交于
Commit c0077061 accidentally inverted the logic for nouveau_acpi_edid, causing it to only show a connector as connected when the edid could not be retrieved with acpi. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Kelly Doran 提交于
Signed-off-by: NKelly Doran <kel.p.doran@gmail.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
It slipped in thanks to typeless API. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
nv04_graph_priv / nv04_graph_chan are not defined in this context... Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
It's a miracle it compiles at all - nv04_vm_priv does not exist anywhere in the tree. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 08 11月, 2012 2 次提交
-
-
由 Alex Deucher 提交于
This register is needed for streamout to work properly. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
-
由 Alex Deucher 提交于
These regs were being wronly rejected leading to rendering issues. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=56876Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
-
- 07 11月, 2012 4 次提交
-
-
由 Alex Deucher 提交于
The order shouldn't matter, but this seems to cause regressions for certain specific cases. This should fix it for now. We probably need to investigate a proper fix in the next development cycle. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: Andy Furniss <andyqos@ukfsn.org>
-
由 Alex Deucher 提交于
Add missing index that may have led us to enabling more crtcs than necessary. May also fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ilija Hadzic 提交于
Some drivers (specifically vmwgfx) look at dev_mapping in their open hook, so we have to set dev->dev_mapping earlier in the process. Reference: http://lists.freedesktop.org/archives/dri-devel/2012-October/029420.htmlSigned-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com> Reported-by: NThomas Hellstrom <thellstrom@vmware.com> Cc: stable@vger.kernel.org Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ilija Hadzic 提交于
If drm_setup (called at first open) fails, the whole open call has failed, so we should not keep the open_count incremented. Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com> Cc: stable@vger.kernel.org Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 06 11月, 2012 1 次提交
-
-
由 Jani Nikula 提交于
PCH platforms and VLV should map DPMS standby and suspend modes to off, but due to a buggy reversed comparison this is done on pre-PCH platforms instead. Reported-by: NLoïc Yhuel <loic.yhuel@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56754Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 11月, 2012 1 次提交
-
-
由 Dave Airlie 提交于
When buffer sharing with the i915 and using a 1680x1050 monitor, the i915 gives is a 6912 buffer for the 6720 width, the code doesn't render this properly as it uses one value to set the base address for reading from the vmap and for where to start on the device. This fixes it by calculating the values correctly for the device and for the pixmap. No idea how I haven't seen this before now. Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 01 11月, 2012 9 次提交
-
-
由 Alex Deucher 提交于
The R200 asics use an external DAC for the secondary DAC. The current KMS code tries to use code for the integrated TV DAC for R200 which leads to unpredictable results since R200 does not have an integrated TV DAC. This patch ports the external DAC load detection support from the UMS driver to KMS. v2: fix typo in loop break logic Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NEgbert Eich <eich@suse.de>
-
由 Egbert Eich 提交于
On all dual CRTC GPUs the CRTC_CRT_ON in the RADEON_CRTC_EXT_CNTL register controls the CRTC of the primary DAC. Therefore it is set in the DAC DMPS function. This is different for GPU's with a single CRTC but a primary and a TV DAC: here it controls the single CRTC no matter where it is routed. Therefore we set it here. This avoids an elaborate on/off state tracking since both primary_dac_dpms() and tv_dac_dpms() functions would have to touch this bit. On single CRTC GPUs with just one DAC it's irrelevant where this bit is handled. agd5f: fix warning Signed-off-by: NEgbert Eich <eich@suse.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Egbert Eich 提交于
The RN50 has a TV DAC but only a single CRTC. For load detection this DAC is controlled by the primary CRTC. Signed-off-by: NEgbert Eich <eich@suse.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Egbert Eich 提交于
Signed-off-by: NEgbert Eich <eich@suse.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Igor Murzov 提交于
Fix a copy&pasted documentation. Signed-off-by: NIgor Murzov <e-mail@date.by> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Peter Senna Tschudin 提交于
A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r1@ statement S; position p,p1; @@ S@p1;@p @script:python r2@ p << r1.p; p1 << r1.p1; @@ if p[0].line != p1[0].line_end: cocci.include_match(False) @@ position r1.p; @@ -;@p // </smpl> Signed-off-by: NPeter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Egbert Eich 提交于
The Radeon driver uses the analog/digital flag to determine if the DAC or the TMDS encoder should be enabled on a DVI-I connector. If the EDID is bogus this flag is no longer reliable. This fix adds a fallback to DAC load detection to determine if anything is connected to the DAC. If not and a (bogus) EDID is found it assumes a digital display is connected. This works around problems with some crappy IPMI devices using Radeon ES1000. Signed-off-by: NEgbert Eich <eich@suse.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Egbert Eich 提交于
For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value works better on ES1000 (RV100) chips, too, as it doesn't produce any false positives on any cards I have tested. Therefore let's assume that this value is good for all RV100 and RV200 chipset generations. Signed-off-by: NEgbert Eich <eich@suse.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Egbert Eich 提交于
An uninitialized variable led to broken load detection. Signed-off-by: NEgbert Eich <eich@suse.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 31 10月, 2012 8 次提交
-
-
由 Rahul Sharma 提交于
Removing the warning by adding proper type casting where local pointer variable of type mixer driver data is assigned with void pointer. Signed-off-by: NRahul Sharma <rahul.sharma@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 Rob Clark 提交于
Exynos does not seem to have any dependency on anything from platform headers so just needs Kconfig updated to build in ARCH_MULTIPLATFORM builds. Signed-off-by: NRob Clark <rob@ti.com> Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 Inki Dae 提交于
When crtc_funcs->dpms callback is called, exynos_crtc->dpms and exynos_encoder->dpms are changed to new mode. But if user requests dpms mode operation, OFF -> ON, when crtc's dpms callback is called, exynos_encoder->dpms is also changed to ON. This makes encoder's dpms callback call be ignored so display power couldn't become on again. This patch removes exynos_encoder->dpms changing and adds 'updated' variable to exynos_drm_encoder structure to avoid duplicated overlay updating. Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 Ben Skeggs 提交于
This is to prevent nouveau from taking over the console on headless boards such as Tesla. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Unconditionally create the tagram mm, even if there's zero tags. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Useful for places where a given chipset may or may not have a given resource, and we want to avoid having to spray checks for the mm's existance around everywhere. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Reported-by: NMathieu Chouquet-Stringer <mathieu@csetco.com> Tested-by: NMathieu Chouquet-Stringer <mathieu@csetco.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-