This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001814] Kinetis clock gating
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Sat, 06 Apr 2013 06:17:26 +0000
- Subject: [Bug 1001814] Kinetis clock gating
- Auto-submitted: auto-generated
- References: <bug-1001814-104 at http dot bugs dot ecos dot sourceware dot org/>
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #3 from Mike Jones <mjones@linear.com> ---
Ilija,
I think the problem was you incorporated part of my GPIO patch and I patched
against my changes rather than a fresh tree. So with some hand editing I fixed
it. I can run my applications tomorrow to make sure nothing breaks and perhaps
play with the added API a little to turn off what I am not using.
I noticed the datasheet says in section 5.6 the peripheral should be disabled
before stopping their clock. I did not look, but is there API similar to these
+__externC void hal_clock_enable( cyg_uint32 clkcd );
+__externC void hal_clock_disable( cyg_uint32 clkcd );
for disabling peripherals? If not, I wonder if the clock API should handle that
at the same time. I assume that stopping a clock and then enabling it again
with the peripheral enabled might lead to unpredictable behavior. Perhaps
disable clock should disable the peripheral. I am not sure I would want it to
enable it, in case some setup was required before starting the clock.
Mike
--
You are receiving this mail because:
You are on the CC list for the bug.