Age | Commit message (Collapse) | Author | Files | Lines |
|
Typically, there is space available within the ring and if not we have
to wait (by definition a slow path). Rearrange the code to reduce the
number of branches and stack size for the hotpath, accomodating a slight
growth for the wait.
v2: Fix the new assert that packets are not larger than the actual ring.
v3: Make the parameters unsigned as well to make usage.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Some callers immediately want to know the current ring->space after
calling intel_ring_update_space(), which we can freely provide via the
return parameter.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Exploit the power-of-two ring size to compute the space across the
wraparound using a mask rather than a if. Convert to unsigned integers
so the operation is well defined.
References: https://bugs.freedesktop.org/show_bug.cgi?id=99671
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Since unifying ringbuffer/execlist submission to use
engine->pin_context, we ensure that the intel_ring is available before
we start constructing the request. We can therefore move the assignment
of the request->ring to the central i915_gem_request_alloc() and not
require it in every engine->request_alloc() callback. Another small step
towards simplification (of the core, but at a cost of handling error
pointers in less important callers of engine->pin_context).
v2: Rearrange a few branches to reduce impact of PTR_ERR() on gcc's code
generation.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Oscar Mateo <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Oscar Mateo <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Since kmap allows us to block we can pin the pages and use our normal
page lookup routine making the implementation simple, or as some might
say quick and dirty.
Testcase: igt/drv_selftest/dmabuf
Testcase: igt/prime_rw
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Backmerge the main drm-next pull to sync up.
Chris also pointed out that
commit ade0b0c965f59176daddbef9c4717354034f9bce
Author: Chris Wilson <[email protected]>
Date: Sat Apr 22 09:15:37 2017 +0100
drm/i915: Confirm the request is still active before adding it to the await
is double-applied in the git merge, so make sure we get this right.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Now that everything is in place let's register a PCM device for
each port of the display engine. This will make it possible to
actually output audio to multiple displays at the same time. And
it avoids modesets on unrelated displays from clobbering up the
ELD and whatnot for the display currently doing the playback.
v2: Add a PCM per port instead of per pipe
v3: Fix off by one error with port numbers (Pierre-Louis)
Fix .notify_audio_lpe() prototype (Pierre-Louis)
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
To allow multiple PCM devices to be registered for the LPE audio card,
split the private data into card and PCM specific chunks. For now we'll
stick to just one PCM device as before.
v2: Rework to do a pcm device per port instead of per pipe
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
In preparation for register a PCM device for each pipe adjust
link up the ctl elements with the corresponding PCM device.
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
Split the LPE audio platform data into a port specific
chunk and device specific chunk. Eventually we'll have
a port specific chunk for each port, but for now we'll
stick to just one.
We'll also get rid of the intel_hdmi_lpe_audio_eld structure
which doesn't seem to have any real reason to exist.
v2: Organize per port instead of per pipe
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
Shuffle the arguments to intel_lpe_audio_notify() around a bit. Pipe
and port being the most important things, so let's put the first, and
thre rest can come in as is. Also constify the eld argument.
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
We can determine that the pipe was shut down from pipe<0, so there's
no point in duplicating that information as 'hdmi_connected'.
v2: Use pipe<0 instead of port<0 as we'll want to do per-port
PCM devices later
Initialize pipe to -1 to inidicate inactive initial state
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
There's no need to distinguish between the DP link rate and HDMI TMDS
clock for the purposes of the LPE audio. Both are actually the same
thing more or less, which is the link symbol clock. So let's just
call the thing ls_clock and simplify the code.
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
The pending_notify flag in the LPE audio platform data is pointless,
actually unused. So let's kill it off.
v2: Fix typo in patch subject
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
vlv_display_irq_postinstall() enables the LPE audio interrupts
regardless of whether the LPE audio irq chip has masked/unmasked
them. Also the irqchip masking/unmasking doesn't consider the state
of the display power well or the device, and hence just leads to
dmesg spew when it tries to access the hardware while it's powered
down.
If the current way works, then we don't need to do anything in the
mask/unmask hooks. If it doesn't work, well, then we'd need to properly
track whether the irqchip has masked/unmasked the interrupts when
we enable display interrupts. And the mask/unmask hooks would need
to check whether display interrupts are even enabled before frobbing
with he registers.
So let's just assume the current way works and neuter the mask/unmask
hooks. Also clean up vlv_display_irq_postinstall() a bit and stop
it from trying to unmask/enable the LPE C interrupt on VLV since it
doesn't exist.
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
Clear the notify function pointer in the platform data before we tear
down the driver. Otherwise i915 would end up calling a stale function
pointer and possibly explode.
Cc: [email protected]
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
Not calling pm_runtime_enable() means that runtime PM can't be
enabled at all via sysfs. So we definitely need to call it
from somewhere.
Calling it from the driver seems like a bad idea because it
would have to be paired with a pm_runtime_disable() at driver
unload time, otherwise the core gets upset. Also if there's
no LPE audio driver loaded then we couldn't runtime suspend
i915 either.
So it looks like a better plan is to call it from i915 when
we register the platform device. That seems to match how
pci generally does things. I cargo culted the
pm_runtime_forbid() and pm_runtime_set_active() calls from
pci as well.
The exposed runtime PM API is massive an thorougly misleading, so
I don't actually know if this is how you're supposed to use the API
or not. But it seems to work. I can now runtime suspend i915 again
with or without the LPE audio driver loaded, and reloading the
LPE audio driver also seems to work.
Note that powertop won't auto-tune runtime PM for platform devices,
which is a little annoying. So I'm not sure that leaving runtime
PM in "on" mode by default is the best choice here. But I've left
it like that for now at least.
Also remove the comment about there not being much benefit from
LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
PM, which will also block s0ix, and that could have a measurable
impact on power consumption.
Cc: [email protected]
Cc: Takashi Iwai <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Takashi Iwai <[email protected]>
|
|
Rather than use a global modparam, we can just check to see if the
engine has semaphores configured upon it.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
As we may unwind the requests, even though the request we are awaiting
has a global_seqno that seqno may be revoked during the await and so we
can not reliably use it as a barrier for all future awaits on the same
timeline.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Michał Winiarski <[email protected]>
Reviewed-by: Michał Winiarski <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
With the addition of the inter-context intel_time.sync map, having a
very similar sync_seqno[] is confusing. Aide the reader by denoting that
this is a pre-allocated array for storing semaphore sync points wrt to
the global seqno.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.
v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment. (Tvrkto)
v11: Refactor igt_sync kselftests to avoid deep nesting (Tvrkto)
v12: __sync_leaf_idx() to assert that p->height is 0 when checking leaves
v13: kselftests to investigate struct i915_syncmap itself (Tvrtko)
v14: Foray into ascii art graphs
v15: Take into account that the random lookup/insert does 2 prng calls,
not 1, when benchmarking, and use for_each_set_bit() (Tvrtko)
v16: Improved ascii art
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Currently we filter out repeated use of the same timeline in the low
level i915_gem_request_await_request(), after having added the
dependency on the old request. However, we can lift this to
i915_gem_request_await_dma_fence() (before the dependency is added)
using the observation that requests along the same timeline are
explicitly ordered via i915_add_request (along with the dependencies).
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
By first unwrapping an incoming fence-array into its child fences, we
can simplify the internal branching, and so avoid triggering a potential
bug in the next patch when not squashing the child fences on the same
timeline.
It will also have the advantage of keeping the (top-level) fence arrays
out of any fence/timeline caching since these are unordered timelines
but with a random context id.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special global context to mean unordered.
Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to
have the same semantics everywhere.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace the handcrafter loop when checking for fifo slots
with atomic wait for. This brings this wait in line with
the other waits on register access. We also get a readable
timeout constraint, so make it to fail after 10ms.
Chris suggested that we should fail silently as the fifo debug
handler, now attached to unclaimed mmio handling, will take care of the
possible errors at later stage.
Note that the decision to wait was changed so that we avoid
allocating the first reserved entry. Nor do we reduce the count
if we fail the wait, removing the possiblity to wrap the
count if the hw fifo returned zero.
v2: remove unclaimed check on timeout (Chris)
v3: use void return (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=100247
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove the per-mmio checking of the FIFO debug register into the common
conditional mmio debug handling. Based on patch from Chris Wilson.
v2: postpone warn on fifodbg for unclaimed reg debugs
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
|
|
It is safer to setup valid send function after successful GuC
hardware initialization. In addition we prepare placeholder
where we can setup any alternate GuC communication mechanism.
Signed-off-by: Michal Wajdeczko <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
[ickle: Fixup ENODEV for an impossible error path]
Signed-off-by: Chris Wilson <[email protected]>
|
|
Add intel_irq_fini() for placing the deinitialization code,
starting with freeing dev_priv->l3_parity.remap_info[].
Signed-off-by: Joonas Lahtinen <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1493366319-18515-1-git-send-email-joonas.lahtinen@linux.intel.com
|
|
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Some nouveau regression fixes.
* 'linux-4.12' of git://github.com/skeggsb/linux:
drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detection
drm/nouveau/secboot/gm20b: fix the error return code in gm20b_secboot_tegra_read_wpr()
drm/nouveau/kms: Increase max retries in scanout position queries.
drm/nouveau/bios/bitP: check that table is long enough for optional pointers
drm/nouveau/fifo/nv40: no ctxsw for pre-nv44 mpeg engine
|
|
A missing u64 cast causes a 32-Bit wraparound from
4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected
if card has 4096 Mib per FBP.
Signed-off-by: Mario Kleiner <[email protected]>
Reviewed-by: Karol Herbst <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
gm20b_secboot_tegra_read_wpr()
The error return code PTR_ERR(mc) is always 0 since mc is
equal to 0 in this error handling case.
Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
So far we only allowed for 1 retry and just failed the query
- and thereby high precision vblank timestamping - if we did
not get a reasonable result, as such a failure wasn't considered
all too horrible. There are a few NVidia gpu models out there which
may need a bit more than 1 retry to get a successful query result
under some conditions.
Since Linux 4.4 the update code for vblank counter and timestamp
in drm_update_vblank_count() changed so that the implementation
assumes that high precision vblank timestamping of a kms driver
either consistently succeeds or consistently fails for a given
video mode and encoder/connector combo. Iow. switching from success
to fail or vice versa on a modeset or connector change is ok, but
spurious temporary failure for a given setup can confuse the core
code and potentially cause bad miscounting of vblanks and confusion
or hangs in userspace clients which rely on vblank stuff, e.g.,
desktop compositors.
Therefore change the max retry count to a larger number - more than
any gpu so far is known to need to succeed, but still low enough
so that these queries which do also happen in vblank interrupt are
still fast enough to be not disastrously long if something would
go badly wrong with them.
As such sporadic retries only happen seldom even on affected gpu's,
this could mean a vblank irq could take a few dozen microseconds
longer every few hours of uptime -- better than a desktop compositor
randomly hanging every couple of hours or days of uptime in a hard
to reproduce manner.
Signed-off-by: Mario Kleiner <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Fixes OOB VBIOS accesses on some boards.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
git://anongit.freedesktop.org/git/drm-intel into drm-next
drm/i915 and gvt fixes for drm-next/v4.12
* tag 'drm-intel-next-fixes-2017-04-27' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: Confirm the request is still active before adding it to the await
drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio
drm/i915/selftests: Allocate inode/file dynamically
drm/i915: Fix system hang with EI UP masked on Haswell
drm/i915: checking for NULL instead of IS_ERR() in mock selftests
drm/i915: Perform link quality check unconditionally during long pulse
drm/i915: Fix use after free in lpe_audio_platdev_destroy()
drm/i915: Use the right mapping_gfp_mask for final shmem allocation
drm/i915: Make legacy cursor updates more unsynced
drm/i915: Apply a cond_resched() to the saturated signaler
drm/i915: Park the signaler before sleeping
drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()
drm/i915/gvt: Fix PTE write flush for taking runtime pm properly
drm/i915/gvt: remove some debug messages in scheduler timer handler
drm/i915/gvt: add mmio init for virtual display
drm/i915/gvt: use directly assignment for structure copying
drm/i915/gvt: remove redundant ring id check which cause significant CPU misprediction
drm/i915/gvt: remove redundant platform check for mocs load/restore
drm/i915/gvt: Align render mmio list to cacheline
drm/i915/gvt: cleanup some too chatty scheduler message
|
|
git://people.freedesktop.org/~syeh/repos_linux into drm-next
trivial patch.
* 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux:
drm/vmwgfx: Convert macro to octal representation
|
|
drm-next
Latest updates on Mali DP, adding support for colour management,
plane scaling and power management.
(these have been in -next for a while).
* 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld:
drm: mali-dp: use div_u64 for expensive 64-bit divisions
drm: mali-dp: Check the mclk rate and allow up/down scaling
drm: mali-dp: Enable image enhancement when scaling
drm: mali-dp: Add plane upscaling support
drm/mali-dp: Add core_id file to the sysfs interface
drm: mali-dp: Add CTM support
drm: mali-dp: enable gamma support
drm: mali-dp: add malidp_crtc_state struct
drm: mali-dp: add custom reset hook for planes
drm: mali-dp: remove unused variable
drm: mali-dp: add atomic_print_state for planes
drm: mali-dp: Enable power management for the device.
drm: mali-dp: Update the state of all planes before re-enabling active CRTCs.
|
|
The sequence in glk_dsi_device_ready() enters ULPS then waits until it is
*not* active to then disable it. The correct sequence according to the
spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is
zero, i.e., ULPS is active, and then disable ULPS.
Fixing the condition gets rid of the following spurious error messages:
[drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active
Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence")
Cc: Deepak M <[email protected]>
Cc: Madhav Chauhan <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: [email protected]
Cc: <[email protected]>
Signed-off-by: Ander Conselvan de Oliveira <[email protected]>
Reviewed-by: Madhav Chauhan <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
CCID register existed already on ILK according to the PRM (Chris
verified the address to match too).
Signed-off-by: Joonas Lahtinen <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1493366019-18380-1-git-send-email-joonas.lahtinen@linux.intel.com
|
|
ILK should survive a reset without display corruption.
Suggested-by: Chris Wilson <[email protected]>
Signed-off-by: Joonas Lahtinen <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
|
|
HAS_HW_CONTEXTS is misleading condition for GPU reset and CCID,
replace it with Gen specific (to be updated in next patches).
HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF
match also has .has_hw_contexts = 1 set.
This leads to us being able to get rid of the property completely.
v2:
- Keep the checks at Gen6 for no functional change (Ville)
Signed-off-by: Joonas Lahtinen <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Cc: Ville Syrjälä <[email protected]>
|
|
Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.
v2:
- Squash and get rid of hw_context_size (Chris)
v3:
- Move after MMIO init for probing on Gen7 and 8 (Chris)
- Retained rounding (Tvrtko)
v4:
- Rebase for deferred legacy context allocation
Signed-off-by: Joonas Lahtinen <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Oscar Mateo <[email protected]>
Cc: Zhenyu Wang <[email protected]>
Cc: [email protected]
Acked-by: Tvrtko Ursulin <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
|
|
Looks like intel_guc_reset had the ability to sleep under the
uncore spinlock since forever but it wasn't detected until the
recent changes annotated the wait for register with might_sleep.
I have fixed it by removing holding of the uncore spinlock over
the call to gen6_hw_domain_reset, since I do not see that is
really needed. But there is always a possibility I am missing
some nasty detail so please double check.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Michal Wajdeczko <[email protected]>
Cc: Arkadiusz Hiler <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Oscar Mateo <[email protected]>
Acked-by: Michel Thierry <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
|
|
Almost from the outset for execlists, we used deferred allocation of the
logical context and rings. Then we ported the infrastructure for pinning
contexts back to legacy, and so now we are able to also implement
deferred allocation for context objects prior to first use on the legacy
submission.
v2: We still need to differentiate between legacy engines, Joonas is
fixing that but I want this first ;) (Joonas)
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
|
|
As all other functions related to resetting engines are using
reset_engine.
v2: remove _request_ and use start/cancel instead (Chris)
Cc: Chris Wilson <[email protected]>
Signed-off-by: Michel Thierry <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
|
|
It has been replaced by I915_RESET_BACKOFF / I915_RESET_HANDOFF.
Signed-off-by: Michel Thierry <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
|
|
On 32-bit machines, we can't divide 64-bit integers:
drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check':
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod'
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined reference to `__aeabi_uldivmod'
This calls the div_u64 function explicitly instead.
Fixes: 4cea4e9f6690 ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Display workaround #1139 for Geminilake instructs us to restrict HDMI
to 8 bpc when htotal is greater than 5460. Otherwise, the pipe is unable
to generate a proper signal and is left in a state where corruption is
seen with other modes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100440
Cc: Shashank Sharma <[email protected]>
Signed-off-by: Ander Conselvan de Oliveira <[email protected]>
Reviewed-by: Shashank Sharma <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.
In fact, without checking for a completed request we may try to use the
signaler after it has been retired and its dependency tree freed:
[ 60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
[ 60.044118] Read of size 8 by task gem_exec_fence/530
[ 60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G E 4.11.0-rc7+ #46
[ 60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[ 60.044290] Call Trace:
[ 60.044337] dump_stack+0x4d/0x6a
[ 60.044383] kasan_object_err+0x21/0x70
[ 60.044435] kasan_report+0x225/0x4e0
[ 60.044488] ? __list_add_valid+0x1d/0xd0
[ 60.044534] ? kasan_kmalloc+0xad/0xe0
[ 60.044587] __asan_load8+0x5e/0x70
[ 60.044639] __list_add_valid+0x1d/0xd0
[ 60.044788] __i915_priotree_add_dependency+0x67/0x130 [i915]
[ 60.044895] i915_gem_request_await_request+0xa8/0x370 [i915]
[ 60.044974] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.045049] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.045077] ? save_stack+0xb1/0xd0
[ 60.045105] ? save_stack_trace+0x1b/0x20
[ 60.045132] ? save_stack+0x46/0xd0
[ 60.045158] ? kasan_kmalloc+0xad/0xe0
[ 60.045184] ? __kmalloc+0xd8/0x670
[ 60.045229] ? drm_ioctl+0x359/0x640 [drm]
[ 60.045256] ? SyS_ioctl+0x41/0x70
[ 60.045330] ? i915_vma_move_to_active+0x540/0x540 [i915]
[ 60.045360] ? tty_insert_flip_string_flags+0xa1/0xf0
[ 60.045387] ? tty_flip_buffer_push+0x63/0x70
[ 60.045414] ? remove_wait_queue+0xa9/0xc0
[ 60.045441] ? kasan_unpoison_shadow+0x35/0x50
[ 60.045467] ? kasan_kmalloc+0xad/0xe0
[ 60.045494] ? kasan_check_write+0x14/0x20
[ 60.045568] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.045616] drm_ioctl+0x359/0x640 [drm]
[ 60.045705] ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
[ 60.045751] ? drm_version+0x150/0x150 [drm]
[ 60.045778] ? compat_start_thread+0x60/0x60
[ 60.045805] ? plist_del+0xda/0x1a0
[ 60.045833] do_vfs_ioctl+0x12e/0x910
[ 60.045860] ? ioctl_preallocate+0x130/0x130
[ 60.045886] ? pci_mmcfg_check_reserved+0xc0/0xc0
[ 60.045913] ? vfs_write+0x196/0x240
[ 60.045939] ? __fget_light+0xa7/0xc0
[ 60.045965] SyS_ioctl+0x41/0x70
[ 60.045991] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.046017] RIP: 0033:0x7feb2baefc47
[ 60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
[ 60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
[ 60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
[ 60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
[ 60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
[ 60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
[ 60.046225] Allocated:
[ 60.046246] PID = 530
[ 60.046269] save_stack_trace+0x1b/0x20
[ 60.046292] save_stack+0x46/0xd0
[ 60.046318] kasan_kmalloc+0xad/0xe0
[ 60.046343] kasan_slab_alloc+0x12/0x20
[ 60.046368] kmem_cache_alloc+0xab/0x650
[ 60.046445] i915_gem_request_await_request+0x88/0x370 [i915]
[ 60.046559] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.046705] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.046849] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.046936] drm_ioctl+0x359/0x640 [drm]
[ 60.046987] do_vfs_ioctl+0x12e/0x910
[ 60.047038] SyS_ioctl+0x41/0x70
[ 60.047090] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.047139] Freed:
[ 60.047179] PID = 530
[ 60.047223] save_stack_trace+0x1b/0x20
[ 60.047269] save_stack+0x46/0xd0
[ 60.047317] kasan_slab_free+0x72/0xc0
[ 60.047366] kmem_cache_free+0x39/0x160
[ 60.047512] i915_gem_request_retire+0x83f/0x930 [i915]
[ 60.047657] i915_gem_request_alloc+0x166/0x600 [i915]
[ 60.047799] i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
[ 60.047897] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.047942] drm_ioctl+0x359/0x640 [drm]
[ 60.047968] do_vfs_ioctl+0x12e/0x910
[ 60.047993] SyS_ioctl+0x41/0x70
[ 60.048019] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.048044] Memory state around the buggy address:
[ 60.048066] ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048105] ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 60.048170] ^
[ 60.048191] ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048225] ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
Note to hit the use-after-free requires us to be passed back a request
via a fence-array, that is from explicit fencing accumulated into a
sync-file fence-array.
Fixes: 52e542090701 ("drm/i915/scheduler: Record all dependencies upon request construction")
Testcase: igt/gem_exec_fence/expired-history
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Michał Winiarski <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit ade0b0c965f59176daddbef9c4717354034f9bce)
Signed-off-by: Jani Nikula <[email protected]>
|