* Catalin Marinas | 2009-02-17 13:33:53 [+0000]: >In the ISP1761 manual, there are some timing diagrams for register >access. If I understand them correctly (as a software person), there is >something like minimum 86ns between the end of the write pulse to the >beginning of the read one. > >The fix below, as you suggested, works fine as well: > > >diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c >index ee56e01..054543c 100644 >--- a/drivers/usb/host/isp1760-hcd.c >+++ b/drivers/usb/host/isp1760-hcd.c >@@ -820,6 +820,8 @@ static void enqueue_an_ATL_packet(struct usb_hcd *hcd, struct isp1760_qh *qh, > u32 atl_regs, payload; > u32 buffstatus; > >+ /* wait for the SKIPMAP register to be updated */ >+ udelay(1); > skip_map = isp1760_readl(hcd->regs + HC_ATL_PTD_SKIPMAP_REG); > > BUG_ON(!skip_map); >@@ -854,6 +856,8 @@ static void enqueue_an_INT_packet(struct usb_hcd *hcd, struct isp1760_qh *qh, > u32 int_regs, payload; > u32 buffstatus; > >+ /* wait for the SKIPMAP register to be updated */ >+ udelay(1); > skip_map = isp1760_readl(hcd->regs + HC_INT_PTD_SKIPMAP_REG); > > BUG_ON(!skip_map); I would like to NAK this but I don't have a better idea for a proper fix. According to section 14.1.3, table 95 write - read delay is 195ns for EHCI op regs and the SKIPMAP register is one of those see table 8 in section 8. So the required delay should be 195ns. This constraint probably fails on fast boxes if we enqueue a following qtd-packet for the same urb in the interrupt handler. I tried to keep a copy of this register and write it back after the end. This is not going to work because we have to drop the spinlock in isp1760_urb_done() because the calback may enqueue another packet. So I thing we have to stick with this udelay(). So after long thinking I'm fine with this patch. Please update your comment and add _why_ this delay is required. I could live with something like | If we get called from the interrupt handler to enqueue a follow-up | packet the SKIP register gets written and read again almost | immediately. This register requires a delay of 195ns before a read can | happen after a write, see section 14.1.3 maybe you have a shorter version or one with better english :) You could proably use ndelay() instead of udelay() but it would result in the same thing on most archs. Sebastian -- 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
