RE: serial on omap in current git.

RE: serial on omap in current git.

[Woodruff, Richard]

Actually it is more like this...


if (up->port.type != PORT_16750) {
	if (fcr & UART_FCR_ENABLE_FIFO) {
		/* emulated UARTs (Lucent Venus 167x) need two steps */
		serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
	}
	if(uart_config[up->port.type].flags & UART_CAP_EFR){
		serial_outp(up, UART_LCR, 0xBF); /*allow access to
EFR(vs LCR)*/
		serial_outp(up, UART_EFR, UART_EFR_ECB);/*allow FCR tx
fifo write*/
		serial_outp(up, UART_LCR, 0x0); /* access back to FCR */
		serial_outp(up, UART_FCR, fcr); /* set fcr with possible
TX fifo setting */
		serial_outp(up, UART_LCR, 0xBF);
		serial_outp(up, UART_EFR, 0);
		serial_outp(up, UART_LCR, cval); /* access back to FCR
*/
	} else
		serial_outp(up, UART_FCR, fcr);

In my build your last serial hack is not necessary anymore either.

I played around a bit trying to remove several of them.  To use the
actual TX watermark interrupt set at 32bytes required too ugly of a hack
to use (not use OMAP_SCR=0).

A minor note is we are still only using 32 bytes of the 64 byte TX fifo
for transmits in the current code.  I'm not sure if there is an
application that this matters to.


Regards,
Richard W.


> -----Original Message-----
> From: Woodruff, Richard
> Sent: Tuesday, February 07, 2006 6:19 PM
> To: 'Tony Lindgren'
> Cc: Linux-omap-open-source@linux.omap.com
> Subject: RE: serial on omap in current git.
> 
> Here is one it should get the FCR set correctly.  There is still
something
> wrong though.
> 
> Regards,
> Richard W.
> 
> 
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony@atomide.com]
> > Sent: Tuesday, February 07, 2006 6:14 PM
> > To: Woodruff, Richard
> > Cc: Linux-omap-open-source@linux.omap.com
> > Subject: Re: serial on omap in current git.
> >
> > * Woodruff, Richard <r-woodruff2@ti.com> [060207 16:00]:
> > > Tony,
> > >
> > > Not that it fixes the issue you saw but it may half explain
others.
> With
> > > the tx threshold interrupt.
> > >
> > > 	The:
> > > 		serial_outp(up, UART_FCR, fcr) in
> > > serial8250_set_termios() won't set the UART_FCR_T_TRIG_10 as
expected
> as
> > > the UART_EFR.UART_EFR_ECB bit is not set.  Bits 5:4 of the FCR are
not
> > > settable with out the EFR bit4 set.
> > >
> > > The current code seems to only think it needs to set the ECB at
sleep
> > > time, else it just writes a 0 back into the EFR.
> >
> > Thanks. Do you have a patch around for that?
> >
> > Tony

Re: serial on omap in current git.

[Tony Lindgren]

Hi,

