All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	Ming Lei <ming.lei@canonical.com>,
	Woodruff Richard <r-woodruff2@ti.com>,
	Will Deacon <will.deacon@arm.com>,
	Benoit Cousson <b-cousson@ti.com>, Kevin Hilman <khilman@ti.com>
Subject: Re: [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
Date: Mon, 24 Sep 2012 14:46:10 -0500	[thread overview]
Message-ID: <5060B882.3060007@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1209201655060.12583@utopia.booyaka.com>


On 09/20/2012 11:59 AM, Paul Walmsley wrote:
> Hi
> 
> On Mon, 10 Sep 2012, Jon Hunter wrote:
> 
>> From: Ming Lei <ming.lei@canonical.com>
>>
>> For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be
>> routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to work
>> on OMAP4430.
>>
>> The idea is from Woodruff Richard in the disscussion about "Oprofile on
>> Pandaboard / Omap4" on pandaboard@googlegroups.com.
>>
>> Ming's original patch was called "arm: omap4: support pmu" [1] and has been
>> renamed and modified by Jon Hunter. There main differences from the original
>> patch are ...
>>
>> 1. Instead of only configuring the CTI interrupt once during boot, the
>>    interrupts are configured everytime the the PMU is used. The reason for this
>>    is because during power transitions the CTI logic state will be lost and so
>>    we will need to configure the interrupts everytime they are used. This is
>>    accomplished by using the PM runtime callbacks which will be called whenever
>>    the PMU is used.
>> 2. Assign the PMU events to different cross triggering channels. This prevents
>>    a single PMU event generating interrupts to both CPUs and hence can cause
>>    spurious interrupts to occur. Reported by Ming [2].
>>
>> [1] http://marc.info/?l=linux-arm-kernel&m=132227620816504&w=2
>> [2] http://permalink.gmane.org/gmane.linux.linaro.devel/10532
> 
> Spent some time with this one here.  At this point I don't think I can 
> queue it.  It's got hardcoded IRQ numbers and address information for the 
> CTI, and mixes the CTI and PMU programming.  A few months ago we might 
> have gotten away with this, but now it seems best to do this one cleanly.
> Probably the CTI control should be moved off into mach-omap2/omap4-cti.c 
> or somewhere into drivers/ if possible.  So let's revisit this for 3.8.

Ok, no problem, I can't say I was thrilled with the implementation so
probably best to re-think some more. How about adding the cross-trigger
interface as a hwmod for omap4 to store the base address and interrupt
number?

Cheers
Jon



WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
Date: Mon, 24 Sep 2012 14:46:10 -0500	[thread overview]
Message-ID: <5060B882.3060007@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1209201655060.12583@utopia.booyaka.com>


On 09/20/2012 11:59 AM, Paul Walmsley wrote:
> Hi
> 
> On Mon, 10 Sep 2012, Jon Hunter wrote:
> 
>> From: Ming Lei <ming.lei@canonical.com>
>>
>> For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be
>> routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to work
>> on OMAP4430.
>>
>> The idea is from Woodruff Richard in the disscussion about "Oprofile on
>> Pandaboard / Omap4" on pandaboard at googlegroups.com.
>>
>> Ming's original patch was called "arm: omap4: support pmu" [1] and has been
>> renamed and modified by Jon Hunter. There main differences from the original
>> patch are ...
>>
>> 1. Instead of only configuring the CTI interrupt once during boot, the
>>    interrupts are configured everytime the the PMU is used. The reason for this
>>    is because during power transitions the CTI logic state will be lost and so
>>    we will need to configure the interrupts everytime they are used. This is
>>    accomplished by using the PM runtime callbacks which will be called whenever
>>    the PMU is used.
>> 2. Assign the PMU events to different cross triggering channels. This prevents
>>    a single PMU event generating interrupts to both CPUs and hence can cause
>>    spurious interrupts to occur. Reported by Ming [2].
>>
>> [1] http://marc.info/?l=linux-arm-kernel&m=132227620816504&w=2
>> [2] http://permalink.gmane.org/gmane.linux.linaro.devel/10532
> 
> Spent some time with this one here.  At this point I don't think I can 
> queue it.  It's got hardcoded IRQ numbers and address information for the 
> CTI, and mixes the CTI and PMU programming.  A few months ago we might 
> have gotten away with this, but now it seems best to do this one cleanly.
> Probably the CTI control should be moved off into mach-omap2/omap4-cti.c 
> or somewhere into drivers/ if possible.  So let's revisit this for 3.8.

Ok, no problem, I can't say I was thrilled with the implementation so
probably best to re-think some more. How about adding the cross-trigger
interface as a hwmod for omap4 to store the base address and interrupt
number?

Cheers
Jon

  reply	other threads:[~2012-09-24 19:46 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-10 15:23 [PATCH V3 0/8] ARM: OMAP4: Add PMU Support Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data Jon Hunter
2012-09-10 15:23   ` Jon Hunter
2012-09-13  3:32   ` Jon Hunter
2012-09-13  3:32     ` Jon Hunter
2012-09-19 17:34   ` Paul Walmsley
2012-09-19 17:34     ` Paul Walmsley
2012-09-20 17:13     ` Paul Walmsley
2012-09-20 17:13       ` Paul Walmsley
2012-09-24 15:57       ` Jon Hunter
2012-09-24 15:57         ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 2/8] ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD Jon Hunter
2012-09-10 15:23   ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS Jon Hunter
2012-09-10 15:23   ` Jon Hunter
2012-09-20 17:00   ` Paul Walmsley
2012-09-20 17:00     ` Paul Walmsley
2012-09-10 15:23 ` [PATCH V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD Jon Hunter
2012-09-10 15:23   ` Jon Hunter
2012-09-20 17:14   ` Paul Walmsley
2012-09-20 17:14     ` Paul Walmsley
2012-09-10 15:23 ` [PATCH V3 5/8] ARM: OMAP2+: PMU: Add runtime PM support Jon Hunter
2012-09-10 15:23   ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs Jon Hunter
2012-09-10 15:23   ` Jon Hunter
2012-09-20 16:59   ` Paul Walmsley
2012-09-20 16:59     ` Paul Walmsley
2012-09-24 19:46     ` Jon Hunter [this message]
2012-09-24 19:46       ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 7/8] ARM: OMAP4: Enable PMU for OMAP4460/70 Jon Hunter
2012-09-10 15:23   ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint Jon Hunter
2012-09-10 15:23   ` Jon Hunter
2012-09-20 17:14   ` Paul Walmsley
2012-09-20 17:14     ` Paul Walmsley
2012-09-24 16:08     ` Jon Hunter
2012-09-24 16:08       ` Jon Hunter
2012-09-11  6:48 ` [PATCH V3 0/8] ARM: OMAP4: Add PMU Support Shilimkar, Santosh
2012-09-11  6:48   ` Shilimkar, Santosh
2012-09-20 17:17 ` Paul Walmsley
2012-09-20 17:17   ` Paul Walmsley
2012-09-20 17:39   ` Shilimkar, Santosh
2012-09-20 17:39     ` Shilimkar, Santosh
2012-09-20 17:43     ` Paul Walmsley
2012-09-20 17:43       ` Paul Walmsley
2012-09-20 17:52       ` Shilimkar, Santosh
2012-09-20 17:52         ` Shilimkar, Santosh
2012-09-20 21:09   ` Will Deacon
2012-09-20 21:09     ` Will Deacon
2012-09-24 21:45     ` Jon Hunter
2012-09-24 21:45       ` Jon Hunter
2012-10-01  9:45       ` Will Deacon
2012-10-01  9:45         ` Will Deacon
2012-10-01 15:03         ` Jon Hunter
2012-10-01 15:03           ` Jon Hunter
2012-09-24 21:43   ` Jon Hunter
2012-09-24 21:43     ` Jon Hunter

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=5060B882.3060007@ti.com \
    --to=jon-hunter@ti.com \
    --cc=b-cousson@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=paul@pwsan.com \
    --cc=r-woodruff2@ti.com \
    --cc=tony@atomide.com \
    --cc=will.deacon@arm.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.