linux-kernel - Re: [RFC/RFT PATCH 0/6] Asynchronous UVC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <239ae307-9c8d-ab95-34c0-3a179d2899bd@ideasonboard.com>
Date:   Tue, 5 Jun 2018 10:01:43 +0100
From:   Kieran Bingham <kieran.bingham@...asonboard.com>
To:     Troy Kisky <troy.kisky@...ndarydevices.com>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        laurent.pinchart@...asonboard.com
Cc:     Olivier BRAUN <olivier.braun@...reolabs.com>,
        kieran.bingham@...asonboard.com,
        Guennadi Liakhovetski <g.liakhovetski@....de>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [RFC/RFT PATCH 0/6] Asynchronous UVC

Hi Troy

On 03/01/18 21:13, Troy Kisky wrote:
> On 1/3/2018 12:32 PM, Kieran Bingham wrote:
>> From: Kieran Bingham <kieran.bingham@...asonboard.com>
>>
>> The Linux UVC driver has long provided adequate performance capabilities for
>> web-cams and low data rate video devices in Linux while resolutions were low.
>>
>> Modern USB cameras are now capable of high data rates thanks to USB3 with
>> 1080p, and even 4k capture resolutions supported.
>>
>> Cameras such as the Stereolabs ZED or the Logitech Brio can generate more data
>> than an embedded ARM core is able to process on a single core, resulting in
>> frame loss.
>>
>> A large part of this performance impact is from the requirement to
>> ‘memcpy’ frames out from URB packets to destination frames. This unfortunate
>> requirement is due to the UVC protocol allowing a variable length header, and
>> thus it is not possible to provide the target frame buffers directly.
> 
> 
> I have a rather large patch that does provide frame buffers directly for bulk
> cameras. It cannot be used with ISOC cameras.  But it is currently for 4.1.
> I'll be porting it to 4.9 in a few days if you'd like to see it.


How did you get on with this porting activity?

Is it possible to share any of this work with the mailing lists ?

(If you have not ported to v4.9 - I think it would be useful even to post the
v4.1 patch and we can look at what's needed for getting it ported to mainline)

--
Regards

Kieran


> 
> BR
> Troy
> 
> 
>>
>> Extra throughput is possible by moving the actual memcpy actions to a work
>> queue, and moving the memcpy out of interrupt context and allowing work tasks
>> to be scheduled across multiple cores.
>>
>> This series has been tested on both the ZED and Brio cameras on arm64
>> platforms, however due to the intrinsic changes in the driver I would like to
>> see it tested with other devices and other platforms, so I'd appreciate if
>> anyone can test this on a range of USB cameras.
>>
>> Kieran Bingham (6):
>>   uvcvideo: Refactor URB descriptors
>>   uvcvideo: Convert decode functions to use new context structure
>>   uvcvideo: Protect queue internals with helper
>>   uvcvideo: queue: Simplify spin-lock usage
>>   uvcvideo: queue: Support asynchronous buffer handling
>>   uvcvideo: Move decode processing to process context
>>
>>  drivers/media/usb/uvc/uvc_isight.c |   4 +-
>>  drivers/media/usb/uvc/uvc_queue.c  | 115 ++++++++++++++----
>>  drivers/media/usb/uvc/uvc_video.c  | 191 ++++++++++++++++++++++--------
>>  drivers/media/usb/uvc/uvcvideo.h   |  56 +++++++--
>>  4 files changed, 289 insertions(+), 77 deletions(-)
>>
>> base-commit: 6f0e5fd39143a59c22d60e7befc4f33f22aeed2f
>>
>