dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[PATCH] drm/scheduler: quieten kernel-doc warnings
by Randy Dunlap 04 Apr '22

04 Apr '22

Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c. Quashes these warnings: include/drm/gpu_scheduler.h:316: warning: Function parameter or member 'work' not described in 'drm_sched_job' include/drm/gpu_scheduler.h:332: warning: missing initial short description on line: * struct drm_sched_backend_ops include/drm/gpu_scheduler.h:412: warning: missing initial short description on line: * struct drm_gpu_scheduler include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev' not described in 'drm_gpu_scheduler' drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short description on line: * drm_sched_dependency_optimized drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or member 'dev' not described in 'drm_sched_init' Fixes: 2d33948e4e00 ("drm/scheduler: add documentation") Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler") Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes") Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Andrey Grodzovsky <andrey.grodzovsky(a)amd.com> Cc: Nayan Deshmukh <nayan26deshmukh(a)gmail.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Jiawei Gu <Jiawei.Gu(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org --- Feel free to make changes or suggest changes... drivers/gpu/drm/scheduler/sched_main.c | 3 ++- include/drm/gpu_scheduler.h | 10 ++++++---- 2 files changed, 8 insertions(+), 5 deletions(-) --- linux-next-20220401.orig/drivers/gpu/drm/scheduler/sched_main.c +++ linux-next-20220401/drivers/gpu/drm/scheduler/sched_main.c @@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct } /** - * drm_sched_dependency_optimized + * drm_sched_dependency_optimized - test if the dependency can be optimized * * @fence: the dependency fence * @entity: the entity which depends on the above fence @@ -984,6 +984,7 @@ static int drm_sched_main(void *param) * used * @score: optional score atomic shared with other schedulers * @name: name used for debugging + * @dev: target &struct device * * Return 0 on success, otherwise error code. */ --- linux-next-20220401.orig/include/drm/gpu_scheduler.h +++ linux-next-20220401/include/drm/gpu_scheduler.h @@ -270,6 +270,7 @@ struct drm_sched_fence *to_drm_sched_fen * @sched: the scheduler instance on which this job is scheduled. * @s_fence: contains the fences for the scheduling of job. * @finish_cb: the callback for the finished fence. + * @work: scheduler work queue * @id: a unique id assigned to each job scheduled on the scheduler. * @karma: increment on every hang caused by this job. If this exceeds the hang * limit of the scheduler then the job is marked guilty and will not @@ -328,10 +329,10 @@ enum drm_gpu_sched_stat { }; /** - * struct drm_sched_backend_ops + * struct drm_sched_backend_ops - Define the backend operations + * called by the scheduler * - * Define the backend operations called by the scheduler, - * these functions should be implemented in driver side. + * These functions should be implemented in the driver side. */ struct drm_sched_backend_ops { /** @@ -408,7 +409,7 @@ struct drm_sched_backend_ops { }; /** - * struct drm_gpu_scheduler + * struct drm_gpu_scheduler - scheduler instance-specific data * * @ops: backend operations provided by the driver. * @hw_submission_limit: the max size of the hardware queue. @@ -434,6 +435,7 @@ struct drm_sched_backend_ops { * @_score: score used when the driver doesn't provide one * @ready: marks if the underlying HW is ready to work * @free_guilty: A hit to time out handler to free the guilty job. + * @dev: system &struct device * * One scheduler is implemented for each hardware ring. */

3 4

[PATCH] drm/radeon: change si_default_state table from global to static
by Tom Rix 04 Apr '22

04 Apr '22

