linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* sbp2 address space
@ 2006-01-07 12:07 Stefan Richter
  2006-01-09 21:41 ` Stefan Richter
  0 siblings, 1 reply; 3+ messages in thread
From: Stefan Richter @ 2006-01-07 12:07 UTC (permalink / raw)
  To: linux1394-devel; +Cc: linux-kernel

Hi all,

sbp2 currently puts its status FIFO at the address range of 
0xfffe_0000_0000 ... 0xfffe_0000_0220 (FireWire bus addresses, i.e. 
addresses according to ISO/IEC 13213). This range must not fall into the 
"physical range" of OHCI host adapters (OHCI 1.1 figure 1-2, see also 
OHCI 1.1 sections 12 and 5.15).

Most OHCI implementations hardwire the physical range to 
0x0000_0000_0000 ... 0x0000_ffff_ffff. A few however implement a 
writable PhysicalUpperBound register. Ohci1394 sets this register to the 
maximum allowed value which extends the physical range to 
0x0000_0000_0000 ... 0xfffe_ffff_ffff.

Sbp2 has never worked with the latter kind of host adapters, except if 
physical DMA was disabled. Else sbp2 always ended up in an alleged login 
timeout. http://marc.theaimsgroup.com/?t=113639033500002

What is the solution?
  - Modify ohci1394 to keep the physical range below sbp2's status FIFO?
Or
  - move sbp2's status FIFO into the "upper address space" (OHCI 1.1
    figure 1-2), between 0xffff_0000_0000 and the CSR space, i.e. below
    0xffff_f000_0000?

Are any FireWire protocols or important application programs already 
using the upper address space? If we move sbp2's status FIFO, we don't 
want to break other software. No other 1394 high-level driver is using 
the upper address space. Oracle's Endpoint (SBP-2 target) seems not to 
use it either. What about applications like AV/C "targets"?

Or is it better to leave sbp2 as it is but restrict ohci1394 to use the 
same physical range on _all_ controllers, i.e. 0x0000_0000_0000 ... 
0x0000_ffff_ffff == 4 GB?

Does PCIe provide a bigger host bus address space than PCI?
-- 
Stefan Richter
-=====-=-==- ---= --===
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: sbp2 address space
  2006-01-07 12:07 sbp2 address space Stefan Richter
@ 2006-01-09 21:41 ` Stefan Richter
  2006-01-14 22:12   ` Randy.Dunlap
  0 siblings, 1 reply; 3+ messages in thread
From: Stefan Richter @ 2006-01-09 21:41 UTC (permalink / raw)
  To: linux1394-devel; +Cc: linux-kernel

I wrote:
> Does PCIe provide a bigger host bus address space than PCI?

PCIe obviously supports 64bit addressing. Do newer revisions of 
conventional PCI support more than 32bit addressing? What about PCI-X? TIA.

[sbp2 depends on a <= 32bit address space of the host bus. Single-chip 
FireWire PCIe adapters are available now but I believe they are merely 
based on a PCI FireWire link layer controller plus PCI-PCIe bridge.]
-- 
Stefan Richter
-=====-=-==- ---= -=--=
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: sbp2 address space
  2006-01-09 21:41 ` Stefan Richter
@ 2006-01-14 22:12   ` Randy.Dunlap
  0 siblings, 0 replies; 3+ messages in thread
From: Randy.Dunlap @ 2006-01-14 22:12 UTC (permalink / raw)
  To: Stefan Richter; +Cc: linux1394-devel, linux-kernel

On Mon, 09 Jan 2006 22:41:45 +0100 Stefan Richter wrote:

> I wrote:
> > Does PCIe provide a bigger host bus address space than PCI?
> 
> PCIe obviously supports 64bit addressing. Do newer revisions of 
> conventional PCI support more than 32bit addressing? What about PCI-X? TIA.

PCI-X allows 32-bit or 64-bit transfers.
IIRC, PCI conventional supports 64-bit by "DAC" == dual-address cycle,
basically 2 32-bit transfers.

> [sbp2 depends on a <= 32bit address space of the host bus. Single-chip 
> FireWire PCIe adapters are available now but I believe they are merely 
> based on a PCI FireWire link layer controller plus PCI-PCIe bridge.]

The PCI specs cost money, else we could just download and read them.  :(

Google found some hits, mostly marketing-speak, and this
1394b PCI-64bit host controller:
  http://tekgems.com/Products/MJ-FW-PCI-13.htm

---
~Randy

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-01-14 22:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-07 12:07 sbp2 address space Stefan Richter
2006-01-09 21:41 ` Stefan Richter
2006-01-14 22:12   ` Randy.Dunlap

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).