From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH v2 1/4] dma-mapping: Add devm_ interface for dma_map_single() Date: Wed, 4 Jun 2014 16:12:11 +0200 Message-ID: <20140604141211.GC23880@8bytes.org> References: <1401606077-1739-1-git-send-email-eli.billauer@gmail.com> <1401606077-1739-2-git-send-email-eli.billauer@gmail.com> <538E3D04.9060808@samsung.com> <20140603233907.GB23880@8bytes.org> <20140604140408.GC5004@htj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20140604140408.GC5004-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Tejun Heo Cc: devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org, Shuah Khan , discuss-Wa75r+71Mmgdnm+yROfE0A@public.gmane.org, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, Eli Billauer , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org List-Id: iommu@lists.linux-foundation.org On Wed, Jun 04, 2014 at 10:04:08AM -0400, Tejun Heo wrote: > Hmmm? Don't we have drivers which map dma buffers on device init and > release them on exit? For dynamic usages, its usefulness is limited > especially given that dynamic tracking of buffers usually would > involve tracking of other information too in addition to dma buffer > pointer themselves. If alloc on init and free on exit is a very rare > usage pattern, I have no objection against not adding devm interface > for dma mappings. Yes, but those drivers usually get DMA buffers at init time with the dma_alloc_* interfaces. The dma_map_* interfaces discussed here belong to the streaming DMA-API, so they are usually used for only one DMA transaction before dma_unmap_* is called on them. A devm interface for the dma_alloc_* family of functions would actually make sense, but not for the dma_map_* functions. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 8bytes.org ([85.214.48.195]:50181 "EHLO mail.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751508AbaFDOMQ (ORCPT ); Wed, 4 Jun 2014 10:12:16 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.8bytes.org (Postfix) with SMTP id 247D512B2B2 for ; Wed, 4 Jun 2014 16:12:14 +0200 (CEST) Date: Wed, 4 Jun 2014 16:12:11 +0200 From: Joerg Roedel To: Tejun Heo Cc: Shuah Khan , Eli Billauer , devel@driverdev.osuosl.org, gregkh@linuxfoundation.org, bhelgaas@google.com, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org, discuss@x86-64.org Subject: Re: [PATCH v2 1/4] dma-mapping: Add devm_ interface for dma_map_single() Message-ID: <20140604141211.GC23880@8bytes.org> References: <1401606077-1739-1-git-send-email-eli.billauer@gmail.com> <1401606077-1739-2-git-send-email-eli.billauer@gmail.com> <538E3D04.9060808@samsung.com> <20140603233907.GB23880@8bytes.org> <20140604140408.GC5004@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20140604140408.GC5004@htj.dyndns.org> Sender: linux-pci-owner@vger.kernel.org List-ID: On Wed, Jun 04, 2014 at 10:04:08AM -0400, Tejun Heo wrote: > Hmmm? Don't we have drivers which map dma buffers on device init and > release them on exit? For dynamic usages, its usefulness is limited > especially given that dynamic tracking of buffers usually would > involve tracking of other information too in addition to dma buffer > pointer themselves. If alloc on init and free on exit is a very rare > usage pattern, I have no objection against not adding devm interface > for dma mappings. Yes, but those drivers usually get DMA buffers at init time with the dma_alloc_* interfaces. The dma_map_* interfaces discussed here belong to the streaming DMA-API, so they are usually used for only one DMA transaction before dma_unmap_* is called on them. A devm interface for the dma_alloc_* family of functions would actually make sense, but not for the dma_map_* functions. Joerg