Benoit Cousson <b-cous...@ti.com> writes: > Some initiator modules in OMAP2 & 3 does not have IDLEST bit, > in that case we cannot detect the module readiness by > polling that bit and must exist the function immediately > assuming that the module is ready. > > The previous flag was affected to the OCP interface. While it is > technically true that the idlest is related to the L4 slave > interface of the module, the PRCM status belong to the module. > > Signed-off-by: Benoit Cousson <b-cous...@ti.com> > Cc: Paul Walmsley <p...@pwsan.com>
We had some discussions off-list on this patch... summarizing below. > --- > arch/arm/mach-omap2/omap_hwmod.c | 2 +- > arch/arm/plat-omap/include/plat/omap_hwmod.h | 8 +++++--- > 2 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_hwmod.c > b/arch/arm/mach-omap2/omap_hwmod.c > index 4a134c4..6459d07 100644 > --- a/arch/arm/mach-omap2/omap_hwmod.c > +++ b/arch/arm/mach-omap2/omap_hwmod.c > @@ -808,7 +808,7 @@ static int _wait_target_ready(struct omap_hwmod *oh) > > os = *oh->slaves + oh->_mpu_port_index; > > - if (!(os->flags & OCPIF_HAS_IDLEST)) > + if (oh->flags & HWMOD_NO_IDLEST) > return 0; This changes the default from assuming a module doesn't have an IDLEST to assuming it does. Because of this, we now get a bunch of failures in _enable() on OMAP2/3 due to missing fields in the hwmods, in particular the members of the 'struct omap_hwmod_omap2_prcm' are required to get correct _wait_for_ready() behavior. Therefore, when creating new hwmods, please be sure the fields of this struct are filled out and correct. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
