mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Frieder Schrempf <frieder@fris.de>
To: Dominique Martinet <dominique.martinet@atmark-techno.com>,
	Adam Ford <aford173@gmail.com>
Cc: "Kishon Vijay Abraham I" <kishon@kernel.org>,
	linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
	"Vinod Koul" <vkoul@kernel.org>,
	"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 20:26:48 +0200	[thread overview]
Message-ID: <440cf92a-052f-4a03-91a8-2405c902aa3e@fris.de> (raw)
In-Reply-To: <ZuDyBQ1I2vcGzAqX@atmark-techno.com>

On 11.09.24 03:27, Dominique Martinet wrote:
> Adam Ford wrote on Tue, Sep 10, 2024 at 08:16:04PM -0500:
>>> 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.
>>
>> Is there a reason this couldn't be coded in C and used to expand my
>> integer calculator series?  With that, we could drop the lookup table.
> 
> Quoting a previous mail from Frieder:
>> I will clean things up a bit and then share what I have. I hope that this
>> allows anyone to calculate parameters for their non-standard displays if
>> required.
>>
>> If someone feels extra motivated they could try to calculate the fractional
>> parameters at runtime. However I'm not sure that this is feasible. The
>> numerical computation of a large number of parameters is quite heavy and it's
>> probably not easy to strip the algorithm down to something that can be run on
>> the target without too much overhead.
> 
> Trying a random frequency with the algorithm he has implemented it
> easily takes 10 seconds to run on my imx8mp board, so even if we asssume
> C is 3-4 times faster I think the current algorithm is too slow for
> runtime and it makes more sense to extended the LUT to me (as long as
> the values can be & are checked at least once, which we now can)
> 
> The current algorithm brute-forces its way through so there could be a
> better way of computing the fractional part of the divider, but I'm not
> sure it's worth the effort at this point; I guess it's a good
> intellectual challenge though so someone might do it in the future.

Second this. My algorithm is far from optimal and there might be more 
elegant solutions. If anyone feels like creating something that can be 
added to the driver that would be interesting and welcome for sure.

  reply	other threads:[~2024-09-11 18:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10 18:14 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 ` [PATCH 0/2] Extending PLL LUT for i.MX8MP Samsung HDMI PHY Dominique Martinet
2024-09-11  1:16   ` Adam Ford
2024-09-11  1:27     ` Dominique Martinet
2024-09-11 18:26       ` Frieder Schrempf [this message]
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=440cf92a-052f-4a03-91a8-2405c902aa3e@fris.de \
    --to=frieder@fris.de \
    --cc=aford173@gmail.com \
    --cc=dominique.martinet@atmark-techno.com \
    --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

all inboxes | Powered by JetHome®