With hardware that has to use ir_raw_event_store_edge to collect IR
sample durations, we were not doing an event reset unless
IR_MAX_DURATION had passed. That's around 4 seconds. So if someone
presses up, then down, with less than 4 seconds in between, they'd get
the initial up, then up and down upon pressing down.

To fix this, I've lowered the "send a reset event" logic's threshold to
the input device's REP_DELAY (defaults to 500ms), and with an
saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get
*much* better behavior out of the remote now. Special thanks to Devin
for providing the hardware to investigate this issue.

CC: stable@kernel.org
CC: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There's really no good reason not to just grab the desired IRQ at driver
init time, instead of every time the lirc device node is accessed. This
also improves the speed and reliability with which a serial transmitter
can operate, as back-to-back transmission attempts (i.e., channel change
to a multi-digit channel) don't have to spend time acquiring and then
releasing the IRQ for every digit, sometimes multiple times, if lircd
has been told to use the min_repeat parameter.

CC: devel@driverdev.osuosl.org
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced in
commit 5bd6b046, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included in,
but alas, stuff happens...
Acked-by: NAndy Walls <awalls@md.metrocast.net>
CC: stable@kernel.org
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Both consumers of RC_MAP_PINNACLE_PCTV_HD send along full RC-5
scancodes, so this update makes this keymap actually *have* full
scancodes, heisted from rc-dib0700-rc5.c. This should fix out of the box
remote functionality for the Pinnacle PCTV HD 800i (cx88 pci card) and
PCTV HD Pro 801e (em28xx usb stick).

CC: stable@kernel.org
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to the intrepid testing and debugging of Matthijs van Drunen, it
was uncovered that at least some variants of the ITE8709 need to use pnp
resource 2, rather than 0, for things to function properly. Resource 0
has a length of only 1, and if you try to bypass the pnp_port_len check
and use it anyway (with either a length of 1 or 2), the system in
question's trackpad ceased to function.

The circa lirc 0.8.7 lirc_ite8709 driver used resource 2, but the value
was (amusingly) changed to 0 by way of a patch from ITE themselves, so I
don't know if there may be variants where 0 actually *is* correct, but
at least in this case and in the original lirc_ite8709 driver author's
case, it sure looks like 2 is the right value.

This fix should probably be applied to all stable kernels with the
ite-cir driver, lest we nuke more people's trackpads.

Tested-by: Matthijs van Drunen
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
CC: stable@kernel.org
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

mx1_camera_add_device() can return an uninitialized value of ret.
Signed-off-by: NAndre Bartke <andre.bartke@gmail.com>
[g.liakhovetski@gmx.de: modified the fix to remove "ret" completely]
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The usecase where, user allocates small size of buffer
through bootargs (video1_bufsize/video2_bufsize) and later from application
tries to set the format which requires larger buffer size, driver doesn't
check for insufficient buffer size and allows application to map extra buffer.
This leads to kernel crash, when user application tries to access memory
beyond the allocation size.

Added check in both mmap and reqbuf call back function,
and return error if the size of the buffer allocated by user through
bootargs is less than the S_FMT size.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With addition of media-controller framework, now we have various
device nodes (/dev/videoX) getting created, so hardcoding
minor number in video_register_device() is not recommended.

So let V4L2 framework choose free minor number for the device.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The omap_vout_new_crop() function has possible bug, uses uninitialized
variable "crop.width/height" which is actually output of the function.
Instead we should be using "try_crop.width/height" to calculate the
resizer value.
Signed-off-by: NVladimir Pantelic <vladoman@gmail.com>
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When failing to start the camera we should disable the queue again, to
rollback into the same initial state. Otherwise re-trying will always
hit -EBUSY
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When freeing memory for the video buffers also remove them from the
irq & main queues.

This fixes an oops when doing the following:

open ("/dev/video", ..)
VIDIOC_REQBUFS
VIDIOC_QBUF
VIDIOC_REQBUFS
close ()

As the second VIDIOC_REQBUFS will cause the list entries of the buffers
to be cleared while they still hang around on the main and irc queues
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If a streaming interface has no supported format, the driver won't
create a video device for the associated terminal. Fix an oops by
ignoring that terminal when creating links between entities.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Entities associated with video device nodes are unregistered in
video_unregister_device(). This destroys the entity even though it can
still be accessed through open video device nodes.

Move the media_device_unregister_entity() call from
video_unregister_device() to v4l2_device_release() to ensure that the
entity isn't unregistered until the last reference to the video device
is released.

Also remove the media_entity_get()/put() calls from v4l2-dev.c. Those
functions were designed for subdevs, to avoid a parent module from being
removed while still accessible through board code. They're not currently
needed for video device nodes, and will oops when a hotpluggable device
is disconnected during streaming, as media_entity_put() called in
v4l2_device_release() tries to access entity->parent->dev->driver which
is set to NULL when the device is disconnected.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix a potential NULL pointer dereference by skipping registration of
external entities in case none are provided.

This is useful at least when testing mere memory-to-memory scenarios.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

