Commit Graph

235733 Commits

Author SHA1 Message Date
Rodrigo Vivi
a0fcbd9535 drm/i915: Add IS_BDW_GT3 macro.
It will be usefull to specify w/a that affects only BDW GT3.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-30 09:18:58 +02:00
Rodrigo Vivi
ad9dc91b6e drm/i915: Fix Sink CRC
In some cases like when PSR just got enabled the panel need more vblank
times to calculate CRC. I figured that out with the new PSR test cases
facing some cases that I had a green screen but a blank CRC. Even with
2 vblank waits on kernel + 2 vblank waits on test case.

So let's give up to 6 vblank wait time. However we now check for
TEST_CRC_COUNT that shows when panel finished to calculate CRC and
has it ready.

v2: Jani pointed out attempts decrements was wrong and should never reach
the error condition. And Daniel pointed out that EIO is more appropriated than
EGAIN. Also I realized that I have to read test_crc_count after setting
test_sink

v3: Rebase and adding error message

Cc: Todd Previte <tprevite@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-30 09:18:37 +02:00
Rodrigo Vivi
6805b2a743 drm/i915: Broadwell DDI Buffer translation - more tuning
BDW display - DP buffer translation values changed to give better margin.

Further change to entry 6; set dword 0 bit 31=1.

Both changes were approved already but this one didn't landed BSpec yet
this is why it is in a separated patch. Making reviewer's life easier.
Also alowing separated tests and any future bisect that might be needed.

Reference: Predator r74080 / HSD 4394389

v2: Arthur noticed I was changing the wrong bit.

Cc: Arthur Runyan <arthur.j.runyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Arthur Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-29 14:49:35 +02:00
Rodrigo Vivi
17b523ba5c drm/i915: Broadwell DDI Buffer translation changed to give better margin.
Reference: Predator r73977 / HSD 4394389

Cc: Arthur Runyan <arthur.j.runyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Arthur Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-29 14:49:19 +02:00
Rodrigo Vivi
8d7f4fe9f5 drm/i915: Make sure PSR is ready for been re-enabled.
Let's make sure PSR is propperly disabled before to re-enabled it.

According to Spec, after disabled PSR CTL, the Idle state might occur
up to 24ms, that is one full frame time (1/refresh rate),
plus SRD exit training time (max of 6ms),
plus SRD aux channel handshake (max of 1.5ms).

So if something went wrong PSR will be disabled until next full
enable/disable setup.

v2: The 24ms above takes in account 16ms for refresh rate on 60Hz mode. However
on low frequency modes this can take longer. So let's use 50ms for safeness.

v3: Move wait out of psr.lock critical area.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-29 14:21:49 +02:00
Rodrigo Vivi
1d73c2a8f2 drm/i915: Minimize the huge amount of unecessary fbc sw cache clean.
The sw cache clean on BDW is a tempoorary workaround because we cannot
set cache clean on blt ring with risk of hungs. So we are doing the cache clean on sw.
However we are doing much more than needed. Not only when using blt ring.
So, with this extra w/a we minimize the ammount of cache cleans and call it only
on same cases that it was being called on gen7.

The traditional FBC Cache clean happens over LRI on BLT ring when there is a
frontbuffer touch happening. frontbuffer tracking set fbc_dirty variable
to let BLT flush that it must clean FBC cache.

fbc.need_sw_cache_clean works in the opposite information direction
of ring->fbc_dirty telling software on frontbuffer tracking to perform
the cache clean on sw side.

v2: Clean it a little bit and fully check for Broadwell instead of gen8.

v3: Rebase after frontbuffer organization.

