headers
[frid04@pochta.ru] | 2 Aug 2005 18:18
Picon
Favicon

REPRESENTATIVE NEEDED,

Dear friend, 

I represent WFS INC based in Finland. My company markets and exports 
cotton,cocoa and other products for world trade. We are searching for 
representatives who can help us establish a medium of getting to our 
customers in Europe and America as well as making payments through 
you as our payment officer. It is upon this note that we seek your 
assistance to stand as our representative in your country.

Note that, as our representative, you will receive 5% of whatever 
amount you clear for the company and the balance will be paid into an 
account we will avail to you. Please, to facilitate the conclusion of 
this transaction if accepted, do send me promptly by email the 
following:

(1)Your full names.
(2)Contact address.and,Phone/fax numbers. 
(3)Age.

Thank you for your time.

Very Respectfully,

 
Mr Sauerwald Wilhelm Fridrich. President, 
WFS INC. 
Finland.

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Budd | 4 Aug 2005 03:36
Picon

2.4.21: Sharing interrupts with serial console

I have read http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/preparation-setport.html
and http://www.linux-mips.org/archives/linux-mips/2004-04/msg00134.html
and other items, but I still have not found the answers to the
following questions:

1.  The rs_init function in ./linux-2.4.21/drivers/char/serial.c
explicitly states "The interrupt of the serial console port can't be
shared."  Does this include *ALL* interrupts?  The code checks for
sharing only with other serial devices, not *ALL* types of devices
like I2C, RTC, etc.

2.  While the presence of the comment about not sharing was nice, it
does not explain "why?"  Why can't we share the serial console
interrupt?  The serial console seems to work when I alter serial.c to
skip this check for the sharing of interrupts with the serial console.

3.  Does the hardware platform matter?  We are running Linux 2.4.21 on
an embedded XScale(ARM)-based board.

Thanks,
Chris.
-
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
Permalink | Reply | 0 comments |
headers
Russell King | 4 Aug 2005 09:54
Picon

Re: 2.4.21: Sharing interrupts with serial console

On Wed, Aug 03, 2005 at 06:36:51PM -0700, Chris Budd wrote:
> 1.  The rs_init function in ./linux-2.4.21/drivers/char/serial.c
> explicitly states "The interrupt of the serial console port can't be
> shared."  Does this include *ALL* interrupts?  The code checks for
> sharing only with other serial devices, not *ALL* types of devices
> like I2C, RTC, etc.

I think you'll find that older versions of the serial driver did not
allow the IRQ to be shared by other devices.  It probably got changed
with the addition of PCI card support.

> 2.  While the presence of the comment about not sharing was nice, it
> does not explain "why?"

Connecting a level-active interrupt output to an edge-triggered
interrupt controller input is Bad News(tm) for missing interrupts.

The situation is as follows:
- serial port asserts interrupt output which triggers an interrupt
  to the CPU.  You enter the serial handler.

- Before you clear the serial interrupt, the other device sharing
  this interrupt asserts its interrupt output - so there was no
  edge transition.

- You complete service the serial port, and move on to service the
  other device.

- Before you clear it's interrupt, the serial port re-asserts its
  interrupt output, and again there was no edge transition as far
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Budd | 4 Aug 2005 16:29
Picon

Re: 2.4.21: Sharing interrupts with serial console

On 8/4/05, Russell King <rmk+lkml <at> arm.linux.org.uk> wrote:
> On Wed, Aug 03, 2005 at 06:36:51PM -0700, Chris Budd wrote:
> > 1.  The rs_init function in ./linux-2.4.21/drivers/char/serial.c
> > explicitly states "The interrupt of the serial console port can't be
> > shared."  Does this include *ALL* interrupts?  The code checks for
> > sharing only with other serial devices, not *ALL* types of devices
> > like I2C, RTC, etc.
<snip>
> > 2.  While the presence of the comment about not sharing was nice, it
> > does not explain "why?"
> 
> Connecting a level-active interrupt output to an edge-triggered
> interrupt controller input is Bad News(tm) for missing interrupts.
> 

