On Wed, Nov 10, 2010 at 7:24 PM, Ming Lei <tom.leiming@xxxxxxxxx> wrote: > Hi Bob, > > 2010/11/10 Bob Liu <lliubbo@xxxxxxxxx>: >> Our spec said when double buffering enabled >> " >> Set up an ISR, sensitive to the SOF_B interrupt, that reads the >> FIFO_FULL_R bit, reads the USB_RXCOUNT status register, and finally >> removes one or two packets (equaling from the USB_RXCOUNT number >> of bytes) from the FIFO and clears RXPKTRDY. >> >> Set SOF_B=1 in USB_INTRUSBE to generate an interrupt on each start >> of frame. >> " > > Suppose you meet data corruption issue in test #5, so it is bulk transfer, > and should not be related with SOF in principle. > Yes, but our spec doesn't describe bulk transfer clearly(when in double buffer mode). If it also related with SOF as ISO transfer, it reasonable test #5 will fail. >> >> We didn't see g_ether problem on our platform without this patch, it works fine. >> Could you give detail step how to reproduce the g_ether problem? > > Did you test g_ether and g_zero(test #6) at full speed? > I don't think the tests at fullspeed can be OK without my patch. > Currently, we didn't test any full speed mode. I will check it soon. >> >> After added this patch, double buffer will always auto enabled on our >> platform which will cause >> problem as our spec said on double buffer mode it use SOF_B interrupt >> and FIFO_FULL_R bit etc. > > In fact, double buffer implementation inside chip should not be very difficult > and seems there should not be bugs here, so I guess musb IP doesn't > provide double buffer switch to disable the feature. > > Could you apply the attachment patch against linus tree plus musb patches > submitted by Felipe to feedback the log when the data corruption is triggered > by test #5? > I changed your patch 1. add more info during the printk 2. restore rx_double_buffer during musb_gadget_disable After apply it, test #5 can pass but with lots of print like: root:/> musb_gadget_disable musb_gadget_disable musb_gadget_enable hb_mult 0, MUSB_TXMAXP 512, hw_ep->max_packet_sz_rx 1024 musb_gadget_enable hb_mult 0, MUSB_RXMAXP 512,rx_double_buffered 1 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=3: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=3: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=3: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=3: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 epnum 6:csr=1: rx_double_buffered=1, len=438,hw_ep->max_packet_sz_rx=512,musb_ep->packet_sz=512 I think it's still too many printk which makes the delay time enough just like udelay(50), so the test can pass. > I remembered the similar problem touched me before, but was fixed by my > previous double buffer patches. Maybe bfin musb IP is newer version, and > something is not considered by previous patches. > > The patch only adds some debug messages to dump csr against the last > patch sent to Bob. > Thanks a lot for your help! -- Regards, --Bob -- 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
