v4l: VPE mem to mem driver

drivers/media/platform/ti-vpe/vpdma.c new file +7 -0

+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for completion
+ */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list)
+{
+	/* we always use the first list */
+	int list_num = 0;

drivers/media/platform/ti-vpe/vpdma.c new file +32 -0

+	write_reg(vpdma, VPDMA_LIST_ATTR,
+			(list_num << VPDMA_LIST_NUM_SHFT) |
+			(list->type << VPDMA_LIST_TYPE_SHFT) |
+			list_size);
+
+	return 0;
+}
 
+static void vpdma_firmware_cb(const struct firmware *f, void *context)
+{
+	struct vpdma_data *vpdma = context;
+	struct vpdma_buf fw_dma_buf;
+	int i, r;
+
+	dev_dbg(&vpdma->pdev->dev, "firmware callback\n");
+
+	if (!f || !f->data) {
+		dev_err(&vpdma->pdev->dev, "couldn't get firmware\n");
+		return;
+	}
+
+	/* already initialized */
+	if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+			VPDMA_LIST_RDY_SHFT)) {
+		vpdma->ready = true;
+		return;
+	}
+
+	r = vpdma_buf_alloc(&fw_dma_buf, f->size);
+	if (r) {
+		dev_err(&vpdma->pdev->dev,
+			"failed to allocate dma buffer for firmware\n");
+		goto rel_fw;

drivers/media/platform/ti-vpe/vpdma.c new file +9 -0

+		if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+				VPDMA_LIST_RDY_SHFT))
+			break;
+	}
+
+	if (i == 100) {
+		dev_err(&vpdma->pdev->dev, "firmware upload failed\n");
+		goto free_buf;
+	}

Hi,

drivers/media/platform/ti-vpe/vpdma.c line 34

Quoted 5 lines · Archit Taneja

drivers/media/platform/ti-vpe/vpdma.c new file +5 -0

+struct vpdma_data_format vpdma_yuv_fmts[] = {
+	[VPDMA_DATA_FMT_Y444] = {
+		.data_type	= DATA_TYPE_Y444,
+		.depth		= 8,
+	},

This, and all the other tables, should probably be consts?

drivers/media/platform/ti-vpe/vpdma.c line 239

Quoted 9 lines

drivers/media/platform/ti-vpe/vpdma.c new file +8 -0

+static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
+{
+	u32 val = *valp;
+
+	val &= ~(mask << shift);
+	val |= (field & mask) << shift;
+	*valp = val;
+}

I think "insert" normally means, well, inserting a thing in between something. What you do here is overwriting.

Why not just call it "write_field"?

drivers/media/platform/ti-vpe/vpdma.c line 309

Quoted 7 lines

+ * Allocate a DMA buffer
+ */

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+	buf->size = size;
+	buf->mapped = 0;

Maybe true/false is clearer here that 0/1.

Quoted 12 lines

drivers/media/platform/ti-vpe/vpdma.c new file +11 -0

+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for completion
+ */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list)
+{
+	/* we always use the first list */
+	int list_num = 0;
+	int list_size;
+
+	if (vpdma_list_busy(vpdma, list_num))
+		return -EBUSY;

drivers/media/platform/ti-vpe/vpdma.c line 419

Quoted 6 lines

drivers/media/platform/ti-vpe/vpdma.c new file +6 -0

+
+	/* 16-byte granularity */
+	list_size = (list->next - list->buf.addr) >> 4;
+
+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list->buf.dma_addr);
+	wmb();

What is the wmb() for?

Quoted 40 lines

drivers/media/platform/ti-vpe/vpdma.c new file +38 -0

+	write_reg(vpdma, VPDMA_LIST_ATTR,
+			(list_num << VPDMA_LIST_NUM_SHFT) |
+			(list->type << VPDMA_LIST_TYPE_SHFT) |
+			list_size);
+
+	return 0;
+}
 
+static void vpdma_firmware_cb(const struct firmware *f, void *context)
+{
+	struct vpdma_data *vpdma = context;
+	struct vpdma_buf fw_dma_buf;
+	int i, r;
+
+	dev_dbg(&vpdma->pdev->dev, "firmware callback\n");
+
+	if (!f || !f->data) {
+		dev_err(&vpdma->pdev->dev, "couldn't get firmware\n");
+		return;
+	}
+
+	/* already initialized */
+	if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+			VPDMA_LIST_RDY_SHFT)) {
+		vpdma->ready = true;
+		return;
+	}
+
+	r = vpdma_buf_alloc(&fw_dma_buf, f->size);
+	if (r) {
+		dev_err(&vpdma->pdev->dev,
+			"failed to allocate dma buffer for firmware\n");
+		goto rel_fw;
+	}
+
+	memcpy(fw_dma_buf.addr, f->data, f->size);
+
+	vpdma_buf_map(vpdma, &fw_dma_buf);
+

drivers/media/platform/ti-vpe/vpdma.c line 511

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) fw_dma_buf.dma_addr);
+
+	for (i = 0; i < 100; i++) {		/* max 1 second */
+		msleep_interruptible(10);

You call interruptible version here, but you don't handle the interrupted case. I believe the loop will just continue looping, even if the user interrupted.

Quoted 13 lines · Tomi Valkeinen

Quoted 13 lines

+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for completion
+ */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list)

drivers/media/platform/ti-vpe/vpdma.c new file +7 -0

+{
+    /* we always use the first list */
+    int list_num = 0;
+    int list_size;
+
+    if (vpdma_list_busy(vpdma, list_num))
+        return -EBUSY;

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 419

Quoted 6 lines

drivers/media/platform/ti-vpe/vpdma.c new file +6 -0

+
+    /* 16-byte granularity */
+    list_size = (list->next - list->buf.addr) >> 4;
+
+    write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list->buf.dma_addr);
+    wmb();

What is the wmb() for?

VPDMA_LIST_ADDR needs to be written before VPDMA_LIST_ATTR, otherwise VPDMA doesn't work. wmb() ensures the ordering.

Quoted 7 lines

drivers/media/platform/ti-vpe/vpdma.c line 511

Quoted 3 lines

drivers/media/platform/ti-vpe/vpdma.c new file +3 -0

+
+    for (i = 0; i < 100; i++) {        /* max 1 second */
+        msleep_interruptible(10);

You call interruptible version here, but you don't handle the interrupted case. I believe the loop will just continue looping, even if the user interrupted.

Okay. I think I don't understand the interruptible version correctly. We don't need to msleep_interruptible here, we aren't waiting on any wake up event, we just want to wait till a bit gets set.

Quoted 8 lines · Tomi Valkeinen

drivers/media/platform/ti-vpe/vpdma.c line 34

Quoted 5 lines · Archit Taneja

drivers/media/platform/ti-vpe/vpdma.c new file +5 -0

+struct vpdma_data_format vpdma_yuv_fmts[] = {
+	[VPDMA_DATA_FMT_Y444] = {
+		.data_type	= DATA_TYPE_Y444,
+		.depth		= 8,
+	},

This, and all the other tables, should probably be consts?

That's true, I'll fix those.

Quoted 12 lines

drivers/media/platform/ti-vpe/vpdma.c line 239

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c new file +8 -0

+static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
+{
+	u32 val = *valp;
+
+	val &= ~(mask << shift);
+	val |= (field & mask) << shift;
+	*valp = val;
+}

I think "insert" normally means, well, inserting a thing in between something. What you do here is overwriting.

Quoted 1 line

Why not just call it "write_field"?

sure, will change it.

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 309

Quoted 6 lines

+ * Allocate a DMA buffer
+ */

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+	buf->size = size;
+	buf->mapped = 0;

Maybe true/false is clearer here that 0/1.

okay.

Quoted 11 lines

Quoted 11 lines

+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for completion + */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list) +{

drivers/media/platform/ti-vpe/vpdma.c new file +6 -0

+	/* we always use the first list */
+	int list_num = 0;
+	int list_size;
+
+	if (vpdma_list_busy(vpdma, list_num))
+		return -EBUSY;

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 419

Quoted 6 lines

drivers/media/platform/ti-vpe/vpdma.c new file +6 -0

+
+	/* 16-byte granularity */
+	list_size = (list->next - list->buf.addr) >> 4;
+
+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list->buf.dma_addr);
+	wmb();

What is the wmb() for?

VPDMA_LIST_ADDR needs to be written before VPDMA_LIST_ATTR, otherwise VPDMA doesn't work. wmb() ensures the ordering.

Quoted 39 lines

Quoted 39 lines

drivers/media/platform/ti-vpe/vpdma.c new file +38 -0

+	write_reg(vpdma, VPDMA_LIST_ATTR,
+			(list_num << VPDMA_LIST_NUM_SHFT) |
+			(list->type << VPDMA_LIST_TYPE_SHFT) |
+			list_size);
+
+	return 0;
+}
 
