linux-mediatek.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Boris Lysov <arz65xx@gmail.com>,
	arzamas-16@mail.ee, mturquette@baylibre.com, sboyd@kernel.org,
	matthias.bgg@gmail.com, wenst@chromium.org,
	miles.chen@mediatek.com
Cc: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] clk: mediatek: Fix unused 'ops' field in mtk_pll_data
Date: Wed, 18 May 2022 14:15:13 +0200	[thread overview]
Message-ID: <ead37cb0-c841-df1a-ca10-a396b5e9951c@collabora.com> (raw)
In-Reply-To: <20220515122409.13423-1-arzamas-16@mail.ee>

Il 15/05/22 14:24, Boris Lysov ha scritto:
> From: Boris Lysov <arzamas-16@mail.ee>
> 
> Allow to specify optional clk_ops in mtk_pll_data which will be picked up in
> mtk_clk_register_pll. So far no already supported Mediatek SoC needs
> non-default clk_ops for PLLs but instead of removing this field it will be
> actually used in the future for supporting older SoCs (see [1] for details)
> with quirky PLLs.
> 

Hello Boris,

I disagree about this change and would rather see the ops pointer removed
with fire.

I got that you're trying to do something about "quirky PLLs", but is it
really about the PLLs that you're mentioning being "quirky", or are they
simply a different IP?

Also, if it's just about a bit inversion and a bigger delay:
1. Bigger delay: Depending on how bigger, we may simply delay more by default
    for all PLLs, even the ones that aren't requiring us to wait for longer...
    ...after all, if it's about waiting for 10/20 *microseconds* more, that's
    really not going to affect anyone's UX, nor make things slower for real,
    as the .prepare() ops for MediaTek PLLs are seldom called.. and even if
    that wasn't true, I don't think that a total of 30uS would be that much
    detrimental to the system's overall operation latency.
    Besides, if you see a case of a PLL not just switching on and off, but
    preparing and unpreparing continuously, there must be some big issue in
    some driver, or in the clock framework somewhere (and that ain't the case);

2. Bit inversion: that can be solved simply with a flag in the prepare/unprepare
    ops for this driver... and if you want something that performs even better,
    sparing you a nanosecond or two, you can always assign an "inverted" callback
    for managing that single bit;

3. Different IP: mtk_clk_register_(name-of-the-new-ip)_pll() - I don't think that
    there's anything to explain to that one.

Regards,
Angelo

> This patch depends on series "clk: mediatek: Move to struct clk_hw provider
> APIs" [2] by Chen-Yu Tsai.
> 
> [1] https://lists.infradead.org/pipermail/linux-mediatek/2022-February/035093.html
> [2] https://lists.infradead.org/pipermail/linux-mediatek/2022-May/040921.html
> 
> Signed-off-by: Boris Lysov <arzamas-16@mail.ee>
> ---
>   drivers/clk/mediatek/clk-pll.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> index cabdf25a27f3..509959a325f0 100644
> --- a/drivers/clk/mediatek/clk-pll.c
> +++ b/drivers/clk/mediatek/clk-pll.c
> @@ -347,7 +347,10 @@ static struct clk_hw *mtk_clk_register_pll(const struct mtk_pll_data *data,
>   
>   	init.name = data->name;
>   	init.flags = (data->flags & PLL_AO) ? CLK_IS_CRITICAL : 0;
> -	init.ops = &mtk_pll_ops;
> +	if (data->ops)
> +		init.ops = data->ops;
> +	else
> +		init.ops = &mtk_pll_ops;
>   	if (data->parent_name)
>   		init.parent_names = &data->parent_name;
>   	else
> 


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

  reply	other threads:[~2022-05-18 12:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-15 12:24 [PATCH] clk: mediatek: Fix unused 'ops' field in mtk_pll_data Boris Lysov
2022-05-18 12:15 ` AngeloGioacchino Del Regno [this message]
2022-05-19 19:27   ` Boris Lysov
2022-05-20  8:27     ` AngeloGioacchino Del Regno
2022-05-20 16:59       ` Boris Lysov

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=ead37cb0-c841-df1a-ca10-a396b5e9951c@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=arz65xx@gmail.com \
    --cc=arzamas-16@mail.ee \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=miles.chen@mediatek.com \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    --cc=wenst@chromium.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;
as well as URLs for NNTP newsgroup(s).