aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_sdvo.c
Commit message (Collapse)AuthorAgeFilesLines
* remove firmware files, merge more uncritical stuff from 3.0.101Wolfgang Wiedmeyer2015-10-231-192/+224
|
* merged 3.0.101 tagWolfgang Wiedmeyer2015-10-221-5/+7
|
* Merge remote-tracking branch 'kernelorg/linux-3.0.y' into 3_0_64Andrew Dodd2013-02-271-19/+52
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/Kconfig arch/arm/include/asm/hwcap.h arch/arm/kernel/smp.c arch/arm/plat-samsung/adc.c drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_drv.h drivers/mmc/core/sd.c drivers/net/tun.c drivers/net/usb/usbnet.c drivers/regulator/max8997.c drivers/usb/core/hub.c drivers/usb/host/xhci.h drivers/usb/serial/qcserial.c fs/jbd2/transaction.c include/linux/migrate.h kernel/sys.c kernel/time/timekeeping.c lib/genalloc.c mm/memory-failure.c mm/memory_hotplug.c mm/mempolicy.c mm/page_alloc.c mm/vmalloc.c mm/vmscan.c mm/vmstat.c scripts/Kbuild.include Change-Id: I91e2d85c07320c7ccfc04cf98a448e89bed6ade6
| * drm/i915: clear the entire sdvo infoframe bufferDaniel Vetter2012-11-171-20/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b6e0e543f75729f207b9c72b0162ae61170635b2 upstream. Like in the case of native hdmi, which is fixed already in commit adf00b26d18e1b3570451296e03bcb20e4798cdd Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Sep 25 13:23:34 2012 -0300 drm/i915: make sure we write all the DIP data bytes we need to clear the entire sdvo buffer to avoid upsetting the display. Since infoframe buffer writing is now a bit more elaborate, extract it into it's own function. This will be useful if we ever get around to properly update the ELD for sdvo. Also #define proper names for the two buffer indexes with fixed usage. v2: Cite the right commit above, spotted by Paulo Zanoni. v3: I'm too stupid to paste the right commit. v4: Ben Hutchings noticed that I've failed to handle an underflow in my loop logic, breaking it for i >= length + 8. Since I've just lost C programmer license, use his solution. Also, make the frustrated 0-base buffer size a notch more clear. Reported-and-tested-by: Jürg Billeter <j@bitron.ch> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Ben Hutchings <ben@decadent.org.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm/i915: fixup infoframe support for sdvoDaniel Vetter2012-11-171-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 81014b9d0b55fb0b48f26cd2a943359750d532db upstream. At least the worst offenders: - SDVO specifies that the encoder should compute the ecc. Testing also shows that we must not send the ecc field, so copy the dip_infoframe struct to a temporay place and avoid the ecc field. This way the avi infoframe is exactly 17 bytes long, which agrees with what the spec mandates as a minimal storage capacity (with the ecc field it would be 18 bytes). - Only 17 when sending the avi infoframe. The SDVO spec explicitly says that sending more data than what the device announces results in undefined behaviour. - Add __attribute__((packed)) to the avi and spd infoframes, for otherwise they're wrongly aligned. Noticed because the avi infoframe ended up being 18 bytes large instead of 17. We haven't noticed this yet because we don't use the uint16_t fields yet (which are the only ones that would be wrongly aligned). This regression has been introduce by 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 Author: David Härdeman <david@hardeman.nu> Date: Fri Sep 24 21:44:32 2010 +0200 i915: enable AVI infoframe for intel_hdmi.c [v4] Patch tested on my g33 with a sdvo hdmi adaptor. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI) Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm/i915: properly handle interlaced bit for sdvo dtd conversionDaniel Vetter2012-06-101-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 59d92bfa5f0cdf57f82f5181b0ad6af75c3fdf41 upstream. We've simply ignored this, which isn't too great. With this, interlaced 1080i works on my HDMI screen connected through sdvo. For no apparent reason anything else still doesn't work as it should. While at it, give these magic numbers in the dtd proper names and add a comment that they match with EDID detailed timings. v2: Actually use the right bit for interlaced. Tested-by: Peter Ross <pross@xvid.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge linux-3.0.31 from korg into jellybeancodeworkx2012-09-181-16/+18
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/mm/proc-v7.S drivers/base/core.c drivers/gpu/drm/i915/i915_gem_execbuffer.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_lvds.c drivers/gpu/drm/radeon/evergreen.c drivers/gpu/drm/radeon/r100.c drivers/gpu/drm/radeon/radeon_connectors.c drivers/gpu/drm/radeon/rs600.c drivers/usb/core/hub.c drivers/usb/host/xhci-pci.c drivers/usb/host/xhci.c drivers/usb/serial/qcserial.c fs/proc/base.c Change-Id: Ia98b35db3f8c0bfd95817867d3acb85be8e5e772
| * drm/i915: handle input/output sdvo timings separately in mode_setDaniel Vetter2012-05-071-16/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6651819b4b4fc3caa6964c5d825eb4bb996f3905 upstream. We seem to have a decent confusion between the output timings and the input timings of the sdvo encoder. If I understand the code correctly, we use the original mode unchanged for the output timings, safe for the lvds case. And we should use the adjusted mode for input timings. Clarify the situation by adding an explicit output_dtd to the sdvo mode_set function and streamline the code-flow by moving the input and output mode setting in the sdvo encode together. Furthermore testing showed that the sdvo input timing needs the unadjusted dotclock, the sdvo chip will automatically compute the required pixel multiplier to get a dotclock above 100 MHz. Fix this up when converting a drm mode to an sdvo dtd. This regression was introduced in commit c74696b9c890074c1e1ee3d7496fc71eb3680ced Author: Pavel Roskin <proski@gnu.org> Date: Thu Sep 2 14:46:34 2010 -0400 i915: revert some checks added by commit 32aad86f particularly the following hunk: # diff --git a/drivers/gpu/drm/i915/intel_sdvo.c # b/drivers/gpu/drm/i915/intel_sdvo.c # index 093e914..62d22ae 100644 # --- a/drivers/gpu/drm/i915/intel_sdvo.c # +++ b/drivers/gpu/drm/i915/intel_sdvo.c # @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder, # # /* We have tried to get input timing in mode_fixup, and filled into # adjusted_mode */ # - if (intel_sdvo->is_tv || intel_sdvo->is_lvds) { # - intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); # + intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); # + if (intel_sdvo->is_tv || intel_sdvo->is_lvds) # input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags; # - } else # - intel_sdvo_get_dtd_from_mode(&input_dtd, mode); # # /* If it's a TV, we already set the output timing in mode_fixup. # * Otherwise, the output timing is equal to the input timing. Due to questions raised in review, below a more elaborate analysis of the bug at hand: Sdvo seems to have two timings, one is the output timing which will be sent over whatever is connected on the other side of the sdvo chip (panel, hdmi screen, tv), the other is the input timing which will be generated by the gmch pipe. It looks like sdvo is expected to scale between the two. To make things slightly more complicated, we have a bunch of special cases: - For lvds panel we always use a fixed output timing, namely intel_sdvo->sdvo_lvds_fixed_mode, hence that special case. - Sdvo has an interface to generate a preferred input timing for a given output timing. This is the confusing thing that I've tried to clear up with the follow-on patches. - A special requirement is that the input pixel clock needs to be between 100MHz and 200MHz (likely to keep it within the electromechanical design range of PCIe), 270MHz on later gen4+. Lower pixel clocks are doubled/quadrupled. The thing this patch tries to fix is that the pipe needs to be explicitly instructed to double/quadruple the pixels and needs the correspondingly higher pixel clock, whereas the sdvo adaptor seems to do that itself and needs the unadjusted pixel clock. For the sdvo encode side we already set the pixel mutliplier with a different command (0x21). This patch tries to fix this mess by: - Keeping the output mode timing in the unadjusted plain mode, safe for the lvds case. - Storing the input timing in the adjusted_mode with the adjusted pixel clock. This way we don't need to frob around with the core crtc mode set code. - Fixing up the pixelclock when constructing the sdvo dtd timing struct. This is why the first hunk of the patch is an integral part of the series. - Dropping the is_tv special case because input_dtd is equivalent to adjusted_mode after these changes. Follow-up patches clear this up further (by simply ripping out intel_sdvo->input_dtd because it's not needed). v2: Extend commit message with an in-depth bug analysis. Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm/i915/sdvo: always set positive sync polarityPaulo Zanoni2012-02-031-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ba68e086223a5f149f37bf8692c8cdbf1b0ba3ef upstream. This is a revert of 81a14b46846fea0741902e8d8dfcc6c6c78154c8. We already set the mode polarity using the SDVO commands with struct intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch. The documentation, despite not clear, can also be interpreted in a way that suggests this patch is needed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43333 Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | samsung update 1codeworkx2012-06-021-229/+195
|/
* drm/i915: Share the common force-audio property between connectorsChris Wilson2011-06-041-12/+2
| | | | | | | | | Make the audio property creation routine common and share the single property between the connectors. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915/sdvo: Reorder i2c initialisation before ddc proxyChris Wilson2011-05-181-6/+4
| | | | | | | | | | | | | | | | | | | | | | The ddc proxy depends upon the underlying i2c bus being selected. Under certain configurations, the i2c-adapter functionality is queried during initialisation and so may trigger an OOPS during boot. Hence, we need to reorder the initialisation of the ddc proxy until after we hook up the i2c adapter for the SDVO device. The condition under which it fails is when the i2c_add_adapter calls into i2c_detect which will attempt to probe all valid addresses on the adapter iff there is a pre-existing i2c_driver with the same class as the freshly added i2c_adapter. So it appears to depend upon having compiled in (or loaded such a module before i915.ko) an i2c-driver that likes to futz over the i2c_adapters claiming DDC support. Reported-by: Mihai Moldovan <ionic@ionic.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* Merge remote branch 'intel/drm-intel-next' of ../drm-next into drm-core-nextDave Airlie2011-03-141-37/+86
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'intel/drm-intel-next' of ../drm-next: (755 commits) drm/i915: Only wait on a pending flip if we intend to write to the buffer drm/i915/dp: Sanity check eDP existence drm/i915: Rebind the buffer if its alignment constraints changes with tiling drm/i915: Disable GPU semaphores by default drm/i915: Do not overflow the MMADDR write FIFO Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing" drm/i915: Don't save/restore hardware status page address register drm/i915: don't store the reg value for HWS_PGA drm/i915: fix memory corruption with GM965 and >4GB RAM Linux 2.6.38-rc7 Revert "TPM: Long default timeout fix" drm/i915: Re-enable GPU semaphores for SandyBridge mobile drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#" Revert "drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU" drm/i915: Allow relocation deltas outside of target bo drm/i915: Silence an innocuous compiler warning for an unused variable fs/block_dev.c: fix new kernel-doc warning ACPI: Fix build for CONFIG_NET unset mm: <asm-generic/pgtable.h> must include <linux/mm_types.h> x86: Use u32 instead of long to set reset vector back to 0 ... Conflicts: drivers/gpu/drm/i915/i915_gem.c
| * drm/i915: Add support for limited color range of broadcast outputsChris Wilson2011-02-221-0/+20
| | | | | | | | | | | | | | | | | | In order to prevent "crushed blacks" on TVs, the range of the RGB output may be limited to 16-235. This used to be available through Xorg under the "Broadcast RGB" option, so reintroduce support for KMS. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34543 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| * Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson2011-02-161-11/+55
| |\ | | | | | | | | | | | | | | | | | | | | | | | | Grab the latest stabilisation bits from -fixes and some suspend and resume fixes from linus. Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_irq.c
| | * drm/i915: Trigger modesetting if force-audio changesChris Wilson2011-02-111-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | If the user changes the force-audio property and it no longer reflects the current configuration, then we need to trigger a mode set in order to update the registers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| | * drm/i915/sdvo: If we have an EDID confirm it matches the mode of the connectionChris Wilson2011-02-091-5/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have an EDID for a digital panel, but we are probing a non-TMDS connector then we know that this is a false detection, and vice versa. This should reduce the number of bogus outputs on multi-function adapters that report the same output on multiple connectors. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34101 Reported-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson2011-02-011-23/+23
| |\ \ | | |/ | | | | | | Merge resume fixes from -fixes and an important fix for SDVO GMBUS.
| * | drm/i915/sdvo: Add BUILD_BUG_ON to warn if the structs are ever miscompiledChris Wilson2011-01-261-0/+9
| | | | | | | | | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| * | drm/i915/sdvo: Use a compact test for determining a multi-function deviceChris Wilson2011-01-261-27/+3
| | | | | | | | | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | | drm: Mark constant arrays of drm_display_mode constChris Wilson2011-02-231-1/+1
| |/ |/| | | | | | | | | | | | | | | | | | | ... and fixup some methods to accept the constant argument. Now that constant module arrays are loaded into read-only memory, using const appropriately has some benefits beyond warning the programmer about likely mistakes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/i915/sdvo: If at first we don't succeed in reading the response, waitChris Wilson2011-01-251-23/+23
|/ | | | | | | | | | We were not pausing after detecting the response was pending and so did not allow the hardware sufficient time to complete before aborting. This lead to transient failures whilst probing SDVO devices. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30235 Reported-by: Knut Petersen <Knut_Petersen@t-online.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/sdvo: Defer detection of output capabilities until probingChris Wilson2011-01-111-22/+11
| | | | | | | | | | | | | | | | | | Alex Fiestas reported an issue with his HDMI connector being misdetected as DVI unless he had something connected upon boot. By moving the decision as to whether to use HDMI or DVI encoding for the HDMI capable output until we probe the monitor means that we should avoid sending a HDMI signal to a DVI monitor and also correctly detect hardware like Alex's. However, to really determine what connector is soldered onto the wire we need to inspect the VBT sdvo child devices - but can we trust it? Reported-by: Alex Fiestas <alex@eyeos.org> Tested-by: Alex Fiestas <alex@eyeos.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org
* Merge branch 'master' of /home/airlied/kernel/linux-2.6 into drm-core-nextDave Airlie2011-01-051-1/+2
|\
| * drm/i915/sdvo: Add hdmi connector properties after initing the connectorChris Wilson2010-12-231-1/+2
| | | | | | | | | | | | Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25012 Reported-by: Tõnu Raitviir <jussuf@linux.ee> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/sdvo: Border and stall select became test bits in gen5Chris Wilson2010-12-161-2/+5
|/ | | | | | This is even more important as those bits will be moved in future. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/sdvo: Only use the SDVO pin if it is in the valid rangeChris Wilson2010-12-091-3/+6
| | | | | | | | | BIOSes. Can't live without them (apparently), definitely can't live with them. Reported-by: Ben Gamari <bgamari@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24312 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/sdvo: Always add a 30ms delay to make SDVO TV detection reliableChris Wilson2010-11-241-3/+5
| | | | | | | | | | Commit d09c23de intended to add a 30ms delay to give the ADD time to detect any TVs connected. However, it used the sdvo->is_tv flag to do so which is dependent upon the previous detection result and not whether the output supports TVs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org
* drm/i915/sdvo: Always fallback to querying the shared DDC lineChris Wilson2010-11-231-45/+6
| | | | | | | | | | On a few devices, like the Mac Mini, the CRT DDC pins are shared between the analog connector and the digital connector. In this scenario, rely on the EDID to determine if a digital panel is connected to the digital connector. Reported-and-tested-by: Tino Keitel <tino.keitel@tikei.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/sdvo: Only enable HDMI encodings only if the commandset is supportedChris Wilson2010-11-221-11/+14
| | | | | | | | | | | As we conflated intel_sdvo->is_hdmi with both having HDMI support on the ADD along with having HDMI support on the monitor, we would attempt to use HDMI encodings even if the interface did not support those commands. Reported-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
* drm/i915/sdvo: Remove unused encoding memberChris Wilson2010-10-221-23/+22
| | | | | | | This block is only used when detecting whether the connector is HDMI and never again, so scope the variable to the detection routine. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* i915: enable AVI infoframe for intel_hdmi.c [v4]David Härdeman2010-10-221-104/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables the sending of AVI infoframes in drivers/gpu/drm/i915/intel_hdmi.c. My receiver currently loses sync when the HDMI output on my computer (DG45FC motherboard) is switched from 800x600 (the BIOS resolution) to 1920x1080 as part of the boot. Fixable by switching inputs on the receiver a couple of times. With this patch, my receiver has not lost sync yet (> 40 tries). Fourth version, now based on drm-intel-next from: git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git Two questions still remain: I'm assuming that the sdvo hardware also stores a header ECC byte in the MSB of the first dword - is this correct? Does the SDVOB and SDVOC handling in intel_hdmi_set_avi_infoframe() look correct? Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/sdvo: Add 'force_audio' propertyChris Wilson2010-10-191-2/+46
| | | | | | | | | Allow the user to override the detection of the sink's audio capabilities from EDID. Not all sinks support the required EDID level to specify whether they handle audio over the display connection, so allow the user to enable it manually. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson2010-09-281-9/+6
|\
| * drm/i915/sdvo: Handle unsupported GET_SUPPORTED_ENHANCEMENTS gracefullyChris Wilson2010-09-231-5/+4
| | | | | | | | | | | | | | | | | | | | 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: Woody Suwalski <terraluna977@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| * drm/i915/sdvo: Cleanup connector on error pathChris Wilson2010-09-231-4/+2
| | | | | | | | | | | | | | | | | | 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: Woody Suwalski <terraluna977@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/sdvo: Fix GMBUSificationChris Wilson2010-09-281-135/+197
| | | | | | | | | | | | | | | | Besides a couple of bugs when writing more than a single byte along the GMBUS, SDVO was completely failing whilst trying to use GMBUS, so use bit banging instead. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915: INTEL_INFO->gen supercedes i8xx, i9xx, i965gChris Wilson2010-09-211-2/+2
| | | | | | | | | | | | | | Avoid confusion between i965g meaning broadwater and the gen4+ chipset families. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | Merge branch 'drm-intel-fixes' into HEADChris Wilson2010-09-211-2/+3
|\ \ | |/ | | | | | | | | Conflicts: drivers/char/agp/intel-agp.c drivers/gpu/drm/i915/intel_crt.c
| * drm: Use a nondestructive mode for output detect when polling (v2)Chris Wilson2010-09-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm: Use a nondestructive mode for output detect when pollingChris Wilson2010-09-131-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=16265 Reported-by: Bruno Prémont <bonbons@linux-vserver.org> Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/i915: use GMBUS to manage i2c linksChris Wilson2010-09-181-116/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the GMBUS interface rather than direct bit banging to grab the EDID over DDC (and for other forms of auxiliary communication with external display controllers). The hope is that this method will be much faster and more reliable than bit banging for fetching EDIDs from buggy monitors or through switches, though we still preserve the bit banging as a fallback in case GMBUS fails. Based on an original patch by Jesse Barnes. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915: call drm_encoder_init firstChris Wilson2010-09-151-8/+7
| | | | | | | | | | | | | | | | | | | | | | Later initialisation of the encoder often requires that drm_encoder_init() has already been called, for instance, initialiasing the DDC buses. Yet another recent regression, as 819f3fb7 depended upon these fixes which I missed when cherry-picking. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/sdvo: Mark the status as unknown if attached with EDIDChris Wilson2010-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | One problem with devices that share the DDC bus between the VGA and DVI-I connectors is that with two devices attached we cannot know if there is truly a monitor attached to the DVI connector. In this case, it is preferrrable to mark the status as unknown, so that the user can supply the known set of modes and continue to use the output. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/sdvo: Only create the analog encoder as requiredChris Wilson2010-09-151-28/+41
| | | | | | | | | | | | | | We only need to use the analog encoder for rare devices which share the DDC between the DVI-I and VGA connectors, so only create as needed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/sdvo: Propagate i2c error from switching DDC control bus.Chris Wilson2010-09-141-9/+18
| | | | | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/sdvo: Tidy intel_sdvo_hdmi_sink_detectChris Wilson2010-09-141-31/+24
| | | | | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/i2c: Track the parent encoder rather than just the devChris Wilson2010-09-141-36/+26
| | | | | | | | | | | | | | | | The SDVO proxy i2c adapter wants to be able to use information stored in the encoder, so pass that through intel_i2c rather than iterate over all known encoders every time. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/sdvo: Poll command status 5 times without delay on readChris Wilson2010-09-121-35/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The documentation says that an SDVO command takes a maximum of 15us to be processed by the device, and that it is sufficient to read the status byte 3 times (whilst the command is still in the PENDING state) for the driver to be confident that sufficient time has elapsed. We err on the safe side and try 5 times before giving up. The only question that remains: was the old behaviour derived by experiments with real hardware? A look into the murky history of UMS, implies that the behaviour was accidental and the current retry mechanism was solely designed to catch the status byte indicating PENDING with no reference to hardware behaviour. (commit ac9181c014638dbeb334b40b4029d0ccb2b7a0fc in xf86-video-intel) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915: Make the connector->encoder relationship explicitChris Wilson2010-09-091-40/+46
| | | | | | | | | | | | | | | | | | Currently we have a exact mapping of a connector onto an encoder for its whole lifetime. Make this an explicit property of the structure and so simplify the code. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
generated by cgit v1.1 at 2024-05-30 23:24:01 +0000