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

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

[bugzilla-daemon]

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

           Summary: HAL misses Interrupt Clear-Pending Registers handling:
                    wasted processing power
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: major
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


The way the Cortex-M3 manages peripheral interrupts require handling these
registers, otherwise an interrupt may be triggered multiple times.

I was looking for spurious interrupts on the LPC17XX CAN driver, and my error
was to skip handling of ICPR0 and ICPR1. The Cortex-M HAL must provide a
function like this:

//===========================================================================
// Clear pending interrupt.
//===========================================================================
__externC void hal_interrupt_clear_pending(cyg_uint32 vector )
{
    HAL_WRITE_UINT32(
CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_CPR(vector-CYGNUM_HAL_INTERRUPT_EXTERNAL),
                     
CYGARC_REG_NVIC_IBIT(vector-CYGNUM_HAL_INTERRUPT_EXTERNAL) );
}


This also means that when writing a driver, especially a driver with some kind
of FIFO mechanism, special care must be taken:

- it is impossible to have a general function able to fully acknowledge an
interrupt since the NVIC knows nothing of the inner details of all peripherals
and each peripheral is very different from the other. Hence
cyg_drv_interrupt_acknowledge() should not be used in Cortex-M drivers: it
resolves to an empty statement while letting the programmer think he/she had
done something useful while the situation is the exact opposite: nothing was
done, and an important step has been skipped. IMHO this function should
generate a message on diag_printf() and freeze the system (after some cdl
setting) on the Cortex arch.

- see next point why cyg_drv_interrupt_acknowledge() is different from the
function provided above: clearing the pending interrupt condition must be done
at a particular time, not at anytime during DSR processing, nor during ISR
processing. If the name 'acknowledge' is kept, it is likely that some design
flaw will occur in driver writing.

- when a driver reads a peripheral register to know what kind of job to do, the
corresponding ICPR register must be used to clear the pending interrupt state
first, before reading the driver specific interrupt register. Otherwise a race
condition may occur, at least in cases where the DSR is not looping until it
has completed everything that requires work to do: DSR clears reads the
peripheral register, thinks it knows everything, and just before clearing ICPR,
a new event occurs. By clearing ICPR at this time, an event may be missed
(depends probably of the kind of peripheral and of the way the MCU designed
cabler ICPR to the peripherals).

- IMHO it is necessary to have DSR to perform loops until they see no reason to
continue processing: a simple one time scanning of a peripheral with FIFO
registers will very probably lead to ISR/DSR being fired uselessly.

- even when doing loops but not handling ICPR, an other interrupt will be
triggered and in many cases the DSR will be fired just to discover that there
is nothing to do, the job has been done in the previous run. Sometimes I had
30% of the calls to the CAN DSR that were done without use, so it can be a real
waste.

- if the hardware has two different bits to reports two different conditions
(typically RX and Overrun), don't assume for instance that overrun shows up
only after a RX, unless explicitly stated in the datasheet. I've seen this on
the generic serial driver (made a report: bug #1001392 but nobody reacted about
it) and also on the CAN driver. This is because of the need to have loops in
DSR for efficient processing: if for some reasons the conditions are unrelated
but the code thinks they are, a loop based DSR may be stuck.

I did not investigate the generic serial driver behavior yet regarding ICPR but
I have seen ICPR issues on the SPI and CAN driver: I would be surprised to not
see this problem in the generic serial driver since it has a FIFO.

Checking the issue for any driver is rather simple: count the number of times
the DSR is fired without doing any processing. A non zero count means an ICPR
issue. The count value depends of a number of conditions hard to reproduce. For
instance an ISR may be fired 1000 times, the DSR 1032 times, it depends
entirely of what's going on the concerned peripheral, what the remote end is
doing, etc.

Conclusion:

- cyg_drv_interrupt_acknowledge() is misleading for Cortex-M.
- not handling IPCR -> wasted processing.
- handling IPCR incorrectly -> lost events.
- using a loop in a DSR that incorrect combines unrelated conditions -> stuck
program.

-- 
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.

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

[bugzilla-daemon]

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

--- Comment #1 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-16 16:28:46 GMT ---
Confirmed with ser_16x5x.c. 

Test config: 2 uarts used, one at 115200, the other at 9600, very light serial
traffic. HW flow control activated on uart at 115200, no flow control on uart
at 9600. (did not checked yet if HW flow control is really operational yet)

I've added a counter of DSR calls, a counter of RX/TX chars and a counter of
DSR calls that do nothing:

1st run:

(gdb) print ser_dsr_dbg_rx
$1 = 1230
(gdb) print ser_dsr_dbg_tx
$2 = 49
(gdb) print ser_dsr_dbg_calls
$3 = 3483
(gdb) print ser_dsr_dbg_spurious
$4 = 2228

2nd run, hal_interrupt_clear_pending() called before reading Interrupt
Identification Register (two reads in my version of the DSR):

(gdb) print ser_dsr_dbg_rx
$1 = 1230
(gdb) print ser_dsr_dbg_tx
$2 = 49
(gdb) print ser_dsr_dbg_calls
$3 = 1867
(gdb) print ser_dsr_dbg_spurious
$4 = 668
(gdb)

Much better but still a gremlin to find and kill, counter of spurious ints must
be zero. Anyway the numbers speak by themselves.

-- 
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-8684-listarch-ecos-bugs=sources.redhat.com@sourceware.org Mon Jan 16 16:29:10 2012
Return-Path: <ecos-bugs-return-8684-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 28570 invoked by alias); 16 Jan 2012 16:29:07 -0000
Received: (qmail 28561 invoked by uid 22791); 16 Jan 2012 16:29:04 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,TW_DB,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; Mon, 16 Jan 2012 16:28:52 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id AC3F22F7800F; Mon, 16 Jan 2012 16:28:50 +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: Mon, 16 Jan 2012 16:29:00 -0000
Message-Id: <20120116162849.2FA1F2F78005@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/msg00113.txt.bz2
Content-length: 1382

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

--- Comment #1 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-16 16:28:46 GMT ---
Confirmed with ser_16x5x.c. 

Test config: 2 uarts used, one at 115200, the other at 9600, very light serial
traffic. HW flow control activated on uart at 115200, no flow control on uart
at 9600. (did not checked yet if HW flow control is really operational yet)

I've added a counter of DSR calls, a counter of RX/TX chars and a counter of
DSR calls that do nothing:

1st run:

(gdb) print ser_dsr_dbg_rx
$1 = 1230
(gdb) print ser_dsr_dbg_tx
$2 = 49
(gdb) print ser_dsr_dbg_calls
$3 = 3483
(gdb) print ser_dsr_dbg_spurious
$4 = 2228

2nd run, hal_interrupt_clear_pending() called before reading Interrupt
Identification Register (two reads in my version of the DSR):

(gdb) print ser_dsr_dbg_rx
$1 = 1230
(gdb) print ser_dsr_dbg_tx
$2 = 49
(gdb) print ser_dsr_dbg_calls
$3 = 1867
(gdb) print ser_dsr_dbg_spurious
$4 = 668
(gdb)

Much better but still a gremlin to find and kill, counter of spurious ints must
be zero. Anyway the numbers speak by themselves.

-- 
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-8686-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 17 17:49:40 2012
Return-Path: <ecos-bugs-return-8686-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 16116 invoked by alias); 17 Jan 2012 17:49:34 -0000
Received: (qmail 16096 invoked by uid 22791); 17 Jan 2012 17:49:32 -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; Tue, 17 Jan 2012 17:49:18 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id E9F6B2FB085B; Tue, 17 Jan 2012 17:49:16 +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 1001269] Via Rhine Ethernet driver is reading the MAC
 incorrectly
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Ethernet
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: stephen@centtech.com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status Resolution
In-Reply-To: <bug-1001269-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001269-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: Tue, 17 Jan 2012 17:49:00 -0000
Message-Id: <20120117174915.53A6B2FF0027@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/msg00115.txt.bz2
Content-length: 1487

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

stephen@centtech.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #7 from stephen@centtech.com 2012-01-17 17:49:11 GMT ---
(In reply to comment #5)
> (In reply to comment #4)
>
> > Yes, I will test the patch out.  I have the hardware in my office.
> > I will email you when the testing is done.
>
> Stephen, could you test the patch? We appreciate any feedback.
>
> Sergei

Hello Sergei.  I am sorry for the delay.  My boss had me working on
other stuff until recently.  I applied your patch to the latest ecos
build tree. I have verified that your patch [attachment 1356]
fixes the bug in the VIA Rhine driver.

I built the VIA Rhine driver for the pc redboot package.  This
is a new package that I will be uploading to ECOS very shortly.
I was successful in loading and running hello.c via GDB network debugging
using a D-Link DFE-530TX Rev-A3-1 PCI card.

Please commit your changes to the ECOS tree at your earliest convenience.

Thanks,

Stephen

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

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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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

Bernard Fouché <bernard.fouche@kuantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1578|0                           |1
        is obsolete|                            |

--- Comment #10 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 10:10:10 GMT ---
Created an attachment (id=1579)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1579)
Hal patch

Patch for HAL related file. 43K patch, 99% is context info for diff.

-- 
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-8870-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 10:10:58 2012
Return-Path: <ecos-bugs-return-8870-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 20982 invoked by alias); 15 Feb 2012 10:10:56 -0000
Received: (qmail 20958 invoked by uid 22791); 15 Feb 2012 10:10:54 -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; Wed, 15 Feb 2012 10:10:32 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id B1B1D2F78003; Wed, 15 Feb 2012 10:10:31 +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: Attachment #1578 is obsolete
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: Wed, 15 Feb 2012 10:10:00 -0000
Message-Id: <20120215101025.9908E2F78003@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/msg00299.txt.bz2
Content-length: 871

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

Bernard Fouché <bernard.fouche@kuantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1578|0                           |1
        is obsolete|                            |

--- Comment #10 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 10:10:10 GMT ---
Created an attachment (id=1579)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1579)
Hal patch

Patch for HAL related file. 43K patch, 99% is context info for diff.

-- 
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-8872-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 10:11:48 2012
Return-Path: <ecos-bugs-return-8872-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 22183 invoked by alias); 15 Feb 2012 10:11:47 -0000
Received: (qmail 22176 invoked by uid 22791); 15 Feb 2012 10:11:47 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
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; Wed, 15 Feb 2012 10:11:06 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id C30992F78001
	for <ecos-bugs@ecos.sourceware.org>; Wed, 15 Feb 2012 10:11:05 +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 WnARFBSjyU1C; Wed, 15 Feb 2012 10:11:05 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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: Wed, 15 Feb 2012 10:11:00 -0000
Message-Id: <20120215101101.4737A2FB082B@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/msg00301.txt.bz2
Content-length: 513

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

--- Comment #11 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 10:10:57 GMT ---
Created an attachment (id=1580)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1580)
Kernel patch

-- 
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-8873-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 10:11:55 2012
Return-Path: <ecos-bugs-return-8873-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 22270 invoked by alias); 15 Feb 2012 10:11:54 -0000
Received: (qmail 22262 invoked by uid 22791); 15 Feb 2012 10:11:54 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,TW_BJ
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; Wed, 15 Feb 2012 10:11:42 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 50A1A2F78005
	for <ecos-bugs@ecos.sourceware.org>; Wed, 15 Feb 2012 10:11:41 +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 bc+aTRiWIQpH; Wed, 15 Feb 2012 10:11:41 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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: Wed, 15 Feb 2012 10:11:00 -0000
