[rt2x00-users] rt2x00queue_status_timeout

[Ivo Van Doorn]

Hi,

> I'm currently staring at rt2x00queue_status_timeout()
> and rt2x00queue_dma_timeout().
>
> static inline int rt2x00queue_status_timeout(struct data_queue *queue)
> {
>        return time_after(queue->last_action[Q_INDEX_DMA_DONE],
>                          queue->last_action[Q_INDEX_DONE] + (HZ / 10));
> }
>
>
> - if the last frame is in state Q_INDEX_DMA_DONE, then
>  queue->last_action[Q_INDEX_DONE] will be from the previous
>  packet, i.e. some arbitrary time in the past
>
> - no matter how much time passes, the result of
>  rt2x00queue_status_timeout() will not change since it does
>  not compare against jiffies;

Well as soon as the index is updated, the last_action is updated
with the jiffies value. Thus, as long as the index counter changes,
rt2x00queue_status_timeout will return a different value.

>  i.e. if two frames are processed in quick succession and the
>  TX status from the second one is missing, rt2x00queue_status_timeout()
>  will not flag the timeout until eventually the next frame is tranmitted

True.

> So, maybe we need something like this:
>
>
> static inline int rt2x00queue_status_timeout(struct data_queue *queue)
> {
>        return (check current entry is in state Q_INDEX_DMA_DONE)
>                && time_after(jiffies,
>                              queue->last_action[Q_INDEX_DMA_DONE] + (HZ / 10));
> }
>
>
> Except there is another problem that TX status happens asynchronous
> (for rt2800pci, and soon for rt2800usb), thus we can have
>
>  frame1 DMA done
>  frame2 DMA done
>  waiting for frame1 TX status done
>
> thus rt2x00queue_status_timeout() for frame1 would compare
> to the wrong timestamp.

Your analysis sounds right, but the problems you encounter are
for situations where timeout() returns false while it should have been
true. However, isn't the timeout returning true too often already?

Ivo