msi_bitmap.c question

msi_bitmap.c question

[Tirumala Marri]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

Hi,

I am trying to resubmit a patch for MSI support for ppc4xx devices. One of
the review feedback was not to use the bit map as it is only for the devices
which don’t have hard wired mapping between interrupt controller interrupts
and MSI number. For example intr-ctrl0 interrupt 20 goes to MSI-0, interrupt
21 goes to MSI-1 ..etc. But when I checked  freescale SoCs and cell SoCs
they have interrupts hard wired to MSI interrupts.



Why do they have to use the bitmap and create irqhost, even though they are
one-to-one mapped between interrupt controller numbers and MSI ?



Thx,

Marri

[-- Attachment #2: Type: text/html, Size: 1843 bytes --]

Re: msi_bitmap.c question

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

On Thu, 2010-10-14 at 15:56 -0700, Tirumala Marri wrote:
> Hi,
> 
> I am trying to resubmit a patch for MSI support for ppc4xx devices.
> One of the review feedback was not to use the bit map as it is only
> for the devices which don’t have hard wired mapping between interrupt
> controller interrupts and MSI number. For example intr-ctrl0 interrupt
> 20 goes to MSI-0, interrupt 21 goes to MSI-1 ..etc. But when I checked
> freescale SoCs and cell SoCs they have interrupts hard wired to MSI
> interrupts.  
> 
>  
> 
> Why do they have to use the bitmap and create irqhost, even though
> they are one-to-one mapped between interrupt controller numbers and
> MSI ?

I'm not quite sure I understand your question.

The MSI bitmap and the irq_host are two different things.

The MSI bitmap is basically an allocator for hardware numbers that can
be used for MSI. On some interrupt controllers that might be any
interrupt that's not used, on others there are restrictions on which
numbers can be used for MSI, it depends. So it's possible you don't need
to use that code, but I don't know how your hardware works.

The irq_host is the struct that controls mapping hardware irq numbers
into linux irq numbers. The cell MSI code has no restrictions on what
the MSI value is, so it just uses the Linux irq number directly using
irq_create_direct_mapping().

cheers




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: msi_bitmap.c question

[Tirumala Marri]

> >
> > I am trying to resubmit a patch for MSI support for ppc4xx devices.
> > One of the review feedback was not to use the bit map as it is only
> > for the devices which don=92t have hard wired mapping between interrupt
> > controller interrupts and MSI number. For example intr-ctrl0
> interrupt
> > 20 goes to MSI-0, interrupt 21 goes to MSI-1 ..etc. But when I
> checked
> > freescale SoCs and cell SoCs they have interrupts hard wired to MSI
> > interrupts.
> >
> >
> >
> > Why do they have to use the bitmap and create irqhost, even though
> > they are one-to-one mapped between interrupt controller numbers and
> > MSI ?
>
> I'm not quite sure I understand your question.
>
> The MSI bitmap and the irq_host are two different things.
>
> The MSI bitmap is basically an allocator for hardware numbers that can
> be used for MSI. On some interrupt controllers that might be any
> interrupt that's not used, on others there are restrictions on which
> numbers can be used for MSI, it depends. So it's possible you don't
> need to use that code, but I don't know how your hardware works.
>
> The irq_host is the struct that controls mapping hardware irq numbers
> into linux irq numbers. The cell MSI code has no restrictions on what
> the MSI value is, so it just uses the Linux irq number directly using
> irq_create_direct_mapping().
>

Mike, thanks. Could please you clarify your statement
" The cell MSI code has no restrictions on what  the MSI value is ".
If MSIs are one to one mapped to system interrupt controller
Interrupts, why do we need to create new irq_host? Isn't passing
Interrupt controllers irq_host instance not enough ?

Also when is cascade is needed?

Regards,
Marri