* Woodruff, Richard <r-woodruff2@ti.com> [060212 14:15]:
> Actually it is more like this...
> 
> 
> if (up->port.type != PORT_16750) {
> 	if (fcr & UART_FCR_ENABLE_FIFO) {
> 		/* emulated UARTs (Lucent Venus 167x) need two steps */
> 		serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
> 	}
> 	if(uart_config[up->port.type].flags & UART_CAP_EFR){
> 		serial_outp(up, UART_LCR, 0xBF); /*allow access to
> EFR(vs LCR)*/
> 		serial_outp(up, UART_EFR, UART_EFR_ECB);/*allow FCR tx
> fifo write*/
> 		serial_outp(up, UART_LCR, 0x0); /* access back to FCR */
> 		serial_outp(up, UART_FCR, fcr); /* set fcr with possible
> TX fifo setting */
> 		serial_outp(up, UART_LCR, 0xBF);
> 		serial_outp(up, UART_EFR, 0);
> 		serial_outp(up, UART_LCR, cval); /* access back to FCR
> */
> 	} else
> 		serial_outp(up, UART_FCR, fcr);

So the extended capabilities bit is needed to write fcr, or else some
settings don't get set?
 
> In my build your last serial hack is not necessary anymore either.

Looks like patch f5968b37b3ad35b682b574b578843a0361218aff fixed it in
the mainline 8250.c:

http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f5968b37b3ad35b682b574b578843a0361218aff;hp=620739025b94fe472c845ce013bff62716d3c576
 
> I played around a bit trying to remove several of them.  To use the
> actual TX watermark interrupt set at 32bytes required too ugly of a hack
> to use (not use OMAP_SCR=0).

Can you list the 8250.c issues you've seen?
 
> A minor note is we are still only using 32 bytes of the 64 byte TX fifo
> for transmits in the current code.  I'm not sure if there is an
> application that this matters to.

I guess that could help on bluetooth maybe.

Regards,

Tony

RE: serial on omap in current git.

[Woodruff, Richard]

> So the extended capabilities bit is needed to write fcr, or else some
> settings don't get set?

That is what the OMAP-UART data sheet says.  The write water mark bits
4:5 are not accessible unless ECB is set.

The data sheet says it is TI16C750 compatible but it seems to share more
with what the code calls a TI16C752.  The 750 has a DLAB to set 64bit
fifo and I don't believe that is the case for ours.

The code id's it as a 16654 which isn't quite correct.

> Can you list the 8250.c issues you've seen?

The TX watermark, the IRQ_HANDLED not working, then the recent error
which you worked around.
 
> > A minor note is we are still only using 32 bytes of the 64 byte TX
fifo
> > for transmits in the current code.  I'm not sure if there is an
> > application that this matters to.
> 
> I guess that could help on bluetooth maybe.

Sure.  For fast Bluetooth I would think both DMA and flow control should
also be enabled.  I doubt both would just work given it identified
wrongly and the details around these areas are exactly what are
differently between the 554/750/752 as far as I can tell.

Regards,
Richard W.

Re: serial on omap in current git.

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [060213 10:51]:
> > So the extended capabilities bit is needed to write fcr, or else some
> > settings don't get set?
> 
> That is what the OMAP-UART data sheet says.  The write water mark bits
> 4:5 are not accessible unless ECB is set.
> 
> The data sheet says it is TI16C750 compatible but it seems to share more
> with what the code calls a TI16C752.  The 750 has a DLAB to set 64bit
> fifo and I don't believe that is the case for ours.
> 
> The code id's it as a 16654 which isn't quite correct.
> 
> > Can you list the 8250.c issues you've seen?
> 
> The TX watermark, the IRQ_HANDLED not working, then the recent error
> which you worked around.
>  
> > > A minor note is we are still only using 32 bytes of the 64 byte TX
> fifo
> > > for transmits in the current code.  I'm not sure if there is an
> > > application that this matters to.
> > 
> > I guess that could help on bluetooth maybe.
> 
> Sure.  For fast Bluetooth I would think both DMA and flow control should
> also be enabled.  I doubt both would just work given it identified
> wrongly and the details around these areas are exactly what are
> differently between the 554/750/752 as far as I can tell.

I've pushed this, let's see how it works and then send it to RMK.

Tony

RE: serial on omap in current git.

[Woodruff, Richard]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

Here is one it should get the FCR set correctly.  There is still
something wrong though.

Regards,
Richard W.


> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Tuesday, February 07, 2006 6:14 PM
> To: Woodruff, Richard
> Cc: Linux-omap-open-source@linux.omap.com
> Subject: Re: serial on omap in current git.
> 
> * Woodruff, Richard <r-woodruff2@ti.com> [060207 16:00]:
> > Tony,
> >
> > Not that it fixes the issue you saw but it may half explain others.
With
> > the tx threshold interrupt.
> >
> > 	The:
> > 		serial_outp(up, UART_FCR, fcr) in
> > serial8250_set_termios() won't set the UART_FCR_T_TRIG_10 as
expected as
> > the UART_EFR.UART_EFR_ECB bit is not set.  Bits 5:4 of the FCR are
not
> > settable with out the EFR bit4 set.
> >
> > The current code seems to only think it needs to set the ECB at
sleep
> > time, else it just writes a 0 back into the EFR.
> 
> Thanks. Do you have a patch around for that?
> 
> Tony

[-- Attachment #2: serial.diff --]
[-- Type: application/octet-stream, Size: 670 bytes --]

--- linux-omap-2.6-dev/drivers/serial/8250.c	2006-02-07 15:10:12.000000000 -0600
+++ linux-omap-2.6/drivers/serial/8250.c	2006-02-07 17:03:28.000000000 -0600
@@ -1887,6 +1887,10 @@ serial8250_set_termios(struct uart_port 
 	serial_outp(up, UART_LCR, cval);		/* reset DLAB */
 	up->lcr = cval;					/* Save LCR */
 	if (up->port.type != PORT_16750) {
+		if(uart_config[up->port.type].flags & UART_CAP_EFR){
+			serial_outp(up, UART_EFR, UART_EFR_ECB);
+			printk("\nMAKE SURE TX THRESHOLD GETS SET in FCR write \n");
+		}
 		if (fcr & UART_FCR_ENABLE_FIFO) {
 			/* emulated UARTs (Lucent Venus 167x) need two steps */
 			serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

serial on omap in current git.

[Woodruff, Richard]

Tony,

Not that it fixes the issue you saw but it may half explain others. With
the tx threshold interrupt.

	The:
		serial_outp(up, UART_FCR, fcr) in
serial8250_set_termios() won't set the UART_FCR_T_TRIG_10 as expected as
the UART_EFR.UART_EFR_ECB bit is not set.  Bits 5:4 of the FCR are not
settable with out the EFR bit4 set.

The current code seems to only think it needs to set the ECB at sleep
time, else it just writes a 0 back into the EFR.

Regards,
Richard W.

Re: serial on omap in current git.

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [060207 16:00]:
> Tony,
> 
> Not that it fixes the issue you saw but it may half explain others. With
> the tx threshold interrupt.
> 
> 	The:
> 		serial_outp(up, UART_FCR, fcr) in
> serial8250_set_termios() won't set the UART_FCR_T_TRIG_10 as expected as
> the UART_EFR.UART_EFR_ECB bit is not set.  Bits 5:4 of the FCR are not
> settable with out the EFR bit4 set.
> 
> The current code seems to only think it needs to set the ECB at sleep
> time, else it just writes a 0 back into the EFR.

Thanks. Do you have a patch around for that?

Tony