Commit Graph

897 Commits

Author SHA1 Message Date
Paulo Zanoni
1f544388be drm/i915: fix checks inside haswell_crtc_{enable, disable}
These functions were forked from their Ironlake versions, so now fix
the gen checks to reflect the fact that they will only run on Haswell.

It is worth noticing that we are not considering IBX/CPT possible on
Haswell anymore. So far on Haswell enablement we kept trying to still
consider IBX/CPT as a possibility with a Haswell CPU, but this was
never tested, I really doubt it will work with the current code and we
don't really have plans to support it. Future patches will remove the
IBX/CPT code from other Haswell functions. Notice that we still have a
WARN on haswell_crtc_mode_set in case we detect non-LPT PCH.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26 10:24:44 +02:00
Paulo Zanoni
20474e90c9 drm/i915: fix checks inside ironlake_crtc_{enable, disable}
The last commit forked a Haswell version, so now we remove Haswell
code from these functions.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26 10:24:43 +02:00
Paulo Zanoni
4f771f1055 drm/i915: fork a Haswell version of ironlake_crtc_{enable, disable}
The way we enable and disable the PCH on Haswell changed considerably
since now we have only one PCH transcoder, so we can't keep the same
asserts and we also can't just unconditionally disable the PCH
transcoder for non-PCH outputs. So let's fork a Haswell version.

These new functions look exactly the same as the ironlake versions.
The next patches will introduce the differences.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26 10:24:43 +02:00
Daniel Vetter
d2acd215cd drm/i915/eDP: compute the panel power clock divisor from the pch rawclock
We need this when the bios forgets even to set that bit up. Most seem
to do that, even when they don't set up anything else in the panel
power sequencer.

Note that on IBX the rawclk is variable according to Bspec, but
everyone is using 125MHz. The rawclk is fixed to 125MHz on CPT, but
luckily we still have the same register available. On hsw, different
variants have different clocks, hence we need to check the register.

Since other pieces are driven by the rawclock, too, keep the little
helper in a central place.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-24 17:54:36 +02: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
1eb8dfec8d drm/i915: fix Haswell DP M/N registers
We have to write the correct values inside intel_dp_set_m_n and then
prevent these values from being overwritten later.

V2: Unconfuse double negation.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-18 21:22:32 +02:00
Daniel Vetter
2e9388923e drm/i915/crt: explicitly set up HOTPLUG_BITS on resume
... instead of relying on the register save/restore madness to do this.

To extract a bit of code call drm_mode_config_reset both on resume
and boot-up and move the hw state frobbing from the crt_init to the
->reset callback. The crt connector is the only one with a ->reset
callback, hence we can easily do this.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-18 14:30:06 +02:00
Paulo Zanoni
dae847991a drm/i915: add intel_ddi_set_pipe_settings
In theory, all the DDI pipe settings should be set here, including
timing and M/N registers. For now, let's just set the DP MSA
attributes.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: fixed up the unused typo in a #define, spotted by Jani
Nikula.]
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 22:01:54 +02:00
Dave Airlie
3459f62047 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Daniel writes:
"- some register magic to fix hsw crw (Paulo&Ben)
- fix backlight destruction for cpu edp (Jani)
- fix gen ch7xxx dvo ->get_hw_state
- fixup the plane->pipe fixup code, the broken version massively angers
  the modeset sanity checks
- kill pipe A quirk for i855gm, otherwise I get a black screen with the
  above patch
- fixup for gem_get_page helper (Chris)
- fixup guardband clipping w/a (Ken), without this mesa master can erronously
  drop vertices on snb, mesa 9.0 has the optimization reverted
- another pageflip vs. modeset fix
- kill bogus BUG_ON which broke ums+gem from Willy Tarreau (gasp, people
  are still using this!)"

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: fix non-DP-D eDP backlight cleanup and module reload
  drm/i915: HSW CRW stability magic
  drm/i915/dvo-ch7xxx: fix get_hw_state
  drm/i915: fixup the plane->pipe fixup code
  drm/i915: rip out the pipe A quirk for i855gm
  drm/i915: disable wc gtt pte mappings on gen2
  drm/i915: fixup i915_gem_object_get_page inline helper
  drm/i915: Disallow preallocation of requests
  drm/i915: Set guardband clipping workaround bit in the right register.
  drm/i915: paper over a pipe-enable vs pageflip race
  drm/i915: remove useless BUG_ON which caused a regression in 3.5.
