Re: [PATCH 0/2] drm: amdgpu: Fix includes of

Hi Alex, Em 16/06/2025 03:59, Christian König escreveu: Acked-by: Christian König for the series. Can you add this series to amd-staging-drm-next? Thanks! On 6/13/25 20:26, André Almeida wrote: Commit 7d95680d64ac ("scripts/misc-check: check unnecessary #include when W=1") and commit a93

Re: [PATCH 0/2] drm: amdgpu: Fix includes of

Applied. Thanks! On Tue, Jun 24, 2025 at 11:27 AM André Almeida wrote: > > Hi Alex, > > Em 16/06/2025 03:59, Christian König escreveu: > > Acked-by: Christian König for the series. > > > > Can you add this series to amd-staging-drm-next? Thanks! > > > On 6/13/25 20:26, André Almeida wrote: > >>

Re: [PATCH 0/2] drm: amdgpu: Fix includes of

Acked-by: Christian König for the series. On 6/13/25 20:26, André Almeida wrote: > Commit 7d95680d64ac ("scripts/misc-check: check unnecessary #include > when W=1") and commit a934a57a42f6 ("scripts/misc-check: > check missing #include when W=1") added new checks for when > the > include is m

Re: [PATCH 0/2] drm/amdgpu: typos and standardization

Applied. Thanks! On Fri, Apr 4, 2025 at 1:48 AM Alexandre Demers wrote: > > Typos were found in DCE, where hpd should have been used. > > DCE6/8: standardize the "interrupt" vs "irq" usage in function names > with DCE10/11. > > Alexandre Demers (2): > drm/amdgpu: fix typos in DCEs > drm/amdg

Re: [PATCH 0/2] drm/amdgpu: better complete DCE6 and GMC6

Applied. Thanks! On Fri, Apr 4, 2025 at 1:43 AM Alexandre Demers wrote: > > First patch moves some DCE files around so they are distributed as are > other DCE files > > Second patch implements gmc_v6_0_set_clockgating_state(), which was mostly > there, but commented out. A few tweeks were needed

Re: [PATCH 0/2] Fit one IB struct amdgpu_job into a 512 byte slab

On 24/02/2025 12:06, Tvrtko Ursulin wrote: A lot of the workloads create jobs with just one IB and if we re-order some struct members we can stop that allocation spilling into the 1k SLAB bucket. Before: sizeof(struct amdgpu_job) + sizeof(struct amdgpu_ib) = 480 + 40 = 520 After: size

Re: [PATCH 0/2] Add amdisp pinctrl MFD resource

On 2/20/2025 12:31, Pratap Nirujogi wrote: This patch series includes two patches: patch-1: drm/amdgpu: Replace DRM_ERROR() with drm_err() patch-2: drm/amdgpu: Add amdisp pinctrl MFD resource About Patch-1: DRM_ERROR() is no longer preferred. Replace DRM_ERROR() usage with drm_err() in isp driv

Re: [PATCH 0/2] drm/amd/display: Fix Null Pointer Dereference Issues

Hi, Gentle ping. The patch link is: [PATCH 0/2] drm/amd/display: Fix Null Pointer Dereference Issues - Zicheng Qu (kernel.org) Best regards, Zicheng On 2024/11/5 22:01, Zicheng Qu wrote: Hi all, I am s

Re: [PATCH 0/2] drm/amd/display: Fix Power Gating Configuration

On 11/5/24 7:02 AM, Zicheng Qu wrote: Hi all, I am submitting two patches to correct power gating configurations in the AMD display driver. 1. Patch 1/2 (Fixes: 46825fcfbe16): Corrects DOMAIN10_PG_CONFIG to use DOMAIN10_POWER_FORCEON. 2. Patch 2/2 (Fixes: 46825fcfbe16): Corrects DOMAIN11_PG_

Re: [PATCH 0/2] drm: Treewide plane/crtc legacy state sweeping

On Fri, 25 Oct 2024, Ville Syrjälä wrote: > On Wed, Oct 02, 2024 at 09:21:58PM +0300, Ville Syrjala wrote: >> From: Ville Syrjälä >> >> An attempt to hide the drm_plane/crtc legacy state better. >> >> This also highlights the fact that a lot of supposedly >> atomic drivers are poking around in

Re: [PATCH 0/2] drm: Treewide plane/crtc legacy state sweeping

On Fri, 25 Oct 2024 at 10:46, Ville Syrjälä wrote: > > On Wed, Oct 02, 2024 at 09:21:58PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > An attempt to hide the drm_plane/crtc legacy state better. > > > > This also highlights the fact that a lot of supposedly > > atomic drivers are po

