Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <59f53724-87fe-97b8-0660-dcb1a5b464fe@samsung.com>
Date:   Wed, 18 May 2022 12:56:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0)
        Gecko/20100101 Thunderbird/91.9.0
Subject: Re: [PATCH v5 0/4] PM / devfreq: Add cpu based scaling support to
 passive governor
Content-Language: en-US
To:     Chanwoo Choi <cw00.choi@samsung.com>, linux-pm@vger.kernel.org,
        linux-kernel@vger.kernel.org
Cc:     johnson.wang@mediatek.com, mka@chromium.org, wenst@chromium.org,
        jia-wei.chang@mediatek.com, andrew-sh.cheng@mediatek.com,
        hsinyi@chromium.org, saravanak@google.com,
        myungjoo.ham@samsung.com, kyungmin.park@samsung.com
From:   Marek Szyprowski <m.szyprowski@samsung.com>
In-Reply-To: <20220517092108.31680-1-cw00.choi@samsung.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <CGME20220517085446epcas1p4c07ab7d3b80d62c0093c3a45484eae97@epcas1p4.samsung.com>
        <20220517092108.31680-1-cw00.choi@samsung.com>
Precedence: bulk

Hi,

On 17.05.2022 11:21, Chanwoo Choi wrote:
> The devfreq passive governor has already supported the devfreq parent device
> for coupling the frequency change if some hardware have the constraints
> such as power sharing and so on.
>
> Add cpu based scaling support to passive governor with required-opp property.
> It uses the cpufreq notifier to catch the frequency change timing of cpufreq
> and get the next frequency according to new cpu frequency by using required-opp
> property. It is based on patch[1] and then just code clean-up by myself.
>
> Make the common code for both passive_devfreq and passive_cpufreq
> parent type to remove the duplicate code.

I've just tested it on Exynos based boards and on all I see the 
following issues after system suspend/resume cycle:

# time rtcwake -s10 -mmem
rtcwake: wakeup from "mem" using /dev/rtc0 at Wed May 18 11:13:16 2022
PM: suspend entry (deep)
Filesystems sync: 0.001 seconds
Freezing user space processes ... (elapsed 0.002 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.

...

devfreq soc:bus-disp1-fimd: failed to suspend devfreq device
devfreq soc:bus-jpeg-apb: failed to suspend devfreq device
devfreq soc:bus-jpeg: failed to suspend devfreq device
devfreq soc:bus-g2d-acp: failed to suspend devfreq device
devfreq soc:bus-g2d: failed to suspend devfreq device
devfreq soc:bus-peri: failed to suspend devfreq device
devfreq soc:bus-gen: failed to suspend devfreq device
devfreq soc:bus-mfc: failed to suspend devfreq device
devfreq soc:bus-fsys2: failed to suspend devfreq device
devfreq soc:bus-fsys-apb: failed to suspend devfreq device
devfreq soc:bus-noc: failed to suspend devfreq device
...
Disabling non-boot CPUs ...
Enabling non-boot CPUs ...
...
devfreq soc:bus-mscl: failed to resume devfreq device
devfreq soc:bus-gscl-scaler: failed to resume devfreq device
devfreq soc:bus-disp1: failed to resume devfreq device
devfreq soc:bus-disp1-fimd: failed to resume devfreq device
devfreq soc:bus-jpeg-apb: failed to resume devfreq device
devfreq soc:bus-jpeg: failed to resume devfreq device
devfreq soc:bus-g2d-acp: failed to resume devfreq device
devfreq soc:bus-g2d: failed to resume devfreq device
devfreq soc:bus-peri: failed to resume devfreq device
devfreq soc:bus-gen: failed to resume devfreq device
devfreq soc:bus-mfc: failed to resume devfreq device
devfreq soc:bus-fsys2: failed to resume devfreq device
devfreq soc:bus-fsys-apb: failed to resume devfreq device
devfreq soc:bus-noc: failed to resume devfreq device

Some boards (like Trats2) after suspend/resume cycle reveals random crashes.

All those issues were not observed before applying this patchset.

> [1] [RFC,v2] PM / devfreq: Add cpu based scaling support to passive_governor
> - https://lore.kernel.org/patchwork/patch/1101049/
>
> Changes from v4:
> : https://patchwork.kernel.org/project/linux-pm/cover/20220511093554.17535-1-cw00.choi@samsung.com/
> - Fix issue[2] reported by Marek Szyprowski
> [2] https://patchwork.kernel.org/project/linux-pm/patch/20220511093554.17535-3-cw00.choi@samsung.com/
>
> Changes from v3:
> : ttps://patchwork.kernel.org/project/linux-pm/cover/20220509120337.92472-1-cw00.choi@samsung.com/
> - Add tested-by tag of both Chen-Yu Tsai and Johnson Wang
> - Fix some typo
>
> Changes from v2:
> : https://patchwork.kernel.org/project/linux-pm/cover/20220507150145.531864-1-cw00.choi@samsung.com/
> - Drop the following patch ("PM / devfreq: passive: Update frequency when start governor")
> - Move p_data->this initialization into cpufreq_passive_regiser_notifier()
>
> Changes from v1:
> : https://patchwork.kernel.org/project/linux-pm/cover/20210617060546.26933-1-cw00.choi@samsung.com/
> - Rename cpu_data variable to parent_cpu_data to avoid build fail
> - Use for_each_possible_cpu macro when register cpufreq transition notifier
> - Add missing exception handling when cpufreq_passive_register_notifier is failed
> - Keep cpufreq_policy for posible cpus instead of NR_CPU in order to avoid
>    the memory waste when NR_CPU is too high.
> - Add reviewed-by tag of Matthias Kaehlcke for patch1
>
> Chanwoo Choi (3):
>    PM / devfreq: Export devfreq_get_freq_range symbol within devfreq
>    PM / devfreq: passive: Reduce duplicate code when passive_devfreq case
>    PM / devfreq: passive: Keep cpufreq_policy for possible cpus
>
> Saravana Kannan (1):
>    PM / devfreq: Add cpu based scaling support to passive governor
>
>   drivers/devfreq/devfreq.c          |  20 +-
>   drivers/devfreq/governor.h         |  27 ++
>   drivers/devfreq/governor_passive.c | 403 ++++++++++++++++++++++++-----
>   include/linux/devfreq.h            |  17 +-
>   4 files changed, 389 insertions(+), 78 deletions(-)
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland