Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 5月, 2020 1 次提交
  3. 15 4月, 2020 1 次提交
  5. 23 3月, 2020 1 次提交
  7. 28 1月, 2020 1 次提交
  9. 14 10月, 2019 1 次提交
  11. 11 10月, 2019 1 次提交
  13. 10 10月, 2019 1 次提交
    • D
      drm/rockchip: Round up _before_ giving to the clock framework · 287422a9
      由 Douglas Anderson 提交于 
      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: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003114726.v2.1.Ib233b3e706cf6317858384264d5b0ed35657456e@changeid
      287422a9
  15. 19 9月, 2019 1 次提交
    • S
      drm: Measure Self Refresh Entry/Exit times to avoid thrashing · d4da4e33
      由 Sean Paul 提交于 
      Currently the self refresh idle timer is a const set by the crtc. This
is fine if the self refresh entry/exit times are well-known for all
panels used on that crtc. However panels and workloads can vary quite a
bit, and a timeout which works well for one doesn't work well for
another.

In the extreme, if the timeout is too short we could get in a situation
where the self refresh exits are taking so long we queue up a self refresh
entry before the exit commit is even finished.

This patch changes the idle timeout to a moving average of the entry
times + a moving average of exit times + the crtc constant.

This patch was tested on rockchip, with a kevin CrOS panel the idle
delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On
the same board, the bob panel idle delay lands around ~340ms (90 entry
+ 150 exit + 100 const).

WRT the dedicated mutex in self_refresh_data, it would be nice if we
could rely on drm_crtc.mutex to protect the average times, but there are
a few reasons why a separate lock is a better choice:
- We can't rely on drm_crtc.mutex being held if we're doing a nonblocking
  commit
- We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us
  whether the lock was already held in the acquire context (it eats
  -EALREADY), so we can't tell if we should drop it or not
- We don't need such a heavy-handed lock for what we're trying to do,
  commit ordering doesn't matter, so a point-of-use lock will be less
  contentious
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-2-sean@poorly.run

Changes in v2:
- Migrate locking explanation from comment to commit msg (Daniel)
- Turf constant entry delay and multiply the avg times by 2 (Daniel)
      d4da4e33
  17. 08 8月, 2019 1 次提交
  19. 27 7月, 2019 3 次提交
  21. 17 7月, 2019 1 次提交
  23. 16 6月, 2019 2 次提交
  25. 05 6月, 2019 1 次提交
  27. 04 6月, 2019 1 次提交
    • H
      drm/rockchip: fix fb references in async update · d985a353
      由 Helen Koike 提交于 
      In the case of async update, modifications are done in place, i.e. in the
current plane state, so the new_state is prepared and the new_state is
cleaned up (instead of the old_state, unlike what happens in a
normal sync update).
To cleanup the old_fb properly, it needs to be placed in the new_state
in the end of async_update, so cleanup call will unreference the old_fb
correctly.

Also, the previous code had a:

	plane_state = plane->funcs->atomic_duplicate_state(plane);
	...
	swap(plane_state, plane->state);

	if (plane->state->fb && plane->state->fb != new_state->fb) {
	...
	}

Which was wrong, as the fb were just assigned to be equal, so this if
statement nevers evaluates to true.

Another details is that the function drm_crtc_vblank_get() can only be
called when vop->is_enabled is true, otherwise it has no effect and
trows a WARN_ON().

Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
fb and pus the old fb) is not required, as it is taken care by
drm_mode_cursor_universal() when calling
drm_atomic_helper_update_plane().

Fixes: 15609559 ("drm/rockchip: update cursors asynchronously through atomic.")
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: NHelen Koike <helen.koike@collabora.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-2-helen.koike@collabora.com
      d985a353
  29. 20 5月, 2019 2 次提交
  31. 25 4月, 2019 1 次提交
  33. 31 3月, 2019 1 次提交
  35. 19 3月, 2019 1 次提交
  37. 28 1月, 2019 1 次提交
  39. 24 1月, 2019 1 次提交
  41. 11 1月, 2019 4 次提交
  43. 13 12月, 2018 1 次提交
  45. 30 10月, 2018 1 次提交
  47. 05 9月, 2018 1 次提交
  49. 29 8月, 2018 1 次提交
  51. 23 8月, 2018 1 次提交
  53. 13 8月, 2018 1 次提交
  55. 18 7月, 2018 1 次提交
  57. 27 6月, 2018 1 次提交
  59. 18 6月, 2018 2 次提交
  61. 18 5月, 2018 1 次提交
  63. 02 5月, 2018 1 次提交