Re: [PATCH RFC/DO NOT MERGE 07/12] drm/msm/hdmi: Split PHY init from power up

From: Krzysztof Kozlowski <krzk@kernel.org>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>,
	Rob Clark <robin.clark@oss.qualcomm.com>,
	Dmitry Baryshkov <lumag@kernel.org>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Jessica Zhang <jesszhan0024@gmail.com>,
	Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Vinod Koul <vkoul@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, linux-phy@lists.infradead.org
Subject: Re: [PATCH RFC/DO NOT MERGE 07/12] drm/msm/hdmi: Split PHY init from power up
Date: Tue, 1 Sep 2026 07:57:38 +0200	[thread overview]
Message-ID: <ad7883c2-3b0d-43d0-b057-8a8eaf34a6c9@kernel.org> (raw)
In-Reply-To: <c1d13f41-e29e-41ee-b02a-b38013e4e7f2@oss.qualcomm.com>

On 31/08/2026 18:40, Konrad Dybcio wrote:
> On 8/28/26 4:05 PM, Krzysztof Kozlowski wrote:
>> Future Eliza SoC HDMI PHY and HDMI block require certain clock
>> operations, like reparenting pixclok to HDMI PHY PLL, once PHY is
>> initialized.  Similarly to what is happening on Qualcomm MSM DSI blocks
>> since SM8750.
> 
> [...]
> 
>>  static void msm_hdmi_power_on(struct drm_bridge *bridge)
>> +{
>> +	struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
>> +	struct hdmi *hdmi = hdmi_bridge->hdmi;
>> +
>> +	pm_runtime_resume_and_get(&hdmi->pdev->dev);
>> +}
> 
> I know the caller is void and it's existing behavior, but we
> should definitely not continue if this fails

Yeah, I can rework that.

Best regards,
Krzysztof