media: mediatek: vcodec: Add encoder driver support for 34-bit iova
Encoder driver got iova from IOMMU is 34-bit, for example: Here is the sample code: encoder input frame buffer dma address is: frm_buf = vb2_dma_contig_plane_dma_addr(&vb2_v4l2_buffer->vb2_buf, 0); the value of frm_buf is 0x1_ff30_0000. encoder driver got the frm_buf and send the iova to SCP firmware through SCP IPI message, then write to encoder hardware in SCP. The iova is stored in IPI message as uint32_t data type, so the value will be truncated from *0x1_ff30_0000* to *0xff30_0000*, and then *0xff30_0000* will be written to encoder hardware, but IOMMU will help to add the high *0x1_* bit back, so IOMMU can translate the iova to PA correctly, encoder hardware can access the correct memory for encoding. Another reason to do this is the encoder hardware can't access the 34-bit iova, IOMMU will help to add the remaining high bits of iova. But for mt8188, encoder hardware can access 34-bit iova directly, and encoder driver need write all 34 bits because IOMMU can't help driver do this if the hardware support access 34-bit iova. For the reasons above, this patch is added to support transfer 34-bit iova between kernel and SCP encoder driver. Use uint64_t data type to store the iova, for compatibility with old chipsets, add some new struct definitions for 34-bit. [hverkuil: initialize wb and wb_34 to NULL] Signed-off-by: Irui Wang <irui.wang@mediatek.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Showing
This diff is collapsed.
Please register or sign in to comment