On Thu, Jul 11, 2013 at 11:08:59AM +0200, Sebastian Andrzej Siewior wrote:
> Hello,
>
> following scenario:
> you attach an UART-TO-USB adapter to your musb port running ux500-dma
> code. The USB UARt driver queues 1x RX URB with the size of 256 bytes
> (example) and the max packet size is 64.
>
On Thu, 11 Jul 2013, Sarah Sharp wrote:
> On Sat, Jul 06, 2013 at 04:48:47PM -0400, Alan Stern wrote:
> > On Sat, 6 Jul 2013, Maarten Lankhorst wrote:
> >
> > > I didn't even know I still had lockdep on.
> > > The following lockdep splat happened when I plugged in a usb bluetooth
> > > dongle, u
[also adding Steven, he's the tracing expert after all :-)]
Hi Xenia, Sarah, all,
> (Mentors and wireless folks, we're struggling a bit with adding trace
> events to the xHCI USB host controller driver. I'm trying to look at
> the ath6kl driver trace events as an example. We could use some help
On 07/11/2013 06:20 PM, Sarah Sharp wrote:
On Mon, Jul 08, 2013 at 09:17:59PM +0300, Xenia Ragiadakou wrote:
But when there are other function calls before the callback call, I don't
no why but i cannot track anymore the position of the args following the
fmt argumenent in the stack with the p
On Thu, Jul 11, 2013 at 4:24 AM, Johannes Stezenbach wrote:
> There are several cases where the isoc descriptor actual length is
> short (< 2892, e.g. 0, 552 or 1928), yet the actual_length for the
> whole URB at the end of the line is still 64*2892 -- is that like it should
> be?
Yup, as Alan s
On 07/11/2013 06:58 PM, Greg KH wrote:
>> following scenario:
>> you attach an UART-TO-USB adapter to your musb port running ux500-dma
>> code. The USB UARt driver queues 1x RX URB with the size of 256 bytes
>> (example) and the max packet size is 64.
>>
>> The other side sends only one byte becaus
On Thu, Jul 11, 2013 at 11:28 AM, Alan Stern wrote:
> On Thu, 11 Jul 2013, Johannes Stezenbach wrote:
>
>> I took a peek at the usbmon log, and there is one thing I don't get.
>>
>> $ grep "C Zi:1:005:2" em28xx_usbmon.log | less -S
>>
>> There are several cases where the isoc descriptor actual l
Hi Peter,
> This patchset adds tested otg id switch function and
> vbus connect and disconnect detection for chipidea driver.
> And fix kinds of bugs found at chipidea drivers after enabling
> id and vbus detection.
>
> This patch is fully tested at imx6 sabresd platform.
> My chipidea repo: http
On Thu, 11 Jul 2013, Devin Heitmueller wrote:
> It looks like I may have created some confusion by attempting to
> correlate the usbmon trace against the Beagle data. I've got two
> environments I'm debugging on: an x86 box with the stock Intel EHCI
> HCD, and a Davinci TI8147 ARM system which h
This patch removes a redundant nested "#ifdef CONFIG_PM" from the hub
driver. It also adds a label to the "#endif" line corresponding to
the outer "#ifdef CONFIG_PM".
Signed-off-by: Alan Stern
---
[as1691]
drivers/usb/core/hub.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
The hub driver was recently changed to use "global" suspend for system
suspend transitions on non-SuperSpeed buses. This means that we don't
suspend devices individually by setting the suspend feature on the
upstream hub port; instead devices all go into suspend automatically
when the root hub sto
On Thu, Jul 11, 2013 at 07:08:53PM +0200, Johannes Berg wrote:
> [also adding Steven, he's the tracing expert after all :-)]
>
> Hi Xenia, Sarah, all,
>
> > (Mentors and wireless folks, we're struggling a bit with adding trace
> > events to the xHCI USB host controller driver. I'm trying to look
On Thu, Jul 11, 2013 at 02:12:08PM -0400, Alan Stern wrote:
> On Thu, 11 Jul 2013, Devin Heitmueller wrote:
>
> > Another strange thing: If I change the completion handler on the 8147
> > to comment out the actual processing of the URB (such that all the
> > completion handler does is resubmit th
On Wed, Jul 03, 2013 at 10:07:13AM -0400, Alan Stern wrote:
> On Tue, 2 Jul 2013, Sarah Sharp wrote:
>
> > > On the other hand, I know from personal experience that some companies
> > > are worried about this race and insist on avoiding it. Should I add a
> > > Kconfig option to force global susp
On 07/11/2013 08:58 PM, Alan Stern wrote:
> This should be applied to the 3.10 stable kernel.
>
> Signed-off-by: Alan Stern
> Reported-and-tested-by: Toralf Förster
> CC:
tested this patch against 3.10 - works fine too - thx.
(this patch is a slightly modified variant of what you sent a week
On Thu, Jul 11, 2013 at 3:02 PM, Johannes Stezenbach wrote:
> I'm not familiar with musb but a quick glance at the code
> shows it uses software packet scheduling. If you do too
> much processing in the URB completion callback (which
> is called from irq context), then the next bus transaction
>
On Thu, 2013-07-11 at 19:08 +0200, Johannes Berg wrote:
> > > lets say that we want the tracepoint function to have the prototype:
> > >
> > > void trace_cmd_address_device(const char *fmt, ...).
>
> I'm not sure this is possible. I think we (wireless) do this with
>
> void trace_cmd_address_de
James Stone wrote:
> On Mon, Jul 8, 2013 at 2:12 PM, James Stone wrote:
>>> ALSA: poll time out, polled for 2176094 usecs
>>> JackAudioDriver::ProcessAsync: read error, stopping...
>>>
>>> This is a definite reduction in performance compared to earlier kernels.
In theory, "poll time out" indicate
On Thu, 11 Jul 2013, Toralf Förster wrote:
> On 07/11/2013 08:58 PM, Alan Stern wrote:
> > This should be applied to the 3.10 stable kernel.
> >
> > Signed-off-by: Alan Stern
> > Reported-and-tested-by: Toralf Förster
> > CC:
>
> tested this patch against 3.10 - works fine too - thx.
>
> (th
On Thu, 11 Jul 2013, Devin Heitmueller wrote:
> Funny - I had the same thought a few hours ago about moving the actual
> URB processing to a tasklet. However I don't think it will help.
> Here's why:
>
> Expanding on the test where I cut out everything in the URB handler
> except for the submit,
On Thu, 11 Jul 2013, Sarah Sharp wrote:
> > I don't know. The real cause of the problem is that the USB-2 spec
> > never took this race into account. (AFAIK neither did the USB-3 spec;
> > didn't you face this problem at one point?) It contains detailed state
> > diagrams and explanations for
On Thu, Jul 11, 2013 at 5:02 PM, Alan Stern wrote:
> You could try doing the opposite test: Leave the driver otherwise
> intact, but have it not deliver the video buffers to the userspace
> client.
Interesting. Only one error in 72 frames of video. Suggests the
problem is somewhere that is anyw
Hi Jingoo,
Yeah, I followed that discussion back then, but it seems to have
stalled a little (at least the HSIC patches haven't been picked up in
any kernel.org repo yet to my knowledge).
The problem is that I think these approaches cannot work reliably. I
agree that it would be nice to control t
From: Hayes Wang
Date: Mon, 8 Jul 2013 10:41:21 +0800
> Base on cdc_ether, add the mii functions for RTL8152 and RTL8153.
> The RTL8152 and RTL8153 support ECM mode which use the driver of
> cdc_ether. Add the mii functions. Then, the basic PHY access is
> possible.
>
> Signed-off-by: Hayes Wang
This patch declares an event class for trace events that
trace messages with variadic arguments, called xhci_log_msg,
and defines a trace event for tracing the debug messages in
xhci_address_device() function, called xhci_dbg_address.
In order to implement this type of trace events, a wrapper func
On Friday, July 12, 2013 6:46 AM, Julius Werner wrote:
>
> Hi Jingoo,
>
> Yeah, I followed that discussion back then, but it seems to have
> stalled a little (at least the HSIC patches haven't been picked up in
> any kernel.org repo yet to my knowledge).
>
> The problem is that I think these app
Minor coding style nits below:
On Fri, Jul 12, 2013 at 03:36:27AM +0300, Xenia Ragiadakou wrote:
> --- a/drivers/usb/host/xhci-dbg.c
> +++ b/drivers/usb/host/xhci-dbg.c
> @@ -21,6 +21,7 @@
> */
>
> #include "xhci.h"
> +#include "xhci-trace.h"
>
> #define XHCI_INIT_VALUE 0x0
>
> @@ -580,3
This patch declares an event class for trace events that
trace messages with variadic arguments, called xhci_log_msg,
and defines a trace event for tracing the debug messages in
xhci_address_device() function, called xhci_dbg_address.
In order to implement this type of trace events, a wrapper func
On 07/12/2013 03:54 AM, Greg KH wrote:
Minor coding style nits below:
On Fri, Jul 12, 2013 at 03:36:27AM +0300, Xenia Ragiadakou wrote:
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -21,6 +21,7 @@
*/
#include "xhci.h"
+#include "xhci-trace.h"
#define XHCI_
On Thu, Jul 11, 2013 at 11:33 PM, Pete Zaitcev
wrote:
> On Thu, 11 Jul 2013 17:05:26 +0800
> Ming Lei wrote:
>
>> Complete() will be run with interrupt enabled, so change to
>> spin_lock_irqsave().
>>
>> Cc: Pete Zaitcev
>> Signed-off-by: Ming Lei
>
> Signed-off-by: Pete Zaitcev
Thank you.
>
On Fri, Jul 12, 2013 at 2:47 AM, Randy Dunlap wrote:
> On 07/10/13 21:17, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20130710:
>>
>
>
> on x86_64:
>
> # CONFIG_USB_GADGET is not set
>
> ERROR: "usb_gadget_map_request" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> ERROR: "usb_del_gadge
On Thu, Jul 11, 2013 at 05:36:10PM +0200, Marek Vasut wrote:
> Dear Peter Chen,
>
> > Since we need otgsc to know vbus's status at some chipidea
> > controllers even it is peripheral-only mode. Besides, some
> > SoCs (eg, AR9331 SoC) don't have otgsc register even
> > the DCCPARAMS_DC and DCCPARAM
On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> Hi Peter,
>
> > This patchset adds tested otg id switch function and
> > vbus connect and disconnect detection for chipidea driver.
> > And fix kinds of bugs found at chipidea drivers after enabling
> > id and vbus detection.
> >
> >
Hi,
> However, the USB-2 spec says (section 9.2.6.4) that devices should be
> able to carry out requests with no Data stage (such as Set-Config)
> within 50 ms. Does your gadget really take longer than that to handle
> the exception?
>
> To find out, collect a usbmon trace showing what happens wh
Dear Peter Chen,
> On Thu, Jul 11, 2013 at 05:36:10PM +0200, Marek Vasut wrote:
> > Dear Peter Chen,
> >
> > > Since we need otgsc to know vbus's status at some chipidea
> > > controllers even it is peripheral-only mode. Besides, some
> > > SoCs (eg, AR9331 SoC) don't have otgsc register even
> >
apply the patch
> > below. The board stays in HOST mode all the time. If I configure it as
> > peripheral, it works as peripheral. Note with [1], I was able to switch
> > from Peripheral->Host , not the other way around.
>
> Thanks for your testing. But first, can you hav
Johannes Berg writes:
>> (Mentors and wireless folks, we're struggling a bit with adding trace
>> events to the xHCI USB host controller driver. I'm trying to look at
>> the ath6kl driver trace events as an example. We could use some help
>> and/or advice.)
>
> Those were in turn modelled on ma
Sarah Sharp writes:
> My initial list of specific trace points was something like:
>
> 1. xHCI host initialization and shutdown
>
> 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
>
> 3. A few individual xHCI host controller command tracepoints:
>* status only for all
Hi, Oliver,
Regarding skel_write, I see your current desgin only refuse its execution
when> WRITES_IN_FLIGHT are on the fly, but this is not blocking IO due to
write() will not wait before callback returns, right? Do you think it's
unnecessary to support blocking IO on write or any special reas
On Fri, Jul 12, 2013 at 04:49:54AM +, WangChen wrote:
> Hi, Oliver,
> Regarding skel_write, I see your current desgin only refuse its
> execution when> WRITES_IN_FLIGHT are on the fly, but this is not
> blocking IO due to write() will not wait before callback returns,
> right? Do you think it'
Current usbhsx_for_each_xxx macro will read out-of-array's
memory after last loop operation.
It was not good C language operation, and the binary which was
compiled by (at least) gcc 4.8.1 is broken
This patch tidyup these issues
Reported-by: Yusuke Goda
Reviewed-by: Takashi Yoshii
Signed-off-by
I'm writing a driver for OSRFX2 learning board to test bulkloop read/write. I
think non-blocking write is good for such device due to the FX2 chipset has
dual-buffer for bulk endpoints. I am just wondering if I also need to support
blocking write IO due to I used to think from driver perspective
On Fri, Jul 12, 2013 at 05:51:04AM +, WangChen wrote:
> I'm writing a driver for OSRFX2 learning board to test bulkloop
> read/write.
What's wrong with the existing usb-serial driver that can easily do
this?
> I think non-blocking write is good for such device due to
> the FX2 chipset has dua
---
drivers/usb/gadget/composite.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 55f4df6..9d25912 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1138,7 +1138,7 @@ st
On Fri, Jul 12, 2013 at 09:48:08AM +0300, Daniel Ciocirlan wrote:
> ---
> drivers/usb/gadget/composite.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
you need to fix the patch by adding a commit log and moving your SoB to
the commit log, rather than the subject.
--
balbi
signatu
Hi,
On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote:
> Hi Felipe,
>
> This is intended to pull down a reset signal line, not to switch power
> to the device. I could implement that with the regulator framework
> too, but I think that would just be confusing and harder to understand
101 - 146 of 146 matches
Mail list logo
