Oscar Mateo [Thu, 24 Jul 2014 16:04:22 +0000 (17:04 +0100)]
drm/i915/bdw: Skeleton for the new logical rings submission path
Execlists are indeed a brave new world with respect to workload
submission to the GPU.
In previous version of these series, I have tried to impact the
legacy ringbuffer submission path as little as possible (mostly,
passing the context around and using the correct ringbuffer when I
needed one) but Daniel is afraid (probably with a reason) that
these changes and, especially, future ones, will end up breaking
older gens.
This commit and some others coming next will try to limit the
damage by creating an alternative path for workload submission.
The first step is here: laying out a new ring init/fini.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:21 +0000 (17:04 +0100)]
drm/i915: Abstract the legacy workload submission mechanism away
As suggested by Daniel Vetter. The idea, in subsequent patches, is to
provide an alternative to these vfuncs for the Execlists submission
mechanism.
v2: Splitted into two and reordered to illustrate our intentions, instead
of showing it off. Also, remove the add_request vfunc and added the
stop_ring one.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet:
- Make checkpatch happy.
- Be grumpy about the excessive vtable.
- Ditch gt->is_ring_initialized.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:18 +0000 (17:04 +0100)]
drm/i915/bdw: Deferred creation of user-created LRCs
The backing objects and ringbuffers for contexts created via open
fd are actually empty until the user starts sending execbuffers to
them. At that point, we allocate & populate them. We do this because,
at create time, we really don't know which engine is going to be used
with the context later on (and we don't want to waste memory on
objects that we might never use).
v2: As contexts created via ioctl can only be used with the render
ring, we have enough information to allocate & populate them right
away.
v3: Defer the creation always, even with ioctl-created contexts, as
requested by Daniel Vetter.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:17 +0000 (17:04 +0100)]
drm/i915/bdw: Populate LR contexts (somewhat)
For the most part, logical ring context objects are similar to hardware
contexts in that the backing object is meant to be opaque. There are
some exceptions where we need to poke certain offsets of the object for
initialization, updating the tail pointer or updating the PDPs.
For our basic execlist implementation we'll only need our PPGTT PDs,
and ringbuffer addresses in order to set up the context. With previous
patches, we have both, so start prepping the context to be load.
Before running a context for the first time you must populate some
fields in the context object. These fields begin 1 PAGE + LRCA, ie. the
first page (in 0 based counting) of the context image. These same
fields will be read and written to as contexts are saved and restored
once the system is up and running.
Many of these fields are completely reused from previous global
registers: ringbuffer head/tail/control, context control matches some
previous MI_SET_CONTEXT flags, and page directories. There are other
fields which we don't touch which we may want in the future.
v2: CTX_LRI_HEADER_0 is MI_LOAD_REGISTER_IMM(14) for render and (11)
for other engines.
v3: Several rebases and general changes to the code.
v4: Squash with "Extract LR context object populating"
Also, Damien's review comments:
- Set the Force Posted bit on the LRI header, as the BSpec suggest we do.
- Prevent warning when compiling a 32-bits kernel without HIGHMEM64.
- Add a clarifying comment to the context population code.
v5: Damien's review comments:
- The third MI_LOAD_REGISTER_IMM in the context does not set Force Posted.
- Remove dead code.
v6: Add a note about the (presumed) differences between BDW and CHV state
contexts. Also, Brad's review comments:
- Use the _MASKED_BIT_ENABLE, upper_32_bits and lower_32_bits macros.
- Be less magical about how we set the ring size in the context.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> (v2) Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 11 Aug 2014 14:17:44 +0000 (16:17 +0200)]
drm/i915/bdw: Add a context and an engine pointers to the ringbuffer
Any given ringbuffer is unequivocally tied to one context and one engine.
By setting the appropriate pointers to them, the ringbuffer struct holds
all the infromation you might need to submit a workload for processing,
Execlists style.
v2: Drop ring->ctx since that looks terribly ill-defined for legacy
ringbuffer submission.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> (v1) Acked-by: Damien Lespiau <damien.lespiau@intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:15 +0000 (17:04 +0100)]
drm/i915/bdw: Allocate ringbuffers for Logical Ring Contexts
As we have said a couple of times by now, logical ring contexts have
their own ringbuffers: not only the backing pages, but the whole
management struct.
In a previous version of the series, this was achieved with two separate
patches:
drm/i915/bdw: Allocate ringbuffer backing objects for default global LRC
drm/i915/bdw: Allocate ringbuffer for user-created LRCs
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:14 +0000 (17:04 +0100)]
drm/i915/bdw: A bit more advanced LR context alloc/free
Now that we have the ability to allocate our own context backing objects
and we have multiplexed one of them per engine inside the context structs,
we can finally allocate and free them correctly.
Regarding the context size, reading the register to calculate the sizes
can work, I think, however the docs are very clear about the actual
context sizes on GEN8, so just hardcode that and use it.
v2: Rebased on top of the Full PPGTT series. It is important to notice
that at this point we have one global default context per engine, all
of them using the aliasing PPGTT (as opposed to the single global
default context we have with legacy HW contexts).
v3:
- Go back to one single global default context, this time with multiple
backing objects inside.
- Use different context sizes for non-render engines, as suggested by
Damien (still hardcoded, since the information about the context size
registers in the BSpec is, well, *lacking*).
- Render ctx size is 20 (or 19) pages, but not 21 (caught by Damien).
- Move default context backing object creation to intel_init_ring (so
that we don't waste memory in rings that might not get initialized).
v4:
- Reuse the HW legacy context init/fini.
- Create a separate free function.
- Rename the functions with an intel_ preffix.
v5: Several rebases to account for the changes in the previous patches.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:13 +0000 (17:04 +0100)]
drm/i915/bdw: Introduce one context backing object per engine
A context backing object only makes sense for a given engine (because
it holds state data specific to that engine).
In legacy ringbuffer sumission mode, the only MI_SET_CONTEXT we really
perform is for the render engine, so one backing object is all we nee.
With Execlists, however, we need backing objects for every engine, as
contexts become the only way to submit workloads to the GPU. To tackle
this problem, we multiplex the context struct to contain <no-of-engines>
objects.
Originally, I colored this code by instantiating one new context for
every engine I wanted to use, but this change suggested by Brad Volkin
makes it more elegant.
v2: Leave the old backing object pointer behind. Daniel Vetter suggested
using a union, but it makes more sense to keep rcs_state as a NULL
pointer behind, to make sure no one uses it incorrectly when Execlists
are enabled, similar to what he suggested for ring->buffer (Rusty's API
level 5).
v3: Use the name "state" instead of the too-generic "obj", so that it
mirrors the name choice for the legacy rcs_state.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:12 +0000 (17:04 +0100)]
drm/i915/bdw: Initialization for Logical Ring Contexts
For the moment this is just a placeholder, but it shows one of the
main differences between the good ol' HW contexts and the shiny
new Logical Ring Contexts: LR contexts allocate and free their
own backing objects. Another difference is that the allocation is
deferred (as the create function name suggests), but that does not
happen in this patch yet, because for the moment we are only dealing
with the default context.
Early in the series we had our own gen8_gem_context_init/fini
functions, but the truth is they now look almost the same as the
legacy hw context init/fini functions. We can always split them
later if this ceases to be the case.
Also, we do not fall back to legacy ringbuffers when logical ring
context initialization fails (not very likely to happen and, even
if it does, hw contexts would probably fail as well).
v2: Daniel says "explain, do not showcase".
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: s/BUG_ON/WARN_ON/.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:11 +0000 (17:04 +0100)]
drm/i915/bdw: Macro for LRCs and module option for Execlists
GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts".
These expanded contexts enable a number of new abilities, especially
"Execlists".
The macro is defined to off until we have things in place to hope to
work.
v2: Rename "advanced contexts" to the more correct "logical ring
contexts".
v3: Add a module parameter to enable execlists. Execlist are relatively
new, and so it'd be wise to be able to switch back to ring submission
to debug subtle problems that will inevitably arise.
v4: Add an intel_enable_execlists function.
v5: Sanitize early, as suggested by Daniel. Remove lrc_enabled.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v3) Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> (v2, v4 & v5) Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oscar Mateo [Thu, 24 Jul 2014 16:04:10 +0000 (17:04 +0100)]
drm/i915/bdw: New source and header file for LRs, LRCs and Execlists
Some legacy HW context code assumptions don't make sense for this new
submission method, so we will place this stuff in a separate file.
Note for reviewers: I've carefully considered the best name for this file
and this was my best option (other possibilities were intel_lr_context.c
or intel_execlist.c). I am open to a certain bikeshedding on this matter,
anyway.
And some point in time, it would be a good idea to split intel_lrc.c/.h
even further, but for the moment just shove everything together.
v2: Change to intel_lrc.c
v3: Squash together with the header file addition
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sun, 10 Aug 2014 05:29:11 +0000 (06:29 +0100)]
drm/i915: Simplify relocate_entry_gtt() and make 64-bit safe
Even though we should not try to use 4+GiB GTTs on 32-bit systems, by
using a local variable we can future proof the code whilst making it
easier to read.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Appease checkpatch a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sun, 10 Aug 2014 05:29:10 +0000 (06:29 +0100)]
drm/i915: Remove redundant list_empty(eb->vmas) tests in execbuffer
Part of the pre-validation for an execbuffer call is that there is at
least one object in the execlist. As we bail if we fail to lookup any
object, we can be sure that after the eb_lookup_vma() there is at least
one object in the vma list and so we do not need to assert.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sun, 10 Aug 2014 05:29:08 +0000 (06:29 +0100)]
drm/i915: Pre-validate the NEED_GTTS flag for execbuffer
We have an implementation requirement that precludes the user from
requesting a ggtt entry when the device is operating in ppgtt mode. Move
the current check from inside the execbuffer object collation to the
prevalidation phase.
v2: Roll both invalid flags checks into one
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 11 Aug 2014 10:08:58 +0000 (12:08 +0200)]
drm/i915: Fix secure dispatch with full ppgtt
Based upon a hunk from a patch from Chris Wilson, but augmented to:
- Process the batch in the full ppgtt vm so that self-relocations
match again with userspace's expectations..
- Add a comment why plain pin for the global gtt binding is safe at
that point.
v2: Drop local bind_vm variable (Chris).
v3: Explain why this works despite the lack of proper active tracking
for the ggtt batch vma.
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 9 Aug 2014 18:18:43 +0000 (19:18 +0100)]
drm/i915: Agnostic INTEL_INFO
Adapt the macro so that we can pass either the struct drm_device or the
struct drm_i915_private pointers and get the answer we want. Over time,
my plan is to convert all users over to using drm_i915_private and so
trimming down the pointer dance. Having spent a few hours chasing that
goal and achieved over 8k of object code saving, it appears to be a
worthwhile target. This interim macro allows us to slowly convert over.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Drop the (struct drm_device *) cast per the m-l discussion.
Also explain the seemingly unecessary first cast.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 11 Aug 2014 08:21:35 +0000 (09:21 +0100)]
drm/i915: Double check ring is idle before declaring the GPU wedged
During ring initialisation, sometimes we observe, though not in
production hardware, that the idle flag is not set even though the ring
is empty. Double check before giving up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 9 Aug 2014 18:18:42 +0000 (19:18 +0100)]
drm/i915: Copy PCI device id into the device info block
This is so that we can make the drm_i915_private->info always the
preferred source for chipset type and feature queries.
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>
Chris Wilson [Mon, 11 Aug 2014 10:00:12 +0000 (12:00 +0200)]
drm/i915: Force CPU relocations if not GTT mapped
Move the decision on whether we need to have a mappable object during
execbuffer to the fore and then reuse that decision by propagating the
flag through to reservation. As a corollary, before doing the actual
relocation through the GTT, we can make sure that we do have a GTT
mapping through which to operate.
Note that the key to make this work is to ditch the
obj->map_and_fenceable unbind optimization - with full ppgtt it
doesn't make a lot of sense any more anyway.
v2: Revamp and resend to ease future patches.
v3: Refresh patch rationale
References: https://bugs.freedesktop.org/show_bug.cgi?id=81094 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Explain why obj->map_and_fenceable is key and split out the
secure batch fix.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 9 Aug 2014 16:37:22 +0000 (17:37 +0100)]
drm/i915: Only perform set-to-gtt domain for objects bound to the global gtt
If an object is not bound into the global GTT, then it cannot be
accessed via the GTT. This restores the original code that was muddled
by ppGTT. In the process, we remove a WARN that had long outlived its
usefulness and was simply being coded around instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Sat, 9 Aug 2014 15:29:31 +0000 (16:29 +0100)]
drm/i915: Fix wrong number of HDMI translation entries
I keep telling myself that those tables aren't great because their size
is the number of dwords we need to program and not the number of entries
(number of dwords = number of entries * 2).
And... I got it wrong when I refactored the code. Fortunately, it was
only wrong when the VBT table (or the code parsing it) is itself
erroneous. Long story short, it shouldn't matter, but still, there's a
potential array overflow and random programming of the DDI translation
tables.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 8 Aug 2014 18:51:11 +0000 (21:51 +0300)]
drm/i915: Call .update_primary_plane in intel_{enable, disable}_primary_hw_plane()
Make the intel_{enable,disable}_primary_hw_plane() simply call
.update_primary_plane(), thus eliminating the rmw from these functions
which should help the poor old 830M.
Now we can also remove the .update_primary_plane() from the
.crtc_enable() hooks because we end up calling it via
intel_crtc_enable_planes()->intel_enable_primary_hw_plane().
This also has the nice benefit of making primary planes a bit closer to
the way we handle sprite planes during modesets.
v2: Just write 0 to DSPCNTR and DSPSURF/DSPADDR if the plane is (to be)
disabled. Quicker, and more importantly avoids an oops when fb==NULL
due to BIOS fb takeover failure.
Pimp the commit message a bit (Matt)
v3: Drop useless primary_enabled checks when setting DISPLAY_PLANE_ENABLE
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 8 Aug 2014 18:51:10 +0000 (21:51 +0300)]
drm/i915: Eliminate rmw from .update_primary_plane()
Move the entire DSPCNTR register setup into the .update_primary_plane()
functions. That's where it belongs anyway and it'll also help 830M which
has the extra problem that plane registers reads will return the value
latched at the last vblank, not the value that was last written.
Also move DSPPOS and DSPSIZE setup there.
v2: Don't move variable initialization to avoid churn later
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Fri, 8 Aug 2014 18:25:57 +0000 (19:25 +0100)]
drm/i915: Fix erroneous conversion to u8
adj was defined as u8. The issue is last_adj can be negative and adj is
initialized with:
adj = dev_priv->rps.last_adj;
and we were also happily doing things like:
if (adj < 0)
(thank static analysers!)
v2: Make new_delay an int in case we overflow the u8 in the intermediate
computations. new_delay will get clamped at the end anyway. (Ville)
Cc: Deepak S <deepak.s@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> 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>
Daniel Vetter [Thu, 7 Aug 2014 14:05:39 +0000 (16:05 +0200)]
drm/i915: No busy-loop wait_for in the ring init code
Doing a 1s wait (tops) with the cpu is a bit excessive. Tune it down
like everything else in that code.
v2: Also insert the missing space Chris spotted.
Cc: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gajanan Bhat [Thu, 7 Aug 2014 11:33:30 +0000 (17:03 +0530)]
drm/i915: Add sprite watermark programming for VLV and CHV
Program DDL register as part of sprite watermark programming for CHV and VLV.
v2: Rename DRAIN_LATENCY_MAX by DRAIN_LATENCY_MASK
v3: Addressed review comments by Ville
- Changed Sprite DDL definitions to more generic to avoid multiple if-else
- Changed bit masking to customary form
- Changed to bitwise shorthand operator for sprite_dl assignment
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gajanan Bhat [Wed, 6 Aug 2014 20:28:24 +0000 (01:58 +0530)]
drm/i915: Generalize drain latency computation
Modify drain latency computation to use it for any plane. Same function can be
used for primary, cursor and sprite planes.
v2: Adressed review comments by Imre and Ville.
- Moved clock round up in separate patch
- Added WARN check for clock and pixel size
- Simplified bit masking
- Use cursor_base instead of reg read
v3: Changed to bitwise shorthand operator for plane_dl assignment.
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 6 Aug 2014 11:02:51 +0000 (14:02 +0300)]
drm/i915: Free pending page flip events at .preclose()
If there are pending page flips when the fd gets closed those page
flips may have events associated to them. When the page flip eventually
completes it will queue the event to file_priv->event_list, but that
may be too late and file_priv->event_list has already been cleaned up.
Thus we leak a bit of kernel memory in the form of the event structure.
To avoid such problems clear out such pending events from
intel_crtc->unpin_work at ->preclose(). Any event that already made it
to file_priv->event_list will get cleaned up by the drm_release_events()
a bit later.
We can ignore the file_priv->event_space accounting since file_priv is
going away. This is already how drm core deals with pending vblank
events, which are maintained by the drm core.
What saves us from a total disaster (ie. dereferencing and alrady
freed file_priv) is the fact that the fb descruction triggers a modeset
and there we wait for pending flips.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jesse Barnes [Tue, 5 Aug 2014 14:51:18 +0000 (07:51 -0700)]
drm/i915: clean up PPGTT checking logic
sanitize_enable_ppgtt is the function that checks all the conditions,
honoring a forced ppgtt status or doing auto-detect as necessary. Just
make sure it returns the right value in all cases and use that in the
macros instead of the confusing intel_enable_ppgtt() function.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Don't reenable full ppgtt through the backdoor.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 16:52:13 +0000 (19:52 +0300)]
drm/i915: Polish the chv cmnlane resrt macros
Replace the semi-funky cmnlane assert/deassert macros with something a
bit more conventional. Also protect the macro arguments properly (also
for PHY_POWERGOOD()).
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 16:49:57 +0000 (19:49 +0300)]
drm/i915: Hack to tie both common lanes together on chv
It looks like frobbing the cmnreset line on pne PHY disturbs the other
PHY on chv. The result is a black screen. On HDMI it's just a flash of
black, but DP usually falls over and can't get back up.
As a workaround set up the power domains so that both common lane
wells power up and down together. I also tried leaving the cmnreset
deasserted even the if the power well goes down but that didn't seem
acceptable to the PHY.
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 26 Jun 2014 14:03:06 +0000 (17:03 +0300)]
drm/i915: Add cherryview_update_wm()
CHV has a third pipe so we need to compute the watermarks for its
planes. Add cherryview_update_wm() to do just that.
v2: Rebase on top of Imre's cxsr changes
v3: Pass crtc to vlv_update_drain_latency()
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of looping through all CRTCs, update DDL for current CRTC for which
watermark is being updated.
CHV is confirmed to have precision of 32/64 which is same as VLV.
Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 26 Jun 2014 14:02:37 +0000 (17:02 +0300)]
drm/i915: Parametrize VLV_DDL registers
The VLV/CHV DDL registers are uniform, and neatly enough the register
offsets are sane so we can easily unify them to a single set of defines
and just pass the pipe as the parameter to compute the register offset.
Note that we now fill out the drain latency for pipe C on CHV which we
didn't do before. The rest of the pipe C watermarks are still untouched
but that will be remedied later by adding a proper cherryview_update_wm()
function.
v2: Add a note about CHV pipe C changes (Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 11 Jun 2014 13:51:18 +0000 (16:51 +0300)]
drm/i915: Fill out the FWx watermark register defines
Add defines for all the watermark registers on modernish gmch platforms.
VLV has increased the number of bits available for certain watermaks so
expand the masks appropriately. Also vlv and chv have added some extra
FW registers.
Not sure what happened on chv because a new register called FW9 is now
at the offset where FW7 was on vlv, while FW7 and FW8 (another new
register) have been moved off somewhere else. Oh well, well just need
two defines for FW7 then.
v2: Fix DSPHOWM1 offset (Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 5 Aug 2014 05:56:55 +0000 (11:26 +0530)]
drm/i915: Add rotation property for sprites
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
v2: Moving rotation_property to mode_config
Cc: dri-devel@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 5 Aug 2014 05:56:53 +0000 (11:26 +0530)]
drm/i915: Make intel_plane_restore() return an error
Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.
Cc: dri-devel@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 5 Aug 2014 05:56:52 +0000 (11:26 +0530)]
drm/i915: Add 180 degree sprite rotation support
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated buffer offset automagically
v3: BDW also handles the rotated buffer offset automagically
Testcase: igt/kms_rotation_crc Cc: dri-devel@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I also modified a few call sites by hand where a pointer to mode_config
was directly used (to avoid overflowing 80 chars).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Wrap paramters correctly in the macro and remove spurious
space checkpatch noticed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Fri, 1 Aug 2014 10:07:56 +0000 (11:07 +0100)]
drm/i915/bdw: Remove the HDMI/DVI entry from the DP/eDP/FDI tables
We always write entries 0 to 8 from the DDI translation tables and then
entry 9 for HDMI/DVI with the help of the VBT. We then don't need the
failsafe HDMI entry in the DP/eDP/FDI tables.
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>
Damien Lespiau [Fri, 1 Aug 2014 10:07:54 +0000 (11:07 +0100)]
drm/i915: Gather the HDMI level shifter logic into one place
The knowledge about the HDMI/DVI DDI translation table was scattered
around.
- info->hdmi_level_shift was initialized with 6, the index of the 800
mV, 0dB translation
- A check on the VBT value was done to ensure it wasn't overflowing
the translation table (< 0xC)
- The actual programming was done in intel_ddi.c
As we need to change that knowledge for Broadwell, let's gather
everything into one place.
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>
Rodrigo Vivi [Fri, 1 Aug 2014 09:04:45 +0000 (02:04 -0700)]
drm/i915: Introduce FBC False Color for debug purposes.
With this bit enabled, HW changes the color when compressing frames for
debug purposes.
ALthough the simple way to enable a single bit is over intel_reg_write,
this value is overwriten on next update_fbc so depending on the workload
it is not possible to set this bit with intel-gpu-tools. So this patch
introduces a persistent way to enable false color over debugfs.
v2: Use DEFINE_SIMPLE_ATTRIBUTE as Daniel suggested
v3: (Ville) only do false color for IVB+ since according to spec bit is
MBZ before IVB.
v4: We don't have FBC on valleyview nor on cherryview (Ben)
v5: s/!HAS_PCH_SPLIT/!HAS_FBC (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 30 Jul 2014 20:34:27 +0000 (22:34 +0200)]
drm/i915: Align intel_dsi*.c files a bit
I'm not really that insisting on checkpath compliance, but ragged
function paramter alignment does get me. Please adjust your editor to
just do this for you.
Cc: Shobhit Kumar <shobhit.kumar@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:00 +0000 (02:04 +0300)]
drm/i915: Split chv_update_pll() apart
Split chv_update_pll() into two parts ala:
commit bdd4b6a655749970cc632aafc5fd596c07b60b1c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Apr 24 23:55:11 2014 +0200
drm/i915: Extract vlv_prepare_pll
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>
Paulo Zanoni [Thu, 17 Jul 2014 20:43:46 +0000 (17:43 -0300)]
d rm/i915: freeze display before the interrupts and GT
Since we started using intel_runtime_pm_disable_interrupts() at normal
(non-runtime) suspend/resume, we had to remove a WARN from
ironlake_disable_display_irq to avoid a case where we were doing the
correct thing and the WARN was not really needed. The problem is that
the WARN was useful in other cases, and its removal can hide some bugs
that we would catch automatically.
To be able to add back the WARN, we have to call intel_crtc_control()
before interrupts are disabled, which is what this patch currently
does.
Also notice that Ville's patch from the Watermarks series "drm/i915:
Leave interrupts enabled while disabling crtcs during suspend" also
did a change that's equivalent to the one we're doing on this patch,
with the exception that its original patch, when applied to the
current tree, procduces a WARN.
Related commits:
commit daa390e5ee45cc051d6bf37b296901f2f92b002d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
drm/i915: don't warn if IRQs are disabled when shutting down display IRQs
drm/i915: don't suspend gt until after we disable irqs and display (v2)
so all that's left from Paulo's patch is reinstating the WARNING.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Explain conflict resolution with Dave's DP MST patches with a
note in the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:18 +0000 (02:04 +0300)]
drm/i915: Split a few long debug prints
Split some WM debug prints to multiple lines. This shouldn't hurt
grappability since the important part is at the start and the rest
is just repeated stuff for each pipe.
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>
Rafael Barbalho [Mon, 28 Jul 2014 18:56:27 +0000 (19:56 +0100)]
drm/i915: Fix read back of plane stride register
According to the specifications bit 6 is actually valid in the stride register.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:13 +0000 (02:04 +0300)]
drm/i915: Add chv port D TX wells
Add the TX wells for port D. The Punit subsystem numbers are a total
guess at this time. Also I'm not sure these even exist. Certainly the
Punit in current hardware doesn't deal with these.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:12 +0000 (02:04 +0300)]
drm/i915: Add chv port B and C TX wells
Add the TX wells for ports B and C just like on VLV.
Again Punit doesn't seem ready (or the wells don't even exist anymore)
so leave it iffed out.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:11 +0000 (02:04 +0300)]
drm/i915: Add per-pipe power wells for chv
CHV has a power well for each pipe. Add the code to deal with them.
The Punit in current hardware doesn't seem ready for this yet, so
leave it iffed out.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:10 +0000 (02:04 +0300)]
drm/i915: Add disp2d power well for chv
Not sure if it's still there since chv has per-pipe power wells.
At least with current Punit this doesn't work. Also the display
irq handling would need to be adjusted for pipe C. So leave the
code iffed out for now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:09 +0000 (02:04 +0300)]
drm/i915: Kill intel_reset_dpio()
Both VLV and CHV handle the cmnreset stuff in the power well code now,
so intel_reset_dpio() is no longer needed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:08 +0000 (02:04 +0300)]
drm/i915: Add chv cmnlane power wells
CHV has two display PHYs so there are also two cmnlane power wells. Add
the approriate code to power the wells up/down.
Like on VLV we do the cmnreset assert/deassert and the DPLL refclock
enabling at approriate times.
This code actually works on my bsw.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 23:04:07 +0000 (02:04 +0300)]
drm/i915: Add chv_power_wells[]
Add chv_power_wells[] so we can start to build up the power well support
for chv. Just the "always on" well there initialy.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 22 May 2014 16:00:50 +0000 (19:00 +0300)]
drm/i915: Kill intel_crtc->vbl_wait
Share the waitqueue that drm_irq uses when performing the vblank evade
trick for atomic pipe updates.
v2: Keep intel_pipe_handle_vblank() (Chris)
Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Vandana Kannan [Tue, 5 Aug 2014 14:51:23 +0000 (07:51 -0700)]
drm/i915: State readout and cross-checking for dp_m2_n2
Adding relevant read out comparison code, in check_crtc_state, for the new
member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
values for a DP downclock mode (if available). Suggested by Daniel.
v2: Changed patch title.
Daniel's review comments incorporated.
Added relevant state readout code for M2_N2. dp_m2_n2 comparison to be done
only when high RR is not in use (This is because alternate m_n register
programming will be done only when low RR is being used).
v3: Modified call to get_m2_n2 which had dp_m_n as param by mistake.
Compare dp_m_n and dp_m2_n2 for gen 7 and below. compare the structures
based on DRRS state for gen 8 and above.
Save and restore M2 N2 registers for gen 7 and below
v4: For Gen>=8, check M_N registers against dp_m_n and dp_m2_n2 as there is
only one set of M_N registers
v5: Removed the chunk which saves and restores M2_N2 registers. Modified
get_m_n() to get M2_N2 registers as well. Modified the macro which compares
hw.dp_m_n against sw.dp_m2_n2/sw.dp_m_n for gen > 8.
v6: Added check to compare dp_m2_n2 only when DRRS is enabled
v7: Modified drrs check to use has_drrs
v8: Add has_drrs check before reading M2_N2 registers
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Vandana Kannan [Tue, 5 Aug 2014 14:51:22 +0000 (07:51 -0700)]
drm/i915: Set M2_N2 registers during mode set
For Gen < 8, set M2_N2 registers on every mode set. This is required to make
sure M2_N2 registers are set during boot, resume from sleep for cross-
checking the state. The register is set only if DRRS is supported.
v2: Patch rebased
v3: Daniel's review comments
- Removed HAS_DRRS(dev) and added bool has_drrs to pipe_config to
track drrs support
v4: Jesse's review comments
- Made changes to set m2_n2 in intel_dp_set_m_n()
Although POST_SYNC brought a bit of stability to Semaphores on BDW
it didn't solved all issues and some hungs can still occour when
semaphores are enabled on BDW. Also some sloweness can be found on some
igt tests, althoguth it apparently doesn't affect real workloads.
Besides that, no real performance gain was found on our tests with different
and even multiple workloads.
Let's disable it again for now. At least until we are sure it is safe
to re-enable it.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is not a complete fix, but it is verified to make the ring
initialization failures during resume much less likely.
We were not able to root-cause this bug (likely HW-specific to Gen4 chips)
yet. This is therefore used as a ducttape before problem is fully
understood and proper fix created, so that people don't suffer from
completely unusable systems in the meantime.
Rafael Barbalho [Thu, 24 Jul 2014 14:16:12 +0000 (15:16 +0100)]
drm/i915: Fix crash when failing to parse MIPI VBT
This particular nasty presented itself while trying to register the
intelfb device (intel_fbdev.c). During the process of registering the device
the driver will disable the crtc via i9xx_crtc_disable. These will
also disable the panel using the generic mipi panel functions in
dsi_mod_vbt_generic.c. The stale MIPI generic data sequence pointers would
cause a crash within those functions. However, all of this is happening
while console_lock is held from do_register_framebuffer inside fbcon.c. Which
means that you got kernel log and just the device appearing to reboot/hang for
no apparent reason.
The fault started from the FB_EVENT_FB_REGISTERED event using the
fb_notifier_call_chain call in fbcon.c.
Rodrigo Vivi [Tue, 5 Aug 2014 17:07:13 +0000 (10:07 -0700)]
drm/i915: Fix DEIER and GTIER collecting for BDW.
BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.
On debugfs all was properly listed already but besides we were also listing old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages
v2: Fix small issues of first version and don't read DEIER regs when pipe's
power well is disabled
v3: bikeshed accepted: use enum pipe pipe instead of int i for pipe interection
v4: Ben notice previous version was checking for display_power_enabled without
using propper locks. Using _unlocked version isn't reliable and we cannot
get this registers when power well is off. So let's avoid getting all DE_IER
per pipe for now. If someone think this is an useful information it can be
added later.
v5: Ben: put back debugfs stuff that might be coverred by pm_get and use
gen >= 8 trying to predict future.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81701 Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: (v3) 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>
Mika Kuoppala [Tue, 5 Aug 2014 14:16:26 +0000 (17:16 +0300)]
drm/i915: Don't accumulate hangcheck score on forward progress
If the actual head has progressed forward inside a batch (request),
don't accumulate hangcheck score.
As the hangcheck score in increased only by acthd jumping backwards,
the result is that we only declare an active batch as stuck if it is
trapped inside a loop. Or that the looping will dominate the batch
progression so that it overcomes the bonus that forward progress gives.
v2: Improved commit message (Chris Wilson)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: s/active_loop/active (loop)/ as requested by Chris.] Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Jun 2014 21:40:34 +0000 (00:40 +0300)]
drm/i915: Fix threshold for choosing 32 vs. 64 precisions for VLV DDL values
The DDL registers can hold 7bit numbers. Make the most of those seven
bits by adjusting the threshold where we switch between the 64 vs. 32
precision multipliers.
Also we compute 'entries' to make the decision about precision, and then
we recompute the same value to calculate the actual drain latency. Just
use the already calculate 'entries' there.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Zhenyu Wang [Thu, 27 Feb 2014 22:50:06 +0000 (06:50 +0800)]
drm/i915: Fix drain latency precision multipler for VLV
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rodrigo Vivi [Fri, 1 Aug 2014 16:12:27 +0000 (09:12 -0700)]
drm/i915: Collect gtier properly on HSW.
GTIER and DEIER doesn't have same interface on HSW so this "or" operation
makes the information provided useless.
v2: since we have gtier variable already let's split for everybody
and avoid the strange | op.
Also avoid overriding the value that was set for vlv. In this case I
believe that we should reorganize the whole function, but I'll respect
the comment that ask to not touch the order and let this organization
work to be done later.
v3: moving VLV check to the right place.
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>
projects / linux-beck.git / log