OSDN Git Service
Arnd Bergmann [Mon, 9 Apr 2018 09:48:01 +0000 (05:48 -0400)]
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.
Co-developed-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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>
Laurent Pinchart [Sat, 7 Apr 2018 11:40:08 +0000 (07:40 -0400)]
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>
Mauro Carvalho Chehab [Thu, 5 Apr 2018 14:54:14 +0000 (10:54 -0400)]
media: omap: omap-iommu.h: allow building drivers with COMPILE_TEST
Drivers that depend on omap-iommu.h (currently, just omap3isp)
need a stub implementation in order to be built with COMPILE_TEST.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Niklas Söderlund [Sat, 14 Apr 2018 11:57:26 +0000 (07:57 -0400)]
media: rcar-vin: enable support for r8a77970
Add the SoC specific information for Renesas r8a77970.
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 [Sat, 14 Apr 2018 11:57:25 +0000 (07:57 -0400)]
media: rcar-vin: enable support for r8a7796
Add the SoC specific information for Renesas r8a7796.
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 [Sat, 14 Apr 2018 11:57:24 +0000 (07:57 -0400)]
media: rcar-vin: enable support for r8a7795
Add the SoC specific information for Renesas r8a7795 ES1.x and ES2.0.
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 [Sat, 14 Apr 2018 11:57:23 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:22 +0000 (07:57 -0400)]
media: rcar-vin: add link notify for Gen3
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 [Sat, 14 Apr 2018 11:57:21 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:20 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:19 +0000 (07:57 -0400)]
media: rcar-vin: change name of video device
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 <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 [Sat, 14 Apr 2018 11:57:18 +0000 (07:57 -0400)]
media: rcar-vin: add group allocator functions
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 <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 [Sat, 14 Apr 2018 11:57:17 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:16 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:15 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:14 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:13 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:12 +0000 (07:57 -0400)]
media: rcar-vin: enable Gen3 hardware configuration
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 [Sat, 14 Apr 2018 11:57:11 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:10 +0000 (07:57 -0400)]
media: rcar-vin: cache video standard
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 <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 [Sat, 14 Apr 2018 11:57:09 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:08 +0000 (07:57 -0400)]
media: rcar-vin: break out format alignment and checking
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 <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 [Sat, 14 Apr 2018 11:57:07 +0000 (07:57 -0400)]
media: rcar-vin: align pixelformat check
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 <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 [Sat, 14 Apr 2018 11:57:06 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:05 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:04 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:03 +0000 (07:57 -0400)]
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.
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 [Sat, 14 Apr 2018 11:57:02 +0000 (07:57 -0400)]
media: rcar-vin: move functions regarding scaling
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 <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 [Sat, 14 Apr 2018 11:57:01 +0000 (07:57 -0400)]
media: rcar-vin: move max width and height information to chip information
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: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
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 [Sat, 14 Apr 2018 11:57:00 +0000 (07:57 -0400)]
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.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
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 [Sat, 14 Apr 2018 11:56:59 +0000 (07:56 -0400)]
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.
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 [Sat, 14 Apr 2018 11:56:58 +0000 (07:56 -0400)]
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.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Acked-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 [Sat, 14 Apr 2018 11:56:57 +0000 (07:56 -0400)]
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.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
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 [Sat, 14 Apr 2018 11:56:56 +0000 (07:56 -0400)]
media: rcar-vin: add Gen3 devicetree bindings documentation
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: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Rob Herring <robh@kernel.org>
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>
Fabrizio Castro [Sat, 14 Apr 2018 11:56:55 +0000 (07:56 -0400)]
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>
Fabrizio Castro [Sat, 14 Apr 2018 11:56:54 +0000 (07:56 -0400)]
media: dt-bindings: media: rcar_vin: Reverse SoC part number list
Change the sorting of the part numbers from descending to ascending to
match with other documentation.
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>
Andi Shyti [Fri, 13 Apr 2018 13:48:29 +0000 (09:48 -0400)]
media: rc: ir-spi: update Andi's e-mail
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 <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Wed, 11 Apr 2018 14:57:57 +0000 (10:57 -0400)]
media: cx88: enable IR transmitter on HVR-1300
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 <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Sun, 8 Apr 2018 15:06:49 +0000 (11:06 -0400)]
media: rc: mceusb: allow the timeout to be configurable
mceusb devices have a default timeout of 100ms, but this can be changed.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Sean Young [Wed, 18 Apr 2018 09:36:25 +0000 (05:36 -0400)]
media: rc: mceusb: IR of length 0 means IR timeout, not reset
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 <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 [Wed, 11 Apr 2018 15:02:16 +0000 (11:02 -0400)]
media: rc: mce_kbd decoder: remove superfluous call to input_sync
There is nothing to sync in this code path.
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 [Sat, 7 Apr 2018 21:41:17 +0000 (17:41 -0400)]
media: rc: mce_kbd protocol encodes two scancodes
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 <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:59:52 +0000 (16:59 -0400)]
media: rc: add ioctl to get the current timeout
Since the kernel now modifies the timeout, make it possible to retrieve
the current value.
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.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Colin Ian King [Wed, 18 Apr 2018 15:26:19 +0000 (11:26 -0400)]
media: cec: set ev rather than v with CEC_PIN_EVENT_FL_DROPPED bit
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:
6ec1cbf6b125 ("media: cec: improve CEC pin event handling")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Kai-Heng Feng [Mon, 26 Mar 2018 06:06:16 +0000 (02:06 -0400)]
media: cx231xx: Add support for AverMedia DVD EZMaker 7
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: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
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>
Mauro Carvalho Chehab [Thu, 19 Apr 2018 16:28:07 +0000 (12:28 -0400)]
media: v4l2-compat-ioctl32: better document the code
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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Tue, 17 Apr 2018 13:01:46 +0000 (09:01 -0400)]
media: v4l2-compat-ioctl32: simplify casts
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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Mon, 16 Apr 2018 14:58:18 +0000 (10:58 -0400)]
media: v4l2-compat-ioctl32: better name userspace pointers
In the past, "up" were an acronym for "user pointer" and "kp" for
"kernel pointer". However, since commit
a1dfb4c48cc1 ("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: Sakari Ailus <sakari.ailus@linux.intel.com>
Suggested-by: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Wed, 11 Apr 2018 14:23:18 +0000 (10:23 -0400)]
media: v4l2-compat-ioctl32: fix several __user annotations
Smatch report several issues with bad __user annotations:
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: expected void [noderef] <asn:1>*uptr
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: got void *<noident>
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: expected void const volatile [noderef] <asn:1>*<noident>
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: got struct v4l2_plane [noderef] <asn:1>**<noident>
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: expected void [noderef] <asn:1>*uptr
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: got void *[assigned] base
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: expected struct v4l2_ext_control [noderef] <asn:1>*kcontrols
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: got struct v4l2_ext_control *<noident>
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: expected unsigned char [usertype] *__pu_val
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: got void [noderef] <asn:1>*
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: expected void [noderef] <asn:1>*uptr
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: got void *[assigned] edid
Fix them.
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Wed, 18 Apr 2018 19:21:41 +0000 (15:21 -0400)]
media: si470x: fix a typo at the Makefile causing build issues
Instead of +=, the rule had :=, with actually disables build
of everything else.
Fixes:
58757984ca3c ("media: si470x: allow build both USB and I2C at the same time")
Reported-by: Daniel Scheller <d.scheller.oss@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Daniel Scheller [Mon, 16 Apr 2018 17:36:00 +0000 (13:36 -0400)]
media: ddbridge: don't uselessly check for dma in start/stop functions
The check for a valid ptr in ddb_io->dma isn't really necessary since only
devices that do data transport using DMA are supported by the driver, and
all previous initialisation code (through input_init(), output_init() and
dma_init(), has_dma is always true as it's set in ddb_probe() during
driver load) guarantees the ptr is set.
As a side effect, this silences these sparse warnings (albeit them being
false positives as ddb_io->dma won't change in these functions so the
condition always equals to the same result):
drivers/media/pci/ddbridge/ddbridge-core.c:495:9: warning: context imbalance in 'ddb_output_start' - different lock contexts for basic block
drivers/media/pci/ddbridge/ddbridge-core.c:510:9: warning: context imbalance in 'ddb_output_stop' - different lock contexts for basic block
drivers/media/pci/ddbridge/ddbridge-core.c:525:9: warning: context imbalance in 'ddb_input_stop' - different lock contexts for basic block
drivers/media/pci/ddbridge/ddbridge-core.c:560:9: warning: context imbalance in 'ddb_input_start' - different lock contexts for basic block
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 12 Apr 2018 12:28:33 +0000 (08:28 -0400)]
media: mantis: prevent staying forever in a loop at IRQ
As warned by smatch:
drivers/media/pci/mantis/mantis_uart.c:105 mantis_uart_work() warn: this loop depends on readl() succeeding
If something goes wrong at readl(), the logic will stay there
inside an IRQ code forever. This is not the nicest thing to
do :-)
So, add a timeout there, preventing staying inside the IRQ
for more than 10ms.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 12 Apr 2018 10:32:18 +0000 (06:32 -0400)]
media: st_rc: Don't stay on an IRQ handler forever
As warned by smatch:
drivers/media/rc/st_rc.c:110 st_rc_rx_interrupt() warn: this loop depends on readl() succeeding
If something goes wrong at readl(), the logic will stay there
inside an IRQ code forever. This is not the nicest thing to
do :-)
So, add a timeout there, preventing staying inside the IRQ
for more than 10ms.
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 12 Apr 2018 09:44:33 +0000 (05:44 -0400)]
media: atomisp: get rid of a warning
On smatch, this warning is trigged:
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c:324 __bo_take_off_handling() error: we previously assumed 'bo->prev' could be null (see line 314)
Because it can't properly analize the truth table for the above
function. So, add an explicit check for the final condition there.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 12 Apr 2018 09:31:59 +0000 (05:31 -0400)]
media: atomisp: compat32: fix __user annotations
The __user annotations at the compat32 code is not right:
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: expected void *base
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: expected unsigned int [usertype] *xcoords_y
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: expected unsigned int [usertype] *ycoords_y
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: expected unsigned int [usertype] *xcoords_uv
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: expected unsigned int [usertype] *ycoords_uv
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: expected unsigned int [usertype] *effective_width
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: expected unsigned int [usertype] *effective_width
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: expected struct v4l2_framebuffer *frame
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: expected unsigned short *calb_grp_values
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:701:39: warning: cast removes address space of expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: expected void const volatile [noderef] <asn:1>*<noident>
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: got unsigned int [usertype] *src
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: expected struct atomisp_shading_table *shading_table
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: expected void [noderef] <asn:1>*to
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: got struct atomisp_shading_table *shading_table
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: expected struct atomisp_morph_table *morph_table
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: expected void [noderef] <asn:1>*to
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: got struct atomisp_morph_table *morph_table
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: expected struct atomisp_dvs2_coefficients *dvs2_coefs
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: expected void [noderef] <asn:1>*to
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: got struct atomisp_dvs2_coefficients *dvs2_coefs
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: expected struct atomisp_dvs_6axis_config *dvs_6axis_config
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: expected void [noderef] <asn:1>*to
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: got struct atomisp_dvs_6axis_config *dvs_6axis_config
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: expected struct atomisp_sensor_ae_bracketing_lut_entry *lut
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: got void [noderef] <asn:1>*
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 12 Apr 2018 09:20:31 +0000 (05:20 -0400)]
media: staging: atomisp: add missing include
There are two functions used externally:
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:866:6: warning: symbol 'atomisp_do_compat_ioctl' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:1110:6: warning: symbol 'atomisp_compat_ioctl32' was not declared. Should it be static?
whose include header is missing. Add it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 12 Apr 2018 09:08:39 +0000 (05:08 -0400)]
media: atomisp: compat32: use get_user() before referencing user data
The logic at get_atomisp_parameters32() is broken, as pointed by
smatch:
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:21: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:744:60: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:763:21: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:770:60: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:21: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:795:60: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:812:21: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:819:60: warning: dereference of noderef expression
It tries to access userspace data directly, without calling
get_user(). That should generate OOPS. Thankfully, the right
logic is already there (although commented out).
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Wed, 11 Apr 2018 15:47:32 +0000 (11:47 -0400)]
media: v4l2-compat-ioctl32: prevent go past max size
As warned by smatch:
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:879 put_v4l2_ext_controls32() warn: check for integer overflow 'count'
The access_ok() logic should check for too big arrays too.
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Wed, 11 Apr 2018 13:33:18 +0000 (09:33 -0400)]
media: platform: fix some 64-bits warnings
The omap/omap3 and viu drivers are for 32 bit platforms only.
There, a pointer has 32 bits. Now that those drivers build
for 64 bits with COMPILE_TEST, they produce the following
warnings:
drivers/media/platform/omap/omap_vout_vrfb.c: In function 'omap_vout_allocate_vrfb_buffers':
drivers/media/platform/omap/omap_vout_vrfb.c:57:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
memset((void *) vout->smsshado_virt_addr[i], 0,
^
drivers/media/platform/fsl-viu.c: In function 'viu_setup_preview':
drivers/media/platform/fsl-viu.c:753:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
reg_val.field_base_addr = (u32)dev->ovbuf.base;
^
drivers/media/platform/omap/omap_vout.c: In function 'omap_vout_get_userptr':
drivers/media/platform/omap/omap_vout.c:209:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
*physp = virt_to_phys((void *)virtp);
^
drivers/media/platform/omap3isp/ispccdc.c: In function 'ccdc_config':
drivers/media/platform/omap3isp/ispccdc.c:738:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
(__force void __user *)fpc.fpcaddr,
^
Add some typecasts to remove those warnings when building for
64 bits.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Wed, 11 Apr 2018 12:27:59 +0000 (08:27 -0400)]
media: atomisp: remove an impossible condition
Changeset
dc9f65cf9aea ("media: staging: atomisp: avoid a warning if 32
bits build") was meant to solve an impossible condition when building
with 32 bits. It turns that this impossible condition also happens wit
64 bits:
drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:698 gmin_get_config_var() warn: impossible condition '(*out_len > (~0)) => (0-u64max > u64max)'
After a further analysis, this condition will always be false as, on
all architectures, size_t doesn't have more bits than unsigned long.
Also, the only two archs that really matter are x86 and x86_64, as this
driver doesn't build on other archs (as it depends on X86-specific UEFI
support).
So, just drop the useless code.
Fixes:
dc9f65cf9aea ("media: staging: atomisp: avoid a warning if 32 bits build")
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Hans Verkuil [Sat, 7 Apr 2018 09:38:52 +0000 (05:38 -0400)]
media: cec: fix smatch error
drivers/media/cec/cec-pin-error-inj.c:231
cec_pin_error_inj_parse_line() error: uninitialized symbol 'pos'.
The tx-add-bytes command didn't check for the presence of an argument, and
also didn't check that it was > 0.
This should fix this error.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Wed, 4 Apr 2018 11:21:04 +0000 (07:21 -0400)]
media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props()
The logic at v4l2_fwnode_reference_parse_int_props() is somewhat
complex and violates Linux coding style, as it does multiple
statements on a single line. That makes static analyzers to
be confused, as warned by smatch:
drivers/media/v4l2-core/v4l2-fwnode.c:832 v4l2_fwnode_reference_parse_int_props() warn: passing zero to 'PTR_ERR'
Simplify the logic, in order to make clearer about what happens
when v4l2_fwnode_reference_get_int_prop() returns an error.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 5 Apr 2018 09:30:52 +0000 (05:30 -0400)]
media: dvb_frontend: fix locking issues at dvb_frontend_get_event()
As warned by smatch:
drivers/media/dvb-core/dvb_frontend.c:314 dvb_frontend_get_event() warn: inconsistent returns 'sem:&fepriv->sem'.
Locked on: line 288
line 295
line 306
line 314
Unlocked on: line 303
The lock implementation for get event is wrong, as, if an
interrupt occurs, down_interruptible() will fail, and the
routine will call up() twice when userspace calls the ioctl
again.
The bad code is there since when Linux migrated to git, in
2005.
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 18:45:59 +0000 (14:45 -0400)]
media: staging: atomisp: fix string comparation logic
it makes no sense to use strncmp() with a size with is
bigger than the string we're comparing with.
Fix those warnings:
drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c:776 atomisp_open() error: strncmp() '"ATOMISP ISP ACC"' too small (16 vs 32)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c:913 atomisp_release() error: strncmp() '"ATOMISP ISP ACC"' too small (16 vs 32)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c:2751 atomisp_vidioc_default() error: strncmp() '"ATOMISP ISP ACC"' too small (16 vs 32)
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 18:08:37 +0000 (14:08 -0400)]
media: atomisp: fix __user annotations
There are lots of troubles with atomisp __user annotations. Fix them.
drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c:357:49: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c:357:49: expected void *userptr
drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c:357:49: got void [noderef] <asn:1>*user_ptr
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:3302:43: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:3302:43: expected void const [noderef] <asn:1>*from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:3302:43: got void const *from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4070:58: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4070:58: expected void const *from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4070:58: got unsigned short [noderef] <asn:1>*<noident>
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4082:58: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4082:58: expected void const *from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4082:58: got unsigned short [noderef] <asn:1>*<noident>
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: expected void const [noderef] <asn:1>*from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: got unsigned short [usertype] *<noident>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 17:47:20 +0000 (13:47 -0400)]
media: staging: atomisp: don't declare the same vars as both private and public
The mmu_private.h header is included at mmu.c, with duplicates the
already existing definitions at mmu_public.h.
Fix this by removing the erroneous header file.
Solve those issues:
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:24:26: warning: function 'mmu_reg_store' with external linkage has definition
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:35:30: warning: function 'mmu_reg_load' with external linkage has definition
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:24:26: warning: function 'mmu_reg_store' with external linkage has definition
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:35:30: warning: function 'mmu_reg_load' with external linkage has definition
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 17:31:13 +0000 (13:31 -0400)]
media: staging: atomisp: fix number conversion
smatch says that there's an issue with number
conversion:
drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:4154 sh_css_params_write_to_ddr_internal() warn: '((-(1 << ((14 - 1)))))'
4294959104 can't fit into 32767 'converted_macc_table.data[idx]'
drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:4157 sh_css_params_write_to_ddr_internal() warn: '((-(1 << ((14 - 1)))))'
4294959104 can't fit into 32767 'converted_macc_table.data[idx + 1]'
drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:4160 sh_css_params_write_to_ddr_internal() warn: '((-(1 << ((14 - 1)))))'
4294959104 can't fit into 32767 'converted_macc_table.data[idx + 2]'
drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:4163 sh_css_params_write_to_ddr_internal() warn: '((-(1 << ((14 - 1)))))'
4294959104 can't fit into 32767 'converted_macc_table.data[idx + 3]'
drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c:168 ia_css_eed1_8_vmem_encode() warn: assigning (-8192) to unsigned variable 'to->e_dew_enh_a[0][base + j]'
That's probably because min() and max() definition used there
are really poor ones. So, replace by the in-kernel macro.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 14:18:33 +0000 (10:18 -0400)]
media: omap_vout: fix wrong identing
As warned:
drivers/media/platform/omap/omap_vout.c:711 omap_vout_buffer_setup() warn: inconsistent indenting
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 14:04:47 +0000 (10:04 -0400)]
media: fsl-viu: fix __iomem annotations
Those annotations are wrong, causing this warning:
drivers/media/platform/fsl-viu.c:1440:21: warning: incorrect type in assignment (different address spaces)
drivers/media/platform/fsl-viu.c:1440:21: expected struct viu_reg *vr
drivers/media/platform/fsl-viu.c:1440:21: got struct viu_reg [noderef] <asn:2>*[assigned] viu_regs
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 13:50:45 +0000 (09:50 -0400)]
media: fsl-viu: use %p to print pointers
Solve those warnings:
drivers/media/platform/fsl-viu.c:299 restart_video_queue() warn: argument 3 to %08lx specifier is cast from pointer
drivers/media/platform/fsl-viu.c:506 buffer_queue() warn: argument 2 to %08lx specifier is cast from pointer
drivers/media/platform/fsl-viu.c:518 buffer_queue() warn: argument 2 to %08lx specifier is cast from pointer
drivers/media/platform/fsl-viu.c:528 buffer_queue() warn: argument 2 to %08lx specifier is cast from pointer
drivers/media/platform/fsl-viu.c:1219 viu_open() warn: argument 2 to %08lx specifier is cast from pointer
drivers/media/platform/fsl-viu.c:1219 viu_open() warn: argument 3 to %08lx specifier is cast from pointer
drivers/media/platform/fsl-viu.c:1219 viu_open() warn: argument 4 to %08lx specifier is cast from pointer
drivers/media/platform/fsl-viu.c:1329 viu_mmap() warn: argument 2 to %08lx specifier is cast from pointer
drivers/media/platform/fsl-viu.c:1334 viu_mmap() warn: argument 2 to %08lx specifier is cast from pointer
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 12:33:44 +0000 (08:33 -0400)]
media: isppreview: fix __user annotations
The 'from' variable at preview_config() expects an __user * type.
However, the logic there does:
from = *(void * __user *) ((void *)cfg + attr->config_offset);
With actually means a void pointer, pointing to a void __ user
pointer. When the first pointer is de-referenced with *(foo),
the type it returns is "void *" instead of "void __user *".
Change it to:
from = *(void __user **) ((void *)cfg + attr->config_offset);
in order to obtain, when de-referenced, a void __user pointer,
as desired.
That prevent those warnings:
drivers/media/platform/omap3isp/isppreview.c:893:45: warning: incorrect type in initializer (different address spaces)
drivers/media/platform/omap3isp/isppreview.c:893:45: expected void [noderef] <asn:1>*from
drivers/media/platform/omap3isp/isppreview.c:893:45: got void *[noderef] <asn:1><noident>
drivers/media/platform/omap3isp/isppreview.c:893:47: warning: dereference of noderef expression
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 12:29:10 +0000 (08:29 -0400)]
media: ispstat: use %p to print the address of a buffer
Instead of converting to int, use %p. That prevents this
warning:
drivers/media/platform/omap3isp/ispstat.c:451 isp_stat_bufs_alloc() warn: argument 7 to %08lx specifier is cast from pointer
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 12:24:27 +0000 (08:24 -0400)]
media: vpbe_display: get rid of warnings
Solve those warnings:
drivers/media/platform/davinci/vpbe_display.c:288 vpbe_start_streaming() warn: inconsistent indenting
drivers/media/platform/davinci/vpbe_display.c:1356 register_device() warn: argument 3 to %x specifier is cast from pointer
drivers/media/platform/davinci/vpbe_display.c:1356 register_device() warn: argument 4 to %x specifier is cast from pointer
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 12:12:51 +0000 (08:12 -0400)]
media: vpbe_display: properly handle error case
if v4l2_subdev_call(..., VENC_GET_FLD,...) fails, it
currently returns a random value. Instead, return 1.
That's probably better than returning 0, as this is very
likely what happens in practice with the current code, as
as the probably of an unititialized 32 bits integer to
have an specific value (0, in this case), is 1/(2^32).
An alternative would be to return an error code, and
let the caller to hint, based on the past received
frame, but that sounds weird.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 12:09:18 +0000 (08:09 -0400)]
media: mmp-driver: add needed __iomem marks to power_regs
Solve those warnings:
drivers/media/platform/marvell-ccic/mmp-driver.c:135:41: warning: incorrect type in argument 2 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:135:41: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:135:41: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:136:44: warning: incorrect type in argument 2 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:136:44: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:136:44: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:174:38: warning: incorrect type in argument 2 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:174:38: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:174:38: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:175:38: warning: incorrect type in argument 2 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:175:38: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:175:38: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:195:48: warning: incorrect type in argument 1 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:195:48: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:195:48: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:196:55: warning: incorrect type in argument 2 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:196:55: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:196:55: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:197:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:197:54: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:197:54: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:202:48: warning: incorrect type in argument 1 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:202:48: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:202:48: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:203:55: warning: incorrect type in argument 2 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:203:55: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:203:55: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:204:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:204:54: expected void [noderef] <asn:2>*<noident>
drivers/media/platform/marvell-ccic/mmp-driver.c:204:54: got void *
drivers/media/platform/marvell-ccic/mmp-driver.c:389:25: warning: incorrect type in assignment (different address spaces)
drivers/media/platform/marvell-ccic/mmp-driver.c:389:25: expected void *power_regs
drivers/media/platform/marvell-ccic/mmp-driver.c:389:25: got void [noderef] <asn:2>*
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 12:05:41 +0000 (08:05 -0400)]
media: davinci: fix an inconsistent ident
drivers/media/platform/davinci/vpbe_osd.c:849 try_layer_config() warn: inconsistent indenting
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 12:02:46 +0000 (08:02 -0400)]
media: isif: reorder a statement to match coding style
On all places, we do:
void <asn_ref> *foo;
Here, it is doing, instead:
void * <asn_ref> foo;
That tricks static analyzers, making it see errors where
there's none. So, just reorder in order to cleanup those
warnings:
drivers/media/platform/davinci/isif.c:1066:22: warning: incorrect type in assignment (different address spaces)
drivers/media/platform/davinci/isif.c:1066:22: expected void *[noderef] <asn:2>addr
drivers/media/platform/davinci/isif.c:1066:22: got void [noderef] <asn:2>*
drivers/media/platform/davinci/isif.c:1074:44: warning: incorrect type in assignment (different address spaces)
drivers/media/platform/davinci/isif.c:1074:44: expected void [noderef] <asn:2>*static [toplevel] [assigned] base_addr
drivers/media/platform/davinci/isif.c:1074:44: got void *[noderef] <asn:2>addr
drivers/media/platform/davinci/isif.c:1078:51: warning: incorrect type in assignment (different address spaces)
drivers/media/platform/davinci/isif.c:1078:51: expected void [noderef] <asn:2>*static [toplevel] [assigned] linear_tbl0_addr
drivers/media/platform/davinci/isif.c:1078:51: got void *[noderef] <asn:2>addr
drivers/media/platform/davinci/isif.c:1082:51: warning: incorrect type in assignment (different address spaces)
drivers/media/platform/davinci/isif.c:1082:51: expected void [noderef] <asn:2>*static [toplevel] [assigned] linear_tbl1_addr
drivers/media/platform/davinci/isif.c:1082:51: got void *[noderef] <asn:2>addr
drivers/media/platform/davinci/isif.c:1067:22: warning: dereference of noderef expression
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 11:54:51 +0000 (07:54 -0400)]
media: si470x: fix __be16 annotations
The annotations there are wrong as warned:
drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16
drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16
drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16
drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16
drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: warning: incorrect type in assignment (different base types)
drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: expected unsigned short [unsigned] [short] <noident>
drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: got restricted __be16 [usertype] <noident>
drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16
drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16
drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16
drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 11:48:08 +0000 (07:48 -0400)]
media: davinci_vpfe: fix __user annotations
The __user annotations on this driver are wrong, causing lots
of warnings:
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1269:22: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1269:22: expected void [noderef] <asn:1>*from
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1269:22: got void *[noderef] <asn:1><noident>
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1313:20: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1313:20: expected void [noderef] <asn:1>*to
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1313:20: got void *[noderef] <asn:1><noident>
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:424:41: warning: incorrect type in initializer (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:424:41: expected struct ipipeif_params *config
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:424:41: got void [noderef] <asn:1>*arg
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:474:46: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:474:46: expected void [noderef] <asn:1>*arg
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:474:46: got void *arg
drivers/staging/media/davinci_vpfe/dm365_resizer.c:922:32: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_resizer.c:922:32: expected void const [noderef] <asn:1>*from
drivers/staging/media/davinci_vpfe/dm365_resizer.c:922:32: got struct vpfe_rsz_config_params *config
drivers/staging/media/davinci_vpfe/dm365_resizer.c:945:27: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_resizer.c:945:27: expected void [noderef] <asn:1>*to
drivers/staging/media/davinci_vpfe/dm365_resizer.c:945:27: got void *<noident>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 11:45:06 +0000 (07:45 -0400)]
media: davinci_vpfe: cleanup ipipe_[g|s]_config logic
Reduce one ident level inside those functions and use BIT()
macro.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 11:30:16 +0000 (07:30 -0400)]
media: davinci_vpfe: fix a typo for "default"
resizer_set_defualt_configuration -> resizer_set_default_configuration
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 11:27:45 +0000 (07:27 -0400)]
media: davinci_vpfe: don't use kernel-doc markup for simple comments
Fix those two warnings:
drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c:90: warning: Function parameter or member 'interface' not described in 'MODULE_PARM_DESC'
drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c:90: warning: Function parameter or member '(default' not described in 'MODULE_PARM_DESC'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 11:25:05 +0000 (07:25 -0400)]
media: davinci_vpfe: vpfe_video: remove an unused var
as warned:
drivers/staging/media/davinci_vpfe/vpfe_video.c: In function 'vpfe_streamon':
drivers/staging/media/davinci_vpfe/vpfe_video.c:1471:31: warning: variable 'sdinfo' set but not used [-Wunused-but-set-variable]
struct vpfe_ext_subdev_info *sdinfo;
^~~~~~
While here, cleanup this kernel-doc warning:
drivers/staging/media/davinci_vpfe/vpfe_video.c:225: warning: Function parameter or member 'pipe' not described in 'vpfe_video_validate_pipeline'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 11:12:45 +0000 (07:12 -0400)]
media: davinci_vpfe: get rid of an unused var at dm365_isif.c
Not sure what was the original idea here, but the implementation
went into a different way, and the fmt var is not used
anymore, as warned:
drivers/staging/media/davinci_vpfe/dm365_isif.c: In function '__isif_get_format':
drivers/staging/media/davinci_vpfe/dm365_isif.c:1401:29: warning: variable 'fmt' set but not used [-Wunused-but-set-variable]
struct v4l2_subdev_format fmt;
^~~
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 11:08:24 +0000 (07:08 -0400)]
media: davinci_vpfe: mark __iomem as such
There are several usages of an __iomem memory that aren't
marked as such, causing those warnings:
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:201:27: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:201:27: expected void *ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:201:27: got void [noderef] <asn:2>*ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: expected void const volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: expected void const volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:510:42: warning: incorrect type in initializer (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:510:42: expected void *ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:510:42: got void [noderef] <asn:2>*ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: expected void const volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:797:42: warning: incorrect type in initializer (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:797:42: expected void *ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:797:42: got void [noderef] <asn:2>*ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: got void *
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 10:26:34 +0000 (06:26 -0400)]
media: davinci_vpfe: fix vpfe_ipipe_init() error handling
As warned:
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1834 vpfe_ipipe_init() error: we previously assumed 'res' could be null (see line 1797)
There's something wrong at vpfe_ipipe_init():
1) it caches the resourse_size() from from the first region
and reuses to the second region;
2) the "res" var is overridden 3 times;
3) at free logic, it assumes that "res->start" is not
overridden by platform_get_resource(pdev, IORESOURCE_MEM, 6),
but that's not true, as it can even be NULL there.
This patch fixes the above issues by:
a) store the resources used by release_mem_region() on
a separate var;
b) stop caching resource_size(), using the function where
needed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 10:17:16 +0000 (06:17 -0400)]
media: dm365_ipipe: remove an unused var
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:74:17: warning: variable 'dev' set but not used [-Wunused-but-set-variable]
struct device *dev;
^~~
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Fri, 6 Apr 2018 10:02:53 +0000 (06:02 -0400)]
media: davinci_vpfe: remove useless checks from ipipe
The dm365_ipipe_hw.c and dm365_ipipe.c file check if several table
pointers, declared at davinci_vpfe_user.h, are filled before using
them.
The problem is that those pointers come from struct declarations
like:
struct vpfe_ipipe_yee {
...
short table[VPFE_IPIPE_MAX_SIZE_YEE_LUT];
};
So, they can't be NULL! Solve those warnings:
drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:433 ipipe_set_lutdpc_regs() warn: this array is probably non-NULL. 'dpc->table'
drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:763 ipipe_set_gamma_regs() warn: this array is probably non-NULL. 'gamma->table_r'
drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:766 ipipe_set_gamma_regs() warn: this array is probably non-NULL. 'gamma->table_b'
drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:769 ipipe_set_gamma_regs() warn: this array is probably non-NULL. 'gamma->table_g'
drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:791 ipipe_set_3d_lut_regs() warn: this array is probably non-NULL. 'lut_3d->table'
drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:903 ipipe_set_gbce_regs() warn: this array is probably non-NULL. 'gbce->table'
drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:946 ipipe_set_ee_regs() warn: this array is probably non-NULL. 'ee->table'
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:59 ipipe_validate_lutdpc_params() warn: this array is probably non-NULL. 'lutdpc->table'
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:697 ipipe_get_gamma_params() warn: this array is probably non-NULL. 'gamma_param->table_r'
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:705 ipipe_get_gamma_params() warn: this array is probably non-NULL. 'gamma_param->table_g'
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:712 ipipe_get_gamma_params() warn: this array is probably non-NULL. 'gamma_param->table_b'
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:745 ipipe_get_3d_lut_params() warn: this array is probably non-NULL. 'lut_param->table'
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:926 ipipe_get_gbce_params() warn: this array is probably non-NULL. 'gbce_param->table'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 5 Apr 2018 18:07:28 +0000 (14:07 -0400)]
media: staging: davinci_vpfe: allow building with COMPILE_TEST
This is a little bit hashish, but this driver is at staging,
so it won't become worse.
With this small change at Makefile, we can now build it with
COMPILE_TEST.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 5 Apr 2018 19:08:12 +0000 (15:08 -0400)]
media: si470x: allow build both USB and I2C at the same time
Currently, either USB or I2C is built. Change it to allow
having both enabled at the same time.
The main reason is that COMPILE_TEST all[yes/mod]builds will
now contain all drivers under drivers/media.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Mauro Carvalho Chehab [Thu, 5 Apr 2018 18:11:54 +0000 (14:11 -0400)]
media: omap4iss: make it build with COMPILE_TEST
This driver compile as-is with COMPILE_TEST.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>