- 07 Jan, 2014 40 commits
-
-
Laurent Pinchart authored
Modules failing to stop are fatal errors for the preview engine only. Flag that condition separately from the other stop failures to prepare support for more fatal errors. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com>
-
Laurent Pinchart authored
When a fatal error that prevents any further video streaming occurs in a pipeline, all queued buffers must be marked as erroneous and new buffers must be prevented from being queued. Implement this behaviour with a new omap3isp_pipeline_cancel_stream() function that can be used by submodules to cancel streaming. Signed-off-by:
-
Mauro Carvalho Chehab authored
As reported by the kbuild test robot: All error/warnings: >> ERROR: "em28xx_release_resources" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Hans Verkuil authored
The include for delay.h was missing. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Ricardo Ribalda authored
As discussed on the media summit 2013, there is no reason for the width and height to be signed. Therefore this patch is an attempt to convert those fields from __s32 to __u32. Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Acked-by: Sakari Ailus <sakari.ailus@iki.fi> (documentation and smiapp) Acked-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Joe Perches authored
Emitting an OOM message isn't necessary after input_allocate_device as there's a generic OOM and a dump_stack already done. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Fengguang Wu authored
drivers/staging/media/bcm2048/radio-bcm2048.c:2255:3-4: Unneeded semicolon Removes unneeded semicolon. Generated by: coccinelle/misc/semicolon.cocci CC: Hans Verkuil <hans.verkuil@cisco.com> CC: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Fengguang Wu authored
drivers/staging/media/bcm2048/radio-bcm2048.c:2632:1-7: Replace memcpy with struct assignment /c/kernel-tests/src/cocci/drivers/staging/media/bcm2048/radio-bcm2048.c:744:1-7: Replace memcpy with struct assignment /c/kernel-tests/src/cocci/drivers/staging/media/bcm2048/radio-bcm2048.c:2360:3-9: Replace memcpy with struct assignment Generated by: coccinelle/misc/memcpy-assign.cocci CC: Hans Verkuil <hans.verkuil@cisco.com> CC: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Hans Verkuil authored
You can set this through sysfs, so don't mix the two. Signed-off-by:
-
Hans Verkuil authored
saa6588 always blocked while waiting for data, even if the filehandle was in non-blocking mode. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
CMD_CLOSE sets data_available_for_read to 1, which is necessary to do the wakeup call, but it is never reset to 0. Because of this calling CMD_POLL afterwards will always return that data is available, even if there isn't any. Signed-off-by:
-
Hans Verkuil authored
There are no controls for the radio node, so just drop support for this ioctl. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
This driver is independent from saa7134, so there is no reason why this shouldn't be in media/i2c like all other i2c media drivers. Signed-off-by:
-
Hans Verkuil authored
The saa7134 driver is now converted to the control framework, so drop the control compat code in saa6752hs.c. Also add 'const' to several static arrays. Signed-off-by:
-
Hans Verkuil authored
NO_SYNC was meant for DVB and shouldn't be used anymore. In this case NO_SIGNAL is a good alternative. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
The empress video node can share resource management with the normal video nodes, thus allowing for code sharing and making the empress node non-exclusive. Signed-off-by:
-
Hans Verkuil authored
Use the saa7134_fh struct for the empress video node as well, drop the dev pointer from that struct since we can use drvdata for that. Signed-off-by:
-
Hans Verkuil authored
The video and empress nodes can share various ioctls. Drop the input/std ioctls from the radio node (out of spec). Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
These fields are global, not per-filehandle. Signed-off-by:
-
Hans Verkuil authored
There are already video output drivers that allow STREAMON without any buffers queued, and with the change in vb2 there are now more drivers like that. So saying "The ioctl will succeed only when at least one output buffer is in the incoming queue." isn't true. Just drop the word 'only'. We cannot say that it will also work if no output buffers are queued as long as not all drivers are converted to vb2. Signed-off-by:
-
Hans Verkuil authored
videobuf2 file I/O emulation assumed that buffers dequeued from the driver would return in the order they were enqueued in the driver. Improve the file I/O emulator's book-keeping to remove this assumption. Also set the buf->size properly if a write() dequeues a buffer and the VB2_FILEIO_WRITE_IMMEDIATELY flag is set. Based on an initial patch by Andy Walls. Signed-off-by:
Andy Walls <awalls@md.metrocast.net> Signed-off-by:
-
Hans Verkuil authored
This works together with the retry_start_streaming mechanism to allow userspace to start streaming even if not all required buffers have been queued. Signed-off-by:
Kamil Debski <k.debski@samsung.com> Acked-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Hans Verkuil authored
Two fixes: - there is no need to set the index when calling dqbuf: dqbuf will overwrite it. - __vb2_init_fileio already starts streaming for write(), so there is no need to do it again in __vb2_perform_fileio. It can never have worked anyway: either __vb2_init_fileio succeeds in starting streaming or it is never going to happen. Signed-off-by:
-
Hans Verkuil authored
If start_streaming returns -ENOBUFS, then it will be retried the next time a buffer is queued. This means applications no longer need to know how many buffers need to be queued before STREAMON can be called. This is particularly useful for output stream I/O. If a DMA engine needs at least X buffers before it can start streaming, then for applications to get a buffer out as soon as possible they need to know the minimum number of buffers to queue before STREAMON can be called. You can't just try STREAMON after every buffer since on failure STREAMON will dequeue all your buffers. (Is that a bug or a feature? Frankly, I'm not sure). This patch simplifies applications substantially: they can just call STREAMON at the beginning and then start queuing buffers and the DMA engine will kick in automagically once enough buffers are available. This also fixes using write() to stream video: the fileio implementation calls streamon without having any queued buffers, which will fail today for any driver that requires a minimum number of buffers. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
-
Hans Verkuil authored
The read/write implementation in vb2 reuses existing vb2 functions, but it sets q->fileio to NULL before calling them in order to skip the 'q->fileio != NULL' check. This works today due to the synchronous nature of read/write, but it 1) is ugly, and 2) will fail in an asynchronous use-case such as a thread queuing and dequeuing buffers. This last example will be necessary in order to implement vb2 DVB support. This patch removes the hack by splitting up the dqbuf/qbuf/streamon/streamoff functions into an external and an internal version. The external version checks q->fileio and then calls the internal version. The read/write implementation now just uses the internal version, removing the need to set q->fileio to NULL. Signed-off-by:
-
Hans Verkuil authored
When preparing a buffer the queue lock is released for a short while if the memory mode is USERPTR (see __buf_prepare for the details), which would allow a race with a REQBUFS which can free the buffers. Removing the buffers from underneath __buf_prepare is obviously a bad idea, so we check if any of the buffers is in the state PREPARING, and if so we just return -EAGAIN. If this happens, then the application does something really strange. The REQBUFS call can be retried safely, since this situation is transient. Signed-off-by:
-
Hans Verkuil authored
The callback used to merge the common code of the qbuf/prepare_buf code can be removed now that the mmap_sem handling is pushed down to __buf_prepare(). This makes the code more readable. Signed-off-by:
-
Mauro Carvalho Chehab authored
Changeset b18a8ff2 added a comment violating the 80cols max size, with no good reason. Fix it. Cc: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
Rather than taking the mmap semaphore at a relatively high-level function, push it down to the place where it is really needed. It was placed in vb2_queue_or_prepare_buf() to prevent racing with other vb2 calls. The only way I can see that a race can happen is when two threads queue the same buffer. The solution for that it to introduce a PREPARING state. Moving it down offers opportunities to simplify the code. Signed-off-by:
-
Archit Taneja authored
The struct vpdma_data_format holds the color format depth and the data_type value needed to be programmed in the data descriptors. However, it doesn't tell what type of color format is it, i.e, whether it is RGB, YUV or Misc. This information is needed when by vpdma library when forming descriptors. We modify the depth parameter for the chroma portion of the NV12 format. For this, we check if the data_type value is C420. This isn't sufficient as there are many YUV and RGB vpdma formats which have the same data_type value. Hence, we need to hold the type of the color format for the above case, and possibly more cases in the future. Signed-off-by:
Archit Taneja <archit@ti.com> Signed-off-by:
-
Archit Taneja authored
Use the csc library functions to configure the CSC block in VPE. Some changes are required in try_fmt to handle the pix->colorspace parameter more correctly. Previously, we copied the source queue colorspace to the destination queue colorspace as we didn't support RGB formats. Now, we configure pix->colorspace based on the color format set(and the height of the image if it's a YUV format). Add basic RGB color formats to the list of supported vpe formats. If the destination format is RGB colorspace, we also need to use the RGB output port instead of the Luma and Chroma output ports. This requires configuring the output data descriptors differently. Also, make the default colorspace V4L2_COLORSPACE_SMPTE170M as that resembles the Standard Definition colorspace more closely. Signed-off-by:
-
Archit Taneja authored
The CSC block can be used for color space conversion between YUV and RGB formats. It is configurable via a programmable set of coefficients. Add functionality to choose the appropriate CSC coefficients and program them in the CSC registers. We take the source and destination colorspace formats as the arguments, and choose the coefficient table accordingly. YUV to RGB coefficients are provided for standard and high definition colorspaces. The coefficients can also be limited or full range. For now, only full range coefficients are chosen. We would need some sort of control ioctl for the user to specify the range needed. Not sure if there is a generic control ioctl for this already? Signed-off-by:
-
Archit Taneja authored
VPE and VIP IPs in DAR7x contain a color space converter(CSC) sub block. Create a library which will perform CSC related configurations and hold CSC register definitions. The functions provided by this library will be called by the vpe and vip drivers using a csc_data handle. The vpe_dev holds the csc_data handle. The handle represents an instance of the CSC hardware, and the vpe driver uses it to access the CSC register offsets or helper functions to configure these registers. The CSC register offsets are now relative to the CSC block itself, so we need to use the macro GET_OFFSET_TOP to get the CSC register offset relative to the VPE IP in the vpe driver. Signed-off-by:
-
Archit Taneja authored
Add the required SC register configurations which lets us perform linear scaling for the supported range of horizontal and vertical scaling ratios. The horizontal scaler performs polyphase scaling using it's 8 tap 32 phase filter, decimation is performed when downscaling passes beyond 2x or 4x. The vertical scaler performs polyphase scaling using it's 5 tap 32 phase filter, it switches to a simpler form of scaling using the running average filter when the downscale ratio is more than 4x. Many of the SC features like peaking, trimming and non-linear scaling aren't implemented for now. Only the minimal register fields required for basic scaling operation are configured. The function to configure SC registers takes the sc_data handle, the source and destination widths and heights, and the scaler address data block offsets for the current context so that they can be configured. Signed-off-by:
-
Archit Taneja authored
Make the driver allocate dma buffers to store horizontal and scaler coeffs. Use the scaler library api to choose and copy scaler coefficients to a the above buffers based on the scaling ratio. Since the SC block comes after the de-interlacer, make sure that the source height is doubled if de-interlacer was used. These buffers now need to be used by VPDMA to load the coefficients into the SRAM within SC. In device_run, add configuration descriptors which have payloads pointing to the scaler coefficients in memory. Use the members in sc_data handle to prevent addition of these descriptors if there isn't a need to re-load coefficients into SC. This comes helps unnecessary re-loading of the coefficients when we switch back and forth between vpe contexts. Signed-off-by:
-
Archit Taneja authored
The SC block in VPE/VIP contains a SRAM within it. This internal memory requires to be loaded with appropriate scaler coefficients from a contiguous block of memory through VPDMA. The horizontal and vertical scaler each require 2 sets of scaler coefficients for luma and chroma scaling. The horizontal polyphase scaler requires coefficients for a 32 phase and 8 tap filter. Similarly, the vertical scaler requires coefficients for a 5 tap filter. The choice of the scaler coefficients depends on the scaling ratio. Add coefficient tables for different scaling ratios in sc_coeffs.h. In the case of horizontal downscaling, we need to consider the change in ratio caused by decimation performed by the horizontal scaler. In order to load the scaler coefficients via VPDMA, a configuration descriptor is used in block mode. The payload for the descriptor is the scaler coefficients copied to memory. Coefficients for each phase have to be placed in memory in a particular order understood by the scaler hardware. The choice of the scaler coefficients, and the loading of the coefficients from our tables to a contiguous buffer is managed by the functions sc_set_hs_coefficients and sc_set_vs_coefficients. The sc_data handle is now added with some parameters to describe the state of the coefficients loaded in the SC block. 'loaded_coeff_h' and 'loaded_coeff_v' hold the address of the last dma buffer which was used by VPDMA to copy coefficients. This information can be used by a vpe mem-to-mem context to decide whether it should load coefficients or not. 'hs_index' and 'vs_index' provide some optimization by preventing loading of coefficients if the scaling ratio didn't change between 2 contexts. 'load_coeff_h' and 'load_coeff_v' tell the vpe/vip driver whether we need to load the coefficients through VPDMA or not. Signed-off-by:
-
