Commit Graph

3496 Commits

Author SHA1 Message Date
Paulo Zanoni
82a4d9c0a8 drm/i915: turn the eDP DDI panel on/off
It's an important step :)

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-10-26 10:24:51 +02:00
Paulo Zanoni
d6c50ff8ca drm/i915: set/unset the DDI eDP backlight
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-10-26 10:24:51 +02:00
Paulo Zanoni
b8fc2f6a18 drm/i915: set the correct eDP aux channel clock divider on DDI
The cdclk frequency is not always the same, so the value here should
be adjusted to match it.

Version 2: call intel_ddi_get_cdclk_freq instead of reading
CDCLK_FREQ, because the register is just for earlier HW steppings.

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-10-26 10:24:50 +02:00
Paulo Zanoni
e6f0bfc4fb drm/i915: select the correct pipe when using TRANSCODER_EDP
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-10-26 10:24:50 +02:00
Paulo Zanoni
b5e508d4c0 drm/i915: implement workaround for VTOTAL when using TRANSCODER_EDP
See the documentation for the DDI_FUNC_CTL register, EDP Input Select
bits: when the EDP input selection is B, the VTOTAL_B must be
programmed with the VTOTAL_EDP value, same thing for selection C.

V2: Use I915_READ as suggested by Daniel Vetter.

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-10-26 10:24:49 +02:00
Paulo Zanoni
fe2b8f9dfb drm/i915: convert pipe timing definitions to transcoder
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-26 10:24:49 +02:00
Paulo Zanoni
afe2fcf5e0 drm/i915: convert CPU M/N timings to transcoder
Same thing as the previous commits. Not renaming this one since it
exists since way before Haswell.

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-26 10:24:48 +02:00
Paulo Zanoni
c9809791ae drm/i915: convert PIPE_MSA_MISC to transcoder
Same as the other registers. This one also appeared on Haswell for the
first time, so that's why we are renaming 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-26 10:24:48 +02:00
Paulo Zanoni
702e7a56af drm/i915: convert PIPECONF to use transcoder instead of pipe
Because the PIPECONF register is actually part of the CPU transcoder,
not the CPU pipe.

Ideally we would also rename PIPECONF to TRANSCONF to remind people
that they should use the transcoder instead of the pipe, but let's
keep it like this for now since most Gens still name it PIPECONF.

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-26 10:24:47 +02:00
Paulo Zanoni
e28d54cbf9 drm/i915: check TRANSCODER_EDP on intel_modeset_setup_hw_state
We need to check if any of the pipes is using TRANSCODER_EDP.

V2: DDI_BUF_CTL was renamed, so fix the usage here.

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-26 10:24:47 +02:00
Paulo Zanoni
ad80a810ec drm/i915: convert DDI_FUNC_CTL to transcoder
Because there's one instance of the register per CPU transcoder and
not per CPU pipe. This is another register that appeared for the first
time on Haswell, and even though its Haswell name is
PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's
just use the new naming scheme before it confuses more people.

Notice that there's a big improvement on intel_ddi_get_hw_state due to
the new TRANSCODER_EDP.

V2: Also rename the register to TRANS_DDI_FUNC_CTL as suggested by
Damien Lespiau.

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-26 10:24:46 +02:00
Paulo Zanoni
bb523fc08d drm/i915: convert PIPE_CLK_SEL to transcoder
This register appeared in Haswell. It does not have an EDP version
because the EDP transcoder is always tied to the DDIA clock. Notice
that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder
is TRANSCODER_EDP we might introduce a bug, that's why this is a
transcoder register even though it does not have an EDP version.

Even though Haswell names this register PIPE_CLK_SEL, it will be
renamed to TRANS_CLK_SEL in the future, so let's just start using the
real name that makes more sense and avoids misusage.

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-26 10:24:46 +02:00
Paulo Zanoni
a5c961d1f3 drm/i915: add TRANSCODER_EDP
Before Haswell we used to have the CPU pipes and the PCH transcoders.
We had the same amount of pipes and transcoders, and there was a 1:1
mapping between them. After Haswell what we used to call CPU pipe was
split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A,
B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder
(only used for VGA).

For all the outputs except for EDP we have an 1:1 mapping on the CPU
pipes and CPU transcoders, so if you're using CPU pipe A you have to
use CPU transcoder A. When have an eDP output you have to use
transcoder EDP and you can attach this CPU transcoder to any of the 3
CPU pipes. When using VGA you need to select a pair of matching CPU
pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the
PCH transcoder.

For now we're just creating the cpu_transcoder definitions and setting
cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the
registers was ported to use transcoder instead of pipe. The goal is to
keep the code backwards-compatible since on all cases except when
using eDP we must have pipe == cpu_transcoder.

V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau
and Daniel Vetter.

We currently need the haswell_crtc_off chunk because TRANSCODER_EDP
can be used by any CRTC, so when you stop using it you have to stop
saying you're using it, otherwise you may have at some point 2 CRTCs
claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled
one), then the HW state readout code will get completely confused.

In other words:

Imagine the following case:
  xrandr --output eDP1 --auto --crtc 0
  xrandr --output eDP1 --off
  xrandr --output eDP1 --auto --crtc 2

After the last command you could get a "pipe A assertion failure
(expected off, current on)" because CRTC 0 still claims it's using
TRANSCODER_EDP, so the HW state readout function will read it
(through PIPECONF) and expect it to be off, when it's actually on
because it's being used by CRTC 2.

So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we
make sure we're pointing to our own original CRTC which is certainly
not used by any other CRTC.

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-26 10:24:45 +02:00
Paulo Zanoni
8361663420 drm/i915: don't call Haswell PCH code when we can't or don't need
On Ironlake we have one PCH transcoder and FDI per pipe, so we know
that if ironlake_crtc_driving_pch returns false we can disable the PCH
transcoder and we also know that when we disable the crtc we can also
disable the PCH transcoder.

On Haswell there is only 1 PCH transcoder and FDI and they can be used
by any CRTC. So if for one specific crtc haswell_crtc_driving_pch
returns false we can't assert anything about the state of the PCH
transcoder or the FDI link without checking if any other CRTC is using
the PCH.

So on this commit remove the "assert_fdi_{t,r}x_disabled" form
haswell_crtc_enable and also only disable FDI and the PCH transcoder
if the port being disabled was actually a PCH port (we only have one
port using PCH: the VGA port).

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:45 +02:00
Paulo Zanoni
fc316cbe46 drm/i915: simplify intel_crtc_driving_pch
By forking Ironlake and Haswell functions. The only callers are
{ironlake,haswell}_crtc_enable anyway, and this way we won't need to
add other checks on the Haswell version for the next gens.

V2: Even simpler, as pointed by Jani Nikula.

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
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
Jani Nikula
051f86639c drm/i915: remove an extra #define for DP_RECEIVER_CAP_SIZE
Identical #define is now available in include/drm/drm_dp_helper.h, nuke the
dupe.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26 10:24:42 +02:00
Daniel Vetter
67a5456655 drm/i915: extract intel_dp_init_panel_power_sequencer
That thing has grown way too big already.

Also move around a comment to the right spot.

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:37 +02:00
Daniel Vetter
6b3ec1c9fb drm/i915/dp: compute the pch dp aux divider from the rawclk
Otherwise dp aux won't work on some hsw platforms, since they use a
different rawclk than the 125MHz clock used thus far.

To absolutely not change anything, round up: That way we get the old
63 divider for the default 125MHz clock.

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
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
035aa3dec8 drm/i915: enable/disable backlight for eDP
Like we already do for the LVDS panels. This seems to help greatly
in setting up the backlight, since the BIOS might refuse to cooperate.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

v2: Move the backlight_off call from panel_off to edp_backlight_off,
noticed by Paulo Zanoni.

Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-24 17:54:16 +02:00
Daniel Vetter
b6e0e543f7 drm/i915: clear the entire sdvo infoframe buffer
Like in the case of native hdmi, which is fixed already in

commit adf00b26d1
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Sep 25 13:23:34 2012 -0300

    drm/i915: make sure we write all the DIP data bytes

we need to clear the entire sdvo buffer to avoid upsetting the
display.

Since infoframe buffer writing is now a bit more elaborate, extract it
into it's own function. This will be useful if we ever get around to
properly update the ELD for sdvo. Also #define proper names for the
two buffer indexes with fixed usage.

v2: Cite the right commit above, spotted by Paulo Zanoni.

v3: I'm too stupid to paste the right commit.

v4: Ben Hutchings noticed that I've failed to handle an underflow in
my loop logic, breaking it for i >= length + 8. Since I've just lost C
programmer license, use his solution. Also, make the frustrated 0-base
buffer size a notch more clear.

Reported-and-tested-by: Jürg Billeter <j@bitron.ch>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Cc: stable@vger.kernel.org
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-24 15:12:48 +02:00
Daniel Vetter
82ed61fa1a drm/i915: make edp panel power sequence setup more robust
3 changes:
- If a given value is unset, use the maximal limits from the eDP spec.
- Write back the new values, since otherwise the panel power sequencing
  hw will not dtrt.
- Revert the early bail-out in case the register values are unset.

The last change reverts

commit bfa3384a9a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Apr 10 11:58:04 2012 -0700

    drm/i915: check PPS regs for sanity when using eDP

v2:
- Unlock the PP regs as the very first thing. This is a required w/a
  for cpu eDP on port A, and generally a good idea.
- Fixup the panel power control port selection bits.

v3: Paulo Zanoni noticed that I've fumbled the computation of the spec
limit values. Fix them up. We've also noticed that the t8/t9 values in
the vbt/bios-programmed pp are much larger than any limits. My guess
is that this is to conceal any backlight enable/disable delays. So by
using the much shorter limits from the spec, which only concerns the
sink, we risk that we might display before the backlight is fully on,
or disable the output while the backlight still has afterglow. I've
figured I don't care too much, since this will only happen when both
the pp regs are not programmed, and the vbt tables don't contain
anything useful.

v4: Don't set the port selection bits on hsw/LPT, they don't exist any
more.

v5: Fixup spelling issues in comments, as noticed by Jesse Barnes.

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-23 19:36:42 +02:00
Damien Lespiau
2d354c3472 drm/i915: Don't try to use SPR_SCALE when we don't have a sprite scaler
Haswell does not have a scaler in the sprite pipeline anymore, so let's
ensure:
  1/ We bail out of update_plate() when someone is trying to ask to
     display a scaled framebuffer,
  2/ We never write to the nonexistent SPR_SCALE register

