All of lore.kernel.org
 help / color / mirror / Atom feed
From: Georgi Djakov <georgi.djakov@linaro.org>
To: Akash Asthana <akashast@codeaurora.org>, broonie@kernel.org
Cc: gregkh@linuxfoundation.org, agross@kernel.org,
	bjorn.andersson@linaro.org, wsa@the-dreams.de,
	mark.rutland@arm.com, robh+dt@kernel.org,
	linux-i2c@vger.kernel.org, linux-spi@vger.kernel.org,
	devicetree@vger.kernel.org, swboyd@chromium.org,
	mgautam@codeaurora.org, linux-arm-msm@vger.kernel.org,
	linux-serial@vger.kernel.org, mka@chromium.org,
	dianders@chromium.org, evgreen@chromium.org,
	Linux PM list <linux-pm@vger.kernel.org>,
	Mike Tipton <mdtipton@codeaurora.org>,
	Sean Sweeney <seansw@qti.qualcomm.com>
Subject: Re: [PATCH V4 2/9] interconnect: Set peak requirement as twice of average
Date: Thu, 23 Apr 2020 12:31:11 +0300	[thread overview]
Message-ID: <58b91dc1-6ce3-49b8-88c8-259be9af1dbd@linaro.org> (raw)
In-Reply-To: <1586946198-13912-3-git-send-email-akashast@codeaurora.org>

Hi Akash,

On 4/15/20 13:23, Akash Asthana wrote:
> Lot of ICC clients are not aware of their actual peak requirement,
> most commonly they tend to guess their peak requirement as
> (some factor) * avg_bw.
> 
> Centralize random peak guess as twice of average, out into the core
> to maintain consistency across the clients. Client can always
> override this setting if they got a better idea.

I am still not convinced that this is a good idea. If the factor is a random
value, then i think that the default factor should be 1.

According to your previous reply, it seems that from geni we are requesting
double peak bandwidth to compensate for other clients which are not requesting
bandwidth for themselves. IMO, this is a bit hacky.

Instead of requesting double peak bandwidth, IIUC the correct thing to do here
is to request peak_bw = avg_bw for geni. And instead of trying to compensate for
other clients "stealing" bandwidth, can't we make these clients vote for their
own bandwidth? Or if they really can't, this should be handled elsewhere - maybe
in the interconnect platform driver we can reserve some amount of minimum
bandwidth for such cases?

Thanks,
Georgi

  reply	other threads:[~2020-04-23  9:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 10:23 [PATCH V4 0/9] Add interconnect support to QSPI and QUP drivers Akash Asthana
2020-04-15 10:23 ` [PATCH V4 1/9] interconnect: Add devm_of_icc_get() as exported API for users Akash Asthana
2020-04-28 16:04   ` Georgi Djakov
2020-04-15 10:23 ` [PATCH V4 2/9] interconnect: Set peak requirement as twice of average Akash Asthana
2020-04-23  9:31   ` Georgi Djakov [this message]
2020-04-28  9:46     ` Akash Asthana
2020-04-28 10:53       ` Georgi Djakov
2020-04-15 10:23 ` [PATCH V4 3/9] soc: qcom: geni: Support for ICC voting Akash Asthana
2020-04-15 23:36   ` Matthias Kaehlcke
2020-04-28  9:48     ` Akash Asthana
2020-04-15 10:23 ` [PATCH V4 4/9] soc: qcom-geni-se: Add interconnect support to fix earlycon crash Akash Asthana
2020-04-16  0:31   ` Matthias Kaehlcke
2020-04-28 10:21     ` Akash Asthana
2020-04-28 15:48       ` Matthias Kaehlcke
2020-04-15 10:23 ` [PATCH V4 5/9] i2c: i2c-qcom-geni: Add interconnect support Akash Asthana
2020-04-16 17:09   ` Matthias Kaehlcke
2020-04-15 10:23 ` [PATCH V4 6/9] spi: spi-geni-qcom: " Akash Asthana
2020-04-15 11:39   ` Mark Brown
2020-04-15 10:23 ` [PATCH V4 7/9] tty: serial: qcom_geni_serial: " Akash Asthana
2020-04-16 17:17   ` Matthias Kaehlcke
2020-04-15 10:23 ` [PATCH V4 8/9] spi: spi-qcom-qspi: " Akash Asthana
2020-04-15 10:23 ` [PATCH V4 9/9] arm64: dts: sc7180: Add interconnect for QUP and QSPI Akash Asthana

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=58b91dc1-6ce3-49b8-88c8-259be9af1dbd@linaro.org \
    --to=georgi.djakov@linaro.org \
    --cc=agross@kernel.org \
    --cc=akashast@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=evgreen@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mdtipton@codeaurora.org \
    --cc=mgautam@codeaurora.org \
    --cc=mka@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=seansw@qti.qualcomm.com \
    --cc=swboyd@chromium.org \
    --cc=wsa@the-dreams.de \
    /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.