v4: Wiggle confused me. So fixing v3!

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-29 14:17:31 +02:00
Rodrigo Vivi
7ca5a41f4d drm/i915: Avoid re-configure panel on every PSR re-enable.
The panel has to be reconfigured only when it really loose the power.
The traditional enable/disable sequence already take care of this so we can
minimize the time spend on every re-enable.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-24 21:00:46 +02:00
Rodrigo Vivi
0aa4878397 drm/i915: PSR: Organize PSR enable function
We don't need to setup everything else if it doesn't match all conditions.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-24 10:37:00 +02:00
Rodrigo Vivi
ba80f4d426 drm/i915: PSR: organize setup function.
psr_enabled is already by itself a setup once so let's put the W/As there and
rename old setup once to setup_vsc.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-24 10:36:31 +02:00
Paulo Zanoni
9adccc6063 drm/i915: add SW tracking to FBC enabling
Currently, calling intel_fbc_enabled() will trigger a register read.
And we call it a lot of times, even when FBC is disabled, so saving a
few cycles would be a good thing.

Another reason for this patch is because we currently call
intel_fbc_enabled() while the HW is runtime suspended, so the read
makes no sense and triggers a WARN. This happens even if FBC is
disabled by default. Of course one could argue that we just shouldn't
be calling intel_fbc_enabled() while the driver is runtime suspended,
and I agree that's a good argument, but I still think that the reason
explained in the first paragraph already justifies the patch.
This problem can easily be reproduced with many subtests of
igt/pm_rpm, and it is a regression introduced by:

    commit c5ad011d7d
    Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Date:   Mon Aug 4 03:51:38 2014 -0700
        drm/i915: FBC flush nuke for BDW

Testcase: igt/pm_rpm/cursor (and others)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-23 10:28:53 +02:00
Paulo Zanoni
d2dee86cec drm/i915: extract intel_init_fbc()
Because I plan to expand it a little bit.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-23 10:27:34 +02:00
Daniel Vetter
b680c37a4d drm/i915: DocBook integration for frontbuffer tracking
I shouldn't ask everyone to do this and fail myself ...

This extracts all the frontbuffer tracking functions into
intel_frontbuffer.c, adds a DOC overview section and also adds the
missing kerneldoc for i915_gem_track_fb and also pulls it into the
same section for convenience.

v2: Don't forget about the header files.

v3: Oops, might check compilation next time around. To make my life
easier drop the increase_pllclock from set_base_atomic since really,
it doesn't matter if you see your Oops or kgdb with a tiny bit of lag.

v4: Try to better explain how to actually use this, requested by Paulo
on irc.

v5: Explain invalidate/flush a bit clearer.

v6: s/business/busyness/

Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-09-19 19:46:49 +02:00
Chris Wilson
1893a71b1e drm/i915: Inline feature detection into sanitize_enable_ppgtt
Rather than splitting and hiding away critical parts of
sanitize_enable_ppgtt() into single use macros in the headers, inline
them into the function for clarity.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 17:58:42 +02:00
Brad Volkin
00caf0199f drm/i915: Log a message when rejecting LRM to OACONTROL
The other paths in the command parser that reject a batch all
log a message indicating the reason. We simply missed this one.

Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 17:56:20 +02:00
Brad Volkin
9beb0ccb66 drm/i915: Re-enable the command parser when using PPGTT
In commit

commit 896ab1a5d5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 6 15:04:51 2014 +0200

    drm/i915: Fix up checks for aliasing ppgtt

it looks like we accidentally inverted the check that the command
parser should only run when the driver enables some form of PPGTT.

Testcase: igt/gem_exec_parse
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Also drop the comment right above, all production vlv now
have hw ppgtt enabled.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 17:53:58 +02:00
Daniel Vetter
9d533c5a52 drm/i915: Update DRIVER_DATE to 20140919
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 17:07:10 +02:00
Deepak S
5cb13c07da drm/i915/vlv: Remove check for Old Ack during forcewake
Based on the HW team inputs. We can should not wait for the old ack,
Waiting for old ack might fail, when other forcewake came before the
present one is desserted.

