summaryrefslogtreecommitdiffstats
path: root/sys/sparc64/sbus
Commit message (Collapse)AuthorAgeFilesLines
* Adapt parts of the sparc64 Open Firmware bus enumeration code (in particular,nwhitehorn2008-12-151-0/+1
| | | | | | | | | | | | | | | the code for parsing interrupt maps) to PowerPC and reflect their new MI status by moving them to the shared dev/ofw directory. This commit also modifies the OFW PCI enumeration procedure on PowerPC to allow the bus to find non-firmware-enumerated devices that Apple likes to add, and adds some useful Open Firmware properties (compat and name) to the pnpinfo string of children on OFW SBus, EBus, PCI, and MacIO links. Because of the change to PCI enumeration on PowerPC, X has started working again on PPC machines with Grackle hostbridges. Reviewed by: marius Obtained from: sparc64
* o Move the MODULE_DEPEND() for cam(4) from the esp_sbus.c front-end tomarius2008-09-083-97/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the ncr53c9x.c core where it actually belongs so future front-ends don't need to add it. o Use the correct OFW property when looking for the initiator ID of the SBus device. o Don't specify an alignment when creating the parent DMA tag for SUNW,fas; their DMA engine doesn't require an alignment constraint and it's no inherited by the child DMA tags anyway (which probably is a bug though). o Drop the superfluous sc_maxsync and use sc_minsync instead. The former apparently was added due to a confusion with the maximum frequency used in cam(4), which basically corresponds to the inverse of minimum sync period. o Merge ncr53c9x.c from NetBSD: 1.116: NCRDMA_SETUP() should be called before NCR_SET_COUNT() and NCRCMD_DMA command in ncr53c9x_select(). 1.125: free allocated resources on detach. o Static'ize ncr53c9x_action(), ncr53c9x_init() and ncr53c9x_reset() as these are not required outside of ncr53c9x.c. o In ncr53c9x_attach() don't leak the device mutex in case attaching fails. o Register an asynchronous notification handler so in case cam(4) reports a lost device we can cancel outstanding commands and restore the default parameters for the target in question. o For FAS366 correctly support 16-bit target IDs and let it know that we use 32-bit transfers. o Overhaul the negotiation of transfer settings. This includes distinguishing between current and goal transfer settings of the target so we can renegotiate their goal settings when necessary and correcting the order in which tagged, wide and synchronous transfers are negotiated. o If we are requesting sense, force a renegotiation if we are currently using anything different from asynchronous at 8 bit as the target might have lost our transfer negotiations. o In case of an XPT_RESET_BUS just directly call ncr53c9x_init() instead of issuing a NCRCMD_RSTSCSI, which in turn will issue an interrupt that is treated as an unexpected SCSI bus reset by ncr53c9x_intr() and thus calls ncr53c9x_init(). Remove the now no longer used ncr53c9x_scsi_reset(). o Correct an off-by-one error when setting cpi->max_lun. o In replace printf(9) with device_printf(9) calls where appropriate and in ncr53c9x_action() remove some unnecessarily verbose messages. o In ncr53c9x_sched() use TAILQ_FOREACH() instead of reimplementing it and consolidate two tagging-related target info checks into one. o In ncr53c9x_done() set the CAM status to CAM_SCSI_STATUS_ERROR when appropriate, respect CAM_DIS_AUTOSENSE and teach it to return SCSI status information. o In ncr53c9x_dequeue() ensure the tags are cleared. o Use ulmin() instead of min() where appropriate. o In ncr53c9x_msgout() consistently use the reset label. o When we're interrupted during a data phase and the DMA engine is still active, don't panic but reset the core and the DMA engine as this should be sufficient. Also, the typical problem for triggering this was the lack of renegotiation when requesting sense. o Correctly handle DEVICE RESETs. o Adapt the locking of esp(4) to MPSAFE cam(4). This includes moving the calls of lsi64854_attach() to the bus front-ends so it can pass the esp(4) mutex to bus_dma_tag_create(9). o Change the LSI64854 driver to not create a DMA tag and map for the Ethernet channel as le(4) will handle these on its own as well as sync and unload the DMA maps for the SCSI and parallel port channel after a DMA transfer. o Cam(4)'ify some NetBSD-centric comments. o Use bus_{read,write}_*(9) instead of bus_space_{read,write}_*(9) and take advantage of rman_get_rid(9) in order to save some softc members. Reviewed by: scottl MFC after: 1 month
* Provide and consume module dependency information.marius2008-08-232-0/+3
| | | | MFC after: 3 days
* - Use the name returned by device_get_nameunit(9) for the name of themarius2008-05-071-9/+3
| | | | | | | | | | | | counter-timer timecounter so the associated SYSCTL nodes don't clash on machines having multiple U2P and U2S bridges as well as establishing a clear mapping between these bridges and their timecounter device. - Don't bother setting up a "nice" name for the IOMMU, just use the name returned by device_get_nameunit(9), too. - Fix some minor style(9) bugs. - Use __FBSDID in counter.c MFC after: 1 week
* o Rename ic_eoi to ic_clear to emphasize the functions it pointsmarius2008-04-231-3/+16
| | | | | | | | | | | | | | | | | | | don't send and EOI which works like on amd64/i386 and blocks all interrupts on the relevant interrupt controller. o Replace the post_filter and post_inthread hooks registered when creating the interrupt events with just ic_clear as on sparc64 we don't need to do any disable->EOI->enable dance to unblock all but the relevant interrupt while running the filter or handler; just not clearing the interrupt already has the same effect. o Merge from amd64/i386: - Split the intr_table_lock into an sx lock used for most things, and a spin lock to protect intrcnt_index. - Add support for binding interrupts to CPUs, including for the bus_bind_intr(9) interface, a assign_cpu hook and initially shuffling interrupts arround in a round-robin fashion. Reviewed by: jhb MFC after: 1 month
* o Revamp the sparc64 interrupt code in order to be able to interfacemarius2007-09-062-128/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the INTR_FILTER-enabled MI code. Basically this consists of registering an interrupt controller (of which there can be multiple and optionally different ones either per host-to-foo bridge or shared amongst host-to-foo bridges in any one machine) along with an interrupt vector as specific argument for all the interrupt vectors used by a given host-to-foo bridge (roughly similar to registering interrupt sources on amd64 and i386), providing functions to enable, clear and disable the interrupts of the children beneath the bridge. This also includes: - No longer entering a critical section in tl0_intr() and tl1_intr() for executing interrupt handlers but rather let the handlers enter it themselves so in the case of intr_event_handle() we don't enter a nested critical section. - Adding infrastructure for binding delivery of interrupt vectors to specific CPUs which later on can be interfaced with the code from amd64/i386 for binding interrupts to specific CPUs. - Getting rid of the wrapper hack introduced along the lines of the API changes for INTR_FILTER which as a side-effect caused interrupts associated with ithread handlers only to get the elevated priority of those associated with filters ("fast handlers") (this removes the hack also in the non-INTR_FILTER case). - Disabling (by not clearing) an interrupt in the interrupt controller until all associated handlers have been executed, which is crucial for the typical locking strategy of NIC drivers in order to work correctly in case of shared interrupts. This was a more or less theoretical problem on sparc64 though, as shared interrupts are rather uncommon there except for the on-board SCCs and UARTs. Note that due to the behavior of at least of some of the interrupt controllers used on sparc64 an enable+EOI instead of a disable+EOI approach (as implied by the INTR_FILTER MI code and implemented on other architectures) is used as the latter can cause lost interrupts or in the worst case interrupt starvation. o Correct a typo in sbus_alloc_resource() which caused (pass-through) allocations to only work down to the grandchildren of the bus, which wasn't a real problem so far as we don't support any devices which are great-grandchildren or greater of a U2S bridge, yet. o In fhc(4) use bus_{read,write}_4() instead of bus_space_{read,write}_4() in order to get rid of sc_bh and sc_bt in the fhc_softc. Also get rid of some other unneeded members in fhc_softc. Reviewed by: marcel (earlier version) Approved by: re (kensmith)
* - Divorce the IOTSBs, which so far where handled via a global listmarius2007-08-052-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instead of per IOMMU, so we no longer need to program all of them identically in systems having multiple IOMMUs. This continues the rototilling of the nexus(4) done about 5 months ago, which amongst others changed nexus(4) and the drivers for host-to-foo bridges to provide bus_get_dma_tag methods, allowing to handle DMA tags in a hierarchical way and to link them with devices. This still doesn't move the silicon bug workarounds for Sabre (and in the uncommitted schizo(4) for Tomatillo) bridges into special bus_dma_tag_create() and bus_dmamap_sync() methods though, as w/o fully newbus'ified bus_dma_tag_create() and bus_dma_tag_destroy() this still requires too much hackery, i.e. per-child parent DMA tags in the parent driver. - Let the host-to-foo drivers supply the maximum physical address of the IOMMU accompanying the bridges. Previously iommu(4) hard- coded an upper limit of 16GB, which actually only applies to the IOMMUs of the Hummingbird and Sabre bridges. The Psycho variants as well as the U2S in fact can can translate to up to 2TB, i.e. translate to 41-bit physical addresses. According to the recently available Tomatillo documentation these bridges even translate to 43-bit physical addresses and hints at the Schizo bridges doing 43 bits as well. This fixes the issue the FreeBSD 6.0 todo list item "Max RAM on sparc64" was refering to and pretty much obsoletes the lack of support for bounce buffers on sparc64. Thanks to Nathan Whitehorn for pointing me at the Tomatillo manual. Approved by: re (kensmith)
* - Don't register the over-temperature and power-fail interruptmarius2007-06-161-20/+14
| | | | | | | | handlers as filter/"fast" handlers so shutdown_nice() can acquire the process lock. - Use bus_{read,write}_8() instead of bus_space_{read,write}_8() in order to get rid of sc_bushandle and sc_bustag in the softc. - Remove the banal and outdated comment above sbus_filter_stub().
* Teach the bridge wrapper how to handle the filter+ithread case.piso2007-06-061-12/+25
| | | | Reviewed by: marius
* Rototill the sparc64 nexus(4) (actually this brings in the code themarius2007-03-071-42/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith)
* o break newbus api: add a new argument of type driver_filter_t topiso2007-02-231-15/+25
| | | | | | | | | | | | | 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@
* - Use bus_get_dma_tag() to obtain the parent DMA tag so dma(4) willmarius2007-01-201-6/+6
| | | | | | | | | work when we start requiring this. - Don't specify an alignment when creating our own parent DMA tag; the supported DMA engines require no alignment constraint (f.e. the LANCE child does though) and it's no inherited by the child DMA tags anyway (which probably is a bug though). - Fix whitespace nits.
* Check the return value of bus_setup_intr() when setting up themarius2007-01-151-10/+12
| | | | | | | over-temperature and power-fail interrupts. Suggested by: Coverity Prevent (CID 683) MFC after: 1 week
* - Merge sys/sparc64/pci/psycho.c rev. 1.8:marius2006-06-081-7/+26
| | | | | | | | | | | | | | | | | | | | | | | | | Map the device memory belonging to resources of type SYS_RES_MEMORY into KVA upon activation so that rman_get_virtual() works as expected. - In sbus_alloc_resource() checking whether toffs is 0 as an indication that no applicable child range was found isn't appropriate as it's perfectly valid for the requested SYS_RES_MEMORY resource to start at the beginning of a child range. So check for the RMAN still being NULL instead. - As a minor runtime speed optimization break out of the loop where we search for the applicable child range in sbus_alloc_resource() as soon as it's found. - Let sbus_setup_intr() return ENOMEM rather than 0 if it can't allocate memory for the interrupt clearing info. - Actually do what the comment in sbus_setup_intr() says and disable the respective interrupt while fiddling with it. - Remove some superfluous INTVEC() around inr, which already only contains the interrupt vector, in sbus_setup_intr(). - While here, fix a style(9) bug in sbus_setup_intr() (don't use function calls in initializers). The first two changes are required for a CG6 driver. MFC after: 2 weeks
* Set the rid for any resource obtained from rman_reserve_resource.imp2006-04-201-0/+1
| | | | Reviewed by: wollman, jmg (as were the other commits fixing this problem)
* o lsi64854_enet_intr():marius2006-01-312-32/+31
| | | | | | | | | | | | | | | | | | | | | | | | | - Like lsi64854_scsi_intr() return -1 in case there was a DMA error so the caller can distinguish it from a normal interrupt and leave the reset of the DMA engine to the caller so we don't kill any state there. - Move the static 'dodrain' flag to struct lsi64854_softc as there can be more than one LSI64854 used for a LANCE in a system and reset it again once draining the E-cache is done so we don't keep draining the cache with every interrupt. - Remove calling sc->sc_intrchain(), we will call lsi64854_enet_intr() via sc->intr() in the interrupt handler of the LANCE driver and not use it in chained mode. o lsi64854_pp_intr(): - Like lsi64854_scsi_intr() return -1 in case there was a DMA error so the caller can distinguish it from a normal interrupt. o Remove the no longer used sc_intrchain* from struct lsi64854_softc. o Make lsi64854_reset(), lsi64854_setup*() and lsi64854_*_intr() static to lsi64854.c as we do and will only call them via the respective function pointers in struct lsi64854_softc. o While here fix style(9) bugs (variable definition inside a nested scope).
* Revert the part of rev. 1.3 which enabled the chaining of the DMA enginemarius2006-01-301-21/+1
| | | | | | | interrupt handler for the LANCE devices and remove dma_setup_intr(). We just can't completely ignore the DMA engine in a LANCE driver anyway and calling the DMA engine interrupt handler in the LANCE driver directly allows to cover it by the LANCE driver lock.
* - Register the generic implementations for the device shutdown, suspendmarius2006-01-262-8/+6
| | | | | | | | | | | | | | and resume methods so these events propagate through the device driver hierarchy. - In dma(4) enable the chaining of the DMA engine interrupt handler for the LANCE devices via a dma_setup_intr(). This was commented out before as I was unsure whether I'd use it but this is probably cleaner than fiddling with the DMA engine interrupt in the LANCE driver directly. - In ebus_setup_dinfo() free 'intrs' instead of 'reg' twice in case setting up a child fails due to routing one of its interrupts fails. [1] Found by: Coverity Prevent [1] MFC after: 3 days
* - Convert these bus drivers to make use of the newly introduced set ofmarius2005-11-222-222/+126
| | | | | | | | | | | | | ofw_bus_gen_get_*() for providing the ofw_bus KOBJ interface in order to reduce code duplication. - While here sync the various sparc64 bus drivers a bit (handle failure to attach a child gracefully instead of panicing, move the printing of child resources common to bus_print_child() and bus_probe_nomatch() implementations of a bus into a <bus>_print_res() function, ...) and fix some minor bugs and nits (plug memory leaks present when attaching a bus or child device fails, remove unused struct members, ...). Additional testing by: kris (central(4) and fhc(4))
* - Try to not leak resources in the attach functions of the esp(4) SBusmarius2005-05-193-14/+540
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | front-end and the LSI64854 and NCR53C9x code in case one of these functions fails. Add detach functions to these parts and make esp(4) detachable. - Revert rev. 1.7 of esp_sbus.c, since rev. 1.34 of sbus.c the clockfreq IVAR defaults to the per-child values. - Merge ncr53c9x.c rev. 1.111 from NetBSD (partial): On reset, clear state flags and the msgout queue. In NetBSD code to notify the upper layer (i.e. CAM in FreeBSD) on reset was also added with this revision. This is believed to be not necessary in FreeBSD and was not merged. This makes ncr53c9x.c to be in sync with NetBSD up to rev. 1.114. - Conditionalize the LSI64854 support on sbus(4) only instead of sbus(4) and esp(4) as it's also required for the 'dma', 'espdma' and 'ledma' busses/devices as well as the 'SUNW,bpp' device (printer port) which all hang off of sbus(4). - Add a driver for the 'dma', 'espdma' and 'ledma' (pseudo-)busses/ devices. These busses and devices actually represent the LSI64854 DMA engines for the ESP SCSI and LANCE Ethernet controllers found on the SBus of Ultra 1 and SBus add-on cards. With 'espdma' and 'ledma' the 'esp' and 'le' devices hang off of the respective DMA bus instead of directly from the SBus. The 'dma' devices are either also used in this manner or on some add-on cards also as a companion device to an 'esp' device which also hangs off directly from the SBus. With the latter variant it's a bit tricky to glue the DMA engine to the core logic of the respective 'esp' device. With rev. 1.35 of sbus.c we are however guaranteed that such a 'dma' device is probed before the respective 'esp' device which simplifies things a lot. [1] - In the esp(4) SBus front-end read the part-unique ID code of Fast-SCSI capable chips the right way. This fixes erroneously detecting some chips as FAS366 when in fact they are not. Add explicit checks for the FAS100A, FAS216 and FAS236 variants instead treating all of these as ESP200. That way we can correctly set the respective Fast-SCSI config bits instead of driving them out of specs. This includes adding the FAS100A and FAS236 variants to the NCR53C9x core code. We probably still subsume some chip variants as ESP200 while in fact they are another variant which however shouldn't really matter as this will only happen when these chips are driven at 25MHz or less which implies not being able to run Fast-SCSI. [3] - Add a workaround to the NCR53C9x interrupt handler which ignores the stray interrupt generated by FAS100A when doing path inquiry during boot and which otherwiese would trigger a panic. - Add support for the 'esp' devices hanging off of a 'dma' or 'espdma' busses or which are companions of 'dma' devices to esp(4). In case of the variants that hang off of a DMA device this is a bit hackish as esp(4) then directly uses the softc of the respective parent to talk to the DMA engine. It might make sense to add an interface for this in order to implement this in a cleaner way however it's not yet clear how the requirements for the LANCE Ethernet controllers are and the hack works for now. [2] This effectively adds support for the onboard SCSI controller in Ultra 1 as well as most of the ESP-based SBus add-on cards to esp(4). With this the code for supporting the Performance Technologies SBS430 SBus SCSI add-on cards is also largely in place the remaining bits were however omitted as it's unclear from the NetBSD how to couple the DMA engine and the core logic together for these cards. Obtained from: OpenBSD [1] Obtained from: NetBSD [2] Clue from: BSD/OS [3] Reviewed by: scottl (earlier version) Tested with: FSBE/S add-on card (FAS236), SSHA add-on card (ESP100A), Ultra 1 (onboard FAS100A), Ultra 2 (onboard FAS366)
* - Add an IVAR for retrieving the interrupt group number of the parent Sbusmarius2005-05-192-9/+55
| | | | | | | | | | | | | | | | | | | | | | | | | device and which also applies to the children. This is very usefull for drivers for the various subordinate busses so they don't need to fiddle with the OFW node of their parent themselves. As SBus busses hang of the nexus and we don't use the ofw_bus interface for nexus devices, yet, this would also require special knowledge about this in the drivers for the SBus children which these shouldn't need to have. This includes switching to use an unshifted IGN in the sc_ign member of the sbus(4) softc internally. - For SBus child devices where there are variants that are actually split split into two SBus devices (as opposed to the first half of the device being a SBus device and the second half hanging off of the first one) like 'auxio' and 'SUNW,fdtwo' or 'dma' and 'esp' probe the SBus device which is a prerequisite to the driver attaching to the second one with a lower order. This saves us from dealing with different probe orders in the respective device drivers which generally is more hackish. - Remove a stale comment about the 'specials' array above the attaching of the child devices. This is a remnant of the NetBSD/sparc origin of this code. There the 'specials' array is also used to probe certain devices which are prerequisites to others first. Why NetBSD soley relies on the devices having the expected order in the OFW tree on sparc64 isn't clear to me, as far as I can tell OFW doesn't guaranteed such things.
* Fix compilation when DEBUG is defined.marius2005-04-181-1/+1
|
* Style and minor changes:marius2005-04-173-121/+102
| | | | | | | | | | | | | - Merge lsi64854.c rev. 1.25 from NetBSD: nuke trailing whitespace. - Update NetBSD RCS IDs according to what was actually already merged. - Remove dv_name from the lsi64854_softc and use device_printf() instead. - Use __func__ instead of hardcoded function names in error messages. - Use ulmin() instead of min() for comparing the DMA sizes as the values involved actually are represented by 64bit unsigned instead of 32bit unsigned. As far as I can't tell this doesn't make a difference in practice though. - Some style(9) fixes (mainly indentation). - Remove unnecessary braces.
* Re-commit the following changes which were committed to these filesmarius2005-04-172-13/+13
| | | | | | | | | | | | | | at their old location in sys/dev/esp after they were repo-copied to sys/sparc64/sbus at rev. 1.1: sys/dev/esp/lsi64854.c rev. 1.2 sys/dev/esp/lsi64854var.h rev. 1.2 Add some style(9) touch ups; style(9) states that new code should follow these conventions and, well, this is a new driver. Tested on: i386, sparc64 Reviewed by: scottl
* - Split the bus probe function into a bus probe and a bus attach functionmarius2005-04-171-57/+70
| | | | | | | | | | | | | | | | | | with the attaching of the children done in the bus attach function like it's supposed to be. - In the bus probe nomatch function print the resources of the children like it's done in the other sparc64 specific bus drivers. - For the clock frequency IVAR use the per-child values and fall back to the bus default in case a child doesn't have the respective property instead of always using the bus default so a child driver doesn't need to obtain the per-child value itself (see also the commit message of sys/dev/esp/esp_sbus.c rev. 1.7). - Add support for pass-through allocations. The comment preceding sbus_alloc_resource() wasn't quite correct, we need to support pass- through allocations for the 'espdma' and 'ledma' (pseudo-)busses which hang off of the SBus in Ultra 1 machines. There can also be actual bridges like the SBus-to-PCMCIA bridge on the SBus and the XBox (SBus extension box) probably also involves one.
* Some clean-up announced in rev. 1.31:marius2005-04-171-80/+67
| | | | | | | | | | | | | | - Use auto-generated typedefs for the prototypes of the device interface functions. - Style(9) fixes (mainly don't use function calls in initializers). - Use __func__ instead of hardcoded function names in error messages. - Try to make error messages sound uniform. - Try to keep the code within 80 columns. - Correct some typos. - Correct some function declarations to match their prototypes. - Remove unused headers, macros and variables. - Remove a bzero() superfluous due to allocating with M_ZERO. - Use FBSDID.
* /* -> /*- for license, minor formatting changesimp2005-01-073-4/+4
|
* Fix paths after repocopies done by scottltrhodes2004-11-101-2/+2
| | | | | Reviewed by: marius OK'ed by: scottl
* - Introduce an ofw_bus kobj-interface for retrieving the OFW node and amarius2004-08-122-33/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* These don't need RMAN_RESOURCE_VISIBLE now that rman is visibleimp2004-07-031-1/+0
|
* These need __RMAN_RESOURCE_VISIBLE, too.marius2004-06-301-0/+2
|
* Port the NetBSD esp(4) driver. This only includes the sbus front-end, soscottl2004-06-103-0/+1041
| | | | | | | | | | | its primary use is for the FEPS/FAS366 SCSI found in Sun Ultra 1e and 2 machines. Once the pci front-end is ported, this driver can replace the amd(4) driver. The code as-is is fairly stable. I've disabled tagged-queueing until I can figure out a corruption bug related to it. I'm importing it now so that people with these machines can (finally) stop netbooting and report bugs before 5.3.
* Add missing <sys/module.h> #includesphk2004-06-041-0/+1
|
* Remove advertising clause from University of California Regent'simp2004-04-072-8/+0
| | | | | | | license, per letter dated July 22, 1999 and email from Peter Wemm, Alan Cox and Robert Watson. Approved by: core, peter, alc, rwatson
* The compatibility specification property is named "compatible", nottmm2004-03-271-1/+1
| | | | | | "compat". Spotted by: Marius Strobl <marius@alchemy.franken.de>
* Don't confuse NULL with 0.obrien2003-12-261-3/+3
|
* s=include <ofw/=include <dev/ofw/= to reflect removal of -I$S/devimp2003-08-231-1/+1
|
* Mega busdma API commit.scottl2003-07-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg. Lockfunc allows a driver to provide a function for managing its locking semantics while using busdma. At the moment, this is used for the asynchronous busdma_swi and callback mechanism. Two lockfunc implementations are provided: busdma_lock_mutex() performs standard mutex operations on the mutex that is specified from lockfuncarg. dftl_lock() is a panic implementation and is defaulted to when NULL, NULL are passed to bus_dma_tag_create(). The only time that NULL, NULL should ever be used is when the driver ensures that bus_dmamap_load() will not be deferred. Drivers that do not provide their own locking can pass busdma_lock_mutex,&Giant args in order to preserve the former behaviour. sparc64 and powerpc do not provide real busdma_swi functions, so this is largely a noop on those platforms. The busdma_swi on is64 is not properly locked yet, so warnings will be emitted on this platform when busdma callback deferrals happen. If anyone gets panics or warnings from dflt_lock() being called, please let me know right away. Reviewed by: tmm, gibbs
* Further cleanup of the sparc64 busdma implementation:tmm2003-06-181-9/+2
| | | | | | | | | | | | | | | | | | | | | | | | | - Move prototypes for sparc64-specific helper functions from bus.h to bus_private.h - Move the method pointers from struct bus_dma_tag into a separate structure; this saves some memory, and allows to use a single method table for each busdma backend, so that the bus drivers need no longer be changed if the methods tables need to be modified. - Remove the hierarchical tag method lookup. It was never really useful, since the layering is fixed, and the current implementations do not need to call into parent implementations anyway. Each tag inherits its method table pointer and cookie from the parent (or the root tag) now, and the method wrapper macros directly use the method table of the tag. - Add a method table to the non-IOMMU backend, remove unnecessary prototypes, remove the extra parent tag argument. - Rename sparc64_dmamem_alloc_map() and sparc64_dmamem_free_map() to sparc64_dma_alloc_map() and sparc64_dma_free_map(), move them to a better place and use them for all map allocations and deallocations. - Add a method table to the iommu backend, and staticize functions, remove the extra parent tag argument. - Change the psycho and sbus drivers to just set cookie and method table in the root tag. - Miscellaneous small fixes.
* Remove the psycho and sbus iommu function stubs, and put the pointertmm2003-06-111-125/+19
| | | | | to the iommu_state structure directly into dt_cookie. The stubs have not been needed for a long time now.
* Bring back bus_dmasync_op_t. It is now a typedef to an int, though thescottl2003-05-271-2/+3
| | | | | | | | BUS_DMASYNC_ definitions remain as before. The does not change the ABI, and reverts the API to be a bit more compatible and flexible. This has survived a full 'make universe'. Approved by: re (bmah)
* De-orbit bus_dmamem_alloc_size(). It's a hack and was never used anyways.scottl2003-05-261-25/+0
| | | | | | No need for it to pollute the 5.x API any further. Approved by: re (bmah)
* - Reduce the DVMA preallocation limit from 128kB to 32kB. 128kB weretmm2003-05-021-1/+1
| | | | | | | | | | | | | quite excessive, and caused the available space to be used up too easily. The new limit should be a better estimation of how much the caller will need at most. - Double the IOTSB size 64kB, for a DVMA area size of 64MB. This should fix DMA problems on e450s and other large machines due to DVMA space exhaustion, which were introduced in my last IOMMU code revision in January. Reported and tested by: fenner
* fix typo in the previous commit.simokawa2003-04-121-1/+1
|
* Change the operation parameter of bus_dmamap_sync() from anmux2003-04-101-3/+2
| | | | | | enum to an int and redefine the BUS_DMASYNC_* constants as flags. This allows us to specify several operations in one call to bus_dmamap_sync() as in NetBSD.
* Back out M_* changes, per decision of the TRB.imp2003-02-191-1/+1
| | | | Approved by: trb
* Fix some more missing dt_ prefixes for dma tag fields.scottl2003-01-291-2/+2
|
* Implement bus_dmamem_alloc_size() and bus_dmamem_free_size() asscottl2003-01-291-0/+25
| | | | | | | | | | | | | | | | | | | | counterparts to bus_dmamem_alloc() and bus_dmamem_free(). This allows the caller to specify the size of the allocation instead of it defaulting to the max_size field of the busdma tag. This is intended to aid in converting drivers to busdma. Lots of hardware cannot understand scatter/gather lists, which forces the driver to copy the i/o buffers to a single contiguous region before sending it to the hardware. Without these new methods, this would require a new busdma tag for each operation, or a complex internal allocator/cache for each driver. Allocations greater than PAGE_SIZE are rounded up to the next PAGE_SIZE by contigmalloc(), so this is not suitable for multiple static allocations that would be better served by a single fixed-length subdivided allocation. Reviewed by: jake (sparc64)
* Remove M_TRYWAIT/M_WAITOK/M_WAIT. Callers should use 0.alfred2003-01-211-1/+1
| | | | Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT.
* Change the iommu code to be able to handle more than one DVMA area pertmm2003-01-061-0/+28
| | | | | | | | | | | map. Use this new feature to implement iommu_dvmamap_load_mbuf() and iommu_dvmamap_load_uio() functions in terms of a new helper function, iommu_dvmamap_load_buffer(). Reimplement the iommu_dvmamap_load() to use it, too. This requires some changes to the map format; in addition to that, remove unused or redundant members. Add SBus and Psycho wrappers for the new functions, and make them available through the respective DMA tags.
OpenPOWER on IntegriCloud