public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Akash Kumar <quic_akakum@quicinc.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Jing Leng <jleng@ambarella.com>, Felipe Balbi <balbi@kernel.org>,
	Jack Pham <quic_jackp@quicinc.com>,
	kernel@quicinc.com, Wesley Cheng <quic_wcheng@quicinc.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Scally <dan.scally@ideasonboard.com>,
	Vijayavardhan Vennapusa <quic_vvreddy@quicinc.com>,
	Krishna Kurapati <quic_kriskura@quicinc.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] usb: gadget: uvc: Add H264 frame format support
Date: Thu, 11 Jul 2024 11:07:42 +0200	[thread overview]
Message-ID: <2024071126-napped-cobbler-4693@gregkh> (raw)
In-Reply-To: <20240711082304.1363-1-quic_akakum@quicinc.com>

On Thu, Jul 11, 2024 at 01:53:04PM +0530, Akash Kumar wrote:
> Add support for framebased frame format which can be used to support
> multiple formats like H264 or H265 other than mjpeg and YUV frames.
> 
> Framebased format is set to H264 by default, which can be updated to
> other formats by updating the GUID through guid configfs attribute.
> Using Different structures for all 3 formats as H264 has different
> structure than mjpeg and uncompressed which will be paased to
> frame make func based on active format instead of common frame
> structure, have updated all apis in driver accordingly.
> h264 is not recognized by hosts machine during enumeration
> with common frame structure, so we need to pass h264 frame
> structure separately.
> 
> Signed-off-by: Akash Kumar <quic_akakum@quicinc.com>
> ---
>  .../ABI/testing/configfs-usb-gadget-uvc       |  88 ++-
>  drivers/usb/gadget/function/uvc_configfs.c    | 570 +++++++++++++++---
>  drivers/usb/gadget/function/uvc_configfs.h    |  34 +-
>  drivers/usb/gadget/function/uvc_v4l2.c        |  80 ++-
>  include/uapi/linux/usb/video.h                |  62 ++
>  5 files changed, 714 insertions(+), 120 deletions(-)
> 
> Changes for v2:
> - Added H264 frame format Details in Documentation/ABI/
>   and new configsfs attribute path for mjpeg and
>   uncompresseed formats.
> 
> diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> index 4feb692c4c1d..2580083cdcc5 100644
> --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> @@ -224,13 +224,13 @@ Description:	Additional color matching descriptors
>  					  white
>  		========================  ======================================
>  
> -What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg
> -Date:		Dec 2014
> +What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name

You are changing an existing api, how will all existing code handle
this?  Will it not break?  What is ensuring that this will work as-is
ok?

> -#define UVCG_FRAME_ATTR(cname, aname, bits) \
> -static ssize_t uvcg_frame_##cname##_show(struct config_item *item, char *page)\
> +#define UVCG_FRAME_ATTR(cname, fname, bits) \
> +static ssize_t uvcg_frame_##fname##_##cname##_show(struct config_item *item, char *page)\
>  {									\
>  	struct uvcg_frame *f = to_uvcg_frame(item);			\
>  	struct f_uvc_opts *opts;					\
> @@ -1936,14 +1941,14 @@ static ssize_t uvcg_frame_##cname##_show(struct config_item *item, char *page)\
>  	opts = to_f_uvc_opts(opts_item);				\
>  									\
>  	mutex_lock(&opts->lock);					\
> -	result = sprintf(page, "%u\n", f->frame.cname);			\
> +	result = scnprintf(page, PAGE_SIZE, "%u\n", f->frame.fname.cname);\

sysfs_emit() is made for this.

thanks,

greg k-h

  reply	other threads:[~2024-07-11  9:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-11  8:23 [PATCH v2] usb: gadget: uvc: Add H264 frame format support Akash Kumar
2024-07-11  9:07 ` Greg Kroah-Hartman [this message]
2024-07-11  9:43   ` AKASH KUMAR
2024-08-01  6:15     ` AKASH KUMAR
2024-08-26  9:36       ` Michael Riesch
2024-08-26 15:30         ` AKASH KUMAR
2024-08-30  9:39           ` Michael Riesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024071126-napped-cobbler-4693@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=balbi@kernel.org \
    --cc=dan.scally@ideasonboard.com \
    --cc=jleng@ambarella.com \
    --cc=kernel@quicinc.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=quic_akakum@quicinc.com \
    --cc=quic_jackp@quicinc.com \
    --cc=quic_kriskura@quicinc.com \
    --cc=quic_vvreddy@quicinc.com \
    --cc=quic_wcheng@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox