From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: linux1394-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
Subject: sbp2 address space
Date: Sat, 07 Jan 2006 13:07:05 +0100 [thread overview]
Message-ID: <43BFAEE9.7090707@s5r6.in-berlin.de> (raw)
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/
next reply other threads:[~2006-01-07 12:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-07 12:07 Stefan Richter [this message]
2006-01-09 21:41 ` Stefan Richter
2006-01-14 22:12 ` Randy.Dunlap
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=43BFAEE9.7090707@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
/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®