@@ -481,7 +481,6 @@ void vfe_buf_done(struct vfe_device *vfe, int wm)
ops->vfe_wm_update(vfe, output->wm_idx[0],
output->buf[index]->addr[0],
line);
- ops->reg_update(vfe, line->id);
} else {
output->gen2.active_num--;
}
@@ -546,9 +545,10 @@ int vfe_enable_output_v2(struct vfe_line *line)
output->gen2.active_num++;
ops->vfe_wm_update(vfe, output->wm_idx[0],
output->buf[i]->addr[0], line);
- ops->reg_update(vfe, line->id);
}
+ ops->reg_update(vfe, line->id);
+
spin_unlock_irqrestore(&vfe->output_lock, flags);
return 0;
@@ -582,7 +582,6 @@ int vfe_queue_buffer_v2(struct camss_video *vid,
output->buf[output->gen2.active_num++] = buf;
ops->vfe_wm_update(vfe, output->wm_idx[0],
buf->addr[0], line);
- ops->reg_update(vfe, line->id);
} else {
vfe_buf_add_pending(output, buf);
}
Today, we submit a RUP command (reg_update) after queuing a new frame buffer using vfe_wm_update. However, vfe_wm_update writes the buffer address to a FIFO register which does not require a subsequent RUP command, as this register is not double-buffered like other config or control shadow registers. This results in the capture process generating twice the expected number of interrupts, with one RUP done and one BUF done interrupt for each frame. We can relax the interrupt pressure and VFE load by removing this extra RUP command, which is only necessary when initializing or reconfiguring the VFE. Note: this has only been tested with vfe-340/qcm2290, the assumption is that the other VFEs behave similarly. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> --- drivers/media/platform/qcom/camss/camss-vfe.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)