public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Nayak, Rajendra" <rnayak@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 0/3] OMAP3: PM: Make PRM setup times and CPUidle latencies/threshold board specific
Date: Tue, 13 Oct 2009 12:31:33 -0700	[thread overview]
Message-ID: <87bpkbjdka.fsf@deeprootsystems.com> (raw)
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB030A3D1009@dbde02.ent.ti.com> (Rajendra Nayak's message of "Mon\, 12 Oct 2009 19\:11\:07 +0530")

"Nayak, Rajendra" <rnayak@ti.com> writes:

> The setup times to be programmed in the PRM module on OMAP (for
> clksetup, voltsetup etc) are board specific. They depend heavily on
> the PMIC used and even on different boards with the same PMIC, they
> vary based on the sleep/wake sequence used, system clock speed et
> al.
>
> The CPUidle latencies and hence thresholds (derived from latencies
> and Power consumption numbers) and very much dependent on these
> setup values and hence also need to be board specific.
>
> This patchset makes it possible for the PRM setup times and the
> CPUidle latencies/threshold numbers to be configured from board
> files, and some default values are used if nothing gets passed from
> board files.
>
> Only the 3430SDP board file is currently been modifed to pass these
> values and the rest of the 3430 based board's still pass NULL and
> hence use the default values defined.

Hi Rajendra,

Thanks for making these changes.  I'm very much for the approach
you've taken in these patches to make these more configurable.

One other comment that would require one more spin:

Since we may be moving the OPP tables from board code to SoC common code,
let's separate the rate tables from the VC and cpudle parameters.

How about an optional omap3_pm_init_vc() for the setup times. and
omap3_pm_init_cpuidle() for the CPUidle values.  This way only the
board files that don't want the defaults have to call them.

The other benefit of having optional calls is that we don't have to
keep touching every single board file to make these kinds of changes.

Thanks,

Kevin



  reply	other threads:[~2009-10-13 19:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-12 13:41 [PATCH 0/3] OMAP3: PM: Make PRM setup times and CPUidle latencies/threshold board specific Nayak, Rajendra
2009-10-13 19:31 ` Kevin Hilman [this message]
2009-10-14 12:10   ` Nayak, Rajendra

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=87bpkbjdka.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=rnayak@ti.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox