On Sat, Jun 09, 2012 at 04:40:03, Paul Walmsley wrote: > Hi > > On Fri, 8 Jun 2012, Hiremath, Vaibhav wrote: > > > In case of AM33xx, recently I came across similar issue (rather more > > than this) with CPSW module. > > > > The issue is, > > > > We have observed that, in order to disable the CPSW module > > (MODULEMODE=0x0), We have to assert OCP level reset, before disabling > > it; else module enters into unknown state, where register status shows, > > MODULEMODE turns 0x0, but idlests says module is busy. > > > > This has to be done everytime you try to disable the module. > > > > The worst part here is, CPSW has 4 submodules (SS, SL1, SL2, CPDMA), > > We have to assert reset signal to each submodules. > > > > So the approach I had taken is, I had implemented almost similar > > function specific to cpsw and introduced flag called > > HWMOD_SWSUP_RESET_BEFORE_IDLE. > > Why "SWSUP" ? > Since it was SW initiated reset assertion so I added this prefix. > > Now the question here would be, should we consider this IP bug or > > integration bug? If it is integration bug, then isn't this device issue? > > I don't know if it's a bug in either place, but it sounds like something > that needs to be handled in the _am335x_disable_module() code in > mach-omap2/omap_hwmod.c. > Yes, certainly it should be part of _am335x_disable_module(). Thanks, Vaibhav -- 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
