public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@ecoscentric.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: martin.laabs@mailbox.tu-dresden.de, ecos-devel@ecos.sourceware.org
Subject: Re: Patch for CYGPKG_IO_SERIAL_ARM_LPC2XXX
Date: Sun, 23 Nov 2008 22:20:00 -0000	[thread overview]
Message-ID: <pny6zaqe68.fsf@delenn.bartv.net> (raw)
In-Reply-To: <20081122191149.GO17925@lunn.ch> (message from Andrew Lunn on 	Sat, 22 Nov 2008 20:11:49 +0100)

>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:

    >> PS: Is it possible to avoid assignment of equal priorities to
    >> different IRQs at same time in configtool/cdl.

    Andrew> You can use an implies statement in one of the options. eg
    Andrew> in CYGNUM_IO_SERIAL_ARM_LPC2XXX_SERIAL0_INTPRIO0 have


    Andrew>     requires { is_active(CYGNUM_IO_SERIAL_ARM_LPC2XXX_SERIAL0_INTPRIO1) 
    Andrew>                    implies { CYGNUM_IO_SERIAL_ARM_LPC2XXX_SERIAL0_INTPRIO0 != 
    Andrew>                              CYGNUM_IO_SERIAL_ARM_LPC2XXX_SERIAL0_INTPRIO1 }
    Andrew>              }

That works for the specific case of preventing the two serial devices
from sharing the same interrupt priority, but does not prevent a
serial device from being given the same priority as some other device
(which I assume is the limitation within the LPC VIC).

I have run into similar problems on some ColdFire processors.
Unfortunately right now there is no good way of imposing the
constraint in CDL. The syntax for that would look something like:

  cdl_option CYGDAT_HAL_ARM_LPC2XXX_INTPRIO(0 to 31) {
      flavor        data
      default_value "user"
  }

  cdl_option CYGNUM_IO_SERIAL_ARM_LPC2XXX_SERIAL0_INTPRIO {
      legal_values 0 to 31
      requires    { CYGDAT_HAL_ARM_LPC2XXX_INTPRIO($self) == "uart0" }
  }

As long as all relevant device drivers, and anything else that
installed an interrupt handler, had a config option like that per
interrupt source the "requires" constraints would prevent two devices
being given the same interrupt priority. Also, the application
developer could see which interrupt priorities were still available,
and could reserve certain ones by setting user values.

Unfortunately there are no plans at present to extend the CDL language
with facilities like that.

What I have done in the past is to add a testcase to the processor HAL
which walks through the interrupt vectors, reports the priority
associated with each one, and checks for any conflicts. You can then
run that testcase in your configuration. However that won't catch
clashes between priorities used by device drivers and ones used by
application code. Another approach is to have a debug version of the
interrupt SET_LEVEL() macro which does a run-time check.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

  reply	other threads:[~2008-11-23 22:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-22 16:06 Martin Laabs
2008-11-22 19:12 ` Andrew Lunn
2008-11-23 22:20   ` Bart Veer [this message]
2008-11-23 13:53 ` Andrew Lunn
2008-11-23 14:52   ` Martin Laabs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pny6zaqe68.fsf@delenn.bartv.net \
    --to=bartv@ecoscentric.com \
    --cc=andrew@lunn.ch \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=martin.laabs@mailbox.tu-dresden.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).