294883 |
27-Jan-2016 |
jhibbits |
Convert rman to use rman_res_t instead of u_long
Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long.
This is step one in migrating rman to use uintmax_t for resources instead of u_long.
Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API.
This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI.
Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
|
267961 |
27-Jun-2014 |
hselasky |
Extend the meaning of the CTLFLAG_TUN flag to automatically check if there is an environment variable which shall initialize the SYSCTL during early boot. This works for all SYSCTL types both statically and dynamically created ones, except for the SYSCTL NODE type and SYSCTLs which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to be used in the case a tunable sysctl has a custom initialisation function allowing the sysctl to still be marked as a tunable. The kernel SYSCTL API is mostly the same, with a few exceptions for some special operations like iterating childrens of a static/extern SYSCTL node. This operation should probably be made into a factored out common macro, hence some device drivers use this. The reason for changing the SYSCTL API was the need for a SYSCTL parent OID pointer and not only the SYSCTL parent OID list pointer in order to quickly generate the sysctl path. The motivation behind this patch is to avoid parameter loading cludges inside the OFED driver subsystem. Instead of adding special code to the OFED driver subsystem to post-load tunables into dynamically created sysctls, we generalize this in the kernel.
Other changes: - Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask" to "hw.pcic.intr_mask". - Removed redundant TUNABLE statements throughout the kernel. - Some minor code rewrites in connection to removing not needed TUNABLE statements. - Added a missing SYSCTL_DECL(). - Wrapped two very long lines. - Avoid malloc()/free() inside sysctl string handling, in case it is called to initialize a sysctl from a tunable, hence malloc()/free() is not ready when sysctls from the sysctl dataset are registered. - Bumped FreeBSD version to indicate SYSCTL API change.
MFC after: 2 weeks Sponsored by: Mellanox Technologies
|
264257 |
08-Apr-2014 |
marius |
Distinguish between the different variants and configurations of Sunix {MIO,SER}5xxxx chips instead of treating all of them as PUC_PORT_2S. Among others, this fixes the hang seen when trying to probe the none- existent second UART on an actually 1-port chip.
Obtained from: NetBSD (BAR layouts) MFC after: 3 days Sponsored by: Bally Wulff Games & Entertainment GmbH
|
263109 |
13-Mar-2014 |
rstone |
Add MSI support to puc(9)
Add support for MSI interrupts in the puc(9) driver. By default the driver will prefer MSI interrupts to legacy interrupts. A tunable, hw.puc.msi_disable, has been added to force the allocation of legacy interrupts.
Reviewed by: jhb@ MFC after: 2 weeks Sponsored by: Sandvine Inc.
|
251715 |
13-Jun-2013 |
marius |
All of Oxford/PLX OX16PCI954, OXm16PCI954 and OXu16PCI954 share the exact same (subsystem) device and vendor IDs. However, the reference design for the OXu16PCI954 uses a 14.7456 MHz clock (as does the EXSYS EX-41098-2 equipped with these), while at least the OX16PCI954 defaults to a 1.8432 MHz one. According to the datasheets of these chips, the only difference in PCI configuration space is that OXu16PCI954 have a revision ID of 1 while the other two are at 0. So employ the latter for determining the default clock rates of this family. Note that one might think that the actual clock could be derived from the Clock Prescaler Register (CPR) of these chips. Unfortunately, this is not that case and its use and content are orthogonal to the frequency of the crystal employed. Tested with an EXSYS EX-41098-2, which identifies and attaches as: pcib4@pci0:19:0:0: class=0x060400 card=0x02dd1014 chip=0x10801b21 rev=0x03 hdr=0x01 vendor = 'ASMedia Technology Inc.' device = 'ASM1083/1085 PCIe to PCI Bridge' class = bridge subclass = PCI-PCI puc0@pci0:20:4:0: class=0x070006 card=0x00001415 chip=0x95011415 rev=0x01 hdr=0x00 vendor = 'Oxford Semiconductor Ltd' device = 'OX16PCI954 (Quad 16950 UART) function 0 (Uart)' class = simple comms subclass = UART puc1@pci0:20:4:1: class=0x068000 card=0x00001415 chip=0x95111415 rev=0x01 hdr=0x00 vendor = 'Oxford Semiconductor Ltd' device = 'OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)' class = bridge puc2@pci0:20:8:0: class=0x070006 card=0x00001415 chip=0x95011415 rev=0x01 hdr=0x00 vendor = 'Oxford Semiconductor Ltd' device = 'OX16PCI954 (Quad 16950 UART) function 0 (Uart)' class = simple comms subclass = UART puc3@pci0:20:8:1: class=0x068000 card=0x00001415 chip=0x95111415 rev=0x01 hdr=0x00 vendor = 'Oxford Semiconductor Ltd' device = 'OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)' class = bridge
pci20: <ACPI PCI bus> on pcib4 puc0: <Oxford Semiconductor OX16PCI954 UARTs> port 0x5000-0x501f, 0x5020-0x503f mem 0xc6000000-0xc6000fff,0xc6001000-0xc6001fff irq 16 at device 4.0 on pci20 uart1: <16950 or compatible> at port 1 on puc0 uart2: <16950 or compatible> at port 2 on puc0 uart3: <16950 or compatible> at port 3 on puc0 uart4: <16950 or compatible> at port 4 on puc0 puc1: <Oxford Semiconductor OX9160/OX16PCI954 UARTs (function 1)> port 0x5040-0x505f,0x5060-0x507f mem 0xc6002000-0xc6002fff,0xc6003000-0xc6003fff irq 16 at device 4.1 on pci20 puc2: <Oxford Semiconductor OX16PCI954 UARTs> port 0x5080-0x509f, 0x50a0-0x50bf mem 0xc6004000-0xc6004fff,0xc6005000-0xc6005fff irq 16 at device 8.0 on pci20 uart5: <16950 or compatible> at port 1 on puc2 uart6: <16950 or compatible> at port 2 on puc2 uart7: <16950 or compatible> at port 3 on puc2 uart8: <16950 or compatible> at port 4 on puc2 puc3: <Oxford Semiconductor OX9160/OX16PCI954 UARTs (function 1)> port 0x50c0-0x50df,0x50e0-0x50ff mem 0xc6006000-0xc6006fff,0xc6007000-0xc6007fff irq 16 at device 8.1 on pci20
MFC after: 2 weeks
|
247571 |
01-Mar-2013 |
marius |
- Apparently, r186520 was just wrong and the clock of Oxford OX16PCI958 is neither DEFAULT_RCLK * 2 nor DEFAULT_RCLK * 10 but plain DEFAULT_RCLK and there's no (open) source indicating otherwise. This was tested with an EXSYS EX-41098-2, whose clock is not configurable and identifies as: puc0@pci0:5:1:0: class=0x070200 card=0x06711415 chip=0x95381415 rev=0x01 hdr=0x00 vendor = 'Oxford Semiconductor Ltd' class = simple comms subclass = multiport serial
Note that this exactly matches the card mentioned in PR 129665 so no sub-device/sub-vendor based quirking of the latter is possible. So maybe we should grow some sort of tunable, in case non-default cards such as the latter aren't configurable either (this also wouldn't be the first time an allegedly tested commit turns out to be wrong though). - Make the TiMedia tables const.
MFC after: 1 week
|
227843 |
22-Nov-2011 |
marius |
- There's no need to overwrite the default device method with the default 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.
|
186520 |
27-Dec-2008 |
rik |
Add support for the Oxford OX16PCI958-based card.
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
|
179409 |
29-May-2008 |
mckusick |
The SIIG 4 port serial card based on the Oxford OX16PCI954 is 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
|
158124 |
28-Apr-2006 |
marcel |
Rewrite of puc(4). Significant changes are: 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.
|
153249 |
08-Dec-2005 |
imp |
Careful measurement of the ST Labs card shows that the pulse width of 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
|
153148 |
05-Dec-2005 |
imp |
The Oxford 16C950 based CardBus Serial device that I was given some 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...
|
145391 |
22-Apr-2005 |
imp |
Sort Oxford Semi entires. Add entry for OXCB950, a PCI/CardBus 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
|
143142 |
04-Mar-2005 |
marius |
- sparc64/fhc/fhc.c: 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
|
142532 |
26-Feb-2005 |
marius |
Declare the sbus(4) front-end of puc(4) also for fhc(4), allowing 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
|
133589 |
12-Aug-2004 |
marius |
- Introduce an ofw_bus kobj-interface for retrieving the OFW node and a subset ("compatible", "device_type", "model" and "name") of the standard properties in drivers for devices on Open Firmware supported busses. The standard properties "reg", "interrupts" und "address" are not covered by this interface because they are only of interest in the respective bridge code. There's a remaining standard property "status" which is unclear how to support properly but which also isn't used in FreeBSD at present. This ofw_bus kobj-interface allows to replace the various (ebus_get_node(), ofw_pci_get_node(), etc.) and partially inconsistent (central_get_type() vs. sbus_get_device_type(), etc.) existing IVAR ones with a common one. This in turn allows to simplify and remove code-duplication in drivers for devices that can hang off of more than one OFW supported bus. - Convert the sparc64 Central, EBus, FHC, PCI and SBus bus drivers and the drivers for their children to use the ofw_bus kobj-interface. The IVAR- interfaces of the Central, EBus and FHC are entirely replaced by this. The PCI bus driver used its own kobj-interface and now also uses the ofw_bus one. The IVARs special to the SBus, e.g. for retrieving the burst size, remain. Beware: this causes an ABI-breakage for modules of drivers which used the IVAR-interfaces, i.e. esp(4), hme(4), isp(4) and uart(4), which need to be recompiled. The style-inconsistencies introduced in some of the bus drivers will be fixed by tmm@ in a generic clean-up of the respective drivers later (he requested to add the changes in the "new" style). - Convert the powerpc MacIO bus driver and the drivers for its children to use the ofw_bus kobj-interface. This invloves removing the IVARs related to the "reg" property which were unused and a leftover from the NetBSD origini of the code. There's no ABI-breakage caused by this because none of these driver are currently built as modules. There are other powerpc bus drivers which can be converted to the ofw_bus kobj-interface, e.g. the PCI bus driver, which should be done together with converting powerpc to use the OFW PCI code from sparc64. - Make the SBus and FHC front-end of zs(4) and the sparc64 eeprom(4) take advantage of the ofw_bus kobj-interface and simplify them a bit.
Reviewed by: grehan, tmm Approved by: re (scottl) Discussed with: tmm Tested with: Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386
|
128383 |
18-Apr-2004 |
bde |
Fixed some style bugs (tab lossage) in rev.1.26.
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
|
119814 |
06-Sep-2003 |
marcel |
Enhance puc(4) to support uart(4). This includes: o Introduce PUC_PORT_TYPE_UART so that we can attach to uart(4), o Introduce port sub-types (eg PUC_PORT_UART_NS8250, PUC_PORT_UART_Z8530) to handle different hardware and determine resource sizes. o Introduce two new IVARs: PUC_IVAR_SUBTYPE and PUC_IVAR_REGSHFT. Both are used by uart(4) to get sufficient information to talk to the HW. o Introduce PUC_FLAGS_ALTRES to tell puc(4) to try memory mapped I/O if I/O port space cannot be allocated, or vice versa. o Have ports of type PUC_PORT_TYPE_COM attach to uart(1) if attaching to sio(4) fails (due to not having the sio driver). o Put struct puc_device_description in struct puc_softc instead of having a pointer to a device description in the softc. This allows us to create device descriptions on the fly without having to use malloc() or otherwise have them staticly defined. o Move puc_find_description() from puc.c to puc_pci.c as it's specific to PCI. o Add EBUS and SBUS frontends for use on sparc64. Note that the P in puc stands for PCI, so we kinda mess things up here. It's too soon to worry about it though. We'll know what to do about it in time.
NOTE: This commit changes the behaviour of puc(4) to not quieten the device probe and attach for child devices. The uart(4) driver provides additional device description that is valuable to have.
|
118902 |
14-Aug-2003 |
pb |
Add support for the newer Moxa PCI 8-port, 16550-compatible based CP-168U board. It initializes and attaches in the same way as the older (but higher performance) C168H. The only difference is the board ID, which is 0x1681.
PR: kern/53548 Submitted by: regnauld@catpipe.net MFC after: 1 week
|
109458 |
18-Jan-2003 |
marcel |
MFp4: Add support for memory mapped UARTs, but don't add any devices yet that depend on it because sio(4) needs support for it before it can be used. There's no reason why zs(4) couldn't attach to puc(4) in the (near?) future (in principle), so don't make memory mapped I/O support in sio(4) a precondition for this change.
|
102734 |
31-Aug-2002 |
phk |
More cleaning up and unhacking:
Don't expect all RIDs to be PCI rids. The previous code made at least 1 mistake, even for PCI.
Give the card definitions a chance to specify a init function. Use this instead of the gross superio hack. Move the win877 init function to puc_pci.c where it belongs.
RIDs can actually be zero, don't set badmuxed if so.
Set a less incorrect end for the construct SYS_RES_IOPORT entries, I guess both sio and lpt happen to use 8 IO ports, but that shouldn't really be hardcoded this way.
Fixup puc_pccard.c to match.
We're getting closer.
|
98376 |
18-Jun-2002 |
obrien |
Add support for Comtrol RocketPort 550 PCi models: 4 RJ45, 4 Quadcable, 8 RJ11, 8 Octacable, and 8 (used with RocketPort I/F box).
Note: untested due to lack of hardware
|
90731 |
16-Feb-2002 |
jhay |
Add the puc (PCI "Universal" Communications) driver. The idea and some of the structure definitions come from NetBSD to make it easier to share card definitions. The driver only acts as a shim between the pci bus and the sio driver. Later pci parallel ports could also be supported through this driver. Support for most single and multiport pci serial cards should be as simple as adding its definition to pucdata.c
Tested with the following pci cards: Moxa Industio CP-114, 4 port RS-232,RS-422/485 Syba Tech Ltd. PCI-4S2P-550-ECP, 4 port RS-232 + 2 parallel ports Netmos NM9835 PCI-2S-550, 2 port RS-232
|