tree 8aaf628c5118176239924e864ba483039569679d
parent 3e7caae5f2853436153a7d5f253fd7e0e720f4b8
author Stanimir Varbanov <stanimir.varbanov@linaro.org> 1500465097 -0400
committer Mauro Carvalho Chehab <mchehab@s-opensource.com> 1501064072 -0400

media: venus: don't abuse dma_alloc for non-DMA allocations

In venus_boot(), we pass a pointer to a phys_addr_t
into dmam_alloc_coherent, which the compiler warns about:

platform/qcom/venus/firmware.c: In function 'venus_boot':
platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]

To avoid the error refactor venus_boot function by discard
dma_alloc_coherent invocation because we don't want to map the
memory for the device.  Something more, the usage of
DMA mapping API is actually wrong and the current
implementation relies on several bugs in DMA mapping code.
When these bugs are fixed that will break firmware loading,
so fix this now to avoid future troubles.

The meaning of venus_boot is to copy the content of the
firmware buffer into reserved (and memblock removed)
block of memory and pass that physical address to the
trusted zone for authentication and mapping through iommu
form the secure world. After iommu mapping is done the iova
is passed as ane entry point to the remote processor.

After this change memory-region property is parsed manually
and the physical address is memremap to CPU, call mdt_load to
load firmware segments into proper places and unmap
reserved memory.

Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>