linux-kernel - Re: [PATCH 1/2] venus: use on-chip interconnect API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 12 Sep 2019 18:11:55 +0300
From:   Georgi Djakov <georgi.djakov@...aro.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        Vikash Garodia <vgarodia@...eaurora.org>,
        Andy Gross <agross@...nel.org>,
        Aniket Masule <amasule@...eaurora.org>,
        Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 1/2] venus: use on-chip interconnect API

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@...aro.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/