headers
Anders Lennartsson | 2 Oct 2005 23:01
Picon
Favicon

problems with exar-17158 based 8-port card

I'm trying to get a 8-port serial card based on Exar XR17C158
working. It's a PC104 card [1], mounted on a Pentium based PC104
computer [2], which is running Debian Sarge from a 20GiB 1.8" HD. The
kernel is however upgraded to a kernel compiled by myself from
linux-sources-2.6.12, in order to include the drivers for the Exar
chip.  Information about the devices on the PCI-bus is found in [3].

Based on information logged in dmesg [4], the card is in fact
recognized by the kernel at boot and MMIO addresses seem to be
set. After boot completes the use of setserial to display information
about the ports displays that the MMIO addresses are incorrectly
reported [5]. In [6] is a shell script to fix that.

However, I fail to get the ports working after applying these changes
by setserial. I have tried all ports with a cable and minicom settings
that is verified to work between each of the standard serial ports
/dev/(ttyS0 | ttyS1) on this particular computer, to the serial port
on a desktop box.

Any tips?

Anders Lennartsson

[1] http://www.digitallogic.com/english/products/datasheets/pc104_peripherials_detail.asp?id=MSMX104-Plus

[2] http://www.digitallogic.com/english/products/datasheets/ms_pc104_detail.asp?id=MSMP5SEV

[3] Information from lspci:

0000:00:00.0 Host bridge: Intel Corp. 430TX - 82439TX MTXC (rev 01)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hallie Pelletier | 3 Oct 2005 16:52
Picon

buy cials-tabs without embarrassment


Be ERECT in less than 15 mins

PRlCE: $ 2 / use

visit us: bookold.com

-
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
Samuel Thibault | 9 Oct 2005 00:27
Gravatar

Re: [patch 3/4] new serial flow control

Hi,

I'm re-opening a somewhat old thread about serial flow control methods:

