✎ soc:2008:balajirrao:notes:uhci_design

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

====== UHCI Driver Desgin ======

{{:soc:2008:balajirrao:notes:schedule.png|}}

An example schedule is shown above. It consists of a frame list made up of 1024 frames. In each frame, the UHCI controller inserts number of TDs that can fit into a it. The gPXE since we don't support isochronous TDs, the UHCI starts scanning at the first Queue Head (QH). It executes the first TD queued below, sets its status, updates the QH to point to the executed TD's next TD, and goes to the next QH. Thus, UHCI executes one TD belonging to a particular QH at a time. This goes on till the end. Now, there could be time remaining in a 1ms time window. To reclaim this, we link the last QH to the first one. So, the UHCI controller keeps looping continuously, executing the first TD of every QH. This is called FSBR. We achieve a throughput of 425 KB/s. But it has a very big negative impact on PCI performance even though it boosts the throughput of the bus, which may not be very desirable. If there were no FSBR, UHCI would sit idly until the start of a next frame which is waste of time. As an example, when we need to transfer 1514 bytes of data through a particular endpoint, we see that only 64 bytes (max packet size of the endpoint) are transferred in ~1ms. This mreans a maximum throughput of 64 KB/s per endpoint.

gPXE creates as many QHs as there are number of endpoints. So, executing one TD per QH gives a fair share of bandwidth to all endpoints. This could be useful if several devices are being serviced by the controller simultaneously. In gPXE however, since we use only one device at a time, we could  have all TDs belonging to a QH execute first, before going to the an adjacent QH. This is called Depth First Execution and is enabled by setting a flag in each of the TDs. This gives us a maximum bandwidth of 425 KB/s without impacting performance in a negative way.

Trace: • week2 • week10 • week1 • week4 • week8 • week3 • 2011 • week9 • 2009 • week5 • asdlkf • week1

Navigation

Search

Toolbox

QR Code