linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
	linux1394-devel@lists.sourceforge.net,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH v2 1/1] staging: fwserial: Add TTY-over-Firewire serial driver
Date: Wed, 28 Nov 2012 00:58:46 +0100	[thread overview]
Message-ID: <20121128005846.0f1d4d5e@stein> (raw)
In-Reply-To: <1354041196.3284.121.camel@thor>

On Nov 27 Peter Hurley wrote:
> > > Currently, firewire-net sets an arbitrary address handler length of
> > > 4096. This works because the largest AR packet size the current
> > > firewire-ohci driver handles is 4096 (value of MAX_ASYNC_PAYLOAD) +
> > > header/trailer. Note that firewire-ohci does not limit card->max_receive
> > > to this value.
> > > 
> > > So if the ohci driver changes to handle 8K+ AR packets and the hardware
> > > supports it, these address handler windows will be too small.  
> > 
> > While the IEEE 1394:2008 link layer specification (section 6) provides for
> > asynchronous packet payloads of up to 16384 bytes (table 6-4), the IEEE
> > 1394 beta mode port specification (section 13) only allows up to 4096
> > bytes (table 16-18).  And alpha mode is of course limited to 2048 bytes.
> > 
> > So, asynchronous packet payloads greater than 4096 bytes are out of scope
> > of the current revision of IEEE 1394.  
> 
> You should look at this 1394ta.org video
> http://www.youtube.com/watch?v=xVXNvXHNQTY of DAP Technologies S1600
> OHCI controllers running S1600 cameras using beta cables.

I don't know the details of their implementation, but I suppose they conform
with the 1394 beta mode port specification.  Which in turn means that their
S1600 solution (and by extrapolation, their S3200 prototypes) comply with a
maximum asynchronous packet payload of 4096 bytes.  Citing IEEE 1394-2008:

>>>
	Table 16-18———Maximum payload size for Beta data packets
 Data rate | Maximum asynchronous payload size | Maximum isochronous payload
           |              (bytes)              |           (bytes)
 ----------+-----------------------------------+----------------------------
    S100   |                 512               |             1024
    S200   |                1024               |             2048
    S400   |                2048               |             4096
    S800   |                4096               |             8192
    S1600  |                4096               |            16384
    S3200  |                4096               |            32768
<<<

(Alpha mode payload limits are the same as the S100...S400 subset of beta mode.
In IEEE 1394b-2002, the table number is 16-3.)

You can of course define registers (or better termed: buffers) which are larger
than what can be atomically read or written, or atomically compared-swapped;
IOW which are larger than what can be accessed in a single transaction, if such
registers or buffers are useful.  But if you particularly need a register which
is just large enough to accommodate the largest possible inbound block write
transaction which complies with IEEE 1394, and you don't know the peer's
capability and the speeds of all intermediary cable hops, then
fw_card.max_receive is the number that you need.  Or you ignore the cards actual
capability and just allocate 4096 bytes.

OHCIs that you can buy offer fw_card.max_receive of 1024, or 2048, or 4096 bytes.
1024 bytes is the limit of many but not all 1394a S400 CardBus cards.

[Issues of transaction retries and possible loss at session termination to be
left to another reply at another time.]
-- 
Stefan Richter
-=====-===-- =-== ==-==
http://arcgraph.de/sr/

  reply	other threads:[~2012-11-27 23:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-18 12:56 [PATCH 0/1] staging: Add firewire-serial driver Peter Hurley
2012-10-22 22:45 ` Greg Kroah-Hartman
2012-10-23  2:34   ` Peter Hurley
2012-10-23  3:15     ` Greg Kroah-Hartman
2012-10-23  9:51     ` Alan Cox
2012-10-23 16:30       ` Peter Hurley
2012-10-23 18:41         ` Stefan Richter
2012-10-24 13:41   ` Stefan Richter
2012-10-24 15:56     ` Peter Hurley
2012-11-02 12:16 ` [PATCH v2 " Peter Hurley
2012-11-02 12:16   ` [PATCH v2 1/1] staging: fwserial: Add TTY-over-Firewire serial driver Peter Hurley
2012-11-12 23:33     ` Stefan Richter
2012-11-12 23:51       ` Greg Kroah-Hartman
2012-11-13 19:37         ` Peter Hurley
2012-11-13 19:47           ` Greg Kroah-Hartman
2012-11-13 19:14       ` Peter Hurley
2012-11-14  1:25         ` Stefan Richter
2012-11-27 18:33           ` Peter Hurley
2012-11-27 23:58             ` Stefan Richter [this message]
2012-11-28  1:00               ` Peter Hurley

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=20121128005846.0f1d4d5e@stein \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=peter@hurleysoftware.com \
    /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;
as well as URLs for NNTP newsgroup(s).