Message-Id: <20120215101135.DB83A2F78008@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/msg00302.txt.bz2
Content-length: 516

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

--- Comment #12 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 10:11:32 GMT ---
Created an attachment (id=1581)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1581)
objloader patch

-- 
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-8874-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 10:11:55 2012
Return-Path: <ecos-bugs-return-8874-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 22316 invoked by alias); 15 Feb 2012 10:11:55 -0000
Received: (qmail 22271 invoked by uid 22791); 15 Feb 2012 10:11:54 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,TW_BJ,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; Wed, 15 Feb 2012 10:11:42 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 405302F78003; Wed, 15 Feb 2012 10:11:41 +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: Wed, 15 Feb 2012 10:11:00 -0000
Message-Id: <20120215101135.BC8722F78005@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/msg00303.txt.bz2
Content-length: 514

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

--- Comment #12 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 10:11:32 GMT ---
Created an attachment (id=1581)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1581)
objloader patch

-- 
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-8871-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 10:11:33 2012
Return-Path: <ecos-bugs-return-8871-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 21761 invoked by alias); 15 Feb 2012 10:11:32 -0000
Received: (qmail 21753 invoked by uid 22791); 15 Feb 2012 10:11:31 -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; Wed, 15 Feb 2012 10:11:07 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id CE4292FB0827; Wed, 15 Feb 2012 10:11:06 +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: Wed, 15 Feb 2012 10:11:00 -0000
Message-Id: <20120215101101.16A192FB0827@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/msg00300.txt.bz2
Content-length: 511

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

--- Comment #11 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 10:10:57 GMT ---
Created an attachment (id=1580)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1580)
Kernel patch

-- 
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-8876-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 10:45:48 2012
Return-Path: <ecos-bugs-return-8876-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 28596 invoked by alias); 15 Feb 2012 10:45:47 -0000
Received: (qmail 28577 invoked by uid 22791); 15 Feb 2012 10:45:46 -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; Wed, 15 Feb 2012 10:45:14 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 4F60E2F78008; Wed, 15 Feb 2012 10:45:13 +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: Attachment #1579 mime type Attachment #1579 is
 patch
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: Wed, 15 Feb 2012 10:45:00 -0000
Message-Id: <20120215104507.AE4122F78003@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/msg00305.txt.bz2
Content-length: 702

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

Bernard Fouché <bernard.fouche@kuantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1579|application/octet-stream    |text/plain
          mime type|                            |
   Attachment #1579|0                           |1
           is patch|                            |

-- 
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-8875-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 10:45:48 2012
Return-Path: <ecos-bugs-return-8875-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 28584 invoked by alias); 15 Feb 2012 10:45:47 -0000
Received: (qmail 28576 invoked by uid 22791); 15 Feb 2012 10:45:46 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
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; Wed, 15 Feb 2012 10:45:14 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 425BF2F78003
	for <ecos-bugs@ecos.sourceware.org>; Wed, 15 Feb 2012 10:45:13 +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 0YZyVw-5oHLo; Wed, 15 Feb 2012 10:45:13 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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: Attachment #1579 mime type Attachment #1579 is
 patch
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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: Wed, 15 Feb 2012 10:45:00 -0000
Message-Id: <20120215104507.C144F2F78005@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/msg00304.txt.bz2
Content-length: 704

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

Bernard Fouché <bernard.fouche@kuantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1579|application/octet-stream    |text/plain
          mime type|                            |
   Attachment #1579|0                           |1
           is patch|                            |

-- 
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-8878-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 10:48:46 2012
Return-Path: <ecos-bugs-return-8878-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 29294 invoked by alias); 15 Feb 2012 10:48:46 -0000
Received: (qmail 29277 invoked by uid 22791); 15 Feb 2012 10:48:45 -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; Wed, 15 Feb 2012 10:48:21 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 02F102F78001; Wed, 15 Feb 2012 10:48:19 +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: ilijak@siva.com.mk
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"
MIME-Version: 1.0
Date: Wed, 15 Feb 2012 10:48:00 -0000
Message-Id: <20120215104814.278ED2F78003@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/msg00307.txt.bz2
Content-length: 753

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

--- Comment #13 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-15 10:48:11 GMT ---
(In reply to comment #11)
> Created an attachment (id\x1580)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id\x1580) [details]
> Kernel patch

Changes to the Kernel should be done with caution. I think that this addition
is not necessary. The desired functionality, for a given platform, can be
introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).

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

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

[bugzilla-daemon]

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

--- Comment #13 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-15 10:48:11 GMT ---
(In reply to comment #11)
> Created an attachment (id=1580)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1580) [details]
> Kernel patch

Changes to the Kernel should be done with caution. I think that this addition
is not necessary. The desired functionality, for a given platform, can be
introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).

-- 
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.

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

[bugzilla-daemon]

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

--- Comment #14 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 11:28:54 GMT ---
(In reply to comment #13)
> Changes to the Kernel should be done with caution. I think that this addition
> is not necessary. The desired functionality, for a given platform, can be
> introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).

There are two problems:

- clearing the pending interrupt bit is completely different from acknowledging
an interrupt. Acknowledgment is usually done at the end of DSR/ISR while
clearing the pending interrupt bit must be done *before* reading the peripheral
registers describing interrupt source(s): HAL_VAR_INTERRUPT_ACKNOWLEDGE is not
a solution.

- if HAL_VAR_INTERRUPT_CLEAR_PENDING is added only to Cortex-M targets, then
how can one share a driver between an arch not requiring clearing pending
interrupt and Cortex-M cores? For instance the generic serial 16x5x driver?
Today cyg_drv_interrupt_acknowledge() resolves to CYG_EMPTY_STATEMENT for
Cortex-M, IMHO we need cyg_drv_interrupt_clear_pending() to resolve to
CYG_EMPTY_STATEMENT for non-Cortex-M, hence one can write a driver using both
cyg_drv_interrupt_acknowledge() and cyg_drv_interrupt_clear_pending() at the
correct place so the driver can work in different arch.

-- 
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-8879-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 11:29:28 2012
Return-Path: <ecos-bugs-return-8879-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 11566 invoked by alias); 15 Feb 2012 11:29:27 -0000
Received: (qmail 11552 invoked by uid 22791); 15 Feb 2012 11:29:27 -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; Wed, 15 Feb 2012 11:29:03 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 61B582F78009; Wed, 15 Feb 2012 11:29:02 +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: Wed, 15 Feb 2012 11:29:00 -0000
Message-Id: <20120215112857.7AE192F78003@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/msg00308.txt.bz2
Content-length: 1606

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

--- Comment #14 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 11:28:54 GMT ---
(In reply to comment #13)
> Changes to the Kernel should be done with caution. I think that this addition
> is not necessary. The desired functionality, for a given platform, can be
> introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).

There are two problems:

- clearing the pending interrupt bit is completely different from acknowledging
an interrupt. Acknowledgment is usually done at the end of DSR/ISR while
clearing the pending interrupt bit must be done *before* reading the peripheral
registers describing interrupt source(s): HAL_VAR_INTERRUPT_ACKNOWLEDGE is not
a solution.

- if HAL_VAR_INTERRUPT_CLEAR_PENDING is added only to Cortex-M targets, then
how can one share a driver between an arch not requiring clearing pending
interrupt and Cortex-M cores? For instance the generic serial 16x5x driver?
Today cyg_drv_interrupt_acknowledge() resolves to CYG_EMPTY_STATEMENT for
Cortex-M, IMHO we need cyg_drv_interrupt_clear_pending() to resolve to
CYG_EMPTY_STATEMENT for non-Cortex-M, hence one can write a driver using both
cyg_drv_interrupt_acknowledge() and cyg_drv_interrupt_clear_pending() at the
correct place so the driver can work in different arch.

-- 
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-8881-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 13:35:41 2012
Return-Path: <ecos-bugs-return-8881-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 8130 invoked by alias); 15 Feb 2012 13:35:39 -0000
Received: (qmail 8057 invoked by uid 22791); 15 Feb 2012 13:35:39 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,SARE_SUB_OBFU_OTHER,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; Wed, 15 Feb 2012 13:34:58 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id D49832F78003; Wed, 15 Feb 2012 13:34:55 +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 1001461] Spansion S25FLxxxK (SPI NOR FLASH) driver
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: 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: Attachment #1532 mime type Attachment #1532 is
 patch
In-Reply-To: <bug-1001461-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001461-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: Wed, 15 Feb 2012 13:35:00 -0000
Message-Id: <20120215133449.E93C82F78003@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/msg00310.txt.bz2
Content-length: 702

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

Bernard Fouché <bernard.fouche@kuantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1532|application/octet-stream    |text/plain
          mime type|                            |
   Attachment #1532|0                           |1
           is patch|                            |

-- 
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-8882-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 13:46:30 2012
Return-Path: <ecos-bugs-return-8882-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 10799 invoked by alias); 15 Feb 2012 13:46:27 -0000
Received: (qmail 10791 invoked by uid 22791); 15 Feb 2012 13:46:26 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,SARE_SUB_OBFU_OTHER,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; Wed, 15 Feb 2012 13:46:14 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 3E9762F78003; Wed, 15 Feb 2012 13:46:13 +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 1001461] Spansion S25FLxxxK (SPI NOR FLASH) driver
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: 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-1001461-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001461-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: Wed, 15 Feb 2012 13:46:00 -0000
Message-Id: <20120215134606.C57772F78003@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/msg00311.txt.bz2
Content-length: 511

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

--- Comment #1 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 13:46:05 GMT ---
Created an attachment (id=1582)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1582)
ecos.db entry

-- 
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-8883-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 13:47:52 2012
Return-Path: <ecos-bugs-return-8883-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 11734 invoked by alias); 15 Feb 2012 13:47:51 -0000
Received: (qmail 11723 invoked by uid 22791); 15 Feb 2012 13:47:50 -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; Wed, 15 Feb 2012 13:47:02 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 100C92F78003; Wed, 15 Feb 2012 13:47:01 +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 1001466] /dev/null serial driver
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: 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-1001466-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001466-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: Wed, 15 Feb 2012 13:47:00 -0000
Message-Id: <20120215134656.721E12F78003@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/msg00312.txt.bz2
Content-length: 511

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

--- Comment #2 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 13:46:54 GMT ---
Created an attachment (id=1583)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1583)
ecos.db entry

-- 
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-8884-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 13:48:37 2012
Return-Path: <ecos-bugs-return-8884-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 12322 invoked by alias); 15 Feb 2012 13:48:36 -0000
Received: (qmail 12309 invoked by uid 22791); 15 Feb 2012 13:48:35 -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; Wed, 15 Feb 2012 13:47:53 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 3942B2F78005; Wed, 15 Feb 2012 13:47:52 +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 1001466] /dev/null serial driver
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: 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: Attachment #1534 description Attachment #1534 is
 patch
In-Reply-To: <bug-1001466-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001466-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: Wed, 15 Feb 2012 13:48:00 -0000
Message-Id: <20120215134746.E25972F78005@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/msg00313.txt.bz2
Content-length: 715

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

Bernard Fouché <bernard.fouche@kuantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1534|/dev/null                   |/dev/null as a tar file
        description|                            |
   Attachment #1534|1                           |0
           is patch|                            |

