Re: Difference between run time and normal suspend
hi Alan:
2015-01-19 0:49 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Sun, 18 Jan 2015, vichy wrote:
after tracing the source, I only can find the ehci_suspend is called
when system hibernate/suspend.
rpm_suspend use below method to find out suspend callback
if (dev-pm_domain)
callback = dev-pm_domain-ops.runtime_suspend;
else if (dev-type dev-type-pm)
callback = dev-type-pm-runtime_suspend;
else if (dev-class dev-class-pm)
callback = dev-class-pm-runtime_suspend;
else if (dev-bus dev-bus-pm)
callback = dev-bus-pm-runtime_suspend;
else
callback = NULL;
ehci_suspend doesn't register any one of above function.
ehci_pci_init() in ehci_pci.c stores ehci_suspend in
ehci_pci_hc_driver.pci_suspend. That pointer is called by
suspend_common() in hcd-pci.c, which is called by both
hcd_pci_suspend() and hcd_pci_runtime_suspend().
I have several questions:
a.
in ehci-pci driver, the runtime suspend is register in the driver
structure, driver-pm, like below.
static struct pci_driver ehci_pci_driver = {
...
.probe =usb_hcd_pci_probe,
.remove =usb_hcd_pci_remove,
.shutdown = usb_hcd_pci_shutdown,
#ifdef CONFIG_PM_SLEEP
.driver ={
.pm =usb_hcd_pci_pm_ops
},
#endif
};
But rpm_suspend search runtime suspend from device structure.
like dev-pm_domain, dev-type, dev-class, dev-bus, etc.
Why hcd_pci_runtime_suspend will be called?
b.
Contrary to pci system, in ehci-platfomr.c, there is no any runtime
suspend call back register in ehci_platform_pm_ops.
Could we get the conclusion that ehci controller will NOT be suspended
when all device on the root hub and root hub are suspended?
Sincerely appreciate your kind help,
--
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
Re: [PATCH 2/2] Add HCS_PPC when getting root hub status
hi alan 2015-01-19 1:06 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Sun, 18 Jan 2015, Chechun Kuo wrote: for some platform ehci controller, it is possible there is no port power control capability in the root hub. And we add port power control determination when getting root hub port status. Why do you need to do this? Doesn't the current code always give the right result? My host controller doesn't support PPC, and the PORT_POWER bit will not be one even when device is powered up. After I checking the ehci spec, it should be HW's issue, since spec say PP should be one even when PPC is zero. Sorry to make you confuse ^^ -- 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
Re: [PATCH 1/2] Add hub port switchable when checking port power
2015-01-19 1:04 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Sun, 18 Jan 2015, Chechun Kuo wrote: In check_port_resume_type, we will check port power status to determine whether the status should change to -ENODEV. If all ports power control of the hub are handled at once, the port power status may not represent the real case and cause resume fail. At this patch, we add hub_is_port_power_switchable as well as checking the port power. I don't understand the reason for this patch. Are you saying that the PORT POWER bit in the port status will be wrong (that is, will be 0) if the hub doesn't support power switching? According to section 11.24.2.7.1.6 of the USB-2 spec: This bit is implemented on all ports whether or not actual port power switching devices are present. So why is this patch needed? Does it fix any real problems? this patch fixed the failure of runtime suspend happened on my host controller root hub. After reading what you point out above and ehci spec, I found it is our HW's issue for handling PP when PPC is zero. I am really sorry to make you confused ^^ Sincerely appreciate your kind help, -- 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
Re: Difference between run time and normal suspend
Is 3rd situation you mentioned above the function will be called is hcd-bus_suspend? hcd-bus_suspend will be called first, and shortly afterward ehci-suspend will be called (if this is an EHCI controller). Fourthly, you should realize that controller itself will also be put into runtime suspend means the controller itself will be put into runtime suspend. is 4th situation you mentioned above the function will be called is ehci_suspend, (take ehci for example)? Yes. after tracing the source, I only can find the ehci_suspend is called when system hibernate/suspend. rpm_suspend use below method to find out suspend callback if (dev-pm_domain) callback = dev-pm_domain-ops.runtime_suspend; else if (dev-type dev-type-pm) callback = dev-type-pm-runtime_suspend; else if (dev-class dev-class-pm) callback = dev-class-pm-runtime_suspend; else if (dev-bus dev-bus-pm) callback = dev-bus-pm-runtime_suspend; else callback = NULL; ehci_suspend doesn't register any one of above function. but ehci_supend is called when system is going to suspend/hibernate, or it will be called even in runtime suspend? Both. BTW, when I turn off the led on the keyboard, the keyboard can successfully go to runtime suspend. Good. Would you mind to let us know how you find out the problem from mon files? Is it due there is no remote wake control message on the mon file? The usbmon trace showed that the interrupt URB for one of the HID interfaces was cancelled (indicating that the interface had been suspended) but the interrupt URB for the other HID interface was not cancelled (indicating that the interface had failed to suspend). Reading the source code for the usbhid driver showed that there are only a few reasons for failing to suspend an interface, and one of those reasons was if an LED was illuminated. Sincerely appreciate your kind help, -- 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
Re: Difference between run time and normal suspend
hi alan: Firstly, you should realize that a hub port can be put into suspend _only_ if a device is plugged into it. If nothing is plugged into a port then the port cannot be put into suspend. Secondly, you should realize that putting a USB device into suspend means the same thing as suspending the hub port the device is plugged into. Thirdly, you should realize therefore that if _all_ the devices attached to the host controller are in runtime suspend, then all the connected ports must be suspended. (And none of the disconnected ports can be suspended, since it is impossible to suspend a disconnected port.) Is 3rd situation you mentioned above the function will be called is hcd-bus_suspend? Fourthly, you should realize that controller itself will also be put into runtime suspend means the controller itself will be put into runtime suspend. is 4th situation you mentioned above the function will be called is ehci_suspend, (take ehci for example)? but ehci_supend is called when system is going to suspend/hibernate, or it will be called even in runtime suspend? BTW, when I turn off the led on the keyboard, the keyboard can successfully go to runtime suspend. Would you mind to let us know how you find out the problem from mon files? Is it due there is no remote wake control message on the mon file? Sincerely appreciate your kind help, -- 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
Re: Difference between run time and normal suspend
hi Alan: 3. for host part, runtime suspend/resume is only doing port suspend/resume or both host and port going to suspend/resume? Only the port. However, when _all_ the devices attached to the host controlluer go into runtime suspend, the controller itself will also be put into runtime suspend. here controller itself will also be put into runtime suspend. mean the controller itself will put into suspend or root hub ports will put in suspend? Sincerely appreciate your kind help, -- 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
What is usb fs driver used for
hi all: usually the usb_driver is matched by usb_device_id or usb_dynids. But there is any of them above defined in usb fs driver. if so, what is usb fs driver used for when registered in the usb_init of core/usb.c? appreciate all your kine explanation in the advance, -- 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
Re: Difference between run time and normal suspend
hi alan: 2015-01-06 23:54 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Tue, 6 Jan 2015, vichy wrote: But I cannot see the keyboard go to suspend even I force autosuspend as 0. is there any other way to trigger runtime suspend immediately instead of waiting kernel judge it is idle for a while? There may be other reasons why the keyboard does not get suspended. For example, it may not support remote wakeup. What does lsusb -v show? And what does usbmon show? here is the output of lsusb and usbmon will be attach soon. BTW, 1. is there any other method to trigger runtime suspend instead of waiting device to be idle. such as echo xxx , and it will directly call runtime suspend related function No, there isn't. 2. why remote wake up feature of hid is related to runtime suspend? runtime suspend is kernel use to saving power and suspend/resume actively, right? That's true. But it wouldn't work very well if the keyboard went into runtime suspend and stayed that way even when you tried to type on it! If a keyboard doesn't support remote wakeup then we must not put it into runtime suspend. I attach usbmon for your reference. But keyboard is still not working on runtime suspend. However, I see from the lsusb output that your keyboard _does_ support remote wakeup, so that isn't the reason. 3. for host part, runtime suspend/resume is only doing port suspend/resume or both host and port going to suspend/resume? Only the port. However, when _all_ the devices attached to the host controlluer go into runtime suspend, the controller itself will also be put into runtime suspend. Would you mind to show me where the program determine controller go into runtime suspend if all devices on it go to suspend? BTW a. if even controller suspended, does that mean all devices on it will be disconnect and re-enumerated when resume? b. is there any usb sysfs file can let us suspend specific port on root or normal hub? appreciate your kind help, liteon.keyboard.mon.tar.bz2 Description: BZip2 compressed data
Re: Difference between run time and normal suspend
hi alan: 2015-01-06 8:39 GMT+08:00 vichy vichy@gmail.com: 2015-01-05 23:40 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Mon, 5 Jan 2015, vichy wrote: hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? No. That directory will never be empty. You can check whether runtime suspend works by enabling it: echo auto /sys/bus/usb/devices/.../power/control You can see whether the device has been suspended by looking at the runtime_status and runtime_suspended_time files in the .../power directory. I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. But I cannot see the keyboard go to suspend even I force autosuspend as 0. is there any other way to trigger runtime suspend immediately instead of waiting kernel judge it is idle for a while? appreciate your help in advance, # lsmod Not tainted usbhid 21486 0 - Live 0xbe4a3000 hid_generic 954 0 - Live 0xbe49f000 hid 72898 2 usbhid,hid_generic, Live 0xbe487000 usb_storage 43962 0 - Live 0xbe473000 ehci_hcd 60249 0 - Live 0xbe45e000 xhci_hcd 92188 0 - Live 0xbe441000 usbcore 182850 4 usbhid,usb_storage,ehci_hcd,xhci_hcd, Live 0xbe404000 usb_common 1822 1 usbcore, Live 0xbe40 # # [0-57.0178] usb 6-1: new low-speed USB device number 3 using platform-ehci [0-57.1687] usb 6-1: New USB device found, idVendor=04ca, idProduct=002f [0-57.1752] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [0-57.1821] usb 6-1: Product: USB Multimedia Keyboard [0-57.1869] usb 6-1: Manufacturer: Lite-On Technology Corp. [0-57.2035] input: Lite-On Technology Corp. USB Multimedia Keyboard as /devices/fc1a.ehci/usb6/6-1/6-1:1.0/input/input0 [0-57.2152] hid-generic 0003:04CA:002F.0001: input: USB HID v1.10 Keyboard [Lite-On Technology Corp. USB Multimedia Keyboard] on usb-platform-1/input0 [0-57.2409] input: Lite-On Technology Corp. USB Multimedia Keyboard as /devices/fc1a.ehci/usb6/6-1/6-1:1.1/input/input1 [0-57.2522] hid-generic 0003:04CA:002F.0002: input: USB HID v1.10 Device [Lite-On Technology Corp. USB Multimedia Keyboard] on usb-platform-1/input1 # # cat /sys/bus/usb/devices/6-1/power/control on # echo auto /sys/bus/usb/devices/6-1/power/control # echo 0 /sys/bus/usb/devices/6-1/power/autosuspend # cat /sys/bus/usb/devices/6-1/power/ active_duration runtime_active_time wakeup_count autosuspend runtime_status wakeup_expire_count autosuspend_delay_msruntime_suspended_time wakeup_last_time_ms connected_duration wakeup wakeup_max_time_ms control wakeup_abort_count wakeup_total_time_ms level wakeup_active persist wakeup_active_count # cat /sys/bus/usb/devices/6-1/power/runtime_status active # cat /sys/bus/usb/devices/6-1/power/runtime_suspended_time 0 #
Re: Difference between run time and normal suspend
hi all: 2015-01-06 16:06 GMT+08:00 vichy vichy@gmail.com: hi alan: 2015-01-06 8:39 GMT+08:00 vichy vichy@gmail.com: 2015-01-05 23:40 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Mon, 5 Jan 2015, vichy wrote: hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? No. That directory will never be empty. You can check whether runtime suspend works by enabling it: echo auto /sys/bus/usb/devices/.../power/control You can see whether the device has been suspended by looking at the runtime_status and runtime_suspended_time files in the .../power directory. I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. But I cannot see the keyboard go to suspend even I force autosuspend as 0. is there any other way to trigger runtime suspend immediately instead of waiting kernel judge it is idle for a while? I test the same keyboard on the NB is also not seeing autosuspend work. the kernel version of NB is 3.18 and my embedded system is 3.10 (I also attach usb descriptor of the keyboard I used in the mail) thanks for your help, liteon.keyboard.desc.txt.tar.bz2 Description: BZip2 compressed data
Re: Difference between run time and normal suspend
hi Alan: 2015-01-06 23:03 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Tue, 6 Jan 2015, vichy wrote: I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. But I cannot see the keyboard go to suspend even I force autosuspend as 0. is there any other way to trigger runtime suspend immediately instead of waiting kernel judge it is idle for a while? There may be other reasons why the keyboard does not get suspended. For example, it may not support remote wakeup. What does lsusb -v show? And what does usbmon show? here is the output of lsusb and usbmon will be attach soon. BTW, 1. is there any other method to trigger runtime suspend instead of waiting device to be idle. such as echo xxx , and it will directly call runtime suspend related function 2. why remote wake up feature of hid is related to runtime suspend? runtime suspend is kernel use to saving power and suspend/resume actively, right? 3. for host part, runtime suspend/resume is only doing port suspend/resume or both host and port going to suspend/resume? appreciate your kind help, liteon.keyboard.desc.txt.tar.bz2 Description: BZip2 compressed data
Difference between run time and normal suspend
hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? 2. I plug in one mouse and found the device will auto disconnect every 2 secs, the default value of usb_autosuspend_delay. But I have some questions a. how kernel judge the device is idle, from usb spec, the idle mean there is no any bus traffic, including sof, over 3ms and host will always firing sof even there is no transaction on the bus. b. I think dynamic suspend is used for saving power when device is idle for a specific time, but why the mouse will dynamic resume when suspend for a while. it should resume when user or external event trigger it for resume right? appreciate your help in advance, -- 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
Re: Difference between run time and normal suspend
2015-01-05 23:40 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Mon, 5 Jan 2015, vichy wrote: hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? No. That directory will never be empty. You can check whether runtime suspend works by enabling it: echo auto /sys/bus/usb/devices/.../power/control You can see whether the device has been suspended by looking at the runtime_status and runtime_suspended_time files in the .../power directory. 2. I plug in one mouse and found the device will auto disconnect every 2 secs, the default value of usb_autosuspend_delay. But I have some questions a. how kernel judge the device is idle, from usb spec, the idle mean there is no any bus traffic, including sof, over 3ms and host will always firing sof even there is no transaction on the bus. The kernel judges a device to be idle if it hasn't been used in some time. The bus traffic has nothing to do with it. b. I think dynamic suspend is used for saving power when device is idle for a specific time, but why the mouse will dynamic resume when suspend for a while. it should resume when user or external event trigger it for resume right? That's right. If your mouse is resuming, it must be because some event has triggered the resume. The mouse will reconnect even I just kept it connected and not moving it. is there any method or debug message we can tell what is going on to make it resume? sincere appreciate your help, -- 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
Re: Proper delay function in host driver
hi alan: 2014-12-19 23:20 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Fri, 19 Dec 2014, vichy wrote: hi all: For HW bug, we have to mdelay(100) in getting root hub port status. That's quite a bug! 100 ms is a very long delay. With a bug that big, it's questionable whether the hardware will work correctly at all. But it suffer system performance. (The place we need to add is like below) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 388cfd8..9a6b841 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -760,6 +760,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, retval = -ENODEV; break; } + mdelay(100); status = xhci_get_port_status(hcd, bus_state, port_array, wIndex, temp, flags); if (status == 0x) Then I try to use msleep(100) but I found hub_port_status will first mutex_lock(hub-status_mutex); then calling get_port_status. That mean the deadlock may happen. No it doesn't. Why it doesn't? from the source, the get_port_status did called in critical section protected by hub-status_mutex. And msleep is not allowed in critical section. appreciate your help, -- 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
Proper delay function in host driver
hi all: For HW bug, we have to mdelay(100) in getting root hub port status. But it suffer system performance. (The place we need to add is like below) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 388cfd8..9a6b841 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -760,6 +760,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, retval = -ENODEV; break; } + mdelay(100); status = xhci_get_port_status(hcd, bus_state, port_array, wIndex, temp, flags); if (status == 0x) Then I try to use msleep(100) but I found hub_port_status will first mutex_lock(hub-status_mutex); then calling get_port_status. That mean the deadlock may happen. Is there any better way to do so? appreciate your kind help in advance, -- 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
Re: Question about calculate trbs in xhci
hi Mathias: As I understood it, it is ok to cross page boundaries as long as the buffer is physically contiguous. As our dma case should be. xhci specification section 3.2.8 says that: Note that no constraints are placed on the TRB Length fields in a Scatter/Gather list. Classically all the buffers pointed to by a scatter gather list were required to be “page size” in length except for the first and last (as illustrated by the example above). The xHCI does not require this constraint. Any buffer pointed to by a Normal, Data Stage, or Isoch TRB in a TD may be any size between 0 and 64K bytes in size. For instance, if when an OS translates a virtual memory buffer into a list of physical pages, some of the entries in the list reference multiple contiguous pages, the flexible Length fields of TRBs allow a 1:1 mapping of list entries to TRBs, i.e. a multi-page list entry does not need to be defined as multiple page sized TRBs. Yes, you are correct. ^^ there is no page boundary limitation for Scatter/Gather list, but how about iso transfer? for iso TRB, it seems a limitation for not crossing page boundary in section 3.2.11. appreciate all your kind help, -- 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
Question about calculate trbs in xhci
hi all: for iso transactions, we use below function to calculate trbs addr = (u64) (urb-transfer_dma + urb-iso_frame_desc[i].offset); td_len = urb-iso_frame_desc[i].length; num_trbs = DIV_ROUND_UP(td_len + (addr (TRB_MAX_BUFF_SIZE - 1)), TRB_MAX_BUFF_SIZE); Could we use below method to calculate it instead? addr = (u64) (urb-transfer_dma + urb-iso_frame_desc[i].offset); td_len = urb-iso_frame_desc[i].length; -num_trbs = DIV_ROUND_UP(td_len + (addr (TRB_MAX_BUFF_SIZE - 1)), TRB_MAX_BUFF_SIZE); + num_trbs = DIV_ROUND_UP(td_len ,TRB_MAX_BUFF_SIZE); Why the trb calculation for iso is related to dma address? Appreciate your kind help in advance, -- 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
Re: Question about calculate trbs in xhci
hi David:
Because the trb buffers can't cross a 64k physical address boundary.
Is it only specific to iso scheduling or bulk also need to take care?
from your kind explanation, the trb buffer for Bulk also need to take
care crossing 64k physical boundary.
But i don't find it for bulk transfer.
Below is excerpted from xhci_queue_bulk_tx
while (running_total urb-transfer_buffer_length) {
num_trbs++;
running_total += TRB_MAX_BUFF_SIZE;
}
appreciate your kind help,
--
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
Re: Question about calculate trbs in xhci
hi David and All:
Because the trb buffers can't cross a 64k physical address boundary.
Is it only specific to iso scheduling or bulk also need to take care?
from your kind explanation, the trb buffer for Bulk also need to take
care crossing 64k physical boundary.
But i don't find it for bulk transfer.
Below is excerpted from xhci_queue_bulk_tx
while (running_total urb-transfer_buffer_length) {
num_trbs++;
running_total += TRB_MAX_BUFF_SIZE;
}
Hmmm... that looks like a division by a power of 2!
I am not quite understand what you mean a division by a power of 2
Would you please give me more hint? ^^
The constraint applies to all TRB.
i found where bulk handle 64k physical address boundary as you explain.
it just a couple lines ahead of the source code I captured in the
previous mail :P
Meanwhile, I have another question:
for iso transfer, the first iso trb cannot cross page boundary,
but I cannot find this restriction in xhci driver.
appreciate all your kind help,
--
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
Re: Question about calculate trbs in xhci
hi Mathias: In xhci-ring.c, static int xhci_queue_isoc_tx(): /* Calculate TRB length */ trb_buff_len = TRB_MAX_BUFF_SIZE - (addr ((1 TRB_MAX_BUFF_SHIFT) - 1)); where addr = start_addr + urb-iso_frame_desc[i].offset; this limits the trb_buff_len to stop the trb buffer at TRB_MAX_BUFF_SIZE boundary Yes, you are right. the above is make sure trb buffer will not cross over TRB_MAX_BUFF_SIZE boundary. But it still possible to cross the page boundary for ISO trb, right? (suppose page boundary is 4KB, TRB_MAX_BUFF_SIZE is 64KB) appreciate your kind help, -- 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
Re: usb sound cannot get frequency from enpoind
hi all: I get the same message on kernel 3.16.0 and attach the device information as well. (from the description, the ep 0x82 did have different sample rate configuration, but why uac cannot get it?) appreciate your help, Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 3 bDelay 1 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength29 bDescriptorType36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 1 bSubframeSize 2 bBitResolution 16 bSamFreqType7 Discrete tSamFreq[ 0] 8000 tSamFreq[ 1]16000 tSamFreq[ 2]22050 tSamFreq[ 3]24000 tSamFreq[ 4]32000 tSamFreq[ 5]44100 tSamFreq[ 6]48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes5 Transfer TypeIsochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0100 1x 256 bytes bInterval 4 bRefresh0 bSynchAddress 0 AudioControl Endpoint Descriptor: bLength 7 bDescriptorType37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0 Undefined Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) 2014-09-12 13:46 GMT+08:00 vichy vichy@gmail.com: hi all: My kernel is 3.8.0. and when I plug in microsoft LifeCam, I get message at the end of mail about cannot get min/max values from camera. is there any usb audio class initial sequence we need to check when this message pop out? Appreciate your help in advance, usb 3-1: new high-speed USB device number 2 using Platform-ehci Platform-ehci Platform-ehci.0: port 1 reset complete, port enabled Platform-ehci Platform-ehci.0: GetStatus port:1 status 0d 0 ACK sig=se0 PEC PE CONNECT usb 3-1: skipped 1 descriptor after configuration usb 3-1: skipped 6 descriptors after interface usb 3-1: skipped 1 descriptor after endpoint usb 3-1: skipped 28 descriptors after interface usb 3-1: skipped 1 descriptor after endpoint usb 3-1: skipped 4 descriptors after interface usb 3-1: skipped 2 descriptors after interface usb 3-1: skipped 1 descriptor after endpoint usb 3-1: default language 0x0409 usb 3-1: udev 2, busnum 3, minor = 257 usb 3-1: New USB device found, idVendor=045e, idProduct=075d usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-1: Product: Microsoft® LifeCam Cinema(TM) usb 3-1: Manufacturer: Microsoft usb 3-1: usb_probe_device usb 3-1: configuration #1 chosen from 1 choice usb 3-1: adding 3-1:1.0 (config #1, interface 0) uvcvideo 3-1:1.0: usb_probe_interface uvcvideo 3-1:1.0: usb_probe_interface - got id uvcvideo: Found UVC 1.00 device Microsoft® LifeCam Cinema(TM) (045e:075d) input: Microsoft® LifeCam Cinema(TM) as /devices/platform/Platform-ehci.0/usb3/3-1/3-1:1.0/input/input4 usb 3-1: adding 3-1:1.1 (config #1, interface 1) usb 3-1: adding 3-1:1.2 (config #1, interface 2) snd-usb-audio 3-1:1.2: usb_probe_interface snd-usb-audio 3-1:1.2: usb_probe_interface - got id ALSA sound/usb/stream.c:682 2:3:1: add audio endpoint 0x82 usb 3-1: khubd timed out on ep0in len=0/3 ALSA sound/usb/clock.c:237 2:3:1: cannot get freq at ep 0x82 ALSA sound/usb/mixer.c:1305 [5] FU [Mic Capture Switch] ch = 1, val = 0/1/1 ALSA sound/usb/mixer.c:929 5:2: cannot get min/max
Re: usb sound cannot get frequency from enpoind
hi Clements: 2014-09-12 14:41 GMT+08:00 Clemens Ladisch clem...@ladisch.de: vichy wrote: ALSA sound/usb/clock.c:237 2:3:1: cannot get freq at ep 0x82 ALSA sound/usb/mixer.c:929 5:2: cannot get min/max values for control 2 (id 5) ALSA sound/usb/mixer.c:929 5:2: cannot get min/max values for control 2 (id 5) (from the description, the ep 0x82 did have different sample rate configuration, but why uac cannot get it?) This is likely to be a bug in the device's firmware. How could we determine it? is the any tool, log or experiments we can do to to show the bug belongs to device not uac? appreciate your kind help, -- 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
Re: Bind usb device to another class driver
hi alan: 2014-08-29 22:54 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Fri, 29 Aug 2014, vichy wrote: hi all: I have read the article below and try to do the same operation on my device. http://lwn.net/Articles/143397/ My environment: 1. my kernel is 3.16 2. device descriptor is attached. 3. below are my operation logs: # echo -n 4-2:1.0 /sys/bus/usb/drivers/uas/unbind # echo -n 4-2:1.0 /sys/bus/usb/drivers/usb-storage/unbind bash: echo: write error: No such device # Why do you want to bind your drive to usb-storage instead of uas? I read the article from the web but have no real test case to try on my pc until I found there are both usb-storage and uas interface on my external hard disk. My questions: 1. is there anything I need to do, such as PCI driver, before bind to usb-storage driver? Normally, if uas will bind to a device then usb-storage won't. You can change this by using a module paramter for usb-storage: modprobe usb-storage quirks=1759:5002:u (1759 and 5002 are the vendor and product IDs for this device.) Is there any interface priority written in driver to let uas instead of usb-storage bind the device? BTW, if we try not let uas bind the device, why don't we add the quirk in uas but usb-storage? What is the u at the end of command mean? 2. I can check whether the usb device is bound to specific driver through cat /sys/kernel/debug/usb/devices. is there any alternative way to do so? how about other drivers, except usb, to let user know whether the binding/unbinding successfully and which device is bound to which driver? ls -l /sys/bus/usb/devices/.../driver where you fill in the ... with the path for the interface you are interested in, such as 1-4:1.0. Alternatively, ls /sys/bus/usb/drivers/.../ where you fill in the ... with the name of the driver you are interested in. I found what you mentioned ^^ appreciate your help, -- 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
Re: Bind usb device to another class driver
hi Greg: 2014-08-30 2:31 GMT+08:00 Greg KH g...@kroah.com: On Fri, Aug 29, 2014 at 11:18:39AM +0800, vichy wrote: hi all: I have read the article below and try to do the same operation on my device. http://lwn.net/Articles/143397/ My environment: 1. my kernel is 3.16 2. device descriptor is attached. 3. below are my operation logs: # echo -n 4-2:1.0 /sys/bus/usb/drivers/uas/unbind # echo -n 4-2:1.0 /sys/bus/usb/drivers/usb-storage/unbind bash: echo: write error: No such device You unbound your device from two different drivers? Of course the second one doesn't work, it's not bound there :) sorry for my typo ^^ BTW, is bind/unbind a part of bus driver call backs, since I only find them in /sys/bus. If so, # pwd /sys # find ./ -name 'unbind' ./bus/cpu/drivers/processor/unbind ./bus/i2c/drivers/rc5t583/unbind ./bus/i2c/drivers/smsc/unbind ./bus/i2c/drivers/88PM860x/unbind ./bus/i2c/drivers/dummy/unbind .. appreciate all your kind help, -- 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
Bind usb device to another class driver
hi all: I have read the article below and try to do the same operation on my device. http://lwn.net/Articles/143397/ My environment: 1. my kernel is 3.16 2. device descriptor is attached. 3. below are my operation logs: # echo -n 4-2:1.0 /sys/bus/usb/drivers/uas/unbind # echo -n 4-2:1.0 /sys/bus/usb/drivers/usb-storage/unbind bash: echo: write error: No such device # My questions: 1. is there anything I need to do, such as PCI driver, before bind to usb-storage driver? 2. I can check whether the usb device is bound to specific driver through cat /sys/kernel/debug/usb/devices. is there any alternative way to do so? how about other drivers, except usb, to let user know whether the binding/unbinding successfully and which device is bound to which driver? thanks for your help in advance, usb_hd_desc.tar.bz2 Description: BZip2 compressed data
Re: [PATCH 1/1] HID: usbhid: add usb_clear_halt determination for next hid_start_in
hi Alan: usb_unbind_and_rebind_marked_interfaces is called if config parameter is not null, it seems no matter post_reset routine fail or not. Yes, that's right. I should have said: Because the post_reset routine failed, usb_unbind_and_rebind_marked_interfaces indirectly calls usbhid_disconnect. Even post_reset routine failed, usb_unbind_and_rebind_marked_interfaces will still indirectly calls usbhid_disconnect, right? I don't remember the entire call chain. It was pretty long. hid_destroy_device calls hid_remove_device, which calls device_del, which calls lots of other things. If you really want to see all the details, put a dump_stack() call in usbhid_close and examine what it prints in the kernel log when you unplug an HID device. I found what you mentioned ^^ Thanks for your kind help, -- 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
Re: [PATCH 1/1] HID: usbhid: add usb_clear_halt determination for next hid_start_in
hi Oliver: 2014-08-25 18:21 GMT+08:00 Oliver Neukum oneu...@suse.de: On Fri, 2014-08-22 at 14:23 -0400, Alan Stern wrote: On Sat, 23 Aug 2014, vichy wrote: from your patch, I have some questions: a. in Alan's version, if both HID_CLEAR_HALT and HID_RESET_PENDING are set, hid_reset will both clear ep halt and reset devcie. But in original one, even HID_CLEAR_HALT and HID_RESET_PENDING are both set, hid_reset only do one of them. Yes. In my patch, the clear-halt handler will turn on the HID_RESET_PENDING bit if something goes wrong. In that case we want to do both things. Why? If we reset, why bother clearing a halt? Especially as this may mean waiting the full 5 seconds for a timeout. I think what Alan mean is IF CLEAR HALT fail, we reset the device. That is what below In that case mean. In that case we want to do both things. BR, -- 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
Re: some question about unbind and rebind usb interfaces
hi Alan: After usb_reset_device, the whole enumeration will run again, No, only part of the enumeration. The kernel does read the device and config descriptors again. But if the reset succeeded, the kernel doesn't carry out any of the other parts of enumeration. here the kernel you mean above is usb HCD driver, right? the other parts of enumeration you mean is class driver, right? why this patch say the previous solution will be fail to claim additional interface? Suppose a driver claims interfaces 0 and 1, and then they have to be unbound and rebound. The old code would unbind interface 0, then rebind it, then unbind interface 1, and then rebind it. Suppose the driver's probe routine for interface 0 tries to claim interface 1? The probe routine runs when interface 0 is rebound. At Is there any class driver will try to claim both interface 0 and 1? As I remember correctly, the usb class driver is passively called with different interface class ID matched. that time interface 1 hasn't been unbound yet. Since interface 1 is still owned, the driver will not be able to claim it. On the other hand, the new code will unbind interface 0, then unbind interface 1, then rebind interface 0, and then rebind interface 1. Now if the driver's probe routine for interface 0 tries to claim interface 1, the claim will succeed because interface has already been unbound. appreciate your kind help, -- 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
some question about unbind and rebind usb interfaces
hi all: below patch introduce unbind and rebind interfaces during usb reset https://lists.ubuntu.com/archives/kernel-team/2014-April/042177.html If a driver claims additional interfaces, the claim may fail because the old binding instance may still own the additional interface when the new instance tries to claim it. After usb_reset_device, the whole enumeration will run again, why this patch say the previous solution will be fail to claim additional interface? thanks for your help in advance, -- 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
Re: [PATCH 1/1] HID: usbhid: add usb_clear_halt determination for next hid_start_in
hi Alan:
I originally tried using usb_reset_device, and it caused a deadlock:
Unplug the HID device.
I/O error occurs. hid_io_error schedules reset_work.
The reset_work callback routine is hid_reset. It calls
usb_reset_device.
The reset fails because the device is gone. At the end of the
reset, hid_post_reset is called.
hid_post_reset returns 1 because hid_get_class_descriptor
fails.
Because the post_reset routine failed, usb_reset_device calls
usb_unbind_and_rebind_marked_interfaces.
usb_unbind_and_rebind_marked_interfaces is called if config
parameter is not null,
it seems no matter post_reset routine fail or not.
That routine indirectly calls usbhid_disconnect.
Why that routine, usb_reset_device, will call usbhid_disconnect?
No matter port reset success or fail, usbhid_disconnect should not be
called except that did happen disconnection.
usbhid_disconnect calls usbhid_close by way of
hid_destroy_device.
below is the content of hid_destroy and hid_remove_device, but I
cannot find where usbhid_close be called by way of hid_destroy_device.
static void hid_remove_device(struct hid_device *hdev)
{
if (hdev-status HID_STAT_ADDED) {
device_del(hdev-dev);
hid_debug_unregister(hdev);
hdev-status = ~HID_STAT_ADDED;
}
kfree(hdev-dev_rdesc);
hdev-dev_rdesc = NULL;
hdev-dev_rsize = 0;
}
void hid_destroy_device(struct hid_device *hdev)
{
hid_remove_device(hdev);
put_device(hdev-dev);
}
usbhid_close calls hid_cancel_delayed_stuff.
hid_cancel_delayed_stuff calls cancel_work_sync for reset_work.
So the reset_work routine tries to cancel itself synchronously while it
is running. usb_queue_reset_device was carefully written to avoid such
deadlocks.
thanks for your help,
--
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
Re: [PATCH 1/1] HID: usbhid: add usb_clear_halt determination for next hid_start_in
hi Jiri: 2014-08-22 15:45 GMT+08:00 Jiri Kosina jkos...@suse.cz: On Fri, 22 Aug 2014, CheChun Kuo wrote: HID IR device will not response to any command send from host when it is finishing paring and tring to reset itself. During this period of time, usb_cleaer_halt will be fail and if hid_start_in soon again, we has the possibility trap in infinite loop. Signed-off-by: CheChun Kuo vichy@gmail.com --- drivers/hid/usbhid/hid-core.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c index 79cf503..256b102 100644 --- a/drivers/hid/usbhid/hid-core.c +++ b/drivers/hid/usbhid/hid-core.c @@ -122,7 +122,8 @@ static void hid_reset(struct work_struct *work) dev_dbg(usbhid-intf-dev, clear halt\n); rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid-urbin-pipe); clear_bit(HID_CLEAR_HALT, usbhid-iofl); - hid_start_in(hid); + if (rc == 0) + hid_start_in(hid); } I'd need a more detailed explanation for this patch, as I don't understand neither the text in the changelog nor the patch itself. Namely: - which IR devices are showing this behavior? The USB hid device that will transform IR signal to usb command when user press volume up/down, voice recording, etc. - where does the infinite loop come from? hid_reset() should error out properly if usb_clear_halt() fails and HID_IN_RUNNING flag is not set Below I briefly draw the timing when this issue happen i) hid_irq_in get URB status as -EPIPE ii) set HID_CLEAR_HALT flag and schedule hid_reset work iii) hid_reset call usb_clear_halt and hid_start_in again iv) if device still doesn't response host command, it will go to i) above and keep looping thanks for your help, -- 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
Re: [PATCH 1/1] HID: usbhid: add usb_clear_halt determination for next hid_start_in
hi alan and all:
I recently posted (but did not submit) a more comprehensive solution to
this and other related problems. For example, HID devices typically
run at low speed or full speed. When attached through a hub to an EHCI
controller (very common on modern systems), unplugging the device
causes -EPIPE errors, so the driver calls usb_clear_halt and restarts
the interrupt pipe. Of course, the same failure occurs again, so
there's a lengthy flurry of useless error messages.
This patch changes the driver so that after usb_clear_halt fails, it
will try to do a port reset. And if that fails, the driver will be
unbound from the device. This avoids infinite loops.
What do you think?
Alan Stern
Index: usb-3.16/drivers/hid/usbhid/hid-core.c
===
--- usb-3.16.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.16/drivers/hid/usbhid/hid-core.c
@@ -116,40 +116,24 @@ static void hid_reset(struct work_struct
struct usbhid_device *usbhid =
container_of(work, struct usbhid_device, reset_work);
struct hid_device *hid = usbhid-hid;
- int rc = 0;
+ int rc;
if (test_bit(HID_CLEAR_HALT, usbhid-iofl)) {
dev_dbg(usbhid-intf-dev, clear halt\n);
rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid-urbin-pipe);
clear_bit(HID_CLEAR_HALT, usbhid-iofl);
- hid_start_in(hid);
- }
-
- else if (test_bit(HID_RESET_PENDING, usbhid-iofl)) {
- dev_dbg(usbhid-intf-dev, resetting device\n);
- rc = usb_lock_device_for_reset(hid_to_usb_dev(hid),
usbhid-intf);
if (rc == 0) {
- rc = usb_reset_device(hid_to_usb_dev(hid));
- usb_unlock_device(hid_to_usb_dev(hid));
+ hid_start_in(hid);
+ } else {
+ dev_dbg(usbhid-intf-dev,
+ clear-halt failed: %d\n, rc);
+ set_bit(HID_RESET_PENDING, usbhid-iofl);
}
- clear_bit(HID_RESET_PENDING, usbhid-iofl);
}
- switch (rc) {
- case 0:
- if (!test_bit(HID_IN_RUNNING, usbhid-iofl))
- hid_io_error(hid);
- break;
- default:
- hid_err(hid, can't reset device, %s-%s/input%d, status %d\n,
- hid_to_usb_dev(hid)-bus-bus_name,
- hid_to_usb_dev(hid)-devpath,
- usbhid-ifnum, rc);
- /* FALLTHROUGH */
- case -EHOSTUNREACH:
- case -ENODEV:
- case -EINTR:
- break;
+ if (test_bit(HID_RESET_PENDING, usbhid-iofl)) {
+ dev_dbg(usbhid-intf-dev, resetting device\n);
+ usb_queue_reset_device(usbhid-intf);
}
}
from your patch, I have some questions:
a. in Alan's version, if both HID_CLEAR_HALT and HID_RESET_PENDING are
set, hid_reset will both clear ep halt and reset devcie.
But in original one, even HID_CLEAR_HALT and HID_RESET_PENDING are
both set, hid_reset only do one of them.
is there any special reason in original hid_reset to use below flow?
if (test_bit(HID_CLEAR_HALT, usbhid-iofl)) {
x
} else if (test_bit(HID_RESET_PENDING, usbhid-iofl)) {
xx
}
b. in original hid_reset, if Clear halt ep or Rest device success
or none of those flags raise up, it will call hid_io_error for later
resending the urb. Shall we need to call hid_io_error(hid); in the
end if clear halt or reset device success?
c. why we chose to use usb_queue_reset_device instead of usb_reset_device()?
d. shall we useusb_lock_device_for_reset(hid_to_usb_dev(hid),
usbhid-intf) or spin_lock_irq(usbhid-lock) before calling
usb_queue_reset_device?
I append patch for explaining my questions.
Appreciate your kind help,
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 256b102..aa321f9 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -116,18 +116,22 @@ static void hid_reset(struct work_struct *work)
struct usbhid_device *usbhid =
container_of(work, struct usbhid_device, reset_work);
struct hid_device *hid = usbhid-hid;
- int rc = 0;
+ int rc;
if (test_bit(HID_CLEAR_HALT, usbhid-iofl)) {
dev_dbg(usbhid-intf-dev, clear halt\n);
rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid-urbin-pipe);
clear_bit(HID_CLEAR_HALT, usbhid-iofl);
- if (rc == 0)
+ if (rc == 0) {
hid_start_in(hid);
+ } else {
+ dev_dbg(usbhid-intf-dev,
+ clear-halt failed: %d\n, rc);
+ set_bit(HID_RESET_PENDING, usbhid-iofl);
+
Re: Iso trbs for xhci arrangement
hi Paul My questions are 1. The xhci controller seems not handle the normal TRB for short package. as you can see the length of event package for normal package is 0. am I correct? 2. if above #1 is correct, how xhci controller get the left 0x6f8 data in original normal package? This looks like a hardware bug to me. Which xHCI controller is this? Synopsys Ouch ;) the controller did fire iso in token to get 0x4fc bytes, above marked , and if xhci controller didn't firing the left in tokens to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not continuous, right? I would bet that no data was transferred at all, but the controller forgot to set the transfer length correctly for the chained normal TRB. so you mean the ISO will be sent but the chained normal TRB won't. that mean the host only get 0x4fc instead of total 0xbf4 Bytes. Am I right? No, I'm thinking that no data at all was received. That is what the Isoc event TRB shows. But from isoc event TRB it shows there did get 0x4fc bytes from device, since the data length of event trb is not 0. Are you seeing an actual problem with this? If not, maybe the xHCI driver is written in such a way that this does not cause a problem. I found this problem because when I activate ISO for my webcam, I get below message ERROR Transfer event TRB DMA ptr not part of current TD Yes, but does the webcam work? Without the patch that you mentioned below, you will get these messages, but they shouldn't cause any functional problem. we will try to eliminate the message and check whether webcam is ok. Also, which webcam is this? Maybe I can try to reproduce the problem here. And normal uvc webcam will have this issue.(But you have to purposely disable XHCI_SPURIOUS_SUCCESS) Which version of the kernel are you using? Please try this with the latest version (3.16-rc5) to make sure this is not some problem that has already been fixed. the version I use is 3.8.2. I will try to merge 3.16-rc5 into our system. after tracing the src and checking the event TRB, I found the TRB pointer in event TRB is pointing to the chained normal TRB. And length of Event TRB is 0 but complete code is success. 3. is there any relationship between below patch https://lkml.org/lkml/2013/6/26/501 I doubt it. appreciate your help, Endpoint 02 Context: xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] ep ring xhci.0: @2796e110 279ccb34 0bf4 80021625 xhci.0: @2796e120 279cd728 0bf4 80021625 xhci.0: @2796e130 279ce31c 0bf4 80021625 xhci.0: @2796e140 279cef10 0bf4 80021625 xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 event ring: xhci.0: @278d1700 2796e140 0d000bf4 01038001 xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal xhci.0: @278d1730 2796e170 0d000bf4 01038001 xhci.0: @278d1740 2796e180 0d000bf4 01038001 Are these the entire rings, or did you just show a part of them? Sure. I attach both event ring and ep ring at the end of mail. Because all the TRBs have the cycle bit set, which shouldn't happen AFAIK. Thanks for your kind help, Thanks, I will look at the ring data and see if I see anything suspicious. -- Paul event ring segment: platform-xhci.0: @278d1400 2796e240 0d000bf4 01038000 platform-xhci.0: @278d1410 2796e250 0d000bf4 01038000 platform-xhci.0: @278d1420 2796e260 0d000bf4 01038000 platform-xhci.0: @278d1430 2796e270 0d000bf4 01038000 platform-xhci.0: @278d1440 2796e280 0d000bf4 01038000 platform-xhci.0: @278d1450 2796e290 0d000bf4 01038000 platform-xhci.0: @278d1460 2796e2a0 0d000bf4 01038000 platform-xhci.0: @278d1470 2796e2b0 0d000bf4 01038000 platform-xhci.0: @278d1480 2796e2c0 0d000bf4 01038000 platform-xhci.0: @278d1490 2796e2d0 0d000bf4 01038000 platform-xhci.0: @278d14a0 2796e2e0 0d000bf4 01038000 platform-xhci.0: @278d14b0 2796e2f0 0d000bf4 01038000 platform-xhci.0: @278d14c0 2796e300 0d000bf4 01038000 platform-xhci.0: @278d14d0 2796e310 0d000bf4
Re: Iso trbs for xhci arrangement
hi Paul: Driver prepare ep ring like below xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 but event ring get below result xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal My questions are 1. The xhci controller seems not handle the normal TRB for short package. as you can see the length of event package for normal package is 0. am I correct? 2. if above #1 is correct, how xhci controller get the left 0x6f8 data in original normal package? This looks like a hardware bug to me. Which xHCI controller is this? Synopsys the controller did fire iso in token to get 0x4fc bytes, above marked , and if xhci controller didn't firing the left in tokens to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not continuous, right? I would bet that no data was transferred at all, but the controller forgot to set the transfer length correctly for the chained normal TRB. so you mean the ISO will be sent but the chained normal TRB won't. that mean the host only get 0x4fc instead of total 0xbf4 Bytes. Am I right? Are you seeing an actual problem with this? If not, maybe the xHCI driver is written in such a way that this does not cause a problem. I found this problem because when I activate ISO for my webcam, I get below message ERROR Transfer event TRB DMA ptr not part of current TD after tracing the src and checking the event TRB, I found the TRB pointer in event TRB is pointing to the chained normal TRB. And length of Event TRB is 0 but complete code is success. 3. is there any relationship between below patch https://lkml.org/lkml/2013/6/26/501 I doubt it. appreciate your help, Endpoint 02 Context: xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] ep ring xhci.0: @2796e110 279ccb34 0bf4 80021625 xhci.0: @2796e120 279cd728 0bf4 80021625 xhci.0: @2796e130 279ce31c 0bf4 80021625 xhci.0: @2796e140 279cef10 0bf4 80021625 xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 event ring: xhci.0: @278d1700 2796e140 0d000bf4 01038001 xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal xhci.0: @278d1730 2796e170 0d000bf4 01038001 xhci.0: @278d1740 2796e180 0d000bf4 01038001 Are these the entire rings, or did you just show a part of them? Sure. I attach both event ring and ep ring at the end of mail. Because all the TRBs have the cycle bit set, which shouldn't happen AFAIK. Thanks for your kind help, event ring segment: platform-xhci.0: @278d1400 2796e240 0d000bf4 01038000 platform-xhci.0: @278d1410 2796e250 0d000bf4 01038000 platform-xhci.0: @278d1420 2796e260 0d000bf4 01038000 platform-xhci.0: @278d1430 2796e270 0d000bf4 01038000 platform-xhci.0: @278d1440 2796e280 0d000bf4 01038000 platform-xhci.0: @278d1450 2796e290 0d000bf4 01038000 platform-xhci.0: @278d1460 2796e2a0 0d000bf4 01038000 platform-xhci.0: @278d1470 2796e2b0 0d000bf4 01038000 platform-xhci.0: @278d1480 2796e2c0 0d000bf4 01038000 platform-xhci.0: @278d1490 2796e2d0 0d000bf4 01038000 platform-xhci.0: @278d14a0 2796e2e0 0d000bf4 01038000 platform-xhci.0: @278d14b0 2796e2f0 0d000bf4 01038000 platform-xhci.0: @278d14c0 2796e300 0d000bf4 01038000 platform-xhci.0: @278d14d0 2796e310 0d000bf4 01038000 platform-xhci.0: @278d14e0 2796e320 0d000bf4 01038000 platform-xhci.0: @278d14f0 2796e330 0d000bf4 01038000 platform-xhci.0: @278d1500 2796e340 0d000bf4 01038000 platform-xhci.0: @278d1510 2796e350 0d000bf4 01038000 platform-xhci.0: @278d1520 2796e360 0d0004fc 01038000 platform-xhci.0: @278d1530 2796e370 0100 01038000 platform-xhci.0: @278d1540 2796e380 0d000bf4 01038000 platform-xhci.0: @278d1550
Re: Iso trbs for xhci arrangement
hi Paul: Please read section 3.2.11 in the xHCI spec, which is freely available on the web. I found what you mean. I dump ep context, ep ring and event ring for handling short package. Driver prepare ep ring like below xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 but event ring get below result xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal My questions are 1. The xhci controller seems not handle the normal TRB for short package. as you can see the length of event package for normal package is 0. am I correct? 2. if above #1 is correct, how xhci controller get the left 0x6f8 data in original normal package? the controller did fire iso in token to get 0x4fc bytes, above marked , and if xhci controller didn't firing the left in tokens to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not continuous, right? 3. is there any relationship between below patch https://lkml.org/lkml/2013/6/26/501 appreciate your help, Endpoint 02 Context: xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] ep ring xhci.0: @2796e110 279ccb34 0bf4 80021625 xhci.0: @2796e120 279cd728 0bf4 80021625 xhci.0: @2796e130 279ce31c 0bf4 80021625 xhci.0: @2796e140 279cef10 0bf4 80021625 xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 event ring: xhci.0: @278d1700 2796e140 0d000bf4 01038001 xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal xhci.0: @278d1730 2796e170 0d000bf4 01038001 xhci.0: @278d1740 2796e180 0d000bf4 01038001 -- 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
Iso trbs for xhci arrangement
hi all: when I trace xhci_queue_isoc_tx, I found ISO TD should look like ISO TRB -- Normal TRB -- Normal TRB But when I dump ep segment during Iso transfer I get below result 1. Why most of them are ISO TRBs? 2. Why there is only 1 normal TRB appreciate your help in advance, ep ring segment: platform-xhci platform-xhci.0: @2796e000 279c 0bf4 80021625 platform-xhci platform-xhci.0: @2796e010 279c0bf4 0bf4 80021625 platform-xhci platform-xhci.0: @2796e020 279c17e8 0bf4 80021625 platform-xhci platform-xhci.0: @2796e030 279c23dc 0bf4 80021625 platform-xhci platform-xhci.0: @2796e040 279c2fd0 0bf4 80021625 platform-xhci platform-xhci.0: @2796e050 279c3bc4 0bf4 80021625 platform-xhci platform-xhci.0: @2796e060 279c47b8 0bf4 80021625 platform-xhci platform-xhci.0: @2796e070 279c53ac 0bf4 80021625 platform-xhci platform-xhci.0: @2796e080 279c5fa0 0bf4 80021625 platform-xhci platform-xhci.0: @2796e090 279c6b94 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0a0 279c7788 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0b0 279c837c 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0c0 279c8f70 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0d0 279c9b64 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0e0 279ca758 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0f0 279cb34c 0bf4 80021625 platform-xhci platform-xhci.0: @2796e100 279cbf40 0bf4 80021625 platform-xhci platform-xhci.0: @2796e110 279ccb34 0bf4 80021625 platform-xhci platform-xhci.0: @2796e120 279cd728 0bf4 80021625 platform-xhci platform-xhci.0: @2796e130 279ce31c 0bf4 80021625 platform-xhci platform-xhci.0: @2796e140 279cef10 0bf4 80021625 //ISO TRB platform-xhci platform-xhci.0: @2796e150 279cfb04 000404fc 80021415 //ISO TRB platform-xhci platform-xhci.0: @2796e160 279d 06f8 0625 //Normal TRB platform-xhci platform-xhci.0: @2796e170 279d06f8 0bf4 80021625 platform-xhci platform-xhci.0: @2796e180 279d12ec 0bf4 80021625 platform-xhci platform-xhci.0: @2796e190 279d1ee0 0bf4 80021625 -- 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
Re: xhci handling ring expansion
hi David: 2014-06-18 22:33 GMT+08:00 David Laight david.lai...@aculab.com: From: vichy ... and I get error message as platform-xhci: ERROR Transfer event TRB DMA ptr 483702160 not part of current TD platform-xhci: trb_comp_code = 0x1, event status -115, buffer 1cd4b590, len 100, flags 1038001 that seems wired. complete code is success and not short package. Why we still get TRB DMA will not be part of current TD? I would trace all the setup requests and responses and then work out what is expected and then missing. i purposely print the dma of 4 parameters when we pass to trb_in_td like below. I found something wired: 1. when problem happen, the ep_dequeue_trb_dma is increase 0x20 instead of 0x10. But I trace the source, I cannot find the place where we inc_deq twice when handling iso trbs. (ep_dequeue_trb_dma=0x2796e150 == ep_dequeue_trb_dma=0x2796e170 ) ep_dequeue_trb_dma=0x2796e130, end_seg_dma = 0x2796e3f0, suspect_dma= 0x2796e130, end_trb_dma = 0x2796e130 ep_dequeue_trb_dma=0x2796e140, end_seg_dma = 0x2796e3f0, suspect_dma= 0x2796e140, end_trb_dma = 0x2796e140 ep_dequeue_trb_dma=0x2796e150, end_seg_dma = 0x2796e3f0, suspect_dma= 0x2796e150, end_trb_dma = 0x2796e160 ep_dequeue_trb_dma=0x2796e170, end_seg_dma = 0x2796e3f0, suspect_dma= 0x2796e160, end_trb_dma = 0x2796e170 Platform-xhci: event status -115, buffer 2796e160, Dma 2796e160, len 100, flags 1038001 Platform-xhci: ERROR Transfer event TRB DMA ptr 664199520 not part of current TD Platform-xhci: ERROR Transfer evenourt TRB DMA ptr not part of current TD appreciate your help, -- 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
Re: some question about xhci skip_isoc_td
hi Mathias:
2014-06-24 16:38 GMT+08:00 Mathias Nyman mathias.ny...@linux.intel.com:
On 06/23/2014 03:44 PM, David Laight wrote:
From: vichy
hi all:
when i trace xhci source, I found in skip_isoc_td, there is a
possibility to increase de-queue pointer twice.
in skip_isoc_td:
/* Update ring dequeue pointer */
while (ep_ring-dequeue != td-last_trb)
inc_deq(xhci, ep_ring);
inc_deq(xhci, ep_ring);
why (ep_ring-dequeue != td-last_trb) we have to increase the dequeue
pointer?
I try to find any description in spec about this but in vain.
is there any special reason to do so?
An isoc transfer can consist of a lot of TRB.
The code wants to skip all of them.
I suspect there are faster ways to achieve the same effect!
As David says, the inc_dec() in the while loop will move the dequeue pointer
to the last TRB of that TD.
The additional inc_deq() then moves it to the next TD, (or to enqueue if no
more TDs are on the endpoint ring)
section 4.10.1 in xhci specification has some info on this:
If a Missed Service Error occurs on
did Missed Service Error occurs you mean is when we cannot find
match ep_dequeue_seg which contain event_buffer?
like the below code in handle_tx_event:
if (!event_seg) {
...
}
an intermediate TRB of a TD of an Isoch endpoint the xHC shall advance to the
first TRB of the next TD or
the Enqueue Pointer (i.e.Cycle bit transition), whichever is encountered
first, when continuing execution on
the Transfer Ring.
appreciate your help,
--
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
some question about xhci skip_isoc_td
hi all: when i trace xhci source, I found in skip_isoc_td, there is a possibility to increase de-queue pointer twice. in skip_isoc_td: /* Update ring dequeue pointer */ while (ep_ring-dequeue != td-last_trb) inc_deq(xhci, ep_ring); inc_deq(xhci, ep_ring); why (ep_ring-dequeue != td-last_trb) we have to increase the dequeue pointer? I try to find any description in spec about this but in vain. is there any special reason to do so? appreciate your kind help, -- 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
Re: xhci handling ring expansion
hi David:
2014-06-18 16:45 GMT+08:00 David Laight david.lai...@aculab.com:
From: vichy
hi david:
...
From one of the patches (not applied) I sent last November ...
Include the unknown address when the DMA pointer from an event isn't part
of the current TD. This will happen if the error code is TRB error.
do you mean below patch?
http://markmail.org/message/74qvwz7fhjxqeih3
it only add debug message instead of fixing it.
appreciate your help,
In my case there was a coding error in one of the other xhci
patches that caused a 'TRB error' report.
The patch to change the tracing was an attempt to make things
less confusing.
If you modify the tracing you might find out where the pointer from
the event came from.
I modify your patch like below
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7f76a49..17d5ad0 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2456,6 +2456,11 @@ static int handle_tx_event(struct xhci_hcd *xhci,
goto cleanup;
}
+ if (status status != -EINPROGRESS)
+ xhci_dbg(xhci, event status %d, buffer %llx,
len %x, flags %x\n,
+ status,
event-buffer, event-transfer_len,
+ event-flags);
+
do {
/* This TRB should be in the TD at the head of this ring's
* TD list.
@@ -2522,9 +2527,10 @@ static int handle_tx_event(struct xhci_hcd *xhci,
goto cleanup;
}
/* HC is busted, give up! */
- xhci_err(xhci,
- ERROR Transfer event TRB DMA ptr not
- part of current TD\n);
+ xhci_err(xhci, ERROR Transfer event
TRB DMA ptr %lld not part of current TD\n,event-buffer);
+ xhci_err(xhci, trb_comp_code = 0x%x,
event status %d, buffer %llx, len %x, flags %x\n,trb_comp_code,
+
status, event-buffer, event-transfer_len,
+ event-flags);
return -ESHUTDOWN;
}
and I get error message as
platform-xhci: ERROR Transfer event TRB DMA ptr 483702160 not part of current TD
platform-xhci: trb_comp_code = 0x1, event status -115, buffer
1cd4b590, len 100, flags 1038001
that seems wired.
complete code is success and not short package.
Why we still get TRB DMA will not be part of current TD?
appreciate your help,
--
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
xhci handling ring expansion
hi all: I use kernel 3.8.0 And when I plug in webcam in my platform xhci host, I get below message: platform-xhci platform-xhci.0: ERROR no room on ep ring, try ring expansion platform-xhci platform-xhci.0: ring expansion succeed, now has 4 segments platform-xhci platform-xhci.0: ERROR Transfer event TRB DMA ptr not part of current TD under what circumstance the controller will return TRB DMA which is not part of TD? Is it possible to workaround this issue by modifying xhci-mem.c for extending segments? appreciate your help in advance, -- 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
Re: xhci handling ring expansion
hi Greg: 2014-06-17 22:25 GMT+08:00 Greg KH gre...@linuxfoundation.org: On Tue, Jun 17, 2014 at 10:07:38PM +0800, vichy wrote: hi all: I use kernel 3.8.0 That's a very old, and unsupported kernel version. I suggest you update Yes. it is pretty old kernel. But i have git diff the xhci-mem.c there is no log about Transfer event TRB DMA ptr not part of current TD I have no idea whether it is hardware issue. I just want to know any one bump the same problem before? appreciate your help, -- 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
Re: xhci handling ring expansion
hi david: platform-xhci platform-xhci.0: ERROR no room on ep ring, try ring expansion platform-xhci platform-xhci.0: ring expansion succeed, now has 4 segments platform-xhci platform-xhci.0: ERROR Transfer event TRB DMA ptr not part of current TD under what circumstance the controller will return TRB DMA which is not part of TD? When the event TRB contains a pointer to something other than a data buffer. after tracing the xhci driver, the message shows up because transfer event TRB DMA is not located in current TD. This is true for one of the error events. Not that they should happen either. do you mean this is one of error event trb we will get? But I cannot find the error trb type in spec. or it means something wrong in hardware? Appreciate your help, -- 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
Re: xhci handling ring expansion
hi david: 2014-06-17 23:50 GMT+08:00 David Laight david.lai...@aculab.com: From: vichy hi david: platform-xhci platform-xhci.0: ERROR no room on ep ring, try ring expansion platform-xhci platform-xhci.0: ring expansion succeed, now has 4 segments platform-xhci platform-xhci.0: ERROR Transfer event TRB DMA ptr not part of current TD under what circumstance the controller will return TRB DMA which is not part of TD? When the event TRB contains a pointer to something other than a data buffer. after tracing the xhci driver, the message shows up because transfer event TRB DMA is not located in current TD. This is true for one of the error events. Not that they should happen either. do you mean this is one of error event trb we will get? But I cannot find the error trb type in spec. or it means something wrong in hardware? From one of the patches (not applied) I sent last November ... Include the unknown address when the DMA pointer from an event isn't part of the current TD. This will happen if the error code is TRB error. do you mean below patch? http://markmail.org/message/74qvwz7fhjxqeih3 it only add debug message instead of fixing it. appreciate your help, -- 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
Re: [PATCH 1/1] usb: add xhci warm reset if get device descripor return error
hi Greg:
2014-05-31 0:02 GMT+08:00 Greg KH gre...@linuxfoundation.org:
On Fri, May 30, 2014 at 11:28:36PM +0800, che-chun Kuo wrote:
We found when we plug in/out usb3.0 device for stress testing, once
usb_get_device_descriptor fail in hub_port_init, we will call
hub_port_disable.
Then usb3.0 device may not recover successfully with only hot reset like
below function
retval = hub_port_reset(hub, port1, udev, delay, false);
For covering this error handling, we add warm reset if getting device
descriptor fail on usb3.0 devices.
Odd linewrapping :(
since I try to make the explanation more readable, I purposely add
more blank like.
sorry for making you confused. ^^
Anyway, what makes USB 3 devices so special here that they need a
reset vs. all other devices?
in the beginning, I try to add quirk determination in usb driver.
But get descriptor is the 1st command we get.
if getting descriptor fail, I have no idea how to add quirk
determination in usb driver.
Are you sure your device isn't just broken somehow?
Yes, your concern is reasonable.
for accelerating the issue happen, I purposely create diff at the end of mail.
And I try 5 devices on my hand, 2 of them will not successfully return
back with only hot reset.
In usb3.0 spec, warm reset will force usb3.0 jump to Rx.detect.
But hot reset will direct down stream port from to ss.Disabled only
only if time out happen.
That is why I add warm reset when get device descriptor fail.
appreciate your help,
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
old mode 100644
new mode 100755
index f829a1a..ffc5241
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -18,6 +18,9 @@
#include usb.h
+static int try_flag = 0;
+module_param(try_flag, int, S_IRUGO|S_IWUSR);
+
static void cancel_async_set_config(struct usb_device *udev);
struct api_context {
@@ -912,6 +915,12 @@ int usb_get_device_descriptor(struct usb_device
*dev, unsigned int size)
if (!desc)
return -ENOMEM;
+
+ if ((try_flag = 3) (dev-speed == USB_SPEED_SUPER)
(dev-state == USB_STATE_ADDRESS) (dev-devpath[0] != '0')){
+ printk(KERN_ERRpurposely let get device descriptor fail\n);
+ try_flag ++;
+ return -2;
+ }
ret = usb_get_descriptor(dev, USB_DT_DEVICE, 0, desc, size);
if (ret = 0)
memcpy(dev-descriptor, desc, size);
--
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
Re: debug info for scheduling
hi all: Sorry for not making my description more clearer. in ehci controller, 1. is it possible to know the period bandwidth in a frame from sys or other additional configuration? 2. is it possible to know how many bits in SMASK and CMASK are assigned to 1 in a frame? thanks for your help in advance, -- 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
Re: debug info for scheduling
hi Alan: 2014-05-23 22:34 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Fri, 23 May 2014, vichy wrote: hi all: Sorry for not making my description more clearer. in ehci controller, 1. is it possible to know the period bandwidth in a frame from sys or other additional configuration? The information is available in debugfs, in /sys/kernel/debug/usb/ehci/.../bandwidth. 2. is it possible to know how many bits in SMASK and CMASK are assigned to 1 in a frame? Do you mean how bits in SMASK and CMASK are set to 1 in a QH or sITD? YES The SMASK and CMASK values are provided in /sys/kernel/debug/usb/ehci/.../periodic. Below is the directory content under /sys/kernel/debug/usb And I cannot see ehci directory. My kernel version is Linux 2.6.38-8-generic. Should I recompile kernel with additional configuration? # ls /sys/kernel/debug/usb/ devices usbmon # appreciate your kind help -- 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
some question about usb_interrupt_msg
hi all: I see usb_interrupt_msg do nothing but call usb_bulk_msg. Why we still keep usb_interrupt_msg? for old api compatibility? thanks for your help in advance, -- 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
Re: some question about usb_interrupt_msg
hi Alan: 2014-05-22 22:14 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Thu, 22 May 2014, vichy wrote: hi all: I see usb_interrupt_msg do nothing but call usb_bulk_msg. Why we still keep usb_interrupt_msg? for old api compatibility? That's right. Also because it gives an indication to the reader about what type of transfer is being performed. I got it. appreciate your kind reply ^^ -- 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
debug info for scheduling
hi all: I have some questions: 1. is it possible to know period bandwidth for ehci controller from sys or other additional configuration? 2. is it possible to know S/C bit in QHs which are linked in a frame? thanks for your help in advance, -- 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
Re: about possible port reset when disconnect
hi Alan:
2014-04-09 6:58 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Tue, 8 Apr 2014, vichy wrote:
That's a different bit. USB_PORT_FEAT_C_RESET isn't the same as
USB_PORT_FEAT_RESET.
what I am curious is,
if port reset bit will clear to 0 within 2ms, why we still need to
clear_port_feature with USB_PORT_FEAT_C_RESET
(clear Port reset )
if (hub_is_superspeed(hub-hdev)) {
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_BH_PORT_RESET);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
}
Because if we leave these bits set, the hub will send messages on its
interrupt endpoint telling us that these bits need to be cleared.
I got what makes me confused.
The USB_PORT_FEAT_C_RESET only work for non-root hub.
appreciate your kind help,
--
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
error handing for usb3.0 devices
hi all:
When I plug in usb3.0 device for stressing test, once
usb_get_device_descriptor fail in hub_port_init.
we will call hub_port_disable(hub, port1, 0);
And usb3.0 device may not recover successfully only with below function
retval = hub_port_reset(hub, port1, udev, delay, false);
when we try to save back the device.
in hub_port_connect_change
-- for (i = 0; i SET_CONFIG_TRIES; i++) {
-- hub_port_init
-- hub_port_reset(hub, port1, udev, delay, false);
-- usb_get_device_descriptor
(fail) -- hub_port_disable(hub, port1, 0);
( I list rough function calls flow like above)
For covering this error handling, shall we add patch like below?
diff --git drivers/usb/core/hub.c b/linux-3.8.2/drivers/usb/core/hub.c
index 64af693..599de96 100644
--- a/linux-3.8.2/drivers/usb/core/hub.c
+++ b/linux-3.8.2/drivers/usb/core/hub.c
@@ -4451,6 +4453,10 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
if (retval) {
hub_port_disable(hub, port1, 0);
update_devnum(udev, devnum);/* for disconnect processing */
+ if(udev-speed == USB_SPEED_SUPER)
+ hub_port_reset(hub, port1, udev,
+ HUB_BH_RESET_TIME, true);
}
mutex_unlock(usb_address0_mutex);
return retval;
Thanks for your kind help in advance,
--
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
what HCD_FLAG_POLL_RH used for
hi all: When I grep HCD_FLAG_POLL_RH, I ave some questions: 1. why this flag only seems used by xhci, uhci, ohci except ehci? 2. it seems to setup when pcd happen and need to poll port status. And clear it when hcd_died, hcd_remove, hcd_suspend and no port change in hub_status_data 3. if we once set this flag up, we may need to test it when we needed. But why there is no test bit case in usb driver? appreciate your kind help in advance, PS:Below is my grep results: # grep -rwn 'HCD_FLAG_POLL_RH' drivers/usb/* drivers/usb/c67x00/c67x00-hcd.c:284:set_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/core/hcd.c:2386:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/core/hcd.c:2396:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/core/hcd.c:2749:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/core/hcd.c:2753:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/core/hcd.c:2826:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/core/hcd.c:2833:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/xhci-hub.c:1088:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/uhci-hcd.c:144:clear_bit(HCD_FLAG_POLL_RH, uhci_to_hcd(uhci)-flags); drivers/usb/host/uhci-hcd.c:375:set_bit(HCD_FLAG_POLL_RH, uhci_to_hcd(uhci)-flags); drivers/usb/host/uhci-hcd.c:377:clear_bit(HCD_FLAG_POLL_RH, uhci_to_hcd(uhci)-flags); drivers/usb/host/uhci-hcd.c:395:set_bit(HCD_FLAG_POLL_RH, uhci_to_hcd(uhci)-flags); drivers/usb/host/uhci-pci.c:183:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/uhci-pci.c:243:set_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/hwa-hc.c:161:set_bit(HCD_FLAG_POLL_RH, usb_hcd-flags); drivers/usb/host/xhci.c:868:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/xhci.c:1068:set_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/ohci-hub.c:497:set_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/ohci-hub.c:499:clear_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/xhci-ring.c:1873:set_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/ohci-hcd.c:693:set_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/ohci-hcd.c:857:set_bit(HCD_FLAG_POLL_RH, hcd-flags); drivers/usb/host/whci/hcd.c:72:set_bit(HCD_FLAG_POLL_RH, usb_hcd-flags); -- 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
Re: error handing for usb3.0 devices
hi Greg:
Allways run your patches through checkpatch.pl so someone doesn't point
out the formatting issues in it when you send it to the mailing list :)
Here it is
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 090469e..2192776 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4316,6 +4316,9 @@ fail:
if (retval) {
hub_port_disable(hub, port1, 0);
update_devnum(udev, devnum);/* for disconnect processing */
+ if(udev-speed == USB_SPEED_SUPER)
+ hub_port_reset(hub, port1, udev,
+ HUB_BH_RESET_TIME, true);
}
mutex_unlock(usb_address0_mutex);
return retval;
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 090469e..2192776 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4316,6 +4316,9 @@ fail:
if (retval) {
hub_port_disable(hub, port1, 0);
update_devnum(udev, devnum); /* for disconnect processing */
+ if(udev-speed == USB_SPEED_SUPER)
+ hub_port_reset(hub, port1, udev,
+HUB_BH_RESET_TIME, true);
}
mutex_unlock(usb_address0_mutex);
return retval;
Re: error handing for usb3.0 devices
hi Greg and Sergei:
Well, I didn't want to complain about the example patch but now I'll just
have to... :-)
Here it is
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 090469e..2192776 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4316,6 +4316,9 @@ fail:
if (retval) {
hub_port_disable(hub, port1, 0);
update_devnum(udev, devnum);/* for disconnect
processing */
+ if(udev-speed == USB_SPEED_SUPER)
If you'd really run the patch thru checkpatch.pl, it would have
complained about missing space after *if*. ;-)
+ hub_port_reset(hub, port1, udev,
+ HUB_BH_RESET_TIME, true);
Apologizing for making you inconvenient. ^^
After reading the newbie document, I recreate it.
# ./scripts/checkpatch.pl
./0001-When-plugging-in-usb3.0-device-once-get-descriptor-o.patch
total: 0 errors, 0 warnings, 9 lines checked
./0001-When-plugging-in-usb3.0-device-once-get-descriptor-o.patch has
no obvious style problems and is ready for submission.
#
From 6915f0c8be03a79df3ee8ea5aeba2d223d822e18 Mon Sep 17 00:00:00 2001
From: vichy Kuo vichy@gmail.com
Date: Mon, 14 Apr 2014 10:03:15 +0800
Subject: [PATCH] When plugging in usb3.0 device, once get descriptor or set
address fail in hub_port_init. We will call hub_port_disabe
and usb3.0 device may not recover successfully only with
not warm reset. So we add belwo warm reset when there is
any error happen in hub_port_init.
Signed-off-by: vichy Kuo vichy@gmail.com
---
drivers/usb/core/hub.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 090469e..0c3ca34 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4316,6 +4316,9 @@ fail:
if (retval) {
hub_port_disable(hub, port1, 0);
update_devnum(udev, devnum); /* for disconnect processing */
+ if (udev-speed == USB_SPEED_SUPER)
+ hub_port_reset(hub, port1, udev,
+HUB_BH_RESET_TIME, true);
}
mutex_unlock(usb_address0_mutex);
return retval;
--
1.7.9.5
Re: about possible port reset when disconnect
hi Alan:
2014-04-07 10:06 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Sun, 6 Apr 2014, vichy wrote:
hi alan:
Why you think it is a bug in hardware?
The timeout error means that the kernel told the controller to turn off
the PORT_RESET bit, and 1000 us later the bit was still on. That's a
hardware bug.
after checking my hardware I found if device is no connected and do
the port reset,
the reset bit always will be 1 (I purposely add port status check in
set port reset case like below)
Platform-ehci Platform-ehci.0: port 1 reset
Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus
port:1 status 000100 0 ACK sig=se0 RESET
Yep. That's a hardware bug.
from ehci spec, there did not mention what will HW to do if port reset
happens on no connection.
it only explain what controller needs to do when device is connected.
Nonsense. The EHCI spec says this (in Table 2-16, the description
for bit 8):
... Software writes a zero to this bit to terminate
the bus reset sequence...
... Note that when software writes a zero to this bit there
may be a delay before the bit status changes to a zero. The bit
status will not read as a zero until after the reset has
completed... A host controller must terminate the reset and
stabilize the state of the port within 2 milliseconds of
software transitioning this bit from a one to a zero.
Thus, the bit is supposed to change to 0 after no more than 2 ms,
whether a device is connected or not.
I got it.
At first glance of this part of spec, I only focus this behaviour when
device is connected.
^^
if related reset bit will automatically cleared for a while when
device is not connected.
Why we still need to clear them in hub_port_finish_reset like below flow
in hub_port_reset,
/* Check for disconnect or reset */
if (status == 0 || status == -ENOTCONN || status == -ENODEV) {
hub_port_finish_reset(hub, port1, udev, status);
then in hub_port_finish_reset
case -ENOTCONN:
case -ENODEV:
clear_port_feature(hub-hdev,
port1, USB_PORT_FEAT_C_RESET);
That's a different bit. USB_PORT_FEAT_C_RESET isn't the same as
USB_PORT_FEAT_RESET.
what I am curious is,
if port reset bit will clear to 0 within 2ms, why we still need to
clear_port_feature with USB_PORT_FEAT_C_RESET
(clear Port reset )
if (hub_is_superspeed(hub-hdev)) {
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_BH_PORT_RESET);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
}
Sincerely Appreciate your kind explanation,
--
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
Re: about possible port reset when disconnect
hi alan:
Why you think it is a bug in hardware?
The timeout error means that the kernel told the controller to turn off
the PORT_RESET bit, and 1000 us later the bit was still on. That's a
hardware bug.
after checking my hardware I found if device is no connected and do
the port reset,
the reset bit always will be 1 (I purposely add port status check in
set port reset case like below)
Platform-ehci Platform-ehci.0: port 1 reset
Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus
port:1 status 000100 0 ACK sig=se0 RESET
from ehci spec, there did not mention what will HW to do if port reset
happens on no connection.
it only explain what controller needs to do when device is connected.
if related reset bit will automatically cleared for a while when
device is not connected.
Why we still need to clear them in hub_port_finish_reset like below flow
in hub_port_reset,
/* Check for disconnect or reset */
if (status == 0 || status == -ENOTCONN || status == -ENODEV) {
hub_port_finish_reset(hub, port1, udev, status);
then in hub_port_finish_reset
case -ENOTCONN:
case -ENODEV:
clear_port_feature(hub-hdev,
port1, USB_PORT_FEAT_C_RESET);
if (hub_is_superspeed(hub-hdev)) {
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_BH_PORT_RESET);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
}
Sincerely appreciate your kind help,
--
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
Re: about possible port reset when disconnect
hi Alan:
2014-04-04 8:48 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Thu, 3 Apr 2014, vichy wrote:
I add more description.
in Below #1, since connect status is zero, handshake will fail with
return -ETIMEDOUT.
Then go to #2 error label.
and finally hub_port_status get -32, -EPIPE.
1. Platform-ehci Platform-ehci.0: port 1 reset error -110
the -110 is due to below handshake timeout.
retval = handshake(ehci, status_reg,
PORT_RESET, 0, 1000);
if (retval != 0) {
ehci_err (ehci, port %d reset error %d\n,
wIndex + 1, retval);
goto error;
}
Right -- although the handshake shouldn't time out. That's a bug in
the hardware.
if there is no connection, it is reasonable have return value as timeout.
Why you think it is a bug in hardware?
2. hub 4-0:1.0: hub_port_status failed (err = -32)
the -32 is due to below error label we set retval = -EPIPE
error:
/* stall on error */
retval = -EPIPE;
But... This will happen only the first time we get the port status.
After that, ehci-reset_done[wIndex] will be 0 and so handshake() won't
get called.
hub_port_status() calls get_port_status(), which performs the operation
up to 3 times. The first time it will fail with -EPIPE, but what about
the second time?
in hub_port_reset, there PORT_RESET_TRIES, 5 in right now definition
to reset port.
and ehci-reset_done[wIndex] will refilled the (jiffies + 50ms) when
set port reset.
if in all PORT_RESET_TRIES loops, there is no device connected.
We will get -EPIPE all the time, right?
for (i = 0; i PORT_RESET_TRIES; i++) {
status = set_port_feature(hub-hdev, port1, (warm ?
USB_PORT_FEAT_BH_PORT_RESET :
USB_PORT_FEAT_RESET));
if (status) {
dev_err(hub-intfdev,
cannot %sreset port %d (err = %d)\n,
warm ? warm : , port1, status);
} else {
status = hub_port_wait_reset(hub, port1, udev, delay,
warm);
if (status status != -ENOTCONN)
dev_dbg(hub-intfdev,
port_wait_reset: err = %d\n,
status);
}
}
appreciate your kind explanation,
--
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
about possible port reset when disconnect
hi all: I list my environment as below: 1. Arm platform with ehci support 2. plug in NTFS USB HD and play movie 3. plug out device suddenly. I found there will be possibly that driver will reset port even there is no device connected. I purposely add below code in ehci-hub.c when we try to do port reset @@ -1173,7 +1173,12 @@ static int ehci_hub_control ( ehci_writel(ehci, temp, status_reg); + dbg_port (ehci, in port reset sequence, GetStatus, wIndex + 1, temp); + break; and I found driver will reset even device is disconnected like below log: (I also attach full log in the mail) tntfs info: NTFS volume version 3.1 (cluster_size 4096, PAGE_CACHE_SIZE 4096). Platform-ehci Platform-ehci.0: detected XactErr len 19456/20480 retry 1 hub 4-0:1.0: state 7 ports 1 chg evt 0002 hub 4-0:1.0: port 1, status , change 0001, 12 Mb/s Platform-ehci Platform-ehci.0: port 1 reset Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus port:1 status 000100 0 ACK sig=se0 RESET usb 4-1: USB disconnect, device number 20 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 hub 4-0:1.0: hub_port_status failed (err = -32) hub 4-0:1.0: port_wait_reset: err = -32 hub 4-0:1.0: port 1 not enabled, trying reset again... My questions are: 1. from the log the reason why port reset shows is test_bit(US_FLIDX_DISCONNECTING, us-dflags) failed in usb_stor_port_reset (in the log, I purposely dump_stack in usb_reset_and_verify_device) Why even USB disconnect show, the US_FLIDX_DISCONNECTING is not set up in time? 2. shall we add below determination before port reset? --- a/linux-3.8.2/drivers/usb/host/ehci-hub.c ++ b/linux-3.8.2/drivers/usb/host/ehci-hub.c @@ -1139,6 +1139,9 @@ static int ehci_hub_control ( case USB_PORT_FEAT_RESET: if (temp PORT_RESUME) goto error; + + if (!(temp PORT_CONNECT)) + goto disconnect; /* line status bits may report this as low speed, * which can be fine if this root hub has a * transaction translator built in. @@ -1219,6 +1223,10 @@ static int ehci_hub_control ( error: /* stall on error */ retval = -EPIPE; +disconnect: + + retval = -ENOTCONN; } Appreciate your help, tntfs info: NTFS volume version 3.1 (cluster_size 4096, PAGE_CACHE_SIZE 4096). Platform-ehci Platform-ehci.0: detected XactErr len 19456/20480 retry 1 hub 4-0:1.0: state 7 ports 1 chg evt 0002 hub 4-0:1.0: port 1, status , change 0001, 12 Mb/s Platform-ehci Platform-ehci.0: port 1 reset Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus port:1 status 000100 0 ACK sig=se0 RESET usb 4-1: USB disconnect, device number 20 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 hub 4-0:1.0: hub_port_status failed (err = -32) hub 4-0:1.0: port_wait_reset: err = -32 hub 4-0:1.0: port 1 not enabled, trying reset again... Platform-ehci Platform-ehci.0: port 1 reset Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus port:1 status 000100 0 ACK sig=se0 RESET Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 hub 4-0:1.0: hub_port_status failed (err = -32) hub 4-0:1.0: port_wait_reset: err = -32 hub 4-0:1.0: port 1 not enabled, trying reset again... Platform-ehci Platform-ehci.0: port 1 reset Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus port:1 status 000100 0 ACK sig=se0 RESET Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 hub 4-0:1.0: hub_port_status failed (err = -32) hub 4-0:1.0: port_wait_reset: err = -32 hub 4-0:1.0: port 1 not enabled, trying reset again... Platform-ehci Platform-ehci.0: port 1 reset Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus port:1 status 000100 0 ACK sig=se0 RESET Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1 reset error -110 Platform-ehci Platform-ehci.0: port 1
Re: about possible port reset when disconnect
hi Alan:
2014-04-03 20:52 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Thu, 3 Apr 2014, vichy wrote:
hi all:
I list my environment as below:
1. Arm platform with ehci support
2. plug in NTFS USB HD and play movie
3. plug out device suddenly.
I found there will be possibly that driver will reset port even there
is no device connected.
I purposely add below code in ehci-hub.c when we try to do port reset
@@ -1173,7 +1173,12 @@ static int ehci_hub_control (
ehci_writel(ehci, temp, status_reg);
+ dbg_port (ehci, in port reset sequence,
GetStatus, wIndex + 1, temp);
+
break;
and I found driver will reset even device is disconnected like below log:
(I also attach full log in the mail)
tntfs info: NTFS volume version 3.1 (cluster_size 4096, PAGE_CACHE_SIZE
4096).
Platform-ehci Platform-ehci.0: detected XactErr len 19456/20480 retry 1
hub 4-0:1.0: state 7 ports 1 chg evt 0002
hub 4-0:1.0: port 1, status , change 0001, 12 Mb/s
Platform-ehci Platform-ehci.0: port 1 reset
Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus
port:1 status 000100 0 ACK sig=se0 RESET
usb 4-1: USB disconnect, device number 20
Platform-ehci Platform-ehci.0: port 1 reset error -110
Platform-ehci Platform-ehci.0: port 1 reset error -110
Platform-ehci Platform-ehci.0: port 1 reset error -110
Platform-ehci Platform-ehci.0: port 1 reset error -110
Platform-ehci Platform-ehci.0: port 1 reset error -110
hub 4-0:1.0: hub_port_status failed (err = -32)
hub 4-0:1.0: port_wait_reset: err = -32
hub 4-0:1.0: port 1 not enabled, trying reset again...
My questions are:
1. from the log the reason why port reset shows is
test_bit(US_FLIDX_DISCONNECTING, us-dflags) failed in
usb_stor_port_reset
(in the log, I purposely dump_stack in usb_reset_and_verify_device)
Why even USB disconnect show, the US_FLIDX_DISCONNECTING is not
set up in time?
Your log contains the explanation:
Platform-ehci Platform-ehci.0: port 1 reset
This is where the reset starts.
Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus
port:1 status 000100 0 ACK sig=se0 RESET
usb 4-1: USB disconnect, device number 20
And this is where US_FLIDX_DISCONNECTING gets set -- after the reset
has already begun.
2. shall we add below determination before port reset?
--- a/linux-3.8.2/drivers/usb/host/ehci-hub.c
++ b/linux-3.8.2/drivers/usb/host/ehci-hub.c
@@ -1139,6 +1139,9 @@ static int ehci_hub_control (
case USB_PORT_FEAT_RESET:
if (temp PORT_RESUME)
goto error;
+
+ if (!(temp PORT_CONNECT))
+ goto disconnect;
/* line status bits may report this as low speed,
* which can be fine if this root hub has a
* transaction translator built in.
We could add this, but it's not a big deal. The real question is why
did this happen:
hub 4-0:1.0: hub_port_status failed (err = -32)
hub_port_status should not return an error. It should have returned
valid data, and the port status should have shown that the device was
disconnected. Can you figure out why hub_port_status didn't work?
1. Platform-ehci Platform-ehci.0: port 1 reset error -110
retval = handshake(ehci, status_reg,
PORT_RESET, 0, 1000);
if (retval != 0) {
ehci_err (ehci, port %d reset error %d\n,
wIndex + 1, retval);
goto error;
}
2. hub 4-0:1.0: hub_port_status failed (err = -32)
the -32 is due to below error label we set retval = -EPIPE
error:
/* stall on error */
retval = -EPIPE;
thanks for your kind reply ^^
--
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
Re: about possible port reset when disconnect
hi Alan:
Your log contains the explanation:
Platform-ehci Platform-ehci.0: port 1 reset
This is where the reset starts.
Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus
port:1 status 000100 0 ACK sig=se0 RESET
usb 4-1: USB disconnect, device number 20
And this is where US_FLIDX_DISCONNECTING gets set -- after the reset
has already begun.
2. shall we add below determination before port reset?
--- a/linux-3.8.2/drivers/usb/host/ehci-hub.c
++ b/linux-3.8.2/drivers/usb/host/ehci-hub.c
@@ -1139,6 +1139,9 @@ static int ehci_hub_control (
case USB_PORT_FEAT_RESET:
if (temp PORT_RESUME)
goto error;
+
+ if (!(temp PORT_CONNECT))
+ goto disconnect;
/* line status bits may report this as low speed,
* which can be fine if this root hub has a
* transaction translator built in.
We could add this, but it's not a big deal. The real question is why
did this happen:
hub 4-0:1.0: hub_port_status failed (err = -32)
hub_port_status should not return an error. It should have returned
valid data, and the port status should have shown that the device was
disconnected. Can you figure out why hub_port_status didn't work?
I add more description.
in Below #1, since connect status is zero, handshake will fail with
return -ETIMEDOUT.
Then go to #2 error label.
and finally hub_port_status get -32, -EPIPE.
1. Platform-ehci Platform-ehci.0: port 1 reset error -110
the -110 is due to below handshake timeout.
retval = handshake(ehci, status_reg,
PORT_RESET, 0, 1000);
if (retval != 0) {
ehci_err (ehci, port %d reset error %d\n,
wIndex + 1, retval);
goto error;
}
2. hub 4-0:1.0: hub_port_status failed (err = -32)
the -32 is due to below error label we set retval = -EPIPE
error:
/* stall on error */
retval = -EPIPE;
thanks for your kind reply ^^
--
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
Re: questions about give back urb in tasklet
hi Ming.lei: 2014-03-17 22:01 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Sun, 16 Mar 2014, vichy wrote: hi all: recently we bump to system performance issue when usb irq take quite long. I found below link for discussing how to short in http://permalink.gmane.org/gmane.linux.usb.general/89363 I have some questions about this patch. 1. is there patch or kernel config I can use to measure man/avage usb irq time consuming like the above link show 2. I see this patch is roll back in commit c04ee4b1136e462722567cf6e76bb35a181574a7 and intend to be ready in 3.13-rc1 Is there special reason why we need to roll back? Appreciate your help in advance, -- 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
Re: questions about give back urb in tasklet
hi all: 2014-03-19 17:57 GMT+08:00 vichy vichy@gmail.com: hi Ming.lei: 2014-03-17 22:01 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Sun, 16 Mar 2014, vichy wrote: hi all: recently we bump to system performance issue when usb irq take quite long. I found below link for discussing how to short in http://permalink.gmane.org/gmane.linux.usb.general/89363 I have some questions about this patch. 1. is there patch or kernel config I can use to measure man/avage usb irq time consuming like the above link show 2. I see this patch is roll back in commit c04ee4b1136e462722567cf6e76bb35a181574a7 and intend to be ready in 3.13-rc1 Is there special reason why we need to roll back? why this patch didn't implement xhci? in xhci-pci.c there is no HCD_HB at xhci_pci_hc_driver .flags =HCD_MEMORY | HCD_USB3 | HCD_SHARED, does that mean xhci don't need to pug complete in the BH? thanks for your help, -- 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
Re: questions about give back urb in tasklet
hi Ming in http://permalink.gmane.org/gmane.linux.usb.general/89363 I have some questions about this patch. 1. is there patch or kernel config I can use to measure man/avage usb irq time consuming like the above link show One approach I like to use is trace event. Would you please let us how to to use trace event for calculate max/average usb irq time? 2. I see this patch is roll back in commit c04ee4b1136e462722567cf6e76bb35a181574a7 and intend to be ready in 3.13-rc1 Is there special reason why we need to roll back? Yes, the revert revert can enable to run completion handler in BH, isn't that what you need? YES, what I need is try to see whether my problem will be solved if running completion handlers in BH. At beginning, the revert let me think there are something wrong after we put completion in BH. And we need to revert it back to put completion in irq so the revert mean put completion in BH, right? But actually the local interrupt is still disabled during completion because we need to convert spin_lock in all current usb drivers to spin_lock_irqsave() first. Would you please let me know the function or source you mentioned? BTW, why I cannot see xhci add HCD_BH? is there some reason xhci cannot put completion in BH? thanks for your kind help, -- 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
Re: questions about give back urb in tasklet
hi Ming: One approach I like to use is trace event. Would you please let us how to to use trace event for calculate max/average usb irq time? You can enable irq_handler_entry and irq_handler_exit event, then write a script easily to figure out the time consumed in ehci irq handler, see Documentation/trace/events.txt of linux kernel for detailed steps. I find it ^^ But actually the local interrupt is still disabled during completion because we need to convert spin_lock in all current usb drivers to spin_lock_irqsave() first. Would you please let me know the function or source you mentioned? The local interrupt is disabled during completion handler in __usb_hcd_giveback_urb(). BTW, why I cannot see xhci add HCD_BH? There might be some reasons: - in previous following up discussion, Alan thought it should be easier to just split the hcd interrupt handler into two parts - as I said, spin_lock() isn't converted to spin_lock_irqsave() in drivers' completion handler yet Do you mean , take uvc/uac for example, if we put completion what they register previously in BH, the spin_lock() in their completions should be changed to spin_lock_irqsave()? Is it due to original completion is called in irq context? - maybe no one really care the time in which local interrupt is disabled by USB completion handler.(That might be true because USB devices are commonly used in personal computer, not in big server product) is there some reason xhci cannot put completion in BH? IMO, the completion handler should be put into tasklet, and can be done. If you like, you can take time to do that. Below is so far kernel implementation. Isn't it put completion handler into tasklet? ... .. spin_lock(bh-lock); list_add_tail(urb-urb_list, bh-head); running = bh-running; spin_unlock(bh-lock); if (running) ; else if (high_prio_bh) tasklet_hi_schedule(bh-bh); else tasklet_schedule(bh-bh); Thanks for your help, -- 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
questions about give back urb in tasklet
hi all: recently we bump to system performance issue when usb irq take quite long. I found below link for discussing how to short http://permalink.gmane.org/gmane.linux.usb.general/89363 I have some questions about this patch. 1. is there patch or kernel config I can use to measure man/avage usb irq time consuming like the above link show 2. I see this patch is roll back in commit c04ee4b1136e462722567cf6e76bb35a181574a7 and intend to be ready in 3.13-rc1 Is there special reason why we need to roll back? appreciate your help in advance, -- 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
xhci port link Disable setting and logic disconnect
hi all:
below is the source code about setting xhci port to ss.disable state
Why we need to or PORT_PE at this time?
Spec didn't mention about to or PORT_PE before setting xhci port to
ss.disable state.
/* Disable port */
if (link_state == USB_SS_PORT_LS_SS_DISABLED) {
xhci_dbg(xhci, Disable port %d\n, wIndex);
temp = xhci_port_state_to_neutral(temp);
/*
* Clear all change bits, so that we get a new
* connection event.
*/
temp |= PORT_CSC | PORT_PEC | PORT_WRC |
PORT_OCC | PORT_RC | PORT_PLC |
PORT_CEC;
xhci_writel(xhci, temp | PORT_PE,
port_array[wIndex]);
temp = xhci_readl(xhci, port_array[wIndex]);
break;
}
2. when I unplug some buggy device, I see even connect status as 0
xhci driver still try to warm reset, should we add connect status
determination in xhci for terminating warm reset earlier.
( I attach the log for your reference.
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x2802f0
platform-xhci platform-xhci.0: Get port status returned 0x3002f0
hub 6-0:1.0: port 1 not reset yet, waiting 200ms
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x2802f0
platform-xhci platform-xhci.0: Get port status returned 0x3002f0
hub 6-0:1.0: port 1 not reset yet, waiting 200ms
hub 6-0:1.0: port_wait_reset: err = -16
hub 6-0:1.0: port 1 not enabled, trying reset again...
platform-xhci platform-xhci.0: set port reset, actual port 0 status = 0x2802f0
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x2802f0
platform-xhci platform-xhci.0: Get port status returned 0x3002f0
hub 6-0:1.0: port 1 not reset yet, waiting 200ms
3. what is the difference between logic disconnect and real disconnect?
from the log, I see logic disconnect but I cannot tell the meaning of
this function.
Appreciate your kind help in advance,
VDLinux# [ 0][ 6392.390460] platform-xhci platform-xhci.0: Port Status Change Event for port 2
platform-xhci platform-xhci.0: handle_port_status: starting port polling.
hub 6-0:1.0: state 7 ports 1 chg evt 0002
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x4012c1
platform-xhci platform-xhci.0: Get port status returned 0x4002c1
platform-xhci platform-xhci.0: clear port link state change, actual port 0 status = 0x12c1
hub 6-0:1.0: warm reset port 1
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12c1
platform-xhci platform-xhci.0: Get port status returned 0x2c1
platform-xhci platform-xhci.0: xhci_hub_status_data: stopping port polling.
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12b1
platform-xhci platform-xhci.0: Get port status returned 0x2b1
hub 6-0:1.0: port 1 not warm reset yet, waiting 50ms
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12f1
platform-xhci platform-xhci.0: Get port status returned 0x2f1
hub 6-0:1.0: port 1 not warm reset yet, waiting 200ms
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12f1
platform-xhci platform-xhci.0: Get port status returned 0x2f1
hub 6-0:1.0: port 1 not warm reset yet, waiting 200ms
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12f1
platform-xhci platform-xhci.0: Get port status returned 0x2f1
hub 6-0:1.0: port 1 not warm reset yet, waiting 200ms
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12f1
platform-xhci platform-xhci.0: Get port status returned 0x2f1
hub 6-0:1.0: port 1 not warm reset yet, waiting 200ms
hub 6-0:1.0: port_wait_reset: err = -16
hub 6-0:1.0: port 1 not enabled, trying warm reset again...
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12f1
platform-xhci platform-xhci.0: Get port status returned 0x2f1
hub 6-0:1.0: port 1 not warm reset yet, waiting 200ms
platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12f1
platform-xhci platform-xhci.0: Get port status returned 0x2f1
hub 6-0:1.0: port 1 not warm reset yet, waiting 200ms
VDLinux#
VDLinux# [ 0][ 6393.943456] platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12f1
platform-xhci platform-xhci.0: Get port status returned 0x2f1
hub 6-0:1.0: port 1 not warm reset yet, waiting 200ms
VDLinux# [ 0][ 6394.167464] platform-xhci platform-xhci.0: get port status, actual port 0 status = 0x12f1
platform-xhci platform-xhci.0: Get port status returned 0x2f1
hub 6-0:1.0: port 1 not warm reset yet, waiting 200ms
hub 6-0:1.0: port_wait_reset: err = -16
hub
Re: usb modem not working on xhci host
hi Greg: 2014-03-06 22:49 GMT+08:00 Greg KH gre...@linuxfoundation.org: On Thu, Mar 06, 2014 at 10:35:24PM +0800, vichy wrote: hi sarah: Can you send me the output of `sudo lsusb -v` for when the device is under EHCI and when it's under xHCI? Also, please take a usbmon trace, as described by http://lxr.free-electrons.com/source/Documentation/usb/usbmon.txt Start the trace just before you plug the device in. Take one trace when the device under EHCI, and one when it's under xHCI. Please reference the attachment Below is my host environment Which kernel are you running? Linux 3.13.0 Please try 3.13.5, as a number of known USB 3 bugs have been fixed in there since 3.13.0 Sure! BTW, would you please let me know what bug fixed in 3.13 for usb3? is it related to modem? appreciate your help, -- 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
Re: usb modem not working on xhci host
hi Sarah and Greg: 2014-03-06 23:25 GMT+08:00 vichy vichy@gmail.com: hi Greg: 2014-03-06 22:49 GMT+08:00 Greg KH gre...@linuxfoundation.org: On Thu, Mar 06, 2014 at 10:35:24PM +0800, vichy wrote: hi sarah: Can you send me the output of `sudo lsusb -v` for when the device is under EHCI and when it's under xHCI? Also, please take a usbmon trace, as described by http://lxr.free-electrons.com/source/Documentation/usb/usbmon.txt Start the trace just before you plug the device in. Take one trace when the device under EHCI, and one when it's under xHCI. Please reference the attachment Below is my host environment Which kernel are you running? Linux 3.13.0 Please try 3.13.5, as a number of known USB .3 bugs have been fixed in there since 3.13.0 1. I attach lsusb -v log fro xhci and ehci. 2. I try kernel 3.14.rc5 but xhci port still cannot enable modem successfully thanks for your help, ehci.xhci.lsusb.log.tar.bz2 Description: BZip2 compressed data
Re: some question about xhci TRB_INTR_TARGET
hi David: 2014-03-04 19:40 GMT+08:00 David Laight david.lai...@aculab.com: From: vichy hi all: from xhci spec, Interrupter Target is the value between 0 and MaxIntrs-1. But why the parameter pass to TRB_INTR_TARGTRB_INTR_TARGET is always 0. Does that mean so far xhci host didn't support multi-interrupt as MSI-X suggested? AFAIK The Linux USB stack doesn't support the locking required for fine-grained interrupts. So only a single interrupt can be supported. is there any special reason we don't support fine-grained interrupts? it semes PCI has support MSI-X quite long ago. Thanks for your kind reply, -- 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
usb modem not working on xhci host
hi all: when I plug 3g modem dongle to ehci port, it works But when I plug in xhci port, it cannot successfully doing the modem mode change. The related 3G modem driver should be independent by host type, right? Below is my host environment and I also attach log about plug in xhci and ehci. ( as you can see in ehci log, the 3g modem can change to modem mode successfully) 00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Lenovo Device 21f7 Flags: bus master, medium devsel, latency 0, IRQ 40 Memory at f260 (64-bit, non-prefetchable) [size=64K] Capabilities: access denied Kernel driver in use: xhci_hcd [20043.678076] usb 3-1: USB disconnect, device number 31 [20050.235962] usb 1-1.2: new high-speed USB device number 16 using ehci-pci [20050.334882] usb 1-1.2: New USB device found, idVendor=12d1, idProduct=1446 [20050.337862] usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=0 [20050.340685] usb 1-1.2: Product: HUAWEI Mobile [20050.343022] usb 1-1.2: Manufacturer: HUAWEI Technology [20050.347185] usb-storage 1-1.2:1.0: USB Mass Storage device detected [20050.348408] scsi116 : usb-storage 1-1.2:1.0 [20050.350633] usb-storage 1-1.2:1.1: USB Mass Storage device detected [20050.353079] scsi117 : usb-storage 1-1.2:1.1 [20051.350203] scsi 116:0:0:0: CD-ROMHUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2 [20051.354209] scsi 117:0:0:0: Direct-Access HUAWEI SD Storage 2.31 PQ: 0 ANSI: 2 [20051.357444] sr0: scsi-1 drive [20051.359681] sr 116:0:0:0: Attached scsi CD-ROM sr0 [20051.361846] sr 116:0:0:0: Attached scsi generic sg1 type 5 [20051.364925] sd 117:0:0:0: Attached scsi generic sg2 type 0 [20051.368804] sd 117:0:0:0: [sdb] Attached SCSI removable disk [20051.462065] usb 1-1.2: USB disconnect, device number 16 [20051.466012] scsi 117:0:0:0: rejecting I/O to offline device [20051.468190] scsi 117:0:0:0: killing request [20055.618056] usb 1-1.2: new high-speed USB device number 17 using ehci-pci [20055.713401] usb 1-1.2: New USB device found, idVendor=12d1, idProduct=1436 [20055.715448] usb 1-1.2: New USB device strings: Mfr=4, Product=3, SerialNumber=0 [20055.717477] usb 1-1.2: Product: HUAWEI Mobile [20055.719465] usb 1-1.2: Manufacturer: HUAWEI Technology [20055.724692] usb-storage 1-1.2:1.0: USB Mass Storage device detected [20055.727146] option 1-1.2:1.0: GSM modem (1-port) converter detected [20055.729346] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0 [20055.731406] usb-storage 1-1.2:1.1: USB Mass Storage device detected [20055.735213] cdc_ether 1-1.2:1.1 wwan0: register 'cdc_ether' at usb-:00:1a.0-1.2, Mobile Broadband Network Device, 02:50:f3:00:00:00 [20055.736548] usb-storage 1-1.2:1.3: USB Mass Storage device detected [20055.738153] option 1-1.2:1.3: GSM modem (1-port) converter detected [20055.739706] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1 [20055.740660] usb-storage 1-1.2:1.4: USB Mass Storage device detected [20055.741740] option 1-1.2:1.4: GSM modem (1-port) converter detected [20055.743124] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2 [20055.744105] usb-storage 1-1.2:1.5: USB Mass Storage device detected [20055.745711] scsi122 : usb-storage 1-1.2:1.5 [20055.747201] usb-storage 1-1.2:1.6: USB Mass Storage device detected [20055.749722] scsi123 : usb-storage 1-1.2:1.6 [20056.748638] scsi 122:0:0:0: CD-ROMHUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2 [20056.753896] scsi 123:0:0:0: Direct-Access HUAWEI SD Storage 2.31 PQ: 0 ANSI: 2 [20056.757543] sr0: scsi-1 drive [20056.760088] sr 122:0:0:0: Attached scsi CD-ROM sr0 [20056.761289] sr 122:0:0:0: Attached scsi generic sg1 type 5 [20056.762580] sd 123:0:0:0: Attached scsi generic sg2 type 0 [20056.769739] sd 123:0:0:0: [sdb] Attached SCSI removable disk [20030.333022] usb 3-1: new high-speed USB device number 31 using xhci_hcd [20030.355575] usb 3-1: New USB device found, idVendor=12d1, idProduct=1446 [20030.357627] usb 3-1: New USB device strings: Mfr=3, Product=2, SerialNumber=0 [20030.359654] usb 3-1: Product: HUAWEI Mobile [20030.361649] usb 3-1: Manufacturer: HUAWEI Technology [20030.365767] usb-storage 3-1:1.0: USB Mass Storage device detected [20030.368209] scsi114 : usb-storage 3-1:1.0 [20030.370372] usb-storage 3-1:1.1: USB Mass Storage device detected [20030.372697] scsi115 : usb-storage 3-1:1.1 [20031.371542] scsi 114:0:0:0: CD-ROMHUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2 [20031.376507] sr0: scsi-1 drive [20031.378831] sr 114:0:0:0: Attached scsi CD-ROM sr0 [20031.378975] scsi 115:0:0:0: Direct-Access HUAWEI SD Storage 2.31 PQ: 0 ANSI: 2 [20031.383303] sr 114:0:0:0: Attached scsi generic sg1 type 5 [20031.385041] sd 115:0:0:0: Attached scsi generic sg2 type 0 [20031.389105] sd 115:0:0:0: [sdb] Attached SCSI removable disk
Re: some questions about bandwidth calculation
hi alan: 2014-02-14 23:36 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Fri, 14 Feb 2014, vichy wrote: hi Alan: I don't understand your question. At full speed (12 Mb/s), the time required to transfer 188 bytes is (188 bytes) * (8 bits/byte) / (12 b/us) = 125.33 us, which is greater than 125 us. @@ -1412,7 +1412,7 @@ sitd_slot_ok ( */ uf = uframe 7; if (!tt_available(ehci, period_uframes 3, - stream-udev, frame, uf, stream-tt_usecs)) + stream-udev, frame, uf, stream-usecs)) if so, shall we modify code like above? Use transfer time instead of bus budget to calculate tt_avaiable? No. stream-usecs is the time required on the high-speed bus, and stream-tt_usecs is the time required on the full/low-speed bus. tt_available makes its decisions based on whether there is enough available time on the full/low-speed bus. Therefore it needs to use stream-tt_usecs. it makes me a little confused. if we try to send 108 bytes to FS iso ep over HS hub. shouldn't we use below formula to calculate what bus time need for? NS_TO_US (think_time + usb_calc_bus_time ( dev-speed, is_input, 1, 108)); it seems no matter we transfer 108, 118, 140, even 188 bytes to FS iso ep over HS hub. The full/low bus time are all the same. appreciate your help -- 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
Re: some questions about bandwidth calculation
hi Alan: I don't understand your question. At full speed (12 Mb/s), the time required to transfer 188 bytes is (188 bytes) * (8 bits/byte) / (12 b/us) = 125.33 us, which is greater than 125 us. @@ -1412,7 +1412,7 @@ sitd_slot_ok ( */ uf = uframe 7; if (!tt_available(ehci, period_uframes 3, - stream-udev, frame, uf, stream-tt_usecs)) + stream-udev, frame, uf, stream-usecs)) if so, shall we modify code like above? Use transfer time instead of bus budget to calculate tt_avaiable? For each packet (token, data, and handshake), the overhead includes inter-packet delay, cable delay, SYNC, bit-stuffing, and End-Of-Packet -- all in addition to the PID, token, and CRC bytes. I don't know where you got that 13 from. If you assume the The 13 bytes I see is from usb spec section 5.8.4. Then you must have noticed the sentence just above Table 5-9: The table does not include the overhead associated with bit stuffing. The table also doesn't include the overhead associated with cable delay and intermediate hubs. inter-packet delays always require 1 byte time and count up the inter-packet delays (3), SYNCs (3), token bytes (3), PID and CRC hytes (3), and handshake (1), that adds up to 13 bytes of protocol overhead. But it leaves out cable delay, bit-stuffing, and End-Of-Packet signals. You also have to remember that the spec allows the clock rate on Full-Speed devices to vary by up to 0.25% of the nominal rate. so you mean FS speed will be 12M bits/s +- 3 bits/s?(3/12M = 0.25%) That's right. Also, Low-Speed devices are allowed to vary by up to 1.5%, and High-Speed devices are allowed to vary by up to 0.05%. Appreciate your help, -- 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
Re: some questions about bandwidth calculation
hi Alan:
2014-02-07 23:40 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Fri, 7 Feb 2014, vichy wrote:
Hi Alan:
2014-01-31 2:23 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Fri, 31 Jan 2014, vichy wrote:
Hi all:
I have some questions about bandwidth calculation
1. why tt time need to include one maxp bus time ?
qh-tt_usecs = NS_TO_US (think_time +
usb_calc_bus_time (urb-dev-speed,
is_input, 0, max_packet (maxp)));
Because tt_usecs is the time required to send a maximum-size packet.
So of course you have to include the maxp bus time.
is it the requirement defined in spec?
if so, would you please tell me where I can find it?
Section 11.18.2 (last paragraph on p. 373):
The host always uses the maximum data payload size for a
full-/low-speed endpoint in doing its budgeting.
2. in tt_available, below is used to check whether tt time is bigger than
125us
if (125 usecs) {
int ufs = (usecs / 125);
int i;
for (i = uframe; i (uframe + ufs) i 8; i++)
if (0 tt_usecs[i]) {
ehci_vdbg(ehci,
multi-uframe xfer can't fit
in frame %d uframe %d\n,
frame, i);
return 0;
}
}
is it possible tt time bigger than 1 uframe?
Yes. Any isochronous transfer that is longer than 188 bytes will
require more than one uframe.
from spec's explanation, the usecs in the above source is the budget
calculated with Maxp instead of bandwidth indeed we need to transfer.
Why it is still possible over 125us?
for the case the ep max packet size over 188 bytes?
3. below is the fomula to calculate bus time
Full-speed (Input)
Non-Isochronous Transfer (Handshake Included)
= 9107 + (83.54 * Floor(3.167 + BitStuffTime(Data_bc))) + Host_Delay
what is 9107 and 3.167 used for?
(9102 is not equal to FS bit time * FS protocol overhead)
9107 is the overhead. It includes things like inter-packet delays, the
IN or OUT token packet, the ACK packet, and so on.
in spec I only find the formula, but spec didn't tell where this 9107 come
from?
No, it doesn't. And in fact, the values in the spec are wrong because
they don't take into account the delays caused by intermediate hubs.
take Full buck for example, which is non-iso, the protocol overhead is
only 13Bytes.
What do you mean by Full buck?
sorry it is my typo, I mean FS bulk.
For each packet (token, data, and handshake), the overhead includes
inter-packet delay, cable delay, SYNC, bit-stuffing, and End-Of-Packet
-- all in addition to the PID, token, and CRC bytes.
I don't know where you got that 13 from. If you assume the
The 13 bytes I see is from usb spec section 5.8.4.
inter-packet delays always require 1 byte time and count up the
inter-packet delays (3), SYNCs (3), token bytes (3), PID and CRC hytes
(3), and handshake (1), that adds up to 13 bytes of protocol overhead.
But it leaves out cable delay, bit-stuffing, and End-Of-Packet signals.
You also have to remember that the spec allows the clock rate on
Full-Speed devices to vary by up to 0.25% of the nominal rate.
so you mean FS speed will be 12M bits/s +- 3 bits/s?(3/12M = 0.25%)
Appreciate your help
--
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
Re: some questions about bandwidth calculation
Hi Alan:
2014-01-31 2:23 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Fri, 31 Jan 2014, vichy wrote:
Hi all:
I have some questions about bandwidth calculation
1. why tt time need to include one maxp bus time ?
qh-tt_usecs = NS_TO_US (think_time +
usb_calc_bus_time (urb-dev-speed,
is_input, 0, max_packet (maxp)));
Because tt_usecs is the time required to send a maximum-size packet.
So of course you have to include the maxp bus time.
is it the requirement defined in spec?
if so, would you please tell me where I can find it?
2. in tt_available, below is used to check whether tt time is bigger than
125us
if (125 usecs) {
int ufs = (usecs / 125);
int i;
for (i = uframe; i (uframe + ufs) i 8; i++)
if (0 tt_usecs[i]) {
ehci_vdbg(ehci,
multi-uframe xfer can't fit
in frame %d uframe %d\n,
frame, i);
return 0;
}
}
is it possible tt time bigger than 1 uframe?
Yes. Any isochronous transfer that is longer than 188 bytes will
require more than one uframe.
3. below is the fomula to calculate bus time
Full-speed (Input)
Non-Isochronous Transfer (Handshake Included)
= 9107 + (83.54 * Floor(3.167 + BitStuffTime(Data_bc))) + Host_Delay
what is 9107 and 3.167 used for?
(9102 is not equal to FS bit time * FS protocol overhead)
9107 is the overhead. It includes things like inter-packet delays, the
IN or OUT token packet, the ACK packet, and so on.
in spec I only find the formula, but spec didn't tell where this 9107 come from?
take Full buck for example, which is non-iso, the protocol overhead is
only 13Bytes.
appreciate your help,
--
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
some questions about bandwidth calculation
Hi all:
I have some questions about bandwidth calculation
1. why tt time need to include one maxp bus time ?
qh-tt_usecs = NS_TO_US (think_time +
usb_calc_bus_time (urb-dev-speed,
is_input, 0, max_packet (maxp)));
2. in tt_available, below is used to check whether tt time is bigger than 125us
if (125 usecs) {
int ufs = (usecs / 125);
int i;
for (i = uframe; i (uframe + ufs) i 8; i++)
if (0 tt_usecs[i]) {
ehci_vdbg(ehci,
multi-uframe xfer can't fit
in frame %d uframe %d\n,
frame, i);
return 0;
}
}
is it possible tt time bigger than 1 uframe?
3. below is the fomula to calculate bus time
Full-speed (Input)
Non-Isochronous Transfer (Handshake Included)
= 9107 + (83.54 * Floor(3.167 + BitStuffTime(Data_bc))) + Host_Delay
what is 9107 and 3.167 used for?
(9102 is not equal to FS bit time * FS protocol overhead)
Thanks for your help in advance,
--
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
Re: some question about period scheduleing
hi 2013/12/2 Alan Stern st...@rowland.harvard.edu: On Sun, 1 Dec 2013, vichy wrote: hi Alan: 2013/12/1 Alan Stern st...@rowland.harvard.edu: On Fri, 29 Nov 2013, vichy wrote: hi all: My connection like below ehci -- high speed hub - full speed device I have some questions about period scheduling. 1. when creating qh for full speed device, why we set EHCI_TUNE_RL_TT. Are you asking why EHCI_TUNE_RL_TT is equal to 0? I don't know -- it looks like a mistake. Do you find that changing it to 3 makes any difference? Yes, when I change EHCI_TUNE_RL_TT as not 0. The transaction can keep going. But if EHCI_TUNE_RL_TT is 0, the transfer doesn't work? No. the transaction will stop since device return Nak. I copy the usb traffic log for your reference. usually device will not return NAK in setup token. but in my case, it did. Thanks for your kind help, attachment: Device.Nak.png
Re: some question about period scheduleing
hi Alan: 2013/12/1 Alan Stern st...@rowland.harvard.edu: On Fri, 29 Nov 2013, vichy wrote: hi all: My connection like below ehci -- high speed hub - full speed device I have some questions about period scheduling. 1. when creating qh for full speed device, why we set EHCI_TUNE_RL_TT. Are you asking why EHCI_TUNE_RL_TT is equal to 0? I don't know -- it looks like a mistake. Do you find that changing it to 3 makes any difference? Yes, when I change EHCI_TUNE_RL_TT as not 0. The transaction can keep going. isn't it possible the full speed device return NAK during transaction? Of course it is possible. If so, why we use EHCI_TUNE_RL_TT default as 0? that mean once it react with NAK, the host will stop below transaction. The host stops the transaction temporarily. It will restart the transaction later. See section 4.9.1 in the EHCI spec. I find what you mentioned. How could we make sure device never react with NAK? There is no way to do that. 2. I attach my mon log for your reference. there is one thing I am curious why below message 'E' mean in bulk/interrupt? I have checked Document/usb/usbmon.txt but get nothing. E means the preceding submission failed. d8c32600 190047566 E Bi:1:006:2 -19 0 d8c32980 190062351 C Bi:1:006:2 -107 0 d8c32980 190062363 S Bi:1:006:2 -115 1025 d8c32980 190072803 E Bi:1:006:2 -19 0 For example, this E means the submission on the line above was unsuccessful. The error code -19 is -ENODEV, which means the device has been disconnected. This is described in Documentation/usb/usbmon.txt: - Event Type. This type refers to the format of the event, not URB type. Available types are: S - submission, C - callback, E - submission error. Thanks for your help -- 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
some question about period scheduleing
hi all: My connection like below ehci -- high speed hub - full speed device I have some questions about period scheduling. 1. when creating qh for full speed device, why we set EHCI_TUNE_RL_TT. isn't it possible the full speed device return NAK during transaction? that mean once it react with NAK, the host will stop below transaction. How could we make sure device never react with NAK? 2. I attach my mon log for your reference. there is one thing I am curious why below message 'E' mean in bulk/interrupt? I have checked Document/usb/usbmon.txt but get nothing. d8c32600 190047566 E Bi:1:006:2 -19 0 d8c32980 190062351 C Bi:1:006:2 -107 0 d8c32980 190062363 S Bi:1:006:2 -115 1025 d8c32980 190072803 E Bi:1:006:2 -19 0 d71e1080 190087616 C Bi:1:006:2 -107 0 d71e1080 190087631 S Bi:1:006:2 -115 1025 d71e1080 190098075 E Bi:1:006:2 -19 0 d8c32e80 190112778 C Ii:1:006:1 -107:1 0 d8c32e80 190112798 S Ii:1:006:1 -115:1 258 d8c32e80 190112823 E Ii:1:006:1 -19 0 grateful to your help, d8c1f900 174296127 S Ci:1:006:0 s 80 06 0100 0012 18 d8c1f900 174324543 C Ci:1:006:0 0 18 = 12010002 ff010140 5c0abe22 12010102 0301 d8c32c80 174328283 S Ci:1:006:0 s 80 06 0600 000a 10 d8c32c80 174379310 C Ci:1:006:0 -32 0 d8c32c80 174379388 S Ci:1:006:0 s 80 06 0600 000a 10 d8c32c80 174430320 C Ci:1:006:0 -32 0 d8c32c80 174430384 S Ci:1:006:0 s 80 06 0600 000a 10 d8c32c80 174479871 C Ci:1:006:0 -32 0 da681c00 174484791 S Ci:1:006:0 s 80 06 0200 0009 9 da681c00 174520974 C Ci:1:006:0 0 9 = 0902da00 040100e0 00 da681c00 174521041 S Ci:1:006:0 s 80 06 0200 00da 218 da681c00 174564730 C Ci:1:006:0 0 218 = 0902da00 040100e0 00090400 0003ff01 01000705 81031000 01070582 0241 d8c32680 174571894 S Ci:1:006:0 s 80 06 0300 00ff 255 d8c32680 174613002 C Ci:1:006:0 0 4 = 04030904 d8c32680 174618720 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 d8c32680 174661979 C Ci:1:006:0 0 22 = 16034200 43004d00 32003000 37003000 32004100 3000 d8c32680 174662431 S Ci:1:006:0 s 80 06 0301 0409 00ff 255 d8c32680 174704527 C Ci:1:006:0 0 28 = 1c034200 72006f00 61006400 63006f00 6d002000 43006f00 72007000 d8c32680 174704770 S Ci:1:006:0 s 80 06 0303 0409 00ff 255 d8c32680 174746502 C Ci:1:006:0 0 26 = 1a033000 30003000 42003600 42004500 44003900 39003800 3600 d8c32680 174807834 S Co:1:006:0 s 00 09 0001 0 d8c32680 174834431 C Co:1:006:0 0 0 d8c32680 174870590 S Co:1:006:0 s 01 0b 0001 0 d8c32680 174897880 C Co:1:006:0 0 0 d8c32e80 174922305 S Ii:1:006:1 -115:1 258 d8c32b80 174931010 S Ii:1:006:1 -115:1 258 d8c32480 174931177 S Ii:1:006:1 -115:1 258 d8c32300 174931267 S Ii:1:006:1 -115:1 258 d8c32400 174931352 S Ii:1:006:1 -115:1 258 d8c32f00 174931428 S Ii:1:006:1 -115:1 258 d8c32e00 174931493 S Ii:1:006:1 -115:1 258 d8c32a00 174931565 S Ii:1:006:1 -115:1 258 d8c32280 174931652 S Bi:1:006:2 -115 1025 d8c32a80 174942316 S Bi:1:006:2 -115 1025 d8c32580 174953281 S Bi:1:006:2 -115 1025 d8c32180 174964533 S Bi:1:006:2 -115 1025 d8c32b00 174975493 S Bi:1:006:2 -115 1025 d8c32080 174986576 S Bi:1:006:2 -115 1025 d8c32780 174997454 S Bi:1:006:2 -115 1025 d8c32f80 175008444 S Bi:1:006:2 -115 1025 d8c32500 175019240 S Bi:1:006:2 -115 1025 d8c32600 175030098 S Bi:1:006:2 -115 1025 d8c32980 175040930 S Bi:1:006:2 -115 1025 d71e1080 175051876 S Bi:1:006:2 -115 1025 d71e1700 175062714 S Bi:1:006:4 -115 1025 d71e1780 175073656 S Bi:1:006:4 -115 1025 d8c32680 175330914 S Co:1:006:0 s 20 00 0003 3 = 030c00 d8c32680 175359355 C Co:1:006:0 0 3 d8c32e80 175368360 C Ii:1:006:1 0:1 6 = 0e040103 0c00 d8c32e80 175369092 S Ii:1:006:1 -115:1 258 d8c32680 175379837 S Co:1:006:0 s 20 00 0003 3 = 051000 d8c32680 175415382 C Co:1:006:0 0 3 d8c32b80 175424464 C Ii:1:006:1 0:1 13 = 0e0b0105 1000fd03 40080001 00 d8c32b80 175427478 S Ii:1:006:1 -115:1 258 d8c32680 175435384 S Co:1:006:0 s 20 00 000a 10 = 330c079b 06ff1400 0a00 d8c32680 175471360 C Co:1:006:0 0 10 d8c32480 175480365 C Ii:1:006:1 0:1 6 = 0e040133 0c00 d8c32480 175480492 S Ii:1:006:1 -115:1 258 d8c32680 175481017 S Co:1:006:0 s 20 00 0003 3 = 011000 d8c32680 175525553 C Co:1:006:0 0 3 d8c32300 175534638 C Ii:1:006:1 0:1 14 = 0e0c0101 16b8 21060f00 0e41 d8c32300 175534750 S Ii:1:006:1 -115:1 258 d8c32680 175535082 S Co:1:006:0 s 20 00 0003 3 = 091000 d8c32680 175579666 C Co:1:006:0 0 3 d8c32400 175588769 C Ii:1:006:1 0:1 12 = 0e0a0109 10008699 ed6b0b00 d8c32400 175588874 S Ii:1:006:1 -115:1 258 d8c32680 175589408 S Co:1:006:0 s 20 00 0003 3 = 021000 d8c32680 175635075 C Co:1:006:0 0 3 d8c32f00 175644175 C Ii:1:006:1 0:1 70 = 0e440102 1000 ff03ccff efffcfff ec1ff20f e8fe3ff7 8fff1c00 61f7 d8c32f00 175644312 S Ii:1:006:1 -115:1 258 d8c32680 175644670 S Co:1:006:0 s 20 00 0003 3 = 031000 d8c32680 175690521 C Co:1:006:0 0 3 d8c32e00 175699606 C Ii:1:006:1 0:1 14 = 0e0c0103 1000bffe cffedbff
Re: some question about mon binary
hi alan 2013/11/15 Alan Stern st...@rowland.harvard.edu: On Fri, 15 Nov 2013, vichy wrote: hi Alan 2013/11/14 Alan Stern st...@rowland.harvard.edu: On Thu, 14 Nov 2013, vichy wrote: hi all: I have some questions: 1. if I need to capture all the data host capture from bus, usb mon binary can reach this goal? Yes. 2. if #1 is Yes. from usb mon text I need a. compile kernel with usbmon support b. access /dev/usbmonx c. feed the binary file to wireshark. in b), shall we write a user mode program? No, just use the usbmon program. However, it creates a text file, not a binary file. You can't feed the output to wireshark. If you want binary output that wireshark can use, you have to run a different program like tcpdump or dumpcap. Read the four lines above... I can use wireshark to pasring the binary get from tcpdump. I apoligize for misunderstanding your explaination. :) BTW, is it possible to filter out bulk, interrupt or isochronous data that echi driver pass to urb? I am writing user mode usb driver with libusb and want to check the data correctness by comparing 1. the data return from urb-complete 2. data ehci get from device and pass to urb Appreciate your help, -- 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
some question about mon binary
hi all: I have some questions: 1. if I need to capture all the data host capture from bus, usb mon binary can reach this goal? 2. if #1 is Yes. from usb mon text I need a. compile kernel with usbmon support b. access /dev/usbmonx c. feed the binary file to wireshark. in b), shall we write a user mode program? if so, is there any sample flow I can reference? 3. if #1 is No, is there any default kernel config can do that? or I should write memcpy by hand in urb_complete? Thanks for your help -- 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
Re: some question about mon binary
hi alan: 2013/11/14 Alan Ott a...@signal11.us: On 11/14/2013 09:33 AM, vichy wrote: 1. if I need to capture all the data host capture from bus, usb mon binary can reach this goal? 2. if #1 is Yes. from usb mon text I need a. compile kernel with usbmon support b. access /dev/usbmonx c. feed the binary file to wireshark. With usbmon loaded, wireshark can capture from usbmon directly. Depending on your distro, you may need to load usbmon manually: modprobe usbmon forget to mentioned, my platform is arm embedded system. And it seems I have to get binary from my target board then feed it to wireshark on my pc, right? if so, how could I dump the binary from embedded target board? Appreciate your help, -- 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
Re: some question about mon binary
hi alan ott: 2013/11/14 Alan Ott a...@signal11.us: On 11/14/2013 09:52 AM, vichy wrote: hi alan: 2013/11/14 Alan Ott a...@signal11.us: On 11/14/2013 09:33 AM, vichy wrote: 1. if I need to capture all the data host capture from bus, usb mon binary can reach this goal? 2. if #1 is Yes. from usb mon text I need a. compile kernel with usbmon support b. access /dev/usbmonx c. feed the binary file to wireshark. With usbmon loaded, wireshark can capture from usbmon directly. Depending on your distro, you may need to load usbmon manually: modprobe usbmon forget to mentioned, my platform is arm embedded system. And it seems I have to get binary from my target board then feed it to wireshark on my pc, right? if so, how could I dump the binary from embedded target board? Use tcpdump: tcpdump -i usbmon1 -w out.dump It is embarrassing that busybox on the target don't have tcpdump :-) Is there any other way to reach the same goal? appreciate your kind help, -- 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
Re: some question about mon binary
hi Alan 2013/11/14 Alan Stern st...@rowland.harvard.edu: On Thu, 14 Nov 2013, vichy wrote: hi all: I have some questions: 1. if I need to capture all the data host capture from bus, usb mon binary can reach this goal? Yes. 2. if #1 is Yes. from usb mon text I need a. compile kernel with usbmon support b. access /dev/usbmonx c. feed the binary file to wireshark. in b), shall we write a user mode program? No, just use the usbmon program. However, it creates a text file, not a binary file. You can't feed the output to wireshark. If you want binary output that wireshark can use, you have to run a different program like tcpdump or dumpcap. if so, is there any sample flow I can reference? See the README file and the man page that are part of the usbmon package: http://people.redhat.com/zaitcev/linux/usbmon-6.tar.gz I download and compile the file you mention. when I run the binary as below with option -a1, I still cannot see binary file. # ./usbmon -i usb1 -a1 f2acb600 0.568167 S Ci:1:001:0 s a3 00 0001 0004 4 f2acb600 0.568181 C Ci:1:001:0 0 4 = 0001 f2acb600 0.568186 S Ci:1:001:0 s a3 00 0002 0004 4 f2acb600 0.568193 C Ci:1:001:0 0 4 = 01050100 f2acb600 0.568199 S Co:1:001:0 s 23 01 0010 0002 0 f2acb600 0.568205 C Co:1:001:0 0 0 f2acb600 0.568209 S Ci:1:001:0 s a3 00 0003 0004 4 f2acb600 0.568213 C Ci:1:001:0 0 4 = # # ls # ls COPYING Makefile README usbmon usbmon.8 usbmon.c usbmon.o # Did I use the wrong option or the only way to get binary is using tcpdump? Appreciate all your kind help :-) -- 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
Re: some questions about ehci period scheduling
hi alan:
BTW, I have another question about iso_stream_schedule.
When if (likely (!list_empty (stream-td_list))) happen,
why don't we just take last scheduled microframe, stream-next_uframe
as start point directly?
We do exactly that if URB_ISO_ASAP isn't set. But first the routine
has to check and see if the schedule is already full, and it prints a
debugging message if all the assigned microframes have already expired.
Does below source show us what you mean?
if (unlikely(start period)) {
ehci_dbg(ehci, iso sched full %p (%u-%u %u mod %u)\n,
urb, stream-next_uframe, base,
period, mod);
status = -ENOSPC;
goto fail;
}
That's the first part (checking if the schedule is already full).
This is the second part (printing a debug message if all the assigned
microframes have already expired):
Does this expired come from (controller frame pointer)
(stream-next_uframe)?
Suppose controller frame pointer = 640 and stream-next_uframe = 600.
And that mean Controller have scan our last schedule uframe?
/*
* Not ASAP: Use the next slot in the stream,
* no matter what.
*/
else if (start + span - period now2) {
ehci_dbg(ehci, iso underrun %p (%u+%u %u)\n,
urb, start + base,
span - period, now2 + base);
}
if so, I have one question, why we use ( (last scan frame and last
schedule frame) end point interval) to determine schedule is full?
If start period, it means that the last packet on the schedule (which
is assigned to uframe start - period) comes before base. The only way
this can happen is if the packets occupy the entire schedule and wrap
around.
base in your example base should be 8's multiple, right?
if so, I try to rewrite your example.
(if anything wrong, please correct me)
(rewrite version)
If you think about a few examples, you'll understand. Suppose the
endpoint's interval is 8 uframes, starting from uframe 3. Suppose base
is 496, and suppose the schedule really is full. Then there will be
packets scheduled for uframes 507, 515, ..., 8187, 3, 11, ..., 491, 499
(note that 491 is slightly before 496), and stream-next_uframe will be
499. So start will be set to (499 - 496) 8191 = 3. The fact that 3
8 indicates the schedule is full.
(rewrite version)
Now suppose everything else is the same, but the schedule isn't
completely full. For this example, let's suppose the last scheduled
packet is in uframe 483, so stream-next_uframe is equal to 491. Then
start will be set to (491 - 496) 8191 = 8196. The fact that 8196 =
8 indicates the schedule isn't full.
In above case, driver should try to stop this urb if it try to
schedule more than 1 packet, right?
(rewrite version)
Consider one more example: Everything else is the same, but there's
only one packet in the schedule. It is assigned to uframe 507, and
stream-next_uframe is 515. Then start will be set to (515 - 496)
8191 = 19, and the fact that 19 = 8 indicates the schedule isn't full.
Does this help?
Yes, it did help me a lot. :)
Below is where we handle URB_ISO_ASAP,
if (urb-transfer_flags URB_ISO_ASAP)
start += (next - start + period - 1) -period;
Why don't we just use start as next?
If start next then we don't want to use it. Packets scheduled before
next might not be seen by the hardware, because of the isochronous
scheduling threshold (see section 4.7.2.1 in the EHCI spec).
when we calculate next, we have already put isochronous scheduling threshold.
if (ehci-i_thresh)
next = now + ehci-i_thresh;/* uframe cache */
else
next = (now + 2 + 7) ~0x07;/* full frame cache */
so when handling URB_ISO_ASAP, is it possible to change as below
if (urb-transfer_flags URB_ISO_ASAP)
-start += (next - start + period - 1) -period;
+ start = (next + base);
Appreciate your kind help,
--
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
Re: some questions about ehci period scheduling
hi Alan:
BTW, I have another question about iso_stream_schedule.
When if (likely (!list_empty (stream-td_list))) happen,
why don't we just take last scheduled microframe, stream-next_uframe
as start point directly?
We do exactly that if URB_ISO_ASAP isn't set. But first the routine
has to check and see if the schedule is already full, and it prints a
debugging message if all the assigned microframes have already expired.
Does below source show us what you mean?
if (unlikely(start period)) {
ehci_dbg(ehci, iso sched full %p (%u-%u %u mod %u)\n,
urb, stream-next_uframe, base,
period, mod);
status = -ENOSPC;
goto fail;
}
if so, I have one question, why we use ( (last scan frame and last
schedule frame) end point interval) to determine schedule is full?
Below is where we handle URB_ISO_ASAP,
if (urb-transfer_flags URB_ISO_ASAP)
start += (next - start + period - 1) -period;
Why don't we just use start as next?
Appreciate your kind help,
--
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
Re: [alsa-devel] question about webcam audio capture
hi Clemens: 2013/9/9 Clemens Ladisch clem...@ladisch.de: vichy wrote: I try to do webcam audio capture on my arm platform. when I execute audio capture I got below message retire_capture_urb: 108 callbacks suppressed This means that the retire_capture_urb() function printed lots of messages, and that 108 of them were thrown away because they were identical. Does that mean: 1. 108 of messages are the same and through away 2. alsa get data from uac device through Host controller driver 108 times and find they are the same and through away You have to look at the previous line to get the actual message. I try to grep -rwn 'retire_capture_urb.*' sound/usb/*, but get nothing. Would you please tell me what the previous line to get the actual message you mean? 2. from usb mon log, it seems HW keep Active status high even until ehci_io_watchdog happen, because the ep status is -EXDEV. How are you trying to capture data? I use the capture function in tinyalsa. BTW, If I want to use number of urbs I expected and only send/complete only 1 round, where I can find the source code to modify? Thanks for your great help, -- 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
Re: [alsa-devel] question about webcam audio capture
hi Clemens: 2013/9/9 vichy vichy@gmail.com: hi Clemens: 2013/9/9 Clemens Ladisch clem...@ladisch.de: vichy wrote: I try to do webcam audio capture on my arm platform. when I execute audio capture I got below message retire_capture_urb: 108 callbacks suppressed This means that the retire_capture_urb() function printed lots of messages, and that 108 of them were thrown away because they were identical. Does that mean: 1. 108 of messages are the same and through away 2. alsa get data from uac device through Host controller driver 108 times and find they are the same and through away You have to look at the previous line to get the actual message. I try to grep -rwn 'retire_capture_urb.*' sound/usb/*, but get nothing. Would you please tell me what the previous line to get the actual message you mean? 2. from usb mon log, it seems HW keep Active status high even until ehci_io_watchdog happen, because the ep status is -EXDEV. How are you trying to capture data? I use the capture function in tinyalsa. forget to say, the command I execute is tinycap record.wav -D 0 -d 0 -c 2 -r 32000 BTW, If I want to use number of urbs I expected and only send/complete only 1 round, where I can find the source code to modify? it seems ep-nurbs in snd_usb_endpoint_start is what I expected, right? Thanks for your great help, -- 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
Re: some questions about ehci period scheduling
hi Alan: 2013/9/7 Alan Stern st...@rowland.harvard.edu: On Sat, 7 Sep 2013, vichy wrote: hi all: when I trace linux ehci driver source code. I have some questions 1. in itd_slot_ok, why we have to uframe %= period; and use this uframe to calculate the bandwidth? suppose start passed to itd_slot_ok is 537, period, usb-interval, is 8. that mean we want to know whether bandwidth of microframe 537 is enough. Not want to know whether 537%8 =1 the bandwidth of microframe 1 is enough. In fact you need to know both. If an isochronous endpoint has interval 8 and it uses microframe 537, then it's also going to use microframes 545, 553, 561, ..., 8177, 8185, 1, 9, ..., 529. So at first time stream is scheduled, we have to make sure all possible microframe bandwidth is enough, right? 2. Below is part of message excerpted from usb mon log: db1e2000 81051026 S Zi:1:002:6 -115:8:5327 1 -18:0:132 132 db1e2000 81058043 C Zi:1:002:6 0:8:5391:0 1 0:0:4 132 = 2efd82fd 0cfe 84feb3ff 98fec4fb 08ffdaf8 060059fb 8b01d2ff db02de01 why these 2 ep-start_frame are different, 5327 in -115:8:5327 and 5391 in 0:8:5391:0? The log is captured with the same urb, for submitting and completing. That mean ep-start_frame=urb-start_frame in submit and complete should be the same, right? No. The value in urb-start_frame during submission is meaningless. Usually it is left over from the last time urb was used. After the URB is submitted, the host controller driver stores the correct value in urb-start_frame, and usbmon shows the correct value during completion. I got it. BTW, I have another question about iso_stream_schedule. When if (likely (!list_empty (stream-td_list))) happen, why don't we just take last scheduled microframe, stream-next_uframe as start point directly? appreciate your kind help, -- 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
Re: question about webcam audio capture
2013/9/8 vichy vichy@gmail.com: hi all: I try to do webcam audio capture on my arm platform. when I execute audio capture I got below message retire_capture_urb: 108 callbacks suppressed my questions: 1. where I can get the message retire_capture_urb: 108 callbacks suppressed show in sound/usb driver? I try to grep -rwn 'retire_capture_urb.*' sound/usb/*, but get nothing. 2. from usb mon log, it seems HW keep Active status high even until ehci_io_watchdog happen, because the ep status is -EXDEV. if my observation is correct, is it possible to modify usb sound driver to purposely send fix number urbs. Because from the usb mon log, the first 8 urb will get time out already. BTW, forget to say my kernel version is 3.8.2 thanks for your help in advance, -- 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
some questions about ehci period scheduling
hi all: when I trace linux ehci driver source code. I have some questions 1. in itd_slot_ok, why we have to uframe %= period; and use this uframe to calculate the bandwidth? suppose start passed to itd_slot_ok is 537, period, usb-interval, is 8. that mean we want to know whether bandwidth of microframe 537 is enough. Not want to know whether 537%8 =1 the bandwidth of microframe 1 is enough. 2. Below is part of message excerpted from usb mon log: db1e2000 81051026 S Zi:1:002:6 -115:8:5327 1 -18:0:132 132 db1e2000 81058043 C Zi:1:002:6 0:8:5391:0 1 0:0:4 132 = 2efd82fd 0cfe 84feb3ff 98fec4fb 08ffdaf8 060059fb 8b01d2ff db02de01 why these 2 ep-start_frame are different, 5327 in -115:8:5327 and 5391 in 0:8:5391:0? The log is captured with the same urb, for submitting and completing. That mean ep-start_frame=urb-start_frame in submit and complete should be the same, right? appreciate your help in advance, -- 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
RE: USB Host to Host Communication
Hi: Do you mean host to hub or really host to host? According usb spec, no matter ehci or usb2.0, if one plays the role as host, another one have the responsibility to receive different schedules, Asynchronous and period, and this will make this one plays the role as device. It seems unreasonable if you designed two hosts that only send the schedules without receiving anything. Sincerely Yours, vichy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of krishna prasath Sent: Tuesday, February 26, 2008 1:57 PM To: linux-usb@vger.kernel.org Subject: USB Host to Host Communication Hi , I am new to Device driver. I am developing a USB device driver in LInux Platform for a host to host communication. Do you have any documents which tells how to do USB host to host commmunication or a driver code for the same. Please help me in this issue. - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about port reset
Dear all: Below is a part of ehci_hub_control function in ehci-hub.c. /* force reset to complete */ writel (temp ~(PORT_RWC_BITS | PORT_RESET), ehci-regs-port_status [wIndex]); Where PORT_RWC_BITS = (PORT_CSC | PORT_PEC | PORT_OCC) and if I interpret it correctly, it will set PORT_CSC, PORT_PEC, PORT_OCC and PORT_RESET as 0. I can understand why we set PORT_RESET as 0, but why we set other 3 parameters as 0, too. Thanks for your help, vichy - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question about port reset
I got it. Thanks for your help, vichy -Original Message- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Monday, February 25, 2008 4:58 AM To: vichy Cc: linux-usb@vger.kernel.org Subject: Re: Question about port reset On Sun, 24 Feb 2008, vichy wrote: Dear all: Below is a part of ehci_hub_control function in ehci-hub.c. /* force reset to complete */ writel (temp ~(PORT_RWC_BITS | PORT_RESET), ehci-regs-port_status [wIndex]); Where PORT_RWC_BITS = (PORT_CSC | PORT_PEC | PORT_OCC) and if I interpret it correctly, it will set PORT_CSC, PORT_PEC, PORT_OCC and PORT_RESET as 0. You do not interpret it correctly. The PORT_RWC_BITS are named that way because that are Read-and-Write-to-Clear. That is, when the computer writes a 1 to any of those bits, the effect is to set the bit to 0. Writing a 0 leaves the bit unchanged. I can understand why we set PORT_RESET as 0, but why we set other 3 parameters as 0, too. By including PORT_RWC_BITS in that statement we _avoid_ setting those bits to 0. Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about FRINDEX and SOF
Dear all: In section 4.5 of ehci-r10.pdf, there is a phase which says The one micro-frame delay yields host controller periodic schedule and bus frame boundary relationship as illustrated in Figure 4-7. This adjustment allows software to trivially schedule the periodic start and complete-split transactions for full and low-speed periodic endpoints, using the natural alignment of the periodic schedule interface I know it tries to explain why FRINDEX is one ahead of SOF number. But I cannot feel the trivialness which mentions in driver source, could someone tell me why it tries to do so? Thanks for your help, vichy - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
