architecture doesn't implement 64-bit atomic operations. This
implementation is pessimistic and only flags naturally aligned
operations up to and including 32-bit as lock free.
tested by cwen@
ok gkoehler@
Although there are open questions about whether we should flag failures with
UVM_PMA_FAIL or not, we really should only wake up a sleeper if we unlink
the pma. For now only do that if pages were actually freed in the requested
region.
Prompted by:
CID 1453061 Logically dead code
which should be fixed by this commit.
ok (and together with) beck@
Defer saving the altivec registers until we need to access them (like
how arm defers saving the VFP registers). This prevents a SIGILL on a
G3 cpu when code throws a C++ exception.
ok kettenis@
Use two underbars to start the locally defined variable, as suggested by
guenther@. The other option to avoid namespace conflict would be to start
the identifier with an underbar and a capital.
ok beck@, guenther@
the eMMC module on my rockpro64 and doesn't break the eMMC on the rk3399-q7
board I have. Sadly the eMMC on my firefly-rk3399 died, which may
or may not have something to do with the fact that there were issues
with enabling the output tap delay on that board.
ok patrick@
stack into the USB controller driver, since not all of the xfers
actually use DMA and some invalidations might even be harmful.
The important part is to sync before handing the buffer to the
controller, and to sync on a successful transfer before handing
it back to the USB stack. For isoc transfers it's easier to sync
the complete length of the transfer, since the buffer to flush is
not filled in a contiguous fashion.
For dwc2 there's a common point which takes care of the start
of transfers from or to devices, where we can make sure that our
buffers are synced. On completion, there's a common point before
handing it off to the USB stack.
For ehci there are three places which take care of the start
of transfers from or to devices, where one already does the sync,
while the two other places still need the sync. There are two
completion handler (isoc and non-isoc), where one already has a
comment asking for the need of a sync. The done handler for intr
xfers does a sync that is not needed anymore after adding the sync
in the completion handler.
For ohci there are three places which take care of the start
of transfers from or to devices, where all of them were still in
need of the sync. For completion, there is one place for isoc
xfers and two places for handling successful generic xfers.
For uhci there are two places which take care of the start
of transfers from or to device, where all of them were still in
need of the sync. For completion, there is one handler for both
isoc and non-isoc xfers where syncs need to occur.
For xhci there are three places which take care of the start
of transfers from or to device, where all of them were still in
need of the sync. For completion, there is one handler for isoc
and one for non-isoc xfers where syncs need to occur.
With this we can revert the workaround that implicitly allocated
buffers are COHERENT, since now control transfers fulfilled by the
driver code (instead of the controller doing DMA) are not flushed
into oblivion anymore.
Tested by Janne Johansson with dwc2 (octeon)
Tested by kettenis@ with xhci(4) (octeon)
Tested by patrick@ with ehci(4) on a Cubox-i (armv7)
Tested by patrick@ with xhci(4) on an i.MX8MQ (arm64)
Tested by tobhe@ with dwc2 on a rPi 3b (arm64)
ok kettenis@
It happens not just if the mutex is locked by another thread, but also
if any other threads refer to the mutex (e.g. by waiting for the lock).
ok guenther
