[linux-next:master] BUILD REGRESSION e2425464bc87159274879ab30f9d4fe624b9fcd2

2024-01-05 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: e2425464bc87159274879ab30f9d4fe624b9fcd2  Add linux-next specific 
files for 20240105

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202401061458.1ympozgi-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

Warning: /sys/devices/.../hwmon/hwmon/curr1_crit is defined 2 times:  
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon:35  
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon:52
Warning: /sys/devices/.../hwmon/hwmon/energy1_input is defined 2 times:  
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon:54  
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon:65
Warning: /sys/devices/.../hwmon/hwmon/in0_input is defined 2 times:  
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon:46  
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon:0
Warning: /sys/devices/.../hwmon/hwmon/power1_crit is defined 2 times:  
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon:22  
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon:39
Warning: /sys/devices/.../hwmon/hwmon/power1_max is defined 2 times:  
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon:0  
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon:8
Warning: /sys/devices/.../hwmon/hwmon/power1_max_interval is defined 2 
times:  Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon:62  
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon:30
Warning: /sys/devices/.../hwmon/hwmon/power1_rated_max is defined 2 times:  
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon:14  
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon:22

Unverified Error/Warning (likely false positive, please contact us if 
interested):

drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c:6147:9-13: ERROR: invalid 
reference to the index variable of the iterator on line 6138
drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c:6357:1-7: preceding lock on 
line 6318
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c:575:9-32: duplicated 
argument to & or |
{standard input}:20841: Warning: overflow in branch to .L4773; converted into 
longer instruction sequence
{standard input}:52226: Warning: overflow in branch to .L4679; converted into 
longer instruction sequence
{standard input}:54153: Warning: overflow in branch to .L4936; converted into 
longer instruction sequence
{standard input}:5891: Warning: overflow in branch to .L1414; converted into 
longer instruction sequence

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- arm-randconfig-r062-20240105
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-dst_addr-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-filled_descs_num-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-size-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-src_addr-not-described-in-xdma_fill_descs
|   `-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-sw_desc-not-described-in-xdma_fill_descs
|-- arm64-randconfig-r053-20240104
|   |-- 
drivers-net-ethernet-marvell-octeontx2-af-rvu_nix.c:ERROR:invalid-reference-to-the-index-variable-of-the-iterator-on-line
|   |-- 
drivers-net-ethernet-marvell-octeontx2-af-rvu_nix.c:preceding-lock-on-line
|   `-- 
drivers-net-ethernet-marvell-octeontx2-af-rvu_npc_fs.c:duplicated-argument-to-or
|-- i386-randconfig-012-20240105
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-dst_addr-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-filled_descs_num-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-size-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-src_addr-not-described-in-xdma_fill_descs
|   `-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-sw_desc-not-described-in-xdma_fill_descs
|-- i386-randconfig-016-20240105
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-dst_addr-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-filled_descs_num-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-size-not-described-in-xdma_fill_descs
|   |-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-src_addr-not-described-in-xdma_fill_descs
|   `-- 
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-sw_desc-not-described-in-xdma_fill_descs
|-- m68k-randconfig-r113-20240105
|   |-- 
WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-base-regmap-regmap-mmio.o
|   `-- drivers-h

Re: [PATCH v3 3/4] drm/msm: add a kernel param to select between MDP5 and DPU drivers

2024-01-05 Thread Dmitry Baryshkov
On Sat, 6 Jan 2024 at 02:04, Carl Vanderlip  wrote:
>
>
> On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
> > For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
> > possible to support this platform via the DPU driver (e.g. to provide
> > support for DP, multirect, etc). Add a modparam to be able to switch
> > between these two drivers.
> >
> > All platforms supported by both drivers are by default handled by the
> > MDP5 driver. To let them be handled by the DPU driver pass the
> > `msm.prefer_mdp5=false` kernel param.
> >
> > Reviewed-by: Stephen Boyd 
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  3 +++
> >   drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  3 +++
> >   drivers/gpu/drm/msm/msm_drv.c| 31 
> > +++
> >   drivers/gpu/drm/msm/msm_drv.h|  1 +
> >   4 files changed, 38 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index aa9e0ad33ebb..8f11a98491a1 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > @@ -1276,6 +1276,9 @@ static int dpu_dev_probe(struct platform_device *pdev)
> >   int irq;
> >   int ret = 0;
> >
> > + if (!msm_disp_drv_should_bind(>dev, true))
> > + return -ENODEV;
> > +
> >   dpu_kms = devm_kzalloc(dev, sizeof(*dpu_kms), GFP_KERNEL);
> >   if (!dpu_kms)
> >   return -ENOMEM;
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > index 0827634664ae..43d05851c54d 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > @@ -866,6 +866,9 @@ static int mdp5_dev_probe(struct platform_device *pdev)
> >
> >   DBG("");
> >
> > + if (!msm_disp_drv_should_bind(>dev, false))
> > + return -ENODEV;
> > +
> >   mdp5_kms = devm_kzalloc(>dev, sizeof(*mdp5_kms), GFP_KERNEL);
> >   if (!mdp5_kms)
> >   return -ENOMEM;
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index 50b65ffc24b1..ef57586fbeca 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -969,6 +969,37 @@ static int add_components_mdp(struct device 
> > *master_dev,
> >   return 0;
> >   }
> >
> > +#if !IS_REACHABLE(CONFIG_DRM_MSM_MDP5) || !IS_REACHABLE(CONFIG_DRM_MSM_DPU)
> > +bool msm_disp_drv_should_bind(struct device *dev, bool mdp5_driver)
>
> s/mdp5_driver/dpu_driver/

Well, ignored_driver, but your suggestion is better.

>
> > +{
> > + /* If just a single driver is enabled, use it no matter what */
> > + return true;
> > +}
>
> This will cause both MDP/DPU probes to return -ENODEV, rather than
> select the enabled one.

No. The code (e.g. for DPU) is:

   if (!msm_disp_drv_should_bind(>dev, true))
return -ENODEV;

So the driver returns -ENODEV if msm_disp_drv_should_bind() returns
false. Which is logical from the function name point of view.

>
> > +#else
> > +
> > +static bool prefer_mdp5 = true;
> > +MODULE_PARM_DESC(prefer_mdp5, "Select whether MDP5 or DPU driver should be 
> > preferred");
> > +module_param(prefer_mdp5, bool, 0444);
> > +
> > +/* list all platforms supported by both mdp5 and dpu drivers */
> > +static const char *const msm_mdp5_dpu_migration[] = {
> > + NULL,
> > +};
> > +
> > +bool msm_disp_drv_should_bind(struct device *dev, bool dpu_driver)
> > +{
> > + /* If it is not an MDP5 device, do not try MDP5 driver */
> > + if (!of_device_is_compatible(dev->of_node, "qcom,mdp5"))
> > + return dpu_driver;
> > +
> > + /* If it is not in the migration list, use MDP5 */
> > + if (!of_device_compatible_match(dev->of_node, msm_mdp5_dpu_migration))
> > + return !dpu_driver;
> > +
> > + return prefer_mdp5 ? !dpu_driver : dpu_driver;
> > +}
> > +#endif
> > +
> >   /*
> >* We don't know what's the best binding to link the gpu with the drm 
> > device.
> >* Fow now, we just hunt for all the possible gpus that we support, and 
> > add them
> > diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> > index 01e783130054..762e13e2df74 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.h
> > +++ b/drivers/gpu/drm/msm/msm_drv.h
> > @@ -563,5 +563,6 @@ int msm_drv_probe(struct device *dev,
> >   struct msm_kms *kms);
> >   void msm_kms_shutdown(struct platform_device *pdev);
> >
> > +bool msm_disp_drv_should_bind(struct device *dev, bool dpu_driver);
> >
> >   #endif /* __MSM_DRV_H__ */
> >



-- 
With best wishes
Dmitry


Re: [PATCH v3 3/4] drm/msm: add a kernel param to select between MDP5 and DPU drivers

2024-01-05 Thread Carl Vanderlip



On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:

For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.

All platforms supported by both drivers are by default handled by the
MDP5 driver. To let them be handled by the DPU driver pass the
`msm.prefer_mdp5=false` kernel param.

Reviewed-by: Stephen Boyd 
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  3 +++
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  3 +++
  drivers/gpu/drm/msm/msm_drv.c| 31 +++
  drivers/gpu/drm/msm/msm_drv.h|  1 +
  4 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index aa9e0ad33ebb..8f11a98491a1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1276,6 +1276,9 @@ static int dpu_dev_probe(struct platform_device *pdev)
int irq;
int ret = 0;
  
+	if (!msm_disp_drv_should_bind(>dev, true))

+   return -ENODEV;
+
dpu_kms = devm_kzalloc(dev, sizeof(*dpu_kms), GFP_KERNEL);
if (!dpu_kms)
return -ENOMEM;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 0827634664ae..43d05851c54d 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -866,6 +866,9 @@ static int mdp5_dev_probe(struct platform_device *pdev)
  
  	DBG("");
  
+	if (!msm_disp_drv_should_bind(>dev, false))

+   return -ENODEV;
+
mdp5_kms = devm_kzalloc(>dev, sizeof(*mdp5_kms), GFP_KERNEL);
if (!mdp5_kms)
return -ENOMEM;
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 50b65ffc24b1..ef57586fbeca 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -969,6 +969,37 @@ static int add_components_mdp(struct device *master_dev,
return 0;
  }
  
+#if !IS_REACHABLE(CONFIG_DRM_MSM_MDP5) || !IS_REACHABLE(CONFIG_DRM_MSM_DPU)

+bool msm_disp_drv_should_bind(struct device *dev, bool mdp5_driver)


s/mdp5_driver/dpu_driver/


+{
+   /* If just a single driver is enabled, use it no matter what */
+   return true;
+}


This will cause both MDP/DPU probes to return -ENODEV, rather than
select the enabled one.


+#else
+
+static bool prefer_mdp5 = true;
+MODULE_PARM_DESC(prefer_mdp5, "Select whether MDP5 or DPU driver should be 
preferred");
+module_param(prefer_mdp5, bool, 0444);
+
+/* list all platforms supported by both mdp5 and dpu drivers */
+static const char *const msm_mdp5_dpu_migration[] = {
+   NULL,
+};
+
+bool msm_disp_drv_should_bind(struct device *dev, bool dpu_driver)
+{
+   /* If it is not an MDP5 device, do not try MDP5 driver */
+   if (!of_device_is_compatible(dev->of_node, "qcom,mdp5"))
+   return dpu_driver;
+
+   /* If it is not in the migration list, use MDP5 */
+   if (!of_device_compatible_match(dev->of_node, msm_mdp5_dpu_migration))
+   return !dpu_driver;
+
+   return prefer_mdp5 ? !dpu_driver : dpu_driver;
+}
+#endif
+
  /*
   * We don't know what's the best binding to link the gpu with the drm device.
   * Fow now, we just hunt for all the possible gpus that we support, and add 
them
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 01e783130054..762e13e2df74 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -563,5 +563,6 @@ int msm_drv_probe(struct device *dev,
struct msm_kms *kms);
  void msm_kms_shutdown(struct platform_device *pdev);
  
+bool msm_disp_drv_should_bind(struct device *dev, bool dpu_driver);
  
  #endif /* __MSM_DRV_H__ */




[PATCH] drm/msm/dpu: make "vblank timeout" more useful

2024-01-05 Thread Dmitry Baryshkov
We have several reports of vblank timeout messages. However after some
debugging it was found that there might be different causes to that.
Include the actual CTL_FLUSH value into the timeout message. This allows
us to identify the DPU block that gets stuck.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index d0f56c5c4cce..fb34067ab6af 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -489,7 +489,7 @@ static int dpu_encoder_phys_vid_wait_for_commit_done(
(hw_ctl->ops.get_flush_register(hw_ctl) == 0),
msecs_to_jiffies(50));
if (ret <= 0) {
-   DPU_ERROR("vblank timeout\n");
+   DPU_ERROR("vblank timeout: %x\n", 
hw_ctl->ops.get_flush_register(hw_ctl));
return -ETIMEDOUT;
}
 

---
base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
change-id: 20240106-fd-dpu-debug-timeout-e917f0bc8063

Best regards,
-- 
Dmitry Baryshkov 



[PATCH v3 4/4] drm/msm/dpu: add support for SDM660 and SDM630 platforms

2024-01-05 Thread Dmitry Baryshkov
Bring in hardware support for the SDM660 and SDM630 platforms, which
belong to the same DPU generation as MSM8998.

Note, by default these platforms are still handled by the MDP5 driver
unless the `msm.prefer_mdp5=false' parameter is provided.

