When controls are used together with the Request API, then for
each request a v4l2_ctrl_handler struct is allocated. This contains
the controls that can be set in a request. If a control is *not* set in
the request, then the value used in the most recent previous request
must be used, or the current value if it is not found in any outstanding
requests.
The framework tried to find such a previous request and it would set
the 'req' pointer in struct v4l2_ctrl_ref to the v4l2_ctrl_ref of the
control in such a previous request. So far, so good. However, when that
previous request was applied to the hardware, returned to userspace, and
then userspace would re-init or free that request, any 'ref' pointer in
still-queued requests would suddenly point to freed memory.
This was not noticed before since the drivers that use this expected
that each request would always have the controls set, so there was
never any need to find a control in older requests. This requirement
was relaxed, and now this bug surfaced.
It was also made worse by changeset
2fae4d6aab ("media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->req")
which increased the chance of this happening.
The use of the 'req' pointer in v4l2_ctrl_ref was very fragile, so
drop this entirely. Instead add a valid_p_req bool to indicate that
p_req contains a valid value for this control. And if it is false,
then just use the current value of the control.
Note that VIDIOC_G_EXT_CTRLS will always return -EACCES when attempting
to get a control from a request until the request is completed. And in
that case, all controls in the request will have the control value set
(i.e. valid_p_req is true). This means that the whole 'find the most
recent previous request containing a control' idea is pointless, and
the code can be simplified considerably.
The v4l2_g_ext_ctrls_common() function was refactored a bit to make
it more understandable. It also avoids updating volatile controls
in a completed request since that was already done when the request
was completed.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 2fae4d6aab ("media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->req")
Fixes: 6fa6f831f0 ("media: v4l2-ctrls: add core request support")
Cc: <stable@vger.kernel.org> # for v5.9 and up
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add keymaps and bindings for the simple IR (NEC) remotes used with
the MeCool KII-Pro and MeCool KIII-Pro Android STB devices.
Tested-by: Drazen Spio <drazsp@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Rename v4l2_async_register_subdev_sensor_common as
v4l2_async_register_subdev_sensor. This is a part of the effort to make
the long names present in V4L2 fwnode and async frameworks shorter.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Rename v4l2_async_notifier_parse_fwnode_sensor_common() as
v4l2_async_notifier_parse_fwnode_sensor() and make the function static, as
it's not used by a driver and maybe never will.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It was always assumed that walking the media graph would require holding
the media_device graph_mutex but this was not documented nor checked for.
Add a lockdep check to graph walk init and iter, and document the need for
acquiring the graph_mutex.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The plane size needs to be PAGE_ALIGNED, so it is not possible to have
sizes bigger than MAX_INT - PAGE_SIZE.
We already check for overflows when that happen:
if (size < vb->planes[plane].length)
goto free;
But it is good to explicitly state our max allowed value, in order to
align with the driver expectations.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
According to Rec. ITU-T T.872 (06/2012) 6.5.3
APP14 segment is for color encoding, it contains a transform flag, which
may have values of 0, 1 and 2 and are interpreted as follows:
0 - CMYK for images that are encoded with four components
- RGB for images that are encoded with three components
1 - An image encoded with three components using YCbCr colour encoding.
2 - An image encoded with four components using YCCK colour encoding.
This is used in imx-jpeg decoder, to distinguish between
YUV444 and RGB24.
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix these kernel-doc warnings:
include/media/davinci/vpbe_osd.h:77: warning: Enum value 'PIXFMT_YCBCRI' not described in enum 'osd_pix_format'
include/media/davinci/vpbe_osd.h:77: warning: Enum value 'PIXFMT_YCRCBI' not described in enum 'osd_pix_format'
include/media/davinci/vpbe_osd.h:77: warning: Excess enum value 'PIXFMT_YCrCbI' description in 'osd_pix_format'
include/media/davinci/vpbe_osd.h:77: warning: Excess enum value 'PIXFMT_YCbCrI' description in 'osd_pix_format'
include/media/davinci/vpbe_osd.h:232: warning: expecting prototype for enum davinci_cursor_v_width. Prototype was for enum
osd_cursor_v_width instead
include/uapi/linux/uvcvideo.h:98: warning: Function parameter or member 'ns' not described in 'uvc_meta_buf'
include/uapi/linux/uvcvideo.h:98: warning: Function parameter or member 'sof' not described in 'uvc_meta_buf'
include/uapi/linux/uvcvideo.h:98: warning: Function parameter or member 'length' not described in 'uvc_meta_buf'
include/uapi/linux/uvcvideo.h:98: warning: Function parameter or member 'flags' not described in 'uvc_meta_buf'
include/uapi/linux/uvcvideo.h:98: warning: Function parameter or member 'buf' not described in 'uvc_meta_buf'
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This fixes these kernel-doc warnings:
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI1A' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI1B' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI1C' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI2A' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI2B' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI2C' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI3A' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI3B' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI3C' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_CVBS_VI4A' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI2A_VI1A' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI2B_VI1B' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI2C_VI1C' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI2A_VI3A' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI2B_VI3B' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI2C_VI3C' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI4A_VI1A' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI4A_VI1B' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI4A_VI1C' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI4A_VI3A' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI4A_VI3B' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_SVIDEO_VI4A_VI3C' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:70: warning: Enum value 'INPUT_INVALID' not described in enum 'tvp514x_input'
include/media/i2c/tvp514x.h:82: warning: Enum value 'OUTPUT_10BIT_422_EMBEDDED_SYNC' not described in enum 'tvp514x_output'
include/media/i2c/tvp514x.h:82: warning: Enum value 'OUTPUT_20BIT_422_SEPERATE_SYNC' not described in enum 'tvp514x_output'
include/media/i2c/tvp514x.h:82: warning: Enum value 'OUTPUT_10BIT_422_SEPERATE_SYNC' not described in enum 'tvp514x_output'
include/media/i2c/tvp514x.h:82: warning: Enum value 'OUTPUT_INVALID' not described in enum 'tvp514x_output'
include/media/i2c/adv7343.h:38: warning: cannot understand function prototype: 'struct adv7343_power_mode '
include/media/i2c/s5k4ecgx.h:31: warning: expecting prototype for struct ss5k4ecgx_platform_data. Prototype was for struct
s5k4ecgx_platform_data instead
include/media/i2c/mt9t112.h:21: warning: cannot understand function prototype: 'struct mt9t112_platform_data '
include/media/i2c/noon010pc30.h:13: warning: Cannot understand * @clk_rate: the clock frequency in Hz
include/media/i2c/s5k6aa.h:45: warning: Function parameter or member 'bus_type' not described in 's5k6aa_platform_data'
include/media/i2c/tw9910.h:19: warning: cannot understand function prototype: 'enum tw9910_mpout_pin '
include/media/i2c/tw9910.h:36: warning: cannot understand function prototype: 'struct tw9910_video_info '
include/media/i2c/ov772x.h:53: warning: cannot understand function prototype: 'struct ov772x_camera_info '
include/media/i2c/s5c73m3.h:53: warning: Function parameter or member 'bus_type' not described in 's5c73m3_platform_data'
drivers/media/i2c/ccs/ccs-quirk.h:50: warning: Function parameter or member 'post_streamoff' not described in 'ccs_quirk'
drivers/media/i2c/ccs/ccs-quirk.h:50: warning: Function parameter or member 'flags' not described in 'ccs_quirk'
drivers/media/i2c/ccs/ccs-data.h:144: warning: expecting prototype for struct ccs_pdaf_pix_loc_block_desc. Prototype was for struct
ccs_pdaf_pix_loc_pixel_desc instead
drivers/media/i2c/tvp514x_regs.h:272: warning: Function parameter or member 'token' not described in 'tvp514x_reg'
drivers/media/i2c/tvp514x_regs.h:272: warning: Function parameter or member 'reg' not described in 'tvp514x_reg'
drivers/media/i2c/tvp514x_regs.h:272: warning: Function parameter or member 'val' not described in 'tvp514x_reg'
drivers/media/i2c/m5mols/m5mols.h:69: warning: Function parameter or member 'brightness' not described in 'm5mols_exif'
drivers/media/i2c/m5mols/m5mols.h:147: error: Cannot parse struct or union!
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_AIN0' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_AIN1' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_AIN2' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_AIN3' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_AIN4' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_AIN5' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_AIN6' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_AIN7' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_HDMI' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_TTL' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_TXA' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_TXB' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:65: warning: Enum value 'ADV748X_PORT_MAX' not described in enum 'adv748x_ports'
drivers/media/i2c/adv748x/adv748x.h:199: warning: Function parameter or member 'i2c_clients' not described in 'adv748x_state'
drivers/media/i2c/adv748x/adv748x.h:199: warning: Function parameter or member 'regmap' not described in 'adv748x_state'
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This patch fixes the following kernel-doc warnings:
include/uapi/linux/videodev2.h:996: warning: Function parameter or member 'm' not described in 'v4l2_plane'
include/uapi/linux/videodev2.h:996: warning: Function parameter or member 'reserved' not described in 'v4l2_plane'
include/uapi/linux/videodev2.h:1057: warning: Function parameter or member 'm' not described in 'v4l2_buffer'
include/uapi/linux/videodev2.h:1057: warning: Function parameter or member 'reserved2' not described in 'v4l2_buffer'
include/uapi/linux/videodev2.h:1057: warning: Function parameter or member 'reserved' not described in 'v4l2_buffer'
include/uapi/linux/videodev2.h:1068: warning: Function parameter or member 'tv' not described in 'v4l2_timeval_to_ns'
include/uapi/linux/videodev2.h:1068: warning: Excess function parameter 'ts' description in 'v4l2_timeval_to_ns'
include/uapi/linux/videodev2.h:1138: warning: Function parameter or member 'reserved' not described in 'v4l2_exportbuffer'
include/uapi/linux/videodev2.h:2237: warning: Function parameter or member 'reserved' not described in 'v4l2_plane_pix_format'
include/uapi/linux/videodev2.h:2270: warning: Function parameter or member 'hsv_enc' not described in 'v4l2_pix_format_mplane'
include/uapi/linux/videodev2.h:2270: warning: Function parameter or member 'reserved' not described in 'v4l2_pix_format_mplane'
include/uapi/linux/videodev2.h:2281: warning: Function parameter or member 'reserved' not described in 'v4l2_sdr_format'
include/uapi/linux/videodev2.h:2315: warning: Function parameter or member 'fmt' not described in 'v4l2_format'
include/uapi/linux/v4l2-subdev.h:53: warning: Function parameter or member 'reserved' not described in 'v4l2_subdev_format'
include/uapi/linux/v4l2-subdev.h:66: warning: Function parameter or member 'reserved' not described in 'v4l2_subdev_crop'
include/uapi/linux/v4l2-subdev.h:89: warning: Function parameter or member 'reserved' not described in 'v4l2_subdev_mbus_code_enum'
include/uapi/linux/v4l2-subdev.h:108: warning: Function parameter or member 'min_width' not described in 'v4l2_subdev_frame_size_enum'
include/uapi/linux/v4l2-subdev.h:108: warning: Function parameter or member 'max_width' not described in 'v4l2_subdev_frame_size_enum'
include/uapi/linux/v4l2-subdev.h:108: warning: Function parameter or member 'min_height' not described in 'v4l2_subdev_frame_size_enum'
include/uapi/linux/v4l2-subdev.h:108: warning: Function parameter or member 'max_height' not described in 'v4l2_subdev_frame_size_enum'
include/uapi/linux/v4l2-subdev.h:108: warning: Function parameter or member 'reserved' not described in 'v4l2_subdev_frame_size_enum'
include/uapi/linux/v4l2-subdev.h:119: warning: Function parameter or member 'reserved' not described in 'v4l2_subdev_frame_interval'
include/uapi/linux/v4l2-subdev.h:140: warning: Function parameter or member 'reserved' not described in 'v4l2_subdev_frame_interval_enum'
include/uapi/linux/cec.h:406: warning: Function parameter or member 'raw' not described in 'cec_connector_info'
include/uapi/linux/cec.h:470: warning: Function parameter or member 'flags' not described in 'cec_event'
include/media/v4l2-h264.h:82: warning: Function parameter or member 'reflist' not described in 'v4l2_h264_build_p_ref_list'
include/media/v4l2-h264.h:82: warning: expecting prototype for v4l2_h264_build_b_ref_lists(). Prototype was for v4l2_h264_build_p_ref_list()
instead
include/media/cec.h:50: warning: Function parameter or member 'lock' not described in 'cec_devnode'
include/media/v4l2-jpeg.h:122: warning: Function parameter or member 'num_dht' not described in 'v4l2_jpeg_header'
include/media/v4l2-jpeg.h:122: warning: Function parameter or member 'num_dqt' not described in 'v4l2_jpeg_header'
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Until now, the VP8 V4L2 API was not exported as a public API,
and only defined in a private media header (media/vp8-ctrls.h).
The reason for this was a concern about the API not complete
and ready to support VP8 decoding hardware accelerators.
After reviewing the VP8 specification in detail, and now
that the API is able to support Cedrus and Hantro G1,
we can consider this ready.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Before we move the VP8 controls to a stable public header,
rename this macro so it's clearly V4L2-specific.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move the VP8 stateless control types out of staging,
and re-number it to avoid any confusion.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Since we are ready to stabilize the VP8 stateless API,
move the parsed VP8 pixel format.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In preparation for making the interface public,
document all the structures.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Rename to struct v4l2_vp8_loop_filter, which is closer to the
VP8 syntax. This change is only cosmetics, but since this API
is exposed to userspace, it's worth the trouble to get it consistent.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It doesn't seem to add any clarity to have a "header" suffix in controls,
struct names and flags.
Since this just makes names too long without any benefit, just drop it.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a flags argument to the v4l2_create_fwnode_links_to_pad() function
to specify the link flags. This allows drivers to create immutable links
for instance.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The syntax without dots is available since commit 43756e347f
("scripts/kernel-doc: Add support for named variable macro arguments").
The same HTML output is produced with and without this patch.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Captured using a raw IR receiver. Manual linked in the remote definition
itself.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a keymap and bindings for the simple IR (NEC) remote used with
Minix 'NEO' branded Android STB devices.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The rc-cec keymap is unusual in that it can't be built as a module,
instead it is registered directly in rc-main.c if CONFIG_MEDIA_CEC_RC
is set. This is because it can be called from drm_dp_cec_set_edid() via
cec_register_adapter() in an asynchronous context, and it is not
allowed to use request_module() to load rc-cec.ko in that case. Trying to
do so results in a 'WARN_ON_ONCE(wait && current_is_async())'.
Since this keymap is only used if CONFIG_MEDIA_CEC_RC is set, we
just compile this keymap into the rc-core module and never as a
separate module.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 2c6d1fffa1 (drm: add support for DisplayPort CEC-Tunneling-over-AUX)
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
- replace mm/frame_vector.c by get_user_pages in misc/habana and
drm/exynos drivers, then move that into media as it's sole user
- close race in generic_access_phys
- s390 pci ioctl fix of this series landed in 5.11 already
- properly revoke iomem mappings (/dev/mem, pci files)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEb4nG6jLu8Y5XI+PfTA9ye/CYqnEFAmAzgywACgkQTA9ye/CY
qnFPbA//RUHB5bD7vwnEglfJhonKSi/Vt3dNQwUI+pCFK8muWvvPyTkGXKjjT2dI
uAOY2F23wymtIexV3fNLgnMez7kMcupOLkdxJic4GiO+HJn1jnkshdX7/dGtUW7O
G3yfnf/D27i912tT3j6PN7dVnasAYYtndCgImM027Zigzn4ibY+02tnzd5XTj1F8
yq8Swx88oqF8v10HxfpF3RLShqT3S17mFmd9dTv0GkZX497Pe75O44XcXzkD33Bj
wasH2Tz8gMEQx6TNAGlJe13dzDHReh2cG0z2r+6PTA6KnaMMxbEIImHNuhWOmHb/
nf8Jpu9uMOLzB+3hG3TzISTDBhAgPfoJ8Ov40VJCWMtCVBnyMyPJr28Oobb8Dj3V
SXvjSVlLeobOLt+E9vAS+Rmas07LCGBdNP9sexxV7S/sveSQ5W+FptaQW03EghwA
nBYEUC68WqpX99lJCFPmv5zmy5xkecjpU6mLHZljtV1ORzktqWZdVhmC8njHMAMY
Hi/emnPxEX1FpOD38rr7F9KUUSsy4t/ZaCgVaLcxCcbglCHXSHC41R09p9TBRSJo
G6Lksjyj4aa+UL5dZDAtLY0shg0bv2u93dGQNaDAC+uzj6D0ErBBzDK570zBKjp/
75+nqezJlD0d7I6rOl6FwiEYeSrYXJxYEveKVUr8CnH6sfeBlwo=
=lQoR
-----END PGP SIGNATURE-----
Merge tag 'topic/iomem-mmap-vs-gup-2021-02-22' of git://anongit.freedesktop.org/drm/drm
Pull follow_pfn() updates from Daniel Vetter:
"Fixes around VM_FPNMAP and follow_pfn:
- replace mm/frame_vector.c by get_user_pages in misc/habana and
drm/exynos drivers, then move that into media as it's sole user
- close race in generic_access_phys
- s390 pci ioctl fix of this series landed in 5.11 already
- properly revoke iomem mappings (/dev/mem, pci files)"
* tag 'topic/iomem-mmap-vs-gup-2021-02-22' of git://anongit.freedesktop.org/drm/drm:
PCI: Revoke mappings like devmem
PCI: Also set up legacy files only after sysfs init
sysfs: Support zapping of binary attr mmaps
resource: Move devmem revoke code to resource framework
/dev/mem: Only set filp->f_mapping
PCI: Obey iomem restrictions for procfs mmap
mm: Close race in generic_access_phys
media: videobuf2: Move frame_vector into media subsystem
mm/frame-vector: Use FOLL_LONGTERM
misc/habana: Use FOLL_LONGTERM for userptr
misc/habana: Stop using frame_vector helpers
drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
drm/exynos: Stop using frame_vector helpers
Fix kerneldoc documentation for functions that add async sub-devices to
notifiers. The functions themselves were improved recently but that left
issues with the kerneldoc documentation. Fix them now.
Also remove underscores from macro argument names.
[mchehab: fix a build breakage]
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: b01edcbd40 ("media: v4l2-async: Improve v4l2_async_notifier_add_*_subdev() API")
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The V4L2 temporary clock helper API, was introduced
in late 2012 and, as mentioned in the documentation,
meant to be replaced by the generic clock API,
once the generic clock framework became available
on all relevant architectures.
The generic clock API is a well-established API (since a few
years now). The last few media capture drivers and sensors
using v4l2-clk have been converted to the generic clock framework.
We can now remove the v4l2-clk API.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Acked-by: Petr Cvek <petrcvekcz@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that most users of v4l2_async_notifier_add_subdev have been converted,
let's fix the documentation so it's more clear how the v4l2-async API
should be used.
Document functions that drivers should use, and their purpose.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The functions that add an async subdev to an async subdev notifier take
as an argument the size of the container structure they need to
allocate. This is error prone, as passing an invalid size will not be
caught by the compiler. Wrap those functions in macros that take a
container type instead of a size, and cast the returned pointer to the
desired type. The compiler will catch mistakes if the incorrect type is
passed to the macro, as the assignment types won't match.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> (core+ti-cal)
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Most -if not all- use-cases are expected to be covered by one of:
v4l2_async_notifier_add_fwnode_subdev,
v4l2_async_notifier_add_fwnode_remote_subdev or
v4l2_async_notifier_add_i2c_subdev.
We'd like to discourage drivers from using v4l2_async_notifier_add_subdev,
so rename it as __v4l2_async_notifier_add_subdev. This is
typically a good hint for drivers to avoid using the function.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are no users for vpif_display_config.asd_sizes
and vpif_display_config.asd members, which means the v4l2-async
subdevices aren't being defined anywhere.
Remove the v4l2-async, leaving only the synchronous setup.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Change v4l2_async_notifier_add_fwnode_remote_subdev semantics
so it allocates the struct v4l2_async_subdev pointer.
This makes the API consistent: the v4l2-async subdevice addition
functions have now a unified usage model. This model is simpler,
as it makes v4l2-async responsible for the allocation and release
of the subdevice descriptor, and no longer something the driver
has to worry about.
On the user side, the change makes the API simpler for the drivers
to use and less error-prone.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The last user for this type of match was the soc-camera/sh_mobile_csi2
driver, which was removed in v4.9. If the support is ever needed,
it can always be restored.
[Sakari Ailus: Also drop DEVNAME from debug prints recently added.]
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is currently little to no information available about the reasons
why a v4l2-async device hasn't probed completely.
Inspired by the "devices_deferred" debugfs file, add a file to list
information about the subdevices that are on waiting lists, for each
notifier.
This is useful to debug v4l2-async subdevices and notifiers, for instance
when doing device bring-up.
For instance, a typical output would be:
$ cat /sys/kernel/debug/video4linux/pending_async_subdevices
ipu1_csi1:
[fwnode] dev=20e0000.iomuxc-gpr:ipu1_csi1_mux, node=/soc/bus@2000000/iomuxc-gpr@20e0000/ipu1_csi1_mux
ipu1_csi0:
[fwnode] dev=20e0000.iomuxc-gpr:ipu1_csi0_mux, node=/soc/bus@2000000/iomuxc-gpr@20e0000/ipu1_csi0_mux
imx6-mipi-csi2:
[fwnode] dev=1-003c, node=/soc/bus@2100000/i2c@21a4000/camera@3c
imx-media:
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Custom/driver-specific v4l2-async match support was introduced
in 2013, as V4L2_ASYNC_BUS_CUSTOM.
This type of match never had any user, so it's fair
to conclude it's not required and that safe for removal.
If the support is ever needed, it can always be restored.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
V4L2 fwnode bus types are enumerated in v4l2-fwnode.c, meaning they aren't
available to the rest of the kernel. Move the enum to the corresponding
header so that I can use the label to refer to those values.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Document that v4l2_async_notifier_parse_fwnode_endpoints() is deprecated.
Its functionality has been replaced by other, better functions. Also add a
reference to an example if someone ends up wandering here.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Pawel Osciak <pawel@osciak.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomasz Figa <tfiga@chromium.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201127164131.2244124-7-daniel.vetter@ffwll.ch
Rename v4l2_get_link_rate() as v4l2_get_link_freq(). What the function
returns is the frequency of the link; rename it to reflect the name of the
control where the information is obtained.
Fixes: 1b888b3ceb ("media: v4l: Add a helper for obtaining the link frequency")
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When unregistering a V4L2 device node, make sure any filehandles
that are waiting for an event are woken up.
Add v4l2_event_wake_all() to v4l2-event.c and call it from
video_unregister_device().
Otherwise userspace might never know that a device node was removed.
[hverkuil: checkpatch: replaced 'if (vdev == NULL)' by 'if (!vdev)']
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some CSI2 receivers support 8 data lanes.
So, this patch updates CSI2 maximum data lanes to be 8.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a keymap for the pine64 IR remote [0]. The mouse key has been mapped to
KEY_EPG to provide a more useful remote.
[0] http://files.pine64.org/doc/Pine%20A64%20Schematic/remote-wit-logo.jpg
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The FWHT stateless 'uAPI' was staging and marked explicitly in the
V4L2 specification that it will change and is unstable.
Note that these control IDs were never exported as a public API,
they were only defined in kernel-local headers (fwht-ctrls.h).
Now, the FWHT stateless controls is ready to be part
of the stable uAPI.
While not too late:
- Rename V4L2_CID_MPEG_VIDEO_FWHT_PARAMS to V4L2_CID_STATELESS_FWHT_PARAMS.
- Move the contents of fwht-ctrls.h to v4l2-controls.h.
- Move the public parts of drivers/media/test-drivers/vicodec/codec-fwht.h
to v4l2-controls.h.
- Add V4L2_CTRL_TYPE_FWHT_PARAMS control initialization and validation.
- Add p_fwht_params to struct v4l2_ext_control.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The H.264 stateless 'uAPI' was staging and marked explicitly in the
V4L2 specification that it will change and is unstable.
Note that these control IDs were never exported as a public API,
they were only defined in kernel-local headers (h264-ctrls.h).
Now, the H264 stateless controls is ready to be part
of the stable uAPI.
While not too late, let's rename them and re-number their
control IDs, moving them to the newly created stateless
control class, and updating all the drivers accordingly.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move the H264 stateless control types out of staging,
and re-number them to avoid any confusion.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Since we are ready to stabilize the H264 stateless API,
start by first moving the parsed H264 pixel format.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Check that all the fields that correspond or are related
to a H264 specification syntax element have legal values.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
