[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210518032634.4ek6gpjjagtxptpv@vireshk-i7>
Date: Tue, 18 May 2021 08:56:34 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Dmitry Osipenko <digetx@...il.com>
Cc: Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Paul Fertser <fercerpav@...il.com>,
Matt Merhar <mattmerhar@...tonmail.com>,
Peter Geis <pgwipeout@...il.com>,
Nicolas Chauvet <kwizart@...il.com>,
Viresh Kumar <vireshk@...nel.org>,
Stephen Boyd <sboyd@...nel.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/1] soc/tegra: Add
devm_tegra_core_dev_init_opp_table()
On 17-05-21, 17:09, Dmitry Osipenko wrote:
> 17.05.2021 06:37, Viresh Kumar пишет:
> > I am not sure why you divided this into three different patchsets,
> > while it should really have been one. Like this one just adds the API
> > but doesn't use it.
>
> Previously Krzysztof Kozlowski asked to split the large series into smaller sets which could be reviewed and applied separately by maintainers. He suggested that the immutable branch is a better option, I decided to implement this suggestion. So far I only sent out the memory patches which make use of the new helper, there will be more patches. The memory patches are intended to show that this helper can be utilized right now. My plan was to finalize this patch first, then Thierry will apply it and I will be able to sent the rest of the patches telling that they depend on the immutable branch.
>
> I'll merge this helper patch and the memory patches into a single series in v2.
Diving the series is fine, but an API and its users should always be
in the same series. You can still apply them differently anyway.
> The previous versions of this patch had this comment:
>
> /*
> * dev_pm_opp_set_rate() doesn't search for a floor clock rate and it
> * will error out if default clock rate is too high, i.e. unsupported
> * by a SoC hardware version. Hence find floor rate by ourselves.
> */
>
> I removed it because it appeared to me that it should be obvious why this is needed.
It can never be obvious to anyone without looking at the API in
detail. So if it is indeed required, please keep the comment as is.
--
viresh
Powered by blists - more mailing lists