On 29/01/2014 12:08 μμ, Rafał Miłecki wrote:
2014-01-29 David Laight <David.Laight@xxxxxxxxxx>:
Maybe I misunderstand something, but won't that commit end up replacing
the previous pair of writel() with a single native writeq() on 64bit
platforms?
Judging by the comment in front of the xhci_write_64(), that might not
necessarily be supported on all xHCI implementations:
* Some xHCI implementations may support 64-bit address pointers. Registers
* with 64-bit address pointers should be written to with dword accesses by
* writing the low dword first (ptr[0]), then the high dword (ptr[1]) second.
* xHCI implementations that do not support 64-bit address pointers will ignore
* the high dword, and write order is irrelevant.
I wonder if (some of) these implementations actually depend on this
two-cycle write, making __raw_writeq() fail?
I think this is a 32bit kernel on hardware that would support a 64bit one.
This is notebook with i7-2670QM, see cpuinfo.txt for details.
I use x86_64 kernel:
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
(see attached config for details).
So the xhci controller supports 64 bits addressing (etc) but the cpu doesn't
have a 64bit write, so writeq() will do two 32bit accesses.
ISTR that these are in the correct order.
I assume the required compiler barrier is present.
I've enabled some debugging in xhci-dbg.c, does it help?
xhci_hcd 0000:04:00.0: xHCI capability registers at ffffc90004e60000:
xhci_hcd 0000:04:00.0: CAPLENGTH AND HCIVERSION 0x960020:
xhci_hcd 0000:04:00.0: CAPLENGTH: 0x20
xhci_hcd 0000:04:00.0: HCIVERSION: 0x96
xhci_hcd 0000:04:00.0: HCSPARAMS 1: 0x4000820
xhci_hcd 0000:04:00.0: Max device slots: 32
xhci_hcd 0000:04:00.0: Max interrupters: 8
xhci_hcd 0000:04:00.0: Max ports: 4
xhci_hcd 0000:04:00.0: HCSPARAMS 2: 0x17f1
xhci_hcd 0000:04:00.0: Isoc scheduling threshold: 1
xhci_hcd 0000:04:00.0: Maximum allowed segments in event ring: 15
xhci_hcd 0000:04:00.0: HCSPARAMS 3 0x0:
xhci_hcd 0000:04:00.0: Worst case U1 device exit latency: 0
xhci_hcd 0000:04:00.0: Worst case U2 device exit latency: 0
xhci_hcd 0000:04:00.0: HCC PARAMS 0x200f180:
xhci_hcd 0000:04:00.0: HC generates 32 bit addresses
xhci_hcd 0000:04:00.0: FIXME: more HCCPARAMS debugging
xhci_hcd 0000:04:00.0: RTSOFF 0x1000:
Hi Rafał,
Like Bjørn already pointed out, I think too the problem is that the
USB3.0 host controller does not support 64 bit addressing (this can be
seen from the first bit of HCC PARAMS that is 0) but the patch does not
take it into account and blindly tries to perform 64bit write accesses
just because your system is 64bit. My mistake. I will try to find a
solution for that and send a patch when I ll return home.
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
