From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Mike Tipton <quic_mdtipton@quicinc.com>
Cc: Georgi Djakov <djakov@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>,
cros-qcom-dts-watchers@chromium.org,
Marijn Suijten <marijn.suijten@somainline.org>,
linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/53] icc-rpmh multi-RSC voting groundwork
Date: Fri, 15 Sep 2023 15:43:27 +0200 [thread overview]
Message-ID: <978fd46d-8142-41e6-9c62-df678018d6c2@linaro.org> (raw)
In-Reply-To: <20230914023239.GA25147@hu-mdtipton-lv.qualcomm.com>
On 14.09.2023 04:32, Mike Tipton wrote:
> On Wed, Sep 13, 2023 at 10:31:49AM +0200, Konrad Dybcio wrote:
>>> The applicable voters should likely be defined in the target-specific
>>> headers, rather than the common qcom,icc.h. The bit range used for them
>>> could be common, but each target may only support a small subset of the
>>> total set of possible voters across all targets.
>> I'm not sure how client drivers would then choose the
>> correct path other than
>>
>> switch (soc) {
>> case 8450:
>> tag = QCOM_ICC_TAG_VOTER_8450_HLOS;
>> break;
>> case 8550:
>> tag = QCOM_ICC_TAG_VOTER_8550_HLOS;
>> break;
>> ...
>> }
>>
>> which would be unacceptable.
>
> The same general way it's handled for the endpoint bindings, which are
> already target-specific.
>
> Any client drivers hardcoding the endpoint bindings in their driver
> would have to include the appropriate, target-specific binding header
> (e.g. qcom,sm8550-rpmh.h). That would only be possible if their driver
> file is itself target-specific. Otherwise, it would have to pull the
> endpoint bindings from devicetree. Or just use the recommended
> of_icc_get() and let devicetree do everything for them. Same for the
> target-specific voter tag bindings.
>
> Clients can also specify their tags in devicetree. They don't actually
> have to call icc_set_tag() directly. For example:
>
> #include <dt-bindings/interconnect/qcom,sm8450.h>
>
> interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_VOTER_DISP
> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_VOTER_DISP>;
>
> Then when they call of_icc_get() for this path it'll automatically have
> QCOM_ICC_TAG_VOTER_DISP set for them.
I think I'd skew towards the "define everything in the DT" approach.
One thing that makes me uneasy to go on with this approach is the
question whether there is a case in which we would want to switch
from e.g. voting through DISP to voting through APPS (or similar)
from within a single device.
Konrad
next prev parent reply other threads:[~2023-09-15 13:43 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 12:17 Konrad Dybcio
2023-07-11 12:18 ` [PATCH 01/53] dt-bindings: interconnect: qcom,icc: Introduce fixed BCM voter indices Konrad Dybcio
2023-07-12 20:39 ` Krzysztof Kozlowski
2023-07-15 15:09 ` Konrad Dybcio
2023-07-11 12:18 ` [PATCH 02/53] dt-bindings: interconnect: qcom,bcm-voter: Add qcom,bcm-voter-idx Konrad Dybcio
2023-07-11 13:13 ` Rob Herring
2023-07-12 20:43 ` Krzysztof Kozlowski
2023-07-15 15:09 ` Konrad Dybcio
2023-08-05 21:21 ` Krzysztof Kozlowski
2023-09-06 12:43 ` Konrad Dybcio
2023-07-11 12:18 ` [PATCH 03/53] interconnect: qcom: icc-rpmh: Store direct BCM voter references Konrad Dybcio
2023-07-11 12:18 ` [PATCH 04/53] interconnect: qcom: icc-rpmh: Retire dead code Konrad Dybcio
2023-07-11 12:18 ` [PATCH 05/53] interconnect: qcom: icc-rpmh: Implement voting on non-APPS RSCs Konrad Dybcio
2023-07-11 12:18 ` [PATCH 06/53] interconnect: qcom: sc7180: Retire DEFINE_QNODE Konrad Dybcio
2023-07-11 12:18 ` [PATCH 07/53] interconnect: qcom: sdm670: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 08/53] interconnect: qcom: sdm845: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 09/53] interconnect: qcom: sdx55: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 10/53] interconnect: qcom: sdx65: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 11/53] interconnect: qcom: sm6350: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 12/53] interconnect: qcom: sm8150: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 13/53] interconnect: qcom: sm8250: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 14/53] interconnect: qcom: sm8350: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 15/53] interconnect: qcom: icc-rpmh: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 16/53] interconnect: qcom: sc7180: Retire DEFINE_QBCM Konrad Dybcio
2023-07-11 12:18 ` [PATCH 17/53] interconnect: qcom: sdm670: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 18/53] interconnect: qcom: sdm845: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 19/53] interconnect: qcom: sdx55: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 20/53] interconnect: qcom: sdx65: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 21/53] interconnect: qcom: sm6350: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 22/53] interconnect: qcom: sm8150: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 23/53] interconnect: qcom: sm8250: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 24/53] interconnect: qcom: sm8350: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 25/53] interconnect: qcom: icc-rpmh: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 26/53] interconnect: qcom: qdu1000: Explicitly assign voter_idx Konrad Dybcio
2023-07-11 12:18 ` [PATCH 27/53] interconnect: qcom: sa8775p: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 28/53] interconnect: qcom: sc7280: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 29/53] interconnect: qcom: sc8180x: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 30/53] interconnect: qcom: sc8280xp: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 31/53] interconnect: qcom: sm8450: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 32/53] interconnect: qcom: sm8550: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 33/53] arm64: dts: qcom: qdu1000: add qcom,bcm-voter-idx Konrad Dybcio
2023-07-11 12:18 ` [PATCH 34/53] arm64: dts: qcom: sa8775p: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 35/53] arm64: dts: qcom: sc7180: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 36/53] arm64: dts: qcom: sc7280: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 37/53] arm64: dts: qcom: sc8180x: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 38/53] arm64: dts: qcom: sc8280xp: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 39/53] arm64: dts: qcom: sdm670: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 40/53] arm64: dts: qcom: sdm845: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 41/53] arm64: dts: qcom: sdx75: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 42/53] arm64: dts: qcom: sm6350: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 43/53] arm64: dts: qcom: sm8150: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 44/53] arm64: dts: qcom: sm8250: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 45/53] arm64: dts: qcom: sm8350: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 46/53] arm64: dts: qcom: sm8450: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 47/53] arm64: dts: qcom: sm8550: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 48/53] arm64: dts: qcom: sdx55: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 49/53] arm64: dts: qcom: sdx65: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 50/53] interconnect: qcom: sm8350: Point display paths to the display RSC Konrad Dybcio
2023-07-11 14:17 ` Dmitry Baryshkov
2023-07-11 14:18 ` Konrad Dybcio
2023-07-11 12:18 ` [PATCH 51/53] interconnect: qcom: sm8450: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 52/53] interconnect: qcom: sm8550: " Konrad Dybcio
2023-07-11 12:18 ` [PATCH 53/53] interconnect: qcom: sm8550: Point camera paths to the camera RSC Konrad Dybcio
2023-08-03 16:48 ` [PATCH 00/53] icc-rpmh multi-RSC voting groundwork Georgi Djakov
2023-08-07 21:57 ` Mike Tipton
2023-09-06 12:14 ` Konrad Dybcio
2023-09-13 1:29 ` Mike Tipton
2023-09-13 8:31 ` Konrad Dybcio
2023-09-14 2:32 ` Mike Tipton
2023-09-15 13:43 ` Konrad Dybcio [this message]
2023-09-15 16:05 ` Mike Tipton
2023-09-16 0:54 ` Konrad Dybcio
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=978fd46d-8142-41e6-9c62-df678018d6c2@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cros-qcom-dts-watchers@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=djakov@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_mdtipton@quicinc.com \
--cc=robh+dt@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
all inboxes | Powered by JetHome®