On October 23, 2014 6:38:27 AM PDT, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: >On 23/10/14 15:16, Joel Sherrill wrote: >> >> >> On October 23, 2014 1:52:47 AM PDT, Sebastian Huber ><sebastian.hu...@embedded-brains.de> wrote: >>> On 21/10/14 04:56, Gedare Bloom wrote: >>>> On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault<dufa...@hda.com> >>> wrote: >>>>>> >>>>>>>> On Oct 20, 2014, at 16:47 , Joel >>> Sherrill<joel.sherr...@oarcorp.com> wrote: >>>>>>>> >>>>>>>>>> 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. >>>>>>>> >>>>>> >>>>>> I'm flat-out, I can't do a proper job on this. I couldn't have >>> told you that the MPC55XX had a unified cache before I checked this >>> morning, but I would have gotten the answer correct on a >>> multiple-choice question. >>>>>> >>>>>> I think that unimplemented operations should return errors and >not >>> OK, forcing one to add an implementation when it is OK. But the >>> MPC55XX and its cache works fine as long as you keep cache-flushing >in >>> mind and flush it when you should, so I don't recommend anything be >>> changed in the next RTEMS release. >>>>>> >>>> +1 >>>> What we should do is make sure any generic cache mgr functions that >>>> get called within RTEMS are all implemented (I recall there being >>>> some, they may be in score/cpu code though.) Then make the >>>> unimplemented calls be errors. If someone uses it without checking, >>>> they should get slapped for it. >>> >>> What do you mean with "return errors"? Should this be a fatal error >or >>> a >>> linker error? >> >> Let's take the simplest case. A CPU with no cache control. Empty >stubs is the right implementation. >> >> Next up is just enable, disable and flush. Can we map those to more >specialized methods. Is it ok and expected that disable data cache does >all? Or flush flushes all. > >What is the use case for a cache disable/enable at application level? >Most >cache disable functions in the tree are broken. > >The only useful cache manager functions I see is data cache >flush/invalidate >lines and instruction cache invalidate lines.
Personally I don't see enable and disable used besides during BSP initialization. Maybe disable when app starts if having trouble with a user provided driver. But much beyond that >> >> My thinking is that there are probably tiers of cache capabilities >and if we can define expected behavior of higher tier operations onto >lower capability CPU models, then we have a good solution. >> >> I don't like any errors in this case because as Peter says the code >works well enough for applications as is if it is being used. Injecting >a fatal error would be breakage. Returning an error would (I think) >take an API change which no code would look at. >> >> >> _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