Smatch reports these issues si_blit_shaders.c:31:11: warning: symbol 'si_default_state' was not declared. Should it be static? si_blit_shaders.c:253:11: warning: symbol 'si_default_size' was not declared. Should it be static? Both symbols are only used in si.c. Single file symbols should be static. So move the si_default_state and si_default_size to si.c and change their storage-class-specifier to static. Remove unneeded si_blit_shaders.[c|h] Signed-off-by: Tom Rix <trix(a)redhat.com> --- drivers/gpu/drm/radeon/Makefile | 2 +- drivers/gpu/drm/radeon/si.c | 224 +++++++++++++++++++- drivers/gpu/drm/radeon/si_blit_shaders.c | 253 ----------------------- drivers/gpu/drm/radeon/si_blit_shaders.h | 32 --- 4 files changed, 224 insertions(+), 287 deletions(-) delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.h diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile index 11c97edde54d..664381f4eb07 100644 --- a/drivers/gpu/drm/radeon/Makefile +++ b/drivers/gpu/drm/radeon/Makefile @@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \ evergreen.o evergreen_cs.o evergreen_blit_shaders.o \ evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \ atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \ - si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \ + radeon_prime.o cik.o cik_blit_shaders.o \ r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \ rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o \ trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \ diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index 8d5e4b25609d..a4032702e302 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -38,7 +38,6 @@ #include "radeon_asic.h" #include "radeon_audio.h" #include "radeon_ucode.h" -#include "si_blit_shaders.h" #include "si.h" #include "sid.h" @@ -3553,6 +3552,229 @@ static int si_cp_load_microcode(struct radeon_device *rdev) return 0; } +static const u32 si_default_state[] = { + 0xc0066900, + 0x00000000, + 0x00000060, /* DB_RENDER_CONTROL */ + 0x00000000, /* DB_COUNT_CONTROL */ + 0x00000000, /* DB_DEPTH_VIEW */ + 0x0000002a, /* DB_RENDER_OVERRIDE */ + 0x00000000, /* DB_RENDER_OVERRIDE2 */ + 0x00000000, /* DB_HTILE_DATA_BASE */ + + 0xc0046900, + 0x00000008, + 0x00000000, /* DB_DEPTH_BOUNDS_MIN */ + 0x00000000, /* DB_DEPTH_BOUNDS_MAX */ + 0x00000000, /* DB_STENCIL_CLEAR */ + 0x00000000, /* DB_DEPTH_CLEAR */ + + 0xc0036900, + 0x0000000f, + 0x00000000, /* DB_DEPTH_INFO */ + 0x00000000, /* DB_Z_INFO */ + 0x00000000, /* DB_STENCIL_INFO */ + + 0xc0016900, + 0x00000080, + 0x00000000, /* PA_SC_WINDOW_OFFSET */ + + 0xc00d6900, + 0x00000083, + 0x0000ffff, /* PA_SC_CLIPRECT_RULE */ + 0x00000000, /* PA_SC_CLIPRECT_0_TL */ + 0x20002000, /* PA_SC_CLIPRECT_0_BR */ + 0x00000000, + 0x20002000, + 0x00000000, + 0x20002000, + 0x00000000, + 0x20002000, + 0xaaaaaaaa, /* PA_SC_EDGERULE */ + 0x00000000, /* PA_SU_HARDWARE_SCREEN_OFFSET */ + 0x0000000f, /* CB_TARGET_MASK */ + 0x0000000f, /* CB_SHADER_MASK */ + + 0xc0226900, + 0x00000094, + 0x80000000, /* PA_SC_VPORT_SCISSOR_0_TL */ + 0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */ + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x80000000, + 0x20002000, + 0x00000000, /* PA_SC_VPORT_ZMIN_0 */ + 0x3f800000, /* PA_SC_VPORT_ZMAX_0 */ + + 0xc0026900, + 0x000000d9, + 0x00000000, /* CP_RINGID */ + 0x00000000, /* CP_VMID */ + + 0xc0046900, + 0x00000100, + 0xffffffff, /* VGT_MAX_VTX_INDX */ + 0x00000000, /* VGT_MIN_VTX_INDX */ + 0x00000000, /* VGT_INDX_OFFSET */ + 0x00000000, /* VGT_MULTI_PRIM_IB_RESET_INDX */ + + 0xc0046900, + 0x00000105, + 0x00000000, /* CB_BLEND_RED */ + 0x00000000, /* CB_BLEND_GREEN */ + 0x00000000, /* CB_BLEND_BLUE */ + 0x00000000, /* CB_BLEND_ALPHA */ + + 0xc0016900, + 0x000001e0, + 0x00000000, /* CB_BLEND0_CONTROL */ + + 0xc00e6900, + 0x00000200, + 0x00000000, /* DB_DEPTH_CONTROL */ + 0x00000000, /* DB_EQAA */ + 0x00cc0010, /* CB_COLOR_CONTROL */ + 0x00000210, /* DB_SHADER_CONTROL */ + 0x00010000, /* PA_CL_CLIP_CNTL */ + 0x00000004, /* PA_SU_SC_MODE_CNTL */ + 0x00000100, /* PA_CL_VTE_CNTL */ + 0x00000000, /* PA_CL_VS_OUT_CNTL */ + 0x00000000, /* PA_CL_NANINF_CNTL */ + 0x00000000, /* PA_SU_LINE_STIPPLE_CNTL */ + 0x00000000, /* PA_SU_LINE_STIPPLE_SCALE */ + 0x00000000, /* PA_SU_PRIM_FILTER_CNTL */ + 0x00000000, /* */ + 0x00000000, /* */ + + 0xc0116900, + 0x00000280, + 0x00000000, /* PA_SU_POINT_SIZE */ + 0x00000000, /* PA_SU_POINT_MINMAX */ + 0x00000008, /* PA_SU_LINE_CNTL */ + 0x00000000, /* PA_SC_LINE_STIPPLE */ + 0x00000000, /* VGT_OUTPUT_PATH_CNTL */ + 0x00000000, /* VGT_HOS_CNTL */ + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, /* VGT_GS_MODE */ + + 0xc0026900, + 0x00000292, + 0x00000000, /* PA_SC_MODE_CNTL_0 */ + 0x00000000, /* PA_SC_MODE_CNTL_1 */ + + 0xc0016900, + 0x000002a1, + 0x00000000, /* VGT_PRIMITIVEID_EN */ + + 0xc0016900, + 0x000002a5, + 0x00000000, /* VGT_MULTI_PRIM_IB_RESET_EN */ + + 0xc0026900, + 0x000002a8, + 0x00000000, /* VGT_INSTANCE_STEP_RATE_0 */ + 0x00000000, + + 0xc0026900, + 0x000002ad, + 0x00000000, /* VGT_REUSE_OFF */ + 0x00000000, + + 0xc0016900, + 0x000002d5, + 0x00000000, /* VGT_SHADER_STAGES_EN */ + + 0xc0016900, + 0x000002dc, + 0x0000aa00, /* DB_ALPHA_TO_MASK */ + + 0xc0066900, + 0x000002de, + 0x00000000, /* PA_SU_POLY_OFFSET_DB_FMT_CNTL */ + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + + 0xc0026900, + 0x000002e5, + 0x00000000, /* VGT_STRMOUT_CONFIG */ + 0x00000000, + + 0xc01b6900, + 0x000002f5, + 0x76543210, /* PA_SC_CENTROID_PRIORITY_0 */ + 0xfedcba98, /* PA_SC_CENTROID_PRIORITY_1 */ + 0x00000000, /* PA_SC_LINE_CNTL */ + 0x00000000, /* PA_SC_AA_CONFIG */ + 0x00000005, /* PA_SU_VTX_CNTL */ + 0x3f800000, /* PA_CL_GB_VERT_CLIP_ADJ */ + 0x3f800000, /* PA_CL_GB_VERT_DISC_ADJ */ + 0x3f800000, /* PA_CL_GB_HORZ_CLIP_ADJ */ + 0x3f800000, /* PA_CL_GB_HORZ_DISC_ADJ */ + 0x00000000, /* PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0 */ + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0x00000000, + 0xffffffff, /* PA_SC_AA_MASK_X0Y0_X1Y0 */ + 0xffffffff, + + 0xc0026900, + 0x00000316, + 0x0000000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */ + 0x00000010, /* */ +}; + +static const u32 si_default_size = ARRAY_SIZE(si_default_state); + static int si_cp_start(struct radeon_device *rdev) { struct radeon_ring *ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX]; diff --git a/drivers/gpu/drm/radeon/si_blit_shaders.c b/drivers/gpu/drm/radeon/si_blit_shaders.c deleted file mode 100644 index ec415e7dfa4b..000000000000 --- a/drivers/gpu/drm/radeon/si_blit_shaders.c +++ /dev/null @@ -1,253 +0,0 @@ -/* - * Copyright 2011 Advanced Micro Devices, Inc. - * - * 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 (including the next - * paragraph) 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) AND/OR ITS SUPPLIERS 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. - * - * Authors: - * Alex Deucher <alexander.deucher(a)amd.com> - */ - -#include <linux/types.h> -#include <linux/bug.h> -#include <linux/kernel.h> - -const u32 si_default_state[] = -{ - 0xc0066900, - 0x00000000, - 0x00000060, /* DB_RENDER_CONTROL */ - 0x00000000, /* DB_COUNT_CONTROL */ - 0x00000000, /* DB_DEPTH_VIEW */ - 0x0000002a, /* DB_RENDER_OVERRIDE */ - 0x00000000, /* DB_RENDER_OVERRIDE2 */ - 0x00000000, /* DB_HTILE_DATA_BASE */ - - 0xc0046900, - 0x00000008, - 0x00000000, /* DB_DEPTH_BOUNDS_MIN */ - 0x00000000, /* DB_DEPTH_BOUNDS_MAX */ - 0x00000000, /* DB_STENCIL_CLEAR */ - 0x00000000, /* DB_DEPTH_CLEAR */ - - 0xc0036900, - 0x0000000f, - 0x00000000, /* DB_DEPTH_INFO */ - 0x00000000, /* DB_Z_INFO */ - 0x00000000, /* DB_STENCIL_INFO */ - - 0xc0016900, - 0x00000080, - 0x00000000, /* PA_SC_WINDOW_OFFSET */ - - 0xc00d6900, - 0x00000083, - 0x0000ffff, /* PA_SC_CLIPRECT_RULE */ - 0x00000000, /* PA_SC_CLIPRECT_0_TL */ - 0x20002000, /* PA_SC_CLIPRECT_0_BR */ - 0x00000000, - 0x20002000, - 0x00000000, - 0x20002000, - 0x00000000, - 0x20002000, - 0xaaaaaaaa, /* PA_SC_EDGERULE */ - 0x00000000, /* PA_SU_HARDWARE_SCREEN_OFFSET */ - 0x0000000f, /* CB_TARGET_MASK */ - 0x0000000f, /* CB_SHADER_MASK */ - - 0xc0226900, - 0x00000094, - 0x80000000, /* PA_SC_VPORT_SCISSOR_0_TL */ - 0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */ - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x80000000, - 0x20002000, - 0x00000000, /* PA_SC_VPORT_ZMIN_0 */ - 0x3f800000, /* PA_SC_VPORT_ZMAX_0 */ - - 0xc0026900, - 0x000000d9, - 0x00000000, /* CP_RINGID */ - 0x00000000, /* CP_VMID */ - - 0xc0046900, - 0x00000100, - 0xffffffff, /* VGT_MAX_VTX_INDX */ - 0x00000000, /* VGT_MIN_VTX_INDX */ - 0x00000000, /* VGT_INDX_OFFSET */ - 0x00000000, /* VGT_MULTI_PRIM_IB_RESET_INDX */ - - 0xc0046900, - 0x00000105, - 0x00000000, /* CB_BLEND_RED */ - 0x00000000, /* CB_BLEND_GREEN */ - 0x00000000, /* CB_BLEND_BLUE */ - 0x00000000, /* CB_BLEND_ALPHA */ - - 0xc0016900, - 0x000001e0, - 0x00000000, /* CB_BLEND0_CONTROL */ - - 0xc00e6900, - 0x00000200, - 0x00000000, /* DB_DEPTH_CONTROL */ - 0x00000000, /* DB_EQAA */ - 0x00cc0010, /* CB_COLOR_CONTROL */ - 0x00000210, /* DB_SHADER_CONTROL */ - 0x00010000, /* PA_CL_CLIP_CNTL */ - 0x00000004, /* PA_SU_SC_MODE_CNTL */ - 0x00000100, /* PA_CL_VTE_CNTL */ - 0x00000000, /* PA_CL_VS_OUT_CNTL */ - 0x00000000, /* PA_CL_NANINF_CNTL */ - 0x00000000, /* PA_SU_LINE_STIPPLE_CNTL */ - 0x00000000, /* PA_SU_LINE_STIPPLE_SCALE */ - 0x00000000, /* PA_SU_PRIM_FILTER_CNTL */ - 0x00000000, /* */ - 0x00000000, /* */ - - 0xc0116900, - 0x00000280, - 0x00000000, /* PA_SU_POINT_SIZE */ - 0x00000000, /* PA_SU_POINT_MINMAX */ - 0x00000008, /* PA_SU_LINE_CNTL */ - 0x00000000, /* PA_SC_LINE_STIPPLE */ - 0x00000000, /* VGT_OUTPUT_PATH_CNTL */ - 0x00000000, /* VGT_HOS_CNTL */ - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, /* VGT_GS_MODE */ - - 0xc0026900, - 0x00000292, - 0x00000000, /* PA_SC_MODE_CNTL_0 */ - 0x00000000, /* PA_SC_MODE_CNTL_1 */ - - 0xc0016900, - 0x000002a1, - 0x00000000, /* VGT_PRIMITIVEID_EN */ - - 0xc0016900, - 0x000002a5, - 0x00000000, /* VGT_MULTI_PRIM_IB_RESET_EN */ - - 0xc0026900, - 0x000002a8, - 0x00000000, /* VGT_INSTANCE_STEP_RATE_0 */ - 0x00000000, - - 0xc0026900, - 0x000002ad, - 0x00000000, /* VGT_REUSE_OFF */ - 0x00000000, - - 0xc0016900, - 0x000002d5, - 0x00000000, /* VGT_SHADER_STAGES_EN */ - - 0xc0016900, - 0x000002dc, - 0x0000aa00, /* DB_ALPHA_TO_MASK */ - - 0xc0066900, - 0x000002de, - 0x00000000, /* PA_SU_POLY_OFFSET_DB_FMT_CNTL */ - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - - 0xc0026900, - 0x000002e5, - 0x00000000, /* VGT_STRMOUT_CONFIG */ - 0x00000000, - - 0xc01b6900, - 0x000002f5, - 0x76543210, /* PA_SC_CENTROID_PRIORITY_0 */ - 0xfedcba98, /* PA_SC_CENTROID_PRIORITY_1 */ - 0x00000000, /* PA_SC_LINE_CNTL */ - 0x00000000, /* PA_SC_AA_CONFIG */ - 0x00000005, /* PA_SU_VTX_CNTL */ - 0x3f800000, /* PA_CL_GB_VERT_CLIP_ADJ */ - 0x3f800000, /* PA_CL_GB_VERT_DISC_ADJ */ - 0x3f800000, /* PA_CL_GB_HORZ_CLIP_ADJ */ - 0x3f800000, /* PA_CL_GB_HORZ_DISC_ADJ */ - 0x00000000, /* PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0 */ - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0x00000000, - 0xffffffff, /* PA_SC_AA_MASK_X0Y0_X1Y0 */ - 0xffffffff, - - 0xc0026900, - 0x00000316, - 0x0000000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */ - 0x00000010, /* */ -}; - -const u32 si_default_size = ARRAY_SIZE(si_default_state); diff --git a/drivers/gpu/drm/radeon/si_blit_shaders.h b/drivers/gpu/drm/radeon/si_blit_shaders.h deleted file mode 100644 index c739e51e3961..000000000000 --- a/drivers/gpu/drm/radeon/si_blit_shaders.h +++ /dev/null @@ -1,32 +0,0 @@ -/* - * Copyright 2011 Advanced Micro Devices, Inc. - * - * 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 (including the next - * paragraph) 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) AND/OR ITS SUPPLIERS 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. - * - */ - -#ifndef SI_BLIT_SHADERS_H -#define SI_BLIT_SHADERS_H - -extern const u32 si_default_state[]; - -extern const u32 si_default_size; - -#endif -- 2.27.0

