lkml.org 
[lkml]   [2012]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 1/1] staging: fwserial: Add TTY-over-Firewire serial driver
    On Nov 13 Peter Hurley wrote:
    > On Tue, 2012-11-13 at 00:33 +0100, Stefan Richter wrote:
    > > On Nov 02 Peter Hurley wrote:
    > > > +2. MAX_ASYNC_PAYLOAD needs to be publicly exposed by core/ohci
    > > > + - otherwise how will this driver know the max size of address window to
    > > > + open for one packet write?
    > >
    > > Hmm, don't firewire-sbp2 and firewire-net deal with this very problem
    > > already on their own? Firewire-sbp2 tells the target what maximum payload
    > > the local node is ready to accept, and firewire-net figures out whether it
    > > needs to fragment the datagrams in unicast TX depending on the remote
    > > node's capabilities.
    >
    > I wasn't as clear as I should have been here. This is only about how big
    > to make the address handler window.

    Isn't fw_card.max_receive what you were looking for? But since the
    current firewire-core API requires you to allocate one handler address and
    size for all cards --- even for cards which will be hot-added later while
    your driver is already running ---, you should surely just allocate
    4096 bytes; see below.

    > Just like firewire-net, this driver
    > communicates with remotes at S100 speeds (and packet sizes) to
    > query the largest packet size that the remote supports.

    (RFC 2734 additionally keeps things sane for itself by requiring all 2734
    compliant nodes to support at least max packet = 512 bytes.)

    Could it be easier to take this information from fw_device.max_speed and
    the max_rec in fw_device.config_rom? RFC 2734 was designed to work
    without a local node management layer which is capable to gather such
    information, but we have this information on Linux (at the time when
    core_device.c finished its node discovery).

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

    > > > +3. Maybe device_max_receive() and link_speed_to_max_payload() should be
    > > > + taken up by the firewire core?
    > >
    > > Sounds like an extension of item 2, and is easier resolved after the
    > > driver moves out of staging.
    >
    > Ok.
    >
    > > > +4. To avoid dropping rx data while still limiting the maximum buffering,
    > > > + the size of the AR context must be known. How to expose this to drivers?
    > >
    > > I don't see a requirement to know the local or remote node's size of AR
    > > DMA buffer. Rather, keep the traffic throttled such that too frequent
    > > ack-busy are avoided.
    [...]
    > I do need to implement retries but that will be of limited benefit to
    > this particular problem.
    >
    > Data is written from the remote as a posted write into the AR buffer.
    [...]

    Oh, I forgot about posted writes. However, you only lose data with posted
    writes if the OHCI somehow fails to access the host bus. Merely getting
    to the end of the DMA program before all of the PCI posting FIFO could be
    emptied is not a reason to drop data. See OHCI-1394 section 3.3 which
    speaks about the possibility to drop selfID/ IR/ AR-resp data if out of
    buffer, but not AR-req data.

    Well, maybe there are bad OHCI implementations which drop posted AR-req
    data...? I don't know.

    firewire-net uses posted writes too. But with IP-over-1394, delivery
    guarantee is handled further above if needed, not by the 1394
    encapsulation. firewire-sbp2 also uses posted writes, in two ways: With
    physical DMA to SCSI READ command data buffers, and for the SBP status
    FIFO. But physical DMA does not have a backing DMA program, and data loss
    during a status FIFO write would likely be covered by a SCSI transaction
    retry.

    [...]
    > Besides the inefficiency of re-sending data that has already been
    > received, retrying may not be possible. Consider when a console driver
    > (work-in-progress) writes to the remote using the same interface. It
    > could be one of the last things the remote does. And the most crucial
    > information is that last write.

    As mentioned, I have no idea how TTY works or is supposed to work. But
    even if the sending application is allowed to quit before its last
    outbound datagram was delivered, fwserial could still be made to deliver
    this last datagram at its own pace, with as many software retries as
    prudent.
    --
    Stefan Richter
    -=====-===-- =-== -===-
    http://arcgraph.de/sr/


    \
     
     \ /
      Last update: 2012-11-14 02:41    [W:3.835 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site