LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: "Kristian Høgsberg" <krh@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: Juju
Date: Fri, 26 Jan 2007 03:35:19 +0100	[thread overview]
Message-ID: <45B968E7.1070402@s5r6.in-berlin.de> (raw)
In-Reply-To: <20070125153824.8d7f50c5.zaitcev@redhat.com>

Pete Zaitcev wrote:
> On Thu, 25 Jan 2007 16:18:35 -0500, Kristian Høgsberg <krh@redhat.com> wrote:
...
>> will do a status write to the status address specified in the ORB, at which 
>> point the SBP-2 transaction is complete.
> 
> You know, I wanted to use this picture for a long time:
>  http://www.flickr.com/photos/zaitcev/369269557/

The fundamental thing about SBP-2 is that ORBs ( = SCSI command blocks
plus SBP-2 header) and data buffers all reside in the memory of the
initiator (or of a 3rd party on the FireWire bus). The target peeks and
pokes them when and how it sees fit. The initiator pushes only tiny
notifications about availability of new ORBs to the target. The target
eventually completes SCSI commands in-order or out-of-order and signals
so by pushing a status block per one or more completed commands.

(Juju's fw-sbp2 gives only one command at a time to the target.
Mainline's sbp2 can optionally give more commands in a row, but the
implementation is subtly broken in several ways and therefore disabled
by default until I fix it right after hell froze over.)

Another important thing to know in order to understand fw-sbp2 and sbp2
is that they currently rely on OHCI-1394's physical DMA feature, which
I'll not explain here. It means two things: 1. FireWire bus addresses of
ORBs and buffers are directly derived from the DMA mapped address.
(FireWire bus addresses are the addresses used in communication between
SBP-2 initiator and target.) 2. Almost all of the transfers done by the
target do not generate interrupts. (Just the status write generates an
interrupt.)

...
> Now that you drew my attention to sbp2_status_write(), this looks wrong:
> 
>         /* Lookup the orb corresponding to this status write. */
>         spin_lock_irqsave(&card->lock, flags);
>         list_for_each_entry(orb, &sd->orb_list, link) {
>                 if (status_get_orb_high(status) == 0 &&
>                     status_get_orb_low(status) == orb->request_bus) {
>                         list_del(&orb->link);
>                         break;
>                 }
>         }
>         spin_unlock_irqrestore(&card->lock, flags);
> 
> Why is it that fw_request can't carry a pointer?

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. Since there aren't many
mapped ORBs per target, a linked list is a reasonable data structure to
search over. That said --- Kristian, doesn't fw-sbp2 have at most 1 ORB
in sd->orb_list?
-- 
Stefan Richter
-=====-=-=== ---= ==-=-
http://arcgraph.de/sr/

  reply	other threads:[~2007-01-26  2:35 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     ` Stefan Richter [this message]
2007-01-26  4:01       ` Juju Kristian Høgsberg
2007-01-26 11:30         ` Juju Stefan Richter
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:
  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=45B968E7.1070402@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=krh@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zaitcev@redhat.com \
    --subject='Re: Juju' \
    /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

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