| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Submitted by: Mark Johnston
Obtained from: Sandvine Incorporated
|
|
|
|
|
| |
Submitted by: Douglas K. Rand rand of meridian-enviro com
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Obtained from: NetMos MCS9865 v1.0.0.1 driver
MFC after: 3 days
|
|
|
|
|
|
|
| |
puc0@pci0:4:1:0: class=0x070002 card=0x00021000 chip=0x98359710 rev=0x01 hdr=0x00
Reviewed by: marcel@
Approved by: gnn (mentor)
|
|
|
|
|
|
|
| |
series POS terminals.
MFC after: 3 days
Submitted by: Marc Balmer <marc at msys.ch>
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PR: kern/128219
Submitted by: Thinker K.F. Li <thinker at branda dot to>
|
|
|
|
|
| |
Submitted by: dmarck
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
|
|
|
|
|
|
| |
based on the OX16PCI954 chip with a non-standard clock.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
| |
PR: kern/69730
Submitted by: Darrin Smith
|
|
|
|
|
| |
PR: kern/72352
Submitted by: Thomas Nystrom
|
|
|
|
|
| |
PR: kern/110797
Submitted by: Trevor Roydhouse
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
PR: kern/119515
Submitted by: Gavin Stone-Tolcher
MFC after: 1 month
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
| |
Linux equivalent gives BAR offsets relative to the implied base of 0x10.
Our PUC_CFG_GET_RID functions have to add the base offset themselves.
|
|
|
|
|
|
|
| |
-correctly check for filter only handler
Reviewed by: marcel
Tested by: marcel
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bus_setup_intr()
o add an int return code to all fast handlers
o retire INTR_FAST/IH_FAST
For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current
Reviewed by: many
Approved by: re@
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
saying that scc(4) should be configured into the kernel. This
helps people to migrate away from puc(4) for these devices.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
puc still prints out [FAST] on Peter's box.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
subdrivers to hook up.
It should probably be rewritten to implement a simple bus to which
the sub drivers attach using some kind of hint.
Until then, provide a couple of crutch functions with big warning
signs so it can survive the recent changes to struct resource.
|
| |
|
| |
|
|
|
|
| |
since ebus.c rev. 1.22.
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change fhc(4) to use IRQ numbers instead of RIDs for allocating the
IRQs of children. This works similar to e.g. sbus(4), i.e. add the
IRQ resources as fully specified to the resource lists of the children,
allocate them like normal. When establishing the interrupt search the
interrupt maps of the children for a matching INO to determine which
map we need to write the fully specified interrupt number to and to
enable the mapping (before the RID was used to indicate which interrupt
map to use).
- dev/puc/puc.c:
Revert rev. 1.38, with the above change fhc(4) no longer needs special
treatment for allocating IRQs.
Thanks to: joerg for providing access to an E3500
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uart(4) to support the Zilog 8530 SCCs which hang off of a FireHose
bus on Sun E4000/E5000 class machines.
Beside the fact that a puc_fhc.c would just be a copy of puc_sbus.c
with s,sbus,fhc,g the reason why the declaration for fhc(4) was
sticked into puc_sbus.c is that both of these front-ends for puc(4)
will go away once there is a scc(4).
Discussed with: marcel
Tested by: hrs, kris
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
both a scc(4) is under way and fhc(4) will be change to use INOs this
shouldn't stay in HEAD for too long but we need a MFC-able solution
for FreeBSD 5.4.
Discussed with: marcel
Tested by: hrs, kris
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
| |
to allocate a bar; it's unclear whether this can happen in practice
Noticed by: Coverity Prevent analysis tool
Discussed with: marcel
|
|
|
|
|
|
| |
Submitted by: Willy Offermans <W.K.Offermans@TUe.nl>
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
It should be safe to attach to all Z8530 controllers again. In fact,
the keyboard works on Ultra 2 machines.
MFC after: 5 days
|