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=-0.8 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 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 DC47DC10F05 for ; Mon, 1 Apr 2019 05:26:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A8E8520896 for ; Mon, 1 Apr 2019 05:26:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GSMfenxK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725992AbfDAF0R (ORCPT ); Mon, 1 Apr 2019 01:26:17 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:33076 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725771AbfDAF0R (ORCPT ); Mon, 1 Apr 2019 01:26:17 -0400 Received: by mail-lj1-f195.google.com with SMTP id f23so6888317ljc.0; Sun, 31 Mar 2019 22:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bIVPtU/6p+7QNpj3MFhNlKtXKn4Iq452QD8npHz+GbM=; b=GSMfenxKmemWULo792hWOfy/Tlep6WqOO9L/jJR2e5gnB7dWER5LBXqu5dxALEN2tm inGtCLH8AGdUkulnrqLgYPflDKpirpF5+cHZAQ3XbB15xMH3nX22akA/pJVbyaAKZX85 xvv8tvFX+ASSgFa7HJDqm0nA/zF6CKx+YjZJOYw4CYVXVz6IXPrmsRrnCO/I4IuXa9Ls vqGoW3074MgmcMmyS+MuUEhIbWdCqV8WxAafH2eVkIAnmnHDsOkbNTf28jHZj7mSs13i Yh6dW2t3w6dwsYv6iQ5J9TiAx/ermCxDUS4HhW8hxE8MVqmYyKd6GYwrESF9RaJ25eb+ l02w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bIVPtU/6p+7QNpj3MFhNlKtXKn4Iq452QD8npHz+GbM=; b=JiC6f2rsZ6sPHstWX5IIovHUXjtu9g6Ab5M35kSv3VsqH8YSR5hBD0Ko07rZOXT+64 dCpZ5lJPO32oB24UQpvbeLQI+sbLRYtVfdkXMXZWpDe56U9DqzXoVvZAVj4eQfi4OiQ0 Q1skwng24R50lRWcNwMDyI64OlapM2uoH3P3sX4WcQSXidZIOSYs0PID/XMTdnHLnLNX Okz4hBulezcn5h2gwDoGBw2XJYQN+i8NA0dodE7SxMYgE5aDD7k7DVDhMSFFviH6NW5I RoKLQbrIh0QR8RuqjdvHiaS2wy1fRS1xOlky8WUROluLCbMnTPAsPJIkZs9seRgylKTg xAvQ== X-Gm-Message-State: APjAAAXHiTtDIQL9xMPbWgmJkV+GACUiuN9s52eKL8y2nf6Zyz/rENHW Ce6qmwFkuuMecmZFfII1hzx1c60bzulhdehdKmU= X-Google-Smtp-Source: APXvYqzAIbEvWsJKCr8Si4qji6vpGtPpgJ9t/2hq0YVPrFKEma2+t934Gmkq9NVJTNcsivtQulGbZiMEOTK9cecCE6g= X-Received: by 2002:a2e:3e18:: with SMTP id l24mr23912301lja.68.1554096373899; Sun, 31 Mar 2019 22:26:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Souptick Joarder Date: Mon, 1 Apr 2019 10:56:02 +0530 Message-ID: Subject: Re: [RESEND PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API To: Andrew Morton , Matthew Wilcox , Michal Hocko , "Kirill A. Shutemov" , Vlastimil Babka , Rik van Riel , Stephen Rothwell , rppt@linux.vnet.ibm.com, Peter Zijlstra , Russell King - ARM Linux , robin.murphy@arm.com, iamjoonsoo.kim@lge.com, treding@nvidia.com, Kees Cook , Marek Szyprowski , stefanr@s5r6.in-berlin.de, hjc@rock-chips.com, Heiko Stuebner , airlied@linux.ie, oleksandr_andrushchenko@epam.com, joro@8bytes.org, pawel@osciak.com, Kyungmin Park , mchehab@kernel.org, Boris Ostrovsky , Juergen Gross Cc: linux-kernel@vger.kernel.org, Linux-MM , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Andrew, On Tue, Mar 19, 2019 at 7:47 AM Souptick Joarder wrote: > > 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() Is it fine to take these patches into mm tree for regression ? > > 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 >