Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
soc:2008:mdeck:journal:week4 [2008/06/19 20:02] mdeck |
soc:2008:mdeck:journal:week4 [2008/06/25 10:34] (current) mdeck |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ---- | ---- | ||
| - | === 16 June === | + | === 16 & 17 June === |
| I added dynamic allocation of RFDs today. | I added dynamic allocation of RFDs today. | ||
| Line 23: | Line 23: | ||
| Also, since RFDs are initialized both in ''ifec_net_open()'' as well as ''ifec_net_poll()'', I moved the initialization code for RFDs into ''ifec_rfd_init()''. And of course I added code in ''ifec_net_close()'' to free the io_buffers in the ''rx_iobs'' array. | Also, since RFDs are initialized both in ''ifec_net_open()'' as well as ''ifec_net_poll()'', I moved the initialization code for RFDs into ''ifec_rfd_init()''. And of course I added code in ''ifec_net_close()'' to free the io_buffers in the ''rx_iobs'' array. | ||
| - | === 17 & 18 June === | + | === 18 June === |
| - | I spent the 17th implementing **multiple TCB support**. It involved setting the final TCB to enter suspend mode, and each transmit request would issue a start command. Unfortunately, I didn't make a commit at this point, which I should have. | + | I spent today implementing **multiple TCB support**. It involved setting the final TCB to enter suspend mode, and each transmit request would issue a start command. Unfortunately, I didn't make a commit at this point, which I should have. |
| - | I spent the 18th attempting to rewrite the tx support such that the card never entered suspend mode. I hoped to keep the card in a loop processing NOP commands while nothing was ready to transmit. After many attempts I found it appears that the card will enter the idle state if it receives a command with the OK and C bits set. These bits are set after a command is processed. Thus, it won't remain active while processing NOP commands unless I clear certain bits after it processes them the first time. | + | === 19 June === |
| + | |||
| + | I spent today attempting to rewrite the tx support such that the card never entered suspend mode. I hoped to keep the card in a loop processing NOP commands while nothing was ready to transmit. After many attempts I found it appears that the card will enter the idle state if it receives a command with the OK and C bits set. These bits are set after a command is processed. Thus, it won't remain active while processing NOP commands unless I clear certain bits after it processes them the first time. | ||
| So it would seem either suspending the card or setting it idle is necessary, unless you have enough TCBs to keep the card busy between calls to ''ifec_net_poll()''. I'm not sure what the difference between suspend mode and idle mode is, aside from a resume command affecting them differently. | So it would seem either suspending the card or setting it idle is necessary, unless you have enough TCBs to keep the card busy between calls to ''ifec_net_poll()''. I'm not sure what the difference between suspend mode and idle mode is, aside from a resume command affecting them differently. | ||
| I'll have to work on this some more when I get back from my cousin's wedding. It seems that both Linux drivers place the card into suspend mode when the end of the transmit ring is reached, so that seems the feasible way to go. | I'll have to work on this some more when I get back from my cousin's wedding. It seems that both Linux drivers place the card into suspend mode when the end of the transmit ring is reached, so that seems the feasible way to go. | ||
