Mika Kahola [Fri, 9 Sep 2016 11:10:55 +0000 (14:10 +0300)]
drm/i915: Check pixel rate for DP to VGA dongle
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rate divided by 8 in MP/s.
v2: DPCD read outs and computation moved to drm (Ville, Daniel)
v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
function (Daniel)
v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
v5: Use of intel_dp->downstream_ports to read out port capabilities.
Code restructuring (Ville)
v6: Move DP branch device check to drm_dp_helper.c (Daniel)
v7: Cleanup as suggested by Ville
Mika Kahola [Fri, 9 Sep 2016 11:10:54 +0000 (14:10 +0300)]
drm/i915: Read DP branch device SW revision
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register fields 0x50A
and 0x50B.
v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)
v3: remove dependency to drm_dp_helper but instead parse
DPCD and print SW revision info to dmesg (Ville)
v4: commit message fix (Jim Bride)
Mika Kahola [Fri, 9 Sep 2016 11:10:53 +0000 (14:10 +0300)]
drm/i915: Read DP branch device HW revision
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.
v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)
v3: remove dependency to drm_dp_helper but instead parse
DPCD and print HW revision info to dmesg (Ville)
Mika Kahola [Fri, 9 Sep 2016 11:10:49 +0000 (14:10 +0300)]
drm: Helper to read max clock rate
Helper routine to read out maximum supported pixel rate
for DisplayPort legay VGA converter or TMDS clock rate
for other digital legacy converters. The helper returns
clock rate in kHz.
v2: Return early if detailed port cap info is not available.
Replace if-else ladder with switch-case (Ville)
Dave Gordon [Mon, 12 Sep 2016 20:19:35 +0000 (21:19 +0100)]
drm/i915: clarify PMINTRMSK/pm_intr_keep usage
No functional changes; just renaming a bit, tweaking a datatype,
prettifying layout, and adding comments, in particular in the
GuC setup code that touches this data.
Dave Gordon [Wed, 14 Sep 2016 12:10:33 +0000 (13:10 +0100)]
drm/i915: Only expand COND once in wait_for()
Commentary from Chris Wilson's original version:
> I was looking at some wait_for() timeouts on a slow system, with lots of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing COND. However, the double test of COND either side
> of the timeout check makes that unlikely. But we can do an equivalent
> loop, that keeps the COND check after testing for timeout (required so
> that we are not preempted between testing COND and then testing for a
> timeout) without expanding COND twice.
>
> The advantage of only expanding COND once is a dramatic reduction in
> code size:
>
> text data bss dec hex
> 1308733 5184 1152 1315069 1410fd before
> 1305341 5184 1152 1311677 1403bd after
but it turned out that due to a missing iniitialiser, gcc had "gone
wild trimming undefined code" :( This version acheives a rather more
modest (but still worthwhile) gain of ~550 bytes.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Original-idea-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zanoni, Paulo R <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473855033-26980-1-git-send-email-david.s.gordon@intel.com Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ville Syrjälä [Tue, 13 Sep 2016 09:22:19 +0000 (12:22 +0300)]
drm/i915: Ignore OpRegion panel type except on select machines
Turns out
commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
details") has regressed quite a few machines. So it looks like we
can't use the panel type from OpRegion on all systems, and yet we
absolutely must use it on some specific systems.
Despite trying, I was unable to find any automagic way to determine
if the OpRegion panel type is respectable or not. The only glimmer
of hope I had was bit 8 in the SCIC response, but that turned out to
not work either (it was always 0 on both types of systems).
So, to fix the regressions without breaking the machine we know to need
the OpRegion panel type, let's just add a quirk for this. Only specific
machines known to require the OpRegion panel type will therefore use
it. Everyone else will fall bck to the VBT panel type.
The only known machine so far is a "Conrac GmbH IX45GM2". The PCI
subsystem ID on this machine is just a generic 8086:2a42, so of no use.
Instead we'll go with a DMI match.
I suspect we can now also revert
commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
but let's leave that to a separate patch.
v2: Do the DMI match in the opregion code directly, as dev_priv->quirks
gets populated too late
Cc: Rob Kramer <rob@solution-space.com> Cc: Martin van Es <martin@mrvanes.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Dave Airlie <airlied@linux.ie> Cc: Marco Krüger <krgsch@gmail.com> Cc: Sean Greenslade <sean@seangreenslade.com> Cc: Trudy Tective <bertslany@gmail.com> Cc: Robin Müller <rm1990@gmx.de> Cc: Alexander Kobel <a-kobel@a-kobel.de> Cc: Alexey Shumitsky <alexey.shumitsky@gmail.com> Cc: Emil Andersen Lauridsen <mine809@gmail.com> Cc: oceans112@gmail.com Cc: James Hogan <james@albanarts.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: stable@vger.kernel.org
References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html
References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html
References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363 Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") Tested-by: Marco Krüger <krgsch@gmail.com> Tested-by: Alexey Shumitsky <alexey.shumitsky@gmail.com> Tested-by: Sean Greenslade <sean@seangreenslade.com> Tested-by: Emil Andersen Lauridsen <mine809@gmail.com> Tested-by: Robin Müller <rm1990@gmx.de> Tested-by: oceans112@gmail.com Tested-by: Rob Kramer <rob@solution-space.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com
References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.com Acked-by: Jani Nikula <jani.nikula@intel.com>
There are panels that needs 4 idle frames before entering PSR,
but VBT is unproperly set.
Also lately it was identified that idle frame count calculated at HW
can be off by 1, what makes the minimum of 2, at least.
Without the current vbt+1 we are with the risk of having HW calculating
0 idle frames and entering PSR when it shouldn't. Regardless the lack
of link training.
[Jani: there is some disagreement on the explanation, but the commit
regresses so revert it is.]
References: http://marc.info/?i=20160904191153.GA2328@light.dominikbrodowski.net Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: 1c80c25fb622 ("drm/i915/psr: Make idle_frames sensible again") Cc: drm-intel-fixes@lists.freedesktop.org # v4.8-rc1+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473295351-8766-1-git-send-email-rodrigo.vivi@intel.com
drm/i915: Add support for Kabylake to function obtaining shared PLL
This adds support for KBL in the new function added in commit ID:
commit <f169660ed4e57a03e6f6ed07fe192dbcb7687a0d> that returns a
shared pll in case of DDI platforms.
drm/i915: Make DP link training channel equalization DP 1.2 Spec compliant
Fix the number of tries in channel euqalization link training sequence
according to DP 1.2 Spec. It returns a boolean depending on channel
equalization pass or failure.
drm/dp/i915: Make clock recovery in the link training compliant with DP Spec 1.2
This function cleans up clock recovery loop in link training compliant
tp Dp Spec 1.2. It tries the clock recovery 5 times for the same voltage
or until max voltage swing is reached and removes the additional non
compliant retries. This function now returns a boolean values based on
if clock recovery passed or failed.
v3:
* Better Debug prints in case of failures (Mika Kahola)
v2:
* Rebased on top of new revision of vswing patch (Manasi Navare)
Jim Bride [Wed, 7 Sep 2016 22:47:34 +0000 (15:47 -0700)]
drm/i915/dp: Add a standalone function to obtain shared dpll for HSW/BDW/SKL/BXT
Add the PLL selection code for HSW/BDW/BXT/SKL into a stand-alone function
in order to allow for the implementation of a platform neutral upfront
link training function.
v4:
* Removed dereferencing NULL pointer in case of failure (Dhinakaran Pandiyan)
v3:
* Add Hooks for all DDI platforms into this standalone function
v2:
* Change the macro to use dev_priv instead of dev (David Weinehall)
Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Fri, 9 Sep 2016 20:19:57 +0000 (21:19 +0100)]
drm/i915: Flush to GTT domain all GGTT bound objects after hibernation
Recently I have been applying an optimisation to avoid stalling and
clflushing GGTT objects based on their current binding. That is we only
set-to-gtt-domain upon first bind. However, on hibernation the objects
remain bound, but they are in the CPU domain. Currently (since commit 975f7ff42edf ("drm/i915: Lazily migrate the objects after hibernation"))
we only flush scanout objects as all other objects are expected to be
flushed prior to use. That breaks down in the face of the runtime
optimisation above - and we need to flush all GGTT pinned objects
(essentially ringbuffers).
To reduce the burden of extra clflushes, we only flush those objects we
cannot discard from the GGTT. Everything pinned to the scanout, or
current contexts or ringbuffers will be flushed and rebound. Other
objects, such as inactive contexts, will be left unbound and in the CPU
domain until first use after resuming.
Fixes: 7abc98fadfdd ("drm/i915: Only change the context object's domain...") Fixes: 57e885318119 ("drm/i915: Use VMA for ringbuffer tracking")
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: David Weinehall <david.weinehall@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909201957.2499-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 9 Sep 2016 13:12:01 +0000 (14:12 +0100)]
drm/i915: Serialise execbuf operation after a dma-buf reservation object
Now that we can wait upon fences before emitting the request, it becomes
trivial to wait upon any implicit fence provided by the dma-buf
reservation object.
To protect against failure, we force any asynchronous waits on a foreign
fence to timeout after 10s - so that a stall in another driver does not
permanently cripple ourselves. Still unpleasant though!
Chris Wilson [Fri, 9 Sep 2016 13:12:00 +0000 (14:12 +0100)]
drm/i915: Nonblocking request submission
Now that we have fences in place to drive request submission, we can
employ those to queue requests after their dependencies as opposed to
stalling in the middle of an execbuf ioctl. (However, we still choose to
spin before enabling the IRQ as that is faster - though contentious.)
v2: Do the fence ordering first, where we can still fail.
Chris Wilson [Fri, 9 Sep 2016 13:11:59 +0000 (14:11 +0100)]
drm/i915: Avoid incrementing hangcheck whilst waiting for external fence
If we are waiting upon an external fence, from the pov of hangcheck the
engine is stuck on the last submitted seqno. Currently we give a small
increment to the hangcheck score in order to catch a stuck waiter /
driver. Now that we both have an independent wait hangcheck and may be
stuck waiting on an external fence, resetting the GPU has little effect
on that external fence. As we cannot advance by resetting, skip
incrementing the hangcheck score.
Chris Wilson [Fri, 9 Sep 2016 13:11:57 +0000 (14:11 +0100)]
drm/i915/guc: Prepare for nonblocking execbuf submission
Currently the presumption is that the request construction and its
submission to the GuC are all under the same holding of struct_mutex. We
wish to relax this to separate the request construction and the later
submission to the GuC. This requires us to reserve some space in the
GuC command queue for the future submission. For flexibility to handle
out-of-order request submission we do not preallocate the next slot in
the GuC command queue during request construction, just ensuring that
there is enough space later.
Chris Wilson [Fri, 9 Sep 2016 13:11:56 +0000 (14:11 +0100)]
drm/i915: Prepare object synchronisation for asynchronicity
We are about to specialize object synchronisation to enable nonblocking
execbuf submission. First we make a copy of the current object
synchronisation for execbuffer. The general i915_gem_object_sync() will
be removed following the removal of CS flips in the near future.
Chris Wilson [Fri, 9 Sep 2016 13:11:54 +0000 (14:11 +0100)]
drm/i915: Drive request submission through fence callbacks
Drive final request submission from a callback from the fence. This way
the request is queued until all dependencies are resolved, at which
point it is handed to the backend for queueing to hardware. At this
point, no dependencies are set on the request, so the callback is
immediate.
A side-effect of imposing a heavier-irqsafe spinlock for execlist
submission is that we lose the softirq enabling after scheduling the
execlists tasklet. To compensate, we manually kickstart the softirq by
disabling and enabling the bh around the fence signaling.
Chris Wilson [Fri, 9 Sep 2016 13:11:53 +0000 (14:11 +0100)]
drm/i915: Update reset path to fix incomplete requests
Update reset path in preparation for engine reset which requires
identification of incomplete requests and associated context and fixing
their state so that engine can resume correctly after reset.
The request that caused the hang will be skipped and head is reset to the
start of breadcrumb. This allows us to resume from where we left-off.
Since this request didn't complete normally we also need to cleanup elsp
queue manually. This is vital if we employ nonblocking request
submission where we may have a web of dependencies upon the hung request
and so advancing the seqno manually is no longer trivial.
We change the way we count pending batches. Only the active context
involved in the reset is marked as either innocent or guilty, and not
mark the entire world as pending. By inspection this only affects
igt/gem_reset_stats (which assumes implementation details) and not
piglit.
ARB_robustness gives this guide on how we expect the user of this
interface to behave:
* Provide a mechanism for an OpenGL application to learn about
graphics resets that affect the context. When a graphics reset
occurs, the OpenGL context becomes unusable and the application
must create a new context to continue operation. Detecting a
graphics reset happens through an inexpensive query.
And with regards to the actual meaning of the reset values:
Certain events can result in a reset of the GL context. Such a reset
causes all context state to be lost. Recovery from such events
requires recreation of all objects in the affected context. The
current status of the graphics reset state is returned by
enum GetGraphicsResetStatusARB();
The symbolic constant returned indicates if the GL context has been
in a reset state at any point since the last call to
GetGraphicsResetStatusARB. NO_ERROR indicates that the GL context
has not been in a reset state since the last call.
GUILTY_CONTEXT_RESET_ARB indicates that a reset has been detected
that is attributable to the current GL context.
INNOCENT_CONTEXT_RESET_ARB indicates a reset has been detected that
is not attributable to the current GL context.
UNKNOWN_CONTEXT_RESET_ARB indicates a detected graphics reset whose
cause is unknown.
The language here is explicit in that we must mark up the guilty batch,
but is loose enough for us to relax the innocent (i.e. pending)
accounting as only the active batches are involved with the reset.
In the future, we are looking towards single engine resetting (with
minimal locking), where it seems inappropriate to mark the entire world
as innocent since the reset occurred on a different engine. Reducing the
information available means we only have to encounter the pain once, and
also reduces the information leaking from one context to another.
v2: Legacy ringbuffer submission required a reset following hibernation,
or else we restore stale values to the RING_HEAD and walked over
stolen garbage.
v3: GuC requires replaying the requests after a reset.
v4: Restore engine IRQ after reset (so waiters will be woken!)
Rearm hangcheck if resetting with a waiter.
Chris Wilson [Fri, 9 Sep 2016 13:11:52 +0000 (14:11 +0100)]
drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker
Since we have a cooperative mode now with a direct reset, we can avoid
the contention on struct_mutex and instead try then sleep on the
I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is
cleared, all is fine. Otherwise, we sleep for a bit and try again. In
the worst case we sleep for an extra second waiting for the mutex to be
released (no one touching the GPU is allowed the struct_mutex whilst the
I915_RESET_IN_PROGRESS bit is set). But when we have a direct reset,
this allows us to clean up the reset worker faster.
v2: Remember to call wake_up_bit() after changing (for the faster wakeup
as promised)
Chris Wilson [Fri, 9 Sep 2016 13:11:51 +0000 (14:11 +0100)]
drm/i915: Perform a direct reset of the GPU from the waiter
If a waiter is holding the struct_mutex, then the reset worker cannot
reset the GPU until the waiter returns. We do not want to return -EAGAIN
form i915_wait_request as that breaks delicate operations like
i915_vma_unbind() which often cannot be restarted easily, and returning
-EIO is just as useless (and has in the past proven dangerous). The
remaining WARN_ON(i915_wait_request) serve as a valuable reminder that
handling errors from an indefinite wait are tricky.
We can keep the current semantic that knowing after a reset is complete,
so is the request, by performing the reset ourselves if we hold the
mutex.
uevent emission is still handled by the reset worker, so it may appear
slightly out of order with respect to the actual reset (and concurrent
use of the device).
Chris Wilson [Fri, 9 Sep 2016 13:11:50 +0000 (14:11 +0100)]
drm/i915: Mark up all locked waiters
In the next patch we want to handle reset directly by a locked waiter in
order to avoid issues with returning before the reset is handled. To
handle the reset, we must first know whether we hold the struct_mutex.
If we do not hold the struct_mtuex we can not perform the reset, but we do
not block the reset worker either (and so we can just continue to wait for
request completion) - otherwise we must relinquish the mutex.
Chris Wilson [Fri, 9 Sep 2016 13:11:48 +0000 (14:11 +0100)]
drm/i915: Drop local struct_mutex around intel_init_emon[ilk]
Access to intel_init_emon() is strictly ordered by gt_powersave, using
struct_mutex around it is overkill (and will conflict with the caller
holding struct_mutex themselves).
Chris Wilson [Fri, 9 Sep 2016 13:11:47 +0000 (14:11 +0100)]
drm/i915: Separate out reset flags from the reset counter
In preparation for introducing a per-engine reset, we can first separate
the mixing of the reset state from the global reset counter.
The loss of atomicity in updating the reset state poses a small problem
for handling the waiters. For requests, this is solved by advancing the
seqno so that a waiter waking up after the reset knows the request is
complete. For pending flips, we still rely on the increment of the
global reset epoch (as well as the reset-in-progress flag) to signify
when the hardware was reset.
The advantage, now that we do not inspect the reset state during reset
itself i.e. we no longer emit requests during reset, is that we can use
the atomic updates of the state flags to ensure that only one reset
worker is active.
v2: Mika spotted that I transformed the i915_gem_wait_for_error() wakeup
into a waiter wakeup.
Chris Wilson [Fri, 9 Sep 2016 13:11:46 +0000 (14:11 +0100)]
drm/i915: Simplify ELSP queue request tracking
Emulate HW to track and manage ELSP queue. A set of SW ports are defined
and requests are assigned to these ports before submitting them to HW. This
helps in cleaning up incomplete requests during reset recovery easier
especially after engine reset by decoupling elsp queue management. This
will become more clear in the next patch.
In the engine reset case we want to resume where we left-off after skipping
the incomplete batch which requires checking the elsp queue, removing
element and fixing elsp_submitted counts in some cases. Instead of directly
manipulating the elsp queue from reset path we can examine these ports, fix
up ringbuffer pointers using the incomplete request and restart submissions
again after reset.
Chris Wilson [Fri, 9 Sep 2016 13:11:44 +0000 (14:11 +0100)]
drm/i915: Compute the ELSP register location once
Similar to the issue with reading from the context status buffer,
see commit 26720ab97fea ("drm/i915: Move CSB MMIO reads out of the
execlists lock"), we frequently write to the ELSP register (4 writes per
interrupt) and know we hold the required spinlock and forcewake throughout.
We can further reduce the cost of writing these registers beyond the
I915_WRITE_FW() by precomputing the address of the ELSP register. We also
note that the subsequent read serves no purpose here, and are happy to
see it go.
v2: Address I915_WRITE mistakes in changelog
text data bss dec hex filename 1259784 4581 576 1264941 134d2d drivers/gpu/drm/i915/i915.ko 1259720 4581 576 1264877 134ced drivers/gpu/drm/i915/i915.ko
Chris Wilson [Fri, 9 Sep 2016 13:11:41 +0000 (14:11 +0100)]
drm/i915: Add a sw fence for collecting up dma fences
This is really a core kernel struct in disguise until we can finally
place it in kernel/. There is an immediate need for a fence collection
mechanism that is more flexible than fence-array, in particular being
able to easily drive request submission via events (and not just
interrupt driven). The same mechanism would be useful for handling
nonblocking and asynchronous atomic modesets, parallel execution and
more, but for the time being just create a local sw fence for execbuf.
Carlos Santa [Wed, 17 Aug 2016 19:30:57 +0000 (12:30 -0700)]
drm/i915: Move HAS_GUC definition to platform definition
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platform
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:56 +0000 (12:30 -0700)]
drm/i915: Make HWS_NEEDS_PHYSICAL the exception
Make the .hws_needs_physical the exception by switching the flag
on earlier platforms since they are fewer to support. Remove the flag on
later GPUs hardware since they all use GTT hws by default.
Switch the logic as well in the driver to reflect this change
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:55 +0000 (12:30 -0700)]
drm/i915: Move HAS_GMCH_DISPLAY definition to platform
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:54 +0000 (12:30 -0700)]
drm/i915: Move HAS_L3_DPF definition to platform definition
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:53 +0000 (12:30 -0700)]
drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:52 +0000 (12:30 -0700)]
drm/i915: Move HAS_HW_CONTEXTS definition to platform
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:51 +0000 (12:30 -0700)]
drm/i915: Introduce GEN2_FEATURES for device info
Introducing a GEN2_FEATURES macro to simplify the struct definitions by
platforms given that most of the features are common. Inspired by the
GEN7_FEATURES macro done by Ben W. and others.
Use it for 830, 845g, i85x, i865g.
CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:50 +0000 (12:30 -0700)]
drm/i915: Introduce GEN3_FEATURES for device info
Introducing a GEN3_FEATURES macro to simplify the struct definitions by
platforms given that most of the features are common. Inspired by the
GEN7_FEATURES macro done by Ben W. and others.
Use it for i915g, i915gm, i945g, i945gm, g33 and pnv.
CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:49 +0000 (12:30 -0700)]
drm/i915: Introduce GEN4_FEATURES for device info
Introducing a GEN4_FEATURES macro to simplify the struct
definitions by platforms given that most of the features are common.
Inspired by the GEN7_FEATURES macro done by Ben W. and others.
Use it for i965g, i965gm, g45 and gm45.
CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:48 +0000 (12:30 -0700)]
drm/i915: Move HAS_GMBUS_IRQ definition to platform definition
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:47 +0000 (12:30 -0700)]
drm/i915: Introduce GEN5_FEATURES for device info
Introducing a GEN5_FEATURES macro to simplify the struct
definitions by platforms given that most of the features are common.
Inspired by the GEN7_FEATURES macro done by Ben W. and others.
Use it for ilk.
CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:46 +0000 (12:30 -0700)]
drm/i915: Move HAS_DP_MST definition to platform definition
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:45 +0000 (12:30 -0700)]
drm/i915: Move HAS_RC6p definition to platform definition
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:44 +0000 (12:30 -0700)]
drm/i915: Move HAS_RC6 definition to platform definition
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:43 +0000 (12:30 -0700)]
drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:42 +0000 (12:30 -0700)]
drm/i915 Move HAS_CSR definition to platform definition
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:39 +0000 (12:30 -0700)]
drm/i915: Move HAS_RUNTIME_PM definition to platform
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:38 +0000 (12:30 -0700)]
drm/i915: Introduce GEN6_FEATURES for device info
Introducing a GEN6_FEAUTRES macro to simplify the struct definitions by
platforms given that most of the features are common. Inspired by the
GEN7_FEATURES macro done by Ben W. and others.
Use it for snb.
CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:37 +0000 (12:30 -0700)]
drm/i915: Remove .is_mobile field from platform struct
As recommended by Ville Syrjala removing .is_mobile field from the
platform struct definition for vlv and hsw+ GPUs as there's no need to
make the distinction in later hardware anymore. Keep it for older GPUs
as it is still needed for ilk-ivb.
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Carlos Santa [Wed, 17 Aug 2016 19:30:36 +0000 (12:30 -0700)]
drm/i915: Move HAS_PSR definition to platform struct definition
[patch series] Moving all GPU features to the platform struct definition
allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct definition
Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Split out the DisplayPort and HDMI pll setup code into separate
functions and refactor the DP code that calculates the pll
so that it doesn't depend on crtc state.
This will be used for acquiring port pll when doing
upfront link training.
Jim Bride [Thu, 1 Sep 2016 22:08:10 +0000 (15:08 -0700)]
drm/i915: Split skl_get_dpll()
Split out the DisplayPort and HDMI pll setup code into separate
functions and refactor the DP code does not directly depend on
crtc state, so that the code can be used for upfront link training.
Durgadoss R [Thu, 1 Sep 2016 22:08:09 +0000 (15:08 -0700)]
drm/i915: Split bxt_ddi_pll_select()
Split out of bxt_ddi_pll_select() the logic that calculates the pll
dividers and dpll_hw_state into a new function that doesn't depend on
crtc state. This will be used for enabling the port pll when doing
upfront link training.
v2:
* Refactored code so that bxt_clk_div need not be exported (Durga)
v1:
* Rebased on top of intel_dpll_mgr.c (Durga)
* Initial version from Ander on top of intel_ddi.c
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions
Split intel_ddi_pre_enable() into encoder type specific versions that
don't depend on crtc_state. The necessary parameters are passed as
function arguments. This split will be necessary for implementing DP
upfront link training.
drm/i915: Remove ddi_pll_sel from intel_crtc_state
The value of ddi_pll_sel is derived from the selection of shared dpll,
so just calculate the final value when necessary.
v2: Actually remove it from crtc state and delete remaining usages. (CI)
Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Our current implementation of live status check (repeat 9 times
with 10ms delays between each attempt as a workaround for
buggy displays) imposes a rather serious penalty, time wise,
on intel_hdmi_detect(). Since we we already skip live status
checks on platforms before gen 7, and since we seem to have
coped quite well before the live status check was introduced
for newer platforms too, the previous behaviour is probably
preferable, at least unless someone can point to a use-case
that the live status check improves (apart from "Bspec says so".)
Signed-off-by: David Weinehall <david.weinehall@linux.intel.com> Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid") Fixes: f8d03ea0053b ("drm/i915: increase the tries for HDMI hotplug live status checking")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97139
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94014 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160817124748.31208-1-david.weinehall@linux.intel.com
Lyude [Mon, 29 Aug 2016 16:31:27 +0000 (12:31 -0400)]
drm/i915/skl: Don't try to update plane watermarks if they haven't changed
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.
Simple reproduction recipe:
- Get a SKL laptop, launch any kind of X session
- Get two extra monitors
- Keep hotplugging both displays (so that the display configuration
jumps from 1 active pipe to 3 active pipes and back)
- Eventually underrun
Changes since v1:
- Fix incorrect use of "it's"
Changes since v2:
- Add reproduction recipe
Chris Wilson [Tue, 6 Sep 2016 14:45:38 +0000 (15:45 +0100)]
drm/i915: Remove 64b mmio write vfuncs
We don't have safe 64-bit mmio writes as they are really split into
2x32-bit writes. This tearing is dangerous as the hardware *will*
operate on the intermediate value, requiring great care when assigning.
(See, for example, i965_write_fence_reg.) As such we don't currently use
them and strongly advise not to us them. Go one step further and remove
the 64-bit write vfuncs.
v2: Add some more details to the comment about why WRITE64 is absent,
and why you need to think twice before using READ64.
Zhi Wang [Tue, 6 Sep 2016 04:04:12 +0000 (12:04 +0800)]
drm/i915: disable 48bit full PPGTT when vGPU is active
Disable 48bit full PPGTT on vGPU too for now.
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160906040412.1274-3-zhenyuw@linux.intel.com
Chris Wilson [Tue, 6 Sep 2016 07:38:44 +0000 (08:38 +0100)]
drm/i915: Don't wait for a spinlock inside error capture
If we can't grab the breadcrumb's spinlock, possibly due to a driver
deadlock inside the waiters, ignore them. Like hangcheck, error
capturing must work no matter how the driver/GPU dies.
Dave Gordon [Thu, 18 Aug 2016 17:17:24 +0000 (18:17 +0100)]
drm/i915/guc: revisit GuC loader message levels
Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.
v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()
Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Dave Gordon [Thu, 18 Aug 2016 17:17:22 +0000 (18:17 +0100)]
drm: extra printk() wrapper macros
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.
DRM_ERROR is unchanged, as it's not just a printk wrapper.
v2:
Fix whitespace, missing ## (Eric Engestrom)
Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Cc: dri-devel@lists.freedesktop.org Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Sat, 3 Sep 2016 06:53:43 +0000 (07:53 +0100)]
drm/i915: debugfs/i915_gem_interrupt_info does not need struct_mutex
i915_gem_interrupt_info() only looks at mmio registers, and the waiters
under a spinlock. It doesn't need struct_mutex (but does need the rpm
wakelock for mmio access). Maybe useful using get_if_notidle?
Imre Deak [Wed, 31 Aug 2016 16:13:07 +0000 (19:13 +0300)]
drm/i915/bdw: sseu: Fix sseu status parsing
Currently when checking for fused off EUs we may ignore the EU count in
an enabled slice if there is any disabled slice preceding the enabled
one (with a lower slice ID). Perhaps this can't happen in reality, but
there is no reason to have this assumption built-in, the code is clearer
without it.
Imre Deak [Wed, 31 Aug 2016 16:13:05 +0000 (19:13 +0300)]
drm/i915: sseu: Convert subslice count fields to subslice mask
In an upcoming patch we'll need the actual mask of subslices in addition
to their count, so convert the subslice_per_slice field to a mask.
Also we can easily calculate subslice_total from the other fields, so
instead of storing a cached version of this, add a helper to calculate
it.
v2:
- Use hweight8() on u8 typed vars instead of hweight32(). (Ben)
Reviewed-by: Robert Bragg <robert@sixbynine.org> (v1) Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Tested-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Signed-off-by: Imre Deak <imre.deak@intel.com>
Imre Deak [Wed, 31 Aug 2016 16:13:02 +0000 (19:13 +0300)]
drm/i915: sseu: Use sseu_dev_info in device info
Move all slice/subslice/eu related properties to the sseu_dev_info
struct.
No functional change.
v2:
- s/info/sseu/ based on the new struct name. (Ben)
Reviewed-by: Robert Bragg <robert@sixbynine.org> (v1) Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Tested-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Signed-off-by: Imre Deak <imre.deak@intel.com>
Imre Deak [Wed, 31 Aug 2016 16:13:01 +0000 (19:13 +0300)]
drm/i915: sseu: Move sseu_dev_status to i915_drv.h
The data in this struct is provided both by getting the
slice/subslice/eu features available on a given platform and the actual
runtime state of these same features which depends on the HW's current
power saving state.
Atm members of this struct are duplicated in sseu_dev_status and
intel_device_info. For clarity and code reuse we can share one struct
for both of the above purposes. This patch only moves the struct to the
header file, the next patch will convert users of intel_device_info to
use this struct too.
Instead of unsigned int u8 is used now, which is big enough and is used
anyway in intel_device_info.
No functional change.
v2:
- s/stat/sseu/ based on the new struct name (Ben)
David Weinehall [Fri, 2 Sep 2016 10:46:17 +0000 (13:46 +0300)]
drm/i915: Cleanup i915_param()
Rather than having a separate case for each value where we just return
a hardcoded value = 1, we lump them all together and rely on the awesome
case-fallthrough feature of C.
Fix all feature macros to pass dev_priv instead of dev while at it,
and use INTEL_GEN() instead of INTEL_INFO()->gen.
Chris Wilson [Thu, 1 Sep 2016 20:55:10 +0000 (21:55 +0100)]
drm/i915: Drop mutex around clearing error state
The error state itself is guarded by a spinlock (admittedly even that is
overkill for a single pointer!) and doesn't require us to take the
struct_mutex in the debugfs/sysfs interface. Removing the struct_mutex
removes one more potential blockage when trying to debug a deadlock.
The mentioned commit changes intel_display_crc_init to take a dev_priv,
but forgets to change the stub.
Cc: David Weinehall <david.weinehall@linux.intel.com> Fixes: 36cdd0138b7f ("drm/i915: debugfs spring cleaning") Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-and-by: Kim Lidström <kim@dxtr.im> Link: http://patchwork.freedesktop.org/patch/msgid/1472116022-17598-1-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
projects / linux-beck.git / log