This removes the 'write' and 'force' from get_user_pages_remote() and
replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in
callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull drm updates from Dave Airlie:
"Core:
- Fence destaging work
- DRIVER_LEGACY to split off legacy drm drivers
- drm_mm refactoring
- Splitting drm_crtc.c into chunks and documenting better
- Display info fixes
- rbtree support for prime buffer lookup
- Simple VGA DAC driver
Panel:
- Add Nexus 7 panel
- More simple panels
i915:
- Refactoring GEM naming
- Refactored vma/active tracking
- Lockless request lookups
- Better stolen memory support
- FBC fixes
- SKL watermark fixes
- VGPU improvements
- dma-buf fencing support
- Better DP dongle support
amdgpu:
- Powerplay for Iceland asics
- Improved GPU reset support
- UVD/VEC powergating support for CZ/ST
- Preinitialised VRAM buffer support
- Virtual display support
- Initial SI support
- GTT rework
- PCI shutdown callback support
- HPD IRQ storm fixes
amdkfd:
- bugfixes
tilcdc:
- Atomic modesetting support
mediatek:
- AAL + GAMMA engine support
- Hook up gamma LUT
- Temporal dithering support
imx:
- Pixel clock from devicetree
- drm bridge support for LVDS bridges
- active plane reconfiguration
- VDIC deinterlacer support
- Frame synchronisation unit support
- Color space conversion support
analogix:
- PSR support
- Better panel on/off support
rockchip:
- rk3399 vop/crtc support
- PSR support
vc4:
- Interlaced vblank timing
- 3D rendering CPU overhead reduction
- HDMI output fixes
tda998x:
- HDMI audio ASoC support
sunxi:
- Allwinner A33 support
- better TCON support
msm:
- DT binding cleanups
- Explicit fence-fd support
sti:
- remove sti415/416 support
etnaviv:
- MMUv2 refactoring
- GC3000 support
exynos:
- Refactoring HDMI DCC/PHY
- G2D pm regression fix
- Page fault issues with wait for vblank
There is no nouveau work in this tree, as Ben didn't get a pull
request in, and he was fighting moving to atomic and adding mst
support, so maybe best it waits for a cycle"
* tag 'drm-for-v4.9' of git://people.freedesktop.org/~airlied/linux: (1412 commits)
drm/crtc: constify drm_crtc_index parameter
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
...
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
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: ca09fb9f60 ("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
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: dadd481bfe ("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
(cherry picked from commit 5ba899082c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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.
v2: Cancel both timers as well, sanitize the IMR.
Fixes: 821ed7df6e ("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>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-3-chris@chris-wilson.co.uk
(cherry picked from commit ad07dfcddf)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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 e8cb909ac3 ("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: e8cb909ac3 ("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
(cherry picked from commit d7f7633557)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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: 0a046a0e93 ("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 8687b3ec85)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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 f21a21983e ("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: f21a21983e ("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 5cb651a795)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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 27d4efc559)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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.
Fixes: 821ed7df6e ("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>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161004201132.21801-2-chris@chris-wilson.co.uk
(cherry picked from commit a3aabe86a3)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When decoding the semaphores inside hangcheck, we need to use the hw-id
and not the local array index.
Fixes: de1add3605 ("drm/i915: Decouple execbuf uAPI ...")
Testcase: igt/gem_exec_whisper/hang # gen6-7
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: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-3-chris@chris-wilson.co.uk
(cherry picked from commit 348b9b1192)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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: 05a76d3d6a ("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 7f60e200e2)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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)
Cc: Nick Yamane <nick.diego@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Tested-by: Nick Yamane <nick.diego@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97204
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474878646-17711-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 7d7f8633a8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
a277ca7dc0 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: a277ca7dc0 ("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 a04139c4cf)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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 0fda65680e, 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.
v2: Try to add a "Fixes" tag (Maarten).
Fixes: 0fda65680e ("drm/i915/skl: Update watermarks for Y tiling")
Cc: stable@vger.kernel.org
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-8-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 75676ed423)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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 0fda65680e, but we can't really say
that commit was a regression, it looks like just an incomplete fix.
There's always the possibility that 0fda65680e matched our
specification at that time, and then later the specification changed.
v2: Try to add a "Fixes" tag (Maarten).
Fixes: 0fda65680e ("drm/i915/skl: Update watermarks for Y tiling")
Cc: stable@vger.kernel.org
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-7-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 7a1a8aed67)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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.
Cc: stable@vger.kernel.org
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-6-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 1186fa85eb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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.
v2: Add Fixes tag (Maarten).
Fixes: 367294be7c ("drm/i915/gen9: Add 2us read latency to WM level")
Cc: stable@vger.kernel.org
Cc: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-5-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 0727e40a48)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
According to BSpec, it's the "core CPUs" that need the code, which
means SKL and KBL, but not BXT.
I don't have a KBL to test this patch on it.
v2: Only SKL should have I915_SAGV_NOT_CONTROLLED.
Cc: stable@vger.kernel.org
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-4-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 6e3100ec21)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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).
Cc: stable@vger.kernel.org
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-3-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 56feca9197)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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.
Cc: stable@vger.kernel.org
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-2-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 16dcdc4edb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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: 6687c9062c ("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 4c0b8a8bc4)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Following commit 821ed7df6e ("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: 821ed7df6e ("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 f2a91d1a6f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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.
Fixes: ed6143b8f7 ("drm/i915/lvds: Restore initial HW state during encoder enabling")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473847453-4771-1-git-send-email-imre.deak@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 51f592050a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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
It's perfectly legal for the sink to support 12bpc only for
some lower resolution modes, while the higher resolution modes
can only be used with 8bpc. So let's take the sink's max TMDS clock
into account before we go and decide that a particular mode can
be used with 12bpc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-11-git-send-email-ville.syrjala@linux.intel.com
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJX6H4uAAoJEHm+PkMAQRiG5sMH/3yzrMiUCSokdS+cvY+jgKAG
JS58JmRvBPz2mRaU3MRPBGRDeCz/Nc9LggL2ZcgM+E1ZYirlYyQfIED3lkqk5R07
kIN1wmb+kQhXyU4IY3fEX7joqyKC6zOy4DUChPkBQU0/0+VUmdVmcJvsuPlnMZtf
g95m0BdYTui+eDezASRqOEp3Lb5ONL4c3ao4yBP0LHF033ctj3VJQiyi5uERPZJ0
5e6Mo7Wxn78t9WqJLQAiEH46kTwT2plNlxf3XXqTenfIdbWhqE873HPGeSMa3VQV
VywXTpCpSPQsA8BYg66qIbebdKOhs9MOviHVfqDtwQlvwhjlBDya0gNHfI5fSy4=
=Y/L5
-----END PGP SIGNATURE-----
Merge tag 'v4.8-rc8' into drm-next
Linux 4.8-rc8
There was a lot of fallout in the imx/amdgpu/i915 drivers, so backmerge
it now to avoid troubles.
* tag 'v4.8-rc8': (1442 commits)
Linux 4.8-rc8
fault_in_multipages_readable() throws set-but-unused error
mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing
radix tree: fix sibling entry handling in radix_tree_descend()
radix tree test suite: Test radix_tree_replace_slot() for multiorder entries
fix memory leaks in tracing_buffers_splice_read()
tracing: Move mutex to protect against resetting of seq data
MIPS: Fix delay slot emulation count in debugfs
MIPS: SMP: Fix possibility of deadlock when bringing CPUs online
mm: delete unnecessary and unsafe init_tlb_ubc()
huge tmpfs: fix Committed_AS leak
shmem: fix tmpfs to handle the huge= option properly
blk-mq: skip unmapped queues in blk_mq_alloc_request_hctx
MIPS: Fix pre-r6 emulation FPU initialisation
arm64: kgdb: handle read-only text / modules
arm64: Call numa_store_cpu_info() earlier.
locking/hung_task: Fix typo in CONFIG_DETECT_HUNG_TASK help text
nvme-rdma: only clear queue flags after successful connect
i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended
perf/core: Limit matching exclusive events to one PMU
...
* the only remaining callers of "short" fault-ins are just as happy with generic
variants (both in lib/iov_iter.c); switch them to multipage variants, kill the
"short" ones
* rename the multipage variants to now available plain ones.
* get rid of compat macro defining iov_iter_fault_in_multipage_readable by
expanding it in its only user.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
- refactor the sseu code (Imre)
- refine guc dmesg output (Dave Gordon)
- more vgpu work
- more skl wm fixes (Lyude)
- refactor dpll code in prep for upfront link training (Jim Bride et al)
- consolidate all platform feature checks into intel_device_info (Carlos Santa)
- refactor elsp/execlist submission as prep for re-submission after hang
recovery and eventually scheduling (Chris Wilson)
- allow synchronous gpu reset handling, to remove tricky/impossible/fragile
error recovery code (Chris Wilson)
- prep work for nonblocking (execlist) submission, using fences to track
depencies and drive elsp submission (Chris Wilson)
- partial error recover/resubmission of non-guilty batches after hangs (Chris Wilson)
- full dma-buf implicit fencing support (Chris Wilson)
- dp link training fixes (Jim, Dhinkaran, Navare, ...)
- obey dp branch device pixel rate/bpc/clock limits (Mika Kahola), needed for
many vga dongles
- bunch of small cleanups and polish all over, as usual
[airlied: printing macros collided]
* tag 'drm-intel-next-2016-09-19' of git://anongit.freedesktop.org/drm-intel: (163 commits)
drm/i915: Update DRIVER_DATE to 20160919
drm: Fix DisplayPort branch device ID kernel-doc
drm/i915: use NULL for NULL pointers
drm/i915: do not use 'false' as a NULL pointer
drm/i915: make intel_dp_compute_bpp static
drm: Add DP branch device info on debugfs
drm/i915: Update bits per component for display info
drm/i915: Check pixel rate for DP to VGA dongle
drm/i915: Read DP branch device SW revision
drm/i915: Read DP branch device HW revision
drm/i915: Cleanup DisplayPort AUX channel initialization
drm: Read DP branch device id
drm: Helper to read max bits per component
drm: Helper to read max clock rate
drm: Drop VGA from bpc definitions
drm: Add missing DP downstream port types
drm/i915: Add ddb size field to device info structure
drm/i915/guc: general tidying up (submission)
drm/i915/guc: general tidying up (loader)
drm/i915: clarify PMINTRMSK/pm_intr_keep usage
...
Fix sparse warning:
drivers/gpu/drm/i915/intel_dp.c:1527:5: warning: symbol
'intel_dp_compute_bpp' was not declared. Should it be static?
Fixes: f9bb705e65 ("drm/i915: Update bits per component for display info")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473946137-1931-1-git-send-email-jani.nikula@intel.com
Read DisplayPort branch device info from through debugfs
interface.
v2: use drm_dp_helper routines to collect data
v3: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v4: move DP branch device info to function 'intel_dp_branch_device_info()'
v5: initial step to move debugging info from intel_dp. to drm_dp_helper.c (Daniel)
v6: read hw and sw revision without using specific drm_dp_helper routines
v7: indentation fixes (Jim Bride)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-12-git-send-email-mika.kahola@intel.com
DisplayPort branch device may define max supported bits per
component. Update display info based on this value if bpc
is defined.
v2: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v3: Fill bpc for connector's display info in separate
drm_dp_helper function (Daniel)
v4: remove updating bpc for display info as it may be overridden
when parsing EDID. Instead, check bpc for DP branch device
during compute_config
v5: Indentation fixes (Jim Bride)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-11-git-send-email-mika.kahola@intel.com
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
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-10-git-send-email-mika.kahola@intel.com
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)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-9-git-send-email-mika.kahola@intel.com
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)
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-8-git-send-email-mika.kahola@intel.com
Adding the ddb size into the devide info will avoid
platform checks while computing wm.
v2: Added comment and WARN_ON if ddb size is zero.(Jani)
v3: Added WARN_ON at the right place.(Jani)
Suggested-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473931870-7724-1-git-send-email-m.deepak@intel.com
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.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473711577-11454-2-git-send-email-david.s.gordon@intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
