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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 29C0FC433E1 for ; Wed, 19 Aug 2020 14:23:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F1B412076E for ; Wed, 19 Aug 2020 14:23:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="MwoQKU4R" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726560AbgHSOXA (ORCPT ); Wed, 19 Aug 2020 10:23:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728370AbgHSOWv (ORCPT ); Wed, 19 Aug 2020 10:22:51 -0400 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13874C061343 for ; Wed, 19 Aug 2020 07:22:51 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id m22so26466001eje.10 for ; Wed, 19 Aug 2020 07:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=MwoQKU4RRVGBwswghQT2kEA4PWtzNJ9PP0GlvGH+VtAzrSvBnEW2dUpr0fs6tqB36t NEatNz3nTo9Srl8JZAX9oVp9pc5TQLgcK+vTRNeNePaaHI1s5H4G84GiGqxdAJ9X51ZU 9RjLZl32ILMLyADH9W9JtyN4rfe/+nXKgJFvs= 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=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=lUTQo+aTLXmcZX7sT/9vuLVZ3RjGsKQC9JQlnO6zBKn4e4SUv49Qc3B1fbv8yFj44g kBVfJXLp7/NAXdf4Nu7NYydprvzUdESUu+eD3DiFLO2cAjTl4Z70k6OYjXWZk0ihWCng UcERvaoZJnbONnHc2cx4JfP5N/3t6IvHxf/YI4WfxAet9G2yW/BAwrx20v4HSHr6jZRX cUXK0T2/vAqFhoi2UscP7/fw1OeLhgV1iDCQSrCiu+YJfNsPMuYI+0Yu0ts+mXps4scD UJW+0rThScNhuuZTzk9tKfm3CRDdsxQWii5Td9mX6+305yIUEZ9T99/KXuY/Jmla0lss Y1Mg== X-Gm-Message-State: AOAM531nE/EX3x/a06LjEWTBNsKUmrigsG6LyebYWpG0XMuAbRED+Yn8 jNaSnqfH56Aj7GfQZeQn99kFwiF7i63Erg== X-Google-Smtp-Source: ABdhPJw+dmDexmn2cwriQUaO113Ef5fXcODHg0fymeph4phMJeYor/zuZXWLegHcLCXM97aEcHRcHg== X-Received: by 2002:a17:906:6a84:: with SMTP id p4mr26190492ejr.374.1597846969397; Wed, 19 Aug 2020 07:22:49 -0700 (PDT) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com. [209.85.221.42]) by smtp.gmail.com with ESMTPSA id c20sm18099980edy.40.2020.08.19.07.22.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 07:22:48 -0700 (PDT) Received: by mail-wr1-f42.google.com with SMTP id l2so21713364wrc.7 for ; Wed, 19 Aug 2020 07:22:47 -0700 (PDT) X-Received: by 2002:adf:ec45:: with SMTP id w5mr25495420wrn.415.1597846966201; Wed, 19 Aug 2020 07:22:46 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <62e4f4fc-c8a5-3ee8-c576-fe7178cb4356@arm.com> <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> In-Reply-To: <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> From: Tomasz Figa Date: Wed, 19 Aug 2020 16:22:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Robin Murphy Cc: Christoph Hellwig , alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, Linux Kernel Mailing List , "James E.J. Bottomley" , linux-mm@kvack.org, Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Kyungmin Park , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS" , Joerg Roedel , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , linux-mips@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote: > > On 2020-08-19 13:49, Tomasz Figa wrote: > > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: > >> > >> Hi Tomasz, > >> > >> On 2020-08-19 12:16, Tomasz Figa wrote: > >>> Hi Christoph, > >>> > >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: > >>>> > >>>> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, > >>> > >>> Could you explain what makes you think it's unused? It's a feature of > >>> the UAPI generally supported by the videobuf2 framework and relied on > >>> by Chromium OS to get any kind of reasonable performance when > >>> accessing V4L2 buffers in the userspace. > >>> > >>>> and causes > >>>> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >>>> unimplemented except on PARISC and some MIPS configs, and about to be > >>>> removed. > >>> > >>> It is implemented by the generic DMA mapping layer [1], which is used > >>> by a number of architectures including ARM64 and supposed to be used > >>> by new architectures going forward. > >> > >> AFAICS all that V4L2_FLAG_MEMORY_NON_CONSISTENT does is end up > >> controling whether DMA_ATTR_NON_CONSISTENT is added to vb2_queue::dma_attrs. > >> > >> Please can you point to where DMA_ATTR_NON_CONSISTENT does anything at > >> all on arm64? > >> > > > > With the default config it doesn't, but with > > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep > > the pgprot value as is, without enforcing coherence attributes. > > How active are the PA-RISC and MIPS ports of Chromium OS? Not active. We enable CONFIG_DMA_NONCOHERENT_CACHE_SYNC for ARM64, given the directions received back in April when discussing the noncoherent memory functionality on the mailing list in the thread I pointed out in my previous message and no clarification on why it is disabled for ARM64 in upstream, despite making several attempts to get some. > > Hacking CONFIG_DMA_NONCOHERENT_CACHE_SYNC into an architecture that > doesn't provide dma_cache_sync() is wrong, since at worst it may break > other drivers. If downstream is wildly misusing an API then so be it, > but it's hardly a strong basis for an upstream argument. I guess it means that we're wildly misusing the API, but it still does work. Could you explain how it could break other drivers? > > >> Also, I posit that videobuf2 is not actually relying on > >> DMA_ATTR_NON_CONSISTENT anyway, since it's clearly not using it properly: > >> > >> "By using this API, you are guaranteeing to the platform > >> that you have all the correct and necessary sync points for this memory > >> in the driver should it choose to return non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also always > been wrong per the API, regardless of the bodies of code that have > happened to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I pointed to, but that might of course be my misunderstanding. > i.e. this series - not encouraging mixing the existing APIs. It doesn't > seem impossible to implement a remapping version of this new > dma_alloc_pages() for IOMMU-backed ops if it's really warranted > (although at that point it seems like "non-coherent" vb2-dc starts to > have significant conceptual overlap with vb2-sg). No, there is no overlap between vb2-dc and vb2-sg. They differ on another level - the former is to be used by devices without scatter-gather or internal mapping capabilities and gives the driver a single DMA address for the whole buffer, regardless of whether it's IOVA-contiguous (for devices behind an IOMMU) or physically contiguous (for the others), while the latter gives the driver an sgtable, which of course may be DMA-contiguous internally, but doesn't have to and usually isn't. This model makes it possible to hide the SoC implementation details from particular drivers, since those are very often reused on many SoCs which differ in the availability of IOMMU, DMA addressing restrictions and so on. Best regards, Tomasz 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 69A6EC433E1 for ; Wed, 19 Aug 2020 14:22:55 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 3962420639 for ; Wed, 19 Aug 2020 14:22:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Tu1LbEX0"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="MwoQKU4R" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3962420639 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lvTBYV4Owej2L69VVMGzVxMJ6HqnmMS7xU7WbB+nK+Q=; b=Tu1LbEX0+GhciSrngehZ7gUPi xYkxGCRXn0TlypUhJHNIfzzjOAU9apcLtILWmTlRshvZxT/Bl0h5MH2xJZyaj5FWXMcLbZBcD9zn6 yFFZozOLqlSOjXHjKzVj7Vwyyu10GL3gGJ+z43TU0gfSAKeMcjcve3Fpg5t2CyXuWmv/xE7SHSHEH +3KCFO0n9RiKiIHWB2Rd8wduopDyBdBlE9rtJDD7EXVdoG9mryK8umFULryy64Ks04IwOrr316Q8N sk4cOra+lMxYmHvnIqiPUECJu3TuFMxeeBufX+ioHRiGZo1a8dfOUTz08uee2xRY7NGT9OaregG72 eDmMme8Rw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8OzL-0004sK-GM; Wed, 19 Aug 2020 14:22:51 +0000 Received: from mail-ej1-x641.google.com ([2a00:1450:4864:20::641]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8OzI-0004rl-Sk for linux-nvme@lists.infradead.org; Wed, 19 Aug 2020 14:22:49 +0000 Received: by mail-ej1-x641.google.com with SMTP id bo3so26471929ejb.11 for ; Wed, 19 Aug 2020 07:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=MwoQKU4RRVGBwswghQT2kEA4PWtzNJ9PP0GlvGH+VtAzrSvBnEW2dUpr0fs6tqB36t NEatNz3nTo9Srl8JZAX9oVp9pc5TQLgcK+vTRNeNePaaHI1s5H4G84GiGqxdAJ9X51ZU 9RjLZl32ILMLyADH9W9JtyN4rfe/+nXKgJFvs= 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=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=GUKw5FiTo64HAoG/4niRQYq5Ka4IZZ+Zx9sVNJ8xjKSAKr3XeKmzznd1TAVOj7wXzw 2btxwgnnIGeIGfkBSGSuqGD9/0geo9U1syBEBUs54pCTS+8BLhOrGKiyREM4ZZwQxsLj 54pwyWY3hIw1AqCrnmynnLtkWlgYB3q40ImreEwMHiCQTZNIxhoIY6ZDtwAM4JUVJLHE UIGxg4UskshL8NJZnc76n7hFAnXec1JNsQgBEErvOaJME41l5tLg8IRnIeO6hlX4F+Ho kfJF9Bf7caRuSLUpS8+8VoxEjwouv+7CYEdmcVGYpWhjUFmJHdlJYPJxm99Dqg4Fy+27 9qwg== X-Gm-Message-State: AOAM532HN2bqSEujsezbGD09WuJ7URPdW29DKhN63o47zDtRApsWLsDq mVy9ksa34iimsuqPdUf97z+av31Vbom/yg== X-Google-Smtp-Source: ABdhPJyXVtM6dBwihMzRuuMnjuS88+iO7v12GSmEP3VghjhE+11fpZYUM1njQu2ivJUp2KeakXGxDg== X-Received: by 2002:a17:906:ce59:: with SMTP id se25mr4770900ejb.359.1597846967445; Wed, 19 Aug 2020 07:22:47 -0700 (PDT) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com. [209.85.221.54]) by smtp.gmail.com with ESMTPSA id c7sm18063691edf.1.2020.08.19.07.22.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 07:22:47 -0700 (PDT) Received: by mail-wr1-f54.google.com with SMTP id r4so21690367wrx.9 for ; Wed, 19 Aug 2020 07:22:46 -0700 (PDT) X-Received: by 2002:adf:ec45:: with SMTP id w5mr25495420wrn.415.1597846966201; Wed, 19 Aug 2020 07:22:46 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <62e4f4fc-c8a5-3ee8-c576-fe7178cb4356@arm.com> <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> In-Reply-To: <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> From: Tomasz Figa Date: Wed, 19 Aug 2020 16:22:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Robin Murphy X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200819_102249_001201_0982457D X-CRM114-Status: GOOD ( 41.75 ) X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, "James E.J. Bottomley" , linux-mm@kvack.org, Christoph Hellwig , Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Joerg Roedel , "list@263.net:IOMMU DRIVERS" , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , Kyungmin Park Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-nvme" Errors-To: linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote: > > On 2020-08-19 13:49, Tomasz Figa wrote: > > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: > >> > >> Hi Tomasz, > >> > >> On 2020-08-19 12:16, Tomasz Figa wrote: > >>> Hi Christoph, > >>> > >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: > >>>> > >>>> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, > >>> > >>> Could you explain what makes you think it's unused? It's a feature of > >>> the UAPI generally supported by the videobuf2 framework and relied on > >>> by Chromium OS to get any kind of reasonable performance when > >>> accessing V4L2 buffers in the userspace. > >>> > >>>> and causes > >>>> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >>>> unimplemented except on PARISC and some MIPS configs, and about to be > >>>> removed. > >>> > >>> It is implemented by the generic DMA mapping layer [1], which is used > >>> by a number of architectures including ARM64 and supposed to be used > >>> by new architectures going forward. > >> > >> AFAICS all that V4L2_FLAG_MEMORY_NON_CONSISTENT does is end up > >> controling whether DMA_ATTR_NON_CONSISTENT is added to vb2_queue::dma_attrs. > >> > >> Please can you point to where DMA_ATTR_NON_CONSISTENT does anything at > >> all on arm64? > >> > > > > With the default config it doesn't, but with > > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep > > the pgprot value as is, without enforcing coherence attributes. > > How active are the PA-RISC and MIPS ports of Chromium OS? Not active. We enable CONFIG_DMA_NONCOHERENT_CACHE_SYNC for ARM64, given the directions received back in April when discussing the noncoherent memory functionality on the mailing list in the thread I pointed out in my previous message and no clarification on why it is disabled for ARM64 in upstream, despite making several attempts to get some. > > Hacking CONFIG_DMA_NONCOHERENT_CACHE_SYNC into an architecture that > doesn't provide dma_cache_sync() is wrong, since at worst it may break > other drivers. If downstream is wildly misusing an API then so be it, > but it's hardly a strong basis for an upstream argument. I guess it means that we're wildly misusing the API, but it still does work. Could you explain how it could break other drivers? > > >> Also, I posit that videobuf2 is not actually relying on > >> DMA_ATTR_NON_CONSISTENT anyway, since it's clearly not using it properly: > >> > >> "By using this API, you are guaranteeing to the platform > >> that you have all the correct and necessary sync points for this memory > >> in the driver should it choose to return non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also always > been wrong per the API, regardless of the bodies of code that have > happened to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I pointed to, but that might of course be my misunderstanding. > i.e. this series - not encouraging mixing the existing APIs. It doesn't > seem impossible to implement a remapping version of this new > dma_alloc_pages() for IOMMU-backed ops if it's really warranted > (although at that point it seems like "non-coherent" vb2-dc starts to > have significant conceptual overlap with vb2-sg). No, there is no overlap between vb2-dc and vb2-sg. They differ on another level - the former is to be used by devices without scatter-gather or internal mapping capabilities and gives the driver a single DMA address for the whole buffer, regardless of whether it's IOVA-contiguous (for devices behind an IOMMU) or physically contiguous (for the others), while the latter gives the driver an sgtable, which of course may be DMA-contiguous internally, but doesn't have to and usually isn't. This model makes it possible to hide the SoC implementation details from particular drivers, since those are very often reused on many SoCs which differ in the availability of IOMMU, DMA addressing restrictions and so on. Best regards, Tomasz _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme 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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 84CC0C433E1 for ; Wed, 19 Aug 2020 14:30:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32E6620639 for ; Wed, 19 Aug 2020 14:30:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="MwoQKU4R" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32E6620639 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A21696B0073; Wed, 19 Aug 2020 10:30:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D1616B00B4; Wed, 19 Aug 2020 10:30:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87E256B00B5; Wed, 19 Aug 2020 10:30:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) by kanga.kvack.org (Postfix) with ESMTP id 6E1DE6B0073 for ; Wed, 19 Aug 2020 10:30:42 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 06DF52489 for ; Wed, 19 Aug 2020 14:30:42 +0000 (UTC) X-FDA: 77167554324.23.able56_410424a27028 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 6A46837608 for ; Wed, 19 Aug 2020 14:30:33 +0000 (UTC) X-HE-Tag: able56_410424a27028 X-Filterd-Recvd-Size: 9649 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Aug 2020 14:30:32 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id t23so25638458ljc.3 for ; Wed, 19 Aug 2020 07:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=MwoQKU4RRVGBwswghQT2kEA4PWtzNJ9PP0GlvGH+VtAzrSvBnEW2dUpr0fs6tqB36t NEatNz3nTo9Srl8JZAX9oVp9pc5TQLgcK+vTRNeNePaaHI1s5H4G84GiGqxdAJ9X51ZU 9RjLZl32ILMLyADH9W9JtyN4rfe/+nXKgJFvs= 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=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=GXaKiJV5Ip7s2OnM5r13mcQxULpCEvp7pcy5OUiXIEWgVaM7noi6LfB4qsXpJciNj0 UUmrbfYU1hr0HE8pl/iwW7EaxWzQ07WOo56HqMlwPPp1zwd71mBObbuQeRmyuxV80EaN J0g9L1K1OCScl6bA+ZJa93TmKbLXIxWS17l0lcuvUXDLrMFbwr8U+p2YB4/TdjTblkrw ugbF2aLrWud2avETmniPVtI6QGN4KcNNBBnNbd9+NLG9m4AFaUty3Gzj7D7S7L5oB2dt XCZEdQnt/RUtUvICAdil1uNpfV0ULaY5YgWkYoTmG7WCRpdQxuUTj90RKGWL/ho4O/g+ fX3Q== X-Gm-Message-State: AOAM533TVIkMksp8JhWwcpw82mE4WM0z7lXkqSE74J9BSQ1OKC2pQIJ9 +u3O9Aw0UxzCGsJsWGUw4iZXDw40MZMK9A== X-Google-Smtp-Source: ABdhPJx+Zbou/ZdYjt9/sjVTcQiZ9zLwGN80Ts07zKs3bNtazes3Yw0xjeVoSul6kvQIQTnf1BTikQ== X-Received: by 2002:a2e:7014:: with SMTP id l20mr5805070ljc.162.1597847430309; Wed, 19 Aug 2020 07:30:30 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id r14sm7309723lfe.29.2020.08.19.07.30.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 07:30:29 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id b30so12160022lfj.12 for ; Wed, 19 Aug 2020 07:30:29 -0700 (PDT) X-Received: by 2002:adf:ec45:: with SMTP id w5mr25495420wrn.415.1597846966201; Wed, 19 Aug 2020 07:22:46 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <62e4f4fc-c8a5-3ee8-c576-fe7178cb4356@arm.com> <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> In-Reply-To: <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> From: Tomasz Figa Date: Wed, 19 Aug 2020 16:22:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Robin Murphy Cc: Christoph Hellwig , alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, Linux Kernel Mailing List , "James E.J. Bottomley" , linux-mm@kvack.org, Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Kyungmin Park , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS" , Joerg Roedel , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , linux-mips@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 6A46837608 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote: > > On 2020-08-19 13:49, Tomasz Figa wrote: > > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: > >> > >> Hi Tomasz, > >> > >> On 2020-08-19 12:16, Tomasz Figa wrote: > >>> Hi Christoph, > >>> > >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: > >>>> > >>>> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, > >>> > >>> Could you explain what makes you think it's unused? It's a feature of > >>> the UAPI generally supported by the videobuf2 framework and relied on > >>> by Chromium OS to get any kind of reasonable performance when > >>> accessing V4L2 buffers in the userspace. > >>> > >>>> and causes > >>>> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >>>> unimplemented except on PARISC and some MIPS configs, and about to be > >>>> removed. > >>> > >>> It is implemented by the generic DMA mapping layer [1], which is used > >>> by a number of architectures including ARM64 and supposed to be used > >>> by new architectures going forward. > >> > >> AFAICS all that V4L2_FLAG_MEMORY_NON_CONSISTENT does is end up > >> controling whether DMA_ATTR_NON_CONSISTENT is added to vb2_queue::dma_attrs. > >> > >> Please can you point to where DMA_ATTR_NON_CONSISTENT does anything at > >> all on arm64? > >> > > > > With the default config it doesn't, but with > > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep > > the pgprot value as is, without enforcing coherence attributes. > > How active are the PA-RISC and MIPS ports of Chromium OS? Not active. We enable CONFIG_DMA_NONCOHERENT_CACHE_SYNC for ARM64, given the directions received back in April when discussing the noncoherent memory functionality on the mailing list in the thread I pointed out in my previous message and no clarification on why it is disabled for ARM64 in upstream, despite making several attempts to get some. > > Hacking CONFIG_DMA_NONCOHERENT_CACHE_SYNC into an architecture that > doesn't provide dma_cache_sync() is wrong, since at worst it may break > other drivers. If downstream is wildly misusing an API then so be it, > but it's hardly a strong basis for an upstream argument. I guess it means that we're wildly misusing the API, but it still does work. Could you explain how it could break other drivers? > > >> Also, I posit that videobuf2 is not actually relying on > >> DMA_ATTR_NON_CONSISTENT anyway, since it's clearly not using it properly: > >> > >> "By using this API, you are guaranteeing to the platform > >> that you have all the correct and necessary sync points for this memory > >> in the driver should it choose to return non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also always > been wrong per the API, regardless of the bodies of code that have > happened to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I pointed to, but that might of course be my misunderstanding. > i.e. this series - not encouraging mixing the existing APIs. It doesn't > seem impossible to implement a remapping version of this new > dma_alloc_pages() for IOMMU-backed ops if it's really warranted > (although at that point it seems like "non-coherent" vb2-dc starts to > have significant conceptual overlap with vb2-sg). No, there is no overlap between vb2-dc and vb2-sg. They differ on another level - the former is to be used by devices without scatter-gather or internal mapping capabilities and gives the driver a single DMA address for the whole buffer, regardless of whether it's IOVA-contiguous (for devices behind an IOMMU) or physically contiguous (for the others), while the latter gives the driver an sgtable, which of course may be DMA-contiguous internally, but doesn't have to and usually isn't. This model makes it possible to hide the SoC implementation details from particular drivers, since those are very often reused on many SoCs which differ in the availability of IOMMU, DMA addressing restrictions and so on. Best regards, Tomasz 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=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 0FB5DC433E1 for ; Fri, 21 Aug 2020 07:52:50 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 89F5C22CAE for ; Fri, 21 Aug 2020 07:52:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="HcRt3d+2"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="MwoQKU4R" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 89F5C22CAE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 1412616DD; Fri, 21 Aug 2020 09:51:58 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 1412616DD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1597996368; bh=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=HcRt3d+2nY1mw/i41d0b/NQBTw7NcL1JbxfieZregMCimyF6AFPaq3gDrq9WMpI83 /8oTrfBK/3YeIC8U+B7LLBoD3cUGUZBuiY9mP81b/nCO07n1k6LOsu7BnkZ05ZudPp s90Upj5/0YSISvOL7BfRiS8QO2IKVBzdDA1L8HGY= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id D71F4F803F5; Fri, 21 Aug 2020 09:36:29 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 784A1F80257; Wed, 19 Aug 2020 16:22:57 +0200 (CEST) Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 07AFFF800D3 for ; Wed, 19 Aug 2020 16:22:50 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 07AFFF800D3 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="MwoQKU4R" Received: by mail-ej1-x644.google.com with SMTP id o23so26551647ejr.1 for ; Wed, 19 Aug 2020 07:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=MwoQKU4RRVGBwswghQT2kEA4PWtzNJ9PP0GlvGH+VtAzrSvBnEW2dUpr0fs6tqB36t NEatNz3nTo9Srl8JZAX9oVp9pc5TQLgcK+vTRNeNePaaHI1s5H4G84GiGqxdAJ9X51ZU 9RjLZl32ILMLyADH9W9JtyN4rfe/+nXKgJFvs= 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=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=ssSC64/tvg0Nl+PaMi41FlMQanNTwB/AWeeen/QeafHUNgxRgZTEAehomTWafbedP8 +7kfQeOHWu4Wpt/dRtf83MT75M/GpNCmk/fzkdwSh0k0O+wIelXFYDuJ/X5UOEY3Hfq0 1GsWf5Lb+hX9iEPWLxaO1YdgUPC5P8Puz4q89PwEKLcU9mKmxYfZSE2pCTURgUVChlzf GoS60qb6N7LihCdsZusn67P159N+NZKDFD4kWkyOk2ZZJO5KOJYorXBmuHxXqManOuBy Hwi9CI0eOJ/t8pQ/ousqyzMXUI3+JOVJm+pjyYVWdcP7dwqlk9TWqBFblID3Rp4kpHpg +WhA== X-Gm-Message-State: AOAM531Q7xvu2xh4D8041N4fUvmKvKcTGrpwuadKr3GNHNqu4A9gnJ4b 1D0Vbn1IytI4t6XGOykTKbogyoGcSfb9JA== X-Google-Smtp-Source: ABdhPJz45LG/9kEMu8IDVYGfDYlLmFVOl+GdhVG+eTheEF2tkoCwPElikD+VmDyAakd57DG5PwHHsw== X-Received: by 2002:a17:906:e2c5:: with SMTP id gr5mr26676422ejb.89.1597846968871; Wed, 19 Aug 2020 07:22:48 -0700 (PDT) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com. [209.85.221.53]) by smtp.gmail.com with ESMTPSA id j1sm17697265edq.58.2020.08.19.07.22.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 07:22:47 -0700 (PDT) Received: by mail-wr1-f53.google.com with SMTP id r2so21739407wrs.8 for ; Wed, 19 Aug 2020 07:22:46 -0700 (PDT) X-Received: by 2002:adf:ec45:: with SMTP id w5mr25495420wrn.415.1597846966201; Wed, 19 Aug 2020 07:22:46 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <62e4f4fc-c8a5-3ee8-c576-fe7178cb4356@arm.com> <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> In-Reply-To: <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> From: Tomasz Figa Date: Wed, 19 Aug 2020 16:22:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Robin Murphy Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Fri, 21 Aug 2020 09:36:14 +0200 Cc: alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, "James E.J. Bottomley" , linux-mm@kvack.org, Christoph Hellwig , Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Joerg Roedel , "list@263.net:IOMMU DRIVERS" , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , Kyungmin Park X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote: > > On 2020-08-19 13:49, Tomasz Figa wrote: > > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: > >> > >> Hi Tomasz, > >> > >> On 2020-08-19 12:16, Tomasz Figa wrote: > >>> Hi Christoph, > >>> > >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: > >>>> > >>>> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, > >>> > >>> Could you explain what makes you think it's unused? It's a feature of > >>> the UAPI generally supported by the videobuf2 framework and relied on > >>> by Chromium OS to get any kind of reasonable performance when > >>> accessing V4L2 buffers in the userspace. > >>> > >>>> and causes > >>>> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >>>> unimplemented except on PARISC and some MIPS configs, and about to be > >>>> removed. > >>> > >>> It is implemented by the generic DMA mapping layer [1], which is used > >>> by a number of architectures including ARM64 and supposed to be used > >>> by new architectures going forward. > >> > >> AFAICS all that V4L2_FLAG_MEMORY_NON_CONSISTENT does is end up > >> controling whether DMA_ATTR_NON_CONSISTENT is added to vb2_queue::dma_attrs. > >> > >> Please can you point to where DMA_ATTR_NON_CONSISTENT does anything at > >> all on arm64? > >> > > > > With the default config it doesn't, but with > > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep > > the pgprot value as is, without enforcing coherence attributes. > > How active are the PA-RISC and MIPS ports of Chromium OS? Not active. We enable CONFIG_DMA_NONCOHERENT_CACHE_SYNC for ARM64, given the directions received back in April when discussing the noncoherent memory functionality on the mailing list in the thread I pointed out in my previous message and no clarification on why it is disabled for ARM64 in upstream, despite making several attempts to get some. > > Hacking CONFIG_DMA_NONCOHERENT_CACHE_SYNC into an architecture that > doesn't provide dma_cache_sync() is wrong, since at worst it may break > other drivers. If downstream is wildly misusing an API then so be it, > but it's hardly a strong basis for an upstream argument. I guess it means that we're wildly misusing the API, but it still does work. Could you explain how it could break other drivers? > > >> Also, I posit that videobuf2 is not actually relying on > >> DMA_ATTR_NON_CONSISTENT anyway, since it's clearly not using it properly: > >> > >> "By using this API, you are guaranteeing to the platform > >> that you have all the correct and necessary sync points for this memory > >> in the driver should it choose to return non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also always > been wrong per the API, regardless of the bodies of code that have > happened to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I pointed to, but that might of course be my misunderstanding. > i.e. this series - not encouraging mixing the existing APIs. It doesn't > seem impossible to implement a remapping version of this new > dma_alloc_pages() for IOMMU-backed ops if it's really warranted > (although at that point it seems like "non-coherent" vb2-dc starts to > have significant conceptual overlap with vb2-sg). No, there is no overlap between vb2-dc and vb2-sg. They differ on another level - the former is to be used by devices without scatter-gather or internal mapping capabilities and gives the driver a single DMA address for the whole buffer, regardless of whether it's IOVA-contiguous (for devices behind an IOMMU) or physically contiguous (for the others), while the latter gives the driver an sgtable, which of course may be DMA-contiguous internally, but doesn't have to and usually isn't. This model makes it possible to hide the SoC implementation details from particular drivers, since those are very often reused on many SoCs which differ in the availability of IOMMU, DMA addressing restrictions and so on. Best regards, Tomasz From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Figa Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT Date: Wed, 19 Aug 2020 16:22:29 +0200 Message-ID: References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <62e4f4fc-c8a5-3ee8-c576-fe7178cb4356@arm.com> <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> Sender: linux-media-owner@vger.kernel.org To: Robin Murphy Cc: Christoph Hellwig , alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, Linux Kernel Mailing List , "James E.J. Bottomley" , linux-mm@kvack.org, Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Kyungmin Park , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Maur List-Id: nouveau.vger.kernel.org On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote: > > On 2020-08-19 13:49, Tomasz Figa wrote: > > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: > >> > >> Hi Tomasz, > >> > >> On 2020-08-19 12:16, Tomasz Figa wrote: > >>> Hi Christoph, > >>> > >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: > >>>> > >>>> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, > >>> > >>> Could you explain what makes you think it's unused? It's a feature of > >>> the UAPI generally supported by the videobuf2 framework and relied on > >>> by Chromium OS to get any kind of reasonable performance when > >>> accessing V4L2 buffers in the userspace. > >>> > >>>> and causes > >>>> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >>>> unimplemented except on PARISC and some MIPS configs, and about to be > >>>> removed. > >>> > >>> It is implemented by the generic DMA mapping layer [1], which is used > >>> by a number of architectures including ARM64 and supposed to be used > >>> by new architectures going forward. > >> > >> AFAICS all that V4L2_FLAG_MEMORY_NON_CONSISTENT does is end up > >> controling whether DMA_ATTR_NON_CONSISTENT is added to vb2_queue::dma_attrs. > >> > >> Please can you point to where DMA_ATTR_NON_CONSISTENT does anything at > >> all on arm64? > >> > > > > With the default config it doesn't, but with > > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep > > the pgprot value as is, without enforcing coherence attributes. > > How active are the PA-RISC and MIPS ports of Chromium OS? Not active. We enable CONFIG_DMA_NONCOHERENT_CACHE_SYNC for ARM64, given the directions received back in April when discussing the noncoherent memory functionality on the mailing list in the thread I pointed out in my previous message and no clarification on why it is disabled for ARM64 in upstream, despite making several attempts to get some. > > Hacking CONFIG_DMA_NONCOHERENT_CACHE_SYNC into an architecture that > doesn't provide dma_cache_sync() is wrong, since at worst it may break > other drivers. If downstream is wildly misusing an API then so be it, > but it's hardly a strong basis for an upstream argument. I guess it means that we're wildly misusing the API, but it still does work. Could you explain how it could break other drivers? > > >> Also, I posit that videobuf2 is not actually relying on > >> DMA_ATTR_NON_CONSISTENT anyway, since it's clearly not using it properly: > >> > >> "By using this API, you are guaranteeing to the platform > >> that you have all the correct and necessary sync points for this memory > >> in the driver should it choose to return non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also always > been wrong per the API, regardless of the bodies of code that have > happened to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I pointed to, but that might of course be my misunderstanding. > i.e. this series - not encouraging mixing the existing APIs. It doesn't > seem impossible to implement a remapping version of this new > dma_alloc_pages() for IOMMU-backed ops if it's really warranted > (although at that point it seems like "non-coherent" vb2-dc starts to > have significant conceptual overlap with vb2-sg). No, there is no overlap between vb2-dc and vb2-sg. They differ on another level - the former is to be used by devices without scatter-gather or internal mapping capabilities and gives the driver a single DMA address for the whole buffer, regardless of whether it's IOVA-contiguous (for devices behind an IOMMU) or physically contiguous (for the others), while the latter gives the driver an sgtable, which of course may be DMA-contiguous internally, but doesn't have to and usually isn't. This model makes it possible to hide the SoC implementation details from particular drivers, since those are very often reused on many SoCs which differ in the availability of IOMMU, DMA addressing restrictions and so on. Best regards, Tomasz 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 88628C433E3 for ; Wed, 19 Aug 2020 14:22:55 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 56FC72076E for ; Wed, 19 Aug 2020 14:22:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="MwoQKU4R" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56FC72076E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 23DAF864DA; Wed, 19 Aug 2020 14:22:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNJv7NDGybYi; Wed, 19 Aug 2020 14:22:54 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by whitealder.osuosl.org (Postfix) with ESMTP id 6CEA9864D7; Wed, 19 Aug 2020 14:22:54 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 56B39C07FF; Wed, 19 Aug 2020 14:22:54 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id AF397C0051 for ; Wed, 19 Aug 2020 14:22:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 97A9D864DA for ; Wed, 19 Aug 2020 14:22:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GVadbJ-SA-v for ; Wed, 19 Aug 2020 14:22:51 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by whitealder.osuosl.org (Postfix) with ESMTPS id 551C8864D7 for ; Wed, 19 Aug 2020 14:22:51 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id v22so18262612edy.0 for ; Wed, 19 Aug 2020 07:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=MwoQKU4RRVGBwswghQT2kEA4PWtzNJ9PP0GlvGH+VtAzrSvBnEW2dUpr0fs6tqB36t NEatNz3nTo9Srl8JZAX9oVp9pc5TQLgcK+vTRNeNePaaHI1s5H4G84GiGqxdAJ9X51ZU 9RjLZl32ILMLyADH9W9JtyN4rfe/+nXKgJFvs= 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=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=C6W/k/DZ/yGw4tj6odGw5zxUXAasCviOEDkT4KHnj55qIvx9wwRD5O/if4K08cOBo9 KaUZLltRNuXbFF+240rHE1rjOhffn3Y+OQhjNnKtxQ56FdI9J39eSeCh+Bok1Sf5Z2sH ESL0vOJiddbhEZABcb8TFbZgvJ+aDh0WZ3nWDWpst3MmcLORBg8Wk5acG2FMLcLemrsf 4PGOf7LSEF8lTekXzDi56pPsHL7fRecz69hFEmCDSwWH5XEMVb5X8rmF8cYqwdn+k83Q xvhtjNeur81SOro6rMfXj5W/Wu/25RujgxqKo5zi9Yrq3Dy46lgN7Jr3E56a8mlDCjkt 84VQ== X-Gm-Message-State: AOAM531mtyffIe0fN5NfhgnukIsR4OeLTQ1/3Ia6M/iCAocehgkN4U4a e1Vxi2fOaPtfzIdIHBMrj94tSzrcDfFeiA== X-Google-Smtp-Source: ABdhPJyKtnatzqH2+jkSLuWqLZTOFJsNzetfrGXQvxI1fxy8VieRhpEKasp/wLbNjJUmfWgV80d9rw== X-Received: by 2002:a05:6402:212:: with SMTP id t18mr25692889edv.124.1597846969285; Wed, 19 Aug 2020 07:22:49 -0700 (PDT) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com. [209.85.221.51]) by smtp.gmail.com with ESMTPSA id g24sm17799074eds.42.2020.08.19.07.22.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 07:22:48 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id a14so21737477wra.5 for ; Wed, 19 Aug 2020 07:22:47 -0700 (PDT) X-Received: by 2002:adf:ec45:: with SMTP id w5mr25495420wrn.415.1597846966201; Wed, 19 Aug 2020 07:22:46 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <62e4f4fc-c8a5-3ee8-c576-fe7178cb4356@arm.com> <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> In-Reply-To: <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> From: Tomasz Figa Date: Wed, 19 Aug 2020 16:22:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Robin Murphy Cc: alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, "James E.J. Bottomley" , linux-mm@kvack.org, Christoph Hellwig , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, "list@263.net:IOMMU DRIVERS" , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , Kyungmin Park X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote: > > On 2020-08-19 13:49, Tomasz Figa wrote: > > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: > >> > >> Hi Tomasz, > >> > >> On 2020-08-19 12:16, Tomasz Figa wrote: > >>> Hi Christoph, > >>> > >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: > >>>> > >>>> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, > >>> > >>> Could you explain what makes you think it's unused? It's a feature of > >>> the UAPI generally supported by the videobuf2 framework and relied on > >>> by Chromium OS to get any kind of reasonable performance when > >>> accessing V4L2 buffers in the userspace. > >>> > >>>> and causes > >>>> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >>>> unimplemented except on PARISC and some MIPS configs, and about to be > >>>> removed. > >>> > >>> It is implemented by the generic DMA mapping layer [1], which is used > >>> by a number of architectures including ARM64 and supposed to be used > >>> by new architectures going forward. > >> > >> AFAICS all that V4L2_FLAG_MEMORY_NON_CONSISTENT does is end up > >> controling whether DMA_ATTR_NON_CONSISTENT is added to vb2_queue::dma_attrs. > >> > >> Please can you point to where DMA_ATTR_NON_CONSISTENT does anything at > >> all on arm64? > >> > > > > With the default config it doesn't, but with > > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep > > the pgprot value as is, without enforcing coherence attributes. > > How active are the PA-RISC and MIPS ports of Chromium OS? Not active. We enable CONFIG_DMA_NONCOHERENT_CACHE_SYNC for ARM64, given the directions received back in April when discussing the noncoherent memory functionality on the mailing list in the thread I pointed out in my previous message and no clarification on why it is disabled for ARM64 in upstream, despite making several attempts to get some. > > Hacking CONFIG_DMA_NONCOHERENT_CACHE_SYNC into an architecture that > doesn't provide dma_cache_sync() is wrong, since at worst it may break > other drivers. If downstream is wildly misusing an API then so be it, > but it's hardly a strong basis for an upstream argument. I guess it means that we're wildly misusing the API, but it still does work. Could you explain how it could break other drivers? > > >> Also, I posit that videobuf2 is not actually relying on > >> DMA_ATTR_NON_CONSISTENT anyway, since it's clearly not using it properly: > >> > >> "By using this API, you are guaranteeing to the platform > >> that you have all the correct and necessary sync points for this memory > >> in the driver should it choose to return non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also always > been wrong per the API, regardless of the bodies of code that have > happened to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I pointed to, but that might of course be my misunderstanding. > i.e. this series - not encouraging mixing the existing APIs. It doesn't > seem impossible to implement a remapping version of this new > dma_alloc_pages() for IOMMU-backed ops if it's really warranted > (although at that point it seems like "non-coherent" vb2-dc starts to > have significant conceptual overlap with vb2-sg). No, there is no overlap between vb2-dc and vb2-sg. They differ on another level - the former is to be used by devices without scatter-gather or internal mapping capabilities and gives the driver a single DMA address for the whole buffer, regardless of whether it's IOVA-contiguous (for devices behind an IOMMU) or physically contiguous (for the others), while the latter gives the driver an sgtable, which of course may be DMA-contiguous internally, but doesn't have to and usually isn't. This model makes it possible to hide the SoC implementation details from particular drivers, since those are very often reused on many SoCs which differ in the availability of IOMMU, DMA addressing restrictions and so on. Best regards, Tomasz _______________________________________________ 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 13367C433E1 for ; Wed, 19 Aug 2020 14:32:18 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 CFC7A20738 for ; Wed, 19 Aug 2020 14:32:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="x2S8UO6o"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="MwoQKU4R" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFC7A20738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BsybmKhfHmJuMvRtne8KzmRkefMBskBAA09IlkNE4ZY=; b=x2S8UO6obyKLYRU5eRijSCkm7 /PhW/5jcyBStb2j/goDngn9ADmubKFXHQnljvl91iL1OIdS1pP+yQ3LElmfrPmSbRmnk9Sq62Dsd2 orkvZTYsLajtL9/jBDkROOJNLeObBKhwx23m3Qw9tohJkc99uLSuZ1nsXoQU2kh/fWKHQEbk/Ds5y x3PFsSPaQw7v78IGzFmNwImGD3PK15CL5bgzi1goObrdgHRglvUmO/6oXxbJRjXv0kP9HtVrZFSoN giwqztbdjgkEzhJaVsmGe+Pz3qiUKHLet8kynv4C4Ltinr4gVUU//OWXbkXzSLp4gCALRAcGk2Xm4 AEoPA4EUA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8P75-0005pK-Hr; Wed, 19 Aug 2020 14:30:51 +0000 Received: from mail-ej1-x644.google.com ([2a00:1450:4864:20::644]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8P73-0005oY-1A for linux-arm-kernel@lists.infradead.org; Wed, 19 Aug 2020 14:30:49 +0000 Received: by mail-ej1-x644.google.com with SMTP id d6so26547695ejr.5 for ; Wed, 19 Aug 2020 07:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=MwoQKU4RRVGBwswghQT2kEA4PWtzNJ9PP0GlvGH+VtAzrSvBnEW2dUpr0fs6tqB36t NEatNz3nTo9Srl8JZAX9oVp9pc5TQLgcK+vTRNeNePaaHI1s5H4G84GiGqxdAJ9X51ZU 9RjLZl32ILMLyADH9W9JtyN4rfe/+nXKgJFvs= 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=uEY7dk9y/9x4HcaWjwFAfwvm+T0doGz7atsT11F+few=; b=O2b8KC5j2Xn58SFbM8nKEQRl1dusnuD36uM9lzN3nWdt/nttDpxFGtUa/xvdMQpQQt YizM+S6PHezee57C0ExUpbjl4XK0CROQvWM2SK4GArP3srO7k4GJGkxxtQXIXv4s6nyo 6ND9TyZ8l/CbJFhKjN3A3vpdas/66jfkOowsQoD10UyLH8MjWkoJuUXKF6H0qxJjwU+c Yp9F8dcga6o0FXiO6fzHEBZ48Ks2xhGxOL99ztowbw5hqUW292JAaU1SH1F82/Co8VMn OMHvOavzDml7UpZUsgeSFSE6NkV3C3Bp7opFtdc+LrXEZzztxtmUpO82qVpgOQWovJSJ pMEg== X-Gm-Message-State: AOAM5315HnctDa4L4fooUAyPqTkt9s6SkOrM/GX50+HU26bODm2qeCp2 aDpSbDmrrUHNe5GHtMWNQ0j1qUn/aSLA8w== X-Google-Smtp-Source: ABdhPJxzprPUB6I4YjLesM8uncNm7bduAL/axBMHRIctmrpr7ZMcGAbF2mVMNanAHMKXnxSd5l14dQ== X-Received: by 2002:a17:906:95d4:: with SMTP id n20mr26780111ejy.485.1597847447615; Wed, 19 Aug 2020 07:30:47 -0700 (PDT) Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com. [209.85.218.41]) by smtp.gmail.com with ESMTPSA id t3sm18005998edq.26.2020.08.19.07.30.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 07:30:47 -0700 (PDT) Received: by mail-ej1-f41.google.com with SMTP id qc22so26556382ejb.4 for ; Wed, 19 Aug 2020 07:30:47 -0700 (PDT) X-Received: by 2002:adf:ec45:: with SMTP id w5mr25495420wrn.415.1597846966201; Wed, 19 Aug 2020 07:22:46 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <62e4f4fc-c8a5-3ee8-c576-fe7178cb4356@arm.com> <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> In-Reply-To: <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> From: Tomasz Figa Date: Wed, 19 Aug 2020 16:22:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Robin Murphy X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200819_103049_105554_589EBE2F X-CRM114-Status: GOOD ( 41.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, "James E.J. Bottomley" , linux-mm@kvack.org, Christoph Hellwig , Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Joerg Roedel , "list@263.net:IOMMU DRIVERS" , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , Kyungmin Park Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote: > > On 2020-08-19 13:49, Tomasz Figa wrote: > > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: > >> > >> Hi Tomasz, > >> > >> On 2020-08-19 12:16, Tomasz Figa wrote: > >>> Hi Christoph, > >>> > >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: > >>>> > >>>> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, > >>> > >>> Could you explain what makes you think it's unused? It's a feature of > >>> the UAPI generally supported by the videobuf2 framework and relied on > >>> by Chromium OS to get any kind of reasonable performance when > >>> accessing V4L2 buffers in the userspace. > >>> > >>>> and causes > >>>> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >>>> unimplemented except on PARISC and some MIPS configs, and about to be > >>>> removed. > >>> > >>> It is implemented by the generic DMA mapping layer [1], which is used > >>> by a number of architectures including ARM64 and supposed to be used > >>> by new architectures going forward. > >> > >> AFAICS all that V4L2_FLAG_MEMORY_NON_CONSISTENT does is end up > >> controling whether DMA_ATTR_NON_CONSISTENT is added to vb2_queue::dma_attrs. > >> > >> Please can you point to where DMA_ATTR_NON_CONSISTENT does anything at > >> all on arm64? > >> > > > > With the default config it doesn't, but with > > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep > > the pgprot value as is, without enforcing coherence attributes. > > How active are the PA-RISC and MIPS ports of Chromium OS? Not active. We enable CONFIG_DMA_NONCOHERENT_CACHE_SYNC for ARM64, given the directions received back in April when discussing the noncoherent memory functionality on the mailing list in the thread I pointed out in my previous message and no clarification on why it is disabled for ARM64 in upstream, despite making several attempts to get some. > > Hacking CONFIG_DMA_NONCOHERENT_CACHE_SYNC into an architecture that > doesn't provide dma_cache_sync() is wrong, since at worst it may break > other drivers. If downstream is wildly misusing an API then so be it, > but it's hardly a strong basis for an upstream argument. I guess it means that we're wildly misusing the API, but it still does work. Could you explain how it could break other drivers? > > >> Also, I posit that videobuf2 is not actually relying on > >> DMA_ATTR_NON_CONSISTENT anyway, since it's clearly not using it properly: > >> > >> "By using this API, you are guaranteeing to the platform > >> that you have all the correct and necessary sync points for this memory > >> in the driver should it choose to return non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also always > been wrong per the API, regardless of the bodies of code that have > happened to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I pointed to, but that might of course be my misunderstanding. > i.e. this series - not encouraging mixing the existing APIs. It doesn't > seem impossible to implement a remapping version of this new > dma_alloc_pages() for IOMMU-backed ops if it's really warranted > (although at that point it seems like "non-coherent" vb2-dc starts to > have significant conceptual overlap with vb2-sg). No, there is no overlap between vb2-dc and vb2-sg. They differ on another level - the former is to be used by devices without scatter-gather or internal mapping capabilities and gives the driver a single DMA address for the whole buffer, regardless of whether it's IOVA-contiguous (for devices behind an IOMMU) or physically contiguous (for the others), while the latter gives the driver an sgtable, which of course may be DMA-contiguous internally, but doesn't have to and usually isn't. This model makes it possible to hide the SoC implementation details from particular drivers, since those are very often reused on many SoCs which differ in the availability of IOMMU, DMA addressing restrictions and so on. Best regards, Tomasz _______________________________________________ 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 From: Tomasz Figa Date: Wed, 19 Aug 2020 14:22:29 +0000 Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT Message-Id: List-Id: References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <62e4f4fc-c8a5-3ee8-c576-fe7178cb4356@arm.com> <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> In-Reply-To: <2b32f1d8-16f7-3352-40a5-420993d52fb5@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Robin Murphy Cc: Christoph Hellwig , alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, Linux Kernel Mailing List , "James E.J. Bottomley" , linux-mm@kvack.org, Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Kyungmin Park , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS" , Joerg Roedel , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , linux-mips@vger.kernel.org On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote: > > On 2020-08-19 13:49, Tomasz Figa wrote: > > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: > >> > >> Hi Tomasz, > >> > >> On 2020-08-19 12:16, Tomasz Figa wrote: > >>> Hi Christoph, > >>> > >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: > >>>> > >>>> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, > >>> > >>> Could you explain what makes you think it's unused? It's a feature of > >>> the UAPI generally supported by the videobuf2 framework and relied on > >>> by Chromium OS to get any kind of reasonable performance when > >>> accessing V4L2 buffers in the userspace. > >>> > >>>> and causes > >>>> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >>>> unimplemented except on PARISC and some MIPS configs, and about to be > >>>> removed. > >>> > >>> It is implemented by the generic DMA mapping layer [1], which is used > >>> by a number of architectures including ARM64 and supposed to be used > >>> by new architectures going forward. > >> > >> AFAICS all that V4L2_FLAG_MEMORY_NON_CONSISTENT does is end up > >> controling whether DMA_ATTR_NON_CONSISTENT is added to vb2_queue::dma_attrs. > >> > >> Please can you point to where DMA_ATTR_NON_CONSISTENT does anything at > >> all on arm64? > >> > > > > With the default config it doesn't, but with > > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep > > the pgprot value as is, without enforcing coherence attributes. > > How active are the PA-RISC and MIPS ports of Chromium OS? Not active. We enable CONFIG_DMA_NONCOHERENT_CACHE_SYNC for ARM64, given the directions received back in April when discussing the noncoherent memory functionality on the mailing list in the thread I pointed out in my previous message and no clarification on why it is disabled for ARM64 in upstream, despite making several attempts to get some. > > Hacking CONFIG_DMA_NONCOHERENT_CACHE_SYNC into an architecture that > doesn't provide dma_cache_sync() is wrong, since at worst it may break > other drivers. If downstream is wildly misusing an API then so be it, > but it's hardly a strong basis for an upstream argument. I guess it means that we're wildly misusing the API, but it still does work. Could you explain how it could break other drivers? > > >> Also, I posit that videobuf2 is not actually relying on > >> DMA_ATTR_NON_CONSISTENT anyway, since it's clearly not using it properly: > >> > >> "By using this API, you are guaranteeing to the platform > >> that you have all the correct and necessary sync points for this memory > >> in the driver should it choose to return non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also always > been wrong per the API, regardless of the bodies of code that have > happened to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I pointed to, but that might of course be my misunderstanding. > i.e. this series - not encouraging mixing the existing APIs. It doesn't > seem impossible to implement a remapping version of this new > dma_alloc_pages() for IOMMU-backed ops if it's really warranted > (although at that point it seems like "non-coherent" vb2-dc starts to > have significant conceptual overlap with vb2-sg). No, there is no overlap between vb2-dc and vb2-sg. They differ on another level - the former is to be used by devices without scatter-gather or internal mapping capabilities and gives the driver a single DMA address for the whole buffer, regardless of whether it's IOVA-contiguous (for devices behind an IOMMU) or physically contiguous (for the others), while the latter gives the driver an sgtable, which of course may be DMA-contiguous internally, but doesn't have to and usually isn't. This model makes it possible to hide the SoC implementation details from particular drivers, since those are very often reused on many SoCs which differ in the availability of IOMMU, DMA addressing restrictions and so on. Best regards, Tomasz