Re: [PATCH 0/2] drm: Treewide plane/crtc legacy state sweeping

On Wed, Oct 02, 2024 at 09:21:58PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > An attempt to hide the drm_plane/crtc legacy state better. > > This also highlights the fact that a lot of supposedly > atomic drivers are poking around in the legacy crtc state, > which is rather questionab

Re: [PATCH 0/2] drm/amd: fix VRR race condition during IRQ handling

On 9/9/24 19:18, Harry Wentland wrote: On 2024-09-09 13:11, Alex Deucher wrote: On Sun, Sep 8, 2024 at 7:23 AM Tobias Jakobi wrote: On 9/8/24 09:35, Christopher Snowhill wrote: On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote: From: Tobias Jakobi Hello, this fixes a nasty race conditio

Re: [PATCH 0/2] drm/amd: fix VRR race condition during IRQ handling

On 2024-09-09 13:11, Alex Deucher wrote: > On Sun, Sep 8, 2024 at 7:23 AM Tobias Jakobi > wrote: >> >> On 9/8/24 09:35, Christopher Snowhill wrote: >> >>> On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote: From: Tobias Jakobi Hello, this fixes a nasty race condition in

Re: [PATCH 0/2] drm/amd: fix VRR race condition during IRQ handling

On Sun, Sep 8, 2024 at 7:23 AM Tobias Jakobi wrote: > > On 9/8/24 09:35, Christopher Snowhill wrote: > > > On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote: > >> From: Tobias Jakobi > >> > >> Hello, > >> > >> this fixes a nasty race condition in the set_drr() callbacks for DCN10 > >> and DCN35 th

Re: [PATCH 0/2] drm/amd: fix VRR race condition during IRQ handling

On Sun Sep 8, 2024 at 4:23 AM PDT, Tobias Jakobi wrote: > On 9/8/24 09:35, Christopher Snowhill wrote: > > > On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote: > >> From: Tobias Jakobi > >> > >> Hello, > >> > >> this fixes a nasty race condition in the set_drr() callbacks for DCN10 > >> and DCN35 t

Re: [PATCH 0/2] drm/amd: fix VRR race condition during IRQ handling

On 9/8/24 09:35, Christopher Snowhill wrote: On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote: From: Tobias Jakobi Hello, this fixes a nasty race condition in the set_drr() callbacks for DCN10 and DCN35 that has existed now since quite some time, see this GitLab issue for reference. https:/

Re: [PATCH 0/2] drm/amd: fix VRR race condition during IRQ handling

On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote: > From: Tobias Jakobi > > Hello, > > this fixes a nasty race condition in the set_drr() callbacks for DCN10 > and DCN35 that has existed now since quite some time, see this GitLab > issue for reference. > > https://gitlab.freedesktop.org/drm/amd/-/

Re: [PATCH 0/2] Fix for lightup issue on Lenovo 4k60 HDMI

On 8/22/24 3:14 PM, Fangzhi Zuo wrote: 338567d176 ("drm/amd/display: Fix MST BW calculation Regression") has been merged with a mistake being fixed by "drm/amd/display: Fix a mistake in revert commit" Fix dsc enablement for Synaptics Cascaded Panamera hub is included in "drm/amd/display:

Re: [PATCH 0/2] Fix for lightup issue on Lenovo 4k60 HDMI

On 22. 08. 24, 21:14, Fangzhi Zuo wrote: 338567d176 ("drm/amd/display: Fix MST BW calculation Regression") has been merged with a mistake being fixed by "drm/amd/display: Fix a mistake in revert commit" Fix dsc enablement for Synaptics Cascaded Panamera hub is included in "drm/amd/display: F

Re: [PATCH 0/2] Add support for Panel Power Savings property

Am Di., 21. Mai 2024 um 19:28 Uhr schrieb Leo Li : > > > > On 2024-05-21 12:21, Mario Limonciello wrote: > > On 5/21/2024 11:14, Xaver Hugl wrote: > >> Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello > >> : > >>> > >>> On 5/21/2024 08:43, Simon Ser wrote: > This makes sense to me i

Re: [PATCH 0/2] Add support for Panel Power Savings property

Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : > > On 5/21/2024 08:43, Simon Ser wrote: > > This makes sense to me in general. I like the fact that it's simple and > > vendor-neutral. > > > > Do we want to hardcode "panel" in the name? Are we sure that this will > > ever only apply t

Re: [PATCH 0/2] Add support for Panel Power Savings property

