The VIDIOC_LOG_STATUS ioctl allows to dump the current status of a driver
to the kernel log. Currently this ioctl is only available at video device
nodes and the subdevs rely on the host driver to expose their core.log_status
operation to user space.
This patch adds VIDIOC_LOG_STATUS support at the sub-device nodes,
for standalone subdevs that expose their own /dev entry.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following ioctl sequence causes fimc_dma_run() to start processing without
complete scaler and DMA initialization which causes missing interrupt and
blocking on DQBUF:
S_FMT, STREAMON, QBUF, DQBUF, STREAMOFF, STREAMON, QBUF, DQBUF.
Fix this regression caused by moving pm_runtime* calls to start/stop_streaming
callback by making sure the fimc_m2m_resume() is always invoked when expected.
Reported-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
videobuf_dvb_register_bus relies on dvb_net_init to set dvbnet->dvbdev
on success, but ever since commit fcc8e7d8c0 ("dvb_net: Simplify the
code if DVB NET is not defined"), ->dvbdev is left unset when
networking support is disabled. Therefore in such configurations
videobuf_dvb_register_bus always returns failure, tripping
little-tested error handling paths and preventing the device from
being initialized and used.
Now that dvb_net_init returns a nonzero value on error, we can use
that as a more reliable error indication. Do so.
Now your card be used with CONFIG_DVB_NET=n, and the kernel will pass
on a more useful error code describing what happened when
CONFIG_DVB_NET=y but dvb_net_init fails due to resource exhaustion.
Reported-by: David Fries <David@Fries.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The function v4l2_device_register() is called too late in vpif_probe().
This meant that vpif_obj.v4l2_dev is accessed before it is initialized
which caused a crash.
This used to work in the past, but video_register_device() is now actually
using the v4l2_dev pointer.
Note that vpif_display.c doesn't have this bug, there v4l2_device_register()
is called at the beginning of vpif_probe.
Signed-off-by: Georgios Plakaris <gplakari@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Manjunath Hadli <Manjunath.hadli@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Somehow I didn't ever quite get around to implementing suspend/resume on
the MMP2 platform; this patch fixes that little oversight. A bit of core
work was necessary to do the right thing in the s/g DMA case.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Reworked device probing to get rid of hacks to guess the maximum size of
dvb iso transfer packets. The new code also selects the first alternate
config which supports the largest possible iso transfers for dvb.
[mchehab@redhat.com: Fix a few checkpatch.pl CodingStyle compliants]
Signed-off-by: Holger Nelson <hnelson@hnelson.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds support for the Honestech Vidbox NW03 USB capture device.
Signed-off-by: Gareth Williams <gareth@garethwilliams.me.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds support for the Terratec Cinergy HTC USB XS which is similar to
the Terratec H5 by adding the USB-ids to the table. According to
http://linux.terratec.de it uses the same ICs and DVB-C works for me
using the firmware of the H5.
Signed-off-by: Holger Nelson <hnelson@hnelson.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
vpbe_dev needs to be freed before leaving the function in an error case.
A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)
// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
x->f1
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
To properly detect frame loss the driver must keep
track of a frame_count.
Furthermore, field_count use was erroneous because
in progressive format this must be incremented twice.
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch uses channel 2 of the eMMa-PrP to convert
format provided by the sensor to YUV420.
This format is very useful since it is used by the
internal H.264 encoder.
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As our general practice, we use stream off before we close
the video node. So that the drivers its stream off function
would be called before its remove function.
But for the case for ctrl+c, the program would be force closed.
We have no chance to call that vb2 stream off from user space,
but directly call the remove function in soc_camera.
In that common code of soc_camera:
ici->ops->remove(icd);
if (ici->ops->init_videobuf2)
vb2_queue_release(&icd->vb2_vidq);
It would first call the device remove function, then release vb2,
in which stream off function is called. Thus it create different
order for the driver.
This patch change the order to make driver see the same sequence
to make it happy.
Signed-off-by: Lei Wen <leiwen@marvell.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
mt9m111 camera sensors support cropping and scaling. The current
implementation is broken. For example, .s_crop() sets output frame sizes
instead of the input cropping window. This patch adds a proper implementation
of these methods. Besides it adds a sensor-disable and -enable operations
on first open() and last close() respectively, to save power while closed and
to return the camera to the default power-on state.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cleanly separating register contexts A and B will allow us to configure
the contexts independently.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The "pixfmt" parameter of the struct soc_camera_host_ops::set_bus_param()
method is redundant, because at the time, when this method is called,
pixfmt is guaranteed to be equal to icd->current_fmt->host_fmt->fourcc.
Remove this parameter and update all drivers accordingly.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before this patch the resulting values from a try_fmt were different then
those from a s_fmt with the same parameters. try_fmt simply did not
touch / fill some values like bytesperline at all.
This patch also corrects bytesperline to the proper value for a planar
format such as the YUV420P format the pwc driver produces, which is
the bytesperline value for the biggest plane, rather then those
of all planes added together.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of making this a module parameter, automatically fallback to
higher compression settings if there is not enough bandwidth.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The pwc driver claims to support any resolution between 160x120
and 640x480, but emulates this by simply drawing a black border
around the image. Userspace can draw its own black border if it
really wants one.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This stems from the v4l1 era, with v4l2 everything can be done with
standardized v4l2 API calls.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The in kernel version of the pwc driver has never supported snapshot
mode, and now that we no longer support the pixfmt.priv abuse there also
no longer is a way for userspace to request it, rendering all the code in
question dead (never called), so remove it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The .priv field never was intended for this, setting a framerate is
support using the standardized S_PARM ioctl.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Setting pan/tilt should be done with v4l2 controls, like with other
cams. The button is available as a standard input device
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
So that events get generated for the new red + blue bal values when switching
to a preset. This allows apps to solely rely on events instead of needing
to do a query + g_ctrl on all controls when a control with the update flag
set is gets set or gets an event.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While testing gtk-v4l's new ctrl event code, I hit the following deadlock
in the pwc driver:
Thread 1:
-Does a VIDIOC_G_CTRL
-video2_ioctl takes the modlock
-video2_ioctl calls v4l2_g_ctrl
-v4l2_g_ctrl takes the ctrl_handler lock
-v4l2_g_ctrl calls pwc_g_volatile_ctrl
-pwc_g_volatile_ctrl releases the modlock as the usb transfer can take a
significant amount of time and we don't want to block DQBUF / QBUF too long
Thread 2:
-Does a VIDIOC_FOO_CTRL
-video2_ioctl takes the modlock
-video2_ioctl calls v4l2_foo_ctrl
-v4l2_foo_ctrl blocks while trying to take the ctrl_handler lock
Thread 1:
-Blocks while trying to re-take the modlock, as its caller will eventually
unlock that
Now we have thread 1 waiting for the modlock while holding the ctrl_handler
lock and thread 2 waiting for the ctrl_handler lock while holding the
modlock -> deadlock.
Conclusion:
1) We cannot unlock modlock from pwc_s_ctrl / pwc_g_volatile_ctrl,
but this can cause QBUF / DQBUF to block for up to a full second
2) After evaluating various option I came to the conclusion that pwc should
stop using the v4l2 core locking, and instead do its own locking
Thus this patch stops pwc using the v4l2 core locking, and replaces that with
it doing its own locking where necessary.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently auto white balance speed and delay are only available through custom
ioctls, which are deprecated and will be going away in 3.3 .
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a preperation patch for adding support for control events. Actually
enabling support for control events will be done in a separate patch, as that
depends on the necessary poll changes going upstream
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Somehow the code has ended up assuming 1400 packets/sec which of course
is wrong for usb1 devices like the ov511 cameras. usb1 only does 1000
(isoc) packets / sec.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This got broken by some gscpa core fixes, this patch restores the proper
min/max values for these controls.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Written by Theodore Kilgore
With minor changes by Hans de Goede:
-Code style fixes
-Correct the verbose level on various PDEBUG messages
-Make error messages use pr_err instead of PDEBUG
-Document the jl20 pixel format
Signed-off-by: Theodore Kilgore <kilgota@auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* tag 'v3.2': (83 commits)
Linux 3.2
minixfs: misplaced checks lead to dentry leak
ptrace: ensure JOBCTL_STOP_SIGMASK is not zero after detach
ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD->EXIT_ZOMBIE race
Revert "rtc: Expire alarms after the time is set."
[CIFS] default ntlmv2 for cifs mount delayed to 3.3
cifs: fix bad buffer length check in coalesce_t2
Revert "rtc: Disable the alarm in the hardware"
hung_task: fix false positive during vfork
security: Fix security_old_inode_init_security() when CONFIG_SECURITY is not set
fix CAN MAINTAINERS SCM tree type
mwifiex: fix crash during simultaneous scan and connect
b43: fix regression in PIO case
ath9k: Fix kernel panic in AR2427 in AP mode
CAN MAINTAINERS update
net: fsl: fec: fix build for mx23-only kernel
sch_qfq: fix overflow in qfq_update_start()
drm/radeon/kms/atom: fix possible segfault in pm setup
gspca: Fix falling back to lower isoc alt settings
futex: Fix uninterruptible loop due to gate_area
...
This patch implements necessary changes for enabling dm365 and
dm355 hardware for vpbe. The patch contains additional HD mode
support for dm365 (720p60, 1080i30) and appropriate register
modifications based on version numbers.
VPBE_VERSION_2 = dm365 specific
VPBE_VERSION_3 = dm355 specific
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add OSD block changes to enable dm365 and dm355 for vpbe driver.
Changes are based on version number of OSD, which have incremental
changes over 644x OSD hardware interms of few registers.
VPBE_VERSION_2 = dm365 specific
VPBE_VERSION_3 = dm355 specific
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements the core additions to the display driver,
mainly controlling the VENC and other encoders for dm365.
This patch also includes addition of amplifier subdevice to the
vpbe driver and interfacing with venc subdevice.
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When using the SN9C20X_I420 fmt the sn9c20x needs more bandwidth
than our regular bandwidth calculations reserve.
This patch adds a sd_isoc_init function, which forces the use of a specific
altsetting when using the SN9C20X_I420 fmt.
This fixes the bottom 10-30% of the image getting corrupted when using
the SN9C20X_I420 fmt (which is the default fmt).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some cameras will pretty much entirely fill all the image buffers all the
time even though they are using compression.
This patch adds a flag to sd_desc, which drivers for such cameras can set.
When this flag is set the bandwidth calculation code will no longer
assume that the image buffer size is a worst case and less bandwidth than
imagebufsize * fps will be used on average.
This patch sets this new flag for 3 drivers:
* For spca561 (for rev12a cameras) and nw80x cams as these simply don't work
when given less bandwidth than imagebufsize * fps.
* For sn9c20x cameras, because these show severy jpeg artifacts when
given less bandwidth than imagebufsize * fps and since these are usb2
cameras there is plenty bandwidth anyways.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Quoting from the official usb 20 spec:
"5.6.4 Isochronous Transfer Bus Access Constraints
Isochronous transfers can only be used by full-speed and high-speed devices."
This means that for code paths which are isoc mode only, we don't need to
check for the device being low speed, simplifying the code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Check dev->actconfig rather than dev->config when checking various
configuration things. dev->config points to the array of configs for the
device so dev->config->foo boils down to dev->config[0].foo and the first
config is not necessarily always the active config.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In case we ever get sub drivers which do 7.5 fps and express this as
15 / 2 fps.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The calculated bandwidth should not be multiplied by the interval, but be
divided by it. Also bInterbval should be interpreted as a power of 2
for isochronous endpoints.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After the "gspca: Fix bulk mode cameras no longer working (regression fix)"
patch build_ep_tb is no longer being called for bulk endpoints.
This patch renames build_ep_tb to build_isoc_ep_tb to make clear it should
only be called for isoc mode cameras.
This patch also:
- drops the no longer needed xfer parameter
- removes a check for bulk mode from the build_isoc_ep_tb code
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Having:
- a mean image size of 0.375 time the max compressed image size and
- a frame rate of 30 fps for small images or with USB 2.0/3.0
seems more realistic and gives less image freezes.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This path add support to "OmniVision Technologies, Inc. VEHO Filmscanner".
Signed-off-by: Jose Alberto Reguero <jareguero@telefonica.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix detection of EMP202 audio chip. Some versions have an id of
0x83847650 instead of 0xffffffff
Honestech Vidbox NW03 has a EMP202 audio chip with a different Vendor ID.
Apparently, it is the same with the Gadmei ITV380:
http://linuxtv.org/wiki/index.php/Gadmei_USB_TVBox_UTV380
Signed-off-by: Gareth Williams <gareth@garethwilliams.me.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of creating two DVB frontend entries for the same device,
create just one entry, and fill the delivery_system according with
the supported standards.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