Of course.  I thought it was something more serious in the bowels of
the kernel.  All the comment needed was just that one adjective "The
*edge-triggered* interrupt of the serial console port can't be
shared."  I know many programmers do not like to write comments, but
good comments make the code more robust and stable:  the code clearly
shows *what* you did, but comments are necessary to indicate *why*.

<snip>
> If your Intel hardware doesn't have level triggered input capabilities,
> please apply customer pressure to Intel to ensure that they consider it
> for their future ARM-based designs.

You will be happy to know that the Intel IOP80321 has level-sensitive
interrupts.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ben Papps | 4 Aug 2005 16:36

Hardware Flow Control on 16C950/954 (kernel 2.6.11)

Hi all,

I have found an issue concerning hardware flow control on the 16C950/954 
(specifically I am working on the OX16PCI954/952 devices) in Linux 2.6 
(Specifically the 2.6.11 kernel source (Fedora Core 3)). I have been 
looking at how I can get this small fix made in the kernel, and thought 
that I'd post the issue here first to see what other people think about it.

The short version...: In file 8250.c, in uart_config[], lines 223-229.

[PORT_16C950] = {
.name = “16C950/954”,
.fifo_size = 128,
.tx_loadsz = 128,
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO,
}

They should be*:*

[PORT_16C950] = {
.name = “16C950/954”,
.fifo_size = 128,
.tx_loadsz = 128,
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO *| UART_CAP_EFR | UART_CAP_SLEEP*,
}

These flags allow the enhanced register to be used, allowing flow 
control amongst other things.
(Continue reading)

Permalink | Reply | 0 comments |
headers
linux-os (Dick Johnson | 4 Aug 2005 13:16

Re: 2.4.21: Sharing interrupts with serial console


On Wed, 3 Aug 2005, Chris Budd wrote:

> I have read http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/preparation-setport.html
> and http://www.linux-mips.org/archives/linux-mips/2004-04/msg00134.html
> and other items, but I still have not found the answers to the
> following questions:
>
> 1.  The rs_init function in ./linux-2.4.21/drivers/char/serial.c
> explicitly states "The interrupt of the serial console port can't be
> shared."  Does this include *ALL* interrupts?  The code checks for
> sharing only with other serial devices, not *ALL* types of devices
> like I2C, RTC, etc.
>
> 2.  While the presence of the comment about not sharing was nice, it
> does not explain "why?"  Why can't we share the serial console
> interrupt?  The serial console seems to work when I alter serial.c to
> skip this check for the sharing of interrupts with the serial console.
>
> 3.  Does the hardware platform matter?  We are running Linux 2.4.21 on
> an embedded XScale(ARM)-based board.
>
> Thanks,
> Chris.
> -

Only LEVEL interrupts can be shared, and all the drivers that
share that one interrupt need to be designed for sharing.

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nishanth Aravamudan | 15 Aug 2005 20:28
Picon
Favicon

[-mm PATCH 30/32] serial: fix-up schedule_timeout() usage

Description: Use schedule_timeout_uninterruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size.

Signed-off-by: Nishanth Aravamudan <nacc <at> us.ibm.com>

---

 drivers/serial/crisv10.c |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

diff -urpN 2.6.13-rc5-mm1/drivers/serial/crisv10.c 2.6.13-rc5-mm1-dev/drivers/serial/crisv10.c
--- 2.6.13-rc5-mm1/drivers/serial/crisv10.c	2005-08-07 09:58:14.000000000 -0700
+++ 2.6.13-rc5-mm1-dev/drivers/serial/crisv10.c	2005-08-10 14:27:46.000000000 -0700
 <at>  <at>  -4417,10 +4417,8  <at>  <at>  rs_close(struct tty_struct *tty, struct 
 	info->event = 0;
 	info->tty = 0;
 	if (info->blocked_open) {
-		if (info->close_delay) {
-			set_current_state(TASK_INTERRUPTIBLE);
-			schedule_timeout(info->close_delay);
-		}
+		if (info->close_delay)
+			schedule_timeout_interruptible(info->close_delay);
 		wake_up_interruptible(&info->open_wait);
 	}
 	info->flags &= ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING);
 <at>  <at>  -4470,8 +4468,7  <at>  <at>  static void rs_wait_until_sent(struct tt
 	while (info->xmit.head != info->xmit.tail || /* More in send queue */
 	       (*info->ostatusadr & 0x007f) ||  /* more in FIFO */
 	       (elapsed_usec < 2*info->char_time_usec)) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Horváth Ákos Péter | 29 Aug 2005 15:05
Picon

16550a baud_base < 9600 ???

Hi all,

I need to use serial communication with baud rates under 9600. I tried the 
uart 16550a linux driver, but found that setserial gives back invalid 
argument. The cause is that serial_core.c and 8250.c explicitly disallow 
these settings. Why?

The quick & dirty solution (simply eliminating these limit checks in 
serial_core.c and 8250.c) does GPF. Ok :)

Is it possible now to do serial communication with a device which can only 
1200 baud?

thanks,

MaXX
-
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
Permalink | Reply | 1 comment |
headers
Theodore Ts'o | 30 Aug 2005 16:18
Picon
Picon
Favicon
Gravatar

Re: 16550a baud_base < 9600 ???

On Mon, Aug 29, 2005 at 03:05:56PM +0200, Horv?th ?kos P?ter wrote:
> Hi all,
> 
> I need to use serial communication with baud rates under 9600. I tried the 
> uart 16550a linux driver, but found that setserial gives back invalid 
> argument. The cause is that serial_core.c and 8250.c explicitly disallow 
> these settings. Why?
> 
> The quick & dirty solution (simply eliminating these limit checks in 
> serial_core.c and 8250.c) does GPF. Ok :)
> 
> Is it possible now to do serial communication with a device which can only 
> 1200 baud?

