[PATCH] gpu/drm/radeon: Fix typo in comments
Alex Deucher
alexdeucher at gmail.com
Fri Jul 30 02:17:37 UTC 2021
Applied. Thanks!
Alex
On Thu, Jul 29, 2021 at 4:21 AM Cai Huoqing <caihuoqing at baidu.com> wrote:
>
> Remove the repeated word 'the' from comments
>
> Signed-off-by: Cai Huoqing <caihuoqing at baidu.com>
> ---
> drivers/gpu/drm/radeon/atombios.h | 4 ++--
> drivers/gpu/drm/radeon/r300_reg.h | 2 +-
> drivers/gpu/drm/radeon/radeon_device.c | 2 +-
> drivers/gpu/drm/radeon/radeon_fence.c | 2 +-
> drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios.h b/drivers/gpu/drm/radeon/atombios.h
> index 4b86e8b45009..83e8b8547f9b 100644
> --- a/drivers/gpu/drm/radeon/atombios.h
> +++ b/drivers/gpu/drm/radeon/atombios.h
> @@ -2802,8 +2802,8 @@ ucMaxNBVoltageHigh: Voltage regulator dependent PWM value. High 8 bits of t
> ucMinNBVoltageHigh: Voltage regulator dependent PWM value. High 8 bits of the value for the min voltage.Set this one to 0x00 if VC without PWM or no VC at all.
>
>
> -usInterNBVoltageLow: Voltage regulator dependent PWM value. The value makes the the voltage >=Min NB voltage but <=InterNBVoltageHigh. Set this to 0x0000 if VC without PWM or no VC at all.
> -usInterNBVoltageHigh: Voltage regulator dependent PWM value. The value makes the the voltage >=InterNBVoltageLow but <=Max NB voltage.Set this to 0x0000 if VC without PWM or no VC at all.
> +usInterNBVoltageLow: Voltage regulator dependent PWM value. The value makes the voltage >=Min NB voltage but <=InterNBVoltageHigh. Set this to 0x0000 if VC without PWM or no VC at all.
> +usInterNBVoltageHigh: Voltage regulator dependent PWM value. The value makes the voltage >=InterNBVoltageLow but <=Max NB voltage.Set this to 0x0000 if VC without PWM or no VC at all.
> */
>
>
> diff --git a/drivers/gpu/drm/radeon/r300_reg.h b/drivers/gpu/drm/radeon/r300_reg.h
> index 00c0d2ba22d3..60d5413bafa1 100644
> --- a/drivers/gpu/drm/radeon/r300_reg.h
> +++ b/drivers/gpu/drm/radeon/r300_reg.h
> @@ -353,7 +353,7 @@
> # define R300_PVS_CNTL_1_PROGRAM_START_SHIFT 0
> # define R300_PVS_CNTL_1_POS_END_SHIFT 10
> # define R300_PVS_CNTL_1_PROGRAM_END_SHIFT 20
> -/* Addresses are relative the the vertex program parameters area. */
> +/* Addresses are relative the vertex program parameters area. */
> #define R300_VAP_PVS_CNTL_2 0x22D4
> # define R300_PVS_CNTL_2_PARAM_OFFSET_SHIFT 0
> # define R300_PVS_CNTL_2_PARAM_COUNT_SHIFT 16
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
> index cec03238e14d..ac8c3251b616 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -406,7 +406,7 @@ void radeon_doorbell_free(struct radeon_device *rdev, u32 doorbell)
>
> /*
> * radeon_wb_*()
> - * Writeback is the the method by which the the GPU updates special pages
> + * Writeback is the method by which the GPU updates special pages
> * in memory with the status of certain GPU events (fences, ring pointers,
> * etc.).
> */
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c
> index 18f2c2e0dfb3..e9c47ec28ade 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -50,7 +50,7 @@
> * for GPU/CPU synchronization. When the fence is written,
> * it is expected that all buffers associated with that fence
> * are no longer in use by the associated ring on the GPU and
> - * that the the relevant GPU caches have been flushed. Whether
> + * that the relevant GPU caches have been flushed. Whether
> * we use a scratch register or memory location depends on the asic
> * and whether writeback is enabled.
> */
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/radeon_vm.c
> index 36a38adaaea9..bb53016f3138 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -41,7 +41,7 @@
> * (uncached system pages).
> * Each VM has an ID associated with it and there is a page table
> * associated with each VMID. When execting a command buffer,
> - * the kernel tells the the ring what VMID to use for that command
> + * the kernel tells the ring what VMID to use for that command
> * buffer. VMIDs are allocated dynamically as commands are submitted.
> * The userspace drivers maintain their own address space and the kernel
> * sets up their pages tables accordingly when they submit their
> --
> 2.25.1
>
More information about the amd-gfx
mailing list