Re: correct use of bus_dmamap_sync
Dinesh Nair wrote: On 10/27/05 04:16 Scott Long said the following: an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in 4.x which in the syscall is actually a no op. Yes, that is fugly. Just don't use the | versions for now I would guess. Trying to maintain source compatibility between 4.x and 5.x/6.x will make you encounter a whole lot more problems than just this. could you elaborate on what busdma related problems there'd be, between 4.x and 5.x/6.x ? do, for example, the inner workings of the bus_dma* syscalls work the same on both ? I was speaking about driver code in general. For busdma specifically, the only difference is the extra arguments to bus_dma_tag_create(). Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/26/05 04:10 John Baldwin said the following: Yes, and on some archs the sync() operations do have memory barriers in place, but there isn't any bounce buffering with bus_dmamem_alloc() memory. and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c, apparently if the second argument to bus_dmamap_load (the pointer to bus_dmamap_t)) is NULL, the syscall code sets it to nobounce_dmamap, a static struct which doesnt seem to be used/allocated, except within the syscall. what would the implications of using NULL for the dmamap address be ? Well, you need it to get the physical address to pass to your device for it to do DMA against. on freebsd 4.x, vtophys(buffer) returns the same value as the this address. (i.e, when the callback function from bus_dmamap_load() is called, the address of the segment returned is the same as vtophys(buffer)). this is the current observed behaviour on 4.x. have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? I don't think so as far as the interface. the values of the BUS_DMASYNC_ constants have changed though. they're an enum with values 0-3 in 4.x but in 5.x they're defined as 0x01, 0x02, 0x04 and 0x08. due to this, combining BUS_DMASYNC_XXX thru an OR could possibly give different behaviour on 4.x and 5.x. an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in 4.x which in the syscall is actually a no op. also, in both 4.x and 5.x, only POSTREAD and PREWRITE have any real meaning, as PREREAD and POSTWRITE are no ops. it's due to these that the importance of correctly using the correct PRE/POST READ/WRITE and in the correct places seem important and the source of my confusion. :) thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). taking ruslan's suggestion, i looked up the HEAD manpage at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion=0manpath=FreeBSD+6.0-currentformat=html i've quoted the relevant descriptions below: BUS_DMASYNC_PREWRITE Perform any synchronization required after an update of memory by the CPU but prior to DMA write operations. BUS_DMASYNC_POSTREAD Perform any synchronization required after DMA read operations, but prior to CPU access of the memory. which would indicate that we'd need to use POSTREAD /before/ reading the buffer and PREWRITE /after/ the CPU writes to the buffer, for the following pseudo code: /*cpu reads from device */ bus_dmamap_sync(..., BUS_DMASYNC_POSTREAD) memcpy(myreceivebuf, mappedreceivebuf) /* do some computation on data read from device */ /* cpu writes to device */ memcpy(mappedtransmitbuf, mytransmitbuf) bus_dmamap_sync(..., BUS_DMASYNC_PREWRITE) where mappedreceivebuf and mappedtransmitbuf is the bufferspace allocated in bus_dmamem_alloc() and myreceivebuf/mytransmitbuf is a temporary holding area before writing to the device. is this reasoning correct ? -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On Wednesday 26 October 2005 02:13 am, Dinesh Nair wrote: On 10/26/05 04:10 John Baldwin said the following: Yes, and on some archs the sync() operations do have memory barriers in place, but there isn't any bounce buffering with bus_dmamem_alloc() memory. and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c, apparently if the second argument to bus_dmamap_load (the pointer to bus_dmamap_t)) is NULL, the syscall code sets it to nobounce_dmamap, a static struct which doesnt seem to be used/allocated, except within the syscall. what would the implications of using NULL for the dmamap address be ? Well, you need it to get the physical address to pass to your device for it to do DMA against. on freebsd 4.x, vtophys(buffer) returns the same value as the this address. (i.e, when the callback function from bus_dmamap_load() is called, the address of the segment returned is the same as vtophys(buffer)). this is the current observed behaviour on 4.x. On i386, yes. It won't on sparc64 when using an IOMMU for example. The whole point of using bus_dma is to not use vtophys() since by doing that you are assuming that the PA's used by the CPU map 1:1 to the addresses used by your device to do DMA, and on architectures with an IOMMU such as sparc64, G5 ppc boxes, and probably amd64 boxes in the future, that is not a valid assumption at all. have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? I don't think so as far as the interface. the values of the BUS_DMASYNC_ constants have changed though. they're an enum with values 0-3 in 4.x but in 5.x they're defined as 0x01, 0x02, 0x04 and 0x08. due to this, combining BUS_DMASYNC_XXX thru an OR could possibly give different behaviour on 4.x and 5.x. an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in 4.x which in the syscall is actually a no op. Yes, that is fugly. Just don't use the | versions for now I would guess. also, in both 4.x and 5.x, only POSTREAD and PREWRITE have any real meaning, as PREREAD and POSTWRITE are no ops. On i386, yes. Eventually those operations might be used to manipulate IOMMU mappings for example. it's due to these that the importance of correctly using the correct PRE/POST READ/WRITE and in the correct places seem important and the source of my confusion. :) thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). taking ruslan's suggestion, i looked up the HEAD manpage at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion= 0manpath=FreeBSD+6.0-currentformat=html i've quoted the relevant descriptions below: BUS_DMASYNC_PREWRITE Perform any synchronization required after an update of memory by the CPU but prior to DMA write operations. BUS_DMASYNC_POSTREAD Perform any synchronization required after DMA read operations, but prior to CPU access of the memory. which would indicate that we'd need to use POSTREAD /before/ reading the buffer and PREWRITE /after/ the CPU writes to the buffer, for the following pseudo code: /*cpu reads from device */ bus_dmamap_sync(..., BUS_DMASYNC_POSTREAD) memcpy(myreceivebuf, mappedreceivebuf) /* do some computation on data read from device */ /* cpu writes to device */ memcpy(mappedtransmitbuf, mytransmitbuf) bus_dmamap_sync(..., BUS_DMASYNC_PREWRITE) where mappedreceivebuf and mappedtransmitbuf is the bufferspace allocated in bus_dmamem_alloc() and myreceivebuf/mytransmitbuf is a temporary holding area before writing to the device. is this reasoning correct ? Yes. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/27/05 01:20 John Baldwin said the following: On i386, yes. It won't on sparc64 when using an IOMMU for example. The whole point of using bus_dma is to not use vtophys() since by doing that you are righto, so for platform portability, we'd still need to use it there though. Yes, that is fugly. Just don't use the | versions for now I would guess. which would mean than backporting stuff from 5.x would need to be double checked for | usage. is this reasoning correct ? Yes. excellent, thanx jhb. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
John Baldwin wrote: On Wednesday 26 October 2005 02:13 am, Dinesh Nair wrote: On 10/26/05 04:10 John Baldwin said the following: Yes, and on some archs the sync() operations do have memory barriers in place, but there isn't any bounce buffering with bus_dmamem_alloc() memory. and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c, apparently if the second argument to bus_dmamap_load (the pointer to bus_dmamap_t)) is NULL, the syscall code sets it to nobounce_dmamap, a static struct which doesnt seem to be used/allocated, except within the syscall. what would the implications of using NULL for the dmamap address be ? Well, you need it to get the physical address to pass to your device for it to do DMA against. on freebsd 4.x, vtophys(buffer) returns the same value as the this address. (i.e, when the callback function from bus_dmamap_load() is called, the address of the segment returned is the same as vtophys(buffer)). this is the current observed behaviour on 4.x. On i386, yes. It won't on sparc64 when using an IOMMU for example. The whole point of using bus_dma is to not use vtophys() since by doing that you are assuming that the PA's used by the CPU map 1:1 to the addresses used by your device to do DMA, and on architectures with an IOMMU such as sparc64, G5 ppc boxes, and probably amd64 boxes in the future, that is not a valid assumption at all. Well, the point of busdma is to make the DMA mechanics transparent to the driver. It's not just about IOMMUs, it's also about handling alignment constraints and address boundaries and exclusion areas. It's a set-it-and-forget-it deal. Set the requirements and constraints in the tag, follow the API, and the details Just Work without having to worry about them. have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? I don't think so as far as the interface. the values of the BUS_DMASYNC_ constants have changed though. they're an enum with values 0-3 in 4.x but in 5.x they're defined as 0x01, 0x02, 0x04 and 0x08. due to this, combining BUS_DMASYNC_XXX thru an OR could possibly give different behaviour on 4.x and 5.x. an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in 4.x which in the syscall is actually a no op. Yes, that is fugly. Just don't use the | versions for now I would guess. Trying to maintain source compatibility between 4.x and 5.x/6.x will make you encounter a whole lot more problems than just this. also, in both 4.x and 5.x, only POSTREAD and PREWRITE have any real meaning, as PREREAD and POSTWRITE are no ops. On i386, yes. Eventually those operations might be used to manipulate IOMMU mappings for example. I honestly don't ever expect to see IOMMU code for i386. The IOMMU that is provided by the AGP bus is fairly limited in what it can do, and trying to coordinate its use with X would be simply a nightmare. I'm less clear on the IOMMU that exists for amd64 and whether it's a true IOMMU or just an aliasing of the AGP IOMMU. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/27/05 04:16 Scott Long said the following: an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in 4.x which in the syscall is actually a no op. Yes, that is fugly. Just don't use the | versions for now I would guess. Trying to maintain source compatibility between 4.x and 5.x/6.x will make you encounter a whole lot more problems than just this. could you elaborate on what busdma related problems there'd be, between 4.x and 5.x/6.x ? do, for example, the inner workings of the bus_dma* syscalls work the same on both ? -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/25/05 21:15 Dinesh Nair said the following:
the pseudo code for the read and write, called during an interrupt
cycle, are:
rx_func()
{
POSITION A
while(there_is_some_data) {
memcpy(somebuf, readbuf)
}
POSITION B
}
tx_func()
{
POSITION C
while(there_is_some_data) {
memcpy(writebuf, somebuf)
}
POSITION D
}
the question is, what op should i use for bus_dmamap_sync in positions
A, B, C and D ?
responding to my own request, i mean which of BUS_DMASYNC_PREREAD,
BUS_DMASYNC_POSTREAD, BUS_DMASYNC_PREWRITE, BUS_DMASYNC_POSTWRITE should i
use, and where ?
--
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do|
| for b in clients employers associates relatives neighbours pets; do |
| echo The opinions here in no way reflect the opinions of my $a $b. |
| done; done |
+=+
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: correct use of bus_dmamap_sync
man bus_dma(9)
-Original Message-
From: Dinesh Nair [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 25, 2005 7:03 AM
To: Dinesh Nair
Cc: freebsd-hackers@freebsd.org
Subject: Re: correct use of bus_dmamap_sync
On 10/25/05 21:15 Dinesh Nair said the following:
the pseudo code for the read and write, called during an interrupt
cycle, are:
rx_func()
{
POSITION A
while(there_is_some_data) {
memcpy(somebuf, readbuf)
}
POSITION B
}
tx_func()
{
POSITION C
while(there_is_some_data) {
memcpy(writebuf, somebuf)
}
POSITION D
}
the question is, what op should i use for bus_dmamap_sync
in positions
A, B, C and D ?
responding to my own request, i mean which of
BUS_DMASYNC_PREREAD, BUS_DMASYNC_POSTREAD,
BUS_DMASYNC_PREWRITE, BUS_DMASYNC_POSTWRITE should i use, and where ?
--
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==
==
+==+
| for a in past present future; do
|
| for b in clients employers associates relatives
neighbours pets; do |
| echo The opinions here in no way reflect the opinions of
my $a $b. |
| done; done
|
+=
==
+==+
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote:
i came across this message
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.htm
l
and while it explains the use of bus_dmamap_sync, i'm still a little
confused on it's usage. i'm trying to port over a driver from freebsd 5.x
to freebsd 4.x, and it uses dma mapped addresses extensively.
i've been trying to figure out the best places to use bus_dmamap_sync when
reading/writing to a dma mapped address space. however, i cant seem to get
the gist of this, either from the mailing list discussions or the man page.
i've got two buffers, one for read, and one for write. both have been set
up with calls to bus_dma_tag_create, bus_dmamem_alloc and bus_dmamap_load.
the buffers, which are used in the calls to bus_dmamem_alloc and
bus_dmamap_load are,
int *readbuf;
int *writebuf;
(must i malloc space for them before passing them into those functions, or
will the call to bus_dmamem_alloc do it for me ?)
bus_dmamem_alloc() will do it for you.
also, i'm on FreeBSD 4.11 right now, and i notice the definitions of
BUS_DMASYNC_* has changed from an enum (0-3) in 4.x to a typedef in 5.x in
machine/bus_dma.h
the pseudo code for the read and write, called during an interrupt cycle,
are:
rx_func()
{
POSITION A
bus_dmamap_sync(PREREAD);
while(there_is_some_data) {
memcpy(somebuf, readbuf)
}
POSITION B
bus_dmamap_sync(POSTREAD);
}
tx_func()
{
POSITION C
bus_dmamap_sync(PREWRITE);
while(there_is_some_data) {
memcpy(writebuf, somebuf)
}
POSITION D
bus_dmamap_sync(POSTWRITE);
}
the question is, what op should i use for bus_dmamap_sync in positions A,
B, C and D ?
any assistance would be gladly appreciated, as i'm seeing some really weird
symptoms on this device, where data written out is being immediately read
in. i'm guessing this has to do with my wrong usage of bus_dmamap_sync().
Probably not as the sync()'s don't really do anything with memory allocated
via bus_dmamem_alloc(). The operations are named from the CPU's perspective,
thus when you send data to your device, that is a WRITE operation (even
though your device is doing a DMA to read data), and when you get data back
from your device, that is a READ operation (even though your device is doing
a DMA to write the data into the buffer).
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/26/05 01:27 John Baldwin said the following: On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote: (must i malloc space for them before passing them into those functions, or will the call to bus_dmamem_alloc do it for me ?) bus_dmamem_alloc() will do it for you. thanx. Probably not as the sync()'s don't really do anything with memory allocated via bus_dmamem_alloc(). The operations are named from the CPU's perspective, however, the man page at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion=0manpath=FreeBSD+5.4-stableformat=html says, Although no explicit loading is required to access the memory referenced by the returned map, the synchronization requirements as described in the bus_dmamap_sync() section still apply. also, is bus_dmamap_load() required, since the same man page section above says it isnt ? have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). thanx, the verbiage on the man page is slightly confusing with it's use of CPU, giving the opposite impression. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/26/05 01:02 Singh, Vijay said the following: man bus_dma(9) thanx, but that doesn't exist on freebsd 4.x. though http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion=0manpath=FreeBSD+5.4-stableformat=html has it, it still applies only to 5.x. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On Tuesday 25 October 2005 02:46 pm, Dinesh Nair wrote: On 10/26/05 01:27 John Baldwin said the following: On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote: (must i malloc space for them before passing them into those functions, or will the call to bus_dmamem_alloc do it for me ?) bus_dmamem_alloc() will do it for you. thanx. Probably not as the sync()'s don't really do anything with memory allocated via bus_dmamem_alloc(). The operations are named from the CPU's perspective, however, the man page at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion= 0manpath=FreeBSD+5.4-stableformat=html says, Although no explicit loading is required to access the memory referenced by the returned map, the synchronization requirements as described in the bus_dmamap_sync() section still apply. Yes, and on some archs the sync() operations do have memory barriers in place, but there isn't any bounce buffering with bus_dmamem_alloc() memory. also, is bus_dmamap_load() required, since the same man page section above says it isnt ? Well, you need it to get the physical address to pass to your device for it to do DMA against. have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? I don't think so as far as the interface. thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). thanx, the verbiage on the man page is slightly confusing with it's use of CPU, giving the opposite impression. Yes, I know. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On Tue, Oct 25, 2005 at 04:10:52PM -0400, John Baldwin wrote: On Tuesday 25 October 2005 02:46 pm, Dinesh Nair wrote: [...] thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). thanx, the verbiage on the man page is slightly confusing with it's use of CPU, giving the opposite impression. Yes, I know. :) Please go read the HEAD version of the manpage; it's been fixed recently to improve the description of these details. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpN3gKadHm2L.pgp Description: PGP signature
