Xu Han
5cf5fe8f72
drm/i915/gvt: Update MMIO handle policy to compatible KBL platform.
...
Update MMIO handle policy to KBL platform.
Signed-off-by: Xu Han <xu.han@intel.com >
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com >
2017-03-29 15:28:51 +08:00
Xu Han
18af19dbe1
drm/i915/gvt: Add KBL platform definition.
...
Add KBL platform definition.
Signed-off-by: Xu Han <xu.han@intel.com >
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com >
2017-03-29 15:28:51 +08:00
Zhenyu Wang
7a7a65617b
drm/i915/gvt: Add mdev device attribute group
...
This adds initial attribute group for mdev to hold vGPU related
for each mdev device, currently just vGPU id is shown.
v2: rename group name as "intel_vgpu"
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com >
Reviewed-by: Kevin Tian <kevin.tian@intel.com >
2017-03-29 15:28:51 +08:00
Pei Zhang
e2e02cbb5b
drm/i915/gvt: make dpcd_fix_data supports DP1.2
...
GVT-g will emulate a fixed DPCD data to VM for DP/eDP panel. Update
this data to latest DP1.2 with the maximum lane bandwidth of 5.4G/s
to support 4K resolution in VM.
V3: modify patch comment
V2: add inline comment to describe the dpcd_fix_data.
Signed-off-by: Pei Zhang <pei.zhang@intel.com >
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com >
2017-03-29 15:28:51 +08:00
Weinan Li
88a16b64c3
drm/i915/gvt: emulate SKL_FUSE_STATUS and LCPLL_CTL for virtual monitor detection
...
Initialize the correct vreg for virtual monitor.
Set PG0/1/2 distribution and fuse download done in SKL_FUSE_STATUS.
Set PLL_ENABLE and PLL_LOCK in LCPLL_CTL.
Guest may need to check these registers for display monitor detection
on Skylake platforms.
Signed-off-by: Weinan Li <weinan.z.li@intel.com >
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com >
2017-03-29 15:28:51 +08:00
Daniel Vetter
c276be4f38
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued
...
Backmerge drm-next one more because Dave fumbled the conflict
resolution slightly and I didn't notice it. We need Zhenyu's hotfix
before he can assemble the gvt pull ...
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
2017-03-29 09:20:33 +02:00
Daniel Vetter
d26f96c74d
drm/atomic-helper: remove backoff hack from disable/update_plane
...
We can now properly retry at the top level, yay!
v2: Also remove the temporary acquire_ctx hack again, no longer
needed!
Reviewed-by: Harry Wentland <harry.wentland@amd.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-6-daniel.vetter@ffwll.ch
2017-03-29 09:15:06 +02:00
Daniel Vetter
1931529448
drm: Add acquire ctx parameter to ->plane_disable
...
Nouveau had a few direct calls to ->disable_plane, I replaced those
with drm_plane_force_disable. Same story for shmob.
Otherwise no code changes.
Cc: Ben Skeggs <bskeggs@redhat.com >
Cc: Russell King <linux@armlinux.org.uk >
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Reviewed-by: Harry Wentland <harry.wentland@amd.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-5-daniel.vetter@ffwll.ch
2017-03-29 09:14:58 +02:00
Daniel Vetter
5fbef3ee4a
drm: drm_plane_force_disable is not for atomic drivers
...
This way I can explain why it'll be fine to pass a NULL acquire ctx
here in the next patch.
Reviewed-by: Harry Wentland <harry.wentland@amd.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-4-daniel.vetter@ffwll.ch
2017-03-29 09:14:49 +02:00
Daniel Vetter
34a2ab5e06
drm: Add acquire ctx parameter to ->update_plane
...
Just rolling it out, no code change here.
Cc: Ben Skeggs <bskeggs@redhat.com >
Cc: Russell King <linux@armlinux.org.uk >
Cc: Rob Clark <robdclark@gmail.com >
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Eric Anholt <eric@anholt.net >
Reviewed-by: Harry Wentland <harry.wentland@amd.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-3-daniel.vetter@ffwll.ch
2017-03-29 09:14:01 +02:00
Daniel Vetter
232e8f703b
drm: Wire up proper acquire ctx for plane functions
...
This is just prep work to get an acquire ctx into every place where we
call ->update_plane or ->disable_plane.
v2: Keep the hidden acquire_ctx pointers valid while transitioning.
Reviewed-by: Harry Wentland <harry.wentland@amd.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-2-daniel.vetter@ffwll.ch
2017-03-29 09:13:44 +02:00
Zhenyu Wang
8bcad07a45
drm/i915/gvt: fix error return check for copy_gma_to_hva()
...
From commit 73dec95e6b73dec95e6be5c1ff1475airlied@redhat.com >
Cc: Tina Zhang <tina.zhang@intel.com >
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com >
Signed-off-by: Dave Airlie <airlied@redhat.com >
2017-03-29 13:38:01 +10:00
Jani Nikula
9a86cda07a
drm/i915/dp: reduce link M/N parameters
...
Several major vendor USB-C->HDMI converters, in particular the DA200,
fail to recover a 5.4 GHz 1 lane signal if the link N is greater than
0x80000.
The link M and N depend on the pixel clock and link clock ratio. With
current code link N exceeds 0x80000 only when link clock >= 540000
kHz. Except for the eDP intermediate link clocks, at least the four
least significant bits are always zero. Just one bit shift right would
be enough to bring even the DP 1.4 810000 kHz link clock under 0x80000
link N. The pixel clock for modes that require a link clock >= 540000
kHz would also have several least significant bits zero. Unless the user
provides a mode with an odd pixel clock value, we can reduce the numbers
to reach the goal, with no loss in precision.
The DP spec even mentions sources making choices that "allow for static
and relatively small Mvid and Nvid values", thus reducing the link M/N
regardless of the sink in question seems justified.
Everything here is based on the work and information gathered by Clint
Taylor <clinton.a.taylor@intel.com >. This is just an iteration to reduce
the parameters regardless of lane count, link rate, or sink.
Reference: http://patchwork.freedesktop.org/patch/msgid/1490225256-11667-1-git-send-email-clinton.a.taylor@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Tested-by: Mads <mads@ab3.no >
Tested-by: PJ <foobar@pjmodos.net >
Tested-by: François Guerraz <kubrick@fgv6.net >
Tested-by: Lev Popov <leo@nabam.net >
Tested-by: Igor Krivenko <igor.s.krivenko@gmail.com >
Tested-by: Clint Taylor <clinton.a.taylor@intel.com >
Reviewed-by: Clint Taylor <clinton.a.taylor@intel.com >
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com >
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Cc: Clint Taylor <clinton.a.taylor@intel.com >
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Cc: Daniel Vetter <daniel.vetter@ffwll.ch >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1490614405-23337-1-git-send-email-jani.nikula@intel.com
2017-03-28 18:18:23 +03:00
Chris Wilson
090e5fe3f0
drm/i915: Take rpm wakelock around debugfs/i915_gpu_info
...
Capturing GPU state requires the device to be awake in order to read
registers. Normally, this is taken along the error handler, but for the
direct debugfs access, we cannot make assumptions about the current
device state and so either need to wake it up, or abort.
Fixes: 5a4c6f1b1bchris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170328131407.14863-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-03-28 15:59:12 +01:00
Imre Deak
f5073824ef
drm/i915: WARN if the core runtime PM get helpers fail
...
We don't expect the core runtime PM get helpers to return any error, so
add a WARN for this. Also print the return value for all the callsites
to help debugging.
v2:
- Don't call pm_runtime_get_sync() as part of initing locals. (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/1490693935-12638-1-git-send-email-imre.deak@intel.com
2017-03-28 16:02:10 +03:00
Matthew Auld
0a309f9e3d
drm/i915/perf: remove user triggerable warn
...
Don't throw a warning if we are given an invalid property id. While
here let's also bring back Robert' original idea of catching unhandled
enumeration values at compile time.
Fixes: eec688e142matthew.auld@intel.com >
Cc: Robert Bragg <robert@sixbynine.org >
Reviewed-by: Robert Bragg <robert@sixbynine.org >
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170327203236.18276-1-matthew.auld@intel.com
2017-03-28 14:52:43 +03:00
Jani Nikula
c1aecc5376
drm/i915: update the firmware download URL
...
The old URL works but gives 301 Moved Permanently. Update.
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1489574966-27200-1-git-send-email-jani.nikula@intel.com
2017-03-28 11:17:37 +03:00
Daniel Vetter
4adda532c0
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued
...
Backmerge drm-next to get at -rc4, which we need to land the 4.12 gvt
patches.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
2017-03-28 10:02:45 +02:00
Dave Airlie
e5c1ff1475
Backmerge tag 'v4.11-rc4' into drm-next
...
Linux 4.11-rc4
The i915 GVT team need the rc4 code to base some more code on.
2017-03-28 17:34:19 +10:00
Matthew Auld
22f880ca82
drm/i915/perf: destroy stream on sample_flags mismatch
...
If we were to ever encounter a sample_flags mismatch we need to ensure
we destroy the stream when we bail.
Fixes: d79651522ematthew.auld@intel.com >
Cc: Robert Bragg <robert@sixbynine.org >
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170327203459.18398-1-matthew.auld@intel.com
2017-03-28 10:31:51 +03:00
Shashank Sharma
14292b7ff8
drm/i915: allow HDMI 2.0 clock rates
...
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
Cc: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com >
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com >
Reviewed-by: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-7-git-send-email-shashank.sharma@intel.com
2017-03-28 10:17:49 +03:00
Shashank Sharma
1595363788
drm/i915: enable scrambling
...
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.
V4: Addressed review comment from Maarten
- scrambling -> hdmi_scrambling
- high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
V5: Addressed review comments from Ville and Ander
- Do not modifiy the crtc_state after compute_config. Move all
scrambling and tmds_clock_ratio calcutations to compute_config.
- While setting scrambling for source/sink, do not check the
conditions again, just go by the crtc_state flags. This will
simplyfy the condition checks.
V6: Addressed review comments from Ville
- Do not add IS_GLK check in disable/enable function, instead add it
in compute_config, while setting state flags.
- Remove unnecessary paranthesis.
- Simplyfy handle_sink_scrambling function as suggested.
- Add readout code for scrambling status in get_ddi_config and add a
check for the same in pipe_config_compare.
V7: Addressed review comments from Ander/Ville
- No separate function for source scrambling, make it inline
- Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
- Do not add platform check while setting source scrambling
- Use pipe_config instead of crtc->config to set sink scrambling
- To readout scrambling status, Compare with SCRAMBLING_MASK
not any of its bits
- Remove platform check in intel_pipe_config_compare while checking
scrambling status
V8: Fixed mege conflict, Addressed review comments from Ander
- Remove the desciption/comment about scrambling fom the caller, move
it to the function
- Move the IS_GLK check into scrambling function
- Fix alignment
V9: Fixed review comments from Ville, Ander
- Pass the scrambling state variables as bool input to the sink_scrambling
function and let the disable call be unconditional.
- Fix alignments in function calls and debug messages.
- Add kernel doc for function intel_hdmi_handle_sink_scrambling
V10: Rebase
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com >
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
2017-03-28 10:17:29 +03:00
Paulo Zanoni
44a126ba5d
drm/i915: kill intel_ddi_pll_select()
...
All it does is pick the encoder and call intel_get_shared_dpll(). We
can just do this in the caller. One less indirection level during code
reading.
As another plus, now the two callers of intel_get_shared_dpll() are
{ironlake,haswell}_crtc_compute_clock().
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
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/1490209125-20046-2-git-send-email-paulo.r.zanoni@intel.com
2017-03-27 17:24:33 -03:00
Michel Dänzer
ce4b4f228e
drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags
...
We were accidentally only overriding the first VRAM placement. For BOs
with the RADEON_GEM_NO_CPU_ACCESS flag set,
radeon_ttm_placement_from_domain creates a second VRAM placment with
fpfn == 0. If VRAM is almost full, the first VRAM placement with
fpfn > 0 may not work, but the second one with fpfn == 0 always will
(the BO's current location trivially satisfies it). Because "moving"
the BO to its current location puts it back on the LRU list, this
results in an infinite loop.
Fixes: 2a85aedd11zmichaels@oblong.com >
Reported-and-Tested-by: Julien Isorce <jisorce@oblong.com >
Reviewed-by: Christian König <christian.koenig@amd.com >
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Cc: stable@vger.kernel.org
2017-03-27 16:17:30 -04:00
Daniel Vetter
99612b2776
drm/tegra: Don't use modeset_lock_crtc
...
Yes the help text is unhelpful, but atomic drivers should never use
this. Just grab the lock without context or anything.
Also an aside: Checking ->active like this doesn't protect against
nonblocking commits, this is rather bogus.
Cc: Thierry Reding <thierry.reding@gmail.com >
Acked-by: Thierry Reding <thierry.reding@gmail.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-8-daniel.vetter@ffwll.ch
2017-03-27 17:50:47 +02:00
Chris Wilson
598b6b5ada
drm/i915: Mark manually wedged engines as guilty
...
Use the incoming value from debugfs/i915_wedged to select which engines
to marked as guilty in order to force us to reset those requests
(required to quickly bypass simulated hangs).
Testcase: igt/gem_exec_capture
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170325134735.30581-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
2017-03-27 15:36:10 +01:00
Chris Wilson
ed1501d451
drm/i915: Refactor tests for validity of RING_TAIL
...
Whilst I like having the assertions clearly visible in the code, they
are quite repetitious! As we find new limits we want to incorporate into
the set of assertions, it make sense to refactor them to a common
routine.
v2: Add a guc holdout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170327131412.20293-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-03-27 15:03:53 +01:00
Chris Wilson
a91fdf1293
drm/i915: Assert that the request->tail fits within the ring
...
In addition to being qword-aligned, the RING_TAIL offset must be within
the ring!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170327130009.4678-2-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-03-27 15:03:21 +01:00
Chris Wilson
450362d3fe
drm/i915/execlists: Wrap tail pointer after reset tweaking
...
If the request->wa_tail is 0 (because it landed exactly on the end of
the ringbuffer), when we reconstruct request->tail following a reset we
fill in an illegal value (-8 or 0x001ffff8). As a result, RING_HEAD is
never able to catch up with RING_TAIL and the GPU spins endlessly. If
the ring contains a couple of breadcrumbs, even our hangcheck is unable
to catch the busy-looping as the ACTHD and seqno continually advance.
v2: Move the wrap into a common intel_ring_wrap().
Fixes: a3aabe86a3chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Cc: <stable@vger.kernel.org > # v4.10+
Link: http://patchwork.freedesktop.org/patch/msgid/20170327130009.4678-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-03-27 15:02:56 +01:00
Ville Syrjälä
f9407ae153
drm/i915: Use i9xx_check_plane_surface() for sprite planes as well
...
All the pre-SKL sprite planes compute the x/y/tile offsets in a
similar way. There are a couple of minor differences but the primary
planes have those as well. Thus i9xx_check_plane_surface()
already does what we need, so let's use it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-7-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-03-27 15:58:33 +03:00
Ville Syrjälä
3ba35e53cf
drm/i915: Eliminate ironlake_update_primary_plane()
...
The effective difference between i9xx_update_primary_plane()
and ironlake_update_primary_plane() is only the HSW/BDW
DSPOFFSET special case. So bring that over into
i9xx_update_primary_plane() and eliminate the duplicated code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-6-ville.syrjala@linux.intel.com
2017-03-27 15:58:33 +03:00
Ville Syrjälä
5b7fcc44aa
drm/i915: Introduce i9xx_check_plane_surface()
...
Extract the primary plane surfae offset/x/y calculations for
pre-SKL platforms into a common function, and call it during the
atomic check phase to reduce the amount of stuff we have to do
during the commit phase. SKL is already doing this.
v2: Update the comment about the rotation adjustments to
match the code better (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-5-ville.syrjala@linux.intel.com
2017-03-27 15:58:33 +03:00
Ville Syrjälä
a0864d5905
drm/i915: Pre-compute plane control register value
...
Computing the plane control register value is branchy so moving it out
from the plane commit hook seems prudent. Let's pre-compute it during
the atomic check phase and store the result in the plane state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-4-ville.syrjala@linux.intel.com
2017-03-27 15:58:33 +03:00
Ville Syrjälä
6a4407a653
drm/i915: Nuke ironlake_plane_ctl()
...
Share the code to compute the primary plane control register value
between the i9xx and ilk codepaths as the differences are minimal.
Actually there are no differences between g4x and ilk, so the
current split doesn't really make any sense.
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-3-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-03-27 15:58:33 +03:00
Ville Syrjälä
7145f60a34
drm/i915: Extract i9xx_plane_ctl() and ironlake_plane_ctl()
...
Pull the code to calculate the pre-SKL primary plane control register
value into separate functions. Allows us to pre-compute it in the
future.
v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-03-27 15:58:32 +03:00
Chris Wilson
59ce13104d
drm/i915: Use BIT() for computing the engine's flag
...
Since the engine's flag is just the bit of its id, use BIT().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170324163540.31981-3-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2017-03-27 13:02:39 +01:00
Chris Wilson
ddb2397e30
drm/i915: Remove unused intel_flush_status_page()
...
intel_flush_status_page() is defunct since commit f8dd2934c4chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170324163540.31981-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2017-03-27 12:59:37 +01:00
Chris Wilson
9a29dd85a0
drm/i915: Fixup intel_write_status_page() for old CPUs without clflush
...
Not all of our target platforms have clflush. For those without, just
assume the status page is sufficiently coherent that we do not need our
paranoia.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Fixes: 14a6bbf9e5chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170324163540.31981-1-chris@chris-wilson.co.uk
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-03-27 12:57:36 +01:00
Chris Wilson
f4ce766f28
drm/i915: Align "unfenced" tiled access on gen2, early gen3
...
Old devices have quite severe restrictions for using fences, and unlike
more recent device (anything from Pineview onwards) we need to enforce
those restrictions even for unfenced tiled access from the render
pipeline.
Fixes: 944397f04fville.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: <drm-intel-fixes@lists.freedesktop.org > # v4.11-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170325113243.16438-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
2017-03-27 12:48:45 +01:00
Chris Wilson
71cc2b184c
drm/i915: Limit number of reads to stabilize rc6 counter reads
...
We have only 8bits of precise timestamps in which to complete our
upper/load reads, along with the switch between precision. This is not
always enough time to read the upper counter twice within the same time
slice, leading to hard lockups. Limit the number of times to prevent
an inifite loop (my fault for assuming we would have no trouble doing
the write + reads fast enough).
Fixes: 47c21d9a1ahttps://bugs.freedesktop.org/show_bug.cgi?id=100377
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170324165418.7455-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-03-27 12:48:45 +01:00
Chris Wilson
e2a2aa36a5
drm/i915: Check we have an wake device before flushing GTT writes
...
We can assume that if the device is asleep then all pending GTT writes
will have been posted, and so we can defer the flush from
i915_gem_object_flush_gtt_write_domain()
[ 1957.462568] WARNING: CPU: 0 PID: 6132 at drivers/gpu/drm/i915/intel_drv.h:1742 fwtable_read32+0x123/0x150 [i915]
[ 1957.462582] RPM wakelock ref not held during HW access
[ 1957.462583] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers
[ 1957.462607] CPU: 0 PID: 6132 Comm: gem_concurrent_ Tainted: G U 4.11.0-rc1+ #464
[ 1957.462619] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 1957.462630] Call Trace:
[ 1957.462646] dump_stack+0x4d/0x6f
[ 1957.462657] __warn+0xc1/0xe0
[ 1957.462667] warn_slowpath_fmt+0x4a/0x50
[ 1957.462709] fwtable_read32+0x123/0x150 [i915]
[ 1957.462750] i915_gem_object_flush_gtt_write_domain+0x43/0x70 [i915]
[ 1957.462791] i915_gem_object_set_to_cpu_domain+0x46/0xa0 [i915]
[ 1957.462831] i915_gem_set_domain_ioctl+0x15d/0x220 [i915]
[ 1957.462843] drm_ioctl+0x1d7/0x440
[ 1957.462885] ? i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0 [i915]
[ 1957.462896] ? pick_next_task_fair+0x436/0x440
[ 1957.462906] ? mntput+0x1f/0x30
[ 1957.462915] do_vfs_ioctl+0x8f/0x5c0
[ 1957.462925] ? __schedule+0x16f/0x5f0
[ 1957.462935] ? ____fput+0x9/0x10
[ 1957.462943] SyS_ioctl+0x3c/0x70
[ 1957.462952] entry_SYSCALL_64_fastpath+0x17/0x98
[ 1957.462961] RIP: 0033:0x7fc542179ca7
[ 1957.462968] RSP: 002b:00007ffeef12ff98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 1957.462982] RAX: ffffffffffffffda RBX: 00007ffeef1301d0 RCX: 00007fc542179ca7
[ 1957.462990] RDX: 00007ffeef12ffd0 RSI: 00000000400c645f RDI: 0000000000000003
[ 1957.462999] RBP: 0000000000000003 R08: 000055f433bc7c40 R09: 000000000000002c
[ 1957.463006] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000018
[ 1957.463015] R13: 000055f432c89d20 R14: 000055f432c87690 R15: 0000000000000000
Fixes: 3b5724d702chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170323150053.28582-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2017-03-27 12:48:44 +01:00
Chris Wilson
4af0d727b1
drm/i915/execlists: Trim irq handler
...
I noticed that gcc was spilling the CSB to the stack, so rearrange the
code to be more compact. Spilling in this function is slightly more
interesting due to the mmio reads acting as memory barriers and so
end up flushing the stack spills. Still miniscule to having to do at
least the pair of uncached reads :(
function old new delta
intel_lrc_irq_handler 1039 878 -161
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170325201053.21306-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2017-03-27 12:48:44 +01:00
Michal Wajdeczko
9d98af0bbe
drm/i915/uc: Make intel_uc_prepare_fw() static
...
There is no need to expose this function as it is called from
one function only. Also move it up to avoid forward declaration.
v2: drop intel_ prefix (Oscar) and rename to fetch_uc_fw (Michal)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170327094510.167400-1-michal.wajdeczko@intel.com
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-03-27 12:48:43 +01:00
Chris Wilson
0abfe7e257
drm/i915: Restore marking context objects as dirty on pinning
...
Commit e8a9c58fcde8a9c58fcddennis@ausil.us >
Reported-by: Mathieu Marquer <mathieu.marquer@gmail.com >
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99993
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100181
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: <drm-intel-fixes@lists.freedesktop.org > # v4.11-rc1
Link: http://patchwork.freedesktop.org/patch/msgid/20170322205930.12762-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
(cherry picked from commit 5d4bac5503jani.nikula@intel.com >
2017-03-27 11:56:27 +03:00
Gabriel Krisman Bertazi
c0411316ab
drm: bochs: Prevent double-free of fb helper
...
If fbdev registration fails for whatever reason, the error path of
bochs_fbdev_init() will call bochs_fbdev_fini(), but since an fbdev
initialization error is not fatal to the probe function, a subsequent
device removal will try to call bochs_fbdev_fini() again, hitting the
Oops below.
This was detected by 0-day with a failing framebuffer registration and
CONFIG_DEBUG_TEST_DRIVER_REMOVE=y. This reproduces the scenario I
mentioned above at insmod time, because the test attempts to remove the
device right after probing.
root@debian:~# insmod bochs-drm.ko
[ 17.609635] [drm] Found bochs VGA, ID 0xb0c0.
[ 17.612974] [drm] Framebuffer size 16384 kB @ 0xfa000000, mmio @ 0xfebf2000.
[ 17.613938] [TTM] Zone kernel: Available graphics memory: 1022244 kiB
[ 17.614701] [TTM] Initializing pool allocator
[ 17.615427] [TTM] Initializing DMA pool allocator
[ 17.619143] fbcon: bochsdrmfb (fb0) is primary device
[ 17.619428] Console: switching to colour frame buffer device 128x48
[ 17.621047] bochs-drm 0000:00:02.0: fb0: bochsdrmfb frame buffer device
[ 17.641111] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 0
[ 17.642380] general protection fault: 0000 [#1 ] SMP
[ 17.642985] Modules linked in: bochs_drm(+)
[ 17.643259] CPU: 4 PID: 3279 Comm: insmod Tainted: G W 4.11.0-rc1+ #119
[ 17.643259] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 17.643259] task: ffff88007af35e00 task.stack: ffffc90000d84000
[ 17.643259] RIP: 0010:drm_fb_helper_fini+0x8e/0x110
[ 17.643259] RSP: 0018:ffffc90000d87ad0 EFLAGS: 00010202
[ 17.643259] RAX: dead000000000200 RBX: ffff8800790d5770 RCX: 0000000000000000
[ 17.652101] RDX: dead000000000100 RSI: 000000007fffffff RDI: ffffffff81eaf820
[ 17.652101] RBP: ffffc90000d87ae0 R08: 0000000000000000 R09: ffff88007271d918
[ 17.652101] R10: ffffc90000d87a88 R11: 0000000000000000 R12: 0000000000000000
[ 17.652101] R13: ffff8800790d56d0 R14: 0000000000000000 R15: 0000000000000000
[ 17.652101] FS: 00007f9285995700(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000
[ 17.652101] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 17.652101] CR2: 0000564f1cf9f1e8 CR3: 0000000079686000 CR4: 00000000000006e0
[ 17.652101] Call Trace:
[ 17.652101] bochs_fbdev_fini+0x24/0x90 [bochs_drm]
[ 17.652101] bochs_unload+0x16/0x50 [bochs_drm]
[ 17.652101] drm_dev_unregister+0x37/0xd0
[ 17.652101] drm_put_dev+0x31/0x60
[ 17.652101] bochs_pci_remove+0x10/0x20 [bochs_drm]
[ 17.652101] pci_device_remove+0x34/0xb0
[ 17.652101] driver_probe_device+0xd0/0x370
[ 17.652101] __driver_attach+0x96/0xa0
[ 17.652101] ? driver_probe_device+0x370/0x370
[ 17.652101] bus_for_each_dev+0x5b/0x90
[ 17.652101] driver_attach+0x19/0x20
[ 17.652101] bus_add_driver+0x11c/0x220
[ 17.652101] driver_register+0x5b/0xd0
[ 17.652101] ? 0xffffffffa0006000
[ 17.652101] __pci_register_driver+0x47/0x50
[ 17.652101] drm_pci_init+0xe1/0xf0
[ 17.652101] ? 0xffffffffa0006000
[ 17.652101] bochs_init+0x3c/0x1000 [bochs_drm]
[ 17.652101] do_one_initcall+0x3e/0x180
[ 17.652101] ? kmem_cache_alloc_trace+0x33/0x150
[ 17.652101] do_init_module+0x5a/0x1eb
[ 17.652101] load_module+0x1ea0/0x2650
[ 17.652101] ? __symbol_put+0x40/0x40
[ 17.652101] ? kernel_read_file+0x19e/0x1c0
[ 17.652101] ? kernel_read_file_from_fd+0x44/0x70
[ 17.652101] SYSC_finit_module+0xba/0xc0
[ 17.652101] SyS_finit_module+0x9/0x10
[ 17.652101] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 17.652101] RIP: 0033:0x7f92854da119
[ 17.652101] RSP: 002b:00007ffcd0390498 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 17.652101] RAX: ffffffffffffffda RBX: 00007f928578eb58 RCX: 00007f92854da119
[ 17.652101] RDX: 0000000000000000 RSI: 0000564f1c8bd638 RDI: 0000000000000003
[ 17.652101] RBP: 000000000000270e R08: 0000000000000000 R09: 00007f9285790ea0
[ 17.652101] R10: 0000000000000003 R11: 0000000000000246 R12: 00007f928578eb58
[ 17.652101] R13: 0000000000001020 R14: 0000564f1cf9e1c0 R15: 00007f928578eb00
[ 17.652101] Code: c7 20 f8 ea 81 e8 b3 3e 50 00 48 8b 83 d0 00 00 00 48 8d 93 d0 00 00 00 48 39 c2 74 46 48 8b 83 d8 00 00 00 48 8b 93 d0 00 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 0000 ad de 48 89 83 d0
[ 17.652101] RIP: drm_fb_helper_fini+0x8e/0x110 RSP: ffffc90000d87ad0
[ 17.653331] ---[ end trace 542fd75a2e60a6a4 ]---
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170324045444.11912-1-krisman@collabora.co.uk
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com >
2017-03-27 10:34:52 +02:00
Jani Nikula
69653f626e
Merge tag 'gvt-fixes-2017-03-23' of https://github.com/01org/gvt-linux into drm-intel-fixes
...
gvt-fixes-2017-03-23
- KVM reference fix from Alex
- shadow gtt entry partial update fix from Xiaoguang
- gvt context notification check (Changbin)
- other misc fixes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
2017-03-27 11:01:30 +03:00
Daniel Vetter
18dddadc78
drm/atomic: Introduce drm_atomic_helper_shutdown
...
The trouble here is that it does multiple atomic commits under one
drm_modeset_lock_all, which breaks the behind-the-scenes acquire
context magic that function pulls off. It's much better to have one
overall atomic commit. That we still have multiple atomic commits
prevents us from adding some pretty useful debug checks to the atomic
machinery.
Hence it is really a bad idea to call the legacy
drm_crtc_force_disable_all() function. There's 2 atomic drivers using
this still, nouveau and tinydrm. To fix this, introduce a new
drm_atomic_helper_shutdown() by extracting the code from i915.
While at it improve kernel-doc and catch future offenders by
sprinkling a WARN_ON into the legacy function. We should probably move
those into the legacy modeset helpers, too ...
v2: Make it compile on arm drivers too (Noralf).
v3: Correct kerneldoc to point at _disable_all().
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Acked-by: Noralf Trønnes <noralf@tronnes.org >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Noralf Trønnes <noralf@tronnes.org >
Cc: Ben Skeggs <bskeggs@redhat.com >
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170321164149.31531-1-daniel.vetter@ffwll.ch
2017-03-27 09:43:58 +02:00
Noralf Trønnes
79b85d2b7e
drm/tinydrm: Fix drm_driver.fops.owner
...
drm_driver.fops can't be shared since the owner then becomes tinydrm.ko.
Move the fops declaration to the driver.
v2: Use DEFINE_DRM_GEM_CMA_FOPS
Reported-by: Daniel Vetter <daniel.vetter@intel.com >
Signed-off-by: Noralf Trønnes <noralf@tronnes.org >
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Link: http://patchwork.freedesktop.org/patch/msgid/20170326142529.16938-1-noralf@tronnes.org
2017-03-27 08:41:35 +02:00
Romain Perier
187697a454
drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD
...
Currently, the irq handler that monitors changes for HPD and RX_SENSE
relies on the status of the bridge for updating the status of the HPD.
The update is done only when the bridge is enabled.
However, on Rockchip platforms we have found use cases where it could be
a problem. When HDMI is being used, turning off/on the screen or
unplugging/re-plugging the cable, the following simplified code path
will happen:
- dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on
hdmi->disabled is false, then the handler will update the rxsense flag
accordingly.
- dw_hdmi_update_power() will be invoked with the mode
DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be
called and the PHY will be desactivated (its pixel clocks and TMDS)
[...]
- dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as
disabled.
- dw_hdmi_irq() will be triggered by an HPD event, as the bridge is
currently disabled the HPD status won't be updated, so hdmi->rxsense
won't be changed. Even if the data part of the PHY is disabled, this
information coming from the HDMI Transmitter is correct and should be
saved.
[...]
- dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as
enabled.
- dw_hdmi_update_power() will be called. When hdmi->force is equal to
DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. If this
field has not been updated by the irq handler, it will be false and
DRM_FORCE_ON won't be put to hdmi->force.
Consequently, most of the time dw_hdmi_poweron() won't be called in this
use case, TMDS won't be re-enabled the PHY won't be re-initialized,
resulting in a "Signal not found".
This commit fixes the issue by removing the check for "!hdmi->disabled".
As already explained, even if the PHY is partially disabled, information
coming from HDMI Transmitter about HPD should be saved for a later use.
Signed-off-by: Romain Perier <romain.perier@collabora.com >
Signed-off-by: Archit Taneja <architt@codeaurora.org >
Link: https://patchwork.freedesktop.org/patch/143602/
2017-03-27 11:50:48 +05:30
Daniel Vetter
f19aee7f27
drm/vblank: Remove DRM_VBLANKTIME_IN_VBLANK
...
The core code doesn't care at all about this, it's entirely dead.
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170322083617.13361-11-daniel.vetter@ffwll.ch
2017-03-25 22:41:32 +01:00
