On 2014/11/24 22:19, Yun Wu (Abel) wrote: > On 2014/11/24 22:11, Jiang Liu wrote: > >> On 2014/11/24 22:01, Yun Wu (Abel) wrote: >>> On 2014/11/24 21:13, Thomas Gleixner wrote: >>> >>>> On Mon, 24 Nov 2014, Yun Wu (Abel) wrote: >>>>> Hi Thomas, Jiang, >>>>> On 2014/11/12 21:42, Thomas Gleixner wrote: >>>>> >>>>>> From: Jiang Liu <[email protected]> >>>>>> >>>>> [...] >>>>>> /* Number of irqs reserved for a legacy isa controller */ >>>>>> #define NUM_ISA_INTERRUPTS 16 >>>>>> @@ -64,6 +66,16 @@ struct irq_domain_ops { >>>>>> int (*xlate)(struct irq_domain *d, struct device_node *node, >>>>>> const u32 *intspec, unsigned int intsize, >>>>>> unsigned long *out_hwirq, unsigned int *out_type); >>>>>> + >>>>>> +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY >>>>>> + /* extended V2 interfaces to support hierarchy irq_domains */ >>>>>> + int (*alloc)(struct irq_domain *d, unsigned int virq, >>>>>> + unsigned int nr_irqs, void *arg); >>>>>> + void (*free)(struct irq_domain *d, unsigned int virq, >>>>>> + unsigned int nr_irqs); >>>>>> + void (*activate)(struct irq_domain *d, struct irq_data >>>>>> *irq_data); >>>>>> + void (*deactivate)(struct irq_domain *d, struct irq_data >>>>>> *irq_data); >>>>> >>>>> What's the usage of the parameter domain reference in activate/deactivate? >>>>> I think the purpose of the two callbacks is to activate/deactivate the >>>>> irq_data->hwirq in irq_data->domain. If so, the first parameter @domain is >>>>> required to be equal to irq_data->domain (which makes @domain useless). >>>>> Besides, the main responsibility of interrupt domains is to manage >>>>> mappings >>>>> between hardware and linux interrupt numbers, so would it be better if >>>>> move >>>>> the two callbacks into struct irq_chip? >>>> >>>> No. It's not a function of the irq_chip to activate/deactivate a >>>> hierarchy. As I explained you before: >>>> >>>> The existing irqdomain code maps between hardware and virtual >>>> interrupts and thereby activates the interrupt in hardware. >>>> >>>> In the hierarchical case we do not touch the hardware in the >>>> allocation step, so we need to activate the allocated interrupt in the >>>> hardware before we can use it. And that's clearly a domain interface >>>> not a irq chip issue. >>>> >>> >>> Makes sense, now the interrupt domain seems to be the best place. >>> And when the @domain parameter can be really useful? I haven't see >>> anyone using it so far. >> We will use it for IOAPIC on x86, as below: >> void mp_irqdomain_deactivate(struct irq_domain *domain, >> struct irq_data *irq_data) >> { >> ioapic_mask_entry(mp_irqdomain_ioapic_idx(domain), >> (int)irq_data->hwirq); >> } >> >> >From an object oriented point of view, we pass the object as the >> first parameter. It's true that we could retrieve domain from >> irq_data->domain instead of explicitly passing it in, but that >> will cause irqdomain interfaces depends on irq_data, not sounds >> a good situation:) > > Hi Gerry, > > Is there any possibility that domain doesn't equal to irq_data->domain? > I'm a little confused.. Hi Yun, Currently they are always the same, but we don't want irqdomain interfaces make assumption of struct irq_data. If it will bring big performance improvement, we will try to kill the first parameter, otherwise we may prefer keeping irqdomain interfaces clear. Thanks! Gerry
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
