| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Joonas Lahtinen <[email protected]>
|
|
Introduce a complementary function to i915_driver_create() to undo all
that is created.
Suggested-by: Michal Wajdeczko <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Cc: Michal Wajdeczko <[email protected]>
Reviewed-by: Michal Wajdeczko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Attach our device_info to the our i915 private on creation so that it is
always available for inspection.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Michal Wajdeczko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
During IPS disabling the current 42ms timeout value leads to occasional
timeouts, increase it to 100ms which seems to get rid of the problem.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107494
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107562
Reported-by: Diego Viola <[email protected]>
Tested-by: Diego Viola <[email protected]>
Cc: Diego Viola <[email protected]>
Cc: <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Future gen reduce the number of bits we will have available to
differentiate between contexts, so reduce the lifetime of the ID
assignment from that of the context to its current active cycle (i.e.
only while it is pinned for use by the HW, will it have a constant ID).
This means that instead of a max of 2k allocated contexts (worst case
before fun with bit twiddling), we instead have a limit of 2k in flight
contexts (minus a few that have been pinned by the kernel or by perf).
To reduce the number of contexts id we require, we allocate a context id
on first and mark it as pinned for as long as the GEM context itself is,
that is we keep it pinned it while active on each engine. If we exhaust
our context id space, then we try to reclaim an id from an idle context.
In the extreme case where all context ids are pinned by active contexts,
we force the system to idle in order to recover ids.
We cannot reduce the scope of an HW-ID to an engine (allowing the same
gem_context to have different ids on each engine) as in the future we
will need to preassign an id before we know which engine the
context is being executed on.
v2: Improved commentary (Tvrtko) [I tried at least]
References: https://bugs.freedesktop.org/show_bug.cgi?id=107788
Signed-off-by: Chris Wilson <[email protected]>
Cc: Lionel Landwerlin <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Michel Thierry <[email protected]>
Cc: Michal Wajdeczko <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
If the previous modeset commit has completed and is no longer part of
the crtc state, skip waiting for it.
Ville pointed out that, in fact, the commit is never removed after a
modeset so the only way we could see a NULL here should be if there was
never a commit attached. Nevertheless, we have the evidence it can be
NULL and it has been defended against elsewhere, for example commit
93313538c153 ("drm/i915: Pass idle crtc_state to intel_dp_sink_crc").
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107792
Fixes: c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs, v6")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Dhinakaran Pandiyan <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Elsewhere we manipulate uncore.unclaimed_mmio_check and
i915_param.mmio_debug under the irq lock (e.g. preserving the current
value across a user forcewake grab), but do not protect the manipulation
inside intel_uncore_arm_unclaimed_mmio_detection() from concurrent
access, even from itself. This is an issue as we do call
arm_unclaimed_mmio_detection from multiple threads without coordination.
Suggested-by: Mika Kuoppala <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There are two issues with the current RPCS programming for Icelake:
Expansion of the slice count bitfield has been missed, as well as the
required programming workaround for the subslice count bitfield size
limitation.
1)
Bitfield width for configuring the active slice count has grown so we need
to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writing to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
2)
Due subslice count bitfield being only three bits wide and furthermore
capped to a maximum documented value of four, special programming
workaround is needed to enable more than four subslices.
With this programming driver has to consider the GT configuration as
2x4x8, while the hardware internally translates this to 1x8x8.
A limitation stemming from this is that either a subslice count between
one and four can be selected, or a subslice count equaling the total
number of subslices in all selected slices. In other words, odd subslice
counts greater than four are impossible, as are odd subslice counts
greater than a single slice subslice count.
This also had no impact in the current code base due breakage from 1)
always reqesting more than one slice.
While fixing this we also add some asserts to flag up any future bitfield
overflows.
v2:
* Use a local in all branches for clarity. (Lionel)
Signed-off-by: Tvrtko Ursulin <[email protected]>
Bspec: 12247
Reported-by: [email protected]
Suggested-by: Lionel Landwerlin <[email protected]>
Cc: Lionel Landwerlin <[email protected]>
Cc: [email protected]
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Continuing the fun of trying to find exactly the delay that is
sufficient to ensure that the page directory is fully loaded between
context switches, move the extra flush added in commit 70b73f9ac113
("drm/i915/ringbuffer: Delay after invalidating gen6+ xcs") to just
after we flush the pd. Entirely based on the empirical data of running
failing tests in a loop until we survive a day (before the mtbf is 10-30
minutes).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107769
References: 70b73f9ac113 ("drm/i915/ringbuffer: Delay after invalidating gen6+ xcs")
Signed-off-by: Chris Wilson <[email protected]>
Acked-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Currently, if the user has enabled mmio-debug around each register
access, we presume that we have then checked them all. However, it is
still possible through omission (raw register access) or external
interaction that the unclaimed access was not highlighted.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Copy the 38.4 vs. 19.2 MHz ref clock exception from the dpll
mgr into the clock readout function as well.
v2: Refactor the code into a common function
s/is_icl/gen11+/ (Rodrigo)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107722
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Rodrigo Vivi <[email protected]>
|
|
Older gen use a physical address for the hardware status page, for which
we use cache-coherent writes. As the writes are into the cpu cache, we use
a normal WB mapped page to read the HWS, used for our seqno tracking.
Anecdotally, I observed lost breadcrumbs writes into the HWS on i965gm,
which so far have not reoccurred with this patch. How reliable that
evidence is remains to be seen.
v2: Explicitly pass the expected physical address to the hw
v3: Also remember the wild writes we once had for HWS above 4G.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Pull the physical status page cleanup into a common
cleanup_status_page() for caller simplicity.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We currently assert that if the target is in a CPU write domain, we use
a CPU reloc path rather than the GPU reloc path. However, we have a debug
override to force the GPU path and that unfortunately hits the assert.
Include the async clflush under the debug option to ensure correct
behaviour even when debugging, and strict when not.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Joonas Lahtinen <[email protected]>
|
|
Add a mode to debugfs/drop-caches to flush unwanted requests off the GPU
(by wedging the device and resetting). This is very useful if a test
terminated leaving a long queue of hanging batches that would ordinarily
require a round trip through hangcheck for each.
It reduces the inter-test operation to just a write into drop-caches to
reset driver/GPU state between tests.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We currently try to pin and allocate the whole buffer at a time. If that
object is larger than RAM, we will try to pin the whole of physical
memory, force the machine into oom, and then still fail the allocation.
If the request is obviously too large, error out early. We opt to do
this in the backend to make it easy to use alternate paths that do not
require the entire object pinned, or may easily handle proxy objects
that are larger than physical memory.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
If we fail to write the user relocation back when it is changed, force
ourselves to take the slow relocation path where we can handle faults in
the write path. There is still an element of dubiousness as having
patched up the batch to use the correct offset, it no longer matches the
presumed_offset in the relocation, so a second pass may miss any changes
in layout.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We do not explicitly mark the PTE for the user's GTT mmap as being
wrprotect, so we don't get a refault when we would need to change a
read-only mmapping into read-write. As such, we must presume that if the
vma has PROT_WRITE it may be written to, although this is supposed to be
indicated by set-domain there are cases (e.g. after swap) where
userspace may not be aware of the implicit domain change.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We only call unset_wedged on the global reset path (since it's a global
operation), so if we are terminally wedged and wish to reset, take the
full device reset path rather than the quicker individual engine resets.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Rather than inspect the global module parameter for whether full-ppgtt
maybe enabled, we can inspect the context directly as to whether it has
its own vm.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Bob Paauwe <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
So far we have been relying on vm->file pointer being NULL to declare
something GGTT.
This has the unfortunate consequence that the default kernel context is
also declared GGTT and interferes with the following patch which wants to
instantiate VMA's and execute requests against the kernel context.
Change the is_ggtt test to use an explicit flag in struct address_space to
solve this issue.
Note that the bit used is free since there is an alignment hole in the
struct.
v2:
* Mark mock ggtt.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Cc: Chris Wilson <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
inadvertently stopped enabling the pipe clock for any DP-MST stream
after the first one. It also rearranged the pipe clock enabling wrt.
initial MST payload allocation step (which may or may not be a
problem, but it's contrary to the spec.).
Fix things by making the above commit truly a non-functional change.
Fixes: afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365
Reported-by: Lyude Paul <[email protected]>
Reported-by: [email protected]
Tested-by: [email protected]
Tested-by: Lyude Paul <[email protected]>
Cc: Lyude Paul <[email protected]>
Cc: [email protected]
Cc: Ville Syrjälä <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This patch resolves the DMC FW loading issue.
Earlier DMC FW package have only one DMC FW for one stepping. But as such
there is no such restriction from Package side.
For ICL icl_dmc_ver1_07.bin binary package has DMC FW for 2 steppings.
So while reading the dmc_offset from package header, for 1st stepping
offset used to come 0x0 and was working fine till now.
But for second stepping and other steppings, offset is non zero number
and is in dwords. So we need to convert into bytes to fetch correct DMC
FW from correct place.
v2 : Added check for DMC FW max size for various gen. (Imre Deak)
v3 : Corrected naming convention for various gen. (Imre Deak)
v4 : Initialized max_fw_size to 0
v5 : Corrected DMC FW MAX_SIZE for various gen. (Imre Deak)
v6 : Fixed the typo issues.
Reviewed-by: Imre Deak <[email protected]>
Signed-off-by: Jyoti Yadav <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Although we cannot do a full system-level test of suspend/hibernate from
deep with the kernel selftests, we can exercise the GEM subsystem in
isolation and simulate the external effects (such as losing stolen
contents and trashing the register state).
v2: Don't forget to hold rpm
v3: Suspend the GTT mappings, and more rpm!
References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
References: 5ab57c702069 ("drm/i915: Flush logical context image out to memory upon suspend")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Jakub Bartmiński <[email protected]>
Cc: Matthew Auld <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Jakub Bartmiński <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The optimisation inherent in commit 6a2c4232ece1 ("drm/i915: Make the
physical object coherent with GTT") relies on that once we allocated a
cursor we would have coherent, zero overhead access to the scanout plane
holding the cursor. That is we could then do the very frequent cursor
updates X enjoys with no indirection or kernel involvement. However,
that all hinges on the GGTT mmap of the cursor being pinned and not
require refaulting on each access -- handling such a page fault likely
requires the busy GGTT to be rearranged causing a stall. A very simple
fix is then to handle the physical cursor exactly like other cursors and
keep its vma pinned while active.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107600
References: 6a2c4232ece1 ("drm/i915: Make the physical object coherent with GTT")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
During stress testing of full-ppgtt (on Baytrail at least), we found
that the invalidation around a context/mm switch was insufficient (writes
would go astray). Adding a second MI_FLUSH_DW barrier prevents this, but
it is unclear as to whether this is merely a delaying tactic or if it is
truly serialising with the TLB invalidation. Either way, it is
empirically required.
v2: Avoid the loop for readability;
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107715
References: https://bugs.freedesktop.org/show_bug.cgi?id=107759
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Matthew Auld <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We need to clear the register in order to get correct value after the
next potential hang.
v2: Centralize error register clearing in i915_irq.c (Chris)
v3: Don't read gen8 register on < gen6 (Chris)
v4: Don't swap gen8+ & gen6+ code... (Chris)
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Joonas Lahtinen <[email protected]>
|
|
Signed-off-by: Joonas Lahtinen <[email protected]>
|
|
On finishing the reset, the intention is to restart the GPU before we
relinquish the forcewake taken to handle the reset - the goal being the
GPU reloads a context before it is allowed to sleep. For this purpose,
we used tasklet_flush() which although it accomplished the goal of
restarting the GPU, carried with it a sting in its tail: it cleared the
TASKLET_STATE_SCHED bit. This meant that if another CPU queued a new
request to this engine, we would clear the flag and later attempt to
requeue the tasklet on the local CPU, breaking the per-cpu softirq
lists.
Remove the dangerous tasklet_kill() and just run the tasklet func
directly as we know it is safe to do so (the tasklets are internally
locked to allow mixed usage from direct submission).
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Michel Thierry <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
During power domains initialization we acquire power well references for
power wells in the INIT power domain. The rest of power wells - which
BIOS could have left enabled - we can only acquire references as needed
during display HW readout and so must defer sanitization until then
(also implying that we must always do HW readout to cleanup unused power
wells).
Thus during initialization these latter power wells can have a refcount
of 0 while still being enabled. To avoid the false-positive state
mismatch error this causes remove the check from
intel_power_domains_init_hw() and rely on the state check in
intel_power_domains_enable() which follows the HW readout.
v2:
- Add comment to log and code clarifying how unused power wells get
disabled. (Chris)
Fixes: 6dfc4a8f134f ("drm/i915: Verify power domains after enabling them")
Cc: Chris Wilson <[email protected]>
References: https://bugs.freedesktop.org/show_bug.cgi?id=107411
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This patch fixes the PPS4 and PPS5 register definition macros that were
resulting into an incorect MMIO address.
Fixes: 2efbb2f099fb ("i915/dp/dsc: Add DSC PPS register definitions")
Cc: Anusha Srivatsa <[email protected]>
Signed-off-by: Manasi Navare <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Anusha Srivatsa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
ICL requires two planes for scanning out a NV12 framebuffer. Do
not advertize support for creating NV12 framebuffers until required
plane programming is implemented.
v2: Do not allow adding buffers.
Check inside skl_plane_has_planar (Ville)
Bspec: Plane Planar YUV programming (18566)
Cc: Ville Syrjälä <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Signed-off-by: Dhinakaran Pandiyan <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
skl_plane_has_planar is hard to read, simplify the logic by checking for
support in the order of platform, pipe and plane.
No change in functionality intended.
v2: Fix logic for primary plane (Ville)
Cc: Ville Syrjälä <[email protected]>
Signed-off-by: Dhinakaran Pandiyan <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Y/Yf tiling can't be used with IF-ID. We already reject uncompressed
Y/Yf but we should also reject them when compressed.
Cc: José Roberto de Souza <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: José Roberto de Souza <[email protected]>
Reviewed-by: Mahesh Kumar <[email protected]>
|
|
.check_plane() already gets the plane state, so we can dig out the plane
from there if needed. No need in passing it separately.
Cc: José Roberto de Souza <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
gcc is too smart for us and doesn't evaluate BUILD_BUG_ON()s in
unused static inlines. Collect them up in one static inline and
actually call it to make sure gcc sees it.
Cc: Chris Wilson <[email protected]>
Suggested-by: Chris Wilson <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Chris Wilson <[email protected]>
|
|
Now that we have a generic caller let's simplify it and
clean up the intel_psr.c code a bit.
Cc: Dhinakaran Pandiyan <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
No functional change. But let's get first i915 pointer
directly from intel_dp so we can clean up a lot of code
later.
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We currently verify that all doorbells can be registered with GuC and
HW but don't check that all works as expected after a db ring.
Do a nop ring of all doorbells to make sure we haven't misprogrammed
any WQ or stage descriptor data. This will also help validating
upcoming changes in the db programming flow.
Cc: Michel Thierry <[email protected]>
Cc: Michal Wajdeczko <[email protected]>
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Michel Thierry <[email protected]>
Acked-by: Katarzyna Dec <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Added bspec reference, aligned text and documented the function.
Cc: Rodrigo Vivi <[email protected]>
Signed-off-by: Dhinakaran Pandiyan <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
CI runs show PSR2 does not go to IDLE with selective update enabled on
all PSR exit triggers. Specifically, logs indicate the hardware enters
"SLEEP Selective Update" and not "IDLE Reset state', like the kernel
expects, when vblank interrupts are enabled. This check was added for PSR1
but incorrectly extended to PSR2, remove the check as it breaks tests
and prints out misleading error messages.
v2: Split out non-code changes (Rodrigo)
Cc: Tarun Vyas <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Fixes: c43dbcbbcc8c ("drm/i915/psr: Lockless version of psr_wait_for_idle")
Signed-off-by: Dhinakaran Pandiyan <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
pulse"
This re-applies the workaround for "some DP sinks, [which] are a
little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
quality check unconditionally during long pulse").
It makes the secondary AOC E2460P monitor connected via DP to an
acer Veriton N4640G usable again.
This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
DP link retraining into the ->post_hotplug() hook")
Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook")
[Cleaned up commit message, added stable cc]
Signed-off-by: Lyude Paul <[email protected]>
Signed-off-by: Jan-Marek Glogowski <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There's no need for that forward declaration.
Cc: Imre Deak <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Signed-off-by: Paulo Zanoni <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use the nice helper function to make the implementation simpler.
v2: Rebase.
Cc: Imre Deak <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]> (v1)
Signed-off-by: Paulo Zanoni <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
None of the current lookup_power_well() callers are actually checking
for NULL return values, they all just use the pointer right away. The
first idea was to replace these theoretical segfaults with a BUG()
since this would at least make our code a little more explicit to the
reader. It was suggested that just converting the BUG() to a WARN()
and returning any power well would probably be better since it would
still keep the system running while at the same time exposing the
driver bug.
We can only hit this NULL/BUG()/WARN() condition if we try to lookup a
power well that isn't defined on a given platform. If that ever
happens, we have to fix our code, making it lookup the correct power
well. Because of this, I don't think it's worth trying to implement
error checking in every caller. Improving our CI system will be a
better use of our time once a bug is found in the wild.
v2: Avoid the BUG() with a WARN() return a random PW (Michal).
Cc: Michal Wajdeczko <[email protected]>
Cc: Imre Deak <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Signed-off-by: Paulo Zanoni <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Unlike the other ports, TC ports are not available to use as soon as
we get a hotplug. The TC PHYs can be shared between multiple
controllers: display, USB, etc. As a result, handshaking through FIA
is required around connect and disconnect to cleanly transfer
ownership with the controller and set the type-C power state.
This patch implements the flow sequences described by our
specification. We opt to grab ownership of the ports as soon as we get
the hotplugs in order to simplify the interactions and avoid surprises
in the user space side. We may consider changing this in the future,
once we improve our testing capabilities on this area.
v2:
* This unifies the DP and HDMI patches so we can discuss everything
at once so people looking at random single patches can actually
understand the direction.
* I found out the spec was updated a while ago. There's a small
difference in the connect flow and the patch was updated for that.
* Our spec also now gives a good explanation on what is really
happening. As a result, comments were added.
* Add some more comments as requested by Rodrigo (Rodrigo).
v3:
* Downgrade a DRM_ERROR that shouldn't ever happen but we can't act
on in case it does (Chris).
BSpec: 21750, 4250.
Cc: Animesh Manna <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Paulo Zanoni <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|