Message ID | 20181128144240.28727-1-rrichter@cavium.com (mailing list archive) |
---|---|
Headers | show |
Series | irqdomain, gic-v3-its: Implement late irq domain initialization | expand |
Marc, do you have any comments on this series? Please take a look at it. There is also this one on top: https://patchwork.kernel.org/cover/10685025/ Both series fix ITS table allocation for 4k page size and make the upstream kernel working without the need of additional patches. Thanks, -Robert On 28.11.18 15:43:02, Richter, Robert wrote: > This patch series is a rework of the gic-v3-its initialization. It is > in preparation of a further series that uses CMA memory allocation for > ITS tables. For this the CMA framework must be available and thus ITS > needs to be initialized after the arch_initcalls. This requires two > major reworks. > > First we must remove all irq domain init order dependencies (patches > #1-#5), second the ITS initialization must be split into an early > probe and a later init part (patches #6-#10). > > Patch #1 introduces a new interface to request an irq domain, see the > patch description for details. In patches #2-#5 all ITS related irq > domains are converted to use the new interface. There are no order > dependencies for parent and client irq domain initialization anymore > which allows us to initialize all ITS irq domains in the same initcall > (moving to the later subsys_initcall). Note that I do not have fsl > hardware available, the code should work, but is only carefully > reviewed and compile tested, please test on that hardware. > > The remaining patches #6-#10 are an incremental rework of the ITS > initialization, basically splitting probe and init (patch #7) and > separating it from gic-v3 code (patch #8). Patches #9 and #10 change > initcall levels for various drivers. > > Patches have been tested with Cavium ThunderX and ThunderX2. I have an > implementation of CMA ITS table allocation on top of this series > available, I will send out patches for this in a couple of days. > > v2: > * fix check for domain match in irq_domain_handle_requests() > * add comment that describes this check in irq_domain_handle_ > requests() > > Robert Richter (10): > irqdomain: Add interface to request an irq domain > irqchip/gic-v3-its-platform-msi: Remove domain init order dependencies > irqchip/irq-gic-v3-its-pci-msi: Remove domain init order dependencies > irqchip/irq-gic-v3-its-fsl-mc-msi: Remove domain init order > dependencies > fsl-mc/dprc-driver: Remove domain init order dependencies > irqchip/gic-v3-its: Initialize its nodes in probe order > irqchip/gic-v3-its: Split probing from its node initialization > irqchip/gic-v3-its: Decouple its initialization from gic > irqchip/gic-v3-its: Initialize its nodes later > irqchip/gic-v3-its: Initialize MSIs with subsys_initcalls > > drivers/bus/fsl-mc/dprc-driver.c | 41 +++++++ > drivers/bus/fsl-mc/fsl-mc-msi.c | 6 +- > drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 49 +++++--- > drivers/irqchip/irq-gic-v3-its-pci-msi.c | 68 ++++++----- > drivers/irqchip/irq-gic-v3-its-platform-msi.c | 56 +++++++-- > drivers/irqchip/irq-gic-v3-its.c | 160 ++++++++++++++++--------- > drivers/irqchip/irq-gic-v3.c | 12 +- > include/linux/cpuhotplug.h | 1 + > include/linux/irqchip/arm-gic-v3.h | 5 +- > include/linux/irqdomain.h | 15 +++ > kernel/irq/irqdomain.c | 163 ++++++++++++++++++++++++++ > 11 files changed, 446 insertions(+), 130 deletions(-) > > -- > 2.11.0 >
On 05/12/2018 12:50, Richter, Robert wrote: > Marc, > > do you have any comments on this series? Please take a look at it. It is on my list of stuff to review. Slowly getting there. Thanks, M.
Hi Marc, On 05/12/2018 14:27, Marc Zyngier wrote: > On 05/12/2018 12:50, Richter, Robert wrote: >> Marc, >> >> do you have any comments on this series? Please take a look at it. > > It is on my list of stuff to review. Slowly getting there. > Did you have time to review this patches? This affects production ready hardware, so we would like to see a upstream solution for that. Regards, Matthias
On 27/02/2019 16:24, Matthias Brugger wrote: > Hi Marc, > > On 05/12/2018 14:27, Marc Zyngier wrote: >> On 05/12/2018 12:50, Richter, Robert wrote: >>> Marc, >>> >>> do you have any comments on this series? Please take a look at it. >> >> It is on my list of stuff to review. Slowly getting there. >> > > Did you have time to review this patches? > This affects production ready hardware, so we would like to see a upstream > solution for that. I did: https://lkml.org/lkml/2018/12/13/459 As I said, it is a bit of a hack, but I'm not opposed to the idea. I'd like it to be driven differently though. Instead of requiring a new interface, I'd like it to be resolved on demand as domains get requested. This would allow for some of the more exotic stuff to be never created (platform MSI anyone?), because no device needs it. M.