Russell King, le Wed 05 Jan 2005 23:53:01 +0000, a écrit :
> we have other people
> who want to use their on-board hardware RS485 flow control options on
> UARTs for their application, which means we need an RS485 flow control
> method.  (They can't select it without accessing the hardware directly.)
> 
> So, we now seem to have:
> 
> 	Standard flow control
> 	CTVB flow control
> 	RS485 RTS flow control

Let's add a new one: Inka braille devices, which uses RTS/CTS as
acknowledge strobes for each character.

> I still believe that flow control should be enabled by CRTSCTS, but
> the flow control personality set by other means.
> 
> Therefore, I think this requires further discussion, especially with
> Alan (who seems to be the tty layer god now) to work out some sort of
> reasonable interface.

How could this look like in userspace? Something like

#define CRTSCTS_RS232 0
#define CRTSCTS_RS485 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuel Thibault | 9 Oct 2005 02:21
Gravatar

Re: [patch 3/4] new serial flow control

Russell King, le Sun 09 Oct 2005 01:01:53 +0100, a écrit :
> > How could this look like in userspace?
> 
> I think they should be termios settings - existing programs know how
> to handle termios to get what they want. 

Hence a new field in the termios structure?

There was a discussion about this back in 2000:

http://marc.theaimsgroup.com/?t=96514848800003&r=1&w=2

and more precisely a remind of SVR4's termiox structure with an added
x_hflag:

http://marc.theaimsgroup.com/?l=linux-kernel&m=96523146720678&w=2

I'm not sure about how we'd want to implement that. The SVR4 approach
(orthogonal input/output flow control selection) doesn't seem right to
me: there are really peculiar flow controls that involve both ways. A
mere enumeration of possible methods might be better.

Regards,
Samuel
Permalink | Reply | 0 comments |
headers
Russell King | 9 Oct 2005 02:01
Picon

Re: [patch 3/4] new serial flow control

On Sun, Oct 09, 2005 at 12:27:11AM +0200, Samuel Thibault wrote:
> Hi,
> 
> I'm re-opening a somewhat old thread about serial flow control methods:
> 
> Russell King, le Wed 05 Jan 2005 23:53:01 +0000, a ?crit :
> > we have other people
> > who want to use their on-board hardware RS485 flow control options on
> > UARTs for their application, which means we need an RS485 flow control
> > method.  (They can't select it without accessing the hardware directly.)
> > 
> > So, we now seem to have:
> > 
> > 	Standard flow control
> > 	CTVB flow control
> > 	RS485 RTS flow control
> 
> Let's add a new one: Inka braille devices, which uses RTS/CTS as
> acknowledge strobes for each character.
> 
> > I still believe that flow control should be enabled by CRTSCTS, but
> > the flow control personality set by other means.
> > 
> > Therefore, I think this requires further discussion, especially with
> > Alan (who seems to be the tty layer god now) to work out some sort of
> > reasonable interface.
> 
> How could this look like in userspace? Something like
> 
> #define CRTSCTS_RS232 0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King | 9 Oct 2005 10:37
Picon

Re: [patch 3/4] new serial flow control

On Sun, Oct 09, 2005 at 02:21:30AM +0200, Samuel Thibault wrote:
> Russell King, le Sun 09 Oct 2005 01:01:53 +0100, a ?crit :
> > > How could this look like in userspace?
> > 
> > I think they should be termios settings - existing programs know how
> > to handle termios to get what they want. 
> 
> Hence a new field in the termios structure?
> 
> There was a discussion about this back in 2000:
> 
> http://marc.theaimsgroup.com/?t=96514848800003&r=1&w=2
> 
> and more precisely a remind of SVR4's termiox structure with an added
> x_hflag:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=96523146720678&w=2
> 
> I'm not sure about how we'd want to implement that. The SVR4 approach
> (orthogonal input/output flow control selection) doesn't seem right to
> me: there are really peculiar flow controls that involve both ways. A
> mere enumeration of possible methods might be better.

What I was thinking of was to use some of the spare termios cflag bits
to select the flow control.  You'd only want one flow control type at
one time though.  Eg: define two fields, each to select the signal.

0 - RTS
1 - DTR
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuel Thibault | 9 Oct 2005 12:09
Gravatar

Re: [patch 3/4] new serial flow control

Hi,

Russell King, le Sun 09 Oct 2005 09:37:24 +0100, a écrit :
> On Sun, Oct 09, 2005 at 02:21:30AM +0200, Samuel Thibault wrote:
> > Russell King, le Sun 09 Oct 2005 01:01:53 +0100, a ?crit :
> > > > How could this look like in userspace?
> > > 
> > > I think they should be termios settings - existing programs know how
> > > to handle termios to get what they want. 
> > 
> > Hence a new field in the termios structure?
> > 
> > There was a discussion about this back in 2000:
> > 
> > http://marc.theaimsgroup.com/?t=96514848800003&r=1&w=2
> 
> What I was thinking of was to use some of the spare termios cflag bits
> to select the flow control.  You'd only want one flow control type at
> one time though.  Eg: define two fields, each to select the signal.
> 
> 0 - RTS
> 1 - DTR
> 
> 0 - CTS
> 1 - DTR
> 2 - DSR

It looks fine, but it might not be sufficient for expressing that:

- some flow control use RTS to indicate that DTE is ready to send data,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King | 9 Oct 2005 13:17
Picon

Re: [patch 3/4] new serial flow control

On Sun, Oct 09, 2005 at 12:09:09PM +0200, Samuel Thibault wrote:
> Russell King, le Sun 09 Oct 2005 09:37:24 +0100, a ?crit :
> > What I was thinking of was to use some of the spare termios cflag bits
> > to select the flow control.  You'd only want one flow control type at
> > one time though.  Eg: define two fields, each to select the signal.
> > 
> > 0 - RTS
> > 1 - DTR
> > 
> > 0 - CTS
> > 1 - DTR
> > 2 - DSR
> 
> It looks fine, but it might not be sufficient for expressing that:
> 
> - some flow control use RTS to indicate that DTE is ready to send data,
> - some other use it to indicate that DTE wants to send data. (and CTS is
> used for acknowledgment of this),

Agreed - and that's one extra bit of control information.

> - some other use it as a strobe for acknowledging characters, some other
> use it as a strobe for acknowledging frames (announced by CTS).

The last has no business being in the serial driver though - the driver
knows nothing about frames of characters.  It's more a userland (in
which case it's TIOCM* ioctls) or ldisc issue (tty_driver->tiocmset).

> > However, bear in mind that the majority of the more inteligent 8250-
> > compatible UARTs with large FIFOs only do hardware flow control on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuel Thibault | 9 Oct 2005 13:33
Gravatar

Re: [patch 3/4] new serial flow control

Hi,

Russell King, le Sun 09 Oct 2005 12:17:18 +0100, a écrit :
> On Sun, Oct 09, 2005 at 12:09:09PM +0200, Samuel Thibault wrote:
> > - some other use it as a strobe for acknowledging characters, some other
> > use it as a strobe for acknowledging frames (announced by CTS).
> 
> The last has no business being in the serial driver though -
> the driver knows nothing about frames of characters.  It's more
> a userland (in which case it's TIOCM* ioctls) or ldisc issue
> (tty_driver->tiocmset).

In principle, yes. But implementing it in userland is not responsive
enough doesn't work reliably, while it can actually be implemented in
the serial driver as "acknowledge any CTS upfront" (if the device is not
throttled), and then it works fine. Writing a whole line discipline (and
getting it accepted in the kernel) just for this is a bit overkill.

> > > However, bear in mind that the majority of the more inteligent 8250-
> > > compatible UARTs with large FIFOs only do hardware flow control on
> > > RTS/CTS
> > 
> > Hardward flow control is usually performed in software. Can't their
> > hardware implementation of hardware flow control be disabled when
> > control method is not usual RTS/CTS?
> 
> You missed the point.  Of course the hardware flow control can be
> disabled.  However, if you do have on-chip CTS flow control disabled
> with UARTs with large FIFOs,
> etc..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuel Thibault | 9 Oct 2005 13:44
Gravatar

Re: [patch 3/4] new serial flow control

Samuel Thibault, le Sun 09 Oct 2005 13:33:13 +0200, a écrit :
> 
> Russell King, le Sun 09 Oct 2005 12:17:18 +0100, a écrit :
> > > Hardward flow control is usually performed in software. Can't their
> > > hardware implementation of hardware flow control be disabled when
> > > control method is not usual RTS/CTS?
> > 
> > You missed the point.  Of course the hardware flow control can be
> > disabled.  However, if you do have on-chip CTS flow control disabled
> > with UARTs with large FIFOs,
> > etc..
> 
> Yes, of course. But can't this be disabled too?

(I mean, the FIFOs)
-
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 |

Gmane