According to Kanoj Sarcar ...
>
> >
> > Hi,
> > The final word on TS ....
> >
> > > It says that this bit is set when tlb is "presented" with an entry
> > > that is already present and may cause multiple matches. It also
> > > goes on to say those conflicting entries are invalidated before the
> > > new entry is inserted. What we dont know is whether TS is sticky.
> > > We dont know whether it gets cleared after the the r10k 'fixes'
> > > everything.
> >
> > In case you still have this TS question....
> > The R10K "fixes" the other matching entries during the same write operation
> > which caused them. Afterwards the TS bit stays set.
>
> That was my understanding from the above statement taken out of the manual.
> Lets your page fault handler be sloppy, ie not need to do a tlbp, then a
> tlb dropin, when you are updating the tlb entry. Or may be high performance,
> since you can avoid doing tlbp.
>
> So, I don't have any questions on the TS getting set on entry into the
> kernel, if you are saying that the PROM fault handlers are getting it set.
There is no fault handler in the PROM. The PROM drops in a few tlb entries
for the mapped prom. I dont know if TS is set on entry from the PROM.
>
> > If you later do another TLB write which doesn't match any other entry, the
> > TS
> > bit will be cleared.
>
> This is new to me. One wonders why the hardware guys exposed the bit at all,
You mean news? This is typical of MIPS hardware. They do something only
when it is necessary. This is a debug tool or a status indicator and
can be used to fix sloppy fault handlers. The hw still does what one
would 'expect' it to do in addition to showing status.
Srinivasa
> since other than detecting a sloppy fault handler, I can't see any reason
> for software using it.
>
> Kanoj
>
> >
> > Thanks
> > srinivasa
> >
>
|