v2: Smash in the fixup from Damien in the disable_plane function.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (for v1)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (for v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-23 19:35:18 +02:00
Daniel Vetter
9324cf7fef drm/i915/dp: actually nack test request
... like the comment says. No idea whether this has any effect, but
I guess it's better to not lie to the display by acking a test request
and never following through with it. This goes back to the commit that
originally introduced this code:

commit a60f0e38d7
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Oct 20 15:09:17 2011 -0700

    drm/i915: add DP test request handling

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Meh'ed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-23 16:39:33 +02:00
Daniel Vetter
7f6658ef35 drm/i915: VGA needs to be on pipe A on i830M
The bit doesn't stick, and the output is always cloned from pipe A,
even when it's supposed to scan out from pipe B.

Shuts up annoying warnings from the modeset-rework, too.

I've noticed that with this patch we know get and unknown connection
state since the code can't find a suitable pipe for load detection.
But that beats the previous state of affairs, where it tried to use
pipe B, actually used pipe A and concluded that something is connected
(although it's the LVDS on pipe A and nothing on the VGA connector on
pipe B).

I've tried to make load detect work by remapping the pipe->planes
stuff, so that crtc 0 will use pipe B and hence we still have
something left for load-detect on pipe A. But alas, that upset the hw
a bit.

So there's still some things to figure out, but this here will at
least paper over some of the problems.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51265
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: extend the commit message a bit with recent observations.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-23 13:03:01 +02:00
Daniel Vetter
a9193983f4 drm/i915: fix overlay on i830M
The overlay on the i830M has a peculiar failure mode: It works the
first time around after boot-up, but consistenly hangs the second time
it's used.

Chris Wilson has dug out a nice errata:

"1.5.12 Clock Gating Disable for Display Register
Address Offset:	06200h–06203h

"Bit 3
Ovrunit Clock Gating Disable.
0 = Clock gating controlled by unit enabling logic
1 = Disable clock gating function
DevALM Errata ALM049: Overlay Clock Gating Must be Disabled:  Overlay
& L2 Cache clock gating must be disabled in order to prevent device
hangs when turning off overlay.SW must turn off Ovrunit clock gating
(6200h) and L2 Cache clock gating (C8h)."

Now I've nowhere found that 0xc8 register and hence couldn't apply the
l2 cache workaround. But I've remembered that part of the magic that
the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache
allocations so that the overlay scaler has some scratch space.

And while pondering how that could explain the hang the 2nd time we
enable the overlay, I've remembered that the old ums overlay code did
_not_ issue the OVERLAY_OFF cmd.

And indeed, disabling the OFF cmd results in the overlay working
flawlessly, so I guess we can workaround the lack of the above
workaround by simply never disabling the overlay engine once it's
enabled.

Note that we have the first part of the above w/a already implemented
in i830_init_clock_gating - leave that as-is to avoid surprises.

v2: Add a comment in the code.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827
Cc: stable@vger.kernel.org
Tested-by: Rhys <rhyspuk@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-23 12:57:50 +02:00
Daniel Vetter
397fe15715 drm: extract drm_dp_max_lane_count helper
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 22:56:43 +02:00
Daniel Vetter
3b5c662e8f drm: extract dp link bw helpers
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 22:34:47 +02:00
Daniel Vetter
a7c9655fdd drm/i915: use the new dp train delay helpers
Only really required for dp 1.2. I've hoped this would help with some
link training woes I'm fighting, but alas those are only dp 1.1
devices.

Also move a comment that went misplaced in the recent refactorings to
the right spot again.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 22:34:46 +02:00
Daniel Vetter
1a644cd47c drm: extract dp link train delay functions from radeon
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.

Hence extend the various dpcd arrays in the radeon driver, use
proper symbolic constants where applicable (one place overallocated
the dpcd array to 25 bytes). Then also drop the rd_interval cache -
radeon_dp_link_train_init re-reads the dpcd block, so the values we'll
consume in train_cr and train_ce will always be fresh.

To avoid needless diff-churn, #define the old size of dpcd as the new
one and keep it around.

v2: Alex Deucher noticed one place where I've forgotten to replace 8
with DP_RECEIVER_CAP_SIZE.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 22:34:46 +02:00
Daniel Vetter
0f037bdee1 drm: extract helpers to compute new training values from sink request
Safe for the minor difference that the intel versions get an offset
into the link_status as an argument, both are the same again.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 22:34:45 +02:00
Daniel Vetter
01916270b8 drm: dp helper: extract drm_dp_clock_recovery_ok
radeon and intel use the exact same definition.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>

v2: Kill 2 more helpers in intel_dp.c that I've missed.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 22:34:37 +02:00
Daniel Vetter
1ffdff134e drm: dp helper: extract drm_dp_channel_eq_ok
radeon and intel use the exact same definition.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 22:23:36 +02:00
Mika Kuoppala
9ec15619fc drm/i915: remove unused mem_block struct definition
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 19:39:29 +02:00
Jani Nikula
9cd300e038 drm/i915: Move cached EDID to intel_connector
Move the cached EDID from intel_dp and intel_lvds_connector to
intel_connector. Unify cached EDID handling for LVDS and eDP, in
preparation for adding more generic EDID caching later.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 19:34:03 +02:00
Jani Nikula
ebda95a996 drm/i915: Do not free the passed EDID in intel_connector_update_modes()
The caller, not intel_connector_update_modes(), should free the edid. This
improves the reusability of intel_connector_update_modes().

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 19:33:46 +02:00
Jani Nikula
dd06f90ee8 drm/i915: Move the fixed mode to intel_panel
Pave the way for sharing some logic between eDP and LVDS.

Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 19:01:49 +02:00
Jani Nikula
1d508706ea drm/i915: Create generic intel_panel for LVDS and eDP
Create a generic struct intel_panel for sharing a data structure and code
between eDP and LVDS panels. Add the new struct to intel_connector so that
later on we can have generic EDID and mode reading functions with EDID
caching that transparently fallback to fixed mode when EDID is not
available.

Add intel_panel as a dummy first, and move data (such as the mentioned
fixed mode) to it in later patches.

Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup tiny conflict in intel_dp_destroy.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 18:31:20 +02:00
Jani Nikula
f8779fda57 drm/i915/dp: Initialize eDP fixed mode in intel_dp_init
Since we do EDID caching in intel_dp_init, we can do the fixed mode
initialization there too. This should not change the functionality apart
from initializing fixed mode earlier. Particularly retain the behaviour of
only falling back to VBT if EDID is not available to not regress

commit 47f0eb2234
Author: Keith Packard <keithp@keithp.com>
Date:   Mon Sep 19 14:33:26 2011 -0700

    drm/i915: Only use VBT panel mode on eDP if no EDID is found

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 18:09:50 +02:00
Jani Nikula
62165e0def drm/i915/lvds: Move some connector specific info across from the encoder
As there is 1:1 mapping between encoder and connector for the LVDS, the
goal is to simply reduce the amount of noise within the connector
functions, i.e. we split the encoder/connector for LVDS as best we can and
try to only operate on the LVDS connector from the connector funcs and the
LVDS encoder form the encoder funcs.

Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 18:08:41 +02:00
Jani Nikula
0657b6b111 drm/i915: Backlight setup requires connector so pass it as parameter
Get rid of saved int_lvds_connector and int_edp_connector in
drm_i915_private.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 18:07:51 +02:00
Jani Nikula
db1740a0f1 drm/i915/lvds: Move the acpi_lid_notifier from drm_i915_private to the connector
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 18:06:21 +02:00
Jani Nikula
c7362c4dac drm/i915/lvds: Introduce intel_lvds_connector
Introduce a local structure to move LVDS specific information away from the
drm_i915_private and onto the LVDS connector.

Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 18:03:20 +02:00
Jani Nikula
29b99b4841 drm/i915/lvds: Rename intel_lvds to intel_lvds_encoder
In preparation for introducing intel_lvds_connector to move some of the
LVDS specific storage away from drm_i915_private, first rename the encoder
to avoid potential confusion.

Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22 18:03:02 +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
Dave Airlie
64acba6a7a Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Daniel writes:
The big thing is the disabling of the hsw support by default, cc: stable.
We've aimed for basic hsw support in 3.6, but due to a few bad
happenstances we've screwed up and only 3.8 will have better modeset
support than vesa. To avoid yet another round of fallout from such a
gaffle on for the next platform we've added a module option to disable
early hw support by default. That should also give us more flexibility in
bring-up.

 Otherwise just small fixes:
 - 3 fixes from Egbert for sdvo corner cases
 - invert-brightness quirk entry from Egbert
 - revert a dp link training change, it regresses some setups
 - and shut up a spurious WARN in our gem fault handler.
 - regression fix for an oops on bit17 swizzling machines, introduce in 3.7
 - another no-lvds quirk

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Initialize obj->pages before use by i915_gem_object_do_bit17_swizzle()
  drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
  drm/i915: Insert i915_preliminary_hw_support variable.
  drm/i915: shut up spurious WARN in the gtt fault handler
  Revert "drm/i915: Try harder to complete DP training pattern 1"
  DRM/i915: Restore sdvo_flags after dtd->mode->dtd Roundrtrip.
  DRM/i915: Don't clone SDVO LVDS with analog.
  DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines.
  DRM/i915: Don't delete DPLL Multiplier during DAC init.
2012-10-22 09:55:48 +10:00
Damien Lespiau
29de6ce574 drm/i915: Don't program DSPCLK_GATE_D twice on IVB and VLV
We were programming register 0x42020 twice on those platforms. Once
should be enough.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-20 01:01:48 +02:00
Damien Lespiau
4d47e4f57f drm/i915: Program DSPCLK_GATE_D only once on Ironlake
With the consolidated registers, it appears that we're setting the same
bis several times. Let's just collect the bits we want to set and program
it once.

v2: More cleanup. Also program 0x42004 and 0x45000 for FBC on non
    mobile platforms (Paulo Zanoni)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Undo the functional change as discussed on irc.]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-20 00:59:02 +02:00
Chris Wilson
74ce6b6c63 drm/i915: Initialize obj->pages before use by i915_gem_object_do_bit17_swizzle()
If we leave obj->pages set to NULL before attempting to deswizzle them,
then an OOPS is well deserved.

Fixes regression introduced in commit 9da3da660d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jun 1 15:20:22 2012 +0100

    drm/i915: Replace the array of pages with a scatterlist

Reported-and-tested-by: Krzysztof Kolasa
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-19 21:52:52 +02:00
Chris Wilson
c31407a367 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
Reported-and-tested-by: Francois Tigeot <ftigeot@wolfpond.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55375
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-19 21:49:30 +02:00
Damien Lespiau
231e54f639 drm/i915: Consolidate ILK_DSPCLK_GATE and PCH_DSPCLK_GATE
Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and
ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one.

The transforms done are:

PCH_DSPCLK_GATE_D    -> ILK_DSPCLK_GATE_D
ILK_DSPCLK_GATE      -> ILK_DSPCLK_GATE_D

DPARBUNIT_CLOCK_GATE_DISABLE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE
ILK_DPARB_CLK_GATE           -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE

DPFDUNIT_CLOCK_GATE_DISABLE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
ILK_DPFD_CLK_GATE           -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
ILK_CLK_FBC                 -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE

DPFCRUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE
ILK_DPFC_DIS1                -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE

DPFCUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE
ILK_DPFC_DIS2               -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE

We have a VHRUNIT_CLOCK_GATE_DISABLE define for the pre-ILK DSPCLK_GATE_D.
Even if the same bit is used in ILK_DSPCLK_GATE_D, other bits in the
register change, so I went with re-defining it, well more precisely rename
IVB_VRHUNIT_CLK_GATE, which is not specific to IVB+. So:

IVB_VRHUNIT_CLK_GATE       -> ILK_VHRUNIT_CLOCK_GATE_DISABLE
VHRUNIT_CLOCK_GATE_DISABLE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE (ILK+ code)

This commit is only a renaming commit, further commits will clean up the
logic.

v2: Rename bit 5 and 7 to _ENABLE as setting them to 1 enables clock
    gating on their respective units, contrary to all of the other bits
    (Paulo Zanoni)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-19 20:30:51 +02:00
