public inbox for linux-arm-msm@vger.kernel.org
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Stephan Gerhold <stephan.gerhold@linaro.org>,
	Andi Shyti <andi.shyti@kernel.org>
Cc: Wolfram Sang <wsa@kernel.org>, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-i2c@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Konrad Dybcio <konradybcio@kernel.org>
Subject: Re: [PATCH 3/3] i2c: qup: Vote for interconnect bandwidth to DRAM
Date: Tue, 25 Feb 2025 14:25:28 +0100	[thread overview]
Message-ID: <af3f28d3-d3aa-4da2-81d7-4c3640ae62cf@oss.qualcomm.com> (raw)
In-Reply-To: <Z7W1EJ7uGsaTZMRh@linaro.org>

On 19.02.2025 11:40 AM, Stephan Gerhold wrote:
> Hi Andi,
> 
> On Wed, Feb 19, 2025 at 12:02:06AM +0100, Andi Shyti wrote:
>>
>> sorry for the very late reply here. Just one question.
>>
> 
> Thanks for bringing the patch back up after such a long time. I've been
> meaning to resend it, but never found the time to do so... :-)
> 
>>
>>> downstream/vendor driver [1]. Due to lack of documentation about the
>>> interconnect setup/behavior I cannot say exactly if this is right.
>>> Unfortunately, this is not implemented very consistently downstream...
>>
>> Can we have someone from Qualcomm or Linaro taking a peak here?
>>
> 
> I suppose I count as someone from Linaro nowadays. However, since this
> driver is only used on really old platforms nowadays, I'm not sure where
> to look or who to ask...
> 
> At the end, the whole bus scaling/interconnect is always somewhat
> "imprecise". There is no clear "correct" or "wrong", since the ideal
> bandwidth depends heavily on the actual use case that we are not aware
> of in the driver. There is also overhead when voting for bandwidth,
> since that can take a couple of milliseconds.
> 
> The most important part is that we vote for any bandwidth at all, since
> otherwise the bus path could potentially be completely off and it would
> get stuck. My patch implements one of the approaches that was used in
> the downstream/vendor drivers and matches what we already have upstream
> in the corresponding spi-qup driver. I think it's "good enough". If
> someone ever wants to fine tune this based on actual measurements they
> can just submit an incremental patch. Right now this series is blocking
> adding the necessary properties in the device tree and that's not good.

Yeah, the throughput of an I2C controller isn't even very likely to affect
the total bus frequency requirement, although it's a strict requirement
that the requested bw is nonzero (otherwise the bus may be clock-gated)

Konrad

  parent reply	other threads:[~2025-02-25 13:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-28  9:48 [PATCH 0/3] i2c: qup: Allow scaling power domains and interconnect Stephan Gerhold
2023-11-28  9:48 ` [PATCH 1/3] dt-bindings: i2c: qcom,i2c-qup: Document power-domains Stephan Gerhold
2023-11-28 17:50   ` Rob Herring
2023-11-28  9:48 ` [PATCH 2/3] dt-bindings: i2c: qup: Document interconnects Stephan Gerhold
2023-11-28 17:51   ` Rob Herring
2023-11-28  9:48 ` [PATCH 3/3] i2c: qup: Vote for interconnect bandwidth to DRAM Stephan Gerhold
2023-11-28 19:17   ` Andi Shyti
2025-02-18 23:02   ` Andi Shyti
2025-02-18 23:13     ` Andi Shyti
2025-02-19  7:00     ` Krzysztof Kozlowski
2025-02-19 19:36       ` Andi Shyti
2025-02-19 10:40     ` Stephan Gerhold
2025-02-19 19:30       ` Andi Shyti
2025-02-20  9:47         ` Stephan Gerhold
2025-02-25 13:25       ` Konrad Dybcio [this message]
2025-02-26 22:11 ` [PATCH 0/3] i2c: qup: Allow scaling power domains and interconnect Andi Shyti

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=af3f28d3-d3aa-4da2-81d7-4c3640ae62cf@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=andi.shyti@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=stephan.gerhold@linaro.org \
    --cc=wsa@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox