Hi Guennadi,
When I'm refining the patch based on your comments, I met an issue. Could you
please help me?
[snip]
>>> -
>>> /*
>>> * Configure the controller for operation; caller holds the
>>> * device mutex.
>>> @@ -979,11 +1070,32 @@ static void mcam_vb_buf_queue(struct vb2_buffer
>>> *vb) {
>>> struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
>>> struct mcam_camera *cam = vb2_get_drv_priv(vb->vb2_queue);
>>> + struct v4l2_pix_format *fmt = &cam->pix_format;
>>> unsigned long flags;
>>> int start;
>>> + dma_addr_t dma_handle;
>>> + u32 base_size = fmt->width * fmt->height;
>>
>>Shouldn't you be just using bytesperline? Is stride != width * height
>>supported?
>>
>We will update it.
[Libin] What I understand is width is the pixel number perline, so bytesperline
= width * BytePerPixel. This means bytesperline should include Y data and UV
data.
For example, for yuv420 legacy 8-bit, it transfers like below:
U Y Y U Y Y U Y Y U Y Y ......
V Y Y V Y Y V Y Y V Y Y ......
As each Y is one byte, so all Y data length is nuber_Y_per_line * height. While
the nuber_Y_per_line is the pixel_per_line, which is fmt->width.
So for the planner, the first block is saving the Y data, whose length is
nuber_Y_per_line * height, which equals to fmt->width * height.
Do I understand correctly?
The base_size here means the size of Y data, so it should be fmt->width *
fmt->height.
>>>
>>> spin_lock_irqsave(&cam->dev_lock, flags);
>>> + dma_handle = vb2_dma_contig_plane_dma_addr(vb, 0);
Best Regards,
Libin
--
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/majordomo-info.html
