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.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