2012-10-16 10:11:59 +10:00
Daniel Vetter
fa55583797 drm/i915: fixup the plane->pipe fixup code
We need to check whether the _other plane is on our pipe, not whether
our plane is on the other pipe. Otherwise if not both pipes/planes are
active, we won't properly clean up the mess and set up our desired
plane->pipe mapping.

v2: Fixup the logic, I've totally fumbled it. Noticed by Chris Wilson.

v3: I've checked Bspec, and the flexible plane->pipe mapping is a
gen2/3 feature, so test for that instead of PCH_SPLIT

v4: Check whether we indeed have 2 pipes before checking the other
pipe, to avoid upsetting i845g/i865g. Noticed by Chris Wilson.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51265
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838
Tested-by: Dave Airlie <airlied@gmail.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #855gm
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-12 10:59:11 +02:00
Daniel Vetter
ccd0d36e2a drm/i915: rip out the pipe A quirk for i855gm
This seems to be the root-cause that breaks resume on my i855gm when I
apply the "drm/i915: fixup the plane->pipe fixup code" patch. And that
code doesn't even run on my machine, so it's pure timing changes
causing the regression.

Furthermore resume has been constantly switching between working and
broken on this machine ever since kms support has been merged,
seemingly with no related change as a root cause. And always with the
same symptoms of the backlight lighting up, but the lvds panel only
displaying black.

Also, of both i855gm variants only one is in the table. And in the
past we've only ever removed entries from this quirk table because it
breaks things.

So let's just remove it - in case there's indeed a bios out there
relying on a running pipe A, we can add back in a more precise quirk
entry, like all the others (save for i830/i845).

Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #855gm
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-12 10:59:10 +02:00
Paulo Zanoni
1ce4292073 drm/i915: pipe and planes should be disabled on haswell_crtc_mode_set
So WARN in case they're not. It also does not make any sense to
wait_for_vblank at this point.

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-11 00:43:20 +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
Paulo Zanoni
ee2b0b382a drm/i915: add haswell_set_pipeconf
It's a copy of ironlake_set_pipeconf with 2 differences:
  - There is no BPC field to set.
  - The interlaced mask is now 2 bits instead of 3.

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:06:30 +02:00
Paulo Zanoni
5dc5298bb3 drm/i915: add proper CPU/PCH checks to crtc_mode_set functions
On ironlake_crtc_mode_set, WARN if not using IBX or CPT.

On haswell_crtc_mode_set, only run IBX/CPT code on IBX/CPT. I am still
not sure whether IBX/CPT will be possible with a Haswell CPU, so leave
the code there for now and put a WARN in case we spot it.

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 15:56:47 +02:00
Paulo Zanoni
09b4ddf95d drm/i915: add haswell_crtc_mode_set
It's just a copy of ironlake_crtc_mode_set.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-10 15:50:36 +02:00
Paulo Zanoni
fc914639b1 drm/i915: enable and disable PIPE_CLK_SEL at the right time
Previously we were enabling it at mode_set but never disabling. Let's
follow the mode set sequence.

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 15:48:16 +02:00
Paulo Zanoni
8d9ddbcbd0 drm/i915: enable and disable DDI_FUNC_CTL at the right time
And the right time is exactly after/before changing PIPE_CONF. See the
documentation about the mode set sequence.

This code is not inside any encoder-specific callback because
DDI_FUNC_CTL is part of the pipe, so it is used by all encoders.

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 15:47:59 +02:00
Paulo Zanoni
79f689aa6b drm/i915: rewrite the LCPLL code
Right now, we're trying to enable LCPLL at every mode set, but we're
never disabling it. Also, we really don't want to be disabling LCPLL
since it requires a very complex disable/enable sequence. This
register should really be set by the BIOS and we shouldn't be touching
it. Still, let's try to check its value and print some errors in case
we find something wrong. We're also adding intel_ddi_get_cdclk_freq
which will be used later in other places.

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 15:47:39 +02:00
Daniel Vetter
6ce9410047 drm/i915: paper over a pipe-enable vs pageflip race
I've discovered this on my ivb machine while stress-testing the new
flip_tests. Only harmful effect observed is that the timestamp is a
bit bogus.

Note that this is empirical duct-tape: I've noticed that we seem to
only ever miss the very first vblank irq right after enabling the
pipe. And with this hack applied I couldn't reproduce the failure case
anywhere else any more.

Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-08 19:31:04 +02:00
Dave Airlie
1f31c69dac Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:

