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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 03 Jan 2019 14:53:51 -0800
From:   Stephen Boyd <swboyd@...omium.org>
To:     Henry Chen <henryc.chen@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Viresh Kumar <vireshk@...nel.org>
Cc:     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

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.

> 2. Active state management of power domains[1]: to handle the operating
>    voltage opp requirement from different power domains

Do you have any devices that aren't "OPP-ish" in how they use
frequencies and voltages? What I mean is devices such as i2c, SPI, UART
controllers that don't use the OPP library to set a frequency but want
to affect some voltage of their power domain when clk frequencies
change. The existing code works well for devices that naturally use the
OPP rate changing API, typically multimedia devices that churn through
data like a CPU and don't care about the frequency of their main clk
because it doesn't match physical link bit rates, etc. I haven't seen
any good solution for devices that don't fit well with the OPP API
though so I'm curious if Mediatek needs to solve that problem. 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