Re: g_webcam Isoch high bandwidth transfer

2016-09-27 Thread Felipe Balbi

Hi,

Bin Liu  writes:
> On Fri, Sep 23, 2016 at 10:49:57AM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Bin Liu  writes:
>> > +Fengwei Yin per his request.
>> >
>> > On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
>> >> 
>> >> Hi,
>> >> 
>> >> Bin Liu  writes:
>> >> 
>> >> [...]
>> >> 
>> >> >> Here's one that actually compiles, sorry about that.
>> >> >
>> >> > No worries, I was sleeping ;-)
>> >> >
>> >> > I will test it out early next week. Thanks.
>> >> 
>> >> meanwhile, how about some instructions on how to test this out myself?
>> >> How are you using g_webcam and what are you running on host side? Got a
>> >> nice list of commands there I can use? I think I can get to bottom of
>> >> this much quicker if I can reproduce it locally ;-)
>> >
>> > On device side:
>> > - first patch g_webcam as in my first email in this thread to enable
>> >   640x480@30fps;
>> > - # modprobe g_webcam streaming_maxpacket=3072
>> > - then run uvc-gadget to feed the YUV frames;
>> >http://git.ideasonboard.org/uvc-gadget.git
>> 
>> as is, g_webcam never enumerates to the host. It's calls to
>
> Right, on mainline kernel (I tested 4.8.0-rc7) g_webcam is broken with
> DWC3, g_webcam does not enumerate on the host. But it works on v4.4.21.

There aren't that many changes related to g_webcam though.

$ git log --oneline --no-merges v4.4..HEAD -- 
drivers/usb/gadget/function/f_uvc.c drivers/usb/gadget/legacy/webcam.c 
drivers/usb/gadget/function/uvc*
4fbac5206afd usb: gadget: uvc: Add missing call for additional setup data
bd610c5aa9fc usb: gadget: uvc: Fix return value in case of error
36c0f8b32c4b [media] vb2: replace void *alloc_ctxs by struct device *alloc_devs
1ae1602de028 configfs: switch ->default groups to a linked list
d6dd645eae76 [media] media: videobuf2: Move timestamp to vb2_buffer
df9ecb0cad14 [media] vb2: drop v4l2_format argument from queue_setup
0aecfc1b359d usb: gadget: composite: remove redundant bcdUSB setting in legacy

>> uvc-gadget keeps printing this error message:
>> 
>>  159 if ((ret = ioctl(dev->fd, VIDIOC_DQBUF, )) < 0) {
>>  160 printf("Unable to dequeue buffer: %s (%d).\n", 
>> strerror(errno),
>>  161 errno);
>>  162 return ret;
>>  163 }
>
> I removed this printf, since it floods the console if start uvc-gadget
> before connect to the host.

fair enough

> BTY, you don't have to start uvc-gadget first then connect usb cable. I
> keep the cable always connected.

good to know. Thanks

-- 
balbi


signature.asc
Description: PGP signature


Re: g_webcam Isoch high bandwidth transfer

2016-09-27 Thread Felipe Balbi

Hi,

Laurent Pinchart  writes:
> Hi Felipe,
>
> On Friday 23 Sep 2016 11:27:26 Felipe Balbi wrote:
>> yfw  writes:
>> >> Here's one that actually compiles, sorry about that.
>> > 
>> > No worries, I was sleeping ;-)
>> > 
>> > I will test it out early next week. Thanks.
>>  
>>  meanwhile, how about some instructions on how to test this out myself?
>>  How are you using g_webcam and what are you running on host side? Got a
>>  nice list of commands there I can use? I think I can get to bottom of
>>  this much quicker if I can reproduce it locally ;-)
>> >>> 
>> >>> On device side:
>> >>> - first patch g_webcam as in my first email in this thread to enable
>> >>>   640x480@30fps;
>> >>> - # modprobe g_webcam streaming_maxpacket=3072
>> >>> - then run uvc-gadget to feed the YUV frames;
>> >>>  http://git.ideasonboard.org/uvc-gadget.git
>> >> 
>> >> as is, g_webcam never enumerates to the host. It's calls to
>> >> usb_function_active() and usb_function_deactivate() are unbalanced. Do
>> >> you have any other changes to g_webcam?
>> > 
>> > With uvc function gadget driver, user daemon uvc-gadget must be started
>> > before connect to host. Not sure whether g_webcam has same requirement.
>> 
>> f_uvc.c should be handling that by means for usb_function_deactivate().
>> 
>> I'll try keeping cable disconnected until uvc-gadget is running.
>
> Things might have changed since we've discussed the issue several years ago, 
> but back then at least the musb UDC started unconditionally connected.

That's kinda of not the case anymore. We deactivate during function
registration if a certain flag is set.

-- 
balbi


signature.asc
Description: PGP signature


Re: g_webcam Isoch high bandwidth transfer

2016-09-26 Thread Laurent Pinchart
Hi Felipe,

On Friday 23 Sep 2016 11:27:26 Felipe Balbi wrote:
> yfw  writes:
> >> Here's one that actually compiles, sorry about that.
> > 
> > No worries, I was sleeping ;-)
> > 
> > I will test it out early next week. Thanks.
>  
>  meanwhile, how about some instructions on how to test this out myself?
>  How are you using g_webcam and what are you running on host side? Got a
>  nice list of commands there I can use? I think I can get to bottom of
>  this much quicker if I can reproduce it locally ;-)
> >>> 
> >>> On device side:
> >>> - first patch g_webcam as in my first email in this thread to enable
> >>>   640x480@30fps;
> >>> - # modprobe g_webcam streaming_maxpacket=3072
> >>> - then run uvc-gadget to feed the YUV frames;
> >>>   http://git.ideasonboard.org/uvc-gadget.git
> >> 
> >> as is, g_webcam never enumerates to the host. It's calls to
> >> usb_function_active() and usb_function_deactivate() are unbalanced. Do
> >> you have any other changes to g_webcam?
> > 
> > With uvc function gadget driver, user daemon uvc-gadget must be started
> > before connect to host. Not sure whether g_webcam has same requirement.
> 
> f_uvc.c should be handling that by means for usb_function_deactivate().
> 
> I'll try keeping cable disconnected until uvc-gadget is running.

Things might have changed since we've discussed the issue several years ago, 
but back then at least the musb UDC started unconditionally connected.

-- 
Regards,

Laurent Pinchart

--
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: g_webcam Isoch high bandwidth transfer

2016-09-26 Thread Laurent Pinchart
Hi Felipe,

On Friday 23 Sep 2016 10:49:57 Felipe Balbi wrote:
> Bin Liu  writes:
> > +Fengwei Yin per his request.
> > 
> > On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
> >> Bin Liu  writes:
> >> 
> >> [...]
> >> 
>  Here's one that actually compiles, sorry about that.
> >>> 
> >>> No worries, I was sleeping ;-)
> >>> 
> >>> I will test it out early next week. Thanks.
> >> 
> >> meanwhile, how about some instructions on how to test this out myself?
> >> How are you using g_webcam and what are you running on host side? Got a
> >> nice list of commands there I can use? I think I can get to bottom of
> >> this much quicker if I can reproduce it locally ;-)
> > 
> > On device side:
> > - first patch g_webcam as in my first email in this thread to enable
> > 
> >   640x480@30fps;
> > 
> > - # modprobe g_webcam streaming_maxpacket=3072
> > - then run uvc-gadget to feed the YUV frames;
> > 
> > http://git.ideasonboard.org/uvc-gadget.git
> 
> as is, g_webcam never enumerates to the host. It's calls to
> usb_function_active() and usb_function_deactivate() are unbalanced. Do
> you have any other changes to g_webcam?
> 
> Also, uvc-gadget.git doesn't compile, had to modify it a bit:
> 
> -#include "../drivers/usb/gadget/uvc.h"
> +#include "../drivers/usb/gadget/function/uvc.h"
> 
> Also fixed a build warning:
> 
> @@ -732,6 +732,8 @@ int main(int argc, char *argv[])
> fd_set wfds = fds;
> 
> ret = select(dev->fd + 1, NULL, , , NULL);
> +   if (ret < 0)
> +   return ret;
> if (FD_ISSET(dev->fd, ))
> uvc_events_process(dev);
> if (FD_ISSET(dev->fd, ))
> 
> Laurent, have you tested g_webcam recently? What's the magic to get it
> working?

I'm afraid not, I haven't had time to work on UVC gadget for a few years now.

> Here's what I get out of dmesg:
> 
> [   58.568380] usb 1-9: new high-speed USB device number 5 using xhci_hcd
> [   58.738680] usb 1-9: New USB device found, idVendor=1d6b, idProduct=0102
> [   58.738683] usb 1-9: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0 [   58.738685] usb 1-9: Product: Webcam gadget
> [   58.738687] usb 1-9: Manufacturer: Linux Foundation
> [   58.739133] g_webcam gadget: high-speed config #1: Video
> [   58.739138] g_webcam gadget: uvc_function_set_alt(0, 0)
> [   58.739139] g_webcam gadget: reset UVC Control
> [   58.739149] g_webcam gadget: uvc_function_set_alt(1, 0)
> [   58.804369] uvcvideo: Found UVC 1.00 device Webcam gadget (1d6b:0102)
> [   58.804479] g_webcam gadget: uvc_function_set_alt(1, 0)
> [   64.188459] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported.
> Enabling workaround. [   69.307458] uvcvideo: Failed to query (129) UVC
> probe control : -110 (exp. 26). [   69.307459] uvcvideo: Failed to
> initialize the device (-5).
> [   69.307505] usbcore: registered new interface driver uvcvideo
> [   69.307506] USB Video Class driver (1.1.1)
> [  146.646012] [ cut here ]
> [  146.646023] WARNING: CPU: 0 PID: 2616 at
> drivers/usb/gadget/composite.c:371 usb_function_activate+0x77/0x80
> [libcomposite] [  146.646024] Modules linked in: uvcvideo g_webcam
> usb_f_uvc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
> videodev libcomposite kvm_intel kvm psmouse e1000e input_leds hid_generic
> usbhid atkbd irqbypass evdev [  146.646054] CPU: 0 PID: 2616 Comm:
> gst-launch-1.0 Not tainted
> 4.8.0-rc7-next-20160922-4-gc71031593917-dirty #20 [  146.646055]
> Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3
> RVP3, BIOS SKLSE2R1.R00.B097.B02.1509020030 09/02/2015 [  146.646058] 
> c9000769bb70
> [  146.646059]  8132d415
> [  146.646060]  
> [  146.646061]  
> 
> [  146.646063]  c9000769bbb0
> [  146.646063]  8105ec1b
> [  146.646064]  01730769bb90
> [  146.646066]  ffea
> [  146.646070]  88016c03a150
> [  146.646072]  0282 88016d793000 c9000769befc
> [  146.646077] Call Trace:
> [  146.646086]  [] dump_stack+0x68/0x93
> [  146.646090]  [] __warn+0xcb/0xf0
> [  146.646095]  [] warn_slowpath_null+0x1d/0x20
> [  146.646099]  [] usb_function_activate+0x77/0x80
> [libcomposite] [  146.646105]  []
> uvc_function_connect+0x1e/0x40 [usb_f_uvc] [  146.646110] 
> [] uvc_v4l2_open+0x6e/0x80 [usb_f_uvc] [  146.646116] 
> [] v4l2_open+0xa0/0x100 [videodev] [  146.646121] 
> [] chrdev_open+0xa1/0x1d0
> [  146.646125]  [] ? cdev_put+0x30/0x30
> [  146.646129]  [] do_dentry_open.isra.17+0x150/0x2e0
> [  146.646133]  [] vfs_open+0x45/0x60
> [  146.646137]  [] path_openat+0x62d/0x1370
> [  146.646141]  [] ? putname+0x54/0x60
> [  146.646146]  [] do_filp_open+0x7e/0xe0
> [  146.646150]  [] ? preempt_count_sub+0x48/0x70
> [  146.646154]  [] ? _raw_spin_unlock+0x16/0x30
> [  146.646160]  [] ? __alloc_fd+0xc9/0x180
> [  146.646164]  [] 

Re: g_webcam Isoch high bandwidth transfer

2016-09-26 Thread Bin Liu
On Fri, Sep 23, 2016 at 10:49:57AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> > +Fengwei Yin per his request.
> >
> > On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
> >> 
> >> Hi,
> >> 
> >> Bin Liu  writes:
> >> 
> >> [...]
> >> 
> >> >> Here's one that actually compiles, sorry about that.
> >> >
> >> > No worries, I was sleeping ;-)
> >> >
> >> > I will test it out early next week. Thanks.
> >> 
> >> meanwhile, how about some instructions on how to test this out myself?
> >> How are you using g_webcam and what are you running on host side? Got a
> >> nice list of commands there I can use? I think I can get to bottom of
> >> this much quicker if I can reproduce it locally ;-)
> >
> > On device side:
> > - first patch g_webcam as in my first email in this thread to enable
> >   640x480@30fps;
> > - # modprobe g_webcam streaming_maxpacket=3072
> > - then run uvc-gadget to feed the YUV frames;
> > http://git.ideasonboard.org/uvc-gadget.git
> 
> as is, g_webcam never enumerates to the host. It's calls to

Right, on mainline kernel (I tested 4.8.0-rc7) g_webcam is broken with
DWC3, g_webcam does not enumerate on the host. But it works on v4.4.21.

[snip]

> 
> uvc-gadget keeps printing this error message:
> 
>  159 if ((ret = ioctl(dev->fd, VIDIOC_DQBUF, )) < 0) {
>  160 printf("Unable to dequeue buffer: %s (%d).\n", 
> strerror(errno),
>  161 errno);
>  162 return ret;
>  163 }

I removed this printf, since it floods the console if start uvc-gadget
before connect to the host.

BTY, you don't have to start uvc-gadget first then connect usb cable. I
keep the cable always connected.

Regards,
-Bin.
--
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: g_webcam Isoch high bandwidth transfer

2016-09-23 Thread Felipe Balbi

Hi,

yfw  writes:
>> Here's one that actually compiles, sorry about that.
>
> No worries, I was sleeping ;-)
>
> I will test it out early next week. Thanks.

 meanwhile, how about some instructions on how to test this out myself?
 How are you using g_webcam and what are you running on host side? Got a
 nice list of commands there I can use? I think I can get to bottom of
 this much quicker if I can reproduce it locally ;-)