-- 
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-8885-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Feb 15 20:46:17 2012
Return-Path: <ecos-bugs-return-8885-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 9699 invoked by alias); 15 Feb 2012 20:46:15 -0000
Received: (qmail 9599 invoked by uid 22791); 15 Feb 2012 20:46:15 -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; Wed, 15 Feb 2012 20:45:40 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 93FEE2F78005; Wed, 15 Feb 2012 20:45:39 +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 1001466] /dev/null serial driver
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: 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-1001466-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001466-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: Wed, 15 Feb 2012 20:46:00 -0000
Message-Id: <20120215204522.066212F78008@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/msg00314.txt.bz2
Content-length: 2030

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

--- Comment #3 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-15 20:45:18 GMT ---
On Comment #0
> Try to mimick /dev/null. (inspired by loop serial driver.) Comments
> welcome, maybe the semantics aren't close enough to Un*x but it should
> do the job for most cases. The doc may need to be rewritten?

It seemed to me your interpretation of /dev/null will arise some
confusions for some users. Below are mine.

Mess #1

  I would avoid the same mimic (and naming). In UNIX-like operating
  systems, /dev/null is a special *file* and not a serial device.

  % stty -aF /dev/null
  stty: /dev/null: Inappropriate ioctl for device

As you can see /dev/null is not some terminal line (serial device).
Well, eCos != *nix, but, I would avoid the ability to configure the
/dev/null as a serial device under eCos.

Mess #2

  A read on /dev/null would not block process (thread), it does return
  EOF, and you offer in your documentation to enter an ability of the
  blocking read on /dev/null as an option.

Mess #3

  IMO, if anyone will see those words together in CDL (I mean 'serial'
  and 'null'), under eCos dev/serial/null, then he would think, Great!
  There is 'nullmodem' device in eCos! Come check my guess

    http://www.google.com/search?q=%2Bserial+%2Bnull

  And after reading your documentation, they will think, Nope! They
  provide something very special (special null device :-)

BUT

I do not want to break your idea. IMHO, the main mess here is naming and
your free interpretation of /dev/null. You try to implement some serial
device like a "tear off" nullmodem, but what is bad with a "nullmodem"
abstraction for your purposes? And eCos serial loop driver (as you could
see) is a half of nullmodem itself.

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

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

[bugzilla-daemon]

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

--- Comment #15 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-16 15:29:18 GMT ---
(In reply to comment #14)
> (In reply to comment #13)
> > Changes to the Kernel should be done with caution. I think that this addition
> > is not necessary. The desired functionality, for a given platform, can be
> > introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).
> 
> There are two problems:
> 
> - clearing the pending interrupt bit is completely different from acknowledging
> an interrupt. Acknowledgment is usually done at the end of DSR/ISR while
> clearing the pending interrupt bit must be done *before* reading the peripheral
> registers describing interrupt source(s): HAL_VAR_INTERRUPT_ACKNOWLEDGE is not
> a solution.
> 
> - if HAL_VAR_INTERRUPT_CLEAR_PENDING is added only to Cortex-M targets, then
> how can one share a driver between an arch not requiring clearing pending
> interrupt and Cortex-M cores? For instance the generic serial 16x5x driver?
> Today cyg_drv_interrupt_acknowledge() resolves to CYG_EMPTY_STATEMENT for
> Cortex-M, IMHO we need cyg_drv_interrupt_clear_pending() to resolve to
> CYG_EMPTY_STATEMENT for non-Cortex-M, hence one can write a driver using both
> cyg_drv_interrupt_acknowledge() and cyg_drv_interrupt_clear_pending() at the
> correct place so the driver can work in different arch.

Normally acknowledge should be enough. Regarding the IRQ re-triggering you have
found out, maybe (some of) LPC17xx peripherals employ pulsed rather than level
interrupts. Here is what's Cortex-M NVIC doc saying about it.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Bhchgeei.html

Then, if we must implement HAL_VAR_INTERRUPT_CLEAR_PENDING I would suggest to
do it on LPC17xx variant or, if the problem appears on other variants consider
Cortex-M architecture level, and avoid patching kernel files. FYI as i
mentioned earlier I'll do some tests on Kinetis during next week.

-- 
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.

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

[bugzilla-daemon]

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

--- Comment #16 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-16 16:45:35 GMT ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > Changes to the Kernel should be done with caution. I think that this addition
> > > is not necessary. The desired functionality, for a given platform, can be
> > > introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).
> > 
> > There are two problems:
> > 
> > - clearing the pending interrupt bit is completely different from acknowledging
> > an interrupt. Acknowledgment is usually done at the end of DSR/ISR while
> > clearing the pending interrupt bit must be done *before* reading the peripheral
> > registers describing interrupt source(s): HAL_VAR_INTERRUPT_ACKNOWLEDGE is not
> > a solution.
> > 
> > - if HAL_VAR_INTERRUPT_CLEAR_PENDING is added only to Cortex-M targets, then
> > how can one share a driver between an arch not requiring clearing pending
> > interrupt and Cortex-M cores? For instance the generic serial 16x5x driver?
> > Today cyg_drv_interrupt_acknowledge() resolves to CYG_EMPTY_STATEMENT for
> > Cortex-M, IMHO we need cyg_drv_interrupt_clear_pending() to resolve to
> > CYG_EMPTY_STATEMENT for non-Cortex-M, hence one can write a driver using both
> > cyg_drv_interrupt_acknowledge() and cyg_drv_interrupt_clear_pending() at the
> > correct place so the driver can work in different arch.
> 
> Normally acknowledge should be enough. Regarding the IRQ re-triggering you have
> found out, maybe (some of) LPC17xx peripherals employ pulsed rather than level
> interrupts. Here is what's Cortex-M NVIC doc saying about it.
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Bhchgeei.html

I've read this, did you look at the section just afterwards ('NVIC usage hints
and tips') that states: "A interrupt can enter pending state even if it is
disabled. Disabling an interrupt only prevents the processor from taking that
interrupt.": there is no difference between pulse and level interrupts for
pending interrupt management.

Since eCos disable interrupts when using cyg_interrupt_mask() my guess is the
issue should show up on all Cortex-M cores having the ICPR0/1 registers (all?).

Most if not all drivers I've seen do:

1) read interrupt source(s)
2) work
3) acknowledge and unmask interrupt, exit

If there are multiple memory buffers (CAN), many interrupt conditions described
in a single register (ser16x5x,CAN,SPI), and/or a FIFO (ser16x5x,SPI) to
process then it's:

1) read interrupt source(s)
2) work
3) goto step 1 if there is still at least an interrupt condition
4) acknowledge and unmask interrupt, exit

The issue appears more clearly with this second type of drivers, they must be
changed to:

0) clear pending interrupts
1) read interrupt source(s)
2) work
3) goto step *0* if there is still at least an interrupt condition
4) acknowledge and unmask interrupt

You see that it's not possible to rewrite cyg_drv_interrupt_acknowledge() to
solve the problem: the need is different because it occurs at a different time.
Or you change the semantics of cyg_drv_interrupt_acknowledge() and then you
break driver re-use.

Doing:

1) read interrupt source(s)
2) work
3) goto step 1 if there is still at least an interrupt condition
4) clear pending interrupt, acknowledge and unmask interrupt

won't work: an interrupt could occur between steps 3 and 4 and you would lose
it, that's why clearing pending ints must be done at the beginning of the
processing.

> 
> Then, if we must implement HAL_VAR_INTERRUPT_CLEAR_PENDING I would suggest to
> do it on LPC17xx variant or, if the problem appears on other variants consider
> Cortex-M architecture level, and avoid patching kernel files. FYI as i
> mentioned earlier I'll do some tests on Kinetis during next week.

If there is a way to do that and keep driver code re-use between arch that's
would be fine!

When you perform your tests, please try clocking SLOWLY (no PLL for instance):
if the ISR/DSR sequence is faster than the time it takes to the MCU to generate
a new interrupt, then there won't be any pending interrupt and the dust will
stay hidden under the carpet and re-appear only when many different drivers
trigger more important amounts of interrupts. (my guess is this is what
happened to have this matter appearing only now, or if nobody counts the
numbers of ISR/DSR/DSR-that does-nothing/volume-of-data-handled-per-DSR-run
when testing drivers)

-- 
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-8896-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 16 16:46:42 2012
Return-Path: <ecos-bugs-return-8896-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 10122 invoked by alias); 16 Feb 2012 16:46:35 -0000
Received: (qmail 10100 invoked by uid 22791); 16 Feb 2012 16:46:32 -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, 16 Feb 2012 16:45:48 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id B92172F78009; Thu, 16 Feb 2012 16:45:46 +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, 16 Feb 2012 16:46:00 -0000
Message-Id: <20120216164539.0692C2F78005@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/msg00325.txt.bz2
Content-length: 4850

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

--- Comment #16 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-16 16:45:35 GMT ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > Changes to the Kernel should be done with caution. I think that this addition
> > > is not necessary. The desired functionality, for a given platform, can be
> > > introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).
> > 
> > There are two problems:
> > 
> > - clearing the pending interrupt bit is completely different from acknowledging
> > an interrupt. Acknowledgment is usually done at the end of DSR/ISR while
> > clearing the pending interrupt bit must be done *before* reading the peripheral
> > registers describing interrupt source(s): HAL_VAR_INTERRUPT_ACKNOWLEDGE is not
> > a solution.
> > 
> > - if HAL_VAR_INTERRUPT_CLEAR_PENDING is added only to Cortex-M targets, then
> > how can one share a driver between an arch not requiring clearing pending
> > interrupt and Cortex-M cores? For instance the generic serial 16x5x driver?
> > Today cyg_drv_interrupt_acknowledge() resolves to CYG_EMPTY_STATEMENT for
> > Cortex-M, IMHO we need cyg_drv_interrupt_clear_pending() to resolve to
> > CYG_EMPTY_STATEMENT for non-Cortex-M, hence one can write a driver using both
> > cyg_drv_interrupt_acknowledge() and cyg_drv_interrupt_clear_pending() at the
> > correct place so the driver can work in different arch.
> 
> Normally acknowledge should be enough. Regarding the IRQ re-triggering you have
> found out, maybe (some of) LPC17xx peripherals employ pulsed rather than level
> interrupts. Here is what's Cortex-M NVIC doc saying about it.
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Bhchgeei.html

I've read this, did you look at the section just afterwards ('NVIC usage hints
and tips') that states: "A interrupt can enter pending state even if it is
disabled. Disabling an interrupt only prevents the processor from taking that
interrupt.": there is no difference between pulse and level interrupts for
pending interrupt management.

Since eCos disable interrupts when using cyg_interrupt_mask() my guess is the
issue should show up on all Cortex-M cores having the ICPR0/1 registers (all?).

Most if not all drivers I've seen do:

1) read interrupt source(s)
2) work
3) acknowledge and unmask interrupt, exit

If there are multiple memory buffers (CAN), many interrupt conditions described
in a single register (ser16x5x,CAN,SPI), and/or a FIFO (ser16x5x,SPI) to
process then it's:

1) read interrupt source(s)
2) work
3) goto step 1 if there is still at least an interrupt condition
4) acknowledge and unmask interrupt, exit

The issue appears more clearly with this second type of drivers, they must be
changed to:

0) clear pending interrupts
1) read interrupt source(s)
2) work
3) goto step *0* if there is still at least an interrupt condition
4) acknowledge and unmask interrupt

You see that it's not possible to rewrite cyg_drv_interrupt_acknowledge() to
solve the problem: the need is different because it occurs at a different time.
Or you change the semantics of cyg_drv_interrupt_acknowledge() and then you
break driver re-use.

