RE: [RFC][PATCH]: Adding support for omap-serail driver

From: Pandita, Vikram
Date: Tue Sep 01 2009 - 10:58:19 EST


>-----Original Message-----
>From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of
>Sent: Tuesday, September 01, 2009 2:14 AM
>Cc: vimal singh; linux-omap@xxxxxxxxxxxxxxx; LKML; linux-serial@xxxxxxxxxxxxxxx; Ye Yuan.Bo-A22116;
>Chen Xiaolong-A21785
>Subject: Re: [RFC][PATCH]: Adding support for omap-serail driver
>On Mon, Aug 31, 2009 at 5:20 PM, HU TAO-TGHK48<taohu@xxxxxxxxxxxx> wrote:
>> 1. Shall we cleanup PM related stuff in arch/arm/mach-omap2/serial.c as
>> well?
>>    Originally serail.c register UART IRQ  to decide if UART idle for a
>> while and is able to enter low power mode (e.g. retention).
>>    To work with original 8250 driver, it is probably the only way since
>> 8250 is not aware of OMAP PM.
>>    However  it would be more reasonable to merge PM stuff to
>> omap-serial.c. since the new driver is already OMAP specific
>> 2. There is an issue for DMA  with current implementation in serial.c
>>    When Rx DMA is active NO Rx IRQ will be generated.
>>    So serial.c will easily set uart->can_sleep with "1" even there is
>> Rx DMA ongoing
>>    +   if ((iir & 0x4) && up->use_dma) {
>>    +           up->ier &= ~UART_IER_RDI;
>>    +           serial_out(up, UART_IER, up->ier
>>   In my view, the best way is to do the idle detection in
>> omap_serial.c.
>Yes I understand that we cannot adapt 8250 PM model for omap-serial
>driver in DMA mode I am currently working on that adaption with dma
>mode and will be posting a separate patch for changes on serial.c.
>Wouldn't it be cleaner to inherit and adapt the Serial-PM framework
>from serial.c rather than redefining the PM changes in the driver.
>As Serial-PM framework already has support for interrupt mode and we
>have to adapt the same for DMA mode.
>Also defining PM changes in omap-serial would need changes in PM framework.
>As PM framework calls functions from serail.c file if we are defining
>PM framework in our driver then we may need to redefine the functions
>as in serial.c or modify the PM-framework for uart-activity check.
>I feel adapting the existing serial-PM framework for DMA mode would be
>better rather than
>doing these changes.

You can take reference of how to integrate omap-serial driver PM
with mach-omap2/serial.c as follows, for reference ---