This is the mail archive of the
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 12:47:31 +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.
Ilija Kocho <email@example.com> changed:
What |Removed |Added
Attachment #2155|0 |1
is obsolete| |
--- Comment #4 from Ilija Kocho <firstname.lastname@example.org> ---
Created attachment 2162
Kinetis HAL clock gating (fix, ref comment 3)
(In reply to comment #3)
> 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.
Thank you for the catch. It is there by accident. I used the same eCos
repsitory for testing of your contribution and it slipped of my mind.
Here I post a fixed patch.
> 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
Devices with disabled clock are inaccessible. Some are simply silent, but for
majority, access attempt raises exception. Besides this some devices have some
kind of enable feature. But there's no general rule, therefore it's up to the
device driver to take care of that.
You are receiving this mail because:
You are on the CC list for the bug.