Doing:

1) read interrupt source(s)
2) work
3) goto step 1 if there is still at least an interrupt condition
4) clear pending interrupt, acknowledge and unmask interrupt

won't work: an interrupt could occur between steps 3 and 4 and you would lose
it, that's why clearing pending ints must be done at the beginning of the
processing.

> 
> Then, if we must implement HAL_VAR_INTERRUPT_CLEAR_PENDING I would suggest to
> do it on LPC17xx variant or, if the problem appears on other variants consider
> Cortex-M architecture level, and avoid patching kernel files. FYI as i
> mentioned earlier I'll do some tests on Kinetis during next week.

If there is a way to do that and keep driver code re-use between arch that's
would be fine!

When you perform your tests, please try clocking SLOWLY (no PLL for instance):
if the ISR/DSR sequence is faster than the time it takes to the MCU to generate
a new interrupt, then there won't be any pending interrupt and the dust will
stay hidden under the carpet and re-appear only when many different drivers
trigger more important amounts of interrupts. (my guess is this is what
happened to have this matter appearing only now, or if nobody counts the
numbers of ISR/DSR/DSR-that does-nothing/volume-of-data-handled-per-DSR-run
when testing drivers)

-- 
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-8898-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 16 16:49:39 2012
Return-Path: <ecos-bugs-return-8898-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 12888 invoked by alias); 16 Feb 2012 16:49:37 -0000
Received: (qmail 12786 invoked by uid 22791); 16 Feb 2012 16:49:35 -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, 16 Feb 2012 16:48:55 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id F23BC2F78005; Thu, 16 Feb 2012 16:48:53 +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 1001466] /dev/null serial driver
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: 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-1001466-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001466-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, 16 Feb 2012 16:49:00 -0000
Message-Id: <20120216164842.E17952F78008@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/msg00327.txt.bz2
Content-length: 901

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

--- Comment #12 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-16 16:48:39 GMT ---
(In reply to comment #11)
> (In reply to comment #10)
> 
> [snip]
> 
> > > And what you get?
> > 
> > Excellent! Just need some documentation and then /dev/null can go to
> > itself ;-)
> 
> So, let's 
> 
>   Bug 1001466 > /dev/null
> 
> :-)

Please change bug's state only when there is some doc about the trick you used,
and that doc uses the term '/dev/null': this will avoid losing time to some
other users if they are looking for a solution to the absence of /dev/null in
eCos.

-- 
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-8899-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 16 17:22:36 2012
Return-Path: <ecos-bugs-return-8899-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 27000 invoked by alias); 16 Feb 2012 17:22:33 -0000
Received: (qmail 26990 invoked by uid 22791); 16 Feb 2012 17:22:31 -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, 16 Feb 2012 17:21:15 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id C06E42F78008; Thu, 16 Feb 2012 17:21:14 +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 1001466] /dev/null serial driver
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: 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-1001466-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001466-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, 16 Feb 2012 17:22:00 -0000
Message-Id: <20120216172103.CE00F2F78009@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/msg00328.txt.bz2
Content-length: 1390

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

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-16 17:21:00 GMT ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> >
> > [snip]
> >
> > > > And what you get?
> > >
> > > Excellent! Just need some documentation and then /dev/null can go
> > > to itself ;-)
> >
> > So, let's
> >
> >   Bug 1001466 > /dev/null
      ^^^^^^^^^^^^^^^^^^^^^^^

Excuse my '... > /dev/null' jargon:
http://en.wikipedia.org/wiki//dev/null

> Please change bug's state only when there is some doc about the trick
> you used, and that doc uses the term '/dev/null': this will avoid
> losing time to some other users if they are looking for a solution to
> the absence of /dev/null in eCos.

Good approach. I'll change the state to 'NEED INFO'.

As for my guess and test in GDB. I decided to check that example when I
saw in ecos.ecc:

  cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
      # Default value:  CYGDAT_IO_SERIAL_TTY_CONSOLE ?
CYGDAT_IO_SERIAL_TTY_CONSOLE : "\"/dev/null\""
  }

Hm, /dev/null? And I was looking for what will happen then.

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

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

[bugzilla-daemon]

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

--- Comment #17 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-23 09:05:21 GMT ---
If you have at hand "The definitive guide to the ARM Cortex-M3" by Joseph Yiu:
see chapter 7, "Interrupt Inputs and Pending Behavior" section,  especially
figure 7.13, this is exactly what I observed.

-- 
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-8912-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 23 09:05:48 2012
Return-Path: <ecos-bugs-return-8912-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 8817 invoked by alias); 23 Feb 2012 09:05:47 -0000
Received: (qmail 8792 invoked by uid 22791); 23 Feb 2012 09:05:46 -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, 23 Feb 2012 09:05:33 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id A8AE42F78008; Thu, 23 Feb 2012 09:05:32 +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, 23 Feb 2012 09:05:00 -0000
Message-Id: <20120223090531.0E4272F78008@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/msg00341.txt.bz2
Content-length: 603

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

--- Comment #17 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-23 09:05:21 GMT ---
If you have at hand "The definitive guide to the ARM Cortex-M3" by Joseph Yiu:
see chapter 7, "Interrupt Inputs and Pending Behavior" section,  especially
figure 7.13, this is exactly what I observed.

-- 
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-8914-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 23 09:58:56 2012
Return-Path: <ecos-bugs-return-8914-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 14503 invoked by alias); 23 Feb 2012 09:58:56 -0000
Received: (qmail 14489 invoked by uid 22791); 23 Feb 2012 09:58:55 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
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, 23 Feb 2012 09:58:38 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id C21672F78003
	for <ecos-bugs@ecos.sourceware.org>; Thu, 23 Feb 2012 09:58:37 +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 XfJXJ7KYYCUX; Thu, 23 Feb 2012 09:58:37 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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: ilijak@siva.com.mk
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-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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, 23 Feb 2012 09:58:00 -0000
Message-Id: <20120223095835.8464D2F7800A@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/msg00343.txt.bz2
Content-length: 1335

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

--- Comment #18 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-23 09:58:31 GMT ---
(In reply to comment #17)
> If you have at hand "The definitive guide to the ARM Cortex-M3" by Joseph Yiu:
> see chapter 7, "Interrupt Inputs and Pending Behavior" section,  especially
> figure 7.13, this is exactly what I observed.

I guess that in context of this bug you probably mean fig 7.14. (i guess the
number at the bottom of fig.).

For solution I would return to cyg_drv_interrupt_acknowledge() since that's
what it's supposed to do: "Perform any processing required at the interrupt
controller and in the CPU to cancel the current interrupt request on the
vector. An ISR may also need to program the hardware of the device to prevent
an immediate re-triggering of the interrupt."
Only, it should be called later than it is called now. I acknowledge your
concern about generic serial driver but it has some conditional code already so
adding little-bit more wouldn't harm (or IMO the impact will be lower than
adding functions on Kernel level).

--
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.

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

[bugzilla-daemon]

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

--- Comment #19 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-23 10:29:10 GMT ---
(In reply to comment #18)
> (In reply to comment #17)
> > If you have at hand "The definitive guide to the ARM Cortex-M3" by Joseph Yiu:
> > see chapter 7, "Interrupt Inputs and Pending Behavior" section,  especially
> > figure 7.13, this is exactly what I observed.
> 
> I guess that in context of this bug you probably mean fig 7.14. (i guess the
> number at the bottom of fig.).

Well on my edition there isn't any figure 7.14 ;-) (I think I have the first
edition)

> 
> For solution I would return to cyg_drv_interrupt_acknowledge() since that's
> what it's supposed to do: "Perform any processing required at the interrupt
> controller and in the CPU to cancel the current interrupt request on the
> vector. An ISR may also need to program the hardware of the device to prevent
> an immediate re-triggering of the interrupt."

Our problem isn't usually in the ISR (unless it does all interrupt handling)
and the feature concerned is different: we don't need to cancel "the current
interrupt request" but to manage possible pending requests: we have to manage
interrupt requests THAT ARE NOT THE CURRENT INTERRUPT REQUEST, exactly what
cyg_drv_interrupt_acknowledge() does not!

> Only, it should be called later than it is called now. I acknowledge your
> concern about generic serial driver but it has some conditional code already so
> adding little-bit more wouldn't harm (or IMO the impact will be lower than
> adding functions on Kernel level).

If we take the serial driver as an example, cyg_drv_interrupt_acknowledge() is
called at the end of the ISR while interrupt pending conditions should be
processed at the beginning or in the middle of the DSR (a strange place to
acknowledge an interrupt , if we consider the driver code being read by someone
unaware of the Cortex-M NVIC).

You'll end up with multiple calls to cyg_drv_interrupt_acknowledge() in the
code, bordered by conditional compilation specific to Cortex-M cores.

And then you have all other 'Prime-cell' related drivers, shared between arch
(CAN, ADC, SPI for the driver I ported/checked) so the mysterious calls to
cyg_drv_interrupt_acknowledge() in the middle or at the beginning of DSR will
start to sprout in different places and if one looks at the original definition
of cyg_drv_interrupt_acknowledge() you shown then it's really impossible to
grab the reason why such calls have to be inserted here and there.

Or you change the definition of cyg_drv_interrupt_acknowledge(), describing it
as something that has a different meaning according to the type of arch
involved while at the same time all cyg_drv_*() functions are arch independent.

I understand that changing a decade old API isn't a good news but I'm not sure
that making the API difficult to understand because of a change of meaning of a
well known function is a better solution. Cortex-M brings a new interrupt
handling model, maybe it's time to update the API spec also, instead of keeping
it at any cost.

-- 
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-8915-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 23 10:29:35 2012
Return-Path: <ecos-bugs-return-8915-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 25655 invoked by alias); 23 Feb 2012 10:29:35 -0000
Received: (qmail 25641 invoked by uid 22791); 23 Feb 2012 10:29:34 -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, 23 Feb 2012 10:29:17 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id CD7BC2F78006; Thu, 23 Feb 2012 10:29:15 +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, 23 Feb 2012 10:29:00 -0000
Message-Id: <20120223102914.1554C2F78006@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/msg00344.txt.bz2
Content-length: 3400

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

--- Comment #19 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-23 10:29:10 GMT ---
(In reply to comment #18)
> (In reply to comment #17)
> > If you have at hand "The definitive guide to the ARM Cortex-M3" by Joseph Yiu:
> > see chapter 7, "Interrupt Inputs and Pending Behavior" section,  especially
> > figure 7.13, this is exactly what I observed.
> 
> I guess that in context of this bug you probably mean fig 7.14. (i guess the
> number at the bottom of fig.).

Well on my edition there isn't any figure 7.14 ;-) (I think I have the first
edition)

> 
> For solution I would return to cyg_drv_interrupt_acknowledge() since that's
> what it's supposed to do: "Perform any processing required at the interrupt
> controller and in the CPU to cancel the current interrupt request on the
> vector. An ISR may also need to program the hardware of the device to prevent
> an immediate re-triggering of the interrupt."

Our problem isn't usually in the ISR (unless it does all interrupt handling)
and the feature concerned is different: we don't need to cancel "the current
interrupt request" but to manage possible pending requests: we have to manage
interrupt requests THAT ARE NOT THE CURRENT INTERRUPT REQUEST, exactly what
cyg_drv_interrupt_acknowledge() does not!

> Only, it should be called later than it is called now. I acknowledge your
> concern about generic serial driver but it has some conditional code already so
> adding little-bit more wouldn't harm (or IMO the impact will be lower than
> adding functions on Kernel level).