On 2024-05-21 13:32, Mario Limonciello wrote: On 5/21/2024 12:27, Leo Li wrote: On 2024-05-21 12:21, Mario Limonciello wrote: On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me

Re: [PATCH 0/2] Add support for Panel Power Savings property

On Tuesday, May 21st, 2024 at 19:27, Leo Li wrote: > I wonder if flags would work better than enums? A compositor can set something > like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example. (FWIW, the KMS uAPI has first-class support for bitfields.)

Re: [PATCH 0/2] Add support for Panel Power Savings property

On 5/21/2024 12:27, Leo Li wrote: On 2024-05-21 12:21, Mario Limonciello wrote: On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and

Re: [PATCH 0/2] Add support for Panel Power Savings property

On 2024-05-21 12:21, Mario Limonciello wrote: On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hard

Re: [PATCH 0/2] Add support for Panel Power Savings property

On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this wi

Re: [PATCH 0/2] Add support for Panel Power Savings property

On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mech

Re: [PATCH 0/2] Add support for Panel Power Savings property

This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On 2024-04-16 10:10, Harry Wentland wrote: On 2024-04-16 04:01, Pekka Paalanen wrote: On Mon, 15 Apr 2024 18:33:39 -0400 Leo Li wrote: On 2024-04-15 04:19, Pekka Paalanen wrote: On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On 2024-04-16 04:01, Pekka Paalanen wrote: > On Mon, 15 Apr 2024 18:33:39 -0400 > Leo Li wrote: > >> On 2024-04-15 04:19, Pekka Paalanen wrote: >>> On Fri, 12 Apr 2024 16:14:28 -0400 >>> Leo Li wrote: >>> On 2024-04-12 11:31, Alex Deucher wrote: > On Fri, Apr 12, 2024 at 11:08 A

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Mon, 15 Apr 2024 18:33:39 -0400 Leo Li wrote: > On 2024-04-15 04:19, Pekka Paalanen wrote: > > On Fri, 12 Apr 2024 16:14:28 -0400 > > Leo Li wrote: > > > >> On 2024-04-12 11:31, Alex Deucher wrote: > >>> On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen > >>> wrote: > > On Fri

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On 2024-04-15 04:19, Pekka Paalanen wrote: On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote:

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: > On 2024-04-12 11:31, Alex Deucher wrote: > > On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen > > wrote: > >> > >> On Fri, 12 Apr 2024 10:28:52 -0400 > >> Leo Li wrote: > >> > >>> On 2024-04-12 04:03, Pekka Paalanen wrote: > On Thu, 1

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: > On 2024-04-12 04:03, Pekka Paalanen wrote: > > On Thu, 11 Apr 2024 16:33:57 -0400 > > Leo Li wrote: > > ... > >> That begs the question of what can be nailed down and what can left to > >> independent implementation. I guess things like whi

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: > On 2024-04-04 10:22, Marius Vlad wrote: > > On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: > >> > > Hi all, > >> > >> On 2024-04-04 06:24, Pekka Paalanen wrote: > >>> On Wed, 3 Apr 2024 17:32:46 -0400 > >>> Leo Li wrote:

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be na

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: > > On Fri, 12 Apr 2024 10:28:52 -0400 > Leo Li wrote: > > > On 2024-04-12 04:03, Pekka Paalanen wrote: > > > On Thu, 11 Apr 2024 16:33:57 -0400 > > > Leo Li wrote: > > > > > ... > > > >> That begs the question of what can be nailed down and

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: On 2024-04-04 10:22, Marius Vlad wrote: On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: Hi all, On 2024-04-04 06:24, Pekka Paalanen wrote: On Wed, 3 Apr 2024 17:32:46 -0400 Le

RE: [PATCH 0/2] First set in IP dump patches

