Hi everyone,
Am Freitag, 27. September 2024, 01:13:57 CEST schrieb Dmitry Baryshkov:
> On Thu, Sep 26, 2024 at 04:09:03PM GMT, Alexander Stein wrote:
> > Hi Dmitry,
> >
> > Am Donnerstag, 26. September 2024, 08:05:56 CEST schrieb Dmitry Baryshkov:
> > > On Thu, Sep 26, 2024 at 07:55:51AM GMT, Ale
2250.07e1c...@canb.auug.org.au/
Cc: David Airlie
Cc: Simona Vetter
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Thomas Zimmermann
---
Cc: patc...@lists.linux.dev
Documentation/gpu/drm-kms-helpers.rst |9 -
1 file changed, 9 deletions(-)
--- linux-next-202
modprobe drm_hdmi_state_helper_test and then rmmod it, the following
memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xff80ccd18100 (size 128):
comm "kun
modprobe ttm_device_test and then rmmod ttm_device_test, the following
memory leaks occurs:
The ttm->pages allocated in ttm_tt_init() is not freed after calling
ttm_tt_simple_create(), which cause the memory leak:
unreferenced object 0xff80caf27750 (size 8):
comm "kunit_try_
modprobe drm_connector_test and then rmmod drm_connector_test,
the following memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xff80cb0ee400 (size 128):
c
As Maxime suggested, add a new helper
drm_kunit_display_mode_from_cea_vic(), it can replace the direct call
of drm_display_mode_from_cea_vic(), and it will help solving
the `mode` memory leaks.
Acked-by: Maxime Ripard
Suggested-by: Maxime Ripard
Signed-off-by: Jinjie Ruan
---
v3:
- Adjust drm/d
Fix some memory leaks in drm tests.
Changes in v3:
- Adjust drm/drm_edid.h header to drm_kunit_helpers.c.
- Drop the "helper" in the helper name.
- s/fllowing/following/
- Add Acked-by.
Changes in v2:
- Fix it with new introduced helper instead of drm_mode_destroy().
- Update the commit message.
On Wed, Oct 16, 2024 at 09:50:04AM +0200, Krzysztof Kozlowski wrote:
> On 15/10/2024 21:35, Akhil P Oommen wrote:
> > On Mon, Oct 14, 2024 at 09:40:13AM +0200, Krzysztof Kozlowski wrote:
> >> On Sat, Oct 12, 2024 at 01:59:30AM +0530, Akhil P Oommen wrote:
> >>> Update GPU node to include acd level
On Wed, Oct 16, 2024 at 09:53:58AM +0200, Krzysztof Kozlowski wrote:
> On 15/10/2024 21:13, Akhil P Oommen wrote:
> > On Mon, Oct 14, 2024 at 09:39:01AM +0200, Krzysztof Kozlowski wrote:
> >> On Sat, Oct 12, 2024 at 01:59:29AM +0530, Akhil P Oommen wrote:
> >>> Add a new schema which extends opp-v2
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> >>
>> >> > On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew B
On Thu, Oct 17, 2024, at 00:26, Sean Christopherson wrote:
> On Tue, Oct 15, 2024, Arnd Bergmann wrote:
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index 46301c06d18a..985cb78d8256 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
>
> Matthew Brost writes:
>
> > On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair Popple wrote:
> >>
> >> Matthew Brost writes:
> >>
> >> > On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew Brost wrote:
> >> >> On Wed, Oct 16,
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, October 16, 2024 7:31 PM
> To: Murthy, Arun R
> Cc: intel...@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/display: plane property for async supported
On 10/14/24 19:13, Matthew Brost wrote:
On Fri, Oct 11, 2024 at 04:12:41PM -0700, Lizhi Hou wrote:
Add interfaces for user application to submit command and wait for its
completion.
Co-developed-by: Min Ma
Signed-off-by: Min Ma
Signed-off-by: Lizhi Hou
---
drivers/accel/amdxdna/aie2_ctx.
GitHub Dependabot has issued the following alert:
"build(deps): bump idna from 3.4 to 3.7 in /drivers/gpu/drm/ci/xfails.
A specially crafted argument to the function could consume
significant resources. This may lead to a denial-of-service.
The function has been refined to reject such strings
GitHub Dependabot has issued the following alert:
"build(deps): bump certifi from 2023.7.22 to 2024.7.4 in
/drivers/gpu/drm/ci/xfails.
Certifi 2024.07.04 removes root certificates from "GLOBALTRUST"
from the root store. These are in the process of being removed from
Mozilla's trust store.
G
GitHub Dependabot has issued the following alert:
"build(deps): bump requests from 2.31.0 to 2.32.2 in
/drivers/gpu/drm/ci/xfails.
When making requests through a Requests Session, if the first
request is made with verify=False to disable cert verification,
all subsequent requests to the same
GitHub Dependabot has issued the following alert:
"build(deps): bump urllib3 from 2.0.7 to 2.2.2 in
/drivers/gpu/drm/ci/xfails.
When using urllib3's proxy support with, the header is only sent
to the configured proxy, as expected.
However, when sending HTTP requests without using urllib3's p
GitHub Dependabot keeps bugging us about old, vulnerable Python packages.
Until we figure out a way to make it calm, we're stuck updating our
dependencies whenever it complains.
I guess it's a good thing in the long run, though, right?
Makes our CI a bit "more secure"...
Signed-off-by: WangYuli
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew Brost wrote:
>> >> On Wed, Oct 16, 2024 at 03:04:06PM +1100, Alistair Popple wrote:
>>
>> [...]
>>
>> >> > > +{
>>
Hi,
>Hi,
>
>On Wed, Oct 16, 2024 at 10:10 PM wrote:
>>
>> >
>> >
>> >-Original Message-
>> >From: Pin-yen Lin
>> >Sent: Thursday, October 17, 2024 5:52 AM
>> >To: Hermes Wu (吳佳宏)
>> >Cc: Andrzej Hajda ; Neil Armstrong
>> >; Robert Foss ; Laurent
>> >Pinchart ; Jonas Karlman
>> >; Jer
Vetter
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
---
Cc: patc...@lists.linux.dev
Documentation/gpu/drm-kms-helpers.rst |9 -
1 file changed, 9 deletions(-)
--- linux-next-20241016.orig/Documentation/gpu/drm-kms-helpers.rst
+++ linux-next-20241016/Documentation/g
On Mon, Sep 30, 2024 at 01:08:41PM +0530, Raag Jadav wrote:
> Introduce device wedged event, which will notify userspace of wedged
> (hanged/unusable) state of the DRM device through a uevent. This is
> useful especially in cases where the device is no longer operating as
> expected even after a ha
On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair Popple wrote:
>
> Matthew Brost writes:
>
> > On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew Brost wrote:
> >> On Wed, Oct 16, 2024 at 03:04:06PM +1100, Alistair Popple wrote:
>
> [...]
>
> >> > > +{
> >> > > + unsigned long i;
> >> >
l@lists.freedesktop.org
> ---
> Documentation/gpu/drm-kms-helpers.rst |9 -
> 1 file changed, 9 deletions(-)
>
> --- linux-next-20241016.orig/Documentation/gpu/drm-kms-helpers.rst
> +++ linux-next-20241016/Documentation/gpu/drm-kms-helpers.rst
> @@ -110,15 +110,6
Hi,
On Wed, Oct 16, 2024 at 10:10 PM wrote:
>
> >
> >
> >-Original Message-
> >From: Pin-yen Lin
> >Sent: Thursday, October 17, 2024 5:52 AM
> >To: Hermes Wu (吳佳宏)
> >Cc: Andrzej Hajda ; Neil Armstrong
> >; Robert Foss ; Laurent
> >Pinchart ; Jonas Karlman
> >; Jernej Skrabec ; Maart
ction")
Signed-off-by: Randy Dunlap
Reported-by: Stephen Rothwell
Cc: David Airlie
Cc: Simona Vetter
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
---
Documentation/gpu/drm-kms-helpers.rst |9 -
1 file changed, 9 deletions(-)
--- linux-next-20241016.orig/Documentation/g
The print function dev_err() is redundant because
platform_get_irq_byname() already prints an error.
./drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c:278:2-9: line 278 is redundant
because platform_get_irq() already prints an error.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/sho
Jason Gunthorpe writes:
> On Wed, Oct 16, 2024 at 04:10:53PM +1100, Alistair Popple wrote:
>> On that note how is the refcounting of the returned p2pdma page expected
>> to work? We don't want the driver calling hmm_range_fault() to be able
>> to pin the page with eg. get_page(), so the returne
>
>
>-Original Message-
>From: Pin-yen Lin
>Sent: Thursday, October 17, 2024 5:52 AM
>To: Hermes Wu (吳佳宏)
>Cc: Andrzej Hajda ; Neil Armstrong
>; Robert Foss ; Laurent Pinchart
>; Jonas Karlman ; Jernej
>Skrabec ; Maarten Lankhorst
>; Maxime Ripard ;
>Thomas Zimmermann ; David Airlie
Matthew Brost writes:
> On Wed, Oct 16, 2024 at 03:00:08PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > Avoid multiple CPU page faults to the same device page racing by trying
>> > to lock the page in do_swap_page before taking an extra reference to the
>> > page. This p
Matthew Brost writes:
> On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew Brost wrote:
>> On Wed, Oct 16, 2024 at 03:04:06PM +1100, Alistair Popple wrote:
[...]
>> > > +{
>> > > +unsigned long i;
>> > > +
>> > > +for (i = 0; i < npages; i++) {
>> > > +struct pa
On 2024/10/16 17:35, Maxime Ripard wrote:
> On Mon, Oct 14, 2024 at 08:52:01PM GMT, Jinjie Ruan wrote:
>> As Maxime suggested, add a new helper
>> drm_kunit_helper_display_mode_from_cea_vic(), it can replace
>> the direct call of drm_display_mode_from_cea_vic(), and it will
>> help solving the `
Add a helper that will handle the correct order of the encoder kickoffs
for concurrent writeback.
For concurrent writeback, the realtime encoder must always kickoff last
as it will call the trigger flush and start.
This avoids the following scenario where the writeback encoder
increments the pend
From: Dmitry Baryshkov
All resource allocation is centered around the LMs. Then other blocks
(except DSCs) are allocated basing on the LMs that was selected, and LM
powers up the CRTC rather than the encoder.
Moreover if at some point the driver supports encoder cloning,
allocating resources fro
Adjust QoS remapper, OT limit, and CDP parameters to account for
concurrent writeback
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
Add support for RM to reserve dedicated CWB PINGPONGs and CWB muxes
For concurrent writeback, even-indexed CWB muxes must be assigned to
even-indexed LMs and odd-indexed CWB muxes for odd-indexed LMs. The same
even/odd rule applies for dedicated CWB PINGPONGs.
Track the CWB muxes in the global st
For concurrent writeback, the real time encoder is responsible for
trigger flush and trigger start. Return early for trigger start and
trigger flush for the concurrent writeback encoders.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
Starting the frame done timer before the encoder is finished kicking off
can lead to unnecessary frame done timeouts when the device is
experiencing heavy load (ex. when debug logs are enabled).
Thus, create a separate API for starting the encoder frame done timer and
call it after the encoder kic
Cache the CWB block mask in the DPU virtual encoder and configure CWB
according to the CWB block mask within the writeback phys encoder
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 75 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.
From: Dmitry Baryshkov
The struct dpu_rm_requirements was used to wrap display topology and
hw resources, which meant INTF indices. As of commit ef58e0ad3436
("drm/msm/dpu: get INTF blocks directly rather than through RM") the hw
resources struct was removed, leaving struct dpu_rm_requirements
co
We cannot support both CWB and CDM simultaneously as this would require
2 CDM blocks and currently our hardware only supports 1 CDM block at
most.
Thus return an error if both CWB and CDM are enabled.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4
1 file cha
From: Esha Bharadwaj
Adjust the WB_MUX configuration to account for using dedicated CWB
pingpong blocks.
Signed-off-by: Esha Bharadwaj
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletio
Change pingpong index and names to distinguish between general use
pingpong blocks and pingpong blocks dedicated for concurrent writeback
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 8
drivers/gpu/drm/msm/dis
Add a common helper to check if the given CRTC state is in clone mode.
This can be used by drivers to help detect if a CRTC is being shared by
multiple encoders
Signed-off-by: Jessica Zhang
---
NOTE: The appropriate KUnit tests will be added in a separate series
---
drivers/gpu/drm/drm_crtc.c |
From: Dmitry Baryshkov
Up to now the driver has been using encoder to allocate hardware
resources. Switch it to use CRTC id in preparation for the next step.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +--
drivers/gpu/drm
The CWB mux has a pending flush bit and *_active register.
Add support for configuring them within the dpu_hw_ctl layer.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 13 ++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys
Add the cwb_enabled flag to msm_display topology and adjust the toplogy
to account for concurrent writeback
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 11 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 --
drivers/gpu/drm/msm/msm_drv.h
Add support for allocating the concurrent writeback mux as part of the
WB allocation
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 ++
2 files changed, 17 insertions(+), 2
From: Esha Bharadwaj
Implement instance of snapshot function to dump new registers used
for cwb
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Esha Bharadwaj
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/driver
From: Dmitry Baryshkov
Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources
from dpu_crtc_assign_resources().
Signed-off-by: Dmitry Baryshkov
[quic_abhin...@quicinc.com: cleaned up formatting]
Signed-off-by: Abhinav Kumar
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm
Set writeback encoders as possible clones for DSI encoders and vice
versa.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 32 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 ++
drivers/gpu/drm/msm/disp
The CWB mux has its own registers and set of operations. Add dpu_hw_cwb
abstraction to allow driver to configure the CWB mux.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.c | 73 +
From: Esha Bharadwaj
Add a new block for concurrent writeback mux to the SM8650 HW catalog
Signed-off-by: Esha Bharadwaj
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 21 +
drivers/gpu/drm/msm/disp/dpu
Check that all encoders attached to a given CRTC are valid
possible_clones of each other.
Signed-off-by: Jessica Zhang
---
NOTE: Appropriate KUnit tests for this change will be posted in a
separate series
---
drivers/gpu/drm/drm_atomic_helper.c | 23 +++
1 file changed, 23 i
DPU supports a single writeback session running concurrently with primary
display when the CWB mux is configured properly. This series enables
clone mode for DPU driver and adds support for programming the CWB mux
in cases where the hardware has dedicated CWB pingpong blocks. Currently,
the CWB har
If the clone mode enabled status is changing, a modeset needs to happen
so that the resources can be reassigned
Signed-off-by: Jessica Zhang
---
NOTE: As noted by Sima in the v1 [1], the DPU driver doesn't handle
crtc_state->mode_changed correctly. However, fixing this is out of the
scope of thi
On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew Brost wrote:
> On Wed, Oct 16, 2024 at 03:04:06PM +1100, Alistair Popple wrote:
> >
> > Matthew Brost writes:
> >
> > > Add migrate_device_prepoluated_range which prepares an array of
> > > pre-populated device pages for migration.
> >
> > It wo
On Tue, Oct 15, 2024, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Depending on x86 and KVM is not enough, as the kvm helper functions
> that get called here are controlled by CONFIG_KVM_X86, which is
> disabled if both KVM_INTEL and KVM_AMD are turned off.
>
> ERROR: modpost: "kvm_write_track
Add support for gamma LUT in VOP2 driver. The implementation was inspired
by one found in VOP1 driver. Blue and red channels in gamma LUT register
write were swapped with respect to how gamma LUT values are written in
VOP1. Gamma LUT port selection was added before the write of new gamma LUT
table.
Yonatan Maman writes:
> On 16/10/2024 7:23, Christoph Hellwig wrote:
>> On Tue, Oct 15, 2024 at 06:23:44PM +0300, Yonatan Maman wrote:
>>> From: Yonatan Maman
>>>
>>> This patch series aims to enable Peer-to-Peer (P2P) DMA access in
>>> GPU-centric applications that utilize RDMA and private de
Hi Andy
On Wednesday, October 16th, 2024 at 11:23 AM, Piotr Zalewski
wrote:
> > > static void vop2_crtc_atomic_flush(struct drm_crtc *crtc,
> > > @@ -2790,7 +2945,13 @@ static int vop2_create_crtcs(struct vop2 *vop2)
> > > }
> > >
> > > drm_crtc_helper_add(&vp->crtc, &vop2_crtc_helper_funcs);
Hi Hermes,
On Wed, Oct 16, 2024 at 3:54 AM Hermes Wu via B4 Relay
wrote:
>
> This is a v6 patch-set.
>
> There are lots of failure items while running HDCP CTS using UNIGRAF DPR-100.
> In Order to fix those failures, HDCP flow needs to be changed.
>
> The DisplayPort AUX protocol supports I2C tra
On Wed, Oct 16, 2024 at 5:13 AM Antonino Maniscalco
wrote:
>
> On 10/8/24 11:10 PM, Kees Bakker wrote:
> > Op 03-10-2024 om 18:12 schreef Antonino Maniscalco:
> >> Add trace points corresponding to preemption being triggered and being
> >> completed for latency measurement purposes.
> >>
> >> Revi
Hi Piotr,
On Wed, 16 Oct 2024 at 20:19, Piotr Zalewski wrote:
> On Wednesday, October 16th, 2024 at 2:27 PM, Daniel Stone
> wrote:
> > 1 is the only solution that can work. Silently changing the colour
> > properties of a separate CRTC is not OK, since this can lead to
> > displaying incorrect
("platform: Make platform_driver::remove()
> return void") .remove() is (again) the right callback to implement for
> platform drivers. Please just drop "_new".
>
> Additionally I suggest to drop one of the white spaces between .probe
> and =.
Handled b
From: Zichen Xie
There may be potential integer overflow issue in
rockchip_gem_dumb_create(). args->size is defined
as "__u64" while args->pitch and args->height are
both defined as "__u32". The result of
"args->pitch * args->height" will be limited to
"__u32" without correct casting.
Cast it to
The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX Controller IP
supports the following features, among others:
* Fixed Rate Link (FRL)
* Display Stream Compression (DSC)
* 4K@120Hz and 8K@60Hz video modes
* Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
Cinema VRR
* Fas
The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1
Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a
Samsung IP block.
Add just the basic support for now, i.e. RGB output up to 4K@60Hz,
without audio, CEC or any of the HDMI 2.1 specific features.
Co-deve
Rockchip RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1
Quad-Pixel (QP) TX controller IP.
Since this is a new IP block, quite different from those used in the
previous generations of Rockchip SoCs, add a dedicated binding file.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Cristian Cio
The Rockchip RK3588 SoC family integrates the Synopsys DesignWare HDMI
2.1 Quad-Pixel (QP) TX controller, which is a new IP block, quite
different from those used in the previous generations of Rockchip SoCs.
The controller supports the following features, among others:
* Fixed Rate Link (FRL)
*
Hi Dave, Simona,
Fixes for 6.12.
The following changes since commit 8e929cb546ee42c9a61d24fae60605e9e3192354:
Linux 6.12-rc3 (2024-10-13 14:33:32 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.12-2024-10-16
for you to fe
On 2024-10-15 23:29, Kasireddy, Vivek wrote:
> I think it would make sense to limit the passing criteria for device
> functions'
> compatibility to Intel GPUs for now. These are the devices I am currently
> testing that we know are P2P compatible. Would this be OK?
Yes, this sounds good to me.
Hi Daniel,
On Wednesday, October 16th, 2024 at 2:27 PM, Daniel Stone
wrote:
> Hi all,
>
> On Wed, 16 Oct 2024 at 02:11, Andy Yan andys...@163.com wrote:
>
> > At 2024-10-16 04:13:40, "Piotr Zalewski" pz010001011...@proton.me wrote:
> >
> > > Ok I get it now. Is such rework correct? - when gamma
Hi Stefan
On Tue, 15 Oct 2024 at 22:13, Stefan Wahren wrote:
>
> Hi Dave,
>
> Am 15.10.24 um 11:32 schrieb Dave Stevenson:
> > On Mon, 14 Oct 2024 at 22:16, Stefan Wahren wrote:
> >>
> >> Am 14.10.24 um 12:54 schrieb Dave Stevenson:
> >>> On Mon, 14 Oct 2024 at 10:04, Maxime Ripard wrote:
> >>>
On 2024-09-16 14:23, Thomas Weißschuh wrote:
> Hi Harry, Leo and other amdgpu maintainers,
>
> On 2024-08-24 20:33:53+, Thomas Weißschuh wrote:
>> The value of "min_input_signal" returned from ATIF on a Framework AMD 13
>> is "12". This leads to a fairly bright minimum display backlight.
>>
On Wed, Oct 16, 2024 at 09:41:03AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 16, 2024 at 12:44:28PM -0300, Jason Gunthorpe wrote:
> > > We are talking about P2P memory here. How do you manage to get a page
> > > that dma_map_page can be used on? All P2P memory needs to use the P2P
> > > aware
On 2024-09-20 9:20 am, Andy Yan wrote:
From: Andy Yan
The vop mmu support translate physical address upper 4 GB to iova
below 4 GB. So set dma mask to 64 bit to indicate we support address
4GB.
This can avoid warnging message like this on some boards with DDR
4 GB:
rockchip-drm display-su
On Wed, Oct 16, 2024 at 08:17:50AM +0200, Thomas Hellström wrote:
[...]
> >
> > So even though first_lock_dep_map is a fake lock, it has to have the
> > same wait types as a real mutex.
>
> Understood.
> >
> > Does this make sense?
>
> Yes it does. I'll update to a v3, and add a Tested-by: tag.
Hi Dave,
A few fixes for v6.12, see description below
The following changes since commit 15302579373ed2c8ada629e9e7bcf9569393a48d:
drm/msm/dpu: enable writeback on SM6350 (2024-09-02 02:53:44 +0300)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git tags/drm
On 16.10.2024 15:12, Christian König wrote:
> Am 15.10.24 um 01:31 schrieb Adrián Larumbe:
> > Doesn't make any functional difference because generic dma_fence is the
> > first panfrost_fence structure member, but I guess it doesn't hurt either.
>
> As discussed with Sima we want to push into the
On Wed, Oct 16, 2024 at 10:26 AM AngeloGioacchino Del Regno
wrote:
>
> Il 16/10/24 16:00, Rob Herring ha scritto:
> > On Wed, Oct 16, 2024 at 4:23 AM AngeloGioacchino Del Regno
> > wrote:
> >>
> >> Il 15/10/24 15:48, Rob Herring ha scritto:
> >>> On Tue, Oct 15, 2024 at 10:32:22AM +0200, AngeloGi
On Wed, Oct 16, 2024 at 04:10:53PM +1100, Alistair Popple wrote:
> On that note how is the refcounting of the returned p2pdma page expected
> to work? We don't want the driver calling hmm_range_fault() to be able
> to pin the page with eg. get_page(), so the returned p2pdma page should
> have a zer
On Tue, Oct 15, 2024 at 09:49:30PM -0700, Christoph Hellwig wrote:
> > + /*
> > +* Used for private (un-addressable) device memory only. Return a
> > +* corresponding struct page, that can be mapped to device
> > +* (e.g using dma_map_page)
> > +*/
> > + struct page *(*get_dma_
Il 16/10/24 16:00, Rob Herring ha scritto:
On Wed, Oct 16, 2024 at 4:23 AM AngeloGioacchino Del Regno
wrote:
Il 15/10/24 15:48, Rob Herring ha scritto:
On Tue, Oct 15, 2024 at 10:32:22AM +0200, AngeloGioacchino Del Regno wrote:
Il 14/10/24 19:36, Rob Herring ha scritto:
On Mon, Oct 14, 2024
On 16/10/2024 8:12, Alistair Popple wrote:
Yonatan Maman writes:
From: Yonatan Maman
Enabling Peer-to-Peer DMA (P2P DMA) access in GPU-centric applications
is crucial for minimizing data transfer overhead (e.g., for RDMA use-
case).
This change aims to enable that capability for Nouveau
On 16/10/2024 7:23, Christoph Hellwig wrote:
On Tue, Oct 15, 2024 at 06:23:44PM +0300, Yonatan Maman wrote:
From: Yonatan Maman
This patch series aims to enable Peer-to-Peer (P2P) DMA access in
GPU-centric applications that utilize RDMA and private device pages. This
enhancement is crucial
Hi Jyothi,
...
> @@ -523,26 +576,49 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c,
> struct i2c_msg *msg,
> enum dma_transfer_direction dma_dirn;
> struct dma_async_tx_descriptor *desc;
> int ret;
> + struct gpi_multi_xfer *gi2c_gpi_xfer;
> + dma_cookie_t cookie;
On 16/10/2024 7:49, Christoph Hellwig wrote:
The subject does not make sense. All P2P is on ZONE_DEVICE pages.
It seems like this is about device private memory?
Correct, thanks, I will change it to `mm/hmm: HMM API to enable P2P DMA
for device private pages`, on v2.
On Tue, Oct 15, 2024
On Tue, Oct 15, 2024 at 03:33:00PM GMT, Krzysztof Kozlowski wrote:
> On 15/10/2024 14:07, Jyothi Kumar Seerapu wrote:
> > When high performance with multiple i2c messages in a single transfer
> > is required, employ Block Event Interrupt (BEI) to trigger interrupts
> > after specific messages trans
On Wed, 2024-10-16 at 15:02 +0100, Robin Murphy wrote:
> On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
> > On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
> > > On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
> > > > +/**
> > > > + * enum drm_panthor_sync_op_flags - Synchronizatio
On Wed, 16 Oct 2024 16:05:55 +0200
Erik Faye-Lund wrote:
> On Wed, 2024-10-16 at 15:02 +0100, Robin Murphy wrote:
> > On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
> > > On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
> > > > On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
wed-by tag
- Link to v2:
https://lore.kernel.org/r/20241016-color-v2-1-46db5c78a...@chromium.org
Changes in v2:
- Clarify that the commit get fixed was intended to be a no-op cleanup
- Fix the typo in tag
- Link to v1:
https://lore.kernel.org/r/20241015-color-v1-1-35b01fa0a...@chromium.org
On Wed, 2024-10-16 at 15:47 +0200, Boris Brezillon wrote:
> On Wed, 16 Oct 2024 15:16:22 +0200
> Erik Faye-Lund wrote:
>
> > On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
> > > +/**
> > > + * enum drm_panthor_sync_op_flags - Synchronization operation
> > > flags.
> > > + */
> > > +enu
On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
+/**
+ * enum drm_panthor_sync_op_flags - Synchronization operation
flags.
+ */
+enum drm_panthor_sync_op_flags {
+ /** @DRM_PANT
On Wed, Oct 16, 2024 at 04:54:09PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> > > Create a i915 private plane property for sharing the async supported
> > > modifiers to the user.
On Wed, Oct 16, 2024 at 4:23 AM AngeloGioacchino Del Regno
wrote:
>
> Il 15/10/24 15:48, Rob Herring ha scritto:
> > On Tue, Oct 15, 2024 at 10:32:22AM +0200, AngeloGioacchino Del Regno wrote:
> >> Il 14/10/24 19:36, Rob Herring ha scritto:
> >>> On Mon, Oct 14, 2024 at 3:51 AM AngeloGioacchino De
On Mon, 2024-10-14 at 14:23 +, Matt Coster wrote:
> From: Brendan King
>
> When remaining resources are being cleaned up on driver close,
> outstanding VM mappings may result in resources being leaked, due
> to an object reference loop, as shown below, with each object (or
> set of objects) r
On Mon, 2024-10-14 at 14:22 +, Matt Coster wrote:
> From: Brendan King
>
> This adds a linked list of VM contexts which is needed for the next patch
> to be able to correctly track VM contexts for destruction on file close.
>
> It is only safe for VM contexts to be removed from the list and
On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> > Create a i915 private plane property for sharing the async supported
> > modifiers to the user.
> > UMD related discussion requesting the same
> > https://gitlab.freed
1 - 100 of 168 matches
Mail list logo
