Hi,
on my gta04 I experiment with idling uarts, so that they
runtime-suspend and suspequently some clocks are turned off.
To measure my success, I check the results via a bq27000 fuel gauge
connected to omap_hdq.
Unfortunately that does not work properly. I might get a single
byte written but nothing more.
So there is probably some clock problem.
Things checked:
I forced runtime on by
echo on >power/control for the omap_hdq device
Then I checked by accessing /dev/mem:
CM_FCLKEN1_CORE: mostly unset bits, bit 22 behaves ok
it is 1 when omap_hdq is runtime-active and 0 if not.
So ICLK remains the most interesting:
After some experiments I find the following:
clearing CM_AUTOIDLE1_CORE.AUTO_HDQ (something sets it) and
checking that CM_ICLKEN1_CORE.EN_HDQ is set
makes things work.
Doing RTFM reveals the following:
SPRUGN4R: AM/DM37x Multimedia Device
Silicon Revision 1.x TRM (p.2866):
> AUTO_HDQ bit PRCM.CM_AUTOIDLE1_CORE[22] is set. In this case, the
> software must verify that all HDQ/1-Wire transfers are complete
> before enabling the L4 interconnect clock domain idle mode.
> Otherwise, the HDQ/1-Wire has no way to prevent the clock from being
> cut, because no hardware mechanism exists. The steps listed in this
> section must be verified before putting the L4 clock domain into idle
> state.
So I guess that clearing That AUTO_HDQ bit is actually a good idea,
at least while hdq is used.
But then the next question arises: where is the code which accesses
CM_AUTOIDLE1_CORE?
I only find:
in cm3xxx.c:
omap2_cm_write_mod_reg(cm_context.core_cm_autoidle1, CORE_MOD,
CM_AUTOIDLE1);
Maybe I am a bit blind today, can someone enlighten me?
Thanks in advance for any ideas.
Regards,
Andreas
Attachment:
pgpIngsGfOcRB.pgp
Description: OpenPGP digital signature
