Re: correct use of bus_dmamap_sync
From: Dinesh Nair (dinesh_at_alphaque.com)
Date: 10/26/05
- Previous message: Chrystian Lopez: "usb umass"
- In reply to: John Baldwin: "Re: correct use of bus_dmamap_sync"
- Next in thread: John Baldwin: "Re: correct use of bus_dmamap_sync"
- Reply: John Baldwin: "Re: correct use of bus_dmamap_sync"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 26 Oct 2005 14:13:11 +0800 To: John Baldwin <jhb@freebsd.org>
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_XXXX 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_sync&apropos=0&sektion=0&manpath=FreeBSD+6.0-current&format=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." dinesh@alphaque.com (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 "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Chrystian Lopez: "usb umass"
- In reply to: John Baldwin: "Re: correct use of bus_dmamap_sync"
- Next in thread: John Baldwin: "Re: correct use of bus_dmamap_sync"
- Reply: John Baldwin: "Re: correct use of bus_dmamap_sync"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
