• Peter Chen's avatar
    usb: chipidea: define stream mode disable for both roles · 8022d3d5
    Peter Chen authored
    The system bus and chipidea IP have different limitations for
    both host and device mode.
    For example, with below errata, we need to enable SDIS(Stream Disable
    Mode) at host mode. But we don't want it for device mode at the
    same system.
    
    TAR 9000378958
    Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to
    Hang on OUT Retry
    Impacted Configuration: Host mode, all transfer types
    Description:
    The host core operating in streaming mode may under run while sending
    the data packet of an OUT transaction. This under run can occur if
    there are unexpected system delays in fetching the remaining packet
    data from memory. The host forces a bad CRC on the packet, the device
    detects the error and discards the packet. The host then retries a Bulk,
    Interrupt, or Control transfer if an under run occurs according to the
    USB specification. During simulations, it was found that the host does
    not issue the retry of the failed bulk OUT. It does not issue any other
    transactions except SOF packets that have incorrect frame numbers.
    
    The second failure mode occurs if the under run occurs on an ISO OUT
    transaction and the next ISO transaction is a zero byte packet. The host
    does not issue any transactions (including SOFs). The device detects a
    Suspend condition, reverts to full speed, and waits for resume signaling.
    
    A third failure mode occurs when the host under runs on an ISO OUT and
    the next ISO in the schedule is an ISO OUT with two max packets of 1024
    bytes each. The host should issue MDATA for the first OUT followed by
    DATA1 for the second. However, it drops the MDATA transaction, and
    issues the DATA1 transaction.
    
    The system impact of this bug is the same regardless of the failure mode
    observed. The host core hangs, the ehci_ctrl state machine waits for the
    protocol engine to send the completion status for the corrupted
    transaction, which never occurs. No indication is sent to the host
    controller driver, no register bits change and no interrupts occur.
    Eventually the requesting application times out.
    
    Detailed internal behavior:
    The EHCI control state machine (ehci_ctrl) in the DMA block is responsible
    for parsing the schedules and initiating all transactions. The ehci_ctrl
    state machine passes the transaction details to the protocol block by
    writing the transaction information in to the TxFIFO. It then asserts
    the pe_hst_run_pkt signal to inform the host protocol state machine
    (pe_hst_state) that there is a packet in the TxFIFO.
    A tag of 0x0 indicates a start of packet with the data providing the
    following information:
    
    35:32 Tag
    31:30 Reserved
    29:23 Endpoint (lowest 4 bits)
    22:16 Address
    15:10 Reserved
    9:8 Endpoint speed
    7:6 Endpoint type
    5:6 Data Toggle
    3:0 PID
    The pe_hst_state reads the packet information and constructs the packet
    and issues it to the PHY interface.
    The ehci_ctrl state machine writes the start transaction information in
    to the TxFIFO as 0x03002910c for the OUT packet that had the under run
    error. However, it writes 0xC3002910C for the retry of the Out
    transaction, which is incorrect.
    The pe_hst_state enters a bus timeout state after sending the bad CRC
    for the packet that under ran. It then purges any data that was back
    filled in to the TxFIFO for the packet that under ran. The pe_hst_state
    machine stops purging the TxFIFO when it is empty or if it reads a
    location that has a tag of 0x0, indicating a start of packet command.
    
    The pe_hst_state reads 0xC3002910C and discards it as it does not decode
    to a start of packet command. It continues to purge the OUT data that
    has been pre-buffered for the OUT retry . The pe_hst_state detects the
    hst_packet_run signal and attempts to read the PID and address
    information from the TxFIFO. This location has packet data and so does
    not decode to a valid PID and so falls through to the PE_HST_SOF_LOAD
    state where the frame_num_counter is updated. The frame_num_counter
    is updated with the data in the TxFIFO. In this case, the data is
    incorrect as the ehci_ctrl state machine did not initiate the load.
    The hst_pe_state machine detects the SOF request signal and sends an
    SOF with the bad frame number. Meanwhile, the ehci_ctrl state machine
    waits indefinitely in the run_pkt state waiting for the completion
    status from pe_hst_state machine, which will never happen.
    
    The ISO failure case is similar except that there is no retry for ISO.
    The ehci_ctrl state machine moves to the next transfer in the periodic
    schedule. If the under run occurs on the last entry of the periodic
    list then it moves to the Async schedule.
    
    In the case of ISO OUT simulations, the next ISO is a zero byte OUT
    and again the start of packet command gets corrupted. The TxFIFO is
    empty when the hst_pe_state attempts to read the Address and PID
    information as the transaction is a zero byte packet. This results
    in the hst_pe_state machine staying in the GET_PID state, which means
    that it does not issue any transactions (including SOFs). The device
    detects a Suspend condition and reverts to full speed mode and waits
    for a Resume or Reset signal.
    
    The EHCI specification allows a Non-DoubleWord (32 bits) offset to
    be used as a current offset for Buffer Pointer Page 0 of the qTD.
    In Non-DoubleWord aligned cases, the core reads the packet data
    from the AHB memory, performs the alignment operation before writing
    it in to the TxFIFO as a 32 bit data word. An End Of Packet tag (EOP)
    is written to the TxFIFO after all the packet data has been written
    in to the TxFIFO. The alignment function is reset to Idle by the EOP
    tag. The corruption of the start of packet command arises because the
    packet buffer for the OUT transaction that under ran is not aligned
    to a DoubleWord, and hence no EOP tag is written to the TxFIFO. The
    alignment function is still active when the start packet information
    is written in to the TxFIFO for the retry of the bulk packet or for
    the next transaction in the case of an under run on an ISO. This
    results in the corruption of the start tag and the transaction
    information.
    
    Click for waveform showing the command 0x 0000300291 being written in
    to the TX FIFO for the Out that under ran.
    Click for waveform showing the command 0xC3002910C written to the
    TxFIFO instead of 0x 0000300291
    Versions affected: Versions 2.10a and previous versions
    How discovered: Customer simulation
    
    Workaround:
    1- The EHCI specification allows a non-DoubleWord offset to be used
    as a current offset for Buffer Pointer Page 0 of the qTD. However,
    if a DoubleWord offset is used then this issue does not arise.
    2- Use non streaming mode to eliminate under runs.
    
    Resolution:
    The fix involves changes to the traffic state machine in the
    vusb_hs_dma_traf block. The ehci_ctrl state machine updates the context
    information by encoding the transaction results on the
    hst_op_context_update signals at the end of a transaction. The signal
    hst_op_context_update is added to the traffic state machine, and the
    tx_fifo_under_ran_r signal is generated if the transaction results in
    an under run error. Click for waveform
    
    The traffic state machine then traverses to the do_eop states if the
    tx_fifo_under_ran error is asserted. Thus an EOP tag is written in to
    the TxFIFO as shown in this waveform .
    
    The EOP tag resets the align state machine to the Idle state ensuring
    that the next command written by the echi_ctrl state machine does not
    get corrupted.
    
    File(s) modified:
    RTL code fixed: …..
    Method of reproducing: This failure cannot be reproduced in the current
    test bench.
    Date Found: March 2010
    Date Fixed: June 2010
    Update information:
    Added the RTL code fix
    Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
    8022d3d5
core.c 24.7 KB