Bigger -fixes pile, mostly because I've included Ajax' DP dongle stuff,
as discussed on irc. Otherwise just small things:
- regression fix to finally make 6bpc auto-dither on dp work (Jani)
- reinstate an snb ctx w/a that accidentally got lost in a rework (Chris)
- fixup the DP train sequence, logic-goof-up uncovered by Coverty (Chris)
- fix set_caching locking (Ben)
- fix spurious segfault on con-current gtt mmap faulting (Dimitry and Mika)
- some pageflip correctness fixes (still hunting down some issues, but
  these are the worst offenders of confused code that we've tracked down
  thus far) from Chris and me
- fixup swizzling settings on vlv (Jesse)
- gt_mode w/a from Ben added, fixes snb gt1 rc6+hw ctx hangs.

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Fix GT_MODE default value
  drm/i915: don't frob the vblank ts in finish_page_flip
  drm/i915: call drm_handle_vblank before finish_page_flip
  drm/i915: print warning if vmi915_gem_fault error is not handled
  drm/i915: EBUSY status handling added to i915_gem_fault().
  drm/i915: Try harder to complete DP training pattern 1
  drm/i915: set swizzling to none on VLV
  drm/dp: Make sink count DP 1.2 aware
  drm/dp: Document DP spec versions for various DPCD registers
  drm/i915/dp: Be smarter about connection sense for branch devices
  drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
  drm/dp: Update DPCD defines
  drm: Export drm_probe_ddc()
  drm/i915: Flush the pending flips on the CRTC before modification
  drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a
  drm/i915: Fix set_caching locking
  drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
2012-10-07 21:13:54 +10:00
Daniel Vetter
95cb1b02b0 drm/i915: don't frob the vblank ts in finish_page_flip
Now that we correctly generate it, this hack is no longer required (and
might actually paper over a serious bug).

pageflip timestamps are sanity check in the latest version of the flip-test
in intel-gpu-tools.

v2: Also remove the gettimeofday(&now) which is no longer used.
Noticed by Mario Kleiner.

Reviewed-by: mario.kleiner@tuebingen.mpg.de
Tested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-04 10:33:43 +02:00
Linus Torvalds
612a9aab56 Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
Pull drm merge (part 1) from Dave Airlie:
 "So first of all my tree and uapi stuff has a conflict mess, its my
  fault as the nouveau stuff didn't hit -next as were trying to rebase
  regressions out of it before we merged.

  Highlights:
   - SH mobile modesetting driver and associated helpers
   - some DRM core documentation
   - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write
     combined pte writing, ilk rc6 support,
   - nouveau: major driver rework into a hw core driver, makes features
     like SLI a lot saner to implement,
   - psb: add eDP/DP support for Cedarview
   - radeon: 2 layer page tables, async VM pte updates, better PLL
     selection for > 2 screens, better ACPI interactions

  The rest is general grab bag of fixes.

  So why part 1? well I have the exynos pull req which came in a bit
  late but was waiting for me to do something they shouldn't have and it
  looks fairly safe, and David Howells has some more header cleanups
  he'd like me to pull, that seem like a good idea, but I'd like to get
  this merge out of the way so -next dosen't get blocked."

Tons of conflicts mostly due to silly include line changes, but mostly
mindless.  A few other small semantic conflicts too, noted from Dave's
pre-merged branch.

* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits)
  drm/nv98/crypt: fix fuc build with latest envyas
  drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering
  drm/nv41/vm: fix and enable use of "real" pciegart
  drm/nv44/vm: fix and enable use of "real" pciegart
  drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie
  drm/nouveau: store supported dma mask in vmmgr
  drm/nvc0/ibus: initial implementation of subdev
  drm/nouveau/therm: add support for fan-control modes
  drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules
  drm/nouveau/therm: calculate the pwm divisor on nv50+
  drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster
  drm/nouveau/therm: move thermal-related functions to the therm subdev
  drm/nouveau/bios: parse the pwm divisor from the perf table
  drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices
  drm/nouveau/therm: rework thermal table parsing
  drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table
  drm/nouveau: fix pm initialization order
  drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it
  drm/nouveau: log channel debug/error messages from client object rather than drm client
  drm/nouveau: have drm debugging macros build on top of core macros
  ...