>>>
>>> On device side:
>>> - first patch g_webcam as in my first email in this thread to enable
>>>   640x480@30fps;
>>> - # modprobe g_webcam streaming_maxpacket=3072
>>> - then run uvc-gadget to feed the YUV frames;
>>> http://git.ideasonboard.org/uvc-gadget.git
>>
>> as is, g_webcam never enumerates to the host. It's calls to
>> usb_function_active() and usb_function_deactivate() are unbalanced. Do
>> you have any other changes to g_webcam?
> With uvc function gadget driver, user daemon uvc-gadget must be started
> before connect to host. Not sure whether g_webcam has same requirement.

f_uvc.c should be handling that by means for usb_function_deactivate().

I'll try keeping cable disconnected until uvc-gadget is running.

>> Also, uvc-gadget.git doesn't compile, had to modify it a bit:
>>
>> -#include "../drivers/usb/gadget/uvc.h"
>> +#include "../drivers/usb/gadget/function/uvc.h"
>>
>> Also fixed a build warning:
>>
>> @@ -732,6 +732,8 @@ int main(int argc, char *argv[])
>> fd_set wfds = fds;
>>
>> ret = select(dev->fd + 1, NULL, , , NULL);
>> +   if (ret < 0)
>> +   return ret;
>> if (FD_ISSET(dev->fd, ))
>> uvc_events_process(dev);
>> if (FD_ISSET(dev->fd, ))
>>
>> Laurent, have you tested g_webcam recently? What's the magic to get it
>> working?
>>
>> Here's what I get out of dmesg:
>>
>> [   58.568380] usb 1-9: new high-speed USB device number 5 using xhci_hcd
>> [   58.738680] usb 1-9: New USB device found, idVendor=1d6b, idProduct=0102
>> [   58.738683] usb 1-9: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=0
>> [   58.738685] usb 1-9: Product: Webcam gadget
>> [   58.738687] usb 1-9: Manufacturer: Linux Foundation
>> [   58.739133] g_webcam gadget: high-speed config #1: Video
>> [   58.739138] g_webcam gadget: uvc_function_set_alt(0, 0)
>> [   58.739139] g_webcam gadget: reset UVC Control
>> [   58.739149] g_webcam gadget: uvc_function_set_alt(1, 0)
>> [   58.804369] uvcvideo: Found UVC 1.00 device Webcam gadget (1d6b:0102)
>> [   58.804479] g_webcam gadget: uvc_function_set_alt(1, 0)
>> [   64.188459] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. 
>> Enabling workaround.
> Looks like you connect your usb device to your usb host port on same
> board. Nice.

yeah, that helps.

> The GET_DEF is handled by user daemon uvc-gadget. It may be related.

okay.

-- 
balbi


signature.asc
Description: PGP signature


Re: g_webcam Isoch high bandwidth transfer

2016-09-23 Thread yfw

Hi Felipe,

On 2016/9/23 15:49, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

+Fengwei Yin per his request.

On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

[...]


Here's one that actually compiles, sorry about that.


No worries, I was sleeping ;-)

I will test it out early next week. Thanks.


meanwhile, how about some instructions on how to test this out myself?
How are you using g_webcam and what are you running on host side? Got a
nice list of commands there I can use? I think I can get to bottom of
this much quicker if I can reproduce it locally ;-)


On device side:
- first patch g_webcam as in my first email in this thread to enable
  640x480@30fps;
- # modprobe g_webcam streaming_maxpacket=3072
- then run uvc-gadget to feed the YUV frames;
http://git.ideasonboard.org/uvc-gadget.git


as is, g_webcam never enumerates to the host. It's calls to
usb_function_active() and usb_function_deactivate() are unbalanced. Do
you have any other changes to g_webcam?

With uvc function gadget driver, user daemon uvc-gadget must be started
before connect to host. Not sure whether g_webcam has same requirement.



Also, uvc-gadget.git doesn't compile, had to modify it a bit:

-#include "../drivers/usb/gadget/uvc.h"
+#include "../drivers/usb/gadget/function/uvc.h"

Also fixed a build warning:

@@ -732,6 +732,8 @@ int main(int argc, char *argv[])
fd_set wfds = fds;

ret = select(dev->fd + 1, NULL, , , NULL);
+   if (ret < 0)
+   return ret;
if (FD_ISSET(dev->fd, ))
uvc_events_process(dev);
if (FD_ISSET(dev->fd, ))

Laurent, have you tested g_webcam recently? What's the magic to get it
working?

Here's what I get out of dmesg:

[   58.568380] usb 1-9: new high-speed USB device number 5 using xhci_hcd
[   58.738680] usb 1-9: New USB device found, idVendor=1d6b, idProduct=0102
[   58.738683] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   58.738685] usb 1-9: Product: Webcam gadget
[   58.738687] usb 1-9: Manufacturer: Linux Foundation
[   58.739133] g_webcam gadget: high-speed config #1: Video
[   58.739138] g_webcam gadget: uvc_function_set_alt(0, 0)
[   58.739139] g_webcam gadget: reset UVC Control
[   58.739149] g_webcam gadget: uvc_function_set_alt(1, 0)
[   58.804369] uvcvideo: Found UVC 1.00 device Webcam gadget (1d6b:0102)
[   58.804479] g_webcam gadget: uvc_function_set_alt(1, 0)
[   64.188459] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. 
Enabling workaround.

Looks like you connect your usb device to your usb host port on same
board. Nice.

The GET_DEF is handled by user daemon uvc-gadget. It may be related.

Regards
Yin, Fengwei


[   69.307458] uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 
26).
[   69.307459] uvcvideo: Failed to initialize the device (-5).
[   69.307505] usbcore: registered new interface driver uvcvideo
[   69.307506] USB Video Class driver (1.1.1)
[  146.646012] [ cut here ]
[  146.646023] WARNING: CPU: 0 PID: 2616 at drivers/usb/gadget/composite.c:371 
usb_function_activate+0x77/0x80 [libcomposite]
[  146.646024] Modules linked in: uvcvideo g_webcam usb_f_uvc videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_core videodev libcomposite kvm_intel 
kvm psmouse e1000e input_leds hid_generic usbhid atkbd irqbypass evdev
[  146.646054] CPU: 0 PID: 2616 Comm: gst-launch-1.0 Not tainted 
4.8.0-rc7-next-20160922-4-gc71031593917-dirty #20
[  146.646055] Hardware name: Intel Corporation Skylake Client platform/Skylake 
Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B097.B02.1509020030 09/02/2015
[  146.646058]  c9000769bb70
[  146.646059]  8132d415
[  146.646060]  
[  146.646061]  

[  146.646063]  c9000769bbb0
[  146.646063]  8105ec1b
[  146.646064]  01730769bb90
[  146.646066]  ffea
[  146.646070]  88016c03a150
[  146.646072]  0282 88016d793000 c9000769befc
[  146.646077] Call Trace:
[  146.646086]  [] dump_stack+0x68/0x93
[  146.646090]  [] __warn+0xcb/0xf0
[  146.646095]  [] warn_slowpath_null+0x1d/0x20
[  146.646099]  [] usb_function_activate+0x77/0x80 
[libcomposite]
[  146.646105]  [] uvc_function_connect+0x1e/0x40 [usb_f_uvc]
[  146.646110]  [] uvc_v4l2_open+0x6e/0x80 [usb_f_uvc]
[  146.646116]  [] v4l2_open+0xa0/0x100 [videodev]
[  146.646121]  [] chrdev_open+0xa1/0x1d0
[  146.646125]  [] ? cdev_put+0x30/0x30
[  146.646129]  [] do_dentry_open.isra.17+0x150/0x2e0
[  146.646133]  [] vfs_open+0x45/0x60
[  146.646137]  [] path_openat+0x62d/0x1370
[  146.646141]  [] ? putname+0x54/0x60
[  146.646146]  [] do_filp_open+0x7e/0xe0
[  146.646150]  [] ? preempt_count_sub+0x48/0x70
[  146.646154]  [] ? _raw_spin_unlock+0x16/0x30
[  146.646160]  [] ? __alloc_fd+0xc9/0x180
[  146.646164]  [] do_sys_open+0x123/0x200
[  146.646170]  [] 

Re: g_webcam Isoch high bandwidth transfer

2016-09-23 Thread Felipe Balbi

Hi,

Bin Liu  writes:
> +Fengwei Yin per his request.
>
> On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Bin Liu  writes:
>> 
>> [...]
>> 
>> >> Here's one that actually compiles, sorry about that.
>> >
>> > No worries, I was sleeping ;-)
>> >
>> > I will test it out early next week. Thanks.
>> 
>> meanwhile, how about some instructions on how to test this out myself?
>> How are you using g_webcam and what are you running on host side? Got a
>> nice list of commands there I can use? I think I can get to bottom of
>> this much quicker if I can reproduce it locally ;-)
>
> On device side:
> - first patch g_webcam as in my first email in this thread to enable
>   640x480@30fps;
> - # modprobe g_webcam streaming_maxpacket=3072
> - then run uvc-gadget to feed the YUV frames;
>   http://git.ideasonboard.org/uvc-gadget.git

as is, g_webcam never enumerates to the host. It's calls to
usb_function_active() and usb_function_deactivate() are unbalanced. Do
you have any other changes to g_webcam?

Also, uvc-gadget.git doesn't compile, had to modify it a bit:

-#include "../drivers/usb/gadget/uvc.h"
+#include "../drivers/usb/gadget/function/uvc.h"

Also fixed a build warning:

@@ -732,6 +732,8 @@ int main(int argc, char *argv[])
fd_set wfds = fds;
 
ret = select(dev->fd + 1, NULL, , , NULL);
+   if (ret < 0)
+   return ret;
if (FD_ISSET(dev->fd, ))
uvc_events_process(dev);
if (FD_ISSET(dev->fd, ))

Laurent, have you tested g_webcam recently? What's the magic to get it
working?

Here's what I get out of dmesg:

[   58.568380] usb 1-9: new high-speed USB device number 5 using xhci_hcd
[   58.738680] usb 1-9: New USB device found, idVendor=1d6b, idProduct=0102
[   58.738683] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   58.738685] usb 1-9: Product: Webcam gadget
[   58.738687] usb 1-9: Manufacturer: Linux Foundation
[   58.739133] g_webcam gadget: high-speed config #1: Video
[   58.739138] g_webcam gadget: uvc_function_set_alt(0, 0)
[   58.739139] g_webcam gadget: reset UVC Control
[   58.739149] g_webcam gadget: uvc_function_set_alt(1, 0)
[   58.804369] uvcvideo: Found UVC 1.00 device Webcam gadget (1d6b:0102)
[   58.804479] g_webcam gadget: uvc_function_set_alt(1, 0)
[   64.188459] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. 
Enabling workaround.
[   69.307458] uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 
26).
[   69.307459] uvcvideo: Failed to initialize the device (-5).
[   69.307505] usbcore: registered new interface driver uvcvideo
[   69.307506] USB Video Class driver (1.1.1)
[  146.646012] [ cut here ]
[  146.646023] WARNING: CPU: 0 PID: 2616 at drivers/usb/gadget/composite.c:371 
usb_function_activate+0x77/0x80 [libcomposite]
[  146.646024] Modules linked in: uvcvideo g_webcam usb_f_uvc videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_core videodev libcomposite kvm_intel 
kvm psmouse e1000e input_leds hid_generic usbhid atkbd irqbypass evdev
[  146.646054] CPU: 0 PID: 2616 Comm: gst-launch-1.0 Not tainted 
4.8.0-rc7-next-20160922-4-gc71031593917-dirty #20
[  146.646055] Hardware name: Intel Corporation Skylake Client platform/Skylake 
Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B097.B02.1509020030 09/02/2015
[  146.646058]  c9000769bb70
[  146.646059]  8132d415
[  146.646060]  
[  146.646061]  

[  146.646063]  c9000769bbb0
[  146.646063]  8105ec1b
[  146.646064]  01730769bb90
[  146.646066]  ffea
[  146.646070]  88016c03a150
[  146.646072]  0282 88016d793000 c9000769befc
[  146.646077] Call Trace:
[  146.646086]  [] dump_stack+0x68/0x93
[  146.646090]  [] __warn+0xcb/0xf0
[  146.646095]  [] warn_slowpath_null+0x1d/0x20
[  146.646099]  [] usb_function_activate+0x77/0x80 
[libcomposite]
[  146.646105]  [] uvc_function_connect+0x1e/0x40 [usb_f_uvc]
[  146.646110]  [] uvc_v4l2_open+0x6e/0x80 [usb_f_uvc]
[  146.646116]  [] v4l2_open+0xa0/0x100 [videodev]
[  146.646121]  [] chrdev_open+0xa1/0x1d0
[  146.646125]  [] ? cdev_put+0x30/0x30
[  146.646129]  [] do_dentry_open.isra.17+0x150/0x2e0
[  146.646133]  [] vfs_open+0x45/0x60
[  146.646137]  [] path_openat+0x62d/0x1370
[  146.646141]  [] ? putname+0x54/0x60
[  146.646146]  [] do_filp_open+0x7e/0xe0
[  146.646150]  [] ? preempt_count_sub+0x48/0x70
[  146.646154]  [] ? _raw_spin_unlock+0x16/0x30
[  146.646160]  [] ? __alloc_fd+0xc9/0x180
[  146.646164]  [] do_sys_open+0x123/0x200
[  146.646170]  [] SyS_open+0x1e/0x20
[  146.646174]  [] entry_SYSCALL_64_fastpath+0x18/0xa8
[  146.646177] ---[ end trace 1a4f7b9817d19b04 ]---
[  146.646180] g_webcam gadget: UVC connect failed with -22
[  146.653808] usb 1-9: USB disconnect, device number 5
[  146.653986] g_webcam gadget: UVC disconnect failed with -110


And 

Re: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread yfw

Hi Bin,

On 2016/9/23 4:11, Bin Liu wrote:

+Fengwei Yin per his request.

Thanks a lot for adding me to this thread.



On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

[...]


Here's one that actually compiles, sorry about that.


No worries, I was sleeping ;-)

I will test it out early next week. Thanks.


meanwhile, how about some instructions on how to test this out myself?
How are you using g_webcam and what are you running on host side? Got a
nice list of commands there I can use? I think I can get to bottom of
this much quicker if I can reproduce it locally ;-)

I am using similar use case with a different gadget function driver.


On device side:
- first patch g_webcam as in my first email in this thread to enable
  640x480@30fps;
- # modprobe g_webcam streaming_maxpacket=3072
- then run uvc-gadget to feed the YUV frames;
http://git.ideasonboard.org/uvc-gadget.git

