commit d02eee49be53ea07bd358278fcf4a106f29fdd78
author John Grossman <johngro@google.com> Mon Apr 12 18:01:57 2021 +0000
committer CQ Bot <commit-bot@chromium.org> Mon Apr 12 18:01:57 2021 +0000
tree 04602f14ee43d3631ce154640da0d2e3f1660cb3
parent 6f0c9adf7662023cc5b1a8cece95f75638abb89b

[vdec1] Work around an issue with the power on sequence.

Change the position where we release the clock gating during a power
up sequence in order to work around a limited number of devices in the
field which lock up if we don't.

Note that the previous sequence seemed to work for most devices.
However, we found at least one developer box (and have evidence of a
few more production boxes in the field) for which the sequence does
not work.  Specifically, after releasing the DOS unit from isolation,
the RMW to the MdecPicDcCtrl would cause the entire system to lock up,
eventually causing the HW WDT to fire.

There are really no docs from AML (that we have access to at least)
which specify the power up sequence or requirements here, however.
There are a few different driver implementations out there in the open
source world, however their sequences are inconsistent, and it is not
clear who to trust.

The best theory we have so far is that, if the clocks no present when
the VDEC/DOS unit powers up and is reset, that it is possible that
there may be clock synchronizers which don't actually end up getting
synchronized, and that later on, when we touch the MdecPicDcCtrl
register, it results in a lockup.

So, in the absence of any guidance from AML, move the un-gating of the
clocks up in the power on sequence.  Make sure that they are present
before we power the unit on, and then reset it.  This has been passing
overnight stress testing on the "bad" box, where it used to fail on
the first attempt to power down and then power back up again.

Test: See above.  Manual stress testing on the special "bad" hardware.
Bug: 70724
Change-Id: I8df0b90457bf1cde82420641c9145850b86bf90d
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/513642
Reviewed-by: Dustin Green <dustingreen@google.com>
Reviewed-by: Eric Holland <hollande@google.com>
Reviewed-by: John Bauman <jbauman@google.com>
Commit-Queue: John Grossman <johngro@google.com>