__vb2_queue_alloc function returns the number of successfully allocated
buffers. There is no point in checking if the returned value is negative.
If this function returns 0, videobuf2 should just return -ENOMEM to
userspace, because no driver can work without memory buffers.
Reported-by: NJonathan Corbet <corbet@lwn.net>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

queued_count variable was left untouched during the queue reinitialization
in __vb2_queue_cancel, what might lead to mismatch between the real number
of queued buffers and queued_count variable.
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This reverts commit 31901a07.

Queue should be reinitialized on each REQBUFS() call even if the memory
access method and buffer count have not been changed. The user might have
changed the format and if we go the short path introduced in that commit,
the memory buffer will not be reallocated to fit with new format.

The previous patch was just over-engineered optimization, which just
introduced a bug to videobuf2.
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add __GFP_NOWARN parameter to videobuf2 dma-sg allocator to prevent
kernel warning and stack dump if there is not enough memory available.
Videobuf2 and drivers should correctly handle no memory case, so there
is no need for stack dump and extensive log.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Unplugging a pwc cam while an app has the /dev/video# node open leads
to an oops in pwc_video_close when the app closes the node, because
the disconnect handler has free-ed the pdev struct pwc_video_close
tries to use. Instead of adding some sort of bandaid for this.
fix it properly using the v4l2 core's new(ish) behavior of keeping the
v4l2_dev structure around until both unregister has been called, and
all file handles referring  to it have been closed:

Embed the v4l2_dev structure in the pdev structure and define a v4l2 dev
release callback releasing the pdev structure (and thus also the embedded
v4l2 dev structure.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add maintainers for the videobuf2 V4L2 driver framework.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHeungJun, Kim <riverful.kim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove union version in the m5mols_get_version(), and read version information
directly. Also remove VERSION_SIZE.
Signed-off-by: NHeungJun, Kim <riverful.kim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

For now, the m5mols_read() share in case of I2C packet 1, 2, 4 byte(s) width.
So, this commit adds 3 functions - m5mols_read_u8/u16/u32() according to byte
width of I2C packet. And, the u32 variables in spite of u8 or u16 for fitting
to m5mols_read() having no choice, is replaced to have original byte width
like u8, u16, u32 as same reason.
Signed-off-by: NHeungJun, Kim <riverful.kim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The main capture and the thumbnail image size registers were
erroneously defined to have 1 byte width, resulting in wrong
reported image size. Fix this by changing the registers width
to correct value.
Reported-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHeungJun, Kim <riverful.kim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With multi-planar formats fmt.pix_mp member of struct v4l2_format
should be used rather than fmt.pix. Fix find_fmt() function to do
the right thing.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The buf_init buffer queue operation is optional and
buffer_init() does nothing, remove it.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Avoid dereferencing of NULL f->fmt. Correct size of the allocated
buffer in case the crop rectangle is smaller than the bounds
rectangle (configured with S_FMT). Also remove redundant check
for *num_buffer == 0 as this case is handled in videobuf2.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Correct inconsistencies in data structures' documentation.
Remove meaningless debug traces.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove V4L2_MBUS_FMT_RGB565_2X8_BE media code entry as
camera interface supports only packed YUYV formats.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add missing kfree on the error path.
Reported-by: NTomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As pointed out on the lirc list by Andreas Dick, initial panel key
repeat suppression wasn't working, as we had no timevals accumulated
until after the first repeat. Also add a missing locking call.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Courtesy of information from Andreas Dick on the lirc list.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Hans Petter Selasky pointed out to me that we're leaking urbs when
mce_async_out is called. Its used both for configuring the hardware and
for transmitting IR data. In the tx case, mce_request_packet actually
allocates both a urb and the transfer buffer, neither of which was being
torn down. Do that in the tx callback.

CC: Hans Petter Selasky <hselasky@c2i.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There was a missing lock in fintek_suspend. Without the lock, its
possible the system will be in the middle of receiving IR (draining the
RX buffer) when we try to disable CIR interrupts.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Store the cdev pointer in struct irctl, allocated dynamically as needed,
rather than having a static array. At the same time, recycle some of the
saved memory to nudge the maximum number of lirc devices supported up a
ways -- its not that uncommon these days, now that we have the rc-core
lirc bridge driver, to see a system with at least 4 raw IR receivers.
(consider a mythtv backend with several video capture devices and the
possible need for IR transmit hardware).
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Aside from the initial "hey, lets make sure we've flushed any
pre-existing data on the device" call to mce_sync_in, every other one of
the calls was entirely superfluous. Ergo, remove them all, and rename
the one and only (questionably) useful one to reflect what it really
does. Verified on both gen2 and gen3 hardware to make zero difference.
Well, except that you no longer get a bunch of urb submit failures from
the unneeded mce_sync_in calls. Oh. And move that flush to a point
*after* we've wired up the inbound urb, or it won't do squat. I have
half a mind to just remove it entirely, but someone thought it was
necessary at some point, and it doesn't seem to hurt, so lets leave it
for the time being.

This excercise took place due to insightful questions asked by Hans
Petter Selasky, about the possible reuse of the inbound urb before it
was actually availble by mce_sync_in, so thanks to him for motivating
this cleanup.
Reported-by: NHans Petter Selasky <hselasky@c2i.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>