- I am using uvc function driver  + configfs.
- maxpacket in configfs was set to 3072.
- uvc-gadget from the same source as Bin.


On host side:
- first check the device ep descriptor, which should be
wMaxPacketSize 0x1400  3x 1024 bytes
- then use luvcview or yavta to capture the video stream

- lsusb give me same wMaxPacketSize.
- I am using example (changed a little bit) from libuvc.

Regards
Yin, Fengwei



Capture the bus trace to check if multiple IN transactions happens in
each SOF.

The data buffer size in the usb_request coming from the uvc driver is
5120 bytes, so there should be 3 IN transactions if the UDC works
correctly.

Regards,
-Bin.


--
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: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Bin Liu
+Fengwei Yin per his request.

On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> 
> [...]
> 
> >> Here's one that actually compiles, sorry about that.
> >
> > No worries, I was sleeping ;-)
> >
> > I will test it out early next week. Thanks.
> 
> meanwhile, how about some instructions on how to test this out myself?
> How are you using g_webcam and what are you running on host side? Got a
> nice list of commands there I can use? I think I can get to bottom of
> this much quicker if I can reproduce it locally ;-)

On device side:
- first patch g_webcam as in my first email in this thread to enable
  640x480@30fps;
- # modprobe g_webcam streaming_maxpacket=3072
- then run uvc-gadget to feed the YUV frames;
http://git.ideasonboard.org/uvc-gadget.git

On host side:
- first check the device ep descriptor, which should be
wMaxPacketSize 0x1400  3x 1024 bytes
- then use luvcview or yavta to capture the video stream

Capture the bus trace to check if multiple IN transactions happens in
each SOF.

The data buffer size in the usb_request coming from the uvc driver is
5120 bytes, so there should be 3 IN transactions if the UDC works
correctly.

Regards,
-Bin.
--
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: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Bin Liu
On Thu, Sep 22, 2016 at 01:06:46PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Balbi  writes:
> > Felipe Balbi  writes:
> >> Bin Liu  writes:
> >>> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
>  
>  Hi,
>  
>  Bin Liu  writes:
>  > Hi,
>  >
>  > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
>  >  high-speed connection.
>  >
>  > First I hacked webcam.c as follows to enable 640x480@30fps mode.
>  >
>  > diff --git a/drivers/usb/gadget/legacy/webcam.c 
>  > b/drivers/usb/gadget/legacy/webcam.c
>  > index 72c976b..9eb315f 100644
>  > --- a/drivers/usb/gadget/legacy/webcam.c
>  > +++ b/drivers/usb/gadget/legacy/webcam.c
>  > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
>  > uvc_frame_yuv_360p = {
>  > .bFrameIndex= 1,
>  > .bmCapabilities = 0,
>  > .wWidth = cpu_to_le16(640),
>  > -   .wHeight= cpu_to_le16(360),
>  > +   .wHeight= cpu_to_le16(480),
>  > .dwMinBitRate   = cpu_to_le32(18432000),
>  > .dwMaxBitRate   = cpu_to_le32(55296000),
>  > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
>  > -   .dwDefaultFrameInterval = cpu_to_le32(66),
>  > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
>  > +   .dwDefaultFrameInterval = cpu_to_le32(33),
>  > .bFrameIntervalType = 3,
>  > -   .dwFrameInterval[0] = cpu_to_le32(66),
>  > -   .dwFrameInterval[1] = cpu_to_le32(100),
>  > -   .dwFrameInterval[2] = cpu_to_le32(500),
>  > +   .dwFrameInterval[0] = cpu_to_le32(33),
>  > +   .dwFrameInterval[1] = cpu_to_le32(66),
>  > +   .dwFrameInterval[2] = cpu_to_le32(100),
>  >  };
>  >
>  > then loaded g_webcam.ko as
>  >
>  > # modprobe g_webcam streaming_maxpacket=3072
>  >
>  > The endpoint descriptor showing on the host is
>  >
>  >   Endpoint Descriptor:
>  > bLength 7
>  > bDescriptorType 5
>  > bEndpointAddress 0x8d  EP 13 IN
>  > bmAttributes5
>  >   Transfer TypeIsochronous
>  >   Synch Type   Asynchronous
>  >   Usage Type   Data
>  > wMaxPacketSize 0x1400  3x 1024 bytes
>  > bInterval   1
>  >
>  > However the usb bus trace shows only one transaction with 1024-bytes 
>  > packet in
>  > every SOF. The host only sends one IN packet in every SOF, I am 
>  > expecting 2~3
>  > 1024-bytes transactions, since this would be required to transfer 
>  > 640x480@30fps
>  > YUV frames in high-speed.
>  >
>  > DId I miss anything in the setup?
>  
>  MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
> >>>
> >>> Happened on both MUSB and DWC3.
> >>>
>  of your bus analyzer? When host sends IN token, are you replying with
> >>>
> >>> The trace screenshot on DWC3 is attached.
> >>>
>  DATA0, DATA1 or DATA2?
> >>>
> >>> Good hint! It is DATA0!
> >>
> >> yeah, should've been DATA2. I'll check if we're missing anything for
> >> High Bandwidth Iso on DWC3. Can you confirm if it works of tails on
> >> DWC3? On your follow-up mail you mentioned it's a bug in MUSB. What
> >> about DWC3?
> >
> > I'm assuming DWC3 really breaks. Here's a patch for that:
> >
> > 8<-- cut here 
> > --
> > From 62807011c00055785575bb39d92bfe8836817e2f Mon Sep 17 00:00:00 2001
> > From: Felipe Balbi 
> > Date: Thu, 22 Sep 2016 11:01:01 +0300
> > Subject: [PATCH] usb: dwc3: gadget: set PCM1 field of isochronous-first TRBs
> >
> > In case of High-Speed, High-Bandwidth endpoints, we
> > need to tell DWC3 that we have more than one packet
> > per interval. We do that by setting PCM1 field of
> > Isochronous-First TRB.
> >
> > Signed-off-by: Felipe Balbi 
> > ---
> >  drivers/usb/dwc3/gadget.c | 14 --
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index 602f12254161..106623faf060 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -787,6 +787,9 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
> > unsigned length, unsigned chain, unsigned node)
> >  {
> > struct dwc3_trb *trb;
> > +   struct dwc3 *dwc = dep->dwc;
> > +   struct usb_gadget   *gadget = >gadget;
> > +   enum usb_device_speed   speed 

Re: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Felipe Balbi

Hi,

Felipe Balbi  writes:
> Felipe Balbi  writes:
>> Bin Liu  writes:
>>> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
 
 Hi,
 
 Bin Liu  writes:
 > Hi,
 >
 > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
 >  high-speed connection.
 >
 > First I hacked webcam.c as follows to enable 640x480@30fps mode.
 >
 > diff --git a/drivers/usb/gadget/legacy/webcam.c 
 > b/drivers/usb/gadget/legacy/webcam.c
 > index 72c976b..9eb315f 100644
 > --- a/drivers/usb/gadget/legacy/webcam.c
 > +++ b/drivers/usb/gadget/legacy/webcam.c
 > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
 > uvc_frame_yuv_360p = {
 > .bFrameIndex= 1,
 > .bmCapabilities = 0,
 > .wWidth = cpu_to_le16(640),
 > -   .wHeight= cpu_to_le16(360),
 > +   .wHeight= cpu_to_le16(480),
 > .dwMinBitRate   = cpu_to_le32(18432000),
 > .dwMaxBitRate   = cpu_to_le32(55296000),
 > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
 > -   .dwDefaultFrameInterval = cpu_to_le32(66),
 > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
 > +   .dwDefaultFrameInterval = cpu_to_le32(33),
 > .bFrameIntervalType = 3,
 > -   .dwFrameInterval[0] = cpu_to_le32(66),
 > -   .dwFrameInterval[1] = cpu_to_le32(100),
 > -   .dwFrameInterval[2] = cpu_to_le32(500),
 > +   .dwFrameInterval[0] = cpu_to_le32(33),
 > +   .dwFrameInterval[1] = cpu_to_le32(66),
 > +   .dwFrameInterval[2] = cpu_to_le32(100),
 >  };
 >
 > then loaded g_webcam.ko as
 >
 > # modprobe g_webcam streaming_maxpacket=3072
 >
 > The endpoint descriptor showing on the host is
 >
 >   Endpoint Descriptor:
 > bLength 7
 > bDescriptorType 5
 > bEndpointAddress 0x8d  EP 13 IN
 > bmAttributes5
 >   Transfer TypeIsochronous
 >   Synch Type   Asynchronous
 >   Usage Type   Data
 > wMaxPacketSize 0x1400  3x 1024 bytes
 > bInterval   1
 >
 > However the usb bus trace shows only one transaction with 1024-bytes 
 > packet in
 > every SOF. The host only sends one IN packet in every SOF, I am 
 > expecting 2~3
 > 1024-bytes transactions, since this would be required to transfer 
 > 640x480@30fps
 > YUV frames in high-speed.
 >
 > DId I miss anything in the setup?
 
 MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
>>>
>>> Happened on both MUSB and DWC3.
>>>
 of your bus analyzer? When host sends IN token, are you replying with
>>>
>>> The trace screenshot on DWC3 is attached.
>>>
 DATA0, DATA1 or DATA2?
>>>
>>> Good hint! It is DATA0!
>>
>> yeah, should've been DATA2. I'll check if we're missing anything for
>> High Bandwidth Iso on DWC3. Can you confirm if it works of tails on
>> DWC3? On your follow-up mail you mentioned it's a bug in MUSB. What
>> about DWC3?
>
> I'm assuming DWC3 really breaks. Here's a patch for that:
>
> 8<-- cut here 
> --
> From 62807011c00055785575bb39d92bfe8836817e2f Mon Sep 17 00:00:00 2001
> From: Felipe Balbi 
> Date: Thu, 22 Sep 2016 11:01:01 +0300
> Subject: [PATCH] usb: dwc3: gadget: set PCM1 field of isochronous-first TRBs
>
> In case of High-Speed, High-Bandwidth endpoints, we
> need to tell DWC3 that we have more than one packet
> per interval. We do that by setting PCM1 field of
> Isochronous-First TRB.
>
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/dwc3/gadget.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 602f12254161..106623faf060 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -787,6 +787,9 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
>   unsigned length, unsigned chain, unsigned node)
>  {
>   struct dwc3_trb *trb;
> + struct dwc3 *dwc = dep->dwc;
> + struct usb_gadget   *gadget = >gadget;
> + enum usb_device_speed   speed = speed;

and of course I sent the wrong version :-)

