- 04 May, 2018 16 commits
-
-
Laurent Pinchart authored
Various types of objects subclassing vsp1_entity currently store a pointer to the pipeline. Move the pointer to vsp1_entity to simplify the code and avoid storing the pipeline in more entity subclasses later. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Laurent Pinchart authored
The vsp1_drm_pipeline enabled field is set but never used. Remove it. Signed-off-by:
-
Laurent Pinchart authored
The DRM support code manages a pipeline of VSP entities, each backed by a media entity. When starting or stopping the pipeline, it starts and stops the media pipeline through the media API in order to store the pipeline pointer in every entity. The driver doesn't use the pipe pointer in media entities, neither does it rely on the other effects of the media_pipeline_start() and media_pipeline_stop() functions. Furthermore, as the media links for the DRM pipeline are never set up correctly, and as the pipeline can be modified dynamically when enabling or disabling planes, the current implementation is not correct. Remove the incorrect and unneeded code. While at it remove the outdated comment that states that entities are not started when the LIF is setup, as they now are. Signed-off-by:
-
Hugo Grostabussiat authored
Use the USBTV_TV_STD define instead of repeating ourselves. Signed-off-by:
Hugo Grostabussiat <bonstra@bonstra.fr.eu.org> Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Hugo Grostabussiat authored
Depending on the chosen standard, configure the decoder to use the appropriate color encoding standard (PAL-like, NTSC-like or SECAM). Until now, the decoder was not configured for a specific color standard, making it autodetect the color encoding. While this may sound fine, it potentially causes the wrong image tuning parameters to be applied (e.g. tuning parameters for NTSC are applied to a PAL source), and may confuse users about what the actual standard is in use. This commit explicitly configures the color standard the decoder will use, making it visually obvious if a wrong standard was chosen. Signed-off-by:
-
Hugo Grostabussiat authored
The user-supplied norm value gets overwritten by the generic .norm member from the norm_params. That way, we lose the specific norm the user may want to set. For instance, if the user specifies V4L2_STD_PAL_60, the value actually used will be V4L2_STD_525_60, which in the end will be as if the user had specified V4L2_STD_NTSC, since this is always the first bitfield we match the norm value against before configuring the hardware. The norm_params array is only there to match a norm with an output resolution. The norm value itself should not be changed. Signed-off-by:
-
Hugo Grostabussiat authored
Make use of the V4L2_STD_525_60 and V4L2_STD_625_50 defines to determine the vertical resolution to use when capturing. V4L2_STD_525_60 (resp. V4L2_STD_625_50) is the set of standards using 525 (resp. 625) lines per frame, independently of the color encoding. Signed-off-by:
-
Hugo Grostabussiat authored
Add support for the SECAM norm, using the "AVSECAM" decoder configuration sequence found in Windows driver's .INF file. For reference, the "AVSECAM" sequence in the .INF file is: 0x04,0x73,0xDC,0x72,0xA2,0x90,0x35,0x01,0x30,0x04,0x08,0x2D,0x28,0x08, 0x02,0x69,0x16,0x35,0x21,0x16,0x36 Signed-off-by:
-
Hugo Grostabussiat authored
Re-format the register {address, value} pairs so they follow the same order as the decoder configuration sequences in the Windows driver's .INF file. For instance, for PAL, the "AVPAL" sequence in the .INF file is: 0x04,0x68,0xD3,0x72,0xA2,0xB0,0x15,0x01,0x2C,0x10,0x20,0x2e,0x08,0x02, 0x02,0x59,0x16,0x35,0x17,0x16,0x36 Signed-off-by: -
Matt Ranostay authored
There are several thermal sensors that only have a low-speed bus interface but output valid video data. This patchset enables support for the AMG88xx "Grid-Eye" sensor family. Signed-off-by:
Matt Ranostay <matt.ranostay@konsulko.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> [hans.verkuil@cisco.com: split up int ret = ...->xfer(); line] Signed-off-by:
-
Matt Ranostay authored
Define the device tree bindings for the panasonic,amg88xx i2c video driver. Cc: devicetree@vger.kernel.org Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Dmitry Osipenko authored
This is Open Firmware driver, hence 'of_device.h' should be included instead of 'platform_device.h'. Right now OF headers happen to be included indirectly and this may break in the future, so let's correct the header. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Dmitry Osipenko authored
Do not handle interrupts if we haven't asked for them, potentially that could happen if HW wasn't programmed properly. Signed-off-by:
-
Dmitry Osipenko authored
Stride of U/V planes must be aligned to 16 bytes (2 macroblocks). This needs to be taken into account, otherwise it is possible to get a silent memory corruption if dmabuf size is less than the size of decoded video frame. Signed-off-by:
-
Dmitry Osipenko authored
Make all strings single line to make them grep'able and add a comment to the memory barrier. Signed-off-by:
-
Dmitry Osipenko authored
I've noticed that decoding fails sometime if size of bitstream buffer isn't aligned to 16K, probably because HW fetches data from memory in a 16K granularity and if the last chunk of data isn't aligned, HW reads garbage data beyond the dmabuf and tries to parse it. Signed-off-by:
-
- 23 Apr, 2018 8 commits
-
-
Leonard Crestez authored
It's called v4l2_fwnode_endpoint_parse, not v4l2_fwnode_parse_endpoint. Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Sakari Ailus authored
Assigning subdev flags in probe() after v4l2_i2c_subdev_init() clears the I2C flag set by that function. Fix this by using bitwise or instead. Signed-off-by:
-
Sakari Ailus authored
The driver has event support implemented but fails to set the flag enabling event support. Set the flag to enable control events. Signed-off-by:
-
Sakari Ailus authored
Check that no error happened during adding controls to the driver's control handler. Print an error message and bail out if there was one. Signed-off-by:
-
Sakari Ailus authored
Check that creating the control actually succeeded before accessing it. A failure would lead to NULL pointer reference. Fix this. Signed-off-by:
-
Sakari Ailus authored
The driver has 12 controls, not 2. Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used as a copy operation. Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
-
Bhumika Goyal authored
Make this const as it is only stored in a const field of a video_device structure. Signed-off-by:
-
- 20 Apr, 2018 16 commits
-
-
Mauro Carvalho Chehab authored
Drivers that depend on ISAPNP currently can't be built with COMPILE_TEST. However, looking at isapnp.h, there are already stubs there to allow drivers to include it even when isa PNP is not supported. So, remove such dependencies when COMPILE_TEST. Acked-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mauro Carvalho Chehab authored
All sound drivers that don't depend on PNP can be safelly build with COMPILE_TEST, as ISA provides function stubs to be used for such purposes. As a side effect, with this change, the radio-miropcm20 can now be built outside i386 with COMPILE_TEST. It should be noticed that ISAPNP currently depends on ISA. So, on drivers that depend on it, we need to add an explicit dependency on ISA, at least until another patch removes it. Acked-by:
-
Arnd Bergmann authored
There aren't much things required for it to build with COMPILE_TEST. It just needs to not compile the code that depends on arm-specific iommu implementation. Co-developed-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Laurent Pinchart authored
The omap3isp driver can't be compiled on non-ARM platforms but has no compile-time dependency on OMAP. It however requires common clock framework support, which isn't provided by all ARM platforms. Drop the OMAP dependency when COMPILE_TEST is set and add ARM and COMMON_CLK dependencies. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
-
Mauro Carvalho Chehab authored
Drivers that depend on omap-iommu.h (currently, just omap3isp) need a stub implementation in order to be built with COMPILE_TEST. Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Niklas Söderlund authored
Add the SoC specific information for Renesas r8a77970. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
-
Niklas Söderlund authored
Add the SoC specific information for Renesas r8a7796. Signed-off-by:
-
Niklas Söderlund authored
Add the SoC specific information for Renesas r8a7795 ES1.x and ES2.0. Signed-off-by:
-
Niklas Söderlund authored
The procedure to start or stop streaming using the non-MC single subdevice and the MC graph and multiple subdevices are quite different. Create a new function to abstract which method is used based on which mode the driver is running in and add logic to start the MC graph. Signed-off-by:
-
Niklas Söderlund authored
Add the ability to process media device link change requests. Link enabling is a bit complicated on Gen3, whether or not it's possible to enable a link depends on what other links already are enabled. On Gen3 the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a routing perspective these two groups are independent of each other. Each subgroup's routing is controlled by the subgroup VIN master instance (VIN0 and VIN4). There are a limited number of possible route setups available for each subgroup and the configuration of each setup is dictated by the hardware. On H3 for example there are 6 possible route setups for each subgroup to choose from. This leads to the media device link notification code being rather large since it will find the best routing configuration to try and accommodate as many links as possible. When it's not possible to enable a new link due to hardware constrains the link_notifier callback will return -EMLINK. Signed-off-by:
-
Niklas Söderlund authored
The parsing and registering CSI-2 subdevices with the v4l2 async framework is a collaborative effort shared between the VIN instances which are part of the group. When the last VIN in the group is probed it asks all other VINs to parse its share of OF and record the async subdevices it finds in the notifier belonging to the last probed VIN. Once all CSI-2 subdevices in this notifier are bound proceed to register all VIN video devices of the group and crate media device links between all CSI-2 and VIN entities according to the SoC specific routing configuration. Signed-off-by:
-
Niklas Söderlund authored
Each Gen3 SoC has a limited set of predefined routing possibilities for which CSI-2 device and channel can be routed to which VIN instance. Prepare to store this information in the struct rvin_info. Signed-off-by:
-
Niklas Söderlund authored
The rcar-vin driver needs to be part of a media controller to support Gen3. Give each VIN instance a unique name so it can be referenced from userspace. Signed-off-by:
-
Niklas Söderlund authored
In media controller mode all VIN instances needs to be part of the same media graph. There is also a need for each VIN instance to know about and in some cases be able to communicate with other VIN instances. Add an allocator framework where the first VIN instance to be probed creates a shared data structure and registers a media device. Consecutive VINs insert themself into the global group. Signed-off-by:
-
Niklas Söderlund authored
Prepare for media controller by calling a different initialization then when running in device centric mode. Add trivial configuration of the mbus and creation of the media pad for the video device entity. While we are at it clearly mark the digital device centric notifier functions with a comment. Signed-off-by:
-
Niklas Söderlund authored
The V4L2 specification clearly documents the colorspace fields as being set by drivers for capture devices. Using the values supplied by userspace thus wouldn't comply with the API. Until the API is updated to allow for userspace to set these Hans wants the fields to be set by the driver to fixed values. Signed-off-by:
-
