From: slapdau@yahoo•com.au (Craig McGeachie)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] irq: bcm2835: Re-implement the hardware IRQ handler.
Date: Wed, 02 Oct 2013 20:35:38 +1300 [thread overview]
Message-ID: <524BCCCA.4050105@yahoo.com.au> (raw)
In-Reply-To: <524B8117.9070309@wwwdotorg.org>
On 10/02/2013 03:12 PM, Stephen Warren wrote:
> On 09/26/2013 02:19 AM, Craig McGeachie wrote:
>> I don't understand the concern with re-reading two volatile registers
>> between each dispatch. Given the amount of processing that occurs
>> between the call to handle_IRQ and the calls to the possibly multiple
>> registered interrupt handlers, plus the processing that the handlers
>> perform (even if they are implemented as top/bottom halves), I think the
>> performance overhead of the two extra reads is vanishingly small. In
>> fact, I think that focusing on eliminating them is premature
>> optimisation. Developers are notoriously bad at identifying performance
>> hotspots through visual inspection.
>>
>> The point about the registers being volatile is important. It's a C
>> keyword for a very good reason.
>
> Volatile as a keyword isn't especially useful for registers though,
> since register IO tends to need various barriers as well, but anyway...
I agree. I hadn't really meant that the volatile would make register
reading correct. I really only meant it as a concept of values that
might be changed by something else unknown.
I'm still a little uncertain about the correct reading of registers,
especially here. I tried to get a good understanding of readl versus
readl_relaxed and what ordering guarantees were, or were not given.
About the only thing I am sure of is the requirements for wmb() and
rmb() given by section 1.3 of BCM2835_ARM_Peripherals.pdf. And I don't
know whether or not it should be applied to interrupt registers, or
whether the two different readl functions remove the need for explicit
barriers.
I do know that the barriers are required when you switch which
peripheral IO memory you are reading/writing, and I think the interrupt
controller counts as different to the various devices that the handlers
will be interacting with.
Cheers,
Craig.
next prev parent reply other threads:[~2013-10-02 7:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1379751251-2799-1-git-send-email-slapdau@yahoo.com.au>
[not found] ` <5e0b6222e8648fb0c63aa649ee70b29d11f4924f@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid>
2013-09-26 8:19 ` [PATCH] irq: bcm2835: Re-implement the hardware IRQ handler Craig McGeachie
2013-09-26 11:28 ` Simon Arlott
2013-10-02 2:12 ` Stephen Warren
2013-10-02 7:35 ` Craig McGeachie [this message]
2013-10-05 2:19 ` Craig McGeachie
[not found] ` <1379755112-19446-1-git-send-email-slapdau@yahoo.com.au>
2013-09-24 3:38 ` Stephen Warren
2013-09-24 8:09 ` Craig McGeachie
2013-10-02 2:01 ` Stephen Warren
2013-10-02 6:31 ` Craig McGeachie
2013-10-04 9:40 ` Craig McGeachie
2013-09-25 6:00 ` Craig McGeachie
2013-10-02 2:04 ` Stephen Warren
2013-10-02 7:25 ` Craig McGeachie
2013-09-27 9:57 ` [PATCH v3] irq: bmc2835: " Craig McGeachie
2013-10-02 2:23 ` Stephen Warren
2013-10-02 8:51 ` Craig McGeachie
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=524BCCCA.4050105@yahoo.com.au \
--to=slapdau@yahoo$(echo .)com.au \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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