On Tue, Oct 16, 2012 at 04:53:28PM +0300, Felipe Balbi wrote: > Hi, > > On Tue, Oct 16, 2012 at 05:10:39PM +0530, Vikas Sajjan wrote: > > Hi Felipe, ... > did you have a transfer going through when you suspended ? If you > didn't, then you haven't stressed well enough. > > > 2) We tested by running command > > echo +20 > /sys/class/rtc/rtc0/wakealarm && echo mem > /sys/power/state > > that's ok, but try something like: > > # dd if=/dev/urandom of=/dev/sdXX bs=1M count=99999999 & > # echo +20 > /sys/class/rtc/rtc0/wakealarm && echo mem > /sys/power/state > > Better yet, generate a big (and I really mean big :-) file with a known > pattern (make a sequence from 0x00 to 0xff and back to zero, over and > over again) then write that file to the mass storage device, while > transfer is on the fly, suspend, then resume and see if transfer > continues, then later verify the bytes by reading back the data and > comparing with original source file. > > Do this for both Host and Peripheral roles. I have a rather big > suspicion that it won't work, in which case we need to make sure to > prevent suspend while transfers are on the fly or do something else. For system suspend while the DW3 hardware is in host mode, doesn't the USB core prevent drivers from submitting URBs just before the PCI/platform suspend is called? Alan? If the USB core doesn't quiesce URBs before system suspend, then we probably have a larger issue that the generic xHCI driver should take care of. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
