[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dmaengine
Subject:    Re: DMA Engine API multiplanar support
From:       Vinod Koul <vinod.koul () intel ! com>
Date:       2016-07-24 6:27:01
Message-ID: 20160724061501.GU9681 () localhost
[Download RAW message or body]

On Wed, Jul 13, 2016 at 11:24:55AM +0000, Radhey Shyam Pandey wrote:
> Hello All,
> 

Pls wrap within 80 chars, I have reflown below

> I am planning to write DMA driver for new Xilinx VDMA IP (HLS Based) and
> integrate it with Xilinx V4L2 capture pipeline.

It should be update on existing VDMA driver then?

> 
> For single DMA read/write transaction hardware requires two physically
> separate buffers for Y and CbCr components, which must be placed in two
> different memory banks.  i.e DMA reads YUV AXI-Stream for source(DEV) and
> put it MEM into planar format.
> 
> 
> V4L2_PIX_FMT_NV16 (Description) These are two-plane versions of the YUV
> 4:2:2 format.  The three components are separated into two sub-images or
> planes.  The Y plane is first. The Y plane has one byte per pixel.  For
> V4L2_PIX_FMT_NV16, a combined CbCr plane immediately follows the Y plane
> in memory.  The CbCr plane is the same width and height, in bytes, as the
> Y plane (and of the image).
> 
> So I need some attribute in struct dma_channel to indicate that it
> supports packed/planar format?
> 
> Also while programming DMA we need to provide the base address of Y plane
> and UV plane to hardware for one DMA transaction.  Current
> dmaengine_prep_* implementations doesn't provide an interface to program
> multiplanar channel address.

Sounds like interleaved API could be used here?

> 
> One way is to split programming of DMA channel into two
> dma_async_tx_descriptor's for each channel (Y and UV) request but that
> doesn't looks right. There will be two DMA/callbacks programming for a
> single DMA write/read transaction.  Any suggestions?

Nope doesnt look right. A descriptor is for channel, splitting them causes
all descriptor and cookie calculations and assumptions to go wrong

> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are
> not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any attachments
> immediately.

pls fix this as well.

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]