> > Then the inc_deq() code could just be:
> >
> > ring->deq_updates++;
> > ring->num_trbs_free++;
> >
> > if (last_trb(xhci, ring, ring->deq_seg, ++ring->dequeue)) {
> > ring->deq_seg = ring->deq_seg->next;
> > ring->dequeue = ring->deq_seg->trbs;
> > if (ring->deq_seg == ring->first_seg) /* not sure of name */
> > ring->cycle_state ^= 1;
> > }
>
> The cycle state is only changed when the enqueue pointer makes it past
> the segment with the toggle bit. It shouldn't be modified for the
> dequeue pointer.
Except for the event ring.
I did think that was a quick rewrite of the existing functionality.
Really the code for the event and command rings needs separating completely.
It would all then be clearer.
> And yes, inc_deq() could do with some simplification. David, are you
> interested in creating a patch to simplify this code? I haven't gotten
> v2 revisions from a couple of patches you previously sent, so I wasn't
> sure if you're still interested in creating xHCI patches.
I will sort out my existing patches hopefully today.
git managed to trash my source tree and I've been busy fixing some
of my own code.
I was waiting for the patches I'd posted to get processed before
adding many more. Otherwise it all gets completely out of hand.
Also I've dropped you (Sarah) from the mail address list, our work email
server is getting very strange bounces for linux.intel.com and I think
the list carefully avoids delivering mails to addresses in the mail itself.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
