summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_sdvo.c
AgeCommit message (Collapse)Author
2013-06-20drm/i915: prefer VBT modes for SVDO-LVDS over EDIDDaniel Vetter
commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 upstream. In commit 53d3b4d7778daf15900867336c85d3f8dd70600c Author: Egbert Eich <eich@suse.de> Date: Tue Jun 4 17:13:21 2013 +0200 drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC Egbert Eich fixed a long-standing bug where we simply used a non-working i2c controller to read the EDID for SDVO-LVDS panels. Unfortunately some machines seem to not be able to cope with the mode provided in the EDID. Specifically they seem to not be able to cope with a 4x pixel mutliplier instead of a 2x one, which seems to have been worked around by slightly changing the panels native mode in the VBT so that the dotclock is just barely above 50MHz. Since it took forever to notice the breakage it's fairly safe to assume that at least for SDVO-LVDS panels the VBT contains fairly sane data. So just switch around the order and use VBT modes first. v2: Also add EDID modes just in case, and spell Egbert correctly. v3: Elaborate a bit more about what's going on on Chris' machine. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524 Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-13drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.Egbert Eich
commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream. In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. This regression seems to have been introduced in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add note about which commit likely introduced this issue.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/i915: clear the entire sdvo infoframe bufferDaniel Vetter
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>
2012-11-17drm/i915: fixup infoframe support for sdvoDaniel Vetter
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>
2012-06-10drm/i915: properly handle interlaced bit for sdvo dtd conversionDaniel Vetter
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>
2012-05-07drm/i915: handle input/output sdvo timings separately in mode_setDaniel Vetter
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>
2012-02-03drm/i915/sdvo: always set positive sync polarityPaulo Zanoni
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>
2011-06-04drm/i915: Share the common force-audio property between connectorsChris Wilson
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>
2011-05-18drm/i915/sdvo: Reorder i2c initialisation before ddc proxyChris Wilson
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>
2011-03-14Merge remote branch 'intel/drm-intel-next' of ../drm-next into drm-core-nextDave Airlie
* '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
2011-02-23drm: Mark constant arrays of drm_display_mode constChris Wilson
... 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>
2011-02-22drm/i915: Add support for limited color range of broadcast outputsChris Wilson
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>
2011-02-16Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson
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
2011-02-11drm/i915: Trigger modesetting if force-audio changesChris Wilson
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>
2011-02-09drm/i915/sdvo: If we have an EDID confirm it matches the mode of the connectionChris Wilson
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
2011-02-01Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson
Merge resume fixes from -fixes and an important fix for SDVO GMBUS.
2011-01-26drm/i915/sdvo: Add BUILD_BUG_ON to warn if the structs are ever miscompiledChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-01-26drm/i915/sdvo: Use a compact test for determining a multi-function deviceChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-01-25drm/i915/sdvo: If at first we don't succeed in reading the response, waitChris Wilson
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>
2011-01-11drm/i915/sdvo: Defer detection of output capabilities until probingChris Wilson
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
2011-01-05Merge branch 'master' of /home/airlied/kernel/linux-2.6 into drm-core-nextDave Airlie
2010-12-23drm/i915/sdvo: Add hdmi connector properties after initing the connectorChris Wilson
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>
2010-12-16drm/i915/sdvo: Border and stall select became test bits in gen5Chris Wilson
This is even more important as those bits will be moved in future. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-12-09drm/i915/sdvo: Only use the SDVO pin if it is in the valid rangeChris Wilson
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>
2010-11-24drm/i915/sdvo: Always add a 30ms delay to make SDVO TV detection reliableChris Wilson
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
2010-11-23drm/i915/sdvo: Always fallback to querying the shared DDC lineChris Wilson
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>
2010-11-22drm/i915/sdvo: Only enable HDMI encodings only if the commandset is supportedChris Wilson
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>
2010-10-22drm/i915/sdvo: Remove unused encoding memberChris Wilson
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>
2010-10-22i915: enable AVI infoframe for intel_hdmi.c [v4]David Härdeman
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>
2010-10-19drm/i915/sdvo: Add 'force_audio' propertyChris Wilson
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>
2010-09-28Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson
2010-09-28drm/i915/sdvo: Fix GMBUSificationChris Wilson
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>
2010-09-23drm/i915/sdvo: Handle unsupported GET_SUPPORTED_ENHANCEMENTS gracefullyChris 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: 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>
2010-09-23drm/i915/sdvo: Cleanup connector on error pathChris 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: 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>
2010-09-21drm/i915: INTEL_INFO->gen supercedes i8xx, i9xx, i965gChris Wilson
Avoid confusion between i965g meaning broadwater and the gen4+ chipset families. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-21Merge branch 'drm-intel-fixes' into HEADChris Wilson
Conflicts: drivers/char/agp/intel-agp.c drivers/gpu/drm/i915/intel_crt.c
2010-09-18drm/i915: use GMBUS to manage i2c linksChris Wilson
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>
2010-09-15drm/i915: call drm_encoder_init firstChris Wilson
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>
2010-09-15drm/i915/sdvo: Mark the status as unknown if attached with EDIDChris Wilson
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>
2010-09-15drm/i915/sdvo: Only create the analog encoder as requiredChris Wilson
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>
2010-09-14drm/i915/sdvo: Propagate i2c error from switching DDC control bus.Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-14drm/i915/sdvo: Tidy intel_sdvo_hdmi_sink_detectChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-14drm/i915/i2c: Track the parent encoder rather than just the devChris Wilson
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>
2010-09-14drm: Use a nondestructive mode for output detect when polling (v2)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: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-09-13drm: Use a nondestructive mode for output detect when pollingChris 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=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>
2010-09-12drm/i915/sdvo: Poll command status 5 times without delay on readChris Wilson
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>
2010-09-09drm/i915: Make the connector->encoder relationship explicitChris Wilson
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>
2010-09-09drm/i915: Rename intel_encoder->enc to base for consistencyChris Wilson
[Patch is slightly larger than is strictly necessary to fixup surrounding checkpatch.pl errors.] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-09-08drm/i915/sdvo: Preserve pixel-multiplierChris Wilson
Store the pixel-multiplier on the adjusted mode and avoid modifying the requested mode. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-07drm/i915/sdvo: Restore guess of the DDC bus in absence of VBIOSChris 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, 14571b4). 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=15109 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de> Cc: Adam Jackson <ajax@redhat.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: stable@kernel.org