- 28 Aug, 2020 16 commits
-
-
Sowjanya Komatineni authored
With the split of MIPI calibration into tegra_mipi_calibrate() and tegra_mipi_wait(), MIPI clock is not kept enabled and mutex is not locked till the calibration is done. So, this patch keeps MIPI clock enabled and mutex locked after triggering start of calibration till its done. To let calibration process go through its finite sequence codes before calibration logic waiting for pads idle state added wait time of 75usec to make sure it sees idle state to apply the results. This patch renames tegra_mipi_calibrate() as tegra_mipi_start_calibration() and tegra_mipi_wait() as tegra_mipi_finish_calibration() to be inline with their usage. Reviewed-by: Dmitry Osipenko <digetx@gmail.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>
-
Sowjanya Komatineni authored
This patch adds selection v4l2 ioctl operations to allow configuring a selection rectangle in the sensor through the Tegra video device node. Some sensor drivers supporting crop uses try_crop rectangle from v4l2_subdev_pad_config during try format for computing binning. So with selection ops support, this patch also updates try format to use try crop rectangle either from subdev frame size enumeration or from subdev crop boundary. 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>
-
Sowjanya Komatineni authored
This patch adds support to capture from the external sensor based on device graph in the device tree. Driver walks through the device graph to create media links between the entities and registers and unregisters video devices when the corresponding sub-devices are bound and unbound. Channel formats are enumerated based on available formats from the sensor and the corresponding matched formats from the Tegra supported video formats list. Each Tegra CSI instance can be configured as 4-lane or 2-lane based on supported lane configuration from the sensor through the device tree. Currently this driver supports V4L2 video node centric only. [hverkuil: changed video_unregister_device to vb2_video_unregister_device] 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>
-
Sowjanya Komatineni authored
This patch separates implementation of CSI stream enable and disable into separate functions for readability. Reviewed-by: Dmitry Osipenko <digetx@gmail.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>
-
Sowjanya Komatineni authored
Update VI and CSI bindings to add port and endpoint nodes as per media video-interfaces DT binding document. Acked-by: Rob Herring <robh@kernel.org> 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>
-
Sowjanya Komatineni authored
Tegra VI supported video formats are more for non TPG and there can be multiple pixel formats for the same media bus format. This patch updates the helper function for format lookup based on mbus code from pre-defined Tegra supported format list to look from the specified list index offset. Offset based look up is used with sensor device graph (non TPG) where format enumeration can list all supported formats for the specific sensor mbus codes. 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>
-
Sowjanya Komatineni authored
Tegra internal TPG mode is only for Tegra vi and csi testing without a real sensor and driver should default support real sensor. So, This patch adds CONFIG_VIDEO_TEGRA_TPG and enables Tegra internal TPG mode only when this config is selected. 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>
-
Sowjanya Komatineni authored
Pixel format width is mistakenly aligned to surface align bytes and altering width to aligned value may force sensor mode change other than the requested one and also cause mismatch in width programmed between sensor and vi which can lead to capture errors. This patch removes width alignment and clamps width as per Tegra minimum and maximum limits. 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>
-
Hans Verkuil authored
This is only needed for drivers that do not use vb2_fop_release(). Note that vb2_queue_release() is *not* the counterpart of vb2_queue_init() as some drivers here seem to think. Also use vb2_video_unregister_device() to automatically stop streaming at unregister time for those drivers that set vdev->queue. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Use vb2_video_unregister_device() to automatically stop streaming at unregister time. This avoids the use of vb2_queue_release() which should not be called by drivers that set vdev->queue. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Use vb2_video_unregister_device() to automatically stop streaming at unregister time. This avoids the use of vb2_queue_release() which should not be called by drivers that set vdev->queue. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
This is only needed for drivers that do not use vb2_fop_release(). Note that vb2_queue_release() is *not* the counterpart of vb2_queue_init() as some drivers here seem to think. Also use vb2_video_unregister_device() to automatically stop streaming at unregister time for those drivers that set vdev->queue. Note that sun4i-csi didn't unregister the video device at all. That's now fixed. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Use vb2_video_unregister_device() to automatically stop streaming at unregister time. This avoids the use of vb2_queue_release() which should not be called by drivers that set vdev->queue. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Use vb2_video_unregister_device() to automatically stop streaming at unregister time. This avoids the use of vb2_queue_release() which should not be called by drivers that set vdev->queue. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Tested-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
If a driver calls (_)vb2_fop_release(), then such a driver should also call vb2_video_unregister_device() instead of video_unregister_device(). This helper will call vb2_queue_release() if a filehandle is marked as owner of the queue. This ensures that at unregister time any streaming is cancelled and all buffers are returned to userspace. This is very useful for complex drivers since this stops all streaming in all subdevs in the pipeline controlled by this video device. Otherwise this would be delayed until the owner filehandle is closed, which can be quite some time later. Bonus points for ordering the includes :-) Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Kieran Bingham authored
The files maintained as part of the RDACM20 were incorrectly sorted while they were added. Correct the sort-order. Fixes: 34009bff ("media: i2c: Add RDACM20 driver") Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 26 Aug, 2020 13 commits
-
-
Helen Koike authored
Add Dafna Hirschfeld to rkisp1 maintainers list Signed-off-by: Helen Koike <helen.koike@collabora.com> Acked-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Christopher Snowhill authored
This small change adds the device identifier for the MyGica iGrabber, which features an Empia EM2860, a Philips SAA7113, Empia EMP202, and no tuner. Verified that both the composite and S-Video inputs work with NTSC source. It does not appear to need any port twiddling on pre-init. Signed-off-by: Christopher Snowhill <chris@kode54.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Tom Rix authored
clang static analysis reports this problem tuner-simple.c:714:13: warning: Assigned value is garbage or undefined buffer[1] = buffer[3]; ^ ~~~~~~~~~ In simple_set_radio_freq buffer[3] used to be done in-function with a switch of tuner type, now done by a call to simple_radio_bandswitch which has this case case TUNER_TENA_9533_DI: case TUNER_YMEC_TVF_5533MF: tuner_dbg("This tuner doesn't ... return 0; which does not set buffer[3]. In the old logic, this case would have returned 0 from simple_set_radio_freq. Recover this old behavior by returning an error for this codition. Since the old simple_set_radio_freq behavior returned a 0, do the same. Fixes: c7a9f3aa ("V4L/DVB (7129): tuner-simple: move device-specific code into three separate functions") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Peilin Ye authored
Setting `hue` by calling tpg_s_hue() directly is risky, since it does not perform range check. Clamp `hue` to the valid range in tpg_s_hue(). Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Peilin Ye authored
vivid_meta_out_process() is setting `brightness`, `contrast`, `saturation` and `hue` using tpg_s_*(). This is wrong, since tpg_s_*() do not provide range checks. Using tpg_s_*() here also makes the control framework out-of-sync with the actual values. Use v4l2_ctrl_s_ctrl() instead. This issue has been reported by syzbot as an out-of-bounds read bug in precalculate_color(). Reported-and-tested-by: syzbot+02d9172bf4c43104cd70@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=02d9172bf4c43104cd70 Fixes: 746facd3 ("media: vivid: Add metadata output support") Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Alexandre Courbot authored
The Kconfig help text for VIDEO_MEDIATEK_VCODEC was referring to a single module named mtk-vcodec, while this driver produces two modules named mtk-vcodec-dec and mtk-vcodec-enc. Fix that. Reported-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hsin-Yi Wang authored
Set dma max segment size for encoder and decoder driver. Fix following warning with CONFIG_DMA_API_DEBUG_SG=y [ 75.147825] ------------[ cut here ]------------ [ 75.147844] mtk-vcodec-enc 19002000.vcodec: DMA-API: mapping sg segment longer than device claims to support [len=983040] [max=65536] [ 75.147876] WARNING: CPU: 2 PID: 4069 at kernel/dma/debug.c:1302 debug_dma_map_sg+0x1a8/0x2c4 ... [ 75.148139] Call trace: [ 75.148149] debug_dma_map_sg+0x1a8/0x2c4 [ 75.148165] vb2_dc_get_userptr+0x228/0x364 [videobuf2_dma_contig] [ 75.148178] __buf_prepare+0x3ac/0x8c0 [videobuf2_common] [ 75.148188] vb2_core_qbuf+0xa4/0x58c [videobuf2_common] [ 75.148199] vb2_qbuf+0x88/0xe4 [videobuf2_v4l2] [ 75.148211] v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem] [ 75.148221] vidioc_venc_qbuf+0x3c/0x70 [mtk_vcodec_enc] [ 75.148234] v4l_qbuf+0x48/0x58 [ 75.148242] __video_do_ioctl+0x200/0x37c [ 75.148250] video_usercopy+0x360/0x834 [ 75.148259] video_ioctl2+0x38/0x48 [ 75.148267] v4l2_ioctl+0x6c/0x80 [ 75.148276] do_video_ioctl+0xefc/0x4b70 [ 75.148284] v4l2_compat_ioctl32+0x5c/0xcc [ 75.148294] __arm64_compat_sys_ioctl+0xf4/0x240 [ 75.148304] el0_svc_common+0xac/0x198 [ 75.148312] el0_svc_compat_handler+0x2c/0x40 [ 75.148321] el0_svc_compat+0x8/0x18 [ 75.148328] irq event stamp: 0 [ 75.148337] hardirqs last enabled at (0): [<0000000000000000>] (null) [ 75.148347] hardirqs last disabled at (0): [<ffffff90080e65c0>] copy_process+0x380/0x115c [ 75.148356] softirqs last enabled at (0): [<ffffff90080e65d8>] copy_process+0x398/0x115c [ 75.148364] softirqs last disabled at (0): [<0000000000000000>] (null) [ 75.148372] ---[ end trace 588bf529451e3531 ]--- Reported-by: Anand K Mistry <amistry@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Tong Zhang authored
pvr2_std_str_to_id() returns 0 on failure and 1 on success, however the caller is checking failure case using <0 Acked-by: Mike Isely <isely@pobox.com> Co-developed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Tong Zhang <ztong0001@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Tomasz Figa authored
According to [1], there has been no email related to videobuf2 posted from him to the linux-media mailing list since Apr 2015. Note: The linked archive seems to lack messages newer than the middle of 2019, but it is the only archive that offers search by name. A manual look through the messages after that time confirms the observation. [1] https://www.mail-archive.com/search?a=1&l=linux-media%40vger.kernel.org&haswords=&x=0&y=0&from=Pawel+Osciak&subject=&datewithin=1d&date=¬words=&o=newestSigned-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Tomasz Figa authored
According to [1], there has been no email posted from him to the linux-media mailing list since Feb 2013. Note: The linked archive seems to lack messages newer than the middle of 2019, but it is the only archive that offers search by name. A manual look through the messages after that time confirms the observation. [1] https://www.mail-archive.com/search?a=1&l=linux-media%40vger.kernel.org&haswords=&x=7&y=20&from=Kyungmin+Park&subject=&datewithin=1d&date=¬words=&o=newestSigned-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Tomasz Figa authored
Tomasz is the most active member from the people listed currently in the MAINTAINERS file, but is currently listed as a reviewer. Change the entry into a maintainer and move to the top of the list. Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The default RGB quantization range for BT.2020 is full range (just as for all the other RGB pixel encodings), not limited range. Update the V4L2_MAP_QUANTIZATION_DEFAULT macro and documentation accordingly. Also mention that HSV is always full range and cannot be limited range. When RGB BT2020 was introduced in V4L2 it was not clear whether it should be limited or full range, but full range is the right (and consistent) choice. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The documentation reported service_set as a __u32, but according to videodev2.h it is a __u16. Correct the documentation. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 18 Aug, 2020 11 commits
-
-
Rajendra Nayak authored
Add support to add OPP tables and perf voting on the OPP powerdomain. This is needed so venus votes on the corresponding performance state for the OPP powerdomain along with setting the core clock rate. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Rajendra Nayak authored
Post a successful pm_ops->core_get, an error in probe should exit by doing a pm_ops->core_put which seems to be missing. So fix it. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dinghao Liu authored
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. For other error paths after this call, things are the same. Fix this by adding pm_runtime_put_noidle() after 'err_runtime_disable' label. But in this case, the error path after pm_runtime_put_sync() will decrease PM usage counter twice. Thus add an extra pm_runtime_get_noresume() in this path to balance PM counter. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
Use the newly introduced get_mbus_config() subdevice pad operation to retrieve the remote subdevice MIPI CSI-2 bus configuration and configure the number of active data lanes accordingly. In order to be able to call the remote subdevice operation cache the index of the remote pad connected to the single CSI-2 input port. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
Implement the newly introduced get_mbus_config operation to report the number of currently used data lanes on the MIPI CSI-2 interface. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
When outputting SD-Core output through the TXA MIPI CSI-2 interface, the number of enabled data lanes should be reduced in order to guarantee that the two video formats produced by the SD-Core (480i and 576i) generate a MIPI CSI-2 link clock frequency compatible with the MIPI D-PHY specifications. Limit the number of enabled data lanes to 2, which is guaranteed to support 480i and 576i formats. Cache the number of enabled data lanes to be able to report it through the new get_mbus_config operation. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
Update the TODO entry that mentioned a potential use case for the now removed g_mbus_config video operation. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
With the removal of the legacy g_mbus_config and s_mbus_config video operations, the sole users of V4L2_MBUS_* flags are now the newly introduced get_mbus_config and set_mbus_config pad operations. As the semantic of the new operations differs from the semantic of the legacy ones, add a usage note in the v4l2-mediabus.h header to specify how to use the flags. Also add a TODO note to record that we intend to replace the existing flags with fields, to prevent users from mixing conflicting values in a single operation call. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
With all sensor and platform drivers now converted to use the new get_mbus_config and set_mbus_config pad operations, remove the deprecated video operations g_mbus_config and s_mbus_config. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
Move the PXA camera driver to use the new set_mbus_config pad operation. For this platform the change is not only cosmetic, as the pxa driver is currently the only driver in mainline to make use of the g_mbus_config and s_mbus_config video operations. The existing driver semantic is the following: - Collect all supported mbus config flags from the remote end - Match them with the supported PXA mbus configuration flags - If the remote subdevice allows multiple options for for VSYNC, HSYNC and PCLK polarity, use platform data requested settings The semantic of the new get_mbus_config and set_mbus_config differs from the corresponding video ops, particularly in the fact get_mbus_config reports the current mbus configuration and not the set of supported configuration options, with set_mbus_config always reporting the actual mbus configuration applied to the remote subdevice. Adapt the driver to perform the following - Set the remote subdevice mbus configuration according to the PXA platform data preferences. - If the applied configuration differs from the requested one (i.e. the remote subdevice does not allow changing one setting) make sure that - The remote end does not claim for DATA_ACTIVE_LOW, which seems not supported by the platform - The bus mastering roles match While at there remove a few checks performed on the media bus configuration at get_format() time as they do not belong there. Compile-tested only. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
Use the new get_mbus_config and set_mbus_config pad operations in place of the video operations currently in use. Compared to other drivers where the same conversion has been performed, ov6650 proved to be a bit more tricky, as the existing g_mbus_config implementation did not report the currently applied configuration but the set of all possible configuration options. Adapt the driver to support the semantic of the two newly introduced operations: - get_mbus_config reports the current media bus configuration - set_mbus_config applies only changes explicitly requested and updates the provided cfg parameter to report what has actually been applied to the hardware. Compile-tested only. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-