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: <CAHCN7xLX1FPQFFBsgfd4Msa+y=KNay9M9q1fu=P1uuKZLacS4g@mail.gmail.com>
Date: Wed, 28 Aug 2024 09:11:16 -0500
From: Adam Ford <aford173@...il.com>
To: Dominique Martinet <dominique.martinet@...ark-techno.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

On Wed, Aug 28, 2024 at 3:47 AM Dominique Martinet
<dominique.martinet@...ark-techno.com> wrote:
>
> 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.

Do you want me to create a table entry for 51.2MHz?  I am pretty sure
the integer engine can handle it.  I'll investigate what's calling
phy_clk_round_rate to see if we can use the PMS calcualtor to avoid
the look-up table.


>
> 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...)

When I looked at the LUT entries for the clock rates that don't need
the fractional divider, I noted the clock rate was 5x the pix clock.
This was consistent for each entry.  Even when the fractional divider
was used, it appeared that the clock rate was 5x the pix clk.  Because
the PMS calculator I wrote is expecting a clock rate, I just
multiplied by 5 here instead of inside the PMS calculator.

adam
>
> Thanks,
> --
> Dominique
>
>