Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Samuel Holland <samuel@sholland.org>
To:     MyungJoo Ham <myungjoo.ham@samsung.com>,
        Kyungmin Park <kyungmin.park@samsung.com>,
        Chanwoo Choi <cw00.choi@samsung.com>,
        Maxime Ripard <mripard@kernel.org>,
        Chen-Yu Tsai <wens@csie.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Rob Herring <robh+dt@kernel.org>
Cc:     Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
        linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
        Samuel Holland <samuel@sholland.org>
Subject: [PATCH 00/10] DRAM devfreq support for Allwinner A64/H5
Date:   Tue, 28 Sep 2021 23:42:44 -0500
Message-Id: <20210929044254.38301-1-samuel@sholland.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

This series adds a new devfreq driver for the MBUS/DRAM controller in
some Allwinner SoCs, and enables it for the A64 and H5.

The first four patches make some improvements to the devfreq core to
support drivers without any OPPs in the DT. They could be merged
independently. (Since this driver controls only a divider, and can only
slow down the DRAM clock, it works with most any base DRAM frequency.)

Then the binding and DTs are updated in patches 5-9. The MBUS nodes
already existed, but were not bound to any driver before; they were only
used for their dma-ranges property.

Finally, the driver is added in patch 10.

I am not 100% sure the best way to handle DRAM register access -- as a
separate reg property, a separate node, or simply enlarging the MBUS
register range. While the DRAM controller is a separate IP block, the
MBUS hardware has the ability to double-buffer certain DRAM controller
registers, and the hardware MDFS process writes to some DRAM controller
registers as well. So they are rather tightly integrated.

Like the patch 10 description says, this driver could support additional
SoCs: at least A33, A83T, and H3. I can send follow-up patches for
these, but I cannot test A33 or A83T.

Samuel Holland (10):
  PM / devfreq: strengthen check for freq_table
  PM / devfreq: Do not require devices to have OPPs
  PM / devfreq: Drop code for descending freq_table
  PM / devfreq: Add a recommended frequency helper
  dt-bindings: clock: sunxi: Export CLK_DRAM for devfreq
  dt-bindings: arm: sunxi: Expand MBUS binding
  dt-bindings: arm: sunxi: Add H5 MBUS compatible
  ARM: dts: sunxi: h3/h5: Update MBUS node
  arm64: dts: allwinner: a64: Update MBUS node
  PM / devfreq: Add a driver for the sun8i/sun50i MBUS

 .../arm/sunxi/allwinner,sun4i-a10-mbus.yaml   |  77 ++-
 arch/arm/boot/dts/sun8i-h3.dtsi               |   4 +
 arch/arm/boot/dts/sunxi-h3-h5.dtsi            |  11 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  10 +-
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi  |   4 +
 drivers/clk/sunxi-ng/ccu-sun50i-a64.h         |   2 -
 drivers/clk/sunxi-ng/ccu-sun8i-h3.h           |   2 -
 drivers/devfreq/Kconfig                       |   8 +
 drivers/devfreq/Makefile                      |   1 +
 drivers/devfreq/devfreq.c                     |  77 ++-
 drivers/devfreq/sun8i-a33-mbus.c              | 482 ++++++++++++++++++
 include/dt-bindings/clock/sun50i-a64-ccu.h    |   2 +-
 include/dt-bindings/clock/sun8i-h3-ccu.h      |   2 +-
 include/linux/devfreq.h                       |   2 +
 14 files changed, 644 insertions(+), 40 deletions(-)
 create mode 100644 drivers/devfreq/sun8i-a33-mbus.c

-- 
2.31.1