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