* Design issues Keyspan serial PCI driver
[not found] <199908130501.AAA18955@lists.linuxppc.org>
@ 1999-08-13 18:48 ` Otto Moerbeek
1999-08-14 15:30 ` Geert Uytterhoeven
0 siblings, 1 reply; 2+ messages in thread
From: Otto Moerbeek @ 1999-08-13 18:48 UTC (permalink / raw)
To: linuxppc-dev
Hi to you all,
after some struggling I now have a very first working version of the
Keyspan SX
serial card driver, but I do not think the code I wrote is ready for
publishing. To make a neat driver I have some design issues I want to
share with you. Hopefully this will help me making the right decisions
for the real driver.
The Keyspan SX cards use a PLX9050 as PCI bridge to connect to an
ST16C654 UART. I found some patches for char/serial.c that support the
UART directly. So this part of the problem was solved easily.
But Keyspan choose to map the UART to PCI memory space using the 9050,
not PCI I/O space. Furthermore, for some unknown reason, the registers
of the UART are separated 0x80 apart. Since char/serial.c uses I/O
instructions to access the UART, I had to hack the driver to use readb()
and friends. I am also multiplying the offset to compensate for the
strange offsets.
I would really like to use the char/serial.c driver and keep it
compatible with existing cards, because I do not want to write a
complete driver myself for a UART that is supported by standard code.
But then I have to decide runtime to use inb() and outb() or readb() and
writeb(), since the driver also may be used for other cards that use I/O
based access. Do you think that this would cause too much overhead in
the interrupt handlers? It means that every I/O access will be slowed
down by some extra memory references and a test.
Another point is that the serial structs use an int as the type for the
port field. Since cannot change the struct in include/linux/serial.h to
use u8 * as a type for compatibility reasons, I have to find some way to
use the port as an offset added to some memory mapped base pointer of
type u8 *, instead of using port as an absolute (I/O or mem) address.
Just using the int port as a memory address value is dangerous, since it
won't work on 64 bits architectures. Do you think this is the way to
go: keeping compatibility with applications that expect port to be an
int, while still be able to do memory mapped PCI access?
The good news of course is, if I can resolve the above issues, I have a
driver that can access both I/O based and memory based PCI cards. The
start of proper PCI serial card support in the standard serial driver?
You can find some more background info on my home page, <http://people.a2000.nl/omoerbe/>
Sorry for the long winding story, but I really would like some feedback,
Otto
--
Otto Moerbeek
otto@cable.a2000.nl
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [flat|nested] 2+ messages in thread