From: Dominique Martinet <dominique.martinet@atmark-techno.com>
To: Frieder Schrempf <frieder@fris.de>
Cc: "Kishon Vijay Abraham I" <kishon@kernel.org>,
linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
"Vinod Koul" <vkoul@kernel.org>, "Adam Ford" <aford173@gmail.com>,
"Lucas Stach" <l.stach@pengutronix.de>,
"Marco Felsch" <m.felsch@pengutronix.de>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH 0/2] Extending PLL LUT for i.MX8MP Samsung HDMI PHY
Date: Wed, 11 Sep 2024 09:23:31 +0900 [thread overview]
Message-ID: <ZuDjAwPxHeJTvXAp@atmark-techno.com> (raw)
In-Reply-To: <20240910181544.214797-1-frieder@fris.de>
Frieder Schrempf wrote on Tue, Sep 10, 2024 at 08:14:51PM +0200:
> [2] https://codeberg.org/fschrempf/samsung-hdmi-phy-pll-calculator/src/branch/main/pll.py
Great work! Thanks!
I was curious about the existing table entries, recomputing existing
values doesn't yield the same values. For example, the first entry is
{
.pixclk = 22250000,
.pll_div_regs = { 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40 },
}
but computing it yields
{
.pixclk = 22250000,
.pll_div_regs = { 0xd1, 0x4a, 0xf0, 0xef, 0x10, 0x81, 0x40 },
}
I assume there just are multiple ways to generate the same frequencies,
which is fine in itself, but it'd be great to be able to "back-compute"
the entries as a sanity check.
I've played a bit with your script and spent more time on it than I'd
like to admit, but something like this seems to do the trick, plugging
in the regs from the kernel:
---
pll = FractionalNPLL(freq_ref)
regs = [0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40]
# assume fractional
if not regs[0] & 0xD0:
print("reg[0] missing 0xD0")
sys.exit(1)
pll.freq_frac = True
pll.params["p"] = regs[0] & 0x2f
pll.params["m"] = regs[1]
pll.params["s"] = (regs[2] >> 4) + 1
pll.params["n2"] = ((regs[2] >> 3) & 0x1) + 1
pll.params["n"] = (regs[2] & 0x7) + 4
pll.params["lc"] = regs[3] & 0x7f
if regs[4] & 0x80:
pll.params["lc"] = - pll.params["lc"]
pll.params["k"] = regs[4] & 0x7f
pll.params["lc_s"] = regs[5] & 0x7f
pll.params["k_s"] = regs[6] & 0xbf
f_vco = int(pll.params["m"] * pll.f_ref / pll.params["p"])
if f_vco < 750000000 or f_vco > 3000000000:
print(f"f_vco {f_vco} out of range")
sys.exit(1)
f_calc = f_vco / pll.params["s"] / 5
pll.freq_int = round(f_calc)
print(f_calc)
sdc = pll.calc_sdc(pll.params)
frac = pll.calc_f_frac(sdc, pll.params)
print(frac)
freq = pll.freq_int + frac
print(freq)
pll.print_reg_driver_data(freq)
exit(0);
---
yields this back (comments added manually)
---
22500000.0 (integer part)
-250000.0 (fractional part)
22250000.0 (summed)
PHY Driver Table Entry:
{
.pixclk = 22250000.0,
.pll_div_regs = { 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x81, 0x40 },
}
---
so if I find some time I'll whip some loop to check all other values...
That aside, I see no problem with this, just one meta-comment about
adding a link to the script in an external repo: I see some other
drivers have python scripts in their trees e.g.
drivers/comedi/drivers/ni_routing/tools/*py
drivers/gpu/drm/ci/xfails/update-xfails.py
drivers/gpu/drm/msm/registers/gen_header.py
would it make sense to commit the script here instead of linking to a
repo that might be lost in the future?
I'm not quite sure what policy the linux repo has here, so leaving that
as an open question.
--
Dominique
next prev parent reply other threads:[~2024-09-11 0:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 18:14 [PATCH 0/2] Extending PLL LUT for i.MX8MP Samsung HDMI PHY Frieder Schrempf
2024-09-10 18:14 ` [PATCH 1/2] phy: freescale: fsl-samsung-hdmi: Add references for calculating LUT parameters to comment Frieder Schrempf
2024-09-10 18:14 ` [PATCH 2/2] phy: freescale: fsl-samsung-hdmi: Add PLL LUT entries for some non-CEA-861 modes Frieder Schrempf
2024-09-11 0:23 ` Dominique Martinet [this message]
2024-09-11 1:16 ` [PATCH 0/2] Extending PLL LUT for i.MX8MP Samsung HDMI PHY Adam Ford
2024-09-11 1:27 ` Dominique Martinet
2024-09-11 18:26 ` Frieder Schrempf
2024-09-11 6:08 ` Dominique Martinet
2024-09-11 19:03 ` Frieder Schrempf
2024-09-11 18:24 ` Frieder Schrempf
2024-12-10 7:15 ` Frieder Schrempf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZuDjAwPxHeJTvXAp@atmark-techno.com \
--to=dominique.martinet@atmark-techno.com \
--cc=aford173@gmail.com \
--cc=frieder@fris.de \
--cc=kishon@kernel.org \
--cc=l.stach@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=m.felsch@pengutronix.de \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox