- 03 Jan, 2020 6 commits
-
-
Arnd Bergmann authored
The v4l2_buffer structure contains a 'struct timeval' member that is defined by the user space C library, creating an ABI incompatibility when that gets updated to a 64-bit time_t. As in v4l2_event, handle this with a special case in video_put_user() and video_get_user() to replace the memcpy there. Since the structure also contains a pointer, there are now two native versions (on 32-bit systems) as well as two compat versions (on 64-bit systems), which unfortunately complicates the compat handler quite a bit. Duplicating the existing handlers for the new types is a safe conversion for now, but unfortunately this may turn into a maintenance burden later. A larger-scale rework of the compat code might be a better alternative, but is out of scope of the y2038 work. Sparc64 needs a special case because of their special suseconds_t definition. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Arnd Bergmann authored
The v4l2_event structure contains a 'struct timespec' member that is defined by the user space C library, creating an ABI incompatibility when that gets updated to a 64-bit time_t. While passing a 32-bit time_t here would be sufficient for CLOCK_MONOTONIC timestamps, simply redefining the structure to use the kernel's __kernel_old_timespec would not work for any library that uses a copy of the linux/videodev2.h header file rather than including the copy from the latest kernel headers. This means the kernel has to be changed to handle both versions of the structure layout on a 32-bit architecture. The easiest way to do this is during the copy from/to user space. Signed-off-by:
-
Arnd Bergmann authored
The copy-in/out portions of video_usercopy() are about to get more complex, so turn then into separate functions as a cleanup first. Signed-off-by:
-
Arnd Bergmann authored
The do_video_ioctl() compat handler converts the compat command codes into the native ones before processing further, but this causes problems for 32-bit user applications that pass a command code that matches a 64-bit native number, which will then be handled the same way. Specifically, this breaks VIDIOC_DQEVENT_TIME from user space applications with 64-bit time_t, as the structure layout is the same as the native 64-bit layout on many architectures (x86 being the notable exception). Change the handler to use the converted command code only for passing into the native ioctl handler, not for deciding on the conversion, in order to make the compat behavior match the native behavior. Actual support for the 64-bit time_t version of VIDIOC_DQEVENT_TIME and other commands still needs to be added in a separate patch. Cc: stable@vger.kernel.org Signed-off-by:
-
Arnd Bergmann authored
As a preparation for adding 64-bit time_t support in the uapi, change the drivers to no longer care about the format of the timestamp field in struct v4l2_buffer. The v4l2_timeval_to_ns() function is no longer needed in the kernel after this, but there is userspace code relying on it to be part of the uapi header. Signed-off-by:
-
Arnd Bergmann authored
The type for the timestamp in video_event was changed to 'long' a long time ago, change the documentation to match. Signed-off-by:
-
- 16 Dec, 2019 34 commits
-
-
Hans Verkuil authored
The v4l2-compliance tests failed with the touch device when multiplanar was enabled in vivid. Since it is perfectly fine to support the multiplanar API for touch, add support for this in vivid. Signed-off-by:
-
Hans Verkuil authored
There is no reason to prohibit multiplanar support for touch devices, so just allow it. Signed-off-by:
-
Hans Verkuil authored
The v4l2_buffer's 'field' value was never initialized in vivid for the touch capture device, causing v4l2-compliance errors. Set it to NONE. Signed-off-by:
-
Hans Verkuil authored
Log (if debug > 0) when a CEC message is received. This is done for transmits already, so it makes sense to do the same for receives. Signed-off-by:
-
Hans Verkuil authored
Don't schedule the next ping before the current ping is sent, schedule it after. Signed-off-by:
-
Hans Verkuil authored
Don't free everything in the disconnect callback, instead use the adap_free callback, which is called when the last open filehandle is closed. Signed-off-by:
-
Hans Verkuil authored
It turns out that received CEC messages can arrive faster than can be processed by the CEC framework, resulting in lost messages. Instead of storing only one CEC message, store up to 8. Also fix a bug where the EOM bit wasn't checked for a received message of length 1, so POLL messages weren't properly reported. Signed-off-by:
-
Hans Verkuil authored
Instead of adap_transmit waiting until the full message is transmitted (and thus hoarding the adap->lock mutex), have it kick off a transmit workqueue. This prevents adap->lock from being locked for a very long time. Also skip FAILED_ACK reports for broadcast messages: this makes no sense, and it seems a spurious message coming from the Pulse-Eight, since some time later I see the SUCCEEDED message. Signed-off-by:
-
Hans Verkuil authored
Instead of translating work_result to a transmit_done status in pulse8_irq_work_handler(), pass the CEC_TX_STATUS via a new tx_done_status field. Signed-off-by:
-
Hans Verkuil authored
Use debug level 2 to show the low-level Pulse-Eight commands. Also show the message to transmit on debug level 1 and add a debug log to show where the transmit failed. Signed-off-by:
-
Hans Verkuil authored
Drop the write_lock, rename config_lock to plain lock since this now locks access to the adapter. Use 'lock' when transmitting a message, ensuring that nothing interferes with the transmit. Signed-off-by:
-
Hans Verkuil authored
Reorganize the order of the functions in the source, going from low-level to high-level. No functional changes were made. Signed-off-by:
-
Hans Verkuil authored
Add and use pulse8_msgname() to show the message codes as a human readable text instead of a number. Signed-off-by:
-
Nathan Chancellor authored
When building with Clang + -Wtautological-constant-compare, several of the ivtv and cx18 drivers warn along the lines of: drivers/media/pci/cx18/cx18-driver.c:1005:21: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL, ^ drivers/media/pci/cx18/cx18-cards.h:18:37: note: expanded from macro 'CX18_HW_GPIO_RESET_CTRL' #define CX18_HW_GPIO_RESET_CTRL (1 << 6) ^ 1 warning generated. This warning happens because the shift operation is implicitly converted to a boolean in v4l2_device_mask_call_all before being negated. This can be solved by just comparing the mask result to 0 explicitly so that there is no boolean conversion. The ultimate goal is to enable -Wtautological-compare globally because there are several subwarnings that would be helpful to have. For visual consistency and avoidance of these warnings in the future, all of the implicitly boolean conversions in the v4l2_device macros are converted to explicit ones as well. Link: https://github.com/ClangBuiltLinux/linux/issues/752Reviewed-by:Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Ezequiel Garcia authored
The Hantro G1 decoder is able to enable a post-processor on the decoding pipeline, which can be used to perform scaling and color conversion. The post-processor is integrated to the decoder, and it's possible to use it in a way that is completely transparent to the user. This commit enables color conversion via post-processing, which means the driver now exposes YUV packed, in addition to NV12. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
hantro_prepare_run() and hantro_finish_run() are slightly misleading, so let's rename it to something a bit more clear. Signed-off-by:
-
Ezequiel Garcia authored
Format negotiation helpers, hantro_find_format() and hantro_get_default_fmt() can be simplified, making the code a little bit clearer. More importantly, this change is preparation work for the post-processor usage. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
-
Ezequiel Garcia authored
It has been decided to use the ENUM_FMT index value as a hint for driver preference. This is defined purposedly in a very liberal way, letting drivers define what "preference" means. For instance, the Hantro VPU driver indicates additional processing to output a given format, and thus implicates more CPU usage, which is enumerated after native (non-processed) formats. Signed-off-by:
-
Dragos Bogdan authored
The AD7611 chip supports the same Deep Color Mode settings as the AD7604. This change extends support for this feature to the AD7611 by adding a wrapper function for the `read_hdmi_pixelclock` hook and adding the same frequency adjustment logic. Signed-off-by:
Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
-
Guilherme Alcarde Gallo authored
Add support for the sink pad of scaler subdevice to respond VIDIOC_G_SELECTION and VIDIOC_S_SELECTION ioctls with the following targets: V4L2_SEL_TGT_COMPOSE_BOUNDS and V4L2_SEL_TGT_CROP. * Add new const struct crop_rect_default to initialize subdev scaler properly. * Make changes in sink pad format reflect to the crop rectangle. E.g. changing the frame format to a smaller size one can make the former crop rectangle selects a non existing frame area. To solve this situation the crop rectangle is clamped to the frame boundaries. * Clamp crop rectangle respecting the sink bounds during set_selection ioctl. Co-developed-by:
Danilo Figueiredo Rocha <drocha.figueiredo@gmail.com> Signed-off-by:
Guilherme Alcarde Gallo <gagallo7@gmail.com> Signed-off-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
Hans Verkuil authored
Testing with the rmi_f54 driver on the Lenovo X1 Carbon 6th gen laptop showed that the data is in little endian format. Update the documentation accordingly. Signed-off-by:
-
Rui Miguel Silva authored
It was defined a notifier in the csi_state structure that is never allocated. And besides that it's unregister in the remove, even though it is a no-op, just remove both. Fixes: 7807063b ("media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Suggested-by:
Rui Miguel Silva <rui.silva@linaro.org> Reviewed-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
-
Wei Yongjun authored
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Hirokazu Honda authored
MediaTek encoder allocates non pixel data area for an input buffer every plane. As the input buffer should be read-only, the driver should not write anything in the buffer. Therefore, the extra data should be unnecessary. Signed-off-by:
Hirokazu Honda <hiroh@chromium.org> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Niklas Söderlund authored
When adding the compatibility string for R8A77470 (RZ/G1C) to the rcar-vin driver the string was never documented in the bindings, add it now. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Niklas Söderlund authored
It might be convenient to have aliases but it's not required, drop the sentence as it's not true and not used in Gen3 DTS files. Signed-off-by:
-
Eugen Hristev authored
When requesting format from sensor, some sensors call the subdev_get_try_crop which for ISI was not properly initialized, and this causes errors in determining proper image resolutions. To accommodate for this, when trying a format (in try_fmt), first attempt to obtain the framesize for this format from sensor. In case this fails, use the maximum ISI width/height as try_crop, otherwise provide the first size height/width from the sensor. Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
-
Eugen Hristev authored
In try_fmt, properly initialize the pad_cfg variable to zeros. This can be used by various calls from the subdev, so it's better to have it initialized. Signed-off-by:
-
Eugen Hristev authored
This adds support for GREY and Y16 formats, based on Y10 mbus codes. Y16 needs to go through preview path in the ISI, with 2 pixels per word, and it fits the Y16 format. The ISI data lines need to be MSB aligned with the sensor data lines. GREY format in 8 bits per pixel is done by dropping the 2 LSB bits from the Y10 format, and packed as 4 pixels per word. Suggested-by:
Wenyou Yang <wenyou.yang@microchip.com> Signed-off-by:
-
Eugen Hristev authored
When requesting format from sensor, some sensors call the subdev_get_try_crop which for ISC was not properly initialized, and this causes errors in determining proper image resolutions. To accommodate for this, when trying a format (in try_fmt), first attempt to obtain the framesize for this format from sensor. In case this fails, use the maximum ISC width/height as try_crop, otherwise provide the first size height/width from the sensor. Signed-off-by:
-
Eugen Hristev authored
With some sensors, the mbus code must match the one that sensor supports. In this case we should initialize the mbus_code of the fse/fie before calling the subdev, and not after. Signed-off-by:
-
Eugen Hristev authored
In try_fmt, properly initialize the pad_cfg variable to zeros. This can be used by various calls from the subdev, so it's better to have it initialized. Signed-off-by:
-
Eugen Hristev authored
The ISC can receive input from sensors using Y10 format directly (10 bits greyscale). In this case, the ISC must dump the data directly, either as GREY (8bit) or Y10 (10bit). Y16 is not supported because we cannot align the MSB 10 bits to the MSB inside the 16bit container. For this format, the ISC internal pipeline cannot work (only works with BAYER), so we must dump the data directly as 8bit/10bit. Signed-off-by:
-
Eugen Hristev authored
In case the format that the sensor sends is 8 bit only (like GREY for example) we need to be able to bypass ISC pipeline and directly dump 8 bits. That's why the hardcoded value of 16 bpp is not correct in all cases. This change allows the output format to decide what is the correct bpp (bits per pixel) such that the result is in the proper format. Signed-off-by:
-
