[lkml]   [2019]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC 0/4] Add support for drm/rockchip to dynamically control the DDR frequency within vblank for gru chromebooks.
Dear all,

The purpose of that RFC is to enable de DMC device for the Rockchip
based GRU Chromebooks, and to add a mean of synchronization between the
Rockchip DRM driver and that DMC devfreq driver.

The DMC device is responsible for updating the DDR frequency according
to the load of the DDR memory. Changing that clock rate within the
display scanout leads to glitches. Thus, the devfreq framework needs a
mean to synchronize the rate change with other devices.

In that case, the DRM driver display has to synchronize a change rate
within the VBLANK.

The first patch adds a locking API to the devfreq framework. The users
of a devfreq device can control the frequency change by locking and
unlocking the devfreq device whenever they want. When a change rate is
requested, and the device is locked, the drivers that hold a lock are
called back, and the change will be applied as soon as the device is

The second patch adds the devfreq support in the Rockchip DRM drivers
and uses the devfreq lock API to defer the change of the DDR frequency
within the next VBLANK. The DRM driver locks the devfreq device and gets
notified when a change is wanted then. Next, it enables the VBLANK
interrupt, releases the lock on interrupt and starts a timer that
relocks the devfreq device at the end of the vertical blanking interval.
Also, the DRM driver disables the devfreq device if more than one CRTC
becomes active.

The third patch merges the Rockchip DDR clock code to the Rockchip DMC
devfreq driver. These drivers both perform SMC calls to the
Trusted-Firmware A to run SiP services that are related to the DDR
memory. This merge puts the code at the same place. It avoids the
contention in the Common Clock Framework that may cause to miss the
deadline during which the rate can be changing without making glitches.

The fourth patch tells display-subsystem to use the DMC devfreq device.

I am waiting for your feedback.

Note: This RFC needs patchset[1]. Its purpose is to addresses the review
that was made in v1[2]. I dropped some patches in v2 to address things
separately (in that RFC).


Best regards,
Gaël PORTAY (3):
PM / devfreq: add devfreq_lock/unlock() functions
drm: rockchip: Add DDR devfreq support.
clk: rockchip: merge clk-ddr in dmc devfreq driver
arm64: dts: rockchip: Set the display-subsystem devfreq

arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 4 +
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
drivers/clk/rockchip/Makefile | 1 -
drivers/clk/rockchip/clk-ddr.c | 147 --------------
drivers/clk/rockchip/clk-rk3399.c | 2 -
drivers/clk/rockchip/clk.c | 9 -
drivers/clk/rockchip/clk.h | 33 ---
drivers/devfreq/devfreq.c | 200 ++++++++++++++++++-
drivers/devfreq/rk3399_dmc.c | 42 ++--
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 51 ++++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 6 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 177 +++++++++++++++-
drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 3 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 82 ++++++++
include/linux/devfreq.h | 64 ++++++
15 files changed, 611 insertions(+), 212 deletions(-)
delete mode 100644 drivers/clk/rockchip/clk-ddr.c


 \ /
  Last update: 2019-04-30 20:07    [W:0.044 / U:1.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site