From: Peter Hurley <peter@hurleysoftware.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
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: Tue, 27 Nov 2012 20:00:01 -0500 [thread overview]
Message-ID: <1354064401.2703.13.camel@thor> (raw)
In-Reply-To: <20121128005846.0f1d4d5e@stein>
On Wed, 2012-11-28 at 00:58 +0100, Stefan Richter wrote:
> 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.
Thanks for the clarification. I need to update
link_speed_to_max_payload() now. ;)
Plus I should just renew my IEEE membership so I can get the 1394-2008
spec without having to saw my arm off.
prev parent reply other threads:[~2012-11-28 1:00 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
2012-11-28 1:00 ` Peter Hurley [this message]
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=1354064401.2703.13.camel@thor \
--to=peter@hurleysoftware.com \
--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=stefanr@s5r6.in-berlin.de \
/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).