On October 20, 2014 3:41:06 PM CDT, Peter Dufault <dufa...@hda.com> wrote: > >> On Oct 20, 2014, at 13:20 , Joel Sherrill <joel.sherr...@oarcorp.com> >wrote: >> >> >> On 10/20/2014 12:09 PM, Gedare Bloom wrote: >>> Cache manager implementations are a perennial open project. >> +1 >> >> In this case,we only have ten RTEMS_CPU_MODELs which are not >> addressed. There are currently two blocks of code in the file. One >> is protected by this: >> >> #if defined(ppc603) || defined(ppc603e) || defined(mpc8260) >> >> And the other by this: >> >> #elif ( defined(mpx8xx) || defined(mpc860) || defined(mpc821) ) >> >> My guess with no research is that the first block of code is also >> appropriate for these RTEMS_CPU_MODELs: >> >> e500 >> mpc604 >> mpc7400 mpc7455 mpc750 >> qoriq >> mpc55xx >> >> A quick google makes me pretty confident that the mpc690 and mpc7* >models >> belong in the ppc603 HID0 block. >> >> I do not have a guess about these >> >> ppc405 ppc440 mpc555 >> >> If we have to implement code to support something new, then I don't >want >> to do it. If we have the code and just need to check to see if more >needs to >> be added to the conditional, then we should. >> >> --joel >> > >I'm not sure. I looked at this briefly today. The MPC55XX has a >unified cache, a lot of the unimplemented entry points had to to do >with operations specifically on either the instruction or data cache. >I agree you could implement a unified method where accessing either >would affect the other, but I also agree with Sebastian that I'm not >sure it matters if someone is trying to use one of those for good >reason. > >However, should unimplemented versions return an error instead of being >a NOP? That would force one to visit code that makes assumptions.
If this is OK for the mpc55xx, feel free to submit a patch turning the warning off for it. I tend to agree that if I had a generic drive that wanted to flush data cache and all we can do on a target is flush all, then that's preferable to flushing nothing. If these are called from a cache test then we would end up with a hard error instead of a warning in that test which makes the issue worse. >Peter >----------------- >Peter Dufault >HD Associates, Inc. Software and System Engineering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
