From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 8 05:03:32 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ECC11065688 for ; Sun, 8 Jun 2008 05:03:32 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 37F5F8FC18 for ; Sun, 8 Jun 2008 05:03:32 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so846277ywe.13 for ; Sat, 07 Jun 2008 22:03:31 -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:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=RE7NIta3ZfJiTYWhwTmfI/rLOThqfn76jNeD+2IexQ0=; b=hMVUs98dZOXE7UFRfurxDDelB2UVp9d/gwcT9WuDUbODXMWIZ8YujT/micr9YZw9Ht vYWTO7i3JOHUNhuE9eGwCsiF85nv0yKuxurBJ+pRnLNNRUp3FTK+fjlruzytWss8BMQV Rtm4fxzxDWFsSsoXCOOK0Yw2oeLtimVXKWSm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=LzXFRhIwtpI4oPE3Ioh/NazjCG7Wt5fBpWruOUy4VVcWkr49VH53JF+c9pE+M+k94Q VkDL+VtkgsQupNCnxMtD5beOveCC+tNOpJcnkfFTTx0Q0MZl81pZCOGjvPbD22V5s++0 07njcsoIHPQugOkvhocr7FOSd+K29woZt7SCI= Received: by 10.150.202.8 with SMTP id z8mr3555612ybf.5.1212899926875; Sat, 07 Jun 2008 21:38:46 -0700 (PDT) Received: from ?192.168.0.137? ( [24.174.5.175]) by mx.google.com with ESMTPS id u25sm8147428ele.5.2008.06.07.21.38.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Jun 2008 21:38:46 -0700 (PDT) From: Jason Harmening To: freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org Date: Sat, 7 Jun 2008 23:41:16 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806072341.17041.jason.harmening@gmail.com> X-Mailman-Approved-At: Sun, 08 Jun 2008 05:39:00 +0000 Cc: Subject: bus_dmamem_alloc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2008 05:03:32 -0000 Hello, I've written a FreeBSD driver for Conexant CX2388x-based PCI TV capture cards. Of course the driver uses busdma to be as machine-independent as possible. One problem I've encountered is that bus_dmamem_alloc is inadequate for my needs. The CX2388x only understands 32-bit physical addreses, and the driver has two separate use cases for busdma: 1) Data buffers: These buffers may be relatively large (a 640x480 RGB32 video frame is ~1.2M), and therefore it is desirable that these buffers not be physically contiguous. 2) DMA program buffers: The DMA engine on the CX2388x is controlled by special-purpose RISC instructions, usually stored in host memory, that provide information on, among other things, the physical layout of the data buffers, which enables handling of non-contiguous data buffers. These programs are rarely more than a few pages in size, so for the sake of simplicity it is desirable that DMA program buffers be physically contiguous. 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. For case 2), I contigmalloc the DMA program buffers in the 32-bit physical address range and then feed them to busdma. I don't use bus_dmamem_alloc here because it always allocates the maximum size specified in the bus_dma_tag_t. Since the driver supports dynamic data buffer allocation and DMA program generation, DMA program sizes may vary significantly. I therefore just create the bus_dma_tag_t with the maximum possible size for a DMA program buffer since I'd prefer not to have to re-create the tag every time the DMA program size changes. But always allocating the maximum buffer size would be a huge waste of contiguous memory, so bus_dmamem_alloc is out of the question here too. At the same time, use of contigmalloc is suboptimal as it may not be necessary to restrict the allocation to 32-bit physical addresses on IOMMU-equipped machines. This is something that bus_dmamem_alloc could take care of, if only it supported a size parameter (as I believe the NetBSD version does). So I have 3 questions: 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. 2) Are there currently any serious plans to have bus_dmamem_alloc perform multi-segment allocations on non-IOMMU machines? It looks like NetBSD does this by reserving the physical segments and then stitching them together into a virtually contiguous range. Is something like this feasible for FreeBSD? 3) Are there currently any serious plans to support IOMMUs on anything besides Sun machines? The AMD AGP GART, PowerPC 970 DART, and Intel VT-d and AMD IOMMU all come to mind. If any of these ideas sound feasible, I'd be more than willing to help research/implement/test them. Thanks, Jason