Hi Laurent,

On 24/05/18 11:47, Laurent Pinchart wrote:

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:13 EEST Kieran Bingham wrote:

...

The use of the packed attribute can cause a performance penalty for all accesses to the struct members, as the compiler will assume that the structure has the potential to have an unaligned base.

These structures are all correctly aligned and contain no holes, thus the attribute is redundant and negatively impacts performance, so we remove the attributes entirely.

With gcc 6.4.0 this patch makes no difference on the generated object. Is it worth it ?

This patch has certainly either enlightened me, or confused me about this topic - as I had in the past used the packed attribute as here to define that we don't want holes. (just as this existing code does)

As the documentation seems to determine that this isn't the effect of this attribute, and removing it has no effect - I suspect removing it is the right thing to do, as otherwise we are simply mis-using the construct for no purpose.

It's up to though. Drop or accept as you feel is right.

...

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

You forget to pick Geert's review tag.

Ah yes, Collected thanks

-- Regards

Kieran

...

---

v2

• Remove attributes entirely

---

drivers/media/platform/vsp1/vsp1_dl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index c7fa1cb088cd..f4cede9b9b43 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -25,19 +25,19 @@ struct vsp1_dl_header_list { u32 num_bytes; u32 addr; -} __attribute__((__packed__)); +};

struct vsp1_dl_header { u32 num_lists; struct vsp1_dl_header_list lists[8]; u32 next_header; u32 flags; -} __attribute__((__packed__)); +};

struct vsp1_dl_entry { u32 addr; u32 data; -} __attribute__((__packed__)); +};

/**

• struct vsp1_dl_body - Display list body

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:14 EEST Kieran Bingham wrote:

Both vsp1_dl_list_commit() and __vsp1_dl_list_put() walk the display list chain referencing the nodes as children, when in reality they are siblings.

Update the terminology to 'dl_next' to be consistent with the vsp1_video_pipeline_run() usage.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com

---

drivers/media/platform/vsp1/vsp1_dl.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index f4cede9b9b43..ec6fc21fabe0 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -398,7 +398,7 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm) /* This function must be called with the display list manager lock held.*/ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl) {

• struct vsp1_dl_list *dl_child;

• struct vsp1_dl_list *dl_next;

  if (!dl) return;

@@ -408,8 +408,8 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl) * hardware operation. */ if (dl->has_chain) {

• list_for_each_entry(dl_child, &dl->chain, chain)
  

• 	__vsp1_dl_list_put(dl_child);
  

• list_for_each_entry(dl_next, &dl->chain, chain)
  

• 	__vsp1_dl_list_put(dl_next);
  

  }

  dl->has_chain = false;

