v4: Moved code from probe/remove/runtime_suspend into
different pm_ops callbacks
v3: Renamed the optional power domain as cx
v2: Fixed up the labels of OPP nodes in patch 4
Included the bindings update patch as part of this series,
a resend of https://lore.kernel.org/patchwork/patch/1241077/
These patches add DVFS support for Venus
Patch 1 will need to be picked by Rob.
Patch 2 and 3 will need to be picked by Stan,
Patch 4 and 5 should land via the qcom tree.
Rajendra Nayak (5):
dt-bindings: media: venus: Add an optional power domain for perf
voting
media: venus: core: Fix error handling in probe
media: venus: core: Add support for opp tables/perf voting
arm64: dts: sdm845: Add OPP tables and power-domains for venus
arm64: dts: sc7180: Add OPP tables and power-domains for venus
.../bindings/media/qcom,sc7180-venus.yaml | 6 +-
.../bindings/media/qcom,sdm845-venus-v2.yaml | 6 +-
arch/arm64/boot/dts/qcom/sc7180.dtsi | 35 +++++++-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 +++++++++-
drivers/media/platform/qcom/venus/core.c | 17 ++--
drivers/media/platform/qcom/venus/core.h | 5 ++
drivers/media/platform/qcom/venus/pm_helpers.c | 92 ++++++++++++++++++++--
7 files changed, 183 insertions(+), 18 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Add support to add OPP tables and perf voting on the OPP powerdomain.
This is needed so venus votes on the corresponding performance state
for the OPP powerdomain along with setting the core clock rate.
Signed-off-by: Rajendra Nayak <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
---
drivers/media/platform/qcom/venus/core.c | 2 +
drivers/media/platform/qcom/venus/core.h | 5 ++
drivers/media/platform/qcom/venus/pm_helpers.c | 92 ++++++++++++++++++++++++--
3 files changed, 92 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index bfcaba3..a3e98a5 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -525,6 +525,7 @@ static const struct venus_resources sdm845_res_v2 = {
.vcodec_clks_num = 2,
.vcodec_pmdomains = { "venus", "vcodec0", "vcodec1" },
.vcodec_pmdomains_num = 3,
+ .opp_pmdomain = (const char *[]) { "cx", NULL },
.vcodec_num = 2,
.max_load = 3110400, /* 4096x2160@90 */
.hfi_version = HFI_VERSION_4XX,
@@ -570,6 +571,7 @@ static const struct venus_resources sc7180_res = {
.vcodec_clks_num = 2,
.vcodec_pmdomains = { "venus", "vcodec0" },
.vcodec_pmdomains_num = 2,
+ .opp_pmdomain = (const char *[]) { "cx", NULL },
.vcodec_num = 1,
.hfi_version = HFI_VERSION_4XX,
.vmem_id = VIDC_RESOURCE_NONE,
diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
index 7118612..b0cc544 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -62,6 +62,7 @@ struct venus_resources {
unsigned int vcodec_clks_num;
const char * const vcodec_pmdomains[VIDC_PMDOMAINS_NUM_MAX];
unsigned int vcodec_pmdomains_num;
+ const char **opp_pmdomain;
unsigned int vcodec_num;
enum hfi_version hfi_version;
u32 max_load;
@@ -145,8 +146,12 @@ struct venus_core {
struct clk *vcodec1_clks[VIDC_VCODEC_CLKS_NUM_MAX];
struct icc_path *video_path;
struct icc_path *cpucfg_path;
+ struct opp_table *opp_table;
+ bool has_opp_table;
struct device_link *pd_dl_venus;
struct device *pmdomains[VIDC_PMDOMAINS_NUM_MAX];
+ struct device_link *opp_dl_venus;
+ struct device *opp_pmdomain;
struct video_device *vdev_dec;
struct video_device *vdev_enc;
struct v4l2_device v4l2_dev;
diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
index abf9315..0308d20 100644
--- a/drivers/media/platform/qcom/venus/pm_helpers.c
+++ b/drivers/media/platform/qcom/venus/pm_helpers.c
@@ -9,6 +9,7 @@
#include <linux/iopoll.h>
#include <linux/kernel.h>
#include <linux/pm_domain.h>
+#include <linux/pm_opp.h>
#include <linux/pm_runtime.h>
#include <linux/types.h>
#include <media/v4l2-mem2mem.h>
@@ -66,10 +67,9 @@ static void core_clks_disable(struct venus_core *core)
static int core_clks_set_rate(struct venus_core *core, unsigned long freq)
{
- struct clk *clk = core->clks[0];
int ret;
- ret = clk_set_rate(clk, freq);
+ ret = dev_pm_opp_set_rate(core->dev, freq);
if (ret)
return ret;
@@ -740,13 +740,16 @@ static int venc_power_v4(struct device *dev, int on)
static int vcodec_domains_get(struct device *dev)
{
+ int ret;
+ struct opp_table *opp_table;
+ struct device **opp_virt_dev;
struct venus_core *core = dev_get_drvdata(dev);
const struct venus_resources *res = core->res;
struct device *pd;
unsigned int i;
if (!res->vcodec_pmdomains_num)
- return -ENODEV;
+ goto skip_pmdomains;
for (i = 0; i < res->vcodec_pmdomains_num; i++) {
pd = dev_pm_domain_attach_by_name(dev,
@@ -763,7 +766,41 @@ static int vcodec_domains_get(struct device *dev)
if (!core->pd_dl_venus)
return -ENODEV;
+skip_pmdomains:
+ if (!core->has_opp_table)
+ return 0;
+
+ /* Attach the power domain for setting performance state */
+ opp_table = dev_pm_opp_attach_genpd(dev, res->opp_pmdomain, &opp_virt_dev);
+ if (IS_ERR(opp_table)) {
+ ret = PTR_ERR(opp_table);
+ goto opp_attach_err;
+ }
+
+ core->opp_pmdomain = *opp_virt_dev;
+ core->opp_dl_venus = device_link_add(dev, core->opp_pmdomain,
+ DL_FLAG_RPM_ACTIVE |
+ DL_FLAG_PM_RUNTIME |
+ DL_FLAG_STATELESS);
+ if (!core->opp_dl_venus) {
+ ret = -ENODEV;
+ goto opp_dl_add_err;
+ }
+
return 0;
+
+opp_dl_add_err:
+ dev_pm_domain_detach(core->opp_pmdomain, true);
+opp_attach_err:
+ if (core->pd_dl_venus) {
+ device_link_del(core->pd_dl_venus);
+ for (i = 0; i < res->vcodec_pmdomains_num; i++) {
+ if (IS_ERR_OR_NULL(core->pmdomains[i]))
+ continue;
+ dev_pm_domain_detach(core->pmdomains[i], true);
+ }
+ }
+ return ret;
}
static void vcodec_domains_put(struct device *dev)
@@ -773,7 +810,7 @@ static void vcodec_domains_put(struct device *dev)
unsigned int i;
if (!res->vcodec_pmdomains_num)
- return;
+ goto skip_pmdomains;
if (core->pd_dl_venus)
device_link_del(core->pd_dl_venus);
@@ -783,6 +820,15 @@ static void vcodec_domains_put(struct device *dev)
continue;
dev_pm_domain_detach(core->pmdomains[i], true);
}
+
+skip_pmdomains:
+ if (!core->has_opp_table)
+ return;
+
+ if (core->opp_dl_venus)
+ device_link_del(core->opp_dl_venus);
+
+ dev_pm_domain_detach(core->opp_pmdomain, true);
}
static int core_get_v4(struct device *dev)
@@ -811,19 +857,46 @@ static int core_get_v4(struct device *dev)
if (legacy_binding)
return 0;
+ core->opp_table = dev_pm_opp_set_clkname(dev, "core");
+ if (IS_ERR(core->opp_table))
+ return PTR_ERR(core->opp_table);
+
+ if (core->res->opp_pmdomain) {
+ ret = dev_pm_opp_of_add_table(dev);
+ if (!ret) {
+ core->has_opp_table = true;
+ } else if (ret != -ENODEV) {
+ dev_err(dev, "invalid OPP table in device tree\n");
+ dev_pm_opp_put_clkname(core->opp_table);
+ return ret;
+ }
+ }
+
ret = vcodec_domains_get(dev);
- if (ret)
+ if (ret) {
+ if (core->has_opp_table)
+ dev_pm_opp_of_remove_table(dev);
+ dev_pm_opp_put_clkname(core->opp_table);
return ret;
+ }
return 0;
}
static void core_put_v4(struct device *dev)
{
+ struct venus_core *core = dev_get_drvdata(dev);
+
if (legacy_binding)
return;
vcodec_domains_put(dev);
+
+ if (core->has_opp_table)
+ dev_pm_opp_of_remove_table(dev);
+ if (core->opp_table)
+ dev_pm_opp_put_clkname(core->opp_table);
+
}
static int core_power_v4(struct device *dev, int on)
@@ -831,10 +904,15 @@ static int core_power_v4(struct device *dev, int on)
struct venus_core *core = dev_get_drvdata(dev);
int ret = 0;
- if (on == POWER_ON)
+ if (on == POWER_ON) {
ret = core_clks_enable(core);
- else
+ } else {
+ /* Drop the performance state vote */
+ if (core->opp_pmdomain)
+ dev_pm_opp_set_rate(dev, 0);
+
core_clks_disable(core);
+ }
return ret;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Add the OPP tables in order to be able to vote on the performance state of
a power-domain.
Signed-off-by: Rajendra Nayak <[email protected]>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 ++++++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index e506793..5ca2265 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3631,8 +3631,10 @@
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&videocc VENUS_GDSC>,
<&videocc VCODEC0_GDSC>,
- <&videocc VCODEC1_GDSC>;
- power-domain-names = "venus", "vcodec0", "vcodec1";
+ <&videocc VCODEC1_GDSC>,
+ <&rpmhpd SDM845_CX>;
+ power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
+ operating-points-v2 = <&venus_opp_table>;
clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
<&videocc VIDEO_CC_VENUS_AHB_CLK>,
<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
@@ -3654,6 +3656,40 @@
video-core1 {
compatible = "venus-encoder";
};
+
+ venus_opp_table: venus-opp-table {
+ compatible = "operating-points-v2";
+
+ opp-100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ required-opps = <&rpmhpd_opp_min_svs>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-320000000 {
+ opp-hz = /bits/ 64 <320000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-380000000 {
+ opp-hz = /bits/ 64 <380000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-444000000 {
+ opp-hz = /bits/ 64 <444000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+
+ opp-533000000 {
+ opp-hz = /bits/ 64 <533000000>;
+ required-opps = <&rpmhpd_opp_turbo>;
+ };
+ };
};
videocc: clock-controller@ab00000 {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Post a successful pm_ops->core_get, an error in probe
should exit by doing a pm_ops->core_put which seems
to be missing. So fix it.
Signed-off-by: Rajendra Nayak <[email protected]>
---
drivers/media/platform/qcom/venus/core.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index 203c653..bfcaba3 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -224,13 +224,15 @@ static int venus_probe(struct platform_device *pdev)
ret = dma_set_mask_and_coherent(dev, core->res->dma_mask);
if (ret)
- return ret;
+ goto err_core_put;
if (!dev->dma_parms) {
dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
GFP_KERNEL);
- if (!dev->dma_parms)
- return -ENOMEM;
+ if (!dev->dma_parms) {
+ ret = -ENOMEM;
+ goto err_core_put;
+ }
}
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
@@ -242,11 +244,11 @@ static int venus_probe(struct platform_device *pdev)
IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
"venus", core);
if (ret)
- return ret;
+ goto err_core_put;
ret = hfi_create(core, &venus_core_ops);
if (ret)
- return ret;
+ goto err_core_put;
pm_runtime_enable(dev);
@@ -302,6 +304,9 @@ static int venus_probe(struct platform_device *pdev)
pm_runtime_set_suspended(dev);
pm_runtime_disable(dev);
hfi_destroy(core);
+err_core_put:
+ if (core->pm_ops->core_put)
+ core->pm_ops->core_put(dev);
return ret;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Add the OPP tables in order to be able to vote on the performance state
of a power-domain
Signed-off-by: Rajendra Nayak <[email protected]>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 16df08d..cb6137d 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2664,8 +2664,10 @@
reg = <0 0x0aa00000 0 0xff000>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&videocc VENUS_GDSC>,
- <&videocc VCODEC0_GDSC>;
- power-domain-names = "venus", "vcodec0";
+ <&videocc VCODEC0_GDSC>,
+ <&rpmhpd SC7180_CX>;
+ power-domain-names = "venus", "vcodec0", "cx";
+ operating-points-v2 = <&venus_opp_table>;
clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
<&videocc VIDEO_CC_VENUS_AHB_CLK>,
<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
@@ -2686,6 +2688,35 @@
video-encoder {
compatible = "venus-encoder";
};
+
+ venus_opp_table: venus-opp-table {
+ compatible = "operating-points-v2";
+
+ opp-150000000 {
+ opp-hz = /bits/ 64 <150000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-340000000 {
+ opp-hz = /bits/ 64 <340000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-434000000 {
+ opp-hz = /bits/ 64 <434000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ required-opps = <&rpmhpd_opp_turbo>;
+ };
+ };
};
videocc: clock-controller@ab00000 {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Hi Rajendra,
After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
below messages on db845:
qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
current OPP for freq 533000097 (-34)
^^^ This one is new.
qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
^^^ and this message is annoying, can we make it pr_debug in rpmh?
On 7/23/20 2:26 PM, Rajendra Nayak wrote:
> Add the OPP tables in order to be able to vote on the performance state of
> a power-domain.
>
> Signed-off-by: Rajendra Nayak <[email protected]>
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index e506793..5ca2265 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -3631,8 +3631,10 @@
> interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> power-domains = <&videocc VENUS_GDSC>,
> <&videocc VCODEC0_GDSC>,
> - <&videocc VCODEC1_GDSC>;
> - power-domain-names = "venus", "vcodec0", "vcodec1";
> + <&videocc VCODEC1_GDSC>,
> + <&rpmhpd SDM845_CX>;
> + power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
> + operating-points-v2 = <&venus_opp_table>;
> clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
> <&videocc VIDEO_CC_VENUS_AHB_CLK>,
> <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
> @@ -3654,6 +3656,40 @@
> video-core1 {
> compatible = "venus-encoder";
> };
> +
> + venus_opp_table: venus-opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-100000000 {
> + opp-hz = /bits/ 64 <100000000>;
> + required-opps = <&rpmhpd_opp_min_svs>;
> + };
> +
> + opp-200000000 {
> + opp-hz = /bits/ 64 <200000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
> +
> + opp-320000000 {
> + opp-hz = /bits/ 64 <320000000>;
> + required-opps = <&rpmhpd_opp_svs>;
> + };
> +
> + opp-380000000 {
> + opp-hz = /bits/ 64 <380000000>;
> + required-opps = <&rpmhpd_opp_svs_l1>;
> + };
> +
> + opp-444000000 {
> + opp-hz = /bits/ 64 <444000000>;
> + required-opps = <&rpmhpd_opp_nom>;
> + };
> +
> + opp-533000000 {
> + opp-hz = /bits/ 64 <533000000>;
> + required-opps = <&rpmhpd_opp_turbo>;
> + };
> + };
> };
>
> videocc: clock-controller@ab00000 {
>
--
regards,
Stan
Hey Stan,
On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
> Hi Rajendra,
>
> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> below messages on db845:
>
> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> current OPP for freq 533000097 (-34)
>
> ^^^ This one is new.
I was hoping to be able to reproduce this on the 845 mtp (I don't have
a db845), but I can;t seem to get venus working on mainline [1]
(neither with linux-next, nor with linaro integration)
Do you know if I might be missing some fix?
>
> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>
> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
Sure, I'll send a patch for that and see what the rpmh owners have to say.
[1]
[ 1.632147] qcom-venus aa00000.video-codec: Adding to iommu group 2
[ 1.638920] qcom-venus aa00000.video-codec: non legacy binding
[ 1.648313] ------------[ cut here ]------------
[ 1.652976] video_cc_venus_ctl_axi_clk status stuck at 'off'
[ 1.653068] WARNING: CPU: 7 PID: 1 at drivers/clk/qcom/clk-branch.c:92 clk_b8
[ 1.667977] Modules linked in:
[ 1.671076] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc6-00254-gc43551
[ 1.678704] Hardware name: Qualcomm Technologies, Inc. SDM845 MTP (DT)
[ 1.685294] pstate: 60c00085 (nZCv daIf +PAN +UAO BTYPE=--)
[ 1.690911] pc : clk_branch_toggle+0x14c/0x168
[ 1.695397] lr : clk_branch_toggle+0x14c/0x168
[ 1.699881] sp : ffff80001005b900
[ 1.703232] x29: ffff80001005b900 x28: ffffb58586ac2f38
[ 1.708594] x27: ffff0000f86c6d48 x26: ffffb58586f09000
[ 1.713953] x25: ffffb585867c0bd8 x24: 0000000000000000
[ 1.719312] x23: ffffb5858702df28 x22: ffffb58585a3c6a8
[ 1.724672] x21: 0000000000000001 x20: ffffb58586f09000
[ 1.730031] x19: 0000000000000000 x18: ffffb58586f09948
[ 1.735390] x17: 0000000000000001 x16: 0000000000000019
[ 1.740749] x15: ffff80009005b5a7 x14: 0000000000000006
[ 1.746107] x13: ffff80001005b5b5 x12: ffffb58586f21d68
[ 1.751466] x11: 0000000000000000 x10: 0000000005f5e0ff
[ 1.756825] x9 : ffff80001005b900 x8 : 2766666f27207461
[ 1.762184] x7 : 206b637574732073 x6 : ffffb58587141848
[ 1.767543] x5 : 0000000000000000 x4 : 0000000000000000
[ 1.772902] x3 : 00000000ffffffff x2 : ffff4a7b76cd8000
[ 1.778261] x1 : ad405f90446fcf00 x0 : 0000000000000000
[ 1.783624] Call trace:
[ 1.786103] clk_branch_toggle+0x14c/0x168
[ 1.790241] clk_branch2_enable+0x18/0x20
[ 1.794306] clk_core_enable+0x60/0xa8
[ 1.798090] clk_core_enable_lock+0x20/0x40
[ 1.802316] clk_enable+0x14/0x28
[ 1.805682] core_clks_enable+0x94/0xd8
[ 1.809562] core_power_v4+0x48/0x50
[ 1.813178] venus_runtime_resume+0x24/0x40
[ 1.817417] pm_generic_runtime_resume+0x28/0x40
[ 1.822079] __rpm_callback+0xa0/0x138
[ 1.825861] rpm_callback+0x24/0x98
[ 1.829390] rpm_resume+0x32c/0x490
[ 1.832917] __pm_runtime_resume+0x38/0x88
[ 1.837051] venus_probe+0x1f0/0x34c
[ 1.840667] platform_drv_probe+0x4c/0xa8
[ 1.844727] really_probe+0x100/0x388
[ 1.848428] driver_probe_device+0x54/0xb8
[ 1.852563] device_driver_attach+0x6c/0x78
[ 1.856790] __driver_attach+0xb0/0xf0
[ 1.860576] bus_for_each_dev+0x68/0xc8
[ 1.864456] driver_attach+0x20/0x28
[ 1.868064] bus_add_driver+0x148/0x200
[ 1.871941] driver_register+0x60/0x110
[ 1.875819] __platform_driver_register+0x44/0x50
[ 1.880576] qcom_venus_driver_init+0x18/0x20
[ 1.884990] do_one_initcall+0x58/0x1a0
[ 1.888878] kernel_init_freeable+0x1fc/0x28c
[ 1.893292] kernel_init+0x10/0x108
[ 1.896821] ret_from_fork+0x10/0x1c
[ 1.900441] ---[ end trace f12a7e5e182f3e4e ]---
[ 1.906415] qcom-venus: probe of aa00000.video-codec failed with error -16
>
> On 7/23/20 2:26 PM, Rajendra Nayak wrote:
>> Add the OPP tables in order to be able to vote on the performance state of
>> a power-domain.
>>
>> Signed-off-by: Rajendra Nayak <[email protected]>
>> ---
>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 ++++++++++++++++++++++++++++++++++--
>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index e506793..5ca2265 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -3631,8 +3631,10 @@
>> interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>> power-domains = <&videocc VENUS_GDSC>,
>> <&videocc VCODEC0_GDSC>,
>> - <&videocc VCODEC1_GDSC>;
>> - power-domain-names = "venus", "vcodec0", "vcodec1";
>> + <&videocc VCODEC1_GDSC>,
>> + <&rpmhpd SDM845_CX>;
>> + power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
>> + operating-points-v2 = <&venus_opp_table>;
>> clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
>> <&videocc VIDEO_CC_VENUS_AHB_CLK>,
>> <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
>> @@ -3654,6 +3656,40 @@
>> video-core1 {
>> compatible = "venus-encoder";
>> };
>> +
>> + venus_opp_table: venus-opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-100000000 {
>> + opp-hz = /bits/ 64 <100000000>;
>> + required-opps = <&rpmhpd_opp_min_svs>;
>> + };
>> +
>> + opp-200000000 {
>> + opp-hz = /bits/ 64 <200000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> +
>> + opp-320000000 {
>> + opp-hz = /bits/ 64 <320000000>;
>> + required-opps = <&rpmhpd_opp_svs>;
>> + };
>> +
>> + opp-380000000 {
>> + opp-hz = /bits/ 64 <380000000>;
>> + required-opps = <&rpmhpd_opp_svs_l1>;
>> + };
>> +
>> + opp-444000000 {
>> + opp-hz = /bits/ 64 <444000000>;
>> + required-opps = <&rpmhpd_opp_nom>;
>> + };
>> +
>> + opp-533000000 {
>> + opp-hz = /bits/ 64 <533000000>;
>> + required-opps = <&rpmhpd_opp_turbo>;
>> + };
>> + };
>> };
>>
>> videocc: clock-controller@ab00000 {
>>
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Hi Maulik/Lina,
On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
> Hi Rajendra,
>
> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> below messages on db845:
>
> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> current OPP for freq 533000097 (-34)
>
> ^^^ This one is new.
>
> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>
> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
Would you be fine with moving this message to a pr_debug? Its currently
a pr_info_ratelimited()
thanks,
Rajendra
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Hi,
On 7/24/20 11:49 AM, Rajendra Nayak wrote:
> Hey Stan,
>
> On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
>> Hi Rajendra,
>>
>> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
>> below messages on db845:
>>
>> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
>> current OPP for freq 533000097 (-34)
>>
>> ^^^ This one is new.
>
> I was hoping to be able to reproduce this on the 845 mtp (I don't have
> a db845), but I can;t seem to get venus working on mainline [1]
> (neither with linux-next, nor with linaro integration)
The driver should at least load without errors on -next and
linaro-integration for db845. As to MTP and haven't checked because I
don't have such board with me.
I will try to debug dev_pm_opp_set_rate -ERANGE error.
> Do you know if I might be missing some fix?
>
>>
>> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>>
>> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
>
> Sure, I'll send a patch for that and see what the rpmh owners have to say.
>
> [1]
>
> [ 1.632147] qcom-venus aa00000.video-codec: Adding to iommu group 2
> [ 1.638920] qcom-venus aa00000.video-codec: non legacy binding
> [ 1.648313] ------------[ cut here ]------------
> [ 1.652976] video_cc_venus_ctl_axi_clk status stuck at 'off'
I guess this means that venus_gdsc is not powered on.
> [ 1.653068] WARNING: CPU: 7 PID: 1 at
> drivers/clk/qcom/clk-branch.c:92 clk_b8
> [ 1.667977] Modules linked in:
> [ 1.671076] CPU: 7 PID: 1 Comm: swapper/0 Not tainted
> 5.8.0-rc6-00254-gc43551
> [ 1.678704] Hardware name: Qualcomm Technologies, Inc. SDM845 MTP (DT)
> [ 1.685294] pstate: 60c00085 (nZCv daIf +PAN +UAO BTYPE=--)
> [ 1.690911] pc : clk_branch_toggle+0x14c/0x168
> [ 1.695397] lr : clk_branch_toggle+0x14c/0x168
> [ 1.699881] sp : ffff80001005b900
> [ 1.703232] x29: ffff80001005b900 x28: ffffb58586ac2f38
> [ 1.708594] x27: ffff0000f86c6d48 x26: ffffb58586f09000
> [ 1.713953] x25: ffffb585867c0bd8 x24: 0000000000000000
> [ 1.719312] x23: ffffb5858702df28 x22: ffffb58585a3c6a8
> [ 1.724672] x21: 0000000000000001 x20: ffffb58586f09000
> [ 1.730031] x19: 0000000000000000 x18: ffffb58586f09948
> [ 1.735390] x17: 0000000000000001 x16: 0000000000000019
> [ 1.740749] x15: ffff80009005b5a7 x14: 0000000000000006
> [ 1.746107] x13: ffff80001005b5b5 x12: ffffb58586f21d68
> [ 1.751466] x11: 0000000000000000 x10: 0000000005f5e0ff
> [ 1.756825] x9 : ffff80001005b900 x8 : 2766666f27207461
> [ 1.762184] x7 : 206b637574732073 x6 : ffffb58587141848
> [ 1.767543] x5 : 0000000000000000 x4 : 0000000000000000
> [ 1.772902] x3 : 00000000ffffffff x2 : ffff4a7b76cd8000
> [ 1.778261] x1 : ad405f90446fcf00 x0 : 0000000000000000
> [ 1.783624] Call trace:
> [ 1.786103] clk_branch_toggle+0x14c/0x168
> [ 1.790241] clk_branch2_enable+0x18/0x20
> [ 1.794306] clk_core_enable+0x60/0xa8
> [ 1.798090] clk_core_enable_lock+0x20/0x40
> [ 1.802316] clk_enable+0x14/0x28
> [ 1.805682] core_clks_enable+0x94/0xd8
> [ 1.809562] core_power_v4+0x48/0x50
> [ 1.813178] venus_runtime_resume+0x24/0x40
> [ 1.817417] pm_generic_runtime_resume+0x28/0x40
> [ 1.822079] __rpm_callback+0xa0/0x138
> [ 1.825861] rpm_callback+0x24/0x98
> [ 1.829390] rpm_resume+0x32c/0x490
> [ 1.832917] __pm_runtime_resume+0x38/0x88
> [ 1.837051] venus_probe+0x1f0/0x34c
> [ 1.840667] platform_drv_probe+0x4c/0xa8
> [ 1.844727] really_probe+0x100/0x388
> [ 1.848428] driver_probe_device+0x54/0xb8
> [ 1.852563] device_driver_attach+0x6c/0x78
> [ 1.856790] __driver_attach+0xb0/0xf0
> [ 1.860576] bus_for_each_dev+0x68/0xc8
> [ 1.864456] driver_attach+0x20/0x28
> [ 1.868064] bus_add_driver+0x148/0x200
> [ 1.871941] driver_register+0x60/0x110
> [ 1.875819] __platform_driver_register+0x44/0x50
> [ 1.880576] qcom_venus_driver_init+0x18/0x20
> [ 1.884990] do_one_initcall+0x58/0x1a0
> [ 1.888878] kernel_init_freeable+0x1fc/0x28c
> [ 1.893292] kernel_init+0x10/0x108
> [ 1.896821] ret_from_fork+0x10/0x1c
> [ 1.900441] ---[ end trace f12a7e5e182f3e4e ]---
> [ 1.906415] qcom-venus: probe of aa00000.video-codec failed with
> error -16
>
>>
>> On 7/23/20 2:26 PM, Rajendra Nayak wrote:
>>> Add the OPP tables in order to be able to vote on the performance
>>> state of
>>> a power-domain.
>>>
>>> Signed-off-by: Rajendra Nayak <[email protected]>
>>> ---
>>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 40
>>> ++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> index e506793..5ca2265 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> @@ -3631,8 +3631,10 @@
>>> interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>>> power-domains = <&videocc VENUS_GDSC>,
>>> <&videocc VCODEC0_GDSC>,
>>> - <&videocc VCODEC1_GDSC>;
>>> - power-domain-names = "venus", "vcodec0", "vcodec1";
>>> + <&videocc VCODEC1_GDSC>,
>>> + <&rpmhpd SDM845_CX>;
>>> + power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
>>> + operating-points-v2 = <&venus_opp_table>;
>>> clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
>>> <&videocc VIDEO_CC_VENUS_AHB_CLK>,
>>> <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
>>> @@ -3654,6 +3656,40 @@
>>> video-core1 {
>>> compatible = "venus-encoder";
>>> };
>>> +
>>> + venus_opp_table: venus-opp-table {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-100000000 {
>>> + opp-hz = /bits/ 64 <100000000>;
>>> + required-opps = <&rpmhpd_opp_min_svs>;
>>> + };
>>> +
>>> + opp-200000000 {
>>> + opp-hz = /bits/ 64 <200000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + };
>>> +
>>> + opp-320000000 {
>>> + opp-hz = /bits/ 64 <320000000>;
>>> + required-opps = <&rpmhpd_opp_svs>;
>>> + };
>>> +
>>> + opp-380000000 {
>>> + opp-hz = /bits/ 64 <380000000>;
>>> + required-opps = <&rpmhpd_opp_svs_l1>;
>>> + };
>>> +
>>> + opp-444000000 {
>>> + opp-hz = /bits/ 64 <444000000>;
>>> + required-opps = <&rpmhpd_opp_nom>;
>>> + };
>>> +
>>> + opp-533000000 {
>>> + opp-hz = /bits/ 64 <533000000>;
>>> + required-opps = <&rpmhpd_opp_turbo>;
>>> + };
>>> + };
>>> };
>>> videocc: clock-controller@ab00000 {
>>>
>>
>
--
regards,
Stan
Hi,
On 7/23/20 9:06 PM, Stanimir Varbanov wrote:
> Hi Rajendra,
>
> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> below messages on db845:
>
> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> current OPP for freq 533000097 (-34)
>
> ^^^ This one is new.
>
> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>
> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
>
> On 7/23/20 2:26 PM, Rajendra Nayak wrote:
>> Add the OPP tables in order to be able to vote on the performance state of
>> a power-domain.
>>
>> Signed-off-by: Rajendra Nayak <[email protected]>
>> ---
>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 ++++++++++++++++++++++++++++++++++--
>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index e506793..5ca2265 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -3631,8 +3631,10 @@
>> interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>> power-domains = <&videocc VENUS_GDSC>,
>> <&videocc VCODEC0_GDSC>,
>> - <&videocc VCODEC1_GDSC>;
>> - power-domain-names = "venus", "vcodec0", "vcodec1";
>> + <&videocc VCODEC1_GDSC>,
>> + <&rpmhpd SDM845_CX>;
>> + power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
>> + operating-points-v2 = <&venus_opp_table>;
>> clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
>> <&videocc VIDEO_CC_VENUS_AHB_CLK>,
>> <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
>> @@ -3654,6 +3656,40 @@
>> video-core1 {
>> compatible = "venus-encoder";
>> };
>> +
>> + venus_opp_table: venus-opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-100000000 {
>> + opp-hz = /bits/ 64 <100000000>;
>> + required-opps = <&rpmhpd_opp_min_svs>;
>> + };
>> +
>> + opp-200000000 {
>> + opp-hz = /bits/ 64 <200000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> +
>> + opp-320000000 {
>> + opp-hz = /bits/ 64 <320000000>;
>> + required-opps = <&rpmhpd_opp_svs>;
>> + };
>> +
>> + opp-380000000 {
>> + opp-hz = /bits/ 64 <380000000>;
>> + required-opps = <&rpmhpd_opp_svs_l1>;
>> + };
>> +
>> + opp-444000000 {
>> + opp-hz = /bits/ 64 <444000000>;
>> + required-opps = <&rpmhpd_opp_nom>;
>> + };
>> +
>> + opp-533000000 {
>> + opp-hz = /bits/ 64 <533000000>;
Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
defines 533000000 but the real calculated freq is 533000097.
If I change to opp-hz = /bits/ 64 <533000097> the error disappear.
I guess we have to revisit m/n and/or pre-divider for this freq when the
source pll is P_VIDEO_PLL0_OUT_MAIN PLL?
>> + required-opps = <&rpmhpd_opp_turbo>;
>> + };
>> + };
>> };
>>
>> videocc: clock-controller@ab00000 {
>>
>
--
regards,
Stan
On 7/23/20 2:26 PM, Rajendra Nayak wrote:
> Post a successful pm_ops->core_get, an error in probe
> should exit by doing a pm_ops->core_put which seems
> to be missing. So fix it.
>
> Signed-off-by: Rajendra Nayak <[email protected]>
> ---
> drivers/media/platform/qcom/venus/core.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
Acked-by: Stanimir Varbanov <[email protected]>
>
> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
> index 203c653..bfcaba3 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -224,13 +224,15 @@ static int venus_probe(struct platform_device *pdev)
>
> ret = dma_set_mask_and_coherent(dev, core->res->dma_mask);
> if (ret)
> - return ret;
> + goto err_core_put;
>
> if (!dev->dma_parms) {
> dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> GFP_KERNEL);
> - if (!dev->dma_parms)
> - return -ENOMEM;
> + if (!dev->dma_parms) {
> + ret = -ENOMEM;
> + goto err_core_put;
> + }
> }
> dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
>
> @@ -242,11 +244,11 @@ static int venus_probe(struct platform_device *pdev)
> IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> "venus", core);
> if (ret)
> - return ret;
> + goto err_core_put;
>
> ret = hfi_create(core, &venus_core_ops);
> if (ret)
> - return ret;
> + goto err_core_put;
>
> pm_runtime_enable(dev);
>
> @@ -302,6 +304,9 @@ static int venus_probe(struct platform_device *pdev)
> pm_runtime_set_suspended(dev);
> pm_runtime_disable(dev);
> hfi_destroy(core);
> +err_core_put:
> + if (core->pm_ops->core_put)
> + core->pm_ops->core_put(dev);
> return ret;
> }
>
>
--
regards,
Stan
On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
>Hi Maulik/Lina,
>
>On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
>>Hi Rajendra,
>>
>>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
>>below messages on db845:
>>
>>qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
>>current OPP for freq 533000097 (-34)
>>
>>^^^ This one is new.
>>
>>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>>
>>^^^ and this message is annoying, can we make it pr_debug in rpmh?
>
How annoyingly often do you see this message?
Usually, this is an indication of bad system state either on remote
processors in the SoC or in Linux itself. On a smooth sailing build you
should not see this 'warning'.
>Would you be fine with moving this message to a pr_debug? Its currently
>a pr_info_ratelimited()
I would rather not, moving this out of sight will mask a lot serious
issues that otherwise bring attention to the developers.
--Lina
Hi Lina,
On 7/24/20 7:28 PM, Lina Iyer wrote:
> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
>> Hi Maulik/Lina,
>>
>> On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
>>> Hi Rajendra,
>>>
>>> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
>>> below messages on db845:
>>>
>>> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
>>> current OPP for freq 533000097 (-34)
>>>
>>> ^^^ This one is new.
>>>
>>> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>>>
>>> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
>>
> How annoyingly often do you see this message?
I haven't gig deeply but on every driver pm_runtime_suspend (after
applying Rajendra's patches). And I guess it comes after a call to
dev_pm_opp_set_rate(dev, 0).
IMO this is too often.
> Usually, this is an indication of bad system state either on remote
> processors in the SoC or in Linux itself. On a smooth sailing build you
> should not see this 'warning'.
>
>> Would you be fine with moving this message to a pr_debug? Its currently
>> a pr_info_ratelimited()
> I would rather not, moving this out of sight will mask a lot serious
> issues that otherwise bring attention to the developers.
>
> --Lina
--
regards,
Stan
On 7/24/20 7:52 PM, Stanimir Varbanov wrote:
> Hi Lina,
>
> On 7/24/20 7:28 PM, Lina Iyer wrote:
>> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
>>> Hi Maulik/Lina,
>>>
>>> On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
>>>> Hi Rajendra,
>>>>
>>>> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
>>>> below messages on db845:
>>>>
>>>> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
>>>> current OPP for freq 533000097 (-34)
>>>>
>>>> ^^^ This one is new.
>>>>
>>>> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>>>>
>>>> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
>>>
>> How annoyingly often do you see this message?
>
> I haven't gig deeply but on every driver pm_runtime_suspend (after
> applying Rajendra's patches). And I guess it comes after a call to
> dev_pm_opp_set_rate(dev, 0).
Or it might be when the driver is switching off opp_pmdomain.
>
> IMO this is too often.
>
>> Usually, this is an indication of bad system state either on remote
>> processors in the SoC or in Linux itself. On a smooth sailing build you
>> should not see this 'warning'.
>>
>>> Would you be fine with moving this message to a pr_debug? Its currently
>>> a pr_info_ratelimited()
>> I would rather not, moving this out of sight will mask a lot serious
>> issues that otherwise bring attention to the developers.
>>
>> --Lina
>
--
regards,
Stan
Hi Rajendra,
On 7/23/20 2:26 PM, Rajendra Nayak wrote:
> Add support to add OPP tables and perf voting on the OPP powerdomain.
> This is needed so venus votes on the corresponding performance state
> for the OPP powerdomain along with setting the core clock rate.
>
> Signed-off-by: Rajendra Nayak <[email protected]>
> Reviewed-by: Matthias Kaehlcke <[email protected]>
> ---
> drivers/media/platform/qcom/venus/core.c | 2 +
> drivers/media/platform/qcom/venus/core.h | 5 ++
> drivers/media/platform/qcom/venus/pm_helpers.c | 92 ++++++++++++++++++++++++--
> 3 files changed, 92 insertions(+), 7 deletions(-)
Once we have a fix in opp-table (patch 4/5) to avoid -ERANGE from
dev_pm_opp_set_rate:
Acked-by: Stanimir Varbanov <[email protected]>
<cut>
--
regards,
Stan
On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
> Hi,
>
> On 7/23/20 9:06 PM, Stanimir Varbanov wrote:
>> Hi Rajendra,
>>
>> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
>> below messages on db845:
>>
>> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
>> current OPP for freq 533000097 (-34)
>>
>> ^^^ This one is new.
>>
>> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>>
>> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
>>
>> On 7/23/20 2:26 PM, Rajendra Nayak wrote:
>>> Add the OPP tables in order to be able to vote on the performance state of
>>> a power-domain.
>>>
>>> Signed-off-by: Rajendra Nayak <[email protected]>
>>> ---
>>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 ++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> index e506793..5ca2265 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> @@ -3631,8 +3631,10 @@
>>> interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>>> power-domains = <&videocc VENUS_GDSC>,
>>> <&videocc VCODEC0_GDSC>,
>>> - <&videocc VCODEC1_GDSC>;
>>> - power-domain-names = "venus", "vcodec0", "vcodec1";
>>> + <&videocc VCODEC1_GDSC>,
>>> + <&rpmhpd SDM845_CX>;
>>> + power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
>>> + operating-points-v2 = <&venus_opp_table>;
>>> clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
>>> <&videocc VIDEO_CC_VENUS_AHB_CLK>,
>>> <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
>>> @@ -3654,6 +3656,40 @@
>>> video-core1 {
>>> compatible = "venus-encoder";
>>> };
>>> +
>>> + venus_opp_table: venus-opp-table {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-100000000 {
>>> + opp-hz = /bits/ 64 <100000000>;
>>> + required-opps = <&rpmhpd_opp_min_svs>;
>>> + };
>>> +
>>> + opp-200000000 {
>>> + opp-hz = /bits/ 64 <200000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + };
>>> +
>>> + opp-320000000 {
>>> + opp-hz = /bits/ 64 <320000000>;
>>> + required-opps = <&rpmhpd_opp_svs>;
>>> + };
>>> +
>>> + opp-380000000 {
>>> + opp-hz = /bits/ 64 <380000000>;
>>> + required-opps = <&rpmhpd_opp_svs_l1>;
>>> + };
>>> +
>>> + opp-444000000 {
>>> + opp-hz = /bits/ 64 <444000000>;
>>> + required-opps = <&rpmhpd_opp_nom>;
>>> + };
>>> +
>>> + opp-533000000 {
>>> + opp-hz = /bits/ 64 <533000000>;
>
> Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
> defines 533000000 but the real calculated freq is 533000097.
I still don't quite understand why the videocc driver returns this
frequency despite this not being in the freq table.
I would expect a clk_round_rate() when called with 533000097 to return
a 533000000.
Taniya, Do you know why?
>
> If I change to opp-hz = /bits/ 64 <533000097> the error disappear.
>
> I guess we have to revisit m/n and/or pre-divider for this freq when the
> source pll is P_VIDEO_PLL0_OUT_MAIN PLL?
>
>>> + required-opps = <&rpmhpd_opp_turbo>;
>>> + };
>>> + };
>>> };
>>>
>>> videocc: clock-controller@ab00000 {
>>>
>>
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
On 7/27/2020 11:23 AM, Rajendra Nayak wrote:
>
>
> On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
>> Hi,
>>
>> On 7/23/20 9:06 PM, Stanimir Varbanov wrote:
>>> Hi Rajendra,
>>>
>>> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
>>> below messages on db845:
>>>
>>> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
>>> current OPP for freq 533000097 (-34)
>>>
>>> ^^^ This one is new.
>>>
>>> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>>>
>>> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
>>>
>>> On 7/23/20 2:26 PM, Rajendra Nayak wrote:
>>>> Add the OPP tables in order to be able to vote on the performance state of
>>>> a power-domain.
>>>>
>>>> Signed-off-by: Rajendra Nayak <[email protected]>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 ++++++++++++++++++++++++++++++++++--
>>>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> index e506793..5ca2265 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> @@ -3631,8 +3631,10 @@
>>>> interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>>>> power-domains = <&videocc VENUS_GDSC>,
>>>> <&videocc VCODEC0_GDSC>,
>>>> - <&videocc VCODEC1_GDSC>;
>>>> - power-domain-names = "venus", "vcodec0", "vcodec1";
>>>> + <&videocc VCODEC1_GDSC>,
>>>> + <&rpmhpd SDM845_CX>;
>>>> + power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
>>>> + operating-points-v2 = <&venus_opp_table>;
>>>> clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
>>>> <&videocc VIDEO_CC_VENUS_AHB_CLK>,
>>>> <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
>>>> @@ -3654,6 +3656,40 @@
>>>> video-core1 {
>>>> compatible = "venus-encoder";
>>>> };
>>>> +
>>>> + venus_opp_table: venus-opp-table {
>>>> + compatible = "operating-points-v2";
>>>> +
>>>> + opp-100000000 {
>>>> + opp-hz = /bits/ 64 <100000000>;
>>>> + required-opps = <&rpmhpd_opp_min_svs>;
>>>> + };
>>>> +
>>>> + opp-200000000 {
>>>> + opp-hz = /bits/ 64 <200000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>>> + };
>>>> +
>>>> + opp-320000000 {
>>>> + opp-hz = /bits/ 64 <320000000>;
>>>> + required-opps = <&rpmhpd_opp_svs>;
>>>> + };
>>>> +
>>>> + opp-380000000 {
>>>> + opp-hz = /bits/ 64 <380000000>;
>>>> + required-opps = <&rpmhpd_opp_svs_l1>;
>>>> + };
>>>> +
>>>> + opp-444000000 {
>>>> + opp-hz = /bits/ 64 <444000000>;
>>>> + required-opps = <&rpmhpd_opp_nom>;
>>>> + };
>>>> +
>>>> + opp-533000000 {
>>>> + opp-hz = /bits/ 64 <533000000>;
>>
>> Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
>> defines 533000000 but the real calculated freq is 533000097.
>
> I still don't quite understand why the videocc driver returns this
> frequency despite this not being in the freq table.
Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to
return whats in the freq table, but clk_set_rate() goes ahead and sets it
to 533000097. Subsequently when we try to set a different OPP, it fails to
find the 'current' OPP entry for 533000097. This sounds like an issue with the OPP
framework? Should we not fall back to the highest OPP as the current OPP?
Stephen/Viresh, any thoughts?
> I would expect a clk_round_rate() when called with 533000097 to return
> a 533000000.
>
> Taniya, Do you know why?
>
>>
>> If I change to opp-hz = /bits/ 64 <533000097> the error disappear.
>>
>> I guess we have to revisit m/n and/or pre-divider for this freq when the
>> source pll is P_VIDEO_PLL0_OUT_MAIN PLL?
>>
>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>> + };
>>>> + };
>>>> };
>>>> videocc: clock-controller@ab00000 {
>>>>
>>>
>>
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
On 27-07-20, 17:38, Rajendra Nayak wrote:
>
> On 7/27/2020 11:23 AM, Rajendra Nayak wrote:
> >
> >
> > On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
> > > Hi,
> > >
> > > On 7/23/20 9:06 PM, Stanimir Varbanov wrote:
> > > > Hi Rajendra,
> > > >
> > > > After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> > > > below messages on db845:
> > > >
> > > > qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> > > > current OPP for freq 533000097 (-34)
> > > >
> > > > ^^^ This one is new.
> > > >
> > > > qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
> > > >
> > > > ^^^ and this message is annoying, can we make it pr_debug in rpmh?
> > > >
> > > > On 7/23/20 2:26 PM, Rajendra Nayak wrote:
> > > > > Add the OPP tables in order to be able to vote on the performance state of
> > > > > a power-domain.
> > > > >
> > > > > Signed-off-by: Rajendra Nayak <[email protected]>
> > > > > ---
> > > > > ? arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 ++++++++++++++++++++++++++++++++++--
> > > > > ? 1 file changed, 38 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > index e506793..5ca2265 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > @@ -3631,8 +3631,10 @@
> > > > > ????????????? interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> > > > > ????????????? power-domains = <&videocc VENUS_GDSC>,
> > > > > ????????????????????? <&videocc VCODEC0_GDSC>,
> > > > > -??????????????????? <&videocc VCODEC1_GDSC>;
> > > > > -??????????? power-domain-names = "venus", "vcodec0", "vcodec1";
> > > > > +??????????????????? <&videocc VCODEC1_GDSC>,
> > > > > +??????????????????? <&rpmhpd SDM845_CX>;
> > > > > +??????????? power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
> > > > > +??????????? operating-points-v2 = <&venus_opp_table>;
> > > > > ????????????? clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
> > > > > ?????????????????? <&videocc VIDEO_CC_VENUS_AHB_CLK>,
> > > > > ?????????????????? <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
> > > > > @@ -3654,6 +3656,40 @@
> > > > > ????????????? video-core1 {
> > > > > ????????????????? compatible = "venus-encoder";
> > > > > ????????????? };
> > > > > +
> > > > > +??????????? venus_opp_table: venus-opp-table {
> > > > > +??????????????? compatible = "operating-points-v2";
> > > > > +
> > > > > +??????????????? opp-100000000 {
> > > > > +??????????????????? opp-hz = /bits/ 64 <100000000>;
> > > > > +??????????????????? required-opps = <&rpmhpd_opp_min_svs>;
> > > > > +??????????????? };
> > > > > +
> > > > > +??????????????? opp-200000000 {
> > > > > +??????????????????? opp-hz = /bits/ 64 <200000000>;
> > > > > +??????????????????? required-opps = <&rpmhpd_opp_low_svs>;
> > > > > +??????????????? };
> > > > > +
> > > > > +??????????????? opp-320000000 {
> > > > > +??????????????????? opp-hz = /bits/ 64 <320000000>;
> > > > > +??????????????????? required-opps = <&rpmhpd_opp_svs>;
> > > > > +??????????????? };
> > > > > +
> > > > > +??????????????? opp-380000000 {
> > > > > +??????????????????? opp-hz = /bits/ 64 <380000000>;
> > > > > +??????????????????? required-opps = <&rpmhpd_opp_svs_l1>;
> > > > > +??????????????? };
> > > > > +
> > > > > +??????????????? opp-444000000 {
> > > > > +??????????????????? opp-hz = /bits/ 64 <444000000>;
> > > > > +??????????????????? required-opps = <&rpmhpd_opp_nom>;
> > > > > +??????????????? };
> > > > > +
> > > > > +??????????????? opp-533000000 {
> > > > > +??????????????????? opp-hz = /bits/ 64 <533000000>;
Is this the highest OPP in table ?
> > > Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
> > > defines 533000000 but the real calculated freq is 533000097.
> >
> > I still don't quite understand why the videocc driver returns this
> > frequency despite this not being in the freq table.
>
> Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to
> return whats in the freq table, but clk_set_rate() goes ahead and sets it
> to 533000097. Subsequently when we try to set a different OPP, it fails to
> find the 'current' OPP entry for 533000097. This sounds like an issue with the OPP
> framework? Should we not fall back to the highest OPP as the current OPP?
>
> Stephen/Viresh, any thoughts?
I think we (in all frameworks generally) try to set a frequency <=
target frequency and so there may be a problem if the frequency is
larger than highest supported. IOW, you need to fix tables a bit.
--
viresh
Quoting Lina Iyer (2020-07-24 09:28:25)
> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
> >Hi Maulik/Lina,
> >
> >On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
> >>Hi Rajendra,
> >>
> >>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> >>below messages on db845:
> >>
> >>qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> >>current OPP for freq 533000097 (-34)
> >>
> >>^^^ This one is new.
> >>
> >>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
> >>
> >>^^^ and this message is annoying, can we make it pr_debug in rpmh?
> >
> How annoyingly often do you see this message?
> Usually, this is an indication of bad system state either on remote
> processors in the SoC or in Linux itself. On a smooth sailing build you
> should not see this 'warning'.
>
> >Would you be fine with moving this message to a pr_debug? Its currently
> >a pr_info_ratelimited()
> I would rather not, moving this out of sight will mask a lot serious
> issues that otherwise bring attention to the developers.
>
I removed this warning message in my patch posted to the list[1]. If
it's a serious problem then I suppose a timeout is more appropriate, on
the order of several seconds or so and then a pr_warn() and bail out of
the async call with an error.
[1] https://lore.kernel.org/r/[email protected]
Quoting Viresh Kumar (2020-07-27 08:38:06)
> On 27-07-20, 17:38, Rajendra Nayak wrote:
> > On 7/27/2020 11:23 AM, Rajendra Nayak wrote:
> > > On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
> > > > > > +
> > > > > > + opp-533000000 {
> > > > > > + opp-hz = /bits/ 64 <533000000>;
>
> Is this the highest OPP in table ?
>
> > > > Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
> > > > defines 533000000 but the real calculated freq is 533000097.
> > >
> > > I still don't quite understand why the videocc driver returns this
> > > frequency despite this not being in the freq table.
> >
> > Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to
> > return whats in the freq table, but clk_set_rate() goes ahead and sets it
I'm happy to see clk_round_rate() return the actual rate that would be
achieved and not just the rate that is in the frequency tables. Would
that fix the problem? It may be that we need to make clk_round_rate() do
some more math on qcom platforms and actually figure out what the rate
is going to be instead of blindly trust the frequency that has been set
in the tables.
> > to 533000097. Subsequently when we try to set a different OPP, it fails to
> > find the 'current' OPP entry for 533000097. This sounds like an issue with the OPP
> > framework? Should we not fall back to the highest OPP as the current OPP?
> >
> > Stephen/Viresh, any thoughts?
>
> I think we (in all frameworks generally) try to set a frequency <=
> target frequency and so there may be a problem if the frequency is
> larger than highest supported. IOW, you need to fix tables a bit.
>
Rounding is annoying for sure.
On 7/28/2020 6:22 AM, Stephen Boyd wrote:
> Quoting Viresh Kumar (2020-07-27 08:38:06)
>> On 27-07-20, 17:38, Rajendra Nayak wrote:
>>> On 7/27/2020 11:23 AM, Rajendra Nayak wrote:
>>>> On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
>>>>>>> +
>>>>>>> + opp-533000000 {
>>>>>>> + opp-hz = /bits/ 64 <533000000>;
>>
>> Is this the highest OPP in table ?
>>
>>>>> Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
>>>>> defines 533000000 but the real calculated freq is 533000097.
>>>>
>>>> I still don't quite understand why the videocc driver returns this
>>>> frequency despite this not being in the freq table.
>>>
>>> Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to
>>> return whats in the freq table, but clk_set_rate() goes ahead and sets it
>
> I'm happy to see clk_round_rate() return the actual rate that would be
> achieved and not just the rate that is in the frequency tables. Would
> that fix the problem?
It would, but only if I also update the OPP table to have 533000097
instead of 533000000 (which I guess is needed anyway)
If this is the actual frequency that's achievable, then perhaps even the clock
freq table should have this? 533000097 and not 533000000?
That way clk_round_rate() would return the actual rate that's achieved and
we don't need any extra math. Isn't that the reason these freq tables exist
anyway.
> It may be that we need to make clk_round_rate() do
> some more math on qcom platforms and actually figure out what the rate
> is going to be instead of blindly trust the frequency that has been set
> in the tables.
>
>>> to 533000097. Subsequently when we try to set a different OPP, it fails to
>>> find the 'current' OPP entry for 533000097. This sounds like an issue with the OPP
>>> framework? Should we not fall back to the highest OPP as the current OPP?
>>>
>>> Stephen/Viresh, any thoughts?
>>
>> I think we (in all frameworks generally) try to set a frequency <=
>> target frequency and so there may be a problem if the frequency is
>> larger than highest supported. IOW, you need to fix tables a bit.
>>
>
> Rounding is annoying for sure.
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
On Mon, Jul 27 2020 at 18:45 -0600, Stephen Boyd wrote:
>Quoting Lina Iyer (2020-07-24 09:28:25)
>> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
>> >Hi Maulik/Lina,
>> >
>> >On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
>> >>Hi Rajendra,
>> >>
>> >>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
>> >>below messages on db845:
>> >>
>> >>qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
>> >>current OPP for freq 533000097 (-34)
>> >>
>> >>^^^ This one is new.
>> >>
>> >>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>> >>
>> >>^^^ and this message is annoying, can we make it pr_debug in rpmh?
>> >
>> How annoyingly often do you see this message?
>> Usually, this is an indication of bad system state either on remote
>> processors in the SoC or in Linux itself. On a smooth sailing build you
>> should not see this 'warning'.
>>
>> >Would you be fine with moving this message to a pr_debug? Its currently
>> >a pr_info_ratelimited()
>> I would rather not, moving this out of sight will mask a lot serious
>> issues that otherwise bring attention to the developers.
>>
>
>I removed this warning message in my patch posted to the list[1]. If
>it's a serious problem then I suppose a timeout is more appropriate, on
>the order of several seconds or so and then a pr_warn() and bail out of
>the async call with an error.
>
The warning used to capture issues that happen within a second and it
helps capture system related issues. Timing out after many seconds
overlooks the system issues that generally tend to resolve itself, but
nevertheless need to be investigated.
--Lina
>[1] https://lore.kernel.org/r/[email protected]
Quoting Lina Iyer (2020-07-28 09:52:12)
> On Mon, Jul 27 2020 at 18:45 -0600, Stephen Boyd wrote:
> >Quoting Lina Iyer (2020-07-24 09:28:25)
> >> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
> >> >Hi Maulik/Lina,
> >> >
> >> >On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
> >> >>Hi Rajendra,
> >> >>
> >> >>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> >> >>below messages on db845:
> >> >>
> >> >>qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> >> >>current OPP for freq 533000097 (-34)
> >> >>
> >> >>^^^ This one is new.
> >> >>
> >> >>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
> >> >>
> >> >>^^^ and this message is annoying, can we make it pr_debug in rpmh?
> >> >
> >> How annoyingly often do you see this message?
> >> Usually, this is an indication of bad system state either on remote
> >> processors in the SoC or in Linux itself. On a smooth sailing build you
> >> should not see this 'warning'.
> >>
> >> >Would you be fine with moving this message to a pr_debug? Its currently
> >> >a pr_info_ratelimited()
> >> I would rather not, moving this out of sight will mask a lot serious
> >> issues that otherwise bring attention to the developers.
> >>
> >
> >I removed this warning message in my patch posted to the list[1]. If
> >it's a serious problem then I suppose a timeout is more appropriate, on
> >the order of several seconds or so and then a pr_warn() and bail out of
> >the async call with an error.
> >
> The warning used to capture issues that happen within a second and it
> helps capture system related issues. Timing out after many seconds
> overlooks the system issues that generally tend to resolve itself, but
> nevertheless need to be investigated.
>
Is it correct to read "system related issues" as performance problems
where the thread is spinning forever trying to send a message and it
can't? So the problem is mostly that it's an unbounded amount of time
before the message is sent to rpmh and this printk helps identify those
situations where that is happening?
Otherwise as you say above it's a bad system state where the rpmh
processor has gotten into a bad state like a crash? Can we recover from
that? Or is the only recovery a reboot of the system? Does the rpmh
processor reboot the system if it crashes?
Quoting Rajendra Nayak (2020-07-27 21:17:28)
>
> On 7/28/2020 6:22 AM, Stephen Boyd wrote:
> > Quoting Viresh Kumar (2020-07-27 08:38:06)
> >> On 27-07-20, 17:38, Rajendra Nayak wrote:
> >>> On 7/27/2020 11:23 AM, Rajendra Nayak wrote:
> >>>> On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
> >>>>>>> +
> >>>>>>> + opp-533000000 {
> >>>>>>> + opp-hz = /bits/ 64 <533000000>;
> >>
> >> Is this the highest OPP in table ?
> >>
> >>>>> Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
> >>>>> defines 533000000 but the real calculated freq is 533000097.
> >>>>
> >>>> I still don't quite understand why the videocc driver returns this
> >>>> frequency despite this not being in the freq table.
> >>>
> >>> Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to
> >>> return whats in the freq table, but clk_set_rate() goes ahead and sets it
> >
> > I'm happy to see clk_round_rate() return the actual rate that would be
> > achieved and not just the rate that is in the frequency tables. Would
> > that fix the problem?
>
> It would, but only if I also update the OPP table to have 533000097
> instead of 533000000 (which I guess is needed anyway)
> If this is the actual frequency that's achievable, then perhaps even the clock
> freq table should have this? 533000097 and not 533000000?
> That way clk_round_rate() would return the actual rate that's achieved and
> we don't need any extra math. Isn't that the reason these freq tables exist
> anyway.
Yes the freq tables are there in the clk driver so we don't have to do a
bunch of math. Fixing them to be accurate has been deemed "hard" from
what I recall because the tables are generated from some math function
that truncates the lower Hertz values.
On Tue, Jul 28 2020 at 13:51 -0600, Stephen Boyd wrote:
>Quoting Lina Iyer (2020-07-28 09:52:12)
>> On Mon, Jul 27 2020 at 18:45 -0600, Stephen Boyd wrote:
>> >Quoting Lina Iyer (2020-07-24 09:28:25)
>> >> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
>> >> >Hi Maulik/Lina,
>> >> >
>> >> >On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
>> >> >>Hi Rajendra,
>> >> >>
>> >> >>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
>> >> >>below messages on db845:
>> >> >>
>> >> >>qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
>> >> >>current OPP for freq 533000097 (-34)
>> >> >>
>> >> >>^^^ This one is new.
>> >> >>
>> >> >>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>> >> >>
>> >> >>^^^ and this message is annoying, can we make it pr_debug in rpmh?
>> >> >
>> >> How annoyingly often do you see this message?
>> >> Usually, this is an indication of bad system state either on remote
>> >> processors in the SoC or in Linux itself. On a smooth sailing build you
>> >> should not see this 'warning'.
>> >>
>> >> >Would you be fine with moving this message to a pr_debug? Its currently
>> >> >a pr_info_ratelimited()
>> >> I would rather not, moving this out of sight will mask a lot serious
>> >> issues that otherwise bring attention to the developers.
>> >>
>> >
>> >I removed this warning message in my patch posted to the list[1]. If
>> >it's a serious problem then I suppose a timeout is more appropriate, on
>> >the order of several seconds or so and then a pr_warn() and bail out of
>> >the async call with an error.
>> >
>> The warning used to capture issues that happen within a second and it
>> helps capture system related issues. Timing out after many seconds
>> overlooks the system issues that generally tend to resolve itself, but
>> nevertheless need to be investigated.
>>
>
>Is it correct to read "system related issues" as performance problems
>where the thread is spinning forever trying to send a message and it
>can't? So the problem is mostly that it's an unbounded amount of time
>before the message is sent to rpmh and this printk helps identify those
>situations where that is happening?
>
Yes, but mostly a short period of time like when other processors are in
the middle of a restart or resource states changes have taken unusual
amounts of time. The system will generally recover from this without
crashing in this case. User action is investigation of the situation
leading to these messages.
>Otherwise as you say above it's a bad system state where the rpmh
>processor has gotten into a bad state like a crash? Can we recover from
>that? Or is the only recovery a reboot of the system? Does the rpmh
>processor reboot the system if it crashes?
We cannot recover from such a state. The remote processor will reboot if
it detects a failure at it's end. If the system entered a bad state, it
is possible that RPMH requests start timing out in Linux and remote
processor may not detect it. Hence, the timeout in rpmh_write() API. The
advised course of action is a restart as there is no way to recover from
this state.
--Lina
Hi,
On Tue, Jul 28, 2020 at 1:11 PM Lina Iyer <[email protected]> wrote:
>
> On Tue, Jul 28 2020 at 13:51 -0600, Stephen Boyd wrote:
> >Quoting Lina Iyer (2020-07-28 09:52:12)
> >> On Mon, Jul 27 2020 at 18:45 -0600, Stephen Boyd wrote:
> >> >Quoting Lina Iyer (2020-07-24 09:28:25)
> >> >> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
> >> >> >Hi Maulik/Lina,
> >> >> >
> >> >> >On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
> >> >> >>Hi Rajendra,
> >> >> >>
> >> >> >>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> >> >> >>below messages on db845:
> >> >> >>
> >> >> >>qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> >> >> >>current OPP for freq 533000097 (-34)
> >> >> >>
> >> >> >>^^^ This one is new.
> >> >> >>
> >> >> >>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
> >> >> >>
> >> >> >>^^^ and this message is annoying, can we make it pr_debug in rpmh?
> >> >> >
> >> >> How annoyingly often do you see this message?
> >> >> Usually, this is an indication of bad system state either on remote
> >> >> processors in the SoC or in Linux itself. On a smooth sailing build you
> >> >> should not see this 'warning'.
> >> >>
> >> >> >Would you be fine with moving this message to a pr_debug? Its currently
> >> >> >a pr_info_ratelimited()
> >> >> I would rather not, moving this out of sight will mask a lot serious
> >> >> issues that otherwise bring attention to the developers.
> >> >>
> >> >
> >> >I removed this warning message in my patch posted to the list[1]. If
> >> >it's a serious problem then I suppose a timeout is more appropriate, on
> >> >the order of several seconds or so and then a pr_warn() and bail out of
> >> >the async call with an error.
> >> >
> >> The warning used to capture issues that happen within a second and it
> >> helps capture system related issues. Timing out after many seconds
> >> overlooks the system issues that generally tend to resolve itself, but
> >> nevertheless need to be investigated.
> >>
> >
> >Is it correct to read "system related issues" as performance problems
> >where the thread is spinning forever trying to send a message and it
> >can't? So the problem is mostly that it's an unbounded amount of time
> >before the message is sent to rpmh and this printk helps identify those
> >situations where that is happening?
> >
> Yes, but mostly a short period of time like when other processors are in
> the middle of a restart or resource states changes have taken unusual
> amounts of time. The system will generally recover from this without
> crashing in this case. User action is investigation of the situation
> leading to these messages.
While I do agree that seeing the "TCS Busy, retrying RPMH message
send" message printed a lot was usually a sign that something was
wrong in the system (possibly someone was spamming RPMh when they
shouldn't be), it still feels like we need to remove it.
Specifically, the prints would also sometimes come up in normal usage
and always sounded a bit scary. These types of prints always confuse
people and lead to log pollution where it's super hard to figure out
which of the various things in a log are "expected" and which ones are
relevant to whatever issue you're debugging.
Presumably we could either change that from a "info" level to "dbg"
level. ...or we could find some other thing to check for that's a
better signal of problems.
> >Otherwise as you say above it's a bad system state where the rpmh
> >processor has gotten into a bad state like a crash? Can we recover from
> >that? Or is the only recovery a reboot of the system? Does the rpmh
> >processor reboot the system if it crashes?
> We cannot recover from such a state. The remote processor will reboot if
> it detects a failure at it's end. If the system entered a bad state, it
> is possible that RPMH requests start timing out in Linux and remote
> processor may not detect it. Hence, the timeout in rpmh_write() API. The
> advised course of action is a restart as there is no way to recover from
> this state.
>
> --Lina
>
>
On Tue 28 Jul 13:11 PDT 2020, Lina Iyer wrote:
> On Tue, Jul 28 2020 at 13:51 -0600, Stephen Boyd wrote:
> > Quoting Lina Iyer (2020-07-28 09:52:12)
> > > On Mon, Jul 27 2020 at 18:45 -0600, Stephen Boyd wrote:
> > > >Quoting Lina Iyer (2020-07-24 09:28:25)
> > > >> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
> > > >> >Hi Maulik/Lina,
> > > >> >
> > > >> >On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
> > > >> >>Hi Rajendra,
> > > >> >>
> > > >> >>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> > > >> >>below messages on db845:
> > > >> >>
> > > >> >>qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> > > >> >>current OPP for freq 533000097 (-34)
> > > >> >>
> > > >> >>^^^ This one is new.
> > > >> >>
> > > >> >>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
> > > >> >>
> > > >> >>^^^ and this message is annoying, can we make it pr_debug in rpmh?
> > > >> >
> > > >> How annoyingly often do you see this message?
> > > >> Usually, this is an indication of bad system state either on remote
> > > >> processors in the SoC or in Linux itself. On a smooth sailing build you
> > > >> should not see this 'warning'.
> > > >>
> > > >> >Would you be fine with moving this message to a pr_debug? Its currently
> > > >> >a pr_info_ratelimited()
> > > >> I would rather not, moving this out of sight will mask a lot serious
> > > >> issues that otherwise bring attention to the developers.
> > > >>
> > > >
> > > >I removed this warning message in my patch posted to the list[1]. If
> > > >it's a serious problem then I suppose a timeout is more appropriate, on
> > > >the order of several seconds or so and then a pr_warn() and bail out of
> > > >the async call with an error.
> > > >
> > > The warning used to capture issues that happen within a second and it
> > > helps capture system related issues. Timing out after many seconds
> > > overlooks the system issues that generally tend to resolve itself, but
> > > nevertheless need to be investigated.
> > >
> >
> > Is it correct to read "system related issues" as performance problems
> > where the thread is spinning forever trying to send a message and it
> > can't? So the problem is mostly that it's an unbounded amount of time
> > before the message is sent to rpmh and this printk helps identify those
> > situations where that is happening?
> >
> Yes, but mostly a short period of time like when other processors are in
> the middle of a restart or resource states changes have taken unusual
> amounts of time. The system will generally recover from this without
> crashing in this case. User action is investigation of the situation
> leading to these messages.
>
Given that these messages shows up from time and seemingly is harmless,
users such as myself implements the action of ignoring these printouts.
In the cases I do see these messages it seems, as you say, to be related
to something happening in the firmware. So it's not something that a
user typically could investigate/debug anyways.
As such I do second Doug's request of not printing what looks like error
messages unless there is a persistent problem - but provide some means
for the few who would find them useful..
Regards,
Bjorn
> > Otherwise as you say above it's a bad system state where the rpmh
> > processor has gotten into a bad state like a crash? Can we recover from
> > that? Or is the only recovery a reboot of the system? Does the rpmh
> > processor reboot the system if it crashes?
> We cannot recover from such a state. The remote processor will reboot if
> it detects a failure at it's end. If the system entered a bad state, it
> is possible that RPMH requests start timing out in Linux and remote
> processor may not detect it. Hence, the timeout in rpmh_write() API. The
> advised course of action is a restart as there is no way to recover from
> this state.
>
> --Lina
>
>