entry is a specific entry to override the generic NetMos entry so that
puc(4) will leave this device alone and let uart(4) claim it.
Submitted by: Navdeep Parhar nparhar @ gmail
Reviewed by: marcel
MFC after: 1 week
Note, that the patch provided with this card for the Linux states that
the card uses DEFAULT_RCLK * 2, while in fact it is '* 10'. So probably
we should also use the subdevice/subvendord here. For now just ignore
that fact.
PR: kern/129665
Submitted by: bsam
Obtained from: united efforst with bsam
clocked at 10x normal speed. That is, when you set it for 9600
baud, it actually does 96000 baud. In order to make it plug and
play with other serial ports, it has to have its clock rate
reduced by a factor of 10.
Discussed with: Marcel Moolenaar
MFC after: 2 weeks
so the index needs to be translated into an offset. While we
did add the offset (0x10), we forgot to account for the width.
Tested by: Thomas Vogt
MFC after: 3 days
o Properly use rman(9) to manage resources. This eliminates the
need to puc-specific hacks to rman. It also allows devinfo(8)
to be used to find out the specific assignment of resources to
serial/parallel ports.
o Compress the PCI device "database" by optimizing for the common
case and to use a procedural interface to handle the exceptions.
The procedural interface also generalizes the need to setup the
hardware (program chipsets, program clock frequencies).
o Eliminate the need for PUC_FASTINTR. Serdev devices are fast by
default and non-serdev devices are handled by the bus.
o Use the serdev I/F to collect interrupt status and to handle
interrupts across ports in priority order.
o Sync the PCI device configuration to include devices found in
NetBSD and not yet merged to FreeBSD.
o Add support for Quatech 2, 4 and 8 port UARTs.
o Add support for a couple dozen Timedia serial cards as found
in Linux.
transmitted bits was between 8.6180us and 8.6200us when we used a RCLK
of 16.500MHz. This is a little low (should be 8.6805us). This error
is exactly the error one would expect if it actually had a 16.384MHz
watch oscillator (as suggested by garrett) instead of using the PCI
RCLK. Assume that the pci clock therefore wasn't really used, but
instead the cheap 16.384MH watch quartz oscillator. This gives bits
in the 8.6800us to 8.6810us ranage, which matches theoretical.
Submitted by: garrett
time ago appears to be based not on the typical 1.8432MHz clock, or
the other more typical multiple of 8 of this (14.7456MHz), but instead
it appears to be 1/2 the PCI clock rate or 16.50000MHz. I'm not 100%
sure that this is right, but since I did the original entry, I'm going
to go ahead and modify it. With the 14.7456MHz value, I was getting
bits that were ~7.3us instead of ~8.6us like they are supposed to be.
My measuring gear for today is a stupid handheld scope with two
signficant digits. So I don't know if it is 33.000000/2 MHz or some
other value close to 16.5MHz, but 16.5MHz works well enough for me to
use a couple of different devices at 115200 baud, and is a nice even
multiple of a well known clock frequency...
16C950. Adding it here doesn't unlock any of the cool 16C950 features
(like the 128 byte fifo, the different prescalor, etc), but it does
seem to get it working for me in light testing.
Card Provided by: Ihsan Dogan
virtual COM port. This makes the use of the Dell OpenManage tools on FreeBSD
considerably easier, and is based on Chuck Cranor's original patch for 4.6.
Reviewed by: imp
Tested by: dpk at dpk dot net
MFC after: 1 week
to be the same as Boca Research Turbo Serial 654 (4 serial port).
While add the 8 port variants as well.
Submitted by: sten@blinkenlights.nl
PR: kern/75793
MFC after: 1 week
of the struct, so that a placeholder for it (or unportable C99
initializers) are not needed for entries that don't use it. Use a C99
initializer for the 1 entry that uses it. Removed 91 placeholders.
This also restores API compatibility with NetBSD and RELENG_4 for most
entries.
Removed the requirement for a particular subvendor/subproduct in
rev.1.26 (VScom PCI-800L card). While the BARs, etc., may depend on
the sub-ids, this is not known to be so, and I think it is better to
guess that they don't. The decision to check sub-id checks in this
file is apparently random; for VScom cards they were checked in 3 of
8 cases.
Reviewed by: timeout by committer (joerg) after 6 months
