| Message ID | 84742b96802d94da00006be8d51cadce4ae04f9f.1599974998.git.saiprakash.ranjan@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | soc: qcom: llcc: Support chipsets that can write to llcc regs | expand |
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 ( > 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.
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
Quoting Sai Prakash Ranjan (2020-09-14 22:22:45) > > 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. I think my MUA has a hard time sometimes. I don't know how to fix it besides switching away from it to something else. Seems that it can't handle UTF-8 encoding properly and sends the wrong content-type headers. > > [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. > The lore stuff seems slow sometimes. I see it on lore now: https://lore.kernel.org/r/160010909573.4188128.171199552773965552@swboyd.mtv.corp.google.com https://lore.kernel.org/r/160010921920.4188128.15524650302574745988@swboyd.mtv.corp.google.com maybe I'm hitting spam filters and have to be allowed through. Don't know.
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 @@ -45,6 +45,9 @@ #define LLCC_TRP_ATTR0_CFGn(n) (0x21000 + SZ_8 * n) #define LLCC_TRP_ATTR1_CFGn(n) (0x21004 + SZ_8 * n) +#define LLCC_TRP_SCID_DIS_CAP_ALLOC 0x21f00 +#define LLCC_TRP_PCB_ACT 0x21f04 + #define BANK_OFFSET_STRIDE 0x80000 /** @@ -89,6 +92,7 @@ struct llcc_slice_config { struct qcom_llcc_config { const struct llcc_slice_config *sct_data; int size; + bool need_llcc_cfg; }; static const struct llcc_slice_config sc7180_data[] = { @@ -122,11 +126,13 @@ static const struct llcc_slice_config sdm845_data[] = { static const struct qcom_llcc_config sc7180_cfg = { .sct_data = sc7180_data, .size = ARRAY_SIZE(sc7180_data), + .need_llcc_cfg = true, }; static const struct qcom_llcc_config sdm845_cfg = { .sct_data = sdm845_data, .size = ARRAY_SIZE(sdm845_data), + .need_llcc_cfg = false, }; static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER; @@ -359,7 +365,8 @@ static int qcom_llcc_attr_cfg(const struct llcc_slice_config *table) return ret; } -static int qcom_llcc_cfg_program(struct platform_device *pdev) +static int qcom_llcc_cfg_program(struct platform_device *pdev, + const struct qcom_llcc_config *cfg) { int i; u32 sz; @@ -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); @@ -484,7 +507,7 @@ static int qcom_llcc_probe(struct platform_device *pdev) mutex_init(&drv_data->lock); platform_set_drvdata(pdev, drv_data); - ret = qcom_llcc_cfg_program(pdev); + ret = qcom_llcc_cfg_program(pdev, cfg); if (ret) goto err;