Commit Graph

167 Commits

Author SHA1 Message Date
Daniel Vetter
ff9a6750ac drm/i915: store adjusted dotclock in adjusted_mode->clock
... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.

Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
overwrite it when retrying the crtc/encoder bw arbitrage step in the
compute config stage. Hence we need to always clear port_clock and
update it again if the encoder hasn't put in something more specific.
This can't be done in one step since the encoder might want to adjust
the mode first.

I was a bit on the fence whether I should subsume the pixel multiplier
handling into the port_clock, too. But then I decided against this
since it's on an abstract level still the dotclock of the adjusted
mode, and only our hw makes it a bit special due to the separate pixel
mulitplier setting (which requires that the dpll runs at the
non-multiplied dotclock).

So after this patch the adjusted_mode accurately describes the mode we
feed into the port, after the panel fitter and pixel multiplier (or
line doubling, if we ever bother with that) have done their job.
Since the fdi link is between the pfit and the pixel multiplier steps
we need to be careful with calculating the fdi link config.

v2: Fix up ilk cpu pll handling.

v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
to make it clearer that we transmit the adjusted_mode without the
pixel multiplier taken into account. The old code multiplied the the
available link bw with the pixel multiplier, which results in the same
fdi configuration, but is much more confusing.

v4: Rebase on top of Imre's is_cpu_edp removal.

v5: Rebase on top of Paulo's haswell watermark fixes, which introduce
a new place which looked at the pixel_clock and so needed conversion.

v6: Split out prep patches as requested by Paulo Zanoni. Also rebase
on top of the fdi dotclock handling fix in the fdi lanes/bw
computation code.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-04 14:01:48 +02:00
Jani Nikula
ae99258f02 drm/i915: rename VLV IOSF sideband functions logically
Rename all VLV IOSF sideband register accessor functions to
vlv_<port>_{read,write}. No functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-23 23:25:10 +02:00
Jani Nikula
a1ca802d98 drm/i915: drop redundant warnings on not holding dpio_lock
The lower level sideband read/write functions already do this.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-23 23:24:46 +02:00
Jesse Barnes
045ac3b562 drm/i915: add encoder get_config function v5
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-21 09:55:19 +02:00
Daniel Vetter
e1b73cba13 Linux 3.10-rc2
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iQEcBAABAgAGBQJRmpexAAoJEHm+PkMAQRiGrRIH/1uWFW38RvaCV/PXm/ia6Z+x
 BfBJfBIvPxGwb4n7aQNQlhU25xkfrPZ6szO4WiBH5/KPH3xYi2I2OZ1AzffkYqMF
 BWkPmsPK6EsTdp16zsi6JtH2aXArG4SpYA7ZamPvDkmfigHuiZg7GlL/9eHTRPNV
 P7Q8JToOrcnP8RoGgNj0uFiQeQbc62Kmoq7WuPtUhVlpQCCCknXgOJiYgz9w6Xe9
 /i79YFS8WRrzAquExT1NbIOh4ZMqB9MvuroaVWy8JDDLUyz7QUvOCe3tCDNguwgi
 FdWvU6nfkdQq5SLaWCWXDE9Rp/pL1MvfBn9vCOwFcp42aw0aQ0PgJVIXvsqufd0=
 =jgDI
 -----END PGP SIGNATURE-----

Merge tag 'v3.10-rc2' into drm-intel-next-queued

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>
2013-05-21 09:52:16 +02:00
Daniel Vetter
e29c22c0c4 drm/i915: implement fdi auto-dithering
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.

The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.

But ports compute their state under the assumption that the bpp they
pick will be the one selected, e.g. the display port bw computations
won't work otherwise. Now we could adjust our code to again up-dither
to the computed DP link parameters, but that's pointless.

So instead when the pipe needs to adjust parameters we need to retry
the pipe_config computation at the encoder stage. Furthermore we need
to inform encoders that they should not increase bandwidth
requirements if possible. This is required for the hdmi code, which
prefers the pipe to up-dither to either of the two possible hdmi bpc
values.

LVDS has a similar requirement, although that's probably only
theoretical in nature: It's unlikely that we'll ever see an 8bpc
high-res lvds panel (which is required to hit the 2 fdi lane limit).

