On 17 April 2015 at 19:32, Alan Stern wrote:
> On Fri, 17 Apr 2015, Tomeu Vizoso wrote:
>
>> When the system goes to sleep and afterwards resumes, a significant
>> amount of time is spent suspending and resuming devices that were
>> already runtime-suspended.
>>
>> By setting the power.force_direc
Hi Prashant,
A few comments:
On 04/08/2015 02:57 PM, Prashant Laddha wrote:
> Extended detect_cvt/gtf API to indicate the scan type (interlaced
> or progressive). In case of interlaced, the vertical front and back
> porch and vsync values for both (odd,even) fields are considered to
> derive ima
Hi Mauro,
Would you please pull the following two patches for finally
mainlining the Technisat SkyStar S2 (and its frontend cx24120).
Ideally for 4.1, but I assume it is too late. So for 4.2.
Please also tell whether a pull-request is OK for you or whether you
prefer patches.
I'm based on the c
Am Donnerstag, den 16.04.2015, 10:23 +0200 schrieb Kamil Debski:
[...]
> > > But, in general, in what kind of scenario would the driver want to
> > > call this function, as opposed to vb2 clearing this flag by itself on
> > > STREAMOFF?
> >
> > There is VIDIOC_DECODER_CMD / V4L2_DEC_CMD_START.
> >
Document the interaction between VIDIOC_DECODER_CMD V4L2_DEC_CMD_STOP and
VIDIOC_ENCODER_CMD V4L2_ENC_CMD_STOP to start the draining, the V4L2_EVENT_EOS
event signalling all capture buffers are finished and ready to be dequeud,
the new V4L2_BUF_FLAG_LAST buffer flag indicating the last buffer being
From: Peter Seiderer
This v4l2_buffer flag can be used by drivers to mark a capture buffer
as the last generated buffer, for example after a V4L2_DEC_CMD_STOP
command was issued.
Signed-off-by: Peter Seiderer
Signed-off-by: Philipp Zabel
---
Changes since v4:
- Split out DocBook changes into
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver
Setting the last buffer flag causes the videobuf2 core to return -EPIPE from
DQBUF calls on the capture queue after the last buffer is dequeued.
This patch also fixes the EOS event to conform to the specification. It now is
sent right after the last buffer has been decoded instead of when the last
Setting the last buffer flag causes the videobuf2 core to return -EPIPE from
DQBUF calls on the capture queue after the last buffer is dequeued.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/s5
At the V4L2 codec API session during ELC-E 2014, we agreed that for the decoder
draining flow, after a V4L2_DEC_CMD_STOP decoder command was issued, the last
decoded buffer should get dequeued with a V4L2_BUF_FLAG_LAST set. After that,
poll should immediately return and all following VIDIOC_DQBUF s
Hi Johannes,
On Mon, 20 Apr 2015 10:20:47 +0200 Johannes Stezenbach
wrote:
> (add Mauro)
>
> On Sun, Apr 19, 2015 at 11:19:43PM +0200, Patrick Boettcher wrote:
> > On Fri, 17 Apr 2015 11:06:30 +0200
> > Patrick Boettcher wrote:
> > > http://git.linuxtv.org/cgit.cgi/pb/media_tree.git/ cx24120-v
Hi Laurent,
On 04/17/2015 05:07 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Saturday 21 March 2015 09:41:29 Hans Verkuil wrote:
>> I've been thinking about extending v4l2-compliance with v4l-subdev tests.
>>
>> However, there are a few missing pieces that are needed before this can be
>> done.
(add Mauro)
On Sun, Apr 19, 2015 at 11:19:43PM +0200, Patrick Boettcher wrote:
> On Fri, 17 Apr 2015 11:06:30 +0200
> Patrick Boettcher wrote:
> > http://git.linuxtv.org/cgit.cgi/pb/media_tree.git/ cx24120-v2
>
> Jannis pointed out, that my repository on linuxtv.org was not
> fetchable...
>
> I
Hi Sakari,
On 04/18/2015 03:04 PM, Sakari Ailus wrote:
> Hi Hans,
>
> On Fri, Apr 17, 2015 at 12:27:41PM +0200, Hans Verkuil wrote:
>> Hi Laurent,
>>
>> On 04/14/2015 09:44 PM, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> The v4l2_plane data_offset field has been introduced at the same time as the
On 04/17/2015 02:53 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Friday 17 April 2015 12:27:41 Hans Verkuil wrote:
>> On 04/14/2015 09:44 PM, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> The v4l2_plane data_offset field has been introduced at the same time as
>>> the the multiplane API to convey he
Hi Hans,
On Monday 20 April 2015 11:34:44 Hans Verkuil wrote:
> On 04/17/2015 02:53 PM, Laurent Pinchart wrote:
> > On Friday 17 April 2015 12:27:41 Hans Verkuil wrote:
> >> On 04/14/2015 09:44 PM, Laurent Pinchart wrote:
> >>> Hello,
> >>>
> >>> The v4l2_plane data_offset field has been introduc
Hi Hans,
On Monday 20 April 2015 10:37:59 Hans Verkuil wrote:
> On 04/17/2015 05:07 PM, Laurent Pinchart wrote:
> > On Saturday 21 March 2015 09:41:29 Hans Verkuil wrote:
> >> I've been thinking about extending v4l2-compliance with v4l-subdev tests.
> >>
> >> However, there are a few missing piec
Hi,
> From: Philipp Zabel [mailto:p.za...@pengutronix.de]
> Sent: Monday, April 20, 2015 10:28 AM
> To: Kamil Debski
> Cc: 'Pawel Osciak'; 'LMML'; 'Hans Verkuil'; 'Laurent Pinchart';
> 'Nicolas Dufresne'; 'Sakari Ailus'; ker...@pengutronix.de
> Subject: Re: [PATCH v4 2/4] [media] videobuf2: retur
On Mon, Apr 20, 2015 at 2:18 PM, Krzysztof Hałasa wrote:
> Andrey Utkin writes:
>
>> I am starting a work on driver for techwell tw5864 media grabber&encoder.
>
> If this is tw6864 then I have a driver mostly completed.
> Actually I'm using tw6869 but I think this is very similar (4 channels
> in
Andrey Utkin writes:
> I am starting a work on driver for techwell tw5864 media grabber&encoder.
If this is tw6864 then I have a driver mostly completed.
Actually I'm using tw6869 but I think this is very similar (4 channels
instead of 8 and PCI instead of PCIe). I have 6864s but haven't yet
tri
Andrey Utkin writes:
> Please check first digit. I mean _5_864, in your post there's 6869.
Ok, I just thought it may be a typo. I can now see 5864 is a H.264
encoder, while 686x are simpler frame-grabbers only.
Sorry for the noise.
--
Krzysztof Halasa
Research Institute for Automation and Mea
On Mon, Apr 20, 2015 at 3:45 PM, Krzysztof Hałasa wrote:
> Andrey Utkin writes:
>
>> Please check first digit. I mean _5_864, in your post there's 6869.
>
> Ok, I just thought it may be a typo. I can now see 5864 is a H.264
> encoder, while 686x are simpler frame-grabbers only.
>
> Sorry for the
Hi Hans,
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Friday, April 17, 2015 2:17 PM
>
> On 04/13/2015 03:19 PM, Kamil Debski wrote:
> > Hi Hans,
> >
> > Thank you so much for the review.
> >
> > From: linux-media-ow...@vger.k
Hi Hans,
On Monday 20 April 2015 11:16:53 Hans Verkuil wrote:
> On 04/18/2015 03:04 PM, Sakari Ailus wrote:
> > On Fri, Apr 17, 2015 at 12:27:41PM +0200, Hans Verkuil wrote:
> >> On 04/14/2015 09:44 PM, Laurent Pinchart wrote:
> >>> Hello,
> >>>
> >>> The v4l2_plane data_offset field has been int
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: Tue Apr 21 04:00:19 CEST 2015
git branch: test
git hash: e183201b9e917daf2530b637b2f34f1d5afb934d
gcc versi
25 matches
Mail list logo
