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

[Adam Ford]

On Wed, Aug 28, 2024 at 9:11 AM Adam Ford <aford173 at gmail.com> wrote:
>
> 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.

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