[PATCH 23/40] drm/amd/include/vega20_ip_offset: Mark top-level IP_BASE definition as __maybe_unused
In file included from drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c:27:
drivers/gpu/drm/amd/amdgpu/../include/vega20_ip_offset.h:154:29: warning:
‘XDMA_BASE’ defined but not used [-Wunused-const-variable=
154 | static const struct IP_BASE XDMA_BASE ={ { { { 0x3400, 0, 0, 0, 0, 0
} },
| ^
drivers/gpu/drm/amd/amdgpu/../include/vega20_ip_offset.h:63:29: warning:
‘FUSE_BASE’ defined but not used [-Wunused-const-variable=]
63 | static const struct IP_BASE FUSE_BASE ={ { { { 0x00017400, 0, 0, 0, 0, 0
} },
| ^
Fixes the following W=1 kernel build warning(s):
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/include/vega20_ip_offset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/vega20_ip_offset.h
b/drivers/gpu/drm/amd/include/vega20_ip_offset.h
index 2a2a9cc8bedb6..1deb68f3d3341 100644
--- a/drivers/gpu/drm/amd/include/vega20_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/vega20_ip_offset.h
@@ -33,7 +33,7 @@ struct IP_BASE_INSTANCE
struct IP_BASE
{
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
static const struct IP_BASE ATHUB_BASE={ { { { 0x0C20, 0, 0,
0, 0, 0 } },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/40] drm/msm/disp/dpu1/dpu_hw_catalog: Remove duplicated initialisation of 'max_linewidth'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:124:19: warning: initialized
field overwritten [-Woverride-init]
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:124:19: note: (near
initialization for ‘sm8250_dpu_caps.max_linewidth’)
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 6a6a7172e3beb..a7004f18523b0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -113,7 +113,6 @@ static const struct dpu_caps sm8150_dpu_caps = {
static const struct dpu_caps sm8250_dpu_caps = {
.max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.max_mixer_blendstages = 0xb,
- .max_linewidth = 4096,
.qseed_type = DPU_SSPP_SCALER_QSEED3, /* TODO: qseed3 lite */
.smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
.ubwc_version = DPU_HW_UBWC_VER_40,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/40] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
parameter or member 'init' not described in 'init_reserved'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: Function
parameter or member 'init' not described in 'init_done'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:622: warning: Function
parameter or member 'init' not described in 'init_io_restrict_prog'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:659: warning: Function
parameter or member 'init' not described in 'init_repeat'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:685: warning: Function
parameter or member 'init' not described in 'init_io_restrict_pll'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:725: warning: Function
parameter or member 'init' not described in 'init_end_repeat'
NB: Trimmed for brevity (lots of these!)
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 136 +-
1 file changed, 68 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2a..68e35219cf757 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -575,7 +575,7 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
* init opcode handlers
*/
-/**
+/*
* init_reserved - stub for various unknown/unused single-byte opcodes
*
*/
@@ -602,7 +602,7 @@ init_reserved(struct nvbios_init *init)
init->offset += length;
}
-/**
+/*
* INIT_DONE - opcode 0x71
*
*/
@@ -613,7 +613,7 @@ init_done(struct nvbios_init *init)
init->offset = 0x;
}
-/**
+/*
* INIT_IO_RESTRICT_PROG - opcode 0x32
*
*/
@@ -650,7 +650,7 @@ init_io_restrict_prog(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_REPEAT - opcode 0x33
*
*/
@@ -676,7 +676,7 @@ init_repeat(struct nvbios_init *init)
init->repeat = repeat;
}
-/**
+/*
* INIT_IO_RESTRICT_PLL - opcode 0x34
*
*/
@@ -716,7 +716,7 @@ init_io_restrict_pll(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_END_REPEAT - opcode 0x36
*
*/
@@ -732,7 +732,7 @@ init_end_repeat(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_COPY - opcode 0x37
*
*/
@@ -759,7 +759,7 @@ init_copy(struct nvbios_init *init)
init_wrvgai(init, port, index, data);
}
-/**
+/*
* INIT_NOT - opcode 0x38
*
*/
@@ -771,7 +771,7 @@ init_not(struct nvbios_init *init)
init_exec_inv(init);
}
-/**
+/*
* INIT_IO_FLAG_CONDITION - opcode 0x39
*
*/
@@ -788,7 +788,7 @@ init_io_flag_condition(struct nvbios_init *init)
init_exec_set(init, false);
}
-/**
+/*
* INIT_GENERIC_CONDITION - opcode 0x3a
*
*/
@@ -840,7 +840,7 @@ init_generic_condition(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_IO_MASK_OR - opcode 0x3b
*
*/
@@ -859,7 +859,7 @@ init_io_mask_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
}
-/**
+/*
* INIT_IO_OR - opcode 0x3c
*
*/
@@ -878,7 +878,7 @@ init_io_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data | (1 << or));
}
-/**
+/*
* INIT_ANDN_REG - opcode 0x47
*
*/
@@ -895,7 +895,7 @@ init_andn_reg(struct nvbios_init *init)
init_mask(init, reg, mask, 0);
}
-/**
+/*
* INIT_OR_REG - opcode 0x48
*
*/
@@ -912,7 +912,7 @@ init_or_reg(struct nvbios_init *init)
init_mask(init, reg, 0, mask);
}
-/**
+/*
* INIT_INDEX_ADDRESS_LATCHED - opcode 0x49
*
*/
@@ -942,7 +942,7 @@ init_idx_addr_latched(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_IO_RESTRICT_PLL2 - opcode 0x4a
*
*/
@@ -977,7 +977,7 @@ init_io_restrict_pll2(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_PLL2 - opcode 0x4b
*
*/
@@ -994,7 +994,7 @@ init_pll2(struct nvbios_init *init)
init_prog_pll(init, reg, freq);
}
-/**
+/*
* INIT_I2C_BYTE - opcode 0x4c
*
*/
@@ -1025,7 +1025,7 @@ init_i2c_byte(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_ZM_I2C_BYTE - opcode 0x4d
*
*/
@@ -1051,7 +1051,7 @@ init_zm_i2c_byte(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_ZM_I2C - opcode 0x4e
*
*/
@@ -1085,7 +1085,7 @@ init_zm_i2c(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_TMDS - opcode 0x4f
*
*/
@@ -,7 +,7 @@ init_tmds(struct nvbios_init *init)
init_wr32(init, reg + 0, addr);
}
-/**
+/*
* INIT_ZM_TMDS_GROUP - opcode 0x50
*
*/
@@ -1138,7 +1138,7 @@ init_zm_tmds_group(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_CR_INDEX_ADDRESS_LATCHED - opcode 0x51
*
*/
@@ -1168,7 +1168,7 @@ init_cr_idx_ad
[PATCH 22/40] drm/amd/amdgpu/dce_v6_0: Fix formatting and missing parameter description issues
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:192: warning: Function parameter or member 'async' not described in 'dce_v6_0_page_flip' drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:1050: warning: Cannot understand * Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Luben Tuikov Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c index 9439763493464..83a88385b7620 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c @@ -180,6 +180,7 @@ static void dce_v6_0_pageflip_interrupt_fini(struct amdgpu_device *adev) * @adev: amdgpu_device pointer * @crtc_id: crtc to cleanup pageflip on * @crtc_base: new address of the crtc (GPU MC address) + * @async: asynchronous flip * * Does the actual pageflip (evergreen+). * During vblank we take the crtc lock and wait for the update_pending @@ -1047,7 +1048,6 @@ static u32 dce_v6_0_line_buffer_adjust(struct amdgpu_device *adev, /** - * * dce_v6_0_bandwidth_update - program display watermarks * * @adev: amdgpu_device pointer -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 21/40] drm/amd/amdgpu/uvd_v3_1: Fix-up some documentation issues
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:91: warning: Function parameter or member 'job' not described in 'uvd_v3_1_ring_emit_ib' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:91: warning: Function parameter or member 'flags' not described in 'uvd_v3_1_ring_emit_ib' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:108: warning: Function parameter or member 'addr' not described in 'uvd_v3_1_ring_emit_fence' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:108: warning: Function parameter or member 'seq' not described in 'uvd_v3_1_ring_emit_fence' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:108: warning: Function parameter or member 'flags' not described in 'uvd_v3_1_ring_emit_fence' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:108: warning: Excess function parameter 'fence' description in 'uvd_v3_1_ring_emit_fence' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:625: warning: Function parameter or member 'handle' not described in 'uvd_v3_1_hw_init' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:625: warning: Excess function parameter 'adev' description in 'uvd_v3_1_hw_init' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:692: warning: Function parameter or member 'handle' not described in 'uvd_v3_1_hw_fini' drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:692: warning: Excess function parameter 'adev' description in 'uvd_v3_1_hw_fini' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Sonny Jiang Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c b/drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c index 7cf4b11a65c5c..143ba7a41f41f 100644 --- a/drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c @@ -80,7 +80,9 @@ static void uvd_v3_1_ring_set_wptr(struct amdgpu_ring *ring) * uvd_v3_1_ring_emit_ib - execute indirect buffer * * @ring: amdgpu_ring pointer + * @job: unused * @ib: indirect buffer to execute + * @flags: unused * * Write ring commands to execute the indirect buffer */ @@ -99,7 +101,9 @@ static void uvd_v3_1_ring_emit_ib(struct amdgpu_ring *ring, * uvd_v3_1_ring_emit_fence - emit an fence & trap command * * @ring: amdgpu_ring pointer - * @fence: fence to emit + * @addr: address + * @seq: sequence number + * @flags: fence related flags * * Write a fence and a trap command to the ring. */ @@ -617,7 +621,7 @@ static void uvd_v3_1_enable_mgcg(struct amdgpu_device *adev, /** * uvd_v3_1_hw_init - start and test UVD block * - * @adev: amdgpu_device pointer + * @handle: handle used to pass amdgpu_device pointer * * Initialize the hardware, boot up the VCPU and do some testing */ @@ -684,7 +688,7 @@ static int uvd_v3_1_hw_init(void *handle) /** * uvd_v3_1_hw_fini - stop the hardware block * - * @adev: amdgpu_device pointer + * @handle: handle used to pass amdgpu_device pointer * * Stop the UVD block, mark ring as not ready any more */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 24/40] drm/amd/include/navi10_ip_offset: Mark top-level IP_BASE as __maybe_unused
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/navi10_reg_init.c:27:
drivers/gpu/drm/amd/amdgpu/../include/navi10_ip_offset.h:127:29: warning:
‘UMC_BASE’ defined but not used [-Wunused-const-variable=]
127 | static const struct IP_BASE UMC_BASE ={ { { { 0x00014000, 0, 0, 0, 0, 0
} },
| ^~~~
drivers/gpu/drm/amd/amdgpu/../include/navi10_ip_offset.h:109:29: warning:
‘RSMU_BASE’ defined but not used [-Wunused-const-variable=]
109 | static const struct IP_BASE RSMU_BASE = { { { { 0x00012000, 0, 0, 0, 0,
0 } },
| ^
drivers/gpu/drm/amd/amdgpu/../include/navi10_ip_offset.h:61:29: warning:
‘FUSE_BASE’ defined but not used [-Wunused-const-variable=]
61 | static const struct IP_BASE FUSE_BASE ={ { { { 0x00017400, 0, 0, 0, 0, 0
} },
| ^
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/include/navi10_ip_offset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/navi10_ip_offset.h
b/drivers/gpu/drm/amd/include/navi10_ip_offset.h
index d4a9ddc7782ff..d6824bb6139db 100644
--- a/drivers/gpu/drm/amd/include/navi10_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/navi10_ip_offset.h
@@ -31,7 +31,7 @@ struct IP_BASE_INSTANCE {
struct IP_BASE {
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
static const struct IP_BASE ATHUB_BASE={ { { { 0x0C00, 0, 0,
0, 0, 0 } },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 27/40] drm/amd/include/navi12_ip_offset: Mark top-level IP_BASE as __maybe_unused
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/navi12_reg_init.c:27:
drivers/gpu/drm/amd/amdgpu/../include/navi12_ip_offset.h:179:29: warning:
‘USB0_BASE’ defined but not used [-Wunused-const-variable=]
179 | static const struct IP_BASE USB0_BASE ={ { { { 0x0242A800, 0x05B0,
0, 0, 0 } },
| ^
drivers/gpu/drm/amd/amdgpu/../include/navi12_ip_offset.h:172:29: warning:
‘UMC_BASE’ defined but not used [-Wunused-const-variable=]
172 | static const struct IP_BASE UMC_BASE ={ { { { 0x00014000, 0x02425800, 0,
0, 0 } },
| ^~~~
drivers/gpu/drm/amd/amdgpu/../include/navi12_ip_offset.h:151:29: warning:
‘SDMA_BASE’ defined but not used [-Wunused-const-variable=]
151 | static const struct IP_BASE SDMA_BASE ={ { { { 0x1260, 0xA000,
0x02402C00, 0, 0 } },
| ^
NB: Snipped a few of these
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/include/navi12_ip_offset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/navi12_ip_offset.h
b/drivers/gpu/drm/amd/include/navi12_ip_offset.h
index 6c2cc6296c061..d8fc00478b6a0 100644
--- a/drivers/gpu/drm/amd/include/navi12_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/navi12_ip_offset.h
@@ -33,7 +33,7 @@ struct IP_BASE_INSTANCE
struct IP_BASE
{
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
static const struct IP_BASE ATHUB_BASE ={ { { { 0x0C00, 0x02408C00, 0, 0,
0 } },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 26/40] drm/amd/include/navi14_ip_offset: Mark top-level IP_BASE as __maybe_unused
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/navi14_reg_init.c:27:
drivers/gpu/drm/amd/amdgpu/../include/navi14_ip_offset.h:179:29: warning:
‘USB0_BASE’ defined but not used [-Wunused-const-variable=]
179 | static const struct IP_BASE USB0_BASE ={ { { { 0x0242A800, 0x05B0,
0, 0, 0 } },
| ^
drivers/gpu/drm/amd/amdgpu/../include/navi14_ip_offset.h:172:29: warning:
‘UMC_BASE’ defined but not used [-Wunused-const-variable=]
172 | static const struct IP_BASE UMC_BASE ={ { { { 0x00014000, 0x02425800, 0,
0, 0 } },
| ^~~~
drivers/gpu/drm/amd/amdgpu/../include/navi14_ip_offset.h:151:29: warning:
‘SDMA_BASE’ defined but not used [-Wunused-const-variable=]
151 | static const struct IP_BASE SDMA_BASE ={ { { { 0x1260, 0xA000,
0x02402C00, 0, 0 } },
| ^
NB: Snipped a few of these
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/include/navi14_ip_offset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/navi14_ip_offset.h
b/drivers/gpu/drm/amd/include/navi14_ip_offset.h
index ecdd9eabe0dc8..c39ef651adc6f 100644
--- a/drivers/gpu/drm/amd/include/navi14_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/navi14_ip_offset.h
@@ -33,7 +33,7 @@ struct IP_BASE_INSTANCE
struct IP_BASE
{
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
static const struct IP_BASE ATHUB_BASE ={ { { { 0x0C00, 0x02408C00, 0, 0,
0 } },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 25/40] drm/amd/include/arct_ip_offset: Mark top-level IP_BASE definition as __maybe_unused
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/arct_reg_init.c:27:
drivers/gpu/drm/amd/amdgpu/../include/arct_ip_offset.h:227:29: warning:
‘DBGU_IO_BASE’ defined but not used [-Wunused-const-variable=]
227 | static const struct IP_BASE DBGU_IO_BASE ={ { { { 0x01E0,
0x000125A0, 0x0040B400, 0, 0, 0 } },
| ^~~~
drivers/gpu/drm/amd/amdgpu/../include/arct_ip_offset.h:127:29: warning:
‘PCIE0_BASE’ defined but not used [-Wunused-const-variable=]
127 | static const struct IP_BASE PCIE0_BASE ={ { { { 0x000128C0, 0x00411800,
0x0444, 0, 0, 0 } },
| ^~
In file included from drivers/gpu/drm/amd/amdgpu/arct_reg_init.c:27:
drivers/gpu/drm/amd/amdgpu/../include/arct_ip_offset.h:63:29: warning:
‘FUSE_BASE’ defined but not used [-Wunused-const-variable=]
63 | static const struct IP_BASE FUSE_BASE ={ { { { 0x000120A0, 0x00017400,
0x00401400, 0, 0, 0 } },
| ^
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/include/arct_ip_offset.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/include/arct_ip_offset.h
b/drivers/gpu/drm/amd/include/arct_ip_offset.h
index a7791a9e1f905..af1c46991429b 100644
--- a/drivers/gpu/drm/amd/include/arct_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/arct_ip_offset.h
@@ -28,12 +28,12 @@
struct IP_BASE_INSTANCE
{
unsigned int segment[MAX_SEGMENT];
-};
+} __maybe_unused;
struct IP_BASE
{
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
static const struct IP_BASE ATHUB_BASE={ { { { 0x0C20,
0x00012460, 0x00408C00, 0, 0, 0 } },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/40] drm/amd/amdgpu/amdgpu_virt: Correct possible copy/paste or doc-rot misnaming issue
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:115: warning: Function parameter or member 'adev' not described in 'amdgpu_virt_request_full_gpu' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:115: warning: Excess function parameter 'amdgpu' description in 'amdgpu_virt_request_full_gpu' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:138: warning: Function parameter or member 'adev' not described in 'amdgpu_virt_release_full_gpu' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:138: warning: Excess function parameter 'amdgpu' description in 'amdgpu_virt_release_full_gpu' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:159: warning: Function parameter or member 'adev' not described in 'amdgpu_virt_reset_gpu' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:159: warning: Excess function parameter 'amdgpu' description in 'amdgpu_virt_reset_gpu' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:194: warning: Function parameter or member 'adev' not described in 'amdgpu_virt_wait_reset' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:194: warning: Excess function parameter 'amdgpu' description in 'amdgpu_virt_wait_reset' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:210: warning: Function parameter or member 'adev' not described in 'amdgpu_virt_alloc_mm_table' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:210: warning: Excess function parameter 'amdgpu' description in 'amdgpu_virt_alloc_mm_table' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:239: warning: Function parameter or member 'adev' not described in 'amdgpu_virt_free_mm_table' drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:239: warning: Excess function parameter 'amdgpu' description in 'amdgpu_virt_free_mm_table' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c index 905b85391e64a..462c5dd8ca72c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c @@ -106,7 +106,7 @@ void amdgpu_virt_kiq_reg_write_reg_wait(struct amdgpu_device *adev, /** * amdgpu_virt_request_full_gpu() - request full gpu access - * @amdgpu:amdgpu device. + * @adev: amdgpu device. * @init: is driver init time. * When start to init/fini driver, first need to request full gpu access. * Return: Zero if request success, otherwise will return error. @@ -129,7 +129,7 @@ int amdgpu_virt_request_full_gpu(struct amdgpu_device *adev, bool init) /** * amdgpu_virt_release_full_gpu() - release full gpu access - * @amdgpu:amdgpu device. + * @adev: amdgpu device. * @init: is driver init time. * When finishing driver init/fini, need to release full gpu access. * Return: Zero if release success, otherwise will returen error. @@ -151,7 +151,7 @@ int amdgpu_virt_release_full_gpu(struct amdgpu_device *adev, bool init) /** * amdgpu_virt_reset_gpu() - reset gpu - * @amdgpu:amdgpu device. + * @adev: amdgpu device. * Send reset command to GPU hypervisor to reset GPU that VM is using * Return: Zero if reset success, otherwise will return error. */ @@ -186,7 +186,7 @@ void amdgpu_virt_request_init_data(struct amdgpu_device *adev) /** * amdgpu_virt_wait_reset() - wait for reset gpu completed - * @amdgpu:amdgpu device. + * @adev: amdgpu device. * Wait for GPU reset completed. * Return: Zero if reset success, otherwise will return error. */ @@ -202,7 +202,7 @@ int amdgpu_virt_wait_reset(struct amdgpu_device *adev) /** * amdgpu_virt_alloc_mm_table() - alloc memory for mm table - * @amdgpu:amdgpu device. + * @adev: amdgpu device. * MM table is used by UVD and VCE for its initialization * Return: Zero if allocate success. */ @@ -232,7 +232,7 @@ int amdgpu_virt_alloc_mm_table(struct amdgpu_device *adev) /** * amdgpu_virt_free_mm_table() - free mm table memory - * @amdgpu:amdgpu device. + * @adev: amdgpu device. * Free MM table memory */ void amdgpu_virt_free_mm_table(struct amdgpu_device *adev) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/40] drm/msm/disp/dpu1/dpu_hw_sspp: Fix kernel-doc formatting abuse
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function parameter or member 'ctx' not described in 'dpu_hw_sspp_setup_format' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function parameter or member 'fmt' not described in 'dpu_hw_sspp_setup_format' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function parameter or member 'flags' not described in 'dpu_hw_sspp_setup_format' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function parameter or member 'rect_mode' not described in 'dpu_hw_sspp_setup_format' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:446: warning: Function parameter or member 'ctx' not described in 'dpu_hw_sspp_setup_rects' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:446: warning: Function parameter or member 'cfg' not described in 'dpu_hw_sspp_setup_rects' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:446: warning: Function parameter or member 'rect_index' not described in 'dpu_hw_sspp_setup_rects' Cc: Rob Clark Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Jonathan Marek Cc: linux-arm-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c index c940b69435e16..2c2ca5335aa8c 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c @@ -231,7 +231,7 @@ static void _sspp_setup_csc10_opmode(struct dpu_hw_pipe *ctx, DPU_REG_WRITE(&ctx->hw, SSPP_VIG_CSC_10_OP_MODE + idx, opmode); } -/** +/* * Setup source pixel format, flip, */ static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe *ctx, @@ -437,7 +437,7 @@ static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_pipe *ctx) return dpu_hw_get_scaler3_ver(&ctx->hw, idx); } -/** +/* * dpu_hw_sspp_setup_rects() */ static void dpu_hw_sspp_setup_rects(struct dpu_hw_pipe *ctx, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 31/40] drm/msm/disp/dpu1/dpu_rm: Fix formatting issues and supply 'global_state' description
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c:247: warning: Excess function parameter 'Return' description in '_dpu_rm_check_lm_peer' drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c:283: warning: Function parameter or member 'global_state' not described in '_dpu_rm_check_lm_and_get_connected_blks' drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c:283: warning: Excess function parameter 'Return' description in '_dpu_rm_check_lm_and_get_connected_blks' Cc: Rob Clark Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Drew Davenport Cc: linux-arm-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c index 0ae8a36ffcff3..fd2d104f0a91d 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c @@ -239,7 +239,7 @@ static bool _dpu_rm_needs_split_display(const struct msm_display_topology *top) * @rm: dpu resource manager handle * @primary_idx: index of primary mixer in rm->mixer_blks[] * @peer_idx: index of other mixer in rm->mixer_blks[] - * @Return: true if rm->mixer_blks[peer_idx] is a peer of + * Return: true if rm->mixer_blks[peer_idx] is a peer of * rm->mixer_blks[primary_idx] */ static bool _dpu_rm_check_lm_peer(struct dpu_rm *rm, int primary_idx, @@ -264,6 +264,7 @@ static bool _dpu_rm_check_lm_peer(struct dpu_rm *rm, int primary_idx, * proposed use case requirements, incl. hardwired dependent blocks like * pingpong * @rm: dpu resource manager handle + * @global_state: resources shared across multiple kms objects * @enc_id: encoder id requesting for allocation * @lm_idx: index of proposed layer mixer in rm->mixer_blks[], function checks * if lm, and all other hardwired blocks connected to the lm (pp) is @@ -274,7 +275,7 @@ static bool _dpu_rm_check_lm_peer(struct dpu_rm *rm, int primary_idx, * mixer in rm->dspp_blks[]. * @reqs: input parameter, rm requirements for HW blocks needed in the * datapath. - * @Return: true if lm matches all requirements, false otherwise + * Return: true if lm matches all requirements, false otherwise */ static bool _dpu_rm_check_lm_and_get_connected_blks(struct dpu_rm *rm, struct dpu_global_state *global_state, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 29/40] drm/amd/include/vangogh_ip_offset: Mark top-level IP_BASE as __maybe_unused
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/vangogh_reg_init.c:28:
drivers/gpu/drm/amd/amdgpu/../include/vangogh_ip_offset.h:210:29: warning:
‘USB_BASE’ defined but not used [-Wunused-const-variable=]
210 | static const struct IP_BASE USB_BASE = { { { { 0x0242A800, 0x05B0,
0, 0, 0, 0 } },
| ^~~~
drivers/gpu/drm/amd/amdgpu/../include/vangogh_ip_offset.h:202:29: warning:
‘UMC_BASE’ defined but not used [-Wunused-const-variable=]
202 | static const struct IP_BASE UMC_BASE = { { { { 0x00014000, 0x02425800,
0, 0, 0, 0 } },
| ^~~~
drivers/gpu/drm/amd/amdgpu/../include/vangogh_ip_offset.h:178:29: warning:
‘PCIE0_BASE’ defined but not used [-Wunused-const-variable=]
178 | static const struct IP_BASE PCIE0_BASE = { { { { 0x, 0x0014,
0x0D20, 0x00010400, 0x0241B000, 0x0404 } },
| ^~
drivers/gpu/drm/amd/amdgpu/../include/vangogh_ip_offset.h:154:29: warning:
‘MP2_BASE’ defined but not used [-Wunused-const-variable=]
154 | static const struct IP_BASE MP2_BASE = { { { { 0x00016400, 0x02400800,
0x00F4, 0x00F8, 0x00FC, 0 } },
| ^~~~
NB: Snipped lots of these
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Huang Rui
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/include/vangogh_ip_offset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/vangogh_ip_offset.h
b/drivers/gpu/drm/amd/include/vangogh_ip_offset.h
index 2875574b060e6..691073ed780ec 100644
--- a/drivers/gpu/drm/amd/include/vangogh_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/vangogh_ip_offset.h
@@ -36,7 +36,7 @@ struct IP_BASE_INSTANCE
struct IP_BASE
{
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
static const struct IP_BASE ACP_BASE = { { { { 0x02403800, 0x0048, 0, 0,
0, 0 } },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 33/40] drm/amd/amdgpu/cik_sdma: Add one and remove another function param description
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/cik_sdma.c:282: warning: Function parameter or
member 'flags' not described in 'cik_sdma_ring_emit_fence'
drivers/gpu/drm/amd/amdgpu/cik_sdma.c:282: warning: Excess function parameter
'fence' description in 'cik_sdma_ring_emit_fence'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
index f1e9966e7244e..28a64de8ae0e6 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
@@ -271,7 +271,7 @@ static void cik_sdma_ring_emit_hdp_flush(struct amdgpu_ring
*ring)
* @ring: amdgpu ring pointer
* @addr: address
* @seq: sequence number
- * @fence: amdgpu fence object
+ * @flags: fence related flags
*
* Add a DMA fence packet to the ring to write
* the fence seq number and DMA trap packet to generate
@@ -279,7 +279,7 @@ static void cik_sdma_ring_emit_hdp_flush(struct amdgpu_ring
*ring)
*/
static void cik_sdma_ring_emit_fence(struct amdgpu_ring *ring, u64 addr, u64
seq,
unsigned flags)
-{
+ {
bool write64bit = flags & AMDGPU_FENCE_FLAG_64BIT;
/* write the fence */
amdgpu_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_FENCE, 0, 0));
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 28/40] drm/amd/include/sienna_cichlid_ip_offset: Mark top-level IP_BASE as __maybe_unused
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/sienna_cichlid_reg_init.c:28:
drivers/gpu/drm/amd/amdgpu/../include/sienna_cichlid_ip_offset.h:186:29:
warning: ‘USB0_BASE’ defined but not used [-Wunused-const-variable=]
186 | static const struct IP_BASE USB0_BASE = { { { { 0x0242A800, 0x05B0,
0, 0, 0 } },
| ^
drivers/gpu/drm/amd/amdgpu/../include/sienna_cichlid_ip_offset.h:179:29:
warning: ‘UMC_BASE’ defined but not used [-Wunused-const-variable=]
179 | static const struct IP_BASE UMC_BASE = { { { { 0x00014000, 0x02425800,
0, 0, 0 } },
| ^~~~
drivers/gpu/drm/amd/amdgpu/../include/sienna_cichlid_ip_offset.h:158:29:
warning: ‘SDMA1_BASE’ defined but not used [-Wunused-const-variable=]
158 | static const struct IP_BASE SDMA1_BASE = { { { { 0x1260, 0xA000,
0x0001C000, 0x02402C00, 0 } },
| ^~
NB: Snipped lots of these
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Hawking Zhang
Cc: Likun Gao
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/include/sienna_cichlid_ip_offset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/sienna_cichlid_ip_offset.h
b/drivers/gpu/drm/amd/include/sienna_cichlid_ip_offset.h
index 06800c6fa0495..b07bc2dd895dc 100644
--- a/drivers/gpu/drm/amd/include/sienna_cichlid_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/sienna_cichlid_ip_offset.h
@@ -33,7 +33,7 @@ struct IP_BASE_INSTANCE
struct IP_BASE
{
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
static const struct IP_BASE ATHUB_BASE = { { { { 0x0C00, 0x02408C00, 0, 0,
0 } },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 32/40] drm/msm/disp/dpu1/dpu_vbif: Fix a couple of function param descriptions
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c:150: warning: Function parameter or member 'dpu_kms' not described in 'dpu_vbif_set_ot_limit' drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c:150: warning: Excess function parameter 'vbif' description in 'dpu_vbif_set_ot_limit' Cc: Rob Clark Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: linux-arm-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c index 5e8c3f3e66256..7e08f40e7e6fe 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c @@ -140,7 +140,7 @@ static u32 _dpu_vbif_get_ot_limit(struct dpu_hw_vbif *vbif, /** * dpu_vbif_set_ot_limit - set OT based on usecase & configuration parameters - * @vbif: Pointer to hardware vbif driver + * @dpu_kms: DPU handler * @params:Pointer to usecase parameters * * Note this function would block waiting for bus halt. -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 30/40] drm/amd/include/dimgrey_cavefish_ip_offset: Mark top-level IP_BASE as __maybe_unused
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/dimgrey_cavefish_reg_init.c:28:
drivers/gpu/drm/amd/amdgpu/../include/dimgrey_cavefish_ip_offset.h:151:29:
warning: ‘UMC_BASE’ defined but not used [-Wunused-const-variable=]
151 | static const struct IP_BASE UMC_BASE = { { { { 0x00014000, 0x02425800, 0,
0, 0, 0 } },
| ^~~~
drivers/gpu/drm/amd/amdgpu/../include/dimgrey_cavefish_ip_offset.h:81:29:
warning: ‘FUSE_BASE’ defined but not used [-Wunused-const-variable=]
81 | static const struct IP_BASE FUSE_BASE = { { { { 0x00017400, 0x02401400, 0,
0, 0, 0 } },
| ^
drivers/gpu/drm/amd/amdgpu/../include/dimgrey_cavefish_ip_offset.h:74:29:
warning: ‘DPCS_BASE’ defined but not used [-Wunused-const-variable=]
74 | static const struct IP_BASE DPCS_BASE = { { { { 0x0012, 0x00C0,
0x34C0, 0x9000, 0x02403C00, 0 } },
| ^
NB: Snipped lots of these
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Tao Zhou
Cc: Hawking Zhang
Cc: Jiansong Chen
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/include/dimgrey_cavefish_ip_offset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/dimgrey_cavefish_ip_offset.h
b/drivers/gpu/drm/amd/include/dimgrey_cavefish_ip_offset.h
index b41263de8a9b6..f84996a73de94 100644
--- a/drivers/gpu/drm/amd/include/dimgrey_cavefish_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/dimgrey_cavefish_ip_offset.h
@@ -33,7 +33,7 @@ struct IP_BASE_INSTANCE
struct IP_BASE
{
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
static const struct IP_BASE ATHUB_BASE = { { { { 0x0C00, 0x02408C00, 0, 0,
0, 0 } },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 34/40] drm/amd/amdgpu/uvd_v4_2: Add one and remove another function param description
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:448: warning: Function parameter or member 'flags' not described in 'uvd_v4_2_ring_emit_fence' drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:448: warning: Excess function parameter 'fence' description in 'uvd_v4_2_ring_emit_fence' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c b/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c index 2c8c35c3bca52..bf3d1c63739b8 100644 --- a/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c @@ -439,7 +439,7 @@ static void uvd_v4_2_stop(struct amdgpu_device *adev) * @ring: amdgpu_ring pointer * @addr: address * @seq: sequence number - * @fence: fence to emit + * @flags: fence related flags * * Write a fence and a trap command to the ring. */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 39/40] drm/amd/amdgpu/gmc_v9_0: Remove unused table 'ecc_umc_mcumc_status_addrs'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:382:23: warning:
‘ecc_umc_mcumc_status_addrs’ defined but not used [-Wunused-const-variable=]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 0c3421d587e87..fbee43b4ba64d 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -379,41 +379,6 @@ static const uint32_t ecc_umc_mcumc_ctrl_mask_addrs[] = {
(0x001d43e0 + 0x1800),
};
-static const uint32_t ecc_umc_mcumc_status_addrs[] = {
- (0x000143c2 + 0x),
- (0x000143c2 + 0x0800),
- (0x000143c2 + 0x1000),
- (0x000143c2 + 0x1800),
- (0x000543c2 + 0x),
- (0x000543c2 + 0x0800),
- (0x000543c2 + 0x1000),
- (0x000543c2 + 0x1800),
- (0x000943c2 + 0x),
- (0x000943c2 + 0x0800),
- (0x000943c2 + 0x1000),
- (0x000943c2 + 0x1800),
- (0x000d43c2 + 0x),
- (0x000d43c2 + 0x0800),
- (0x000d43c2 + 0x1000),
- (0x000d43c2 + 0x1800),
- (0x001143c2 + 0x),
- (0x001143c2 + 0x0800),
- (0x001143c2 + 0x1000),
- (0x001143c2 + 0x1800),
- (0x001543c2 + 0x),
- (0x001543c2 + 0x0800),
- (0x001543c2 + 0x1000),
- (0x001543c2 + 0x1800),
- (0x001943c2 + 0x),
- (0x001943c2 + 0x0800),
- (0x001943c2 + 0x1000),
- (0x001943c2 + 0x1800),
- (0x001d43c2 + 0x),
- (0x001d43c2 + 0x0800),
- (0x001d43c2 + 0x1000),
- (0x001d43c2 + 0x1800),
-};
-
static int gmc_v9_0_ecc_interrupt_state(struct amdgpu_device *adev,
struct amdgpu_irq_src *src,
unsigned type,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 36/40] drm/amd/amdgpu/gmc_v7_0: Add some missing kernel-doc descriptions
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:433: warning: Function parameter or member 'flush_type' not described in 'gmc_v7_0_flush_gpu_tlb_pasid' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:433: warning: Function parameter or member 'all_hub' not described in 'gmc_v7_0_flush_gpu_tlb_pasid' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:471: warning: Function parameter or member 'vmhub' not described in 'gmc_v7_0_flush_gpu_tlb' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:471: warning: Function parameter or member 'flush_type' not described in 'gmc_v7_0_flush_gpu_tlb' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:771: warning: Function parameter or member 'pasid' not described in 'gmc_v7_0_vm_decode_fault' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c index 80c146df338aa..fe71c89ecd26f 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c @@ -424,6 +424,8 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev) * * @adev: amdgpu_device pointer * @pasid: pasid to be flush + * @flush_type: unused + * @all_hub: unused * * Flush the TLB for the requested pasid. */ @@ -463,7 +465,9 @@ static int gmc_v7_0_flush_gpu_tlb_pasid(struct amdgpu_device *adev, * * @adev: amdgpu_device pointer * @vmid: vm instance to flush - * + * @vmhub: unused + * @flush_type: unused + * * * Flush the TLB for the requested page table (CIK). */ static void gmc_v7_0_flush_gpu_tlb(struct amdgpu_device *adev, uint32_t vmid, @@ -763,6 +767,7 @@ static void gmc_v7_0_gart_disable(struct amdgpu_device *adev) * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value * @mc_client: VM_CONTEXT1_PROTECTION_FAULT_MCCLIENT register value + * @pasid: debug logging only - no functional use * * Print human readable fault information (CIK). */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 40/40] drm/amd/amdgpu/gmc_v9_0: Suppy some missing function doc descriptions
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:382:23: warning: ‘ecc_umc_mcumc_status_addrs’ defined but not used [-Wunused-const-variable=] drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:720: warning: Function parameter or member 'vmhub' not described in 'gmc_v9_0_flush_gpu_tlb' drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:836: warning: Function parameter or member 'flush_type' not described in 'gmc_v9_0_flush_gpu_tlb_pasid' drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:836: warning: Function parameter or member 'all_hub' not described in 'gmc_v9_0_flush_gpu_tlb_pasid' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c index fbee43b4ba64d..a83743ab3e8bb 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c @@ -675,6 +675,7 @@ static bool gmc_v9_0_get_atc_vmid_pasid_mapping_info(struct amdgpu_device *adev, * * @adev: amdgpu_device pointer * @vmid: vm instance to flush + * @vmhub: vmhub type * @flush_type: the flush type * * Flush the TLB for the requested page table using certain type. @@ -791,6 +792,8 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev, uint32_t vmid, * * @adev: amdgpu_device pointer * @pasid: pasid to be flush + * @flush_type: the flush type + * @all_hub: Used with PACKET3_INVALIDATE_TLBS_ALL_HUB() * * Flush the TLB for the requested pasid. */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 35/40] drm/msm/disp/dpu1/dpu_plane: Fix some spelling and missing function param descriptions
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:152: warning: Function parameter or
member 'plane' not described in '_dpu_plane_calc_bw'
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:152: warning: Function parameter or
member 'fb' not described in '_dpu_plane_calc_bw'
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:152: warning: Excess function
parameter 'Plane' description in '_dpu_plane_calc_bw'
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:200: warning: Function parameter or
member 'plane' not described in '_dpu_plane_calc_clk'
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:200: warning: Excess function
parameter 'Plane' description in '_dpu_plane_calc_clk'
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:232: warning: Function parameter or
member 'src_width' not described in '_dpu_plane_calc_fill_level'
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:232: warning: Excess function
parameter 'src_wdith' description in '_dpu_plane_calc_fill_level'
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1060: warning: Function parameter or
member 'error' not described in 'dpu_plane_set_error'
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Kalyan Thota
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c0b1d77369e53..cf0084d7cc7c9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -142,7 +142,8 @@ static struct dpu_kms *_dpu_plane_get_kms(struct drm_plane
*plane)
/**
* _dpu_plane_calc_bw - calculate bandwidth required for a plane
- * @Plane: Pointer to drm plane.
+ * @plane: Pointer to drm plane.
+ * @fb: Pointer to framebuffer associated with the given plane
* Result: Updates calculated bandwidth in the plane state.
* BW Equation: src_w * src_h * bpp * fps * (v_total / v_dest)
* Prefill BW Equation: line src bytes * line_time
@@ -192,7 +193,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
/**
* _dpu_plane_calc_clk - calculate clock required for a plane
- * @Plane: Pointer to drm plane.
+ * @plane: Pointer to drm plane.
* Result: Updates calculated clock in the plane state.
* Clock equation: dst_w * v_total * fps * (src_h / dst_h)
*/
@@ -224,7 +225,7 @@ static void _dpu_plane_calc_clk(struct drm_plane *plane)
* _dpu_plane_calc_fill_level - calculate fill level of the given source format
* @plane: Pointer to drm plane
* @fmt: Pointer to source buffer format
- * @src_wdith: width of source buffer
+ * @src_width: width of source buffer
* Return: fill level corresponding to the source buffer/format or 0 if error
*/
static int _dpu_plane_calc_fill_level(struct drm_plane *plane,
@@ -1055,6 +1056,7 @@ void dpu_plane_flush(struct drm_plane *plane)
/**
* dpu_plane_set_error: enable/disable error condition
* @plane: pointer to drm_plane structure
+ * @error: error value to set
*/
void dpu_plane_set_error(struct drm_plane *plane, bool error)
{
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 37/40] drm/amd/amdgpu/gmc_v8_0: Fix more issues attributed to copy/paste
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:618: warning: Function parameter or member 'flush_type' not described in 'gmc_v8_0_flush_gpu_tlb_pasid' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:618: warning: Function parameter or member 'all_hub' not described in 'gmc_v8_0_flush_gpu_tlb_pasid' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:657: warning: Function parameter or member 'vmhub' not described in 'gmc_v8_0_flush_gpu_tlb' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:657: warning: Function parameter or member 'flush_type' not described in 'gmc_v8_0_flush_gpu_tlb' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:998: warning: Function parameter or member 'pasid' not described in 'gmc_v8_0_vm_decode_fault' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c index 0f32a8002c3d7..41c1d8e812b88 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c @@ -609,6 +609,8 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev) * * @adev: amdgpu_device pointer * @pasid: pasid to be flush + * @flush_type: unused + * @all_hub: unused * * Flush the TLB for the requested pasid. */ @@ -649,6 +651,8 @@ static int gmc_v8_0_flush_gpu_tlb_pasid(struct amdgpu_device *adev, * * @adev: amdgpu_device pointer * @vmid: vm instance to flush + * @vmhub: unused + * @flush_type: unused * * Flush the TLB for the requested page table (VI). */ @@ -990,6 +994,7 @@ static void gmc_v8_0_gart_disable(struct amdgpu_device *adev) * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value * @mc_client: VM_CONTEXT1_PROTECTION_FAULT_MCCLIENT register value + * @pasid: debug logging only - no functional use * * Print human readable fault information (VI). */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 38/40] drm/msm/msm_drv: Make '_msm_ioremap()' static
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/msm_drv.c:124:15: warning: no previous prototype for
‘_msm_ioremap’ [-Wmissing-prototypes]
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 4d58668b80853..edc99e3b0eca7 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -121,8 +121,8 @@ struct clk *msm_clk_get(struct platform_device *pdev, const
char *name)
return clk;
}
-void __iomem *_msm_ioremap(struct platform_device *pdev, const char *name,
- const char *dbgname, bool quiet)
+static void __iomem *_msm_ioremap(struct platform_device *pdev, const char
*name,
+ const char *dbgname, bool quiet)
{
struct resource *res;
unsigned long size;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/40] [Set 8] Rid W=1 warnings from GPU
Only skimmed over them, but over all looks sane to me.
Series is Acked-by: Christian König
Thanks,
Christian.
Am 23.11.20 um 12:18 schrieb Lee Jones:
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Only 900 (from 5000) to go!
Lee Jones (40):
drm/radeon/radeon_device: Consume our own header where the prototypes
are located
drm/amd/amdgpu/amdgpu_ttm: Add description for 'page_flags'
drm/amd/amdgpu/amdgpu_ib: Provide docs for 'amdgpu_ib_schedule()'s
'job' param
drm/amd/amdgpu/amdgpu_virt: Correct possible copy/paste or doc-rot
misnaming issue
drm/amd/amdgpu/cik_ih: Supply description for 'ih' in
'cik_ih_{get,set}_wptr()'
drm/amd/amdgpu/uvd_v4_2: Fix some kernel-doc misdemeanours
drm/amd/amdgpu/dce_v8_0: Supply description for 'async'
drm/amd/amdgpu/cik_sdma: Supply some missing function param
descriptions
drm/amd/amdgpu/gfx_v7_0: Clean-up a bunch of kernel-doc related issues
drm/msm/disp/dpu1/dpu_core_perf: Fix kernel-doc formatting issues
drm/msm/disp/dpu1/dpu_hw_blk: Add one missing and remove an extra
param description
drm/msm/disp/dpu1/dpu_formats: Demote non-conformant kernel-doc header
drm/msm/disp/dpu1/dpu_hw_catalog: Remove duplicated initialisation of
'max_linewidth'
drm/msm/disp/dpu1/dpu_hw_catalog: Move definitions to the only place
they are used
drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
drm/amd/amdgpu/si_dma: Fix a bunch of function documentation issues
drm/amd/amdgpu/gfx_v6_0: Supply description for
'gfx_v6_0_ring_test_ib()'s 'timeout' param
drm/msm/disp/dpu1/dpu_encoder: Fix a few parameter/member formatting
issues
drm/msm/disp/dpu1/dpu_hw_lm: Fix misnaming of parameter 'ctx'
drm/msm/disp/dpu1/dpu_hw_sspp: Fix kernel-doc formatting abuse
drm/amd/amdgpu/uvd_v3_1: Fix-up some documentation issues
drm/amd/amdgpu/dce_v6_0: Fix formatting and missing parameter
description issues
drm/amd/include/vega20_ip_offset: Mark top-level IP_BASE definition as
__maybe_unused
drm/amd/include/navi10_ip_offset: Mark top-level IP_BASE as
__maybe_unused
drm/amd/include/arct_ip_offset: Mark top-level IP_BASE definition as
__maybe_unused
drm/amd/include/navi14_ip_offset: Mark top-level IP_BASE as
__maybe_unused
drm/amd/include/navi12_ip_offset: Mark top-level IP_BASE as
__maybe_unused
drm/amd/include/sienna_cichlid_ip_offset: Mark top-level IP_BASE as
__maybe_unused
drm/amd/include/vangogh_ip_offset: Mark top-level IP_BASE as
__maybe_unused
drm/amd/include/dimgrey_cavefish_ip_offset: Mark top-level IP_BASE as
__maybe_unused
drm/msm/disp/dpu1/dpu_rm: Fix formatting issues and supply
'global_state' description
drm/msm/disp/dpu1/dpu_vbif: Fix a couple of function param
descriptions
drm/amd/amdgpu/cik_sdma: Add one and remove another function param
description
drm/amd/amdgpu/uvd_v4_2: Add one and remove another function param
description
drm/msm/disp/dpu1/dpu_plane: Fix some spelling and missing function
param descriptions
drm/amd/amdgpu/gmc_v7_0: Add some missing kernel-doc descriptions
drm/amd/amdgpu/gmc_v8_0: Fix more issues attributed to copy/paste
drm/msm/msm_drv: Make '_msm_ioremap()' static
drm/amd/amdgpu/gmc_v9_0: Remove unused table
'ecc_umc_mcumc_status_addrs'
drm/amd/amdgpu/gmc_v9_0: Suppy some missing function doc descriptions
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 12 +-
drivers/gpu/drm/amd/amdgpu/cik_ih.c | 2 +
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 18 ++-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 33 +++--
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 7 +-
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 5 +
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 38 +
drivers/gpu/drm/amd/amdgpu/si_dma.c | 14 +-
drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c | 10 +-
drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 10 +-
drivers/gpu/drm/amd/include/arct_ip_offset.h | 4 +-
.../amd/include/dimgrey_cavefish_ip_offset.h | 2 +-
.../gpu/drm/amd/include/navi10_ip_offset.h| 2 +-
.../gpu/drm/amd/include/navi12_ip_offset.h| 2 +-
.../gpu/drm/amd/include/navi14_ip_offset.h| 2 +-
.../amd/include/sienna_cichlid_ip_offset.h| 2 +-
.../gpu/drm/amd/include/vangogh_ip_offset.h | 2 +-
.../gpu/drm/amd/include/vega20_ip_offset.h| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 17 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 15 +-
driver
[PATCH 0/2] drm/cma-helper: Move mmap to object functions
This patchset moves CMA's mmap into a GEM object function. This change allows for removing CMA's mmap and gem_prime_mmap callbacks in favor of the default implementation. Tested with vc4 on RPi3. Thomas Zimmermann (2): drm/cma-helper: Remove prime infix from GEM object functions drm/cma-helper: Implement mmap as GEM CMA object functions drivers/gpu/drm/drm_file.c | 3 +- drivers/gpu/drm/drm_gem_cma_helper.c | 141 +-- drivers/gpu/drm/pl111/pl111_drv.c| 2 +- drivers/gpu/drm/vc4/vc4_bo.c | 6 +- include/drm/drm_gem_cma_helper.h | 14 +-- 5 files changed, 58 insertions(+), 108 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/cma-helper: Remove prime infix from GEM object functions
These functions are not directly related to PRIME interfaces any
longer, but are now GEM object functions. Rename them accordingly
and fix the docs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_cma_helper.c | 20 ++--
drivers/gpu/drm/vc4/vc4_bo.c | 4 ++--
include/drm/drm_gem_cma_helper.h | 4 ++--
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 4d5c1d86b022..6a4ef335ebc9 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -36,8 +36,8 @@
static const struct drm_gem_object_funcs drm_gem_cma_default_funcs = {
.free = drm_gem_cma_free_object,
.print_info = drm_gem_cma_print_info,
- .get_sg_table = drm_gem_cma_prime_get_sg_table,
- .vmap = drm_gem_cma_prime_vmap,
+ .get_sg_table = drm_gem_cma_get_sg_table,
+ .vmap = drm_gem_cma_vmap,
.vm_ops = &drm_gem_cma_vm_ops,
};
@@ -424,18 +424,18 @@ void drm_gem_cma_print_info(struct drm_printer *p,
unsigned int indent,
EXPORT_SYMBOL(drm_gem_cma_print_info);
/**
- * drm_gem_cma_prime_get_sg_table - provide a scatter/gather table of pinned
+ * drm_gem_cma_get_sg_table - provide a scatter/gather table of pinned
* pages for a CMA GEM object
* @obj: GEM object
*
- * This function exports a scatter/gather table suitable for PRIME usage by
+ * This function exports a scatter/gather table by
* calling the standard DMA mapping API. Drivers using the CMA helpers should
* set this as their &drm_gem_object_funcs.get_sg_table callback.
*
* Returns:
* A pointer to the scatter/gather table of pinned pages or NULL on failure.
*/
-struct sg_table *drm_gem_cma_prime_get_sg_table(struct drm_gem_object *obj)
+struct sg_table *drm_gem_cma_get_sg_table(struct drm_gem_object *obj)
{
struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
struct sg_table *sgt;
@@ -456,7 +456,7 @@ struct sg_table *drm_gem_cma_prime_get_sg_table(struct
drm_gem_object *obj)
kfree(sgt);
return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(drm_gem_cma_prime_get_sg_table);
+EXPORT_SYMBOL_GPL(drm_gem_cma_get_sg_table);
/**
* drm_gem_cma_prime_import_sg_table - produce a CMA GEM object from another
@@ -528,13 +528,13 @@ int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
EXPORT_SYMBOL_GPL(drm_gem_cma_prime_mmap);
/**
- * drm_gem_cma_prime_vmap - map a CMA GEM object into the kernel's virtual
+ * drm_gem_cma_vmap - map a CMA GEM object into the kernel's virtual
* address space
* @obj: GEM object
* @map: Returns the kernel virtual address of the CMA GEM object's backing
* store.
*
- * This function maps a buffer exported via DRM PRIME into the kernel's
+ * This function maps a buffer into the kernel's
* virtual address space. Since the CMA buffers are already mapped into the
* kernel virtual address space this simply returns the cached virtual
* address. Drivers using the CMA helpers should set this as their DRM
@@ -543,7 +543,7 @@ EXPORT_SYMBOL_GPL(drm_gem_cma_prime_mmap);
* Returns:
* 0 on success, or a negative error code otherwise.
*/
-int drm_gem_cma_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map *map)
+int drm_gem_cma_vmap(struct drm_gem_object *obj, struct dma_buf_map *map)
{
struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
@@ -551,7 +551,7 @@ int drm_gem_cma_prime_vmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
return 0;
}
-EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vmap);
+EXPORT_SYMBOL_GPL(drm_gem_cma_vmap);
/**
* drm_gem_cma_prime_import_sg_table_vmap - PRIME import another driver's
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 469d1b4f2643..813e6cb3f9af 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -385,7 +385,7 @@ static const struct vm_operations_struct vc4_vm_ops = {
static const struct drm_gem_object_funcs vc4_gem_object_funcs = {
.free = vc4_free_object,
.export = vc4_prime_export,
- .get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .get_sg_table = drm_gem_cma_get_sg_table,
.vmap = vc4_prime_vmap,
.vm_ops = &vc4_vm_ops,
};
@@ -794,7 +794,7 @@ int vc4_prime_vmap(struct drm_gem_object *obj, struct
dma_buf_map *map)
return -EINVAL;
}
- return drm_gem_cma_prime_vmap(obj, map);
+ return drm_gem_cma_vmap(obj, map);
}
struct drm_gem_object *
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 5605c1b8f779..4680275ab339 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -96,14 +96,14 @@ unsigned long drm_gem_cma_get_unmapped_area(struct file
*filp,
void drm_gem_cma_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_gem_object *obj);
-struct s
[PATCH 2/2] drm/cma-helper: Implement mmap as GEM CMA object functions
The new GEM object function drm_gem_cma_mmap() sets the VMA flags
and offset as in the old implementation and immediately maps in the
buffer's memory pages.
Changing CMA helpers to use the GEM object function allows for the
removal of the special implementations for mmap and gem_prime_mmap
callbacks. The regular functions drm_gem_mmap() and drm_gem_prime_mmap()
are now used.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_file.c | 3 +-
drivers/gpu/drm/drm_gem_cma_helper.c | 121 +--
drivers/gpu/drm/pl111/pl111_drv.c| 2 +-
drivers/gpu/drm/vc4/vc4_bo.c | 2 +-
include/drm/drm_gem_cma_helper.h | 10 +--
5 files changed, 44 insertions(+), 94 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index b50380fa80ce..80886d50d0f1 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -113,8 +113,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
* The memory mapping implementation will vary depending on how the driver
* manages memory. Legacy drivers will use the deprecated drm_legacy_mmap()
* function, modern drivers should use one of the provided memory-manager
- * specific implementations. For GEM-based drivers this is drm_gem_mmap(), and
- * for drivers which use the CMA GEM helpers it's drm_gem_cma_mmap().
+ * specific implementations. For GEM-based drivers this is drm_gem_mmap().
*
* No other file operations are supported by the DRM userspace API. Overall the
* following is an example &file_operations structure::
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 6a4ef335ebc9..7942cf05cd93 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -38,6 +38,7 @@ static const struct drm_gem_object_funcs
drm_gem_cma_default_funcs = {
.print_info = drm_gem_cma_print_info,
.get_sg_table = drm_gem_cma_get_sg_table,
.vmap = drm_gem_cma_vmap,
+ .mmap = drm_gem_cma_mmap,
.vm_ops = &drm_gem_cma_vm_ops,
};
@@ -277,62 +278,6 @@ const struct vm_operations_struct drm_gem_cma_vm_ops = {
};
EXPORT_SYMBOL_GPL(drm_gem_cma_vm_ops);
-static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object *cma_obj,
- struct vm_area_struct *vma)
-{
- int ret;
-
- /*
-* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
-* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
-* the whole buffer.
-*/
- vma->vm_flags &= ~VM_PFNMAP;
- vma->vm_pgoff = 0;
-
- ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
- cma_obj->paddr, vma->vm_end - vma->vm_start);
- if (ret)
- drm_gem_vm_close(vma);
-
- return ret;
-}
-
-/**
- * drm_gem_cma_mmap - memory-map a CMA GEM object
- * @filp: file object
- * @vma: VMA for the area to be mapped
- *
- * This function implements an augmented version of the GEM DRM file mmap
- * operation for CMA objects: In addition to the usual GEM VMA setup it
- * immediately faults in the entire object instead of using on-demaind
- * faulting. Drivers which employ the CMA helpers should use this function
- * as their ->mmap() handler in the DRM device file's file_operations
- * structure.
- *
- * Instead of directly referencing this function, drivers should use the
- * DEFINE_DRM_GEM_CMA_FOPS().macro.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
-{
- struct drm_gem_cma_object *cma_obj;
- struct drm_gem_object *gem_obj;
- int ret;
-
- ret = drm_gem_mmap(filp, vma);
- if (ret)
- return ret;
-
- gem_obj = vma->vm_private_data;
- cma_obj = to_drm_gem_cma_obj(gem_obj);
-
- return drm_gem_cma_mmap_obj(cma_obj, vma);
-}
-EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
-
#ifndef CONFIG_MMU
/**
* drm_gem_cma_get_unmapped_area - propose address for mapping in noMMU cases
@@ -500,33 +445,6 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
}
EXPORT_SYMBOL_GPL(drm_gem_cma_prime_import_sg_table);
-/**
- * drm_gem_cma_prime_mmap - memory-map an exported CMA GEM object
- * @obj: GEM object
- * @vma: VMA for the area to be mapped
- *
- * This function maps a buffer imported via DRM PRIME into a userspace
- * process's address space. Drivers that use the CMA helpers should set this
- * as their &drm_driver.gem_prime_mmap callback.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct drm_gem_cma_object *cma_obj;
- int ret;
-
- ret = drm_gem_mmap_obj(obj, obj->size, vma);
- if (ret < 0)
- return ret;
-
- cma_obj = to_drm_gem_cma_obj(obj);
-
Re: [PATCH 00/40] [Set 8] Rid W=1 warnings from GPU
On Mon, 23 Nov 2020, Christian König wrote: > Only skimmed over them, but over all looks sane to me. > > Series is Acked-by: Christian König Thanks Christian, much appreciated. > Am 23.11.20 um 12:18 schrieb Lee Jones: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > > Only 900 (from 5000) to go! > > > > Lee Jones (40): > >drm/radeon/radeon_device: Consume our own header where the prototypes > > are located > >drm/amd/amdgpu/amdgpu_ttm: Add description for 'page_flags' > >drm/amd/amdgpu/amdgpu_ib: Provide docs for 'amdgpu_ib_schedule()'s > > 'job' param > >drm/amd/amdgpu/amdgpu_virt: Correct possible copy/paste or doc-rot > > misnaming issue > >drm/amd/amdgpu/cik_ih: Supply description for 'ih' in [...] -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] drm/imx: Introduce i.MX8qxp DPU DRM
Hi Liu Ying,
On Mon, Nov 23, 2020 at 10:45:38AM +0800, Liu Ying wrote:
> Hi Laurentiu,
>
> On Fri, 2020-11-20 at 16:38 +0200, Laurentiu Palcu wrote:
> > Hi Liu Ying,
> >
> > I gave this a first look but, since this is a huge piece of code and I'm not
> > very familiar with DPU, I'll probably give it another pass next week.
> >
> > Anyway, some comments/questions inline.
> >
> > On Thu, Nov 19, 2020 at 11:22:22AM +0200, Liu Ying wrote:
> > > This patch introduces i.MX8qxp Display Processing Unit(DPU) DRM support.
> > >
> > > DPU is comprised of two main components that include a blit engine for
> > > 2D graphics accelerations(with composition support) and a display
> > > controller
> > > for display output processing, as well as a command sequencer. Outside of
> > > DPU, optional prefetch engines, a.k.a, Prefetch Resolve Gasket(PRG) and
> > > Display Prefetch Resolve(DPR), can fetch data from memory prior to some
> > > DPU
> > > fetchunits of blit engine and display controller. The prefetch engines
> > > support reading linear formats and resolving Vivante GPU tile formats.
> > >
> > > This patch adds kernel modesetting support for the display controller
> > > part.
> > > The driver supports two CRTCs per display controller, planes backed by
> > > four fetchunits(decode0/1, fetchlayer, fetchwarp), fetchunit allocation
> > > logic for the two CRTCs, prefetch engines(with tile resolving supported),
> > > plane upscaling/deinterlacing/yuv2rgb CSC/alpha blending and CRTC gamma
> > > correction. The registers of the controller is accessed without command
> > > sequencer involved, instead just by using CPU.
> >
> > Will you also add support for command sequencer in the future? The command
> > sequencer seems to have the same purpose as the DCSS context loader on
> > iMX8MQ,
> > which is very useful for configuring the various DC blocks right in the
> > blanking period without having to worry about synchronization. Why not use
> > it
> > from the very beginning?
>
> The single command sequencer(cmdseq) per DPU supports
> NOP/CALL/RET/WRITE/COPY/CCOPY/SYNC instructions.
>
> It is designed to autonomously process command lists.
>
> Two reasons for not using cmdseq for display controller(kms):
>
> 1) performance consideration:
>
> The SYNC instruction stops processing the subsequent command list until
> one specific hardware event of the DPU is triggered, like shadow loaded
> event, ComCtrl_SW0(cmdseq sequence complete event), etc. To use the
> autonomous command list processing, we would queue command blocks to a
> chain. The command blocks are usually comprised of some initial WRITE
> instructions and a final SYNC instruction(to make sure the WRITE
> instructions take effect). The command blocks could be for blit engine
> or display controller. As blit engine and display controller
> operations are naturally async, those SYNC instructions would impact
> the blit and display performance. Even the two display pipelines(two
> CRTCs) of DPU themselves could impact each other's performance, because
> there could be parallel atomic commits for the two pipelines.
>
> 2) no cmdseq read instructions:
>
> The KMS driver for the display controller needs to read DPU registers
> to report CRTC scannout position, vlbank count and CRC data(DPU
> Signature units). Also, it needs to read DPU registers to sync some
> events(like FrameGen counter moving). Inserting CPU read operations
> into command sequence would pollute the pure cmdseq programming model.
>
>
> In general, cmdseq is probably better to be reserved for blit engine,
> since I assume blit engine, as a 2D engine, usually doesn't need
> reading registers. Also, blit performance would be good.
Thanks for clarifying this.
>
> >
> > > Reference manual can be found at:
> > > https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM
> > >
> > > Signed-off-by: Liu Ying
> > > ---
> >
> > [...]
> >
> > > diff --git a/drivers/gpu/drm/imx/dpu/dpu-core.c
> > > b/drivers/gpu/drm/imx/dpu/dpu-core.c
> > > new file mode 100644
> > > index ..1583c7a
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/imx/dpu/dpu-core.c
> > > @@ -0,0 +1,880 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +
> > > +/*
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + * Copyright 2017-2020 NXP
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include "dpu.h"
> > > +#include "dpu-prv.h"
> > > +
> > > +static inline u32 dpu_comctrl_read(struct dpu_soc *dpu, unsigned int
> > > offset)
> > > +{
> > > + return readl(dpu->comctrl_reg + offset);
> > > +}
> > > +
> > > +static inline void dpu_comctrl_write(struct dpu_soc *dpu,
> > > + unsigned int offset, u32 value)
> > > +{
> > > + writel(value, dpu->comctrl_reg + offset);
> > > +}
> > > +
> > > +/* Const
Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote: > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote: > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote: > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote: > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > > > > > Please tell me our reward for all this effort isn't a single > > > > > missing error print. > > > > > > > > There were quite literally dozens of logical defects found > > > > by the fallthrough additions. Very few were logging only. > > > > > > So can you give us the best examples (or indeed all of them if > > > someone is keeping score)? hopefully this isn't a US election > > > situation ... > > > > Gustavo? Are you running for congress now? > > > > https://lwn.net/Articles/794944/ > > That's 21 reported fixes of which about 50% seem to produce no change > in code behaviour at all, a quarter seem to have no user visible effect > with the remaining quarter producing unexpected errors on obscure > configuration parameters, which is why no-one really noticed them > before. The really important point here is the number of bugs this has prevented and will prevent in the future. See an example of this, below: https://lore.kernel.org/linux-iio/20190813135802.gb27...@kroah.com/ This work is still relevant, even if the total number of issues/bugs we find in the process is zero (which is not the case). "The sucky thing about doing hard work to deploy hardening is that the result is totally invisible by definition (things not happening) [..]" - Dmitry Vyukov Thanks -- Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/meson: dw-hdmi: Disable clocks on driver teardown
On Fri 20 Nov 2020 at 10:42, Marc Zyngier wrote:
> The HDMI driver request clocks early, but never disable them, leaving
> the clocks on even when the driver is removed.
>
> Fix it by slightly refactoring the clock code, and register a devm
> action that will eventually disable/unprepare the enabled clocks.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 43 ++-
> 1 file changed, 29 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 7f8eea494147..29623b309cb1 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -145,8 +145,6 @@ struct meson_dw_hdmi {
> struct reset_control *hdmitx_apb;
> struct reset_control *hdmitx_ctrl;
> struct reset_control *hdmitx_phy;
> - struct clk *hdmi_pclk;
> - struct clk *venci_clk;
> struct regulator *hdmi_supply;
> u32 irq_stat;
> struct dw_hdmi *hdmi;
> @@ -946,6 +944,29 @@ static void meson_disable_regulator(void *data)
> regulator_disable(data);
> }
>
> +static void meson_disable_clk(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> +static int meson_enable_clk(struct device *dev, char *name)
> +{
> + struct clk *clk;
> + int ret;
> +
> + clk = devm_clk_get(dev, name);
> + if (IS_ERR(clk)) {
> + dev_err(dev, "Unable to get %s pclk\n", name);
> + return PTR_ERR(clk);
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (!ret)
> + ret = devm_add_action_or_reset(dev, meson_disable_clk,
> clk);
Thanks for fixing this Marc.
FYI, while it is fine to declare a function to disable the clocks, a quick
cast may avoid it
devm_add_action_or_reset(dev, (void(*)(void *))clk_disable_unprepare, clk);
> +
> + return ret;
> +}
> +
> static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
> void *data)
> {
> @@ -1026,19 +1047,13 @@ static int meson_dw_hdmi_bind(struct device *dev,
> struct device *master,
> if (IS_ERR(meson_dw_hdmi->hdmitx))
> return PTR_ERR(meson_dw_hdmi->hdmitx);
>
> - meson_dw_hdmi->hdmi_pclk = devm_clk_get(dev, "isfr");
> - if (IS_ERR(meson_dw_hdmi->hdmi_pclk)) {
> - dev_err(dev, "Unable to get HDMI pclk\n");
> - return PTR_ERR(meson_dw_hdmi->hdmi_pclk);
> - }
> - clk_prepare_enable(meson_dw_hdmi->hdmi_pclk);
> + ret = meson_enable_clk(dev, "isfr");
> + if (ret)
> + return ret;
>
> - meson_dw_hdmi->venci_clk = devm_clk_get(dev, "venci");
> - if (IS_ERR(meson_dw_hdmi->venci_clk)) {
> - dev_err(dev, "Unable to get venci clk\n");
> - return PTR_ERR(meson_dw_hdmi->venci_clk);
> - }
> - clk_prepare_enable(meson_dw_hdmi->venci_clk);
> + ret = meson_enable_clk(dev, "venci");
> + if (ret)
> + return ret;
>
> dw_plat_data->regm = devm_regmap_init(dev, NULL, meson_dw_hdmi,
> &meson_dw_hdmi_regmap_config);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/meson: dw-hdmi: Disable clocks on driver teardown
On 2020-11-23 14:03, Jerome Brunet wrote:
On Fri 20 Nov 2020 at 10:42, Marc Zyngier wrote:
The HDMI driver request clocks early, but never disable them, leaving
the clocks on even when the driver is removed.
Fix it by slightly refactoring the clock code, and register a devm
action that will eventually disable/unprepare the enabled clocks.
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 43
++-
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 7f8eea494147..29623b309cb1 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -145,8 +145,6 @@ struct meson_dw_hdmi {
struct reset_control *hdmitx_apb;
struct reset_control *hdmitx_ctrl;
struct reset_control *hdmitx_phy;
- struct clk *hdmi_pclk;
- struct clk *venci_clk;
struct regulator *hdmi_supply;
u32 irq_stat;
struct dw_hdmi *hdmi;
@@ -946,6 +944,29 @@ static void meson_disable_regulator(void *data)
regulator_disable(data);
}
+static void meson_disable_clk(void *data)
+{
+ clk_disable_unprepare(data);
+}
+
+static int meson_enable_clk(struct device *dev, char *name)
+{
+ struct clk *clk;
+ int ret;
+
+ clk = devm_clk_get(dev, name);
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Unable to get %s pclk\n", name);
+ return PTR_ERR(clk);
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (!ret)
+ ret = devm_add_action_or_reset(dev, meson_disable_clk,
clk);
Thanks for fixing this Marc.
FYI, while it is fine to declare a function to disable the clocks, a
quick
cast may avoid it
devm_add_action_or_reset(dev, (void(*)(void *))clk_disable_unprepare,
clk);
While this works for now, a change to the clk_disable_unprepare()
prototype (such as adding a second argument) would now go completely
unnoticed (after all, you've cast the function, it *must* be correct,
right?), and someone would spend a few hours trying to track down memory
corruption or some other interesting results.
Yes, casting C functions can be hilarious.
I can see a few uses of this hack in the tree, and I have my pop-corn
ready.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: Drop local dma_parms
Hi, Robin:
Robin Murphy 於 2020年9月4日 週五 上午4:59寫道：
>
> Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
> for platform devices"), struct platform_device already provides a
> dma_parms structure, so we can save allocating another one.
>
> Also the DMA segment size is simply a size, not a bitmask.
>
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
> Signed-off-by: Robin Murphy
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 23 +++
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 --
> 2 files changed, 3 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 040a8f393fe2..3941f6f6b003 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -221,21 +221,10 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> * Configure the DMA segment size to make sure we get contiguous IOVA
> * when importing PRIME buffers.
> */
> - if (!dma_dev->dma_parms) {
> - private->dma_parms_allocated = true;
> - dma_dev->dma_parms =
> - devm_kzalloc(drm->dev, sizeof(*dma_dev->dma_parms),
> -GFP_KERNEL);
> - }
> - if (!dma_dev->dma_parms) {
> - ret = -ENOMEM;
> - goto err_component_unbind;
> - }
> -
> - ret = dma_set_max_seg_size(dma_dev, (unsigned int)DMA_BIT_MASK(32));
> + ret = dma_set_max_seg_size(dma_dev, UINT_MAX);
> if (ret) {
> dev_err(dma_dev, "Failed to set DMA segment size\n");
> - goto err_unset_dma_parms;
> + goto err_component_unbind;
> }
>
> /*
> @@ -246,16 +235,13 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> drm->irq_enabled = true;
> ret = drm_vblank_init(drm, MAX_CRTC);
> if (ret < 0)
> - goto err_unset_dma_parms;
> + goto err_component_unbind;
>
> drm_kms_helper_poll_init(drm);
> drm_mode_config_reset(drm);
>
> return 0;
>
> -err_unset_dma_parms:
> - if (private->dma_parms_allocated)
> - dma_dev->dma_parms = NULL;
> err_component_unbind:
> component_unbind_all(drm->dev, drm);
>
> @@ -269,9 +255,6 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
> drm_kms_helper_poll_fini(drm);
> drm_atomic_helper_shutdown(drm);
>
> - if (private->dma_parms_allocated)
> - private->dma_dev->dma_parms = NULL;
> -
> component_unbind_all(drm->dev, drm);
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index b5be63e53176..6afd0b5f2b92 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -44,8 +44,6 @@ struct mtk_drm_private {
> struct mtk_ddp_comp *ddp_comp[DDP_COMPONENT_ID_MAX];
> const struct mtk_mmsys_driver_data *data;
> struct drm_atomic_state *suspend_state;
> -
> - bool dma_parms_allocated;
> };
>
> extern struct platform_driver mtk_ddp_driver;
> --
> 2.28.0.dirty
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 30/30] drm/mediatek/mtk_disp_ovl: Fix formatting and provide missing member description
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 上午3:01寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or
> member 'ddp_comp' not described in 'mtk_disp_ovl'
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or
> member 'crtc' not described in 'mtk_disp_ovl'
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or
> member 'data' not described in 'mtk_disp_ovl'
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Cc: Chun-Kuang Hu
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Matthias Brugger
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 28651bc579bc9..74ef6fc0528b6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -65,8 +65,9 @@ struct mtk_disp_ovl_data {
>
> /**
> * struct mtk_disp_ovl - DISP_OVL driver structure
> - * @ddp_comp - structure containing type enum and hardware resources
> - * @crtc - associated crtc to report vblank events to
> + * @ddp_comp: structure containing type enum and hardware resources
> + * @crtc: associated crtc to report vblank events to
> + * @data: platform data
> */
> struct mtk_disp_ovl {
> struct mtk_ddp_comp ddp_comp;
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/40] drm/mediatek/mtk_disp_rdma: Fix formatting and supply missing struct member description
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 下午9:49寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c:66: warning: Function parameter or
> member 'ddp_comp' not described in 'mtk_disp_rdma'
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c:66: warning: Function parameter or
> member 'crtc' not described in 'mtk_disp_rdma'
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c:66: warning: Function parameter or
> member 'data' not described in 'mtk_disp_rdma'
>
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
> Cc: Chun-Kuang Hu
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Matthias Brugger
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index e04319fedf463..d46b8ae1d0800 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -56,8 +56,9 @@ struct mtk_disp_rdma_data {
>
> /**
> * struct mtk_disp_rdma - DISP_RDMA driver structure
> - * @ddp_comp - structure containing type enum and hardware resources
> - * @crtc - associated crtc to report irq events to
> + * @ddp_comp: structure containing type enum and hardware resources
> + * @crtc: associated crtc to report irq events to
> + * @data: local driver data
> */
> struct mtk_disp_rdma {
> struct mtk_ddp_comp ddp_comp;
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/40] drm/mediatek/mtk_drm_drv: Staticise local function invoked by reference
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 下午9:49寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_drm_drv.c:316:24: warning: no previous
> prototype for ‘mtk_drm_gem_prime_import’ [-Wmissing-prototypes]
>
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
> Cc: Chun-Kuang Hu
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Matthias Brugger
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: YT SHEN
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 2e8065b1e2bbc..401311453e7d0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -313,8 +313,8 @@ static const struct file_operations mtk_drm_fops = {
> * We need to override this because the device used to import the memory is
> * not dev->dev, as drm_gem_prime_import() expects.
> */
> -struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device *dev,
> - struct dma_buf *dma_buf)
> +static struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device
> *dev,
> + struct dma_buf
> *dma_buf)
> {
> struct mtk_drm_private *private = dev->dev_private;
>
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/30] drm/mediatek/mtk_disp_color: Fix formatting and provide missing member description
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 上午3:01寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or
> member 'ddp_comp' not described in 'mtk_disp_color'
> drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or
> member 'crtc' not described in 'mtk_disp_color'
> drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or
> member 'data' not described in 'mtk_disp_color'
>
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
> Cc: Chun-Kuang Hu
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Matthias Brugger
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> index 3ae9c810845bb..a788ff95ed6e4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> @@ -30,8 +30,9 @@ struct mtk_disp_color_data {
>
> /**
> * struct mtk_disp_color - DISP_COLOR driver structure
> - * @ddp_comp - structure containing type enum and hardware resources
> - * @crtc - associated crtc to report irq events to
> + * @ddp_comp: structure containing type enum and hardware resources
> + * @crtc: associated crtc to report irq events to
> + * @data: platform colour driver data
> */
> struct mtk_disp_color {
> struct mtk_ddp_comp ddp_comp;
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm: panel: add support for the Khadas TS050 panel
This add support & bindings for the Khadas TS050 1080x1920 5" LCD DSI panel designed to work with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers. It provides a MIPI DSI interface to the host, a built-in LED backlight and touch controller. Neil Armstrong (2): dt-bindings: panel-simple-dsi: add Khadas TS050 panel bindings drm: panel: add Khadas TS050 panel driver .../display/panel/panel-simple-dsi.yaml | 2 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-khadas-ts050.c| 876 ++ 4 files changed, 890 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: panel-simple-dsi: add Khadas TS050 panel bindings
This add the bindings for the Khadas TS050 1080x1920 5" LCD DSI panel designed to work with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers. Signed-off-by: Neil Armstrong --- .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 72e4b6d4d5e1..fbd71669248f 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -35,6 +35,8 @@ properties: - boe,tv080wum-nl0 # Innolux P079ZCA 7.85" 768x1024 TFT LCD panel - innolux,p079zca +# Khadas TS050 5" 1080x1920 LCD panel + - khadas,ts050 # Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel - kingdisplay,kd097d04 # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: panel: add Khadas TS050 panel driver
This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to
work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.
The init values was taken from the vendor source tree, comments were added to
the
know values but most of the init table is undocumented.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-khadas-ts050.c | 876 +
3 files changed, 888 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index b4e021ea30f9..8fec45b2ce02 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -145,6 +145,17 @@ config DRM_PANEL_JDI_LT070ME05000
The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
24 bit per pixel.
+config DRM_PANEL_KHADAS_TS050
+ tristate "Khadas TS050 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Khadas TS050 TFT-LCD
+ panel module. The panel has a 1080x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host, a built-in LED backlight and touch controller.
+
config DRM_PANEL_KINGDISPLAY_KD097D04
tristate "Kingdisplay kd097d04 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index ebbf488c7eac..03496695e03f 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) +=
panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
+obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c
b/drivers/gpu/drm/panel/panel-khadas-ts050.c
new file mode 100644
index ..856fcad69306
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
@@ -0,0 +1,876 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct khadas_ts050_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+
+ struct regulator *supply;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+ bool enabled;
+};
+
+struct khadas_ts050_panel_cmd {
+ u8 cmd;
+ u8 data;
+};
+
+/* Only the CMD1 User Command set is documented */
+static const struct khadas_ts050_panel_cmd init_code[] = {
+ /* Select Unknown CMD Page (Undocumented) */
+ {0xff, 0xee},
+ /* Reload CMD1: Don't reload default value to register */
+ {0xfb, 0x01},
+ {0x1f, 0x45},
+ {0x24, 0x4f},
+ {0x38, 0xc8},
+ {0x39, 0x27},
+ {0x1e, 0x77},
+ {0x1d, 0x0f},
+ {0x7e, 0x71},
+ {0x7c, 0x03},
+ {0xff, 0x00},
+ {0xfb, 0x01},
+ {0x35, 0x01},
+ /* Select CMD2 Page0 (Undocumented) */
+ {0xff, 0x01},
+ /* Reload CMD1: Don't reload default value to register */
+ {0xfb, 0x01},
+ {0x00, 0x01},
+ {0x01, 0x55},
+ {0x02, 0x40},
+ {0x05, 0x40},
+ {0x06, 0x4a},
+ {0x07, 0x24},
+ {0x08, 0x0c},
+ {0x0b, 0x7d},
+ {0x0c, 0x7d},
+ {0x0e, 0xb0},
+ {0x0f, 0xae},
+ {0x11, 0x10},
+ {0x12, 0x10},
+ {0x13, 0x03},
+ {0x14, 0x4a},
+ {0x15, 0x12},
+ {0x16, 0x12},
+ {0x18, 0x00},
+ {0x19, 0x77},
+ {0x1a, 0x55},
+ {0x1b, 0x13},
+ {0x1c, 0x00},
+ {0x1d, 0x00},
+ {0x1e, 0x13},
+ {0x1f, 0x00},
+ {0x23, 0x00},
+ {0x24, 0x00},
+ {0x25, 0x00},
+ {0x26, 0x00},
+ {0x27, 0x00},
+ {0x28, 0x00},
+ {0x35, 0x00},
+ {0x66, 0x00},
+ {0x58, 0x82},
+ {0x59, 0x02},
+ {0x5a, 0x02},
+ {0x5b, 0x02},
+ {0x5c, 0x82},
+ {0x5d, 0x82},
+ {0x5e, 0x02},
+ {0x5f, 0x02},
+ {0x72, 0x31},
+ /* Select CMD2 Page4 (Undocumented) */
+ {0xff, 0x05},
+ /* Reload CMD1: Don't reload default value to register */
+ {0xfb, 0x01},
+ {0x00, 0x01},
+ {0x01
Re: [PATCH 18/40] drm/mediatek/mtk_dpi: Remove unused struct definition 'mtk_dpi_encoder_funcs'
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 下午9:50寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_dpi.c:530:39: warning: ‘mtk_dpi_encoder_funcs’
> defined but not used [-Wunused-const-variable=]
>
Thanks for this patch, but I've applied another identical patch
"drm/mediatek: mtk_dpi: Fix unused variable 'mtk_dpi_encoder_funcs'"
[1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/commit/?h=mediatek-drm-fixes&id=46b97aed5484a3f44584a10f9e0691bf89d29064
Regards,
Chun-Kuang.
> Cc: Chun-Kuang Hu
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Matthias Brugger
> Cc: Jie Qiu
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index cf11c4850b405..52f11a63a3304 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -522,15 +522,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> return 0;
> }
>
> -static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> - .destroy = mtk_dpi_encoder_destroy,
> -};
> -
> static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 1/8] iommu/io-pgtable-arm: Add support to use system cache
On Tue, Nov 17, 2020 at 08:00:40PM +0530, Sai Prakash Ranjan wrote:
> Add a quirk IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to override
> the attributes set in TCR for the page table walker when
> using system cache.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/io-pgtable-arm.c | 10 --
> include/linux/io-pgtable.h | 4
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index a7a9bc08dcd1..7c9ea9d7874a 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -761,7 +761,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg,
> void *cookie)
>
> if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
> IO_PGTABLE_QUIRK_NON_STRICT |
> - IO_PGTABLE_QUIRK_ARM_TTBR1))
> + IO_PGTABLE_QUIRK_ARM_TTBR1 |
> + IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
> return NULL;
>
> data = arm_lpae_alloc_pgtable(cfg);
> @@ -773,10 +774,15 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg
> *cfg, void *cookie)
> tcr->sh = ARM_LPAE_TCR_SH_IS;
> tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
> tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
> + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
> + goto out_free_data;
> } else {
> tcr->sh = ARM_LPAE_TCR_SH_OS;
> tcr->irgn = ARM_LPAE_TCR_RGN_NC;
> - tcr->orgn = ARM_LPAE_TCR_RGN_NC;
> + if (!(cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
> + tcr->orgn = ARM_LPAE_TCR_RGN_NC;
> + else
> + tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
> }
>
> tg1 = cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1;
> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> index 4cde111e425b..a9a2c59fab37 100644
> --- a/include/linux/io-pgtable.h
> +++ b/include/linux/io-pgtable.h
> @@ -86,6 +86,9 @@ struct io_pgtable_cfg {
>*
>* IO_PGTABLE_QUIRK_ARM_TTBR1: (ARM LPAE format) Configure the table
>* for use in the upper half of a split address space.
> + *
> + * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the attributes set in TCR
> for
> + * the page table walker when using system cache.
Please can you reword this to say:
"Override the outer-cacheability attributes set in the TCR for a non-coherent
page-table walker."
Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 2/8] iommu/arm-smmu: Add domain attribute for pagetable configuration
On Tue, Nov 17, 2020 at 08:00:41PM +0530, Sai Prakash Ranjan wrote:
> Add iommu domain attribute for pagetable configuration which
> initially will be used to set quirks like for system cache aka
> last level cache to be used by client drivers like GPU to set
> right attributes for caching the hardware pagetables into the
> system cache and later can be extended to include other page
> table configuration data.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 25 +
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
> include/linux/io-pgtable.h| 4
> include/linux/iommu.h | 1 +
> 4 files changed, 31 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 0f28a8614da3..7b05782738e2 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
> if (smmu_domain->non_strict)
> pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
>
> + if (smmu_domain->pgtbl_cfg.quirks)
> + pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
> +
> pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
> if (!pgtbl_ops) {
> ret = -ENOMEM;
> @@ -1511,6 +1514,12 @@ static int arm_smmu_domain_get_attr(struct
> iommu_domain *domain,
> case DOMAIN_ATTR_NESTING:
> *(int *)data = (smmu_domain->stage ==
> ARM_SMMU_DOMAIN_NESTED);
> return 0;
> + case DOMAIN_ATTR_IO_PGTABLE_CFG: {
> + struct domain_attr_io_pgtbl_cfg *pgtbl_cfg = data;
> + *pgtbl_cfg = smmu_domain->pgtbl_cfg;
> +
> + return 0;
> + }
> default:
> return -ENODEV;
> }
> @@ -1551,6 +1560,22 @@ static int arm_smmu_domain_set_attr(struct
> iommu_domain *domain,
> else
> smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
> break;
> + case DOMAIN_ATTR_IO_PGTABLE_CFG: {
> + struct domain_attr_io_pgtbl_cfg *pgtbl_cfg = data;
> +
> + if (smmu_domain->smmu) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> +
> + if (!pgtbl_cfg) {
Do we really need to check this? If somebody passed us a NULL pointer then
they have a bug and we don't check this for other domain attributes afaict.
> + ret = -ENODEV;
> + goto out_unlock;
> + }
> +
> + smmu_domain->pgtbl_cfg = *pgtbl_cfg;
> + break;
> + }
> default:
> ret = -ENODEV;
> }
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 04288b6fc619..18fbed376afb 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -364,6 +364,7 @@ enum arm_smmu_domain_stage {
> struct arm_smmu_domain {
> struct arm_smmu_device *smmu;
> struct io_pgtable_ops *pgtbl_ops;
> + struct domain_attr_io_pgtbl_cfg pgtbl_cfg;
> const struct iommu_flush_ops*flush_ops;
> struct arm_smmu_cfg cfg;
> enum arm_smmu_domain_stage stage;
> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> index a9a2c59fab37..686b37d48743 100644
> --- a/include/linux/io-pgtable.h
> +++ b/include/linux/io-pgtable.h
> @@ -212,6 +212,10 @@ struct io_pgtable {
>
> #define io_pgtable_ops_to_pgtable(x) container_of((x), struct io_pgtable,
> ops)
>
> +struct domain_attr_io_pgtbl_cfg {
> + unsigned long quirks;
> +};
nit: Can you rename this to 'struct io_pgtable_domain_attr' please?
Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 3/8] iommu/arm-smmu: Move non-strict mode to use domain_attr_io_pgtbl_cfg
On Tue, Nov 17, 2020 at 08:00:42PM +0530, Sai Prakash Ranjan wrote:
> Now that we have a struct domain_attr_io_pgtbl_cfg with quirks,
> use that for non_strict mode as well thereby removing the need
> for more members of arm_smmu_domain in the future.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 7 ++-
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 7b05782738e2..5f066a1b7221 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -786,9 +786,6 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
> goto out_clear_smmu;
> }
>
> - if (smmu_domain->non_strict)
> - pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
> -
> if (smmu_domain->pgtbl_cfg.quirks)
> pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
>
> @@ -1527,7 +1524,7 @@ static int arm_smmu_domain_get_attr(struct iommu_domain
> *domain,
> case IOMMU_DOMAIN_DMA:
> switch (attr) {
> case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
> - *(int *)data = smmu_domain->non_strict;
> + *(int *)data = smmu_domain->pgtbl_cfg.quirks;
Probably better to compare with IO_PGTABLE_QUIRK_NON_STRICT here even though
we only support this one quirk for DMA domains atm.
Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 0/8] System Cache support for GPU and required SMMU support
On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote: > Some hardware variants contain a system cache or the last level > cache(llc). This cache is typically a large block which is shared > by multiple clients on the SOC. GPU uses the system cache to cache > both the GPU data buffers(like textures) as well the SMMU pagetables. > This helps with improved render performance as well as lower power > consumption by reducing the bus traffic to the system memory. > > The system cache architecture allows the cache to be split into slices > which then be used by multiple SOC clients. This patch series is an > effort to enable and use two of those slices preallocated for the GPU, > one for the GPU data buffers and another for the GPU SMMU hardware > pagetables. > > Patch 1 - Patch 6 adds system cache support in SMMU and GPU driver. > Patch 7 and 8 are minor cleanups for arm-smmu impl. > > Changes in v8: > * Introduce a generic domain attribute for pagetable config (Will) > * Rename quirk to more generic IO_PGTABLE_QUIRK_ARM_OUTER_WBWA (Will) > * Move non-strict mode to use new struct domain_attr_io_pgtbl_config (Will) Modulo some minor comments I've made, this looks good to me. What is the plan for merging it? I can take the IOMMU parts, but patches 4-6 touch the MSM GPU driver and I'd like to avoid conflicts with that. Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210317] New: Sleep mode not working in ryzen 4000 laptop
https://bugzilla.kernel.org/show_bug.cgi?id=210317 Bug ID: 210317 Summary: Sleep mode not working in ryzen 4000 laptop Product: Drivers Version: 2.5 Kernel Version: 5.10.rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: sujay1...@protonmail.com Regression: No Created attachment 293787 --> https://bugzilla.kernel.org/attachment.cgi?id=293787&action=edit Output of inxi -Fxz I have an Acer Swift 3 with AMD Ryzen 5 4500U running Manjaro. When I close and open the laptop lid, the screen doesn't turn back on but the keyboard backlight does. If I remember correctly, when I installed 5.10.rc2, sleep worked normally for exactly twice and then never again till now. I have the output of inxi -Fxz in a text file attached. This is my first ever bug report so hopefully I have given all the required information. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210317] Sleep mode not working in ryzen 4000 laptop
https://bugzilla.kernel.org/show_bug.cgi?id=210317 --- Comment #1 from Sujay1844 (sujay1...@protonmail.com) --- btw the same issue persists for 5.6, 5.7, 5.8 and 5.9 kernels. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] MAINTAINERS tag for cleanup robot
On Sat, 21 Nov 2020, James Bottomley
wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
>> A difficult part of automating commits is composing the subsystem
>> preamble in the commit log. For the ongoing effort of a fixer
>> producing
>> one or two fixes a release the use of 'treewide:' does not seem
>> appropriate.
>>
>> It would be better if the normal prefix was used. Unfortunately
>> normal is
>> not consistent across the tree.
>>
>>
>> D: Commit subsystem prefix
>>
>> ex/ for FPGA DFL DRIVERS
>>
>> D: fpga: dfl:
>>
>
> I've got to bet this is going to cause more issues than it solves.
Agreed.
> SCSI uses scsi: : for drivers but not every driver has a
> MAINTAINERS entry. We use either scsi: or scsi: core: for mid layer
> things, but we're not consistent. Block uses blk-: for all
> of it's stuff but almost no s have a MAINTAINERS entry. So
> the next thing you're going to cause is an explosion of suggested
> MAINTAINERs entries.
On the one hand, adoption of new MAINTAINERS entries has been really
slow. Look at B, C, or P, for instance. On the other hand, if this were
to get adopted, you'll potentially get conflicting prefixes for patches
touching multiple files. Then what?
I'm guessing a script looking at git log could come up with better
suggestions for prefixes via popularity contest than manually maintained
MAINTAINERS entries. It might not always get it right, but then human
outsiders aren't going to always get it right either.
Now you'll only need Someone(tm) to write the script. ;)
Something quick like this:
git log --since={1year} --pretty=format:%s -- |\
grep -v "^\(Merge\|Revert\)" |\
sed 's/:[^:]*$//' |\
sort | uniq -c | sort -rn | head -5
already gives me results that really aren't worse than some of the
prefixes invented by drive-by contributors.
> Has anyone actually complained about treewide:?
As Joe said, I'd feel silly applying patches to drivers with that
prefix. If it gets applied by someone else higher up, literally
treewide, then no complaints.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > wrote: > > Well, it seems to be three years of someone's time plus the > > maintainer review time and series disruption of nearly a thousand > > patches. Let's be conservative and assume the producer worked > > about 30% on the series and it takes about 5-10 minutes per patch > > to review, merge and for others to rework existing series. So > > let's say it's cost a person year of a relatively junior engineer > > producing the patches and say 100h of review and application > > time. The latter is likely the big ticket item because it's what > > we have in least supply in the kernel (even though it's 20x vs the > > producer time). > > How are you arriving at such numbers? It is a total of ~200 trivial > lines. Well, I used git. It says that as of today in Linus' tree we have 889 patches related to fall throughs and the first series went in in october 2017 ... ignoring a couple of outliers back to February. > > It's not about the risk of the changes it's about the cost of > > implementing them. Even if you discount the producer time (which > > someone gets to pay for, and if I were the engineering manager, I'd > > be unhappy about), the review/merge/rework time is pretty > > significant in exchange for six minor bug fixes. Fine, when a new > > compiler warning comes along it's certainly reasonable to see if we > > can benefit from it and the fact that the compiler people think > > it's worthwhile is enough evidence to assume this initially. But > > at some point you have to ask whether that assumption is supported > > by the evidence we've accumulated over the time we've been using > > it. And if the evidence doesn't support it perhaps it is time to > > stop the experiment. > > Maintainers routinely review 1-line trivial patches, not to mention > internal API changes, etc. We're also complaining about the inability to recruit maintainers: https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ And burn out: http://antirez.com/news/129 The whole crux of your argument seems to be maintainers' time isn't important so we should accept all trivial patches ... I'm pushing back on that assumption in two places, firstly the valulessness of the time and secondly that all trivial patches are valuable. > If some company does not want to pay for that, that's fine, but they > don't get to be maintainers and claim `Supported`. What I'm actually trying to articulate is a way of measuring value of the patch vs cost ... it has nothing really to do with who foots the actual bill. One thesis I'm actually starting to formulate is that this continual devaluing of maintainers is why we have so much difficulty keeping and recruiting them. James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/bridge: lt9611: Fix handling of 4k panels
On 23-11-20, 11:46, Robert Foss wrote:
> 4k requires two dsi pipes, so don't report MODE_OK when only a
> single pipe is configured. But rather report MODE_PANEL to
> signal that requirements of the panel are not being met.
Acked-By: Vinod Koul
> Reported-by: Peter Collingbourne
> Suggested-by: Peter Collingbourne
> Signed-off-by: Robert Foss
> Tested-by: John Stultz
> ---
> drivers/gpu/drm/bridge/lontium-lt9611.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> index d734d9402c35..e8eb8deb444b 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -867,8 +867,14 @@ static enum drm_mode_status
> lt9611_bridge_mode_valid(struct drm_bridge *bridge,
>const struct
> drm_display_mode *mode)
> {
> struct lt9611_mode *lt9611_mode = lt9611_find_mode(mode);
> + struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
>
> - return lt9611_mode ? MODE_OK : MODE_BAD;
> + if (!lt9611_mode)
> + return MODE_BAD;
> + else if (lt9611_mode->intfs > 1 && !lt9611->dsi1)
> + return MODE_PANEL;
> + else
> + return MODE_OK;
> }
>
> static void lt9611_bridge_pre_enable(struct drm_bridge *bridge)
> --
> 2.27.0
--
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley wrote: > > On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > > wrote: [cut] > > > > Maintainers routinely review 1-line trivial patches, not to mention > > internal API changes, etc. > > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 Right. > The whole crux of your argument seems to be maintainers' time isn't > important so we should accept all trivial patches ... I'm pushing back > on that assumption in two places, firstly the valulessness of the time > and secondly that all trivial patches are valuable. > > > If some company does not want to pay for that, that's fine, but they > > don't get to be maintainers and claim `Supported`. > > What I'm actually trying to articulate is a way of measuring value of > the patch vs cost ... it has nothing really to do with who foots the > actual bill. > > One thesis I'm actually starting to formulate is that this continual > devaluing of maintainers is why we have so much difficulty keeping and > recruiting them. Absolutely. This is just one of the factors involved, but a significant one IMV. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] Allwinner MBUS and DMA-ops rework
On Wed, Nov 18, 2020 at 10:13 AM Maxime Ripard wrote: > > Hi Arnd, Olof, > > Here's the PR for the MBUS rework we discussed in the last couple of > weeks, for what will become 5.11. > > As Arnd suggested, this is based on a PR sent to drm-misc-fixes to merge > the initial fix for a probe error in drm/sun4i due to > dma_direct_set_offset. > > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git > tags/sunxi-rework-mbus Looks good, nice cleanup! I've applied it to the arm/drivers branch now, but I almost missed it, as you sent it to the old a...@kernel.org address instead of s...@kernel.org that is connected to the patchwork. Please also use http:// or git:// addresses in pull requests instead of ssh:// Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 majorgo...@juno.com changed: What|Removed |Added CC||majorgo...@juno.com --- Comment #38 from majorgo...@juno.com --- I have a similar problem, a cascade of errors that typically starts with one of these: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=1093546, emitted seq=1093548 This used to occur only when playing Dauntless, and only after my MSI Radeon RX580 ran hot for a while. Warframe never crashed. Totally different methods of running the games (Dauntless=Lutris and Epic Games Store, Warframe = Steam and Proton). Something then changed after one of the updates within the last month, and now it crashes on both Warframe and Dauntless well before the card is at a high temp. Basically can't run more than about 5 minutes. I was running Ubuntu 18.04, so I figured maybe a newer kernel would fix this, but updating to 20.10 did nothing but waste a couple of days of reloading everything. System: Ryzen 5 3600 on Gigabyte x570 UD with a MSI Radeon RX580 8GB I'm willing to work with whoever sending whatever info/logs are necessary to get this fixed. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote: > On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote: > > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote: > > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote: > > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote: > > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > > > > > > Please tell me our reward for all this effort isn't a > > > > > > single missing error print. > > > > > > > > > > There were quite literally dozens of logical defects found > > > > > by the fallthrough additions. Very few were logging only. > > > > > > > > So can you give us the best examples (or indeed all of them if > > > > someone is keeping score)? hopefully this isn't a US election > > > > situation ... > > > > > > Gustavo? Are you running for congress now? > > > > > > https://lwn.net/Articles/794944/ > > > > That's 21 reported fixes of which about 50% seem to produce no > > change in code behaviour at all, a quarter seem to have no user > > visible effect with the remaining quarter producing unexpected > > errors on obscure configuration parameters, which is why no-one > > really noticed them before. > > The really important point here is the number of bugs this has > prevented and will prevent in the future. See an example of this, > below: > > https://lore.kernel.org/linux-iio/20190813135802.gb27...@kroah.com/ I think this falls into the same category as the other six bugs: it changes the output/input for parameters but no-one has really noticed, usually because the command is obscure or the bias effect is minor. > This work is still relevant, even if the total number of issues/bugs > we find in the process is zero (which is not the case). Really, no ... something which produces no improvement has no value at all ... we really shouldn't be wasting maintainer time with it because it has a cost to merge. I'm not sure we understand where the balance lies in value vs cost to merge but I am confident in the zero value case. > "The sucky thing about doing hard work to deploy hardening is that > the result is totally invisible by definition (things not happening) > [..]" > - Dmitry Vyukov Really, no. Something that can't be measured at all doesn't exist. And actually hardening is one of those things you can measure (which I do have to admit isn't true for everything in the security space) ... it's number of exploitable bugs found before you did it vs number of exploitable bugs found after you did it. Usually hardening eliminates a class of bug, so the way I've measured hardening before is to go through the CVE list for the last couple of years for product X, find all the bugs that are of the class we're looking to eliminate and say if we had hardened X against this class of bug we'd have eliminated Y% of the exploits. It can be quite impressive if Y is a suitably big number. James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote: > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 https://www.wired.com/story/open-source-coders-few-tired/ > What I'm actually trying to articulate is a way of measuring value of > the patch vs cost ... it has nothing really to do with who foots the > actual bill. It's unclear how to measure value in consistency. But one way that costs can be reduced is by automation and _not_ involving maintainers when the patch itself is provably correct. > One thesis I'm actually starting to formulate is that this continual > devaluing of maintainers is why we have so much difficulty keeping and > recruiting them. The linux kernel has something like 1500 different maintainers listed in the MAINTAINERS file. That's not a trivial number. $ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l 1543 $ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l 1446 I think the question you are asking is about trust and how it effects development. And back to that wired story, the actual number of what you might be considering to be maintainers is likely less than 10% of the listed numbers above. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210321] New: /display/dc/dcn20/dcn20_resource.c:3240 dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu]
https://bugzilla.kernel.org/show_bug.cgi?id=210321 Bug ID: 210321 Summary: /display/dc/dcn20/dcn20_resource.c:3240 dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu] Product: Drivers Version: 2.5 Kernel Version: 5.10.0-rc5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: vl...@aresgate.net Regression: No Been happening since 5.9 [Mon Nov 23 08:42:42 2020] [ cut here ] [Mon Nov 23 08:42:42 2020] WARNING: CPU: 15 PID: 155 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:3240 dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu] [Mon Nov 23 08:42:42 2020] Modules linked in: autofs4 ipv6 tcp_bic binfmt_misc btusb btrtl btbcm btintel bluetooth snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_usb_audio snd_hda_codec snd_hwdep snd_usbmidi_lib snd_hda_core rfkill amdgpu ecdh_generic snd_pcm ecc snd_seq_midi mousedev snd_seq_midi_event snd_rawmidi cdc_acm input_leds led_class iommu_v2 evdev gpu_sched snd_seq ttm i2c_algo_bit snd_seq_device drm_kms_helper snd_timer syscopyarea sysfillrect sysimgblt fb_sys_fops snd drm k10temp ccp soundcore sha1_generic button efivarfs dm_crypt encrypted_keys dm_mod r8169 realtek mdio_devres libphy usbhid [Mon Nov 23 08:42:42 2020] CPU: 15 PID: 155 Comm: kworker/15:1 Not tainted 5.10.0-rc5 #50 [Mon Nov 23 08:42:42 2020] Hardware name: Micro-Star International Co., Ltd. MS-7B89/B450M MORTAR (MS-7B89), BIOS 1.D0 01/06/2020 [Mon Nov 23 08:42:42 2020] Workqueue: events drm_mode_rmfb_work_fn [drm] [Mon Nov 23 08:42:42 2020] RIP: 0010:dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu] [Mon Nov 23 08:42:42 2020] Code: 00 7b 2b 22 85 14 1f 00 00 75 26 f2 0f 11 85 58 26 00 00 31 d2 48 89 ee 4c 89 e7 e8 8f f6 ff ff 89 c2 22 95 14 1f 00 00 75 33 <0f> 0b eb 03 90 75 d2 66 0f 12 14 24 f2 0f 11 95 58 26 00 00 48 83 [Mon Nov 23 08:42:42 2020] RSP: 0018:a93000607c28 EFLAGS: 00010246 [Mon Nov 23 08:42:42 2020] RAX: 0001 RBX: RCX: 0001876f [Mon Nov 23 08:42:42 2020] RDX: RSI: 211d5948abbbab22 RDI: 000261a0 [Mon Nov 23 08:42:42 2020] RBP: 8d0cab2a R08: 8d0cab2a1ec8 R09: 8d0c8e44 [Mon Nov 23 08:42:42 2020] R10: 8d0c86dde000 R11: 00010001 R12: 8d0c8e44 [Mon Nov 23 08:42:42 2020] R13: R14: 8d0cab2a R15: 8d0c85b20308 [Mon Nov 23 08:42:42 2020] FS: () GS:8d0f8efc() knlGS: [Mon Nov 23 08:42:42 2020] CS: 0010 DS: ES: CR0: 80050033 [Mon Nov 23 08:42:42 2020] CR2: 56169e9dd940 CR3: 0001114fa000 CR4: 00350ee0 [Mon Nov 23 08:42:42 2020] Call Trace: [Mon Nov 23 08:42:42 2020] dcn20_validate_bandwidth+0x2d/0x50 [amdgpu] [Mon Nov 23 08:42:42 2020] dc_validate_global_state+0x279/0x300 [amdgpu] [Mon Nov 23 08:42:42 2020] amdgpu_dm_atomic_check+0xb39/0xc30 [amdgpu] [Mon Nov 23 08:42:42 2020] drm_atomic_check_only+0x557/0x7e0 [drm] [Mon Nov 23 08:42:42 2020] drm_atomic_commit+0x19/0x70 [drm] [Mon Nov 23 08:42:42 2020] drm_framebuffer_remove+0x395/0x430 [drm] [Mon Nov 23 08:42:42 2020] drm_mode_rmfb_work_fn+0x37/0x50 [drm] [Mon Nov 23 08:42:42 2020] process_one_work+0x1ae/0x300 [Mon Nov 23 08:42:42 2020] worker_thread+0x1f6/0x3e0 [Mon Nov 23 08:42:42 2020] ? rescuer_thread+0x410/0x410 [Mon Nov 23 08:42:42 2020] kthread+0x12a/0x150 [Mon Nov 23 08:42:42 2020] ? kthread_create_worker_on_cpu+0x70/0x70 [Mon Nov 23 08:42:42 2020] ret_from_fork+0x22/0x30 [Mon Nov 23 08:42:42 2020] ---[ end trace cb43a970abd417bb ]--- ❯ emerge --info Portage 3.0.9 (python 3.7.9-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-10.2.0, glibc-2.32-r2, 5.10.0-rc5 x86_64) = System uname: Linux-5.10.0-rc5-x86_64-AMD_Ryzen_7_3700X_8-Core_Processor-with-gentoo-2.7 KiB Mem:16419668 total, 12449312 free KiB Swap: 16137212 total, 16137212 free Timestamp of repository gentoo: Mon, 23 Nov 2020 15:05:42 + Head commit of repository gentoo: b98ac916976c6de90fd633bcb2b579f57762a23c Head commit of repository lto-overlay: 3c0f2f8521d5d8e5180e742bee80f93e64575b38 Head commit of repository mv: 45f322abb49bf38da282afe2aa8c287d99c9e630 Head commit of repository steam-overlay: 6ed5630096d43208168572264f204d40e6b2a5c0 Head commit of repository eroen: 168c481db277e12e30ba6dea71a774337512ce32 Head commit of repository mva: 88a3abdfc840fc7d5645a0570fc0c6b03a45218d sh bash 5.0_p18 ld GNU ld (Gentoo 2.34 p6) 2.34.0 distcc 3.3.3 x86_64-pc-linux-gnu [disabled] ccache version 3.7.12 [disabled] app-shells/bash: 5.0_p18::gentoo dev-java/java-config: 2.3.1::gentoo dev-lang/perl:
Re: [RFC] MAINTAINERS tag for cleanup robot
On 11/22/20 10:22 AM, Joe Perches wrote: > On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote: >> On 11/21/20 9:10 AM, Joe Perches wrote: >>> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote: A difficult part of automating commits is composing the subsystem preamble in the commit log. For the ongoing effort of a fixer producing one or two fixes a release the use of 'treewide:' does not seem appropriate. It would be better if the normal prefix was used. Unfortunately normal is not consistent across the tree. So I am looking for comments for adding a new tag to the MAINTAINERS file D: Commit subsystem prefix ex/ for FPGA DFL DRIVERS D: fpga: dfl: >>> I'm all for it. Good luck with the effort. It's not completely trivial. >>> >>> From a decade ago: >>> >>> https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/ >>> >>> (and that thread started with extra semicolon patches too) >> Reading the history, how about this. >> >> get_maintainer.pl outputs a single prefix, if multiple files have the >> same prefix it works, if they don't its an error. >> >> Another script 'commit_one_file.sh' does the call to get_mainainter.pl >> to get the prefix and be called by run-clang-tools.py to get the fixer >> specific message. > It's not whether the script used is get_maintainer or any other script, > the question is really if the MAINTAINERS file is the appropriate place > to store per-subsystem patch specific prefixes. > > It is. > > Then the question should be how are the forms described and what is the > inheritance priority. My preference would be to have a default of > inherit the parent base and add basename(subsystem dirname). > > Commit history seems to have standardized on using colons as the separator > between the commit prefix and the subject. > > A good mechanism to explore how various subsystems have uses prefixes in > the past might be something like: > > $ git log --no-merges --pretty='%s' - | \ > perl -n -e 'print substr($_, 0, rindex($_, ":") + 1) . "\n";' | \ > sort | uniq -c | sort -rn Thanks, I have shamelessly stolen this line and limited the commits to the maintainer. I will post something once the generation of the prefixes is done. Tom ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/5] drm: panel: simple: Fixup the struct panel_desc kernel doc
Hi,
On Mon, Nov 9, 2020 at 5:01 PM Douglas Anderson wrote:
>
> When I run:
> scripts/kernel-doc -rst drivers/gpu/drm/panel/panel-simple.c
>
> I see that several of the kernel-doc entries aren't showing up because
> they don't specify the full path down the hierarchy. Let's fix that
> and also move to inline kernel docs.
>
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v4:
> - ("drm: panel: simple: Fixup the struct panel_desc kernel doc") new for v4.
>
> drivers/gpu/drm/panel/panel-simple.c | 59
> 1 file changed, 42 insertions(+), 17 deletions(-)
I'm curious if there are any outstanding actions I need to take for
this series. I know I found that on patch #4 I should have added the
sync flags [1] but I was waiting to see if there was any other
feedback before sending a v5. If there's nothing else I'm happy with
any of:
a) I can send a v5 with that small fix.
b) v4 can land an the maintainer landing can add the ".flags =
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC," into the patch when
landing.
c) v4 can land and I can send a follow-up patch with the sync flags fix.
I know it's the holidays right now and folks are busy, but I just
wanted to see if there were any actions I needed to take. Personally
I'm on vacation the last 3 days this week and I imagine I'll come back
to work Monday swamped with email, so today/tomorrow would be an ideal
time to send a spin if one is needed. Thanks!
-Doug
[1]
https://lore.kernel.org/r/CAD=FV=UPkuJ5E2sCQeozNR3CO+LZW=dw9h77vfooeismqgn...@mail.gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 0/4] RDMA: Add dma-buf support
This is the eleventh version of the patch set. Changelog: v11: * Rework the parameter checking code inside ib_umem_dmabuf_get() * Fix incorrect error handling in the new verbs command handler * Put a duplicated code sequence for checking iova and setting page size into a function * In the invalidation callback, check for if the buffer has been mapped and thus the presence of a valid driver mr is ensured * The patch that checks for dma_virt_ops is dropped because it is no longer needed * The patch that documents that dma-buf size is fixed has landed at: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=476b485be03c and thus is no longer included here * The matching user space patch set is sent separately v10: https://www.spinics.net/lists/linux-rdma/msg97483.html * Don't map the pages in ib_umem_dmabuf_get(); use the size information of the dma-buf object to validate the umem size instead * Use PAGE_SIZE directly instead of use ib_umem_find_best_pgsz() when the MR is created since the pages have not been mapped yet and dma-buf requires PAGE_SIZE anyway * Always call mlx5_umem_find_best_pgsz() after mapping the pages to verify that the page size requirement is satisfied * Add a patch to document that dma-buf size is fixed v9: https://www.spinics.net/lists/linux-rdma/msg97432.html * Clean up the code for sg list in-place modification * Prevent dma-buf pages from being mapped multiple times * Map the pages in ib_umem_dmabuf_get() so that inproper values of address/length/iova can be caught early * Check for unsupported flags in the new uverbs command * Add missing uverbs_finalize_uobj_create() * Sort uverbs objects by name * Fix formating issue -- unnecessary alignment of '=' * Unmap pages in mlx5_ib_fence_dmabuf_mr() * Remove address range checking from pagefault_dmabuf_mr() v8: https://www.spinics.net/lists/linux-rdma/msg97370.html * Modify the dma-buf sg list in place to get a proper umem sg list and restore it before calling dma_buf_unmap_attachment() * Validate the umem sg list with ib_umem_find_best_pgsz() * Remove the logic for slicing the sg list at runtime v7: https://www.spinics.net/lists/linux-rdma/msg97297.html * Rebase on top of latest mlx5 MR patch series * Slice dma-buf sg list at runtime instead of creating a new list * Preload the buffer page mapping when the MR is created * Move the 'dma_virt_ops' check into dma_buf_dynamic_attach() v6: https://www.spinics.net/lists/linux-rdma/msg96923.html * Move the dma-buf invalidation callback from the core to the device driver * Move mapping update from work queue to pagefault handler * Add dma-buf based MRs to the xarray of mmkeys so that the pagefault handler can be reached * Update the new driver method and uverbs command signature by changing the paramter 'addr' to 'offset' * Modify the sg list returned from dma_buf_map_attachment() based on the parameters 'offset' and 'length' * Don't import dma-buf if 'dma_virt_ops' is used by the dma device * The patch that clarifies dma-buf sg lists alignment has landed at https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac80cd17a615 and thus is no longer included with this set v5: https://www.spinics.net/lists/linux-rdma/msg96786.html * Fix a few warnings reported by kernel test robot: - no previous prototype for function 'ib_umem_dmabuf_release' - no previous prototype for function 'ib_umem_dmabuf_map_pages' - comparison of distinct pointer types in 'check_add_overflow' * Add comment for the wait between getting the dma-buf sg tagle and updating the NIC page table v4: https://www.spinics.net/lists/linux-rdma/msg96767.html * Add a new ib_device method reg_user_mr_dmabuf() instead of expanding the existing method reg_user_mr() * Use a separate code flow for dma-buf instead of adding special cases to the ODP memory region code path * In invalidation callback, new mapping is updated as whole using work queue instead of being updated in page granularity in the page fault handler * Use dma_resv_get_excl() and dma_fence_wait() to ensure the content of the pages have been moved to the new location before the new mapping is programmed into the NIC * Add code to the ODP page fault handler to check the mapping status * The new access flag added in v3 is removed. * The checking for on-demand paging support in the new uverbs command is removed because it is implied by implementing the new ib_device method * Clarify that dma-buf sg lists are page aligned v3: https://www.spinics.net/lists/linux-rdma/msg96330.html * Use dma_buf_dynamic_attach() instead of dma_buf_attach() * Use on-demand paging mechanism to avoid pinning the GPU memory * Instead of adding a new parameter to the device method for memory registration, pass all the attributes including the file descriptor as a structure * Define a new access flag for dma-buf based memory region * Check for on-demand paging support in the new uverbs command v2: https://www.spinics.net/lists/linu
[PATCH v11 2/4] RDMA/core: Add device method for registering dma-buf based memory region
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/device.c | 1 +
include/rdma/ib_verbs.h | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index ce26564..6768a19 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -2689,6 +2689,7 @@ void ib_set_device_ops(struct ib_device *dev, const
struct ib_device_ops *ops)
SET_DEVICE_OP(dev_ops, read_counters);
SET_DEVICE_OP(dev_ops, reg_dm_mr);
SET_DEVICE_OP(dev_ops, reg_user_mr);
+ SET_DEVICE_OP(dev_ops, reg_user_mr_dmabuf);
SET_DEVICE_OP(dev_ops, req_ncomp_notif);
SET_DEVICE_OP(dev_ops, req_notify_cq);
SET_DEVICE_OP(dev_ops, rereg_user_mr);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 9420827..3d1d098 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -2,7 +2,7 @@
/*
* Copyright (c) 2004 Mellanox Technologies Ltd. All rights reserved.
* Copyright (c) 2004 Infinicon Corporation. All rights reserved.
- * Copyright (c) 2004 Intel Corporation. All rights reserved.
+ * Copyright (c) 2004, 2020 Intel Corporation. All rights reserved.
* Copyright (c) 2004 Topspin Corporation. All rights reserved.
* Copyright (c) 2004 Voltaire Corporation. All rights reserved.
* Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
@@ -2433,6 +2433,10 @@ struct ib_device_ops {
struct ib_mr *(*reg_user_mr)(struct ib_pd *pd, u64 start, u64 length,
u64 virt_addr, int mr_access_flags,
struct ib_udata *udata);
+ struct ib_mr *(*reg_user_mr_dmabuf)(struct ib_pd *pd, u64 offset,
+u64 length, u64 virt_addr, int fd,
+int mr_access_flags,
+struct ib_udata *udata);
int (*rereg_user_mr)(struct ib_mr *mr, int flags, u64 start, u64 length,
u64 virt_addr, int mr_access_flags,
struct ib_pd *pd, struct ib_udata *udata);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 1/4] RDMA/umem: Support importing dma-buf as user memory region
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the buffer is registered as a memory region,
the file descriptor is passed to the RDMA driver along with other
parameters.
Implement the common code for importing dma-buf object and mapping
dma-buf pages.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/Makefile | 2 +-
drivers/infiniband/core/umem.c| 4 +
drivers/infiniband/core/umem_dmabuf.c | 174 ++
drivers/infiniband/core/umem_dmabuf.h | 11 +++
include/rdma/ib_umem.h| 39 +++-
5 files changed, 228 insertions(+), 2 deletions(-)
create mode 100644 drivers/infiniband/core/umem_dmabuf.c
create mode 100644 drivers/infiniband/core/umem_dmabuf.h
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index ccf2670..8ab4eea 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -40,5 +40,5 @@ ib_uverbs-y :=uverbs_main.o
uverbs_cmd.o uverbs_marshall.o \
uverbs_std_types_srq.o \
uverbs_std_types_wq.o \
uverbs_std_types_qp.o
-ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
+ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o umem_dmabuf.o
ib_uverbs-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index f1fc7e3..4bc455f 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -2,6 +2,7 @@
* Copyright (c) 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005 Cisco Systems. All rights reserved.
* Copyright (c) 2005 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -43,6 +44,7 @@
#include
#include "uverbs.h"
+#include "umem_dmabuf.h"
static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int
dirty)
{
@@ -278,6 +280,8 @@ void ib_umem_release(struct ib_umem *umem)
{
if (!umem)
return;
+ if (umem->is_dmabuf)
+ return ib_umem_dmabuf_release(to_ib_umem_dmabuf(umem));
if (umem->is_odp)
return ib_umem_odp_release(to_ib_umem_odp(umem));
diff --git a/drivers/infiniband/core/umem_dmabuf.c
b/drivers/infiniband/core/umem_dmabuf.c
new file mode 100644
index 000..2fcd072
--- /dev/null
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+
+#include "uverbs.h"
+#include "umem_dmabuf.h"
+
+int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf)
+{
+ struct sg_table *sgt;
+ struct scatterlist *sg;
+ struct dma_fence *fence;
+ unsigned long start, end, cur;
+ unsigned int nmap;
+ int i;
+
+ dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
+
+ if (umem_dmabuf->sgt)
+ return 0;
+
+ sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt))
+ return PTR_ERR(sgt);
+
+ /* modify the sg list in-place to match umem address and length */
+
+ start = ALIGN_DOWN(umem_dmabuf->umem.address, PAGE_SIZE);
+ end = ALIGN(umem_dmabuf->umem.address + umem_dmabuf->umem.length,
+ PAGE_SIZE);
+ cur = 0;
+ nmap = 0;
+ for_each_sgtable_dma_sg(sgt, sg, i) {
+ if (start < cur + sg_dma_len(sg) && cur < end)
+ nmap++;
+ if (cur <= start && start < cur + sg_dma_len(sg)) {
+ unsigned long offset = start - cur;
+
+ umem_dmabuf->first_sg = sg;
+ umem_dmabuf->first_sg_offset = offset;
+ sg_dma_address(sg) += offset;
+ sg_dma_len(sg) -= offset;
+ cur += offset;
+ }
+ if (cur < end && end <= cur + sg_dma_len(sg)) {
+ unsigned long trim = cur + sg_dma_len(sg) - end;
+
+ umem_dmabuf->last_sg = sg;
+ umem_dmabuf->last_sg_trim = trim;
+ sg_dma_len(sg) -= trim;
+ break;
+ }
+ cur += sg_dma_len(sg);
+ }
+
+ umem_dmabuf->umem.sg_head.s
[PATCH v11 3/4] RDMA/uverbs: Add uverbs command for dma-buf based MR registration
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/uverbs_std_types_mr.c | 114 +-
include/uapi/rdma/ib_user_ioctl_cmds.h| 14
2 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_std_types_mr.c
b/drivers/infiniband/core/uverbs_std_types_mr.c
index 9b22bb5..e9028ea 100644
--- a/drivers/infiniband/core/uverbs_std_types_mr.c
+++ b/drivers/infiniband/core/uverbs_std_types_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -178,6 +179,83 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
return IS_UVERBS_COPY_ERR(ret) ? ret : 0;
}
+static int UVERBS_HANDLER(UVERBS_METHOD_REG_DMABUF_MR)(
+ struct uverbs_attr_bundle *attrs)
+{
+ struct ib_uobject *uobj =
+ uverbs_attr_get_uobject(attrs,
UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ struct ib_pd *pd =
+ uverbs_attr_get_obj(attrs, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE);
+ struct ib_device *ib_dev = pd->device;
+
+ u64 offset, length, virt_addr;
+ u32 fd, access_flags;
+ struct ib_mr *mr;
+ int ret;
+
+ if (!ib_dev->ops.reg_user_mr_dmabuf)
+ return -EOPNOTSUPP;
+
+ ret = uverbs_copy_from(&offset, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_OFFSET);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(&length, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(&virt_addr, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_IOVA);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(&fd, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_FD);
+ if (ret)
+ return ret;
+
+ ret = uverbs_get_flags32(&access_flags, attrs,
+UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+IB_ACCESS_LOCAL_WRITE |
+IB_ACCESS_REMOTE_READ |
+IB_ACCESS_REMOTE_WRITE |
+IB_ACCESS_REMOTE_ATOMIC |
+IB_ACCESS_RELAXED_ORDERING);
+ if (ret)
+ return ret;
+
+ ret = ib_check_mr_access(access_flags);
+ if (ret)
+ return ret;
+
+ mr = pd->device->ops.reg_user_mr_dmabuf(pd, offset, length, virt_addr,
+ fd, access_flags,
+ &attrs->driver_udata);
+ if (IS_ERR(mr))
+ return PTR_ERR(mr);
+
+ mr->device = pd->device;
+ mr->pd = pd;
+ mr->type = IB_MR_TYPE_USER;
+ mr->uobject = uobj;
+ atomic_inc(&pd->usecnt);
+
+ uobj->object = mr;
+
+ uverbs_finalize_uobj_create(attrs, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+
+ ret = uverbs_copy_to(attrs, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+&mr->lkey, sizeof(mr->lkey));
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_to(attrs, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+&mr->rkey, sizeof(mr->rkey));
+ return ret;
+}
+
DECLARE_UVERBS_NAMED_METHOD(
UVERBS_METHOD_ADVISE_MR,
UVERBS_ATTR_IDR(UVERBS_ATTR_ADVISE_MR_PD_HANDLE,
@@ -243,6 +321,37 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
UVERBS_ATTR_TYPE(u32),
UA_MANDATORY));
+DECLARE_UVERBS_NAMED_METHOD(
+ UVERBS_METHOD_REG_DMABUF_MR,
+ UVERBS_ATTR_IDR(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_OBJECT_MR,
+ UVERBS_ACCESS_NEW,
+ UA_MANDATORY),
+ UVERBS_ATTR_IDR(UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_OBJECT_PD,
+ UVERBS_ACCESS_READ,
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_IOVA,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_FD,
+
[PATCH v11 4/4] RDMA/mlx5: Support dma-buf based userspace memory region
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/hw/mlx5/main.c| 2 +
drivers/infiniband/hw/mlx5/mlx5_ib.h | 18 +
drivers/infiniband/hw/mlx5/mr.c | 127 +--
drivers/infiniband/hw/mlx5/odp.c | 86 ++--
4 files changed, 224 insertions(+), 9 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index 36b15a0..e647ea4 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
/*
* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*/
#include
@@ -4055,6 +4056,7 @@ static int mlx5_ib_enable_driver(struct ib_device *dev)
.query_srq = mlx5_ib_query_srq,
.query_ucontext = mlx5_ib_query_ucontext,
.reg_user_mr = mlx5_ib_reg_user_mr,
+ .reg_user_mr_dmabuf = mlx5_ib_reg_user_mr_dmabuf,
.req_notify_cq = mlx5_ib_arm_cq,
.rereg_user_mr = mlx5_ib_rereg_user_mr,
.resize_cq = mlx5_ib_resize_cq,
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index bb44080..3ef6872 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
/*
* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*/
#ifndef MLX5_IB_H
@@ -665,6 +666,12 @@ static inline bool is_odp_mr(struct mlx5_ib_mr *mr)
mr->umem->is_odp;
}
+static inline bool is_dmabuf_mr(struct mlx5_ib_mr *mr)
+{
+ return IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING) && mr->umem &&
+ mr->umem->is_dmabuf;
+}
+
struct mlx5_ib_mw {
struct ib_mwibmw;
struct mlx5_core_mkey mmkey;
@@ -1200,6 +1207,10 @@ int mlx5_ib_create_cq(struct ib_cq *ibcq, const struct
ib_cq_init_attr *attr,
struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
u64 virt_addr, int access_flags,
struct ib_udata *udata);
+struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
+u64 length, u64 virt_addr,
+int fd, int access_flags,
+struct ib_udata *udata);
int mlx5_ib_advise_mr(struct ib_pd *pd,
enum ib_uverbs_advise_mr_advice advice,
u32 flags,
@@ -1210,11 +1221,13 @@ int mlx5_ib_advise_mr(struct ib_pd *pd,
int mlx5_ib_dealloc_mw(struct ib_mw *mw);
int mlx5_ib_update_xlt(struct mlx5_ib_mr *mr, u64 idx, int npages,
int page_shift, int flags);
+int mlx5_ib_update_mr_pas(struct mlx5_ib_mr *mr, unsigned int flags);
struct mlx5_ib_mr *mlx5_ib_alloc_implicit_mr(struct mlx5_ib_pd *pd,
struct ib_udata *udata,
int access_flags);
void mlx5_ib_free_implicit_mr(struct mlx5_ib_mr *mr);
void mlx5_ib_fence_odp_mr(struct mlx5_ib_mr *mr);
+void mlx5_ib_fence_dmabuf_mr(struct mlx5_ib_mr *mr);
int mlx5_ib_rereg_user_mr(struct ib_mr *ib_mr, int flags, u64 start,
u64 length, u64 virt_addr, int access_flags,
struct ib_pd *pd, struct ib_udata *udata);
@@ -1306,6 +1319,7 @@ int mlx5_ib_advise_mr_prefetch(struct ib_pd *pd,
enum ib_uverbs_advise_mr_advice advice,
u32 flags, struct ib_sge *sg_list, u32 num_sge);
int mlx5_ib_init_odp_mr(struct mlx5_ib_mr *mr, bool enable);
+int mlx5_ib_init_dmabuf_mr(struct mlx5_ib_mr *mr);
#else /* CONFIG_INFINIBAND_ON_DEMAND_PAGING */
static inline void mlx5_ib_internal_fill_odp_caps(struct mlx5_ib_dev *dev)
{
@@ -1331,6 +1345,10 @@ static inline int mlx5_ib_init_odp_mr(struct mlx5_ib_mr
*mr, bool enable)
{
return -EOPNOTSUPP;
}
+static inline int mlx5_ib_init_dmabuf_mr(struct mlx5_ib_mr *mr)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_INFINIBAND_ON_DEMAND_PAGING */
extern const struct mmu_interval_notifier_ops mlx5_mn_ops;
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 9f653b4..b7c869c 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2013-2015, Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. A
[PATCH rdma-core 0/5] Add user space dma-buf support
This is the user space counter-part of the kernel patch set to add dma-buf support to the RDMA subsystem. This patch series adds user space API for registering dma-buf based memory regions, updates pyverbs with the new API, and adds new tests. This series consists of five patches. The first patch adds the new API function and updates the man pages. Patch 2 implements the new API in the mlx5 provider. Patch 3 adds new class definitions to pyverbs for the new API. Patch 4 adds new tests for the new API. Patch 5 fixes bug in the utility code of the tests. Jianxin Xiong (5): verbs: Support dma-buf based memory region mlx5: Support dma-buf based memory region pyverbs: Add dma-buf based MR support tests: Add tests for dma-buf based memory regions tests: Bug fix for get_access_flags() kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 libibverbs/cmd_mr.c | 38 + libibverbs/driver.h | 7 ++ libibverbs/dummy_ops.c | 11 +++ libibverbs/libibverbs.map.in | 6 ++ libibverbs/man/ibv_reg_mr.3 | 21 - libibverbs/verbs.c | 19 + libibverbs/verbs.h | 10 +++ providers/mlx5/mlx5.c| 2 + providers/mlx5/mlx5.h| 3 + providers/mlx5/verbs.c | 23 ++ pyverbs/CMakeLists.txt | 2 + pyverbs/dmabuf.pxd | 13 pyverbs/dmabuf.pyx | 58 ++ pyverbs/libibverbs.pxd | 2 + pyverbs/mr.pxd | 5 ++ pyverbs/mr.pyx | 77 +- tests/test_mr.py | 130 ++- tests/utils.py | 31 +++- 19 files changed, 464 insertions(+), 8 deletions(-) create mode 100644 pyverbs/dmabuf.pxd create mode 100644 pyverbs/dmabuf.pyx -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core 1/5] verbs: Support dma-buf based memory region
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14
libibverbs/cmd_mr.c | 38
libibverbs/driver.h | 7 ++
libibverbs/dummy_ops.c | 11 +
libibverbs/libibverbs.map.in | 6 +
libibverbs/man/ibv_reg_mr.3 | 21 --
libibverbs/verbs.c | 19
libibverbs/verbs.h | 10 +
8 files changed, 124 insertions(+), 2 deletions(-)
diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h
b/kernel-headers/rdma/ib_user_ioctl_cmds.h
index 7968a18..dafc7eb 100644
--- a/kernel-headers/rdma/ib_user_ioctl_cmds.h
+++ b/kernel-headers/rdma/ib_user_ioctl_cmds.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -251,6 +252,7 @@ enum uverbs_methods_mr {
UVERBS_METHOD_MR_DESTROY,
UVERBS_METHOD_ADVISE_MR,
UVERBS_METHOD_QUERY_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
};
enum uverbs_attrs_mr_destroy_ids {
@@ -272,6 +274,18 @@ enum uverbs_attrs_query_mr_cmd_attr_ids {
UVERBS_ATTR_QUERY_MR_RESP_IOVA,
};
+enum uverbs_attrs_reg_dmabuf_mr_cmd_attr_ids {
+ UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_REG_DMABUF_MR_IOVA,
+ UVERBS_ATTR_REG_DMABUF_MR_FD,
+ UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+};
+
enum uverbs_attrs_create_counters_cmd_attr_ids {
UVERBS_ATTR_CREATE_COUNTERS_HANDLE,
};
diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
index 42dbe42..91ce2ef 100644
--- a/libibverbs/cmd_mr.c
+++ b/libibverbs/cmd_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018 Mellanox Technologies, Ltd. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -116,3 +117,40 @@ int ibv_cmd_query_mr(struct ibv_pd *pd, struct verbs_mr
*vmr,
return 0;
}
+int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t length,
+ uint64_t iova, int fd, int access,
+ struct verbs_mr *vmr)
+{
+ DECLARE_COMMAND_BUFFER(cmdb, UVERBS_OBJECT_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
+ 9);
+ struct ib_uverbs_attr *handle;
+ uint32_t lkey, rkey;
+ int ret;
+
+ handle = fill_attr_out_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY, &lkey);
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY, &rkey);
+
+ fill_attr_in_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE, pd->handle);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_OFFSET, offset);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_LENGTH, length);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_IOVA, iova);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_FD, fd);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
access);
+
+ ret = execute_ioctl(pd->context, cmdb);
+ if (ret)
+ return errno;
+
+ vmr->ibv_mr.handle =
+ read_attr_obj(UVERBS_ATTR_REG_DMABUF_MR_HANDLE, handle);
+ vmr->ibv_mr.context = pd->context;
+ vmr->ibv_mr.lkey= lkey;
+ vmr->ibv_mr.rkey= rkey;
+ vmr->ibv_mr.pd = pd;
+ vmr->ibv_mr.addr= (void *)offset;
+ vmr->ibv_mr.length = length;
+ vmr->mr_type= IBV_MR_TYPE_MR;
+ return 0;
+}
diff --git a/libibverbs/driver.h b/libibverbs/driver.h
index ab80f4b..d6a9d0a 100644
--- a/libibverbs/driver.h
+++ b/libibverbs/driver.h
@@ -2,6 +2,7 @@
* Copyright (c) 2004, 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005, 2006 Cisco Systems, Inc. All rights reserved.
* Copyright (c) 2005 PathScale, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -373,6 +374,9 @@ struct verbs_context_ops {
struct ibv_mr *(*reg_dm_mr)(struct ibv_pd *pd, struct ibv_dm *dm,
uin
[PATCH rdma-core 2/5] mlx5: Support dma-buf based memory region
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 23 +++
3 files changed, 28 insertions(+)
diff --git a/providers/mlx5/mlx5.c b/providers/mlx5/mlx5.c
index 1378acf..b3e2d57 100644
--- a/providers/mlx5/mlx5.c
+++ b/providers/mlx5/mlx5.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -96,6 +97,7 @@ static const struct verbs_context_ops mlx5_ctx_common_ops = {
.async_event = mlx5_async_event,
.dealloc_pd= mlx5_free_pd,
.reg_mr= mlx5_reg_mr,
+ .reg_dmabuf_mr = mlx5_reg_dmabuf_mr,
.rereg_mr = mlx5_rereg_mr,
.dereg_mr = mlx5_dereg_mr,
.alloc_mw = mlx5_alloc_mw,
diff --git a/providers/mlx5/mlx5.h b/providers/mlx5/mlx5.h
index 8c94f72..17a2470 100644
--- a/providers/mlx5/mlx5.h
+++ b/providers/mlx5/mlx5.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -903,6 +904,8 @@ void mlx5_async_event(struct ibv_context *context,
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd);
struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr, size_t length,
uint64_t hca_va, int access);
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int access);
int mlx5_rereg_mr(struct verbs_mr *mr, int flags, struct ibv_pd *pd, void
*addr,
size_t length, int access);
int mlx5_dereg_mr(struct verbs_mr *mr);
diff --git a/providers/mlx5/verbs.c b/providers/mlx5/verbs.c
index b956156..6279993 100644
--- a/providers/mlx5/verbs.c
+++ b/providers/mlx5/verbs.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -647,6 +648,28 @@ struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr,
size_t length,
return &mr->vmr.ibv_mr;
}
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int acc)
+{
+ struct mlx5_mr *mr;
+ int ret;
+ enum ibv_access_flags access = (enum ibv_access_flags)acc;
+
+ mr = calloc(1, sizeof(*mr));
+ if (!mr)
+ return NULL;
+
+ ret = ibv_cmd_reg_dmabuf_mr(pd, offset, length, iova, fd, access,
+ &mr->vmr);
+ if (ret) {
+ free(mr);
+ return NULL;
+ }
+ mr->alloc_flags = acc;
+
+ return &mr->vmr.ibv_mr;
+}
+
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd)
{
struct mlx5_mr *mr;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core 4/5] tests: Add tests for dma-buf based memory regions
Define a full set of tests similar to regular MR tests. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/test_mr.py | 130 ++-
tests/utils.py | 25 +++
2 files changed, 154 insertions(+), 1 deletion(-)
diff --git a/tests/test_mr.py b/tests/test_mr.py
index adc649c..8d7f002 100644
--- a/tests/test_mr.py
+++ b/tests/test_mr.py
@@ -9,9 +9,10 @@ import errno
from tests.base import PyverbsAPITestCase, RCResources, RDMATestCase
from pyverbs.pyverbs_error import PyverbsRDMAError, PyverbsError
-from pyverbs.mr import MR, MW, DMMR, MWBindInfo, MWBind
+from pyverbs.mr import MR, MW, DMMR, DmaBufMR, MWBindInfo, MWBind
from pyverbs.qp import QPCap, QPInitAttr, QPAttr, QP
from pyverbs.wr import SendWR
+from pyverbs.dmabuf import DmaBuf
import pyverbs.device as d
from pyverbs.pd import PD
import pyverbs.enums as e
@@ -366,3 +367,130 @@ class DMMRTest(PyverbsAPITestCase):
dm_mr = DMMR(pd, dm_mr_len, e.IBV_ACCESS_ZERO_BASED,
dm=dm, offset=dm_mr_offset)
dm_mr.close()
+
+class DmaBufMRTest(PyverbsAPITestCase):
+"""
+Test various functionalities of the DmaBufMR class.
+"""
+def test_dmabuf_reg_mr(self):
+"""
+Test ibv_reg_dmabuf_mr()
+"""
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+off = random.randint(0, len//2)
+with DmaBufMR(pd, len, f, offset=off) as mr:
+pass
+
+def test_dmabuf_dereg_mr(self):
+"""
+Test ibv_dereg_mr() with DmaBufMR
+"""
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+off = random.randint(0, len//2)
+with DmaBufMR(pd, len, f, offset=off) as mr:
+mr.close()
+
+def test_dmabuf_dereg_mr_twice(self):
+"""
+Verify that explicit call to DmaBufMR's close() doesn't fail
+"""
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+off = random.randint(0, len//2)
+with DmaBufMR(pd, len, f, offset=off) as mr:
+# Pyverbs supports multiple destruction of objects,
+# we are not expecting an exception here.
+mr.close()
+mr.close()
+
+def test_dmabuf_reg_mr_bad_flags(self):
+"""
+Verify that illegal flags combination fails as expected
+"""
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+for i in range(5):
+flags = random.sample([e.IBV_ACCESS_REMOTE_WRITE,
+ e.IBV_ACCESS_REMOTE_ATOMIC],
+ random.randint(1, 2))
+mr_flags = 0
+for i in flags:
+mr_flags += i.value
+try:
+DmaBufMR(pd, u.get_mr_length(), mr_flags)
+except PyverbsRDMAError as err:
+assert 'Failed to register a dma-buf MR' in err.args[0]
+else:
+raise PyverbsRDMAError('Registered a dma-buf MR with
illegal falgs')
+
+def test_dmabuf_write(self):
+"""
+Test writing to DmaBufMR's buffer
+"""
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+for i in range(10):
+mr_len = u.get_mr_length()
+mr_off = random.randint(0, mr_len//2)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+with DmaBufMR(pd, mr_len, f, offset=mr_off) as mr:
+write_len = min(random.randint(1, MAX_IO_LEN),
+mr_len)
+mr.write('a' * write_len, write_len)
+
+def test_dmabuf_read(self):
+"""
+Test reading from DmaBufMR's buffer
+"""
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+for i in range(10):
+mr_len = u.get_mr_length()
+mr_off = random.randint(0, mr_len//2)
+flags = u.get_dmabuf_access_flag
[PATCH rdma-core 3/5] pyverbs: Add dma-buf based MR support
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' for dma-buf object allocation.
Signed-off-by: Jianxin Xiong
---
pyverbs/CMakeLists.txt | 2 ++
pyverbs/dmabuf.pxd | 13 +
pyverbs/dmabuf.pyx | 58 +
pyverbs/libibverbs.pxd | 2 ++
pyverbs/mr.pxd | 5
pyverbs/mr.pyx | 77 --
6 files changed, 155 insertions(+), 2 deletions(-)
create mode 100644 pyverbs/dmabuf.pxd
create mode 100644 pyverbs/dmabuf.pyx
diff --git a/pyverbs/CMakeLists.txt b/pyverbs/CMakeLists.txt
index 9542c4b..5aee02b 100644
--- a/pyverbs/CMakeLists.txt
+++ b/pyverbs/CMakeLists.txt
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2019, Mellanox Technologies. All rights reserved. See COPYING
file
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
rdma_cython_module(pyverbs ""
addr.pyx
@@ -16,6 +17,7 @@ rdma_cython_module(pyverbs ""
wr.pyx
xrcd.pyx
srq.pyx
+ dmabuf.pyx
)
rdma_python_module(pyverbs
diff --git a/pyverbs/dmabuf.pxd b/pyverbs/dmabuf.pxd
new file mode 100644
index 000..040db4b
--- /dev/null
+++ b/pyverbs/dmabuf.pxd
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
+
+#cython: language_level=3
+
+cdef class DmaBuf:
+cdef int dri_fd
+cdef int handle
+cdef int fd
+cdef unsigned long size
+cdef unsigned long map_offset
+cdef object dmabuf_mrs
+cdef add_ref(self, obj)
diff --git a/pyverbs/dmabuf.pyx b/pyverbs/dmabuf.pyx
new file mode 100644
index 000..6c7622d
--- /dev/null
+++ b/pyverbs/dmabuf.pyx
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
+
+#cython: language_level=3
+
+import weakref
+
+from os import open, close, O_RDWR
+from fcntl import ioctl
+from struct import pack_into, unpack
+from pyverbs.base cimport close_weakrefs
+from pyverbs.mr cimport DmaBufMR
+
+cdef extern from "drm/drm.h":
+cdef int DRM_IOCTL_MODE_CREATE_DUMB
+cdef int DRM_IOCTL_MODE_MAP_DUMB
+cdef int DRM_IOCTL_MODE_DESTROY_DUMB
+cdef int DRM_IOCTL_PRIME_HANDLE_TO_FD
+
+cdef class DmaBuf:
+def __init__(self, size, unit=0):
+"""
+Allocate DmaBuf object from a GPU device. This is done through the
+DRI device interface (/dev/dri/card*). Usually this requires the
+effective user id being root or being a member of the 'video' group.
+:param size: The size (in number of bytes) of the buffer.
+:param unit: The unit number of the GPU to allocate the buffer from.
+:return: The newly created DmaBuf object on success.
+"""
+self.dmabuf_mrs = weakref.WeakSet()
+self.dri_fd = open('/dev/dri/card'+str(unit), O_RDWR)
+
+args = bytearray(32)
+pack_into('=iiq', args, 0, 1, size, 8, 0, 0, 0, 0)
+ioctl(self.dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, args)
+a, b, c, d, self.handle, e, self.size = unpack('=iiq', args)
+
+args = bytearray(12)
+pack_into('=iii', args, 0, self.handle, O_RDWR, 0)
+ioctl(self.dri_fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, args)
+a, b, self.fd = unpack('=iii', args)
+
+args = bytearray(16)
+pack_into('=iiq', args, 0, self.handle, 0, 0)
+ioctl(self.dri_fd, DRM_IOCTL_MODE_MAP_DUMB, args);
+a, b, self.map_offset = unpack('=iiq', args);
+
+def __dealloc__(self):
+close_weakrefs([self.dmabuf_mrs])
+args = bytearray(4)
+pack_into('=i', args, 0, self.handle)
+ioctl(self.dri_fd, DRM_IOCTL_MODE_DESTROY_DUMB, args)
+close(self.dri_fd)
+
+cdef add_ref(self, obj):
+if isinstance(obj, DmaBufMR):
+self.dmabuf_mrs.add(obj)
+
diff --git a/pyverbs/libibverbs.pxd b/pyverbs/libibverbs.pxd
index 6fbba54..95e51e1 100644
--- a/pyverbs/libibverbs.pxd
+++ b/pyverbs/libibverbs.pxd
@@ -507,6 +507,8 @@ cdef extern from 'infiniband/verbs.h':
ibv_pd *ibv_alloc_pd(ibv_context *context)
int ibv_dealloc_pd(ibv_pd *pd)
ibv_mr *ibv_reg_mr(ibv_pd *pd, void *addr, size_t length, int access)
+ibv_mr *ibv_reg_dmabuf_mr(ibv_pd *pd, uint64_t offset, size_t length,
+ int fd, int access)
int ibv_dereg_mr(ibv_mr *mr)
int ibv_advise_mr(ibv_pd *pd, uint32_t advice, uint32_t flags,
ibv_sge *sg_list, uint32_t num_sge)
diff --git a/pyverbs/mr.pxd b/pyverbs/mr.pxd
index ebe8ada..b89cf02 100644
--- a/pyverbs/mr.pxd
+++ b/pyverbs/mr.pxd
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2019, Mellanox Technologies. All rights reserved. See COPYING
file
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
#cython: language_level=3
@@ -33,3 +34,7 @@ cdef class MW(PyverbsCM
[PATCH rdma-core 5/5] tests: Bug fix for get_access_flags()
The filter defintion is wrong and causes get_access_flags() always returning empty list. As the result the MR tests using this function are effectively skipped (but report success). Also fix a typo in the comments. Signed-off-by: Jianxin Xiong --- tests/utils.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/utils.py b/tests/utils.py index 0ad7110..eee44b4 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -55,8 +55,8 @@ def filter_illegal_access_flags(element): :param element: A list of access flags to check :return: True if this list is legal, else False """ -if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE: -if e.IBV_ACCESS_LOCAL_WRITE: +if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE in element: +if not e.IBV_ACCESS_LOCAL_WRITE in element: return False return True @@ -69,7 +69,7 @@ def get_access_flags(ctx): added as well. After verifying that the flags selection is legal, it is appended to an array, assuming it wasn't previously appended. -:param ctx: Device Context to check capabilities +:param ctx: Device Coyyntext to check capabilities :param num: Size of initial collection :return: A random legal value for MR flags """ -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/6] drm/bridge: cdns-mhdp8546: Fix the interrupt enable/disable
On 19/11/2020 18:01, Nikhil Devshatwar wrote: > When removing the tidss driver, there is a warning reported by > kernel about an unhandled interrupt for mhdp driver. > > [ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option) > ... [snipped backtrace] > [ 43.330735] handlers: > [ 43.333020] [<5367c4f9>] irq_default_primary_handler threaded > [<7e02b601>] > cdns_mhdp_irq_handler [cdns_mhdp8546] > [ 43.344607] Disabling IRQ #31 > > This happens because as part of cdns_mhdp_bridge_hpd_disable, driver tries > to disable the interrupts. While disabling the SW_EVENT interrupts, > it accidentally enables the MBOX interrupts, which are not handled by > the driver. > > Fix this with a read-modify-write to update only required bits. > Use the enable / disable function as required in other places. > > Signed-off-by: Nikhil Devshatwar > Reviewed-by: Swapnil Jakhade Reviewed-by: Tomi Valkeinen I think this is fine as a fix for this issue, but at some point the irq management needs some work. E.g. we call cdns_mhdp_bridge_hpd_enable when attaching/enabling the hw, but also via drm_bridge_funcs->hpd_enable. This doesn't make sense, as one of those calls doesn't achieve anything, as cdns_mhdp_bridge_hpd_enable has already been called. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/cma-helper: Move mmap to object functions
Am 23.11.20 um 13:32 schrieb Maxime Ripard: On Mon, Nov 23, 2020 at 12:56:44PM +0100, Thomas Zimmermann wrote: This patchset moves CMA's mmap into a GEM object function. This change allows for removing CMA's mmap and gem_prime_mmap callbacks in favor of the default implementation. Tested with vc4 on RPi3. For both patches, Acked-by: Maxime Ripard Thanks, Maxime! Maxime -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/10] drm/fb-helper: Call dirty helper after writing to fbdev
On Fri, Nov 20, 2020 at 11:25:36AM +0100, Thomas Zimmermann wrote:
> If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
> the update might not make it to the screen.
>
> v2:
> * mark virtual screen as dirty (Ville)
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 222ec45f4c69 ("drm/fb_helper: Support framebuffers in I/O memory")
> Cc: Thomas Zimmermann
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: dri-devel@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
Acked-by: Sam Ravnborg
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/10] drm/fb-helper: Unmap client buffer during shutdown
On Fri, Nov 20, 2020 at 11:25:37AM +0100, Thomas Zimmermann wrote: > The fbdev helper's generic probe function establishes a mapping for > framebuffers without shadow buffer. The clean-up function did not unmap > the buffer object. Add the unmap operation. > > As fbdev devices are usally released during system shutdown, this has > not been a problem in practice. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 0/8] System Cache support for GPU and required SMMU support
On Mon, Nov 23, 2020 at 9:01 AM Sai Prakash Ranjan wrote: > > On 2020-11-23 20:51, Will Deacon wrote: > > On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote: > >> Some hardware variants contain a system cache or the last level > >> cache(llc). This cache is typically a large block which is shared > >> by multiple clients on the SOC. GPU uses the system cache to cache > >> both the GPU data buffers(like textures) as well the SMMU pagetables. > >> This helps with improved render performance as well as lower power > >> consumption by reducing the bus traffic to the system memory. > >> > >> The system cache architecture allows the cache to be split into slices > >> which then be used by multiple SOC clients. This patch series is an > >> effort to enable and use two of those slices preallocated for the GPU, > >> one for the GPU data buffers and another for the GPU SMMU hardware > >> pagetables. > >> > >> Patch 1 - Patch 6 adds system cache support in SMMU and GPU driver. > >> Patch 7 and 8 are minor cleanups for arm-smmu impl. > >> > >> Changes in v8: > >> * Introduce a generic domain attribute for pagetable config (Will) > >> * Rename quirk to more generic IO_PGTABLE_QUIRK_ARM_OUTER_WBWA (Will) > >> * Move non-strict mode to use new struct domain_attr_io_pgtbl_config > >> (Will) > > > > Modulo some minor comments I've made, this looks good to me. What is > > the > > plan for merging it? I can take the IOMMU parts, but patches 4-6 touch > > the > > MSM GPU driver and I'd like to avoid conflicts with that. > > > > SMMU bits are pretty much independent and GPU relies on the domain > attribute > and the quirk exposed, so as long as SMMU changes go in first it should > be good. > Rob? I suppose one option would be to split out the patch that adds the attribute into it's own patch, and merge that both thru drm and iommu? If Will/Robin dislike that approach, I'll pick up the parts of the drm patches which don't depend on the new attribute for v5.11 and the rest for v5.12.. or possibly a second late v5.11 pull req if airlied doesn't hate me too much for it. Going forward, I think we will have one or two more co-dependent series, like the smmu iova fault handler improvements that Jordan posted. So I would like to hear how Will and Robin prefer to handle those. BR, -R > Thanks, > Sai > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a > member > of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/10] drm/fb-helper: Rename dirty worker to damage worker
On Fri, Nov 20, 2020 at 11:25:39AM +0100, Thomas Zimmermann wrote: > The dirty worker handles all damage updates, instead of just calling > the framebuffer's dirty callback. Rename it to damage worker. Also > rename related variables accordingly. No functional changes are made. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg It had been nice to move to inline comments in struct drm_fb_helper_funcs but that can be another day. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/10] drm/fb-helper: Return early in dirty worker
On Fri, Nov 20, 2020 at 11:25:40AM +0100, Thomas Zimmermann wrote:
> Returning early in the dirty worker if no update is required makes the
> code more readable. No functional changes are made.
>
> Signed-off-by: Thomas Zimmermann
It is a damage worker (both subject and changelog).
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_fb_helper.c | 31 +++
> 1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 87d4759de04a..c90185f9 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -407,24 +407,23 @@ static void drm_fb_helper_damage_work(struct
> work_struct *work)
> clip->x2 = clip->y2 = 0;
> spin_unlock_irqrestore(&helper->damage_lock, flags);
>
> - /* call dirty callback only when it has been really touched */
> - if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) {
> -
> - /* Generic fbdev uses a shadow buffer */
> - if (helper->buffer) {
> - ret = drm_client_buffer_vmap(helper->buffer, &map);
> - if (ret)
> - return;
> - drm_fb_helper_damage_blit_real(helper, &clip_copy,
> &map);
> - }
> -
> - if (helper->fb->funcs->dirty)
> - helper->fb->funcs->dirty(helper->fb, NULL, 0, 0,
> - &clip_copy, 1);
> + /* Call damage handlers only if necessary */
> + if (!(clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2))
> + return;
>
> - if (helper->buffer)
> - drm_client_buffer_vunmap(helper->buffer);
> + /* Generic fbdev uses a shadow buffer */
> + if (helper->buffer) {
> + ret = drm_client_buffer_vmap(helper->buffer, &map);
> + if (ret)
> + return;
> + drm_fb_helper_damage_blit_real(helper, &clip_copy, &map);
> }
> +
> + if (helper->fb->funcs->dirty)
> + helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> +
> + if (helper->buffer)
> + drm_client_buffer_vunmap(helper->buffer);
> }
>
> /**
> --
> 2.29.2
>
> ___
> 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 v2 06/10] drm/fb-helper: Separate shadow-buffer flushing and calling dirty callback
On Fri, Nov 20, 2020 at 11:25:41AM +0100, Thomas Zimmermann wrote: > Flushing the shadow framebuffer and invoking the dirty callback are two > separate operations, so do them seprately. The flush operation is paired > with calls to vmap and vunmap. They are not needed for the dirty callback, > which performs its own invocations if necessary. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/10] drm/fb-helper: Move damage blit code and its setup into separate routine
On Fri, Nov 20, 2020 at 11:25:42AM +0100, Thomas Zimmermann wrote: > Introduce a separate function for the blit code and its vmap setup. Done > in preparation of additional changes. No functional changes are made. > > v2: > * print a single warning if damage blitter fails > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/10] drm/fb-helper: Restore damage area upon errors
On Fri, Nov 20, 2020 at 11:25:43AM +0100, Thomas Zimmermann wrote: > If the damage handling fails, restore the damage area. The next invocation > of the damage worker will then perform the update. > > v2: > * print a single warning if dirty callback fails (Daniel, Sebastian) > * update comment > > Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/10] drm/fb-helper: Copy dma-buf map before flushing shadow fb
On Fri, Nov 20, 2020 at 11:25:44AM +0100, Thomas Zimmermann wrote: > Copy the vmap()'ed instance of struct dma_buf_map before modifying it, > in case the implementation of vunmap() depends on the exact address. > > Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] drm/fb-helper: Acquire modeset lock around shadow-buffer flushing
On Fri, Nov 20, 2020 at 11:25:45AM +0100, Thomas Zimmermann wrote: > Flushing the fbdev's shadow buffer requires vmap'ing the BO memory, which > in turn requires pinning the BO. While being pinned, the BO cannot be moved > into VRAM for scanout. Consequently, a concurrent modeset operation that > involves the fbdev framebuffer would likely fail. > > Resolve this problem be acquiring the modeset lock of the planes that use > the fbdev framebuffer. On non-atomic drivers, also acquire the mode-config > lock. This serializes the flushing of the framebuffer with concurrent > modeset operations. > > v2: > * only acquire struct drm_fb_helper.lock in damage blitter (Daniel, > Christian) > > Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH rdma-core 2/5] mlx5: Support dma-buf based memory region
> -Original Message-
> From: Jason Gunthorpe
> Sent: Monday, November 23, 2020 10:02 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH rdma-core 2/5] mlx5: Support dma-buf based memory region
>
> On Mon, Nov 23, 2020 at 09:53:01AM -0800, Jianxin Xiong wrote:
>
> > +struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset,
> > size_t length,
> > + uint64_t iova, int fd, int acc) {
> > + struct mlx5_mr *mr;
> > + int ret;
> > + enum ibv_access_flags access = (enum ibv_access_flags)acc;
>
> Why?
It's copied from mlx5_reg_mr(). Didn't pay attention to this but looks
unnecessary now.
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH rdma-core 3/5] pyverbs: Add dma-buf based MR support
> -Original Message-
> From: Jason Gunthorpe
> Sent: Monday, November 23, 2020 10:05 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH rdma-core 3/5] pyverbs: Add dma-buf based MR support
>
> On Mon, Nov 23, 2020 at 09:53:02AM -0800, Jianxin Xiong wrote:
>
> > +cdef class DmaBuf:
> > +def __init__(self, size, unit=0):
> > +"""
> > +Allocate DmaBuf object from a GPU device. This is done through the
> > +DRI device interface (/dev/dri/card*). Usually this requires the
> > +effective user id being root or being a member of the 'video'
> > group.
> > +:param size: The size (in number of bytes) of the buffer.
> > +:param unit: The unit number of the GPU to allocate the buffer
> > from.
> > +:return: The newly created DmaBuf object on success.
> > +"""
> > +self.dmabuf_mrs = weakref.WeakSet()
> > +self.dri_fd = open('/dev/dri/card'+str(unit), O_RDWR)
> > +
> > +args = bytearray(32)
> > +pack_into('=iiq', args, 0, 1, size, 8, 0, 0, 0, 0)
> > +ioctl(self.dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, args)
> > +a, b, c, d, self.handle, e, self.size = unpack('=iiq',
> > + args)
> > +
> > +args = bytearray(12)
> > +pack_into('=iii', args, 0, self.handle, O_RDWR, 0)
> > +ioctl(self.dri_fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, args)
> > +a, b, self.fd = unpack('=iii', args)
> > +
> > +args = bytearray(16)
> > +pack_into('=iiq', args, 0, self.handle, 0, 0)
> > +ioctl(self.dri_fd, DRM_IOCTL_MODE_MAP_DUMB, args);
> > +a, b, self.map_offset = unpack('=iiq', args);
>
> Wow, OK
>
> Is it worth using ctypes here instead? Can you at least add a comment before
> each pack specifying the 'struct XXX' this is following?
>
The ioctl call only accept a bytearray, not sure how to use ctypes here. I will
add
comments with the actual layout of the parameter structure.
> Does this work with normal Intel GPUs, like in a Laptop? AMD too?
>
Yes, the interface is generic and works with most GPUs. Works with AMD, too.
> Christian, I would be very happy to hear from you that this entire work is
> good for AMD as well
>
> Edward should look through this, but I'm glad to see something like this
>
> Thanks,
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On 11/25/20 5:42 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: It's needed to drop iommu backed pages on device unplug before device's IOMMU group is released. It would be cleaner if we could do the whole handling in TTM. I also need to double check what you are doing with this function. Christian. Check patch "drm/amdgpu: Register IOMMU topology notifier per device." to see how i use it. I don't see why this should go into TTM mid-layer - the stuff I do inside is vendor specific and also I don't think TTM is explicitly aware of IOMMU ? Do you mean you prefer the IOMMU notifier to be registered from within TTM and then use a hook to call into vendor specific handler ? Andrey Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/ttm/ttm_tt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 1ccf1ef..29248a5 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -495,3 +495,4 @@ void ttm_tt_unpopulate(struct ttm_tt *ttm) else ttm_pool_unpopulate(ttm); } +EXPORT_SYMBOL(ttm_tt_unpopulate); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky: On 11/25/20 5:42 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: It's needed to drop iommu backed pages on device unplug before device's IOMMU group is released. It would be cleaner if we could do the whole handling in TTM. I also need to double check what you are doing with this function. Christian. Check patch "drm/amdgpu: Register IOMMU topology notifier per device." to see how i use it. I don't see why this should go into TTM mid-layer - the stuff I do inside is vendor specific and also I don't think TTM is explicitly aware of IOMMU ? Do you mean you prefer the IOMMU notifier to be registered from within TTM and then use a hook to call into vendor specific handler ? No, that is really vendor specific. What I meant is to have a function like ttm_resource_manager_evict_all() which you only need to call and all tt objects are unpopulated. Give me a day or two to look into this. Christian. Andrey Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/ttm/ttm_tt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 1ccf1ef..29248a5 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -495,3 +495,4 @@ void ttm_tt_unpopulate(struct ttm_tt *ttm) else ttm_pool_unpopulate(ttm); } +EXPORT_SYMBOL(ttm_tt_unpopulate); ___ 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 000/141] Fix fall-through warnings for Clang
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote: > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley > wrote: > > Well, I used git. It says that as of today in Linus' tree we have > > 889 patches related to fall throughs and the first series went in > > in october 2017 ... ignoring a couple of outliers back to February. > > I can see ~10k insertions over ~1k commits and 15 years that mention > a fallthrough in the entire repo. That is including some commits > (like the biggest one, 960 insertions) that have nothing to do with C > fallthrough. A single kernel release has an order of magnitude more > changes than this... > > But if we do the math, for an author, at even 1 minute per line > change and assuming nothing can be automated at all, it would take 1 > month of work. For maintainers, a couple of trivial lines is noise > compared to many other patches. So you think a one line patch should take one minute to produce ... I really don't think that's grounded in reality. I suppose a one line patch only takes a minute to merge with b4 if no-one reviews or tests it, but that's not really desirable. > In fact, this discussion probably took more time than the time it > would take to review the 200 lines. :-) I'm framing the discussion in terms of the whole series of changes we have done for fall through, both what's in the tree currently (889 patches) both in terms of the produce and the consumer. That's what I used for my figures for cost. > > We're also complaining about the inability to recruit maintainers: > > > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > > > And burn out: > > > > http://antirez.com/news/129 > > Accepting trivial and useful 1-line patches Part of what I'm trying to measure is the "and useful" bit because that's not a given. > is not what makes a voluntary maintainer quit... so the proverb "straw which broke the camel's back" uniquely doesn't apply to maintainers > Thankless work with demanding deadlines is. That's another potential reason, but it doesn't may other reasons less valid. > > The whole crux of your argument seems to be maintainers' time isn't > > important so we should accept all trivial patches > > I have not said that, at all. In fact, I am a voluntary one and I > welcome patches like this. It takes very little effort on my side to > review and it helps the kernel overall. Well, you know, subsystems are very different in terms of the amount of patches a maintainer has to process per release cycle of the kernel. If a maintainer is close to capacity, additional patches, however trivial, become a problem. If a maintainer has spare cycles, trivial patches may look easy. > Paid maintainers are the ones that can take care of big > features/reviews. > > > What I'm actually trying to articulate is a way of measuring value > > of the patch vs cost ... it has nothing really to do with who foots > > the actual bill. > > I understand your point, but you were the one putting it in terms of > a junior FTE. No, I evaluated the producer side in terms of an FTE. What we're mostly arguing about here is the consumer side: the maintainers and people who have to rework their patch sets. I estimated that at 100h. > In my view, 1 month-work (worst case) is very much worth > removing a class of errors from a critical codebase. > > > One thesis I'm actually starting to formulate is that this > > continual devaluing of maintainers is why we have so much > > difficulty keeping and recruiting them. > > That may very well be true, but I don't feel anybody has devalued > maintainers in this discussion. You seem to be saying that because you find it easy to merge trivial patches, everyone should. I'm reminded of a friend long ago who thought being a Tees River Pilot was a sinecure because he could navigate the Tees blindfold. What he forgot, of course, is that just because it's easy with a trawler doesn't mean it's easy with an oil tanker. In fact it takes longer to qualify as a Tees River Pilot than it does to get a PhD. James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On 11/23/20 3:20 PM, Christian König wrote: Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky: On 11/25/20 5:42 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: It's needed to drop iommu backed pages on device unplug before device's IOMMU group is released. It would be cleaner if we could do the whole handling in TTM. I also need to double check what you are doing with this function. Christian. Check patch "drm/amdgpu: Register IOMMU topology notifier per device." to see how i use it. I don't see why this should go into TTM mid-layer - the stuff I do inside is vendor specific and also I don't think TTM is explicitly aware of IOMMU ? Do you mean you prefer the IOMMU notifier to be registered from within TTM and then use a hook to call into vendor specific handler ? No, that is really vendor specific. What I meant is to have a function like ttm_resource_manager_evict_all() which you only need to call and all tt objects are unpopulated. So instead of this BO list i create and later iterate in amdgpu from the IOMMU patch you just want to do it within TTM with a single function ? Makes much more sense. Andrey Give me a day or two to look into this. Christian. Andrey Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/ttm/ttm_tt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 1ccf1ef..29248a5 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -495,3 +495,4 @@ void ttm_tt_unpopulate(struct ttm_tt *ttm) else ttm_pool_unpopulate(ttm); } +EXPORT_SYMBOL(ttm_tt_unpopulate); ___ 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%7CAndrey.Grodzovsky%40amd.com%7C9be029f26a4746347a6108d88fed299b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637417596065559955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tZ3do%2FeKzBtRlNaFbBjCtRvUHKdvwDZ7SoYhEBu4%2BT8%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote: > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > add multiple break/goto/return/fallthrough statements instead of just > letting the code fall through to the next case. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/1] regulator: as3722: Fix fall-through warnings for Clang commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky: On 11/23/20 3:20 PM, Christian König wrote: Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky: On 11/25/20 5:42 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: It's needed to drop iommu backed pages on device unplug before device's IOMMU group is released. It would be cleaner if we could do the whole handling in TTM. I also need to double check what you are doing with this function. Christian. Check patch "drm/amdgpu: Register IOMMU topology notifier per device." to see how i use it. I don't see why this should go into TTM mid-layer - the stuff I do inside is vendor specific and also I don't think TTM is explicitly aware of IOMMU ? Do you mean you prefer the IOMMU notifier to be registered from within TTM and then use a hook to call into vendor specific handler ? No, that is really vendor specific. What I meant is to have a function like ttm_resource_manager_evict_all() which you only need to call and all tt objects are unpopulated. So instead of this BO list i create and later iterate in amdgpu from the IOMMU patch you just want to do it within TTM with a single function ? Makes much more sense. Yes, exactly. The list_empty() checks we have in TTM for the LRU are actually not the best idea, we should now check the pin_count instead. This way we could also have a list of the pinned BOs in TTM. BTW: Have you thought about what happens when we unpopulate a BO while we still try to use a kernel mapping for it? That could have unforeseen consequences. Christian. Andrey Give me a day or two to look into this. Christian. Andrey Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/ttm/ttm_tt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 1ccf1ef..29248a5 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -495,3 +495,4 @@ void ttm_tt_unpopulate(struct ttm_tt *ttm) else ttm_pool_unpopulate(ttm); } +EXPORT_SYMBOL(ttm_tt_unpopulate); ___ 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%7CAndrey.Grodzovsky%40amd.com%7C9be029f26a4746347a6108d88fed299b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637417596065559955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tZ3do%2FeKzBtRlNaFbBjCtRvUHKdvwDZ7SoYhEBu4%2BT8%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: panel-simple-dsi: add Khadas TS050 panel bindings
On Mon, Nov 23, 2020 at 03:33:53PM +0100, Neil Armstrong wrote: > This add the bindings for the Khadas TS050 1080x1920 5" LCD DSI panel > designed to work > with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers. > > Signed-off-by: Neil Armstrong Reviewed-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203905] amdgpu:actual_brightness has unreal/wrong value
https://bugzilla.kernel.org/show_bug.cgi?id=203905 Germán Ríos González (german.rios.gonza...@gmail.com) changed: What|Removed |Added CC||german.rios.gonzalez@gmail. ||com --- Comment #18 from Germán Ríos González (german.rios.gonza...@gmail.com) --- (In reply to Xia Mu from comment #14) > The bug should be fixed in 5.9.0-0.rc3. I tested it on my laptop with AMD > Ryzen 7 PRO 4750U CPU with Renoir GPU. I'm actually using 5.9.9-200.fc33.x86_64 and the problem it's still there -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: panel: add Khadas TS050 panel driver
Hi Neil.
Looks good but a few comments in the following that needs some attention.
Sam
On Mon, Nov 23, 2020 at 03:33:54PM +0100, Neil Armstrong wrote:
> This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to
> work
> with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
> It provides a MIPI DSI interface to the host, a built-in LED backlight
> and touch controller.
>
> The init values was taken from the vendor source tree, comments were added to
> the
> know values but most of the init table is undocumented.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/panel/Kconfig | 11 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-khadas-ts050.c | 876 +
> 3 files changed, 888 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index b4e021ea30f9..8fec45b2ce02 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -145,6 +145,17 @@ config DRM_PANEL_JDI_LT070ME05000
> The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
> 24 bit per pixel.
>
> +config DRM_PANEL_KHADAS_TS050
> + tristate "Khadas TS050 panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for Khadas TS050 TFT-LCD
> + panel module. The panel has a 1080x1920 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host, a built-in LED backlight and touch controller.
> +
> config DRM_PANEL_KINGDISPLAY_KD097D04
> tristate "Kingdisplay kd097d04 panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index ebbf488c7eac..03496695e03f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) +=
> panel-ilitek-ili9322.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
> obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
> obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
> +obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
> obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
> obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
> obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
> diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c
> b/drivers/gpu/drm/panel/panel-khadas-ts050.c
> new file mode 100644
> index ..856fcad69306
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
> @@ -0,0 +1,876 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Panels do not use DRM_ or drm_ for logging, so this include is not
needed.
> +
> +struct khadas_ts050_panel {
> + struct drm_panel base;
> + struct mipi_dsi_device *link;
> +
> + struct regulator *supply;
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *enable_gpio;
> +
> + bool prepared;
> + bool enabled;
> +};
> +
> +struct khadas_ts050_panel_cmd {
> + u8 cmd;
> + u8 data;
> +};
> +
> +/* Only the CMD1 User Command set is documented */
> +static const struct khadas_ts050_panel_cmd init_code[] = {
> + /* Select Unknown CMD Page (Undocumented) */
> + {0xff, 0xee},
...
> + {0xd4, 0x04}, /* RGBMIPICTRL: VSYNC front porch = 4 */
> +};
> +
> +static inline
> +struct khadas_ts050_panel *to_khadas_ts050_panel(struct drm_panel *panel)
> +{
> + return container_of(panel, struct khadas_ts050_panel, base);
> +}
> +
> +static int khadas_ts050_panel_prepare(struct drm_panel *panel)
> +{
> + struct khadas_ts050_panel *khadas_ts050 = to_khadas_ts050_panel(panel);
> + int err, regulator_err;
> + unsigned int i;
> +
> + if (khadas_ts050->prepared)
> + return 0;
> +
> + gpiod_set_value_cansleep(khadas_ts050->enable_gpio, 0);
> +
> + err = regulator_enable(khadas_ts050->supply);
> + if (err < 0)
> + return err;
> +
> + gpiod_set_value_cansleep(khadas_ts050->enable_gpio, 1);
> +
> + msleep(60);
> +
> + gpiod_set_value_cansleep(khadas_ts050->reset_gpio, 1);
> +
> + usleep_range(1, 11000);
> +
> + gpiod_set_value_cansleep(khadas_ts050->reset_gpio, 0);
> +
> + /* Select CMD2 page 4 (Undocumented) */
> + mipi_dsi_dcs_write(khadas_ts050->link, 0xff, (u8[]){ 0x05 }, 1);
> +
> + /* Reload CMD1: Don't reload default value to register */
> + mipi_dsi_dcs_write(khadas_ts050->link,
Re: [Freedreno] [PATCH 11/40] drm/msm/disp/dpu1/dpu_hw_blk: Add one missing and remove an extra param description
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c:28: warning: Function
parameter or member 'hw_blk' not described in 'dpu_hw_blk_init'
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c:120: warning: Excess
function parameter 'free_blk' description in 'dpu_hw_blk_put'
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
index ca2d2af91..819b26e660b9c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
@@ -19,6 +19,7 @@ static LIST_HEAD(dpu_hw_blk_list);
/**
* dpu_hw_blk_init - initialize hw block object
+ * @hw_blk: pointer to hw block object
* @type: hw block type - enum dpu_hw_blk_type
* @id: instance id of the hw block
* @ops: Pointer to block operations
@@ -114,7 +115,6 @@ struct dpu_hw_blk *dpu_hw_blk_get(struct
dpu_hw_blk *hw_blk, u32 type, int id)
/**
* dpu_hw_blk_put - put hw_blk to free pool if decremented refcount is
zero
* @hw_blk: hw block to be freed
- * @free_blk: function to be called when reference count goes to zero
*/
void dpu_hw_blk_put(struct dpu_hw_blk *hw_blk)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 13/40] drm/msm/disp/dpu1/dpu_hw_catalog: Remove duplicated initialisation of 'max_linewidth'
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:124:19: warning:
initialized field overwritten [-Woverride-init]
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:124:19: note: (near
initialization for ‘sm8250_dpu_caps.max_linewidth’)
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 6a6a7172e3beb..a7004f18523b0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -113,7 +113,6 @@ static const struct dpu_caps sm8150_dpu_caps = {
static const struct dpu_caps sm8250_dpu_caps = {
.max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.max_mixer_blendstages = 0xb,
- .max_linewidth = 4096,
.qseed_type = DPU_SSPP_SCALER_QSEED3, /* TODO: qseed3 lite */
.smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
.ubwc_version = DPU_HW_UBWC_VER_40,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 12/40] drm/msm/disp/dpu1/dpu_formats: Demote non-conformant kernel-doc header
On 2020-11-23 03:18, Lee Jones wrote: Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'fmt' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'a' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'r' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'g' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'b' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'e0' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'e1' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'e2' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'e3' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'uc' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'alpha' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'bp' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'flg' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'fm' not described in 'INTERLEAVED_RGB_FMT' drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function parameter or member 'np' not described in 'INTERLEAVED_RGB_FMT' Cc: Rob Clark Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Fritz Koenig Cc: linux-arm-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Lee Jones Reviewed-by: Abhinav Kumar --- drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c index a05282dede91b..21ff8f9e5dfd1 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c @@ -22,7 +22,7 @@ #define DPU_MAX_IMG_WIDTH 0x3FFF #define DPU_MAX_IMG_HEIGHT 0x3FFF -/** +/* * DPU supported format packing, bpp, and other format * information. * DPU currently only supports interleaved RGB formats ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On 11/23/20 3:41 PM, Christian König wrote: Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky: On 11/23/20 3:20 PM, Christian König wrote: Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky: On 11/25/20 5:42 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: It's needed to drop iommu backed pages on device unplug before device's IOMMU group is released. It would be cleaner if we could do the whole handling in TTM. I also need to double check what you are doing with this function. Christian. Check patch "drm/amdgpu: Register IOMMU topology notifier per device." to see how i use it. I don't see why this should go into TTM mid-layer - the stuff I do inside is vendor specific and also I don't think TTM is explicitly aware of IOMMU ? Do you mean you prefer the IOMMU notifier to be registered from within TTM and then use a hook to call into vendor specific handler ? No, that is really vendor specific. What I meant is to have a function like ttm_resource_manager_evict_all() which you only need to call and all tt objects are unpopulated. So instead of this BO list i create and later iterate in amdgpu from the IOMMU patch you just want to do it within TTM with a single function ? Makes much more sense. Yes, exactly. The list_empty() checks we have in TTM for the LRU are actually not the best idea, we should now check the pin_count instead. This way we could also have a list of the pinned BOs in TTM. So from my IOMMU topology handler I will iterate the TTM LRU for the unpinned BOs and this new function for the pinned ones ? It's probably a good idea to combine both iterations into this new function to cover all the BOs allocated on the device. BTW: Have you thought about what happens when we unpopulate a BO while we still try to use a kernel mapping for it? That could have unforeseen consequences. Are you asking what happens to kmap or vmap style mapped CPU accesses once we drop all the DMA backing pages for a particular BO ? Because for user mappings (mmap) we took care of this with dummy page reroute but indeed nothing was done for in kernel CPU mappings. Andrey Christian. Andrey Give me a day or two to look into this. Christian. Andrey Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/ttm/ttm_tt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 1ccf1ef..29248a5 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -495,3 +495,4 @@ void ttm_tt_unpopulate(struct ttm_tt *ttm) else ttm_pool_unpopulate(ttm); } +EXPORT_SYMBOL(ttm_tt_unpopulate); ___ 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%7CAndrey.Grodzovsky%40amd.com%7C9be029f26a4746347a6108d88fed299b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637417596065559955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tZ3do%2FeKzBtRlNaFbBjCtRvUHKdvwDZ7SoYhEBu4%2BT8%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 18/40] drm/msm/disp/dpu1/dpu_encoder: Fix a few parameter/member formatting issues
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:207: warning: Function
parameter or member 'cur_slave' not described in 'dpu_encoder_virt'
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:207: warning: Function
parameter or member 'hw_pp' not described in 'dpu_encoder_virt'
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:207: warning: Function
parameter or member 'intfs_swapped' not described in
'dpu_encoder_virt'
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1445: warning: Function
parameter or member 'drm_enc' not described in
'_dpu_encoder_trigger_flush'
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1445: warning: Function
parameter or member 'phys' not described in
'_dpu_encoder_trigger_flush'
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1445: warning: Function
parameter or member 'extra_flush_bits' not described in
'_dpu_encoder_trigger_flush'
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1481: warning: Function
parameter or member 'phys' not described in
'_dpu_encoder_trigger_start'
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1564: warning: Function
parameter or member 'dpu_enc' not described in
'_dpu_encoder_kickoff_phys'
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 289bfb6f1861c..288e95ee8e1d5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -132,9 +132,10 @@ enum dpu_enc_rc_states {
* @phys_encs: Container of physical encoders managed.
* @cur_master: Pointer to the current master in this mode.
Optimization
* Only valid after enable. Cleared as disable.
- * @hw_pp Handle to the pingpong blocks used for the display. No.
+ * @cur_slave: As above but for the slave encoder.
+ * @hw_pp: Handle to the pingpong blocks used for the display. No.
* pingpong blocks can be different than num_phys_encs.
- * @intfs_swapped Whether or not the phys_enc interfaces have been
swapped
+ * @intfs_swapped: Whether or not the phys_enc interfaces have been
swapped
* for partial update right-only cases, such as pingpong
* split where virtual pingpong does not generate IRQs
* @crtc: Pointer to the currently assigned crtc. Normally you
@@ -1436,9 +1437,9 @@ static void dpu_encoder_off_work(struct
work_struct *work)
/**
* _dpu_encoder_trigger_flush - trigger flush for a physical encoder
- * drm_enc: Pointer to drm encoder structure
- * phys: Pointer to physical encoder structure
- * extra_flush_bits: Additional bit mask to include in flush trigger
+ * @drm_enc: Pointer to drm encoder structure
+ * @phys: Pointer to physical encoder structure
+ * @extra_flush_bits: Additional bit mask to include in flush trigger
*/
static void _dpu_encoder_trigger_flush(struct drm_encoder *drm_enc,
struct dpu_encoder_phys *phys, uint32_t extra_flush_bits)
@@ -1475,7 +1476,7 @@ static void _dpu_encoder_trigger_flush(struct
drm_encoder *drm_enc,
/**
* _dpu_encoder_trigger_start - trigger start for a physical encoder
- * phys: Pointer to physical encoder structure
+ * @phys: Pointer to physical encoder structure
*/
static void _dpu_encoder_trigger_start(struct dpu_encoder_phys *phys)
{
@@ -1558,7 +1559,7 @@ static void dpu_encoder_helper_hw_reset(struct
dpu_encoder_phys *phys_enc)
* encoder rather than the individual physical ones in order to handle
* use cases that require visibility into multiple physical encoders
at
* a time.
- * dpu_enc: Pointer to virtual encoder structure
+ * @dpu_enc: Pointer to virtual encoder structure
*/
static void _dpu_encoder_kickoff_phys(struct dpu_encoder_virt
*dpu_enc)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 10/40] drm/msm/disp/dpu1/dpu_core_perf: Fix kernel-doc formatting issues
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:31: warning: Enum value
'DPU_PERF_MODE_MAX' not described in enum 'dpu_perf_mode'
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:34: warning: Cannot
understand * @_dpu_core_perf_calc_bw() - to calculate BW per crtc
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:73: warning: Function
parameter or member 'kms' not described in '_dpu_core_perf_calc_clk'
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:73: warning: Function
parameter or member 'crtc' not described in '_dpu_core_perf_calc_clk'
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:73: warning: Function
parameter or member 'state' not described in '_dpu_core_perf_calc_clk'
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:249: warning: Cannot
understand * @dpu_core_perf_crtc_release_bw() - request zero
bandwidth
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Kalyan Thota
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 36927fc04a388..b6b3bbab03336 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -22,6 +22,7 @@
* @DPU_PERF_MODE_NORMAL: performance controlled by user mode client
* @DPU_PERF_MODE_MINIMUM: performance bounded by minimum setting
* @DPU_PERF_MODE_FIXED: performance bounded by fixed setting
+ * @DPU_PERF_MODE_MAX: maximum value, used for error checking
*/
enum dpu_perf_mode {
DPU_PERF_MODE_NORMAL,
@@ -31,9 +32,9 @@ enum dpu_perf_mode {
};
/**
- * @_dpu_core_perf_calc_bw() - to calculate BW per crtc
- * @kms - pointer to the dpu_kms
- * @crtc - pointer to a crtc
+ * _dpu_core_perf_calc_bw() - to calculate BW per crtc
+ * @kms: pointer to the dpu_kms
+ * @crtc: pointer to a crtc
* Return: returns aggregated BW for all planes in crtc.
*/
static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
@@ -63,9 +64,9 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms
*kms,
/**
* _dpu_core_perf_calc_clk() - to calculate clock per crtc
- * @kms - pointer to the dpu_kms
- * @crtc - pointer to a crtc
- * @state - pointer to a crtc state
+ * @kms: pointer to the dpu_kms
+ * @crtc: pointer to a crtc
+ * @state: pointer to a crtc state
* Return: returns max clk for all planes in crtc.
*/
static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
@@ -246,8 +247,8 @@ static int _dpu_core_perf_crtc_update_bus(struct
dpu_kms *kms,
}
/**
- * @dpu_core_perf_crtc_release_bw() - request zero bandwidth
- * @crtc - pointer to a crtc
+ * dpu_core_perf_crtc_release_bw() - request zero bandwidth
+ * @crtc: pointer to a crtc
*
* Function checks a state variable for the crtc, if all pending
commit
* requests are done, meaning no more bandwidth is needed, release
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 20/40] drm/msm/disp/dpu1/dpu_hw_sspp: Fix kernel-doc formatting abuse
On 2020-11-23 03:18, Lee Jones wrote: Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function parameter or member 'ctx' not described in 'dpu_hw_sspp_setup_format' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function parameter or member 'fmt' not described in 'dpu_hw_sspp_setup_format' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function parameter or member 'flags' not described in 'dpu_hw_sspp_setup_format' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function parameter or member 'rect_mode' not described in 'dpu_hw_sspp_setup_format' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:446: warning: Function parameter or member 'ctx' not described in 'dpu_hw_sspp_setup_rects' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:446: warning: Function parameter or member 'cfg' not described in 'dpu_hw_sspp_setup_rects' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:446: warning: Function parameter or member 'rect_index' not described in 'dpu_hw_sspp_setup_rects' Cc: Rob Clark Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Jonathan Marek Cc: linux-arm-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Lee Jones Reviewed-by: Abhinav Kumar --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c index c940b69435e16..2c2ca5335aa8c 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c @@ -231,7 +231,7 @@ static void _sspp_setup_csc10_opmode(struct dpu_hw_pipe *ctx, DPU_REG_WRITE(&ctx->hw, SSPP_VIG_CSC_10_OP_MODE + idx, opmode); } -/** +/* * Setup source pixel format, flip, */ static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe *ctx, @@ -437,7 +437,7 @@ static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_pipe *ctx) return dpu_hw_get_scaler3_ver(&ctx->hw, idx); } -/** +/* * dpu_hw_sspp_setup_rects() */ static void dpu_hw_sspp_setup_rects(struct dpu_hw_pipe *ctx, ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