Co-developed-by: Konrad Dybcio 
Signed-off-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_3_2_sdm660.h | 291 +
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_3_3_sdm630.h | 225 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|   2 +
 drivers/gpu/drm/msm/msm_drv.c  |   2 +
 6 files changed, 524 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_2_sdm660.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_2_sdm660.h
new file mode 100644
index ..424815e7fb7d
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_2_sdm660.h
@@ -0,0 +1,291 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023. Linaro Inc. All rights reserved.
+ */
+
+#ifndef _DPU_3_2_SDM660_H
+#define _DPU_3_2_SDM660_H
+
+static const struct dpu_caps sdm660_dpu_caps = {
+   .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+   .max_mixer_blendstages = 0x7,
+   .has_src_split = true,
+   .has_dim_layer = true,
+   .has_idle_pc = true,
+   .has_3d_merge = true,
+   .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .max_hdeci_exp = MAX_HORZ_DECIMATION,
+   .max_vdeci_exp = MAX_VERT_DECIMATION,
+};
+
+static const struct dpu_mdp_cfg sdm660_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 },
+   [DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .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_CURSOR0] = { .reg_off = 0x3a8, .bit_off = 16 },
+   },
+};
+
+static const struct dpu_ctl_cfg sdm660_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),
+   },
+};
+
+static const struct dpu_sspp_cfg sdm660_sspp[] = {
+   {
+   .name = "sspp_0", .id = SSPP_VIG0,
+   .base = 0x4000, .len = 0x1ac,
+   .features = VIG_MSM8998_MASK,
+   .sblk = _vig_sblk_qseed3_1_2,
+   .xin_id = 0,
+   .type = SSPP_TYPE_VIG,
+   .clk_ctrl = DPU_CLK_CTRL_VIG0,
+   }, {
+   .name = "sspp_1", .id = SSPP_VIG1,
+   .base = 0x6000, .len = 0x1ac,
+   .features = VIG_MSM8998_MASK,
+   .sblk = _vig_sblk_qseed3_1_2,
+   .xin_id = 4,
+   .type = SSPP_TYPE_VIG,
+   .clk_ctrl = DPU_CLK_CTRL_VIG1,
+   }, {
+   .name = "sspp_8", .id = SSPP_DMA0,
+   .base = 0x24000, .len = 0x1ac,
+   .features = DMA_MSM8998_MASK,
+   .sblk = _dma_sblk,
+   .xin_id = 1,
+   .type = SSPP_TYPE_DMA,
+   .clk_ctrl = DPU_CLK_CTRL_DMA0,
+   }, {
+   .name = "sspp_9", .id = SSPP_DMA1,
+   .base = 0x26000, .len = 0x1ac,
+   .features = DMA_MSM8998_MASK,
+   .sblk = _dma_sblk,
+   .xin_id = 5,
+   .type = SSPP_TYPE_DMA,
+   .clk_ctrl = DPU_CLK_CTRL_DMA1,
+   }, {
+   .name = "sspp_10", .id = SSPP_DMA2,
+   .base = 0x28000, .len = 0x1ac,
+   .features = DMA_CURSOR_MSM8998_MASK,
+   .sblk = _dma_sblk,
+   .xin_id = 9,
+   .type = SSPP_TYPE_DMA,
+   .clk_ctrl = DPU_CLK_CTRL_DMA2,
+   },
+};
+

