All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gaël PORTAY" <gael.portay@collabora.com>
To: "Rob Herring" <robh+dt@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"MyungJoo Ham" <myungjoo.ham@samsung.com>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Gaël PORTAY" <gael.portay@collabora.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Cc: Douglas Anderson <dianders@chromium.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Derek Basehore <dbasehore@chromium.org>,
	Lin Huang <hl@rock-chips.com>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	kernel@collabora.com
Subject: [RFC 0/4] Add support for drm/rockchip to dynamically control  the DDR frequency within vblank for gru chromebooks.
Date: Tue, 30 Apr 2019 14:05:20 -0400	[thread overview]
Message-ID: <20190430180524.22710-1-gael.portay@collabora.com> (raw)

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
unlocked.

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).

[1]: https://patchwork.kernel.org/cover/10901577/
[2]: https://lkml.org/lkml/fancy/2018/8/2/7

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

-- 
2.21.0


WARNING: multiple messages have this Message-ID (diff)
From: "Gaël PORTAY" <gael.portay@collabora.com>
To: "Rob Herring" <robh+dt@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"MyungJoo Ham" <myungjoo.ham@samsung.com>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Gaël PORTAY" <gael.portay@collabora.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Cc: Lin Huang <hl@rock-chips.com>,
	Derek Basehore <dbasehore@chromium.org>,
	Douglas Anderson <dianders@chromium.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	kernel@collabora.com
Subject: [RFC 0/4] Add support for drm/rockchip to dynamically control the DDR frequency within vblank for gru chromebooks.
Date: Tue, 30 Apr 2019 14:05:20 -0400	[thread overview]
Message-ID: <20190430180524.22710-1-gael.portay@collabora.com> (raw)

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
unlocked.

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).

[1]: https://patchwork.kernel.org/cover/10901577/
[2]: https://lkml.org/lkml/fancy/2018/8/2/7

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

-- 
2.21.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2019-04-30 18:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-30 18:05 Gaël PORTAY [this message]
2019-04-30 18:05 ` [RFC 0/4] Add support for drm/rockchip to dynamically control the DDR frequency within vblank for gru chromebooks Gaël PORTAY
2019-04-30 18:05 ` [RFC 1/4] PM / devfreq: add devfreq_lock/unlock() functions Gaël PORTAY
2019-04-30 18:05   ` Gaël PORTAY
2019-04-30 18:05 ` [RFC 2/4] drm: rockchip: Add DDR devfreq support Gaël PORTAY
2019-04-30 18:05   ` Gaël PORTAY
2019-05-01 12:47   ` Gaël PORTAY
2019-05-01 12:47     ` Gaël PORTAY
2019-04-30 18:05 ` [RFC 3/4] clk: rockchip: merge clk-ddr in dmc devfreq driver Gaël PORTAY
2019-04-30 18:05   ` Gaël PORTAY
2019-04-30 18:05 ` [RFC 4/4] arm64: dts: rockchip: Set the display-subsystem devfreq Gaël PORTAY
2019-04-30 18:05   ` Gaël PORTAY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190430180524.22710-1-gael.portay@collabora.com \
    --to=gael.portay@collabora.com \
    --cc=airlied@linux.ie \
    --cc=boris.brezillon@collabora.com \
    --cc=cw00.choi@samsung.com \
    --cc=daniel@ffwll.ch \
    --cc=dbasehore@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=enric.balletbo@collabora.com \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=hl@rock-chips.com \
    --cc=kernel@collabora.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=mka@chromium.org \
    --cc=mturquette@baylibre.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.