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 6A49EC433E1 for ; Thu, 20 Aug 2020 11:26:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3AFB720885 for ; Thu, 20 Aug 2020 11:26:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="foA95pAM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730200AbgHTL0r (ORCPT ); Thu, 20 Aug 2020 07:26:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730659AbgHTKGM (ORCPT ); Thu, 20 Aug 2020 06:06:12 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C161C061342 for ; Thu, 20 Aug 2020 03:05:50 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id w17so1117146edt.8 for ; Thu, 20 Aug 2020 03:05: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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=foA95pAMne0k+ZduK2+JsEaA0Kd3Xk6AJeP12ZUtsQO8oCEqpY6AC2jWiQeJjjQrKA n//Z/S/hwU9sUSwrh2bpFx9EjO5w8H5vkm5cyHDHvlSF0L7E3fVBHC7P2Ym9zd8UwQZN UTTFBKoIkLT88Lc8FZLz7dV6a5Tegh0nandB0= 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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=P5F+M15aT3Wo1ztHwMrir9kxWNWo/NLz4HonmvMWmCgGW8tOpccpWIX+00svzixkm0 /b+mNtMpptRPQxKruozd8lyqf3DO1V8b94mcUIli0RvaJW2cX3lYlslHIcV+xtXtv8x0 pduEExi6yE01Vzz+QeF09Imnu37qtMCWLzur6O+vy9wEJNe1+o8c7id7r5GaVVpSd1Sp ytxXUVGxobniK+1Cr5RzIi5zNX4A5bUvZ95JfCn2YRxrprHP/qtEXZvhPDQaV3wjNjlE Q7OiLinrrri062KVVy3oE8UCKjCDf0D/Vm003L8gqWJZ/iToiMdoa1MYZo/PzXbysSc1 R0aQ== X-Gm-Message-State: AOAM532LIax0Cv0gwf4TjsM3PrHuUxKqHIH2wjO2YANetc5xswlO5VsT ke0xnD2+PjVUEt5s0RxIw2r3ZIeVGAkPGJtg X-Google-Smtp-Source: ABdhPJyPhDaxPcCdLS7kdrIbdd3HltB6jpIcnP3Toh3j4q+ROeMaWnj7fw5Rj/Exe4PMPcN3EA6Ypw== X-Received: by 2002:a05:6402:6c8:: with SMTP id n8mr2157561edy.195.1597917946962; Thu, 20 Aug 2020 03:05:46 -0700 (PDT) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id cm22sm1051886edb.44.2020.08.20.03.05.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 03:05:46 -0700 (PDT) Received: by mail-ej1-f48.google.com with SMTP id d11so728723ejt.13 for ; Thu, 20 Aug 2020 03:05:45 -0700 (PDT) X-Received: by 2002:a5d:6744:: with SMTP id l4mr2628495wrw.105.1597917944145; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <20200819135454.GA17098@lst.de> <20200820044347.GA4533@lst.de> <20200820052004.GA5305@lst.de> In-Reply-To: <20200820052004.GA5305@lst.de> From: Tomasz Figa Date: Thu, 20 Aug 2020 12:05:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Christoph Hellwig 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, 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 ," , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," 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 Thu, Aug 20, 2020 at 7:20 AM Christoph Hellwig wrote: > > On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > > > so by definition it isn't used by any of these media drivers. > > > > > > It's still an UAPI feature, so we can't simply remove the flag, it > > > must stay there as a no-op, until the problem is resolved. > > > > Ok, I'll switch to just ignoring it for the next version. > > So I took a deeper look. I don't really think it qualifies as a UAPI > in our traditional sense. For one it only appeared in 5.9-rc1, so we > can trivially expedite the patch into 5.9-rc and not actually make it > show up in any released kernel version. And even as of the current > Linus' tree the only user is a test driver. So I really think the best > way to go ahead is to just revert it ASAP as the design wasn't thought > out at all. The UAPI and V4L2/videobuf2 changes are in good shape and the only wrong part is the use of DMA API, which was based on an earlier email guidance anyway, and a change to the synchronization part . I find conclusions like the above insulting for people who put many hours into designing and implementing the related functionality, given the complexity of the videobuf2 framework and how ill-defined the DMA API was, and would feel better if such could be avoided in future communication. That said, we can revert it on the basis of the implementation issues, but I feel like we wouldn't get anything by doing so, because as I said, the design is sane and most of the implementation is fine as well. Instead. I'd suggest simply removing the use of the attribute being removed, so that the feature stays no-op until the DMA API provides a way to implement it or we just migrate videobuf2 to stop using the DMA API as much as possible, like many drivers in the DRM subsystem did. 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 8E763C433E1 for ; Thu, 20 Aug 2020 10:12:42 +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 4E54C206DA for ; Thu, 20 Aug 2020 10:12:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Lnk0v+sS"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="foA95pAM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E54C206DA 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=d2npsPOmYAFS1J8DBeg7bZSyHr3fJgmX8qgnPqVBfPU=; b=Lnk0v+sS1p4d//q6G20IQEvmX twsOtLXyX/fJP0/tQZffJ0rfvsM9o3BTHCrcMgOo0F8zLcF2/NSw01nfmYEBuMUNMD1/vOKqY01Gt t1r2PBuW2amgjpDkM4fsb+ZzL2AZ9mVV+c69TxA/ki8DBh0Zkm+sir0fgouVDJjTfzl+sEO+SyO10 XNTfkkuzpQkkivZo94f753RRApmq9NGY1srrgfjw1Tp9YdFlBOvJ/d9UW6JYo4rXIt8N51Xhgmg7O czLOIUmeNV4q3spPR2EhDEZd7zoYi/rvzUxLx1TYKFrsaayUHWQw8zd76HYgRfB/NDqEPYClmcWSt LO9Wj4eMQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8hYm-0006Sj-9H; Thu, 20 Aug 2020 10:12:40 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8hYk-0006S5-Jk for linux-nvme@lists.infradead.org; Thu, 20 Aug 2020 10:12:39 +0000 Received: by mail-ed1-x541.google.com with SMTP id cq28so1122894edb.10 for ; Thu, 20 Aug 2020 03:12:38 -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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=foA95pAMne0k+ZduK2+JsEaA0Kd3Xk6AJeP12ZUtsQO8oCEqpY6AC2jWiQeJjjQrKA n//Z/S/hwU9sUSwrh2bpFx9EjO5w8H5vkm5cyHDHvlSF0L7E3fVBHC7P2Ym9zd8UwQZN UTTFBKoIkLT88Lc8FZLz7dV6a5Tegh0nandB0= 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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=FJqf7ZjV25BUK3OyPz54y+qTnuqsTLs0pVfYXDqcIYGxHRMc29XAMmcRGVH2P1PcV0 8RueX9J/qNh3WjwB0eUHwnNa6Hd4xCDpUZ4u41b950Hhqb672I0NKUAuEtGuicB0Hd1d PYNdbUy9hvl5tvSvZzdREUnDnQcI0wVnZhA3DVgQJwsf97Z/y7CbyHdMUZ1k9a1Cl66E NWOVZqjGcGeNZKaXmVN2BZORr0fDyHGBmTPd+C+JfvzgHQk5hWRjgDBcaYopaljZvmIQ eFOVnGjf2mBiBuw8ErlAaoFi5imHENljE7sTCgnqD69OJ80ttv1aMjMKDQE3SdaJbVwi eRVA== X-Gm-Message-State: AOAM532sSiY7SWRnCHhhHWaJYTob10bvM/NsNEBtQFixB3SaI9Vf/WPL YYLGuoDTk+4FFEmDBNMDJZadhZQmqA1iCr1Q X-Google-Smtp-Source: ABdhPJyhC6atbg/ogGQ8IISZzfBzSrLplFY5VD3D5GNaS3kguYW5xOj7X0euTNwK4C47wWoBAaGBkw== X-Received: by 2002:aa7:c70b:: with SMTP id i11mr2111225edq.272.1597918357257; Thu, 20 Aug 2020 03:12:37 -0700 (PDT) Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com. [209.85.208.44]) by smtp.gmail.com with ESMTPSA id d20sm1144462ejj.10.2020.08.20.03.12.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 03:12:37 -0700 (PDT) Received: by mail-ed1-f44.google.com with SMTP id bs17so1155653edb.1 for ; Thu, 20 Aug 2020 03:12:36 -0700 (PDT) X-Received: by 2002:a5d:6744:: with SMTP id l4mr2628495wrw.105.1597917944145; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <20200819135454.GA17098@lst.de> <20200820044347.GA4533@lst.de> <20200820052004.GA5305@lst.de> In-Reply-To: <20200820052004.GA5305@lst.de> From: Tomasz Figa Date: Thu, 20 Aug 2020 12:05:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Christoph Hellwig X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200820_061238_752312_6437E828 X-CRM114-Status: GOOD ( 26.90 ) 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 Kernel Mailing List , "James E.J. Bottomley" , linux-mm@kvack.org, linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , 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-mips@vger.kernel.org, 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 Thu, Aug 20, 2020 at 7:20 AM Christoph Hellwig wrote: > > On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > > > so by definition it isn't used by any of these media drivers. > > > > > > It's still an UAPI feature, so we can't simply remove the flag, it > > > must stay there as a no-op, until the problem is resolved. > > > > Ok, I'll switch to just ignoring it for the next version. > > So I took a deeper look. I don't really think it qualifies as a UAPI > in our traditional sense. For one it only appeared in 5.9-rc1, so we > can trivially expedite the patch into 5.9-rc and not actually make it > show up in any released kernel version. And even as of the current > Linus' tree the only user is a test driver. So I really think the best > way to go ahead is to just revert it ASAP as the design wasn't thought > out at all. The UAPI and V4L2/videobuf2 changes are in good shape and the only wrong part is the use of DMA API, which was based on an earlier email guidance anyway, and a change to the synchronization part . I find conclusions like the above insulting for people who put many hours into designing and implementing the related functionality, given the complexity of the videobuf2 framework and how ill-defined the DMA API was, and would feel better if such could be avoided in future communication. That said, we can revert it on the basis of the implementation issues, but I feel like we wouldn't get anything by doing so, because as I said, the design is sane and most of the implementation is fine as well. Instead. I'd suggest simply removing the use of the attribute being removed, so that the feature stays no-op until the DMA API provides a way to implement it or we just migrate videobuf2 to stop using the DMA API as much as possible, like many drivers in the DRM subsystem did. 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 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 91656C433E1 for ; Thu, 20 Aug 2020 10:05:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C114206DA for ; Thu, 20 Aug 2020 10:05:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="foA95pAM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C114206DA 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 E0DAC8D0007; Thu, 20 Aug 2020 06:05:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC04F8D0001; Thu, 20 Aug 2020 06:05:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD4248D0007; Thu, 20 Aug 2020 06:05:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id B5EFC8D0001 for ; Thu, 20 Aug 2020 06:05:47 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 61C94180AD81A for ; Thu, 20 Aug 2020 10:05:47 +0000 (UTC) X-FDA: 77170515534.18.start89_1906eef2702f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 32748100ED3CB for ; Thu, 20 Aug 2020 10:05:47 +0000 (UTC) X-HE-Tag: start89_1906eef2702f X-Filterd-Recvd-Size: 6809 Received: from mail-ej1-f68.google.com (mail-ej1-f68.google.com [209.85.218.68]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Aug 2020 10:05:46 +0000 (UTC) Received: by mail-ej1-f68.google.com with SMTP id m22so1773541eje.10 for ; Thu, 20 Aug 2020 03:05:46 -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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=foA95pAMne0k+ZduK2+JsEaA0Kd3Xk6AJeP12ZUtsQO8oCEqpY6AC2jWiQeJjjQrKA n//Z/S/hwU9sUSwrh2bpFx9EjO5w8H5vkm5cyHDHvlSF0L7E3fVBHC7P2Ym9zd8UwQZN UTTFBKoIkLT88Lc8FZLz7dV6a5Tegh0nandB0= 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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=rteLspKE6W9sydZeuWzRbFLSFcNHJB0o1t6fS0ixKGwcOzpcJFyZsu6a6Ueh4UC35m spodHyFvH9TDo1sYJ1mUtutztQAzUU9nLvoMwQr9NbBtAty6VYXKKiDazLbFkL6qv5WH tb69+UXkbVMg0ME+yY8ON1TuUNi6TD1tX7/075lIJxNHRNzKVAU2fHlkNqxNqNkAerGV aKrt93dgdVGDGpy9R738zLKKmJHaf/4Lnut6dEEWdGCo4h6QeGvXdqY2HaxKMPC9hnHM ItCZXQGREZap0DxqhA2h9rNTBRzNI/+cCEIug1iU4FFW+jaRTno/HSSBCCr/23gWoZ2x Kf0Q== X-Gm-Message-State: AOAM5321zBrWeYxcRvzDY+j3Vfc/e1+AIqd9l9bDoAJVoMrNL3z5O7lh LfFgQSvu8ZaRD8jBtIP/ErhydUT6c06iHNSY X-Google-Smtp-Source: ABdhPJwA9o/Lo2cAW/jreAbScKbu/sdA6Ese9NRmiszuiyul9Yz0IcPDZaBHBISaVSsgZzV//DEvzQ== X-Received: by 2002:a17:907:36b:: with SMTP id rs11mr2585715ejb.544.1597917945422; Thu, 20 Aug 2020 03:05:45 -0700 (PDT) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com. [209.85.221.50]) by smtp.gmail.com with ESMTPSA id v14sm1140318ejb.63.2020.08.20.03.05.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 03:05:45 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id a5so1454153wrm.6 for ; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) X-Received: by 2002:a5d:6744:: with SMTP id l4mr2628495wrw.105.1597917944145; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <20200819135454.GA17098@lst.de> <20200820044347.GA4533@lst.de> <20200820052004.GA5305@lst.de> In-Reply-To: <20200820052004.GA5305@lst.de> From: Tomasz Figa Date: Thu, 20 Aug 2020 12:05:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Christoph Hellwig 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, 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 ," , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 32748100ED3CB 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 Thu, Aug 20, 2020 at 7:20 AM Christoph Hellwig wrote: > > On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > > > so by definition it isn't used by any of these media drivers. > > > > > > It's still an UAPI feature, so we can't simply remove the flag, it > > > must stay there as a no-op, until the problem is resolved. > > > > Ok, I'll switch to just ignoring it for the next version. > > So I took a deeper look. I don't really think it qualifies as a UAPI > in our traditional sense. For one it only appeared in 5.9-rc1, so we > can trivially expedite the patch into 5.9-rc and not actually make it > show up in any released kernel version. And even as of the current > Linus' tree the only user is a test driver. So I really think the best > way to go ahead is to just revert it ASAP as the design wasn't thought > out at all. The UAPI and V4L2/videobuf2 changes are in good shape and the only wrong part is the use of DMA API, which was based on an earlier email guidance anyway, and a change to the synchronization part . I find conclusions like the above insulting for people who put many hours into designing and implementing the related functionality, given the complexity of the videobuf2 framework and how ill-defined the DMA API was, and would feel better if such could be avoided in future communication. That said, we can revert it on the basis of the implementation issues, but I feel like we wouldn't get anything by doing so, because as I said, the design is sane and most of the implementation is fine as well. Instead. I'd suggest simply removing the use of the attribute being removed, so that the feature stays no-op until the DMA API provides a way to implement it or we just migrate videobuf2 to stop using the DMA API as much as possible, like many drivers in the DRM subsystem did. 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,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 BC5A4C433DF for ; Fri, 21 Aug 2020 07:54:26 +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 47719207DF for ; Fri, 21 Aug 2020 07:54:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="Ij6DGphW"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="foA95pAM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47719207DF 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 D07E916CC; Fri, 21 Aug 2020 09:53:34 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz D07E916CC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1597996464; bh=I9kinie5TZrj16A3H/gqR8jwrsPlhdpKSfx4hal8kO0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Ij6DGphWk0w3Bhx3SRTXbrHSIyFv2I4niI/QdxCaDr9vSrZN7RBVWps70yuqBxRu8 vjTAbix81I6X0pPVfL9ntTeDdKnVgP2cAKvlcSYXctBufVvaYXm3Wy+WVOJxvE3oNn 6mxpKk4pbXXlHF1X7LO49wp30XFybgyN0ll9HlEA= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id ACA3CF8041E; Fri, 21 Aug 2020 09:36:40 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id B3A2CF80228; Thu, 20 Aug 2020 12:05:58 +0200 (CEST) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 B5515F800C0 for ; Thu, 20 Aug 2020 12:05:47 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz B5515F800C0 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="foA95pAM" Received: by mail-ed1-x544.google.com with SMTP id di22so1105513edb.12 for ; Thu, 20 Aug 2020 03:05:47 -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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=foA95pAMne0k+ZduK2+JsEaA0Kd3Xk6AJeP12ZUtsQO8oCEqpY6AC2jWiQeJjjQrKA n//Z/S/hwU9sUSwrh2bpFx9EjO5w8H5vkm5cyHDHvlSF0L7E3fVBHC7P2Ym9zd8UwQZN UTTFBKoIkLT88Lc8FZLz7dV6a5Tegh0nandB0= 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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=OYFuce2rayXwpA0E+JlEjF3Jr5fR+hDQvPuFSB7Cm/y+2IBtoqsOVLr1mmgf6Z+pMi sDrE8aE9xA1XgRsGAH7SGQSE1UvRS5BwJcXkZJJce2jyIWw2/Q/QBWEx+K2XgCA080Fq B1ksL4xFmusCWZKP62Q51w5bJfrOcbxfxkEqnPuDdCErUdTw7ttXppWHDrScD4ud4B6b 1Nu8CjphD69GmMcL+/ur/OcV932zt0Z8E+pahPW/HnZZsXAMChu/S3atiRQtrQ2U9CG6 q2JIrdrpJSYjlrcx1T4VqdK6vD6lhlwLX+TEirzebyjff6bev3iiE428AoXo/5bpVMIi D97Q== X-Gm-Message-State: AOAM533m4vWqJNJEiB/go7sKgUJCyo/5MlmvlPSTbtv1fqswMip2ICXB /Pc/5X8D/IKcy402H+uDGNtcP3ebSbEeSN0p X-Google-Smtp-Source: ABdhPJyEZgkJSVEnKx1vNE1DrEbt70rzIDlwaUOpjLYaQt5js1yPnQFcOVBTrWZP+sbQvsdZ8Q9dlg== X-Received: by 2002:aa7:c70b:: with SMTP id i11mr2087360edq.272.1597917946363; Thu, 20 Aug 2020 03:05:46 -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 b22sm892547eje.27.2020.08.20.03.05.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 03:05:45 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id f7so1477092wrw.1 for ; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) X-Received: by 2002:a5d:6744:: with SMTP id l4mr2628495wrw.105.1597917944145; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <20200819135454.GA17098@lst.de> <20200820044347.GA4533@lst.de> <20200820052004.GA5305@lst.de> In-Reply-To: <20200820052004.GA5305@lst.de> From: Tomasz Figa Date: Thu, 20 Aug 2020 12:05:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Christoph Hellwig 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 Kernel Mailing List , "James E.J. Bottomley" , linux-mm@kvack.org, linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , 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-mips@vger.kernel.org, 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 Thu, Aug 20, 2020 at 7:20 AM Christoph Hellwig wrote: > > On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > > > so by definition it isn't used by any of these media drivers. > > > > > > It's still an UAPI feature, so we can't simply remove the flag, it > > > must stay there as a no-op, until the problem is resolved. > > > > Ok, I'll switch to just ignoring it for the next version. > > So I took a deeper look. I don't really think it qualifies as a UAPI > in our traditional sense. For one it only appeared in 5.9-rc1, so we > can trivially expedite the patch into 5.9-rc and not actually make it > show up in any released kernel version. And even as of the current > Linus' tree the only user is a test driver. So I really think the best > way to go ahead is to just revert it ASAP as the design wasn't thought > out at all. The UAPI and V4L2/videobuf2 changes are in good shape and the only wrong part is the use of DMA API, which was based on an earlier email guidance anyway, and a change to the synchronization part . I find conclusions like the above insulting for people who put many hours into designing and implementing the related functionality, given the complexity of the videobuf2 framework and how ill-defined the DMA API was, and would feel better if such could be avoided in future communication. That said, we can revert it on the basis of the implementation issues, but I feel like we wouldn't get anything by doing so, because as I said, the design is sane and most of the implementation is fine as well. Instead. I'd suggest simply removing the use of the attribute being removed, so that the feature stays no-op until the DMA API provides a way to implement it or we just migrate videobuf2 to stop using the DMA API as much as possible, like many drivers in the DRM subsystem did. 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: Thu, 20 Aug 2020 12:05:29 +0200 Message-ID: References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <20200819135454.GA17098@lst.de> <20200820044347.GA4533@lst.de> <20200820052004.GA5305@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200820052004.GA5305-jcswGhMUV9g@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Sender: "iommu" To: Christoph Hellwig Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, linux-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Doc Mailing List , nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Linux Kernel Mailing List , "James E.J. Bottomley" , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-samsung-soc , Joonyoung Shim , linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS , Joerg Roedel , " , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS wrote: > > On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > > > so by definition it isn't used by any of these media drivers. > > > > > > It's still an UAPI feature, so we can't simply remove the flag, it > > > must stay there as a no-op, until the problem is resolved. > > > > Ok, I'll switch to just ignoring it for the next version. > > So I took a deeper look. I don't really think it qualifies as a UAPI > in our traditional sense. For one it only appeared in 5.9-rc1, so we > can trivially expedite the patch into 5.9-rc and not actually make it > show up in any released kernel version. And even as of the current > Linus' tree the only user is a test driver. So I really think the best > way to go ahead is to just revert it ASAP as the design wasn't thought > out at all. The UAPI and V4L2/videobuf2 changes are in good shape and the only wrong part is the use of DMA API, which was based on an earlier email guidance anyway, and a change to the synchronization part . I find conclusions like the above insulting for people who put many hours into designing and implementing the related functionality, given the complexity of the videobuf2 framework and how ill-defined the DMA API was, and would feel better if such could be avoided in future communication. That said, we can revert it on the basis of the implementation issues, but I feel like we wouldn't get anything by doing so, because as I said, the design is sane and most of the implementation is fine as well. Instead. I'd suggest simply removing the use of the attribute being removed, so that the feature stays no-op until the DMA API provides a way to implement it or we just migrate videobuf2 to stop using the DMA API as much as possible, like many drivers in the DRM subsystem did. 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 73EDFC433E1 for ; Thu, 20 Aug 2020 10:05: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 402702078D for ; Thu, 20 Aug 2020 10:05: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="foA95pAM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 402702078D 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 D8745875AE; Thu, 20 Aug 2020 10:05:54 +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 s11TN+kOYBZ8; Thu, 20 Aug 2020 10:05:53 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by whitealder.osuosl.org (Postfix) with ESMTP id D34AA86E6A; Thu, 20 Aug 2020 10:05:53 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9A59BC0889; Thu, 20 Aug 2020 10:05:53 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 23505C0051 for ; Thu, 20 Aug 2020 10:05:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0D2828685B for ; Thu, 20 Aug 2020 10:05:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNfo1xO0JP1F for ; Thu, 20 Aug 2020 10:05:49 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 0D3FD86813 for ; Thu, 20 Aug 2020 10:05:49 +0000 (UTC) Received: by mail-ej1-f66.google.com with SMTP id f24so1801997ejx.6 for ; Thu, 20 Aug 2020 03:05: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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=foA95pAMne0k+ZduK2+JsEaA0Kd3Xk6AJeP12ZUtsQO8oCEqpY6AC2jWiQeJjjQrKA n//Z/S/hwU9sUSwrh2bpFx9EjO5w8H5vkm5cyHDHvlSF0L7E3fVBHC7P2Ym9zd8UwQZN UTTFBKoIkLT88Lc8FZLz7dV6a5Tegh0nandB0= 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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=uMJRclur8RgSqIH4C03dhdlAAMxY9gPopT6j4g1OEmeP2TokZ6IlVqQpOqsG/YseYd g/qnDJWsr4RZxQHS0+T1Lnf5KgkYpkCPcF0vTshHGmpWgsKagnUQ9jSgnYV/cgimLz4e KS7HkL/CMhF7JXe2cbu80o129KTcSx1JtssGWFqi54AdyHowdED1yhFLJWttEvlALWxS rT4Ml0KwpzXb8WIPYZ4n4zjcsZL3WW5JjiF4egLFfvQMoWnVC5EleTm0BKM6Y3b13U0+ UXSNDF+3vI500Ufhg6gwfxJP5C53s8R+8PGAAvH5bHQ5rlzu8xpRMSuzhFBPpUAXIH3T qO7w== X-Gm-Message-State: AOAM532dHjDYTI4/NypVxyI3trP2D5QAXWmvE96Wzc3qoETp/5xcWvf9 +wYchdWmEEoDLg0A7VRocFaZQDKF4VSJ1PHV X-Google-Smtp-Source: ABdhPJxpeSrWaW2smykdfFDnz63GzM68xXDnNOYl7j9adL3KqgETga3BCMUvcbcOLXHKsWXscrscaw== X-Received: by 2002:a17:906:8490:: with SMTP id m16mr2515761ejx.132.1597917947028; Thu, 20 Aug 2020 03:05:47 -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 e13sm1025642eds.46.2020.08.20.03.05.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 03:05:46 -0700 (PDT) Received: by mail-wr1-f42.google.com with SMTP id z18so1417375wrm.12 for ; Thu, 20 Aug 2020 03:05:45 -0700 (PDT) X-Received: by 2002:a5d:6744:: with SMTP id l4mr2628495wrw.105.1597917944145; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <20200819135454.GA17098@lst.de> <20200820044347.GA4533@lst.de> <20200820052004.GA5305@lst.de> In-Reply-To: <20200820052004.GA5305@lst.de> From: Tomasz Figa Date: Thu, 20 Aug 2020 12:05:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Christoph Hellwig 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 Kernel Mailing List , "James E.J. Bottomley" , linux-mm@kvack.org, linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , 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-mips@vger.kernel.org, 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 Thu, Aug 20, 2020 at 7:20 AM Christoph Hellwig wrote: > > On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > > > so by definition it isn't used by any of these media drivers. > > > > > > It's still an UAPI feature, so we can't simply remove the flag, it > > > must stay there as a no-op, until the problem is resolved. > > > > Ok, I'll switch to just ignoring it for the next version. > > So I took a deeper look. I don't really think it qualifies as a UAPI > in our traditional sense. For one it only appeared in 5.9-rc1, so we > can trivially expedite the patch into 5.9-rc and not actually make it > show up in any released kernel version. And even as of the current > Linus' tree the only user is a test driver. So I really think the best > way to go ahead is to just revert it ASAP as the design wasn't thought > out at all. The UAPI and V4L2/videobuf2 changes are in good shape and the only wrong part is the use of DMA API, which was based on an earlier email guidance anyway, and a change to the synchronization part . I find conclusions like the above insulting for people who put many hours into designing and implementing the related functionality, given the complexity of the videobuf2 framework and how ill-defined the DMA API was, and would feel better if such could be avoided in future communication. That said, we can revert it on the basis of the implementation issues, but I feel like we wouldn't get anything by doing so, because as I said, the design is sane and most of the implementation is fine as well. Instead. I'd suggest simply removing the use of the attribute being removed, so that the feature stays no-op until the DMA API provides a way to implement it or we just migrate videobuf2 to stop using the DMA API as much as possible, like many drivers in the DRM subsystem did. 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 DD82EC433E1 for ; Thu, 20 Aug 2020 10:07:08 +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 AC56C20738 for ; Thu, 20 Aug 2020 10:07:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yXqjI7o9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="foA95pAM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC56C20738 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=vUnrI1BXCSNEL4pvLOUSU3GZy82MEyENhAwodkKkXHY=; b=yXqjI7o9qEImgBWJkWW4W7+3P dvwWfi2u/QMLhnQF9LvdW1a5rx2SmJq0wdZs2gjM9T6XPqrltFUoEQ/JCrpBUKh13b33k5xJIVcBL zZzPKZjePTuwmw3F83DrlGVvDSdN+m9ZH2olb2dFmPeVsnMr0Ko+cqKqki6nrAeyMP9zMCjYk4Ikb AD2XAb0NV/ufe0K5k2Cv3mxfDwO8tbB+10h+TnWpG9zZ+YMRgE2GqQ+QwXIDmPVqaN/RewZ5jbxHX 8vkWhHVYtcPhfveoY/GXZSN7cot+2aWQZUp3AiE+iv2qoXoKNrBStAMGJM9JzR4cwqdJhXdR06WUB kKnxoHEOg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8hSB-000468-NV; Thu, 20 Aug 2020 10:05:51 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8hS7-00044L-T4 for linux-arm-kernel@lists.infradead.org; Thu, 20 Aug 2020 10:05:49 +0000 Received: by mail-ed1-x542.google.com with SMTP id i26so1130802edv.4 for ; Thu, 20 Aug 2020 03:05:47 -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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=foA95pAMne0k+ZduK2+JsEaA0Kd3Xk6AJeP12ZUtsQO8oCEqpY6AC2jWiQeJjjQrKA n//Z/S/hwU9sUSwrh2bpFx9EjO5w8H5vkm5cyHDHvlSF0L7E3fVBHC7P2Ym9zd8UwQZN UTTFBKoIkLT88Lc8FZLz7dV6a5Tegh0nandB0= 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=Pbe+IJf4ZBxt6yUxRRrQR1l3UQTW2eLx6AT4PE1gQKg=; b=BJmE3tOy3jVQ7DTadZ47AN/MI76mmYOs5DBdjpxUlOo4e2NBL8jPEsPixS3NK+tKEb lvzVTPWNf83mNB5ZxL3rJcLzF/TvTBiCU7vRA/8at+NQ8DtnBgQFq3HkybkjdJ0vGktz X3VpgRdRe5/kvpKJotrnbpxmegUlu5AisrWKFC7ejY735seimigZkg6DlIkxRbDTVmqu BxmWsl8mDFOyFsTDvDCwmu5u2E8W2yhlkk/IIxdprGfR0/vTbSyTk5U0ViHZWXrnUfhb YmAfH7QdL2Z7bp0TIh8PdxuhrUdqRLkBgQygSB7/t9W4JZm3L20ah+4+U7sy7rZc5UgP FA7A== X-Gm-Message-State: AOAM533CK6maSq7myCDPlV2PfEvTOFgRI1cnGY6HATu9rc/sy1Kr7cp1 MfJxtHc+1WgkKtDeTgoSh3kpPpw1de24WmCN X-Google-Smtp-Source: ABdhPJy3Wb25GraJ+s1IqSxRzkIMKGEW6ZzBoJBorSgbzLaYH2Ya/47QZ58DQ/czTjcPyLnU2i0wrQ== X-Received: by 2002:a05:6402:3196:: with SMTP id di22mr2055767edb.193.1597917945950; Thu, 20 Aug 2020 03:05:45 -0700 (PDT) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com. [209.85.221.50]) by smtp.gmail.com with ESMTPSA id m13sm1037064eds.10.2020.08.20.03.05.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 03:05:45 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id r4so1433488wrx.9 for ; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) X-Received: by 2002:a5d:6744:: with SMTP id l4mr2628495wrw.105.1597917944145; Thu, 20 Aug 2020 03:05:44 -0700 (PDT) MIME-Version: 1.0 References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-6-hch@lst.de> <20200819135454.GA17098@lst.de> <20200820044347.GA4533@lst.de> <20200820052004.GA5305@lst.de> In-Reply-To: <20200820052004.GA5305@lst.de> From: Tomasz Figa Date: Thu, 20 Aug 2020 12:05:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT To: Christoph Hellwig X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200820_060548_011544_1BBB82C3 X-CRM114-Status: GOOD ( 26.51 ) 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 Kernel Mailing List , "James E.J. Bottomley" , linux-mm@kvack.org, linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , 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-mips@vger.kernel.org, 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 Thu, Aug 20, 2020 at 7:20 AM Christoph Hellwig wrote: > > On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > > > so by definition it isn't used by any of these media drivers. > > > > > > It's still an UAPI feature, so we can't simply remove the flag, it > > > must stay there as a no-op, until the problem is resolved. > > > > Ok, I'll switch to just ignoring it for the next version. > > So I took a deeper look. I don't really think it qualifies as a UAPI > in our traditional sense. For one it only appeared in 5.9-rc1, so we > can trivially expedite the patch into 5.9-rc and not actually make it > show up in any released kernel version. And even as of the current > Linus' tree the only user is a test driver. So I really think the best > way to go ahead is to just revert it ASAP as the design wasn't thought > out at all. The UAPI and V4L2/videobuf2 changes are in good shape and the only wrong part is the use of DMA API, which was based on an earlier email guidance anyway, and a change to the synchronization part . I find conclusions like the above insulting for people who put many hours into designing and implementing the related functionality, given the complexity of the videobuf2 framework and how ill-defined the DMA API was, and would feel better if such could be avoided in future communication. That said, we can revert it on the basis of the implementation issues, but I feel like we wouldn't get anything by doing so, because as I said, the design is sane and most of the implementation is fine as well. Instead. I'd suggest simply removing the use of the attribute being removed, so that the feature stays no-op until the DMA API provides a way to implement it or we just migrate videobuf2 to stop using the DMA API as much as possible, like many drivers in the DRM subsystem did. 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: Thu, 20 Aug 2020 10:05: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> <20200819135454.GA17098@lst.de> <20200820044347.GA4533@lst.de> <20200820052004.GA5305@lst.de> In-Reply-To: <20200820052004.GA5305@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Christoph Hellwig 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, 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 ," , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," On Thu, Aug 20, 2020 at 7:20 AM Christoph Hellwig wrote: > > On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > > > so by definition it isn't used by any of these media drivers. > > > > > > It's still an UAPI feature, so we can't simply remove the flag, it > > > must stay there as a no-op, until the problem is resolved. > > > > Ok, I'll switch to just ignoring it for the next version. > > So I took a deeper look. I don't really think it qualifies as a UAPI > in our traditional sense. For one it only appeared in 5.9-rc1, so we > can trivially expedite the patch into 5.9-rc and not actually make it > show up in any released kernel version. And even as of the current > Linus' tree the only user is a test driver. So I really think the best > way to go ahead is to just revert it ASAP as the design wasn't thought > out at all. The UAPI and V4L2/videobuf2 changes are in good shape and the only wrong part is the use of DMA API, which was based on an earlier email guidance anyway, and a change to the synchronization part . I find conclusions like the above insulting for people who put many hours into designing and implementing the related functionality, given the complexity of the videobuf2 framework and how ill-defined the DMA API was, and would feel better if such could be avoided in future communication. That said, we can revert it on the basis of the implementation issues, but I feel like we wouldn't get anything by doing so, because as I said, the design is sane and most of the implementation is fine as well. Instead. I'd suggest simply removing the use of the attribute being removed, so that the feature stays no-op until the DMA API provides a way to implement it or we just migrate videobuf2 to stop using the DMA API as much as possible, like many drivers in the DRM subsystem did. Best regards, Tomasz