Here's one that actually compiles, sorry about that.

8<-- cut here --
From 44282f6c664b17e6b9dffbc31e72258be84823a4 Mon Sep 17 00:00:00 2001
From: Felipe Balbi 

Re: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Felipe Balbi

Hi,

Felipe Balbi  writes:
> Bin Liu  writes:
>> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
>>> 
>>> Hi,
>>> 
>>> Bin Liu  writes:
>>> > Hi,
>>> >
>>> > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
>>> >  high-speed connection.
>>> >
>>> > First I hacked webcam.c as follows to enable 640x480@30fps mode.
>>> >
>>> > diff --git a/drivers/usb/gadget/legacy/webcam.c 
>>> > b/drivers/usb/gadget/legacy/webcam.c
>>> > index 72c976b..9eb315f 100644
>>> > --- a/drivers/usb/gadget/legacy/webcam.c
>>> > +++ b/drivers/usb/gadget/legacy/webcam.c
>>> > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
>>> > uvc_frame_yuv_360p = {
>>> > .bFrameIndex= 1,
>>> > .bmCapabilities = 0,
>>> > .wWidth = cpu_to_le16(640),
>>> > -   .wHeight= cpu_to_le16(360),
>>> > +   .wHeight= cpu_to_le16(480),
>>> > .dwMinBitRate   = cpu_to_le32(18432000),
>>> > .dwMaxBitRate   = cpu_to_le32(55296000),
>>> > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
>>> > -   .dwDefaultFrameInterval = cpu_to_le32(66),
>>> > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
>>> > +   .dwDefaultFrameInterval = cpu_to_le32(33),
>>> > .bFrameIntervalType = 3,
>>> > -   .dwFrameInterval[0] = cpu_to_le32(66),
>>> > -   .dwFrameInterval[1] = cpu_to_le32(100),
>>> > -   .dwFrameInterval[2] = cpu_to_le32(500),
>>> > +   .dwFrameInterval[0] = cpu_to_le32(33),
>>> > +   .dwFrameInterval[1] = cpu_to_le32(66),
>>> > +   .dwFrameInterval[2] = cpu_to_le32(100),
>>> >  };
>>> >
>>> > then loaded g_webcam.ko as
>>> >
>>> > # modprobe g_webcam streaming_maxpacket=3072
>>> >
>>> > The endpoint descriptor showing on the host is
>>> >
>>> >   Endpoint Descriptor:
>>> > bLength 7
>>> > bDescriptorType 5
>>> > bEndpointAddress 0x8d  EP 13 IN
>>> > bmAttributes5
>>> >   Transfer TypeIsochronous
>>> >   Synch Type   Asynchronous
>>> >   Usage Type   Data
>>> > wMaxPacketSize 0x1400  3x 1024 bytes
>>> > bInterval   1
>>> >
>>> > However the usb bus trace shows only one transaction with 1024-bytes 
>>> > packet in
>>> > every SOF. The host only sends one IN packet in every SOF, I am expecting 
>>> > 2~3
>>> > 1024-bytes transactions, since this would be required to transfer 
>>> > 640x480@30fps
>>> > YUV frames in high-speed.
>>> >
>>> > DId I miss anything in the setup?
>>> 
>>> MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
>>
>> Happened on both MUSB and DWC3.
>>
>>> of your bus analyzer? When host sends IN token, are you replying with
>>
>> The trace screenshot on DWC3 is attached.
>>
>>> DATA0, DATA1 or DATA2?
>>
>> Good hint! It is DATA0!
>
> yeah, should've been DATA2. I'll check if we're missing anything for
> High Bandwidth Iso on DWC3. Can you confirm if it works of tails on
> DWC3? On your follow-up mail you mentioned it's a bug in MUSB. What
> about DWC3?

I'm assuming DWC3 really breaks. Here's a patch for that:

8<-- cut here --
From 62807011c00055785575bb39d92bfe8836817e2f Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Thu, 22 Sep 2016 11:01:01 +0300
Subject: [PATCH] usb: dwc3: gadget: set PCM1 field of isochronous-first TRBs

