headers
Russell King | 1 Nov 2004 13:10
Picon

Re: [PATCH] 8250 driver interrupt sharing

On Thu, Oct 28, 2004 at 01:01:58PM +0200, Thomas Koeller wrote:
> here is a little patch that causes the driver to no longer pretend having
> handled an interrupt if none of the ports actually interrupted. I am currently
> doing a port to a platform where I want (actually, have) to share a single
> interrupt between serial ports and other devices. The patch is against kernel
> version 2.6.9.

Ok, a variant of this has now been applied - using IRQ_RETVAL rather
than irqreturn_t + IRQ_NONE + IRQ_HANDLED.

Thanks.

--

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core
-
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
Thomas Koeller | 4 Nov 2004 14:30
Favicon

[PATCH]

Hi,

I made the 8250 driver work on the internal UART found on
PMC-Sierra RM9000 MIPS CPUs. To do so, I did

- define the register layout, which is different from the standard
  layout, in include/linux/serial_reg.h

- add a new register access type named UPIO_PORT32 for I/O
  registers that must be accessed as 32-bit entities

- add a new port type PORT_RM9000 in include/linux/serial_core.h

While being at it, I also fixed a couple of missing resource
allocations for UPIO_MEM32.

tk

Signed-off-by: Thomas Koeller <thomas.koeller <at> baslerweb.com>

diff -rpu linux-2.6.9-old/drivers/serial/8250.c linux-2.6.9/drivers/serial/8250.c
--- linux-2.6.9-old/drivers/serial/8250.c	2004-10-28 12:45:30.000000000 +0200
+++ linux-2.6.9/drivers/serial/8250.c	2004-11-04 14:11:42.636338544 +0100
 <at>  <at>  -174,6 +174,7  <at>  <at>  static const struct serial8250_config ua
 	{ "RSA",	2048,	2048,	UART_CAP_FIFO },
 	{ "NS16550A",	16,	16,	UART_CAP_FIFO | UART_NATSEMI },
 	{ "XScale",	32,	32,	UART_CAP_FIFO },
+	{ "RM9000",	16,	16,	UART_CAP_FIFO }
 };
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Grimes | 7 Nov 2004 15:04
Favicon

=\

While I'm sitting here waiting for my linux machine to serve a login to 
my terminal emulator on my BeOS machine over a serial cable, (it takes 
a minute or two to respond under this 2.6.9 kernel as opposed to 
instantly for the 2.4.27 kernel), I'm going to report a very serious 
bug.. (admittedly, this absurdly long latancy is also present on the 
regular console but linux offers far too few clues as to why...) 

Hitting enter exactly once to cause the logon prompt to appear causes 
several logon prompts to appear over the next several seconds. However, 
when login is accomplished the machine behaves very well. -- go figure. 

I am beginning to suspect that the reason I can't get a reliable dialup 
connection using the other serial port (an actual hardware port on the 
back of the machine), is that tthe serial driver or something in the 
kernel which, in some way, supports the serial port causes all outbound 
network trafic to (apparently) fail. and completely precludes all 
inbound trafic. 

Recompiling the kernel last night I found that there were different ppp 
drivers for synchronous and asynchronoous ports... I made sure those 
were correct.. I hoped that would fix it, it seemed to at first but now 
it is as unreliable as ever...

A typical dialup session on 2.6.9 will -- about 2/3rds of the time, 
successfully chat with the modem and make a connection. -- Other times 
the chat fails randomly during any part of the process from 
initializing the modem to negotiating a PPP session. 

Earlier 2.6 kernels would disconnect randomly, this one just freezes. =
\
(Continue reading)

Permalink | Reply | 0 comments |
headers
Support | 18 Nov 2004 12:01
Picon

Your support request

Thank you for contacting Activision. 

Please use the online database at <http://www.activision.com/support> to
find answers for any issues you may be having with our products.

For Activision Value products go to <http://www.activisionvalue.com>

If you are looking for help getting through a game, try
<http://www.gamefaqs.com>

This is an automated response.
-
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
Ian Abbott | 26 Nov 2004 21:14
Picon
Favicon
Gravatar

[PATCH][2.6.10-rc2-bk9] 8250 fix for unconfigured FIFO size

Hi,

In the 8250 driver, for a serial port manually configured by setserial 
(not using autoconfig), the FIFO size and the TX load size do not get 
set.  The attached patch fixes that.  During UART startup, it sanitizes 
the FIFO size and the TX load size.

This might also fix Alexandre Courbot's problem (which I suspect is due 
to the old FIFO size being remembered):

 > Subject: Bug with 2.6 serial driver when in UART 8250 mode
 > Date: Thu, 19 Aug 2004 18:53:49 +0200

Signed-off-by: Ian Abbott <abbotti <at> mev.co.uk>
Attachment (8250_fifosize.patch): text/x-patch, 775 bytes
Permalink | Reply | 0 comments |
headers
Ian Abbott | 26 Nov 2004 22:29
Picon
Favicon
Gravatar

[PATCH][2.6.10-rc2-bk9] Assume struct uart_state closing times are in centiseconds

[Reposting due to Cc: address mix-up the first time!]

Hi,

The current use of close_delay and closing_wait within serial_core.c is
a little messed up for the following reasons:

