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

Sebastian Huber sebastian.huber at embedded-brains.de
Fri Mar 14 07:30:57 UTC 2014


On 2014-03-13 16:26, 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?

erc32, leon3 (leon2 not, since I have no way to test it).

> + All PowerPC BSPs?

Yes.

> + pc386?

No.

> + which ARMs?

LPC24XX, LPC32XX, Xilinx, Altera, Realview.

> + other?

No.

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

We just need someone how has the time to do it.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list