- 24 9月, 2010 2 次提交
-
-
由 Chris Wilson 提交于
In the event that the external chipset doesn't implement the GET_SUPPORTED_ENHANCEMENTS commands, gracefully treat it as having no enhancments rather than bailing. Reported-and-tested-by: NWoody Suwalski <terraluna977@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Chris Wilson 提交于
We weren't unlinking the freed connector from the drm lists, and so hit some use-after-free if we failed to initialise the connector. Reported-and-tested-by: NWoody Suwalski <terraluna977@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 14 9月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
v2: Julien Cristau pointed out that @nondestructive results in double-negatives and confusion when trying to interpret the parameter, so use @force instead. Much easier to type as well. ;-) And fix the miscompilation of vmgfx reported by Sedat Dilek. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 9月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
Destructive load-detection is very expensive and due to failings elsewhere can trigger system wide stalls of up to 600ms. A simple first step to correcting this is not to invoke such an expensive and destructive load-detection operation automatically. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29536 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16265Reported-by: NBruno Prémont <bonbons@linux-vserver.org> Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 07 9月, 2010 2 次提交
-
-
由 Chris Wilson 提交于
If the VBIOS tells us the mapping of the SDVO device onto the DDC bus, use it. However, if there is no VBIOS available that mapping is uninitialised and we should fallback to our earlier guess. Fix regression introduced in b1083333 (which in turn is a fix for the regression caused by the introduction of this guess, 14571b4c). References: Bug 29499 - [945GM] Screen disconnected because of missing VBIOS https://bugs.freedesktop.org/show_bug.cgi?id=29499 Bug 15109 - i945GM fails to detect EDID on DVI port https://bugzilla.kernel.org/show_bug.cgi?id=15109Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: NPaul Neumann <paul104x@yahoo.de> Cc: Adam Jackson <ajax@redhat.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: stable@kernel.org
-
由 Pavel Roskin 提交于
This fixes blur-like screen corruption on the following card: VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express Integrated Graphics Controller [8086:29c2] (rev 10) intel_sdvo_mode_set() should not return prematurely just because some features are not supported. https://bugzilla.kernel.org/show_bug.cgi?id=17151Signed-off-by: NPavel Roskin <proski@gnu.org> Reported-by: NJonathan Corbet <corbet@lwn.net> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> [ickle: Relax a couple more checks for failing LVDS modesetting] Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 22 8月, 2010 1 次提交
-
-
由 Jesse Barnes 提交于
Waiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling). This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 10 8月, 2010 9 次提交
-
-
由 Chris Wilson 提交于
If we have failed to ascertain the fixed mode for the LVDS panel, then trust the pixel clock ranges reported for the connection when determing valid modes. This makes intel_sdvo_mode_valid() consistent with intel_lvds_mode_valid() which is also a no-op is there is no fixed mode defined. (Since the mode is both validated by SDVO and LVDS, why are checking against an LVDS fixed mode in SDVO...) By only defining is_lvds to be true when we actually have an LVDS output with a fixed mode, we avoid various potential NULL deferences where the assumption is made that all LVDS outputs have a fixed mode. References: Bug 29449 - [Q35] failure to read EDID/vbios for LVDS, no mode => no output https://bugs.freedesktop.org/show_bug.cgi?id=29449 The primary failure in this bug is not finding the EDID and determining the correct fixed panel mode. However, this patch should fix the secondary issue of not enabling any of the standard modes for the panel either. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
This property is slightly unusual in that it is a boolean and so has no GET_MAX command. Reference: Bug 28636 - missing TV parameter "Dot Crawl freeze" https://bugs.freedesktop.org/show_bug.cgi?id=28636Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Reference: Bug 28634 - missing TV parameter "Flicker Filter" https://bugs.freedesktop.org/show_bug.cgi?id=28634Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Make the code that tiny bit clearer by reducing the pointer dance. 2 files changed, 130 insertions(+), 147 deletions(-) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Subclass intel_encoder to reduce the pointer dance through intel_encoder->dev_priv. 10 files changed, 896 insertions(+), 997 deletions(-) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 02 8月, 2010 1 次提交
-
-
由 Adam Jackson 提交于
Signed-off-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 20 7月, 2010 1 次提交
-
-
由 Kulikov Vasiliy 提交于
Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x). Signed-off-by: NKulikov Vasiliy <segooon@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 27 5月, 2010 1 次提交
-
-
由 Dan Carpenter 提交于
The "connector" variable is used as the cursor in a list_for_each_entry() and it's always non-null so we don't need to check it. Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 18 5月, 2010 1 次提交
-
-
由 Dave Airlie 提交于
After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings. v3: add config lock take inside polling, add intel/nouveau poll init/fini calls v4: config lock was a bit agressive, only needed around connector list reading. otherwise it could re-enter. glisse: discard drm_helper_hpd_irq_event v3: Reviewed-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 11 5月, 2010 2 次提交
-
-
由 Adam Jackson 提交于
If we're both RGB and TMDS capable, we'll have set up one connector for each. When determining connectivity, require analog/digital state in the EDID block to match analog/digital support in the connector. Otherwise, both DVI and VGA will appear to be connected. Signed-off-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Adam Jackson 提交于
Multifunction SDVO cards stopped working after 14571b4c, and would report something that looked remarkably like an ADD2 SPD ROM instead of EDID. This appears to be because DDC bus selection was utterly horked by that commit; controlled_output was no longer always a single bit, so intel_sdvo_select_ddc_bus would pick bus 0, which is (unsurprisingly) the SPD ROM bus, not a DDC bus. So, instead of that, let's just use the DDC bus the child device table tells us to use. I'm guessing at the bitmask and shifting from VBIOS dumps, but it can't possibly be worse. cf. https://bugzilla.redhat.com/584229Signed-off-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 13 4月, 2010 6 次提交
-
-
由 Zhao Yakui 提交于
Otherwise it will cause that S-video output becomes black/white when switching to other TV format. http://bugs.freedesktop.org/show_bug.cgi?id=23916Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Tested-by: NArnold <arnold.erbsloeh@web.de> Tested-by: NBazin <bazin.cz@gmail.com> Tested-by: NNigel <nigel_tuck@eircom.net> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhao Yakui 提交于
SDVO on Ibexpeak PCH with Ironlake is multiplexed with HDMIB port, and only has SDVOB port. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhenyu Wang 提交于
This reverts commit 6070a4a9. The quirk for this SDVO device on IBM specific board is just a hack in old code which showed the broken multifunction SDVO support in the driver. Multifunction SDVO patch provided the right fix for it. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhenyu Wang 提交于
With new intel_encoder/intel_connector structure change, each supported connector type on SDVO device will be created as a new 'intel_connector', and all attached to one 'intel_encoder' for its SDVO port. The SDVO encoder will handle SDVO protocol stuff, and each connector does its own part of work now, like detection is only to check if current active output is itself, etc. Update since last submit: - Fixed SDVO TV property creation failure by incorrect set target output call Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhenyu Wang 提交于
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Eric Anholt 提交于
This was brought over from UMS, and used for a while until we decided that drm_helper_resume_force_mode was easier and more reliable, since it didn't require duplicating all the code deleted here. We just forgot to delete all that junk for a while.
-
- 10 4月, 2010 1 次提交
-
-
由 Zhenyu Wang 提交于
This one replaces original param for intel_ddc_get_modes() with DRM connector and i2c bus adapter instead. With explicit params, we won't require that a single driver structure must hold connector and DDC bus reference, which ease the conversion to splitted encoder/ connector model. It also clears up for some cases that we would steal other DDC bus for mode probe, like VGA analog DDC probe for DVI-I. Also it fixed a bug in old DVI-I probe handling, that failed to restore origin analog GPIO port. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 26 3月, 2010 2 次提交
-
-
由 Eric Anholt 提交于
Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
The intel_output naming is inherited from the UMS code, which had a structure of screen -> CRTC -> output. The DRM code has an additional notion of encoder/connector, so the structure is screen -> CRTC -> encoder -> connector. This is a useful structure for SDVO encoders which can support multiple connectors (each of which requires different programming in the one encoder and could be connected to different CRTCs), or for DVI-I, where multiple encoders feed into the connector for whether it's used for digital or analog. Most of our code is encoder-related, so transition it to talking about encoders before we start trying to distinguish connectors. This patch is produced by sed s/intel_output/intel_encoder/ over the driver. Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 27 2月, 2010 1 次提交
-
-
由 Zhao Yakui 提交于
This IBM system has a multi-function SDVO card that reports both VGA and TV, but the system has no TV connector. The TV connector always reported as connected, which would lead to poor modesetting choices. https://bugs.freedesktop.org/show_bug.cgi?id=25787Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Tested-by: NVance <liangghv@sg.ibm.com> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 30 1月, 2010 1 次提交
-
-
由 Zhao Yakui 提交于
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 13 1月, 2010 2 次提交
-
-
由 Zhao Yakui 提交于
There exist multiple DDC buses for the SDVO cards with multiple outputs. When we can't get the EDID by using the select DDC bus, we can try the other possible DDC bus to see whether the EDID can be obtained. https://bugs.freedesktop.org/show_bug.cgi?id=23842Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
For some SDVO cards based on conexant chip, we can't read the EDID if we don't read the response after issuing SDVO DDC bus switch command. From the SDVO spec once when another I2C transaction is finished after completing the I2C transaction of issuing the bus switch command, it will be switched back to the SDVO internal state again. So we can't initiate a new I2C transaction to read the response after issuing the DDC bus switch command. Instead we should issue DDC bus switch command and read the response in the same I2C transaction. https://bugs.freedesktop.org/show_bug.cgi?id=23842 https://bugs.freedesktop.org/show_bug.cgi?id=24458 https://bugs.freedesktop.org/show_bug.cgi?id=24522 https://bugs.freedesktop.org/show_bug.cgi?id=24282Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 17 12月, 2009 1 次提交
-
-
由 Jesse Barnes 提交于
This patch changes around our hotplug enable code a bit to only enable it for ports we actually detect and initialize. This prevents problems with stuck or spurious interrupts on outputs that aren't actually wired up, and is generally more correct. Fixes FDO bug #23183. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 04 12月, 2009 1 次提交
-
-
由 André Goddard Rosa 提交于
That is "success", "unknown", "through", "performance", "[re|un]mapping" , "access", "default", "reasonable", "[con]currently", "temperature" , "channel", "[un]used", "application", "example","hierarchy", "therefore" , "[over|under]flow", "contiguous", "threshold", "enough" and others. Signed-off-by: NAndré Goddard Rosa <andre.goddard@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 02 12月, 2009 1 次提交
-
-
由 Zhao Yakui 提交于
Without this, on some boots the TV wouldn't be detected. Testing showed 15ms to be insufficient. https://bugs.freedesktop.org/show_bug.cgi?id=24290 https://bugs.freedesktop.org/show_bug.cgi?id=20785Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Tested-by: NYan Seiner <yan@seiner.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 06 11月, 2009 1 次提交
-
-
由 Eric Anholt 提交于
Signed-off-by: NEric Anholt <eric@anholt.net>
-