Fixes: fe5a66f91c88 ("drm/i915: Read PSR caps/intermediate freqs/etc. only once on eDP") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: <drm-intel-fixes@lists.freedesktop.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161013085508.GJ16198@mwanda
Chris Wilson [Thu, 13 Oct 2016 08:55:04 +0000 (09:55 +0100)]
drm/i915: Skip unbinding large unmappable global buffers
If the user requests a mappable binding to the global GTT, we will first
unbind an existing mapping if it doesn't match. We will unbind even if
there is no possibility that the object can fit in the mappable
aperture. This may lead to a ping-pong migration of the object, for
example igt/gem_exec_big.
v2: Comment upon the reasoning, or lack thereof!, behind the choice of
magic numbers.
Imre Deak [Wed, 12 Oct 2016 14:46:37 +0000 (17:46 +0300)]
drm/i915/hsw: Fix GPU hang during resume from S3-devices state
Currently resuming on HSW from S3 pm_test/devices state leads to an
unrecoverable GPU hang. Resetting the GPU during suspend fixes this. For
a full S3 cycle this change only means the reset happens earlier (before
reaching S3). For S4 the reset will happen now both during the freeze
and quiesce phases, which is a benefit since it will guarantee that the
GPU is idle before creating and loading the hibernation image.
Chris Wilson [Wed, 12 Oct 2016 12:48:24 +0000 (13:48 +0100)]
drm/i915: Treat a framebuffer reference as an active reference whilst shrinking
Treat a framebuffer reference with the same priority as an active
reference whilst shrinking. Framebuffers are likely to be reused and
typically cost more to migrate to and from GPU memory (on LLC
architectures we need to clflush), so defer the temptation to purge them
during a kswapd run until we have run out of cheap buffers.
Chris Wilson [Wed, 12 Oct 2016 11:48:27 +0000 (12:48 +0100)]
drm/i915: Update debugfs describe_obj() to show fault-mappable
The current meaning of whether an object has a GGTT vma is very
ill-defined (and note we don't check for any partials either), it just
means that at some point it was in the GGTT but it may not be now. The
information we really care about here is whether it is taking up
precious mappable aperture space. This is the obj->fault_mappable flag.
We have a redundant long form reprinting of this information, so remove
that in favour of the compact flag.
Chris Wilson [Wed, 12 Oct 2016 11:48:26 +0000 (12:48 +0100)]
drm/i915: Use fence_write() from rpm resume
During rpm resume we restore the fences, but we do not have the
protection of struct_mutex. This rules out updating the activity
tracking on the fences, and requires us to rely on the rpm as the
serialisation barrier instead.
Note we also have to remember the lesson from commit 4fc788f5ee3d
("drm/i915: Flush delayed fence releases after reset") where we have to
flush any changes to the fence on restore.
v2: Replace call to release user mmaps with an assertion that they have
already been zapped.
Fixes: 49ef5294cda2 ("drm/i915: Move fence tracking from object to vma") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012114827.17031-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 12 Oct 2016 09:05:22 +0000 (10:05 +0100)]
drm/i915: Compress GPU objects in error state
Our error states are quickly growing, pinning kernel memory with them.
The majority of the space is taken up by the error objects. These
compress well using zlib and without decode are mostly meaningless, so
encoding them does not hinder quickly parsing the error state for
familiarity.
Chris Wilson [Wed, 12 Oct 2016 09:05:21 +0000 (10:05 +0100)]
drm/i915: Consolidate error object printing
Leave all the pretty printing to userspace and simplify the error
capture to only have a single common object printer. It makes the kernel
code more compact, and the refactoring allows us to apply more complex
transformations like compressing the output.
Chris Wilson [Wed, 12 Oct 2016 09:05:20 +0000 (10:05 +0100)]
drm/i915: Always use the GTT for error capture
Since the GTT provides universal access to any GPU page, we can use it
to reduce our plethora of read methods to just one. It also has the
important characteristic of being exactly what the GPU sees - if there
are incoherency problems, seeing the batch as executed (rather than as
trapped inside the cpu cache) is important.
Chris Wilson [Wed, 12 Oct 2016 09:05:19 +0000 (10:05 +0100)]
drm/i915: Stop the machine whilst capturing the GPU crash dump
The error state is purposefully racy as we expect it to be called at any
time and so have avoided any locking whilst capturing the crash dump.
However, with multi-engine GPUs and multiple CPUs, those races can
manifest into OOPSes as we attempt to chase dangling pointers freed on
other CPUs. Under discussion are lots of ways to slow down normal
operation in order to protect the post-mortem error capture, but what it
we take the opposite approach and freeze the machine whilst the error
capture runs (note the GPU may still running, but as long as we don't
process any of the results the driver's bookkeeping will be static).
Note that by of itself, this is not a complete fix. It also depends on
the compiler barriers in list_add/list_del to prevent traversing the
lists into the void. We also depend that we only require state from
carefully controlled sources - i.e. all the state we require for
post-mortem debugging should be reachable from the request itself so
that we only have to worry about retrieving the request carefully. Once
we have the request, we know that all pointers from it are intact.
v2: Avoid drm_clflush_pages() inside stop_machine() as it may use
stop_machine() itself for its wbinvd fallback.
Chris Wilson [Wed, 12 Oct 2016 09:05:18 +0000 (10:05 +0100)]
drm/i915: Allow disabling error capture
We currently capture the GPU state after we detect a hang. This is vital
for us to both triage and debug hangs in the wild (post-mortem
debugging). However, it comes at the cost of running some potentially
dangerous code (since it has to make very few assumption about the state
of the driver) that is quite resource intensive.
This patch introduces both a method to disable error capture at runtime
(for users who hit bugs at runtime and need a workaround) and to disable
error capture at compiletime (for realtime users who want to minimise
any possible latency, and never require error capture, saving ~30k of
code). The cost is that we now have to be wary of (and test!) a kconfig
flag and a module parameter. The effect of the module parameter is easy
to verify through code inspection and runtime testing, but a kconfig flag
needs regular compile checking.
Joonas Lahtinen [Wed, 12 Oct 2016 07:18:54 +0000 (10:18 +0300)]
drm/i915: Remove unused BSM_MASK causing warning
Remove never used BSM{,_MASK}. BSM_MASK #define also causes a warning.
include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, but ‘int’ only has 32 bits
[-Wshiftoverflow=]
#define INTEL_BSM_MASK (0xFFFF << 20)
Daniel Vetter [Wed, 12 Oct 2016 06:22:25 +0000 (08:22 +0200)]
Merge tag 'drm-for-v4.9' into drm-intel-next-queued
It's been over two months, git definitely lost it's marbles. Conflicts
resolved by picking our version, plus manually checking the diff with
the parent in drm-intel-next-queued to make sure git didn't do
anything stupid. It did, so I removed 2 occasions where it
double-inserted a bit of code. The diff is now just
- kernel-doc changes
- drm format/name changes
- display-info changes
so looks all reasonable.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Dave Airlie [Tue, 11 Oct 2016 20:07:38 +0000 (06:07 +1000)]
Merge tag 'topic/drm-misc-2016-10-11' of git://anongit.freedesktop.org/drm-intel into drm-next
Just flushing out my -misc queue. Slightly important are the prime
refcount/unload fixes from Chris.
There's also the reservation stuff from Chris still pending, and Sumits
hasn't landed that yet. Might get another pull for that, but pls don't
hold up the main pull for it ;-)
* tag 'topic/drm-misc-2016-10-11' of git://anongit.freedesktop.org/drm-intel:
drm/crtc: constify drm_crtc_index parameter
drm: use the right function name in documentation
drm: Release resources with a safer function
drm: Fix up kerneldoc for new drm_gem_dmabuf_export()
drm/bridge: Drop drm_connector_unregister and call drm_connector_cleanup directly
drm/fb-helper: fix sphinx markup for DRM_FB_HELPER_DEFAULT_OPS
drm/bridge: Add RGB to VGA bridge support
drm/prime: Take a ref on the drm_dev when exporting a dma_buf
drm/prime: Pass the right module owner through to dma_buf_export()
drm/bridge: Call drm_connector_cleanup directly
drm: simple_kms_helper: Add prepare_fb and cleanup_fb hooks
drm: Release resources with a safer function
Dave Airlie [Tue, 11 Oct 2016 19:46:18 +0000 (05:46 +1000)]
Merge tag 'drm-intel-next-fixes-2016-10-11' of git://anongit.freedesktop.org/drm-intel into drm-next
A big bunch of i915 fixes for drm-next / v4.9 merge window, with more
than half of them also cc: stable. We also continue to have more Fixes:
annotations for our fixes, which should help the backporters and
archeologists.
* tag 'drm-intel-next-fixes-2016-10-11' of git://anongit.freedesktop.org/drm-intel: (27 commits)
drm/i915: Fix conflict resolution from backmerge of v4.8-rc8 to drm-next
drm/i915/guc: Unwind GuC workqueue reservation if request construction fails
drm/i915: Reset the breadcrumbs IRQ more carefully
drm/i915: Force relocations via cpu if we run out of idle aperture
drm/i915: Distinguish last emitted request from last submitted request
drm/i915: Allow DP to work w/o EDID
drm/i915: Move long hpd handling into the hotplug work
drm/i915/execlists: Reinitialise context image after GPU hang
drm/i915: Use correct index for backtracking HUNG semaphores
drm/i915: Unalias obj->phys_handle and obj->userptr
drm/i915: Just clear the mmiodebug before a register access
drm/i915/gen9: only add the planes actually affected by ddb changes
drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
drm/i915/bxt: Fix HDMI DPLL configuration
drm/i915/gen9: fix the watermark res_blocks value
drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations
drm/i915/gen9: minimum scanlines for Y tile is not always 4
drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
drm/i915/kbl: KBL also needs to run the SAGV code
drm/i915: introduce intel_has_sagv()
...
Paulo Zanoni [Tue, 4 Oct 2016 17:37:32 +0000 (14:37 -0300)]
drm/i915/gen9: fix DDB partitioning for multi-screen cases
With the previous code we were only recomputing the DDB partitioning
for the CRTCs included in the atomic commit, so any other active CRTCs
would end up having their DDB registers zeroed. In this patch we make
sure that the computed state starts as a copy of the current
partitioning, and then we only zero the DDBs that we're actually
going to recompute.
How to reproduce the bug:
1 - Enable the primary plane on pipe A
2 - Enable the primary plane on pipe B
3 - Enable the cursor or sprite plane on pipe A
Step 3 will zero the DDB partitioning for pipe B since it's not
included in the commit that enabled the cursor or sprite for pipe A.
I expect this to fix many FIFO underrun problems on gen9+.
v2:
- Mention the cursor on the steps to reproduce the problem (Paulo).
- Add Testcase tag provided by Maarten (Maarten).
Jani Nikula [Mon, 10 Oct 2016 15:04:06 +0000 (18:04 +0300)]
drm/i915/audio: add register macros for audio config N value
Have generic macros in line with the rest of the register bit definition
macros instead of a dedicated function in intel_audio.c, and use them.
No functional changes.
Jani Nikula [Mon, 10 Oct 2016 15:04:02 +0000 (18:04 +0300)]
drm/i915/audio: use the same code for updating audio config
It gets fragile to duplicate the code for updating HSW_AUD_CFG. The only
change should be that the hdmi pixel clock is also updated in
i915_audio_component_sync_audio_rate(), but it should not be any
different.
Chris Wilson [Tue, 11 Oct 2016 09:06:56 +0000 (10:06 +0100)]
drm/i915: Convert open-coded use of vma_pages()
If we want to know how many pages a VMA spans, we can use vma_pages() to
find out. We have one such invocation inside our faulthandler, so
convert it. (We have two other that want the size in bytes rather than
pages, food for future thought.)
Chris Wilson [Tue, 11 Oct 2016 08:20:21 +0000 (09:20 +0100)]
drm/i915: Allow compaction upto SWIOTLB max segment size
commit 1625e7e549c5 ("drm/i915: make compact dma scatter lists creation
work with SWIOTLB backend") took a heavy handed approach to undo the
scatterlist compaction in the face of SWIOTLB. (The compaction hit a bug
whereby we tried to pass a segment larger than SWIOTLB could handle.) We
can be a little more intelligent and try compacting the scatterlist up
to the maximum SWIOTLB segment size (when using SWIOTLB).
v2: Tidy sg_mark_end() and cpp
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Imre Deak <imre.deak@intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161011082021.14606-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 11 Oct 2016 08:20:20 +0000 (09:20 +0100)]
drm/i915: Remove self-harming shrink_all on get_pages_gtt fail
When we notice the system under memory pressure, we try to evict some
driver pages before asking the VM to shrink all caches. As a final step
in that process, we tried to evict everything, including active buffers.
This is harming ourselves, and we can mix shrinking all caches as well
as our residual buffers (after the first pass of trying to shrink just
our own buffers).
Chris Wilson [Mon, 10 Oct 2016 12:50:17 +0000 (13:50 +0100)]
drm/i915: Fix conflict resolution from backmerge of v4.8-rc8 to drm-next
The conflict resolution of v4.8-rc8 backmerge to drm-next pulled back in
a few lines of dead code due to the code movement around
i915_gem_reset(), fix that up.
Fixes: ca09fb9f60b5 ("Merge tag 'v4.8-rc8' into drm-next") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161010125017.23911-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 7 Oct 2016 06:53:27 +0000 (07:53 +0100)]
drm/i915/guc: Unwind GuC workqueue reservation if request construction fails
We reserve space in the GuC workqueue for submitting the request in the
future. However, if we fail to construct the request, we need to give
that reserved space back to the system.
Chris Wilson [Fri, 7 Oct 2016 06:53:26 +0000 (07:53 +0100)]
drm/i915: Reset the breadcrumbs IRQ more carefully
Along with the interrupt, we want to restore the fake-irq and
wait-timeout detection. If we use the breadcrumbs interface to setup the
interrupt as it wants, the auxiliary timers will also be restored.
Chris Wilson [Fri, 7 Oct 2016 06:53:25 +0000 (07:53 +0100)]
drm/i915: Force relocations via cpu if we run out of idle aperture
If we run out of enough aperture space to fit the entire object, we
fallback to trying to insert a single page. However, if that also fails,
we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means
to userspace that their batch could not be fitted within the GTT.) Prior
to commit e8cb909ac3ab ("drm/i915: Fallback to single page GTT
mmappings for relocations") the approach is to fallback to using the
slow CPU relocation path in case of iomapping failure, and that is the
behaviour we need to restore.
Chris Wilson [Fri, 7 Oct 2016 06:53:24 +0000 (07:53 +0100)]
drm/i915: Distinguish last emitted request from last submitted request
In order not to trigger hangcheck on a idle-but-waiting engine, we need
to distinguish between the pending request queue and the actual
execution queue. This is done later in "drm/i915: Enable multiple
timelines" but for now we need a temporary fix to prevent blaming the
wrong engine for a GPU hang.
(Note that this causes a temporary subtle change in how we decide when
to allow a waitboost to be re-awarded back to the waiter, the temporary
effect is that if the wait is upon the most current execution the wait
is given for free, instead of checking to see if the client stalled
itself. This will be repaired in "drm/i915: Enable multiple timelines".)
Fixes: 0a046a0e93d2 ("drm/i915: Nonblocking request submission")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98104 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> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-1-chris@chris-wilson.co.uk
(cherry picked from commit 8687b3ec852e89630bac650f15136811c7b4c1dc) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Mon, 3 Oct 2016 07:55:16 +0000 (10:55 +0300)]
drm/i915: Allow DP to work w/o EDID
Allow returning "connected" or "unknown" connector status for DP branch
devices that don't have an EDID. Currently we'd claim the thing as
"disconnected" if there is no EDID.
This stuff used to broken already, I think, but it got more broken by
commit f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by: Arno <blouin.arno@gmail.com> Fixes: f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 5cb651a7959310ef4dbb0b93f005b10286789656) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Mon, 3 Oct 2016 07:55:15 +0000 (10:55 +0300)]
drm/i915: Move long hpd handling into the hotplug work
We can't rely on connector->status in the detect() hook if the long hpd
was already handled by the dig_port_work as that won't update
connector->status. Thus we have to defer the long hpd handling entirely
until the hotplug work runs to avoid the double long hpd handling
the "detect_done" flag is trying to prevent.
We'll start to depend on connector->status being up to date in a
following patch.
Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by: Arno <blouin.arno@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 27d4efc5591a5853de54713bc717de73c8951e17) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Tue, 4 Oct 2016 20:11:26 +0000 (21:11 +0100)]
drm/i915/execlists: Reinitialise context image after GPU hang
On Braswell, at least, we observe that the context image is written in
multiple phases. The first phase is to clear the register state, and
subsequently rewrite it. A GPU reset at the right moment can interrupt
the context update leaving it corrupt, and our update of the RING_HEAD
is not sufficient to restart the engine afterwards. To recover, we need
to reset the registers back to their original values. The context state
is lost. What we need is a better mechanism to serialise the reset with
pending flushes from the GPU.
Chris Wilson [Mon, 3 Oct 2016 12:45:15 +0000 (13:45 +0100)]
drm/i915: Unalias obj->phys_handle and obj->userptr
We use obj->phys_handle to choose the pread/pwrite path, but as
obj->phys_handle is a union with obj->userptr, we then mistakenly use
the phys_handle path for userptr objects within pread/pwrite.
Chris Wilson [Mon, 3 Oct 2016 12:45:14 +0000 (13:45 +0100)]
drm/i915: Just clear the mmiodebug before a register access
When we enable the per-register access mmiodebug, it is to detect which
access is illegal. Reporting on earlier untraced access outside of the
mmiodebug does not help debugging (as the suspicion is immediately put
upon the current register which is not at fault)!
Paulo Zanoni [Thu, 29 Sep 2016 19:36:48 +0000 (16:36 -0300)]
drm/i915/gen9: only add the planes actually affected by ddb changes
We were previously adding all the planes owned by the CRTC even when
the ddb partitioning didn't change for them. As a consequence, a lot
of functions were being called when we were just moving the cursor
around the screen, such as skylake_update_primary_plane().
This was causing flickering on the primary plane when moving the
cursor. I'm not 100% sure which operation caused the flickering, but
we were writing to a lot of registers, so it could be any of these
writes. With this patch, just moving the mouse won't add the primary
plane to the commit since it won't trigger a change in DDB
partitioning.
v2: Use skl_ddb_entry_equal() (Lyude).
v3: Change Reported-and-bisected-by: to Reported-by: for checkpatch
Fixes: 05a76d3d6ad1 ("drm/i915/skl: Ensure pipes with changed wms get added to the state")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97888 Cc: Mike Lothian <mike@fireburn.co.uk> Cc: stable@vger.kernel.org Reported-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Lyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475177808-29955-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 7f60e200e254cd53ad1bd74a56bdd23e813ac4b7) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Mon, 26 Sep 2016 08:30:46 +0000 (11:30 +0300)]
drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
forbidden to set it for LVDS/CRT as well. So let's also set it on
CRT to make it possible to share the DPLL between HDMI and CRT.
What that bit apparently does is enable the x5 clock to the port,
which then pumps out the bits on both edges of the clock. The DAC
doesn't need that clock since it's not pumping out bits, but I don't
think it hurts to have the DPLL output that clock anyway.
This is fairly important on IVB since it has only two DPLLs with three
pipes. So trying to drive three or more PCH ports with three pipes
is only possible when at least one of the DPLLs gets shared between
two of the pipes.
SNB doesn't really need to do this since it has only two pipes. It could
be done to avoid enabling the second DPLL at all in certain cases, but
I'm not sure that's such a huge win. So let's not do it for SNB, at
least for now. On ILK it never makes sense as the DPLLs can't be shared.
v2: Just always enable the high speed clock to keep things simple (Daniel)
Beef up the commit message a bit (Daniel)
Imre Deak [Mon, 26 Sep 2016 14:54:31 +0000 (17:54 +0300)]
drm/i915/bxt: Fix HDMI DPLL configuration
a277ca7dc01d should've been a no-functional-change commit, but it
removed the initialization of the dpll_hw_state for HDMI outputs,
resulting in state mismatches and a failed modeset with blank
screen. Fix this by reinstating the dpll_hw_state initialization.
v2:
- Make bxt_ddi_hdmi_set_dpll_hw_state() static.
Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474901671-22719-1-git-send-email-imre.deak@intel.com
(cherry picked from commit a04139c4cf289119cdfb6081af602f7a452fb7c2) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Paulo Zanoni [Thu, 22 Sep 2016 21:00:33 +0000 (18:00 -0300)]
drm/i915/gen9: fix the watermark res_blocks value
We forgot the "res_blocks += y_tile_minimum" that's described on step
V of our documentation.
Again, this should only affect the Y tiling cases.
It looks like the relevant code was introduced in 0fda65680e92, but
there's always the possibility that it matched our specification when
it was introduced, and then the specification changed while the code
stayed the same. So we can't really say this was a regression, but
let's try to add a "Fixes" tag anyway to help backporting.
Paulo Zanoni [Thu, 22 Sep 2016 21:00:32 +0000 (18:00 -0300)]
drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations
The confusing thing is that plane_blocks_per_line is listed as part of
the method 2 calculation but is also used for other things. We
calculated it in two different places and different ways: one inside
skl_wm_method2() and the other inside skl_compute_plane_wm(). The
skl_wm_method2() implementation is the one that matches the
specification.
With this patch we fix the skl_compute_plane_wm() calculation and just
pass it as a parameter to skl_wm_method2(). We also take care to not
modify the value of plane_bytes_per_line since we're going to rely on
it having a correct value in later patches.
This should affect the watermarks for Linear and Y-tiled.
From my analysis, it looks like the two plane_blocks_per_line
variables got out of sync on 0fda65680e92, but we can't really say
that commit was a regression, it looks like just an incomplete fix.
There's always the possibility that 0fda65680e92 matched our
specification at that time, and then later the specification changed.
Paulo Zanoni [Thu, 22 Sep 2016 21:00:31 +0000 (18:00 -0300)]
drm/i915/gen9: minimum scanlines for Y tile is not always 4
During watermarks calculations, this value is used in 3 different
places. Only one of them was not using a hardcoded 4. Move the code up
so everybody can benefit from the actual value.
This should only help on situations with Y tiling + 90/270 rotation +
1 or 2 bpp or NV12.
Paulo Zanoni [Thu, 22 Sep 2016 21:00:30 +0000 (18:00 -0300)]
drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
Bspec says:
"The mailbox response data may not account for memory read latency.
If the mailbox response data for level 0 is 0us, add 2 microseconds
to the result for each valid level."
This means we should only do the +2 in case wm[0] == 0, not always.
So split the sanitizing implementation from the WA implementation and
fix the WA implementation.
Paulo Zanoni [Thu, 22 Sep 2016 21:00:28 +0000 (18:00 -0300)]
drm/i915: introduce intel_has_sagv()
And use it to move knowledge about the SAGV-supporting platforms from
the callers to the SAGV code.
We'll add more platforms to intel_has_sagv(), so IMHO it makes more
sense to move all this to a single function instead of patching all
the callers every time we add SAGV support to a new platform.
v2: Move I915_SAGV_NOT_CONTROLLED to the new function (Lyude).
Paulo Zanoni [Thu, 22 Sep 2016 21:00:27 +0000 (18:00 -0300)]
drm/i915: SAGV is not SKL-only, so rename a few things
The plan is to introduce intel_has_sagv() and then use it to discover
which platforms actually support it.
I thought about keeping the functions with their current skl names,
but found two problems: (i) skl_has_sagv() would become a very
confusing name, and (ii) intel_atomic_commit_tail() doesn't seem to be
calling any functions whose name start with a platform name, so the
"intel_" naming scheme seems make more sense than the "firstplatorm_"
naming scheme here.
Paulo Zanoni [Fri, 19 Aug 2016 22:03:23 +0000 (19:03 -0300)]
drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+
We never remembered to set it (so it was zero), but this was not a
problem in the past due to the way handled the hardware registers.
Unfortunately we changed how we set the hardware and forgot to set
intel_crtc->dspaddr_offset.
This started to reflect on a few kms_frontbuffer_tracking subtests
that relied on page flips with CRTCs that don't point to the x:0,y:0
coordinates of the frontbuffer. After the page flip the CRTC was
showing the x:0,y:0 coordinate of the frontbuffer instead of
x:500,y:500. This problem is present even if we don't enable FBC or
PSR.
While trying to bisect it I realized that the first bad commit
actually just gives me a black screen for the mentioned tests instead
of showing the wrong x:0,y:0 offsets. A few commits later the black
screen problem goes away and we get to the point where the code is
today, but I'll consider the black screen as the first bad commit
since it's the point where the IGT subtests start to fail.
Fixes: 6687c9062c46 ("drm/i915: Rewrite fb rotation GTT handling")
Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-pgflip-blt
Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-evflip-blt
Testcase: kms_frontbuffer_tracking/fbc-1p-shrfb-fliptrack Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471644203-23463-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 4c0b8a8bc49c477be9467f614b6b4ec479736019) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Wed, 21 Sep 2016 13:51:07 +0000 (14:51 +0100)]
drm/i915: Only shrink the unbound objects during freeze
At the point of creating the hibernation image, the runtime power manage
core is disabled - and using the rpm functions triggers a warn.
i915_gem_shrink_all() tries to unbind objects, which requires device
access and so tries to how an rpm reference triggering a warning:
Chris Wilson [Wed, 21 Sep 2016 13:51:06 +0000 (14:51 +0100)]
drm/i915: Restore current RPS state after reset
Following commit 821ed7df6e2a ("drm/i915: Update reset path to fix
incomplete requests") we no longer mark the context as lost on reset as
we keep the requests (and contexts) alive. However, RPS remains reset
and we need to restore the current state to match the in-flight
requests.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824 Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk
(cherry picked from commit f2a91d1a6f5960c08f1ca60bd076f4dc020c50c6) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Imre Deak [Wed, 14 Sep 2016 10:04:13 +0000 (13:04 +0300)]
drm/i915: Unlock PPS registers after GPU reset
Reapply the PPS register unlock workaround after GPU reset on platforms
where the reset clobbers the display HW state. This at least gets rid of
the related WARN during LVDS encoder enabling on PNV.
Shawn Lee [Mon, 19 Sep 2016 10:35:26 +0000 (13:35 +0300)]
drm/i915/backlight: setup backlight pwm alternate increment on backlight enable
Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.
v2 by Jani, rebase on the patch caching alt increment
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
References: https://bugs.freedesktop.org/show_bug.cgi?id=67454 Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Wei Shun Chen <wei.shun.chang@intel.com> Cc: Gary C Wang <gary.c.wang@intel.com> Cc: stable@vger.kernel.org # v4.4+ 16e1203db8ab drm/i915/backlight: setup and cache... Cc: stable@vger.kernel.org # v4.4+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Shawn Lee <shawn.c.lee@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com
(cherry picked from commit e29aff05f239f8dd24e9ee7816fd96726e20105a) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Wed, 5 Oct 2016 17:40:56 +0000 (18:40 +0100)]
drm: Fix up kerneldoc for new drm_gem_dmabuf_export()
I hit send before completing a make htmldoc, and lo I forgot to fix up
the cut'n'paste.
Fixes: a4fce9cb782a ("drm/prime: Take a ref on the drm_dev when exporting...") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161005174056.29869-1-chris@chris-wilson.co.uk
Dave Airlie [Mon, 10 Oct 2016 06:40:16 +0000 (16:40 +1000)]
Merge branch 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-next
Just some misc bug fixes for 4.9.
* 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: revert "use more than 64KB fragment size if possible"
drm/amdgpu: warn if dp aux is still attached on free
drm/amdgpu/dce11: add missing drm_mode_config_cleanup call
drm/amdgpu: also track late init state
drm/amdgpu/virtual_dce: adjust config ifdef
drm/amdgpu/vce: add support for hw config packet (v2)
drm/amdgpu: clean up to set fw_offset as 0 twice
drm/amdgpu: remove DRM_AMD_POWERPLAY
drm/radeon: Prevent races on pre DCE4 between flip submission and completion.
drm/radeon: Slightly more robust flip completion handling for < DCE-4
Dave Airlie [Mon, 10 Oct 2016 06:36:16 +0000 (16:36 +1000)]
Merge tag 'topic/drm-misc-2016-10-05' of git://anongit.freedesktop.org/drm-intel into drm-next
Another attempt, this time rebased and without the pipe crc patches:
- display_info cleanups from Ville
- make prime/gem lookups faster with rbtrees (Chris)
- misc stuff all over
* tag 'topic/drm-misc-2016-10-05' of git://anongit.freedesktop.org/drm-intel:
drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it
drm/bridge: analogix_dp: Add analogix_dp_psr_supported
drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops
drm: Document caveats around atomic event handling
uapi: add missing install of sync_file.h
drm: Simplify drm_printk to reduce object size quite a bit
drm/i915: Account for sink max TMDS clock when checking the port clock
drm/i915: Replace a bunch of connector->base.display_info with a local variable
drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()
drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID
drm/edid: Reduce the number of times we parse the CEA extension block
drm/edid: Don't pass around drm_display_info needlessly
drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info
drm/edid: Make max_tmds_clock kHz instead of MHz
drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID
drm/edid: Clear old audio latency values before parsing the new EDID
drm: Convert prime dma-buf <-> handle to rbtree
drm/mediatek: mark symbols static where possible
drm/rockchip: mark symbols static where possible
drm/rockchip: add missing header dependencies
Dave Airlie [Mon, 10 Oct 2016 06:32:58 +0000 (16:32 +1000)]
Merge tag 'drm-vc4-next-2016-10-06' of https://github.com/anholt/linux into drm-next
This pull request brings in several fixes for drm-next, mostly for
HDMI.
* tag 'drm-vc4-next-2016-10-06' of https://github.com/anholt/linux:
drm/vc4: Add support for double-clocked modes.
drm/vc4: Set up the AVI and SPD infoframes.
drm/vc4: Fix support for interlaced modes on HDMI.
drm/vc4: Increase timeout for HDMI_SCHEDULER_CONTROL changes.
drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.
drm/vc4: Enable limited range RGB output on HDMI with CEA modes.
drm/vc4: Fix races when the CS reads from render targets.
drm/vc4: cleanup with list_first_entry_or_null()
Maxime Ripard [Fri, 30 Sep 2016 14:37:06 +0000 (16:37 +0200)]
drm/bridge: Add RGB to VGA bridge support
Some boards have an entirely passive RGB to VGA bridge, based on DACs
implemented by resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either based on the EDIDs if available, or based on the XGA
standards.
Chris Wilson [Fri, 7 Oct 2016 06:53:27 +0000 (07:53 +0100)]
drm/i915/guc: Unwind GuC workqueue reservation if request construction fails
We reserve space in the GuC workqueue for submitting the request in the
future. However, if we fail to construct the request, we need to give
that reserved space back to the system.
Fixes: dadd481bfe55 ("drm/i915/guc: Prepare for nonblocking execbuf submission")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-4-chris@chris-wilson.co.uk
Chris Wilson [Fri, 7 Oct 2016 06:53:26 +0000 (07:53 +0100)]
drm/i915: Reset the breadcrumbs IRQ more carefully
Along with the interrupt, we want to restore the fake-irq and
wait-timeout detection. If we use the breadcrumbs interface to setup the
interrupt as it wants, the auxiliary timers will also be restored.
Chris Wilson [Fri, 7 Oct 2016 06:53:25 +0000 (07:53 +0100)]
drm/i915: Force relocations via cpu if we run out of idle aperture
If we run out of enough aperture space to fit the entire object, we
fallback to trying to insert a single page. However, if that also fails,
we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means
to userspace that their batch could not be fitted within the GTT.) Prior
to commit e8cb909ac3ab ("drm/i915: Fallback to single page GTT
mmappings for relocations") the approach is to fallback to using the
slow CPU relocation path in case of iomapping failure, and that is the
behaviour we need to restore.
Fixes: e8cb909ac3ab ("drm/i915: Fallback to single page GTT mmappings...")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98101 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-2-chris@chris-wilson.co.uk
Chris Wilson [Fri, 7 Oct 2016 06:53:24 +0000 (07:53 +0100)]
drm/i915: Distinguish last emitted request from last submitted request
In order not to trigger hangcheck on a idle-but-waiting engine, we need
to distinguish between the pending request queue and the actual
execution queue. This is done later in "drm/i915: Enable multiple
timelines" but for now we need a temporary fix to prevent blaming the
wrong engine for a GPU hang.
(Note that this causes a temporary subtle change in how we decide when
to allow a waitboost to be re-awarded back to the waiter, the temporary
effect is that if the wait is upon the most current execution the wait
is given for free, instead of checking to see if the client stalled
itself. This will be repaired in "drm/i915: Enable multiple timelines".)
Fixes: 0a046a0e93d2 ("drm/i915: Nonblocking request submission")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98104 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> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-1-chris@chris-wilson.co.uk
Eric Anholt [Thu, 29 Sep 2016 22:34:44 +0000 (15:34 -0700)]
drm/vc4: Add support for double-clocked modes.
Now that we have infoframes to report the pixel repeat flag, we can
start using it. Fixes locking the 720x480i and 720x576i modes on my
Dell 2408WFP. Like the 1920x1080i case, they don't fit properly on
the screen, though.
Eric Anholt [Thu, 29 Sep 2016 00:30:25 +0000 (17:30 -0700)]
drm/vc4: Fix support for interlaced modes on HDMI.
We really do need to be using the halved V fields. I had been
confused by the code I was using as a reference because it stored
halved vsync fields but not halved vdisplay, so it looked like I only
needed to divide vdisplay by 2.
This reverts part of Mario's timestamping fixes that prevented
CRTC_HALVE_V from applying, and instead adjusts the timestamping code
to not use the crtc field in that case.
Fixes locking of 1920x1080x60i on my Dell 2408WFP. There are black
bars on the top and bottom, but I suspect that might be an
under/overscan flags problem as opposed to video timings.
Eric Anholt [Thu, 29 Sep 2016 00:21:05 +0000 (17:21 -0700)]
drm/vc4: Increase timeout for HDMI_SCHEDULER_CONTROL changes.
Fixes occasional debug spew at boot when connected directly through
HDMI, and probably confusing the HDMI state machine when we go trying
to poke registers for the enable sequence too soon.
Eric Anholt [Wed, 14 Sep 2016 18:21:29 +0000 (19:21 +0100)]
drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.
On Pi0/1/2, we use an external GPIO line for hotplug detection, since
the HDMI_HOTPLUG register isn't connected to anything. However, with
the Pi3 the HPD GPIO line has moved off to a GPIO expander that will
be tricky to get to (the firmware is constantly polling the expander
using i2c0, so we'll need to coordinate with it).
As a stop-gap, if we don't have a GPIO line, use an EDID probe to
detect connection. Fixes HDMI display on the pi3.
Eric Anholt [Tue, 27 Sep 2016 16:03:13 +0000 (09:03 -0700)]
drm/vc4: Fix races when the CS reads from render targets.
With the introduction of bin/render pipelining, the previous job may
not be completed when we start binning the next one. If the previous
job wrote our VBO, IB, or CS textures, then the binning stage might
get stale or uninitialized results.
Fixes the major rendering failure in glmark2 -b terrain.
Signed-off-by: Eric Anholt <eric@anholt.net> Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Cc: stable@vger.kernel.org
The block size is indeed an equal match, so this can cause performance regressions.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
drm/amdgpu: warn if dp aux is still attached on free
If this happens (and it recently did), we free a structure while part of
it is still in use, which results in non-obvious crashes. The way it's
detached is not trivial (DRM core has to call the connector .destroy
callback and things must be torn down in the right order), so better
detect it and warn early.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Successful sw_init() and hw_init() states are tracked, but not
late_init(). Various error paths may result in amdgpu_fini() being
called before .late init is done, so late_init needs to be tracked
to avoid unexpected or multiple .late_fini() calls.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ville Syrjälä [Mon, 26 Sep 2016 09:20:46 +0000 (12:20 +0300)]
drm/i915: Add spurious CRT DMI match for Intel DZ77BH-55K
Intel DZ77BH-55K board doest't have a physical VGA connector,
and yet it always detects that something is connected there.
Add it to the DMI blacklist to ignore the spurious detection
results.
Allows me to drop 'video=VGA-1:d' from my kernel cmdline.
Ville Syrjälä [Mon, 26 Sep 2016 09:20:45 +0000 (12:20 +0300)]
drm/i915: Register shadow VGA even when it produces spurious detection results
Having a shadow VGA connector is useful for testing purposes. We
currently skip registering the connector on machines where the
CRT detect falsely reports it as connected. Let's instead move the
the blacklist check to the detect callback (and hpd setup) and
if we get a match we always report the connector as disconnected.
This way we get a shadow VGA connector to help with testing, while
we still avoid the user facing problems from the incorrect
detection results.
commit 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT
initialization on ZGB") doesn't provide much in the way of details
as to why 'ACER ZGB' was added to the blacklist. Trying to trace it
further leads me to a chromeos bugreport I can't access. So based on
the fact that the commit added the
"/* Skip machines without VGA that falsely report hotplug events */"
comment, I'm going to assume that it was just spurious CRT detection.
So it should be safe to move the blacklist to just block the detection
and hpd without causing a regression on said machine.
In fact Stéphane confirmed on irc that the problem was indeed just
crappy hotplug detect:
"22:29 < marcheu> vsyrjala: the port isn't there, but the load detect is
improperly stubbed in hw
22:29 < marcheu> vsyrjala: so it floats"
so this change should be perfectly fine.
According to [1] Dell XPS8700 VBT says 'int_crt_support 0', so thanks
to commit e4abb733bb72 ("drm/i915: Check VBT for CRT port presence on
HSW/BDW") we no longer need to blacklist it based on DMI.
Looking through the bug report, SFUSE_STRAP based detection was
apparently also tried and failed, but the VBT based one should still
work just fine.
The commit says that the symptom was a frozen machine, but based on the
bug report it doesn't look like the CRT detection was at least directly
responsible for such a drastic outcome.
Chris Wilson [Wed, 5 Oct 2016 12:21:44 +0000 (13:21 +0100)]
drm/prime: Take a ref on the drm_dev when exporting a dma_buf
dma_buf may live a long time, longer than the last direct user of the
driver. We already hold a reference to the owner module (that prevents
the object code from disappearing), but there is no reference to the
drm_dev - so the pointers to the driver backend themselves may vanish.
v2: Resist temptation to fix the bug in armada_gem.c not setting the
correct flags on the exported dma-buf (it should pass the flags through
and not be arbitrarily setting O_RDWR).
Use a common wrapper for exporting the dmabuf and acquiring the
reference to the drm_device.
Testcase: igt/vgem_basic/unload Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Tested-by: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 5 Oct 2016 12:21:43 +0000 (13:21 +0100)]
drm/prime: Pass the right module owner through to dma_buf_export()
dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right
owner from the device->fops instead.
v2: Use C99 initializers to zero out unset elements of
dma_buf_export_info
v3: Extract the right module from dev->fops.
Testcase: igt/vgem_basic/unload Reported-by: Petri Latvala <petri.latvala@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Tested-by: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-1-chris@chris-wilson.co.uk
Joonas Lahtinen [Wed, 5 Oct 2016 10:50:16 +0000 (13:50 +0300)]
drm/i915: Reduce trickery in DEV_INFO_FOR_EACH_FLAG
Get rid of SEP_SEMICOLON and SEP_BLANK in DEV_INFO_FOR_EACH_FLAG.
Consolidate the debug output so that instead of one huge line with
"cap1,cap2,capN" each capability is split to own line and displayed
as "capN: [yes|no]" to make the dumps more historically informative.
v2:
- Do not break auto-indent by keeping semicolon after macro (Jani)
- Consolidate and use yesno() in all locations (Chris)
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Ville Syrjälä [Mon, 3 Oct 2016 07:55:16 +0000 (10:55 +0300)]
drm/i915: Allow DP to work w/o EDID
Allow returning "connected" or "unknown" connector status for DP branch
devices that don't have an EDID. Currently we'd claim the thing as
"disconnected" if there is no EDID.
This stuff used to broken already, I think, but it got more broken by
commit f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by: Arno <blouin.arno@gmail.com> Fixes: f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Ville Syrjälä [Mon, 3 Oct 2016 07:55:15 +0000 (10:55 +0300)]
drm/i915: Move long hpd handling into the hotplug work
We can't rely on connector->status in the detect() hook if the long hpd
was already handled by the dig_port_work as that won't update
connector->status. Thus we have to defer the long hpd handling entirely
until the hotplug work runs to avoid the double long hpd handling
the "detect_done" flag is trying to prevent.
We'll start to depend on connector->status being up to date in a
following patch.
Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by: Arno <blouin.arno@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
projects / karo-tx-linux.git / log