(), amdgpu had no way of telling when a
deadlock happened from these helpers. This could definitely result in some
kernel splats.
V2:
* Address Wayne's comments (fix another bunch of spots where we weren't
passing down return codes)
Signed-off-by: Lyude Paul
Fixes: 8c20a1ed9b4f ("drm/a
without doing
compression, and on ret == -ENOSPC it should just continue the function from
there
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
On Wed, 2022-11-09 at 09:48 +, Lin, Wayne wrote:
> [Public]
>
> Thanks, Lyude!
> Comments inline.
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, November 5, 2022 7:59 AM
> > To: amd-...@lists.freedesktop.org
> > Cc: Wen
}
>
> -void
> +static void
> wpr_generic_header_dump(struct nvkm_subdev *subdev, const struct
> wpr_generic_header *hdr)
> {
> nvkm_debug(subdev, "wprGenericHeader\n");
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
For the whole series:
Reviewed-by: Lyude Paul
Will push to drm-misc-next in a bit
On Fri, 2022-11-11 at 17:11 +0800, Jiapeng Chong wrote:
> This symbol is not used outside of acr.c, so marks it static.
>
> drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototy
Reviewed-by: Lyude Paul
Will go ahead and push these two upstream, thanks!
On Tue, 2022-11-01 at 15:07 +0800, Shang XiaoJing wrote:
> drm_dev_init() will add drm_dev_init_release() as a callback. When
> drmm_add_action() failed, the release function won't be added. As the
> resul
Reviewed-by: Lyude Paul
On Tue, 2022-11-01 at 15:07 +0800, Shang XiaoJing wrote:
> drm_vblank_init() call drmm_add_action_or_reset() with
> drm_vblank_init_release() as action. If __drmm_add_action() failed, will
> directly call drm_vblank_init_release() with the vblank whose worker
al
to cause a deadlock.
Signed-off-by: Lyude Paul
Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC
MST CRTCs")
Cc: # v5.6+
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
(), amdgpu had no way of telling when a
deadlock happened from these helpers. This could definitely result in some
kernel splats.
Signed-off-by: Lyude Paul
Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share")
Cc: Harry Wentland
Cc: # v5.6+
---
.../gpu/drm/amd/display/amdgpu_dm/a
Reviewed-by: Lyude Paul
Will push in just a moment to drm-misc-next, thanks!
On Mon, 2022-10-17 at 08:07 +0800, Yang Li wrote:
> ./drivers/gpu/drm/nouveau/nouveau_dmem.c: nvif/if000c.h is included more
> than once.
>
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2404
&
For the nouveau bits:
Reviewed-by: Lyude Paul
On Tue, 2022-10-18 at 22:43 -0400, Zack Rusin wrote:
> From: Zack Rusin
>
> v4: Fix issue spotted by the kernel test robot
>
> The fb_base in struct drm_mode_config has been unused for a long time.
> Some drivers set it and som
For the nouveau bits:
Reviewed-by: Lyude Paul
On Thu, 2022-10-20 at 14:56 -0700, Dan Williams wrote:
> A 'struct dev_pagemap' (pgmap) represents a collection of ZONE_DEVICE
> pages. The pgmap is a reference counted object that serves a similar
> role as a 'struct request
Reviewed-by: Lyude Paul
Will push to drm-misc-next as well
On Thu, 2022-10-20 at 21:07 -0400, Zack Rusin wrote:
> From: Zack Rusin
>
> Trivial removal of an unused variable. Not sure how it snuck by me and
> build bots in the 7c99616e3fe7.
>
> Fixes: 7c99616e
Gotcha, I'll take another look at this tomorrow
On Mon, 2022-10-17 at 03:09 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-----
> > From: Lyude Paul
> > Sent: Thursday, October 6, 2022 3:37 AM
> > To: Siqueira, Rodrigo ;
LGTM! Thank you for the help with this:
Reviewed-by: Lyude Paul
On Mon, 2022-10-17 at 15:32 +, Simon Ser wrote:
> A typical DP-MST unplug removes a KMS connector. However care must
> be taken to properly synchronize with user-space. The expected
> sequence of events is the followin
...oops, totally forgot to actually give you the magic tag so patchwork knows
I reviewed it:
Reviewed-by: Lyude Paul
On Sat, 2022-09-24 at 17:25 +0800, ruanjinjie wrote:
> When build Linux kernel with 'make C=2', encounter the following warnings:
>
> ./drivers/gpu/drm/nouv
ruct nvif_push *push, u32 size)
> if (WARN_ON(size > dmac->max))
> return -EINVAL;
>
> - dmac->cur = push->cur - (u32 *)dmac->_push.mem.object.map.ptr;
> + dmac->cur = push->cur - (u32 __iomem *)dmac->_push.mem.object.map.ptr;
> if (dmac->cur + size >= dmac->max) {
> int ret = nv50_dmac_wind(dmac);
> if (ret)
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
On Tue, 2022-10-04 at 16:46 -0400, Rodrigo Siqueira Jordao wrote:
>
> On 2022-10-04 16:24, Lyude Paul wrote:
> > Yikes, it appears somehow I totally made a mistake here. We're currently
> > checking to see if drm_dp_add_payload_part2() returns a non-zero value to
>
t.
Signed-off-by: Lyude Paul
Issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic
state")
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
Re comments about infinite retry: gotcha, makes sense to me.
On Tue, 2022-09-27 at 09:45 +1000, Alistair Popple wrote:
> John Hubbard writes:
>
> > On 9/26/22 14:35, Lyude Paul wrote:
> > > > + for (i = 0; i < npages; i++) {
> > > > +
Reviewed-by: Lyude Paul
On Wed, 2022-09-28 at 22:01 +1000, Alistair Popple wrote:
> When the module is unloaded or a GPU is unbound from the module it is
> possible for device private pages to still be mapped in currently
> running processes. This can lead to a hangs and RCU stall warn
On Tue, 2022-09-27 at 11:39 +1000, Alistair Popple wrote:
> Felix Kuehling writes:
>
> > On 2022-09-26 17:35, Lyude Paul wrote:
> > > On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
> > > > When the module is unloaded or a GPU is unbound from the
mem_fini(struct nouveau_drm *drm)
> mutex_lock(&drm->dmem->mutex);
>
> list_for_each_entry_safe(chunk, tmp, &drm->dmem->chunks, list) {
> + nouveau_dmem_evict_chunk(chunk);
> nouveau_bo_unpin(chunk->bo);
> nouveau_bo_ref(NULL, &chunk->bo);
> + WARN_ON(chunk->callocated);
> list_del(&chunk->list);
> memunmap_pages(&chunk->pagemap);
> release_mem_region(chunk->pagemap.range.start,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
AGE_SIZE, DMA_BIDIRECTIONAL);
> + return -EIO;
> + }
Feel free to just align this with the starting (, as long as it doesn't go
above 100 characters it doesn't really matter imho and would look nicer that
way.
Otherwise:
Reviewed-by: Lyude Paul
Will look at the other patc
For nouveau:
Reviewed-by: Lyude Paul
On Thu, 2022-09-22 at 16:25 +0200, Maxime Ripard wrote:
> drm_mode_create_tv_properties(), among other things, will create the
> "mode" property that stores the analog TV mode that connector is
> supposed to output.
>
> However,
nouveau changes:
Reviewed-by: Lyude Paul
On Thu, 2022-09-22 at 16:25 +0200, Maxime Ripard wrote:
> The current tv_mode has driver-specific values that don't allow to
> easily share code using it, either at the userspace or kernel level.
>
> Since we're going to in
For the nouveau bits on 1, 2 and 4:
Reviewed-by: Lyude Paul
On Fri, 2022-09-09 at 12:59 +0200, Thomas Zimmermann wrote:
> This patchset does cleanups to the plane code, most noteably it removes
> drm_plane_init(). The function is a small wrapper, which can easily be
> inlined int
Reviewed-by: Lyude Paul
for common and nouveau bits
On Fri, 2022-09-09 at 12:59 +0200, Thomas Zimmermann wrote:
> Open-code drm_plane_init() and remove the function from DRM. The
> implementation of drm_plane_init() is a simple wrapper around a call
> to drm_universal_plane_init(), s
.
Seems like we've got a pretty good argument for renaming this from backlight
to something else at some point. FWIW, the word backlight is sometimes used
around these parts simply to describe controlling the brightness of an OLED
screen.
>
> Aurélien
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Surprised this didn't come up on Intel's CI (or at least it certainly didn't
when the series that introduced this was tested), thanks for the catch!
Reviewed-by: Lyude Paul
On Wed, 2022-09-07 at 17:25 +0300, Imre Deak wrote:
> When an MST connector stays enabled during a comm
Reviewed-by: Lyude Paul
On Wed, 2022-08-31 at 18:13 -0400, Fangzhi Zuo wrote:
> The attempt to read DPCD_REV before any native aux read breaks
> majority of DP2 compliance.
>
> The spec. requires DP_SINK_STATUS to be polled for the reset status
> DP_INTRA_HOP_AUX_REPLY_INDICA
Reviewed-by: Lyude Paul
Also, went ahead and tested this for you on one of my machines:
Tested-by: Lyude Paul
On Thu, 2022-09-01 at 15:47 +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi and has_audio in display info over
> calling drm_detect_hdmi_monitor
Thanks for this! We definitely need more logging like this in DRM. for patches
1 and 2:
Reviewed-by: Lyude Paul
On Mon, 2022-08-29 at 15:14 +, Simon Ser wrote:
> Sometimes drivers are missing logs when they return EINVAL.
> Printing the failure here in common code can help understand
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> Add an entry summarizing the discussion about dealing with brightness
> control on devices with more then 1 internal panel.
>
> The original discussion can be found here:
> https://lore.kerne
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> Typically the acpi_video driver will initialize before nouveau, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> nouveau would register its own nv_backlight device lat
or digits + 1 for '\0'
> @@ -405,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
> goto fail_alloc;
> }
>
> + if (!nouveau_acpi_video_backlight_use_native()) {
> + NV_INFO(drm, "Skipping nv_backlight registration\n");
>
Actually, talked with airlied and they suggested at this point I should just
go ahead and push. So, pushed! Have fun getting nice DSC support everyone :)
On Tue, 2022-08-23 at 13:26 -0400, Lyude Paul wrote:
> Would anyone have any issues if I merged this today? The whole series is
> acke
Would anyone have any issues if I merged this today? The whole series is
acked, but I'm not sure if we would like to wait for R-b's?
On Wed, 2022-08-17 at 15:38 -0400, Lyude Paul wrote:
> For quite a while we've been carrying around a lot of legacy modesetting
> code in the
Reviewed-by: Lyude Paul
Thanks! I will push this upstream in a moment
On Mon, 2022-08-15 at 13:40 +0300, Beniamin Sandu wrote:
> This makes the code look cleaner and easier to read.
>
> Signed-off-by: Beniamin Sandu
> ---
> drivers/gpu/drm/nouveau/nouve
Reviewed-by: Lyude Paul
On Fri, 2022-08-19 at 22:09 +0200, Karol Herbst wrote:
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
>
> Cc: sta...@vger.kernel.org # v5.15+
> Closes: https://gi
ier is better since there generally will be a
bit of Q&A with organizers.
And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
Best regards,
Lyude Paul
On behalf of X.org
--
Cheers,
L
got
myself confused by DC and we don't actually need this.
Changes since v2:
* Get rid of fix for not sending payload deallocations if ddps=0 and just
go back to wayne's fix
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Dea
n just drop this code and forget
about it. I've already run this idea by Harry Wentland and Alex Deucher a
few times as well.
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: Alex Deucher
Acked
vers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.
So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
->delete, which we set whenever we're planning on deleting a payload
during the current atomic commit.
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
---
drivers/gpu/dr
e only queue
link address probing work at the end of handling all CSNs - allowing us to
make sure we drop as many topology references as we can beforehand.
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 Pa
e simple helpers
for doing that and hook them up in various drivers.
v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
CI failures
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:
o avoid looking it
up each time. This isn't safe for NV50 since PIORs then come into play,
however there's no code pre-NV50 that would need to look this up anyhow -
so it's not really an issue.
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/nouveau_c
ive change
being rejected by the atomic check.
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
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 ---
1 file changed,
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 N
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 ch
s we release or allocate timeslots
on. As well, add some helpers for:
* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state
v2:
* Use drm_dp_mst_atomic_setup_commit() directly - Jani
Signed-off-by: Lyude Paul
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
d
allocations.
So, let's get rid of that comment.
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
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +--
1 file changed,
the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
the source DP Tx and the immediate downstream DP Rx
Signed-off-by: Lyude Paul
Cc: Wayn
ming it to
drm_dp_mst_atomic_payload. Also, rename various variables throughout the
code that use atomic payloads.
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
---
drivers/gpu/d
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
hrew me into a
loop a few times.
So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 7 ---
x that Wayne pointed out isn't needed
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Lyude Paul (17):
drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)
drm/amdgpu/dm/mst: Rename get_payload_table()
drm/display/dp_m
Adding Mark Pearson from Lenovo to this, Mark for reference the original patch
is here:
https://patchwork.freedesktop.org/patch/497807/?series=107312&rev=1
Comments from me down below
On Wed, 2022-08-17 at 09:02 +0800, Kai-Heng Feng wrote:
> On Wed, Aug 17, 2022 at 2:24 AM Lyude Paul
On Tue, 2022-08-16 at 14:24 -0400, Lyude Paul wrote:
> On Tue, 2022-08-16 at 19:29 +0800, Kai-Heng Feng wrote:
> > On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula
> > wrote:
> > >
> > > On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > > > On mobile worksta
> > NULL);
> > > - if (obj)
> > > + if (obj) {
> > > + if (obj->type == ACPI_TYPE_INTEGER)
> > > + supported = obj->integer.value;
> > > +
> > > ACPI_FREE(obj);
> > > + }
> > > +
> > > + /*
[INVALID_ARG] mthd
2008 data 0001 code 0008
nouveau :1f:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] mthd
0200 data 0001 code 0001
So let's fix this by following the same behavior Nvidia's driver does and
disable interlacing entirely.
Signed-off-by: Lyud
On Thu, 2022-08-11 at 10:33 +0300, Lisovskiy, Stanislav wrote:
> On Wed, Aug 10, 2022 at 04:02:08PM -0400, Lyude Paul wrote:
> > Btw, what's the plan for this? Figured I'd ask since I noticed this on the
> > ML,
> > nd I'm now finishing up getting t
e the delay with updating the in-memory topology structure
might put us slightly out of sync with the state of the hub on the other end -
causing the hub to spit out an error.
However - based on the excerpts you mentioned I think what I was seeing was
mainly just the 2 second timeout causing thi
On Wed, 2022-08-10 at 09:23 -0400, Hamza Mahfooz wrote:
> On 2022-08-09 18:01, Lyude Paul wrote:
> > Ah yes of course! Probably should have asked when I gave the r-b :). Also,
> > just so patchwork actually catches it I will say the magic incantation:
> >
> > Reviewed-
ivers/gpu/drm/i915/display/intel_dp_mst.c | 145
> include/drm/display/drm_dp.h| 10 +-
> 4 files changed, 203 insertions(+), 45 deletions(-)
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
e simple helpers
for doing that and hook them up in various drivers.
v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
CI failures
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:
Ah yes of course! Probably should have asked when I gave the r-b :). Also,
just so patchwork actually catches it I will say the magic incantation:
Reviewed-by: Lyude Paul
Do we want to merge just this patch to drm-misc-next, or do you want to merge
the whole series through there? If you&#
r.lock - Wayne Lin
* Remove mentions of allowing multiple ACT updates per payload change,
mention that this is a result of vendors not consistently supporting this
part of the spec and requiring a unique ACT for each payload change.
* Get rid of reference to drm_dp_mst_port in DC - turns out I just
->delete, which we set whenever we're planning on deleting a payload
during the current atomic commit.
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
---
drivers/gpu/dr
n just drop this code and forget
about it. I've already run this idea by Harry Wentland and Alex Deucher a
few times as well.
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: Alex Deucher
Acked
e simple helpers
for doing that and hook them up in various drivers.
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
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
dri
e only queue
link address probing work at the end of handling all CSNs - allowing us to
make sure we drop as many topology references as we can beforehand.
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 Pa
omatically if that port is also marked as disconnected.
However, if there's another parent in the chain after that which is
connected - payloads must be released there with an ALLOCATE_PAYLOAD
message.
So, let's do that!
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc:
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 ch
o avoid looking it
up each time. This isn't safe for NV50 since PIORs then come into play,
however there's no code pre-NV50 that would need to look this up anyhow -
so it's not really an issue.
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/nouveau_c
ive change
being rejected by the atomic check.
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
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 ---
1 file changed,
vers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.
So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
s we release or allocate timeslots
on. As well, add some helpers for:
* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state
v2:
* Use drm_dp_mst_atomic_setup_commit() directly - Jani
Signed-off-by: Lyude Paul
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
d
allocations.
So, let's get rid of that comment.
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
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +--
1 file changed,
the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
the source DP Tx and the immediate downstream DP Rx
Signed-off-by: Lyude Paul
Cc: Wayn
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 N
ming it to
drm_dp_mst_atomic_payload. Also, rename various variables throughout the
code that use atomic payloads.
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
---
drivers/gpu/d
hrew me into a
loop a few times.
So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 7 ---
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
Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Lyude Paul (18):
drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)
drm/amdgpu/dm/mst: Rename get_payload_table()
drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation
drm/display/dp_mst: Ca
e" which is a bit conflicting with
> the idea in the reply of ENUM_PATH_RESOURCES - full PBN & available PBN.
> Maybe better to change to use "full_slots"?
>
> Not yet finish all the patches. Will try to go through all the patches
> recently : )
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
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-devel@lists.freedesktop.org;
> > nouv...@lists.freedesktop
lgtm!
Reviewed-by: Lyude Paul
On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
> Currently, there is no way to identify if DSC pass-through can be
> enabled and what aux DSC pass-through requests ought to be sent to. So,
> add a variable to struct drm_dp_mst_port that keeps tra
e
contents of this member in DC on non-Linux platforms. If void* is preferred
though I'm fine with switching it to that.
--
Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
On Tue, 2022-07-05 at 08:45 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-----
> > From: Lyude Paul
> > Sent: Wednesday, June 8, 2022 3:30 AM
> > To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> > g..
d like to change the structure name to "struct drm_dp_mst_vcp {}" to
> represent
> the virtual channel payload. Not specific to the ID.
> Would like to know your thoughts : )
JFYI - I didn't rename this structure because we actually remove it entirely
in later patches
>
Yikes! Surprised this wasn't noticed until now. This lgtm:
Reviewed-by: Lyude Paul
On Mon, 2022-08-01 at 13:38 +, Simon Ser wrote:
> When registering a connector, the kernel sends a hotplug uevent in
> drm_connector_register(). When unregistering a connector, drivers
> are ex
ed at this point though,
so I should have a chance to respin this in the next few business days.
On Tue, 2022-06-07 at 15:29 -0400, Lyude Paul wrote:
> Ugh, thanks ./scripts/get_maintainers.pl for confusing and breaking
> git-send email <<. Sorry for the resend everyone.
>
>
le of
coherent allocations using is_swiotlb_active().
So, let's do this by replacing is_swiotlb_active() with our own
nouveau_drm_use_coherent_gpu_mapping() helper.
Signed-off-by: Lyude Paul
Cc: Christoph Hellwig
---
Hey! This is the patch that I came up with, but as the folks involved
with this
e need all
noncoherent allocations without getting is_swiotlb_active() involved - which
should be easy. Does this seem like a workable solution, or is there something
I'm missing here?
On Thu, 2022-07-28 at 17:17 -0400, Lyude Paul wrote:
> Hi! Sorry about the slow reply to this, been busy wit
nd/or that function
> should switch to use dma_alloc_noncoherent.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
s.
Anyway, this patch looks good to me:
Reviewed-by: Lyude Paul
I will push it to the appropriate branch in a little bit
On Wed, 2022-07-20 at 16:27 +1000, Alistair Popple wrote:
> Users may request that pages from an OpenCL SVM allocation be migrated
> to the GPU with clEnqueueSVMMigrateM
201 - 300 of 1458 matches
Mail list logo
