[PATCH] drm/amdgpu: Remove volatile from 'wb' & from 'ptr' in amdgpu.h
Christian König
christian.koenig at amd.com
Thu Aug 3 08:42:44 UTC 2023
Am 03.08.23 um 07:23 schrieb SHANMUGAM, SRINIVASAN:
>
>
> On 7/24/2023 10:43 PM, Alex Deucher wrote:
>> On Mon, Jul 24, 2023 at 11:54 AM Srinivasan Shanmugam
>> <srinivasan.shanmugam at amd.com> wrote:
>>> Fixes the following from checkpatch.pl:
>>>
>>> WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
>>> + volatile uint32_t *wb;
>>>
>>> WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
>>> + volatile uint32_t *ptr;
>>>
>>> 'wb' field from 'amdgpu_wb' struct & 'ptr' field from
>>> 'amdgpu_mem_scratch', is not used to access h/w directly, neither they
>>> are shared variables, so volatile is not necessary
>> How did you come to that determination? Both are GPU accessible
>> memory allocations. The writeback (wb) allocation happens to be in
>> GTT so it's system memory, but the the mem_scratch allocation can be
>> in device memory.
>>
>> Alex
>
> Hi Alex,
>
> Thanks for your feedbacks!
>
> Commit message is misleading, I presumed that this volatile modifiers
> are used for monitoring HW status registers due to external events &
> for some shared variables - may be volatile might be needed for *wb
> pointer variable - as they may be used for caches in between (on
> surface level info), can we split this patch into two, I felt volatile
> for *ptr is unnecessary as it is type casted with void type [(void
> **)&adev->mem_scratch.ptr); in amdgpu_device.c]- Any advises onto this
> please?
>
Instead of declaring pointers we should use READ_ONCE()/WRITE_ONCE()
when accessing those values to make sure that the compiler doesn't do
any nasty things.
Regards,
Christian.
> Best regards,
>
> Srini
>
>>> Cc: Christian König<christian.koenig at amd.com>
>>> Cc: Alex Deucher<alexander.deucher at amd.com>
>>> Signed-off-by: Srinivasan Shanmugam<srinivasan.shanmugam at amd.com>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index a046160b6a0e..06f79a84ff4b 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -502,7 +502,7 @@ int amdgpu_file_to_fpriv(struct file *filp, struct amdgpu_fpriv **fpriv);
>>>
>>> struct amdgpu_wb {
>>> struct amdgpu_bo *wb_obj;
>>> - volatile uint32_t *wb;
>>> + u32 *wb;
>>> uint64_t gpu_addr;
>>> u32 num_wb; /* Number of wb slots actually reserved for amdgpu. */
>>> unsigned long used[DIV_ROUND_UP(AMDGPU_MAX_WB, BITS_PER_LONG)];
>>> @@ -621,7 +621,7 @@ int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void *data,
>>> /* VRAM scratch page for HDP bug, default vram page */
>>> struct amdgpu_mem_scratch {
>>> struct amdgpu_bo *robj;
>>> - volatile uint32_t *ptr;
>>> + u32 *ptr;
>>> u64 gpu_addr;
>>> };
>>>
>>> --
>>> 2.25.1
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20230803/bb1b2a56/attachment-0001.htm>
More information about the amd-gfx
mailing list