Commit Graph

10861 Commits

Author SHA1 Message Date
Daniel Vetter
190d6cd5cd drm/i915: less magic for stolen preallocated objects w/o gtt offset
A magic -1 is a obscure, especially since it's actually passed as an
unsigned, so depends upon the magic sign extension rules in C. This has
been added in

commit 3727d55e4d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed May 8 10:45:14 2013 -0700

    drm/i915: allow stolen, pre-allocated objects to avoid GTT allocation v2

Use a proper #define instead. Spotted while reviewing Ben's
drm_mm_create_block changes.

v2: Cast the constant to u32 since otherwise we again have a type
mismatch. Suggested by Chris Wilson.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-05 23:56:18 +02:00
Daniel Vetter
d94ab06827 drm/i915: Explicitly cast pipe -> intel_dpll_id
We only do this on IBX where there's a fixed pch dpll to pipe
assignment. Being explicit about it can't really hurt and makes
sparse happy.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-05 23:47:09 +02:00
Daniel Vetter
e143a21c4d drm/i915: explicitly cast pipe -> cpu_transcoder
This makes sparse happy and also makes it a bit more obvious where we
pull off this trick - after all we're only allowed to do it eithe as a
default or on platforms where there is no disdinction between the pipe
and the cpu transcoder.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-05 23:47:08 +02:00
Ville Syrjälä
e8474409d7 drm/i915: Use wait_for() to wait for Punit to change GPU freq on VLV
Use wait_for() instead of the open coded loop to avoid spreading the
same old timeout related bugs.

This changes the loop to use msleep(1) instead of udelay(10) when the
Punit had not yet completed the frequency change. In practice that
doesn't seem to hurt performance as the Punit appears to be ready pretty
much always.

Also give the status bit a name, instead of using the magic number 1.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-02 15:40:23 +02:00
Jesse Barnes
510d5f2f6b drm/i915: split encoder get_config calls from crtc get_clock calls
This should help on HSW, where we don't currently have a get_clock call.

Reported-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-02 09:44:29 +02:00
Jesse Barnes
6f02488e3a drm/i915: fixup messages in pipe_config_compare
Print out the flag that failed and fix up a mismatched paren.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 19:39:56 +02:00
Mika Kuoppala
ef86ddced7 drm/i915: add error_state sysfs entry
As getting error state doesn't anymore require big kmallocs,
make error state accessible also from sysfs.

v2: - error state clearing (Chris Wilson)
    - user hint, proper access mode bits and name (Daniel Vetter)

v3: release resources in proper order (Chris Wilson)

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Apply Chris' s/error_state/error/ bikeshed on the sysfs
name. Also update the dmesg message, spotted by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 19:39:31 +02:00
Mika Kuoppala
4dc955f7f5 drm/i915: introduce i915_error_state_buf_init
Make function for struct i915_error_state_buf initialization
and export it, for sysfs and debugfs.

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>
2013-07-01 19:38:20 +02:00
Mika Kuoppala
95d5bfb3ac drm/i915: export error state ref handling
In preparation for sysfs error state access,
export ref error state ref counting interface.

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>
2013-07-01 19:38:19 +02:00
Mika Kuoppala
fc16b48be6 drm/i915: export error state to string conversion
In preparation for accessing error state from sysfs, export
error state to string conversion function. Also tuck buffer
error handling inside the function.

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>
2013-07-01 19:38:19 +02:00
Jesse Barnes
319d9827eb drm/i915: flip on a no fb -> fb transition if crtc is active v3
If the crtc is active, we can simply flip a new fb onto it, provided the
other mode setting reqs are met.  Otherwise, we'll need to do a full
mode set to re-enable the crtc.

v2: check for crtc active and set mode_changed accordingly
v3: add module parameter, i915.fastboot, to control no fb -> fb flip behavior

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 19:38:18 +02:00
Jesse Barnes
4d6a3e63bc drm/i915: turn off panel fitting at flip time if needed v2
Need better pfit tracking to do this right.

