All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Tomeu Vizoso
	<tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Javier Martinez Canillas
	<javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Peter De Schrijver
	<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 0/3] Add support for Tegra Activity Monitor
Date: Fri, 7 Nov 2014 18:07:24 +0900	[thread overview]
Message-ID: <545C8BCC.3090908@nvidia.com> (raw)
In-Reply-To: <1414594232-15684-1-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>

On 10/29/2014 11:50 PM, Tomeu Vizoso wrote:
> Hello,
>
> these patches implement support for setting the rate of the EMC clock based on
> stats collected from the ACTMON, a piece of hw in the Tegra124 that counts
> memory accesses (among others).
>
> It depends on the following in-flight patches:
>
> * MC driver: http://thread.gmane.org/gmane.linux.ports.tegra/19623
> * EMC driver: http://thread.gmane.org/gmane.linux.ports.arm.kernel/365125
> * CPUFreq driver: http://thread.gmane.org/gmane.linux.kernel/1812962
>
> I have pushed a branch here for testing:

I am not too familiar with DVFS, but after going through this series it 
really seems to me that this could use devfreq. In its current form this 
driver mixes control and policy and lacks flexibility, preventing e.g. 
to switch to a performance or power-saving profile. Could you study the 
feasibility of using devfreq for this?

I also wonder if this driver could not be made more flexible generally 
speaking - right now it is hardcoded that you can only control EMC 
frequency with it. I can imagine that we could want to control several 
clocks using the same counter information, and that e.g. a notifier 
block might help with that. But let's keep that for later - whether to 
use devfreq or not seems to be the most important question for now.

WARNING: multiple messages have this Message-ID (diff)
From: acourbot@nvidia.com (Alexandre Courbot)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] Add support for Tegra Activity Monitor
Date: Fri, 7 Nov 2014 18:07:24 +0900	[thread overview]
Message-ID: <545C8BCC.3090908@nvidia.com> (raw)
In-Reply-To: <1414594232-15684-1-git-send-email-tomeu.vizoso@collabora.com>

On 10/29/2014 11:50 PM, Tomeu Vizoso wrote:
> Hello,
>
> these patches implement support for setting the rate of the EMC clock based on
> stats collected from the ACTMON, a piece of hw in the Tegra124 that counts
> memory accesses (among others).
>
> It depends on the following in-flight patches:
>
> * MC driver: http://thread.gmane.org/gmane.linux.ports.tegra/19623
> * EMC driver: http://thread.gmane.org/gmane.linux.ports.arm.kernel/365125
> * CPUFreq driver: http://thread.gmane.org/gmane.linux.kernel/1812962
>
> I have pushed a branch here for testing:

I am not too familiar with DVFS, but after going through this series it 
really seems to me that this could use devfreq. In its current form this 
driver mixes control and policy and lacks flexibility, preventing e.g. 
to switch to a performance or power-saving profile. Could you study the 
feasibility of using devfreq for this?

I also wonder if this driver could not be made more flexible generally 
speaking - right now it is hardcoded that you can only control EMC 
frequency with it. I can imagine that we could want to control several 
clocks using the same counter information, and that e.g. a notifier 
block might help with that. But let's keep that for later - whether to 
use devfreq or not seems to be the most important question for now.

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Courbot <acourbot@nvidia.com>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	<linux-kernel@vger.kernel.org>
Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
	<devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-tegra@vger.kernel.org>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Stephen Warren <swarren@nvidia.com>,
	Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH 0/3] Add support for Tegra Activity Monitor
Date: Fri, 7 Nov 2014 18:07:24 +0900	[thread overview]
Message-ID: <545C8BCC.3090908@nvidia.com> (raw)
In-Reply-To: <1414594232-15684-1-git-send-email-tomeu.vizoso@collabora.com>

On 10/29/2014 11:50 PM, Tomeu Vizoso wrote:
> Hello,
>
> these patches implement support for setting the rate of the EMC clock based on
> stats collected from the ACTMON, a piece of hw in the Tegra124 that counts
> memory accesses (among others).
>
> It depends on the following in-flight patches:
>
> * MC driver: http://thread.gmane.org/gmane.linux.ports.tegra/19623
> * EMC driver: http://thread.gmane.org/gmane.linux.ports.arm.kernel/365125
> * CPUFreq driver: http://thread.gmane.org/gmane.linux.kernel/1812962
>
> I have pushed a branch here for testing:

I am not too familiar with DVFS, but after going through this series it 
really seems to me that this could use devfreq. In its current form this 
driver mixes control and policy and lacks flexibility, preventing e.g. 
to switch to a performance or power-saving profile. Could you study the 
feasibility of using devfreq for this?

I also wonder if this driver could not be made more flexible generally 
speaking - right now it is hardcoded that you can only control EMC 
frequency with it. I can imagine that we could want to control several 
clocks using the same counter information, and that e.g. a notifier 
block might help with that. But let's keep that for later - whether to 
use devfreq or not seems to be the most important question for now.

  parent reply	other threads:[~2014-11-07  9:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-29 14:50 [PATCH 0/3] Add support for Tegra Activity Monitor Tomeu Vizoso
2014-10-29 14:50 ` Tomeu Vizoso
2014-10-29 14:50 ` [PATCH 1/3] of: Add binding for NVIDIA Tegra ACTMON node Tomeu Vizoso
2014-10-29 14:50 ` [PATCH 2/3] soc/tegra: add support for Tegra Activity Monitor Tomeu Vizoso
2014-10-29 14:50 ` [PATCH 3/3] ARM: tegra: Add Tegra124 ACTMON support Tomeu Vizoso
2014-10-29 14:50   ` Tomeu Vizoso
     [not found] ` <1414594232-15684-1-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2014-11-07  9:07   ` Alexandre Courbot [this message]
2014-11-07  9:07     ` [PATCH 0/3] Add support for Tegra Activity Monitor Alexandre Courbot
2014-11-07  9:07     ` Alexandre Courbot
     [not found]     ` <545C8BCC.3090908-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-11-07 12:35       ` Tomeu Vizoso
2014-11-07 12:35         ` Tomeu Vizoso
2014-11-07 12:35         ` Tomeu Vizoso
     [not found]         ` <545CBC87.7050404-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2014-11-11  4:29           ` Alexandre Courbot
2014-11-11  4:29             ` Alexandre Courbot
2014-11-11  4:29             ` Alexandre Courbot
     [not found]             ` <546190BA.7050502-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-11-11  6:57               ` Terje Bergström
2014-11-11  6:57                 ` Terje Bergström
2014-11-11  6:57                 ` Terje Bergström
2014-11-11  7:32                 ` Alexandre Courbot
2014-11-11  7:32                   ` Alexandre Courbot
2014-11-11  7:32                   ` Alexandre Courbot
2014-11-11  8:40             ` Tomeu Vizoso
2014-11-11  8:40               ` Tomeu Vizoso

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=545C8BCC.3090908@nvidia.com \
    --to=acourbot-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org \
    --cc=treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.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.