eDP is the only thing which could increase the pipe_bpp setting again,
even when in the retry-loop. This could hit the WARN. Two reasons for
not bothering:
- On many eDP panels we'll get a black screen if the bpp settings
  don't match vbt. So failing the modeset is the right thing to do.
  But since that also means it's the only way to light up the panel,
  it should work. So we shouldn't be able to hit this WARN.
- There are still opens around the eDP panel handling, and maybe we
  need additional tricks. Before that happens it's imo no use trying
  to be too clever.
Worst case we just need to kill that WARN or maybe fail the compute
config stage if the eDP connector can't get the bpp setting it wants.
And since this can only happen with an fdi link in between and so for
pch eDP panels it's rather unlikely to blow up, if ever.

v2: Rebased on top of a bikeshed from Paulo.

v3: Improve commit message around eDP handling with the stuff
things with Imre.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-29 21:51:17 +02:00
Daniel Vetter
325b9d0488 drm/i915: fixup 12bpc hdmi dotclock handling
We need to multiply the hdmi port dotclock by 1.5x since it's not
really a dotclock, but the 10/8 encoding bitclock divided by 10.

Also add correct limit checks for the dotclock and reject modes which
don't fit. HDMI 1.4 would allow more, but our hw doesn't support that
unfortunately :(

Somehow I suspect 12bpc hdmi output never really worked - we really
need an i-g-t testcase to check all the different pixel modes and
outputs.

v2: Fixup the adjusted port clock handling - we need to make sure that
the fdi link code still gets the real pixelclock.

v3: g4x/vlv don't support 12bpc hdmi output so drop the bogus comment.

Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Switch dotclock limit check to <= as suggested by Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-29 21:51:17 +02:00
Daniel Vetter
ae4edb8089 drm/i915: avoid full modeset when changing the color range properties
Automatic color range selection was added in

commit 55bc60db59
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Jan 17 16:31:29 2013 +0200

    drm/i915: Add "Automatic" mode for the "Broadcast RGB" property

but that removed the check to avoid a full modeset if the value is
unchanged. Unfortunately X sets all properties with their current
value at start-up, resulting in some ugly flickering which shouldn't
be there.

v2: Change old_range from bool to uint32_t, spotted by Ville.

v3: Actually git add everything ;-)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 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>
2013-04-23 13:52:57 +02:00
Jesse Barnes
89b667f86a drm/i915: update VLV PLL and DPIO code v11
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric.  Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.

We need to make sure that the tx lane reset occurs in both the full mode
set and DPMS paths, so factor things out to allow that.

v2: use different DPIO_DIVISOR values for VGA and DisplayPort
v3: Fix update pll logic to use same DPIO_DIVISOR & DPIO_REFSFR values
        for all display interfaces
v4: collapse with various updates
v5: squash with crtc enable/pll enable bits
v6: split out DP code (jbarnes)
    put phyready check under IS_VALLEYVIEW (jbarnes)
    remove unneeded check in 9xx pll div update (Jani)
    wrap VLV pll update call in IS_VALLEYVIEW (Jani)
    move port enable back to end of crtc enable (jbarnes)
    put phyready check under IS_VALLEYVIEW (jbarnes)
v7: fix up conflicts against latest drm-intel-next-queued
v8: use DPIO reg names, fix pipes (Jani)
    from mPhy_registers_VLV2_ww20p5 doc
v9: update to latest info from driver enabling notes doc
    driver_vbios_notes_9
v10: fixup a bit of pipe/port confusion to allow eDP and HDMI to work
     simultaneously (Jesse)
v11: use pll/port callbacks for DPIO port activity (Daniel)
     use separate VLV CRTC enable function (Daniel)
     move around port ready checks (Jesse)

Signed-off-by: Pallavi G <pallavi.g@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop pfit changes and add a little comment explaining that
vlv has a different enable sequence and so needs it's own crtc_enable
callback. Also apply a fixup patch from Wu Fengguang to shut up some
compiler warnings.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-19 09:10:33 +02:00
Daniel Vetter
3b117c8f28 drm/i915: move cpu_transcoder to the pipe configuration
For a bunch of reason we need to more accurately track this:
- hw pipe state readout for Haswell needs the cpu transcoder.
- We need to know the right cpu transcoder in a bunch of places in
  ->disable and other modeset callbacks.

