linux-kernel - Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus

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]

Message-ID: <VI1PR04MB5055BED59960B4F4147479AEEED50@VI1PR04MB5055.eurprd04.prod.outlook.com>
Date:   Tue, 6 Aug 2019 13:41:31 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     Artur Świgoń <a.swigon@...tner.samsung.com>,
        Georgi Djakov <georgi.djakov@...aro.org>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-samsung-soc@...r.kernel.org" 
        <linux-samsung-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "krzk@...nel.org" <krzk@...nel.org>,
        "cw00.choi@...sung.com" <cw00.choi@...sung.com>,
        "myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
        "inki.dae@...sung.com" <inki.dae@...sung.com>,
        "sw0312.kim@...sung.com" <sw0312.kim@...sung.com>,
        "georgi.djakov@...aro.org" <georgi.djakov@...aro.org>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>
Subject: Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect
 functionality to exynos-bus

On 23.07.2019 15:21, Artur Świgoń wrote:

> +static int exynos_bus_icc_aggregate(struct icc_node *node, u32 avg_bw,
> +				    u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
> +{
> +	*agg_peak = *agg_avg = peak_bw;
> +
> +	return 0;
> +}

The only current provider aggregates "avg" with "sum" and "peak" with 
"max", any particular reason to do something different? This function 
doesn't even really do aggregation, if there is a second request for "0" 
then the first request is lost.

I didn't find any docs but my interpretation of avg/peak is that "avg" 
is for constant traffic like a display or VPU pushing pixels and "peak" 
is for variable traffic like networking. I assume devices which make 
"peak" requests are aggregated with max because they're not expected to 
all max-out together.

In PATCH 11 you're making a bandwidth request based on resolution, that 
traffic is constant and guaranteed to happend while the display is on so 
it would make sense to request it as an "avg" and aggregate it with "sum".

--
Regards,
Leonard