aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/dvo_ns2501.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2015-12-09drm/i915: constify intel_dvo_dev_ops structuresJulia Lawall1-1/+1
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-09-30drm/i915: Constify adjusted_modeVille Syrjälä1-2/+2
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-04-23drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu S6010Thomas Richter1-296/+374
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>
2014-09-03drm/i915: Check pixel clock in ns2501 mode_valid hookVille Syrjälä1-3/+3
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-03drm/i915: Init important ns2501 registersVille Syrjälä1-0/+10
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-03drm/i915: Rewrite ns2501 driver a bitVille Syrjälä1-204/+325
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-03drm/i915: Kill useless ns2501_dump_regsVille Syrjälä1-17/+0
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-04-09drm/i915: Remove spurious semicolonsDamien Lespiau1-1/+1
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-09Merge remote-tracking branch 'airlied/drm-next' into HEADDaniel Vetter1-5/+5
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-01drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMSChristoph Jaeger1-14/+8
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-03-28drm/i915: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()Lespiau, Damien1-5/+5
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>
2013-11-04drm/i915/ns2501: Rip out the reenable hackDaniel Vetter1-69/+4
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>
2012-09-06drm/i915/dvo: implement get_hw_stateDaniel Vetter1-0/+15
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-08-17drm/i915: simplify dvo dpms interfaceDaniel Vetter1-8/+6
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-17drm/i915/ns2501: kill pll A enabling hackDaniel Vetter1-7/+0
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-07-25drm/i915: Support for ns2501-DVOThomas Richter1-0/+582
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>