| Age | Commit message (Collapse) | Author |
|---|
|
Add some checks in the interrupt handler to ensure
that the slot and ring referred to by the event have
been initialized.
Also add a check in ctlrcmd() just in case we mess
up the recovery and someone issues a ctlrcmd() after
a failed xhciinit().
|
|
When a ring wraps around, we need to program a wrap around
td with the base address. To get the base, we need to call
Ctlr.dmaaddr() and we used the slot->ctlr pointer to get to
it.
But the command ring has no slot associated to it so we would
crash as soon as we tried to submit more than 256 controller
commands.
The solution is to put a ctlr pointer into the Ring structure,
which also allows us to simplify resetring() and waittd()
as they now can get the controller implicitely thru the ring
pointer.
|
|
|
|
For the reform kernel, we used to have a slightly modified
copy of port/usbxhci.c as the controller was implemented in
soc specific registers and requires some rocket science
initialization.
Instead, we want to have a common generic xhci driver (usbxhci)
and separate drivers that deal with the specific implementation
such as usbxhcipci and usbxhciimx.
|
|
The xhci spec says that the HCRST bit is cleared once the reset is
complete, and that no operational or runtime registers shall be
written while the bit is set.
Waiting for the reset to complete fixes initialization of some host
controllers, such as the ASMedia ASM1142, which otherwise enter an
endless init-recover loop.
Also, add a comment about the reason for the 1ms delay. This appears
to work around a system hang bug in intel chipsets through the 400
series (see errata 15 in [0]).
[0] https://cdrdv2-public.intel.com/620856/620856-009.pdf
|
|
|
|
For "in" transactions, the "Total Bytes to Transfer" field in
the siTD is decremented by the controller by the actual transfer
size, so what remains in the field is the residue number of bytes.
Also, handle restart when we get a zero byte read on a isochronous
"in" endpoint in devusb itself (removing the restart code for
xhci drivers).
This fixes audio recording with a usb1.1 audio device connected
to ehci controller.
|
|
|
|
This makes vmap()/vunmap() take a vlong size argument,
and change the type of Pci.mem[].size to vlong as well.
Even if vmap() wont support large mappings, it is nice to
get the original unruncated value for error checking.
pc64 needs a bigger VMAP window, as system76 pangolin
puts the framebuffer at a physical address > 512GB.
|
|
The timing loop is here for the case if the
controller doesnt produce an interrupt when
becoming broken. In normal case, we should
just get worken up from the interrupt.
In any case, 100 times a second polling is
not neccessary here, increase to 1 second.
|
|
The new pci code is moved to port/pci.[hc] and shared by
all ports.
Each port has its own PCI controller implementation,
providing the pcicfgrw*() functions for low level pci
config space access. The locking for pcicfgrw*() is now
done by the caller (only port/pci.c).
Device drivers now need to include "../port/pci.h" in
addition to "io.h".
The new code now checks bridge windows and membars,
while enumerating the bus, giving the pc driver a chance
to re-assign them. This is needed because some UEFI
implementations fail to assign the bars for some devices,
so we need to do it outselfs. (See pcireservemem()).
While working on this, it was discovered that the pci
code assimed the smallest I/O bar size is 16 (pcibarsize()),
which is wrong. I/O bars can be as small as 4 bytes.
Bit 1 in an I/O bar is also reserved and should be masked off,
making the port mask: port = bar & ~3;
|
|
|
|
|
|
the calculation for the control endpoint0 output device context
missed the context size scaling shift, resulting in botched
stall handling as we would not read the correct endpoint status
value.
note, this calculation only affected control endpoint 0, which
was handled separately from all other endpoints.
|
|
after issuing CR_RESETEP command, we have to invalidate
the endpoints output context buffer so that the halted/error
status reflects the new state. not doing so resulted in
the halted state to be stuck and we continued issuing
endpoint reset commands when we where already recovered.
handle the devusb Ep.clrhalt flag from devusb that userspace
uses to force a endpoint reset on the next transaction.
|
|
|
