Date: Fri, 30 Jan 2015 21:07:52 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Wrapper API for static bus_dma allocations Message-ID: <21F3F28E-DAB8-4809-A9ED-1095F6BECCFC@bsdimp.com> In-Reply-To: <1440008.gcoNUU8dV6@ralph.baldwin.cx> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <54CB9B9F.50905@FreeBSD.org> <20150130152150.GX42409@kib.kiev.ua> <1440008.gcoNUU8dV6@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 30, 2015, at 2:31 PM, John Baldwin <jhb@freebsd.org> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21F3F28E-DAB8-4809-A9ED-1095F6BECCFC>