Re: [Xenomai] s3c24xx with clocksource/clockevent (kernel 3.2.21)

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 10/22/2012 01:33 AM, Romain Naour wrote:

> Le 21/10/2012 20:43, Gilles Chanteperdrix a écrit :
>> On 10/21/2012 03:35 AM, Romain Naour wrote:
>>
>>>> You mean the patch for the UART ? I can not take that patch. You have to
>>>> understand what goes wrong in the I-pipe core, or irq chip callbacks
>>>> implementation for this processor, and fix it there, not in the irq
>>>> handler for the serial interrupt.
>>> I think there is a problem when Linux unmask an IRQ line with
>>> irq_enable() and when there is an IRQ pending behind.
>>> I made some comments on the ipipe-tracer log
>>> (UART-samsung-bug-ipipe-tracer.txt)
>>
>> Ok: first comment: thanks to this patch:
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=352ee07368a89133df74948f3dd71ae657c519a0;hp=5e7413789eb3d1ca1613e986cbeb6c979082a217
>>
>> We know that irq_state_clr_masked is called when unmask_irq is called.
>>
>> Second, to know why cond_unmask_irq does not unmask the irq, you can use
>> ipipe_trace_special to print the value of the various conditions.
>>
>> It would have been better to include the relevant parts of the trace in
>> the mail body, this would have made answering simpler.
>>
> Ok, sorry for that.
> 
> here are some new trace with id :
> (1): IRQ enabled == 1
> (2): IRQ masked == 1
> (3): Treads oneshot == 1


Ok, so, if it is a oneshot irq, it means that it is a threaded irq, and
should be unmasked by the irq thread, not by handle_level_irq. You
should find the reason why the irq thread does not unmask it.

As explained on the page I directed you too, converting a spinlock to an
ipipe_spinlock is not something that should be done lightly. Otherwise,
you might well end-up with large masking sections, so, I would try and
find what section needs to run with irqs off, and only disable irqs for
that section.

A good candidate would be for instance, in s3c24xx_serial_start_tx, to
shuts off irqs around enable_irq and tx_enabled(port) = 1. Or,
alternatively, put tx_enabled(port) = 1 before the call to enable_irq,
and put a compiler barrier so that the instructions to not get reordered.

Another candidate would be irq_enable in kernel/irq/chip.c, shut off the
irqs around the whole section, or move irq_state_clk_masked before the
call to irq_unmask with a compiler barrier.

Yet another candidate would be changing cond_unmask_irq in
kernel/irq/chip.c.

-- 
                                                                Gilles.