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. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
