From: Daniel Hellstrom <daniel@gaisler.com>
To: sparclinux@vger.kernel.org
Subject: Re: [PATCH 5/5] sparc32: genirq support
Date: Wed, 30 Mar 2011 10:10:58 +0000 [thread overview]
Message-ID: <4D9301B2.9030609@gaisler.com> (raw)
In-Reply-To: <1298234400-22378-5-git-send-email-sam@ravnborg.org>
David Miller wrote:
>From: Daniel Hellstrom <daniel@gaisler.com>
>Date: Wed, 16 Mar 2011 16:53:18 +0100
>
>
>
>>I think it is very good as well, it will save us a lot of problems in
>>the future! However LEON needs VIRQ to map 1:1 to real IRQs. I figured
>>that it does not hurt the SUNs if we map 1:1 as long as it is
>>possible. The reason is that LEON drivers must have the possibility to
>>do request_irq on IRQ and IRQ+1 and IRQ+2 and so on. Due to how the
>>Plug&Play information is designed we can only know the first IRQ of a
>>device, a device may have 2 IRQs (always IRQ and IRQ+1 in that
>>case). And since VIRQ->REAL_IRQ but not VIRQ+1->REAL_IRQ+1 this will
>>break.
>>
>>Please see my patches sent to the list (not the APBUART patches),
>>perhaps Sam can include the single patch into the PATCH5? The other
>>patches for the exteneded IRQ controller and irq_shutdown must be
>>applied afterwards.
>>
>>
>
>I disagree with the validity of your conclusion.
>
>The physical interrupts can be anything.
>
>What you need to do on LEON is convert this linear sequence of
>physical IRQs to a set of virtual IRQs and make the drivers receive
>this information.
>
>The method by which the IRQs are communicated to the kernel is
>absolutely arbitrary, and has no bearing on how this stuff must
>or must not work.
>
>Therefore, there is absolutely no 1:1 requirement, and I am strongly
>against supporting such a mapping. It makes the whole VIRQ exercise
>pointless.
>
>
I agree, but the problem is that due to hardware limitation the LEON IRQ
layers or bootloader can not know this. Please see my reply to "[PATCH
1/2 v2] sparc32,leon: APBUART driver must use ..."
>Make the drivers LEON drivers and able to receive a set of IRQs from
>the kernel, instead of depending upon linearity.
>
>
>
That is no problem, I can have that done by today. The problem is the
bootloader or the IRQ layer of sparc32-leon.
prev parent reply other threads:[~2011-03-30 10:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-20 20:40 [PATCH 5/5] sparc32: genirq support Sam Ravnborg
2011-02-20 21:30 ` Josip Rodin
2011-02-22 18:22 ` Sam Ravnborg
2011-02-26 7:06 ` David Miller
2011-03-16 15:53 ` Daniel Hellstrom
2011-03-30 9:22 ` David Miller
2011-03-30 10:10 ` Daniel Hellstrom [this message]
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=4D9301B2.9030609@gaisler.com \
--to=daniel@gaisler.com \
--cc=sparclinux@vger.kernel.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 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.