In the future we need to add hw state readout&check support, too. But
to avoid ugly merge conflicts do the rote sed job now without any
functional changes.

v2: Preserve the cpu_transcoder value when overwriting crtc->config.
Reported by Paulo.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: Removed rough whitespace that Chris spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18 09:43:32 +02:00
Egbert Eich
821450c693 drm/i915: (re)init HPD interrupt storm statistics
When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that storm
detection doesn't mess up the settings for those connectors.
Therefore we store the settings in the intel_connector struct and
restore them from there.
If nothing is set but the encoder has a hpd_pin set we assume this
connector is hotplug capable.
On init/reset we make sure the polled state of the connectors
is (re)set to the default value, the HPD interrupts are marked
enabled.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18 09:43:29 +02:00
Ville Syrjälä
83a2af88f8 drm/i915: Don't use the HDMI port color range bit on Valleyview
VLV docs still list the the color range selection bit for the HDMI
ports, but for DP ports it has been repurposed.

I have no idea whether the HDMI color range selection bit still works
on VLV, but since we now have to use the PIPECONF color range bit for
DP, we might as well do the same for HDMI.

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-04-05 20:47:20 +02:00
Daniel Vetter
4e53c2e010 drm/i915: precompute pipe bpp before touching the hw
The procedure has now 3 steps:

1. Compute the bpp that the plane will output, this is done in
   pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
   this function clamps the pipe_bpp to whatever limit the EDID of any
   connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
   whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
   computed pipe_bpp.