v2: use fastboot param around this hack

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 19:38:17 +02:00
Jesse Barnes
babea61dfb drm/i915: copy fetched mode state into crtc at setup_hw time v5
We already fetch and track other state into the main CRTC and encoder
structs, and for fastboot we need to do the same with the mode and clock
data we read out.

v2: fix debug print
v3: use fastboot param around state copy
v4: set clock and flags for crtc here instead of in setup_hw_state
v5: rename function to intel_crtc_mode_from_pipe_config for consistency (Chris)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 19:38:17 +02:00
Jesse Barnes
f1f644dc66 drm/i915: get mode clock when reading the pipe config v9
We need this for comparing modes between configuration changes.

The tricky part is to allow us to reuse the new get_clock stuff to
recover the lvds clock on gen2/3 when neither the vbt has an lvds mode
nor the panel a (useful) EDID.

v2: try harder to calulate non-simple pixel clocks (Daniel)
    call get_clock after getting the encoder config, needed for pixel multiply
    (Jesse)
v3: drop get_clock now that the pixel_multiply has been moved into
    get_pipe_config
v4: re-add get_clock; we need to get the pixel multiplier in the
    encoder, so need to calculate the clock value after the encoder's
    get_config is called
v5: drop hsw clock_get, still needs to be written
v6: add fuzzy clock check (Daniel)
v7: wrap fuzzy clock check under !IS_HASWELL
    use port_clock field rather than a new CPU eDP clock field in crtc_config
v8: remove stale pixel_multiplier sets (Daniel)
    multiply by pixel_multiplier in 9xx clock get too (Daniel)
v9: make sure we set pixel_multiplier before calling clock_get from mode_get
    for LVDS (Daniel)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add some explanation to the commit message about why we have
