This patch fixes the private_flags of mode to be checked and
compared against uapi.mode and not from hw.mode. This helps
properly trigger modeset at boot if desired by driver.
It helps resolve audio_codec initialization issues if display
is connected at boot. Initial discussion on this issue has h
> -Original Message-
> From: Khor, Swee Aun
> Sent: Tuesday, March 24, 2020 11:26 AM
> To: Ville Syrjälä ; Shankar, Uma
>
> Cc: Souza, Jose ; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot
> for audio
> codec init
>
> Git
== Series Details ==
Series: drm/i915/display: Fix mode private_flags comparison at atomic_check
URL : https://patchwork.freedesktop.org/series/75106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190 -> Patchwork_17093
Su
On Thu, 26 Mar 2020, Masahiro Yamada wrote:
> CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
> Use SSE4.1 movntdqa to accelerate reads from WC memory").
>
> We raise the minimal supported binutils version from time to time.
> The last bump was commit 1fb12b35e5ff ("kbuild: Ra
Beware dereferencing the NULL pointer prior to checking for its
existence.
Fixes: 419190429cd1 ("drm/i915/hdmi: use struct drm_device based logging")
Signed-off-by: Chris Wilson
Cc: Wambui Karuga
Cc: Jani Nikula
Cc: "Ville Syrjälä"
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++---
1 fi
On Thu, 26 Mar 2020, Chris Wilson wrote:
> Beware dereferencing the NULL pointer prior to checking for its
> existence.
Huh, I don't see the failure mode. Please enlighten me.
BR,
Jani.
>
> Fixes: 419190429cd1 ("drm/i915/hdmi: use struct drm_device based logging")
> Signed-off-by: Chris Wilson
On 26/03/2020 06:43, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead t
== Series Details ==
Series: drm/i915/display: Remove useless but deadly local
URL : https://patchwork.freedesktop.org/series/75109/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190 -> Patchwork_17094
Summary
---
*
On 25/03/2020 23:48, Chris Wilson wrote:
We've migrated all the heavy users over to the intel_gt, and can finally
drop the last few users and with that the mirror in dev_priv->engine[].
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_ov
* Masahiro Yamada wrote:
> > LGTM. I've got these four from Jason A. Donenfeld queued up in
> > tip:WIP.x86/asm:
> >
> > bd5b1283e41c: ("crypto: Curve25519 - do not pollute dispatcher based on
> > assembler")
> > 829f32d78588: ("crypto: X86 - rework configuration, based on Kconfig")
> > 95e
* Jason A. Donenfeld wrote:
> Very little has changed from last time, and this whole series still
> looks good to me. I think I already ack'd most packages, but in case
> it helps:
>
> Reviewed-by: Jason A. Donenfeld
Acked-by: Ingo Molnar
> Since this touches a lot of stuff, it might be be
== Series Details ==
Series: drm/i915/display: Fix mode private_flags comparison at atomic_check
URL : https://patchwork.freedesktop.org/series/75106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190_full -> Patchwork_17093_full
==
On Thu, 26 Mar 2020, Chris Wilson wrote:
> Beware dereferencing the NULL pointer prior to checking for its
> existence.
Okay, so the crt code calls ddi functions, and enc_to_dig_port() will
return NULL. Backtrace for posterity below, copy-pasted from logs Chris
pointed me at.
I think alternative
== Series Details ==
Series: drm/i915/display: Remove useless but deadly local
URL : https://patchwork.freedesktop.org/series/75109/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190_full -> Patchwork_17094_full
Summary
--
Op 26-03-2020 om 08:49 schreef Uma Shankar:
> This patch fixes the private_flags of mode to be checked and
> compared against uapi.mode and not from hw.mode. This helps
> properly trigger modeset at boot if desired by driver.
>
> It helps resolve audio_codec initialization issues if display
> is co
this patch adds hdr capabilities checks for Gen9 devices with
lspcon support.
Signed-off-by: Vipin Anand
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 17 +
drivers/gpu/drm/i915/display/intel_lspcon.c | 9 +++--
2 files changed, 20 insertions(+), 6 deletions(-)
diff --g
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rend
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Maarten Lankhorst
---
.../gpu/d
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/g
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938 100644
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
This patch fixes the private_flags of mode to be checked and
compared against uapi.mode and not from hw.mode. This helps
properly trigger modeset at boot if desired by driver.
It helps resolve audio_codec initialization issues if display
is connected at boot. Initial discussion on this issue has h
> -Original Message-
> From: Maarten Lankhorst
> Sent: Thursday, March 26, 2020 4:18 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjä ; Kai Vehmanen
> ; Souza, Jose ; Khor, Swee
> Aun
> Subject: Re: [PATCH] drm/i915/display: Fix mode private_flags comparison at
Op 26-03-2020 om 13:24 schreef Uma Shankar:
> This patch fixes the private_flags of mode to be checked and
> compared against uapi.mode and not from hw.mode. This helps
> properly trigger modeset at boot if desired by driver.
>
> It helps resolve audio_codec initialization issues if display
> is co
This patch fixes the private_flags of mode to be checked and
compared against uapi.mode and not from hw.mode. This helps
properly trigger modeset at boot if desired by driver.
It helps resolve audio_codec initialization issues if display
is connected at boot. Initial discussion on this issue has h
> -Original Message-
> From: Maarten Lankhorst
> Sent: Thursday, March 26, 2020 5:38 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjä ; Kai Vehmanen
> ; Souza, Jose ; Khor, Swee
> Aun
> Subject: Re: [v2] drm/i915/display: Fix mode private_flags comparison at
> a
This series of cleanups was prompted by Linus:
https://lkml.org/lkml/2020/3/12/726
First, this series drop always-on CONFIG_AS_* options.
Some of those options were introduced in old days.
For example, the check for CONFIG_AS_CFI dates back to 2006.
We raise the minimal tool versions from time to
CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
Use SSE4.1 movntdqa to accelerate reads from WC memory").
We raise the minimal supported binutils version from time to time.
The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum
required binutils version to 2.21").
Very little has changed from last time, and this whole series still
looks good to me. I think I already ack'd most packages, but in case
it helps:
Reviewed-by: Jason A. Donenfeld
Since this touches a lot of stuff, it might be best to get it in as
early as possible during the merge window, as I i
On Mon, 23 Mar 2020, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> The mock device in the selftests needed it's pci_device split
> up from the drm_device. In the future we could simplify this again
> by allocating the pci_device as a managed allocation
On Wed, 25 Mar 2020, Jani Nikula wrote:
> On Mon, 23 Mar 2020, Daniel Vetter wrote:
>> For two reasons:
>>
>> - The driver core clears this already for us after we're unloaded in
>> __device_release_driver().
>>
>> - It's way too late, the drm_device ->release callback might massively
>> outl
On Wed, 25 Mar 2020, Chris Wilson wrote:
> Avoid using the uninitialised len along the impossible error path to
> shut the compiler up:
>
> drivers/gpu/drm/i915/display/intel_dp.c:4928 intel_write_dp_sdp() error:
> uninitialized symbol 'len'.
Why am I not seeing this? GCC 8.3.0
Reviewed-by: Jan
On Thu, Mar 26, 2020 at 2:11 PM Jani Nikula wrote:
>
> On Mon, 23 Mar 2020, Daniel Vetter wrote:
> > With this we can drop the final kfree from the release function.
> >
> > The mock device in the selftests needed it's pci_device split
> > up from the drm_device. In the future we could simplify t
On Mon, Mar 23, 2020 at 03:49:00PM +0100, Daniel Vetter wrote:
> slab does this already, and I want to use this in a memory allocation
> tracker in drm for stuff that's tied to the lifetime of a drm_device,
> not the underlying struct device. Kinda like devres, but for drm.
>
> Acked-by: Andrew Mo
This series adds i915_lpsp_info connector debugfs.
v3 has fixed some review comments on patch (2/3)
and added RB tag on patch (3/3).
Test-with: 20200326131929.23072-1-anshuman.gu...@intel.com
Anshuman Gupta (3):
drm/i915: Power well id for ICL PG3
drm/i915: Add i915_lpsp_info debugfs
drm/i9
Gen11 onwards PG3 is contains functions for pipe B,
external displays, and VGA. It make sense to add
a power well id with name ICL_DISP_PW_3 rather then
TGL_DISP_PW_3, Also PG3 power well id requires to
know if lpsp is enabled.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel
Add connector debugfs attributes for each intel
connector which is getting register.
v2:
- adding connector debugfs for each connector in
intel_connector_register() to fix CI failure for legacy connectors.
Reviewed-by: Jani Nikula
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/displa
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_info, it exposes whether an output is
capable of driving lpsp and exposes lpsp enablement info.
v2:
- CI fixup.
v3:
- register i915_lpsp_info only for supported connector. [Jani]
- use intel_display_pow
drm-misc-fixes-2020-03-26:
drm-misc-fixes for v5.6:
- SG fixes for prime, radeon and amdgpu.
The following changes since commit b216a8e7908cd750550c0480cf7d2b3a37f06954:
drm/lease: fix WARNING in idr_destroy (2020-03-18 14:42:18 +0100)
are available in the Git repository at:
git://anongit.fr
> -Original Message-
> From: Shankar, Uma
> Sent: Thursday, March 26, 2020 6:21 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Ville Syrjä
> ; Maarten Lankhorst
> ; Kai Vehmanen
> ; Souza; Souza, Jose ;
> Khor, Swee Aun
> Subject: [v3] drm/i915/display: Fix mode private_f
Userptr causes lockdep to complain when we are using the aliasing-ppgtt
(and ggtt, but for that it is rightfully so to complain about) in that
when we revoke the userptr we take a mutex which we also use to revoke
the mmaps. However, we only revoke mmaps for GGTT bindings and we never
allow userptr
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
A few very simple testcases to exercise the dma-fence-chain API.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-chain.c | 713 +++
3 files changed, 716 insertions(+)
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11 ins
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct cont
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilso
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
v2: Also measure throughput using only one thread.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gp
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.
Signed-off-by: Chris Wilson
Reviewed-by:
On Mon, Mar 23, 2020 at 03:48:59PM +0100, Daniel Vetter wrote:
> Hi all,
>
> Another round, another set of polish all over. intel-gfx-ci was happy last
> time around (after I fixed a fumble), so really just review and comments
> needed now. There's still a few patches at the beginning holding the
On Tue, Mar 24, 2020 at 06:46:10PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 24, 2020 at 03:32:09PM +, Laxminarayan Bharadiya, Pankaj
> wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: 23 March 2020 20:18
> > > To: Laxminarayan Bharadiya, Pankaj
> > >
>
On Thu, Mar 26, 2020 at 08:45:59PM +0530, Bharadiya,Pankaj wrote:
> On Tue, Mar 24, 2020 at 06:46:10PM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 24, 2020 at 03:32:09PM +, Laxminarayan Bharadiya, Pankaj
> > wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä
>
On Thu, Mar 26, 2020 at 01:19:28PM +0530, Uma Shankar wrote:
> This patch fixes the private_flags of mode to be checked and
> compared against uapi.mode and not from hw.mode. This helps
> properly trigger modeset at boot if desired by driver.
>
> It helps resolve audio_codec initialization issues
Allow a bit of leniency for the CPU scheduler to be distracted while we
flush the tasklet and so ensure that we always check the status of the
request once more before timing out.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 11 +--
1 file changed, 5 insertion
On Thu, 2020-03-05 at 15:12 -0500, Sean Paul wrote:
> From: Sean Paul
>
> Used to query whether an MST stream is encrypted or not.
>
> Signed-off-by: Sean Paul
>
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> #v4
>
> Changes in v4:
> -Added
On Wed, 25 Mar 2020 at 21:23, George Spelvin wrote:
>
> igt_mm_config() calls ilog2() on the (pseudo)random 21-bit number
> s>>12. Once in 2 million seeds, this is zero and ilog2 summons
> the nasal demons.
>
> There was an attempt to handle this case with a max(), but that's
> too late; ms could
== Series Details ==
Series: drm:i915:display: add checks for Gen9 devices with hdr capability
URL : https://patchwork.freedesktop.org/series/75114/
State : failure
== Summary ==
Applying: drm:i915:display: add checks for Gen9 devices with hdr capability
error: sha1 information is lacking or u
== Series Details ==
Series: series starting with [01/21] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75115/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d083289b34df Revert "drm/i915/gem: Drop relocation slowpath"
-:78: WARN
== Series Details ==
Series: series starting with [01/21] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75115/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8194 -> Patchwork_17096
==
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, March 26, 2020 9:47 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; Maarten Lankhorst
> ; Kai Vehmanen
> ; Souza; Souza, Jose ;
> Khor, Swee Aun
> Subject: Re: [PATCH] drm/i915/display: Fix mode private_flags com
On Wed, Mar 25, 2020 at 06:52:52PM -0700, Dixit, Ashutosh wrote:
On Wed, 25 Mar 2020 17:32:35 -0700, Umesh Nerlige Ramappa wrote:
On Wed, Mar 25, 2020 at 11:20:19AM -0700, Ashutosh Dixit wrote:
> It is wrong to block the user thread in the next poll when OA data is
> already available which cou
Upon a GPU reset, we copy the default context image over top of the
guilty image. This will rollback the CTX_TIMESTAMP register to before
our value of ce->runtime.last. Reset both back to 0 so that we do not
encounter an underflow on the next schedule out after resume.
This should not be a huge is
The pool will be private to GuC in the new submission scheme, so we
won't be able to print it and we can just drop the current legacy code.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_deb
We currently initialize HuC support based on GuC being enabled in
modparam; this means that huc_is_supported() can return false on HW that
does have a HuC when enable_guc=0. The rationale for this behavior is
that HuC requires GuC for authentication and therefore is not supported
by itself. However
uC is a component of the GT, so it makes sense for the uC debugfs files
to be in the GT folder. A subfolder has been used to keep the same
structure we have for the code.
v2: use intel_* prefix (Jani), rebase on new gt_debugfs_register_files,
fix permissions for writable debugfs files.
v3: Re
Minor changes applied to patch 5, which is the only one missing a
review.
As multiple people have noted, intel_gt_debugfs_register_files is
now generic enough to be pulled out of gt/. Andi has patches for that
and will follow up after this series is merged.
Cc: Andi Shyti
Cc: Michal Wajdeczko
C
We need to keep the GuC error logs around to debug the load failure,
so we can't clean them in the error unwind, which includes uc_fini().
Moving the cleanup to driver remove ensures that the logs stick around
long enough for us to dump them.
v2: reword commit msg (John)
Signed-off-by: Daniele Ce
From: Andi Shyti
When registering debugfs files the intel gt debugfs library
forces a 'struct *gt' private data on the caller.
To be open to different usages make the new
"intel_gt_debugfs_register_files()"[*] function more generic by
converting the 'struct *gt' pointer to a 'void *' type.
I ta
Move the printers to the respective files for clarity. The
guc_load_status debugfs has been squashed in the guc_info one, has
having separate ones wasn't very useful. The HuC debugfs has been
renamed huc_info to match.
v2: keep printing HUC_STATUS2 (Tony), avoid const->non-const
container_of (
Add correspondent helpers to be able to get old/new bandwidth
global state object.
v2: - Fixed typo in function call
v3: - Changed new functions naming to use convention proposed
by Jani Nikula, i.e intel_bw_* in intel_bw.c file.
v4: - Change function naming back to intel_atomic* pattern,
Addressing one of the comments, recommending to extract platform
specific code from intel_can_enable_sagv as a preparation, before
we are going to add support for tgl+.
Current code in intel_can_enable_sagv is valid only for skl,
so this patch adds also proper support for icl, subsequent
patches w
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be
Let's refactor the whole SAGV logic, moving
the main calculations from intel_can_enable_sagv
to intel_compute_sagv_mask, which also handles
this in a unified way calling gen specific
functions to evaluate if SAGV is allowed for
each crtc. If crtc sagv mask have been changed
we serialize access and
That is a preparation patch before next one where we
introduce old_bw_state and a bunch of other changes
as well.
In a review comment it was suggested to split out
at least that renaming into a separate patch, what
is done here.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display
For Gen11+ platforms BSpec suggests disabling specific
QGV points separately, depending on bandwidth limitations
and current display configuration. Thus it required adding
a new PCode request for disabling QGV points and some
refactoring of already existing SAGV code.
Also had to refactor intel_can
According to many computer science sources - magic values
in code _are_ _bad_. For many reasons: the reason is that "0"
or "1" or whatever magic values confuses and doesn't give any
info why this parameter is this value and what it's meaning
is.
I renamed "0" to COLOR_PLANE_Y and "1" to COLOR_PLANE
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_reg.h | 4
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
v2: Changed latency type from u32 to unsigned int(Ville Syrjälä)
Reviewe
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6e4d64b626f8..4c278493559a 100644
--- a/dr
1 - 100 of 150 matches
Mail list logo