+static void vpdma_firmware_cb(const struct firmware *f, void *context)
+{
+	struct vpdma_data *vpdma = context;
+	struct vpdma_buf fw_dma_buf;
+	int i, r;
+
+	dev_dbg(&vpdma->pdev->dev, "firmware callback\n");
+
+	if (!f || !f->data) {
+		dev_err(&vpdma->pdev->dev, "couldn't get firmware\n");
+		return;
+	}
+
+	/* already initialized */
+	if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+			VPDMA_LIST_RDY_SHFT)) {
+		vpdma->ready = true;
+		return;
+	}
+
+	r = vpdma_buf_alloc(&fw_dma_buf, f->size);
+	if (r) {
+		dev_err(&vpdma->pdev->dev,
+			"failed to allocate dma buffer for firmware\n");
+		goto rel_fw;
+	}
+
+	memcpy(fw_dma_buf.addr, f->data, f->size);
+
+	vpdma_buf_map(vpdma, &fw_dma_buf);
+

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 511

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) fw_dma_buf.dma_addr);
+
+	for (i = 0; i < 100; i++) {		/* max 1 second */
+		msleep_interruptible(10);

You call interruptible version here, but you don't handle the interrupted case. I believe the loop will just continue looping, even if the user interrupted.

Okay. I think I don't understand the interruptible version correctly. We don't need to msleep_interruptible here, we aren't waiting on any wake up event, we just want to wait till a bit gets set.

I am thinking of implementing something similar to wait_for_bit_change() in 'drivers/video/omap2/dss/dsi.c'

Hi Archit,

Quoted 59 lines · On Monday 05 August 2013 16:56:46 Archit Taneja wrote:

Quoted 8 lines · Tomi Valkeinen

drivers/media/platform/ti-vpe/vpdma.c line 34

Quoted 5 lines · Archit Taneja

drivers/media/platform/ti-vpe/vpdma.c new file +5 -0

+struct vpdma_data_format vpdma_yuv_fmts[] = {
+	[VPDMA_DATA_FMT_Y444] = {
+		.data_type	= DATA_TYPE_Y444,
+		.depth		= 8,
+	},

This, and all the other tables, should probably be consts?

That's true, I'll fix those.

Quoted 12 lines

drivers/media/platform/ti-vpe/vpdma.c line 239

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c new file +8 -0

+static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
+{
+	u32 val = *valp;
+
+	val &= ~(mask << shift);
+	val |= (field & mask) << shift;
+	*valp = val;
+}

I think "insert" normally means, well, inserting a thing in between something. What you do here is overwriting.

Quoted 1 line

Why not just call it "write_field"?

sure, will change it.

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 309

Quoted 6 lines

+ * Allocate a DMA buffer
+ */

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+	buf->size = size;
+	buf->mapped = 0;

Maybe true/false is clearer here that 0/1.

okay.

Quoted 19 lines

Quoted 7 lines

+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for completion + */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list) +{

drivers/media/platform/ti-vpe/vpdma.c new file +2 -0

+	/* we always use the first list */
+	int list_num = 0;

drivers/media/platform/ti-vpe/vpdma.c line 419

Quoted 10 lines

drivers/media/platform/ti-vpe/vpdma.c new file +10 -0

+	int list_size;
+
+	if (vpdma_list_busy(vpdma, list_num))
+		return -EBUSY;
+
+	/* 16-byte granularity */
+	list_size = (list->next - list->buf.addr) >> 4;
+
+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list->buf.dma_addr);
+	wmb();

What is the wmb() for?

Quoted 2 lines

VPDMA_LIST_ADDR needs to be written before VPDMA_LIST_ATTR, otherwise VPDMA doesn't work. wmb() ensures the ordering.

write_reg() calls iowrite32(), which already includes an __iowmb().

The primary function of VPDMA is to move data between external memory and internal processing modules(in our case, VPE) that source or sink data. VPDMA is capable of buffering this data and then delivering the data as demanded to the modules as programmed. The modules that source or sink data are referred to as clients or ports. A channel is setup inside the VPDMA to connect a specific memory buffer to a specific client. The VPDMA centralizes the DMA control functions and buffering required to allow all the clients to minimize the effect of long latency times.

Add the following to the VPDMA helper:

- A data struct which describe VPDMA channels. For now, these channels are the ones used only by VPE, the list of channels will increase when VIP(Video Input Port) also uses the VPDMA library. This channel information will be used to populate fields required by data descriptors.

- Data structs which describe the different data types supported by VPDMA. This data type information will be used to populate fields required by data descriptors and used by the VPE driver to map a V4L2 format to the corresponding VPDMA data type.

- Provide VPDMA register offset definitions, functions to read, write and modify VPDMA registers.

- Functions to create and submit a VPDMA list. A list is a group of descriptors that makes up a set of DMA transfers that need to be completed. Each descriptor will either perform a DMA transaction to fetch input buffers and write to output buffers(data descriptors), or configure the MMRs of sub blocks of VPE(configuration descriptors), or provide control information to VPDMA (control descriptors).

- Functions to allocate, map and unmap buffers needed for the descriptor list, payloads containing MMR values and motion vector buffers. These use the DMA mapping APIs to ensure exclusive access to VPDMA.

- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on the VPE interrupt line when a descriptor list is parsed completely and the DMA transactions are completed. This requires masking the events in VPDMA registers and configuring some top level VPE interrupt registers.

- Enable some VPDMA specific parameters: frame start event(when to start DMA for a client) and line mode(whether each line fetched should be mirrored or not).

- Function to load firmware required by VPDMA. VPDMA requires a firmware for it's internal list manager. We add the required request_firmware apis to fetch this firmware from user space.

- Function to dump VPDMA registers.

- A function to initialize VPDMA, this will be called by the VPE driver with it's platform device pointer, this function will take care of loading VPDMA firmware and returning a handle back to the VPE driver. The VIP driver will also call the same init function to initialize it's own VPDMA instance.

Signed-off-by Archit Taneja <[email protected]>

---
 drivers/media/platform/ti-vpe/vpdma.c      | 589 ++++++++++++++++++++++++++
 drivers/media/platform/ti-vpe/vpdma.h      | 154 ++++++++
 drivers/media/platform/ti-vpe/vpdma_priv.h | 119 ++++++
 3 files changed, 862 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/vpdma.c
 create mode 100644 drivers/media/platform/ti-vpe/vpdma.h
 create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h

(quoted diff) +0 -0

b/drivers/media/platform/ti-vpe/vpdma.c new file mode 100644 index 0000000..b15b3dd

drivers/media/platform/ti-vpe/vpdma.c new file +0 -0

@@ -0,0 +1,589 @@

+static void insert_field_reg(struct vpdma_data *vpdma, int offset, u32 field,

drivers/media/platform/ti-vpe/vpdma.c new file +8 -0

+		u32 mask, int shift)
+{
+	u32 val = read_reg(vpdma, offset);
+
+	insert_field(&val, field, mask, shift);
+
+	write_reg(vpdma, offset, val);
+}

drivers/media/platform/ti-vpe/vpdma.c new file +18 -0

+	if (!buf->addr)
+		return -ENOMEM;
+
+	WARN_ON((u32) buf->addr & VPDMA_DESC_ALIGN);
+
+	return 0;
+}
+
+void vpdma_buf_free(struct vpdma_buf *buf)
+{
+	WARN_ON(buf->mapped != 0);
+	kfree(buf->addr);
+	buf->addr = NULL;
+	buf->size = 0;
+}
+
+/*
+ * map a DMA buffer, enabling DMA access

drivers/media/platform/ti-vpe/vpdma.c new file +18 -0

+}
+
+/*
+ * unmap a DMA buffer, disabling DMA access and
+ * allowing the main processor to acces the data
+ */
+void vpdma_buf_unmap(struct vpdma_data *vpdma, struct vpdma_buf *buf)
+{
+	struct device *dev = &vpdma->pdev->dev;
+
+	if (buf->mapped)
+		dma_unmap_single(dev, buf->dma_addr, buf->size, DMA_TO_DEVICE);
+
+	buf->mapped = 0;
+}
+
+/*
+ * create a descriptor list, the user of this list will append

configuration,
+ * contorl and data descriptors to this list, this list will be submitted

to
+ * VPDMA. VPDMA's list parser will go through each descriptor and perform
+ * the required DMA operations
+ */
+int vpdma_create_desc_list(struct vpdma_desc_list *list, size_t size, int type)

drivers/media/platform/ti-vpe/vpdma.c new file +16 -0

+{
+	int r;
+
+	r = vpdma_buf_alloc(&list->buf, size);
+	if (r)
+		return r;
+
+	list->next = list->buf.addr;
+
+	list->type = type;
+
+	return 0;
+}
+
+/*
+ * once a descriptor list is parsed by VPDMA, we reset the list by emptying

it,
+ * to allow new descriptors to be added to the list.
+ */

drivers/media/platform/ti-vpe/vpdma.c new file +7 -0

+void vpdma_reset_desc_list(struct vpdma_desc_list *list)
+{
+	list->next = list->buf.addr;
+}
+
+/*
+ * free the buffer allocated fot the VPDMA descriptor list, this should be

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+}
+
+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for

completion
+ */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list)

drivers/media/platform/ti-vpe/vpdma.c new file +124 -0

