From: Eugene Surovegin <ebs@ebshome.net>
To: "Barbier, Renaud (GE Infrastructure)" <Renaud.Barbier@ge.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 440GX interrupt
Date: Thu, 17 Feb 2005 14:54:14 -0800 [thread overview]
Message-ID: <20050217225414.GA32623@gate.ebshome.net> (raw)
In-Reply-To: <45ABD2373C33C4459D42B40EC4F346F205E1A4F0@FTWMLVEM03.e2k.ad.ge.com>
On Thu, Feb 17, 2005 at 03:50:27PM -0600, Barbier, Renaud (GE Infrastructure) wrote:
> I have a question regarding interrupt and irq locking.
> I derived (or copied from somehwere)a library (linux 2.4.26) for the 440GX from ppc4xx_pic.c to take care of the last interrupt register (UIC2).
> This a newbie question regarding get_irq/spin_lock
> here is get_irq:
> ...
> bits = mfdcr(DCRN_UIC_MSR(UICBASE));
> if ((bits & 0x40000000) == 0x40000000)
> {
> bits = mfdcr(DCRN_UIC_MSR(UIC0));
> irq = ( ffs(bits));
> irq = 32-irq;
> }
> ...
>
> my question is what guarantee that the code is executed atomically?
ppc_md.get_irq is called with hard irqs disabled, this makes
its execution context atomic.
> The reason I asked is that we have a driver that did the following in the ioctl call:
>
> disable_irq(26);
> /* do something */
> enable_irq(26);
>
> as you noticed there is not any spin_lock.
> Sometimes, this leads get_irq to see UICBASE indicating an irq in UIC0 and
> UIC0_MSR to return 0. hence you get irq 32 (MAL_SERR) and an infinite loop.
> My current fix is to use irqsave/irqrestore in the driver which I
> think is the correct way to do (but I may be wrong please help).
Yes, this is preferable to disable/enable_irq.
> However, I have a colleague (here is the human problem of my
> questions: him or me is the problem) that insists that I should do
> something in get_irq to have atomic execution.
No, it's already atomic.
Probably it's a race which cannot be avoided anyway because external
IRQs are completely async, and your version of ppc4xx_pic.c just has a
bug. I'll think about it a little more.
Could you try 2.6 version of ppc_4xx_pic.c? I don't think 2.4 has any
official support for UIC2 anyway.
--
Eugene.
next prev parent reply other threads:[~2005-02-17 22:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-17 21:50 440GX interrupt Barbier, Renaud (GE Infrastructure)
2005-02-17 22:54 ` Eugene Surovegin [this message]
2005-02-17 23:36 ` Eugene Surovegin
2005-02-18 15:56 ` Matt Porter
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=20050217225414.GA32623@gate.ebshome.net \
--to=ebs@ebshome.net \
--cc=Renaud.Barbier@ge.com \
--cc=linuxppc-embedded@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).