- 23 May, 2014 40 commits
-
-
Kiran AVND authored
This patch adds variant data and core support for V8 decoder. This patch also adds the register definition file for new firmware version v8 for MFC. Signed-off-by:
Kiran AVND <avnd.kiran@samsung.com> Signed-off-by:
Pawel Osciak <posciak@chromium.org> Signed-off-by:
Arun Kumar K <arun.kk@samsung.com> [k.debski@samsung.com: Change MFC version macro name to MFC_V8_BIT] Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com>
-
Kamil Debski authored
MFC versions support a different set of formats, this specially applies to the raw YUV formats. This patch changes enum_fmt, so that it only reports formats that are supported by the used MFC version. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Kamil Debski authored
The patch adding the v6 version of MFC changed the default format for the CAPTURE queue, but this also affects the v5 version. This patch solves this problem by checking the MFC version before assigning the default format. Signed-off-by:
-
Arun Kumar K authored
Renaming the IS_MFCV7 macro to IS_MFCV7_PLUS for the addition of MFCv8 support which reuses the v7 code. Signed-off-by:
-
Kiran AVND authored
This patch is needed in preparation to add MFC V8 where the register offsets are changed w.r.t MFC V6/V7. This patch adds variants of MFC V6 and V7 while accessing MFC registers. Registers are kept in mfc context and are initialized to a particular MFC variant during probe, which is used instead of macros. This avoids duplication of the code for MFC variants V6 & V7, and reduces the if_else checks while accessing registers of different MFC variants. Signed-off-by:
-
Arun Kumar K authored
The register S5P_FIMV_D_INIT_BUFFER_OPTIONS holds good for v6 firmware too. So moving the definition from v7 regs to v6. Signed-off-by:
-
Arun Kumar K authored
Update the MPEG4 decoder scratch buffer size as per the new v6 firmware. This updation is increasing the size and so is backward compatible with older v6 firmwares. Signed-off-by:
-
Pawel Osciak authored
Currently, for formats that are not H264, MFC driver will check the consumed stream size returned by the firmware and, based on that, will try to decide whether the bitstream buffer contained more than one frame. If the size of the buffer is larger than the consumed stream, it assumes that there are more frames in the buffer and that the buffer should be resubmitted for decode. This rarely works though and actually introduces problems, because: - v7 firmware will always return consumed stream size equal to whatever the driver passed to it when running decode (which is the size of the whole buffer), which means we will never try to resubmit, because the firmware will always tell us that it consumed all the data we passed to it; - v6 firmware will return the number of consumed bytes, but will not include the padding ("stuffing") bytes that are allowed after the frame in VP8. Since there is no way of figuring out how many of those bytes follow the frame without getting the frame size from IVF headers (or somewhere else, but not from the stream itself), the driver tries to guess that padding size is not larger than 4 bytes, which is not always true; The only way to make it work is to queue only one frame per buffer from userspace and the check in the kernel is useless and wrong for VP8. So adding VP8 also along with H264 to disallow re-submitting of buffer back to hardware for decode. Signed-off-by: -
Kiran AVND authored
Scratch buffer size updated for vp8 encoding as per the latest v7 firmware. As the new macro increases the scratch buffer size, it is backward compatible with the older firmware too. Signed-off-by:
-
Pawel Osciak authored
Currently, we allocate private codec buffers on STREAMON, which may fail if we are out of memory. We don't check for failure though, which will make us crash with the codec accessing random memory. We shouldn't be failing STREAMON with out of memory errors though. So move the allocation of private codec buffers to REQBUFS for OUTPUT queue. Also, move MFC instance opening and closing to REQBUFS as well, as it's tied to allocation and deallocation of private codec buffers. Signed-off-by:
-
Pawel Osciak authored
This is in preparation for a new flow to fix issues with streamon, which should not be allocating buffer memory. Signed-off-by:
-
Pawel Osciak authored
- Honor return values from vb2_reqbufs on REQBUFS(0). - Do not set the number of allocated buffers to 0 if userspace tries to request buffers again without freeing them. - There is no need to verify correct instance state on reqbufs, as we will verify this in queue_setup(). - There is also no need to verify that vb2_reqbufs() was able to allocate enough buffers (pb_count) and call buf_init on that many buffers (i.e. dst_buf_count is at least pb_count), because this will be verified by second queue_setup() call as well and vb2_reqbufs() will fail otherwise. - Only verify state is MFCINST_INIT when allocating, not when freeing. - Refactor and simplify code. Signed-off-by:
-
Pawel Osciak authored
Timestamps for destination buffers are assigned by copying them from corresponding source buffers when the decode operation results in a frame being outputted to a destination buffer. But the decision when to do this, i.e. whether the decode operation on current source buffer produced a destination frame, is wrongly based on "display status". Display status reflects the status of the destination buffer, not source. This used to work for firmwares version <= 6, because in addition to the above, we'd check the decoded frame type register, which was set to "skipped" if a destination frame was not produced, exiting early from s5p_mfc_handle_frame_new(). Firmware >=7 does not set the frame type register for frames that were not decoded anymore though, which results in us wrongly overwriting timestamps of previously decoded buffers (firmware reports the same destination buffer address as previously decoded one if a frame wasn't decoded during current operation). To do it properly, we should be basing our decision to copy the timestamp on the status of the source buffer, i.e. "decode status". The decode status register values are confusing, because in its case "display" means "a frame has been outputted to a destination buffer". We should copy if "decode and display" is returned in it. This also works on <= v6 firmware, which behaves in the same way with regards to decode status register. Signed-off-by:
-
Alexander Shiyan authored
This patch adds the missing mutex_destroy(), when the driver is removed. Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Alexander Shiyan authored
There are no need to store resource struct and IRQ in the driver internal structure. This patch remove these fields and improve error handling by using proper return codes from devm_ioremap_resource() and devm_request_irq(). Signed-off-by:
-
John Sheu authored
VIDIOC_STREAMOFF clears the encoder's destination queue -- routines run from the interrupt handler cannot assume that the queue is non-empty. Signed-off-by:
John Sheu <sheu@google.com> Signed-off-by:
-
Laurent Pinchart authored
Auto BLC and BLC digital offset are disabled when enabling the test pattern and must be restored when disabling it. The driver does so by calling the set control handler on the auto BLC and BLC offset controls, but this programs the hardware with the new value of those controls, not the current value. Fix this by writing to the registers directly. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
The digital side of the Black Level Calibration (BLC) function must be disabled when generating a test pattern to avoid artifacts in the image. The driver disables BLC correctly at the hardware level, but the feature gets reenabled by v4l2_ctrl_handler_setup() the next time the device is powered on. Fix this by marking the BLC controls as inactive when generating a test pattern, and ignoring control set requests on inactive controls. Signed-off-by:
-
Archit Taneja authored
Rename the memory block resource "vpe_csc" to "csc" since it also exists within the VIP IP block. This would make the name more generic, and both VPE and VIP DT nodes in the future can use it. Signed-off-by:
Archit Taneja <archit@ti.com> Signed-off-by:
-
Archit Taneja authored
Add selection ioctl ops. For VPE, cropping makes sense only for the input to VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers). For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output in a rectangle within the capture buffer. For the OUTPUT type, V4L2_SEL_TGT_CROP results in selecting a rectangle region within the source buffer. Setting the crop/compose rectangles should successfully result in re-configuration of registers which are affected when either source or destination dimensions change, set_srcdst_params() is called for this purpose. Signed-off-by:
-
Archit Taneja authored
Some parameters of the VPE descriptors were understood incorrectly. They are now fixed. The fixes are explained as follows: - When adding an inbound data descriptor to the VPDMA descriptor list, we intend to use c_rect as the cropped region fetched by VPDMA. Therefore, c_rect->width shouldn't be used to calculate the line stride, the original image width should be used for that. We add a 'width' argument which gives the buffer width in memory. - frame_width and frame_height describe the complete width and height of the client to which the channel is connected. If there are multiple channels fetching data and providing to the same client, the above 2 arguments should be the width and height of the region covered by all the channels. In the case where there is only one channel providing pixel data to the client (like in VPE), frame_width and frame_height should be the cropped width and cropped height respectively. The calculation of these params is done in the vpe driver now. - start_h and start_v is also used in the case of multiple channels to describe where each channel should start filling pixel data. We don't use this in VPE, and pass 0s to the vpdma_add_in_dtd() helper. - Some minor changes are made to the vpdma_add_out_dtd() helper. The c_rect param is used for specifying the 'composition' target, and 'width' is added to calculate the line stride. Signed-off-by:
-
Mauro Carvalho Chehab authored
Changeset 95d2608b created this function, but declared it as global, by mistake. Signed-off-by:
-
Archit Taneja authored
For OMAP and DRA7x, we generally allocate video and graphics buffers through omapdrm since the corresponding omap-gem driver provides DMM-Tiler backed contiguous buffers. omapdrm is a dma-buf exporter. These buffers are used by other drivers in the video pipeline. Add VB2_DMABUF flag to the io_modes of the vb2 output and capture queues. This allows the driver to import dma shared buffers. Reviewed-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Archit Taneja authored
vpe fops(vpe_open in particular) should be called only when VPDMA firmware is loaded. File operations on the video device are possible the moment it is registered. Currently, we register the video device for VPE at driver probe, after calling a vpdma helper to initialize VPDMA and load firmware. This function is non-blocking(it calls request_firmware_nowait()), and doesn't ensure that the firmware is actually loaded when it returns. We remove the device registration from vpe probe, and move it to a callback provided by the vpe driver to the vpdma library, through vpdma_create(). The ready field in vpdma_data is no longer needed since we always have firmware loaded before the device is registered. A minor problem with this approach is that if the video_register_device fails(which doesn't really happen), the vpe platform device would be registered. however, there won't be any v4l2 device corresponding to it. Signed-off-by:
-
Hans Verkuil authored
If the saa7134 module is loaded with the saa7134_userptr set to 1, then USERPTR support is enabled. A check in buffer_prepare verifies that the pointer is page-aligned. Signed-off-by:
-
Hans Verkuil authored
Convert the saa7134 driver to vb2. Note that while this uses the vb2-dma-sg version, the VB2_USERPTR mode is disabled. The DMA hardware only supports DMAing full pages, and in the USERPTR memory model the first and last scatter-gather buffer is almost never a full page. In practice this means that we can't use the VB2_USERPTR mode. This has been tested with raw video, compressed video, VBI, radio, DVB and video overlays. Unfortunately, a vb2 conversion is one of those things you cannot split up in smaller patches, it's all or nothing. This patch switches the whole driver over to vb2, using the vb2 ioctl and fop helper functions. Signed-off-by:
-
Hans Verkuil authored
All dmaqueue's use saa7134_pgtable, so move it into struct saa7134_dmaqueue. The videobuf_queue priv_data field now points to the dmaqueue struct. Signed-off-by:
-
Hans Verkuil authored
Use consistent _vbq suffix for videobuf_queue fields. Signed-off-by:
-
Philipp Zabel authored
num_buffers can't be bigger than VIDEO_MAX_FRAME. This is assured by: num_buffers = min_t(unsigned int, req->count, VIDEO_MAX_FRAME); However, this value is overriden by: num_buffers = max_t(unsigned int, req->count, q->min_buffers_needed); It should, instead, use the previously calculated value as an input to max_t: num_buffers = max_t(unsigned int, num_buffers, q->min_buffers_needed); Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
-
Laurent Pinchart authored
The __vb2_queue_cancel function marks the queue as not streaming and then WARNs when buffers are still owned by the driver. It proceeds to complete all active buffers by calling vb2_buffer_done with the new buffer state set to VB2_BUF_STATE_ERROR in that case. This triggers another WARN_ON due to as new state not being VB2_BUF_STATE_QUEUED while the queue is not streaming. Check buffer ownership and complete all active buffers before marking the queue as not streaming to avoid the double WARN_on. Signed-off-by:
-
Frank Schaefer authored
[media] em28xx: move fields wq_trigger and streaming_started from struct em28xx to struct em28xx_audio Both wq_trigger and stream_started are used only to control the em28xx alsa streaming. They don't belong to em28xx common struct. Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Frank Schaefer authored
The tuner address is only used by the v4l submodule and at tuner setup and can be obtained from the board data directly (if specified). Signed-off-by:
-
Frank Schaefer authored
The tda9887 chipset is part of the analog tuner. Move it out of em28xx-cards. Also, it is used only one time by the v4l2 sub-module at tuner setup. With that, we can get rid of an additional data inside the em28xx common structure. Signed-off-by:
-
Frank Schaefer authored
Move V4L2-specific frequency cache to struct em28xx_v4l2. Signed-off-by:
-
Frank Schaefer authored
Despite being at the common em28xx struct, those two fields are actually taking into account only the usage inside em28xx v4l2 submodule. So, move them out of the common struct. Signed-off-by:
-
Frank Schaefer authored
Move some temporary capture tracking date to the em28xx_v4l2 struct, as those info are used only by em28xx v4l2 submodule. Signed-off-by:
-
Frank Schaefer authored
Move camera sensor resolution and xtal out of em28xx common struct, as thore are used only by the em28xx v4l2 submodule. Signed-off-by:
-
Frank Schaefer authored
The video progressive data fields belong to analog TV. Move them out of the common em28xx struct. Signed-off-by:
-
Frank Schaefer authored
The analog format struct belongs to analog TV. Move it out of the common em28xx struct. Signed-off-by:
-
Frank Schaefer authored
TV norm is specific to analog TV reception. move it out of the common em28xx struct. Signed-off-by:
-