If we take the serial driver as an example, cyg_drv_interrupt_acknowledge() is
called at the end of the ISR while interrupt pending conditions should be
processed at the beginning or in the middle of the DSR (a strange place to
acknowledge an interrupt , if we consider the driver code being read by someone
unaware of the Cortex-M NVIC).

You'll end up with multiple calls to cyg_drv_interrupt_acknowledge() in the
code, bordered by conditional compilation specific to Cortex-M cores.

And then you have all other 'Prime-cell' related drivers, shared between arch
(CAN, ADC, SPI for the driver I ported/checked) so the mysterious calls to
cyg_drv_interrupt_acknowledge() in the middle or at the beginning of DSR will
start to sprout in different places and if one looks at the original definition
of cyg_drv_interrupt_acknowledge() you shown then it's really impossible to
grab the reason why such calls have to be inserted here and there.

Or you change the definition of cyg_drv_interrupt_acknowledge(), describing it
as something that has a different meaning according to the type of arch
involved while at the same time all cyg_drv_*() functions are arch independent.

I understand that changing a decade old API isn't a good news but I'm not sure
that making the API difficult to understand because of a change of meaning of a
well known function is a better solution. Cortex-M brings a new interrupt
handling model, maybe it's time to update the API spec also, instead of keeping
it at any cost.

-- 
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-8917-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 23 16:06:25 2012
Return-Path: <ecos-bugs-return-8917-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 13298 invoked by alias); 23 Feb 2012 16:06:24 -0000
Received: (qmail 13287 invoked by uid 22791); 23 Feb 2012 16:06:23 -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, 23 Feb 2012 16:05:57 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id E56532F78006; Thu, 23 Feb 2012 16:05:55 +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 1001426] HAL for Kinetis Kwikstik
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: ilijak@siva.com.mk
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-1001426-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001426-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, 23 Feb 2012 16:06:00 -0000
Message-Id: <20120223160550.B59362F78006@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/msg00346.txt.bz2
Content-length: 621

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

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-23 16:05:48 GMT ---
Tomas

I have checked the bug #1001450 patches in. Can you synchronize this port with
CVS?
Hint: Since this port is based on TWR-K40X256, IMO the easy way is to look at
Attachment 1561 for diffs (with respect to original Kwikstik patch).

Ilija

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

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

[bugzilla-daemon]

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

--- Comment #20 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-04-02 09:10:15 BST ---
(In reply to comment #15)
>ariants consider
> FYI as i
> mentioned earlier I'll do some tests on Kinetis during next week.

Hello Ilija,

did you find some time to make these tests?

Thanks!

  Bernard

-- 
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-9290-listarch-ecos-bugs=sources.redhat.com@sourceware.org Mon Apr 02 08:10:56 2012
Return-Path: <ecos-bugs-return-9290-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 14425 invoked by alias); 2 Apr 2012 08:10:54 -0000
Received: (qmail 14398 invoked by uid 22791); 2 Apr 2012 08:10:49 -0000
X-SWARE-Spam-Status: No, hits=-2.7 required=5.0
	tests=AWL,BAYES_00,KHOP_THREADED,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; Mon, 02 Apr 2012 08:10:34 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 338992F78003; Mon,  2 Apr 2012 09:10:33 +0100 (BST)
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: Mon, 02 Apr 2012 08:10:00 -0000
Message-Id: <20120402081025.4ABAD2F78005@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/msg00719.txt.bz2
Content-length: 602

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

--- Comment #20 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-04-02 09:10:15 BST ---
(In reply to comment #15)
>ariants consider
> FYI as i
> mentioned earlier I'll do some tests on Kinetis during next week.

Hello Ilija,

did you find some time to make these tests?

Thanks!

  Bernard

-- 
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-9291-listarch-ecos-bugs=sources.redhat.com@sourceware.org Mon Apr 02 17:48:24 2012
Return-Path: <ecos-bugs-return-9291-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 14680 invoked by alias); 2 Apr 2012 17:48:22 -0000
Received: (qmail 14670 invoked by uid 22791); 2 Apr 2012 17:48:20 -0000
X-SWARE-Spam-Status: No, hits=-2.7 required=5.0
	tests=AWL,BAYES_00,KHOP_THREADED,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; Mon, 02 Apr 2012 17:48:07 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 9B9C82F7800F; Mon,  2 Apr 2012 18:48:06 +0100 (BST)
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: ilijak@siva.com.mk
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"
MIME-Version: 1.0
Date: Mon, 02 Apr 2012 17:48:00 -0000
Message-Id: <20120402174802.A95DA2F7800F@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/msg00720.txt.bz2
Content-length: 1172

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

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-02 18:47:55 BST ---
(In reply to comment #20)
> (In reply to comment #15)
> >ariants consider
> > FYI as i
> > mentioned earlier I'll do some tests on Kinetis during next week.
>
> Hello Ilija,
>
> did you find some time to make these tests?
>
> Thanks!
>
>   Bernard

Hi Bernard. I apologize, but I haven't tested although I would like to see how
Kinetis drivers beehive with respect to this issue.

Nevertheless, as stated earlier I acknowledge your findings as well as efforts
to fix the problem. My only concern is: do we have to extend the kernel API or
can we implement the solution on architecture level.
Your patch proposal doesn't seem to affect/harm other architectures and you
have provided some arguments. It would be good if we have comments from other
colleagues, possibly eCos architects.

Ilija

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

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

[bugzilla-daemon]

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

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-02 18:47:55 BST ---
(In reply to comment #20)
> (In reply to comment #15)
> >ariants consider
> > FYI as i
> > mentioned earlier I'll do some tests on Kinetis during next week.
> 
> Hello Ilija,
> 
> did you find some time to make these tests?
> 
> Thanks!
> 
>   Bernard

Hi Bernard. I apologize, but I haven't tested although I would like to see how
Kinetis drivers beehive with respect to this issue.

Nevertheless, as stated earlier I acknowledge your findings as well as efforts
to fix the problem. My only concern is: do we have to extend the kernel API or
can we implement the solution on architecture level.
Your patch proposal doesn't seem to affect/harm other architectures and you
have provided some arguments. It would be good if we have comments from other
colleagues, possibly eCos architects.

Ilija

-- 
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.

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

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickg@ecoscentric.com

--- Comment #22 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-02 22:22:16 BST ---
Any changes in this area to either Cortex-M arch HAL or the kernel, especially
the API, would definitely need to be approved by Nick. I'm adding him to CC.

-- 
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.

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

[bugzilla-daemon]

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

--- Comment #26 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-09-27 09:52:36 BST ---
(In reply to comment #25)
> But I wouldn't overstate the problem, as far I can tell this will only happen
> with certain designs of devices, and only then if certain situations combine,
> which therefore makes it uncommon. That's not to say it's irrelevant, but it's
> not like it happens every interrupt or anything like that.

If you're not looking for this problem, you won't see it :-).

For instance you send X KB of data in a FIFO based driver (say the UART) and
you don't count the number of times the ISR/DSR sequence is triggered but just
check that the UART traffic is correctly sent: everything seems fine since the
job is done.

But if you start counting ISR/DSR then you wonder why you have a number of
ISR/DSR that is bigger, sometimes much much bigger, that the number of bytes
you sent (or have received) while with a FIFO you should have a lower number of
ISR/DSR compared to the number of bytes sent/received(otherwise the interest of
the FIFO is questionable).

This is how I ran into this issue, first with the UART driver then I found it
with the other drivers I considered (SSP, CAN).

-- 
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-9836-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Sep 27 11:05:32 2012
Return-Path: <ecos-bugs-return-9836-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 24209 invoked by alias); 27 Sep 2012 11:05:31 -0000
Received: (qmail 24196 invoked by uid 22791); 27 Sep 2012 11:05:31 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0
	tests=AWL,BAYES_00,KHOP_THREADED
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, 27 Sep 2012 11:05:24 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 6BEAF2F78001
	for <ecos-bugs@ecos.sourceware.org>; Thu, 27 Sep 2012 12:05:23 +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 f5RlslVEkvOY; Thu, 27 Sep 2012 12:05:23 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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: ilijak@siva.com.mk
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: nickg@ecoscentric.com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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, 27 Sep 2012 11:05:00 -0000
Message-Id: <20120927110518.158192F7800B@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/msg01265.txt.bz2
Content-length: 1657

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

--- Comment #27 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-27 12:05:14 BST ---
(In reply to comment #25)
> I still think this needs to be commented on by Nick as it involves a
> significant change to the HAL definition, and he's both the HAL in general and
> specifically Cortex-M HAL architect. So I'm assigning this to him and see if he
> grumbles :-). He can always assign it away if he's not interested in commenting
> on the API change.
>
> But I wouldn't overstate the problem, as far I can tell this will only happen
> with certain designs of devices, and only then if certain situations combine,
> which therefore makes it uncommon. That's not to say it's irrelevant, but it's
> not like it happens every interrupt or anything like that.

Jifl, I think that we ought to resolve this issue.

In order to avoid API extension I proposed usage of
cyg_drv_interrupt_acknowledge() (effectively unused by Cortex-M) for which
Bernard has arguments that I respect (our discussion in comment #13 till
comment #20).

On the other hand the addition proposed by Bernard does not affect other
architectures because for them it compiles to empty statement so it could be
considered safe. The questions (for me) are:
    - Is there other alternative way to fix this issue?
    - If we add Bernard's function and associated macro do we bloat our API or
not?

Ilija

--
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.

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

[bugzilla-daemon]

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

Bernd Edlinger <bernd.edlinger@hotmail.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger@hotmail.de

--- Comment #28 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-09-27 13:38:45 BST ---
Hi Bernard,

just one thing...

personally I would not like to add more Kernel APIs unless it is absolutely
necessary.

In the hal/arm subtree when there is an interrupt, the function
hal_IRQ_handler() gets called first. This function determines the
highest priority irq, and updates the ISR (in service register),
this would be a place to clear the interrupt pending bit for your architecture.

Suppose the clear pending is done automatically in hal_IRQ_handler()
and hal_interrupt_acknowledge is empty, then this would be a safe way
to write the isr/dsr in the driver:

isr()
{
  HAL_INTERRUPT_MASK(vector);
  HAL_INTERRUPT_ACKNOWLEGE();
  return CALL_DSR;
}


dsr()
{
   now handle interrupt...

   HAL_INTERRUPT_UNMASK(vector);
}

this is in fact how most drivers are already written today.

would'nt that be OK for you too?

Regards,
Bernd Edlinger

-- 
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.

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

[bugzilla-daemon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 10434 bytes --]

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

--- Comment #29 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-09-27 14:36:11 BST ---
(In reply to comment #28)
>
> this is in fact how most drivers are already written today.
> 
> would'nt that be OK for you too?
> 
> Regards,
> Bernd Edlinger

Hi Bernd,

if the current interrupt handling management was able to fix this issue then
the problem would not exist. Please look at the chronograms:

1) when a 1st ISR occurs, the ISR handler is called, that's ok.
2) the ISR handler schedules a DSR and disable interrupt for the concerned
vector.
3) however a second interrupt condition occurs at that point: the pending bit
is raised because the interrupt can't be triggered by the MCU and hence the
pending bit could not have been cleared earlier in ISR code. This happens
generally in hardware having FIFO or buffers because they have many interrupt
conditions.
4) the DSR is run and processes all interrupt conditions, even the interrupt
condition that made the pending bit to be raised: this is the general design of
all DSR I've seen in eCos: do as much as possible in a single DSR run.
5) There is no API to clear the pending bit at the end of the DSR, hence:
6) the ISR is called again because of the pending bit previously set, even if
the DSR did all required work.
7) the DSR is triggered and have no work to do.

