From: amasule@codeaurora.org
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, vgarodia@codeaurora.org
Subject: Re: [PATCH v3 2/4] media: venus: Update clock scaling
Date: Tue, 02 Jul 2019 10:29:10 +0530 [thread overview]
Message-ID: <84a42501461f4aee29815a0609fdef8d@codeaurora.org> (raw)
In-Reply-To: <69610fc3-5333-ccc6-316f-aee96dc11150@linaro.org>
Hi Stan,
On 2019-07-01 18:41, Stanimir Varbanov wrote:
> On 6/25/19 7:27 PM, Aniket Masule wrote:
>> Current clock scaling calculations are same for vpu4 and
>> previous versions. For vpu4, Clock scaling calculations
>> are updated with cycles/mb. This helps in getting precise
>> clock required.
>>
>> Signed-off-by: Aniket Masule <amasule@codeaurora.org>
>> ---
>> drivers/media/platform/qcom/venus/helpers.c | 111
>> ++++++++++++++++++++++++----
>> drivers/media/platform/qcom/venus/helpers.h | 2 +-
>> drivers/media/platform/qcom/venus/vdec.c | 2 +-
>> drivers/media/platform/qcom/venus/venc.c | 2 +-
>> 4 files changed, 99 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/helpers.c
>> b/drivers/media/platform/qcom/venus/helpers.c
>> index f7f724b..e1a0247 100644
>> --- a/drivers/media/platform/qcom/venus/helpers.c
>> +++ b/drivers/media/platform/qcom/venus/helpers.c
>> @@ -348,8 +348,9 @@ static u32 load_per_type(struct venus_core *core,
>> u32 session_type)
>> return mbs_per_sec;
>> }
>>
>> -static int load_scale_clocks(struct venus_core *core)
>> +static int scale_clocks(struct venus_inst *inst)
>> {
>> + struct venus_core *core = inst->core;
>> const struct freq_tbl *table = core->res->freq_tbl;
>> unsigned int num_rows = core->res->freq_tbl_size;
>> unsigned long freq = table[0].freq;
>> @@ -398,6 +399,86 @@ static int load_scale_clocks(struct venus_core
>> *core)
>> return ret;
>> }
>>
>> +static unsigned long calculate_vpp_freq(struct venus_inst *inst)
>> +{
>> + unsigned long vpp_freq = 0;
>> + u32 mbs_per_sec;
>> +
>> + mbs_per_sec = load_per_instance(inst);
>> + vpp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
>> + /* 21 / 20 is overhead factor */
>> + vpp_freq += vpp_freq / 20;
>> +
>> + return vpp_freq;
>> +}
>> +
>> +static int scale_clocks_v4(struct venus_inst *inst)
>> +{
>> + struct venus_core *core = inst->core;
>> + const struct freq_tbl *table = core->res->freq_tbl;
>> + unsigned int num_rows = core->res->freq_tbl_size;
>> +
>
> please remove this blank line.
>
>> + struct clk *clk = core->clks[0];
>> + struct device *dev = core->dev;
>> + unsigned int i;
>> + unsigned long freq = 0, freq_core0 = 0, freq_core1 = 0;
>
> could you count the cores as it is done for VIDC_CORE_ID_ ?
> i.e. start counting from one.
>
Sure, I was aligning it with clock handle name in core, but
aligning it with VIDC_CORE_ID_ would give good readability.
>> + int ret;
>> +
>> + freq = calculate_vpp_freq(inst);
>> +
>> + if (freq > table[0].freq)
>> + goto err;
>
> if the goto is triggered the error message will be wrong. Infact the
> dev_err message is targeted for clk_set_rate failure.
>
I will add separate exit for this.
>> +
>> + for (i = 0; i < num_rows; i++) {
>> + if (freq > table[i].freq)
>> + break;
>> + freq = table[i].freq;
>> + }
>> +
>> + inst->clk_data.freq = freq;
>> +
>> + mutex_lock(&core->lock);
>> + list_for_each_entry(inst, &core->instances, list) {
>> + if (inst->clk_data.core_id == VIDC_CORE_ID_1) {
>> + freq_core0 += inst->clk_data.freq;
>> + } else if (inst->clk_data.core_id == VIDC_CORE_ID_2) {
>> + freq_core1 += inst->clk_data.freq;
>> + } else if (inst->clk_data.core_id == VIDC_CORE_ID_3) {
>> + freq_core0 += inst->clk_data.freq;
>> + freq_core1 += inst->clk_data.freq;
>> + }
>> + }
>> + mutex_unlock(&core->lock);
>> +
>> + freq = max(freq_core0, freq_core1);
>> +
>> + ret = clk_set_rate(clk, freq);
>> + if (ret)
>> + goto err;
>> +
>> + ret = clk_set_rate(core->core0_clk, freq);
>> + if (ret)
>> + goto err;
>> +
>> + ret = clk_set_rate(core->core1_clk, freq);
>> + if (ret)
>> + goto err;
>> +
>> + return 0;
>> +
>> +err:
>> + dev_err(dev, "failed to set clock rate %lu (%d)\n", freq, ret);
>> + return ret;
>> +}
>> +
>> +static int load_scale_clocks(struct venus_inst *inst)
>> +{
>> + if (IS_V4(inst->core))
>> + return scale_clocks_v4(inst);
>> +
>> + return scale_clocks(inst);
>> +}
>> +
>> static void fill_buffer_desc(const struct venus_buffer *buf,
>> struct hfi_buffer_desc *bd, bool response)
>> {
>> @@ -715,35 +796,36 @@ int venus_helper_set_core_usage(struct
>> venus_inst *inst, u32 usage)
>> }
>> EXPORT_SYMBOL_GPL(venus_helper_set_core_usage);
>>
>> -int venus_helper_init_codec_data(struct venus_inst *inst)
>> +int venus_helper_init_codec_freq_data(struct venus_inst *inst)
>> {
>> - const struct codec_data *codec_data;
>> - unsigned int i, codec_data_size;
>
> those deletions shouldn't exist once you fix the git rebase issue.
>
>> + const struct codec_freq_data *codec_freq_data;
>> + unsigned int i, codec_freq_data_size;
>
> could you rename the variables to shorter?
>
Yes
>> u32 pixfmt;
>> int ret = 0;
>>
>> if (!IS_V4(inst->core))
>> return 0;
>>
>> - codec_data = inst->core->res->codec_data;
>> - codec_data_size = inst->core->res->codec_data_size;
>> + codec_freq_data = inst->core->res->codec_freq_data;
>> + codec_freq_data_size = inst->core->res->codec_freq_data_size;
>> pixfmt = inst->session_type == VIDC_SESSION_TYPE_DEC ?
>> inst->fmt_out->pixfmt : inst->fmt_cap->pixfmt;
>>
>> - for (i = 0; i < codec_data_size; i++) {
>> - if (codec_data[i].pixfmt == pixfmt &&
>> - codec_data[i].session_type == inst->session_type) {
>> - inst->clk_data.codec_data = &codec_data[i];
>> + for (i = 0; i < codec_freq_data_size; i++) {
>> + if (codec_freq_data[i].pixfmt == pixfmt &&
>> + codec_freq_data[i].session_type == inst->session_type) {
>> + inst->clk_data.codec_freq_data =
>> + &codec_freq_data[i];
>> break;
>> }
>> }
>>
>> - if (!inst->clk_data.codec_data)
>> + if (!inst->clk_data.codec_freq_data)
>> ret = -EINVAL;
>>
>> return ret;
>> }
>> -EXPORT_SYMBOL_GPL(venus_helper_init_codec_data);
>> +EXPORT_SYMBOL_GPL(venus_helper_init_codec_freq_data);
>>
Thanks,
Aniket
next prev parent reply other threads:[~2019-07-02 4:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-25 16:27 [PATCH v3 0/4] media: venus: Update clock scaling and core selection Aniket Masule
2019-06-25 16:27 ` [PATCH v3 1/4] media: venus: Add codec data table Aniket Masule
2019-07-01 11:43 ` Stanimir Varbanov
2019-07-02 4:55 ` amasule
2019-06-25 16:27 ` [PATCH v3 2/4] media: venus: Update clock scaling Aniket Masule
2019-07-01 13:11 ` Stanimir Varbanov
2019-07-02 4:59 ` amasule [this message]
2019-06-25 16:27 ` [PATCH v3 3/4] media: venus: Add interface for load per core Aniket Masule
2019-07-01 13:55 ` Stanimir Varbanov
2019-06-25 16:27 ` [PATCH v3 4/4] media: venus: Update core selection Aniket Masule
2019-07-01 13:58 ` Stanimir Varbanov
2019-07-02 5:01 ` amasule
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84a42501461f4aee29815a0609fdef8d@codeaurora.org \
--to=amasule@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=stanimir.varbanov@linaro.org \
--cc=vgarodia@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.