Hi Albert, On Monday 08 August 2011 03:09 PM, Albert ARIBAUD wrote: > Le 08/08/2011 10:24, Aneesh V a écrit : >> Hi Albert, >> >> On Sunday 07 August 2011 12:25 PM, Albert ARIBAUD wrote: >>> Hi Aneesh, >>> >>> (cutting quotation for readability) >>> >>> Le 05/08/2011 16:59, Aneesh V a écrit : >>>> Hi Albert, >>> >>>> I don't dispute that having buffers aligned is the ideal scenario. The >>>> question is about error-handling the situation when this requirement is >>>> not met. >>> >>> I understand what you're trying to achieve in this respect, that is, >>> make the code as correct as it can be under unspecified conditions. I >>> believe we are differing in how we construe 'as correct as it can be': >>> you want to make the implementation of the called function as correct as >>> it can be' at the expense of introducing a non-intuitive behavior (flush >>> while invalidating), while I prefer the overall system to be as correct >>> as it can be by 'doing exactly what it says on the tin', i.e. >>> invalidating only. >> >> I understand your point of view now. I shall update my cache fix series >> to invalidate only the aligned part of the buffer and to print a big >> warning when the buffer is not aligned. > > Thanks Aneesh. > > Another point I raised with Hong Xu's patch: for range-limited > operations, in case of a misalignment, why not try to *reduce* to > aligned addresses rather than *expand* it? Moving start up to the next > cache line boundary, and moving stop down, would still cause an > imperfect situation (can't help it anyway) but it would not affect third > party data any more, only the data which the cache range operation was > supposed to affect. > > What do you (and others) think?
I agree. Indeed this is what I meant when I wrote this above: "invalidate *only the aligned part* of the buffer" best regards, Aneesh _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
