From: "Robert Crocombe" <rcrocomb@gmail.com>
To: "Stefan Richter" <stefanr@s5r6.in-berlin.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux1394-devel <linux1394-devel@lists.sourceforge.net>
Subject: Re: ieee1394: host adapter disappears on 1394 bus reset
Date: Tue, 28 Nov 2006 12:07:08 -0700 [thread overview]
Message-ID: <e6babb600611281107j2f03d5a7ld0214b2e82b305b8@mail.gmail.com> (raw)
In-Reply-To: <456B680D.2000703@s5r6.in-berlin.de>
On 11/27/06, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Posted writes are still enabled. phys_dma=0 disables only the physical
> response unit. You have to change the source if you want to disable
> posted writes. See the top of ohci_initialize. Should this be a module
> load parameter too?
Er. I misspoke. What I need is for write requests directed to
address 0 to be directed to the asynchronous unit so that I can treat
them as regular asynchronous write requests. As the OHCI 1.1 spec
says:
"Physical requests that are rejected by the PhysicalRequestFilter
shall be sent to the AR Request DMA context if the AR Request DMA
context is enabled". (5.14.2, page 58)
That does appear to be happening: I have an ARM mapping set to begin
at 0 and extend some ways along, and I do receive write requests. At
first I was simply changing the lines:
reg_write(ohci,OHCI1394_PhyReqFilterHiSet, 0xffffffff);
reg_write(ohci,OHCI1394_PhyReqFilterLoSet, 0xffffffff);
to be 0x0000 0000 instead, but then I paid more attention to the
source and saw the phys_dma parameter, which does the same. .... Well,
*did*, in 2.6.16. I see that 2.6.18 doesn't write 0 if !phys_dma, it
just leaves the values alone, but I guess that's okay since they are
set to 0 on reset. Same difference.
So that's okay. Uhm, mostly. You should really see the horrors I
have created in order to be able to have 5 hosts map the same address
range (the custom protocol we're using doesn't use the destination
address at all, so it's 0 for everybody).
So long ways round, I think the phys_dma parameter is the proper thing for me.
And I will try and do some actual thinking about what is happening. I
was hoping to offload that work to you and simply perform mechanical
changes to the source! Rats!
--
Robert Crocombe
rcrocomb@gmail.com
next prev parent reply other threads:[~2006-11-28 19:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-22 15:31 Robert Crocombe
2006-11-22 21:44 ` Stefan Richter
2006-11-23 0:28 ` Robert Crocombe
2006-11-27 15:39 ` Robert Crocombe
2006-11-27 17:11 ` Stefan Richter
2006-11-27 17:46 ` Robert Crocombe
2006-11-27 18:26 ` Stefan Richter
2006-11-27 20:34 ` Robert Crocombe
2006-11-27 22:34 ` Stefan Richter
2006-11-28 19:07 ` Robert Crocombe [this message]
2006-11-28 20:14 ` Stefan Richter
2006-11-27 18:29 ` MMIO write ordering (was Re: ieee1394: host adapter disappears on 1394 bus reset) Stefan Richter
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=e6babb600611281107j2f03d5a7ld0214b2e82b305b8@mail.gmail.com \
--to=rcrocomb@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=stefanr@s5r6.in-berlin.de \
/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
all inboxes | Powered by JetHome®