summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* media: ti-vpe: cal: program number of lines properlyTomi Valkeinen2020-04-141-2/+1
| | | | | | | | | | | | | | | | | | | CAL_CSI2_CTX register has LINES field, which, according to the documentation, should be programmed to the number of lines transmitted by the camera. If the number of lines is unknown, it can be set to 0. The driver sets the field to 0 for some reason, even if we know the number of lines. This patch sets the number of lines properly, which will allow the HW to discard extra lines (if the sensor would send such for some reason), and, according to documentation: "This leads to regular video timings and avoids potential artifacts". Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: fix dummy read to phyTomi Valkeinen2020-04-141-2/+2
| | | | | | | | | | | | After ComplexIO reset, a dummy read to PHY is needed as per CAL spec to finish the reset. Currently the driver reads a ComplexIO register, not PHY register. Fix this. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: cleanup CIO power enable/disableTomi Valkeinen2020-04-141-36/+31
| | | | | | | | | | Move the code to enable and disable ComplexIO power to its own function. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: use reg_write_fieldTomi Valkeinen2020-04-141-20/+14
| | | | | | | | | | Simplify the code by using reg_write_field() where trivially possible. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: remove useless IRQ definesTomi Valkeinen2020-04-142-10/+4
| | | | | | | | | | | Remove a bunch of IRQ defines, of which only CAL_HL_IRQ_ENABLE and CAL_HL_IRQ_CLEAR are used, and these defines only end up obfuscating code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: remove useless CAL_GEN_* macrosTomi Valkeinen2020-04-142-21/+8
| | | | | | | | | | These macros only obfuscate the code, so drop them. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: simplify irq handlingTomi Valkeinen2020-04-141-43/+25
| | | | | | | | | | Instead of having identical code block to handle irqs for the two CAL ports, we can have a for loop and a single code block. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: print errors on timeoutsTomi Valkeinen2020-04-141-8/+9
| | | | | | | | | | | | | The driver does not print any errors on ComplexIO reset timeout or when waiting for stop-state, making it difficult to debug and notice problems. Add error prints for these cases. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: catch error irqs and print errorsTomi Valkeinen2020-04-142-1/+51
| | | | | | | | | | | | | CAL reports various errors via IRQs, which are not handled at all by the current driver. Add code to enable and catch those IRQs and print errors. This will make it much easier to notice and debug issues with sensors. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil-cisco@xs4all.nl: fix: spaces preferred around that '-'] Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: drop cal_runtime_get/putTomi Valkeinen2020-04-141-17/+7
| | | | | | | | | | Now that cal_runtime_get and cal_runtime_put are only direct wrappers to pm_runtime_get/put, we can drop cal_runtime_get and cal_runtime_put. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: use runtime_resume for errata handlingTomi Valkeinen2020-04-141-14/+22
| | | | | | | | | | | | | | We need to do errata handling every time CAL is being enabled. The code is currently in cal_runtime_get(), which is not the correct place for it. Move the code to cal_runtime_resume, which is called every time CAL is enabled. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: fix use of wrong macroTomi Valkeinen2020-04-141-2/+1
| | | | | | | | | | | | | | i913_errata() sets a bit to 1 in PHY_REG10, but for some reason uses CAL_CSI2_PHY_REG0_HSCLOCKCONFIG_DISABLE for the bit value. The value of that macro is 1, so it works, but is still wrong. Fix this to 1. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: improve enable_irqsTomi Valkeinen2020-04-141-8/+8
| | | | | | | | | | | | | | IRQENABLE_SET registers are (usually) not meant to be read, only written to. The current driver needlessly uses read-modify-write cycle to enable IRQ bits. The read-modify-write has no bad side effects here, but it's still better to clean this up by only using write. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ti-vpe: cal: fix DMA memory corruptionTomi Valkeinen2020-04-141-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the CAL driver stops streaming, it will shut everything down without waiting for the current frame to finish. This leaves the CAL DMA in a slightly undefined state, and when CAL DMA is enabled when the stream is started the next time, the old DMA transfer will continue. It is not clear if the old DMA transfer continues with the exact settings of the original transfer, or is it a mix of old and new settings, but in any case the end result is memory corruption as the destination memory address is no longer valid. I could not find any way to ensure that any old DMA transfer would be discarded, except perhaps full CAL reset. But we cannot do a full reset when one port is getting enabled, as that would reset both ports. This patch tries to make sure that the DMA transfer is finished properly when the stream is being stopped. I say "tries", as, as mentioned above, I don't see a way to force the DMA transfer to finish. I believe this fixes the corruptions for normal cases, but if for some reason the DMA of the final frame would stall a lot, resulting in timeout in the code waiting for the DMA to finish, we'll again end up with unfinished DMA transfer. However, I don't know what could cause such a timeout. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Implement the .enum_mbus_code() operationLaurent Pinchart2020-04-141-0/+33
| | | | | | | | | | Implement the subdev pad .enum_mbus_code() operation to enumerate media bus codes on the sink and source pads. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Don't use imx-media-utils helpersLaurent Pinchart2020-04-141-8/+12
| | | | | | | | | | | | | The imx7-mipi-csis only uses the imx_media_init_mbus_fmt() function from the imx-media-utils helpers. The helpers don't support all the media bus formats used by this driver, and are thus a bad fit. As the MIPI CSIS is a standalone IP core that could be integrated in other SoCs, let's not use the helper. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Cleanup includesLaurent Pinchart2020-04-141-4/+3
| | | | | | | | | Remove unneeded includes, add needed ones, and sort them alphabetically. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Remove link setup on source padLaurent Pinchart2020-04-141-12/+1
| | | | | | | | | | The driver rejects enablement of multiple links on its source pad. This isn't needed, as the CSIS doesn't care. Drop it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Align macro definitionsLaurent Pinchart2020-04-141-65/+65
| | | | | | | | | | The register macros at the top of the file have their value not aligned on the same column, hindering readability. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Never set MIPI_CSIS_ISPCFG_ALIGN_32BITLaurent Pinchart2020-04-141-8/+2
| | | | | | | | | | | | | The MIPI_CSIS_ISPCFG_ALIGN_32BIT bit enables output of 32-bit data. The driver sets it based on the select format, but no format uses a 32-bit bus width, so the bit is never set in practice. This isn't likely to change any time soon, as the CSI IP core connected at the output of the CSIS doesn't support 32-bit data width. Hardcode the bit to 0. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Align image width based on formatLaurent Pinchart2020-04-141-3/+26
| | | | | | | | | | | | | | The total number of bits per line needs to be a multiple of 8, which requires aligning the image width based on the format width. The csis_pix_format structure contains a pix_width_alignment field that serves this purpose, but the field is never set. Instead of fixing that, calculate the alignment constraints based on the bus width for the format, and drop the unneeded pix_width_alignment field. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Rename data_alignment field to widthLaurent Pinchart2020-04-141-23/+23
| | | | | | | | | | The csis_pix_format data_alignment field stores the bus width. Rename it accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Add MEDIA_BUS_FMT_UYVY10_2X10 supportLaurent Pinchart2020-04-141-0/+4
| | | | | | | | | Add support for 10-bit YUV 4:2:2. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Fix MEDIA_BUS_FMT_UYVY8_2X8 data alignmentLaurent Pinchart2020-04-141-1/+1
| | | | | | | | | | The MEDIA_BUS_FMT_UYVY8_2X8 format reports a data alignment of 16 bits, which isn't correct as it is output on an 8-bit bus. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Expose correct YUV formatsLaurent Pinchart2020-04-141-5/+1
| | | | | | | | | | | | The imx7-mipi-csis driver claims to support MEDIA_BUS_FMT_VYUY8_2X8 and MEDIA_BUS_FMT_YUYV8_2X8, but this is not correct. When receiving YUV 4:2:2 data on the CSI-2 bus, the output format is MEDIA_BUS_FMT_UYVY8_2X8. Fix this. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Add missing RAW formatsLaurent Pinchart2020-04-141-9/+69
| | | | | | | | | | | Add support for all the missing 8-, 10-, 12- and 14-bit RAW formats. This include all Bayer combinations, as well as greyscale. No media bus code exist for Y14 so this is currently left out. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Centralize initialization of pad formatsLaurent Pinchart2020-04-141-24/+32
| | | | | | | | | | | | | | Pad formats for the active configuration are manually initialized in mipi_csis_subdev_init(), while pad formats for the TRY configurations are initialized by the subdev .init_cfg() operation. This creates a risk of the two configurations not being synchronized. Fix it by initializing formats in the .init_cfg() operation only, and calling it from mipi_csis_subdev_init(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: imx: imx7-mipi-csis: Cleanup and fix subdev pad format handlingLaurent Pinchart2020-04-141-45/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | The subdev set pad format operation currently misbehaves in multiple ways: - mipi_csis_try_format() unconditionally stores the format in the device state, even for V4L2_SUBDEV_FORMAT_TRY. - The format is never stored in the pad cfg, but the pad cfg format always overwrites the format requested by the user. - The sink format is not propagated to the source. Fix all this by reworking the set format operation as follows: 1. For the source pad, turn set() into get() as the source format is not modifiable. 2. Validate the requested format and updated the stored format accordingly. 3. Return the format actually set. 4. Propagate the format from sink to source. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: venus: core: remove CNOC voting while device suspendMansur Alisha Shaik2020-04-141-4/+8
| | | | | | | | | | | | | 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>
* media: venus: hfi_msgs.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-04-141-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* media: venus: hfi_cmds.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-04-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* media: venus: vdec: Use pmruntime autosuspendStanimir Varbanov2020-04-143-20/+119
| | | | | | | | | | | | 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>
* media: staging: imgu: do not hold spinlock during freeing mmu page tableBingbu Cao2020-04-141-4/+6
| | | | | | | | | | | | | | | 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>
* media: staging/intel-ipu3: Simplify single goto jumpDeepak R Varma2020-04-141-9/+7
| | | | | | | | | | | 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>
* media: doc-rst: add yavta test example in ipu3 docsBingbu Cao2020-04-141-2/+0
| | | | | | | | | 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>
* media: ov5640: fix use of destroyed mutexTomi Valkeinen2020-04-141-2/+2
| | | | | | | | | | | | | | | | | 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>
* media: staging/intel-ipu3: Remove extra blank linesDeepak R Varma2020-04-141-2/+0
| | | | | | | | | 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>
* media: staging/intel-ipu3: css: simplify expressionDeepak R Varma2020-04-141-8/+6
| | | | | | | | | | 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>
* media: staging/intel-ipu3: Implement lock for stream on/off operationsBingbu Cao2020-04-143-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* media: vimc: fix kernel-doc markupsMauro Carvalho Chehab2020-04-142-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* media: vim2m: Remove unneeded buffer lockEzequiel Garcia2020-04-141-8/+0
| | | | | | | | | | | | | | | | | | | | 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>
* media: vimc: add vimc_ent_type struct for the callbacks of entitiesDafna Hirschfeld2020-04-146-60/+67
| | | | | | | | | | | | | 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>
* media: vimc: fix issues in documentation in vimc-common.hDafna Hirschfeld2020-04-141-6/+5
| | | | | | | | | | 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>
* media: vimc: keep the error value when adding an entity failsDafna Hirschfeld2020-04-145-12/+15
| | | | | | | | | | | | 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>
* media: vimc: handle error in vimc_add_subdevsDafna Hirschfeld2020-04-141-20/+22
| | | | | | | | | | | | | | 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>
* media: vimc: remove the function vimc_unregisterDafna Hirschfeld2020-04-141-8/+3
| | | | | | | | | | 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>
* media: coda: jpeg: support optimized huffman tablesAdrian Ratiu2020-04-141-5/+10
| | | | | | | | | | | | | | 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>
* media: coda: lock capture queue wakeup against decoder stop commandPhilipp Zabel2020-04-142-0/+11
| | | | | | | | | | | | | | | | | | 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>
* media: coda: mark last capture bufferPhilipp Zabel2020-04-141-3/+32
| | | | | | | | | | | | 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>
* media: coda: split marking last meta into helper functionPhilipp Zabel2020-04-141-14/+22
| | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-28 15:38:07 +0100