for example, if forcewake bit 0 was set and before it could get cleared
forcewake bit 1 got set, HW eventually clear bit 0, when the bit 1
is cleared. i.e, bit 1 is still sent then forcewake bit 0 will still be
set.

Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add comment Ville requested.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:25 +02:00
Rodrigo Vivi
342e36c6b0 drm/i915: Avoid reading fbc registers in vain when fbc was never enabled.
If it wasn't never enabled by kernel parameter or platform default
we can avoid reading registers so many times in vain

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:24 +02:00
Rodrigo Vivi
01d06e9f96 drm/i915: Only flush fbc on sw when fbc is enabled.
Avoid touching fbc register when fbc is disabled.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:23 +02:00
Daniel Vetter
24955f2412 drm/i915: Clarify mmio_flip_lock locking
The ->queue_flip callback is always called from process context, so
plain _irq spinlock variants are enough.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:23 +02:00
Daniel Vetter
d2e40e2741 drm/i915: Clarify uncore.lock locking
Only one place looked in need of a bit of polish: hsw_restore_lcpll.
It's used by the runtime pm code and hence is always called from
process context. No irq flag saving required.

Another thing I've stumbled over is that we might need to add a
raw forcewake_get/put helpers which don't grab a runtime pm reference
but just check that the device isn't suspended - we have this duplicated
in the execlist code, too.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:22 +02:00
Daniel Vetter
133217869e drm/i915: Clarify irq_lock locking, special cases
Grab bag for all the special cases:
- i9xx_check_fifo_underruns is only called from crtc_enable hooks,
  i.e. process context.
- i915_enable_asle_pipestat is only called from interrupt postinstall
  hooks. So again process context.
- gen8_irq_power_well_post_enable is called from the runtime pm code,
  which again means process context.
- The open-coded hpd_irq_setup loop in _thaw is also running in process
  context.

So for all of them the plain _irq variant is sufficient.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:21 +02:00
Daniel Vetter
222c7f51b0 drm/i915: Clarify irq_lock locking, irq handlers
irq handlers always run with interrupts locally disabled, so
plain spinlocks is all we need. I've also reviewed again that they
all follow the _irq_handler postfix convention.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:21 +02:00
Daniel Vetter
d62074358d drm/i915: Clarify irq_lock locking, interrupt install/uninstall
All the interrupt setup/teardown hooks are always run from plain
process context. So again just the _irq variant is good enough.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:20 +02:00
Daniel Vetter
4cb2183228 drm/i915: Clarify irq_lock locking, work functions
Work functions are in process context, so plain _irq spinlock variants
is all we need.

The hpd reenable work didn't follow the _work/_work_func postfix
naming scheme, so adjust that while at it.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:20 +02:00
Daniel Vetter
2795aa4864 drm/i915: Clarify irq_lock locking, intel_tv_detect
->detect callbacks are only ever called from process context, and
there's no fancy nesting going on here. So plain _irq spinlock
variants is what we want.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:19 +02:00
Daniel Vetter
5b254c5978 drm/i915: Clarify gpu_error.lock locking
i915_capture_error_state can be called from all kinds of contexts, so
needs the full irqsave dance. But the other two places to grab and
release the error state are only called from process context. So
simplify them to the plaine _irq spinlock versions to clarify the
locking semantics.

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:18 +02:00
Daniel Vetter
f326038a29 drm/i915: Clarify event_lock locking, irq&mixed context
Now we tackle the functions also called from interrupt handlers.

- intel_check_page_flip is exclusively called from irq handlers, so a
  plain spin_lock is all we need. In i915_irq.c we have the convention
  to give all such functions an _irq_handler postfix, but that would
  look strange and als be a bit a misleading name. I've opted for a
  WARN_ON(!in_irq()) instead.

- The other two places left are called both from interrupt handlers
  and from our reset work, so need the full irqsave dance. Annotate
  them with a short comment.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:18 +02:00
Daniel Vetter
5e2d7afcfe drm/i915: Clarify event_lock locking, process context
It's good practice to use the more specific versions for irq save
spinlocks both as executable documentation and to enforce saner
design. The _irqsave version really should only be used if the calling
context is unknown and there's a good reason to call a function from
all kinds of places.

