On Sat, 21 Jan 2012 17:07:18 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> wrote: > On Wed, 18 Jan 2012, NeilBrown wrote: > > > Oh - another thing. > > Sometimes during early boot I get: > > > > [ 0.158447] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck. > > [ 0.176879] omap_hwmod: hdq: softreset failed (waited 10000 usec) > > This latter bug just got fixed, it's updated in the new HDQ series that I > sent out: > > http://marc.info/?l=linux-omap&m=132719073710874&w=2 > > BTW, if you could give that a spin for us at some point, it would be > greatly appreciated; I don't think I have a board with a 1-wire device on > it (at least, not that I know of). Yes, the patch series seems to work OK - at least it doesn't break anything: I can still access my battery charge meter. It doesn't fix the problem I am having where HDQ gets confused when CPUIDLE kicks in, but I think I might have a handle on that now. Unlike other modules, HDQ doesn't have SIDLEMODE. According to 18.4.5 (AM/DM37x Multimedia Device Silicon Revision) it acts as though SIDLEMODE were set to SIDLE_FORCE so if the clock-domain trys to switch off, HDQ lets it. Normally UART has SIDLEMODE set to SIDLE_NO so that keeps the necessary clock domain active. But if I let the UARTs sleep, SIDLEMODE changes to SIDLE_SMART which can allow the clockdomain to be stopped, which affects HDQ. However I'm not sure how PRCM.CM_AUTOIDLE1_CORE fits into this. if AUTO_HDQ is clear - which it is by default and I cannot see code that changes it - then the clock for HDQ should be independent of .... something. I definitely see behaviour that looks like the HDQ clock stopping when the UART allows SIDLE_SMART or when I explicitly deny idling of the clockdomains. Should there be special handling of HDQ because it doesn't have SIDLEMODE?? Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
