All of lore.kernel.org
 help / color / mirror / Atom feed
From: bilhuang <bilhuang@nvidia.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Stephen Warren <swarren@wwwdotorg.org>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] cpufreq: tegra: Re-model Tegra cpufreq driver
Date: Thu, 19 Dec 2013 13:57:33 +0800	[thread overview]
Message-ID: <52B28ACD.5080204@nvidia.com> (raw)
In-Reply-To: <CAKohpo=fJTLrN6myq5b9FTSro1m9oN3ep-aMu-3iv0J-S6TpdQ@mail.gmail.com>

On 12/19/2013 01:29 PM, Viresh Kumar wrote:
> On 19 December 2013 10:56, bilhuang <bilhuang@nvidia.com> wrote:
>> I'm not sure virtual regulator for CPU is a good idea, in addition to that,
>> we don't have a single SoC OPP table, we need several which are speedo-id
>> and process-id dependant, but generic cpufreq-cpu0 is assuming there is only
>> one statically
>
> Can't that be handled via DT ?
I don't think it can be handled via DT unless we separate DTB according 
to different CPU speedo/process-id but that is not a good idea.
>
>> for some SoC the frequency table is not fixed, they are
>> created at runtime combining our fast and slow CPU frequency table and dvfs
>> table. So I'm really not sure is it worth adding so many tweaks in order to
>> use the generic cpufreq-cpu0 driver.
>
> Hmm, maybe I got confused because I don't have a clear picture in my mind.
> It might be better to go ahead with your implementation for now and after
> everything is set, we can choose to use cpufreq-cpu0 if it is worth it.
>
This makes more sense to me, thanks.
> --
> viresh
>


  reply	other threads:[~2013-12-19  5:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05  7:44 [PATCH v3 0/2] Remodel Tegra cpufreq drivers to support Tegra series SoC Bill Huang
2013-12-05  7:44 ` Bill Huang
2013-12-05  7:44 ` [PATCH v3 1/2] cpufreq: tegra: Call tegra_cpufreq_init() specifically in machine code Bill Huang
2013-12-05  7:44   ` Bill Huang
2013-12-05 22:54   ` Stephen Warren
2013-12-09  8:41     ` bilhuang
2013-12-17  6:31   ` Viresh Kumar
2013-12-17 10:48     ` bilhuang
2013-12-05  7:44 ` [PATCH v3 2/2] cpufreq: tegra: Re-model Tegra cpufreq driver Bill Huang
2013-12-05  7:44   ` Bill Huang
     [not found]   ` <1386229462-3474-3-git-send-email-bilhuang-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-12-05 23:04     ` Stephen Warren
2013-12-05 23:04       ` Stephen Warren
2013-12-09  8:44       ` bilhuang
2013-12-09 17:32         ` Stephen Warren
2013-12-11 11:18           ` bilhuang
2013-12-11 18:39             ` Stephen Warren
2013-12-17  6:54   ` Viresh Kumar
2013-12-17 10:52     ` bilhuang
2013-12-18 11:11       ` Viresh Kumar
2013-12-18 11:33         ` bilhuang
     [not found]           ` <52B187F5.7020105-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-12-18 14:39             ` Viresh Kumar
2013-12-18 14:39               ` Viresh Kumar
2013-12-19  5:26               ` bilhuang
     [not found]                 ` <52B28397.5010808-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-12-19  5:29                   ` Viresh Kumar
2013-12-19  5:29                     ` Viresh Kumar
2013-12-19  5:57                     ` bilhuang [this message]
     [not found] ` <1386229462-3474-1-git-send-email-bilhuang-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-12-17  6:26   ` [PATCH v3 0/2] Remodel Tegra cpufreq drivers to support Tegra series SoC Viresh Kumar
2013-12-17  6:26     ` Viresh Kumar
     [not found]     ` <CAKohponJAU20MQ92y4VaOXbsOOmxz6K=349KCq91c5=P=zQOQQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-17 10:47       ` bilhuang
2013-12-17 10:47         ` bilhuang
2013-12-17 10:51         ` Viresh Kumar

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=52B28ACD.5080204@nvidia.com \
    --to=bilhuang@nvidia.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    --cc=viresh.kumar@linaro.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.