Questions on interrupt vector assignment on MPC8641D

[tiejun.chen]

tiejun.chen wrote:
> david.hagood at gmail.com wrote:
>> OK, using 224 as the MPIC interrupt number, and attempting to map it via
>> irq_create_mapping(0,224) gives me a kernel seg fault:
> 
> This should not be correct without initialing MSI for MPIC host. As I comment on
> another email, please refer to the file, arch/powerpc/sysdev/fsl_msi.c.

With Scott's comment I remember the NULL host would be always 'irq_default_host'
at last. The 'irq_default_host' should be your MPIC host so it should be fine.

> 
> -Tiejun
> 
>> Unable to handle kernel paging request for data at address 0x00000000
>> Faulting instruction address: 0xc0016540
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> PREEMPT SMP NR_CPUS=2 EP8641A
>> Modules linked in: Endpoint_driver(+)
>> NIP: c0016540 LR: c0050b38 CTR: c00163b8
>> REGS: ef8c1ab0 TRAP: 0300   Not tainted  (2.6.26.2-ep1.10)
>> MSR: 00001032 <ME,IR,DR>  CR: 24024482  XER: 00000000
>> DAR: 00000000, DSISR: 40000000
>> TASK = eedec6a0[60] 'insmod' THREAD: ef8c0000 CPU: 1
>> GPR00: 00000000 ef8c1b60 eedec6a0 ffffffea 00000000 00000000 c035c17c
					^
					The return value, r3, should be -22, '-EINVAL'.

And refer to the call trace and the source codes
------
int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
{
        struct mpic *mpic = mpic_from_irq(virq);
        unsigned int src = mpic_irq_to_hw(virq);
        struct irq_desc *desc = get_irq_desc(virq);
        unsigned int vecpri, vold, vnew;

        DBG("mpic: set_irq_type(mpic:@%p,virq:%d,src:0x%x,type:0x%x)\n",
            mpic, virq, src, flow_type);

        if (src >= mpic->irq_count)
                return -EINVAL;
			^
			I think this OOPS may be from here.

You can enable DBG on this file, arch/powerpc/sysdev/mpic.c, to track 'src' and
'mpic->irq_count' on your old tree.

-Tiejun

>> 000000e0
>> GPR08: 00400000 00000000 c035c020 00000000 24024422 100a7264 00000000
>> 00000095
>> GPR16: 00000095 00000000 0000000d 00000124 f102fd98 00000000 c004a4fc
>> f102c000
>> GPR24: 0000001a f1038400 00000000 c031e610 fffffffa 00009032 c031e5e0
>> 000000e0
>> NIP [c0016540] mpic_set_irq_type+0x188/0x1c4
>> LR [c0050b38] set_irq_type+0x84/0xc8
>> Call Trace:
>> [ef8c1b60] [c0050b1c] set_irq_type+0x68/0xc8 (unreliable)
>> [ef8c1b80] [c001572c] mpic_host_map+0xec/0xf4
>> [ef8c1b90] [c00064a0] irq_setup_virq+0x60/0x98
>> [ef8c1bb0] [c00065dc] irq_create_mapping+0x104/0x114
>> [ef8c1bd0] [f1034798] Endpoint_device_ctor+0x258/0x3b8 [Endpoint_driver]
>>
>> Reading the source (since these calls don't seem to have any other
>> documentation), it *looks* like it ought to be valid to call
>> irq_create_mapping with a null irq_host *host - which is good, since I
>> can't see anything obvious that would give me some other irq_host (again,
>> since none of this seems to be documented anywhere).
>>
>> I am assuming the default host used by the system would be correct.
>>
>> However, then I get this fault.
>>
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>