On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
a small spike on the HPD line right when you power the panel on.  The
picture looks something like this:

         +--------------------------------------
         |
         |
         |
Power ---+
                                           +---
                                           |
              ++                           |
         +----+|                           |
HPD -----+     +---------------------------+

So right when power is applied there's a little bump in HPD and then
there's small spike right before it goes low.  The total time of the
little bump plus the spike was measured on one panel as being 8 ms
long.  The total time for the HPD to go high on the same panel was
51.2 ms, though the datasheet only promises it is < 200 ms.

When asked about this glitch, BOE indicated that it was expected and
persisted until the TCON has been initialized.

If this was a real hotpluggable DP panel then this wouldn't matter a
whole lot.  We'd debounce the HPD signal for a really long time and so
the little blip wouldn't hurt.  However, this is not a hotpluggable DP
panel and the the debouncing logic isn't needed and just shows down
the time needed to get the display working.  This is why the code in
panel_simple_prepare() doesn't do debouncing and just waits for HPD to
go high once.  Unfortunately if we get unlucky and happen to poll the
HPD line right at the spike we can try talking to the panel before
it's ready.

Let's handle this situation by putting in a 15 ms prepare delay and
decreasing the "hpd absent delay" by 15 ms.  That means:
* If you don't have HPD hooked up at all you've still got the
  hardcoded 200 ms delay.
* If you've got HPD hooked up you will always wait at least 15 ms
  before checking HPD.  The only case where this could be bad is if
  the panel is sharing a voltage rail with something else in the
  system and was already turned on long before the panel came up.  In
  such a case we'll be delaying 15 ms for no reason, but it's not a
  huge delay and I don't see any other good solution to handle that
  case.

Even though the delay was measured as 8 ms, 15 ms was chosen to give a
bit of margin.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716132120.1.I01e738cd469b61fc9b28b3ef1c6541a4f48b11bf@changeid