2012-10-03 23:29:23 -07:00
David Howells
760285e7e7 UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/
Convert #include "..." to #include <path/...> in drivers/gpu/.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
2012-10-02 18:01:07 +01:00
Paulo Zanoni
b0e77b9c6b drm/i915: extract intel_set_pipe_timings from crtc_mode_set
Version 2: call intel_set_pipe_timings from both i9xx_crtc_mode_set
and ironlake_crtc_mode_set, instead of just ironlake, as requested by
Daniel Vetter.

The problem caused by calling this function from i9xx_crtc_mode_set
too is that now on i9xx we write to PIPESRC before writing to DSPSIZE
and DSPPOS. I could not find any evidence in our documentation that
this won't work, and the docs actually say the pipe registers should
be set before the plane registers.

Version 3: don't remove pipeconf bits on i9xx_crtc_mode_set.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-02 13:24:37 +02:00
Chris Wilson
5bb61643f6 drm/i915: Flush the pending flips on the CRTC before modification
This was meant to be the purpose of the
intel_crtc_wait_for_pending_flips() function which is called whilst
preparing the CRTC for a modeset or before disabling. However, as Ville
Syrjala pointed out, we set the pending flip notification on the old
framebuffer that is no longer attached to the CRTC by the time we come
to flush the pending operations. Instead, we can simply wait on the
pending unpin work to be finished on this CRTC, knowning that the
hardware has therefore finished modifying the registers, before proceeding
with our direct access.

Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply
schedule the flip immediately when the pipe is disabled, leading
to other funny issues.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[danvet: Added i-g-t note and cc: stable]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-02 11:50:26 +02:00
Vijay Purushothaman
17dc92574b drm/i915: Fixup HDMI output on Valleyview
Fixed correct min, max vco limits and dip ctl reg

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>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-28 17:05:08 +02:00
Gajanan Bhat
19c03924d4 drm/i915: Add eDP support for Valleyview
Eventhough Valleyview display block is derived from Cantiga, VLV
supports eDP. So, added eDP checks in i9xx_crtc_mode_set path.

v2: use different DPIO_DIVISOR values for VGA, DP and eDP
v3: fix DPIO value calculation to use same values for all display
interfaces
v4: removed unconditional enabling of 6bpc dithering based on comments
from Daniel & Jani Nikula. Also changed the display enabling order to
force eDP detection first.

Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-28 17:04:38 +02:00
Vijay Purushothaman
2a8f64ca23 drm/i915: Enable DisplayPort in Valleyview
In valleyview voltageswing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric.

Cleaned up DPLL calculations for Valleyview to support multi display
configurations.

v2: Based on Daniel's feedbacak, moved crt hotplug detect work around as separate
patch. Also moved i9xx_update_pll_dividers to i8xx_update_pll and
i9xx_update_pll.

Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: drop spurious whitespace changes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-28 17:02:08 +02:00
Vijay Purushothaman
74a4dd2e45 drm/i915: Program correct m n tu register for Valleyview
m n tu register offset has changed in Valleyview. Also fixed DP limit
frequencies.

Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-28 16:49:53 +02:00
Jani Nikula
0c96c65b48 drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
The dithering introduced in

commit 3b5c78a35c
Author: Adam Jackson <ajax@redhat.com>
Date:   Tue Dec 13 15:41:00 2011 -0800

    drm/i915/dp: Dither down to 6bpc if it makes the mode fit

stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
the original mode, without the flag, so it would never have any
effect. However, the BPC was clamped by VBT settings, making things work by
coincidence, until that part was removed in

commit 4344b813f1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Aug 10 11:10:20 2012 +0200

Use adjusted_mode instead of mode when checking for
INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.

v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
Daniel both before and after sending the first patch.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621
CC: Adam Jackson <ajax@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-27 08:42:10 +02:00
Paulo Zanoni
e2f12b070d drm/i915: remove unused variables from ironlake_crtc_mode_set
The last patches moved a lot of code from ironlake_crtc_mode_set to
sub-functions, so these variables became useless. You could get
warnings by enabling -Wunused-but-set-variable.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-25 10:44:06 +02:00
Paulo Zanoni
de13a2e3f8 drm/i915: extract compute_dpll from ironlake_crtc_mode_set
Too many lines just to compute the value of a single variable, so
move this to its own function.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-25 10:40:04 +02:00
Paulo Zanoni
f48d8f235a drm/i915: extract set_m_n from ironlake_crtc_mode_set
The set_m_n code was spread all over the mode_set function.