[AMD Official Use Only - General] Ignore the series sent by mistake -Original Message- From: Sunil Khatri Sent: Friday, April 12, 2024 2:30 PM To: Deucher, Alexander ; Koenig, Christian Cc: amd-gfx@lists.freedesktop.org; Khatri, Sunil Subject: [PATCH 0/2] First set in IP dump patches

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On 2024-04-04 10:22, Marius Vlad wrote: On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: Hi all, On 2024-04-04 06:24, Pekka Paalanen wrote: On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: On 2024-03-28 10:33, Pekka Paalanen wrote: On Fri, 15 Mar 2024 13:09:56 -0400 w

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: > On 2024-03-28 10:33, Pekka Paalanen wrote: > > On Fri, 15 Mar 2024 13:09:56 -0400 > > wrote: > > > >> From: Leo Li > >> > >> These patches aim to make the amdgpgu KMS driver play nicer with > >> compositors > >> when building multi-plane sca

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: > Hi all, > > On 2024-04-04 06:24, Pekka Paalanen wrote: > > On Wed, 3 Apr 2024 17:32:46 -0400 > > Leo Li wrote: > > > >> On 2024-03-28 10:33, Pekka Paalanen wrote: > >>> On Fri, 15 Mar 2024 13:09:56 -0400 > >>> wrote: > >>> >

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On 2024-04-04 06:24, Pekka Paalanen wrote: > On Wed, 3 Apr 2024 17:32:46 -0400 > Leo Li wrote: > >> On 2024-03-28 10:33, Pekka Paalanen wrote: >>> On Fri, 15 Mar 2024 13:09:56 -0400 >>> wrote: >>> From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On 2024-03-28 10:33, Pekka Paalanen wrote: On Fri, 15 Mar 2024 13:09:56 -0400 wrote: From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allo

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Fri, 15 Mar 2024 13:09:56 -0400 wrote: > From: Leo Li > > These patches aim to make the amdgpgu KMS driver play nicer with compositors > when building multi-plane scanout configurations. They do so by: > > 1. Making cursor behavior more sensible. > 2. Allowing placement of DRM OVERLAY plane

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

On 2024-01-17 13:57, Xaver Hugl wrote: > Am Mi., 17. Jan. 2024 um 09:55 Uhr schrieb Pekka Paalanen > : >> Is it important enough to be special-cased, e.g. to be always allowed >> with async commits? > > I thought so, and sent a patch to dri-devel to make it happen, but > there are some > concerns

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

Am Mi., 17. Jan. 2024 um 09:55 Uhr schrieb Pekka Paalanen : > Is it important enough to be special-cased, e.g. to be always allowed > with async commits? I thought so, and sent a patch to dri-devel to make it happen, but there are some concerns about untested driver paths. https://lists.freedeskto

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

My plan is to require support for IN_FENCE_FD at least. If the driver doesn't allow tearing with that, then tearing just doesn't happen. For overlay planes though, it depends on how the compositor prioritizes things. If the compositor prioritizes overlay planes and would like to do tearing if poss

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

On Tue, 16 Jan 2024 17:10:18 +0100 Xaver Hugl wrote: > My plan is to require support for IN_FENCE_FD at least. If the driver > doesn't > allow tearing with that, then tearing just doesn't happen. That's an excellent point. I think this is important enough in its own right, that it should be call

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

On 1/16/24 13:35, André Almeida wrote: + Joshua Em 16/01/2024 10:14, Pekka Paalanen escreveu: On Tue, 16 Jan 2024 08:50:59 -0300 André Almeida wrote: Hi Pekka, Em 16/01/2024 06:45, Pekka Paalanen escreveu: On Tue, 16 Jan 2024 01:51:57 -0300 André Almeida wrote: Hi, AMD hardware can d

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

+ Joshua Em 16/01/2024 10:14, Pekka Paalanen escreveu: On Tue, 16 Jan 2024 08:50:59 -0300 André Almeida wrote: Hi Pekka, Em 16/01/2024 06:45, Pekka Paalanen escreveu: On Tue, 16 Jan 2024 01:51:57 -0300 André Almeida wrote: Hi, AMD hardware can do more on the async flip path than just

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

On Tue, 16 Jan 2024 08:50:59 -0300 André Almeida wrote: > Hi Pekka, > > Em 16/01/2024 06:45, Pekka Paalanen escreveu: > > On Tue, 16 Jan 2024 01:51:57 -0300 > > André Almeida wrote: > > > >> Hi, > >> > >> AMD hardware can do more on the async flip path than just the primary > >> plane, so >

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

Hi Pekka, Em 16/01/2024 06:45, Pekka Paalanen escreveu: On Tue, 16 Jan 2024 01:51:57 -0300 André Almeida wrote: Hi, AMD hardware can do more on the async flip path than just the primary plane, so to lift up the current restrictions, this patchset allows drivers to write their own check for p

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

On Tue, 16 Jan 2024 01:51:57 -0300 André Almeida wrote: > Hi, > > AMD hardware can do more on the async flip path than just the primary plane, > so > to lift up the current restrictions, this patchset allows drivers to write > their > own check for planes for async flips. Hi, what's the user

Re: [PATCH 0/2] fdinfo shared stats

