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
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 ---
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
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
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
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,
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
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
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
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,
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
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
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:
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.
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
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
->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
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
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&#
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:
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
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-
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 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
[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
> > NULL);
> > > - if (obj)
> > > + if (obj) {
> > > + if (obj->type == ACPI_TYPE_INTEGER)
> > > + supported = obj->integer.value;
> > > +
> > > ACPI_FREE(obj);
> > > + }
> > > +
> > > + /*
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
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
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
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
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
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
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,
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
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
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
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
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,
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
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:
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
->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
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
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
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
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
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
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
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
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
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");
>
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
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
Whoops! Was going through my unread emails and noticed I somehow missed this
patch last month.
Reviewed-by: Lyude Paul
I will push this to drm-misc-fixes in a little bit (assuming I don't find it
there already)
On Tue, 2022-04-05 at 15:21 +0100, Robin Murphy wrote:
> Even if some I
Sorry I totally missed this patch up until now, noticed it while going through
unread emails today. This is:
Reviewed-by: Lyude Paul
FWIW, if there's something you need reviews on that hasn't gotten looked at
after a few weeks feel free to poke the nouveau list/me.
Anyway, I will go
ferent file like "nouveau_fbcon.c" seem like too big changes for
> such small fix. I don't know.
>
> Can this new proposed order break something in the finish part as well?
> Maybe it would be just better to change the order of "nouveau_drm_finish
ooking
at the code - and I think someone just generally forgot to write docs for
drm_kms_helper_poll_fini()…
On Mon, 2022-05-09 at 13:59 -0400, Lyude Paul wrote:
> On Mon, 2022-05-09 at 15:13 +0200, Mark Menzynski wrote:
> > I think there are no direct issues with initialization in the
owever, so let's add it!
Keep in mind that this currently just lets one enable or disable amdgpu, I
haven't bothered adding a headless mode like nouveau has - however I'm sure
someone else can add this if needed.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a bit
On Mon, 2022-05-16 at 11:20 +0800, Hangyu Hua wrote:
> drm_dp_mst_get_edid call kmemdup to create mst_edid. So mst_edid need to be
> freed after use.
>
> Signed-off-by: Hangyu Hua
> ---
>
24.860008] ? pci_dev_put+0x20/0x20
> [ 24.860011] __rpm_callback+0x48/0x1b0
> [ 24.860014] ? pci_dev_put+0x20/0x20
> [ 24.860018] rpm_callback+0x5a/0x70
> [ 24.860020] ? pci_dev_put+0x20/0x20
> [ 24.860023] rpm_suspend+0x10a/0x6f0
> [ 24.860025] ? process_one_work+0
So I think you forgot to update the subject of the patch. If you can send a
respin of this patch with a corrected patch title, then you can consider this:
Reviewed-by: Lyude Paul
I'll push once you get the respin out
On Mon, 2022-05-16 at 15:31 +0200, Mark Menzynski wrote:
> Resource
So I think you forgot to update the subject of the patch. If you can send a
respin of this patch with a corrected patch title, then you can consider this:
Reviewed-by: Lyude Paul
I'll push once you get the respin out
On Mon, 2022-05-16 at 15:31 +0200, Mark Menzynski wrote:
> Resource
Reviewed-by: Lyude Paul
Also, ack on this being pushed to drm-misc, along with any other patches I r-b
On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backl
ave an internal panel, but no nv_backlight,
> + * try registering an ACPI video backlight device instead.
> + */
> + if (ret == 0)
> + acpi_video_register_backlight();
Assuming we don't need to return the value of acpi_video_register_backlight()
here:
Reviewed-by: Lyude Paul
> +
> return ret;
> }
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
24.860025] ? process_one_work+0x1d0/0x560
> [ 24.860031] pm_runtime_work+0xa0/0xb0
> [ 24.860034] process_one_work+0x254/0x560
> [ 24.860039] worker_thread+0x4f/0x390
> [ 24.860043] ? process_one_work+0x560/0x560
> [ 24.860046] kthread+0xe6/0x110
> [ 24.860049] ? kthread_complete_and_exit+0x20/0x20
> [ 24.860053] ret_from_fork+0x22/0x30
> [ 24.860059]
>
> Regards,
>
> Hans
>
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a bit, thanks!
On Mon, 2022-05-23 at 13:35 +0200, Mark Menzynski wrote:
> Resources needed for output poll workers are destroyed in
> nouveau_fbcon_fini() before output poll workers are cleared in
> nouveau_display_fin
Reviewed-by: Lyude Paul
Will fix that double space after the punctuation while I'm at it as well, and
will push to the appropriate branch in a little bit. Thanks!
On Sat, 2022-05-21 at 13:11 +0200, Julia Lawall wrote:
> Spelling mistake (triple letters) in comment.
> Detected with
On Fri, 2022-05-20 at 13:46 +0200, Computer Enthusiastic wrote:
> Hello,
>
> Il giorno mer 18 mag 2022 alle ore 19:42 Lyude Paul
> ha scritto:
> >
> > On Tue, 2022-05-17 at 13:10 +0200, Hans de Goede wrote:
> > > Hi All,
> > > I just noticed the bel
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a moment
On Thu, 2022-05-19 at 15:29 +0800, Guo Zhengkui wrote:
> There has already been NULL check in clk_prepare_enable() and
> clk_disable_unprepare(), so remove needless NULL check before
> calling them.
>
> Sig
So, let's fix that and also add a missing check to ensure that we've
properly allocated nv_connector->aux.name while we're at it.
Signed-off-by: Lyude Paul
Fixes: fd43ad9d47e7 ("drm/nouveau/kms/nv50-: Move AUX adapter reg to connector
late register/early unregister&quo
Since this isn't actually a failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 2cd0932
be
blocked.
So, let's only use pm_runtime_put_autosuspend().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_displ
Reviewed-by: Lyude Paul
Do you need me to push this to drm-misc? Or will this be pushed as one series?
On Fri, 2022-05-27 at 12:22 +0800, 1064094...@qq.com wrote:
> From: pengfuyuan
>
> Fix spelling typo in comments.
>
> Reported-by: k2ci
> Signed-off-by: pengfuyuan
&g
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a moment
On Sat, 2022-05-28 at 10:18 -0400, Tom Rix wrote:
> sparse reports
> drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c:56:1: warning: symbol
> 'gv100_fifo_runlist' was not declared.
d me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
https://twitter.com/XOrgDevConf
Best regards,
Lyude Paul, on behalf of X.org
--
Cheers,
L
Reviewed-by: Lyude Paul
Going to change the name of the patch slightly so it's more obvious this is
just about the MST selftests
On Thu, 2022-06-23 at 18:06 +0800, Jiang Jian wrote:
> there is an unexpected word 'for' in the comments that need to be dropped
>
>
do end up forgetting.
On Tue, 2022-06-28 at 17:32 -0400, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
>
> Going to change the name of the patch slightly so it's more obvious this is
> just about the MST selftests
>
> On Thu, 2022-06-23 at 18:06 +0800, Jiang Jian wrote:
> > t
Oh-it's back up now! will push now :)
On Tue, 2022-06-28 at 17:35 -0400, Lyude Paul wrote:
> …ah, I totally forgot that gitlab happens to be down right now which part of
> the DRM maintainer scripts rely on - so I can't actually push this patch
> upstream right away. I wil
Nice catch!
Reviewed-by: Lyude Paul
Will push to drm-intel-next
On Fri, 2022-06-24 at 10:28 +0800, Hangyu Hua wrote:
> If drm_connector_init fails, intel_connector_free will be called to take
> care of proper free. So it is necessary to drop the refcount of port
> before intel_conne
Ah-nevermind! Seems like someone already pushed this for you :)
On Tue, 2022-06-28 at 18:55 -0400, Lyude Paul wrote:
> Nice catch!
>
> Reviewed-by: Lyude Paul
>
> Will push to drm-intel-next
>
> On Fri, 2022-06-24 at 10:28 +0800, Hangyu Hua wrote:
> >
Reviewed-by: Lyude Paul
Currently on flakey internet in the back of a car, so I probably won't be able
to push this until I get back tonight or early tomorrow
On Sat, 2022-07-02 at 11:39 -0400, Tom Rix wrote:
> clang static analysis reports
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a moment
On Tue, 2022-07-05 at 21:25 +0800, Jianglei Nie wrote:
> nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
> back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and
>
This should probably be prefixed with the title "drm/nouveau/clk:", but I can
fix that before pushing it.
Reviewed-by: Lyude Paul
Will push it to the appropriate repository shortly
On Sun, 2022-03-27 at 15:58 +0800, Xiaomeng Tong wrote:
> The bug is here:
> if (nvkm_
Reviewed-by: Lyude Paul
Will push this to the appropriate branch in a little bit
On Mon, 2022-04-18 at 10:18 -0400, Tom Rix wrote:
> Smatch reports this issue
> base917c.c:26:1: warning: symbol 'base917c_format'
> was not declared. Should it be static?
>
> base91
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a moment
On Mon, 2022-04-18 at 11:28 -0400, Tom Rix wrote:
> Smatch reports this issue
> gf108.c:147:1: warning: symbol 'gf108_gr_fwif'
> was not declared. Should it be static?
>
> gf108_gr_fwif is only
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
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
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
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
.
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
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
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
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 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,
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
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
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
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
801 - 900 of 2396 matches
Mail list logo
