From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8988 invoked by alias); 24 Dec 2012 17:38:40 -0000 Received: (qmail 8798 invoked by uid 22791); 24 Dec 2012 17:38:37 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Dec 2012 17:38:32 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 5DD444680019 for ; Mon, 24 Dec 2012 17:38:31 +0000 (GMT) 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 n94RI2XVGmtR; Mon, 24 Dec 2012 17:38:28 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001397] I2C driver for Kinetic microcontrollers 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: NEEDINFO X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 24 Dec 2012 17:38:00 -0000 Message-Id: <20121224173828.248BE4680002@mail.ecoscentric.com> 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 X-SW-Source: 2012-12/txt/msg00026.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397 Mike Jones changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjones@linear.com --- Comment #28 from Mike Jones 2012-12-24 17:38:26 GMT --- I can make a couple of comments based on my experience with K60 and the Freescale POSIX I2C driver and a real application. First is the issue of using the interrupt driver vs polling driver. I use the interrupt driver so that other tasks can operate while waiting. My application is PMBus, and clock stretching can slow things down, so I figure I don't want to be in a polling loop. Second, is the issue of polling on bits. I discovered that the Freescale driver polls on bits at times, even when using the interrupt driver. This causes some serious problems in real use. I'll give an example. When multimastering, it is always possible to have a misbehaving master. I have one of these, and it basically breaks the rules and asserts the clock or data line randomly. Because I can't predict what master might misbehave, I tried to make the telemetry task immune to this. What I did was create a watchdog. Since most of my PMBus/I2C transactions are telemetry, it is easy to do. When the misbehaving master does its deed, I found the I2C driver got stuck in a polling loop on a bit, even though it was in interrupt driver. Once in this condition, you are helpless to get out of the loop without modifying the driver code, because it does not have a counter/timeout on the loop. The driver assumes the other masters and slaves follow the rules. So my watchdog kills the task and tries to recover. This means my code has to clean up the I2C driver state either by reopening the device, or manually. This proved a bit difficult because in MQX once you are stuck in this loop, you can't clean up mutexes from a different task. So you have a catch 22. If you don't kill it, you can't get out of the loop and have it clean up. And if you kill it, you can't clean up because you don't have permission. So I had to create tasks that did not own the resources so I could kill the task and clean up. Then I restart the task. This is a pretty nasty way to deal with the problem, but it does in fact work. In general, a bad master will not be a permanent state of affairs. A bad master is probably someone putting a USB based dongle on the bus for debug, programming, etc. A production hardware will probably behave, but even then, in High Availability systems, one may still want to try to recover. So potential solutions are to have driver calls that timeout or driver calls that when stuck, can easily be cleared. If a watchdog can make a call to cause the driver to break its loop and return an error, one can solve the stuck loop that was as well. If you use a timeout, it is best to remain compliant with PMBus/SMBus and set the loops to timeout on a specific time, and best if you use a hardware timer so the loop does not consume the CPU. From my point of view this just suggests making a easy way for the watchdog to kill the stuck loop at clean up so that the time function is under the application's control. But I would still use an interrupt approach in general for those things where the I2C peripheral supports it. I don't know why and when people use the Freescale polled driver. Perhaps there is a case where other uses of interrupts makes this a problem. So I guess for completeness you could do both. The Freescale driver code is publicly available for inspection. I am not familiar with it. The last thing I will say is that a good I2C driver will open up opportunities for eCos. eCos would be a good choice for implementing IPMI Board Controllers, which is my area of interest. -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.