From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ARM interrupt handling - was: interrupt handling
Date: Mon, 24 Jun 2013 11:46:22 +0200 [thread overview]
Message-ID: <20130624094622.CC6D3380DDB@gemini.denx.de> (raw)
In-Reply-To: <20130622115844.0a9b0c9a@lilith>
Dear Albert,
In message <20130622115844.0a9b0c9a@lilith> you wrote:
>
> From time to time there is discussion about the need for proper
> interrupt support in U-Boot.
>
> Right now, the only thing left in the source code which remotely looks
> like interrupt support is a few code sections compiled conditionally
> under CONFIG_USE_IRQ, and it does not constitute a good approach to
> interrupt support, if only for the following reasons:
I think we should add as an explanation here thatt allt his refers to
the ARM architecture.
For other architectures the situation is different. Some (like PPC)
already have working interrupt support.
> So I am tempted to start this RFC with a first question: do we *need*
> interrupts in the first place, and if we do, do we need an organized
> interrupts subsystem or do we keep an ad hoc approach?
In the strict sense we do not mandatorily _need_ interrupts.
We always claim that U-Boot is strictly single-tasking. Of course
interrupts can also be used in a strictly single-tasking way (which
would essentially be the same as polling), but I would expect that
they open a door to multiple parallel threads of execution.
Like other powerful tools this can be very useful, but it can also be
dangerous if used without the necessary care.
I the past I have seen a number of situations where the (sensible!)
use of interrupts would have significantly reduced the efforts, or
allowed for cleaner implementations, or even enbaled to implement
certain functionality in a clean way - for example for appearently
simple requirements like a blinking status LED.
For example, having just an interrupt based timer implementation could
help to implement a few things in a simpler and cleaner way.
My gut feeling is that adding interrupt support would be a good thing.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is better to marry than to burn.
- Bible ``I Corinthians'' ch. 7, v. 9
prev parent reply other threads:[~2013-06-24 9:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-22 9:58 [U-Boot] [RFC] interrupt handling Albert ARIBAUD
2013-06-22 11:10 ` Stefan Roese
2013-06-24 12:23 ` Lukasz Majewski
2013-06-24 9:46 ` Wolfgang Denk [this message]
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=20130624094622.CC6D3380DDB@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.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