L138: submit descriptor into CPPI DMA queue

Wong

I understand your question, you are expecting that CPPI DMA should able to take next descriptor from submit queue automatically ( as you have pushed 4 descriptors to rx-submit queue).

This is possible it depends on which DMA mode you are using.

A) If RXDMA configured for TRANSPARENT MODE

1) In this mode, you can queue more than one descriptor to rx-submit queue, In host mode you should select the autoreq enable feature, then DMA will receive the first packet into first descriptor and push the completed descriptor to completion queue. Since auto-req is enabled, the subsequenct completed BDs will received into BDs available in the submit queue. 

In device mode, the packets are received automatically into BDs available in the submit queue.

Another important point, you should not disable the DMA Req Enable in the RXCSR register.

B) In case of GENERIC RNDIS mode :

          When you are using the Generic Rndis mode, In host mode, if you are using auto-req always, then DMA is will take next BD from submit queue automatically after completion of first BD, provided the EPSIZE should not be changed between the request.

Regards

Ravi B

Thanks Ravi.

Sorry that I did not provide the complete information. The driver is in device mode and configured for RNDIS mode.

 case RNDIS:
  REG32_SET_BIT(USB_OTG_CTRLR, USB_OTG_CTRLR_RNDIS); /* Enable RNDIS from Global Level */
  REG32_WRITE(USB_OTG_MODE, 0x11111111);

As it is in device mode, I did not select the autoreq enable feature. And I have also set DMAEN (Bit_13) in RXCSR register to enable DMA in USB core.

(1) Is there a maximum number of descriptor that can be queued in RNDIS mode ?

 I have pushed 4 descriptors into RX Submit Queue 0. These descriptors have been initialized properly, and I set Next Descriptor Pointer (HBD Word 5) to 0 for all the 4 descriptors.

(a) When host sends 1st packet, I expect the Queue Manager pops the 1st descriptor from submit queue.

(b) Once the data transfer is completed, Queue Manager will push the 1st descriptor into return queue (specified in the descriptor HBD Word 2 Bits 11-0).

(c) As I chose the return queue that generates interrupt, interrupt is gnerated as expected. In ISR, PEND0 is read to determine which return queue that has actually generated the interrupt.

(d) Once the queue is determined, the return queue is read and I get back the 1st descriptor.

The problem is when host sends 2nd packet, the Queue Manager still get the 1st descriptor for data transfer which is not I expected (and should not be possible) because at this point of time the submit queue does not even have 1st descriptor in the queue, it should have only 2nd, 3rd and 4th descriptor in the queue. When the return queue is read for the 2nd packet, I still get back the 1st descriptor.

And the subsequent packets sent by host, all ends up using 1st descriptor althought the 1st descriptor is no longer in the submit queue. The 2nd, 3rd and 4th descriptor never get to be used. This is really bothering me ???

In summary, although I have queued 4 different descriptors into submit queue, the behaviour here is like that I have queued the same 1st descriptors into submit queue for 4 times.

Or more than 4 times because host can send more than 4 packets, and the Queue Manager always get 1st descriptor for data tansfer, and when the return queue is read in ISR, it is always 1st descriptor.

Any comment ??? Hopefully I have described the prolem clearly.

rgds,

kc Wong

Wong

I understood your problem. It is strange to see such situation.

Ideally in RNDIS mode, the DMA shall receive the data till the short packet is received from the host. In RNDIS mode short packet is the termination condition for DMA to complete the BD and return to complete queue.

1) What happen if you don't submit descriptor 2,3,and 4. can you check still do you get the 1st descriptor in completion queue  for subsequent packet from host.

2) What is the packet length transfered by host?

3) what is the buffer length configured for 1st BD.

4) Can you add descriptor id field in BD (and set to 1,2,3..etc) to recognize the order of the descriptor queued to submit queue and order in which the descriptors are obtained in the completion queue.

Have you submitted all 4 BDs before enabling the DMA channel.

Regards

Ravi B

Hi Ravi,

Thanks for comment.

Previously, I see this problem, when I submit descriptor right after USB and CPPI DMA initializtion and before softconn bit is set.

/* Set softconn bit */
USB_OTG->POWER |= USB_OTG_POWER_SOFTCONN;

