- 13 Dec, 2019 19 commits
-
-
Hans Verkuil authored
Remove spurious trailing 'i'. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Colin Ian King authored
Currently if the allocation of new_buf fails then a null pointer dereference occurs when assiging new_buf->vb. Avoid this by returning early on a memory allocation failure as there is not much more can be done at this point. Addresses-Coverity: ("Dereference null return") Fixes: 3e7f51bd ("media: meson: add v4l2 m2m video decoder driver") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Hans Verkuil authored
That URL is no longer valid, so either remove references to it or replace it with linuxtv.org. Rather than updating the URL I've just dropped the cx18.rst driver documentation since it was really out of date. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Daniel Gomez authored
Fix documentation fourcc names for the 12-bit packed Bayer formats. Signed-off-by:
Daniel Gomez <daniel@qtec.com> Signed-off-by:
-
Chuhong Yuan authored
This driver forgets to kill tasklet when probe fails and remove. Add the calls to fix it. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
Hans Verkuil authored
It is the vfrontporch of field 1 that is one half-line longer, not the backporch. The order of the vertical signals in an interlaced system is: Field 1: vsync vbackporch active video of field 1 vfrontporch + 0.5 Field 2: il_vsync il_vbackporch - 0.5 active video of field 2 il_vfrontporch Interlaced systems that use HALF_LINE set the il_ fields as follows: il_vfrontporch = vfrontporch il_vsync = vsync il_vbackporch = vbackporch + 1 So the total vertical blanking for field 1 is: vsync + vbackporch + vfrontporch + 0.5 and for field 2: vsync + vbackporch + 1 + vfrontporch - 0.5 == vsync + vbackporch + vfrontporch + 0.5 So each field has the same number of half-lines. Signed-off-by:
-
Vandana BN authored
Support to emulate touch devices in vivid driver. It generates touch patterns simulating single tap, double tap, triple tap, move from left to right, zoom in, zoom out, palm press simulating large area being pressed on screen, and simulating 16 different simultaneous touch points.The values generated are based on behavior of the rmi_f54 driver. Signed-off-by:
Vandana BN <bnvandana@gmail.com> Signed-off-by:
-
Chuhong Yuan authored
The driver forgets to call i2c_unregister_device in remove like what is done in probe failure. Add the missed call to fix it. Signed-off-by:
-
Forest Crossman authored
The AVerMedia CE310B is a simple composite + S-Video + stereo audio capture card, and uses only the CX23888 to perform all of these functions. I've tested both video inputs and the audio interface and confirmed that they're all working. However, there are some issues: * Sometimes when I switch inputs the video signal turns black and can't be recovered until the system is rebooted. I haven't been able to determine the cause of this behavior, nor have I found a solution to fix it or any workarounds other than rebooting. * The card sometimes seems to have trouble syncing to the video signal, and some of the VBI data appears as noise at the top of the frame, but I assume that to be a result of my very noisy RF environment and the card's unshielded input traces rather than a configuration issue. Signed-off-by:
Forest Crossman <cyrozap@gmail.com> Signed-off-by:
-
Chuhong Yuan authored
The driver misses destroying wdt_wq when remove like what is done when probe fails. Add the missed calls like what is done to job_wq to fix it. Signed-off-by:
-
Chuhong Yuan authored
The driver forgets to call destroy_workqueue when remove and probe fails. Add the missed calls to fix it. Signed-off-by:
Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by:
-
Hans Verkuil authored
This fixes a syzbot failure since actlen could be uninitialized, but it was still used. Syzbot link: https://syzkaller.appspot.com/bug?extid=6bf9606ee955b646c0e1 Reported-and-tested-by: syzbot+6bf9606ee955b646c0e1@syzkaller.appspotmail.com Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Hans Verkuil authored
Allocate gspca_dev->usb_buf with kzalloc instead of kmalloc to ensure it is property zeroed. This fixes various syzbot errors about uninitialized data. Syzbot links: https://syzkaller.appspot.com/bug?extid=32310fc2aea76898d074 https://syzkaller.appspot.com/bug?extid=99706d6390be1ac542a2 https://syzkaller.appspot.com/bug?extid=64437af5c781a7f0e08e Reported-and-tested-by: syzbot+32310fc2aea76898d074@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+99706d6390be1ac542a2@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+64437af5c781a7f0e08e@syzkaller.appspotmail.com Signed-off-by:
-
Wolfram Sang authored
v4l2_subdev_call() is unconditional, so don't mention in the docs a @cond parameter which does not exist. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Enclose multiple macro parameters in parentheses in order to make such macros safer and fix the Clang warning below: drivers/media/i2c/adv748x/adv748x-afe.c:452:12: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] ret = sdp_clrset(state, ADV748X_SDP_FRP, ADV748X_SDP_FRP_MASK, enable ? ctrl->val - 1 : 0); Fixes: 3e89586a ("media: i2c: adv748x: add adv748x driver") Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
The periodic PING command could interfere with the result of a CEC transmit, causing a lost cec_transmit_attempt_done() call. Signed-off-by:
-
Hans Verkuil authored
Currently wait_event_interruptible_timeout is called in cec_thread_func() when adap->transmitting is set. But if the adapter is unconfigured while transmitting, then adap->transmitting is set to NULL. But the hardware is still actually transmitting the message, and that's indicated by adap->transmit_in_progress and we should wait until that is finished or times out before transmitting new messages. As the original commit says: adap->transmitting is the userspace view, adap->transmit_in_progress reflects the hardware state. However, if adap->transmitting is NULL and adap->transmit_in_progress is true, then wait_event_interruptible is called (no timeout), which can get stuck indefinitely if the CEC driver is flaky and never marks the transmit-in-progress as 'done'. So test against transmit_in_progress when deciding whether to use the timeout variant or not, instead of testing against adap->transmitting. Signed-off-by:
-
Hans Verkuil authored
WARN if transmit_queue_sz is 0 but do not decrement it. The CEC adapter will become unresponsive if it goes below 0 since then it thinks there are 4 billion messages in the queue. Obviously this should not happen, but a driver bug could cause this. Signed-off-by:
-
Hans Verkuil authored
Some messages are allowed to be a broadcast message in CEC 2.0 only, and should be ignored by CEC 1.4 devices. Unfortunately, the check was wrong, causing such messages to be marked as invalid under CEC 2.0. Signed-off-by:
-
- 09 Dec, 2019 20 commits
-
-
Benoit Parrot authored
Convert ti-cal.txt to ti,cal.yaml. Add ti,cal.yaml to the MAINTAINERS file. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Benoit Parrot authored
Make sure that both enum_mbus_code() and enum_framesize() properly populate the .which parameter member, otherwise -EINVAL is return causing the subdev asynchronous registration handshake to fail. Signed-off-by:
-
Benoit Parrot authored
When start_streaming fails after the buffers have been queued we have to make sure all buffers are returned to user-space properly otherwise a v4l2 level WARN is generated. Signed-off-by:
-
Benoit Parrot authored
Currently we were using an arbitrarily small maximum resolution mostly based on available sensor capabilities. However the hardware DMA limits are much higher than the statically define maximum resolution we were using. There we rework the boundary check code to handle the maximum width and height based on the maximum line width in bytes and re-calculating the pixel width based on the given pixel format. Signed-off-by:
-
Benoit Parrot authored
Because V4L2 still uses a specific way to manage power state of devices that predates runtime PM, bridge driver should power on and off sub device explicitly. Signed-off-by:
-
Benoit Parrot authored
Add the needed control module register bit layout to support the AM654 family of devices. Signed-off-by:
-
Benoit Parrot authored
Update Device Tree bindings for the CAL driver to add AM654 support. Signed-off-by:
-
Benoit Parrot authored
Add the needed control module register bit layout to support the DRA76x family of devices. Signed-off-by:
-
Benoit Parrot authored
Update Device Tree bindings for the CAL driver to add DRA76x support. Signed-off-by:
-
Benoit Parrot authored
The current CSI2 DPHY initialization sequence although functional does not match with the documented sequence in the Technical Reference Manual. This may affect capture re-startability in stop/start situations. Signed-off-by:
-
Benoit Parrot authored
The pixel processing unit was hard coded to only handle 8 bits per pixel from input to output. We now add handling for 10, 12 and 16 bits per pixel at the source and setting the in-memory size (i.e. container size) to 16 bits for these 3 cases. Signed-off-by:
-
Benoit Parrot authored
The current method to calculate the ddr clk period is wrong. Therefore the ths_term calculation is incorrect. Also it was wrongly assumed that the ths_settle parameter was based on the control clock instead of the pixel clock. Since the DPHY can tolerate quite a bit a of variation, capture was still mostly working with the 2 tested modes when the pixel clock was close to the control clock (i.e. 96 Mhz). But it would quickly stops working when using different modes or when customers used different sensors altogether. Calculating the DDRClk period needs to take into account the pixel bit width and the number of active data lanes. Based on the latest technical reference manual these parameters should now be calculated as follows: THS_TERM: Programmed value = floor(20 ns/DDRClk period) THS_SETTLE: Programmed value = floor(105 ns/DDRClk period) + 4 Also originally 'depth' was used to represent the number of bits a pixel would use once stored in memory (i.e. the container size). To accurately calculate the THS_* parameters we need to use the actual number of bits per pixels coming in from the sensor. So we are renaming 'depth' to 'bpp' (bits per pixels) and update the format table to show the actual number of bits per pixel being received. The "container" size will be derived from the "bpp" value. Signed-off-by:
-
Benoit Parrot authored
Apply Errata i913 every time the functional clock is enabled. This should take care of suspend/resume case as well. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
-
Benoit Parrot authored
Update Device Tree bindings for the CAL driver to add support for the CSI2 PHY LDO errata workaround for pre-es2 devices. Signed-off-by:
-
Nikhil Devshatwar authored
When setting DMA for video capture from CSI channel, if the DMA size is not given, it ends up writing as much data as sent by the camera. This may lead to overwriting the buffers causing memory corruption. Observed green lines on the default framebuffer. Restrict the DMA to maximum height as specified in the S_FMT ioctl. Signed-off-by:
Nikhil Devshatwar <nikhil.nd@ti.com> Signed-off-by:
-
Benoit Parrot authored
Allow CAL to be able to export DMA buffer. Signed-off-by:
-
Benoit Parrot authored
First this patch adds a method to access the CTRL_CORE_CAMERRX_CONTROL register to use the syscon mechanism. For backward compatibility we also handle using the existing camerrx_control "reg" entry if a syscon node is not found. In addition the register bit layout for the CTRL_CORE_CAMERRX_CONTROL changes depending on the device. In order to support this we need to use a register access scheme based on data configuration instead of using static macro. In this case we make use of the regmap facility and create data set based on the various device and phy available. Signed-off-by:
-
Benoit Parrot authored
Looks like the preferred macro to define a single bit mask is BIT() and not BIT_MASK(). Signed-off-by:
-
Benoit Parrot authored
Update binding example to show proper endpoint properties and linkage. Signed-off-by:
-
Benoit Parrot authored
Update Device Tree bindings for the CAL driver to use syscon to access the phy config register instead of trying to map it directly. Signed-off-by:
-
- 08 Dec, 2019 1 commit
-
-
Linus Torvalds authored
-
