- 21 Apr, 2020 40 commits
-
-
Dafna Hirschfeld authored
Planar formats with the u and v planes swapped can be supported by swapping the address of the cb and cr buffers. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
The register RKISP1_CIF_MI_XTD_FORMAT_CTRL is relevant only for semiplanar formats, therefore the uv swap can be supported through this register only for semiplanar formats. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
The register RKISP1_CIF_MI_XTD_FORMAT_CTRL is currently written with "on" only if the u,v streams need to be swapped. This patch also write to it with "off" if they don't need to be swapped. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
The value RKISP1_CIF_MI_XTD_FMT_CTRL_SP_CB_CR_SWAP should be set to the register instead of masking with ~BIT(1) Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
The value RKISP1_CIF_MI_XTD_FMT_CTRL_MP_CB_CR_SWAP equals BIT(0), Therefore when writing it to the register there is no need to mask it first with ~BIT(0). Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Marco Felsch authored
Add common (Full-)HD definitions also known as 720p and 1080p. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Philipp Zabel authored
Currently the encoder enables the rate control algorithms if the bitrate control is non-zero. Implement the V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE and V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE controls to allow userspace to choose frame-level or macroblock-level rate control updates, or to explicitly disable rate control. Both controls are initially enabled to keep the current behavior. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
don't call 'v4l2_async_notifier_parse_fwnode_endpoints_by_port' in order to register async subdevices. Instead call 'v4l2_fwnode_endpoint_parse' to parse the remote endpoints and then register each async subdev with 'v4l2_async_notifier_add_fwnode_remote_subdev' Also remove the relevant item in the TODO file Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
'struct v4l2_mbus_config' is a legacy struct that should not be used in new drivers. So replace it with the fields: enum v4l2_mbus_type mbus_type; unsigned int mbus_flags; Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Helen Koike authored
In order to support simultaneous streaming from both capture devices, start/stop vb2 calls need to be serialized to allow multiple concurrent calls. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Helen Koike authored
If no errors occurs, pm functions return usage counters, so they can return positive numbers. This happens when streaming from multiple capture devices (mainpath and selfpath). Fix simultaneous streaming from mainpath and selfpath by not failing when pm usage counters returns a positive number. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Rather than creating new compound control helpers for each new type, create one generic function and just create defines on top. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
If the v4l2_ctrl_g_ctrl*() or __v4l2_ctrl_s_ctrl*() functions are called for the wrong control type then they call WARN_ON since that is a driver error. But they still continue, potentially overwriting data. Change this to return an error (s_ctrl) or 0 (g_ctrl), just to be safe. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
Since commit 4957133f ("media: lirc: improve locking"), drivers do not need to do any of their own locking. During suspend and resume, no processes are running so no locking is needed. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Brad Love authored
Remove vbi_regs_offset from a group of registers that are 888 specific, include those registers names. Sources used for reference are 885 and 888 datasheets. Add labels to some undocumented registers. 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
The CNR is already calculated, so populate DVBv5 CNR stat during read_status. 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
Add get_rf_strength callback to get RSSI from the tuner. DVBv5 stat cache is updated. get_rf_strength is called by tuner_core for analog tuners and is also used by some bridge drivers to obtain RSSI directly from the tuner. 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
The boards listed below use i2c device drivers and have tuner_type equal TUNER_ABSENT. This means additional support is required to enable the analog tuning capability, a case statement is used to identify these models. Models with analog tuning enabled: - CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx (tested) - CX231XX_BOARD_HAUPPAUGE_935C (tested) - CX231XX_BOARD_HAUPPAUGE_955Q (tested) - CX231XX_BOARD_HAUPPAUGE_975 (tested) - CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD (untested) The EvroMedia model was added, since it uses the si2157 tuner and the board profile claims it has analog inputs. 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
Hauppauge QuadHD/1265/5525 boards all use i2c device drivers and have tuner_type equal TUNER_ABSENT. This means additional support is required to enable the analog tuning capability, a case statement is used to identify these models. 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
Enables the analog tuning frontend for Hauppauge HVR-5525. 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
Enables the analog tuning frontend for Hauppauge HVR-1265_K4. 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
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 <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Brad Love authored
Enable flags to get status of commands sent to the tuner. 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>
-
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Boris Brezillon authored
Document the Rockchip RK3399 Video Decoder bindings. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <boris.brezillon@collabora.com> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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: Ezequiel Garcia <ezequiel@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <ezequiel@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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: Ezequiel Garcia <ezequiel@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-