Re: [PATCH v7 10/24] drm/rockchip: dw_hdmi: Add support for hclk

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

 



On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
25.02.2022 10:51, Sascha Hauer пишет:
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.

Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
---

Notes:
     Changes since v5:
     - Use devm_clk_get_optional rather than devm_clk_get

  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 ++++++++++++++++
  1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index fe4f9556239ac..c6c00e8779ab5 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -76,6 +76,7 @@ struct rockchip_hdmi {
  	const struct rockchip_hdmi_chip_data *chip_data;
  	struct clk *ref_clk;
  	struct clk *grf_clk;
+	struct clk *hclk_clk;
  	struct dw_hdmi *hdmi;
  	struct regulator *avdd_0v9;
  	struct regulator *avdd_1v8;
@@ -229,6 +230,14 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
  		return PTR_ERR(hdmi->grf_clk);
  	}
+ hdmi->hclk_clk = devm_clk_get_optional(hdmi->dev, "hclk");
+	if (PTR_ERR(hdmi->hclk_clk) == -EPROBE_DEFER) {

Have you tried to investigate the hclk? I'm still thinking that's not
only HDMI that needs this clock and then the hardware description
doesn't look correct.

I am still not sure what you mean. Yes, it's not only the HDMI that
needs this clock. The VOP2 needs it as well and the driver handles that.

I'm curious whether DSI/DP also need that clock to be enabled. If they
do, then you aren't modeling h/w properly AFAICS.

Assuming nobody at Rockchip decided to make things needlessly inconsistent with previous SoCs, HCLK_VOP should be the clock for the VOP's AHB slave interface. Usually, if that affected anything other than accessing VOP registers, indeed it would smell of something being wrong in the clock tree, but in this case I'd also be suspicious of whether it might have ended up clocking related GRF registers as well (either directly, or indirectly via some gate that the clock driver hasn't modelled yet).

If the symptom of not claiming HCLK_VOP is hanging on some register access in the HDMI driver while the VOP is idle, then it should be relatively straightforward to narrow down with some logging, and see if it looks like this is really just another "grf" clock. If not, then we're back to suspecting something more insidiously wrong elsewhere.

Robin.



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux