CPPI DMA transfer for usb host mode in OMAPL138

Hi,

HPD is always the first Descriptor for a SINGLE transfer. If you have a data to transfer size of 1024 bytes and you allocate memory large enough to accommodate the whole 1024 bytes and this memory is contiguous and can be described using one descriptor, then you will only need 1 descriptor and that will be 1 HPD. However, you can allocate more than 1 descriptor but they will not be used. It is like allocating a memory location greater than 1024 bytes for 1024 bytes of data.

However, if the memory described by the single 1st Descriptor is not large enough or if you want the transfer to reside in segmented memory locations, then you will need multiple Descriptors. The 2nd Descriptor and following are HBDs.

Having said that.

Case 1. You have 512 Bytes of memory reserved and described by the 1st Descriptor (HPD) then you will need additional memory for the remaining 512 bytes. So you will need one or more HBDs depending upon the size and segmentation of the data.

Case 2. This is not correct. HPD is the first Descriptor. Either allocate large enough memory that is referenced by the HBD or need to use other Descriptors (HBD) to reference/describe the memory locations for the remainder of the transfer.

Case 3. This is the case where a single contiguous memory with a size greater or equal to the transfer size is available. So, this is OK too.

Typical way depends on your application. If you do not need to segment your data (this is what is meant by "scatter" and "gather") Case 3 is probably the typical case. If need to scatter your data on a receive transfer or you need to gather on your transmit transfer Case 3 is the typical way. Case 2 is illegal.

The length of the data is determined based on the type of DMA mode you are using. If you are transferring data size of 1024 bytes (your e.g.) and your USB Max Packet size is set for 64 Bytes, then you probably want to use either RNDIS or GENERIC RNDIS transfer. If using RNDIS, your will need to transfer 17 packets where the last packet is a short packet (zero bytes of data) and this would be used as an indication for the end of the data. If you are using GENRIC RNDIS you can program the corresponding size register with 1024 bytes and you will need to transfer 16 Sixty Four bytes packet and it knows that the transfer ended when packet 16 is received.

If your transfer size is less than 64 Bytes then you will be using Transparent Mode.

Best regards, Zegeye

Hi, 

Thanks for your reply. It is much clearer right now. Still more uncertainties on the following paragraph.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The length of the data is determined based on the type of DMA mode you are using. If you are transferring data size of 1024 bytes (your e.g.) and your USB Max Packet size is set for 64 Bytes, then you probably want to use either RNDIS or GENERIC RNDIS transfer. If using RNDIS, your will need to transfer 17 packets where the last packet is a short packet (zero bytes of data) and this would be used as an indication for the end of the data. If you are using GENRIC RNDIS you can program the corresponding size register with 1024 bytes and you will need to transfer 16 Sixty Four bytes packet and it knows that the transfer ended when packet 16 is received.

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Assume OMAP is under USB HOST mode. OMAP send 1024 bytes to the usb device. Please compare the implementation of RNDIS mode and GENRIC RNDIS mode. In the firmware, do I need to  concern about the last zero-length pkt. In my thinking, I do not need to concern this zero-length pkt, the omap will generate this zero-length pkt automatically. But I am wondering how the usb device handles these two different consecutive packets, where one is "17 pkts with last one zero-length" and another one is "16 Sixty Four bytes packets". 

Q2 No matter what kind of dma mode the omap is, what the firmware needs to prepare is the one HPD with 1024 data buffer (CASE 3). Is this right?

Q3 I setup a HPD with address 0x80004800, I write 0x80004802 to CTRLD[16] to submit a HPD  for endpoint 1 TX. but when I try to read the value back, I get 0x00004803. Is this correct?

Q4 Suppose that I setup a HPD with completion queue 24 and submit it to queue 16 by writing CTRLD[16], I get the 16th bit of PENDING0 set. So my question is "After I submit the HPD to the queue 16 for EP1 TX. How I verify the data is sent out correctly?" I guess the 24thbit in PENDING0 will be set and 16th bit will be cleared, right?

Hi,

Q1. No, you do not need to be concerned. The DMA knows which mode you are using since you are programming the mode of operation (be it Transparent, RNDIS, GENERIC RNDIS, or Linux CDC). For this reason, it knows whether to insert a zero byte packet when the the transfer size is an exact multiple of a USB Max Packet size. It will insert a Zero byte packet after sending the 1024 bytes data if operating in RNDIS mode and will not insert a Zero Byte packet if operating in GENERIC RNDIS mode. One thing though, this is especially true on the receive. Since a Zero byte data packet has no data it is not going to occupy any memory buffer. Even though that is the case, just have a minimum of 1 byte additional data buffer size for your receive transfer.

Q2. Like mentioned previously, this is up to your application. If your application has the whole data to be transfered within 1 contigous memory location, then 1 Descriptor (HPD) is good enough. However, if your data is segmented and is present within multiple locations then you will need multiple descriptors.

Q3. Bits[4:0] content is OK. It increases by one and the h/w does that. However, Bits[31:5], I expect it to be the same. When you perform your transaction, so long as it works, you can ignore that. Let me know if you have issues and I will look into it.

Q4. Yes. If you would like to know if the transfer has completed and wanted to do polling method, you can read the Control D register and will have the address of the Descriptor when done.

Best regards, Zegeye

Hi,

thanks for your reply. One more question:

~~~~~~~~~~~~~~

Since a Zero byte data packet has no data it is not going to occupy any memory buffer. Even though that is the case, just have a minimum of 1 byte additional data buffer size for your receive transfer.

~~~~~~~~~~~~~~

Assume OMAP (usb HOST mode )works in RNDIS and usb maxpktsize = 512 byte, if firmware would receive 1024 bytes from the usb device, does the firmware need to prepare two HBDs in which one is with 1024 byte data buffer, and one is with 1byte data buffer?

Q2: in DMA mode, can I still use ERROR and NAK and RXSTALL bits in HOST_TXCSR to check the response from the usb device?

Thanks,

Sheng

Assume I have submitted the HPD to queue 16, do I need to set TXPKTRDY bit in TXCSR in order to start a bulk out transfer?

Can you give me a to-do list for a bulk out transfer. The following are what I am trying to do.

1) set up a HPD with a data buffer, link it to compQueue 24

2) set queue[16].CTRLD 

3) After 2), the 16th bit of PENDING0 is set.

4) set FLUSHFIFO & CLRDATATOG & MODE & DMAEN & DMAMODE

5) Reset FRCDATATOG & AUTOSET  in ep1 TXCSR

6) After reset AUTOSET, the OMAP should send data in queue 16 out

7) After 6), the 24th bit of PENDING0 is set.

8) Check TXCSR to see what stats is returned from the usb device. ACK or STALL or NAK

Can you help to clarify these?

Thanks

Sheng