+{
+	/* we always use the first list */
+	int list_num = 0;
+	int list_size;
+
+	if (vpdma_list_busy(vpdma, list_num))
+		return -EBUSY;
+
+	/* 16-byte granularity */
+	list_size = (list->next - list->buf.addr) >> 4;
+
+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list->buf.dma_addr);
+	wmb();
+	write_reg(vpdma, VPDMA_LIST_ATTR,
+			(list_num << VPDMA_LIST_NUM_SHFT) |
+			(list->type << VPDMA_LIST_TYPE_SHFT) |
+			list_size);
+
+	return 0;
+}
+
+/* set or clear the mask for list complete interrupt */
+void vpdma_enable_list_complete_irq(struct vpdma_data *vpdma, int list_num,
+		bool enable)
+{
+	u32 val;
+
+	val = read_reg(vpdma, VPDMA_INT_LIST0_MASK);
+	if (enable)
+		val |= (1 << (list_num * 2));
+	else
+		val &= ~(1 << (list_num * 2));
+	write_reg(vpdma, VPDMA_INT_LIST0_MASK, val);
+}
+
+/* clear previosuly occured list intterupts in the LIST_STAT register */
+void vpdma_clear_list_stat(struct vpdma_data *vpdma)
+{
+	write_reg(vpdma, VPDMA_INT_LIST0_STAT,
+		read_reg(vpdma, VPDMA_INT_LIST0_STAT));
+}
+
+/*
+ * configures the output mode of the line buffer for the given client, the
+ * line buffer content can either be mirrored(each line repeated twice) or
+ * passed to the client as is
+ */
+void vpdma_set_line_mode(struct vpdma_data *vpdma, int line_mode,
+		enum vpdma_channel chan)
+{
+	int client_cstat = chan_info[chan].cstat_offset;
+
+	insert_field_reg(vpdma, client_cstat, line_mode,
+		VPDMA_CSTAT_LINE_MODE_MASK, VPDMA_CSTAT_LINE_MODE_SHIFT);
+}
+
+/*
+ * configures the event which should trigger VPDMA transfer for the given
+ * client
+ */
+void vpdma_set_frame_start_event(struct vpdma_data *vpdma,
+		enum vpdma_frame_start_event fs_event,
+		enum vpdma_channel chan)
+{
+	int client_cstat = chan_info[chan].cstat_offset;
+
+	insert_field_reg(vpdma, client_cstat, fs_event,
+		VPDMA_CSTAT_FRAME_START_MASK, VPDMA_CSTAT_FRAME_START_SHIFT);
+}
+
+static void vpdma_firmware_cb(const struct firmware *f, void *context)
+{
+	struct vpdma_data *vpdma = context;
+	struct vpdma_buf fw_dma_buf;
+	int i, r;
+
+	dev_dbg(&vpdma->pdev->dev, "firmware callback\n");
+
+	if (!f || !f->data) {
+		dev_err(&vpdma->pdev->dev, "couldn't get firmware\n");
+		return;
+	}
+
+	/* already initialized */
+	if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+			VPDMA_LIST_RDY_SHFT)) {
+		vpdma->ready = true;
+		return;
+	}
+
+	r = vpdma_buf_alloc(&fw_dma_buf, f->size);
+	if (r) {
+		dev_err(&vpdma->pdev->dev,
+			"failed to allocate dma buffer for firmware\n");
+		goto rel_fw;
+	}
+
+	memcpy(fw_dma_buf.addr, f->data, f->size);
+
+	vpdma_buf_map(vpdma, &fw_dma_buf);
+
+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) fw_dma_buf.dma_addr);
+
+	for (i = 0; i < 100; i++) {		/* max 1 second */
+		msleep_interruptible(10);
+
+		if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+				VPDMA_LIST_RDY_SHFT))
+			break;
+	}
+
+	if (i == 100) {
+		dev_err(&vpdma->pdev->dev, "firmware upload failed\n");
+		goto free_buf;
+	}
+
+	vpdma->ready = true;
+
+free_buf:
+	vpdma_buf_unmap(vpdma, &fw_dma_buf);
+
+	vpdma_buf_free(&fw_dma_buf);
+rel_fw:
+	release_firmware(f);

drivers/media/platform/ti-vpe/vpdma.c new file +12 -0

+{
+	struct resource *res;
+	struct vpdma_data *vpdma;
+	int r;
+
+	dev_dbg(&pdev->dev, "vpdma_init\n");
+
+	vpdma = devm_kzalloc(&pdev->dev, sizeof(*vpdma), GFP_KERNEL);
+	if (!vpdma) {
+		dev_err(&pdev->dev, "couldn't alloc vpdma_dev\n");
+		return -ENOMEM;
+	}

drivers/media/platform/ti-vpe/vpdma.c new file +16 -0

+	if (!vpdma->base) {
+		dev_err(&pdev->dev, "failed to ioremap\n");
+		return -ENOMEM;
+	}
+
+	r = vpdma_load_firmware(vpdma);
+	if (r) {
+		pr_err("failed to load firmware %s\n", VPDMA_FIRMWARE);
+		return r;
+	}
+
+	*pvpdma = vpdma;
+
+	return 0;
+}
+MODULE_FIRMWARE(VPDMA_FIRMWARE);

Hi Archit,

Thank you for the patch.

Quoted 71 lines · On Friday 02 August 2013 19:33:38 Archit Taneja wrote:

The primary function of VPDMA is to move data between external memory and internal processing modules(in our case, VPE) that source or sink data. VPDMA is capable of buffering this data and then delivering the data as demanded to the modules as programmed. The modules that source or sink data are referred to as clients or ports. A channel is setup inside the VPDMA to connect a specific memory buffer to a specific client. The VPDMA centralizes the DMA control functions and buffering required to allow all the clients to minimize the effect of long latency times.

Add the following to the VPDMA helper:

- A data struct which describe VPDMA channels. For now, these channels are the ones used only by VPE, the list of channels will increase when VIP(Video Input Port) also uses the VPDMA library. This channel information will be used to populate fields required by data descriptors.

- Data structs which describe the different data types supported by VPDMA. This data type information will be used to populate fields required by data descriptors and used by the VPE driver to map a V4L2 format to the corresponding VPDMA data type.

- Provide VPDMA register offset definitions, functions to read, write and modify VPDMA registers.

- Functions to create and submit a VPDMA list. A list is a group of descriptors that makes up a set of DMA transfers that need to be completed. Each descriptor will either perform a DMA transaction to fetch input buffers and write to output buffers(data descriptors), or configure the MMRs of sub blocks of VPE(configuration descriptors), or provide control information to VPDMA (control descriptors).

- Functions to allocate, map and unmap buffers needed for the descriptor list, payloads containing MMR values and motion vector buffers. These use the DMA mapping APIs to ensure exclusive access to VPDMA.

- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on the VPE interrupt line when a descriptor list is parsed completely and the DMA transactions are completed. This requires masking the events in VPDMA registers and configuring some top level VPE interrupt registers.

- Enable some VPDMA specific parameters: frame start event(when to start DMA for a client) and line mode(whether each line fetched should be mirrored or not).

- Function to load firmware required by VPDMA. VPDMA requires a firmware for it's internal list manager. We add the required request_firmware apis to fetch this firmware from user space.

- Function to dump VPDMA registers.

- A function to initialize VPDMA, this will be called by the VPE driver with it's platform device pointer, this function will take care of loading VPDMA firmware and returning a handle back to the VPE driver. The VIP driver will also call the same init function to initialize it's own VPDMA instance.

Signed-off-by Archit Taneja <[email protected]>

---
  drivers/media/platform/ti-vpe/vpdma.c      | 589 ++++++++++++++++++++++++++
  drivers/media/platform/ti-vpe/vpdma.h      | 154 ++++++++
  drivers/media/platform/ti-vpe/vpdma_priv.h | 119 ++++++
  3 files changed, 862 insertions(+)

create mode 100644 drivers/media/platform/ti-vpe/vpdma.c create mode 100644 drivers/media/platform/ti-vpe/vpdma.h create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h

(quoted diff) +0 -0

b/drivers/media/platform/ti-vpe/vpdma.c new file mode 100644 index 0000000..b15b3dd

drivers/media/platform/ti-vpe/vpdma.c new file +0 -0

@@ -0,0 +1,589 @@

[snip]

drivers/media/platform/ti-vpe/vpdma.c line 227

Quoted 7 lines

drivers/media/platform/ti-vpe/vpdma.c new file +7 -0

+static int get_field(u32 value, u32 mask, int shift)
+{
+	return (value & (mask << shift)) >> shift;
+}
+
+static int get_field_reg(struct vpdma_data *vpdma, int offset,
+		u32 mask, int shift)

I would call this read_field_reg().

drivers/media/platform/ti-vpe/vpdma.c line 239

Quoted 12 lines

drivers/media/platform/ti-vpe/vpdma.c new file +12 -0

+{
+	return get_field(read_reg(vpdma, offset), mask, shift);
+}
+
+static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
+{
+	u32 val = *valp;
+
+	val &= ~(mask << shift);
+	val |= (field & mask) << shift;
+	*valp = val;
+}

get_field() and insert_field() are used in a single location, you can manually inline them.

Quoted 11 lines

+static void insert_field_reg(struct vpdma_data *vpdma, int offset, u32 field,

drivers/media/platform/ti-vpe/vpdma.c new file +8 -0

+		u32 mask, int shift)
+{
+	u32 val = read_reg(vpdma, offset);
+
+	insert_field(&val, field, mask, shift);
+
+	write_reg(vpdma, offset, val);
+}

[snip]

drivers/media/platform/ti-vpe/vpdma.c line 310

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c new file +8 -0

+/*
+ * Allocate a DMA buffer
+ */
+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+	buf->size = size;
+	buf->mapped = 0;
+	buf->addr = kzalloc(size, GFP_KERNEL);

You should use the dma allocation API (depending on your needs, dma_alloc_coherent for instance) to allocate DMA-able buffers.

Quoted 23 lines

drivers/media/platform/ti-vpe/vpdma.c new file +22 -0

+	if (!buf->addr)
+		return -ENOMEM;
+
+	WARN_ON((u32) buf->addr & VPDMA_DESC_ALIGN);
+
+	return 0;
+}
+
+void vpdma_buf_free(struct vpdma_buf *buf)
+{
+	WARN_ON(buf->mapped != 0);
+	kfree(buf->addr);
+	buf->addr = NULL;
+	buf->size = 0;
+}
+
+/*
+ * map a DMA buffer, enabling DMA access
+ */
+void vpdma_buf_map(struct vpdma_data *vpdma, struct vpdma_buf *buf)
+{
+	struct device *dev = &vpdma->pdev->dev;

drivers/media/platform/ti-vpe/vpdma.c line 338

Quoted 6 lines

drivers/media/platform/ti-vpe/vpdma.c new file +6 -0

+
+	WARN_ON(buf->mapped != 0);
+	buf->dma_addr = dma_map_single(dev, buf->addr, buf->size,
+				DMA_TO_DEVICE);
+	buf->mapped = 1;
+	BUG_ON(dma_mapping_error(dev, buf->dma_addr));

BUG_ON() is too harsh, you should return a proper error instead.

Quoted 19 lines

drivers/media/platform/ti-vpe/vpdma.c new file +18 -0

+}
+
+/*
+ * unmap a DMA buffer, disabling DMA access and
+ * allowing the main processor to acces the data
+ */
+void vpdma_buf_unmap(struct vpdma_data *vpdma, struct vpdma_buf *buf)
+{
+	struct device *dev = &vpdma->pdev->dev;
+
+	if (buf->mapped)
+		dma_unmap_single(dev, buf->dma_addr, buf->size, DMA_TO_DEVICE);
+
+	buf->mapped = 0;
+}
+
+/*
+ * create a descriptor list, the user of this list will append

Quoted 2 lines

configuration,
+ * contorl and data descriptors to this list, this list will be submitted

s/contorl/control/

Quoted 36 lines

to
+ * VPDMA. VPDMA's list parser will go through each descriptor and perform
+ * the required DMA operations
+ */
+int vpdma_create_desc_list(struct vpdma_desc_list *list, size_t size, int type)

drivers/media/platform/ti-vpe/vpdma.c new file +16 -0

+{
+	int r;
+
+	r = vpdma_buf_alloc(&list->buf, size);
+	if (r)
+		return r;
+
+	list->next = list->buf.addr;
+
+	list->type = type;
+
+	return 0;
+}
+
+/*
+ * once a descriptor list is parsed by VPDMA, we reset the list by emptying

it,
+ * to allow new descriptors to be added to the list.
+ */

drivers/media/platform/ti-vpe/vpdma.c new file +11 -0

+void vpdma_reset_desc_list(struct vpdma_desc_list *list)
+{
+	list->next = list->buf.addr;
+}
+
+/*
+ * free the buffer allocated fot the VPDMA descriptor list, this should be
+ * called when the user doesn't want to use VPDMA any more.
+ */
+void vpdma_free_desc_list(struct vpdma_desc_list *list)
+{

drivers/media/platform/ti-vpe/vpdma.c line 396

Quoted 6 lines

drivers/media/platform/ti-vpe/vpdma.c new file +6 -0

+	vpdma_buf_free(&list->buf);
+
+	list->next = NULL;
+}
+
+static int vpdma_list_busy(struct vpdma_data *vpdma, int list_num)

Should the function return a bool instead of an int ?

drivers/media/platform/ti-vpe/vpdma.c line 400

Quoted 5 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+{
+	u32 sync_reg = read_reg(vpdma, VPDMA_LIST_STAT_SYNC);
+
+	return (sync_reg >> (list_num + 16)) & 0x01;

You could shorten that as

	return read_reg(vpdma, VPDMA_LIST_STAT_SYNC) & BIT(list_num + 16);

Quoted 139 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+}
+
+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for

completion
+ */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list)

drivers/media/platform/ti-vpe/vpdma.c new file +130 -0

+{
+	/* we always use the first list */
+	int list_num = 0;
+	int list_size;
+
+	if (vpdma_list_busy(vpdma, list_num))
+		return -EBUSY;
+
+	/* 16-byte granularity */
+	list_size = (list->next - list->buf.addr) >> 4;
+
+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list->buf.dma_addr);
+	wmb();
+	write_reg(vpdma, VPDMA_LIST_ATTR,
+			(list_num << VPDMA_LIST_NUM_SHFT) |
+			(list->type << VPDMA_LIST_TYPE_SHFT) |
+			list_size);
+
+	return 0;
+}
+
+/* set or clear the mask for list complete interrupt */
+void vpdma_enable_list_complete_irq(struct vpdma_data *vpdma, int list_num,
+		bool enable)
+{
+	u32 val;
+
+	val = read_reg(vpdma, VPDMA_INT_LIST0_MASK);
+	if (enable)
+		val |= (1 << (list_num * 2));
+	else
+		val &= ~(1 << (list_num * 2));
+	write_reg(vpdma, VPDMA_INT_LIST0_MASK, val);
+}
+
+/* clear previosuly occured list intterupts in the LIST_STAT register */
+void vpdma_clear_list_stat(struct vpdma_data *vpdma)
+{
+	write_reg(vpdma, VPDMA_INT_LIST0_STAT,
+		read_reg(vpdma, VPDMA_INT_LIST0_STAT));
+}
+
+/*
+ * configures the output mode of the line buffer for the given client, the
+ * line buffer content can either be mirrored(each line repeated twice) or
+ * passed to the client as is
+ */
+void vpdma_set_line_mode(struct vpdma_data *vpdma, int line_mode,
+		enum vpdma_channel chan)
+{
+	int client_cstat = chan_info[chan].cstat_offset;
+
+	insert_field_reg(vpdma, client_cstat, line_mode,
+		VPDMA_CSTAT_LINE_MODE_MASK, VPDMA_CSTAT_LINE_MODE_SHIFT);
+}
+
+/*
+ * configures the event which should trigger VPDMA transfer for the given
+ * client
+ */
+void vpdma_set_frame_start_event(struct vpdma_data *vpdma,
+		enum vpdma_frame_start_event fs_event,
+		enum vpdma_channel chan)
+{
+	int client_cstat = chan_info[chan].cstat_offset;
+
+	insert_field_reg(vpdma, client_cstat, fs_event,
+		VPDMA_CSTAT_FRAME_START_MASK, VPDMA_CSTAT_FRAME_START_SHIFT);
+}
+
+static void vpdma_firmware_cb(const struct firmware *f, void *context)
+{
+	struct vpdma_data *vpdma = context;
+	struct vpdma_buf fw_dma_buf;
+	int i, r;
+
+	dev_dbg(&vpdma->pdev->dev, "firmware callback\n");
+
+	if (!f || !f->data) {
+		dev_err(&vpdma->pdev->dev, "couldn't get firmware\n");
+		return;
+	}
+
+	/* already initialized */
+	if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+			VPDMA_LIST_RDY_SHFT)) {
+		vpdma->ready = true;
+		return;
+	}
+
+	r = vpdma_buf_alloc(&fw_dma_buf, f->size);
+	if (r) {
+		dev_err(&vpdma->pdev->dev,
+			"failed to allocate dma buffer for firmware\n");
+		goto rel_fw;
+	}
+
+	memcpy(fw_dma_buf.addr, f->data, f->size);
+
+	vpdma_buf_map(vpdma, &fw_dma_buf);
+
+	write_reg(vpdma, VPDMA_LIST_ADDR, (u32) fw_dma_buf.dma_addr);
+
+	for (i = 0; i < 100; i++) {		/* max 1 second */
+		msleep_interruptible(10);
+
+		if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+				VPDMA_LIST_RDY_SHFT))
+			break;
+	}
+
+	if (i == 100) {
+		dev_err(&vpdma->pdev->dev, "firmware upload failed\n");
+		goto free_buf;
+	}
+
+	vpdma->ready = true;
+
+free_buf:
+	vpdma_buf_unmap(vpdma, &fw_dma_buf);
+
+	vpdma_buf_free(&fw_dma_buf);
+rel_fw:
+	release_firmware(f);
+}
+
+static int vpdma_load_firmware(struct vpdma_data *vpdma)
+{
+	int r;
+	struct device *dev = &vpdma->pdev->dev;

drivers/media/platform/ti-vpe/vpdma.c line 540

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+
+	r = request_firmware_nowait(THIS_MODULE, 1,
+		(const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
+		vpdma_firmware_cb);

Is there a reason not to use the synchronous interface ? That would simplify both this code and the callers, as they won't have to check whether the firmware has been correctly loaded.

Quoted 7 lines

drivers/media/platform/ti-vpe/vpdma.c new file +7 -0

+	if (r) {
+		dev_err(dev, "firmware not available %s\n", VPDMA_FIRMWARE);
+		return r;
+	} else {
+		dev_info(dev, "loading firmware %s\n", VPDMA_FIRMWARE);
+	}
+

drivers/media/platform/ti-vpe/vpdma.c line 551

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+	return 0;
+}
+
+int vpdma_init(struct platform_device *pdev, struct vpdma_data **pvpdma)

As the function allocates the vpdma instance, I would call it vpdma_create() and make it turn a struct vpdma_data *. You can then return error codes using ERR_PTR().

Quoted 19 lines

drivers/media/platform/ti-vpe/vpdma.c new file +18 -0

+{
+	struct resource *res;
+	struct vpdma_data *vpdma;
+	int r;
+
+	dev_dbg(&pdev->dev, "vpdma_init\n");
+
+	vpdma = devm_kzalloc(&pdev->dev, sizeof(*vpdma), GFP_KERNEL);
+	if (!vpdma) {
+		dev_err(&pdev->dev, "couldn't alloc vpdma_dev\n");
+		return -ENOMEM;
+	}
+
+	vpdma->pdev = pdev;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vpdma");
+	if (res == NULL) {
+		dev_err(&pdev->dev, "missing platform resources data\n");

drivers/media/platform/ti-vpe/vpdma.c line 573

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+		return -ENODEV;
+	}
+
+	vpdma->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));

You can use devm_ioremap_resource(). The function checks the res pointer and prints error messages, so you can remove the res == NULL check above and the dev_err() below.

Quoted 58 lines · Laurent Pinchart

Quoted 57 lines · On Friday 02 August 2013 19:33:38 Archit Taneja wrote:

The primary function of VPDMA is to move data between external memory and internal processing modules(in our case, VPE) that source or sink data. VPDMA is capable of buffering this data and then delivering the data as demanded to the modules as programmed. The modules that source or sink data are referred to as clients or ports. A channel is setup inside the VPDMA to connect a specific memory buffer to a specific client. The VPDMA centralizes the DMA control functions and buffering required to allow all the clients to minimize the effect of long latency times.

