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

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

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:
> > I don't know what the BWB unit is, I guess W is for write and one of the
> > Bs is for burst. All I know is that there repeatedly have been issues
> > with it hanging on certain streams (ENGR00223231, ENGR00293425), with
> > various firmware versions, sometimes blocking something related to the
> > GDI bus or the GDI AXI adapter. There are some error cases that we don't
> > know how to recover from without a reboot. Apparently this unit can be
> > disabled by setting bit 12 in the FRAME_MEM_CTRL mailbox register to
> > zero, so do that to avoid crashes.
> 
> Both those FSL ENGR patches to Android and VPU lib are specific to 
> decode, with the first being specific to VC1 decode only.

The first one is older, I suppose VC1 is where the issue has been
observed first.
I have seen sporadic BWB hangups when decoding h.264 RTP streams.

> > 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.

> It might also be worth adding some sort of /* HACK */ marker, since 
> disabling the BWB feels very like a hack to me.

I don't think HACK in itself is very descriptive, but a reference to the
original workaround could be helpful in the future.

regards
Philipp