From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1786 invoked by alias); 25 Dec 2012 23:38:07 -0000 Received: (qmail 1763 invoked by uid 22791); 25 Dec 2012 23:38:05 -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; Tue, 25 Dec 2012 23:37:59 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id BB9654680018 for ; Tue, 25 Dec 2012 23:37:58 +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 XSHL2ys8t--S; Tue, 25 Dec 2012 23:37:56 +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: 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: Tue, 25 Dec 2012 23:38:00 -0000 Message-Id: <20121225233756.53D814680002@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/msg00032.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 --- Comment #31 from Mike Jones 2012-12-25 23:37:55 GMT --- I think that looping on bus ready is probably ok if there is a SMBus like timeout of 25ms to 30ms, and as long as the scheduler can break in switch tasks. If the wait can't be interrupted by the scheduler it is more problematic when the bus is stuck. A worst case scenario might have a task for ALERTB and one for telemetry. The second master hogs the bus and the first master is having trouble getting in. The the ALERTB comes along and needs immediate service. The ALERTB task may flip a GPIO bit and kill power, or it may wait for the timeout and then attempt to use the bus. All that matters to me is that it the driver waits for the bus to be free, times out, and allows a higher priority task do its job while waiting. I would not want it to just return because the bus is busy and force me to write my own timeout. And I would not want it to hang forever if a second master was beating the bus to death. -- 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.