There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
  a 2nd change we now unconditionally force the lvds bpc value - this
  shouldn't matter in reality when the panel setup is consistent, but
  better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
  what we actually want, since otherwise at least the pixelclock
  computations are wrong (I'm not sure whether the port would accept
  e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
  the next higher bpc value, since otherwise there's no way to make
  use of the 12 bpc mode (since the next patch will remove the 12bpc
  plane format, it doesn't exist).

Both of these changes are due to the removal of the

	pipe_bpp = min(display_bpp, plane_bpp);

statement.

Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
  the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
  all available bpp values in an outer loop and the codeblock that
  computes derived values (once a good configuration is found) has been
  moved out of the for loop maze. This is prep work to allow us to
  successively fall back on bpc values, and also correctly support bpc
  values != 8 or 6.

v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.

v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.

v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.

v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.

v6: Fix spelling in a comment.

v7: Debug output improvements for the bpp computation.

v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!

v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.

v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.

v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.

v12: Rebased.

v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.

v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-28 01:09:33 +01:00
Daniel Vetter
965e0c489f drm/i915: introduce pipe_config->dither|pipe_bpp
We want to compute this earlier. To avoid a big complicated patch,
this patch here just does the big search&replace and still calls the
old functions at the same places.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-28 01:09:29 +01:00
Daniel Vetter
50f3b016b0 drm/i915: add pipe_config->limited_color_range
Now that we have a useful struct for this, let's use it. Some neat
pointer-chasing required, but it's all there already.

v2: Rebased on top of the added Haswell limited color range support.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-28 00:50:07 +01:00
Daniel Vetter
5bfe2ac003 drm/i915: add pipe_config->has_pch_encoder
This is used way too often in the enable/disable paths. And will
be even more useful in the future.

Note that correct semantics of this change highly depend upon
correct updating of intel_crtc->config: Like with all other
modeset state, we need to call ->disable with the old config,
but ->mode_set and ->enable with the new config.

v2: Do not yet use the flag in the ->disable callbacks - atm we don't
yet have support for the information stored in the pipe_config in the
hw state readout code, so this will be wrong at boot-up/resume.

v3: Rebased on top of the hdmi/dp ddi encoder merging.

v4: Fixup stupid rebase error which lead to a NULL vfunc deref.

v5: On haswell the VGA port is on the PCH!

v6: s/IS_HASWELL/HAS_DDI/, spotted by Paulo Zanoni. Also add a missing
parameter name in a function declaration.

v7: Don't forget to git add ...

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-28 00:50:07 +01:00
Egbert Eich
4f770a5bee DRM/i915: Get rid if the 'hotplug_supported_mask' in struct drm_i915_private.
Now since we have replaced the bits to show interest in hotplug IRQs
we can go and nuke the 'hotplug_supported_mask'.

Signed-off-by: Egbert Eich <eich@suse.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-27 17:13:43 +01:00
Egbert Eich
1d843f9de4 DRM/I915: Add enum hpd_pin to intel_encoder.
To clean up hotplug support we add a new enum to intel_encoder:
enum hpd_pin. It allows the encoder to request a hpd line but leave
the details which IRQ is responsible on which chipset generation
to i915_irq.c.
This way requesting hotplug support will become really simple on
the encoder/connector level.

Signed-off-by: Egbert Eich <eich@suse.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-26 21:50:22 +01:00
Jesse Barnes
7637bfdb54 drm/i915: use VLV DIP routines on VLV v2
This fixes up broken logic introduced in

commit 90b107c8f7
Author: Shobhit Kumar <shobhit.kumar@intel.com>
Date:   Wed Mar 28 13:39:32 2012 -0700

    drm/i915: Enable HDMI on ValleyView

That one was probably a rebase fail along the way.

v2: clean up init ordering (Daniel)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Pimp commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-23 12:17:59 +01:00
Daniel Vetter
0d4a42f6bd Linux 3.9-rc3
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iQEcBAABAgAGBQJRRkrbAAoJEHm+PkMAQRiGy3oH/jrbHinYs0auurANgx4TdtWT
 /WNajstKBqLOJJ6cnTR7sOqwOVlptt65EbbTs+qGyZ2Z2W/Lg0BMenHvNHo4ER8C
 e7UbMdBCSLKBjAMKh1XCoZscGv4Exm8WRH3Vc5yP0Hafj3EzSAVLY1dta9WKKoQi
 bh7D1ErUlbU1zczA1w5YbPF0LqFKRvyZOwebMCCAKAxv5wWAxmbcPNxVR4sufkjg
 k6TkQ2ysgWivZAfy3tJYOcxiEu7ahpZVEuYdlZEJQXHRQUfoNljQlOp4BqKsYUai
 5A0kaf2VpKay/7pkhvTfBBcF/jFJ68pYP6gQ2ThNdr0b5kOiAfMWj030Xyngnhg=
 =iO9t
 -----END PGP SIGNATURE-----

Merge tag 'v3.9-rc3' into drm-intel-next-queued

Backmerge so that I can merge Imre Deak's coalesced sg entries fixes,
which depend upon the new for_each_sg_page introduce in

commit a321e91b6d
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Feb 27 17:02:56 2013 -0800

    lib/scatterlist: add simple page iterator

The merge itself is just two trivial conflicts:

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-19 09:47:30 +01:00
Paulo Zanoni
4f3a8bc7ba drm/i915: rename some HDMI bit definitions
Bits used only on HDMI mode now have HDMI_ prefix instead of SDVO_.
The COLOR_FORMAT bits now have prefixes (and the 12bpc bit is for HDMI
only).

Notice that this patch uncovers a bug on the SDVO code: the
COLOR_RANGE_16_235 bit can only be used if the port is in TMDS mode,
not SDVO mode. This will have to be fixed in a later patch.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-04 23:17:00 +01:00
Paulo Zanoni
dc0fa71811 drm/i915: remove duplicated SDVO/HDMI bit definitions
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-04 23:16:57 +01:00
Rodrigo Vivi
7d9bcebe13 drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe
While old platforms had 3 transcoders and 3 pipes (1:1), HSW has
4 transcoders and 3 pipes.
These regs were being used only by HDMI code where pipe is always the same
thing as cpu_transcoder.
This patch allow us to use them for DP, specially for TRANSCODER_EDP.

v2: Adding HSW_TVIDEO_DIP_VSC_DATA to transmit vsc to eDP.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-03 18:24:52 +01:00
Dave Airlie
28ee46184f Merge branch 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux into drm-next
Thierry writes:
"Remove a duplicate implementation of the CEA VIC lookup and move the CEA
and other mode tables to drm_edid.c to make it more difficult to create
duplicates of the tables.

Add some helpers to pack CEA-861/HDMI AVI, audio and SPD infoframes into
binary buffers that can easily be written into hardware registers. A new
helper function makes it easy construct an AVI infoframe from a DRM
display mode.

Convert the Tegra and Radeon drivers to use the new HDMI helpers."
* 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux:
  drm/radeon: Use generic HDMI infoframe helpers
  drm/tegra: Use generic HDMI infoframe helpers
  drm: Add EDID helper documentation
  drm: Add HDMI infoframe helpers
  video: Add generic HDMI infoframe helpers
  drm: Add some missing forward declarations
  drm: Move mode tables to drm_edid.c
  drm: Remove duplicate drm_mode_cea_vic()
2013-02-24 12:39:42 +10:00
Dave Airlie
a497bfe9db Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Two regressions fixes from snowboarding land

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Revert hdmi HDP pin checks
  drm/i915: Handle untiled planes when computing their offsets
2013-02-24 12:39:02 +10:00
Daniel Vetter
202adf4b9f drm/i915: Revert hdmi HDP pin checks
This reverts

commit 8ec22b214d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 11 18:01:34 2012 +0100

    drm/i915/hdmi: Query the live connector status bit for G4x

and

commit b0ea7d37a8
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Thu Dec 13 16:09:00 2012 +0000

    drm/i915/hdmi: Read the HPD status before trying to read the EDID

They reliably cause HDMI to not be detected on some systems (like my
ivb or the bug reporters gm45). To fix up the very slow unplug issues
we might want to fire up a 2nd detect cycle a few hundred ms after
each hotplug. But for now at least make displays work again.

I somewhat suspect that this is confined to HDMI connectors, since all
the machines I have with DP+ outputs work correctly.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52361
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org.kernel.org # for 8ec22b21
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-22 13:04:33 +01:00
Thierry Reding
18316c8c39 drm: Remove duplicate drm_mode_cea_vic()
The same function had already been merged with a different name. Remove
the duplicate one but reuse some of its kerneldoc fragments for the
existing implementation.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2013-02-22 08:19:53 +01:00
Dave Airlie
b81e059ec5 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
So here's my promised pile of fixes for 3.9. I've dropped the core prep
patches for vt-switchless suspend/resume as discussed on irc. Highlights:
- Fix dmar on g4x. Not really gfx related, but I'm fed up with getting
  blamed for dmar crapouts.
- Disable wc ptes updates on ilk when dmar is enabled (Chris). So again,
  dmar, but this time gfx related :(
- Reduced range support for hsw, using the pipe CSC (Ville).
- Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is
  already confirmed to fix 2 bug reports, so added cc: stable on that one.
- Regression fix for 8bit fb console (Ville).
- Preserve lane reversal bits on DDI/FDI ports (Damien).
- Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of
  them, need to decide what to do with the currently still in-flight ones.
- Panel fitter regression fix from Mika Kuoppala (was accidentally left on
  on some pipes with the new modset code since 3.7). This also improves
  the modeset sequence and might help a few other unrelated issues with
  lvds.
- Write backlight regs even harder ... another installement in our eternal
  fight against the BIOS and backlights.
- Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for
  new ACPI stuff, but closing the race itself seems worthwile on its own.
- A few other small fixes and tiny cleanups all over.

Lots of the patches are cc: stable since I've stalled on a few
not-so-important fixes for 3.8 due to the grumpy noise Linus made.

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits)
  intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
  drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
  drm/i915: Implement pipe CSC based limited range RGB output
  drm/i915: inverted brightness quirk for Acer Aspire 4736Z
  drm/i915: Print the hw context status is debugfs
  drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap
  drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+
  drm/i915: Set i9xx sdvo clock limits according to specifications
  drm/i915: Set i9xx lvds clock limits according to specifications
  drm/i915: Preserve the DDI link reversal configuration
  drm/i915: Preserve the FDI line reversal override bit on CPT
  drm/i915: add missing \n to UTS_RELEASE in the error_state
  drm: Use C8 instead of RGB332 when determining the format from depth/bpp
  drm: Fill depth/bits_per_pixel for C8 format
  drm/i915: don't clflush gem objects in stolen memory
  drm/i915: Don't wait for page flips if there was GPU reset
  drm/i915: Kill obj->pending_flip
  drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment
  drm/i915: remove bogus mutex_unlock from error-path
  drm/i915: Print the pipe control page GTT address
  ...
2013-02-20 11:41:26 +10:00
Paulo Zanoni
b242b7f745 drm/i915: rename sdvox_reg to hdmi_reg on HDMI context
Some (but not all) of the HDMI registers can be used to control sDVO,
so those registers have two names. IMHO, when we're talking about
HDMI, we really should call the HDMI control register "hdmi_reg"
instead of "sdvox_reg", otherwise we'll just confuse people reading
our code (we now have platforms with HDMI but without SDVO). So now
"struct intel_hdmi" has a member called "hdmi_reg" instead of
"sdvox_reg".

Also, don't worry: "struct intel_sdvo" still has a member called
"sdvo_reg".

v2: Rebase (v1 was sent in May 2012).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20 01:33:46 +01:00
Paulo Zanoni
22b8bf17c6 drm/i915: use HAS_DDI on intel_hdmi.c and intel_display.c
Since basically every code called on these places comes from
intel_ddi.c

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20 01:33:45 +01:00
Daniel Vetter
26739f12cf drm/i915: unify HDMI/DP hpd definitions
They're physically the same pins and also the same bits, duplicating
only confuses the reader. This also makes it a bit obvious that we
have quite some code duplication going on here. Squashing that is for
a larger rework in our hpd handling though.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-15 10:30:37 +01:00
Daniel Vetter
af5676f1f9 drm/i915: rip out helper->disable noop functions
Now that the driver is in control of whether it needs to disable
everything at take-over or not, we can rip this all out.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-14 00:07:54 +01:00
Ville Syrjälä
69fde0a610 drm/i915: Convert intel_hdmi to enum port
Use intel_dig_port->port rather than intel_hdmi->sdvox_erg.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-24 22:25:59 +01:00
Ville Syrjälä
abedc077b4 drm/i915: Provide the quantization range in the AVI infoframe
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.

As per CEA-861 [1] we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.

[1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame

v2: Give the Q bits better names, add spec chapter information

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-20 13:09:45 +01:00
Ville Syrjälä
55bc60db59 drm/i915: Add "Automatic" mode for the "Broadcast RGB" property
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.

Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise full range output is used.
Additionally DVI monitors should most likely default to full range
always.

As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and
otherwise will follow CEA-861 rules.

NOTE: The default value for the property will now be "Automatic"
so some people may be affected in case they're relying on the
current full range default.

[1] CEA-861-E - 5.1 Default Encoding Parameters
[2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry

v2: Use has_hdmi_sink to check if a HDMI monitor is present
v3: Add information about relevant spec chapters

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-20 13:09:44 +01:00
Ville Syrjälä
3685a8f38f drm/i915: Fix RGB color range property for PCH platforms
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.

Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limited color range is requested.
Set the the PIPECONF bit 13 based on the flag.

Experimentation showed that simply toggling the bit while the pipe is
active doesn't work. We need to restart the pipe, which luckily already
happens.

The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
although it doesn't seem to do any harm in practice.

TODO:
- the PIPECONF bit too seems to have disappeared from HSW. Need a
  volunteer to test if it's just a documentation issue or if it's really
  gone. If the bit is gone and no easy replacement is found, then I suppose
  we may need to use the pipe CSC unit to perform the range compression.

v2: Use mode private_flags instead of intel_encoder virtual functions
v3: Moved the intel_dp color_range handling after bpc check to help
    later patches

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-20 13:09:43 +01:00
Chris Wilson
c0c36b941b drm/i915: Return the real error code from intel_set_mode()
Note: This patch also adds a little helper intel_crtc_restore_mode for
the common case where we do a full modeset but with the same
parameters, e.g. to undo bios damage or update a property.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Added note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-20 21:09:55 +01:00
Damien Lespiau
b0ea7d37a8 drm/i915/hdmi: Read the HPD status before trying to read the EDID
If you unplug the hdmi connector slowly enough, the hotplug interrupt
fires but then the kernel code tries to read the EDID and succeeds
(because the connector is still half connected, the HPD pin is shorter
than the others, and DDC works). Since EDID succeeds it thinks the
monitor is still connected.

To prevent that, read the live HPD status in the hotplug handler before
trying to read the EDID.

v2: Rename the function to ibx_ (Chris Wilson)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55372
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>
2012-12-14 11:12:58 +01:00
Paulo Zanoni
affa935440 drm/i915: add HAS_DDI check
And use it whenever we call code that uses the DDIs. We already have
intel_ddi.c and prefix every function with intel_ddi_something instead of
haswell_something, so I think replacing the checks with HAS_DDI makes more
sense. Just a cosmetical change, yes I know, but I have this OCD...

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-29 14:58:53 +01:00
Paulo Zanoni
9a69b885e9 drm/i915: set the VIC of the mode on the AVI InfoFrame
We currently set "0" as the VIC value of the AVI InfoFrames. According
to the specs this should be fine and work for every mode, so to my
point of view we can't consider the current behavior as a bug. The
problem is that  we recently received a bug report (Kernel bug #50371)
from a user that has an AV receiver that gives a black screen for any
mode with VIC set to 0.

So in order to make at least some modes work for him, this patch sets
the correct VIC number when sending AVI InfoFrames.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-29 11:42:38 +01:00
Rob Clark
662595df9f drm/i915: drm_connector_property -> drm_object_property
v2: Rebased.

Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1)
[danvet: Pimp commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-21 22:12:26 +01:00
Paulo Zanoni
00c09d70df drm/i915: create the DDI encoder
Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it
inits the encoder and then calls the proper init_connector functions.
Notice that for non-eDP ports we call both HDMI and DP connector init,
so we have 2 connectors attached to each DDI encoder.

After this change, intel_hdmi_init and intel_dp_init are only called
by Ivy Bridge and earlier, while hardware containing DDI outputs
should call intel_ddi_init.

Also added/removed quite a few "static" keywords due to the fact that
some function pointers were moved from intel_dp.c and intel_hdmi.c to
intel_ddi.c.

DP finally works on Haswell now! \o/

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11 23:51:08 +01:00
Paulo Zanoni
bcbc889bc4 drm/i915: add intel_ddi_connector_get_hw_state
We need this since now on DDI we will have 2 connectors on each
encoder.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11 23:51:08 +01:00
Paulo Zanoni
174edf1f86 drm/i915: add port field to intel_digital_port
Both "intel_dp" and "intel_hdmi" structs had a "port" field, which
always had the same value. It makes more sense to move this to
intel_digital_port, so we can know the port independently of the
connector type.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11 23:51:07 +01:00
Paulo Zanoni
d63885da96 drm/i915: reset intel_encoder->type when DP or HDMI is detected
When intel_hdmi_detect detects a monitor, set intel_encoder->type with
INTEL_OUTPUT_HDMI. Same for DP.

This should not break the current code because these variables never
change. This will be used after we create the DDI encoder because it
will have both DP and HDMI connectors.

We won't support eDP+HDMI on the same port, so if an encoder is eDP we
should expect it to always remain eDP and never change.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11 23:51:07 +01:00
Paulo Zanoni
b9cb234cbd drm/i915: split intel_hdmi_init into encoder and connector pieces
We want to split the HDMI connector and encoder initialization because
in the future the DDI code will have its own "encoder init" function,
but it will still call intel_hdmi_init_connector. The DDI encoder will
actually have two connectors attached to it: HDMI and DP.

The best way to look at this patch is to imagine that we're renaming
intel_hdmi_init to intel_hdmi_init_connector and removing the
encoder-specific pieces and placing them into intel_hdmi_init.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11 23:51:06 +01:00
Paulo Zanoni
da63a9f2e4 drm/i915: create intel_digital_port and use it
The goal is to have one single encoder capable of controlling both DP
and HDMI outputs. This patch just adds the initial infrastructure, no
functional changes.

Previously, both intel_dp and intel_hdmi were intel_encoders. Now,
these 2 structs do not have intel_encoder as members anymore. The new
struct intel_digital_port has intel_encoder as a member, and it also
includes intel_dp and intel_hdmi as members. In other words: see the
changes inside intel_drv.h: it's the most important change, everything
else is only to make it compile and work.

For now, each intel_digital_port is still only able to control one of
HDMI or DP, but not both together.

In the future we should also try to merge the common fields from
intel_dp and intel_hdmi (e.g., port).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Add the missing ' ' spotted by Damien Lespiau.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11 23:51:06 +01:00
Paulo Zanoni
30add22d84 drm/i915: add intel_dp_to_dev and intel_hdmi_to_dev
When we add struct intel_digital_port, there will be no direct way of
going from intel_{dp,hdmi} to drm_device: we will need to call
container_of().

This patch adds functions to go from intel_{dp,hdmi} to drm_device.
The main goal here is to greatly reduce the size of the next patch,
where we will change the implementation of the functions we just
added here (among other things).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11 23:51:05 +01:00
Daniel Vetter
c2fb791692 Linux 3.7-rc2
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQEcBAABAgAGBQJQgvdwAAoJEHm+PkMAQRiG+3AH/i2XsqqN3VctL0nnbWfvds+Q
 aKulfIdJTjKiVAsawPUtRqReZ8ijiebrgA/53lZLlrFOoPPQ5+LHmnSyQF6gErOY
 NuAE1lijXDRM1pwBlhvOBbAj26wUobGjqONFJ9OkKr758Ue8ds/Q7UdxyEgmYgmg
 tvVMzfRcICzryUV3PcqL+3cNPpCUdT6wGGRJ9DCv/jvGiWKExWhOle5oltrmxk+D
 NsqRcws5pEubfHE4J8BvNWr8lE1kHfYVhrJETiLJUiN2XAJcbI4Jy7rU/3EGteNS
 0HMZdaPPjV874lohdM70X2225SbYrCVkAYB5hnZCTeC3tYyCawBBPMQoyAiOcmU=
 =+861
 -----END PGP SIGNATURE-----

Merge tag 'v3.7-rc2' into drm-intel-next-queued

Linux 3.7-rc2

Backmerge to solve two ugly conflicts:
- uapi. We've already added new ioctl definitions for -next. Do I need to say more?
- wc support gtt ptes. We've had to revert this for snb+ for 3.7 and
  also fix a few other things in the code. Now we know how to make it
  work on snb+, but to avoid losing the other fixes do the backmerge
  first before re-enabling wc gtt ptes on snb+.

And a few other minor things, among them git getting confused in
intel_dp.c and seemingly causing a conflict out of nothing ...

Conflicts:
	drivers/gpu/drm/i915/i915_reg.h
	drivers/gpu/drm/i915/intel_display.c
	drivers/gpu/drm/i915/intel_dp.c
	drivers/gpu/drm/i915/intel_modes.c
	include/drm/i915_drm.h

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 14:34:51 +02:00
Paulo Zanoni
6441ab5f8f drm/i915: completely rewrite the Haswell PLL handling code
Problems with the previous code:
  - HDMI just uses WRPLL1 for everything, so dual head cases might not
    work sometimes.
  - At encoder->mode_set we just write the PLL register without doing
    any kind of check (e.g., check if the PLL is already being used).
  - There is no way to fail and return error codes at
    encoder->mode_set.
  - We write to PORT_CLK_SEL at mode_set and we never disable it.
  - Machines hang due to wrong clock enable/disable sequence.

So here we rewrite the code, making it a little more like the
pre-Haswell PLL mode set code:
  - Check PLL availability at ironlake_crtc_mode_set.
  - Try to use both WRPLLs.
  - Check if PLLs are used before actually trying to use them, and
    properly fail with error messages.
  - Enable/disable PORT_CLK_SEL at the right place.
  - Add some WARNs to check for bugs.

The next improvement will be to try to reuse PLLs if the timings
match, but this is content for another patch and it's already
documented with a TODO comment.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-10 16:53:02 +02:00