[PATCH 7/7] bsps/sparc: Add prototype for rtems_bsp_delay.

Joel Sherrill joel.sherrill at OARcorp.com
Thu Mar 13 17:27:17 UTC 2014


On 3/13/2014 10:26 AM, Joel Sherrill wrote:
> On 3/13/2014 9:59 AM, Sebastian Huber wrote:
>> On 2014-03-13 15:53, Joel Sherrill wrote:
>>> This is the best way to remove the warnings.
>>>
>>> Longer term, we should address rtems_bsp_delay() as a
>>> generic BSP interface or provide it in a more uniform way.
>> We already have this:
>>
>> http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__ClassicCounter.html
>>
>> The proper way is to get rid of this rtems_bsp_delay() entirely.
>>
> Where does this work now?
>
> + All SPARC BSPs?
> + All PowerPC BSPs?
> + pc386?
> + which ARMs?
> + other?
>
> My grep shows that if a few NIC drivers are fixed, there do not appear to
> be many uses in non-BSP specific code. There is powerpc-utility.h in libcpu
> which needs to be looked at.  And there is a related
> rtems_bsp_delay_in_bus_cycles which is used in some PowerPC BSPs.
>
> My point is that there are currently a few uses outside BSPs which need to
> be addressed before this can be eliminated. Since some of the uses are
> NICs which have conditionals on PPC and x86, having counter work there
> would be sufficient I think to change them.
>
> Beyond that, it would be a per-BSP issue that is quick to eliminate I think.
>
Hmm.. Wait_X_MS() in the pc386 BSP is another variant. :(

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




More information about the devel mailing list