#
259065 |
|
07-Dec-2013 |
gjb |
- Copy stable/10 (r259064) to releng/10.0 as part of the 10.0-RELEASE cycle. - Update __FreeBSD_version [1] - Set branch name to -RC1
[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so start releng/10.0 at '100' so the branch is started with a value ending in zero.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
242625 |
|
05-Nov-2012 |
dim |
Remove duplicate const specifiers in many drivers (I hope I got all of them, please let me know if not). Most of these are of the form:
static const struct bzzt_type { [...list of members...] } const bzzt_devs[] = { [...list of initializers...] };
The second const is unnecessary, as arrays cannot be modified anyway, and if the elements are const, the whole thing is const automatically (e.g. it is placed in .rodata).
I have verified this does not change the binary output of a full kernel build (except for build timestamps embedded in the object files).
Reviewed by: yongari, marius MFC after: 1 week
|
#
239941 |
|
31-Aug-2012 |
marius |
Add a global MD macro for the VIS block size instead of duplicating it and using magic values all over the place.
MFC after: 1 week
|
#
233701 |
|
30-Mar-2012 |
marius |
- Remove erroneous trailing semicolon. [1] - Correctly determine the maximum payload size for setting the TX link frequent NACK latency and replay timer thresholds.
Submitted by: stefanf [1] MFC after: 3 days
|
#
233421 |
|
24-Mar-2012 |
marius |
Given that this is a host-PCI-Express bridge driver, create the parent DMA tag with a 4 GB boundary as required by PCI-Express. With r232403 in place this actually is redundant. However, the host-PCI-Express bridge driver is the more appropriate place for implementing this restriction.
MFC after: 3 days
|
#
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.
|
#
225931 |
|
02-Oct-2011 |
marius |
Make sparc64 compatible with NEW_PCIB and enable it: - Implement bus_adjust_resource() methods as far as necessary and in non-PCI bridge drivers as far as feasible without rototilling them. - As NEW_PCIB does a layering violation by activating resources at layers above pci(4) without previously bubbling up their allocation there, move the assignment of bus tags and handles from the bus_alloc_resource() to the bus_activate_resource() methods like at least the other NEW_PCIB enabled architectures do. This is somewhat unfortunate as previously sparc64 (ab)used resource activation to indicate whether SYS_RES_MEMORY resources should be mapped into KVA, which is only necessary if their going to be accessed via the pointer returned from rman_get_virtual() but not for bus_space(9) as the later always uses physical access on sparc64. Besides wasting KVA if we always map in SYS_RES_MEMORY resources, a driver also may deliberately not map them in if the firmware already has done so, possibly in a special way. So in order to still allow a driver to decide whether a SYS_RES_MEMORY resource should be mapped into KVA we let it indicate that by calling bus_space_map(9) with BUS_SPACE_MAP_LINEAR as actually documented in the bus_space(9) page. This is implemented by allocating a separate bus tag per SYS_RES_MEMORY resource and passing the resource via the previously unused bus tag cookie so we later on can call rman_set_virtual() in sparc64_bus_mem_map(). As a side effect this now also allows to actually indicate that a SYS_RES_MEMORY resource should be mapped in as cacheable and/or read-only via BUS_SPACE_MAP_CACHEABLE and BUS_SPACE_MAP_READONLY respectively. - Do some minor cleanup like taking advantage of rman_init_from_resource(), factor out the common part of bus tag allocation into a newly added sparc64_alloc_bus_tag(), hook up some missing newbus methods and replace some homegrown versions with the generic counterparts etc. - While at it, let apb_attach() (which can't use the generic NEW_PCIB code as APB bridges just don't have the base and limit registers implemented) regarding the config space registers cached in pcib_softc and the SYSCTL reporting nodes set up.
|
#
223960 |
|
12-Jul-2011 |
marius |
- Current testing shows that (ab)using the JBC performance counter in bus cycle mode as timecounter just works fine. My best guess is that a firmware update has fixed this, check at run-time whether it advances and use a positive quality if it does. The latter will cause this timecounter to be used instead of the tick counter based one, which just sucks for SMP. - Remove a redundant NULL assignment from the timecounter initialization.
|
#
219785 |
|
19-Mar-2011 |
marius |
- Make a panic message better reflect the actual problem. - A closer inspection of the OpenSolaris code indicates the block store workaround is only necessary in case of BUS_DMASYNC_POSTREAD. - Mark some unused parameters as such.
|
#
216961 |
|
04-Jan-2011 |
marius |
Reserve INTR_MD[1-4] similarly to what BUS_DMA_BUS[1-4] are intended for and switch sparc64 to use the first one for bus error filter handlers of bridge drivers instead of (ab)using INTR_FAST for that so we eventually can get rid of the latter.
Reviewed by: jhb MFC after: 1 month
|
#
209298 |
|
18-Jun-2010 |
nwhitehorn |
Provide for multiple, cascaded PICs on PowerPC systems, and extend the OFW interrupt map interface to also return the device's interrupt parent.
MFC after: 8.1-RELEASE
|
#
203094 |
|
27-Jan-2010 |
marius |
- Zero the MSI/MSI-X queue argument, otherwise mtx_init(9) can panic indicating an already initialized lock. - Check for an empty MSI/MSI-X queue entry before asserting that we have received a MSI/MSI-X message in order to not panic in case of stray MSI/ MSI-X queue interrupts which may happen in case of using an interrupt handler rather than a filter.
MFC after: 3 days
|
#
202023 |
|
10-Jan-2010 |
marius |
When setting up MSIs with a filter ensure that the event queue interrupt is cleared as it might have triggered before and given we supply NULL as ic_clear, inthand_add() won't do this for us in this case.
|
#
202003 |
|
10-Jan-2010 |
marius |
- According to OpenSolaris it's sufficient to align the MSIs of a device in the table based on the count rather than the maxcount. Also the previous code didn't work properly as it would have been necessary to reserve the entire maxcount range in order keep later requests from filling the spare MSIs between count and maxcount, which would be complicated to unreserve in fire_release_msi(). - For MSIs with filters rather than handlers only don't clear the event queue interrupt via fire_intr_clear() since given that these are executed directly would clear it while we're still processing the event queue, which in turn would lead to lost MSIs. - Save one level of indentation in fire_setup_intr(). - Correct a bug in fire_teardown_intr() which prevented it from correctly restoring the MSI in the resource, causing allocation of a resource representing an MSI to fail after the first pass when repeatedly loading and unloading a driver module.
|
#
201200 |
|
29-Dec-2009 |
marius |
- Remove a redundant variable and an unnecessary cast. - Fix whitespace.
|
#
201052 |
|
27-Dec-2009 |
marius |
Add a driver for the `Fire' JBus to PCIe bridges found in at least the Sun Fire V215/V245 and Sun Ultra 25/45 machines. This driver also already includes all the code to support the `Oberon' Uranus to PCIe bridges found in the Fujitsu-Siemens based Mx000 machines but due to lack of access to such a system for testing, probing of these bridges is currently disabled. Unfortunately, the event queue mechanism of these bridges for MSIs/ MSI-Xs matches our current MD and MI interrupt frameworks like square pegs fit into round holes so for now we are generous and use one event queue per MSI, which limits us to 35 MSIs/MSI-Xs per Host-PCIe-bridge (we use one event queue for the PCIe error messages). This seems tolerable as long as most devices just use one MSI/MSI-X anyway. Adding knowledge about MSIs/MSI-Xs to the MD interrupt code should allow us to decouple the 1:1 mapping at the cost of no longer being able to bind MSIs/MSI-Xs to specific CPUs as we currently have no reliable way to quiesce a device during the transition of its MSIs/ MSI-Xs to another event queue. This would still require the problem of interrupt storms generated by devices which have no one-shot behavior or can't/don't mask interrupts while the filter/handler is executed (like the older PCIe NICs supported by bge(4)) to be solved though.
Committed from: 26C3
|