1. 16 Oct, 2019 1 commit
  2. 15 Oct, 2019 2 commits
  3. 14 Oct, 2019 7 commits
  4. 13 Oct, 2019 4 commits
  5. 11 Oct, 2019 11 commits
  6. 10 Oct, 2019 11 commits
  7. 09 Oct, 2019 4 commits
    • Sean Paul's avatar
      Documentation: Fix warning in drm-kms-helpers.rst · 64292b33
      Sean Paul authored
      Fixes the following warning:
      ../include/drm/drm_atomic_state_helper.h:1: warning: no structured comments found
      
      Fixes: 9ef8a9dc ("drm: Extract drm_atomic_state_helper.[hc]")
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <mripard@kernel.org>
      Cc: Sean Paul <sean@poorly.run>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: dri-devel@lists.freedesktop.org
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191007151921.27099-1-sean@poorly.run
      64292b33
    • Douglas Anderson's avatar
      drm/rockchip: Round up _before_ giving to the clock framework · 287422a9
      Douglas Anderson authored
      I'm embarassed to say that even though I've touched
      vop_crtc_mode_fixup() twice and I swear I tested it, there's still a
      stupid glaring bug in it.  Specifically, on veyron_minnie (with all
      the latest display timings) we want to be setting our pixel clock to
      66,666,666.67 Hz and we tell userspace that's what we set, but we're
      actually choosing 66,000,000 Hz.  This is confirmed by looking at the
      clock tree.
      
      The problem is that in drm_display_mode_from_videomode() we convert
      from Hz to kHz with:
      
        dmode->clock = vm->pixelclock / 1000;
      
      ...and drm_display_mode_from_videomode() is called from panel-simple
      when we have an "override_mode" like we do on veyron_minnie.  See
      commit 123643e5 ("ARM: dts: rockchip: Specify
      rk3288-veyron-minnie's display timings").
      
      ...so when the device tree specifies a clock of 66666667 for the panel
      then DRM translates that to 66666000.  The clock framework will always
      pick a clock that is _lower_ than the one requested, so it will refuse
      to pick 66666667 and we'll end up at 66000000.
      
      While we could try to fix drm_display_mode_from_videomode() to round
      to the nearest kHz and it would fix our problem, it wouldn't help if
      the clock we actually needed was 60,000,001 Hz.  We could
      alternatively have DRM always round up, but maybe this would break
      someone else who already baked in the assumption that DRM rounds down.
      Specifically note that clock drivers are not consistent about whether
      they round up or round down when you call clk_set_rate().  We know how
      Rockchip's clock driver works, but (for instance) you can see that on
      most Qualcomm clocks the default is clk_rcg2_ops which rounds up.
      
      Let's solve this by just adding 999 Hz before calling
      clk_round_rate().  This should be safe and work everywhere.  As
      discussed in more detail in comments in the commit, Rockchip's PLLs
      are configured in a way that there shouldn't be another PLL setting
      that is only a few kHz off so we won't get mixed up.
      
      NOTE: if this is picked to stable, it's probably easiest to first pick
      commit 527e4ca3 ("drm/rockchip: Base adjustments of the mode based
      on prev adjustments") which shouldn't hurt in stable.
      
      Fixes: b59b8de3 ("drm/rockchip: return a true clock rate to adjusted_mode")
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191003114726.v2.1.Ib233b3e706cf6317858384264d5b0ed35657456e@changeid
      287422a9
    • Steven Price's avatar
      drm/panfrost: Remove commented out call to panfrost_core_dump · cfbb2e38
      Steven Price authored
      panfrost_core_dump() has never existed in mainline, so remove it and add
      a TODO entry that core dump support is currently lacking.
      Signed-off-by: default avatarSteven Price <steven.price@arm.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191009094456.9704-2-steven.price@arm.com
      cfbb2e38
    • Steven Price's avatar
      drm/panfrost: Handle resetting on timeout better · de89212d
      Steven Price authored
      Panfrost uses multiple schedulers (one for each slot, so 2 in reality),
      and on a timeout has to stop all the schedulers to safely perform a
      reset. However more than one scheduler can trigger a timeout at the same
      time. This race condition results in jobs being freed while they are
      still in use.
      
      When stopping other slots use cancel_delayed_work_sync() to ensure that
      any timeout started for that slot has completed. Also use
      mutex_trylock() to obtain reset_lock. This means that only one thread
      attempts the reset, the other threads will simply complete without doing
      anything (the first thread will wait for this in the call to
      cancel_delayed_work_sync()).
      
      While we're here and since the function is already dependent on
      sched_job not being NULL, let's remove the unnecessary checks.
      
      Fixes: aa202367 ("drm/panfrost: Prevent concurrent resets")
      Tested-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarSteven Price <steven.price@arm.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191009094456.9704-1-steven.price@arm.com
      de89212d