Now, I don't see this problem as I postpone descriptor submission until after the device enumeration is completed and device is in configured state.

I am not quite sure what is happening here. Anyway, it seems to work fine now.

Anyway, I still answer your questions.

(1) I need to revert back to the old code to try this. Will try it if I have time.

(2) Packet length transfered by host is always 20 bytes.

(3) Buffer length for all BDs are configured to be 64 bytes.

(4) Same as (1)

Previously, I submitted descriptors after enabling the DMA channel RXGCR[n].RX_ENABLE but before enabling USB core rx dma RXCSR.DMAEN.

Now, I submitted descriptors only after enabling both DMA channel and the USB core rx dma. I believe this should not be reason for the problem becasue the example given in SPRUFM9H also submit descriptors before enabling USB core rx dma.

rgds,

kc Wong 

Wong

Good, it is working now. But you are correct, there should not be any issue when submit the BD before enabling the RXCSR.DMAEN bit. Analyze which sequeuce was causing the issue when you have time.

But make sure, do not disable the DMA channel (RXGCR[n].RX_ENABLE) once it is enabled.

Regards

Ravi B

Ravi B said:

But make sure, do not disable the DMA channel (RXGCR[n].RX_ENABLE) once it is enabled.

Hmm, when I submit descriptors (both for TX and RX), I always disable the DMA channel first and enable it back after complete the submission.

Will this causing any problem ???

rgds,

kc Wong

Wong

Probably for RX you may not face issue, but still the there may be race condition can happen while rx-dma updating the completed buffer descriptor to memory and ISR reading the completed BD (still not updated).

The issue more severe in Tx direction. You should not disable the TX-DMA as the data transmission is not yet complete when the DMA returns the completed TX BD to completion queue.

Regards

Ravi B

Ravi B said:

Probably for RX you may not face issue, but still the there may be race condition can happen while rx-dma updating the completed buffer descriptor to memory and ISR reading the completed BD (still not updated).

 Are you saying when interrrupt is generated for RX, we still cannot assume the full packet has been completely DMA transfered from endpoint FiFO to data buffer specifed in the descriptors ???

Ravi B said:

The issue more severe in Tx direction. You should not disable the TX-DMA as the data transmission is not yet complete when the DMA returns the completed TX BD to completion queue.

Not sure I understand you correctly. Do you mean even though the descriptor has been pushed back to completion queue, it does not mean that data has been DMA transfered completely from the data buffer to endpoint FIFO ??? Because I thought the Queue Manager will only push the descriptor back to completion queue only after the data has been completely DMA transfer to endpoint FIFO. Let me know if this is not the case.

rgds,

kc Wong

For question-1 : When RX-DMA returns the BD to completion queue, all the data has been transferred from FIFO to memory.  Only updating Buffer descriptor with number of bytes received may delay till DMA arbitrates for memory and completes the write.

For question-2: Transmission is still in progress (data may be present in FIFO and intermediate CPPI FIFO).  The Tx-DMA-ISR should wait till TXCSR.TXPKTRDY bit set to zero to make sure not disturbing the transmission of previous packets. If you are not disturbing the TXCSR you can keep re-submit any number of Tx-BD.

Regards

Ravi B

Ravi B said:

For question-1 : When RX-DMA returns the BD to completion queue, all the data has been transferred from FIFO to memory.  Only updating Buffer descriptor with number of bytes received may delay till DMA arbitrates for memory and completes the write.

What is the measure that I can take to ensure that field is already updated when I access the number of bytes received in Buffer Descriptor especially for EOP ???

Ravi B said:

For question-2: Transmission is still in progress (data may be present in FIFO and intermediate CPPI FIFO).  The Tx-DMA-ISR should wait till TXCSR.TXPKTRDY bit set to zero to make sure not disturbing the transmission of previous packets. If you are not disturbing the TXCSR you can keep re-submit any number of Tx-BD.

 OK, noted.

So, back to the original question, it will not really matter if I disable the TX DMA channel before I submit descriptors and enable it back after complete the submission (set/clear TXGCR[n].TX_ENABLE) as long as I don't disturb the TXCSR ???

Noted. Thanks Ravi.