L138: Question on CPPI DMA RX

Hi Ravi,

I have another question for CPPI DMA RX.

Just for example, let say I want to rx 640 bytes data from host. I can prepare 10 buffer descriptors with each of them having data buffer with size of 64 bytes. This definitely works, but I need to pre-allocate the memory for data buffer to support the maximum size of data that can be sent from host for the specific application. This is expensive in term of memory.

My question is can I use a single buffer descriptor with size of 64 bytes to transfer 640-byte packet ??? The same descriptor is reused 10 times.

(1) I submit single descriptor with data buffer of 64 bytes

(2) Host send 640-byte packet

(3) Queue Manager pops the signle descriptor to fill the first 64 bytes of the packet and pushs it to the specified return queue. This is where I am not sure about the behaviour of CPPI DMA. As the transfer of packet has not completed, will interrupt still being generated ? When there is no descriptor in the submit queue, and the endpoint FIFO is filled with seond 64 bytes, I believe USB core will NAK the host from sending the third 64 bytes, right ?

(4) If the interrupt is generated, I can offload the first 64 bytes data to another memory. And submit the same descriptor back to the queue to receive the remaining bytes of data. For eample, if second 64 bytes is already in endpoint FIFIO, Queue Manage immediately pops the descriptor to fill the second 64 bytes of the packet.

Not sure if this is how CPPI DMA works ?

rgds,

kc Wong

Wong

What is max endpoint packet size configured in this scenario.

In RNDIS mode the DMA will not terminate the packet completion until short packet is received. (short packet - less than max epsize or multiple of max-epsize followed by short packet). If there is no enough buffer descriptor in queue it may lead to starvation condition of DMA.

The device should know what is the maximum number of bytes that host is going to send.

Recycling of buffer descriptor using single BD.

         You can disable the Rx-DMA channel as soon as rx-completion interrupt is occured, then consume the BD and then re-submit the BD to submit queue and then enable the RX-DMA channel.

To disable the DMA Channel - remove the entry of respective channel in schedular table and also decrement the number of channels configured in table.

To enable the DMA Channel - add the entry of respective channel in schedular table and  increment the number of channels configured in table.

Regards

Ravi B

Ravi B said:

What is max endpoint packet size configured in this scenario.

The max endpoint packet size is configured for 64 bytes.

Ravi B said:

 

In RNDIS mode the DMA will not terminate the packet completion until short packet is received. (short packet - less than max epsize or multiple of max-epsize followed by short packet). If there is no enough buffer descriptor in queue it may lead to starvation condition of DMA.

Does this statement say that no interrupt will be generated if DMA has not seen the EOP (short packet) ? Because if no interrupt generated, then the recycling of single buffer descriptor will not work in this case.

Ravi B said:

Recycling of buffer descriptor using single BD.

         You can disable the Rx-DMA channel as soon as rx-completion interrupt is occured, then consume the BD and then re-submit the BD to submit queue and then enable the RX-DMA channel.

To disable the DMA Channel - remove the entry of respective channel in schedular table and also decrement the number of channels configured in table.

To enable the DMA Channel - add the entry of respective channel in schedular table and  increment the number of channels configured in table.

 

 What is the difference to disable the channel by clearing RXGCR[n].RX_ENABLE compared with removing the entry of respective channel in schedular table ? Will removing channel from scheduling prevent starvation condition to happen since the Queue Manager will not try to read the empty queue ???

Any bad consequences if starvation condition happen ? Or the scheduler will just retry again when it comes to the same channel  again ?

rgds,

kc Wong 

Wong

considering the ep max pkt size is 64 bytes. Then if you are submitting the BD1 with 64 byte buffer length, then

1) Rx DMA will terminate if short packet (<64) is received and return the BD1 to compeltion queue.

2) If exact 64 byte is received, the RX-DMA termination is not occured and BD1 will be returned to completion queue and fetch next BD from submit queue for subsequent packets till short packet is received.

But why you need to multiple BD of 64 buffer size or re-cycling single BD.  You can submit single BD with maximum buffer length (may be 640+ bytes) receive data from host, this will reduce the number of interrupts to system.

Regards

Ravi B

In the application that we are building, we are expecting 130,000 bytes max from host. 640 bytes is just an example.

Ya, I can submit a single BD with 130,000 buffer length. It is kind of waste of memory, as in normal usage, we don't really use up to 130,000 bytes of data transfer, only on certain rare cases.

Thus, I am exploring if re-cycling a single BD is feasible or not in order to conserve memory.

rgds,

kc Wong

wong

If the device knows how much data host is going to send at any point of time prior configuring the RX-DMA to receive the data, then you can configure the RX-DMA to receive maximum of 64K of data with single BD, if data to be received is more than 64K, then you can mulitple BD or reccycle the same BD after each rx-dma receive completion.

Regards

Ravi B

Hi Ravi,

Unfortunately, there is no way for device to know in advance how much data host is going to send.