Daniel Vetter
36ec8f8774 drm/i915: unconditionally use mt forcewake on hsw/ivb
Single-threaded forcewake was only used on some early pre-production
ivybridge machines, all the latest ones should use mt forcewake. And
we already assume this in other places of the code (e.g. DERRMR
support in the ddx, or the latest intel_gt_reset patch to reset any
lingering forcewake references left behind by the bios), so don't
bother here, too.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-19 19:32:36 +02:00
Paulo Zanoni
a7902ac548 drm/i915: set the correct function pointers for Haswell DP
This is the final remaining piece of Haswell DP enablement. After this
patch, just calling intel_dp_init on any port will make DP work. We
still do not do this because we're currently initializing HDMI on all
the ports, so if we replace intel_hdmi_init with intel_dp_init, we
will break HDMI, and we can't call both because they share the same
registers.

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-18 21:24:38 +02:00
Paulo Zanoni
c19b066992 drm/i915: implement Haswell DP link train sequence
Previous patch "drm/i915: add basic Haswell DP link train bits"
implemented the basic structure to set the voltage levels and training
patterns. This patch adds the higher-level bits that are part of the
mode set sequence and hot plug.

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-18 21:24:07 +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
Paulo Zanoni
a836bdf9ae drm/i915: add DP support to intel_ddi_disable_port
Just a missing register. There is no problem to run this code when the
output is HDMI.

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-18 21:21:43 +02:00
Paulo Zanoni
247d89f622 drm/i915: add DP support to intel_ddi_mode_set
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-18 21:19:22 +02:00
Paulo Zanoni
6547fef887 drm/i915: add DP support to intel_enable_ddi
We should only write the DDI_BUF_CTL at this point for HDMI/DVI. For
DP we need to do this earlier, and the values written to the register
are also different.

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-18 20:43:44 +02:00
Paulo Zanoni
fe43d3f5a3 drm/i915: add DP support to intel_ddi_get_hw_state
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-18 20:43:44 +02:00
Paulo Zanoni
0bdee30ed3 drm/i915: add DP support to intel_ddi_get_encoder_port
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-18 20:43:43 +02:00
Paulo Zanoni
750eb99e0e drm/i915: fix DP AUX register definitions on Haswell
The old rule that the AUX registers are just an offset (+4 and +10)
from output_reg is not true anymore, since output_reg in on the CPU
and some AUX regs are on the PCH.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: use the existing #defines as spotted by Damien Lespiau.]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-18 20:43:25 +02:00
Chris Wilson
16995a9fe1 drm/i915: Clear FORCEWAKE when taking over from BIOS
Some BIOSes may forcibly suspend RC6 during their operation which
trigger a warning as we find the hardware in a perplexing state upon
first use. So far that appears to be the worst symptom as fortuituously
we use the same values as the BIOS for programming the FORCEWAKE register.

Reported-by: Oleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-18 14:36:08 +02:00
Daniel Vetter
7fdd74ab80 drm/i915: don't save/restor ADPA for kms
We now no longer rely on this.

This is step 1 on a long journey to rid us of the save/restore
madness, which tends to lightly paper over many issues, and cause
tons of bad things itself ...

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: satisfy Paulo's ocd and drop the needless braces.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-18 14:34:00 +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
Daniel Vetter
912d812e84 drm/i915/crt: don't set HOTPLUG bits on !PCH
... since they don't apply to pre-pch platforms and could actually be
harmful.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-18 14:20:40 +02:00
Daniel Vetter
c630119f43 drm/i915: don't save/restore HWS_PGA reg for kms
We already do that as part of the ringbuffer re-setup at resume time.
Furthermore the register offset has moved on gen6+ around quite a bit,
and on ilk/gm45 we also need to restore the HWS reg for the bsd ring,
not just the render ring.

So again in kms mode this is only confusing a best, hence don't
bother.

v2: Fixup logic, noticed by Paulo Zanoni.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 22:38:34 +02:00
Daniel Vetter
905c27bb0d drm/i915: don't save/restore irq regs for kms
We already call drm_irq_install/uninstall at the right time, which
will set up the irq registers with the correct values (through the
preinstall hooks).

For kms this is at best harmless, in the worst case we get an
interrupt when we don't really expect it.

v2: Fixup the logic, noticed by Paulo Zanoni.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 22:36:51 +02:00
Daniel Vetter
f81183f76a drm/i915: don't save/restore DP regs for kms
We completely compute these anew in each modeset, hence we don't rely
on them containing anything valid after resume.

To avoid breaking any ums setup due to reordering of the reads/writes
simply don't reorder anything, but bracket the reads/writes into if
(!kms) conditionals. More churn, but safer.

v2: Fixup the logic, noticed by Paulo Zanoni.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 22:36:29 +02:00
Paulo Zanoni
7346bfa00d drm/i915: use TU_SIZE macro at intel_dp_set_m_n
Much simpler and looks more like the M/N code inside intel_display.c.

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-17 22:18:11 +02:00
Paulo Zanoni
d6c0d722ae drm/i915: add basic Haswell DP link train bits
Previously, the DP register was used for everything. On Haswell, it
was split into DDI_BUF_CTL (which is the new intel_dp->DP register)
and DP_TP_CTL.

The logic behind this patch is based on a patch written by Shobhit
Kumar, but the way the code was written is very different.

Credits-to: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fixup the logic error spotted by Jani Nikula.]
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 22:17:26 +02:00
Paulo Zanoni
068759bd6e drm/i915: add DP support to intel_ddi_pll_mode_set
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 22:13:02 +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
Paulo Zanoni
7739c33ba4 drm/i915: add DP support to intel_ddi_enable_pipe_func
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-17 21:47:26 +02:00
Rodrigo Vivi
0a3af26864 drm/i915: Insert i915_preliminary_hw_support variable.
On the worst scenario, users with new hardwares and old kernel from
enabling times can get black screens.  So, from now on, this
perliminary_hw_support module parameter shall be used by all upcoming
platforms that are still under enabling. The second option would be to
merge the pci ids after basic modeset works, but that makes testing
and development while bringing up hw a rather tedious afair.

Although it is uncomfortable for developers use this extra variable it
brings more stability for end users.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
[danvet: dropped the i915_ param prefix, i915.i915_ is just tedious.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 21:21:45 +02:00
Chris Wilson
c5836c27ae drm/i915: Document the multi-threaded FORCEWAKE bits
No functional change, but reserves 0x2 for use by userspace.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 21:10:41 +02:00
Chris Wilson
d7d4eeddb8 drm/i915: Allow DRM_ROOT_ONLY|DRM_MASTER to submit privileged batchbuffers
With the introduction of per-process GTT space, the hardware designers
thought it wise to also limit the ability to write to MMIO space to only
a "secure" batch buffer. The ability to rewrite registers is the only
way to program the hardware to perform certain operations like scanline
waits (required for tear-free windowed updates). So we either have a
choice of adding an interface to perform those synchronized updates
inside the kernel, or we permit certain processes the ability to write
to the "safe" registers from within its command stream. This patch
exposes the ability to submit a SECURE batch buffer to
DRM_ROOT_ONLY|DRM_MASTER processes.

v2: Haswell split up bit8 into a ppgtt bit (still bit8) and a security
bit (bit 13, accidentally not set). Also add a comment explaining why
secure batches need a global gtt binding.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: added hsw fixup.]
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 21:06:59 +02:00
Daniel Vetter
76e4383034 drm/i915: move hpd handling to (ibx|cpt)_irq_handler
Somehow this was left out in the refactoring that introduced the pch
handlers. Avoids a hotplug_mask special case in the ilk_irq_handler.

Noticed while hunting down the pch hotplug bits.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 21:06:57 +02:00
Daniel Vetter
a7c2e1aad6 drm/i915: shut up spurious WARN in the gtt fault handler
-ENOSPC can happen if userspace is being simplistic and tries to map a
too big object. To aid further spurious WARN debugging, also print out
the error code.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56017
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-17 11:56:40 +02:00
Daniel Vetter
b06fbda328 Revert "drm/i915: Try harder to complete DP training pattern 1"
This reverts commit 2477367083.

If (for whatever reason) the DP sink device never asks for the maximal
voltage level, we never don't hit the check that should bail us out
after 5 retries of the same voltage. Which leads to an endless loop in
the DP link training code, which hangs the driver.

Now some more DP link training experiments on eDP panels seem to
indicate that our training algorithm isn't robust enough anyway and
needs more work. Hence for 3.7-fixes, let's just revert the regressing
commit instead of trying to apply more duct-tape.

Reported-by: Oleksij Rempel <bug-track@fisher-privat.net>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-16 10:01:56 +02:00
Egbert Eich
e751823da2 DRM/i915: Restore sdvo_flags after dtd->mode->dtd Roundrtrip.
For TV and LVDS encoders intel_sdvo_set_input_timings_for_mode()
is called to pass a mode to the sdvo chip and retrieve a dtd
containing information needed to calculate the adjusted_mode which
is done by intel_sdvo_get_dtd_from_mode().
To set this adjusted_mode as input mode for the sdvo chip, a dtd is
recalculated using intel_sdvo_get_mode_from_dtd(). During this round
trip the sdvo_flags contained in the dtd obtained from the hardware
are lost.
Since these flags cannot be ignored in all cases this patch preserves
and restores them.

This regression has been introduced in

commit 6651819b4b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Apr 1 19:16:18 2012 +0200

    drm/i915: handle input/output sdvo timings separately in mode_set

Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-16 09:39:04 +02:00
Egbert Eich
e3b86d6941 DRM/i915: Don't clone SDVO LVDS with analog.
SDVO LVDS are not clonable as the input mode gets adjusted by
the LVDS encoder.

Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-16 09:39:04 +02:00
Egbert Eich
5f85f176c2 DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines.
NCR machines with LVDS panels using Intel chipsets need to have the
QUIRK_INVERT_BRIGHTNESS bit set.
Unfortunately NCR doesn't set a meaningful subvendor/subdevice ID,
therefore we add a DMI dependent quirk list.

