serial driver question

serial driver question

[John Covici]

I have been wondering about the serial drivers shared irq
configuration parameter.  Will it allow two dumb serial ports which
know nothing about sharing irq's to actually share the same irq, or
does the actual hardware have to support some kind of irq sharing for
this to work?

I did try two ports on the same irq, but one of them isn't seem at all
by Linux, so I am quite curious whether I am barking up the wrong
line?

Thanks.


-- 
         John Covici
         covici@ccs.covici.com

Re: serial driver question

[Thorsten Kranzkowski]

On Thu, Mar 22, 2001 at 06:07:52PM -0500, John Covici wrote:
> I have been wondering about the serial drivers shared irq
> configuration parameter.  Will it allow two dumb serial ports which
> know nothing about sharing irq's to actually share the same irq, or

no.

> does the actual hardware have to support some kind of irq sharing for
> this to work?

yes.

For one there are multiport serial cards that combine every ports' irq
into one.

PCI cards should also be able to share their irqs (with other PCI cards).

But you can't share an ISA irq with a PCI one.

And you can't share one ISA card's irq with another ISA one nor the irqs of
a dumb ISA multiport card either ...
... without some modification, that is ;-)

Imagine the situation on a typical ISA card:

                   Card              ISA     Mainboard
                                  connector

-------+                              "      | to other ISA connectors
       |               Jumper         "      |
  IC   |-------------+--*=*-----------"------+
       |             |                "      |
-------+             +--* *------     "      | to IRQ-Controller-IC
                     |                "
                     +--* *------


Now replace the jumper for each irq sharing device with a diode and add one
resistor to the irq line:

-------+                    Diode     "      | to other ISA connectors
       |               e.g. 1n4148    "      |
  IC   |-------------+--*=*--|>|---+--"------+
       |             |      A   K  |  "      |
-------+             +--* *---     |  "      | to IRQ-Controller-IC
                     |             #  "
                     +--* *---     # Resistor 20kOhm
                                   #
                                   |
                                 __|__ GND

So for 4 serial ports sharing a single irq line you wuld use 4 diodes and 
1 resistor.


> I did try two ports on the same irq, but one of them isn't seem at all
> by Linux, so I am quite curious whether I am barking up the wrong
> line?

It should be seen. You won't be able to use them effectively (they'll be
transmitting only about 16 bytes every 30 seconds or something) but they
should definitively be detected both.
Did you use setserial to convince the kernel of their presence?

> 
> Thanks.
> 

Bye,
Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@gmx.net                        |
| Mobile: ++49 170 1876134       Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

serial driver question

[Guennadi Liakhovetski]

(asking on kernelnewbies didn't produceany results, so, I'm protected:-))

Hello all

The function
static int size_fifo(struct async_struct *info)
{
...
ends as follows:
	serial_outp(info, UART_LCR, UART_LCR_DLAB);
	serial_outp(info, UART_DLL, old_dll);
	serial_outp(info, UART_DLM, old_dlm);

	return count;
}

Which means, that DLAB is not re-set, and, in particular, all subsequent
read/write operations on offsets 0 and 1 will not affect the data and
interrupt enable registers, but the divisor latch register... Or is this
register somehow magically restored elsewhere or by the hardware (say, on
an interrupt)? This function seems to be only called for startech UARTs.

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

RE: serial driver question

[Ed Vance]

Guennadi Liakhovetski wrote:
> Hello all
> 
> The function
> static int size_fifo(struct async_struct *info)
> {
> ...
> ends as follows:
> 	serial_outp(info, UART_LCR, UART_LCR_DLAB);
> 	serial_outp(info, UART_DLL, old_dll);
> 	serial_outp(info, UART_DLM, old_dlm);
> 
> 	return count;
> }
> 
> Which means, that DLAB is not re-set, and, in particular, all 
> subsequent read/write operations on offsets 0 and 1 will not 
> affect the data and interrupt enable registers, but the divisor 
> latch register... Or is this register somehow magically restored 
> elsewhere or by the hardware (say, on an interrupt)? This 
> function seems to be only called for startech UARTs.

Hi Guennadi,

I'll look at it as soon as my system is up. It's morning boot-up time here.
Have a good evening.

Ed Vance

---------------------------------------------------------------- 
Ed Vance              edv@macrolink.com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

RE: serial driver question

[Ed Vance]

Guennadi Liakhovetski wrote:
> Hello all
> 
> The function
> static int size_fifo(struct async_struct *info)
> {
> ...
> ends as follows:
> 	serial_outp(info, UART_LCR, UART_LCR_DLAB);
> 	serial_outp(info, UART_DLL, old_dll);
> 	serial_outp(info, UART_DLM, old_dlm);
> 
> 	return count;
> }
> 
> Which means, that DLAB is not re-set, and, in particular, all 
> subsequent read/write operations on offsets 0 and 1 will not 
> affect the data and interrupt enable registers, but the divisor 
> latch register... Or is this register somehow magically restored 
> elsewhere or by the hardware (say, on an interrupt)? This 
> function seems to be only called for startech UARTs.

Hi Guennadi,

It is somehow magically restored elsewhere. The divisor latch bit (DLAB)
does remain set when size_fifo() returns, but the state does not persist.
Here is why the code works anyway, albeit with a trap or two for the
insufficiently paranoid ... and it can be explained without magic. :)

Notice that function size_fifo() does not save the LCR value before changing
it. Static function size_fifo() is called only from the very end of static
function autoconfig_startech_uarts(). Notice that function
autoconfig_startech_uarts() never returns with state->type set to
PORT_16550A. All code paths change state->type to something else. Static
function autoconfig_startech_uarts() is only called from the middle of
static function autoconfig(). Function autoconfig() saves the LCR value
before the testing of the alleged UART, which may include calling
autoconfig_startech_uarts(). When autoconfig_startech_uarts() returns to
autoconfig(), state->type cannot be PORT_16550A so the bodies of the next
two "if" statements that check state->type are skipped. The next line of
UART touching code that runs after size_fifo() and
autoconfig_startech_uarts() return to autoconfig(), is at about 50 lines
after the call to autoconfig_startech_uarts(), just before the check for
state->type == PORT_16450:

	serial_outp(info, UART_LCR, save_lcr);

which restores autoconfig()'s saved LCR value, including the DLAB bit. 

Yeah, I agree that size_fifo() should clean up after itself, but it doesn't
break anything as the code currently sits. Care to submit a one-line patch
for size_fifo() to clean up the UART state? 

Best regards,
Ed Vance

---------------------------------------------------------------- 
Ed Vance              edv@macrolink.com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------