[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YTeqEilet1p4vTAU@smile.fi.intel.com>
Date: Tue, 7 Sep 2021 21:06:10 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Chris Morgan <macroalpha82@...il.com>
Cc: abel.vesa@....com, festevam@...il.com, heiko@...ech.de,
kernel@...gutronix.de, lee.jones@...aro.org, lenb@...nel.org,
linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-clk@...r.kernel.org, linux-imx@....com,
linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
mturquette@...libre.com, rafael.j.wysocki@...el.com,
rjw@...ysocki.net, s.hauer@...gutronix.de, sboyd@...nel.org,
shawnguo@...nel.org, zhangqing@...k-chips.com,
Chris Morgan <macromorgan@...mail.com>
Subject: Re: [PATCH v4 1/4] clk: fractional-divider: Export approximation
algorithm to the CCF users
On Tue, Sep 07, 2021 at 08:54:04PM +0300, Andy Shevchenko wrote:
> On Tue, Sep 07, 2021 at 10:44:00AM -0500, Chris Morgan wrote:
> > From: Chris Morgan <macromorgan@...mail.com>
> >
> > Unfortunately, I can confirm this breaks the DSI panel on the Rockchip
> > PX30 (and possibly other SoCs). Tested on my Odroid Go Advance. When
> > I revert 4e7cf74fa3b2 "clk: fractional-divider: Export approximation
> > algorithm to the CCF users" and 928f9e268611 "clk: fractional-divider:
> > Hide clk_fractional_divider_ops from wide audience" the panel begins
> > working again as expected on the master branch.
> >
> > It looks like an assumption is made in the vop_crtc_mode_fixup()
> > function in the rockchip_drm_vop.c that gets broken with this change.
> > Specifically, the function says in the comments "When DRM gives us a
> > mode, we should add 999 Hz to it.". I believe this is no longer true
> > after this clk change, and when I remove the + 999 from the function
> > the DSI panel works again. Note that I do not know the implications
> > of removing this 999 aside from that it fixes the DSI panel on my
> > PX30 after this change, so I don't know if it's a positive change
> > or not.
> >
> > Thank you.
>
> Thank you for the report!
>
> I'll check this. Perhaps Heiko can help with testing as well on his side.
On the first glance the mentioned patch may not be the culprit because it does
not change the functional behaviour (if I'm not mistaken). What really changes
it is the additional flag that removes the left-shift of the rate in the
calculations.
To me sounds like you found a proper solution to the issue and that +999 is
a hack against the (blindly?) copied part of the algorithm used in fractional
divider. Have you read the top comment in clk-fractional-divider.c? It should
explain how it works after my series.
In any case I'm not going to come to any conclusions right now and also want
to hear from people who have better understanding of this hardware.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists