From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5229 invoked by alias); 6 Apr 2013 06:17:40 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 5219 invoked by uid 89); 6 Apr 2013 06:17:40 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,TW_KC autolearn=ham version=3.3.1 Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 06 Apr 2013 06:17:36 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id AD2DC4680006 for ; Sat, 6 Apr 2013 07:17:34 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9gKAxzw9Syf; Sat, 6 Apr 2013 07:17:28 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001814] Kinetis clock gating Date: Sat, 06 Apr 2013 06:17:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: mjones@linear.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg00009.txt.bz2 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 --- 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.