@@ -673,17 +673,17 @@ static void vsp1_dl_list_commit_singleshot(struct vsp1_dl_list *dl) void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool internal) { struct vsp1_dl_manager *dlm = dl->dlm;

• struct vsp1_dl_list *dl_child;

• struct vsp1_dl_list *dl_next; unsigned long flags;

  if (dlm->mode == VSP1_DL_MODE_HEADER) { /* Fill the header for the head and chained display lists. */ vsp1_dl_list_fill_header(dl, list_empty(&dl->chain));

• list_for_each_entry(dl_child, &dl->chain, chain) {
  

• 	bool last = list_is_last(&dl_child->chain, &dl->chain);
  

• list_for_each_entry(dl_next, &dl->chain, chain) {
  

• 	bool last = list_is_last(&dl_next->chain, &dl->chain);
  
  

• 	vsp1_dl_list_fill_header(dl_child, last);
  

• 	vsp1_dl_list_fill_header(dl_next, last);
  

  } }

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:15 EEST Kieran Bingham wrote:

The vsp1 reference in the vsp1_dl_body structure is not used. Remove it.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com

---

drivers/media/platform/vsp1/vsp1_dl.c | 2 -- 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index ec6fc21fabe0..b23e88cda49f 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -44,7 +44,6 @@ struct vsp1_dl_entry {

• @list: entry in the display list list of bodies
• @free: entry in the pool free body list
• @pool: pool to which this body belongs

• • @vsp1: the VSP1 device
  • @entries: array of entries
  • @dma: DMA address of the entries
  • @size: size of the DMA memory in bytes

@@ -58,7 +57,6 @@ struct vsp1_dl_body { refcount_t refcnt;

struct vsp1_dl_body_pool *pool;

• struct vsp1_device *vsp1;

  struct vsp1_dl_entry *entries; dma_addr_t dma;

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:16 EEST Kieran Bingham wrote:

If there is an error allocating a display list within a DLM object the existing display lists are not free'd, and neither is the DL body pool.

Use the existing vsp1_dlm_destroy() function to clean up on error.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com

---

drivers/media/platform/vsp1/vsp1_dl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index b23e88cda49f..fbffbd407b29 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -851,8 +851,10 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1, struct vsp1_dl_list *dl;

dl = vsp1_dl_list_alloc(dlm);

• if (!dl)
  

• if (!dl) {
  

• 	vsp1_dlm_destroy(dlm);
  return NULL;
  

• }
  
  

  list_add_tail(&dl->list, &dlm->free); }

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:17 EEST Kieran Bingham wrote:

The VSP1 devices define their specific capabilities through features marked in their device info structure. Various parts of the code read this info structure to infer if the features are available.

Wrap this into a more readable vsp1_feature(vsp1, f) macro to ensure that usage is consistent throughout the driver.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com

---

drivers/media/platform/vsp1/vsp1.h | 2 ++ drivers/media/platform/vsp1/vsp1_drv.c | 16 ++++++++-------- drivers/media/platform/vsp1/vsp1_wpf.c | 6 +++--- 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h b/drivers/media/platform/vsp1/vsp1.h index 33f632331474..f0d21cc8e9ab 100644 --- a/drivers/media/platform/vsp1/vsp1.h +++ b/drivers/media/platform/vsp1/vsp1.h @@ -68,6 +68,8 @@ struct vsp1_device_info { bool uapi; };

+#define vsp1_feature(vsp1, f) ((vsp1)->info->features & (f))

struct vsp1_device { struct device *dev; const struct vsp1_device_info *info; diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index d29f9c4baebe..0fc388bf5a33 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -265,7 +265,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1) }

/* Instantiate all the entities. */

• if (vsp1->info->features & VSP1_HAS_BRS) {

• if (vsp1_feature(vsp1, VSP1_HAS_BRS)) { vsp1->brs = vsp1_brx_create(vsp1, VSP1_ENTITY_BRS); if (IS_ERR(vsp1->brs)) { ret = PTR_ERR(vsp1->brs);

@@ -275,7 +275,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1) list_add_tail(&vsp1->brs->entity.list_dev, &vsp1->entities); }

• if (vsp1->info->features & VSP1_HAS_BRU) {

• if (vsp1_feature(vsp1, VSP1_HAS_BRU)) { vsp1->bru = vsp1_brx_create(vsp1, VSP1_ENTITY_BRU); if (IS_ERR(vsp1->bru)) { ret = PTR_ERR(vsp1->bru);

@@ -285,7 +285,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1) list_add_tail(&vsp1->bru->entity.list_dev, &vsp1->entities); }

• if (vsp1->info->features & VSP1_HAS_CLU) {

• if (vsp1_feature(vsp1, VSP1_HAS_CLU)) { vsp1->clu = vsp1_clu_create(vsp1); if (IS_ERR(vsp1->clu)) { ret = PTR_ERR(vsp1->clu);

@@ -311,7 +311,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)

list_add_tail(&vsp1->hst->entity.list_dev, &vsp1->entities);

• if (vsp1->info->features & VSP1_HAS_HGO && vsp1->info->uapi) {

• if (vsp1_feature(vsp1, VSP1_HAS_HGO) && vsp1->info->uapi) { vsp1->hgo = vsp1_hgo_create(vsp1); if (IS_ERR(vsp1->hgo)) { ret = PTR_ERR(vsp1->hgo);

@@ -322,7 +322,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1) &vsp1->entities); }

• if (vsp1->info->features & VSP1_HAS_HGT && vsp1->info->uapi) {

• if (vsp1_feature(vsp1, VSP1_HAS_HGT) && vsp1->info->uapi) { vsp1->hgt = vsp1_hgt_create(vsp1); if (IS_ERR(vsp1->hgt)) { ret = PTR_ERR(vsp1->hgt);

@@ -353,7 +353,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1) } }

• if (vsp1->info->features & VSP1_HAS_LUT) {

• if (vsp1_feature(vsp1, VSP1_HAS_LUT)) { vsp1->lut = vsp1_lut_create(vsp1); if (IS_ERR(vsp1->lut)) { ret = PTR_ERR(vsp1->lut);

@@ -387,7 +387,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1) } }

• if (vsp1->info->features & VSP1_HAS_SRU) {

• if (vsp1_feature(vsp1, VSP1_HAS_SRU)) { vsp1->sru = vsp1_sru_create(vsp1); if (IS_ERR(vsp1->sru)) { ret = PTR_ERR(vsp1->sru);

@@ -537,7 +537,7 @@ static int vsp1_device_init(struct vsp1_device *vsp1) vsp1_write(vsp1, VI6_DPR_HSI_ROUTE, VI6_DPR_NODE_UNUSED); vsp1_write(vsp1, VI6_DPR_BRU_ROUTE, VI6_DPR_NODE_UNUSED);

• if (vsp1->info->features & VSP1_HAS_BRS)

• if (vsp1_feature(vsp1, VSP1_HAS_BRS)) vsp1_write(vsp1, VI6_DPR_ILV_BRS_ROUTE, VI6_DPR_NODE_UNUSED);

  vsp1_write(vsp1, VI6_DPR_HGO_SMPPT, (7 << VI6_DPR_SMPPT_TGW_SHIFT) |

diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c b/drivers/media/platform/vsp1/vsp1_wpf.c index 2edea361eee4..ea1d226371b2 100644 --- a/drivers/media/platform/vsp1/vsp1_wpf.c +++ b/drivers/media/platform/vsp1/vsp1_wpf.c @@ -141,13 +141,13 @@ static int wpf_init_controls(struct vsp1_rwpf *wpf) if (wpf->entity.index != 0) { /* Only WPF0 supports flipping. */ num_flip_ctrls = 0;

• } else if (vsp1->info->features & VSP1_HAS_WPF_HFLIP) {

• } else if (vsp1_feature(vsp1, VSP1_HAS_WPF_HFLIP)) { /*
  • When horizontal flip is supported the WPF implements three
  • controls (horizontal flip, vertical flip and rotation).
  */ num_flip_ctrls = 3;

• } else if (vsp1->info->features & VSP1_HAS_WPF_VFLIP) {

• } else if (vsp1_feature(vsp1, VSP1_HAS_WPF_VFLIP)) { /*
  • When only vertical flip is supported the WPF implements a
  • single control (vertical flip).

@@ -276,7 +276,7 @@ static void wpf_configure_stream(struct vsp1_entity *entity,

vsp1_wpf_write(wpf, dlb, VI6_WPF_DSWAP, fmtinfo->swap);

• if (vsp1->info->features & VSP1_HAS_WPF_HFLIP &&
  

• if (vsp1_feature(vsp1, VSP1_HAS_WPF_HFLIP) &&
  

  wpf->entity.index == 0) vsp1_wpf_write(wpf, dlb, VI6_WPF_ROT_CTRL, VI6_WPF_ROT_CTRL_LN16 |

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:18 EEST Kieran Bingham wrote:

Header mode display lists are now supported on all WPF outputs. To support extended headers and auto-fld capabilities for interlaced mode handling only header mode display lists can be used.

Disable the headerless display list configuration, and remove the dead code.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

drivers/media/platform/vsp1/vsp1_dl.c | 107 ++++++--------------------- 1 file changed, 27 insertions(+), 80 deletions(-)

I like the diffstat.

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index fbffbd407b29..56514cd51c51 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -94,7 +94,7 @@ struct vsp1_dl_body_pool {

• struct vsp1_dl_list - Display list
• @list: entry in the display list manager lists
• @dlm: the display list manager

• • @header: display list header, NULL for headerless lists

• • @header: display list header
  • @dma: DMA address for the header
  • @body0: first display list body
  • @bodies: list of extra display list bodies

@@ -118,15 +118,9 @@ struct vsp1_dl_list { bool internal; };

-enum vsp1_dl_mode {

• VSP1_DL_MODE_HEADER,
• VSP1_DL_MODE_HEADERLESS,

-};

/**

• struct vsp1_dl_manager - Display List manager
• @index: index of the related WPF

• • @mode: display list operation mode (header or headerless)
  • @singleshot: execute the display list in single-shot mode
  • @vsp1: the VSP1 device
  • @lock: protects the free, active, queued, and pending lists

@@ -138,7 +132,6 @@ enum vsp1_dl_mode { */ struct vsp1_dl_manager { unsigned int index;

• enum vsp1_dl_mode mode; bool singleshot; struct vsp1_device *vsp1;

@@ -318,6 +311,7 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, u32 data) static struct vsp1_dl_list *vsp1_dl_list_alloc(struct vsp1_dl_manager *dlm) { struct vsp1_dl_list *dl;

• size_t header_offset;

  dl = kzalloc(sizeof(*dl), GFP_KERNEL); if (!dl)

@@ -330,16 +324,15 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct vsp1_dl_manager *dlm) dl->body0 = vsp1_dl_body_get(dlm->pool); if (!dl->body0) return NULL;

• if (dlm->mode == VSP1_DL_MODE_HEADER) {

• size_t header_offset = dl->body0->max_entries
  

• 		     * sizeof(*dl->body0->entries);
  
  

• dl->header = ((void *)dl->body0->entries) + header_offset;
  

• dl->dma = dl->body0->dma + header_offset;
  

• header_offset = dl->body0->max_entries

• 	     * sizeof(*dl->body0->entries);
  

Nitpicking, please align * under =.

• memset(dl->header, 0, sizeof(*dl->header));
  

• dl->header->lists[0].addr = dl->body0->dma;
  

• }

• dl->header = ((void *)dl->body0->entries) + header_offset;

• dl->dma = dl->body0->dma + header_offset;

• memset(dl->header, 0, sizeof(*dl->header));

• dl->header->lists[0].addr = dl->body0->dma;

  return dl;

} @@ -471,16 +464,9 @@ struct vsp1_dl_body *vsp1_dl_list_get_body0(struct vsp1_dl_list *dl) *

• The reference must be explicitly released by a call to

vsp1_dl_body_put() * when the body isn't needed anymore.

• • Additional bodies are only usable for display lists in header mode.
• • Attempting to add a body to a header-less display list will return an

error. */ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct vsp1_dl_body *dlb) {

• /* Multi-body lists are only available in header mode. */

• if (dl->dlm->mode != VSP1_DL_MODE_HEADER)

• return -EINVAL;
  

• refcount_inc(&dlb->refcnt);

  list_add_tail(&dlb->list, &dl->bodies);

@@ -501,17 +487,10 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct vsp1_dl_body *dlb) * Adding a display list to a chain passes ownership of the display list to * the head display list item. The chain is released when the head dl item is * put back with __vsp1_dl_list_put().

• • Chained display lists are only usable in header mode. Attempts to add a
• • display list to a chain in header-less mode will return an error.
  */

int vsp1_dl_list_add_chain(struct vsp1_dl_list *head, struct vsp1_dl_list *dl) {

• /* Chained lists are only available in header mode. */
• if (head->dlm->mode != VSP1_DL_MODE_HEADER)

• return -EINVAL;
  

• head->has_chain = true; list_add_tail(&dl->chain, &head->chain); return 0;

@@ -579,17 +558,10 @@ static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm) return false;

/*

• * Check whether the VSP1 has taken the update. In headerless mode the
  

• * hardware indicates this by clearing the UPD bit in the DL_BODY_SIZE
  

• * register, and in header mode by clearing the UPDHDR bit in the CMD
  

• * register.
  

• * Check whether the VSP1 has taken the update. In header mode by
  

• * clearing the UPDHDR bit in the CMD register.
  

I'd write this

* Check whether the VSP1 has taken the update. The hardware indicates * this by clearing the UPDHDR bit in the CMD register.

*/

• if (dlm->mode == VSP1_DL_MODE_HEADERLESS)

• return !!(vsp1_read(vsp1, VI6_DL_BODY_SIZE)
  

• 	  & VI6_DL_BODY_SIZE_UPD);
  

• else

• return !!(vsp1_read(vsp1, VI6_CMD(dlm->index))
  

• 	  & VI6_CMD_UPDHDR);
  

• return !!(vsp1_read(vsp1, VI6_CMD(dlm->index)) & VI6_CMD_UPDHDR);

}

static void vsp1_dl_list_hw_enqueue(struct vsp1_dl_list *dl) @@ -597,26 +569,14 @@ static void vsp1_dl_list_hw_enqueue(struct vsp1_dl_list *dl) struct vsp1_dl_manager *dlm = dl->dlm; struct vsp1_device *vsp1 = dlm->vsp1;

• if (dlm->mode == VSP1_DL_MODE_HEADERLESS) {

• /*
  

•  * In headerless mode, program the hardware directly with the
  

•  * display list body address and size and set the UPD bit. The
  

•  * bit will be cleared by the hardware when the display list
  

•  * processing starts.
  

•  */
  

• vsp1_write(vsp1, VI6_DL_HDR_ADDR(0), dl->body0->dma);
  

• vsp1_write(vsp1, VI6_DL_BODY_SIZE, VI6_DL_BODY_SIZE_UPD |
  

• 	(dl->body0->num_entries * sizeof(*dl->header->lists)));
  

• } else {

• /*
  

•  * In header mode, program the display list header address. If
  

•  * the hardware is idle (single-shot mode or first frame in
  

•  * continuous mode) it will then be started independently. If
  

•  * the hardware is operating, the VI6_DL_HDR_REF_ADDR register
  

•  * will be updated with the display list address.
  

•  */
  

• vsp1_write(vsp1, VI6_DL_HDR_ADDR(dlm->index), dl->dma);
  

• }

• /*

• * In header mode, program the display list header address. If
  

s/In header mode, program/Program/

You can also reformat the comment block to reach the 80th column.

• * the hardware is idle (single-shot mode or first frame in
  

• * continuous mode) it will then be started independently. If
  

• * the hardware is operating, the VI6_DL_HDR_REF_ADDR register
  

• * will be updated with the display list address.
  

• */
  

• vsp1_write(vsp1, VI6_DL_HDR_ADDR(dlm->index), dl->dma);

}

static void vsp1_dl_list_commit_continuous(struct vsp1_dl_list *dl) @@ -674,15 +634,13 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool internal) struct vsp1_dl_list *dl_next; unsigned long flags;

• if (dlm->mode == VSP1_DL_MODE_HEADER) {

• /* Fill the header for the head and chained display lists. */
  

• vsp1_dl_list_fill_header(dl, list_empty(&dl->chain));
  

• /* Fill the header for the head and chained display lists. */
• vsp1_dl_list_fill_header(dl, list_empty(&dl->chain));

• list_for_each_entry(dl_next, &dl->chain, chain) {
  

• 	bool last = list_is_last(&dl_next->chain, &dl->chain);
  

• list_for_each_entry(dl_next, &dl->chain, chain) {

• bool last = list_is_last(&dl_next->chain, &dl->chain);
  
  

• 	vsp1_dl_list_fill_header(dl_next, last);
  

• }
  

• vsp1_dl_list_fill_header(dl_next, last);
  

  }

  dl->internal = internal;

@@ -783,13 +741,6 @@ void vsp1_dlm_setup(struct vsp1_device *vsp1)

 | VI6_DL_CTRL_DC2 | VI6_DL_CTRL_DC1 | VI6_DL_CTRL_DC0
 | VI6_DL_CTRL_DLE;

• /*

• * The DRM pipeline operates with display lists in Continuous Frame
  

• * Mode, all other pipelines use manual start.
  

• */
  

• if (vsp1->drm)

• ctrl |= VI6_DL_CTRL_CFM0 | VI6_DL_CTRL_NH0;
  

• vsp1_write(vsp1, VI6_DL_CTRL, ctrl); vsp1_write(vsp1, VI6_DL_SWAP, VI6_DL_SWAP_LWS);

} @@ -824,8 +775,6 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1, return NULL;

dlm->index = index;

• dlm->mode = index == 0 && !vsp1->info->uapi

•   ? VSP1_DL_MODE_HEADERLESS : VSP1_DL_MODE_HEADER;
  

  dlm->singleshot = vsp1->info->uapi; dlm->vsp1 = vsp1;

@@ -834,13 +783,11 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1,

/* * Initialize the display list body and allocate DMA memory for the body

• * and the optional header. Both are allocated together to avoid memory
  

• * and the header. Both are allocated together to avoid memory
  

  • fragmentation, with the header located right after the body in
  • memory.
  */

• header_size = dlm->mode == VSP1_DL_MODE_HEADER

•     ? ALIGN(sizeof(struct vsp1_dl_header), 8)
  

•     : 0;
  

• header_size = ALIGN(sizeof(struct vsp1_dl_header), 8);

  dlm->pool = vsp1_dl_body_pool_create(vsp1, prealloc, VSP1_DL_NUM_ENTRIES, header_size);

While at it, could you update the documentation of the vsp1_dlm_irq_frame_end() function to s/header mode/single-shot mode/ ?

With these small issues fixed,

Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com

Hi Laurent,

On 24/05/18 12:44, Laurent Pinchart wrote:

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:19 EEST Kieran Bingham wrote:

...

Extended display list headers allow pre and post command lists to be executed by the VSP pipeline. This provides the base support for features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for supporting continuous camera preview pipelines.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

---

v2:

• remove __packed attributes

---

drivers/media/platform/vsp1/vsp1.h | 1 +- drivers/media/platform/vsp1/vsp1_dl.c | 83 +++++++++++++++++++++++++- drivers/media/platform/vsp1/vsp1_dl.h | 29 ++++++++- drivers/media/platform/vsp1/vsp1_drv.c | 7 +- drivers/media/platform/vsp1/vsp1_regs.h | 5 +- 5 files changed, 116 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h b/drivers/media/platform/vsp1/vsp1.h index f0d21cc8e9ab..56c62122a81a 100644 --- a/drivers/media/platform/vsp1/vsp1.h +++ b/drivers/media/platform/vsp1/vsp1.h @@ -53,6 +53,7 @@ struct vsp1_uif; #define VSP1_HAS_HGO (1 << 7) #define VSP1_HAS_HGT (1 << 8) #define VSP1_HAS_BRS (1 << 9) +#define VSP1_HAS_EXT_DL (1 << 10)

struct vsp1_device_info { u32 version; diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index 56514cd51c51..b64d32535edc 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -22,6 +22,9 @@ #define VSP1_DLH_INT_ENABLE (1 << 1) #define VSP1_DLH_AUTO_START (1 << 0)

+#define VSP1_DLH_EXT_PRE_CMD_EXEC (1 << 9) +#define VSP1_DLH_EXT_POST_CMD_EXEC (1 << 8)

struct vsp1_dl_header_list { u32 num_bytes; u32 addr; @@ -34,11 +37,34 @@ struct vsp1_dl_header { u32 flags; };

+struct vsp1_dl_ext_header {

• u32 reserved0; /* alignment padding */
• u16 pre_ext_cmd_qty;

Should this be called pre_ext_dl_num_cmd to match the datasheet ?

Yes, renamed.

...

• u16 flags;

Aren't the flags supposed to come before the pre_ext_dl_num_cmd field ?

These are out-of-order to account for the fact that they are 16bit values.

I felt that keeping them described in the struct was cleaner than shifts and masks - but clearly this stands out, due to the byte-ordering.

Would you prefer I re-write this as 32 bit accesses (or even 64bit), with shifts? Or is a comment sufficient here ?

If we rewrite to be 32 bit accesses, would you be happy with the following naming:

u32 reserved0; u32 pre_ext_dl_num_cmd; /* Also stores command flags. */ u32 pre_ext_dl_plist; u32 post_ext_dl_num_cmd; u32 post_ext_dl_plist;

(Technically the flags are for the whole header, not the just the pre_ext, which is why I wanted it separated)

Actually - now I write that - the 'number of commands' is sort of a flag or a parameter? so maybe the following is just as appropriate?:

u32 reserved0; u32 pre_ext_dl_flags; u32 pre_ext_dl_plist; u32 post_ext_dl_flags; u32 post_ext_dl_plist;

Or they could be named 'options', or parameters?

Any comments before I hack that in?

The annoying part is that the 'flags' aren't part of the pre_ext cmds, they declare whether the pre or post cmd should be executed (or both I presume, we are yet to see post-cmd usage)

...

• u32 pre_ext_cmd_plist;

And pre_ext_dl_plist ?

...

• u32 post_ext_cmd_qty;
• u32 post_ext_cmd_plist;

Similar comments for these variables.

Renamed.

...

+};

+struct vsp1_dl_header_extended {

• struct vsp1_dl_header header;
• struct vsp1_dl_ext_header ext;

+};

struct vsp1_dl_entry { u32 addr; u32 data; };

+struct vsp1_dl_ext_cmd_header {

Isn't this referred to in the datasheet as a body entry, not a header ? How about naming it vsp1_dl_ext_cmd_entry ? Or just vsp1_dl_ext_cmd (in which case the other structure that goes by the same name would need to be renamed) ?

I think I was getting too creative. The reality is this part is really a 'header' describing the data in the body, but yes - it should be named to match a "Pre Extended Display List Body"

s/vsp1_dl_ext_cmd_header/vsp1_pre_ext_dl_body/

This will then leave "struct vsp1_dl_ext_cmd" which represents the object instance within the VSP1 driver only.

...

• u32 cmd;

This should really have been opcode then too :)

...

• u32 flags;
• u32 data;
• u32 reserved;

The datasheet documents this as two 64-bit fields, shouldn't we handle the structure the same way ?

I was trying to separate out the fields for clarity.

In this instance (unlike the 16bit handling above), the byte ordering of a 64 bit value works in our favour, and the ordering of the 4 u32s, follows the order of the datasheet.

If you'd prefer to handle them as 64bit with mask and shift, I'll update, and rename this to contain two fields : u64 ext_dl_cmd; u64 ext_dl_data;

But this is working well with the 32 bit definitions.

...

+};

/**

• struct vsp1_dl_body - Display list body
• @list: entry in the display list list of bodies

@@ -95,9 +121,12 @@ struct vsp1_dl_body_pool {

• @list: entry in the display list manager lists
• @dlm: the display list manager
• @header: display list header

• • @extended: extended display list header. NULL for normal lists

Should we name this extension instead of extended ?

Fixed.

...

• @dma: DMA address for the header
• @body0: first display list body
• @bodies: list of extra display list bodies

• • @pre_cmd: pre cmd to be issued through extended dl header
• • @post_cmd: post cmd to be issued through extended dl header

I think you can spell command in full.

Fixed

...

• @has_chain: if true, indicates that there's a partition chain
• @chain: entry in the display list partition chain
• @internal: whether the display list is used for internal purpose

@@ -107,11 +136,15 @@ struct vsp1_dl_list { struct vsp1_dl_manager *dlm;

struct vsp1_dl_header *header;

• struct vsp1_dl_ext_header *extended; dma_addr_t dma;

  struct vsp1_dl_body *body0; struct list_head bodies;

• struct vsp1_dl_ext_cmd *pre_cmd;

• struct vsp1_dl_ext_cmd *post_cmd;

• bool has_chain; struct list_head chain;

@@ -496,6 +529,14 @@ int vsp1_dl_list_add_chain(struct vsp1_dl_list *head, return 0; }

+static void vsp1_dl_ext_cmd_fill_header(struct vsp1_dl_ext_cmd *cmd)

...

+{

• cmd->cmds[0].cmd = cmd->cmd_opcode;
• cmd->cmds[0].flags = cmd->flags;
• cmd->cmds[0].data = cmd->data_dma;
• cmd->cmds[0].reserved = 0;

+}

static void vsp1_dl_list_fill_header(struct vsp1_dl_list *dl, bool is_last) { struct vsp1_dl_manager *dlm = dl->dlm; @@ -548,6 +589,27 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list *dl, bool is_last) */ dl->header->flags = VSP1_DLH_INT_ENABLE; }

• if (!dl->extended)

• return;
  

• dl->extended->flags = 0;
• if (dl->pre_cmd) {

• dl->extended->pre_ext_cmd_plist = dl->pre_cmd->cmd_dma;
  

• dl->extended->pre_ext_cmd_qty = dl->pre_cmd->num_cmds;
  

• dl->extended->flags |= VSP1_DLH_EXT_PRE_CMD_EXEC;
  

• vsp1_dl_ext_cmd_fill_header(dl->pre_cmd);
  

• }
• if (dl->post_cmd) {

• dl->extended->pre_ext_cmd_plist = dl->post_cmd->cmd_dma;
  

• dl->extended->pre_ext_cmd_qty = dl->post_cmd->num_cmds;
  

• dl->extended->flags |= VSP1_DLH_EXT_POST_CMD_EXEC;
  

• vsp1_dl_ext_cmd_fill_header(dl->pre_cmd);
  

• }

}

static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm) @@ -735,14 +797,20 @@ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm) }

/* Hardware Setup */ -void vsp1_dlm_setup(struct vsp1_device *vsp1) +void vsp1_dlm_setup(struct vsp1_device *vsp1, unsigned int index) { u32 ctrl = (256 << VI6_DL_CTRL_AR_WAIT_SHIFT)

 | VI6_DL_CTRL_DC2 | VI6_DL_CTRL_DC1 | VI6_DL_CTRL_DC0
 | VI6_DL_CTRL_DLE;

• if (vsp1_feature(vsp1, VSP1_HAS_EXT_DL))

• vsp1_write(vsp1, VI6_DL_EXT_CTRL(index),
  

• 	   (0x02 << VI6_DL_EXT_CTRL_POLINT_SHIFT) |
  

• 	   VI6_DL_EXT_CTRL_DLPRI | VI6_DL_EXT_CTRL_EXT);
  

With the DL_SWAP change removed below, this is the only register which needs to be written for each VSP1 index. As such, the loop iterator is moved to this point, so that the VI6_DL_CTRL and VI6_DL_SWAP are not needlessly written multiple times.

...

• vsp1_write(vsp1, VI6_DL_CTRL, ctrl);

• vsp1_write(vsp1, VI6_DL_SWAP, VI6_DL_SWAP_LWS);

• vsp1_write(vsp1, VI6_DL_SWAP(index), VI6_DL_SWAP_LWS |

• 	 ((index == 1) ? VI6_DL_SWAP_IND : 0));
  

Is this change needed ? If VI6_DL_SWAP_IND is not set in VI6_DL_SWAP(1), display list swap for WPF1 is supposed to be controlled by VI6_DL_SWAP(0) according to the datasheet.

If that's not the case and this change is needed, I would split support for VI6_DL_SWAP(n) to a separate patch, and moved it before 07/11.

No - it's a no-op and not needed. Removed.

...

}

void vsp1_dlm_reset(struct vsp1_dl_manager *dlm) @@ -787,7 +855,11 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1, * fragmentation, with the header located right after the body in * memory. */

• header_size = ALIGN(sizeof(struct vsp1_dl_header), 8);

• header_size = vsp1_feature(vsp1, VSP1_HAS_EXT_DL) ?

• 	sizeof(struct vsp1_dl_header_extended) :
  

• 	sizeof(struct vsp1_dl_header);
  

• header_size = ALIGN(header_size, 8);

We will have to improve header handling at some point. Not all headers require extensions.

...

dlm->pool = vsp1_dl_body_pool_create(vsp1, prealloc, VSP1_DL_NUM_ENTRIES, header_size); @@ -803,6 +875,11 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1, return NULL; }

• /* The extended header immediately follows the header */
  

s/ */. */

Fixed.

...

• if (vsp1_feature(vsp1, VSP1_HAS_EXT_DL))
  

• 	dl->extended = (void *)dl->header
  

• 		     + sizeof(*dl->header);
  

• list_add_tail(&dl->list, &dlm->free); }

