On Mon, Nov 8, 2010 at 12:39 PM, Ming Lei <tom.leiming@xxxxxxxxx> wrote: > 2010/11/8 Bob Liu <lliubbo@xxxxxxxxx>: >> On Mon, Nov 8, 2010 at 12:15 PM, Ming Lei <tom.leiming@xxxxxxxxx> wrote: >>> 2010/11/8 Bob Liu <lliubbo@xxxxxxxxx>: >>>> >>>> Hi, Felipe >>>> >>>> After apply this patch, we will still get data corruption on blackfin >>>> platform(g_zero test) >>>> even following all of MingLei's suggestion. >>> >>> Maybe it is another problem, but I have asked you to post your >>> log when the corruption issue happened, seems you did not provide >>> anything, so how could you hope to get further help from community? >>> >> >> Hi, Ming >> >> I think i have posted the information in my mail on Oct 22. >> I described the error situation. >> If more log is needed, please feel free asking me and which musb_debug >> level is needed. > > Please use level 5 first. > >> >>>> >>>> As you said >>>> "NAK. I have observed data corruption when using double buffering on >>>> tusb6010, omap3430 and omap3630." >>>> when cliff first upload patch "USB: musb: disable double buffering for >>>> older RTL versions". >>>> link:http://marc.info/?l=linux-usb&m=126472940418964&w=2 >>> >>> Anyway, this patch sent by cliff is wrong, I have explained it before, >>> so it is certainly to be fixed. Without the patch, g_ether is broken and >>> all full speed tests are broken. There are two guys who complained the >>> broken g_ether caused by cliff's patch already, but fixed by my patch. >>> >>> Â Â Â Â http://marc.info/?l=linux-omap&m=128894639005312&w=2 >>> Â Â Â Â http://marc.info/?t=128640815600002&r=1&w=2 >>> >>>> So could you please confirm this issue? >>>> This patch won't cause data corruption on tusb6010, omap3430 and >>>> omap3630 any more? >>> >>> Both beagle B5, C4 and -xM are OK(f_storage/g_zero/g_ether) wrt. double >>> buffer mode after applying my patch. ÂSo I suggest the patch [USB: musb: >>> gadget: fix MUSB_TXMAXP and MUSB_RXMAXP configuration] should be >>> merged into mainline first. >>> >>> For blackfin's data broken issue, we may dig into further if any log >>> can be provided by ADI guys. Also the patch below >>> >>> Â Â Â Â Â http://marc.info/?l=linux-usb&m=128750402903278&w=2 >>> >>> is sure to be needed if bfin want to work well with double buffer mode. >>> Have you tried the patch on bfin? Anyway, you should post your musb log >>> when data corruption is triggered. >>> >> >> I have added that patch, and all i have also posted the diff result on > > I wonder why you post the diff, can not you apply the patch > against mainline directly? > >> my platform in mail >> date Oct 22. >> you can see what patch i have applied for testing. > > > -- > Lei Ming > Hi, Ming I found out the cause of this problem on our platform. According to our hardware reference manuel, big changes are needed to support double buffer(eg. it depends on SOF interrupt and rxcsr fifofull bit etc). We need more time to work on these. So Felipe, is patch like this can be accepted ? ============ - if (musb->hwvers < MUSB_HWVERS_2000) if (musb->hwvers < MUSB_HWVERS_2000 && !musb->dyn_fifo) musb_writew(regs, MUSB_TXMAXP, hw_ep->max_packet_sz_tx); else musb_writew(regs, MUSB_TXMAXP, musb_ep->packet_sz | (musb_ep->hb_mult << 11)); or - if (musb->hwvers < MUSB_HWVERS_2000) if (musb->hwvers < MUSB_HWVERS_2000 && musb->config->gpio_vrsel) musb_writew(regs, MUSB_TXMAXP, hw_ep->max_packet_sz_tx); else musb_writew(regs, MUSB_TXMAXP, musb_ep->packet_sz | (musb_ep->hb_mult << 11)); If not, are there any suggestions how to deal with this problem. How to support no dyn_fifo and only support single buffer platform ? -- Thanks, --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
