- 15 Jul, 2022 40 commits
-
-
Benjamin Gaignard authored
'F.7.3.6.1 General slice segment header syntax' section of HEVC specification describes that a slice header always end aligned on byte boundary, therefore we only need to provide the data offset in bytes. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Acked-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Tested-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Benjamin Gaignard authored
Fix padding where needed to remove holes Signed-off-by:
-
Benjamin Gaignard authored
The number of bits to skip in the slice header can be computed in the driver by using sps, pps and decode_params information. This makes it possible to remove Hantro dedicated control. Signed-off-by:
-
Benjamin Gaignard authored
Simply print the type of the control. Signed-off-by:
-
Benjamin Gaignard authored
Move the HEVC stateless controls types out of staging, and re-number them. Signed-off-by:
-
Benjamin Gaignard authored
Move HEVC pixel format since we are ready to stabilize the uAPI Signed-off-by:
-
Benjamin Gaignard authored
The number of 'entry point offset' can be very variable. Instead of using a large static array define a v4l2 dynamic array of U32 (V4L2_CTRL_TYPE_U32). The number of entry point offsets is reported by the elems field and in struct v4l2_ctrl_hevc_slice_params.num_entry_point_offsets field. Signed-off-by:
-
Benjamin Gaignard authored
Make explicit that V4L2_CID_STATELESS_HEVC_SLICE_PARAMS control is a dynamic array control type. Some drivers may be able to receive multiple slices in one control to improve decoding performance. Signed-off-by:
-
Benjamin Gaignard authored
Add kernel-doc documentation for all the HEVC structures. Signed-off-by:
-
Benjamin Gaignard authored
The possible values for the field_pic field in the v4l2_hevc_dpb_entry structure are defined in the table D.2 in HEVC specification section D.3.3. Add flags and documentation for each of them. Signed-off-by:
-
Benjamin Gaignard authored
The HEVC specification describes the following: "PicOrderCntVal is derived as follows: PicOrderCntVal = PicOrderCntMsb + slice_pic_order_cnt_lsb The value of PicOrderCntVal shall be in the range of −2^31 to 2^31 − 1, inclusive." To match with these definitions change __u16 pic_order_cnt[2] into __s32 pic_order_cnt_val. Change v4l2_ctrl_hevc_slice_params->slice_pic_order_cnt to __s32 too. Signed-off-by:
-
Benjamin Gaignard authored
Change HEVC stateless controls names to V4L2_CID_STATELESS_HEVC instead of V4L2_CID_MPEG_VIDEO_HEVC be coherent with v4l2 naming convention. Signed-off-by:
-
Benjamin Gaignard authored
Complete the HEVC controls with missing fields from H.265 specifications. Even if these fields aren't used by the current mainlined drivers they will be required for (at least) the rkvdec driver. Signed-off-by:
-
Hans Verkuil authored
Add a dynamic array test control to help test support for this feature. Acked-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
Implement support for dynamically allocated arrays. Most of the changes concern keeping track of the number of elements of the array and the number of elements allocated for the array and reallocating memory if needed. Acked-by:
-
Hans Verkuil authored
Add a new flag that indicates that this control is a dynamically sized array. Also document this flag. Currently dynamically sized arrays are limited to one dimensional arrays, but that might change in the future if there is a need for it. The initial use-case of dynamic arrays are stateless codecs. A frame can be divided in many slices, so you want to provide an array containing slice information for each slice. Typically the number of slices is small, but the standard allow for hundreds or thousands of slices. Dynamic arrays are a good solution since sizing the array for the worst case would waste substantial amounts of memory. Acked-by:
-
Vikash Garodia authored
UBWC configuration parameters would vary across video hardware generations. At the same time, driver is expected to configure these parameters, without relying on video firmware to use the default configurations. Setting the configuration parameters for sc7280. Signed-off-by:
Vikash Garodia <quic_vgarodia@quicinc.com> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
-
Hans Verkuil authored
Fix a smatch error: drivers/media/platform/qcom/venus/helpers.c: drivers/media/platform/qcom/venus/helpers.c:678 venus_helper_get_bufreq() error: we previously assumed 'req' could be null (see line 674) After checking how venus_helper_get_bufreq() is called it is clear that req is never NULL, so just drop the checks. Signed-off-by:
-
Tommaso Merciai authored
Add ov5693_of_match. Device tree support Signed-off-by:
Tommaso Merciai <tommaso.merciai@amarulasolutions.com> Reviewed-by:
Jacopo Mondi <jacopo@jmondi.org> Reviewed-by:
Daniel Scally <djrscally@gmail.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Tommaso Merciai authored
Add documentation of device tree in YAML schema for the OV5693 CMOS image sensor from Omnivision Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Tommaso Merciai authored
Add support for ACPI-based platforms that specify the clock frequency by using the "clock-frequency" property instead of specifying a clock provider reference Signed-off-by:
-
Tommaso Merciai authored
Rename clk pdata pointer into xvclk (system clock input). Same for clk_rate into xvclk_rate. This is more explicit Signed-off-by:
-
Tommaso Merciai authored
Add missing "dvdd" (Digital circuit power) entry into ov5693_supply_names array Signed-off-by:
-
Tommaso Merciai authored
Instead of hardcode OV5693_NUM_SUPPLIES in a define is better use ARRAY_SIZE function to count the number of supplies from ov5693_supply_names array Signed-off-by:
-
Daniel Scally authored
Where iteration over links for an entity is clearly assuming that all of those links are data links, use the new iterator to guarantee that assumption is met. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Scally authored
Iterating over the links for an entity is a somewhat common need through the media subsystem, but generally the assumption is that they will all be data links. To meet that assumption add a new macro that iterates through an entity's links and skips non-data links. Signed-off-by:
-
Marek Vasut authored
Implement V4L2_SEL_TGT_CROP_BOUNDS query in get_selection subdev op for this sensor. This is required e.g. to bind it to STM32MP15x DCMI. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Stefan Riedmueller <s.riedmueller@phytec.de> Reviewed-by:
-
Tomi Valkeinen authored
stm32-dcmi calls its source subdev with v4l2_subdev_call() using a v4l2_subdev_state constructed on stack. This means that init_cfg is never called for that state, and a source subdev that depends on the init_cfg call may break. A new macro has been added for this particular purpose, which properly initializes the state, so let's use v4l2_subdev_call_state_try() here. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
-
Tomi Valkeinen authored
Add a helper macro for the situations where a non-MC driver needs to call a state-operation (operation which takes a subdev state as a parameter) in try-context in another subdev. The macro allocates a new subdev state for the called subdev and frees the state afterwards. An example use case is a media platform driver testing if a v4l2_subdev_format would be accepted by a source subdev. This should not be used in MC drivers. Signed-off-by:
-
Hans Verkuil authored
VIDEO_V4L2 no longer exists, instead use VIDEO_DEV. Without this change this driver cannot be selected. Signed-off-by:
-
Laurent Pinchart authored
The VIDEO_V4L2_SUBDEV_API Kconfig symbol is mostly selected automatically, with a a handful of drivers still using it as a dependency. Fix them to use selection, and drop the symbol title text to not expose it for manual selection. Signed-off-by:
-
Yang Yingliang authored
Add the missing gpiod_set_value_cansleep() and clk_disable_unprepare() before return from ov7251_set_power_on() in the error handling case. Fixes: 9e1d3012 ("media: i2c: Remove .s_power() from ov7251") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Sakari Ailus authored
The sun6i-mipi-csi2 and sun6i-a83t-mipi-csi2 drivers depend on the generic MIPI D-PHY support. Select it. This fixes a linking problem when either of these drivers is enabled and GENERIC_PHY_MIPI_DPHY is disabled. Signed-off-by:
-
Laurent Pinchart authored
Extend the format sanitization code in the framework to handle invalid values for the colorspace-related fields. Signed-off-by:
-
Laurent Pinchart authored
The helper functions that test validity of colorspace-related fields use the last value of the corresponding enums. This isn't very future-proof, as there's a high chance someone adding a new value may forget to update the helpers. Add new "LAST" entries to the enumerations to improve this, and keep them private to the kernel. Signed-off-by:
-
Laurent Pinchart authored
Extend vivid to support the newly added YUVA and YUVX pixel formats through the TPG. Signed-off-by:
-
Laurent Pinchart authored
Extend the TPG to support generating the newly added YUVA and YUVX pixel formats. Signed-off-by:
-
Laurent Pinchart authored
The new YUVA and YUVX are permutations of the existing AYUV and XYUV formats. They are use by the NXP i.MX8 ISI hardware. Signed-off-by:
-
Chen-Yu Tsai authored
This partially reverts commit fd9f8050, and changes things so that the capability string fields of the encoder conform to their requirements. The driver name field should contain the actual driver name, not some otherwise unused string macro from the driver. To make this clear, copy the name from the driver's name field. The card name for the video encoder previously held a static platform name that was fixed to match MT8173. This obviously doesn't make sense for newer chips. Since commit fd9f8050 ("media: mediatek: vcodec: Change encoder v4l2 capability value"), this field was changed to hold the driver's name, or "mtk-vcodec-dec". This doesn't make much sense either, since this still doesn't reflect what chip this is. Instead, fill in the card name with "MTxxxx video encoder" with the proper chip number. Since commit f2d8b691 ("media: v4l: ioctl: Set bus_info in v4l_querycap()"), the V4L2 core provides a default value for the bus_info field for platform and PCI devices. This value will match the default value for media devices added by commit cef69974 ("media: mc: Set bus_info in media_device_init()"). These defaults are stable and device-specific. Drop the custom capability bus_info from the mtk-vcodec encoder driver, and use the defaults. As this patch removes the last usage of MTK_VCODEC_DRV_NAME, remove the macro as well. Fixes: fd9f8050 ("media: mediatek: vcodec: Change encoder v4l2 capability value") Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Signed-off-by:
-
Chen-Yu Tsai authored
This partially reverts commit a8a7a278, and changes things so that the capability string fields of the decoder conform to their requirements. This recent change caused ChromeOS's decoder to no longer function. This is due to ChromeOS using the driver name field to match the video device with its accompanying media device. After the change, they no longer matched. The driver name field should contain the actual driver name, not some otherwise unused string macro from the driver. To make this clear, copy the name from the driver's name field. The card name for the video decoder previously held a static platform name that was fixed to match MT8173. This obviously doesn't make sense for newer chips. Since commit a8a7a278 ("media: mediatek: vcodec: Change decoder v4l2 capability value"), this field was changed to hold the driver's name, or "mtk-vcodec-dec". This doesn't make much sense either, since this still doesn't reflect what chip this is. Instead, fill in the card name with "MTxxxx video decoder" with the proper chip number. Since commit f2d8b691 ("media: v4l: ioctl: Set bus_info in v4l_querycap()"), the V4L2 core provides a default value for the bus_info field for platform and PCI devices. This value will match the default value for media devices added by commit cef69974 ("media: mc: Set bus_info in media_device_init()"). These defaults are stable and device-specific. Drop the custom capability bus_info from the mtk-vcodec decoder driver, and use the defaults. This also fixes the long standing issue where the media device used for the stateless decoder didn't have its bus_info set, and would never match its accompanying video device. Fixes: a8a7a278 ("media: mediatek: vcodec: Change decoder v4l2 capability value") Signed-off-by:
-