Ping on this series again? Alex On Wed, Dec 13, 2023 at 4:13 PM Alex Deucher wrote: > > On Thu, Dec 7, 2023 at 1:03 PM Alex Deucher wrote: > > > > We had a request to add shared buffer stats to fdinfo for amdgpu and > > while implementing that, Christian mentioned that just looking at > > the G

Re: [PATCH 0/2] fdinfo shared stats

On Thu, Dec 7, 2023 at 1:03 PM Alex Deucher wrote: > > We had a request to add shared buffer stats to fdinfo for amdgpu and > while implementing that, Christian mentioned that just looking at > the GEM handle count doesn't take into account buffers shared with other > subsystems like V4L or RDMA.

Re: [PATCH 0/2] Reduce stack size for DML2

On Tue, Oct 17, 2023 at 11:45:42AM -0600, Rodrigo Siqueira Jordao wrote: > Hi Nathan, > (+Hamza) > > First of all, thanks a lot for your feedback. You can see my comments > inline. > > On 10/17/23 11:22, Nathan Chancellor wrote: > > Hi Rodrigo, > > > > On Mon, Oct 16, 2023 at 08:19:16AM -0600, R

Re: [PATCH 0/2] Reduce stack size for DML2

On Tue, Oct 17, 2023 at 1:22 PM Nathan Chancellor wrote: > > Hi Rodrigo, > > On Mon, Oct 16, 2023 at 08:19:16AM -0600, Rodrigo Siqueira wrote: > > Stephen discovers a stack size issue when compiling the latest amdgpu > > code with allmodconfig. This patchset addresses that issue by splitting > > a

Re: [PATCH 0/2] Reduce stack size for DML2

Hi Nathan, (+Hamza) First of all, thanks a lot for your feedback. You can see my comments inline. On 10/17/23 11:22, Nathan Chancellor wrote: Hi Rodrigo, On Mon, Oct 16, 2023 at 08:19:16AM -0600, Rodrigo Siqueira wrote: Stephen discovers a stack size issue when compiling the latest amdgpu c

Re: [PATCH 0/2] Reduce stack size for DML2

Hi Rodrigo, On Mon, Oct 16, 2023 at 08:19:16AM -0600, Rodrigo Siqueira wrote: > Stephen discovers a stack size issue when compiling the latest amdgpu > code with allmodconfig. This patchset addresses that issue by splitting > a large function into two smaller parts. > > Thanks > Siqueira > > Rod

Re: [PATCH 0/2] Disable dynamic switching for SMU13 on Intel hosts

On Fri, Jul 7, 2023 at 3:32 PM Mario Limonciello wrote: > > When ASPM is enabled, DPM is used to perform dynamic switching. When > connected to an Intel PCIe controller this causes malfunctions. > > Identify this combination and disable dynamic switching in SMU13. > > This series superceeds my ot

Re: [PATCH 0/2] Recover from failure to probe GPU

Hello Alex, On 12/27/22 18:04, Alex Deucher wrote: [...] > > I think something like this would do the trick: > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > index 2017b3466612..45aee27ab6b1 100644 > --- a/drivers/gpu/drm/amd/amdgpu/a

Re: [PATCH 0/2] Recover from failure to probe GPU

On Tue, Dec 27, 2022 at 10:40 AM Alex Deucher wrote: > > On Sun, Dec 25, 2022 at 10:31 AM Christian König > wrote: > > > > Am 24.12.22 um 10:34 schrieb Thomas Zimmermann: > > > Hi > > > > > > Am 22.12.22 um 19:30 schrieb Mario Limonciello: > > >> One of the first thing that KMS drivers do during

Re: [PATCH 0/2] Recover from failure to probe GPU

On Sun, Dec 25, 2022 at 10:31 AM Christian König wrote: > > Am 24.12.22 um 10:34 schrieb Thomas Zimmermann: > > Hi > > > > Am 22.12.22 um 19:30 schrieb Mario Limonciello: > >> One of the first thing that KMS drivers do during initialization is > >> destroy the system firmware framebuffer by means

Re: [PATCH 0/2] Recover from failure to probe GPU

Am 24.12.22 um 10:34 schrieb Thomas Zimmermann: Hi Am 22.12.22 um 19:30 schrieb Mario Limonciello: One of the first thing that KMS drivers do during initialization is destroy the system firmware framebuffer by means of `drm_aperture_remove_conflicting_pci_framebuffers` This means that if for a

Re: [PATCH 0/2] Recover from failure to probe GPU

Hi Am 22.12.22 um 19:30 schrieb Mario Limonciello: One of the first thing that KMS drivers do during initialization is destroy the system firmware framebuffer by means of `drm_aperture_remove_conflicting_pci_framebuffers` This means that if for any reason the GPU failed to probe the user will b

