Hi Sarah,
Are there any news on this issue?
suddenly i don't have usb analyser to find what actually happening (That
is way too expensive for Hobbyist). But probably thinkpenguin.com can
provide you some sample to track it down (CC them).
Am 22.07.2013 20:54, schrieb Oleksij Rempel:
Am 22.07.2013 19:33, schrieb Sarah Sharp:
On Mon, Jul 22, 2013 at 11:43:53AM +0200, Oleksij Rempel wrote:
Hello all,
i'm working on ath9k_htc's suspend/resume issue and need your help.
This devices has problems with suspend mode. After it resume,
USB_PHY stay misconfigured. Only way to bring PHY back to normal is
reset it. Normally it is not a problem for EHCI controllers - they
will reset this adapter even without USB_QUIRK_RESET_RESUME. But it
is not reseted on XHCI controller. At leas not on this one:
lspci -nvvs 00:14.0
00:14.0 0c03: 8086:1e31 (rev 04) (prog-if 30 [XHCI])
Subsystem: 1043:1517
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 41
Region 0: Memory at f7d00000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Address: 00000000fee0a00c Data: 4122
Kernel driver in use: xhci_hcd
here is some log after device resume:
[ 6719.265241] ath9k_htc: Driver unloaded
[ 6723.581445] usb 3-2: reset high-speed USB device number 32 using
xhci_hcd
[ 6723.602774] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880114a40800
[ 6723.602778] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880114a40840
[ 6723.602781] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880114a40880
[ 6723.602784] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880114a408c0
[ 6723.602786] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880114a40900
[ 6723.602790] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880114a40940
[ 6723.603138] usb 3-2: ath9k_htc: Firmware htc_9271.fw requested
Is the code issuing a device reset, or is the code trying to reset the
endpoints?
This dmesg was generated without any extra code in kernel or firmware.
Just USB_QUIRK_RESET_RESUME.
My firmware workaround will do only USB_PHY reset, not complete device.
In this case USB_PHY is FUSB200 ip core.
Can you please enable CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING
and send me the dmesg from shortly before the device is reset, through
just after the device is reset. That will let me see if the xHCI host
is allowing the device to be reset.
attached.
after module is removed in 2 seconds device will be suspended. After
module load, it is resumed. But after some requests i'll get corrupt
packets. Every data packet on EP4, bigger as 64byte will be corrupt. i
_assume_ USB_PHY is misconnfigured. Beside, this endpoint has workaround
in firmware to handle packets bigger 64bytes.
For now i have fallowing workarounds:
- use USB2.0 HC... device is resumed and reseted without any side effects.
- reload xhci_hcd module... should it do device reset?
- do USB_PHY of ath9k_htc from frimware. But it will generate disconnect
event, new device number and so on.
--
Regards,
Oleksij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
