| Age | Commit message (Collapse) | Author |
|
Needed by libdrm_amdgpu.
Based on patch from Jeff Frasca -- thanks!
XXX pullup-10
|
|
implement support for:
- pcie_capability_read_dword()
- pcie_capability_read_word()
- pcie_capability_write_dword()
- pcie_capability_write_word()
- pcie_get_readrq()
- pcie_set_readrq()
implement the "struct pci_dev" bus->self member by creating a minimal fake
"struct pci_dev" for the pci bus itself. this is kind of gross. it checks
that the current device's parent is a netbsd "pci" device, and that it has
a (grand) parent "ppb" device, and then fills in the fake device based upon
the pci and ppb devices.
add some PCIE_LCSR2_TGT_LSPEED encodings, and map them to linux names.
map several other PCIE_LCSR and PCIE_LCAP names.
uncomment several pcie code segments in radeon and amdgpu. (not sure that
we can test the amdgpu_si.c change, as we use the radeon version and the
amdgpu version hangs on the one machine i have.)
tested on amdgpu (RX550) and radeon (7750 & 3650).
ok @riastradh
|
|
- implement pcie_get_speed_cap(), pcie_bandwidth_available(), and
pci_is_root_bus().
- expand "enum pci_bus_speed" to add PCIe 5.x and 6.x speeds.
- add "enum pcie_link_width".
- add defines for PCIE_LCSR_LINKSPEED (PCIe generation) and PCIE_LCSR_NLW
(negotiated lane width) to pcireg.h
- enable amdgpu_device_get_pcie_info() code now it works.
ok riastradh@
|
|
Tested but forgot to amend change before exporting to CVS again.
|
|
|
|
|
|
This horrible kludge dates from before I understood the relation of
genfb_pci and pci drm drivers in the old and new worlds of drm.
The only user of it, in i915, was changed to use agp_i810_borrow
directly in the last drm update, so this hack can die.
|
|
|
|
|
|
|
|
Sort cases by type number.
|
|
|
|
|
|
Don't just zero the part that we're about to initialize -- i915 does
memcmp on the whole structure.
|
|
|
|
|
|
Shoulda done this ages ago.
|
|
The Intel GMBUS (graphics management bus, i2c controller) relies on
this now to fall back from interrupt-driven xfers to bit-banging.
|
|
|
|
This just goes through my recent reference count membar audit and
changes membar_exit to membar_release and membar_enter to
membar_acquire -- this should make everything cheaper on most CPUs
without hurting correctness, because membar_acquire is generally
cheaper than membar_enter.
|
|
This way we get a full lockdebug dump when LOCKDEBUG is enabled,
instead of just the panic message (which includes the lock address
you could pass to `show lock' in ddb, but let's get the dump by
default even if you don't enter ddb).
Also in the KASSERT print the mutex.
|
|
If two threads are using an object that is freed when the reference
count goes to zero, we need to ensure that all memory operations
related to the object happen before freeing the object.
Using an atomic_dec_uint_nv(&refcnt) == 0 ensures that only one
thread takes responsibility for freeing, but it's not enough to
ensure that the other thread's memory operations happen before the
freeing.
Consider:
Thread A Thread B
obj->foo = 42; obj->baz = 73;
mumble(&obj->bar); grumble(&obj->quux);
/* membar_exit(); */ /* membar_exit(); */
atomic_dec -- not last atomic_dec -- last
/* membar_enter(); */
KASSERT(invariant(obj->foo,
obj->bar));
free_stuff(obj);
The memory barriers ensure that
obj->foo = 42;
mumble(&obj->bar);
in thread A happens before
KASSERT(invariant(obj->foo, obj->bar));
free_stuff(obj);
in thread B. Without them, this ordering is not guaranteed.
So in general it is necessary to do
membar_exit();
if (atomic_dec_uint_nv(&obj->refcnt) != 0)
return;
membar_enter();
to release a reference, for the `last one out hit the lights' style
of reference counting. (This is in contrast to the style where one
thread blocks new references and then waits under a lock for existing
ones to drain with a condvar -- no membar needed thanks to mutex(9).)
I searched for atomic_dec to find all these. Obviously we ought to
have a better abstraction for this because there's so much copypasta.
This is a stop-gap measure to fix actual bugs until we have that. It
would be nice if an abstraction could gracefully handle the different
styles of reference counting in use -- some years ago I drafted an
API for this, but making it cover everything got a little out of hand
(particularly with struct vnode::v_usecount) and I ended up setting
it aside to work on psref/localcount instead for better scalability.
I got bored of adding #ifdef __HAVE_ATOMIC_AS_MEMBAR everywhere, so I
only put it on things that look performance-critical on 5sec review.
We should really adopt membar_enter_preatomic/membar_exit_postatomic
or something (except they are applicable only to atomic r/m/w, not to
atomic_load/store_*, making the naming annoying) and get rid of all
the ifdefs.
|
|
|
|
|
|
|
|
|
|
|
|
Except as a fast path in an RCU reader.
The array sizes appear to be reasonably small and not trivially
controlled by userland, from what I can tell, so if my impression is
accurate, it is reasonable to sleep for allocation here.
|
|
via kn_selnext:
- klist_init()
- klist_fini()
- klist_insert()
- klist_remove()
These provide some API insulation from the implementation details of these
lists (but not completely; see vn_knote_attach() and vn_knote_detach()).
Currently just a wrapper around SLIST(9).
This will make it significantly easier to switch kn_selnext linkage
to a different kind of list.
|
|
In other words, if ww_mutex_lock would return -EALREADY, that's OK and
does not warrant an assertion.
PR kern/56557
|
|
Accidentally included more than I intended here.
|
|
|
|
|
|
|
|
|
|
|
|
Requires passing in the caller's lock and condvar to kthread_run, but
for the one user that appears not to be an onerous requirement.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Otherwise, the thread to pakr may be sleeping on some condvar not
noticing it has to notify kthread_park --> deadlock.
|
|
|
|
|
|
|
|
|
|
- wait_on_bit is supposed to wait until the bit is cleared, not set.
- wait_on_bit_timeout is supposed to return 0 on success, -EAGAIN on
faiure.
Omit wake_up_bit; nothing uses it and clear_and_wake_up_bit is a more
semantically coherent operation.
|
|
|