1
0
Fork 0
Commit Graph

16 Commits (486a68f5449521edf5ea8a198481fc021da4a3e0)

Author SHA1 Message Date
Julia Lawall 0f55564406 drm/i915: constify intel_dvo_dev_ops structures
The intel_dvo_dev_ops structures are never modified, so declare them as
const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449608127-21715-1-git-send-email-Julia.Lawall@lip6.fr
2015-12-09 08:21:10 +01:00
Ville Syrjälä 7c5f93b05e drm/i915: Constify adjusted_mode
Make adjusted_mode const whereever we don't have to modify it. This only
covers cases when we have a local adjusted_mode variable, and doesn't
make any difference for cases where we just dereference
pipe_config->adjusted_mode.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-30 10:20:11 +02:00
Thomas Richter 14f1fa2d0c drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu S6010
This patch enables the (unfortunately undocumented) scaler of the
NatSemi 2501 DVO found in the Fujitsu-Siemens S6010 laptop and other
machines of the same series and age.

Parts of the DVO scaler logic have been revealed by reverse
engineering and trial and error, so your milage may vary. The
patch (and the whole ns2501 DVO code) is currently only good for
the 1024x768 panel of the S6010, and may hopefully work on other
machines with the same panel size.

The mode-specific configuration of the scaler have been moved out
into a separate class, the mode-agnostic settings remain as raw
register list as their purpose remains unclear at this point.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Thomas Richter <thor@math.tu-berlin.de>
[danvet: Make the thing apply and conform to kernel patch
expectations.]
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-04-23 21:31:58 +02:00
Ville Syrjälä b07aaf8849 drm/i915: Check pixel clock in ns2501 mode_valid hook
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>
2014-09-03 11:05:21 +02:00
Ville Syrjälä d9d9bced0a drm/i915: Init important ns2501 registers
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>
2014-09-03 11:05:19 +02:00
Ville Syrjälä bae06ca122 drm/i915: Rewrite ns2501 driver a bit
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>
2014-09-03 11:05:17 +02:00
Ville Syrjälä 09b0085a9d drm/i915: Kill useless ns2501_dump_regs
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>
2014-09-03 11:05:16 +02:00
Damien Lespiau 6ed6bd84ea drm/i915: Remove spurious semicolons
Found by running the semicolon.cocci spatch:

  https://github.com/coccinelle/coccinellery/blob/master/semicolon/semicolon.cocci

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>
2014-04-09 21:54:33 +02:00
Daniel Vetter 8cbf320209 Merge remote-tracking branch 'airlied/drm-next' into HEAD
Backmerge drm-next after the big s/crtc->fb/crtc->primary->fb/
cocinelle patch to avoid endless amounts of conflict hilarity in my
-next queue for 3.16.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-09 14:33:47 +02:00
Christoph Jaeger 1643a9c6a5 drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMS
DRM_DEBUG_KMS includes printing the function name.

Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-01 22:58:20 +02:00
Lespiau, Damien 29139e4b33 drm/i915: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-03-28 12:57:10 +10:00
Daniel Vetter c77ba21d74 drm/i915/ns2501: Rip out the reenable hack
With the change in the modeset sequence this shouldn't be required
any more since the ->mode_set callback now gets called when the dvo
port is fully up and running.

Also limit the retry loop to 10 tries to avoid hanging the machine
while holding important modeset locks.

Cc: Thomas Richter <thor@math.tu-berlin.de>
Tested-by: Thomas Richter <thor@math.tu-berlin.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-04 16:32:31 +01:00
Daniel Vetter 732ce74f4a drm/i915/dvo: implement get_hw_state
Similar to the sdvo code we poke the dvo encoder whether the output is
active. Safe that dvo encoders are not standardized, so this requires
a new callback into the dvo chip driver.

Hence implement that for all 6 dvo drivers.

v2: With the newly added ns2501 we now have 6 dvo drivers instead of
just 5 ...

Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:58:52 +02:00
Daniel Vetter fac3274c4e drm/i915: simplify dvo dpms interface
All dvo drivers only support 2 dpms states, and our dvo driver
even switches of the dvo port for anything else than DPMS_ON. Hence
ditch this complexity and simply use bool enable.

While reading through this code I've noticed that the mode_set
function of ch7017 is a bit peculiar - it disable the lvds again, even
though the crtc helper code should have done that ... This might be to
work around an issue at driver load, we pretty much ignore the hw
state when taking over.

v2: Also do the conversion for the new ns2501 driver.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-17 10:10:02 +02:00
Daniel Vetter a37b9b349e drm/i915/ns2501: kill pll A enabling hack
With the pipe A quirk properly fixed up for i830M, this shouldn't be
required any longer.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-17 10:10:00 +02:00
Thomas Richter 7434a255a5 drm/i915: Support for ns2501-DVO
This patch adds support for the ns2501 DVO, found in some older Fujitsu/Siemens Labtops.
It is in the state of "works for me".
Includes now proper DPMS support. Includes switching between resolutions -
from 640x480 to 1024x768.
Currently assumes that the native display resolution is 1024x768.

The ns2501 seems to be rather critical - if the output PLL is not
running, the chip doesn't seem to be clocked and then doesn't react
on i2c messages. Thus, a quick'n-dirty trick ensures that the DVO
is active before submitting any i2c messages to it. This is
probably to be reviewed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17902
Signed-off-by: Thomas Richter <thor@math.tu-berlin.de>
[danvet: fixup whitespace fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25 18:23:48 +02:00