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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
