- 04 Jul, 2018 40 commits
-
-
Jacopo Mondi authored
Handle parallel subdevices in link_notify callback. If the notified link involves a parallel subdevice, do not change routing of the VIN-CSI-2 devices and mark the VIN instance as using a parallel input. If the CSI-2 link setup succeeds instead, mark the VIN instance as using CSI-2. Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Acked-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Jacopo Mondi authored
When running with media-controller link the parallel input media entities with the VIN entities at 'complete' callback time. To create media links the v4l2_device should be registered first. Check if the device is already registered, to avoid double registrations. Signed-off-by:
-
Jacopo Mondi authored
The rcar-vin driver so far had a mutually exclusive code path for handling parallel and CSI-2 video input subdevices, with only the CSI-2 use case supporting media-controller. As we add support for parallel inputs to Gen3 media-controller compliant code path now parse both port@0 and port@1, handling the media-controller use case in the parallel bound/unbind notifier operations. Signed-off-by:
-
Jacopo Mondi authored
Media bus configuration flags and media bus type were so far a property of each VIN instance, as the subdevice they were connected to was immutable during the whole system life time. With the forth-coming introduction of parallel input devices support, a VIN instance can have the subdevice it is connected to switched at runtime, from a CSI-2 subdevice to a parallel one and viceversa, through the modification of links between media entities in the media controller graph. To avoid discarding the per-subdevice configuration flags retrieved by v4l2_fwnode parsing facilities, cache them in the 'rvin_graph_entity' member of each VIN instance, opportunely renamed to 'rvin_parallel_entity'. Also modify the register configuration function to take mbus flags into account when running on a bus type that supports them. The media bus type currently in use will be updated in a follow-up patch to the link state change notification function. Signed-off-by:
-
Jacopo Mondi authored
During the notifier initialization, memory for the list of associated async subdevices is reserved during the fwnode endpoint parsing from the v4l2-async framework. If the notifier registration fails, that memory should be released and the notifier 'cleaned up'. Catch the notifier registration error and perform the cleanup both for the group and the parallel notifiers. Signed-off-by:
-
Jacopo Mondi authored
As CSI-2 subdevices are shared between several VIN instances, a shared notifier to collect the CSI-2 async subdevices is required. So far, the rcar-vin driver used the notifier of the last VIN instance to probe but with the forth-coming introduction of parallel input subdevices support in mc-compliant code path, each VIN may register its own notifier if any parallel subdevice is connected there. To avoid registering a notifier twice (once for parallel subdev and one for the CSI-2 subdevs) create a group notifier, shared by all the VIN instances. Signed-off-by:
-
Jacopo Mondi authored
Remove un-necessary empty lines. Signed-off-by:
-
Jacopo Mondi authored
As the term 'digital' is used all over the rcar-vin code in place of 'parallel', rename all the occurrencies. Signed-off-by:
-
Hans Verkuil authored
Request API requires a media node. Add one to the vim2m driver so we can use requests with it. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
A memory-to-memory pipeline device consists in three entities: two DMA engine and one video processing entities. The DMA engine entities are linked to a V4L interface. This commit add a new v4l2_m2m_{un}register_media_controller API to register this topology. For instance, a typical mem2mem device topology would look like this: Device topology - entity 1: source (1 pad, 1 link) type Node subtype V4L flags 0 pad0: Source -> "proc":1 [ENABLED,IMMUTABLE] - entity 3: proc (2 pads, 2 links) type Node subtype Unknown flags 0 pad0: Source -> "sink":0 [ENABLED,IMMUTABLE] pad1: Sink <- "source":0 [ENABLED,IMMUTABLE] - entity 6: sink (1 pad, 1 link) type Node subtype V4L flags 0 pad0: Sink <- "proc":0 [ENABLED,IMMUTABLE] [hans.verkuil@cisco.com: mark interface links as IMMUTABLE] Suggested-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
Currently links between entities and an interface are just marked as ENABLED. But (at least today) these links cannot be disabled by userspace or the driver, so they should also be marked as IMMUTABLE. It might become possible that drivers can disable such links (if for some reason the device node cannot be used), so we might need to add a new link flag at some point to mark interface links that can be changed by the driver but not by userspace. Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Hans Verkuil authored
When you switch from auto to manual mode for an auto-cluster (e.g. autogain+gain controls), then the current HW value has to be copied to the current control value. However, has_changed was never set to true, so new_to_cur didn't actually copy this value. Reported-by:
Hugues FRUCHET <hugues.fruchet@st.com> Tested-by:
-
Alexey Khoroshilov authored
viu_of_probe() ignores fails in i2c_get_adapter(), tries to unlock uninitialized mutex on error path. The patch streamlining the error handling in viu_of_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Philipp Zabel authored
This patch adds the i.MX6 CODA960 firmware versions 2.1.9 (revision 32515) to the list of supported firmware versions. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
Explicitly clear DEC_SEQ_JPG_THUMB_EN during sequence initialization. Not clearing the register does not cause problems, since the only other codec (MPEG-4 decode) that writes to this register happens to always write 0 as well. Signed-off-by:
-
Philipp Zabel authored
Padding the bitstream buffer is not enough to reliably avoid prefetch failures. Picture runs with the next buffer's header already visible to the CODA7541 succeed much more reliably, so always queue two JPEG frames into the bitstream buffer. Signed-off-by:
-
Philipp Zabel authored
The hardware codec is not colorspace aware. We should trust userspace to set the correct colorimetry information on the OUTPUT queue and mirror the exact same setting on the CAPTURE queue. There is no reason to restrict colorspace to JPEG for JPEG images, if userspace injects the correct colorspace information into the JPEG headers after encoding. Fixes: b14ac545 ("[media] coda: improve colorimetry handling") Signed-off-by:
-
Philipp Zabel authored
If new buffers are queued after streamoff, the flag will be cleared anyway, so this is mostly for the purpose of correctness. Signed-off-by:
-
Hans Verkuil authored
In the vivid driver you want gain to continuous change while autogain is on. However, dev->jiffies_vid_cap doesn't actually change. It probably did in the past, but changes in the code caused this to be a fixed value that is only set when you start streaming. Replace it by jiffies, which is always changing. [mchehab@kernel.org: use jiffies_to_msecs() instead of dividing by HZ] Signed-off-by:
-
Philipp Zabel authored
Whether reordering should be enabled only depends on the h.264 profile. Stop parsing the level and drop the debug message, profile and level can now be determined via read-only decoder controls. Signed-off-by:
-
Philipp Zabel authored
The decoder profile/level controls initially can be used to determine supported profiles and levels. The values are set for a given stream once the headers are parsed. Signed-off-by:
-
Philipp Zabel authored
The encoder picture run command takes a picture source stride parameter. This must be set to the output queue's bytesperline, not width. Signed-off-by:
-
Steve Longerbeam authored
When the imx-media driver was initially merged, there was a conflict with 8d67ae25 ("media: v4l2-ctrls: Reserve controls for MAX217X") which was not fixed up correctly, resulting in V4L2_CID_USER_MAX217X_BASE and V4L2_CID_USER_IMX_BASE taking on the same value. Fix by assigning imx CID base the next available range at 0x10b0. Signed-off-by:
Steve Longerbeam <steve_longerbeam@mentor.com> Acked-by:
-
Ezequiel Garcia authored
The vb2_queue will soon be mandatory. The videobuf2 core will throw a verbose warning if it's not set. The stk1160 driver is setting the queue lock, but after the vb2_queue_init call. Avoid the warning by setting the lock before the queue initialization. Signed-off-by:
-
Ezequiel Garcia authored
This driver is currently specifying a video_device lock, which means it is protecting all the ioctls (including queue ioctls) with a single mutex. It's therefore straightforward to implement wait_prepare and wait_finish, by explicitly setting the vb2_queue lock. Having these callbacks releases the queue lock while blocking, which improves latency by allowing for example streamoff or qbuf operations while waiting in dqbuf. Signed-off-by:
-
Ezequiel Garcia authored
This driver is currently specifying a video_device lock, which means it is protecting all the ioctls (including queue ioctls) with a single mutex. It's therefore straightforward to implement wait_prepare and wait_finish, by explicitly setting the vb2_queue lock. Having these callbacks releases the queue lock while blocking, which improves latency by allowing for example streamoff or qbuf operations while waiting in dqbuf. Signed-off-by:
-
Ezequiel Garcia authored
Currently, this driver does not serialize its video4linux ioctls, which is a bug, as race conditions might appear. In addition, video_device and vb2_queue locks are now both mandatory. Add them, and implement wait_prepare and wait_finish. To stay on the safe side, this commit uses a single mutex for both locks. Better latency can be obtained by separating these if needed. Signed-off-by:
-
Ezequiel Garcia authored
Use the device mutex to protect the vb2_queue. This allows to replace the ad-hoc wait_{prepare, finish} with vb2_ops_wait_{prepare, finish}. Signed-off-by: -
Ezequiel Garcia authored
This driver is currently specifying a vb2_queue lock, which means it straightforward to implement wait_prepare and wait_finish. Having these callbacks releases the queue lock while blocking, which improves latency by allowing for example streamoff or qbuf operations while waiting in dqbuf. Signed-off-by:
-
Ezequiel Garcia authored
Use the mutex in struct mtk_mdp_ctx to protect the capture and output vb2_queues. This allows to replace the ad-hoc wait_{prepare, finish} with vb2_ops_wait_{prepare, finish}. Signed-off-by: -
Ezequiel Garcia authored
Currently, this driver does not serialize its video4linux ioctls, which is a bug, as race conditions might appear. In addition, video_device and vb2_queue locks are now both mandatory. Add them, and implement wait_prepare and wait_finish. To stay on the safe side, this commit uses a single mutex for both locks. Better latency can be obtained by separating these if needed. Signed-off-by:
-
Hans Verkuil authored
For m2m devices the vdev->queue lock was always taken instead of the lock for the specific capture or output queue. Now that we pushed the locking down into __video_do_ioctl() we can pick the correct lock and potentially improve the performance of m2m devices. Signed-off-by:
-
Luca Ceresoli authored
pd -> pad Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by:
-
Luca Ceresoli authored
imx274_write_table() is a mere wrapper (and the only user) to imx274_regmap_util_write_table_8(). Remove this useless indirection by merging the two functions into one. Also get rid of the wait_ms_addr and end_addr parameters since it does not make any sense to give them any values other than IMX274_TABLE_WAIT_MS and IMX274_TABLE_END. Signed-off-by:
-
Luca Ceresoli authored
IMX274_DEFAULT_MODE is defined but not used. Start using it, so the default can be more easily changed without digging into the code. Signed-off-by:
-
Luca Ceresoli authored
After restructuring struct imx274_frmfmt, the mode_index field is still in use only for two dev_dbg() calls in imx274_s_stream(). Let's remove it and avoid duplicated information. Replacing the first usage requires some rather annoying but trivial pointer math. The other one can be removed entirely since it would print the same value anyway. Signed-off-by:
-
Luca Ceresoli authored
Data about the implemented readout modes is partially stored in imx274_formats[], the rest is scattered in several arrays. The latter are then accessed using the mode index, e.g.: min_frame_len[priv->mode_index] Consolidate all these data in imx274_formats[], and store a pointer to the selected mode (i.e. imx274_formats[priv->mode_index]) in the main device struct. This way code to use these data becomes more readable, e.g.: priv->mode->min_frame_len This removes lots of scaffolding code and keeps data about each mode in a unique place. Also remove a parameter to imx274_mode_regs() that is now unused. While this adds the mode pointer to the device struct, it does not remove the mode_index from it because mode_index is still used in two dev_dbg() calls. This will be handled in a follow-up commit. Signed-off-by:
-
Luca Ceresoli authored
The current probe function calls v4l2_ctrl_handler_setup() before initializing the format info. This triggers call paths such as: imx274_probe -> v4l2_ctrl_handler_setup -> imx274_s_ctrl -> imx274_set_exposure, where priv->mode_index is accessed before being assigned. This is wrong but does not trigger a visible bug because priv is zero-initialized and 0 is the default value for priv->mode_index. But this would become a crash in follow-up commits when mode_index is replaced by a pointer that must always be valid. Fix the bug before it shows up by initializing struct members early. Signed-off-by:
-
Bingbu Cao authored
Add a v4l2 sub-device driver for the ak7375 lens voice coil. This is a voice coil module using the i2c bus to control the focus position. ak7375 can write multiple bytes of data at a time. If more data is received instead of the stop condition after receiving one byte of data, the address inside the chip is automatically incremented and the data is written into the next address. The ak7375 can control the position with 12 bits value and consists of two 8 bit registers show as below: register 0x00(AK7375_REG_POSITION): +---+---+---+---+---+---+---+---+ |D11|D10|D09|D08|D07|D06|D05|D04| +---+---+---+---+---+---+---+---+ register 0x01: +---+---+---+---+---+---+---+---+ |D03|D02|D01|D00|---|---|---|---| +---+---+---+---+---+---+---+---+ This driver support : - set ak7375 to standby mode once suspend and turn it back to active if resume - set the position via V4L2_CID_FOCUS_ABSOLUTE ctrl [Sakari Ailus: Rename val as ret in probe, drop redundant error message] Signed-off-by:Tianshu Qiu <tian.shu.qiu@intel.com> Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Bingbu Cao authored
Add device tree bindings for AKM ak7375 voice coil lens driver. This chip is used to drive a lens in a camera module. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
