LKML Archive on
help / color / mirror / Atom feed
From: Stefan Richter <>
To: "Kristian Høgsberg" <>
Cc: Pete Zaitcev <>,
Subject: Re: Juju
Date: Fri, 26 Jan 2007 12:30:08 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Kristian Høgsberg wrote:
> Another thing that probably makes my explanation a little confusing is that 
> there are two types of transactions: FireWire transactions which consists of a 
>   request followed by a response and are pretty much the smallest interaction 
> you can have with a remote device.  Then there are SBP-2 transactions, which 
> are a higer level sequence layered on top of FireWire transactions.

Exactly. One SBP-2 transaction is one SCSI task's request and completion
and contains
  1. one 1394 write transaction, requested by initiator node,
  2. one 1394 read transaction, requested by the target node,
  3. zero to many 1394 read or write transactions, requested by the
     target node,
  4. one 1394 write transaction, requested by the target node
(if everything goes well and if we don't have dynamically appended ORB
lists). So it might be less confusing if we only speak of "1394
transactions" and "SCSI tasks".

BTW, SBP-3 allows to wrap step 2 into step 1. I read that some SBP-2
targets support this SBP-3 feature.

>> The target wrote an SBP-2 status block into our memory. The status block
>> contains the FireWire bus address of the ORB to which it belongs. Juju's
>> fw-sbp2 does the same as mainline's sbp2: Looking through the pile of
>> unfinished ORBs for one with the same FireWire bus address, which was
>> previously derived from the DMA mapped address.
> But the status write actually does carry the address of the ORB it signals the 
> completion of.  So in theory, we could just read out the ORB address from the 
> status write packet and map that back to kernel virtual memory

"Map back to virtual memory" is exactly what we do already, although in
a rather dumb fashion. It would be easier if there was a portable
bus_to_virt() which would do the job for us. This is much more of an
issue if we want to work without OHCI-1394 physical DMA: Then we have to
do this inverse DMA mapping also for arbitrary pieces of all scatter
gather elements of the SCSI data buffer.

> One thing I want to do (though very low priority) is to allocate the ORBs out 
> of a preallocated circular buffer.

Incidentally, one thing I want to do (though at low priority) is to use
a circular ORB buffer... Well, linux1394 has a number of more serious
issues pending at, and meanwhile people are eager to
run things like FreeBob or Kino on Juju --- thus it remains to be seen
who of us gets to it first. :-)
Stefan Richter
-=====-=-=== ---= ==-=-

  reply	other threads:[~2007-01-26 11:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25  6:37 Juju Pete Zaitcev
2007-01-25 17:13 ` Juju Stefan Richter
2007-01-25 21:18 ` Juju Kristian Høgsberg
2007-01-25 23:38   ` Juju Pete Zaitcev
2007-01-26  2:35     ` Juju Stefan Richter
2007-01-26  4:01       ` Juju Kristian Høgsberg
2007-01-26 11:30         ` Stefan Richter [this message]
2007-01-26  4:47       ` Juju Pete Zaitcev
2007-01-26 10:53         ` Juju Stefan Richter
2007-01-26  6:47     ` Juju Greg KH
2007-01-26 19:51       ` Juju Kristian Høgsberg
2007-01-29  0:13   ` Juju Pete Zaitcev
2007-01-29 19:53     ` Juju Kristian Høgsberg
2007-01-29 20:22       ` Juju Pete Zaitcev

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: Juju' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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