From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
Date: Thu, 8 May 2014 19:05:40 -0400 [thread overview]
Message-ID: <536C0DC4.7090309@ti.com> (raw)
In-Reply-To: <CAD=GYpbQQxQgKd3oZcAuWrxoD4VrkKzpybd11qwxs405HSUVGw@mail.gmail.com>
On Thursday 08 May 2014 06:43 PM, Joel Fernandes wrote:
> On Thu, May 8, 2014 at 3:37 PM, Nishanth Menon <nm@ti.com> wrote:
>> On 14:24-20140508, Joel Fernandes wrote:
>>> On 05/05/2014 09:18 AM, Sricharan R wrote:
>>>> From: Nishanth Menon <nm@ti.com>
>>>>
>>>> When, in the system due to varied reasons, interrupts might be unusable
>>>> due to hardware behavior, but register maps do exist, then those interrupts
>>>> should be skipped while mapping irq to crossbars.
>>>>
>>>
>>> Just wondering, instead of hardcoding this data in the code, and
>>> introducing additional flags (IRQ_SKIP), why not just put these GIC IRQs
>>> in the ti,irq-reserved property in DTS for platforms where such IRQs are
>>> not usable. That way you're skipping these IRQs anyway.
>>>
>>> Also that would avoid adding more hard coded data for future SoCs into
>>> the source for such IRQs that must be skipped, and also reduces LOC.
>>>
>>
>> Good question - lets try to explain the hardware a little here ->
>> obviously a driver that cannot use the hardware is useless compared to
>> reducing LOC count ;).. and apologies about the long reply..
>>
>> Basic understanding:
>> GIC has 160 SPIs and number of hardware block interrupt sources is around or
>> more than 400. So, in comes crossbar - which is basically a mapper by
>> allowing us to select an hardware block interrupt source (identified as
>> crossbar_number or cb_no in code). So all we have to do is to write to a
>> register in crossbar corresponding to GIC and viola, we now routed the
>> interrupt source to a GIC interrupt of our choice. At least the
>> Specification reads so.... until you drill down to the details.
>
> Thanks for the long explanation and the diagrams!
>
> Yes, I feel there is no other way and with so many HW bugs, I think it
> makes sense to make it a real irqchip driver.
>
It doesn't because its not an irqchip.
> Further since not everything goes through the crossbar and some are
> direct mapped like your diagram, the correct fix is probably making it
> an irqchip and doing the interrupt controller parenting correctly in
> DT.
>
> That would take care of A), because users of such direct mapped
> interrupts will go through the GIC interrupt controller directly.
>
> It will also take care of B), because if writing to cross bar has no
> effect for a particular IRQ, or if those IRQs are hard-wired to
> something, as you said, then that something should go through the GIC
> directly.
>
> I can try to whip up something like this if it makes sense, let me know...
>
I have been ignoring this series considering they were just fixes
but you comments are like re-inventing wheel. Please read all
the old threads and comments from Thomas and me on why we took
approach and why it is not an irqchip. There is no need to complicate
it further.
Regards,
Santosh
next prev parent reply other threads:[~2014-05-08 23:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 14:18 [PATCH 0/5] irqchip/dra7: crossbar bug fixes Sricharan R
2014-05-05 14:18 ` [PATCH 1/5] irqchip: crossbar: dont use '0' to mark reserved interrupts Sricharan R
2014-05-05 14:18 ` [PATCH 2/5] irqchip: crossbar: check for premapped crossbar before allocating Sricharan R
2014-05-05 14:18 ` [PATCH 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar Sricharan R
2014-05-08 19:24 ` Joel Fernandes
2014-05-08 20:37 ` Nishanth Menon
2014-05-08 22:43 ` Joel Fernandes
2014-05-08 23:05 ` Santosh Shilimkar [this message]
2014-05-09 0:13 ` Joel Fernandes
2014-05-09 0:25 ` Santosh Shilimkar
2014-05-09 4:22 ` Joel Fernandes
2014-05-09 12:54 ` Nishanth Menon
2014-05-09 13:27 ` Santosh Shilimkar
2014-05-09 13:36 ` Nishanth Menon
2014-05-09 13:45 ` Santosh Shilimkar
2014-05-09 14:00 ` Nishanth Menon
2014-05-09 14:13 ` Joel Fernandes
2014-05-09 20:41 ` Santosh Shilimkar
2014-05-09 13:43 ` Joel Fernandes
2014-05-09 13:36 ` Joel Fernandes
2014-05-09 13:37 ` Joel Fernandes
2014-05-09 13:38 ` Nishanth Menon
2014-05-05 14:18 ` [PATCH 4/5] irqchip: crossbar: Initialise the crossbar with a safe value Sricharan R
2014-05-05 14:18 ` [PATCH 5/5] irqchip: crossbar: Change allocation logic by reversing search for free irqs Sricharan R
2014-05-05 18:10 ` [PATCH 0/5] irqchip/dra7: crossbar bug fixes Darren Etheridge
2014-05-06 0:48 ` 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=536C0DC4.7090309@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=linux-arm-kernel@lists.infradead.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).