[RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains

On Mon, 29 Sep 2014, Abel wrote:

On 2014/9/26 22:02, Jiang Liu wrote:

quoted

+static void irq_domain_free_descs(unsigned int virq, unsigned int nr_irqs)
+{
+	unsigned int i;
+
+	for (i = 0; i < nr_irqs; i++)
+		irq_free_desc(virq + i);
+}

I am not sure why this function is needed, since it works in the exact same
way as irq_free_descs(virq, nr_irqs).

Indeed.
 

I've been through your patches and noticed that the only domain
which does not call irq_domain_alloc_irqs_parent() is
x86_vector_domain. And this makes sense *if* we already knew which
domain is the nearest one to the CPU.

Right, and in case of x86 the vector domain _IS_ the one which is
always the nearest one to the cpu.

But I don't think a well implemented device driver should assume
itself be in a particular position of the interrupt delivery path.

The device driver has no knowledge of this. The irq domain driver
definitely has to know to some extent.

Actually it should be guaranteed by the core infrastructure that all
the domains in the interrupt delivery path should allocate a
hardware interrupt for the interrupt source.

Well, that's what we do. We allocate down the irq domain hierarchy. If
one level fails the whole operation fails.

And besides the comments/questions I mentioned above, I am also curious about
how the chained interrupts been processed.

Let's take a 3-level-chained-domains for example.
Given 3 interrupt controllers A, B and C, and the interrupt delivery path is:

DEV -> A -> B -> C -> CPU

After the hierarchy irqdomains are established, the unique linux interrupt of
DEV will be mapped with a hardware interrupt in each domain:

DomainA: HWIRQ_A => VIRQ_DEV
DomainB: HWIRQ_B => VIRQ_DEV
DomainC: HWIRQ_C => VIRQ_DEV

When the DEV triggered an interrupt signal, the CPU will acknowledge HWIRQ_C,

Not necessarily. The CPU will process HWIRQ_C. The acknowledge
mechanism depends on the implementation details of the hierarchy.

and then irq_find_mapping(DomainC, HWIRQ_C) will be called to get the linux
interrupt VIRQ_DEV, and after the handler of the VIRQ_DEV has been processed,
the interrupt will end with the level (if have) uncleared on B, which will
result in the interrupt of DEV cannot be processed again.

Or is there anything I misunderstand?

This heavily depends on the properties of the stacked domains.

It depends on the hardware requirements and the implementation of
domain A and B how this is handled.

It might be sufficient to have the following code in the irq_ack()
callback of domain A:

irq_ack_A(struct irq_data *d)
{
	ack_hw_A();
}

Another HW or stacking scenario requires

irq_ack_A(struct irq_data *d)
{
	ack_hw_A();
	ack_parent();
}

where ack_parent() does:

      if (d->parent_data)
      	 d->parent_data->chip->ack(d->parent_data);

and ack_hw_A() can be anything from a nop to some more or less complex
hw access.

So we cannot define upfront how deep an ack/mask/unmask/... has to be
propagated down the chain. This needs a careful consideration in terms
of functionality and we want to be able to do performance shortcuts as
well.

Thanks,

	tglx