[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