2 6

[PATCH 3/4] drm/fourcc: Introduce format modifier for DG2 clear color
by Imre Deak 04 Apr '22

04 Apr '22

From: Mika Kahola <mika.kahola(a)intel.com> DG2 clear color render compression uses Tile4 layout. Therefore, we need to define a new format modifier for uAPI to support clear color rendering. v2: Display version is fixed. [Imre] KDoc is enhanced for cc modifier. [Nanley & Lionel] v3: Split out the modifier addition to a separate patch. Clarify the modifier layout description. Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Mika Kahola <mika.kahola(a)intel.com> cc: Anshuman Gupta <anshuman.gupta(a)intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila(a)intel.com> Signed-off-by: Ramalingam C <ramalingam.c(a)intel.com> Signed-off-by: Imre Deak <imre.deak(a)intel.com> Acked-by: Nanley Chery <nanley.g.chery(a)intel.com> --- include/uapi/drm/drm_fourcc.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 4a5117715db3c..e5074162bcdd4 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -605,6 +605,20 @@ extern "C" { */ #define I915_FORMAT_MOD_4_TILED_DG2_MC_CCS fourcc_mod_code(INTEL, 11) +/* + * Intel Color Control Surface with Clear Color (CCS) for DG2 render compression. + * + * The main surface is Tile 4 and at plane index 0. The CCS data is stored + * outside of the GEM object in a reserved memory area dedicated for the + * storage of the CCS data for all RC/RC_CC/MC compressible GEM objects. The + * main surface pitch is required to be a multiple of four Tile 4 widths. The + * clear color is stored at plane index 1 and the pitch should be ignored. The + * format of the 256 bits of clear color data matches the one used for the + * I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC modifier, see its description + * for details. + */ +#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12) + /* * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks * -- 2.30.2

1 0

Re: [PATCH v10 0/3] drivers: ddcci: add drivers for DDCCI
by Hans de Goede 04 Apr '22

04 Apr '22

Hi Yusuf, On 4/4/22 01:08, Yusuf Khan wrote: > This patch adds the DDCCI driver by Christoph Grenz into the kernel. > The original gitlab page is loacted at https://gitlab.com/ddcci-driv > er-linux/ddcci-driver-linux/-/tree/master. > > DDC/CI is a control protocol for monitor settings supported by most > monitors since about 2005. A chardev and sysfs interface is provided. > A backlight driver using DDCCI is also provided in the seccond patch. > > Signed-off-by: Yusuf Khan <yusisamerican(a)gmail.com> > Signed-off-by: Christoph Grenz <christophg+lkml(a)grenz-bonn.de> Thank you for your submission of this patch series. I must say that I'm a bit surprised that this series was NOT also send to the drm/kms subsystem maintainers and mailinglists since this deals with monitors and thus is highly relevant for those folks. Luckily I saw an article about this at Phoronix (you write in the changelog that you believe that there is no interaction with the DRM/KMS subsystems but that is wrong). One very important thing which I'm missing in this cover-letter is why you want to have this in the kernel at all? There are already various tools which do DDCCI from userspace just fine. I guess you may be interested in offering /sys/class/backlight functionality for external monitors. That is actually something which I'm interested in too, but it is not that simple. The current /sys/class/backlight interface does not offer a way for userspace to map a /sys/class/backlight device to a specific display-output / monitor. So userspace currently assumes that there is only 1 (1 valid) /sys/class/backlight device and that that *always* belongs to the internal LCD panel of a laptop. So just adding /sys/class/backlight device(s) for internal monitors without addressing the short-comings of the existing userspace interface is simply not possible because it would break existing userspace which is something which is not allowed. So NACK from me for the backlight part at least and without that, I really see no reason to do this in the kernel rather then userspace. I've recently been discussing this with a colleague of mine, Sebastian Wick and as a result of that I'm giving a talk with a proposal for a better userspace API for this at kernel-recipes: https://kernel-recipes.org/en/2022/talks/new-userspace-api-for-display-pane… I hope to start working on a RFC patch series for this soon. IMHO merging this series should be put on hold until we have a better idea of how we want to solve the userspace API challenges, esp. the monitor <-> /sys/class/backlight mapping problem. Regards, Hans p.s. This is not the first time this has come up: https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b02c6@linux.inte… https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ > --- > v2: Fix typos. > > v3: Add documentation, move files around, replace semaphores with > mutexes, and replaced <asm-generic/fcntl.h> with <linux/fcntl.h>. > "imirkin"(which due to his involvement in the dri-devel irc channel > I cant help but assume to be a DRM developer) said that the DDC/CI > bus does not intefere with the buses that DRM is involved with. > > v4: Move some documentation, fix grammer mistakes, remove usages of > likely(), and clarify some documentation. > > v5: Fix grammer mistakes, remove usages of likely(), and clarify > some documentation. > > v6: Change contact information to reference Christoph Grenz. > > v7: Remove all instances of the unlikely() macro. > > v8: Modify documentation to provide updated date and kernel > documentation, fix SPDX lines, use isalpha instead of redefining > logic, change maximum amount of bytes that can be written to be > conformant with DDC/CI specification, prevent userspace from holding > locks with the open file descriptor, remove ddcci_cdev_seek, dont > refine sysfs_emit() logic, use EXPORT_SYMBOL_GPL instead of > EXPORT_SYMBOL, remove ddcci_device_remove_void, remove module > paramaters and version, and split into 2 patches. > > v9: Fix IS_ANY_ID matching for compilers and archs where char is > unsigned char and use the cannonical patch format. > Reported-by: kernel test robot <lkp(a)intel.com> > > v10: Change patch title to "drivers: ddcci: add drivers for DDCCI > and change" and change patch descriptions to add more detailed > explanations of function. > > Patch 1: Add the main DDCCI component. > > Patch 2: Add the backlight driver that utilizes the DDCCI driver. > > Patch 3: Add documentation for the DDCCI drivers. > > Yusuf Khan (3): > drivers: ddcci: add drivers for DDCCI > drivers: ddcci: add drivers for DDCCI > drivers: ddcci: add drivers for DDCCI > > Documentation/ABI/testing/sysfs-driver-ddcci | 57 + > Documentation/driver-api/ddcci.rst | 122 ++ > drivers/char/Kconfig | 11 + > drivers/char/Makefile | 1 + > drivers/char/ddcci.c | 1805 ++++++++++++++++++ > drivers/video/backlight/Kconfig | 11 + > drivers/video/backlight/Makefile | 1 + > drivers/video/backlight/ddcci-backlight.c | 411 ++++ > include/linux/ddcci.h | 163 ++ > 9 files changed, 2582 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-driver-ddcci > create mode 100644 Documentation/driver-api/ddcci.rst > create mode 100644 drivers/char/ddcci.c > create mode 100644 drivers/video/backlight/ddcci-backlight.c > create mode 100644 include/linux/ddcci.h >

1 0

[PATCH 1/3] drm/etnaviv: add function to create etnaviv platform device
by Sui Jingfeng 04 Apr '22

04 Apr '22

This patch separate the code related to the platform device creation so that it can be reuse by other function. An immediate benefit is we need call of_node_put() only once in the for_each_compatible_node(np, NULL, "vivante,gc") loop instead of three. Signed-off-by: Sui Jingfeng <15330273260(a)189.cn> --- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 47 +++++++++++++++++++-------- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 4 +++ 2 files changed, 37 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c index 0b756ecb1bc2..69d879e623b8 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c @@ -659,10 +659,39 @@ static struct platform_driver etnaviv_platform_driver = { static struct platform_device *etnaviv_drm; -static int __init etnaviv_init(void) +int etnaviv_create_platform_device(const char *name, + const char *data[], + unsigned int num) { struct platform_device *pdev; int ret; + + pdev = platform_device_alloc(name, PLATFORM_DEVID_NONE); + if (!pdev) + return -ENOMEM; + + if (data && num) { + ret = platform_device_add_data(pdev, data, num * sizeof(char *)); + if (ret) { + platform_device_put(pdev); + return ret; + } + } + + ret = platform_device_add(pdev); + if (ret) { + platform_device_put(pdev); + return ret; + } + + etnaviv_drm = pdev; + + return 0; +} + +static int __init etnaviv_init(void) +{ + int ret; struct device_node *np; etnaviv_validate_init(); @@ -683,22 +712,12 @@ static int __init etnaviv_init(void) if (!of_device_is_available(np)) continue; - pdev = platform_device_alloc("etnaviv", PLATFORM_DEVID_NONE); - if (!pdev) { - ret = -ENOMEM; - of_node_put(np); - goto unregister_platform_driver; - } + of_node_put(np); - ret = platform_device_add(pdev); - if (ret) { - platform_device_put(pdev); - of_node_put(np); + ret = etnaviv_create_platform_device("etnaviv", NULL, 0); + if (ret) goto unregister_platform_driver; - } - etnaviv_drm = pdev; - of_node_put(np); break; } diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h b/drivers/gpu/drm/etnaviv/etnaviv_drv.h index f32f4771dada..944001a21ca2 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h @@ -81,6 +81,10 @@ void etnaviv_gem_describe_objects(struct etnaviv_drm_private *priv, struct seq_file *m); #endif +int etnaviv_create_platform_device(const char *name, + const char *data[], + unsigned int num); + #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__) #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt"\n", ##__VA_ARGS__) -- 2.25.1

1 2

[PATCH] drm/bridge: nwl-dsi: Drop the drm_of_panel_bridge_remove() function call
by Liu Ying 04 Apr '22

04 Apr '22

Since this driver has been changed to use the resource managed devm_drm_of_get_bridge() to get bridge from ->attach(), it's unnecessary to call drm_of_panel_bridge_remove() to remove the bridge from ->detach(). So, let's drop the drm_of_panel_bridge_remove() function call. As nwl_dsi_bridge_detach() only calls drm_of_panel_bridge_remove(), it can also be dropped. Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Guido Günther <agx(a)sigxcpu.org> Cc: Jagan Teki <jagan(a)amarulasolutions.com> Cc: NXP Linux Team <linux-imx(a)nxp.com> Signed-off-by: Liu Ying <victor.liu(a)nxp.com> --- drivers/gpu/drm/bridge/nwl-dsi.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c index a549da5b3f93..47859d4506b4 100644 --- a/drivers/gpu/drm/bridge/nwl-dsi.c +++ b/drivers/gpu/drm/bridge/nwl-dsi.c @@ -919,12 +919,6 @@ static int nwl_dsi_bridge_attach(struct drm_bridge *bridge, return drm_bridge_attach(bridge->encoder, panel_bridge, bridge, flags); } -static void nwl_dsi_bridge_detach(struct drm_bridge *bridge) -{ struct nwl_dsi *dsi = bridge_to_dsi(bridge); - - drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0); -} - static u32 *nwl_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge, struct drm_bridge_state *bridge_state, struct drm_crtc_state *crtc_state, @@ -970,7 +964,6 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = { .mode_set = nwl_dsi_bridge_mode_set, .mode_valid = nwl_dsi_bridge_mode_valid, .attach = nwl_dsi_bridge_attach, - .detach = nwl_dsi_bridge_detach, }; static int nwl_dsi_parse_dt(struct nwl_dsi *dsi) -- 2.25.1

3 2

[PATCH] drm: bridge: mcde_dsi: Drop explicit bridge remove
by Jagan Teki 04 Apr '22

04 Apr '22

This driver has been changed to use the resource managed devm_drm_of_get_bridge() to get bridge from ->bind(), it's unnecessary to call drm_of_panel_bridge_remove() to remove the bridge from ->unbind() as devm_drm_of_get_bridge() is automatically remove the bridge when @dev is unbound. Drop it the drm_bridge_remove(). Cc: Linus Walleij <linus.walleij(a)linaro.org> Reported-by: Maxime Ripard <maxime(a)cerno.tech> Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- drivers/gpu/drm/mcde/mcde_dsi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c index 083a4728654d..960b49ea2ee5 100644 --- a/drivers/gpu/drm/mcde/mcde_dsi.c +++ b/drivers/gpu/drm/mcde/mcde_dsi.c @@ -1122,7 +1122,6 @@ static void mcde_dsi_unbind(struct device *dev, struct device *master, { struct mcde_dsi *d = dev_get_drvdata(dev); - drm_bridge_remove(d->bridge_out); regmap_update_bits(d->prcmu, PRCM_DSI_SW_RESET, PRCM_DSI_SW_RESET_DSI0_SW_RESETN, 0); } -- 2.25.1

3 2

Re: [Intel-gfx] Small bar recovery vs compressed content on DG2
by Daniel Vetter 04 Apr '22

04 Apr '22

Maybe also good to add dri-devel to these discussions. I'm not sure where exactly we landed with dgpu error capture (maybe I should check the code but it's really w/e here), but I think we can also toss in "you need a non-recoverable context for error capture to work on dgpu". Since that simplifies things even more. Maybe Thomas forgot to add that to the list of restrictions. Anyway on the "we can't capture lmem-only compressed buffers", I think that's totally fine. Those are for render targets, and we don't capture those. Adding Lionel and Ken to confirm. -Daniel On Fri, 18 Mar 2022 at 17:26, Bloomfield, Jon <jon.bloomfield(a)intel.com> wrote: > > @Thomas Hellström - I agree :-) > > My question was really to @Joonas Lahtinen, who was saying we could always migrate in the CPU fault handler. I am pushing back on that unless we have no choice. It's the very complication we were trying to avoid with the current SAS. If that's what's needed, then so be it. But I'm asking whether we can instead handle this specially, instead of adding generic complexity to the primary code paths. > > Jon > > > -----Original Message----- > > From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > > Sent: Friday, March 18, 2022 2:48 AM > > To: Bloomfield, Jon <jon.bloomfield(a)intel.com>; Joonas Lahtinen > > <joonas.lahtinen(a)linux.intel.com>; Intel Graphics Development <intel- > > gfx(a)lists.freedesktop.org>; Auld, Matthew <matthew.auld(a)intel.com>; C, > > Ramalingam <ramalingam.c(a)intel.com>; Vetter, Daniel > > <daniel.vetter(a)intel.com> > > Subject: Re: Small bar recovery vs compressed content on DG2 > > > > Hi, > > > > On Thu, 2022-03-17 at 18:21 +0000, Bloomfield, Jon wrote: > > > +@Vetter, Daniel > > > > > > Let's not start re-inventing this on the fly again. That's how we got > > > into trouble in the past. The SAS/Whitepaper does currently require > > > the SMEM+LMEM placement for mappable, for good reasons. > > > > Just to avoid any misunderstandings here: > > > > We have two hard requirements from Arch that clash, main problem is > > compressed bos can't be captured on error with current designs. > > > > From an engineering point of view we can do little more than list > > options available to resolve this and whether they are hard or not so > > hard to implemement. But IMHO Arch needs to agree on what's got to > > give. > > > > Thanks, > > Thomas > > > > > > > > > > We cannot 'always migrate to mappable in the fault handler'. Or at > > > least, this is not as trivial as it is to write in a sentence due to > > > the need to spill out other active objects, and all the usual > > > challenges with context synchronization etc. It is possible, perhaps > > > with a lot of care, but it is challenging to guarantee, easy to > > > break, and not needed for 99.9% of software. We are trying to > > > simplify our driver stack. > > > > > > If we need a special mechanism for debug, we should devise a special > > > mechanism, not throw out the general LMEM+SMEM requirement. Are > > there > > > any identified first-class clients that require such access, or is it > > > only debugging tools? > > > > > > If only debug, then why can't the tool use a copy engine submission > > > to access the data in place? Or perhaps a bespoke ioctl to access > > > this via the KMD (and kmd submitted copy-engine BB)? > > > > > > Thanks, > > > > > > Jon > > > > > > > -----Original Message----- > > > > From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > > > > Sent: Thursday, March 17, 2022 2:35 AM > > > > To: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>; Bloomfield, > > > > Jon > > > > <jon.bloomfield(a)intel.com>; Intel Graphics Development <intel- > > > > gfx(a)lists.freedesktop.org>; Auld, Matthew <matthew.auld(a)intel.com>; > > > > C, > > > > Ramalingam <ramalingam.c(a)intel.com> > > > > Subject: Re: Small bar recovery vs compressed content on DG2 > > > > > > > > On Thu, 2022-03-17 at 10:43 +0200, Joonas Lahtinen wrote: > > > > > Quoting Thomas Hellström (2022-03-16 09:25:16) > > > > > > Hi! > > > > > > > > > > > > Do we somehow need to clarify in the headers the semantics for > > > > > > this? > > > > > > > > > > > > From my understanding when discussing the CCS migration series > > > > > > with > > > > > > Ram, the kernel will never do any resolving (compressing / > > > > > > decompressing) migrations or evictions which basically implies > > > > > > the > > > > > > following: > > > > > > > > > > > > *) Compressed data must have LMEM only placement, otherwise the > > > > GPU > > > > > > would read garbage if accessing from SMEM. > > > > > > > > > > This has always been the case, so it should be documented in the > > > > > uAPI > > > > > headers and kerneldocs. > > > > > > > > > > > *) Compressed data can't be assumed to be mappable by the CPU, > > > > > > because > > > > > > in order to ensure that on small BAR, the placement needs to be > > > > > > LMEM+SMEM. > > > > > > > > > > Not strictly true, as we could always migrate to the mappable > > > > > region > > > > > in > > > > > the CPU fault handler. Will need the same set of tricks as with > > > > > limited > > > > > mappable GGTT in past. > > > > > > > > In addition to Matt's reply: > > > > > > > > Yes, if there is sufficient space. I'm not sure we want to > > > > complicate > > > > this to migrate only part of the buffer to mappable on a fault > > > > basis? > > > > Otherwise this is likely to fail. > > > > > > > > One option is to allow cpu-mapping from SYSTEM like TTM is doing > > > > for > > > > evicted buffers, even if SYSTEM is not in the placement list, and > > > > then > > > > migrate back to LMEM for gpu access. > > > > > > > > But can user-space even interpret the compressed data when CPU- > > > > mapping? > > > > without access to the CCS metadata? > > > > > > > > > > > > > > > *) Neither can compressed data be part of a CAPTURE buffer, > > > > > > because > > > > > > that > > > > > > requires the data to be CPU-mappable. > > > > > > > > > > Especially this will be too big of a limitation which we can't > > > > > really > > > > > afford > > > > > when it comes to debugging. > > > > > > > > Same here WRT user-space interpretation. > > > > > > > > This will become especially tricky on small BAR, because either we > > > > need > > > > to fit all compressed buffers in the mappable portion, or be able > > > > to > > > > blit the contents of the capture buffers from within the fence > > > > signalling critical section, which will require a lot of work I > > > > guess. > > > > > > > > /Thomas > > > > > > > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > Are we (and user-mode drivers) OK with these restrictions, or > > > > > > do we > > > > > > need > > > > > > to rethink? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 3