Re: [PATCH 0/2] Recover from failure to probe GPU

On 12/22/22 13:41, Javier Martinez Canillas wrote: [adding Thomas Zimmermann to CC list] Hello Mario, Interesting case. On 12/22/22 19:30, Mario Limonciello wrote: One of the first thing that KMS drivers do during initialization is destroy the system firmware framebuffer by means of `drm_aper

Re: [PATCH 0/2] Recover from failure to probe GPU

[adding Thomas Zimmermann to CC list] Hello Mario, Interesting case. On 12/22/22 19:30, Mario Limonciello wrote: > One of the first thing that KMS drivers do during initialization is > destroy the system firmware framebuffer by means of > `drm_aperture_remove_conflicting_pci_framebuffers` > The

Re: [PATCH 0/2] Avoid creating acpi_video0 on desktop APUs

On Wed, Dec 07, 2022 at 10:32:05PM +0100, Hans de Goede wrote: > Hi, > > On 12/7/22 22:21, Limonciello, Mario wrote: > > On 12/7/2022 15:04, Hans de Goede wrote: > >> Hi All, > >> > >> Mario, thank you for working on this. > > > > Sure > > > > > >> > >> Note that the problem of the creating a n

Re: [PATCH 0/2] Avoid creating acpi_video0 on desktop APUs

Hi, On 12/7/22 22:21, Limonciello, Mario wrote: > On 12/7/2022 15:04, Hans de Goede wrote: >> Hi All, >> >> Mario, thank you for working on this. > > Sure > > >> >> Note that the problem of the creating a non functional acpi_video0 >> device happened before the overhaul too. >> >> The differenc

Re: [PATCH 0/2] Avoid creating acpi_video0 on desktop APUs

On 12/7/2022 15:04, Hans de Goede wrote: Hi All, Mario, thank you for working on this. Sure Note that the problem of the creating a non functional acpi_video0 device happened before the overhaul too. The difference is that now we have the in kernel GPU drivers all call acpi_video_register

Re: [PATCH 0/2] Avoid creating acpi_video0 on desktop APUs

Hi All, Mario, thank you for working on this. On 12/7/22 20:31, Mario Limonciello wrote: > In kernel 6.1 the backlight registration code was overhauled so that > at most one backlight device got registered. As part of this change > there was code added to cover the "nomodeset" case to still allow

Re: [PATCH 0/2] Use kfd_lock/unlock_pdd helpers

On 2022-08-24 13:38, Felix Kuehling wrote: > Do you mind squashing the two patches. It would make them easier to review > because it makes it easier to see that the same functions are using both. Will do. Regards, Daniel

Re: [PATCH 0/2] Use kfd_lock/unlock_pdd helpers

Do you mind squashing the two patches. It would make them easier to review because it makes it easier to see that the same functions are using both. Thanks,   Felix On 2022-08-24 16:01, Daniel Phillips wrote: Patch 1 adds kfd_lock_pdd_by_id and patch 2 adds kfd_unlock_pdd helpers, broken out

Re: [PATCH 0/2] Update AMDGPU glossary and MAINTAINERS

Am 15.04.22 um 21:50 schrieb Tales Lelo da Aparecida: I was handling the request from [0] and then I noticed that some AMD developers were missing from get_maintainers output due to the lack of a reference to their documentation in the MAINTAINERS file. Acked-by: Christian König [0] https:/

Re: [PATCH 0/2] remove DC_FP_* wrappers in dml files

On 03/30, Rodrigo Siqueira Jordao wrote: > > > On 2022-03-26 16:24, Melissa Wen wrote: > > From FPU documentation, developers must not use DC_FP_START/END in dml > > files, but invoke it when calling FPU-associated functions (isolated in > > dml folder). Therefore, the first patch renames dcn10_

Re: [PATCH 0/2] remove DC_FP_* wrappers in dml files

On 2022-03-26 16:24, Melissa Wen wrote: From FPU documentation, developers must not use DC_FP_START/END in dml files, but invoke it when calling FPU-associated functions (isolated in dml folder). Therefore, the first patch renames dcn10_validate_bandwidth in dml/calcs to dcn_ for generalizati

Re: [PATCH 0/2]

Hi Zhenneng, + some display folks First of all, thanks a lot for your patch. We had a similar patch in the past, but we had to revert it because we cannot simply enable DCN for ARM-based systems. You can refer to this commit message to get a better context: https://gitlab.freedesktop.org/ag

Re: [PATCH 0/2] Create shared array of power profile name strings

On 11/25/2021 7:49 AM, Darren Powell wrote: == Description == All the power profile modes use the same strings (or a subset of) Creating a public array of the strings will allow sharing rather than duplicating for each chip First patch only implements change for navi10 Second patch e

Re: [PATCH 0/2] v2 Add limit_type to (pptable_funcs)->set_power_limit signature

On 10/6/2021 10:36 AM, Darren Powell wrote: === Description === Add limit_type to (pptable_funcs)->set_power_limit signature plus small patch Fix for incorrect power limit readback in smu11 if POWER_SOURCE_DC v2 add check for SMU_DEFAULT_PPT_LIMIT dropped patch: Explicit initializati

Re: [PATCH 0/2] Use MTYPE_NC for coarse-grain remote memory

This series is Reviewed-by: Oak Zeng Regards, Oak On 2021-05-10, 7:36 PM, "amd-gfx on behalf of Felix Kuehling" wrote: These patches are the result of deliberations with multiple AMD SW and HW teams with the goal of improving Aldebaran performance and harmonizing the Arcturu

Re: [PATCH 0/2] drm/radeon: Fix off-by-one power_state index heap overwrite

On Mon, May 3, 2021 at 1:06 AM Kees Cook wrote: > > Hi, > > This is an attempt at fixing a bug[1] uncovered by the relocation of > the slab freelist pointer offset, as well as some related clean-ups. > > I don't have hardware to do runtime testing, but it builds. ;) > > -Kees > > [1] https://bugzi

Re: [PATCH 0/2] ensure alignment on CPU page for bo mapping

Applied. Thanks! Alex On Tue, Mar 30, 2021 at 12:21 PM Christian König wrote: > > Reviewed-by: Christian König for the entire > series. > > Alex will probably pick them up for the next feature pull request. > > Regards, > Christian. > > Am 30.03.21 um 17:33 schrieb Xℹ Ruoyao: > > In AMDGPU dri

Re: [PATCH 0/2] ensure alignment on CPU page for bo mapping

Reviewed-by: Christian König for the entire series. Alex will probably pick them up for the next feature pull request. Regards, Christian. Am 30.03.21 um 17:33 schrieb Xℹ Ruoyao: In AMDGPU driver, the bo mapping should always align to CPU page or the page table is corrupted. The first patch

Re: [PATCH 0/2] Fix for 64 bit divisions on 32-bit platform.

On Mon, Mar 1, 2021 at 12:06 PM Bindu Ramamurthy wrote: > > This patch set fixes 64 bit divisions for the display > synchronization code that caused a regression on 32-bit platform. > > Vladimir Stempen (2): > SWDEV-266369 - dc: Fix 64 bit divisions on 32 bit platforms by using > div64 API >

Re: [PATCH 0/2] drm/amd/display: Adjustments for dc_create()

On Sun, Dec 20, 2020 at 6:10 AM Markus Elfring wrote: > > From: Markus Elfring > Date: Sat, 19 Dec 2020 18:30:56 +0100 > > Two update suggestions were taken into account > from static source code analysis. > Applied. Thanks! Alex > Markus Elfring (2): > Return directly after a failed kzall

Re: [PATCH 0/2] amdgpu's drm_driver becomes const

On 2020-11-04 04:43, Daniel Vetter wrote: > On Tue, Nov 03, 2020 at 10:11:27PM -0500, Luben Tuikov wrote: >> Hi Daniel, >> >> These two patches follow up your latest >> DRM work to make definitions of struct drm_driver >> in DRM low-level drivers, constant, in amdgpu. >> >> This set doesn't descend

Re: [PATCH 0/2] amdgpu's drm_driver becomes const

On Tue, Nov 03, 2020 at 10:11:27PM -0500, Luben Tuikov wrote: > Hi Daniel, > > These two patches follow up your latest > DRM work to make definitions of struct drm_driver > in DRM low-level drivers, constant, in amdgpu. > > This set doesn't descend from my previous patch > "drm/amdgpu: Convert to

Re: [PATCH 0/2] Fixes to drm_sched_priority

+ dri-devel On Fri, Aug 14, 2020 at 3:14 PM Luben Tuikov wrote: > > Some fixes to enum drm_sched_priority which I'd wanted to do > since last year. > > For instance, renaming MAX to COUNT, as usually a maximum value > is a value which is part of the set of values, (e.g. a maxima of > a function),

RE: [PATCH 0/2] add correctable error query support on arcturus

[AMD Official Use Only - Internal Distribution Only] The series is: Reviewed-by: Tao Zhou > -Original Message- > From: Chen, Guchun > Sent: 2020年4月26日 17:17 > To: amd-gfx@lists.freedesktop.org; Zhang, Hawking > ; Li, Dennis ; Zhou1, Tao > ; Clements, John ; > Deucher, Alexander > Cc:

Re: [PATCH 0/2] drm/amd/display: dc_link: cleaning up some code style issues

Hi Rodrigo, On 02/27, Rodrigo Siqueira wrote: > Hi Melissa, > > First of all, thank you very much for this patchset; in general, > everything looks good to me. > > I noticed that your patchset does not apply because you made your > changes based on `drm-misc-next`; when you send patches to amdgp

Re: [PATCH 0/2] drm/amd/display: dc_link: cleaning up some code style issues

Hi Melissa, First of all, thank you very much for this patchset; in general, everything looks good to me. I noticed that your patchset does not apply because you made your changes based on `drm-misc-next`; when you send patches to amdgpu, use the following repository: git://people.freedesktop.o

RE: [PATCH 0/2] query edc counter for more mmhub sub-blocks of Acrturus

[AMD Official Use Only - Internal Distribution Only] Series is Reviewed-by: Hawking Zhang Regards, Hawking -Original Message- From: Dennis Li Sent: Sunday, January 19, 2020 11:03 To: amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Zhou1, Tao ; Zhang, Hawking ; Chen, Guchun Cc:

Re: [PATCH 0/2] Adjust AMD GPU ATS quirks

On Wed, Jan 15, 2020 at 03:20:18PM -0500, Alex Deucher wrote: > On Wed, Jan 15, 2020 at 3:17 PM Bjorn Helgaas wrote: > > On Wed, Jan 15, 2020 at 12:26:32PM -0500, Alex Deucher wrote: > > > On Wed, Jan 15, 2020 at 12:14 PM Bjorn Helgaas wrote: > > > > On Tue, Jan 14, 2020 at 05:41:44PM -0600, Bjor

Re: [PATCH 0/2] Adjust AMD GPU ATS quirks

On Wed, Jan 15, 2020 at 3:17 PM Bjorn Helgaas wrote: > > On Wed, Jan 15, 2020 at 12:26:32PM -0500, Alex Deucher wrote: > > On Wed, Jan 15, 2020 at 12:14 PM Bjorn Helgaas wrote: > > > On Tue, Jan 14, 2020 at 05:41:44PM -0600, Bjorn Helgaas wrote: > > > > On Tue, Jan 14, 2020 at 03:55:21PM -0500, A

Re: [PATCH 0/2] Adjust AMD GPU ATS quirks

On Wed, Jan 15, 2020 at 12:26:32PM -0500, Alex Deucher wrote: > On Wed, Jan 15, 2020 at 12:14 PM Bjorn Helgaas wrote: > > On Tue, Jan 14, 2020 at 05:41:44PM -0600, Bjorn Helgaas wrote: > > > On Tue, Jan 14, 2020 at 03:55:21PM -0500, Alex Deucher wrote: > > > > We've root caused the issue and clari

Re: [PATCH 0/2] Adjust AMD GPU ATS quirks

On Wed, Jan 15, 2020 at 12:14 PM Bjorn Helgaas wrote: > > On Tue, Jan 14, 2020 at 05:41:44PM -0600, Bjorn Helgaas wrote: > > On Tue, Jan 14, 2020 at 03:55:21PM -0500, Alex Deucher wrote: > > > We've root caused the issue and clarified the quirk. > > > This also adds a new quirk for a new GPU. > >

Re: [PATCH 0/2] Adjust AMD GPU ATS quirks

On Tue, Jan 14, 2020 at 05:41:44PM -0600, Bjorn Helgaas wrote: > On Tue, Jan 14, 2020 at 03:55:21PM -0500, Alex Deucher wrote: > > We've root caused the issue and clarified the quirk. > > This also adds a new quirk for a new GPU. > > > > Alex Deucher (2): > > pci: Clarify ATS quirk > > pci: ad

RE: [PATCH 0/2] Adjust AMD GPU ATS quirks

[AMD Public Use] > -Original Message- > From: Bjorn Helgaas > Sent: Tuesday, January 14, 2020 6:42 PM > To: Alex Deucher > Cc: amd-gfx@lists.freedesktop.org; linux-...@vger.kernel.org; Deucher, > Alexander > Subject: Re: [PATCH 0/2] Adjust AMD GPU ATS quirks >

  1   2   >