- 24 Apr, 2022 33 commits
-
-
Tomi Valkeinen authored
v4l2_subdev_alloc_state() and v4l2_subdev_free_state() are not supposed to be used by the drivers. However, we do have a few drivers that use those at the moment, so we need to expose these functions for the time being. Prefix the functions with __ to mark the functions as internal. At the same time, rename them to v4l2_subdev_state_alloc and v4l2_subdev_state_free to match the style used for other functions like video_device_alloc() and media_request_alloc(). Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Tomi Valkeinen authored
subdev_open() is inside #ifdef CONFIG_VIDEO_V4L2_SUBDEV_API, which depends on CONFIG_MEDIA_CONTROLLER, so there's no need for an extra Signed-off-by:
-
Tomi Valkeinen authored
Add comments after #endifs to clarify their scope. Signed-off-by:
-
Jacopo Mondi authored
The ov5645 driver reports as its unique supported format MEDIA_BUS_FMT_UYVY8_2X8, which is not correct as the sensor uses the MIPI CSI-2 serial bus. Fix that by using MEDIA_BUS_FMT_UYVY8_1X16 instead. Signed-off-by:
-
Hangyu Hua authored
media_gobj_destroy has already set graph_obj.mdev to NULL. There is no need to set it again. [Sakari Ailus: Remove extra newline, rewrap commit msg] Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Reviewed-by:
-
Umang Jain authored
Use an existing helper imgu_video_nodes_exit() on imgu-video-node initialization failure path to cleanup dummy buffers. Signed-off-by:
Umang Jain <umang.jain@ideasonboard.com> Reviewed-by:
-
Umang Jain authored
Reset the sequence number of imgu_video_device on stream start. Failing to do so results in sequence number getting incremented for consecutive stream on/off cycles. Signed-off-by:
-
Laurent Pinchart authored
Matching on device fwnode handles is deprecated in favour of endpoint fwnode handles. Switch the __v4l2_async_nf_add_fwnode_remote() function to use the latter. The match code handles backward compatibility by falling by to the device fwnode handle, so this shouldn't introduce any regression. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
Primarily request a specific revision of the IPU3 firmware that the driver is known to work with, irci_irci_ecr-master_20161208_0213_20170112_1500.bin. Some distros only ship this while others provide a symlink called ipu3-fw.bin, which the driver only requested previously. Signed-off-by:
-
Kate Hsuan authored
For the AF configuration, if the rightmost stripe is used, the AF scene will be at the incorrect location of the sensor. The AF coordinate may be set to the right part of the sensor. This configuration would lead to x_start being greater than the down_scaled_stripes offset and the leftmost stripe would be disabled and only the rightmost stripe is used to control the AF coordinate. If the x_start doesn't perform any adjustments, the AF coordinate will be at the wrong place of the sensor since down_scaled_stripes offset would be the new zero of the coordinate system. In this patch, if only the rightmost stripe is used, x_start should minus down_scaled_stripes offset to maintain its correctness of AF scene coordinate. Signed-off-by:
Kate Hsuan <hpa@redhat.com> Signed-off-by:
-
Laurentiu Palcu authored
When removing the max9286 module we get a kernel oops: Unable to handle kernel paging request at virtual address 000000aa00000094 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000 [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : i2c_mux_del_adapters+0x24/0xf0 lr : max9286_remove+0x28/0xd0 [max9286] sp : ffff800013a9bbf0 x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000 x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8 x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000 Call trace: i2c_mux_del_adapters+0x24/0xf0 max9286_remove+0x28/0xd0 [max9286] i2c_device_remove+0x40/0x110 __device_release_driver+0x188/0x234 driver_detach+0xc4/0x150 bus_remove_driver+0x60/0xe0 driver_unregister+0x34/0x64 i2c_del_driver+0x58/0xa0 max9286_i2c_driver_exit+0x1c/0x490 [max9286] __arm64_sys_delete_module+0x194/0x260 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xd4/0xfc do_el0_svc+0x2c/0x94 el0_svc+0x28/0x80 el0t_64_sync_handler+0xa8/0x130 el0t_64_sync+0x1a0/0x1a4 The Oops happens because the I2C client data does not point to max9286_priv anymore but to v4l2_subdev. The change happened in max9286_init() which calls v4l2_i2c_subdev_init() later on... Besides fixing the max9286_remove() function, remove the call to i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make the necessary changes to max9286_init() so that it doesn't have to use i2c_get_clientdata() in order to fetch the pointer to priv. Fixes: 66d8c9d2 ("media: i2c: Add MAX9286 driver") Signed-off-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
The bus_info field is set by most drivers based on the type of the device bus as well as the name of the device. Do this in v4l_querycap() so drivers don't need to. This keeps compatibility with non-default and silly bus_info. Signed-off-by:
-
Sakari Ailus authored
Set bus_info field based on struct device in media_device_init() and remove corresponding code from drivers. Also update media_device_init() documentation: the dev field must be now initialised before calling it. Signed-off-by:
-
Sakari Ailus authored
The bus_info or a similar field exists in a lot of structs, yet drivers tend to set the value of that field by themselves in a determinable way. Thus provide a helper for doing this. To be used in subsequent patches. Signed-off-by:
-
Sakari Ailus authored
The documentation for media_device_init() had several references to (struct) media_entity where it should have referred to struct media_device instead. Fix this. Signed-off-by:
-
Sakari Ailus authored
Remove redundant kerneldoc documentation in mc-device.c. The functions are already documented in media-device.h, where non-redundant documentation is also moved. Signed-off-by:
-
Sakari Ailus authored
Use an unsigned int to index an array instead of a signed one. Signed-off-by:
-
Sakari Ailus authored
Use %u for printing unsigned integer or u32 values. In a lot of cases %d was being used instead. Also remove an extra debug print --- the number of lanes is already printed by V4L2 when parsing fwnode endpoints when dynamic debug is enabled. Signed-off-by:
-
Daniel Scally authored
Upon an async fwnode match, there's some typical behaviour that the notifier and matching subdev will want to do. For example, a notifier representing a sensor matching to an async subdev representing its VCM will want to create an ancillary link to expose that relationship to userspace. To avoid lots of code in individual drivers, try to build these links within v4l2 core. Signed-off-by:
Daniel Scally <djrscally@gmail.com> Reviewed-by:
Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by:
-
Daniel Scally authored
Add functions to create ancillary links, so that they don't need to be manually created by users. Reviewed-by:
-
Daniel Scally authored
Now we have three types of media link, printing the right name during debug output is slightly more complicated. Add a helper function to make it easier. Reviewed-by:
-
Daniel Scally authored
To describe in the kernel the connection between devices and their supporting peripherals (for example, a camera sensor and the vcm driving the focusing lens for it), add a new type of media link to introduce the concept of these ancillary links. Add some elements to the uAPI documentation to explain the new link type, their purpose and some aspects of their current implementation. Reviewed-by:
-
Daniel Scally authored
When iterating over the media graph, don't follow links that are not data links. Reviewed-by:
-
Yunke Cao authored
The original implementation removes reverse links for any input link and assumes the presense of sink/source. It fails when the link is a not a data link. media_entity_remove_links when there's an ancillary link can also fail. We only need to remove reverse links for a data link. Signed-off-by:
Yunke Cao <yunkec@google.com> Signed-off-by:
-
Jacopo Mondi authored
Add support for MEDIA_BUS_FMT_JPEG_1X8 media bus code to the CSIS driver. The MEDIA_BUS_FMT_JPEG_1X8 code is mapped to the RAW8 CSI-2 Data Type, while the CSI-2 specification suggests to use User Defined Data Type 1. As reported in the comment, the CSIS interface captures arbitrary Data Types by using a pixel sampling mode not supported by the IP core connected to it on i.MX SoCs. As some sensors, such as OV5640, support sending JPEG data on the RAW8 Data Type and capture operations work correcty with such configuration, map MEDIA_BUS_FMT_JPEG_1X8 to Data Type 0x2a. Signed-off-by:
-
Hans Verkuil authored
This new optional callback is called when the adapter is fully configured or fully unconfigured. Some drivers may have to take action when this happens. Signed-off-by:
-
Hans Verkuil authored
Allow drivers to change the transmit timeout value, i.e. after how long should a transmit be considered 'lost', i.e. the corresponding cec_transmit_done_ts was never called. Some CEC devices have their own timeout, and so this timeout value must be longer than that hardware timeout value. If it is shorter then the framework would consider the transmit lost, even though it is effectively still in progress at the hardware level. Signed-off-by:
-
Hans Verkuil authored
Use call_(void_)op consistently in the CEC core framework. Ditto for the cec pin ops. And check if !adap->devnode.unregistered before calling each op. This avoids calls to ops when the device has been unregistered and the underlying hardware may be gone. Signed-off-by:
-
Hans Verkuil authored
These two helper functions return true if the received message contains the result of a previous non-blocking transmit. Either the tx_status result (cec_msg_recv_is_tx_result) of the transmit, or the rx_status result (cec_msg_recv_is_rx_result) of the reply to the original transmit. Signed-off-by:
-
Hans Verkuil authored
The results of non-blocking transmits were not correctly communicated to userspace. Specifically: 1) if a non-blocking transmit was canceled, then rx_status wasn't set to 0 as it should. 2) if the non-blocking transmit succeeded, but the corresponding reply never arrived (aborted or timed out), then tx_status wasn't set to 0 as it should, and rx_status was hardcoded to ABORTED instead of the actual reason, such as TIMEOUT. In addition, adap->ops->received() was never called, so drivers that want to do message processing themselves would not be informed of the failed reply. Signed-off-by:
-
Hans Verkuil authored
If a transmit-in-progress was canceled, then, once the transmit is done, mark it as aborted and refrain from retrying the transmit. To signal this situation the new transmit_in_progress_aborted field is set to true. The old implementation would just set adap->transmitting to NULL and set adap->transmit_in_progress to false, but on the hardware level the transmit was still ongoing. However, the framework would think the transmit was aborted, and if a new transmit was issued, then it could overwrite the HW buffer containing the old transmit with the new transmit, leading to garbled data on the CEC bus. Signed-off-by:
-
Hans Verkuil authored
Don't enable/disable the adapter if the first fh is opened or the last fh is closed, instead do this when the adapter is configured or unconfigured, and also when we enter Monitor All or Monitor Pin mode for the first time or we exit the Monitor All/Pin mode for the last time. However, if needs_hpd is true, then do this when the physical address is set or cleared: in that case the adapter typically is powered by the HPD, so it really is disabled when the HPD is low. This case (needs_hpd is true) was already handled in this way, so this wasn't changed. The problem with the old behavior was that if the HPD goes low when no fh is open, and a transmit was in progress, then the adapter would be disabled, typically stopping the transmit immediately which leaves a partial message on the bus, which isn't nice and can confuse some adapters. It makes much more sense to disable it only when the adapter is unconfigured and we're not monitoring the bus, since then you really won't be using it anymore. To keep track of this store a CEC activation count and call adap_enable only when it goes from 0 to 1 or back to 0. Signed-off-by:
-
Yihao Han authored
Remove dev_err() messages after platform_get_irq*() failures. platform_get_irq() already prints an error. Generated by: scripts/coccinelle/api/platform_get_irq.cocci Signed-off-by:
Yihao Han <hanyihao@vivo.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
- 18 Apr, 2022 7 commits
-
-
Mauro Carvalho Chehab authored
The device number is currently a value that needs to be the same on two separate tables, but the code doesn't actually enforce it, leading to errors as boards get added or removed. Fix it by using an enum. Link: https://lore.kernel.org/linux-media/028699ec71158dbc49d710a4259eb8cdb7f673cb.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
The device number is currently a value that needs to be the same on two separate tables, but the code doesn't actually enforce it, leading to errors as boards get added or removed. Fix it by using an enum. Link: https://lore.kernel.org/linux-media/f1d4fa4960b709152ae693800c830e19a4bc1f48.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
The device number is currently a value that needs to be the same on two separate tables, but the code doesn't actually enforce it, leading to errors as boards get added or removed. Fix it by using an enum. Link: https://lore.kernel.org/linux-media/a300c26ad4e9bb913e86eeaf0ec7d72b9e7d5d3e.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
The device number is currently a value that needs to be the same on two separate tables, but the code doesn't actually enforce it, leading to errors as boards get added or removed. Fix it by using an enum. Link: https://lore.kernel.org/linux-media/0241bf842bf592dfa01b0ef4916afda396194f98.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
The device number is currently a value that needs to be the same on two separate tables, but the code doesn't actually enforce it, leading to errors as boards get added or removed. Fix it by using an enum. Link: https://lore.kernel.org/linux-media/13bf6aab3909fae5da4c9a24c114b15e76abd146.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
The device number is currently a value that needs to be the same on two separate tables, but the code doesn't actually enforce it, leading to errors as boards get added or removed. Fix it by using an enum. Link: https://lore.kernel.org/linux-media/5fd3c469faa115856f48037019e607edcb41d458.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
The device number is currently a value that needs to be the same on two separate tables, but the code doesn't actually enforce it, leading to errors as boards get added or removed. Fix it by using an enum. Link: https://lore.kernel.org/linux-media/b447d9fd3832da5eff6267e8fe742c431f1133f2.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
