- 20 Apr, 2018 40 commits
-
-
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 <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
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:
-
Sean Young authored
Since the kernel now modifies the timeout, make it possible to retrieve the current value. Signed-off-by:
-
Sean Young authored
The longer the IR timeout, the longer the rc device waits until delivering the trailing space. So, by reducing this timeout, we reduce the delay for the last scancode to be delivered. Note that the lirc daemon disables all protocols, in which case we revert back to the default value. Signed-off-by:
-
Sean Young authored
On the raspberry pi, we might have two lirc devices; one for sending and one for receiving. This change makes it much more apparent which one is which. Signed-off-by:
-
Koji Matsuoka authored
In Video Pixel/Line Pre-Clip Register, the setting value can be set in 1 line unit, but it can only be specified as a multiple of 4 by v4l_bound_align_image function(). So correct that it can be specified in 1 line unit with this patch. Signed-off-by:
Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Colin Ian King authored
Setting v with the CEC_PIN_EVENT_FL_DROPPED is incorrect, instead ev should be set with this bit. Fix this. Detected by CoverityScan, CID#1467974 ("Extra high-order bits") Fixes: 6ec1cbf6 ("media: cec: improve CEC pin event handling") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Kai-Heng Feng authored
User reports AverMedia DVD EZMaker 7 can be driven by VIDEO_GRABBER. Add the device to the id_table to make it work. BugLink: https://bugs.launchpad.net/bugs/1620762 Cc: stable@vger.kernel.org Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Suman Anna authored
The OMAP3 ISP driver manages its MMU mappings through the IOMMU-aware ARM DMA backend. The current code creates a dma_iommu_mapping and attaches this to the ISP device, but never detaches the mapping in either the probe failure paths or the driver remove path resulting in an unbalanced mapping refcount and a memory leak. Fix this properly. Reported-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Suman Anna <s-anna@ti.com> Tested-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
This file does a lot of non-trivial struff. Document it using kernel-doc markups where needed and improve the comments inside do_video_ioctl(). Reviewed-by:
-
Mauro Carvalho Chehab authored
Making the cast right for get_user/put_user is not trivial, as it needs to ensure that the types are the correct ones. Improve it by using macros. Tested with vivid with: $ sudo modprobe vivid no_error_inj=1 $ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a -s10 > 64bits && diff -U0 32bits 64bits --- 32bits 2018-04-17 11:18:29.141240772 -0300 +++ 64bits 2018-04-17 11:18:40.635282341 -0300 @@ -1 +1 @@ -v4l2-compliance SHA : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 32 bits +v4l2-compliance SHA : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 64 bits Using the latest version of v4l-utils with this patch applied: https://patchwork.linuxtv.org/patch/48746/Reviewed-by:
-
Mauro Carvalho Chehab authored
In the past, "up" were an acronym for "user pointer" and "kp" for "kernel pointer". However, since commit a1dfb4c4 ("media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both are now __user pointers. So, the usage of "kp" is really misleading there. So, rename both to just "p32" and "p64" everywhere it occurs, in order to make peace with this file's namespace. There are two exceptions to "up/kp" nomenclature: at alloc_userspace() and at do_video_ioctl(). There, a new userspace pointer were allocated, in order to store the 64 bits version of the ioctl. Those were called as "up_native", with is, IMHO, an even worse name, as "native" could mislead of being the arguments that were filled from userspace. I almost renamed it to just "p64", but, after thinking more about that, it sounded better to call it as "new_p64", as this makes clearer that this is the data structure that was allocated inside this file in order to be used to pass/retrieve data when calling the 64-bit ready file->f_op->unlocked_ioctl() function. Suggested-by:
Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by:
-
