- 23 Nov, 2018 40 commits
-
-
Hans Verkuil authored
The v4l2_dv_timings_cap struct is used to do sanity checks when setting and enumerating DV timings, ensuring that only valid timings as per the HW capabilities are allowed. However, many drivers just filled in 0 for the minimum width, height or pixelclock frequency. This can cause timings with e.g. 0 as width and height to be accepted, which will in turn lead to a potential division by zero. Fill in proper values are minimum boundaries. 640x350 was chosen since it is the smallest resolution in v4l2-dv-timings.h. Same for 13 MHz as the lowest pixelclock frequency (it's slightly below the minimum of 13.5 MHz in the v4l2-dv-timings.h header). Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Hans Verkuil authored
The use of flush_schedule_work() made no sense and caused a syzkaller error. Replace with the correct cancel_delayed_work_sync(). Signed-off-by:
-
Hans Verkuil authored
If you create multiple vivid instances, each with their own media device, then there was no way to tell them apart. Fill in the bus_info so each instance has a unique bus_info string. Signed-off-by:
-
Julia Lawall authored
The video_device structure is only copied into another structure, so it can be const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
The capture DV timings capabilities allowed for a minimum width and height of 0. So passing a timings struct with 0 values is allowed and will later cause a division by zero. Ensure that the width and height must be >= 16 to avoid this. Signed-off-by:
-
Hans Verkuil authored
kthread_run returns an error pointer, but elsewhere in the code dev->kthread_vid_cap/out is checked against NULL. If kthread_run returns an error, then set the pointer to NULL. I chose this method over changing all kthread_vid_cap/out tests elsewhere since this is more robust. Signed-off-by:
-
Julia Lawall authored
The fields of a v4l2_subdev_ops structure are all const, so the structures that are stored there and are not used elsewhere can be const as well. Done with the help of Coccinelle. Signed-off-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
Julia Lawall authored
The v4l2_m2m_ops structure can be const as it is only passed to v4l2_m2m_init whose parameter is const. Done with the help of Coccinelle. Signed-off-by:
-
Julia Lawall authored
The v4l2_ctrl_ops structure is only stored in the ops field of a v4l2_ctrl_config structure, and this field is const, or passed as the second argument of v4l2_ctrl_new_std, and the corresponding parameter is declared as const. Accordingly, the structure can also be const. Done with the help of Coccinelle. Signed-off-by:
-
Sean Young authored
Do a series of minor corrections at the V4L2 uAPI documentation. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Hans Verkuil authored
I noticed that repeatedly running 'cec-ctl --playback' would occasionally select 'Playback Device 2' instead of 'Playback Device 1', even though there were no other Playback devices in the HDMI topology. This happened both with 'real' hardware and with the vivid CEC emulation, suggesting that this was an issue in the core code that claims a logical address. What 'cec-ctl --playback' does is to first clear all existing logical addresses, and immediately after that configure the new desired device type. The core code will poll the logical addresses trying to find a free address. When found it will issue a few standard messages as per the CEC spec and return. Those messages are queued up and will be transmitted asynchronously. What happens is that if you run two 'cec-ctl --playback' commands in quick succession, there is still a message of the first cec-ctl command being transmitted when you reconfigure the adapter again in the second cec-ctl command. When the logical addresses are cleared, then all information about outstanding transmits inside the CEC core is also cleared, and the core is no longer aware that there is still a transmit in flight. When the hardware finishes the transmit it calls transmit_done and the CEC core thinks it is actually in response of a POLL messages that is trying to find a free logical address. The result of all this is that the core thinks that the logical address for Playback Device 1 is in use, when it is really an earlier transmit that ended. The main transmit thread looks at adap->transmitting to check if a transmit is in progress, but that is set to NULL when the adapter is unconfigured. adap->transmitting represents the view of userspace, not that of the hardware. So when unconfiguring the adapter the message is marked aborted from the point of view of userspace, but seen from the PoV of the hardware it is still ongoing. So introduce a new bool transmit_in_progress that represents the hardware state and use that instead of adap->transmitting. Now the CEC core waits until the hardware finishes the transmit before starting a new transmit. Signed-off-by:
-
Hans Verkuil authored
If debug_phys_addr is set, then CEC_CAP_PHYS_ADDR is added to the CEC adapter capabilities. This allows for testing CEC even if the physical address isn't set. This makes it possible to connect two HDMI outputs together and still use CEC. Very useful for testing CEC if you don't have access to an HDMI receiver under linux. Signed-off-by:
-
Hans Verkuil authored
The CEC specification requires that the Vendor ID (if any) is reported after a logical address was claimed. This was never done, so add support for this. Signed-off-by:
-
Hans Verkuil authored
The CEC IP is very similar between the three HDMI receivers, but not identical. Add support for all three variants. Tested with an adv7604 and an adv7612. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Hans Verkuil authored
If a filehandle is dup()ped, then it is possible to close it from one fd and call mmap from the other. This creates a race condition in vb2_mmap where it is using queue data that __vb2_queue_free (called from close()) is in the process of releasing. By moving up the mutex_lock(mmap_lock) in vb2_mmap this race is avoided since __vb2_queue_free is called with the same mutex locked. So vb2_mmap now reads consistent buffer data. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Reported-by: syzbot+be93025dd45dccd8923c@syzkaller.appspotmail.com Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Hans Verkuil authored
Return 0 when invalidating the logical address. The cec core produces a warning for drivers that do this. Signed-off-by:
Torbjorn Jansson <torbjorn.jansson@mbox200.swipnet.se> Signed-off-by:
-
Hans Verkuil authored
If the tx_ignore_nack_until_eom error injection was activated, then tx_nacked was never set instead of setting it when the last byte of the message was transmitted. As a result the transmit was marked as OK, when it should have been NACKed. Modify the condition so that it always sets tx_nacked when the last byte of the message was transmitted. Signed-off-by:
-
Ricardo Ribalda Delgado authored
Documentation and code was linking the old documentation at: http://v4l2spec.bytesex.org/spec/x1904.htmSigned-off-by:
Ricardo Ribalda Delgado <ricardo@ribalda.com> Signed-off-by:
-
kbuild test robot authored
drivers/staging/media/sunxi/cedrus/cedrus.c:421:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Fixes: 50e76151 ("media: platform: Add Cedrus VPU decoder driver") CC: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
kbuild test robot <fengguang.wu@intel.com> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Jacopo Mondi authored
The R-Car CSI-2 interface has a number of selectable 'channels' that provides pixel data to the VINs during image acquisition. Each channel can be used to match a CSI-2 data type and a CSI-2 virtual channel to be routed to output path. Different SoCs have different number of channels, with R-Car E3 being the notable exception supporting only 2 of them. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
-
Jacopo Mondi authored
Update PHTW tables for V3M and E3 SoCs to the latest datasheet release (R-Car Series, 3rd Generation manual rev1.00 20181017). Signed-off-by:
-
Jacopo Mondi authored
Add support for R-Car E3 R8A77965 to R-Car CSI-2 driver. Based on the experimental patch from Magnus Damm. Signed-off-by:
-
Jacopo Mondi authored
Add compatible string for R-Car E3 R8A77990 to the list of supported SoCs. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
-
Jacopo Mondi authored
Add R-Car E3 R8A77990 SoC to the rcar-vin supported ones. Based on the experimental patch from Magnus Damm. Signed-off-by:
-
Jacopo Mondi authored
Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by rcar-vin driver. Signed-off-by:
-
Fabio Estevam authored
Improve the pxp_soft_reset() error message by moving it to the caller function, associating it with a proper device and also by displaying the error code. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Fabio Estevam authored
pxp_soft_reset() may fail with a timeout, so it is better to propagate the error in this case. Signed-off-by:
-
Fabio Estevam authored
clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of error. Signed-off-by:
-
Philipp Zabel authored
In addition to the S_FMT debug output, S_SELECTION (SEL_TGT_CROP) is relevant to determine encoded size. Add debug output for it. Signed-off-by:
-
Philipp Zabel authored
Consistently add the context index to debug output, which otherwise is impossible to make sense of when two contexts are running concurrently. For this purpose, add a convenience macro coda_dbg(). Use the function name with the coda_ prefix stripped as keyword where applicable, and consistently use vid-out and vid-cap names for the queues. Add sequence counters to the decoder job finished message and correctly indicate B frames. Add a start streaming message to complement the stop streaming message and a start encoding message to complement the existing start decoding message. Signed-off-by:
-
Philipp Zabel authored
Use v4l2_type_names to indicate which of the two queues is busy. Signed-off-by:
-
Michael Tretter authored
The error code looks much more like a bit field than an error value. Print it as hex rather than decimal. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
v4l2-compliance complains if S_SELECTION returns 0 for read-only targets. Signed-off-by:
-
Philipp Zabel authored
v4l2-compliance complains if G_PARM returns 0 in the denominator. Signed-off-by:
-
Philipp Zabel authored
v4l2-compliance complains about S_PARM being supported, but not ENUM_FRAMEINTERVALS. Report a continuous frame interval even though the hardware only supports 16-bit numerator and denominator, with min/max values that can be programmed into the mailbox registers. Signed-off-by:
-
Philipp Zabel authored
The flag is already set in coda_g_parm, but v4l2-compliance complains about it not being set during S_PARM. Signed-off-by:
-
Lucas Stach authored
The CODA driver uses threaded IRQs only, so there is nothing happening in hardirq context that could interfere with the buffer meta handling. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
The per-device instance list is unused, remove it. Signed-off-by:
-
Philipp Zabel authored
Three macroblocks seem to be the minimum resolution that can be encoded and decoded by the CODA960 h.264 codec. Picture run commands fail for smaller resolutions. Signed-off-by:
-
Lucas Stach authored
The ringbuffer used to hold the bitstream is very conservatively sized, as keyframes can get very large and still need to fit into this buffer. This means that the buffer is way oversized for the average stream to the extend that it will hold a few hundred frames when the video data is compressing well. The current strategy of queueing as much bitstream data as possible leads to large delays when draining the decoder. In order to keep the drain latency to a reasonable bound, try to only queue a full reorder window of buffers. We can't always hit this low target for very well compressible video data, as we might end up with less than the minimum amount of data that needs to be available to the bitstream prefetcher, so we must take this into account and allow more buffers to be queued in this case. Signed-off-by:
-
