bile_ceu one.
> >
> > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> > platform GR-Peach.
> >
> > Tested with ov7725 camera sensor on SH4 platform Migo-R.
> >
> > Signed-off-by: Jacopo Mondi
> > Reviewed-by: La
save(&queue->irqlock, flags);
> + spin_lock_irq(&queue->irqlock);
> uvc_queue_return_buffers(queue, UVC_BUF_STATE_ERROR);
> - spin_unlock_irqrestore(&queue->irqlock, flags);
> + spin_unlock_irq(&queue->irqlock);
> }
Please add a one
camif_mbus_formats); i++)
if (camif_mbus_formats[i] == mf->code)
break;
if (i == ARRAY_SIZE(camif_mbus_formats))
mf->code = camif_mbus_formats[0];
(I do love the for (...) { ... } else { ... } construct from Python, I miss it
so much in C.)
> if (pad == CAMIF_SD_PAD_SINK) {
> v4l_bound_align_image(&mf->width, 8, CAMIF_MAX_PIX_WIDTH,
--
Regards,
Laurent Pinchart
es in patch 2/4 to 4/4.
Apart from the kmalloc() to kmalloc_array() change, a byte-to-byte comparison
of the .text sections of the module shows no difference before and after this
series.
Laurent Pinchart (4):
uvcvideo: Drop extern keyword in function declarations
uvcvideo: Use kernel integer
The extern keyword isn't needed to declare functions in header files.
Drop it.
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvcvideo.h | 145 +++
1 file changed, 71 insertions(+), 74 deletions(-)
diff --git a/drivers/media/usb/uvc/uvcvide
silence a
checkpatch warning triggered by this patch.
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_ctrl.c | 6 ++---
drivers/media/usb/uvc/uvc_driver.c | 53 +++---
drivers/media/usb/uvc/uvc_v4l2.c | 12 -
drivers/media/usb/uvc/uvc_video.c
Replace the __[su]{8,16,32} variant of integer types with the
non-underscored types as the code is internal to the driver, not exposed
to userspace.
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_ctrl.c | 56 ++--
drivers/media/usb/uvc/uvc_driver.c | 36
Replace the uint_{8,16,32} types with the corresponding native kernel
types u{8,16,32}.
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_driver.c | 16
drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
drivers/media/usb/uvc/uvcvideo.h | 4 ++--
3 files changed, 11
+)
> if (camif_mbus_formats[i] == mf->code)
> break;
>
> - mf->code = camif_mbus_formats[i];
> + if (i == ARRAY_SIZE(camif_mbus_formats))
> + mf->code = camif_mbus_formats[0];
>
> if (pad == CAMIF_SD_PAD_SINK) {
> v4l_bound_align_image(&mf->width, 8, CAMIF_MAX_PIX_WIDTH,
--
Regards,
Laurent Pinchart
buffer {
> unsigned int bytesused;
>
> u32 pts;
> +
> + /* asynchronous buffer handling */
Please capitalize the first word to match other comments in the driver.
> + struct kref ref;
> };
>
> #define UVC_QUEUE_DISCONNECTED (1 << 0)
> @@ -696,6 +699,7 @@ extern struct uvc_buffer *
> uvc_queue_get_current_buffer(struct uvc_video_queue *queue);
> extern struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue
> *queue, struct uvc_buffer *buf);
> +extern void uvc_queue_buffer_release(struct uvc_buffer *buf);
No need for the extern keyboard. I'll submit a patch to drop it for all
functions.
> extern int uvc_queue_mmap(struct uvc_video_queue *queue,
> struct vm_area_struct *vma);
> extern unsigned int uvc_queue_poll(struct uvc_video_queue *queue,
--
Regards,
Laurent Pinchart
opy destination address
> + * @src: copy source address
> + * @len: copy length
> + */
> +struct uvc_copy_op {
> + struct uvc_buffer *buf;
> + void *dst;
> + const __u8 *src;
> + int len;
Can the length be negative ?
> +};
> +
> +/**
> * struct uvc_urb - URB context management structure
> *
> * @urb: the URB described by this context structure
> * @stream: UVC streaming context
> * @buffer: memory storage for the URB
> * @dma: DMA coherent addressing for the urb_buffer
> + * @async_operations: counter to indicate the number of copy operations
> + * @copy_operations: work descriptors for asynchronous copy operations
> + * @work: work queue entry for asynchronous decode
> */
> struct uvc_urb {
> struct urb *urb;
> @@ -496,6 +515,10 @@ struct uvc_urb {
>
> char *buffer;
> dma_addr_t dma;
> +
> + unsigned int async_operations;
> + struct uvc_copy_op copy_operations[UVC_MAX_PACKETS];
> + struct work_struct work;
> };
>
> struct uvc_streaming {
> @@ -528,6 +551,7 @@ struct uvc_streaming {
> /* Buffers queue. */
> unsigned int frozen : 1;
> struct uvc_video_queue queue;
> + struct workqueue_struct *async_wq;
> void (*decode)(struct uvc_urb *uvc_urb, struct uvc_buffer *buf);
>
> /* Context data used by the bulk completion handler. */
--
Regards,
Laurent Pinchart
s
> > masking if those users already integrate the limit check, and lfence
> > they don't."
> >
> > ...which translates to narrow the pointer for get_user() and use a
> > barrier for __get_user().
>
> Great, that matches my thinking re set_fs but I'm still worried about
> finding all the places where the bound is conditional for other users
> of the macro. Then again, finding the places that need this macro in the
> first place is tough enough so perhaps analysing the bound calculation
> doesn't make it much worse.
It might not now, but if the bound calculation changes later, I'm pretty sure
we'll forget to update the speculation barrier macro at least in some cases.
Without the help of static (or possibly dynamic) code analysis I think we're
bound to reintroduce problems over time, but that's true for finding places
where the barrier is needed, not just for barrier selection based on bound
calculation.
--
Regards,
Laurent Pinchart
(NV[12|21|16|61]).
> >
> > This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> >
> > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> > platform GR-Peach.
> >
> > Tested with ov7725 camera sensor on SH4
t;>> - Adjust build system
> >>>
> >>> This commit does not remove the original soc_camera based driver as
> >>> long as other platforms depends on soc_camera-based CEU driver.
> >>>
> >>> Signed-off-by: Jacopo Mondi
> >>> Rev
Hi Hans,
On Friday, 19 January 2018 14:25:39 EET Hans Verkuil wrote:
> On 01/19/18 13:20, Laurent Pinchart wrote:
> > On Friday, 19 January 2018 13:20:19 EET Hans Verkuil wrote:
> >> On 01/16/18 22:44, Jacopo Mondi wrote:
> >>> Add driver for Renesas Capture Engin
_resume,
> @@ -867,6 +875,7 @@ static int as3645a_remove(struct i2c_client *client)
> .driver = {
> .name = AS3645A_NAME,
> .pm = &as3645a_pm_ops,
> + .of_match_table = of_match_ptr(as3645a_of_match),
> },
> .probe = as3645a_probe,
> .remove = as3645a_remove,
--
Regards,
Laurent Pinchart
id)
> IRQF_ONESHOT, dev_name(dev),
> adv7511);
> if (ret)
> - goto err_unregister_cec;
> + goto err_unregister_packet;
> }
>
> adv7511_power_off(adv7511);
> @@ -1203,6 +1212,8 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id)
> adv7511_audio_init(dev, adv7511);
> return 0;
>
> +err_unregister_packet:
> + i2c_unregister_device(adv7511->i2c_packet);
> err_unregister_cec:
> i2c_unregister_device(adv7511->i2c_cec);
> if (adv7511->cec_clk)
> @@ -1234,6 +1245,7 @@ static int adv7511_remove(struct i2c_client *i2c)
> cec_unregister_adapter(adv7511->cec_adap);
>
> i2c_unregister_device(adv7511->i2c_edid);
> + i2c_unregister_device(adv7511->i2c_packet);
>
> return 0;
> }
--
Regards,
Laurent Pinchart
EINVAL;
> +
> + fie->interval.numerator = 1;
> + fie->interval.denominator = ov772x_frame_intervals[fie->index];
> +
> + return 0;
> +}
> +
> static int ov772x_enum_mbus_code(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_mbus_code_enum *code)
> @@ -1052,14 +1353,17 @@ static int ov772x_enum_mbus_code(struct v4l2_subdev
> *sd, }
>
> static const struct v4l2_subdev_video_ops ov772x_subdev_video_ops = {
> - .s_stream = ov772x_s_stream,
> + .s_stream = ov772x_s_stream,
> + .s_frame_interval = ov772x_s_frame_interval,
> + .g_frame_interval = ov772x_g_frame_interval,
> };
>
> static const struct v4l2_subdev_pad_ops ov772x_subdev_pad_ops = {
> - .enum_mbus_code = ov772x_enum_mbus_code,
> - .get_selection = ov772x_get_selection,
> - .get_fmt= ov772x_get_fmt,
> - .set_fmt= ov772x_set_fmt,
> + .enum_frame_interval= ov772x_enum_frame_interval,
> + .enum_mbus_code = ov772x_enum_mbus_code,
> + .get_selection = ov772x_get_selection,
> + .get_fmt= ov772x_get_fmt,
> + .set_fmt= ov772x_set_fmt,
> };
>
> static const struct v4l2_subdev_ops ov772x_subdev_ops = {
> @@ -1131,6 +1435,7 @@ static int ov772x_probe(struct i2c_client *client,
>
> priv->cfmt = &ov772x_cfmts[0];
> priv->win = &ov772x_win_sizes[0];
> + priv->fps = 15;
>
> ret = v4l2_async_register_subdev(&priv->subdev);
> if (ret)
--
Regards,
Laurent Pinchart
_set_rate() documentation in
include/linux/clk.h to state explicitly that the rate will be rounded).
> Anyway, in this case a much simpler:
> clk_set_rate(video_clk, clk_round_rate(video_clk, 1000));
> does the job for Migo-R.
>
> I will include this in next CEU iterations, since I already have a
> small comment from you to fix there ;)
That should not be needed, but if the above code is in a board file, I can
live with that until drivers/sh/clk/ gets fixed.
> >>> (clk_rate_table_find() is called from sh_clk_div_set_rate())
> >>>
> >>> Or are you supposed to ask for the exact clock rate? Where does the 10
> >>> MHz come from?
> >>
> >> From board initialization code, in order to provide a valid input
> >> clock to OV7720 sensor.
--
Regards,
Laurent Pinchart
t)
> + return 0;
> +
> + if (get_user(p, &up->clips))
> + return -EFAULT;
> + uclips = compat_ptr(p);
This is compat code so I don't care too much, but it would be more readable if
you assigned both kclips and uclips here instead of assigning kclips at the
beginning of the function.
> + while (n--) {
Similarly a for loop would be easier to read.
> + if (copy_in_user(&uclips->c, &kclips->c, sizeof(uclips->c)))
> + return -EFAULT;
> + uclips++;
> + kclips++;
> + }
> return 0;
> }
--
Regards,
Laurent Pinchart
ioctls since the error_idx will
> contain information on which control failed. */
--
Regards,
Laurent Pinchart
&karg.v2ecs, up);
> compatible_arg = 0;
> break;
> case VIDIOC_DQEVENT:
> @@ -939,7 +958,7 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar case VIDIOC_G_EXT_CTRLS:
> case VIDIOC_S_EXT_CTRLS:
> case VIDIOC_TRY_EXT_CTRLS:
> - if (put_v4l2_ext_controls32(&karg.v2ecs, up))
> + if (put_v4l2_ext_controls32(file, &karg.v2ecs, up))
> err = -EFAULT;
> break;
> case VIDIOC_S_EDID:
--
Regards,
Laurent Pinchart
Hi Hans,
Thank you for the patches.
For patches 01/13 to 08/13 and 10/13 to 12/13,
Reviewed-by: Laurent Pinchart
On Tuesday, 30 January 2018 12:26:48 EET Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch series fixes a number of bugs and culminates in the removal
> o
s missing a Fixes: tag, and a Reported-by: tag would be nice too.
Apart from that,
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioct
x_s_power,
> };
>
> +static int ov772x_enum_frame_interval(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_frame_interval_enum
> *fie)
> +{
> + if (fie->pad
ime_t, which requires the conversion function ktime_to_ns to be used on
> some places. With this patch it will compile now also for older Kernel
> versions.
>
> Signed-off-by: Jasmin Jessich
Reviewed-by: Laurent Pinchart
and taken into my tree for v4.17.
> ---
> drivers/me
case, not just in a compliance or test tool.
On the topic of the G_TOPOLOGY API, it's pretty clear it was merged too
hastily. We could try to fix it, but given all the issues we haven't solved
yet, I believe a new version of the API would be better.
--
Regards,
Laurent Pinchart
Hi Hans,
On Sunday, 4 February 2018 15:16:26 EET Hans Verkuil wrote:
> On 02/04/2018 02:13 PM, Laurent Pinchart wrote:
> > On Sunday, 4 February 2018 15:06:42 EET Hans Verkuil wrote:
> >> Hi Mauro,
> >>
> >> I'm working on adding proper compliance tests
Hi Jasmin,
On Sunday, 4 February 2018 12:37:08 EET Jasmin J. wrote:
> Hi Laurent!
>
> > Reviewed-by: Laurent Pinchart
>
> THX!
> Don't forget the "Acked-by: Arnd Bergmann " (see Patchwork:
> https://patchwork.linuxtv.org/patch/46464 ).
Sure.
> >
Hi Kieran,
On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
> On 29/01/18 10:26, Laurent Pinchart wrote:
> > On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
> >> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> >>
Hi Guennadi,
On Thursday, 12 July 2018 10:30:46 EEST Guennadi Liakhovetski wrote:
> On Thu, 12 Jul 2018, Laurent Pinchart wrote:
> > On Tuesday, 8 May 2018 18:07:43 EEST Guennadi Liakhovetski wrote:
> >> UVC defines a method of handling asynchronous controls, which sends a
&g
n EBUSY error code instead of a
> generic EPIPE.
>
> Signed-off-by: Guennadi Liakhovetski
Reviewed-by: Laurent Pinchart
> ---
>
> v8:
>
> * restrict UVC_VC_REQUEST_ERROR_CODE_CONTROL to the control interface
> * fix the wIndex value
> * improve error codes
>
Hi Guennadi,
On Tuesday, 17 July 2018 23:58:03 EEST Laurent Pinchart wrote:
> On Tuesday, 8 May 2018 18:07:44 EEST Guennadi Liakhovetski wrote:
> > When a command ends up in a STALL on the control pipe, use the Request
> > Error Code control to provide a more precise error inf
Hi Guennadi,
On Wednesday, 18 July 2018 00:30:45 EEST Guennadi Liakhovetski wrote:
> On Tue, 17 Jul 2018, Laurent Pinchart wrote:
> > On Thursday, 12 July 2018 10:30:46 EEST Guennadi Liakhovetski wrote:
> >> On Thu, 12 Jul 2018, Laurent Pinchart wrote:
> >>> On Tue
Hi Guennadi,
On Wednesday, 18 July 2018 09:55:27 EEST Guennadi Liakhovetski wrote:
> On Wed, 18 Jul 2018, Laurent Pinchart wrote:
> > On Wednesday, 18 July 2018 00:30:45 EEST Guennadi Liakhovetski wrote:
> >> On Tue, 17 Jul 2018, Laurent Pinchart wrote:
> >>> On T
;Unknown status event "
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index b36ad9eb8c80..e5f5d84f1d1d 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -261,7 +261,7 @@ struct uvc_control {
u8 *uvc_data;
- struct uvc_fh *handle; /* Used for asynchronous event delivery */
+ struct uvc_fh *handle; /* File handle that last changed the control. */
};
struct uvc_format_desc {
--
Regards,
Laurent Pinchart
Hi Guennadi,
On Wednesday, 25 July 2018 20:25:16 EEST Laurent Pinchart wrote:
> On Tuesday, 8 May 2018 18:07:43 EEST Guennadi Liakhovetski wrote:
> > UVC defines a method of handling asynchronous controls, which sends a
> > USB packet over the interrupt pipe. This patch impleme
Hi Guennadi,
On Wednesday, 25 July 2018 20:21:54 EEST Guennadi Liakhovetski wrote:
> On Wed, 25 Jul 2018, Laurent Pinchart wrote:
> > On Wednesday, 18 July 2018 09:55:27 EEST Guennadi Liakhovetski wrote:
> >> On Wed, 18 Jul 2018, Laurent Pinchart wrote:
> >>> On We
Hi Javier,
On Tuesday, 24 July 2018 15:35:17 EEST Javier Martinez Canillas wrote:
> On Thu, Jul 12, 2018 at 3:01 PM, Laurent Pinchart wrote:
>
> [snip]
>
> >> Laurent, thank you for your input on this. I thought it was a bit weird
> >> that the cam on my HP X2 o
t for
> such packets by sending a control event to the user. Since this can
> involve USB traffic and, therefore, scheduling, this has to be done
> in a work queue.
>
> Signed-off-by: Guennadi Liakhovetski
Reviewed-by: Laurent Pinchart
applied to my tree and pushed to the uvc/
STALLs
uvcvideo: Send a control event when a Control Change interrupt arrives
Kieran Bingham (1):
uvcvideo: Fix minor spelling
Laurent Pinchart (1):
uvcvideo: Add KSMedia 8-bit IR format support
Nicolas Dufresne (1):
uvcvideo: Also validate buffers in BULK mode
drivers
TA(V4L2_META_FMT_D4XX) },
> /* Generic USB Video Class */
> { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, UVC_PC_PROTOCOL_UNDEFINED) },
> { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, UVC_PC_PROTOCOL_15) },
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 0d07b2d..7d3fbc6 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -688,6 +688,7 @@ struct v4l2_pix_format {
> #define V4L2_META_FMT_VSP1_HGOv4l2_fourcc('V', 'S', 'P', 'H') /* R-Car
> VSP1 1-D Histogram */
> #define V4L2_META_FMT_VSP1_HGTv4l2_fourcc('V', 'S', 'P', 'T') /* R-Car
> VSP1 2-D Histogram */
> #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC
> Payload Header metadata */
> +#define V4L2_META_FMT_D4XXv4l2_fourcc('D', '4', 'X', 'X') /* D4XX
> Payload Header metadata */
>
> /* priv field value to indicates that subsequent fields are valid. */
> #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe
--
Regards,
Laurent Pinchart
> }
>
> static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm)
> @@ -736,9 +822,16 @@ unsigned int vsp1_dlm_irq_frame_end(struct
> vsp1_dl_manager *dlm) /* Hardware Setup */
> void vsp1_dlm_setup(struct vsp1_device *vsp1)
> {
> + unsigned i
/vsp1/vsp1_wpf.c | 6 +-
include/media/vsp1.h| 2 +
10 files changed, 468 insertions(+), 110 deletions(-)
--
Regards,
Laurent Pinchart
| 5 +
drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c | 6 +-
drivers/media/platform/soc_camera/soc_camera_platform.c | 5 +
14 files changed, 16 insertions(+), 58 deletions(-)
--
Regards,
Laurent Pinchart
Hi Pavel,
On Tuesday, 5 September 2017 20:27:39 EEST Pavel Rojtberg wrote:
> 2017-09-04 11:56 GMT+02:00 Laurent Pinchart:
> > On Monday, 4 September 2017 11:14:17 EEST Pavel Rojtberg wrote:
> >> From: Pavel Rojtberg
> >>
> >> attaching two Logite
The menu_info field of the uvc_control_mapping structure points to an
array of menu info data that are never changed by the driver. Make the
pointer const and constify the related static arrays in the driver.
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_ctrl.c | 10
Hi Christoph,
On Wednesday, 21 February 2018 23:24:36 EEST Laurent Pinchart wrote:
> On Wednesday, 21 February 2018 22:42:45 EET Christoph Fritz wrote:
> > Hi Laurent
> >
> >> Could you please send me the output of 'lsusb -d 199e:8302 -v' (if
> >> poss
a) static int isp_xclk_init(struct
> isp_device *isp)
> {
> struct device_node *np = isp->dev->of_node;
> - struct clk_init_data init = { 0 };
> + struct clk_init_data init = {};
How about = { NULL }; to avoid a gcc-specific syntax ?
> unsigned int i;
>
> for (i = 0; i < ARRAY_SIZE(isp->xclks); ++i)
--
Regards,
Laurent Pinchart
ntation. In particular the code should compute the 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
ations set the
> ``memory`` field to ``V4L2_MEMORY_USERPTR``, the ``m.userptr`` field to
> @@ -98,6 +98,25 @@ dequeued, until the :ref:`VIDIOC_STREAMOFF
> ` or
> :ref:`VIDIOC_REQBUFS` ioctl is called, or until the
>
> device is closed.
>
> +The ``request_fd`` field can be used with the ``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
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
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 Laurent Pinc
r_info 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/u
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
ass = USB_CLASS_VIDEO,
> > .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 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
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'
dle the rest this week.
--
Regards,
Laurent Pinchart
edia/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
ever still like to get the following information
- 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
akes to long to obtain that, let'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 f
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):
video.h
> > @@ -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
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
- if (ctrl->val == V4L2_EXPOSURE_MANUAL)
> - return 0;
> val = ov5640_get_exposure(sensor);
> if (val < 0)
> return val;
And same here.
--
Regards,
Laurent Pinchart
ual 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(-)
&g
0_set_mode(struct ov5640_dev *sensor,
> > >>
> > >> @@ -1626,7 +1614,7 @@ static int ov5640_set_mode(struct ov5640_dev
> > >> *sensor,
> > >>
> > >> return ret;
> > >>
> > >>
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
efmt(sensor, &sensor->fmt);
> ==> This is what have fixed Mita-san, this line was 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
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
> >
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,
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 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
on't like the name 'mutex'. Perhaps something 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
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
frame rate
> * @pad: pad number, as reported by the media API
> * @interval: frame interval in seconds
> @@ -117,8 +127,13 @@ struct v4l2_subdev_frame_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
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
er says :)
Is that the 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, Ricardo Ribalda
a new control (e.g.
> >> V4L2_CID_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 informed how the
> control values reflect to device configuration, 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
-by: 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-b
a pad graph object.
> *
> @@ -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
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
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
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
es, I think the flag can be dropped as I suggested.
>
> > Thus, I think that control over the rounding is tightly related to this
> > 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
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:
> >
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
.
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
ed to be modified, uvc being the most important of the
> lot.
>
> Any comments?
--
Regards,
Laurent Pinchart
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.
&
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
ivers/staging/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 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
ame.
>
> It looks 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
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
+
> +V4L2 userspace API - V4L2 API
> + 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
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
>
201 - 300 of 8133 matches
Mail list logo
