Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp225402pxj; Thu, 17 Jun 2021 01:02:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmFAEpzwF5pOm40EPcWNhoLSUo+36onquSfTgW/ypogimhl0SYZQ8OK64rgOSKhn4CIgKF X-Received: by 2002:a05:6e02:1c2f:: with SMTP id m15mr462895ilh.119.1623916935826; Thu, 17 Jun 2021 01:02:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623916935; cv=none; d=google.com; s=arc-20160816; b=nZ/iKOW9mKFkGI5qipN31DJ7GskzX0qZFcedUEIwSCkpp8VbmBpSMWEduHLXI4E8Vf Fzn4gLMuQN3In5T0d18xGEOUsrAYjM6FWsxIHNyP9YelVXJe+7ZVUlT0IxEfOMaR2l3o w6dHJfBOx3Ls4+6Qbcm482O/jqoJ8f5ZqGQjmx5BYEyuBwYbPyPW6ozUKRMN/64MVyDe 93mfuSvde6KxH/zDDGKX2dDrLoxJ7oIxvu+Gcc1sn2hlADwq7EjKUelKdjPkGnNE31Db rAcRgHoyYmygsCH55V/rkWc10WjXI20fmDJTKchXGWf7YU/GsTlpSM4JS8VKzarCmg3R Jh1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=5tVrb+sugqqyiBfr1VlC5UZLAva4Gdsx/GvvtJ2DRCw=; b=pt8+Kf7z9CMOUMxkTgQYqCO5CDu3B1yIr3dSlmWjIbDtiT2445iKK+fCX1e2Lth01I 0ZoWttuaxPQK+FjOIIE+lKlO90f5IallTwRiPB2KzxxW92lDAqxhUd6lJhOEVnPnAecF Qn8i8ThsFQKTOHZ0BlsILB/cN1i3JCGV5YfywQ2K+e5qLnm4BJ1+/o+3AUWulL7IRfKc Zt3h8g92eOztzDM7plIbVWo0/wkB99VPIn9cLJ6IL3EHgyTRs09xPH7oJmRj0+IhUb40 oMngAw8njcXw7EnnHRsSsKxJjAgH289ZUa1hqHIfGT+dXpWv9iS9VZQaCMZoSbZr4UJb GEWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a21si6778978jab.23.2021.06.17.01.02.03; Thu, 17 Jun 2021 01:02:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229915AbhFQIDa (ORCPT + 99 others); Thu, 17 Jun 2021 04:03:30 -0400 Received: from verein.lst.de ([213.95.11.211]:57681 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230055AbhFQIDR (ORCPT ); Thu, 17 Jun 2021 04:03:17 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 0355768C4E; Thu, 17 Jun 2021 10:01:08 +0200 (CEST) Date: Thu, 17 Jun 2021 10:01:07 +0200 From: Christoph Hellwig To: Sergey Senozhatsky Cc: Hans Verkuil , Tomasz Figa , Ricardo Ribalda , Christoph Hellwig , Mauro Carvalho Chehab , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv2 8/8] videobuf2: handle non-contiguous DMA allocations Message-ID: <20210617080107.GA1422@lst.de> References: <20210427131344.139443-1-senozhatsky@chromium.org> <20210427131344.139443-9-senozhatsky@chromium.org> <10a0903a-e295-5cba-683a-1eb89a0804ed@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 17, 2021 at 04:56:17PM +0900, Sergey Senozhatsky wrote: > > This function can use some comments. What is happening AFAICS is that > > buf->vaddr is either set in vb2_dc_alloc_coherent (unless > > DMA_ATTR_NO_KERNEL_MAPPING was set), it is obtained through dma_buf_vmap() > > if the buffer was attached to a dma_buf, or it is allocated via > > dma_vmap_noncontiguous() for non-coherent memory. > > Yeah, it's complicated. Maybe we can make things more symmetrical. > > > But this leaves coherent memory with DMA_ATTR_NO_KERNEL_MAPPING set, what > > is vaddr in that case? I think it will call dma_vmap_noncontiguous() > > incorrectly in that case, shouldn't there be a check for !buf->coherent_mem > > before the call to dma_vmap_noncontiguous()? > > Thanks a lot for looking into it. Can we just kill off DMA_ATTR_NO_KERNEL_MAPPING in v4l now? There really is no good reason to use that with dma_alloc_noncoherent/noncontiguous available, and I plan to eventually remove that interface entirely.