This is the first step whice replaces all occurances of _irqsave in
process context with the simpler irq disable/enable variants. We don't
have any funky spinlock nesting going on, especially since the
event_lock is the outermost of the irq/vblank related spinlocks.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:17 +02:00
Ville Syrjälä
4b3a9526fc drm/i915: Move vblank enable earlier and disable later
We changed to an interrupt based vblank wait (as opposed to polling)
in:
 commit 44bd93a3d367913d883be6abba9a6e51a53c4e90
 Author: Daniel Vetter <daniel.vetter@ffwll.ch>
 Date:   Fri Jul 25 23:36:44 2014 +0200

    drm/i915: Use generic vblank wait

However we already had vblank waits on the wrong side of
drm_vblank_{on,off}() calls due to various workarounds, so now we get
a warning more or less every time we do a modeset, and we fail to
wait for the vblank like we should.

Move the drm_vblank_{on,off}() calls back out from
intel_crtc_{enable,disable}_planes() so that all of these vblank waits
return to proper operation. Also move the cxsr wait a bit earlier so
that we can keep the encoder disable after we've turned off vblanks.
Moving stuff out from the plane enable/disable functions seems
preferrable to moving the workaround stuff in since the workarounds are
required only on specific platforms.

While at it switch over to the drm_crtc_ variants of the vblank on/off
functions.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82525
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82490
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:16 +02:00
Daniel Vetter
4f905cf97f drm/i915: static inline for intel_wait_for_vblank
Requested by Chris, and also requested to keep it since it's a
more accurate name in his opinion.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:16 +02:00
Daniel Vetter
51e31d49c8 drm/i915: Use generic vblank wait
This has the upside that it will no longer steal interrupts from the
interrupt handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.

v2: Adjust to the new names.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:15 +02:00
Daniel Vetter
07f11d49f1 drm/i915: Convert backlight_lock to a mutex
Originally the irq safe spinlock was required because of asle
interrupts. But since

commit 91a60f2071
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Oct 31 18:55:48 2013 +0200

    drm/i915: move opregion asle request handling to a work queue

there's no need for this any more. So switch to the simpler mutex.

v2: Cite the right commit, spotted by Jani.

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:15 +02:00
Jani Nikula
4dc49272bd drm/i915/bios: add missing __packed to structs used for reading vbt
This does not seem to make a difference for the structs in question, but
document the intent.

v2: also pack union child_device_config (Daniel)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:14 +02:00
Daniel Vetter
7cd512f152 drm/i915: Fix irq checks in ring->irq_get/put functions
Yet another place that wasn't properly transformed when implementing
SOix. While at it convert the checks to WARN_ON on gen5+ (since we
don't have UMS potentially doing stupid things on those platforms).
And also add the corresponding checks to the put functions (again with
a WARN_ON) for gen5+.

v2: Drop the WARNINGS in the irq_put functions (including the existing
one for vebox), Chris convinced me that they're not that terribly
useful.

v3: Don't forget about execlist code.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-09-19 14:43:13 +02:00
Imre Deak
950eabaf5a drm/i915: vlv: fix display IRQ enable/disable
We want to enable/disable display IRQs only if global i915 IRQs are
enabled. To check the latter it's not enough to consult the DRM
dev->irq_enabled flag, since runtime PM can disable/enable IRQs
and it won't adjust this flag only the i915 specific
dev_priv->pm._irqs_disabled flag. Fix this by using the proper
intel_irqs_enabled() helper instead.

Fortunately this didn't cause an actual problem since even if we enabled
display IRQs too early (before enabling global i915 IRQs) the
VLV_MASTER_IER would still be clear masking all IRQs.

This issue was caught by

commit 920dd15a2b2fc60d054646a8a1ffd6aeb6090e05
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 27 10:43:37 2014 +0200

    drm/i915: WARN if interrupts aren't on in en/disable_pipestat

Signed-off-by: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:13 +02:00
Ville Syrjälä
47bf17a7d1 drm/i915: Only set CURSOR_PIPE_CSC_ENABLE when cursor is enabled
It seems cleaner if we keep CURCNTR at 0 when the cursor is disabled,
so don't set the CURSOR_PIPE_CSC_ENABLE bit unless the cursor is
enabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:12 +02:00
Ville Syrjälä
99d1f3878b drm/i915: Move the cursor_base setup to i{845, 9xx}_update_cursor()
To make the code a bit more undestandable move the
intel_crtc->cursor_base assignment into the low level update cursor
routines. That's were we compare the current value with the new one
so immediately seeing that it gets assigned only afterwards helps
one to understand that it gets assigned only after the comparison.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:12 +02:00
Daniel Vetter
f77c44b902 agp/intel-gtt: Remove get/put_pages
If a page isn't allocated as __GFP_MOVEABLE it won't move around, so
no need to grab a reference to lock it into place.

Discovered while reviewing page allocation handling in i915 gem.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-09-19 14:43:11 +02:00
Daniel Vetter
c04d016124 drm/i915: Drop get/put_pages for scratch page
While discussing/reviewing __GFP_MOVEABLE behaviour and interactions
with our various page allocations on irc Chris brought up that the
scratch page isn't allocated as moveable, but we still grab/put a
reference to lock it in place. Which is unecessary.

So drop that.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-09-19 14:43:10 +02:00
Gustavo Padovan
e259f172ad drm/i915: Fix regression in the sprite plane update split
7e4bf45dbd99a965c7b5d5944c6dc4246f171eb5 introduced the regression.
We fix it by doing the right assignment of crtc_y

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83747
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:10 +02:00
Chris Wilson
be2d599b5d drm/i915: Remove dead code, i915_gem_verify_gtt
The data structure it was supposed to be sanity checking has long gone.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:09 +02:00
Gustavo Padovan
e30e8f7536 drm/i915: create intel_update_pipe_size()
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.

This will help refactor the update primary plane path.

v2: use struct intel_crtc as argument to intel_update_pipe_size()

v3: use 'crtc' as argument name

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:08 +02:00
Gustavo Padovan
25067bfc06 drm/i915: pin sprite fb only if it changed
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.

v2: take Ville's comments
	- move comment along with the pin_and_fence call
	- check for error before calling i915_gem_track_fb
	- move old_obj != obj to an upper if condition

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:08 +02:00
Gustavo Padovan
94f598f176 drm/i915: remove !enabled handling from commit primary plane step
The !crtc->enabled case will now be handled by the !visible code,
since the handling is basically the same.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:07 +02:00
Daniel Vetter
2363d8c97f drm/i915: Restore resume irq ordering comment
This was lost in

commit e11aa36230
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Jun 18 09:52:55 2014 -0700

    drm/i915: use runtime irq suspend/resume in freeze/thaw

which makes the second part of this commen a bit nonsense. Both were
originally added in

commit 15239099d7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Mar 5 09:50:58 2013 +0100

    drm/i915: enable irqs earlier when resuming

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:07 +02:00
Gustavo Padovan
3c692a4162 drm/i915: split intel_primary_plane_setplane() into check() and commit()
As a preparation for atomic updates we need to split the code to check
everything we are going to commit first. This patch starts the work to
split intel_primary_plane_setplane() into check() and commit() parts.

More work is expected on this to get a better split of the two steps.
Ideally the commit() step should never fail.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:06 +02:00
Gustavo Padovan
852e787c4c drm/i915: split intel_cursor_plane_update() into check() and commit()
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.

The commit part can still fail, but that should be solved in another
upcoming patch.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:05 +02:00
Gustavo Padovan
96d61a7f26 drm/i915: split intel_update_plane into check() and commit()
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.

This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning procedure.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:05 +02:00
Gustavo Padovan
eeca778a3e drm/i915: create struct intel_plane_state
This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-19 14:43:04 +02:00