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: <CAHCN7xKsH4Rau23t_pmsjTsNS7Hz32Xb+GBydjLFDpgtni7w2A@mail.gmail.com>
Date: Fri, 30 Aug 2024 08:05:37 -0500
From: Adam Ford <aford173@...il.com>
To: Vinod Koul <vkoul@...nel.org>
Cc: linux-phy@...ts.infradead.org, dominique.martinet@...ark-techno.com, 
	linux-imx@....com, festevam@...il.com, frieder.schrempf@...tron.de, 
	aford@...conembedded.com, Kishon Vijay Abraham I <kishon@...nel.org>, 
	Lucas Stach <l.stach@...gutronix.de>, Marco Felsch <m.felsch@...gutronix.de>, 
	Uwe Kleine-König <u.kleine-koenig@...gutronix.de>, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC V2 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider

On Fri, Aug 30, 2024 at 2:55 AM Vinod Koul <vkoul@...nel.org> wrote:
>
> On 29-08-24, 13:30, Adam Ford wrote:
> > On Thu, Aug 29, 2024 at 12:56 PM Vinod Koul <vkoul@...nel.org> wrote:
> > >
> > > On 28-08-24, 21:12, Adam Ford wrote:
> > > > 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.
> > >
> > > Any reason why this is RFC?
> >
> > Someone was asking for functionality, but I'm not 100% sure this is
> > the right approach or it would even work.  I am waiting for feedback
> > from Dominique to determine if this helps solve the display for that
> > particular display.
> >
> > >
> > > >
> > > > Signed-off-by: Adam Ford <aford173@...il.com>
> > > >
> > > > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > > index bc5d3625ece6..76e0899c6006 100644
> > > > --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > > @@ -16,6 +16,8 @@
> > > >
> > > >  #define PHY_REG(reg)         (reg * 4)
> > > >
> > > > +#define REG01_PMS_P_MASK     GENMASK(3, 0)
> > > > +#define REG03_PMS_S_MASK     GENMASK(7, 4)
> > > >  #define REG12_CK_DIV_MASK    GENMASK(5, 4)
> > > >  #define REG13_TG_CODE_LOW_MASK       GENMASK(7, 0)
> > > >  #define REG14_TOL_MASK               GENMASK(7, 4)
> > > > @@ -31,11 +33,17 @@
> > > >
> > > >  #define PHY_PLL_DIV_REGS_NUM 6
> > > >
> > > > +#ifndef MHZ
> > > > +#define MHZ  (1000UL * 1000UL)
> > > > +#endif
> > > > +
> > > >  struct phy_config {
> > > >       u32     pixclk;
> > > >       u8      pll_div_regs[PHY_PLL_DIV_REGS_NUM];
> > > >  };
> > > >
> > > > +static struct phy_config custom_phy_pll_cfg;
> > > > +
> > > >  static const struct phy_config phy_pll_cfg[] = {
> > > >       {
> > > >               .pixclk = 22250000,
> > > > @@ -440,10 +448,83 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
> > > >              phy->regs + PHY_REG(14));
> > > >  }
> > > >
> > > > +static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
> > > > +{
> > > > +     unsigned long best_freq = 0;
> > > > +     u32 min_delta = 0xffffffff;
> > >
> > > > +     u8 _p, best_p;
> > > > +     u16 _m, best_m;
> > > > +     u8 _s, best_s;
> > > > +
> > > > +     for (_p = 1; _p <= 11; ++_p) {
> > >
> > > starts with 1 to 11.. why?
> >
> > According to Rev 2 of the 8MP Reference Manual, the Previder range is
> > between 1 and 11.
>
> Would be better to document these assumptions, am sure if someone asks
> you this next year, it would be hard to recall :-)

I updated the note n V3.

Dominique confirmed V3 appears to be working, so I'll investigate his
suggestions, and submit a patch based on my V3 without the RFC.

adam
>
> --
> ~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