== Series Details ==
Series: drm/i915/display: avoid abnormal pixel output when turn eDP display off
(rev2)
URL : https://patchwork.freedesktop.org/series/106910/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11975 -> Patchwork_106910v2
===
On Tue, 9 Aug 2022 00:15:14 +
"Vivi, Rodrigo" wrote:
> On Tue, 2022-08-09 at 01:09 +0200, Andi Shyti wrote:
> > Hi Rodrigo,
> >
> > On Mon, Aug 08, 2022 at 03:04:13PM -0400, Rodrigo Vivi wrote:
> > > On Mon, Aug 08, 2022 at 06:37:58PM +0200, Andi Shyti wrote:
> > > > Hi Mauro,
> > > >
> > >
== Series Details ==
Series: drm/display/dp_mst: Drop Radeon MST support, make MST atomic-only
URL : https://patchwork.freedesktop.org/series/107073/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11975 -> Patchwork_107073v1
== Series Details ==
Series: drm/display/dp_mst: Drop Radeon MST support, make MST atomic-only
URL : https://patchwork.freedesktop.org/series/107073/
State : warning
== Summary ==
Error: dim checkpatch failed
1edd44d8fda1 drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)
0dc527949f22
On Tue, 2022-08-09 at 01:09 +0200, Andi Shyti wrote:
> Hi Rodrigo,
>
> On Mon, Aug 08, 2022 at 03:04:13PM -0400, Rodrigo Vivi wrote:
> > On Mon, Aug 08, 2022 at 06:37:58PM +0200, Andi Shyti wrote:
> > > Hi Mauro,
> > >
> > > On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab
> > > wr
Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on, as
We want to start cutting down on all of the places that we use port
validation, so that ports may be removed from the topology as quickly as
possible to minimize the number of errors we run into as a result of being
out of sync with the current topology status. This isn't a very typical
scenario an
Right now, radeon is technically the only non-atomic driver still making
use of the MST helpers - and thus the final user of all of the legacy MST
helpers. Originally I was going to look into seeing if we could move legacy
MST into the radeon driver itself, however:
* SI and CIK both can use amdgp
Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to
indicate that we're about to delete a payload in the current atomic state.
Since we're going to be dropping all of the legacy code for handling the
payload table however, we need to be able to ensure that we still keep
track of th
In the past, we've ran into strange issues regarding errors in response to
trying to destroy payloads after a port has been unplugged. We fixed this
back in:
This is intended to replace the workaround that was added here:
commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports i
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* User
Currently with the MST helpers we avoid releasing payloads _and_ avoid
pulling in the MST state if there aren't any actual payload changes. While
we want to keep the first step, we need to now make sure that we're always
pulling in the MST state on all modesets that can modify payloads - even if
th
I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using t
As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.
This could pot
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia
GPUs are SORs (serial output resources). Because SORs have fixed
associations with their connectors, we can correctly assume that any DP
connector on a nvidia GPU will have exactly one SOR encoder routed to it
for DisplayPo
Since we're going to be relying on atomic locking for payloads now (and the
MST mgr needs to track CRTCs), pull in the topology state for all modesets
in nv50_msto_atomic_check().
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
1 file changed,
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
i
For some reason we mention returning 0 if "slots have been added back to
drm_dp_mst_topology_state->avail_slots". This is totally misleading,
avail_slots is simply for figuring out the total number of slots available
in total on the topology and has no relation to the current payload
allocations.
VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.
Now that we actually have consistent ac
In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
drm_dp_mst_atomic_
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdg
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few t
For quite a while we've been carrying around a lot of legacy modesetting
code in the MST helpers that has been rather annoying to keep around,
and very often gets in the way of trying to implement additional
functionality in MST such as fallback link rate retraining, dynamic BPC
management and DSC
== Series Details ==
Series: Sanitycheck PCI BARs (rev2)
URL : https://patchwork.freedesktop.org/series/106927/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11971_full -> Patchwork_106927v2_full
Summary
---
**SUCCES
Hi Rodrigo,
On Mon, Aug 08, 2022 at 03:04:13PM -0400, Rodrigo Vivi wrote:
> On Mon, Aug 08, 2022 at 06:37:58PM +0200, Andi Shyti wrote:
> > Hi Mauro,
> >
> > On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab wrote:
> > > WRITE_ONCE() should happen at the original var, not on a local
On Mon, 2022-08-08 at 10:02 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Thursday, August 4, 2022 4:28 AM
> > To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> > nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Cc: Vil
== Series Details ==
Series: Sanitycheck PCI BARs (rev2)
URL : https://patchwork.freedesktop.org/series/106927/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11971 -> Patchwork_106927v2
Summary
---
**SUCCESS**
No
On Thu, 7 Apr 2022 03:19:43 -0400
Zhi Wang wrote:
> From: Zhi Wang
>
> To support the new mdev interfaces and the re-factor patches from
> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> MMIO tracking table needs to be separated from GVT-g.
>
Since this commit I'm
On Fri, Aug 05, 2022 at 05:41:38PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Sanitycheck PCI BARs (rev2)
> URL : https://patchwork.freedesktop.org/series/106927/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11971 -> Patchwork_106927v2
>
On Mon, Aug 08, 2022 at 06:37:58PM +0200, Andi Shyti wrote:
> Hi Mauro,
>
> On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab wrote:
> > WRITE_ONCE() should happen at the original var, not on a local
> > copy of it.
> >
> > Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations"
On 8/4/2022 17:40, Teres Alexis, Alan Previn wrote:
I have a question on below code. Everything else looked good.
Will r-b as soon as we can close on below question
...alan
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
From: John Harrison
It is useful to be able to matc
Hi Mauro,
On Thu, Aug 04, 2022 at 09:37:24AM +0200, Mauro Carvalho Chehab wrote:
> Add a description for the TLB cache invalidation algorithm and for
> the related kAPI functions.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Andi Shyti
Andi
Hi Mauro,
On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab wrote:
> WRITE_ONCE() should happen at the original var, not on a local
> copy of it.
>
> Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations")
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Andi Shyti
Are y
Hi, [back from vacation]
On Tue, 2022-07-26 at 16:39 +0100, Robert Beckett wrote:
> Calling swiotlb functions directly is nowadays considered harmful.
> See
> https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
>
> Replace swiotlb_max_segment() calls with dma_max_mapping_size().
> In
== Series Details ==
Series: series starting with [RESUBMIT,1/2] drm/i915/gem: Avoid taking
runtime-pm under the shrinker
URL : https://patchwork.freedesktop.org/series/106838/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11960_full -> Patchwork_106838v1_full
===
== Series Details ==
Series: drm/i915/d13: Fix unclaimed accesses while loading PIPEDMC-C/D
URL : https://patchwork.freedesktop.org/series/107059/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11972_full -> Patchwork_107059v1_full
==
On Fri, Aug 05, 2022 at 03:53:41PM -0600, Jim Cromie wrote:
> Rework/modernize docs:
>
> - use /proc/dynamic_debug/control in examples
>its *always* there (when dyndbg is config'd), even when is not.
>drop talk, its a distraction here.
>
> - alias ddcmd='echo $* > /proc/dynamic_debug/
On Mon, 2022-08-01 at 17:20 +, Sean Christopherson wrote:
> On Thu, Jul 28, 2022, Maxim Levitsky wrote:
> > On Mon, 2022-07-25 at 16:08 +, Sean Christopherson wrote:
> > > On Wed, Jul 20, 2022, Maxim Levitsky wrote:
> > > And on that topic, do you have performance numbers to justify using a
== Series Details ==
Series: Avoid parent bridge rpm on mmap mappings
URL : https://patchwork.freedesktop.org/series/107061/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11972 -> Patchwork_107061v1
Summary
---
**FAI
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/edid: convert DP, HDMI and LVDS
to drm_edid
URL : https://patchwork.freedesktop.org/series/107056/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11971_full -> Patchwork_107056v1_full
=
== Series Details ==
Series: Avoid parent bridge rpm on mmap mappings
URL : https://patchwork.freedesktop.org/series/107061/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Am 25.07.22 um 13:42 schrieb Arunpravin Paneer Selvam:
Implemented a new intersect and compatible callback functions
to ttm range manager fetching start offset from drm mm range
allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/ttm/ttm_r
== Series Details ==
Series: drm/i915/d13: Fix unclaimed accesses while loading PIPEDMC-C/D
URL : https://patchwork.freedesktop.org/series/107059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11972 -> Patchwork_107059v1
Su
Am 25.07.22 um 13:42 schrieb Arunpravin Paneer Selvam:
We are adding two new callbacks to ttm resource manager
function to handle intersection and compatibility of
placement and resources.
v2: move the amdgpu and ttm_range_manager changes to
separate patches (Christian)
Signed-off-by: Chri
As per PCIe Spec Section 5.3,
When a Type 1 Function associated with a Switch/Root
Port (a “virtual bridge”) is in a non-D0 power state,
it will emulate the behavior of a conventional PCI bridge
in its handling of Memory, I/O, and Configuration
Requests and Completions. All Memory and I/O requests
RFC proposal to get community feedback to handle the lmem
mmap memory mappings. We can have two solutions.
1. Avoid rpm for any mmap mapping.
2. Update the page tables while entering to runtime suspend to raise
a page fault while device in D3.
Solution 2 will incur huge latency versus solution
At the moment on DG2 at least loading the DMC firmware's PIPEDMC C and D
programs leads to sporadic unclaimed register accesses while programming
the initial state as described by the firmware's "MMIO init" table. This
will also lead to later unclaimed accesses for unrelated transcoder/pipe
registe
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/edid: convert DP, HDMI and LVDS
to drm_edid
URL : https://patchwork.freedesktop.org/series/107056/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11971 -> Patchwork_107056v1
===
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/edid: convert DP, HDMI and LVDS
to drm_edid
URL : https://patchwork.freedesktop.org/series/107056/
State : warning
== Summary ==
Error: dim checkpatch failed
0303ec97282f drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
-
Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 19 ++-
drivers/gpu/drm/i915/display/
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Since drm_get_edid() calls drm_connector_update_edid_property() while
drm_edid_read*() do not, we need to call drm_edid_connector_update()
separately, in part due to the EDID caching behaviour in HDMI and
DP. Es
52 matches
Mail list logo
