[Cbe-oss-dev] [PATCH] spufs: Avoid restarting MFC in context saving

Kazunori Asayama asayama at sm.sony.co.jp
Tue Jul 3 20:36:26 EST 2007


Jeremy Kerr <jk at ozlabs.org> wrote:
> Asayama-san,
> 
> > I think that you misunderstand the meaning of Sc bit (and Sm
> > bit).
> 
> Quite possibly :)
> 
> I had the bit values of Sm reversed. So your patch is disabling the 
> effect of the Sc bit. Doesn't this mean that with your patch, when we 
> later try to suspend the MFC queue in suspend_mfc(), nothing will 
> happen?

When saving context, save_mfc_cntl is called to suspend MFC. The
suspend_mfc is used to restore context (and isolation mode support).
So the DMA has already been suspended when halt_mfc_decr is called,
and we must use Sm bit in halt_mfc_decr in order to keep that status.

> 
> (Still, I think this should be kept separate from our use of the Dh bit, 
> and so done somewhere other than halt_decr())
> 
> > Writing "Sc == 0" does *NOT* mean "Suspend MFC command queue 
> > operation is not requested", but means "Request normal MFC command
> > queue operation".
> 
> Yep. From reading the doc:
> 
>   MFC suspended = ~Sm & Sc

    ~Sm &  Sc       any state -> suspended
    ~Sm & ~Sc       any state -> normal
     Sm             stay in previous state

> 
> So why don't we just leave Sm at 0, and alter Sc when we need to 
> suspend? If your patch fixes the bug, doesn't that make the CBEA doc 
> wrong?

The CBEA doc says:

     MFC_CNTL[Sm] should be written as a ‘1’ value when the MFC
     Control Register is written with no intent to change the current
     MFC operation state (suspended or normal).

> 
> > Yes, I have. I'll submit it to this ML later.
> 
> Great, thanks.

--
(ASAYAMA Kazunori
  (asayama at sm.sony.co.jp))
t



More information about the cbe-oss-dev mailing list