On 01/20/2012 07:46 PM, Gilles Chanteperdrix wrote: > 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.
Well, I'm actually not the maintainer. Jan? Wolfgang. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
