From owner-freebsd-drivers@FreeBSD.ORG Thu Jun 12 01:01:27 2008 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8607B1065678 for ; Thu, 12 Jun 2008 01:01:27 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 35CAA8FC1C for ; Thu, 12 Jun 2008 01:01:26 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1701857ywe.13 for ; Wed, 11 Jun 2008 18:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=u5lxJbYpV/5kAUPT7Te8CVXo+JMqFlELKbVS4a0qxqo=; b=G3Jw3gHEFETnRyNZkbiJUyBmrSTWRon0LuSkqixrDFPeVS61Nti3rJdrn7BOVjvi8b tdzhfLAYdVIT6ZskEL9EvaAGjKA6iIPXM9ZeFkAwhiZBPt6x08LocC4+56gJBuQAqKxq U1yL0cyk082ZIzmljZT1uXPokGiRMcOl7taUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=E0aiHjqpFoiwWInQPTyNX7ahBB30bxbUtv/9wBqhS2ARNYCT2cb6R5+n9dsUxenafJ iEhDPW9yIYp3/euU4NO9zhy6M2ohEL8iNZLK9668QcCvF6HrGj7wJRR017rZZb3YGjDh cDury74c05emUFBD1vN4ZWn5LCvIVm7BWt1FI= Received: by 10.150.202.3 with SMTP id z3mr1232219ybf.224.1213232482565; Wed, 11 Jun 2008 18:01:22 -0700 (PDT) Received: from ?192.168.0.137? ( [24.174.5.175]) by mx.google.com with ESMTPS id i27sm1051562elf.11.2008.06.11.18.01.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Jun 2008 18:01:15 -0700 (PDT) From: Jason Harmening To: John-Mark Gurney Date: Wed, 11 Jun 2008 20:03:42 -0500 User-Agent: KMail/1.9.7 References: <200806072341.17041.jason.harmening@gmail.com> <20080611182632.GT3767@funkthat.com> In-Reply-To: <20080611182632.GT3767@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806112003.43326.jason.harmening@gmail.com> Cc: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: bus_dmamem_alloc X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2008 01:01:27 -0000 On Wednesday 11 June 2008, John-Mark Gurney wrote: > > Why not use the SRAM for this? That's what my driver does... w/ 32k > SRAM, it's more than enough for more programs... The DMA programs (or at least a significant chunk of them) will get stored in the SRAM, if there's enough room. That's often the case with just MPEG TS, but once you add analog video there's usually not enough room. > > > For case 1), I malloc(9) the buffers and then feed them to busdma, since > > on most machines bus_dmamem_alloc just calls contigmalloc. Use of > > malloc(9) is suboptimal as it may result in bounce buffering for > > non-IOMMU machines with large amounts of RAM. > > I prefer to do direct to use DMA as it saves on allocating a buffer in > the kernel, and then coping the data from that buffer... The driver actually supports both. Kernel-mode buffers are mmap'ed, so there shouldn't be a copy. Of course user-mode buffers can still bounce... > > 1) Would it be possible to provide a bus_dmamem_alloc overload that > > takes a size parameter? We could call it bus_dmamem_alloc_size and have > > bus_dmamem_alloc just call bus_dmamem_alloc_size with dmat->maxsize to > > preserve source-level compatibility with existing drivers. > > It would be nice, but hasn't been something someone has gotten around to > implementing yet... That's probably my only real complaint here--it seems like dmat->maxsize should just be a restriction, not an allocation unit. I don't want to sound ungrateful--busdma, at an API level at least, is great compared to what other OSes have to offer. > > I know that one person recently was working on Intel's VT IOMMU and I > thought it was close to being committed, but I haven't been following > the work... That'll be awesome when it's ready.