soc: qcom: llcc: Support chipsets that can write to llcc regs
Subsystems (2)
v4 cover soc: qcom: llcc: Support chipsets that can write to llcc regs
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.
Patch 1 is a cleanup to separate out llcc attribute configuration to its own function.
Patch 2 adds support for chipsets capable of writing to llcc registers.
Changes in v4:
* Separate out llcc attribute config to its own function (Stephen)
* Pass qcom_llcc_config instead of a new llcc_drvdata property (Doug)
Changes in v3:
* Drop separate table and use existing qcom_llcc_config (Doug)
* More descriptive commit msg (Doug)
* Directly set the config instead of '|=' (Doug)
Changes in v2:
* Fix build errors reported by kernel test robot.
Isaac J. Manjarres (1):
soc: qcom: llcc: Support chipsets that can write to llcc
Sai Prakash Ranjan (1):
soc: qcom: llcc: Move attribute config to its own function
drivers/soc/qcom/llcc-qcom.c | 100 +++++++++++++++++++++++------------ 1 file changed, 65 insertions(+), 35 deletions(-)
base-commit: 75894849c81ab9a2e9df2e8cf2f9c52035cd22a0
Signature · 2 lines
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
PATCH v4 1/2 soc: qcom: llcc: Move attribute config to its own function
Cleanup qcom_llcc_cfg_program() by moving llcc attribute configuration to a separate function of its own. Also correct misspelled 'instance' caught by checkpatch.
--- drivers/soc/qcom/llcc-qcom.c | 75 ++++++++++++++++++++---------------- 1 file changed, 41 insertions(+), 34 deletions(-)
drivers/soc/qcom/llcc-qcom.c +41 -34
@@ -318,14 +318,50 @@ size_t llcc_get_slice_size(struct llcc_slice_desc *desc) }EXPORT_SYMBOL_GPL (llcc_get_slice_size); -static int qcom_llcc_cfg_program (struct platform_device *pdev) +static int qcom_llcc_attr_cfg (const struct llcc_slice_config *table) { -int i;u32 attr1_cfg;u32 attr0_cfg;u32 attr1_val;u32 attr0_val;u32 max_cap_cacheline; +int ret; + + attr1_cfg =LLCC_TRP_ATTR1_CFGn (table->slice_id); + attr0_cfg =LLCC_TRP_ATTR0_CFGn (table->slice_id); + + attr1_val = table->cache_mode; + attr1_val |= table->probe_target_ways <<ATTR1_PROBE_TARGET_WAYS_SHIFT ; + attr1_val |= table->fixed_size <<ATTR1_FIXED_SIZE_SHIFT ; + attr1_val |= table->priority <<ATTR1_PRIORITY_SHIFT ; + + max_cap_cacheline =MAX_CAP_TO_BYTES (table->max_cap); + +/* LLCC instances can vary for each target. +* The SW writes to broadcast register which gets propagated +* to each llcc instance (llcc0,.. llccN). +* Since the size of the memory is divided equally amongst the +* llcc instances, we need to configure the max cap accordingly. +*/ + max_cap_cacheline = max_cap_cacheline / drv_data->num_banks; + max_cap_cacheline >>=CACHE_LINE_SIZE_SHIFT ; + attr1_val |= max_cap_cacheline <<ATTR1_MAX_CAP_SHIFT ; + + attr0_val = table->res_ways &ATTR0_RES_WAYS_MASK ; + attr0_val |= table->bonus_ways <<ATTR0_BONUS_WAYS_SHIFT ; + + ret =regmap_write (drv_data->bcast_regmap, attr1_cfg, attr1_val); +if (ret) +return ret; + + ret =regmap_write (drv_data->bcast_regmap, attr0_cfg, attr0_val); + +return ret; +} + +static int qcom_llcc_cfg_program (struct platform_device *pdev) +{ +int i;u32 sz;int ret =0 ;const struct llcc_slice_config *llcc_table;
@@ -335,45 +371,16 @@ static int qcom_llcc_cfg_program(struct platform_device *pdev) llcc_table = drv_data->cfg;for (i =0 ; i < sz; i++) { - attr1_cfg =LLCC_TRP_ATTR1_CFGn (llcc_table[i].slice_id); - attr0_cfg =LLCC_TRP_ATTR0_CFGn (llcc_table[i].slice_id); - - attr1_val = llcc_table[i].cache_mode; - attr1_val |= llcc_table[i].probe_target_ways << -ATTR1_PROBE_TARGET_WAYS_SHIFT ; - attr1_val |= llcc_table[i].fixed_size << -ATTR1_FIXED_SIZE_SHIFT ; - attr1_val |= llcc_table[i].priority << -ATTR1_PRIORITY_SHIFT ; - - max_cap_cacheline =MAX_CAP_TO_BYTES (llcc_table[i].max_cap); - -/* LLCC instances can vary for each target. -* The SW writes to broadcast register which gets propagated -* to each llcc instace (llcc0,.. llccN). -* Since the size of the memory is divided equally amongst the -* llcc instances, we need to configure the max cap accordingly. -*/ - max_cap_cacheline = max_cap_cacheline / drv_data->num_banks; - max_cap_cacheline >>=CACHE_LINE_SIZE_SHIFT ; - attr1_val |= max_cap_cacheline <<ATTR1_MAX_CAP_SHIFT ; - - attr0_val = llcc_table[i].res_ways &ATTR0_RES_WAYS_MASK ; - attr0_val |= llcc_table[i].bonus_ways <<ATTR0_BONUS_WAYS_SHIFT ; - - ret =regmap_write (drv_data->bcast_regmap, attr1_cfg, - attr1_val); -if (ret) -return ret; - ret =regmap_write (drv_data->bcast_regmap, attr0_cfg, - attr0_val); + ret =qcom_llcc_attr_cfg (&llcc_table[i]);if (ret)return ret; +if (llcc_table[i].activate_on_init) { desc.slice_id = llcc_table[i].slice_id; ret =llcc_slice_activate (&desc); } } +return ret; }
Signature · 2 lines
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCHv4 1/2] soc: qcom: llcc: Move attribute config to its own function
Quoting Sai Prakash Ranjan (2020-09-14 04:12:59)
Quoted 15 lines
Cleanup
qcom_llcc_cfg_program()by moving llcc attribute configuration to a separate function of its own. Also correct misspelled 'instance' caught by checkpatch.Suggested-by Stephen Boyd <[email protected]>Signed-off-by Sai Prakash Ranjan <[email protected]>--- drivers/soc/qcom/llcc-qcom.c | 75 ++++++++++++++++++++---------------- 1 file changed, 41 insertions(+), 34 deletions(-)drivers/soc/qcom/llcc-qcom.c +0
-0
drivers/soc/qcom/llcc-qcom.c size_t llcc_get_slice_size(struct llcc_slice_desc *desc) · line 321
Quoted 5 lines
drivers/soc/qcom/llcc-qcom.c +1
-1@@ -318,14 +318,50 @@ size_t llcc_get_slice_size(struct llcc_slice_desc *desc) }EXPORT_SYMBOL_GPL (llcc_get_slice_size); -static int qcom_llcc_cfg_program (struct platform_device *pdev) +static int qcom_llcc_attr_cfg (const struct llcc_slice_config *table)
Call it config? It's certainly not a table.
drivers/soc/qcom/llcc-qcom.c size_t llcc_get_slice_size(struct llcc_slice_desc *desc) · line 331
Quoted 11 lines
drivers/soc/qcom/llcc-qcom.c +4
-1{ -int i;u32 attr1_cfg;u32 attr0_cfg;u32 attr1_val;u32 attr0_val;u32 max_cap_cacheline; +int ret; + + attr1_cfg =LLCC_TRP_ATTR1_CFGn (table->slice_id); + attr0_cfg =LLCC_TRP_ATTR0_CFGn (table->slice_id);
Can this move down to near where it is used?
drivers/soc/qcom/llcc-qcom.c size_t llcc_get_slice_size(struct llcc_slice_desc *desc) · line 340
Quoted 9 lines
drivers/soc/qcom/llcc-qcom.c +9
-0+ + attr1_val = table->cache_mode; + attr1_val |= table->probe_target_ways <<ATTR1_PROBE_TARGET_WAYS_SHIFT ; + attr1_val |= table->fixed_size <<ATTR1_FIXED_SIZE_SHIFT ; + attr1_val |= table->priority <<ATTR1_PRIORITY_SHIFT ; + + max_cap_cacheline =MAX_CAP_TO_BYTES (table->max_cap); + +/* LLCC instances can vary for each target.
The /* should be on a line by itself.
Quoted 9 lines
drivers/soc/qcom/llcc-qcom.c +9
-0+* The SW writes to broadcast register which gets propagated +* to each llcc instance (llcc0,.. llccN). +* Since the size of the memory is divided equally amongst the +* llcc instances, we need to configure the max cap accordingly. +*/ + max_cap_cacheline = max_cap_cacheline / drv_data->num_banks; + max_cap_cacheline >>=CACHE_LINE_SIZE_SHIFT ; + attr1_val |= max_cap_cacheline <<ATTR1_MAX_CAP_SHIFT ; +
drivers/soc/qcom/llcc-qcom.c size_t llcc_get_slice_size(struct llcc_slice_desc *desc) · line 359
Quoted 10 lines
drivers/soc/qcom/llcc-qcom.c +10
-0+ attr0_val = table->res_ways &ATTR0_RES_WAYS_MASK ; + attr0_val |= table->bonus_ways <<ATTR0_BONUS_WAYS_SHIFT ; + + ret =regmap_write (drv_data->bcast_regmap, attr1_cfg, attr1_val); +if (ret) +return ret; + + ret =regmap_write (drv_data->bcast_regmap, attr0_cfg, attr0_val); + +return ret;
return regmap_write(...)
Quoted 8 lines
drivers/soc/qcom/llcc-qcom.c +5
-0+} + +static int qcom_llcc_cfg_program (struct platform_device *pdev) +{ +int i;u32 sz;int ret =0 ;const struct llcc_slice_config *llcc_table;
Re: [PATCHv4 1/2] soc: qcom: llcc: Move attribute config to its own function
Quoted 21 lines · Stephen Boyd
Quoting Sai Prakash Ranjan (2020-09-14 04:12:59)
Quoted 20 lines
Cleanup
qcom_llcc_cfg_program()by moving llcc attribute configuration to a separate function of its own. Also correct misspelled 'instance' caught by checkpatch.Suggested-by Stephen Boyd <[email protected]>Signed-off-by Sai Prakash Ranjan <[email protected]>--- drivers/soc/qcom/llcc-qcom.c | 75 ++++++++++++++++++++---------------- 1 file changed, 41 insertions(+), 34 deletions(-)drivers/soc/qcom/llcc-qcom.c +0
-0@@ -318,14 +318,50 @@ size_t llcc_get_slice_size(struct llcc_slice_desc *desc) }EXPORT_SYMBOL_GPL (llcc_get_slice_size);
Quoted 5 lines
drivers/soc/qcom/llcc-qcom.c size_t llcc_get_slice_size(struct llcc_slice_desc *desc) · line 321
Quoted 2 lines
drivers/soc/qcom/llcc-qcom.c +1
-1-static int qcom_llcc_cfg_program (struct platform_device *pdev) +static int qcom_llcc_attr_cfg (const struct llcc_slice_config *table)Call it config? It's certainly not a table.
Yes, will do.
Quoted 12 lines
drivers/soc/qcom/llcc-qcom.c size_t llcc_get_slice_size(struct llcc_slice_desc *desc) · line 331
Quoted 11 lines
drivers/soc/qcom/llcc-qcom.c +4
-1{ -int i;u32 attr1_cfg;u32 attr0_cfg;u32 attr1_val;u32 attr0_val;u32 max_cap_cacheline; +int ret; + + attr1_cfg =LLCC_TRP_ATTR1_CFGn (table->slice_id); + attr0_cfg =LLCC_TRP_ATTR0_CFGn (table->slice_id);
Quoted 2 lines
Can this move down to near where it is used?
Sure.
Quoted 4 lines
Quoted 4 lines
drivers/soc/qcom/llcc-qcom.c +3
-0+ + attr1_val = table->cache_mode; + attr1_val |= table->probe_target_ways <<ATTR1_PROBE_TARGET_WAYS_SHIFT ;
Quoted 9 lines
drivers/soc/qcom/llcc-qcom.c size_t llcc_get_slice_size(struct llcc_slice_desc *desc) · line 340
Quoted 6 lines
drivers/soc/qcom/llcc-qcom.c +6
-0+ attr1_val |= table->fixed_size <<ATTR1_FIXED_SIZE_SHIFT ; + attr1_val |= table->priority <<ATTR1_PRIORITY_SHIFT ; + + max_cap_cacheline =MAX_CAP_TO_BYTES (table->max_cap); + +/* LLCC instances can vary for each target. The /* should be on a line by itself.
This was there before I moved this hunk but I will fix it.
Quoted 16 lines
Quoted 16 lines
drivers/soc/qcom/llcc-qcom.c +4
-0+* The SW writes to broadcast register which gets propagated +* to each llcc instance (llcc0,.. llccN). +* Since the size of the memory is divided equally amongst the +* llcc instances, we need to configure the max cap accordingly.
drivers/soc/qcom/llcc-qcom.c +9
-0+*/ + max_cap_cacheline = max_cap_cacheline / drv_data->num_banks; + max_cap_cacheline >>=CACHE_LINE_SIZE_SHIFT ; + attr1_val |= max_cap_cacheline <<ATTR1_MAX_CAP_SHIFT ; + + attr0_val = table->res_ways &ATTR0_RES_WAYS_MASK ; + attr0_val |= table->bonus_ways <<ATTR0_BONUS_WAYS_SHIFT ; + + ret = regmap_write(drv_data->bcast_regmap, attr1_cfg,
attr1_val);
+ if (ret)
Quoted 9 lines
drivers/soc/qcom/llcc-qcom.c
Quoted 6 lines
drivers/soc/qcom/llcc-qcom.c +3
-0+return ret; + + ret = regmap_write(drv_data->bcast_regmap, attr0_cfg,
attr0_val);drivers/soc/qcom/llcc-qcom.c +2
-0+ +return ret;return
regmap_write(...)
Ok done.
Thanks,
Sai
Signature · 2 lines
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
PATCH v4 2/2 soc: qcom: llcc: Support chipsets that can write to llcc regs
In reply to Sai Prakash RanjanFrom: "Isaac J. Manjarres" <[email protected]>
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.
([email protected]: use existing config and reword commit msg)
--- drivers/soc/qcom/llcc-qcom.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-)
drivers/soc/qcom/llcc-qcom.c +25 -2
@@ -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;
Signature · 2 lines
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Quoting Sai Prakash Ranjan (2020-09-14 04:13:00)
Quoted 18 lines
From: "Isaac J. Manjarres" <[email protected]>
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.
Quoted 3 lines
Signed-off-by Isaac J. Manjarres <[email protected]>Reviewed-by Douglas Anderson <[email protected]>([email protected]: use existing config and reword commit msg)
Should be [ not (
Quoted 22 lines
Signed-off-by Sai Prakash Ranjan <[email protected]>--- drivers/soc/qcom/llcc-qcom.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-)drivers/soc/qcom/llcc-qcom.c +9
-0@@ -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; +
drivers/soc/qcom/llcc-qcom.c static int qcom_llcc_cfg_program(struct platform_device *pdev) · line 403
Quoted 10 lines
drivers/soc/qcom/llcc-qcom.c +7
-0+ 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.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 19 lines · Stephen Boyd
Quoting Sai Prakash Ranjan (2020-09-14 04:13:00)
Quoted 18 lines
From: "Isaac J. Manjarres" <[email protected]>
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.
Quoted 6 lines
Quoted 3 lines
Signed-off-by Isaac J. Manjarres <[email protected]>Reviewed-by Douglas Anderson <[email protected]>([email protected]: use existing config and reword commit msg)
Should be [ not (
Ok
Quoted 31 lines
Quoted 31 lines
Signed-off-by Sai Prakash Ranjan <[email protected]>--- drivers/soc/qcom/llcc-qcom.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-)drivers/soc/qcom/llcc-qcom.c +10
-0@@ -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;
drivers/soc/qcom/llcc-qcom.c +4
-0+ ret =regmap_write (drv_data->bcast_regmap, +LLCC_TRP_PCB_ACT , retain_pc); +if (ret) +return ret;
Quoted 8 lines
drivers/soc/qcom/llcc-qcom.c static int qcom_llcc_cfg_program(struct platform_device *pdev) · line 403
Quoted 5 lines
drivers/soc/qcom/llcc-qcom.c +2
-0+ } +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
Signature · 2 lines
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Quoting Sai Prakash Ranjan (2020-09-14 22:22:45)
Quoted 7 lines
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.
Quoted 7 lines
[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.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel