summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-04-14media: venus: core: remove CNOC voting while device suspendMansur Alisha Shaik
The Venus driver is voting Configuration NoC during .probe but not clear voting in .suspend. Because of this NoC is up during shutdown also. As a consequence the whole device could leak energy while in .suspend. So correct this by moving voting in .resume and unvoting in .suspend Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: venus: hfi_msgs.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: venus: hfi_cmds.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: venus: vdec: Use pmruntime autosuspendStanimir Varbanov
Implement pmruntime autosuspend in video decoder. This will allow to save power while the userspace is inactive for some reasonable period of time. Here we power-off venus core clocks and power domain and don't touch vcodec because it is under hardware control. The later decision is made to simplify the code and avoid a mess in the power management code. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: staging: imgu: do not hold spinlock during freeing mmu page tableBingbu Cao
ImgU need set the mmu page table in memory as uncached, and set back to write-back when free the page table by set_memory_wb(), set_memory_wb() can not do flushing without interrupt, so the spinlock should not be hold during ImgU page alloc and free, the interrupt should be enabled during memory cache flush. This patch release spinlock before freeing pages table. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: ipu3.rst: add yuv-downscaling into pipeline diagramBingbu Cao
For ipu3 ImgU image processing, the frame data from TNR can feed into DDR by Output Formatting System or feed into YUV downscaler to do YUV downscaling for secondary output, which is usually used for display. current ImgU image pipeline diagram misses the YUV downscaling, this patch add it to aligh with actual hardware blocks. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: staging/intel-ipu3: Simplify single goto jumpDeepak R Varma
On successful node setup, the code jumps to a cleanup label to perform nodes cleanup. This only call to cleanup using goto label can be included in the for / if blocks to make it look more associated. Signed-off-by: Deepak R Varma <mh12gx2825@gmail.com> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: doc-rst: add yavta test example in ipu3 docsBingbu Cao
This patch add yavta test command in ipu3.rst as an example on how to run simple ImgU test using yavta. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: ov5640: fix use of destroyed mutexTomi Valkeinen
v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting in the use of the destroyed mutex. Fix this by calling moving the mutex_destroy() to the end of the cleanup sequence, as there's no need to destroy the mutex as early as possible. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: stable@vger.kernel.org # v4.14+ Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: staging/intel-ipu3: Remove extra blank linesDeepak R Varma
Remove extra blank lines from the code blocks. Signed-off-by: Deepak R Varma <mh12gx2825@gmail.com> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: staging/intel-ipu3: css: simplify expressionDeepak R Varma
An array index computed inside square brackets complicates the code and also extends the line beyond 80 character. Add new variable to compute array index separately and use it as an index during assignment. Signed-off-by: Deepak R Varma <mh12gx2825@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: staging/intel-ipu3: Implement lock for stream on/off operationsBingbu Cao
Currently concurrent stream off operations on ImgU nodes are not synchronized, leading to use-after-free bugs (as reported by KASAN). [ 250.090724] BUG: KASAN: use-after-free in ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu] [ 250.090726] Read of size 8 at addr ffff888127b29bc0 by task yavta/18836 [ 250.090731] Hardware name: HP Soraka/Soraka, BIOS Google_Soraka.10431.17.0 03/22/2018 [ 250.090732] Call Trace: [ 250.090735] dump_stack+0x6a/0xb1 [ 250.090739] print_address_description+0x8e/0x279 [ 250.090743] ? ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu] [ 250.090746] kasan_report+0x260/0x28a [ 250.090750] ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu] [ 250.090754] ipu3_css_pool_cleanup+0x24/0x37 [ipu3_imgu] [ 250.090759] ipu3_css_pipeline_cleanup+0x61/0xb9 [ipu3_imgu] [ 250.090763] ipu3_css_stop_streaming+0x1f2/0x321 [ipu3_imgu] [ 250.090768] imgu_s_stream+0x94/0x443 [ipu3_imgu] [ 250.090772] ? ipu3_vb2_buf_queue+0x280/0x280 [ipu3_imgu] [ 250.090775] ? vb2_dma_sg_unmap_dmabuf+0x16/0x6f [videobuf2_dma_sg] [ 250.090778] ? vb2_buffer_in_use+0x36/0x58 [videobuf2_common] [ 250.090782] ipu3_vb2_stop_streaming+0xf9/0x135 [ipu3_imgu] Implemented a lock to synchronize imgu stream on / off operations and the modification of streaming flag (in struct imgu_device), to prevent these issues. Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: vimc: fix kernel-doc markupsMauro Carvalho Chehab
There are several markups there that doesn't follow the specs. Fields should be like: @foo: with a collon at the end. Also, continuation lines should be aligned. Failing to do that would cause kernel-doc to parse it wrong. Some of the troubles will even cause warnings: $ ./scripts/kernel-doc -none drivers/media/test_drivers/vimc/vimc-common.h drivers/media/test_drivers/vimc/vimc-common.h:59: error: Cannot parse struct or union! drivers/media/test_drivers/vimc/vimc-common.h:77: warning: Function parameter or member 'bpp' not described in 'vimc_pix_map' drivers/media/test_drivers/vimc/vimc-common.h:120: warning: Function parameter or member 'pipe_cfg' not described in 'vimc_device' drivers/media/test_drivers/vimc/vimc-common.h:120: warning: Function parameter or member 'ent_devs' not described in 'vimc_device' drivers/media/test_drivers/vimc/vimc-common.h:120: warning: Function parameter or member 'mdev' not described in 'vimc_device' drivers/media/test_drivers/vimc/vimc-common.h:120: warning: Function parameter or member 'v4l2_dev' not described in 'vimc_device' drivers/media/test_drivers/vimc/vimc-common.h:137: warning: Function parameter or member 'add' not described in 'vimc_ent_type' drivers/media/test_drivers/vimc/vimc-common.h:137: warning: Function parameter or member 'unregister' not described in 'vimc_ent_type' drivers/media/test_drivers/vimc/vimc-common.h:137: warning: Function parameter or member 'release' not described in 'vimc_ent_type' drivers/media/test_drivers/vimc/vimc-common.h:150: warning: Function parameter or member 'name' not described in 'vimc_ent_config' drivers/media/test_drivers/vimc/vimc-common.h:150: warning: Function parameter or member 'type' not described in 'vimc_ent_config' drivers/media/test_drivers/vimc/vimc-common.h:197: warning: bad line: flags of the pads Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: vim2m: Remove unneeded buffer lockEzequiel Garcia
This spinlock is used solely to call v4l2_m2m_buf_done(). Since buffers are obtained only after being removed from the ready queue, there's no concurrent access, and so no need for synchronization. Remove the spinlock to make sure no one copies this pattern. Some archaeology shows this is a small leftover from ancient code. This driver (then called m2m_testdev) used the videobuf1 framework; commit d80ee38cd845 ("[media] v4l: mem2mem: port m2m_testdev to vb2") converted it to videobuf2. The spinlock was then no longer needed, and this simply went unnoticed. 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>
2020-04-14media: vimc: add vimc_ent_type struct for the callbacks of entitiesDafna Hirschfeld
Since each vimc entity type is defined by the callbacks implementation, it is a good idea to add a struct to hold these callbacks. Each vimc entity then declare its type in the file for the entity. 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>
2020-04-14media: vimc: fix issues in documentation in vimc-common.hDafna Hirschfeld
There are some missing and extra fields and typos in structs documentations in vimc-common.h. Fix it. [mchehab+huawei@kernel.org: add a missing ':' after @bayer field] 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>
2020-04-14media: vimc: keep the error value when adding an entity failsDafna Hirschfeld
Currently when the 'add' callback of an entity fails, a NULL is returned. This hides the error code of the failure and always returns -EINVAL. Replace return NULL with return ERR_PTR(ret) to improve debugging. 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>
2020-04-14media: vimc: handle error in vimc_add_subdevsDafna Hirschfeld
In case the 'add' callback of an entity fails, then all other entities should unregister and released. This should be done inside vimc_add_subdevs so that the function handles its own failure. In order to call vimc_unregister_subdevs and vimc_release_subdevs from vimc_add_subdevs, the order of the function should change. 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>
2020-04-14media: vimc: remove the function vimc_unregisterDafna Hirschfeld
The function vimc_unregister is called only from one place in the code and has only 3 lines so it has no justification. 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>
2020-04-14media: coda: jpeg: support optimized huffman tablesAdrian Ratiu
Each jpeg can have the huffman tables optimized for its specific content meaning that the table lenghts and values don't match the standard table of substitutions so there's no reason to hardcode and expect the standard lengths, otherwise we just end up rejecting optimized jpegs altogether. Tested on CODA960. Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Reviewed-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>
2020-04-14media: coda: lock capture queue wakeup against decoder stop commandPhilipp Zabel
Similar to commit 9ee50a9489f1 ("media: coda: lock capture queue wakeup against encoder stop command"), make sure that a JPEG decoder stop command running concurrently with a decoder finish_run always either flags the last returned buffer or wakes up the capture queue to signal the end of stream condition afterwards. This was not necessary for BIT processor contexts because of the need to release the bitstream buffer with the stream end condition. In contrast, the JPEG decoder can be finished with decoding the image between the time the application queues the last output buffer and the time it issues the decoder stop command. 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>
2020-04-14media: coda: mark last capture bufferPhilipp Zabel
If a JPEG decoding application queues the last capture and output buffers, issues a decoder stop command after the decoding is already done, and then dequeues the last capture buffer, it is not marked as last. Detect this condition in the decoder stop command and mark the last buffer on the capture done list. 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>
2020-04-14media: coda: split marking last meta into helper functionPhilipp Zabel
Split marking the last metadata entry into a helper function to simplify coda_decoder_cmd. 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>
2020-04-14media: coda: jpeg: add CODA960 JPEG decoder supportPhilipp Zabel
This patch adds JPEG decoding support for CODA960, handling the JPEG hardware directly. A separate JPEG decoder video device is created due to the separate hardware unit and different supported pixel formats. While the hardware can not change subsampling on the fly, it can decode 4:2:2 subsampled JPEG images into YUV422P. [m.felsch@pengutronix.de: fix qsequence counting by explicitly checking for the !use_bit case] [hverkuil-cisco@xs4all.nl: fix 'warning: missing braces around initializer'] [mchehab+huawei@kernel.org: fix 'BRACES: Unbalanced braces around else statement'] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 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>
2020-04-14media: add v4l2 JPEG helpersPhilipp Zabel
Add helpers for JPEG header parsing. They allow both scanning for marker segment positions and later parsing the segments individually, as required by s5p-jpeg, as well as parsing all headers in one go, as required by coda-vpu. The frame header is always parsed, as basically all decoders are interested in width, height, and number of components. For convenience, the JPEG chroma subsampling factors are decoded into a v4l2_jpeg_chroma_subsampling enum. Only baseline and extended sequential DCT encoded JPEGs with 8-bit or 12-bit precision with up to four components are supported. 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>
2020-04-14media: coda: round up decoded buffer size for all codecsPhilipp Zabel
The BIT decoders always write 16x16 macroblocks. Align stride and height to avoid spilling luma data into the top of the chroma planes. 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>
2020-04-14media: v4l2-common: Add BGR666 to v4l2_format_infoDafna Hirschfeld
Add V4L2_PIX_FMT_BGR666 to the format table. 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>
2020-04-14media: doc-rst: in the RGB formats table add '-' in undefined bitsDafna Hirschfeld
In the table of the RGB formats, add an explicit '-' signs to cells that contain undefined bits. This makes it more clear how many bits and bytes are used for each format. 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>
2020-04-14media: imx.rst: Add example media graphsSteve Longerbeam
Add the media graph topologies for the i.MX6Q SabreSD and SabreAuto. This makes it easier to understand the topology and follow the entity descriptions in the following sections. Also clarify that the SabreSD and SabreLite media pipeline config examples are for the i.MX6Q boards. Signed-off-by: Steve Longerbeam <slongerbeam@gmail.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>
2020-04-14media: v4l2-common: change the pixel_enc of V4L2_PIX_FMT_GREY to YUVDafna Hirschfeld
V4L2_PIX_FMT_GREY format is Ycbcr format without the color data, therefore its pixel_enc should set to V4L2_PIXEL_ENC_YUV. 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>
2020-04-14media: usb: pvrusb2: convert to use i2c_new_client_device()Wolfram Sang
Move away from the deprecated API. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Mike Isely <isely@pobox.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: usb: hdpvr: convert to use i2c_new_client_device()Wolfram Sang
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: usb: cx231xx: convert to use i2c_new_client_device()Wolfram Sang
Move away from the deprecated API and make use of the fact that unregistering devices is NULL- and ERR_PTR-safe. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: marvell-ccic: convert to use i2c_new_client_device()Wolfram Sang
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: pci: saa7134: convert to use i2c_new_client_device()Wolfram Sang
Move away from the deprecated API. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: pci: cx88: convert to use i2c_new_client_device()Wolfram Sang
Move away from the deprecated API and make use of the fact that unregistering devices is NULL- and ERR_PTR-safe. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: dt-bindings: rockchip-vpu: Convert bindings to json-schemaEzequiel Garcia
Convert Rockchip VPU (Hantro IP block) codec driver documentation to json-schema. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: hantro: Refactor for V4L2 API spec compliancyEzequiel Garcia
Refactor how S_FMT and TRY_FMT are handled, and also make sure internal initial format and format reset are done properly. The latter is achieved by making sure the same hantro_{set,try}_fmt helpers are called on all paths that set the format (which is part of the driver state). This commit removes the following v4l2-compliance warnings: test VIDIOC_G_FMT: OK fail: v4l2-test-formats.cpp(711): Video Capture Multiplanar: TRY_FMT(G_FMT) != G_FMT test VIDIOC_TRY_FMT: FAIL fail: v4l2-test-formats.cpp(1116): Video Capture Multiplanar: S_FMT(G_FMT) != G_FMT test VIDIOC_S_FMT: FAIL Reported-by: Nicolas Dufresne <nicolas.dufresne@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>
2020-04-14media: hantro: Move H264 motion vector calculation to a helperEzequiel Garcia
Move the extra bytes calculation that are needed for H264 motion vector to a helper. This is just a cosmetic cleanup. 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>
2020-04-14media: hantro: Remove unneeded hantro_dec_buf_finishEzequiel Garcia
Since now .buf_prepare takes care of setting the buffer payload size, we can get rid of this, at least for decoders. 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>
2020-04-14media: hantro: Use v4l2_m2m_buf_done_and_job_finishEzequiel Garcia
Let the core sort out the nuances of returning buffers to userspace, by using the v4l2_m2m_buf_done_and_job_finish helper. 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>
2020-04-14media: hantro: Set buffers' zeroth plane payload in .buf_prepareEzequiel Garcia
Buffers' zeroth plane payload size is calculated at format negotiation time, and so it can be set in .buf_prepare. Keep in mind that, to make this change easier, hantro_buf_prepare is refactored, using the cedrus driver as reference. This results in cleaner code as byproduct. 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>
2020-04-14media: v4l2-mem2mem: return CAPTURE buffer firstEzequiel Garcia
When the request API is used, typically an OUTPUT (src) buffer will be part of a request. A userspace process will be typically blocked, waiting on the request file descriptor. Returning the OUTPUT (src) buffer will wake-up such processes, who will immediately attempt to dequeue the CAPTURE buffer, only to find it's still unavailable. Therefore, change v4l2_m2m_buf_done_and_job_finish returning the CAPTURE (dst) buffer first, to avoid signalling the request file descriptor prematurely, i.e. before the CAPTURE buffer is done. When the request API is not used, this change should have no impact. Tested-by: Nicolas Dufresne <nicolas.dufresne@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>
2020-04-14Revert "media: Kconfig: better support hybrid TV devices"Mauro Carvalho Chehab
Changing from "depends on" to "select" may cause some side-effects. This patch is not ready to be merged yet, as it requires some adjustments. So, let's revert it. This reverts commit a3b91d8bd1e034c8ed89d3f55243478af97a0a52. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: docs: get rid of Documentation/media/Mauro Carvalho Chehab
Now that everything got moved, we can get rid of the old media directory. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: docs: add an uAPI chapter for driver-specific stuffMauro Carvalho Chehab
There are some uAPI stuff that are driver-specific. Add them to the main media uAPI body. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: docs: move driver-specific info to driver-apiMauro Carvalho Chehab
Those documents don't really describe the driver API. Instead, they contain development-specific information. Yet, as the main index file describes the content of it as: "how specific kernel subsystems work from the point of view of a kernel developer" It seems to be the better fit. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: docs: move user-facing docs to the admin guideMauro Carvalho Chehab
Most of the driver-specific documentation is meant to help users of the media subsystem. Move them to the admin-guide. It should be noticed, however, that several of those files are outdated and will require further work in order to make them useful again. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: docs: move fourcc file to the uAPI documentMauro Carvalho Chehab
This file gives a hint about how fourcc should be named. It is on a very weird place, as such kind of thing belongs to the uAPI guide. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: docs: kAPI docs: move them to driver-apiMauro Carvalho Chehab
All those documents describe the media driver API. So, move them to the right place within the Kernel documentation. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>