• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 557 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/XIO2213A: IT/IR Context | data loss when we try to use more than 4 IR Contexts simultaneously

Anthony Kawa
Prodigy 60 points
Part Number: XIO2213A
Other Parts Discussed in Thread: XIO2213B

Tool/software: Linux

We seem to have run into a limitation on isochronous data reception using the firewire card with the TI chipset. Although the Linux driver reports that this card has 8 IR contexts, we are seeing data loss when we try to use more than 4 of them simultaneously. We did not see this problem with the old card.

I found a link to a datasheet for the chipset here: http://www.ti.com/product/XIO2213A/technicaldocuments

  1. The datasheet doesn't indicate how many IR contexts are supported. Can you tell us how many IR contexts are supported by this board? Linux uses the OHCI standard way of querying contexts (writing 0xFFFFFFFF to the ISO receive mask register and then reading it back), but perhaps this chipset/board isn't reporting properly.
  2. Are the IR and IT contexts independent, or do they share resources? In other words, can we theoretically receive on all of the available IR contexts while simultaneously transmitting using all available IT contexts?
  3. I saw something concerning in the datasheet, section 2.1 (page 14):

The XIO2213A simultaneously supports up to four posted write transactions, four non-posted transactions, and four completion transactions pending in each direction at any time. Each posted write data queue and completion data queue can store up to 8K bytes of data. The non-posted data queues can store up to 128 bytes of data.

Is this referring to PCI or 1394 transactions? And would these limits (4 transactions, 8K of posted/completed, 128 bytes of non-posted) have an effect on the number of isochronous contexts we could use simultaneously?

Our design requires 6 IR and 2 IT contexts as a minimum, even though the OHCI spec apparently only requires 4/4 as a minimum.

  • 0
    TI__Guru 64326 points
    Anthony,

    We are looking into this and will get back to you as soon as possible.
  • 0
    Prodigy 140 points

    Hello Anthony, this is Richard Mourn with FlightWire Technology. I should be able to help with your questions.

    1. The datasheet doesn't indicate how many IR contexts are supported. Can you tell us how many IR contexts are supported by this board? Linux uses the OHCI standard way of querying contexts (writing 0xFFFFFFFF to the ISO receive mask register and then reading it back), but perhaps this chipset/board isn't reporting properly.

    Please refer to the XIO2213B data sheet, it appears to fix some error in the XIO2213A data sheet. The XIO2213B supports eight (8) IT context and four (4) IR contexts. Please see Table 8-1 OHCI Register Map (Isochronous Transmit Context n (n=0,1,2,3,...,7), Isochronous Receive Context n (n=0,1,2,3).

    2. Are the IR and IT contexts independent, or do they share resources? In other words, can we theoretically receive on all of the available IR contexts while simultaneously transmitting using all available IT contexts?

    Yes they are independent resources. Yes you can transmit and receive simultaneously.

    3. I saw something concerning in the datasheet, section 2.1 (page 14):

    This section is referring to Asynchronous transaction not Isochronous.

    Please contact support@flightwiretech.com if you have any other questions.

  • 0
    Guru 243120 points
    The XIO2213A datasheet shows the number of IT/IR contexts in sections 8.23/8.25, i.e., there are 8 IT, 4 IR.
    Does the driver really report "8 IR + 8 IT contexts"?

    If you want to receive on six channels, you could use a single context in multichannel mode (FW_CDEV_ISO_CONTEXT_RECEIVE_MULTICHANNEL).
  • 0 in reply to Clemens Ladisch
    TI__Guru 64326 points
    Anthony,

    The information that Richard Mourn posted about XIO2213A is correct. Do you have any additional question on this topic?
  • 0 in reply to Clemens Ladisch
    Prodigy 20 points

    Clemens Ladisch said:
    The XIO2213A datasheet shows the number of IT/IR contexts in sections 8.23/8.25, i.e., there are 8 IT, 4 IR.
    Does the driver really report "8 IR + 8 IT contexts"?

    Yes, the Linux driver reports 8/8, both from the old ("ieee1394") and new ("Juju" or just "firewire") driver stacks:

    OLD> ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[16] MMIO=[90110000-901107ff] Max Packet=[4096] IR/IT contexts=[8/8]

    NEW> firewire_ohci: Added fw-ohci device 0000:02:00.0, OHCI v1.10, 8 IR + 8 IT contexts, quirks 0x2

    It queries the number of available contexts by writing 0xFFFFFFFF to the ISO TX/RX mask registers and then reading them, expecting the hardware to clear any bits for irrelevant contexts. It's my understanding that this is the OHCI-defined way to query for the number of available contexts. Does the XIO2213A not support that sort of query strategy?

    Clemens Ladisch said:

    If you want to receive on six channels, you could use a single context in multichannel mode (FW_CDEV_ISO_CONTEXT_RECEIVE_MULTICHANNEL).

    We have been using that mode in some of our configurations, but unfortunately it's still not completely supported by the `raw1394` library when running on the new Juju stack.

  • 0 in reply to Ken Treis
    Guru 243120 points

    Does the XIO2213A not support that sort of query strategy?

    This looks like a simple hardware bug.

    multichannel mode … is still not completely supported by the `raw1394` library when running on the new Juju stack.

    I don't know if it even can be made to fit into the libraw1394 API: Thread: Re: [FFADO-devel] Libraw1394

    I'd estimate it would be easier to use the new kernel API directly. Why are you using the old driver? Isn't that kernel quite a few years out of date?

  • 0 in reply to Clemens Ladisch
    Prodigy 20 points

    Thanks. We suspected a hardware bug; it unfortunately caused some headaches for us but I think we're going to be OK using multichannel mode.