Add the following to the VPDMA helper:

- A data struct which describe VPDMA channels. For now, these channels are the ones used only by VPE, the list of channels will increase when VIP(Video Input Port) also uses the VPDMA library. This channel information will be used to populate fields required by data descriptors.

- Data structs which describe the different data types supported by VPDMA. This data type information will be used to populate fields required by data descriptors and used by the VPE driver to map a V4L2 format to the corresponding VPDMA data type.

- Provide VPDMA register offset definitions, functions to read, write and modify VPDMA registers.

- Functions to create and submit a VPDMA list. A list is a group of descriptors that makes up a set of DMA transfers that need to be completed. Each descriptor will either perform a DMA transaction to fetch input buffers and write to output buffers(data descriptors), or configure the MMRs of sub blocks of VPE(configuration descriptors), or provide control information to VPDMA (control descriptors).

- Functions to allocate, map and unmap buffers needed for the descriptor list, payloads containing MMR values and motion vector buffers. These use the DMA mapping APIs to ensure exclusive access to VPDMA.

- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on the VPE interrupt line when a descriptor list is parsed completely and the DMA transactions are completed. This requires masking the events in VPDMA registers and configuring some top level VPE interrupt registers.

- Enable some VPDMA specific parameters: frame start event(when to start DMA for a client) and line mode(whether each line fetched should be mirrored or not).

- Function to load firmware required by VPDMA. VPDMA requires a firmware for it's internal list manager. We add the required request_firmware apis to fetch this firmware from user space.

- Function to dump VPDMA registers.

- A function to initialize VPDMA, this will be called by the VPE driver with it's platform device pointer, this function will take care of loading VPDMA firmware and returning a handle back to the VPE driver. The VIP driver will also call the same init function to initialize it's own VPDMA instance.

Signed-off-by Archit Taneja <[email protected]>

Quoted 11 lines

drivers/media/platform/ti-vpe/vpdma.c line 310

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c new file +8 -0

+/*
+ * Allocate a DMA buffer
+ */
+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+	buf->size = size;
+	buf->mapped = 0;
+	buf->addr = kzalloc(size, GFP_KERNEL);

You should use the dma allocation API (depending on your needs, dma_alloc_coherent for instance) to allocate DMA-able buffers.

I'm not sure about this, dma_map_single() api works fine on kzalloc'd buffers. The above function is used to allocate small contiguous buffers (never more than 1024 bytes) needed for descriptors for the DMA IP. I thought of using DMA pool, but that creates small buffers of the same size. So I finally went with kzalloc.

Quoted 7 lines

Quoted 7 lines

drivers/media/platform/ti-vpe/vpdma.c new file +7 -0

+	if (!buf->addr)
+		return -ENOMEM;
+
+	WARN_ON((u32) buf->addr & VPDMA_DESC_ALIGN);
+
+	return 0;
+}

Quoted 4 lines

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+static int vpdma_load_firmware(struct vpdma_data *vpdma)
+{
+	int r;
+	struct device *dev = &vpdma->pdev->dev;

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 540

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+
+	r = request_firmware_nowait(THIS_MODULE, 1,
+		(const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
+		vpdma_firmware_cb);

Is there a reason not to use the synchronous interface ? That would simplify both this code and the callers, as they won't have to check whether the firmware has been correctly loaded.

I'm not clear what you mean by that, the firmware would be stored in the filesystem. If the driver is built-in, then the synchronous interface wouldn't work unless the firmware is appended to the kernel image. Am I missing something here? I'm not very aware of the firmware api.

Quoted 9 lines

Quoted 9 lines

drivers/media/platform/ti-vpe/vpdma.c new file +9 -0

+	if (r) {
+		dev_err(dev, "firmware not available %s\n", VPDMA_FIRMWARE);
+		return r;
+	} else {
+		dev_info(dev, "loading firmware %s\n", VPDMA_FIRMWARE);
+	}
+
+	return 0;
+}

Hi Archit,

Quoted 59 lines · On Wednesday 14 August 2013 16:27:57 Archit Taneja wrote:

Quoted 58 lines · Laurent Pinchart

Quoted 57 lines · On Friday 02 August 2013 19:33:38 Archit Taneja wrote:

The primary function of VPDMA is to move data between external memory and internal processing modules(in our case, VPE) that source or sink data. VPDMA is capable of buffering this data and then delivering the data as demanded to the modules as programmed. The modules that source or sink data are referred to as clients or ports. A channel is setup inside the VPDMA to connect a specific memory buffer to a specific client. The VPDMA centralizes the DMA control functions and buffering required to allow all the clients to minimize the effect of long latency times.

Add the following to the VPDMA helper:

- A data struct which describe VPDMA channels. For now, these channels are the ones used only by VPE, the list of channels will increase when VIP(Video Input Port) also uses the VPDMA library. This channel information will be used to populate fields required by data descriptors.

- Data structs which describe the different data types supported by VPDMA. This data type information will be used to populate fields required by data descriptors and used by the VPE driver to map a V4L2 format to the corresponding VPDMA data type.

- Provide VPDMA register offset definitions, functions to read, write and modify VPDMA registers.

- Functions to create and submit a VPDMA list. A list is a group of descriptors that makes up a set of DMA transfers that need to be completed. Each descriptor will either perform a DMA transaction to fetch input buffers and write to output buffers(data descriptors), or configure the MMRs of sub blocks of VPE(configuration descriptors), or provide control information to VPDMA (control descriptors).

- Functions to allocate, map and unmap buffers needed for the descriptor list, payloads containing MMR values and motion vector buffers. These use the DMA mapping APIs to ensure exclusive access to VPDMA.

- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on the VPE interrupt line when a descriptor list is parsed completely and the DMA transactions are completed. This requires masking the events in VPDMA registers and configuring some top level VPE interrupt registers.

- Enable some VPDMA specific parameters: frame start event(when to start DMA for a client) and line mode(whether each line fetched should be mirrored or not).

- Function to load firmware required by VPDMA. VPDMA requires a firmware for it's internal list manager. We add the required request_firmware apis to fetch this firmware from user space.

- Function to dump VPDMA registers.

- A function to initialize VPDMA, this will be called by the VPE driver with it's platform device pointer, this function will take care of loading VPDMA firmware and returning a handle back to the VPE driver. The VIP driver will also call the same init function to initialize it's own VPDMA instance.

Signed-off-by Archit Taneja <[email protected]>

[snip]

Quoted 12 lines

Quoted 11 lines

drivers/media/platform/ti-vpe/vpdma.c line 310

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c new file +8 -0

+/*
+ * Allocate a DMA buffer
+ */
+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+	buf->size = size;
+	buf->mapped = 0;
+	buf->addr = kzalloc(size, GFP_KERNEL);

You should use the dma allocation API (depending on your needs, dma_alloc_coherent for instance) to allocate DMA-able buffers.

Quoted 5 lines

I'm not sure about this, dma_map_single() api works fine on kzalloc'd buffers. The above function is used to allocate small contiguous buffers (never more than 1024 bytes) needed for descriptors for the DMA IP. I thought of using DMA pool, but that creates small buffers of the same size. So I finally went with kzalloc.

OK, I mistakenly thought it would allocate larger buffers as well. If it's used to allocate descriptors only, would it be better to rename it to vpdma_desc_alloc() (or something similar) ?

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c new file +7 -0

+	if (!buf->addr)
+		return -ENOMEM;
+
+	WARN_ON((u32) buf->addr & VPDMA_DESC_ALIGN);
+
+	return 0;
+}

[snip]

Quoted 13 lines

