• Stanimir Varbanov's avatar
    media: venus: don't abuse dma_alloc for non-DMA allocations · a6e2d36b
    Stanimir Varbanov authored
    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: af2c3834 ("[media] media: venus: adding core part and helper functions")
    Signed-off-by: default avatarStanimir Varbanov <stanimir.varbanov@linaro.org>
    Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
    Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
    a6e2d36b
firmware.h 681 Bytes