Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to display continuously updating information 24/7, and so
some code to detect when the driver missed the page flip completion
signal was added. Until recently, it was presumed that the interrupt
handling was now flawless, but once again Simon Farnsworth has found a
system whose display will stall. Reinstate the pageflip stall detection,
which works by checking to see if the hardware has been updated to the
new framebuffer address following each vblank. If the hardware is
scanning out from the new framebuffer, but we still think the flip is
pending, then we kick our driver into submision.
This is a continuation of the effort started with
commit 4e5359cd05
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date: Wed Sep 1 17:47:52 2010 +0100
drm/i915: Avoid pageflipping freeze when we miss the flip prepare interrupt
This now includes a belt-and-braces approach to make sure the driver
(or the hardware) doesn't miss an interrupt and cause us to stop
updating the display should the unthinkable happen and the pageflip fail - i.e.
that the user is able to continue submitting flips.
v2: Cleanup, refactor, and rename
v3: Only start counting vblanks after the flip command has been seen by
the hardware.
v4: Record the seqno after we touch the ring, or else there may be no
seqno allocated yet.
v5: Rebase on mmio-flip.
v6: Rebase, rebase.
Reported-by: Simon Farnsworth <simon@farnz.org.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [v4]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tired of copy/pasting things around.
v2: Rebase on top of the for_each_pipe() change adding dev_priv as first
argument.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The new version of the macro does a few things better:
- protect the arguments,
- only evaluate the arguments once,
- check that the arguments are of the same type,
Change LC_FREQ_2K to be a unsigned 64bit constant and removed the '()'
from the caller as a result.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani wanted some comments to explain why we call certain vdd on/off
functions in certain places.
v2: Make the comments more thorough (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to turn the DP port off after the pipe, otherwise the pipe won't
turn off properly on certain pch platforms at least (happens on my ILK for
example). This also matches the BSpec modeset sequence better. We still
don't match the spec exactly though (eg. audio disable should happen
much earlier), but at last this eliminates the nasty
wait_for_pipe_off() timeouts.
We already did the port disable after the pipe for VLV/CHV and for CPU
eDP.
For g4x leave the port disable where it is since that matches the
modeset sequence in the documentation and I don't have a suitable
machine to test if the other order would work.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bspec says we should enable the DP port before enabling panel power,
and that the port must be enabled with training pattern 1. Do so.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV/CHV the panel power sequencer may need to be "kicked" a bit to
lock onto the new port, and that needs to happen before any aux
transfers are attempted if we want the aux transfers to actaully
succeed. So turn on panel power (part of the "kick") before aux
transfers (DPMS_ON + link training).
This also matches the documented modeset sequence better for pch
platforms. The documentation doesn't explicitly state anything about the
DPMS or link training DPCD writes, but the panel power on step is
always listed before link training is mentioned.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=70117
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Try to make sure we find the power sequencer that the BIOS used
by first looking for one which has the panel power enabled, then
fall back to one with VDD force bit enabled, and finally look at
just the port select bits. This should make us pick the correct
power sequencer when the BIOS has already enabled the panel.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Shorten the vlv_intial_pps_pipe to make lines fit into 80
chars.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The power sequencer loses its state when the disp2d power well is down.
Clear the dev_priv->pps_pipe tracking so that the power sequencer state
gets reinitialized the next time it's needed.
v2: Fix the pps_mutex vs. power_domain mutex deadlock by taking power
domain reference first
v3: Rename from edp_pps_(un)lock() to just pps_(un)lock() for the future,
update due to backlight code changes
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV/CHV have a per-pipe panel power sequencer which locks onto the
port once used. We need to keep track wich power sequencers are
locked to which ports.
v2: remove spurious whitespace change, rebase due to backlight changes (Imre)
Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Break some really long lines to appease checkpatch a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduce a new mutex (pps_mutex) to protect the power sequencer
state. For now this state includes want_panel_vdd as well as the
power sequencer registers.
We need a single mutex (as opposed to per port) because later on we
will need to deal with VLV/CHV which have multiple power sequencer
which can be reassigned to different ports.
v2: Add the locking to intel_dp_encoder_suspend too (Imre)
v3: Take care intel_edp_backlight_power() and
_intel_edp_backlight_on/off(), deal with reboot notifier
vlv_power_sequencer_pipe() call (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville found an old w/a documented for g4x that suggested that we need to
reset the HEAD after writing START. This is a useful fixup for some of
the g4x ring initialisation woes, but as usual, not all.
v2: Do the rewrite unconditionally anyway
References: https://bugs.freedesktop.org/show_bug.cgi?id=76554
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
When unbinding, there is a possibility that we drop the active reference
on the object, thereby freeing it. If that happens, we may destroy the
vm link as well as the object and vma. So iterate carefully.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman <derek.foreman@collabora.co.uk>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Check for !HAS_PCH_SPLIT() instead of 'gen < 5' in the PCH transcoder
enable functions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few open coded HAS_GMCH_DISPLAY() remain in the underrun reporting
code. Convert them over.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
IS_GEN8() is a bad check in the forcewake code due to bdw vs. chv
differences. Use IS_BROADWELL() instead.
The only actual bug here is that we currently call
__gen7_gt_force_wake_mt_reset() on chv. On the other places we
have checked for chv before using IS_GEN8(), but change them
to use IS_BROADWELL() anyway to reduce the chance of accidents in the
future.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV doesn't have FBC, so don't go calling gen8_fbc_sw_flush() on it.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a FIXME comment while at it that we should rework this a
lot more.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use the variable name latency_ns in both the local lowlevel wm
calculation routines and at the global level. Rename the global value to
reduce shadow warnings and future confusion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have CHV code that already makes the test obsolete. Besides, when
num_wa_regs is 0 (platforms not gathering that W/A data), we expose
something sensible already.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we happen to emit more than I915_MAX_WA_REGS workarounds, we will
currently discard them, not even emit the LRI. Not really what we want,
so warn loudly.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When entering intel_ring_emit_wa() with num_wa_regs equal to
I915_MAX_WA_REGS, we end up indexing the intel_wa_regs array beyond its
allocation.
Fix the check then.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those debugfs files are prefixed by i915, the name of the kernel module,
presumably to make the difference with files exposed by core DRM.
Also, add a ',' at the end of the last entry. This is to ease the
conflict resolution when rebasing internal patches that add a member at
the end of the array. Without it, wiggle can't do its job as we need to
modify an existing line (appending the ',').
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, CHV is using the same functions as HSW/BDW instead of the
same functions as VLV. This looks wrong, especially since, for
example, valleyview_modeset_global_resouces even has an IS_CHERRYVIEW
check.
This patch has the potential to fix display audio and the CHV CDCLK.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Also hookup the force() callback for audio detection when the user
forces the connection status.
v3: Ville spots a typo, s/==/!=/
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Implement connector->force() callback so that edid is associated
with the connector for user overrides as well (Ville)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Both gmch and pch detection routines used the exact same routine for
eDP, so de-duplicate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: : Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the last patch in the series, so remove old defines
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_1200 (3 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_3 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adding new defines, older one will be removed in the last patch in the series.
This is to rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
...
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No point in calling intel_plane_restore() in .set_property() if the
value didn't change.
More importantly this papers over a bug where the current primary plane
code forgets to update the user coordinates we store under intel_plane
unless the primary plane .update_plane() hook is actually called. This
means we have 0 in the coordinates straight after boot and any call
to intel_restore_plane() (such as from restore_fbdev_mode()) will
actually turn off the primary plane. This mess needs to be fixed properly
but that's a bigger task and the first step there is killing off
intel_pipe_set_base() and just calling the primary plane
.update_plane() hook. For the immediate problem of black screen after
boot this small patch is enough to hide it.
The problem originates from these two commits:
commit 3a5f87c286
Author: Thomas Wood <thomas.wood@intel.com>
Date: Wed Aug 20 14:45:00 2014 +0100
drm: fix plane rotation when restoring fbdev configuration
commit d91a2cb8e5104233c02bbde539bd4ee455ec12ac
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Fri Aug 22 14:06:04 2014 +0530
drm/i915: Add 180 degree primary plane rotation support
Cc: Thomas Wood <thomas.wood@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Tested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Tested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no need to use hex_dump_to_buffer() since we have a kernel helper to
dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Add cast since %*ph expects and int for the size parameter.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaGsvRC0ResidenncyMethod is for vlv, it doesn't deal with chv
appropriately (eg. doesn't limit rps values to even numbers).
Fix a typo in the w/a name while at it.
Cc: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My Fujistsu-Siemens Lifebook S6010 doesn't like to resume from
S3 unless VGACNTR has been restore to the original value. The BIOS
value in this case was 0x0124008E. Setting the "VGA disable" bit
doesn't interfere with the S3 resume fortunately.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
830M has problems when some of the pipes are disabled. Namely if a
plane, DVO port etc. is currently assigned to a disabled pipe, it
can't moved to the other pipe until the current pipe is also enabled.
To keep things simple just leave both pipes running all the time.
Ideally I think should turn the pipes off if neither is active, and
when either becomes active we enable both. But that would reuquire
proper atomic modeset support, and probably a bit of extra care in
the order things get enabled.
v2: Reorder wrt. double wide handling changes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
830 really does want the pipe A quirk. The planes and ports don't
react to any register writes unless the pipe currently attached
to them is running, so it's impossible to move them to the other
pipe unless both pipes are running.
Also it's documented that the DPLL must be enabled on both pipes
whenever it's needed.
This reverts commit ac6696d3236bd61503f89a1a99680fd7894d5d53.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The vbt on my Fujitsu-Siemens Lifebook S6010 provides two 800x600 modes,
60Hz and 56Hz. The magic register values we have correspond to the 60Hz
mode, and as I don't know how one would trick the VGA BIOS to set up
the 56Hz mode we can't get the magic values for the orther mode. So
when checking whether a mode is valid also check the pixel clock so that
we filter out the 56Hz variant.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.
Looks like IEGD does a one time init of these three registers. We don't
have a good one time init place in the ns2501 driver, so let's just
stick them into the .mode_set() hook and see if that helps things along.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Try to use the same programming sequence as used by the IEGD driver.
Also shovel the magic register values into a big static const array.
The register values are actually the based on what the BIOS programs
on the Fujitsu-Siemens Lifebook S6010. IEGD seemed to have hardcoded
register values (which also enabled the scaler for 1024x768 mode).
However those didn't actually work so well on the S6010. Possibly the
pipe timings that got used didn't match the ns2501 configuration.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Calling the mode_set hook on DPMS changes doesn't seem to be necessary
for ns2501. Just drop it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To more closely match the IEGD ns2501 driver behaviour, call the
mode_set hook while the DVO port is still disabled, then enable the DVO
port, and finally call the dpms hook.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead
of DVOC.
FIXME: Maybe need to dig out the correct DVO port from VBT
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson