[tesla-dev] turnstiles block issue

[Li, Aubrey]

Dana.Myers wrote:

> Li, Aubrey wrote:
>> Dana.Myers wrote:
>> 
>> 
>>> Li, Aubrey wrote:
>>> 
>>>> Dana.Myers wrote:
>>>> 
>>>> 
>>>>> Let's take a step back here and think about what we really
>>>>> want to happen.
>>>>> 
>>>>> Cx is controlled using P_BLK registers, which are a per-CPU
>>>>> hardware resource; is it correct to assume that manipulation of
>>>>> a P_BLK is always done on the corresponding CPU?  Another way of
>>>>> stating this - is it correct to assume that a P_BLK is never
>>>>> manipulated by another CPU? 
>>>>> 
>>>> No, we are not talking about P_BLK, we are talking about BM_STS in
>>>> PM1 Status Registers, which is not a per-CPU hardware resource,
>>>> and BM_RLD as well. 
>>>> 
>>>> 
>>> Ah, well.  Something seems wrong with a thread holding a machine
>>> global lock on machine global resources on a CPU that's not
>>> executing - while other CPUs may contend for that same lock.  Help
>>> me understand the use-case and why this isn't bad.
>>> 
>> 
>> The problem is, currently we are using adaptive mutex for this global
>> lock, and we are in idle thread. So one cpu hold this lock, and
>> another cpu has to wait. We can keep spinning here, and we also can
>> put this cpu's thread to sleep. Here, we are not spinning here, we
>> are trying to put this thread to sleep. But, this is idle thread, it
>> can't be put to sleep. 
>> 
> Do I understand correctly that one CPU holds the hardware global lock
> and then halts in a C2/C3 state?
> 
> Dana


No, no, no.
Let me write a piece of pseudo code.

1. acquire a global lock
2. read BM_STS
3. release the global lock
4. depending on the value of BM_STS to determine the next idle type
5. read P_LVLx/_CST to halt CPU. (put CPU to halt in C2/C3)

Hope this is more clear.

Thanks,
-Aubrey