headers
Govindraj | 1 Sep 2009 09:13
Picon

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

On Mon, Aug 31, 2009 at 5:20 PM, HU TAO-TGHK48<taohu <at> motorola.com> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Govindraj | 1 Sep 2009 16:10
Picon

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

On Fri, Aug 28, 2009 at 7:35 PM, Alan Cox<alan <at> lxorguk.ukuu.org.uk> wrote:
>> +#define UART_BASE(uart_no)           (uart_no == UART1) ? OMAP_UART1_BASE :\
>> +                                     (uart_no == UART2) ? OMAP_UART2_BASE :\
>> +                                      OMAP_UART3_BASE
>
> Would be cleaner if this was simply an array (and probably faster)
>
>> +
>> +#define UART_MODULE_BASE(uart_no)    (UART1 == uart_no ? \
>> +                                             IO_ADDRESS(OMAP_UART1_BASE) :\
>> +                                     (UART2 == uart_no ? \
>> +                                             IO_ADDRESS(OMAP_UART2_BASE) :\
>> +                                             IO_ADDRESS(OMAP_UART3_BASE)))
>
> Ditto
>
>> +extern unsigned int fcr[MAX_UARTS];
>> +extern char *saved_command_line;
>
> We really don't wang globals floating around with names like fcr - and
> why is saved command line needed when we have module option parsing
> functions ?
>
>
>> +unsigned int fcr[MAX_UARTS];
>> +unsigned long up_activity;
>
> Not acceptable as global names - too big a risk of clashes
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pandita, Vikram | 1 Sep 2009 16:58
Picon
Favicon

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

govindraj

>-----Original Message-----
>From: linux-omap-owner <at> vger.kernel.org [mailto:linux-omap-owner <at> vger.kernel.org] On Behalf Of
>Govindraj
>Sent: Tuesday, September 01, 2009 2:14 AM
>To: HU TAO-TGHK48
>Cc: vimal singh; linux-omap <at> vger.kernel.org; LKML; linux-serial <at> vger.kernel.org; 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 <at> motorola.com> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Govindraj | 2 Sep 2009 10:40
Picon

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

Vikram,

> What about UART3 supporting IRDA and CIR modes?
> Is that planned to be added?
>

We do have an driver to support IrDA -- > drivers/net/irda/omap-ir.c

>>+static unsigned int check_modem_status(struct uart_omap_port *up)
>
> What is the use case for modem_status?

This is basically used to handle any change in uart line[cts,dcd],
like an change in status of cts line should be handled
which is done using the function by checking the MSR[modem status register].

>>+              if (jiffies_to_msecs(jiffies - up_activity) < 10000) {
>>+                      mod_timer(&up->uart_dma.rx_timer, jiffies +
>>+                              usecs_to_jiffies(up->uart_dma.rx_timeout));
>
> Is this a 10 second timeout? Is this acceptable way?
> This has to be done in conjunction with the inactivity timer in mach-omap2/serial.c

This timeout is the period where we except some activity on rx line as
we dont the time period we receive data hence we keep rx dma channel
active for minimum of 10 secs, however this can be reduced.

-----
Regards,
Govindraj.R
(Continue reading)

Permalink | Reply | 0 comments |
headers
HU TAO-TGHK48 | 3 Sep 2009 07:40

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


> -----Original Message-----
> From: Govindraj [mailto:govindraj.ti <at> gmail.com] 
> Sent: Tuesday, September 01, 2009 3:14 PM
> To: HU TAO-TGHK48
> Cc: vimal singh; linux-omap <at> vger.kernel.org; LKML; 
> linux-serial <at> vger.kernel.org; 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 <at> motorola.com> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
HU TAO-TGHK48 | 3 Sep 2009 07:46

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


I don't  see much added value to use omap_uart_idle_timer() in serial.c since it will be called anyway after timeout.

Is it more simple to do it in omap_uart_prepare_idle()?
Hence omap_uart_prepare_idle() can be move into driver/serial/omap_serial.c eventually.

>  
> +extern int are_driveromap_uarts_active(int *);
> +
>  static void omap_uart_idle_timer(unsigned long data)
>  {
>  	struct omap_uart_state *uart = (struct omap_uart_state *)data;
> +	int dummy;
> +
> +	if (are_driveromap_uarts_active(&dummy)){
> +		/* Keep UART on NoIdle when DMA channel is 
> enabled in omap
> +		 * serial: do not allow UART to goto Smart-idle 
> till its done
> +		 * dma'ing
> +		 */
> +		omap_uart_block_sleep(uart);
> +		return;
> +	}
>  
>  	omap_uart_allow_sleep(uart);
>  }
> 

> -----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jiri Slaby | 6 Sep 2009 23:10
Picon
Gravatar

[PATCH 1/2] Char: riscom8, fix tty refcnt

Stanse found a tty refcnt leak on one fail path in rc_transmit.
Fix that by jumping to the 'out' label.

http://stanse.fi.muni.cz/

Signed-off-by: Jiri Slaby <jirislaby <at> gmail.com>
---
 drivers/char/riscom8.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/riscom8.c b/drivers/char/riscom8.c
index 3c7cf2c..3cfa22d 100644
--- a/drivers/char/riscom8.c
+++ b/drivers/char/riscom8.c
 <at>  <at>  -467,7 +467,7  <at>  <at>  static void rc_transmit(struct riscom_board const *bp)
 			rc_out(bp, CD180_CCR, CCR_CORCHG2);
 			port->break_length = 0;
 		}