[PATCH v3 3/4] drm/msm: add a kernel param to select between MDP5 and DPU drivers

2024-01-05 Thread Dmitry Baryshkov
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.

All platforms supported by both drivers are by default handled by the
MDP5 driver. To let them be handled by the DPU driver pass the
`msm.prefer_mdp5=false` kernel param.

Reviewed-by: Stephen Boyd 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  3 +++
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  3 +++
 drivers/gpu/drm/msm/msm_drv.c| 31 +++
 drivers/gpu/drm/msm/msm_drv.h|  1 +
 4 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index aa9e0ad33ebb..8f11a98491a1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1276,6 +1276,9 @@ static int dpu_dev_probe(struct platform_device *pdev)
int irq;
int ret = 0;
 
+   if (!msm_disp_drv_should_bind(>dev, true))
+   return -ENODEV;
+
dpu_kms = devm_kzalloc(dev, sizeof(*dpu_kms), GFP_KERNEL);
if (!dpu_kms)
return -ENOMEM;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 0827634664ae..43d05851c54d 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -866,6 +866,9 @@ static int mdp5_dev_probe(struct platform_device *pdev)
 
DBG("");
 
+   if (!msm_disp_drv_should_bind(>dev, false))
+   return -ENODEV;
+
mdp5_kms = devm_kzalloc(>dev, sizeof(*mdp5_kms), GFP_KERNEL);
if (!mdp5_kms)
return -ENOMEM;
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 50b65ffc24b1..ef57586fbeca 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -969,6 +969,37 @@ static int add_components_mdp(struct device *master_dev,
return 0;
 }
 
