[PATCH v11 01/19] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

this add functions for: - remove buffers from src/dst queue by index - remove exact buffer from src/dst queue also extends m2m API to iterate over a list of src/dst buffers in safely and non-safely manner. Signed-off-by: Stanimir Varbanov ---

[PATCH v10 01/18] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

this add functions for: - remove buffers from src/dst queue by index - remove exact buffer from src/dst queue also extends m2m API to iterate over a list of src/dst buffers in safely and non-safely manner. Signed-off-by: Stanimir Varbanov ---

[PATCH v9 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

this add functions for: - remove buffers from src/dst queue by index - remove exact buffer from src/dst queue also extends m2m API to iterate over a list of src/dst buffers in safely and non-safely manner. Reviewed-by: Hans Verkuil Signed-off-by: Stanimir Varbanov

Re: [PATCH v8 02/10] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

On 04/28/17 11:13, Stanimir Varbanov wrote: > this add functions for: > - remove buffers from src/dst queue by index > - remove exact buffer from src/dst queue > > also extends m2m API to iterate over a list of src/dst buffers > in safely and non-safely manner. > > Signed-off-by: Stanimir

[PATCH v8 02/10] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

this add functions for: - remove buffers from src/dst queue by index - remove exact buffer from src/dst queue also extends m2m API to iterate over a list of src/dst buffers in safely and non-safely manner. Signed-off-by: Stanimir Varbanov ---

[PATCH v7 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

this add functions for: - remove buffers from src/dst queue by index - remove exact buffer from src/dst queue also extends m2m API to iterate over a list of src/dst buffers in safely and non-safely manner. Signed-off-by: Stanimir Varbanov ---

[PATCH v6 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

this add functions for: - remove buffers from src/dst queue by index - remove exact buffer from src/dst queue also extends m2m API to iterate over a list of src/dst buffers in safely and non-safely manner. Signed-off-by: Stanimir Varbanov ---

[PATCH v5 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

this add functions for: - remove buffers from src/dst queue by index - remove exact buffer from src/dst queue also extends m2m API to iterate over a list of src/dst buffers in safely and non-safely manner. Signed-off-by: Stanimir Varbanov ---

Re: [PATCH v4 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

Hi Hans, On 12/05/2016 01:25 PM, Hans Verkuil wrote: > On 12/01/2016 10:03 AM, Stanimir Varbanov wrote: >> this add functions for: >> - remove buffers from src/dst queue by index >> - remove exact buffer from src/dst queue >> >> also extends m2m API to iterate over a list of src/dst buffers

Re: [PATCH v4 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

On 12/01/2016 10:03 AM, Stanimir Varbanov wrote: > this add functions for: > - remove buffers from src/dst queue by index > - remove exact buffer from src/dst queue > > also extends m2m API to iterate over a list of src/dst buffers > in safely and non-safely manner. > > Signed-off-by:

Re: [PATCH v4 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

Hi Stanimir, [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.9-rc7 next-20161202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH v4 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

this add functions for: - remove buffers from src/dst queue by index - remove exact buffer from src/dst queue also extends m2m API to iterate over a list of src/dst buffers in safely and non-safely manner. Signed-off-by: Stanimir Varbanov ---

[PATCH 2/2] media: rcar_vin: move buffer management to .stop_streaming handler

This commit moves the buffer in use logic from the .buf_cleanup handler into .stop_streaming, based on advice that this is its proper logical home. By ensuring the list of pointers in priv-queue_buf[] is managed as soon as possible, we avoid warnings concerning buffers in ACTIVE state when the

rcar_vin video buffer management fixes, v3

. The series comprises: [PATCH 1/2] media: rcar_vin: helper function for streaming stop [PATCH 2/2] media: rcar_vin: move buffer management to Cheers, Wills -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More

Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

On Mon, 19 Jan 2015, Guennadi Liakhovetski wrote: On Mon, 19 Jan 2015, William Towle wrote: in the patchset Ben linked to above we think we have the appropriate loops: a for loop for queue_buf[], and list_for_each_safe() for anything left in priv-capture; this is consistent with

Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

On Mon, 19 Jan 2015, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: Well, I thought that too. Will's submission from last week has that change: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/87009 Anyway, yes, that looks better! But I would

Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

Hi, On Mon, 19 Jan 2015, William Towle wrote: On Mon, 19 Jan 2015, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: Well, I thought that too. Will's submission from last week has that change:

Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

On 01/19/2015 03:11 PM, William Towle wrote: On Mon, 19 Jan 2015, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: Well, I thought that too. Will's submission from last week has that change:

Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

On Mon, 19 Jan 2015, Ben Hutchings wrote: On Sun, 2015-01-18 at 22:23 +0100, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: From: William Towle william.to...@codethink.co.uk Move the buffer state test in the .buf_cleanup handler into .stop_streaming so

Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

On Sun, 2015-01-18 at 22:23 +0100, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: From: William Towle william.to...@codethink.co.uk Move the buffer state test in the .buf_cleanup handler into .stop_streaming so that a) the vb2_queue API is not subverted, and

Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

On Thu, 18 Dec 2014, Ben Hutchings wrote: From: William Towle william.to...@codethink.co.uk Move the buffer state test in the .buf_cleanup handler into .stop_streaming so that a) the vb2_queue API is not subverted, and b) tracking of active-state buffers via priv-queue_buf[] is handled as

[PATCH 2/2] media: rcar_vin: move buffer management to .stop_streaming handler

This commit moves the buffer in use logic from the .buf_cleanup handler into .stop_streaming, based on advice that this is its proper logical home. By ensuring the list of pointers in priv-queue_buf[] is managed as soon as possible, we avoid warnings concerning buffers in ACTIVE state when the

[RFC PATCH 0/5] media: rcar_vin: Fixes for buffer management

The following is a subset of our work in progress branch for video support on the Renesas Lager board, comprising hotfixes for video buffer management. We are successfully capturing single frames and video with the complete branch, and intend to follow up with stable patches from the branch

[PATCH 2/2] media: rcar_vin: move buffer management to .stop_streaming handler

This commit moves the buffer in use logic from the .buf_cleanup handler into .stop_streaming, based on advice that this is its proper logical home. By ensuring the list of pointers in priv-queue_buf[] is managed as soon as possible, we avoid warnings concerning buffers in ACTIVE state when the

[RFC PATCH 0/5] media: rcar_vin: Fixes for buffer management

race condition terminating stream media: rcar_vin: Clean up rcar_vin_irq William Towle (1): media: rcar_vin: move buffer management to .stop_streaming handler drivers/media/platform/soc_camera/rcar_vin.c | 109 ++ 1 file changed, 59 insertions(+), 50 deletions

[RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

From: William Towle william.to...@codethink.co.uk Move the buffer state test in the .buf_cleanup handler into .stop_streaming so that a) the vb2_queue API is not subverted, and b) tracking of active-state buffers via priv-queue_buf[] is handled as early as is possible Signed-off-by: William

Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler

Hello. On 12/18/2014 05:50 PM, Ben Hutchings wrote: From: William Towle william.to...@codethink.co.uk Move the buffer state test in the .buf_cleanup handler into .stop_streaming so that a) the vb2_queue API is not subverted, and b) tracking of active-state buffers via priv-queue_buf[] is

Re: [RFC PATCH 0/5] media: rcar_vin: Fixes for buffer management

are returned to error state before stopping. media: rcar_vin: Fix race condition terminating stream media: rcar_vin: Clean up rcar_vin_irq William Towle (1): media: rcar_vin: move buffer management to .stop_streaming handler Having actual fixes and clean-ups in a single series

[RFC] video-buffer management optimizations

Agenda: === User-space applications need more flexibility in managing their video- (multimedia-) buffers to achieve their goals. A popular example is a photo- camera with a preview. Currently the application has to first enter the preview mode: * set the preview format * allocate buffers (if

Re: buffer management

(dvb_dmabuf_dma_pos(dmabuf, i) | MAKE_IRQ); } RISC_JUMP(risc_dma); Other buffer management code isn't driver specific. One possible problem that remains with this approach, is that what if the DMA buffer gets overwritten? Then the pointers in the ringbuffer might become garbage. Another possible

Re: buffer management

Now, on each video interrupt, I know which SG list i need to read from. At this stage i do need to copy the buffers associated with each of the SG lists at once. In this scenario, I don't see how videobuf could be used, while I keep getting this feeling that a simple copy_to_user of the entire

Re: buffer management

23.06.2010 15:43, Steven Toth kirjoitti: Now, on each video interrupt, I know which SG list i need to read from. At this stage i do need to copy the buffers associated with each of the SG lists at once. In this scenario, I don't see how videobuf could be used, while I keep getting this feeling

buffer management

Hi All, While working on a driver, i stumbled up on this question. I have a driver where the driver allocates it's buffers (maybe it's better to term that the hardware requires it that way) in the following fashion: Buffer 1: SG list 1 Buffer 2: SG list 2 Buffer 3: SG list 3 Buffer 4: SG list 4