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
Attachment:
signature.asc
Description: This is a digitally signed message part