diff --git a/drivers/media/platform/vsp1/vsp1_dl.h b/drivers/media/platform/vsp1/vsp1_dl.h index 216bd23029dd..aa5f4adc6617 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.h +++ b/drivers/media/platform/vsp1/vsp1_dl.h @@ -20,7 +20,34 @@ struct vsp1_dl_manager; #define VSP1_DL_FRAME_END_COMPLETED BIT(0) #define VSP1_DL_FRAME_END_INTERNAL BIT(1)

-void vsp1_dlm_setup(struct vsp1_device *vsp1); +/**

• • struct vsp1_dl_ext_cmd - Extended Display command
• • @free: entry in the pool of free commands list
• • @cmd_opcode: command type opcode

Maybe just opcode ?

Fixed.

...

• • @flags: flags used by the command
• • @cmds: array of command bodies for this extended cmd
• • @num_cmds: quantity of commands in @cmds array
• • @cmd_dma: DMA address of the command bodies

s/command bodies/commands body/ ?

Fixed.

...

• • @data: memory allocation for command specific data
• • @data_dma: DMA address for command specific data

s/command specific/command-specific/

...

• • @data_size: size of the @data_dma memory in bytes

data_size is set but otherwise never used. Should we drop the field, or make use of it ?

Dropped

...

• */