to jump through a few hoops. Also remove the rebase-fail hunk from
intel_sdvo.c]
[danvet: Squash in the fixup from Jesse to also call ->get_clock in
the modeset state checker.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 19:37:53 +02:00
Jesse Barnes
2385bdf078 drm/i915: add fastboot param for fast & loose mode setting
Handling all the state properly for fastboot is still not yet done by
far, but we need some way to be able to test what we currently have.
So hide the not-yet-quite-complete stuff behind a module option.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add a real commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:28:02 +02:00
Daniel Vetter
c93f54cf7d drm/i915: pixel multiplier readout support for pch ports
Now that we painstakingly track the shared pch dplls we can finally
implement pixel mutliplier readout support for pch ports, too.

v2: Undo the temporary hack to disable the sdvo pixel multiplier
cross-checking.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:28:01 +02:00
Ben Widawsky
911bdf0ae6 drm/i915: Move gtt_mtrr to i915_gtt
for file in `ls drivers/gpu/drm/i915/*.c` ; do
	sed -i "s/mm.gtt_mtrr/gtt.mtrr/" $file;
done

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:28:01 +02:00
Ben Widawsky
5c3fe8b03e drm/i915: Move fbc members out of line
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict with Damien's FBC_CHIP_DEFAULT no fbc
reason.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:28:00 +02:00
Ben Widawsky
b2f21b4dfd drm/i915: Use gtt shortform where possible
Just for compactness.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:59 +02:00
Ben Widawsky
80a74f7f9c drm/i915: Drop dev from pte_encode
The original pte_encode function needed the dev argument so we could do
platform specific handling via IS_GENX, etc. With the merging of a pte
encoding function there should never been a need to quirk away gen
specific details.

The patch doesn't do much but makes the upcoming reworks in gtt/ppgtt/mm
slightly (albeit, ever so) easier.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:59 +02:00
Ben Widawsky
6716724006 drm/i915: Combine scratch members into a struct
There isn't any special reason to do this other than it makes it obvious
that the two members are connected.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:58 +02:00
Ben Widawsky
84f1356058 drm/i915: Really share scratch page
A previous patch had set up the ppgtt and ggtt to use the same scratch
page, but still kept around both pointers. Kill it, it's not needed and
gets in our way for upcoming cleanups.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:57 +02:00
Ben Widawsky
6670a5a5c7 drm/i915: make PDE|PTE platform specific
Nothing outside of i915_gem_gtt.c and more specifically, the relevant
gen specific init function should need to know about number of PDEs, or
PTEs per PD. Exposing this will only lead to circumventing using the
upcoming VM abstraction.

To accomplish this, move the defines into the .c file, rename the PDE
define to be GEN6, and make the PTE count less of a magic number.

The remaining code in the global gtt setup is a bit messy, but an
upcoming patch will clean that one up.

v2: Don't hardcode number of PDEs (Daniel + Jesse)
Reworded commit message to reflect change.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:57 +02:00
Ben Widawsky
26b7c22465 drm/i915: Extract error buffer capture
This helps when we have per VM buffer capturing.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:56 +02:00
Ben Widawsky
5476f8505b drm/i915: Remove extra error state NULL
Not only was there an extra, but since we now kzalloc the error state,
we don't need either.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:56 +02:00
Ville Syrjälä
165e901caa drm/i915: Mask out hardware status bits from VLV DPLL register
The DPLL lock bit, and the DPIO phy status bits are read-only and
controlled by the hardware, so they will never be set by the driver.
Mask them out when reading the hw state, so that the state
comparison won't fail.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuosugeek.org>
[danvet: Jesse asked for a code comment and I wholeheartly agree, so
added one.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:55 +02:00
Daniel Vetter
f6736a1a7b drm/i915: s/pre_pll/pre/ on the lvds port enable function
i9xx doesn't use pre_enable at all, so we can fold this in now.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:54 +02:00
Daniel Vetter
66e3d5c099 drm/i915: move i9xx dpll enabling into crtc enable function
Now that we have the proper pipe config to track this, we don't need
to write any registers any more.

Note that for platforms without DPLL_MD (pre-gen4) which store the
pixel mutliplier in the DPLL register I've decided to keep the
seemingly "redundant" write: The comment right below saying "do this
trice for luck" doesn't instill confidence ...

v2: Drop a few now unnecessary local variables and switch the enable
function to take a struct intel_crtc * to simply arguments.

v3: Rebase on top of the newly-colored BUG_ON.

v4: Amend commit message to alliviate Imre's comment about the
redudant DPLL write for the pixel mutliplier.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:54 +02:00
Daniel Vetter
8bcc2795a6 drm/i915: hw state readout for i9xx dplls
In addition to existing stuff we also need to track DPLL_MD on gen4
and vlv. This is prep work so that we can move the dpll enable
sequence out from the ->mode_set callback into the crtc enabling
functions.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:53 +02:00
Daniel Vetter
952735ee41 drm/i915: move encoder pre enable hooks togther on ilk+
The ->pre_enable hook is only used for the cpu edp port on ilk-ivb, so
we can safely move it up across the fdi pll enabling.

Unfortunately we can't (yet) merge in the pre_pll enable hook despite
that only lvds uses it on ilk-ivb: Since the same lvds hook is also
need on i9xx platforms we need to fix up the pll enabling sequence
there, too.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:52 +02:00
Daniel Vetter
55607e8aaa drm/i915: asserts for lvds pre_enable
Lots of bangin my head against the wall^UExperiments have shown that
we really need to enable the lvds port before we enable plls. Strangely
that seems to include the fdi rx pll on the pch.

Note that the pch pll assert can fire since the lvds port has it's own
special clock source settings in the DPLL register, which means it
will never have a shared dpll (since there's only one LVDS port).

Anyway, encode this new evidence with a few nice WARNs.

v2: Incorporate review comments from Imre.
- Explain why lvds can't have a shared dpll.
- Update the WARN output.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:51 +02:00
Daniel Vetter
87442f732b drm/i915: duplicate intel_enable_pll into i9xx and vlv versions
Mostly since I _really_ don't want to touch the vlv hell.

No code change, just duplication. Also kill a now seriously outdated
code comment - the remark about the dvo encoder is now handled with
the pipe A quirk.

v2: Update the BUG_ONs as suggested by Jani (both in vlv_ and i9xx_
functions, since the split happens here).

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:51 +02:00
Daniel Vetter
b89a1d395b drm/i915: use sw tracked state to select shared dplls
Just yet another prep step to be able to do all this up-front, before
we've set up any of the shared dplls in the new state. This will
eventually be useful for atomic modesetting.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:50 +02:00
Daniel Vetter
15bdd4cff4 drm/i915: consolidate pch pll enable sequence
It's been splattered over 3 different places all doing random things.
Now we have (mostly) the same sequence as i8xx/i9xx, but all called
from the crtc_enable hook (through the pll->enable function):
- write new dividers
- enable vco and wait for stable clocks
- write again for the pixel mutliplier

I've left the seemingly random 200 usec delay in there, just in case.

Also move the encoder->pre_pll_enable hook into the crtc_enable
function, at the same spot we currently have a hack to enable the lvds
port. Since that hack is now redundant, kill it.

While doing this patch I've learned the hard way that we can only fire
up the LVDS port if both the pch dpll _and_ the fdi rc pll are not yet
enabled. Otherwise things go haywire, at least on cpt.

v2: It is paramount to write the FPx divisors before we enable the
the vco by writing to the DPLL registers, for otherwise the divisors
won't get updated. This is in line with the i8xx/i9xx dpll.

v3: To keep the nice abstraction add a ->mode_set callback to set the
divisors. Also streamline the enabling/disabling code a bit by
removing some cargo-cult duplication and clearing registers where
possible in the ->disable hook.

v4: Remove now unused local variable.

Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:49 +02:00
Damien Lespiau
3ef8fb5ae2 drm/i915: Bail out once we've found the context object
Once we've found the the context object programmed in CCID, there's no
need to look the other objects in the list.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:49 +02:00
Damien Lespiau
f4db9321a7 drm/i915: Fix a couple of "should it be static?" sparse warnings
A genuine 'static' omission and 2 other warnings triggered by not
including the header where those functions where defined.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:48 +02:00
Damien Lespiau
aee56cff33 drm/i915: Fix a few style issues found by checkpatch.pl
Missing spaces and misplaced '*'.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:47 +02:00
Damien Lespiau
267f0c90ac drm/i915: Use seq_puts/seq_putc when possible
Caught with checkpatch.pl.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:47 +02:00
Damien Lespiau
8a5729a373 drm/i915: Fix reason for per-chip disabling of FBC
When running on my snb machine, recent kernels display successively:

[drm:intel_update_fbc], fbc set to per-chip default
[drm:intel_update_fbc], fbc disabled per module param

But no module param is set. This happens because the check for the
module parameter uses a variable that has been overridden inside the
"per-chip default" code.

Fix up the logic and add another reason for the FBC to the be disabled.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:46 +02:00
Damien Lespiau
b63fb44c65 drm/i915: Make intel_enable_fbc() static
This function has no user outside of intel_pm.c.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:45 +02:00
Paulo Zanoni
6cdcb5e73f drm/i915: invert the verbosity of intel_enable_fbc
We currently print a DRM_DEBUG_KMS message on the happy path and don't
print anything on the "failed to allocate" path. On some desktop
environments (e.g., Unity) I see the "scheduling delayed FBC enable"
thousands and thousands of times on my dmesg.

So kill the useless message for the happy case, saving a lot of dmesg
space, and properly signal the "kzalloc fail" case.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:27:44 +02:00
Chris Wilson
baf27f9b17 drm/i915: Break up the large vsnprintf() in print_error_buffers()
So it appears that I have encountered some bogosity when trying to call
i915_error_printf() with many arguments from print_error_buffers(). The
symptom is that the vsnprintf parser tries to interpret an integer arg
as a character string, the resulting OOPS indicating stack corruption.
Replacing the single call with its 13 format specifiers and arguments
with multiple calls to i915_error_printf() worked fine. This patch goes
one step further and introduced i915_error_puts() to pass the strings
simply.

It may not fix the root cause, but it does prevent my box from dying and
I think helps make print_error_buffers() more friendly.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66077
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:15:01 +02:00
Chris Wilson
d26e3af842 drm/i915: Refactor the wait_rendering completion into a common routine
Harmonise the completion logic between the non-blocking and normal
wait_rendering paths, and move that logic into a common function.

In the process, we note that the last_write_seqno is by definition the
earlier of the two read/write seqnos and so all successful waits will
have passed the last_write_seqno. Therefore we can unconditionally clear
the write seqno and its domains in the completion logic.

v2: Add the missing ring parameter, because sometimes it is good to have
things compile.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:15:01 +02:00
Chris Wilson
daa13e1ca5 drm/i915: Only clear write-domains after a successful wait-seqno
In the introduction of the non-blocking wait, I cut'n'pasted the wait
completion code from normal locked path. Unfortunately, this neglected
that the normal path returned early if the wait returned early. The
result is that read-only waits may return whilst the GPU is still
writing to the bo.

Fixes regression from
commit 3236f57a01 [v3.7]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 24 09:35:09 2012 +0100

    drm/i915: Use a non-blocking wait for set-to-domain ioctl

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:15:00 +02:00
Xiong Zhang
63000ef656 drm/i915: correct intel_dp_get_config() function for DevCPT
On DevCPT, the control register for Transcoder DP Sync Polarity is
TRANS_DP_CTL, not DP_CTL.
Without this patch, Many call trace occur on CPT machine with DP monitor.
The call trace is like: *ERROR* mismatch in adjusted_mode.flags(expected X,found X)

v2: use intel-crtc to simple patch, suggested by Daniel.

Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
[danvet: Extend the encoder->get_config comment to specify that we now
also depend upon intel_encoder->base.crtc being correct. Also bikeshed
s/intel_crtc/crtc/.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65287
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:14:59 +02:00
Daniel Vetter
b5ea2d5681 drm/i915: fix hpd interrupt register locking
Our interrupt handler (in hardirq context) could race with the timer
(in softirq context), hence we need to hold the spinlock around the
call to ->hdp_irq_setup in intel_hpd_irq_handler, too.

But as an optimization (and more so to clarify things) we don't need
to do the irqsave/restore dance in the hardirq context.

Note also that on ilk+ the race isn't just against the hotplug
reenable timer, but also against the fifo underrun reporting. That one
also modifies the SDEIMR register (again protected by the same
dev_priv->irq_lock).

To lock things down again sprinkle a assert_spin_locked. But exclude
the functions touching SDEIMR for now, I want to extract them all into
a new helper function (like we do already for pipestate, display
interrupts and all the various gt interrupts).

v2: Add the missing 't' Egbert spotted in a comment.

v3: Actually fix the right misspelled comment (Paulo).

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:14:59 +02:00
Daniel Vetter
91d131d21e drm/i915: fold the no-irq check into intel_hpd_irq_handler
The usual pattern for our sub-function irq_handlers is that they check
for the no-irq case themselves. This results in more streamlined code
in the upper irq handlers.

v2: Rebase on top of the i965g/gm sdvo hpd fix.

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:14:58 +02:00
Daniel Vetter
5876fa0d9e drm/i915: fold the queue_work into intel_hpd_irq_handler
Everywhere the same.

Note that this patch leaves unnecessary braces behind, but the next
patch will kill those all anyway (including the if itself) so I've
figured I can keep the diff a bit smaller.

v2: Rebase on top of the i965g/gm sdvo hpd fix.

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:14:57 +02:00
Daniel Vetter
10a504de56 drm/i915: fold the hpd_irq_setup call into intel_hpd_irq_handler
We already have a vfunc for this (and other parts of the hpd storm
handling code already use it).

v2: Rebase on top of the i965g/gm sdvo hpd fix.

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:14:57 +02:00
Daniel Vetter
22062dbacf drm/i915: s/hotplug_irq_storm_detect/intel_hpd_irq_handler/
The combination of Paulo's fifo underrun detection code and Egbert's
hpd storm handling code unfortunately made the hpd storm handling code
racy.

To avoid duplicating tricky interrupt locking code over all platforms
start with a bit of refactoring. This patch is the very first step
since in the end the irq storm handling code will handle all hotplug
logic (and so also encapsulate the locking nicely).

v2: Rebase on top of the i965g/gm sdvo hpd fix.

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01 11:14:56 +02:00