From: Philip Balister <philip@balister.org>
To: Paul Walmsley <paul@pwsan.com>
Cc: Kyungmin Park <kmpark@infradead.org>,
linux-omap@vger.kernel.org, lethal@linux-sh.org
Subject: Re: [PATCH] IRQ: simplify OMAP2 mask_irq/unmask_irq code
Date: Tue, 20 May 2008 20:39:24 -0400 [thread overview]
Message-ID: <48336F3C.5040004@balister.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0805201802040.9463@utopia.booyaka.com>
[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]
Paul Walmsley wrote:
> Hello Kyungmin,
>
> On Wed, 21 May 2008, Kyungmin Park wrote:
>
>> On Wed, May 21, 2008 at 3:21 AM, Paul Walmsley <paul@pwsan.com> wrote:
>>> static void omap_mask_irq(unsigned int irq)
>>> {
>>> - int offset = (irq >> 5) << 5;
>>> + int offset = irq & (~(IRQ_BITS_PER_REG - 1));
>>>
>>> - if (irq >= 64)
>>> - irq %= 64;
>>> - else if (irq >= 32)
>>> - irq %= 32;
>>> + irq %= IRQ_BITS_PER_REG;
>> Is it the right conversion?
>> If the irq is greater then 32 and less then or equal to 64 it's
>> result is different.
>> E.g, If irq is 63 then original irq is 63, but new code is 31
>
> Hmm, in that condition, the result looks the same to me: irq % 32, either
> way?
>
> More practically, if you look at what it does with that irq variable
> afterwards, it seems to be a bug if irq is ever greater than 31:
>
> intc_bank_write_reg(1 << irq, &irq_banks[0], INTC_MIR_CLEAR0 +
> offset);
>
> I think the only case where the new code would work differently than the
> previous code is if irq > 95. But that would be a bug, since the shift
> value would then be > 32, for a 32-bit register.
>
>> And if this code is right, how about to use mask instead of modulo op?
>> irq &= (IRQ_BITS_PER_REG - 1);
>
> Hehe, very good point, that would probably save even more cycles! If you
> agree with the above, perhaps I can convert the code to use that also,
> and add your Signed-off-by also?
On some code where I used % to detect a counter passing multiples of a
certain number, oprofile revealed that the % operator burned a lot of
CPU cycles. I suspect this had to do with the counter increasing to very
large numbers, but ever since, I've tried to avoid the % operator in
critical paths.
Philip
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]
next prev parent reply other threads:[~2008-05-21 0:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-20 18:21 [PATCH] IRQ: simplify OMAP2 mask_irq/unmask_irq code Paul Walmsley
2008-05-20 23:18 ` Kyungmin Park
2008-05-21 0:12 ` Paul Walmsley
2008-05-21 0:39 ` Philip Balister [this message]
2008-05-21 0:52 ` Kyungmin Park
2008-05-21 0:55 ` Paul Mundt
2008-05-21 1:19 ` Paul Walmsley
-- strict thread matches above, loose matches on Subject: below --
2008-05-21 1:19 Paul Walmsley
2008-05-21 15:05 ` Tony Lindgren
2008-05-21 19:15 ` Paul Walmsley
2008-05-22 19:50 ` Tony Lindgren
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=48336F3C.5040004@balister.org \
--to=philip@balister.org \
--cc=kmpark@infradead.org \
--cc=lethal@linux-sh.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.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.