[Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power

[bugzilla-daemon@bugs.ecos.sourceware.org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456

--- Comment #7 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 14:22:40 GMT ---
Thanks for your message Ilija.

I gave a look at the Kinetis I2C driver being discussed these days. I don't
know if it has similar problems, I don't have a Kinetis target at hand. I think
so when I see this in the end of the ISR code:

...
    }
  else
    {
      /*
       * Invalid state? Some kind of spurious interrupt? Ignore it.
       */
      I2C_TRACE("I2C spurious interrupt\n");
    }
...

However the interrupt seems to be cleared into the peripheral, it isn't masked
in the Cortex-M core itself (beginning of ISR code):

...
  // clear interrupt
  i2c_s->s |= FREESCALE_I2C_S_IICIF_M;
...

If the interrupt is disabled in the peripheral itself, then the Cortex-M core
may not see new interrupts (depends of the peripheral), so the interrupt
pending condition won't happened.

So if you test a driver that doesn't disable interrupts this way, for instance
any driver still compatible with a non Cortex-M core and ported to your
Cortex-M target and that relies only on interrupt_mask/unmask/acknowledge (like
the generic serial driver), you should get the same problem.

The easiest way to see it is to count the number of time the DSR is called, and
the number of times the DSR is called but does nothing.

This second counter should be zero or near zero, depending of the way the
peripheral works and if there are other hidden issues giving the same side
effect (like the bug in the generic serial driver that triggers the TX
interrupt before filling the TX FIFO).

BTW I found that counting the times a DSR is run without doing nothing gives
valuable info about a driver's sanity and tells if in depth analysis of the
driver is required. I also count the number of data that comes in/out, the
number of times the DSR is called, and the ratio data_in_out/dsr_calls gives
also indication about the driver's efficiency.

When I started looking at the generic serial driver ported to the the LPC17XX,
IIRC, this ratio was <1 byte exchanged per DSR call(!). Having 16 bytes FIFO it
was obvious I had to open the bug chase even if the code is more than 10 years
old and considered to be reliable.

My current ratio is now an average of 13 bytes processed per DSR calls (testing
file transfers), the RX FIFO trigger being set at 14 bytes: I know that I now
have something much more efficient and probably bug free.

-- 
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.
>From ecos-bugs-return-8815-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 14:23:04 2012
Return-Path: <ecos-bugs-return-8815-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 14175 invoked by alias); 9 Feb 2012 14:23:03 -0000
Received: (qmail 14166 invoked by uid 22791); 9 Feb 2012 14:23:02 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
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; Thu, 09 Feb 2012 14:22:48 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 882112F78009; Thu,  9 Feb 2012 14:22:47 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: bernard.fouche@kuantic.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001456-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Thu, 09 Feb 2012 14:23:00 -0000
Message-Id: <20120209142246.04E842F78006@mail.ecoscentric.com>
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00244.txt.bz2
Content-length: 2746

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456

--- Comment #7 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 14:22:40 GMT ---
Thanks for your message Ilija.

I gave a look at the Kinetis I2C driver being discussed these days. I don't
know if it has similar problems, I don't have a Kinetis target at hand. I think
so when I see this in the end of the ISR code:

...
    }
  else
    {
      /*
       * Invalid state? Some kind of spurious interrupt? Ignore it.
       */
      I2C_TRACE("I2C spurious interrupt\n");
    }
...

However the interrupt seems to be cleared into the peripheral, it isn't masked
in the Cortex-M core itself (beginning of ISR code):

...
  // clear interrupt
  i2c_s->s |= FREESCALE_I2C_S_IICIF_M;
...

If the interrupt is disabled in the peripheral itself, then the Cortex-M core
may not see new interrupts (depends of the peripheral), so the interrupt
pending condition won't happened.

So if you test a driver that doesn't disable interrupts this way, for instance
any driver still compatible with a non Cortex-M core and ported to your
Cortex-M target and that relies only on interrupt_mask/unmask/acknowledge (like
the generic serial driver), you should get the same problem.

The easiest way to see it is to count the number of time the DSR is called, and
the number of times the DSR is called but does nothing.

This second counter should be zero or near zero, depending of the way the
peripheral works and if there are other hidden issues giving the same side
effect (like the bug in the generic serial driver that triggers the TX
interrupt before filling the TX FIFO).

BTW I found that counting the times a DSR is run without doing nothing gives
valuable info about a driver's sanity and tells if in depth analysis of the
driver is required. I also count the number of data that comes in/out, the
number of times the DSR is called, and the ratio data_in_out/dsr_calls gives
also indication about the driver's efficiency.

When I started looking at the generic serial driver ported to the the LPC17XX,
IIRC, this ratio was <1 byte exchanged per DSR call(!). Having 16 bytes FIFO it
was obvious I had to open the bug chase even if the code is more than 10 years
old and considered to be reliable.

My current ratio is now an average of 13 bytes processed per DSR calls (testing
file transfers), the RX FIFO trigger being set at 14 bytes: I know that I now
have something much more efficient and probably bug free.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
>From ecos-bugs-return-8817-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 21:46:54 2012
Return-Path: <ecos-bugs-return-8817-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 2013 invoked by alias); 9 Feb 2012 21:46:53 -0000
Received: (qmail 1998 invoked by uid 22791); 9 Feb 2012 21:46:52 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
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; Thu, 09 Feb 2012 21:46:24 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 8A0052F78005; Thu,  9 Feb 2012 21:46:23 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001453] CAN IO package: wider flags field, flag to report
 return to 'error active' mode
X-Bugzilla-Reason: AssignedTo
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: sergei.gavrikov@gmail.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: <bug-1001453-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001453-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Thu, 09 Feb 2012 21:46:00 -0000
Message-Id: <20120209214620.E06D92F78006@mail.ecoscentric.com>
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00246.txt.bz2
Content-length: 488

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001453

--- Comment #21 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-09 21:46:13 GMT ---
Now in CVS (a few small corrections was applied).

Thank you for your contribution to eCos.

Sergei

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.