====== Differences ====== This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2008:balajirrao:notes:usb_outline [2008/05/25 08:10] balajirrao |
soc:2008:balajirrao:notes:usb_outline [2008/05/25 13:04] (current) mdc |
||
|---|---|---|---|
| Line 45: | Line 45: | ||
| Finally, once we know how TDs and QHs are arranged in memory, we'll describe how the Host Controller processes them. The Frame Counter register is incremented every millisecond. It indexes into the Frame list and selects a frame. From the frame, TDs one by one are executed, and their status marked in the TD itself. The TDs can be optionally marked to generate Interrupts on Completion (IOCs). This goes on and on. When interrupts are not available for use, we can poll for their status and recognize their completion. | Finally, once we know how TDs and QHs are arranged in memory, we'll describe how the Host Controller processes them. The Frame Counter register is incremented every millisecond. It indexes into the Frame list and selects a frame. From the frame, TDs one by one are executed, and their status marked in the TD itself. The TDs can be optionally marked to generate Interrupts on Completion (IOCs). This goes on and on. When interrupts are not available for use, we can poll for their status and recognize their completion. | ||
| - | |||
| ===== How do we use this in a USB NIC ===== | ===== How do we use this in a USB NIC ===== | ||
| Line 64: | Line 63: | ||
| === Receiving Packets === | === Receiving Packets === | ||
| - | When the device is opened, we create as many rx buffers as our device's rx queue can hold and send it out on the USB for the device to fill in received data. When our driver's poll() method is called, we check the status of those requests by examining the TDs corresponding to that request. If they're done, we pass it on to the higher layers. We again create fresh rx buffers and fill the device's rq queue to the brim. This will go on similarly. | + | First, we allocate empty buffers for incoming packets. Next, we need to instruct the device to put data into that buffer. To do this, we create a chain of TDs in a way similar to the method used for transmitting packets. The host controller can figure out the direction of data transfer from the endpoint we've addressed the TDs to since each endpoint is a simplex channel. When our TDs get 'executed' in the schedule, they will have data in them. |
| + | |||
| + | When the device is initialized we create many empty buffers and ask the USB controller to insert it into the schedule. In the poll method, we check for filled buffers. We hand away received packets to upper layers and add buffers in the schedule for receiving data. This process continues as long as the device is open. | ||
| + | |||
| + | Also, in the poll method, we handle completion of tx packets by signalling (un)successful transmission of data to the upper layers. | ||
| - | We handle completed tx packets similarly, in the poll() method of our driver. | ||
