Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

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

On 01/20/2012 07:03 PM, Wolfgang Grandegger wrote:
> Hi Fabrice and Manfred,
> 
> On 01/19/2012 06:09 PM, Fabrice Gasnier wrote:
>> On 18/01/2012 17:32, Wolfgang Grandegger wrote:
>>>> Further investigation indicates that when writing, tx interrupt is not asserted as expected (rt_16550_write):
>>>>> /* unmask tx interrupt */
>>>>> ctx->ier_status |= IER_TX;
>>>>> rt_16550_reg_out(rt_16550_io_mode_from_ctx(ctx),
>>>>> 		 ctx->base_addr, IER,
>>>>> 		 ctx->ier_status,
>>>>> 		 ctx->regshift);
>>>>>
>>>>> >From my understanding this should trigger an irq for data to be put in rt_16550_tx_interrupt().
>>>>> It seems this is not always the case. Moreover, TX interrupt seem to be triggered by a new RX interrupt.
>>> The TX interrupt will be enabled as long as there are chars to send,
>>> IIRC. The isr the puts the chars into the FIFO and triggers the xfer.
>> Finally, I find out that UART was in sleep mode.
>> According to omap's reference manual, it enters this mode when conditions are met:
>> rx line is idle,
>> tx fifo and shift register are empty,
>> rx fifo is empty
>> no interrupts pending
>>
>> One solution that i've tested successfully is to disable sleep mode in rt_16550_open(). TX interrupts are then being triggered as expected.
>>>
>>>>>
>>>>> Would you have an explanation for such a behavior?
>>>>> I'm not sure how to solve this.
>>> Depending on the hardware/uart revision, you may need to take care of
>>> other quirks, see:
>>>
>>> http://lxr.linux.no/#linux+v3.2.1/arch/arm/mach-omap2/serial.c#L742
>> Thank you for this link! It helps handle the fifo full condition.
>> However, I noticed a strange value regarding version register. My omap3530 reports 0x46?
>> Linux serial driver assume this bug is present on revision >= 0x52 ...
>> But my target freeze when I send more than 16 chars at once (Fifo full without errata handling).
>> It works when using errata handling.
> 
> It seems the 16550-compatible UARTs on the OMAP processor are special
> and also buggy requiring more or less heavy workarounds, unfortunately.
> I can't comment on that as I do not have experience with OMAP processors.
> 
>> You'll find attached a patch that works for me.
>> Please advise. Maybe we can enhance it and push it?
> 
> To handle hardware-specific initialization I/O properly, I think we need
> first a more flexible interface using callback functions. The existing
> interface with
> 
> 	base = ctx->base_addr;
> 	mode = rt_16550_io_mode_from_ctx(ctx);
> 	regshift = ctx->regshift;
> 	rt_16550_reg_in(mode, base, regshift, offset)",
> 
> #ifdef's and switch statements in the I/O functions is really horrible.
> A more elegant solution would make integration of the OMAP specialities
> much easier.

I will wait for Wolfgang's ack before merging anything, then.

-- 
                                                                Gilles.