CPM command processing

[Till Straumann]

Leon Pollak wrote:
> On Monday, 14 בJanuary 2008, Till Straumann wrote:
>   
>> My usual 2-cents:
>>
>> Busy-waiting with interrupts disabled is evil.
>> Such a loop *must* IMHO implement a timeout
>> so that the worst-case impact on latency other
>> tasks have to suffer from is guaranteed.
>>     
> Well, if everything works,
The problem is that if for some reason it doesn't and
it takes longer then there is no safeguard.
>  there should be not more then 20 cycles, thus any 
> timeout technique will take more time.
>   
I disagree. Since you're busy-waiting you can
as well read e.g. some hardware timer
(or at least a loop count).

then = read_hw_timer();
while (m8260.cpcr & M8260_CR_FLG) {
  if ( read_hw_timer() - then > timeout ) {
    rtems_interrupt_enable(lvl);
    /* TIMEOUT; deal with it here */
  }

}

> If there is the problem I mentioned, then I do not know what to do, actually.
> And we do HW reset, which always helps...
> May be there is some method to overcome/recover from the situation...
>
>   
>> -- Till
>>
>> Leon Pollak wrote:
>>     
>>> Hello, all.
>>>
>>> Both files
>>> ..lib/libcpu/powerpc/mpc8260/cp.c
>>> ..lib/libcpu/powerpc/mpc860/cp.c
>>> contain the same code:
>>>
>>> void m8xx_cp_execute_cmd( uint32_t   command )
>>> {
>>>   uint16_t   lvl;
>>>
>>>   rtems_interrupt_disable(lvl);
>>>   while (m8260.cpcr & M8260_CR_FLG) {
>>>     continue;
>>>   }
>>>
>>>   m8260.cpcr = command | M8260_CR_FLG;
>>>   rtems_interrupt_enable (lvl);
>>> }
>>>
>>> The problem with this code is (based on my experience with both CPU's)
>>> that it does not check the result of a command execution. Although
>>> Motorola's specification states that CPM should finish the command
>>> processing in about 20 cycles, my 13 years experience shows that there
>>> are cases when the command is not executed and the flag bit remains "1".
>>>
>>> Therefore, I swap the operators in my code:
>>>
>>>   m8260.cpcr = command | M8260_CR_FLG;
>>>
>>>   while (m8260.cpcr & M8260_CR_FLG) {
>>>     continue;
>>>   }
>>>
>>> and cause system reset if it remains "1" for too long.
>>>
>>> I have no explanation to this, because after reset the system returns to
>>> the same exactly sequence and now it passes. We have such problem once on
>>> each 20-25 units based on MPC8260, but I remember this to occur on MPC860
>>> units too.
>>>
>>> Hope this will be useful...
>>>       
>
>
>
>