linux-kernel - Re: [RFC 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic integer divider

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]

Message-ID: <Zs7kJ6vCDbxVvxU1@atmark-techno.com>
Date: Wed, 28 Aug 2024 17:47:35 +0900
From: Dominique Martinet <dominique.martinet@...ark-techno.com>
To: Adam Ford <aford173@...il.com>
Cc: linux-phy@...ts.infradead.org, linux-imx@....com, festevam@...il.com,
	frieder.schrempf@...tron.de, aford@...conembedded.com,
	Vinod Koul <vkoul@...nel.org>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
	Marco Felsch <m.felsch@...gutronix.de>,
	Lucas Stach <l.stach@...gutronix.de>, linux-kernel@...r.kernel.org,
	Makoto Sato <makoto.sato@...ark-techno.com>
Subject: Re: [RFC 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider

Adam Ford wrote on Tue, Aug 27, 2024 at 09:48:02PM -0500:
> There is currently a look-up table for a variety of resolutions.
> Since the phy has the ability to dynamically calculate the values
> necessary to use the intger divider which should allow more
> resolutions without having to update the look-up-table.  If the
> integer calculator cannot get an exact frequency, it falls back
> to the look-up-table.  Because the LUT algorithm does some
> rounding, I did not remove integer entries from the LUT.

Thank you!

We're still running 5.10 so I backported the driver as of it's current
state first (that part works), unfortunately our 51.2MHz display does
not work with this.

After phy_clk_round_rate() not round the pixel clock to the table values
(otherwise we'd only get rounded values), and making phy_clk_set_rate()
pass the requested `rate` instead of using the next smaller cfg->pixclk,
the display no longer comes up.

It comes up with the values obtained for 50.4MHz (next closest value),
which also has an exact match so uses the integer divider this patch
computes instead of the table values, but not with the 51.2MHz it
requests...
I'm afraid at this point I don't know how to debug that further without
getting a scope out (I don't know if the soc isn't generating something
correct or if the display actually doesn't like the frequency it
requests?! the later could be checked by plugging it in to another PC
that might support that frequency...), and that is going to take quite a
while...

Hopefully Frieder will have more success with his displays?
It could also be very well due to some of the differences with our 5.10
tree, sorry about that.

>  static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
>  					  const struct phy_config *cfg)
>  {
> +	u32 desired_clock = cfg->pixclk * 5;

(I don't really understand where that `* 5` comes from, but I guess it's
expected? works for other display and neighbor frequency anyway...)

Thanks,
-- 
Dominique