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

[Adam Ford]

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