+#if !IS_REACHABLE(CONFIG_DRM_MSM_MDP5) || !IS_REACHABLE(CONFIG_DRM_MSM_DPU)
+bool msm_disp_drv_should_bind(struct device *dev, bool mdp5_driver)
+{
+   /* If just a single driver is enabled, use it no matter what */
+   return true;
+}
+#else
+
+static bool prefer_mdp5 = true;
+MODULE_PARM_DESC(prefer_mdp5, "Select whether MDP5 or DPU driver should be 
preferred");
+module_param(prefer_mdp5, bool, 0444);
+
+/* list all platforms supported by both mdp5 and dpu drivers */
+static const char *const msm_mdp5_dpu_migration[] = {
+   NULL,
+};
+
+bool msm_disp_drv_should_bind(struct device *dev, bool dpu_driver)
+{
+   /* If it is not an MDP5 device, do not try MDP5 driver */
+   if (!of_device_is_compatible(dev->of_node, "qcom,mdp5"))
+   return dpu_driver;
+
+   /* If it is not in the migration list, use MDP5 */
+   if (!of_device_compatible_match(dev->of_node, msm_mdp5_dpu_migration))
+   return !dpu_driver;
+
+   return prefer_mdp5 ? !dpu_driver : dpu_driver;
+}
+#endif
+
 /*
  * We don't know what's the best binding to link the gpu with the drm device.
  * Fow now, we just hunt for all the possible gpus that we support, and add 
them
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 01e783130054..762e13e2df74 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -563,5 +563,6 @@ int msm_drv_probe(struct device *dev,
struct msm_kms *kms);
 void msm_kms_shutdown(struct platform_device *pdev);
 
+bool msm_disp_drv_should_bind(struct device *dev, bool dpu_driver);
 
 #endif /* __MSM_DRV_H__ */

-- 
2.39.2



[PATCH v3 2/4] drm/msm/dpu: support binding to the mdp5 devices

2024-01-05 Thread Dmitry Baryshkov
Existing MDP5 devices have slightly different bindings. The main
register region is called `mdp_phys' instead of `mdp'. Also vbif
register regions are a part of the parent, MDSS device. Add support for
handling this binding differences.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 98 ++---
 drivers/gpu/drm/msm/msm_drv.h   |  3 +
 drivers/gpu/drm/msm/msm_io_utils.c  | 13 +
 3 files changed, 93 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 723cc1d82143..aa9e0ad33ebb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1197,6 +1197,78 @@ static int dpu_kms_init(struct drm_device *ddev)
return 0;
 }
 
