On 06/28/2013 07:47 PM, Michael Trimarchi wrote: > Hi > > On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote: >> On 06/28/2013 02:33 PM, Michael Trimarchi wrote: >>> Hi Roger >>> >>> On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote: >>>> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi >>>> <michael@xxxxxxxxxxxxxxxxxxxx> wrote: >> >>>> Do you have locks around this software workaround? >>>> The patch I did against 3.4 linux kernel may be helpful for >>>> you in such case: http://review.omapzoom.org/28515 >>>> Another patch extends this WA for all OMAP4 SoCs: >>>> http://review.omapzoom.org/31108 >>> >>> I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so >>> the problem could be: >>> >>> 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion >>> could be it a problem? >> >> If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the >> issue if OFF mode is disabled? If yes then it probably is not related to SAR. >> >>> >>> 2) idle status of ulpis pins? >> >> Yes this can be possible. >> >> When you said earlier that the problem doesn't happen when one of the ULPIs is used >> did you try both of them individually. e.g. case 1: port 1 only enabled, >> case 2: port 2 only enabled. >> >> Did it work in both the cases? > > Yes, so I don't think could be a problem of ulpi pins and why this happen > on both at the same time? Seems more connected to somenthing else. > Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously. I'm not sure how to go about fixing this. How important is OFF Mode for your application. Can you keep it always disabled? cheers, -roger -- 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
