Re: [Xenomai-help] PowerPC irq unmask

[Philippe Gerum <rpm@xenomai.org>]

Federico Ridolfo wrote:

Ok, things look clearer now. As an introductory remark, the actual OF data does
not match the comments found in your dts file, which does not help at all (e.g.
PSC0 is tagged as PSC1 etc). The device description blob seems to match
otherwise, at least for the PSCs.

> irq: irq_create_mapping(0xc041d2a0, 0x81)
> irq: -> using host @c041d2a0
> irq: -> existing mapping on virq 129
> f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
> irq: irq_create_mapping(0xc041d2a0, 0x82)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 130
> f0002200.serial: ttyPSC1 at MMIO 0xf0002200 (irq = 130) is a MPC52xx PSC
> irq: irq_create_mapping(0xc041d2a0, 0x8b)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 139
> f0002600.serial: ttyPSC3 at MMIO 0xf0002600 (irq = 139) is a MPC52xx PSC
> irq: irq_create_mapping(0xc041d2a0, 0x8c)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 140
> f0002800.serial: ttyPSC4 at MMIO 0xf0002800 (irq = 140) is a MPC52xx PSC

<snip>

This is where you loaded the psc_psi module, which in turn caused two more IRQs
to be mapped and claimed by the driver. This explains part of the behavior you
observed: at init time, all IRQ descriptors point at a dummy interrupt chip
controller, which has no unmask handler (i.e. NULL); and the kernel provides no
default unmask handler whatsoever.

Therefore, until the psc_spi module is loaded, there is no unmask handler for
PSC3 and PSC6 IRQs, since those have not been mapped and claimed by the driver
yet. Hence, -ENODEV is received when rtdm_irq_request() attempts to enable the line.

Second issue: once the driver is loaded, and you attempt to load your RTDM
driver, the board locks up badly. At that point, you don't receive -ENODEV
anymore since PSC3 and PSC6 IRQs have been mapped, so they do have a valid
unmask handler (unloading your driver won't dispose of the mapping).
This means that your RTDM driver is missing a call to e.g.
irq_of_parse_and_map(), in order to map the PSC3 and PSC6 IRQs you want to use,
and get back their actual virtual numbers to pass to rtdm_irq_request(); as
Wolfgang pointed out, you should go through the OF parsing to get those values,
and never use pre-defined constants now that you depend on a device tree. You
may want to have a look at the CAN drivers in the Xenomai drivers/ area to find
out how to retrieve the OF node that corresponds to some device by name (i.e.
of_find_compatible_node()).

Regarding the lockup, I suspect this has something to do with your RTDM
interrupt handler; the PSC3/PSC6 IRQs are level ones, so your board likely locks
up out of an interrupt storm, due to a bad device acknowledge or something
alike. In any case, you want to fix the IRQ mapping issue first, so that you
don't need to fiddle with the standard psc_spi driver to get those mapped. This
should reduce the number of opportunities for breakage when looking at the
second issue.

> irq: irq_create_mapping(0xc041d2a0, 0x83)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 131
> mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
> (de)activate_cs function will be called
> irq: irq_create_mapping(0xc041d2a0, 0x84)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 132
> mpc52xx-psc-spi f0002c00.spi: probe called without platform data, no
> (de)activate_cs function will be called
> 
> Philippe Gerum wrote:
>> Federico Ridolfo wrote:
>>   
>>> Ok, i'm debugging the problem, but i have not a solution.
>>> I compiled the kernel with the debug switch for irq.c.
>>> In addition i added the mpc52xx_psc_spi module in my
>>> .config.
>>> So, now i'm sure that the irq used in mpc52xx_psc_spi
>>> for the PSC3 is 131 and for PSC6 is 132:
>>>
>>> # dmesg
>>> mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
>>> (de)activate_cs function will be called
>>> irq: irq_create_mapping(0xc041d2a0, 0x84)
>>> irq: -> using host @c041d2a0
>>> irq: -> obtained virq 132
>>>
>>>     
>> Please send all the IRQ related information, you get in the boot log, because
>> the few lines above do not match what your dts file below says.
>>
>> As far as I understand those lines, the generic IRQ code is asked to create a
>> virtual mapping for hwirq 132 out of the OF specs, and this hint is kept so that
>> you actually get virq 132. So far so good.
>>
>> However, to get asked for 132, your dts file should have specified an intspec
>> which rather looks like { 2 4 <sense-type> } and not { 2 3 <sense-type> } as
>> mentioned in the spi@domain.hid block. { 2 3 <sense-type> } for PSC3 in SPI mode would
>> rather give us hwirq 131 (the hairy computation determining the hwirq number
>> from the inspec is available from mpc52xx_irqhost_xlate()).
>>
>> So either you are not booting with the blob that matches the dts file below, or
>> the console output above is misleading. In short, I'm lost.
>>
>>   
>>> I'm using the same irqs for my rtdm spi driver, but it doesnìt work.
>>> If i reboot the board and try my rtdm driver, the result is -ENODEV
>>>
>>> If i "modprobe  mpc52xx_psc_spi"  and retry my rtdm driver -> the board
>>> hangs for ever.
>>> I have the same result  also if i "rrmod mpc52xx_psc_spi" before.
>>> My dts is:
>>> /dts-v1/;
>>>

-- 
Philippe.