[PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage

[tomi.valkeinen@ti.com (Tomi Valkeinen)]

On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
> On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
> > On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
> >
> >> The only little problem was that during bootup, when hwmods are setup,
> >> only the 'parent' hwmod was able to get reset properly, all the other
> >> 'child' hwmods don't have modulemode bits tied to them, and hence
> >> weren't able to reset. So we got some error prints.
> >>
> >> Once DSS driver kicks in, the driver ensures the parent is enabled for
> >> any child to be enabled, so we don't face the issue again.
> >>
> >> So, if DSS driver is not built in, and if the bootloader left DSS in a
> >> bad state, the DSS clocks might remain messed up all the time since
> >> hwmod fwk wasn't able to reset them.
> >>
> >> I think this is why we didn't proceed with remove "dss_fck" as a slave
> >> clock. If this issue is minor, we could go ahead and remove it.
> >
> > I wonder if we could handle this with a custom reset function. We
> > already have a reset func for dss core. If I remember right, the main
> > point for that is the fact that omap4 doesn't have a softreset for dss
> > core, so we manually write the default values to registers.
> >
> > For omap2/3 this would be simple: skip the resets for all other dss
> > submodules, and dss core's reset would enable all the clocks and set the
> > softreset bit. This would reset all the submodules also.
> >
> > Omap4 is more tricky. I guess we'd need to enable all the clocks, clear
> > manually dss core's registers, and then set softreset bits in all the
> > submodules. So in this case dss core would need to have information
> > about the other submodules.
> 
> The is a good idea. I don't clearly understand your approach though. Are 
> you saying we have a custom reset function for only dss core? And reset 
> the submodules in it manually?

Yes.

> An alternative approach would be to implement custom reset functions for 
> each submodule(or each hwmod), and in the beginning of every reset 
> function, add a hack to enable MODULEMODE bits(since we don't want hwmod 
> fwk to touch MODULEMODE for the DSS submodules), and then set the soft 
> reset bits.

I thought about that also. We'd need reset functions for all of them,
and for omap2/3 we'd just reset the submodules again as they have
already been reset with the dss core reset.

The dss submodule resets are a bit linked. For omap2/3 the connection is
obvious as dss core reset resets also the submodules, and for omap4 we
have this requirement for the modulemode. That's why I though it'd be
perhaps cleaner to handle the reset of the DSS block as a whole, in one
place.

> Your approach would ensure that we get a clean reset of DSS, but it 
> would still give the annoying prints when each of the submodule tries to 
> reset itself.

The other submodules would not be reset by the hwmod framework at all,
so there wouldn't be prints. I think there's a flag for that.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120831/def63783/attachment-0001.sig>