- 18 May, 2020 8 commits
-
-
Steve Longerbeam authored
media: Revert "media: v4l2-fwnode: Add a convenience function for registering subdevs with notifiers" The users of v4l2_async_register_fwnode_subdev() have switched to parsing their endpoints and setting up async sub-device lists in their notifiers locally, without using the endpoint parsing callbacks. There are no more users of v4l2_async_register_fwnode_subdev() so this convenience function can be removed. This reverts commit 1634f0ed. Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Steve Longerbeam authored
Instead of using the convenience functions v4l2_async_notifier_parse_fwnode_endpoints*() or v4l2_async_register_fwnode_subdev(), parse the input endpoints and set up the async sub-devices without using callbacks. The drivers know which ports it must parse and how to handle unconnected remotes, so it makes the code simpler to transfer control of endpoint parsing to the driver. Signed-off-by:
-
Steve Longerbeam authored
Instead of using the convenience function v4l2_async_register_fwnode_subdev(), parse the video-mux input endpoints and set up the async sub-devices without using callbacks. The video-mux knows which ports it must parse (the input ports) and how to handle unconnected remotes, so it makes the code simpler to transfer control of endpoint parsing to the driver. Signed-off-by:
-
Steve Longerbeam authored
Add functions to create media links between source and sink subdevices, based on the fwnode endpoint connections between them: v4l2_create_fwnode_links_to_pad() - create links from a source subdev to a single sink pad based on fwnode endpoint connections. v4l2_create_fwnode_links() - create all links from a source to sink subdev based on fwnode endpoint connections. These functions can be used in a sink's v4l2-async notifier subdev bound callback to make the links from the bound subdev. Signed-off-by: -
Steve Longerbeam authored
Add a convenience function that can be used as the .get_fwnode_pad operation for subdevices that map port numbers and pad indexes 1:1. The function verifies the endpoint is owned by the subdevice, and if so returns the endpoint port number. Signed-off-by:
-
Steve Longerbeam authored
Add a missing pointer to the entity in the media_entity operation get_fwnode_pad. There are no implementers of this op yet, but a future entity that does so will almost certainly need a reference to itself to carry out the work. operation") Fixes: ae45cd5e ("[media] media: entity: Add get_fwnode_pad entity Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Dafna Hirschfeld authored
When enumerating the frame sizes, the value sent to imx219_get_format_code should be fse->code (the code from the ioctl) and not imx219->fmt.code which is the code set currently in the driver. Fixes: 22da1d56 ("media: i2c: imx219: Add support for RAW8 bit bayer format") Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by:
Helen Koike <helen.koike@collabora.com> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by:
-
Jacopo Mondi authored
Implement the get_selection pad operation for the IMX219 sensor driver. The supported targets report the sensor's native size, the crop default rectangle and the crop rectangle. Reviewed-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
-
- 14 May, 2020 1 commit
-
-
Geert Uytterhoeven authored
Since its inclusion in v3.9, no users of the SuperH VEU mem2mem video processing driver have appeared upstream. All VEU devices in SuperH board code still bind to the "uio_pdrv_genirq" driver instead. The original author marked the driver orphaned in v3.15. Remove the driver; it can always be resurrected from git history when needed. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Rob Landley <rob@landley.net> Acked-by:
-
- 12 May, 2020 13 commits
-
-
Colin Ian King authored
The variable status is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Colin Ian King authored
The variable result is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Jia-Ju Bai authored
In ttusb_dec_handle_irq(), buffer[4] is continuously read from memory three times, without being modified. To reduce the number of memory reads, buffer[4] is first assigned to a local variable index, and then index is used to replace buffer[4]. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Colin Ian King authored
The variable val is being initializeed with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Colin Ian King authored
The variable bw is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Sean Young authored
Some IR protocols do not use a carrier. Signed-off-by:
-
Sean Young authored
usleep_range() may take longer than the max argument due to scheduling, especially under load. This is causing random errors in the transmitted IR. Remove the usleep_range() in favour of busy-looping with udelay(). Signed-off-by:
-
Hans Verkuil authored
Add documentation for the new VIDIOC_SUBDEV_QUERYCAP ioctl. Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
While normal video/radio/vbi/swradio nodes have a proper QUERYCAP ioctl that apps can call to determine that it is indeed a V4L2 device, there is currently no equivalent for v4l-subdev nodes. Adding this ioctl will solve that, and it will allow utilities like v4l2-compliance to be used with these devices as well. SUBDEV_QUERYCAP currently returns the version and capabilities of the subdevice. Define a capability flag to report if the subdevice is registered in read-only mode. Signed-off-by:
-
Jacopo Mondi authored
A sub-device device node can be registered in user space only if the CONFIG_VIDEO_V4L2_SUBDEV_API Kconfig option is selected. Currently the open/close file operations and the ioctl handler have some parts of their implementations guarded by #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API), while they are actually not accessible without a video device node registered to user space. Guard the whole open, close and ioctl handler and provide stubs if the VIDEO_V4L2_SUBDEV_API Kconfig option is not selected. This slightly reduces the kernel size when the option is not selected and simplifies the file ops and ioctl implementations. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Jacopo Mondi authored
Add to the V4L2 core a function to register device nodes for video subdevices in read-only mode. Registering a device node in read-only mode is useful to expose to userspace the current sub-device configuration, without allowing application to change it by using the V4L2 subdevice ioctls. Acked-by:
-
Jacopo Mondi authored
Document a new kAPI function to register subdev device nodes in read only mode and for each affected ioctl report how access is restricted. Acked-by:
-
Jacopo Mondi authored
Update the V4L2 sub-device userspace API introduction to provide more details on why complex devices might want to register devnodes for the connected subdevices. Acked-by:
-
- 06 May, 2020 8 commits
-
-
Mauro Carvalho Chehab authored
Sphinx 2.4.4 produces this warning: Documentation/admin-guide/media/ipu3.rst:235: WARNING: Title underline too short. Acked-by:
-
Hans Verkuil authored
Rework the documentation to make it easier for the reader to understand the differences in behavior of this ioctl between MC and non-MC drivers. Note the addition of the 'video-node-centric' and 'MC-centric' terms to help understand what the IO_MC capability really means. Also mention in the beginning that mbus_code is one of the fields that application should initialize, and add META_OUTPUT as one of the types that this ioctl supports (that was never added here when the META_OUTPUT buffer type was added). Finally document that EINVAL will be returned if mbus_code is unsupported. Fixes: e5b6b07a ("media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices") Signed-off-by:
-
Niklas Söderlund authored
Set the V4L2_CAP_IO_MC capability flag to report this vimc inputs/outputs are controlled by the media graph. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Niklas Söderlund authored
Set the V4L2_CAP_IO_MC capability flag and remove the driver specific vidioc_enum_{input,output}, vidioc_g_{input,output} and vidioc_s_{input,output} callbacks. Signed-off-by: -
Niklas Söderlund authored
Set the V4L2_CAP_IO_MC capability flag and remove the driver specific vidioc_enum_input, vidioc_g_input and vidioc_s_input callbacks for the media controller enabled part of the driver. Also add support mbus_code filtering for format enumeration. Signed-off-by:
-
Laurent Pinchart authored
The VIDIOC_ENUM_FMT ioctl enumerates all formats supported by a video node. For MC-centric devices, its behaviour has always been ill-defined, with drivers implementing one of the following behaviours: - No support for VIDIOC_ENUM_FMT at all - Enumerating all formats supported by the video node, regardless of the configuration of the pipeline - Enumerating formats supported by the video node for the active configuration of the connected subdevice The first behaviour is obviously useless for applications. The second behaviour provides the most information, but doesn't offer a way to find what formats are compatible with a given pipeline configuration. The third behaviour fixes that, but with the drawback that applications can't enumerate all supported formats anymore, and have to modify the active configuration of the pipeline to enumerate formats. The situation is messy as none of the implemented behaviours are ideal, and userspace can't predict what will happen as the behaviour is driver-specific. To fix this, let's extend the VIDIOC_ENUM_FMT with a missing capability: enumerating pixel formats for a given media bus code. The media bus code is passed through the v4l2_fmtdesc structure in a new mbus_code field (repurposed from the reserved fields). With this capability in place, applications can enumerate pixel formats for a given media bus code without modifying the active configuration of the device. The current behaviour of the ioctl is preserved when the new mbus_code field is set to 0, ensuring compatibility with existing userspace. The API extension is documented as mandatory for MC-centric devices (as advertised through the V4L2_CAP_IO_MC capability), allowing applications and compliance tools to easily determine the availability of the VIDIOC_ENUM_FMT extension. Signed-off-by:
-
Laurent Pinchart authored
Replace initialization of static const v4l2_fmtdesc instances that specify every struct member with designated initializers. This allows not zeroing the reserved fields explicitly, and will avoid a need to patch these drivers every time a reserved field is repurposed. Signed-off-by:
-
Niklas Söderlund authored
Add a video device capability flag to indicate that its inputs and/or outputs are controlled by the Media Controller instead of the V4L2 API. When this flag is set, ioctl for enum inputs and outputs are automatically enabled and programmed to call a helper function. Suggested-by:
-
- 05 May, 2020 10 commits
-
-
Mauro Carvalho Chehab authored
After adding all cardlists, this file became too big. Split it on smaller files, in order to make easier to maintain. Signed-off-by: -
Mauro Carvalho Chehab authored
On several parts of the document, it mentions "PCI ID", when it is actually referring to the subsystem's part of the PCI ID. Change the language to let it be clear. Signed-off-by: -
Dan Carpenter authored
The log_addrs->log_addr_type[i] value is a u8 which is controlled by the user and comes from the ioctl. If it's over 31 then that results in undefined behavior (shift wrapping) and that leads to a Smatch static checker warning. We already cap the value later so we can silence the warning just by re-ordering the existing checks. I think the UBSan checker will also catch this bug at runtime and generate a warning. But otherwise the bug is harmless. Fixes: 9881fe0c ("[media] cec: add HDMI CEC framework (adapter)") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Christophe JAILLET authored
It is spurious to call 'clk_disable_unprepare()' when 'clk_prepare_enable()' has not been called yet. Re-order the error handling path to avoid it. Fixes: a4260ea4 ("media: sun4i: Add H3 deinterlace driver") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Nícolas F. R. A. Prado authored
Add support for RGB888_*, BGR888_* and GBR888_* media bus formats on the source pad of debayer subdevices. Acked-by:
Vitor Massaru Iha <vitor@massaru.org> Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@protonmail.com> Signed-off-by:
-
Nícolas F. R. A. Prado authored
Add missing RGB888_*, BGR888_* and GBR888_* media bus codes in the vimc_pix_map_list. Since there is no GBR24 pixelformat, use the RGB24 pixelformat for MEDIA_BUS_FMT_GBR888_1X24. Acked-by:
-
Nícolas F. R. A. Prado authored
Change vimc_pix_map_list to allow multiple media bus codes to map to the same pixelformat, making it possible to add media bus codes for which there are no pixelformat. Acked-by:
-
Arnd Bergmann authored
gcc warns about empty array declarations, which we get in this driver when compile-testing without CONFIG_OF: drivers/media/platform/ti-vpe/cal.c:2194:34: warning: array 'cal_of_match' assumed to have one element 2194 | static const struct of_device_id cal_of_match[]; Since all users of this driver do need CONFIG_OF anyway, there is no point in making the array definition conditional to save space, so just remove the #ifdef and move the array up a little. Fixes: 343e89a7 ("[media] media: ti-vpe: Add CAL v4l2 camera capture driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
John Oldman authored
Correct spelling in comment Signed-off-by:
John Oldman <john.oldman@polehill.co.uk> Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Steve Longerbeam <slongerbeam@gmail.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: devel@driverdev.osuosl.org Signed-off-by:
Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by:
-
