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. Wolfgang. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help