All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter De Schrijver <pdeschrijver@nvidia.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: Device tree binding for DVFS table
Date: Wed, 11 Jul 2012 13:49:00 +0000	[thread overview]
Message-ID: <20120711134900.GA9437@tbergstrom-lnx.Nvidia.com> (raw)
In-Reply-To: <20748722.319671342012092123.JavaMail.weblogic@epml17>

On Wed, Jul 11, 2012 at 03:08:14PM +0200, 함명주 wrote:
> > Hi,
> >
> > I am working on DT binding for Tegra DVFS.
> >
> > For Tegra, DVFS node mainly consists of frequency and voltage pairs. 
> > Frequency in the pair may change for different process. E.g. for process 
> > 1 CPU clock frequency could be 900MHz at 1V while for process 2 it could 
> > be 1GHz at 1V.
> > Tegra uses vendor specific ids to identify the correct frequency table.
> 
> Hello,
> 
> It seems that in the example, the values in "voltage-array" and
> "frequencies" are switched.
> 
> Anyway, what about SoCs that reads information from IEM (or any other module)
>  to measure gate delays or some other value to set the appriorate voltage values
>  for every possible frequency? I remember some of Exynos SoCs have been doing
>  it; dynamically measure the characteristics at boot-up time and apply voltages
>  accordingly; they couldn't identify it based on the chip-id or simply by reading
>  a single register.

But in that case you would have a nominal voltage for each OPP which gets
adjusted at boottime or runtime depending on the exact silicon characteristics?
I would say the DT binding should then specify 1 table with the nominal values
and leave the dynamics to the driver.

Cheers,

Peter.

WARNING: multiple messages have this Message-ID (diff)
From: pdeschrijver@nvidia.com (Peter De Schrijver)
To: linux-arm-kernel@lists.infradead.org
Subject: Device tree binding for DVFS table
Date: Wed, 11 Jul 2012 16:49:00 +0300	[thread overview]
Message-ID: <20120711134900.GA9437@tbergstrom-lnx.Nvidia.com> (raw)
In-Reply-To: <20748722.319671342012092123.JavaMail.weblogic@epml17>

On Wed, Jul 11, 2012 at 03:08:14PM +0200, ??? wrote:
> > Hi,
> >
> > I am working on DT binding for Tegra DVFS.
> >
> > For Tegra, DVFS node mainly consists of frequency and voltage pairs. 
> > Frequency in the pair may change for different process. E.g. for process 
> > 1 CPU clock frequency could be 900MHz at 1V while for process 2 it could 
> > be 1GHz at 1V.
> > Tegra uses vendor specific ids to identify the correct frequency table.
> 
> Hello,
> 
> It seems that in the example, the values in "voltage-array" and
> "frequencies" are switched.
> 
> Anyway, what about SoCs that reads information from IEM (or any other module)
>  to measure gate delays or some other value to set the appriorate voltage values
>  for every possible frequency? I remember some of Exynos SoCs have been doing
>  it; dynamically measure the characteristics at boot-up time and apply voltages
>  accordingly; they couldn't identify it based on the chip-id or simply by reading
>  a single register.

But in that case you would have a nominal voltage for each OPP which gets
adjusted at boottime or runtime depending on the exact silicon characteristics?
I would say the DT binding should then specify 1 table with the nominal values
and leave the dynamics to the driver.

Cheers,

Peter.

  reply	other threads:[~2012-07-11 13:49 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-11 13:08 Device tree binding for DVFS table 함명주
2012-07-11 13:08 ` 함명주
2012-07-11 13:49 ` Peter De Schrijver [this message]
2012-07-11 13:49   ` Peter De Schrijver
2012-07-11 13:49 ` Peter De Schrijver
2012-07-11 13:49   ` Peter De Schrijver
2012-07-12  4:22   ` Prashant Gaikwad
2012-07-12  4:34     ` Prashant Gaikwad
  -- strict thread matches above, loose matches on Subject: below --
2012-07-11 12:56 Prashant Gaikwad
2012-07-11 13:08 ` Prashant Gaikwad
2012-07-11 14:03 ` Rob Herring
2012-07-11 14:03   ` Rob Herring
2012-07-11 14:44   ` Mark Brown
2012-07-11 14:44     ` Mark Brown
2012-07-11 20:04     ` Mike Turquette
2012-07-11 20:04       ` Mike Turquette
2012-07-12  4:14       ` Prashant Gaikwad
2012-07-12  4:26         ` Prashant Gaikwad
2012-07-12 14:10       ` Peter De Schrijver
2012-07-12 14:10         ` Peter De Schrijver
2012-07-12 17:10         ` Mike Turquette
2012-07-12 17:10           ` Mike Turquette
2012-07-12 17:15           ` Mark Brown
2012-07-12 17:15             ` Mark Brown
2012-07-13 10:34           ` Peter De Schrijver
2012-07-13 10:34             ` Peter De Schrijver
2012-07-13 17:25             ` Mike Turquette
2012-07-13 17:25               ` Mike Turquette
2012-07-12  4:17     ` Prashant Gaikwad
2012-07-12  4:29       ` Prashant Gaikwad
2012-07-12 15:23       ` Mark Brown
2012-07-12 15:23         ` Mark Brown
2012-07-12 17:01       ` Mike Turquette
2012-07-12 17:01         ` Mike Turquette
2012-07-12  8:19     ` Peter De Schrijver
2012-07-12  8:19       ` Peter De Schrijver
2012-07-12  4:08   ` Prashant Gaikwad
2012-07-12  4:20     ` Prashant Gaikwad
2012-07-13 18:30     ` Prashant Gaikwad
2012-07-13 18:42       ` Prashant Gaikwad
2012-07-15 21:40       ` Mark Brown
2012-07-15 21:40         ` Mark Brown
2012-07-15 23:42     ` Rob Herring
2012-07-15 23:42       ` Rob Herring
2012-07-16 18:36       ` Turquette, Mike
2012-07-16 18:36         ` Turquette, Mike
2012-07-17 12:37         ` Prashant Gaikwad
2012-07-17 12:49           ` Prashant Gaikwad
2012-07-17 13:20           ` Mark Brown
2012-07-17 13:20             ` Mark Brown
2012-07-17 14:22             ` Prashant Gaikwad
2012-07-17 14:34               ` Prashant Gaikwad
2012-07-17 14:37               ` Mark Brown
2012-07-17 14:37                 ` Mark Brown
2012-07-18 12:46                 ` Prashant Gaikwad
2012-07-18 12:58                   ` Prashant Gaikwad
2012-07-18 21:19                   ` Mark Brown
2012-07-18 21:19                     ` Mark Brown
2012-07-18 17:08 ` Shawn Guo
2012-07-18 17:08   ` Shawn Guo

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=20120711134900.GA9437@tbergstrom-lnx.Nvidia.com \
    --to=pdeschrijver@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.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.