+struct vsp1_dl_ext_cmd {

• struct list_head free;
• u8 cmd_opcode;
• u32 flags;
• struct vsp1_dl_ext_cmd_header *cmds;
• unsigned int num_cmds;
• dma_addr_t cmd_dma;
• void *data;
• dma_addr_t data_dma;
• size_t data_size;

+};

+void vsp1_dlm_setup(struct vsp1_device *vsp1, unsigned int index);

struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1, unsigned int index, diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index 0fc388bf5a33..26a7b4d32e6c 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -545,7 +545,8 @@ static int vsp1_device_init(struct vsp1_device *vsp1) vsp1_write(vsp1, VI6_DPR_HGT_SMPPT, (7 << VI6_DPR_SMPPT_TGW_SHIFT) | (VI6_DPR_NODE_UNUSED << VI6_DPR_SMPPT_PT_SHIFT));

• vsp1_dlm_setup(vsp1);

• for (i = 0; i < vsp1->info->wpf_count; ++i)

• vsp1_dlm_setup(vsp1, i);
  

With the associated changes, this loop doesn't really have any benefit to being here. Moved to the vsp1_dlm_setup(), and the function prototype is no longer adjusted.

...

return 0; } @@ -754,7 +755,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = { .version = VI6_IP_VERSION_MODEL_VSPD_GEN3, .model = "VSP2-D", .gen = 3,

• .features = VSP1_HAS_BRU | VSP1_HAS_WPF_VFLIP,
  

• .features = VSP1_HAS_BRU | VSP1_HAS_WPF_VFLIP | VSP1_HAS_EXT_DL,
  

  .lif_count = 1, .rpf_count = 5, .uif_count = 1,

@@ -774,7 +775,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = { .version = VI6_IP_VERSION_MODEL_VSPDL_GEN3, .model = "VSP2-DL", .gen = 3,

• .features = VSP1_HAS_BRS | VSP1_HAS_BRU,
  

• .features = VSP1_HAS_BRS | VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
  

  .lif_count = 2, .rpf_count = 5, .uif_count = 2,

diff --git a/drivers/media/platform/vsp1/vsp1_regs.h b/drivers/media/platform/vsp1/vsp1_regs.h index 0d249ff9f564..d054767570c1 100644 --- a/drivers/media/platform/vsp1/vsp1_regs.h +++ b/drivers/media/platform/vsp1/vsp1_regs.h @@ -67,12 +67,13 @@

#define VI6_DL_HDR_ADDR(n) (0x0104 + (n) * 4)

-#define VI6_DL_SWAP 0x0114 +#define VI6_DL_SWAP(n) (0x0114 + (n) * 56) +#define VI6_DL_SWAP_IND (1 << 31)

Removed.

...

#define VI6_DL_SWAP_LWS (1 << 2) #define VI6_DL_SWAP_WDS (1 << 1) #define VI6_DL_SWAP_BTS (1 << 0)

-#define VI6_DL_EXT_CTRL 0x011c +#define VI6_DL_EXT_CTRL(n) (0x011c + (n) * 36) #define VI6_DL_EXT_CTRL_NWE (1 << 16) #define VI6_DL_EXT_CTRL_POLINT_MASK (0x3f << 8) #define VI6_DL_EXT_CTRL_POLINT_SHIFT 8

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:20 EEST Kieran Bingham wrote:

VSPD and VSP-DL devices can provide extended display lists supporting extended command display list objects.

These extended commands require their own dma memory areas for a header and body specific to the command type.

Implement a command pool to allocate all necessary memory in a single DMA allocation to reduce pressure on the TLB, and provide convenient re-usable command objects for the entities to utilise.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

---

v2:

• Fix spelling typo in commit message
• constify, and staticify the instantiation of vsp1_extended_commands
• s/autfld_cmds/autofld_cmds/
• staticify cmd pool functions (Thanks kbuild-bot)

---

drivers/media/platform/vsp1/vsp1_dl.c | 191 +++++++++++++++++++++++++++- drivers/media/platform/vsp1/vsp1_dl.h | 3 +- 2 files changed, 194 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index b64d32535edc..d33ae5f125bd 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -117,6 +117,30 @@ struct vsp1_dl_body_pool { };

/**

• • struct vsp1_cmd_pool - display list body pool

The structure is called vsp1_dl_cmd_pool. I would document it as "Display list commands pool", not "body pool".

• • @dma: DMA address of the entries
• • @size: size of the full DMA memory pool in bytes
• • @mem: CPU memory pointer for the pool
• • @bodies: Array of DLB structures for the pool

The field is called cmds.

• • @free: List of free DLB entries

"free pool entries" or "free command entries" ?

• • @lock: Protects the pool and free list

The pool is the whole structure, does the lock really protects all fields ?

• • @vsp1: the VSP1 device
• */

+struct vsp1_dl_cmd_pool {

• /* DMA allocation */
• dma_addr_t dma;
• size_t size;
• void *mem;
• struct vsp1_dl_ext_cmd *cmds;
• struct list_head free;
• spinlock_t lock;
• struct vsp1_device *vsp1;

+};

+/**

• struct vsp1_dl_list - Display list
• @list: entry in the display list manager lists
• @dlm: the display list manager

@@ -162,6 +186,7 @@ struct vsp1_dl_list {

• @queued: list queued to the hardware (written to the DL registers)
• @pending: list waiting to be queued to the hardware
• @pool: body pool for the display list bodies

• • @autofld_cmds: command pool to support auto-fld interlaced mode

This could also be used for auto-disp. How about calling it cmdpool ?

*/ struct vsp1_dl_manager { unsigned int index; @@ -175,6 +200,7 @@ struct vsp1_dl_manager { struct vsp1_dl_list *pending;

struct vsp1_dl_body_pool *pool;

• struct vsp1_dl_cmd_pool *autofld_cmds;

};

/* ------------------------------------------------------------------------ @@ -338,6 +364,140 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, u32 data) }

/* ------------------------------------------------------------------------

• • Display List Extended Command Management
• */

+enum vsp1_extcmd_type {

• VSP1_EXTCMD_AUTODISP,
• VSP1_EXTCMD_AUTOFLD,

+};

+struct vsp1_extended_command_info {

• u16 opcode;
• size_t body_size;

+} static const vsp1_extended_commands[] = {

The location of the static const keywords is strange. I would move them before struct, or split the structure definition and variable declaration.

• [VSP1_EXTCMD_AUTODISP] = { 0x02, 96 },
• [VSP1_EXTCMD_AUTOFLD] = { 0x03, 160 },

+};

+/**

• • vsp1_dl_cmd_pool_create - Create a pool of commands from a single

allocation

• • @vsp1: The VSP1 device
• • @type: The command pool type
• • @num_commands: The quantity of commands to allocate

s/quantity/number/ ?

• • Allocate a pool of commands each with enough memory to contain the

private

• • data of each command. The allocation sizes are dependent upon the

command

• • type.
• • Return a pointer to a pool on success or NULL if memory can't be

s/a pool/the pool/

allocated.

• */

+static struct vsp1_dl_cmd_pool * +vsp1_dl_cmd_pool_create(struct vsp1_device *vsp1, enum vsp1_extcmd_type type,

• 	unsigned int num_cmds)
  

+{

• struct vsp1_dl_cmd_pool *pool;
• unsigned int i;
• size_t cmd_size;
• pool = kzalloc(sizeof(*pool), GFP_KERNEL);
• if (!pool)

• return NULL;
  

• pool->cmds = kcalloc(num_cmds, sizeof(*pool->cmds), GFP_KERNEL);
• if (!pool->cmds) {

• kfree(pool);
  

• return NULL;
  

• }
• cmd_size = sizeof(struct vsp1_dl_ext_cmd_header) +

•    vsp1_extended_commands[type].body_size;
  

• cmd_size = ALIGN(cmd_size, 16);
• pool->size = cmd_size * num_cmds;
• pool->mem = dma_alloc_wc(vsp1->bus_master, pool->size, &pool->dma,

• 		 GFP_KERNEL);
  

• if (!pool->mem) {

• kfree(pool->cmds);
  

• kfree(pool);
  

• return NULL;
  

• }
• spin_lock_init(&pool->lock);
• INIT_LIST_HEAD(&pool->free);

I would move these two lines right after allocation of pool, I find it more readable to perform small and simple initialization right away.

• for (i = 0; i < num_cmds; ++i) {

• struct vsp1_dl_ext_cmd *cmd = &pool->cmds[i];
  

• size_t cmd_offset = i * cmd_size;
  

• size_t data_offset = sizeof(struct vsp1_dl_ext_cmd_header) +
  

• 		     cmd_offset;
  

The data memory has to be 16-bytes aligned. This is guaranteed as the header is 16 bytes long, and cmd_size is aligned to 16 bytes, but it would be worth adding a comment to explain this.

• cmd->pool = pool;
  

• cmd->cmd_opcode = vsp1_extended_commands[type].opcode;
  

• /* TODO: Auto-disp can utilise more than one command per cmd */
  

That will be annoying to handle :-/

• cmd->num_cmds = 1;
  

• cmd->cmds = pool->mem + cmd_offset;
  

• cmd->cmd_dma = pool->dma + cmd_offset;
  

• cmd->data = pool->mem + data_offset;
  

• cmd->data_dma = pool->dma + data_offset;
  

• cmd->data_size = vsp1_extended_commands[type].body_size;
  

• list_add_tail(&cmd->free, &pool->free);
  

• }
• return pool;

+}

+static +struct vsp1_dl_ext_cmd *vsp1_dl_ext_cmd_get(struct vsp1_dl_cmd_pool *pool) +{

• struct vsp1_dl_ext_cmd *cmd = NULL;
• unsigned long flags;
• spin_lock_irqsave(&pool->lock, flags);
• if (!list_empty(&pool->free)) {

• cmd = list_first_entry(&pool->free, struct vsp1_dl_ext_cmd,
  

• 		       free);
  

• list_del(&cmd->free);
  

• }
• spin_unlock_irqrestore(&pool->lock, flags);
• return cmd;

+}

+static void vsp1_dl_ext_cmd_put(struct vsp1_dl_ext_cmd *cmd) +{

• unsigned long flags;
• if (!cmd)

• return;
  

• /* Reset flags, these mark data usage */

s/usage/usage./

• cmd->flags = 0;
• spin_lock_irqsave(&cmd->pool->lock, flags);
• list_add_tail(&cmd->free, &cmd->pool->free);
• spin_unlock_irqrestore(&cmd->pool->lock, flags);

+}

+static void vsp1_dl_ext_cmd_pool_destroy(struct vsp1_dl_cmd_pool *pool) +{

• if (!pool)

• return;
  

• if (pool->mem)

• dma_free_wc(pool->vsp1->bus_master, pool->size, pool->mem,
  

• 	    pool->dma);
  

• kfree(pool->cmds);
• kfree(pool);

+}

+/* ------------------------------------------------------------------------

• • Display List Transaction Management
  */

@@ -440,6 +600,12 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)

vsp1_dl_list_bodies_put(dl);

• vsp1_dl_ext_cmd_put(dl->pre_cmd);
• vsp1_dl_ext_cmd_put(dl->post_cmd);
• dl->pre_cmd = NULL;
• dl->post_cmd = NULL;
• /*
  • body0 is reused as as an optimisation as presently every display list
  • has at least one body, thus we reinitialise the entries list.

@@ -883,6 +1049,15 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1, list_add_tail(&dl->list, &dlm->free); }

• if (vsp1_feature(vsp1, VSP1_HAS_EXT_DL)) {

• dlm->autofld_cmds = vsp1_dl_cmd_pool_create(vsp1,
  

• 			VSP1_EXTCMD_AUTOFLD, prealloc);
  

• if (!dlm->autofld_cmds) {
  

• 	vsp1_dlm_destroy(dlm);
  

• 	return NULL;
  

• }
  

• }
• return dlm;

}

@@ -899,4 +1074,20 @@ void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm) }

vsp1_dl_body_pool_destroy(dlm->pool);

• vsp1_dl_ext_cmd_pool_destroy(dlm->autofld_cmds);

+}

+struct vsp1_dl_ext_cmd *vsp1_dlm_get_autofld_cmd(struct vsp1_dl_list *dl) +{

• struct vsp1_dl_manager *dlm = dl->dlm;
• struct vsp1_dl_ext_cmd *cmd;
• if (dl->pre_cmd)

• return dl->pre_cmd;
  

• cmd = vsp1_dl_ext_cmd_get(dlm->autofld_cmds);
• if (cmd)

• dl->pre_cmd = cmd;
  

• return cmd;

You can write it in a simpler way.

dl->pre_cmd = vsp1_dl_ext_cmd_get(dlm->autofld_cmds); return dl->pre_cmd;

} diff --git a/drivers/media/platform/vsp1/vsp1_dl.h b/drivers/media/platform/vsp1/vsp1_dl.h index aa5f4adc6617..d9621207b093 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.h +++ b/drivers/media/platform/vsp1/vsp1_dl.h @@ -22,6 +22,7 @@ struct vsp1_dl_manager;

/**

• struct vsp1_dl_ext_cmd - Extended Display command

• • @pool: pool to which this command belongs
  • @free: entry in the pool of free commands list
  • @cmd_opcode: command type opcode
  • @flags: flags used by the command

@@ -33,6 +34,7 @@ struct vsp1_dl_manager;

• @data_size: size of the @data_dma memory in bytes

*/ struct vsp1_dl_ext_cmd {

• struct vsp1_dl_cmd_pool *pool; struct list_head free;

  u8 cmd_opcode;

@@ -55,6 +57,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1, void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm); void vsp1_dlm_reset(struct vsp1_dl_manager *dlm); unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm); +struct vsp1_dl_ext_cmd *vsp1_dlm_get_autofld_cmd(struct vsp1_dl_list *dl);

Should this be named vsp1_dl_get_autofld_cmd() as it operates on a dl ? I also think that you should move it down to group it with the dl functions.

struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm); void vsp1_dl_list_put(struct vsp1_dl_list *dl);

