1. 08 Apr, 2024 2 commits
    • Douglas Anderson's avatar
      drm/panel-edp: If we fail to powerup/get EDID, use conservative timings · ce0ff223
      Douglas Anderson authored
      If at boot we fail to power up the eDP panel (most often happens if
      the eDP panel never asserts HPD to us) or if we are unable to read the
      EDID at bootup to figure out the panel's ID then let's use the
      conservative eDP panel powerup/powerdown timings but _not_ fail the
      probe.
      
      It might seem strange to _not_ fail the probe in this case since we
      were unable to powerup the panel and confirm it's there. However,
      there is a reason to do this. Specifically, if we fail to probe the
      panel then it really throws the whole display pipeline for loop. Most
      DRM subsystems are written so that they wait until all components
      (including the panel) have probed before they set everything up. When
      the panel doesn't come up then this never happens. As a side effect of
      not setting everything up then other display adapters don't get
      initialized. As a practical example, I can see that if I open up a
      sc7180-trogdor based Chromebook that's using the generic "edp-panel"
      and unplug the eDP panel that it causes the _external_ DP monitor not
      to function. This is obviously bad because it means that a device with
      a dead eDP panel becomes e-waste when it could instead still be given
      useful life with an external display.
      
      NOTES:
      - When we fail to probe like this, boot is a bit slow because we try
        several times to power the panel up. This doesn't feel horrible
        because it'll eventually work and the retries are known to help
        bring some panels up.
      - In the case where we hit the condition of failing to power up, the
        display will likely _never_ have a chance to work again until
        reboot. Once the panel-edp pm_runtime resume function fails it
        doesn't ever seem to retry. This is probably for the best given that
        we don't have any real timing/modes. eDP isn't expected to be
        "hotplugged" so this makes some sense.
      - It turns out that this makes panel-edp behave more similarly for
        users of the generic "edp-panel" compatible string and the old fixed
        panel compatible string. With the old fixed panel compatible string
        we don't talk to the panel during probe so we'd actually behave much
        the same way that we'll now behave for the generic "edp-panel".
      Reviewed-by: default avatarHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.2.Ia7a55a9657b0b6aa4644fd497a0bc595a771258c@changeid
      ce0ff223
    • Douglas Anderson's avatar
      drm/panel-edp: Abstract out function to set conservative timings · 2cbee8ae
      Douglas Anderson authored
      If we're using the generic "edp-panel" compatible string and we fail
      to detect an eDP panel then we fall back to conservative timings for
      powering up and powering down the panel. Abstract out the function for
      setting these timings so it can be used in future patches.
      
      No functional change expected--just code movement.
      Reviewed-by: default avatarHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.1.I659b2517d9f619d09e804e071591ecab76335dfb@changeid
      2cbee8ae
  2. 05 Apr, 2024 5 commits
  3. 04 Apr, 2024 2 commits
  4. 03 Apr, 2024 7 commits
  5. 02 Apr, 2024 18 commits
  6. 31 Mar, 2024 6 commits