headers
jungjackson | 1 May 2006 01:40

(unknown)

-
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
bec | 1 May 2006 09:56

(unknown)

-
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
Rodolfo Giometti | 2 May 2006 14:21
Picon
Favicon

Re: trouble on serial console for au1100

On Fri, Apr 28, 2006 at 11:19:23AM -0600, Jordan Crouse wrote:
> 
> CCing the serial list too.  It could use more testing, but this seems
> like it might be the answer to the myriad of serial issues that have 
> been reported in the last month or so. 
> 
> I'm ashamed to admit I have no idea if this patch is even in the system or
> not.  If not, I'm sure somebody
> can clean it up and send it in the proper style.

Here:

   http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-au1x00-serial-fix

the patch against «linux-2.6.16-stable» branch for serial support
tested with an au1100 based board.

Here:

   http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-au1x00-serial-real-interrupt

my suggestion to get real interrupts from the serial line (I have
redefined the function «is_real_interrupt()» for the au1x00 CPUs into
the platform «serial.h» file).

Ciao,

Rodolfo

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sergei Organov | 3 May 2006 14:59
Favicon

High baud rates support for Quatech DSP-100.


I've got a Quatech DSP-100 PCMCIA dual RS232 adapter. After adding the
adapter parameters into the 'multi_id' and 'serial_ids' tables of the
serial_cs.c driver, it is now automatically loaded and supports the card
almost fine. However, the card supports baud rates up to 460800, but
using serial_cs I get rates only up to 115200.

On the other hand, Quatech has GPL Linux driver (serial_qt.c) for this
card that has been made for some early 2.6.x kernel version and doesn't
compile for recent 2.6.16. I've managed to hack it to compile for
2.6.16.8, -- it does support 460800 indeed.

So the question is what to do next. I'd like to either modify serial_cs
to support high baud rates or to somehow get serial_qt to the linux
tree. For me it seems that the former is more appropriate as serial_qt
in fact looks like some earlier serial_cs modified by Quatech. OTOH,
supporting high baud rates seems to be very card-specific[1] and IMHO
doesn't fit well into rather generic serial_cs.

Is it OK to put card-specific code into serial_cs (provided it's invoked
only after manufacturer id is checked)? Should it be Kconfig option? Is
there a better way to go?

[1] It basically involves checking of some card-specific config
register(s), then setting another card-specific register accordingly and
setting of the 'uartclk' field of the 'struct uart_port' to
corresponding value.

--

-- 
Sergei.
(Continue reading)

Permalink | Reply | 0 comments |
headers
George G. Davis | 6 May 2006 00:15

[RFC][PATCH] Make sure UART is powered up when dumping MCTRL status

Greetings,

Since serial devices are powered down when not in use and some of those
devices cannot be accessed when powered down, we need to enable power
around calls to get_mcrtl() when dumping port state via uart_line_info().
This resolves hangs observed on some machines while reading serial device
registers when a port is powered off.

Signed-off-by: George G. Davis <gdavis <at> mvista.com>
---

 drivers/serial/serial_core.c |   12 ++++++++++++
 1 files changed, 12 insertions(+)

