[PATCH 5/5] powerpc/fsl_msi: add 'msiregs' kernel parameter

Lian Minghuan-b31939 B31939 at freescale.com
Mon Jun 17 15:36:50 EST 2013


Hi Scott,

please see my comments inline.

On 06/15/2013 06:13 AM, Scott Wood wrote:
> On 06/14/2013 02:15:59 AM, Minghuan Lian wrote:
>> 1. Only MSIIR1 can index 16 MSI registers, but when using MSIIR1
>> the IRQs of a register are not continuous. for example, the first
>> register irq values are 0x0, 0x10, 0x20, 0x30 ... 0x1f0. So it
>> is hard to use 'msi-available-ranges' property to indicate the
>> available ranges and 'msi-available-ranges' property has been
>> removed from dts node, so this patch removes the related code.
>>
>> 2. Add 'msiregs' kernel parameter instead of 'msi-available-ranges'
>> functionality.
>
> The reason we used a device tree property was because this is for 
> virtualization and AMP scenarios where this instance of Linux does not 
> own all of the MSI registers.
>
> I don't see any reasonable way to partition an MPIC v4.3 MSI group -- 
> but there are more groups, so it's not that bad.  What's the use case 
> for this patch?
>
[Minghuan] I do not known any case about this patch. I add 'msiregs' 
just for achieving "msi-available-ranges" functionality. I do not want 
to remove partition functionality when updating to mpic4.3, although I 
do not see virtualization and AMP cases on T4(KVM does not need this 
functionality).
If you hope to keep 'msi-available-ranges' property for older mpic, can 
I add 'msi-available-regs' property for mpic4.3.
Using 'msi-available-regs' to implement partition is similar to 
'msi-available-ranges'. When considering the consistency, 
'msi-available-regs' is better than msiregs.
> -Scott




More information about the Linuxppc-dev mailing list