[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