Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device

[Yijing Wang]

>> MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes
>> are bonding with PCI device. Because MSI has a lot advantages in design.
>> More and more non-PCI devices want to use MSI as their default interrupt.
>> The existing MSI device include HPET. HPET driver provide its own MSI
>> code to initialize and process MSI interrupts. In the latest GIC v3 spec,
>> legacy device can deliver MSI by the help of a relay device named
>> consolidator.
>> Consolidator can translate the legacy interrupts connected to it to
>> MSI/MSI-X. And new non-PCI device will be designed to support MSI in
>> future. So make the MSI driver code be generic will help the non-PCI
>> device use MSI more simply.
> 
> As per my understanding the GICv3 provides a service that will convert writes to a specified address to IRQs delivered to the core and as you mention above MSIs are part of the PCI spec. So I can see a strong case for non-PCI devices to want MSI like functionality without being fully compliant with the requirements of the MSI spec.

In GICv3, MBI is named for the service, but there is no more detailed information about it, only we can know is MBI is analogous to MSI,
MBI devices must have address/data registers, but other registers like enable/mask/ctrl are not mandatory requirement.
I don't know whether the MBI spec will be release, but anyway I think MSI refactoring is make sense, there are some existing Non-PCI MSI device like hpet, dmar.
For simplicity, let name MSI and MBI to MSI temporarily.
> 
> My question is do we necessarily want to rework so much of the PCI-MSI layer to support non PCI devices? Or will it be sufficient to create a framework to allow non PCI devices to hook up with a device that can convert their writes to an IRQ to the core.
> 
> As I understand it, the msi_chip is (almost) such a framework. The only problem being that it makes some PCI specific assumptions (such as PCI specific writes from within msi_chip functions). Won't it be sufficient to make the msi_chip framework generic enough to be used by non-PCI devices and let each bus/device manage any additional requirements (such as configuration flow, bit definitions etc) that it places on message based interrupts?

msi_chip framework is important to support that, but I think maybe it's not enough, msi_chip is only responsible for IRQ allocation, teardown, etc..

The key difference between PCI device and Non-PCI MSI is the interfaces to access hardware MSI registers.
for instance, currently, msi_chip->setup_irq() to setup MSI irq and configure the MSI address/data registers, so we need to provide device specific write_msi_msg() interface,
then when we call msi_chip->setup_irq(), the device MSI registers can be configured appropriately.

My patchset is just a RFC draft, I will update it later, all we want to do is make kernel support Non-PCI MSI devices.

Thanks!
Yijing.


> 
> Thanks
> Arnab
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> .
> 


-- 
Thanks!
Yijing

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/