- 11 Mar, 2014 33 commits
-
-
Mauro Carvalho Chehab authored
As reported when compiled with W=1: drivers/media/dvb-frontends/drx39xyj/drxj.c: In function ‘ctrl_set_channel’: drivers/media/dvb-frontends/drx39xyj/drxj.c:10340:26: warning: variable ‘common_attr’ set but not used [-Wunused-but-set-variable] struct drx_common_attr *common_attr = NULL; ^ drivers/media/dvb-frontends/drx39xyj/drxj.c:10336:6: warning: variable ‘intermediate_freq’ set but not used [-Wunused-but-set-variable] s32 intermediate_freq = 0; Signed-off-by:Mauro Carvalho Chehab <m.chehab@samsung.com>
-
Mauro Carvalho Chehab authored
Fix a smatch warning: drivers/media/dvb-frontends/drx39xyj/drxj.c:11711 drx_ctrl_u_code() info: why not propagate 'rc' from request_firmware() instead of (-2)? Signed-off-by: -
Mauro Carvalho Chehab authored
This function is currently not used. However, it was meant to be called at device release. So, add it there. While here, remove the bad check, as reported by Dan, as smatch warning: drivers/media/dvb-frontends/drx39xyj/drxj.c:20041 drxj_close() warn: variable dereferenced before check 'demod' (see line 20036) Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
This driver doesn't export any external symbol, except for the attach() method. Signed-off-by: -
Mauro Carvalho Chehab authored
There are large chunks of code at drx-j that aren't used. Most of them are due to analog TV support. Well, just enabling them won't make analog support work, as devices with DRX and analog support requires an extra chip (avf4910). We don't have drivers for it, nor the current device that uses this frontend has support for analog TV. So, let's just get rid of this code. If latter needed, this patch can easily be reverted from git history. Signed-off-by: -
Mauro Carvalho Chehab authored
smatch warning: drivers/media/dvb-frontends/drx39xyj/drxj.c:20803 drx_ctrl_u_code() warn: variable dereferenced before check 'mc_info' (see line 20800) Reported-by:
-
Mauro Carvalho Chehab authored
As reported by the kbuild test robot <fengguang.wu@intel.com>: drivers/built-in.o: In function `em28xx_dvb_init': em28xx-dvb.c:(.text+0x876f2c): undefined reference to `drx39xxj_attach' That happens when CONFIG_VIDEO_EM28XX_DVB is selected, and neither CONFIG_MEDIA_SUBDRV_AUTOSELECT or DVB_DRX39XYJ is selected. Signed-off-by: -
Mauro Carvalho Chehab authored
Fixes the following warnings: drivers/media/dvb-frontends/drx39xyj/drxj.c:16764:68: warning: dubious: x & !y drivers/media/dvb-frontends/drx39xyj/drxj.c:16778:68: warning: dubious: x & !y drivers/media/dvb-frontends/drx39xyj/drxj.c:16797:68: warning: dubious: x & !y Signed-off-by: -
Mauro Carvalho Chehab authored
Fixes the following warnings: drivers/media/dvb-frontends/drx39xyj/drxj.c:1679:65: warning: Using plain integer as NULL pointer drivers/media/dvb-frontends/drx39xyj/drxj.c:1679:71: warning: Using plain integer as NULL pointer drivers/media/dvb-frontends/drx39xyj/drxj.c:1681:52: warning: Using plain integer as NULL pointer drivers/media/dvb-frontends/drx39xyj/drxj.c:1681:58: warning: Using plain integer as NULL pointer Signed-off-by: -
Dave Jones authored
No functional changes, but removes a duplicate check, if !state->type_A. Signed-off-by:
Dave Jones <davej@fedoraproject.org> Signed-off-by:
-
Fengguang Wu authored
Fix sparse warning: drivers/media/dvb-frontends/drx39xyj/drxj.c:1039:16: sparse: symbol 'drxj_default_aud_data_g' was not declared. Should it be static? Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Simplify the logic a little by removing one level of identation. Also, it only makes sense to print something if the .fini callback is actually doing something. Reviewed-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
We can't free struct em28xx while one of the extensions is still using it. So, add a kref() to control it, freeing it only after the extensions fini calls. Reviewed-by:
-
Mauro Carvalho Chehab authored
Instead of keeping the led always on, use it to indicate when DVB is streaming. Signed-off-by: -
Hans Verkuil authored
This function never checked if width and height are correct. Add such a check so the v4l2-compliance tool returns OK again for vivi. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
If start_streaming fails then any queued buffers must be given back to the vb2 core. Signed-off-by:
-
Hans Verkuil authored
Don't call buf_finish unless we know that the buffer is in a valid state. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Hans Verkuil authored
If you request buffers, then queue buffers and then call STREAMOFF those buffers are not returned to their dequeued state because streamoff will just return if q->streaming was 0. This means that afterwards you can never QBUF that same buffer again unless you do STREAMON, REQBUFS or close the filehandle first. It is clear that if you do STREAMOFF even if no STREAMON was called before, you still want to have all buffers returned to their proper dequeued state. Signed-off-by:
-
Hans Verkuil authored
No need to oops for this, WARN_ON is good enough. Signed-off-by:
-
Hans Verkuil authored
If __reqbufs was called then existing buffers are freed. However, if that happens without ever having started STREAMON, but if buffers have been queued, then the buf_finish op is never called. Add a call to __vb2_queue_cancel in __reqbufs so that these buffers are cleaned up there as well. Signed-off-by:
-
Hans Verkuil authored
In commit 02f142ec support was added to start_streaming to return -ENOBUFS if insufficient buffers were queued for the DMA engine to start. The vb2 core would attempt calling start_streaming again if another buffer would be queued up. Later analysis uncovered problems with the queue management if start_streaming would return an error: the buffers are enqueued to the driver before the start_streaming op is called, so after an error they are never returned to the vb2 core. The solution for this is to let the driver return them to the vb2 core in case of an error while starting the DMA engine. However, in the case of -ENOBUFS that would be weird: it is not a real error, it just says that more buffers are needed. Requiring start_streaming to give them back only to have them requeued again the next time the application calls QBUF is inefficient. This patch changes this mechanism: it adds a 'min_buffers_needed' field to vb2_queue that drivers can set with the minimum number of buffers required to start the DMA engine. The start_streaming op is only called if enough buffers are queued. The -ENOBUFS handling has been dropped in favor of this new method. Drivers are expected to return buffers back to vb2 core with state QUEUED if start_streaming would return an error. The vb2 core checks for this and produces a warning if that didn't happen and it will forcefully reclaim such buffers to ensure that the internal vb2 core state remains consistent and all buffer-related resources have been correctly freed and all op calls have been balanced. __reqbufs() has been updated to check that at least min_buffers_needed buffers could be allocated. If fewer buffers were allocated then __reqbufs will free what was allocated and return -ENOMEM. Based on a suggestion from Pawel Osciak. __create_bufs() doesn't do that check, since the use of __create_bufs assumes some advance scenario where the user might want more control. Instead streamon will check if enough buffers were allocated to prevent streaming with fewer than the minimum required number of buffers. Signed-off-by:
-
Hans Verkuil authored
__vb2_queue_free() would init the queued_list at all times, even if q->num_buffers > 0. This should only happen if num_buffers == 0. This situation can happen if a CREATE_BUFFERS call couldn't allocate enough buffers and had to free those it did manage to allocate before returning an error. While we're at it: __vb2_queue_alloc() returns the number of buffers allocated, not an error code. So stick the result in allocated_buffers instead of ret as that's very confusing. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
'queued_count' is a bit vague since it is not clear to which queue it refers to: the vb2 internal list of buffers or the driver-owned list of buffers. Rename to make it explicit. Signed-off-by:
Pawel Osciak <pawel@osciak.com> Acked-by:
-
Hans Verkuil authored
Ensure that these ops are properly balanced. There are two scenarios: 1) for MMAP buf_init is called when the buffers are created and buf_cleanup must be called when the queue is finally freed. This scenario was always working. 2) for USERPTR and DMABUF it is more complicated. When a buffer is queued the code checks if all planes of this buffer have been acquired before. If that's the case, then only buf_prepare has to be called. Otherwise buf_cleanup needs to be called if the buffer was acquired before, then, once all changed planes have been (re)acquired, buf_init has to be called followed by buf_prepare. Should buf_prepare fail, then buf_cleanup must be called on the newly acquired planes to release them in. Finally, in __vb2_queue_free we have to check if the buffer was actually acquired before calling buf_cleanup. While that it always true for MMAP mode, it is not necessarily true for the other modes. E.g. if you just call REQBUFS and close the file handle, then buffers were never queued and so no buf_init was ever called. Signed-off-by:
-
Hans Verkuil authored
Sometimes sentences in comments ended with a period, and sometimes they didn't. Add periods. No other changes. Signed-off-by:
-
Hans Verkuil authored
If a queue was canceled, then the buf_finish op was never called for the pending buffers. So add this call to queue_cancel. Before calling buf_finish set the buffer state to PREPARED, which is the correct state. That way the states DONE and ERROR will only be seen in buf_finish if streaming is in progress. Since buf_finish can now be called from non-streaming state we need to adapt the handful of drivers that actually need to know this. Signed-off-by:
-
Hans Verkuil authored
There is no point in trying to decompress a captured frame unless the buffer state is OK. It won't be used in any other state, and in fact the contents of the buffer might well be corrupt. Signed-off-by:
-
Hans Verkuil authored
The buf_finish op should always work, so change the return type to void. Update the few drivers that use it. Signed-off-by:
-
Hans Verkuil authored
When a vb2_queue is freed check if all the mem_ops and queue ops were balanced. So the number of calls to e.g. buf_finish has to match the number of calls to buf_prepare, etc. This code is only enabled if CONFIG_VIDEO_ADV_DEBUG is set. Signed-off-by:
-
Hans Verkuil authored
Fix an incorrect test in vb2_internal_qbuf() where only DEQUEUED buffers are allowed. But PREPARED buffers are also OK. Introduced by commit 4138111a ("vb2: simplify qbuf/prepare_buf by removing callback"). Signed-off-by:
-
Hans Verkuil authored
Commit 88e26870 ("vb2: Improve file I/O emulation to handle buffers in any order") broke read/write support if the size of the buffer being read/written is less than the size of the image. When the commit was tested originally I used qv4l2, which calls read() with exactly the size of the image. But if you try 'cat /dev/video0' then it will fail and typically hang after reading two buffers. This patch fixes the behavior by adding a new cur_index field that contains the index of the field currently being filled/read, or it is num_buffers in which case a new buffer needs to be dequeued. The old index field has been renamed to initial_index in order to be a bit more descriptive. This has been tested with both read and write. Signed-off-by:
-
Ricardo Ribalda Delgado authored
This patch adds a test preventing streamon() if there is no buffer ready. Without this patch, a user could call streamon() before preparing any buffer. This leads to a situation where if he calls close() before calling streamoff() the device is kept streaming. Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Linux 3.14-rc5 * tag 'v3.14-rc5': (1117 commits) Linux 3.14-rc5 drm/vmwgfx: avoid null pointer dereference at failure paths drm/vmwgfx: Make sure backing mobs are cleared when allocated. Update driver date. drm/vmwgfx: Remove some unused surface formats MAINTAINERS: add maintainer entry for Armada DRM driver arm64: Fix !CONFIG_SMP kernel build arm64: mm: Add double logical invert to pte accessors dm cache: fix truncation bug when mapping I/O to >2TB fast device perf tools: Fix strict alias issue for find_first_bit powerpc/powernv: Fix indirect XSCOM unmangling powerpc/powernv: Fix opal_xscom_{read,write} prototype powerpc/powernv: Refactor PHB diag-data dump powerpc/powernv: Dump PHB diag-data immediately powerpc: Increase stack redzone for 64-bit userspace to 512 bytes powerpc/ftrace: bugfix for test_24bit_addr powerpc/crashdump : Fix page frame number check in copy_oldmem_page powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly kvm, vmx: Really fix lazy FPU on nested guest perf tools: fix BFD detection on opensuse drm/radeon: enable speaker allocation setup on dce3.2 ...
-
- 05 Mar, 2014 7 commits
-
-
Peter Meerwald authored
Use the correct name in the comment describing function omap3isp_module_sync_is_stopping(). isp_isr() never returned IRQ_NONE, remove the comment saying so. Signed-off-by:
Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by:
-
Lad, Prabhakar authored
This patch renames the variable in the description to match it appropriately to function definition. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Lad, Prabhakar authored
This patch removes the description of members which does not exists for ispccdc_lsc structure. Signed-off-by:
-
Lad, Prabhakar authored
Signed-off-by:
-
Edgar Thier authored
Add bayer 8-bit GUIDs to uvcvideo and associated them with the corresponding V4L2 pixel formats. Signed-off-by:
Edgar Thier <info@edgarthier.net> Signed-off-by:
-
Oleksij Rempel authored
The UVC specification uses alternate setting selection to notify devices of stream start/stop. This breaks when using bulk-based devices, as the video streaming interface has a single alternate setting in that case, making video stream start and video stream stop events to appear identical to the device. Bulk-based devices are thus not well supported by UVC. The webcam built in the Asus Zenbook UX302LA ignores the set interface request and will keep the video stream enabled when the driver tries to stop it. If USB autosuspend is enabled the device will then be suspended and will crash, requiring a cold reboot. USB trace capture showed that Windows sends a CLEAR_FEATURE(HALT) request to the bulk endpoint when stopping the stream instead of selecting alternate setting 0. The camera then behaves correctly, and thus seems to require that behaviour. Replace selection of alternate setting 0 with clearing of the endpoint halt feature at video stream stop for bulk-based devices. Let's refrain from blaming Microsoft this time, as it's not clear whether this Windows-specific but USB-compliant behaviour was specifically developed to handle bulkd-based UVC devices, or if the camera just took advantage of it. CC: stable@vger.kernel.org Signed-off-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
-
Sakari Ailus authored
Timestamp buffer flags are constant at the moment. Document them so that 1) they're always valid and 2) not changed by the drivers. This leaves room to extend the functionality later on if needed. Signed-off-by:
Sakari Ailus <sakari.ailus@iki.fi> Acked-by:
-
