On Thu, Jul 20, 2017 at 1:26 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
> On 19/07/17 13:51, Stanimir Varbanov wrote:
>> 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@xxxxxxxxxx>
>
> Arnd, is this OK for you?
Looks good
Reviewed-by: Arnd Bergmann <arnd@xxxxxxxx>
