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
--pzbqGaOtRNiVr7w4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 08, 2012 at 08:51:12AM -1000, Jeff Roberson wrote: > Hello, >=20 > http://people.freebsd.org/~jeff/physbio.diff >=20 > I have a relative large patch that reforms the busdma API so that new=20 > types may be added without modifying every architecture's=20 > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer()= =20 > routines so that they may be called from MI code. The MD busdma is then= =20 > given a chance to do any final processing in the complete() callback.=20 > This patch also contains cam changes to unify the bus_dmamap_load*=20 > handling in cam drivers. >=20 > The arm and mips implementations saw the largest changes since they have= =20 > to track virtual addresses for sync(). Previously this was done in a typ= e=20 > specific way. Now it is done in a generic way by recording the list of= =20 > virtuals in the map. >=20 > I have verified that this patch passes make universe which includes=20 > several kernel builds from each architecture. I suspect that if I broke= =20 > anything your machine simply won't boot or will throw I/O errors. There= =20 > is little subtlety, it is mostly refactoring. >=20 > The next step is to allow for dma loading of physical addresses. This=20 > will permit unmapped I/O. Which is a significant performance optimizatio= n=20 > targeted for 10.0. >=20 > 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 ? --pzbqGaOtRNiVr7w4 Content-Type: application/pgp-signature -----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----- --pzbqGaOtRNiVr7w4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121222142230.GU53644>