Version 2:
Don't set the DP M/N registers on ironlake_set_m_n. Daniel Vetter has
plans to add some encoder-specific callbacks. Also, on this version we
don't change the order we're writing the registers, making the code
change safer.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-25 10:37:34 +02:00
Paulo Zanoni
cc769b6257 drm/i915: don't recheck for invalid pipe bpp
As noticed by Daniel Vetter, intel_pipe_choose_bpp_dither should
already check for invalid bpp values and set a valid value, so remove
the recheck inside ironlake_crtc_mode_set and also replace a "default"
switch case inside ironlake_set_pipeconf with a BUG().

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-25 10:36:10 +02:00
Daniel Vetter
398b7a1b88 Linux 3.6-rc7
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (GNU/Linux)
 
 iQEcBAABAgAGBQJQX7MuAAoJEHm+PkMAQRiG0h0IAJURkrMCAQUxA+Ik66ReH89s
 LQcVd0U9uL4UUOi7f5WR64Vf9Cfu6VVGX9ZKSvjpNskvlQaUQPMIt4pMe6g4X4dI
 u0bApEy4XZz3nGabUAghIU8jJ8cDmhCG6kPpSiS7pi7KHc0yIa4WFtJRrIpGaIWT
 xuK38YOiOHcSDRlLyWZzainMncQp/ixJdxnqVMTonkVLk0q0b84XzOr4/qlLE5lU
 i+TsK3PRKdQXgvZ4CebL+srPBwWX1dmgP3VkeBloQbSSenSeELICbFWavn2ml+sF
 GXi4dO93oNquL/Oy5SwI666T4uNcrRPaS+5X+xSZgBW/y2aQVJVJuNZg6ZP/uWk=
 =0v2l
 -----END PGP SIGNATURE-----

Merge tag 'v3.6-rc7' into drm-intel-next-queued

Manual backmerge of -rc7 to resolve a silent conflict leading to
compile failure in drivers/gpu/drm/i915/intel_hdmi.c.

This is due to the bugfix in -rc7:

commit b98b601672
Author: Wang Xingchao <xingchao.wang@intel.com>
Date:   Thu Sep 13 07:43:22 2012 +0800

    drm/i915: HDMI - Clear Audio Enable bit for Hot Plug

Since this code moved around a lot in -next git put that snippet at
the wrong spot. I've tried to fix this by making the conflict explicit
by merging a version for next with:

commit 3cce574f01
Author: Wang Xingchao <xingchao.wang@intel.com>
Date:   Thu Sep 13 11:19:00 2012 +0800

    drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally

But that failed to solve the entire problem. To avoid pushing out
further -nightly branch to our QA where this is broken, do the
backmerge and manually add the stuff git adds to -next from the patch
in -fixes.

Note that this doesn't show up in git's merge diff (and hence is also
not handled by git rerere), which adds to the reasons why I'd like to
fix this with a verbose backmerge. The git merge diff only shows a
bunch of trivial conflicts of the "code changed in lines next to each
another" kind.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-24 18:17:12 +02:00
Daniel Vetter
68d3472047 drm/i915: update dpms property in set_mode
Hopefully this makes userspace slightly less confused about us
frobbing the dpms state behind its back. Yeah, it would be better
to be more careful with not changing the dpms state, but that is
quite more invasive.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:09 +02:00
Daniel Vetter
172a1ae141 drm/i915: don't call dpms funcs after set_mode
... because our current set_mode implementation doesn't bother to adjust
for the dpms state, we just forcefully update it. So stop pretending that
we're better than we are and rip out this extranous call.

Note that this totally confuses userspace, because the exposed connector
property isn't actually updated ...

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:09 +02:00
Daniel Vetter
46b6f8149a drm/i915: don't disable fdi links harder in ilk_crtc_enable
Because they should have been disabled when shutting down the display
pipe previously. To ensure that this is the case, add a few assserts
instead of unconditionally disabling the fdi link.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:08 +02:00
Daniel Vetter
a14d335920 drm/i915: rip out intel_disable_pch_ports
Even with the old crtc helper code we should have disabled all
encoders on that pipe by now, and with the new code this would
definitely paper over a bug. We already have the necessary checks
in place in intel_disable_transcoder, so if we accidentally leave
a pch port on, this will be caught.

Hence just rip this all out.

