Re: [PATCH v3 17/19] drm/msm/dpu: inline INTF_BLK and INTF_BLK_DSI_TE macros
On 17/06/2023 01:12, Marijn Suijten wrote: On 2023-06-16 13:03:15, Dmitry Baryshkov wrote: To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Signed-off-by: Dmitry Baryshkov Looks good but I am not sure how much it is worth to review this (versus checking your script and rerunning it to see if I get the same results), considering that there are quite some conflicts with your interrupt rework. In what order to you intend to land that? As I wrote, this series goes in first. Initially I designed them the other way, but intr rework depends on DPU revision changes, while this one doesn't have such dependencies. -- With best wishes Dmitry
Re: [PATCH v3 17/19] drm/msm/dpu: inline INTF_BLK and INTF_BLK_DSI_TE macros
On 17/06/2023 01:12, Marijn Suijten wrote:
On 2023-06-16 13:03:15, Dmitry Baryshkov wrote:
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
Looks good but I am not sure how much it is worth to review this (versus
checking your script and rerunning it to see if I get the same results),
considering that there are quite some conflicts with your interrupt
rework. In what order to you intend to land that?
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 52 ++--
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 53 ++--
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 55 ++--
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 82 +---
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 55 ++--
.../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 28 +++-
.../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 15 ++-
.../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h| 28 +++-
.../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 15 ++-
.../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h| 15 ++-
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 55 ++--
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 41 --
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 120 +-
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 55 ++--
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 55 ++--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 30 -
16 files changed, 545 insertions(+), 209 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index a71a6cd532c0..d78cedd35c01 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -243,18 +243,46 @@ static const struct dpu_dspp_cfg msm8998_dspp[] = {
};
static const struct dpu_intf_cfg msm8998_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP,
MSM_DP_CONTROLLER_0, 21, INTF_SDM845_MASK,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
- INTF_BLK("intf_1", INTF_1, 0x6a800, 0x280, INTF_DSI,
MSM_DSI_CONTROLLER_0, 21, INTF_SDM845_MASK,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27)),
- INTF_BLK("intf_2", INTF_2, 0x6b000, 0x280, INTF_DSI,
MSM_DSI_CONTROLLER_1, 21, INTF_SDM845_MASK,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29)),
- INTF_BLK("intf_3", INTF_3, 0x6b800, 0x280, INTF_HDMI, 0, 21,
INTF_SDM845_MASK,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31)),
+ {
+ .name = "intf_0", .id = INTF_0,
+ .base = 0x6a000, .len = 0x280,
+ .features = INTF_SDM845_MASK,
+ .type = INTF_DP,
+ .controller_id = MSM_DP_CONTROLLER_0,
+ .prog_fetch_lines_worst_case = 21,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25),
+ .intr_tear_rd_ptr = -1,
+ }, {
+ .name = "intf_1", .id = INTF_1,
+ .base = 0x6a800, .len = 0x280,
+ .features = INTF_SDM845_MASK,
+ .type = INTF_DSI,
+ .controller_id = MSM_DSI_CONTROLLER_0,
+ .prog_fetch_lines_worst_case = 21,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
+ .intr_tear_rd_ptr = -1,
+ }, {
+ .name = "intf_2", .id = INTF_2,
+ .base = 0x6b000, .len = 0x280,
+ .features = INTF_SDM845_MASK,
+ .type = INTF_DSI,
+ .controller_id = MSM_DSI_CONTROLLER_1,
+ .prog_fetch_lines_worst_case = 21,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
+ .intr_tear_rd_ptr = -1,
+ }, {
+ .name = "intf_3", .id = INTF_3,
+ .base = 0x6b800, .len = 0x280,
+ .features = INTF_SDM845_MASK,
+ .type = INTF_HDMI,
+ .prog_fetch_lines_worst_case = 21,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31),
+ .intr_tear_rd_ptr = -1,
+ },
};
static const struct dpu_perf_cfg msm8998_perf_data = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index
Re: [PATCH v3 13/19] drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macros
On 17/06/2023 01:59, Marijn Suijten wrote:
On 2023-06-16 13:03:11, Dmitry Baryshkov wrote:
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 11 +-
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 17 +++--
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 21 +--
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 31 +---
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 21 +--
.../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h| 6 ++-
.../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h| 6 ++-
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 25 +++--
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 7 +++-
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 37 ---
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 25 +++--
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 25 +++--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 15
13 files changed, 191 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index a07c68744b29..7c3da4033c46 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -200,8 +200,15 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
};
static const struct dpu_dsc_cfg msm8998_dsc[] = {
- DSC_BLK("dsc_0", DSC_0, 0x8, 0),
- DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
+ {
+ .name = "dsc_0", .id = DSC_0,
+ .base = 0x8, .len = 0x1800,
This length (here and for all other DSC v1.1 blocks) was 0x140, why is
it 0x1800 now?
Thanks for noticiing this, it seems it creeped from the regexp. I'll
recheck this.
+ .features = 0,
+ }, {
+ .name = "dsc_1", .id = DSC_1,
+ .base = 0x80400, .len = 0x1800,
+ .features = 0,
Seems you forgot to drop the zero features from MSM8998 :)
- Marijn
+ },
};
static const struct dpu_dspp_cfg msm8998_dspp[] = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index 786263ed1ef2..ca3bb6a1a93a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -224,10 +224,19 @@ static const struct dpu_pingpong_cfg sdm845_pp[] = {
};
static const struct dpu_dsc_cfg sdm845_dsc[] = {
- DSC_BLK("dsc_0", DSC_0, 0x8, 0),
- DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
- DSC_BLK("dsc_2", DSC_2, 0x80800, 0),
- DSC_BLK("dsc_3", DSC_3, 0x80c00, 0),
+ {
+ .name = "dsc_0", .id = DSC_0,
+ .base = 0x8, .len = 0x1800,
+ }, {
+ .name = "dsc_1", .id = DSC_1,
+ .base = 0x80400, .len = 0x1800,
+ }, {
+ .name = "dsc_2", .id = DSC_2,
+ .base = 0x80800, .len = 0x1800,
+ }, {
+ .name = "dsc_3", .id = DSC_3,
+ .base = 0x80c00, .len = 0x1800,
+ },
};
static const struct dpu_intf_cfg sdm845_intf[] = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index 6b9bfeac6e0a..5b068521de13 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -245,10 +245,23 @@ static const struct dpu_merge_3d_cfg sm8150_merge_3d[] = {
};
static const struct dpu_dsc_cfg sm8150_dsc[] = {
- DSC_BLK("dsc_0", DSC_0, 0x8, BIT(DPU_DSC_OUTPUT_CTRL)),
- DSC_BLK("dsc_1", DSC_1, 0x80400, BIT(DPU_DSC_OUTPUT_CTRL)),
- DSC_BLK("dsc_2", DSC_2, 0x80800, BIT(DPU_DSC_OUTPUT_CTRL)),
- DSC_BLK("dsc_3", DSC_3, 0x80c00, BIT(DPU_DSC_OUTPUT_CTRL)),
+ {
+ .name = "dsc_0", .id = DSC_0,
+ .base = 0x8, .len = 0x1800,
+ .features = BIT(DPU_DSC_OUTPUT_CTRL),
+ }, {
+ .name = "dsc_1", .id = DSC_1,
+ .base = 0x80400, .len = 0x1800,
+ .features = BIT(DPU_DSC_OUTPUT_CTRL),
+ }, {
+ .name = "dsc_2", .id = DSC_2,
+ .base = 0x80800, .len = 0x1800,
+ .features = BIT(DPU_DSC_OUTPUT_CTRL),
+ }, {
+ .name = "dsc_3", .id = DSC_3,
+ .base = 0x80c00, .len = 0x1800,
+ .features = BIT(DPU_DSC_OUTPUT_CTRL),
+ },
};
static const struct dpu_intf_cfg sm8150_intf[] = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 414f0db3306c..ba5420f334ec 100644
---
Re: [PATCH] drm/i915: make i915_drm_client_fdinfo() reference conditional again
On 6/16/23 02:31, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The function is only defined if CONFIG_PROC_FS is enabled:
>
> ld.lld: error: undefined symbol: i915_drm_client_fdinfo
referenced by i915_driver.c
drivers/gpu/drm/i915/i915_driver.o:(i915_drm_driver) in
archive vmlinux.a
>
> Use the PTR_IF() helper to make the reference NULL otherwise.
>
> Fixes: e894b724c316d ("drm/i915: Use the fdinfo helper")
> Signed-off-by: Arnd Bergmann
Acked-by: Randy Dunlap
Tested-by: Randy Dunlap # build-tested
Thanks.
> ---
> drivers/gpu/drm/i915/i915_driver.c | 2 +-
> drivers/gpu/drm/i915/i915_drm_client.h | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 75cbc43b326dd..0ad0c5885ec27 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1816,7 +1816,7 @@ static const struct drm_driver i915_drm_driver = {
> .open = i915_driver_open,
> .lastclose = i915_driver_lastclose,
> .postclose = i915_driver_postclose,
> - .show_fdinfo = i915_drm_client_fdinfo,
> + .show_fdinfo = PTR_IF(IS_ENABLED(CONFIG_PROC_FS),
> i915_drm_client_fdinfo),
>
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
> b/drivers/gpu/drm/i915/i915_drm_client.h
> index 4c18b99e10a4e..67816c912bca1 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.h
> +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> @@ -47,8 +47,6 @@ static inline void i915_drm_client_put(struct
> i915_drm_client *client)
>
> struct i915_drm_client *i915_drm_client_alloc(void);
>
> -#ifdef CONFIG_PROC_FS
> void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
> -#endif
>
> #endif /* !__I915_DRM_CLIENT_H__ */
--
~Randy
Re: [PATCH] drm/msm/adreno: Update MODULE_FIRMWARE macros
On 16/06/2023 18:55, Akhil P Oommen wrote:
On Fri, Jun 16, 2023 at 02:28:15PM +0200, Juerg Haefliger wrote:
Add missing MODULE_FIRMWARE macros and remove some for firmwares that
the driver no longer references.
Signed-off-by: Juerg Haefliger
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 23 ++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 8cff86e9d35c..9f70d7c1a72a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -364,17 +364,32 @@ MODULE_FIRMWARE("qcom/a330_pm4.fw");
MODULE_FIRMWARE("qcom/a330_pfp.fw");
MODULE_FIRMWARE("qcom/a420_pm4.fw");
MODULE_FIRMWARE("qcom/a420_pfp.fw");
+MODULE_FIRMWARE("qcom/a506_zap.mdt");
+MODULE_FIRMWARE("qcom/a508_zap.mdt");
+MODULE_FIRMWARE("qcom/a512_zap.mdt");
MODULE_FIRMWARE("qcom/a530_pm4.fw");
MODULE_FIRMWARE("qcom/a530_pfp.fw");
MODULE_FIRMWARE("qcom/a530v3_gpmu.fw2");
MODULE_FIRMWARE("qcom/a530_zap.mdt");
-MODULE_FIRMWARE("qcom/a530_zap.b00");
-MODULE_FIRMWARE("qcom/a530_zap.b01");
-MODULE_FIRMWARE("qcom/a530_zap.b02");
Why are these not required when "qcom/a530_zap.mdt" is present?
mdt & b0* binaries are different partitions of the same secure
firmware. Even though we specify only the .mdt file here, the PIL driver
will load the *.b0* file automatically. OTOH, "*.mbn" is a standalone
unified binary format.
If the requirement is to ensure that all necessary firmwares are part of
your distribution, you should include the *.b0* files too here.
I'd say, we should drop all zap files from this list. Linux-firmware
does not provide files with such names. The zap file name depends on the
SoC and the platform name.
Juerg, could you please split the patch into two parts:
- pfp/pm4/sqe firmware names (which can be merged pretty quickly, as
there is no controversy) and zap files changes (after we finish
discussion in this thread).
-Akhil
+MODULE_FIRMWARE("qcom/a540_gpmu.fw2");
+MODULE_FIRMWARE("qcom/a540_zap.mdt");
+MODULE_FIRMWARE("qcom/a615_zap.mdt");
MODULE_FIRMWARE("qcom/a619_gmu.bin");
MODULE_FIRMWARE("qcom/a630_sqe.fw");
MODULE_FIRMWARE("qcom/a630_gmu.bin");
-MODULE_FIRMWARE("qcom/a630_zap.mbn");
+MODULE_FIRMWARE("qcom/a630_zap.mdt");
+MODULE_FIRMWARE("qcom/a640_gmu.bin");
+MODULE_FIRMWARE("qcom/a640_zap.mdt");
+MODULE_FIRMWARE("qcom/a650_gmu.bin");
+MODULE_FIRMWARE("qcom/a650_sqe.fw");
+MODULE_FIRMWARE("qcom/a650_zap.mdt");
+MODULE_FIRMWARE("qcom/a660_gmu.bin");
+MODULE_FIRMWARE("qcom/a660_sqe.fw");
+MODULE_FIRMWARE("qcom/a660_zap.mdt");
+MODULE_FIRMWARE("qcom/leia_pfp_470.fw");
+MODULE_FIRMWARE("qcom/leia_pm4_470.fw");
+MODULE_FIRMWARE("qcom/yamato_pfp.fw");
+MODULE_FIRMWARE("qcom/yamato_pm4.fw");
static inline bool _rev_match(uint8_t entry, uint8_t id)
{
--
2.37.2
--
With best wishes
Dmitry
Re: [PATCH v3 02/19] drm/msm/dpu: always use MSM_DP/DSI_CONTROLLER_n
On 17/06/2023 01:03, Marijn Suijten wrote:
On 2023-06-16 13:03:00, Dmitry Baryshkov wrote:
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
index 8da424eaee6a..8fa9d83a539d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
@@ -169,11 +169,11 @@ static const struct dpu_intf_cfg sm8350_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x34000, 0x280, INTF_DP,
MSM_DP_CONTROLLER_0, 24, INTF_SC7280_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
- INTF_BLK_DSI_TE("intf_1", INTF_1, 0x35000, 0x2c4, INTF_DSI, 0, 24,
INTF_SC7280_MASK,
+ INTF_BLK_DSI_TE("intf_1", INTF_1, 0x35000, 0x2c4, INTF_DSI,
MSM_DSI_CONTROLLER_0, 24, INTF_SC7280_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
DPU_IRQ_IDX(MDP_INTF1_7xxx_TEAR_INTR, 2)),
This doesn't apply cleanly on top of your interupt rework series: do you
still intend to land that?
Yes, but most likely after this series. If everything goes well, I want
to land this series, DSI DSC docs and last minute fixes to 6.5,
everything else goes into 6.6 (as its review was not started).
- INTF_BLK_DSI_TE("intf_2", INTF_2, 0x36000, 0x2c4, INTF_DSI, 1, 24,
INTF_SC7280_MASK,
+ INTF_BLK_DSI_TE("intf_2", INTF_2, 0x36000, 0x2c4, INTF_DSI,
MSM_DSI_CONTROLLER_1, 24, INTF_SC7280_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
DPU_IRQ_IDX(MDP_INTF2_7xxx_TEAR_INTR, 2)),
- Marijn
--
With best wishes
Dmitry
Re: [PATCH v3 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field
On 17/06/2023 01:44, Marijn Suijten wrote:
On 2023-06-17 00:41:40, Marijn Suijten wrote:
- cfg = _top_offset(idx, m, addr, >hw);
- if (IS_ERR_OR_NULL(cfg)) {
- kfree(mdp);
- return ERR_PTR(-EINVAL);
- }
+ mdp->hw.blk_addr = addr + m->mdp->base;
+ mdp->hw.log_mask = DPU_DBG_MASK_TOP;
You lost the assignment of m->mdp to the local cfg variable, causing
mdp->caps = cfg; below to remain NULL.
To solve that in a clean way, you might as well pass `const struct
dpu_mdp_cfg *cfg` directly from dpu_kms.c into dpu_hw_mdptop_init, as I
did for the other HW blocks in "Pass catalog pointers in RM to replace
for-loop ID lookups".
Sounds good.
--
With best wishes
Dmitry
Re: [Freedreno] [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On 17/06/2023 00:10, Abhinav Kumar wrote: On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote: On 14/06/2023 23:39, Abhinav Kumar wrote: On 6/14/2023 12:54 PM, Abhinav Kumar wrote: On 6/14/2023 12:35 PM, Abhinav Kumar wrote: On 6/14/2023 5:23 AM, Marijn Suijten wrote: On 2023-06-14 15:01:59, Dmitry Baryshkov wrote: On 14/06/2023 14:42, Marijn Suijten wrote: On 2023-06-13 18:57:11, Jessica Zhang wrote: DPU 5.x+ supports a databus widen mode that allows more data to be sent per pclk. Enable this feature flag on all relevant chipsets. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ 2 files changed, 4 insertions(+), 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 36ba3f58dcdf..0be7bf0bfc41 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -103,7 +103,8 @@ (BIT(DPU_INTF_INPUT_CTRL) | \ BIT(DPU_INTF_TE) | \ BIT(DPU_INTF_STATUS_SUPPORTED) | \ - BIT(DPU_DATA_HCTL_EN)) + BIT(DPU_DATA_HCTL_EN) | \ + BIT(DPU_INTF_DATABUS_WIDEN)) This doesn't work. DPU 5.0.0 is SM8150, which has DSI 6G 2.3. In the last patch for DSI you state and enable widebus for DSI 6G 2.5+ only, meaning DPU and DSI are now desynced, and the output is completely corrupted. I looked at the internal docs and also this change. This change is incorrect because this will try to enable widebus for DPU >= 5.0 and DSI >= 2.5 That was not the intended right condition as thats not what the docs say. We should enable for DPU >= 7.0 and DSI >= 2.5 Is there any combination where this compatibility is broken? That would be the strange thing for me ( not DPU 5.0 and DSI 2.5 as that was incorrect) Part of this confusion is because of catalog macro re-use again. This series is a good candidate and infact I think we should only do core_revision based check on DPU and DSI to avoid bringing the catalog mess into this. I have just a single request here: can we please have the same approach for both DSI and DP? I don't mind changing DP code if it makes it better. If you don't have better reasons, I like the idea of DSI/DP dictating whether wide bus should be used on the particular interface. It allows us to handle possible errata or corner cases there. Another option would be to make DPU tell DSI / DP whether the wide bus is enabled or not, but I'd say, this is slightly worse solution. Today, DP's widebus does not check if DPU supports that or not. DPU encoder queries the DP whether widebus is available and enables it. We can also do the same thing for DSI. So for intf_type of DSI, DPU encoder will query DSI if it supports widebus. Not if it supports wide bus. But the check is whether enabling wide bus is requested by the output driver (DSI/DP). Then DSI will do its version checks and for DSC it will say yes. This way, we will never check for the DPU's core revision for DSI and purely rely of DP/DSI's hw revisions. Thats fine with me because that way we again just rely on the hw revision to enable the feature. But as a result I am still going to drop this patch which adds widebus to the catalog as a dpu cap which I always wanted to do anyway as we will just rely on the DSI and DP hw revisions. Yep. Tested this on SM8350 which actually has DSI 2.5, and it is also corrupted with this series so something else on this series might be broken. Missed this response. That seems strange. This series was tested on SM8350 HDK with a command mode panel. We will fix the DPU-DSI handshake and post a v2 but your issue needs investigation in parallel. So another bug to track that would be great. Is the bound in dsi_host wrong, or do DPU and DSI need to communicate when widebus will be enabled, based on DPU && DSI supporting it? I'd prefer to follow the second approach, as we did for DP. DPU asks the actual video output driver if widebus is to be enabled. I was afraid of this. This series was made on an assumption that the DPU version of widebus and DSI version of widebus would be compatible but looks like already SM8150 is an outlier. Yes, I think we have to go with second approach. DPU queries DSI if it supports widebus and enables it. Thanks for your responses. We will post a v2. Doesn't it seem very strange that DPU 5.x+ comes with a widebus feature, but the DSI does not until two revisions later? Or is this available on every interface, but only for a different (probably DP) encoder block? Yes its strange. I have clarified this above. Its not strange but appeared strange because we were checking wrong conditions. - Marijn -- With best wishes Dmitry
Re: [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders
On 17/06/2023 00:54, Marijn Suijten wrote: On 2023-06-16 14:18:39, Abhinav Kumar wrote: On 6/14/2023 12:56 AM, Dmitry Baryshkov wrote: On 14/06/2023 04:57, Jessica Zhang wrote: Add a DPU INTF op to set the DATABUS_WIDEN register to enable the databus-widen mode datapath. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 3 +++ 3 files changed, 18 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index b856c6286c85..124ba96bebda 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -70,6 +70,9 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg( if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression) phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf); + + if (phys_enc->hw_intf->ops.enable_widebus) + phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf); No. Please provide a single function which takes necessary configuration, including compression and wide_bus_enable. There are two ways to look at this. Your point is coming from the perspective that its programming the same register but just a different bit. But that will also make it a bit confusing. My point is to have a high-level function that configures the INTF for the CMD mode. This way it can take a structure with necessary configuration bits. So lets say the function is called intf_cfg2_xxx(..., bool widebus, bool data_compress) Now for the caller who wants to just enable widebus this will be intf_cfg2_xxx(., true, false) if we want to do both intf_cfg2_xxx(, true, true) the last one where we want to do just data_compress(highly unlikely and not recommended) intf_cfg2_xxx(, false, true) Now someone looking at the code will have to go and find out what each bool is. Whereas with separate ops, its kind of implicit. That's why you never pass bools as function argument (edge-case if it is the only argument, and its meaning becomes clear from the function name). Use enumerations anywhere else. - Marijn For that reason, I dont think this patch is bad at all. -- With best wishes Dmitry
Re: [Freedreno] [PATCH v8 10/18] drm/msm/a6xx: Introduce GMU wrapper support
On 16.06.2023 19:54, Akhil P Oommen wrote:
> On Thu, Jun 15, 2023 at 11:43:04PM +0200, Konrad Dybcio wrote:
>>
>> On 10.06.2023 00:06, Akhil P Oommen wrote:
>>> On Mon, May 29, 2023 at 03:52:29PM +0200, Konrad Dybcio wrote:
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
but don't implement the associated GMUs. This is due to the fact that
the GMU directly pokes at RPMh. Sadly, this means we have to take care
of enabling & scaling power rails, clocks and bandwidth ourselves.
Reuse existing Adreno-common code and modify the deeply-GMU-infused
A6XX code to facilitate these GPUs. This involves if-ing out lots
of GMU callbacks and introducing a new type of GMU - GMU wrapper (it's
the actual name that Qualcomm uses in their downstream kernels).
This is essentially a register region which is convenient to model
as a device. We'll use it for managing the GDSCs. The register
layout matches the actual GMU_CX/GX regions on the "real GMU" devices
and lets us reuse quite a bit of gmu_read/write/rmw calls.
Signed-off-by: Konrad Dybcio
---
[...]
+
+ ret = clk_bulk_prepare_enable(gpu->nr_clocks, gpu->grp_clks);
+ if (ret)
+ goto err_bulk_clk;
+
+ /* If anything goes south, tear the GPU down piece by piece.. */
+ if (ret) {
+err_bulk_clk:
>>>
>>> Goto jump directly to another block looks odd to me. Why do you need this
>>> label
>>> anyway?
>> If clk_bulk_prepare_enable() fails, trying to proceed will hang the
>> platform with unclocked accesses. We need to unwind everything that
>> has been done up until that point, in reverse order.
>
> I missed this response from you earlier.
>
> But you are checking for 'ret' twice here. You will end up here even
> if you don't jump! So "if (ret) goto err_bulk_clk;" looks
> unnecessary.
>
> -Akhil.
Ohhh right, silly mistake on my part ;)
I already sent out a v9 since.. Please check it out and if you
have any further comments, I'll fix this, and if not.. Perhaps I
could fix it in an incremental patch if that revision is gtg?
Konrad
>
>>
>>>
+ pm_runtime_put(gmu->gxpd);
+ pm_runtime_put(gmu->dev);
+ dev_pm_opp_set_opp(>pdev->dev, NULL);
+ }
+err_set_opp:
>>>
>>> Generally, it is better to name the label based on what you do here. For
>>> eg: "unlock_lock:".
>> That seems to be a mixed bag all throughout the kernel, I've seen many
>> usages of err_(what went wrong)
>>
>>>
>>> Also, this function is small enough that it is better to return directly
>>> in case of error. I think that would be more readable.
>> Not really, adding the necessary cleanup steps in `if (ret)`
>> blocks would roughly double the function's size.
>>
>>>
+ mutex_unlock(_gpu->gmu.lock);
+
+ if (!ret)
+ msm_devfreq_resume(gpu);
+
+ return ret;
+}
+
+static int a6xx_gmu_pm_suspend(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
@@ -1720,7 +1799,40 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
return 0;
}
-static int a6xx_get_timestamp(struct msm_gpu *gpu, uint64_t *value)
+static int a6xx_pm_suspend(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ struct a6xx_gmu *gmu = _gpu->gmu;
+ int i;
+
+ trace_msm_gpu_suspend(0);
+
+ msm_devfreq_suspend(gpu);
+
+ mutex_lock(_gpu->gmu.lock);
>>>
>>> Again, is this initialized somewhere?
>>>
+
+ /* Drain the outstanding traffic on memory buses */
+ a6xx_bus_clear_pending_transactions(adreno_gpu, true);
+
+ clk_bulk_disable_unprepare(gpu->nr_clocks, gpu->grp_clks);
+
+ pm_runtime_put_sync(gmu->gxpd);
+ dev_pm_opp_set_opp(>pdev->dev, NULL);
+ pm_runtime_put_sync(gmu->dev);
+
+ mutex_unlock(_gpu->gmu.lock);
+
+ if (a6xx_gpu->shadow_bo)
+ for (i = 0; i < gpu->nr_rings; i++)
+ a6xx_gpu->shadow[i] = 0;
+
+ gpu->suspend_count++;
+
+ return 0;
+}
+
+static int a6xx_gmu_get_timestamp(struct msm_gpu *gpu, uint64_t *value)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
@@ -1739,6 +1851,12 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu,
uint64_t *value)
return 0;
}
+static int a6xx_get_timestamp(struct msm_gpu *gpu, uint64_t *value)
+{
+ *value = gpu_read64(gpu, REG_A6XX_CP_ALWAYS_ON_COUNTER);
+ return 0;
+}
+
static struct msm_ringbuffer *a6xx_active_ring(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu =
[PATCH v2] drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID
In order to read the EDID from an eDP panel, you not only need to
power on the bridge chip itself but also the panel. In the ps8640
driver, this was made to work by having the bridge chip manually power
the panel on by calling pre_enable() on everything connectorward on
the bridge chain. This worked OK, but...
...when trying to do the same thing on ti-sn65dsi86, feedback was that
this wasn't a great idea. As a result, we designed the "DP AUX"
bus. With the design we ended up with the panel driver itself was in
charge of reading the EDID. The panel driver could power itself on and
the bridge chip was able to power itself on because it implemented the
DP AUX bus.
Despite the fact that we came up with a new scheme, implemented in on
ti-sn65dsi86, and even implemented it on parade-ps8640, we still kept
the old code around. This was because the new scheme required a DT
change. Previously the panel was a simple "platform_device" and in DT
at the top level. With the new design the panel needs to be listed in
DT under the DP controller node. The old code allowed us to properly
fetch EDIDs with ps8640 with the old DTs.
Unfortunately, the old code stopped working as of commit 102e80d1fa2c
("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs"). There
are cases at bootup where connector->state->state is NULL and the
kernel crashed at:
* drm_atomic_bridge_chain_pre_enable
* drm_atomic_get_old_bridge_state
* drm_atomic_get_old_private_obj_state
The crash went away at commit 4fb912e5e190 ("drm/bridge: Introduce
pre_enable_prev_first to alter bridge init order") which added a NULL
check. However, even though we were no longer crashing the end result
was that we weren't actually powering the panel on when we thought we
were. Things could end up working (despite warning splats) if
userspace was persistent and tried to get the mode again, but it
wasn't great.
A bit of digging was done to see if there was an easy fix but there
was nothing obvious. Instead, the only device using ps8640 the "old"
way had its DT updated so that the panel was no longer a simple
"platform_deice". See commit c2d94f72140a ("arm64: dts: mediatek:
mt8173-elm: Move display to ps8640 auxiliary bus") and commit
113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel model
number in DT").
Let's delete the old broken code so nobody gets tempted to copy it or
figure out how it works (since it doesn't).
NOTE: from a device tree "purist" point of view, we're supposed to
keep old device trees working and this patch is technically "against
policy". Reasons I'm still proposing it anyway:
1. Officially, old mt8173-elm device trees worked via the "little
white lie" approach. The DT would list an arbitrary/representative
panel that would be used for power sequencing. The mode information
in the panel driver would then be ignored / overridden by the EDID
reading code in ps8640. I don't feel too terrible breaking DTs that
contained the wrong "compatible" string to begin with. NOTE that
any old device trees that _didn't_ lie about their compatible will
still work because the mode information will come from the
hardcoded panels in panel-edp.
2. The only users of the old code were Chromebooks and Chromebooks
don't bake their DTs into the BIOS (they are bundled with the
kernel). Thus we don't need to worry about breaking someone using
an old DT with a new kernel.
3. The old code was broken anyway. If someone wants to fix the old
code instead of deleting it then they have my blessing, but without
a proper fix the old code isn't useful.
Reviewed-by: Sam Ravnborg
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Removed "Fixes" tag as per discussion on v1.
- Adjusted commit message since commit 4fb912e5e190 made things not crash.
drivers/gpu/drm/bridge/parade-ps8640.c | 79 --
1 file changed, 79 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 8801cdd033b5..8161b1a1a4b1 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -105,7 +105,6 @@ struct ps8640 {
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_powerdown;
struct device_link *link;
- struct edid *edid;
bool pre_enabled;
bool need_post_hpd_delay;
};
@@ -155,23 +154,6 @@ static inline struct ps8640 *aux_to_ps8640(struct
drm_dp_aux *aux)
return container_of(aux, struct ps8640, aux);
}
-static bool ps8640_of_panel_on_aux_bus(struct device *dev)
-{
- struct device_node *bus, *panel;
-
- bus = of_get_child_by_name(dev->of_node, "aux-bus");
- if (!bus)
- return false;
-
- panel = of_get_child_by_name(bus, "panel");
- of_node_put(bus);
- if (!panel)
- return false;
- of_node_put(panel);
-
- return true;
-}
-
static int _ps8640_wait_hpd_asserted(struct ps8640 *ps_bridge, unsigned long
Re: [PATCH v3 00/19] drm/msm/dpu: another catalog rework
On 2023-06-16 13:02:58, Dmitry Baryshkov wrote: > Having a macro with 10 arguments doesn't seem like a good idea. It makes > it inherently harder to compare the actual structure values. Also this > leads to adding macros covering varieties of the block. > > As it was previously discussed, inline all foo_BLK macros in order to > ease performing changes to the catalog data. > > Major part of the conversion was performed using vim script found at > [1]. Then some manual cleanups were applied, like dropping fields set to > 0. > > Dependencies: msm-next-lumag. > > Changes since v2: > - Rebased on top of msm-next-lumag > - Fixed MSM_DP/DSI_CONTROLLER_n usage in sm6350 and sm6375 catalog data >(Abhinav, Marijn). > > Changes since v1: > - Rebased on top of msm-next > - Dropped dependency on interrupt rework > > [1] https://pastebin.ubuntu.com/p/26cdW5VpYB/ > [2] https://patchwork.freedesktop.org/patch/542142/?series=119220=1 > > Dmitry Baryshkov (19): > drm/msm: enumerate DSI interfaces > drm/msm/dpu: always use MSM_DP/DSI_CONTROLLER_n > drm/msm/dpu: simplify peer LM handling > drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field > drm/msm/dpu: drop enum dpu_mdp and MDP_TOP value > drm/msm/dpu: expand .clk_ctrls definitions > drm/msm/dpu: drop zero features from dpu_mdp_cfg data > drm/msm/dpu: drop zero features from dpu_ctl_cfg data > drm/msm/dpu: correct indentation for CTL definitions > drm/msm/dpu: inline SSPP_BLK macros > drm/msm/dpu: inline DSPP_BLK macros > drm/msm/dpu: inline LM_BLK macros > drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macros > drm/msm/dpu: inline MERGE_3D_BLK macros > drm/msm/dpu: inline various PP_BLK_* macros > drm/msm/dpu: inline WB_BLK macros > drm/msm/dpu: inline INTF_BLK and INTF_BLK_DSI_TE macros Not sure if I'm ready to manually review all the inline patches before the weekend, so for now this should do: Tested-by: Marijn Suijten (On SM8350 and SDM845 for now) That is, after fixing the cfg-not-assigned regression in patch 4 where mdp_count is dropped. - Marijn > drm/msm/dpu: drop empty features mask MERGE_3D_SM8150_MASK > drm/msm/dpu: drop empty features mask INTF_SDM845_MASK > > .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 329 > .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 348 + > .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 411 ++- > .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 448 +++- > .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 430 +++- > .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 184 +-- > .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 88 +++- > .../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h| 188 --- > .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 88 +++- > .../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h| 95 +++- > .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 418 ++- > .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 244 ++--- > .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 484 +- > .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 445 +++- > .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 467 - > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 130 - > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 5 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 34 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h| 7 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 34 +- > drivers/gpu/drm/msm/msm_drv.h | 8 +- > 23 files changed, 3320 insertions(+), 1572 deletions(-) > > -- > 2.39.2 >
Re: [PATCH v3 19/19] drm/msm/dpu: drop empty features mask INTF_SDM845_MASK
On 2023-06-16 13:03:17, Dmitry Baryshkov wrote:
> The INTF_SDM845_MASK features mask is zero. Drop it completely.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 4
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 --
> 3 files changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index d78cedd35c01..060e6a49b2f9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -246,7 +246,6 @@ static const struct dpu_intf_cfg msm8998_intf[] = {
> {
> .name = "intf_0", .id = INTF_0,
> .base = 0x6a000, .len = 0x280,
> - .features = INTF_SDM845_MASK,
> .type = INTF_DP,
> .controller_id = MSM_DP_CONTROLLER_0,
> .prog_fetch_lines_worst_case = 21,
> @@ -256,7 +255,6 @@ static const struct dpu_intf_cfg msm8998_intf[] = {
> }, {
> .name = "intf_1", .id = INTF_1,
> .base = 0x6a800, .len = 0x280,
> - .features = INTF_SDM845_MASK,
> .type = INTF_DSI,
> .controller_id = MSM_DSI_CONTROLLER_0,
> .prog_fetch_lines_worst_case = 21,
> @@ -266,7 +264,6 @@ static const struct dpu_intf_cfg msm8998_intf[] = {
> }, {
> .name = "intf_2", .id = INTF_2,
> .base = 0x6b000, .len = 0x280,
> - .features = INTF_SDM845_MASK,
> .type = INTF_DSI,
> .controller_id = MSM_DSI_CONTROLLER_1,
> .prog_fetch_lines_worst_case = 21,
> @@ -276,7 +273,6 @@ static const struct dpu_intf_cfg msm8998_intf[] = {
> }, {
> .name = "intf_3", .id = INTF_3,
> .base = 0x6b800, .len = 0x280,
> - .features = INTF_SDM845_MASK,
> .type = INTF_HDMI,
> .prog_fetch_lines_worst_case = 21,
> .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index de26f469ebb1..54d7475e1591 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -260,7 +260,6 @@ static const struct dpu_intf_cfg sdm845_intf[] = {
> {
> .name = "intf_0", .id = INTF_0,
> .base = 0x6a000, .len = 0x280,
> - .features = INTF_SDM845_MASK,
> .type = INTF_DP,
> .controller_id = MSM_DP_CONTROLLER_0,
> .prog_fetch_lines_worst_case = 24,
> @@ -270,7 +269,6 @@ static const struct dpu_intf_cfg sdm845_intf[] = {
> }, {
> .name = "intf_1", .id = INTF_1,
> .base = 0x6a800, .len = 0x280,
> - .features = INTF_SDM845_MASK,
> .type = INTF_DSI,
> .controller_id = MSM_DSI_CONTROLLER_0,
> .prog_fetch_lines_worst_case = 24,
> @@ -280,7 +278,6 @@ static const struct dpu_intf_cfg sdm845_intf[] = {
> }, {
> .name = "intf_2", .id = INTF_2,
> .base = 0x6b000, .len = 0x280,
> - .features = INTF_SDM845_MASK,
> .type = INTF_DSI,
> .controller_id = MSM_DSI_CONTROLLER_1,
> .prog_fetch_lines_worst_case = 24,
> @@ -290,7 +287,6 @@ static const struct dpu_intf_cfg sdm845_intf[] = {
> }, {
> .name = "intf_3", .id = INTF_3,
> .base = 0x6b800, .len = 0x280,
> - .features = INTF_SDM845_MASK,
> .type = INTF_DP,
> .controller_id = MSM_DP_CONTROLLER_1,
> .prog_fetch_lines_worst_case = 24,
> 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 4a18fc66a412..3efa22429e5f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -95,8 +95,6 @@
>
> #define DSPP_SC7180_MASK BIT(DPU_DSPP_PCC)
>
> -#define INTF_SDM845_MASK (0)
> -
> #define INTF_SC7180_MASK \
> (BIT(DPU_INTF_INPUT_CTRL) | \
>BIT(DPU_INTF_TE) | \
> --
> 2.39.2
>
Re: [PATCH v3 18/19] drm/msm/dpu: drop empty features mask MERGE_3D_SM8150_MASK
On 2023-06-16 13:03:16, Dmitry Baryshkov wrote:
> The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 3 ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 3 ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 3 ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 3 ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 3 ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 4
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 --
> 8 files changed, 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> index c8c702e4f045..94d97d7f6ff3 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> @@ -273,15 +273,12 @@ static const struct dpu_merge_3d_cfg sm8150_merge_3d[]
> = {
> {
> .name = "merge_3d_0", .id = MERGE_3D_0,
> .base = 0x83000, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_1", .id = MERGE_3D_1,
> .base = 0x83100, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_2", .id = MERGE_3D_2,
> .base = 0x83200, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> },
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> index 11bf4cec0f95..acf14227e68e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> @@ -272,15 +272,12 @@ static const struct dpu_merge_3d_cfg sc8180x_merge_3d[]
> = {
> {
> .name = "merge_3d_0", .id = MERGE_3D_0,
> .base = 0x83000, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_1", .id = MERGE_3D_1,
> .base = 0x83100, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_2", .id = MERGE_3D_2,
> .base = 0x83200, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> },
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> index bf35b5bf0cd1..0936b719b9c6 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> @@ -273,15 +273,12 @@ static const struct dpu_merge_3d_cfg sm8250_merge_3d[]
> = {
> {
> .name = "merge_3d_0", .id = MERGE_3D_0,
> .base = 0x83000, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_1", .id = MERGE_3D_1,
> .base = 0x83100, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_2", .id = MERGE_3D_2,
> .base = 0x83200, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> },
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> index d5191a663ae1..59a96a4b250c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> @@ -271,15 +271,12 @@ static const struct dpu_merge_3d_cfg sm8350_merge_3d[]
> = {
> {
> .name = "merge_3d_0", .id = MERGE_3D_0,
> .base = 0x4e000, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_1", .id = MERGE_3D_1,
> .base = 0x4f000, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_2", .id = MERGE_3D_2,
> .base = 0x5, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> },
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> index 9f94cc6369dd..7110caae7251 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> @@ -275,15 +275,12 @@ static const struct dpu_merge_3d_cfg
> sc8280xp_merge_3d[] = {
> {
> .name = "merge_3d_0", .id = MERGE_3D_0,
> .base = 0x4e000, .len = 0x8,
> - .features = MERGE_3D_SM8150_MASK,
> }, {
> .name = "merge_3d_1", .id = MERGE_3D_1,
>
Re: [PATCH v3 08/19] drm/msm/dpu: drop zero features from dpu_ctl_cfg data
On 2023-06-16 13:03:06, Dmitry Baryshkov wrote:
> Drop useless zero assignments to the dpu_ctl_cfg::features field.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 3 ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 3 ---
> 2 files changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index 757ac648a692..e0cc1ce3f3e2 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -54,7 +54,6 @@ static const struct dpu_ctl_cfg msm8998_ctl[] = {
> {
> .name = "ctl_1", .id = CTL_1,
> .base = 0x1200, .len = 0x94,
> - .features = 0,
> .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> },
> {
> @@ -66,13 +65,11 @@ static const struct dpu_ctl_cfg msm8998_ctl[] = {
> {
> .name = "ctl_3", .id = CTL_3,
> .base = 0x1600, .len = 0x94,
> - .features = 0,
> .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> },
> {
> .name = "ctl_4", .id = CTL_4,
> .base = 0x1800, .len = 0x94,
> - .features = 0,
> .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
> },
> };
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index 9fb8ef21c7f0..f52e1fa27e2c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -58,19 +58,16 @@ static const struct dpu_ctl_cfg sdm845_ctl[] = {
> {
> .name = "ctl_2", .id = CTL_2,
> .base = 0x1400, .len = 0xe4,
> - .features = 0,
> .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> },
> {
> .name = "ctl_3", .id = CTL_3,
> .base = 0x1600, .len = 0xe4,
> - .features = 0,
> .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> },
> {
> .name = "ctl_4", .id = CTL_4,
> .base = 0x1800, .len = 0xe4,
> - .features = 0,
> .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
> },
> };
> --
> 2.39.2
>
Re: [PATCH v3 13/19] drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macros
On 2023-06-16 13:03:11, Dmitry Baryshkov wrote:
> To simplify making changes to the hardware block definitions, expand
> corresponding macros. This way making all the changes are more obvious
> and visible in the source files.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 11 +-
> .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 17 +++--
> .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 21 +--
> .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 31 +---
> .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 21 +--
> .../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h| 6 ++-
> .../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h| 6 ++-
> .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 25 +++--
> .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 7 +++-
> .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 37 ---
> .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 25 +++--
> .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 25 +++--
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 15
> 13 files changed, 191 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index a07c68744b29..7c3da4033c46 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -200,8 +200,15 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
> };
>
> static const struct dpu_dsc_cfg msm8998_dsc[] = {
> - DSC_BLK("dsc_0", DSC_0, 0x8, 0),
> - DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
> + {
> + .name = "dsc_0", .id = DSC_0,
> + .base = 0x8, .len = 0x1800,
This length (here and for all other DSC v1.1 blocks) was 0x140, why is
it 0x1800 now?
> + .features = 0,
> + }, {
> + .name = "dsc_1", .id = DSC_1,
> + .base = 0x80400, .len = 0x1800,
> + .features = 0,
Seems you forgot to drop the zero features from MSM8998 :)
- Marijn
> + },
> };
>
> static const struct dpu_dspp_cfg msm8998_dspp[] = {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index 786263ed1ef2..ca3bb6a1a93a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -224,10 +224,19 @@ static const struct dpu_pingpong_cfg sdm845_pp[] = {
> };
>
> static const struct dpu_dsc_cfg sdm845_dsc[] = {
> - DSC_BLK("dsc_0", DSC_0, 0x8, 0),
> - DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
> - DSC_BLK("dsc_2", DSC_2, 0x80800, 0),
> - DSC_BLK("dsc_3", DSC_3, 0x80c00, 0),
> + {
> + .name = "dsc_0", .id = DSC_0,
> + .base = 0x8, .len = 0x1800,
> + }, {
> + .name = "dsc_1", .id = DSC_1,
> + .base = 0x80400, .len = 0x1800,
> + }, {
> + .name = "dsc_2", .id = DSC_2,
> + .base = 0x80800, .len = 0x1800,
> + }, {
> + .name = "dsc_3", .id = DSC_3,
> + .base = 0x80c00, .len = 0x1800,
> + },
> };
>
> static const struct dpu_intf_cfg sdm845_intf[] = {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> index 6b9bfeac6e0a..5b068521de13 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> @@ -245,10 +245,23 @@ static const struct dpu_merge_3d_cfg sm8150_merge_3d[]
> = {
> };
>
> static const struct dpu_dsc_cfg sm8150_dsc[] = {
> - DSC_BLK("dsc_0", DSC_0, 0x8, BIT(DPU_DSC_OUTPUT_CTRL)),
> - DSC_BLK("dsc_1", DSC_1, 0x80400, BIT(DPU_DSC_OUTPUT_CTRL)),
> - DSC_BLK("dsc_2", DSC_2, 0x80800, BIT(DPU_DSC_OUTPUT_CTRL)),
> - DSC_BLK("dsc_3", DSC_3, 0x80c00, BIT(DPU_DSC_OUTPUT_CTRL)),
> + {
> + .name = "dsc_0", .id = DSC_0,
> + .base = 0x8, .len = 0x1800,
> + .features = BIT(DPU_DSC_OUTPUT_CTRL),
> + }, {
> + .name = "dsc_1", .id = DSC_1,
> + .base = 0x80400, .len = 0x1800,
> + .features = BIT(DPU_DSC_OUTPUT_CTRL),
> + }, {
> + .name = "dsc_2", .id = DSC_2,
> + .base = 0x80800, .len = 0x1800,
> + .features = BIT(DPU_DSC_OUTPUT_CTRL),
> + }, {
> + .name = "dsc_3", .id = DSC_3,
> + .base = 0x80c00, .len = 0x1800,
> + .features = BIT(DPU_DSC_OUTPUT_CTRL),
> + },
> };
>
> static const struct dpu_intf_cfg sm8150_intf[] = {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> index 414f0db3306c..ba5420f334ec 100644
> ---
Re: [PATCH v3 07/19] drm/msm/dpu: drop zero features from dpu_mdp_cfg data
On 2023-06-16 13:03:05, Dmitry Baryshkov wrote:
> Drop useless zero assignments to the dpu_mdp_cfg::features field.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 1 -
> 7 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> index ab1820f1ac54..e321cc0a80ee 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> @@ -28,7 +28,6 @@ static const struct dpu_ubwc_cfg sm8250_ubwc_cfg = {
> static const struct dpu_mdp_cfg sm8250_mdp = {
> .name = "top_0",
> .base = 0x0, .len = 0x494,
> - .features = 0,
> .clk_ctrls = {
> [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> [DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
> index 2df9a00728c0..1919ee487e68 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
> @@ -25,7 +25,6 @@ static const struct dpu_ubwc_cfg sc7180_ubwc_cfg = {
> static const struct dpu_mdp_cfg sc7180_mdp = {
> .name = "top_0",
> .base = 0x0, .len = 0x494,
> - .features = 0,
> .clk_ctrls = {
> [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h
> index 1982654e74a0..0252fe9590e7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h
> @@ -26,7 +26,6 @@ static const struct dpu_ubwc_cfg sm6115_ubwc_cfg = {
> static const struct dpu_mdp_cfg sm6115_mdp = {
> .name = "top_0",
> .base = 0x0, .len = 0x494,
> - .features = 0,
> .clk_ctrls = {
> [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> index ac237c3197cf..3c2083760294 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> @@ -28,7 +28,6 @@ static const struct dpu_ubwc_cfg sm6350_ubwc_cfg = {
> static const struct dpu_mdp_cfg sm6350_mdp = {
> .name = "top_0",
> .base = 0x0, .len = 0x494,
> - .features = 0,
> .clk_ctrls = {
> [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h
> index 24c4536e7981..54cc6ad8ee36 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h
> @@ -23,7 +23,6 @@ static const struct dpu_ubwc_cfg qcm2290_ubwc_cfg = {
> static const struct dpu_mdp_cfg qcm2290_mdp = {
> .name = "top_0",
> .base = 0x0, .len = 0x494,
> - .features = 0,
> .clk_ctrls = {
> [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> index 099b74be3fd2..f0f6f2d801b4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> @@ -27,7 +27,6 @@ static const struct dpu_ubwc_cfg sm6375_ubwc_cfg = {
> static const struct dpu_mdp_cfg sm6375_mdp = {
> .name = "top_0",
> .base = 0x0, .len = 0x494,
> - .features = 0,
> .clk_ctrls = {
> [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> index 7db3a6969189..318bed612da5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> +++
Re: [PATCH v3 06/19] drm/msm/dpu: expand .clk_ctrls definitions
On 2023-06-16 13:03:04, Dmitry Baryshkov wrote:
> Use more standard initialisation for .clk_ctrls definitions. Define a
> single .clk_ctrls field and use array init inside.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 22 +
> .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 18 +++---
> .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 18 +++---
> .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 18 +++---
> .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 22 +
> .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 12 ++
> .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 6 +++--
> .../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h| 12 ++
> .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 6 +++--
> .../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h| 6 +++--
> .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 20 +---
> .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 12 ++
> .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 20 +---
> .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 20 +---
> .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 24 ++-
> 15 files changed, 133 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index 30565b245b29..757ac648a692 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -30,16 +30,18 @@ static const struct dpu_mdp_cfg msm8998_mdp = {
> .name = "top_0",
> .base = 0x0, .len = 0x458,
> .features = BIT(DPU_MDP_VSYNC_SEL),
> - .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> - .clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
> - .clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0 },
> - .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_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
> - .clk_ctrls[DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2c4, .bit_off = 12 },
> - .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = { .reg_off = 0x3a8, .bit_off = 16 },
> - .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = { .reg_off = 0x3b0, .bit_off = 16 },
> + .clk_ctrls = {
> + [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> + [DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
> + [DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0 },
> + [DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0 },
> + [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> + [DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> + [DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
> + [DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2c4, .bit_off = 12 },
> + [DPU_CLK_CTRL_CURSOR0] = { .reg_off = 0x3a8, .bit_off = 16 },
> + [DPU_CLK_CTRL_CURSOR1] = { .reg_off = 0x3b0, .bit_off = 16 },
> + },
> };
>
> static const struct dpu_ctl_cfg msm8998_ctl[] = {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index 35c495bdcbe9..9fb8ef21c7f0 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -30,14 +30,16 @@ static const struct dpu_mdp_cfg sdm845_mdp = {
> .name = "top_0",
> .base = 0x0, .len = 0x45c,
> .features = BIT(DPU_MDP_AUDIO_SELECT) | BIT(DPU_MDP_VSYNC_SEL),
> - .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> - .clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
> - .clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0 },
> - .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_DMA2] = { .reg_off = 0x2bc, .bit_off = 8 },
> - .clk_ctrls[DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2c4, .bit_off = 8 },
> + .clk_ctrls = {
> + [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> + [DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
> + [DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0 },
> + [DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0 },
> + [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> + [DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> +
Re: [PATCH v3 05/19] drm/msm/dpu: drop enum dpu_mdp and MDP_TOP value
On 2023-06-16 13:03:03, Dmitry Baryshkov wrote:
> Since there is always just a single MDP_TOP instance, drop the enum
> dpu_mdp and corresponding index value.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 6 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h | 7 ++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
> 19 files changed, 20 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index e0d2ee48d733..30565b245b29 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -27,7 +27,7 @@ static const struct dpu_ubwc_cfg msm8998_ubwc_cfg = {
> };
>
> static const struct dpu_mdp_cfg msm8998_mdp = {
> - .name = "top_0", .id = MDP_TOP,
> + .name = "top_0",
> .base = 0x0, .len = 0x458,
> .features = BIT(DPU_MDP_VSYNC_SEL),
> .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index 72295d5a10dc..35c495bdcbe9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -27,7 +27,7 @@ static const struct dpu_ubwc_cfg sdm845_ubwc_cfg = {
> };
>
> static const struct dpu_mdp_cfg sdm845_mdp = {
> - .name = "top_0", .id = MDP_TOP,
> + .name = "top_0",
> .base = 0x0, .len = 0x45c,
> .features = BIT(DPU_MDP_AUDIO_SELECT) | BIT(DPU_MDP_VSYNC_SEL),
> .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> index 418312b164b8..cb2716715e3d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> @@ -27,7 +27,7 @@ static const struct dpu_ubwc_cfg sm8150_ubwc_cfg = {
> };
>
> static const struct dpu_mdp_cfg sm8150_mdp = {
> - .name = "top_0", .id = MDP_TOP,
> + .name = "top_0",
> .base = 0x0, .len = 0x45c,
> .features = BIT(DPU_MDP_AUDIO_SELECT),
> .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> index ffacf29926b3..a655e84cf147 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> @@ -27,7 +27,7 @@ static const struct dpu_ubwc_cfg sc8180x_ubwc_cfg = {
> };
>
> static const struct dpu_mdp_cfg sc8180x_mdp = {
> - .name = "top_0", .id = MDP_TOP,
> + .name = "top_0",
> .base = 0x0, .len = 0x45c,
> .features = BIT(DPU_MDP_AUDIO_SELECT),
> .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> index 86dfc5745630..90e561d086e0 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> @@ -26,7 +26,7 @@ static const struct dpu_ubwc_cfg sm8250_ubwc_cfg = {
> };
>
> static const struct dpu_mdp_cfg sm8250_mdp = {
> - .name = "top_0", .id = MDP_TOP,
> + .name = "top_0",
> .base = 0x0, .len = 0x494,
> .features = 0,
> .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
> index
Re: [PATCH v3 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field
On 2023-06-17 00:41:40, Marijn Suijten wrote:
> > - cfg = _top_offset(idx, m, addr, >hw);
> > - if (IS_ERR_OR_NULL(cfg)) {
> > - kfree(mdp);
> > - return ERR_PTR(-EINVAL);
> > - }
> > + mdp->hw.blk_addr = addr + m->mdp->base;
> > + mdp->hw.log_mask = DPU_DBG_MASK_TOP;
>
> You lost the assignment of m->mdp to the local cfg variable, causing
> mdp->caps = cfg; below to remain NULL.
To solve that in a clean way, you might as well pass `const struct
dpu_mdp_cfg *cfg` directly from dpu_kms.c into dpu_hw_mdptop_init, as I
did for the other HW blocks in "Pass catalog pointers in RM to replace
for-loop ID lookups".
- Marijn
Re: [PATCH v3 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field
On 2023-06-16 13:03:02, Dmitry Baryshkov wrote:
> There is always a single MDP TOP block. Drop the mdp_count field and
> stop declaring dpu_mdp_cfg instances as arrays.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 ++---
> .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 7 ++---
> .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 7 ++---
> .../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 7 ++---
> .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 7 ++---
> .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 7 ++---
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 28 ++-
> 17 files changed, 32 insertions(+), 102 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index be0514bf27ec..e0d2ee48d733 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -26,8 +26,7 @@ static const struct dpu_ubwc_cfg msm8998_ubwc_cfg = {
> .highest_bank_bit = 0x2,
> };
>
> -static const struct dpu_mdp_cfg msm8998_mdp[] = {
> - {
> +static const struct dpu_mdp_cfg msm8998_mdp = {
> .name = "top_0", .id = MDP_TOP,
> .base = 0x0, .len = 0x458,
> .features = BIT(DPU_MDP_VSYNC_SEL),
> @@ -41,7 +40,6 @@ static const struct dpu_mdp_cfg msm8998_mdp[] = {
> .clk_ctrls[DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2c4, .bit_off = 12 },
> .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = { .reg_off = 0x3a8, .bit_off = 16 },
> .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = { .reg_off = 0x3b0, .bit_off = 16 },
> - },
> };
>
> static const struct dpu_ctl_cfg msm8998_ctl[] = {
> @@ -192,8 +190,7 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
> const struct dpu_mdss_cfg dpu_msm8998_cfg = {
> .caps = _dpu_caps,
> .ubwc = _ubwc_cfg,
> - .mdp_count = ARRAY_SIZE(msm8998_mdp),
> - .mdp = msm8998_mdp,
> + .mdp = _mdp,
> .ctl_count = ARRAY_SIZE(msm8998_ctl),
> .ctl = msm8998_ctl,
> .sspp_count = ARRAY_SIZE(msm8998_sspp),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index b33472625fcb..72295d5a10dc 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -26,8 +26,7 @@ static const struct dpu_ubwc_cfg sdm845_ubwc_cfg = {
> .highest_bank_bit = 0x2,
> };
>
> -static const struct dpu_mdp_cfg sdm845_mdp[] = {
> - {
> +static const struct dpu_mdp_cfg sdm845_mdp = {
> .name = "top_0", .id = MDP_TOP,
> .base = 0x0, .len = 0x45c,
> .features = BIT(DPU_MDP_AUDIO_SELECT) | BIT(DPU_MDP_VSYNC_SEL),
> @@ -39,7 +38,6 @@ static const struct dpu_mdp_cfg sdm845_mdp[] = {
> .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> .clk_ctrls[DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2bc, .bit_off = 8 },
> .clk_ctrls[DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2c4, .bit_off = 8 },
> - },
> };
>
> static const struct dpu_ctl_cfg sdm845_ctl[] = {
> @@ -196,8 +194,7 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
> const struct dpu_mdss_cfg dpu_sdm845_cfg = {
> .caps = _dpu_caps,
> .ubwc = _ubwc_cfg,
> - .mdp_count = ARRAY_SIZE(sdm845_mdp),
> - .mdp = sdm845_mdp,
> + .mdp = _mdp,
> .ctl_count = ARRAY_SIZE(sdm845_ctl),
> .ctl = sdm845_ctl,
> .sspp_count = ARRAY_SIZE(sdm845_sspp),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> index 64ed10da1b73..418312b164b8 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> @@ -26,8 +26,7 @@ static const struct dpu_ubwc_cfg sm8150_ubwc_cfg = {
> .highest_bank_bit = 0x2,
> };
>
> -static const struct dpu_mdp_cfg sm8150_mdp[] = {
> - {
> +static const struct dpu_mdp_cfg sm8150_mdp = {
> .name = "top_0", .id = MDP_TOP,
> .base = 0x0, .len = 0x45c,
> .features = BIT(DPU_MDP_AUDIO_SELECT),
> @@ -39,7 +38,6 @@ static const struct dpu_mdp_cfg sm8150_mdp[] = {
> .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> .clk_ctrls[DPU_CLK_CTRL_DMA2] =
Re: [PATCH v3 09/19] drm/msm/dpu: correct indentation for CTL definitions
On 2023-06-16 13:03:07, Dmitry Baryshkov wrote:
> Shift dpu_ctl_cfg contents to correct the indentation of CTL blocks.
> This is done in preparation to expanding the rest of hardware block
> defines, so that all blocks have similar indentation.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 46 +++---
> .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 46 +++---
> .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 63 +--
> .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 63 +--
> .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 63 +--
> .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 30 +
> .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 8 +--
> .../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h| 41 ++--
> .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 8 +--
> .../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h| 8 +--
> .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 63 +--
> .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 41 ++--
> .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 63 +--
> .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 63 +--
> .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 63 +--
> 15 files changed, 309 insertions(+), 360 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index e0cc1ce3f3e2..6660a55909e7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -46,31 +46,27 @@ static const struct dpu_mdp_cfg msm8998_mdp = {
>
> static const struct dpu_ctl_cfg msm8998_ctl[] = {
> {
> - .name = "ctl_0", .id = CTL_0,
> - .base = 0x1000, .len = 0x94,
> - .features = BIT(DPU_CTL_SPLIT_DISPLAY),
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> - },
> - {
> - .name = "ctl_1", .id = CTL_1,
> - .base = 0x1200, .len = 0x94,
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> - },
> - {
> - .name = "ctl_2", .id = CTL_2,
> - .base = 0x1400, .len = 0x94,
> - .features = BIT(DPU_CTL_SPLIT_DISPLAY),
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> - },
> - {
> - .name = "ctl_3", .id = CTL_3,
> - .base = 0x1600, .len = 0x94,
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> - },
> - {
> - .name = "ctl_4", .id = CTL_4,
> - .base = 0x1800, .len = 0x94,
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
> + .name = "ctl_0", .id = CTL_0,
> + .base = 0x1000, .len = 0x94,
> + .features = BIT(DPU_CTL_SPLIT_DISPLAY),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> + }, {
> + .name = "ctl_1", .id = CTL_1,
> + .base = 0x1200, .len = 0x94,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> + }, {
> + .name = "ctl_2", .id = CTL_2,
> + .base = 0x1400, .len = 0x94,
> + .features = BIT(DPU_CTL_SPLIT_DISPLAY),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> + }, {
> + .name = "ctl_3", .id = CTL_3,
> + .base = 0x1600, .len = 0x94,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> + }, {
> + .name = "ctl_4", .id = CTL_4,
> + .base = 0x1800, .len = 0x94,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
> },
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index f52e1fa27e2c..8f96a9e4ee4c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -44,31 +44,27 @@ static const struct dpu_mdp_cfg sdm845_mdp = {
>
> static const struct dpu_ctl_cfg sdm845_ctl[] = {
> {
> - .name = "ctl_0", .id = CTL_0,
> - .base = 0x1000, .len = 0xe4,
> - .features = BIT(DPU_CTL_SPLIT_DISPLAY),
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> - },
> - {
> - .name = "ctl_1", .id = CTL_1,
> - .base = 0x1200, .len = 0xe4,
> - .features = BIT(DPU_CTL_SPLIT_DISPLAY),
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> - },
> - {
> - .name = "ctl_2", .id = CTL_2,
> - .base = 0x1400, .len = 0xe4,
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> - },
> - {
> - .name = "ctl_3", .id = CTL_3,
> - .base = 0x1600, .len = 0xe4,
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> - },
> - {
> - .name = "ctl_4", .id = CTL_4,
> - .base = 0x1800, .len = 0xe4,
> - .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
> + .name =
[PATCH net-next v8 11/11] MAINTAINERS: ASP 2.0 Ethernet driver maintainers
Add maintainers entry for ASP 2.0 Ethernet driver. Reviewed-by: Simon Horman Signed-off-by: Florian Fainelli Signed-off-by: Justin Chen --- v3 - Change from gmail to broadcom emails MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7322963b0670..adbbfe636c0c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4195,6 +4195,15 @@ F: drivers/net/mdio/mdio-bcm-unimac.c F: include/linux/platform_data/bcmgenet.h F: include/linux/platform_data/mdio-bcm-unimac.h +BROADCOM ASP 2.0 ETHERNET DRIVER +M: Justin Chen +M: Florian Fainelli +L: bcm-kernel-feedback-l...@broadcom.com +L: net...@vger.kernel.org +S: Supported +F: Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml +F: drivers/net/ethernet/broadcom/asp2/ + BROADCOM IPROC ARM ARCHITECTURE M: Ray Jui M: Scott Branden -- 2.7.4 smime.p7s Description: S/MIME Cryptographic Signature
[PATCH net-next v8 08/11] net: bcmasp: Add support for ethtool driver stats
Add support for ethernet driver specific stats.
Signed-off-by: Justin Chen
---
v8
- Address maybe uninit variable warning
drivers/net/ethernet/broadcom/asp2/bcmasp.c| 4 +-
drivers/net/ethernet/broadcom/asp2/bcmasp.h| 21 +++
.../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 160 +
drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 17 ++-
4 files changed, 198 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
index 51b7aa8365c8..a8905fef4f8a 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
@@ -890,8 +890,10 @@ int bcmasp_set_en_mda_filter(struct bcmasp_intf *intf,
unsigned char *addr,
/* Attempt to combine filters */
ret = bcmasp_combine_set_filter(intf, addr, mask, i);
- if (!ret)
+ if (!ret) {
+ intf->mib.filters_combine_cnt++;
return 0;
+ }
}
/* Create new filter if possible */
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.h
b/drivers/net/ethernet/broadcom/asp2/bcmasp.h
index d6740077877a..1d5c3be575d7 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp.h
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.h
@@ -245,6 +245,26 @@ struct bcmasp_intf_stats64 {
struct u64_stats_sync syncp;
};
+struct bcmasp_mib_counters {
+ u32 edpkt_ts;
+ u32 edpkt_rx_pkt_cnt;
+ u32 edpkt_hdr_ext_cnt;
+ u32 edpkt_hdr_out_cnt;
+ u32 umac_frm_cnt;
+ u32 fb_frm_cnt;
+ u32 fb_rx_fifo_depth;
+ u32 fb_out_frm_cnt;
+ u32 fb_filt_out_frm_cnt;
+ u32 alloc_rx_skb_failed;
+ u32 tx_dma_failed;
+ u32 mc_filters_full_cnt;
+ u32 uc_filters_full_cnt;
+ u32 filters_combine_cnt;
+ u32 promisc_filters_cnt;
+ u32 tx_realloc_offload_failed;
+ u32 tx_realloc_offload;
+};
+
struct bcmasp_intf_ops {
unsigned long (*rx_desc_read)(struct bcmasp_intf *intf);
void (*rx_buffer_write)(struct bcmasp_intf *intf, dma_addr_t addr);
@@ -307,6 +327,7 @@ struct bcmasp_intf {
/* Statistics */
struct bcmasp_intf_stats64 stats64;
+ struct bcmasp_mib_counters mib;
u32 wolopts;
u8 sopass[SOPASS_MAX];
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
index 59d853c2293c..81a84ba7a394 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#define pr_fmt(fmt)"bcmasp_ethtool: " fmt
+#include
#include
#include
#include
@@ -8,6 +9,162 @@
#include "bcmasp.h"
#include "bcmasp_intf_defs.h"
+enum bcmasp_stat_type {
+ BCMASP_STAT_RX_EDPKT,
+ BCMASP_STAT_RX_CTRL,
+ BCMASP_STAT_RX_CTRL_PER_INTF,
+ BCMASP_STAT_SOFT,
+};
+
+struct bcmasp_stats {
+ char stat_string[ETH_GSTRING_LEN];
+ enum bcmasp_stat_type type;
+ u32 reg_offset;
+};
+
+#define STAT_BCMASP_SOFT_MIB(str) { \
+ .stat_string = str, \
+ .type = BCMASP_STAT_SOFT, \
+}
+
+#define STAT_BCMASP_OFFSET(str, _type, offset) { \
+ .stat_string = str, \
+ .type = _type, \
+ .reg_offset = offset, \
+}
+
+#define STAT_BCMASP_RX_EDPKT(str, offset) \
+ STAT_BCMASP_OFFSET(str, BCMASP_STAT_RX_EDPKT, offset)
+#define STAT_BCMASP_RX_CTRL(str, offset) \
+ STAT_BCMASP_OFFSET(str, BCMASP_STAT_RX_CTRL, offset)
+#define STAT_BCMASP_RX_CTRL_PER_INTF(str, offset) \
+ STAT_BCMASP_OFFSET(str, BCMASP_STAT_RX_CTRL_PER_INTF, offset)
+
+/* Must match the order of struct bcmasp_mib_counters */
+static const struct bcmasp_stats bcmasp_gstrings_stats[] = {
+ /* EDPKT counters */
+ STAT_BCMASP_RX_EDPKT("RX Time Stamp", ASP_EDPKT_RX_TS_COUNTER),
+ STAT_BCMASP_RX_EDPKT("RX PKT Count", ASP_EDPKT_RX_PKT_CNT),
+ STAT_BCMASP_RX_EDPKT("RX PKT Buffered", ASP_EDPKT_HDR_EXTR_CNT),
+ STAT_BCMASP_RX_EDPKT("RX PKT Pushed to DRAM", ASP_EDPKT_HDR_OUT_CNT),
+ /* ASP RX control */
+ STAT_BCMASP_RX_CTRL_PER_INTF("Frames From Unimac",
+ASP_RX_CTRL_UMAC_0_FRAME_COUNT),
+ STAT_BCMASP_RX_CTRL_PER_INTF("Frames From Port",
+ASP_RX_CTRL_FB_0_FRAME_COUNT),
+ STAT_BCMASP_RX_CTRL_PER_INTF("RX Buffer FIFO Depth",
+ASP_RX_CTRL_FB_RX_FIFO_DEPTH),
+ STAT_BCMASP_RX_CTRL("Frames Out(Buffer)",
+ ASP_RX_CTRL_FB_OUT_FRAME_COUNT),
+ STAT_BCMASP_RX_CTRL("Frames Out(Filters)",
+
[PATCH net-next v8 09/11] net: phy: mdio-bcm-unimac: Add asp v2.0 support
Add mdio compat string for ASP 2.0 ethernet driver.
Reviewed-by: Simon Horman
Reviewed-by: Andrew Lunn
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
drivers/net/mdio/mdio-bcm-unimac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/mdio/mdio-bcm-unimac.c
b/drivers/net/mdio/mdio-bcm-unimac.c
index bfc9be23c973..6b26a0803696 100644
--- a/drivers/net/mdio/mdio-bcm-unimac.c
+++ b/drivers/net/mdio/mdio-bcm-unimac.c
@@ -334,6 +334,8 @@ static SIMPLE_DEV_PM_OPS(unimac_mdio_pm_ops,
unimac_mdio_suspend, unimac_mdio_resume);
static const struct of_device_id unimac_mdio_ids[] = {
+ { .compatible = "brcm,asp-v2.1-mdio", },
+ { .compatible = "brcm,asp-v2.0-mdio", },
{ .compatible = "brcm,genet-mdio-v5", },
{ .compatible = "brcm,genet-mdio-v4", },
{ .compatible = "brcm,genet-mdio-v3", },
--
2.7.4
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH net-next v8 10/11] net: phy: bcm7xxx: Add EPHY entry for 74165
From: Florian Fainelli
74165 is a 16nm process SoC with a 10/100 integrated Ethernet PHY,
utilize the recently defined 16nm EPHY macro to configure that PHY.
Reviewed-by: Simon Horman
Reviewed-by: Andrew Lunn
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
drivers/net/phy/bcm7xxx.c | 1 +
include/linux/brcmphy.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index f8c17a253f8b..8478b081c058 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -913,6 +913,7 @@ static struct phy_driver bcm7xxx_driver[] = {
BCM7XXX_28NM_GPHY(PHY_ID_BCM7278, "Broadcom BCM7278"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7364, "Broadcom BCM7364"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7366, "Broadcom BCM7366"),
+ BCM7XXX_16NM_EPHY(PHY_ID_BCM74165, "Broadcom BCM74165"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM74371, "Broadcom BCM74371"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7439, "Broadcom BCM7439"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7439_2, "Broadcom BCM7439 (2)"),
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 5d732f48f787..c55810a43541 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -44,6 +44,7 @@
#define PHY_ID_BCM7366 0x600d8490
#define PHY_ID_BCM7346 0x600d8650
#define PHY_ID_BCM7362 0x600d84b0
+#define PHY_ID_BCM741650x359052c0
#define PHY_ID_BCM7425 0x600d86b0
#define PHY_ID_BCM7429 0x600d8730
#define PHY_ID_BCM7435 0x600d8750
--
2.7.4
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH net-next v8 05/11] net: bcmasp: Add support for wake on net filters
Add support for wake on network filters. The max match is 256 bytes.
Signed-off-by: Justin Chen
---
drivers/net/ethernet/broadcom/asp2/bcmasp.c| 595 +
drivers/net/ethernet/broadcom/asp2/bcmasp.h| 40 ++
.../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 131 -
drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 3 +
4 files changed, 768 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
index 40143bb566ef..51b7aa8365c8 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
@@ -130,6 +130,597 @@ void bcmasp_flush_rx_port(struct bcmasp_intf *intf)
rx_ctrl_core_wl(priv, mask, priv->hw_info->rx_ctrl_flush);
}
+static void bcmasp_netfilt_hw_en_wake(struct bcmasp_priv *priv,
+ struct bcmasp_net_filter *nfilt)
+{
+ rx_filter_core_wl(priv, ASP_RX_FILTER_NET_OFFSET_L3_1(64),
+ ASP_RX_FILTER_NET_OFFSET(nfilt->hw_index));
+
+ rx_filter_core_wl(priv, ASP_RX_FILTER_NET_OFFSET_L2(32) |
+ ASP_RX_FILTER_NET_OFFSET_L3_0(32) |
+ ASP_RX_FILTER_NET_OFFSET_L3_1(96) |
+ ASP_RX_FILTER_NET_OFFSET_L4(32),
+ ASP_RX_FILTER_NET_OFFSET(nfilt->hw_index + 1));
+
+ rx_filter_core_wl(priv, ASP_RX_FILTER_NET_CFG_CH(nfilt->port + 8) |
+ ASP_RX_FILTER_NET_CFG_EN |
+ ASP_RX_FILTER_NET_CFG_L2_EN |
+ ASP_RX_FILTER_NET_CFG_L3_EN |
+ ASP_RX_FILTER_NET_CFG_L4_EN |
+ ASP_RX_FILTER_NET_CFG_L3_FRM(2) |
+ ASP_RX_FILTER_NET_CFG_L4_FRM(2) |
+ ASP_RX_FILTER_NET_CFG_UMC(nfilt->port),
+ ASP_RX_FILTER_NET_CFG(nfilt->hw_index));
+
+ rx_filter_core_wl(priv, ASP_RX_FILTER_NET_CFG_CH(nfilt->port + 8) |
+ ASP_RX_FILTER_NET_CFG_EN |
+ ASP_RX_FILTER_NET_CFG_L2_EN |
+ ASP_RX_FILTER_NET_CFG_L3_EN |
+ ASP_RX_FILTER_NET_CFG_L4_EN |
+ ASP_RX_FILTER_NET_CFG_L3_FRM(2) |
+ ASP_RX_FILTER_NET_CFG_L4_FRM(2) |
+ ASP_RX_FILTER_NET_CFG_UMC(nfilt->port),
+ ASP_RX_FILTER_NET_CFG(nfilt->hw_index + 1));
+}
+
+#define MAX_WAKE_FILTER_SIZE 256
+enum asp_netfilt_reg_type {
+ ASP_NETFILT_MATCH = 0,
+ ASP_NETFILT_MASK,
+ ASP_NETFILT_MAX
+};
+
+static int bcmasp_netfilt_get_reg_offset(struct bcmasp_priv *priv,
+struct bcmasp_net_filter *nfilt,
+enum asp_netfilt_reg_type reg_type,
+u32 offset)
+{
+ u32 block_index, filter_sel;
+
+ if (offset < 32) {
+ block_index = ASP_RX_FILTER_NET_L2;
+ filter_sel = nfilt->hw_index;
+ } else if (offset < 64) {
+ block_index = ASP_RX_FILTER_NET_L2;
+ filter_sel = nfilt->hw_index + 1;
+ } else if (offset < 96) {
+ block_index = ASP_RX_FILTER_NET_L3_0;
+ filter_sel = nfilt->hw_index;
+ } else if (offset < 128) {
+ block_index = ASP_RX_FILTER_NET_L3_0;
+ filter_sel = nfilt->hw_index + 1;
+ } else if (offset < 160) {
+ block_index = ASP_RX_FILTER_NET_L3_1;
+ filter_sel = nfilt->hw_index;
+ } else if (offset < 192) {
+ block_index = ASP_RX_FILTER_NET_L3_1;
+ filter_sel = nfilt->hw_index + 1;
+ } else if (offset < 224) {
+ block_index = ASP_RX_FILTER_NET_L4;
+ filter_sel = nfilt->hw_index;
+ } else if (offset < 256) {
+ block_index = ASP_RX_FILTER_NET_L4;
+ filter_sel = nfilt->hw_index + 1;
+ } else {
+ return -EINVAL;
+ }
+
+ switch (reg_type) {
+ case ASP_NETFILT_MATCH:
+ return ASP_RX_FILTER_NET_PAT(filter_sel, block_index,
+(offset % 32));
+ case ASP_NETFILT_MASK:
+ return ASP_RX_FILTER_NET_MASK(filter_sel, block_index,
+ (offset % 32));
+ default:
+ return -EINVAL;
+ }
+}
+
+static void bcmasp_netfilt_wr(struct bcmasp_priv *priv,
+ struct bcmasp_net_filter *nfilt,
+ enum asp_netfilt_reg_type reg_type,
+ u32 val, u32 offset)
+{
+ int reg_offset;
+
+ /* HW only accepts 4 byte aligned writes */
+ if (!IS_ALIGNED(offset, 4) || offset > MAX_WAKE_FILTER_SIZE)
+ return;
+
+ reg_offset =
[PATCH net-next v8 07/11] net: bcmasp: Add support for ethtool standard stats
Add support for eth_mac_stats, rmon_stats, and eth_ctrl_stats.
Signed-off-by: Justin Chen
---
.../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 77 ++
.../net/ethernet/broadcom/asp2/bcmasp_intf_defs.h | 63 +-
2 files changed, 139 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
index 1e96a69043f3..59d853c2293c 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
@@ -250,6 +250,80 @@ static int bcmasp_set_eee(struct net_device *dev, struct
ethtool_eee *e)
return phy_ethtool_set_eee(dev->phydev, e);
}
+static void bcmasp_get_eth_mac_stats(struct net_device *dev,
+struct ethtool_eth_mac_stats *mac_stats)
+{
+ struct bcmasp_intf *intf = netdev_priv(dev);
+
+ mac_stats->FramesTransmittedOK = umac_rl(intf, UMC_GTPOK);
+ mac_stats->SingleCollisionFrames = umac_rl(intf, UMC_GTSCL);
+ mac_stats->MultipleCollisionFrames = umac_rl(intf, UMC_GTMCL);
+ mac_stats->FramesReceivedOK = umac_rl(intf, UMC_GRPOK);
+ mac_stats->FrameCheckSequenceErrors = umac_rl(intf, UMC_GRFCS);
+ mac_stats->AlignmentErrors = umac_rl(intf, UMC_GRALN);
+ mac_stats->OctetsTransmittedOK = umac_rl(intf, UMC_GTBYT);
+ mac_stats->FramesWithDeferredXmissions = umac_rl(intf, UMC_GTDRF);
+ mac_stats->LateCollisions = umac_rl(intf, UMC_GTLCL);
+ mac_stats->FramesAbortedDueToXSColls = umac_rl(intf, UMC_GTXCL);
+ mac_stats->OctetsReceivedOK = umac_rl(intf, UMC_GRBYT);
+ mac_stats->MulticastFramesXmittedOK = umac_rl(intf, UMC_GTMCA);
+ mac_stats->BroadcastFramesXmittedOK = umac_rl(intf, UMC_GTBCA);
+ mac_stats->FramesWithExcessiveDeferral = umac_rl(intf, UMC_GTEDF);
+ mac_stats->MulticastFramesReceivedOK = umac_rl(intf, UMC_GRMCA);
+ mac_stats->BroadcastFramesReceivedOK = umac_rl(intf, UMC_GRBCA);
+}
+
+static const struct ethtool_rmon_hist_range bcmasp_rmon_ranges[] = {
+ {0, 64},
+ { 65, 127},
+ { 128, 255},
+ { 256, 511},
+ { 512, 1023},
+ { 1024, 1518},
+ { 1519, 1522},
+ {}
+};
+
+static void bcmasp_get_rmon_stats(struct net_device *dev,
+ struct ethtool_rmon_stats *rmon_stats,
+ const struct ethtool_rmon_hist_range **ranges)
+{
+ struct bcmasp_intf *intf = netdev_priv(dev);
+
+ *ranges = bcmasp_rmon_ranges;
+
+ rmon_stats->undersize_pkts = umac_rl(intf, UMC_RRUND);
+ rmon_stats->oversize_pkts = umac_rl(intf, UMC_GROVR);
+ rmon_stats->fragments = umac_rl(intf, UMC_RRFRG);
+ rmon_stats->jabbers = umac_rl(intf, UMC_GRJBR);
+
+ rmon_stats->hist[0] = umac_rl(intf, UMC_GR64);
+ rmon_stats->hist[1] = umac_rl(intf, UMC_GR127);
+ rmon_stats->hist[2] = umac_rl(intf, UMC_GR255);
+ rmon_stats->hist[3] = umac_rl(intf, UMC_GR511);
+ rmon_stats->hist[4] = umac_rl(intf, UMC_GR1023);
+ rmon_stats->hist[5] = umac_rl(intf, UMC_GR1518);
+ rmon_stats->hist[6] = umac_rl(intf, UMC_GRMGV);
+
+ rmon_stats->hist_tx[0] = umac_rl(intf, UMC_TR64);
+ rmon_stats->hist_tx[1] = umac_rl(intf, UMC_TR127);
+ rmon_stats->hist_tx[2] = umac_rl(intf, UMC_TR255);
+ rmon_stats->hist_tx[3] = umac_rl(intf, UMC_TR511);
+ rmon_stats->hist_tx[4] = umac_rl(intf, UMC_TR1023);
+ rmon_stats->hist_tx[5] = umac_rl(intf, UMC_TR1518);
+ rmon_stats->hist_tx[6] = umac_rl(intf, UMC_TRMGV);
+}
+
+static void bcmasp_get_eth_ctrl_stats(struct net_device *dev,
+ struct ethtool_eth_ctrl_stats *ctrl_stats)
+{
+ struct bcmasp_intf *intf = netdev_priv(dev);
+
+ ctrl_stats->MACControlFramesTransmitted = umac_rl(intf, UMC_GTXCF);
+ ctrl_stats->MACControlFramesReceived = umac_rl(intf, UMC_GRXCF);
+ ctrl_stats->UnsupportedOpcodesReceived = umac_rl(intf, UMC_GRXUO);
+}
+
const struct ethtool_ops bcmasp_ethtool_ops = {
.get_drvinfo= bcmasp_get_drvinfo,
.get_link = ethtool_op_get_link,
@@ -263,4 +337,7 @@ const struct ethtool_ops bcmasp_ethtool_ops = {
.set_rxnfc = bcmasp_set_rxnfc,
.set_eee= bcmasp_set_eee,
.get_eee= bcmasp_get_eee,
+ .get_eth_mac_stats = bcmasp_get_eth_mac_stats,
+ .get_rmon_stats = bcmasp_get_rmon_stats,
+ .get_eth_ctrl_stats = bcmasp_get_eth_ctrl_stats,
};
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h
b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h
index b259a475207f..ad742612895f 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h
@@ -45,7 +45,68 @@
#define UMC_EEE_LPI_TIMER
[PATCH net-next v8 06/11] net: bcmasp: Add support for eee mode
Add support for eee mode.
Signed-off-by: Justin Chen
---
drivers/net/ethernet/broadcom/asp2/bcmasp.h| 4 ++
.../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 61 ++
drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 6 +++
3 files changed, 71 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.h
b/drivers/net/ethernet/broadcom/asp2/bcmasp.h
index e791b869006e..d6740077877a 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp.h
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.h
@@ -313,6 +313,8 @@ struct bcmasp_intf {
/* Used if per intf wol irq */
int wol_irq;
unsigned intwol_irq_enabled:1;
+
+ struct ethtool_eee eee;
};
#define NUM_NET_FILTERS32
@@ -559,4 +561,6 @@ void bcmasp_netfilt_get_all_active(struct bcmasp_intf
*intf, u32 *rule_locs,
u32 *rule_cnt);
void bcmasp_netfilt_suspend(struct bcmasp_intf *intf);
+
+void bcmasp_eee_enable_set(struct bcmasp_intf *intf, bool enable);
#endif
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
index eddd1c43f00e..1e96a69043f3 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
@@ -191,6 +191,65 @@ static int bcmasp_get_rxnfc(struct net_device *dev, struct
ethtool_rxnfc *cmd,
return err;
}
+void bcmasp_eee_enable_set(struct bcmasp_intf *intf, bool enable)
+{
+ u32 reg;
+
+ reg = umac_rl(intf, UMC_EEE_CTRL);
+ if (enable)
+ reg |= EEE_EN;
+ else
+ reg &= ~EEE_EN;
+ umac_wl(intf, reg, UMC_EEE_CTRL);
+
+ intf->eee.eee_enabled = enable;
+ intf->eee.eee_active = enable;
+}
+
+static int bcmasp_get_eee(struct net_device *dev, struct ethtool_eee *e)
+{
+ struct bcmasp_intf *intf = netdev_priv(dev);
+ struct ethtool_eee *p = >eee;
+
+ if (!dev->phydev)
+ return -ENODEV;
+
+ e->eee_enabled = p->eee_enabled;
+ e->eee_active = p->eee_active;
+ e->tx_lpi_enabled = p->tx_lpi_enabled;
+ e->tx_lpi_timer = umac_rl(intf, UMC_EEE_LPI_TIMER);
+
+ return phy_ethtool_get_eee(dev->phydev, e);
+}
+
+static int bcmasp_set_eee(struct net_device *dev, struct ethtool_eee *e)
+{
+ struct bcmasp_intf *intf = netdev_priv(dev);
+ struct ethtool_eee *p = >eee;
+ int ret;
+
+ if (!dev->phydev)
+ return -ENODEV;
+
+ if (!p->eee_enabled) {
+ bcmasp_eee_enable_set(intf, false);
+ } else {
+ ret = phy_init_eee(dev->phydev, 0);
+ if (ret) {
+ netif_err(intf, hw, dev,
+ "EEE initialization failed: %d\n", ret);
+ return ret;
+ }
+
+ umac_wl(intf, e->tx_lpi_timer, UMC_EEE_LPI_TIMER);
+ intf->eee.eee_active = ret >= 0;
+ intf->eee.tx_lpi_enabled = e->tx_lpi_enabled;
+ bcmasp_eee_enable_set(intf, true);
+ }
+
+ return phy_ethtool_set_eee(dev->phydev, e);
+}
+
const struct ethtool_ops bcmasp_ethtool_ops = {
.get_drvinfo= bcmasp_get_drvinfo,
.get_link = ethtool_op_get_link,
@@ -202,4 +261,6 @@ const struct ethtool_ops bcmasp_ethtool_ops = {
.set_wol= bcmasp_set_wol,
.get_rxnfc = bcmasp_get_rxnfc,
.set_rxnfc = bcmasp_set_rxnfc,
+ .set_eee= bcmasp_set_eee,
+ .get_eee= bcmasp_get_eee,
};
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
index e221f07bf743..2c8a9d5711de 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
@@ -653,6 +653,9 @@ static void bcmasp_adj_link(struct net_device *dev)
UMC_CMD_TX_PAUSE_IGNORE);
reg |= cmd_bits;
umac_wl(intf, reg, UMC_CMD);
+
+ intf->eee.eee_active = phy_init_eee(phydev, 0) >= 0;
+ bcmasp_eee_enable_set(intf, intf->eee.eee_active);
}
reg = rgmii_rl(intf, RGMII_OOB_CNTRL);
@@ -1403,6 +1406,9 @@ int bcmasp_interface_resume(struct bcmasp_intf *intf)
bcmasp_resume_from_wol(intf);
+ if (intf->eee.eee_enabled)
+ bcmasp_eee_enable_set(intf, true);
+
netif_device_attach(dev);
return 0;
--
2.7.4
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH net-next v8 04/11] net: bcmasp: Add support for WoL magic packet
Add support for Wake-On-Lan magic packet and magic packet with password.
Signed-off-by: Justin Chen
---
drivers/net/ethernet/broadcom/asp2/bcmasp.c| 148 +
drivers/net/ethernet/broadcom/asp2/bcmasp.h| 18 +++
.../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 36 +
drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 76 +--
4 files changed, 266 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
index 34a0c7545ebd..40143bb566ef 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
@@ -440,6 +440,139 @@ static int bcmasp_is_port_valid(struct bcmasp_priv *priv,
int port)
return port == 0 || port == 1;
}
+static irqreturn_t bcmasp_isr_wol(int irq, void *data)
+{
+ struct bcmasp_priv *priv = data;
+ u32 status;
+
+ /* No L3 IRQ, so we good */
+ if (priv->wol_irq <= 0)
+ goto irq_handled;
+
+ status = wakeup_intr2_core_rl(priv, ASP_WAKEUP_INTR2_STATUS) &
+ ~wakeup_intr2_core_rl(priv, ASP_WAKEUP_INTR2_MASK_STATUS);
+ wakeup_intr2_core_wl(priv, status, ASP_WAKEUP_INTR2_CLEAR);
+
+irq_handled:
+ pm_wakeup_event(>pdev->dev, 0);
+ return IRQ_HANDLED;
+}
+
+static int bcmasp_get_and_request_irq(struct bcmasp_priv *priv, int i)
+{
+ struct platform_device *pdev = priv->pdev;
+ int irq, ret;
+
+ irq = platform_get_irq_optional(pdev, i);
+ if (irq < 0)
+ return irq;
+
+ ret = devm_request_irq(>dev, irq, bcmasp_isr_wol, 0,
+ pdev->name, priv);
+ if (ret)
+ return ret;
+
+ return irq;
+}
+
+static void bcmasp_init_wol_shared(struct bcmasp_priv *priv)
+{
+ struct platform_device *pdev = priv->pdev;
+ struct device *dev = >dev;
+ int irq;
+
+ irq = bcmasp_get_and_request_irq(priv, 1);
+ if (irq < 0) {
+ dev_warn(dev, "Failed to init WoL irq: %d\n", irq);
+ return;
+ }
+
+ priv->wol_irq = irq;
+ priv->wol_irq_enabled_mask = 0;
+ device_set_wakeup_capable(>dev, 1);
+}
+
+static void bcmasp_enable_wol_shared(struct bcmasp_intf *intf, bool en)
+{
+ struct bcmasp_priv *priv = intf->parent;
+ struct device *dev = >pdev->dev;
+
+ if (en) {
+ if (priv->wol_irq_enabled_mask) {
+ set_bit(intf->port, >wol_irq_enabled_mask);
+ return;
+ }
+
+ /* First enable */
+ set_bit(intf->port, >wol_irq_enabled_mask);
+ enable_irq_wake(priv->wol_irq);
+ device_set_wakeup_enable(dev, 1);
+ } else {
+ if (!priv->wol_irq_enabled_mask)
+ return;
+
+ clear_bit(intf->port, >wol_irq_enabled_mask);
+ if (priv->wol_irq_enabled_mask)
+ return;
+
+ /* Last disable */
+ disable_irq_wake(priv->wol_irq);
+ device_set_wakeup_enable(dev, 0);
+ }
+}
+
+static void bcmasp_wol_irq_destroy_shared(struct bcmasp_priv *priv)
+{
+ if (priv->wol_irq > 0)
+ free_irq(priv->wol_irq, priv);
+}
+
+static void bcmasp_init_wol_per_intf(struct bcmasp_priv *priv)
+{
+ struct platform_device *pdev = priv->pdev;
+ struct device *dev = >dev;
+ struct bcmasp_intf *intf;
+ int irq, i;
+
+ for (i = 0; i < priv->intf_count; i++) {
+ intf = priv->intfs[i];
+ irq = bcmasp_get_and_request_irq(priv, intf->port + 1);
+ if (irq < 0) {
+ dev_warn(dev, "Failed to init WoL irq(port %d): %d\n",
+intf->port, irq);
+ continue;
+ }
+
+ intf->wol_irq = irq;
+ intf->wol_irq_enabled = false;
+ device_set_wakeup_capable(>dev, 1);
+ }
+}
+
+static void bcmasp_enable_wol_per_intf(struct bcmasp_intf *intf, bool en)
+{
+ struct device *dev = >parent->pdev->dev;
+
+ if (en ^ intf->wol_irq_enabled)
+ irq_set_irq_wake(intf->wol_irq, en);
+
+ intf->wol_irq_enabled = en;
+ device_set_wakeup_enable(dev, en);
+}
+
+static void bcmasp_wol_irq_destroy_per_intf(struct bcmasp_priv *priv)
+{
+ struct bcmasp_intf *intf;
+ int i;
+
+ for (i = 0; i < priv->intf_count; i++) {
+ intf = priv->intfs[i];
+
+ if (intf->wol_irq > 0)
+ free_irq(intf->wol_irq, priv);
+ }
+}
+
static struct bcmasp_hw_info v20_hw_info = {
.rx_ctrl_flush = ASP_RX_CTRL_FLUSH,
.umac2fb = UMAC2FB_OFFSET,
@@ -449,6 +582,9 @@ static struct bcmasp_hw_info v20_hw_info = {
};
static const struct bcmasp_plat_data v20_plat_data = {
+ .init_wol =
[PATCH net-next v8 03/11] net: bcmasp: Add support for ASP2.0 Ethernet controller
Add support for the Broadcom ASP 2.0 Ethernet controller which is first
introduced with 72165. This controller features two distinct Ethernet
ports that can be independently operated.
Reviewed-by: Simon Horman
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
v8
- Address some checkpatch warnings
v7
- Fixed leaking ports_node device node.
- Split out to smaller commits
v6
- Fixed a reserved mac filter indexing error
- Removed tx_lock
- Simplified tx_timeout hook
- Removed get_stats
- Fixed phy ioctl
- Fixed dev -> ndev typo
- Fixed set_wol double disable
v5
- Remove unnecessary parenthesis
- Use bool for bcmasp_netfilt_check_dup()
v4
- Address sparse warnings
- Fix one more reverse xmas tree violation
- Improve error logic for bcmasp_netfilt_get_reg_offset()
- Remove inlines
v3
- Fix logic error with net stats where some stats were missing
- General clean up addressing formatting/spelling/consistency
- Use dev_err_probe to save a few LoCs
- Use put_unaligned when updating net stats
v2
- Replace a couple functions with helper functions
- Fix a few WoL issues
drivers/net/ethernet/broadcom/Kconfig | 11 +
drivers/net/ethernet/broadcom/Makefile |1 +
drivers/net/ethernet/broadcom/asp2/Makefile|2 +
drivers/net/ethernet/broadcom/asp2/bcmasp.c| 726 +++
drivers/net/ethernet/broadcom/asp2/bcmasp.h| 504
.../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 40 +
drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 1358
.../net/ethernet/broadcom/asp2/bcmasp_intf_defs.h | 196 +++
8 files changed, 2838 insertions(+)
create mode 100644 drivers/net/ethernet/broadcom/asp2/Makefile
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.c
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.h
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h
diff --git a/drivers/net/ethernet/broadcom/Kconfig
b/drivers/net/ethernet/broadcom/Kconfig
index 948586bf1b5b..d4166141145d 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -255,4 +255,15 @@ config BNXT_HWMON
Say Y if you want to expose the thermal sensor data on NetXtreme-C/E
devices, via the hwmon sysfs interface.
+config BCMASP
+ tristate "Broadcom ASP 2.0 Ethernet support"
+ default ARCH_BRCMSTB
+ depends on OF
+ select MII
+ select PHYLIB
+ select MDIO_BCM_UNIMAC
+ help
+ This configuration enables the Broadcom ASP 2.0 Ethernet controller
+ driver which is present in Broadcom STB SoCs such as 72165.
+
endif # NET_VENDOR_BROADCOM
diff --git a/drivers/net/ethernet/broadcom/Makefile
b/drivers/net/ethernet/broadcom/Makefile
index 0ddfb5b5d53c..bac5cb6ad0cd 100644
--- a/drivers/net/ethernet/broadcom/Makefile
+++ b/drivers/net/ethernet/broadcom/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_BGMAC_BCMA) += bgmac-bcma.o bgmac-bcma-mdio.o
obj-$(CONFIG_BGMAC_PLATFORM) += bgmac-platform.o
obj-$(CONFIG_SYSTEMPORT) += bcmsysport.o
obj-$(CONFIG_BNXT) += bnxt/
+obj-$(CONFIG_BCMASP) += asp2/
diff --git a/drivers/net/ethernet/broadcom/asp2/Makefile
b/drivers/net/ethernet/broadcom/asp2/Makefile
new file mode 100644
index ..e07550315f83
--- /dev/null
+++ b/drivers/net/ethernet/broadcom/asp2/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_BCMASP) += bcm-asp.o
+bcm-asp-objs := bcmasp.o bcmasp_intf.o bcmasp_ethtool.o
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
new file mode 100644
index ..34a0c7545ebd
--- /dev/null
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
@@ -0,0 +1,726 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Broadcom STB ASP 2.0 Driver
+ *
+ * Copyright (c) 2023 Broadcom
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "bcmasp.h"
+#include "bcmasp_intf_defs.h"
+
+static void _intr2_mask_clear(struct bcmasp_priv *priv, u32 mask)
+{
+ intr2_core_wl(priv, mask, ASP_INTR2_MASK_CLEAR);
+ priv->irq_mask &= ~mask;
+}
+
+static void _intr2_mask_set(struct bcmasp_priv *priv, u32 mask)
+{
+ intr2_core_wl(priv, mask, ASP_INTR2_MASK_SET);
+ priv->irq_mask |= mask;
+}
+
+void bcmasp_enable_tx_irq(struct bcmasp_intf *intf, int en)
+{
+ struct bcmasp_priv *priv = intf->parent;
+
+ if (en)
+ _intr2_mask_clear(priv, ASP_INTR2_TX_DESC(intf->channel));
+ else
+ _intr2_mask_set(priv, ASP_INTR2_TX_DESC(intf->channel));
+}
+EXPORT_SYMBOL_GPL(bcmasp_enable_tx_irq);
+
[PATCH net-next v8 02/11] dt-bindings: net: Brcm ASP 2.0 Ethernet controller
From: Florian Fainelli
Add a binding document for the Broadcom ASP 2.0 Ethernet
controller.
Reviewed-by: Conor Dooley
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
v7
- Added "unevaluatedProperties: False"
v6
- Moved compatible to the top
- Changed quotes to be consistent
- Elaborated on brcm,channel description
v5
- Fix compatible string yaml format to properly capture what we want
v4
- Adjust compatible string example to reference SoC and HW ver
v3
- Minor formatting issues
- Change channel prop to brcm,channel for vendor specific format
- Removed redundant v2.0 from compat string
- Fix ranges field
v2
- Minor formatting issues
.../devicetree/bindings/net/brcm,asp-v2.0.yaml | 155 +
1 file changed, 155 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
new file mode 100644
index ..aa3162c74833
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom ASP 2.0 Ethernet controller
+
+maintainers:
+ - Justin Chen
+ - Florian Fainelli
+
+description: Broadcom Ethernet controller first introduced with 72165
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - brcm,bcm74165-asp
+ - const: brcm,asp-v2.1
+ - items:
+ - enum:
+ - brcm,bcm72165-asp
+ - const: brcm,asp-v2.0
+
+ "#address-cells":
+const: 1
+ "#size-cells":
+const: 1
+
+ reg:
+maxItems: 1
+
+ ranges: true
+
+ interrupts:
+minItems: 1
+items:
+ - description: RX/TX interrupt
+ - description: Port 0 Wake-on-LAN
+ - description: Port 1 Wake-on-LAN
+
+ clocks:
+maxItems: 1
+
+ ethernet-ports:
+type: object
+properties:
+ "#address-cells":
+const: 1
+ "#size-cells":
+const: 0
+
+patternProperties:
+ "^port@[0-9]+$":
+type: object
+
+$ref: ethernet-controller.yaml#
+
+unevaluatedProperties: false
+
+properties:
+ reg:
+maxItems: 1
+description: Port number
+
+ brcm,channel:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+ ASP Channel Number
+
+ The depacketizer channel that consumes packets from
+ the unimac/port.
+
+required:
+ - reg
+ - brcm,channel
+
+additionalProperties: false
+
+patternProperties:
+ "^mdio@[0-9a-f]+$":
+type: object
+$ref: brcm,unimac-mdio.yaml
+
+description:
+ ASP internal UniMAC MDIO bus
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+ethernet@9c0 {
+compatible = "brcm,bcm72165-asp", "brcm,asp-v2.0";
+reg = <0x9c0 0x1fff14>;
+interrupts = ;
+ranges = <0x0 0x9c0 0x1fff14>;
+clocks = < 14>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+mdio@c614 {
+compatible = "brcm,asp-v2.0-mdio";
+reg = <0xc614 0x8>;
+reg-names = "mdio";
+#address-cells = <1>;
+#size-cells = <0>;
+
+phy0: ethernet-phy@1 {
+reg = <1>;
+};
+ };
+
+mdio@ce14 {
+compatible = "brcm,asp-v2.0-mdio";
+reg = <0xce14 0x8>;
+reg-names = "mdio";
+#address-cells = <1>;
+#size-cells = <0>;
+
+phy1: ethernet-phy@1 {
+reg = <1>;
+};
+};
+
+ethernet-ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+brcm,channel = <8>;
+phy-mode = "rgmii";
+phy-handle = <>;
+};
+
+port@1 {
+reg = <1>;
+brcm,channel = <9>;
+phy-mode = "rgmii";
+phy-handle = <>;
+};
+};
+};
--
2.7.4
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH net-next v8 00/11] Brcm ASP 2.0 Ethernet Controller
Add support for the Broadcom ASP 2.0 Ethernet controller which is first introduced with 72165. Florian Fainelli (2): dt-bindings: net: Brcm ASP 2.0 Ethernet controller net: phy: bcm7xxx: Add EPHY entry for 74165 Justin Chen (9): dt-bindings: net: brcm,unimac-mdio: Add asp-v2.0 net: bcmasp: Add support for ASP2.0 Ethernet controller net: bcmasp: Add support for WoL magic packet net: bcmasp: Add support for wake on net filters net: bcmasp: Add support for eee mode net: bcmasp: Add support for ethtool standard stats net: bcmasp: Add support for ethtool driver stats net: phy: mdio-bcm-unimac: Add asp v2.0 support MAINTAINERS: ASP 2.0 Ethernet driver maintainers .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 155 +++ .../devicetree/bindings/net/brcm,unimac-mdio.yaml |2 + MAINTAINERS|9 + drivers/net/ethernet/broadcom/Kconfig | 11 + drivers/net/ethernet/broadcom/Makefile |1 + drivers/net/ethernet/broadcom/asp2/Makefile|2 + drivers/net/ethernet/broadcom/asp2/bcmasp.c| 1471 drivers/net/ethernet/broadcom/asp2/bcmasp.h| 587 .../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 503 +++ drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 1430 +++ .../net/ethernet/broadcom/asp2/bcmasp_intf_defs.h | 257 drivers/net/mdio/mdio-bcm-unimac.c |2 + drivers/net/phy/bcm7xxx.c |1 + include/linux/brcmphy.h|1 + 14 files changed, 4432 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml create mode 100644 drivers/net/ethernet/broadcom/asp2/Makefile create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.h create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h -- 2.7.4 smime.p7s Description: S/MIME Cryptographic Signature
[PATCH net-next v8 01/11] dt-bindings: net: brcm, unimac-mdio: Add asp-v2.0
The ASP 2.0 Ethernet controller uses a brcm unimac. Reviewed-by: Simon Horman Acked-by: Conor Dooley Signed-off-by: Florian Fainelli Signed-off-by: Justin Chen --- Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml index 0be426ee1e44..6684810fcbf0 100644 --- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml +++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml @@ -22,6 +22,8 @@ properties: - brcm,genet-mdio-v3 - brcm,genet-mdio-v4 - brcm,genet-mdio-v5 + - brcm,asp-v2.0-mdio + - brcm,asp-v2.1-mdio - brcm,unimac-mdio reg: -- 2.7.4 smime.p7s Description: S/MIME Cryptographic Signature
Re: [git pull] drm fixes for 6.4-rc7
The pull request you sent on Sat, 17 Jun 2023 06:29:31 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-06-17 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1639fae5132bc8a904af28d97cea0bedb3af802e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v3 17/19] drm/msm/dpu: inline INTF_BLK and INTF_BLK_DSI_TE macros
On 2023-06-16 13:03:15, Dmitry Baryshkov wrote:
> To simplify making changes to the hardware block definitions, expand
> corresponding macros. This way making all the changes are more obvious
> and visible in the source files.
>
> Signed-off-by: Dmitry Baryshkov
Looks good but I am not sure how much it is worth to review this (versus
checking your script and rerunning it to see if I get the same results),
considering that there are quite some conflicts with your interrupt
rework. In what order to you intend to land that?
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 52 ++--
> .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 53 ++--
> .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 55 ++--
> .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 82 +---
> .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 55 ++--
> .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 28 +++-
> .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 15 ++-
> .../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h| 28 +++-
> .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 15 ++-
> .../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h| 15 ++-
> .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 55 ++--
> .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 41 --
> .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 120 +-
> .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 55 ++--
> .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 55 ++--
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 30 -
> 16 files changed, 545 insertions(+), 209 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index a71a6cd532c0..d78cedd35c01 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -243,18 +243,46 @@ static const struct dpu_dspp_cfg msm8998_dspp[] = {
> };
>
> static const struct dpu_intf_cfg msm8998_intf[] = {
> - INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP,
> MSM_DP_CONTROLLER_0, 21, INTF_SDM845_MASK,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
> - INTF_BLK("intf_1", INTF_1, 0x6a800, 0x280, INTF_DSI,
> MSM_DSI_CONTROLLER_0, 21, INTF_SDM845_MASK,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27)),
> - INTF_BLK("intf_2", INTF_2, 0x6b000, 0x280, INTF_DSI,
> MSM_DSI_CONTROLLER_1, 21, INTF_SDM845_MASK,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29)),
> - INTF_BLK("intf_3", INTF_3, 0x6b800, 0x280, INTF_HDMI, 0, 21,
> INTF_SDM845_MASK,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31)),
> + {
> + .name = "intf_0", .id = INTF_0,
> + .base = 0x6a000, .len = 0x280,
> + .features = INTF_SDM845_MASK,
> + .type = INTF_DP,
> + .controller_id = MSM_DP_CONTROLLER_0,
> + .prog_fetch_lines_worst_case = 21,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25),
> + .intr_tear_rd_ptr = -1,
> + }, {
> + .name = "intf_1", .id = INTF_1,
> + .base = 0x6a800, .len = 0x280,
> + .features = INTF_SDM845_MASK,
> + .type = INTF_DSI,
> + .controller_id = MSM_DSI_CONTROLLER_0,
> + .prog_fetch_lines_worst_case = 21,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
> + .intr_tear_rd_ptr = -1,
> + }, {
> + .name = "intf_2", .id = INTF_2,
> + .base = 0x6b000, .len = 0x280,
> + .features = INTF_SDM845_MASK,
> + .type = INTF_DSI,
> + .controller_id = MSM_DSI_CONTROLLER_1,
> + .prog_fetch_lines_worst_case = 21,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
> + .intr_tear_rd_ptr = -1,
> + }, {
> + .name = "intf_3", .id = INTF_3,
> + .base = 0x6b800, .len = 0x280,
> + .features = INTF_SDM845_MASK,
> + .type = INTF_HDMI,
> + .prog_fetch_lines_worst_case = 21,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31),
> + .intr_tear_rd_ptr = -1,
> + },
> };
>
> static const struct dpu_perf_cfg msm8998_perf_data = {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index
[PATCH] drm/i915/gt: Remove incorrect hard coded cache coherrency setting
The previouse i915_gem_object_create_internal already set it with proper value before function return. This hard coded setting is incorrect for platforms like MTL, thus need to be removed. Signed-off-by: Zhanjun Dong --- drivers/gpu/drm/i915/gt/intel_timeline.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c index b9640212d659..693d18e14b00 100644 --- a/drivers/gpu/drm/i915/gt/intel_timeline.c +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c @@ -26,8 +26,6 @@ static struct i915_vma *hwsp_alloc(struct intel_gt *gt) if (IS_ERR(obj)) return ERR_CAST(obj); - i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC); - vma = i915_vma_instance(obj, >ggtt->vm, NULL); if (IS_ERR(vma)) i915_gem_object_put(obj); -- 2.34.1
Re: [PATCH v3 02/19] drm/msm/dpu: always use MSM_DP/DSI_CONTROLLER_n
On 2023-06-16 13:03:00, Dmitry Baryshkov wrote:
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> index 8da424eaee6a..8fa9d83a539d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> @@ -169,11 +169,11 @@ static const struct dpu_intf_cfg sm8350_intf[] = {
> INTF_BLK("intf_0", INTF_0, 0x34000, 0x280, INTF_DP,
> MSM_DP_CONTROLLER_0, 24, INTF_SC7280_MASK,
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
> - INTF_BLK_DSI_TE("intf_1", INTF_1, 0x35000, 0x2c4, INTF_DSI, 0, 24,
> INTF_SC7280_MASK,
> + INTF_BLK_DSI_TE("intf_1", INTF_1, 0x35000, 0x2c4, INTF_DSI,
> MSM_DSI_CONTROLLER_0, 24, INTF_SC7280_MASK,
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
> DPU_IRQ_IDX(MDP_INTF1_7xxx_TEAR_INTR, 2)),
This doesn't apply cleanly on top of your interupt rework series: do you
still intend to land that?
> - INTF_BLK_DSI_TE("intf_2", INTF_2, 0x36000, 0x2c4, INTF_DSI, 1, 24,
> INTF_SC7280_MASK,
> + INTF_BLK_DSI_TE("intf_2", INTF_2, 0x36000, 0x2c4, INTF_DSI,
> MSM_DSI_CONTROLLER_1, 24, INTF_SC7280_MASK,
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
> DPU_IRQ_IDX(MDP_INTF2_7xxx_TEAR_INTR, 2)),
- Marijn
Re: [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On 2023-06-16 14:06:47, Abhinav Kumar wrote: > On 6/14/2023 3:49 PM, Marijn Suijten wrote: > > On 2023-06-14 14:23:38, Marijn Suijten wrote: > > > >> Tested this on SM8350 which actually has DSI 2.5, and it is also > >> corrupted with this series so something else on this series might be > >> broken. > > > > Never mind, this was a bad conflict-resolve. Jessica's original > > BURST_MODE patch was RMW'ing MDP_CTRL2, but the upstreamed patch was > > only writing, and the way I conflict-resolved that caused the write of > > BURST_MODE to overwrite the RMW DATABUS_WIDEN. > > > > If both are moved to dsi_ctrl_config(), we could do a read, add both > > flags in conditionally, and write. > > > > So just to confirm, there is no issue on your 8350 setup with widebus > enabled right? After properly conflict-resolving both series so that they either both RMW, or combine the two bit-sets (the same you just discussed _not_ doing on the DPU side for DATABUS_WIDEN|COMPRESSION...) before a single write, it works fine! - Marijn
Re: [Freedreno] [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On 2023-06-16 14:13:22, Abhinav Kumar wrote: > > As I've asked many times before, we should inline these masks (not just > > the macros) (disclaimer: haven't reviewed if Dmitry's series actually > > does so!). > > > > Yes it does inline it. I am halfway through that rework got stuck in one > of the patches. Neat, I'm still going through it but there are some conflicts with other reworks that make it harder to review and test in parallel. > > Tested this on SM8350 which actually has DSI 2.5, and it is also > > corrupted with this series so something else on this series might be > > broken. > > > >>> > >>> Missed this response. That seems strange. > > > > No worries. But don't forget to look at the comments on patch 2/3 > > either. Some of it is a continuation of pclk scaling factor for DSC > > which discussion seems to have ceased on. > > > >>> This series was tested on SM8350 HDK with a command mode panel. > >>> > >>> We will fix the DPU-DSI handshake and post a v2 but your issue needs > >>> investigation in parallel. > >>> > >>> So another bug to track that would be great. > > > > Will see if I can set that up for you! > > > > Now, it seems this is resolved so bug is not needed? Indeed, as mentioned in another message. Looking forward to v2. - Marijn
Re: [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders
On 2023-06-16 14:18:39, Abhinav Kumar wrote: > > > On 6/14/2023 12:56 AM, Dmitry Baryshkov wrote: > > On 14/06/2023 04:57, Jessica Zhang wrote: > >> Add a DPU INTF op to set the DATABUS_WIDEN register to enable the > >> databus-widen mode datapath. > >> > >> Signed-off-by: Jessica Zhang > >> --- > >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ > >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 > >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 3 +++ > >> 3 files changed, 18 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > >> index b856c6286c85..124ba96bebda 100644 > >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > >> @@ -70,6 +70,9 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg( > >> if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression) > >> phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf); > >> + > >> + if (phys_enc->hw_intf->ops.enable_widebus) > >> + phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf); > > > > No. Please provide a single function which takes necessary > > configuration, including compression and wide_bus_enable. > > > > There are two ways to look at this. Your point is coming from the > perspective that its programming the same register but just a different > bit. But that will also make it a bit confusing. > > So lets say the function is called intf_cfg2_xxx(..., bool widebus, bool > data_compress) > > Now for the caller who wants to just enable widebus this will be > > intf_cfg2_xxx(., true, false) > > if we want to do both > > intf_cfg2_xxx(, true, true) > > the last one where we want to do just data_compress(highly unlikely and > not recommended) > > intf_cfg2_xxx(, false, true) > > Now someone looking at the code will have to go and find out what each > bool is. > > Whereas with separate ops, its kind of implicit. That's why you never pass bools as function argument (edge-case if it is the only argument, and its meaning becomes clear from the function name). Use enumerations anywhere else. - Marijn > > For that reason, I dont think this patch is bad at all.
Re: [PATCH 3/3] drm/msm/dsi: Enable DATABUS_WIDEN for DSI command mode
On 6/14/2023 12:49 AM, Dmitry Baryshkov wrote:
On 14/06/2023 04:57, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data per pclk instead of 24.
For all chipsets that support this mode, enable it whenever DSC is
enabled as recommend by the hardware programming guide.
Only enable this for command mode as we are currently unable to validate
it for video mode.
Signed-off-by: Jessica Zhang
---
Note: The dsi.xml.h changes were generated using the headergen2 script in
envytools [1], but the changes to the copyright and rules-ng-ng source
file
paths were dropped.
[1] https://github.com/freedreno/envytools/
drivers/gpu/drm/msm/dsi/dsi.xml.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c | 19 ++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index a4a154601114..2a7d980e12c3 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -664,6 +664,7 @@ static inline uint32_t
DSI_CMD_MODE_MDP_CTRL2_INPUT_RGB_SWAP(enum dsi_rgb_swap v
return ((val) << DSI_CMD_MODE_MDP_CTRL2_INPUT_RGB_SWAP__SHIFT) &
DSI_CMD_MODE_MDP_CTRL2_INPUT_RGB_SWAP__MASK;
}
#define DSI_CMD_MODE_MDP_CTRL2_BURST_MODE 0x0001
+#define DSI_CMD_MODE_MDP_CTRL2_DATABUS_WIDEN 0x0010
#define REG_DSI_CMD_MODE_MDP_STREAM2_CTRL 0x01b8
#define DSI_CMD_MODE_MDP_STREAM2_CTRL_DATA_TYPE__MASK 0x003f
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 5d7b4409e4e9..1da5238e7105 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -927,6 +927,9 @@ static void dsi_timing_setup(struct msm_dsi_host
*msm_host, bool is_bonded_dsi)
u32 hdisplay = mode->hdisplay;
u32 wc;
int ret;
+ bool widebus_supported = msm_host->cfg_hnd->major ==
MSM_DSI_VER_MAJOR_6G &&
+ msm_host->cfg_hnd->minor >= MSM_DSI_6G_VER_MINOR_V2_5_0;
+
DBG("");
@@ -973,8 +976,15 @@ static void dsi_timing_setup(struct msm_dsi_host
*msm_host, bool is_bonded_dsi)
*
* hdisplay will be divided by 3 here to account for the fact
* that DPU sends 3 bytes per pclk cycle to DSI.
+ *
+ * If widebus is supported, set DATABUS_WIDEN register and
divide hdisplay by 6
+ * instead of 3
This is useless, it is already obvious from the code below. Instead
there should be something like "wide bus extends that to 6 bytes per
pclk cycle"
*/
- hdisplay =
DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->dsc), 3);
+ if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) &&
widebus_supported)
+ hdisplay =
DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->dsc), 6);
+ else
+ hdisplay =
DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->dsc), 3);
+
h_total += hdisplay;
ha_end = ha_start + hdisplay;
}
@@ -1027,6 +1037,13 @@ static void dsi_timing_setup(struct
msm_dsi_host *msm_host, bool is_bonded_dsi)
dsi_write(msm_host, REG_DSI_CMD_MDP_STREAM0_TOTAL,
DSI_CMD_MDP_STREAM0_TOTAL_H_TOTAL(hdisplay) |
DSI_CMD_MDP_STREAM0_TOTAL_V_TOTAL(mode->vdisplay));
+
+ if (msm_host->dsc && widebus_supported) {
+ u32 mdp_ctrl2 = dsi_read(msm_host,
REG_DSI_CMD_MODE_MDP_CTRL2);
+
+ mdp_ctrl2 |= DSI_CMD_MODE_MDP_CTRL2_DATABUS_WIDEN;
+ dsi_write(msm_host, REG_DSI_CMD_MODE_MDP_CTRL2, mdp_ctrl2);
Is widebus applicable only to the CMD mode, or video mode can employ it
too?
Video mode can employ it too but like Jessica said in the commit text,
we dont have a setup to validate this for DSI video mode so it was
restricted to cmd mode.
We can leave a note here too.
+ }
}
}
--
2.40.1
Re: [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders
On 6/14/2023 12:56 AM, Dmitry Baryshkov wrote: On 14/06/2023 04:57, Jessica Zhang wrote: Add a DPU INTF op to set the DATABUS_WIDEN register to enable the databus-widen mode datapath. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 3 +++ 3 files changed, 18 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index b856c6286c85..124ba96bebda 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -70,6 +70,9 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg( if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression) phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf); + + if (phys_enc->hw_intf->ops.enable_widebus) + phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf); No. Please provide a single function which takes necessary configuration, including compression and wide_bus_enable. There are two ways to look at this. Your point is coming from the perspective that its programming the same register but just a different bit. But that will also make it a bit confusing. So lets say the function is called intf_cfg2_xxx(..., bool widebus, bool data_compress) Now for the caller who wants to just enable widebus this will be intf_cfg2_xxx(., true, false) if we want to do both intf_cfg2_xxx(, true, true) the last one where we want to do just data_compress(highly unlikely and not recommended) intf_cfg2_xxx(, false, true) Now someone looking at the code will have to go and find out what each bool is. Whereas with separate ops, its kind of implicit. For that reason, I dont think this patch is bad at all.
Re: [Freedreno] [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On 6/14/2023 2:41 PM, Marijn Suijten wrote: On 2023-06-14 13:39:57, Abhinav Kumar wrote: On 6/14/2023 12:54 PM, Abhinav Kumar wrote: On 6/14/2023 12:35 PM, Abhinav Kumar wrote: On 6/14/2023 5:23 AM, Marijn Suijten wrote: On 2023-06-14 15:01:59, Dmitry Baryshkov wrote: On 14/06/2023 14:42, Marijn Suijten wrote: On 2023-06-13 18:57:11, Jessica Zhang wrote: DPU 5.x+ supports a databus widen mode that allows more data to be sent per pclk. Enable this feature flag on all relevant chipsets. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ 2 files changed, 4 insertions(+), 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 36ba3f58dcdf..0be7bf0bfc41 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -103,7 +103,8 @@ (BIT(DPU_INTF_INPUT_CTRL) | \ BIT(DPU_INTF_TE) | \ BIT(DPU_INTF_STATUS_SUPPORTED) | \ - BIT(DPU_DATA_HCTL_EN)) + BIT(DPU_DATA_HCTL_EN) | \ + BIT(DPU_INTF_DATABUS_WIDEN)) This doesn't work. DPU 5.0.0 is SM8150, which has DSI 6G 2.3. In the last patch for DSI you state and enable widebus for DSI 6G 2.5+ only, meaning DPU and DSI are now desynced, and the output is completely corrupted. I looked at the internal docs and also this change. This change is incorrect because this will try to enable widebus for DPU >= 5.0 and DSI >= 2.5 That was not the intended right condition as thats not what the docs say. We should enable for DPU >= 7.0 and DSI >= 2.5 That makes more sense, DSI 2.5 is SM8350 which has DPU 7.0. Is there any combination where this compatibility is broken? That would be the strange thing for me ( not DPU 5.0 and DSI 2.5 as that was incorrect) No clue if there are any interim SoCs... Part of this confusion is because of catalog macro re-use again. Somewhat agreed. SC7180 is a DPU 6.2 SoC, and for this mask to be used across DPU 5.x and above it should have been renamed to SM8150 and as suggested by Dmitry, have DPU_5_x_` as suffix. As I've asked many times before, we should inline these masks (not just the macros) (disclaimer: haven't reviewed if Dmitry's series actually does so!). Yes it does inline it. I am halfway through that rework got stuck in one of the patches. This series is a good candidate and infact I think we should only do core_revision based check on DPU and DSI to avoid bringing the catalog mess into this. Tested this on SM8350 which actually has DSI 2.5, and it is also corrupted with this series so something else on this series might be broken. Missed this response. That seems strange. No worries. But don't forget to look at the comments on patch 2/3 either. Some of it is a continuation of pclk scaling factor for DSC which discussion seems to have ceased on. This series was tested on SM8350 HDK with a command mode panel. We will fix the DPU-DSI handshake and post a v2 but your issue needs investigation in parallel. So another bug to track that would be great. Will see if I can set that up for you! Now, it seems this is resolved so bug is not needed? Is the bound in dsi_host wrong, or do DPU and DSI need to communicate when widebus will be enabled, based on DPU && DSI supporting it? I'd prefer to follow the second approach, as we did for DP. DPU asks the actual video output driver if widebus is to be enabled. I was afraid of this. This series was made on an assumption that the DPU version of widebus and DSI version of widebus would be compatible but looks like already SM8150 is an outlier. Fwiw SM8250 would have been an outlier as well :) Yes, I think we have to go with second approach. DPU queries DSI if it supports widebus and enables it. Thanks for your responses. We will post a v2. No hurry, btw. As alluded to above, let's also look at the comments on patch 2/3 and discuss how this affects pclk. Doesn't it seem very strange that DPU 5.x+ comes with a widebus feature, but the DSI does not until two revisions later? Or is this available on every interface, but only for a different (probably DP) encoder block? Yes its strange. I have clarified this above. Its not strange but appeared strange because we were checking wrong conditions. Hehe :) - Marijn
Re: [Freedreno] [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote: On 14/06/2023 23:39, Abhinav Kumar wrote: On 6/14/2023 12:54 PM, Abhinav Kumar wrote: On 6/14/2023 12:35 PM, Abhinav Kumar wrote: On 6/14/2023 5:23 AM, Marijn Suijten wrote: On 2023-06-14 15:01:59, Dmitry Baryshkov wrote: On 14/06/2023 14:42, Marijn Suijten wrote: On 2023-06-13 18:57:11, Jessica Zhang wrote: DPU 5.x+ supports a databus widen mode that allows more data to be sent per pclk. Enable this feature flag on all relevant chipsets. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ 2 files changed, 4 insertions(+), 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 36ba3f58dcdf..0be7bf0bfc41 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -103,7 +103,8 @@ (BIT(DPU_INTF_INPUT_CTRL) | \ BIT(DPU_INTF_TE) | \ BIT(DPU_INTF_STATUS_SUPPORTED) | \ - BIT(DPU_DATA_HCTL_EN)) + BIT(DPU_DATA_HCTL_EN) | \ + BIT(DPU_INTF_DATABUS_WIDEN)) This doesn't work. DPU 5.0.0 is SM8150, which has DSI 6G 2.3. In the last patch for DSI you state and enable widebus for DSI 6G 2.5+ only, meaning DPU and DSI are now desynced, and the output is completely corrupted. I looked at the internal docs and also this change. This change is incorrect because this will try to enable widebus for DPU >= 5.0 and DSI >= 2.5 That was not the intended right condition as thats not what the docs say. We should enable for DPU >= 7.0 and DSI >= 2.5 Is there any combination where this compatibility is broken? That would be the strange thing for me ( not DPU 5.0 and DSI 2.5 as that was incorrect) Part of this confusion is because of catalog macro re-use again. This series is a good candidate and infact I think we should only do core_revision based check on DPU and DSI to avoid bringing the catalog mess into this. I have just a single request here: can we please have the same approach for both DSI and DP? I don't mind changing DP code if it makes it better. If you don't have better reasons, I like the idea of DSI/DP dictating whether wide bus should be used on the particular interface. It allows us to handle possible errata or corner cases there. Another option would be to make DPU tell DSI / DP whether the wide bus is enabled or not, but I'd say, this is slightly worse solution. Today, DP's widebus does not check if DPU supports that or not. DPU encoder queries the DP whether widebus is available and enables it. We can also do the same thing for DSI. So for intf_type of DSI, DPU encoder will query DSI if it supports widebus. Then DSI will do its version checks and for DSC it will say yes. This way, we will never check for the DPU's core revision for DSI and purely rely of DP/DSI's hw revisions. Thats fine with me because that way we again just rely on the hw revision to enable the feature. But as a result I am still going to drop this patch which adds widebus to the catalog as a dpu cap which I always wanted to do anyway as we will just rely on the DSI and DP hw revisions. Tested this on SM8350 which actually has DSI 2.5, and it is also corrupted with this series so something else on this series might be broken. Missed this response. That seems strange. This series was tested on SM8350 HDK with a command mode panel. We will fix the DPU-DSI handshake and post a v2 but your issue needs investigation in parallel. So another bug to track that would be great. Is the bound in dsi_host wrong, or do DPU and DSI need to communicate when widebus will be enabled, based on DPU && DSI supporting it? I'd prefer to follow the second approach, as we did for DP. DPU asks the actual video output driver if widebus is to be enabled. I was afraid of this. This series was made on an assumption that the DPU version of widebus and DSI version of widebus would be compatible but looks like already SM8150 is an outlier. Yes, I think we have to go with second approach. DPU queries DSI if it supports widebus and enables it. Thanks for your responses. We will post a v2. Doesn't it seem very strange that DPU 5.x+ comes with a widebus feature, but the DSI does not until two revisions later? Or is this available on every interface, but only for a different (probably DP) encoder block? Yes its strange. I have clarified this above. Its not strange but appeared strange because we were checking wrong conditions. - Marijn
Re: [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On 6/14/2023 3:49 PM, Marijn Suijten wrote: On 2023-06-14 14:23:38, Marijn Suijten wrote: Tested this on SM8350 which actually has DSI 2.5, and it is also corrupted with this series so something else on this series might be broken. Never mind, this was a bad conflict-resolve. Jessica's original BURST_MODE patch was RMW'ing MDP_CTRL2, but the upstreamed patch was only writing, and the way I conflict-resolved that caused the write of BURST_MODE to overwrite the RMW DATABUS_WIDEN. If both are moved to dsi_ctrl_config(), we could do a read, add both flags in conditionally, and write. So just to confirm, there is no issue on your 8350 setup with widebus enabled right? - Marijn
[PATCH v2 2/2] drm/panel: boe-tv101wum-nl6: Drop surplus prepare tracking
The DRM panel core already keeps track of if the panel is already
prepared so do not reimplement this.
Reviewed-by: Sam Ravnborg
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index bc806d420ca7..24fbc1629e40 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -50,8 +50,6 @@ struct boe_panel {
struct regulator *avee;
struct regulator *avdd;
struct gpio_desc *enable_gpio;
-
- bool prepared;
};
static int boe_tv110c9m_init(struct mipi_dsi_device *dsi)
@@ -1286,9 +1284,6 @@ static int boe_panel_unprepare(struct drm_panel *panel)
{
struct boe_panel *boe = to_boe_panel(panel);
- if (!boe->prepared)
- return 0;
-
if (boe->desc->discharge_on_disable) {
regulator_disable(boe->avee);
regulator_disable(boe->avdd);
@@ -1307,8 +1302,6 @@ static int boe_panel_unprepare(struct drm_panel *panel)
regulator_disable(boe->pp3300);
}
- boe->prepared = false;
-
return 0;
}
@@ -1317,9 +1310,6 @@ static int boe_panel_prepare(struct drm_panel *panel)
struct boe_panel *boe = to_boe_panel(panel);
int ret;
- if (boe->prepared)
- return 0;
-
gpiod_set_value(boe->enable_gpio, 0);
usleep_range(1000, 1500);
@@ -1357,8 +1347,6 @@ static int boe_panel_prepare(struct drm_panel *panel)
}
}
- boe->prepared = true;
-
return 0;
poweroff:
--
2.34.1
[PATCH v2 1/2] drm/panel: boe-tv101wum-nl6: Drop macros and open code sequences
The boe-tv101wum-nl6 is reinventing the mechanism to send command
sequences that we usually nix during review, but I missed this one
so fixing it up myself.
Also use the explicit function calls to mipi_dsi_dcs_exit_sleep_mode()
and mipi_dsi_dcs_set_display_on() instead of reimplementing them
with homegrown sequences.
Reviewed-by: Sam Ravnborg
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 2408
1 file changed, 1193 insertions(+), 1215 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 783234ae0f57..bc806d420ca7 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -33,7 +33,7 @@ struct panel_desc {
unsigned long mode_flags;
enum mipi_dsi_pixel_format format;
- const struct panel_init_cmd *init_cmds;
+ int (*init)(struct mipi_dsi_device *dsi);
unsigned int lanes;
bool discharge_on_disable;
};
@@ -54,1224 +54,1200 @@ struct boe_panel {
bool prepared;
};
-enum dsi_cmd_type {
- INIT_DCS_CMD,
- DELAY_CMD,
-};
+static int boe_tv110c9m_init(struct mipi_dsi_device *dsi)
+{
+ int ret;
-struct panel_init_cmd {
- enum dsi_cmd_type type;
- size_t len;
- const char *data;
-};
+ mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x20);
+ mipi_dsi_dcs_write_seq(dsi, 0xFB, 0x01);
+ mipi_dsi_dcs_write_seq(dsi, 0x05, 0xD9);
+ mipi_dsi_dcs_write_seq(dsi, 0x07, 0x78);
+ mipi_dsi_dcs_write_seq(dsi, 0x08, 0x5A);
+ mipi_dsi_dcs_write_seq(dsi, 0x0D, 0x63);
+ mipi_dsi_dcs_write_seq(dsi, 0x0E, 0x91);
+ mipi_dsi_dcs_write_seq(dsi, 0x0F, 0x73);
+ mipi_dsi_dcs_write_seq(dsi, 0x95, 0xE6);
+ mipi_dsi_dcs_write_seq(dsi, 0x96, 0xF0);
+ mipi_dsi_dcs_write_seq(dsi, 0x30, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x6D, 0x66);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0xA2);
+ mipi_dsi_dcs_write_seq(dsi, 0x77, 0x3B);
-#define _INIT_DCS_CMD(...) { \
- .type = INIT_DCS_CMD, \
- .len = sizeof((char[]){__VA_ARGS__}), \
- .data = (char[]){__VA_ARGS__} }
-
-#define _INIT_DELAY_CMD(...) { \
- .type = DELAY_CMD,\
- .len = sizeof((char[]){__VA_ARGS__}), \
- .data = (char[]){__VA_ARGS__} }
-
-static const struct panel_init_cmd boe_tv110c9m_init_cmd[] = {
- _INIT_DCS_CMD(0xFF, 0x20),
- _INIT_DCS_CMD(0xFB, 0x01),
- _INIT_DCS_CMD(0x05, 0xD9),
- _INIT_DCS_CMD(0x07, 0x78),
- _INIT_DCS_CMD(0x08, 0x5A),
- _INIT_DCS_CMD(0x0D, 0x63),
- _INIT_DCS_CMD(0x0E, 0x91),
- _INIT_DCS_CMD(0x0F, 0x73),
- _INIT_DCS_CMD(0x95, 0xE6),
- _INIT_DCS_CMD(0x96, 0xF0),
- _INIT_DCS_CMD(0x30, 0x00),
- _INIT_DCS_CMD(0x6D, 0x66),
- _INIT_DCS_CMD(0x75, 0xA2),
- _INIT_DCS_CMD(0x77, 0x3B),
+ mipi_dsi_dcs_write_seq(dsi, 0xB0, 0x00, 0x08, 0x00, 0x23, 0x00, 0x4D,
0x00, 0x6D, 0x00, 0x89, 0x00, 0xA1, 0x00, 0xB6, 0x00, 0xC9);
+ mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x00, 0xDA, 0x01, 0x13, 0x01, 0x3C,
0x01, 0x7E, 0x01, 0xAB, 0x01, 0xF7, 0x02, 0x2F, 0x02, 0x31);
+ mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x02, 0x67, 0x02, 0xA6, 0x02, 0xD1,
0x03, 0x08, 0x03, 0x2E, 0x03, 0x5B, 0x03, 0x6B, 0x03, 0x7B);
+ mipi_dsi_dcs_write_seq(dsi, 0xB3, 0x03, 0x8E, 0x03, 0xA2, 0x03, 0xB7,
0x03, 0xE7, 0x03, 0xFD, 0x03, 0xFF);
- _INIT_DCS_CMD(0xB0, 0x00, 0x08, 0x00, 0x23, 0x00, 0x4D, 0x00, 0x6D,
0x00, 0x89, 0x00, 0xA1, 0x00, 0xB6, 0x00, 0xC9),
- _INIT_DCS_CMD(0xB1, 0x00, 0xDA, 0x01, 0x13, 0x01, 0x3C, 0x01, 0x7E,
0x01, 0xAB, 0x01, 0xF7, 0x02, 0x2F, 0x02, 0x31),
- _INIT_DCS_CMD(0xB2, 0x02, 0x67, 0x02, 0xA6, 0x02, 0xD1, 0x03, 0x08,
0x03, 0x2E, 0x03, 0x5B, 0x03, 0x6B, 0x03, 0x7B),
- _INIT_DCS_CMD(0xB3, 0x03, 0x8E, 0x03, 0xA2, 0x03, 0xB7, 0x03, 0xE7,
0x03, 0xFD, 0x03, 0xFF),
-
- _INIT_DCS_CMD(0xB4, 0x00, 0x08, 0x00, 0x23, 0x00, 0x4D, 0x00, 0x6D,
0x00, 0x89, 0x00, 0xA1, 0x00, 0xB6, 0x00, 0xC9),
- _INIT_DCS_CMD(0xB5, 0x00, 0xDA, 0x01, 0x13, 0x01, 0x3C, 0x01, 0x7E,
0x01, 0xAB, 0x01, 0xF7, 0x02, 0x2F, 0x02, 0x31),
- _INIT_DCS_CMD(0xB6, 0x02, 0x67, 0x02, 0xA6, 0x02, 0xD1, 0x03, 0x08,
0x03, 0x2E, 0x03, 0x5B, 0x03, 0x6B, 0x03, 0x7B),
- _INIT_DCS_CMD(0xB7, 0x03, 0x8E, 0x03, 0xA2, 0x03, 0xB7, 0x03, 0xE7,
0x03, 0xFD, 0x03, 0xFF),
- _INIT_DCS_CMD(0xB8, 0x00, 0x08, 0x00, 0x23, 0x00, 0x4D, 0x00, 0x6D,
0x00, 0x89, 0x00, 0xA1, 0x00, 0xB6, 0x00, 0xC9),
- _INIT_DCS_CMD(0xB9, 0x00, 0xDA, 0x01, 0x13, 0x01, 0x3C, 0x01, 0x7E,
0x01, 0xAB, 0x01, 0xF7, 0x02, 0x2F, 0x02, 0x31),
- _INIT_DCS_CMD(0xBA, 0x02, 0x67, 0x02, 0xA6, 0x02, 0xD1, 0x03, 0x08,
0x03, 0x2E, 0x03, 0x5B, 0x03, 0x6B, 0x03, 0x7B),
- _INIT_DCS_CMD(0xBB, 0x03, 0x8E, 0x03, 0xA2, 0x03, 0xB7, 0x03, 0xE7,
0x03, 0xFD, 0x03, 0xFF),
-
- _INIT_DCS_CMD(0xFF, 0x21),
- _INIT_DCS_CMD(0xFB, 0x01),
-
-
[PATCH v2 0/2] Fix up the boe-tv101wum-nl6 panel driver
This is two patches fixing things I would normally complain about in reviews, but alas I missed this one, so I go in and fix it up myself. Signed-off-by: Linus Walleij --- Changes in v2: - Fix a missed static keyword - Link to v1: https://lore.kernel.org/r/20230615-fix-boe-tv101wum-nl6-v1-0-8ac378405...@linaro.org --- Linus Walleij (2): drm/panel: boe-tv101wum-nl6: Drop macros and open code sequences drm/panel: boe-tv101wum-nl6: Drop surplus prepare tracking drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 2420 1 file changed, 1193 insertions(+), 1227 deletions(-) --- base-commit: ac9a78681b921877518763ba0e89202254349d1b change-id: 20230615-fix-boe-tv101wum-nl6-6aa3fab22b44 Best regards, -- Linus Walleij
[git pull] drm fixes for 6.4-rc7
Hi Linus, Bunch of misc fixes across the board, amdgpu is the usual bulk with a revert and other fixes, nouveau has a race fix that was causing a UAF that was hard hanging systems, otherwise some qaic, bridge and radeon. Dave. drm-fixes-2023-06-17: drm fixes for 6.4-rc7 amdgpu: - GFX9 preemption fixes - Add missing radeon secondary PCI ID - vblflash fixes - SMU 13 fix - VCN 4.0 fix - Re-enable TOPDOWN flag for large BAR systems to fix regression - eDP fix - PSR hang fix - DPIA fix radeon: - fbdev client warning fix qaic: - leak fix - null ptr deref fix nouveau: - use-after-free caused by fence race fix - runtime pm fix - NULL ptr checks bridge: - ti-sn65dsi86: Avoid possible buffer overflow The following changes since commit 858fd168a95c5b9669aac8db6c14a9aeab446375: Linux 6.4-rc6 (2023-06-11 14:35:30 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-06-17 for you to fetch changes up to 9930f518b6a82ff10a3d13e0cbde05cce04f5930: Merge tag 'drm-misc-fixes-2023-06-16' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-06-17 06:11:59 +1000) drm fixes for 6.4-rc7 amdgpu: - GFX9 preemption fixes - Add missing radeon secondary PCI ID - vblflash fixes - SMU 13 fix - VCN 4.0 fix - Re-enable TOPDOWN flag for large BAR systems to fix regression - eDP fix - PSR hang fix - DPIA fix radeon: - fbdev client warning fix qaic: - leak fix - null ptr deref fix nouveau: - use-after-free caused by fence race fix - runtime pm fix - NULL ptr checks bridge: - ti-sn65dsi86: Avoid possible buffer overflow Alex Deucher (1): drm/amdgpu: add missing radeon secondary PCI ID Arunpravin Paneer Selvam (1): Revert "drm/amdgpu: remove TOPDOWN flags when allocating VRAM in large bar system" Carl Vanderlip (1): accel/qaic: Free user handle on interrupted mutex Dave Airlie (3): Merge tag 'amd-drm-fixes-6.4-2023-06-14' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes nouveau: fix client work fence deletion race Merge tag 'drm-misc-fixes-2023-06-16' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Hersen Wu (1): drm/amd/display: edp do not add non-edid timings Jeffrey Hugo (1): accel/qaic: Fix NULL pointer deref in qaic_destroy_drm_device() Jiadong Zhu (4): drm/amdgpu: Reset CP_VMID_PREEMPT after trailing fence signaled drm/amdgpu: Program gds backup address as zero if no gds allocated drm/amdgpu: Modify indirect buffer packages for resubmission drm/amdgpu: Implement gfx9 patch functions for resubmission Kenneth Feng (1): drm/amd/pm: workaround for compute workload type on some skus Mario Limonciello (2): drm/amd: Make sure image is written to trigger VBIOS image update flow drm/amd: Tighten permissions on VBIOS flashing attributes Natalia Petrova (2): drm/nouveau/dp: check for NULL nv_connector->native_mode drm/nouveau: add nv_encoder pointer check for NULL Peichen Huang (1): drm/amd/display: limit DPIA link rate to HBR3 Ratchanan Srirattanamet (1): drm/nouveau: don't detect DSM for non-NVIDIA device Sonny Jiang (1): drm/amdgpu: vcn_4_0 set instance 0 init sched score to 1 Su Hui (1): drm/bridge: ti-sn65dsi86: Avoid possible buffer overflow Thomas Zimmermann (1): drm/radeon: Disable outputs when releasing fbdev client Tom Chung (1): drm/amd/display: fix the system hang while disable PSR drivers/accel/qaic/qaic_drv.c | 4 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 18 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 9 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c | 60 drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.h | 15 +++ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 101 +++-- drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 6 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +++- .../gpu/drm/amd/display/dc/link/link_detection.c | 5 + .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 33 ++- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 + drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 + drivers/gpu/drm/nouveau/nouveau_connector.c| 7 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 14 ++- drivers/gpu/drm/radeon/radeon_fbdev.c | 1 + 18 files changed, 281 insertions(+), 27 deletions(-)
Re: [PATCH AUTOSEL 4.14 5/6] fbdev: imsttfb: Release framebuffer and dealloc cmap on error path
Hi!
> From: Helge Deller
>
> [ Upstream commit 5cf9a090a39c97f4506b7b53739d469b1c05a7e9 ]
>
> Add missing cleanups in error path.
If we insist this is important enough for -stable, it will need
tweaking. The function returns void, so we can't return a value.
Best regards,
Pavel
> +++ b/drivers/video/fbdev/imsttfb.c
> @@ -1452,9 +1452,13 @@ static void init_imstt(struct fb_info *info)
> FBINFO_HWACCEL_FILLRECT |
> FBINFO_HWACCEL_YPAN;
>
> - fb_alloc_cmap(>cmap, 0, 0);
> + if (fb_alloc_cmap(>cmap, 0, 0)) {
> + framebuffer_release(info);
> + return -ENODEV;
> + }
>
> if (register_framebuffer(info) < 0) {
> + fb_dealloc_cmap(>cmap);
> framebuffer_release(info);
> return;
> }
--
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
signature.asc
Description: PGP signature
Re: [PATCH] drm/vmwgfx: Fix shader stage validation
LGTM.
Reviewed-by: Maaz Mombasawala
Maaz Mombasawala (VMware)
On 6/16/2023 12:09 PM, Zack Rusin wrote:
From: Zack Rusin
For multiple commands the driver was not correctly validating the shader
stages resulting in possible kernel oopses. The validation code was only.
if ever, checking the upper bound on the shader stages but never a lower
bound (valid shader stages start at 1 not 0).
Fixes kernel oopses ending up in vmw_binding_add, e.g.:
Oops: [#1] PREEMPT SMP PTI
CPU: 1 PID: 2443 Comm: testcase Not tainted 6.3.0-rc4-vmwgfx #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
Platform, BIOS 6.00 11/12/2020
RIP: 0010:vmw_binding_add+0x4c/0x140 [vmwgfx]
Code: 7e 30 49 83 ff 0e 0f 87 ea 00 00 00 4b 8d 04 7f 89 d2 89 cb 48 c1 e0 03 4c 8b b0
40 3d 93 c0 48 8b 80 48 3d 93 c0 49 0f af de <48> 03 1c d0 4c 01 e3 49 8>
RSP: 0018:b8014416b968 EFLAGS: 00010206
RAX: c0933ec0 RBX: RCX:
RDX: RSI: b8014416b9c0 RDI: b8014316f000
RBP: b8014416b998 R08: 0003 R09: 746f6c735f726564
R10: aaf2bda0 R11: 732e676e69646e69 R12: b8014316f000
R13: b8014416b9c0 R14: 0040 R15: 0006
FS: 7fba8c0af740() GS:8a1277c8() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0007c0933eb8 CR3: 000118244001 CR4: 003706e0
Call Trace:
vmw_view_bindings_add+0xf5/0x1b0 [vmwgfx]
? ___drm_dbg+0x8a/0xb0 [drm]
vmw_cmd_dx_set_shader_res+0x8f/0xc0 [vmwgfx]
vmw_execbuf_process+0x590/0x1360 [vmwgfx]
vmw_execbuf_ioctl+0x173/0x370 [vmwgfx]
? __drm_dev_dbg+0xb4/0xe0 [drm]
? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
drm_ioctl_kernel+0xbc/0x160 [drm]
drm_ioctl+0x2d2/0x580 [drm]
? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
? do_fault+0x1a6/0x420
vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
__x64_sys_ioctl+0x96/0xd0
do_syscall_64+0x5d/0x90
? handle_mm_fault+0xe4/0x2f0
? debug_smp_processor_id+0x1b/0x30
? fpregs_assert_state_consistent+0x2e/0x50
? exit_to_user_mode_prepare+0x40/0x180
? irqentry_exit_to_user_mode+0xd/0x20
? irqentry_exit+0x3f/0x50
? exc_page_fault+0x8b/0x180
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Signed-off-by: Zack Rusin
Cc: secur...@openanolis.org
Reported-by: Ziming Zhang
Testcase-found-by: Niels De Graef
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Cc: # v4.3+
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 29 ++---
2 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 3810a9984a7f..58bfdf203eca 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1513,4 +1513,16 @@ static inline bool vmw_has_fences(struct vmw_private
*vmw)
return (vmw_fifo_caps(vmw) & SVGA_FIFO_CAP_FENCE) != 0;
}
+static inline bool vmw_shadertype_is_valid(enum vmw_sm_type shader_model,
+ u32 shader_type)
+{
+ SVGA3dShaderType max_allowed = SVGA3D_SHADERTYPE_PREDX_MAX;
+
+ if (shader_model >= VMW_SM_5)
+ max_allowed = SVGA3D_SHADERTYPE_MAX;
+ else if (shader_model >= VMW_SM_4)
+ max_allowed = SVGA3D_SHADERTYPE_DX10_MAX;
+ return shader_type >= SVGA3D_SHADERTYPE_MIN && shader_type <
max_allowed;
+}
+
#endif
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 6b9aa2b4ef54..d30c0e3d3ab7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1992,7 +1992,7 @@ static int vmw_cmd_set_shader(struct vmw_private
*dev_priv,
cmd = container_of(header, typeof(*cmd), header);
- if (cmd->body.type >= SVGA3D_SHADERTYPE_PREDX_MAX) {
+ if (!vmw_shadertype_is_valid(VMW_SM_LEGACY, cmd->body.type)) {
VMW_DEBUG_USER("Illegal shader type %u.\n",
(unsigned int) cmd->body.type);
return -EINVAL;
@@ -2115,8 +2115,6 @@ vmw_cmd_dx_set_single_constant_buffer(struct vmw_private
*dev_priv,
SVGA3dCmdHeader *header)
{
VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdDXSetSingleConstantBuffer);
- SVGA3dShaderType max_shader_num = has_sm5_context(dev_priv) ?
- SVGA3D_NUM_SHADERTYPE : SVGA3D_NUM_SHADERTYPE_DX10;
struct vmw_resource *res = NULL;
struct vmw_ctx_validation_info *ctx_node = VMW_GET_CTX_NODE(sw_context);
@@ -2133,6 +2131,14 @@ vmw_cmd_dx_set_single_constant_buffer(struct vmw_private
*dev_priv,
if (unlikely(ret != 0))
return ret;
+ if (!vmw_shadertype_is_valid(dev_priv->sm_type, cmd->body.type) ||
+ cmd->body.slot >= SVGA3D_DX_MAX_CONSTBUFFERS) {
+
[PATCH] drm/vmwgfx: Fix shader stage validation
From: Zack Rusin
For multiple commands the driver was not correctly validating the shader
stages resulting in possible kernel oopses. The validation code was only.
if ever, checking the upper bound on the shader stages but never a lower
bound (valid shader stages start at 1 not 0).
Fixes kernel oopses ending up in vmw_binding_add, e.g.:
Oops: [#1] PREEMPT SMP PTI
CPU: 1 PID: 2443 Comm: testcase Not tainted 6.3.0-rc4-vmwgfx #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
Platform, BIOS 6.00 11/12/2020
RIP: 0010:vmw_binding_add+0x4c/0x140 [vmwgfx]
Code: 7e 30 49 83 ff 0e 0f 87 ea 00 00 00 4b 8d 04 7f 89 d2 89 cb 48 c1 e0 03
4c 8b b0 40 3d 93 c0 48 8b 80 48 3d 93 c0 49 0f af de <48> 03 1c d0 4c 01 e3 49
8>
RSP: 0018:b8014416b968 EFLAGS: 00010206
RAX: c0933ec0 RBX: RCX:
RDX: RSI: b8014416b9c0 RDI: b8014316f000
RBP: b8014416b998 R08: 0003 R09: 746f6c735f726564
R10: aaf2bda0 R11: 732e676e69646e69 R12: b8014316f000
R13: b8014416b9c0 R14: 0040 R15: 0006
FS: 7fba8c0af740() GS:8a1277c8() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0007c0933eb8 CR3: 000118244001 CR4: 003706e0
Call Trace:
vmw_view_bindings_add+0xf5/0x1b0 [vmwgfx]
? ___drm_dbg+0x8a/0xb0 [drm]
vmw_cmd_dx_set_shader_res+0x8f/0xc0 [vmwgfx]
vmw_execbuf_process+0x590/0x1360 [vmwgfx]
vmw_execbuf_ioctl+0x173/0x370 [vmwgfx]
? __drm_dev_dbg+0xb4/0xe0 [drm]
? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
drm_ioctl_kernel+0xbc/0x160 [drm]
drm_ioctl+0x2d2/0x580 [drm]
? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
? do_fault+0x1a6/0x420
vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
__x64_sys_ioctl+0x96/0xd0
do_syscall_64+0x5d/0x90
? handle_mm_fault+0xe4/0x2f0
? debug_smp_processor_id+0x1b/0x30
? fpregs_assert_state_consistent+0x2e/0x50
? exit_to_user_mode_prepare+0x40/0x180
? irqentry_exit_to_user_mode+0xd/0x20
? irqentry_exit+0x3f/0x50
? exc_page_fault+0x8b/0x180
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Signed-off-by: Zack Rusin
Cc: secur...@openanolis.org
Reported-by: Ziming Zhang
Testcase-found-by: Niels De Graef
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Cc: # v4.3+
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 29 ++---
2 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 3810a9984a7f..58bfdf203eca 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1513,4 +1513,16 @@ static inline bool vmw_has_fences(struct vmw_private
*vmw)
return (vmw_fifo_caps(vmw) & SVGA_FIFO_CAP_FENCE) != 0;
}
+static inline bool vmw_shadertype_is_valid(enum vmw_sm_type shader_model,
+ u32 shader_type)
+{
+ SVGA3dShaderType max_allowed = SVGA3D_SHADERTYPE_PREDX_MAX;
+
+ if (shader_model >= VMW_SM_5)
+ max_allowed = SVGA3D_SHADERTYPE_MAX;
+ else if (shader_model >= VMW_SM_4)
+ max_allowed = SVGA3D_SHADERTYPE_DX10_MAX;
+ return shader_type >= SVGA3D_SHADERTYPE_MIN && shader_type <
max_allowed;
+}
+
#endif
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 6b9aa2b4ef54..d30c0e3d3ab7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1992,7 +1992,7 @@ static int vmw_cmd_set_shader(struct vmw_private
*dev_priv,
cmd = container_of(header, typeof(*cmd), header);
- if (cmd->body.type >= SVGA3D_SHADERTYPE_PREDX_MAX) {
+ if (!vmw_shadertype_is_valid(VMW_SM_LEGACY, cmd->body.type)) {
VMW_DEBUG_USER("Illegal shader type %u.\n",
(unsigned int) cmd->body.type);
return -EINVAL;
@@ -2115,8 +2115,6 @@ vmw_cmd_dx_set_single_constant_buffer(struct vmw_private
*dev_priv,
SVGA3dCmdHeader *header)
{
VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdDXSetSingleConstantBuffer);
- SVGA3dShaderType max_shader_num = has_sm5_context(dev_priv) ?
- SVGA3D_NUM_SHADERTYPE : SVGA3D_NUM_SHADERTYPE_DX10;
struct vmw_resource *res = NULL;
struct vmw_ctx_validation_info *ctx_node = VMW_GET_CTX_NODE(sw_context);
@@ -2133,6 +2131,14 @@ vmw_cmd_dx_set_single_constant_buffer(struct vmw_private
*dev_priv,
if (unlikely(ret != 0))
return ret;
+ if (!vmw_shadertype_is_valid(dev_priv->sm_type, cmd->body.type) ||
+ cmd->body.slot >= SVGA3D_DX_MAX_CONSTBUFFERS) {
+ VMW_DEBUG_USER("Illegal const buffer shader %u slot %u.\n",
+ (unsigned int) cmd->body.type,
+
Re: [PATCH 3/5] drm/bridge: tc358762: Instruct DSI host to generate HSE packets
On Thu, Jun 15, 2023 at 10:19:00PM +0200, Marek Vasut wrote: > This bridge seems to need the HSE packet, otherwise the image is > shifted up and corrupted at the bottom. This makes the bridge > work with Samsung DSIM on i.MX8MM and i.MX8MP. > > Signed-off-by: Marek Vasut Reviewed-by: Sam Ravnborg (Not that I know the register or such, but the patch looks good). > --- > Cc: Andrzej Hajda > Cc: Daniel Vetter > Cc: David Airlie > Cc: Jernej Skrabec > Cc: Jonas Karlman > Cc: Laurent Pinchart > Cc: Neil Armstrong > Cc: Robert Foss > Cc: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/bridge/tc358762.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/tc358762.c > b/drivers/gpu/drm/bridge/tc358762.c > index 5e00c08b99540..77f2ec9de9e59 100644 > --- a/drivers/gpu/drm/bridge/tc358762.c > +++ b/drivers/gpu/drm/bridge/tc358762.c > @@ -241,7 +241,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi) > dsi->lanes = 1; > dsi->format = MIPI_DSI_FMT_RGB888; > dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE | > - MIPI_DSI_MODE_LPM; > + MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_VIDEO_HSE; > > ret = tc358762_parse_dt(ctx); > if (ret < 0) > -- > 2.39.2
Re: [PATCH 5/5] drm/bridge: tc358762: Handle HS/VS polarity
On Thu, Jun 15, 2023 at 10:19:02PM +0200, Marek Vasut wrote: > Add support for handling the HS/VS sync signals polarity in the bridge > driver, otherwise e.g. DSIM bridge feeds the TC358762 inverted polarity > sync signals and the image is shifted to the left, up, and wobbly. > > Signed-off-by: Marek Vasut Reviewed-by: Sam Ravnborg
Re: [PATCH 4/5] drm/bridge: tc358762: Guess the meaning of LCDCTRL bits
On Thu, Jun 15, 2023 at 10:19:01PM +0200, Marek Vasut wrote: > The register content and behavior is very similar to TC358764 VP_CTRL. > All the bits except for unknown bit 6 also seem to match, even though > the datasheet is just not available. Add a comment and reuse the bit > definitions. > > Signed-off-by: Marek Vasut Reviewed-by: Sam Ravnborg
Re: [PATCH 2/5] drm/bridge: tc358762: Switch to atomic ops
On Thu, Jun 15, 2023 at 10:18:59PM +0200, Marek Vasut wrote:
> Switch the bridge driver over to atomic ops. No functional change.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Sam Ravnborg
(I hope one day all bridge drivers are converted to atomic ops...)
> ---
> Cc: Andrzej Hajda
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/bridge/tc358762.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358762.c
> b/drivers/gpu/drm/bridge/tc358762.c
> index df9703eacab1f..5e00c08b99540 100644
> --- a/drivers/gpu/drm/bridge/tc358762.c
> +++ b/drivers/gpu/drm/bridge/tc358762.c
> @@ -126,7 +126,7 @@ static int tc358762_init(struct tc358762 *ctx)
> return tc358762_clear_error(ctx);
> }
>
> -static void tc358762_post_disable(struct drm_bridge *bridge)
> +static void tc358762_post_disable(struct drm_bridge *bridge, struct
> drm_bridge_state *state)
> {
> struct tc358762 *ctx = bridge_to_tc358762(bridge);
> int ret;
> @@ -148,7 +148,7 @@ static void tc358762_post_disable(struct drm_bridge
> *bridge)
> dev_err(ctx->dev, "error disabling regulators (%d)\n", ret);
> }
>
> -static void tc358762_pre_enable(struct drm_bridge *bridge)
> +static void tc358762_pre_enable(struct drm_bridge *bridge, struct
> drm_bridge_state *state)
> {
> struct tc358762 *ctx = bridge_to_tc358762(bridge);
> int ret;
> @@ -165,7 +165,7 @@ static void tc358762_pre_enable(struct drm_bridge *bridge)
> ctx->pre_enabled = true;
> }
>
> -static void tc358762_enable(struct drm_bridge *bridge)
> +static void tc358762_enable(struct drm_bridge *bridge, struct
> drm_bridge_state *state)
> {
> struct tc358762 *ctx = bridge_to_tc358762(bridge);
> int ret;
> @@ -185,9 +185,12 @@ static int tc358762_attach(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs tc358762_bridge_funcs = {
> - .post_disable = tc358762_post_disable,
> - .pre_enable = tc358762_pre_enable,
> - .enable = tc358762_enable,
> + .atomic_post_disable = tc358762_post_disable,
> + .atomic_pre_enable = tc358762_pre_enable,
> + .atomic_enable = tc358762_enable,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> .attach = tc358762_attach,
> };
>
> --
> 2.39.2
Re: [PATCH 1/5] drm/bridge: tc358762: Split register programming from pre-enable to enable
Hi Marek,
On Thu, Jun 15, 2023 at 10:18:58PM +0200, Marek Vasut wrote:
> Move the register programming part, which actually enables the bridge and
> makes it push data out of its DPI side, into the enable callback. The DSI
> host like DSIM may not be able to transmit commands in pre_enable, moving
> the register programming into enable assures it can transmit commands.
>
> Signed-off-by: Marek Vasut
I was about to complain that the use of .enable is deprecated, but the
following patch fixes this.
So:
Reviewed-by: Sam Ravnborg
> ---
> Cc: Andrzej Hajda
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/bridge/tc358762.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358762.c
> b/drivers/gpu/drm/bridge/tc358762.c
> index 5641395fd310e..df9703eacab1f 100644
> --- a/drivers/gpu/drm/bridge/tc358762.c
> +++ b/drivers/gpu/drm/bridge/tc358762.c
> @@ -162,11 +162,17 @@ static void tc358762_pre_enable(struct drm_bridge
> *bridge)
> usleep_range(5000, 1);
> }
>
> + ctx->pre_enabled = true;
> +}
> +
> +static void tc358762_enable(struct drm_bridge *bridge)
> +{
> + struct tc358762 *ctx = bridge_to_tc358762(bridge);
> + int ret;
> +
> ret = tc358762_init(ctx);
> if (ret < 0)
> dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
> -
> - ctx->pre_enabled = true;
> }
>
> static int tc358762_attach(struct drm_bridge *bridge,
> @@ -181,6 +187,7 @@ static int tc358762_attach(struct drm_bridge *bridge,
> static const struct drm_bridge_funcs tc358762_bridge_funcs = {
> .post_disable = tc358762_post_disable,
> .pre_enable = tc358762_pre_enable,
> + .enable = tc358762_enable,
> .attach = tc358762_attach,
> };
>
> --
> 2.39.2
Re: [PATCH] drm/bridge: tc358764: Use BIT() macro for actual bits
On Thu, Jun 15, 2023 at 10:16:35PM +0200, Marek Vasut wrote: > None of these four bits are bitfields, use BIT() macro and treat > them as bits. No functional change. > > Signed-off-by: Marek Vasut I always find FLD_VAL() hard to follow. Reviewed-by: Sam Ravnborg > --- > Cc: Andrzej Hajda > Cc: Daniel Vetter > Cc: David Airlie > Cc: Jernej Skrabec > Cc: Jonas Karlman > Cc: Laurent Pinchart > Cc: Neil Armstrong > Cc: Robert Foss > Cc: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/bridge/tc358764.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/tc358764.c > b/drivers/gpu/drm/bridge/tc358764.c > index f85654f1b1045..6a4cd313f5281 100644 > --- a/drivers/gpu/drm/bridge/tc358764.c > +++ b/drivers/gpu/drm/bridge/tc358764.c > @@ -42,10 +42,10 @@ > > /* Video path registers */ > #define VP_CTRL 0x0450 /* Video Path Control */ > -#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in > RGB666 */ > -#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */ > -#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */ > -#define VP_CTRL_RGB888(v)FLD_VAL(v, 8, 8) /* RGB888 mode */ > +#define VP_CTRL_MSF BIT(0) /* Magic square in RGB666 */ > +#define VP_CTRL_VTGENBIT(4) /* Use chip clock for timing */ > +#define VP_CTRL_EVTMODE BIT(5) /* Event mode */ > +#define VP_CTRL_RGB888 BIT(8) /* RGB888 mode */ > #define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */ > #define VP_CTRL_HSPOLBIT(17) /* Polarity of HSYNC signal */ > #define VP_CTRL_DEPOLBIT(18) /* Polarity of DE signal */ > @@ -233,8 +233,8 @@ static int tc358764_init(struct tc358764 *ctx) > tc358764_write(ctx, DSI_STARTDSI, DSI_RX_START); > > /* configure video path */ > - tc358764_write(ctx, VP_CTRL, VP_CTRL_VSDELAY(15) | VP_CTRL_RGB888(1) | > -VP_CTRL_EVTMODE(1) | VP_CTRL_HSPOL | VP_CTRL_VSPOL); > + tc358764_write(ctx, VP_CTRL, VP_CTRL_VSDELAY(15) | VP_CTRL_RGB888 | > +VP_CTRL_EVTMODE | VP_CTRL_HSPOL | VP_CTRL_VSPOL); > > /* reset PHY */ > tc358764_write(ctx, LV_PHY0, LV_PHY0_RST(1) | > -- > 2.39.2
Re: [PATCH v5] drm/sched: Make sure we wait for all dependencies in kill_jobs_cb()
Am 16.06.23 um 19:12 schrieb Boris Brezillon:
drm_sched_entity_kill_jobs_cb() logic is omitting the last fence popped
from the dependency array that was waited upon before
drm_sched_entity_kill() was called (drm_sched_entity::dependency field),
so we're basically waiting for all dependencies except one.
In theory, this wait shouldn't be needed because resources should have
their users registered to the dma_resv object, thus guaranteeing that
future jobs wanting to access these resources wait on all the previous
users (depending on the access type, of course). But we want to keep
these explicit waits in the kill entity path just in case.
Let's make sure we keep all dependencies in the array in
drm_sched_job_dependency(), so we can iterate over the array and wait
in drm_sched_entity_kill_jobs_cb().
We make sure we wait on drm_sched_fence::finished if we were
originally asked to wait on drm_sched_fence::scheduled. In that case,
we assume the intent was to delegate the wait to the firmware/GPU or
rely on the pipelining done at the entity/scheduler level, but when
killing jobs, we really want to wait for completion not just scheduling.
v5:
- Flag deps on which we should only wait for the scheduled event
at insertion time.
v4:
- Fix commit message
- Fix a use-after-free bug
v3:
- Always wait for drm_sched_fence::finished fences in
drm_sched_entity_kill_jobs_cb() when we see a sched_fence
v2:
- Don't evict deps in drm_sched_job_dependency()
Signed-off-by: Boris Brezillon
Suggested-by: "Christian König"
Cc: Frank Binns
Cc: Sarah Walker
Cc: Donald Robson
Cc: Luben Tuikov
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
---
Hello Christian,
It turns out the approach you suggested just moves the complexity to
the insertion path, and it actually makes the 'should we replace or
drop fence' test a bit more tedious. We might end up with less
duplicates if some drivers start mixing scheduled/finished fences, but
I doubt this will be the case in practice, and I'm not sure it's worth
the extra complexity.
Yeah, and thinking more about it it actually doesn't solve the problem
that the finished fence might not be around any more.
I think your v4 actually looked better than this. Feel free to add my rb
and when Luben has no objections I'm going to push this to drm-misc-next
on Monday.
Thanks,
Christian.
Let me know what you think.
Regards,
Boris
---
drivers/gpu/drm/scheduler/sched_entity.c | 29 --
drivers/gpu/drm/scheduler/sched_main.c | 50 +++-
include/drm/gpu_scheduler.h | 7
3 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 68e807ae136a..ffdee2544f42 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -176,13 +176,14 @@ static void drm_sched_entity_kill_jobs_cb(struct
dma_fence *f,
{
struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
finish_cb);
+ unsigned long index;
int r;
dma_fence_put(f);
/* Wait for all dependencies to avoid data corruptions */
- while (!xa_empty(>dependencies)) {
- f = xa_erase(>dependencies, job->last_dependency++);
+ xa_for_each(>dependencies, index, f) {
+ xa_erase(>dependencies, index);
r = dma_fence_add_callback(f, >finish_cb,
drm_sched_entity_kill_jobs_cb);
if (!r)
@@ -415,8 +416,28 @@ static struct dma_fence *
drm_sched_job_dependency(struct drm_sched_job *job,
struct drm_sched_entity *entity)
{
- if (!xa_empty(>dependencies))
- return xa_erase(>dependencies, job->last_dependency++);
+ struct dma_fence *f;
+
+ /* We keep the fence around, so we can iterate over all dependencies
+* in drm_sched_entity_kill_jobs_cb() to ensure all deps are signaled
+* before killing the job.
+*/
+ f = xa_load(>dependencies, job->last_dependency);
+ if (f) {
+ /* If the entry is flagged as 'wait-for-scheduled', we are
+* dealing with a drm_sched_fence and we want to wait for
+* the scheduled event only.
+*/
+ if (xa_get_mark(>dependencies, job->last_dependency,
+ DRM_SCHED_DEP_WAIT_FOR_SCHEDULED)) {
+ struct drm_sched_fence *s_fence = to_drm_sched_fence(f);
+
+ f = _fence->scheduled;
+ }
+
+ job->last_dependency++;
+ return dma_fence_get(f);
+ }
if (job->sched->ops->prepare_job)
return job->sched->ops->prepare_job(job, entity);
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
Re: [Freedreno] [PATCH v8 10/18] drm/msm/a6xx: Introduce GMU wrapper support
On Thu, Jun 15, 2023 at 11:43:04PM +0200, Konrad Dybcio wrote:
>
> On 10.06.2023 00:06, Akhil P Oommen wrote:
> > On Mon, May 29, 2023 at 03:52:29PM +0200, Konrad Dybcio wrote:
> >>
> >> Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
> >> but don't implement the associated GMUs. This is due to the fact that
> >> the GMU directly pokes at RPMh. Sadly, this means we have to take care
> >> of enabling & scaling power rails, clocks and bandwidth ourselves.
> >>
> >> Reuse existing Adreno-common code and modify the deeply-GMU-infused
> >> A6XX code to facilitate these GPUs. This involves if-ing out lots
> >> of GMU callbacks and introducing a new type of GMU - GMU wrapper (it's
> >> the actual name that Qualcomm uses in their downstream kernels).
> >>
> >> This is essentially a register region which is convenient to model
> >> as a device. We'll use it for managing the GDSCs. The register
> >> layout matches the actual GMU_CX/GX regions on the "real GMU" devices
> >> and lets us reuse quite a bit of gmu_read/write/rmw calls.
> >>
> >> Signed-off-by: Konrad Dybcio
> >> ---
> >> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 72 +-
> >> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 211
> >>
> >> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
> >> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 14 +-
> >> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 +-
> >> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 +
> >> 6 files changed, 277 insertions(+), 35 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> >> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> >> index 5ba8cba69383..385ca3a12462 100644
> >> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> >> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> >> @@ -1437,6 +1437,7 @@ static int a6xx_gmu_get_irq(struct a6xx_gmu *gmu,
> >> struct platform_device *pdev,
> >>
> >> void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> >> {
> >> + struct adreno_gpu *adreno_gpu = _gpu->base;
> >>struct a6xx_gmu *gmu = _gpu->gmu;
> >>struct platform_device *pdev = to_platform_device(gmu->dev);
> >>
> >> @@ -1462,10 +1463,12 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> >>gmu->mmio = NULL;
> >>gmu->rscc = NULL;
> >>
> >> - a6xx_gmu_memory_free(gmu);
> >> + if (!adreno_has_gmu_wrapper(adreno_gpu)) {
> >> + a6xx_gmu_memory_free(gmu);
> >>
> >> - free_irq(gmu->gmu_irq, gmu);
> >> - free_irq(gmu->hfi_irq, gmu);
> >> + free_irq(gmu->gmu_irq, gmu);
> >> + free_irq(gmu->hfi_irq, gmu);
> >> + }
> >>
> >>/* Drop reference taken in of_find_device_by_node */
> >>put_device(gmu->dev);
> >> @@ -1484,6 +1487,69 @@ static int cxpd_notifier_cb(struct notifier_block
> >> *nb,
> >>return 0;
> >> }
> >>
> >> +int a6xx_gmu_wrapper_init(struct a6xx_gpu *a6xx_gpu, struct device_node
> >> *node)
> >> +{
> >> + struct platform_device *pdev = of_find_device_by_node(node);
> >> + struct a6xx_gmu *gmu = _gpu->gmu;
> >> + int ret;
> >> +
> >> + if (!pdev)
> >> + return -ENODEV;
> >> +
> >> + gmu->dev = >dev;
> >> +
> >> + of_dma_configure(gmu->dev, node, true);
> >> +
> >> + pm_runtime_enable(gmu->dev);
> >> +
> >> + /* Mark legacy for manual SPTPRAC control */
> >> + gmu->legacy = true;
> >> +
> >> + /* Map the GMU registers */
> >> + gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
> >> + if (IS_ERR(gmu->mmio)) {
> >> + ret = PTR_ERR(gmu->mmio);
> >> + goto err_mmio;
> >> + }
> >> +
> >> + gmu->cxpd = dev_pm_domain_attach_by_name(gmu->dev, "cx");
> >> + if (IS_ERR(gmu->cxpd)) {
> >> + ret = PTR_ERR(gmu->cxpd);
> >> + goto err_mmio;
> >> + }
> >> +
> >> + if (!device_link_add(gmu->dev, gmu->cxpd, DL_FLAG_PM_RUNTIME)) {
> >> + ret = -ENODEV;
> >> + goto detach_cxpd;
> >> + }
> >> +
> >> + init_completion(>pd_gate);
> >> + complete_all(>pd_gate);
> >> + gmu->pd_nb.notifier_call = cxpd_notifier_cb;
> >> +
> >> + /* Get a link to the GX power domain to reset the GPU */
> >> + gmu->gxpd = dev_pm_domain_attach_by_name(gmu->dev, "gx");
> >> + if (IS_ERR(gmu->gxpd)) {
> >> + ret = PTR_ERR(gmu->gxpd);
> >> + goto err_mmio;
> >> + }
> >> +
> >> + gmu->initialized = true;
> >> +
> >> + return 0;
> >> +
> >> +detach_cxpd:
> >> + dev_pm_domain_detach(gmu->cxpd, false);
> >> +
> >> +err_mmio:
> >> + iounmap(gmu->mmio);
> >> +
> >> + /* Drop reference taken in of_find_device_by_node */
> >> + put_device(gmu->dev);
> >> +
> >> + return ret;
> >> +}
> >> +
> >> int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
> >> {
> >>struct adreno_gpu *adreno_gpu = _gpu->base;
> >> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >> index 58bf405b85d8..0a44762dbb6d 100644
> >> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >> @@ -21,7 +21,7
Re: [PATCH] drm/msm/dsi: Enable BURST_MODE for command mode for DSI 6G v1.3+
On 6/14/2023 2:43 AM, Marijn Suijten wrote: On 2023-06-12 16:37:36, Jessica Zhang wrote: During a frame transfer in command mode, there could be frequent LP11 <-> HS transitions when multiple DCS commands are sent mid-frame or if the DSI controller is running on slow clock and is throttled. To minimize frame latency due to these transitions, it is recommended to send the frame in a single burst. This feature is supported for DSI 6G 1.3 and above, thus enable burst mode if supported. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/dsi/dsi_host.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 744f2398a6d6..8254b06dca85 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -994,6 +994,11 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi) dsi_write(msm_host, REG_DSI_CMD_MDP_STREAM0_TOTAL, DSI_CMD_MDP_STREAM0_TOTAL_H_TOTAL(hdisplay) | DSI_CMD_MDP_STREAM0_TOTAL_V_TOTAL(mode->vdisplay)); + + if (msm_host->cfg_hnd->major == MSM_DSI_VER_MAJOR_6G && + msm_host->cfg_hnd->minor >= MSM_DSI_6G_VER_MINOR_V1_3) + dsi_write(msm_host, REG_DSI_CMD_MODE_MDP_CTRL2, + DSI_CMD_MODE_MDP_CTRL2_BURST_MODE); This is not part of the timing setup, and a similar BURST_MODE flag is enabled for video-mode in dsi_ctrl_config() - should it be moved there? Hi Marijn, Sure, I can move the change to dsi_ctrl_enable() instead. (There is a dsi_sw_reset() in between the calls to dsi_timing_setup() and dsi_ctrl_cfg()) Note that that function sets up the CMD_CFG0 and CMD_CFG1 register, with the former having a very similar layout to MDP_CTRL2... is there documentation outlining the difference? I see what you mean, but unfortunately I'm not able to give you any documentation about the differences between them. FWIW, I think the macros in dsi.xml.h should give you a sense of what's within the registers and the slight differences between them. Thanks, Jessica Zhang - Marijn } } --- base-commit: dd969f852ba4c66938c71889e826aa8e5300d2f2 change-id: 20230608-b4-add-burst-mode-a5bb144069fa Best regards, -- Jessica Zhang
Re: [PATCH v5] drm/sched: Make sure we wait for all dependencies in kill_jobs_cb()
On Fri, 16 Jun 2023 19:12:48 +0200
Boris Brezillon wrote:
> drm_sched_entity_kill_jobs_cb() logic is omitting the last fence popped
> from the dependency array that was waited upon before
> drm_sched_entity_kill() was called (drm_sched_entity::dependency field),
> so we're basically waiting for all dependencies except one.
>
> In theory, this wait shouldn't be needed because resources should have
> their users registered to the dma_resv object, thus guaranteeing that
> future jobs wanting to access these resources wait on all the previous
> users (depending on the access type, of course). But we want to keep
> these explicit waits in the kill entity path just in case.
>
> Let's make sure we keep all dependencies in the array in
> drm_sched_job_dependency(), so we can iterate over the array and wait
> in drm_sched_entity_kill_jobs_cb().
>
> We make sure we wait on drm_sched_fence::finished if we were
> originally asked to wait on drm_sched_fence::scheduled. In that case,
> we assume the intent was to delegate the wait to the firmware/GPU or
> rely on the pipelining done at the entity/scheduler level, but when
> killing jobs, we really want to wait for completion not just scheduling.
>
> v5:
> - Flag deps on which we should only wait for the scheduled event
> at insertion time.
>
> v4:
> - Fix commit message
> - Fix a use-after-free bug
>
> v3:
> - Always wait for drm_sched_fence::finished fences in
> drm_sched_entity_kill_jobs_cb() when we see a sched_fence
>
> v2:
> - Don't evict deps in drm_sched_job_dependency()
>
> Signed-off-by: Boris Brezillon
> Suggested-by: "Christian König"
> Cc: Frank Binns
> Cc: Sarah Walker
> Cc: Donald Robson
> Cc: Luben Tuikov
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sumit Semwal
> Cc: "Christian König"
> ---
> Hello Christian,
>
> It turns out the approach you suggested just moves the complexity to
> the insertion path, and it actually makes the 'should we replace or
> drop fence' test a bit more tedious. We might end up with less
> duplicates if some drivers start mixing scheduled/finished fences, but
> I doubt this will be the case in practice, and I'm not sure it's worth
> the extra complexity.
>
> Let me know what you think.
>
> Regards,
>
> Boris
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 29 --
> drivers/gpu/drm/scheduler/sched_main.c | 50 +++-
> include/drm/gpu_scheduler.h | 7
> 3 files changed, 80 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index 68e807ae136a..ffdee2544f42 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -176,13 +176,14 @@ static void drm_sched_entity_kill_jobs_cb(struct
> dma_fence *f,
> {
> struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
>finish_cb);
> + unsigned long index;
> int r;
>
> dma_fence_put(f);
>
> /* Wait for all dependencies to avoid data corruptions */
> - while (!xa_empty(>dependencies)) {
> - f = xa_erase(>dependencies, job->last_dependency++);
> + xa_for_each(>dependencies, index, f) {
> + xa_erase(>dependencies, index);
> r = dma_fence_add_callback(f, >finish_cb,
> drm_sched_entity_kill_jobs_cb);
> if (!r)
> @@ -415,8 +416,28 @@ static struct dma_fence *
> drm_sched_job_dependency(struct drm_sched_job *job,
>struct drm_sched_entity *entity)
> {
> - if (!xa_empty(>dependencies))
> - return xa_erase(>dependencies, job->last_dependency++);
> + struct dma_fence *f;
> +
> + /* We keep the fence around, so we can iterate over all dependencies
> + * in drm_sched_entity_kill_jobs_cb() to ensure all deps are signaled
> + * before killing the job.
> + */
> + f = xa_load(>dependencies, job->last_dependency);
> + if (f) {
> + /* If the entry is flagged as 'wait-for-scheduled', we are
> + * dealing with a drm_sched_fence and we want to wait for
> + * the scheduled event only.
> + */
> + if (xa_get_mark(>dependencies, job->last_dependency,
> + DRM_SCHED_DEP_WAIT_FOR_SCHEDULED)) {
> + struct drm_sched_fence *s_fence = to_drm_sched_fence(f);
> +
> + f = _fence->scheduled;
> + }
> +
> + job->last_dependency++;
> + return dma_fence_get(f);
> + }
>
> if (job->sched->ops->prepare_job)
> return job->sched->ops->prepare_job(job, entity);
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 394010a60821..8ac207cbd713 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++
Re: [PATCH 0/3] drm: Allow PRIME 'self-import' for all drivers
Series looks good to me: Acked-by: Alex Deucher On Thu, Jun 15, 2023 at 5:42 AM Thomas Zimmermann wrote: > > Set drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() > for all DRM drivers. Even drivers that do not support PRIME import > or export of dma-bufs can now import their own buffer objects. This > is required by some userspace, such as wlroots-based compositors, to > share buffers among processes. > > The only driver that does not use the drm_gem_prime_*() helpers is > vmwgfx. Once it has been converted, the callbacks in struct drm_driver > can be removed. > > Simon Ser implemented the feature for drivers based on GEM VRAM helpers > in [1]. This patchset generalizes the code for all drivers that do not > otherwise support PRIME. Tested by running sway with gma500 hardware. > > [1] > https://lore.kernel.org/dri-devel/20230302143502.500661-1-cont...@emersion.fr/ > > Thomas Zimmermann (3): > drm: Enable PRIME import/export for all drivers > drm: Clear fd/handle callbacks in struct drm_driver > drm/prime: Unexport helpers for fd/handle conversion > > Documentation/gpu/todo.rst| 14 + > drivers/accel/ivpu/ivpu_drv.c | 2 - > drivers/accel/qaic/qaic_drv.c | 1 - > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 - > drivers/gpu/drm/armada/armada_drv.c | 2 - > drivers/gpu/drm/drm_ioctl.c | 4 +- > drivers/gpu/drm/drm_prime.c | 62 ++- > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 - > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 - > drivers/gpu/drm/i915/i915_driver.c| 2 - > drivers/gpu/drm/lima/lima_drv.c | 2 - > drivers/gpu/drm/mediatek/mtk_drm_drv.c| 2 - > drivers/gpu/drm/msm/msm_drv.c | 2 - > drivers/gpu/drm/nouveau/nouveau_drm.c | 2 - > drivers/gpu/drm/omapdrm/omap_drv.c| 2 - > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 - > drivers/gpu/drm/pl111/pl111_drv.c | 2 - > drivers/gpu/drm/qxl/qxl_drv.c | 2 - > drivers/gpu/drm/radeon/radeon_drv.c | 2 - > drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 2 - > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 - > drivers/gpu/drm/tegra/drm.c | 2 - > drivers/gpu/drm/v3d/v3d_drv.c | 2 - > drivers/gpu/drm/virtio/virtgpu_drv.c | 2 - > drivers/gpu/drm/xen/xen_drm_front.c | 2 - > include/drm/drm_drv.h | 6 ++ > include/drm/drm_gem_dma_helper.h | 12 ++-- > include/drm/drm_gem_shmem_helper.h| 6 +- > include/drm/drm_gem_vram_helper.h | 4 +- > include/drm/drm_prime.h | 7 --- > 30 files changed, 62 insertions(+), 96 deletions(-) > > -- > 2.41.0 >
[PATCH v5] drm/sched: Make sure we wait for all dependencies in kill_jobs_cb()
drm_sched_entity_kill_jobs_cb() logic is omitting the last fence popped
from the dependency array that was waited upon before
drm_sched_entity_kill() was called (drm_sched_entity::dependency field),
so we're basically waiting for all dependencies except one.
In theory, this wait shouldn't be needed because resources should have
their users registered to the dma_resv object, thus guaranteeing that
future jobs wanting to access these resources wait on all the previous
users (depending on the access type, of course). But we want to keep
these explicit waits in the kill entity path just in case.
Let's make sure we keep all dependencies in the array in
drm_sched_job_dependency(), so we can iterate over the array and wait
in drm_sched_entity_kill_jobs_cb().
We make sure we wait on drm_sched_fence::finished if we were
originally asked to wait on drm_sched_fence::scheduled. In that case,
we assume the intent was to delegate the wait to the firmware/GPU or
rely on the pipelining done at the entity/scheduler level, but when
killing jobs, we really want to wait for completion not just scheduling.
v5:
- Flag deps on which we should only wait for the scheduled event
at insertion time.
v4:
- Fix commit message
- Fix a use-after-free bug
v3:
- Always wait for drm_sched_fence::finished fences in
drm_sched_entity_kill_jobs_cb() when we see a sched_fence
v2:
- Don't evict deps in drm_sched_job_dependency()
Signed-off-by: Boris Brezillon
Suggested-by: "Christian König"
Cc: Frank Binns
Cc: Sarah Walker
Cc: Donald Robson
Cc: Luben Tuikov
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
---
Hello Christian,
It turns out the approach you suggested just moves the complexity to
the insertion path, and it actually makes the 'should we replace or
drop fence' test a bit more tedious. We might end up with less
duplicates if some drivers start mixing scheduled/finished fences, but
I doubt this will be the case in practice, and I'm not sure it's worth
the extra complexity.
Let me know what you think.
Regards,
Boris
---
drivers/gpu/drm/scheduler/sched_entity.c | 29 --
drivers/gpu/drm/scheduler/sched_main.c | 50 +++-
include/drm/gpu_scheduler.h | 7
3 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 68e807ae136a..ffdee2544f42 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -176,13 +176,14 @@ static void drm_sched_entity_kill_jobs_cb(struct
dma_fence *f,
{
struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
finish_cb);
+ unsigned long index;
int r;
dma_fence_put(f);
/* Wait for all dependencies to avoid data corruptions */
- while (!xa_empty(>dependencies)) {
- f = xa_erase(>dependencies, job->last_dependency++);
+ xa_for_each(>dependencies, index, f) {
+ xa_erase(>dependencies, index);
r = dma_fence_add_callback(f, >finish_cb,
drm_sched_entity_kill_jobs_cb);
if (!r)
@@ -415,8 +416,28 @@ static struct dma_fence *
drm_sched_job_dependency(struct drm_sched_job *job,
struct drm_sched_entity *entity)
{
- if (!xa_empty(>dependencies))
- return xa_erase(>dependencies, job->last_dependency++);
+ struct dma_fence *f;
+
+ /* We keep the fence around, so we can iterate over all dependencies
+* in drm_sched_entity_kill_jobs_cb() to ensure all deps are signaled
+* before killing the job.
+*/
+ f = xa_load(>dependencies, job->last_dependency);
+ if (f) {
+ /* If the entry is flagged as 'wait-for-scheduled', we are
+* dealing with a drm_sched_fence and we want to wait for
+* the scheduled event only.
+*/
+ if (xa_get_mark(>dependencies, job->last_dependency,
+ DRM_SCHED_DEP_WAIT_FOR_SCHEDULED)) {
+ struct drm_sched_fence *s_fence = to_drm_sched_fence(f);
+
+ f = _fence->scheduled;
+ }
+
+ job->last_dependency++;
+ return dma_fence_get(f);
+ }
if (job->sched->ops->prepare_job)
return job->sched->ops->prepare_job(job, entity);
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 394010a60821..8ac207cbd713 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -691,6 +691,8 @@ EXPORT_SYMBOL(drm_sched_job_arm);
int drm_sched_job_add_dependency(struct drm_sched_job *job,
struct dma_fence *fence)
{
+ bool fence_wait_for_scheduled =
Re: [v2] drm/etnaviv: slow down FE idle polling
Hi,
On 2023/6/16 19:02, Lucas Stach wrote:
Currently the FE is spinning way too fast when polling for new work in
the FE idleloop. As each poll fetches 16 bytes from memory, a GPU running
at 1GHz with the current setting of 200 wait cycle between fetches causes
80 MB/s of memory traffic just to check for new work when the GPU is
otherwise idle, which is more FE traffic than in some GPU loaded cases.
Significantly increase the number of wait cycles to slow down the poll
interval to ~30µs, limiting the FE idle memory traffic to 512 KB/s, while
providing a max latency which should not hurt most use-cases. The FE WAIT
command seems to have some unknown discrete steps in the wait cycles so
we may over/undershoot the target a bit, but that should be harmless.
If the GPU core base frequency is unknown keep the 200 wait cycles as
a sane default.
Thanks for the patch, this version still works on our platform.
I add a print, the value is 200 as before.
Signed-off-by: Lucas Stach
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
---
v2: Don't speed up when the GPU core frequency is unknown.
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 11 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 8
drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 1 +
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index cf741c5c82d2..384df1659be6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -53,11 +53,12 @@ static inline void CMD_END(struct etnaviv_cmdbuf *buffer)
OUT(buffer, VIV_FE_END_HEADER_OP_END);
}
-static inline void CMD_WAIT(struct etnaviv_cmdbuf *buffer)
+static inline void CMD_WAIT(struct etnaviv_cmdbuf *buffer,
+ unsigned int waitcycles)
{
buffer->user_size = ALIGN(buffer->user_size, 8);
- OUT(buffer, VIV_FE_WAIT_HEADER_OP_WAIT | 200);
+ OUT(buffer, VIV_FE_WAIT_HEADER_OP_WAIT | waitcycles);
}
static inline void CMD_LINK(struct etnaviv_cmdbuf *buffer,
@@ -168,7 +169,7 @@ u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
/* initialize buffer */
buffer->user_size = 0;
- CMD_WAIT(buffer);
+ CMD_WAIT(buffer, gpu->fe_waitcycles);
CMD_LINK(buffer, 2,
etnaviv_cmdbuf_get_va(buffer,
>mmu_context->cmdbuf_mapping)
+ buffer->user_size - 4);
@@ -320,7 +321,7 @@ void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu,
unsigned int event)
CMD_END(buffer);
/* Append waitlink */
- CMD_WAIT(buffer);
+ CMD_WAIT(buffer, gpu->fe_waitcycles);
CMD_LINK(buffer, 2,
etnaviv_cmdbuf_get_va(buffer,
>mmu_context->cmdbuf_mapping)
+ buffer->user_size - 4);
@@ -503,7 +504,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) |
VIVS_GL_EVENT_FROM_PE);
- CMD_WAIT(buffer);
+ CMD_WAIT(buffer, gpu->fe_waitcycles);
CMD_LINK(buffer, 2,
etnaviv_cmdbuf_get_va(buffer,
>mmu_context->cmdbuf_mapping)
+ buffer->user_size - 4);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index de8c9894967c..63b929b1e5d1 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -493,6 +493,14 @@ static void etnaviv_gpu_update_clock(struct etnaviv_gpu
*gpu)
clock |= VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);
etnaviv_gpu_load_clock(gpu, clock);
}
+
+ /*
+* Choose number of wait cycles to target a ~30us (1/32768) max latency
+* until new work is picked up by the FE when it polls in the idle loop.
+* If the GPU base frequency is unknown use 200 wait cycles.
+*/
+ gpu->fe_waitcycles = clamp(gpu->base_rate_core >> (15 -
gpu->freq_scale),
+ 200UL, 0xUL);
}
static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 98c6f9c320fc..e1e1de59c38d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -150,6 +150,7 @@ struct etnaviv_gpu {
struct clk *clk_shader;
unsigned int freq_scale;
+ unsigned int fe_waitcycles;
unsigned long base_rate_core;
unsigned long base_rate_shader;
};
--
Jingfeng
Re: [PATCH 0/3] drm: Allow PRIME 'self-import' for all drivers
On 6/15/2023 3:31 AM, Thomas Zimmermann wrote: Set drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() for all DRM drivers. Even drivers that do not support PRIME import or export of dma-bufs can now import their own buffer objects. This is required by some userspace, such as wlroots-based compositors, to share buffers among processes. The only driver that does not use the drm_gem_prime_*() helpers is vmwgfx. Once it has been converted, the callbacks in struct drm_driver can be removed. Simon Ser implemented the feature for drivers based on GEM VRAM helpers in [1]. This patchset generalizes the code for all drivers that do not otherwise support PRIME. Tested by running sway with gma500 hardware. [1] https://lore.kernel.org/dri-devel/20230302143502.500661-1-cont...@emersion.fr/ Thomas Zimmermann (3): drm: Enable PRIME import/export for all drivers drm: Clear fd/handle callbacks in struct drm_driver drm/prime: Unexport helpers for fd/handle conversion Documentation/gpu/todo.rst| 14 + drivers/accel/ivpu/ivpu_drv.c | 2 - drivers/accel/qaic/qaic_drv.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 - drivers/gpu/drm/armada/armada_drv.c | 2 - drivers/gpu/drm/drm_ioctl.c | 4 +- drivers/gpu/drm/drm_prime.c | 62 ++- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 - drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 - drivers/gpu/drm/i915/i915_driver.c| 2 - drivers/gpu/drm/lima/lima_drv.c | 2 - drivers/gpu/drm/mediatek/mtk_drm_drv.c| 2 - drivers/gpu/drm/msm/msm_drv.c | 2 - drivers/gpu/drm/nouveau/nouveau_drm.c | 2 - drivers/gpu/drm/omapdrm/omap_drv.c| 2 - drivers/gpu/drm/panfrost/panfrost_drv.c | 2 - drivers/gpu/drm/pl111/pl111_drv.c | 2 - drivers/gpu/drm/qxl/qxl_drv.c | 2 - drivers/gpu/drm/radeon/radeon_drv.c | 2 - drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 2 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 - drivers/gpu/drm/tegra/drm.c | 2 - drivers/gpu/drm/v3d/v3d_drv.c | 2 - drivers/gpu/drm/virtio/virtgpu_drv.c | 2 - drivers/gpu/drm/xen/xen_drm_front.c | 2 - include/drm/drm_drv.h | 6 ++ include/drm/drm_gem_dma_helper.h | 12 ++-- include/drm/drm_gem_shmem_helper.h| 6 +- include/drm/drm_gem_vram_helper.h | 4 +- include/drm/drm_prime.h | 7 --- 30 files changed, 62 insertions(+), 96 deletions(-) Surely the maintainers of the 22 drivers touched by this series should be in the to list or something? Speaking for myself, threads that directly address me trigger my "priority" filters. Series looks sane to me, but I'd like to see what you do for a v2 to address the existing comments. For the QAIC part - Acked-by: Jeffrey Hugo -Jeff
[PATCH 2/2] drm/panel: simple: Add support for Mitsubishi AA084XE01
From: Thomas Weber
Add support for the Mitsubishi AA084XE01 panel which is an 8.4 inch XGA
TFT-LCD module for industrial use.
Link: https://www.mouser.fr/datasheet/2/274/aa084xe01_e-364171.pdf
Signed-off-by: Thomas Weber
Signed-off-by: Miquel Raynal
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 8a3b685c2fcc..f79c9f9124a0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2670,6 +2670,30 @@ static const struct panel_desc mitsubishi_aa070mc01 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH,
};
+static const struct drm_display_mode mitsubishi_aa084xe01_mode = {
+ .clock = 8,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 24,
+ .hsync_end = 1024 + 24 + 63,
+ .htotal = 1024 + 24 + 63 + 1,
+ .vdisplay = 768,
+ .vsync_start = 768 + 3,
+ .vsync_end = 768 + 3 + 6,
+ .vtotal = 768 + 3 + 6 + 1,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc mitsubishi_aa084xe01 = {
+ .modes = _aa084xe01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 1024,
+ .height = 768,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB565_1X16,
+};
+
static const struct display_timing multi_inno_mi0700s4t_6_timing = {
.pixelclock = { 2900, 3300, 3800 },
.hactive = { 800, 800, 800 },
@@ -4158,6 +4182,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = _aa070mc01,
+ }, {
+ .compatible = "mitsubishi,aa084xe01",
+ .data = _aa084xe01,
}, {
.compatible = "multi-inno,mi0700s4t-6",
.data = _inno_mi0700s4t_6,
--
2.34.1
Re: [PATCH 2/2] drm/panel: boe-tv101wum-nl6: Drop surplus prepare tracking
Hi Linus. On Thu, Jun 15, 2023 at 10:21:38PM +0200, Linus Walleij wrote: > The DRM panel core already keeps track of if the panel is already > prepared so do not reimplement this. > > Signed-off-by: Linus Walleij Reviewed-by: Sam Ravnborg It would be good to rip it out for all panels so people do not copy less optimal code. Sam
Re: [PATCH 1/2] drm/panel: boe-tv101wum-nl6: Drop macros and open code sequences
Hi Linus, On Thu, Jun 15, 2023 at 10:21:37PM +0200, Linus Walleij wrote: > The boe-tv101wum-nl6 is reinventing the mechanism to send command > sequences that we usually nix during review, but I missed this one > so fixing it up myself. > > Also use the explicit function calls to mipi_dsi_dcs_exit_sleep_mode() > and mipi_dsi_dcs_set_display_on() instead of reimplementing them > with homegrown sequences. It looks like the same sequence of calls are used in all init functions, maybe move them out to the caller. > > Signed-off-by: Linus Walleij I have browsed the patch, but it was impossible for me to review in details due to the massive changes. But the final result looks good! With the static added as the robot noticed: Reviewed-by: Sam Ravnborg
Re: [PATCH 2/4] video: backlight: lp855x: get PWM for PWM mode during probe
Hello,
On Fri, Jun 16, 2023 at 05:29:08PM +0200, Artur Weber wrote:
> On 14/06/2023 10:39, Uwe Kleine-König wrote:
> > On Sat, Apr 29, 2023 at 12:45:32PM +0200, Artur Weber wrote:
> >> Also deprecate the pwm-period DT property, as it is now redundant
> >> (pwms property already contains period value).
> >>
> >> Signed-off-by: Artur Weber
> >> ---
> >> drivers/video/backlight/lp855x_bl.c | 48 -
> >> 1 file changed, 26 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/video/backlight/lp855x_bl.c
> >> b/drivers/video/backlight/lp855x_bl.c
> >> index 81012bf29baf..21eb4943ed56 100644
> >> --- a/drivers/video/backlight/lp855x_bl.c
> >> +++ b/drivers/video/backlight/lp855x_bl.c
> >> ...
> >> @@ -472,11 +456,31 @@ static int lp855x_probe(struct i2c_client *cl)
> >>lp->enable = devm_regulator_get_optional(dev, "enable");
> >>if (IS_ERR(lp->enable)) {
> >>ret = PTR_ERR(lp->enable);
> >> - if (ret == -ENODEV) {
> >> + if (ret == -ENODEV)
> >>lp->enable = NULL;
> >> - } else {
> >> + else
> >>return dev_err_probe(dev, ret, "getting enable
> >> regulator\n");
> >> - }
> >> + }
> >> +
> >> + lp->pwm = devm_pwm_get(lp->dev, lp->chipname);
> >> + if (IS_ERR(lp->pwm)) {
> >> + ret = PTR_ERR(lp->pwm);
> >> + if (ret == -ENODEV || ret == -EINVAL)
> >
> > Why would you ignore EINVAL?
>
> EINVAL is returned when the pwms property is not found in the DT node
> for the backlight. Not sure if there's a better way of separately
> detecting whether it's present (especially when taking into
> consideration non-DT platforms that might use the driver). Would be nice
> to have something like devm_regulator_get_optional but for PWMs...
Ah, that is because of_pwm_get() calls of_property_match_string(np,
"pwm-names", con_id) which returns -EINVAL if there is no pwm-names
property. This is different for clocks. I wonder if pwm should adapt
accordingly? Thierry?
> Still, someone who's setting up the driver could check the debug
> messages to see if the backlight was set up in PWM mode or register mode.
>
> > ...
> >> + pwm_init_state(lp->pwm, );
> >> + /* Legacy platform data compatibility */
> >> + if (lp->pdata->period_ns > 0)
> >> + pwmstate.period = lp->pdata->period_ns;
> >> + pwm_apply_state(lp->pwm, );
> >
> > This is a change in behaviour. Before lp855x_probe() didn't modify the
> > state the bootloader left the backlight in. Now you're disabling it (I
> > think). Is this intended?
>
> I didn't really consider the implication of this in this way, as on the
> device I was testing this on (Exynos4212-based tablet) the PWM state
> would get reset during PWM chip initialization in the kernel anyways,
Which chip driver is in use here? That's a patch opportunity.
> meaning that the state from the bootloader would be lost regardless of
> this change. Either way, there's no guarantee that this would be the
> same on other devices, though I'd assume that in most cases it's not
> noticeable anyways as brightness is usually set somewhere in userspace
> (or even earlier, in the driver, if the init-brt property is set).
> Nonetheless, that's an oversight on my part.
>
> As for the reasoning for this change in behavior - the previous behavior
> was to silently fail if, while setting the brightness, the PWM could not
This sounds wrong.
> be set up. This seemed rather confusing to me (I encountered this while
> I was initially working on the tablet, I added a "pwm" property instead
> of "pwms" and was wondering why the backlight didn't work...)
>
> Of course, that could be fixed by adding error detection in the
> brightness set function, but since I was already working on it, it made
> more sense to me for the PWM to be set up during the probing process,
> given that this way we could 1. warn about errors early, and 2. catch
> deferred probes and defer the backlight's probe if we're still waiting
> for the PWM. That's why it's done the way it is in this patch.
>
> If this is undesired behavior, let me know and I'll submit another patch
> to revert it.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[PATCH 1/2] dt-bindings: display: simple: Add Mitsubishi AA084XE01 panel
Add Mitsubishi AA084XE01 8.4" XGA TFT LCD panel compatible string. Signed-off-by: Miquel Raynal --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 18241f4051d2..cc841cf96fae 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -232,6 +232,8 @@ properties: - logictechno,lttd800480070-l6wh-rt # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel - mitsubishi,aa070mc01-ca1 +# Mitsubishi AA084XE01 8.4" XGA TFT LCD panel + - mitsubishi,aa084xe01 # Multi-Inno Technology Co.,Ltd MI0700S4T-6 7" 800x480 TFT Resistive Touch Module - multi-inno,mi0700s4t-6 # Multi-Inno Technology Co.,Ltd MI0800FT-9 8" 800x600 TFT Resistive Touch Module -- 2.34.1
[pull] amdgpu, amdkfd, radeon, drm, scheduler, UAPI drm-next-6.5
Hi Dave, Daniel, Last few odds and ends for 6.5. Mostly bug fixes. Was waiting on some GPU scheduler changes in drm-misc for a few of the GPU reset fixes in amdgpu. The following changes since commit 901bdf5ea1a836400ee69aa32b04e9c209271ec7: Merge tag 'amd-drm-next-6.5-2023-06-09' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2023-06-15 14:11:22 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.5-2023-06-16 for you to fetch changes up to 72f1de49ffb90b29748284f27f1d6b829ab1de95: drm/dp_mst: Clear MSG_RDY flag before sending new message (2023-06-15 17:55:41 -0400) amd-drm-next-6.5-2023-06-16: amdgpu: - Misc display fixes - W=1 fixes - Improve scheduler naming - DCN 3.1.4 fixes - kdoc fixes - Enable W=1 - VCN 4.0 fix - xgmi fixes - TOPDOWN fix for large BAR systems - eDP fix - PSR fixes - SubVP fixes - Freesync fix - DPIA fix - SMU 13.0.5 fixes - vblflash fix - RAS fixes - SDMA 4 fix - BO locking fix - BO backing store fix - NBIO 7.9 fixes - GC 9.4.3 fixes - GPU reset recovery fixes - HMM fix amdkfd: - Fix NULL check - Trap fixes - Queue count fix - Add event age tracking radeon: - fbdev client fix scheduler: - Avoid an infinite loop UAPI: - Add KFD event age tracking: Proposed ROCT-Thunk-Interface: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/efdbf6cfbc026bd68ac3c35d00dacf84370eb81e https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/1820ae0a2db85b6f584611dc0cde1a00e7c22915 Proposed ROCR-Runtime: https://github.com/RadeonOpenCompute/ROCR-Runtime/compare/master...zhums:ROCR-Runtime:new_event_wait_review https://github.com/RadeonOpenCompute/ROCR-Runtime/commit/e1f5bdb88eb882ac798aeca2c00ea3fbb2dba459 https://github.com/RadeonOpenCompute/ROCR-Runtime/commit/7d26afd14107b5c2a754c1a3f415d89f3aabb503 drm: - DP MST fix Alex Deucher (4): Revert "drm/amd/display: fix dpms_off issue when disabling bios mode" drm/amd/display: don't free stolen console memory during suspend drm/amdgpu/sdma4: set align mask to 255 drm/amdgpu: mark GC 9.4.3 experimental for now Alvin Lee (4): drm/amd/display: SubVP high refresh only if all displays >= 120hz drm/amd/display: Re-enable SubVP high refresh drm/amd/display: Block SubVP + DRR if the DRR is PSR capable drm/amd/display: Include CSC updates in new fast update path Aric Cyr (2): drm/amd/display: Promote DAL to 3.2.238 drm/amd/display: 3.2.239 Artem Grishin (1): drm/amd/display: Bug fix in dcn315_populate_dml_pipes_from_context Arunpravin Paneer Selvam (1): Revert "drm/amdgpu: remove TOPDOWN flags when allocating VRAM in large bar system" Austin Zheng (2): drm/amd/display: Add DP2 Metrics drm/amd/display: Limit Minimum FreeSync Refresh Rate Candice Li (3): drm/amd/pm: Align eccinfo table structure with smu v13_0_0 interface drm/amdgpu: Update total channel number for umc v8_10 drm/amdgpu: Add channel_dis_num to ras init flags Christian König (8): drm/amdgpu: make sure BOs are locked in amdgpu_vm_get_memory drm/amdgpu: make sure that BOs have a backing store drm/amdgpu: add amdgpu_error_* debugfs file drm/amdgpu: mark force completed fences with -ECANCELED drm/amdgpu: mark soft recovered fences with -ENODATA drm/amdgpu: abort submissions during prepare on error drm/amdgpu: reset VM when an error is detected drm/amdgpu: add VM generation token Daniel Miess (2): drm/amd/display: Enable dcn314 DPP RCO drm/amd/display: Re-enable DPP/HUBP Power Gating Dmytro Laktyushkin (1): drm/amd/display: fix pixel rate update sequence Fangzhi Zuo (1): drm/amd/display: Add Error Code for Dml Validation Failure Hamza Mahfooz (1): drm/amd/amdgpu: enable W=1 for amdgpu Hersen Wu (2): drm/amd/display: edp do not add non-edid timings drm/amd/display: add debugfs for allow_edp_hotplug_detection James Zhu (5): drm/amdkfd: add event age tracking drm/amdkfd: add event_age tracking when receiving interrupt drm/amdkfd: set activated flag true when event age unmatchs drm/amdkfd: update user space last_event_age drm/amdkfd: bump kfd ioctl minor version for event age availability Jonathan Kim (2): drm/amdkfd: fix null queue check on debug setting exceptions drm/amdkfd: decrement queue count on mes queue destroy Lee Jones (1): drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move SYNAPTICS_DEVICE_ID into CONFIG_DRM_AMD_DC_DCN ifdef Lijo Lazar (4): drm/amdgpu: Release SDMAv4.4.2 ecc irq properly drm/amdgpu: Change nbio v7.9 xcp status definition drm/amdgpu: Use PSP FW API for partition switch drm/amdgpu: Remove unused NBIO interface Likun Gao (1):
[PATCH v2 5/6] drm/panel: sitronix-st7789v: Add EDT ET028013DMA panel support
This panel from Emerging Display Technologies Corporation features an
ST7789V2 LCD controller panel inside which is almost identical to what
the Sitronix panel driver supports.
In practice, the module physical size is specific, and experiments show
that the display will malfunction if any of the following situation
occurs:
* Pixel clock is above 3MHz
* Pixel clock is not inverted
I could not properly identify the reasons behind these failures, scope
captures show valid input signals.
Signed-off-by: Miquel Raynal
---
.../gpu/drm/panel/panel-sitronix-st7789v.c| 25 +++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index d7c5b3ad1baa..8649966ceae8 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -187,6 +187,21 @@ static const struct drm_display_mode t28cp45tn89_mode = {
.flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC,
};
+static const struct drm_display_mode et028013dma_mode = {
+ .clock = 3000,
+ .hdisplay = 240,
+ .hsync_start = 240 + 38,
+ .hsync_end = 240 + 38 + 10,
+ .htotal = 240 + 38 + 10 + 10,
+ .vdisplay = 320,
+ .vsync_start = 320 + 8,
+ .vsync_end = 320 + 8 + 4,
+ .vtotal = 320 + 8 + 4 + 4,
+ .width_mm = 43,
+ .height_mm = 58,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
struct st7789_panel_info default_panel = {
.mode = _mode,
.invert_mode = true,
@@ -203,6 +218,14 @@ struct st7789_panel_info t28cp45tn89_panel = {
DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
};
+struct st7789_panel_info et028013dma_panel = {
+ .mode = _mode,
+ .invert_mode = true,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
+DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+};
+
static int st7789v_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -474,6 +497,7 @@ static void st7789v_remove(struct spi_device *spi)
static const struct spi_device_id st7789v_spi_id[] = {
{ "st7789v", (unsigned long) _panel },
{ "t28cp45tn89-v17", (unsigned long) _panel },
+ { "et028013dma", (unsigned long) _panel },
{ }
};
MODULE_DEVICE_TABLE(spi, st7789v_spi_id);
@@ -481,6 +505,7 @@ MODULE_DEVICE_TABLE(spi, st7789v_spi_id);
static const struct of_device_id st7789v_of_match[] = {
{ .compatible = "sitronix,st7789v", .data = _panel },
{ .compatible = "inanbo,t28cp45tn89-v17", .data = _panel },
+ { .compatible = "edt,et028013dma", .data = _panel },
{ }
};
MODULE_DEVICE_TABLE(of, st7789v_of_match);
--
2.34.1
[PATCH v2 3/6] drm/panel: sitronix-st7789v: Use 9 bits per spi word by default
The Sitronix controller expects 9-bit words, provide this as default at probe time rather than specifying this in each and every access. Signed-off-by: Miquel Raynal Reviewed-by: Sam Ravnborg --- drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c index 172c6c1fc090..605b9f6d0f14 100644 --- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c +++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c @@ -142,7 +142,6 @@ static int st7789v_spi_write(struct st7789v *ctx, enum st7789v_prefix prefix, u16 txbuf = ((prefix & 1) << 8) | data; xfer.tx_buf = - xfer.bits_per_word = 9; xfer.len = sizeof(txbuf); return spi_sync_transfer(ctx->spi, , 1); @@ -436,6 +435,11 @@ static int st7789v_probe(struct spi_device *spi) spi_set_drvdata(spi, ctx); ctx->spi = spi; + spi->bits_per_word = 9; + ret = spi_setup(spi); + if (ret < 0) + return dev_err_probe(>dev, ret, "Failed to setup spi\n"); + ctx->info = device_get_match_data(>dev); drm_panel_init(>panel, dev, _drm_funcs, -- 2.34.1
[PATCH v2 4/6] drm/panel: sitronix-st7789v: Clarify a definition
The Sitronix datasheet explains BIT(1) of the RGBCTRL register as the DOTCLK/PCLK edge used to sample the data lines: “0” The data is input on the positive edge of DOTCLK “1” The data is input on the negative edge of DOTCLK IOW, this bit implies a falling edge and not a high state. Correct the definition to ease the comparison with the datasheet. Signed-off-by: Miquel Raynal --- drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c index 605b9f6d0f14..d7c5b3ad1baa 100644 --- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c +++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c @@ -27,7 +27,7 @@ #define ST7789V_RGBCTRL_RCM(n) (((n) & 3) << 5) #define ST7789V_RGBCTRL_VSYNC_HIGH BIT(3) #define ST7789V_RGBCTRL_HSYNC_HIGH BIT(2) -#define ST7789V_RGBCTRL_PCLK_HIGH BIT(1) +#define ST7789V_RGBCTRL_PCLK_FALLING BIT(1) #define ST7789V_RGBCTRL_DE_LOW BIT(0) #define ST7789V_RGBCTRL_VBP(n) ((n) & 0x7f) #define ST7789V_RGBCTRL_HBP(n) ((n) & 0x1f) @@ -259,7 +259,7 @@ static int st7789v_prepare(struct drm_panel *panel) if (ctx->info->mode->flags & DRM_MODE_FLAG_PHSYNC) polarity |= ST7789V_RGBCTRL_HSYNC_HIGH; if (ctx->info->bus_flags & DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE) - polarity |= ST7789V_RGBCTRL_PCLK_HIGH; + polarity |= ST7789V_RGBCTRL_PCLK_FALLING; if (ctx->info->bus_flags & DRM_BUS_FLAG_DE_LOW) polarity |= ST7789V_RGBCTRL_DE_LOW; -- 2.34.1
[PATCH v2 2/6] dt-bindings: display: st7789v: bound the number of Rx data lines
The ST7789V LCD controller supports regular SPI wiring, as well as no Rx data line at all. The operating system needs to know whether it can read registers from the device or not. Let's detail this specific design possibility by bounding the spi-rx-bus-width property. Signed-off-by: Miquel Raynal --- .../devicetree/bindings/display/panel/sitronix,st7789v.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index 0ccf0487fd8e..a25df7e1df88 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -29,6 +29,10 @@ properties: spi-cpha: true spi-cpol: true + spi-rx-bus-width: +minimum: 0 +maximum: 1 + required: - compatible - reg -- 2.34.1
Re: [PATCH] drm/panel: simple: Add Powertip PH800480T013 drm_display_mode flags
On Thu, Jun 15, 2023 at 10:16:02PM +0200, Marek Vasut wrote:
> Add missing drm_display_mode DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC
> flags. Those are used by various bridges in the pipeline to correctly
> configure its sync signals polarity.
>
> Fixes: d69de69f2be1 ("drm/panel: simple: Add Powertip PH800480T013 panel")
> Signed-off-by: Marek Vasut
I do not know PowerTip, but the patch looks fine.
Reviewed-by: Sam Ravnborg
> ---
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/panel/panel-simple.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index b81b21901940b..a0f4302de130a 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3202,6 +3202,7 @@ static const struct drm_display_mode
> powertip_ph800480t013_idf02_mode = {
> .vsync_start = 480 + 49,
> .vsync_end = 480 + 49 + 2,
> .vtotal = 480 + 49 + 2 + 22,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> };
>
> static const struct panel_desc powertip_ph800480t013_idf02 = {
> --
> 2.39.2
[PATCH v2 6/6] drm/panel: sitronix-st7789v: Check display ID
A very basic debugging rule when a device is connected for the first
time is to access a read-only register which contains known data in
order to ensure the communication protocol is properly working. This
driver lacked any read helper which is often a critical piece for
speed-up bring-ups.
Add a read helper and use it to verify the communication with the panel
is working as soon as possible in order to fail early if this is not the
case.
As this panel may work with no MISO line, the check is discarded in this
case.
Signed-off-by: Miquel Raynal
Acked-by: Sam Ravnborg
---
.../gpu/drm/panel/panel-sitronix-st7789v.c| 81 +++
1 file changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index 8649966ceae8..36fb3f2453f1 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -110,6 +110,9 @@
return val; \
} while (0)
+#define ST7789V_IDS { 0x85, 0x85, 0x52 }
+#define ST7789V_IDS_SIZE 3
+
struct st7789_panel_info {
const struct drm_display_mode *mode;
u32 bus_format;
@@ -157,6 +160,80 @@ static int st7789v_write_data(struct st7789v *ctx, u8 cmd)
return st7789v_spi_write(ctx, ST7789V_DATA, cmd);
}
+static int st7789v_read_data(struct st7789v *ctx, u8 cmd, u8 *buf,
+unsigned int len)
+{
+ struct spi_transfer xfer[2] = { };
+ struct spi_message msg;
+ u16 txbuf = ((ST7789V_COMMAND & 1) << 8) | cmd;
+ u16 rxbuf[4] = {};
+ u8 bit9 = 0;
+ int ret, i;
+
+ switch (len) {
+ case 1:
+ case 3:
+ case 4:
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ spi_message_init();
+
+ xfer[0].tx_buf =
+ xfer[0].len = sizeof(txbuf);
+ spi_message_add_tail([0], );
+
+ xfer[1].rx_buf = rxbuf;
+ xfer[1].len = len * 2;
+ spi_message_add_tail([1], );
+
+ ret = spi_sync(ctx->spi, );
+ if (ret)
+ return ret;
+
+ for (i = 0; i < len; i++) {
+ buf[i] = rxbuf[i] >> i | (bit9 << (9 - i));
+ if (i)
+ bit9 = rxbuf[i] & GENMASK(i - 1, 0);
+ }
+
+ return 0;
+}
+
+static int st7789v_check_id(struct drm_panel *panel)
+{
+ const u8 st7789v_ids[ST7789V_IDS_SIZE] = ST7789V_IDS;
+ struct st7789v *ctx = panel_to_st7789v(panel);
+ bool invalid_ids = false;
+ int ret, i;
+ u8 ids[3];
+
+ if (ctx->spi->mode & SPI_NO_RX)
+ return 0;
+
+ ret = st7789v_read_data(ctx, MIPI_DCS_GET_DISPLAY_ID, ids,
ST7789V_IDS_SIZE);
+ if (ret) {
+ dev_err(panel->dev, "Failed to read IDs\n");
+ return ret;
+ }
+
+ for (i = 0; i < ST7789V_IDS_SIZE; i++) {
+ if (ids[i] != st7789v_ids[i]) {
+ invalid_ids = true;
+ break;
+ }
+ }
+
+ if (invalid_ids) {
+ dev_err(panel->dev, "Unrecognized panel IDs");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static const struct drm_display_mode default_mode = {
.clock = 7000,
.hdisplay = 240,
@@ -295,6 +372,10 @@ static int st7789v_prepare(struct drm_panel *panel)
gpiod_set_value(ctx->reset, 0);
msleep(120);
+ ret = st7789v_check_id(panel);
+ if (ret)
+ return ret;
+
ST7789V_TEST(ret, st7789v_write_command(ctx, MIPI_DCS_EXIT_SLEEP_MODE));
/* We need to wait 120ms after a sleep out command */
--
2.34.1
[PATCH v2 0/6] drm/panel: sitronix-st7789v: Support ET028013DMA panel
Hello, The aim of this series is to add support for the EDT ET028013DMA panel. This panel features a Sitronix ST7789V2 LCD controller, which is already supported mainline (or very close to the ST7789V for which Maxime added support years ago). The EDT panel is slightly different on the geometry and appears not to support refresh rates higher than 30fps (above, glitches are visible, despite the incoming signals being rather clean). While I was working on this panel, I found quite inconvenient to not be able to read anything back as it is a great tool for debugging purposes. So the last patch actually adds a read helper and uses it to perform a sanity check at probe time by verifying the Sitronix controller IDs. This series applies on top of Sebastian's series which was also bringing a number of good improvements to this driver. As Sebastian started and contributed his work before me, I think his series is close to be merged so I adapted my changes on top of it. Link: https://lore.kernel.org/dri-devel/20230422205012.2464933-1-...@kernel.org/ Thanks, Miquèl Changes in v2: * Rebased on top of Sebastian's series and adapted all my changes to the existing infrastructure he has already added. * Collected tags. * Prevented the ID check to fail if there is no MISO line. * Used dev_err_probe() when relevant. * Sorted the IDs in the tables. * Renamed the panel mode. * Fixed typos. Miquel Raynal (6): dt-bindings: display: st7789v: Add the edt,et028013dma panel compatible dt-bindings: display: st7789v: bound the number of Rx data lines drm/panel: sitronix-st7789v: Use 9 bits per spi word by default drm/panel: sitronix-st7789v: Clarify a definition drm/panel: sitronix-st7789v: Add EDT ET028013DMA panel support drm/panel: sitronix-st7789v: Check display ID .../display/panel/sitronix,st7789v.yaml | 5 + .../gpu/drm/panel/panel-sitronix-st7789v.c| 116 +- 2 files changed, 118 insertions(+), 3 deletions(-) -- 2.34.1
[PATCH v2 1/6] dt-bindings: display: st7789v: Add the edt, et028013dma panel compatible
The ST7789V LCD controller is also embedded in the ET028013DMA panel. Add a compatible string to describe this other panel. Signed-off-by: Miquel Raynal --- .../devicetree/bindings/display/panel/sitronix,st7789v.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index 7c5e4313db1d..0ccf0487fd8e 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -16,6 +16,7 @@ allOf: properties: compatible: enum: + - edt,et028013dma - inanbo,t28cp45tn89-v17 - sitronix,st7789v -- 2.34.1
Re: [02/14] drm/ast: Remove vga2_clone field
On 2023/6/16 21:52, Thomas Zimmermann wrote:
Remove the unused field vga2_clone from struct ast_device. No
functional changes.
Yeah, it doesn't get used at all.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/drm/ast/ast_main.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 5498a6676f2e8..fc4760a67596f 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -166,7 +166,6 @@ struct ast_device {
void __iomem *dp501_fw_buf;
enum ast_chip chip;
- bool vga2_clone;
uint32_t dram_bus_width;
uint32_t dram_type;
uint32_t mclk;
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 1f35438f614a7..da33cfc6366ec 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -179,7 +179,6 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
drm_info(dev, "AST 2100 detected\n");
break;
}
- ast->vga2_clone = false;
} else {
ast->chip = AST2000;
drm_info(dev, "AST 2000 detected\n");
--
Jingfeng
Re: drm/atomic-helper: Update reference to drm_crtc_force_disable_all()
On 2023/6/16 21:54, Geert Uytterhoeven wrote:
drm_crtc_force_disable_all() was renamed to
drm_helper_force_disable_all(), but one reference was not updated.
Fixes: c2d88e06bcb98540 ("drm: Move the legacy kms disable_all helper to crtc
helpers")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Sui Jingfeng
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 41b8066f61fff4be..292e38eb621806a0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3332,7 +3332,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
* that also takes a snapshot of the modeset state to be restored on resume.
*
* This is just a convenience wrapper around drm_atomic_helper_disable_all(),
- * and it is the atomic version of drm_crtc_force_disable_all().
+ * and it is the atomic version of drm_helper_force_disable_all().
*/
void drm_atomic_helper_shutdown(struct drm_device *dev)
{
--
Jingfeng
[Bug 217545] Serious regression on amdgpu (drm_display_helper/drm_dp_atomic_find_time_slots) with two DisplayPort connected via a HP G5 docking station
https://bugzilla.kernel.org/show_bug.cgi?id=217545 --- Comment #5 from Christoph Biedl (bugzilla.kernel.b...@manchmal.in-ulm.de) --- Dear future reader, please be reminded this is still an ongoing issue, or as written in the drm/amd ticket: "this patch is just papering over underlying issues". So while it makes that specific setup usable, the ultimate fix is still not available yet. Check on the other bug tracker, or re-try newer kernel releases. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: drm/atomic-helper: Update reference to drm_crtc_force_disable_all()
Hi,
Nice patch!
By the way, thomas also fix a bug[1] by calling
drm_helper_force_disable_all() function
So this function seems useful. It deserved learn for a while. :-)
[1] https://patchwork.freedesktop.org/patch/541906/?series=119144=1
On 2023/6/16 21:54, Geert Uytterhoeven wrote:
drm_crtc_force_disable_all() was renamed to
drm_helper_force_disable_all(), but one reference was not updated.
Fixes: c2d88e06bcb98540 ("drm: Move the legacy kms disable_all helper to crtc
helpers")
Signed-off-by: Geert Uytterhoeven
Reviewed-by Sui Jingfeng
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 41b8066f61fff4be..292e38eb621806a0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3332,7 +3332,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
* that also takes a snapshot of the modeset state to be restored on resume.
*
* This is just a convenience wrapper around drm_atomic_helper_disable_all(),
- * and it is the atomic version of drm_crtc_force_disable_all().
+ * and it is the atomic version of drm_helper_force_disable_all().
*/
void drm_atomic_helper_shutdown(struct drm_device *dev)
{
--
Jingfeng
Re: [PATCH] drm/msm/adreno: Update MODULE_FIRMWARE macros
On Fri, Jun 16, 2023 at 02:28:15PM +0200, Juerg Haefliger wrote:
>
> Add missing MODULE_FIRMWARE macros and remove some for firmwares that
> the driver no longer references.
>
> Signed-off-by: Juerg Haefliger
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 23 ++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 8cff86e9d35c..9f70d7c1a72a 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -364,17 +364,32 @@ MODULE_FIRMWARE("qcom/a330_pm4.fw");
> MODULE_FIRMWARE("qcom/a330_pfp.fw");
> MODULE_FIRMWARE("qcom/a420_pm4.fw");
> MODULE_FIRMWARE("qcom/a420_pfp.fw");
> +MODULE_FIRMWARE("qcom/a506_zap.mdt");
> +MODULE_FIRMWARE("qcom/a508_zap.mdt");
> +MODULE_FIRMWARE("qcom/a512_zap.mdt");
> MODULE_FIRMWARE("qcom/a530_pm4.fw");
> MODULE_FIRMWARE("qcom/a530_pfp.fw");
> MODULE_FIRMWARE("qcom/a530v3_gpmu.fw2");
> MODULE_FIRMWARE("qcom/a530_zap.mdt");
> -MODULE_FIRMWARE("qcom/a530_zap.b00");
> -MODULE_FIRMWARE("qcom/a530_zap.b01");
> -MODULE_FIRMWARE("qcom/a530_zap.b02");
Why are these not required when "qcom/a530_zap.mdt" is present?
mdt & b0* binaries are different partitions of the same secure
firmware. Even though we specify only the .mdt file here, the PIL driver
will load the *.b0* file automatically. OTOH, "*.mbn" is a standalone
unified binary format.
If the requirement is to ensure that all necessary firmwares are part of
your distribution, you should include the *.b0* files too here.
-Akhil
> +MODULE_FIRMWARE("qcom/a540_gpmu.fw2");
> +MODULE_FIRMWARE("qcom/a540_zap.mdt");
> +MODULE_FIRMWARE("qcom/a615_zap.mdt");
> MODULE_FIRMWARE("qcom/a619_gmu.bin");
> MODULE_FIRMWARE("qcom/a630_sqe.fw");
> MODULE_FIRMWARE("qcom/a630_gmu.bin");
> -MODULE_FIRMWARE("qcom/a630_zap.mbn");
> +MODULE_FIRMWARE("qcom/a630_zap.mdt");
> +MODULE_FIRMWARE("qcom/a640_gmu.bin");
> +MODULE_FIRMWARE("qcom/a640_zap.mdt");
> +MODULE_FIRMWARE("qcom/a650_gmu.bin");
> +MODULE_FIRMWARE("qcom/a650_sqe.fw");
> +MODULE_FIRMWARE("qcom/a650_zap.mdt");
> +MODULE_FIRMWARE("qcom/a660_gmu.bin");
> +MODULE_FIRMWARE("qcom/a660_sqe.fw");
> +MODULE_FIRMWARE("qcom/a660_zap.mdt");
> +MODULE_FIRMWARE("qcom/leia_pfp_470.fw");
> +MODULE_FIRMWARE("qcom/leia_pm4_470.fw");
> +MODULE_FIRMWARE("qcom/yamato_pfp.fw");
> +MODULE_FIRMWARE("qcom/yamato_pm4.fw");
>
> static inline bool _rev_match(uint8_t entry, uint8_t id)
> {
> --
> 2.37.2
>
Re: [PATCH v1] drm/i915/gsc: Fix intel_gsc_uc_fw_proxy_init_done with directed wakerefs
On 6/15/2023 2:19 PM, Alan Previn wrote:
intel_gsc_uc_fw_proxy_init_done is used by a few code paths
and usages. However, certain paths need a wakeref while others
can't take a wakeref such as from the runtime_pm_resume callstack.
Add a param into this helper to allow callers to direct whether
to take the wakeref or not. This resolves the following bug:
INFO: task sh:2607 blocked for more than 61 seconds.
Not tainted 6.3.0-pxp-gsc-final-jun14+ #297
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:sh state:D stack:13016 pid:2607 ppid:2602
flags:0x4000
Call Trace:
__schedule+0x47b/0xe10
schedule+0x58/0xd0
rpm_resume+0x1cc/0x800
? __pfx_autoremove_wake_function+0x10/0x10
__pm_runtime_resume+0x42/0x80
__intel_runtime_pm_get+0x19/0x80 [i915]
gsc_uc_get_fw_status+0x10/0x50 [i915]
intel_gsc_uc_fw_init_done+0x9/0x20 [i915]
intel_gsc_uc_load_start+0x5b/0x130 [i915]
__uc_resume+0xa5/0x280 [i915]
intel_runtime_resume+0xd4/0x250 [i915]
? __pfx_pci_pm_runtime_resume+0x10/0x10
__rpm_callback+0x3c/0x160
Fixes: 8c33c3755b75 ("drm/i915/gsc: take a wakeref for the proxy-init-completion
check")
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
I'm going to send a trybot of this patch with the FW definition patch,
just to make sure there aren't any other issues that kick in once the FW
is defined and the code starts being executed, and merge if the results
are ok.
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 17 +++--
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 2 +-
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 856de9af1e3a..ab1a456f833d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -22,27 +22,32 @@ static bool gsc_is_in_reset(struct intel_uncore *uncore)
HECI1_FWSTS1_CURRENT_STATE_RESET;
}
-static u32 gsc_uc_get_fw_status(struct intel_uncore *uncore)
+static u32 gsc_uc_get_fw_status(struct intel_uncore *uncore, bool
needs_wakeref)
{
intel_wakeref_t wakeref;
u32 fw_status = 0;
- with_intel_runtime_pm(uncore->rpm, wakeref)
- fw_status = intel_uncore_read(uncore,
HECI_FWSTS(MTL_GSC_HECI1_BASE, 1));
+ if (needs_wakeref)
+ wakeref = intel_runtime_pm_get(uncore->rpm);
+ fw_status = intel_uncore_read(uncore, HECI_FWSTS(MTL_GSC_HECI1_BASE, 1));
+
+ if (needs_wakeref)
+ intel_runtime_pm_put(uncore->rpm, wakeref);
return fw_status;
}
-bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc)
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc, bool
needs_wakeref)
{
return REG_FIELD_GET(HECI1_FWSTS1_CURRENT_STATE,
-gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore)) ==
+gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore,
+ needs_wakeref)) ==
HECI1_FWSTS1_PROXY_STATE_NORMAL;
}
bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
{
- return gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore) &
+ return gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore, false) &
HECI1_FWSTS1_INIT_COMPLETE;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index 8d7b9e4f1ffc..ad2167ce9137 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -15,6 +15,6 @@ struct intel_uncore;
int intel_gsc_fw_get_binary_info(struct intel_uc_fw *gsc_fw, const void
*data, size_t size);
int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
-bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc);
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc, bool
needs_wakeref);
#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 85d90f0a15e3..75a3a0790ef3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -72,7 +72,7 @@ static void gsc_work(struct work_struct *work)
* complete the request handling cleanly, so we need to
check the
* status register to check if the proxy init was
actually successful
*/
- if (intel_gsc_uc_fw_proxy_init_done(gsc)) {
+ if (intel_gsc_uc_fw_proxy_init_done(gsc, false)) {
drm_dbg(>i915->drm, "GSC Proxy
Re: [PATCH v7 2/8] PCI/VGA: Deal only with VGA class devices
Hi,
On 2023/6/16 22:34, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 10:22 AM Sui Jingfeng wrote:
On 2023/6/16 21:41, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng wrote:
Hi,
On 2023/6/16 05:11, Alex Deucher wrote:
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote:
Hi,
On 2023/6/13 11:01, Sui Jingfeng wrote:
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
Cc: Bjorn Helgaas
Signed-off-by: Sui Jingfeng
---
drivers/pci/vgaarb.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
index c1bc6c983932..22a505e877dc 100644
--- a/drivers/pci/vgaarb.c
+++ b/drivers/pci/vgaarb.c
@@ -754,10 +754,6 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
*pdev)
struct pci_dev *bridge;
u16 cmd;
- /* Only deal with VGA class devices */
- if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
- return false;
-
Hi, here is probably a bug fixing.
For an example, nvidia render only GPU typically has 0x0380.
as its PCI class number, but render only GPU should not participate in
the arbitration.
As it shouldn't snoop the legacy fixed VGA address.
It(render only GPU) can not display anything.
But 0x0380 >> 8 = 0x03, the filter failed.
/* Allocate structure */
vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
if (vgadev == NULL) {
@@ -1500,7 +1496,9 @@ static int pci_notify(struct notifier_block *nb, unsigned
long action,
struct pci_dev *pdev = to_pci_dev(dev);
bool notify = false;
- vgaarb_dbg(dev, "%s\n", __func__);
+ /* Only deal with VGA class devices */
+ if (pdev->class != PCI_CLASS_DISPLAY_VGA << 8)
+ return 0;
So here we only care 0x0300, my initial intent is to make an optimization,
nowadays sane display graphic card should all has 0x0300 as its PCI
class number, is this complete right?
```
#define PCI_BASE_CLASS_DISPLAY0x03
#define PCI_CLASS_DISPLAY_VGA0x0300
#define PCI_CLASS_DISPLAY_XGA0x0301
#define PCI_CLASS_DISPLAY_3D0x0302
#define PCI_CLASS_DISPLAY_OTHER0x0380
```
Any ideas ?
I'm not quite sure what you are asking about here.
To be honest, I'm worried about the PCI devices which has a
PCI_CLASS_DISPLAY_XGA as its PCI class number.
As those devices are very uncommon in the real world.
$ find . -name "*.c" -type f | xargs grep "PCI_CLASS_DISPLAY_XGA"
Grep the "PCI_CLASS_DISPLAY_XGA" in the linux kernel tree got ZERO,
there no code reference this macro. So I think it seems safe to ignore
the XGA ?
PCI_CLASS_DISPLAY_3D and PCI_CLASS_DISPLAY_OTHER are used to annotate
the render-only GPU.
And render-only GPU can't decode the fixed VGA address space, it is safe
to ignore them.
For vga_arb, we
only care about VGA class devices since those should be on the only
ones that might have VGA routed to them.
However, as VGA gets deprecated,
We need the vgaarb for a system with multiple video card.
Not only because some Legacy VGA devices implemented
on PCI will typically have the same "hard-decoded" addresses;
But also these video card need to participate in the arbitration,
determine the default boot device.
But couldn't the boot device be determined via what whatever resources
were used by the pre-OS console?
I don't know what you are refer to by saying pre-OS console, UEFI
SHELL, UEFI GOP or something like that.
Right. Before the OS loads the platform firmware generally sets up
something for display. That could be GOP or vesa or some other
platform specific protocol.
If you are referring to the framebuffer driver which light up the screen
before the Linux kernel is loaded .
Then, what you have said is true, the boot device is determined by the
pre-OS console.
But the problem is how does the Linux kernel(vgaarb) could know which
one is the default boot device
on a multiple GPU machine. Relaying on the firmware fb's address and
size is what the mechanism
we already in using.
Right. It shouldn't need to depend on vgaarb.
I feel like that should be separate from vgaarb.
Emm, this really deserved another patch, please ?
vgaarb should handle PCI VGA routing and some other
mechanism should be used to determine what device provided the pre-OS
console.
If the new mechanism need the firmware changed, then this probably break
the old machine.
Also, this probably will get all arch involved. to get the new mechanism
supported.
The testing pressure and review power needed is quite large.
drm/amdgpu and drm/radeon already being used on X86, ARM64, Mips and
more arch...
The reviewing process will became quite difficult then.
vgaarb is really what we already in use, and being
Re: [PATCH 2/4] video: backlight: lp855x: get PWM for PWM mode during probe
On 14/06/2023 10:39, Uwe Kleine-König wrote:
> On Sat, Apr 29, 2023 at 12:45:32PM +0200, Artur Weber wrote:
>> Also deprecate the pwm-period DT property, as it is now redundant
>> (pwms property already contains period value).
>>
>> Signed-off-by: Artur Weber
>> ---
>> drivers/video/backlight/lp855x_bl.c | 48 -
>> 1 file changed, 26 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/video/backlight/lp855x_bl.c
>> b/drivers/video/backlight/lp855x_bl.c
>> index 81012bf29baf..21eb4943ed56 100644
>> --- a/drivers/video/backlight/lp855x_bl.c
>> +++ b/drivers/video/backlight/lp855x_bl.c
>> ...
>> @@ -472,11 +456,31 @@ static int lp855x_probe(struct i2c_client *cl)
>> lp->enable = devm_regulator_get_optional(dev, "enable");
>> if (IS_ERR(lp->enable)) {
>> ret = PTR_ERR(lp->enable);
>> -if (ret == -ENODEV) {
>> +if (ret == -ENODEV)
>> lp->enable = NULL;
>> -} else {
>> +else
>> return dev_err_probe(dev, ret, "getting enable
>> regulator\n");
>> -}
>> +}
>> +
>> +lp->pwm = devm_pwm_get(lp->dev, lp->chipname);
>> +if (IS_ERR(lp->pwm)) {
>> +ret = PTR_ERR(lp->pwm);
>> +if (ret == -ENODEV || ret == -EINVAL)
>
> Why would you ignore EINVAL?
EINVAL is returned when the pwms property is not found in the DT node
for the backlight. Not sure if there's a better way of separately
detecting whether it's present (especially when taking into
consideration non-DT platforms that might use the driver). Would be nice
to have something like devm_regulator_get_optional but for PWMs...
Still, someone who's setting up the driver could check the debug
messages to see if the backlight was set up in PWM mode or register mode.
> ...
>> +pwm_init_state(lp->pwm, );
>> +/* Legacy platform data compatibility */
>> +if (lp->pdata->period_ns > 0)
>> +pwmstate.period = lp->pdata->period_ns;
>> +pwm_apply_state(lp->pwm, );
>
> This is a change in behaviour. Before lp855x_probe() didn't modify the
> state the bootloader left the backlight in. Now you're disabling it (I
> think). Is this intended?
I didn't really consider the implication of this in this way, as on the
device I was testing this on (Exynos4212-based tablet) the PWM state
would get reset during PWM chip initialization in the kernel anyways,
meaning that the state from the bootloader would be lost regardless of
this change. Either way, there's no guarantee that this would be the
same on other devices, though I'd assume that in most cases it's not
noticeable anyways as brightness is usually set somewhere in userspace
(or even earlier, in the driver, if the init-brt property is set).
Nonetheless, that's an oversight on my part.
As for the reasoning for this change in behavior - the previous behavior
was to silently fail if, while setting the brightness, the PWM could not
be set up. This seemed rather confusing to me (I encountered this while
I was initially working on the tablet, I added a "pwm" property instead
of "pwms" and was wondering why the backlight didn't work...)
Of course, that could be fixed by adding error detection in the
brightness set function, but since I was already working on it, it made
more sense to me for the PWM to be set up during the probing process,
given that this way we could 1. warn about errors early, and 2. catch
deferred probes and defer the backlight's probe if we're still waiting
for the PWM. That's why it's done the way it is in this patch.
If this is undesired behavior, let me know and I'll submit another patch
to revert it.
Best regards
Artur
Re: [PATCH] drm/msm/adreno: Update MODULE_FIRMWARE macros
Hi Juerg,
On Fri, Jun 16, 2023 at 02:28:15PM +0200, Juerg Haefliger wrote:
> Add missing MODULE_FIRMWARE macros and remove some for firmwares that
> the driver no longer references.
>
> Signed-off-by: Juerg Haefliger
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 23 ++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 8cff86e9d35c..9f70d7c1a72a 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -364,17 +364,32 @@ MODULE_FIRMWARE("qcom/a330_pm4.fw");
> MODULE_FIRMWARE("qcom/a330_pfp.fw");
> MODULE_FIRMWARE("qcom/a420_pm4.fw");
> MODULE_FIRMWARE("qcom/a420_pfp.fw");
> +MODULE_FIRMWARE("qcom/a506_zap.mdt");
> +MODULE_FIRMWARE("qcom/a508_zap.mdt");
> +MODULE_FIRMWARE("qcom/a512_zap.mdt");
> MODULE_FIRMWARE("qcom/a530_pm4.fw");
> MODULE_FIRMWARE("qcom/a530_pfp.fw");
> MODULE_FIRMWARE("qcom/a530v3_gpmu.fw2");
> MODULE_FIRMWARE("qcom/a530_zap.mdt");
> -MODULE_FIRMWARE("qcom/a530_zap.b00");
> -MODULE_FIRMWARE("qcom/a530_zap.b01");
> -MODULE_FIRMWARE("qcom/a530_zap.b02");
> +MODULE_FIRMWARE("qcom/a540_gpmu.fw2");
> +MODULE_FIRMWARE("qcom/a540_zap.mdt");
> +MODULE_FIRMWARE("qcom/a615_zap.mdt");
> MODULE_FIRMWARE("qcom/a619_gmu.bin");
> MODULE_FIRMWARE("qcom/a630_sqe.fw");
> MODULE_FIRMWARE("qcom/a630_gmu.bin");
> -MODULE_FIRMWARE("qcom/a630_zap.mbn");
> +MODULE_FIRMWARE("qcom/a630_zap.mdt");
> +MODULE_FIRMWARE("qcom/a640_gmu.bin");
> +MODULE_FIRMWARE("qcom/a640_zap.mdt");
> +MODULE_FIRMWARE("qcom/a650_gmu.bin");
> +MODULE_FIRMWARE("qcom/a650_sqe.fw");
> +MODULE_FIRMWARE("qcom/a650_zap.mdt");
> +MODULE_FIRMWARE("qcom/a660_gmu.bin");
> +MODULE_FIRMWARE("qcom/a660_sqe.fw");
> +MODULE_FIRMWARE("qcom/a660_zap.mdt");
> +MODULE_FIRMWARE("qcom/leia_pfp_470.fw");
> +MODULE_FIRMWARE("qcom/leia_pm4_470.fw");
> +MODULE_FIRMWARE("qcom/yamato_pfp.fw");
> +MODULE_FIRMWARE("qcom/yamato_pm4.fw");
You should rebase this on top of the latest -next since the a690 needs
to be added as well.
Brian
[PATCH v9 1/2] dt-bindings: display: ti, am65x-dss: Add am625 dss compatible
The DSS controller on TI's AM625 SoC is an update from that on TI's AM65X SoC. The former has an additional OLDI TX on its first video port that helps output cloned video or WUXGA (1920x1200@60fps) resolution video output over a dual-link mode to reduce the required OLDI clock output. The second video port is same from AM65x DSS and it outputs DPI video data. It can support 2K resolutions @ 60fps, independently. Add the new controller's compatible and update descriptions. Signed-off-by: Aradhya Bhatia Acked-by: Krzysztof Kozlowski Reviewed-by: Tomi Valkeinen --- Notes: Changes from v8: * Add Krzysztof Kozlowski's and Tomi Valkeinen's tags. Changes from v7: * Drop the 3rd port property and update descriptions. * Drop the Reviewed-by tags of Krzysztof Kozlowski and Rahul T R because of the changes. .../bindings/display/ti/ti,am65x-dss.yaml | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index b6b402f16161..ae09cd3cbce1 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -12,14 +12,18 @@ maintainers: - Tomi Valkeinen description: | - The AM65x TI Keystone Display SubSystem with two output ports and - two video planes. The first video port supports OLDI and the second - supports DPI format. The fist plane is full video plane with all - features and the second is a "lite plane" without scaling support. + The AM625 and AM65x TI Keystone Display SubSystem with two output + ports and two video planes. In AM65x DSS, the first video port + supports 1 OLDI TX and in AM625 DSS, the first video port output is + internally routed to 2 OLDI TXes. The second video port supports DPI + format. The first plane is full video plane with all features and the + second is a "lite plane" without scaling support. properties: compatible: -const: ti,am65x-dss +enum: + - ti,am625-dss + - ti,am65x-dss reg: description: @@ -80,7 +84,9 @@ properties: port@0: $ref: /schemas/graph.yaml#/properties/port description: - The DSS OLDI output port node form video port 1 + For AM65x DSS, the OLDI output port node from video port 1. + For AM625 DSS, the internal DPI output port node from video + port 1. port@1: $ref: /schemas/graph.yaml#/properties/port -- 2.40.1
[PATCH v9 2/2] drm/tidss: Add support for AM625 DSS
Add support for the DSS controller on TI's AM625 SoC in the tidss
driver.
The AM625 DSS supports 2 video planes connecting to 2 video ports.
The first plane is a full plane supporting all the features, while the
2nd plane is a "lite" plane without scaling support.
The first video port in AM625 DSS internally provides DPI output to 2
OLDI transmitters. Each OLDI TX outputs 4 differential lanes of video
output and 1 of clock output.
This patch does not automatically enable the OLDI features of AM625 yet.
That support for OLDI will be added subsequently.
The second video port outputs DPI data directly out of the SoC. It has
24 data lines and can support a maximum of RGB888 output bus format.
Signed-off-by: Aradhya Bhatia
Reviewed-by: Tomi Valkeinen
---
Notes:
Changes from v8:
* Update commit message.
* Add Tomi Valkeinen's R-b tag.
Changes from v7:
* Drop all changes made after v3.
- Drop output bus type support. All outputs from DSS will be the
video port outptus.
* Make the first video port type as INTERNAL from OLDI.
drivers/gpu/drm/tidss/tidss_dispc.c | 57 -
drivers/gpu/drm/tidss/tidss_dispc.h | 2 +
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index dca077411f77..484da1aa27bb 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -275,6 +275,55 @@ const struct dispc_features dispc_j721e_feats = {
.vid_order = { 1, 3, 0, 2 },
};
+const struct dispc_features dispc_am625_feats = {
+ .max_pclk_khz = {
+ [DISPC_VP_DPI] = 165000,
+ [DISPC_VP_INTERNAL] = 17,
+ },
+
+ .scaling = {
+ .in_width_max_5tap_rgb = 1280,
+ .in_width_max_3tap_rgb = 2560,
+ .in_width_max_5tap_yuv = 2560,
+ .in_width_max_3tap_yuv = 4096,
+ .upscale_limit = 16,
+ .downscale_limit_5tap = 4,
+ .downscale_limit_3tap = 2,
+ /*
+* The max supported pixel inc value is 255. The value
+* of pixel inc is calculated like this: 1+(xinc-1)*bpp.
+* The maximum bpp of all formats supported by the HW
+* is 8. So the maximum supported xinc value is 32,
+* because 1+(32-1)*8 < 255 < 1+(33-1)*4.
+*/
+ .xinc_max = 32,
+ },
+
+ .subrev = DISPC_AM625,
+
+ .common = "common",
+ .common_regs = tidss_am65x_common_regs,
+
+ .num_vps = 2,
+ .vp_name = { "vp1", "vp2" },
+ .ovr_name = { "ovr1", "ovr2" },
+ .vpclk_name = { "vp1", "vp2" },
+ .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI },
+
+ .vp_feat = { .color = {
+ .has_ctm = true,
+ .gamma_size = 256,
+ .gamma_type = TIDSS_GAMMA_8BIT,
+ },
+ },
+
+ .num_planes = 2,
+ /* note: vid is plane_id 0 and vidl1 is plane_id 1 */
+ .vid_name = { "vid", "vidl1" },
+ .vid_lite = { false, true, },
+ .vid_order = { 1, 0 },
+};
+
static const u16 *dispc_common_regmap;
struct dss_vp_data {
@@ -776,6 +825,7 @@ dispc_irq_t dispc_read_and_clear_irqstatus(struct
dispc_device *dispc)
switch (dispc->feat->subrev) {
case DISPC_K2G:
return dispc_k2g_read_and_clear_irqstatus(dispc);
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
return dispc_k3_read_and_clear_irqstatus(dispc);
@@ -791,6 +841,7 @@ void dispc_set_irqenable(struct dispc_device *dispc,
dispc_irq_t mask)
case DISPC_K2G:
dispc_k2g_set_irqenable(dispc, mask);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_set_irqenable(dispc, mask);
@@ -1281,6 +1332,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc, u32
hw_plane,
dispc_k2g_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
@@ -2199,6 +2251,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
case DISPC_K2G:
dispc_k2g_plane_init(dispc);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_plane_init(dispc);
@@ -2305,6 +2358,7 @@ static void dispc_vp_write_gamma_table(struct
dispc_device *dispc,
case DISPC_K2G:
dispc_k2g_vp_write_gamma_table(dispc, hw_videoport);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
[PATCH v9 0/2] Add DSS support for AM625 SoC
This patch series adds a new compatible for the Display SubSystem (DSS) controller on TI's AM625 SoC. It further adds the required support for the same in the tidss driver. The AM625-DSS is a newer version of the DSS from the AM65X version with the major change being the addition of another OLDI TX. With the help of 2 OLDI TXes, the AM625 DSS can support dual-linked OLDI displays with a resolution of up-to 2K or WUXGA (1920x1200@60fps) at half the OLDI clock frequency or even cloned video outputs on each of the TXes. This patch series acts as a continuation of the patches posted in v3[1]. The OLDI support patches combined from v5 onwards are now separated again. The OLDI support will be added subsequently with a separte patch series. I have tested these patches on AM625 SK-EVM and AM625 based Beagle Play. To test this series on AM625 based platforms, basic display support patches (for driver + devicetree) can be found in the "next_am62-base_support-V2" branch on my github fork[2]. [1]: V3: https://patchwork.freedesktop.org/series/105373/ [2]: https://github.com/aradhya07/linux-ab/tree/next_am62-base_support-V2 Previous versions: - V8: https://patchwork.freedesktop.org/series/119088/ - V7: https://patchwork.freedesktop.org/series/113328/ - V6: https://patchwork.freedesktop.org/series/06/ - V5: https://patchwork.freedesktop.org/series/109194/ Changelog: V9: - Edit the commit message for Patch 2/2. - Add Krzysztof Kozlowski's and Tomi Valkeinen's tags. V8: - Rebase for current merge window. - Drop all the OLDI support patches. - Update the binding to remove the 2nd OLDI port instances. - Drop the Reviewed-by tags of Krzysztof Kozlowski and Rahul T R because of the changes. V7: - Rebase to current linux-next. - Address Tomi Valkeinen's comments. 1. Separate the DSS VP and output port coupling. v6 introduced 'output_port_bus_type' in addition to 'vp_bus_type' but having both of the variables was redundant. Hence, in v7 the 'output_port_bus_type' essentially replaces 'vp_bus_type'. 2. Break Patch v6 2/5 into 2 separate patches (v7 1/6 and v7 3/6). 3. Change in name and addition of OLDI mode macros. 4. Other minor changes. V6: - Rebase for current merge window. - Add 'allOf:' condition in the DT binding. - Address Tomi Valkeinen's comments. 1. Combine DT binding patches for new compatible and 3rd DSS port. 2. Further separate DSS VPs and output ports. 3. Separate OLDI mode discovery logic from the panel/bridge discovery (which allowed support for OLDI bridges as well.) 4. Organize OLDI IO control register macros platform wise. V5: - Rebase for current merge window. - Add max DT ports in DSS features. - Combine the OLDI support series. (Changes from OLDI support series v1) - Address Tomi Valkeinen's comments. 1. Update the OLDI link detection approach. 2. Add port #3 for 2nd OLDI TX. 3. Configure 2 panel-bridges for cloned panels. 4. Drop the OLDI clock set patch. 5. Drop rgb565-to-888 patch. V3: - Change yaml enum in alphabetical order. - Correct a typo. V2: - Remove redundant register array. Aradhya Bhatia (2): dt-bindings: display: ti,am65x-dss: Add am625 dss compatible drm/tidss: Add support for AM625 DSS .../bindings/display/ti/ti,am65x-dss.yaml | 18 -- drivers/gpu/drm/tidss/tidss_dispc.c | 57 ++- drivers/gpu/drm/tidss/tidss_dispc.h | 2 + drivers/gpu/drm/tidss/tidss_drv.c | 1 + 4 files changed, 71 insertions(+), 7 deletions(-) -- 2.40.1
Re: [PATCH v3 01/38] backlight/bd6107: Compare against struct fb_info.device
Hi Lee Am 14.06.23 um 16:13 schrieb Thomas Zimmermann: [...] Can the Backlight patches be applied without the others and visa versa? Unfortunately not. The rest of the series requires the backlight patches. Are you OK with the patches going through drm? Best regards Thomas Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v7 2/8] PCI/VGA: Deal only with VGA class devices
On Fri, Jun 16, 2023 at 10:22 AM Sui Jingfeng wrote:
>
>
> On 2023/6/16 21:41, Alex Deucher wrote:
> > On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng
> > wrote:
> >> Hi,
> >>
> >> On 2023/6/16 05:11, Alex Deucher wrote:
> >>> On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng
> >>> wrote:
> Hi,
>
> On 2023/6/13 11:01, Sui Jingfeng wrote:
> > From: Sui Jingfeng
> >
> > Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
> > pci_get_subsys() function with pci_get_class(). Filter the non-PCI
> > display
> > device(pdev->class != 0x0300) out. There no need to process the
> > non-display
> > PCI device.
> >
> > Cc: Bjorn Helgaas
> > Signed-off-by: Sui Jingfeng
> > ---
> > drivers/pci/vgaarb.c | 22 --
> > 1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> > index c1bc6c983932..22a505e877dc 100644
> > --- a/drivers/pci/vgaarb.c
> > +++ b/drivers/pci/vgaarb.c
> > @@ -754,10 +754,6 @@ static bool vga_arbiter_add_pci_device(struct
> > pci_dev *pdev)
> > struct pci_dev *bridge;
> > u16 cmd;
> >
> > - /* Only deal with VGA class devices */
> > - if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> > - return false;
> > -
> Hi, here is probably a bug fixing.
>
> For an example, nvidia render only GPU typically has 0x0380.
>
> as its PCI class number, but render only GPU should not participate in
> the arbitration.
>
> As it shouldn't snoop the legacy fixed VGA address.
>
> It(render only GPU) can not display anything.
>
>
> But 0x0380 >> 8 = 0x03, the filter failed.
>
>
> > /* Allocate structure */
> > vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
> > if (vgadev == NULL) {
> > @@ -1500,7 +1496,9 @@ static int pci_notify(struct notifier_block *nb,
> > unsigned long action,
> > struct pci_dev *pdev = to_pci_dev(dev);
> > bool notify = false;
> >
> > - vgaarb_dbg(dev, "%s\n", __func__);
> > + /* Only deal with VGA class devices */
> > + if (pdev->class != PCI_CLASS_DISPLAY_VGA << 8)
> > + return 0;
> So here we only care 0x0300, my initial intent is to make an
> optimization,
>
> nowadays sane display graphic card should all has 0x0300 as its PCI
> class number, is this complete right?
>
> ```
>
> #define PCI_BASE_CLASS_DISPLAY0x03
> #define PCI_CLASS_DISPLAY_VGA0x0300
> #define PCI_CLASS_DISPLAY_XGA0x0301
> #define PCI_CLASS_DISPLAY_3D0x0302
> #define PCI_CLASS_DISPLAY_OTHER0x0380
>
> ```
>
> Any ideas ?
> >>> I'm not quite sure what you are asking about here.
> >> To be honest, I'm worried about the PCI devices which has a
> >>
> >> PCI_CLASS_DISPLAY_XGA as its PCI class number.
> >>
> >> As those devices are very uncommon in the real world.
> >>
> >>
> >> $ find . -name "*.c" -type f | xargs grep "PCI_CLASS_DISPLAY_XGA"
> >>
> >>
> >> Grep the "PCI_CLASS_DISPLAY_XGA" in the linux kernel tree got ZERO,
> >>
> >> there no code reference this macro. So I think it seems safe to ignore
> >> the XGA ?
> >>
> >>
> >> PCI_CLASS_DISPLAY_3D and PCI_CLASS_DISPLAY_OTHER are used to annotate
> >> the render-only GPU.
> >>
> >> And render-only GPU can't decode the fixed VGA address space, it is safe
> >> to ignore them.
> >>
> >>
> >>>For vga_arb, we
> >>> only care about VGA class devices since those should be on the only
> >>> ones that might have VGA routed to them.
> >>>However, as VGA gets deprecated,
> >> We need the vgaarb for a system with multiple video card.
> >>
> >> Not only because some Legacy VGA devices implemented
> >>
> >> on PCI will typically have the same "hard-decoded" addresses;
> >>
> >> But also these video card need to participate in the arbitration,
> >>
> >> determine the default boot device.
> > But couldn't the boot device be determined via what whatever resources
> > were used by the pre-OS console?
>
> I don't know what you are refer to by saying pre-OS console, UEFI
> SHELL, UEFI GOP or something like that.
>
Right. Before the OS loads the platform firmware generally sets up
something for display. That could be GOP or vesa or some other
platform specific protocol.
> If you are referring to the framebuffer driver which light up the screen
> before the Linux kernel is loaded .
>
>
> Then, what you have said is true, the boot device is determined by the
> pre-OS console.
>
> But the problem is how does the Linux kernel(vgaarb) could know which
> one is the default boot device
>
> on a multiple GPU machine. Relaying on the firmware fb's address and
> size is what the mechanism
>
> we already in
Re: [01/14] drm/ast: Fix DRAM init on AST2200
On 2023/6/16 21:52, Thomas Zimmermann wrote:
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000
series (v2)")
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v3.5+
---
drivers/gpu/drm/ast/ast_post.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index a005aec18a020..0262aaafdb1c5 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -291,7 +291,7 @@ static void ast_init_dram_reg(struct drm_device *dev)
;
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
- if (ast->chip == AST2100 || ast->chip == 2200)
+ if (ast->chip == AST2100 || ast->chip == AST2200)
dram_reg_info = ast2100_dram_table_data;
else
dram_reg_info = ast1100_dram_table_data;
--
Jingfeng
Re: [PATCH 00/14] drm/ast: Refactor the device-detection code
Hi, On 2023/6/16 21:52, Thomas Zimmermann wrote: Ast's code for detecting the device type and features is convoluted. It mixes up several state fields, chip types and sub-models. Rework the driver into somehting more understandable. "somehting" -> "something" Patches 1 fixes a long-standing bug. The affected code has never worked correctly. Patches 2 to 8 make various changes to the init code, or remove dead and duplicated code paths. Patch 9 introduces chip generations. Until now, ast used the value of enum ast_chip to represent a certain set of related modes, and also used the enum to represent individal models. This makes the driver code hard to understand in certain places. The patch encodes a chip generation in each model enum and converts the driver to use it. Patches 10 to 12 replace duplicated model checks with the correct enum value. Detection of wide-screen functionality and the transmitter chip can then be moved into individual functions in patch 13. Patch 14 merges the detection of the silicon revision and the chip model into s single function. 's' -> 'a' Both need to be done in the same place and affect each other. Tested on AST1100 and AST2300. Thomas Zimmermann (14): drm/ast: Fix DRAM init on AST2200 drm/ast: Remove vga2_clone field drm/ast: Implement register helpers in ast_drv.h drm/ast: Remove dead else branch in POST code drm/ast: Remove device POSTing and config from chip detection drm/ast: Set PCI config before accessing I/O registers drm/ast: Enable and unlock device access early during init drm/ast: Set up release action right after enabling MMIO drm/ast: Distinguish among chip generations drm/ast: Detect AST 1300 model drm/ast: Detect AST 1400 model drm/ast: Detect AST 2510 model drm/ast: Move widescreen- and tx-chip detection into separate helpers drm/ast: Merge config and chip detection drivers/gpu/drm/ast/ast_dp501.c | 6 +- drivers/gpu/drm/ast/ast_drv.h | 97 +++--- drivers/gpu/drm/ast/ast_main.c | 320 +++- drivers/gpu/drm/ast/ast_mm.c| 2 - drivers/gpu/drm/ast/ast_mode.c | 35 ++-- drivers/gpu/drm/ast/ast_post.c | 74 ++-- 6 files changed, 294 insertions(+), 240 deletions(-) -- Jingfeng
Re: [PATCH v8 2/2] drm/tidss: Add support for AM625 DSS
Hi Tomi, Thank you for the reviews! On 16-Jun-23 18:15, Tomi Valkeinen wrote: > Hi, > > On 08/06/2023 19:37, Aradhya Bhatia wrote: >> Add support for the DSS controller on TI's AM625 SoC in the tidss >> driver. >> >> The AM625 DSS supports 2 video planes connecting to 2 video ports. >> The first plane is a full plane supporting all the features, while the >> 2nd plane is a "lite" plane without scaling support. > > The DRM planes are reversed compared to the HW planes, aren't they? Is > the above referring to HW planes? Yes, I am referring to the HW planes, and the DRM planes reversed as well. =) > >> The first video port in AM625 DSS internally provides DPI output to 2 >> OLDI transmitters. Each OLDI TX outputs 4 differential lanes of video >> output and 1 of clock output. > > I think it should be explained that OLDI is not supported in this > version, but will be added later. Okay, I will make the change. Regards Aradhya > > Other than that: > > Reviewed-by: Tomi Valkeinen > > Tomi >
Re: [PATCH v3 02/17] dt-bindings: gpu: Add Imagination Technologies PowerVR GPU
On Fri, Jun 16, 2023 at 6:49 AM Linus Walleij wrote: > > Hi Sarah, > > thanks for your patch! > > On Tue, Jun 13, 2023 at 5:20 PM Sarah Walker wrote: > > > Add the device tree binding documentation for the Series AXE GPU used in > > TI AM62 SoCs. > > > > Signed-off-by: Sarah Walker > > > +properties: > > + compatible: > > +oneOf: > > + - items: > > + - enum: > > + - ti,am62-gpu > > + - const: img,powervr-seriesaxe > > I don't see why you need to restrict the bindings to just the stuff > you happen to > be writing Linux drivers for right now. > > Add all of them! > > There is this out-of-tree binding: > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commit/0ddd308a78926782b8a72f75c74b91417ceb9779 > > With these two on top: > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commit/053346e1933932815066f16ebf6e6bda45d67548 > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commit/1cb62c4cdcad096d438ee7d1d51f6001998acee3 > > They are indeed out-of-tree, but H. Nikolaus is a well-known and respected > contributor to the kernel, and I'm pretty sure he would be contributing > these upstream if he had the time and incentive. He did try[1]. Rob [1] https://lore.kernel.org/all/cover.1587760454.git@goldelico.com/
Re: [PATCH v7 2/8] PCI/VGA: Deal only with VGA class devices
On 2023/6/16 21:41, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng wrote:
Hi,
On 2023/6/16 05:11, Alex Deucher wrote:
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote:
Hi,
On 2023/6/13 11:01, Sui Jingfeng wrote:
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
Cc: Bjorn Helgaas
Signed-off-by: Sui Jingfeng
---
drivers/pci/vgaarb.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
index c1bc6c983932..22a505e877dc 100644
--- a/drivers/pci/vgaarb.c
+++ b/drivers/pci/vgaarb.c
@@ -754,10 +754,6 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
*pdev)
struct pci_dev *bridge;
u16 cmd;
- /* Only deal with VGA class devices */
- if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
- return false;
-
Hi, here is probably a bug fixing.
For an example, nvidia render only GPU typically has 0x0380.
as its PCI class number, but render only GPU should not participate in
the arbitration.
As it shouldn't snoop the legacy fixed VGA address.
It(render only GPU) can not display anything.
But 0x0380 >> 8 = 0x03, the filter failed.
/* Allocate structure */
vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
if (vgadev == NULL) {
@@ -1500,7 +1496,9 @@ static int pci_notify(struct notifier_block *nb, unsigned
long action,
struct pci_dev *pdev = to_pci_dev(dev);
bool notify = false;
- vgaarb_dbg(dev, "%s\n", __func__);
+ /* Only deal with VGA class devices */
+ if (pdev->class != PCI_CLASS_DISPLAY_VGA << 8)
+ return 0;
So here we only care 0x0300, my initial intent is to make an optimization,
nowadays sane display graphic card should all has 0x0300 as its PCI
class number, is this complete right?
```
#define PCI_BASE_CLASS_DISPLAY0x03
#define PCI_CLASS_DISPLAY_VGA0x0300
#define PCI_CLASS_DISPLAY_XGA0x0301
#define PCI_CLASS_DISPLAY_3D0x0302
#define PCI_CLASS_DISPLAY_OTHER0x0380
```
Any ideas ?
I'm not quite sure what you are asking about here.
To be honest, I'm worried about the PCI devices which has a
PCI_CLASS_DISPLAY_XGA as its PCI class number.
As those devices are very uncommon in the real world.
$ find . -name "*.c" -type f | xargs grep "PCI_CLASS_DISPLAY_XGA"
Grep the "PCI_CLASS_DISPLAY_XGA" in the linux kernel tree got ZERO,
there no code reference this macro. So I think it seems safe to ignore
the XGA ?
PCI_CLASS_DISPLAY_3D and PCI_CLASS_DISPLAY_OTHER are used to annotate
the render-only GPU.
And render-only GPU can't decode the fixed VGA address space, it is safe
to ignore them.
For vga_arb, we
only care about VGA class devices since those should be on the only
ones that might have VGA routed to them.
However, as VGA gets deprecated,
We need the vgaarb for a system with multiple video card.
Not only because some Legacy VGA devices implemented
on PCI will typically have the same "hard-decoded" addresses;
But also these video card need to participate in the arbitration,
determine the default boot device.
But couldn't the boot device be determined via what whatever resources
were used by the pre-OS console?
I don't know what you are refer to by saying pre-OS console, UEFI
SHELL, UEFI GOP or something like that.
If you are referring to the framebuffer driver which light up the screen
before the Linux kernel is loaded .
Then, what you have said is true, the boot device is determined by the
pre-OS console.
But the problem is how does the Linux kernel(vgaarb) could know which
one is the default boot device
on a multiple GPU machine. Relaying on the firmware fb's address and
size is what the mechanism
we already in using.
I feel like that should be separate from vgaarb.
Emm, this really deserved another patch, please ?
vgaarb should handle PCI VGA routing and some other
mechanism should be used to determine what device provided the pre-OS
console.
If the new mechanism need the firmware changed, then this probably break
the old machine.
Also, this probably will get all arch involved. to get the new mechanism
supported.
The testing pressure and review power needed is quite large.
drm/amdgpu and drm/radeon already being used on X86, ARM64, Mips and
more arch...
The reviewing process will became quite difficult then.
vgaarb is really what we already in use, and being used more than ten
years ...
Alex
Nowadays, the 'VGA devices' here is stand for the Graphics card
which is capable of display something on the screen.
We still need vgaarb to select the default boot device.
you'll have more non VGA PCI classes for devices which
could be the pre-OS console
