Hi Marc

I can probably help you with that, but this assumes that you've
implemented support for your own bus by providing a glue layer
equivalent to the one we have for other buses.

Thanks for your comments.
I want to consider implementing a glue layer for our bus. 

-----Original Message-----
From: linux-arm-kernel
[mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of
Marc Zyngier
Sent: Monday, April 30, 2018 7:20 PM
To: Zhang, Lei/? ?; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH]irqchip/irq-gic-v3:Avoid a waste of LPI resource

Hi Lei,

On 30/04/18 08:53, Zhang, Lei wrote:

quoted

Hi Marc

thanks for your opinions.

quoted

How many is many? Are they PCI? Or something else?

quoted

As it is, this patch will break Multi-MSI and some other platforms

that

quoted

quoted

do require a higher allocation granule.

Depending on whether you're using PCI or some other bus, we can probably
come up with a solution that works for everyone. But I need more
information on this.

Actually it is our original interconnect device not on PCI but on our
original bus. This device has many sub devices around one thousand,
and each sub device requires only a few LPIs.

OK. Have you implemented your own glue layer for this (like we already
have for PCI, platform and FSL-MC)? Or are you directly using the
platform MSI infrastructure?

quoted

As I explained in point1, each Device ID can still allocate enough
LPIs more than IRQS_PER_CHUNK by increasing chunks. So I couldn't
understand why this patch will break Multi-MSI.

Unfortunately, Multi-MSI has more requirements than just allocating
multiple MSIs. The allocated MSIs must be allocated as a contiguous
range, be a power of two, aligned on the size of the range, with a
maximum of 32 interrupts. Your approach breaks the alignment requirement.

quoted

By the way, 32 seems a good default value for IRQS_PER_CHUNK.
So, I want to write another patch to make IRQ_PER_CHUNK a variable
which can be changed by kernel parameter.
What do you think of this idea?

It is not great, because it prevents two buses with different
requirements from being used concurrently in the same system. It may not
be an issue for you right now, but I want the ITS driver to be
independent of the bus requirements.

Another, more involved (but also more correct) approach would be to
teach the various glue layers about the requirements of the bus they
support, and pass on the allocation requirements to the core ITS driver.
That way, we would keep the heterogeneous case working.

I can probably help you with that, but this assumes that you've
implemented support for your own bus by providing a glue layer
equivalent to the one we have for other buses.

Thanks,

	M.
--
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel