[Cbe-oss-dev] [PATCH] libspe2 Fix signal type initialization

[D. Herrendoerfer]

It was reported in the cell Forum, that the Implementation does
the opposite of what the Documentation says, so we need to
fix the kernel documentation and the libspe implementation.

On Fri, 2007-09-21 at 11:39 +0900, Kazunori Asayama wrote:
> "D. Herrendoerfer" <d.herrendoerfer at herrendoerfer.name> wrote:
> > This fixes the signal type initialization.
> > It is currently wrongly set to OR signals, when it should be set
> > to OVERWRITE.
> > 
> > Signed-off-by: D. Herrendoerfer <herrendoerfer at herrendoerfer.name>
> > 
> > Ok to apply ?
> 
> No. I believe that the current implementation is correct.
> 
> The libspe2 spec says:
> 
>     SPE_CFG_SIGNOTIFY1_OR
> 
>         Configure the SPU Signal Notification 1 Register to be
>         in ″logical OR″ mode instead of the
>         default ″Overwrite″ mode.
> 
>     SPE_CFG_SIGNOTIFY2_OR
> 
>         Configure the SPU Signal Notification 2 Register to be
>         in ″logical OR″ mode instead of the
>         default ″Overwrite″ mode.
> 
> while the SPUFS spec says:
> 
>    /signal1_type
>    /signal2_type
>        These two files change the behavior of the signal1 and signal2  notifi-
>        cation  files.  The  contain  a numerical ASCII string which is read as
>        either "1" or "0".  In mode 0 (overwrite), the  hardware  replaces  the
>        contents of the signal channel with the data that is written to it.  in
>        mode 1 (logical OR), the hardware accumulates the bits that are  subse-
>        quently written to it.
> 
> And the setsignotify() is a function to set the value "1" to
> the signal1_type and/or signal2_type node.
> 
> So we should call the setsignotify() when SPE_CFG_SIGNOTIFY1_OR and/or
> SPE_CFG_SIGNOTIFY2_OR are specified.
> 
> --
> (ASAYAMA Kazunori
>   (asayama at sm.sony.co.jp))
> t