Guidance required for PIC API

Sat Jun 15 18:29:59 UTC 2013

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 <joel.sherrill at oarcorp.com>
> *To:* rtems-devel at rtems.org; Vipul Nayyar <nayyar_vipul at yahoo.com>
> *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<nayyar_vipul at yahoo.com>  <mailto:nayyar_vipul at yahoo.com>  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
> joel.sherrill at OARcorp.com  <mailto:joel.sherrill at OARcorp.com>         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
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130615/349ad479/attachment-0001.html>