linux-kernel - Re: [PATCH 1/3] dt-bindings: soc: imx: add fdcc clock to i.MX8MP hdmi blk ctrl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 7 Jan 2024 10:15:05 -0600
From: Adam Ford <aford173@...il.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: linux-pm@...r.kernel.org, Rob Herring <robh+dt@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, 
	Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>, 
	NXP Linux Team <linux-imx@....com>, Ulf Hansson <ulf.hansson@...aro.org>, 
	Lucas Stach <l.stach@...gutronix.de>, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: soc: imx: add fdcc clock to i.MX8MP hdmi
 blk ctrl

On Sun, Jan 7, 2024 at 4:53 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 06/01/2024 23:39, Adam Ford wrote:
> > Per guidance from the NXP downstream kernel, if the clock is
> > disabled before HDMI/LCDIF probe, LCDIF will not get pixel
> > clock from HDMI PHY and throw an error.  Fix this by adding
> > the fdcc clock to the hdmi_blk_ctrl.
> >
>
> Adding a required clock is ABI break and commit msg is not clear whether
> this was actually necessary or how did it worked so far...

As of right now, this power domain isn't enabled in the device tree.
This power domain is necessary for the HDMI driver which is split
across several drivers which Lucas attempted to push but got some
feedback.  One of those items in question is the enabling of FDCC
during the HDMI Tx probe.  The NXP documentation is vague on what this
clock is and who uses it.  When I did my investigation into how NXP
used it, it turned out they didn't use it in the HDMI TX driver,
because they moved it to the power domain and referenced it from both
the LCDIF and the HDMI TX.  NXP's downstream commit didn't get into a
lot of detail on how to reproduce the error, but it sounded like some
sort of order of operations issue between the LCDIF and HDMI TX.
Moving this to the power domain appeared to solve the issue for them,
and it seemed like it would have also resolved the concern about its
use in the HDMI TX driver that was submitted on the mailing list.  In
the subsequent patch, I listed the error that NXP described, but I can
re-do this commit message to make it more clear if you let me know
what you're wanting to see.

adam
>
> Best regards,
> Krzysztof
>