So one have to choose between:

- consider this problem to be cortex-m specific. Side effect: it is not
possible to have generic drivers (UART, SSP, CAN, etc) that can run efficiently
across cortex-m and other architectures because there isn't a common API call
to cancel the pending bit.

- abandon the idea of generic drivers shared between cortex-m and architectures
that don't have the need to manage the pending bit: re-adapt each driver,
mainly by copying files 99.9% identical from some architecture to cortex-m
(IMHO this is where the real bloat risk is)

- change DSR to do as less as possible in a single run: it sounds sarcastic but
today if a driver doesn't handle this issue, this is what happens: ISR and DSR
are triggered multiples times for nothing so why bother to make an efficient
DSR?

- ignore the problem. But cortex-m isn't some bizarre arch that will disappear
in a few months.

- increase eCos API to add a pending bit clearing call.

If there is another solution I would be glad to here about it!


  Bernard

-- 
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-9839-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Sep 27 14:59:55 2012
Return-Path: <ecos-bugs-return-9839-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 28236 invoked by alias); 27 Sep 2012 14:59:54 -0000
Received: (qmail 28228 invoked by uid 22791); 27 Sep 2012 14:59:53 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0
	tests=AWL,BAYES_00,KHOP_THREADED
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, 27 Sep 2012 14:59:49 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 449DA2FB082E
	for <ecos-bugs@ecos.sourceware.org>; Thu, 27 Sep 2012 15:59:48 +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 xJnw2cuy+TWx; Thu, 27 Sep 2012 15:59:48 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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: nickg@ecoscentric.com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: nickg@ecoscentric.com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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, 27 Sep 2012 14:59:00 -0000
Message-Id: <20120927145942.1DA1F2FB0830@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/msg01268.txt.bz2
Content-length: 5121

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

--- Comment #30 from Nick Garnett <nickg@ecoscentric.com> 2012-09-27 15:59:38 BST ---

I'm not at all happy about adding an extra set of HAL and kernel functions to
all architectures just to solve an obscure problem on a single architecture.
Either a better solution needs to be found that can be applied only to the
Cortex-M architecture, or we simply have to live with the consequences.

The proposed change is, in any case, clearly a misuse of the NVIC hardware. The
feature being used is intended to allow individual interrupts to be set pending
by software for testing. The clear register appears to be present mainly as a
side effect of using a common interface for all these NVIC bit masks. I'm sure
ARM do not expect interrupts to be cleared in this way under normal
circumstances, this should be done as a consequence of entering the ISR.

The timing diagram in comment #2 suggests that the real problem will only occur
if the CPU is too slow for the rate of interrupts being delivered.

A better version of that timing diagram might be as follows:

HW |  E1      E2
---|----------------------------
ISR|    I1      I2
---|----------------------------
DSR|         D1=  ===Ò=
The ====== show the time during which the DSR is running. I2 runs during the
execution of D1, posting a second DSR call, which will run immediately after
D1, and in theory will find nothing to do.

I can see two situations in which this can happen.

1. The CPU is simply too slow to finish running D1 before E2/I2 run, even if D1
was started immediately after I1 completed. If the events are coming at this
rate continually, then the CPU simply won't keep up. If they come in infrequent
bursts, then the odd extra ISR/DSR is of little consequence, and is part of the
cost of dealing with a temporary overload.

2. The start of D1 was delayed because eCos had the scheduler locked when I1
ran. This is a consequence of the ISR/DSR model. If I2 ran before D1 started,
then the DSR would only be called once, with a larger count value. If I2 runs
after D1 starts, it may post a separate DSR; but this is true for all
architectures, not just this one.

Adding an interrupt cancel anywhere in D1 would only deal with any new events
that were posted before that point. E2 could occur just after the cancel, and
would still result in an extra ISR/DSR. The proposed solution can only reduce
the number of extra ISR/DSRs, never eliminate them entirely.

I also don't believe this is entirely an eCos problem. It is also present in
the Cortex-M nested interrupt model, and is the expected/intended behaviour.
Consider a system that is only using ISRs. Here's a timing diagram:

HW  |  E1   E2   E1
----|----------------------------
ISR1|    I1===      ===I1=====----|----------------------------
ISR2|         I2===
Here there are two devices, 1 and 2, with associated ISRs; ISR1 is lower
priority than ISR2. If ISR1 is running when device 2 raises an interrupt, then
it will be pre-empted and ISR2 will run. If ISR2 runs for long enough then it
may delay the completion of ISR1 until after a new device 1 interrupt is
posted. This will re-set the pending bit and immediately after ISR1 returns, it
will be re-entered. The same will happen in the absence of nested ISRs if ISR1
just takes too long to process the first event before the second occurs.

This is similar to the eCos situation. So long as these things occur
infrequently, then extra ISRs are simply a cost of handling bursts of
interrupts. If it happens frequently then that is an indication that the CPU is
too slow to keep up with the interrupt rate.


I wasn't sure what conclusion I would come to when I started writing this, but
I think I have convinced myself that this is actually a non-issue. The proposal
cannot eliminate these extra ISR/DSR calls completely; the problem is not eCos
specific; it is not Cortex-M specific either; the issue only seriously affects
systems that are on the edge of being too slow to cope with the interrupt rate.
The worst aspect of the proposal is that it spreads its tentacles into all
other architectures and device drivers.

However, comment #7 contains a seed of a better solution. Many device drivers
are somewhat lazy in using cyg_drv_interrupt_mask() and friends to control
interrupt delivery; and it is this that is the main cause of the problem. They
should really use peripheral registers to do this, where possible. Certainly
generic drivers like the 16x5x driver should. I switched the eCosCentric
version of this driver over to doing exactly this earlier this year and can
contribute a patch to do that for the public version. Other drivers should be
converted as and when convenient. Those devices that don't have local control
of interrupts will just have to continue with the current approach and accept
the consequences.

--
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.

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

[bugzilla-daemon]

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

--- Comment #31 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-09-27 19:09:39 BST ---
Thanks Nick to have taken the time to answer to this report!

(In reply to comment #30)
> 
> I wasn't sure what conclusion I would come to when I started writing this, but
> I think I have convinced myself that this is actually a non-issue. The proposal
> cannot eliminate these extra ISR/DSR calls completely; the problem is not eCos
> specific; it is not Cortex-M specific either; the issue only seriously affects
> systems that are on the edge of being too slow to cope with the interrupt rate.

The issue happens for all peripherals that can trigger an interrupt for
different and asynchronous reasons that the interrupt being processed.

This can happen at any clocking speed: typically you fill a FIFO or a buffer
for data output and the incoming side of the peripheral reports at that time
that an event from outside is to be considered. Or you are emptying a FIFO and
the transmit FIFO is available again. Or the CAN buffer you filled previously
is now available while you are filling a newer buffer.

The last time I checked, my system was running zero unneeded DSR while I can
have up to 4 UART, SSP and CAN working so the proposed fix is efficient, at
least in my case.

I'm really curious if some other tried to count ISR/DSR regarding to the volume
of exchanged data, but at the moment nobody gave me counts made on another
system.

> The worst aspect of the proposal is that it spreads its tentacles into all
> other architectures and device drivers.

I agree... 

> 
> However, comment #7 contains a seed of a better solution. Many device drivers
> are somewhat lazy in using cyg_drv_interrupt_mask() and friends to control
> interrupt delivery; and it is this that is the main cause of the problem. They
> should really use peripheral registers to do this, where possible. Certainly
> generic drivers like the 16x5x driver should. I switched the eCosCentric
> version of this driver over to doing exactly this earlier this year and can
> contribute a patch to do that for the public version. Other drivers should be
> converted as and when convenient. Those devices that don't have local control
> of interrupts will just have to continue with the current approach and accept
> the consequences.

IIRC some peripherals trigger an interrupt on the rising edge of an event but
won't make any interrupt if the enable interrupt bit is set in their interrupt
enabling register after the event occurred: if the peripheral event occurs
exactly after the DSR reads the peripheral register (so the DSR thinks there is
no more job to do) but before the DSR re-enables peripheral interrupts then an
event may be lost. If this can happen, then there is no other solution than to
handle that interrupt pending bit.

My guess is that the 'pending interrupt bit' is designed to avoid this race
condition, at least you go for another ISR and/or DSR round but you don't lose
anything.

Pure speculation from me: HW peripheral designers may count on this feature to
lower the gate count of their cell, they send to the MCU the pulse of the event
when it occurs, they don't check when the interrupt register is written if an
interrupt condition should be triggered (have the MCU do a bit more so all
peripherals can do and cost less).

Unless someone else count ISR/DSR runs in a fast clocking system different than
mine, I'll stay convinced that this problem occurs frequently in many different
systems.

-- 
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-9841-listarch-ecos-bugs=sources.redhat.com@sourceware.org Fri Sep 28 15:59:49 2012
Return-Path: <ecos-bugs-return-9841-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 5471 invoked by alias); 28 Sep 2012 15:59:48 -0000
Received: (qmail 5460 invoked by uid 22791); 28 Sep 2012 15:59:47 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0
	tests=AWL,BAYES_00,KHOP_THREADED
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; Fri, 28 Sep 2012 15:59:42 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id B2A372F7800C
	for <ecos-bugs@ecos.sourceware.org>; Fri, 28 Sep 2012 16:59:40 +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 DUtKA1g8fiuY; Fri, 28 Sep 2012 16:59:38 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001606] Enable the cache on Kinetis in RAM startup mode
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: ilijak@siva.com.mk
X-Bugzilla-Status: NEEDINFO
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: jifl@ecoscentric.com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001606-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001606-13@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: Fri, 28 Sep 2012 15:59:00 -0000
Message-Id: <20120928155937.CCB732F78001@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/msg01270.txt.bz2
Content-length: 2803

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

--- Comment #18 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-28 16:59:26 BST ---
Created an attachment (id\x1945)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id\x1945)
Cache and DDRAM fixes/improvements 120928