Hi Laurent,

Some questions here too :)

On 24/05/18 13:51, Laurent Pinchart wrote:

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:

...

Calculate the top and bottom fields for the interlaced frames and utilise the extended display list command feature to implement the auto-field operations. This allows the DU to update the VSP2 registers dynamically based upon the currently processing field.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

---

v3:

• Pass DL through partition calls to allow autocmd's to be retrieved
• Document interlaced field in struct vsp1_du_atomic_config

v2:

• fix erroneous BIT value which enabled interlaced
• fix field handling at frame_end interrupt

---

drivers/media/platform/vsp1/vsp1_dl.c | 10 ++++- drivers/media/platform/vsp1/vsp1_drm.c | 11 ++++- drivers/media/platform/vsp1/vsp1_regs.h | 1 +- drivers/media/platform/vsp1/vsp1_rpf.c | 71 ++++++++++++++++++++++++-- drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +- include/media/vsp1.h | 2 +- 6 files changed, 93 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index d33ae5f125bd..bbe9f3006f71 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -906,6 +906,8 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool internal) */ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm) {

• struct vsp1_device *vsp1 = dlm->vsp1;

• u32 status = vsp1_read(vsp1, VI6_STATUS); unsigned int flags = 0;

  spin_lock(&dlm->lock);

@@ -931,6 +933,14 @@ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm) goto done;

