On Sun, Oct 6, 2013 at 8:48 PM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote: > On Mon, Oct 07, 2013 at 10:39:34AM +0900, Chanho Park wrote: >> > > Why didn't you use a cookie value to track the request? >> > > The cookie is assigned when each transfer is submitted. >> > > If you save the value in the desc, we can find the request easily. >> > >> > If there are several cyclic desc in the work list, is there a better way >> > to find the "current" one? The chan struct tracks the last completed and >> > last submitted cookies, but these will be the first and last >> > respectively as long as the cyclic transfer is active. Is there an >> > "active" cookie stored somewhere that I missed? >> >> Assume there are three cookies. If you want to get the second cookie not >> latest cookie, your way can be also correct in such case? >> I think tx_status API is to get dma status of the given cookie. >> You are only considering a cyclic case. > For cyclic case you would have possible same descriptor running till you > terminate. The cyclic case that makes this interesting is when there are multiple cyclic descriptors in the list. The cookie and completed_cookie markers don't help to determine which of the descriptors in the list is currently active. dma_cookie_complete isn't called for a cyclic desc, the desc is just pushed to the end of the list. > > For non cyclic, if you have 3 descriptors submitted, the cookie value can be, say > 7, 8 and 9. If you query the status of any descriptor and pass the last optional > txstate arg then you will know the last cookie completed. so if txstate->last is > 7, then 7th was completed and 8 should be running and 9 in queue! Got it, but the correct desc for cookie 8 will still have to be searched for, correct? Thanks for the advise. Dylan >> > Looking for the first buffer with status == BUSY is an improvement I'll >> > make. Any way to avoid looking through the list? > Its already there :) > > -- > ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |