On Thu, Mar 07, 2013 at 11:59:25AM +0000, Leo Yan wrote: > Very appreciate the detailed answers. i'd like to discuss further more > for the questions, so pls see below comments. > > On 03/07/2013 03:15 PM, Lorenzo Pieralisi wrote: > >> > >> 1. When the program calls the function *v7_coherent_kern_range*, it will > >> firstly read the cache type register (CTR) to get the icache line size > >> is 64 bytes, and then it will run into the loop to flush every icache > >> line with 64 bytes per step; if in the middle of this loop, the program > >> is migrated onto A7, then on A7 it will continue to flush the icache > >> with 64 bytes per step, but A7 will ONLY invalidate the first half 32 > >> bytes of the cache line. So finally there have the possibility for the > >> icache corruption issues. > >> > >> 2. When A15 and A7 cores run at the meantime; when the A15 core execute > >> the instruction ICIMAVU then it will invalidate the i cache with 64 > >> bytes and it will also send DVM to A7 cores to invalidate the icache as > >> well; but A7 will ONLY invalidate 32 bytes. If so, then that means this > >> is an architecture issue, and we must force A15's icache line to be 32 > >> bytes for big.LITTLE from the silicon's level. > >> > >> So could u help confirm, these two scenarios both will introduce the > >> icache corruption, right? If i miss something, pls feel free point out. > > > > IMINLN provides just the stride to the cache functions. So short answer both > > (1) and (2) are wrong. > > > > (1) is wrong since on A7 I-cache size is 32 bytes, so the first-half you are > > mentioning is an incorrect way to put it. The problem is that the MVA > > passed will be 64bytes aligned and the stride is 64 bytes, which means > > that, if run on a core with 32 bytes I-cache line, one line in two is not > > invalidated, but that's because the address passed is incremented by 64 > > bytes at a time, remember, the only thing that matters is the MVA you > > are passing, not the stride itself. > > (2) is just a wrong understanding of how things work, you are invalidating > > by > > MVA, so the MVA determines what the DVM is doing, not the cache line size. > > I'm curious if A15 use the MVA to invalidate icache, then will the DVM > contain the info of MVA and the range size? If it's ONLY include the > MVA, then A7 how to know it need invalidate 64 bytes' range so that > cannot coordinate with A15.
A7 cannot know that, since the operation sent over CCI is all about invalidating an MVA, the operation sent through CCI does not contain a line size with it. This is the reason why IMINLN has to be set up according to the A15 TRM for things to function properly on bL systems (A15 TRM 6.3.6). > >> Here i have another question is for the instruction *ICIALLUIS*; when > >> the core invalidates all icache, actually it's to use the set/way method > >> to invalidate the icache line and send DVM to message other inner share > >> domain's cores. > > > > ICIALLUIS does not use set/way operations. > > Here i may made mistake. before i thought *ICIALLUIS* is a pesudo > instruction, the logic will use the set/way operations to invalidate the > core's icache line one by one. So how ICIALLUIS can invalidate the > totally core self icache lines? Do you mean in RTL :-) ? It is a HW operation, the processor logic will certainly figure that out. > >> If so, that means the core will invalidate the it selves icache and send > >> the DVM to other cores to invalidate icache line if they have the same > >> icache line. But after ICIALLUIS is executed, other cores still may have > >> valid icache lines, right? No, it is a broadcast operation all I-caches in the IS domain are invalidated. > > > > That's not correct. I will check what happens at bus level, but I guess > > the Invalidate All Inner shareable will be a single coherency command > > sent over CCI. > > If so, it's make sense other inner share cores will invalidate all their > icaches after receive the single command. Correct. > > > > Cache line size is just used as stride to for the cache function to be > > optimized. > > > > BTW, A15 TRM 6.3.6 explains what I tried to summarize above. > > Thx for nicely reminding, i think i need read well A7/A15's TRM. You are welcome, Lorenzo _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
