Re: [PATCH] [media] coda: disable BWB for all codecs on CODA 960

[Philipp Zabel <p.zabel@pengutronix.de>]

On Wed, 2017-07-19 at 10:15 +0100, Ian Arkver wrote:
> On 19/07/17 09:09, Philipp Zabel wrote:
> > Hi Ian,
> > 
> > On Wed, 2017-07-19 at 08:16 +0100, Ian Arkver wrote:
> >> Hi Philipp,
> >>
> >> On 02/03/17 10:19, Philipp Zabel wrote:
> >>> Side effects are reduced burst lengths when writing out decoded frames
> >>> to memory, so there is an "enable_bwb" module parameter to turn it back
> >>> on.
> >>
> >> These side effects are dramatically reducing the VPU throughput during
> >> H.264 encode as well. Prior to this patch I was just about managing to
> >> capture and stream 1080p25 H.264. After this change it fell to about
> >> 19fps. Reverting this patch (or presumably using the module param)
> >> restores the frame rate.
> >>
> >> Can we at least make this decode specific? The VPU library patches do it
> >> in vpu_DecOpen. I'd guess disabling the BWB any time prior to stream
> >> start would be OK.
> > 
> > Yes, since ENGR00293425 only talks about decoders, and I haven't seen
> > any BWB related hangups during encoding yet, I'm inclined to agree.
> 
> I took a look at where ctx->frame_mem_ctrl is used, i.e.
> coda_start_encoding and __coda_start_decoding. Is it possible to have
> one instance of coda open for encode and one for decode at the same
> time? 

Sure, when transcoding with a decoder / encoder pair, for example.

> If so, how is the CODA_REG_BIT_FRAME_MEM_CTRL setting
> updated between runs, eg. for differing CODA_FRAME_CHROMA_INTERLEAVE?

Yes. coda_command_async writes ctx->frame_mem_ctrl to
CODA_REG_BIT_FRAME_MEM_CTRL with each PIC_RUN command at from
prepare_encode/decode.

> This code is in the start_streaming path rather than the prepare_run
> path. Does each context switch stop & restart streaming?

No, see above.

regards
Philipp