mbox series

[v2,00/10] irqdomain, gic-v3-its: Implement late irq domain initialization

Message ID 20181128144240.28727-1-rrichter@cavium.com (mailing list archive)
Headers show
Series irqdomain, gic-v3-its: Implement late irq domain initialization | expand

Message

Robert Richter Nov. 28, 2018, 2:43 p.m. UTC
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(-)

Comments

Richter, Robert Dec. 5, 2018, 12:50 p.m. UTC | #1
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
>
Marc Zyngier Dec. 5, 2018, 1:27 p.m. UTC | #2
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.
Matthias Brugger Feb. 27, 2019, 4:24 p.m. UTC | #3
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
Marc Zyngier Feb. 27, 2019, 4:56 p.m. UTC | #4
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.