From patchwork Tue Jun 27 15:02:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 9812313 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id D9AAD60351 for ; Tue, 27 Jun 2017 15:06:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CDBBB28589 for ; Tue, 27 Jun 2017 15:06:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C25C028592; Tue, 27 Jun 2017 15:06:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 18E6E28589 for ; Tue, 27 Jun 2017 15:06:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753227AbdF0PF6 (ORCPT ); Tue, 27 Jun 2017 11:05:58 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:64543 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753262AbdF0PDh (ORCPT ); Tue, 27 Jun 2017 11:03:37 -0400 Received: from wuerfel.lan ([5.56.224.194]) by mrelayeu.kundenserver.de (mreue003 [212.227.15.129]) with ESMTPA (Nemesis) id 0LyyIe-1dlsyI1VEO-014Er0; Tue, 27 Jun 2017 17:03:22 +0200 From: Arnd Bergmann To: Stanimir Varbanov , Mauro Carvalho Chehab Cc: Arnd Bergmann , Hans Verkuil , linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/3] [media] venus: don't abuse dma_alloc for non-DMA allocations Date: Tue, 27 Jun 2017 17:02:47 +0200 Message-Id: <20170627150310.719212-2-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20170627150310.719212-1-arnd@arndb.de> References: <20170627150310.719212-1-arnd@arndb.de> X-Provags-ID: V03:K0:AOplKcxZLtdWFYHHX3xHvvKCwLoNI1JcQG7d++6yVuE2jQvb2h5 rULmuHWsldm83UCGd6sANPgtdYWOW5DxsmZAiiib2bJM3IHMrhHGDSot9qBu3HfCuZH+2iF dCQ3xaOroBfb/G+Kon8xgtVwXrpWDfQ0Qq8/XAfV3V3dergJKc2fY0ZQ8gvOlVMXoloVHVO nUJ4Mf7CfD/nmzvlrR18w== X-UI-Out-Filterresults: notjunk:1; V01:K0:/pdoXREMXJM=:k1UUhfNNCt/VYLEhllfxPV /PpHQ/GCqEX6X5ZI0NzSBnNvi9PVJFMsirJFezViEWncYLcyzOQHJwg+2Rse7CWF9wKheE3OI mC2scHNmsoVpJDh/qWF8kx/EHYBvp7SdqnuKGU4bR40YQaj9VkXEUAOQX5lR2iz7pG9Y8OvUr OJtrXvGTAVT5Jj2gfe49U6GA8Vk7cq2IsFjaj/wYIClaBWRzGWQEt5gKo56YuMN8dRZHzpNnJ umJrS/V8a3Id90X3Hf1AO7Sd0IaeVR5CtMx/xHNw4bHr7+vzP7VgF6aTM/ENjE6A1ScYpd56U 2hSBLZzzmqcBApUJvMi5RIKWijbAt72Sk9Sz6KQ2Q2rT6f8TR6LCM5xzCUiC0mjRssbXrraEZ S8q3NKkNotzgAlwbHMZTfRvrdUW4rft5h5yj/O41hTIHyj0ylXi0fkXCChcAp5GcXnz/otTaV tOAQm3iMSjdqwXXKc5wjdEyXk9kUwC9YqJnC/g+t0sHJkF+H8toCdKR1WJ0GUN3pdG1HCAQ6R x2VQCpid0LwWV2E3Ol9eN+L6oUafTnzN4Hhr2ASVuHLkXhsr2lgtvbtQSDULJNj48i45gPX2U hV7ri10ISYSnsXM4PEjyWFgtiHEJHi4lZERciqxqzqFjuSc08LI66sfOouhd3FqNeIPkXqez8 QW4FcpJG3dZpCpK3tZ2ujcLe5ZaOj/yp9X9dIVnM5tRiwSaJPp3M1FmRCtUpwjZ8oug4= Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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] The returned DMA address is later passed on to a function that takes a phys_addr_t, so it's clearly wrong to use the DMA mapping interface here: the memory may be uncached, or the address may be completely wrong if there is an IOMMU connected to the device. My interpretation is that using dmam_alloc_coherent() had two purposes: a) get a chunk of consecutive memory that may be larger than the limit for kmalloc() b) use the devres infrastructure to simplify the unwinding in the error case. I think ideally we'd use a devres-based version of alloc_pages_exact() here, but since that doesn't exist, let's use devm_get_free_pages() instead. This wastes a little memory as the size gets rounded up to a power of two, but is otherwise harmless. If we want to save memory here, calling devm_free_pages() to release the memory once it is no longer needed is probably better anyway. Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Arnd Bergmann --- The same problem exists in the drm driver, as of commit 7c65817e6d38 ("drm/msm: gpu: Enable zap shader for A5XX"), and I submitted the same patch for that already. --- drivers/media/platform/qcom/venus/firmware.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c index 1b1a4f355918..76edb9f60311 100644 --- a/drivers/media/platform/qcom/venus/firmware.c +++ b/drivers/media/platform/qcom/venus/firmware.c @@ -60,11 +60,13 @@ int venus_boot(struct device *parent, struct device *fw_dev, const char *fwname) mem_size = VENUS_FW_MEM_SIZE; - mem_va = dmam_alloc_coherent(fw_dev, mem_size, &mem_phys, GFP_KERNEL); + mem_va = (void *)devm_get_free_pages(parent, GFP_KERNEL, + get_order(mem_size)); if (!mem_va) { ret = -ENOMEM; goto err_unreg_device; } + mem_phys = virt_to_phys(mem_va); ret = request_firmware(&mdt, fwname, fw_dev); if (ret < 0)