Re: [PATCH v1 16/17] drm/mediatek: dpi: Add mt8195 hdmi to DPI driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Il 27/09/22 15:34, Guillaume Ranquet ha scritto:
On Tue, 20 Sep 2022 14:22, AngeloGioacchino Del Regno
<angelogioacchino.delregno@xxxxxxxxxxxxx> wrote:
Il 19/09/22 18:56, Guillaume Ranquet ha scritto:
Add the DPI1 hdmi path support in mtk dpi driver

Signed-off-by: Guillaume Ranquet <granquet@xxxxxxxxxxxx>

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 630a4e301ef6..91212b7610e8 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -15,7 +15,10 @@
   #include <linux/of_graph.h>
   #include <linux/pinctrl/consumer.h>
   #include <linux/platform_device.h>
+#include <linux/reset.h>
   #include <linux/types.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>

   #include <video/videomode.h>

@@ -66,10 +69,14 @@ struct mtk_dpi {
   	struct drm_bridge *next_bridge;
   	struct drm_connector *connector;
   	void __iomem *regs;
+	struct reset_control *reset_ctl;
   	struct device *dev;
   	struct clk *engine_clk;
+	struct clk *dpi_ck_cg;
   	struct clk *pixel_clk;
+	struct clk *dpi_sel_clk;
   	struct clk *tvd_clk;
+	struct clk *hdmi_cg;


You're adding new clocks and then you're making *all clocks*, including the
already existing ones... optional.

That looks seriously odd.... can you please give a devicetree example for
MT8195 in the next version, perhaps in the cover letter?

Would also make it easier to test this entire big series.

Regards,
Angelo


The clock names are different for MT8195 HDMI than for the legacy DP.
Making everything optional might not have been a smart move.
I'll try to think of something else to make it look less odd.

The device tree I'm using to test things is rather "hackish" and has a bunch of
changes from what is found on linux-next.
I think Jason and Nancy are due to upstream those patches.

I'll try to include something minimal for you to test.
Otherwise would a public branch containing everything work for you?


Any reference would work for me, "something minimal" or a public branch, it
doesn't really matter.

Thanks!
Angelo





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux