Reviewed-by: Lyude Paul
On Fri, 2024-05-10 at 18:08 +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi and has_audio in display info
> over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Conveniently, this also remov
Reviewed-by: Lyude Paul
On Fri, 2024-05-10 at 18:08 +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi and has_audio in display info
> over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Conveniently, this also remov
Reviewed-by: Lyude Paul
On Fri, 2024-05-10 at 18:08 +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi and has_audio in display info
> over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Conveniently, this also remov
Reviewed-by: Lyude Paul
On Fri, 2024-05-10 at 18:08 +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi and has_audio in display info
> over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Conveniently, this also remov
needed is to send an email to the board, and we can handle
setting up scheduling :).
And of course as always, the Code of Conduct team is always looking for
new volunteers.
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
needed is to send an email to the board, and we can handle
setting up scheduling :).
And of course as always, the Code of Conduct team is always looking for
new volunteers.
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
On Thu, 2024-04-25 at 15:46 +, Benno Lossin wrote:
> On 22.04.24 03:54, Lyude Paul wrote:
> > On Wed, 2024-03-27 at 21:06 +, Benno Lossin wrote:
> > > On 22.03.24 23:03, Lyude Paul wrote:
> > > > +
> > > > +pub(crate) type Connector =
> > &
of the scatterlist we're currently on when writing out the page table
for level 2
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 4 +-
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 77 ---
2 files changed, 54
of the scatterlist we're currently on when writing out the page table
for level 2
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 4 +-
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 77 ---
2 files changed, 54
y allocating the memory with vmalloc instead().
V2:
* Fixup explanation as the prior one was bogus
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/f
y allocating the memory with vmalloc instead().
V2:
* Fixup explanation as the prior one was bogus
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/f
ix3 page table for
> > suspend/resume data. So, let's rewrite nvkm_gsp_radix3_sg() to use
> > the sg
> > allocator for level 2. We continue using coherent allocations for
> > lvl0 and
> > 1, since they only take a single page.
> >
> > Signed-off-by: Lyu
ix3 page table for
> > suspend/resume data. So, let's rewrite nvkm_gsp_radix3_sg() to use
> > the sg
> > allocator for level 2. We continue using coherent allocations for
> > lvl0 and
> > 1, since they only take a single page.
> >
> > Signed-off-by: Lyu
On Fri, 2024-04-26 at 15:47 +, Timur Tabi wrote:
> On Fri, 2024-04-26 at 11:41 -0400, Lyude Paul wrote:
> > We hit this because when initializing firmware of type
> > NVKM_FIRMWARE_IMG_DMA we allocate coherent memory and then attempt
> > to
> > include that coher
On Fri, 2024-04-26 at 15:47 +, Timur Tabi wrote:
> On Fri, 2024-04-26 at 11:41 -0400, Lyude Paul wrote:
> > We hit this because when initializing firmware of type
> > NVKM_FIRMWARE_IMG_DMA we allocate coherent memory and then attempt
> > to
> > include that coher
the GPU a radix3 page table for
suspend/resume data. So, let's rewrite nvkm_gsp_radix3_sg() to use the sg
allocator for level 2. We continue using coherent allocations for lvl0 and
1, since they only take a single page.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
.../gpu/drm/nouveau
the GPU a radix3 page table for
suspend/resume data. So, let's rewrite nvkm_gsp_radix3_sg() to use the sg
allocator for level 2. We continue using coherent allocations for lvl0 and
1, since they only take a single page.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
.../gpu/drm/nouveau
since that's the
only thing that would make sense to put in the scatterlist.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
b/drivers/gpu/drm/
since that's the
only thing that would make sense to put in the scatterlist.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
b/drivers/gpu/drm/
05 t440 kernel: [ 6.366655] input: SynPS/2 Synaptics
> TouchPad as /devices/platform/i8042/serio1/input/input2
>
> This without even rebooting or suspending the laptop.
>
> I have some scripts that disable or enable the touchpad (especially
> when
> I use the mouse) and I
For the nouveau bits:
Reviewed-by: Lyude Paul
On Mon, 2024-04-22 at 15:10 +0300, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
>
For the nouveau bits:
Reviewed-by: Lyude Paul
On Mon, 2024-04-22 at 15:10 +0300, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
>
For the nouveau bits:
Reviewed-by: Lyude Paul
On Mon, 2024-04-22 at 15:10 +0300, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
>
For the nouveau bits:
Reviewed-by: Lyude Paul
On Mon, 2024-04-22 at 15:10 +0300, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
>
For the nouveau bits:
Reviewed-by: Lyude Paul
On Mon, 2024-04-22 at 15:10 +0300, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
>
On Wed, 2024-03-27 at 21:06 +, Benno Lossin wrote:
> On 22.03.24 23:03, Lyude Paul wrote:
> > diff --git a/drivers/gpu/drm/rvkms/connector.rs
> > b/drivers/gpu/drm/rvkms/connector.rs
> > new file mode 100644
> > index 0..40f84d38437ee
> > --- /d
arly on - so I had wanted to post a WIP before I
actually wrote up everything to make sure I'm going in the right
direction (I'm certainly not planning on leaving things undocumented
when this is actually ready for submission :).
>
> On 22.03.24 23:03, Lyude Paul wrote:
>
So - first some context here for Ben and anyone else who hasn't been
following. A little while ago I got a Slimbook Executive 16 with a
Nvidia RTX 4060 in it, and I've unfortunately been running into a kind
of annoying issue. Currently this laptop only has 16 gigs of ram, and
as it turns out -
_backlight_init(bl,
> nouveau_connector(connector),
> nv_encoder, , );
> break;
> + case NV_DEVICE_INFO_V0_ADA:
> + ret = nv19x_backlight_init(bl,
> nouveau_connector(connector),
> + nv_encoder, ,
> );
> + break;
> default:
> ret = 0;
> goto fail_alloc;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
_backlight_init(bl,
> nouveau_connector(connector),
> nv_encoder, , );
> break;
> + case NV_DEVICE_INFO_V0_ADA:
> + ret = nv19x_backlight_init(bl,
> nouveau_connector(connector),
> + nv_encoder, ,
> );
> + break;
> default:
> ret = 0;
> goto fail_alloc;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Reviewed-by: Lyude Paul
On Mon, 2024-04-08 at 22:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the open coded drm_crtc_vblank_crtc() with the real
> thing.
>
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: Danilo Krummrich
> Cc: nouv...@lists.f
Reviewed-by: Lyude Paul
On Mon, 2024-04-08 at 22:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the open coded drm_crtc_vblank_crtc() with the real
> thing.
>
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: Danilo Krummrich
> Cc: nouveau@lists.f
Reviewed-by: Lyude Paul
On Mon, 2024-04-08 at 22:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the open coded drm_crtc_vblank_crtc() with the real
> thing.
>
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: Danilo Krummrich
> Cc: nouv...@lists.f
int dacclk_off = NV_PRAMDAC_DACCLK +
> > nv04_dac_output_offset(encoder);
> > uint32_t dacclk = NVReadRAMDAC(dev, 0,
> > dacclk_off);
> > @@ -453,7 +453,7 @@ bool nv04_dac_in_use(struct drm_encoder
> > *encoder)
> > struct drm_device *dev = enco
int dacclk_off = NV_PRAMDAC_DACCLK +
> > nv04_dac_output_offset(encoder);
> > uint32_t dacclk = NVReadRAMDAC(dev, 0,
> > dacclk_off);
> > @@ -453,7 +453,7 @@ bool nv04_dac_in_use(struct drm_encoder
> > *encoder)
> > struct drm_device *dev = enco
I'm in support of this as well! As long as we make sure it gets
renamed everywhere :)
>
> Thanks,
> Easwar
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
I'm in support of this as well! As long as we make sure it gets
renamed everywhere :)
>
> Thanks,
> Easwar
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
I'm in support of this as well! As long as we make sure it gets
renamed everywhere :)
>
> Thanks,
> Easwar
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
I'm in support of this as well! As long as we make sure it gets
renamed everywhere :)
>
> Thanks,
> Easwar
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
to ACPI hotplug probe events.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8b1be7dd64ebe..8b27d372e86da 100644
to ACPI hotplug probe events.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8b1be7dd64ebe..8b27d372e86da 100644
is actually on the connector. Otherwise, we just shut it
off.
This should fix some people's runtime PM issues (like myself), and also get
rid of quite of a lot of GSP error spam in dmesg.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 10 ++
1 file changed, 10 insertions
is actually on the connector. Otherwise, we just shut it
off.
This should fix some people's runtime PM issues (like myself), and also get
rid of quite of a lot of GSP error spam in dmesg.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 10 ++
1 file changed, 10 insertions
Slimbook Executive 16!
Lyude Paul (2):
drm/nouveau/kms/nv50-: Disable AUX bus for disconnected DP ports
drm/nouveau/dp: Don't probe eDP ports twice harder
drivers/gpu/drm/nouveau/nouveau_dp.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
--
2.44.0
Slimbook Executive 16!
Lyude Paul (2):
drm/nouveau/kms/nv50-: Disable AUX bus for disconnected DP ports
drm/nouveau/dp: Don't probe eDP ports twice harder
drivers/gpu/drm/nouveau/nouveau_dp.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
--
2.44.0
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/rvkms/plane.rs | 7 +++-
rust/bindings/bindings_helper.h | 2 +
rust/kernel/drm/kms.rs | 1 +
rust/kernel/drm/kms/gem_atomic_helper.rs | 48
4 files changed, 56 insertions(+), 2
will implement. This is basically the same idea as the
GEM ops - but for plane states.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/rvkms/plane.rs | 2 +-
rust/kernel/drm/kms/plane.rs | 165 -
2 files changed, 103 insertions(+), 64 deletions(-)
diff --git
into rvkms introduction
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/rvkms/Kconfig | 3 +
drivers/gpu/drm/rvkms/Makefile | 1 +
drivers/gpu/drm/rvkms/connector.rs | 55 +++
drivers/gpu/drm
Signed-off-by: Lyude Paul
---
rust/bindings/bindings_helper.h | 4 +
rust/helpers.c | 17 ++
rust/kernel/drm/device.rs| 2 +
rust/kernel/drm/drv.rs | 115 +++--
rust/kernel/drm/kms.rs | 146 +++
rust/kernel/drm/kms/connector.rs
acks to expose
these.
* I'm sure there's bits of code that need cleaning up, but I figured it
was more important to start getting feedback on all of this first :).
Lyude Paul (4):
WIP: rust: Add basic KMS bindings
WIP: drm: Introduce rvkms
rust/drm/kms: Extract PlaneState into IntoPlan
that.
Fixes: 4ae3a20102b2 ("nouveau/gsp: don't free ctrl messages on errors")
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
b/drivers/gpu/d
that.
Fixes: 4ae3a20102b2 ("nouveau/gsp: don't free ctrl messages on errors")
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
b/drivers/gpu/d
Reviewed-by: Lyude Paul
On Mon, 2024-03-04 at 19:31 +0100, Karol Herbst wrote:
> Those are already de-facto UAPI, so let's just move it into the uapi
> header.
>
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 20 +++-
> dr
Reviewed-by: Lyude Paul
On Mon, 2024-03-04 at 19:31 +0100, Karol Herbst wrote:
> Those are already de-facto UAPI, so let's just move it into the uapi
> header.
>
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 20 +++-
> dr
Reviewed-by: Lyude Paul
On Mon, 2024-03-04 at 19:31 +0100, Karol Herbst wrote:
> If VM_BIND is enabled on the client the legacy submission ioctl can't be
> used, however if a client tries to do so regardless it will return an
> error. In this case the clients mutex remained unlocke
Reviewed-by: Lyude Paul
On Mon, 2024-03-04 at 19:31 +0100, Karol Herbst wrote:
> If VM_BIND is enabled on the client the legacy submission ioctl can't be
> used, however if a client tries to do so regardless it will return an
> error. In this case the clients mutex remained unlocke
orking on writing up KMS bindings.
If anyone has any questions or comments feel free to reply :)!
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
orking on writing up KMS bindings.
If anyone has any questions or comments feel free to reply :)!
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
ted through nvif. This
-should- hopefully fix the WARN_ON on GT218 reported by Borislav.
Signed-off-by: Lyude Paul
Cc: Borislav Petkov
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/d
ted through nvif. This
-should- hopefully fix the WARN_ON on GT218 reported by Borislav.
Signed-off-by: Lyude Paul
Cc: Borislav Petkov
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/d
Nevermind - I don't think I'll need the logs, I stared at the code for long
enough and I think I realized what's happening.
I will have a patch for you to test in just a moment, just waiting for it to
compile so I can verify nothing else breaks
On Wed, 2023-12-13 at 18:48 -0500, Lyude Paul wrote
Nevermind - I don't think I'll need the logs, I stared at the code for long
enough and I think I realized what's happening.
I will have a patch for you to test in just a moment, just waiting for it to
compile so I can verify nothing else breaks
On Wed, 2023-12-13 at 18:48 -0500, Lyude Paul wrote
for the time being, but I'd really love
to know how we're managing to get that far on a hardware generation we never
implemented that nvkm ioctl for…
On Wed, 2023-12-13 at 18:37 -0500, Lyude Paul wrote:
> agh - thank you for repeatedly poking on this, I've been busy enough with GSP
> work I totally
for the time being, but I'd really love
to know how we're managing to get that far on a hardware generation we never
implemented that nvkm ioctl for…
On Wed, 2023-12-13 at 18:37 -0500, Lyude Paul wrote:
> agh - thank you for repeatedly poking on this, I've been busy enough with GSP
> work I totally
this or shut
> > up the WARN.
>
> Not only that - panic_on_warn turns this into an explosion so you don't
> want that in a released kernel.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
this or shut
> > up the WARN.
>
> Not only that - panic_on_warn turns this into an explosion so you don't
> want that in a released kernel.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Reviewed-by: Lyude Paul
Will push upstream in a moment
On Wed, 2023-11-22 at 08:49 +0800, Yang Li wrote:
> ./drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c: chid.h is included more
> than once.
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_
Reviewed-by: Lyude Paul
Will push upstream in a moment
On Wed, 2023-11-22 at 08:49 +0800, Yang Li wrote:
> ./drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c: chid.h is included more
> than once.
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_
For patches 1-3:
Reviewed-by: Lyude Paul
On Thu, 2023-11-16 at 15:18 +0200, Imre Deak wrote:
> This is v2 of [1], with the following changes:
> - Store the pbn_div value in fixed point format.
> - Fix PBN calculation in patch 8.
> - Reuse intel_dp_max_data_rate(), intel_dp_effecti
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> From: Ville Syrjälä
>
> The current code does '(bpp << 4) / 16' in the MST PBN
> calculation, but that is just the same as 'bpp' so the
> DSC codepath achieves absolutely nothing. Fix it up so
Reviewed-by: Lyude Paul
On Tue, 2023-11-07 at 02:14 +0200, Imre Deak wrote:
> Add helpers drivers can use to calculate the BW allocation overhead -
> due to SSC, FEC, DSC and data alignment on symbol cycles - and the
> channel coding efficiency - due to the 8b/10b, 128b/132b encoding.
Reviewed-by: Lyude Paul
On Tue, 2023-11-07 at 02:14 +0200, Imre Deak wrote:
> Add helpers drivers can use to calculate the BW allocation overhead -
> due to SSC, FEC, DSC and data alignment on symbol cycles - and the
> channel coding efficiency - due to the 8b/10b, 128b/132b encoding.
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> Add helpers drivers can use to calculate the BW allocation overhead -
> due to SSC, FEC, DSC and data alignment on symbol cycles - and the
> channel coding efficiency - due to the 8b/10b, 128b/132b encoding.
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> Add helpers drivers can use to calculate the BW allocation overhead -
> due to SSC, FEC, DSC and data alignment on symbol cycles - and the
> channel coding efficiency - due to the 8b/10b, 128b/132b encoding.
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> Add a quirk for Synaptics MST hubs, which require a workaround - at leat
> on i915 - for some modes, on which the hub applies HBLANK expansion.
> These modes will only work by enabling DSC decompression
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> Add a quirk for Synaptics MST hubs, which require a workaround - at leat
> on i915 - for some modes, on which the hub applies HBLANK expansion.
> These modes will only work by enabling DSC decompression
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> Add the DPCD flag to enable DSC passthrough in a last branch device,
> used in a follow-up i915 patch.
>
> Also add a flag to detect HBLANK expansion support in a branch device,
> used by a workaround
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> Add the DPCD flag to enable DSC passthrough in a last branch device,
> used in a follow-up i915 patch.
>
> Also add a flag to detect HBLANK expansion support in a branch device,
> used by a workaround
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> The Synaptics MST branch devices support DSC decompression on all their
> output ports, provided that they are last branch devices (with their
> output ports connected to the sinks). The Thinkpad 40B0
Reviewed-by: Lyude Paul
On Mon, 2023-10-30 at 17:58 +0200, Imre Deak wrote:
> The Synaptics MST branch devices support DSC decompression on all their
> output ports, provided that they are last branch devices (with their
> output ports connected to the sinks). The Thinkpad 40B0
_modeset_crtc() (Ville, patch 26).
> - Fix forcing modeset on CRTC due to a change in MST topology
> (Ville, patch 27).
> - Add missing DocBooks, fix typos.
>
> [1] https://lore.kernel.org/all/20231024010925.3949910-1-imre.d...@intel.com
>
> Cc: Stanislav Lisovskiy
> Cc:
Reviewed-by: Lyude Paul
On Wed, 2023-10-11 at 13:41 +0200, Karol Herbst wrote:
> Just special case DP DSM connectors until we properly figure out how to
> deal with this.
>
> This resolves user regressions on GPUs with such connectors without
> reverting the original fix.
>
Reviewed-by: Lyude Paul
On Wed, 2023-10-11 at 13:41 +0200, Karol Herbst wrote:
> Just special case DP DSM connectors until we properly figure out how to
> deal with this.
>
> This resolves user regressions on GPUs with such connectors without
> reverting the original fix.
>
Reviewed-by: Lyude Paul
On Fri, 2023-10-06 at 17:55 -0700, Randy Dunlap wrote:
> include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
> @NOUVEAU_GETPARAM_EXEC_PUSH_MAX
> on line 49 - I thought it was a doc line
>
> Fixes: d59e75eef52d ("drm/nouveau: exec: repo
Reviewed-by: Lyude Paul
On Fri, 2023-10-06 at 17:55 -0700, Randy Dunlap wrote:
> include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
> @NOUVEAU_GETPARAM_EXEC_PUSH_MAX
> on line 49 - I thought it was a doc line
>
> Fixes: d59e75eef52d ("drm/nouveau: exec: repo
, and as well: this breaks things because you don't add back the
drm_mode_probed_add() call.
> + if (!mode)
> + continue;
>
> n++;
> }
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Reviewed-by: Lyude Paul
On Sun, 2023-10-08 at 07:02 -0700, Randy Dunlap wrote:
> kernel-doc emits a warning:
>
> include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
> @NOUVEAU_GETPARAM_EXEC_PUSH_MAX
> on line 49 - I thought it was a doc line
>
> We don't h
Reviewed-by: Lyude Paul
On Sun, 2023-10-08 at 07:02 -0700, Randy Dunlap wrote:
> kernel-doc emits a warning:
>
> include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
> @NOUVEAU_GETPARAM_EXEC_PUSH_MAX
> on line 49 - I thought it was a doc line
>
> We don't h
This seems like a very good solution to the problem :)
Reviewed-by: Lyude Paul
On Thu, 2023-10-05 at 13:16 +, Simon Ser wrote:
> The driver might pull connectors which weren't submitted by
> user-space into the atomic state. For instance,
> intel_dp_mst_atomic_master_trans_chec
For the whole series:
Reviewed-by: Lyude Paul
On Mon, 2023-10-02 at 15:46 +0200, Danilo Krummrich wrote:
> Use actual struct nvif_mclass instead of identical anonymous struct.
>
> Signed-off-by: Danilo Krummrich
> ---
> drivers/gpu/drm/nouveau/nouveau_chan.c | 5 +
>
For the whole series:
Reviewed-by: Lyude Paul
On Mon, 2023-10-02 at 15:46 +0200, Danilo Krummrich wrote:
> Use actual struct nvif_mclass instead of identical anonymous struct.
>
> Signed-off-by: Danilo Krummrich
> ---
> drivers/gpu/drm/nouveau/nouveau_chan.c | 5 +
>
Reviewed-by: Lyude Paul
On Sat, 2023-09-16 at 03:14 +0200, Danilo Krummrich wrote:
> Fix the following warning.
>
> drivers/gpu/drm/nouveau/nouveau_fence.c:210:45: sparse: sparse:
> incorrect type in initializer (different address spaces)
> @@ expected struct nouvea
Reviewed-by: Lyude Paul
On Sat, 2023-09-16 at 03:14 +0200, Danilo Krummrich wrote:
> Fix the following warning.
>
> drivers/gpu/drm/nouveau/nouveau_fence.c:210:45: sparse: sparse:
> incorrect type in initializer (different address spaces)
> @@ expected struct nouvea
Definitely a TODO there that I no longer can remember why I didn't just do
this in the first place, lol. Thank you for the fix
Reviewed-by: Lyude Paul
On Fri, 2023-09-29 at 18:49 +0300, Imre Deak wrote:
> Atm the MST encoder config computation may use an out-of-date pbn_div
> value, if th
actually very glad to see this because I think I've seen one bug in the wild
as a result of things not getting shut down :)
Reviewed-by: Lyude Paul
Tested-by: Lyude Paul
On Thu, 2023-09-21 at 12:26 -0700, Douglas Anderson wrote:
> Based on grepping through the source code this driver appe
actually very glad to see this because I think I've seen one bug in the wild
as a result of things not getting shut down :)
Reviewed-by: Lyude Paul
Tested-by: Lyude Paul
On Thu, 2023-09-21 at 12:26 -0700, Douglas Anderson wrote:
> Based on grepping through the source code this driver appe
gt; return 0;
>
> /* If the CRTC isn't disabled by this state, don't release it's payload
> */
> new_conn_state = drm_atomic_get_new_connector_state(state,
> port->connector);
> - if (new_conn_state->crtc) {
> + WARN_ON(!new_conn_state);
&
…ugh, thanks for catching that :|
yes you're completely right - NAK on this patch then
On Fri, 2023-09-22 at 22:22 +0300, Imre Deak wrote:
> On Fri, Sep 22, 2023 at 03:02:23PM -0400, Lyude Paul wrote:
> >
> > Oh! wow thank you for catching this:
> >
> > Reviewed
Oh! wow thank you for catching this:
Reviewed-by: Lyude Paul
I will go and push this to drm-misc-next in just a moment
On Fri, 2023-09-15 at 10:24 +0530, Ramya SR wrote:
> Modeset mutex unlock is missing in drm_dp_mst_detect_port function.
> This will lead to deadlock if calling the fu
Reviewed-by: Lyude Paul
Thanks!
On Fri, 2023-09-22 at 10:32 -0700, Kees Cook wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time che
1 - 100 of 6924 matches
Mail list logo
