- 12 Jul, 2021 40 commits
-
-
Tomi Valkeinen authored
cal_async_notifier_complete() doesn't handle errors returned from cal_ctx_v4l2_register(). Add the error handling. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.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>
-
Tomi Valkeinen authored
In preparation for supporting multiple virtual channels and datatypes, add vc and datatype fields to cal_ctx, initialize them to the currently used values, and use those fields when writing to the register. Signed-off-by:
-
Tomi Valkeinen authored
I have not noticed any errors due to this, but the DMA configuration looks racy. Setting the DMA mode bitfield in CAL_WR_DMA_CTRL supposedly enables the DMA. However, the driver currently a) continues configuring the DMA after setting the mode, and b) enables the DMA interrupts only after setting the mode. This probably doesn't cause any issues as there should be no data coming in to the DMA yet, but it's still better to fix this. Add a new function, cal_ctx_wr_dma_enable(), to set the DMA mode field, and call that function only after the DMA config and the irq enabling has been done. Signed-off-by:
-
Tomi Valkeinen authored
We already have functions to reserve and release a pix proc unit, but we always reserve such and the code expects the pix proc unit to be used. Add a new field, 'use_pix_proc', to indicate if the pix prox unit has been reserved and should be used. Use the flag to skip programming pix proc unit when not needed. Note that we still always set the use_pix_proc flag to true. Signed-off-by:
-
Tomi Valkeinen authored
CAL has 4 pixel processing units but the units are not needed e.g. for metadata. As we could be capturing 4 pixel streams and 4 metadata streams, i.e. using 8 DMA contexts, we cannot assign a pixel processing unit to every DMA context. Instead we need to reserve a pixel processing unit only when needed. Add functions to reserve and release a pix proc unit, and use them in cal_ctx_prepare/unprepare. Note that for the time being we still always reserve a pix proc unit. Signed-off-by:
-
Tomi Valkeinen authored
Disable CSI2 context and pix proc in cal_ctx_stop() to ensure they are not used if the same context is used later on a different PHY or without pix proc. Signed-off-by:
-
Tomi Valkeinen authored
Asserting ComplexIO reset seems to affect the HW (ie. asserting reset will break an active capture), but the RESET_DONE bit never changes to "reset is ongoing" state. Thus we always get a timeout. Drop the wait, as it seems to achieve nothing. Signed-off-by:
-
Tomi Valkeinen authored
CAL driver currently ignores VC related errors. To help catch error conditions, enable all the VC error interrupts and handle them in the interrupt handler by printing an error. Signed-off-by:
-
Tomi Valkeinen authored
The macros related to CAL_CSI2_VC_IRQ can be handled better by having the VC number as a macro parameter. Note that the macros are not used anywhere yet, so no other changes are needed. Signed-off-by:
-
Tomi Valkeinen authored
CAL_HL_IRQ_MASK macro is used for both WDMA start and end status bits. For clarity, rename CAL_HL_IRQ_MASK macro to CAL_HL_IRQ_WDMA_END_MASK and CAL_HL_IRQ_WDMA_START_MASK. Signed-off-by:
-
Tomi Valkeinen authored
Rename cal_ctx->index to dma_ctx to clarify that the field refers to the DMA context number. Signed-off-by:
-
Tomi Valkeinen authored
CAL has 4 pixel processing contexts (PIX PROC) of which the driver currently uses pix proc 0 for PHY0, and pix proc 1 for PHY1 (as the driver supports only a single source per PHY). Add a pix_proc field to cal_ctx to allow us to use different pix proc contexts in the future Signed-off-by:
-
Tomi Valkeinen authored
CAL has 8 CSI2 contexts per PHY, which are used to tag the incoming data. The current driver only uses the first context, but we need to support all of them to implement multi-stream support. Add a csi2_ctx field to cal_ctx, which indicates which of the 8 CSI2 contexts is used for the particular cal_ctx. Also clean up the context register macros to take the CSI2 context number as a parameter. Note that before this patch the CSI2 context used for both PHYs was always 0. This patch always uses cal_ctx index number as the CSI2 context. There is no functional difference, but this approach will work also in the future when we use more than 1 CSI2 context per PHY. Signed-off-by:
-
Tomi Valkeinen authored
cal_ctx's index and cport fields are numbers less than 8. In the following patches we will get a bunch of new fields, all of which are similar small numbers, so lets change the type to u8. Signed-off-by:
-
Tomi Valkeinen authored
In the following patches we need to do context configuration which might fail. Add new functions, cal_ctx_prepare and cal_ctx_unprepare, to handle such configuration. [hverkuil: fix spurious newline checkpatch warning] Signed-off-by:
-
Tomi Valkeinen authored
CAL driver uses V4L2_CID_PIXEL_RATE to get the required pixel rate, and then changes that value to link rate before configuring the registers. Rewrite the code to use v4l2_get_link_freq(), which simplifies the code as we get the link rate directly, and it also adds support for V4L2_CID_LINK_FREQ. Signed-off-by:
-
Tomi Valkeinen authored
For some reason CAL_CTRL is written at the end of cal_ctx_wr_dma_config. CAL_CTRL is a global (for CAL) register, so it should be independent of contexts. Move the code to cal_runtime_resume(). Signed-off-by:
-
Tomi Valkeinen authored
CAL driver uses "sensor" name to refer to the subdev connected to CAL. As the subdev can also be a bridge, the naming is misleading and might cause the reader to think it refers to the actual sensor at the end of the pipeline. Rename "sensor" to "source". Signed-off-by:
-
Tomi Valkeinen authored
cal_camerarx->dev field is not used, remove it. Signed-off-by:
-
Tomi Valkeinen authored
cal_camerarx_create() doesn't handle error returned from cal_camerarx_sd_init_cfg(). Fix this. Signed-off-by:
-
Tomi Valkeinen authored
v4l2-compliance complains about g/s_parm when using the non-MC API. Fix it by adding the functions and just call v4l2_s/g_parm_cap for the phy subdev. Signed-off-by:
-
Colin Ian King authored
The continue statement at the end of a for-loop has no effect, remove it. Addresses-Coverity: ("Continue has no effect") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Yang Yingliang authored
Convert list_for_each() to list_for_each_entry() where applicable. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Herman authored
Change 'gettig' into 'getting'. Signed-off-by:
Herman <yanshuaijun@yulong.com> Signed-off-by:
-
Hans Verkuil authored
The max number of allowed logical addresses was set to 1 in vivid, for no good reason. This prevented testing with multiple logical addresses for the same CEC device. Increase this number to CEC_MAX_LOG_ADDRS. Signed-off-by:
-
Krzysztof Hałasa authored
Without this patch, the TDA19971 chip's EDID is inactive. EDID never worked with this driver, it was all tested with HDMI signal sources which don't need EDID support. Signed-off-by:
Krzysztof Halasa <khalasa@piap.pl> Fixes: 9ac0038d ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by:
-
Herman authored
media: drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c : fix typo 'in deed imporant' > 'indeed important' Change 'imporant' into 'important'. Signed-off-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'saa7134_pgtable_alloc()', GFP_KERNEL can be used because its 4 callers (one function calls it 2 times, so there is only 3 functions that call it): .hw_params in a struct snd_pcm_ops (saa7134-alsa.c) --> snd_card_saa7134_hw_params (saa7134-alsa.c) --> saa7134_pgtable_alloc ==> .hw_params function can use GFP_KERNEL saa7134_initdev (saa7134-core.c) --> saa7134_hwinit1 (saa7134-core.c) --> saa7134_ts_init1 (saa7134-ts.c) --> saa7134_pgtable_alloc ==> saa7134_initdev already uses GFP_KERNEL saa7134_initdev (saa7134-core.c) --> saa7134_hwinit1 (saa7134-core.c) --> saa7134_video_init1 (saa7134-video.c) --> saa7134_pgtable_alloc (called 2 times) ==> saa7134_initdev already uses GFP_KERNEL and no spin_lock is taken in the between. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
lijian authored
deleted the repeated word 'the' in the comments. Signed-off-by:
lijian <lijian@yulong.com> Signed-off-by:
-
Herman authored
Change 'Proabably' into 'Probably'. Signed-off-by:
-
Eugen Hristev authored
SAMA5D2 does not have the YCYC field for the RLP (rounding, limiting, packaging) module. The YCYC field is supposed to work with interleaved YUV formats like YUYV. In SAMA5D2, we have to use YYCC field, which is used for both planar formats like YUV420 and interleaved formats like YUYV. Fix the according rlp callback to replace the generic YCYC field (which makes more sense from a logical point of view) with the required YYCC field. Fixes: debfa496 ("media: atmel: atmel-isc-base: add support for more formats and additional pipeline modules") Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
-
Colin Ian King authored
The variable ret is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Herman authored
Change 'Fliker' into 'Flicker'. Signed-off-by:
-
Herman authored
change 'syncrous' into 'synchronous' Signed-off-by:
-
Jernej Skrabec authored
Now that segment address is available, support for multi-slice frames can be easily added. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
-
Jernej Skrabec authored
If HEVC frame consists of multiple slices, segment address has to be known in order to properly decode it. Add segment address field to slice parameters. Signed-off-by:
-
Mauro Carvalho Chehab authored
As warned by smatch: drivers/media/pci/ivtv/ivtv-i2c.c:245 ivtv_i2c_register() error: buffer overflow 'hw_devicenames' 21 <= 31 drivers/media/pci/ivtv/ivtv-i2c.c:266 ivtv_i2c_register() error: buffer overflow 'hw_addrs' 21 <= 31 drivers/media/pci/ivtv/ivtv-i2c.c:269 ivtv_i2c_register() error: buffer overflow 'hw_addrs' 21 <= 31 drivers/media/pci/ivtv/ivtv-i2c.c:275 ivtv_i2c_register() error: buffer overflow 'hw_addrs' 21 <= 31 drivers/media/pci/ivtv/ivtv-i2c.c:280 ivtv_i2c_register() error: buffer overflow 'hw_addrs' 21 <= 31 drivers/media/pci/ivtv/ivtv-i2c.c:290 ivtv_i2c_register() error: buffer overflow 'hw_addrs' 21 <= 31 The logic at ivtv_i2c_register() could let buffer overflows at hw_devicenames and hw_addrs arrays. This won't happen in practice due to a carefully-contructed logic, but it is not error-prune. Change the logic in a way that will make clearer that the I2C hardware flags will affect the size of those two arrays, and add an explicit check to avoid buffer overflows. While here, use the bit macro. Reviewed-by:
-
Mauro Carvalho Chehab authored
As warned by smatch: drivers/media/usb/uvc/uvc_v4l2.c:911 uvc_ioctl_g_input() error: doing dma on the stack (&i) drivers/media/usb/uvc/uvc_v4l2.c:943 uvc_ioctl_s_input() error: doing dma on the stack (&i) those two functions call uvc_query_ctrl passing a pointer to a data at the DMA stack. those are used to send URBs via usb_control_msg(). Using DMA stack is not supported and should not work anymore on modern Linux versions. So, use a kmalloc'ed buffer. Cc: stable@vger.kernel.org # Kernel 4.9 and upper Reviewed-by:
-
Mauro Carvalho Chehab authored
The logic at delta_ipc_open() tries to copy past the size of the name passed to it: drivers/media/platform/sti/delta/delta-ipc.c:178 delta_ipc_open() error: __memcpy() 'name' too small (17 vs 32) Basically,this function is called just one with: ret = delta_ipc_open(pctx, "JPEG_DECODER_HW0", ...); The string used there has just 17 bytes. Yet, the logic tries to copy the entire name size (32 bytes), which is plain wrong. Replace it by strscpy, which is good enough to copy the string, warranting that this will be NUL-terminated. Signed-off-by: -
Mauro Carvalho Chehab authored
The logic at dib8000_get_init_prbs() has a few issues: 1. the tables used there has an extra unused value at the beginning; 2. the dprintk() message doesn't write the right value when transmission mode is not 8K; 3. the array overflow validation is done by the callers. Rewrite the code to fix such issues. This should also shut up those smatch warnings: drivers/media/dvb-frontends/dib8000.c:2125 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_8k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2129 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_2k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2131 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_4k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2134 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_8k' 14 <= 14 Signed-off-by:
-
