From: Georgi Djakov <georgi.djakov@linaro.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
Vikash Garodia <vgarodia@codeaurora.org>,
Andy Gross <agross@kernel.org>,
Aniket Masule <amasule@codeaurora.org>,
Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [PATCH 1/2] venus: use on-chip interconnect API
Date: Thu, 12 Sep 2019 18:11:55 +0300 [thread overview]
Message-ID: <345e7450-b3af-92c5-4e83-bccaf0a98a0b@linaro.org> (raw)
In-Reply-To: <20190904042203.GC3081@tuxbook-pro>
Hi Bjorn,
On 9/4/19 07:22, Bjorn Andersson wrote:
> On Tue 20 Aug 02:34 PDT 2019, Georgi Djakov wrote:
>
>> Hi Stan,
>>
>> On 8/14/19 11:47, Stanimir Varbanov wrote:
>>> This aims to add a requests for bandwidth scaling depending
>>> on the resolution and framerate (macroblocks per second). The
>>> exact value ff the requested bandwidth is get from a
>>
>> s/ff/of/
>>
>>> pre-calculated tables for encoder and decoder.
>>>
>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>>> ---
>>> drivers/media/platform/qcom/venus/core.c | 34 +++++++++++
>>> drivers/media/platform/qcom/venus/core.h | 14 +++++
>>> drivers/media/platform/qcom/venus/helpers.c | 67 ++++++++++++++++++++-
>>> 3 files changed, 114 insertions(+), 1 deletion(-)
>>
>> It looks like venus can be built-in, so how about the case when venus is
>> built-in and the interconnect provider is a module? Maybe add a dependency in
>> Kconfig to depend on INTERCONNECT || !INTERCONNECT?
>>
>
> I've been struggling down this road for remoteproc et al for a long
> time, I strongly suggest that you make the INTERCONNECT config bool, to
> ensure that we don't see this problem for every client.
Thanks for the comment. Well, i was expecting that we will have to make it bool
one day. Viresh actually already sent a patch [1]. Maybe you can add an Ack?
>
> The interconnect framework should hide the fact that the provider is
> module.
>
Correct.
>
> But with this in place is there actually a dependency? Won't the include
> file provide stubs in the case of !INTERCONNECT?
There are stubs, so we are fine.
Thanks,
Georgi
[1]
https://lore.kernel.org/linux-pm/b789cce388dd1f2906492f307dea6780c398bc6a.1567065991.git.viresh.kumar@linaro.org/
prev parent reply other threads:[~2019-09-12 15:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190814084701.25455-1-stanimir.varbanov@linaro.org>
[not found] ` <20190814084701.25455-2-stanimir.varbanov@linaro.org>
2019-08-20 9:34 ` [PATCH 1/2] venus: use on-chip interconnect API Georgi Djakov
2019-08-21 7:53 ` Stanimir Varbanov
2019-09-04 4:22 ` Bjorn Andersson
2019-09-12 15:11 ` Georgi Djakov [this message]
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=345e7450-b3af-92c5-4e83-bccaf0a98a0b@linaro.org \
--to=georgi.djakov@linaro.org \
--cc=agross@kernel.org \
--cc=amasule@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).