From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> To: Stephen Boyd <swboyd@chromium.org> Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Douglas Anderson <dianders@chromium.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, "Isaac J. Manjarres" <isaacm@codeaurora.org> Subject: Re: [PATCHv4 2/2] soc: qcom: llcc: Support chipsets that can write to llcc regs Date: Tue, 15 Sep 2020 10:52:45 +0530 [thread overview] Message-ID: <590f9bacf06d735a7961ddb8234299ca@codeaurora.org> (raw) In-Reply-To: <160010921920.4188128.15524650302574745988@swboyd.mtv.corp.google.com> On 2020-09-15 00:16, Stephen Boyd wrote: > Quoting Sai Prakash Ranjan (2020-09-14 04:13:00) >> From: "Isaac J. Manjarres" <isaacm@codeaurora.org> >> >> Older chipsets may not be allowed to configure certain LLCC registers >> as that is handled by the secure side software. However, this is not >> the case for newer chipsets and they must configure these registers >> according to the contents of the SCT table, while keeping in mind that >> older targets may not have these capabilities. So add support to allow >> such configuration of registers to enable capacity based allocation >> and power collapse retention for capable chipsets. >> >> Reason for choosing capacity based allocation rather than the default >> way based allocation is because capacity based allocation allows more >> finer grain partition and provides more flexibility in configuration. >> As for the retention through power collapse, it has an advantage where >> the cache hits are more when we wake up from power collapse although >> it does burn more power but the exact power numbers are not known at >> the moment. >> >> Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org> >> Reviewed-by: Douglas Anderson <dianders@chromium.org> >> (saiprakash.ranjan@codeaurora.org: use existing config and reword >> commit msg) > > Should be [ not ( > Ok >> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> >> --- >> drivers/soc/qcom/llcc-qcom.c | 27 +++++++++++++++++++++++++-- >> 1 file changed, 25 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/soc/qcom/llcc-qcom.c >> b/drivers/soc/qcom/llcc-qcom.c >> index 60ee31842dea..6aedccff49bb 100644 >> --- a/drivers/soc/qcom/llcc-qcom.c >> +++ b/drivers/soc/qcom/llcc-qcom.c >> @@ -375,6 +382,22 @@ static int qcom_llcc_cfg_program(struct >> platform_device *pdev) >> if (ret) >> return ret; >> >> + if (cfg->need_llcc_cfg) { >> + u32 disable_cap_alloc, retain_pc; >> + >> + disable_cap_alloc = >> llcc_table[i].dis_cap_alloc << llcc_table[i].slice_id; >> + ret = regmap_write(drv_data->bcast_regmap, >> + LLCC_TRP_SCID_DIS_CAP_ALLOC, >> disable_cap_alloc); >> + if (ret) >> + return ret; >> + >> + retain_pc = llcc_table[i].retain_on_pc << >> llcc_table[i].slice_id; >> + ret = regmap_write(drv_data->bcast_regmap, >> + LLCC_TRP_PCB_ACT, retain_pc); >> + if (ret) >> + return ret; >> + } >> + >> if (llcc_table[i].activate_on_init) { >> desc.slice_id = llcc_table[i].slice_id; >> ret = llcc_slice_activate(&desc); > > I thought all of this stuff would move into the config function. So the > for loop is simplified to a function call and return if failure. The config function was specifically for attribute config not for other llcc configs like these, so I will rename qcom_llcc_attr_cfg() to _qcom_llcc_cfg_program() and move everything there. As a side note, I have your mails in my inbox but these messages are not appearing in the list [1]. For Patch 2, its on the list [2]. I have noticed same thing on your messages for previous patches, where your reply for one patch was on the list but the other one was missing, you might have to check that. [1] https://lore.kernel.org/patchwork/patch/1305132/ [2] https://lore.kernel.org/patchwork/patch/1305133/ Same with lore.kernel.org/lkml/ links but since url was big, I gave the above patchwork links. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> To: Stephen Boyd <swboyd@chromium.org> Cc: "Isaac J. Manjarres" <isaacm@codeaurora.org>, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Douglas Anderson <dianders@chromium.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCHv4 2/2] soc: qcom: llcc: Support chipsets that can write to llcc regs Date: Tue, 15 Sep 2020 10:52:45 +0530 [thread overview] Message-ID: <590f9bacf06d735a7961ddb8234299ca@codeaurora.org> (raw) In-Reply-To: <160010921920.4188128.15524650302574745988@swboyd.mtv.corp.google.com> On 2020-09-15 00:16, Stephen Boyd wrote: > Quoting Sai Prakash Ranjan (2020-09-14 04:13:00) >> From: "Isaac J. Manjarres" <isaacm@codeaurora.org> >> >> Older chipsets may not be allowed to configure certain LLCC registers >> as that is handled by the secure side software. However, this is not >> the case for newer chipsets and they must configure these registers >> according to the contents of the SCT table, while keeping in mind that >> older targets may not have these capabilities. So add support to allow >> such configuration of registers to enable capacity based allocation >> and power collapse retention for capable chipsets. >> >> Reason for choosing capacity based allocation rather than the default >> way based allocation is because capacity based allocation allows more >> finer grain partition and provides more flexibility in configuration. >> As for the retention through power collapse, it has an advantage where >> the cache hits are more when we wake up from power collapse although >> it does burn more power but the exact power numbers are not known at >> the moment. >> >> Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org> >> Reviewed-by: Douglas Anderson <dianders@chromium.org> >> (saiprakash.ranjan@codeaurora.org: use existing config and reword >> commit msg) > > Should be [ not ( > Ok >> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> >> --- >> drivers/soc/qcom/llcc-qcom.c | 27 +++++++++++++++++++++++++-- >> 1 file changed, 25 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/soc/qcom/llcc-qcom.c >> b/drivers/soc/qcom/llcc-qcom.c >> index 60ee31842dea..6aedccff49bb 100644 >> --- a/drivers/soc/qcom/llcc-qcom.c >> +++ b/drivers/soc/qcom/llcc-qcom.c >> @@ -375,6 +382,22 @@ static int qcom_llcc_cfg_program(struct >> platform_device *pdev) >> if (ret) >> return ret; >> >> + if (cfg->need_llcc_cfg) { >> + u32 disable_cap_alloc, retain_pc; >> + >> + disable_cap_alloc = >> llcc_table[i].dis_cap_alloc << llcc_table[i].slice_id; >> + ret = regmap_write(drv_data->bcast_regmap, >> + LLCC_TRP_SCID_DIS_CAP_ALLOC, >> disable_cap_alloc); >> + if (ret) >> + return ret; >> + >> + retain_pc = llcc_table[i].retain_on_pc << >> llcc_table[i].slice_id; >> + ret = regmap_write(drv_data->bcast_regmap, >> + LLCC_TRP_PCB_ACT, retain_pc); >> + if (ret) >> + return ret; >> + } >> + >> if (llcc_table[i].activate_on_init) { >> desc.slice_id = llcc_table[i].slice_id; >> ret = llcc_slice_activate(&desc); > > I thought all of this stuff would move into the config function. So the > for loop is simplified to a function call and return if failure. The config function was specifically for attribute config not for other llcc configs like these, so I will rename qcom_llcc_attr_cfg() to _qcom_llcc_cfg_program() and move everything there. As a side note, I have your mails in my inbox but these messages are not appearing in the list [1]. For Patch 2, its on the list [2]. I have noticed same thing on your messages for previous patches, where your reply for one patch was on the list but the other one was missing, you might have to check that. [1] https://lore.kernel.org/patchwork/patch/1305132/ [2] https://lore.kernel.org/patchwork/patch/1305133/ Same with lore.kernel.org/lkml/ links but since url was big, I gave the above patchwork links. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-09-15 5:22 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-14 11:12 [PATCHv4 0/2] soc: qcom: llcc: Support chipsets that can write to llcc regs Sai Prakash Ranjan 2020-09-14 11:12 ` Sai Prakash Ranjan 2020-09-14 11:12 ` [PATCHv4 1/2] soc: qcom: llcc: Move attribute config to its own function Sai Prakash Ranjan 2020-09-14 11:12 ` Sai Prakash Ranjan 2020-09-14 18:44 ` Stephen Boyd 2020-09-14 18:44 ` Stephen Boyd 2020-09-15 5:25 ` Sai Prakash Ranjan 2020-09-15 5:25 ` Sai Prakash Ranjan 2020-09-14 11:13 ` [PATCHv4 2/2] soc: qcom: llcc: Support chipsets that can write to llcc regs Sai Prakash Ranjan 2020-09-14 11:13 ` Sai Prakash Ranjan 2020-09-14 18:46 ` Stephen Boyd 2020-09-15 5:22 ` Sai Prakash Ranjan [this message] 2020-09-15 5:22 ` Sai Prakash Ranjan 2020-09-15 16:01 ` Stephen Boyd
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=590f9bacf06d735a7961ddb8234299ca@codeaurora.org \ --to=saiprakash.ranjan@codeaurora.org \ --cc=agross@kernel.org \ --cc=bjorn.andersson@linaro.org \ --cc=dianders@chromium.org \ --cc=isaacm@codeaurora.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=swboyd@chromium.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: linkBe 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.