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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <08d15fa8-7e53-518c-54bb-8050b0e4aabd@linaro.org>
Date:   Mon, 7 Jan 2019 18:34:54 +0200
From:   Georgi Djakov <georgi.djakov@...aro.org>
To:     Henry Chen <henryc.chen@...iatek.com>,
        Stephen Boyd <swboyd@...omium.org>
Cc:     Matthias Brugger <matthias.bgg@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Viresh Kumar <vireshk@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Fan Chen <fan.chen@...iatek.com>,
        Weiyi Lu <weiyi.lu@...iatek.com>,
        James Liao <jamesjj.liao@...iatek.com>,
        Kees Cook <keescook@...omium.org>, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC RESEND PATCH 0/7] Add driver for dvfsrc and add support for
 active state of scpsys on mt8183

Hi Henry,

On 1/7/19 13:04, Henry Chen wrote:
> On Thu, 2019-01-03 at 14:53 -0800, Stephen Boyd wrote:
>> Quoting Henry Chen (2019-01-02 06:09:51)
>>> The patchsets add support for MediaTek hardware module named DVFSRC
>>> (dynamic voltage and frequency scaling resource collector). The DVFSRC is
>>> a HW module which is used to collect all the requests from both software
>>> and hardware and turn into the decision of minimum operating voltage and
>>> minimum DRAM frequency to fulfill those requests.
>>>
>>> So, This series is to implement the dvfsrc driver to collect all the
>>> requests of operating voltage or DRAM bandwidth from other device drivers
>>> likes GPU/Camera through 2 frameworks basically:
>>>
>>> 1. PM_QOS_MEMORY_BANDWIDTH from PM QOS: to aggregate the bandwidth
>>>    requirements from different clients
>>
>> Have you looked at using the interconnect framework for this instead of
>> using PM_QOS_MEMORY_BANDWIDTH? Qcom is pushing an interconnect framework
>> to do DRAM bandwidth requirement aggregation.
> 
> Sorry, I haven't heard that before. Do you mean is following series
> patch?
> https://patchwork.kernel.org/project/linux-arm-msm/list/?series=53775
> 

Yes, this one. The idea is that consumer drivers like GPU, camera, video
encoder etc. report their bandwidth needs by using the interconnect API.
The framework does the aggregation and configures the hardware. In order
to use it you need to implement a platform-specific dvfsrc interconnect
provider driver that understands the SoC topology and knows how to
configure the hardware. I am not familiar with DVFSRC, but it seems to
me that it can fit as interconnect provider.
Does this HW module support any QoS priority/latency configuration or is
it only bandwidth and voltage?

Thanks,
Georgi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