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] [day] [month] [year] [list]

Message-ID: <CAHCN7xJtw2JakEtvD31dCKvpanzu6Pxbc0S81rDurYbVp5g_aA@mail.gmail.com>
Date: Wed, 28 Aug 2024 14:28:00 -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 9:11 AM Adam Ford <aford173@...il.com> wrote:
>
> 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.

It looks like I need to update phy_clk_round_rate to calculate the
integer clock value there as well and if it's not possible to reach
the desired value, fall back to the LUT.

I likely won't get that done today, but I'll try.

adam
>
> 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
> >
> >