Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Mar 12, 2022
  3. Nov 30, 2021
  5. Oct 17, 2021
  7. Oct 15, 2021
  9. Oct 14, 2021
  11. Oct 10, 2021
  13. Oct 09, 2021
  15. Sep 20, 2021
  17. Aug 13, 2021
  19. Aug 05, 2021
  21. Jul 31, 2021
  23. Jul 17, 2021
  25. Jul 14, 2021
  27. Jun 14, 2021
  29. Jun 11, 2021
  31. Jun 10, 2021
  33. Apr 20, 2021
    • Douglas Anderson's avatar
      drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare · 3235b0f2
      Douglas Anderson authored 
      
Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms before the panel will assert HPD
(AKA "panel ready"). The above means that we should avoid turning a
panel off if we're going to turn it on again shortly.

The above becomes a problem when we want to read the EDID of a
panel. The way that ordering works is that userspace wants to read the
EDID of the panel _before_ fully enabling it so that it can set the
initial mode correctly. However, we can't read the EDID until we power
it up. This leads to code that does this dance (like
ps8640_bridge_get_edid()):

1. When userspace requests EDID / the panel modes (through an ioctl),
   we power on the panel just enough to read the EDID and then power
   it off.
2. Userspace then turns the panel on.

There's likely not much time between step #1 and #2 and so we want to
avoid powering the panel off and on again between those two steps.

Let's use Runtime PM to help us. We'll move the existing prepare() and
unprepare() to be runtime resume() and runtime suspend(). Now when we
want to prepare() or unprepare() we just increment or decrement the
refcount. We'll default to a 1 second autosuspend delay which seems
sane given the typical delays we see for panels.

A few notes:
- It seems the existing unprepare() and prepare() are defined to be
  no-ops if called extra times. We'll preserve that behavior but may
  try to remove it in a future patch.
- This is a slight change in the ABI of simple panel. If something was
  absolutely relying on the unprepare() to happen instantly that
  simply won't be the case anymore. I'm not aware of anyone relying on
  that behavior, but if there is someone then we'll need to figure out
  how to enable (or disable) this new delayed behavior selectively.
- In order for this to work we now have a hard dependency on
  "PM". From memory this is a legit thing to assume these days and we
  don't have to find some fallback to keep working if someone wants to
  build their system without "PM".

Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.7.I9e8bd33b49c496745bfac58ea9ab418bd3b6f5ce@changeid
      3235b0f2
  35. Dec 15, 2020
  37. Dec 07, 2020
  39. Nov 17, 2020
  41. Nov 14, 2020
  43. Oct 19, 2020
  45. Oct 15, 2020
  47. Sep 04, 2020
  49. Aug 18, 2020
  51. Jul 01, 2020
  53. May 07, 2020
  55. May 06, 2020
  57. Apr 08, 2020
  59. Mar 05, 2020
  61. Feb 29, 2020
  63. Jan 30, 2020
  65. Jan 17, 2020
  67. Jan 09, 2020

Open hardware computers for makers, educators and professionals