(In reply to comment #5)

Hi Jifl

Here I attach a patch with some fixes that I have announced in my previous
posts. In addition to addressing your remarks that I have accepted in comment
#7 I have added some fixes to DDRAM configuration. Main improvements are PAD
control, and slight memory optimization of initialization code for DDRAM.

> Hi Ilija,
>
> Looking at this patch, I decided to look a bit closer at the Kinetis. Some
> things to do with caches strike me as a bit unusual, but hopefully you can
> clarify where my misunderstandings lie:
>
[ snip - discussed in previous replies]

>
> Not related to the particular patch, but still to do with caching
> configuration... Some subsystems have their caching configuration set under
> CYGPKG_HAL_KINETIS_CACHE, whereas others have them set in their own tree - or
> at least SDRAM/DDR does, but I haven't looked more widely for others. And the
> two key interfaces CYGINT_HAL_CACHE and CYGINT_HAL_HAS_NONCACHEABLE live under
> a separate component CYGHWR_HAL_KINETIS_MEMORY_RESOURCES.

Now they are moved out of CYGHWR_HAL_KINETIS_MEMORY_RESOURCES.

>I think related
> options ought to be kept in the same place. OR if there's a good reason why
> not, a note should be placed in the description e.g. of
> CYGPKG_HAL_KINETIS_CACHE pointing users in the right direction of other
> cache-related configuration options.

I assume you are referring to CYGHWR_HAL_KINETIS_DDR_NON_CACHED_SIZE_MIB and
similar options. They are DDRAM rather than cache configuration options. But
you are right, some explanation is good idea so I wrote explanatory
descriptions for CDLs under DDRAM. Also I grouped "cachable" and "non-cachable"
options so now DDRAM CDL should look simple and more compact.

[snipped - replied earlier in other comments]

>
> - Incidentally some of the indentation in the kinetis CDL is a bit off,
> e.g. underneath CYGHWR_HAL_KINETIS_FLEXNVM_FLASH_SIZE, at the end of
> CYGPKG_HAL_CORTEXM_KINETIS_FLEXBUS and beginning of
> CYGHWR_HAL_KINETIS_FLASH_CONF.

Reformatted.



The attached evolution patch does not affect (and should not be affected by)
our eventual change of cache treatment (separate / unified). I have tested the
code on K60 and K70, and I would like to commit it if you don't have
objections.

Ilija

--
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.

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

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
                 CC|                            |jifl@ecoscentric.com
         AssignedTo|unassigned@bugs.ecos.source |nickg@ecoscentric.com
                   |ware.org                    |
     Ever Confirmed|0                           |1

--- Comment #25 from Jonathan Larmour <jifl@ecoscentric.com> 2012-09-26 22:43:50 BST ---
I still think this needs to be commented on by Nick as it involves a
significant change to the HAL definition, and he's both the HAL in general and
specifically Cortex-M HAL architect. So I'm assigning this to him and see if he
grumbles :-). He can always assign it away if he's not interested in commenting
on the API change.

But I wouldn't overstate the problem, as far I can tell this will only happen
with certain designs of devices, and only then if certain situations combine,
which therefore makes it uncommon. That's not to say it's irrelevant, but it's
not like it happens every interrupt or anything like that.

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

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

[bugzilla-daemon]

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

Phil <pme.neratec@gmx.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pme.neratec@gmx.ch

--- Comment #24 from Phil <pme.neratec@gmx.ch> 2012-09-26 17:15:10 BST ---
If the situation is as described by Bernard Fouché, this means eCos is not well
suited for Cortex-M3 (e.g. STM32 or LPC17xx) platform!

Why is no eCos proponent reacting on this bug?

When is the NVIC_ClearPendingIRQ function needed, only if this is an external
interrupt that needs to be handled?

@Bernard Fouché: In the Cortex-M3 (e.g. STM32 or LPC17xx) the processor
automatically clears the pending bit when it calls the interrupt handler (see
STM32 Programming Manual (CD00228163.pdf) page 128, "A pending interrupt
remains pending until one of the following: The processor enters the ISR for
the interrupt..."). Why do you think this must be done programmatically?

-- 
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-9831-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Sep 26 16:15:45 2012
Return-Path: <ecos-bugs-return-9831-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 1966 invoked by alias); 26 Sep 2012 16:15:40 -0000
Received: (qmail 1828 invoked by uid 22791); 26 Sep 2012 16:15:37 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0
	tests=AWL,BAYES_00,KHOP_THREADED
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; Wed, 26 Sep 2012 16:15:25 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id E2BF22F7800A
	for <ecos-bugs@ecos.sourceware.org>; Wed, 26 Sep 2012 17:15:23 +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 BEdTduubPtcB; Wed, 26 Sep 2012 17:15:23 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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: pme.neratec@gmx.ch
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: CC
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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: Wed, 26 Sep 2012 16:15:00 -0000
Message-Id: <20120926161515.879072FB082C@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/msg01260.txt.bz2
Content-length: 1302

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

Phil <pme.neratec@gmx.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pme.neratec@gmx.ch

--- Comment #24 from Phil <pme.neratec@gmx.ch> 2012-09-26 17:15:10 BST ---
If the situation is as described by Bernard Fouché, this means eCos is not well
suited for Cortex-M3 (e.g. STM32 or LPC17xx) platform!

Why is no eCos proponent reacting on this bug?

When is the NVIC_ClearPendingIRQ function needed, only if this is an external
interrupt that needs to be handled?

@Bernard Fouché: In the Cortex-M3 (e.g. STM32 or LPC17xx) the processor
automatically clears the pending bit when it calls the interrupt handler (see
STM32 Programming Manual (CD00228163.pdf) page 128, "A pending interrupt
remains pending until one of the following: The processor enters the ISR for
the interrupt..."). Why do you think this must be done programmatically?

-- 
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-9833-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Sep 26 21:44:14 2012
Return-Path: <ecos-bugs-return-9833-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 26184 invoked by alias); 26 Sep 2012 21:44:14 -0000
Received: (qmail 26175 invoked by uid 22791); 26 Sep 2012 21:44:13 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0
	tests=AWL,BAYES_00,KHOP_THREADED
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; Wed, 26 Sep 2012 21:44:00 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id ED56E2F7800D
	for <ecos-bugs@ecos.sourceware.org>; Wed, 26 Sep 2012 22:43:58 +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 WcK9fYMVXz8X; Wed, 26 Sep 2012 22:43:58 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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: jifl@ecoscentric.com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: nickg@ecoscentric.com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status CC AssignedTo Ever Confirmed
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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: Wed, 26 Sep 2012 21:44:00 -0000
Message-Id: <20120926214356.A74FF2FB082C@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/msg01262.txt.bz2
Content-length: 1491

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
                 CC|                            |jifl@ecoscentric.com
         AssignedTo|unassigned@bugs.ecos.source |nickg@ecoscentric.com
                   |ware.org                    |
     Ever Confirmed|0                           |1

--- Comment #25 from Jonathan Larmour <jifl@ecoscentric.com> 2012-09-26 22:43:50 BST ---
I still think this needs to be commented on by Nick as it involves a
significant change to the HAL definition, and he's both the HAL in general and
specifically Cortex-M HAL architect. So I'm assigning this to him and see if he
grumbles :-). He can always assign it away if he's not interested in commenting
on the API change.

But I wouldn't overstate the problem, as far I can tell this will only happen
with certain designs of devices, and only then if certain situations combine,
which therefore makes it uncommon. That's not to say it's irrelevant, but it's
not like it happens every interrupt or anything like that.

--
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.

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

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickg@ecoscentric.com

--- Comment #22 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-02 22:22:16 BST ---
Any changes in this area to either Cortex-M arch HAL or the kernel, especially
the API, would definitely need to be approved by Nick. I'm adding him to CC.

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

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

[bugzilla-daemon]

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

--- Comment #18 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-23 09:58:31 GMT ---
(In reply to comment #17)
> If you have at hand "The definitive guide to the ARM Cortex-M3" by Joseph Yiu:
> see chapter 7, "Interrupt Inputs and Pending Behavior" section,  especially
> figure 7.13, this is exactly what I observed.

I guess that in context of this bug you probably mean fig 7.14. (i guess the
number at the bottom of fig.).

For solution I would return to cyg_drv_interrupt_acknowledge() since that's
what it's supposed to do: "Perform any processing required at the interrupt
controller and in the CPU to cancel the current interrupt request on the
vector. An ISR may also need to program the hardware of the device to prevent
an immediate re-triggering of the interrupt."
Only, it should be called later than it is called now. I acknowledge your
concern about generic serial driver but it has some conditional code already so
adding little-bit more wouldn't harm (or IMO the impact will be lower than
adding functions on Kernel level).

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

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

[bugzilla-daemon]

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

--- Comment #15 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-16 15:29:18 GMT ---
(In reply to comment #14)
> (In reply to comment #13)
> > Changes to the Kernel should be done with caution. I think that this addition
> > is not necessary. The desired functionality, for a given platform, can be
> > introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).
> 
> There are two problems:
> 
> - clearing the pending interrupt bit is completely different from acknowledging
> an interrupt. Acknowledgment is usually done at the end of DSR/ISR while
> clearing the pending interrupt bit must be done *before* reading the peripheral
> registers describing interrupt source(s): HAL_VAR_INTERRUPT_ACKNOWLEDGE is not
> a solution.
> 
> - if HAL_VAR_INTERRUPT_CLEAR_PENDING is added only to Cortex-M targets, then
> how can one share a driver between an arch not requiring clearing pending
> interrupt and Cortex-M cores? For instance the generic serial 16x5x driver?
> Today cyg_drv_interrupt_acknowledge() resolves to CYG_EMPTY_STATEMENT for
> Cortex-M, IMHO we need cyg_drv_interrupt_clear_pending() to resolve to
> CYG_EMPTY_STATEMENT for non-Cortex-M, hence one can write a driver using both
> cyg_drv_interrupt_acknowledge() and cyg_drv_interrupt_clear_pending() at the
> correct place so the driver can work in different arch.

Normally acknowledge should be enough. Regarding the IRQ re-triggering you have
found out, maybe (some of) LPC17xx peripherals employ pulsed rather than level
interrupts. Here is what's Cortex-M NVIC doc saying about it.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Bhchgeei.html

Then, if we must implement HAL_VAR_INTERRUPT_CLEAR_PENDING I would suggest to
do it on LPC17xx variant or, if the problem appears on other variants consider
Cortex-M architecture level, and avoid patching kernel files. FYI as i
mentioned earlier I'll do some tests on Kinetis during next week.

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

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

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-09 11:30:20 GMT ---
(In reply to comment #5)

> I don't have any feedback from any eCos maintainer... what's going on :-) ?

Hi Bernard

I am following your posts, but I am little-bit busy so I can't respond. My plan
is to try to reproduce your cases on Kinetis and compare. I hope to have more
time following week.

Ilija

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

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

[bugzilla-daemon]

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

--- Comment #4 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 09:39:50 GMT ---
Created an attachment (id=1570)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1570)
logic analyzer trace showing that interrupt_clear_pending() is badly needed for
Cortex-M core

-- 
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-8809-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 09:40:21 2012
Return-Path: <ecos-bugs-return-8809-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 6797 invoked by alias); 9 Feb 2012 09:40:20 -0000
Received: (qmail 6788 invoked by uid 22791); 9 Feb 2012 09:40:19 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
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 09:40:03 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 7A5462F78006
	for <ecos-bugs@ecos.sourceware.org>; Thu,  9 Feb 2012 09:40:02 +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 Ryf6XT3XlkjS; Thu,  9 Feb 2012 09:39:55 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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 09:40:00 -0000
Message-Id: <20120209093954.BCCD52F78004@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/msg00238.txt.bz2
Content-length: 595

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

--- Comment #4 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 09:39:50 GMT ---
Created an attachment (id=1570)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1570)
logic analyzer trace showing that interrupt_clear_pending() is badly needed for
Cortex-M core

-- 
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-8811-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 09:40:38 2012
Return-Path: <ecos-bugs-return-8811-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 6970 invoked by alias); 9 Feb 2012 09:40:38 -0000
Received: (qmail 6958 invoked by uid 22791); 9 Feb 2012 09:40:37 -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 09:40:24 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id ED6252F78001; Thu,  9 Feb 2012 09:40:22 +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 09:40:00 -0000
Message-Id: <20120209094020.1E1C82F78001@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/msg00240.txt.bz2
Content-length: 2518

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

