lkml.org 
[lkml]   [2014]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 01/16] irqdomain: Introduce new interfaces to support hierarchy irqdomains
On 2014/11/18 17:54, Thomas Gleixner wrote:

> On Tue, 18 Nov 2014, Yun Wu (Abel) wrote:
>> Hi Thomas, Jiang,
>> On 2014/11/12 21:42, Thomas Gleixner wrote:
>>
>>> From: Jiang Liu <jiang.liu@linux.intel.com>
>>> Index: tip/kernel/irq/chip.c
>>> ===================================================================
>>> --- tip.orig/kernel/irq/chip.c
>>> +++ tip/kernel/irq/chip.c
>>> @@ -15,6 +15,7 @@
>>> #include <linux/module.h>
>>> #include <linux/interrupt.h>
>>> #include <linux/kernel_stat.h>
>>> +#include <linux/irqdomain.h>
>>>
>>> #include <trace/events/irq.h>
>>>
>>> @@ -178,6 +179,7 @@ int irq_startup(struct irq_desc *desc, b
>>> irq_state_clr_disabled(desc);
>>> desc->depth = 0;
>>>
>>> + irq_domain_activate_irq(&desc->irq_data);
>>
>> I'm not sure why this is needed, please help me out.. :)
>
> Because it makes the whole error handling in stacked allocations way
> simpler.
>
> We allocate and reserve resources, but do not program the hardware up
> to the point where request_irq and therefor irq_startup() is invoked.
>
> So when in the allocation/reservation phase any of the stack level
> fails we just have to undo the allocations/reservations and not any
> hardware settings.
>
> That also solves the issue that depending on the stacking we might not
> be able to program the hardware during the allocation because all
> stack levels need to be allocated/reserved before we can figure out
> which hardware configuration we need for the various levels.
>
> So we decided to postpone the actual hardware programming to the point
> where the interrupt actually gets used.
>

OK, I got it.

Thanks,
Abel



\
 
 \ /
  Last update: 2014-11-18 13:21    [W:0.108 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site