From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/3] initialize each mbigen device node as a interrupt controller.
Date: Wed, 14 Oct 2015 11:17:58 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1510141100280.3785@nanos> (raw)
In-Reply-To: <561E1886.2050305@arm.com>
Marc,
On Wed, 14 Oct 2015, Marc Zyngier wrote:
> To me, it feels like we're spreading the complexity across multiple
> layers instead of keeping it localized. It also means that next time
> some crazy HW dude comes up with a similar idea (and I have little doubt
> this will happen sooner than later), we'll have to replicate the same
> thing again (though we could put all that behind another abstraction layer).
>
> I would have preferred a solution where the MSI domain is allowed to be
> sandwiched between two non-MSI domains, and expose the top level
> irqchip. This means fixing the following:
>
> - Either find a way to prevent DT doing these early IRQ allocations
> (this could be easily done by simply not registering the irqchip), or be
> able to elegantly reuse them.
The reuse part makes me shudder. We really should not go there. It's a
blatant layering violation.
> - Add an API allowing an MSI domain to be the parent of another domain.
>
> Once we have this, we can use the platform MSI layer for the mbigen
> without much complexity (well, not more that any other stacked irqchip,
> the madness of the mbigen programming interface notwithstanding), and
> drivers stay untouched. It would also give us a 'standard' way to deal
> with the above HW dude. I'd be happy to prototype it.
Ok, I have a better understanding of it now.
I have no objections to your approach as long as it provides us a
clean way to use a full hierarchy without weird interfaces to reuse
irq descriptors etc. If you can find a way which just follows the
proper hierarchy design, I'm certainly not in your way.
OTOH, the platform msi driver is not a huge amount of code and from my
understanding of the hardware it looks weird to have this intermediate
layer. Making mbigen a direct child of ITS feels just more natural to
me. I'm pretty sure that this can be done without the earlier proposed
horrible modifications to ITS. It just should fall into place.
It would be really great just to have shell implementations,
i.e. without the mbigen specific stuff - for both models so we can
compare and contrast the results. That means just the interfaces and
the hookup to the various layers.
Thanks,
tglx
next prev parent reply other threads:[~2015-10-14 9:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 9:39 [PATCH v5 0/3] Support Mbigen interrupt controller MaJun
2015-09-30 9:39 ` [PATCH v5 1/3] initialize each mbigen device node as a " MaJun
2015-09-30 21:37 ` Thomas Gleixner
2015-10-04 7:22 ` majun (F)
2015-10-09 13:47 ` Thomas Gleixner
2015-10-10 9:01 ` majun (F)
2015-10-10 10:09 ` Marc Zyngier
2015-10-11 9:54 ` Thomas Gleixner
2015-10-11 11:03 ` Marc Zyngier
2015-10-11 16:45 ` Thomas Gleixner
2015-10-13 6:32 ` majun (F)
2015-10-13 6:55 ` Thomas Gleixner
2015-10-14 8:16 ` majun (F)
2015-10-14 8:20 ` Thomas Gleixner
2015-10-14 8:54 ` majun (F)
2015-10-14 8:55 ` Marc Zyngier
2015-10-14 9:17 ` Thomas Gleixner [this message]
2015-10-14 9:49 ` Marc Zyngier
2015-09-30 9:39 ` [PATCH v5 2/3] Probe mbigen chip and initial mbigen device as platform device MaJun
2015-09-30 9:39 ` [PATCH v5 3/3] dt-binding:Documents of the mbigen bindings MaJun
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=alpine.DEB.2.11.1510141100280.3785@nanos \
--to=tglx@linutronix.de \
--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