Index: linux-2.6/drivers/serial/serial_core.c
===================================================================
--- linux-2.6.orig/drivers/serial/serial_core.c
+++ linux-2.6/drivers/serial/serial_core.c
 <at>  <at>  -1652,6 +1652,7  <at>  <at>  static const char *uart_type(struct uart
 static int uart_line_info(char *buf, struct uart_driver *drv, int i)
 {
 	struct uart_state *state = drv->state + i;
+	int pm_state;
 	struct uart_port *port = state->port;
 	char stat_buf[32];
 	unsigned int status;
 <at>  <at>  -1674,9 +1675,16  <at>  <at>  static int uart_line_info(char *buf, str

 	if(capable(CAP_SYS_ADMIN))
 	{
(Continue reading)

Permalink | Reply | 4 comments |
headers
tang2 | 6 May 2006 02:26

Finance managers are wanted (msg id = H )

Hello, your e-mail address linux-serial <at> vger.kernel.org ,  has been taken from the open sources. My name
is Alex Brewster. I am the main manager of Web Click Company. 

We are engaged in software developing and design. The main office of our Company is located in Lithuania. 

We are searching for employees to work in our company worldwide. If you wish to have additional income from
4000 to 10 000 dollars a month, 

working from your house this offer is for you. The choice of vacancies is huge (designers, managers,
auditors, financiers). 

We will offer you the best conditions to work. 

Also if you own a company or if you are managing director of the company we offer you to cooperation with us.  

 Please do not reply to this letter. Send your contact data and your CV  to this e-mail:
acef4urkoc7 <at> yahoo.com -  it is our temproary e-mail. 

linux-serial <at> vger.kernel.org sorry for possible disturbance

------------------------------------------------------------

This email is not sent unsolicited and is in compliance with the

federal CAN-SPAM act.  Your email address was provided to us as

either a reciprocal user of website promotion system(s), or as an

email initially sent by you or your company to which this response
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikhail Kolesnik | 7 May 2006 21:59
Gravatar

Oxford Semiconductor's OXCB950 in 8250_pci.c

Hi.

There was a discussion regarding support of OXCB950 in 2.4.x
http://groups.google.com/group/mlist.linux.serial/browse_frm/thread/baf6d48e25662c5/8ab3b1ea12a43420?tvc=1&q=OXCB950#8ab3b1ea12a43420
Somehow changes did not go into the kernel.

Now detailed data sheet is freely available at
http://www.oxsemi.com/oxford/documents/download/standard/dsheets/oxcb950ds.pdf

I own ST Lab RS232 serial port, model C-130. It is a CardBus Type II,
32-bit, 3.3V. After looking into that old discussion I've made the same
changes for 2.6.16 kernel:
diff -ru linux-2.6.16-orig/drivers/serial/8250_pci.c linux-2.6.16/drivers/serial/8250_pci.c
--- linux-2.6.16-orig/drivers/serial/8250_pci.c	2006-03-23 13:32:17.000000000 +0200
+++ linux-2.6.16/drivers/serial/8250_pci.c	2006-03-23 13:39:08.000000000 +0200
 <at>  <at>  -2045,6 +2045,9  <at>  <at> 
 	{	PCI_VENDOR_ID_OXSEMI, 0x950a,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0,
 		pbn_b0_2_1130000 },
+	{	PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_CB950,
+		PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+		pbn_b0_bt_1_115200 },
 	{	PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_16PCI954,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0,
 		pbn_b0_4_115200 },
diff -ru linux-2.6.16-orig/include/linux/pci_ids.h linux-2.6.16/include/linux/pci_ids.h
--- linux-2.6.16-orig/include/linux/pci_ids.h	2006-03-23 13:32:24.000000000 +0200
+++ linux-2.6.16/include/linux/pci_ids.h	2006-03-23 13:40:32.000000000 +0200
 <at>  <at>  -1808,6 +1808,7  <at>  <at> 
 #define PCI_VENDOR_ID_OXSEMI		0x1415
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russell King | 10 May 2006 18:36
Picon

Re: Oxford Semiconductor's OXCB950 in 8250_pci.c

On Sun, May 07, 2006 at 10:59:42PM +0300, Mikhail Kolesnik wrote:
> There was a discussion regarding support of OXCB950 in 2.4.x
> http://groups.google.com/group/mlist.linux.serial/browse_frm/thread/baf6d48e25662c5/8ab3b1ea12a43420?tvc=1&q=OXCB950#8ab3b1ea12a43420
> Somehow changes did not go into the kernel.

Probably because the 8250_pci split happened prior to this discussion
and it therefore got missed.

> diff -ru linux-2.6.16-orig/drivers/serial/8250_pci.c linux-2.6.16/drivers/serial/8250_pci.c
> --- linux-2.6.16-orig/drivers/serial/8250_pci.c	2006-03-23 13:32:17.000000000 +0200
> +++ linux-2.6.16/drivers/serial/8250_pci.c	2006-03-23 13:39:08.000000000 +0200
>  <at>  <at>  -2045,6 +2045,9  <at>  <at> 
>  	{	PCI_VENDOR_ID_OXSEMI, 0x950a,
>  		PCI_ANY_ID, PCI_ANY_ID, 0, 0,
>  		pbn_b0_2_1130000 },
> +	{	PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_CB950,
> +		PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> +		pbn_b0_bt_1_115200 },

This should probably be pbn_b0_1_115200?

>  	{	PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_16PCI954,
>  		PCI_ANY_ID, PCI_ANY_ID, 0, 0,
>  		pbn_b0_4_115200 },
> diff -ru linux-2.6.16-orig/include/linux/pci_ids.h linux-2.6.16/include/linux/pci_ids.h
> --- linux-2.6.16-orig/include/linux/pci_ids.h	2006-03-23 13:32:24.000000000 +0200
> +++ linux-2.6.16/include/linux/pci_ids.h	2006-03-23 13:40:32.000000000 +0200
>  <at>  <at>  -1808,6 +1808,7  <at>  <at> 
>  #define PCI_VENDOR_ID_OXSEMI		0x1415
>  #define PCI_DEVICE_ID_OXSEMI_12PCI840	0x8403
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russell King | 10 May 2006 18:39
Picon

Re: [RFC][PATCH] Make sure UART is powered up when dumping MCTRL status

On Fri, May 05, 2006 at 06:15:37PM -0400, George G. Davis wrote:
>  <at>  <at>  -2068,6 +2076,10  <at>  <at>  uart_configure_port(struct uart_driver *
>  
>  		uart_report_port(drv, port);
>  
> +		/* Power up port for set_mctrl() */
> +		if (!uart_console(port))
> +			uart_change_pm(state, 0);
> +

If it's possible for uarts to be powered down here, wouldn't it be a
good idea to ensure that the console is also powered up?

--

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  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 | 3 comments |
headers
George G. Davis | 10 May 2006 19:13

Re: [RFC][PATCH] Make sure UART is powered up when dumping MCTRL status

On Wed, May 10, 2006 at 05:39:19PM +0100, Russell King wrote:
> On Fri, May 05, 2006 at 06:15:37PM -0400, George G. Davis wrote:
> >  <at>  <at>  -2068,6 +2076,10  <at>  <at>  uart_configure_port(struct uart_driver *
> >  
> >  		uart_report_port(drv, port);
> >  
> > +		/* Power up port for set_mctrl() */
> > +		if (!uart_console(port))
> > +			uart_change_pm(state, 0);
> > +
> 
> If it's possible for uarts to be powered down here, wouldn't it be a
> good idea to ensure that the console is also powered up?

Hrm, yes.  The above !uart_console(port) merely assumed that the device
is already powered up if it's the selected console.  In that way we only
call uart_change_pm() to power it up once, earlier but I haven't verified
that it was indeed done properly.  That check can be removed I guess.

Thanks!

--
Regards,
George
-
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 |

Gmane