Note that up to the patch in this giant modeset series that removes
the LVDS special case to avoid disabling LVDS in the encoder->prepare
callback ("drm/i915/lvds: ditch ->prepare special case"), this was not
the case for all outputs.

Also note that in

commit 1b3c7a47f9
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Wed Nov 25 13:09:38 2009 +0800

    drm/i915: Fix LVDS stability issue on Ironlake

this was already discovered independently and worked around. How I
bloody hate this entire mess of cludges piled on top of other cludges.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:08 +02:00
Daniel Vetter
bf49ec8c52 drm/i915: add encoder->pre_enable/post_disable
The cpu eDP encoder has some horrible hacks to set up the DP pll at
the right time. To be able to move them to the right place, add some
more encoder callbacks so that this can happen at the right time.

LVDS has some similar funky hacks, but that would require more work
(we need to move around the pll setup a bit). Hence for now only
wire these new callbacks up for ilk+ - we only have cpu eDP on these
platforms.

v2: Bikeshed the vtable ordering, requested by Chris Wilson.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:02 +02:00
Paulo Zanoni
6591c6e4d7 drm/i915: extract compute_clocks from ironlake_crtc_mode_set
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: resolved conflicts due to missing some earlier patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:59 +02:00
Paulo Zanoni
a1f9e77e1f drm/i915: simplify setting DSPCNTR inside ironlake_crtc_mode_set
Because declaring a variable in the beginning of the function, then
initializing it 100 lines later, then using it 100 lines later does
not make our code look good IMHO.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:58 +02:00
Paulo Zanoni
c8203565b0 drm/i915: extract ironlake_set_pipeconf form ironlake_crtc_mode_set
Because ironlake_crtc_mode_set is a giant function that used to have
404 lines. Let's try to make it less complex/confusing.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:58 +02:00
Daniel Vetter
6c4c86f51c drm/i915: correctly update crtc->x/y in set_base
While reworking the modeset sequence, this got lost in

commit 25c5b2665f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 8 22:08:04 2012 +0200

    drm/i915: implement new set_mode code flow

I've noticed this because some Xorg versions seem to set up a new mode
with every crtc at (0,0) and then pan to the right multi-monitor
setup. And since some hacks of mine added more calls to mode_set using
the stored crtc->x/y my multi-screen setup blew up.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-18 00:52:43 +02:00
Daniel Vetter
5b5896e4e1 drm/i915: enable lvds pin pairs before dpll on gen2
Otherwise things migt not work too well.

Breakage introduced in

commit eb1cbe4848
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 28 23:12:16 2012 +0200

    drm/i915: split PLL update code out of i9xx_crtc_mode_set

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org (for 3.5 only)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-17 10:04:39 +02:00
Daniel Vetter
75c5da279e drm/i915: fix up the IBX transcoder B check
This has been added in

commit de9a35abb3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jun 5 11:03:40 2012 +0200

    drm/i915: assert that the IBX port transcoder select w/a is implemented

Unfortunately I've failed to notice that these checks are not just
called for the port that is about to be disabled, but for all (which
makes sense for an assert ...), and the WARN missfired when disabling
another pipe than the one with the dp port.

Hence also check whether the port is actually disabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54688
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-11 17:25:14 +02:00
Daniel Vetter
a1ceb67751 Merge the modeset-rework, basic conversion into drm-intel-next
As a quick reference I'll detail the motivation and design of the new code a
bit here (mostly stitched together from patchbomb announcements and commits
introducing the new concepts).

The crtc helper code has the fundamental assumption that encoders and crtcs can
be enabled/disabled in any order, as long as we take care of depencies (which
means that enabled encoders need an enabled crtc to feed them data,
essentially).

Our hw works differently. We already have tons of ugly cases where crtc code
enables encoder hw (or encoder->mode_set enables stuff that should only be
enabled in enocder->commit) to work around these issues. But on the disable
side we can't pull off similar tricks - there we actually need to rework the
modeset sequence that controls all this. And this is also the real motivation
why I've finally undertaken this rewrite: eDP on my shiny new Ivybridge
Ultrabook is broken, and it's broken due to the wrong disable sequence ...

The new code introduces a few interfaces and concepts:

- Add new encoder->enable/disable functions which are directly called from the
crtc->enable/disable function. This ensures that the encoder's can be
enabled/disabled at a very specific in the modeset sequence, controlled by our
platform specific code (instead of the crtc helper code calling them at a time
it deems convenient).

