[media] dib9000: read16/write16 could return an error code
Both dib9000_read16_attr and dib9000_write16_attr can return an
error code. However, they currently return an u16. This produces the
following warnings on smatch:
ivtv_flush_queues() calls ivtv_queue_move() with steal == NULL.
However, part of the code assumes that steal could be not null, as
pointed by smatch:
drivers/media/pci/ivtv/ivtv-queue.c:145 ivtv_queue_move() error: we previously assumed 'steal' could be null (see line 138)
This has the potential of causing an OOPS when the queue is
flushed.
That fixes the following smatch warning:
drivers/media/usb/pvrusb2/pvrusb2-hdw.c:4909 pvr2_hdw_state_log_state() error: buffer overflow 'buf' 256 <= 4294967294
[media] pvrusb2-io: no need to check if sp is not NULL
The buffer_complete() routine assumes that sp is not NULL,
otherwise it will fail completely. Btw, this is also
assumed at pvr2_buffer_queue(), with is the routine that
setups the URB handling.
So, remove the bogus for the callback at buffer_complete.
This fix this smatch warning:
drivers/media/usb/pvrusb2/pvrusb2-io.c:476 buffer_complete() warn: variable dereferenced before check 'sp' (see line 472)
[media] media_device: move allocation out of media_device_*_init
Right now, media_device_pci_init and media_device_usb_init does
media_device allocation internaly. That preents its usage when
the media_device struct is embedded on some other structure.
Move memory allocation outside it, to make it more generic.
Benoit Parrot [Fri, 19 Feb 2016 20:00:30 +0000 (18:00 -0200)]
[media] media: ti-vpe: cal: Fix warning: variable dereference before being checked
As reported ctx->sensor is being dereferenced before being checked
in cal_get_external_info(). That being the case it was also checked
twice in multiple other location where v4l2_subdev_call is already
checking it so no need to explicitly check it again.
Benoit Parrot [Fri, 19 Feb 2016 19:24:45 +0000 (17:24 -0200)]
[media] media: ti-vpe: cal: Fix unreachable code in enum_frame_interval
As reported, the current cal_enum_frameintervals() is confusing
and does not have the intended behavior.
Fix this by re-implementing to properly propagate the enum_frame_interval
request to the subdevice.
[mchehab@osg.samsung.com: remove a now bogus "ret = 0" statement] Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reported-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] dib0090: do the right thing if rf_ramp is NULL
As warned by smatch:
drivers/media/dvb-frontends/dib0090.c:1118 dib0090_pwm_gain_reset() error: we previously assumed 'state->rf_ramp' could be null (see line 1086)
drivers/media/platform/vsp1/vsp1_drm.c:47:5: warning: no previous prototype for 'vsp1_du_init' [-Wmissing-prototypes]
int vsp1_du_init(struct device *dev)
^
drivers/media/platform/vsp1/vsp1_drm.c:76:5: warning: no previous prototype for 'vsp1_du_setup_lif' [-Wmissing-prototypes]
int vsp1_du_setup_lif(struct device *dev, unsigned int width,
^
drivers/media/platform/vsp1/vsp1_drm.c:221:6: warning: no previous prototype for 'vsp1_du_atomic_begin' [-Wmissing-prototypes]
void vsp1_du_atomic_begin(struct device *dev)
^
drivers/media/platform/vsp1/vsp1_drm.c:273:5: warning: no previous prototype for 'vsp1_du_atomic_update' [-Wmissing-prototypes]
int vsp1_du_atomic_update(struct device *dev, unsigned int rpf_index,
^
drivers/media/platform/vsp1/vsp1_drm.c:451:6: warning: no previous prototype for 'vsp1_du_atomic_flush' [-Wmissing-prototypes]
void vsp1_du_atomic_flush(struct device *dev)
^
[media] v4l: vsp1: Configure device based on IP version
The IP version number carries enough information to identify the exact
device instance features. Drop the related DT properties and use the IP
version instead.
Display lists contain lists of registers and associated values to be
applied atomically by the hardware. They lower the pressure on interrupt
processing delays when reprogramming the device as settings can be
prepared well in advance and queued to the hardware without waiting for
the end of the current frame.
Display list support is currently limited to the DRM pipeline.
[media] v4l: vsp1: Implement atomic update for the DRM driver
Add two API functions named vsp1_du_atomic_begin() and
vsp1_du_atomic_flush() to signal the start and end of an atomic update.
The vsp1_du_setup_rpf() function is renamed to vsp1_du_atomic_update()
for consistency.
With this new API, the driver will reprogram all modified inputs
atomically before restarting the video stream.
Implement internal control of the VSP pipeline to be used by the DU
DRM/KMS driver when using the VSP as an internal composer handled
through DRM/KMS only.
[media] v4l: vsp1: Don't validate links when the userspace API is disabled
As the pipeline is configured internally by the driver when the
userspace API is disabled its configuration can be trusted and link
validation isn't needed.
[media] v4l: vsp1: Set the alpha value manually in RPF and WPF s_stream handlers
The RPF and WPF alpha values are set through V4L2 controls and applied
when starting the video stream by a call to v4l2_ctrl_handler_setup().
As that function uses the control handler mutex it can't be called in
interrupt context, where the VSP+DU pipeline handler might need to
reconfigure the pipeline.
Set the alpha value manually in the RPF and WPF s_stream handler to
ensure that the hardware is properly configured even when controlled
without the userspace API. If the userspace API is enabled protect that
with the control lock to avoid race conditions with userspace.
[media] v4l: vsp1: Make pipeline inputs array index by RPF index
The pipeline inputs array stores pointers to all RPFs contained in the
pipeline. It's currently indexed contiguously by adding RPFs in the
order they are found during graph walk. This can't easily support
dynamic addition and removal of RPFs while streaming, which will be
required for combined VSP+DU support.
Make the array indexed by RPF index instead and skip NULL elements when
iterating over RPFs.
[media] v4l: vsp1: Make the userspace API optional
The R-Car Gen3 SoCs include VSP instances dedicated to the DU that will
be controlled entirely by the rcar-du-drm driver through the KMS API. To
support that use case make the userspace V4L2 API optional.
Laurent Pinchart [Fri, 14 Aug 2015 16:53:45 +0000 (13:53 -0300)]
[media] v4l: vsp1: Make the BRU optional
Not all VSP instances have a BRU on R-Car Gen3, make it optional. Set
the feature unconditionally for now, this will be fixed when adding Gen3
support.
[media] v4l: vsp1: Make number of BRU inputs configurable
The R-Car Gen3 family has 5-inputs BRUs, support them by making the
number of BRU inputs configurable.
As the driver assumes that the number of BRU inputs is equal to the
number of RPFs, replace the BRU_MAX_INPUTS macro with VSP1_MAX_RPF to
make the assumption apparent.
[media] v4l: vsp1: Set the SRU CTRL0 register when starting the stream
Commit 58f896d859ce ("[media] v4l: vsp1: sru: Make the intensity
controllable during streaming") refactored the stream start code and
removed the SRU CTRL0 register write by mistake. Add it back.
Fixes: 58f896d859ce ("[media] v4l: vsp1: sru: Make the intensity controllable during streaming") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] v4l: vsp1: Decouple pipeline end of frame processing from vsp1_video
To make the pipeline structure and operations usable without video
devices the frame end processing must be decoupled from struct
vsp1_video. Implement this by calling the video frame end function
indirectly through a function pointer in struct vsp1_pipeline.
[media] v4l: vsp1: Make rwpf operations independent of video device
The rwpf queue operation doesn't queue a buffer but sets the memory
address for the next run. Rename it to set_memory and pass it a new
structure independent of the video buffer than only contains memory
information.
[media] v4l: vsp1: Move video device out of struct vsp1_rwpf
To make the video device nodes optional we need to decouple the [rw]pf
instances from the video devices. Move video devices out of struct
vsp1_rwpf and instantiate them dynamically in the core driver code.
[media] v4l: vsp1: Change the type of the rwpf field in struct vsp1_video
The rwpf field contains a pointer to the rpf or wpf associated with the
video node. Instead of storing it as a vsp1_entity, store the
corresponding vsp1_rwpf pointer to allow accessing the vsp1_rwpf fields
directly.
ti-vpe/cal.c:387:26: warning: incorrect type in return expression (different address spaces)
ti-vpe/cal.c:459:26: warning: incorrect type in return expression (different address spaces)
ti-vpe/cal.c:503:27: warning: incorrect type in argument 6 (different address spaces)
ti-vpe/cal.c:509:47: warning: incorrect type in argument 6 (different address spaces)
ti-vpe/cal.c:518:47: warning: incorrect type in argument 6 (different address spaces)
ti-vpe/cal.c:526:31: warning: incorrect type in argument 6 (different address spaces)
ti-vpe/cal.c:1807:24: warning: Using plain integer as NULL pointer
ti-vpe/cal.c:1844:16: warning: Using plain integer as NULL pointer
Wu-Cheng Li [Tue, 19 Jan 2016 07:07:10 +0000 (05:07 -0200)]
[media] s5p-mfc: add the support of V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
There is a new control V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME to
force an encoder key frame. It is the same as requesting
V4L2_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE_I_FRAME.
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Some drivers also need a control like
V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE to force an encoder
key frame. Add a general V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
so the new drivers and applications can use it.
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Sudip Mukherjee [Fri, 12 Feb 2016 10:53:28 +0000 (08:53 -0200)]
[media] media: ti-vpe: add dependency of HAS_DMA
The build of m32r allmodconfig fails with the error:
drivers/media/v4l2-core/videobuf2-dma-contig.c:492:28: error: implicit
declaration of function 'dma_get_cache_alignment'
The build of videobuf2-dma-contig.c depends on HAS_DMA and it is
correctly mentioned in the Kconfig but the symbol VIDEO_TI_CAL also
selects VIDEOBUF2_DMA_CONTIG, so it is trying to compile
videobuf2-dma-contig.c even though HAS_DMA is not defined.
Fixes: 343e89a792a5 ("[media] media: ti-vpe: Add CAL v4l2 camera capture driver") Cc: Benoit Parrot <bparrot@ti.com> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Wed, 10 Feb 2016 07:40:56 +0000 (05:40 -0200)]
[media] timblogiw: move to staging in preparation for removal
The Timberdale FPGA video driver has not seen any real development
since 2011 (and very little before that).
One of the problems with the timblogiw driver is that it uses videobuf
instead of the newer vb2 framework. The long term goal is to either
convert or remove any driver still using videobuf. Since none of the
core v4l developers has the hardware, we cannot convert it ourselves.
As far as I can tell it was only used in an Intel demo board in 2009
using Meego:
Moving this driver to staging is the first step towards removal. After 2 or
3 kernel cycles it will be removed altogether unless someone steps up to
clean up this driver.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Richard Röjfors <richard@puffinpack.se> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Wed, 10 Feb 2016 11:32:25 +0000 (09:32 -0200)]
[media] adv7511: TX_EDID_PRESENT is still 1 after a disconnect
The V4L2_CID_TX_EDID_PRESENT control reports if an EDID is present.
The adv7511 however still reported the EDID present after disconnecting
the HDMI cable. Fix the logic regarding this control. And when the EDID
is disconnected also call ADV7511_EDID_DETECT to notify the bridge driver.
This was also missing.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v3.12 and up Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Dan Carpenter [Tue, 9 Feb 2016 11:14:12 +0000 (09:14 -0200)]
[media] usb/cpia2_core: clean up a min_t() cast
It makes sense to make the min_t() cast unsigned here since we don't
really want negative sizes. Making it signed causes a static checker
warning in Smatch. Smatch knows "fw->size - i" is positive but it
doesn't know that fw->size is less than INT_MAX so in theory casting it
to int might lead to a negative.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] v4l2-async: Don't fail if registered_async isn't implemented
After sub-dev registration in v4l2_async_test_notify(), the v4l2-async
core calls the registered_async callback but if a sub-dev driver does
not implement it, v4l2_subdev_call() will return a -ENOIOCTLCMD which
should not be considered an error.
[media] siano: use generic function to create MC device
Currently, it is initializing the driver name using the wrong
name ("usb"). Use the generic function, as its logic works
best, and avoids repeating the very same code everywhere.
smscore_getbuffer() calls internally wait_event(), with can sleep.
As smsusb_onresponse() is called on interrupt context, this causes
the following warning:
Some macros were changed/removed at the material for v4.5. We need
to sync with those changes here, in order to avoid troubles.
* v4l_for_linus:
[media] media.h: get rid of MEDIA_ENT_F_CONN_TEST
[media] [for,v4.5] media.h: increase the spacing between function ranges
[media] media: i2c/adp1653: probe: fix erroneous return value
[media] media: davinci_vpfe: fix missing unlock on error in vpfe_prepare_pipeline()
Hans Verkuil [Thu, 11 Feb 2016 14:28:55 +0000 (12:28 -0200)]
[media] [for,v4.5] media.h: increase the spacing between function ranges
Each function range is quite narrow and especially for connectors this
will pose a problem. Increase the function ranges while we still can and
move the connector range to the end so that range is practically limitless.
[mchehab@osg.samsung.com: Rebased to apply at Linus tree] Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control
MEDIA_ENT_F_CONN_TEST is not really a connector, it is actually
a signal generator. Also, as other drivers use the
V4L2_CID_TEST_PATTERN control for signal generators, let's change
the driver accordingly.
v4l2-mc.c: In function 'v4l2_mc_create_media_graph':
v4l2-mc.c:60:69: warning: variable 'sensor' set but not used [-Wunused-but-set-variable]
We could solve it the other way: don't do the second loop for
webcams. However, that would fail if a chip would have two sensors
plugged. This is not the current case, but it doesn't hurt to be
future-safe here, specially since this code runs only once during
device probe. So, performance is not an issue here.
Reported-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] cx231xx, em28xx: pass media_device to si2157
As si2157 doesn't use the subdev, but has instead a binding
logic that doesn't have any core framework, we need to manually
pass the media_device struct via platform data on every place
it is called.
This fixes support for HVR-955Q when MC is enabled.
[media] em28xx-dvb: create RF connector on DVB-only mode
When in analog mode, the RF connector will be created by
em28xx-video. However, when the device is in digital mode only,
the RF connector is not shown. In this case, let the DVB
core to create it for us.
[media] use v4l2_mc_usb_media_device_init() on most USB devices
Except for the usbuvc driver (with has an embedded media_device
struct on it), the other drivers have a pointer to media_device.
On those drivers, replace their own implementation for the core
one. That warrants that those subdev drivers will fill the
media_device info the same way.
On USB drivers, the dev struct is usually filled with the USB
device. That would mean that the name of the driver specified
by media_device.dev.driver.name would be "usb", instead of the
name of the actual driver that created the media entity.
Add an optional field at the internal struct to allow drivers
to override the driver name.
[media] v4l2-mc: add a routine to create USB media_device
Instead of copying exactly the same code on all USB devices,
add an ancillary routine that will create and fill the
struct media_device with the values imported from the USB
device.
The tvp5150 decoder has different input connectors. The actual list of
HW inputs depends on the device version but all have at least these 3:
1) Composite0
2) Composite1
3) S-Video
and some variants have a 4th possible input connector:
4) Signal generator
The driver currently uses the .s_routing callback to switch the input
connector but since these are separate HW blocks, it's better to use
media entities to represent the input connectors and their source pads
linked with the decoder's sink pad.
This allows user-space to use the MEDIA_IOC_SETUP_LINK ioctl to choose
the input connector. For example using the media-ctl user-space tool:
The tvp5150 decoder has different input connectors so extend the device
tree binding to allow device tree source files to define the connectors
that are available on a given board.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] tvp5150: add internal signal generator to HW input list
Some tvp5150 variants, have an internal generator that can generate a
black screen output. Since this is a HW block, it should be in the HW
inputs list.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] v4l2-async: call registered_async after subdev registration
V4L2 sub-devices might need to do initialization that depends on being
registered with a V4L2 device. As an example, sub-devices with Media
Controller support may need to register entities and create pad links.
Execute the registered_async callback after the sub-device has been
registered with the V4L2 device so the driver can do any needed init.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
V4L2 sub-devices that are registered asynchronously have no way to know
when they have been registration with a V4L2 device but they might need
to take some action after this.
So let's add a callback that can be executed by the V4L2 async core to
allow sub-devices drivers to do any needed initialization that depends
on the registration.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
v4l2_ctrl_add_ctrl() interface has no users since its introduction in
commit 0996517cf8ea ("V4L/DVB: v4l2: Add new control handling framework")
and its functionality is covered by v4l2_ctrl_new() and derivative
interfaces, so it is safe to remove the interface from the kernel.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
projects / linux-beck.git / log