[PATCH] drm/bridge: anx7625: Use common macros for DP power sequencing commands
The DRM DP code has macros for the DP power sequencing commands. Use
them in the anx7625 driver instead of raw numbers.
Fixes: 548b512e144f ("drm/bridge: anx7625: send DPCD command to downstream")
Fixes: 27f26359de9b ("drm/bridge: anx7625: Set downstream sink into normal
status")
Signed-off-by: Chen-Yu Tsai
---
This is a minor cleanup. No functional changes.
drivers/gpu/drm/bridge/analogix/anx7625.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 808dbf79d209..7e1fb93a6ce4 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -935,8 +935,8 @@ static void anx7625_dp_start(struct anx7625_data *ctx)
dev_dbg(dev, "set downstream sink into normal\n");
/* Downstream sink enter into normal mode */
- data = 1;
- ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, &data);
+ data = DP_SET_POWER_D0;
+ ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, DP_SET_POWER, 1,
&data);
if (ret < 0)
dev_err(dev, "IO error : set sink into normal mode fail\n");
@@ -975,8 +975,8 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
dev_dbg(dev, "notify downstream enter into standby\n");
/* Downstream monitor enter into standby mode */
- data = 2;
- ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, &data);
+ data = DP_SET_POWER_D3;
+ ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, DP_SET_POWER, 1,
&data);
if (ret < 0)
DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
--
2.39.0.314.g84b9a713c41-goog
[PATCH] drm/bridge: anx7625: Drop device lock before drm_helper_hpd_irq_event()
The device lock is used to serialize the low level power sequencing
operations. Since drm_helper_hpd_irq_event() could end up calling
.atomic_enable, which also calls power sequencing functions through
runtime PM, this results in a real deadlock. This was observed on an
MT8192-based Chromebook's external display (with appropriate patches [1]
and DT changes applied).
Move the drm_helper_hpd_irq_event() call outside of the lock range. The
lock only needs to be held so that the device status can be read back.
This is the bare minimum change to avoid the deadlock. The lock could
be dropped completely and have pm_runtime_get_if_in_use() increase the
reference count, but this is not the same as pm_runtime_suspended().
This also causes the internal display of the same device to not
function correctly. Both the internal and external display of said
device each use one anx7625 bridge.
[1]
https://lore.kernel.org/dri-devel/20230112042104.4107253-1-treapk...@chromium.org/
Fixes: 60487584a79a ("drm/bridge: anx7625: refactor power control to use
runtime PM framework")
Signed-off-by: Chen-Yu Tsai
---
FWIW I'm aware that this driver could be refactored a lot better.
The work function might be simplified and merged into the threaded
interrupt handler. The .detect op should be reading the HPD state
from the hardware, not some cached state.
drivers/gpu/drm/bridge/analogix/anx7625.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 7e1fb93a6ce4..bf1770b79bba 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1597,18 +1597,17 @@ static void anx7625_work_func(struct work_struct *work)
mutex_lock(&ctx->lock);
- if (pm_runtime_suspended(&ctx->client->dev))
- goto unlock;
+ if (pm_runtime_suspended(&ctx->client->dev)) {
+ mutex_unlock(&ctx->lock);
+ return;
+ }
event = anx7625_hpd_change_detect(ctx);
- if (event < 0)
- goto unlock;
+
+ mutex_unlock(&ctx->lock);
if (ctx->bridge_attached)
drm_helper_hpd_irq_event(ctx->bridge.dev);
-
-unlock:
- mutex_unlock(&ctx->lock);
}
static irqreturn_t anx7625_intr_hpd_isr(int irq, void *data)
--
2.39.0.314.g84b9a713c41-goog
[PATCH 3/3] drm/msm/dpu: simplify blend configuration
Rewrite dpu_hw_ctl_setup_blendstage() to use static data configuration
rather than using a switch-case. This simplifies adding support for new
pipes.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 156 ++---
1 file changed, 45 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 4d70dcd46c9d..f3c15b5a2099 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -379,14 +379,37 @@ static void dpu_hw_ctl_clear_all_blendstages(struct
dpu_hw_ctl *ctx)
DPU_REG_WRITE(c, CTL_FETCH_PIPE_ACTIVE, 0);
}
+struct ctl_blend_config {
+ int idx, shift, ext_shift;
+};
+
+static const struct ctl_blend_config ctl_blend_config[][2] = {
+ [SSPP_NONE] = { { -1 }, { -1 } },
+ [SSPP_MAX] = { { -1 }, { -1 } },
+ [SSPP_VIG0] = { { 0, 0, 0 }, { 3, 0 } },
+ [SSPP_VIG1] = { { 0, 3, 2 }, { 3, 4 } },
+ [SSPP_VIG2] = { { 0, 6, 4 }, { 3, 8 } },
+ [SSPP_VIG3] = { { 0, 26, 6 }, { 3, 12 } },
+ [SSPP_RGB0] = { { 0, 9, 8 }, { -1 } },
+ [SSPP_RGB1] = { { 0, 12, 10 }, { -1 } },
+ [SSPP_RGB2] = { { 0, 15, 12 }, { -1 } },
+ [SSPP_RGB3] = { { 0, 29, 14 }, { -1 } },
+ [SSPP_DMA0] = { { 0, 18, 16 }, { 2, 8 } },
+ [SSPP_DMA1] = { { 0, 21, 18 }, { 2, 12 } },
+ [SSPP_DMA2] = { { 2, 0 }, { 2, 16 } },
+ [SSPP_DMA3] = { { 2, 4 }, { 2, 20 } },
+ [SSPP_DMA4] = { { 4, 0 }, { 4, 8 } },
+ [SSPP_DMA5] = { { 4, 4 }, { 4, 12 } },
+ [SSPP_CURSOR0] = { { 1, 20 }, { -1 } },
+ [SSPP_CURSOR1] = { { 1, 26 }, { -1 } },
+};
+
static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl *ctx,
enum dpu_lm lm, struct dpu_hw_stage_cfg *stage_cfg)
{
struct dpu_hw_blk_reg_map *c = &ctx->hw;
u32 mix, ext, mix_ext;
- u32 mixercfg = 0, mixercfg_ext = 0;
- u32 mixercfg_ext2 = 0, mixercfg_ext3 = 0;
- u32 mixercfg_ext4 = 0;
+ u32 mixercfg[5] = { 0 };
int i, j;
int stages;
int pipes_per_stage;
@@ -401,7 +424,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
else
pipes_per_stage = 1;
- mixercfg = CTL_MIXER_BORDER_OUT; /* always set BORDER_OUT */
+ mixercfg[0] = CTL_MIXER_BORDER_OUT; /* always set BORDER_OUT */
if (!stage_cfg)
goto exit;
@@ -415,119 +438,30 @@ static void dpu_hw_ctl_setup_blendstage(struct
dpu_hw_ctl *ctx,
for (j = 0 ; j < pipes_per_stage; j++) {
enum dpu_sspp_multirect_index rect_index =
stage_cfg->multirect_index[i][j];
-
- switch (stage_cfg->stage[i][j]) {
- case SSPP_VIG0:
- if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext3 |= mix_ext << 0;
- } else {
- mixercfg |= mix << 0;
- mixercfg_ext |= ext << 0;
- }
- break;
- case SSPP_VIG1:
- if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext3 |= mix_ext << 4;
- } else {
- mixercfg |= mix << 3;
- mixercfg_ext |= ext << 2;
- }
- break;
- case SSPP_VIG2:
- if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext3 |= mix_ext << 8;
- } else {
- mixercfg |= mix << 6;
- mixercfg_ext |= ext << 4;
- }
- break;
- case SSPP_VIG3:
- if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext3 |= mix_ext << 12;
- } else {
- mixercfg |= mix << 26;
- mixercfg_ext |= ext << 6;
- }
- break;
- case SSPP_RGB0:
- mixercfg |= mix << 9;
- mixercfg_ext |= ext << 8;
- break;
- case SSPP_RGB1:
- mixercfg |= mix << 12;
- mixercfg_ext |= ext << 10;
- break;
- case SSPP_RGB2:
- mixercfg |= mix <<
[PATCH 2/3] drm/msm/dpu: simplify ctl_setup_blendstage calculation
Extract the common expression in the dpu_hw_ctl_setup_blendstage()
function.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index f4fdf537616c..4d70dcd46c9d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -383,7 +383,8 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
enum dpu_lm lm, struct dpu_hw_stage_cfg *stage_cfg)
{
struct dpu_hw_blk_reg_map *c = &ctx->hw;
- u32 mixercfg = 0, mixercfg_ext = 0, mix, ext;
+ u32 mix, ext, mix_ext;
+ u32 mixercfg = 0, mixercfg_ext = 0;
u32 mixercfg_ext2 = 0, mixercfg_ext3 = 0;
u32 mixercfg_ext4 = 0;
int i, j;
@@ -409,6 +410,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
/* overflow to ext register if 'i + 1 > 7' */
mix = (i + 1) & 0x7;
ext = i >= 7;
+ mix_ext = (i + 1) & 0xf;
for (j = 0 ; j < pipes_per_stage; j++) {
enum dpu_sspp_multirect_index rect_index =
@@ -417,7 +419,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
switch (stage_cfg->stage[i][j]) {
case SSPP_VIG0:
if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext3 |= ((i + 1) & 0xF) << 0;
+ mixercfg_ext3 |= mix_ext << 0;
} else {
mixercfg |= mix << 0;
mixercfg_ext |= ext << 0;
@@ -425,7 +427,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
break;
case SSPP_VIG1:
if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext3 |= ((i + 1) & 0xF) << 4;
+ mixercfg_ext3 |= mix_ext << 4;
} else {
mixercfg |= mix << 3;
mixercfg_ext |= ext << 2;
@@ -433,7 +435,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
break;
case SSPP_VIG2:
if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext3 |= ((i + 1) & 0xF) << 8;
+ mixercfg_ext3 |= mix_ext << 8;
} else {
mixercfg |= mix << 6;
mixercfg_ext |= ext << 4;
@@ -441,7 +443,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
break;
case SSPP_VIG3:
if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext3 |= ((i + 1) & 0xF) << 12;
+ mixercfg_ext3 |= mix_ext << 12;
} else {
mixercfg |= mix << 26;
mixercfg_ext |= ext << 6;
@@ -465,7 +467,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
break;
case SSPP_DMA0:
if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext2 |= ((i + 1) & 0xF) << 8;
+ mixercfg_ext2 |= mix_ext << 8;
} else {
mixercfg |= mix << 18;
mixercfg_ext |= ext << 16;
@@ -473,7 +475,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
break;
case SSPP_DMA1:
if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext2 |= ((i + 1) & 0xF) << 12;
+ mixercfg_ext2 |= mix_ext << 12;
} else {
mixercfg |= mix << 21;
mixercfg_ext |= ext << 18;
@@ -481,39 +483,37 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
break;
case SSPP_DMA2:
if (rect_index == DPU_SSPP_RECT_1) {
- mixercfg_ext2 |= ((i + 1) & 0xF) << 16;
+ mixercfg_ext2 |= mi
[PATCH 1/3] drm/msm/dpu: fix blend setup for DMA4 and DMA5 layers
SM8550 uses new register to map SSPP_DMA4 and SSPP_DMA5 units to blend
stages. Add proper support for this register to allow using these two
planes for image processing.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Cc: Neil Armstrong
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 15 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 19 +++
3 files changed, 30 insertions(+), 6 deletions(-)
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 835d6d2c4115..504a22c76412 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -67,6 +67,9 @@
#define CTL_SC7280_MASK \
(BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG))
+#define CTL_SM8550_MASK \
+ (CTL_SC7280_MASK | BIT(DPU_CTL_HAS_LAYER_EXT4))
+
#define MERGE_3D_SM8150_MASK (0)
#define DSPP_MSM8998_MASK BIT(DPU_DSPP_PCC) | BIT(DPU_DSPP_GC)
@@ -999,37 +1002,37 @@ static const struct dpu_ctl_cfg sm8550_ctl[] = {
{
.name = "ctl_0", .id = CTL_0,
.base = 0x15000, .len = 0x290,
- .features = CTL_SC7280_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
+ .features = CTL_SM8550_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
},
{
.name = "ctl_1", .id = CTL_1,
.base = 0x16000, .len = 0x290,
- .features = CTL_SC7280_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
+ .features = CTL_SM8550_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
},
{
.name = "ctl_2", .id = CTL_2,
.base = 0x17000, .len = 0x290,
- .features = CTL_SC7280_MASK,
+ .features = CTL_SM8550_MASK,
.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
},
{
.name = "ctl_3", .id = CTL_3,
.base = 0x18000, .len = 0x290,
- .features = CTL_SC7280_MASK,
+ .features = CTL_SM8550_MASK,
.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
},
{
.name = "ctl_4", .id = CTL_4,
.base = 0x19000, .len = 0x290,
- .features = CTL_SC7280_MASK,
+ .features = CTL_SM8550_MASK,
.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
},
{
.name = "ctl_5", .id = CTL_5,
.base = 0x1a000, .len = 0x290,
- .features = CTL_SC7280_MASK,
+ .features = CTL_SM8550_MASK,
.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 23),
},
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index a1f18d53db6d..d152fef438f9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -199,6 +199,7 @@ enum {
* @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
* @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
* @DPU_CTL_VM_CFG:CTL config to support multiple VMs
+ * @DPU_CTL_HAS_LAYER_EXT4:CTL has the CTL_LAYER_EXT4 register
* @DPU_CTL_MAX
*/
enum {
@@ -206,6 +207,7 @@ enum {
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
DPU_CTL_VM_CFG,
+ DPU_CTL_HAS_LAYER_EXT4,
DPU_CTL_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index a35ecb6676c8..f4fdf537616c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -17,6 +17,8 @@
(0x70 + (((lm) - LM_0) * 0x004))
#define CTL_LAYER_EXT3(lm) \
(0xA0 + (((lm) - LM_0) * 0x004))
+#define CTL_LAYER_EXT4(lm) \
+(0xB8 + (((lm) - LM_0) * 0x004))
#define CTL_TOP 0x014
#define CTL_FLUSH 0x018
#define CTL_START 0x01C
@@ -383,6 +385,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
struct dpu_hw_blk_reg_map *c = &ctx->hw;
u32 mixercfg = 0, mixercfg_ext = 0, mix, ext;
u32 mixercfg_ext2 = 0, mixercfg_ext3 = 0;
+ u32 mixercfg_ext4 = 0;
int i, j;
int stages;
int pipes_per_stage;
@@ -492,6 +495,20 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
mixercfg_ext2 |= mix << 4;
}
break;
+ case SSPP_DMA4:
+ if (rect_index == DPU_SSPP_RECT_1) {
+ mixercfg_ext4 |= ((i + 1) & 0xF) << 8;
+ } else {
+ mixercfg_ext4 |= ((i + 1) & 0xF) << 0;
+ }
+ break;
+
Re: [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
On 2023.01.10 13:49:57 -0500, Rodrigo Vivi wrote:
> On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > function adds the overhead of introducing a proxy file operation
> > functions to wrap the original read/write inside file removal protection
> > functions. This adds significant overhead in terms of introducing and
> > managing the proxy factory file operations structure and function
> > wrapping at runtime.
> > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> > with debugfs_create_file_unsafe() is suggested to be used instead. The
> > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > debugfs_file_put() wrappers to protect the original read and write
> > function calls for the debug attributes. There is no need for any
> > runtime proxy file operations to be managed by the debugfs core.
> > Following coccicheck make command helped identify this change:
> >
> > make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
> > COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> >
> > Signed-off-by: Deepak R Varma
>
> I believe these 2 gvt cases could be done in one patch.
> But anyways,
>
> Reviewed-by: Rodrigo Vivi
>
> for both patches... and will leave these 2 patches for gvt folks
> to apply. Unless they ack and I apply in the drm-intel along with the other
> ones.
>
yeah, they're fine with me, feel free to apply them directly.
Acked-by: Zhenyu Wang
thanks!
> > ---
> > drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
> > b/drivers/gpu/drm/i915/gvt/debugfs.c
> > index 03f081c3d9a4..baccbf1761b7 100644
> > --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> > +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> > @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
> > return 0;
> > }
> >
> > -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL,
> > "0x%llx\n");
> > +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL,
> > "0x%llx\n");
> >
> > /**
> > * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> > @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
> > &vgpu_mmio_diff_fops);
> > debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> >&vgpu_scan_nonprivbb_fops);
> > - debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> > - &vgpu_status_fops);
> > + debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> > + &vgpu_status_fops);
> > }
> >
> > /**
> > --
> > 2.34.1
> >
> >
> >
signature.asc
Description: PGP signature
[PATCH] drm/msm/dpu: enable sourcesplit for sc7180/sc7280
According to the vendor dts files, both sc7180 and sc7280 support the
source split mode (using two LMs for a single output). Change these two
platforms to use MIXER_SDM845_MASK, which includes
DPU_MIXER_SOURCESPLIT. Rename MIXER_SC7180_MASK to MIXER_QCM2290_MASK,
since this platform doesn't seem to support source split mode.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
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 22ad996e9014..835d6d2c4115 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -56,7 +56,7 @@
#define MIXER_SDM845_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER) |
BIT(DPU_MIXER_COMBINED_ALPHA))
-#define MIXER_SC7180_MASK \
+#define MIXER_QCM2290_MASK \
(BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
#define PINGPONG_SDM845_MASK BIT(DPU_PINGPONG_DITHER)
@@ -1464,9 +1464,9 @@ static const struct dpu_lm_sub_blks sc7180_lm_sblk = {
};
static const struct dpu_lm_cfg sc7180_lm[] = {
- LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
&sc7180_lm_sblk, PINGPONG_0, LM_1, DSPP_0),
- LM_BLK("lm_1", LM_1, 0x45000, MIXER_SC7180_MASK,
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
&sc7180_lm_sblk, PINGPONG_1, LM_0, 0),
};
@@ -1499,11 +1499,11 @@ static const struct dpu_lm_cfg sm8150_lm[] = {
};
static const struct dpu_lm_cfg sc7280_lm[] = {
- LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
&sc7180_lm_sblk, PINGPONG_0, 0, DSPP_0),
- LM_BLK("lm_2", LM_2, 0x46000, MIXER_SC7180_MASK,
+ LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
&sc7180_lm_sblk, PINGPONG_2, LM_3, 0),
- LM_BLK("lm_3", LM_3, 0x47000, MIXER_SC7180_MASK,
+ LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
&sc7180_lm_sblk, PINGPONG_3, LM_2, 0),
};
@@ -1518,7 +1518,7 @@ static const struct dpu_lm_sub_blks qcm2290_lm_sblk = {
};
static const struct dpu_lm_cfg qcm2290_lm[] = {
- LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_QCM2290_MASK,
&qcm2290_lm_sblk, PINGPONG_0, 0, DSPP_0),
};
--
2.39.0
Re: [PATCH 1/2] drm/ttm: Check ttm_debugfs_root before creating files under it
On 1/13/2023 5:37 PM, Christian König wrote:
> Am 13.01.23 um 06:34 schrieb Ma Jun:
>> Check the ttm_debugfs_root before creating files under it.
>> If the ttm_debugfs_root is NULL, all the files created for
>> ttm/ will be placed in the /sys/kerne/debug/ but not
>> /sys/kernel/debug/ttm/
>
> Well NAK for upstreaming. Why should ttm_debugfs_root be NULL here?
>
In my case, when the ttm/ removal fails during amdgpu uninstall and then
we try to modprobe the amdgpu again, the ttm_debugfs_root will be NULL
because the ttm/ already exists.
Regards,
Ma Jun
> Regards,
> Christian.
>
>>
>> Signed-off-by: Ma Jun
>> ---
>> drivers/gpu/drm/ttm/ttm_device.c | 3 ++-
>> drivers/gpu/drm/ttm/ttm_pool.c | 10 ++
>> drivers/gpu/drm/ttm/ttm_tt.c | 5 +++--
>> 3 files changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
>> b/drivers/gpu/drm/ttm/ttm_device.c
>> index e7147e304637..967bc2244df3 100644
>> --- a/drivers/gpu/drm/ttm/ttm_device.c
>> +++ b/drivers/gpu/drm/ttm/ttm_device.c
>> @@ -105,7 +105,8 @@ static int ttm_global_init(void)
>> INIT_LIST_HEAD(&glob->device_list);
>> atomic_set(&glob->bo_count, 0);
>>
>> -debugfs_create_atomic_t("buffer_objects", 0444, ttm_debugfs_root,
>> +if(ttm_debugfs_root)
>> +debugfs_create_atomic_t("buffer_objects", 0444,
>> ttm_debugfs_root,
>> &glob->bo_count);
>> out:
>> if (ret && ttm_debugfs_root)
>> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
>> index 21b61631f73a..d95a65f759df 100644
>> --- a/drivers/gpu/drm/ttm/ttm_pool.c
>> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
>> @@ -713,10 +713,12 @@ int ttm_pool_mgr_init(unsigned long num_pages)
>> }
>>
>> #ifdef CONFIG_DEBUG_FS
>> -debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
>> -&ttm_pool_debugfs_globals_fops);
>> -debugfs_create_file("page_pool_shrink", 0400, ttm_debugfs_root, NULL,
>> -&ttm_pool_debugfs_shrink_fops);
>> +if(ttm_debugfs_root) {
>> +debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
>> +&ttm_pool_debugfs_globals_fops);
>> +debugfs_create_file("page_pool_shrink", 0400, ttm_debugfs_root,
>> NULL,
>> +&ttm_pool_debugfs_shrink_fops);
>> +}
>> #endif
>>
>> mm_shrinker.count_objects = ttm_pool_shrinker_count;
>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>> index d505603930a7..fec443494ef0 100644
>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
>> @@ -394,8 +394,9 @@ DEFINE_SHOW_ATTRIBUTE(ttm_tt_debugfs_shrink);
>> void ttm_tt_mgr_init(unsigned long num_pages, unsigned long
>> num_dma32_pages)
>> {
>> #ifdef CONFIG_DEBUG_FS
>> -debugfs_create_file("tt_shrink", 0400, ttm_debugfs_root, NULL,
>> -&ttm_tt_debugfs_shrink_fops);
>> +if(ttm_debugfs_root)
>> +debugfs_create_file("tt_shrink", 0400, ttm_debugfs_root, NULL,
>> +&ttm_tt_debugfs_shrink_fops);
>> #endif
>>
>> if (!ttm_pages_limit)
>
Re: [PATCH 2/2] drm/ttm: Use debugfs_remove_recursive to remove ttm directory
On 1/13/2023 5:38 PM, Christian König wrote: > Am 13.01.23 um 06:34 schrieb Ma Jun: >> Use debugfs_remove_recursive to remove the /sys/kernel/debug/ttm >> directory for better compatibility. Becuase debugfs_remove fails >> on older kernel. > > Again NAK for upstreaming. > > The upstream kernel is made for the newest kernel version and should not > contain any compatibility handling for older kernels. > Yes, generally so. But the debugfs_remove_recursive() and debugfs_remove() are same function now. The debugfs_remove_recursive is used here so that we don't need to make kcl patch for it. Regards, Ma Jun > Christian. > >> >> Signed-off-by: Ma Jun >> --- >> drivers/gpu/drm/ttm/ttm_device.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/ttm/ttm_device.c >> b/drivers/gpu/drm/ttm/ttm_device.c >> index 967bc2244df3..590297123bb2 100644 >> --- a/drivers/gpu/drm/ttm/ttm_device.c >> +++ b/drivers/gpu/drm/ttm/ttm_device.c >> @@ -55,7 +55,7 @@ static void ttm_global_release(void) >> goto out; >> >> ttm_pool_mgr_fini(); >> -debugfs_remove(ttm_debugfs_root); >> +debugfs_remove_recursive(ttm_debugfs_root); >> >> __free_page(glob->dummy_read_page); >> memset(glob, 0, sizeof(*glob)); >
RE: [PATCH 0/3] drm/amd/pm/powerplay: use bitwise or for bitmasks addition
[AMD Official Use Only - General] Series is reviewed-by: Evan Quan > -Original Message- > From: Deepak R Varma > Sent: Sunday, January 15, 2023 3:16 PM > To: Quan, Evan ; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; David > Airlie ; Daniel Vetter ; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux- > ker...@vger.kernel.org > Cc: Saurabh Singh Sengar ; Praveen Kumar > > Subject: [PATCH 0/3] drm/amd/pm/powerplay: use bitwise or for bitmasks > addition > > The patch series proposes usage of bitwise or "|" operator for addition of > bitmasks instead of using numerial additions. The former is quicker and > cleaner. > > The proposed change is compile tested. > > Deepak R Varma (3): > drm/amd/pm/powerplay/smumgr: use bitwise or for addition > drm/amd/pm/powerplay/hwmgr: use bitwise or for bitmasks addition > drm/amd/pm/powerplay/smumgr/ci: use bitwise or for bitmasks addition > > drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 8 --- > - > drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c | 2 +- > drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c | 2 +- > drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c | 2 +- > 4 files changed, 7 insertions(+), 7 deletions(-) > > -- > 2.34.1 > >
linux-next: manual merge of the fbdev tree with the drm-misc tree
Hi all,
Today's linux-next merge of the fbdev tree got a conflict in:
include/linux/fb.h
between commit:
5b6373de4351 ("drm/fbdev: Remove aperture handling and FBINFO_MISC_FIRMWARE")
from the drm-misc tree and commit:
72ac3535c2c5 ("fbdev: fb.h: Replace 0-length array with flexible array")
from the fbdev tree.
I fixed it up (I just used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpj46MaVgRpq.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the amdgpu tree with the drm-misc tree
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
between commit:
a6276e92a037 ("drm: Include where needed")
from the drm-misc tree and commit:
a98cdd8c4856 ("drm/amd/display: refactor ddc logic from dc_link_ddc to
link_ddc")
from the amdgpu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 55a845eb0c6d,7bf21bb52a7d..
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@@ -66,8 -66,6 +66,7 @@@
#include "ivsrcid/ivsrcid_vislands30.h"
- #include "i2caux_interface.h"
+#include
#include
#include
#include
pgp9gF0uZM9cG.pgp
Description: OpenPGP digital signature
Re: [REGRESSION] GM20B probe fails after commit 2541626cfb79
On Thu, Dec 29, 2022 at 12:58 AM Diogo Ivo wrote: > > Hello, > > Commit 2541626cfb79 breaks GM20B probe with > the following kernel log: > > [2.153892] [ cut here ] > [2.153897] WARNING: CPU: 1 PID: 36 at > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 > gf100_vmm_valid+0x2c4/0x390 > [2.153916] Modules linked in: > [2.153922] CPU: 1 PID: 36 Comm: kworker/u8:1 Not tainted 6.1.0+ #1 > [2.153929] Hardware name: Google Pixel C (DT) > [2.153933] Workqueue: events_unbound deferred_probe_work_func > [2.153943] pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [2.153950] pc : gf100_vmm_valid+0x2c4/0x390 > [2.153959] lr : gf100_vmm_valid+0xb4/0x390 > [2.153966] sp : ffc009e134b0 > [2.153969] x29: ffc009e134b0 x28: x27: > ffc008fd44c8 > [2.153979] x26: ffea x25: ffc0087b98d0 x24: > ff8080f89038 > [2.153987] x23: ff8081fadc08 x22: x21: > > [2.153995] x20: ff8080f8a000 x19: ffc009e13678 x18: > > [2.154003] x17: f37a8b93418958e6 x16: ffc009f0d000 x15: > > [2.154011] x14: 0002 x13: 0003a020 x12: > ffc00800 > [2.154019] x11: 000102913000 x10: x9 : > > [2.154026] x8 : ffc009e136d8 x7 : ffc008fd44c8 x6 : > ff80803d0f00 > [2.154034] x5 : x4 : ff8080f88c00 x3 : > 0010 > [2.154041] x2 : 000c x1 : ffea x0 : > ffea > [2.154050] Call trace: > [2.154053] gf100_vmm_valid+0x2c4/0x390 > [2.154061] nvkm_vmm_map_valid+0xd4/0x204 > [2.154069] nvkm_vmm_map_locked+0xa4/0x344 > [2.154076] nvkm_vmm_map+0x50/0x84 > [2.154083] nvkm_firmware_mem_map+0x84/0xc4 > [2.154094] nvkm_falcon_fw_oneinit+0xc8/0x320 > [2.154101] nvkm_acr_oneinit+0x428/0x5b0 > [2.154109] nvkm_subdev_oneinit_+0x50/0x104 > [2.154114] nvkm_subdev_init_+0x3c/0x12c > [2.154119] nvkm_subdev_init+0x60/0xa0 > [2.154125] nvkm_device_init+0x14c/0x2a0 > [2.154133] nvkm_udevice_init+0x60/0x9c > [2.154140] nvkm_object_init+0x48/0x1b0 > [2.154144] nvkm_ioctl_new+0x168/0x254 > [2.154149] nvkm_ioctl+0xd0/0x220 > [2.154153] nvkm_client_ioctl+0x10/0x1c > [2.154162] nvif_object_ctor+0xf4/0x22c > [2.154168] nvif_device_ctor+0x28/0x70 > [2.154174] nouveau_cli_init+0x150/0x590 > [2.154180] nouveau_drm_device_init+0x60/0x2a0 > [2.154187] nouveau_platform_device_create+0x90/0xd0 > [2.154193] nouveau_platform_probe+0x3c/0x9c > [2.154200] platform_probe+0x68/0xc0 > [2.154207] really_probe+0xbc/0x2dc > [2.154211] __driver_probe_device+0x78/0xe0 > [2.154216] driver_probe_device+0xd8/0x160 > [2.154221] __device_attach_driver+0xb8/0x134 > [2.154226] bus_for_each_drv+0x78/0xd0 > [2.154230] __device_attach+0x9c/0x1a0 > [2.154234] device_initial_probe+0x14/0x20 > [2.154239] bus_probe_device+0x98/0xa0 > [2.154243] deferred_probe_work_func+0x88/0xc0 > [2.154247] process_one_work+0x204/0x40c > [2.154256] worker_thread+0x230/0x450 > [2.154261] kthread+0xc8/0xcc > [2.154266] ret_from_fork+0x10/0x20 > [2.154273] ---[ end trace ]--- > [2.154278] nouveau 5700.gpu: pmu: map -22 > [2.154285] nouveau 5700.gpu: acr: one-time init failed, -22 > [2.154559] nouveau 5700.gpu: init failed with -22 > [2.154564] nouveau: DRM-master::0080: init failed with -22 > [2.154574] nouveau 5700.gpu: DRM-master: Device allocation failed: -22 > [2.162905] nouveau: probe of 5700.gpu failed with error -22 > > #regzbot introduced: 2541626cfb79 As a quick check can you try changing drivers/gpu/drm/nouveau/nvkm/core/firmware.c:nvkm_firmware_mem_target from NVKM_MEM_TARGET_HOST to NVKM_MEM_TARGET_NCOH ? Dave. > > Thanks, > > Diogo Ivo >
Re: [PATCH v2] video: fbdev: omapfb: Use kstrtobool() instead of strtobool()
On 1/14/23 09:54, Christophe JAILLET wrote: strtobool() is the same as kstrtobool(). However, the latter is more used within the kernel. In order to remove strtobool() and slightly simplify kstrtox.h, switch to the other function name. While at it, include the corresponding header file () Signed-off-by: Christophe JAILLET applied. Thanks! Helge --- This patch was already sent as a part of a serie ([1]) that axed all usages of strtobool(). Most of the patches have been merged in -next. I synch'ed with latest -next and re-send the remaining ones as individual patches. Changes in v2: - No change [1]: https://lore.kernel.org/all/cover.1667336095.git.christophe.jail...@wanadoo.fr/ --- drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c | 7 --- drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c | 7 --- drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c | 3 ++- drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 3 ++- 4 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c index bc5a44c2a144..ae937854403b 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c @@ -10,6 +10,7 @@ #define DSS_SUBSYS_NAME "DISPLAY" #include +#include #include #include #include @@ -36,7 +37,7 @@ static ssize_t display_enabled_store(struct omap_dss_device *dssdev, int r; bool enable; - r = strtobool(buf, &enable); + r = kstrtobool(buf, &enable); if (r) return r; @@ -73,7 +74,7 @@ static ssize_t display_tear_store(struct omap_dss_device *dssdev, if (!dssdev->driver->enable_te || !dssdev->driver->get_te) return -ENOENT; - r = strtobool(buf, &te); + r = kstrtobool(buf, &te); if (r) return r; @@ -183,7 +184,7 @@ static ssize_t display_mirror_store(struct omap_dss_device *dssdev, if (!dssdev->driver->set_mirror || !dssdev->driver->get_mirror) return -ENOENT; - r = strtobool(buf, &mirror); + r = kstrtobool(buf, &mirror); if (r) return r; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c index ba21c4a2633d..1b644be5fe2e 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c @@ -10,6 +10,7 @@ #define DSS_SUBSYS_NAME "MANAGER" #include +#include #include #include #include @@ -246,7 +247,7 @@ static ssize_t manager_trans_key_enabled_store(struct omap_overlay_manager *mgr, bool enable; int r; - r = strtobool(buf, &enable); + r = kstrtobool(buf, &enable); if (r) return r; @@ -290,7 +291,7 @@ static ssize_t manager_alpha_blending_enabled_store( if(!dss_has_feature(FEAT_ALPHA_FIXED_ZORDER)) return -ENODEV; - r = strtobool(buf, &enable); + r = kstrtobool(buf, &enable); if (r) return r; @@ -329,7 +330,7 @@ static ssize_t manager_cpr_enable_store(struct omap_overlay_manager *mgr, if (!dss_has_feature(FEAT_CPR)) return -ENODEV; - r = strtobool(buf, &enable); + r = kstrtobool(buf, &enable); if (r) return r; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c index 601c0beb6de9..1da4fb1c77b4 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include @@ -210,7 +211,7 @@ static ssize_t overlay_enabled_store(struct omap_overlay *ovl, const char *buf, int r; bool enable; - r = strtobool(buf, &enable); + r = kstrtobool(buf, &enable); if (r) return r; diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c index 06dc41aa0354..831b2c2fbdf9 100644 --- a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -96,7 +97,7 @@ static ssize_t store_mirror(struct device *dev, int r; struct fb_var_screeninfo new_var; - r = strtobool(buf, &mirror); + r = kstrtobool(buf, &mirror); if (r) return r;
Re: [PATCH] drm/amd/display: Simplify same effect if/else blocks
On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
> The if / else block code has same effect irrespective of the logical
> evaluation. Hence, simply the implementation by removing the unnecessary
> conditional evaluation. While at it, also fix the long line checkpatch
> complaint. Issue identified using cond_no_effect.cocci Coccinelle
> semantic patch script.
>
> Signed-off-by: Deepak R Varma
> ---
> Please note: The proposed change is compile tested only. If there are any
> inbuilt test cases that I should run for further verification, I will
> appreciate
> guidance about it. Thank you.
Preface: I do not know the code.
Perhaps Rodrigo Siqueira made a copy/paste error submitting the code for
commit 9114b55fabae ("drm/amd/display: Fix SubVP control flow in the MPO
context")
as the code prior to this change is identical.
Perhaps one of the false uses should be true or dependent on the
interdependent_update_lock state.
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
[]
> @@ -3470,14 +3470,9 @@ static void commit_planes_for_stream(struct dc *dc,
> /* Since phantom pipe programming is moved to
> post_unlock_program_front_end,
>* move the SubVP lock to after the phantom pipes have been
> setup
>*/
> - if (should_lock_all_pipes &&
> dc->hwss.interdependent_update_lock) {
> - if (dc->hwss.subvp_pipe_control_lock)
> - dc->hwss.subvp_pipe_control_lock(dc, context,
> false, should_lock_all_pipes, NULL, subvp_prev_use);
> - } else {
> - if (dc->hwss.subvp_pipe_control_lock)
> - dc->hwss.subvp_pipe_control_lock(dc, context,
> false, should_lock_all_pipes, NULL, subvp_prev_use);
> - }
> -
Perhaps something like:
if (dc->hwss.subvp_pipe_control_lock)
dc->hwss.subvp_pipe_control_lock(dc, context,
should_lock_all_pipes
&&
dc->hwss.interdependent_update_lock,
should_lock_all_pipes,
NULL, subvp_prev_use);
> + if (dc->hwss.subvp_pipe_control_lock)
> + dc->hwss.subvp_pipe_control_lock(dc, context, false,
> should_lock_all_pipes,
> + NULL, subvp_prev_use);
> return;
> }
>
Re: [PATCH] fbdev: fbmon: fix function name in kernel-doc
On 1/13/23 07:36, Randy Dunlap wrote: Fix a kernel-doc warning by correcting the function name in the kernel-doc comment: drivers/video/fbdev/core/fbmon.c:1073: warning: expecting prototype for fb_get_hblank_by_freq(). Prototype was for fb_get_hblank_by_hfreq() instead Signed-off-by: Randy Dunlap Cc: Daniel Vetter Cc: Helge Deller Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org applied. Thanks! Helge --- drivers/video/fbdev/core/fbmon.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -- a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c --- a/drivers/video/fbdev/core/fbmon.c +++ b/drivers/video/fbdev/core/fbmon.c @@ -1050,7 +1050,7 @@ static u32 fb_get_vblank(u32 hfreq) } /** - * fb_get_hblank_by_freq - get horizontal blank time given hfreq + * fb_get_hblank_by_hfreq - get horizontal blank time given hfreq * @hfreq: horizontal freq * @xres: horizontal resolution in pixels *
Re: [PATCH] fbdev/g364fb: Fix a compilation issue
Hi Xurui,
On 1/9/23 11:04, Geert Uytterhoeven wrote:
This time with the new linux-mips mailing list address...
On Mon, Jan 9, 2023 at 11:01 AM Geert Uytterhoeven wrote:
Hi Xurui,
On Thu, Jan 5, 2023 at 10:45 AM xurui wrote:
drivers/video/fbdev/g364fb.c:202:4: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
Signed-off-by: xurui
Thanks for your patch!
--- a/drivers/video/fbdev/g364fb.c
+++ b/drivers/video/fbdev/g364fb.c
@@ -175,7 +175,8 @@ int __init g364fb_init(void)
{
volatile unsigned int *curs_pal_ptr =
(volatile unsigned int *) CURS_PAL_REG;
- int mem, i;
+ int mem;
+ uintptr_t i;
This doesn't look like the right fix to me.
The line the compiler[1] complains about is:
*(unsigned short *) (CURS_PAT_REG + i * 8) = 0;
Interestingly, it doesn't complain about:
*(unsigned short *) (CURS_PAT_REG + 14 * 64) = 0x;
This driver uses raw memory writes to write to hardware registers.
Probably it should use writel() instead.
Xurui, I'll drop this patch from fbdev git tree for now.
Please check if the driver can be converted to writel() or similiar.
Thanks,
Helge
[1] mips64-linux-gnuabi64-gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1)
jazz_defconfig + CONFIG_64BIT=y
Re: [PATCH 1/6] drm/amdgpu: Generalize KFD dmabuf import
Am 2023-01-15 um 11:43 schrieb Christian König:
Am 14.01.23 um 00:15 schrieb Felix Kuehling:
On 2023-01-13 18:00, Chen, Xiaogang wrote:
On 1/13/2023 4:26 PM, Felix Kuehling wrote:
On 2023-01-12 17:41, Chen, Xiaogang wrote:
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 38
++-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 6f236ded5f12..e13c3493b786 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2209,30 +2209,27 @@ int
amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device *adev,
struct amdgpu_bo *bo;
int ret;
- if (dma_buf->ops != &amdgpu_dmabuf_ops)
- /* Can't handle non-graphics buffers */
- return -EINVAL;
-
- obj = dma_buf->priv;
- if (drm_to_adev(obj->dev) != adev)
- /* Can't handle buffers from other devices */
- return -EINVAL;
+ obj = amdgpu_gem_prime_import(adev_to_drm(adev), dma_buf);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
bo = gem_to_amdgpu_bo(obj);
if (!(bo->preferred_domains & (AMDGPU_GEM_DOMAIN_VRAM |
- AMDGPU_GEM_DOMAIN_GTT)))
+ AMDGPU_GEM_DOMAIN_GTT))) {
/* Only VRAM and GTT BOs are supported */
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_put_obj;
+ }
*mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
- if (!*mem)
- return -ENOMEM;
+ if (!*mem) {
+ ret = -ENOMEM;
+ goto err_put_obj;
+ }
ret = drm_vma_node_allow(&obj->vma_node, drm_priv);
- if (ret) {
- kfree(*mem);
- return ret;
- }
+ if (ret)
+ goto err_free_mem;
if (size)
*size = amdgpu_bo_size(bo);
Hi Felix:
I have a question when using amdgpu_gem_prime_import. It will
allow importing a dmabuf to different gpus, then can we still call
amdgpu_bo_mmap_offset on the generated bo if
amdgpu_amdkfd_gpuvm_import_dmabuf also ask mmap_offset?
The mmap offset comes from drm_vma_node_offset_addr. The DRM VMA
address is allocated when ttm_bo_init_reserved calls
drm_vma_offset_add, so there should be no problem querying the
mmap_offset. Whether mmapping of an imported BO is actually
supported is a different question. As far as I can see, it should
be possible. That said, currently ROCm (libhsakmt) uses only
original BOs for CPU mappings, not imported BOs.
Regards,
Felix
The mmap_offset is actually not returned to user space. I just
wonder if here we should get mmap_offset of imported vram buffer if
allow bo be imported to difference gpus. If a vram buffer is
imported to same gpu device amdgpu_bo_mmap_offset is ok, otherwise I
think amdgpu_bo_mmap_offset would not give correct mmap_offset for
the device that the buffer is imported to.
When the BO is imported into the same GPU, you get a reference to the
same BO, so the imported BO has the same mmap_offset as the original BO.
When the BO is imported into a different GPU, it is a new BO with a
new mmap_offset.
That won't work.
I don't think this is incorrect.
No, this is completely incorrect. It mixes up the reverse tracking of
mappings and might crash the system.
I don't understand that. The imported BO is a different BO with a
different mmap offset in a different device file. I don't see how that
messes with the tracking of mappings.
This is the reason why we can't mmap() imported BOs.
I don't see anything preventing that. For userptr BOs, there is this
code in amdgpu_gem_object_mmap:
if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
return -EPERM;
I don't see anything like this preventing mmapping of imported dmabuf
BOs. What am I missing?
mmapping the memory with that new offset should still work. The
imported BO is created with ttm_bo_type_sg, and AFAICT ttm_bo_vm.c
supports mapping of SG BOs.
Actually it shouldn't. This can go boom really easily.
OK. I don't think we're doing this, but after Xiaogang raised the
question I went looking through the code whether it's theoretically
possible. I didn't find anything in the code that says that mmapping
imported dmabufs would be prohibited or even dangerous. On the contrary,
I found that ttm_bo_vm explicitly supports mmapping SG BOs.
When you have imported a BO the only correct way of to mmap() it is to
do so on the original exporter.
That seems sensible, and this is what we do today. That said, if
mmapping an imported BO is dangerous, I'm missing a mechanism to protect
against this.
Re: [PATCH 1/6] drm/amdgpu: Generalize KFD dmabuf import
Am 14.01.23 um 00:15 schrieb Felix Kuehling:
On 2023-01-13 18:00, Chen, Xiaogang wrote:
On 1/13/2023 4:26 PM, Felix Kuehling wrote:
On 2023-01-12 17:41, Chen, Xiaogang wrote:
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 38
++-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 6f236ded5f12..e13c3493b786 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2209,30 +2209,27 @@ int
amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device *adev,
struct amdgpu_bo *bo;
int ret;
- if (dma_buf->ops != &amdgpu_dmabuf_ops)
- /* Can't handle non-graphics buffers */
- return -EINVAL;
-
- obj = dma_buf->priv;
- if (drm_to_adev(obj->dev) != adev)
- /* Can't handle buffers from other devices */
- return -EINVAL;
+ obj = amdgpu_gem_prime_import(adev_to_drm(adev), dma_buf);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
bo = gem_to_amdgpu_bo(obj);
if (!(bo->preferred_domains & (AMDGPU_GEM_DOMAIN_VRAM |
- AMDGPU_GEM_DOMAIN_GTT)))
+ AMDGPU_GEM_DOMAIN_GTT))) {
/* Only VRAM and GTT BOs are supported */
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_put_obj;
+ }
*mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
- if (!*mem)
- return -ENOMEM;
+ if (!*mem) {
+ ret = -ENOMEM;
+ goto err_put_obj;
+ }
ret = drm_vma_node_allow(&obj->vma_node, drm_priv);
- if (ret) {
- kfree(*mem);
- return ret;
- }
+ if (ret)
+ goto err_free_mem;
if (size)
*size = amdgpu_bo_size(bo);
Hi Felix:
I have a question when using amdgpu_gem_prime_import. It will allow
importing a dmabuf to different gpus, then can we still call
amdgpu_bo_mmap_offset on the generated bo if
amdgpu_amdkfd_gpuvm_import_dmabuf also ask mmap_offset?
The mmap offset comes from drm_vma_node_offset_addr. The DRM VMA
address is allocated when ttm_bo_init_reserved calls
drm_vma_offset_add, so there should be no problem querying the
mmap_offset. Whether mmapping of an imported BO is actually
supported is a different question. As far as I can see, it should be
possible. That said, currently ROCm (libhsakmt) uses only original
BOs for CPU mappings, not imported BOs.
Regards,
Felix
The mmap_offset is actually not returned to user space. I just wonder
if here we should get mmap_offset of imported vram buffer if allow bo
be imported to difference gpus. If a vram buffer is imported to same
gpu device amdgpu_bo_mmap_offset is ok, otherwise I think
amdgpu_bo_mmap_offset would not give correct mmap_offset for the
device that the buffer is imported to.
When the BO is imported into the same GPU, you get a reference to the
same BO, so the imported BO has the same mmap_offset as the original BO.
When the BO is imported into a different GPU, it is a new BO with a
new mmap_offset.
That won't work.
I don't think this is incorrect.
No, this is completely incorrect. It mixes up the reverse tracking of
mappings and might crash the system. This is the reason why we can't
mmap() imported BOs.
mmapping the memory with that new offset should still work. The
imported BO is created with ttm_bo_type_sg, and AFAICT ttm_bo_vm.c
supports mapping of SG BOs.
Actually it shouldn't. This can go boom really easily.
When you have imported a BO the only correct way of to mmap() it is to
do so on the original exporter.
Regards,
Christian.
Regards,
Felix
Maybe we should remove mmap_offset parameter of
amdgpu_amdkfd_gpuvm_import_dmabuf since we do not return it to user
space anyway. With that:
Reviewed-by: Xiaogang Chen
Regards
Xiaogang
@@ -2249,7 +2246,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
| KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE
| KFD_IOC_ALLOC_MEM_FLAGS_EXECUTABLE;
- drm_gem_object_get(&bo->tbo.base);
+ get_dma_buf(dma_buf);
+ (*mem)->dmabuf = dma_buf;
(*mem)->bo = bo;
(*mem)->va = va;
(*mem)->domain = (bo->preferred_domains &
AMDGPU_GEM_DOMAIN_VRAM) ?
@@ -2261,6 +2259,12 @@ int
amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device *adev,
(*mem)->is_imported = true;
return 0;
+
+err_free_mem:
+ kfree(*mem);
+err_put_obj:
+ drm_gem_object_put(obj);
+ return ret;
}
/* Evict a userptr BO by stopping the queues if necessary
Re: [PATCH 2/2] Docs: Add some missing SPDX license identifiers of subsystem docs
On Sat, Jan 14, 2023 at 2:48 PM SeongJae Park wrote: > > Some subsystem documents are missing SPDX license identifiers. Add > those. It would be good to split this up per subsystem. > > Signed-off-by: SeongJae Park > --- > Documentation/crypto/index.rst | 2 ++ > Documentation/driver-api/index.rst | 2 ++ > Documentation/gpu/index.rst| 2 ++ > Documentation/hwmon/index.rst | 2 ++ > Documentation/input/index.rst | 2 ++ > Documentation/mm/index.rst | 2 ++ > Documentation/scheduler/index.rst | 2 ++ > Documentation/sound/index.rst | 2 ++ > 8 files changed, 16 insertions(+) > > diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst > index da5d5ad2bdf3..95b0870e09b8 100644 > --- a/Documentation/crypto/index.rst > +++ b/Documentation/crypto/index.rst > @@ -1,3 +1,5 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > == > Crypto API > == > diff --git a/Documentation/driver-api/index.rst > b/Documentation/driver-api/index.rst > index b208e0dac3a0..7a2584ab63c4 100644 > --- a/Documentation/driver-api/index.rst > +++ b/Documentation/driver-api/index.rst > @@ -1,3 +1,5 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > == > Driver implementer's API guide > == > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst > index eee5996acf2c..ff06a6b12c5e 100644 > --- a/Documentation/gpu/index.rst > +++ b/Documentation/gpu/index.rst > @@ -1,3 +1,5 @@ > +.. SPDX-License-Identifier: GPL-2.0 Most of the DRM code is MIT. I'd expect this would be MIT as well. Alex > + > > GPU Driver Developer's Guide > > diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst > index c2b3c1a822dd..2186d732654f 100644 > --- a/Documentation/hwmon/index.rst > +++ b/Documentation/hwmon/index.rst > @@ -1,3 +1,5 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > === > Hardware Monitoring > === > diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst > index 35581cd18e91..d60bf9cfe005 100644 > --- a/Documentation/input/index.rst > +++ b/Documentation/input/index.rst > @@ -1,3 +1,5 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > === > Input Documentation > === > diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst > index 5a94a921ea40..c4e9fbacaf38 100644 > --- a/Documentation/mm/index.rst > +++ b/Documentation/mm/index.rst > @@ -1,3 +1,5 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > === > Memory Management Documentation > === > diff --git a/Documentation/scheduler/index.rst > b/Documentation/scheduler/index.rst > index 1aac972a652f..ae0229f5a9cf 100644 > --- a/Documentation/scheduler/index.rst > +++ b/Documentation/scheduler/index.rst > @@ -1,3 +1,5 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > = > Scheduler > = > diff --git a/Documentation/sound/index.rst b/Documentation/sound/index.rst > index 5abed5fc6485..7e67e12730d3 100644 > --- a/Documentation/sound/index.rst > +++ b/Documentation/sound/index.rst > @@ -1,3 +1,5 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > = > Sound Subsystem Documentation > = > -- > 2.25.1 >
Re: [PATCH 0/3] drm/msm/dpu: several fixes for UBWC setup
On 13/01/2023 23:43, Abhinav Kumar wrote: On 12/7/2022 6:28 AM, Dmitry Baryshkov wrote: Several small corrections for the UBWC setup and related data. I am assuming this series will be dropped in favor of the RFC: https://patchwork.freedesktop.org/series/111751/ Right? No, they cover different topics. One covers the way the DPU handles UBWC setup, another one reworks MDSS. Dmitry Baryshkov (3): drm/msm/dpu: handle UBWC 1.0 in dpu_hw_sspp_setup_format drm/msm/dpu: correct the UBWC version on sm6115 drm/msm/dpu: add missing ubwc_swizzle setting to catalog drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 6 +- 2 files changed, 9 insertions(+), 2 deletions(-) -- With best wishes Dmitry
[RFC PATCH] drm/msm/dpu: enable DPU_MDP_AUDIO_SELECT for sc8180x
According to the discussion ([1]) on the mailing list, platforms before
sm8250 (and derivatives) should program HDMI_DP_CORE_SELECT register to
route audio to the DP ports. Enable DPU_MDP_AUDIO_SELECT on sc8180x to
program correponding register.
[1]
https://lore.kernel.org/all/f86504ba-835a-6e30-6c30-8bb89b135...@quicinc.com/
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file changed, 1 insertion(+), 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 2664fa3665b0..b94b0a772ca8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -550,7 +550,7 @@ static const struct dpu_mdp_cfg sc8180x_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
.base = 0x0, .len = 0x45C,
- .features = 0,
+ .features = BIT(DPU_MDP_AUDIO_SELECT),
.highest_bank_bit = 0x3,
.clk_ctrls[DPU_CLK_CTRL_VIG0] = {
.reg_off = 0x2AC, .bit_off = 0},
--
2.39.0
[PATCH 2/2] drm/msm/dpu: don't use DPU_CLK_CTRL_CURSORn for DMA SSPP clocks
DPU driver has been using the DPU_CLK_CTRL_CURSOR prefix for the DMA
SSPP blocks used for the cursor planes. This has lead to the confusion
at least for the MSM8998 platform. In preparation to supporting the
cursor SSPP blocks, use proper enum values to index DMA SSPP clock
controls.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 64 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +
2 files changed, 34 insertions(+), 32 deletions(-)
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 ad0c55464154..b0f6e071fe4b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -522,9 +522,9 @@ static const struct dpu_mdp_cfg sdm845_mdp[] = {
.reg_off = 0x2AC, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_DMA1] = {
.reg_off = 0x2B4, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = {
.reg_off = 0x2BC, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA3] = {
.reg_off = 0x2C4, .bit_off = 8},
},
};
@@ -539,9 +539,9 @@ static const struct dpu_mdp_cfg sc7180_mdp[] = {
.reg_off = 0x2AC, .bit_off = 0},
.clk_ctrls[DPU_CLK_CTRL_DMA0] = {
.reg_off = 0x2AC, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
.reg_off = 0x2B4, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = {
.reg_off = 0x2C4, .bit_off = 8},
},
};
@@ -564,9 +564,9 @@ static const struct dpu_mdp_cfg sc8180x_mdp[] = {
.reg_off = 0x2AC, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_DMA1] = {
.reg_off = 0x2B4, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = {
.reg_off = 0x2BC, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA3] = {
.reg_off = 0x2C4, .bit_off = 8},
},
};
@@ -602,9 +602,9 @@ static const struct dpu_mdp_cfg sm8250_mdp[] = {
.reg_off = 0x2AC, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_DMA1] = {
.reg_off = 0x2B4, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = {
.reg_off = 0x2BC, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA3] = {
.reg_off = 0x2C4, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_REG_DMA] = {
.reg_off = 0x2BC, .bit_off = 20},
@@ -631,9 +631,9 @@ static const struct dpu_mdp_cfg sm8350_mdp[] = {
.reg_off = 0x2ac, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_DMA1] = {
.reg_off = 0x2b4, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = {
.reg_off = 0x2bc, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA3] = {
.reg_off = 0x2c4, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_REG_DMA] = {
.reg_off = 0x2bc, .bit_off = 20},
@@ -658,9 +658,9 @@ static const struct dpu_mdp_cfg sm8450_mdp[] = {
.reg_off = 0x2AC, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_DMA1] = {
.reg_off = 0x2B4, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = {
.reg_off = 0x2BC, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA3] = {
.reg_off = 0x2C4, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_REG_DMA] = {
.reg_off = 0x2BC, .bit_off = 20},
@@ -676,9 +676,9 @@ static const struct dpu_mdp_cfg sc7280_mdp[] = {
.reg_off = 0x2AC, .bit_off = 0},
.clk_ctrls[DPU_CLK_CTRL_DMA0] = {
.reg_off = 0x2AC, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
.reg_off = 0x2B4, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = {
.reg_off = 0x2C4, .bit_off = 8},
},
};
@@ -696,8 +696,8 @@ static const struct dpu_mdp_cfg sc8280xp_mdp[] = {
.clk_ctrls[DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0},
.clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8},
- .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = { .re
[PATCH 1/2] drm/msm/dpu: fix clocks settings for msm8998 SSPP blocks
DMA2 and DMA3 planes on msm8998 should use corresponding DMA2 and DMA3
clocks rather than CURSOR0/1 clocks (which are used for the CURSOR
planes). Correct corresponding SSPP declarations.
Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
Cc: AngeloGioacchino Del Regno
Cc: Jami Kettunen
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 0f3da480b066..ad0c55464154 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1180,9 +1180,9 @@ static const struct dpu_sspp_cfg msm8998_sspp[] = {
SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_MSM8998_MASK,
sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1),
SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_MSM8998_MASK,
- sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0),
+ sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA2),
SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_MSM8998_MASK,
- sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
+ sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA3),
};
static const struct dpu_sspp_cfg sdm845_sspp[] = {
--
2.39.0
[PATCH] drm/amd/display: Simplify same effect if/else blocks
The if / else block code has same effect irrespective of the logical
evaluation. Hence, simply the implementation by removing the unnecessary
conditional evaluation. While at it, also fix the long line checkpatch
complaint. Issue identified using cond_no_effect.cocci Coccinelle
semantic patch script.
Signed-off-by: Deepak R Varma
---
Please note: The proposed change is compile tested only. If there are any
inbuilt test cases that I should run for further verification, I will appreciate
guidance about it. Thank you.
drivers/gpu/drm/amd/display/dc/core/dc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 0cb8d1f934d1..776209e5d21f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3470,14 +3470,9 @@ static void commit_planes_for_stream(struct dc *dc,
/* Since phantom pipe programming is moved to
post_unlock_program_front_end,
* move the SubVP lock to after the phantom pipes have been
setup
*/
- if (should_lock_all_pipes &&
dc->hwss.interdependent_update_lock) {
- if (dc->hwss.subvp_pipe_control_lock)
- dc->hwss.subvp_pipe_control_lock(dc, context,
false, should_lock_all_pipes, NULL, subvp_prev_use);
- } else {
- if (dc->hwss.subvp_pipe_control_lock)
- dc->hwss.subvp_pipe_control_lock(dc, context,
false, should_lock_all_pipes, NULL, subvp_prev_use);
- }
-
+ if (dc->hwss.subvp_pipe_control_lock)
+ dc->hwss.subvp_pipe_control_lock(dc, context, false,
should_lock_all_pipes,
+NULL, subvp_prev_use);
return;
}
--
2.34.1
[PATCH] drm/amd/display: avoid variable reinitialization
The member variable set_odm_combine is already initialized and hence the
reinitialization instruction can be removed. Issue identified using the
dubleinit.cocci Coccinelle semantic patch script.
Signed-off-by: Deepak R Varma
---
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
index 41edbd64ea21..777d8efee977 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
@@ -254,7 +254,6 @@ static struct timing_generator_funcs dcn314_tg_funcs = {
.get_hw_timing = optc1_get_hw_timing,
.init_odm = optc3_init_odm,
.set_odm_bypass = optc314_set_odm_bypass,
- .set_odm_combine = optc314_set_odm_combine,
.set_h_timing_div_manual_mode =
optc314_set_h_timing_div_manual_mode,
};
--
2.34.1
[PATCH] drm/amd/display: use swap() helper macro in bios_parser
Use swap() helper macro instead of open coded swap instructions. The
change also facilitates code cleanup and realignment for improved
readability. Issue identified using swap.cocci Coccinelle semantic
patch script.
Signed-off-by: Deepak R Varma
---
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 074e70a5c458..7b5894adbf51 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -2929,7 +2929,6 @@ static enum bp_result construct_integrated_info(
struct atom_common_table_header *header;
struct atom_data_revision revision;
- struct clock_voltage_caps temp = {0, 0};
uint32_t i;
uint32_t j;
@@ -3032,14 +3031,8 @@ static enum bp_result construct_integrated_info(
for (i = 1; i < NUMBER_OF_DISP_CLK_VOLTAGE; ++i) {
for (j = i; j > 0; --j) {
if (info->disp_clk_voltage[j].max_supported_clk <
- info->disp_clk_voltage[j-1].max_supported_clk
- ) {
- /* swap j and j - 1*/
- temp = info->disp_clk_voltage[j-1];
- info->disp_clk_voltage[j-1] =
- info->disp_clk_voltage[j];
- info->disp_clk_voltage[j] = temp;
- }
+ info->disp_clk_voltage[j-1].max_supported_clk)
+ swap(info->disp_clk_voltage[j-1],
info->disp_clk_voltage[j]);
}
}
--
2.34.1
