- 09 Jun, 2023 40 commits
-
-
Benjamin Gaignard authored
Implement AV1 stateless decoder for rockchip VPU981. It decode 8 and 10 bits AV1 bitstreams. AV1 scaling feature is done by the postprocessor. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Benjamin Gaignard authored
AV1 hardware decoder needs entropy parameters to decode frames. They are computed from various arrays defined in AV1 section "9.4. Default CDF tables". Add helpers functions to init, store and get these parameters. Signed-off-by:
-
Benjamin Gaignard authored
Compute the additional space required to store motion vectors at the end of the frames buffers. Signed-off-by:
-
Benjamin Gaignard authored
The driver supports 8 and 10 bits bitstreams, make sure to discard other cases. It could happens that userland test if V4L2_CID_STATELESS_AV1_SEQUENCE exists without setting bit_depth field in this case use HANTRO_DEFAULT_BIT_DEPTH value. Signed-off-by:
-
Benjamin Gaignard authored
Add AV1 decoder as new decoder mode to Hantro driver. Register needed AV1 controls for the decoder. Signed-off-by:
-
Benjamin Gaignard authored
Let's the driver knows that V4L2_PIX_FMT_NV15_4L4 is a 10bits pixel format. Signed-off-by:
-
Benjamin Gaignard authored
NV15_4L4 is the 10-bits per component 4x4 tiled format. Signed-off-by:
-
Nicolas Dufresne authored
Fraction bytes-per-pixel exist for some packed format. You will find notably on Rockhip platform that 10bit data is stored fully packed, meaning that there is 1.25 pixels per bytes. This can be represented with the fraction 5/4 and can be used to scale the width into a bytesperline. Signed-off-by:
-
Benjamin Gaignard authored
Make sure that bit_depth field of V4L2_CTRL_TYPE_AV1_SEQUENCE is initialized correctly before using it. Signed-off-by:
-
Benjamin Gaignard authored
Add compatible for rk3588 AV1 vpu decoder. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Daniel Almeida authored
This patch adds the AOMedia Video 1 (AV1) kernel uAPI. This design is based on currently available AV1 API implementations and aims to support the development of AV1 stateless video codecs on Linux. Signed-off-by:
Daniel Almeida <daniel.almeida@collabora.com> Co-developed-by:
-
Hans Verkuil authored
If 'done' is not NULL, then next can never be NULL, so just drop the 'next' check. This fixes this smatch warning: drivers/media/pci/tw686x/tw686x-audio.c:62 tw686x_audio_irq() warn: can 'next' even be NULL? Signed-off-by:
-
Hans Verkuil authored
If vpu_clock_enable() fails, then call clk_unprepare(). This fixes this smatch warning: drivers/media/platform/mediatek/vpu/mtk_vpu.c:1031 mtk_vpu_resume() warn: 'vpu->clk' from clk_prepare() not released on lines: 1020. Signed-off-by:
-
Hans Verkuil authored
If pdev is NULL, then it is still dereferenced. This fixes this smatch warning: drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev' Signed-off-by:
-
Hans Verkuil authored
Since start_streaming is only called if there are at least two buffers queued, the ceudev->capture list will never be empty, so the check whether there are no buffers can be dropped. Note that the '!buf' check was wrong in any case, if we wanted to check for an empty list it should have used list_empty(). This fixes this smatch warning: drivers/media/platform/renesas/renesas-ceu.c:705 ceu_start_streaming() warn: can 'buf' even be NULL? Signed-off-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
Fixes this smatch warning: drivers/media/usb/as102/as102_usb_drv.c:306 as102_usb_release() warn: can 'as102_dev' even be NULL? And indeed, as102_dev can never be NULL, so just drop the NULL check. Signed-off-by:
-
Hans Verkuil authored
Fix this smatch warning: drivers/media/platform/rockchip/rga/rga.c:734 rga_enable_clocks() warn: 'rga->sclk' from clk_prepare_enable() not released on lines: 734. The reason is that aclk should be disabled/unprepared before sclk, instead of the other way around. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
-
Hans de Goede authored
Some standard v4l2 sensor drivers from drivers/media/i2c expect a "clock-frequency" property on the device indicating the frequency of the extclk for the sensor. Example of such drivers are the ov2680 and ov5693 drivers. The standard ov5693 sensor also expects a "link-frequencies" property. Add support for setting both properties. Note the "clock-frequency" prop is added before the "rotation" prop while the "link-frequencies" are added at the end to match the ipu3 cio2-bridge code from which this is derived. Link: https://lore.kernel.org/r/20230606133136.23619-1-hdegoede@redhat.comSigned-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Hans de Goede authored
Testing the atomisp can be a bit tricky. The BYT/CHT CPUs are not very powerful so some apps like camorama cannot run at full FPS. Add instructions for how to test with gstreamer which does runs at full FPS without issues. Link: https://lore.kernel.org/r/20230604161406.69369-6-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
The data sheets say the registers at offset 0x3700 - 0x373f are "sensor control" registers rename the unknown variable in ov2680_set_mode() to sensor_ctrl_0a and add a OV2680_REG_SENSOR_CTRL_0A define. Link: https://lore.kernel.org/r/20230604161406.69369-5-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Many of the values in ov2680_global_setting[] match the default/reset register value for the ov2680 sensor (verified with both datasheet and actual hw) so they are no-ops. And there are also a couple of others which are later overwritten by ctrls or by ov2680_set_mode(). Remove all the unnecessary entries and add annotations to the remaining entries documenting what they change (in so far as things are documented in the datasheet). This also removes the double writing of OV2680_REG_SOFT_RESET in ov2680_init_registers() (one direct write, one in ov2680_global_setting[]) instead add a short sleep after the first write to give the sensor time to reset. Link: https://lore.kernel.org/r/20230604161406.69369-4-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Stop using half pixelclock for binned modes this fixes: 1. The exposure being twice as high for binned mods (due to the half clk) 2. The framerate being 15 fps instead of 30 fps The original code with fixed per mode register lists did use half pixel clk, but this should be combined with using half for the VTS value too. Using half VTS fixes the framerate issue, but this has the undesired side-effect of change the exposure ctrl range (half the range, double the amount of exposure per step). Link: https://lore.kernel.org/r/20230604161406.69369-3-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
No other V4L2 driver resets the selected input (front cam or back cam selected in case of the atomisp). Stop resetting selected input to 0 between /dev/video# opens. This allows e.g. using v4l2-ctl -i to switch the input before starting another app, which is useful since most apps don't support selecting the input. Note more in general the whole resetting of a bunch of internal state from the open fop needs to be removed there to allow multiple opens of /dev/video# for full v4l2 API compliance. Link: https://lore.kernel.org/r/20230604161406.69369-2-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
The fmt / size passed to atomisp_set_crop() includes padding, so the binning check should be against 1/2 of the native rect. of the sensor, rather then 1/2 of the active rect. This fixes binning not being used when using e.g. 800x600 on a 1600x1200 sensor leading to a very small field of view. Link: https://lore.kernel.org/r/20230601145858.59652-4-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Now that atomisp_get_padding() takes minimum padding requirements on BYT/ISP2400 into account, it is possible for a resolution which fits in the active area of the sensor to not fit in the native area once padding is added. For example on the ov2680 which has a native resolution of 1616x1216 the max active resolution of 1600x1200 leaves 16x16 for padding which meets the worst-case minimum padding requirement of 14x14 on BYT. But after binning we are left with an native area of 808x608 and an active area of 800x600. This leaves 8x8 for padding which is not enough. So on BYT 800x600 is not a valid resolution (it could be made by lots of cropping without binning but then the remaining field of view is no good). Modify atomisp_enum_framesizes_crop() to check the resolution + padding fits in the native rectangle, removing 800x600 from the list of valid modes on BYT. Link: https://lore.kernel.org/r/20230601145858.59652-3-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
The main binary for the pipeline on BYT/ISP2400 has its ia_css_binary_info.pipeline.left_cropping and .top_cropping fields set to 12. So a minimum padding of 12 is required. And for certain bayer-orders additional width / height padding is necessary so that the ISP crop rectangle for the raw sensor data can be used to change the bayer-order to the fixed bayer-order supported by the debayer block. Without the minmum required padding ia_css_ifmtr_configure() will fail inside ifmtr_input_start_line() and/or ifmtr_start_column() because it cannot set the ISP crop rectangle for the raw sensor data. Fix this by making atomisp_get_padding() take the minimum padding requirements into account on BYT/ISP2400 (CHT/ISP2401 does not seem to need this). Link: https://lore.kernel.org/r/20230601145858.59652-2-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
The ACPI code takes care of enabling/disabling the PMC clk(s) for the sensors as necessary based on the runtime-pm state of the sensor. But the GMIN code this replaces also set the clk-rate of the PMC clk to 19.2 MHz. At least on BYT devices the PMC clks may come up running at 25 MHz instead of the expected 19.2 MHz. Ensure the sensor clk also runs at the expected 19.2 MHz for sensors using v4l2-async probing by explicitly setting it to 19.2 MHz when enumerating sensors in atomisp_csi2_bridge.c. Link: https://lore.kernel.org/r/20230529103741.11904-22-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Some sensor drivers with crop support (e.g. the ov5693 driver) only return the current crop rectangle + 1/2 (binning) of the current crop rectangle when calling their enum_frame_sizes op. This causes 2 issues: 1. Atomisp sets to the crop area to include the padding, where as the enum_framesizes ioctl should return values without padding. 2. With cropping a lot more standard resolutions are possible then just these 2 and many apps limit the list given to the end user to the list returned by enum_framesizes. Add an alternative enum_framesizes function for sensors which support cropping to fix both issues. Link: https://lore.kernel.org/r/20230529103741.11904-21-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Some drivers which implement selections/crop only allow setting the format with and height to either the crop rectangle width and height or to half the crop rectangle width and height (binning). An example of such a driver is the standard v4l2 ov5693 driver. First set the crop rectangle to match the requested format when trying or setting the sensor format, to match these drivers expectations. Link: https://lore.kernel.org/r/20230529103741.11904-20-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Using the selection / crop info to determine the padding values to use with a specific resolution on specific sensor. This allows e.g. automatically halving the padding when using the max binned resolution and also ensures the right amount of padding is used on models with 2 sensors with different padding requirements. Link: https://lore.kernel.org/r/20230529103741.11904-19-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Make atomisp_init_sensor() check if the sensor supports binning. This is a preparation patch for using the selection / crop support to determine the padding values to use with a specific sensor. Link: https://lore.kernel.org/r/20230529103741.11904-18-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
A sensor driver's enum_frame_size pad-op may return -EINVAL when v4l2_subdev_frame_size_enum.code is not set to a supported MEDIA_BUS_FMT_* code. Make atomisp_init_sensor() get the sensor's MEDIA_BUS_FMT_* code and pass this when calling the enum_frame_size pad-op. Link: https://lore.kernel.org/r/20230529103741.11904-17-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Sensor drivers which implement set_selection V4L2_SEL_TGT_CROP expect v4l2_subdev_state.pads[pad].try_crop to have valid contents when calling set_fmt with which == V4L2_SUBDEV_FORMAT_TRY since the crop-rectangle may influence the available image size. Just passing an uninitalized struct v4l2_subdev_pad_config from the stack to set_fmt with which == V4L2_SUBDEV_FORMAT_TRY will result in wrong results with such drivers. Store a per sensor v4l2_subdev_pad_config and add a new atomisp_init_sensor_crop() function to initialize this before registering /dev/* nodes with userspace. Sensor drivers which implement the selection API will allow the atomisp to properly deal with the extra padding the ISP wants on a per sensor basis instead of hardcoding this. atomisp_init_sensor_crop() stores the native and active rects of the sensor in preparation for using these for this. Link: https://lore.kernel.org/r/20230529103741.11904-16-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
There are a number of bugs in atomisp_try_fmt_cap() and atomisp_set_fmt(): 1. atomisp_try_fmt_cap() uses atomisp_adjust_fmt() which adds the sensor padding to the width passed to atomisp_adjust_fmt() to calculate bytesperline. This is buggy for 2 reasons: a) The width passed to atomisp_adjust_fmt() already contains the sensor padding. b) The fmt returned by atomisp_try_fmt_cap() is the fmt outputted by the ISP and the sensor padding applies to the input side of the ISP not the output side. The output side of the ISP has its own padding / pitch requirements which have nothing to do with the sensor. Both these issues are fixed in this refactor by switching to ia_css_frame_pad_width() to calculate the padding. 2. atomisp_set_fmt() takes the passed in bytesperline value without doing any validation on it and then passes this unchecked value to the configure_output() callback. If bytesperline converted to pixels is > 1920 ia_css_binary_find() will fail to find a valid binary for the preview pipeline triggering a dump_stack_lvl() call inside ia_css_binary_find() and causing atomisp_set_fmt() to fail. This is fixed by making atomisp_set_fmt() call atomisp_try_fmt() first which we override the userspace specified bytesperline with the correct value. Besides this bug there is also a bunch of weirdness and a lot of duplication in the code: 1. atomisp_try_fmt_cap() adds the sensor padding itself but then it gets substracted again in atomisp_adjust_fmt() not doing the addition + substraction in the same place makes the code hard to follow (weirdness). 2. atomisp_set_fmt() starts with basically an atomisp_try_fmt() call, except that the only atomisp_try_fmt() caller: atomisp_try_fmt_cap() adds the sensor padding itself rather than letting atomisp_try_fmt() do this (duplication). 3. Both atomisp_try_fmt_cap() and atomisp_set_fmt() contain code to lookup the bridge-format matching the requested pixelformat and both will fallback to YUV420 if this is not set (duplication). 4. Both atomisp_try_fmt_cap() and atomisp_set_fmt() contain code to fill in the passed in v4l2_pix_format struct (duplication). Cleanup all of this (and fix the bugs mentioned above) by: 1. Adding a new atomisp_fill_pix_format() helper which properly uses ia_css_frame_pad_width() to calculate bytesperline. 2. Move all sensor padding handling to atomisp_try_fmt() and make atomisp_try_fmt() fill the passed in v4l2_pix_format struct. 3. This reduces atomisp_try_fmt_cap() to just a small wrapper around atomisp_try_fmt(). 4. Replace the DIY try_fmt code at the beginning of atomisp_set_fmt() with atomisp_try_fmt(), this will also override/fix the bytersperline passed by userspace. 5. Replace the DIY v4l2_pix_format filling at the end of atomisp_set_fmt() with atomisp_fill_pix_format(). Link: https://lore.kernel.org/r/20230529103741.11904-15-hdegoede@redhat.comSigned-off-by: -
Hans de Goede authored
Factor the code to go from width to a properly aligned pitch out of ia_css_frame_info_set_width(). This is a preparation patch to fix try_fmt() calls returning a bogus bytesperline value. Link: https://lore.kernel.org/r/20230529103741.11904-14-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Passing 'isp->asd->inputs[asd->input_curr].foo' as argument to various function calls is rather long. Add a local input helper variable for this, so that the function calls will fit on one line. Link: https://lore.kernel.org/r/20230529103741.11904-13-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
atomisp_set_fmt*() use a local v4l2_subdev_fh declared on the stack, specifically they use fh.state which is never initialized so when passing fh.state to atomisp_subdev_set_ffmt() / to atomisp_subdev_set_selection() these functions are passing random stack contents as a pointer. The reason this works is because when the which parameter is V4L2_SUBDEV_FORMAT_ACTIVE the passed in state is not used. Remove the bogus fh usage and just pass NULL as state. Link: https://lore.kernel.org/r/20230529103741.11904-12-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
As the 2 comments in the function already say both the sink and the source pads only support setting the selection for 1 target: /* Only crop target supported on sink pad. */ /* Only compose target is supported on source pads. */ Validate that the passed in target actually matches these expectations. Link: https://lore.kernel.org/r/20230529103741.11904-11-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
With the atomisp_subdev_set_selection(sink-pad, V4L2_SEL_TGT_CROP, rect) calls dropped. The first and last compount code blocks of the 3 code blocks in the if (...) {} else if (...) {} else {} code setting the source-pad V4L2_SEL_TGT_COMPOSE selection are the same. The both set V4L2_SEL_TGT_COMPOSE to a rectangle with the same dimensions as f->fmt.pix.height. Remove the else {} block at the end, drop the second if and prepend the first if condition with "!second-if-condition ||" to remove the code duplication. Link: https://lore.kernel.org/r/20230529103741.11904-10-hdegoede@redhat.comSigned-off-by: -
Hans de Goede authored
atomisp_subdev_set_selection(sink-pad, V4L2_SEL_TGT_CROP, rect) ignores the passed in rect, using the width and height from the last atomisp_subdev_set_ffmt(ATOMISP_SUBDEV_PAD_SINK, ffmt) call instead. The atomisp_subdev_set_ffmt() call done by atomisp_set_fmt_to_snr() already propagates the sink ffmt changes to V4L2_SEL_TGT_CROP (this is what allows atomisp_set_fmt() to get the isp_sink_crop in the first place). Remove the redundant atomisp_subdev_set_selection(sink-pad, ...) calls. Note the removed aspect ratio correction in the last else block is is already done by atomisp_subdev_set_selection() itself when setting V4L2_SEL_TGT_COMPOSE on the source-pad. Link: https://lore.kernel.org/r/20230529103741.11904-9-hdegoede@redhat.comSigned-off-by:
-
