On 30/01/2014 11:21 πμ, Rafał Miłecki wrote:
2014-01-29 Xenia Ragiadakou <burzalodowa@xxxxxxxxx>:
Rafał is it possible to send all the "bad" output with xhci debugging on?
Since your config file shows that dynamic debugging is on, that would be
easy to do by adding dyndbg='module xhci_hcd +p' or xhci_hcd.dyndbg=+p boot
option to your linux command line.
Also, I am interested in the lspci -v output related to your usb3
controllers.
Sure. I booted without any USB device connected and then with
04d8:00df connected to the USB 3.0 port.
I also attach full lspci output (with -nnv) just in case.
Thanks a lot! The following logs show that definitely something does not
go well when you perform 64bit mmio transfers:
[snip]
[ 2.599818] xhci_hcd 0000:04:00.0: // Setting command ring address to
0x20
[ 2.649882] xhci_hcd 0000:04:00.0: // xHC command ring deq ptr low
bits + flags = @ffffffff
[ 2.649884] xhci_hcd 0000:04:00.0: // xHC command ring deq ptr high
bits = @ffffffff
[snip]
[ 2.850199] xhci_hcd 0000:04:00.0: ERST deq = 64'hfffffffffffffff0
[ 2.850202] xhci_hcd 0000:04:00.0: // Set the interrupt modulation
register
[ 2.850210] xhci_hcd 0000:04:00.0: // Enable interrupts, cmd = 0x4.
[ 2.850215] xhci_hcd 0000:04:00.0: // Enabling event ring interrupter
ffffc900056f1020 by writing 0x2 to irq_pending
[ 2.850221] xhci_hcd 0000:04:00.0: ffffc900056f1020: ir_set[0]
[ 2.850223] xhci_hcd 0000:04:00.0: ffffc900056f1020: ir_set.pending
= 0x2
[ 2.850227] xhci_hcd 0000:04:00.0: ffffc900056f1024: ir_set.control
= 0xa0
[ 2.850232] xhci_hcd 0000:04:00.0: ffffc900056f1028:
ir_set.erst_size = 0x1
[ 2.900268] xhci_hcd 0000:04:00.0: ffffc900056f1030:
ir_set.erst_base = @ffffffffffffffff
[ 2.950340] xhci_hcd 0000:04:00.0: ffffc900056f1038:
ir_set.erst_dequeue = @ffffffffffffffff
[snip]
And since after reverting the writeq patch, everything works then for
sure writeq does not seem to work as I expected. Probably the 64bit
transaction on the bus is not atomic, but David seems to understand
better what could be the reason for that problem.
Another thing is whether readq works correctly. According to xhci specs,
the bits of the command ring control register when read should return
always 0 (except from the bit 3).
So, i wonder why readq returns 0xffffffffffffffff (xHC command ring deq
ptr low bits + flags = @ffffffff, xHC command ring deq ptr high bits =
@ffffffff).
Still I cannot understand though why ordered split transfers are
necessary for 32bit capable usb3.0 host controllers. Maybe the ordered
32bit transfers its a requirement by some usb3.0 host controllers in
order to read/write 64bit fields, regardless their addressing capability.
best regards,
ksenia
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
