Re: [PATCH 1/3] misc: Add crossbar driver

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

On Thursday 22 August 2013 07:33 AM, Sricharan R wrote:
> Hi Linus,
> 
> On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote:
>> On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:
>>> On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote:
>> (...)
>>>> Sorry I don't understand what thread that is... can you point me there?
>>>> My previous statement on this issue what this:
>>>> http://marc.info/?l=linux-kernel&m=137442541628641&w=2
>> (...)
>>>>> I don't see how you can make this happen with an irqchip
>>>>> infrastructure.
>>>> I think my post above describes this.
>>>>
>>> Sorry for being dumb but I don't think cascaded irqchip examples
>>> like GPIO and cross-bars are same. If you take an example of
>>> GPIO irqchip, it always have a physical connection even if it
>>> is 1 IRQ line for (32 logical/sparse IRQs). That goes with
>>> other MFD examples too.
>>>
>>> So may be I am still missing something in your proposal.
>> Why does it matter if it is a GPIO or MFD or whatever?
>> The point is that the IRQ line passes thru something else,
>> and this we model as an irqdomain.
>>
>> Anyway here is a silicon cascaded IRQ chip:
>> arch/arm/mach-versatile/core.c
>> See versatile_init_irq():
>>
>> __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np);
>> (...)
>> fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START,
>>                 IRQ_VICSOURCE31, PIC_VALID, np);
>>
>> The VIC in the versatile has the SIC cascaded from one of
>> its IRQ lines. Both the VIC and SIC (fpga IRQ) are
>> using irqdomains so the SIC spawns a child irqdomain
>> from IRQ 31 (last IRQ) of the VIC.
>  Ok, this is a typical example of irqchip cascaded.
>> The difference with a crossbar is that it can software-config
>> which IRQ goes where, and does not have a callback
>> to clear interrupts or anything like that, it just passes them
>> thru. But it is best modeled as an irqdomain IMO.
> We can model crossbar as irqchip and gic as its interrupt parent
> and peripherals to have crossbar as interrupt-parent.
>    
>  peripherals will do request_irq(crossbar_number)
>               |
>               |
>  crossbar_unmask()
>               |
>               |
>  maps crossbar number<->  to interrupt number and
>  calls request_irq(int_no, crossbar_handler,..)
> 
>  
>  crossbar_handler(interrupt number)
>             |
>             |
>  get crossbar number from interrupt number
>             |
>             |
>  handle_irq(crossbar_domain(crossbar number))
>                                                                              
> 
> So this means a extra dummy handler.
Its not optimal to go through the dummy call stack on
fast path but considering its not going to eat too many
instructions, its fine to have dummy handler. We should
try this out.

> Also the concern is by modelling it as irqchip, we will have
> to find a different solution for DMA crossbar.
> 
DMAEngine has a notion of logical channel and that was actually
used in the EDMA support series by Matt [1]
We can do something similar to handle that scenario.


[1] https://lkml.org/lkml/2013/6/18/56