- 24 Apr, 2022 22 commits
-
-
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 <sakari.ailus@linux.intel.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
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:
Jacopo Mondi <jacopo@jmondi.org> Reviewed-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 <hverkuil-cisco@xs4all.nl> 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 18 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:
-
Mauro Carvalho Chehab authored
In order to make the drivers under dvb-usb more homogeneous, use the new macro. Link: https://lore.kernel.org/linux-media/c125c28aeb3d4344b632e1f99d81c433917f2a4c.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/283a8c6bdf9778f832b4f6acc104c06688281668.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/08861d80b6706ac1ed04a68959ebb78f27cb028d.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/58f1a356b7b75bbefef3aa07cd99896c446df32f.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/c6f6bab97c39561add54f69a75980f4d453f7c17.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/0d32148747df677f0c930605389c12b190c09bdf.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
In order to make the drivers under dvb-usb more homogeneous, use the new macro, and rename some PIDs. Link: https://lore.kernel.org/linux-media/828998ef3f0843bab4e84780e42f8f0802f57be7.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
In order to make the drivers under dvb-usb more homogeneous, use the new macro. Link: https://lore.kernel.org/linux-media/6e7183735aacf33fff86bc709a38aafb6b858dff.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/9fa3d1add4c58e1320dcc18578fda2d0106becda.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
In order to make the drivers under dvb-usb more homogeneous, use the new macro. Link: https://lore.kernel.org/linux-media/68de8820a361e61c25bf7402acac71b3770ff906.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
In order to make the drivers under dvb-usb more homogeneous, use the new macro. Link: https://lore.kernel.org/linux-media/bd1e61664e234252de3dfac16aab8bfc35b7bcd7.1648499509.git.mchehab@kernel.orgSigned-off-by:
-
