The cell's platform_data is now accessed with a helper function;
change clients to use that, and remove the now-unused data_size.
Note that the mfd's platform_data is marked __devinitdata. This
is still correct in all cases except for the timbgpio driver, whose
remove hook has been changed to no longer reference the pdata.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
dma_addr_t may not fit into void* on some architectures. To be safe, make
vb2_dma_contig_cookie() return a pointer to dma_addr_t and dereference it
in vb2_dma_contig_plane_paddr() back to dma_addr_t.
Signed-off-by: Pawel Osciak <pawel@osciak.com>
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use vb2_dma_contig_plane_paddr to retrieve a physical address for a plane
instead of calling an internal mem_ops callback.
Signed-off-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The soc-camera core accesses the "pix" member of the struct v4l2_format::fmt
union, which is only valid for V4L2_BUF_TYPE_VIDEO_CAPTURE streams. This
patch adds explicit checks for this to {g,s,try}_fmt methods.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This fixes the problem in which a host driver
sets a personalized sizeimage or bytesperline field,
and gets ignored when doing G_FMT.
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Apple and TiVo remotes I've got use an NEC-ish protocol, but rather
than a command/not_command pair, they have what appear to be vendor ID
bytes. This change makes the NEC decoder warn if the command/not_command
checksum fails, but then passes along a full 32-bit scancode for keymap
lookup. This change should make no difference for existing keymaps,
since they simply won't have 32-bit scancodes, but allows for a 32-bit
keymap. At the moment, that'll have to be uploaded by the user, but I've
got Apple and TiVo remote keymaps forthcoming.
In the long run (2.6.40, hopefully), we should probably just always use
all 32 bits for all NEC keymaps, but this should get us by for 2.6.39.
(Note that a few of the TiVo keys actuallly *do* pass the command
checksum, so for now, the keymap for this remote will have to be a mix
of 24-bit and 32-bit scancodes, but so be it).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The hdpvr's IR part, in short, sucks. As observed with a usb traffic
sniffer, the Windows software for it uses a polling interval of 405ms.
Its still not behaving as well as I'd like even with this change, but
this inches us closer and closer to that point...
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The new hauppauge key tables use both device code button code.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This keymap were used for the Hauppauge Black remote controller
only. It also contains some keycodes not found there. As the
Hauppauge Black is now part of the hauppauge keymap, just remove
it.
Also, remove the modprobe hacks to select between the Gray
and the Black versions of the remote controller as:
- Both are supported by default by the keymap;
- If the user just wants one keyboard supported,
it is just a matter of changing the keymap via
the userspace tool (ir-keytable), removing
the keys that he doesn't desire. As ir-keytable
auto-loads the keys via udev, this is better than
obscure modprobe parameters.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
The rc-hauppauge-new map is a messy thing, as it bundles 3
different remote controllers as if they were just one,
discarding the address byte. Also, some key maps are wrong.
With the conversion to the new rc-core, it is likely that
most of the devices won't be working properly, as the i2c
driver and the raw decoders are now providing 16 bits for
the remote, instead of just 8.
delete mode 100644 drivers/media/rc/keymaps/rc-hauppauge-new.c
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
There are two "hauppauge-new" keymaps, one with protocol
unknown, and the other with the protocol marked accordingly.
However, both tables are miss-named.
Also, the old rc-hauppauge-new is broken, as it mixes
three different controllers as if they were just one.
This patch solves half of the problem by renaming the
correct keycode table as just rc-hauppauge. This table
contains the codes for the four different types of
remote controllers found on Hauppauge cards, properly
mapped with their different addresses.
create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c
delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c
[Jarod: fix up RC_MAP_HAUPPAUGE defines]
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
The keys for the old black were messed with the ones for the
hauppauge grey. Fix it.
Also, fixes some keycodes and order the keys according with
the way they appear inside the remote controller.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Hans borrowed me an old Black Hauppauge RC. Thanks to that, we
can fix the RC5 table for Hauppauge.
Thanks-to: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Adds the old grey remote controller to Hauppauge table.
Hans borrowed me an old gray Hauppauge RC. Thanks to that, we
can fix the RC5 table for Hauppauge.
Thanks-to: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
One of the remotes has a picture available at:
http://lirc.sourceforge.net/remotes/leadtek/Y04G0004.jpg
As there's one variant with a set direction keys plus vol/chann
keys, and the same table is used for both models, change it to
represent all keys, avoiding the usage of weird function keys.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
This driver uses an app-specific keymap for one of the tables. This
is wrong. Instead, use the standard keycodes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
This driver uses an app-specific keymap for one of the tables. This
is wrong. Instead, use the standard keycodes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Using xev and testing the "Windows" key on a normal keyboard, it
is mapped as KEY_LEFTMETA. So, as this is the standard code for
it, use it, instead of a generic, meaningless KEY_PROG1.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Those KEY_PROG[n] keys were used on places where the developer
didn't know for sure what key should be used. On several cases,
using KEY_RED, KEY_GREEN, KEY_YELLOW would be enough. On others,
there are specific keys for that already.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Each keyboard map were using a different definition for
the Source/Video Source key.
Behold Columbus were the only one using KEY_PROPS.
As we want to standardize those keys at X11 and at
userspace applications, we need to use just one code
for it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
On a few places, KEY_MHP were used for snapshots. However, KEY_CAMERA
is used for it on all the other keyboards that have a snapshot/Picture
button.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Make the hdpvr's i2c master implementation more closely mirror that of
the pvrusb2 driver. Currently makes no significant difference in IR
reception behavior with ir-kbd-i2c (i.e., it still sucks).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Juan J. Garcia de Soria <skandalfo@gmail.com>
Cc: Stephan Raue <stephan@openelec.tv>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a second version of an rc-core based driver for the ITE Tech IT8712F
CIR and now for a pair of other variants of the IT8512 CIR too.
This driver should replace the lirc_it87 and lirc_ite8709 currently living in
the LIRC staging directory.
The driver should support the ITE8704, ITE8713, ITE8708 and ITE8709 (this last
one yet untested) PNP ID's.
The code doesn'te reuse code from the pre-existing LIRC drivers, but has been
written from scratch using the nuvoton.cir driver as a skeleton.
This new driver shouldn't exhibit timing problems when running under load (or
with interrupts disabled for relatively long times). It works OOTB with the
RC6 MCE remote bundled with the ASUS EEEBox. TX support is implemented, but
I'm unable to test it since my hardware lacks TX capability.
Signed-off-by: Juan J. Garcia de Soria <skandalfo@gmail.com>
Tested-by: Stephan Raue <stephan@openelec.tv>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As the code in saa7134-input is not a module, but the config for it is
set as a boolean instead of a tristate, this causes a strange dependency
on RC_CORE.
VIDEO_SAA7134_RC (which determines if saa7134-input.o is built) depends
on RC_CORE and VIDEO_SAA7134. If VIDEO_SAA7134 is compiled as 'y' but
RC_CORE is compiled as 'm' VIDEO_SAA7134_RC can still be set to 'y'
which causes undefined symbols that it needs from RC_CORE.
The simplest solution is to not allow VIDEO_SAA7134_RC be enabled if
RC_CORE compiled as a module (m) and VIDEO_SA7134 is compiled into the
kernel (y).
Suggested-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kbuild <linux-kbuild@vger.kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes a bug in gspca, more precisely in alt_xfer().
This function looks for an input transfer endpoint in an alternate setting.
By default it returns the first endpoint corresponding to the transfer type
indicated in parameter.
But with some USB devices, the first endpoint corresponding to the transfer
type is not always an INPUT endpoint but an OUTPUT one.
This patch adds the endpoint direction test to be sure to return an INPUT endpoint
Signed-off-by: Patrice CHOTARD <patricechotard@free.fr>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
No 352x288 for Ds3303 and no 320x240 for Generic802.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rather than guess which driver supports core priority handling, require drivers
that do to explicitly set the V4L2_FL_USE_FH_PRIO flag in video_device.
Updated the core prio handling accordingly and set the flag in the three
drivers that do.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
ivtv-ioctl cast the 'void *fh' directly to 'ivtv_open_id *'. This should be
done properly with a contained_of since the 'void *fh' is really a
'struct v4l2_fh *'.
It worked because the v4l2_fh field is also the first field in the ivtv_open_id
struct, but it is not clean code.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use core-assisted locking so .ioctl can be replaced by .unlocked_ioctl.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The video_device struct has proper ref counting and its release function
will be called when the last user releases it. But no such support was
available for struct v4l2_device. This made it hard to determine when a
USB driver can release the device if it has multiple device nodes.
With one device node it is easy of course, since when the device node is
released, the whole device can be released.
This patch adds refcounting to v4l2_device. When registering device nodes
the v4l2_device refcount will be increased, when releasing device nodes
it will be decreased. The (optional) release function will be called when
the last device node was released.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
VIDIOC_S/G_PRIORITY handling is now done by the v4l2 core framework.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Drivers that use v4l2_fh can now use the core framework support of g/s_priority.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Several drivers need to do something when the first filehandle is opened
or the last filehandle is closed. Most implement some use count mechanism,
but if they use v4l2_fh, then you can also just check if this is the only
filehandle for the device node. A simple helper function can do this.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add two new functions: v4l2_fh_open allocates and initializes a struct v4l2_fh
based on a struct file pointer and v4l2_fh_release releases and frees a struct
v4l2_fh.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Integrate the v4l2_prio_state into the core, ready for use.
One struct v4l2_prio_state is added to v4l2_device and a pointer
to a prio state is added to video_device.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We are going to move priority handling into the v4l2 core. As a consequence
the v4l2_prio helper functions need to be moved into the core videodev
module as well to prevent circular dependencies.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On my AverMedia AverTV Studio 507, key up events are no longer sent after
a suspend-to-disk/resume cycle, resulting in "stuck" keys.
Apparently, for key up events to be generated, a certain GPIO pin must be set.
Currently it's set in saa7134_input_init1(), but that function is not called
on device resume. I suggest that code be moved to __saa7134_ir_start(), which
is called both on init and resume.
Signed-off-by: Vadim Solomin <vadic052@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The CellsCoeffs arrays are [3][6][5] not [2][6][5].
Signed-off-by: Dan Carpenter <error27@gmail.com>
Cc: Igor M. Liplianin <liplianin@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We use err to store negative error codes so it should be signed. And
if we return an error from stv0367_get_tuner_freq() that needs to be
handled properly as well. (param->frequency is a u32).
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The code that checks the OLPC serial port is never built at the moment,
because CONFIG_OLPC_XO_1_5 doesn't exist and probably won't be added.
Fix it so that it gets compiled in, only executes on OLPC laptops, and
move the check into the probe routine.
The compiler is smart enough to eliminate this code when CONFIG_OLPC=n
(due to machine_is_olpc() always returning false).
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
These bubble button remote controls appear to be generic from China.
These are the three variants known to be supplied with DM04/QQBOX DVB-S
They could well be supplied with other devices from the region.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use 32 bit decoding to add support for more than one variant of remote
control.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Old versions of these boxes have the BS2F7HZ0194 tuner module on
both the LME2510 and LME2510C.
Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw
files are required.
See Documentation/dvb/lmedm04.txt
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Error path in file drivers/media/video/tlg2300/pd-video.c:
1. First mutex_unlock on &pd->lock in line 767 (in function that
called from line 805)
2. Second in line 806
805 pd_vidioc_s_fmt(pd, &f->fmt.pix);
806 mutex_unlock(&pd->lock);
Found by Linux Device Drivers Verification Project
Signed-off-by: Alexander Strakh <strakh@ispras.ru>
Acked-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
wl1273_device->work is unused. Remove it along with the spurious
flush_scheduled_work() call in wl1273_fm_module_exit().
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Matti Aaltonen <matti.j.aaltonen@nokia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On Thu, 17 Feb 2011, Matthias Schwarzott wrote:
> On Sunday 06 February 2011, Jesper Juhl wrote:
> > If the memory allocation to 'state' succeeds but we jump to the 'error'
> > label before 'state' is assigned to fe->tuner_priv, then the call to
> > 'zl10036_release(fe)' at the 'error:' label will not free 'state', but
> > only what was previously assigned to 'tuner_priv', thus leaking the memory
> > allocated to 'state'.
> > There are may ways to fix this, including assigning the allocated memory
> > directly to 'fe->tuner_priv', but I did not go for that since the
> > additional pointer derefs are more expensive than the local variable, so I
> > just added a 'kfree(state)' call. I guess the call to 'zl10036_release'
> > might not even be needed in this case, but I wasn't sure, so I left it in.
> >
> Yeah, that call to zl10036_release can be completely eleminated.
> Another thing is: jumping to the error label only makes sense when memory was
> already allocated. So the jump in line 471 can be replaced by "return NULL",
> as the other error handling before allocation:
> if (NULL == config) {
> printk(KERN_ERR "%s: no config specified", __func__);
> goto error;
> }
>
> I suggest to improve the patch to clean the code up when changing that.
>
> But I am fine with commiting this patch also if you do not want to change it.
>
Thank you for your feedback. It makes a lot of sense.
Changing it is not a problem :)
How about the updated patch below?
If the memory allocation to 'state' succeeds but we jump to the 'error'
label before 'state' is assigned to fe->tuner_priv, then the call to
'zl10036_release(fe)' at the 'error:' label will not free 'state', but
only what was previously assigned to 'tuner_priv', thus leaking the memory
allocated to 'state'.
This patch fixes the leak and also does not jump to 'error:' before mem
has been allocated but instead just returns. Also some small style
cleanups.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Matthias Schwarzott <zzam@gentoo.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
mem->dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU, as
a hardware IOMMU can (and most likely) will return a bus address where
physical != bus address.
So ensure we are remapping (remap_pfn_range) the right page in
__videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not
mem->dma_handle.
While at it, use PFN_DOWN instead of explicit shift.
[mchehab@redhat.com: Fix compilation breakage due to the lack of a comma]
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The scheme used to index format in uvc_fixup_video_ctrl() is not robust:
format index is based on descriptor ordering, which does not necessarily
match bFormatIndex ordering. Searching for first matching format will
prevent uvc_fixup_video_ctrl() from using the wrong format/frame to make
adjustments.
Signed-off-by: Stephan Lachowsky <stephan.lachowsky@maxim-ic.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Split FW download packages smarter way and bug free. Implementation is
based of Andrea Merello's example he provided for tda18218 driver.
Count remaining FW bytes down in loop instead of division and modulo
combination used earlier.
Thanks to: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Cc: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Quick test shows that FW must be running before other checks
so make it happen earlier.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Split FW download packages smarter way and bug free. Implementation is
based of Andrea Merello's example he provided for tda18218 driver.
Count remaining FW bytes down in loop instead of division and modulo
combination used earlier.
Thanks-to: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Cc: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remote used for TerraTec Cinergy T Stick RC.
Keytable from Martin Groszhauser <mgroszhauser@gmail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Cc: Martin Groszhauser <mgroszhauser@gmail.com>
Cc: TerraTux <TerraTux@terratec.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Patch from Ian Armstrong.
I've encountered a couple of problems with the current af9015 driver as
supplied with the 2.6.37 kernel, that the attached patch appears to fix. (I've
generated this patch against the current v4l-dvb git).
Some key-presses are lost. A key-press is only generated upon 'valid' data
(buf[14] == (u8) ~buf[15]), but the buffer is wiped before this check.
Sometimes the 15th byte has not been set at the time of read, so the data
isn't valid & ignored. On the next poll the 15th byte has been set, but the
rest of the data was wiped previously, so the data is still invalid & the key
is lost.
Weird repeat error, where an old key press is sometimes repeated in error. ie.
button sequence '1 (pause) 2 (pause) 3 (pause) 4' generates output like '1
(pause) 2 (pause) 23 (pause) 4'. The current driver zeroes the data for the
key pushed, but sometimes this data is already zero but with other bytes set
suggesting a repeat code. This results in the last key being incorrectly
repeated.
This patch attempts to reduce the risk of a missed key-press & also stop the
random repeat of an old key-press when a new key is pressed.
Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This file contains functions for the auto gain.
It must be used with the new control mechanism.
Acked-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>
Not only the qx3 microscope has a button, but some cameras too. Tested
with the Trust sp@cecam 100 (and with a creative and ezcam without button).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
allows the driver to proceed and initialize the below two values
even if the kmalloc() fails.
hdw->std_info_enum.def.type_enum.value_names
hdw->std_info_enum.def.type_enum.count
Signed-off-by: Xiaochen Wang <wangxiaochen0@gmail.com>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This was caught via a compiler warning. Amazingly enough this bit of
benign dreck dates all the way back to 2008.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Memory allocated by alloc_page() function might contain some potentially
important data from other system processes. The patch adds a flag to
zero the allocated page before giving it to videobuf2 (and then to
userspace).
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
__vb2_queue_free function doesn't really return anything useful. This patch
removes support for the return value to simplify the code.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Return immediately if the target number of buffers is the same as
the current one and memory access type doesn't change.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes two minor memory leaks in videobuf2-dma-sg module. They
might happen only in case some other operations (like memory allocation)
failed.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes 2 minor bugs in videobuf2 core:
1. Queue should be reallocated if one change the memory access
method without changing the number of buffers.
2. In case of REQBUFS(0), the request should not be passed to the
driver.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use pix_mp member of struct v4l2_format to return a format
description rather than pix. Also fill in the plane_fmt array.
This is a missing bit of conversion to the multiplanar API.
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>
Use pr_debug instead of printk so it is possible to control
debug traces at runtime.
E.g. to enable debug trace in file fimc-core.c use command:
echo -n 'file fimc-core.c +p' > /sys/kernel/debug/dynamic_debug/control
or
echo -n 'file fimc-core.c -p' > /sys/kernel/debug/dynamic_debug/control
to disable.
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>