/*

• * Progressive streams report only TOP fields. If we have a BOTTOM
  

• * field, we are interlaced, and expect the frame to complete on the
  

• * next frame end interrupt.
  

• */
  

• if (status & VI6_STATUS_FLD_STD(dlm->index))

• goto done;
  

• /*
  • The device starts processing the queued display list right after the
  • frame end interrupt. The display list thus becomes active.
  */

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c b/drivers/media/platform/vsp1/vsp1_drm.c index 2c3db8b8adce..cc29c9d96bb7 100644 --- a/drivers/media/platform/vsp1/vsp1_drm.c +++ b/drivers/media/platform/vsp1/vsp1_drm.c @@ -811,6 +811,17 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int pipe_index, return -EINVAL; }

• if (!(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)) && cfg->interlaced) {

Nitpicking, writing the condition as

if (cfg->interlaced && !(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)))

Done.

would match the comment better. You can also drop the parentheses around the vsp1_feature() call.

...

• /*
  

•  * Interlaced support requires extended display lists to
  

•  * provide the auto-fld feature with the DU.
  

•  */
  

• dev_dbg(vsp1->dev, "Interlaced unsupported on this output\n");
  

Could we catch this in the DU driver to fail atomic test ?

Ugh - I thought moving the configuration to vsp1_du_setup_lif() would give us this, but that return value is not checked in the DU.

How can we interogate the VSP1 to ask it if it supports interlaced from rcar_du_vsp_plane_atomic_check()?

Some dummy call to vsp1_du_setup_lif() to check the return value ? Or should we implement a hook to call through to perform checks in the VSP1 DRM API?

...

• return -EINVAL;
  

• }
• rpf->interlaced = cfg->interlaced;
• rpf->fmtinfo = fmtinfo; rpf->format.num_planes = fmtinfo->planes; rpf->format.plane_fmt[0].bytesperline = cfg->pitch;

diff --git a/drivers/media/platform/vsp1/vsp1_regs.h b/drivers/media/platform/vsp1/vsp1_regs.h index d054767570c1..a2ac65cc5155 100644 --- a/drivers/media/platform/vsp1/vsp1_regs.h +++ b/drivers/media/platform/vsp1/vsp1_regs.h @@ -28,6 +28,7 @@ #define VI6_SRESET_SRTS(n) (1 << (n))

