summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* have the ifrxr info stuff report the buffer size the hw handles.dlg2020-12-221-2/+2
| | | | this makes it more consistent with other drivers.
* name the rx rings like ix does for systat mbdlg2020-12-221-1/+2
|
* sync with i915_pciids.hjsg2020-12-201-2/+0
|
* drm/i915: Remove dubious Valleyview PCI IDsjsg2020-12-201-3/+1
| | | | | From Alexei Podtelezhnikov f2bde2546b81b64fb58aa04888fdd82a090b3908 in mainline linux
* remove duplicate device id caused by subids in INTEL_IVB_Q_IDSjsg2020-12-201-1/+0
|
* test against [VM_MIN_ADDRESS, VM_MAXUSER_ADDRESS] in access_ok()jsg2020-12-201-3/+8
| | | | ok kettenis@
* tht(4): more tsleep(9) -> tsleep_nsec(9)cheloha2020-12-171-20/+8
| | | | | | | | | | | | | | | | | The first wait-loop in tht_fw_load() can sleep for at least 10ms per iteration instead of up to 1 tick per iteration with no ill effects. The worst-case scenario is that we sleep a little longer than we do now while we wait. The second wait-loop can be simplified to sleep for at least 10ms per iteration for up to 2000ms instead of using a timeout. This method is less precise and less efficient but is far simpler to read and understand than using a timeout. We can then remove all the timeout-related stuff from if_tht.c. Discussed with mpi@. ok dlg@
* rework the maths used to set mbuf timestamps.dlg2020-12-171-13/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | there's a comment that explains how it works now, but the result is that i get much tighter and more consistent synchronisation between the kernel clock and the values derived from the mcx timestamps now. however, i only just worked out that there is still an unresolved problem where the kernel clock changes how fast it ticks. this happens when ntpd uses adjtime(2) or adjfreq(2) to try and make the kernel tick at the same rate as the rest of the universe (well, the small bit of it that it can observe). these adjustments to the kernel clock immediately skew the timestamps that mcx calculates, but then it also throws off the mcx calibration calculations that run every 30 seconds. the offsets calculated in the next calibration period are often (very) negative. eg, when things are synced up nicely and you do a read of the mcx timer and immediately follow it with a nanouptime(9) call, on this box it calculates that the time in between those two events is about 2600ns. in the calibration period after ntpd did a very small adjtime call, it now thinks the time between those two events is -700000ns. this is a pretty obvious problem in hindsight. i can't think of a simple solution to it at the moment though so i'm going to leave mcx timestamping disabled for now.
* fill in more of mcx_cap_device so i can get to the device frequencies.dlg2020-12-151-1/+78
| | | | | | | fun fact, my Connect-x 4 Lx boards seem to run at 156MHz. less fun fact, mcx_calibrate() seems to work that out pretty well anyway, but the maths is still a bit too wonky to make it usable for mbuf timestamps.
* go to splhigh around the kernel clock and hardware timer reads.dlg2020-12-151-1/+7
| | | | | | | | the idea is to avoid some other work, like a hardware interrupt, running in between the reads of the kernel and chip clocks and therefore skewing the interval calculations. this tightens up a lot of the slop seen when using the cqe timestamp for an mbuf timestamp, but there's still something not quite right.
* turn hardware rx mbuf timestamping off by default.dlg2020-12-151-2/+2
| | | | | | | | | | | | | | | we see too many ntp replies (appear to) arrive before the request for them was sent, which ntpd handles by disabling the peer for an hour. this was a lot easier to narrow down after fixing up bpf and timestamps, cos it let me see this: 16:50:36.051696 802.1Q vid 871 pri 3 192.0.2.55.47079 > 162.159.200.123.123: v4 client strat 0 poll 0 prec 0 [tos 0x10] 16:50:36.047201 802.1Q vid 871 pri 3 162.159.200.123.123 > 192.0.2.55.47079: v4 server strat 3 poll 0 prec -25 (DF) im going to borrow the link0 flag for a bit to allow turning timestamping on.
* neuter the shutdown hooks for now, they seem to crash the fw on some boards.dlg2020-12-151-1/+5
| | | | grumble grumble
* remove unused include linux no longer hasjsg2020-12-141-0/+0
|
* remove unused (and wrong) disable_irq() and enable_irq() definesjsg2020-12-141-3/+0
|
* set scatterlist to NULL after freejsg2020-12-131-1/+2
|
* remove unused wait interfacesjsg2020-12-132-23/+3
|
* Rename the macro MCLGETI to MCLGETL and removes the dead parameter ifp.jan2020-12-1228-66/+66
| | | | | | OK dlg@, bluhm@ No Opinion mpi@ Not against it claudio@
* use jiffies var instead of ticks when checking for timeoutjsg2020-12-102-10/+11
|
* remove timespec_to_jiffies() which no longer exists in linuxjsg2020-12-101-12/+0
|
* ix_txq_kstats_read() should look at a tx_ring struct, not rx_ring.dlg2020-12-091-2/+2
| | | | | | | luckily tx_rings and rx_rings have ix_softc pointers in the same place, so we got away with it. from Christiano Haesbaert
* Call ttm_tt_unpopulate() instead of directly calling ttm_tt_unpopulatejsg2020-12-081-1/+1
| | | | | | function pointer in ttm_tt_swapout(). Reduces the diff to linux. ok kettenis@
* correct ttm_tt error paths if bus_dmamap_create() failsjsg2020-12-081-2/+9
| | | | | | | | Avoids a double free of gtt in amdgpu_ttm_tt_create() if the bus_dmamap_create() call in ttm_sg_tt_init() fails and ttm_tt_destroy() calls amdgpu_ttm_backend_destroy(). feedback from and ok kettenis@
* Fix calculation of "maxlen" if there are multiple MPDUs in one packet.tobhe2020-12-071-8/+2
| | | | | | | | | | Calculating "remain" by subtracting the offset after every parsed MPDU is wrong and not necessary. "offset" always points to the current position in the receive buffer and the maximum size of the buffer is fixed, thus knowing "offset" is sufficient for finding "maxlen". Found by and fix from Christian Erhardt ok stsp@
* Fix calculation of "maxlen" if there are multiple MPDUs in one packet.tobhe2020-12-071-8/+2
| | | | | | | | | | Calculating "remain" by subtracting the offset after every parsed MPDU is wrong and not necessary. "offset" always points to the current position in the receive buffer and the maximum size of the buffer is fixed, thus knowing "offset" is sufficient for finding "maxlen". Found by and fix from Christian Erhardt ok stsp@ phessler@
* remove unused (and wrong) page_address() macrojsg2020-12-071-1/+0
| | | | this is supposed to return a va for a page not pa
* change from bus_addr_t to paddr_t for phys_addr_t and resource_size_tjsg2020-12-071-2/+2
| | | | Types stay unsigned long; we don't do 64 bit paddr_t on any 32 bit arch.
* mbg(4): more tsleep(9) -> tsleep_nsec(9)cheloha2020-12-061-7/+7
| | | | | | | | | | | | | | | | The mbg(4) driver sometimes needs to spin until the MBG_BUSY flag goes away. If the kernel is cold it calls delay(9) for 20us an iteration for up to 50 iterations. If the kernel is not cold it sleeps for up 1 tick per iteration for up to hz/10 iterations. To switch from tsleep(9) to tsleep_nsec(9) claudio@ suggests blocking for at least 1ms per iteration for up to 10 iterations. He reasons that the flag change is expected to take ~70us, so 10 x 1ms (or more) is more than enough. Discussed with mpi@. ok claudio@
* Use DC_FP_START()/DC_FP_END() around dcn2.1 paths known to causejsg2020-11-301-0/+6
| | | | | | | | | | | SSE FP exception traps, update_bw_bounding_box() and dcn20_populate_dml_pipes_from_context(). The scope around the dcn20_fast_validate_bw() call is large to match DC_FP_START()/DC_FP_END() use in dcn20_resource.c and avoid the situation where a dcn2.0 path would have nested DC_FP_START() calls. ok kettenis@
* regenkettenis2020-11-292-2/+7
|
* Add Marvell ARMADA 3700 bridge.kettenis2020-11-291-1/+2
|
* Un-const pci_attach_args var.kevlo2020-11-294-8/+8
| | | | "yes guess so" deraadt@
* Add initialization of sc_sff_lock rwlock.kevlo2020-11-271-1/+3
| | | | ok semarie@
* fter ixgbe_stop() there will be no more link-state-changegerhard2020-11-241-1/+3
| | | | | | interrupts. Hence, update the link state manually. Tested and ok bluhm@
* Enabling RGE_ISR_RX_DESC_UNAVAIL causes an interrupt storm, so disableotto2020-11-221-2/+2
| | | | until the root cause is found. ok kevlo@ kettenis@
* Add barriers in the IO helper functions just like what was done for amdgpu(4).kettenis2020-11-211-6/+22
| | | | ok patrick@, jsg@
* The conversion of the IO BAR access did not completely mirror thepatrick2020-11-191-6/+22
| | | | | | | | | | | | behaviour of Linux' implementation: arm64's bus space operations have no barriers, so while Linux' iowrite32/ioread32 explicitly contain barriers, using bus space read/write is not enough on arm64. Add read barriers after a read to make sure that all reads have completed before the following reads. Add write barriers before a write to make sure all previous writes have completed before that write. This fixes panics on the HoneyComb LX2K with amdgpu(4). ok kettenis@
* fix build on loongson with clangjsg2020-11-181-3/+4
| | | | initial diff from and ok visa@
* regenjsg2020-11-182-2/+22
|
* add Realtek RealManage devicesjsg2020-11-181-1/+5
|
* remove unused definitions which no longer exist in linuxjsg2020-11-174-8/+2
|
* remove setup_timer() interface linux removed in 2017jsg2020-11-172-8/+10
|
* fix time_after32() macrojsg2020-11-171-1/+1
|
* adjust for reversed outb arguments linux usesjsg2020-11-171-0/+4
|
* regenkevlo2020-11-162-2/+72
|
* Add PCI ids for Intel 2.5Gb adapters.kevlo2020-11-161-1/+15
| | | | ok jsg@
* Revise the initialization of the DRM Linux emulation layer such that wekettenis2020-11-142-30/+33
| | | | | | | | only call it when the first drm(4) instance attaches. Also add a cleanup function that gets called when the last drm(4) instance detaches. This makes sure that statically initialized IDR instances always work. ok jsg@, semarie@
* idr limit should be inclusivejsg2020-11-141-3/+7
| | | | ok kettenis@
* Bring IDR function prototypes in line with modern Linux and implementkettenis2020-11-142-37/+23
| | | | | | | IDA functions in terms of IDR. Fixes issues with running out of PASIDs in amdgpu(4). ok jsg@
* whitespacekettenis2020-11-141-2/+2
|
* We should only grab the drm_global_mutex lock for legacy drivers.kettenis2020-11-141-1/+3
| | | | | | Spotted thanks to debugging work by semarie@ ok jsg@, semarie@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.