From: Daniel Berlin <dberlin@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <linuxppc-dev@lists.linuxppc.org>
Subject: Re: u64 fun and PCI DMA not working for things behind bridges?
Date: 01 Mar 2001 10:08:01 -0500 [thread overview]
Message-ID: <m2d7c1y1bi.fsf@dynamic-addr-83-177.resnet.rochester.edu> (raw)
In-Reply-To: <19350124073426.30284@mailhost.mipsys.com> (Benjamin Herrenschmidt's message of "Thu, 1 Mar 2001 15:02:42 +0100")
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> >
> >The firewire device is behind the same bridge the GMAC is behind. Is
> >there something special I need to do to make physical dma work all the
> >time when the device you are dma'ing to/from is behind a bridge?
> >
> >It could be a hardware implementation problem in the uni-north FW, of
> >course. I'm just trying to see if anyone has ever noticed anything.
> >
> >
> >Right now i have to resort to having the SBP-2 driver emulate physical
> >dma reads/writes by telling the firewire subsystem driver to redirect
> >all reads/writes into host memory through a routine that simply does
> >memcpys.
> >I also tell the controller it's not allowed to allow physical dma
> >accesses to be performed (there are filter registers that let you
> >specify what addresses you'll allow physical dma access to, and what
> >you want to go through the normal block read/write/quadlet read/write
> >process) , and that the other side must do it through normal block
> >reads/write packets.
> >
> >This works, but it's a little slow, of course.
>
> It might be possible that we have an apple bug here... Could you try
> doing as if the device was not cache coherent ?
I'm on it.
>
> Basically, invalidate the cache for a data block that will be filled by
> the device, and flush the cache for a data block that will be read by the
> device. You can do the first one with dcbi, the second with dcbf, both
> loops followed by a "sync" instruction to make sure the ache operations
> are completed.
>
This would, of course, be much easier if i had something snooping the
1394 bus, so i could see if it's even really *trying* to do the DMA.
The thing that makes me think it is is the fact that i get random
kernel crashes right after it should be doing the DMA (IE it's
writing the wrong memory).
Let me give your idea a try.
> Ben
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
prev parent reply other threads:[~2001-03-01 15:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-01 5:32 u64 fun and PCI DMA not working for things behind bridges? Daniel Berlin
2001-03-01 12:06 ` Michael Schmitz
2001-03-01 14:03 ` Benjamin Herrenschmidt
2001-03-01 14:05 ` Michael Schmitz
2001-03-01 15:06 ` Daniel Berlin
2001-03-01 20:18 ` Geert Uytterhoeven
2001-03-01 14:02 ` Benjamin Herrenschmidt
2001-03-01 15:08 ` Daniel Berlin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2d7c1y1bi.fsf@dynamic-addr-83-177.resnet.rochester.edu \
--to=dberlin@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).