In case of High-Speed, High-Bandwidth endpoints, we
need to tell DWC3 that we have more than one packet
per interval. We do that by setting PCM1 field of
Isochronous-First TRB.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 602f12254161..106623faf060 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -787,6 +787,9 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
unsigned length, unsigned chain, unsigned node)
 {
struct dwc3_trb *trb;
+   struct dwc3 *dwc = dep->dwc;
+   struct usb_gadget   *gadget = >gadget;
+   enum usb_device_speed   speed = speed;
 
dwc3_trace(trace_dwc3_gadget, "%s: req %p dma %08llx length %d%s",
dep->name, req, (unsigned long long) dma,
@@ -813,10 +816,17 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
break;
 
case USB_ENDPOINT_XFER_ISOC:
-   if (!node)
+   if (!node) {
trb->ctrl = DWC3_TRBCTL_ISOCHRONOUS_FIRST;
-   else
+
+   if (speed == 

Re: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Felipe Balbi

Hi,

Bin Liu  writes:
> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Bin Liu  writes:
>> > Hi,
>> >
>> > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
>> >  high-speed connection.
>> >
>> > First I hacked webcam.c as follows to enable 640x480@30fps mode.
>> >
>> > diff --git a/drivers/usb/gadget/legacy/webcam.c 
>> > b/drivers/usb/gadget/legacy/webcam.c
>> > index 72c976b..9eb315f 100644
>> > --- a/drivers/usb/gadget/legacy/webcam.c
>> > +++ b/drivers/usb/gadget/legacy/webcam.c
>> > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
>> > uvc_frame_yuv_360p = {
>> > .bFrameIndex= 1,
>> > .bmCapabilities = 0,
>> > .wWidth = cpu_to_le16(640),
>> > -   .wHeight= cpu_to_le16(360),
>> > +   .wHeight= cpu_to_le16(480),
>> > .dwMinBitRate   = cpu_to_le32(18432000),
>> > .dwMaxBitRate   = cpu_to_le32(55296000),
>> > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
>> > -   .dwDefaultFrameInterval = cpu_to_le32(66),
>> > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
>> > +   .dwDefaultFrameInterval = cpu_to_le32(33),
>> > .bFrameIntervalType = 3,
>> > -   .dwFrameInterval[0] = cpu_to_le32(66),
>> > -   .dwFrameInterval[1] = cpu_to_le32(100),
>> > -   .dwFrameInterval[2] = cpu_to_le32(500),
>> > +   .dwFrameInterval[0] = cpu_to_le32(33),
>> > +   .dwFrameInterval[1] = cpu_to_le32(66),
>> > +   .dwFrameInterval[2] = cpu_to_le32(100),
>> >  };
>> >
>> > then loaded g_webcam.ko as
>> >
>> > # modprobe g_webcam streaming_maxpacket=3072
>> >
>> > The endpoint descriptor showing on the host is
>> >
>> >   Endpoint Descriptor:
>> > bLength 7
>> > bDescriptorType 5
>> > bEndpointAddress 0x8d  EP 13 IN
>> > bmAttributes5
>> >   Transfer TypeIsochronous
>> >   Synch Type   Asynchronous
>> >   Usage Type   Data
>> > wMaxPacketSize 0x1400  3x 1024 bytes
>> > bInterval   1
>> >
>> > However the usb bus trace shows only one transaction with 1024-bytes 
>> > packet in
>> > every SOF. The host only sends one IN packet in every SOF, I am expecting 
>> > 2~3
>> > 1024-bytes transactions, since this would be required to transfer 
>> > 640x480@30fps
>> > YUV frames in high-speed.
>> >
>> > DId I miss anything in the setup?
>> 
>> MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
>
> Happened on both MUSB and DWC3.
>
>> of your bus analyzer? When host sends IN token, are you replying with
>
> The trace screenshot on DWC3 is attached.
>
>> DATA0, DATA1 or DATA2?
>
> Good hint! It is DATA0!

yeah, should've been DATA2. I'll check if we're missing anything for
High Bandwidth Iso on DWC3. Can you confirm if it works of tails on
DWC3? On your follow-up mail you mentioned it's a bug in MUSB. What
about DWC3?

-- 
balbi


signature.asc
Description: PGP signature


Re: g_webcam Isoch high bandwidth transfer

2016-09-21 Thread Bin Liu
On Wed, Sep 21, 2016 at 08:27:02AM -0500, Bin Liu wrote:
> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
> > 
> > Hi,
> > 
> > Bin Liu  writes:
> > > Hi,
> > >
> > > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
> > >  high-speed connection.
> > >
> > > First I hacked webcam.c as follows to enable 640x480@30fps mode.
> > >
> > > diff --git a/drivers/usb/gadget/legacy/webcam.c 
> > > b/drivers/usb/gadget/legacy/webcam.c
> > > index 72c976b..9eb315f 100644
> > > --- a/drivers/usb/gadget/legacy/webcam.c
> > > +++ b/drivers/usb/gadget/legacy/webcam.c
> > > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
> > > uvc_frame_yuv_360p = {
> > > .bFrameIndex= 1,
> > > .bmCapabilities = 0,
> > > .wWidth = cpu_to_le16(640),
> > > -   .wHeight= cpu_to_le16(360),
> > > +   .wHeight= cpu_to_le16(480),
> > > .dwMinBitRate   = cpu_to_le32(18432000),
> > > .dwMaxBitRate   = cpu_to_le32(55296000),
> > > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
> > > -   .dwDefaultFrameInterval = cpu_to_le32(66),
> > > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
> > > +   .dwDefaultFrameInterval = cpu_to_le32(33),
> > > .bFrameIntervalType = 3,
> > > -   .dwFrameInterval[0] = cpu_to_le32(66),
> > > -   .dwFrameInterval[1] = cpu_to_le32(100),
> > > -   .dwFrameInterval[2] = cpu_to_le32(500),
> > > +   .dwFrameInterval[0] = cpu_to_le32(33),
> > > +   .dwFrameInterval[1] = cpu_to_le32(66),
> > > +   .dwFrameInterval[2] = cpu_to_le32(100),
> > >  };
> > >
> > > then loaded g_webcam.ko as
> > >
> > > # modprobe g_webcam streaming_maxpacket=3072
> > >
> > > The endpoint descriptor showing on the host is
> > >
> > >   Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x8d  EP 13 IN
> > > bmAttributes5
> > >   Transfer TypeIsochronous
> > >   Synch Type   Asynchronous
> > >   Usage Type   Data
> > > wMaxPacketSize 0x1400  3x 1024 bytes
> > > bInterval   1
> > >
> > > However the usb bus trace shows only one transaction with 1024-bytes 
> > > packet in
> > > every SOF. The host only sends one IN packet in every SOF, I am expecting 
> > > 2~3
> > > 1024-bytes transactions, since this would be required to transfer 
> > > 640x480@30fps
> > > YUV frames in high-speed.
> > >
> > > DId I miss anything in the setup?
> > 
> > MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
> 
> Happened on both MUSB and DWC3.

Indeed, it is MUSB gadget driver problem.

> 
> > of your bus analyzer? When host sends IN token, are you replying with
> 
> The trace screenshot on DWC3 is attached.
> 
> > DATA0, DATA1 or DATA2?
> 
> Good hint! It is DATA0!
> 
> > 
> > -- 
> > balbi
> 
> Regards,
> -Bin.


--
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: g_webcam Isoch high bandwidth transfer

2016-09-21 Thread Bin Liu
On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> > Hi,
> >
> > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
> >  high-speed connection.
> >
> > First I hacked webcam.c as follows to enable 640x480@30fps mode.
> >
> > diff --git a/drivers/usb/gadget/legacy/webcam.c 
> > b/drivers/usb/gadget/legacy/webcam.c
> > index 72c976b..9eb315f 100644
> > --- a/drivers/usb/gadget/legacy/webcam.c
> > +++ b/drivers/usb/gadget/legacy/webcam.c
> > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
> > uvc_frame_yuv_360p = {
> > .bFrameIndex= 1,
> > .bmCapabilities = 0,
> > .wWidth = cpu_to_le16(640),
> > -   .wHeight= cpu_to_le16(360),
> > +   .wHeight= cpu_to_le16(480),
> > .dwMinBitRate   = cpu_to_le32(18432000),
> > .dwMaxBitRate   = cpu_to_le32(55296000),
> > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
> > -   .dwDefaultFrameInterval = cpu_to_le32(66),
> > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
> > +   .dwDefaultFrameInterval = cpu_to_le32(33),
> > .bFrameIntervalType = 3,
> > -   .dwFrameInterval[0] = cpu_to_le32(66),
> > -   .dwFrameInterval[1] = cpu_to_le32(100),
> > -   .dwFrameInterval[2] = cpu_to_le32(500),
> > +   .dwFrameInterval[0] = cpu_to_le32(33),
> > +   .dwFrameInterval[1] = cpu_to_le32(66),
> > +   .dwFrameInterval[2] = cpu_to_le32(100),
> >  };
> >
> > then loaded g_webcam.ko as
> >
> > # modprobe g_webcam streaming_maxpacket=3072
> >
> > The endpoint descriptor showing on the host is
> >
> >   Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x8d  EP 13 IN
> > bmAttributes5
> >   Transfer TypeIsochronous
> >   Synch Type   Asynchronous
> >   Usage Type   Data
> > wMaxPacketSize 0x1400  3x 1024 bytes
> > bInterval   1
> >
> > However the usb bus trace shows only one transaction with 1024-bytes packet 
> > in
> > every SOF. The host only sends one IN packet in every SOF, I am expecting 
> > 2~3
> > 1024-bytes transactions, since this would be required to transfer 
> > 640x480@30fps
> > YUV frames in high-speed.
> >
> > DId I miss anything in the setup?
> 
> MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot

Happened on both MUSB and DWC3.

> of your bus analyzer? When host sends IN token, are you replying with

The trace screenshot on DWC3 is attached.

> DATA0, DATA1 or DATA2?

Good hint! It is DATA0!

> 
> -- 
> balbi

Regards,
-Bin.


Re: g_webcam Isoch high bandwidth transfer

2016-09-21 Thread Felipe Balbi

Hi,

Bin Liu  writes:
> Hi,
>
> I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
>  high-speed connection.
>
> First I hacked webcam.c as follows to enable 640x480@30fps mode.
>
> diff --git a/drivers/usb/gadget/legacy/webcam.c 
> b/drivers/usb/gadget/legacy/webcam.c
> index 72c976b..9eb315f 100644
> --- a/drivers/usb/gadget/legacy/webcam.c
> +++ b/drivers/usb/gadget/legacy/webcam.c
> @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
> uvc_frame_yuv_360p = {
> .bFrameIndex= 1,
> .bmCapabilities = 0,
> .wWidth = cpu_to_le16(640),
> -   .wHeight= cpu_to_le16(360),
> +   .wHeight= cpu_to_le16(480),
> .dwMinBitRate   = cpu_to_le32(18432000),
> .dwMaxBitRate   = cpu_to_le32(55296000),
> -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
> -   .dwDefaultFrameInterval = cpu_to_le32(66),
> +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
> +   .dwDefaultFrameInterval = cpu_to_le32(33),
> .bFrameIntervalType = 3,
> -   .dwFrameInterval[0] = cpu_to_le32(66),
> -   .dwFrameInterval[1] = cpu_to_le32(100),
> -   .dwFrameInterval[2] = cpu_to_le32(500),
> +   .dwFrameInterval[0] = cpu_to_le32(33),
> +   .dwFrameInterval[1] = cpu_to_le32(66),
> +   .dwFrameInterval[2] = cpu_to_le32(100),
>  };
>
> then loaded g_webcam.ko as
>
> # modprobe g_webcam streaming_maxpacket=3072
>
> The endpoint descriptor showing on the host is
>
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x8d  EP 13 IN
> bmAttributes5
>   Transfer TypeIsochronous
>   Synch Type   Asynchronous
>   Usage Type   Data
> wMaxPacketSize 0x1400  3x 1024 bytes
> bInterval   1
>
> However the usb bus trace shows only one transaction with 1024-bytes packet in
> every SOF. The host only sends one IN packet in every SOF, I am expecting 2~3
> 1024-bytes transactions, since this would be required to transfer 
> 640x480@30fps
> YUV frames in high-speed.
>
> DId I miss anything in the setup?

MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
of your bus analyzer? When host sends IN token, are you replying with
DATA0, DATA1 or DATA2?

-- 
balbi


signature.asc
Description: PGP signature


g_webcam Isoch high bandwidth transfer

2016-09-20 Thread Bin Liu
Hi,

I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
 high-speed connection.

First I hacked webcam.c as follows to enable 640x480@30fps mode.

diff --git a/drivers/usb/gadget/legacy/webcam.c 
b/drivers/usb/gadget/legacy/webcam.c
index 72c976b..9eb315f 100644
--- a/drivers/usb/gadget/legacy/webcam.c
+++ b/drivers/usb/gadget/legacy/webcam.c
@@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
uvc_frame_yuv_360p = {
.bFrameIndex= 1,
.bmCapabilities = 0,
.wWidth = cpu_to_le16(640),
-   .wHeight= cpu_to_le16(360),
+   .wHeight= cpu_to_le16(480),
.dwMinBitRate   = cpu_to_le32(18432000),
.dwMaxBitRate   = cpu_to_le32(55296000),
-   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
-   .dwDefaultFrameInterval = cpu_to_le32(66),
+   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
+   .dwDefaultFrameInterval = cpu_to_le32(33),
.bFrameIntervalType = 3,
-   .dwFrameInterval[0] = cpu_to_le32(66),
-   .dwFrameInterval[1] = cpu_to_le32(100),
-   .dwFrameInterval[2] = cpu_to_le32(500),
+   .dwFrameInterval[0] = cpu_to_le32(33),
+   .dwFrameInterval[1] = cpu_to_le32(66),
+   .dwFrameInterval[2] = cpu_to_le32(100),
 };

then loaded g_webcam.ko as

# modprobe g_webcam streaming_maxpacket=3072

The endpoint descriptor showing on the host is

  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8d  EP 13 IN
bmAttributes5
  Transfer TypeIsochronous
  Synch Type   Asynchronous
  Usage Type   Data
wMaxPacketSize 0x1400  3x 1024 bytes
bInterval   1

However the usb bus trace shows only one transaction with 1024-bytes packet in
every SOF. The host only sends one IN packet in every SOF, I am expecting 2~3
1024-bytes transactions, since this would be required to transfer 640x480@30fps
YUV frames in high-speed.

DId I miss anything in the setup?

Thanks,
-Bin.
--
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