From owner-freebsd-arch@FreeBSD.ORG Sat Jan 31 03:08:02 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69919E8D for ; Sat, 31 Jan 2015 03:08:02 +0000 (UTC) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DF33EC7 for ; Sat, 31 Jan 2015 03:08:01 +0000 (UTC) Received: by mail-oi0-f52.google.com with SMTP id h136so37566877oig.11 for ; Fri, 30 Jan 2015 19:07:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vwzMtvsayHAZcfz2TRpm2Hnsq9p9qfdIXpsCndgMEWw=; b=Imof5IVsa9S2aMAjRsCq1y2hY4Nmjn/7SQW9MaFqbwPxzgsSu20gfQ1JHaKjy2U+lV XZFVB04YSIbu7vOJLjJO1FA+X+959aH2ut5rG+KE6+eMw0Lqdy2gFD8Lh9a+9hcsvHmY goC6Vvh0I+7XSLYCrvve8Qo8o1t8zepEnbgWBj7zxuRm1r/OBR70t/KpNLucatDKP5h5 08Bhj0Mq+4or2vzjfpfcOyj6RzwLwMALMpubjCUDtmQslm2JZSQ546TTdASoNfm2OYDp sndWDFjDC19T40u8Rwq2o0V5arTYY9wfAi83SWtudkx3MAhz5Ae7OlPJDq6ZgQdZwTAx ea/w== X-Gm-Message-State: ALoCoQl7MY5OIZeSk4uv2DyAiYbjyY+LdaN8QJskOtuh1nxeGLvc8XLPdsPBvkp4MqZViDejHc9O X-Received: by 10.202.67.132 with SMTP id q126mr2812850oia.15.1422673675593; Fri, 30 Jan 2015 19:07:55 -0800 (PST) Received: from [172.16.173.216] ([12.196.110.43]) by mx.google.com with ESMTPSA id dd3sm6260141obb.23.2015.01.30.19.07.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Jan 2015 19:07:55 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Wrapper API for static bus_dma allocations From: Warner Losh In-Reply-To: <1440008.gcoNUU8dV6@ralph.baldwin.cx> Date: Fri, 30 Jan 2015 21:07:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <21F3F28E-DAB8-4809-A9ED-1095F6BECCFC@bsdimp.com> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <54CB9B9F.50905@FreeBSD.org> <20150130152150.GX42409@kib.kiev.ua> <1440008.gcoNUU8dV6@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.2070.6) Cc: Konstantin Belousov , Poul-Henning Kamp , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 03:08:02 -0000 > On Jan 30, 2015, at 2:31 PM, John Baldwin wrote: >=20 > On Friday, January 30, 2015 05:21:50 PM Konstantin Belousov wrote: >> On Fri, Jan 30, 2015 at 09:56:31AM -0500, John Baldwin wrote: >>> On 1/29/15 4:54 PM, Poul-Henning Kamp wrote: >>>> -------- >>>>=20 >>>> In message <2800970.jY4xzTy9Hz@ralph.baldwin.cx>, John Baldwin = writes: >>>>> The bus_dma API to allocate a chunk of static DMA'able memory = (e.g. for >>>>> descriptor rings) can be a bit obtuse [...] >>>>=20 >>>> Isn't it time we take a good hard stare at all of the bus_dma API, >>>> and refactor it into something a lot more compact ? >>>=20 >>> Given the amount of oddball hardware out there I don't think there = is a >>> lot you can cut out. The filter function might be something we can = lose >>> (and losing it would simplify the implementation), but all the other >>> weird constraints are actually used by something AFAIK. I do think = we >>> can provide some simpler wrappers for some of the more common cases, = but >>> there will be some hardware for which those wrappers do not work. >>>=20 >>> One suggestion Scott has had is to at least make it easier to extend = the >>> API by using getter/setter routines on the tag to work with tag >>> attributes instead of passing them all in bus_dma_tag_create(). >>=20 >> BTW, filter function is useless. It can deny specific bus address = from >> being used, but it does not provide the busdma implementation even a = hint >> what other address should be (tried to) used. In dmar busdma, I = simply >> ignored it. And there is no real users of filter in the tree. >=20 > Yes, it is very annoying. I think some old ISA SCSI HBA driver might = have=20 > used it to skip over some low-memory hole (i.e. there were two valid = DMA=20 > ranges and this was the kludge instead of having two sets of = lowaddr/highaddr=20 > exclusions). (That is one part of the API we could rototill is to = just remove=20 > the highaddr arg just use a single arg which is effectively lowaddr. = I think=20 > all drivers always set highaddr to BUS_SPACE_MAXADDR.) Not all. There=E2=80=99s some PCI cards that can=E2=80=99t do 64-bit = cycles that pass in the 32-bit value on 64-bit systems. There=E2=80=99s 386 instances of this in the = tree. But that may be lowaddr only. It=E2=80=99s hard to grep for this to be sure. Wanrer=