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
> -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
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
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
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
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
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 ++-
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
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
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
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
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
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
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(+),
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
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:
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 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
---
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
---
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
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
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
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
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
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
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
== 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
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
== 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
* 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
* 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")
> >
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
---
== 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 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
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
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
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:
== 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
> -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
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
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev2)
URL : https://patchwork.freedesktop.org/series/75085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190_full -> Patchwork_17092_full
101 - 141 of 141 matches
Mail list logo
