Re: [PATCH v3 01/20] drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector()
[AMD Official Use Only - Internal Distribution Only]
I'm fine with having these changes go through drm-misc.
Alex
From: Lipski, Mikita
Sent: Wednesday, April 21, 2021 10:23 AM
To: Lyude Paul ; dri-devel@lists.freedesktop.org
; intel-...@lists.freedesktop.org
; nouv...@lists.freedesktop.org
; amd-...@lists.freedesktop.org
; Ville Syrjälä ;
Jani Nikula ; Rodrigo Vivi
; Thomas Zimmermann ; Thierry
Reding
Cc: Wang, Chao-kai (Stylon) ; Lipski, Mikita
; Park, Chris ; Brol, Eryk
; Li, Sun peng (Leo) ; Lakha,
Bhawanpreet ; Lin, Wayne ;
Siqueira, Rodrigo ; open list
; Kazlauskas, Nicholas
; Somasundaram, Meenakshikumar
; David Airlie ; Pillai,
Aurabindo ; Daniel Vetter ; Bas
Nieuwenhuizen ; Deucher, Alexander
; Cornij, Nikola ; Wentland,
Harry ; Koenig, Christian
Subject: Re: [PATCH v3 01/20] drm/amdgpu: Add error handling to
amdgpu_dm_initialize_dp_connector()
Thanks for the change!
Reviewed-by: Mikita Lipski
On 2021-04-19 6:55 p.m., Lyude Paul wrote:
> While working on moving i2c device registration into drm_dp_aux_init() - I
> realized that in order to do so we need to make sure that drivers calling
> drm_dp_aux_init() handle any errors it could possibly return. In the
> process of doing that, I noticed that the majority of AMD's code for DP
> connector creation doesn't attempt to do any real error handling.
>
> So, let's fix this and also cleanup amdgpu_dm_initialize_dp_connector()
> while we're at it. This way we can handle the error codes from
> drm_dp_aux_init().
>
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++-
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 44 +++
> .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 6 +--
> 3 files changed, 45 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a0c8c41e4e57..fc5d315bbb05 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7608,10 +7608,9 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
>aconnector->i2c = i2c;
>res = i2c_add_adapter(&i2c->base);
> -
>if (res) {
>DRM_ERROR("Failed to register hw i2c %d\n", link->link_index);
> - goto out_free;
> + goto fail_free;
>}
>
>connector_type = to_drm_connector_type(link->connector_signal);
> @@ -7625,8 +7624,7 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
>if (res) {
>DRM_ERROR("connector_init failed\n");
> - aconnector->connector_id = -1;
> - goto out_free;
> + goto fail_id;
>}
>
>drm_connector_helper_add(
> @@ -7643,15 +7641,22 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>drm_connector_attach_encoder(
>&aconnector->base, &aencoder->base);
>
> - if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
> - || connector_type == DRM_MODE_CONNECTOR_eDP)
> - amdgpu_dm_initialize_dp_connector(dm, aconnector,
> link->link_index);
> -
> -out_free:
> - if (res) {
> - kfree(i2c);
> - aconnector->i2c = NULL;
> + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP) {
> + res = amdgpu_dm_initialize_dp_connector(dm, aconnector,
> link->link_index);
> + if (res)
> + goto fail_cleanup;
>}
> +
> + return 0;
> +fail_cleanup:
> + drm_connector_cleanup(&aconnector->base);
> +fail_id:
> + aconnector->connector_id = -1;
> +fail_free:
> + kfree(i2c);
> + aconnector->i2c = NULL;
> +
>return res;
> }
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 73cdb9fe981a..3dee9cce9c9e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -425,33 +425,39 @@ static const struct drm_dp_mst_topology_cbs dm_mst_cbs
> = {
>.add_connector = dm_dp_add_mst_connector,
> };
>
> -void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
> -struct amdgpu_dm_connector *aconnector,
> -int link_index
RE: Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board
[AMD Public Use] + Gustavo, amd-gfx > -Original Message- > From: Christian Zigotzky > Sent: Friday, April 30, 2021 8:00 AM > To: gustavo...@kernel.org; Deucher, Alexander > > Cc: R.T.Dickinson ; Darren Stevens zone.net>; mad skateman ; linuxppc-dev > ; Olof Johansson ; > Maling list - DRI developers ; Michel > Dänzer ; Christian Zigotzky > Subject: Radeon NI: GIT kernel with the nislands_smc commit doesn't > boot on a Freescale P5040 board and P.A.Semi Nemo board > > Hello, > > The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ > board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI > graphics cards (Cayman XT) [3] don't boot with the latest git kernel > anymore after the commit "drm/radeon/nislands_smc.h: Replace > one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE > branch" [4]. > This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5]. > > I bisected today [6]. > > Result: drm/radeon/nislands_smc.h: Replace one-element array with > flexible-array member in struct NISLANDS_SMC_SWSTATE branch > (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit. > > I was able to revert this commit [7] and after a new compiling, the > kernel boots without any problems on my AmigaOnes. > > After that I created a patch for reverting this commit for new git test > kernels. > [3] > > The kernel compiles and boots with this patch on my AmigaOnes. Please > find attached the kernel config files. > > Please check the first bad commit. > > Thanks, > Christian > > [1] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen. > wikipedia.org%2Fwiki%2FAmigaOne_X1000&data=04%7C01%7Calexand > er.deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd89 > 61fe4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnkn > own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > 1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PNSrApUdMrku20hH7dEKlJJ > TBi7Qp5JOkqpA4MvKqdE%3D&reserved=0 > [2] > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki. > a miga.org%2Findex.php%3Ftitle%3DX5000&data=04%7C01%7Calexander > .deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd8961f > e4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnknow > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLCJXVCI6Mn0%3D%7C1000&sdata=B8Uvhs25%2FP3RfnL1AgICN3Y4 > CEXeCE1yIoi3vvwvGto%3D&reserved=0 > [3] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu > m.hyperion- > entertainment.com%2Fviewtopic.php%3Ff%3D35%26t%3D4377&data= > 04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08d > 90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63755380 > 8670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TokXplD > Tvg3%2BZMPLCgR1fs%2BN2X9MIfLXLW67MAM2Qsk%3D&reserved=0 > [4] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. > k ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git% > 2Fcommit%2F%3Fid%3D434fb1e7444a2efc3a4ebd950c7f771ebfcffa31&d > ata=04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346 > b08d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375 > 53808670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JC > M4xvPEnWdckcTPbQ2Ujv%2FAiMMsFMzzl4Pr%2FRPlcMQ%3D&reserve > d=0 > [5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage - > drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev > user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw > root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci > -device usb- tablet -device virtio-keyboard-pci -smp 4 -vnc :1 [6] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu > m.hyperion- > entertainment.com%2Fviewtopic.php%3Fp%3D53074%23p53074&data > =04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08 > d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375538 > 08670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RXfSlY > A3bDEFas0%2Fk2vMWsl2l0nuhS2ecjZgSBLc%2Bs4%3D&reserved=0 > [7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/amd/pm: And destination bounds checking to struct copy
[Public]
> -Original Message-
> From: Koenig, Christian
> Sent: Monday, August 23, 2021 3:02 PM
> To: Kees Cook ; Lazar, Lijo
>
> Cc: Pan, Xinhui ; David Airlie ;
> Daniel Vetter ; Zhang, Hawking
> ; Xu, Feifei ; Gao, Likun
> ; Gu, JiaWei (Will) ; Quan,
> Evan ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; Deucher, Alexander
> ; Tuikov, Luben
> ; Grodzovsky, Andrey
> ; Li, Dennis ;
> Sundararaju, Sathishkumar ; Kim,
> Jonathan ; Wang, Kevin(Yang)
> ; Nieto, David M ; Feng,
> Kenneth ; Lee Jones ;
> Clements, John ; linux-ker...@vger.kernel.org;
> linux-harden...@vger.kernel.org
> Subject: Re: [PATCH] drm/amd/pm: And destination bounds checking to
> struct copy
>
> Am 23.08.21 um 16:23 schrieb Kees Cook:
> >
> > On August 22, 2021 11:28:54 PM PDT, "Christian König"
> wrote:
> >>
> >> Am 19.08.21 um 22:14 schrieb Kees Cook:
> >>> [...]
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> index 96e895d6be35..4605934a4fb7 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> @@ -1446,4 +1446,29 @@ static inline int amdgpu_in_reset(struct
> amdgpu_device *adev)
> >>>{
> >>> return atomic_read(&adev->in_gpu_reset);
> >>>}
> >>> +
> >>> +/**
> >>> + * memcpy_trailing - Copy the end of one structure into the middle
> >>> +of another
> >>> + *
> >>> + * @dst: Pointer to destination struct
> >>> + * @first_dst_member: The member name in @dst where the
> overwrite
> >>> +begins
> >>> + * @last_dst_member: The member name in @dst where the
> overwrite
> >>> +ends after
> >>> + * @src: Pointer to the source struct
> >>> + * @first_src_member: The member name in @src where the copy
> begins
> >>> + *
> >>> + */
> >>> +#define memcpy_trailing(dst, first_dst_member, last_dst_member,
> \
> >>> + src, first_src_member) \
> >> Please don't add a function like this into amdgpu.h, especially when
> >> it is only used by the SMU code.
> > Sure, I'm happy to move it. It wasn't clear to me which headers were
> considered "immutable". Which header should I put this in?
>
> I think amdgpu_smuio.h, but I'm not 100% sure. Alex do you have a better
> idea?
>
No, that's for the SMUIO callbacks for the IP block. Please use
drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
Alex
> We don't want to put anything new into amdgpu.h any more since this is
> basically only a legacy leftover.
>
> Thanks,
> Christian.
>
> >
> >> And please give it an amdgpu_ prefix so that we are not confusing it
> >> with a core function.
> > Sure, I will include that.
> >
> >> Apart from that looks good to me.
> > Thanks!
> >
> > -Kees
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
[AMD Official Use Only - Internal Distribution Only]
+ Leo
From: amd-gfx on behalf of Christian
König
Sent: Friday, March 19, 2021 10:08 AM
To: Liu, Leo ; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: stop warning on TT shrinker failure
Don't print a warning when we fail to allocate a page for swapping things out.
Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_tt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2f0833c98d2c..86fa3e82dacc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -369,7 +369,7 @@ static unsigned long ttm_tt_shrinker_scan(struct shrinker
*shrink,
};
int ret;
- ret = ttm_bo_swapout(&ctx, GFP_NOFS);
+ ret = ttm_bo_swapout(&ctx, GFP_KERNEL | __GFP_NOWARN);
return ret < 0 ? SHRINK_EMPTY : ret;
}
@@ -389,10 +389,13 @@ static unsigned long ttm_tt_shrinker_count(struct
shrinker *shrink,
static int ttm_tt_debugfs_shrink_show(struct seq_file *m, void *data)
{
struct shrink_control sc = { .gfp_mask = GFP_KERNEL };
+ unsigned int flags;
fs_reclaim_acquire(GFP_KERNEL);
+ flags = memalloc_nofs_save();
seq_printf(m, "%lu/%lu\n", ttm_tt_shrinker_count(&mm_shrinker, &sc),
ttm_tt_shrinker_scan(&mm_shrinker, &sc));
+ memalloc_nofs_restore(flags);
fs_reclaim_release(GFP_KERNEL);
return 0;
--
2.25.1
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Calexander.deucher%40amd.com%7C70aef4974dfe465a06a308d8eae08eb3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637517597539809703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kvyinv9FPakf76dvXF0pzfeCpclxAo3L4Ufkf6%2B6%2FCc%3D&reserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [pull] amdgpu, amdkfd drm-next-5.12
[AMD Public Use] > -Original Message- > From: Kuehling, Felix > Sent: Friday, January 29, 2021 5:33 PM > To: Alex Deucher ; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > airl...@gmail.com; daniel.vet...@ffwll.ch > Cc: Deucher, Alexander ; Pan, Xinhui > ; Koenig, Christian > Subject: Re: [pull] amdgpu, amdkfd drm-next-5.12 > > Am 2021-01-29 um 5:28 p.m. schrieb Alex Deucher: > > drm/amdgpu: Make contiguous pinning optional > > This one needs a follow-up fix, as it breaks pinning in GTT. Xinhui should > have > the fix ready very soon. You may want to hold this back until the fix lands. Ok. Ignore this PR for now. I'll send an updated one next week when the fix lands. Thanks, Alex > > Regards, > Felix > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
[AMD Official Use Only - Internal Distribution Only]
Good question. I think push it to drm-misc-next for upstream. We can carry it
internally in amd-staging-drm-next for internal testing and I can coordinate
with drm-next. I think the amdgpu changes are pretty straightforward, so
shouldn't be too hard keep the merge straight. I dunno.
Alex
From: Christian König
Sent: Friday, February 5, 2021 4:58 AM
To: Liu, Leo ; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.org
; Deucher, Alexander
Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
Alex how do we want to merge this?
I've just pushed the first patch to drm-misc-next since that needed a
rebase because it touches other drivers as well.
But the rest is really AMD specific and I'm not sure if the dependent
stuff is already in there as well.
So if I push it to drm-misc-next you will probably need to merge and if
I push it to amd-staging-drm-next somebody else might need to merge when
drm-misc-next is merged.
Ideas?
Christian.
Am 04.02.21 um 19:34 schrieb Leo Liu:
> The series are:
>
> Reviewed-and-Tested-by: Leo Liu
>
>
> On 2021-02-04 9:44 a.m., Christian König wrote:
>> The VCN3 instances can do both decode as well as encode.
>>
>> Share the scheduler load balancing score and remove fixing encode to
>> only the second instance.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +
>> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 11 +++
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> index 13aa417f6be7..d10bc4f0a05f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> @@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
>> void*saved_bo;
>> struct amdgpu_ringring_dec;
>> struct amdgpu_ringring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
>> +atomic_tsched_score;
>> struct amdgpu_irq_srcirq;
>> struct amdgpu_vcn_regexternal;
>> struct amdgpu_bo*dpg_sram_bo;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> index 239a4eb52c61..b33f513fd2ac 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> @@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
>> for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
>> volatile struct amdgpu_fw_shared *fw_shared;
>> +
>> if (adev->vcn.harvest_config & (1 << i))
>> continue;
>> @@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
>> if (r)
>> return r;
>> +atomic_set(&adev->vcn.inst[i].sched_score, 0);
>> +
>> ring = &adev->vcn.inst[i].ring_dec;
>> ring->use_doorbell = true;
>> if (amdgpu_sriov_vf(adev)) {
>> @@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
>> ring->no_scheduler = true;
>> sprintf(ring->name, "vcn_dec_%d", i);
>> r = amdgpu_ring_init(adev, ring, 512,
>> &adev->vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + &adev->vcn.inst[i].sched_score);
>> if (r)
>> return r;
>> @@ -227,11 +231,10 @@ static int vcn_v3_0_sw_init(void *handle)
>> } else {
>> ring->doorbell_index =
>> (adev->doorbell_index.vcn.vcn_ring0_1 << 1) + 2 + j + 8 * i;
>> }
>> -if (adev->asic_type == CHIP_SIENNA_CICHLID && i != 1)
>> -ring->no_scheduler = true;
>> sprintf(ring->name, "vcn_enc_%d.%d", i, j);
>> r = amdgpu_ring_init(adev, ring, 512,
>> &adev->vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + &adev->vcn.inst[i].sched_score);
>> if (r)
>> return r;
>> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
[AMD Official Use Only - Internal Distribution Only]
I think the virt team probably wants it in amd-staging-drm-next so they can
start testing it. 5.12 is getting pretty tight. I'm not sure if there will be
another drm-misc PR or not for 5.12. Rebasing amd-staging-drm-next is turning
into a challenge. there are always a lot of regressions. I guess that is an
argument to rebase more often so we get better internal testing of it.
Alex
From: Koenig, Christian
Sent: Friday, February 5, 2021 9:53 AM
To: Deucher, Alexander ; Liu, Leo ;
amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
The alternative is to wait till drm-misc-next is merged into drm-next, then
rebase amd-staging-drm-next on top of that (or directly drm-misc-next) and push
then.
Would give us at least a clean history. Question is rather if we want it in
5.12?
Christian.
Am 05.02.21 um 15:50 schrieb Deucher, Alexander:
[AMD Official Use Only - Internal Distribution Only]
Good question. I think push it to drm-misc-next for upstream. We can carry it
internally in amd-staging-drm-next for internal testing and I can coordinate
with drm-next. I think the amdgpu changes are pretty straightforward, so
shouldn't be too hard keep the merge straight. I dunno.
Alex
From: Christian König
<mailto:ckoenig.leichtzumer...@gmail.com>
Sent: Friday, February 5, 2021 4:58 AM
To: Liu, Leo <mailto:leo@amd.com>;
amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org>
<mailto:amd-...@lists.freedesktop.org>;
dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org>
<mailto:dri-devel@lists.freedesktop.org>;
Deucher, Alexander <mailto:alexander.deuc...@amd.com>
Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
Alex how do we want to merge this?
I've just pushed the first patch to drm-misc-next since that needed a
rebase because it touches other drivers as well.
But the rest is really AMD specific and I'm not sure if the dependent
stuff is already in there as well.
So if I push it to drm-misc-next you will probably need to merge and if
I push it to amd-staging-drm-next somebody else might need to merge when
drm-misc-next is merged.
Ideas?
Christian.
Am 04.02.21 um 19:34 schrieb Leo Liu:
> The series are:
>
> Reviewed-and-Tested-by: Leo Liu <mailto:leo@amd.com>
>
>
> On 2021-02-04 9:44 a.m., Christian König wrote:
>> The VCN3 instances can do both decode as well as encode.
>>
>> Share the scheduler load balancing score and remove fixing encode to
>> only the second instance.
>>
>> Signed-off-by: Christian König
>> <mailto:christian.koe...@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +
>> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 11 +++
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> index 13aa417f6be7..d10bc4f0a05f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> @@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
>> void*saved_bo;
>> struct amdgpu_ringring_dec;
>> struct amdgpu_ringring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
>> +atomic_tsched_score;
>> struct amdgpu_irq_srcirq;
>> struct amdgpu_vcn_regexternal;
>> struct amdgpu_bo*dpg_sram_bo;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> index 239a4eb52c61..b33f513fd2ac 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> @@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
>> for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
>> volatile struct amdgpu_fw_shared *fw_shared;
>> +
>> if (adev->vcn.harvest_config & (1 << i))
>> continue;
>> @@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
>> if (r)
>> return r;
>> +atomic_set(&adev->vcn.inst[i].sched_score, 0);
>> +
>> ring = &adev->vcn.inst[i].ring_dec;
>> ring->use_doorbell = true;
>> if (amdgpu_sriov_vf(adev)) {
>> @@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
>> ring->no_scheduler = true;
>> sprintf(ring->name, "vcn_dec_%d", i);
>>
RE: [PATCH 1/2] drm/amd/display: Fix the brightness read via aux
[AMD Public Use] > -Original Message- > From: Takashi Iwai > Sent: Saturday, February 6, 2021 7:29 AM > To: Alex Deucher > Cc: Deucher, Alexander ; Koenig, Christian > ; Li, Sun peng (Leo) ; > Wentland, Harry ; Maling list - DRI developers > ; amd-gfx list g...@lists.freedesktop.org> > Subject: Re: [PATCH 1/2] drm/amd/display: Fix the brightness read via aux > > On Fri, 05 Feb 2021 17:36:44 +0100, > Alex Deucher wrote: > > > > On Wed, Feb 3, 2021 at 7:42 AM Takashi Iwai wrote: > > > > > > The current code tries to read the brightness value via > > > dc_link_get_backlight_level() no matter whether it's controlled via > > > aux or not, and this results in a bogus value returned. > > > Fix it to read the current value via > > > dc_link_get_backlight_level_nits() for the aux. > > > > > > BugLink: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu > > > > gzilla.opensuse.org%2Fshow_bug.cgi%3Fid%3D1180749&data=04%7C01 > %7 > > > > Calexander.deucher%40amd.com%7Ce5579cfe56f74b572f1508d8ca9ad0ac%7 > C3d > > > > d8961fe4884e608e11a82d994e183d%7C0%7C0%7C637482113562863043%7CU > nknow > > > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > Wwi > > > > LCJXVCI6Mn0%3D%7C1000&sdata=HVtqM2r6oxSWd3XGGQZotO8wrvM > qCTcwfq1L > > > 2%2FeCmSE%3D&reserved=0 > > > BugLink: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > > > tlab.freedesktop.org%2Fdrm%2Famd%2F- > %2Fissues%2F1438&data=04%7C0 > > > > 1%7Calexander.deucher%40amd.com%7Ce5579cfe56f74b572f1508d8ca9ad0 > ac%7 > > > > C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637482113562863043% > 7CUnk > > > > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1ha > > > > WwiLCJXVCI6Mn0%3D%7C1000&sdata=TdYgwNJ%2FvkuoDLNb9ATFb1P > yznlp%2F > > > P8TLuYSR%2BVkNqY%3D&reserved=0 > > > Signed-off-by: Takashi Iwai > > > > This looks fine to me. FWIW, I have a similar patch set here: > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.f > > > reedesktop.org%2F~agd5f%2Flinux%2Flog%2F%3Fh%3Dbacklight_wip& > data= > > > 04%7C01%7Calexander.deucher%40amd.com%7Ce5579cfe56f74b572f1508d8 > ca9ad0 > > > ac%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637482113562863 > 043%7CU > > > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > 6Ik1ha > > > WwiLCJXVCI6Mn0%3D%7C1000&sdata=aoMSY0nvHjrLocUPJtdgckqIH7x > LUPbwpH0 > > ZjhuuJO8%3D&reserved=0 > > I'm fine to scratch mine as long as the issue gets fixed :) > > FWIW, the biggest problem so far was the aux channel backlight didn't work > as expected, the actual backlight isn't changed by the backlight sysfs write. > (And the sysfs read gives a bogus value, but it's not the cause of the non- > working backlight control.) > > Does the aux channel backlight really work with the current code? > Or is this rather a device-specific issue (e.g. broken BIOS) and we might need > to come up with a deny list or such? > @Kazlauskas, Nicholas, @Siqueira, Rodrigo Has there been any progress on the backlight fixes? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/display: Fix unused variable warning
[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Alex Deucher From: Wei Yongjun Sent: Wednesday, February 24, 2021 4:49 AM To: Hulk Robot ; Wentland, Harry ; Li, Sun peng (Leo) ; Deucher, Alexander ; Koenig, Christian ; David Airlie ; Daniel Vetter ; Kazlauskas, Nicholas ; Siqueira, Rodrigo ; Pillai, Aurabindo ; Wang, Chao-kai (Stylon) ; Lakha, Bhawanpreet ; Bas Nieuwenhuizen ; Simon Ser ; Zhuo, Qingqing Cc: Wei Yongjun ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org Subject: [PATCH -next] drm/amd/display: Fix unused variable warning GCC reports the following warning with W=1: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5439:33: warning: unused variable 'dm' [-Wunused-variable] 5439 | struct amdgpu_display_manager *dm = &adev->dm; | ^~ This variable only used when CONFIG_DRM_AMD_DC_DCN is set, this commit fix the warning. Reported-by: Hulk Robot Signed-off-by: Wei Yongjun --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index e24a13fd2730..bda8d5f4e56a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5436,8 +5436,8 @@ static inline int dm_set_vblank(struct drm_crtc *crtc, bool enable) struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc); struct amdgpu_device *adev = drm_to_adev(crtc->dev); struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state); - struct amdgpu_display_manager *dm = &adev->dm; #if defined(CONFIG_DRM_AMD_DC_DCN) + struct amdgpu_display_manager *dm = &adev->dm; unsigned long flags; #endif int rc = 0; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 04/16] drm/amdkfd: Split kfd suspend from devie exit
[AMD Public Use]
Typo in the subject: devie > device
Alex
From: Grodzovsky, Andrey
Sent: Monday, May 10, 2021 12:36 PM
To: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ;
linux-...@vger.kernel.org ;
ckoenig.leichtzumer...@gmail.com ;
daniel.vet...@ffwll.ch ; Wentland, Harry
Cc: ppaala...@gmail.com ; Deucher, Alexander
; gre...@linuxfoundation.org
; helg...@kernel.org ;
Kuehling, Felix ; Grodzovsky, Andrey
Subject: [PATCH v6 04/16] drm/amdkfd: Split kfd suspend from devie exit
Helps to expdite HW related stuff to amdgpu_pci_remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 5f6696a3c778..2b06dee9a0ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -170,7 +170,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
}
}
-void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev)
+void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev)
{
if (adev->kfd.dev) {
kgd2kfd_device_exit(adev->kfd.dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 14f68c028126..f8e10af99c28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -127,7 +127,7 @@ void amdgpu_amdkfd_interrupt(struct amdgpu_device *adev,
const void *ih_ring_entry);
void amdgpu_amdkfd_device_probe(struct amdgpu_device *adev);
void amdgpu_amdkfd_device_init(struct amdgpu_device *adev);
-void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev);
+void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev);
int amdgpu_amdkfd_submit_ib(struct kgd_dev *kgd, enum kgd_engine_type engine,
uint32_t vmid, uint64_t gpu_addr,
uint32_t *ib_cmd, uint32_t ib_len);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 357b9bf62a1c..ab6d2a43c9a3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -858,10 +858,11 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
return kfd->init_complete;
}
+
+
void kgd2kfd_device_exit(struct kfd_dev *kfd)
{
if (kfd->init_complete) {
- kgd2kfd_suspend(kfd, false);
device_queue_manager_uninit(kfd->dqm);
kfd_interrupt_exit(kfd);
kfd_topology_remove_device(kfd);
--
2.25.1
Re: [PATCH] drm/amdgpu: Unmap all MMIO mappings
[Public]
Reviewed-by: Alex Deucher
From: Grodzovsky, Andrey
Sent: Tuesday, May 18, 2021 10:01 AM
To: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ;
linux-...@vger.kernel.org ;
ckoenig.leichtzumer...@gmail.com ;
daniel.vet...@ffwll.ch ; Wentland, Harry
Cc: ppaala...@gmail.com ; Deucher, Alexander
; gre...@linuxfoundation.org
; helg...@kernel.org ;
Kuehling, Felix
Subject: Re: [PATCH] drm/amdgpu: Unmap all MMIO mappings
Ping
Andrey
On 2021-05-17 3:31 p.m., Andrey Grodzovsky wrote:
> Access to those must be prevented post pci_remove
>
> v6: Drop BOs list, unampping VRAM BAR is enough.
> v8:
> Add condition of xgmi.connected_to_cpu to MTTR
> handling and remove MTTR handling from the old place.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 +++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4
> 3 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index f7cca25c0fa0..8b50315d1fe1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3666,6 +3666,27 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>return r;
> }
>
> +static void amdgpu_device_unmap_mmio(struct amdgpu_device *adev)
> +{
> + /* Clear all CPU mappings pointing to this device */
> + unmap_mapping_range(adev->ddev.anon_inode->i_mapping, 0, 0, 1);
> +
> + /* Unmap all mapped bars - Doorbell, registers and VRAM */
> + amdgpu_device_doorbell_fini(adev);
> +
> + iounmap(adev->rmmio);
> + adev->rmmio = NULL;
> + if (adev->mman.aper_base_kaddr)
> + iounmap(adev->mman.aper_base_kaddr);
> + adev->mman.aper_base_kaddr = NULL;
> +
> + /* Memory manager related */
> + if (!adev->gmc.xgmi.connected_to_cpu) {
> + arch_phys_wc_del(adev->gmc.vram_mtrr);
> + arch_io_free_memtype_wc(adev->gmc.aper_base,
> adev->gmc.aper_size);
> + }
> +}
> +
> /**
>* amdgpu_device_fini - tear down the driver
>*
> @@ -3712,6 +3733,8 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
>amdgpu_device_ip_fini_early(adev);
>
>amdgpu_gart_dummy_page_fini(adev);
> +
> + amdgpu_device_unmap_mmio(adev);
> }
>
> void amdgpu_device_fini_sw(struct amdgpu_device *adev)
> @@ -3739,9 +3762,6 @@ void amdgpu_device_fini_sw(struct amdgpu_device *adev)
>}
>if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
>vga_client_register(adev->pdev, NULL, NULL, NULL);
> - iounmap(adev->rmmio);
> - adev->rmmio = NULL;
> - amdgpu_device_doorbell_fini(adev);
>
>if (IS_ENABLED(CONFIG_PERF_EVENTS))
>amdgpu_pmu_fini(adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 0adffcace326..8eabe3c9ad17 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -1107,10 +1107,6 @@ int amdgpu_bo_init(struct amdgpu_device *adev)
> void amdgpu_bo_fini(struct amdgpu_device *adev)
> {
>amdgpu_ttm_fini(adev);
> - if (!adev->gmc.xgmi.connected_to_cpu) {
> - arch_phys_wc_del(adev->gmc.vram_mtrr);
> - arch_io_free_memtype_wc(adev->gmc.aper_base,
> adev->gmc.aper_size);
> - }
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 0d54e70278ca..58ad2fecc9e3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1841,10 +1841,6 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
>amdgpu_bo_free_kernel(&adev->mman.discovery_memory, NULL, NULL);
>amdgpu_ttm_fw_reserve_vram_fini(adev);
>
> - if (adev->mman.aper_base_kaddr)
> - iounmap(adev->mman.aper_base_kaddr);
> - adev->mman.aper_base_kaddr = NULL;
> -
>amdgpu_vram_mgr_fini(adev);
>amdgpu_gtt_mgr_fini(adev);
>ttm_range_man_fini(&adev->mman.bdev, AMDGPU_PL_GDS);
>
RE: [drm-rerere PATCH] nightly.conf: drop amd branches from drm-tip
[AMD Public Use] > -Original Message- > From: Jani Nikula > Sent: Wednesday, May 19, 2021 4:50 AM > To: dim-to...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; > jani.nik...@intel.com; Deucher, Alexander > ; Koenig, Christian > ; Pan; Pan, Xinhui ; > Daniel Vetter > Subject: [drm-rerere PATCH] nightly.conf: drop amd branches from drm-tip > > We've had a stale repo for amd in drm-tip since around v4.15 i.e. for more > than three years. Nobody seems to notice or care. Drop the amd branches > from drm-tip. > > Having the current amd branches in drm-tip would be nice to have, if only to > have a common drm integration tree. However, maintaining that has a cost > due to the inevitable conflicts. We can add the branches back if and when > there's interest in sharing the burden. > > Cc: Alex Deucher > Cc: Christian König > Cc: Pan, Xinhui > Cc: Daniel Vetter > Signed-off-by: Jani Nikula Reviewed-by: Alex Deucher > --- > nightly.conf | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/nightly.conf b/nightly.conf index 9211550ef75c..35fb1d9ba600 > 100644 > --- a/nightly.conf > +++ b/nightly.conf > @@ -40,12 +40,6 @@ git://anongit.freedesktop.org/drm-misc > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > misc&data=04%7C01%7Calexander.deucher%40amd.com%7C5903896cf > 2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7 > C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am > p;sdata=espN%2BoIX9SjLh2Py%2FkqlVsi0p9Ru%2Fet2M11XWqJ5eUQ%3D&a > mp;reserved=0 > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > misc.git&data=04%7C01%7Calexander.deucher%40amd.com%7C590389 > 6cf2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0 > %7C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=E5cwRH0Pr9JkIfIMNkNzjlLn5hN6k0inxBkk%2Bwhd1lk%3D&r > eserved=0 > " > -drm_tip_repos[drm-amd]=" > -ssh://git.freedesktop.org/git/drm/drm-amd > -git://anongit.freedesktop.org/drm/drm-amd > - > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > amd&data=04%7C01%7Calexander.deucher%40amd.com%7C5903896cf > 2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7 > C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am > p;sdata=1kQe4t89CyANqRhNUpQ2RP3Ndz7A3sdd%2FiWZ7FmKHM4%3D&a > mp;reserved=0 > - > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > amd.git&data=04%7C01%7Calexander.deucher%40amd.com%7C590389 > 6cf2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0 > %7C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=vVqMWMbdJFHJW8j09tn1m7ItGSL0RmfeDbJZFWoYBf4%3D&am > p;reserved=0 > -" > drm_tip_repos[drm]=" > ssh://git.freedesktop.org/git/drm/drm > git://anongit.freedesktop.org/drm/drm > @@ -76,17 +70,14 @@ drm_tip_config=( > "drmdrm-fixes" > "drm-misc drm-misc-fixes" > "drm-intel drm-intel-fixes" > - "drm-amddrm-amd-fixes" > > "drmdrm-next" > "drm-misc drm-misc-next-fixes" > "drm-intel drm-intel-next-fixes" > - "drm-amddrm-amd-next-fixes" > > "drm-misc drm-misc-next" > "drm-intel drm-intel-next" > "drm-intel drm-intel-gt-next" > - "drm-amddrm-amd-next" > > "sound-upstream for-linus" > "sound-upstream for-next" > -- > 2.20.1
RE: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
[AMD Public Use] > -Original Message- > From: Greg KH > Sent: Tuesday, November 3, 2020 1:53 AM > To: Koenig, Christian > Cc: Alex Deucher ; Deepak R Varma > ; David Airlie ; LKML ker...@vger.kernel.org>; Maling list - DRI developers de...@lists.freedesktop.org>; Melissa Wen ; > amd-gfx list ; Daniel Vetter > ; Daniel Vetter ; Deucher, > Alexander > Subject: Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or > NULL > > On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote: > > Am 02.11.20 um 20:43 schrieb Alex Deucher: > > > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma > wrote: > > > > Initializing global variable to 0 or NULL is not necessary and > > > > should be avoided. Issue reported by checkpatch script as: > > > > ERROR: do not initialise globals to 0 (or NULL). > > > I agree that this is technically correct, but a lot of people don't > > > seem to know that so we get a lot of comments about this code for > > > the variables that are not explicitly set. Seems less confusing to > > > initialize them even if it not necessary. I don't have a > > > particularly strong opinion on it however. > > > > Agree with Alex. > > > > Especially for the module parameters we should have a explicit init > > value for documentation purposes, even when it is 0. > > Why is this one tiny driver somehow special compared to the entire rest of > the kernel? (hint, it isn't...) > > Please follow the normal coding style rules, there's no reason to ignore them > unless you like to constantly reject patches like this that get sent to you. > I'll apply the patch, but as a data point, this is the first time I've gotten a patch to make this change. I get several bug reports or patches every year to explicitly set values to global variables because users assume they are not initialized. So it will always be a trade off as to which patches you want to NACK. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 02/11] drm/amdgpu: Move scheduler init to after XGMI is ready
[Public]
If it applies cleanly, feel free to drop it in. I'll drop those patches for
drm-next since they are already in drm-misc.
Alex
From: amd-gfx on behalf of Andrey
Grodzovsky
Sent: Thursday, February 24, 2022 11:24 AM
To: Chen, JingWen ; Christian König
; dri-devel@lists.freedesktop.org
; amd-...@lists.freedesktop.org
Cc: Liu, Monk ; Chen, Horace ; Lazar,
Lijo ; Koenig, Christian ;
dan...@ffwll.ch
Subject: Re: [RFC v4 02/11] drm/amdgpu: Move scheduler init to after XGMI is
ready
No because all the patch-set including this patch was landed into
drm-misc-next and will reach amd-staging-drm-next on the next upstream
rebase i guess.
Andrey
On 2022-02-24 01:47, JingWen Chen wrote:
> Hi Andrey,
>
> Will you port this patch into amd-staging-drm-next?
>
> on 2/10/22 2:06 AM, Andrey Grodzovsky wrote:
>> All comments are fixed and code pushed. Thanks for everyone
>> who helped reviewing.
>>
>> Andrey
>>
>> On 2022-02-09 02:53, Christian König wrote:
>>> Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the entire XGMI hive and so the
reset wq is per hive.
Signed-off-by: Andrey Grodzovsky
>>> One more comment below, with that fixed Reviewed-by: Christian König
>>> .
>>>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 45 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 34 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +
3 files changed, 51 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9704b0e1fd82..00123b0013d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2287,6 +2287,47 @@ static int amdgpu_device_fw_loading(struct
amdgpu_device *adev)
return r;
}
+static int amdgpu_device_init_schedulers(struct amdgpu_device *adev)
+{
+long timeout;
+int r, i;
+
+for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+struct amdgpu_ring *ring = adev->rings[i];
+
+/* No need to setup the GPU scheduler for rings that don't need
it */
+if (!ring || ring->no_scheduler)
+continue;
+
+switch (ring->funcs->type) {
+case AMDGPU_RING_TYPE_GFX:
+timeout = adev->gfx_timeout;
+break;
+case AMDGPU_RING_TYPE_COMPUTE:
+timeout = adev->compute_timeout;
+break;
+case AMDGPU_RING_TYPE_SDMA:
+timeout = adev->sdma_timeout;
+break;
+default:
+timeout = adev->video_timeout;
+break;
+}
+
+r = drm_sched_init(&ring->sched, &amdgpu_sched_ops,
+ ring->num_hw_submission, amdgpu_job_hang_limit,
+ timeout, adev->reset_domain.wq, ring->sched_score,
ring->name);
+if (r) {
+DRM_ERROR("Failed to create scheduler on ring %s.\n",
+ ring->name);
+return r;
+}
+}
+
+return 0;
+}
+
+
/**
* amdgpu_device_ip_init - run init for hardware IPs
*
@@ -2419,6 +2460,10 @@ static int amdgpu_device_ip_init(struct
amdgpu_device *adev)
}
}
+r = amdgpu_device_init_schedulers(adev);
+if (r)
+goto init_failed;
+
/* Don't init kfd if whole hive need to be reset during init */
if (!adev->gmc.xgmi.pending_reset)
amdgpu_amdkfd_device_init(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 45977a72b5dd..fa302540c69a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -457,8 +457,6 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring
*ring,
atomic_t *sched_score)
{
struct amdgpu_device *adev = ring->adev;
-long timeout;
-int r;
if (!adev)
return -EINVAL;
@@ -478,36 +476,12 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring
*ring,
spin_lock_init(&ring->fence_drv.lock);
ring->fence_drv.fences = kcalloc(num_hw_submission * 2, sizeof(void
*),
GFP_KERNEL);
-if (!ring->fence_drv.fences)
-return -ENOMEM;
-/* No need to setup the GPU scheduler f
Re: [PATCH] drm/amd/display: Fix memory leak
[Public]
Applied. Thanks!
From: Wentland, Harry
Sent: Friday, January 21, 2022 2:03 PM
To: Yongzhi Liu ; Li, Sun peng (Leo) ;
Siqueira, Rodrigo ; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; airl...@linux.ie ;
dan...@ffwll.ch ; Lipski, Mikita ; Lin,
Wayne ; Kazlauskas, Nicholas ;
Zuo, Jerry ; anson.ja...@amd.com ;
eryk.b...@amd.com ; Pillai, Aurabindo
; Das, Nirmoy
Cc: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amd/display: Fix memory leak
On 2022-01-21 06:26, Yongzhi Liu wrote:
> [why]
> Resource release is needed on the error handling path
> to prevent memory leak.
>
> [how]
> Fix this by adding kfree on the error handling path.
>
> Signed-off-by: Yongzhi Liu
Reviewed-by: Harry Wentland
Harry
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 80
> --
> 1 file changed, 60 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index ded64d0..e463d46 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -227,8 +227,10 @@ static ssize_t dp_link_settings_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -389,8 +391,10 @@ static ssize_t dp_phy_settings_read(struct file *f, char
> __user *buf,
>break;
>
>r = put_user((*(rd_buf + result)), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1359,8 +1363,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1376,8 +1382,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1546,8 +1554,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
> char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1563,8 +1573,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1731,8 +1743,10 @@ static ssize_t dp_dsc_slice_height_read(struct file
> *f, char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1748,8 +1762,10 @@ static ssize_t dp_dsc_slice_height_read(struct file
> *f, char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1912,8 +1928,10 @@ static ssize_t dp_dsc_bits_per_pixel_read(struct file
> *f, char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
Re: [PATCH v2 1/28] drm/amdgpu: fix that issue that the number of the crtc of the 3250c is not correct
[Public]
Reviewed-by: Alex Deucher
From: RyanLin
Sent: Thursday, January 27, 2022 10:47 PM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Deucher, Alexander ; Koenig,
Christian ; david1.z...@amd.com
; airl...@linux.ie ; dan...@ffwll.ch
; seanp...@chromium.org ;
b...@basnieuwenhuizen.nl ; Kazlauskas, Nicholas
; sas...@kernel.org ;
markyac...@google.com ; victorchengchi...@amd.com
; ching-shih...@amd.corp-partner.google.com
; Siqueira, Rodrigo
; ddavenp...@chromium.org ;
amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org ; Li, Leon
Cc: Lin, Tsung-hua (Ryan)
Subject: [PATCH v2 1/28] drm/amdgpu: fix that issue that the number of the crtc
of the 3250c is not correct
v2:
- remove unnecessary comments and Id
[Why]
External displays take priority over internal display when there are fewer
display controllers than displays.
[How]
The root cause is because of that number of the crtc is not correct.
The number of the crtc on the 3250c is 3, but on the 3500c is 4.
>From the source code, we can see that number of the crtc has been fixed at 4.
Needs to set the num_crtc to 3 for 3250c platform.
Signed-off-by: RyanLin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 40c91b448f7d..455a2c45e8cd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2738,9 +2738,15 @@ static int dm_early_init(void *handle)
break;
#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
case CHIP_RAVEN:
- adev->mode_info.num_crtc = 4;
- adev->mode_info.num_hpd = 4;
- adev->mode_info.num_dig = 4;
+ if (adev->rev_id >= 8) {
+ adev->mode_info.num_crtc = 3;
+ adev->mode_info.num_hpd = 3;
+ adev->mode_info.num_dig = 3;
+ } else {
+ adev->mode_info.num_crtc = 4;
+ adev->mode_info.num_hpd = 4;
+ adev->mode_info.num_dig = 4;
+ }
break;
#endif
#if defined(CONFIG_DRM_AMD_DC_DCN2_0)
--
2.25.1
RE: [PATCH v4 00/10] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping
[Public] > -Original Message- > From: Sierra Guiza, Alejandro (Alex) > Sent: Thursday, January 27, 2022 6:21 PM > To: Andrew Morton > Cc: Kuehling, Felix ; linux...@kvack.org; > rcampb...@nvidia.com; linux-e...@vger.kernel.org; linux- > x...@vger.kernel.org; amd-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; h...@lst.de; j...@nvidia.com; > jgli...@redhat.com; apop...@nvidia.com; wi...@infradead.org; Deucher, > Alexander > Subject: Re: [PATCH v4 00/10] Add MEMORY_DEVICE_COHERENT for > coherent device memory mapping > > Andrew, > We're somehow new on this procedure. Are you referring to rebase this > patch series to git://git.kernel.org/pub/scm/linux/kernel/git/next/linux- > next.git > <5.17-rc1 tag>? > > Regards, > Alex Sierra > > Alex Deucher, > Just a quick heads up. This patch series contains changes to the amdgpu > driver which we're planning to merge through Andrew's tree, If that's ok with > you. No problem. Thanks! Alex > > Regards, > Alex Sierra > > On 1/27/2022 4:32 PM, Andrew Morton wrote: > > On Wed, 26 Jan 2022 21:09:39 -0600 Alex Sierra > wrote: > > > >> This patch series introduces MEMORY_DEVICE_COHERENT, a type of > memory > >> owned by a device that can be mapped into CPU page tables like > >> MEMORY_DEVICE_GENERIC and can also be migrated like > >> MEMORY_DEVICE_PRIVATE. > > Some more reviewer input appears to be desirable here. > > > > I was going to tentatively add it to -mm and -next, but problems. > > 5.17-rc1's mm/migrate.c:migrate_vma_check_page() is rather different > > from the tree you patched. Please redo, refresh and resend? > >
Re: [radeon-alex:amd-20.45 2127/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse: sparse: incorrect type in argument 1 (different base types)
[AMD Public Use]
The test robot should probably not be testing the amd-20.xx branches in the
first place. They are just mirrors of our packaged drivers so they contain a
bunch of stuff that will never go upstream like kernel compatibility layers and
dkms support.
Alex
From: Qinglang Miao
Sent: Tuesday, December 15, 2020 3:21 AM
To: kernel test robot ; Deucher, Alexander
Cc: kbuild-...@lists.01.org ;
dri-devel@lists.freedesktop.org ; Xiong, Yang
(Felix)
Subject: Re: [radeon-alex:amd-20.45 2127/2427]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse:
sparse: incorrect type in argument 1 (different base types)
Hi Alex,
I think it's not a valid report from kernel test robot, for __le16 ought
to be the right type for cpu_to_le16. The sparse warnings seems not
right so I did't try effort to reproduce it.
otherwise, when I take a carful look at this patch, an unconditional
braces exists and I'm not sure about its benefit.
if (bp_params->flags.INTERLACE) {
params.susModeMiscInfo.usAccess =
cpu_to_le16(le16_to_cpu(params.susModeMiscInfo.usAccess) |
ATOM_INTERLACE);
{
le16_add_cpu(¶ms.usV_SyncOffset, 1);
}
}
patch link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCADnq5_PunHA1VHHj7VtEHG6o2Z_Z1WS325y_R9xO%2BgsV_JCOXw%40mail.gmail.com%2F&data=04%7C01%7Calexander.deucher%40amd.com%7Cc9a5d9273f464451b1f808d8a0d271fe%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436173010744629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1TmtjBXJLf60sxq%2BH%2BVmMhnRV%2FuyIKQD2BYDVWMxmUA%3D&reserved=0
How do you think?
在 2020/12/15 14:44, kernel test robot 写道:
> tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
> head: a3950d94b046fb206e58fd3ec717f071c0203ba3
> commit: c82b6c9ed412fb7009b02dd82e50ee24f451e9a8 [2127/2427] drm/amd/display:
> convert to use le16_add_cpu()
> config: arc-randconfig-s031-20201214 (attached as .config)
> compiler: arc-elf-gcc (GCC) 9.3.0
> reproduce:
> wget
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross&data=04%7C01%7Calexander.deucher%40amd.com%7Cc9a5d9273f464451b1f808d8a0d271fe%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436173010754583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DCHDVGjiXhPDoCTofTf0pxHspdydDs1JXneGoSGPgFQ%3D&reserved=0
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # apt-get install sparse
> # sparse version: v0.6.3-184-g1b896707-dirty
> git remote add radeon-alex
> git://people.freedesktop.org/~agd5f/linux.git
> git fetch --no-tags radeon-alex amd-20.45
> git checkout c82b6c9ed412fb7009b02dd82e50ee24f451e9a8
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
> CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
>
> "sparse warnings: (new ones prefixed by >>)"
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
> sparse: sparse: incorrect type in assignment (different base types) @@
> expected unsigned int [addressable] [assigned] [usertype] ulSymClock @@
> got restricted __le16 [usertype] @@
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
> sparse: expected unsigned int [addressable] [assigned] [usertype]
> ulSymClock
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
> sparse: got restricted __le16 [usertype]
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
> sparse: sparse: incorrect type in assignment (different base types) @@
> expected unsigned short [addressable] [assigned] [usertype] usRefDiv @@
> got restricted __le16 [usertype] @@
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
> sparse: expected unsigned short [addressable] [assigned] [usertype]
> usRefDiv
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
> sparse: got restricted __le16 [usertype]
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:958:39:
> sparse: sparse: incorrect type in assignment (different base types) @@
> expected unsigned short [addressable] [assigned] [usertype] usFbDiv @@
> got restricted __le16 [usertype] @@
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/
Re: [radeon-alex:amd-20.45 1953/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:5: warning: no previous prototype for function 'dce60_get_dp_ref_freq_khz'
[AMD Public Use] this branch should be ignored by test robots. It's just a public mirror of our packaged driver source code. It contains kernel compatibility and dkms support which is not going upstream. Alex From: Mauro Rossi Sent: Tuesday, December 15, 2020 2:13 PM To: kernel test robot ; Deucher, Alexander Cc: kbuild-...@lists.01.org ; clang-built-li...@googlegroups.com ; ML dri-devel ; Xiong, Yang (Felix) Subject: Re: [radeon-alex:amd-20.45 1953/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:5: warning: no previous prototype for function 'dce60_get_dp_ref_freq_khz' Hello, the mentioned branch requires the following commit, but it is already applied in 5.10 released kernel, so I really do not know what next step here. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c4e4fd607b17973e54a7e9cc4c275b12ab7308e<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Fcommit%2F%3Fid%3D8c4e4fd607b17973e54a7e9cc4c275b12ab7308e&data=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973465049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4s%2Br5bporx1FuRLkI%2FJbJug4qPqKaIxwu6DJCaCG01U%3D&reserved=0> Mauro On Tue, Dec 15, 2020 at 11:24 AM kernel test robot mailto:l...@intel.com>> wrote: tree: git://people.freedesktop.org/~agd5f/linux.git<https://nam11.safelinks.protection.outlook.com/?url=http:%2F%2Fpeople.freedesktop.org%2F~agd5f%2Flinux.git&data=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973475007%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AwRdBRY9CLM5kV4FvQeKFMR1t8R6uEU%2BOvVLkhqQmwQ%3D&reserved=0> amd-20.45 head: a3950d94b046fb206e58fd3ec717f071c0203ba3 commit: e809646e73921328d66a2fbfddf067b9cdb30998 [1953/2427] drm/amd/display: enable SI support in the Kconfig (v2) config: x86_64-randconfig-a001-20201214 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project&data=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973475007%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pR0HOEIksASstlWPFMR8Eq9e6v%2BTPBQ8lhfPVy%2Bu1iI%3D&reserved=0> a29ecca7819a6ed4250d3689b12b1f664bb790d7) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross&data=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973484960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J9LnzLuz5PGRhi4YFVdiTNq8sQUJ3igy%2FtJWq3BrsSE%3D&reserved=0> -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git<https://nam11.safelinks.protection.outlook.com/?url=http:%2F%2Fpeople.freedesktop.org%2F~agd5f%2Flinux.git&data=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973484960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a%2FwjGAjiR1C5wpjwPtmt%2BLkwVcix2gwFzsBvYB8PmDs%3D&reserved=0> git fetch --no-tags radeon-alex amd-20.45 git checkout e809646e73921328d66a2fbfddf067b9cdb30998 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot mailto:l...@intel.com>> All warnings (new ones prefixed by >>): >> drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:5: >> warning: no previous prototype for function 'dce60_get_dp_ref_freq_khz' >> [-Wmissing-prototypes] int dce60_get_dp_ref_freq_khz(struct clk_mgr *clk_mgr_base) ^ drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:1: note: declare 'static' if the function is not intended to be used outside of this translation uni
RE: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
[AMD Public Use] > -Original Message- > From: Laurent Pinchart > Sent: Tuesday, December 15, 2020 9:15 PM > To: Koenig, Christian > Cc: Daniel Vetter ; Laurent Pinchart > ; dri- > de...@lists.freedesktop.org; Dave Airlie ; Greg Kroah- > Hartman ; Thomas Gleixner > ; Deucher, Alexander ; > Rob Clark ; Sean Paul ; Ben > Skeggs ; Gerd Hoffmann ; > Thierry Reding ; Eric Anholt ; > VMware Graphics ; Thomas > Hellstrom > Subject: Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers > > Hi Christian, > > On Fri, Jul 17, 2020 at 04:05:42PM +0200, Christian König wrote: > > Am 17.07.20 um 04:27 schrieb Laurent Pinchart: > > > On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote: > > >> On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote: > > >>> Am 21.06.20 um 04:07 schrieb Laurent Pinchart: > > >>>> Most of the DRM drivers uAPI headers are licensed under the MIT > > >>>> license, and carry copies of the license with slight variations. > > >>>> Replace them with SPDX headers. > > >>> My personal opinion is that this is a really good idea, but my > > >>> professional is that we need the acknowledgment from our legal > department for this. > > >> I think official ack from amd on first patch, especially the .rst > > >> snippet, would be really good indeed. > > > Any update on this one ? > > > > Sorry totally forgot to forward this because I was waiting for split > > up patches. > > > > Going to do so right now. > > Has there been any update ? :-) AMD legal requires the full license. Alex > > > >>> Please separate that change into one for each > driver/company/maintainer. > > >>> Amdgpu, radeon, r128 can be one for example. > > > > > > I'll do so. > > > > > >> You can leave all the other legacy drivers in one patch (mga, > > >> savage, sis, via), since there's likely no one around anymore and > > >> will just boil down to drm maintainer ack from Dave&me. > > >> > > >>>> Signed-off-by: Laurent Pinchart > > >>>> > > >>>> --- > > >>>>include/uapi/drm/amdgpu_drm.h | 19 +-- > > >>>>include/uapi/drm/i915_drm.h| 22 +- > > >>>>include/uapi/drm/mga_drm.h | 20 +--- > > >>>>include/uapi/drm/msm_drm.h | 20 +--- > > >>>>include/uapi/drm/nouveau_drm.h | 20 +--- > > >>>>include/uapi/drm/qxl_drm.h | 20 +--- > > >>>>include/uapi/drm/r128_drm.h| 20 +--- > > >>>>include/uapi/drm/radeon_drm.h | 20 +--- > > >>>>include/uapi/drm/savage_drm.h | 20 +--- > > >>>>include/uapi/drm/sis_drm.h | 21 + > > >>>>include/uapi/drm/tegra_drm.h | 19 +-- > > >>>>include/uapi/drm/v3d_drm.h | 20 +--- > > >>>>include/uapi/drm/vc4_drm.h | 20 +--- > > >>>>include/uapi/drm/vgem_drm.h| 22 +- > > >>>>include/uapi/drm/via_drm.h | 20 +--- > > >>>>include/uapi/drm/virtgpu_drm.h | 20 +--- > > >>>>include/uapi/drm/vmwgfx_drm.h | 21 + > > >>>>17 files changed, 17 insertions(+), 327 deletions(-) > > >>>> > > >>>> diff --git a/include/uapi/drm/amdgpu_drm.h > > >>>> b/include/uapi/drm/amdgpu_drm.h index > 4e873dcbe68f..c6adda72bec7 > > >>>> 100644 > > >>>> --- a/include/uapi/drm/amdgpu_drm.h > > >>>> +++ b/include/uapi/drm/amdgpu_drm.h > > >>>> @@ -1,3 +1,4 @@ > > >>>> +/* SPDX-License-Identifier: MIT */ > > >>>>/* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c > -*- > > >>>> * > > >>>> * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas. > > >>>> @@ -5,24 +6,6 @@ > > >>>> * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. > > >>>> * Copyright 2014 Advanced Micro Devices, Inc. > > >>>> * > > >>>> - * Permission is hereby granted, f
Re: [kbuild-all] Re: [radeon-alex:amd-20.45 2127/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse: sparse: incorrect type in argument 1 (different base types)
[AMD Official Use Only - Internal Distribution Only]
You can add amd-21.xx as well, since they will coming up next year. Maybe
amd-2*?
Alex
From: Rong Chen
Sent: Wednesday, December 16, 2020 3:48 AM
To: Deucher, Alexander ; Qinglang Miao
; kernel test robot
Cc: kbuild-...@lists.01.org ;
dri-devel@lists.freedesktop.org ; Felix
<"Xiong, "@ml01.01.org>
Subject: Re: [kbuild-all] Re: [radeon-alex:amd-20.45 2127/2427]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse:
sparse: incorrect type in argument 1 (different base types)
Hi Alex,
We have ignored the amd-20.xx branches:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fintel%2Flkp-tests%2Fcommit%2Facb8d1f213ec6841900e0d7e9737f8ea0960e4d3&data=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682479635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U2aA%2B31wbSToDkIHiUrJWriNOPNNJ162W3F1HjYG6mc%3D&reserved=0
Best Regards,
Rong Chen
On 12/15/20 10:24 PM, Deucher, Alexander wrote:
>
> [AMD Public Use]
>
>
> The test robot should probably not be testing the amd-20.xx branches
> in the first place. They are just mirrors of our packaged drivers so
> they contain a bunch of stuff that will never go upstream like kernel
> compatibility layers and dkms support.
>
> Alex
>
>
> *From:* Qinglang Miao
> *Sent:* Tuesday, December 15, 2020 3:21 AM
> *To:* kernel test robot ; Deucher, Alexander
>
> *Cc:* kbuild-...@lists.01.org ;
> dri-devel@lists.freedesktop.org ;
> Xiong, Yang (Felix)
> *Subject:* Re: [radeon-alex:amd-20.45 2127/2427]
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39:
> sparse: sparse: incorrect type in argument 1 (different base types)
> Hi Alex,
>
> I think it's not a valid report from kernel test robot, for __le16 ought
> to be the right type for cpu_to_le16. The sparse warnings seems not
> right so I did't try effort to reproduce it.
>
> otherwise, when I take a carful look at this patch, an unconditional
> braces exists and I'm not sure about its benefit.
>
> if (bp_params->flags.INTERLACE) {
> params.susModeMiscInfo.usAccess =
> cpu_to_le16(le16_to_cpu(params.susModeMiscInfo.usAccess) |
> ATOM_INTERLACE);
> {
> le16_add_cpu(¶ms.usV_SyncOffset, 1);
> }
> }
>
> patch link:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCADnq5_PunHA1VHHj7VtEHG6o2Z_Z1WS325y_R9xO%2BgsV_JCOXw%40mail.gmail.com%2F&data=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682489591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=loDpCZcwzSthBMwesVesMIEwtgf%2BGZoycOyTwBpqkfI%3D&reserved=0
>
> How do you think?
>
> 在 2020/12/15 14:44, kernel test robot 写道:
> > tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
> > head: a3950d94b046fb206e58fd3ec717f071c0203ba3
> > commit: c82b6c9ed412fb7009b02dd82e50ee24f451e9a8 [2127/2427]
> drm/amd/display: convert to use le16_add_cpu()
> > config: arc-randconfig-s031-20201214 (attached as .config)
> > compiler: arc-elf-gcc (GCC) 9.3.0
> > reproduce:
> > wget
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross&data=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682489591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a6yKdL%2BoYm1zc5fYftUrWwmas%2BOfrTjqpivV14xci1Y%3D&reserved=0
> -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # apt-get install sparse
> > # sparse version: v0.6.3-184-g1b896707-dirty
> > git remote add radeon-alex
> git://people.freedesktop.org/~agd5f/linux.git
> > git fetch --no-tags radeon-alex amd-20.45
> > git checkout c82b6c9ed412fb7009b02dd82e50ee24f451e9a8
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
> make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arc
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> >
> >
> > "sparse warnings: (new ones prefix
Re: [PATCH AUTOSEL 5.4 006/130] drm/amd/display: Do not silently accept DCC for multiplane formats.
[AMD Public Use] I don't know if these fixes related to modifiers make sense in the pre-modifier code base. Bas, Nick? Alex From: amd-gfx on behalf of Sasha Levin Sent: Tuesday, December 22, 2020 9:16 PM To: linux-ker...@vger.kernel.org ; sta...@vger.kernel.org Cc: Sasha Levin ; dri-devel@lists.freedesktop.org ; amd-...@lists.freedesktop.org ; Bas Nieuwenhuizen ; Deucher, Alexander ; Kazlauskas, Nicholas Subject: [PATCH AUTOSEL 5.4 006/130] drm/amd/display: Do not silently accept DCC for multiplane formats. From: Bas Nieuwenhuizen [ Upstream commit b35ce7b364ec80b54f48a8fdf9fb74667774d2da ] Silently accepting it could result in corruption. Signed-off-by: Bas Nieuwenhuizen Reviewed-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index d2dd387c95d86..ce70c42a2c3ec 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2734,7 +2734,7 @@ fill_plane_dcc_attributes(struct amdgpu_device *adev, return 0; if (format >= SURFACE_PIXEL_FORMAT_VIDEO_BEGIN) - return 0; + return -EINVAL; if (!dc->cap_funcs.get_dcc_compression_cap) return -EINVAL; -- 2.27.0 ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Calexander.deucher%40amd.com%7Cfb9f2581393f494acd1708d8a6e905fc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63744286704415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZYz1FjTl6SoWX1B91t0McdUai%2FzRF9C8uBmE%2BNQNod4%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10
[AMD Public Use] It looks like the driver is not able to access the firmware for some reason. Please make sure it is available in your initrd or compiled into the kernel depending on your config. Alex From: amd-gfx on behalf of Mikhail Gavrilov Sent: Sunday, December 27, 2020 11:58 AM To: amd-gfx list ; Linux List Kernel Mailing ; dri-devel Subject: Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10 On Sun, 27 Dec 2020 at 21:39, Mikhail Gavrilov wrote: > I suppose the root of cause my problem here: > > [3.961326] amdgpu :0b:00.0: Direct firmware load for > amdgpu/sienna_cichlid_sos.bin failed with error -2 > [3.961359] amdgpu :0b:00.0: amdgpu: failed to init sos firmware > [3.961433] [drm:psp_sw_init [amdgpu]] *ERROR* Failed to load psp firmware! > [3.961529] [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* sw_init > of IP block failed -2 > [3.961549] amdgpu :0b:00.0: amdgpu: amdgpu_device_ip_init failed > [3.961569] amdgpu :0b:00.0: amdgpu: Fatal error during GPU init > [3.961911] amdgpu: probe of :0b:00.0 failed with error -2 > # dnf provides */sienna_cichlid_sos.bin Last metadata expiration check: 3:01:27 ago on Sun 27 Dec 2020 06:53:25 PM +05. linux-firmware-20201218-116.fc34.noarch : Firmware files used by the Linux kernel Repo: @System Matched from: Filename: /usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin linux-firmware-20201218-116.fc34.noarch : Firmware files used by the Linux kernel Repo: rawhide Matched from: Filename: /usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin # dnf install linux-firmware-20201218-116.fc34.noarch Last metadata expiration check: 3:02:11 ago on Sun 27 Dec 2020 06:53:25 PM +05. Package linux-firmware-20201218-116.fc34.noarch is already installed. Dependencies resolved. Nothing to do. Complete! Looks like firmware is present. So I didn't understand why the kernel cannot read firmware. -- Best Regards, Mike Gavrilov. ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Calexander.deucher%40amd.com%7Cf76668be26de4be7d0af08d8aa88a8dc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637446851228684932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NOQO9oeX9gOmM7aOThep5kjURTTn14N5nNkhGx7rofQ%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: amdgpu does not support 3840x2160@30Hz on kaveri apu
[AMD Official Use Only - Internal Distribution Only] You might try enabling DC (the newer modesetting infrastructure). Append amdgpu.dc=1 to the kernel command line in grub. Alex From: Davide Corrado Sent: Saturday, January 2, 2021 1:50 PM To: Deucher, Alexander Cc: Koenig, Christian ; airl...@linux.ie ; dan...@ffwll.ch ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org Subject: amdgpu does not support 3840x2160@30Hz on kaveri apu hello, I'd like to report this issue that I am having since I updated my display (samsung U28E590). The amdgpu does not support the native resolution of my new monitor, which is 3840x2160. Using a HDMI or DVI connection (I tried both, same results), the maximum supported refresh is 30Hz, so I'm stuck with that (don't have a displayport). The radeon module works fine, I'm having this issue just when I use amdgpu (which I'd like to, because performance is better). Some info of my hardware: cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G kernel version (I tried different ones and different linux distros, same results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Monitor: Samsung U28E590. description: If I boot the system using amdgpu and no video mode selection, the system boots but I don't get a screen during boot and in wayland. I can connect using ssh, so the system is running fine, just no display; If I force a full HD resolution with "video:" in the kernel line, I can see the boot process but the screen disappears when wayland starts (because the default resolution is 3840x2160@30Hz). Using a full HD monitor results in no issues, so it must be related to this very 4k resolution. As I have already stated, radeon module works with the same software/hardware configuration. thanks you so much for your time :-) -- Davide Corrado UNIX Team Leader Via Abramo Lincoln, 25 20129 Milano Tel +39 3474259950 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] Add available memory ioctl for libhsakmt
[Public]
This is missing your signed-off-by. Additionally, for UAPI changes, we need a
link the patches for the userspace component that will make use of it.
Alex
From: amd-gfx on behalf of Daniel
Phillips
Sent: Monday, January 10, 2022 3:54 PM
To: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Cc: Phillips, Daniel
Subject: [PATCH 1/1] Add available memory ioctl for libhsakmt
From: Daniel Phillips
Add an ioctl to inquire memory available for allocation by libhsakmt
per node, allowing for space consumed by page translation tables.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c| 14 ++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 17 +
include/uapi/linux/kfd_ioctl.h | 14 --
4 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index fcbc8a9c9e06..64c6c36685d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -266,6 +266,7 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct
amdgpu_device *adev,
void amdgpu_amdkfd_gpuvm_release_process_vm(struct amdgpu_device *adev,
void *drm_priv);
uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *drm_priv);
+size_t amdgpu_amdkfd_get_available_memory(struct amdgpu_device *adev);
int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
struct amdgpu_device *adev, uint64_t va, uint64_t size,
void *drm_priv, struct kgd_mem **mem,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 86a1a6c109d9..b7490a659173 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -190,6 +190,20 @@ static int amdgpu_amdkfd_reserve_mem_limit(struct
amdgpu_device *adev,
return ret;
}
+size_t amdgpu_amdkfd_get_available_memory(struct amdgpu_device *adev)
+{
+ uint64_t reserved_for_pt =
+ ESTIMATE_PT_SIZE(amdgpu_amdkfd_total_mem_size);
+ size_t available_memory;
+
+ spin_lock(&kfd_mem_limit.mem_limit_lock);
+ available_memory =
+ adev->gmc.real_vram_size -
+ adev->kfd.vram_used - reserved_for_pt;
+ spin_unlock(&kfd_mem_limit.mem_limit_lock);
+ return available_memory;
+}
+
static void unreserve_mem_limit(struct amdgpu_device *adev,
uint64_t size, u32 alloc_flag)
{
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 4bfc0c8ab764..5c2f6d97ff1c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -486,6 +486,20 @@ static int kfd_ioctl_get_queue_wave_state(struct file
*filep,
return r;
}
+static int kfd_ioctl_get_available_memory(struct file *filep,
+struct kfd_process *p, void *data)
+{
+ struct kfd_ioctl_get_available_memory_args *args = data;
+ struct kfd_dev *dev;
+
+ dev = kfd_device_by_id(args->gpu_id);
+ if (!dev)
+ return -EINVAL;
+
+ args->available = amdgpu_amdkfd_get_available_memory(dev->adev);
+ return 0;
+}
+
static int kfd_ioctl_set_memory_policy(struct file *filep,
struct kfd_process *p, void *data)
{
@@ -1959,6 +1973,9 @@ static const struct amdkfd_ioctl_desc amdkfd_ioctls[] = {
AMDKFD_IOCTL_DEF(AMDKFD_IOC_SET_XNACK_MODE,
kfd_ioctl_set_xnack_mode, 0),
+
+ AMDKFD_IOCTL_DEF(AMDKFD_IOC_AVAILABLE_MEMORY,
+ kfd_ioctl_get_available_memory, 0),
};
#define AMDKFD_CORE_IOCTL_COUNT ARRAY_SIZE(amdkfd_ioctls)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index af96af174dc4..94a99add2432 100644
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -32,9 +32,10 @@
* - 1.4 - Indicate new SRAM EDC bit in device properties
* - 1.5 - Add SVM API
* - 1.6 - Query clear flags in SVM get_attr API
+ * - 1.7 - Add available_memory ioctl
*/
#define KFD_IOCTL_MAJOR_VERSION 1
-#define KFD_IOCTL_MINOR_VERSION 6
+#define KFD_IOCTL_MINOR_VERSION 7
struct kfd_ioctl_get_version_args {
__u32 major_version;/* from KFD */
@@ -98,6 +99,12 @@ struct kfd_ioctl_get_queue_wave_state_args {
__u32 pad;
};
+struct kfd_ioctl_get_available_memory_args {
+ __u64 available;/* from KFD */
+ __u32 gpu_id; /* to KFD */
+ __u32 pad;
+};
+
/* For kfd_ioctl_set_memory_policy_args.default_policy and alternate_policy */
#define KFD_IOC_CACHE_POLICY_COHERENT 0
#define KFD_IOC_CACHE_POLICY_NONCOHERENT 1
@@ -742,7 +749,10 @@ struct kfd_ioctl_set_xnack_mode_args {
#defin
[Intel-gfx] [PATCH 08/35] drm: Protect dev->filelist with its own mutex
> -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Wednesday, April 27, 2016 3:09 AM > To: Alex Deucher > Cc: Chris Wilson; Daniel Vetter; DRI Development; Deucher, Alexander; Intel > Graphics Development; Daniel Vetter > Subject: Re: [Intel-gfx] [PATCH 08/35] drm: Protect dev->filelist with its own > mutex > > On Wed, Apr 27, 2016 at 09:06:09AM +0200, Daniel Vetter wrote: > > On Tue, Apr 26, 2016 at 05:45:44PM -0400, Alex Deucher wrote: > > > On Tue, Apr 26, 2016 at 4:52 PM, Chris Wilson > > chris-wilson.co.uk> > wrote: > > > > On Tue, Apr 26, 2016 at 07:29:41PM +0200, Daniel Vetter wrote: > > > >> amdgpu gained dev->struct_mutex usage, and that's because it's > walking > > > >> the dev->filelist list. Protect that list with it's own lock to take > > > >> one more step towards getting rid of struct_mutex usage in drivers > > > >> once and for all. > > > >> > > > >> While doing the conversion I noticed that 2 debugfs files in i915 > > > >> completely lacked appropriate locking. Fix that up too. > > > >> > > > >> v2: don't forget to switch to > drm_gem_object_unreference_unlocked. > > > >> > > > >> Cc: Alex Deucher > > > >> Signed-off-by: Daniel Vetter > > > > > > > > Just wondering if this worth converting over. Opening/closing isn't > > > > going to be high contention, I hope, though we can certainly write > > > > stress cases for it! The goal for drivers to stop using the struct_mutex > > > > as their BKL, which doesn't preclude keeping the struct_mutex around > for > > > > where it makes sense to have a single mutex rather than a multitude. > > > > > > > > I have some misgivings over this, but only because I think its overkill. > > > > Reviewed-by: Chris Wilson > > > > > > I agree with Chris' sentiments. > > > > It's not to have more speed or less contention, but just to have fewer > > things to worry about when reviewing locking. Hence orthogonal locks for > > independent parts. > > > > My goal is that in the end dev->struct_mutex is only used by some existing > > drivers for their internals, plus all the legacy core stuff. And never > > even used by modern drivers. New locks are pretty cheap, and not > dragging > > in the entire legacy horror show has benefits. > > > > When/once I tackle the one thing left (master locking) I might move the > > master handling under this lock too (since it's closely related to open > > files). Not sure yet. > > Oh and the main reason I did it here: Much easier to review using git grep > struct_mutex than auditing codepaths. With this drivers have no reason to > ever grab struct_mutex (not even for debugfs or similar), since the last > remaining bit (master control) really shouldn't be a concern for drivers > ever. > > That also makes reviewing new drivers simpler: Contains struct_mutex? > Reject it! I'm convinced! Thanks for cleaning this up. Alex > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
[PATCH 0179/1285] Replace numeric parameter like 0444 with macro
> -Original Message- > From: Baole Ni [mailto:baolex.ni at intel.com] > Sent: Tuesday, August 02, 2016 6:47 AM > To: Deucher, Alexander; Koenig, Christian; airlied at linux.ie; > tony.luck at intel.com; matt at codeblueprint.co.uk; m.chehab at samsung.com; > lho at apm.com; dougthompson at xmission.com; bp at alien8.de > Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; Zhou, > Jammy; Zhou, David(ChunMing); Cui, Flora; chuansheng.liu at intel.com; > baolex.ni at intel.com > Subject: [PATCH 0179/1285] Replace numeric parameter like 0444 with macro > > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access > permission. > As we know, these numeric value for access permission have had the > corresponding macro, > and that using macro can improve the robustness and readability of the code, > thus, I suggest replacing the numeric parameter with the macro. > > Signed-off-by: Chuansheng Liu > Signed-off-by: Baole Ni > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 54 > - > 1 file changed, 27 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index f888c01..f0c9c29 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -86,87 +86,87 @@ unsigned amdgpu_pcie_gen_cap = 0; > unsigned amdgpu_pcie_lane_cap = 0; > > MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in > megabytes"); > -module_param_named(vramlimit, amdgpu_vram_limit, int, 0600); > +module_param_named(vramlimit, amdgpu_vram_limit, int, S_IRUSR | > S_IWUSR); > FWIW, I find it much easier to read and understand the numeric representation. Alex > MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in > megabytes (32, 64, etc., -1 = auto)"); > -module_param_named(gartsize, amdgpu_gart_size, int, 0600); > +module_param_named(gartsize, amdgpu_gart_size, int, S_IRUSR | > S_IWUSR); > > MODULE_PARM_DESC(benchmark, "Run benchmark"); > -module_param_named(benchmark, amdgpu_benchmarking, int, 0444); > +module_param_named(benchmark, amdgpu_benchmarking, int, S_IRUSR > | S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(test, "Run tests"); > -module_param_named(test, amdgpu_testing, int, 0444); > +module_param_named(test, amdgpu_testing, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(audio, "Audio enable (-1 = auto, 0 = disable, 1 = > enable)"); > -module_param_named(audio, amdgpu_audio, int, 0444); > +module_param_named(audio, amdgpu_audio, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(disp_priority, "Display Priority (0 = auto, 1 = normal, 2 > = high)"); > -module_param_named(disp_priority, amdgpu_disp_priority, int, 0444); > +module_param_named(disp_priority, amdgpu_disp_priority, int, S_IRUSR | > S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(hw_i2c, "hw i2c engine enable (0 = disable)"); > -module_param_named(hw_i2c, amdgpu_hw_i2c, int, 0444); > +module_param_named(hw_i2c, amdgpu_hw_i2c, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(pcie_gen2, "PCIE Gen2 mode (-1 = auto, 0 = disable, > 1 = enable)"); > -module_param_named(pcie_gen2, amdgpu_pcie_gen2, int, 0444); > +module_param_named(pcie_gen2, amdgpu_pcie_gen2, int, S_IRUSR | > S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(msi, "MSI support (1 = enable, 0 = disable, -1 = > auto)"); > -module_param_named(msi, amdgpu_msi, int, 0444); > +module_param_named(msi, amdgpu_msi, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms (default > 0 = disable)"); > -module_param_named(lockup_timeout, amdgpu_lockup_timeout, int, > 0444); > +module_param_named(lockup_timeout, amdgpu_lockup_timeout, int, > S_IRUSR | S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(dpm, "DPM support (1 = enable, 0 = disable, -1 = > auto)"); > -module_param_named(dpm, amdgpu_dpm, int, 0444); > +module_param_named(dpm, amdgpu_dpm, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(smc_load_fw, "SMC firmware loading(1 = enable, 0 = > disable)"); > -module_param_named(smc_load_fw, amdgpu_smc_load_fw, int, 0444); > +module_param_named(smc_load_fw, amdgpu_smc_load_fw, int, S_IRUSR > | S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(aspm, "ASPM support (1 = enable, 0 = disable, -1 = > auto)"); > -module_param_named(aspm, amdgpu_aspm, int, 0444); > +module_param_named(aspm, amdgpu_aspm, int, S_IRUSR | S_IRGRP | >
Re: [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking
I reverted all the amdgpu HMM patches for 5.2 because they also depended on
this patch:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip&id=ce05ef71564f7cbe270cd4337c36ee720ea534db
which did not have a clear line of sight for 5.2 either.
Alex
From: amd-gfx on behalf of Kuehling,
Felix
Sent: Monday, May 13, 2019 3:36 PM
To: Jerome Glisse
Cc: linux...@kvack.org; airl...@gmail.com; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; alex.deuc...@amd.com
Subject: Re: [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for
non-blocking
[CAUTION: External Email]
Hi Jerome,
Do you want me to push the patches to your branch? Or are you going to
apply them yourself?
Is your hmm-5.2-v3 branch going to make it into Linux 5.2? If so, do you
know when? I'd like to coordinate with Dave Airlie so that we can also
get that update into a drm-next branch soon.
I see that Linus merged Dave's pull request for Linux 5.2, which
includes the first changes in amdgpu using HMM. They're currently broken
without these two patches.
Thanks,
Felix
On 2019-05-10 4:14 p.m., Jerome Glisse wrote:
> [CAUTION: External Email]
>
> On Fri, May 10, 2019 at 07:53:24PM +, Kuehling, Felix wrote:
>> Don't set this flag by default in hmm_vma_do_fault. It is set
>> conditionally just a few lines below. Setting it unconditionally
>> can lead to handle_mm_fault doing a non-blocking fault, returning
>> -EBUSY and unlocking mmap_sem unexpectedly.
>>
>> Signed-off-by: Felix Kuehling
> Reviewed-by: Jérôme Glisse
>
>> ---
>> mm/hmm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/hmm.c b/mm/hmm.c
>> index b65c27d5c119..3c4f1d62202f 100644
>> --- a/mm/hmm.c
>> +++ b/mm/hmm.c
>> @@ -339,7 +339,7 @@ struct hmm_vma_walk {
>> static int hmm_vma_do_fault(struct mm_walk *walk, unsigned long addr,
>>bool write_fault, uint64_t *pfn)
>> {
>> - unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_REMOTE;
>> + unsigned int flags = FAULT_FLAG_REMOTE;
>>struct hmm_vma_walk *hmm_vma_walk = walk->private;
>>struct hmm_range *range = hmm_vma_walk->range;
>>struct vm_area_struct *vma = walk->vma;
>> --
>> 2.17.1
>>
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 4.19 29/53] drm/amdkfd: Add picasso pci id
NACK. 4.19 did not contain support for picasso. Please drop this patch for
4.19.
Alex
From: amd-gfx on behalf of Sasha Levin
Sent: Friday, April 26, 2019 9:40 PM
To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
Cc: Deucher, Alexander; Sasha Levin; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: [PATCH AUTOSEL 4.19 29/53] drm/amdkfd: Add picasso pci id
From: Alex Deucher
[ Upstream commit e7ad88553aa1d48e950ca9a4934d246c1bee4be4 ]
Picasso is a new raven variant.
Reviewed-by: Kent Russell
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 5aba50f63ac6..06d19bb89cfc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -275,6 +275,7 @@ static const struct kfd_deviceid supported_devices[] = {
{ 0x9876, &carrizo_device_info }, /* Carrizo */
{ 0x9877, &carrizo_device_info }, /* Carrizo */
{ 0x15DD, &raven_device_info }, /* Raven */
+ { 0x15D8, &raven_device_info }, /* Raven */
#endif
{ 0x67A0, &hawaii_device_info },/* Hawaii */
{ 0x67A1, &hawaii_device_info },/* Hawaii */
--
2.19.1
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: Remove duplicate header
It was already fixed a while ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e07834c12b96214e95a473f7b14fc03b20e2e7a Alex From: Brajeswar Ghosh Sent: Wednesday, January 30, 2019 8:58:52 AM To: Souptick Joarder Cc: Zhu, Rex; Quan, Evan; Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); airl...@linux.ie; Zhang, Hawking; Huang, Ray; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Sabyasachi Gupta Subject: Re: [PATCH] drm/amd/powerplay: Remove duplicate header On Fri, Dec 21, 2018 at 6:06 PM Souptick Joarder wrote: > > On Fri, Dec 21, 2018 at 2:49 PM Brajeswar Ghosh > wrote: > > > > Remove hwmgr_ppt.h which is included more than once > > > > Signed-off-by: Brajeswar Ghosh > > --- > Acked-by: Souptick Joarder If no further comment, can we get this patch in queue for 5.1 ? > > > drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > > b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > > index e5a60aa44b5d..07d180ce4d18 100644 > > --- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > > +++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > > @@ -28,7 +28,6 @@ > > #include "hardwaremanager.h" > > #include "hwmgr_ppt.h" > > #include "ppatomctrl.h" > > -#include "hwmgr_ppt.h" > > #include "power_state.h" > > #include "smu_helper.h" > > > > -- > > 2.17.1 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF
> -Original Message-
> From: amd-gfx On Behalf Of Emil
> Velikov
> Sent: Monday, February 25, 2019 8:09 AM
> To: Alex Deucher
> Cc: Deng, Emily ; Maling list - DRI developers de...@lists.freedesktop.org>; amd-gfx list
> Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but
> same BDF
>
> Hi all,
>
> This patch causes unnecessary round trip by openning the nodes. As
> mentioned previously this could be trivially fixed [1].
>
> Even Emily acknowledged that [1], yet the sub-par fix was merged. Can we
> revert+fixup this properly?
>
Sorry, I totally missed your reply. I'm having Internet issues at the moment
so if you want to revert for now, I'll work with Emily to address your
suggestions later in the week or next. Emily, can you take a look at
addressing Emil's concerns with an updated patch?
Alex
> Thanks
> Emil
>
> [1] https://lists.freedesktop.org/archives/amd-gfx/2019-
> February/031573.html
>
> On Fri, 22 Feb 2019 at 21:05, Alex Deucher wrote:
> >
> > Pushed. Thanks!
> >
> > Alex
> >
> > On Thu, Feb 21, 2019 at 9:36 PM Deng, Emily
> wrote:
> > >
> > > Hi Alex,
> > > Please help, thanks.
> > >
> > > Best wishes
> > > Emily Deng
> > >
> > >
> > >
> > > >-Original Message-
> > > >From: Alex Deucher
> > > >Sent: Friday, February 22, 2019 12:13 AM
> > > >To: Deng, Emily ; Maling list - DRI developers
> > > >
> > > >Cc: amd-gfx list
> > > >Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent
> > > >domainID but same BDF
> > > >
> > > >On Thu, Feb 14, 2019 at 2:53 AM Emily Deng
> wrote:
> > > >>
> > > >> For multiple GPUs which has the same BDF, but has different
> > > >> domain ID, the drmOpenByBusid will return the wrong fd when startx.
> > > >>
> > > >> The reproduce sequence as below:
> > > >> 1. Call drmOpenByBusid to open Card0, then will return the right
> > > >> fd0, and the
> > > >> fd0 is master privilege;
> > > >> 2. Call drmOpenByBusid to open Card1. In function drmOpenByBusid,
> > > >> it will open Card0 first, this time, the fd1 for opening Card0 is
> > > >> not master privilege, and will call drmSetInterfaceVersion to
> > > >> identify the domain ID feature, as the fd1 is not master
> > > >> privilege, then drmSetInterfaceVersion will fail, and then won't
> > > >> compare domain ID, then
> > > >return the wrong fd for Card1.
> > > >>
> > > >> Solution:
> > > >> First loop search the best match fd about drm 1.4.
> > > >>
> > > >> Signed-off-by: Emily Deng
> > > >
> > > >Reviewed-by: Alex Deucher
> > > >
> > > >Do you need someone to commit this for you?
> > > >
> > > >Alex
> > > >
> > > >> ---
> > > >> xf86drm.c | 23 +++
> > > >> 1 file changed, 23 insertions(+)
> > > >>
> > > >> diff --git a/xf86drm.c b/xf86drm.c index 336d64d..b60e029 100644
> > > >> --- a/xf86drm.c
> > > >> +++ b/xf86drm.c
> > > >> @@ -584,11 +584,34 @@ static int drmOpenByBusid(const char
> > > >> *busid, int
> > > >type)
> > > >> if (base < 0)
> > > >> return -1;
> > > >>
> > > >> +/* We need to try for 1.4 first for proper PCI domain
> > > >> + support */
> > > >> drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
> > > >> for (i = base; i < base + DRM_MAX_MINOR; i++) {
> > > >> fd = drmOpenMinor(i, 1, type);
> > > >> drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
> > > >> if (fd >= 0) {
> > > >> +sv.drm_di_major = 1;
> > > >> +sv.drm_di_minor = 4;
> > > >> +sv.drm_dd_major = -1;/* Don't care */
> > > >> +sv.drm_dd_minor = -1;/* Don't care */
> > > >> +if (!drmSetInterfaceVersion(fd, &sv)) {
> > > >> +buf = drmGetBusid(fd);
> > > >> +drmMsg("drmOpenByBusid: drmGetBusid reports %s\n",
> buf);
> > > >> +if (buf && drmMatchBusID(buf, busid, 1)) {
> > > >> +drmFreeBusid(buf);
> > > >> +return fd;
> > > >> +}
> > > >> +if (buf)
> > > >> +drmFreeBusid(buf);
> > > >> +}
> > > >> +close(fd);
> > > >> +}
> > > >> +}
> > > >> +
> > > >> + for (i = base; i < base + DRM_MAX_MINOR; i++) {
> > > >> +fd = drmOpenMinor(i, 1, type);
> > > >> +drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
> > > >> +if (fd >= 0) {
> > > >> /* We need to try for 1.4 first for proper PCI domain
> > > >> support
> > > >> * and if that fails, we know the kernel is busted
> > > >> */
> > > >> --
> > > >> 2.7.4
> > > >>
> > > >> ___
> > > >> amd-gfx mailing list
> > > >> amd-...@lists.freedesktop.org
> > > >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/d
Re: [PATCH] drm/amd/display: avoid passing enum as NULL pointer
Thanks for the patch. We already have the fix queued:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip&id=672e78cab819ebe31e3b9b8abac367be8a110472
Alex
From: Arnd Bergmann
Sent: Thursday, March 7, 2019 5:34 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing)
Cc: Nick Desaulniers; Arnd Bergmann; David Airlie; Daniel Vetter; Koo, Anthony;
Cyr, Aric; Tatla, Harmanprit; Chalmers, Kenneth; Kumarasamy, Sivapiriyan; Kees
Cook; Bayan Zabihiyan; Cheng, Tony; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: [PATCH] drm/amd/display: avoid passing enum as NULL pointer
The mod_freesync_build_vrr_infopacket() function uses rather obscure
calling conventions, where an enum is passed in through a pointer,
and a NULL pointer is expected to behave the same way as the zero-value
(TRANSFER_FUNC_UNKNOWN).
Trying to build this with clang results in a warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4601:3: error:
expression which evaluates to zero treated
as a null pointer constant of type 'const enum color_transfer_func *'
[-Werror,-Wnon-literal-null-conversion]
Passing it by value instead of by reference makes the code simpler
and more conventional but should not change the behavior at all.
Fixes: c2791297013e ("drm/amd/display: Add color bit info to freesync
infoframe")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 7 +++
drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 94a84bc57c7a..6f32fe129880 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -724,7 +724,7 @@ static void build_vrr_infopacket_v1(enum signal_type signal,
static void build_vrr_infopacket_v2(enum signal_type signal,
const struct mod_vrr_params *vrr,
- const enum color_transfer_func *app_tf,
+ const enum color_transfer_func app_tf,
struct dc_info_packet *infopacket)
{
unsigned int payload_size = 0;
@@ -732,8 +732,7 @@ static void build_vrr_infopacket_v2(enum signal_type signal,
build_vrr_infopacket_header_v2(signal, infopacket, &payload_size);
build_vrr_infopacket_data(vrr, infopacket);
- if (app_tf != NULL)
- build_vrr_infopacket_fs2_data(*app_tf, infopacket);
+ build_vrr_infopacket_fs2_data(app_tf, infopacket);
build_vrr_infopacket_checksum(&payload_size, infopacket);
@@ -757,7 +756,7 @@ void mod_freesync_build_vrr_infopacket(struct mod_freesync
*mod_freesync,
const struct dc_stream_state *stream,
const struct mod_vrr_params *vrr,
enum vrr_packet_type packet_type,
- const enum color_transfer_func *app_tf,
+ const enum color_transfer_func app_tf,
struct dc_info_packet *infopacket)
{
/* SPD info packet for FreeSync
diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
index 4222e403b151..645793b924cf 100644
--- a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
+++ b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
@@ -145,7 +145,7 @@ void mod_freesync_build_vrr_infopacket(struct mod_freesync
*mod_freesync,
const struct dc_stream_state *stream,
const struct mod_vrr_params *vrr,
enum vrr_packet_type packet_type,
- const enum color_transfer_func *app_tf,
+ const enum color_transfer_func app_tf,
struct dc_info_packet *infopacket);
void mod_freesync_build_vrr_params(struct mod_freesync *mod_freesync,
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait
Reviewed-by: Alex Deucher From: amd-gfx on behalf of Harry Wentland Sent: Tuesday, June 25, 2019 10:00 AM To: airl...@gmail.com; natechancel...@gmail.com Cc: Zhou, David(ChunMing); Li, Sun peng (Leo); Koo, Anthony; linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Wentland, Harry; Deucher, Alexander; Lei, Jun; Lakha, Bhawanpreet; Koenig, Christian Subject: [PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait arm32's udelay only allows values up to 2000 microseconds. msleep does the trick for us here as there is no problem if this isn't microsecond accurate and takes a tad longer. Signed-off-by: Harry Wentland --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 4c31930f1cdf..f5d02f89b3f9 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -548,7 +548,7 @@ static void read_edp_current_link_settings_on_detect(struct dc_link *link) break; } - udelay(8000); + msleep(8); } ASSERT(status == DC_OK); -- 2.22.0 ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: avoid 64-bit division
I'll just apply Arnd's patch. If the display team wants to adjust it later to
clarify the operation, they should go ahead as a follow up patch.
Thanks,
Alex
From: Abramov, Slava
Sent: Tuesday, July 9, 2019 12:31 PM
To: Arnd Bergmann; Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander;
Koenig, Christian; Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: Re: [PATCH] drm/amd/display: avoid 64-bit division
Hi Arnd!
Thanks for bisecting this issue.
I wonder whether you are going to commit your patch or planning to update it
and it's still in your work queue. We have one of our 32-bit builds failing
because of this issue, so that I would like either to fix it or wait to your
fix if it has chances to go upstream today.
Sincerely,
Slava Abramov
From: amd-gfx on behalf of Arnd
Bergmann
Sent: Monday, July 8, 2019 9:52:08 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Arnd Bergmann; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: [PATCH] drm/amd/display: avoid 64-bit division
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4be ("drm/amd/display: Move link functions from dc to dc_link")
Fixes: f18bc4e53ad6 ("drm/amd/display: update calculated bounding box logic for
NV")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c17db5c144aa..8dbf759eba45 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3072,8 +3072,8 @@ uint32_t dc_link_bandwidth_kbps(
* but the difference is minimal and is in a safe direction,
* which all works well around potential ambiguity of DP 1.4a
spec.
*/
- long long fec_link_bw_kbps = link_bw_kbps * 970LL;
- link_bw_kbps = (uint32_t)(fec_link_bw_kbps / 1000LL);
+ link_bw_kbps = mul_u64_u32_shr(BIT_ULL(32) * 970LL / 1000,
+ link_bw_kbps, 32);
}
#endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index b35327bafbc5..70ac8a95d2db 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2657,7 +2657,7 @@ static void update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_
calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
// FCLK:UCLK ratio is 1.08
- min_fclk_required_by_uclk = ((unsigned long
long)uclk_states[i]) * 1080 / 100;
+ min_fclk_required_by_uclk = mul_u64_u32_shr(BIT_ULL(32) * 1080
/ 100, uclk_states[i], 32);
calculated_states[i].fabricclk_mhz =
(min_fclk_required_by_uclk < min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
--
2.20.0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [radeon-alex:drm-next-5.2-wip 21/42] drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID' undeclared; did you mean '_PAGE_VALID'?
The fixes are there; they are the subsequent commits, I guess I can squash them
in.
Alex
From: Kuehling, Felix
Sent: Wednesday, April 3, 2019 6:20 PM
To: Yang, Philip; Deucher, Alexander
Cc: dri-devel@lists.freedesktop.org; Koenig, Christian
Subject: Re: [radeon-alex:drm-next-5.2-wip 21/42]
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID'
undeclared; did you mean '_PAGE_VALID'?
[dropping the robot]
I think Philip fixed those issues on amd-staging-drm-next. Either some
fixes are missing on drm-next-5.2-wip, or they are there but should be
squashed to avoid hitting these errors on intermediate builds.
Regards,
Felix
On 2019-04-03 2:26 p.m., kbuild test robot wrote:
> tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
> head: 5666aea3ea494d4dd96df8f092cab32dbeeac321
> commit: 95db8d6001df8966e3370a66c9f358925fbcc890 [21/42] drm/amdgpu: replace
> get_user_pages with HMM mirror helpers
> config: mips-allyesconfig (attached as .config)
> compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 95db8d6001df8966e3370a66c9f358925fbcc890
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=mips
>
> Note: the radeon-alex/drm-next-5.2-wip HEAD
> 5666aea3ea494d4dd96df8f092cab32dbeeac321 builds fine.
>It only hurts bisectibility.
>
> All errors (new ones prefixed by >>):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:713:19: error: field 'range' has
> incomplete type
> struct hmm_range range;
>^
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function
> 'amdgpu_ttm_tt_get_user_pages':
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:738:7: error: dereferencing
> pointer to incomplete type 'struct hmm_range'
> range->vma = find_vma(mm, gtt->userptr);
>^~
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID'
>>> undeclared (first use in this function); did you mean '_PAGE_VALID'?
> range->pfns[0] = range->flags[HMM_PFN_VALID];
> ^
> _PAGE_VALID
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: note: each undeclared
> identifier is reported only once for each function it appears in
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:758:22: error: 'HMM_PFN_WRITE'
> undeclared (first use in this function); did you mean 'HMM_PFN_VALID'?
> 0 : range->flags[HMM_PFN_WRITE];
> ^
> HMM_PFN_VALID
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:763:6: error: implicit
> declaration of function 'hmm_vma_fault'; did you mean 'hmm_mm_init'?
> [-Werror=implicit-function-declaration]
> r = hmm_vma_fault(range, true);
> ^
> hmm_mm_init
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:770:14: error: implicit
> declaration of function 'hmm_pfn_to_page'; did you mean '__pfn_to_page'?
> [-Werror=implicit-function-declaration]
>pages[i] = hmm_pfn_to_page(range, range->pfns[i]);
> ^~~
> __pfn_to_page
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function
> 'amdgpu_ttm_tt_get_user_pages_done':
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:798:7: error: implicit
> declaration of function 'hmm_vma_range_done'; did you mean
> 'drm_vma_node_size'? [-Werror=implicit-function-declaration]
>r = hmm_vma_range_done(>t->range);
>^~
>drm_vma_node_size
> cc1: some warnings being treated as errors
>
> vim +756 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>
> 703
> 704 /*
> 705* TTM backend functions.
> 706*/
> 707 struct amdgpu_ttm_tt {
> 708 struct ttm_dma_tt ttm;
> 709 u64 offset;
> 710 uint64_tuserptr;
> 711 struct task_struct *usertask;
> 712 uint32_tuserflags;
> > 713 struct hmm_rangerange;
> 714 };
> 715
> 716 /**
> 717* amdgpu_ttm_tt_get_user_pages - get device accessible pages
> that back user
> 718* memory and start HMM tra
Re: [PATCH] drm/amdkfd/kfd_mqd_manager_v10: Fix missing break in switch statement
We need to add a /*fall through */ comment then.
Alex
From: Liu, Shaoyun
Sent: Monday, July 22, 2019 11:14 AM
To: Gustavo A. R. Silva ; Cox, Philip
; Oded Gabbay ; Deucher, Alexander
; Koenig, Christian ;
Zhou, David(ChunMing) ; David Airlie ;
Daniel Vetter
Cc: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amdkfd/kfd_mqd_manager_v10: Fix missing break in
switch statement
This one properly in purpose , The mqd init for CP and COMPUTE will
have the same routine .
Regard
sshaoyun.liu
On 2019-07-21 6:59 p.m., Gustavo A. R. Silva wrote:
> Add missing break statement in order to prevent the code from falling
> through to case KFD_MQD_TYPE_COMPUTE.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: 14328aa58ce5 ("drm/amdkfd: Add navi10 support to amdkfd. (v3)")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
> index 4f8a6ffc5775..1d8b13ad46f9 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
> @@ -430,6 +430,7 @@ struct mqd_manager *mqd_manager_init_v10(enum
> KFD_MQD_TYPE type,
>switch (type) {
>case KFD_MQD_TYPE_CP:
>pr_debug("%s@%i\n", __func__, __LINE__);
> + break;
>case KFD_MQD_TYPE_COMPUTE:
>pr_debug("%s@%i\n", __func__, __LINE__);
>mqd->allocate_mqd = allocate_mqd;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance calculation function
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Jani
> Nikula
> Sent: Thursday, August 4, 2022 5:55 AM
> To: Jouni Högander ; dri-
> de...@lists.freedesktop.org; intel-...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Siqueira, Rodrigo ; Li, Roman
> ; Manasi Navare ; Mika
> Kahola ; Jouni Högander
> ; Wentland, Harry
>
> Subject: Re: [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance
> calculation function
>
> On Tue, 19 Jul 2022, Jouni Högander wrote:
> > Luminance range calculation was split out into drm_edid.c and is now
> > part of edid parsing. Rely on values calculated during edid parsing
> > and use these for caps->aux_max_input_signal and caps-
> >aux_min_input_signal.
>
> Harry, I'll merge patches 1 & 3 in this series through drm-misc-next, because
> I
> think they're good to go, and fix stuff in i915.
>
> Can I get your rb/ack to merge this patch as well, or do you want to take this
> later via your tree?
You can take this via drm-misc.
Acked-by: Alex Deucher
>
> BR,
> Jani.
>
>
> >
> > v2: Use values calculated during edid parsing
> >
> > Cc: Roman Li
> > Cc: Rodrigo Siqueira
> > Cc: Harry Wentland
> > Cc: Lyude Paul
> > Cc: Mika Kahola
> > Cc: Jani Nikula
> > Cc: Manasi Navare
> > Signed-off-by: Jouni Högander
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35
> > +++
> > 1 file changed, 4 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 3e83fed540e8..eb7abdeb8653 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -2903,15 +2903,12 @@ static struct drm_mode_config_helper_funcs
> > amdgpu_dm_mode_config_helperfuncs = {
> >
> > static void update_connector_ext_caps(struct amdgpu_dm_connector
> > *aconnector) {
> > - u32 max_avg, min_cll, max, min, q, r;
> > struct amdgpu_dm_backlight_caps *caps;
> > struct amdgpu_display_manager *dm;
> > struct drm_connector *conn_base;
> > struct amdgpu_device *adev;
> > struct dc_link *link = NULL;
> > - static const u8 pre_computed_values[] = {
> > - 50, 51, 52, 53, 55, 56, 57, 58, 59, 61, 62, 63, 65, 66, 68, 69,
> > - 71, 72, 74, 75, 77, 79, 81, 82, 84, 86, 88, 90, 92, 94, 96, 98};
> > + struct drm_luminance_range_info *luminance_range;
> > int i;
> >
> > if (!aconnector || !aconnector->dc_link) @@ -2933,8 +2930,6 @@
> > static void update_connector_ext_caps(struct amdgpu_dm_connector
> *aconnector)
> > caps = &dm->backlight_caps[i];
> > caps->ext_caps = &aconnector->dc_link->dpcd_sink_ext_caps;
> > caps->aux_support = false;
> > - max_avg = conn_base->hdr_sink_metadata.hdmi_type1.max_fall;
> > - min_cll = conn_base->hdr_sink_metadata.hdmi_type1.min_cll;
> >
> > if (caps->ext_caps->bits.oled == 1 /*||
> > caps->ext_caps->bits.sdr_aux_backlight_control == 1 || @@
> > -2946,31 +2941,9 @@ static void update_connector_ext_caps(struct
> amdgpu_dm_connector *aconnector)
> > else if (amdgpu_backlight == 1)
> > caps->aux_support = true;
> >
> > - /* From the specification (CTA-861-G), for calculating the maximum
> > -* luminance we need to use:
> > -* Luminance = 50*2**(CV/32)
> > -* Where CV is a one-byte value.
> > -* For calculating this expression we may need float point precision;
> > -* to avoid this complexity level, we take advantage that CV is divided
> > -* by a constant. From the Euclids division algorithm, we know that
> CV
> > -* can be written as: CV = 32*q + r. Next, we replace CV in the
> > -* Luminance expression and get 50*(2**q)*(2**(r/32)), hence we
> just
> > -* need to pre-compute the value of r/32. For pre-computing the
> values
> > -* We just used the following Ruby line:
> > -* (0...32).each {|cv| puts (50*2**(cv/32.0)).round}
> > -* The results of the above expressions can be verified at
> > -* pre_computed_values.
> > -*/
> > - q = max_avg >> 5;
> > - r = max_avg % 32;
> > - max = (1 << q) * pre_computed_values[r];
> > -
> > - // min luminance: maxLum * (CV/255)^2 / 100
> > - q = DIV_ROUND_CLOSEST(min_cll, 255);
> > - min = max * DIV_ROUND_CLOSEST((q * q), 100);
> > -
> > - caps->aux_max_input_signal = max;
> > - caps->aux_min_input_signal = min;
> > + luminance_range = &conn_base->display_info.luminance_range;
> > + caps->aux_min_input_signal = luminance_range->min_luminance;
> > + caps->aux_max_input_signal = luminance_range->max_luminance;
> > }
> >
> > void amdgpu_dm_update_connector_after_detect(
>
> --
> Jani Nikula, Intel Open Source Graphics Center
RE: [Bug 215958] New: thunderbolt3 egpu cannot disconnect cleanly
[Public] > -Original Message- > From: Bjorn Helgaas > Sent: Monday, May 9, 2022 12:23 PM > To: Linux PCI > Cc: r087...@yahoo.it; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; amd-gfx > mailing list ; dri-devel de...@lists.freedesktop.org> > Subject: Re: [Bug 215958] New: thunderbolt3 egpu cannot disconnect cleanly > > On Sun, May 8, 2022 at 3:29 PM wrote: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz > > > illa.kernel.org%2Fshow_bug.cgi%3Fid%3D215958&data=05%7C01%7Cal > exan > > > der.deucher%40amd.com%7C8bb8567427844b05e5f808da31d8435f%7C3d > d8961fe48 > > > 84e608e11a82d994e183d%7C0%7C0%7C637877102168668221%7CUnkno > wn%7CTWFpbGZ > > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > 0%3 > > > D%7C3000%7C%7C%7C&sdata=PpcDBIpUW8vCX%2F4kM6Q8RjdgS1qw2 > uuWoWZXis4M > > dDQ%3D&reserved=0 > > > > Bug ID: 215958 > >Summary: thunderbolt3 egpu cannot disconnect cleanly > >Product: Drivers > >Version: 2.5 > > Kernel Version: 5.17.0-1003-oem #3-Ubuntu SMP PREEMPT > > Hardware: All > > OS: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: PCI > > Assignee: drivers_...@kernel-bugs.osdl.org > > Reporter: r087...@yahoo.it > > Regression: No > > I assume this is not a regression, right? If it is a regression, what > previous > kernel worked correctly? > > > I have an external egpu (Radeon 6600 RX) connected through > > thunderbolt3 to my Thinkpad X1 carbon 6th Gen.. When I disconnect the > > thunderbolt3 cable I get the following error in dmesg: > > > > [21874.194994] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195006] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.195123] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195129] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.195271] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195276] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.195406] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195411] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.195544] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:51 param:0x message:GetPptLimit? > > [21874.195550] amdgpu :0c:00.0: amdgpu: > > [smu_v11_0_get_current_power_limit] > > get PPT limit failed! > > [21874.195582] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195587] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227454] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.227463] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227532] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.227536] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227618] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.227621] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227700] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.227703] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227784] amdgpu :0c:00.0: amdgpu: > > [smu_v11_0_get_current_power_limit] > > get PPT limit failed! > > [21874.227804] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.514661] snd_hda_codec_hdmi hdaudioC1D0: Unable to sync > register > > 0x2f0d00. -5 [21874.
RE: RX 5500 XT: PCIe link speed stuck at Gen1 2.5GT/s by default
[Public] > -Original Message- > From: Bjorn Helgaas > Sent: Wednesday, March 30, 2022 7:45 AM > To: linux-...@vger.kernel.org > Cc: Deucher, Alexander ; Robert Hancock > ; dri-devel@lists.freedesktop.org > Subject: RX 5500 XT: PCIe link speed stuck at Gen1 2.5GT/s by default > > See > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.f > reedesktop.org%2Fdrm%2Famd%2F- > %2Fissues%2F1447&data=04%7C01%7Calexander.deucher%40amd.com > %7C01b4e1eed4ac4c97ab0408da1242abe9%7C3dd8961fe4884e608e11a82 > d994e183d%7C0%7C0%7C637842374822556101%7CUnknown%7CTWFpbGZ > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > 0%3D%7C3000&sdata=elFgBq%2FoCfqIO98aaGeS3d1omBdJj%2BSH6HO > 13oNaBWM%3D&reserved=0 > > This report was against DRM, but I'm mentioning it here because we've been > talking about some link speed init issues lately, and AFAICT the gitlab > reports > don't show up anywhere in lore. > Just noticed this. The GPU driver calls pcie_bandwidth_available() to get the speed and link widths of the link to root port. The driver then limits the link speed and number of lanes to the max available on the link. There's no reason to run the link faster than the slowest link in the chain. For the most part this works fine because I think the PCIe spec envisions that the links will negotiate the fastest link available when the system comes up. But it seems that some platforms don't always do this. Maybe pcie_bandwidth_available() should return the max bandwidth based on the caps of the links rather than the current status. That said, I'm not sure how you would differentiate between the platforms that came up in a slow link t save power vs platforms that came up in a slow link because there was some problem negotiating a faster link or who, if anyone would be responsible for making sure the links are upgraded when needed. Alex > Robert Hancock reported: > > > I'm using a RX 5500 XT card on an Asus PRIME H270-PRO motherboard, > > Intel i5-7500 CPU, with kernel 5.10.9 under Fedora 33. I noticed that > > in Linux, "lspci -vv" always showed the GPU PCIe link running at > > 2.5GT/s link speed and never seemed to change regardless of the > > application being run, while in Windows, GPU-Z shows the link running > > at the max supported 8GT/s speed when under graphical load. > > > > It seems like the driver thinks that 2.5GT/s is the max allowable > > speed, based on the pp_dpm_pcie file: > > > > > cd > /sys/devices/pci:00/:00:01.0/:01:00.0/:02:00.0/:0 > 3:00.0/ > > > cat pp_dpm_pcie > > 0: 2.5GT/s, x8 81Mhz * > > 1: 2.5GT/s, x8 619Mhz * > > > > I'm assuming that something is going wrong with the PCIe link speed > > detection in the driver. Using the "amdgpu.pcie_gen_cap=0x70007" > > kernel command line option seems to result in the driver detecting the > > proper 8GT/s maximum speed. > > > > lspci -vv output from booting without overriding the speed is > > attached.
Re: [PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers
[Public]
DCN 3.1.6 needs it, but I don't know if yellow carp needs it. I think this is
only applicable to kernel 5.18. @Kazlauskas,
Nicholas<mailto:nicholas.kazlaus...@amd.com> can you verify?
Alex
From: VURDIGERENATARAJ, CHANDAN
Sent: Wednesday, May 18, 2022 8:36 AM
To: Sasha Levin ; linux-ker...@vger.kernel.org
; sta...@vger.kernel.org
Cc: Yang, Eric ; haonan.wa...@amd.com
; Li, Sun peng (Leo) ; Pan, Xinhui
; Siqueira, Rodrigo ;
amd-...@lists.freedesktop.org ; Koenig,
Christian ; airl...@linux.ie ;
dri-devel@lists.freedesktop.org ;
dan...@ffwll.ch ; wyatt.w...@amd.com ;
Deucher, Alexander ; mikita.lip...@amd.com
; Wentland, Harry ; Kazlauskas,
Nicholas ; Kotarac, Pavle
Subject: RE: [PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10
related function pointers
Hi,
Is S0i3 verified for DCN 3.1.6 with this?
BR,
Chandan V N
>From: Eric Yang
>
>[ Upstream commit 9b9bd3f640640f94272a461b2dfe558f91b322c5 ]
>
> [Why]
>Z10 and S0i3 have some shared path. Previous code clean up , incorrectly
>removed these pointers, which breaks s0i3 restore
>
> [How]
>Do not clear the function pointers based on Z10 disable.
>
>Reviewed-by: Nicholas Kazlauskas
>Acked-by: Pavle Kotarac
>Signed-off-by: Eric Yang
>Signed-off-by: Alex Deucher
>Signed-off-by: Sasha Levin
>---
> drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 5 -
> 1 file changed, 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c
>b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c
>index d7559e5a99ce..e708f07fe75a 100644
>--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c
>+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c
>@@ -153,9 +153,4 @@ void dcn31_hw_sequencer_construct(struct dc *dc)
>dc->hwss.init_hw = dcn20_fpga_init_hw;
>dc->hwseq->funcs.init_pipes = NULL;
>}
>- if (dc->debug.disable_z10) {
>- /*hw not support z10 or sw disable it*/
>- dc->hwss.z10_restore = NULL;
>- dc->hwss.z10_save_init = NULL;
>- }
> }
>--
>2.35.1
>
RE: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of
> Vijendar Mukunda
> Sent: Monday, June 27, 2022 8:59 AM
> To: broo...@kernel.org; alsa-de...@alsa-project.org; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Dommati, Sunil-kumar ; David Airlie
> ; Hiregoudar, Basavaraj ;
> Pan, Xinhui ; open list ker...@vger.kernel.org>; Kai-Heng Feng ;
> Daniel Vetter ; Mukunda, Vijendar
> ; Deucher, Alexander
> ; Koenig, Christian
>
> Subject: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
>
> From: vijendar
>
> Fixed below checkpatch warnings and errors
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:131: CHECK: Comparison to
> NULL could be written "apd"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:150: CHECK: Comparison to
> NULL could be written "apd"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:196: CHECK: Prefer kernel
> type 'u64' over 'uint64_t'
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:224: CHECK: Please don't use
> multiple blank lines
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:226: CHECK: Comparison to
> NULL could be written "!adev->acp.acp_genpd"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:233: CHECK: Please don't use
> multiple blank lines
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:239: CHECK: Alignment should
> match open parenthesis
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:241: CHECK: Comparison to
> NULL could be written "!adev->acp.acp_cell"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:247: CHECK: Comparison to
> NULL could be written "!adev->acp.acp_res"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:253: CHECK: Comparison to
> NULL could be written "!i2s_pdata"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:350: CHECK: Alignment should
> match open parenthesis
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:550: ERROR: that open brace {
> should be on the previous line
>
> Signed-off-by: Vijendar Mukunda
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 27 +
> 1 file changed, 10 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> index cc9c9f8b23b2..ba1605ff521f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -128,7 +128,7 @@ static int acp_poweroff(struct generic_pm_domain
> *genpd)
> struct amdgpu_device *adev;
>
> apd = container_of(genpd, struct acp_pm_domain, gpd);
> - if (apd != NULL) {
> + if (apd) {
> adev = apd->adev;
> /* call smu to POWER GATE ACP block
>* smu will
> @@ -147,7 +147,7 @@ static int acp_poweron(struct generic_pm_domain
> *genpd)
> struct amdgpu_device *adev;
>
> apd = container_of(genpd, struct acp_pm_domain, gpd);
> - if (apd != NULL) {
> + if (apd) {
> adev = apd->adev;
> /* call smu to UNGATE ACP block
>* smu will
> @@ -193,7 +193,7 @@ static int acp_genpd_remove_device(struct device
> *dev, void *data) static int acp_hw_init(void *handle) {
> int r;
> - uint64_t acp_base;
> + u64 acp_base;
> u32 val = 0;
> u32 count = 0;
> struct i2s_platform_data *i2s_pdata = NULL; @@ -220,37 +220,32
> @@ static int acp_hw_init(void *handle)
> return -EINVAL;
>
> acp_base = adev->rmmio_base;
> -
> -
> adev->acp.acp_genpd = kzalloc(sizeof(struct acp_pm_domain),
> GFP_KERNEL);
> - if (adev->acp.acp_genpd == NULL)
> + if (!adev->acp.acp_genpd)
> return -ENOMEM;
>
> adev->acp.acp_genpd->gpd.name = "ACP_AUDIO";
> adev->acp.acp_genpd->gpd.power_off = acp_poweroff;
> adev->acp.acp_genpd->gpd.power_on = acp_poweron;
> -
> -
> adev->acp.acp_genpd->adev = adev;
>
> pm_genpd_init(&adev->acp.acp_genpd->gpd, NULL, false);
>
> - adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
> - GFP_KERNEL);
> + adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
> +GFP_KERNEL);
>
> - if (adev->acp.acp_cell == NULL) {
> + if (!adev->acp.acp_cell) {
> r = -ENOMEM;
> goto failure;
> }
>
> adev->acp.acp_res = kcalloc(5, sizeof(struct resource), GFP_KERNEL);
> - if (adev->acp.acp_res == NULL) {
> + if (!adev->acp.acp_res) {
>
RE: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
[AMD Official Use Only - General]
> -Original Message-
> From: Deucher, Alexander
> Sent: Monday, June 27, 2022 2:18 PM
> To: Vijendar Mukunda ; broo...@kernel.org;
> alsa-de...@alsa-project.org; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Dommati, Sunil-kumar ; David Airlie
> ; Hiregoudar, Basavaraj ;
> Pan, Xinhui ; open list ker...@vger.kernel.org>; Kai-Heng Feng ;
> Daniel Vetter ; Mukunda, Vijendar
> ; Koenig, Christian
>
> Subject: RE: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
>
> [AMD Official Use Only - General]
>
> > -Original Message-
> > From: amd-gfx On Behalf Of
> > Vijendar Mukunda
> > Sent: Monday, June 27, 2022 8:59 AM
> > To: broo...@kernel.org; alsa-de...@alsa-project.org; dri-
> > de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Cc: Dommati, Sunil-kumar ; David Airlie
> > ; Hiregoudar, Basavaraj
> > ; Pan, Xinhui ;
> open
> > list ; Kai-Heng Feng
> > ; Daniel Vetter ;
> > Mukunda, Vijendar ; Deucher, Alexander
> > ; Koenig, Christian
> >
> > Subject: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
> >
> > From: vijendar
> >
> > Fixed below checkpatch warnings and errors
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:131: CHECK: Comparison to
> NULL
> > could be written "apd"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:150: CHECK: Comparison to
> NULL
> > could be written "apd"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:196: CHECK: Prefer kernel
> type
> > 'u64' over 'uint64_t'
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:224: CHECK: Please don't use
> > multiple blank lines
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:226: CHECK: Comparison to
> NULL
> > could be written "!adev->acp.acp_genpd"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:233: CHECK: Please don't use
> > multiple blank lines
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:239: CHECK: Alignment
> should
> > match open parenthesis
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:241: CHECK: Comparison to
> NULL
> > could be written "!adev->acp.acp_cell"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:247: CHECK: Comparison to
> NULL
> > could be written "!adev->acp.acp_res"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:253: CHECK: Comparison to
> NULL
> > could be written "!i2s_pdata"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:350: CHECK: Alignment
> should
> > match open parenthesis
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:550: ERROR: that open brace
> {
> > should be on the previous line
> >
> > Signed-off-by: Vijendar Mukunda
>
> Reviewed-by: Alex Deucher
>
I'm also fine to have this go through the audio tree if it is a pre-requisite
for your jadeite audio series.
Alex
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 27
> > +
> > 1 file changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > index cc9c9f8b23b2..ba1605ff521f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > @@ -128,7 +128,7 @@ static int acp_poweroff(struct generic_pm_domain
> > *genpd)
> > struct amdgpu_device *adev;
> >
> > apd = container_of(genpd, struct acp_pm_domain, gpd);
> > - if (apd != NULL) {
> > + if (apd) {
> > adev = apd->adev;
> > /* call smu to POWER GATE ACP block
> > * smu will
> > @@ -147,7 +147,7 @@ static int acp_poweron(struct generic_pm_domain
> > *genpd)
> > struct amdgpu_device *adev;
> >
> > apd = container_of(genpd, struct acp_pm_domain, gpd);
> > - if (apd != NULL) {
> > + if (apd) {
> > adev = apd->adev;
> > /* call smu to UNGATE ACP block
> > * smu will
> > @@ -193,7 +193,7 @@ static int acp_genpd_remove_device(struct device
> > *dev, void *data) static int acp_hw_init(void *handle) {
> > int r;
> > - uint64_t acp_base;
> > + u64 acp_base;
> > u32 val = 0;
> > u32 count = 0;
> > struct i2s_platform_data *i2s_pdata = NULL; @@ -220,37 +220,32
> @@
> > static int acp_hw_init(void *handle)
> > return -EINVAL;
> >
> > acp_base = adev->rmmio_base;
> > -
> > -
> > adev->acp.acp_genpd = kzalloc(sizeof(struct acp_pm_do
RE: [PATCH] drm/amd/display: fix indentation in commit_planes_for_stream()
[AMD Official Use Only - General]
> -Original Message-
> From: Mahfooz, Hamza
> Sent: Wednesday, August 31, 2022 1:58 PM
> To: linux-ker...@vger.kernel.org
> Cc: Mahfooz, Hamza ; Wentland, Harry
> ; Li, Sun peng (Leo) ;
> Siqueira, Rodrigo ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Kazlauskas,
> Nicholas ; Lei, Jun ;
> Somasundaram, Meenakshikumar
> ; Lee, Alvin
> ; Leung, Martin ; Tam,
> Samson ; Hung, Alex ;
> Aberback, Joshua ; Liu, Wenjing
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: [PATCH] drm/amd/display: fix indentation in
> commit_planes_for_stream()
>
> Address the following warning:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this
> ‘if’ clause does not guard... [-Wmisleading-indentation]
> 3508 | if (update_type != UPDATE_TYPE_FAST)
> | ^~
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this
> statement, but the latter is misleadingly indented as if it were guarded by
> the
> ‘if’
> 3510 | if (update_type != UPDATE_TYPE_FAST)
> | ^~
>
> Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index b49237390cce..6c4948916e7e 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -3505,11 +3505,11 @@ static void commit_planes_for_stream(struct dc
> *dc,
> top_pipe_to_program-
> >stream_res.tg);
> }
>
> - if (update_type != UPDATE_TYPE_FAST)
> + if (update_type != UPDATE_TYPE_FAST) {
> dc->hwss.post_unlock_program_front_end(dc, context);
> - if (update_type != UPDATE_TYPE_FAST)
> - if (dc->hwss.commit_subvp_config)
> - dc->hwss.commit_subvp_config(dc,
> context);
> + if (dc->hwss.commit_subvp_config)
> + dc->hwss.commit_subvp_config(dc, context);
> + }
>
> /* Since phantom pipe programming is moved to
> post_unlock_program_front_end,
>* move the SubVP lock to after the phantom pipes have been setup
> --
> 2.37.2
Re: [PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream()
[Public] Acked-by: Alex Deucher From: Mahfooz, Hamza Sent: Thursday, September 1, 2022 10:15 AM To: linux-ker...@vger.kernel.org Cc: Mahfooz, Hamza ; Wentland, Harry ; Li, Sun peng (Leo) ; Siqueira, Rodrigo ; Deucher, Alexander ; Koenig, Christian ; Pan, Xinhui ; David Airlie ; Daniel Vetter ; Kazlauskas, Nicholas ; Lei, Jun ; Somasundaram, Meenakshikumar ; Lee, Alvin ; Leung, Martin ; Tam, Samson ; Hung, Alex ; Liu, Wenjing ; Aberback, Joshua ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org Subject: [PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream() Address the following warning: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] 3508 | if (update_type != UPDATE_TYPE_FAST) | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 3510 | if (update_type != UPDATE_TYPE_FAST) | ^~ Signed-off-by: Hamza Mahfooz --- v2: implement feedback from Alvin --- drivers/gpu/drm/amd/display/dc/core/dc.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index b49237390cce..9860bf38c547 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -3507,9 +3507,10 @@ static void commit_planes_for_stream(struct dc *dc, if (update_type != UPDATE_TYPE_FAST) dc->hwss.post_unlock_program_front_end(dc, context); - if (update_type != UPDATE_TYPE_FAST) - if (dc->hwss.commit_subvp_config) - dc->hwss.commit_subvp_config(dc, context); + + if (update_type != UPDATE_TYPE_FAST) + if (dc->hwss.commit_subvp_config) + dc->hwss.commit_subvp_config(dc, context); /* Since phantom pipe programming is moved to post_unlock_program_front_end, * move the SubVP lock to after the phantom pipes have been setup -- 2.37.2
Re: [PATCH] drm/amdgpu: cleanup coding style in amdgpu_amdkfd_gpuvm.c
[Public]
Yeah, seems to be a mix. I don't have a strong opinion as long as it has MIT.
Alex
From: Kuehling, Felix
Sent: Tuesday, September 6, 2022 9:46 AM
To: Jingyu Wang ; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; airl...@linux.ie ;
dan...@ffwll.ch
Cc: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amdgpu: cleanup coding style in amdgpu_amdkfd_gpuvm.c
Am 2022-09-05 um 04:38 schrieb Jingyu Wang:
> Fix everything checkpatch.pl complained about in amdgpu_amdkfd_gpuvm.c
>
> Signed-off-by: Jingyu Wang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index cbd593f7d553..eff596c60c89 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: MIT
I'm not sure if this is correct. We've used "GPL-2.0 OR MIT" in KFD. In
amdgpu there is currently a mix of licenses. Alex, do you want to make a
call on a consistent one to use in amdgpu?
Other than that, this patch is
Reviewed-by: Felix Kuehling
> /*
>* Copyright 2014-2018 Advanced Micro Devices, Inc.
>*
> @@ -1612,6 +1613,7 @@ size_t amdgpu_amdkfd_get_available_memory(struct
> amdgpu_device *adev)
>uint64_t reserved_for_pt =
>ESTIMATE_PT_SIZE(amdgpu_amdkfd_total_mem_size);
>size_t available;
> +
>spin_lock(&kfd_mem_limit.mem_limit_lock);
>available = adev->gmc.real_vram_size
>- adev->kfd.vram_used_aligned
> @@ -2216,7 +2218,7 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct
> amdgpu_device *adev,
> {
>if (atomic_read(&adev->gmc.vm_fault_info_updated) == 1) {
>*mem = *adev->gmc.vm_fault_info;
> - mb();
> + mb(); /* make sure read happened */
>atomic_set(&adev->gmc.vm_fault_info_updated, 0);
>}
>return 0;
>
> base-commit: e47eb90a0a9ae20b82635b9b99a8d0979b757ad8
RE: [PATCH 0/2] drm: replace magic nuumbers
> -Original Message- > From: amd-gfx On Behalf Of > Bjorn Helgaas > Sent: Thursday, November 7, 2019 5:21 PM > To: Deucher, Alexander ; Koenig, Christian > ; Zhou, David(ChunMing) > ; David Airlie ; Daniel Vetter > > Cc: Bjorn Helgaas ; dri-devel@lists.freedesktop.org; > amd-...@lists.freedesktop.org; Frederick Lawler ; > linux-ker...@vger.kernel.org > Subject: [PATCH 0/2] drm: replace magic nuumbers > > From: Bjorn Helgaas > > amdgpu and radeon do a bit of mucking with the PCIe Link Control 2 register, > some of it using hard-coded magic numbers. The idea here is to replace > those with #defines. > > I haven't signed off on these because the first one actually changes the bits > involved because the existing code looks like it might have a typo. > But I have no way to know for sure. > It is a typo. Your patches look correct to me. The series is: Reviewed-by: Alex Deucher > I don't intend the Target Link Speed patch to change anything, so it should be > straightforward to review. > > Bjorn Helgaas (2): > drm: replace Compliance/Margin magic numbers with PCI_EXP_LNKCTL2 > definitions > drm: replace Target Link Speed magic numbers with PCI_EXP_LNKCTL2 > definitions > > drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++ > drivers/gpu/drm/amd/amdgpu/si.c | 18 +++--- > drivers/gpu/drm/radeon/cik.c | 22 ++ > drivers/gpu/drm/radeon/si.c | 22 ++ > include/uapi/linux/pci_regs.h| 2 ++ > 5 files changed, 55 insertions(+), 31 deletions(-) > > -- > 2.24.0.rc1.363.gb1bccd3e3d-goog > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V3 0/3] drm: replace magic numbers
> -Original Message- > From: amd-gfx On Behalf Of > Bjorn Helgaas > Sent: Tuesday, November 12, 2019 12:35 PM > To: Deucher, Alexander ; Koenig, Christian > ; Zhou, David(ChunMing) > ; David Airlie ; Daniel Vetter > > Cc: Frederick Lawler ; linux-...@vger.kernel.org; > Michel Dänzer ; linux-ker...@vger.kernel.org; dri- > de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Bjorn Helgaas > ; Ilia Mirkin > Subject: [PATCH V3 0/3] drm: replace magic numbers > > From: Bjorn Helgaas > > amdgpu and radeon do a bit of mucking with the PCIe Link Control 2 register, > some of it using hard-coded magic numbers. The idea here is to replace > those with #defines. > > Since v2: > - Fix a gpu_cfg2 case in amdgpu/si.c that I had missed > - Separate out the functional changes for better bisection (thanks, > Michel!) > - Add #defines in a patch by themselves (so a GPU revert wouldn't break > other potential users) > - Squash all the magic number -> #define changes into one patch > > Since v1: > - Add my signed-off-by and Alex's reviewed-by. > Series is: Reviewed-by: Alex Deucher I'm happy to have it go through whatever tree is easiest for you. Thanks, Alex > Bjorn Helgaas (3): > PCI: Add #defines for Enter Compliance, Transmit Margin > drm: correct Transmit Margin masks > drm: replace numbers with PCI_EXP_LNKCTL2 definitions > > drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++ > drivers/gpu/drm/amd/amdgpu/si.c | 22 ++ > drivers/gpu/drm/radeon/cik.c | 22 ++ > drivers/gpu/drm/radeon/si.c | 22 ++ > include/uapi/linux/pci_regs.h| 2 ++ > 5 files changed, 58 insertions(+), 32 deletions(-) > > -- > 2.24.0.rc1.363.gb1bccd3e3d-goog > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v7 04/11] drm: revocation check at drm subsystem
> -Original Message- > From: Wentland, Harry > Sent: Wednesday, September 11, 2019 8:16 PM > To: Ramalingam C ; intel- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > daniel.vet...@intel.com > Cc: gwan-gyeong@intel.com; Kumar, Ranjeet > ; Deucher, Alexander > ; Lakha, Bhawanpreet > > Subject: Re: [PATCH v7 04/11] drm: revocation check at drm subsystem > > Adding a couple AMD guys. > > I know this is already merged but I have a few questions after some internal > discussions. > > On 2019-05-07 12:27 p.m., Ramalingam C wrote: > > On every hdcp revocation check request SRM is read from fw file > > /lib/firmware/display_hdcp_srm.bin > > > > According to section 5 of the HDCP 2.3 spec [1] a device compliant with HDCP > 2.0 and higher must be capable of storing and updating the SRM in non- > volatile memory. Section 5.2 describes how this SRM needs to be updated > when a new version is served alongside protected content. > > Isn't /lib/firmware intended for static firmware making updates to the folder > problematic for anyone but the system's package maintainer? I've heard /lib > might even be treated as read-only in certain environments. > This would mean it'd be impossible to support HDCP 2.x on those systems. > > Wouldn't it be easier to provide a sysfs entry for SRM that allows userspace > (e.g. system startup/shutdown scripts) to (a) retrieve the SRM from the > HDCP implementation for non-volatile storage and (b) to pass the SRM to the > HDCP implementation for revocation checking? Also, IIRC, for level 1 support, I think the srm parsing has to happen on something other than the CPU, so I'm not sure where need to do any parsing in software, at least for HDCP 2.x. Alex > > [1] > https://www.digital- > cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_ > 3.pdf > > Thanks, > Harry > > > SRM table is parsed and stored at drm_hdcp.c, with functions exported > > for the services for revocation check from drivers (which implements > > the HDCP authentication) > > > > This patch handles the HDCP1.4 and 2.2 versions of SRM table. > > > > v2: > > moved the uAPI to request_firmware_direct() [Daniel] > > v3: > > kdoc added. [Daniel] > > srm_header unified and bit field definitions are removed. [Daniel] > > locking improved. [Daniel] > > vrl length violation is fixed. [Daniel] > > v4: > > s/__swab16/be16_to_cpu [Daniel] > > be24_to_cpu is done through a global func [Daniel] > > Unused variables are removed. [Daniel] > > unchecked return values are dropped from static funcs [Daniel] > > > > Signed-off-by: Ramalingam C > > Acked-by: Satyeshwar Singh > > Reviewed-by: Daniel Vetter > > --- > > Documentation/gpu/drm-kms-helpers.rst | 6 + > > drivers/gpu/drm/Makefile | 2 +- > > drivers/gpu/drm/drm_hdcp.c| 333 > ++ > > drivers/gpu/drm/drm_internal.h| 4 + > > drivers/gpu/drm/drm_sysfs.c | 2 + > > include/drm/drm_hdcp.h| 24 ++ > > 6 files changed, 370 insertions(+), 1 deletion(-) create mode 100644 > > drivers/gpu/drm/drm_hdcp.c > > > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > > b/Documentation/gpu/drm-kms-helpers.rst > > index 14102ae035dc..0fe726a6ee67 100644 > > --- a/Documentation/gpu/drm-kms-helpers.rst > > +++ b/Documentation/gpu/drm-kms-helpers.rst > > @@ -181,6 +181,12 @@ Panel Helper Reference .. kernel-doc:: > > drivers/gpu/drm/drm_panel_orientation_quirks.c > > :export: > > > > +HDCP Helper Functions Reference > > +=== > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c > > + :export: > > + > > Display Port Helper Functions Reference > > === > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index > > 72f5036d9bfa..dd02e9dec810 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \ > > drm_plane.o drm_color_mgmt.o drm_print.o \ > > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ > > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ > > - drm_atomic_uapi.o > > + drm_atomic_uapi.o drm_hdcp.o > > > > drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o > > drm_context.o drm_dma.o drm_scatter.o drm_lock.
Re: [PATCH] drm/amdgpu: release allocated memory
Maybe add a comment here in the code to avoid confusion in the future. Alex From: Koenig, Christian Sent: Saturday, September 21, 2019 7:32 AM To: Navid Emamdoost Cc: emamd...@umn.edu ; smcca...@umn.edu ; k...@umn.edu ; Deucher, Alexander ; Zhou, David(ChunMing) ; David Airlie ; Daniel Vetter ; Sam Ravnborg ; Rex Zhu ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org Subject: Re: [PATCH] drm/amdgpu: release allocated memory Am 21.09.19 um 00:49 schrieb Navid Emamdoost: > In amdgpu_vmid_grab_idle, fences is being leaked in one execution path. > The missing kfree was added. NAK, the array is freed by the dma_fence_array. This is a double free. Regards, Christian. > > Signed-off-by: Navid Emamdoost > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > index 57b3d8a9bef3..9063cd36fa94 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > @@ -244,6 +244,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, >r = amdgpu_sync_fence(adev, sync, &array->base, false); >dma_fence_put(ring->vmid_wait); >ring->vmid_wait = &array->base; > + kfree(fences); >return r; >} >kfree(fences); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/r128: make ATI PCI GART part of its only user, r128
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, November 19, 2019 5:06 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula ; Deucher, Alexander
> ; Daniel Vetter ;
> Dave Airlie
> Subject: [PATCH] drm/r128: make ATI PCI GART part of its only user, r128
>
> The ATI Rage 128 driver has been the only user of ATI PCI GART code since
> Radeon dropped UMS support in commit 8333f607a631 ("drm/radeon:
> remove UMS support"). Clean up the drm top level directory, Kconfig and
> Makefile by making ati_pcigart.[ch] part of r128. Drop the
> CONFIG_DRM_ATI_PCIGART config option made redundant by the change.
>
> This reduces drm.ko module size slightly when legacy drivers are enabled,
> and moves the baggage to r128.ko instead.
>
> Cc: Alex Deucher
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/Kconfig | 4
> drivers/gpu/drm/Makefile| 1 -
> drivers/gpu/drm/r128/Makefile | 2 +-
> drivers/gpu/drm/{ => r128}/ati_pcigart.c| 5 ++---
> {include/drm => drivers/gpu/drm/r128}/ati_pcigart.h | 0
> drivers/gpu/drm/r128/r128_drv.h | 3 ++-
> 6 files changed, 5 insertions(+), 10 deletions(-) rename drivers/gpu/drm/{
> => r128}/ati_pcigart.c (98%) rename {include/drm =>
> drivers/gpu/drm/r128}/ati_pcigart.h (100%)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index
> 76db8bc0dd1f..6d55a73d5d2b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -297,9 +297,6 @@ config DRM_VKMS
>
> If M is selected the module will be called vkms.
>
> -config DRM_ATI_PCIGART
> -bool
> -
> source "drivers/gpu/drm/exynos/Kconfig"
>
> source "drivers/gpu/drm/rockchip/Kconfig"
> @@ -396,7 +393,6 @@ menuconfig DRM_LEGACY
> bool "Enable legacy drivers (DANGEROUS)"
> depends on DRM && MMU
> select DRM_VM
> - select DRM_ATI_PCIGART if PCI
> help
> Enable legacy DRI1 drivers. Those drivers expose unsafe and
> dangerous
> APIs to user-space, which can be used to circumvent access diff --git
> a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index
> 9f1c7c486f88..d9bcc9f2a0a4 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -25,7 +25,6 @@ drm-$(CONFIG_DRM_VM) += drm_vm.o
> drm-$(CONFIG_COMPAT) += drm_ioc32.o
> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> drm-$(CONFIG_DRM_GEM_SHMEM_HELPER) +=
> drm_gem_shmem_helper.o
> -drm-$(CONFIG_DRM_ATI_PCIGART) += ati_pcigart.o
> drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> drm-$(CONFIG_OF) += drm_of.o
> drm-$(CONFIG_AGP) += drm_agpsupport.o
> diff --git a/drivers/gpu/drm/r128/Makefile b/drivers/gpu/drm/r128/Makefile
> index ae8a1860c6b8..c07a069533ef 100644
> --- a/drivers/gpu/drm/r128/Makefile
> +++ b/drivers/gpu/drm/r128/Makefile
> @@ -3,7 +3,7 @@
> # Makefile for the drm device driver. This driver provides support for the
> #
> Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> -r128-y := r128_drv.o r128_cce.o r128_state.o r128_irq.o
> +r128-y := r128_drv.o r128_cce.o r128_state.o r128_irq.o ati_pcigart.o
>
> r128-$(CONFIG_COMPAT) += r128_ioc32.o
>
> diff --git a/drivers/gpu/drm/ati_pcigart.c
> b/drivers/gpu/drm/r128/ati_pcigart.c
> similarity index 98%
> rename from drivers/gpu/drm/ati_pcigart.c rename to
> drivers/gpu/drm/r128/ati_pcigart.c
> index 580aa2676358..9b4072f97215 100644
> --- a/drivers/gpu/drm/ati_pcigart.c
> +++ b/drivers/gpu/drm/r128/ati_pcigart.c
> @@ -33,11 +33,12 @@
>
> #include
>
> -#include
> #include
> #include
> #include
>
> +#include "ati_pcigart.h"
> +
> # define ATI_PCIGART_PAGE_SIZE 4096/**< PCI GART page
> size */
>
> static int drm_ati_alloc_pcigart_table(struct drm_device *dev, @@ -95,7
> +96,6 @@ int drm_ati_pcigart_cleanup(struct drm_device *dev, struct
> drm_ati_pcigart_info
>
> return 1;
> }
> -EXPORT_SYMBOL(drm_ati_pcigart_cleanup);
>
> int drm_ati_pcigart_init(struct drm_device *dev, struct drm_ati_pcigart_info
> *gart_info) { @@ -207,4 +207,3 @@ int drm_ati_pcigart_init(struct
> drm_device *dev, struct drm_ati_pcigart_info *ga
> gart_info->bus_addr = bus_address;
> return ret;
> }
> -EXPORT_SYMBOL(drm_ati_pcigart_init);
> diff --git a/include/drm/ati_pcigart.h b/drivers/gpu/drm/r128/ati_pcigart.h
> similarity index 100%
> rename from include/drm/ati_pcigart.h
>
Re: [PATCH] drm/amd: Fix Kconfig indentation
Reviewed-by: Alex Deucher From: Krzysztof Kozlowski Sent: Thursday, November 21, 2019 8:29 AM To: linux-ker...@vger.kernel.org Cc: Krzysztof Kozlowski ; Deucher, Alexander ; Koenig, Christian ; Zhou, David(ChunMing) ; David Airlie ; Daniel Vetter ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org Subject: [PATCH] drm/amd: Fix Kconfig indentation Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/amd/acp/Kconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig index d968c2471412..19bae9100da4 100644 --- a/drivers/gpu/drm/amd/acp/Kconfig +++ b/drivers/gpu/drm/amd/acp/Kconfig @@ -2,11 +2,11 @@ menu "ACP (Audio CoProcessor) Configuration" config DRM_AMD_ACP - bool "Enable AMD Audio CoProcessor IP support" - depends on DRM_AMDGPU - select MFD_CORE - select PM_GENERIC_DOMAINS if PM - help + bool "Enable AMD Audio CoProcessor IP support" + depends on DRM_AMDGPU + select MFD_CORE + select PM_GENERIC_DOMAINS if PM + help Choose this option to enable ACP IP support for AMD SOCs. This adds the ACP (Audio CoProcessor) IP driver and wires it up into the amdgpu driver. The ACP block provides the DMA -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 0/7] PCI: Prefer pcie_capability_read_word()
> -Original Message- > From: amd-gfx On Behalf Of > Bjorn Helgaas > Sent: Thursday, November 21, 2019 9:02 AM > To: linux-...@vger.kernel.org > Cc: Zhou, David(ChunMing) ; Frederick Lawler > ; Dave Airlie ; linux- > ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Bjorn Helgaas > ; amd-...@lists.freedesktop.org; Daniel Vetter > ; Alex Deucher ; Koenig, > Christian > Subject: [PATCH v2 0/7] PCI: Prefer pcie_capability_read_word() > > From: Bjorn Helgaas > > Use pcie_capability_read_word() and similar instead of using > pci_read_config_word() directly. Add #defines to replace some magic > numbers. Fix typos in use of Transmit Margin field. > > These are currently on my pci/misc branch for v5.5. Let me know if you see > any issues. > Series is: Reviewed-by: Alex Deucher > > Bjorn Helgaas (5): > PCI: Add #defines for Enter Compliance, Transmit Margin > drm/amdgpu: Correct Transmit Margin masks > drm/amdgpu: Replace numbers with PCI_EXP_LNKCTL2 definitions > drm/radeon: Correct Transmit Margin masks > drm/radeon: Replace numbers with PCI_EXP_LNKCTL2 definitions > > Frederick Lawler (2): > drm/amdgpu: Prefer pcie_capability_read_word() > drm/radeon: Prefer pcie_capability_read_word() > > drivers/gpu/drm/amd/amdgpu/cik.c | 95 +++ > drivers/gpu/drm/amd/amdgpu/si.c | 97 > drivers/gpu/drm/radeon/cik.c | 94 +++ > drivers/gpu/drm/radeon/si.c | 97 > include/uapi/linux/pci_regs.h| 2 + > 5 files changed, 243 insertions(+), 142 deletions(-) > > -- > 2.24.0.432.g9d3f5f5b63-goog > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
I recently updated amd-staging-drm-next. Apply whatever makes sense for now
and it'll naturally fall out in the next rebase.
Alex
From: Grodzovsky, Andrey
Sent: Monday, November 25, 2019 7:09 PM
To: Deng, Emily
Cc: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Koenig,
Christian ; steven.pr...@arm.com
; Deucher, Alexander
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Christian asked to submit it to drm-misc instead of our drm-next to avoid later
conflicts with Steven's patch which he mentioned in this thread which is not in
drm-next yet.
Christian, Alex, once this merged to drm-misc I guess we need to pull all
latest changes from there to drm-next so the issue Emily reported can be
avoided.
Andrey
From: Deng, Emily
Sent: 25 November 2019 16:44:36
To: Grodzovsky, Andrey
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
Christian; steven.pr...@arm.com; Grodzovsky, Andrey
Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
[AMD Official Use Only - Internal Distribution Only]
Hi Andrey,
Seems you didn't submit this patch?
Best wishes
Emily Deng
>-Original Message-
>From: Andrey Grodzovsky
>Sent: Monday, November 25, 2019 12:51 PM
>Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>Christian ; Deng, Emily
>; steven.pr...@arm.com; Grodzovsky, Andrey
>
>Subject: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>
>Problem:
>Due to a race between drm_sched_cleanup_jobs in sched thread and
>drm_sched_job_timedout in timeout work there is a possiblity that bad job
>was already freed while still being accessed from the timeout thread.
>
>Fix:
>Instead of just peeking at the bad job in the mirror list remove it from the
>list
>under lock and then put it back later when we are garanteed no race with
>main sched thread is possible which is after the thread is parked.
>
>v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.
>
>v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
>drm_sched_get_cleanup_job already has a lock there.
>
>v4: Fix comments to relfect latest code in drm-misc.
>
>Signed-off-by: Andrey Grodzovsky
>Reviewed-by: Christian König
>Tested-by: Emily Deng
>---
> drivers/gpu/drm/scheduler/sched_main.c | 27
>+++
> 1 file changed, 27 insertions(+)
>
>diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>b/drivers/gpu/drm/scheduler/sched_main.c
>index 6774955..1bf9c40 100644
>--- a/drivers/gpu/drm/scheduler/sched_main.c
>+++ b/drivers/gpu/drm/scheduler/sched_main.c
>@@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
>work_struct *work)
> unsigned long flags;
>
> sched = container_of(work, struct drm_gpu_scheduler,
>work_tdr.work);
>+
>+ /* Protects against concurrent deletion in
>drm_sched_get_cleanup_job */
>+ spin_lock_irqsave(&sched->job_list_lock, flags);
> job = list_first_entry_or_null(&sched->ring_mirror_list,
> struct drm_sched_job, node);
>
> if (job) {
>+ /*
>+ * Remove the bad job so it cannot be freed by concurrent
>+ * drm_sched_cleanup_jobs. It will be reinserted back after
>sched->thread
>+ * is parked at which point it's safe.
>+ */
>+ list_del_init(&job->node);
>+ spin_unlock_irqrestore(&sched->job_list_lock, flags);
>+
> job->sched->ops->timedout_job(job);
>
> /*
>@@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct
>work_struct *work)
> job->sched->ops->free_job(job);
> sched->free_guilty = false;
> }
>+ } else {
>+ spin_unlock_irqrestore(&sched->job_list_lock, flags);
> }
>
> spin_lock_irqsave(&sched->job_list_lock, flags); @@ -370,6 +383,20
>@@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
>drm_sched_job *bad)
> kthread_park(sched->thread);
>
> /*
>+ * Reinsert back the bad job here - now it's safe as
>+ * drm_sched_get_cleanup_job cannot race against us and release the
>+ * bad job at this point - we parked (waited for) any in progress
>+ * (earlier) cleanups and drm_sched_get_cleanup_job will not be
>called
>+ * now until the scheduler thread is unparked.
>+ */
>+ if (bad && bad->sched == sched)
>+ /*
>+ * Ad
Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
[AMD Official Use Only - Internal Distribution Only]
Please go ahead an apply whatever version is necessary for amd-staging-drm-next.
Alex
From: Grodzovsky, Andrey
Sent: Tuesday, December 3, 2019 2:10 PM
To: Deng, Emily ; Deucher, Alexander
Cc: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Koenig,
Christian ; steven.pr...@arm.com
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn't pull to amd-staging-drm-next yet.
Andrey
On 12/2/19 2:24 PM, Deng, Emily wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Andrey,
> Seems this patch is still not in amd-staging-drm-next?
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Deng, Emily
>> Sent: Tuesday, November 26, 2019 4:41 PM
>> To: Grodzovsky, Andrey
>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>> Christian ; steven.pr...@arm.com
>> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Reviewed-by: Emily Deng
>>
>>> -Original Message-
>>> From: Grodzovsky, Andrey
>>> Sent: Tuesday, November 26, 2019 7:37 AM
>>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
>>> Koenig, Christian ; Deng, Emily
>>> ; steven.pr...@arm.com
>>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>>
>>> Ping
>>>
>>> Andrey
>>>
>>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
>>>> Problem:
>>>> Due to a race between drm_sched_cleanup_jobs in sched thread and
>>>> drm_sched_job_timedout in timeout work there is a possiblity that bad
>>>> job was already freed while still being accessed from the timeout
>>>> thread.
>>>>
>>>> Fix:
>>>> Instead of just peeking at the bad job in the mirror list remove it
>>>> from the list under lock and then put it back later when we are
>>>> garanteed no race with main sched thread is possible which is after
>>>> the thread is parked.
>>>>
>>>> v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.
>>>>
>>>> v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
>>>> drm_sched_get_cleanup_job already has a lock there.
>>>>
>>>> v4: Fix comments to relfect latest code in drm-misc.
>>>>
>>>> Signed-off-by: Andrey Grodzovsky
>>>> Reviewed-by: Christian König
>>>> Tested-by: Emily Deng
>>>> ---
>>>>drivers/gpu/drm/scheduler/sched_main.c | 27
>>> +++
>>>>1 file changed, 27 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>>> index 6774955..1bf9c40 100644
>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>>> @@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
>>>> unsigned long flags;
>>>>
>>>> sched = container_of(work, struct drm_gpu_scheduler,
>>>> work_tdr.work);
>>>> +
>>>> + /* Protects against concurrent deletion in
>>> drm_sched_get_cleanup_job */
>>>> + spin_lock_irqsave(&sched->job_list_lock, flags);
>>>> job = list_first_entry_or_null(&sched->ring_mirror_list,
>>>>struct drm_sched_job, node);
>>>>
>>>> if (job) {
>>>> + /*
>>>> + * Remove the bad job so it cannot be freed by concurrent
>>>> + * drm_sched_cleanup_jobs. It will be reinserted back after
>>> sched->thread
>>>> + * is parked at which point it's safe.
>>>> + */
>>>> + list_del_init(&job->node);
>>>> + spin_unlock_irqrestore(&sched->job_list_lock, flags);
>>>> +
>>>> job->sched->ops->timedout_job(job);
>>>>
>>>> /*
>>>> @@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
>>>> job->sched->ops->free_job(job);
>>>>
Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
[AMD Official Use Only - Internal Distribution Only] Cherry pick whatever dependencies you need or pick the older version of the patch. Either way works. Alex From: Grodzovsky, Andrey Sent: Tuesday, December 3, 2019 2:57 PM To: Deucher, Alexander ; Deng, Emily Cc: dri-devel@lists.freedesktop.org ; amd-...@lists.freedesktop.org ; Koenig, Christian ; steven.pr...@arm.com Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job. I don't think i can apply this patch 'as is' as this has dependency on patch by Steven which also wasn't applied yet - 588b982 Steven Price6 weeks ago drm: Don't free jobs in wait_event_interruptible() Andrey On 12/3/19 2:44 PM, Deucher, Alexander wrote: [AMD Official Use Only - Internal Distribution Only] Please go ahead an apply whatever version is necessary for amd-staging-drm-next. Alex From: Grodzovsky, Andrey <mailto:andrey.grodzov...@amd.com> Sent: Tuesday, December 3, 2019 2:10 PM To: Deng, Emily <mailto:emily.d...@amd.com>; Deucher, Alexander <mailto:alexander.deuc...@amd.com> Cc: dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org> <mailto:dri-devel@lists.freedesktop.org>; amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org> <mailto:amd-...@lists.freedesktop.org>; Koenig, Christian <mailto:christian.koe...@amd.com>; steven.pr...@arm.com<mailto:steven.pr...@arm.com> <mailto:steven.pr...@arm.com> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job. Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian didn't pull to amd-staging-drm-next yet. Andrey On 12/2/19 2:24 PM, Deng, Emily wrote: > [AMD Official Use Only - Internal Distribution Only] > > Hi Andrey, > Seems this patch is still not in amd-staging-drm-next? > > Best wishes > Emily Deng > > > >> -Original Message- >> From: Deng, Emily >> Sent: Tuesday, November 26, 2019 4:41 PM >> To: Grodzovsky, Andrey >> <mailto:andrey.grodzov...@amd.com> >> Cc: dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org>; >> amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org>; Koenig, >> Christian <mailto:christian.koe...@amd.com>; >> steven.pr...@arm.com<mailto:steven.pr...@arm.com> >> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job. >> >> [AMD Official Use Only - Internal Distribution Only] >> >> Reviewed-by: Emily Deng <mailto:emily.d...@amd.com> >> >>> -Original Message- >>> From: Grodzovsky, Andrey >>> <mailto:andrey.grodzov...@amd.com> >>> Sent: Tuesday, November 26, 2019 7:37 AM >>> Cc: >>> dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org>; >>> amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org>; >>> Koenig, Christian >>> <mailto:christian.koe...@amd.com>; Deng, Emily >>> <mailto:emily.d...@amd.com>; >>> steven.pr...@arm.com<mailto:steven.pr...@arm.com> >>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job. >>> >>> Ping >>> >>> Andrey >>> >>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote: >>>> Problem: >>>> Due to a race between drm_sched_cleanup_jobs in sched thread and >>>> drm_sched_job_timedout in timeout work there is a possiblity that bad >>>> job was already freed while still being accessed from the timeout >>>> thread. >>>> >>>> Fix: >>>> Instead of just peeking at the bad job in the mirror list remove it >>>> from the list under lock and then put it back later when we are >>>> garanteed no race with main sched thread is possible which is after >>>> the thread is parked. >>>> >>>> v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs. >>>> >>>> v3: Rebase on top of drm-misc-next. v2 is not needed anymore as >>>> drm_sched_get_cleanup_job already has a lock there. >>>> >>>> v4: Fix comments to relfect latest code in drm-misc. >>>> >>>> Signed-off-by: Andrey Grodzovsky >>>> <mailto:andrey.grodzov...@amd.com> >>>> Reviewed-by: Christian König >>>> <mailto:christian.koe...@amd.com> >>>> Tested-by: Emily Deng <mailto:emily.d...@amd.com> >>>> --- >>>>drivers/gpu/drm/scheduler/sched_main.c | 27 >>> +++
RE: [PATCH] drm/amd/display: fix undefined struct member reference
> -Original Message-
> From: Kazlauskas, Nicholas
> Sent: Tuesday, December 10, 2019 3:56 PM
> To: Liu, Zhan ; Arnd Bergmann ;
> Wentland, Harry ; Li, Sun peng (Leo)
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
>
> Cc: Liu, Charlene ; Yang, Eric
> ; linux-ker...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; Cornij, Nikola ;
> Laktyushkin, Dmytro ; dri-
> de...@lists.freedesktop.org; Lei, Jun ; Lakha,
> Bhawanpreet
> Subject: Re: [PATCH] drm/amd/display: fix undefined struct member
> reference
>
> On 2019-12-10 3:54 p.m., Liu, Zhan wrote:
> >
> >
> >> -Original Message-
> >> From: Arnd Bergmann
> >> Sent: 2019/December/10, Tuesday 3:31 PM
> >> To: Wentland, Harry ; Li, Sun peng (Leo)
> >> ; Deucher, Alexander
> ;
> >> Koenig, Christian ; Zhou, David(ChunMing)
> >> ; David Airlie ; Daniel Vetter
> >> ; Liu, Zhan
> >> Cc: Arnd Bergmann ; Laktyushkin, Dmytro
> >> ; Lakha, Bhawanpreet
> >> ; Lei, Jun ; Liu,
> >> Charlene ; Yang, Eric ;
> >> Cornij, Nikola ;
> >> amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >> linux-ker...@vger.kernel.org
> >> Subject: [PATCH] drm/amd/display: fix undefined struct member
> >> reference
> >>
> >> An initialization was added for two optional struct members. One of
> >> these is always present in the dcn20_resource file, but the other one
> >> depends on CONFIG_DRM_AMD_DC_DSC_SUPPORT and causes a build
> failure
> >> if that is
> >> missing:
> >>
> >>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:926:1
> >> 4: error: excess elements in struct initializer [-Werror]
> >> .num_dsc = 5,
> >>
> >> Add another #ifdef around the assignment.
> >>
> >> Fixes: c3d03c5a196f ("drm/amd/display: Include num_vmid and num_dsc
> >> within NV14's resource caps")
> >> Signed-off-by: Arnd Bergmann
> >
> > Thank you for catching that 😊 On my side I kept that flag enabled all the
> time, so I didn't realize there was a warning hidden here.
> >
> > Reviewed-by: Zhan Liu
>
> What tree is this reported on?
>
> We dropped this flag whenever building DCN. Sounds like we're missing a
> patch if you're getting this.
>
> So this is a NAK from me for going into amd-staging-drm-next at least.
>
Those patches are not upstream yet. They are queued for 5.6. So we need this
patch for 5.5. I'll apply it.
Alex
> Nicholas Kazlauskas
>
> >
> >> ---
> >> drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> >> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> >> index faab89d1e694..fdf93e6edf43 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> >> @@ -923,7 +923,9 @@ static const struct resource_caps res_cap_nv14 = {
> >>.num_dwb = 1,
> >>.num_ddc = 5,
> >>.num_vmid = 16,
> >> +#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
> >>.num_dsc = 5,
> >> +#endif
> >> };
> >>
> >> static const struct dc_debug_options debug_defaults_drv = {
> >> --
> >> 2.20.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/9] drm_dp_cec: add connector info support.
Acked-by: Alex Deucher
From: Hans Verkuil
Sent: Thursday, August 22, 2019 4:08 AM
To: Dariusz Marcinkiewicz ; dri-devel@lists.freedesktop.org
; linux-me...@vger.kernel.org
Cc: David Airlie ; nouv...@lists.freedesktop.org
; Dhinakaran Pandiyan
; Koo, Anthony ; Francis,
David ; amd-...@lists.freedesktop.org
; Zuo, Jerry ; Ben Skeggs
; Li, Sun peng (Leo) ;
intel-...@lists.freedesktop.org ; Maxime
Ripard ; Rodrigo Vivi ; Sean Paul
; Thomas Lim ;
linux-ker...@vger.kernel.org ; Manasi Navare
; Deucher, Alexander ;
Koenig, Christian ; Ville Syrjälä
Subject: Re: [PATCH v7 1/9] drm_dp_cec: add connector info support.
Alex, Ville/Rodrigo, Ben,
Can you (hopefully) Ack this patch so that I can merge it?
Thank you!
Hans
On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Hans Verkuil
> ---
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/drm_dp_cec.c | 25 ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +--
> include/drm/drm_dp_helper.h | 17 ++---
> 5 files changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 16218a202b591..5ec14efd4d8cb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -416,7 +416,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>
>drm_dp_aux_register(&aconnector->dm_dp_aux.aux);
>drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
> - aconnector->base.name, dm->adev->dev);
> + &aconnector->base);
>aconnector->mst_mgr.cbs = &dm_mst_cbs;
>drm_dp_mst_topology_mgr_init(
>&aconnector->mst_mgr,
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index b15cee85b702b..b457c16c3a8bb 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -8,7 +8,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
>
> /*
> @@ -295,7 +297,10 @@ static void drm_dp_cec_unregister_work(struct
> work_struct *work)
> */
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> {
> - u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
> + struct drm_connector *connector = aux->cec.connector;
> + u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> +CEC_CAP_CONNECTOR_INFO;
> + struct cec_connector_info conn_info;
>unsigned int num_las = 1;
>u8 cap;
>
> @@ -344,13 +349,17 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>
>/* Create a new adapter */
>aux->cec.adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
> - aux, aux->cec.name, cec_caps,
> + aux, connector->name, cec_caps,
> num_las);
>if (IS_ERR(aux->cec.adap)) {
>aux->cec.adap = NULL;
>goto unlock;
>}
> - if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
> +
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> + cec_s_conn_info(aux->cec.adap, &conn_info);
> +
> + if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
>cec_delete_adapter(aux->cec.adap);
>aux->cec.adap = NULL;
>} else {
> @@ -406,22 +415,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> /**
> * drm_dp_cec_register_connector() - register a new connector
> * @aux: DisplayPort AUX channel
> - * @name: name of the CEC device
> - * @parent: parent device
> + * @connector: drm connector
> *
> * A new connector was registered with associated CEC adapter name and
> * CEC adapter parent device. After registering the name and parent
> * drm_dp_cec_set_edid() is called to check if the connector supports
> * CEC and to register a CEC adapter if that is the case.
> */
> -void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
> -
RE: [PATCH] drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed
> -Original Message- > From: Hans de Goede > Sent: Tuesday, September 10, 2019 5:36 AM > To: Michel Dänzer ; Deucher, Alexander > ; Koenig, Christian > ; Zhou, David(ChunMing) > > Cc: David Airlie ; dri-devel@lists.freedesktop.org; amd- > g...@lists.freedesktop.org; Daniel Vetter > Subject: Re: [PATCH] drm/radeon: Bail earlier when > radeon.cik_/si_support=0 is passed > > Hi, > > On 9/10/19 9:50 AM, Michel Dänzer wrote: > > On 2019-09-07 10:32 p.m., Hans de Goede wrote: > >> Bail from the pci_driver probe function instead of from the > >> drm_driver load function. > >> > >> This avoid /dev/dri/card0 temporarily getting registered and then > >> unregistered again, sending unwanted add / remove udev events to > >> userspace. > >> > >> Specifically this avoids triggering the (userspace) bug fixed by this > >> plymouth merge-request: > >> https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 > >> > >> Note that despite that being an userspace bug, not sending > >> unnecessary udev events is a good idea in general. > >> > >> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 > >> Signed-off-by: Hans de Goede > > > > Reviewed-by: Michel Dänzer > > Thank you for the review. I've drm push rights, but I guess that radeon/amd > GPU patches are collected by someone @AMD, so I do not need to / should > not push this myself, right? I'll pick this up later this week when I get home from travel. Thanks! Alex > > > amdgpu should be changed correspondingly as well. > > Good point. I'm currently travelling (@plumbers) I can do this when I'm back > home, but feel free to beat me to it (if you do please Cc me to avoid double > work). > > Regards, > > Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/mgag200: Map fbdev framebuffer while it's being displayed
Please use C style comments rather than C++.
Alex
From: Thomas Zimmermann
Sent: Wednesday, September 4, 2019 7:56 AM
To: dan...@ffwll.ch ; nor...@tronnes.org ;
airl...@linux.ie ; rong.a.c...@intel.com
; feng.t...@intel.com ;
ying.hu...@intel.com ; s...@poorly.run ;
maxime.rip...@bootlin.com ;
maarten.lankho...@linux.intel.com ;
d...@stgolabs.net
Cc: dri-devel@lists.freedesktop.org ; Thomas
Zimmermann ; Dave Airlie ; Greg
Kroah-Hartman ; Thomas Gleixner
; Gerd Hoffmann ; Deucher, Alexander
; Koenig, Christian ; Sam
Ravnborg ; Daniel Vetter ; Huang,
Ray ; Bartlomiej Zolnierkiewicz ;
Michał Mirosław ; Armijn Hemel
Subject: [PATCH v2 3/3] drm/mgag200: Map fbdev framebuffer while it's being
displayed
The generic fbdev emulation will map and unmap the framebuffer's memory
if required. As consoles are most often updated while being on screen,
we map the fbdev buffer while it's being displayed. This avoids frequent
map/unmap operations in the fbdev code. The original fbdev code in mgag200
used the same trick to improve performance.
v2:
* fix typo in comment
Signed-off-by: Thomas Zimmermann
Fixes: 90f479ae51af ("drm/mgag200: Replace struct mga_fbdev with generic
framebuffer emulation")
Cc: Thomas Zimmermann
Cc: Noralf Trønnes
Cc: Dave Airlie
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc: Gerd Hoffmann
Cc: Alex Deucher
Cc: "Christian König"
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Huang Rui
Cc: Bartlomiej Zolnierkiewicz
Cc: "Michał Mirosław"
Cc: Armijn Hemel
Cc: Rong Chen
Cc: Feng Tang
Cc: Huang Ying
Cc: Davidlohr Bueso
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 5e778b5f1a10..7b95c59341f5 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -860,13 +860,20 @@ static int mga_crtc_do_set_base(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
int x, int y, int atomic)
{
+ struct drm_fb_helper *fb_helper = crtc->dev->fb_helper;
struct drm_gem_vram_object *gbo;
int ret;
s64 gpu_addr;
+ void *base;
if (!atomic && fb) {
gbo = drm_gem_vram_of_gem(fb->obj[0]);
drm_gem_vram_unpin(gbo);
+
+ // Unmap fbdev FB if it's not being displayed
+ // any longer.
+ if (fb == fb_helper->buffer->fb)
+ drm_gem_vram_kunmap(gbo);
}
gbo = drm_gem_vram_of_gem(crtc->primary->fb->obj[0]);
@@ -882,6 +889,14 @@ static int mga_crtc_do_set_base(struct drm_crtc *crtc,
mga_set_start_address(crtc, (u32)gpu_addr);
+ // Map fbdev FB while it's being displayed. This avoids frequent
+ // mapping and unmapping within the fbdev code.
+ if (crtc->primary->fb == fb_helper->buffer->fb) {
+ base = drm_gem_vram_kmap(gbo, true, NULL);
+ if (IS_ERR(base))
+ DRM_ERROR("failed to kmap fbcon\n");
+ }
+
return 0;
err_drm_gem_vram_unpin:
@@ -1403,9 +1418,14 @@ static void mga_crtc_disable(struct drm_crtc *crtc)
DRM_DEBUG_KMS("\n");
mga_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
if (crtc->primary->fb) {
+ struct drm_fb_helper *fb_helper = crtc->dev->fb_helper;
struct drm_framebuffer *fb = crtc->primary->fb;
struct drm_gem_vram_object *gbo =
drm_gem_vram_of_gem(fb->obj[0]);
+
+ // Unmap if it's the fbdev FB.
+ if (fb == fb_helper->buffer->fb)
+ drm_gem_vram_kunmap(gbo);
drm_gem_vram_unpin(gbo);
}
crtc->primary->fb = NULL;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)"
Maybe we can check if iommu is enabled in the driver and do the appropriate thing with respect to gfxoff, assuming this is not platform specific. Alex From: Huang, Ray Sent: Thursday, August 8, 2019 4:14 AM To: Michel Dänzer ; Kai-Heng Feng ; Olsak, Marek Cc: Zhou, David(ChunMing) ; LKML ; dri-devel@lists.freedesktop.org ; Anthony Wong ; amd-gfx list ; Deucher, Alexander ; Koenig, Christian Subject: RE: [Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)" > -Original Message- > From: Michel Dänzer > Sent: Thursday, August 08, 2019 4:10 PM > To: Huang, Ray ; Kai-Heng Feng > > Cc: Zhou, David(ChunMing) ; LKML ker...@vger.kernel.org>; dri-devel@lists.freedesktop.org; Anthony Wong > ; amd-gfx list g...@lists.freedesktop.org>; Deucher, Alexander > ; Koenig, Christian > > Subject: Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series > (v2)" > > On 2019-08-08 8:29 a.m., Huang, Ray wrote: > >> From: Kai-Heng Feng at 00:03, Huang, > >> Ray wrote: > >> > >>> May I know the all firmware version in your system? > > > > Seems to the issue we encountered with IOMMU enabled. Could you > please disable iommu in SBIOS or GRUB? > > The driver needs to work with the IOMMU enabled. If nothing else, ROCm > only works with IOMMU I think. > Yes. ROCm in APU required IOMMU v2. So far, I am asking Kai-Heng to do some tests to make sure the issue that was encountered by us before. (+ Marek) Thanks, Ray > > -- > Earthling Michel Dänzer | https://www.amd.com > Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: fix amdgpu_preempt_mgr_new()
[Public]
I've dropped it from my tree in that case.
From: Christian König
Sent: Monday, June 21, 2021 6:27 AM
To: Alex Deucher ; Kuehling, Felix
Cc: David Airlie ; Pan, Xinhui ;
kernel-janit...@vger.kernel.org ; Maling list
- DRI developers ; amd-gfx list
; Daniel Vetter ; Deucher,
Alexander ; Dave Airlie ;
Koenig, Christian ; Dan Carpenter
Subject: Re: [PATCH] drm/amdgpu: fix amdgpu_preempt_mgr_new()
Am 18.06.21 um 23:18 schrieb Alex Deucher:
> On Fri, Jun 18, 2021 at 11:40 AM Felix Kuehling
> wrote:
>> Am 2021-06-18 um 4:39 a.m. schrieb Christian König:
>>> Am 18.06.21 um 10:37 schrieb Dan Carpenter:
>>>> There is a reversed if statement in amdgpu_preempt_mgr_new() so it
>>>> always returns -ENOMEM.
>>>>
>>>> Fixes: 09b020bb05a5 ("Merge tag 'drm-misc-next-2021-06-09' of
>>>> git://anongit.freedesktop.org/drm/drm-misc into drm-next")
>>>> Signed-off-by: Dan Carpenter
>>> Most be some fallout from merging it with the TTM changes.
>>>
>>> Anyway, patch is Reviewed-by: Christian König
>> This is obviously not for amd-staging-drm-next. Christian, are you going
>> to apply it to the relevant branches?
> I've applied it to my drm-next branch.
I already pushed it to drm-misc-next last week.
Christian.
>
> Alex
>
>
>> Thanks,
>>Felix
>>
>>
>>> Thanks,
>>> Christian.
>>>
>>>> ---
>>>>drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 2 +-
>>>>1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> index f6aff7ce5160..d02c8637f909 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> @@ -71,7 +71,7 @@ static int amdgpu_preempt_mgr_new(struct
>>>> ttm_resource_manager *man,
>>>>struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
>>>> *res = kzalloc(sizeof(**res), GFP_KERNEL);
>>>> -if (*res)
>>>> +if (!*res)
>>>>return -ENOMEM;
>>>> ttm_resource_init(tbo, place, *res);
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Calexander.deucher%40amd.com%7C096813db12f24172870508d9349f375a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637598680703030828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Ffg7TXDA9%2F%2Fjin8T5f3V11fAv3PVvtDFluNHnhwyOGM%3D&reserved=0
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Calexander.deucher%40amd.com%7C096813db12f24172870508d9349f375a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637598680703030828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Ffg7TXDA9%2F%2Fjin8T5f3V11fAv3PVvtDFluNHnhwyOGM%3D&reserved=0
Re: [PATCH v3] drm/radeon: Call radeon_suspend_kms() in radeon_pci_shutdown() for Loongson64
[Public] Applied. Thanks. For whatever reason, I never got this patch and couldn't find it in patchwork. Alex From: Koenig, Christian Sent: Wednesday, June 23, 2021 4:25 AM To: Tiezhu Yang ; Deucher, Alexander Cc: airl...@linux.ie ; amd-...@lists.freedesktop.org ; dan...@ffwll.ch ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org ; lixuef...@loongson.cn ; lvjian...@loongson.cn Subject: Re: [PATCH v3] drm/radeon: Call radeon_suspend_kms() in radeon_pci_shutdown() for Loongson64 Looks good to me. Somebody could try to investigate further why that is necessary on the platform, but radeon is only in maintenance mode without new feature developed. Regards, Christian. Am 23.06.21 um 10:14 schrieb Tiezhu Yang: > Hi Alex and Christian, > > Any comments? > Can this patch be accepted or anything else I need to improve? > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1443649%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C2162309822114d2e41b108d9361ef26c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637600328822651335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2uxyAGk6sHO3lqw0FX6HITY%2Fbj%2BzEMfSIcqbzmiguMs%3D&reserved=0 > > > Thanks, > Tiezhu >
RE: [PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN platforms.
[AMD Official Use Only - General] > -Original Message- > From: Sasha Levin > Sent: Tuesday, January 31, 2023 10:00 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Dave Airlie ; Sasha Levin ; > Wentland, Harry ; Li, Sun peng (Leo) > ; Siqueira, Rodrigo ; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; Li, Roman ; > Wang, Chao-kai (Stylon) ; Pillai, Aurabindo > ; Zuo, Jerry ; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN > platforms. > > From: Dave Airlie > > [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] > > This fixes the build here locally on my 32-bit arm build. > > Signed-off-by: Dave Airlie > Signed-off-by: Sasha Levin This patch is only applicable to kernel 6.1.x and newer. Alex > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 15b408e3a705..d756a606b5e2 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -9411,6 +9411,8 @@ static int amdgpu_dm_atomic_check(struct > drm_device *dev, > bool lock_and_validation_needed = false; > struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; #if > defined(CONFIG_DRM_AMD_DC_DCN) > + struct drm_dp_mst_topology_mgr *mgr; > + struct drm_dp_mst_topology_state *mst_state; > struct dsc_mst_fairness_vars vars[MAX_PIPES]; #endif > > -- > 2.39.0
RE: [PULL] drm-misc-next
[Public] > -Original Message- > From: dim-tools On Behalf Of > John Paul Adrian Glaubitz > Sent: Monday, January 23, 2023 10:01 AM > To: tzimmerm...@suse.de > Cc: tvrtko.ursu...@linux.intel.com; dim-to...@lists.freedesktop.org; > daniel.vet...@ffwll.ch; intel-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; rodrigo.v...@intel.com; airl...@gmail.com > Subject: Re: [PULL] drm-misc-next > > Hi Thomas! > > > Driver Changes: > > > > * Remove obsolete drivers for userspace modesetting i810, mga, r128, > >savage, sis, tdfx, via > > Is the Rage 128 GPU still supported via the generic modesetting driver? > > I'm asking because, we're still supporting PowerMacs in Debian Ports of > which some of those are sporting a Rage 128 GPU. Similar question applies to > the > i810 GPU used in some old ThinkPads, for example. These are not KMS drivers. They are just the kernel component needed for 3D rendering. These drivers have nothing to do with driving the displays on these cards. For display support you need to use the old Xorg DDXs for these cards or the relevant non-DRM fbdev drivers. Alex > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist >`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
RE: [Regression bisected] v6.3-rc4 Error scheduling IBs after resume from hibernate
[Public] > -Original Message- > From: Julian Wollrath > Sent: Thursday, March 30, 2023 10:08 AM > To: dri-devel@lists.freedesktop.org > Cc: Huang, Tim ; Deucher, Alexander > > Subject: [Regression bisected] v6.3-rc4 Error scheduling IBs after resume > from hibernate > > Hi, > > on an AMD Ryzen 5 PRO 4650U / Renoir (amdgpu: added device > 1002:1636) I the screen basically freezes and I get the following errors with > kernel v6.3-rc4 > > [ 26.214541] amdgpu :03:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] > *ERROR* IB test failed on gfx_low (-110). > [ 26.379624] [drm] ring 0 timeout to preempt ib > [ 27.387884] amdgpu :03:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] > *ERROR* IB test failed on gfx_high (-110). > [ 27.392945] [drm:process_one_work] *ERROR* ib ring test failed (-110). > [ 27.400370] amdgpu :03:00.0: amdgpu: couldn't schedule ib on ring > > [ 27.400384] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling > IBs (-22) > [ 44.440532] amdgpu :03:00.0: amdgpu: failed to write reg 28b4 wait reg > 28c6 > [ 61.177118] amdgpu :03:00.0: amdgpu: failed to write reg 1a6f4 wait reg > 1a706 > [ 61.189275] amdgpu :03:00.0: amdgpu: couldn't schedule ib on ring > > [ 61.189286] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling > IBs (-22) > > I bisected the issue, the first bad commit is > b589626674de94d977e81c99bf7905872b991197 reverting it on top of v6.3-rc4 > also fixes the issue. Fixed in: https://patchwork.freedesktop.org/patch/529751/ Alex > > > Best regards, > Julian Wollrath > > -- > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments
RE: [PATCH] radeon: avoid double free in ci_dpm_init()
[Public]
> -Original Message-
> From: Nikita Zhandarovich
> Sent: Monday, April 3, 2023 2:28 PM
> To: Deucher, Alexander
> Cc: Nikita Zhandarovich ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; lvc-proj...@linuxtesting.org
> Subject: [PATCH] radeon: avoid double free in ci_dpm_init()
>
> There are several calls to ci_dpm_fini() in ci_dpm_init() when there occur
> errors in functions like r600_parse_extended_power_table().
> This is harmful as it can lead to double free situations: for instance,
> r600_parse_extended_power_table() will call for
> r600_free_extended_power_table() as will ci_dpm_fini(), both of which will
> try to free resources.
> Other drivers do not call *_dpm_fini functions from their respective
> *_dpm_init calls - neither should cpm_dpm_init().
>
> Fix this by removing extra calls to ci_dpm_fini().
You can't just drop the calls to fini(). You'll need to properly unwind to
avoid leaking memory.
Alex
>
> Found by Linux Verification Center (linuxtesting.org) with static analysis
> tool
> SVACE.
>
> Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
> Cc: sta...@vger.kernel.org
> Co-developed-by: Natalia Petrova
> Signed-off-by: Nikita Zhandarovich
>
> ---
> drivers/gpu/drm/radeon/ci_dpm.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
> b/drivers/gpu/drm/radeon/ci_dpm.c index 8ef25ab305ae..7b77d4c93f1d
> 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -5677,28 +5677,20 @@ int ci_dpm_init(struct radeon_device *rdev)
> pi->pcie_lane_powersaving.min = 16;
>
> ret = ci_get_vbios_boot_values(rdev, &pi->vbios_boot_state);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
> return ret;
> - }
>
> ret = r600_get_platform_caps(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
> return ret;
> - }
>
> ret = r600_parse_extended_power_table(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
> return ret;
> - }
>
> ret = ci_parse_power_table(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
> return ret;
> - }
>
> pi->dll_default_on = false;
> pi->sram_end = SMC_RAM_END;
> @@ -5749,10 +5741,8 @@ int ci_dpm_init(struct radeon_device *rdev)
> kcalloc(4,
> sizeof(struct
> radeon_clock_voltage_dependency_entry),
> GFP_KERNEL);
> - if (!rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) {
> - ci_dpm_fini(rdev);
> + if (!rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries)
> return -ENOMEM;
> - }
> rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.count = 4;
> rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].clk = 0;
> rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].v = 0;
RE: [PATCH 04/11] drm/radeon: Use regular fbdev I/O helpers
[Public]
> -Original Message-
> From: Thomas Zimmermann
> Sent: Friday, May 12, 2023 4:42 AM
> To: dan...@ffwll.ch; airl...@gmail.com; maarten.lankho...@linux.intel.com;
> mrip...@kernel.org; javi...@redhat.com
> Cc: dri-devel@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-...@vger.kernel.org; intel-...@lists.freedesktop.org; linux-
> arm-...@vger.kernel.org; freedr...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; linux-te...@vger.kernel.org; Thomas
> Zimmermann ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui
> Subject: [PATCH 04/11] drm/radeon: Use regular fbdev I/O helpers
>
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's helpers.
> Radeon does not use damage handling, so DRM's fbdev helpers are mere
> wrappers around the fbdev code.
>
> Add CONFIG_DRM_RADEON_FBDEV_EMULATION to select the necessary
> Kconfig options automatically. Make fbdev emulation depend on the new
> config option.
>
> By using fbdev helpers directly within each DRM fbdev emulation, we can
> eventually remove DRM's wrapper functions entirely.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
Feel free to take this through whatever tree makes sense.
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/Kconfig| 8
> drivers/gpu/drm/radeon/Makefile | 2 +-
> drivers/gpu/drm/radeon/radeon_fbdev.c | 9 -
> drivers/gpu/drm/radeon/radeon_mode.h | 2 +-
> 4 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/Kconfig
> b/drivers/gpu/drm/radeon/Kconfig index e19d77d58810..66b741d96cc4
> 100644
> --- a/drivers/gpu/drm/radeon/Kconfig
> +++ b/drivers/gpu/drm/radeon/Kconfig
> @@ -8,6 +8,7 @@ config DRM_RADEON
> select DRM_DISPLAY_DP_HELPER
> select DRM_DISPLAY_HELPER
> select DRM_KMS_HELPER
> + select DRM_RADEON_FBDEV_EMULATION if
> DRM_FBDEV_EMULATION
> select DRM_SUBALLOC_HELPER
> select DRM_TTM
> select DRM_TTM_HELPER
> @@ -39,3 +40,10 @@ config DRM_RADEON_USERPTR
> help
> This option selects CONFIG_MMU_NOTIFIER if it isn't already
> selected to enabled full userptr support.
> +
> +config DRM_RADEON_FBDEV_EMULATION
> + bool
> + depends on DRM_RADEON
> + select FB_CFB_COPYAREA
> + select FB_CFB_FILLRECT
> + select FB_CFB_IMAGEBLIT
> diff --git a/drivers/gpu/drm/radeon/Makefile
> b/drivers/gpu/drm/radeon/Makefile index a8734b7d0485..46c1446196a9
> 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -76,7 +76,7 @@ radeon-y += \
> vce_v1_0.o \
> vce_v2_0.o
>
> -radeon-$(CONFIG_DRM_FBDEV_EMULATION) += radeon_fbdev.o
> +radeon-$(CONFIG_DRM_RADEON_FBDEV_EMULATION) +=
> radeon_fbdev.o
> radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> radeon-$(CONFIG_ACPI) += radeon_acpi.o
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fbdev.c
> b/drivers/gpu/drm/radeon/radeon_fbdev.c
> index fe76e29910ef..dcabe527f9c0 100644
> --- a/drivers/gpu/drm/radeon/radeon_fbdev.c
> +++ b/drivers/gpu/drm/radeon/radeon_fbdev.c
> @@ -24,6 +24,7 @@
> * David Airlie
> */
>
> +#include
> #include
> #include
> #include
> @@ -193,11 +194,9 @@ static const struct fb_ops radeon_fbdev_fb_ops = {
> DRM_FB_HELPER_DEFAULT_OPS,
> .fb_open = radeon_fbdev_fb_open,
> .fb_release = radeon_fbdev_fb_release,
> - .fb_read = drm_fb_helper_cfb_read,
> - .fb_write = drm_fb_helper_cfb_write,
> - .fb_fillrect = drm_fb_helper_cfb_fillrect,
> - .fb_copyarea = drm_fb_helper_cfb_copyarea,
> - .fb_imageblit = drm_fb_helper_cfb_imageblit,
> + .fb_fillrect = cfb_fillrect,
> + .fb_copyarea = cfb_copyarea,
> + .fb_imageblit = cfb_imageblit,
> .fb_destroy = radeon_fbdev_fb_destroy, };
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 1decdcec0264..c5a8e25a4c97 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -939,7 +939,7 @@ void dce4_program_fmt(struct drm_encoder
> *encoder); void dce8_program_fmt(struct drm_encoder *encoder);
>
> /* fbdev layer */
> -#if defined(CONFIG_DRM_FBDEV_EMULATION)
> +#if defined(CONFIG_DRM_RADEON_FBDEV_EMULATION)
> void radeon_fbdev_setup(struct radeon_device *rdev); void
> radeon_fbdev_set_suspend(struct radeon_device *rdev, int state); bool
> radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo
> *robj);
> --
> 2.40.1
RE: [PATCH] drm/radeon: Replace all non-returning strlcpy with strscpy
[Public] > -Original Message- > From: Kees Cook > Sent: Monday, May 22, 2023 4:15 PM > To: Azeem Shaikh > Cc: Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; linux- > harden...@vger.kernel.org; amd-...@lists.freedesktop.org; linux- > ker...@vger.kernel.org; David Airlie ; Daniel Vetter > ; dri-devel@lists.freedesktop.org > Subject: Re: [PATCH] drm/radeon: Replace all non-returning strlcpy with > strscpy > > On Mon, May 22, 2023 at 03:50:32PM +, Azeem Shaikh wrote: > > strlcpy() reads the entire source buffer first. > > This read may exceed the destination size limit. > > This is both inefficient and can lead to linear read overflows if a > > source string is not NUL-terminated [1]. > > In an effort to remove strlcpy() completely [2], replace > > strlcpy() here with strscpy(). > > No return values were used, so direct replacement is safe. > > > > [1] > > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy > > [2] https://github.com/KSPP/linux/issues/89 > > > > Signed-off-by: Azeem Shaikh > > Reviewed-by: Kees Cook > Acked-by: Alex Deucher Ack to take this through whatever tree makes sense if you are trying to batch all of these up. Otherwise, I can pick them up. Alex
RE: [PATCH] drm/amd/pm: Replace all non-returning strlcpy with strscpy
[Public] > -Original Message- > From: Kees Cook > Sent: Monday, May 22, 2023 4:16 PM > To: Azeem Shaikh > Cc: Quan, Evan ; linux-harden...@vger.kernel.org; > amd-...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Deucher, > Alexander ; Koenig, Christian > ; Pan, Xinhui ; David > Airlie ; Daniel Vetter ; dri- > de...@lists.freedesktop.org > Subject: Re: [PATCH] drm/amd/pm: Replace all non-returning strlcpy with > strscpy > > On Mon, May 22, 2023 at 03:52:45PM +, Azeem Shaikh wrote: > > strlcpy() reads the entire source buffer first. > > This read may exceed the destination size limit. > > This is both inefficient and can lead to linear read overflows if a > > source string is not NUL-terminated [1]. > > In an effort to remove strlcpy() completely [2], replace > > strlcpy() here with strscpy(). > > No return values were used, so direct replacement is safe. > > > > [1] > > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy > > [2] https://github.com/KSPP/linux/issues/89 > > > > Signed-off-by: Azeem Shaikh > > Reviewed-by: Kees Cook > Acked-by: Alex Deucher Ack to take this through whatever tree makes sense if you are trying to batch all of these up. Otherwise, I can pick them up. Alex
RE: [PATCH] drm/amdgpu: Log if device is unsupported
[AMD Official Use Only - General]
> -Original Message-
> From: Paul Menzel
> Sent: Monday, June 5, 2023 11:23 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter
> Cc: Paul Menzel ; amd-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: Log if device is unsupported
>
> Since there is overlap in supported devices, both modules load, but only one
> will bind to a particular device depending on the model and user's
> configuration.
>
> amdgpu binds to all display class devices with VID 0x1002 and then
> determines whether or not to bind to a device based on whether the
> individual device is supported by the driver or not. Log that case, so users
> looking at the logs know what is going on.
>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2608
> Signed-off-by: Paul Menzel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 86fbb4138285..410ff918c350 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2062,8 +2062,10 @@ static int amdgpu_pci_probe(struct pci_dev
> *pdev,
>
> /* skip devices which are owned by radeon */
> for (i = 0; i < ARRAY_SIZE(amdgpu_unsupported_pciidlist); i++) {
> - if (amdgpu_unsupported_pciidlist[i] == pdev->device)
> + if (amdgpu_unsupported_pciidlist[i] == pdev->device) {
> + DRM_INFO("This hardware is only supported by
> radeon.");
> return -ENODEV;
I think this will confuse users even more. As there will be a new "error"
message reported. I'd suggest either dropping the message in init per my
proposed patch or just leaving things as is.
Alex
> + }
> }
>
> if (amdgpu_aspm == -1 && !pcie_aspm_enabled(pdev))
> --
> 2.40.1
RE: WARNING: CPU: 5 PID: 1464 at drivers/gpu/drm/ttm/ttm_bo.c:326 ttm_bo_release+0x27e/0x2d0 [ttm]
[Public]
+ Christian
> -Original Message-
> From: Borislav Petkov
> Sent: Saturday, June 3, 2023 1:48 PM
> To: amd-...@lists.freedesktop.org
> Cc: Deucher, Alexander ; dri-
> de...@lists.freedesktop.org; lkml
> Subject: WARNING: CPU: 5 PID: 1464 at drivers/gpu/drm/ttm/ttm_bo.c:326
> ttm_bo_release+0x27e/0x2d0 [ttm]
>
> Hi,
>
> this below triggers with the latest Linus tree:
>
> 51f269a6ecc7 ("Merge tag 'probes-fixes-6.4-rc4' of
> git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
>
> ...
> [ 16.173593] [drm] radeon kernel modesetting enabled.
> [ 16.173743] radeon :29:00.0: vgaarb: deactivate vga console
> [ 16.174300] MCE: In-kernel MCE decoding enabled.
> [ 16.175695] EDAC DEBUG: umc_read_base_mask: DCSB0[0]=0x0001
> reg: 0x5
> [ 16.175698] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC0[0]=0x reg: 0x50010
> [ 16.175700] EDAC DEBUG: umc_read_base_mask: DCSB0[1]=0x
> reg: 0x50004
> [ 16.175702] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC0[1]=0x reg: 0x50014
> [ 16.175703] EDAC DEBUG: umc_read_base_mask: DCSB0[2]=0x0201
> reg: 0x50008
> [ 16.175705] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC0[2]=0x reg: 0x50018
> [ 16.175706] EDAC DEBUG: umc_read_base_mask: DCSB0[3]=0x
> reg: 0x5000c
> [ 16.175707] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC0[3]=0x reg: 0x5001c
> [ 16.175709] EDAC DEBUG: umc_read_base_mask: DCSM0[0]=0x03fffdfe
> reg: 0x50020
> [ 16.175710] EDAC DEBUG: umc_read_base_mask:
> DCSM_SEC0[0]=0x reg: 0x50028
> [ 16.175712] EDAC DEBUG: umc_read_base_mask: DCSM0[1]=0x03fffdfe
> reg: 0x50024
> [ 16.175713] EDAC DEBUG: umc_read_base_mask:
> DCSM_SEC0[1]=0x reg: 0x5002c
> [ 16.175715] EDAC DEBUG: umc_read_base_mask: DCSB1[0]=0x0001
> reg: 0x15
> [ 16.175716] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC1[0]=0x reg: 0x150010
> [ 16.175718] EDAC DEBUG: umc_read_base_mask: DCSB1[1]=0x
> reg: 0x150004
> [ 16.175719] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC1[1]=0x reg: 0x150014
> [ 16.175720] EDAC DEBUG: umc_read_base_mask: DCSB1[2]=0x0201
> reg: 0x150008
> [ 16.175722] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC1[2]=0x reg: 0x150018
> [ 16.175723] EDAC DEBUG: umc_read_base_mask: DCSB1[3]=0x
> reg: 0x15000c
> [ 16.175725] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC1[3]=0x reg: 0x15001c
> [ 16.175726] EDAC DEBUG: umc_read_base_mask: DCSM1[0]=0x03fffdfe
> reg: 0x150020
> [ 16.175728] EDAC DEBUG: umc_read_base_mask:
> DCSM_SEC1[0]=0x reg: 0x150028
> [ 16.175729] EDAC DEBUG: umc_read_base_mask: DCSM1[1]=0x03fffdfe
> reg: 0x150024
> [ 16.175730] EDAC DEBUG: umc_read_base_mask:
> DCSM_SEC1[1]=0x reg: 0x15002c
> [ 16.175741] EDAC DEBUG: umc_determine_memory_type: UMC0 DIMM
> type: Unbuffered-DDR4
> [ 16.175742] EDAC DEBUG: umc_determine_memory_type: UMC1 DIMM
> type: Unbuffered-DDR4
> [ 16.177514] Console: switching to colour dummy device 80x25
> [ 16.177693] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E1
> 0x174B:0x3000 0x00).
> [ 16.177733] ATOM BIOS: AMD
> [ 16.177795] radeon :29:00.0: VRAM: 1024M 0x
> - 0x3FFF (1024M used)
> [ 16.177798] radeon :29:00.0: GTT: 1024M 0x4000 -
> 0x7FFF
> [ 16.177800] [drm] Detected VRAM RAM=1024M, BAR=256M
> [ 16.177802] [drm] RAM width 64bits DDR
> [ 16.177835] [drm] radeon: 1024M of VRAM memory ready
> [ 16.177836] [drm] radeon: 1024M of GTT memory ready.
> [ 16.177839] [drm] Loading CEDAR Microcode
> [ 16.179106] [drm] Internal thermal controller without fan control
> [ 16.199812] [drm] radeon: dpm initialized
> [ 16.200179] [drm] GART: num cpu pages 262144, num gpu pages 262144
> [ 16.200399] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [ 16.218135] [drm] PCIE GART of 1024M enabled (table at
> 0x0014C000).
> [ 16.218239] radeon :29:00.0: WB enabled
> [ 16.218240] radeon :29:00.0: fence driver on ring 0 use gpu addr
> 0x4c00
> [ 16.218242] radeon :29:00.0: fence driver on ring 3 use gpu addr
> 0x4c0c
> [ 16.218606] radeon :29:00.0: fence driver on ring 5 use gpu addr
> 0x0005c418
> [ 16.218657] radeon :29:00.0: radeon: MSI limited to 32-bit
> [ 16.218689] radeon :29:00.0: radeon: using MSI.
> [ 16.218707] [drm] radeon: irq initialized.
> [ 16.234730] [drm] ring test on 0 succeeded in 0 usecs
> [ 16.234738] [drm] ring test on 3 succeeded in 2 usecs
> [ 16.317725] r8169 :
RE: [PATCH v2] drm/amdgpu: Add error reporting code for the display core
[Public]
> -Original Message-
> From: Sui Jingfeng
> Sent: Sunday, June 11, 2023 11:24 AM
> To: Wentland, Harry ; Li, Sun peng (Leo)
> ; Siqueira, Rodrigo ;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Lee, Alvin
> ; Lei, Jun ; Zhuo, Qingqing (Lillian)
> ; Liu, Wenjing ; Tam,
> Samson ; Varone, Dillon
> ; Liu, HaoPing (Alan)
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v2] drm/amdgpu: Add error reporting code for the display
> core
>
> [why]
>
> Because the drm/amdgpu drivers do not work with Navi 10 [RX 5700] series
> GPUs on non-x86 platforms, this patch helps find out where the drivers fail.
> After applying his patch, the following error message can be found:
>
> [drm:dc_create [amdgpu]] *ERROR* dc_construct: failed to create resource
> pool [drm:dc_create [amdgpu]] *ERROR* dc_create: dc construct failed [drm]
> Display Core failed to initialize with v3.2.230!
Curious what the failure was on your platform. Resource create is mostly just
allocating structures.
Alex
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 29
> 1 file changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 52564b93f7eb..d33b78aa3e58 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -951,7 +951,7 @@ static bool dc_construct(struct dc *dc,
> goto fail;
> }
>
> -dc_ctx = dc->ctx;
> + dc_ctx = dc->ctx;
>
> /* Resource should construct all asic specific resources.
>* This should be the only place where we need to parse the asic id
> @@ -990,16 +990,21 @@ static bool dc_construct(struct dc *dc,
> }
>
> dc->res_pool = dc_create_resource_pool(dc, init_params, dc_ctx-
> >dce_version);
> - if (!dc->res_pool)
> + if (!dc->res_pool) {
> + dm_error("%s: failed to create resource pool\n", __func__);
> goto fail;
> + }
>
> /* set i2c speed if not done by the respective dcnxxx__resource.c */
> if (dc->caps.i2c_speed_in_khz_hdcp == 0)
> dc->caps.i2c_speed_in_khz_hdcp = dc-
> >caps.i2c_speed_in_khz;
>
> dc->clk_mgr = dc_clk_mgr_create(dc->ctx, dc->res_pool->pp_smu, dc-
> >res_pool->dccg);
> - if (!dc->clk_mgr)
> + if (!dc->clk_mgr) {
> + dm_error("%s: failed to create clk manager\n", __func__);
> goto fail;
> + }
> +
> #ifdef CONFIG_DRM_AMD_DC_FP
> dc->clk_mgr->force_smu_not_present = init_params-
> >force_smu_not_present;
>
> @@ -1022,14 +1027,18 @@ static bool dc_construct(struct dc *dc,
> goto fail;
> }
>
> - if (!create_links(dc, init_params->num_virtual_links))
> + if (!create_links(dc, init_params->num_virtual_links)) {
> + dm_error("%s: failed to create links\n", __func__);
> goto fail;
> + }
>
> /* Create additional DIG link encoder objects if fewer than the
> platform
>* supports were created during link construction.
>*/
> - if (!create_link_encoders(dc))
> + if (!create_link_encoders(dc)) {
> + dm_error("%s: failed to create link encoders\n", __func__);
> goto fail;
> + }
>
> dc_resource_state_construct(dc, dc->current_state);
>
> @@ -1314,11 +1323,15 @@ struct dc *dc_create(const struct dc_init_data
> *init_params)
> return NULL;
>
> if (init_params->dce_environment == DCE_ENV_VIRTUAL_HW) {
> - if (!dc_construct_ctx(dc, init_params))
> + if (!dc_construct_ctx(dc, init_params)) {
> + DC_LOG_ERROR("%s: dc construct failed\n",
> __func__);
> goto destruct_dc;
> + }
> } else {
> - if (!dc_construct(dc, init_params))
> + if (!dc_construct(dc, init_params)) {
> + DC_LOG_ERROR("%s: dc construct failed\n",
> __func__);
> goto destruct_dc;
> + }
>
> full_pipe_count = dc->res_pool->pipe_count;
> if (dc->res_pool->underlay_pipe_index !=
> NO_UNDERLAY_PIPE) @@ -1349,8 +1362,6 @@ struct dc *dc_create(const
> struct dc_init_data *init_params)
>
> DC_LOG_DC("Display Core initialized\n");
>
> -
> -
> return dc;
>
> destruct_dc:
> --
> 2.25.1
Re: [PATCH] Documentation/gpu: Update amdgpu documentation
[AMD Official Use Only - General]
Reviewed-by: Alex Deucher
From: Lazar, Lijo
Sent: Tuesday, August 15, 2023 11:56 PM
To: amd-...@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; s...@canb.auug.org.au ;
airl...@redhat.com ; dri-devel@lists.freedesktop.org
Subject: [PATCH] Documentation/gpu: Update amdgpu documentation
7957ec80ef97 ("drm/amdgpu: Add FRU sysfs nodes only if needed") moved
the documentation for some of the sysfs nodes to amdgpu_fru_eeprom.c.
Update the documentation accordingly.
Signed-off-by: Lijo Lazar
---
Documentation/gpu/amdgpu/driver-misc.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gpu/amdgpu/driver-misc.rst
b/Documentation/gpu/amdgpu/driver-misc.rst
index be131e963d87..26334e54447b 100644
--- a/Documentation/gpu/amdgpu/driver-misc.rst
+++ b/Documentation/gpu/amdgpu/driver-misc.rst
@@ -11,19 +11,19 @@ via sysfs
product_name
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
:doc: product_name
product_number
--
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
:doc: product_name
serial_number
-
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
:doc: serial_number
unique_id
--
2.25.1
RE: [PATCH v5 06/11] drm/radeon: Use RMW accessors for changing LNKCTL
[Public]
> -Original Message-
> From: Ilpo Järvinen
> Sent: Monday, July 17, 2023 8:05 AM
> To: linux-...@vger.kernel.org; Bjorn Helgaas ; Lorenzo
> Pieralisi ; Rob Herring ;
> Krzysztof Wilczyński ; Emmanuel Grumbach
> ; Rafael J . Wysocki ;
> Heiner Kallweit ; Lukas Wunner ;
> Andy Shevchenko ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Cc: Dean Luick ; Jonas Dreßler
> ; Ilpo Järvinen ;
> sta...@vger.kernel.org
> Subject: [PATCH v5 06/11] drm/radeon: Use RMW accessors for changing
> LNKCTL
>
> Don't assume that only the driver would be accessing LNKCTL. ASPM policy
> changes can trigger write to LNKCTL outside of driver's control.
> And in the case of upstream bridge, the driver does not even own the device
> it's changing the registers for.
>
> Use RMW capability accessors which do proper locking to avoid losing
> concurrent updates to the register value.
>
> Fixes: 8a7cd27679d0 ("drm/radeon/cik: add support for pcie gen1/2/3
> switching")
> Fixes: b9d305dfb66c ("drm/radeon: implement pcie gen2/3 support for SI")
> Suggested-by: Lukas Wunner
> Signed-off-by: Ilpo Järvinen
> Cc: sta...@vger.kernel.org
For this and the amdgpu patch:
Acked-by: Alex Deucher
I'm not sure if this is stable material however. Is there some issue today?
> ---
> drivers/gpu/drm/radeon/cik.c | 36 ++-
> drivers/gpu/drm/radeon/si.c | 37 ++--
> 2 files changed, 20 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 5819737c21c6..a6f3c811ceb8 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -9534,17 +9534,8 @@ static void cik_pcie_gen3_enable(struct
> radeon_device *rdev)
> u16 bridge_cfg2, gpu_cfg2;
> u32 max_lw, current_lw, tmp;
>
> - pcie_capability_read_word(root, PCI_EXP_LNKCTL,
> - &bridge_cfg);
> - pcie_capability_read_word(rdev->pdev,
> PCI_EXP_LNKCTL,
> - &gpu_cfg);
> -
> - tmp16 = bridge_cfg | PCI_EXP_LNKCTL_HAWD;
> - pcie_capability_write_word(root, PCI_EXP_LNKCTL,
> tmp16);
> -
> - tmp16 = gpu_cfg | PCI_EXP_LNKCTL_HAWD;
> - pcie_capability_write_word(rdev->pdev,
> PCI_EXP_LNKCTL,
> -tmp16);
> + pcie_capability_set_word(root, PCI_EXP_LNKCTL,
> PCI_EXP_LNKCTL_HAWD);
> + pcie_capability_set_word(rdev->pdev,
> PCI_EXP_LNKCTL,
> +PCI_EXP_LNKCTL_HAWD);
>
> tmp = RREG32_PCIE_PORT(PCIE_LC_STATUS1);
> max_lw = (tmp & LC_DETECTED_LINK_WIDTH_MASK)
> >> LC_DETECTED_LINK_WIDTH_SHIFT; @@ -9591,21 +9582,14 @@ static
> void cik_pcie_gen3_enable(struct radeon_device *rdev)
> msleep(100);
>
> /* linkctl */
> - pcie_capability_read_word(root,
> PCI_EXP_LNKCTL,
> - &tmp16);
> - tmp16 &= ~PCI_EXP_LNKCTL_HAWD;
> - tmp16 |= (bridge_cfg &
> PCI_EXP_LNKCTL_HAWD);
> - pcie_capability_write_word(root,
> PCI_EXP_LNKCTL,
> -tmp16);
> -
> - pcie_capability_read_word(rdev->pdev,
> - PCI_EXP_LNKCTL,
> - &tmp16);
> - tmp16 &= ~PCI_EXP_LNKCTL_HAWD;
> - tmp16 |= (gpu_cfg &
> PCI_EXP_LNKCTL_HAWD);
> - pcie_capability_write_word(rdev->pdev,
> -PCI_EXP_LNKCTL,
> -tmp16);
> + pcie_capability_clear_and_set_word(root,
> PCI_EXP_LNKCTL,
> +
> PCI_EXP_LNKCTL_HAWD,
> +bridge_cfg &
> +
> PCI_EXP_LNKCTL_HAWD);
> + pcie_capability_clear_and_set_word(rdev-
> >pdev, PCI_EXP_LNKCTL,
> +
> PCI_EXP_LNKCTL_HAWD,
> +
RE: [PATCH AUTOSEL 6.4 10/11] drm/amdkfd: disable IOMMUv2 support for KV/CZ
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH AUTOSEL 6.4 10/11] drm/amdkfd: disable IOMMUv2
> support for KV/CZ
>
> From: Alex Deucher
>
> [ Upstream commit 616f92d188ee7142a95a52068efdbea82645f859 ]
>
> Use the dGPU path instead. There were a lot of platform issues with IOMMU
> in general on these chips due to windows not enabling IOMMU at the time.
> The dGPU path has been used for a long time with newer APUs and works
> fine. This also paves the way to simplify the driver significantly.
>
> v2: use the dGPU queue manager functions
This is not needed for stable.
Alex
>
> Reviewed-by: Felix Kuehling
> Acked-by: Christian König
> Tested-by: Mike Lothian
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 --
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 8 +---
> 2 files changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 00f528eb98126..9c8197573dee7 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -224,10 +224,6 @@ static void kfd_device_info_init(struct kfd_dev *kfd,
> asic_type != CHIP_TONGA)
> kfd->device_info.supports_cwsr = true;
>
> - if (asic_type == CHIP_KAVERI ||
> - asic_type == CHIP_CARRIZO)
> - kfd->device_info.needs_iommu_device = true;
> -
> if (asic_type != CHIP_HAWAII && !vf)
> kfd->device_info.needs_pci_atomics = true;
> }
> @@ -240,7 +236,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> uint32_t gfx_target_version = 0;
>
> switch (adev->asic_type) {
> -#ifdef KFD_SUPPORT_IOMMU_V2
> #ifdef CONFIG_DRM_AMDGPU_CIK
> case CHIP_KAVERI:
> gfx_target_version = 7;
> @@ -253,7 +248,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> if (!vf)
> f2g = &gfx_v8_kfd2kgd;
> break;
> -#endif
> #ifdef CONFIG_DRM_AMDGPU_CIK
> case CHIP_HAWAII:
> gfx_target_version = 70001;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 7a95698d83f73..c73417e79745e 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -2335,18 +2335,12 @@ struct device_queue_manager
> *device_queue_manager_init(struct kfd_dev *dev)
> }
>
> switch (dev->adev->asic_type) {
> - case CHIP_CARRIZO:
> - device_queue_manager_init_vi(&dqm->asic_ops);
> - break;
> -
> case CHIP_KAVERI:
> - device_queue_manager_init_cik(&dqm->asic_ops);
> - break;
> -
> case CHIP_HAWAII:
> device_queue_manager_init_cik_hawaii(&dqm->asic_ops);
> break;
>
> + case CHIP_CARRIZO:
> case CHIP_TONGA:
> case CHIP_FIJI:
> case CHIP_POLARIS10:
> --
> 2.40.1
RE: [PATCH AUTOSEL 6.4 11/11] drm/amdkfd: disable IOMMUv2 support for Raven
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH AUTOSEL 6.4 11/11] drm/amdkfd: disable IOMMUv2
> support for Raven
>
> From: Alex Deucher
>
> [ Upstream commit 091ae5473f96ced844af6ba39b94757359b12348 ]
>
> Use the dGPU path instead. There were a lot of platform issues with IOMMU
> in general on these chips due to windows not enabling IOMMU at the time.
> The dGPU path has been used for a long time with newer APUs and works
> fine. This also paves the way to simplify the driver significantly.
This is not needed for stable.
Alex
>
> Reviewed-by: Felix Kuehling
> Acked-by: Christian König
> Tested-by: Mike Lothian
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 9c8197573dee7..224e057d2dbbf 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -185,11 +185,6 @@ static void kfd_device_info_init(struct kfd_dev *kfd,
>
> kfd_device_info_set_event_interrupt_class(kfd);
>
> - /* Raven */
> - if (gc_version == IP_VERSION(9, 1, 0) ||
> - gc_version == IP_VERSION(9, 2, 2))
> - kfd->device_info.needs_iommu_device = true;
> -
> if (gc_version < IP_VERSION(11, 0, 0)) {
> /* Navi2x+, Navi1x+ */
> if (gc_version == IP_VERSION(10, 3, 6)) @@ -283,7
> +278,6 @@ struct kfd_dev *kgd2kfd_probe(struct amdgpu_device *adev,
> bool vf)
> gfx_target_version = 9;
> f2g = &gfx_v9_kfd2kgd;
> break;
> -#ifdef KFD_SUPPORT_IOMMU_V2
> /* Raven */
> case IP_VERSION(9, 1, 0):
> case IP_VERSION(9, 2, 2):
> @@ -291,7 +285,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> if (!vf)
> f2g = &gfx_v9_kfd2kgd;
> break;
> -#endif
> /* Vega12 */
> case IP_VERSION(9, 2, 1):
> gfx_target_version = 90004;
> --
> 2.40.1
RE: [PATCH AUTOSEL 6.4 09/11] drm/amdkfd: ignore crat by default
[Public] > -Original Message- > From: Sasha Levin > Sent: Tuesday, August 22, 2023 7:36 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Deucher, Alexander ; Kuehling, Felix > ; Koenig, Christian ; > Mike Lothian ; Sasha Levin ; Pan, > Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 6.4 09/11] drm/amdkfd: ignore crat by default > > From: Alex Deucher > > [ Upstream commit a6dea2d64ff92851e68cd4e20a35f6534286e016 ] > > We are dropping the IOMMUv2 path, so no need to enable this. > It's often buggy on consumer platforms anyway. > This is not needed for stable. Alex > Reviewed-by: Felix Kuehling > Acked-by: Christian König > Tested-by: Mike Lothian > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > index 475e470273540..ee0cc35d68a84 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > @@ -1543,11 +1543,7 @@ static bool kfd_ignore_crat(void) > if (ignore_crat) > return true; > > -#ifndef KFD_SUPPORT_IOMMU_V2 > ret = true; > -#else > - ret = false; > -#endif > > return ret; > } > -- > 2.40.1
RE: [PATCH AUTOSEL 6.1 08/10] drm/amdkfd: ignore crat by default
[Public] > -Original Message- > From: Sasha Levin > Sent: Tuesday, August 22, 2023 7:36 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Deucher, Alexander ; Kuehling, Felix > ; Koenig, Christian ; > Mike Lothian ; Sasha Levin ; Pan, > Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 6.1 08/10] drm/amdkfd: ignore crat by default > > From: Alex Deucher > > [ Upstream commit a6dea2d64ff92851e68cd4e20a35f6534286e016 ] > > We are dropping the IOMMUv2 path, so no need to enable this. > It's often buggy on consumer platforms anyway. This is not needed for stable. Alex > > Reviewed-by: Felix Kuehling > Acked-by: Christian König > Tested-by: Mike Lothian > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > index e45c6bc8d10bb..a9fa4772b2d35 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > @@ -1543,11 +1543,7 @@ static bool kfd_ignore_crat(void) > if (ignore_crat) > return true; > > -#ifndef KFD_SUPPORT_IOMMU_V2 > ret = true; > -#else > - ret = false; > -#endif > > return ret; > } > -- > 2.40.1
RE: [PATCH AUTOSEL 6.1 09/10] drm/amdkfd: disable IOMMUv2 support for KV/CZ
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH AUTOSEL 6.1 09/10] drm/amdkfd: disable IOMMUv2
> support for KV/CZ
>
> From: Alex Deucher
>
> [ Upstream commit 616f92d188ee7142a95a52068efdbea82645f859 ]
>
> Use the dGPU path instead. There were a lot of platform issues with IOMMU
> in general on these chips due to windows not enabling IOMMU at the time.
> The dGPU path has been used for a long time with newer APUs and works
> fine. This also paves the way to simplify the driver significantly.
This is not needed for stable.
Alex
>
> v2: use the dGPU queue manager functions
>
> Reviewed-by: Felix Kuehling
> Acked-by: Christian König
> Tested-by: Mike Lothian
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 --
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 8 +---
> 2 files changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 27820f0a282d1..4cc5debdd119b 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -216,10 +216,6 @@ static void kfd_device_info_init(struct kfd_dev *kfd,
> asic_type != CHIP_TONGA)
> kfd->device_info.supports_cwsr = true;
>
> - if (asic_type == CHIP_KAVERI ||
> - asic_type == CHIP_CARRIZO)
> - kfd->device_info.needs_iommu_device = true;
> -
> if (asic_type != CHIP_HAWAII && !vf)
> kfd->device_info.needs_pci_atomics = true;
> }
> @@ -233,7 +229,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> uint32_t gfx_target_version = 0;
>
> switch (adev->asic_type) {
> -#ifdef KFD_SUPPORT_IOMMU_V2
> #ifdef CONFIG_DRM_AMDGPU_CIK
> case CHIP_KAVERI:
> gfx_target_version = 7;
> @@ -246,7 +241,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> if (!vf)
> f2g = &gfx_v8_kfd2kgd;
> break;
> -#endif
> #ifdef CONFIG_DRM_AMDGPU_CIK
> case CHIP_HAWAII:
> gfx_target_version = 70001;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index c06ada0844ba1..5616a722578f5 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -2335,18 +2335,12 @@ struct device_queue_manager
> *device_queue_manager_init(struct kfd_dev *dev)
> }
>
> switch (dev->adev->asic_type) {
> - case CHIP_CARRIZO:
> - device_queue_manager_init_vi(&dqm->asic_ops);
> - break;
> -
> case CHIP_KAVERI:
> - device_queue_manager_init_cik(&dqm->asic_ops);
> - break;
> -
> case CHIP_HAWAII:
> device_queue_manager_init_cik_hawaii(&dqm->asic_ops);
> break;
>
> + case CHIP_CARRIZO:
> case CHIP_TONGA:
> case CHIP_FIJI:
> case CHIP_POLARIS10:
> --
> 2.40.1
RE: [PATCH AUTOSEL 5.15 6/6] drm/amdkfd: ignore crat by default
[Public] > -Original Message- > From: Sasha Levin > Sent: Tuesday, August 22, 2023 7:37 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Deucher, Alexander ; Kuehling, Felix > ; Koenig, Christian ; > Mike Lothian ; Sasha Levin ; Pan, > Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 5.15 6/6] drm/amdkfd: ignore crat by default > > From: Alex Deucher > > [ Upstream commit a6dea2d64ff92851e68cd4e20a35f6534286e016 ] > > We are dropping the IOMMUv2 path, so no need to enable this. > It's often buggy on consumer platforms anyway. This is not needed for stable. Alex > > Reviewed-by: Felix Kuehling > Acked-by: Christian König > Tested-by: Mike Lothian > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > index e574aa32a111d..46dfd9baeb013 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > @@ -1523,11 +1523,7 @@ static bool kfd_ignore_crat(void) > if (ignore_crat) > return true; > > -#ifndef KFD_SUPPORT_IOMMU_V2 > ret = true; > -#else > - ret = false; > -#endif > > return ret; > } > -- > 2.40.1
RE: [PATCH AUTOSEL 6.1 10/10] drm/amdkfd: disable IOMMUv2 support for Raven
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH AUTOSEL 6.1 10/10] drm/amdkfd: disable IOMMUv2
> support for Raven
>
> From: Alex Deucher
>
> [ Upstream commit 091ae5473f96ced844af6ba39b94757359b12348 ]
>
> Use the dGPU path instead. There were a lot of platform issues with IOMMU
> in general on these chips due to windows not enabling IOMMU at the time.
> The dGPU path has been used for a long time with newer APUs and works
> fine. This also paves the way to simplify the driver significantly.
This is not needed for stable.
Alex
>
> Reviewed-by: Felix Kuehling
> Acked-by: Christian König
> Tested-by: Mike Lothian
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 4cc5debdd119b..af18378e58d9f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -185,11 +185,6 @@ static void kfd_device_info_init(struct kfd_dev *kfd,
>
> kfd_device_info_set_event_interrupt_class(kfd);
>
> - /* Raven */
> - if (gc_version == IP_VERSION(9, 1, 0) ||
> - gc_version == IP_VERSION(9, 2, 2))
> - kfd->device_info.needs_iommu_device = true;
> -
> if (gc_version < IP_VERSION(11, 0, 0)) {
> /* Navi2x+, Navi1x+ */
> if (gc_version == IP_VERSION(10, 3, 6)) @@ -287,7
> +282,6 @@ struct kfd_dev *kgd2kfd_probe(struct amdgpu_device *adev,
> bool vf)
> gfx_target_version = 9;
> f2g = &gfx_v9_kfd2kgd;
> break;
> -#ifdef KFD_SUPPORT_IOMMU_V2
> /* Raven */
> case IP_VERSION(9, 1, 0):
> case IP_VERSION(9, 2, 2):
> @@ -295,7 +289,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> if (!vf)
> f2g = &gfx_v9_kfd2kgd;
> break;
> -#endif
> /* Vega12 */
> case IP_VERSION(9, 2, 1):
> gfx_target_version = 90004;
> --
> 2.40.1
RE: [PATCH AUTOSEL 5.10 3/3] drm/amdkfd: ignore crat by default
[Public] > -Original Message- > From: Sasha Levin > Sent: Tuesday, August 22, 2023 7:37 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Deucher, Alexander ; Kuehling, Felix > ; Koenig, Christian ; > Mike Lothian ; Sasha Levin ; Pan, > Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 5.10 3/3] drm/amdkfd: ignore crat by default > > From: Alex Deucher > > [ Upstream commit a6dea2d64ff92851e68cd4e20a35f6534286e016 ] > > We are dropping the IOMMUv2 path, so no need to enable this. > It's often buggy on consumer platforms anyway. This is not needed for stable. Alex > > Reviewed-by: Felix Kuehling > Acked-by: Christian König > Tested-by: Mike Lothian > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > index 86b4dadf772e3..61fea0d268b96 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > @@ -749,11 +749,7 @@ static bool kfd_ignore_crat(void) > if (ignore_crat) > return true; > > -#ifndef KFD_SUPPORT_IOMMU_V2 > ret = true; > -#else > - ret = false; > -#endif > > return ret; > } > -- > 2.40.1
RE: [PATCH 0/5] Add the pci_get_base_class() helper and use it
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Sui
> Jingfeng
> Sent: Friday, August 25, 2023 2:27 AM
> To: Bjorn Helgaas
> Cc: alsa-de...@alsa-project.org; Sui Jingfeng ;
> nouv...@lists.freedesktop.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; linux-
> p...@vger.kernel.org
> Subject: [PATCH 0/5] Add the pci_get_base_class() helper and use it
>
> From: Sui Jingfeng
>
> There is no function that can be used to get all PCI(e) devices in a system by
> matching against its the PCI base class code only, while keep the sub-class
> code
> and the programming interface ignored. Therefore, add the
> pci_get_base_class() function to suit the need.
>
> For example, if an application want to process all PCI(e) display devices in a
> system, it can achieve such goal by writing the code as following:
>
> pdev = NULL;
> do {
> pdev = pci_get_base_class(PCI_BASE_CLASS_DISPLAY, pdev);
> if (!pdev)
> break;
>
> do_something_for_pci_display_device(pdev);
> } while (1);
>
> Sui Jingfeng (5):
> PCI: Add the pci_get_base_class() helper
> ALSA: hda/intel: Use pci_get_base_class() to reduce duplicated code
> drm/nouveau: Use pci_get_base_class() to reduce duplicated code
> drm/amdgpu: Use pci_get_base_class() to reduce duplicated code
> drm/radeon: Use pci_get_base_class() to reduce duplicated code
>
Series is:
Reviewed-by: Alex Deucher
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 11 +++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 20 ---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 11 +++--
> drivers/gpu/drm/radeon/radeon_bios.c | 20 ---
> drivers/pci/search.c | 31
> include/linux/pci.h | 5
> sound/pci/hda/hda_intel.c| 16
> 7 files changed, 59 insertions(+), 55 deletions(-)
>
> --
> 2.34.1
Enabling peer to peer device transactions for PCIe devices
> -Original Message- > From: Haggai Eran [mailto:haggaie at mellanox.com] > Sent: Wednesday, November 30, 2016 5:46 AM > To: Jason Gunthorpe > Cc: linux-kernel at vger.kernel.org; linux-rdma at vger.kernel.org; linux- > nvdimm at ml01.01.org; Koenig, Christian; Suthikulpanit, Suravee; Bridgman, > John; Deucher, Alexander; Linux-media at vger.kernel.org; > dan.j.williams at intel.com; logang at deltatee.com; dri- > devel at lists.freedesktop.org; Max Gurtovoy; linux-pci at vger.kernel.org; > Sagalovitch, Serguei; Blinzer, Paul; Kuehling, Felix; Sander, Ben > Subject: Re: Enabling peer to peer device transactions for PCIe devices > > On 11/28/2016 9:02 PM, Jason Gunthorpe wrote: > > On Mon, Nov 28, 2016 at 06:19:40PM +, Haggai Eran wrote: > >>>> GPU memory. We create a non-ODP MR pointing to VRAM but rely on > >>>> user-space and the GPU not to migrate it. If they do, the MR gets > >>>> destroyed immediately. > >>> That sounds horrible. How can that possibly work? What if the MR is > >>> being used when the GPU decides to migrate? > >> Naturally this doesn't support migration. The GPU is expected to pin > >> these pages as long as the MR lives. The MR invalidation is done only as > >> a last resort to keep system correctness. > > > > That just forces applications to handle horrible unexpected > > failures. If this sort of thing is needed for correctness then OOM > > kill the offending process, don't corrupt its operation. > Yes, that sounds fine. Can we simply kill the process from the GPU driver? > Or do we need to extend the OOM killer to manage GPU pages? Christian sent out an RFC patch a while back that extended the OOM to cover memory allocated for the GPU: https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html Alex > > > > >> I think it is similar to how non-ODP MRs rely on user-space today to > >> keep them correct. If you do something like madvise(MADV_DONTNEED) > on a > >> non-ODP MR's pages, you can still get yourself into a data corruption > >> situation (HCA sees one page and the process sees another for the same > >> virtual address). The pinning that we use only guarentees the HCA's page > >> won't be reused. > > > > That is not really data corruption - the data still goes where it was > > originally destined. That is an application violating the > > requirements of a MR. > I guess it is a matter of terminology. If you compare it to the ODP case > or the CPU case then you usually expect a single virtual address to map to > a single physical page. Violating this cause some of your writes to be dropped > which is a data corruption in my book, even if the application caused it. > > > An application cannot munmap/mremap a VMA > > while a non ODP MR points to it and then keep using the MR. > Right. And it is perfectly fine to have some similar requirements from the > application > when doing peer to peer with a non-ODP MR. > > > That is totally different from a GPU driver wanthing to mess with > > translation to physical pages. > > > >>> From what I understand we are not really talking about kernel p2p, > >>> everything proposed so far is being mediated by a userspace VMA, so > >>> I'd focus on making that work. > > > >> Fair enough, although we will need both eventually, and I hope the > >> infrastructure can be shared to some degree. > > > > What use case do you see for in kernel? > Two cases I can think of are RDMA access to an NVMe device's controller > memory buffer, and O_DIRECT operations that access GPU memory. > Also, HMM's migration between two GPUs could use peer to peer in the > kernel, > although that is intended to be handled by the GPU driver if I understand > correctly. > > > Presumably in-kernel could use a vmap or something and the same basic > > flow? > I think we can achieve the kernel's needs with ZONE_DEVICE and DMA-API > support > for peer to peer. I'm not sure we need vmap. We need a way to have a > scatterlist > of MMIO pfns, and ZONE_DEVICE allows that. > > Haggai
[PATCH] drm/amd/amdgpu: default to zero number of states if not enabled
> -Original Message- > From: Colin Ian King [mailto:colin.king at canonical.com] > Sent: Thursday, October 06, 2016 3:04 PM > To: Alex Deucher > Cc: Deucher, Alexander; Koenig, Christian; David Airlie; Huang, JinHuiEric; > Zhu, Rex; Zhou, Jammy; StDenis, Tom; Dan Carpenter; Maling list - DRI > developers; LKML > Subject: Re: [PATCH] drm/amd/amdgpu: default to zero number of states if > not enabled > > On 06/10/16 19:32, Alex Deucher wrote: > > On Thu, Oct 6, 2016 at 2:02 PM, Colin King > wrote: > >> From: Colin Ian King > >> > >> Currently, if adev->pp_enabled is false then the pp_stats_info data > >> is not read and hence a garbage number of states from the stack > >> is used to dump out the number of states. Given data.nums could be > >> any random value, this could easily lead to read outside the > >> data.states array. Fix this by setting data.nums to zero if > >> adev->pp_enabled is false. > > > > Are you actually seeing a problem? > > Nope. > > > The pp_num_states attribute only > > gets added in the first place if pp_enabled is true. > > Does that mean that the check on adev->pp_enabled is redundant then? Yes, I think so. Alex > > > > > Alex > > > > >> > >> Signed-off-by: Colin Ian King > >> --- > >> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > >> index accc908..808d788 100644 > >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > >> @@ -195,6 +195,8 @@ static ssize_t amdgpu_get_pp_num_states(struct > device *dev, > >> > >> if (adev->pp_enabled) > >> amdgpu_dpm_get_pp_num_states(adev, &data); > >> + else > >> + data.nums = 0; > >> > >> buf_len = snprintf(buf, PAGE_SIZE, "states: %d\n", data.nums); > >> for (i = 0; i < data.nums; i++) > >> -- > >> 2.9.3 > >> > >> ___ > >> dri-devel mailing list > >> dri-devel at lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
commit a481daa88fd (drm/radeon: always apply pci shutdown callbacks) breaks reboot
> -Original Message- > From: Markus Trippelsdorf [mailto:markus at trippelsdorf.de] > Sent: Wednesday, October 12, 2016 4:40 PM > To: Deucher, Alexander > Cc: Koenig, Christian; dri-devel at lists.freedesktop.org > Subject: commit a481daa88fd (drm/radeon: always apply pci shutdown > callbacks) breaks reboot > > Since: > > commit a481daa88fd4d6b54f25348972bba10b5f6a84d0 > Author: Alex Deucher > Date: Thu Sep 22 14:43:50 2016 -0400 > > drm/radeon: always apply pci shutdown callbacks > > We can't properly detect all hypervisors and we > need this to properly tear down the hardware. > > I cannot reboot my machine anymore. Before reboot the monitor goes blank > and > the machine stays in that state until I press the reset button. > > Hardware is RS780. Fixed with this series: https://lists.freedesktop.org/archives/amd-gfx/2016-October/002833.html Alex > > -- > Markus
[PATCH] drm/amd/powerplay: don't give up if DPM is already running
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Zhu, Rex
> Sent: Friday, October 14, 2016 8:12 AM
> To: Alex Deucher
> Cc: Maling list - DRI developers; amd-gfx list
> Subject: RE: [PATCH] drm/amd/powerplay: don't give up if DPM is already
> running
>
> Hi Alex,
>
> Your new attached patch is Tested-by and Reviewed-by: Rex Zhu
>
>
> Just one question,
>
> Do we need to set clock_gate for smu?
At the moment, no, but if we ever have have clockgating for smu related IPs, we
might as well include it. It matches the current behavior with respect to IP
tear down.
Alex
>
> Best Regards
> Rex
>
>
> -Original Message-
> From: Alex Deucher [mailto:alexdeucher at gmail.com]
> Sent: Thursday, October 13, 2016 11:29 PM
> To: Zhu, Rex
> Cc: Grazvydas Ignotas; amd-gfx list; Maling list - DRI developers
> Subject: Re: [PATCH] drm/amd/powerplay: don't give up if DPM is already
> running
>
> On Thu, Oct 13, 2016 at 3:45 AM, Zhu, Rex wrote:
> > Hi all,
> >
> > The attached patches were also for this issue.
> > Disable dpm when rmmod amdgpu.
> >
> > Please help to review.
>
> Patch 1:
> +r = adev->ip_blocks[AMD_IP_BLOCK_TYPE_SMC].funcs->hw_fini((void
> *)adev);
> +if (r)
> +DRM_DEBUG("hw_fini of IP block <%s> failed %d\n",
> +adev->ip_blocks[AMD_IP_BLOCK_TYPE_SMC].funcs->name, r);
> +
> +adev->ip_block_status[AMD_IP_BLOCK_TYPE_SMC].hw = false;
>
> You can't use AMD_IP_BLOCK_TYPE_* as index. Some chips may not have
> the IP block. Maybe something like the attached patch. That said, I think
> longer term it makes more sense to allows the SOCs to specify the order for
> init, fini, etc. otherwise we'll have lots of variable logic in the common
> code.
>
> Patch 2:
> +if (1 == PHM_READ_VFPF_INDIRECT_FIELD(hwmgr->device,
> CGS_IND_REG__SMC, FEATURE_STATUS, AVS_ON)) {
> +PP_ASSERT_WITH_CODE((0 == smum_send_msg_to_smc(hwmgr-
> >smumgr,
> PPSMC_MSG_DisableAvfs)),
> +"Failed to disable AVFS!",
> +return -1;);
> +}
>
> Use a proper error code there like -EINVAL or something. With that fixed:
> Reviewed-by: Alex Deucher
>
> Alex
>
> >
> > Best Regards
> > Rex
> >
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> > Of Zhu, Rex
> > Sent: Wednesday, October 12, 2016 9:45 PM
> > To: Alex Deucher; Grazvydas Ignotas
> > Cc: amd-gfx list; Maling list - DRI developers
> > Subject: RE: [PATCH] drm/amd/powerplay: don't give up if DPM is
> > already running
> >
> > Hi Grazvydas and Alex,
> >
> > We needed to disable dpm when rmmod amdgpu for this issue.
> >
> > I am checking the function of disable dpm task.
> >
> > Best Regards
> > Rex
> >
> > -Original Message-
> > From: Alex Deucher [mailto:alexdeucher at gmail.com]
> > Sent: Wednesday, October 12, 2016 4:01 AM
> > To: Grazvydas Ignotas; Zhu, Rex
> > Cc: Maling list - DRI developers; amd-gfx list
> > Subject: Re: [PATCH] drm/amd/powerplay: don't give up if DPM is
> > already running
> >
> > +Rex to review this.
> >
> > Alex
> >
> > On Sun, Oct 9, 2016 at 3:23 PM, Grazvydas Ignotas
> wrote:
> >> Currently the driver crashes if smu7_enable_dpm_tasks() returns
> >> early, which it does if DPM is already active. It seems to be better
> >> just to continue anyway, at least I haven't noticed any ill effects.
> >> It's also unclear at what state the hardware was left by the previous
> >> driver, so IMO it's better to always fully initialize.
> >>
> >> Way to reproduce:
> >> $ modprobe amdgpu
> >> $ rmmod amdgpu
> >> $ modprobe amdgpu
> >> ...
> >> DPM is already running right now, no need to enable DPM!
> >> ...
> >> failed to send message 18b ret is 0
> >> BUG: unable to handle kernel paging request at ed01fc9ab21f Call
> >> Trace:
> >> smu7_set_power_state_tasks+0x499/0x1940 [amdgpu]
> >> phm_set_power_state+0xcb/0x120 [amdgpu]
> >> psm_adjust_power_state_dynamic+0x11e/0x1b0 [amdgpu]
> >> pem_task_adjust_power_state+0xb9/0xd0 [amdgpu]
> >> pem_excute_event_chain+0x7d/0xe0 [amdgpu]
> >> pem_handle_event_unlocked+0x49/0x60 [amdgpu]
> >> pem_handle_event+0xe/0x10 [amdgpu]
> >> pp_dpm_dispatch_tasks+0xe0/0x190 [amdgpu]
> >> amdgpu_pm_compute_clocks+0x10c/0xc60 [amdgpu]
> >> dce_v11_0_crtc_dpms+0x7d/0x150 [amdgpu]
> >> dce_v11_0_crtc_disable+0x90/0x4a0 [amdgpu]
> >> drm_helper_disable_unused_functions+0x67/0x80 [drm_kms_helper]
> >> amdgpu_fbdev_init+0x13e/0x170 [amdgpu]
> >> amdgpu_device_init+0x1aeb/0x2490 [amdgpu]
> >>
> >> Signed-off-by: Grazvydas Ignotas
> >> ---
> >> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> index f6afa6a..327030b 100644
> >> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> +++ b/drivers/gpu/drm/amd
RE: [PATCH] drm: Silence the compiler for drm_mode_get_hv_timings()
> -Original Message-
> From: Chris Wilson [mailto:chris.ickle.wil...@gmail.com] On Behalf Of Chris
> Wilson
> Sent: Thursday, January 26, 2017 6:44 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Chris Wilson; Daniel Vetter; Deucher, Alexander
> Subject: [PATCH] drm: Silence the compiler for drm_mode_get_hv_timings()
>
> Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler
> has been able to get smarter and spots that drm_mode_copy() is trying to
> preserve garbage from the stack.
>
> Fixes: 196cd5d3758c ("drm:
> s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/")
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Alex Deucher
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_modes.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 73ed6399c3fb..a8616b1a8d22 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -808,9 +808,8 @@ EXPORT_SYMBOL(drm_mode_vrefresh);
> void drm_mode_get_hv_timing(const struct drm_display_mode *mode,
> int *hdisplay, int *vdisplay)
> {
> - struct drm_display_mode adjusted;
> + struct drm_display_mode adjusted = *mode;
>
> - drm_mode_copy(&adjusted, mode);
> drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE_ONLY);
> *hdisplay = adjusted.crtc_hdisplay;
> *vdisplay = adjusted.crtc_vdisplay;
> --
> 2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v1 2/2] drm/radeon: make MacBook Pro d3_delay quirk more generic
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Bjorn Helgaas
> Sent: Monday, January 30, 2017 3:41 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: linux...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; Maarten Lankhorst
> Subject: [PATCH v1 2/2] drm/radeon: make MacBook Pro d3_delay quirk
> more generic
>
> The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond
> delay when powering on a device, i.e., transitioning from state D3hot to
> D0.
>
> Apparently some devices require more time, and d1f9809ed131
> ("drm/radeon:
> add quirk for d3 delay during switcheroo poweron for apple macbooks")
> added
> an additional delay for the Radeon device in a MacBook Pro. 4807c5a8a0c8
> ("drm/radeon: add a PX quirk list") made the affected device more explicit.
>
> Add a generic PCI quirk to increase the d3_delay. This means we will use
> the additional delay for *all* wakeups from D3, not just those initiated by
> radeon_switcheroo_set_state().
>
> Signed-off-by: Bjorn Helgaas
> CC: Maarten Lankhorst
For the series:
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 12
> drivers/pci/quirks.c | 13 +
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 8a1df2a1afbd..8b8fd981cae5 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -113,7 +113,6 @@ static inline bool radeon_is_atpx_hybrid(void) {
> return false; }
> #endif
>
> #define RADEON_PX_QUIRK_DISABLE_PX (1 << 0)
> -#define RADEON_PX_QUIRK_LONG_WAKEUP (1 << 1)
>
> struct radeon_px_quirk {
> u32 chip_vendor;
> @@ -136,9 +135,6 @@ static struct radeon_px_quirk radeon_px_quirk_list[]
> = {
>* https://bugzilla.kernel.org/show_bug.cgi?id=51381
>*/
> { PCI_VENDOR_ID_ATI, 0x6840, 0x1043, 0x2122,
> RADEON_PX_QUIRK_DISABLE_PX },
> - /* macbook pro 8.2 */
> - { PCI_VENDOR_ID_ATI, 0x6741, PCI_VENDOR_ID_APPLE, 0x00e2,
> RADEON_PX_QUIRK_LONG_WAKEUP },
> - { 0, 0, 0, 0, 0 },
> };
>
> bool radeon_is_px(struct drm_device *dev)
> @@ -1241,25 +1237,17 @@ static void radeon_check_arguments(struct
> radeon_device *rdev)
> static void radeon_switcheroo_set_state(struct pci_dev *pdev, enum
> vga_switcheroo_state state)
> {
> struct drm_device *dev = pci_get_drvdata(pdev);
> - struct radeon_device *rdev = dev->dev_private;
>
> if (radeon_is_px(dev) && state == VGA_SWITCHEROO_OFF)
> return;
>
> if (state == VGA_SWITCHEROO_ON) {
> - unsigned d3_delay = dev->pdev->d3_delay;
> -
> printk(KERN_INFO "radeon: switched on\n");
> /* don't suspend or resume card normally */
> dev->switch_power_state =
> DRM_SWITCH_POWER_CHANGING;
>
> - if (d3_delay < 20 && (rdev->px_quirk_flags &
> RADEON_PX_QUIRK_LONG_WAKEUP))
> - dev->pdev->d3_delay = 20;
> -
> radeon_resume_kms(dev, true, true);
>
> - dev->pdev->d3_delay = d3_delay;
> -
> dev->switch_power_state = DRM_SWITCH_POWER_ON;
> drm_kms_helper_poll_enable(dev);
> } else {
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 1800befa8b8b..512d7a875d62 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -1683,6 +1683,19 @@
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2609,
> quirk_intel_pcie_pm);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x260a,
> quirk_intel_pcie_pm);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x260b,
> quirk_intel_pcie_pm);
>
> +static void quirk_radeon_pm(struct pci_dev *dev)
> +{
> + if (dev->subsystem_vendor == PCI_VENDOR_ID_APPLE &&
> + dev->subsystem_device == 0x00e2) {
> + if (dev->d3_delay < 20) {
> + dev->d3_delay = 20;
> + dev_info(&dev->dev, "extending delay after power-
> on from D3 to %d msec\n",
> + dev->d3_delay);
> + }
> + }
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6741,
> quirk_radeon_pm);
> +
> #ifdef CONFIG_X86_IO_APIC
> /*
> * Boot interrupts on some chipsets cannot be turned off. For these
> chipsets,
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Complete CEA modedb(VIC 1-107)
> -Original Message-
> From: Shashank Sharma [mailto:shashank.sharma at intel.com]
> Sent: Wednesday, November 02, 2016 5:46 AM
> To: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org
> Cc: airlied at redhat.com; daniel.vetter at intel.com;
> Jose.Abreu at synopsys.com; Shashank Sharma; Deucher, Alexander
> Subject: [PATCH v2] drm: Complete CEA modedb(VIC 1-107)
>
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
>
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
I don't have the spec in front of me to double check the timings, but assuming
the previous typos were addressed, the patch is:
Reviewed-by: Alex Deucher
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Sonika Jindal
> Reviewed-by: Jose Abreu
> Reviewed-by: Alex Deucher
>
> Cc: Jose Abreu
> Cc: Alex Deucher
>
> V2: Addressed review comments from Jose:
> - fix the timings for VIC 83, 90 and 91
> - fix formatting for VIC 93-107
> ---
> drivers/gpu/drm/drm_edid.c | 215
> +
> 1 file changed, 215 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {
> 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720 at 24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280,
> 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 24, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720 at 25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720 at 30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 30, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720 at 50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 50, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720 at 60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 60, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720 at 100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280,
> 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 100, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720 at 120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280,
> 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 120, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080 at 24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 24, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080 at 25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2448,
> +
[PATCH] drm/amd/powerplay: return false instead of -EINVAL
> -Original Message-
> From: Andrew Shadura [mailto:andrew.shadura at collabora.co.uk]
> Sent: Thursday, November 03, 2016 6:09 AM
> To: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org;
> Deucher,
> Alexander; Koenig, Christian; David Airlie
> Cc: Zhu, Rex; Jammy Zhou
> Subject: [PATCH] drm/amd/powerplay: return false instead of -EINVAL
>
> Returning -EINVAL from a bool-returning function
> phm_check_smc_update_required_for_display_configuration has an
> unexpected
> effect of returning true, which is probably not what was intended.
> Replace -EINVAL by false.
>
> The only place this function is called from is
> psm_adjust_power_state_dynamic in
> drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:
>
> if (!equal ||
> phm_check_smc_update_required_for_display_configuration(hwmgr)) {
> phm_apply_state_adjust_rules(hwmgr, requested,
> pcurrent);
> phm_set_power_state(hwmgr, &pcurrent->hardware,
> &requested->hardware);
> hwmgr->current_ps = requested;
> }
>
> It seems to expect a boolean value here.
>
> This issue has been found using the following Coccinelle semantic patch
> written by Peter Senna Tschudin:
>
> @@
> identifier f;
> constant C;
> typedef bool;
> @@
> bool f (...){
> <+...
> * return -C;
> ...+>
> }
>
>
> Signed-off-by: Andrew Shadura
Reviewed-by: Alex Deucher
I'll pick this up shortly. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> index 789f98a..82038b08 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> @@ -306,7 +306,7 @@ bool
> phm_check_smc_update_required_for_display_configuration(struct
> pp_hwmgr *hw
> PHM_FUNC_CHECK(hwmgr);
>
> if (hwmgr->hwmgr_func-
> >check_smc_update_required_for_display_configuration == NULL)
> - return -EINVAL;
> + return false;
>
> return hwmgr->hwmgr_func-
> >check_smc_update_required_for_display_configuration(hwmgr);
> }
> --
> 2.7.4
>
[PATCH] drm/amd/powerplay: return false instead of -EINVAL
> -Original Message-
> From: Andrew Shadura [mailto:andrew.shadura at collabora.co.uk]
> Sent: Thursday, November 03, 2016 12:42 PM
> To: Deucher, Alexander; linux-kernel at vger.kernel.org; dri-
> devel at lists.freedesktop.org; Koenig, Christian; David Airlie
> Cc: Zhu, Rex; Jammy Zhou
> Subject: Re: [PATCH] drm/amd/powerplay: return false instead of -EINVAL
>
> On 03/11/16 17:39, Deucher, Alexander wrote:
> >> Returning -EINVAL from a bool-returning function
> >> phm_check_smc_update_required_for_display_configuration has an
> >> unexpected
> >> effect of returning true, which is probably not what was intended.
> >> Replace -EINVAL by false.
> >>
> >> The only place this function is called from is
> >> psm_adjust_power_state_dynamic in
> >> drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:
> >>
> >>if (!equal ||
> >> phm_check_smc_update_required_for_display_configuration(hwmgr)) {
> >>phm_apply_state_adjust_rules(hwmgr, requested,
> >> pcurrent);
> >>phm_set_power_state(hwmgr, &pcurrent->hardware,
> >> &requested->hardware);
> >>hwmgr->current_ps = requested;
> >>}
> >>
> >> It seems to expect a boolean value here.
> >>
> >> This issue has been found using the following Coccinelle semantic patch
> >> written by Peter Senna Tschudin:
> >>
> >> @@
> >> identifier f;
> >> constant C;
> >> typedef bool;
> >> @@
> >> bool f (...){
> >> <+...
> >> * return -C;
> >> ...+>
> >> }
> >>
> >>
> >> Signed-off-by: Andrew Shadura
> >
> > Reviewed-by: Alex Deucher
> >
> > I'll pick this up shortly. Thanks!
>
> Great, thanks! I wonder who should I prod for this one:
> https://patchwork.kernel.org/patch/7206081/
PowerPC developers?
Alex
>
> --
> Cheers,
> Andrew
[PATCH 2/3] drm/amdgpu: add the interface of waiting multiple fences (v3)
> -Original Message- > From: Sumit Semwal [mailto:sumit.semwal at linaro.org] > Sent: Friday, November 04, 2016 1:15 PM > To: Alex Deucher > Cc: amd-gfx at lists.freedesktop.org; DRI mailing list; Zhang, Jerry; Deucher, > Alexander > Subject: Re: [PATCH 2/3] drm/amdgpu: add the interface of waiting multiple > fences (v3) > > Hi Alex, > > Thanks for the patch! > > On 3 November 2016 at 11:41, Alex Deucher > wrote: > > From: Junwei Zhang > > > > v2: agd: rebase and squash in all the previous optimizations and > > changes so everything compiles. > > v3: squash in Slava's 32bit build fix > > > > Signed-off-by: Junwei Zhang > > Reviewed-by: Monk Liu > > Reviewed-by: Jammy Zhou > > Signed-off-by: Alex Deucher > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 171 > > > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 + > > include/uapi/drm/amdgpu_drm.h | 27 + > > 4 files changed, 201 insertions(+) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > > index 8d0c689..c2050c0 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > > > + > > + r = fence_wait_any_timeout(array, fence_count, true, timeout); > > With the change proposed about returning index of signalled fence in > patch 1/3, I don't think this would build? Yes, Sorry, I messed up the order when I rebased the patches. It should be 2 1 3. Alex > > Best regards, > Sumit.
v4.9-rc3: radeon oops on shutdown
> -Original Message- > From: Pavel Machek [mailto:pavel at ucw.cz] > Sent: Monday, November 07, 2016 1:40 PM > To: Deucher, Alexander; Koenig, Christian; dri-devel at lists.freedesktop.org; > kernel list > Subject: v4.9-rc3: radeon oops on shutdown > > Hi! > > On old thinkpad T40p... with v4.9-rc3+ I'm getting radeon oops on > shutdown. Seems repeatable. > > Unable to handle kernel NULL pointer dereference at 78c. > IP: .. radeon_connector_unregister > ... > trace: > ? drm_connector_unregister.part.5 > drm_connector_unregister_all > Already fixed: https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=0a6e21056eaa859353945c4b164f3ef574d84271 Alex
[Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
Adding Harry and Tony from our display team to review. > -Original Message- > From: Jani Nikula [mailto:jani.nikula at linux.intel.com] > Sent: Thursday, November 10, 2016 1:20 PM > To: Manasi Navare; dri-devel at lists.freedesktop.org; intel- > gfx at lists.freedesktop.org > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during > modeset > > On Thu, 10 Nov 2016, Manasi Navare wrote: > > Link training failure is handled by lowering the link rate first > > until it reaches the minimum and keeping the lane count maximum > > and then lowering the lane count until it reaches minimim. These > > fallback values are saved and hotplug uevent is sent to the userspace > > after setting the connector link status property to BAD. Userspace > > should triiger another modeset on a uevent and if link status property > > is BAD. This will retrain the link at fallback values. > > This is repeated until the link is successfully trained. > > > > This has been validated to pass DP compliance. > > This cover letter and the commit messages do a good job of explaining > what the patches do. However, you're lacking the crucial information of > *why* we need userspace cooperation to handle link training failures on > DP mode setting, and *why* a new connector property is a good solution > for this. > > Here goes, including some alternative approaches we've considered (and > even tried): > > At the time userspace does setcrtc, we've already promised the mode > would work. The promise is based on the theoretical capabilities of the > link, but it's possible we can't reach this in practice. The DP spec > describes how the link should be reduced, but we can't reduce the link > below the requirements of the mode. Black screen follows. > > One idea would be to have setcrtc return a failure. However, it is my > understanding that it already should not fail as the atomic checks have > passed [citation needed]. It would also conflict with the idea of making > setcrtc asynchronous in the future, returning before the actual mode > setting and link training. > > Another idea is to train the link "upfront" at hotplug time, before > pruning the mode list, so that we can do the pruning based on practical > not theoretical capabilities. However, the changes for link training are > pretty drastic, all for the sake of error handling and DP compliance, > when the most common happy day scenario is the current approach of link > training at mode setting time, using the optimal parameters for the > mode. It is also not certain all hardware could do this without the pipe > on; not even all our hardware can do this. Some of this can be solved, > but not trivially. > > Both of the above ideas also fail to address link degradation *during* > operation. > > So the idea presented in these patches is to do this in a way that a) > changes the current happy day scenario as little as possible, to avoid > regressions, b) can be implemented the same way by all drm drivers, c) > is still opt-in for the drivers and userspace, and opting out doesn't > regress the user experience, d) doesn't prevent drivers from > implementing better or alternate approaches, possibly without userspace > involvement. And, of course, handles all the issues presented. > > The solution is to add a "link status" connector property. In the usual > happy day scenario, this is always "good". If something fails during or > after a mode set, the kernel driver can set the link status to "bad", > prune the mode list based on new information as necessary, and send a > hotplug uevent for userspace to have it re-check the valid modes through > getconnector, and try again. If the theoretical capabilities of the link > can't be reached, the mode list is trimmed based on that. > > If the userspace is not aware of the property, the user experience is > the same as it currently is. If the userspace is aware of the property, > it has a chance to improve user experience. If a drm driver does not > modify the property (it stays "good"), the user experience is the same > as it currently is. A drm driver can also choose to try to handle more > of the failures in kernel, hardware not limiting, or it can choose to > involve userspace more. Up to the drivers. > > The reason for adding the property is to handle link training failures, > but it is not limited to DP or link training. For example, if we > implement asynchronous setcrtc, we can use this to report any failures > in that. > > Finally, while DP CTS compliance is advertized (which is
[PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it
> -Original Message-
> From: Colin King [mailto:colin.king at canonical.com]
> Sent: Tuesday, November 15, 2016 7:55 AM
> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis,
> Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri-
> devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Subject: [PATCH] drm/amd/powerplay: check if table_info is NULL before
> dereferencing it
>
> From: Colin Ian King
>
> table_info is being dereferenced before a null check, which implies
> a potential null pointer deference error. Fix this by moving the null
> check of table_info to the start of smu7_get_evv_voltages to avoid
> potential null pointer deferencing.
>
> Found with static analysis by CoverityScan, CID 1377752
>
> Signed-off-by: Colin Ian King
NACK, this effectively reverts the patch. This causes the function to exit
early on asics where the table it NULL which is not what we want. Whether the
table exists or not is dependent on the table version and the feature caps for
the chip which are checked before the table is dereferenced. The NULL check in
the top if clause is not strictly necessary and could be removed.
Alex
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> index 28e748d..6798067 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> @@ -1473,6 +1473,8 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
> *hwmgr)
> (struct phm_ppt_v1_information *)hwmgr->pptable;
> struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table =
> NULL;
>
> + if (table_info == NULL)
> + return -EINVAL;
>
> for (i = 0; i < SMU7_MAX_LEAKAGE_COUNT; i++) {
> vv_id = ATOM_VIRTUAL_VOLTAGE_ID0 + i;
> @@ -1483,8 +1485,6 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
> *hwmgr)
> table_info-
> >vddgfx_lookup_table, vv_id, &sclk)) {
> if (phm_cap_enabled(hwmgr-
> >platform_descriptor.platformCaps,
>
> PHM_PlatformCaps_ClockStretcher)) {
> - if (table_info == NULL)
> - return -EINVAL;
> sclk_table = table_info-
> >vdd_dep_on_sclk;
>
> for (j = 1; j < sclk_table->count; j++)
> {
> @@ -1517,8 +1517,6 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
> *hwmgr)
> table_info->vddc_lookup_table,
> vv_id, &sclk)) {
> if (phm_cap_enabled(hwmgr-
> >platform_descriptor.platformCaps,
>
> PHM_PlatformCaps_ClockStretcher)) {
> - if (table_info == NULL)
> - return -EINVAL;
> sclk_table = table_info-
> >vdd_dep_on_sclk;
>
> for (j = 1; j < sclk_table->count; j++)
> {
> --
> 2.10.2
[PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it
> -Original Message-
> From: Colin Ian King [mailto:colin.king at canonical.com]
> Sent: Tuesday, November 15, 2016 11:09 AM
> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis,
> Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri-
> devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] drm/amd/powerplay: check if table_info is NULL before
> dereferencing it
>
> On 15/11/16 15:49, Deucher, Alexander wrote:
> >> -Original Message-
> >> From: Colin King [mailto:colin.king at canonical.com]
> >> Sent: Tuesday, November 15, 2016 7:55 AM
> >> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis,
> >> Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri-
> >> devel at lists.freedesktop.org
> >> Cc: linux-kernel at vger.kernel.org
> >> Subject: [PATCH] drm/amd/powerplay: check if table_info is NULL before
> >> dereferencing it
> >>
> >> From: Colin Ian King
> >>
> >> table_info is being dereferenced before a null check, which implies
> >> a potential null pointer deference error. Fix this by moving the null
> >> check of table_info to the start of smu7_get_evv_voltages to avoid
> >> potential null pointer deferencing.
> >>
> >> Found with static analysis by CoverityScan, CID 1377752
> >>
> >> Signed-off-by: Colin Ian King
> >
> > NACK, this effectively reverts the patch. This causes the function to exit
> early on asics where the table it NULL which is not what we want. Whether
> the table exists or not is dependent on the table version and the feature
> caps for the chip which are checked before the table is dereferenced. The
> NULL check in the top if clause is not strictly necessary and could be
> removed.
> >
> > Alex
>
> OK, understood. The part I'm missing is that we dereference table_info
> at the following statement:
>
> if ((hwmgr->pp_table_version == PP_TABLE_V1)
> && !phm_get_sclk_for_voltage_evv(hwmgr,
> table_info->vddgfx_lookup_table, vv_id, &sclk))
>
> and later check if it is NULL. So, I can't see where table_info is being
> set other than the start of the function, so, either it can be null and
> hence we have a null ptr deference, or it's never null, in which case
> the check for NULL is redundant.
Yes, that check is redundant. That is was I was referring to above.
Alex
>
> Colin
> >
> >> ---
> >> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 ++
> >> 1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> index 28e748d..6798067 100644
> >> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> @@ -1473,6 +1473,8 @@ static int smu7_get_evv_voltages(struct
> pp_hwmgr
> >> *hwmgr)
> >>(struct phm_ppt_v1_information *)hwmgr->pptable;
> >>struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table =
> >> NULL;
> >>
> >> + if (table_info == NULL)
> >> + return -EINVAL;
> >>
> >>for (i = 0; i < SMU7_MAX_LEAKAGE_COUNT; i++) {
> >>vv_id = ATOM_VIRTUAL_VOLTAGE_ID0 + i;
> >> @@ -1483,8 +1485,6 @@ static int smu7_get_evv_voltages(struct
> pp_hwmgr
> >> *hwmgr)
> >>table_info-
> >>> vddgfx_lookup_table, vv_id, &sclk)) {
> >>if (phm_cap_enabled(hwmgr-
> >>> platform_descriptor.platformCaps,
> >>
> >>PHM_PlatformCaps_ClockStretcher)) {
> >> - if (table_info == NULL)
> >> - return -EINVAL;
> >>sclk_table = table_info-
> >>> vdd_dep_on_sclk;
> >>
> >>for (j = 1; j < sclk_table->count; j++)
> >> {
> >> @@ -1517,8 +1517,6 @@ static int smu7_get_evv_voltages(struct
> pp_hwmgr
> >> *hwmgr)
> >>table_info->vddc_lookup_table,
> >> vv_id, &sclk)) {
> >>if (phm_cap_enabled(hwmgr-
> >>> platform_descriptor.platformCaps,
> >>
> >>PHM_PlatformCaps_ClockStretcher)) {
> >> - if (table_info == NULL)
> >> - return -EINVAL;
> >>sclk_table = table_info-
> >>> vdd_dep_on_sclk;
> >>
> >>for (j = 1; j < sclk_table->count; j++)
> >> {
> >> --
> >> 2.10.2
> >
Enabling peer to peer device transactions for PCIe devices
This is certainly not the first time this has been brought up, but I'd like to try and get some consensus on the best way to move this forward. Allowing devices to talk directly improves performance and reduces latency by avoiding the use of staging buffers in system memory. Also in cases where both devices are behind a switch, it avoids the CPU entirely. Most current APIs (DirectGMA, PeerDirect, CUDA, HSA) that deal with this are pointer based. Ideally we'd be able to take a CPU virtual address and be able to get to a physical address taking into account IOMMUs, etc. Having struct pages for the memory would allow it to work more generally and wouldn't require as much explicit support in drivers that wanted to use it. Some use cases: 1. Storage devices streaming directly to GPU device memory 2. GPU device memory to GPU device memory streaming 3. DVB/V4L/SDI devices streaming directly to GPU device memory 4. DVB/V4L/SDI devices streaming directly to storage devices Here is a relatively simple example of how this could work for testing. This is obviously not a complete solution. - Device memory will be registered with Linux memory sub-system by created corresponding struct page structures for device memory - get_user_pages_fast() will return corresponding struct pages when CPU address points to the device memory - put_page() will deal with struct pages for device memory Previously proposed solutions and related proposals: 1.P2P DMA DMA-API/PCI map_peer_resource support for peer-to-peer (http://www.spinics.net/lists/linux-pci/msg44560.html) Pros: Low impact, already largely reviewed. Cons: requires explicit support in all drivers that want to support it, doesn't handle S/G in device memory. 2. ZONE_DEVICE IO Direct I/O and DMA for persistent memory (https://lwn.net/Articles/672457/) Add support for ZONE_DEVICE IO memory with struct pages. (https://patchwork.kernel.org/patch/8583221/) Pro: Doesn't waste system memory for ZONE metadata Cons: CPU access to ZONE metadata slow, may be lost, corrupted on device reset. 3. DMA-BUF RDMA subsystem DMA-BUF support (http://www.spinics.net/lists/linux-rdma/msg38748.html) Pros: uses existing dma-buf interface Cons: dma-buf is handle based, requires explicit dma-buf support in drivers. 4. iopmem iopmem : A block device for PCIe memory (https://lwn.net/Articles/703895/) 5. HMM Heterogeneous Memory Management (http://lkml.iu.edu/hypermail/linux/kernel/1611.2/02473.html) 6. Some new mmap-like interface that takes a userptr and a length and returns a dma-buf and offset? Alex
[PATCH] drm: Make the connector .detect() callback optional
> -Original Message-
> From: Laurent Pinchart
> [mailto:laurent.pinchart+renesas at ideasonboard.com]
> Sent: Tuesday, November 29, 2016 3:57 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; Koenig, Christian; Alexey Brodkin; Stefan Agner;
> Alison Wang; Patrik Jakobsson; Xinliang Liu; Rongrong Zou; Daniel Vetter;
> Philipp Zabel; CK Hu; Mark Yao; Benjamin Gaignard; Vincent Abriou; Maxime
> Ripard; Jyri Sarha
> Subject: [PATCH] drm: Make the connector .detect() callback optional
>
> Many drivers (21 to be exact) create connectors that are always
> connected (for instance to an LVDS or DSI panel). Instead of forcing
> them to implement a dummy .detect() handler, make the callback optional
> and consider the connector as always connected in that case.
>
> Signed-off-by: Laurent Pinchart
>
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 7 ---
> drivers/gpu/drm/arc/arcpgu_sim.c | 7 ---
> drivers/gpu/drm/ast/ast_mode.c | 7 ---
> drivers/gpu/drm/bochs/bochs_kms.c| 7 ---
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 7 ---
> drivers/gpu/drm/bridge/parade-ps8622.c | 7 ---
> drivers/gpu/drm/bridge/tc358767.c| 7 ---
> drivers/gpu/drm/cirrus/cirrus_mode.c | 7 ---
> drivers/gpu/drm/drm_probe_helper.c | 14 +++---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 7 ---
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 14 --
> drivers/gpu/drm/gma500/psb_intel_lvds.c | 14 --
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 7 ---
> drivers/gpu/drm/i915/intel_dsi.c | 7 ---
> drivers/gpu/drm/imx/imx-ldb.c| 7 ---
> drivers/gpu/drm/imx/imx-tve.c| 7 ---
> drivers/gpu/drm/imx/parallel-display.c | 7 ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 7 ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 7 ---
> drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c| 7 ---
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 7 ---
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c| 7 ---
> drivers/gpu/drm/sti/sti_hda.c| 7 ---
> drivers/gpu/drm/sun4i/sun4i_rgb.c| 7 ---
> drivers/gpu/drm/sun4i/sun4i_tv.c | 7 ---
> drivers/gpu/drm/tilcdc/tilcdc_panel.c| 8
> include/drm/drm_connector.h | 3 +++
> 27 files changed, 14 insertions(+), 193 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> index 81cbf0b05dff..1d93e123532d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> @@ -429,12 +429,6 @@ dce_virtual_dpms(struct drm_connector
> *connector, int mode)
> return 0;
> }
>
> -static enum drm_connector_status
> -dce_virtual_detect(struct drm_connector *connector, bool force)
> -{
> - return connector_status_connected;
> -}
> -
> static int
> dce_virtual_set_property(struct drm_connector *connector,
>struct drm_property *property,
> @@ -463,7 +457,6 @@ static const struct drm_connector_helper_funcs
> dce_virtual_connector_helper_func
>
> static const struct drm_connector_funcs dce_virtual_connector_funcs = {
> .dpms = dce_virtual_dpms,
> - .detect = dce_virtual_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .set_property = dce_virtual_set_property,
> .destroy = dce_virtual_destroy,
> diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c
> b/drivers/gpu/drm/arc/arcpgu_sim.c
> index 2bf06d71556a..bca3a678c955 100644
> --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> @@ -41,12 +41,6 @@ static int arcpgu_drm_connector_get_modes(struct
> drm_connector *connector)
> return count;
> }
>
> -static enum drm_connector_status
> -arcpgu_drm_connector_detect(struct drm_connector *connector, bool
> force)
> -{
> - return connector_status_connected;
> -}
> -
> static void arcpgu_drm_connector_destroy(struct drm_connector
> *connector)
> {
> drm_connector_unregister(connector);
> @@ -61,7 +55,6 @@ arcpgu_drm_connector_helper_funcs = {
> static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
> .dpms = drm_helper_connector_dpms,
> .reset = drm_atomic_helper_connector_reset,
> - .detect = arcpgu_drm_connector_detect,
> .fill_modes = drm_help
RE: [PATCH libdrm] amdgpu: move asic id table to a separate file
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Michel Dänzer
> Sent: Monday, June 12, 2017 5:50 AM
> To: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH libdrm] amdgpu: move asic id table to a separate file
>
> From: Xiaojie Yuan
>
> v2: fix an off by one error and leading white spaces
> v3: use thread safe strtok_r(); initialize len before calling getline();
> change printf() to drmMsg(); add initial amdgpu.ids
> v4: integrate some recent internal changes, including format changes
> v5: fix line number for empty/commented lines; realloc to save memory;
> indentation changes
> v6: remove a line error
> v7: [Michel Dänzer]
> * Move amdgpu.ids to new data directory
> * Remove placeholder entries from amdgpu.ids
> * Set libdrmdatadir variable in configure.ac instead of Makefile.am
> [Emil Velikov]
> * Use isblank() instead of open-coding it [Emil Velikov]
> * Don't leak asic_id_table memory if realloc fails [Emil Velikov]
> * Check and bump table_max_size at the beginning of the while loop [Emil
> Velikov]
> * Initialize table_max_size to the number of entries in data/amdgpu.ids
>
> Reviewed-by: Junwei Zhang
> Signed-off-by: Samuel Li
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> Makefile.am | 1 +
> amdgpu/Makefile.am | 6 ++
> amdgpu/Makefile.sources | 2 +-
> amdgpu/amdgpu_asic_id.c | 219
> +++
> amdgpu/amdgpu_asic_id.h | 165 ---
> amdgpu/amdgpu_device.c | 28 --
> amdgpu/amdgpu_internal.h | 10 +++
> configure.ac | 4 +
> data/Makefile.am | 23 +
> data/amdgpu.ids | 159 ++
> 10 files changed, 444 insertions(+), 173 deletions(-)
> create mode 100644 amdgpu/amdgpu_asic_id.c
> delete mode 100644 amdgpu/amdgpu_asic_id.h
> create mode 100644 data/Makefile.am
> create mode 100644 data/amdgpu.ids
>
> diff --git a/Makefile.am b/Makefile.am
> index dfb8fcdb..7b86214e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -109,6 +109,7 @@ SUBDIRS = \
> $(TEGRA_SUBDIR) \
> $(VC4_SUBDIR) \
> $(ETNAVIV_SUBDIR) \
> + data \
> tests \
> $(MAN_SUBDIR)
>
> diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
> index cf7bc1ba..3444883f 100644
> --- a/amdgpu/Makefile.am
> +++ b/amdgpu/Makefile.am
> @@ -30,6 +30,12 @@ AM_CFLAGS = \
> $(PTHREADSTUBS_CFLAGS) \
> -I$(top_srcdir)/include/drm
>
> +libdrmdatadir = @libdrmdatadir@
> +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,'
> \
> + $(top_srcdir)/data/amdgpu.ids)
> +AM_CPPFLAGS = -
> DAMDGPU_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\" \
> + -
> DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRI
> ES)
> +
> libdrm_amdgpu_la_LTLIBRARIES = libdrm_amdgpu.la
> libdrm_amdgpu_ladir = $(libdir)
> libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:0 -no-undefined
> diff --git a/amdgpu/Makefile.sources b/amdgpu/Makefile.sources
> index 487b9e0a..bc3abaa6 100644
> --- a/amdgpu/Makefile.sources
> +++ b/amdgpu/Makefile.sources
> @@ -1,5 +1,5 @@
> LIBDRM_AMDGPU_FILES := \
> - amdgpu_asic_id.h \
> + amdgpu_asic_id.c \
> amdgpu_bo.c \
> amdgpu_cs.c \
> amdgpu_device.c \
> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c
> new file mode 100644
> index ..3a88896b
> --- /dev/null
> +++ b/amdgpu/amdgpu_asic_id.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright © 2017 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "xf86drm.h"
> +
