media: s5p-jpeg: don't return a value on a void function
Building this driver on arm64 gives this warning:
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:430:16: error: return expression in void function
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
media: siano: be sure to not override devpath size
Right now, at siano driver, all places where devpath is
defined has sizeof(devpath) == 32. So, there's no practical
risc of going past devpath array anywhere.
Still, code changes might cause troubles. It also confuses
Coverity:
CID 139059 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
9. fixed_size_dest: You might overrun the 32-character
fixed-size string entry->devpath by copying devpath
without checking the length.
10. parameter_as_source: Note: This defect has an
elevated risk because the source argument
is a parameter of the current function.
So, explicitly limit strcmp() and strcpy() to ensure that the
devpath size (32) will be respected.
Anders Roxell [Fri, 20 Apr 2018 11:25:51 +0000 (13:25 +0200)]
drivers: omap2: Kconfig: make FB_OMAP2_DSS_INIT depend on OF
Commit 7378f1149884 ("media: omap2: omapfb: allow building it with
COMPILE_TEST") broke compilation without CONFIG_OF selected.
CC drivers/video/fbdev/core/fbmem.o
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c: In function ‘omapdss_update_prop’:
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c:68:2: error: implicit declaration of function ‘of_update_property’; did you mean ‘of_get_property’? [-Werror=implicit-function-declaration]
of_update_property(node, prop);
^~~~~~~~~~~~~~~~~~
of_get_property
cc1: some warnings being treated as errors
scripts/Makefile.build:312: recipe for target 'drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.o' failed
make[7]: *** [drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.o] Error 1
scripts/Makefile.build:559: recipe for target 'drivers/video/fbdev/omap2/omapfb/dss' failed
make[6]: *** [drivers/video/fbdev/omap2/omapfb/dss] Error 2
make[6]: *** Waiting for unfinished jobs....
Add OF dependency in order to make all configurations work again.
of_update_property() has no inline stub, and that that could be added as
an alternative.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Sean Young [Thu, 3 May 2018 10:38:40 +0000 (06:38 -0400)]
media: rc: probe zilog transmitter when zilog receiver is found
Both Hauppauge WinTV 44981 (bt878) and the HVR 1110 (saa7134) have a Zilog
Z8F0811. The transmitter was not probed. Receive and transmit tested on
both cards.
Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Sean Young [Sun, 12 Nov 2017 21:34:59 +0000 (16:34 -0500)]
media: rc: only register protocol for rc device if enabled
The raw_register function exists to create input devices associated with
that IR protocol.
If the mce_kbd module is loaded, then every rc device will have mce_kbd
input devices, even if the protocol is not enabled. Change this to call
the register function to when the protocol is enabled.
Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Laurent Pinchart [Mon, 26 Feb 2018 16:06:21 +0000 (11:06 -0500)]
media: v4l: vsp1: Rename BRU to BRx
Some VSP instances have two blending units named BRU (Blend/ROP Unit)
and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU
with only two inputs, but otherwise offers similar features and offers
the same register interface. The BRU and BRS can be used exchangeably in
VSP pipelines (provided no more than two inputs are needed).
Due to historical reasons, the VSP1 driver implements support for both
the BRU and BRS through objects named vsp1_bru. The code uses the name
BRU to refer to either the BRU or the BRS, except in a few places where
noted explicitly. This creates confusion.
In an effort to avoid confusion, rename the vsp1_bru object and the
corresponding API to vsp1_brx, and use BRx to refer to blend unit
instances regardless of their type. The names BRU and BRS are retained
where reference to a particular blend unit type is needed, as well as in
hardware registers to stay close to the datasheet.
Dynamic assignment of the BRU and BRS to pipelines is prone to
regressions, add messages to make debugging easier. Keep it as a
separate commit to ease removal of those messages once the code will
deem to be completely stable.
Laurent Pinchart [Thu, 22 Feb 2018 19:26:21 +0000 (14:26 -0500)]
media: v4l: vsp1: Assign BRU and BRS to pipelines dynamically
The VSPDL variant drives two DU channels through two LIF and two
blenders, BRU and BRS. The DU channels thus share the five available
VSPDL inputs and expose them as five KMS planes.
The current implementation assigns the BRS to the second LIF and thus
artificially limits the number of planes for the second display channel
to two at most.
Lift this artificial limitation by assigning the BRU and BRS to the
display pipelines on demand based on the number of planes used by each
pipeline. When a display pipeline needs more than two inputs and the BRU
is already in use by the other pipeline, this requires reconfiguring the
other pipeline to free the BRU before processing, which can result in
frame drop on both pipelines.
Laurent Pinchart [Mon, 26 Feb 2018 09:22:40 +0000 (04:22 -0500)]
media: v4l: vsp1: Generalize detection of entity removal from DRM pipeline
When disabling a DRM plane, the corresponding RPF is only marked as
removed from the pipeline in the atomic update handler, with the actual
removal happening when configuring the pipeline at atomic commit time.
This is required as the RPF has to be disabled in the hardware, which
can't be done from the atomic update handler.
The current implementation is RPF-specific. Make it independent of the
entity type by using the entity's pipe pointer to mark removal from the
pipeline. This will allow using the mechanism to remove BRU instances.
Laurent Pinchart [Thu, 22 Feb 2018 19:26:21 +0000 (14:26 -0500)]
media: v4l: vsp1: Add per-display list internal completion notification support
Display list completion is already reported to the frame end handler,
but that mechanism is global to all display lists. In order to implement
BRU and BRS reassignment in DRM pipelines we will need to commit a
display list and wait for its completion internally, without reporting
it to the DRM driver. Extend the display list API to support such an
internal use of the display list.
media: v4l: vsp1: Turn frame end completion status into a bitfield
We will soon need to return more than a boolean completion status from
the vsp1_dlm_irq_frame_end() IRQ handler. Turn the return value into a
bitfield to prepare for that. No functional change is introduced here.
Laurent Pinchart [Thu, 22 Feb 2018 19:26:21 +0000 (14:26 -0500)]
media: v4l: vsp1: Move DRM pipeline output setup code to a function
In order to make the vsp1_du_setup_lif() easier to read, and for
symmetry with the DRM pipeline input setup, move the pipeline output
setup code to a separate function.
The vsp1_du_setup_lif() function sets up the DRM pipeline input
manually. This duplicates the code from the
vsp1_du_pipeline_setup_inputs() function. Replace the manual
implementation by a call to the function.
As the pipeline has no enabled input in vsp1_du_setup_lif(), the
vsp1_du_pipeline_setup_inputs() function will not setup any RPF, and
will thus not setup formats on the BRU sink pads. This isn't a problem
as all inputs are disabled, and the BRU sink pads will be reconfigured
from the atomic commit handler when inputs will be enabled.
Laurent Pinchart [Thu, 22 Feb 2018 19:26:21 +0000 (14:26 -0500)]
media: v4l: vsp1: Setup BRU at atomic commit time
To implement fully dynamic plane assignment to pipelines, we need to
reassign the BRU and BRS to the DRM pipelines in the atomic commit
handler. In preparation for this setup factor out the BRU source pad
code and call it both at LIF setup and atomic commit time.
Laurent Pinchart [Fri, 23 Feb 2018 20:35:00 +0000 (15:35 -0500)]
media: v4l: vsp1: Move DRM atomic commit pipeline setup to separate function
The DRM pipeline setup code used at atomic commit time is similar to the
setup code used when enabling the pipeline. Move it to a separate
function in order to share it.
Laurent Pinchart [Thu, 22 Feb 2018 22:27:47 +0000 (17:27 -0500)]
media: v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a pipeline
The DRM pipeline handling code uses the entity's pipe list head to check
whether the entity is already included in a pipeline. This method is a
bit fragile in the sense that it uses list_empty() on a list_head that
is a list member. Replace it by a simpler check for the entity pipe
pointer.
Laurent Pinchart [Thu, 22 Feb 2018 22:22:43 +0000 (17:22 -0500)]
media: v4l: vsp1: Store pipeline pointer in vsp1_entity
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.
Laurent Pinchart [Thu, 22 Feb 2018 17:12:36 +0000 (12:12 -0500)]
media: v4l: vsp1: Don't start/stop media pipeline for DRM
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.
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 <bonstra@bonstra.fr.eu.org> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
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 <bonstra@bonstra.fr.eu.org> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
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 <bonstra@bonstra.fr.eu.org> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
media: usbtv: Use same decoder sequence as Windows driver
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: Hugo Grostabussiat <bonstra@bonstra.fr.eu.org> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Matt Ranostay [Fri, 6 Apr 2018 22:52:31 +0000 (18:52 -0400)]
media: video-i2c: add video-i2c driver
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: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Dmitry Osipenko [Sat, 17 Mar 2018 15:28:15 +0000 (11:28 -0400)]
media: staging: tegra-vde: Correct included header
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.
Dmitry Osipenko [Sat, 17 Mar 2018 15:28:13 +0000 (11:28 -0400)]
media: staging: tegra-vde: Correct minimum size of U/V planes
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.
Dmitry Osipenko [Sat, 17 Mar 2018 15:28:11 +0000 (11:28 -0400)]
media: staging: tegra-vde: Align bitstream size to 16K
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.
media: sound, isapnp: allow building more drivers with COMPILE_TEST
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.
media: sound, media: allow building ISA drivers it with COMPILE_TEST
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.
media: omap3isp: Allow it to build with COMPILE_TEST
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.
media: omap3isp: Enable driver compilation on ARM with COMPILE_TEST
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: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
media: rcar-vin: extend {start, stop}_streaming to work with media controller
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.
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.
media: rcar-vin: parse Gen3 OF and setup media graph
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.
media: rcar-vin: add chsel information to rvin_info
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.
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.
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.
media: rcar-vin: prepare for media controller mode initialization
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.
media: rcar-vin: force default colorspace for media centric mode
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.
media: rcar-vin: use different v4l2 operations in media controller mode
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.
media: rcar-vin: add flag to switch to media controller mode
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.
media: rcar-vin: add function to manipulate Gen3 chsel value
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.
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.
media: rcar-vin: move media bus configuration to struct rvin_dev
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.
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.
media: rcar-vin: simplify how formats are set and reset
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.
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.
media: rcar-vin: update bytesperline and sizeimage calculation
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.
media: rcar-vin: fix handling of single field frames (top, bottom and alternate fields)
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.
media: rcar-vin: set a default field to fallback on
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.
media: rcar-vin: all Gen2 boards can scale simplify logic
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.
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.
media: rcar-vin: move model information to own struct
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.
media: rcar-vin: move subdevice handling to async callbacks
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.
media: rcar-vin: unregister video device on driver removal
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.
media: rcar-vin: rename poorly named initialize and cleanup functions
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.
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.
media: dt-bindings: media: rcar_vin: add device tree support for r8a774[35]
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: Rob Herring <robh@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-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>
Ryder Lee [Mon, 16 Apr 2018 02:34:30 +0000 (22:34 -0400)]
media: rc: mtk-cir: use of_device_get_match_data()
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: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Thu, 12 Apr 2018 20:28:39 +0000 (16:28 -0400)]
media: rc: mce_kbd decoder: fix race condition
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 <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Sun, 8 Apr 2018 10:36:40 +0000 (06:36 -0400)]
media: rc: mce_kbd decoder: fix stuck keys
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 <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Sun, 25 Mar 2018 15:45:40 +0000 (11:45 -0400)]
media: rc: mce_kbd decoder: low timeout values cause double keydowns
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 <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Sat, 24 Mar 2018 12:02:48 +0000 (08:02 -0400)]
media: rc: per-protocol repeat period and minimum keyup timer
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 d57ea877af38 ("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 <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Fri, 23 Mar 2018 20:47:37 +0000 (16:47 -0400)]
media: rc: set timeout to smallest value required by enabled protocols
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 <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Tue, 27 Mar 2018 15:24:05 +0000 (11:24 -0400)]
media: rc: report receiver and transmitter type on device register
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: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Koji Matsuoka [Fri, 13 Apr 2018 02:18:13 +0000 (22:18 -0400)]
media: rcar-vin: Fix image alignment for setting pre clipping
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.
Suman Anna [Wed, 14 Mar 2018 15:41:36 +0000 (11:41 -0400)]
media: omap3isp: fix unbalanced dma_iommu_mapping
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: Pavel Machek <pavel@ucw.cz> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>