+static int dpu_kms_mmap_mdp5(struct dpu_kms *dpu_kms)
+{
+   struct platform_device *pdev = dpu_kms->pdev;
+   struct platform_device *mdss_dev;
+   int ret;
+
+   if (dpu_kms->pdev->dev.bus != _bus_type)
+   return -EINVAL;
+
+   mdss_dev = to_platform_device(dpu_kms->pdev->dev.parent);
+
+   dpu_kms->mmio = msm_ioremap(pdev, "mdp_phys");
+   if (IS_ERR(dpu_kms->mmio)) {
+   ret = PTR_ERR(dpu_kms->mmio);
+   DPU_ERROR("mdp register memory map failed: %d\n", ret);
+   dpu_kms->mmio = NULL;
+   return ret;
+   }
+   DRM_DEBUG("mapped dpu address space @%pK\n", dpu_kms->mmio);
+
+   dpu_kms->vbif[VBIF_RT] = msm_ioremap_mdss(mdss_dev,
+ dpu_kms->pdev,
+ "vbif_phys");
+   if (IS_ERR(dpu_kms->vbif[VBIF_RT])) {
+   ret = PTR_ERR(dpu_kms->vbif[VBIF_RT]);
+   DPU_ERROR("vbif register memory map failed: %d\n", ret);
+   dpu_kms->vbif[VBIF_RT] = NULL;
+   return ret;
+   }
+
+   dpu_kms->vbif[VBIF_NRT] = msm_ioremap_mdss(mdss_dev,
+  dpu_kms->pdev,
+  "vbif_nrt_phys");
+   if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) {
+   dpu_kms->vbif[VBIF_NRT] = NULL;
+   DPU_DEBUG("VBIF NRT is not defined");
+   }
+
+   return 0;
+}
+
+static int dpu_kms_mmap_dpu(struct dpu_kms *dpu_kms)
+{
+   struct platform_device *pdev = dpu_kms->pdev;
+   int ret;
+
+   dpu_kms->mmio = msm_ioremap(pdev, "mdp");
+   if (IS_ERR(dpu_kms->mmio)) {
+   ret = PTR_ERR(dpu_kms->mmio);
+   DPU_ERROR("mdp register memory map failed: %d\n", ret);
+   dpu_kms->mmio = NULL;
+   return ret;
+   }
+   DRM_DEBUG("mapped dpu address space @%pK\n", dpu_kms->mmio);
+
+   dpu_kms->vbif[VBIF_RT] = msm_ioremap(pdev, "vbif");
+   if (IS_ERR(dpu_kms->vbif[VBIF_RT])) {
+   ret = PTR_ERR(dpu_kms->vbif[VBIF_RT]);
+   DPU_ERROR("vbif register memory map failed: %d\n", ret);
+   dpu_kms->vbif[VBIF_RT] = NULL;
+   return ret;
+   }
+
+   dpu_kms->vbif[VBIF_NRT] = msm_ioremap_quiet(pdev, "vbif_nrt");
+   if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) {
+   dpu_kms->vbif[VBIF_NRT] = NULL;
+   DPU_DEBUG("VBIF NRT is not defined");
+   }
+
+   return 0;
+}
+
 static int dpu_dev_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1230,28 +1302,12 @@ static int dpu_dev_probe(struct platform_device *pdev)
 
