2010/9/30 Cai, Cliff <Cliff.Cai@xxxxxxxxxx>: > > >>-----Original Message----- >>From: tom.leiming@xxxxxxxxx [mailto:tom.leiming@xxxxxxxxx] >>Sent: Wednesday, September 29, 2010 8:56 PM >>To: greg@xxxxxxxxx; balbi@xxxxxx >>Cc: linux-usb@xxxxxxxxxxxxxxx; Ming Lei; Cai, Cliff; David >>Brownell; Anand Gadiyar; Mike Frysinger; Sergei Shtylyov; >>stable@xxxxxxxxxx >>Subject: [PATCH 2/2] USB: musb: gadget: fix MUSB_TXMAXP and >>MUSB_RXMAXP configuration >> >>From: Ming Lei <tom.leiming@xxxxxxxxx> >> >>Commit 9f445cb29918dc488b7a9a92ef018599cce33df7[USB: musb: >>disable double buffering for older RTL versions] tries to >>disable double buffer mode by writing endpoint hw max packet >>size to TXMAP/RXMAP. >> >>First this way taken is very wrong, which can break full speed >>mode and cause overflow problem, and we should always set this >>registers by the actual max packet size from endpoint descriptor. > > Double buffering is the hw(musb) specific feature.I guess I don't > Understand your idea. If you write hw_ep->max_packet_sz_tx to MUSB_TXMAXP, musb chip sends packet with this size always in usb bus. At full speed mode, max packet size is much less than that of high speed mode, so overflow problem can happen. We should always set this register with the value from endpoint descriptor. You can reproduce the problem easily by connecting musb gadget with one uhci or ohci only usb host controller. Also hw_ep->max_packet_sz_tx is only half size of the actual endpoint hw fifo size in double buffer mode, and double buffer feature is indicated by hw_ep->tx_double_buffered. So your previous commit is wrong... > >>Secondly, I have fixed the double buffer mode problem already >>in the previous patchset, and found the problem of 'infinite >>hangs or data corruption' decribled in Commit >>9f445cb29918dc488b7a9a92ef018599cce33df7 >>is caused by musb gadget driver, nothing to do with older RTL chip. >>My beagle B5 uses RTL 1.4 musb IP core, but either >>g_file_storage/g_ether /g_zero can work well in double buffer mode. > > I'm not sure if your test cases cover the tests which will cause the > data > Corruption problem. All usbtest #5, usb test#6, g_file_storage and g_ether have been verified OK in double fifo mode(set fifo mode as 3), and all the tests are done on my beagle B5(musb RTL 1.4). Did the tests above cover your test cases? If not, could you public your test cases, which you think it may trigger the infinite and data corruption problem? Most patches for double buffer mode support have been merged to 2.6.36-rc6, if you plan to test this, you need to apply the two patches below against 2.6.36-rc6: http://marc.info/?l=linux-usb&m=128532511805416&w=2 http://marc.info/?l=linux-usb&m=128576494214316&w=2 For detailed test description, please see each commit log. thanks, -- Lei Ming -- 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
