- 20 Apr, 2018 40 commits
-
-
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 <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
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: -
Niklas Söderlund authored
If the video device was registered by the complete() callback it should be unregistered when a device is unbound from the driver. Protect from printing an uninitialized video device node name by adding a check in rvin_v4l2_unregister() to identify that the video device is registered. Signed-off-by:
-
Niklas Söderlund authored
The functions to register and unregister the hardware and video device where poorly named from the start. Rename them to better describe their intended function. Signed-off-by:
-
Niklas Söderlund authored
Document the devicetree bindings for the CSI-2 inputs available on Gen3. There is a need to add a custom property 'renesas,id' and to define which CSI-2 input is described in which endpoint under the port@1 node. This information is needed since there are a set of predefined routes between each VIN and CSI-2 block. This routing table will be kept inside the driver but in order for it to act on it it must know which VIN and CSI-2 is which. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Fabrizio Castro authored
Add compatible strings for r8a7743 and r8a7745. No driver change is needed as "renesas,rcar-gen2-vin" will activate the right code. However, it is good practice to document compatible strings for the specific SoC as this allows SoC specific changes to the driver if needed, in addition to document SoC support and therefore allow checkpatch.pl to validate compatible string values. Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Biju Das <biju.das@bp.renesas.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
Fabrizio Castro authored
Change the sorting of the part numbers from descending to ascending to match with other documentation. Signed-off-by:
-
Ryder Lee authored
The usage of of_device_get_match_data() reduce the code size a bit. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Acked-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Andi Shyti authored
Because I will be leaving Samsung soon, update my e-mail to the etezian.org mail. Cc: Andi Shyti <andi@etezian.org> Signed-off-by:
Andi Shyti <andi.shyti@samsung.com> Signed-off-by:
-
Sean Young authored
The HVR 1300 has a Z8F0811 IR device, which can do both IR transmit and receive. The transmit part was not probed. Signed-off-by:
-
Sean Young authored
mceusb devices have a default timeout of 100ms, but this can be changed. Signed-off-by:
-
Sean Young authored
The last usb packet with IR data will end with 0x80 (MCE_IRDATA_TRAILER). If we reset the decoder state at this point, IR decoding can fail. Signed-off-by:
-
Sean Young authored
The MCE keyboard sends both key down and key up events. We have a timeout handler mce_kbd_rx_timeout() in case the keyup event is never received; however, this may race with new key down events from occurring. The race is that key down scancode arrives and key down events are generated. The timeout handler races this and generates key up events straight afterwards. Since the keyboard generates scancodes every 100ms, most likely the keys will be repeated 100ms later, and now we have new key down events and the user sees duplicate key presses. Reported-by:
Matthias Reichl <hias@horus.com> Signed-off-by:
-
Sean Young authored
There is nothing to sync in this code path. Reported-by:
-
Sean Young authored
The MCE Remote sends a 0 scancode when keys are released. If this is not received or decoded, then keys can get "stuck"; the keyup event is not sent since the input_sync() is missing from the timeout handler. Cc: stable@vger.kernel.org Signed-off-by:
-
Sean Young authored
If two keys are pressed, then both keys are encoded in the scancode. This makes the mce keyboard more responsive. Signed-off-by:
-
Sean Young authored
The mce keyboard repeats pressed keys every 100ms. If the IR timeout is set to less than that, we send key up events before the repeat arrives, so we have key up/key down for each IR repeat. The keyboard ends any sequence with a 0 scancode, in which case all keys are cleared so there is no need to run the timeout timer: it only exists for the case that the final 0 was not received. Signed-off-by:
-
Sean Young authored
Each IR protocol has its own repeat period. We can minimise the keyup timer to be the protocol period + IR timeout. This makes keys less "sticky" and makes IR more reactive and nicer to use. This feature was previously attempted in commit d57ea877 ("media: rc: per-protocol repeat period"), but that did not take the IR timeout into account, and had to be reverted. Signed-off-by:
-
