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_POS
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_PREW
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_d
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
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(
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
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 yo
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
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_sync&apropos=0&sektion=0&manpath=FreeBSD+5.4-stable&format=html
has it, it still applies only to 5.x.
--
Regards,
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
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 f
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
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_
i came across this message
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.html
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 addres
14 matches
Mail list logo