- 23 Apr, 2018 7 commits
-
-
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 <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
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 33 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:
-
Niklas Söderlund authored
When the driver runs in media controller mode it should not directly control the subdevice instead userspace will be responsible for configuring the pipeline. To be able to run in this mode a different set of v4l2 operations needs to be used. Add a new set of v4l2 operations to support operation without directly interacting with the source subdevice. Signed-off-by:
-
Niklas Söderlund authored
On Gen3 a media controller API needs to be used to allow userspace to configure the subdevices in the pipeline instead of directly controlling a single source subdevice, which is and will continue to be the mode of operation on Gen2. Prepare for these two modes of operation by adding a flag to struct rvin_info which will control which mode to use. Signed-off-by:
-
Niklas Söderlund authored
On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One feature of this register is that it's only present in the VIN0 and VIN4 instances. The register in VIN0 controls the routing for VIN0-3 and the register in VIN4 controls routing for VIN4-7. To be able to control routing from a media device this function is need to control runtime PM for the subgroup master (VIN0 and VIN4). The subgroup master must be switched on before the register is manipulated, once the operation is complete it's safe to switch the master off and the new routing will still be in effect. Signed-off-by:
-
Niklas Söderlund authored
Add the register needed to work with Gen3 hardware. This patch adds the logic for how to work with the Gen3 hardware. More work is required to enable the subdevice structure needed to configure capturing. Signed-off-by:
-
Niklas Söderlund authored
Bus configuration will once the driver is extended to support Gen3 contain information not specific to only the directly connected parallel subdevice. Move it to struct rvin_dev to show it's not always coupled to the parallel subdevice. Signed-off-by:
-
Niklas Söderlund authored
At stream on time the driver should not query the subdevice for which standard are used. Instead it should be cached when userspace sets the standard and used at stream on time. Signed-off-by:
-
Niklas Söderlund authored
With the recent cleanup of the format code to prepare for Gen3 it's possible to simplify the Gen2 format code path as well. Clean up the process by defining two functions to handle the set format and reset of format when the standard is changed. While at it replace the driver local struct rvin_source_fmt with a struct v4l2_rect as all it's used for is keep track of the source dimensions. Signed-off-by:
-
Niklas Söderlund authored
Part of the format alignment and checking can be shared with the Gen3 format handling. Break that part out to a separate function. Signed-off-by:
-
Niklas Söderlund authored
If the pixelformat is not supported it should not fail but be set to something that works. While we are at it move the two different checks of the pixelformat to the same statement. Signed-off-by:
-
Niklas Söderlund authored
Remove over complicated logic to calculate the value for bytesperline and sizeimage that was carried over from the soc_camera port. There is no need to find the max value of bytesperline and sizeimage from user-space as they are set to 0 before the max_t() operation. Signed-off-by:
-
Niklas Söderlund authored
There was never proper support in the VIN driver to deliver ALTERNATING field format to user-space, remove this field option. The problem is that ALTERNATING field order requires the sequence numbers of buffers returned to userspace to reflect if fields were dropped or not, something which is not possible with the VIN drivers capture logic. The VIN driver can still capture from a video source which delivers frames in ALTERNATING field order, but needs to combine them using the VIN hardware into INTERLACED field order. Before this change if a source was delivering fields using ALTERNATE the driver would default to combining them using this hardware feature. Only if the user explicitly requested ALTERNATE field order would incorrect frames be delivered. The height should not be cut in half for the format for TOP or BOTTOM fields settings. This was a mistake and it was made visible by the scaling refactoring. Correct behavior is that the user should request a frame size that fits the half height frame reflected in the field setting. If not the VIN will do its best to scale the top or bottom to the requested format and cropping and scaling do not work as expected. Signed-off-by:
-
Niklas Söderlund authored
If the field is not supported by the driver it should not try to keep the current field. Instead it should set it to a default fallback. Since trying a format should always result in the same state regardless of the current state of the device. Signed-off-by:
-
Niklas Söderlund authored
The logic to preserve the requested format width and height are too complex and come from a premature optimization for Gen3. All Gen2 SoC can scale and the Gen3 implementation will not use these functions at all so simply preserve the width and height when interacting with the subdevice much like the field is preserved simplifies the logic quite a bit. Signed-off-by:
-
Niklas Söderlund authored
In preparation of refactoring the scaling code move the code regarding scaling to to the top of the file to avoid the need to add forward declarations. No code is changed in this commit only whole functions moved inside the same file. Signed-off-by:
-
Niklas Söderlund authored
On Gen3 the max supported width and height will be different from Gen2. Move the limits to the struct rvin_info to prepare for Gen3 support. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
-
Niklas Söderlund authored
When Gen3 support is added to the driver more than model ID will be different for the different SoCs. To avoid a lot of if statements in the code create a struct rvin_info to store this information. While we are at it rename the poorly chosen enum which contains the different model IDs from chip_id to model_id. Also sort the compatible string entries and make use of of_device_get_match_data() which will always work as the driver is DT only, so there's always a valid match. Signed-off-by:
-
Niklas Söderlund authored
In preparation for Gen3 support move the subdevice initialization and clean up from rvin_v4l2_{register,unregister}() directly to the async callbacks. This simplifies the addition of Gen3 support as the rvin_v4l2_register() can be shared for both Gen2 and Gen3 while direct subdevice control are only used on Gen2. While moving this code drop a large comment which is copied from the framework documentation and fold rvin_mbus_supported() into its only caller. Also move the initialization and cleanup code to separate functions to increase readability. Signed-off-by:
-
