Re: [V10 PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 11/4/2014 7:01 AM, Jiang Liu wrote:
Hi Suravee,
	You may build a two level hierarchy irqdomains. Use the
utilities in this thread
http://www.spinics.net/lists/arm-kernel/msg374722.html  to build an MSI
irqdomain to manage MSI controllers
in PCI devices. And build another irqdomain to manage SPI allocation
in GICv2.
	That is: MSI irqdomain (program MSI registers)  -->
GIV irqdomain (manage SPIs in GICv2 controller)

Regards!
Gerry

Gerry,

I try out your patch from the link above, and I have a couple questions/issues.

1. In the drivers/pci/msi.c: msi_irq_domain_alloc_irqs(), it seems that the hwirq comes from msi_get_hwirq(dev, msidesc). In GICv2m, hwirq for MSI is fixed over a specific range. This might require arch-specific
callback.

2. In msi_domain_activate, why "if (!irq_data->chip_data)"?

3. In, msi_domain_alloc():

- There should be a way to specify other types of irq handler besides the "handle_edge_irq". In case of GIC, it needs handle_fasteoi_irq.

- When calling irq_domain_set_hwirq_and_chip(), you are passing "(void *)(long)i" for the "void *chip_data" parameter. What is this used for, and where? Shouldn't this be pointing to arch-specific data structure?

- The code is calling irq_domain_alloc_irqs_parent before the loop, which calls irq_domain_set_hwirq_and_chip() and __irq_set_handler. Shouldn't the order be switched?

- Overall, it seems that msi_domain_alloc() could be quite different across architectures. Would it be possible to declare this function as weak, and allow arch to override (similar to arch_setup_msi_irq)?

Thanks,

Suravee

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux