> +/* Schedule next QH from musb->in_bulk and move the current qh to
> > + * the end; avoids starvation for other endpoints.
> > + */
> > +static void musb_bulk_rx_nak_timeout(struct musb *musb, struct musb_hw_ep *ep)
> > +{
> > + struct dma_channel *dma;
> > + struct urb *urb;
> > + void __iomem *mbase = musb->mregs;
> > + void __iomem *epio = ep->regs;
> > + struct musb_qh *cur_qh, *next_qh;
> > + u16 rx_csr;
> > +
> > + musb_ep_select(mbase, ep->epnum);
> > + dma = is_dma_capable() ? ep->rx_channel : NULL;
> > +
> > + /* clear nak timeout bit */
> > + rx_csr = musb_readw(epio, MUSB_RXCSR);
> > + rx_csr |= MUSB_RXCSR_H_WZC_BITS;
> > + rx_csr &= ~MUSB_RXCSR_DATAERROR;
> > + musb_writew(epio, MUSB_RXCSR, rx_csr);
>
> I don't think you want to clear the NAKTimeout bit without clearing ReqPkt
> as well since otherwise you're risking a race if the device decides to ACK the
> packet in the short window between this point and when you finally switch to
> another device...
Once we get NAK timeout limit there will not be any __IN token__ issued till the
next QH is scheduled. So no question of clearing ReqPkt or any race condition.
>
> > +
> > + cur_qh = first_qh(&musb->in_bulk);
> > + if (cur_qh) {
>
> Is the opposite even possible? I *highly* doubt it given the fact that
> this gets called with non-NULL URB.
>
> > + /* set rx_reinit and schedule the next qh */
> > + ep->rx_reinit = 1;
> > + musb_start_urb(musb, 1, next_qh);
>
> Note that the NAKTimeout bit will be cleared by musb_h_flush_rxfifo()
> called from musb_rx_reinit() a bit later anyway.
It doesn't. recheck.
>
> > @@ -1420,18 +1461,26 @@ void musb_host_rx(struct musb *musb, u8
> > } else if (rx_csr & MUSB_RXCSR_DATAERROR) {
> >
> > if (USB_ENDPOINT_XFER_ISOC != qh->type) {
>
> Why not change this to switch (qh->type) instead?
>
> > @@ -1751,6 +1800,17 @@ static int musb_schedule(
> > head = &musb->in_bulk;
> > else
> > head = &musb->out_bulk;
> > +
> > + /* Enable bulk RX NAK timeout scheme when bulk requests are
> > + * multiplexed. This scheme doen't work in high speed to full
> > + * speed scenario as NAK interrupts are not coming from a
> > + * full speed device connected to a high speed device.
> > + * NAK timeout interval is 8 (128 uframe or 16ms) for HS and
> > + * 4 (8 frame or 8ms) for FS device.
>
> It's not clear why the timeouts are different...
>
> WBR, Sergei
--
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
