- 20 Dec, 2010 21 commits
-
-
Jarod Wilson authored
Its possible for the call to read rx timeout from the hardware to fail, in which case we end up with a bogus rx timeout value. Set a default one when filling in the rc struct, and we'll just overwrite it later w/the value from hardware, but if that read fails, we've at least got a sane rx timeout value to work with (1000ms is the default value I've seen returned on most if not all mceusb hardware). Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jarod Wilson authored
As it turns out, somewhere along the way, we managed to invert the meaning of the tx_mask_inverted flag. Looking back over the old lirc driver, tx_mask_inverted was set to 0 if the device was in tx_mask_list. Now we have a tx_mask_inverted flag set to 1 for all the devices that were in the list, and set tx_mask_inverted to that flag value, which is actually the opposite of what we used to set, causing set_tx_mask to use the wrong mask setting option. Since there seem to be more devices with inverted masks than not (using the original device as the baseline for inverted vs. normal), lets just call the ones currently marked as inverted normal instead, and flip the if/else actions that key off of the inverted flag. Note: the problem only cropped up if a call to set_tx_mask was made, if no mask was set, the device would work just fine, which is why this managed to slip though w/o getting noticed until now. Tested successfully by myself and Dennis Gilmore. Reported-by:
Dennis Gilmore <dgilmore@redhat.com> Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Dan Carpenter authored
This makes several changes but they're in one function and sort of related: "buf" was leaked on error. The leak if we try to read an invalid length is the main concern because it could be triggered over and over. If the copy_to_user() failed, then the original code returned the number of bytes remaining. read() is supposed to be the opposite way, where we return the number of bytes copied. I changed it to just return -EFAULT on errors. Also I changed the debug output from "-EFAULT" to just "<fail>" because it isn't -EFAULT necessarily. And since we go though that path if the length is invalid now, there was another debug print that I removed. Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
-
Dan Carpenter authored
We shouldn't unlock here. I think this was a cut and paste error. Signed-off-by:
-
Paul Bender authored
When trying to create persistent device names for mceusb and streamzap devices, I noticed that their respective drivers are not creating the rc device as a child of the USB device. Rather it creates it as virtual device. As a result, udev cannot use the USB device information to create persistent device names for event and lirc devices associated with the rc device. Not having persistent device names makes it more difficult to make use of the devices in userspace as their names can change. Signed-off-by:
Paul Bender <pebender@gmail.com> Signed-off-by:
-
Jarod Wilson authored
There are cases where we get an ending space, and our trailing timeout space then gets sent right after it, which breaks repeat, at least for lirc userspace decoding. Merge the two spaces by way of using ir_raw_event_store_filter, set a timeout value, and we're back to good. Successfully tested with streamzap and windows mce remotes. Signed-off-by:
-
Jarod Wilson authored
Something I failed to notice while testing the mceusb RLE buffer decoding simplification patches was that we were getting an extra event from the previously pressed key. As was pointed out to me on irc by Maxim, this is actually due to using ir_raw_event_store_with_filter without having set up a timeout value. The hardware has a timeout value we're now reading and storing, which properly enables the transition to idle in the raw event storage process, and makes IR decode behave correctly w/o keybounce. Also remove no-longer-used ir_raw_event struct from mceusb_dev struct and add as-yet-unused enable flags for carrier reports and learning mode, which I'll hopefully start wiring up sooner than later. While looking into that, found evidence that 0x9f 0x15 responses are only non-zero when the short-range learning sensor is used, so correct the debug spew message, and then suppress it when using the standard long-range sensor. Signed-off-by:
-
Jarod Wilson authored
And clean up some stray spaces. Signed-off-by:
-
Jarod Wilson authored
If we pass in an offset, we shouldn't skip 2 bytes. And the first-gen hardware generates a constant stream of interrupts, always with two header bytes, and if there's been no IR, with nothing else. Bail from ir processing without calling ir_handle_raw_event when we get such a buffer delivered to us. Signed-off-by:
-
Jarod Wilson authored
We were storing a bunch of spaces at the end of each signal, rather than a single long space. The in-kernel decoders were actually okay with this, but lirc isn't. As suggested by David Härdeman, switch to storing samples using ir_raw_event_store_with_filter, which auto-merges the consecutive space samples for us. This also allows us to bypass having to store rawir samples in our device struct, further simplifying the buffer parsing state machine. Both in-kernel decoders and lirc are happy again with this change. Also included in this patch is proper parsing of 0x9f 0x01 commands, the removal of some magic number usage and some printk spew fixups. Signed-off-by:
-
Jarod Wilson authored
Rather than waiting for trigger bits, the formula for which was slightly messy, and apparently, not actually 100% complete for some remotes, just call ir_raw_event_handle whenever we finish parsing a chunk of data from the rx fifo, similar to mceusb, as well as whenever we see an 'end of signal data' 0x80 packet. Signed-off-by:
-
Jarod Wilson authored
Another multi-function Conexant device. Interface 0 is IR, though on this model, TX isn't wired up at all, so I've mixed in support for models without TX (and verified that lircd says TX isn't supported when trying to send w/this device). Signed-off-by:
-
Sylwester Nawrocki authored
FIMC IP in S5Pv310 series has extended DMA status registers and some bit fields are marked as reserved comparing to S5PC100/110. Use correct registers for getting DMA write pointer in each SoC variant supported by the driver. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
Sylwester Nawrocki authored
Replace V4L2_PIX_FMT_RGB24 code with V4L2_PIX_FMT_RGB32 since the hardware uses 24-bits for actual pixel data but pixels are 4-byte aligned in memory. Signed-off-by:
-
Sylwester Nawrocki authored
Signed-off-by:
-
Sylwester Nawrocki authored
Reported by: Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Sylwester Nawrocki authored
Create separate vidioc_g_crop/vidioc_s_crop handlers for capture video node and so image cropping parameters are properly queried at FIMC input (image sensor) and not at FIMC output. Signed-off-by:
-
Sylwester Nawrocki authored
Adapt to recent videobuf_queue_dma_contig_init signature change. Signed-off-by:
-
Guennadi Liakhovetski authored
The test for driver->owner != NULL in sh_mobile_ceu_camera.c is unneeded and it breaks the static build of sh_mobile_csi2.c. Remove it. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Baruch Siach authored
When SOCAM_PCLK_SAMPLE_FALLING, just leave CSICR1_REDGE unset, otherwise we get the inverted behaviour. Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
-
- 17 Dec, 2010 8 commits
-
-
Jean-Francois Moine authored
The initial values of the registers 0x01 and 0x17 are taken from the sensor table at capture start and updated according to the flag PDN_INV. Their values are updated at each step of the capture initialization and memorized for reuse in capture stop. This patch also fixed automatically some bad hardcoded values of these registers. Signed-off-by:
Jean-François Moine <moinejf@free.fr> Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Jean-Francois Moine authored
The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same value as other webcams with the same sensor. For now, only two webcams have been so detected: the Microsoft's VX1000 and VX3000. Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Brandon Philips authored
After Mauro's "bttv: Fix locking issues due to BKL removal code" there are a number of comments that are no longer needed about lock ordering. Remove them. Signed-off-by:
Brandon Philips <bphilips@suse.de> Signed-off-by:
-
Mauro Carvalho Chehab authored
Fix a regression where bttv driver causes oopses when loading, since it were using some non-initialized mutexes. While it would be possible to fix the issue, there are some other lock troubles, like to the presence of lock code at free_btres_lock(). It is possible to fix, but the better is to just use the core-assisted locking schema. This way, V4L2 core will serialize access to all ioctl's/open/close/mmap/read/poll operations, avoiding to have two processes accessing the hardware at the same time. Also, as there's just one lock, instead of 3, there's no risk of dead locks. The net result is a cleaner code, with just one lock. Reported-by:
Chris Clayton <chris2553@googlemail.com> Reported-by:
Torsten Kaiser <just.for.lkml@googlemail.com> Tested-by:
-
- 02 Dec, 2010 1 commit
-
-
Mauro Carvalho Chehab authored
Drivers should append their name on exported symbols, to avoid conflicts with allyesconfig: drivers/staging/built-in.o: In function `format_by_fourcc': /home/v4l/work_trees/linus/drivers/staging/cx25821/cx25821-video.c:96: multiple definition of `format_by_fourcc' drivers/media/built-in.o:/home/v4l/work_trees/linus/drivers/media/common/saa7146_video.c:88: first defined here Let's rename both occurences with a small shellscript: for i in drivers/staging/cx25821/*.[ch]; do sed s,format_by_fourcc,cx25821_format_by_fourcc,g <$i >a && mv a $i; done for i in drivers/media/common/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g <$i >a && mv a $i; done for i in include/media/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g <$i >a && mv a $i; done Signed-off-by:
-
- 22 Nov, 2010 2 commits
-
-
Laurent Pinchart authored
The argument isn't used anymore by the functions, remove it. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
With the v4l2_i2c_new_subdev* functions now supporting loading modules based on modaliases, replace the hardcoded module name passed to those functions by NULL in the cafe-ccic, via-camera and s5p-fimc drivers. All corresponding I2C modules have been checked, and all of them include a module aliases table with names corresponding to what the drivers modified here use. Signed-off-by:
-
- 09 Nov, 2010 8 commits
-
-
Sascha Hauer authored
mx2-camera got broken during the last merge window. This patch fixes this and removes some unused variables. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Janusz Krzysztofik authored
This is a followup patch that addresses two minor issues left in the recently added ov6650 sensor driver, as I've promised to the subsystem maintainer: - remove a pair of extra brackets, - drop useless case for not possible v4l2_mbus_pixelcode enum value of 0. Created against linux-2.6.37-rc1. Signed-off-by:
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by:
-
Janusz Krzysztofik authored
Fix an outstanding typo in the recently added driver, as requested by the subsystem maintainer. Created against linux-2.6.37-rc1. Signed-off-by:
-
Janusz Krzysztofik authored
Recent locking related videobuf changes has not been incorporated into the new OMAP1 camera driver. Fix it. Created and tested against linux-2.6.37-rc1. Signed-off-by:
-
Janusz Krzysztofik authored
The recently added OMAP1 camera driver was not ready for one video queue per device framework changes. Fix it. Created and tested against linux-2.6.37-rc1. Signed-off-by:
-
Sascha Hauer authored
We have two dma engines in MX3 systems: The IPU and the SDMA engine. We have to check if we got a channel from the correct engine before proceeding with a channel. Signed-off-by:
-
Stefan Ringel authored
bugfix set tv standards Signed-off-by:
Stefan Ringel <stefan.ringel@arcor.de> Signed-off-by:
-
Daniel Drake authored
For some reason, commit 1aafeb30104a is missing one change that was included in the email submission. The sensor configuration must be passed down to the ov7670 subdev. Signed-off-by:
Daniel Drake <dsd@laptop.org> Signed-off-by:
-
