- 04 Oct, 2019 3 commits
-
-
Aniket Masule authored
Current clock scaling calculations are same for vpu4 and previous versions. For vpu4, Clock scaling calculations are updated with cycles/mb and bitrate. This helps in getting precise clock required. Signed-off-by:
Aniket Masule <amasule@codeaurora.org> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Aniket Masule authored
Add vpp cycles for different types of codec. It indicates the cycles required by video hardware to process each macroblock. Add vsp cycles, cycles required by stream processor. Initialize the codec data with core resources. Signed-off-by:
-
Stanimir Varbanov authored
Failure to suspend (venus_suspend_3xx) happens when the system is fresh booted and loading venus driver. This happens once and after reload the venus driver modules the problem disrepair. Fix the failure by skipping the check for WFI and IDLE bits if PC_READY is on in control status register. Signed-off-by:
-
- 02 Oct, 2019 2 commits
-
-
Stanimir Varbanov authored
This aims to add a requests for bandwidth scaling depending on the resolution and framerate (macroblocks per second). The exact value of the requested bandwidth is get from a pre-calculated tables for encoder and decoder. Acked-by:
Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
-
Loic Poulain authored
In downstream driver, there are two frequency tables defined, one for the encoder and one for the decoder: /* Encoders / <972000 490000000 0x55555555>, / 4k UHD @ 30 / <489600 320000000 0x55555555>, / 1080p @ 60 / <244800 150000000 0x55555555>, / 1080p @ 30 / <108000 75000000 0x55555555>, / 720p @ 30 */ /* Decoders / <1944000 490000000 0xffffffff>, / 4k UHD @ 60 / < 972000 320000000 0xffffffff>, / 4k UHD @ 30 / < 489600 150000000 0xffffffff>, / 1080p @ 60 / < 244800 75000000 0xffffffff>; / 1080p @ 30 */ It shows that encoder always needs a higher clock than decoder. In current venus driver, the unified frequency table is aligned with the downstream decoder table which causes performance issues in encoding scenarios. Fix that by aligning frequency table on worst case (encoding). Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
- 01 Oct, 2019 35 commits
-
-
Benoit Parrot authored
Switch to SPDX licensing and drop the redundant GPL text. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Acked-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Benoit Parrot authored
The initial registers sequence is only loaded at probe time. Afterward only the resolution and format specific register are modified. Care must be taken to make sure registers modified by one resolution setting are reverted back when another resolution is programmed. This was not done properly for the 720p case. Signed-off-by:
-
Benoit Parrot authored
On some board it is possible that the sensor 'powerdown' and or 'reset' pin might be controlled by gpio instead of being tied. To implement we add pm_runtime support which will handle the power up/down sequence when it is available otherwise the sensor will be powered on at module insertion/probe and powered off at module removal. Now originally the driver assumed that the sensor would always stay powered and keep its register setting. We cannot assume this anymore, so every time we "power up" we need to re-program the initial registers configuration first. This was previously done only at probe time. [Sakari Ailus: Resolve a conflict in Kconfig] Signed-off-by:
-
Benoit Parrot authored
Add powerdown-gpios and reset-gpios to the list of optional properties for the OV2659 camera sensor. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Benoit Parrot authored
In ov2659_s_stream() return value for invoked function should be checked and propagated. Signed-off-by:
-
Benoit Parrot authored
Several of include files listed are not explicitly needed. If they are need then they are implicitly included. Reduce the list of includes to an easier to manage list. Signed-off-by:
-
Benoit Parrot authored
Make sure that if the expected sensor device id register is not recognized properly the failure is propagated up so devices are not left partially initialized. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Acked-by:
-
Benoit Parrot authored
Based on recently found sensor configuration examples, it was discovered that when scaling and binning are used for the lower resolutions (i.e. 640x480, 320x240) the read offset has to be increased otherwise the image appears to be wrapped around. Signed-off-by:
-
Dongchun Zhu authored
This patch adds support for registering a sensor sub-device to the async sub-device framework and parse set up common sensor related devices such as actuator/VCM. [Sakari Ailus: Rewrap commit message] Signed-off-by:
Dongchun Zhu <dongchun.zhu@mediatek.com> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Sakari Ailus authored
Assign vep->link_frequencies to NULL after releasing its memory. Without this change, multiple calls to v4l2_fwnode_endpoint_free() would result in double kfree calls. Signed-off-by:
-
Sakari Ailus authored
Instead of individually depending on MEDIA_CAMERA_SUPPORT (or forgetting it), put all camera sensor, lens and flash drivers under MEDIA_CAMERA_SUPPORT as a whole. The lens VCM devices didn't use to do this, but make them depend on MEDIA_CAMERA_SUPPORT as well since there's no use for these devices without that in practice. Signed-off-by:
-
Janusz Krzysztofik authored
The driver stores crop rectangle settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, crop rectangle width and height settings are not updated correctly when rectangle offset settings are applied on hardware. If an error occurs while the device is updated, the stored settings my no longer reflect hardware state and consecutive calls to .get_selection() as well as .get/set_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informamtion on active frame format returned by .get/set_fmt() is used. Assuming a failed update of the device means its actual settings haven't changed, update crop rectangle width and height settings stored in the device private structure correctly while the rectangle offset is successfully applied on hardware so the stored values always reflect actual hardware state to the extent possible. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
-
Janusz Krzysztofik authored
The driver stores frame format settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, those settings are updated before they are actually applied on hardware. If an error occurs on device update, the stored settings my not reflect hardware state anymore and consecutive calls to .get_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informmation on active frame format returned by .get_fmt() is used. Assuming a failed device update means its state hasn't changed, update frame format related settings stored in the device private structure only after they are successfully applied so the stored values always reflect hardware state as closely as possible. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Janusz Krzysztofik authored
It is not clear what pixel format is actually configured in hardware on reset. MEDIA_BUS_FMT_YUYV8_2X8, assumed on device probe since the driver was intiially submitted, is for sure not the one. Fix it by explicitly applying a known, driver default frame format just after initial device reset. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Janusz Krzysztofik authored
Commit da298c6d ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt") converted a former ov6650_g_fmt() video operation callback to an ov6650_get_fmt() pad operation callback. However, the converted function disregards a format->which flag that pad operations should obey and always returns active frame format settings. That can be fixed by always responding to V4L2_SUBDEV_FORMAT_TRY with -EINVAL, or providing the response from a pad config argument, likely updated by a former user call to V4L2_SUBDEV_FORMAT_TRY .set_fmt(). Since implementation of the latter is trivial, go for it. Fixes: da298c6d ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt") Signed-off-by:
-
Janusz Krzysztofik authored
User arguments passed to .get/set_fmt() pad operation callbacks may contain unsupported values. The driver takes control over frame size and pixel code as well as colorspace and field attributes but has never cared for remainig format attributes, i.e., ycbcr_enc, quantization and xfer_func, introduced by commit 11ff030c ("[media] v4l2-mediabus: improve colorspace support"). Fix it. Set up a static v4l2_mbus_framefmt structure with attributes initialized to reasonable defaults and use it for updating content of user provided arguments. In case of V4L2_SUBDEV_FORMAT_ACTIVE, postpone frame size update, now performed from inside ov6650_s_fmt() helper, util the user argument is first updated in ov6650_set_fmt() with default frame format content. For V4L2_SUBDEV_FORMAT_TRY, don't copy all attributes to pad config, only those handled by the driver, then fill the response with the default frame format updated with resulting pad config format code and frame size. Fixes: 11ff030c ("[media] v4l2-mediabus: improve colorspace support") Signed-off-by:
-
Janusz Krzysztofik authored
Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8. According to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies exclusively to V4L2_PIX_FMT_JPEG. Since the sensor does not support JPEG format, fix it to always select V4L2_COLORSPACE_SRGB. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Janusz Krzysztofik authored
Commit 4f996594 ("[media] v4l2: make vidioc_s_crop const") introduced a writable copy of constified user requested crop rectangle in order to be able to perform hardware alignments on it. Later on, commit 10d5509c ("[media] v4l2: remove g/s_crop from video ops") replaced s_crop() video operation using that const argument with set_selection() pad operation which had a corresponding argument not constified, however the original behavior of the driver was not restored. Since that time, any hardware alignment applied on a user requested crop rectangle is not passed back to the user calling .set_selection() as it should be. Fix the issue by dropping the copy and replacing all references to it with references to the crop rectangle embedded in the user argument. Fixes: 10d5509c ("[media] v4l2: remove g/s_crop from video ops") Signed-off-by:
-
Janusz Krzysztofik authored
Since commit afd9690c ("[media] ov6650: convert to the control framework"), if an error occurs during initialization of a control handler, resources possibly allocated to the handler are not freed before device initialiaton is aborted. Fix it. Fixes: afd9690c ("[media] ov6650: convert to the control framework") Signed-off-by:
-
Janusz Krzysztofik authored
Commit 23a52386 ("media: ov6650: convert to standalone v4l2 subdevice") converted the driver from a soc_camera sensor to a standalone V4L subdevice driver. Unfortunately, module description was not updated to reflect the change. Fix it. While being at it, update email address of the module author. Fixes: 23a52386 ("media: ov6650: convert to standalone v4l2 subdevice") Signed-off-by:
-
YueHaibing authored
If CONFIG_REGMAP_I2C is not set, building fails: drivers/media/i2c/max2175.o: In function `max2175_probe': max2175.c:(.text+0x1404): undefined reference to `__devm_regmap_init_i2c' Select REGMAP_I2C to fix this. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: b47b79d8 ("[media] media: i2c: max2175: Add MAX2175 support") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Hans Verkuil authored
This patch converts the cx231xx driver to the vb2 framework. Since you can't do a partial conversion this is a big-bang patch, i.e. large and hard to review. I never found a way around this. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Co-developed-by:
-
Hans Verkuil authored
Add support for cec-notifier to the cec-gpio driver. This makes it possible to associate the CEC gpio pin with an HDMI connector. This feature was always documented in the cec-gpio bindings: Documentation/devicetree/bindings/media/cec-gpio.txt But support for the hdmi-phandle property was never actually implemented in this driver. This patch adds support for this property. It also fixes a few incorrect error returns in the probe() function, which skipped the call to cec_delete_adapter(). Tested on a Raspberry Pi 3B with a modified vc4 driver. Signed-off-by:
-
Dariusz Marcinkiewicz authored
Document the new CEC_ADAP_G_CONNECTOR_INFO ioctl and the new CEC_CAP_CONNECTOR_INFO capability. Co-developed-by:
Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by:
-
Dariusz Marcinkiewicz authored
Until now the connector info API was a kernel-internal API only. This moves it to the public API and adds the new ioctl to retrieve this information. Signed-off-by:
-
Hans Verkuil authored
CEC_OP_REC_FLAG_NOT_USED is 0 and CEC_OP_REC_FLAG_USED is 1, not the other way around. Signed-off-by:
Jiunn Chang <c0d1n61at3@gmail.com> Cc: <stable@vger.kernel.org> # for v4.10 and up Signed-off-by:
-
Hans Verkuil authored
Instead of hardcoding the UI Command key values, use the new defines. Signed-off-by:
-
Hans Verkuil authored
These defines were never added to this CEC header, likely due to laziness on the part of the original author, i.e. me. But it is useful to have them, so add them. Also update the cec.h.rst.exceptions file to avoid errors when building the documentation. Signed-off-by:
-
Philipp Zabel authored
Now that proper V4L2 pixel formats exist for all 32-bit RGB permutations, drop support for the poorly defined legacy format V4L2_PIX_FMT_BGR32. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
Since the uapi does not contain the num_ref_idx_active_override_flag, drivers for decoders that do not parse slices themselves don't know how to choose between the num_ref_idx_l[01]_default_active and the num_ref_idx_l[01]_active override fields. Instead, userspace must set the override fields to the default values if the slice does not have the num_ref_idx_active_override flag set. The drivers will then always enable the override internally and ignore the default fields completely. Clarify this requirement in the API documentation. Signed-off-by:
-
Philipp Zabel authored
Document that the slice headers must be included for the benefit of decoders that parse them (partially) in hardware, and that the start code is optional. Add a link to the ITU-T Rec. H.264 specification section that describes the slice format. Signed-off-by:
-
Boris Brezillon authored
Step '8.2.4.1 Decoding process for picture numbers' was missing in the reflist creation logic, leading to invalid P reflists when a ->frame_num wraparound happens. Fixes: a9471e25 ("media: hantro: Add core bits to support H264 decoding") Reported-by:
Francois Buergisser <fbuergisser@google.com> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Francois Buergisser <fbuergisser@chromium.org> Reviewed-by:
-
Boris Brezillon authored
And use it for all native type comparisons, even if it's not strictly required. By doing that we make the code more consistent and prevent from potential incorrect results in case of overflow or when the the values being compared are both negative. Signed-off-by:
-
Boris Brezillon authored
So it matches the code and the spec. Signed-off-by:
-
Niklas Söderlund authored
The hardware is capable to passing V4L2_FIELD_ALTERNATE to user-space. Allow users to request this field format but still default to using the hardware interlacer if alternating is not explicitly requested. Before this change a sensor providing data using alternate would be always combined to an interlaced frame. After this change the user can request to receive frames as alternate if the sensor provides it. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
