All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Oltmanns <frank@oltmanns.dev>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Andre Przywara <andre.przywara@arm.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Roman Beranek <me@crly.cz>, Samuel Holland <samuel@sholland.org>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 0/2] clk: sunxi-ng: Consider alternative parent rates when determining NKM clock rate
Date: Thu, 08 Jun 2023 11:29:05 +0200	[thread overview]
Message-ID: <871qim1eow.fsf@oltmanns.dev> (raw)
In-Reply-To: <vvmdk3fqtjt3jspxgvlbypdxajchymydshya5b5ivk3wfodwwr@yyi26m6toosh>


On 2023-06-07 at 14:27:46 +0200, Maxime Ripard <maxime@cerno.tech> wrote:
> [[PGP Signed Part:Undecided]]
> On Wed, Jun 07, 2023 at 09:35:20AM +0200, Frank Oltmanns wrote:
>> So, my question: Is spending the 30 ms fine or do I need to optimize for
>> speed in order for this patchset to be accepted? Or is 2 ms also too
>> much of an increase, in which case I'm out of ideas. :-)
>
> You keep mentioning it, but it's really not clear to me why you think
> that both are intertwined, or depend on one another?

I'm sorry about that. I guess, I got carried away. And furthermore I
took your mentioning of all bets being of how often setting rates
happens when HDMI comes into play as encouragement to optimize for
speed, which it clearly wasn't.

I saw the increase in time as a regression, because it might break
boards that I don't have access to. But since you say it's fine, I'll
speak no more of it.

> What's wrong with just merging (some later version of) this series?

Nothing. :-)

Thanks,
  Frank

>
> Maxime
>
> [[End of PGP Signed Part]]

WARNING: multiple messages have this Message-ID (diff)
From: Frank Oltmanns <frank@oltmanns.dev>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Andre Przywara <andre.przywara@arm.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Roman Beranek <me@crly.cz>, Samuel Holland <samuel@sholland.org>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 0/2] clk: sunxi-ng: Consider alternative parent rates when determining NKM clock rate
Date: Thu, 08 Jun 2023 11:29:05 +0200	[thread overview]
Message-ID: <871qim1eow.fsf@oltmanns.dev> (raw)
In-Reply-To: <vvmdk3fqtjt3jspxgvlbypdxajchymydshya5b5ivk3wfodwwr@yyi26m6toosh>


On 2023-06-07 at 14:27:46 +0200, Maxime Ripard <maxime@cerno.tech> wrote:
> [[PGP Signed Part:Undecided]]
> On Wed, Jun 07, 2023 at 09:35:20AM +0200, Frank Oltmanns wrote:
>> So, my question: Is spending the 30 ms fine or do I need to optimize for
>> speed in order for this patchset to be accepted? Or is 2 ms also too
>> much of an increase, in which case I'm out of ideas. :-)
>
> You keep mentioning it, but it's really not clear to me why you think
> that both are intertwined, or depend on one another?

I'm sorry about that. I guess, I got carried away. And furthermore I
took your mentioning of all bets being of how often setting rates
happens when HDMI comes into play as encouragement to optimize for
speed, which it clearly wasn't.

I saw the increase in time as a regression, because it might break
boards that I don't have access to. But since you say it's fine, I'll
speak no more of it.

> What's wrong with just merging (some later version of) this series?

Nothing. :-)

Thanks,
  Frank

>
> Maxime
>
> [[End of PGP Signed Part]]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-06-08  9:33 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05 19:07 [PATCH 0/2] clk: sunxi-ng: Consider alternative parent rates when determining NKM clock rate Frank Oltmanns
2023-06-05 19:07 ` Frank Oltmanns
2023-06-05 19:07 ` [PATCH 1/2] clk: sunxi-ng: nkm: consider alternative parent rates when finding rate Frank Oltmanns
2023-06-05 19:07   ` Frank Oltmanns
2023-06-07  6:38   ` Maxime Ripard
2023-06-07  6:38     ` Maxime Ripard
2023-06-07  7:39     ` Frank Oltmanns
2023-06-07  7:39       ` Frank Oltmanns
2023-06-12 12:19       ` Maxime Ripard
2023-06-12 16:29         ` Frank Oltmanns
2023-06-12 16:29           ` Frank Oltmanns
2023-06-13  9:10           ` Maxime Ripard
2023-06-13  9:10             ` Maxime Ripard
2023-06-13 10:17             ` Frank Oltmanns
2023-06-13 10:17               ` Frank Oltmanns
2023-06-13 15:30               ` Maxime Ripard
2023-06-13 15:30                 ` Maxime Ripard
2023-06-15 16:04                 ` Frank Oltmanns
2023-06-15 16:04                   ` Frank Oltmanns
2023-06-19 16:36                   ` Maxime Ripard
2023-06-19 16:36                     ` Maxime Ripard
2023-06-19  8:16             ` Frank Oltmanns
2023-06-19  8:16               ` Frank Oltmanns
2023-06-19 18:05               ` Maxime Ripard
2023-06-19 18:05                 ` Maxime Ripard
2023-06-20 18:51                 ` Frank Oltmanns
2023-06-20 18:51                   ` Frank Oltmanns
2023-06-26 16:45                   ` Maxime Ripard
2023-06-26 16:45                     ` Maxime Ripard
2023-07-12  4:39                 ` Frank Oltmanns
2023-07-12  4:39                   ` Frank Oltmanns
2023-07-17 14:06                   ` Maxime Ripard
2023-07-17 14:06                     ` Maxime Ripard
2023-07-23  8:59                     ` Frank Oltmanns
2023-07-23  8:59                       ` Frank Oltmanns
2023-07-25 13:55                       ` Maxime Ripard
2023-07-30 14:35                         ` Frank Oltmanns
2023-07-30 14:35                           ` Frank Oltmanns
2023-06-05 19:07 ` [PATCH 2/2] clk: sunxi-ng: a64: allow pll-mipi to set parent's rate Frank Oltmanns
2023-06-05 19:07   ` Frank Oltmanns
2023-06-07  7:35 ` [PATCH 0/2] clk: sunxi-ng: Consider alternative parent rates when determining NKM clock rate Frank Oltmanns
2023-06-07  7:35   ` Frank Oltmanns
2023-06-07 12:27   ` Maxime Ripard
2023-06-07 12:27     ` Maxime Ripard
2023-06-08  9:29     ` Frank Oltmanns [this message]
2023-06-08  9:29       ` Frank Oltmanns
2023-06-12  8:53       ` Maxime Ripard

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=871qim1eow.fsf@oltmanns.dev \
    --to=frank@oltmanns.dev \
    --cc=andre.przywara@arm.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=maxime@cerno.tech \
    --cc=me@crly.cz \
    --cc=mturquette@baylibre.com \
    --cc=samuel@sholland.org \
    --cc=sboyd@kernel.org \
    --cc=wens@csie.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.