Unless, i can multiplex PIO and DMA mode so that I can use PIO mode to first transfer the header (fixed size),  and determine the payload size from the header and then configure RX-DMA for the rest of the payload.

But, unfortunately, it will not work reliably as you pointed out.

rgds,

kc Wong

Wong

I assume from your description,

1) host sends the header (packet) to device

2) Device decodes the header and get the size of data that host is going to send.

3) configure the Rx-DMA to receive the data from host.

Is my understanding correct?

Regards

Ravi B

Ya, but header and payload are not sent by host separately, or at least the first part of the payload will be in the same transfer as the header.

The header (12-byte header) does not occupy the max endpoint packet size, thus the remaining will be filled with the first part of the payload. if the depth of the FIFO is 64 bytes, then the first 12 bytes will be the header, the remaining 52 bytes will be the first part of the payload.

So, the ideal case is that I can PIO the first 12 bytes (which is the header), and decode to get the size of the payload, and then configure the Rx-DMA to receive the payload.

rgds,

kc Wong

Hi Ravi,

Ya, actually the first option is what I am planing to do.

But, I have concern when you said the multiplex use of PIO and DMA mode will not work reliably. Thus, I drop the plan.

rgds,

kc Wong

Wong

I have not tried the first option, you can try and let us know how it works. The second option i have verified it is working.

Regards

Ravi B

Noted. Thanks Ravi.

By the way, I have a side question. Did you verify on TI OMAP L138 eXperimenter Kit from Logic PD ?

rgds,

kc Wong

Yes wong, i have verifed on TI-OMAP L138 (Linux usb driver).

Regards

Ravi B

The reason I asked is I am seeing issue on the Logic PD eXperimenter Kit when the USB is in high speed mode. I am not using Linux usb driver because our product is not Linux based. With reference to the Linux usb driver, i have come out with our own usb driver.

Thus, would like to check with you if you see the same issue in Linux. During enumeration for high speed mode, the GET_DESCRIPTOR (string) requests are always failed. And thus will not see the valid product ID and serial number in the device manager in Windows host. No issue in full speed mode.

8688.Differences in Full-Speed and High-Speed.docx

Anyway, detailed problem is described in the below post.

htttp://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/98645/388166.aspx#388166

rgds,

kc Wong

Wong

This is something strange how the other Get-descriptors commands working and only for string descriptor there is no ACK/NAK/STALL from the device (in High speed). Can you check what is command executed by the device before to string descriptor. when device responding  previous command, is there any corruption of FIFO registers, can you confirm after execution of last command by device, what is state of all the regsiters.  There is possiblity if FIFO not configured properly may leads to this kind of behavior.

Regards

Ravi B

Ya, it is strange. Because of this issue, the device is working only in full speed mode.

I look at the Ellysis capture, the previous request can be GET_DESCRIPTOR (Configuration), GET_DESCRIPTOR (Device) or GET_DESCRIPTOR (String lang IDs).

Ravi B said:

when device responding  previous command, is there any corruption of FIFO registers, can you confirm after execution of last command by device, what is state of all the regsiters.  There is possiblity if FIFO not configured properly may leads to this kind of behavior.

I am assuming that you are refereing to the Endpoint 0 FIFO register. I am not sure how to check if there is any corruption. As the enumeration is continuous process, I am not sure how to inspect the state of all the registers while enumeration is going on.

rgds,

kc Wong

Wong

Can you confirm that the setup token (8 bytes) sent by host is not received into FIFO (the TXPKTRDY bit is not set). You can disable the interrupts after last successful command and check in polling mode for the failure case (string descriptor).

Regards

Ravi B

Hi Ravi,

If the setup token is in endpoint 0 FIFO, the RXPKTRDY bit will be set, and interrupt is generated. I can confirm that no interrupt has been generated from the USB for those missing requests.

By the way, what is the USB device that you have configured for your Linux kernel. Not sure if you can send me your Linux kernel build (configured with a USB device) so that I can try on my Logic PD eXperimenter Kit. 

rgds,

kc Wong

Wong

I do not have ready image with me (as i have verified long back). You can built new uImage with release kernel tree.  You can choose USB Device mode with file storage gadget configuraton (refer to user's guide for info) for storage media you can use either simple file or SATA or NAND.

     insmod g_file_storage.ko file=/mnt/sample.txt stall=0

Regards

Ravi B

Hi Ravi,

Actually, I am not that familiar with the Linux development environment.

Not sure you can do me a favor to build the uImage for me ?

rgds,

kc Wong

Wong

I will check whether i have pre-built binaries and let you know whether i can send the images to you.

Regards

Ravi B

Hi Ravi,

Just follow up with you.

It is possible for you to configure the USB, and build the Linux kernel for me for L138 eXperimenter Kit ?

rgds,

kc Wong

Hi Ravi,

Ravi B said:

I will check whether i have pre-built binaries and let you know whether i can send the images to you.

 I haven't from you regarding this. Anyway, I will try to configure the USB into Linux kernel by myself.

I will create a new post if I face any problem, hopefully you can help to answer later. Thanks.

rgds,

kc Wong