• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 654 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

c6747 usb cppi dma teardown

Bill McKinney
Prodigy 235 points

The documentation for tearing down a dma channel is confusing.  Is there example source somewhere that works?  It looks like you need to allocate a teardown descriptor and post it to the teardown queue before following the steps in sprufm9f, but the procedure for telling the dma controller which queue is the teardown queue isn't described anywhere. 

The technical documents for this part have been pretty good, but the write up on the usb dma controller particularly blows.

 

 

  • 0
    TI__Expert 7435 points

    Bill,

    Pl. refer to the implementation under "drivers/usb/musb" under Linux installation source directory.  In that refer to cppi41_dma.c file - channel_abort() function.

    USB peripheral is completely supported under both Linux and BIOS platforms from driver perspective.  Any particular reason you are developing the driver from scratch?

    regards

    swami

  • 0 in reply to swami
    Prodigy 235 points

    Thank you for the help.  There were two main problems I was having.  1) apparently you need to set the TDFDQ register to point to a teardown queue you allocate and you need to  push teardown descriptors on to that queue for use by the core (no write up anywhere on that).  2) the RXGCR and TXGCR have some write-only bits that make it necessary to shadow the registers to keep track of what's in them.  Also the procedure for rx teardown in the linux driver uses a much different order of operations than for the tx teardown and contains this comment:

            /*
             * NOTE: docs don't guarantee any of this works...  we expect
             * that if the USB core stops telling the CPPI core to pull
             * more data from it, then it'll be safe to flush current Rx
             * DMA state iff any pending FIFO transfer is done.
             */

    which is a little interesting.  I've been porting some existing USB code to this processor and it took a matter of days to get things running until I tried to hook up the cppi dma engine.  That really is a pretty tough read.  It might make better sense to include the linux driver instead of the sample code that's in the document.

    I do have one last question: Does the errata in section 2.1.1 of sprz284b mean that you can't use generic rndis mode if you're trying to be a mass storage peripheral?  If you have to depend on the host not to send packets too fast doesn't that preclude use of generic rndis mode?

    Thank you again,

    --b

     

     

  • 0 in reply to Bill McKinney
    TI__Expert 7435 points

    Bill,

    Yes GRNDIS mode cannot be used when the request length varies dynamically (as in the case of MSC).

    regards

    swami

  • 0 in reply to swami
    Prodigy 205 points

    Do you mean both RNDIS and GRNDIS modes can not be used in MSC?

     

    Thanks,

    Sheng

     

  • 0 in reply to Bill McKinney
    Prodigy 230 points

    Bill,

    Just wanted to thank you for this post.  Probably will save me a lot of time.  I wonder how long it would have taken me to notice the GCR registers were write only...

    Cheers,

    Peter

  • 0 in reply to PeterM7235
    Expert 2110 points

    Hi,

    Ya, thanks for this post make me realize that TXGCR[n] and RXGCR[n] have some write-only fields.

    As I have below macros to set and clear the register, with write-only fields, the below macros will read back a wrong value before performing ORing or ANDing operation.

    A shadow registers are needed for these 2 sets register.

     #define REG32_SET_BIT(offset, mask) (*((volatile UINT32 *)(USB_OTG_REG_BASE + offset)) |= (mask))

     #define REG32_CLEAR_BIT(offset, mask) (*((volatile UINT32 *)(USB_OTG_REG_BASE + offset)) &= ~(mask))

     

     

     

     

     Thanks again ....

    rgds,

    kc Wong