mbox series

[0/4] spi: qup: Allow scaling power domains and interconnect

Message ID 20230912-spi-qup-dvfs-v1-0-3e38aa09c2bd@kernkonzept.com
Headers show
Series spi: qup: Allow scaling power domains and interconnect | expand

Message

Stephan Gerhold Sept. 12, 2023, 2:30 p.m. UTC
Make it possible to scale performance states of the power domain and
interconnect of the SPI QUP controller in relation to the selected SPI
speed / core clock. This is done separately by:

  - Parsing the OPP table from the device tree for performance state
    votes of the power domain
  - Voting for the necessary bandwidth on the interconnect path to DRAM

Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
---
Stephan Gerhold (4):
      spi: dt-bindings: qup: Document power-domains and OPP
      spi: qup: Parse OPP table for DVFS support
      spi: dt-bindings: qup: Document interconnects
      spi: qup: Vote for interconnect bandwidth to DRAM

 .../devicetree/bindings/spi/qcom,spi-qup.yaml      | 13 ++++++
 drivers/spi/spi-qup.c                              | 50 +++++++++++++++++++++-
 2 files changed, 62 insertions(+), 1 deletion(-)
---
base-commit: 678466ba68915d452c200b78d0385931e6f8e907
change-id: 20230912-spi-qup-dvfs-71fc8a5e0cb1

Best regards,

Comments

Konrad Dybcio Sept. 13, 2023, 8:54 a.m. UTC | #1
On 12.09.2023 16:30, Stephan Gerhold wrote:
> Parse the OPP table from the device tree and use dev_pm_opp_set_rate()
> instead of clk_set_rate() to allow making performance state for power
> domains specified in the OPP table.
> 
> This is needed to guarantee correct behavior of the clock, especially
> with the higher clock/SPI bus frequencies.
> 
> Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>

Konrad
Stephan Gerhold Sept. 13, 2023, 9:26 a.m. UTC | #2
On Tue, Sep 12, 2023 at 04:30:39PM +0200, Stephan Gerhold wrote:
> When the SPI QUP controller is used together with a DMA engine it needs
> to vote for the interconnect path to the DRAM. Otherwise it may be
> unable to access the memory quickly enough.

I realized that I argue here that the interconnect vote is for DMA to
DRAM...

> [...]
> @@ -675,6 +698,12 @@ static int spi_qup_io_prep(struct spi_device *spi, struct spi_transfer *xfer)
>  		return -EIO;
>  	}
>  
> +	ret = spi_qup_vote_bw(controller, xfer->speed_hz);
> +	if (ret) {
> +		dev_err(controller->dev, "fail to vote for ICC bandwidth: %d\n", ret);
> +		return -EIO;
> +	}
> +

... but here I vote for the bandwidth even if PIO is used instead of DMA.

I think it would be more logical to only do the bandwidth vote in the
DMA setup path. I'll fix this in v2.

Thanks,
Stephan