dpu_kms->base.irq = irq;
 
-   dpu_kms->mmio = msm_ioremap(pdev, "mdp");
-   if (IS_ERR(dpu_kms->mmio)) {
-   ret = PTR_ERR(dpu_kms->mmio);
-   DPU_ERROR("mdp register memory map failed: %d\n", ret);
-   dpu_kms->mmio = NULL;
-   return ret;
-   }
-   DRM_DEBUG("mapped dpu address space @%pK\n", dpu_kms->mmio);
-
-   dpu_kms->vbif[VBIF_RT] = msm_ioremap(pdev, "vbif");
-   if (IS_ERR(dpu_kms->vbif[VBIF_RT])) {
-   ret = PTR_ERR(dpu_kms->vbif[VBIF_RT]);
-   DPU_ERROR("vbif register memory map failed: %d\n", ret);
-   dpu_kms->vbif[VBIF_RT] = NULL;
+   if (of_device_is_compatible(dpu_kms->pdev->dev.of_node, "qcom,mdp5"))
+   ret = dpu_kms_mmap_mdp5(dpu_kms);
+   else
+   ret = dpu_kms_mmap_dpu(dpu_kms);
+   if (ret)
return ret;
-   }
-
-   dpu_kms->vbif[VBIF_NRT] = msm_ioremap_quiet(pdev, "vbif_nrt");
-   if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) {
-   dpu_kms->vbif[VBIF_NRT] = NULL;
-   DPU_DEBUG("VBIF NRT is not defined");
-   }
 
ret = dpu_kms_parse_data_bus_icc_path(dpu_kms);
if (ret)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 16a7cbc0b7dd..01e783130054 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -476,6 +476,9 

[PATCH v3 1/4] drm/msm/mdss: generate MDSS data for MDP5 platforms

2024-01-05 Thread Dmitry Baryshkov
Older (mdp5) platforms do not use per-SoC compatible strings. Instead
they use a single compat entry 'qcom,mdss'. To facilitate migrating
these platforms to the DPU driver provide a way to generate the MDSS /
UBWC data at runtime, when the DPU driver asks for it.

It is not possible to generate this data structure at the probe time,
since some platforms might not have MDP_CLK enabled, which makes reading
HW_REV register return 0.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/msm_mdss.c | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 455b2e3a0cdd..566a5dd5b8e8 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2018, The Linux Foundation
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -213,6 +214,49 @@ static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss 
*msm_mdss)
}
 }
 
