From patchwork Tue Mar 19 02:22:08 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Souptick Joarder X-Patchwork-Id: 10859023 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 505416C2 for ; Tue, 19 Mar 2019 08:12:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 357D428785 for ; Tue, 19 Mar 2019 08:12:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 27CE0295BF; Tue, 19 Mar 2019 08:12:54 +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=-5.2 required=2.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D1F8E28785 for ; Tue, 19 Mar 2019 08:12:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1BA95899EA; Tue, 19 Mar 2019 08:12:49 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) by gabe.freedesktop.org (Postfix) with ESMTPS id E7DFB89740 for ; Tue, 19 Mar 2019 02:17:35 +0000 (UTC) Received: by mail-pf1-x441.google.com with SMTP id c8so5935214pfd.10 for ; Mon, 18 Mar 2019 19:17:35 -0700 (PDT) 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=RXoJztkr5KEPIR8CudilQKpUznGN5Xi7fOy8VvvMhtjNx06DChKZe6PH9/S8dAXyx5 Wn8XKOg9X+BXwRmiiS0O8Nv2vzw6sP/FmuPTS5AdPAIYuriG/CBRqc7Y8SZQIjvyPyt8 RSONrxx1SsQRK1Pqkas1ykZ/SsJTYUODt7Wavgq0gnCiE7kwqfYYgSIy8uGHMV7dscBV E8iuNg6RdSkZ7xE9pc1Z8DIIRJFGvl+wthtCKhxGKZeDxgov7uKVEGGuNx5ZHiMv8AGf aeksZK+WkrhH7NsQU3nOB2qeqSfCHP8XeiwikiVL+ONoMbLr//NCai+ARtWsuAfjbQ6N mHPw== X-Gm-Message-State: APjAAAUr2rk+wA7KCLhlGw7fVUdgEcafiheQpaLcu5zos2RHpvokwrfI egATHB7MBpRcUCDOmX7E+XY= 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-Mailman-Approved-At: Tue, 19 Mar 2019 08:12:25 +0000 X-Mailman-Original-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-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development 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 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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(-)