Hi Rajmohan,
On Tuesday, 4 December 2018 18:07:16 EET Mani, Rajmohan wrote:
> >> On Thursday, 29 November 2018 21:51:32 EET Tomasz Figa wrote:
> >>> On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote:
> >>>> On Tuesday, 30 October 2018 00:22:54
| 6 +-
drivers/media/usb/uvc/uvc_queue.c | 110 ++
drivers/media/usb/uvc/uvc_video.c | 274 ++-
drivers/media/usb/uvc/uvcvideo.h | 65 +--
5 files changed, 369 insertions(+), 151 deletions(-)
--
Regards,
Laurent Pinchart
tart() and uvc_uninit_video() to
> > uvc_video_stop().
>
> Could you s/uvc_video_start/uvc_video_start_transfer/ and
> s/uvc_video_stop/uvc_video_stop_transfer/ when applying please?
>
> (Assuming you get to apply and don't find something else :D)
Will do.
Reviewed-by: Lauren
pe);
> > + }
> > +
> > + uvc_video_clock_cleanup(stream);
> > + return 0;
> > +}
> > diff --git a/drivers/media/usb/uvc/uvcvideo.h
> > b/drivers/media/usb/uvc/uvcvideo.h index 94accfa3c009..b1b895c67122
> > 100644
> > --- a/drivers/media/usb/uvc/uvcvideo.h
> > +++ b/drivers/media/usb/uvc/uvcvideo.h
> > @@ -786,7 +786,8 @@ void uvc_mc_cleanup_entity(struct uvc_entity *entity);
> >
> > int uvc_video_init(struct uvc_streaming *stream);
> > int uvc_video_suspend(struct uvc_streaming *stream);
> > int uvc_video_resume(struct uvc_streaming *stream, int reset);
> >
> > -int uvc_video_enable(struct uvc_streaming *stream, int enable);
> > +int uvc_video_start_streaming(struct uvc_streaming *stream);
> > +int uvc_video_stop_streaming(struct uvc_streaming *stream);
> >
> > int uvc_probe_video(struct uvc_streaming *stream,
> >
> > struct uvc_streaming_control *probe);
> >
> > int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
--
Regards,
Laurent Pinchart
; processing through a work queue to move it from interrupt context, and
> allow multiple processors to work on URBs in parallel.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
>
> ---
> v2:
> - Lock full critical section of usb_submit_urb()
>
>
).
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/usb/uvc/uvc_driver.c | 54 +--
> 1 file changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/driv
Hi Sakari,
On Monday, 3 December 2018 11:51:01 EET Sakari Ailus wrote:
> On Fri, Nov 30, 2018 at 01:07:53AM +0200, Laurent Pinchart wrote:
> > On Wednesday, 7 November 2018 06:16:47 EET Bing Bu Cao wrote:
> >> On 11/01/2018 08:03 PM, Sakari Ailus wrote:
> >>> On M
(+), 8 deletions(-)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-cnf4.rst
--
Regards,
Laurent Pinchart
-vtc.h | 5 +
include/dt-bindings/media/xilinx-vip.h | 5 +
12 files changed, 15 insertions(+), 41 deletions(-)
--
Regards,
Laurent Pinchart
char *argv[])
> {
> struct sched_param sched;
> - struct device dev;
> + struct device dev = { 0 };
> int ret;
>
> /* Options parsings */
--
Regards,
Laurent Pinchart
pabilities, which processing blocks are in use, CAPTURE
> video nodes formats etc.), I think you could simply use the FIXED media bus
> code for each pad. That would actually make sense: this device always works
> from memory to memory, and thus does not really have a pixel data bus
> external to the device which is what the media bus codes really are for.
Isn't the Bayer variant useful information to configure debayering ? I would
expect it to be passed through the format on pad 0.
--
Regards,
Laurent Pinchart
entity 41: ipu3-imgu 0 3a stat (1 pad, 1 link)
> >> type Node subtype V4L flags 0
> >> device node name /dev/video4
> >>
> >>pad0: Sink
> >><- "ipu3-imgu 0":4 []
> >>
> >> - entity 47: ipu3-imgu 1 input (1 pad, 1 link)
> >> type Node subtype V4L flags 0
> >> device node name /dev/video5
> >>
> >>pad0: Source
> >>-> "ipu3-imgu 1":0 []
> >>
> >> - entity 53: ipu3-imgu 1 parameters (1 pad, 1 link)
> >> type Node subtype V4L flags 0
> >> device node name /dev/video6
> >>
> >>pad0: Source
> >>-> "ipu3-imgu 1":1 []
> >>
> >> - entity 59: ipu3-imgu 1 output (1 pad, 1 link)
> >> type Node subtype V4L flags 0
> >> device node name /dev/video7
> >>
> >>pad0: Sink
> >><- "ipu3-imgu 1":2 []
> >>
> >> - entity 65: ipu3-imgu 1 viewfinder (1 pad, 1 link)
> >> type Node subtype V4L flags 0
> >> device node name /dev/video8
> >>
> >>pad0: Sink
> >><- "ipu3-imgu 1":3 []
> >>
> >> - entity 71: ipu3-imgu 1 3a stat (1 pad, 1 link)
> >> type Node subtype V4L flags 0
> >> device node name /dev/video9
> >>
> >>pad0: Sink
> >><- "ipu3-imgu 1":4 []
[snip]
--
Regards,
Laurent Pinchart
Hi Tomasz,
On Thursday, 29 November 2018 21:51:32 EET Tomasz Figa wrote:
> On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote:
> > On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote:
[snip]
> >> 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need to be
aw2pnm -x2560 -y1920 -fNV12 /tmp/frames.out /tmp/frames.out.pnm
PNM is an umbrella term that refers to any of the PBM, PGM or PPM format. As
the raw2pnm tool outputs PPM files, let's name them .ppm here and below. This
helps with some image viewers that use file extensions to identify the format,
and have trouble handling .pnm files.
> +where 2560x1920 is output resolution, NV12 is the video format, followed
> +by input frame and output PNM file.
> +
> +Viewfinder output frames
> +
> +
> +raw2pnm -x2560 -y1920 -fNV12 /tmp/frames.vf /tmp/frames.vf.pnm
> +
> +where 2560x1920 is output resolution, NV12 is the video format, followed
> +by input frame and output PNM file.
> +
> +Example user space code for IPU3
> +
> +
> +User space code that configures and uses IPU3 is available here.
> +
> +https://chromium.googlesource.com/chromiumos/platform/arc-camera/+/master/
> +
> +The source can be located under hal/intel directory.
> +
> +References
> +==
> +
> +include/uapi/linux/intel-ipu3.h
> +
> +.. [#f1] https://github.com/intel/nvt
> +
> +.. [#f2] http://git.ideasonboard.org/yavta.git
> +
> +.. [#f3] http://git.ideasonboard.org/?p=media-ctl.git;a=summary
> +
> +.. [#f4] ImgU limitation requires an additional 16x16 for all input
> resolutions
--
Regards,
Laurent Pinchart
l2_fourcc('U', 'V', 'C', 'H') /* UVC
> Payload Header metadata */ #define V4L2_META_FMT_D4XX
> v4l2_fourcc('D', '4', 'X', 'X') /* D4XX Payload Header metadata */
>
> +/* Vendor specific - used for IPU3 camera sub-system */
> +#define V4L2_META_FMT_IPU3_PARAMSv4l2_four
bly am), but in any case, the
driver shouldn't crash. Could you please have a look ?
Please note that, as I couldn't get the IMGU to process frames, the part of
the script that converts output files to PPM is untested and thus probably
incorrect.
[snip]
--
Regards,
Laurent Pinchart
to cab35a9c77adda8f971a7d1d74b21c0df98ffafe:
media: vsp1: Fix LIF buffer thresholds (2018-11-28 20:38:50 +0200)
VSP1 regression fixes for v4.20
Laurent Pinchart (1
e, so it says
> "data is in this buffer, and it starts here" and so that memcpy in
> kernel is not neccessary?
Unfortunately not, as the UVC protocol segments the frame in a large number of
small packets, each prefixed with a variable-length header. It's a poorly
designed protocol from that point of view.
--
Regards,
Laurent Pinchart
From: Jacopo Mondi
Signed-off-by: Jacopo Mondi
Signed-off-by: Laurent Pinchart
---
include/linux/v4l2-common.h | 1 +
include/linux/v4l2-controls.h | 219 ++
include/linux/videodev2.h | 81 -
3 files changed, 221 insertions(+), 80 deletions
++
include/linux/videodev2.h | 81 -
yavta.c | 4 +
4 files changed, 225 insertions(+), 80 deletions(-)
--
Regards,
Laurent Pinchart
From: Jacopo Mondi
Signed-off-by: Jacopo Mondi
Signed-off-by: Laurent Pinchart
---
yavta.c | 4
1 file changed, 4 insertions(+)
diff --git a/yavta.c b/yavta.c
index afe96331a520..c7986bd9e031 100644
--- a/yavta.c
+++ b/yavta.c
@@ -224,6 +224,10 @@ static struct v4l2_format_info
Hi Hans,
On Thursday, 15 November 2018 09:30:55 EET Hans Verkuil wrote:
> On 11/14/2018 08:52 PM, Laurent Pinchart wrote:
> > On Tuesday, 13 November 2018 17:43:48 EET Hans Verkuil wrote:
> >> On 11/13/18 16:06, Philipp Zabel wrote:
> >>> From: John Sheu
> &g
USERPTR)
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index c8e8ff810190..2a223835214c 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -879,6 +879,7 @@ struct v4l2_requestbuffers {
> #define V4L2_BUF_CAP_SUPPORTS_USERPTR(1 << 1)
> #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>
> /**
> * struct v4l2_plane - plane info for multi-planar buffers
--
Regards,
Laurent Pinchart
on/videobuf2/videobuf2-v4l2.c
> > @@ -624,7 +624,7 @@ EXPORT_SYMBOL(vb2_querybuf);
> >
> > static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
> > {
> >
> > - *caps = 0;
> > + *caps = V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS;
> >
> > if (q->io_modes & VB2_MMAP)
> >
> > *caps |= V4L2_BUF_CAP_SUPPORTS_MMAP;
> >
> > if (q->io_modes & VB2_USERPTR)
> >
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h index c8e8ff810190..2a223835214c 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -879,6 +879,7 @@ struct v4l2_requestbuffers {
> >
> > #define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
> > #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> > #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> >
> > +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
> >
> > /**
> >
> > * struct v4l2_plane - plane info for multi-planar buffers
--
Regards,
Laurent Pinchart
uffers,
> we will need to support buffers being processed on multiple CPUs.
>
> Adapt the uvc_queue_next_buffer() such that a reference count tracks the
> active use of the buffer, returning the buffer to the VB2 stack at
> completion.
>
> Signed-off-by: Kieran Bingham
Rev
Hi Kieran,
On Wednesday, 7 November 2018 01:31:29 EET Laurent Pinchart wrote:
> On Tuesday, 6 November 2018 23:27:11 EET Kieran Bingham wrote:
> > From: Kieran Bingham
> >
> > The Linux UVC driver has long provided adequate performance capabilities
> > for web-c
Hi Kieran,
On Wednesday, 7 November 2018 16:30:46 EET Kieran Bingham wrote:
> On 06/11/2018 23:13, Laurent Pinchart wrote:
> > On Tuesday, 6 November 2018 23:27:19 EET Kieran Bingham wrote:
> >> From: Kieran Bingham
> >>
> >> We have both uvc_init_video()
Hi Mauro,
On Wednesday, 7 November 2018 21:53:20 EET Mauro Carvalho Chehab wrote:
> Em Wed, 07 Nov 2018 21:35:32 +0200 Laurent Pinchart escreveu:
> > On Wednesday, 7 November 2018 21:10:35 EET Mauro Carvalho Chehab wrote:
[snip]
> >> I'm with Hans on that matte
Hi Mauro,
On Wednesday, 7 November 2018 21:10:35 EET Mauro Carvalho Chehab wrote:
> Em Wed, 07 Nov 2018 12:06:55 +0200 Laurent Pinchart escreveu:
> > On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote:
> >> On 11/06/2018 08:58 PM, Laurent Pinchart wrote:
> >&
Hi Hans,
On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote:
> On 11/06/2018 08:58 PM, Laurent Pinchart wrote:
> > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:
> >> On 11/06/18 14:12, Laurent Pinchart wrote:
> >>> On Tuesday, 6 November
t.c | 6 +-
> drivers/media/usb/uvc/uvc_queue.c | 110 +---
> drivers/media/usb/uvc/uvc_video.c | 282 +++---
> drivers/media/usb/uvc/uvcvideo.h | 65 ++-
> 5 files changed, 331 insertions(+), 134 deletions(-)
>
> base-commit: dafb7f9aef2fd44991ff1691721ff765a23be27b
--
Regards,
Laurent Pinchart
"Failed to submit URB %u (%d).\n",
> +uvc_urb_index(uvc_urb), ret);
> uvc_video_stop(stream, 1);
> return ret;
> }
> diff --git a/drivers/media/usb/uvc/uvcvideo.h
> b/drivers/media/usb/uvc/uvcvideo.h index c0a120496a1f..6a0f1b59356c 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -617,6 +617,9 @@ struct uvc_streaming {
>(uvc_urb) < &(uvc_streaming)->uvc_urb[UVC_URBS]; \
>++(uvc_urb))
>
> +#define uvc_urb_index(uvc_urb) \
> + (unsigned int)((uvc_urb) - (&(uvc_urb)->stream->uvc_urb[0]))
> +
> struct uvc_device_info {
> u32 quirks;
> u32 meta_format;
--
Regards,
Laurent Pinchart
goto error_commit;
>
> - ret = uvc_init_video(stream, GFP_KERNEL);
> + ret = uvc_video_start(stream, GFP_KERNEL);
> if (ret < 0)
> goto error_video;
>
> @@ -2111,7 +2111,7 @@ int uvc_video_start_streaming(struct uvc_streaming
> *stream)
>
> int uvc_video_stop_streaming(struct uvc_streaming *stream)
> {
> - uvc_uninit_video(stream, 1);
> + uvc_video_stop(stream, 1);
> if (stream->intf->num_altsetting > 1) {
> usb_set_interface(stream->dev->udev,
> stream->intfnum, 0);
--
Regards,
Laurent Pinchart
bulk endpoint, mimic the same behaviour.
> + */
> + unsigned int epnum = stream->header.bEndpointAddress
> +& USB_ENDPOINT_NUMBER_MASK;
> + unsigned int dir = stream->header.bEndpointAddress
> +
se throughput, handle the URB decode
> processing through a work queue to move it from interrupt context, and
> allow multiple processors to work on URBs in parallel.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
I wonder if we shouldn't, as a future improvement,
igned-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
>
> v5:
> - uvc_queue_requeue() -> uvc_queue_buffer_requeue()
> - Fix comment
> ---
> drivers/media/usb/uvc/uvc_queue.c | 61 ++--
> drivers/media/usb/uvc/uvcvideo.h | 4 ++-
>
Hi Hans,
On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:
> On 11/06/18 14:12, Laurent Pinchart wrote:
> > On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:
> >> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
> >>> Hi all,
>
> I think maintaining the script (or perhaps scripts) in v4l-utils is best
> > since that keeps it in sync with the latest kernel and v4l-utils
> > developments.
>
> Makes sense --- and that can be always changed later on if there's a need
> to.
I wonder whether that would be best going forward, especially if we want to
add more tests. Wouldn't a v4l-tests project make sense ?
--
Regards,
Laurent Pinchart
rom: Sergey Dorodnicov
>
> Registering new GUID used by Intel RealSense cameras with fourcc CNF4,
> encoding depth sensor confidence information for every pixel.
And there I would write "Register the GUID ...".
Apart from that the patch looks good to me,
Reviewed-by: Laurent Pin
Hi Sergey,
Thank you for the patch.
The subject line should start with an appropriate prefix. I propose rewriting
it as
media: v4l: Add 4bpp packed depth confidence format CNF4
Apart from that the patch looks good to me,
Reviewed-by: Laurent Pinchart
If you're fine with the subject line
turn the error code.
>
> Fixes: 37c65802e76a ("media: tvp5150: Add sync lock interrupt handling")
> Signed-off-by: Marco Felsch
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/tvp5150.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --
bNrPins 1
> > baSourceID( 0) 12
> > bControlSize2
> > bmControls( 0) 0x00
> > bmControls( 1) 0x06
> > iExtension 0
This one exposes two controls, which are likely used to control the IR light.
I however suspect that the controls merely expose an indirect way to read/
write internal registers, so we would really need to capture a USB trace when
using the device in Windows (assuming that the machine is shipped with
software that can control the IR light).
[snip]
--
Regards,
Laurent Pinchart
planes[0].sizeimage for non-M
> formats and M formats, making it impossible to use planes[0].sizeimage
> to set the luma plane size in the hardware for non-M formats (since
> it's the total size of all planes).
>
> I might have probably forgotten about something, but generally fixing
> the 4 above, would be a really big step forward.
--
Regards,
Laurent Pinchart
Hi Hans,
On Wednesday, 17 October 2018 12:16:14 EEST Hans Verkuil wrote:
> On 10/17/2018 10:57 AM, Laurent Pinchart wrote:
> > On Thursday, 20 September 2018 17:42:15 EEST Hans Verkuil wrote:
> >> Some parts of the V4L2 API are awkward to use and I think it would be
> &
need to revamp VIDIOC_CREATE_BUFS (which would give us a chance to
move away from the format structure passed to that ioctl).
--
Regards,
Laurent Pinchart
n
>
> is this what you have in mind Laurent ?
Yes, that's pretty much the idea. The init sequence could be sent when
powering the sensor on to save time at streamon. Everything else can be
programmed at streamon time to simplify the implementation.
> On 10/10/2018 02:41 PM, Laurent
EV_FORMAT_TRY)
> + fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
> + else
> + fmt = >fmt;
>
> - *fmt = *mbus_fmt;
> - goto out;
> - }
> + *fmt = *mbus_fmt;
>
> if (new_mode != sensor->current_mode) {
> sensor->current_mode = new_mode;
> sensor->pending_mode_change = true;
> }
> - if (mbus_fmt->code != sensor->fmt.code) {
> - sensor->fmt = *mbus_fmt;
> + if (mbus_fmt->code != sensor->fmt.code)
> sensor->pending_fmt_change = true;
> - }
> out:
> mutex_unlock(>lock);
> return ret;
>
> > out:
> > --
> > 2.7.4
--
Regards,
Laurent Pinchart
keep the group small though, so you need to bring relevant
> experience to the table.
--
Regards,
Laurent Pinchart
y: Sakari Ailus
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 93f032a39470..4194ea82e6
eu:
> > > > On Sun, 2018-09-30 at 06:30 -0300, Mauro Carvalho Chehab wrote:
> > > > > Em Sun, 30 Sep 2018 09:54:48 +0300 Laurent Pinchart escreveu:
> > > > > > include/media/atmel-isi got removed three years ago without the
>
The userspace API defined at :ref:`v4l2spec`, with is used to
s/at/in/
> control
> + a V4L2 hardware.
> +
> +V4L2 hardware
> + Part of a media hardware with is supported by the V4L2
> + userspace API.
That's kind of a circular definition, isn't it ?
> +V4L2 main driver
> + A V4L2 device driver that implements the main logic to talk with
> + a V4L2 hardware.
> +
> +V4L2 sub-device
> + Part of a media hardware that it is implemented by a device
s/it is/is/
> + driver that is not part of the main V4L2 driver.
I don't think that's correct a V4L2 subdev is a software object, not a piece
of hardware.
> + See :ref:`subdev`.
--
Regards,
Laurent Pinchart
From: Dhaval Shah
SPDX-License-Identifier is used for the Xilinx Video IP and
related drivers.
Signed-off-by: Dhaval Shah
Reviewed-by: Laurent Pinchart
[Added drivers/media/platform/xilinx/Kconfig]
[Added drivers/media/platform/xilinx/Makefile]
[Added include/dt-bindings/media/xilinx-vip.h
ooks like JPEG and MJPEG are randomly used and I don't think you can
> assume that one will have a huffman table and not the other.
That at least should be fixed. If we decide that whether the frames will
contain a Huffman table or not is useful information for userspace, then we
should convey it, either through the current mechanism (JPEG vs. MJPEG) or
through a different mechanism. Otherwise, we can merge JPEG and MJPEG (as long
as it doesn't break userspace).
--
Regards,
Laurent Pinchart
Hi Michal,
On Monday, 1 October 2018 16:28:32 EEST Michal Simek wrote:
> On 1.10.2018 15:26, Laurent Pinchart wrote:
> > On Monday, 1 October 2018 15:45:49 EEST Michal Simek wrote:
> >> On 28.9.2018 14:52, Laurent Pinchart wrote:
> >>> On Friday, 28 September 201
ing/media/zoran/zoran_driver.c
> > drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> > drivers/usb/gadget/function/uvc_v4l2.c
> >
> > It looks like s2255 and cpia2 support both already, so that would leave
> > 8 drivers that need to be modified, uvc being the most important of the
> > lot.
> >
> > Any comments?
--
Regards,
Laurent Pinchart
Hi Michal,
On Monday, 1 October 2018 15:45:49 EEST Michal Simek wrote:
> On 28.9.2018 14:52, Laurent Pinchart wrote:
> > On Friday, 28 September 2018 10:32:13 EEST Andrea Merello wrote:
> >> In formats table the entry for CFA pattern "rggb" has GRBG fourcc.
> >&g
Hi Hans,
On Monday, 1 October 2018 14:54:29 EEST Hans Verkuil wrote:
> On 10/01/2018 01:48 PM, Laurent Pinchart wrote:
> > On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote:
> >> It turns out that we have both JPEG and Motion-JPEG pixel formats
> >> defined.
&
ed to be modified, uvc being the most important of the
> lot.
>
> Any comments?
--
Regards,
Laurent Pinchart
.
However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have been
reported to work well.
[laurent.pinch...@ideasonboard.com: Factor out code to helper function, update
size checks]
Signed-off-by: ming_qian
Signed-off-by: Laurent Pinchart
Tested-by: Kai-Heng Feng
Tested-by: Ana Guerrero
include/media/atmel-isi got removed three years ago without the
MAINTAINERS file being updated. Remove the stale entry.
Fixes: 40a78f36fc92 ("[media] v4l: atmel-isi: Remove support for platform data")
Reported-by: Joe Perches
Signed-off-by: Laurent Pinchart
---
MAINTAINERS | 1
Hi Helmut,
On Friday, 21 September 2018 10:23:37 EEST Helmut Grohne wrote:
> On Thu, Sep 20, 2018 at 11:00:26PM +0200, Laurent Pinchart wrote:
> > On Thursday, 20 September 2018 23:16:47 EEST Sylwester Nawrocki wrote:
> >> On 09/20/2018 06:49 PM, Grant Grundler wrote:
> >
gt; > patchset and needs to be discussed together.
>
> It addresses some of the same problem area but the implementation is
> orthogonal to this.
>
> Providing that would probably make the base field less useful: the valid
> control values could be enumerated by the user using TRY_EXT_CTRLS without
> the need to tell the valid values are powers of e.g. two.
>
> I don't really have a strong opinion on that actually when it comes to the
> API itself. The imx208 driver could proceed to use linear relation between
> the control value and the digital gain. My worry is just the driver
> implementation: this may not be entirely trivial. There's still no way to
> address this problem in a generic way otherwise.
--
Regards,
Laurent Pinchart
0x0008
> +#define V4L2_CTRL_FLAG_INACTIVE 0x0010
> +#define V4L2_CTRL_FLAG_SLIDER0x0020
> +#define V4L2_CTRL_FLAG_WRITE_ONLY0x0040
> +#define V4L2_CTRL_FLAG_VOLATILE 0x0080
> +#define V4L2_CTRL_FLAG_HAS_PAYLOAD 0x0100
> +#define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE 0x0200
> +#define V4L2_CTRL_FLAG_MODIFY_LAYOUT 0x0400
>
> /* Query flags, to be ORed with the control ID */
> #define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000
--
Regards,
Laurent Pinchart
igned-off-by: Andrea Merello
Reviewed-by: Laurent Pinchart
Michal, should I take the patch in my tree ?
> ---
> drivers/media/platform/xilinx/xilinx-vip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/xilinx/xilinx-vip.c
> b/dr
d ? It's easier to read
pad = media_get_pad_index(entity, MEDIA_PAD_FL_SINK, ...);
than
pad = media_get_pad_index(entity, true, ...);
As an added bonus that would allow the caller to search for any pad with a
given signal type by specifying MEDIA_PAD_FL_SINK | MEDIA_PAD_FL_SOURCE.
> + * @sig_type:type of signal of the pad to be search
> + *
> + * This helper function finds the first pad index inside an entity that
> + * satisfies both @is_sink and @sig_type conditions.
> + *
> + * Return:
> + *
> + * On success, return the pad number. If the pad was not found or the media
> + * entity is a NULL pointer, return -EINVAL.
> + */
> +int media_get_pad_index(struct media_entity *entity, bool is_sink,
> + enum media_pad_signal_type sig_type);
> +
> /**
> * media_create_pad_link() - creates a link between two entities.
> *
--
Regards,
Laurent Pinchart
*
> @@ -169,6 +203,7 @@ struct media_pad {
> struct media_gobj graph_obj;/* must be first field in struct */
> struct media_entity *entity;
> u16 index;
> + enum media_pad_signal_type sig_type;
Missing kerneldoc and Documentation/ update ? It's important to document the
use cases, and in particular whether the type should be static or can vary (as
in whether a pad can carry different types over time).
> unsigned long flags;
> };
--
Regards,
Laurent Pinchart
Hans Verkuil
It wasn't immediately clear to me that the !sev->elems check can be removed
because the subscriptions are *now* only added to the event list once they are
fully initialized, I thought the sentence documented the current
implementation. After realizing that,
Reviewed-by: Laurent
onfiguration, we do need to provide more
> information to the user space. One way to do that would be through
> VIDIOC_QUERY_EXT_CTRL. The IOCTL struct has plenty of reserved fields ---
> just for purposes such as this one.
I don't think we can come up with a good way to expose arbitrary mathematical
formulas through an ioctl. In my opinion the question is how far we want to
go, how precise we need to be.
> > Any opinions or better ideas?
--
Regards,
Laurent Pinchart
ID_DIGITAL_GAIN_DISCRETE) or abuse the specification and
> >> register V4L2_CID_DIGITAL_GAIN as an integer menu.
> >>
> >> Any opinions or better ideas?
> >
> > My $0.02: leave the user UI alone - let users specify/select anything
> > in the range the normal API or UI allows. But have sensor specific
> > code map all values in that range to values the sensor supports. Users
> > will notice how it works when they play with it. One can "adjust" the
> > mapping so it "feels right".
--
Regards,
Laurent Pinchart
e pin that msmgpio 26 is connected to on your board ?
I'd argue that the GPIO should be called xshutdown in that case, as DT usually
uses the pin name, but there's precedent of using well-known names for pins
with the same functionality. In any case you should update the DT bindings to
document the new property, and clearly explain that it describes the GPIO
connected to the xshutdown pin. Please CC the devicet...@vger.kernel.org
mailing list on the bindings change (they usually like bindings changes to be
split to a separate patch).
--
Regards,
Laurent Pinchart
On Thursday, 20 September 2018 23:04:21 EEST Laurent Pinchart wrote:
> Hi Ricardo,
>
> On Thursday, 20 September 2018 22:12:44 EEST Ricardo Ribalda Delgado wrote:
> > On Thu, Sep 20, 2018 at 9:08 PM Pavel Machek wrote:
> > > On Thu 2018-09-20 21:06:16, Ricar
Hi Mauro,
On Thursday, 20 September 2018 17:44:53 EEST Mauro Carvalho Chehab wrote:
> Em Fri, 07 Sep 2018 14:46:34 +0300 Laurent Pinchart escreveu:
> > Hi Mauro,
> >
> > As maintainers should be held to the same level of obligations as
> > developers, and to avoid de
_interval {
> * @code: format code (MEDIA_BUS_FMT_ definitions)
> * @width: frame width in pixels
> * @height: frame height in pixels
> - * @interval: frame interval in seconds
> + * @interval: minimum frame interval in seconds
> * @which: format type (from enum v4l2_subdev_format_whence)
> + * @type: frame interval type (from enum v4l2_subdev_frmival_type)
> + * @max_interval: maximum frame interval in seconds,
> + *if type != V4L2_SUBDEV_FRMIVAL_TYPE_DISCRETE
> + * @step_interval: step between frame intervals, in seconds,
> + * if type == V4L2_SUBDEV_FRMIVAL_TYPE_STEPWISE
> */
> struct v4l2_subdev_frame_interval_enum {
> __u32 index;
> @@ -128,7 +143,10 @@ struct v4l2_subdev_frame_interval_enum {
> __u32 height;
> struct v4l2_fract interval;
> __u32 which;
> - __u32 reserved[8];
> + __u32 type;
> + struct v4l2_fract max_interval;
> + struct v4l2_fract step_interval;
> + __u32 reserved[3];
> };
>
> /**
--
Regards,
Laurent Pinchart
restriction on UDS
Koji Matsuoka (1):
media: vsp1: Fix YCbCr planar formats pitch calculation
Laurent Pinchart (2):
media: vsp1: Fix vsp1_regs.h license header
media: vsp1: Update LIF buffer thresholds
MAINTAINERS | 1 +
drivers/media/platform/vsp1
ething more descriptive like:
> > 'subscribe_lock'?
> >
> >> #if IS_ENABLED(CONFIG_V4L2_MEM2MEM_DEV)
> >>
> >>struct v4l2_m2m_ctx *m2m_ctx;
> >
> > Overall I think this patch makes sense. The code is cleaner and easier to
> > follow. Just give 'mutex' a better name :-)
>
> How about "subscribe_mutex"? It's a mutex... "subscribe_lock" would use a
> similar convention elsewhere in V4L2 where mutexes are commonly called
> locks, so I'm certainly fine with that as well.
We indeed use lock for both mutexes and spinlocks. I have a slight preference
for the name lock myself, but I don't mind too much.
--
Regards,
Laurent Pinchart
Hi Mauro,
On Friday, 7 September 2018 14:46:34 EEST Laurent Pinchart wrote:
> Hi Mauro,
>
> As maintainers should be held to the same level of obligations as
> developers, and to avoid demotivating reviewers, could you handle comments
> you receive before pushing your own patch
Hi Hugues,
On Monday, 10 September 2018 18:14:45 EEST Hugues FRUCHET wrote:
> On 09/07/2018 04:18 PM, Laurent Pinchart wrote:
> > On Thursday, 16 August 2018 18:07:54 EEST Hugues FRUCHET wrote:
> >> On 08/16/2018 12:10 PM, jacopo mondi wrote:
> >>> On Mon, Aug 13, 20
Hi Hugues,
(Hans, there's a question for you below)
On Monday, 10 September 2018 17:43:27 EEST Hugues FRUCHET wrote:
> On 09/10/2018 12:46 PM, Laurent Pinchart wrote:
> > On Monday, 10 September 2018 13:23:41 EEST Hugues FRUCHET wrote:
> >> On 09/06/2018 03:31 PM, Laur
Hi Hugues,
On Monday, 10 September 2018 13:23:41 EEST Hugues FRUCHET wrote:
> On 09/06/2018 03:31 PM, Laurent Pinchart wrote:
> > On Monday, 13 August 2018 13:19:45 EEST Hugues Fruchet wrote:
> >
> >> When switching from auto to manual mode, V4L2 core is calling
> >
as missing previously,
> leading to "mode registers" being loaded but not the "pixel format
> registers".
This seems overly complicated to me. Why do we have to set the mode at power
on time at all, why can't we do it at stream on time only, and simplify all
this logic ?
> PS: There are two other "set mode" related changes that are related to
> this:
> 1) 6949d864776e ("media: ov5640: do not change mode if format or
> frame interval is unchanged")
> => this is merged in media master, unfortunately I've introduced a
> regression on "pixel format" side that I've fixed in this patchset :
> 2) https://www.mail-archive.com/linux-media@vger.kernel.org/msg134413.html
> Symptom was a noisy image when capturing QVGA YUV (in fact captured as
> JPEG data).
[snip]
--
Regards,
Laurent Pinchart
EEST Laurent Pinchart wrote:
> Hi Mauro,
>
> Thank you for the patch.
>
> The subject line should be "media: omap3isp: ...".
>
> On Wednesday, 8 August 2018 17:52:55 EEST Mauro Carvalho Chehab wrote:
> > As sparse complains:
> > drivers/media/pla
;
> > >> @@ -1626,7 +1614,7 @@ static int ov5640_set_mode(struct ov5640_dev
> > >> *sensor,
> > >>
> > >> return ret;
> > >>
> > >> exposure = sensor->ctrls.auto_exp->val;
> >
if (ctrl->val == V4L2_EXPOSURE_MANUAL)
> - return 0;
> val = ov5640_get_exposure(sensor);
> if (val < 0)
> return val;
And same here.
--
Regards,
Laurent Pinchart
l exposure set to 1 while it was intended to
> set autoexposure to "manual", fix this.
>
> Signed-off-by: Hugues Fruchet
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/ov5640.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
&
ar functions.
>
> Signed-off-by: Hugues Fruchet
Reiewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/ov5640.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 7c569de..9fb17b5 100
t; @@ -154,6 +154,9 @@
> > #define UVC_GUID_FORMAT_INVI \
> > { 'I', 'N', 'V', 'I', 0xdb, 0x57, 0x49, 0x5e, \
> > 0x8e, 0x3f, 0xf4, 0x79, 0x53, 0x2b, 0x94, 0x6f}
> > +#define UVC_GUID_FORMAT_CNF4 \
> > + { 'C', ' ', ' ', ' ', 0x00, 0x00, 0x10, 0x00, \
> > +0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> >
> > #define UVC_GUID_FORMAT_D3DFMT_L8 \
> > {0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, \
--
Regards,
Laurent Pinchart
ssary NULL check before
debugfs_remove_recursive
Joe Perches (1):
media: uvcvideo: Make some structs const
Laurent Pinchart (2):
media: uvcvideo: Make uvc_control_mapping menu_info field const
media: uvcvideo: Store device information pointer in struct uvc_device
Nadav Amit (1):
et's not miss v4.20.
> On Sun, 29 Jul 2018, Laurent Pinchart wrote:
> > On Saturday, 23 December 2017 13:11:00 EEST Guennadi Liakhovetski wrote:
> >> From: Guennadi Liakhovetski
> >>
> >> D4M is a mobile model from the D4XX family of Intel RealSense cameras.
&
- What are the version of the three structures documented in this patch ? I
can check that when I get back home, but if you have the information it would
be faster.
- Do the fields in the Depth Control structure apply to the depth video stream
only ? (I assume they do)
- What do the fields in the Capture Control structure apply to ? (I assume the
left sensor and/or fish eye video streams)
- Does the optical time differ from half the exposure time ?
If you think it will take time to get this information and we risk missing the
next kernel version, I'm OK applying the patch already, but please then submit
a follow-up patch (or just drop a mail in reply to this one with the
information and I can turn that into a patch).
[snip]
--
Regards,
Laurent Pinchart
i2c/aptina-pll.c
> index 224ae4e4cf8b..249018772b2b 100644
> --- a/drivers/media/i2c/aptina-pll.c
> +++ b/drivers/media/i2c/aptina-pll.c
> @@ -2,6 +2,7 @@
> * Aptina Sensor PLL Configuration
> *
> * Copyright (C) 2012 Laurent Pinchart
> + * Copyright (C) 2018
st this week.
--
Regards,
Laurent Pinchart
Hi Guennadi,
On Monday, 20 August 2018 15:02:53 EEST Laurent Pinchart wrote:
> On Friday, 3 August 2018 14:36:56 EEST Guennadi Liakhovetski wrote:
> > This macro defines "information about quirks," not "quirks for
> > information."
To address Nicolas' objec
Hi Guennadi,
Thank you for the patch.
On Friday, 3 August 2018 14:36:56 EEST Guennadi Liakhovetski wrote:
> This macro defines "information about quirks," not "quirks for
> information."
>
> Signed-off-by: Guennadi Liakhovetski
Reviewed-by: Laurent
t; > .bInterfaceSubClass = 1,
> > .bInterfaceProtocol = 0,
> >
> > - .driver_info =
> > UVC_QUIRK_INFO(UVC_QUIRK_STATUS_INTERVAL) },
> > + .driver_info =
> > UVC_INFO_QUIRK(UVC_QUIRK_STATUS_INTERVAL) },
> >
> > /* MSI StarCam 370i */
> > { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> >
> > | USB_DEVICE_ID_MATCH_INT_INFO,
> >
> > @@ -2798,7 +2798,7 @@ static int uvc_clock_param_set(const char *val,
> > const struct kernel_param *kp)
> >
> > .bInterfaceClass = USB_CLASS_VIDEO,
> > .bInterfaceSubClass = 1,
> > .bInterfaceProtocol = 0,
> >
> > - .driver_info =
> > UVC_QUIRK_INFO(UVC_QUIRK_PROBE_MINMAX
> > + .driver_info =
> > UVC_INFO_QUIRK(UVC_QUIRK_PROBE_MINMAX
> >
> > UVC_QUIRK_IGNORE_SELECTOR_UNIT) },
> >
> > /* Oculus VR Positional Tracker DK2 */
> > { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
--
Regards,
Laurent Pinchart
Hi Philipp,
On Friday, 17 August 2018 20:46:33 EEST Philipp Zabel wrote:
> Am Donnerstag, den 16.08.2018, 19:39 +0300 schrieb Laurent Pinchart:
> > Hi Christoph,
> >
> > (Philipp, there's a question for you at the end)
>
> > On Thursday, 16 August 2018 15:48
o is
empty.
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_driver.c | 15 +--
drivers/media/usb/uvc/uvc_metadata.c | 7 ---
drivers/media/usb/uvc/uvcvideo.h | 8 +++-
3 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/media/usb/uvc/uv
Hi Christoph,
On Friday, 17 August 2018 10:09:12 EEST Christoph Fritz wrote:
> On Thu, 2018-08-16 at 19:39 +0300, Laurent Pinchart wrote:
> > On Thursday, 16 August 2018 15:48:15 EEST Christoph Fritz wrote:
> >>> On Wednesday, 21 February 2018 23:24:36 EEST L
Hi Christoph,
(Philipp, there's a question for you at the end)
On Thursday, 16 August 2018 15:48:15 EEST Christoph Fritz wrote:
> > On Wednesday, 21 February 2018 23:24:36 EEST Laurent Pinchart wrote:
> >> On Wednesday, 21 February 2018 22:42:45 EET Christoph Fritz wrote:
> &g
``VIDIOC_QBUF`` ioctl to
> specify +the file descriptor of a :ref:`request `, if
> requests are +in use. Setting it means that the buffer will not be passed
> to the driver +until the request itself is queued. Also, the driver will
> apply any +settings associated with the request for this buffer. This field
> will +be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set.
> +If the device does not support requests, then ``EPERM`` will be returned.
> +If requests are supported but an invalid request FD is given, then
> +``ENOENT`` will be returned.
> +
> +.. caution::
> + It is not allowed to mix queuing requests with queuing buffers directly.
> + ``EPERM`` will be returned if the first buffer was queued directly and
> + then the application tries to queue a request, or vice versa.
How do drivers assert this constraint ? Is it per file handle ? Per device
node ? If per device node, how is it reset ? i.e. if an application uses the
device in request mode, closes and, and a legacy application tries to open and
use it in normal mode, what happens ?
> + For :ref:`memory-to-memory devices ` you can specify the
> + ``request_fd`` only for output buffers, not for capture buffers.
> Attempting + to specify this for a capture buffer will result in an
> ``EPERM`` error. +
I think this should be documented in more details in a new V4L2 request API
section, as noted above.
> Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled
> (capturing) or displayed (output) buffer from the driver's outgoing
> queue. They just set the ``type``, ``memory`` and ``reserved`` fields of
> @@ -153,3 +172,14 @@ EPIPE
> ``VIDIOC_DQBUF`` returns this on an empty capture queue for mem2mem
> codecs if a buffer with the ``V4L2_BUF_FLAG_LAST`` was already
> dequeued and no new buffers are expected to become available.
> +
> +EPERM
> +The ``V4L2_BUF_FLAG_REQUEST_FD`` flag was set but the device does not
> +support requests. Or the first buffer was queued via a request, but
> +the application now tries to queue it directly, or vice versa (it is
> +not permitted to mix the two APIs). Or an attempt is made to queue a
> +CAPTURE buffer to a request for a :ref:`memory-to-memory device
> `. +
> +ENOENT
> +The ``V4L2_BUF_FLAG_REQUEST_FD`` flag was set but the the given
> +``request_fd`` was invalid.
> diff --git a/Documentation/media/videodev2.h.rst.exceptions
> b/Documentation/media/videodev2.h.rst.exceptions index
> ca9f0edc579e..99256a2c003e 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -514,6 +514,7 @@ ignore define V4L2_CTRL_DRIVER_PRIV
> ignore define V4L2_CTRL_MAX_DIMS
> ignore define V4L2_CTRL_WHICH_CUR_VAL
> ignore define V4L2_CTRL_WHICH_DEF_VAL
> +ignore define V4L2_CTRL_WHICH_REQUEST_VAL
> ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS
> ignore define V4L2_CID_MAX_CTRLS
--
Regards,
Laurent Pinchart
optimum PLL
parameters when multiple options are possible, and its complexity should be
lower than O(n^2) (ideally O(1), if not possible O(n)).
--
Regards,
Laurent Pinchart
1 - 100 of 7505 matches
Mail list logo
