[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6babb600611281107j2f03d5a7ld0214b2e82b305b8@mail.gmail.com>
Date: Tue, 28 Nov 2006 12:07:08 -0700
From: "Robert Crocombe" <rcrocomb@...il.com>
To: "Stefan Richter" <stefanr@...6.in-berlin.de>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
linux1394-devel <linux1394-devel@...ts.sourceforge.net>
Subject: Re: ieee1394: host adapter disappears on 1394 bus reset
On 11/27/06, Stefan Richter <stefanr@...6.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@...il.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists