summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_sdvo.c
AgeCommit message (Collapse)Author
2014-07-08Merge tag 'topic/core-stuff-2014-06-30' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next misc core patches picked up by Daniel and Jani. * tag 'topic/core-stuff-2014-06-30' of git://anongit.freedesktop.org/drm-intel: drm/fb-helper: Remove unnecessary list empty check in drm_fb_helper_debug_enter() drm/fb-helper: Redundant info->fix.type_aux setting in drm_fb_helper_fill_fix() drm/debugfs: add an "edid_override" file per connector drm/debugfs: add a "force" file per connector drm: add register and unregister functions for connectors drm: fix uninitialized acquire_ctx fields (v2) drm: Driver-specific ioctls range from 0x40 to 0x9f drm: Don't export internal module variables
2014-06-19drm: add register and unregister functions for connectorsThomas Wood
Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-11drm/i915: Avoid div-by-zero when pixel_multiplier is zeroVille Syrjälä
On certain platforms pixel_multiplier is read out in .get_pipe_config(), but it also gets used to calculate the pixel clock in intel_sdvo_get_config(). If the pipe is disable but some SDVO outputs are active, we may end up dividing by zero in intel_sdvo_get_config(). To avoid the problem simply check for zero pixel_multiplier and skip the division. Another attempt at fixing this involved populating pixel_multiplier to 1 even for disabled pipes, but that triggered a WARN because SDVO_CMD_GET_CLOCK_RATE_MULT command failed and thus encoder_pixel_multiplier was left at zero and didn't match pipe_config->pixel_multiplier. The "divide by pixel_multiplier" operation got introduced here: commit 18442d08786472c63a0a80c27f92b033dffc26de Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over and it has caused a regression on certain machines since they would hit the div-by-zero during resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76520 Cc: <stable@vger.kernel.org> # 3.13+ Tested-by: Tim Richardson <tim@tim-richardson.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-06-04drm/i915: replace drm_get_connector_name() with direct name field useJani Nikula
Generated using semantic patches: @@ expression E; @@ - drm_get_connector_name(&E) + E.name @@ expression E; @@ - drm_get_connector_name(E) + E->name v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-05-16drm/i915/sdvo: use config->has_hdmi_sinkDaniel Vetter
This way we can rely on the state cross-checker to have a bit assurance that we'll get it right. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915: state readout and cross checking for limited_color_rangeDaniel Vetter
At least on those platforms which have a simple bit and don't rely on the fully programmable CSC unit to do this. Note that with the current code this includes CHV, but I guess that platform will match BYT. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915/sdvo: Use pipe_config->limited_color_range consistentlyDaniel Vetter
We in the pre_enable hook we should only rely on the pipe config and not on some other state set through properties or detect functions. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-05drm/i915/sdvo: Remove ->mode_set callbackDaniel Vetter
SDVO is used by both crtcs using the i9xx_ and the ironlake_ functions. For both cases there is nothing between the encoder->mode_set and the encoder->pre_enable calls that touches the hardware. The vlv_ functions are different since they enable the pll before the ->pre_enable hook. But SDVO isn't supported on vlv platforms, so this doesn't matter. We've also already clean up all the sdvo state computation logic, all relevant parts are already in the ->compute_config hook. So we can just get rid of the ->mode_set hook by converting it to a ->pre_enable hook. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-15drm/i915/SDVO: For sysfs link put directory and target in correct orderEgbert Eich
When linking the i2c sysfs file into the connector's directory pass directory and link target in the right order. This code was introduced with: commit 931c1c26983b4f84e33b78579fc8d57e4a14c6b4 Author: Imre Deak <imre.deak@intel.com> Date: Tue Feb 11 17:12:51 2014 +0200 drm/i915: sdvo: add i2c sysfs symlink to the connector's directory This is the same what we do for DP connectors, so make things more consistent. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-21drm/i915/sdvo: fix questionable return value checkJani Nikula
intel_sdvo_get_trained_inputs() returns a bool, check the status accordingly. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: Make encoder cloning more flexibleVille Syrjälä
Currently we allow encoders to indicate whether they can be part of a cloned set with just one flag. That's not flexible enough to describe the actual hardware capabilities. Instead make it a bitmask of encoder types with which the current encoder can be cloned. For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should match what the old boolean flag allowed. We will add some more cloning options in the future. Note that this patch also removes the encoder.possible_clones setting from encoder setup code - we compute this dynamically. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add Ville's explanation why removing the encoder possible_clones is save.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-02-14drm/i915: sdvo: add i2c sysfs symlink to the connector's directoryImre Deak
This is the same what we do for DP connectors, so make things more consistent. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-02-14drm/i915: sdvo: fix error path in sdvo_connector_initImre Deak
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-02-14drm/i915: add unregister callback to connectorImre Deak
Since commit d9255d57147e1dbcebdf6670409c2fa0ac3609e6 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date:   Thu Sep 26 20:05:59 2013 -0300 it became clear that we need to separate the unload sequence into two parts: 1. remove all interfaces through which new operations on some object (crtc, encoder, connector) can be started and make sure all pending operations are completed 2. do the actual tear down of the internal representation of the above objects The above commit achieved this separation for connectors by splitting out the sysfs removal part from the connector's destroy callback and doing this removal before calling drm_mode_config_cleanup() which does the actual tear-down of all the drm objects. Since we'll have to customize the interface removal part for different types of connectors in the upcoming patches, add a new unregister callback and move the interface removal part to it. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10drm/i915: Don't cast away const from infoframe bufferVille Syrjälä
We don't modify the packed infoframe data, so we should keep the const qualifier in place. Just pass the buffer as 'const void *' instead of 'const uint8_t *' and we can drop the cast entirely. v2: Do intel_sdvo_write_infoframe() as well Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Return a drm_mode_status enum in the mode_valid vfuncsDamien Lespiau
We had some mode_valid() vfuncs returning an int, others the enum. Let's use the latter everywhere. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915/sdvo: Fix up debug output to not split linesDaniel Vetter
It leads to a big mess when stuff interleaves. Especially with the new patch I've submitted for the drm core to no longer artificially split up debug messages. v2: The size parameter to snprintf includes the terminating 0, but the return value does not. Adjust the logic accordingly. Spotted by Mika. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: destroy connector sysfs files earlierPaulo Zanoni
For some reason, every single time I try to run module_reload something tries to read the connector sysfs files. This happens after we destroy the encoders and before we destroy the connectors, so when the sysfs read triggers the connector detect() function, intel_conector->encoder points to memory that was already freed. The bad backtrace is just: [<ffffffff8163ca9a>] dump_stack+0x54/0x74 [<ffffffffa00c2c8e>] intel_dp_detect+0x1e/0x4b0 [i915] [<ffffffffa001913d>] status_show+0x3d/0x80 [drm] [<ffffffff813d5340>] dev_attr_show+0x20/0x60 [<ffffffff81221f50>] ? sysfs_read_file+0x80/0x1b0 [<ffffffff81221f79>] sysfs_read_file+0xa9/0x1b0 [<ffffffff811aaf1e>] vfs_read+0x9e/0x170 [<ffffffff811aba4c>] SyS_read+0x4c/0xa0 [<ffffffff8164e392>] system_call_fastpath+0x16/0x1b But if you add tons of memory checking debug options to your Kernel you'll also see: - general protection fault: 0000 - BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten - INFO: Allocated in intel_ddi_init+0x65/0x270 [i915] - INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915] Among a bunch of other error messages. So this commit just destroys the sysfs files before both the encoder and connectors are freed. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: Use crtc_clock with the adjusted modeDamien Lespiau
struct drm_mode_display now has a separate crtc_ version of the clock to be used when we're talking about the timings given to the harwadre (was far as the mode is concerned). This commit is really the result of a git grep adjusted_mode.*clock and replacing those by adjusted_mode.crtc_clock. No functional change. v2: Rebased on drm-intel-queued-next Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: Add some debug spam for intialising SDVOChris Wilson
During SDVO initialisation it would be useful to a have a record of the individual devices we try to enable and later probe - in particular to be able to see which fail. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) patternDaniel Vetter
Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-24Merge tag 'v3.12-rc2' into drm-intel-nextDaniel Vetter
Backmerge Linux 3.12-rc2 to prep for a bunch of -next patches: - Header cleanup in intel_drv.h, both changed in -fixes and my current -next pile. - Cursor handling cleanup for -next which depends upon the cursor handling fix merged into -rc2. All just trivial conflicts of the "changed adjacent lines" type: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-16drm/i915: Fix port_clock and adjusted_mode.clock readout all overVille Syrjälä
Now that adjusted_mode.clock no longer contains the pixel_multiplier, we can kill the get_clock() callback and instead do the clock readout in get_pipe_config(). Also i9xx_crtc_clock_get() can now extract the frequency of the PCH DPLL, so use it to populate port_clock accurately for PCH encoders. For DP in port A the encoder is still responsible for filling in port_clock. The FDI adjusted_mode.clock extraction is kept in place for some extra sanity checking, but we no longer need to pretend it's also the port_clock. In the encoder get_config() functions fill out adjusted_mode.clock based on port_clock and other details such as the DP M/N values, HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then do an extra sanity check to make sure the dotclock we derived from the FDI configuratiuon matches the one we derive from port_clock. DVO doesn't exist on PCH platforms, so it doesn't need to anything but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so none of the changes apply there. v2: Use hdmi_reg color format to detect 12bpc HDMI case v3: Set adjusted_mode.clock for LVDS too v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get, eliminate the useless link_freq variable. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-13drm/i915: Make adjusted_mode.clock non-pixel multipliedVille Syrjälä
It would be easier if adjusted_mode.clock would be the pipe pixel clock, and it actually is, except for the cases where pixel_multiplier > 1. So let's change intel_sdvo to use port_clock as the multiplied clock, and then we can leave adjusted_mode.clock as pipe pixel clock. v2: Improve port_clock documentation Rebased on top of SDVO pixel_multiplier fixes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-12drm/i915/sdvo: Robustify the dtd<->drm_mode conversionsDaniel Vetter
We've failed to properly clear out the flags when converting a dtd to a drm mode. For more paranoia just memset the entire structure (and drop the now redundant clears). Also since commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 21 21:37:09 2013 +0200 drm/i915: clean up crtc timings computation we don't update the crtc timings any more properly, so do that again. v2: Remove more redundant clearing, spotted by Ville. v3: Actually make it compile. Oops. v4: Use a temporary structure to fill in the mode and copy it over with drm_mode_copy. This will ensure we don't clobber the mode list or id. Suggested by Ville. Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Use the = {}; structure clearing instead of memset as suggested by Ville.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-10drm/i915/sdvo: Fully translate sync flags in the dtd->mode conversionDaniel Vetter
Instead of just a flag bit for each of the positive/negative sync modes drm actually uses a separate flag for each ... This upsets the modeset checker since the adjusted mode filled out at modeset time doesn't match the one reconstructed at check time (since the ->get_config callback already gets this right). Reported-by: Knut Petersen <Knut_Petersen@t-online.de> Cc: Knut Petersen <Knut_Petersen@t-online.de> References: http://www.gossamer-threads.com/lists/linux/kernel/1778688?do=post_view_threaded Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-05drm/i915: Remove unused mode_fixup() vfunc of struct intel_dvo_dev_opsDamien Lespiau
It's totally unused, so remove the last mode_fixup appearance in i915. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-04drm/i915: handle sdvo input pixel multiplier correctly againDaniel Vetter
The sdvo input timing needs to be the actual mode, the sdvo encoder automatically adjusts for the need of pixel doubling or quadrupling. This was lost in pipe config conversion of the pixel multiplier in commit 6cc5f341b5830541a1b6945435ca90c69b1b8b21 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:53 2013 +0100 drm/i915: add pipe_config->pixel_multiplier While at it ditch the intel_ prefix from the crtc in intel_sdvo_mode_set. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22i915: Fix SDVO potentially turning off randomlyGuillaume Clement
Some Poulsbo cards seem to incorrectly report SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, which causes the display to be turned off. This could also happen to i915. Signed-off-by: Guillaume Clement <gclement@baobob.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-08drm/i915/sdvo: Port the infoframe code to the shared infrastructureDamien Lespiau
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-04drm/i915/sdvo: use intel_encoder for upcast helperDaniel Vetter
It's what all callers (except for the destroy callback which is called from drm core) actually want. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-24drm/i915: Add some debug breadcrumbs to connector detectionChris Wilson
Try to decypher detection failures is a little tricker at the moment as the only indicator of progress is when output_poll_execute() tells us the result after the connector->detect() has run. This patch adds a telltale to the start of each detect function so that we can track progress and associate activity more clearly with each connector. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-12drm/i915: Don't attempt to read an unitialized stack valueDamien Lespiau
If intel_sdvo_get_value() fails here, val is unitialized and the cross check will compare the pipe config multiplier with a bogus value. Instead, only set encoder_pixel_multiplier when the sdvo command has been successful. The cross check will compare the pipe config value with 0 otherwise. v2: Do the cross check with the initial value of encoder_pixel_multiplier (0) if the sdvo command fails (and thus keep the warning) (Daniel Vetter) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01drm/i915: pixel multiplier readout support for pch portsDaniel Vetter
Now that we painstakingly track the shared pch dplls we can finally implement pixel mutliplier readout support for pch ports, too. v2: Undo the temporary hack to disable the sdvo pixel multiplier cross-checking. Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-28Merge tag 'drm-intel-next-2013-06-18' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-next Last 3.11 feature pull. I have a few odds bits and pieces and fixes in my queue, I'll sort them out later on to see what's for 3.11-fixes and what's for 3.12. But nothing to hold this here up imo. Highlights: - more hangcheck work from Mika and Chris to prepare for arb robustness - trickle feed fixes from Ville - first parts of the shared pch pll rework, with some basic hw state readout and cross-checking (this shuts up the confused pch pll refcount WARN that Linus just recently forwarded) - Haswell audio power well support from Wang Xingchao (alsa bits acked by Takashi) - some cleanups and asserts sprinkling around the plane/gamma enabling sequence from Ville - more gtt refactoring from Ben - clear up the adjusted->mode vs. pixel clock vs. port clock confusion - 30bpp support, this time for real hopefully * tag 'drm-intel-next-2013-06-18' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits) drm/i915: remove a superflous semi-colon drm/i915: Kill useless "Enable panel fitter" comments drm/i915: Remove extra "ring" from error message drm/i915: simplify the reduced clock handling for pch plls drm/i915: stop killing pfit on i9xx drm/i915: explicitly set up PIPECONF (and gamma table) on haswell drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms drm/i915: set up PIPECONF explicitly on ilk-ivb drm/i915: find guilty batch buffer on ring resets drm/i915: store ring hangcheck action drm/i915: add batch bo to i915_add_request() drm/i915: change i915_add_request to macro drm/i915: add i915_gem_context_get_hang_stats() drm/i915: add struct i915_ctx_hang_stats drm/i915: Try harder to disable trickle feed on VLV drm/i915: fix up pch pll enabling for pixel multipliers drm/i915: hw state readout and cross-checking for shared dplls drm/i915: WARN on lack of shared dpll drm/i915: split up intel_modeset_check_state drm/i915: extract readout_hw_state from setup_hw_state ... Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_fb.c drivers/gpu/drm/i915/intel_sdvo.c
2013-06-27Merge tag 'v3.10-rc7' into drm-nextDave Airlie
Linux 3.10-rc7 The sdvo lvds fix in this -fixes pull commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jun 10 09:47:58 2013 +0200 drm/i915: prefer VBT modes for SVDO-LVDS over EDID has a silent functional conflict with commit 990256aec2f10800595dddf4d1c3441fcd6b2616 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri May 31 12:17:07 2013 +0000 drm: Add probed modes in probe order in drm-next. W simply need to add the vbt modes before edid modes, i.e. the other way round than now. Conflicts: drivers/gpu/drm/drm_prime.c drivers/gpu/drm/i915/intel_sdvo.c
2013-06-12drm/i915: disable sdvo pixel multiplier cross-check for HAS_PCH_SPLITDaniel Vetter
We don't (yet) have proper pixel multiplier readout support on pch split platforms, so the cross check will naturally fail. v2: Fix spelling in the comment, spotted by Ville. v3: Since the ordering constraint is pretty tricky between the crtc get_pipe_config callback and the encoder->get_config callback add a few comments about it. Prompted by a discussion with Chris Wilson on irc about why this does work anywhere else than on i915g/gm. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10drm/i915: Initialize active_outputs to never read unitialized valuesDamien Lespiau
In case of intel_sdvo_get_active_outputs() failing, we end up reading a value from the stack. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10drm/i915: Fix old reference to i830_sdvo_get_capabilities()Damien Lespiau
It's now intel_sdvo_get_capabilities(). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10drm/i915: prefer VBT modes for SVDO-LVDS over EDIDDaniel Vetter
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. Cc: Egbert Eich <eich@suse.de> Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524 Cc: stable@vger.kernel.org Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10drm/i915: Remove dead code from SDVO initialisationChris Wilson
The hotplug_mask is no longer used as the hpd interrupt setup is now handled in the core. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10drm/i915: Enable hotplug interrupts after querying hw capabilities.Chris Wilson
sdvo->hotplug_active is initialised during intel_sdvo_setup_outputs(), and so we never enabled the hotplug interrupts on SDVO as we were checking too early. This regression has been introduced somewhere in the hpd rework for the storm detection and handling starting with commit 1d843f9de4e6dc6a899b6f07f106c00da09925e6 Author: Egbert Eich <eich@suse.de> Date: Mon Feb 25 12:06:49 2013 -0500 DRM/I915: Add enum hpd_pin to intel_encoder. and the follow-up patches to use the new encoder->hpd_pin variable for the different irq setup functions. The problem is that encoder->hpd_pin was set up _before_ the output setup was done and so before we could assess the hotplug capabilities of the outputs on an sdvo encoder. Reported-by: Alex Fiestas <afiestas@kde.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add regression note.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10drm/i915: Fix hotplug interrupt enabling for SDVOCChris Wilson
A broken conditional would lead to SDVOC waiting upon hotplug events on SDVOB - and so miss all activity on its SDVO port. This regression has been introduced in commit 1d843f9de4e6dc6a899b6f07f106c00da09925e6 Author: Egbert Eich <eich@suse.de> Date: Mon Feb 25 12:06:49 2013 -0500 DRM/I915: Add enum hpd_pin to intel_encoder. References: https://bugs.freedesktop.org/show_bug.cgi?id=58405 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add regression note.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-06drm/i915: pipe config quirk infrastructure plus sdvo mode.flags fixDaniel Vetter
For various reasons the hw state readout might not be able to faithfully match the hw state: - broken hw (like the case which motivated this patch here where the sdvo encoder does not implemented mandatory functionality correctly). - platforms which are not supported fully with the pipe config infrastructure - if our code doesn't support a given hw configuration natively, e.g. special restrictions on the per-pipe panel fitters when they're used in high-quality scaling modes. In all these cases both fastboot and the hw state cross checker need to be aware of these cases and act accordingly. To be able to do this add a new quirk flag to the pipe config structure. The specific case at hand is an sdvo encoder which doesn't implement the get_timings function, so adjusted_mode flags will be wrong. The strange thing though is that the encoder _does_ work, even though it doesn't implement any of the timings functions (so neither get nor set, neither for input nor output timings). Not that non-compliant sdvo encoder are any surprise at all ... v2: - Don't read random garbage from the dtd if the get_timings call failed (suggested by Chris). - Still check the interlaced flag, that's read out from someplace else. We want maximal paranoia, after all. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-06drm/i915: hw state readout support for pixel_multiplierDaniel Vetter
Incomplete since ilk+ support needs proper pch dpll tracking first. SDVO get_config parts based on a patch from Jesse Barnes, but fixed up to actually work. v2: Make sure that we call encoder->get_config _after_ we get_pipe_config to be consistent in both setup_hw_state and the modeset state checker. Otherwise the clever trick with handling the pixel mutliplier on i915G/GM where the encoder overrides the default value of 1 from the crtc get_pipe_config function doesn't work. Spotted by Imre Deak. v3: Actually cross-check the pixel mutliplier (but not on pch split platforms for now). Now actually also tested on a i915G with a sdvo encoder plugged in. Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-05drm/i915: set default value for config->pixel_multiplierDaniel Vetter
This way we can simplify the code quite a bit. Also add a WARN in the sdvo code to complain about a bogus value and kill the readout code in intel_ddi.c that Jesse sneaked in. HW state readout for the pixel multiplier will work a bit differently in the end. v2: Rebase on top of the fdi pixel mutliplier handling fix. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-04drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.Egbert Eich
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> Cc: stable@vger.kernel.org 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>
2013-05-31drm/i915: document why dvo/sdvo/crt need a special dpms functionJani Nikula
In the cloned case, changing just one output but keeping the other, the pipe state won't change and intel_crtc_update_dpms will be a nop, but we still need to update the dpms state of the output being changed. Only dvo, sdvo and crt are cloneable, so only those three have special dpms functions. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-21drm/i915: add encoder get_config function v5Jesse Barnes
We can use this for fetching encoder specific pipe_config state, like mode flags, adjusted clock, etc. Just used for mode flags atm, so we can check the pipe config state at mode set time. v2: get_config when checking hw state too v3: fix DVO and LVDS mode flags (Ville) get SDVO DTD for flag fetch (Ville) v4: use input timings (Ville) correct command used (Ville) remove gen4 check (Ville) v5: get DDI flag config too Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4) Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-21Merge tag 'v3.10-rc2' into drm-intel-next-queuedDaniel Vetter
Backmerge Linux 3.10-rc2 since the various (rather trivial) conflicts grew a bit out of hand. intel_dp.c has the only real functional conflict since the logic changed while dev_priv->edp.bpp was moved around. Also squash in a whitespace fixup from Ben Widawsky for i915_gem_gtt.c, git seems to do something pretty strange in there (which I don't fully understand tbh). Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-12 01:03:30 +0000