Signed-off-by: Egbert Eich <eich@suse.de>
[danvet: fixup whitespace fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-16 09:38:59 +02:00
Egbert Eich
6478d414fe DRM/i915: Don't delete DPLL Multiplier during DAC init.
The DPLL multipiler is set up in intel_display.c:i9xx_update_pll()
called from i9xx_crtc_mode_set().
There the DPLL multiplier is adjusted so that the SDVO gets a sufficient
bus clock.
When cloning a CRTC between an SDVO driven encoder and the standard
DAC the DAC setup code reseted the multiplier value to 1 thus undoing
the correct setup. There is no need to touch the multiplier in the DAC
setup code: the correct value (i.e. 1 in case no SDVO encoder is used)
is set by i9xx_update_pll() already.
A comment at the code suggested that this code is a left over from the
days when there was no setup for clone modes.

Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-16 09:33:38 +02:00
Ben Widawsky
ecd8faeac4 drm/i915: Add rc6vids to debugfs
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-16 09:23:52 +02:00
Ben Widawsky
31643d54a7 drm/i915: Workaround to bump rc6 voltage to 450
BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or
buggy BIOSen may not be doing this, so we correct it for them. Ideally
customers should update the BIOS as only it would know the optimal
values for the platform, so we leave that fact as a DRM_ERROR for the
user to see.

Unfortunately this isn't fixing any of the issues it was targeted to
fix, but it is documented that we must do it.

CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: bikeshedded loglevel of the "your bios is broken message" to
debug.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-16 09:23:52 +02:00
Ben Widawsky
42c0526c93 drm/i915: Extract PCU communication
There is a special mechanism for communicating with the PCU already
being used for the ring frequency stuff. As we'll be needing this for
other commands, extract it now to make future code less error prone and
the current code more reusable.

I'm not entirely sure if this code matches 1:1 with the previous code
behaviorally. Functionally however, it should be the same.

CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Fixup compile fail reported by Wu Fengguang.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-16 09:23:26 +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
Jani Nikula
be3cd5e377 drm/i915: fix non-DP-D eDP backlight cleanup and module reload
Backlight is initialized for eDP, but cleaned up only for eDP on DP-D
port. This leaves behind a dangling backlight interface on module unload on
machines that have eDP connected to something other than DP-D, and breaks
the backlight interface for subsequent module reloads. Fix the cleanup, and
thus module reload on affected machines.

Reported-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Tested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-12 10:59:12 +02:00
Rodrigo Vivi
eda2d7f582 drm/i915: HSW CRW stability magic
This magic brings stability to HSW CRW machines.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-12 10:59:11 +02:00
Daniel Vetter
4afa0ace42 drm/i915/dvo-ch7xxx: fix get_hw_state
The boot-up state seems to be all-zeros, so it's safer to check for
the bits that need to be set when the dvo encoder is in the dpms on
state, than checking the bits we set when it's in the off state.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55047
Tested-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
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
Chris Wilson
1cf8378906 drm/i915: fixup i915_gem_object_get_page inline helper
Note that just because we have n == MAX elements left, does not imply
that there are only MAX elements left in the scatterlist and so we may
not be on the last chain, and the nth element may in fact be a chain ptr.

This is exercised by the improved hangman tests and the gem_exec_big
test in i-g-t.

This regression has been introduced in

commit 9da3da660d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jun 1 15:20:22 2012 +0100

   drm/i915: Replace the array of pages with a scatterlist

v2: KISS, replace the direct lookup with a for_each_sg() [danvet]
v3: Try to be clever again.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-12 10:59:09 +02:00
Chris Wilson
acb868d3d7 drm/i915: Disallow preallocation of requests
The intention was to allow the caller to avoid a failure to queue a
request having already written commands to the ring. However, this is a
moot point as the i915_add_request() can fail for other reasons than a
mere allocation failure and those failure cases are more likely than
ENOMEM. So the overlay code already had to handle i915_add_request()
failures, and due to

commit 3bb73aba1e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 12:40:59 2012 +0100

    drm/i915: Allow late allocation of request for i915_add_request()

the error handling code in intel_overlay.c was subject to causing
double-frees, as found by coverity.

Rather than further complicate i915_add_request() and callers, realise
the battle is lost and adapt intel_overlay.c to take advantage of the
late allocation of requests.

v2: Handle callers passing in a NULL seqno.
v3: Ditto. This time for sure.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-12 10:59:09 +02:00
Kenneth Graunke
26b6e44afb drm/i915: Set guardband clipping workaround bit in the right register.
A previous patch, namely:

commit bf97b276ca
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 11 20:42:41 2012 +0200

    drm/i915: implement w/a for incorrect guarband clipping

accidentally set bit 5 in 3D_CHICKEN, which has nothing to do with
clipping.  This patch changes it to be set in 3D_CHICKEN3, where it
belongs.

The game "Dante" demonstrates random clipping issues when guardband
clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set.  So the
workaround is actually necessary.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Oliver McFadden <oliver.mcfadden@linux.intel.com>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-12 10:59:02 +02:00
Damien Lespiau
39bc66c937 drm/i915: Fix the SCC/SSC typo in the SPLL bits definition
We're talking about Spread Spectrum Clocks here, thus SSC.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-11 22:37:17 +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
2886e93f5d drm/i915: disable DDI_BUF_CTL at the correct time
And also properly wait for its idle bit.

You may notice that DDI_BUF_CTL is enabled in .enable but disabled in
.post_disable instead of .disable. Yes, the mode set sequence is not
exactly symmetrical, but let's assume the spec is correct unless we
can prove it's wrong.

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:42:52 +02:00
Paulo Zanoni
27c6f0a589 drm/i915: don't implement WaDisableEarlyCull for Haswell
Introduced in commit 87f8020ec9:
  drm/i915: implement WaDisableEarlyCull for VLV and IVB

Notice that the original patch sent to the mailing list did not
include the Haswell chunk, it was added later.

The bit set by the commit does not exist on Haswell machines (at least
that's what the documentation says). Also, the commit gives me a GPU
hang every time we're loading the driver. So let's revert the Haswell
chunk, making the patch do only what its title actually says.

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 23:46:16 +02:00
Paulo Zanoni
1e6210f45d drm/i915: don't rely on previous values set on DDI_BUF_CTL
Just set the only bit we need, everything else is either ignored on
HDMI or should be set to zero.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-10 16:56:30 +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
Chris Wilson
bcb4508616 drm/i915: Align the retire_requests worker to the nearest second
By using round_jiffies() we can align the wakeup of our worker to the
nearest second in order to batch wakeups and reduce system load, which
is useful for unimportant coarse tasks like our retire_requests.

v2: round_jiffies_relative() already returns the relative timeout value,
so no need to incorrectly perform the subtraction twice. The timer
interface still leaves the possibility for the value of jiffies to
change be we program the timer.

Suggested-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-08 18:45:21 +02:00
Chris Wilson
cecc21fea9 drm/i915: Align the hangcheck wakeup to the nearest second
round_jiffies() aligns the wakeup time to the nearest second in order to
batch wakeups and reduce system load, which is useful for unimportant
coarse timers like our hangcheck.

v2: round_jiffies_relative() returns the relative jiffie value, whereas
we need the absolute value for the timer.

Suggested-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-08 18:44:36 +02:00
Damien Lespiau
a9627b8816 drm/i915: Remove the WaDisableBackToBackFlipFix w/a for Haswell
This workaround is only valid for IVB and VLV and the write triggers an
error on HSW.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanonI@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-08 11:18:14 +02:00
Damien Lespiau
62cb944fa2 drm/i915: Document that we are implementing WaDisableBackToBackFlipFix
For the next person that checks these kind of things, without having to
dig up the register definition.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-08 11:10:03 +02:00
Willy Tarreau
c77d7162a7 drm/i915: remove useless BUG_ON which caused a regression in 3.5.
starting an old X server causes a kernel BUG since commit 1b50247a8d:

------------[ cut here ]------------
kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3661!
invalid opcode: 0000 [#1] SMP
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss uvcvideo
+videobuf2_core videodev videobuf2_vmalloc videobuf2_memops uhci_hcd ath9k mac80211 snd_hda_codec_realtek ath9k_common microcode
+ath9k_hw psmouse serio_raw sg ath cfg80211 atl1c lpc_ich mfd_core ehci_hcd snd_hda_intel snd_hda_codec snd_hwdep snd_pcm rtc_cmos
+snd_timer snd evdev eeepc_laptop snd_page_alloc sparse_keymap

Pid: 2866, comm: X Not tainted 3.5.6-rc1-eeepc #1 ASUSTeK Computer INC. 1005HA/1005HA
EIP: 0060:[<c12dc291>] EFLAGS: 00013297 CPU: 0
EIP is at i915_gem_entervt_ioctl+0xf1/0x110
EAX: f5941df4 EBX: f5940000 ECX: 00000000 EDX: 00020000
ESI: f5835400 EDI: 00000000 EBP: f51d7e38 ESP: f51d7e20
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: b760e0a0 CR3: 351b6000 CR4: 000007d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process X (pid: 2866, ti=f51d6000 task=f61af8d0 task.ti=f51d6000)
Stack:
 00000001 00000000 f5835414 f51d7e84 f5835400 f54f85c0 f51d7f10 c12b530b
 00000001 c151b139 c14751b6 c152e030 00000b32 00006459 00000059 0000e200
 00000001 00000000 00006459 c159ddd0 c12dc1a0 ffffffea 00000000 00000000
Call Trace:
 [<c12b530b>] drm_ioctl+0x2eb/0x440
 [<c12dc1a0>] ? i915_gem_init+0xe0/0xe0
 [<c1052b2b>] ? enqueue_hrtimer+0x1b/0x50
 [<c1053321>] ? __hrtimer_start_range_ns+0x161/0x330
 [<c10530b3>] ? lock_hrtimer_base+0x23/0x50
 [<c1053163>] ? hrtimer_try_to_cancel+0x33/0x70
 [<c12b5020>] ? drm_version+0x90/0x90
 [<c10ca171>] vfs_ioctl+0x31/0x50
 [<c10ca2e4>] do_vfs_ioctl+0x64/0x510
 [<c10535de>] ? hrtimer_nanosleep+0x8e/0x100
 [<c1052c20>] ? update_rmtp+0x80/0x80
 [<c10ca7c9>] sys_ioctl+0x39/0x60
 [<c1433949>] syscall_call+0x7/0xb
Code: 83 c4 0c 5b 5e 5f 5d c3 c7 44 24 04 2c 05 53 c1 c7 04 24 6f ef 47 c1 e8 6e e0 fd ff c7 83 38 1e 00 00 00 00 00 00 e9 3f ff ff
+ff <0f> 0b eb fe 0f 0b eb fe 8d b4 26 00 00 00 00 0f 0b eb fe 8d b6
EIP: [<c12dc291>] i915_gem_entervt_ioctl+0xf1/0x110 SS:ESP 0068:f51d7e20
---[ end trace dd332ec083cbd513 ]---

The crash happens here in i915_gem_entervt_ioctl() :

    3659          BUG_ON(!list_empty(&dev_priv->mm.active_list));
    3660          BUG_ON(!list_empty(&dev_priv->mm.flushing_list));
 -> 3661          BUG_ON(!list_empty(&dev_priv->mm.inactive_list));
    3662          mutex_unlock(&dev->struct_mutex);

Quoting Chris :
  "That BUG_ON there is silly and can simply be removed. The check is to
   verify that no batches were submitted to the kernel whilst the UMS/GEM
   client was suspended - to which the BUG_ONs are a crude approximation.
   Furthermore, the checks are too late, since it means we attempted to
   program the hardware whilst it was in an invalid state, the BUG_ONs are
   the least of your concerns at that point."

Note that this regression has been introduced in

commit 1b50247a8d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 24 15:47:30 2012 +0100

    drm/i915: Remove the list of pinned inactive objects

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
[danvet: Added note about the regressing commit and cc: stable.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-07 22:57:25 +02:00
Wei Yongjun
1a4bd9eaf0 drm/i915: remove duplicated include from intel_modes.c
Remove duplicated include.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-07 22:49:03 +02:00
Damien Lespiau
b57a1e962e drm/i915: Remove the disabling of VHR unit clock gating for HSW
There's is another register (a read only, so no harm done) at 0x42020 on
Haswell GPUs. Let's just remove the write from the copy&paste that
introduced haswell_init_clock_gating().

A note for the interested reader, it does seem we have a duplication of
the 0x42020 register definition, hence the removal of 2 writes. That
duplication could be the object of a later patch.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-07 22:27:26 +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
Jesse Barnes
87f8020ec9 drm/i915: implement WaDisableEarlyCull for VLV and IVB
Workaround for a culling optimization.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Also apply to haswell, spotted by Damien.]
Reviewed-by: "Lespiau, Damien" <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-04 19:36:30 +02:00
Jesse Barnes
61939d977d drm/i915: implement WaForceL3Serialization on VLV and IVB
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-04 19:34:28 +02:00
Ben Widawsky
f8f2ac9a76 drm/i915: Fix GT_MODE default value
I can't even find how I figured this might be needed anymore. But sure
enough, the value I'm reading back on platforms doesn't match what the
docs recommends.

It seemed to fix Chris' GT1 in limited testing as well.

Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-04 18:44:13 +02: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
Daniel Vetter
74d44445af drm/i915: call drm_handle_vblank before finish_page_flip
... since finish_page_flip needs the vblank timestamp generated
in drm_handle_vblank. Somehow all the gmch platforms get it right,
but all the pch platform irq handlers get is wrong. Hooray for copy&
pasting!

Currently this gets papered over by a gross hack in finish_page_flip.
A second patch will remove that.

Note that without this, the new timestamp sanity checks in flip_test
occasionally get tripped up, hence the cc: stable tag.

Cc: stable@vger.kernel.org
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
Mika Kuoppala
4d0f817e74 drm/i915: print warning if vmi915_gem_fault error is not handled
Falling into default case in vmi915_gem_fault is a bug. Be more
verbose about it.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-04 10:33:42 +02:00
Dmitry Rogozhkin
e79e0fe380 drm/i915: EBUSY status handling added to i915_gem_fault().
Subsequent threads returning EBUSY from vm_insert_pfn() was not handled
correctly. As a result concurrent access from new threads to
mmapped data caused SIGBUS.

Note that this fixes i-g-t/tests/gem_threaded_tiled_access.

Tested-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-04 10:33:42 +02:00
Chris Wilson
2477367083 drm/i915: Try harder to complete DP training pattern 1
In commit cdb0e95bf5
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Nov 1 20:00:06 2011 -0700

    drm/i915: Try harder during dp pattern 1 link training

extra passes were made to retry the same voltage and then retry a full
clock reset. However, as coverity pointed out, we never tried the full
clock reset as we broke out of the loop early.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-04 10:33:41 +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
Jesse Barnes
7f6613412c drm/i915: set swizzling to none on VLV
We don't have bit 6 swizzling on VLV, so this function is easy.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-03 09:15:29 +02: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
David Howells
4126d5d61f UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.
Remove redundant DRM UAPI header #inclusions from drivers/gpu/.

Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and
drm_sarea.h).  They are now #included via drmP.h and drm_crtc.h via a preceding
patch.

Without this patch and the patch to make include the UAPI headers from the core
headers, after the UAPI split, the DRM C sources cannot find these UAPI headers
because the DRM code relies on specific -I flags to make #include "..."  work
on headers in include/drm/ - but that does not work after the UAPI split without
adding more -I flags.

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:05 +01:00
Adam Jackson
232351777c drm/dp: Make sink count DP 1.2 aware
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-02 18:06:07 +02:00
Adam Jackson
caf9ab24e3 drm/i915/dp: Be smarter about connection sense for branch devices
If there's no downstream device, DPCD success is good enough.  If
there's a hotplug-capable downstream device, count the number of
connected sinks in DP_SINK_STATUS and return success if it's non-zero.
Otherwise, probe DDC and report appropriately.

v2: Check DP_SINK_STATUS instead of something unrelated to sink status.

Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-02 18:06:07 +02:00
Adam Jackson
edb39244fa drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
v2: Fix parenthesis mismatch, spotted by Jani Nikula

Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Fixup merge conflict and MAX_DOWNSTREAM #define as spotted by
Jani.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-02 18:06:06 +02:00
Daniel Vetter
ff1f525ef4 drm/i915: s/DRM_IRQ_ARGS/int irq, void *arg
I'm official fed up with the yelling and useless indirection.

Let it burn!

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-02 17:58:21 +02: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
Chris Wilson
ac82ea2e97 drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a
A side-effect of commit 7d54a90428
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 10 10:18:10 2012 +0100

    drm/i915: Apply post-sync write for pipe control invalidates

was that only a request to emit invalidate flush would result in the
TLB being invalidated (since it requires synchronisation and so incurs a
performance penalty). However, the stated w/a for hardware contexts is
that the TLBs must be invalidated prior to a MI_SET_CONTEXT, yet the w/a
itself did not request the TLBs to be invalidated...

Note this w/a does not prevent the hard system hang I experience when
using hw contexts (with rc6 enabled) on SNB GT1.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-02 10:28:18 +02:00
Jani Nikula
749052fba6 drm/i915: add debug logging to ASLE backlight set requests
Make it easier to track backlight set requests coming through ASLE instead
of the driver's own backlight sysfs interface. We've had enough of
backlight issues to warrant some extra debug logs in the area.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-01 16:23:12 +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
Vijay Purushothaman
b56747aace drm/i915: Add Valleyview lane control definitions
Added DPIO data lane register definitions for Valleyview

Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@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 16:48:27 +02:00
Vijay Purushothaman
ae33cdcfc6 drm/i915: Fix SDVO IER and status bits for Valleyview
Fixed SDVOB and SDVOC bit definitions for Valleyview.

Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@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 16:46:55 +02:00
Vijay Purushothaman
9473c8f485 drm/i915: Set aux clk to 100MHz for Valleyview
Set hrawclk to 200 MHz and aux divider clock to 100 MHz for Valleyview.
This enables the aux transactions in Valleyview.

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:42:52 +02:00
Ben Widawsky
3bc2913e2c drm/i915: Fix set_caching locking
On the EINVAL case we don't release struct_mutex. It should be safe to
grab the lock after checking the parameters, which also resolves the
issues.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-27 08:45:11 +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
Jesse Barnes
3bcedbe5f2 drm/i915: limit VLV IRQ enables to those we use
To match IVB.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-26 16:16:32 +02:00
Adam Jackson
da131a4626 drm/dp: Make sink count DP 1.2 aware
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-26 14:26:06 +02:00
Adam Jackson
07d3dc1839 drm/i915/dp: Be smarter about connection sense for branch devices
If there's no downstream device, DPCD success is good enough.  If
there's a hotplug-capable downstream device, count the number of
connected sinks in DP_SINK_STATUS and return success if it's non-zero.
Otherwise, probe DDC and report appropriately.

v2: Check DP_SINK_STATUS instead of something unrelated to sink status.

Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-26 14:22:29 +02:00
Adam Jackson
b091cd928d drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
v2: Fix parenthesis mismatch, spotted by Jani Nikula

Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Fixup merge conflict and MAX_DOWNSTREAM #define as spotted by
Jani.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-26 14:21:29 +02:00
Chris Wilson
f531dcb23f drm/i915: Wrap external callers to IPS state with appropriate locks
Finishes commit 02d719562e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 9 16:44:54 2012 +0200

    drm/i915: properly guard ilk ips state

The core functions were annotated with their locking requirements, but
we overlooked that they were exported, without any control over the
locking, to debugfs. So in order to enable debugfs to read the registers
without triggering sanity checks, we change the exported entry points to
properly take the required locks before calling the core routines.

Reported-by: yangguang <guang.a.yang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-26 09:24:54 +02:00
Ben Widawsky
199adf40ae drm/i915: s/cacheing/caching/
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-26 09:24:36 +02:00
Paulo Zanoni
adf00b26d1 drm/i915: make sure we write all the DIP data bytes
... even if the actual infoframe is smaller than the maximum possible
size.

If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
be correctly calculated in some cases (e.g., when changing the port),
and this will lead to black screens on HDMI monitors. The ECC value is
generated by the hardware.

I don't see how this should break anything since we're writing 0 and
that should be the correct value, so this patch should be safe.

Notice that on IVB and older we actually have 64 bytes available for
VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
others are either read-only ECC values or marked as "reserved". On HSW
we only have 32 bytes, and the ECC value is stored on its own separate
read-only register. See BSpec.

This patch fixes bug #46761, which is marked as a regression
introduced by commit 4e89ee174b:
    drm/i915: set the DIP port on ibx_write_infoframe

Before commit 4e89 we were just failing to send AVI infoframes when we
needed to change the port, which can lead to black screens in some
cases. After commit 4e89 we started sending infoframes, but with a
possibly wrong ECC value. After this patch I hope we start sending
correct infoframes.

Version 2:
  - Improve commit message
  - Try to make the code more clear

Cc: stable@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761
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-26 09:24:09 +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
Paulo Zanoni
57df2ae9df drm/i915: BUG() on unexpected HDMI register
This should never happen, but the silent "return" makes me wonder
every time I try to debug InfoFrame bugs, so promote this to BUG() to
make sure people will complain if we ever break this.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-24 16:24:20 +02:00
Ben Widawsky
853c70e8da drm/i915: Fix !CONFIG_PM sysfs for real this time
Somehow this hunk got dropped from my last patch. We do not have the
rc6_attrs when there is no CONFIG_PM so this causes a compilation error.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:11 +02:00
Chris Wilson
41783eea1a drm/i915: Assert that the exec object lookup table is a power-of-two
As we make the simplification of using a power-of-two size for the
execbuffer handle-to-object TLB, we should validate that this is actually
true and so clarify that premise.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:11 +02:00
Wang Xingchao
3cce574f01 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally
Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.

In intel_enable_hdmi(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
be set to trigger unsolicated event to notify Alsa driver the change.

intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
remove the hdmi cable, here's debug log:

[  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
[  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0

so when comes back to intel_disable_hdmi(), the "Audio enable bit" will not be cleared. And this
cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.

This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:

[  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
[  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0

Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:10 +02:00
Chris Wilson
2f745ad3d3 drm/i915: Convert the dmabuf object to use the new i915_gem_object_ops
By providing a callback for when we need to bind the pages, and then
release them again later, we can shorten the amount of time we hold the
foreign pages mapped and pinned, and importantly the dmabuf objects then
behave as any other normal object with respect to the shrinker and
memory management.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:10 +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
Chris Wilson
934d6086ea drm/i915: Limit the ioremap of the PCI bar to the registers
In the future we may like to experiment with using a WC map of the GTT
portion. However, that will conflict with i915.ko mapping the entire bar
as UC in order to access the GPU registers. Instead we can shrink the
register ioremap to only map the register block.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by (IVB): Ben Widawsky <ben@bwidawsk.net>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Squashed-in follow-up fix for gen2/3 registers file size from
Chris Wilson.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:07 +02:00
Ben Widawsky
ac6ae347a5 drm/i915: Show render P state thresholds in sysfs
This is useful for userspace utilities which wish to use the previous
interface, specifically for micromanaging the increase/decrease steps by
setting min == max.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:06 +02:00
Ben Widawsky
46ddf19477 drm/i915: Add setters for min/max frequency
Provide a standardized sysfs interface for setting min, and max
frequencies.  The code which reads the limits were lifted from the
debugfs files. As a brief explanation, the limits are similar to the CPU
p-states. We have 3 states:

RP0 - ie. max frequency
RP1 - ie. "preferred min" frequency
RPn - seriously lowest frequency

Initially Daniel asked me to clamp the writes to supported values, but
in conforming to the way the cpufreq drivers seem to work, instead
return -EINVAL (noticed by Jesse in discussion).
The values can be used by userspace wishing to control the limits of the
GPU (see the CC list for people who care).

v4: Make exceeding the soft limits return -EINVAL as well (Daniel)

v3: bug fix (Ben) -  was passing the MHz value to gen6_set_rps instead of
the step value. To fix, deal only with step values by doing the divide
at the top.

v2: add the dropped mutex_unlock in error cases (Chris)
EINVAL on both too min, or too max (Daniel)

v2 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:06 +02:00
Daniel Vetter
b6f69c9a7f drm/i915: rip out edp special case from dp_link_down
This has been tons of fun to figure out with git blame. The first
notion of this code block goes back to the original cpu edp enabling
for ilk in

commit 32f9d658ae
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Fri Jul 24 01:00:32 2009 +0800

    drm/i915: Add eDP support on IGDNG mobile chip

Two things are notable in this commit wrt to the this edp special
case:
- The IS_eDP check _only_ fires for DP A, i.e. cpu edp ports.
- The cpu edp port is disabled at the top of the dp_link_down function.

My theory is that these hacks was added to work around the completely
different modeset sequence for cpu edp ports compared to pch edp
ports. With the cpu edp confusion on ilk (and snb/ivb) now fixed up,
this shouldn't be required any more.

The really interesting question is how this special cases survived
this long in the code. The first step is declaring the pch port D as
eDP if it's used for an internal panel:

commit b329530ca7
Author: Adam Jackson <ajax@redhat.com>
Date:   Fri Jul 16 14:46:28 2010 -0400

    drm/i915/dp: Correctly report eDP in the core connector type

This commit unfortunately failed to notice that not all edp ports are
created equal. Then follow a flurry of refactorings, culminating in a
patch from Keith Packard which resulted in the current logic (by
making it "correct" for all platforms that have edp):

commit 417e822dee
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Nov 1 19:54:11 2011 -0700

    drm/i915: Treat PCH eDP like DP in most places

None of these cleanups or refactorings supply any reason why we need
this code, they've simply carried it on as-is.

Hence presume it might be harmful with the current code and rip it
out. We do rewrite the link training bits completely anyway when
re-training the link.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:05 +02:00
Chris Wilson
ba7a64587b drm/i915: Drop the misleading cast to the wrong user pointer type
The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
a drm_i915_gem_relocation_entry is very confusing!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:05 +02:00
Lekensteyn
d627b62ff8 i915: initialize CADL in opregion
This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not
used anywhere in the driver code at the moment, but it could be used in BIOS as
is the case with the Clevo laptop.

The Clevo B7130 requires the CADL field to contain at least the ID of
the LCD device. If this field is empty, the ACPI methods that are called
on pressing brightness / display switching hotkeys will not trigger a
notification. As a result, it appears as no hotkey has been pressed.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:05 +02:00
Daniel Vetter
3739850b46 drm/i915: disable the cpu edp port after the cpu pipe
See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This
applies to all platforms where we currently support eDP on, i.e. ilk,
snb & ivb.

Without this change we fail to light up the eDP port on previously
unused crtcs (likely because something is stuck on the old pipe), and
we also fail to properly disable the old pipe (i.e. bit 30 in the
PIPECONF register is stuck as set until the next reboot).

v2: Rebased on top of the edp panel off sequence changes in 3.6-rc2.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44001
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:04 +02:00
Daniel Vetter
0c33d8d7cc drm/i915: rip out dp port enabling cludges^Wchecks
These have been added because dp links are fiddle things and don't
like it when we try to re-train an enabled output (or disable a
disabled output harder). And because the crtc helper code is
ridiculously bad add tracking the modeset state.

But with the new code in place it is simply a bug to disable a disabled
encoder or to enable an enabled encoder again. Hence convert these to
WARNs (and bail out for safety), but flatten all conditionals in the
code itself.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:04 +02:00
Daniel Vetter
0767935e86 drm/i915: robustify edp_pll_on/off
With the previous patch to clean up where exactly these two functions
are getting called, this patch can tackle the enable/disable code
itself:

- WARN if the port enable bit is in the wrong state or if the edp pll
  bit is in the wrong state, just for paranoia's sake.
- Don't disable the edp pll harder in the modeset functions just for
  fun.
- Don't set the edp pll enable flag in intel_dp->DP in modeset, do
  that while changing the actual hw state. We do the same with the
  actual port enable bit, so this is a bit more consistent.
- Track the current DP register value when setting things up and add
  some comments how intel_dp->DP is used in the disable code.

v2: Be more careful with resetting intel_dp->DP - otherwise dpms
off->on will fail spectacularly, becuase we enable the eDP port when
we should only enable the eDP pll.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:03 +02:00
Daniel Vetter
2bd2ad643d drm/i915: clean up the cpu edp pll special case
By using the new pre_enable/post_disable functions.

To ensure that we only frob the cpu edp pll while the pipe is off add
the relevant asserts. Thanks to the new output state staging, this is
now really easy.

With this fixed we can now finally rip out the special-case handling
in the dp dpms code and replace it by the common intel_connector_dpms.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:03 +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
Daniel Vetter
fba92150aa drm/i915: rip out early dp port write for gm45/ilk
It's bogus.

If I've followed the history of this piece of code correctly, i.e. the
initial register write with the following vblank wait, this goes all
the way back to the original enabling of DP support in

commit a4fc5ed698
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Apr 7 16:16:42 2009 -0700

    drm/i915: Add Display Port support

Unfortunately it seems to be nothing more than glorified duct-tape and
sometimes actively harmful. Adam Jackson noticed this for CPT
platforms with

commit e85194641b
Author: Adam Jackson <ajax@redhat.com>
Date:   Thu Jul 21 17:48:38 2011 -0400

    drm/i915/dp: Don't turn CPT DP ports on too early

Unfortunately this kept the code around for ilk and gm45.

The specific failure case I'm seeing here is that after a dpms off/on
cycle we have the bits from the last link training (hopefully
successful link training) set in intel_dp->DP. This is requiered so
that complete_link_train can enable the port with the right tuning
values.

Unfortunately writing these again to the disabled port at dpms on time
kills the port somehow until it's disabled - dp link training fails in
an endless loop without this patch on my mobile ilk and gm45.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51493
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:02 +02:00
Ben Widawsky
792496368b drm/i915: Error checks in gen6_set_rps
With the new "standardized" sysfs interfaces we need to be a bit more
careful about setting the RPS values.

Because the sysfs code and the rps workqueue can run at the same time,
if the sysfs setter wins the race to the mutex, the workqueue can come
in and set a value which is out of range (ie. we're no longer protecting
by RPINTLIM).

I was not able to actually make this error occur in testing.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:01 +02:00
Ben Widawsky
d5570a7243 drm/i915: POSTING_READ the new rps value
In order to keep our cached values in sync with the hardware, we need a
posting read here.

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:01 +02:00
Ben Widawsky
df6eedc81d drm/i915: Add current/max/min GPU freq to sysfs
Userspace applications such as PowerTOP are interesting in being able to
read the current GPU frequency. The patch itself sets up a generic array
for gen6 attributes so we can easily add other items in the future (and
it also happens to be just about the cleanest way to do this).

The patch is a nice addition to
commit 1ac02185dff3afac146d745ba220dc6672d1d162
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 30 13:26:48 2012 +0200

    drm/i915: add a tracepoint for gpu frequency changes

Reading the GPU frequncy can be done by reading a file like:
/sys/class/drm/card0/render_frequency_mhz

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:00 +02:00
Ben Widawsky
c8735b0c3e drm/i915: #define gpu freq multipler
Magic numbers are bad mmmkay. In this case in particular the value is
especially weird because the docs say multiple things. We'll need this
value for sysfs, so extracting it is useful for that as well.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:23:00 +02:00
Ben Widawsky
dbdfd8e90c drm/i915: variable renames
Name variables a bit better for copy-pasters. This got turned up as part
of review for upcoming sysfs patches.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:59 +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
Chris Wilson
9da3da660d drm/i915: Replace the array of pages with a scatterlist
Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.

One major advantage, other than unifying the page tracking structures,
this offers is that we replace the vmalloc'ed array (which can be up to
a megabyte in size) with a chain of individual pages which helps reduce
memory pressure.

The disadvantage is that we then do not have a simple array to iterate,
or to access randomly. The common case for this is in the relocation
processing, which will typically fit within a single scatterlist page
and so be almost the same cost as the simple array. For iterating over
the array, the extra function call could be optimised away, but in
reality is an insignificant cost of either binding the pages, or
performing the pwrite/pread.

v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the
trivial compile error from rebasing.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:57 +02:00
Chris Wilson
f60d7f0c1d drm/i915: Pin backing pages for pread
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:57 +02:00
Chris Wilson
755d22184f drm/i915: Pin backing pages for pwrite
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
jeneath us, and so we can simplify the code for iterating over the pages.

Note: The old code had such complicated page refcounting since it used
obj->pages as a micro-optimization if it's there, but that could
(before this patch) disappear when we drop the dev->struct_mutex.
Hence some manual page refcounting was required for the slow path,
complicated by the fact that pages returned by shmem_read_mapping_page
already have a pageref, which needs to be dropped again.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Added note to explain the question Ben raised in review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:56 +02:00
Chris Wilson
a5570178c0 drm/i915: Pin backing pages whilst exporting through a dmabuf vmap
We need to refcount our pages in order to prevent reaping them at
inopportune times, such as when they currently vmapped or exported to
another driver. However, we also wish to keep the lazy deallocation of
our pages so we need to take a pin/unpinned approach rather than a
simple refcount.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:56 +02:00
Chris Wilson
37e680a15f drm/i915: Introduce drm_i915_gem_object_ops
In order to specialise functions depending upon the type of object, we
can attach vfuncs to each object via a new ->ops pointer.

For instance, this will be used in future patches to only bind pages from
a dma-buf for the duration that the object is used by the GPU - and so
prevent them from pinning those pages for the entire of the object.

v2: Bonus comments.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20 14:22:55 +02:00
Daniel Vetter
3b7a89fce3 drm/i915: fix OOPS in lid_notify
This goes back to

commit c1c7af6089
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Sep 10 15:28:03 2009 -0700

    drm/i915: force mode set at lid open time

It was used to fix an issue on a i915GM based Thinkpad X41, which
somehow clobbered the modeset state at lid close time. Since then
massive amounts of things changed: Tons of fixes to the modeset
sequence, OpRegion support, better integration with the acpi code.
Especially OpRegion /should/ allow us to control the display hw
cooperatively with the firmware, without the firmware clobbering the
hw state behind our backs.

So it's dubious whether we still need this.

The second issue is that it's unclear who's responsibility it actually
is to restore the mode - Chris Wilson suggests to just emit a hotplug
event and let userspace figure things out.

The real reason I've stumbled over this is that the new modeset code
breaks drm_helper_resume_force_mode - it OOPSes derefing a NULL vfunc
pointer. The reason this wasn't caught in testing earlier is that in

commit c9354c85c1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Nov 2 09:29:55 2009 -0800

    i915: fix intel graphics suspend breakage due to resume/lid event
    confusion

logic was added to _not_ restore the modeset state after a resume. And
since most machines are configured to auto-suspend on lid-close, this
neatly papered over the issue.

Summarizing, this shouldn't be required on any platform supporting
OpRegion. And none of the really old machines I have here seem to
require it either. Hence I'm inclined to just rip it out.

But in case that there are really firmwares out there that clobber the
hw state, replace it with a call to intel_modset_check_state. This
will ensure that we catch any issues as soon as they happen.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-18 00:59:37 +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
Wang Xingchao
b98b601672 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.

In intel_hdmi_dpms(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
be set to trigger unsolicated event to notify Alsa driver the change.

intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
remove the hdmi cable, here's debug log:

[  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
[  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0

so when comes back to intel_hdmi_dpms(), the "Audio enable bit" will not be cleared. And this
cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.

This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:

[  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
[  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0

Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-17 10:13:02 +02:00
Chris Wilson
7e81a42e34 drm/i915: Reduce a pin-leak BUG into a WARN
Pin-leaks persist and we get the perennial bug reports of machine
lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that
the object cannot be pinned at that time it should prevent the driver from
locking up, and hopefully restore a semblance of working whilst still
leaving us a OOPS to debug.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-17 10:12:57 +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
974a3b0f9f drm/i915: set the right gen3 flip_done mode also at resume
Currently we've only frobbed this bit at irq_init time, but did
not restore it at resume time. Move it to the gen3 clock gating
function to fix this.

Notice while reading through code.

Cc: stable@vger.kernel.org (for 3.5 only)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-10 21:30:03 +02:00
Alexander Shishkin
99d0b1db6c drm/i915: initialize dpio_lock spin lock
This thing is killing lockdep.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
[Jani: move the init next to the other spin lock inits]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-08 19:04:04 +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
Daniel Vetter
9dc10f37e3 drm/i915: no longer call drm_helper_resume_force_mode
Since this only calls crtc helper functions, of which a shocking
amount are NULL.

Now the curious thing is how the new modeset code worked with this
function call still present:

Thanks to the hw state readout and the suspend fixes to properly
quiescent the register state, nothing is actually enabled at resume
(if the bios doesn't set up anything). Which means resume_force_mode
doesn't actually do anything and hence nothing blows up at resume
time.

The other reason things do work is that the fbcon layer has it's own
resume notifier callback, which restores the mode. And thanks to the
force vt switch at suspend/resume, that then forces X to restore it's
own mode.

Hence everything still worked (as long as the bios doesn't enable
anything). And we can just kill the call to resume_force_mode.

The upside of both this patch and the preceeding patch to quiescent
the modeset state is that our resume path is much simpler:
- We now longer restore bogus register values (which most often would
  enable the backlight a bit and a few ports), causing flickering.
- We now longer call resume_force_mode to restore a mode that the
  fbcon layer would overwrite right away anyway.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:30 +02:00
Daniel Vetter
a261b246eb drm/i915: disable all crtcs at suspend time
We need this to avoid confusing the hw state readout code with the cpt
pch plls at resume time: We'd read the new pipe state (which is
disabled), but still believe that we have a life pll connected to that
pipe (from before the suspend). Hence properly disable pipes to clear
out all the residual state.

This has the neat side-effect that we don't enable ports prematurely
by restoring bogus state from the saved register values.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:29 +02:00
Daniel Vetter
ea9d758d6d drm/i915: push commit_output_state past the crtc/encoder preparing
With this change we can (finally!) rip out a few of the temporary hacks
and clean up a few other things:
- Kill intel_crtc_prepare_encoders, now unused.
- Kill the hacks in the crtc_disable/enable functions to always call the
  encoder callbacks, we now always call the crtc functions with the right
  encoder -> crtc links.
- Also push down the crtc->enable, encoder and connector dpms state
  updates. Unfortunately we can't add a WARN in the crtc_disable
  callbacks to ensure that the crtc is always still enabled when
  disabling an output pipe - the crtc sanitizer of the hw readout path
  can hit this when it needs to disable an active pipe without any
  enabled outputs.
- Only call crtc->disable if the pipe is already enabled - again avoids
  running afoul of the new WARN.

v2: Copy&paste our own version of crtc_in_use, too.

v3: We need to update the dpms an encoder->connectors_active states,
too.

v4: I've forgotten to kill the unconditional encoder->disable calls in
the crtc_disable functions.

v5: Rip out leftover debug printk.

v6: Properly clear intel_encoder->connectors_active. This wasn't
properly cleared when disabling an encoder because it was no longer on
the new connector list, but the crtc was still enabled (i.e. switching
the encoder of an active crtc). Reported by Jani Nikula.

v7: Don't clobber the encoder->connectors_active state of untouched
encoders. Since X likes to first disable all outputs with dpms off
before setting a new framebuffer, this hit a few warnings. Reported by
Paulo Zanoni.

v8: Kill the now stale comment warning that intel_crtc->active is not
always updated at the right times.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:29 +02:00
Daniel Vetter
fc303101dc drm/i915: switch the load detect code to the staged modeset config
Now that set_mode also disables crtcs and expects it's new
configuration in the staged output links we need to adjust the load
detect code a bit.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:28 +02:00
Daniel Vetter
284637d922 drm/i915: WARN if the pipe won't turn off
This seems to be the symptom of a few neat bugs, hence be more
obnoxious when this fails.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:28 +02:00
Daniel Vetter
1f70385510 drm/i915: s/intel_encoder_disable/intel_encoder_noop
Because that's what it is. Unfortunately we can't rip this out because
the fb helper has an incetious relationship with the crtc helper - it
likes to call disable_unused_functions, among other things.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:27 +02:00
Daniel Vetter
976f8a2013 drm/i915: push commit_output_state past crtc disabling
This requires a few changes
- We still need a noop function for crtc->disable, becuase the fb
  helper is a bit too intimate with the crtc helper.
- We need to clear crtc->fb ourselves in intel_crtc_disable now that
  we no longer rely on the helper's disable_unused_functions to do
  that.
- We need to split out the sare update code, becuase the crtc code
  can't call update_dpms any more, it needs to disable the crtc
  unconditionally. This is because we now keep onto the encoder ->
  crtc mapping of the (still) active output pipe configuration.
- To check that we really disable a crtc that still has encoders,
  insert a WARN_ON(!enabled) in the crtc disable function.
- Lastly, we need to walk over all crtcs to update their enabled state
  after having called commit_output_state - for all disabled crtcs the
  crtc helper code has done that for us previously.

v2: Update connector dpms and encoder->connectors_active after
disabling the crtc, too.

v3: Noop-out intel_encoder_disable. Similarly to the crtc disable
callback used by the crtc helper code we can't simply remove all these
encoder callbacks: The fb helper (which we still use) has a rather
incetious relationship with the crtc helper code ...

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:27 +02:00
Daniel Vetter
25c5b2665f drm/i915: implement new set_mode code flow
... using the pipe masks from the previous patch.

Well, not quite:
- We still need to call the disable_unused_functions helper, until
  we've moved the call to commit_output_state further down and
  adjusted intel_crtc_disable a bit. The next patch will do that.
- Because we don't support (yet) mode changes on more than one crtc at
  a time, some of the modeset_pipes checks are a bit hackish - but
  that only needs fixing once we incorporate global modeset support.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:26 +02:00
Daniel Vetter
e2e1ed41ed drm/i915: compute masks of crtcs affected in set_mode
This is definetely a bit more generic than currently required, but if
we keep track of all crtcs that need to be disabled/enable (because
they loose an encoder or something similar), crtcs that get completely
disabled and those that we need to do an actual mode change nicely
prepares us for global modeset operations on multiple crtcs.

The only big thing missing here would be a global resource allocation
step (for e.g. pch plls), which would equally frob these bitmasks if
e.g. a crtc only needs a new pll. Or if we need to enable dithering on
an another pipe due to bandwidth constrains somewhere.

These masks aren't yet put to use in this patch, this will follow in the
next one.

v2-v5: Fix up the computations for good (hopefully).

v6: Fixup a confusion reported by Damien Lespiau: I've conserved the
(imo braindead) behaviour of the crtc helper to disable _any_
disconnected outputs if we do a modeset, even when that newly disabled
connector isn't connected to the crtc being changed by the modeset.

The effect of that is that we could disable an arbitrary number of
unrelated crtcs, which I haven't taken into account when writing this
code. Fix this up.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:21:26 +02:00
Daniel Vetter
e24c5c2900 drm/i915: use staged outuput config in lvds->mode_fixup
- Use the check_cloned helper from the previous patch.
- Use encoder->new_crtc to check crtc properties.

v2: Kill the double negation with s/!non_cloned/is_cloned, suggested
by Jesse Barnes.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:20:58 +02:00
Daniel Vetter
6ed0f796c2 drm/i915: use staged outuput config in tv->mode_fixup
The "is this encoder cloned" check will be reused by the lvds encoder,
hence exract it.

v2: Be a bit more careful about that we need to check the new, staged
ouput configuration in the check_non_cloned helper ...

v3: Kill the double negation with s/!non_cloned/is_cloned/, suggested
by Jesse Barnes.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:20:31 +02:00
Daniel Vetter
7758a11340 drm/i915: extract adjusted mode computation
While at it, adjust a few things:
- Only assigng the new mode to crtc->mode right before calling the
  mode_set callbacks - none of the previous callbacks depend upon
  this, they all use the mode argument (as they should).
- Check encoder->new_crtc instead of the current crtc to check whether
  the encoder will be used. This prepares for moving the staged output
  committing further down in the sequence. Follow-on patches will fix
  up individual ->mode_fixup callbacks (only tv and lvds are affected
  though).

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:04:38 +02:00
Daniel Vetter
87f1faa630 drm/i915: move output commit and crtc disabling into set_mode
It's rather pointless to compute crtc->enabled twice right away ;-)

The only thing we really have to be careful about is that we frob the
dpms state only after a successful modeset and when we've actually
haven't just disabled the crtc.

Hooray for convoluted interfaces ...

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:04:23 +02:00
Daniel Vetter
ba1c28c900 drm/i915: remove crtc disabling special case
Originally this has been introduced in

commit 6eebd6bb5f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Nov 28 21:10:05 2011 +0000

    drm: Fix lack of CRTC disable for drm_crtc_helper_set_config(.fb=NULL)

With the improvements of the output state staging and no longer
overwriting crtc->fb before the hw state is updated we can now handle
crtc disabling as part of the normal modeset sequence.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:03:39 +02:00
Daniel Vetter
94352cf9a5 drm/i915: push crtc->fb update into pipe_set_base
Passing in the old fb, having overwritten the current fb, leads to
some neatly convoluted code. It's much simpler if we defer the
crtc->fb update to the place that updates the hw, in pipe_set_base.
This way we also don't need to restore anything in case something
fails - we only update crtc->fb once things have succeeded.

The real reason for this change is that now we keep the old fb
assigned to crtc->fb, which allows us to finally move the crtc disable
case into the common low-level set_mode function in the next patch.

Also don't clobber crtc->x and crtc->y, we neatly pass these down the
callchain already. Unfortunately we can't do the same with crtc->mode,
because that one is being used in the mode_set callbacks.

v2: Don't restore the drm_crtc object any more on failed modesets,
since we've lose an fb reference otherwise. Also (and this is the
reason this has been found), this totally confused the modeset state
tracking, since it clobbers crtc->enabled. Issue reported by Paulo
Zanoni.

v3: Rip out the entire crtc saving into struct intel_set_config, not
just the restoring part.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:03:10 +02:00
Daniel Vetter
9a93585699 drm/i915: stage modeset output changes
This is the core of the new modeset logic.

The current code which is based upon the crtc helper code first
updates all the link of the new display pipeline and then calls the
lower-level set_mode function to execute the required callbacks to get
there. The issue with this approach is that for disabling we need to
know the _current_ display pipe state, not the new one.

Hence we need to stage the new state of the display pipe and only
update it once we have disabled the current configuration and before we
start to update the hw registers with the new configuration.

This patch here just prepares the ground by switching the new output
state computation to these staging pointers. To make it clearer,
rename the old update_output_state function to stage_output_state.

A few peculiarities:
- We're also calling the set_mode function at various places to update
  properties. Hence after a successfule modeset we need to stage the
  current configuration (for otherwise we might fall back again). This
  happens automatically because as part of the (successful) modeset we
  need to copy the staged state to the real one. But for the hw
  readout code we need to make sure that this happens, too.
- Teach the new staged output state computation code the required
  smarts to handle the disabling of outputs. The current code handles
  this in a special case, but to better handle global modeset changes
  covering more than one crtc, we want to do this all in the same
  low-level modeset code.
- The actual modeset code is still a bit ugly and wants to know the new
  crtc->enabled state a bit early. Follow-on patches will clean that
  up, for now we have to apply the staged output configuration early,
  outside of the set_mode functions.
- Improve/add comments in stage_output_state.

Essentially all that is left to do now is move the disabling code into
set_mode and then move the staged state update code also into
set_mode, at the right place between disabling things and calling the
mode_set callbacks for the new configuration.

v2: Disabling a crtc works by passing in a NULL mode or fb, userspace
doesn't hand in the list of connectors. We therefore need to detect
this case manually and tear down all the output links.

v3: Properly update the output staging pointers after having read out
the hw state.

v4: Simplify the code, add more DRM_DEBUG_KMS output and check a few
assumptions with WARN_ON. Essentially all things that I've noticed
while debugging issues in other places of the code.

v4: Correctly disable the old set of connectors when enabling an
already enabled crtc on a new set of crtc. Reported by Paulo Zanoni.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:02:57 +02:00
Daniel Vetter
1aa4b628ee drm/i915: don't save all the encoder/crtc state in set_config
We actually only touch the connector -> encoder and encoder -> crtc
linking. So it's enough to just save/restore that.

While at it, also switch to kcalloc to allocate these arrays (omission
in the commit message spotted by Jesse Barnes).

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:02:40 +02:00
Daniel Vetter
8d3e375e77 drm/i915: convert pointless error checks in set_config to BUGs
Because they all are, the ioctl command never calls us with any of
these violated. Also drop a equally pointless empty debug message (and
also in set_cursor, while we're at it).

With all these changes, intel_crtc_set_config is neatly condensed down
to it's essence, the actual modeset code (or fb update calling code)

v2: The fb helper code is actually stretching ->set_config semantics a bit,
it calls it with set->mode == NULL but set->fb != NULL.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:02:17 +02:00
Daniel Vetter
835c5873d6 drm/i915: don't update the fb base if there is no fb
Otherwise we'll set_fb complains pretty loudly if we the crtc is off
and userspace moves the NULL fb around a bit. Yeah, this actually
happens in the wild ...

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:02:07 +02:00
Daniel Vetter
431e50f799 drm/i915: implement crtc helper semantics relied upon by the fb helper
Yikes!

But yeah, we have to do this until someone volunteers to clean up the
fb helper and rid it of its incetious relationship with the crtc
helper code.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:01:31 +02:00
Daniel Vetter
2e43105183 drm/i915: extract intel_set_config_update_output_state
Note that this function already clobbers the mode config state,
so we have to clean things up if something fails.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:01:12 +02:00
Daniel Vetter
5e2b584ed1 drm/i915: extract intel_set_config_compute_mode_changes
This computes what exactly changed in the modeset configuration, i.e.
whether a full modeset is required or only an update of the
framebuffer base address or no change at all.

In the future we might add more checks for e.g. when only the output
mode changed, so that we could do a minimal modeset for outputs that
support this. Like the lvds/eDP panels where we only need to update
the panel fitter.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:01:07 +02:00
Daniel Vetter
85f9eb71fe drm/i915: extract modeset config save/restore code
At the end this won't be of much use to us, but meanwhile just extract
it to get a better overview of what exactly set_config does.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:00:51 +02:00
Daniel Vetter
d9e55608cd drm/i915: introduce struct intel_set_config
intel_crtc_set_config is an unwidly beast and is in serious need of
some function extraction. To facilitate that, introduce a struct to
keep track of all the state involved. Atm it doesn't do much more than
keep track of all the allocated memory.

v2: Apply some bikeshed to intel_set_config_free, as suggested by
Jesse Barnes.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:00:32 +02:00
Daniel Vetter
7fad798e16 drm/i915: ensure the force pipe A quirk is actually followed
Many BIOSen forget to turn on the pipe A after resume (because they
actually don't turn on anything), so we have to do that ourselves when
sanitizing the hw state.

I've discovered this due to the recent addition of a pipe WARN that
takes the force quirk into account.

v2: Actually try to enable the pipe with a proper configuration instead
of simpyl switching it on with whatever random state the bios left it
in after resume.

v3: Fixup rebase conflict - the load_detect functions have lost their
encoder argument.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:00:14 +02:00
Daniel Vetter
24e804ba97 drm/i915: rip out intel_dp->dpms_mode
We now track the connector state in encoder->connectors_active, and
because the DP output can't be cloned, that is sufficient to track the
link state. Hence use this instead of adding yet another modeset state
variable with dubious semantics at driver load and resume time.

Also, connectors_active should only ever be set when the encoder is
linked to a crtc, hence convert that crtc test into a WARN.

v2: Rebase on top of struct intel_dp moving.

v3: The rebase accidentally killed the newly-introduced intel_dp->port
Noticed by Paulo Zanoni.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:00:05 +02:00
Daniel Vetter
84bb65bded drm/i915: rip out intel_crtc->dpms_mode
Afaict this has been used for two things:
- To prevent the crtc enable code from being run twice. We have now
  intel_crtc->active to track this in a more precise way.
- To ensure the code copes correctly with the unknown hw state after
  boot and resume. Thanks to the hw state readout and sanitize code we
  have now a better way to handle this.

The only thing it still does is complicate our modeset state space.

Having outlived its usefullness, let it just die.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 08:00:00 +02:00
Daniel Vetter
0a91ca2921 drm/i915: check connector hw/sw state
Atm we can only check the connector state after a dpms call - while
doing modeset with the copy&pasted crtc helper code things are too
ill-defined for proper checking. But the idea is very much to call
this check from the modeset code, too.

v2: Fix dpms check and don't presume that if the hw isn't on that it
must not be linked up with an encoder (it could simply be switched off
with the dpms state).

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:59:42 +02:00
Daniel Vetter
2492935248 drm/i915: read out the modeset hw state at load and resume time
... instead of resetting a few things and hoping that this will work
out.

To properly disable the output pipelines at the initial modeset after
resume or boot up we need to have an accurate picture of which outputs
are enabled and connected to which crtcs. Otherwise we risk disabling
things at the wrong time, which can lead to hangs (or at least royally
confused panels), both requiring a walk to the reset button to fix.

Hence read out the hw state with the freshly introduce get_hw_state
functions and then sanitize it afterwards.

For a full modeset readout (which would allow us to avoid the initial
modeset at boot up) a few things are still missing:
- Reading out the mode from the pipe, especially the dotclock
  computation is quite some fun.
- Reading out the parameters for the stolen memory framebuffer and
  wrapping it up.
- Reading out the pch pll connections - luckily the disable code
  simply bails out if the crtc doesn't have a pch pll attached (even
  for configurations that would need one).

This patch here turned up tons of smelly stuff around resume: We
restore tons of register in seemingly random way (well, not quite, but
we're not too careful either), which leaves the hw in a rather
ill-defined state: E.g. the port registers are sometimes
unconditionally restore (lvds, crt), leaving us with an active
encoder/connector but no active pipe connected to it. Luckily the hw
state sanitizer detects this madness and fixes things up a bit.

v2: When checking whether an encoder with active connectors has a crtc
wire up to it, check for both the crtc _and_ it's active state.

v3:
- Extract intel_sanitize_encoder.
- Manually disable active encoders without an active pipe.

v4: Correclty fix up the pipe<->plane mapping on machines where we
switch pipes/planes. Noticed by Chris Wilson, who also provided the
fixup.

v5: Spelling fix in a comment, noticed by Paulo Zanoni

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:59:24 +02:00
Daniel Vetter
732ce74f4a drm/i915/dvo: implement get_hw_state
Similar to the sdvo code we poke the dvo encoder whether the output is
active. Safe that dvo encoders are not standardized, so this requires
a new callback into the dvo chip driver.

Hence implement that for all 6 dvo drivers.

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

Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:58:52 +02:00
Daniel Vetter
4ac41f47f8 drm/i915/sdvo: implement get_hw_state
SDVO is the first real special case - we support multiple outputs on
the same encoder and the encoder dpms state isn't the same as when
just disabling the outputs when the encoder is cloned.

Hence we need a real connector get_hw_state function which inquires
the sdvo encoder about its active outputs.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:58:47 +02:00
Daniel Vetter
e403fc941a drm/i915/crt: implement get_hw_state
Note that even though this connector is cloneable we still can use the
exact same test to check whether the connector is on or whether the
encoder is enabled - both the dpms code and the encoder disable/enable
frob the exact same hw state.

For dvo/sdvo outputs, this will be different.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:58:37 +02:00
Daniel Vetter
b1dc332c4d drm/i915/lvds: implement get_hw_state
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:58:33 +02:00
Daniel Vetter
9a8ee983e0 drm/i915/tv: implement get_hw_state
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:58:28 +02:00
Daniel Vetter
85234cdc28 drm/i915/hdmi: implement get_hw_state
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:58:22 +02:00
Daniel Vetter
19d8fe1544 drm/i915/dp: implement get_hw_state
Also add some macros to make the pipe computation a bit easier.

v2: I've mixed up the CPT and !CPT PORT_TO_PIPE macro variants ...

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:58:18 +02:00
Daniel Vetter
f0947c376f drm/i915: Add interfaces to read out encoder/connector hw state
It is all glorious if we try really hard to only enable/disable an
entire display pipe to ensure that everyting happens in the right
order. But if we don't know the output configuration when the driver
takes over, this will all be for vain because we'll make the hw angry
right on the first modeset - we don't know what outputs/ports are
enabled and hence have to disable everything in a rather ad-hoc way.

Hence we need to be able to read out the current hw state, so that we
can properly tear down the current hw state on the first modeset.
Obviously this is also a nice preparation for the fastboot work, where
we try to avoid the modeset on driver load if it matches what the hw
is currently using.

Furthermore we'll be using these functions to cross-check the actual
hw state with what we think it should be, to ensure that the modeset
state machine actually works as advertised.

This patch only contains the interface definitions and a little helper
for the simple case where we have a 1:1 encoder to connector mapping.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:57:51 +02:00
Daniel Vetter
08a4846969 drm/i915: WARN when trying to enabled an unused crtc
This is the first tiny step towards cross-checking the entire modeset
state machine with WARNs. A crtc can only be enabled when it's
actually in use, i.e. crtc->active imlies crtc->enabled.

Unfortunately we can't (yet) check this when disabling the crtc,
because the crtc helpers are a bit slopy with updating state and
unconditionally update crtc->enabled before changing the hw state.

Fixing that requires quite some more work.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:57:45 +02:00
Daniel Vetter
dbf2b54e78 drm/i915: call crtc functions directly
Instead of going through the crtc helper function tables.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:57:40 +02:00
Daniel Vetter
c9deac9776 drm/i915: rip out encoder->prepare/commit
With the new infrastructure we're doing this when enabling/disabling
the entire display pipe.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:57:19 +02:00
Daniel Vetter
821112aa41 drm/i915: simplify intel_crtc_prepare_encoders
- We don't have the ->get_crtc callback.
- Call intel_encoder->disable directly.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:57:03 +02:00
Daniel Vetter
a6778b3cfd drm/i915: copy&paste drm_crtc_helper_set_mode
Together with the static helper functions drm_crtc_prepare_encoders
and drm_encoder_disable (which will be simplified in the next patch,
but for now are 1:1 copies). Again, no changes beside new names for
these functions.

Also call our new set_mode instead of the crtc helper one now in all
the places we've done so far.

v2: Call the function just intel_set_mode to better differentia it
from intel_crtc_mode_set which really only does the ->mode_set step of
the entire modeset sequence on one crtc. Whereas this function does
the global change.

Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:56:54 +02:00
Daniel Vetter
6d832d189b drm/i915: inline intel_best_encoder
Also kill the error-path, we have a fixed connector->encoder mapping.

Unfortunately we can't rip out all the ->best_encoder callbacks, these
are all still used by the fb_helper. Neat helper layering violation there.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:56:35 +02:00
Daniel Vetter
4f660f49b9 drm/i915: call set_base directly
And drop the check, we always have it.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:56:11 +02:00
Daniel Vetter
50f56119ef drm/i915: copy&paste drm_crtc_helper_set_config
And the following static functions required by it:
drm_encoder_crtc_ok, drm_crtc_helper_disable

No changes safe for the s/drm/intel prefix change.

Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06 07:56:00 +02:00