- Rework the dpms code - our code has mostly 1:1 connector:encoder mappings and
does support cloning on only a few encoders, so we can simplify things quite a
bit.

- Also only ever disable/enable the entire output pipeline. This ensures that
we obey the right sequence of enabling/disabling things, trying to be clever
here mostly just complicates the code and results in bugs. For cloneable
encoders this requires a bit of special handling to ensure that outputs can
still be disabled individually, but it simplifies the common case.

- Add infrastructure to read out the current hw state. No amount of careful
ordering will help us if we brick the hw on the initial modeset setup. Which
could happen if we just randomly disable things, oblivious to the state set up
by the bios. Hence we need to be able to read that out. As a benefit, we grow a
few generic functions useful to cross-check our modeset code with actual hw
state.

With all this in place, we can copy&paste the crtc helper code into the
drm/i915 driver and start to rework it:

- As detailed above, the new code only disables/enables an entire output pipe.
As a preparation for global mode-changes (e.g. reassigning shared resources) it
keeps track of which pipes need to be touched by a set of bitmasks.

- To ensure that we correctly disable the current display pipes, we need to
know the currently active connector/encoder/crtc linking. The old crtc helper
simply overwrote these links with the new setup, the new code stages the new
links in ->new_* pointers. Those get commited to the real linking pointers once
the old output configuration has been torn down, before the ->mode_set
callbacks are called.

- Finally the code adds tons of self-consistency checks by employing the new hw
state readout functions to cross-check the actual hw state with what the
datastructure think it should be. These checks are done both after every
modeset and after the hw state has been read out and sanitized at boot/resume
time. All these checks greatly helped in tracking down regressions and bugs in
the new code.

With this new basis, a lot of cleanups and improvements to the code are now
possible (besides the DP fixes that ultimately made me write this), but not yet
done:

- I think we should create struct intel_mode and use it as the adjusted mode
everywhere to store little pieces like needs_tvclock, pipe dithering values or
dp link parameters. That would still be a layering violation, but at least we
wouldn't need to recompute these kinds of things in intel_display.c. Especially
the port bpc computation needed for selecting the pipe bpc and dithering
settings in intel_display.c is rather gross.

- In a related rework we could implement ->mode_valid in terms of ->mode_fixup
in a generic way - I've hunted down too many bugs where ->mode_valid did the
right thing, but ->mode_fixup didn't. Or vice versa, resulting in funny bugs
for user-supplied modes.

- Ditch the idea to rework the hdp handling in the common crtc helper code and
just move things to i915.ko. Which would rid us of the ->detect crtc helper
dependencies.

- LVDS wire pair and pll enabling is all done in the crtc->mode_set function
currently. We should be able to move this to the crtc_enable callbacks (or in
the case of the LVDS wire pair enabling, into some encoder callback).

Last, but not least, this new code should also help in enabling a few neat
features: The hw state readout code prepares (but there are still big pieces
missing) for fastboot, i.e. avoiding the inital modeset at boot-up and just
taking over the configuration left behind by the bios. We also should be able
to extend the configuration checks in the beginning of the modeset sequence and
make better decisions about shared resources (which is the entire point behind
the atomic/global modeset ioctl).

Tested-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Damien Lespiau <damien.lespiau@intel.com>
Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Acked-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 22:52:43 +02:00
Daniel Vetter
b980514c9a drm/i915: improve modeset state checking after dpms calls
Now that we have solid modeset state tracking and checking code in
place, we can do the Full Monty also after dpms calls.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:31 +02:00
Daniel Vetter
8af6cf88a5 drm/i915: add tons of modeset state checks
... let's see whether this catches anything earlier and I can track
down a few bugs.

v2: Add more checks and also add DRM_DEBUG_KMS output so that it's
clear which connector/encoder/crtc is being checked atm. Which proved
rather useful for debugging ...

v3: Add a WARN in the common encoder dpms function, now that also
modeset changes properly update the dpms state ...

v4: Properly add a short explanation for each WARN, to avoid the need
to correlate dmesg lines with source lines accurately. Suggested by
Chris Wilson.

v5: Also dump (expected, found) for state checks (or wherever it's not
apparent from the test what exactly mismatches with expectations).
Again suggested by Chris Wilson.

v6: Due to an issue reported by Paulo Zanoni I've noticed that the
encoder checking is by far not as strict as it could and should be.
Improve this.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:30 +02:00