Re: [PATCH 1/2] venus: use on-chip interconnect API
From: Georgi Djakov
Date: Thu Sep 12 2019 - 11:12:04 EST
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
>>> pre-calculated tables for encoder and decoder.
>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx>
>>> 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 . Maybe you can add an Ack?
> The interconnect framework should hide the fact that the provider is
> 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.