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>
As the end goal is to have platform drivers split by vendor,
rename mediatek/mtk-jpeg/ to mediatek/jpeg/.
Requested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
