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
