From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Georgi Djakov <djakov@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Thara Gopinath <thara.gopinath@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/7] soc: qcom: icc-bwmon: Handle global registers correctly
Date: Wed, 15 Mar 2023 11:13:44 +0100 [thread overview]
Message-ID: <dc831034-98ec-9d8c-1220-9934c9d5b79e@linaro.org> (raw)
In-Reply-To: <7a143671-372a-3af8-7804-fe12f858f853@linaro.org>
On 15.03.2023 08:27, Krzysztof Kozlowski wrote:
> On 13/03/2023 12:41, Konrad Dybcio wrote:
>> The BWMON hardware has two sets of registers: one for the monitor itself
>> and one called "global". It has what seems to be some kind of a head
>> switch and an interrupt control register. It's usually 0x200 in size.
>>
>> On fairly recent SoCs (with the starting point seemingly being moving
>> the OSM programming to the firmware) these two register sets are
>> contiguous and overlapping, like this (on sm8450):
>>
>> /* notice how base.start == global_base.start+0x100 */
>> reg = <0x90b6400 0x300>, <0x90b6300 0x200>;
>> reg-names = "base", "global_base";
>>
>> Which led to some confusion and the assumption that since the
>> "interesting" global registers begin right after global_base+0x100,
>> there's no need to map two separate regions and one can simply subtract
>> 0x100 from the offsets.
>>
>> This is however not the case for anything older than SDM845, as the
>> global region can appear in seemingly random spots on the register map.
>>
>> Handle the case where the global registers are mapped separately to allow
>> proper functioning of BWMONv4 on MSM8998 and older. Add specific
>> compatibles for 845, 8280xp, 7280 and 8550 (all of which use the single
>> reg space scheme) to keep backwards compatibility with old DTs.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
>> drivers/soc/qcom/icc-bwmon.c | 228 +++++++++++++++++++++++++++++++++++++++----
>> 1 file changed, 208 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/icc-bwmon.c b/drivers/soc/qcom/icc-bwmon.c
>> index d07be3700db6..2fe67a3cd2d7 100644
>> --- a/drivers/soc/qcom/icc-bwmon.c
>> +++ b/drivers/soc/qcom/icc-bwmon.c
>> @@ -34,14 +34,27 @@
>> /* Internal sampling clock frequency */
>> #define HW_TIMER_HZ 19200000
>>
>> -#define BWMON_V4_GLOBAL_IRQ_CLEAR 0x008
>> -#define BWMON_V4_GLOBAL_IRQ_ENABLE 0x00c
>> +#define BWMON_V4_GLOBAL_IRQ_CLEAR 0x108
>> +#define BWMON_V4_GLOBAL_IRQ_ENABLE 0x10c
>> /*
>> * All values here and further are matching regmap fields, so without absolute
>> * register offsets.
>> */
>> #define BWMON_V4_GLOBAL_IRQ_ENABLE_ENABLE BIT(0)
>>
>> +/*
>> + * Starting with SDM845, the BWMON4 register space has changed a bit:
>> + * the global registers were jammed into the beginning of the monitor region.
>> + * To keep the proper offsets, one would have to map <GLOBAL_BASE 0x200> and
>> + * <GLOBAL_BASE+0x100 0x300>, which is straight up wrong.
>> + * To facilitate for that, while allowing the older, arguably more proper
>> + * implementations to work, offset the global registers by -0x100 to avoid
>> + * having to map half of the global registers twice.
>> + */
>> +#define BWMON_V4_845_OFFSET 0x100
>> +#define BWMON_V4_GLOBAL_IRQ_CLEAR_845 (BWMON_V4_GLOBAL_IRQ_CLEAR - BWMON_V4_845_OFFSET)
>> +#define BWMON_V4_GLOBAL_IRQ_ENABLE_845 (BWMON_V4_GLOBAL_IRQ_ENABLE - BWMON_V4_845_OFFSET)
>> +
>> #define BWMON_V4_IRQ_STATUS 0x100
>> #define BWMON_V4_IRQ_CLEAR 0x108
>>
>> @@ -118,8 +131,12 @@
>> #define BWMON_NEEDS_FORCE_CLEAR BIT(1)
>>
>> enum bwmon_fields {
>> + /* Global region fields, keep them at the top */
>> F_GLOBAL_IRQ_CLEAR,
>> F_GLOBAL_IRQ_ENABLE,
>> + F_NUM_GLOBAL_FIELDS,
>> +
>> + /* Monitor region fields */
>> F_IRQ_STATUS,
>
> F_IRQ_STATUS = F_NUM_GLOBAL_FIELDS
> or = 2, so you won't waste one space in the array.
Good find!
>
>> F_IRQ_CLEAR,
>> F_IRQ_ENABLE,
>> @@ -157,6 +174,9 @@ struct icc_bwmon_data {
>>
>> const struct regmap_config *regmap_cfg;
>> const struct reg_field *regmap_fields;
>> +
>> + const struct regmap_config *global_regmap_cfg;
>> + const struct reg_field *global_regmap_fields;
>> };
>>
>> struct icc_bwmon {
>> @@ -166,6 +186,7 @@ struct icc_bwmon {
>>
>> struct regmap *regmap;
>> struct regmap_field *regs[F_NUM_FIELDS];
>> + struct regmap_field *global_regs[F_NUM_FIELDS];
>
> F_NUM_GLOBAL_FIELDS?
Totally.
>
>>
>
> (...)
>
>> }
>>
>> static int bwmon_probe(struct platform_device *pdev)
>> @@ -645,6 +816,21 @@ static const struct icc_bwmon_data msm8998_bwmon_data = {
>> .quirks = BWMON_HAS_GLOBAL_IRQ,
>> .regmap_fields = msm8998_bwmon_reg_fields,
>> .regmap_cfg = &msm8998_bwmon_regmap_cfg,
>> + .global_regmap_fields = msm8998_bwmon_global_reg_fields,
>> + .global_regmap_cfg = &msm8998_bwmon_global_regmap_cfg,
>> +};
>> +
>> +static const struct icc_bwmon_data sdm845_ddr_bwmon_data = {
>
> The name "ddr" is here (and other places) confusing. This is not the DDR
> bwmon.
I suppose cpu_bwmon could make more sense?
Konrad
>
>> + .sample_ms = 4,
>> + .count_unit_kb = 64,
>> + .default_highbw_kbps = 4800 * 1024, /* 4.8 GBps */
>> + .default_medbw_kbps = 512 * 1024, /* 512 MBps */
>> + .default_lowbw_kbps = 0,
>> + .zone1_thres_count = 16,
>> + .zone3_thres_count = 1,
>> + .quirks = BWMON_HAS_GLOBAL_IRQ,
>> + .regmap_fields = sdm845_ddr_bwmon_reg_fields,
>> + .regmap_cfg = &sdm845_ddr_bwmon_regmap_cfg,
>> };
>>
>> static const struct icc_bwmon_data sdm845_llcc_bwmon_data = {
>> @@ -673,16 +859,18 @@ static const struct icc_bwmon_data sc7280_llcc_bwmon_data = {
>> };
>>
>> static const struct of_device_id bwmon_of_match[] = {
>> - {
>> - .compatible = "qcom,msm8998-bwmon",
>> - .data = &msm8998_bwmon_data
>> - }, {
>> - .compatible = "qcom,sdm845-llcc-bwmon",
>> - .data = &sdm845_llcc_bwmon_data
>> - }, {
>> - .compatible = "qcom,sc7280-llcc-bwmon",
>> - .data = &sc7280_llcc_bwmon_data
>> - },
>> + /* BWMONv4, separate monitor and global register spaces */
>> + { .compatible = "qcom,msm8998-bwmon", .data = &msm8998_bwmon_data },
>> + /* BWMONv4, unified register space */
>> + { .compatible = "qcom,sdm845-bwmon", .data = &sdm845_ddr_bwmon_data },
>> + /* BWMONv5 */
>> + { .compatible = "qcom,sdm845-llcc-bwmon", .data = &sdm845_llcc_bwmon_data },
>> + { .compatible = "qcom,sc7280-llcc-bwmon", .data = &sc7280_llcc_bwmon_data },
>> +
>> + /* Compatibles kept for legacy reasons */
>> + { .compatible = "qcom,sc7280-cpu-bwmon", .data = &sdm845_ddr_bwmon_data },
>> + { .compatible = "qcom,sc8280xp-cpu-bwmon", .data = &sdm845_ddr_bwmon_data },
>> + { .compatible = "qcom,sm8550-cpu-bwmon", .data = &sdm845_ddr_bwmon_data },
>> {}
>> };
>> MODULE_DEVICE_TABLE(of, bwmon_of_match);
>>
>
> Best regards,
> Krzysztof
>
next prev parent reply other threads:[~2023-03-15 10:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-13 11:41 [PATCH v2 0/7] Fix BWMONv4 for <SDM845 Konrad Dybcio
2023-03-13 11:41 ` [PATCH v2 1/7] dt-bindings: interconnect: qcom,msm8998-bwmon: Resolve MSM8998 support Konrad Dybcio
2023-03-15 7:21 ` Krzysztof Kozlowski
2023-03-13 11:41 ` [PATCH v2 2/7] soc: qcom: icc-bwmon: Handle global registers correctly Konrad Dybcio
2023-03-15 7:27 ` Krzysztof Kozlowski
2023-03-15 10:13 ` Konrad Dybcio [this message]
2023-03-15 13:15 ` Krzysztof Kozlowski
2023-03-13 11:41 ` [PATCH v2 3/7] soc: qcom: icc-bwmon: Remove unused struct member Konrad Dybcio
2023-03-15 7:27 ` Krzysztof Kozlowski
2023-03-13 11:41 ` [PATCH v2 4/7] arm64: dts: qcom: sc7280: Use the correct BWMON fallback compatible Konrad Dybcio
2023-03-15 7:27 ` Krzysztof Kozlowski
2023-03-13 11:41 ` [PATCH v2 5/7] arm64: dts: qcom: sc8280xp: " Konrad Dybcio
2023-03-15 7:28 ` Krzysztof Kozlowski
2023-03-13 11:41 ` [PATCH v2 6/7] arm64: dts: qcom: sdm845: Use the correct BWMON compatible Konrad Dybcio
2023-03-15 7:28 ` Krzysztof Kozlowski
2023-03-13 11:41 ` [PATCH v2 7/7] arm64: dts: qcom: sm8550: Use the correct BWMON fallback compatible Konrad Dybcio
2023-03-15 7:28 ` Krzysztof Kozlowski
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=dc831034-98ec-9d8c-1220-9934c9d5b79e@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=djakov@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=thara.gopinath@gmail.com \
/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®