From: Kevin Hilman <khilman@deeprootsystems.com>
To: Romit Dasgupta <romit@ti.com>
Cc: "Reddy, Teerth" <teerth@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH] OMAP3: PM: Dynamic calculation of SDRC clock stabilization delay
Date: Mon, 14 Dec 2009 08:10:45 -0800 [thread overview]
Message-ID: <873a3dfse2.fsf@deeprootsystems.com> (raw)
In-Reply-To: <4B25FF04.4040306@ti.com> (Romit Dasgupta's message of "Mon\, 14 Dec 2009 14\:31\:56 +0530")
Romit Dasgupta <romit@ti.com> writes:
> Kevin Hilman wrote:
>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>>
>> [...]
>>
>>> PMC code is ARM generic and already largely exists in other places
>>> (oprofile for one.) So the use of the PMC will need to be generalized
>>> as well as be shown not to interfere with other users (as raised
>>> already by Jean Pihet.)
>>
>> Someone is already trying to generalize a PMC interface. You might want
>> to follow this thread:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005898.html
>>
>
> I tried to find the code in LO but I think it is not yet present.
Right, it is still being discussed.
> So with that in mind may I propose that the pmc functions we
> introduce in plat-omap will be present as __init code (so that we
> ensure no one uses it after the system finishes booting up) as long
> as the pmc infrastructure is not available for non-Oprofile uses?
Personally, I don't like this idea.
IMHO, the PMC is not OMAP specific and does not belong in plat-omap
even as init code. Either generalize and use existing PMC
infrastructure, or use a different timer.
You didn't answer my other question about whether or not a GPtimer
could be used for this. You could quickly request/program/free a
GPtimer for this too using the omap_dm_timer* API.
> As I mentioned in an earlier thread, the pmc is used and stopped
> very early during the kernel boot and AFAICT there should not be any
> problem (probably we need to check its behavior on EMU/HS devices).
This isn't very convicing.
Also, it's not just oprofile we have to be worried about. The
perf/trace infrastructure arm is also using the PMC. It will not be
uncommon to use perf on early boot/init and the use of the PMC in this
patch will clearly interfere with that.
In summary, the PMC is a shared resource and should be treated as such
using common code and common APIs.
Kevin
next prev parent reply other threads:[~2009-12-14 16:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-11 12:05 [PATCH] OMAP3: PM: Dynamic calculation of SDRC clock stabilization delay Reddy, Teerth
2009-12-11 12:23 ` Menon, Nishanth
2009-12-11 12:31 ` Romit Dasgupta
2009-12-11 13:42 ` Nishanth Menon
2009-12-12 4:43 ` Nishanth Menon
2009-12-14 8:19 ` Romit Dasgupta
2009-12-11 13:14 ` Jean Pihet
2009-12-11 14:07 ` Romit Dasgupta
2009-12-11 16:38 ` Kevin Hilman
2009-12-12 0:49 ` Kevin Hilman
2009-12-14 9:01 ` Romit Dasgupta
2009-12-14 16:10 ` Kevin Hilman [this message]
2009-12-14 16:41 ` Dasgupta, Romit
2009-12-14 19:34 ` Kevin Hilman
2009-12-21 11:44 ` Reddy, Teerth
2009-12-22 15:56 ` Kevin Hilman
2009-12-22 16:00 ` Sripathy, Vishwanath
2009-12-22 16:56 ` Kevin Hilman
-- strict thread matches above, loose matches on Subject: below --
2009-12-24 5:33 Reddy, Teerth
2009-12-24 10:31 ` Romit Dasgupta
2009-12-28 19:57 ` Tony Lindgren
2010-01-06 23:06 ` Kevin Hilman
2010-01-21 5:35 ` Paul Walmsley
2010-01-21 8:58 ` Reddy, Teerth
2010-02-08 22:52 ` Paul Walmsley
2009-12-23 13:56 Reddy, Teerth
2009-12-23 14:32 ` Romit Dasgupta
2009-12-24 5:31 ` Reddy, Teerth
2009-12-11 12:42 Romit Dasgupta
2009-12-11 10:35 Reddy, Teerth
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=873a3dfse2.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=romit@ti.com \
--cc=teerth@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 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.