You don't need to edit the serial driver to use baud rates under 9600.
The baud_base argument is not what is used to set the baud rate; it is
used to indicate the clock crystal in the serial card utilized to
calculate the baud rate divisor which is programmed into the UART
given a specific required baud rate. 

If you are using setserial to set the baud rate, you're using the
wrong tool, and you're misunderstanding what you need to do.

Use the stty command to set the baud rate on a port.

						- Ted
-
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
malk | 30 Aug 2005 22:59
Favicon

Exar XR17D158 UART on PCI versus 16550 ISA bus performance

Hi Ted and linux-serial list:

I've seen your name around linux since 1993 and I know you're the serial
driver designer, so I was hoping you could shed some light on a question.

I've got a PC104 computer w/ an 8 port RS422/232 serial board (on the ISA
bus) built on 2 x Exar 16654 UARTS (4 channels each) that have port
addresses they occupy w/ the standard 8 bytes of registers per port.

For testing I've connected ports 1 & 2, 3 & 4, 5 & 6, and 7 & 8 together
w/ null modems.

I have my kernel ticking w/ HZ at 1000 to get 1ms select() timeouts in my
app.  If I send 16 byte messages every millisecond down each port and read
them back on the opposing port, I can run 4 senders and 4 receivers and
things work pretty well.  More than 4 ports in use (both directions)
causes things to get sluggish.  I'm running the ports at 460 kbps and I've
got the low_latency setting active in the driver.  The FIFO triggers are
at 56 bytes on the receive side and 8 bytes on the transmit side.  I'm
using a 2.4.29 kernel and it's a uclibc based embedded setup.

I found the bottleneck seems to be the time it takes to read a register
from a port.  i.e. reading the LSR and RHR each take about 2 microsends
per read.  To determine this I wrote a small kernel module that just does
this in the module_init:

do_gettimeofday(starttime)

for(i=0; i<1000; i++)
{
(Continue reading)

Permalink | Reply | 0 comments |

Gmane