-		return;
+		goto out;
 	}

 	count = CD180_NFIFO;
--

-- 
1.6.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jiri Slaby | 6 Sep 2009 23:10
Picon
Gravatar

[PATCH 2/2] USB: serial/mct_u232, fix tty refcnt

Stanse found a tty refcnt leak in read_int_callback. In fact
it's handled wrong altogether. tty_port_tty_get can return NULL
and it's not checked in that manner.

Fix that by checking the tty_port_tty_get retval and put tty kref
properly.

http://stanse.fi.muni.cz/

Signed-off-by: Jiri Slaby <jirislaby <at> gmail.com>
---
 drivers/usb/serial/mct_u232.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c
index d501aef..ad4998b 100644
--- a/drivers/usb/serial/mct_u232.c
+++ b/drivers/usb/serial/mct_u232.c
 <at>  <at>  -566,10 +566,13  <at>  <at>  static void mct_u232_read_int_callback(struct urb *urb)
 	 * Work-a-round: handle the 'usual' bulk-in pipe here
 	 */
 	if (urb->transfer_buffer_length > 2) {
-		tty = tty_port_tty_get(&port->port);
 		if (urb->actual_length) {
-			tty_insert_flip_string(tty, data, urb->actual_length);
-			tty_flip_buffer_push(tty);
+			tty = tty_port_tty_get(&port->port);
+			if (tty) {
+				tty_insert_flip_string(tty, data,
+						urb->actual_length);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Korsgaard | 9 Sep 2009 16:54
Picon

[PATCH-RESEND] uartlite: support shared interrupt lines

Adapt isr to work with shared interrupt lines.

Signed-off-by: Peter Korsgaard <jacmet <at> sunsite.dk>
---
 drivers/serial/uartlite.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 3317148..beb6632 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
 <at>  <at>  -154,17 +154,22  <at>  <at>  static int ulite_transmit(struct uart_port *port, int stat)
 static irqreturn_t ulite_isr(int irq, void *dev_id)
 {
 	struct uart_port *port = dev_id;
-	int busy;
+	int busy, n = 0;

 	do {
 		int stat = readb(port->membase + ULITE_STATUS);
 		busy  = ulite_receive(port, stat);
 		busy |= ulite_transmit(port, stat);
+		n++;
 	} while (busy);

-	tty_flip_buffer_push(port->info->port.tty);
-
-	return IRQ_HANDLED;
+	/* work done? */
+	if (n > 1) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dick Hollenbeck | 15 Sep 2009 23:35

remapping advice sought


I made an ARM board with 6 serial ports.  One port comes out on 
/dev/ttyAM0 and 5 others come out on /dev/ttyS0 through /dev/ttyS4.

The ttyAM0 is implemented by an ARM CPU specific driver, while the ttyS* 
ports are implemented in an FPGA and use the 8250.c driver in a 
multi-port fashion with a shared IRQ.

Our userspace code likes to think of serial ports being at /dev/ttyS0 
through /dev/ttyS5 but this naming convention has not yet been achieved.

(1) Are there any good reason why not to do this:

(A) change my copy of the kernel code so that 8250.c exposes its serial 
ports at some other name than "ttyS".

(B) use symlinks in /dev/ to map ttyS0 through ttyS5 onto ttyAM0 
followed by the 8250 FPGA ports.

(2) How hard and fast is the relationship between the name used in the 
driver 8250.c, to the name in the /dev/ directory? Can they be different 
without changing 8250.c source?

(3) Is there a better way?

Thanks,

Dick

--
(Continue reading)

Permalink | Reply | 1 comment |

Gmane