- 21 Apr, 2020 40 commits
-
-
Brad Love authored
Add analog tuner frontend to 888 Hauppauge QuadHD boards Signed-off-by:
Brad Love <brad@nextdimension.cc> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Brad Love authored
In some debugging cases it is useful to know how long it took signal lock to happen after tuning. This can help diagnose line issues. Signed-off-by:
-
Brad Love authored
To detect errors in the tuning operation, this waits up 40ms for operation completion status. This allows for error detection and prevents issuing additional commands to the tuner before it is finished. Tuning typically completes in 20-30ms. Signed-off-by:
-
Brad Love authored
Include set_analog_params, get_frequency, and get_bandwidth. Tested with NTSC and PAL standards via ch3/4 generator. Other standards are included, but are untested due to lack of generator. Signed-off-by:
-
Brad Love authored
Getting the Xtal trim property to check if running is less error prone. Reset if_frequency if state is unknown. Replaces the previous "garbage check". Signed-off-by:
-
Brad Love authored
Check error status bit on command execute, if error bit is set return -EAGAIN. Ignore -EAGAIN in probe during device check. Signed-off-by:
-
Brad Love authored
Enable flags to get status of commands sent to the tuner. Signed-off-by:
-
Boris Brezillon authored
The rockchip vdec block is a stateless decoder that's able to decode H264, HEVC and VP9 content. This commit adds the core infrastructure and the H264 backend. Support for VP9 and HEVS will be added later on. [mchehab+huawei@kernel.org: select MEDIA_CONTROLLER and REQUEST_API] Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Tested-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Boris Brezillon authored
Document the Rockchip RK3399 Video Decoder bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Boris Brezillon authored
Now that the core provides generic reflist builders, we can use them instead of implementing our own. Signed-off-by:
-
Boris Brezillon authored
Building those list is a standard procedure described in section '8.2.4 Decoding process for reference picture lists construction' of the H264 specification. We already have 2 drivers needing the same logic (hantro and rkvdec) and I suspect we will soon have more. Let's provide generic helpers to create those lists. Signed-off-by:
-
Ezequiel Garcia authored
Instead of depending on the Rockchip PHY driver the ISP driver should really depend on CONFIG_GENERIC_PHY_MIPI_DPHY, given all it needs is the phy_mipi_dphy_get_default_config() symbol. Fix it. Signed-off-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
The driver is perfectly capable of being built without CONFIG_OF. Remove this dependency, which is useful for compile-only tests. Signed-off-by:
-
Ezequiel Garcia authored
If CONFIG_OF is not selected, the compiler will complain: drivers/staging/media/rkisp1/rkisp1-dev.c: In function ‘rkisp1_probe’: drivers/staging/media/rkisp1/rkisp1-dev.c:457:22: warning: unused variable ‘node’ [-Wunused-variable] 457 | struct device_node *node = pdev->dev.of_node; Rework the code slightly and make the compiler happy. Suggested-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Seungchul Kim authored
v4l2_fh struct define differently by CONFIG_V4L2_MEM2MEM_DEV. If some vendors use CONFIG_V4L2_MEM2MEM_DEV by module, it can make the mismatch of v4l2_fh sturct. By the mismatch, the following error occurs. =============================== [ 7.533506] v4l2_mem2mem: disagrees about version of symbol video_devdata [ 7.533594] v4l2_mem2mem: Unknown symbol video_devdata (err -22) [ 7.535319] v4l2_mem2mem: disagrees about version of symbol v4l2_event_pending [ 7.542532] v4l2_mem2mem: Unknown symbol v4l2_event_pending (err -22) =============================== So v4l2_fh struct is modified to does not have dependency for CONFIG_V4L2_MEM2MEM_DEV. Signed-off-by:
Seungchul Kim <sc377.kim@samsung.com> Signed-off-by:
-
Dafna Hirschfeld authored
The fields 'fmt_type' in the structs 'rkisp1_rsz_config', 'rkisp1_isp_mbus_info' are of type 'v4l2_pixel_encoding' so it is nicer to change their name to 'pixel_enc'. Also change the define 'RKISP1_DEF_FMT_TYPE' to 'RKISP1_DEF_PIXEL_ENC' Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
-
Dafna Hirschfeld authored
The pixel encoding can be retrieved from the cap->pix.info. Therefore the field fmt_type can be removed from the struct rkisp1_capture_fmt_cfg. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Dafna Hirschfeld authored
The enum rkisp1_fmt_pix_type that holds the pixel format which is one of RGB, YUV, BAYER, can be replace by the v4l2 enum v4l2_pixel_encoding. Signed-off-by:
-
Kieran Bingham authored
Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will enable extra validation on DMA operations ensuring that the size restraints are met. When using the FCP in conjunction with the VSP1/DU, and display frames, the size of the DMA operations is larger than the default maximum segment size reported by the DMA core (64K). With the DMA debug enabled, this produces a warning such as the following: "DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device claims to support [len=3145728] [max=65536]" We have no specific limitation on the segment size which isn't already handled by the VSP1/DU which actually handles the DMA allcoations and buffer management, so define a maximum segment size of up to 4GB (a 32 bit mask). Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Fixes: 7b49235e ("[media] v4l: Add Renesas R-Car FCP driver") Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
-
Dafna Hirschfeld authored
remove the TODO item: * Make sure uapi structs have the same size and layout in 32 and 62 bits, and that there are no holes in the structures (pahole is a utility that can be used to test this). It was tested with pahole and found compatible. Signed-off-by:
-
Dan Carpenter authored
If these functions fail then we return success, but we should instead preserve negative error code and return that. Fixes: fde649b4 ("media: vicodec: Register another node for stateless decoder") Fixes: c022a4a9 ("media: vicodec: add struct for encoder/decoder instance") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Fabio Estevam authored
Improve the documentation by providing examples on how to test camera capture on imx6q-sabresd via v4l2-ctl and Gstreamer. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by: Steve Longerbeam<slongerbeam@gmail.com> Signed-off-by:
-
Fabio Estevam authored
In order to improve the documentation, provide the OV5640 MIPI module part number that is used on the imx6q-sabresd board. Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
-
Fabio Estevam authored
The current example for imx6q-sabresd is for a direct conversion pipeline. Provide an extra example using unprocessed video capture for completeness. Signed-off-by:
-
Fabio Estevam authored
The current instructions for imx6q-sabresd do not lead to functional capture on OV5640 MIPI CSI-2. The reason for this, as explained by Steve Longerbeam, is that OV5640 by default transmits on virtual channel 0, not channel 1 as is given in the instructions. Adapt the instructions to use virtual channel 0 so that a working camera setup can be achieved on imx6q-sabresd. Also, since we are using an IC direct conversion pipeline, improve the example by demonstrating colorspace and scaling. Signed-off-by:
-
Maheshwar Ajja authored
Add H264 profile "Contrained High" and H264 levels "5.2", "6.0", "6.1" and "6.2". Signed-off-by:
Maheshwar Ajja <majja@codeaurora.org> Signed-off-by:
-
Maheshwar Ajja authored
Add H264 profile "Contrained High" and H264 levels "5.2", "6.0", "6.1" and "6.2". Signed-off-by:
-
Fabio Estevam authored
Currently v4l2-compliance tool returns the following output: Compliance test for imx-media-csc-s device /dev/video8: Driver Info: Driver name : imx-media-csc-s Card type : imx-media-csc-scaler Bus info : platform:imx-media-csc-scaler The driver name string is limited to 16 characters, so provide a shorter name in order to get a better output. While at it, use the same shorter name for driver, card and platform. Signed-off-by: -
Colin Ian King authored
The variable status is being assigned a value that is never read. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Colin Ian King authored
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Hsin-Yi Wang authored
aliases property name must include only lowercase and '-'. Fix in dts and driver. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by:
-
Colin Ian King authored
The pointer 'common' is being assigned with a value that is never read, the assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Laurent Pinchart authored
The imx_media_mbus_fmt_to_pix_fmt() and imx_media_mbus_fmt_to_ipu_image() functions do not need to modify their mbus argument, and imx_media_ipu_image_to_mbus_fmt() does not need to modify its ipu_image argument. Make them const. [slongerbeam@gmail.com: Constified mbus arg to imx_media_mbus_fmt_to_ipu_image(), and ipu_image arg to imx_media_ipu_image_to_mbus_fmt(), as well] Signed-off-by:
-
Laurent Pinchart authored
Rename the format lookup and enumeration functions according to their usage: - Rename imx_media_(find|enum)_format() to *_pixel_format() to explicitly state on what formats the functions operate. This aligns the naming scheme with the media bus and IPU format functions that already end with *_mbus_format() and *_ipu_formats(). - Rename all enumeration functions to pluralize 'formats' at the end, as they enumerate multiple formats. Signed-off-by:
-
Steve Longerbeam authored
To make the code easier to follow, split up find_format() into separate search functions for pixel formats and media-bus codes, and inline find_format() into the exported functions imx_media_find_format() and imx_media_find_mbus_format(). Do the equivalent for enum_format(). Also add comment blocks for the exported find|enum functions. The convenience functions imx_media_find_ipu_format() and imx_media_enum_ipu_format() can now be made inline and moved to imx-media.h. Signed-off-by:
-
Laurent Pinchart authored
The imx_media_pixfmt structures include a codes member that stores media bus codes as a fixed array of 4 integers. The functions dealing with the imx_media_pixfmt structures assume that the array of codes is terminated by a 0 element. This mechanism is fragile, as demonstrated by several instances of the structure containing 4 non-zero codes. Fix this by turning the array into a pointer, and providing an IMX_BUS_FMTS macro to initialize the codes member with a guaranteed 0 element at the end. [Fixed a NULL deref of the codes pointer in a couple places] [Added more comments for the struct imx_media_pixfmt members, including a bold NOTE! for future developers that codes pointer is NULL for the in-memory-only formats] Signed-off-by:
-
Steve Longerbeam authored
Add a PIXFMT_SEL_IPU selection flag, to select only the IPU-internal pixel formats, and move the single-entry IPU-internal pixel format arrays into pixel_formats[]. imx_media_find_ipu_format() and imx_media_enum_ipu_format() can now simply call find_format() and enum_format(). The RGB32 format is both an IPU-internal format, and an in-memory format via idmac channels that is supported by the IPUv3 driver, so it appears twice in pixel_formats[], one with ipufmt=false for the in-memory format, and again with ipufmt=true for the IPU-internal format. Signed-off-by:
-
Steve Longerbeam authored
After the introduction of the CS_SEL_BAYER flag, the "codespace" pixel format selection enumeration wording no longer makes sense (and even before, when selecting between YUV or RGB formats, "codespace" was a misuse of the term). Rename - 'enum codespace_sel' to 'enum imx_pixfmt_sel' - CS_SEL_* to PIXFMT_SEL_* - local vars named cs_sel to fmt_sel or just sel No functional changes. Signed-off-by:
-
Steve Longerbeam authored
- imx_media_capture_device_register() needs to use CS_SEL_ANY when finding the format from the attached source subdevice, because the source can be a CSI which supports bayer, and the CSI may have selected a bayer format when it registered. - Likewise, imx_media_init_mbus_fmt() is called from the CSI, so the function may be passed a bayer code. Use CS_SEL_ANY when locating the format. Signed-off-by:
-
Laurent Pinchart authored
The format lookup (and enumeration) functions take a boolean flag to tell if Bayer formats should be considered. This leads to hard to read lines such as return enum_format(fourcc, NULL, index, cs_sel, true, false); where the boolean parameters can easily be mixed. To make the code clearer, add a CS_SEL_BAYER flag that can be passed through the codespace_sel parameter of the lookup functions to replace the bool parameter. [slongerbeam@gmail.com: Instead of declaring CS_SEL_ANY as a bitfield containing only CS_SEL_YUV | CS_SEL_RGB, declare CS_SEL_ANY as all of the above (YUV, RGB, BAYER). A new enum is declared for the YUV | RGB selection as CS_SEL_YUV_RGB, and that is used by sub-devices that don't support BAYER and only allow selecting and enumerating YUV or RGB encodings. CS_SEL_ANY is now only used by the CSI sub-devices and the attached capture interfaces, since only those devices support BAYER formats.] Signed-off-by:
-
