This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Sat Jun 14 04:00:46 CEST 2014
git branch: test
git hash: f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8
gcc versi
Moikka Daniel,
On 05/31/2014 12:16 AM, Daniel Mayer wrote:
Hi,
attached micro-patch removes the text output of an error-message of the
PCTV452e-driver. The error messages "I2C error: [.]" do not help any user of
the kernel, so whatever causes the error, it does not hamper the function of
my TT-3
We offer all purpose loan at 3% interest rate. Contact Us for more details by
Email:santanderfinancegr...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordo
Fix following warnings:
si2157_cmd_execute() warn: add some parenthesis here?
si2157_cmd_execute() warn: maybe use && instead of &
Reported-by: Dan Carpenter
Signed-off-by: Antti Palosaari
---
drivers/media/tuners/si2157.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
Fix following warnings:
si2168_cmd_execute() warn: add some parenthesis here?
si2168_cmd_execute() warn: maybe use && instead of &
Reported-by: Dan Carpenter
Signed-off-by: Antti Palosaari
---
drivers/media/dvb-frontends/si2168.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
First 8 bytes belonging to firmware image were hard-coded and uploaded
by the driver mistakenly. Introduce new corrected firmware file and
remove those 8 bytes from the driver.
New firmware image could be extracted from the PCTV 292e driver CD
using following command:
$ dd if=/TVC 6.4.8/Driver/PC
Hi Sylwester,
On Fri, Jun 13, 2014 at 06:56:16PM +0200, Sylwester Nawrocki wrote:
[...]
> > @@ -3394,10 +3406,29 @@ static void coda_fw_callback(const struct firmware
> > *fw, void *context)
> > memcpy(dev->codebuf.vaddr, fw->data, fw->size);
> > release_firmware(fw);
> >
> > - ret =
On Thu, Jun 12, 2014 at 8:01 AM, Dan Carpenter wrote:
> We recently changed some locking around so we need some new unlocks on
> the error paths.
>
> Signed-off-by: Dan Carpenter
Applied!
Thanks,
--Prabhakar Lad
> ---
> v2: move the unlock so the list_for_each_entry_safe() loop is protected
>
Hello Philipp,
On 13/06/14 18:08, Philipp Zabel wrote:
> This patch allows to use the runtime pm and generic pm domain frameworks
> to completely gate power to the VPU if it is unused. This functionality
> is available on i.MX6.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/co
Allow userspace to enable cyclic intra refresh by setting the number of
intra macroblocks per frame to a non-zero value.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda.c b/driv
Use the mem2mem helpers introduced to get rid of some duplicated code.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 113 ++
1 file changed, 14 insertions(+), 99 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/pl
This patch allows to use the runtime pm and generic pm domain frameworks
to completely gate power to the VPU if it is unused. This functionality
is available on i.MX6.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 65 +++
1 file changed,
From: Michael Olbrich
In case no further buffers are queued after the stop command, restart
job scheduling explicitly.
Signed-off-by: Michael Olbrich
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/cod
From: Michael Olbrich
Some drivers might allow to decode remaining frames from an internal ringbuffer
after a decoder stop command. Allow those to call v4l2_m2m_try_schedule
directly.
Signed-off-by: Michael Olbrich
Signed-off-by: Philipp Zabel
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 3 ++
Using the coda_mutex lock to serialize hardware access would cause
"INFO: possible circular locking dependency detected" lockdep warnings.
Since the possible locking paths are hard to follow, serialize hardware
access with a single workqueue thread. Ultimately the workqueue could
be converted to on
This patch adds support for the VIDIOC_ENUM_FRAMESIZES ioctl.
When decoding H.264, the output frame size is rounded up to the
next multiple of the macroblock size (16 pixels).
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 59 +++
1 file
If the bitrate control is set, the encoder works in CBR mode, dynamically
changing the quantization parameters to achieve a constant bitrate.
With the min/max QP controls the quantization parameters can be limited
to a given range.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c |
v4l2_fh already contains a mem2mem context pointer. Use it.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 70 +--
1 file changed, 34 insertions(+), 36 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda
If the CODA reports macroblock errors, also set the VB2_BUF_STATE_ERROR flag
to alert userspace.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platfor
This disables forcing IDR frames at GOP size intervals on CODA7541 and CODA960,
which is only needed to work around a firmware bug on CodaDx6.
Instead, the V4L2_BUF_FLAG_KEYFRAME v4l2 buffer flag is cleared before marking
the source buffer done for dequeueing. Userspace can set it before queueing a
This patch adds support for the CODA960 VPU in Freescale i.MX6 SoCs.
It enables h.264 and MPEG4 encoding and decoding support. Besides the usual
register shifting, the CODA960 gains frame memory control and GDI registers
that are set up for linear mapping right now, needs ENC_PIC_SRC_INDEX to be
s
This adds a new function coda_check_firmware that does the firmware
version checks so that this can be done only once from coda_probe
instead of every time the runtime pm framework resumes the coda.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 42 +
CODA7541 only supports encoding h.264 frames with width and height that are
multiples of the macroblock size.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/coda.
The coda driver advertises timestamp_type V4L2_BUF_FLAG_TIMESTAMP_COPY on
both queues, so we have to copy timestamps from input v4l2 buffers to the
corresponding destination v4l2 buffers. Since the h.264 decoder can reorder
frames, a timestamp queue is needed to keep track of and assign the correct
This patch exports all auxiliary buffers, including SRAM, as debugfs binary
blobs for debugging purposes. It shows, for example, that psbuf currently
doesn't seem to be used at all on CODA7541, and that slicebuf and workbuf
usage is far from the maximum. It can also be used to validate SRAM size
al
The coda h.264 decoder also counts PIC_RUNs where no frame was decoded but
a frame was rotated out / marked as ready to be displayed. This causes an
offset between the incoming encoded frame's sequence number and the decode
sequence number returned by the coda. This patch introduces a sequence
coun
Hi,
the following series adds initial support for the CODA960 Video
Processing Unit on i.MX6Q/D/DL/S SoCs to the coda driver.
This series contains a few fixes and preparations, the CODA960
support patch, a rework of the hardware access serialization
into a single threaded workqueue, some cleanups
Previously we'd add one to this value, allocating one additional, superfluous
internal buffer.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index a6
Even though the CODA h.264 decoder always decodes complete macroblocks, we can
set the stride to the corresponding multiple of 16 and use a value smaller than
that as real width. Unfortunately the same doesn't work for height, as there
is no vertical linesperframe stride for discontiguous planar YU
On i.MX53 and i.MX6, the CODA VPU can be reset by the System Reset Controller.
We can use this to get out of dire situations, for example after a PIC_RUN
timeout.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 51 +++
1 file changed, 51 i
Currently the rotator unit is used to copy decoded frames out into buffers
provided by videobuf2. Since the CODA reports the I/P/B frame type of the
last decoded frame, and this frame will be copied out in a later device_run,
depending on display order, we have to store the frame type until such ti
bytesperline is calculated in multiple places, store it in the coda_q_data
structure. This will be more useful later when adding JPEG support.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --
If bitrate is not set, the encoder is running in VBR mode, with the
I- and P-frame quantization parameters configured from userspace.
For the quantization parameters, 0 is a valid value.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 4 ++--
1 file changed, 2 insertions(+), 2 d
The driver uses the genalloc API, which doesn't have stubs in
case GENERIC_ALLOCATOR is disabled.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 20f1655..1d2
This variable should be renamed to hold instead (temporarily stopping streaming
until new data is fed into the bitstream buffer).
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/coda.c b/drivers/media/pla
When encoding into h.264, the input frame stride needs to be a multiple of 16.
During allocation of the input buffers, it may not be known yet whether the
encoder should create h.264 or not. Assume the worst and always use a frame
stride that is a multiple of 16.
Signed-off-by: Philipp Zabel
---
This error was introduced by 5677e3b04d3b3961200aa2bb9cc715e709eafeb9
"[media] coda: update CODA7541 to firmware 1.4.50".
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers
OVL and BTP IRAM buffers are never used, setup the bits for
for DBK/BIT/IP usage depending on CODA version in one place.
Also, use a simple allocator function and group IRAM addresses
and size in a coda_aux_buf structure.
This is done in preparation for CODA960 support.
Signed-off-by: Philipp Zabe
The h.264 decoder produces capture frames that are a multiple of the macroblock
size (16 pixels). To inform userspace about invalid pixel data at the edges,
use the active and padded composing rectangles on the capture queue.
The cropping information is obtained from the h.264 sequence parameter se
This adds controls for the h.264 deblocking loop filter.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index fa7eaf
Am Donnerstag, den 12.06.2014, 14:05 -0700 schrieb Steve Longerbeam:
> Ok. Yes, we definitely need preview and MIPI CSI-2, and adding IC to the
> capture path is nice too, since it allows userland to select arbitrary user
> resolutions, pixel format color space, and also rotation controls.
No ques
Hi Tony,
On Friday 13 June 2014 04:10:12 Tony Lindgren wrote:
> * Laurent Pinchart [140613 03:30]:
> > On Friday 13 June 2014 00:53:25 Tony Lindgren wrote:
> > > * Laurent Pinchart [140612 23:48]:
> > > > On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
> > > > > 1. They live in separate h
commit 2a0a5472af5c ("omap3isp: Use the ARM DMA IOMMU-aware operations")
brought the omap3isp driver closer to using standard APIs, but also
introduced two problems:
a) it selects a particular IOMMU driver for no good reason. This just
causes hard to track dependency chains, in my case breaking
* Laurent Pinchart [140613 03:30]:
> Hi Tony,
>
> On Friday 13 June 2014 00:53:25 Tony Lindgren wrote:
> > * Laurent Pinchart [140612 23:48]:
> > > On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
> > > > 1. They live in separate hardware modules that can be clocked separately
> > >
> > >
Hi Tony,
On Friday 13 June 2014 00:53:25 Tony Lindgren wrote:
> * Laurent Pinchart [140612 23:48]:
> > On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
> > > 1. They live in separate hardware modules that can be clocked separately
> >
> > Actually I don't think that's true. The CSI2 PHY is
On Fri, Jun 13, 2014 at 12:27:54AM +0300, Antti Palosaari wrote:
> Moikka,
>
> The reason is that Avermedia has programmed wrong tuner ID to device
> eeprom. For one IT9135BX device I have it is set 0x38 (whilst Windows
> driver programs 0x60), no idea how others. That same issues was for
> AF9015
* Laurent Pinchart [140612 23:48]:
> On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
> >
> > 1. They live in separate hardware modules that can be clocked separately
>
> Actually I don't think that's true. The CSI2 PHY is part of the camera
> device,
> with all its registers but the one
47 matches
Mail list logo