[PATCH v2] drm: drm/drm_file.h: fix a kernel-doc typo
by Randy Dunlap 03 Apr '22

03 Apr '22

Fix a build warning from 'make htmldocs' by correcting the lock name in the kernel-doc comment. include/drm/drm_file.h:369: warning: Function parameter or member 'master_lookup_lock' not described in 'drm_file' Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Reviewed-by: Simon Ser <contact(a)emersion.fr> --- v2: rebase/resend include/drm/drm_file.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20220401.orig/include/drm/drm_file.h +++ linux-next-20220401/include/drm/drm_file.h @@ -248,7 +248,7 @@ struct drm_file { */ struct drm_master *master; - /** @master_lock: Serializes @master. */ + /** @master_lookup_lock: Serializes @master. */ spinlock_t master_lookup_lock; /** @pid: Process that opened this file. */

1 0

RE: [WARNING] [AMDGPU] Linux 5.16.18 warning about ttm_bo_release with R7 360
by Chris Rankin 03 Apr '22

03 Apr '22

Ah yes, here it is: https://lore.kernel.org/lkml/CAK2bqVJo8TZUwu4-5VcY0MEezM7gJJq77prMpCB=FdA24… It looks like this warning started with the 5.14.x kernels. Cheers, Chris

1 0

← Newer
1
...
87
88
89
90
91
92
93
...
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022