.remove = virtio_gpio_remove,
> .driver = {
> .name = KBUILD_MODNAME,
> - .owner = THIS_MODULE,
> },
> };
> module_virtio_driver(virtio_gpio_driver);
Acked-by: Viresh Kumar
--
viresh
* clkname is set separately so it is not affected by the optional
> + * regulator setting which may return error.
> + */
> + ret = devm_pm_opp_set_clkname(dev, "core");
> + if (ret)
> + return ret;
> +
> + ret = devm_pm_opp_set_regulators(dev, regulator_names);
> if (ret) {
> /* Continue if the optional regulator is missing */
> if (ret != -ENODEV)
Acked-by: Viresh Kumar
--
viresh
On 26-10-22, 10:39, Erico Nunes wrote:
> Commit d8c32d3971e4 ("drm/lima: Migrate to dev_pm_opp_set_config()")
> introduced a regression as it may undo the clk_names setting in case
> the optional regulator is missing. This resulted in test and performance
> regressions with lima.
>
> Restore the
if (machine_is_h3100())
> - name = "KM416S4030CT";
> if (machine_is_jornada720() || machine_is_h3600())
> name = "K4S281632B-1H";
> - if (machine_is_nanoengine())
> - name = "MT
of the
resource unnecessarily.
> Suggested-by: Viresh Kumar
> Signed-off-by: Clément Péron
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/
Make dev_pm_opp_set_regulators() accept a NULL terminated list of names
instead of making the callers keep the two parameters in sync, which
creates an opportunity for bugs to get in.
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Viresh Kumar
---
V3->V3.1:
- Update panfrost_drv.c to incl
On 04-07-22, 15:35, Steven Price wrote:
> I have to say the 'new improved' list ending with NULL approach doesn't
> work out so well for Panfrost. We already have to have a separate
> 'num_supplies' variable for devm_regulator_bulk_get() /
> regulator_bulk_{en,dis}able(), so the keeping everything
Make dev_pm_opp_set_regulators() accept a NULL terminated list of names
instead of making the callers keep the two parameters in sync, which
creates an opportunity for bugs to get in.
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-dt.c
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
by few people.
- Dropped the last patch to rearrange stuff, not required anymore.
Thanks.
--
Viresh
Viresh Kumar (20):
OPP: Track if clock name is configured by platform
OPP: Make dev_pm_opp_set_regulators() accept NULL terminated list
OPP: Add dev_pm_opp_set_config() and friends
cpufreq
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Tested-by: Dmitry Osipenko
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/tegra/gr3d.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Acked-by: Steven Price
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 +-
drivers/gpu/drm/msm
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
low multiple clocks.
- Converted few // comments to /* */.
- Added tags by few people.
- Dropped the last patch to rearrange stuff, not required anymore.
Thanks.
--
Viresh
Viresh Kumar (30):
OPP: Track if clock name is configured by platform
OPP: Add dev_pm_opp_set_config() and friends
cpuf
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/tegra/gr3d.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/gr3d.c b
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 +-
drivers/gpu/drm/msm
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
it a try.
This is pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git opp/config
The entire patchset shall get merged via the OPP tree in 5.20-rc1, please do not
merge individual patches.
Thanks.
--
Viresh
Viresh Kumar (31):
OPP: Track if clock name is configured
1st arg cell
> - description: 2nd arg cell
>
> With this change, some examples need updating so that the bracketing of
> property values matches the schema.
>
> .../devicetree/bindings/opp/opp-v2-base.yaml | 2 +
> .../bindings/power/power-domain.yaml | 4 +
Acked-by: Viresh Kumar
--
viresh
d-off-by: Michael S. Tsirkin
> ---
> drivers/gpio/gpio-virtio.c | 2 +-
> drivers/i2c/busses/i2c-virtio.c | 2 +-
Reviewed-by: Viresh Kumar
--
viresh
On 27-09-21, 01:40, Dmitry Osipenko wrote:
> Elements of the 'names' array are not changed by the code, constify them
> for consistency.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 6 +++---
> include/linux/pm_opp.h | 8
> 2 files changed, 7 insertions(+), 7
On 27-09-21, 01:40, Dmitry Osipenko wrote:
> This series adds runtime PM support to Tegra drivers and enables core
> voltage scaling for Tegra20/30 SoCs, resolving overheating troubles.
>
> All patches in this series are interdependent and should go via Tegra tree.
So you don't need any OPP
On 26-08-21, 08:24, Viresh Kumar wrote:
> On 25-08-21, 18:41, Dmitry Osipenko wrote:
> > Thinking a bit more about this, I got a nicer variant which actually works
> > in all cases for Tegra.
> >
> > Viresh / Ulf, what do you think about this:
>
> This is what
On 25-08-21, 18:41, Dmitry Osipenko wrote:
> Thinking a bit more about this, I got a nicer variant which actually works in
> all cases for Tegra.
>
> Viresh / Ulf, what do you think about this:
This is what I have been suggesting from day 1 :)
On 23-08-21, 23:24, Dmitry Osipenko wrote:
> It's not clear to me whether it will be okay to add a generic OPP syncing by
> clock rate or should it be a Tegra-specific helper. Viresh, what do you think
> about this generic OPP helper:
>
> /**
> * dev_pm_opp_sync_with_clk_rate() - Sync OPP
On 19-08-21, 16:55, Ulf Hansson wrote:
> Right, that sounds reasonable.
>
> We already have pm_genpd_opp_to_performance_state() which translates
> an OPP to a performance state. This function invokes the
> ->opp_to_performance_state() for a genpd. Maybe we need to allow a
> genpd to not have
On 19-08-21, 22:35, Dmitry Osipenko wrote:
> 19.08.2021 16:07, Ulf Hansson пишет:
> > In the other scenario where a consumer driver prefers to *not* call
> > pm_runtime_resume_and_get() in its ->probe(), because it doesn't need
> > to power on the device to complete probing, then we don't want to
On 18-08-21, 18:55, Dmitry Osipenko wrote:
> 18.08.2021 12:41, Ulf Hansson пишет:
>
> Either way gives the equal result. The new callback allows to remove the
> boilerplate dev_pm_opp_set_rate(clk_get_rate() code from the rpm-resume
> of consumer devices, that's it.
It may not be equal, as
On 18-08-21, 11:41, Ulf Hansson wrote:
> On Wed, 18 Aug 2021 at 11:14, Viresh Kumar wrote:
> > What we need here is just configure. So something like this then:
> >
> > - genpd->get_performance_state()
> > -> dev_pm_opp_get_current_opp() //New API
> > -&
On 18-08-21, 10:29, Ulf Hansson wrote:
> Me and Dmitry discussed adding a new genpd callback for this. I agreed
> that it seems like a reasonable thing to add, if he insists.
>
> The intent was to invoke the new callback from __genpd_dev_pm_attach()
> when the device has been attached to its
On 18-08-21, 09:22, Dmitry Osipenko wrote:
> 18.08.2021 08:58, Viresh Kumar пишет:
> > What about calling dev_pm_opp_set_rate(dev, clk_get_rate(dev)) here
> > instead ? That will work, right ? The advantage is it works without
> > any special routine to do so.
>
> It
On 18-08-21, 11:28, Viresh Kumar wrote:
> On 18-08-21, 08:21, Dmitry Osipenko wrote:
> > Yes, GENPD will cache the perf state across suspend/resume and initially
> > cached value is out of sync with h/w.
> >
> > Nothing else. But let me clarify it all again.
>
On 18-08-21, 08:21, Dmitry Osipenko wrote:
> Yes, GENPD will cache the perf state across suspend/resume and initially
> cached value is out of sync with h/w.
>
> Nothing else. But let me clarify it all again.
Thanks for your explanation.
> Initially the performance state of all GENPDs is 0 for
On 18-08-21, 07:37, Dmitry Osipenko wrote:
> This will set voltage level without having an actively used hardware.
> Take a 3d driver for example, if you set the rate on probe and
> rpm-resume will never be called, then the voltage will be set high,
> while hardware is kept suspended if userspace
On 18-08-21, 07:30, Dmitry Osipenko wrote:
> 18.08.2021 07:29, Dmitry Osipenko пишет:
> >> The first resume initializes the OPP state on sync, all further syncs on
> >> resume are no-ops.
> >>
> >
> > Notice that we use GENPD here. GENPD core takes care of storing PD's
> > performance state
On 18-08-21, 07:12, Dmitry Osipenko wrote:
> 18.08.2021 06:55, Viresh Kumar пишет:
> > On 17-08-21, 18:49, Dmitry Osipenko wrote:
> >> 17.08.2021 10:55, Viresh Kumar пишет:
> >> ...
> >>>> +int dev_pm_opp_sync(struct device *dev)
> >&g
On 17-08-21, 18:49, Dmitry Osipenko wrote:
> 17.08.2021 10:55, Viresh Kumar пишет:
> ...
> >> +int dev_pm_opp_sync(struct device *dev)
> >> +{
> >> + struct opp_table *opp_table;
> >> + struct dev_pm_opp *opp;
> >> + int ret =
On 17-08-21, 04:27, Dmitry Osipenko wrote:
> Add dev_pm_opp_sync() helper which syncs OPP table with hardware state
> and vice versa.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 42 +++---
> include/linux/pm_opp.h | 6 ++
> 2
ree.org/meta-schemas/core.yaml#
> +
> +title: Generic OPP (Operating Performance Points) Common Binding
> +
> +maintainers:
> + - Viresh Kumar
> +
> +description: |
> + Devices work at voltage-current-frequency combinations and some
> implementations
> + have the lib
| 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Viresh Kumar
--
viresh
On 25-03-21, 10:13, Stanimir Varbanov wrote:
> Hi,
>
> On 3/14/21 6:34 PM, Dmitry Osipenko wrote:
> > From: Yangtao Li
> >
> > Use resource-managed OPP API to simplify code.
> >
> > Signed-off-by: Yangtao Li
> > Signed-off-by: Dmitry Osipenko
> > ---
> >
On 14-03-21, 19:33, Dmitry Osipenko wrote:
> This series adds resource-managed OPP API helpers and makes drivers
> to use them.
>
> Changelog:
>
> v3: - Dropped dev_pm_opp_register_notifier().
>
> - Changed return type of the devm helpers from opp_table pointer
> to errno.
>
> -
+), 68 deletions(-)
This patch has some updates in linux-next, which I don't have. Please
get this merged with the drm tree over 5.13-rc1 later.
Acked-by: Viresh Kumar
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 11-03-21, 22:20, Dmitry Osipenko wrote:
> +struct opp_table *devm_pm_opp_set_clkname(struct device *dev, const char
> *name)
> +{
> + struct opp_table *opp_table;
> + int err;
> +
> + opp_table = dev_pm_opp_set_clkname(dev, name);
> + if (IS_ERR(opp_table))
> +
On 11-03-21, 22:20, Dmitry Osipenko wrote:
> From: Yangtao Li
>
> Add devres wrapper for dev_pm_opp_register_notifier() to simplify driver
> code.
>
> Signed-off-by: Yangtao Li
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 38 ++
>
On 02-03-21, 16:40, Dmitry Osipenko wrote:
> 20.01.2021 19:01, Dmitry Osipenko пишет:
> > 01.01.2021 19:54, Yangtao Li пишет:
> >> Hi,
> >>
> >> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> >> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> >>
; struct mhuv2 *mhu = amba_get_drvdata(adev);
>
> if (mhu->frame == SENDER_FRAME)
> writel_relaxed(0x0, >send->access_request);
> -
> - return 0;
> }
>
> static struct amba_id mhuv2_ids[] = {
Acked-by: Viresh Kumar
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
be used instead. Migrate to the new API.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
through OPP tree here. Please provide
your Acks for platform specific bits.
--
Viresh
Viresh Kumar (13):
opp: Rename _opp_set_rate_zero()
opp: No need to check clk for errors
opp: Keep track of currently programmed OPP
opp: Split _set_opp() out of dev_pm_opp_set_rate()
opp: Allow _set_opp
On 01-01-21, 16:54, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code, and we don't need
> to make opp_table glabal.
>
> Let's remove opp_table from geni_se later.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/tty/serial/qcom_geni_serial.c | 23 +--
> 1 file
On 01-01-21, 16:54, Yangtao Li wrote:
> There is no need to manually release devm related resources.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/gpu/drm/lima/lima_devfreq.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
>
On 01-01-21, 16:54, Yangtao Li wrote:
> Hi,
>
> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> devm_pm_opp_set_supported_hw, devm_pm_opp_of_add_table and
> devm_pm_opp_register_notifier.
Please also mention next
On 01-01-21, 16:54, Yangtao Li wrote:
> We should use dev_pm_opp_put_clkname() to free opp table each time
> dev_pm_opp_of_add_table() got error.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/tty/serial/qcom_geni_serial.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
>
On 01-01-21, 16:54, Yangtao Li wrote:
> Add devres wrapper for dev_pm_opp_register_notifier() to simplify driver
> code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/opp/core.c | 38 ++
> include/linux/pm_opp.h | 6 ++
> 2 files changed, 44
On 01-01-21, 16:54, Yangtao Li wrote:
> +/**
> + * devm_pm_opp_put_clkname() - Releases resources blocked for clk.
> + * @dev: Device for which we do this operation.
> + * @opp_table: OPP table returned from devm_pm_opp_set_clkname().
> + */
> +void devm_pm_opp_put_clkname(struct device *dev,
On 03-01-21, 03:54, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code, and remove opp_table
> from tegra_devfreq.
Patches starting this one didn't appear in the same thread and it is a
nightmare to apply these now. Please send everything properly next
time.
--
viresh
On 01-01-21, 16:54, Yangtao Li wrote:
> Hi,
>
> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> devm_pm_opp_set_supported_hw, devm_pm_opp_of_add_table and
> devm_pm_opp_register_notifier.
You can't put so many names
On 03-01-21, 03:57, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/devfreq.c | 66 +--
> include/linux/devfreq.h | 23 --
> 2 files changed, 1 insertion(+), 88 deletions(-)
Dropped lots of people from cc list
On 04-01-21, 12:49, Viresh Kumar wrote:
> On 01-01-21, 16:54, Yangtao Li wrote:
> > Use devm_pm_opp_* API to simplify code, and we don't need
> > to make opp_table glabal.
> >
> > Let's remove opp_table from geni_se later.
> &g
On 28-12-20, 17:03, Dmitry Osipenko wrote:
> 28.12.2020 09:22, Viresh Kumar пишет:
> > On 24-12-20, 16:00, Dmitry Osipenko wrote:
> >> In a device driver I want to set PD to the lowest performance state by
> >> removing the performance vote when dev_pm_opp_set_r
On 24-12-20, 16:00, Dmitry Osipenko wrote:
> In a device driver I want to set PD to the lowest performance state by
> removing the performance vote when dev_pm_opp_set_rate(dev, 0) is
> invoked by the driver.
>
> The OPP core already does this, but if OPP levels don't start from 0 in
> a
On 23-12-20, 23:37, Dmitry Osipenko wrote:
> 23.12.2020 08:57, Viresh Kumar пишет:
> > What's wrong with getting the regulator in the driver as well ? Apart from
> > the
> > OPP core ?
>
> The voltage syncing should be done for each consumer regulator
> individually
On 23-12-20, 23:37, Dmitry Osipenko wrote:
> 23.12.2020 07:19, Viresh Kumar пишет:
> > On 22-12-20, 22:15, Dmitry Osipenko wrote:
> >> 22.12.2020 09:42, Viresh Kumar пишет:
> >>> On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >>>> Add a ceil version of th
On 23-12-20, 23:38, Dmitry Osipenko wrote:
> Well, there is no "same structure", the opp_table->set_opp_data is NULL
> there.
Right, I saw that yesterday. What I meant was that we need to start allocating
the structure for this case now.
--
viresh
___
On 23-12-20, 23:36, Dmitry Osipenko wrote:
> 23.12.2020 07:34, Viresh Kumar пишет:
> > On 22-12-20, 22:19, Dmitry Osipenko wrote:
> >> 22.12.2020 12:12, Viresh Kumar пишет:
> >>> rate will be 0 for both the OPPs here if rate_not_available is true and
> &
On 22-12-20, 22:15, Dmitry Osipenko wrote:
> 22.12.2020 09:42, Viresh Kumar пишет:
> > On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >> Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if
> >> levels don't start from 0 in OPP table and zero usually
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Support set_opp() customization without requiring to use regulators. This
> is needed by drivers which want to use dev_pm_opp_set_rate() for changing
> rates of a multiple clocks and don't need to touch regulator.
>
> One example is NVIDIA Tegra30/114
On 22-12-20, 22:19, Dmitry Osipenko wrote:
> 22.12.2020 12:12, Viresh Kumar пишет:
> > On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
> >> unavailable. The OPP comparison is erroneously skipped if OPP
On 22-12-20, 22:39, Dmitry Osipenko wrote:
> 22.12.2020 22:21, Dmitry Osipenko пишет:
> >>> + if (IS_ERR(opp)) {
> >>> + dev_err(>dev, "failed to find OPP for level %u: %pe\n",
> >>> + level, opp);
> >>> + return PTR_ERR(opp);
> >>> + }
> >>> +
> >>> + err =
On 18-12-20, 16:51, Dmitry Osipenko wrote:
> Alright, although I haven't pretended that v2 patches should be merged
> right away since they are fundamentally different from v1, and thus, all
> patches need to be reviewed first.
I agree. I have done some basic review for the stuff.
> If the
On 22-12-20, 22:17, Dmitry Osipenko wrote:
> 22.12.2020 11:59, Viresh Kumar пишет:
> > On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >> A required OPP may not be available, and thus, all OPPs which are using
> >> this required OPP should be unavailable too.
> >>
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> diff --git a/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
> b/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
> index cbe84d25e726..983db1a06682 100644
> --- a/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
> +++
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Add dev_pm_opp_set_voltage() which allows OPP table users to set voltage
> in accordance to a given OPP. In particular this is needed for driving
> voltage of a generic power domain which uses OPPs and doesn't have a
> clock.
>
> Signed-off-by: Dmitry
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> A required OPP may not be available, and thus, all OPPs which are using
> this required OPP should be unavailable too.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Add resource-managed versions of OPP API functions. This removes a need
> from drivers to store and manage OPP table pointers.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 173 +
>
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> +++ b/drivers/soc/tegra/core-power-domain.c
> @@ -0,0 +1,125 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * NVIDIA Tegra SoC Core Power Domain Driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
>
On 17-12-20, 21:05, Dmitry Osipenko wrote:
> Extend OPP API with dev_pm_opp_sync_regulators() function, which syncs
> voltage state of regulators.
>
> Signed-off-by: Dmitry Osipenko
We shouldn't be doing this, details in patch 28.
--
viresh
___
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> diff --git a/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> b/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> index b84afecea154..7e015cdfbc55 100644
> --- a/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> +++
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
> unavailable. The OPP comparison is erroneously skipped if OPP rate is
> missing, thus OPPs are left unsorted.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 23
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if
> levels don't start from 0 in OPP table and zero usually means a minimal
> level.
>
> Signed-off-by: Dmitry Osipenko
Why doesn't the exact version work for you here ?
--
On Mon, 9 Nov 2020 at 16:51, Frank Lee wrote:
> On Mon, Nov 9, 2020 at 1:53 PM Viresh Kumar wrote:
> > > devm_pm_opp_set_supported_hw()
> > > devm_pm_opp_set_regulators() [if we won't use GENPD]
> > > devm_pm_opp_set_clkname()
> > > devm_pm_opp_of_add_
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Support set_opp() customization without requiring to use regulators. This
> is needed by drivers which want to use dev_pm_opp_set_rate() for changing
> rates of a multiple clocks and don't need to touch regulator.
>
> One example is NVIDIA Tegra30/114
On 17-12-20, 21:05, Dmitry Osipenko wrote:
> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
> power consumption and heating of the Tegra chips. Tegra SoC has multiple
> hardware units which belong to a core power domain of the SoC and share
> the core voltage. The voltage
On 07-12-20, 11:46, Viresh Kumar wrote:
> On 19-11-20, 11:35, Viresh Kumar wrote:
> > On 18-11-20, 08:53, Rob Clark wrote:
> > > On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar
> > > wrote:
> > > >
> > > > On 17-11-20, 09:02, Rob Clark wrot
On 19-11-20, 11:35, Viresh Kumar wrote:
> On 18-11-20, 08:53, Rob Clark wrote:
> > On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar
> > wrote:
> > >
> > > On 17-11-20, 09:02, Rob Clark wrote:
> > > > With that on top of the previous patch,
> &
On 23-11-20, 03:27, Dmitry Osipenko wrote:
> This series brings initial support for memory interconnect to Tegra20,
> Tegra30 and Tegra124 SoCs.
>
> For the starter only display controllers and devfreq devices are getting
> interconnect API support, others could be supported later on. The display
On 18-11-20, 08:53, Rob Clark wrote:
> On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar wrote:
> >
> > On 17-11-20, 09:02, Rob Clark wrote:
> > > With that on top of the previous patch,
> >
> > Don't you still have this ? Which fixed the lockdep in the remove p
On 17-11-20, 17:17, Dmitry Osipenko wrote:
> 17.11.2020 13:07, Viresh Kumar пишет:
> > On 16-11-20, 00:29, Dmitry Osipenko wrote:
> >> This patch moves ACTMON driver away from generating OPP table by itself,
> >> transitioning it to use the table which comes from de
On 17-11-20, 09:02, Rob Clark wrote:
> With that on top of the previous patch,
Don't you still have this ? Which fixed the lockdep in the remove path.
https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
To make it clear you need these patches to fix the OPP stuff:
//From
On Fri, 6 Nov 2020 at 12:46, Viresh Kumar wrote:
>
> On 05-11-20, 11:24, Rob Clark wrote:
> > On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> > >
> > > On 03-11-20, 08:50, Rob Clark wrote:
> > > > sorry, it didn't apply cleanly (which I guess
On 16-11-20, 00:29, Dmitry Osipenko wrote:
> This patch moves ACTMON driver away from generating OPP table by itself,
> transitioning it to use the table which comes from device-tree. This
> change breaks compatibility with older device-trees in order to bring
> support for the interconnect
On 11-11-20, 10:32, Dmitry Osipenko wrote:
> 11.11.2020 09:18, Viresh Kumar пишет:
> > On 11-11-20, 09:14, Dmitry Osipenko wrote:
> >> The dev_pm_opp_of_add_table() will produce a error message which doesn't
> >> give a clue about what's wrong, i.e. that devi
On 11-11-20, 09:14, Dmitry Osipenko wrote:
> 11.11.2020 08:53, Viresh Kumar пишет:
> >> +static int tegra_emc_opp_table_init(struct tegra_emc *emc)
> >> +{
> >> + struct opp_table *reg_opp_table = NULL, *clk_opp_table, *hw_opp_table;
> >> + u32 hw_ver
On 11-11-20, 04:14, Dmitry Osipenko wrote:
> +static int tegra_emc_opp_table_init(struct tegra_emc *emc)
> +{
> + struct opp_table *reg_opp_table = NULL, *clk_opp_table, *hw_opp_table;
> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
> + const char *rname = "core";
> + int
On 11-11-20, 04:14, Dmitry Osipenko wrote:
> The dev_pm_opp_get_opp_table() shouldn't be used by drivers, use
> dev_pm_opp_set_clkname() instead.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/memory/tegra/tegra20-emc.c | 30 ++
On 11-11-20, 11:15, Viresh Kumar wrote:
> On 11-11-20, 04:14, Dmitry Osipenko wrote:
> > The dev_pm_opp_get_opp_table() shouldn't be used by drivers, use
> > dev_pm_opp_set_clkname() instead.
> >
> > Suggested-by: Viresh Kumar
> > Signed-off-by: Dmitry Osipenko
On 08-11-20, 15:19, Dmitry Osipenko wrote:
> I took a detailed look at the GENPD and tried to implement it. Here is
> what was found:
>
> 1. GENPD framework doesn't aggregate performance requests from the
> attached devices. This means that if deviceA requests performance state
> 10 and then
On 09-11-20, 08:19, Dmitry Osipenko wrote:
> Thanks, I made it in a different way by simply adding helpers to the
> pm_opp.h which use devm_add_action_or_reset(). This doesn't require to
> add new kernel symbols.
I will prefer to add it in core.c itself, and yes
devm_add_action_or_reset() looks
1 - 100 of 209 matches
Mail list logo
