Map device driver code to Logic Analyzer waveform

As per SDIO specification, the sequence of operations (for write transaction) take place as:

Command53 -- CommandLatency -- Command53Response -- ResponseLatency -- startbit -- write-number-of-bytes -- CRC -- endbit -- WriteLatency -- startbit -- CRC -- endbit -- busybit.

During benchmarking of SDIO UART driver, the time values which I got were more than expected. A lot of latency was found especially during write transaction.

Reasons for latency could be scheduler allocating processor time to other processes, delay in work queues, etc.

I would like to analyze and understand the latency. May be understanding the mapping between the device driver code and the Logic Analyzer waveform can lead to some cue.

Can somebody shed some light on this?

Thank you.

---

EDIT 1: Sorry! I assumed a few things.

In sdio_uart_transmit_chars() there is a call to sdio_out() which in turn calls sdio_writeb() and this call writes byte wise (one byte at a time) to a SDIO UART device. I modified the driver to use sdio_writesb() i.e. multi-byte mode. This reduced the time taken to write X bytes relatively. Interestingly, with increase in size of write data, there was exponential increase in WriteLatency (as mentioned above).

This latency could be because of many reasons. I would like to understand these reasons.

Setup: I am using Linux (v 2.6.32) laptop and a loadable kernel module (which is modified sdio_uart.c)

---

EDIT 2:

May be adding 'SDIO' in this question is misleading..(not sure at the moment). The reasons for delay could be generic to any device driver while interacting with the hardware and it may be independent of SDIO write process.

If somebody can point me to related online resource, I would be happy to explore and update the result here.

Hope I added more clarity this time. Please comment if I the question is still not clear.

Thank you for your time.

---

EDIT 3:

Yes, I am looking at the signal开发者_如何学Pythons on Logic Analyzer (LA) and there are longer delays during and between writes than I expected.

To give an idea about time values:

For 512 bytes transfer: At the hardware level theoretically the write should take 50 micro seconds (us), however in reality I got 200 us.

This gap of 150 us is what I want to understand.

Note:

1) I am rounding off the time values to simplify the case.

2) All the time values are calculated at Kernel level and no user space issue is involved here.

---

One thing worth looking at is if your sd interface functions by DMA, such that the driver can program the state machine and then it just runs by itself, or if getting the message out requires repetitive service by the driver, which might be delayed by other kernel obligations.

You could also see if there may be an I/O bottleneck, for example is the SD interface or whatever bus it hangs off of also used for something else?

Finally you could search for ways to increase the priority. At an extreme, you could switch to a real time SD driver rather than a normal one.