From: Xenia Ragiadakou
> 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.
I can only guess where the hardware guys f*cked it up:-)
> 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).
If 64bit writes are broken, I'd expect the same to be true for the reads.
You should be able to read back a value with both 64bit and two 32bit
reads to see if 64bit requests work.
> 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.
I've got a bit of experience of PCIe from getting a small ppc to 'talk'
efficiently to an altera fpga. I learnt more that I wanted to about PCIe!
My suspicion is that the xhci logic was designed with a 32bit interface
(for its own registers, not its dma engine) that is connected to a PCIe
slave.
However PCIe is inherently a 64bit 'bus' (it isn't a bus at all really).
If the host does a 64bit read/write the PCI logic generates a single 64bit
read/write into the xhci registers, and something would have to convert
that into two 32bit requests. I think that logic is sometimes missing.
It might even just be broken because the guys testing the hardware didn't
try it!
A 32bit transfer is just a 64bit one with only 4 (or the 8) byte enables
asserted - this can be handled by a simple multiplexor.
The fact that readq() seems to be returning 0xffffffff (rather than
either 32bit word or some obvious combination of both words) might
imply that it is just a bug that has got documented so that they
can sell the silicon.
David
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
