From mboxrd@z Thu Jan 1 00:00:00 1970 From: Souptick Joarder Subject: [RESEND PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API Date: Tue, 19 Mar 2019 07:52:08 +0530 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org To: akpm@linux-foundation.org, willy@infradead.org, mhocko@suse.com, kirill.shutemov@linux.intel.com, vbabka@suse.cz, riel@surriel.com, sfr@canb.auug.org.au, rppt@linux.vnet.ibm.com, peterz@infradead.org, linux@armlinux.org.uk, robin.murphy@arm.com, iamjoonsoo.kim@lge.com, treding@nvidia.com, keescook@chromium.org, m.szyprowski@samsung.com, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com, heiko@sntech.de, airlied@linux.ie, oleksandr_andrushchenko@epam.com, joro@8bytes.org, pawel@osciak.com, kyungmin.park@samsung.com, mchehab@kernel.org, boris.ostrovsky@oracle.com, jgross@suse.com Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux1394-devel@lists.sourceforge.net, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, xen-devel@lists.xen.org, iommu@lists.linux-foundation.org, linux-media@vger.kernel.org List-Id: iommu@lists.linux-foundation.org Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_map_pages() is the API which could be used to map kernel memory/pages in drivers which has considered vm_pgoff. vm_map_pages_zero() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_map_pages_zero() to behave according to the normal vm_pgoff offsetting simply by removing the _zero suffix on the function name and if that causes regressions, it gives us an easy way to revert. Tested on Rockchip hardware and display is working fine, including talking to Lima via prime. v1 -> v2: Few Reviewed-by. Updated the change log in [8/9] In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer, not as a in-buffer offset by design and it always want to mmap a whole buffer from its beginning. Added additional changes after discussing with Marek and vm_map_pages() could be used instead of vm_map_pages_zero(). v2 -> v3: Corrected the documentation as per review comment. As suggested in v2, renaming the interfaces to - *vm_insert_range() -> vm_map_pages()* and *vm_insert_range_buggy() -> vm_map_pages_zero()*. As the interface is renamed, modified the code accordingly, updated the change logs and modified the subject lines to use the new interfaces. There is no other change apart from renaming and using the new interface. Patch[1/9] & [4/9], Tested on Rockchip hardware. v3 -> v4: Fixed build warnings on patch [8/9] reported by kbuild test robot. Souptick Joarder (9): mm: Introduce new vm_map_pages() and vm_map_pages_zero() API arm: mm: dma-mapping: Convert to use vm_map_pages() drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero() drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages() drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages() iommu/dma-iommu.c: Convert to use vm_map_pages() videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages() xen/gntdev.c: Convert to use vm_map_pages() xen/privcmd-buf.c: Convert to use vm_map_pages_zero() arch/arm/mm/dma-mapping.c | 22 ++---- drivers/firewire/core-iso.c | 15 +--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 +---- drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-core.c | 7 ++ .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++---- drivers/xen/gntdev.c | 11 ++- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h | 4 ++ mm/memory.c | 81 ++++++++++++++++++++++ mm/nommu.c | 14 ++++ 13 files changed, 134 insertions(+), 103 deletions(-) -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96F1DC282DA for ; Tue, 16 Apr 2019 11:46:39 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5EC7C20821 for ; Tue, 16 Apr 2019 11:46:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="p49+FH8w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5EC7C20821 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 0FA23FEA; Tue, 16 Apr 2019 11:46:39 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3D9D2FE9 for ; Tue, 16 Apr 2019 11:46:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33F5F1C0 for ; Tue, 16 Apr 2019 11:46:37 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id w25so10277221pfi.9 for ; Tue, 16 Apr 2019 04:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=+DR3+vlSbSxZmlBQUDjdm+W5hcNMX8iBKfyCHlGcd98=; b=p49+FH8wefNN/TFhm0musz8K67UGp4XqQ68M2G0tG6gO1vJGpXZ3Z3NHiJenPGxaA2 Yd8ylPhe8XcATRkuSkHwuDLu39aepT7soVRT9pyel9vIQNihWW/ZcUGm0smQEsjTCn2D FyBo3nU67Z7Tvs7bPLA+GVeXAe2VMsxlFRJSQ/ByUa+chNz2i8h036z7Bc11Y+wFAjmF ld3LGMMZrtjiJbO/AdH1l1e89HLwIAGdatLHVeXSAvcAG6MVV5/QSVxVMzhvae0OLT6U LcVMaTmvXS0soKFNCnMoE5ptynqYlYvKH/Rb2zwD82IeS2SIaaKHOxRXebFN+0ct9Usy wj6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=+DR3+vlSbSxZmlBQUDjdm+W5hcNMX8iBKfyCHlGcd98=; b=EGFzSpeXFLRH/u76Vj8DFHqPFr9QxKqWwhBnbxVJDI4ZzlHfIOc9Cufsax6OAerBiP aSYro4XinsRwomLJhp5fKW5Qvom36IiYcXknp8eOXn+FNoa/Kx8KyHfelF5Y9SZ20l3F T8gnw1cvUbwaMtRjXv3x0f36kpaulAJVRefHQSCuqkgH+p407Zz9XvmFm1QAz/PCJBzi JdytTxynYpVws/Krcn/VGsYdwCfTmGWXF2LXby0vgQoxP1TJYnrDOiUpF9GFAh5uOSOc 3rlZPaGBQFqdUM4LOt+3rQs30DYS1UzsFM33VK8CE4h48/o33rFHFHA2AAjez++v1OlT KAHw== X-Gm-Message-State: APjAAAXuP/HxqRDQ60mkfSUMVvzIheOYCX2aLkjJ15b+j4NPP6JAheGx 7TosU7CpRnPnYyqkSJUiNkE= X-Google-Smtp-Source: APXvYqwcEwxacabFKCduxFjnVQjDbc16O98VQyj0wkD2blUxPLseoQlu9WxBt7zSdrSXH5UhKAygqw== X-Received: by 2002:a63:6fcf:: with SMTP id k198mr75605186pgc.158.1555415195795; Tue, 16 Apr 2019 04:46:35 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC.domain.name ([49.207.50.11]) by smtp.gmail.com with ESMTPSA id p6sm55942835pfd.122.2019.04.16.04.46.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Apr 2019 04:46:34 -0700 (PDT) From: Souptick Joarder To: akpm@linux-foundation.org, willy@infradead.org, mhocko@suse.com, kirill.shutemov@linux.intel.com, vbabka@suse.cz, riel@surriel.com, sfr@canb.auug.org.au, rppt@linux.vnet.ibm.com, peterz@infradead.org, linux@armlinux.org.uk, robin.murphy@arm.com, iamjoonsoo.kim@lge.com, treding@nvidia.com, keescook@chromium.org, m.szyprowski@samsung.com, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com, heiko@sntech.de, airlied@linux.ie, oleksandr_andrushchenko@epam.com, joro@8bytes.org, pawel@osciak.com, kyungmin.park@samsung.com, mchehab@kernel.org, boris.ostrovsky@oracle.com, jgross@suse.com Subject: [REBASE PATCH v5 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API Date: Tue, 16 Apr 2019 17:19:41 +0530 Message-Id: X-Mailer: git-send-email 1.9.1 Cc: linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xen.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, Souptick Joarder , linux1394-devel@lists.sourceforge.net, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org Message-ID: <20190416114941.AyTSXOCh8hrycntj9vKfQmVxQCIevtptUQz7pWE7Jck@z> Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_map_pages() is the API which could be used to map kernel memory/pages in drivers which has considered vm_pgoff. vm_map_pages_zero() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_map_pages_zero() to behave according to the normal vm_pgoff offsetting simply by removing the _zero suffix on the function name and if that causes regressions, it gives us an easy way to revert. Tested on Rockchip hardware and display is working fine, including talking to Lima via prime. v1 -> v2: Few Reviewed-by. Updated the change log in [8/9] In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer, not as a in-buffer offset by design and it always want to mmap a whole buffer from its beginning. Added additional changes after discussing with Marek and vm_map_pages() could be used instead of vm_map_pages_zero(). v2 -> v3: Corrected the documentation as per review comment. As suggested in v2, renaming the interfaces to - *vm_insert_range() -> vm_map_pages()* and *vm_insert_range_buggy() -> vm_map_pages_zero()*. As the interface is renamed, modified the code accordingly, updated the change logs and modified the subject lines to use the new interfaces. There is no other change apart from renaming and using the new interface. Patch[1/9] & [4/9], Tested on Rockchip hardware. v3 -> v4: Fixed build warnings on patch [8/9] reported by kbuild test robot. v4 -> v5: Rebase the code to 5.1-rc5. Souptick Joarder (9): mm: Introduce new vm_map_pages() and vm_map_pages_zero() API arm: mm: dma-mapping: Convert to use vm_map_pages() drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero() drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages() drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages() iommu/dma-iommu.c: Convert to use vm_map_pages() videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages() xen/gntdev.c: Convert to use vm_map_pages() xen/privcmd-buf.c: Convert to use vm_map_pages_zero() arch/arm/mm/dma-mapping.c | 22 ++---- drivers/firewire/core-iso.c | 15 +--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 +---- drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-core.c | 7 ++ .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++---- drivers/xen/gntdev.c | 11 ++- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h | 4 ++ mm/memory.c | 81 ++++++++++++++++++++++ mm/nommu.c | 14 ++++ 13 files changed, 134 insertions(+), 103 deletions(-) -- 1.9.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7576DC43381 for ; Tue, 19 Mar 2019 02:17:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4655920700 for ; Tue, 19 Mar 2019 02:17:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AVh1i6oZ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TFLM18uv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4655920700 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Subject:To:From :Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=OYIdWn9Df+MyZfujvIwAkRLBDaUwpgSwiAlne0bEaBk=; b=AVh1i6oZQkKnWa H713BS8PtMJnLhRLwuuuQopph8X5fHmv0ULmtxy1PTB3oKo1tYnpe3i/JRx+6mm1pBWwdE5VkWMj5 /7JHUd6Sjpzdaa5Lc9N6GF6XbrH1X/ILnKlFWEOAoweantDXDEVlJZD74CW9m1Q1fuOABfLwDxl1K pHjufjJ6nzsa47qOPKBFuSYrTfxeAaIYeEUkpCI+MGfPFdr5aw/aj/mkA4ehDNirNe4J8lKnXuHXV JfCojFIS18ZTwCY4SWF56zCUEZbvzUE/nltxnmp84shpDmnR16z3BtwmmGOe932EllpGl5SYSlI3w Qv3DxRNYzu0UtnqCLQGw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h64Jx-0002Kc-Kt; Tue, 19 Mar 2019 02:17:41 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h64Js-0002JW-Nx; Tue, 19 Mar 2019 02:17:39 +0000 Received: by mail-pg1-x542.google.com with SMTP id q206so12734995pgq.4; Mon, 18 Mar 2019 19:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=ybJ6FRmizCH+Ysla/KYM0KU4CJcaZTaDUg0Dc25IXgc=; b=TFLM18uvjK4LjZZrue8Bkuk/wUFod454FjOxaVkU6fvE8wKqIIyWS9uODPgL0b6/vX 5tBh0Q/Xv8xN8YraSLbsAoX/qx9KBTuUWtlAiZCC9XFHCWq13RFni5tqM7iEkFUg5JQD 7dxD9m/GNXj/wsPUBEDK9fUxTfOnTKg3AKutKQrbzjD+c/244ovKdJSnQf5qxs7N+xgQ +xQPNs1yG3Md8O/rSUGYjD7ppbTFVRex7asYga3WHKjxFSWKynOL6Is/7zNQAep6NJr8 Lu6SV6uWaG9wLs2QQHz9r2GdPg+2XXKF6nLfc1jePY8hEXmInBOg/0Er7mP2SCb6/iYz E7NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=ybJ6FRmizCH+Ysla/KYM0KU4CJcaZTaDUg0Dc25IXgc=; b=tL54yUHIg6UoTh1Zdu1XT6fz5EXfF4FY2TYRdfpKxwyf38SH2crvfsconi+To1Ne0+ kKSFdPW7Pxn/uY+To3UjfJhz9MznISYEawGNdp+n+ZhPPZ0v4LVg/DK7iR24cDfrWkYT UYs0u08AmbbfyOJYPmziTjPVEwt5tdGiJKpMEcYCiyL7UIEDSln+rl2efVp32jUacYlq BHjMTJcPOXwdV5TUiQa9RZyMvQ9AV1+o0QnON2S5c8ubdTHVszvb9C+GRILExd1uL8D2 U/KwuTzTdBlj8VmDvItstgDGJPSxd3+uKX/0W6Clc4B4QsRHDqB7GA0GVb4UnvIrQaIc ABDA== X-Gm-Message-State: APjAAAWle3opBuIcPpNWx+oyBXNIkrSxA+0yrs6uzzFl9uHVGjvxZnhn dGKkLHpnB2KPo3xqFNtTBnU= X-Google-Smtp-Source: APXvYqwDKhWRiy9D5bbmTHs3dACkLmoUcPuxvlF0bXWwoogDZxk/mizWJx+ooPXJSq6wCKPJbrPmBw== X-Received: by 2002:a65:4608:: with SMTP id v8mr21025819pgq.9.1552961855318; Mon, 18 Mar 2019 19:17:35 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC ([106.51.22.39]) by smtp.gmail.com with ESMTPSA id w68sm1506149pfb.176.2019.03.18.19.17.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Mar 2019 19:17:33 -0700 (PDT) Date: Tue, 19 Mar 2019 07:52:08 +0530 From: Souptick Joarder To: akpm@linux-foundation.org, willy@infradead.org, mhocko@suse.com, kirill.shutemov@linux.intel.com, vbabka@suse.cz, riel@surriel.com, sfr@canb.auug.org.au, rppt@linux.vnet.ibm.com, peterz@infradead.org, linux@armlinux.org.uk, robin.murphy@arm.com, iamjoonsoo.kim@lge.com, treding@nvidia.com, keescook@chromium.org, m.szyprowski@samsung.com, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com, heiko@sntech.de, airlied@linux.ie, oleksandr_andrushchenko@epam.com, joro@8bytes.org, pawel@osciak.com, kyungmin.park@samsung.com, mchehab@kernel.org, boris.ostrovsky@oracle.com, jgross@suse.com Subject: [RESEND PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API Message-ID: MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190318_191736_805120_C88084A0 X-CRM114-Status: GOOD ( 12.10 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xen.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, linux1394-devel@lists.sourceforge.net, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_map_pages() is the API which could be used to map kernel memory/pages in drivers which has considered vm_pgoff. vm_map_pages_zero() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_map_pages_zero() to behave according to the normal vm_pgoff offsetting simply by removing the _zero suffix on the function name and if that causes regressions, it gives us an easy way to revert. Tested on Rockchip hardware and display is working fine, including talking to Lima via prime. v1 -> v2: Few Reviewed-by. Updated the change log in [8/9] In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer, not as a in-buffer offset by design and it always want to mmap a whole buffer from its beginning. Added additional changes after discussing with Marek and vm_map_pages() could be used instead of vm_map_pages_zero(). v2 -> v3: Corrected the documentation as per review comment. As suggested in v2, renaming the interfaces to - *vm_insert_range() -> vm_map_pages()* and *vm_insert_range_buggy() -> vm_map_pages_zero()*. As the interface is renamed, modified the code accordingly, updated the change logs and modified the subject lines to use the new interfaces. There is no other change apart from renaming and using the new interface. Patch[1/9] & [4/9], Tested on Rockchip hardware. v3 -> v4: Fixed build warnings on patch [8/9] reported by kbuild test robot. Souptick Joarder (9): mm: Introduce new vm_map_pages() and vm_map_pages_zero() API arm: mm: dma-mapping: Convert to use vm_map_pages() drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero() drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages() drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages() iommu/dma-iommu.c: Convert to use vm_map_pages() videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages() xen/gntdev.c: Convert to use vm_map_pages() xen/privcmd-buf.c: Convert to use vm_map_pages_zero() arch/arm/mm/dma-mapping.c | 22 ++---- drivers/firewire/core-iso.c | 15 +--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 +---- drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-core.c | 7 ++ .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++---- drivers/xen/gntdev.c | 11 ++- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h | 4 ++ mm/memory.c | 81 ++++++++++++++++++++++ mm/nommu.c | 14 ++++ 13 files changed, 134 insertions(+), 103 deletions(-) -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59D5EC10F13 for ; Tue, 16 Apr 2019 11:46:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2BFBC20868 for ; Tue, 16 Apr 2019 11:46:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="LUpIp9MF"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="p49+FH8w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BFBC20868 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=qQo25QCl9n+3D3XRx1jbXNSLnc55OFeAVnShgYCEFGA=; b=LUp Ip9MFmO0rUgOHDJf66kT8qVSeYUzSlhlekmjFG61X6s/ut9ajjZl1ZDENg7htO3PDLhU83r2HxMRN 5kPRlWboA/pui7DzYMHLk9KhFGoMqpRK42V3IBVxJeNSU5pwmiKvZhNdzd31OBDdEekPuZRz3Hi3B YS+zM9mDEEzM7A9t6WY2DLO8FUfA6cftGhxfggR86YFt12eReVqxzDHd4MQZap5LGFKcu+ZlK8b7c 4ynmBgzTefbo0FKM/E6G6RaN/Y0IK7eY6XCFd79CgZSeoActhHWW1xFJOGb8PH05lInxK6vJug/oX AteC4E4MFo5mZlS24ywxFi1tjk0DU9g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGMXw-00070d-Qt; Tue, 16 Apr 2019 11:46:40 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGMXu-000708-0O; Tue, 16 Apr 2019 11:46:39 +0000 Received: by mail-pg1-x542.google.com with SMTP id p6so10215765pgh.9; Tue, 16 Apr 2019 04:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=+DR3+vlSbSxZmlBQUDjdm+W5hcNMX8iBKfyCHlGcd98=; b=p49+FH8wefNN/TFhm0musz8K67UGp4XqQ68M2G0tG6gO1vJGpXZ3Z3NHiJenPGxaA2 Yd8ylPhe8XcATRkuSkHwuDLu39aepT7soVRT9pyel9vIQNihWW/ZcUGm0smQEsjTCn2D FyBo3nU67Z7Tvs7bPLA+GVeXAe2VMsxlFRJSQ/ByUa+chNz2i8h036z7Bc11Y+wFAjmF ld3LGMMZrtjiJbO/AdH1l1e89HLwIAGdatLHVeXSAvcAG6MVV5/QSVxVMzhvae0OLT6U LcVMaTmvXS0soKFNCnMoE5ptynqYlYvKH/Rb2zwD82IeS2SIaaKHOxRXebFN+0ct9Usy wj6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=+DR3+vlSbSxZmlBQUDjdm+W5hcNMX8iBKfyCHlGcd98=; b=iYo7WKzmLHSb2/q9foH1RN8FiG2AAbg0gOccP6J6P2FBoTAoMleqPHj/52uN/tSE5n tRQd9RvhBLzTPQcDG1uLtirkkrufqxE8D1h3lybwunySPHcu4pcBvfh/o6ilThelferX eUUbA+saTS5oL1bOW5bR4k8Y3NxPY5pHzgbP5clkIjziULZAeMt9eHv2rvH6ZO0H0Z2U 9rC9yyYDAlAB8aRCcTLpNh9EZknvbKNBv+FdvibbdjAzzVYeK9P4NakZxrnv/sobRZHo HHHEcYAtsYe4g/4agxEwdng61otbGUWJ4CiJMFwHItzNdX6yG0a+c746jNdDpgmaQiHW fjpw== X-Gm-Message-State: APjAAAXfhRQ75D+swHVoPfS1pWI5KpquxguwjjD4wK6jMUcZyf55Ngrf 4ip69Ib1SBjsRUiH3KRc/zg= X-Google-Smtp-Source: APXvYqwcEwxacabFKCduxFjnVQjDbc16O98VQyj0wkD2blUxPLseoQlu9WxBt7zSdrSXH5UhKAygqw== X-Received: by 2002:a63:6fcf:: with SMTP id k198mr75605186pgc.158.1555415195795; Tue, 16 Apr 2019 04:46:35 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC.domain.name ([49.207.50.11]) by smtp.gmail.com with ESMTPSA id p6sm55942835pfd.122.2019.04.16.04.46.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Apr 2019 04:46:34 -0700 (PDT) From: Souptick Joarder To: akpm@linux-foundation.org, willy@infradead.org, mhocko@suse.com, kirill.shutemov@linux.intel.com, vbabka@suse.cz, riel@surriel.com, sfr@canb.auug.org.au, rppt@linux.vnet.ibm.com, peterz@infradead.org, linux@armlinux.org.uk, robin.murphy@arm.com, iamjoonsoo.kim@lge.com, treding@nvidia.com, keescook@chromium.org, m.szyprowski@samsung.com, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com, heiko@sntech.de, airlied@linux.ie, oleksandr_andrushchenko@epam.com, joro@8bytes.org, pawel@osciak.com, kyungmin.park@samsung.com, mchehab@kernel.org, boris.ostrovsky@oracle.com, jgross@suse.com Subject: [REBASE PATCH v5 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API Date: Tue, 16 Apr 2019 17:19:41 +0530 Message-Id: X-Mailer: git-send-email 1.9.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190416_044638_069063_D4CCE0F5 X-CRM114-Status: GOOD ( 11.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xen.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, Souptick Joarder , linux1394-devel@lists.sourceforge.net, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Message-ID: <20190416114941.P6fXsk_uBgHhjmCjcgGenHB0a3SKHyqjHRWn7oYhcCE@z> Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_map_pages() is the API which could be used to map kernel memory/pages in drivers which has considered vm_pgoff. vm_map_pages_zero() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_map_pages_zero() to behave according to the normal vm_pgoff offsetting simply by removing the _zero suffix on the function name and if that causes regressions, it gives us an easy way to revert. Tested on Rockchip hardware and display is working fine, including talking to Lima via prime. v1 -> v2: Few Reviewed-by. Updated the change log in [8/9] In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer, not as a in-buffer offset by design and it always want to mmap a whole buffer from its beginning. Added additional changes after discussing with Marek and vm_map_pages() could be used instead of vm_map_pages_zero(). v2 -> v3: Corrected the documentation as per review comment. As suggested in v2, renaming the interfaces to - *vm_insert_range() -> vm_map_pages()* and *vm_insert_range_buggy() -> vm_map_pages_zero()*. As the interface is renamed, modified the code accordingly, updated the change logs and modified the subject lines to use the new interfaces. There is no other change apart from renaming and using the new interface. Patch[1/9] & [4/9], Tested on Rockchip hardware. v3 -> v4: Fixed build warnings on patch [8/9] reported by kbuild test robot. v4 -> v5: Rebase the code to 5.1-rc5. Souptick Joarder (9): mm: Introduce new vm_map_pages() and vm_map_pages_zero() API arm: mm: dma-mapping: Convert to use vm_map_pages() drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero() drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages() drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages() iommu/dma-iommu.c: Convert to use vm_map_pages() videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages() xen/gntdev.c: Convert to use vm_map_pages() xen/privcmd-buf.c: Convert to use vm_map_pages_zero() arch/arm/mm/dma-mapping.c | 22 ++---- drivers/firewire/core-iso.c | 15 +--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 +---- drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-core.c | 7 ++ .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++---- drivers/xen/gntdev.c | 11 ++- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h | 4 ++ mm/memory.c | 81 ++++++++++++++++++++++ mm/nommu.c | 14 ++++ 13 files changed, 134 insertions(+), 103 deletions(-) -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF62CC10F13 for ; Tue, 16 Apr 2019 11:46:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B86720821 for ; Tue, 16 Apr 2019 11:46:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="p49+FH8w" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726857AbfDPLqi (ORCPT ); Tue, 16 Apr 2019 07:46:38 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:37597 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725787AbfDPLqh (ORCPT ); Tue, 16 Apr 2019 07:46:37 -0400 Received: by mail-pf1-f195.google.com with SMTP id 8so10295133pfr.4; Tue, 16 Apr 2019 04:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=+DR3+vlSbSxZmlBQUDjdm+W5hcNMX8iBKfyCHlGcd98=; b=p49+FH8wefNN/TFhm0musz8K67UGp4XqQ68M2G0tG6gO1vJGpXZ3Z3NHiJenPGxaA2 Yd8ylPhe8XcATRkuSkHwuDLu39aepT7soVRT9pyel9vIQNihWW/ZcUGm0smQEsjTCn2D FyBo3nU67Z7Tvs7bPLA+GVeXAe2VMsxlFRJSQ/ByUa+chNz2i8h036z7Bc11Y+wFAjmF ld3LGMMZrtjiJbO/AdH1l1e89HLwIAGdatLHVeXSAvcAG6MVV5/QSVxVMzhvae0OLT6U LcVMaTmvXS0soKFNCnMoE5ptynqYlYvKH/Rb2zwD82IeS2SIaaKHOxRXebFN+0ct9Usy wj6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=+DR3+vlSbSxZmlBQUDjdm+W5hcNMX8iBKfyCHlGcd98=; b=GLz7AOY5cC8uEvTUknn7D+zNo5CBnQyHIiVjXWYKpbL2KbiaYlqIilaIylfX4hH39W 9I4B+Fv1IfPAExhND+ksVS8NNjlQSn8cjxo5O2XTNS6j4/XkgcJwarAaMkBPQoCIcpug cfEq40S2WqOrBCPd7LXpWBrL1hrziHWUYXGi6uowOrpvL0SvNcW/UithHJm0S8X1TWuh NhKyRInXhM8Pja6CeDDYyNY7rG+x/GzXK8OwbjMIORoSMNXWRrdX9BHyF7+yaQyzF8iH bxDmbSHPfDVsi9/t8VO7ix9wTlNQu4bqdLhRaevF/PbO9Jvrc6Cf8mlKRndlyTeXHD1C URjw== X-Gm-Message-State: APjAAAV9dlh0CmRhBvNjVRWkaYnnVnq3y74mpVXm9BM8w6r7dzx7jp/v P0fX8/DR/FziyNXzoTOMasc= X-Google-Smtp-Source: APXvYqwcEwxacabFKCduxFjnVQjDbc16O98VQyj0wkD2blUxPLseoQlu9WxBt7zSdrSXH5UhKAygqw== X-Received: by 2002:a63:6fcf:: with SMTP id k198mr75605186pgc.158.1555415195795; Tue, 16 Apr 2019 04:46:35 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC.domain.name ([49.207.50.11]) by smtp.gmail.com with ESMTPSA id p6sm55942835pfd.122.2019.04.16.04.46.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Apr 2019 04:46:34 -0700 (PDT) From: Souptick Joarder To: akpm@linux-foundation.org, willy@infradead.org, mhocko@suse.com, kirill.shutemov@linux.intel.com, vbabka@suse.cz, riel@surriel.com, sfr@canb.auug.org.au, rppt@linux.vnet.ibm.com, peterz@infradead.org, linux@armlinux.org.uk, robin.murphy@arm.com, iamjoonsoo.kim@lge.com, treding@nvidia.com, keescook@chromium.org, m.szyprowski@samsung.com, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com, heiko@sntech.de, airlied@linux.ie, oleksandr_andrushchenko@epam.com, joro@8bytes.org, pawel@osciak.com, kyungmin.park@samsung.com, mchehab@kernel.org, boris.ostrovsky@oracle.com, jgross@suse.com Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux1394-devel@lists.sourceforge.net, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, xen-devel@lists.xen.org, iommu@lists.linux-foundation.org, linux-media@vger.kernel.org, Souptick Joarder Subject: [REBASE PATCH v5 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API Date: Tue, 16 Apr 2019 17:19:41 +0530 Message-Id: X-Mailer: git-send-email 1.9.1 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Message-ID: <20190416114941.YXEavjL4bwOc4Ur0Ye6DkApDfDqZiH4nUUpt6sjMs2U@z> Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_map_pages() is the API which could be used to map kernel memory/pages in drivers which has considered vm_pgoff. vm_map_pages_zero() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_map_pages_zero() to behave according to the normal vm_pgoff offsetting simply by removing the _zero suffix on the function name and if that causes regressions, it gives us an easy way to revert. Tested on Rockchip hardware and display is working fine, including talking to Lima via prime. v1 -> v2: Few Reviewed-by. Updated the change log in [8/9] In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer, not as a in-buffer offset by design and it always want to mmap a whole buffer from its beginning. Added additional changes after discussing with Marek and vm_map_pages() could be used instead of vm_map_pages_zero(). v2 -> v3: Corrected the documentation as per review comment. As suggested in v2, renaming the interfaces to - *vm_insert_range() -> vm_map_pages()* and *vm_insert_range_buggy() -> vm_map_pages_zero()*. As the interface is renamed, modified the code accordingly, updated the change logs and modified the subject lines to use the new interfaces. There is no other change apart from renaming and using the new interface. Patch[1/9] & [4/9], Tested on Rockchip hardware. v3 -> v4: Fixed build warnings on patch [8/9] reported by kbuild test robot. v4 -> v5: Rebase the code to 5.1-rc5. Souptick Joarder (9): mm: Introduce new vm_map_pages() and vm_map_pages_zero() API arm: mm: dma-mapping: Convert to use vm_map_pages() drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero() drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages() drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages() iommu/dma-iommu.c: Convert to use vm_map_pages() videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages() xen/gntdev.c: Convert to use vm_map_pages() xen/privcmd-buf.c: Convert to use vm_map_pages_zero() arch/arm/mm/dma-mapping.c | 22 ++---- drivers/firewire/core-iso.c | 15 +--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 +---- drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-core.c | 7 ++ .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++---- drivers/xen/gntdev.c | 11 ++- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h | 4 ++ mm/memory.c | 81 ++++++++++++++++++++++ mm/nommu.c | 14 ++++ 13 files changed, 134 insertions(+), 103 deletions(-) -- 1.9.1