On Tue, 17 Aug 2021 at 03:30, Dmitry Osipenko wrote:
>
> Add runtime PM and OPP support to the Host1x driver. It's required for
> enabling system-wide DVFS and supporting dynamic power management using
> a generic power domain. For the starter we will keep host1x always-on
> because dynamic power
On Wed, 18 Aug 2021 at 08:27, Viresh Kumar wrote:
>
> 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 s
On Tue, 17 Aug 2021 at 16:03, Thierry Reding wrote:
>
> On Tue, Aug 17, 2021 at 02:04:38PM +0200, Ulf Hansson wrote:
> > On Tue, 17 Aug 2021 at 03:30, Dmitry Osipenko wrote:
> > >
> > > Add runtime PM and OPP support to the Host1x driver. It's required for
On Wed, 18 Aug 2021 at 11:14, Viresh Kumar wrote:
>
> 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 t
On Wed, 18 Aug 2021 at 11:41, Ulf Hansson wrote:
>
> On Wed, 18 Aug 2021 at 11:14, Viresh Kumar wrote:
> >
> > 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 re
On Wed, 18 Aug 2021 at 11:50, Viresh Kumar wrote:
>
> 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:
> > >
> &
On Wed, 18 Aug 2021 at 17:43, Dmitry Osipenko wrote:
>
> 18.08.2021 13:08, Ulf Hansson пишет:
> > On Wed, 18 Aug 2021 at 11:50, Viresh Kumar wrote:
> >>
> >> On 18-08-21, 11:41, Ulf Hansson wrote:
> >>> On Wed, 18 Aug 2021 at 11:14, Viresh Kumar
>
On Thu, 19 Aug 2021 at 15:21, Thierry Reding wrote:
>
> On Tue, Aug 17, 2021 at 04:27:39AM +0300, Dmitry Osipenko wrote:
> > The PWM on Tegra belongs to the core power domain and we're going to
> > enable GENPD support for the core domain. Now PWM must be resumed using
> > runtime PM API in order
On Thu, 19 Aug 2021 at 08:17, Viresh Kumar wrote:
>
> 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_r
On Thu, 19 Aug 2021 at 21:35, Dmitry Osipenko wrote:
>
> 19.08.2021 16:07, Ulf Hansson пишет:
> > On Wed, 18 Aug 2021 at 17:43, Dmitry Osipenko wrote:
> >>
> >> 18.08.2021 13:08, Ulf Hansson пишет:
> >>> On Wed, 18 Aug 2021 at 11:50, Viresh Kumar
>
On Fri, 20 Aug 2021 at 07:18, Viresh Kumar wrote:
>
> 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
[...]
> >
> > I'm creating platform device for the clocks that require DVFS. These
> > clocks don't use regulator, they are attached to the CORE domain.
> > GENPD framework manages the performance state, aggregating perf votes
> > from each device, i.e. from each clock individually.
> >
> > You wa
[...]
> We have three components comprising PM on Tegra:
>
> 1. Power gate
> 2. Clock state
> 3. Voltage state
>
> GENPD on/off represents the 'power gate'.
>
> Clock and reset are controlled by device drivers using clk and rst APIs.
>
> Volta
On Fri, 12 Mar 2021 at 06:33, Viresh Kumar wrote:
>
> 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_clk
On Thu, 5 Nov 2020 at 11:40, Viresh Kumar wrote:
>
> On 05-11-20, 11:34, Ulf Hansson wrote:
> > I am not objecting about scaling the voltage through a regulator,
> > that's fine to me. However, encoding a power domain as a regulator
> > (even if it may seem like a r
On Thu, 5 Nov 2020 at 11:06, Viresh Kumar wrote:
>
> On 05-11-20, 10:45, Ulf Hansson wrote:
> > + Viresh
>
> Thanks Ulf. I found a bug in OPP core because you cc'd me here :)
Happy to help. :-)
>
> > On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote:
> >
+ Viresh
On Thu, 5 Nov 2020 at 00:44, 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
On Thu, 5 Nov 2020 at 12:13, Viresh Kumar wrote:
>
> On 05-11-20, 11:56, Ulf Hansson wrote:
> > On Thu, 5 Nov 2020 at 11:40, Viresh Kumar wrote:
> > > Btw, how do we identify if it is a power domain or a regulator ?
>
> To be honest, I was a bit afraid and embarrassed
On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote:
>
> Document new DVFS OPP table and voltage regulator properties of the
> Host1x bus and devices sitting on the bus.
>
> Signed-off-by: Dmitry Osipenko
> ---
> .../display/tegra/nvidia,tegra20-host1x.txt | 56 +++
> 1 file cha
On Sun, 8 Nov 2020 at 13:19, Dmitry Osipenko wrote:
>
> 05.11.2020 18:22, Dmitry Osipenko пишет:
> > 05.11.2020 12:45, Ulf Hansson пишет:
> > ...
> >> I need some more time to review this, but just a quick check found a
> >> few potential issues...
> >
On Thu, 12 Nov 2020 at 23:14, Dmitry Osipenko wrote:
>
> 12.11.2020 23:43, Thierry Reding пишет:
> >> The difference in comparison to using voltage regulator directly is
> >> minimal, basically the core-supply phandle is replaced is replaced with
> >> a power-domain phandle in a device tree.
> > T
On Sun, 17 Oct 2021 at 10:38, Dmitry Osipenko wrote:
>
> 01.10.2021 18:01, Ulf Hansson пишет:
> > On Fri, 1 Oct 2021 at 16:35, Dmitry Osipenko wrote:
> >>
> >> 01.10.2021 17:24, Ulf Hansson пишет:
> >>> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipen
;t work
> while RPM is disabled. Instead of replicating the boilerplate RPM-enable
> code around OPP helper for each driver, let's make OPP helper to take care
> of enabling it.
>
> Signed-off-by: Dmitry Osipenko
Just a minor nitpick, see below. Nevertheless feel free to add:
Re
On Tue, 26 Oct 2021 at 00:46, Dmitry Osipenko wrote:
>
> Depending on hardware version, Tegra SoC may require a higher voltages
> during resume from system suspend, otherwise hardware will crash. Set
> SoC voltages to a nominal levels during suspend.
>
> Signed-off-by: Dmitry Osipenko
I don't un
gt; for simplicity.
>
> Changelog:
>
> v14: - Fixed missing runtime PM syncing on removal of drivers, which was
>spotted by Ulf Hansson in v13.
>
> - clk-device driver now resumes RPM on system suspend instead of
>preparing clock which it backs. This wa
On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> The Clock-and-Reset controller resides in a core power domain on NVIDIA
> Tegra SoCs. In order to support voltage scaling of the core power domain,
> we hook up DVFS-capable clocks to the core GENPD for managing of the
> GENPD's performanc
On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> Only couple drivers need to get the -ENODEV error code and majority of
> drivers need to explicitly initialize the performance state. Add new
> common helper which sets up OPP table for these drivers.
>
> Signed-off-by: Dmitry Osipenko
> -
On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> Add runtime PM and OPP support to the Host1x driver. For the starter we
> will keep host1x always-on because dynamic power management require a major
> refactoring of the driver code since lot's of code paths are missing the
> RPM handling
On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> Add OPP and SoC core voltage scaling support to the display controller
> driver. This is required for enabling system-wide DVFS on pre-Tegra186
> SoCs.
>
> Tested-by: Peter Geis # Ouya T30
> Tested-by: Paul Fertser # PAZ00 T20
> Tested-by
On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> Add runtime power management and support generic power domains.
>
> Tested-by: Peter Geis # Ouya T30
> Tested-by: Paul Fertser # PAZ00 T20
> Tested-by: Nicolas Chauvet # PAZ00 T20 and TK1 T124
> Tested-by: Matt Merhar # Ouya T30
> Signe
On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> Add runtime power management and support generic power domains.
>
> Tested-by: Peter Geis # Ouya T30
> Tested-by: Paul Fertser # PAZ00 T20
> Tested-by: Nicolas Chauvet # PAZ00 T20 and TK1 T124
> Tested-by: Matt Merhar # Ouya T30
> Signe
On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> The GMI bus on Tegra belongs to the core power domain and we're going to
> enable GENPD support for the core domain. Now GMI must be resumed using
> runtime PM API in order to initialize the GMI power state. Add runtime PM
> and OPP support
On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> The NAND on Tegra belongs to the core power domain and we're going to
> enable GENPD support for the core domain. Now NAND must be resumed using
> runtime PM API in order to initialize the NAND power state. Add runtime PM
> and OPP support
On Mon, 27 Sept 2021 at 00:42, 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.
>
> Changelog:
>
>
On Fri, 1 Oct 2021 at 16:29, Dmitry Osipenko wrote:
>
> 01.10.2021 16:39, Ulf Hansson пишет:
> > On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
> >>
> >> Add runtime power management and support generic power domains.
> >>
> >> Tested
On Fri, 1 Oct 2021 at 16:35, Dmitry Osipenko wrote:
>
> 01.10.2021 17:24, Ulf Hansson пишет:
> > On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
> >>
> >> The NAND on Tegra belongs to the core power domain and we're going to
> >> enable GENPD s
On Fri, 1 Oct 2021 at 16:41, Dmitry Osipenko wrote:
>
> 01.10.2021 17:36, Ulf Hansson пишет:
> > On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
> >>
> >> This series adds runtime PM support to Tegra drivers and enables core
> >> voltage scaling for
On Fri, 1 Oct 2021 at 21:00, Dmitry Osipenko wrote:
>
> 01.10.2021 17:55, Ulf Hansson пишет:
> > On Fri, 1 Oct 2021 at 16:29, Dmitry Osipenko wrote:
> >>
> >> 01.10.2021 16:39, Ulf Hansson пишет:
> >>> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipen
On Mon, 4 Oct 2021 at 17:57, Dmitry Osipenko wrote:
>
> 04.10.2021 14:01, Ulf Hansson пишет:
> > On Fri, 1 Oct 2021 at 21:00, Dmitry Osipenko wrote:
> >>
> >> 01.10.2021 17:55, Ulf Hansson пишет:
> >>> On Fri, 1 Oct 2021 at 16:29, Dmitry Osipenko
On Sat, 2 Oct 2021 at 22:44, Dmitry Osipenko wrote:
>
> 01.10.2021 15:32, Ulf Hansson пишет:
> >> +static __maybe_unused int tegra_clock_pm_suspend(struct device *dev)
> >> +{
> >> + struct tegra_clk_device *clk_dev = dev_get_drvdata(dev);
> >&g
On Wed, 6 Oct 2021 at 00:19, Dmitry Osipenko wrote:
>
> 05.10.2021 16:10, Ulf Hansson пишет:
> > On Sat, 2 Oct 2021 at 22:44, Dmitry Osipenko wrote:
> >>
> >> 01.10.2021 15:32, Ulf Hansson пишет:
> >>>> +static __maybe_unused
On Wed, 6 Oct 2021 at 00:43, Dmitry Osipenko wrote:
>
> 06.10.2021 01:19, Dmitry Osipenko пишет:
> ...
> > I reproduced the OFF problem by removing the clk prepare/unprepare from
> > the suspend/resume of the clk driver and making some extra changes to
> > clock tree topology and etc to trigger th
On Thu, 7 Oct 2021 at 01:21, Dmitry Osipenko wrote:
>
> 07.10.2021 01:01, Dmitry Osipenko пишет:
> > 07.10.2021 00:14, Dmitry Osipenko пишет:
> >> 06.10.2021 15:43, Ulf Hansson пишет:
> >>> On Wed, 6 Oct 2021 at 00:43, Dmitry Osipenko wrote:
> >>>>
Carvalho Chehab
> Cc: Krzysztof Kozlowski
> Cc: Jakub Kicinski
> Cc: Wolfgang Grandegger
> Cc: Marc Kleine-Budde
> Cc: Andrew Lunn
> Cc: Vivien Didelot
> Cc: Florian Fainelli
> Cc: Vladimir Oltean
> Cc: Kalle Valo
> Cc: Viresh Kumar
> Cc: Stephen Boyd
> C
On Fri, 29 Oct 2021 at 17:20, Dmitry Osipenko wrote:
>
> 26.10.2021 01:40, Dmitry Osipenko пишет:
> > + ret = devm_pm_runtime_enable(&pdev->dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
> > + if (ret)
> >
Arnd Bergmann
Acked-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/mmc/host/bcm2835.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
> index 8c2361e66277..463b707d9e99 100644
> --- a/drivers/mmc/host
: Nicolas Saenz Julienne
> Signed-off-by: Arnd Bergmann
I think I acked the previous version, but nevermind:
Acked-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/mmc/host/bcm2835.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/mmc/host/bcm2835.c b/drive
-regulator voltage syncing once the state of domain is synced, at
> this point the Core voltage is allowed to go lower.
>
> Signed-off-by: Dmitry Osipenko
This looks reasonable to me, feel free to add:
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/so
On Thu, 17 Dec 2020 at 19:07, Dmitry Osipenko wrote:
>
> NVIDIA Tegra SoCs have multiple power domains, each domain corresponds
> to an external SoC power rail. Core power domain covers vast majority of
> hardware blocks within a Tegra SoC. The voltage of a power domain should
> be set to a value
On Wed, 20 Mar 2019 at 10:50, Rajendra Nayak wrote:
>
> Add the additional power domain and the OPP table for ufs on sdm845
> so the driver can set the appropriate performance state of the
> power domain while setting the clock rate.
>
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm64/boot/dts/
On Mon, 17 Dec 2018 at 15:22, Vincent Guittot
wrote:
>
> On Fri, 14 Dec 2018 at 15:36, Ulf Hansson wrote:
> >
> > On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
> > wrote:
> > >
> > > With jiffies been replaced by raw ns in PM core accounting, 915 dr
On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
wrote:
>
> On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> >
> > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson wrote:
> > > &
On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
wrote:
>
> On Wed, 19 Dec 2018 at 11:21, Ulf Hansson wrote:
> >
> > On Wed, 19 Dec 2018 at 11:11, Vincent Guittot
> > wrote:
> > >
> > > On Wed, 19 Dec 2018 at 10:58, Ulf Hansson wrote:
> > > >
On Wed, 19 Dec 2018 at 11:11, Vincent Guittot
wrote:
>
> On Wed, 19 Dec 2018 at 10:58, Ulf Hansson wrote:
> >
> > On Tue, 18 Dec 2018 at 15:55, Vincent Guittot
> > wrote:
> > >
> > > Some drivers (like i915/drm) need to get the accounted suspended
On Tue, 18 Dec 2018 at 15:55, Vincent Guittot
wrote:
>
> Some drivers (like i915/drm) need to get the accounted suspended time.
> pm_runtime_accounted_time_get() will return the suspended or active
> accounted time until now.
I suggest to leave the active accounted time out for now. At least
unti
a bss dec hex filename
> 133042996805276 402768 20512343138fe57 vmlinux
>
> Signed-off-by: Vincent Guittot
If not too late, feel free to add:
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/base/power/runtime.c | 63
> +++
On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
>
> On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> wrote:
> >
> > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:11, Vincent Guittot
> > > wrote:
> >
[...]
> Hold on. I am wondering if the drm driver could use the existing
> pm_runtime_autosuspend_expiration() function instead. Isn't that
> really that what is needed?
No, it can't. I don't know why I thought that, sorry for the noise.
U
___
dri-deve
On Thu, 20 Dec 2018 at 15:17, Vincent Guittot
wrote:
>
> From: Thara Gopinath
>
> This patch replaces jiffies based accounting for runtime_active_time
> and runtime_suspended_time with ktime base accounting. This makes the
> runtime debug counters inline with genpd and other pm subsytems which
>
On Wed, 19 Dec 2018 at 17:52, Vincent Guittot
wrote:
>
> On Wed, 19 Dec 2018 at 17:36, Ulf Hansson wrote:
> >
> > On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
> > wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> > > >
On Thu, 20 Dec 2018 at 15:16, Vincent Guittot
wrote:
>
> Some drivers (like i915/drm) needs to get the accounted suspended time.
> pm_runtime_suspended_time() will return the suspended accounted time
> in ns unit.
>
> Signed-off-by: Vincent Guittot
Reviewed-by: Ulf Hansson
ng to the new runtime PM API. I think the
changelog deserves to state that, in some simple way.
>
> Signed-off-by: Vincent Guittot
Other than the minor things above:
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 16 ++--
&g
[...]
> > > > Re-thinking this a bit from my earlier comments - and by following the
> > > > above reasoning, it sounds like this better belongs in the
> > > > driver/subsystem, without requiring any data from the core.
> > > >
> > > > The driver/subsystem could just store a timestamp in it's
> >
vices can start to be initialized) called from rest_init() via
> kernel_init_freeable() and do_basic_setup().
>
> Signed-off-by: Thara Gopinath
> [move from ktime to raw nsec]
> Signed-off-by: Vincent Guittot
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/bas
On Tue, 19 Apr 2022 at 15:37, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> This is the full series for converting OMAP1 to multiplatform, rebased
> from my 2019 attempt to do the same thing. The soc tree contains simpler
> patches to do the same for iop32x, ixp4xx, ep93xx and s3c24xx, which
>
s.
>
> Cc: Abel Vesa
> Cc: Stephen Boyd
> Cc: Krzysztof Kozlowski
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Jonathan Cameron
> Cc: Lars-Peter Clausen
> Cc: Ulf Hansson
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Miquel Raynal
> Cc: Richard
On Fri, 23 Sept 2022 at 14:47, Liu Ying wrote:
>
> After a device transitions to sleep state through it's system suspend
> callback pm_runtime_force_suspend(), the device's driver may still try
> to do runtime PM for the device(runtime suspend first and then runtime
> resume) although runtime PM i
On Fri, 23 Sept 2022 at 17:23, Liu Ying wrote:
>
> On Fri, 2022-09-23 at 15:48 +0200, Ulf Hansson wrote:
> > On Fri, 23 Sept 2022 at 14:47, Liu Ying wrote:
> > >
> > > After a device transitions to sleep state through it's system
> > > suspend
&g
On Thu, 12 Dec 2019 at 13:33, Thierry Reding wrote:
>
> On Thu, Dec 12, 2019 at 09:52:22AM +0100, Ulf Hansson wrote:
> > On Mon, 9 Dec 2019 at 14:03, Thierry Reding
> > wrote:
> > >
> > > From: Thierry Reding
> > >
> > > The Tegra DRM dr
On Mon, 9 Dec 2019 at 14:03, Thierry Reding wrote:
>
> From: Thierry Reding
>
> The Tegra DRM driver heavily relies on the implementations for runtime
> suspend/resume to be called at specific times. Unfortunately, there are
> some cases where that doesn't work. One example is if the user disable
On Thu, 12 Dec 2019 at 17:48, Rafael J. Wysocki wrote:
>
> On Thu, Dec 12, 2019 at 2:32 PM Ulf Hansson wrote:
> >
> > On Thu, 12 Dec 2019 at 13:33, Thierry Reding
> > wrote:
> > >
> > > On Thu, Dec 12, 2019 at 09:52:22AM +0100, Ulf Hansson wrote:
&g
hael Turquette
> Cc: Stephen Boyd
> Cc: Viresh Kumar
> Cc: Dmitry Torokhov
> Cc: Jacek Anaszewski
> Cc: Pavel Machek
> Cc: Ulf Hansson
> Cc: Dominik Brodowski
> Cc: Alexandre Belloni
> Cc: Greg Kroah-Hartman
> Cc: Guenter Roeck
> Cc: Mark Brown
> Cc: linux-
ple domains, as in MT8183 Bifrost
> GPU, we need to handle them in driver code.
>
> Signed-off-by: Nicolas Boichat
Besides a minor nitpick, feel free to add:
Reviewed-by: Ulf Hansson
Kind regards
Uffe
>
> ---
>
> The downstream driver we use on chromeos-4.19 currently uses 2
On Sun, 9 Feb 2020 at 13:50, Nicolas Boichat wrote:
>
> On Fri, Feb 7, 2020 at 10:26 PM Ulf Hansson wrote:
> >
> > On Fri, 7 Feb 2020 at 06:27, Nicolas Boichat wrote:
> > >
> > > When there is a single power domain per device, the core will
> > > ens
On Wed, 11 Mar 2020 at 08:40, Miquel Raynal wrote:
>
> Hi Joe,
>
> Joe Perches wrote on Tue, 10 Mar 2020 21:51:27 -0700:
>
> > Convert the various uses of fallthrough comments to fallthrough;
> >
> > Done via script
> > Link:
> > https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d39
On Fri, 10 Jan 2020 at 02:53, Nicolas Boichat wrote:
>
> +Ulf to keep me honest on the power domains
>
> On Thu, Jan 9, 2020 at 10:08 PM Steven Price wrote:
> >
> > On 08/01/2020 05:23, Nicolas Boichat wrote:
> > > When there is a single power domain per device, the core will
> > > ensure the pow
lthough, I have to
admit that I am still learning about the DT json-schema. So, FWIW:
Reviewed-by: Ulf Hansson
Kind regards
Uffe
>
> ---
>
> Changes since v1:
> 1. Select all nodes for consumers,
> 2. Remove from consumers duplicated properties with dt-schema,
> 3. Fix power
ars-Peter Clausen
> Cc: Thomas Gleixner
> Cc: Marc Zyngier
> Cc: Joerg Roedel
> Cc: Jassi Brar
> Cc: Mauro Carvalho Chehab
> Cc: Krzysztof Kozlowski
> Cc: Ulf Hansson
> Cc: Jakub Kicinski
> Cc: Wolfgang Grandegger
> Cc: Marc Kleine-Budde
> Cc: Andrew Lunn
>
resent.
>
> Add unevaluatedProperties or additionalProperties as appropriate, and
> then add any missing properties flagged by the addition.
>
> Signed-off-by: Rob Herring
Acked-by: Ulf Hansson # For MMC
Kind regards
Uffe
> ---
> To: Krzysztof Kozlowski
> To: David Airlie
> To: Dani
t; Cc: Heiko Carstens
> Cc: Helge Deller
> Cc: Herbert Xu
> Cc: Huacai Chen
> Cc: Hugh Dickins
> Cc: Jakub Kicinski
> Cc: James E.J. Bottomley
> Cc: Jan Kara
> Cc: Jason Gunthorpe
> Cc: Jens Axboe
> Cc: Johannes Berg
> Cc: Jonathan Corbet
> Cc: Jozsef K
.
>
> And if it was an oversight, then we are at least explicit about our
> behavior now and it can be further refined down the line.
>
> Signed-off-by: Maxime Ripard
Seems reasonable to me!
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/clk/ux500/clk-sysctrl
On Thu, 10 Nov 2022 at 12:39, Linus Walleij wrote:
>
> On Thu, Nov 10, 2022 at 12:29 PM Ulf Hansson wrote:
> > On Fri, 4 Nov 2022 at 14:32, Maxime Ripard wrote:
> > >
> > > The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent
> >
On Wed, 5 Oct 2022 at 11:08, Akhil P Oommen wrote:
>
> Add a reset op compatible function to poll for gdsc collapse. This is
> required because:
> 1. We don't wait for it to turn OFF at hardware for VOTABLE GDSCs.
> 2. There is no way for client drivers (eg. gpu driver) to do
> put-with-wait
On Wed, 5 Oct 2022 at 11:08, Akhil P Oommen wrote:
>
> Allow a consumer driver to poll for cx gdsc collapse through Reset
> framework.
Would you mind extending this commit message, to allow us to better
understand what part is really the consumer part.
I was expecting the consumer part to be the
On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson wrote:
>
> On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote:
> >
>
> @Ulf, Akhil has a power-domain for a piece of hardware which may be
> voted active by multiple different subsystems (co-processors/execution
> contexts) in the system.
>
On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote:
>
> On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Hansson wrote:
> > On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson wrote:
> > >
> > > On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote:
> > >
On Thu, 8 Dec 2022 at 22:06, Bjorn Andersson wrote:
>
> On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote:
> > On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote:
> > >
> > > On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Hansson wrote:
> > &g
On Fri, 9 Dec 2022 at 18:36, Ulf Hansson wrote:
>
> On Thu, 8 Dec 2022 at 22:06, Bjorn Andersson wrote:
> >
> > On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote:
> > > On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote:
> > > >
> > >
On Tue, 20 Dec 2022 at 08:44, Akhil P Oommen wrote:
>
> From: Ulf Hansson
>
> Some genpd providers doesn't ensure that it has turned off at hardware.
> This is fine until the consumer really requires during some special
> scenarios that the power domain collapse at hardwar
> Signed-off-by: Akhil P Oommen
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Rename the var 'force_sync' to 'wait (Stephen)
>
> drivers/clk/qcom/gdsc.c | 11 ++-
> 1 file changed, 6 in
sing
> genpd framework will be implemented in the upcoming patch.
>
> This effectively reverts commit 1f6cca404918
> ("drm/msm/a6xx: Ensure CX collapse during gpu recovery").
>
> Signed-off-by: Akhil P Oommen
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
>
fier along with the newly introduced
> dev_pm_genpd_synced_poweroff() api to ensure that cx gdsc has collapsed
> before we turn it back ON.
>
> Signed-off-by: Akhil P Oommen
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
>
> (no changes since v2)
>
> Changes in v2:
ctive 0
> cx_gdsc on 0
> /devices/platform/soc@0/3da.iommu active 0
> /devices/genpd:0:3d6a000.gmu active 0
>
> Signed-off-by: Akhil P Oommen
Reviewed-by: Ulf Hansson
Kind regards
Uff
e situtation better and
> solves the immediate issue.
>
> Fixes: 92bf78b33b0b ("gpio: omap: use dynamic allocation of base")
> Signed-off-by: Linus Walleij
This looks like it's best funneled through the soc maintainer's tree(s), right?
Acked-by: Ulf Han
ower_off_work);
>^
> drivers/base/power/domain.c:853:26: error: no member named 'ignore_children'
> in 'struct dev_pm_info'
> if (!dev || dev->power.ignore_children)
> ~~ ^
>
> Fixes: c11fa1204fe9
ler and resumes later than the panel device, hence resolves
> problems where the order is reversed, like the problematic case mentioned
> in the below link.
>
> Link:
> https://lore.kernel.org/lkml/capdykfr0xjru_udkoukq_q8rwaukyql+8fv-7s1ctmqi7u3...@mail.gmail.com/T/
> Suggested-by:
c: Alex Deucher
Cc: Christian König
Cc: Maruthi Srinivas Bayyavarapu
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ulf Hansson
---
Changes in v2:
- Updated changelog.
- Added a fix in the AMD ACP (Audio CoProcessor) drm driver, which
registers a ge
lback invokes pm_generic_resume(), while
it should be pm_generic_restore(). Let's fix this as well.
Signed-off-by: Ulf Hansson
---
Changes in v2:
- Updated changelog.
---
drivers/base/power/domain.c | 203 +++-
1 file changed, 12 insertions(+), 191
ch is actually fixing a bug while it also enables for further clean-ups,
which is done in the second patch.
The next step of improving system PM code in genpd will move it to the part of
trying to optimize the behaviour, such as avoid waking up devices unless it's
really needed.
Ulf Hansson
On 11 May 2016 at 23:25, Rafael J. Wysocki wrote:
> On Wed, May 11, 2016 at 10:00 AM, Ulf Hansson
> wrote:
>> If the PM domain is powered off when the first device in the domain starts
>> its system PM prepare phase, genpd prevents any further attempts to power
>> on
1 - 100 of 149 matches
Mail list logo
