- 28 Oct, 2014 40 commits
-
-
Ilja Friedel authored
Timestamp i of a previously decoded buffer was overwritten for some H.264 streams with timestamp i+1 of the next buffer. This happened when encountering frame_type S5P_FIMV_DECODE_FRAME_SKIPPED, indicating no new frame. In most cases this wrong indexing might not have been noticed except for a one frame delay in frame presentation. For H.264 streams though that require reordering of frames for presentation, it caused a slightly erratic presentation time lookup and consequently dropped frames in the Pepper Flash plugin. Signed-off-by:
Ilja H. Friedel <ihf@google.com> Signed-off-by:
Kiran AVND <avnd.kiran@samsung.com> Signed-off-by:
Arun Kumar K <arun.kk@samsung.com> Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Prathyush K authored
The enter_suspend flag is set after we enter mfc suspend function but if suspend fails after that due to any reason (like hardware timeout etc), this flag must be cleared before returning an error. Otherwise, this flag never gets cleared and the MFC suspend will always return an error on subsequent tries. If clock off fails, disable hw_lock also. Signed-off-by:
Prathyush K <prathyush.k@samsung.com> Signed-off-by:
-
Pawel Osciak authored
Handle REQBUFS(0) for CAPTURE queue as well. Also use the proper queue to call it on for OUTPUT. Signed-off-by:
Pawel Osciak <posciak@chromium.org> Signed-off-by:
-
Kiran AVND authored
Add V4L2_CID_MIN_BUFFERS_FOR_OUTPUT query for encoder. Once mfc encoder state is HEAD_PARSED, which is sequence header produced, dpb_count is avaialable. Let user space query this value. Signed-off-by:
-
Philipp Zabel authored
This patch adds a quick check for valid JPEG frames before feeding them into the bitstream buffer: Frames that do not begin with the JPEG start of image marker and end with the end of image marker are dropped. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
This should fix CODA crashes due to timeouts when stopping the decoding process with SIGINT. Signed-off-by:
-
Philipp Zabel authored
For small frame sizes, allocating 1 MiB per compressed buffer is a waste of space. On the other hand, incompressible 1080p data can produce JPEGs larger than 1 MiB at higher quality settings. Allow userspace to set the compressed buffer size and clamp the value to a sensible range. Also set the initial sizeimage to a value inside the range allowed by try_fmt. While at it, reduce the default image size to a maximum of 1920*1088 (otherwise JPEG will default to 8k*8k and 96 MiB buffers). Signed-off-by:
-
Philipp Zabel authored
With bitstream padding, it is possible to decode a single JPEG in the bitstream immediately. This allows us to only ever queue a single JPEG into the bitstream buffer, except to increase payload over 512 bytes or to back out of hold state. This is a measure to decrease JPEG decoder latency. Signed-off-by:
-
Philipp Zabel authored
Before starting a PIC_RUN, pad the bitstream with 0xff until 256 bytes past the next multiple of 256 bytes, if the buffer to be decoded is the last buffer in the bitstream. Signed-off-by:
-
Philipp Zabel authored
Storing the buffer position in the bitstream with the buffer metadata allows to later use that information to drop metadata for skipped buffers and to determine whether bitstream padding has to be applied. This patch also renames struct coda_timestamp to struct coda_buffer_meta to make clear that it contains more than only the buffer timestamp. Signed-off-by:
-
Philipp Zabel authored
This patch adds JPEG encoding and decoding support for CODA7541, using the BIT processor. Separate JPEG encoder and decoder video devices are created due to different streaming behaviour and different supported pixel formats. The hardware can not change subsampling on the fly, but encode and decode 4:2:2 subsampled JPEG images from and into this format. The CODA7541 JPEG decoder uses the bitstream buffer and thus can run without new buffers queued if there is a buffer in the bitstream. Since there is no standard way to store the colorspace used in JPEGs, and to make v4l2-compliance happy, the JPEG format always reports V4L2_COLORSPACE_JPEG. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
Add JPEG specific sequence initialization registers and bit definitions. Signed-off-by:
-
Philipp Zabel authored
This patch splits the encoder specific controls out of the main control setup function. This way each video device registers only relevant controls. Signed-off-by:
-
Philipp Zabel authored
Each video device descriptor determines the name, callback ops, and input and output formats on the corresponding video device. This simplifies coda_enum_fmt and coda_try_fmt a bit and will simplify adding separate video devices for JPEG codecs due to the slightly different behavior in the CodaDx6/CODA7542 case and a separate hardware unit on CODA960. Signed-off-by:
-
Philipp Zabel authored
We'll use this information to decide whether to request the JPEG IRQ later. Signed-off-by:
-
Philipp Zabel authored
This patch adds support for the three-plane YUV422P format with one luma plane and two horizontally subsampled chroma planes. Signed-off-by:
-
Philipp Zabel authored
This patch adds support for the two-plane NV12 format with one luma plane and one interleaved chroma plane. Signed-off-by:
-
Philipp Zabel authored
Since the firmware newer writes to FRAME_MEM_CTRL, we can initialize it once per context (incidentally, we already do write it in coda_hw_init) and never have to read it back. Signed-off-by:
-
Philipp Zabel authored
This will still do a 1:1 copy into the internal buffers, but stop producing visual artifacts in chroma interleaved (NV12) mode. Signed-off-by:
-
Philipp Zabel authored
Add a helper function that writes a vb2_buffer's Y, Cb, and Cr plane base addresses of into three consecutive registers. This moves common code out of coda-bit.c. Signed-off-by:
-
Philipp Zabel authored
When devm_kzalloc causes an OOM condition, this is already reported by the MM subsystem. Signed-off-by:
-
Philipp Zabel authored
Clearing the aborting flag in stop_streaming is necessary if we want to start streaming again without having to closing and reopening the device. Also, do not explicitly set it in default_params; the context is zeroed by kzalloc anyway. Signed-off-by:
-
Hans Verkuil authored
This is 1) *much* easier to type, and 2) is consistent with vivid ('vi' for virtual). More of such virtual drivers are planned, so keeping the naming consistent makes sense. Note that the old module name is retained as a module alias. Signed-off-by:Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Sakari Ailus authored
The media bus format BPP does affect PLL. Recalculate PLL if the format changes. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
Set supported link frequencies in the menu in control initialisation and when the bpp changes. Signed-off-by:
-
Sakari Ailus authored
smiapp_set_format() has accumulated a fair amount of changes without a needed refactoring, do the cleanup now. There's also an unlocked version of v4l2_ctrl_range_changed(), using that fixes a small serialisation issue with the user space interface. __v4l2_ctrl_modify_range() is used instead of v4l2_ctrl_modify_range() in smiapp_set_format_source() since the mutex is now held during the function call. Signed-off-by:
-
Sakari Ailus authored
Some media bus codes may be unavailable depending on the available media bus codes. Signed-off-by:
-
Sakari Ailus authored
Not all link rates are possible with all BPP values. Also rearrange other initialisation a little. Obtaining possible PLL configurations earlier requires that. Signed-off-by:
-
Sakari Ailus authored
The first one is handy for just trying out a PLL configuration without a need to apply it. Signed-off-by:
-
Sakari Ailus authored
Signed-off-by:
-
Sakari Ailus authored
The actual pixel array pixel rate may be something else than vt_pix_clk_freq on some implementations. Add a new field which contains the corrected value. Signed-off-by:
-
Sakari Ailus authored
op_pix_clk_div is directly assigned and not calculated. There's no need to verify it. Signed-off-by:
-
Sakari Ailus authored
No need to pretend the OP limits are there anymore. Signed-off-by:
-
Sakari Ailus authored
For profile 0 sensors (which have no OP clocks), the OP limits are in fact VT limits. Do not verify them again. Signed-off-by:
-
Sakari Ailus authored
Profile 0 sensors have no OP clock branck in the clock tree. The PLL calculator still calculated them, they just weren't used for anything. Signed-off-by:
-
Sakari Ailus authored
Uniform representation for VT and OP clocks. This is preparation for calculating the VT clocks using the OP clock code. Signed-off-by:
-
Sakari Ailus authored
It's input. Move it elsewhere in the struct. Signed-off-by:
-
Sakari Ailus authored
Enough work for this function already. Signed-off-by:
-
Sakari Ailus authored
These values are unsigned, so use %u instead of %d. Signed-off-by:
-
Sakari Ailus authored
The PLL flags were not used correctly. Cc: stable@vger.kernel.org Signed-off-by:
-
