cc'ing Sebastian: Looks like the ss555 BSP is an odd case
for IRQ legacy code. Thoughts?
On 6/15/2013 1:14 PM, Vipul Nayyar wrote:
------------------------------------------------------------------------
*From:* Joel Sherrill <[email protected]>
*To:* [email protected]; Vipul Nayyar <[email protected]>
*Sent:* Saturday, 15 June 2013 10:44 PM
*Subject:* Re: Guidance required for PIC API
Hi
I hate to reply to myself but to make the work flow clearer,
here is a rough view
For each area to be worked
- identify proper usage pattern
- document this pattern and put to rtems-devel for review
- final version with instructions goes in BSP and Device Driver Guide
- implement script to find violations of pattern
- probably enhancements to check_subm ission or successor
- Fix violations
- Address "enhancements" that are not standard
- could be merged into main API/pattern
- Submit incrementally
As I mentioned for the PIC IRQ, there is a new "shared generic" framework.
I know there are BSPs which should include more in their Makefile.am
but don't.
There are BSPs which use different names or have content in
differently named
files.
There is old IRQ code possibly lurking and possibly used.
SPARC has adaption of new shared PIC code implemented on top of Simple
API. That code can be made generic.
Is there a distinction between old & new code. How do identify it ?
Yes. There were multiple iterations of old PIC code. The new PIC code should
all be centered around the files in c/src/lib/libbsp/shared/irq* with
expectations of BSP specific irq code. That's where the reference to
arm/lpc24xx/Makefile.am for the complete list of shared and BSP specific
files.
Action: Ensure all BSPs using shared IRQ code include all files in their
build and use standard names.
irq-generic.h has a list of deprecated methods. It provides implementations
of them in irq-legacy.c.
Action: Kill all legacy/deprecated API uses in the tree. Review where they
used and make sure we didn't miss any.
Question: What about the ss555 BSP? CC'ed Sebastian above for guidance.
FWIW I don't see what we used to call old-exceptions in the tree anymore.
Hopefully the irq-legacy.c methods are the ones to kill uses of.
That should kill "legacy IRQ uses" inside the tree. irq-legacy.c remains for
uses outside tree.
Phase 2: The Simple IRQ Model uses rtems_interrupt_catch in the cpukit and
set_vector() provided by a BSP. SPARC wraps the shared PIC IRQ code
on top of that. It would be nice on all targets.
That's more or less a work plan for that topic.
On 6/15/2013 10:39 AM, Joel Sherrill wrote:
Unified implies all do things the same way with the same APIs, BSPs include all
the proper components and implement what is expected of them in a standard way.
Go back to my challenge question. The arm lpc24xx is probably a good reference.
What files does it share for generic IRQ handling? What files does if provide
itself? Do other BSPs using this framework on this and other architectures
include all the generic files? Use the same name for BSP specific ones?
I recall finding one BSP which did not include them all and an entire
architecture which put a method in a big file which is in a separate file on
other architectures.
What are the rules for using shared generic IRQ API.. Write them down..
Automate checking them.. Present violations and fixes.
If any other implementations of PIC IRQ frameworks exist, we want to address
getting rid of them. There were predecessors of current code which may hang
around.
After that, SPARC has an implementation of shared IRQ PIC code for A SINGLE
simple vectored architecture. That needs to be available for all simple
vectored targets. It is a layer on top .. That is on.
If the Gaisler code patches have additional functionality in this area, it
could be merged. But in a way that let's all targets use it.
Vipul Nayyar<[email protected]> <mailto:[email protected]> wrote:
Hello
As part of my GSOC Project, I'll be implementing the PIC API on
simple vectored architecture as a first step. I had hoped that I
would've been a bit ahead as of now, but I'm kinda stuck in the basic
stuff for now. Some points which I'm having trouble figuring out is :
1) Which is the latest Programmable Interrupt Controller API that
needs to be implemented, and where does it lie in the RTEMS code base ?
2) How to identify which are simple vectored architectures ?
3) Architectures like arm, i386, powerpc etc. which implement the
desired PIC API, do not seem to have common code. I'm having trouble
identifying which part of code is architecture dependent and which is
common among different architectures.
I'm currently going through the docs, especially the BSP How to
Guide, given in the docs online for previous few days, but I've
failed to grasp answers to the above questions. Thanks in advance for
helping and guiding me out.
Regards
Vipul Nayyar
--
Joel Sherrill, Ph.D. Director of Research & Development
[email protected] <mailto:[email protected]> On-Line
Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
--
Joel Sherrill, Ph.D. Director of Research & Development
[email protected] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
