Date: Sat, 22 Dec 2012 16:22:30 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Jeff Roberson <jroberson@jroberson.net> Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin <jhb@freebsd.org>, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, sparc64@freebsd.org, arm@freebsd.org Subject: Re: Call for testing and review, busdma changes Message-ID: <20121222142230.GU53644@kib.kiev.ua> In-Reply-To: <alpine.BSF.2.00.1212080841370.4081@desktop> References: <alpine.BSF.2.00.1212080841370.4081@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sat, Dec 08, 2012 at 08:51:12AM -1000, Jeff Roberson wrote: > Hello, > > http://people.freebsd.org/~jeff/physbio.diff > > I have a relative large patch that reforms the busdma API so that new > types may be added without modifying every architecture's > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > routines so that they may be called from MI code. The MD busdma is then > given a chance to do any final processing in the complete() callback. > This patch also contains cam changes to unify the bus_dmamap_load* > handling in cam drivers. > > The arm and mips implementations saw the largest changes since they have > to track virtual addresses for sync(). Previously this was done in a type > specific way. Now it is done in a generic way by recording the list of > virtuals in the map. > > I have verified that this patch passes make universe which includes > several kernel builds from each architecture. I suspect that if I broke > anything your machine simply won't boot or will throw I/O errors. There > is little subtlety, it is mostly refactoring. > > The next step is to allow for dma loading of physical addresses. This > will permit unmapped I/O. Which is a significant performance optimization > targeted for 10.0. > > Many thanks for your assistance. Any review feedback is also appreciated. I re-read the patch with the scars from the unmapped buffers work somewhat healed up, and I noted something I do not quite understand. As an example, please look at the sys/cam/ata/ata_da.c:adastart(). The code there takes bp and converts in into ccb with ataio union member used. Should this code path be converted, together with e.g. ahci_begin_transaction(), to operate on ccb instead of loading from the buffer ? The same question for ata. Was the change missed, or do you have some other plans for the drivers ? [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ1cIlAAoJEJDCuSvBvK1BFQAP/iuogDJUm1Ic80g20ZLhSz3M 9Pmb6NXMB0pFCRXy+gWMnMy/Rccf1fJlVtC8cxRxQZLJxOyur/RdrN4PTzdr4HtA gEBk2wnKtyXLTLHgKZcGhMoI62lwxgTJMXz8yK4S3DpmmA2URsLRrqgmWRw1MMdK +fKrhthaedPDFgvcJU0BwJjNoyiMod7LabqmuJr32PC2wtvAQH/sXBILk9qp1lXl xNgAhduvUF7n6d61qRELx1DVQkU3xWjVf8NiA3VqTDbCRrSrFBGdwJZKMSIyqDy/ Q2gUYegpd7QkEKzHt4u8O3sn2Um1XpC86/YfBMNMI28wDZjtijsOgx+RiykJHEiM tvTcQCS7dXo696nXEEKkw9607GU0KAKamtyIGSMz3qUE9PKTFcfR3BVoj7ikrJDq LFiODjF+wCpJ9MtIWJPjWfpVOicl7mkedu6U2HZ7ABIUltusqHZTYW2yEtJSle/e QjDPcfgGdPKtjaKSfd4bCfNqe0mLHtAThJmV/dX1Nx+43aGBmCJ8qWjDkmBJG5Uw su+KSsQ/q+T0QEvUSwDrVUaTJ7PSRctc6MnLMJcUt5VRwHJ8NArIxe6YapMNOlS6 D0MIMcsIt1B0qgvXyGYiTiF564lM0bgqAzRWcragvxYOd6cixWqNBV7qmjkdySch Ysf8ToRRocS2b92/i/8N =GTYI -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121222142230.GU53644>