Quoted 4 lines

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+static int vpdma_load_firmware(struct vpdma_data *vpdma)
+{
+	int r;
+	struct device *dev = &vpdma->pdev->dev;

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 540

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+
+	r = request_firmware_nowait(THIS_MODULE, 1,
+		(const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
+		vpdma_firmware_cb);

Is there a reason not to use the synchronous interface ? That would simplify both this code and the callers, as they won't have to check whether the firmware has been correctly loaded.

Quoted 4 lines

I'm not clear what you mean by that, the firmware would be stored in the filesystem. If the driver is built-in, then the synchronous interface wouldn't work unless the firmware is appended to the kernel image. Am I missing something here? I'm not very aware of the firmware api.

request_firmware() would just sleep (with a 30 seconds timeout if I'm not mistaken) until userspace provides the firmware. As devices are probed asynchronously (in kernel threads) the system will just boot normally, and the request_firmware() call will return when the firmware is available.

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

drivers/media/platform/ti-vpe/vpdma.c new file +9 -0

+	if (r) {
+		dev_err(dev, "firmware not available %s\n", VPDMA_FIRMWARE);
+		return r;
+	} else {
+		dev_info(dev, "loading firmware %s\n", VPDMA_FIRMWARE);
+	}
+
+	return 0;
+}

Quoted 13 lines

Quoted 4 lines

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+static int vpdma_load_firmware(struct vpdma_data *vpdma)
+{
+	int r;
+	struct device *dev = &vpdma->pdev->dev;

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 540

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+
+	r = request_firmware_nowait(THIS_MODULE, 1,
+		(const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
+		vpdma_firmware_cb);

Is there a reason not to use the synchronous interface ? That would simplify both this code and the callers, as they won't have to check whether the firmware has been correctly loaded.

Quoted 4 lines

I'm not clear what you mean by that, the firmware would be stored in the filesystem. If the driver is built-in, then the synchronous interface wouldn't work unless the firmware is appended to the kernel image. Am I missing something here? I'm not very aware of the firmware api.

request_firmware() would just sleep (with a 30 seconds timeout if I'm not mistaken) until userspace provides the firmware. As devices are probed asynchronously (in kernel threads) the system will just boot normally, and the request_firmware() call will return when the firmware is available.

On Tuesday 20 August 2013 05:09 PM, Laurent Pinchart wrote:

<snip>

Quoted 18 lines

Quoted 13 lines

Quoted 4 lines

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+static int vpdma_load_firmware(struct vpdma_data *vpdma)
+{
+	int r;
+	struct device *dev = &vpdma->pdev->dev;

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 540

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+
+	r = request_firmware_nowait(THIS_MODULE, 1,
+		(const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
+		vpdma_firmware_cb);

Is there a reason not to use the synchronous interface ? That would simplify both this code and the callers, as they won't have to check whether the firmware has been correctly loaded.

Quoted 4 lines

I'm not clear what you mean by that, the firmware would be stored in the filesystem. If the driver is built-in, then the synchronous interface wouldn't work unless the firmware is appended to the kernel image. Am I missing something here? I'm not very aware of the firmware api.

Quoted 4 lines

request_firmware() would just sleep (with a 30 seconds timeout if I'm not mistaken) until userspace provides the firmware. As devices are probed asynchronously (in kernel threads) the system will just boot normally, and the request_firmware() call will return when the firmware is available.

Sorry, I sent the previous mail bit too early.

With request_firmware() and the driver built-in, I see that the kernel stalls for 10 seconds at the driver's probe, and the firware loading fails since we didn't enter userspace where the file is.

The probing of devices asynchronously with kernel threads makes sense, so it's possible that I'm doing something wrong here. I'll give it a try again

Hi Archit,

Quoted 27 lines · On Tuesday 20 August 2013 18:46:38 Archit Taneja wrote:

On Tuesday 20 August 2013 05:09 PM, Laurent Pinchart wrote:

<snip>

Quoted 18 lines

Quoted 13 lines

Quoted 4 lines

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+static int vpdma_load_firmware(struct vpdma_data *vpdma)
+{
+	int r;
+	struct device *dev = &vpdma->pdev->dev;

Quoted 8 lines

drivers/media/platform/ti-vpe/vpdma.c line 540

Quoted 4 lines

drivers/media/platform/ti-vpe/vpdma.c new file +4 -0

+
+	r = request_firmware_nowait(THIS_MODULE, 1,
+		(const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
+		vpdma_firmware_cb);

Is there a reason not to use the synchronous interface ? That would simplify both this code and the callers, as they won't have to check whether the firmware has been correctly loaded.

Quoted 4 lines

I'm not clear what you mean by that, the firmware would be stored in the filesystem. If the driver is built-in, then the synchronous interface wouldn't work unless the firmware is appended to the kernel image. Am I missing something here? I'm not very aware of the firmware api.

Quoted 4 lines

request_firmware() would just sleep (with a 30 seconds timeout if I'm not mistaken) until userspace provides the firmware. As devices are probed asynchronously (in kernel threads) the system will just boot normally, and the request_firmware() call will return when the firmware is available.

Quoted 8 lines

Sorry, I sent the previous mail bit too early.

With request_firmware() and the driver built-in, I see that the kernel stalls for 10 seconds at the driver's probe, and the firware loading fails since we didn't enter userspace where the file is.

The probing of devices asynchronously with kernel threads makes sense, so it's possible that I'm doing something wrong here. I'll give it a try again

I might have spoken too fast. It looks like module initcalls are not run in threads. I've most probably mistaken that with asynchronous probing of hot- pluggable devices.

If your driver is built-in then it looks like the correct solution is to build the firmware in the kernel image as well, or use the asynchronous API as you did.

Create functions which the VPE driver can use to create a VPDMA descriptor and add it to a VPDMA descriptor list. These functions take a pointer to an existing list, and append the configuration/data/control descriptor header to the list.

In the case of configuration descriptors, the creation of a payload block may be required(the payloads can hold VPE MMR values, or scaler coefficients). The allocation of the payload buffer and it's content is left to the VPE driver. However, the VPDMA library provides helper macros to create payload in the correct format.

Add debug functions to dump the descriptors in a way such that it's easy to see the values of different fields in the descriptors.

Signed-off-by Archit Taneja <[email protected]>

---
 drivers/media/platform/ti-vpe/vpdma.c      | 269 +++++++++++
 drivers/media/platform/ti-vpe/vpdma.h      |  48 ++
 drivers/media/platform/ti-vpe/vpdma_priv.h | 695 +++++++++++++++++++++++++++++
 3 files changed, 1012 insertions(+)

drivers/media/platform/ti-vpe/vpdma.c +15 -0

index b15b3dd..b957381 100644
@@ -21,6 +21,7 @@
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
+#include <linux/videodev2.h>
 
 #include "vpdma.h"
 #include "vpdma_priv.h"

@@ -425,6 +426,274 @@ int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list)
 	return 0;
 }
 
+static void dump_cfd(struct vpdma_cfd *cfd)
+{
+	int class;
+
+	class = cfd_get_class(cfd);
+
+	pr_debug("config descriptor of payload class: %s\n",
+		class == CFD_CLS_BLOCK ? "simple block" :
+		"address data block");
+
+	if (class == CFD_CLS_BLOCK)
+		pr_debug("word0: dst_addr_offset = 0x%08x\n",
+			cfd_get_dest_addr_offset(cfd));
+

Quoted 4 lines · Archit Taneja

Create functions which the VPE driver can use to create a VPDMA descriptor and add it to a VPDMA descriptor list. These functions take a pointer to an existing list, and append the configuration/data/control descriptor header to the list.

Quoted 8 lines

In the case of configuration descriptors, the creation of a payload block may be required(the payloads can hold VPE MMR values, or scaler coefficients). The allocation of the payload buffer and it's content is left to the VPE driver. However, the VPDMA library provides helper macros to create payload in the correct format.

Add debug functions to dump the descriptors in a way such that it's easy to see the values of different fields in the descriptors.

There are lots of defines and inline functions in this patch. But at least the ones I looked at were only used once.

For example, dtd_set_xfer_length_height() is called only in one place. Then dtd_set_xfer_length_height() uses DTD_W1(), and again it's the only place where DTD_W1() is used.

So instead of:

dtd_set_xfer_length_height(dtd, c_rect->width, height);

You could as well do:

dtd->xfer_length_height = (c_rect->width << DTD_LINE_LENGTH_SHFT) | height;

Now, presuming the compiler optimizes correctly, there should be no difference between the two options above. My only point is that I wonder if having multiple "layers" there improves readability at all. Some helper funcs are rather trivial, like:

drivers/media/platform/ti-vpe/vpdma_priv.h +4 -0

+static inline void dtd_set_w1(struct vpdma_dtd *dtd, u32 value)
+{
+	dtd->w1 = value;
+}

Then there are some, like dtd_set_type_ctl_stride(), that contains lots of parameters. Hmm, okay, dtd_set_type_ctl_stride() is called in two places, so at least in that case it makes sense to have that helper func. But dtd_set_type_ctl_stride() uses DTD_W0(), and that's again the only place where it's used.

So, I don't know. I'm not suggesting to change anything, I just started wondering if all those macros and helpers actually help or not.

Quoted 45 lines

Signed-off-by Archit Taneja <[email protected]>

---
  drivers/media/platform/ti-vpe/vpdma.c      | 269 +++++++++++
  drivers/media/platform/ti-vpe/vpdma.h      |  48 ++
  drivers/media/platform/ti-vpe/vpdma_priv.h | 695 +++++++++++++++++++++++++++++
  3 files changed, 1012 insertions(+)

drivers/media/platform/ti-vpe/vpdma.c +22 -0

index b15b3dd..b957381 100644
@@ -21,6 +21,7 @@
  #include <linux/platform_device.h>
  #include <linux/sched.h>
  #include <linux/slab.h>
+#include <linux/videodev2.h>
 
  #include "vpdma.h"
  #include "vpdma_priv.h"

@@ -425,6 +426,274 @@ int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list)
  	return 0;
  }
 
+static void dump_cfd(struct vpdma_cfd *cfd)
+{
+	int class;
+
+	class = cfd_get_class(cfd);
+
+	pr_debug("config descriptor of payload class: %s\n",
+		class == CFD_CLS_BLOCK ? "simple block" :
+		"address data block");
+
+	if (class == CFD_CLS_BLOCK)
+		pr_debug("word0: dst_addr_offset = 0x%08x\n",
+			cfd_get_dest_addr_offset(cfd));
+
+	if (class == CFD_CLS_BLOCK)
+		pr_debug("word1: num_data_wrds = %d\n", cfd_get_block_len(cfd));
+
+	pr_debug("word2: payload_addr = 0x%08x\n", cfd_get_payload_addr(cfd));
+
+	pr_debug("word3: pkt_type = %d, direct = %d, class = %d, dest = %d, "
+		"payload_len = %d\n", cfd_get_pkt_type(cfd),

drivers/media/platform/ti-vpe/vpdma.c int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list) · line 452

Quoted 3 lines

drivers/media/platform/ti-vpe/vpdma.c +3 -0

+		cfd_get_direct(cfd), class, cfd_get_dest(cfd),
+		cfd_get_payload_len(cfd));
+}

There's quite a bit of code in these dump functions, and they are always called. I'm sure getting that data is good for debugging, but I presume they are quite useless for normal use. So I think they should be compiled in only if some Kconfig option is selected.

drivers/media/platform/ti-vpe/vpdma.c int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list) · line 456

Quoted 5 lines

drivers/media/platform/ti-vpe/vpdma.c +4 -0

+/*
+ * data transfer descriptor
+ *
+ * All fields are 32 bits to make them endian neutral

What does that mean? Why would 32bit fields make it endian neutral?

drivers/media/platform/ti-vpe/vpdma.c int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list) · line 468

Quoted 13 lines

drivers/media/platform/ti-vpe/vpdma.c +12 -0

+ */
+struct vpdma_dtd {
+	u32			type_ctl_stride;
+	union {
+		u32		xfer_length_height;
+		u32		w1;
+	};
+	dma_addr_t		start_addr;
+	u32			pkt_ctl;
+	union {
+		u32		frame_width_height;	/* inbound */
+		dma_addr_t	desc_write_addr;	/* outbound */

Are you sure dma_addr_t is always 32 bit?

drivers/media/platform/ti-vpe/vpdma.c int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list) · line 476

Quoted 9 lines

drivers/media/platform/ti-vpe/vpdma.c +8 -0

+	};
+	union {
+		u32		start_h_v;		/* inbound */
+		u32		max_width_height;	/* outbound */
+	};
+	u32			client_attr0;
+	u32			client_attr1;
+};

I'm not sure if I understand the struct right, but presuming this one struct is used for both writing and reading, and certain set of fields is used for writes and other set for reads, would it make sense to have two different structs, instead of using unions? Although they do have many common fields, and the unions are a bit scattered there, so I don't know if that would be cleaner...

Quoted 4 lines · Tomi Valkeinen

There's quite a bit of code in these dump functions, and they are always called. I'm sure getting that data is good for debugging, but I presume they are quite useless for normal use. So I think they should be compiled in only if some Kconfig option is selected.

Won't pr_debug() functions actually print something only when CONFIG_DYNAMIC_DEBUG is selected or if the DEBUG is defined? They will

still consume a lot of code, but it would just end up in dummy printk calls, right?

Quoted 6 lines

Quoted 4 lines

+/*
+ * data transfer descriptor
+ *
+ * All fields are 32 bits to make them endian neutral

What does that mean? Why would 32bit fields make it endian neutral?

Each 32 bit field describes one word of the data descriptor. Each descriptor has a number of parameters.

If we look at the word 'xfer_length_height'. It's composed of height (from bits 15:0) and width(from bits 31:16). If the word was expressed using bit fields, we can describe the word(in big endian) as:

struct vpdma_dtd {
    ...
    unsigned int    xfer_width:16;
    unsigned int    xfer_height:16;
    ...
    ...
};

and in little endian as:

struct vpdma_dtd {
    ...
    unsigned int    xfer_height:16;
    unsigned int    xfer_width:16;
    ...
    ...
};

So this representation makes it endian dependent. Maybe the comment should be improved saying that usage of u32 words instead of bit fields prevents endian issues.

Quoted 13 lines

Quoted 12 lines

+ */

drivers/media/platform/ti-vpe/vpdma_priv.h +11 -0

+struct vpdma_dtd {
+    u32            type_ctl_stride;
+    union {
+        u32        xfer_length_height;
+        u32        w1;
+    };
+    dma_addr_t        start_addr;
+    u32            pkt_ctl;
+    union {
+        u32        frame_width_height;    /* inbound */
+        dma_addr_t    desc_write_addr;    /* outbound */

Quoted 1 line

Are you sure dma_addr_t is always 32 bit?

I am not sure about this.

Quoted 10 lines

drivers/media/platform/ti-vpe/vpdma_priv.h line 150

Quoted 9 lines

drivers/media/platform/ti-vpe/vpdma_priv.h +8 -0

+    };
+    union {
+        u32        start_h_v;        /* inbound */
+        u32        max_width_height;    /* outbound */
+    };
+    u32            client_attr0;
+    u32            client_attr1;
+};

Quoted 6 lines

I'm not sure if I understand the struct right, but presuming this one struct is used for both writing and reading, and certain set of fields is used for writes and other set for reads, would it make sense to have two different structs, instead of using unions? Although they do have many common fields, and the unions are a bit scattered there, so I don't know if that would be cleaner...

It helps in a having a common debug function, I don't see much benefit apart from that. I'll see if it's better to have them as separate structs.

VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats.

We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible.

Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added.

Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions.

The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports.

When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done.

The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats.

Signed-off-by Archit Taneja <[email protected]>

---
 drivers/media/platform/Kconfig           |   10 +
 drivers/media/platform/Makefile          |    2 +
 drivers/media/platform/ti-vpe/vpe.c      | 1763 ++++++++++++++++++++++++++++++
 drivers/media/platform/ti-vpe/vpe_regs.h |  496 +++++++++
 4 files changed, 2271 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/vpe.c
 create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h

drivers/media/platform/ti-vpe/vpe.c new file +72 -0

+	cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
+	return 0;
+}
+
+static int __enum_fmt(struct v4l2_fmtdesc *f, u32 type)
+{
+	int i, index;
+	struct vpe_fmt *fmt = NULL;
+
+	index = 0;
+	for (i = 0; i < ARRAY_SIZE(vpe_formats); ++i) {
+		if (vpe_formats[i].types & type) {
+			if (index == f->index) {
+				fmt = &vpe_formats[i];
+				break;
+			}
+			index++;
+		}
+	}
+
+	if (!fmt)
+		return -EINVAL;
+
+	strncpy(f->description, fmt->name, sizeof(f->description) - 1);
+	f->pixelformat = fmt->fourcc;
+	return 0;
+}
+
+static int vpe_enum_fmt(struct file *file, void *priv,
+				struct v4l2_fmtdesc *f)
+{
+	if (V4L2_TYPE_IS_OUTPUT(f->type))
+		return __enum_fmt(f, VPE_FMT_TYPE_OUTPUT);
+	else
+		return __enum_fmt(f, VPE_FMT_TYPE_CAPTURE);
+}
+
+static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
+	struct vpe_ctx *ctx = file2ctx(file);
+	struct vb2_queue *vq;
+	struct vpe_q_data *q_data;
+	int i;
+
+	vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
+	if (!vq)
+		return -EINVAL;
+
+	q_data = get_q_data(ctx, f->type);
+
+	pix->width = q_data->width;
+	pix->height = q_data->height;
+	pix->pixelformat = q_data->fmt->fourcc;
+	pix->colorspace = q_data->colorspace;
+	pix->num_planes = q_data->fmt->coplanar ? 2 : 1;
+
+	for (i = 0; i < pix->num_planes; i++) {
+		pix->plane_fmt[i].bytesperline = q_data->bytesperline[i];
+		pix->plane_fmt[i].sizeimage = q_data->sizeimage[i];
+	}
+
+	return 0;
+}
+
+static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
+		       struct vpe_fmt *fmt, int type)
+{
+	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
+	struct v4l2_plane_pix_format *plane_fmt;
+	int i;
+

drivers/media/platform/ti-vpe/vpe.c new file +370 -0

+
+	v4l_bound_align_image(&pix->width, MIN_W, MAX_W, W_ALIGN,
+			      &pix->height, MIN_H, MAX_H, H_ALIGN,
+			      S_ALIGN);
+
+	pix->num_planes = fmt->coplanar ? 2 : 1;
+	pix->pixelformat = fmt->fourcc;
+	pix->colorspace = fmt->fourcc == V4L2_PIX_FMT_RGB24 ?
+			V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
+
+
+	for (i = 0; i < pix->num_planes; i++) {
+		int depth;
+
+		plane_fmt = &pix->plane_fmt[i];
+		depth = fmt->vpdma_fmt[i]->depth;
+
+		if (i == VPE_LUMA)
+			plane_fmt->bytesperline =
+					round_up((pix->width * depth) >> 3,
+						1 << L_ALIGN);
+		else
+			plane_fmt->bytesperline = pix->width;
+
+		plane_fmt->sizeimage =
+				(pix->height * pix->width * depth) >> 3;
+	}
+
+	return 0;
+}
+
+static int vpe_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+	struct vpe_ctx *ctx = file2ctx(file);
+	struct vpe_fmt *fmt = find_format(f);
+
+	if (V4L2_TYPE_IS_OUTPUT(f->type))
+		return __vpe_try_fmt(ctx, f, fmt, VPE_FMT_TYPE_OUTPUT);
+	else
+		return __vpe_try_fmt(ctx, f, fmt, VPE_FMT_TYPE_CAPTURE);
+}
+
+static int __vpe_s_fmt(struct vpe_ctx *ctx, struct v4l2_format *f)
+{
+	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
+	struct v4l2_plane_pix_format *plane_fmt;
+	struct vpe_q_data *q_data;
+	struct vb2_queue *vq;
+	int i;
+
+	vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
+	if (!vq)
+		return -EINVAL;
+
+	if (vb2_is_busy(vq)) {
+		vpe_err(ctx->dev, "queue busy\n");
+		return -EBUSY;
+	}
+
+	q_data = get_q_data(ctx, f->type);
+	if (!q_data)
+		return -EINVAL;
+
+	q_data->fmt		= find_format(f);
+	q_data->width		= pix->width;
+	q_data->height		= pix->height;
+	q_data->colorspace	= pix->colorspace;
+
+	for (i = 0; i < pix->num_planes; i++) {
+		plane_fmt = &pix->plane_fmt[i];
+
+		q_data->bytesperline[i]	= plane_fmt->bytesperline;
+		q_data->sizeimage[i]	= plane_fmt->sizeimage;
+	}
+
+	q_data->c_rect.left	= 0;
+	q_data->c_rect.top	= 0;
+	q_data->c_rect.width	= q_data->width;
+	q_data->c_rect.height	= q_data->height;
+
+	vpe_dbg(ctx->dev, "Setting format for type %d, wxh: %dx%d, fmt: %d bpl_y %d",
+		f->type, q_data->width, q_data->height, q_data->fmt->fourcc,
+		q_data->bytesperline[VPE_LUMA]);
+	if (q_data->fmt->coplanar)
+		vpe_dbg(ctx->dev, " bpl_uv %d\n",
+			q_data->bytesperline[VPE_CHROMA]);
+
+	return 0;
+}
+
+static int vpe_s_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+	int ret;
+	struct vpe_ctx *ctx = file2ctx(file);
+
+	ret = vpe_try_fmt(file, priv, f);
+	if (ret)
+		return ret;
+
+	ret = __vpe_s_fmt(ctx, f);
+	if (ret)
+		return ret;
+
+	if (V4L2_TYPE_IS_OUTPUT(f->type))
+		set_src_registers(ctx);
+	else
+		set_dst_registers(ctx);
+
+	return set_srcdst_params(ctx);
+}
+
+static int vpe_reqbufs(struct file *file, void *priv,
+		       struct v4l2_requestbuffers *reqbufs)
+{
+	struct vpe_ctx *ctx = file2ctx(file);
+
+	return v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
+}
+
+static int vpe_querybuf(struct file *file, void *priv, struct v4l2_buffer *buf)
+{
+	struct vpe_ctx *ctx = file2ctx(file);
+
+	return v4l2_m2m_querybuf(file, ctx->m2m_ctx, buf);
+}
+
+static int vpe_qbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
+{
+	struct vpe_ctx *ctx = file2ctx(file);
+
+	return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
+}
+
+static int vpe_dqbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
+{
+	struct vpe_ctx *ctx = file2ctx(file);
+
+	return v4l2_m2m_dqbuf(file, ctx->m2m_ctx, buf);
+}
+
+static int vpe_streamon(struct file *file, void *priv, enum v4l2_buf_type type)
+{
+	struct vpe_ctx *ctx = file2ctx(file);
+
+	return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
+}
+
+static int vpe_streamoff(struct file *file, void *priv, enum v4l2_buf_type type)
+{
+	struct vpe_ctx *ctx = file2ctx(file);
+
+	vpe_dump_regs(ctx->dev);
+	vpdma_dump_regs(ctx->dev->vpdma);
+
+	return v4l2_m2m_streamoff(file, ctx->m2m_ctx, type);
+}
+
+#define V4L2_CID_TRANS_NUM_BUFS		(V4L2_CID_USER_BASE)
+
+static int vpe_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+	struct vpe_ctx *ctx =
+		container_of(ctrl->handler, struct vpe_ctx, hdl);
+
+	switch (ctrl->id) {
+	case V4L2_CID_TRANS_NUM_BUFS:
+		ctx->bufs_per_job = ctrl->val;
+		break;
+
+	default:
+		vpe_err(ctx->dev, "Invalid control\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static const struct v4l2_ctrl_ops vpe_ctrl_ops = {
+	.s_ctrl = vpe_s_ctrl,
+};
+
+static const struct v4l2_ioctl_ops vpe_ioctl_ops = {
+	.vidioc_querycap	= vpe_querycap,
+
+	.vidioc_enum_fmt_vid_cap_mplane = vpe_enum_fmt,
+	.vidioc_g_fmt_vid_cap_mplane	= vpe_g_fmt,
+	.vidioc_try_fmt_vid_cap_mplane	= vpe_try_fmt,
+	.vidioc_s_fmt_vid_cap_mplane	= vpe_s_fmt,
+
+	.vidioc_enum_fmt_vid_out_mplane = vpe_enum_fmt,
+	.vidioc_g_fmt_vid_out_mplane	= vpe_g_fmt,
+	.vidioc_try_fmt_vid_out_mplane	= vpe_try_fmt,
+	.vidioc_s_fmt_vid_out_mplane	= vpe_s_fmt,
+
+	.vidioc_reqbufs		= vpe_reqbufs,
+	.vidioc_querybuf	= vpe_querybuf,
+
+	.vidioc_qbuf		= vpe_qbuf,
+	.vidioc_dqbuf		= vpe_dqbuf,
+
+	.vidioc_streamon	= vpe_streamon,
+	.vidioc_streamoff	= vpe_streamoff,
+	.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+	.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
+};
+
+/*
+ * Queue operations
+ */
+static int vpe_queue_setup(struct vb2_queue *vq,
+			   const struct v4l2_format *fmt,
+			   unsigned int *nbuffers, unsigned int *nplanes,
+			   unsigned int sizes[], void *alloc_ctxs[])
+{
+	int i;
+	struct vpe_ctx *ctx = vb2_get_drv_priv(vq);
+	struct vpe_q_data *q_data;
+
+	q_data = get_q_data(ctx, vq->type);
+
+	*nplanes = q_data->fmt->coplanar ? 2 : 1;
+
+	for (i = 0; i < *nplanes; i++) {
+		sizes[i] = q_data->sizeimage[i];
+		alloc_ctxs[i] = ctx->dev->alloc_ctx;
+	}
+
+	vpe_dbg(ctx->dev, "get %d buffer(s) of size %d", *nbuffers,
+		sizes[VPE_LUMA]);
+	if (q_data->fmt->coplanar)
+		vpe_dbg(ctx->dev, " and %d\n", sizes[VPE_CHROMA]);
+
+	return 0;
+}
+
+static int vpe_buf_prepare(struct vb2_buffer *vb)
+{
+	struct vpe_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+	struct vpe_q_data *q_data;
+	int i, num_planes;
+
+	vpe_dbg(ctx->dev, "type: %d\n", vb->vb2_queue->type);
+
+	q_data = get_q_data(ctx, vb->vb2_queue->type);
+	num_planes = q_data->fmt->coplanar ? 2 : 1;
+
+	for (i = 0; i < num_planes; i++) {
+		if (vb2_plane_size(vb, i) < q_data->sizeimage[i]) {
+			vpe_err(ctx->dev,
+				"data will not fit into plane (%lu < %lu)\n",
+				vb2_plane_size(vb, i),
+				(long) q_data->sizeimage[i]);
+			return -EINVAL;
+		}
+	}
+
+	for (i = 0; i < num_planes; i++)
+		vb2_set_plane_payload(vb, i, q_data->sizeimage[i]);
+
+	return 0;
+}
+
+static void vpe_buf_queue(struct vb2_buffer *vb)
+{
+	struct vpe_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+	v4l2_m2m_buf_queue(ctx->m2m_ctx, vb);
+}
+
+static void vpe_wait_prepare(struct vb2_queue *q)
+{
+	struct vpe_ctx *ctx = vb2_get_drv_priv(q);
+	vpe_unlock(ctx);
+}
+
+static void vpe_wait_finish(struct vb2_queue *q)
+{
+	struct vpe_ctx *ctx = vb2_get_drv_priv(q);
+	vpe_lock(ctx);
+}
+
+static struct vb2_ops vpe_qops = {
+	.queue_setup	 = vpe_queue_setup,
+	.buf_prepare	 = vpe_buf_prepare,
+	.buf_queue	 = vpe_buf_queue,
+	.wait_prepare	 = vpe_wait_prepare,
+	.wait_finish	 = vpe_wait_finish,
+};
+
+static int queue_init(void *priv, struct vb2_queue *src_vq,
+		      struct vb2_queue *dst_vq)
+{
+	struct vpe_ctx *ctx = priv;
+	int ret;
+
+	memset(src_vq, 0, sizeof(*src_vq));
+	src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
+	src_vq->io_modes = VB2_MMAP;
+	src_vq->drv_priv = ctx;
+	src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
+	src_vq->ops = &vpe_qops;
+	src_vq->mem_ops = &vb2_dma_contig_memops;
+	src_vq->timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+
+	ret = vb2_queue_init(src_vq);
+	if (ret)
+		return ret;
+
+	memset(dst_vq, 0, sizeof(*dst_vq));
+	dst_vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+	dst_vq->io_modes = VB2_MMAP;
+	dst_vq->drv_priv = ctx;
+	dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
+	dst_vq->ops = &vpe_qops;
+	dst_vq->mem_ops = &vb2_dma_contig_memops;
+	dst_vq->timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+
+	return vb2_queue_init(dst_vq);
+}
+
+static const struct v4l2_ctrl_config vpe_bufs_per_job = {
+	.ops = &vpe_ctrl_ops,
+	.id = V4L2_CID_TRANS_NUM_BUFS,
+	.name = "Buffers Per Transaction",
+	.type = V4L2_CTRL_TYPE_INTEGER,
+	.def = VPE_DEF_BUFS_PER_JOB,
+	.min = 1,
+	.max = VIDEO_MAX_FRAME,
+	.step = 1,
+};
+
+/*
+ * File operations
+ */
+static int vpe_open(struct file *file)
+{
+	struct vpe_dev *dev = video_drvdata(file);
+	struct vpe_ctx *ctx = NULL;
+	struct vpe_q_data *s_q_data;
+	struct v4l2_ctrl_handler *hdl;
+	int ret;
+
+	vpe_dbg(dev, "vpe_open\n");
+
+	if (!dev->vpdma->ready) {
+		vpe_err(dev, "vpdma firmware not loaded\n");
+		return -ENODEV;
+	}
+
+	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->dev = dev;
+
+	if (mutex_lock_interruptible(&dev->dev_mutex)) {
+		ret = -ERESTARTSYS;
+		goto free_ctx;
+	}
+
+	ret = vpdma_create_desc_list(&ctx->desc_list, VPE_DESC_LIST_SIZE,
+			VPDMA_LIST_TYPE_NORMAL);
+	if (ret != 0)
+		goto unlock;
+
+	ret = vpdma_buf_alloc(&ctx->mmr_adb, sizeof(struct vpe_mmr_adb));
+	if (ret != 0)
+		goto free_desc_list;
+
+	init_adb_hdrs(ctx);
+