* The values are scaled by uart_set_info() but not scaled back by
uart_get_info(), so the values are different unless HZ==100.

* The closing_wait value is scaled by uart_set_info() and compared to an
unscaled magic value USF_CLOSING_WAIT_NONE in uart_close().

As uart_set_info already assumes that the new values are in centisecond
units and scaling could mess up the comparison with magic values (even
if the magic values are scaled), I propose to store the raw centisecond
values in struct uart_state and scale them at the point of use.  Here is
a patch to do that.

Signed-off-by: Ian Abbott <abbotti <at> mev.co.uk>
Attachment (serial_closing_time.patch): text/x-patch, 2277 bytes
Permalink | Reply | 0 comments |
headers
Ian Abbott | 26 Nov 2004 22:32
Picon
Favicon
Gravatar

[PATCH][2.6.10-rc2-bk9] 8250 fix for unconfigured FIFO size

[Reposting due to Cc: address mix-up the first (and second) time!]

Hi,

In the 8250 driver, for a serial port manually configured by setserial
(not using autoconfig), the FIFO size and the TX load size do not get
set.  The attached patch fixes that.  During UART startup, it sanitizes
the FIFO size and the TX load size.

This might also fix Alexandre Courbot's problem (which I suspect is due
to the old FIFO size being remembered):

  > Subject: Bug with 2.6 serial driver when in UART 8250 mode
  > Date: Thu, 19 Aug 2004 18:53:49 +0200

Signed-off-by: Ian Abbott <abbotti <at> mev.co.uk>
Attachment (8250_fifosize.patch): text/x-patch, 776 bytes
Permalink | Reply | 0 comments |
headers
Ian Abbott | 26 Nov 2004 22:30
Picon
Favicon
Gravatar

[PATCH][2.6.10-rc2-bk9] 8250 fix for unconfigured FIFO size

[Reposting due to Cc: address mix-up the first time!]

Hi,

In the 8250 driver, for a serial port manually configured by setserial
(not using autoconfig), the FIFO size and the TX load size do not get
set.  The attached patch fixes that.  During UART startup, it sanitizes
the FIFO size and the TX load size.

This might also fix Alexandre Courbot's problem (which I suspect is due
to the old FIFO size being remembered):

  > Subject: Bug with 2.6 serial driver when in UART 8250 mode
  > Date: Thu, 19 Aug 2004 18:53:49 +0200

Signed-off-by: Ian Abbott <abbotti <at> mev.co.uk>
Attachment (8250_fifosize.patch): text/x-patch, 776 bytes
Permalink | Reply | 0 comments |
headers
Ian Abbott | 26 Nov 2004 19:16
Picon
Favicon
Gravatar

[PATCH][2.6.10-rc2-bk9] Assume struct uart_state closing times are in centiseconds

Hi,

The current use of close_delay and closing_wait within serial_core.c is 
a little messed up for the following reasons:

* The values are scaled by uart_set_info() but not scaled back by 
uart_get_info(), so the values are different unless HZ==100.

* The closing_wait value is scaled by uart_set_info() and compared to an 
unscaled magic value USF_CLOSING_WAIT_NONE in uart_close().

As uart_set_info already assumes that the new values are in centisecond 
units and scaling could mess up the comparison with magic values (even 
if the magic values are scaled), I propose to store the raw centisecond 
values in struct uart_state and scale them at the point of use.  Here is 
a patch to do that.

Signed-off-by: Ian Abbott <abbotti <at> mev.co.uk>
Attachment (serial_closing_time.patch): text/x-patch, 2276 bytes
Permalink | Reply | 0 comments |
headers
Al Viro | 27 Nov 2004 19:42
Picon
Picon

[PATCH] sunzilog iomem annotations

Signed-off-by: Al Viro <viro <at> parcelfarce.linux.theplanet.co.uk>
----
diff -urN RC10-rc2-bk8-fore200e/drivers/serial/sunzilog.c RC10-rc2-bk8-sunzilog/drivers/serial/sunzilog.c
--- RC10-rc2-bk8-fore200e/drivers/serial/sunzilog.c	Tue Nov 23 19:52:12 2004
+++ RC10-rc2-bk8-sunzilog/drivers/serial/sunzilog.c	Sat Nov 27 12:58:40 2004
 <at>  <at>  -112,7 +112,7  <at>  <at> 
 #endif
 };

-#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel *)((PORT)->membase))
+#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))
 #define UART_ZILOG(PORT)		((struct uart_sunzilog_port *)(PORT))

 #define ZS_IS_KEYB(UP)	((UP)->flags & SUNZILOG_FLAG_CONS_KEYB)
 <at>  <at>  -133,7 +133,7  <at>  <at> 
  * The port lock must be held and local IRQs must be disabled
  * when {read,write}_zsreg is invoked.
  */
-static unsigned char read_zsreg(struct zilog_channel *channel,
+static unsigned char read_zsreg(struct zilog_channel __iomem *channel,
 				unsigned char reg)
 {
 	unsigned char retval;
 <at>  <at>  -146,7 +146,7  <at>  <at> 
 	return retval;
 }

-static void write_zsreg(struct zilog_channel *channel,
+static void write_zsreg(struct zilog_channel __iomem *channel,
 			unsigned char reg, unsigned char value)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane