From: marc.zyngier@arm.com (Marc Zyngier)
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 10:49:07 +0100 [thread overview]
Message-ID: <561E2513.1030901@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1510141100280.3785@nanos>
On 14/10/15 10:17, Thomas Gleixner wrote:
> 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.
OK, let's do that. I'll try to post something before Friday so that we
can really evaluate what the knock-on effect is.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "majun (F)" <majun258@huawei.com>,
Catalin.Marinas@arm.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Will.Deacon@arm.com,
mark.rutland@arm.com, jason@lakedaemon.net, lizefan@huawei.com,
huxinwei@huawei.com, dingtianhong@huawei.com,
zhaojunhua@hisilicon.com, liguozhu@hisilicon.com,
xuwei5@hisilicon.com, wei.chenwei@hisilicon.com,
guohanjun@huawei.com, wuyun.wu@huawei.com, guodong.xu@linaro.org,
haojian.zhuang@linaro.org, zhangfei.gao@linaro.org,
usman.ahmad@linaro.org, klimov.linux@gmail.com
Subject: Re: [PATCH v5 1/3] initialize each mbigen device node as a interrupt controller.
Date: Wed, 14 Oct 2015 10:49:07 +0100 [thread overview]
Message-ID: <561E2513.1030901@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1510141100280.3785@nanos>
On 14/10/15 10:17, Thomas Gleixner wrote:
> 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.
OK, let's do that. I'll try to post something before Friday so that we
can really evaluate what the knock-on effect is.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2015-10-14 9:49 UTC|newest]
Thread overview: 40+ 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 ` MaJun
2015-09-30 9:39 ` [PATCH v5 1/3] initialize each mbigen device node as a " MaJun
2015-09-30 9:39 ` MaJun
2015-09-30 21:37 ` Thomas Gleixner
2015-09-30 21:37 ` Thomas Gleixner
2015-10-04 7:22 ` majun (F)
2015-10-04 7:22 ` majun (F)
2015-10-09 13:47 ` Thomas Gleixner
2015-10-09 13:47 ` Thomas Gleixner
2015-10-10 9:01 ` majun (F)
2015-10-10 9:01 ` majun (F)
2015-10-10 10:09 ` Marc Zyngier
2015-10-10 10:09 ` Marc Zyngier
2015-10-11 9:54 ` Thomas Gleixner
2015-10-11 9:54 ` Thomas Gleixner
2015-10-11 11:03 ` Marc Zyngier
2015-10-11 11:03 ` Marc Zyngier
2015-10-11 16:45 ` Thomas Gleixner
2015-10-11 16:45 ` Thomas Gleixner
2015-10-13 6:32 ` majun (F)
2015-10-13 6:32 ` majun (F)
2015-10-13 6:55 ` Thomas Gleixner
2015-10-13 6:55 ` Thomas Gleixner
2015-10-14 8:16 ` majun (F)
2015-10-14 8:16 ` majun (F)
2015-10-14 8:20 ` Thomas Gleixner
2015-10-14 8:20 ` Thomas Gleixner
2015-10-14 8:54 ` majun (F)
2015-10-14 8:54 ` majun (F)
2015-10-14 8:55 ` Marc Zyngier
2015-10-14 8:55 ` Marc Zyngier
2015-10-14 9:17 ` Thomas Gleixner
2015-10-14 9:17 ` Thomas Gleixner
2015-10-14 9:49 ` Marc Zyngier [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 ` MaJun
2015-09-30 9:39 ` [PATCH v5 3/3] dt-binding:Documents of the mbigen bindings MaJun
2015-09-30 9:39 ` 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=561E2513.1030901@arm.com \
--to=marc.zyngier@arm.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 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.