AM335x CPSW reset (was "RE: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)")

Hiremath, Vaibhav hvaibhav at ti.com
Sat Jun 9 04:39:32 EDT 2012


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




More information about the linux-arm-kernel mailing list