+#define MDSS_HW_MAJ_MINGENMASK(31, 16)
+
+#define MDSS_HW_MSM89960x1007
+#define MDSS_HW_MSM89370x100e
+#define MDSS_HW_MSM89560x1010
+#define MDSS_HW_MSM89980x3000
+#define MDSS_HW_SDM660 0x3002
+#define MDSS_HW_SDM630 0x3003
+
+/*
+ * MDP5 platforms use generic qcom,mdp5 compat string, so we have to generate 
this data
+ */
+static const struct msm_mdss_data *msm_mdss_generate_mdp5_mdss_data(struct 
msm_mdss *mdss)
+{
+   struct msm_mdss_data *data;
+   u32 hw_rev;
+
+   data = devm_kzalloc(mdss->dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return NULL;
+
+   hw_rev = readl_relaxed(mdss->mmio + HW_REV);
+   hw_rev = FIELD_GET(MDSS_HW_MAJ_MIN, hw_rev);
+
+   if (hw_rev == MDSS_HW_MSM8996 ||
+   hw_rev == MDSS_HW_MSM8937 ||
+   hw_rev == MDSS_HW_MSM8956 ||
+   hw_rev == MDSS_HW_MSM8998 ||
+   hw_rev == MDSS_HW_SDM660 ||
+   hw_rev == MDSS_HW_SDM630) {
+   data->ubwc_dec_version = UBWC_1_0;
+   data->ubwc_enc_version = UBWC_1_0;
+   }
+
+   if (hw_rev == MDSS_HW_MSM8996 ||
+   hw_rev == MDSS_HW_MSM8998)
+   data->highest_bank_bit = 2;
+   else
+   data->highest_bank_bit = 1;
+
+   return data;
+}
+
 const struct msm_mdss_data *msm_mdss_get_mdss_data(struct device *dev)
 {
struct msm_mdss *mdss;
@@ -222,6 +266,13 @@ const struct msm_mdss_data *msm_mdss_get_mdss_data(struct 
device *dev)
 
mdss = dev_get_drvdata(dev);
 
+   /*
+* We could not do it at the probe time, since hw revision register was
+* not readable. Fill data structure now for the MDP5 platforms.
+*/
+   if (!mdss->mdss_data && mdss->is_mdp5)
+   mdss->mdss_data = msm_mdss_generate_mdp5_mdss_data(mdss);
+
return mdss->mdss_data;
 }
 

-- 
2.39.2



[PATCH v3 0/4] drm/msm: provide migration path from MDP5 to DPU driver

2024-01-05 Thread Dmitry Baryshkov
Over the last several years the DPU driver has been actively developed,
while the MDP5 is mostly in the maintenance mode. This results in some
features being available only in the DPU driver. For example, bandwidth
scaling, writeback support, properly supported bonded DSI aka dual DSI
support, DSC (display stream compression).

All the pre-SDM845 platforms were originally supported by the MDP5
driver only. However it is possible and easy to support some of the
older SoCs in the DPU driver. For example in the v5.18 it got
support for MSM8998.  This can not be considered as a proper migration,
since there msm8998.dtsi didn't describe the display hardware
beforehand. Instead new bindings were added, making MSM8998 just another
display hardware to be supported by the DPU driver.

This series provides a way to gradually migrate support for several
existing and well-supported SoCs from the MDP5 to the DPU driver without
changing the DT. From the user experience point of view this is
facilitated by the `msm.prefer_mdp5' kernel param. If the parameter is
set to `true' (current default), all `shared' platforms will be handled
by the MDP5 driver. If the switch is flipped to `false' (or if the MDP5
driver is disabled), these platforms will be handled by the DPU driver.
Handling this by the modparam (rather than solely by kernel config)
allows one to easly switch between the drivers, simplifying testing.

This series implements support for two DPU 3.n platforms, SDM660 and
SDM630. The MSM8996 support was a part of the previous iterations of
this patchset, but it was removed in v3. It requires additional
development and testing.

In theory after additional testing we can drop most of migration code
and some parts of MDP5 driver. The proposed boundary is to move all
platforms supporting cursor planes to the DPU driver, while limiting
MDP5 to support only the older platforms which implement cursor as a
part of the LM hardware block (MSM8974, APQ8084, MSM8x26, MSM8x16 and
MSM8x39).

Changes since v2:
- Rebased on top of linux-next
- After additional consideration dropped MSM8996 patch. It will be
  reiterated later, once the generic migration framework is accepted
  (and after we implement scalers support for that platform).

Changes since v1:
- Dropped accepted patches
- Rebased on top of updated [1]
- Added defines for MDSS hw revisions (Stephen)
- Changed msm_mdss_generate_mdp5_mdss_data() to return const struct
  pointer (Stephen)
- Fixed error handling in msm_ioremap_mdss() (Stephen)

[1] https://patchwork.freedesktop.org/series/119804/

---
Dmitry Baryshkov (4):
  drm/msm/mdss: generate MDSS data for MDP5 platforms
  drm/msm/dpu: support binding to the mdp5 devices
  drm/msm: add a kernel param to select between MDP5 and DPU drivers
  drm/msm/dpu: add support for SDM660 and SDM630 platforms

 .../gpu/drm/msm/disp/dpu1/catalog/dpu_3_2_sdm660.h | 291 +
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_3_3_sdm630.h | 225 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 103 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c   |   3 +
 drivers/gpu/drm/msm/msm_drv.c  |  33 +++
 drivers/gpu/drm/msm/msm_drv.h  |   4 +
 drivers/gpu/drm/msm/msm_io_utils.c |  13 +
 drivers/gpu/drm/msm/msm_mdss.c |  51 
 10 files changed, 706 insertions(+), 21 deletions(-)
---
base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
change-id: 20240105-fd-migrate-mdp5-6a2aa51bc83b

Best regards,
-- 
Dmitry Baryshkov 



Re: [PATCH 3/3] ASoC: hdmi-codec: drop drm/drm_edid.h include

2024-01-05 Thread Alex Deucher
On Thu, Jan 4, 2024 at 3:17 PM Jani Nikula  wrote:
>
> hdmi-codec.h does not appear to directly need drm/drm_edid.h for
> anything. Remove it.
>
> There are some files that get drm/drm_edid.h by proxy; include it where
> needed.
>
> v2-v4: Fix build (kernel test robot )
>
> Cc: Rob Clark 
> Cc: Abhinav Kumar 
> Cc: Dmitry Baryshkov 
> Cc: Sean Paul 
> Cc: Marijn Suijten 
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: linux-so...@vger.kernel.org
> Acked-by: Maxime Ripard 
> Signed-off-by: Jani Nikula 

Series is:
Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/bridge/lontium-lt9611.c| 1 +
>  drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 +
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  | 1 +
>  drivers/gpu/drm/msm/dp/dp_display.c| 1 +
>  drivers/gpu/drm/tegra/hdmi.c   | 1 +
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 1 +
>  include/sound/hdmi-codec.h | 1 -
>  7 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c 
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> index 9663601ce098..b9205d14d943 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -18,6 +18,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c 
> b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> index e971b75e90ad..f3f130c1ef0a 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> @@ -21,6 +21,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 52d91a0df85e..fa63a21bdd1c 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index d37d599aec27..c8e1bbebdffe 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "msm_drv.h"
>  #include "msm_kms.h"
> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> index 417fb884240a..09987e372e3e 100644
> --- a/drivers/gpu/drm/tegra/hdmi.c
> +++ b/drivers/gpu/drm/tegra/hdmi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index f05e2c95a60d..34f807ed1c31 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
> index 9b162ac1e08e..5e1a9eafd10f 100644
> --- a/include/sound/hdmi-codec.h
> +++ b/include/sound/hdmi-codec.h
> @@ -12,7 +12,6 @@
>
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 2.39.2
>


Re: [PATCH 3/3] ASoC: hdmi-codec: drop drm/drm_edid.h include

2024-01-05 Thread Andi Shyti
Hi Jani,

On Thu, Jan 04, 2024 at 10:16:32PM +0200, Jani Nikula wrote:
> hdmi-codec.h does not appear to directly need drm/drm_edid.h for
> anything. Remove it.
> 
> There are some files that get drm/drm_edid.h by proxy; include it where
> needed.
> 
> v2-v4: Fix build (kernel test robot )
> 
> Cc: Rob Clark 
> Cc: Abhinav Kumar 
> Cc: Dmitry Baryshkov 
> Cc: Sean Paul 
> Cc: Marijn Suijten 
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: linux-so...@vger.kernel.org
> Acked-by: Maxime Ripard 
> Signed-off-by: Jani Nikula 

Reviewed-by: Andi Shyti 

Andi