1. 02 Nov, 2018 2 commits
  2. 01 Nov, 2018 6 commits
  3. 30 Oct, 2018 2 commits
  4. 29 Oct, 2018 7 commits
    • Douglas Anderson's avatar
      drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 · 8f054b6f
      Douglas Anderson authored
      As far as I can tell the panel that was added in commit da50bd42
      ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
      wasn't actually an Innolux TV123WAM but was actually an Innolux
      P120ZDG-BF1.
      
      As far as I can tell the Innolux TV123WAM isn't a real panel and but
      it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
      Let's unmosh.
      
      Here's my evidence:
      
      * Searching for TV123WAM on the Internet turns up a TI panel.  While
        it's possible that an Innolux panel has the same model number as the
        TI Panel, it seems a little doubtful.  Looking up the datasheet from
        the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
      
      * As far as I know, the patch adding the Innolux Panel was supposed to
        be for the board that's sitting in front of me as I type this
        (support for that board is not yet upstream).  On the back of that
        panel I see Innolux P120ZDZ-EZ1 rev B1.
      
      * Someone pointed me at a datasheet that's supposed to be for the
        panel in front of me (sorry, I can't share the datasheet).  That
        datasheet has the string "p120zdg-bf1"
      
      * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
        that are 2160x1440.  They don't have datasheets, but the fact that
        the resolution matches is a good sign.
      
      In any case, let's update the name and also the physical size to match
      the correct panel.
      
      Fixes: da50bd42 ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
      Cc: Sandeep Panda <spanda@codeaurora.org>
      Reviewed-by: default avatarAbhinav Kumar <abhinavk@codeaurora.org>
      Reviewed-by: default avatarSean Paul <sean@poorly.run>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-6-dianders@chromium.org
      8f054b6f
    • Douglas Anderson's avatar
      dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 · c0e9ab24
      Douglas Anderson authored
      As far as I can tell the bindings that were added in commit
      9c04400f ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
      bindings") weren't actually for Innolux TV123WAM but were actually for
      Innolux P120ZDG-BF1.
      
      As far as I can tell the Innolux TV123WAM isn't a real panel and but
      it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
      Let's unmosh.
      
      Here's my evidence:
      
      * Searching for TV123WAM on the Internet turns up a TI panel.  While
        it's possible that an Innolux panel has the same model number as the
        TI Panel, it seems a little doubtful.  Looking up the datasheet from
        the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
      
      * As far as I know, the patch adding the Innolux Panel was supposed to
        be for the board that's sitting in front of me as I type this
        (support for that board is not yet upstream).  On the back of that
        panel I see Innolux P120ZDZ-EZ1 rev B1.
      
      * Someone pointed me at a datasheet that's supposed to be for the
        panel in front of me (sorry, I can't share the datasheet).  That
        datasheet has the string "p120zdg-bf1"
      
      * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
        that are 2160x1440.  They don't have datasheets, but the fact that
        the resolution matches is a good sign.
      
      While we doing the rename, also mention that no-hpd can be used with
      this panel.  See the previous patch in this series ("drm/panel:
      simple: Add "no-hpd" delay for Innolux TV123WAM").
      
      Fixes: 9c04400f ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings")
      Cc: Sandeep Panda <spanda@codeaurora.org>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-5-dianders@chromium.org
      c0e9ab24
    • Douglas Anderson's avatar
      drm/bridge: ti-sn65dsi86: Remove the mystery delay · c2bfc223
      Douglas Anderson authored
      Let's solve the mystery of commit bf1178c9 ("drm/bridge:
      ti-sn65dsi86: Add mystery delay to enable()").  Specifically the
      reason we needed that mystery delay is that we weren't paying
      attention to HPD.
      
      Looking at the datasheet for the same panel that was tested for the
      original commit, I see there's a timing "t3" that times from power on
      to the aux channel being operational.  This time is specced as 0 - 200
      ms.  The datasheet says that the aux channel is operational at exactly
      the same time that HPD is asserted.
      
      Scoping the signals on this board showed that HPD was asserted 84 ms
      after power was asserted.  That very closely matches the magic 70 ms
      delay that we had.  ...and actually, in my testing the 70 ms wasn't
      quite enough of a delay and some percentage of the time the display
      didn't come up until I bumped it to 100 ms (presumably 84 ms would
      have worked too).
      
      To solve this, we tried to hook up the HPD signal in the bridge.
      ...but in doing so we found that that the bridge didn't report that
      HPD was asserted until ~280 ms after we powered it (!).  This is
      explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
      (Hot Plug/Unplug Detection)".  Reading there we see that the bridge
      isn't even intended to report HPD until 100 ms after it's asserted.
      ...but that would have left us at 184 ms.  The extra 100 ms
      (presumably) comes from this part in the datasheet:
      
      > The HPD state machine operates off an internal ring oscillator. The
      > ring oscillator frequency will vary [ ... ]. The min/max range in
      > the HPD State Diagram refers to the possible times based off
      > variation in the ring oscillator frequency.
      
      Given that the 280 ms we'll end up delaying if we hook up HPD is
      _slower_ than the 200 ms we could just hardcode, for now we'll solve
      the problem by just hardcoding a 200 ms delay in the panel driver
      using the patch in this series ("drm/panel: simple: Support panels
      with HPD where HPD isn't connected").
      
      If we later find a panel that needs to use this bridge where we need
      HPD then we'll have to come up with some new code to handle it.  Given
      the silly debouncing in the bridge chip, though, it seems unlikely.
      
      One last note is that I tried to solve this through another way: In
      ti_sn_bridge_enable() I tried to use various combinations of
      dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
      was up.  In theory that would let me detect _exactly_ when I could
      continue and do link training.  Unfortunately even if I did an aux
      transfer w/out waiting I couldn't see any errors.  Possibly I could
      keep looping over link training until it came back with success, but
      that seemed a little overly hacky to me.
      Reviewed-by: default avatarSean Paul <sean@poorly.run>
      Reviewed-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-4-dianders@chromium.org
      c2bfc223
    • Douglas Anderson's avatar
      drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM · 625d3b5c
      Douglas Anderson authored
      If the HPD signal isn't hooked up to this panel we need a 200 ms
      delay.  In the datasheet this is shown as the maximum time that HPD
      will take to be asserted after power is given to the panel.
      Reviewed-by: default avatarSean Paul <sean@poorly.run>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-3-dianders@chromium.org
      625d3b5c
    • Douglas Anderson's avatar
      drm/panel: simple: Support panels with HPD where HPD isn't connected · 2ed3e951
      Douglas Anderson authored
      Some eDP panels that are designed to be always connected to a board
      use their HPD signal to signal that they've finished powering on and
      they're ready to be talked to.
      
      However, for various reasons it's possible that the HPD signal from
      the panel isn't actually hooked up.  In the case where the HPD isn't
      hooked up you can look at the timing diagram on the panel datasheet
      and insert a delay for the maximum amount of time that the HPD might
      take to come up.
      
      Let's add support in simple-panel for this concept.
      
      At the moment we will co-opt the existing "prepare" delay to keep
      track of the delay and we'll use a boolean to specify that a given
      panel should only apply the delay if the "no-hpd" property was
      specified.
      Reviewed-by: default avatarSean Paul <sean@poorly.run>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-2-dianders@chromium.org
      2ed3e951
    • Douglas Anderson's avatar
      dt-bindings: drm/panel: simple: Add no-hpd property · cb028e49
      Douglas Anderson authored
      Some eDP panels that are designed to be always connected to a board
      use their HPD signal to signal that they've finished powering on and
      they're ready to be talked to.
      
      However, for various reasons it's possible that the HPD signal from
      the panel isn't actually hooked up.  In the case where the HPD isn't
      hooked up you can look at the timing diagram on the panel datasheet
      and insert a delay for the maximum amount of time that the HPD might
      take to come up.
      
      Let's add a property in the device tree for this concept.
      Reviewed-by: default avatarSean Paul <sean@poorly.run>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-1-dianders@chromium.org
      cb028e49
    • Lee, Shawn C's avatar
      drm/edid: Add 6 bpc quirk for BOE panel. · 922dceff
      Lee, Shawn C authored
      BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
      But it's 6bpc panel only instead of 8 bpc.
      
      Add panel ID to edid quirk list and set 6 bpc as default to
      work around this issue.
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Cooper Chiou <cooper.chiou@intel.com>
      Signed-off-by: default avatarLee, Shawn C <shawn.c.lee@intel.com&gt;>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c.lee@intel.com
      922dceff
  5. 26 Oct, 2018 3 commits
  6. 25 Oct, 2018 7 commits
  7. 22 Oct, 2018 6 commits
  8. 19 Oct, 2018 1 commit
  9. 18 Oct, 2018 6 commits