1. 16 Jul, 2018 4 commits
    • Lyude Paul's avatar
      drm/dp_helper: Add DP aux channel tracing · a18b2192
      Lyude Paul authored
      This is something we've needed for a very long time now, as it makes
      debugging issues with faulty MST hubs along with debugging issues
      regarding us interfacing with hubs correctly vastly easier to debug.
      Currently this can actually be done if you trace the i2c devices for DP
      using ftrace but that's significantly less useful for a couple of
      reasons:
      
      - Tracing the i2c devices through ftrace means all of the traces are
        going to contain a lot of "garbage" output that we're sending over the
        i2c line. Most of this garbage comes from retrying transactions, DRM's
        helper library adding extra transactions to work around bad hubs, etc.
      - Having a user set up ftrace so that they can provide debugging
        information is a lot more difficult then being able to say "just boot
        with drm.debug=0x100"
      - We can potentially expand upon this tracing in the future to print
        debugging information in regards to other DP transactions like MST
        sideband transactions
      
      This is inspired by a patch Rob Clark sent to do this a long time back.
      Neither of us could find the patch however, so we both assumed it would
      probably just be easier to rewrite it anyway.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180716154432.13433-1-lyude@redhat.com
      a18b2192
    • Alexandru Gheorghe's avatar
      drm: writeback: Fix doc that says connector should be disconnected · 71a5cb3e
      Alexandru Gheorghe authored
      During iteration process one of the proposed mechanism for not
      breaking existing userspace was to report writeback connectors as
      disconnected, however the final version used
      DRM_CLIENT_CAP_WRITEBACK_CONNECTORS for that purpose.
      
      Change-Id: I2319d099f7669094c8530f1521abdbca08e76486
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Acked-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Link: https://patchwork.freedesktop.org/patch/238399/
      71a5cb3e
    • Michel Dänzer's avatar
      dma-buf: Move BUG_ON from _add_shared_fence to _add_shared_inplace · 7f43ef9f
      Michel Dänzer authored
      Fixes the BUG_ON spuriously triggering under the following
      circumstances:
      
      * reservation_object_reserve_shared is called with shared_count ==
        shared_max - 1, so obj->staged is freed in preparation of an in-place
        update.
      
      * reservation_object_add_shared_fence is called with the first fence,
        after which shared_count == shared_max.
      
      * reservation_object_add_shared_fence is called with a follow-up fence
        from the same context.
      
      In the second reservation_object_add_shared_fence call, the BUG_ON
      triggers. However, nothing bad would happen in
      reservation_object_add_shared_inplace, since both fences are from the
      same context, so they only occupy a single slot.
      
      Prevent this by moving the BUG_ON to where an overflow would actually
      happen (e.g. if a buggy caller didn't call
      reservation_object_reserve_shared before).
      
      v2:
      * Fix description of breaking scenario (Christian König)
      * Add bugzilla reference
      
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/106418
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1
      Reviewed-by: Christian König <christian.koenig@amd.com> # v1
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180704151405.10357-1-michel@daenzer.net
      7f43ef9f
    • Neil Armstrong's avatar
      drm/meson: Make DMT timings parameters and pixel clock generic · 3273fc63
      Neil Armstrong authored
      Remove the modes timings tables for DMT modes and calculate the HW
      paremeters from the modes timings.
      
      Switch the DMT modes pixel clock calculation out of the static frequency
      list to a generic calculation from a range of possible PLL dividers.
      
      This patch is an intermediate step towards usage of the Common Clock
      Framwework for PLL setup, by reworking the code to have common
      sel_pll() function called by the CEA (HDMI) freq setup and the generic
      DMT frequencies setup, we should be able to simply call clk_set_rate()
      on the PLL clock handle in a near future.
      
      The CEA (HDMI) and CVBS modes needs very specific clock paths that CCF will
      never be able to determine by itself, so there is still some work to do for
      a full handoff to CCF handling the clocks.
      
      This setup permits setting non-CEA modes like :
      - 1600x900-60Hz
      - 1280x1024-75Hz
      - 1280x1024-60Hz
      - 1440x900-60Hz
      - 1366x768-60Hz
      - 1280x800-60Hz
      - 1152x864-75Hz
      - 1024x768-75Hz
      - 1024x768-70Hz
      - 1024x768-60Hz
      - 832x624-75Hz
      - 800x600-75Hz
      - 800x600-72Hz
      - 800x600-60Hz
      - 640x480-75Hz
      - 640x480-73Hz
      - 640x480-67Hz
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      [narmstrong: fixed trivial checkpatch issues]
      Link: https://patchwork.freedesktop.org/patch/msgid/1531726814-14638-1-git-send-email-narmstrong@baylibre.com
      3273fc63
  2. 13 Jul, 2018 23 commits
  3. 12 Jul, 2018 11 commits
  4. 11 Jul, 2018 2 commits