#define VI6_STATUS 0x0038 +#define VI6_STATUS_FLD_STD(n) (1 << ((n) + 28)) #define VI6_STATUS_SYS_ACT(n) (1 << ((n) + 8))

#define VI6_WPF_IRQ_ENB(n) (0x0048 + (n) * 12) diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c index 8fae7c485642..511b2e127820 100644 --- a/drivers/media/platform/vsp1/vsp1_rpf.c +++ b/drivers/media/platform/vsp1/vsp1_rpf.c @@ -20,6 +20,20 @@ #define RPF_MAX_WIDTH 8190 #define RPF_MAX_HEIGHT 8190

+/* Pre extended display list command data structure */ +struct vsp1_extcmd_auto_fld_body {

• u32 top_y0;
• u32 bottom_y0;
• u32 top_c0;
• u32 bottom_c0;
• u32 top_c1;
• u32 bottom_c1;
• u32 reserved0;
• u32 reserved1;

+} __packed;

+#define VSP1_DL_EXT_AUTOFLD_INT BIT(0)

Should the bit definition be moved to vsp1_regs.h ?

Moved, (and renamed s/VSP1_/VI6_/)

...

/* ------------------------------------------------------------------------

• Device Access

*/ @@ -64,6 +78,14 @@ static void rpf_configure_stream(struct vsp1_entity *entity, pstride |= format->plane_fmt[1].bytesperline << VI6_RPF_SRCM_PSTRIDE_C_SHIFT;

• /*

• * pstride has both STRIDE_Y and STRIDE_C, but multiplying the whole
  

• * of pstride by 2 is conveniently OK here as we are multiplying both
  

• * values.
  

• */
  

• if (rpf->interlaced)

• pstride *= 2;
  

• vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_PSTRIDE, pstride);

  /* Format */

@@ -100,6 +122,9 @@ static void rpf_configure_stream(struct vsp1_entity *entity, top = compose->top; }

• if (rpf->interlaced)

• top /= 2;
  

• vsp1_rpf_write(rpf, dlb, VI6_RPF_LOC, (left << VI6_RPF_LOC_HCOORD_SHIFT) | (top << VI6_RPF_LOC_VCOORD_SHIFT));

@@ -169,6 +194,31 @@ static void rpf_configure_stream(struct vsp1_entity *entity,

}

+static void vsp1_rpf_configure_autofld(struct vsp1_rwpf *rpf,

• 		       struct vsp1_dl_ext_cmd *cmd)
  

+{

• const struct v4l2_pix_format_mplane *format = &rpf->format;
• struct vsp1_extcmd_auto_fld_body *auto_fld = cmd->data;
• u32 offset_y, offset_c;
• /* Re-index our auto_fld to match the current RPF */

s/RPF/RPF./

Fixed.

...

• auto_fld = &auto_fld[rpf->entity.index];
• auto_fld->top_y0 = rpf->mem.addr[0];
• auto_fld->top_c0 = rpf->mem.addr[1];
• auto_fld->top_c1 = rpf->mem.addr[2];
• offset_y = format->plane_fmt[0].bytesperline;
• offset_c = format->plane_fmt[1].bytesperline;
• auto_fld->bottom_y0 = rpf->mem.addr[0] + offset_y;
• auto_fld->bottom_c0 = rpf->mem.addr[1] + offset_c;
• auto_fld->bottom_c1 = rpf->mem.addr[2] + offset_c;
• cmd->flags |= VSP1_DL_EXT_AUTOFLD_INT;
• cmd->flags |= BIT(16 + rpf->entity.index);

Do you expect some flags to already be set ? If not, couldn't we assign the value to the field instead of OR'ing it ?

No, I think you are correct. Moved to a single expression setting the cmd->flags in one line.

...

+}

static void rpf_configure_frame(struct vsp1_entity *entity, struct vsp1_pipeline *pipe, struct vsp1_dl_list *dl, @@ -192,6 +242,7 @@ static void rpf_configure_partition(struct vsp1_entity *entity, struct vsp1_rwpf *rpf = to_rwpf(&entity->subdev); struct vsp1_rwpf_memory mem = rpf->mem; struct vsp1_device *vsp1 = rpf->entity.vsp1;

• struct vsp1_dl_ext_cmd *cmd; const struct vsp1_format_info *fmtinfo = rpf->fmtinfo; const struct v4l2_pix_format_mplane *format = &rpf->format; struct v4l2_rect crop;

@@ -220,6 +271,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity, crop.left += pipe->partition->rpf.left; }

• if (rpf->interlaced) {

• crop.height = round_down(crop.height / 2, fmtinfo->vsub);
  

• crop.top = round_down(crop.top / 2, fmtinfo->vsub);
  

• }
• vsp1_rpf_write(rpf, dlb, VI6_RPF_SRC_BSIZE, (crop.width << VI6_RPF_SRC_BSIZE_BHSIZE_SHIFT) | (crop.height << VI6_RPF_SRC_BSIZE_BVSIZE_SHIFT));

@@ -248,9 +304,18 @@ static void rpf_configure_partition(struct vsp1_entity *entity, fmtinfo->swap_uv) swap(mem.addr[1], mem.addr[2]);

• vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_Y, mem.addr[0]);
• vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C0, mem.addr[1]);
• vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C1, mem.addr[2]);

• /*

• * Interlaced pipelines will use the extended pre-cmd to process
  

• * SRCM_ADDR_{Y,C0,C1}
  

• */
  

• if (rpf->interlaced) {

• cmd = vsp1_dlm_get_autofld_cmd(dl);
  

How about moving this call to vsp1_rpf_configure_autofld() ?

Done.

...

• vsp1_rpf_configure_autofld(rpf, cmd);
  

• } else {

• vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_Y, mem.addr[0]);
  

• vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C0, mem.addr[1]);
  

• vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C1, mem.addr[2]);
  

• }

}

static void rpf_partition(struct vsp1_entity *entity, diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h b/drivers/media/platform/vsp1/vsp1_rwpf.h index 70742ecf766f..8d6e42f27908 100644 --- a/drivers/media/platform/vsp1/vsp1_rwpf.h +++ b/drivers/media/platform/vsp1/vsp1_rwpf.h @@ -42,6 +42,7 @@ struct vsp1_rwpf { struct v4l2_pix_format_mplane format; const struct vsp1_format_info *fmtinfo; unsigned int brx_input;

• bool interlaced;

Shouldn't this be stored in the pipeline instead ? Interlacing is a property of the whole pipeline, not of each input individually.

Moved.

...

unsigned int alpha;

diff --git a/include/media/vsp1.h b/include/media/vsp1.h index 678c24de1ac6..c10883f30980 100644 --- a/include/media/vsp1.h +++ b/include/media/vsp1.h @@ -50,6 +50,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,

• @dst: destination rectangle on the display (integer coordinates)
• @alpha: alpha value (0: fully transparent, 255: fully opaque)
• @zpos: Z position of the plane (from 0 to number of planes minus 1)

• • @interlaced: true for interlaced pipelines
  */

struct vsp1_du_atomic_config { u32 pixelformat; @@ -59,6 +60,7 @@ struct vsp1_du_atomic_config { struct v4l2_rect dst; unsigned int alpha; unsigned int zpos;

• bool interlaced;

For the same reason shouldn't the interlaced flag be moved to vsp1_du_lif_config ?

Moved.

...

};

/**

Hi Laurent,

On 17/07/18 13:52, Laurent Pinchart wrote:

Hi Kieran,

On Monday, 16 July 2018 21:21:00 EEST Kieran Bingham wrote:

...

On 24/05/18 13:51, Laurent Pinchart wrote:

...

On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:

...

Calculate the top and bottom fields for the interlaced frames and utilise the extended display list command feature to implement the auto-field operations. This allows the DU to update the VSP2 registers dynamically based upon the currently processing field.

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

---

v3:

• Pass DL through partition calls to allow autocmd's to be retrieved
• Document interlaced field in struct vsp1_du_atomic_config

v2:

• fix erroneous BIT value which enabled interlaced
• fix field handling at frame_end interrupt

---

drivers/media/platform/vsp1/vsp1_dl.c | 10 ++++- drivers/media/platform/vsp1/vsp1_drm.c | 11 ++++- drivers/media/platform/vsp1/vsp1_regs.h | 1 +- drivers/media/platform/vsp1/vsp1_rpf.c | 71 ++++++++++++++++++++++++-- drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +- include/media/vsp1.h | 2 +- 6 files changed, 93 insertions(+), 3 deletions(-)

[snip]

...

...

...

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c b/drivers/media/platform/vsp1/vsp1_drm.c index 2c3db8b8adce..cc29c9d96bb7 100644 --- a/drivers/media/platform/vsp1/vsp1_drm.c +++ b/drivers/media/platform/vsp1/vsp1_drm.c @@ -811,6 +811,17 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int pipe_index, return -EINVAL;

}

• if (!(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)) && cfg->interlaced) {

Nitpicking, writing the condition as

if (cfg->interlaced && !(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)))

Done.

...

would match the comment better. You can also drop the parentheses around the vsp1_feature() call.

...

• /*
  

•  * Interlaced support requires extended display lists to
  

•  * provide the auto-fld feature with the DU.
  

•  */
  

• dev_dbg(vsp1->dev, "Interlaced unsupported on this output\n");
  

Could we catch this in the DU driver to fail atomic test ?

Ugh - I thought moving the configuration to vsp1_du_setup_lif() would give us this, but that return value is not checked in the DU.

How can we interogate the VSP1 to ask it if it supports interlaced from rcar_du_vsp_plane_atomic_check()?

Some dummy call to vsp1_du_setup_lif() to check the return value ? Or should we implement a hook to call through to perform checks in the VSP1 DRM API?

Would it be possible to just infer that from the DU compatible string, without querying the VSP driver ? Of course that's a bit of a layering violation, but as we know what type of VSP instance is present in each SoC, such a small hack wouldn't hurt in my opinion. If the need arises later we can introduce an API to query the information from the VSP driver.

I'm not sure what there is to match on currently.

I thought that we had restrictions on which display pipelines supported interlaced. (i.e. D3/E3 might not) - but they seem to support extended display lists ...

So isn't it the case that any pipeline which we connect to DRM supports interlaced? (currently) - we can't / don't physically connect other VSP entities to the DRM pipes...

...

...

...

• return -EINVAL;
  

• }
• rpf->interlaced = cfg->interlaced;
• rpf->fmtinfo = fmtinfo; rpf->format.num_planes = fmtinfo->planes; rpf->format.plane_fmt[0].bytesperline = cfg->pitch;

[snip]

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:

Use the newly exposed VSP1 interface to enable interlaced frame support through the VSP1 lif pipelines.

s/lif/LIF/

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index d71d709fe3d9..206532959ec9 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -289,6 +289,7 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) /* Signal polarities */ value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0) | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)

