Re: [PATCH V7 RESEND 4/7] spi: spi-geni-qcom: Add interconnect support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mark,

On 6/9/2020 7:11 PM, Mark Brown wrote:
On Tue, Jun 09, 2020 at 11:26:31AM +0530, Akash Asthana wrote:
Get the interconnect paths for SPI based Serial Engine device
and vote according to the current bus speed of the driver.

Signed-off-by: Akash Asthana <akashast@xxxxxxxxxxxxxx>
Reviewed-by: Matthias Kaehlcke <mka@xxxxxxxxxxxx>
---
I've repeatedly acked this patch but my ack never seems to get carried
forward :(

I carry acks from previous patches if nothing is changed in current patch wrt previous version, I did that in V6@http://patchwork.ozlabs.org/project/linux-i2c/patch/1590049764-20912-5-git-send-email-akashast@xxxxxxxxxxxxxx/

But since there was change from V6 to V7 so, I didn't carried ack from V6 to V7, because I thought I'll need your approvals on additional changes.

V7@http://patchwork.ozlabs.org/project/linux-i2c/patch/1590497690-29035-5-git-send-email-akashast@xxxxxxxxxxxxxx/

================================================

Changes in V7:
 - As per Matthias's comment removed usage of peak_bw variable because we don't
   have explicit peak requirement, we were voting peak = avg and this can be
   tracked using single variable for avg bw.
==========================================================


+	/* Set the bus quota to a reasonable value for register access */
+	mas->se.icc_paths[GENI_TO_CORE].avg_bw = Bps_to_icc(CORE_2X_50_MHZ);
+	mas->se.icc_paths[CPU_TO_GENI].avg_bw = GENI_DEFAULT_BW;
Why are these asymmetric?

These are asymmetric because we want to start by putting minimal vote on CPU_TO_GENI path for register access and later based on per transfer's need we scale it at runtime.

However, for GENI_TO_CORE path we are trying to keep fixed vote from probe itself that can support max bus speed, we are not scaling it per transfer's need because FW runs on core clock and core behaves a bit different than other NOCs.

We don't have any functional relation which mapping btw actual throughput requirement to core frequency need. In the past we have faced few latency issues because of core slowness (Although it was running much higher than actual throughput requirement). To avoid such scenario we are using tested and recommended value from HW team.

Thankyou for review.

regards,

Akash

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project




[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux