one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
announced during boot and contains the port number. The pnpinfo string
lists the port type (PUC_TYPE_* constants).
Tested by: Boris Samorodov bsam ipt ru
MFC after: 1 week
real owner of the device ID. Also rename the associated config
function while here.
- Add support for the 2-port and 4-port Exar parts as well: Exar XR17C/D152
and Exar XR17C154.
Tested by: Mike Tancsa, Willy Offermans Willy of offermans rompen nl
MFC after: 1 week
which uses a non-standard clock (* 8) while any additional ports use
SUN1699 chips which use a standard clock.
Tested by: N.J. Mann njm of njm me uk
MFC after: 1 week
Oxford Semiconductor OX16PCI954 but uses only two ports with a non-default
clock rate.
PR: kern/152034
Tested by: Hans Fiedler hans of hermes louisville edu
MFC after: 1 week
For these devices, the number of supported ports is read from a register
in BAR 0.
PR: kern/134878
Submitted by: David Wood david of wood2 org uk
MFC after: 1 week
The rewrite of the interrupt handler includes:
o loop until all pending interrupts are handled. This closes a
race condition.
o count the number of interrupt sources we handled so that we can
properly return FILTER_HANDLED or FILTER_STRAY when we break out
of the loop.
o When matching the interrupt source to the devices that have that
source pending, check only from the set of devices we found to
have a pending interrupt.
PR: kern/140947
MFC after: 3 days
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.
Return BUS_PROBE_LOW_PRIORITY for a successful probe. This is in
preparation of the introduction of scc(4), which is going to handle
SCCs in the near future.
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...
via the DEFAULTS kernel configs. This allows folks to turn it that option
off in the kernel configs if desired without having to hack the source.
This is especially useful since PUC_FASTINTR hangs the kernel boot on my
ultra60 which has two uart(4) devices hung off of a puc(4) device.
I did not enable PUC_FASTINTR by default on powerpc since powerpc does not
currently allow sharing of INTR_FAST with non-INTR_FAST like the other
archs.