•      | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
  

How will this affect Gen2 ? Could you document what this change does in the commit message ?

     | DSMR_DIPM_DISP | DSMR_CSPM;

rcar_du_crtc_write(rcrtc, DSMR, value);

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index af7822a66dee..c7b37232ee91 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -186,6 +186,9 @@ static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) }; unsigned int i;

• cfg.interlaced = !!(plane->plane.state->crtc->mode.flags

• 	    & DRM_MODE_FLAG_INTERLACE);
  

• cfg.src.left = state->state.src.x1 >> 16; cfg.src.top = state->state.src.y1 >> 16; cfg.src.width = drm_rect_width(&state->state.src) >> 16;

Hi Kieran,

On Monday, 16 July 2018 20:20:30 EEST Kieran Bingham wrote:

On 24/05/18 12:50, Laurent Pinchart wrote:

...

On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:

...

Use the newly exposed VSP1 interface to enable interlaced frame support through the VSP1 lif pipelines.

s/lif/LIF/

Fixed.

...

...

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index d71d709fe3d9..206532959ec9 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -289,6 +289,7 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) /* Signal polarities */ value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0) | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)

•      | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
  

How will this affect Gen2 ?.

The bit is documented identically for Gen2. Potentially / Probably it 'might' reverse the fields... I'm not certain yet. I don't have access to a Gen2 platform to test.

I'll see if this change can be dropped, but I think it is playing a role in ensuring that the field detection occurs in VSP1 through the VI6_STATUS_FLD_STD() field. (see vsp1_dlm_irq_frame_end())

...

Could you document what this change does in the commit message ?

This sets the position in the buffer of the ODDF. With this set, the ODD field is located in the second half (BOTTOM) of the same frame of the interlace display.

Otherwise, it's in the first half (TOP)

I faced some issues as to the ordering when testing, so I suspect this might actually be related to that. (re VI6_STATUS_FLD_STD in vsp1_dlm_irq_frame_end()).

As you mention - this may have a negative effect on the Gen2 implementation - so it needs considering with that.

/me to investigate further.

Thank you. I don't object to this change, but I'd like to know what its implications are on Gen2. It might even fix a bug :-) Let me know if you'd like me to run tests on a Lager board.

...

...

     | DSMR_DIPM_DISP | DSMR_CSPM;

rcar_du_crtc_write(rcrtc, DSMR, value);

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index af7822a66dee..c7b37232ee91 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -186,6 +186,9 @@ static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) }; unsigned int i;

• cfg.interlaced = !!(plane->plane.state->crtc->mode.flags

• 	    & DRM_MODE_FLAG_INTERLACE);
  

• cfg.src.left = state->state.src.x1 >> 16; cfg.src.top = state->state.src.y1 >> 16; cfg.src.width = drm_rect_width(&state->state.src) >> 16;

Hi Kieran,

On Tuesday, 17 July 2018 23:32:56 EEST Kieran Bingham wrote:

On 17/07/18 14:51, Laurent Pinchart wrote:

...

On Monday, 16 July 2018 20:20:30 EEST Kieran Bingham wrote:

...

On 24/05/18 12:50, Laurent Pinchart wrote:

...

On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:

...

Use the newly exposed VSP1 interface to enable interlaced frame support through the VSP1 lif pipelines.

s/lif/LIF/

Fixed.

...

...

Signed-off-by: Kieran Bingham kieran.bingham+renesas@ideasonboard.com

drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index d71d709fe3d9..206532959ec9 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -289,6 +289,7 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc)

/* Signal polarities */ value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)

     | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)

•      | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
  

How will this affect Gen2 ?.

The bit is documented identically for Gen2. Potentially / Probably it 'might' reverse the fields... I'm not certain yet. I don't have access to a Gen2 platform to test.

I'll see if this change can be dropped, but I think it is playing a role in ensuring that the field detection occurs in VSP1 through the VI6_STATUS_FLD_STD() field. (see vsp1_dlm_irq_frame_end())

...

Could you document what this change does in the commit message ?

This sets the position in the buffer of the ODDF. With this set, the ODD field is located in the second half (BOTTOM) of the same frame of the interlace display.

Otherwise, it's in the first half (TOP)

I faced some issues as to the ordering when testing, so I suspect this might actually be related to that. (re VI6_STATUS_FLD_STD in vsp1_dlm_irq_frame_end()).

As you mention - this may have a negative effect on the Gen2 implementation - so it needs considering with that.

/me to investigate further.

Thank you. I don't object to this change, but I'd like to know what its implications are on Gen2. It might even fix a bug :-) Let me know if you'd like me to run tests on a Lager board.

I've done some testing with this (removing the DSMR change, and inverting the VI6_STATUS_FLD_STD handling) and had some odd results. Perhaps my testing needs refinement.

So, yes please - I think I'd really like to know what the effects are on a Lager platform.

Would you (or anyone with a Gen2 and interest in vsp1/du) be able to test my latest vsp1/du/interlaced branch/tag on your local Gen2 platform please?

I can test it when I'll come back home on the 24th (or rather on the next day as I'll land in the evening). Could you please ping me on the 25th ?

I'm testing interlaced with:

kmstest # sanity test. kmstest -c 1 -r 1920x1080i --flip

My monitors don't support interlaced modes, so this won't be easy :-/

Also, what's the expected outcome of the above command in the working and non- working cases ?

Any (easy) other methods for testing interlaced pipelines are welcome.

Is it possible to set the mode for kmscube? (--help doesn't look promising)

Not that I know of, but I think that shouldn't be too difficult to add.

I have various test streams of interlaced media content in my media library, but not an easy way of decoding and presenting these on the screen on the Gen3.

I believe GStreamer now has a drm/kms sink ... Perhaps I should get that recompiled. (That would help me with other tasks too actually)

...

...

...

...

     | DSMR_DIPM_DISP | DSMR_CSPM;

rcar_du_crtc_write(rcrtc, DSMR, value);

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index af7822a66dee..c7b37232ee91 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -186,6 +186,9 @@ static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) }; unsigned int i;

• cfg.interlaced = !!(plane->plane.state->crtc->mode.flags

• 	    & DRM_MODE_FLAG_INTERLACE);
  

• cfg.src.left = state->state.src.x1 >> 16; cfg.src.top = state->state.src.y1 >> 16; cfg.src.width = drm_rect_width(&state->state.src) >> 16;