- 20 Jun, 2017 33 commits
-
-
Steve Longerbeam authored
This is a media entity subdevice driver for the i.MX Video De-Interlacing or Combining Block. So far this entity does not implement the Combining function but only motion compensated deinterlacing. Video frames are received from the CSI and are routed to the IC PRPVF entity. Signed-off-by:
Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Steve Longerbeam authored
This is a media entity subdevice for the i.MX Camera Sensor Interface module. - Added support for negotiation of frame intervals. - Fixed cropping rectangle negotiation at input and output pads. - Added support for /2 downscaling, if the output pad dimension(s) are 1/2 the crop dimension(s) at csi_setup() time. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> [hans.verkuil@cisco.com: add linux/pinctrl/consumer.h include] Signed-off-by:
-
Steve Longerbeam authored
This is the capture device interface driver that provides the v4l2 user interface. Frames can be received from various sources: - directly from CSI for capturing unconverted images directly from camera sensors. - from the IC pre-process encode task. - from the IC pre-process viewfinder task. Signed-off-by:
-
Steve Longerbeam authored
Add a TODO file. Signed-off-by:
-
Steve Longerbeam authored
Add the core media driver for i.MX SOC. Switch from the v4l2_of_ APIs to the v4l2_fwnode_ APIs. Add the bayer formats to imx-media's list of supported pixel and bus formats. Signed-off-by:
-
Steve Longerbeam authored
This adds a header file for use by userspace programs wanting to interact with the i.MX media driver. It defines custom events and v4l2 controls for the i.MX v4l2 subdevices. Signed-off-by:
-
Steve Longerbeam authored
Add bindings documentation for the i.MX media driver. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Steve Longerbeam authored
Add maintainer entry for the OV5640 V4L2 sensor driver. Signed-off-by:
-
Steve Longerbeam authored
This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta branch, modified heavily to bring forward to latest interfaces and code cleanup. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Steve Longerbeam authored
Add device tree binding documentation for the OV5640 camera sensor. Signed-off-by:
-
Philipp Zabel authored
Add maintainer entry for the video multiplexer v4l2 subdevice driver that will control video bus multiplexers via the multiplexer framework. Signed-off-by:
-
Philipp Zabel authored
This driver can handle SoC internal and external video bus multiplexers, controlled by mux controllers provided by the mux controller framework, such as MMIO register bitfields or GPIOs. The subdevice passes through the mbus configuration of the active input to the output side. Since the mux framework is not yet merged, this driver contains temporary mmio-mux support to work without the framework. The driver should be converted to use the multiplexer API once the "mux: minimal mux subsystem" and "mux: mmio-based syscon mux controller" patches are merged. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Pavel Machek <pavel@ucw.cz> [hans.verkuil@cisco.com: add 'select REGMAP' to Kconfig] Signed-off-by:
-
Philipp Zabel authored
Add two new media entity function definitions for video multiplexers and video interface bridges. - renamed MEDIA_ENT_F_MUX to MEDIA_ENT_F_VID_MUX Signed-off-by:
-
Philipp Zabel authored
Add bindings documentation for the video multiplexer device. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.co.uk> Acked-by:
-
Mauro Carvalho Chehab authored
load is an unsigned integer. So, it is always bigger or equal to zero, as reported by gcc: drivers/media/i2c/max2175.c: In function 'max2175_refout_load_to_bits': drivers/media/i2c/max2175.c:1272:11: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] if (load >= 0 && load <= 40) ^~ Signed-off-by: -
Ramesh Shanmugasundaram authored
Add maintainter entry for the R-Car DRIF and MAX2175 drivers. Signed-off-by:
Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com> Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Ramesh Shanmugasundaram authored
This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs. The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF device represents a channel and each channel can have one or two sub-channels respectively depending on the target board. DRIF supports only Rx functionality. It receives samples from a RF frontend tuner chip it is interfaced with. The combination of DRIF and the tuner device, which is registered as a sub-device, determines the receive sample rate and format. In order to be compliant as a V4L2 SDR device, DRIF needs to bind with the tuner device, which can be provided by a third party vendor. DRIF acts as a slave device and the tuner device acts as a master transmitting the samples. The driver allows asynchronous binding of a tuner device that is registered as a v4l2 sub-device. The driver can learn about the tuner it is interfaced with based on port endpoint properties of the device in device tree. The V4L2 SDR device inherits the controls exposed by the tuner device. The device can also be configured to use either one or both of the data pins at runtime based on the master (tuner) configuration. Signed-off-by:
-
Ramesh Shanmugasundaram authored
Add binding documentation for Renesas R-Car Digital Radio Interface (DRIF) controller. Signed-off-by:
-
Ramesh Shanmugasundaram authored
This patch adds documentation for the three new SDR formats V4L2_SDR_FMT_PCU16BE V4L2_SDR_FMT_PCU18BE V4L2_SDR_FMT_PCU20BE Signed-off-by:
-
Ramesh Shanmugasundaram authored
This patch adds support for the three new SDR formats. These formats were prefixed with "planar" indicating I & Q data are not interleaved as in other formats. Here, I & Q data constitutes the top half and bottom half of the received buffer respectively. V4L2_SDR_FMT_PCU16BE - 14-bit complex (I & Q) unsigned big-endian sample inside 16-bit. V4L2 FourCC: PC16 V4L2_SDR_FMT_PCU18BE - 16-bit complex (I & Q) unsigned big-endian sample inside 18-bit. V4L2 FourCC: PC18 V4L2_SDR_FMT_PCU20BE - 18-bit complex (I & Q) unsigned big-endian sample inside 20-bit. V4L2 FourCC: PC20 Signed-off-by:
-
Ramesh Shanmugasundaram authored
This patch adds driver support for the MAX2175 chip. This is Maxim Integrated's RF to Bits tuner front end chip designed for software-defined radio solutions. This driver exposes the tuner as a sub-device instance with standard and custom controls to configure the device. Signed-off-by:
-
Ramesh Shanmugasundaram authored
Add device tree binding documentation for MAX2175 RF to bits tuner device. Signed-off-by:
-
Ramesh Shanmugasundaram authored
Reserve controls for MAX217X RF to Bits tuner family. These hybrid radio receiver chips are highly programmable and hence reserving 32 controls. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
Now that there is a cec.txt with common CEC bindings, update the two driver-specific bindings to refer to cec.txt. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by:
-
Hans Verkuil authored
Document common HDMI CEC bindings. Add this to the MAINTAINERS file as well. Signed-off-by:
-
Hans Verkuil authored
Use the needs-hpd DT property to determine if the CEC_CAP_NEEDS_HPD should be set. Signed-off-by:
-
Hans Verkuil authored
Needed for boards that wire the CEC pin in such a way that it is unavailable when the HPD is low. Signed-off-by:
-
Hans Verkuil authored
Document the new CEC_CAP_NEEDS_HPD capability. Signed-off-by:
-
Hans Verkuil authored
Add a new capability CEC_CAP_NEEDS_HPD. If this capability is set then the hardware can only use CEC if the HDMI Hotplug Detect pin is high. Such hardware cannot handle the corner case in the CEC specification where it is possible to transmit messages even if no hotplug signal is present (needed for some displays that turn off the HPD when in standby, but still have CEC enabled). Typically hardware that needs this capability have the HPD wired to the CEC block, often to a 'power' or 'active' pin. Signed-off-by:
-
Hans Verkuil authored
Use the helper function cec_transmit_attempt_done instead of cec_transmit_done to simplify the code. Signed-off-by:
-
Hans Verkuil authored
A simpler variant of cec_transmit_done to be used where the HW does just a single attempt at a transmit. So if the status indicates an error, then the corresponding error count will always be 1 and this function figures that out based on the status argument. Signed-off-by:
-
Hans Verkuil authored
Simplifies setting the physical address to CEC_PHYS_ADDR_INVALID. Signed-off-by:
-
Hans Verkuil authored
This function simplifies the integration of CEC in DRM drivers. Signed-off-by:
-
- 13 Jun, 2017 7 commits
-
-
Gustavo A. R. Silva authored
Fix the position of arguments so camif->colorfx_cb, camif->colorfx_cr are passed in proper order to the camif_hw_set_effect() function. Addresses-Coverity-ID: 1248800 Addresses-Coverity-ID: 1269141 [s.nawrocki@samsung.com: edited commit message ] Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
-
Nicholas Mc Guire authored
As this is not in atomic context and it does not seem like a critical timing setting a range of 1ms allows the timer subsystem to optimize the hrtimer here. Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Acked-by:
-
Thibault Saunier authored
Use colorspace provided by the user as we are only doing scaling and color encoding conversion, we won't be able to transform the colorspace itself and the colorspace won't mater in that operation. Also always use output colorspace on the capture side. If the user does not provide a colorspace do not make it up, we might later while processing need to figure out the colorspace, which is possible depending on the frame size but do not ever guess and leak that guess to the userspace. Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Thibault Saunier <thibault.saunier@osg.samsung.com> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Benjamin Gaignard authored
Usage of devm_of_platform_populate() simplify driver code and save somes lines Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in mfc_err error messages Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Alexandre Courbot authored
v4l2_m2m_job_finish(), which is called from the interrupt handler with slock acquired, can call the device_run() hook immediately if another context was in the queue. This hook also acquires slock, resulting in a deadlock for this scenario. Fix this by releasing slock right before calling v4l2_m2m_job_finish(). This is safe to do as the state of the hardware cannot change before v4l2_m2m_job_finish() is called anyway. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Acked-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by:
-
David Härdeman authored
Now that rc_register_device() is reorganised, the dev->initialized hack can be removed. Any driver which calls rc_register_device() must be prepared for the device to go live immediately. The dev->initialized commits that are relevant are commit c73bbaa4 ("[media] rc-core: don't lock device at rc_register_device()") and commit 08aeb7c9 ("[media] rc: add locking to fix register/show race"). The original problem was that show_protocols() would access dev->rc_map.* and various other bits which are now properly initialized before device_add() is called. At the same time, remove the bogus "device is being removed" check. Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