--- Comment #5 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 09:40:16 GMT ---
Final demonstration done with a logic analyzer on a serial channel. The trace
has been done with the fix described in bug #1001480 otherwise the result is
even worse.

More exactly, I applied the fix but I removed a call to
interrupt_clear_pending().

Trace description:

- channel 0: ISR: a GPIO pin is set a low level when entering ISR, to a high
level when ISR exits.
- channel 1: a GPIO pin changes of state each time the DSR runs without doing
any processing.
- channel 2: DSR: a GPIO pin is set a low level when entering DSR, to a high
level when DSR exits.
- channel 3: start_xmit: a GPIO pin is set a low level when entering
start_xmit(), to a high level when start_xmit() exits.
- the other channels show serial link activity (RTS/TX/RX/CTS)

What the trace shows:

- start_xmit() is called, the fix described in bug #1001480 makes this function
to first fill the TX FIFO before activating the TX interrupt.

- 'A' is clocked out on the serial link. When it is nearly completely output,
TX interrupt fires ISR.

- ISR (first run) masks interrupt (so the interrupt is disabled), and return
value tells eCos to post DSR. However the interrupt source hasn't been
processed yet in the concerned peripheral, so the Cortex-M core raises the
interrupt pending bit!

- DSR is fired (first run). It sees that it was triggered because of a TX int,
however there is no more byte to output at that time. DSR unmask interrupts but
pending interrupts for that vector where not cleared: a new ISR is fired during
DSR execution.

- ISR (second run) does as always: mask interrupt, post DSR.

- Note that during the first DSR run, the 'flip/flop' reporting DSR running for
nothing wasn't toggled at this time: this is because the DSR did real work: it
processed the TX int.

- as soon as DSR ends, because of the intermediary ISR that occurred while DSR
was running, DSR runs again (second run).

- however there is nothing to do since latest ISR/DSR did the TX interrupt
processing job: flip/flop pin shows that DSR did nothing.

I don't have any feedback from any eCos maintainer... what's going on :-) ?

-- 
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-8812-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 09:40:39 2012
Return-Path: <ecos-bugs-return-8812-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 6997 invoked by alias); 9 Feb 2012 09:40:38 -0000
Received: (qmail 6960 invoked by uid 22791); 9 Feb 2012 09:40:37 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
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 09:40:23 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 410DD2F78005
	for <ecos-bugs@ecos.sourceware.org>; Thu,  9 Feb 2012 09:40:22 +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 Yh8hLMNdGDRj; Thu,  9 Feb 2012 09:40:20 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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 09:40:00 -0000
Message-Id: <20120209094020.48EE62F78004@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/msg00241.txt.bz2
Content-length: 2520

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

--- Comment #5 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 09:40:16 GMT ---
Final demonstration done with a logic analyzer on a serial channel. The trace
has been done with the fix described in bug #1001480 otherwise the result is
even worse.

More exactly, I applied the fix but I removed a call to
interrupt_clear_pending().

Trace description:

- channel 0: ISR: a GPIO pin is set a low level when entering ISR, to a high
level when ISR exits.
- channel 1: a GPIO pin changes of state each time the DSR runs without doing
any processing.
- channel 2: DSR: a GPIO pin is set a low level when entering DSR, to a high
level when DSR exits.
- channel 3: start_xmit: a GPIO pin is set a low level when entering
start_xmit(), to a high level when start_xmit() exits.
- the other channels show serial link activity (RTS/TX/RX/CTS)

What the trace shows:

- start_xmit() is called, the fix described in bug #1001480 makes this function
to first fill the TX FIFO before activating the TX interrupt.

- 'A' is clocked out on the serial link. When it is nearly completely output,
TX interrupt fires ISR.

- ISR (first run) masks interrupt (so the interrupt is disabled), and return
value tells eCos to post DSR. However the interrupt source hasn't been
processed yet in the concerned peripheral, so the Cortex-M core raises the
interrupt pending bit!

- DSR is fired (first run). It sees that it was triggered because of a TX int,
however there is no more byte to output at that time. DSR unmask interrupts but
pending interrupts for that vector where not cleared: a new ISR is fired during
DSR execution.

- ISR (second run) does as always: mask interrupt, post DSR.

- Note that during the first DSR run, the 'flip/flop' reporting DSR running for
nothing wasn't toggled at this time: this is because the DSR did real work: it
processed the TX int.

- as soon as DSR ends, because of the intermediary ISR that occurred while DSR
was running, DSR runs again (second run).

- however there is nothing to do since latest ISR/DSR did the TX interrupt
processing job: flip/flop pin shows that DSR did nothing.

I don't have any feedback from any eCos maintainer... what's going on :-) ?

-- 
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-8814-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 11:30:47 2012
Return-Path: <ecos-bugs-return-8814-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 21275 invoked by alias); 9 Feb 2012 11:30:47 -0000
Received: (qmail 21256 invoked by uid 22791); 9 Feb 2012 11:30:46 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
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 11:30:27 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 3448C2F78001
	for <ecos-bugs@ecos.sourceware.org>; Thu,  9 Feb 2012 11:30:26 +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 TcQdyJSpHJap; Thu,  9 Feb 2012 11:30:25 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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: ilijak@siva.com.mk
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: CC
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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 11:30:00 -0000
Message-Id: <20120209113024.5D0012F78005@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/msg00243.txt.bz2
Content-length: 925

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-09 11:30:20 GMT ---
(In reply to comment #5)

> I don't have any feedback from any eCos maintainer... what's going on :-) ?

Hi Bernard

I am following your posts, but I am little-bit busy so I can't respond. My plan
is to try to reproduce your cases on Kinetis and compare. I hope to have more
time following week.

Ilija

--
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.

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

[bugzilla-daemon]

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

--- Comment #2 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-24 16:10:54 GMT ---
Some ASCII art to try to better explain the issue:

HW |  E1      E2
---|----------------------------
ISR|    I1          I2
---|----------------------------
DSR|              D1          D2

E1: a 1st event occurs

I1: ISR related to E1 triggered, ISR masks interrupt and asks
for a DSR run.

E2: a 2nd event occurs but since interrupt is masked, pending
interrupt register bit is set and ISR is not run.

D1: DSR processes everything it can (for instance it empties a RX
FIFO). DSR unmasks interrupt at the end of processing.

I2: because E2 occurred while interrupt was masked and since
pending interrupt bit is set, I2 now occurs.

D2: DSR runs, and find no work to do because D1 did all the work.

In this example, there were 1 ISR (I2) and 1 DSR (D2) that ran for
nothing.

-- 
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-8696-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 24 16:11:24 2012
Return-Path: <ecos-bugs-return-8696-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 29161 invoked by alias); 24 Jan 2012 16:11:20 -0000
Received: (qmail 29150 invoked by uid 22791); 24 Jan 2012 16:11:18 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
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, 24 Jan 2012 16:11:05 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 75C031518931
	for <ecos-bugs@ecos.sourceware.org>; Tue, 24 Jan 2012 16:11:04 +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 juX7TTrtVdqu; Tue, 24 Jan 2012 16:11:00 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
 wasted processing power
X-Bugzilla-Reason: CC
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-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@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: Tue, 24 Jan 2012 16:11:00 -0000
Message-Id: <20120124161100.0DD841518936@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/msg00125.txt.bz2
Content-length: 1180

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

--- Comment #2 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-24 16:10:54 GMT ---
Some ASCII art to try to better explain the issue:

HW |  E1      E2
---|----------------------------
ISR|    I1          I2
---|----------------------------
DSR|              D1          D2

E1: a 1st event occurs

I1: ISR related to E1 triggered, ISR masks interrupt and asks
for a DSR run.

E2: a 2nd event occurs but since interrupt is masked, pending
interrupt register bit is set and ISR is not run.

D1: DSR processes everything it can (for instance it empties a RX
FIFO). DSR unmasks interrupt at the end of processing.

I2: because E2 occurred while interrupt was masked and since
pending interrupt bit is set, I2 now occurs.

D2: DSR runs, and find no work to do because D1 did all the work.

In this example, there were 1 ISR (I2) and 1 DSR (D2) that ran for
nothing.

-- 
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-8698-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 24 19:25:45 2012
Return-Path: <ecos-bugs-return-8698-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 29857 invoked by alias); 24 Jan 2012 19:25:43 -0000
Received: (qmail 29831 invoked by uid 22791); 24 Jan 2012 19:25:43 -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; Tue, 24 Jan 2012 19:25:29 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id D0F1315189C3; Tue, 24 Jan 2012 19:25:27 +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: 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-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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Tue, 24 Jan 2012 19:25:00 -0000
Message-Id: <20120124192524.E49D515189C3@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/msg00127.txt.bz2
Content-length: 2124

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

--- Comment #9 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-24 19:25:16 GMT ---
(In reply to comment #8)
>
> So far only one comment.
> 
> Still try to be very careful when planning to change generic CAN I/O
> API. There is not only a dependence (LPC2XXX).
> 
>   % ecosconfig list | grep DEVS_CAN
>   Package CYGPKG_DEVS_CAN_AT91SAM7 (AT91SAM7 CAN device drivers):
>   Package CYGPKG_DEVS_CAN_LOOP (Loop CAN device drivers):
>   Package CYGPKG_DEVS_CAN_LPC2XXX (LPC2xxx CAN device drivers):
>   Package CYGPKG_DEVS_CAN_MCF52xx_FLEXCAN (MCF52xx FlexCAN device drivers):
> 
> Sergei

I've seen this. The only change that impacts other packages is the
CYGNUM_CAN_EVENT_OVERRUN_RX event.

Today this event has two meaning: 1) because the eCos RX queue is overwritten
by a new message 2) a hardware related overrun. So when the event occurs, one
can't know if it's because the receive queue is undersized (or the application
is to slow to empty the queue), or if the driver isn't fast enough to process
CAN bus activity, which is very different. So I've made a
CYGNUM_CAN_EVENT_OVERRUN_RX_HW event for the second case.

I've modified the AT91SAM7 and MCF52XX driver accordingly (one line is patched
just to change the name of the event since this event is generated only in one
place. Since all CAN drivers have been written by Uwe Kindler and follow the
same logic it's easy to understand the code from a driver to the other).

LPC2XXX driver I'll patch without my other changes, so every driver will be
kept coherent with the CAN IO package.

The loop driver does not require any change since it does not handle hardware.

Everything else I added is supported by older driver since it's just a matter
of API convention defaulting to the set of features supported by older drivers.

-- 
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-8700-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 24 19:47:20 2012
Return-Path: <ecos-bugs-return-8700-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 2882 invoked by alias); 24 Jan 2012 19:47:19 -0000
Received: (qmail 2873 invoked by uid 22791); 24 Jan 2012 19:47:18 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
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, 24 Jan 2012 19:46:59 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 5806715189D0
	for <ecos-bugs@ecos.sourceware.org>; Tue, 24 Jan 2012 19:46: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 uBYa+MwxE8VX; Tue, 24 Jan 2012 19:46:57 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage
 and NXP flash checksum
X-Bugzilla-Reason: CC
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: ilijak@siva.com.mk
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status Resolution
In-Reply-To: <bug-1001395-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001395-13@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: Tue, 24 Jan 2012 19:47:00 -0000
Message-Id: <20120124194656.BC17015189D5@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/msg00129.txt.bz2
Content-length: 689

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-24 19:46:53 GMT ---
Checked in.

--
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.