[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241108063942.19744-1-chun-jen.tseng@mediatek.com>
Date: Fri, 8 Nov 2024 14:39:38 +0800
From: Mark Tseng <chun-jen.tseng@...iatek.com>
To: "Rafael J . Wysocki" <rafael@...nel.org>, Viresh Kumar
<viresh.kumar@...aro.org>, MyungJoo Ham <myungjoo.ham@...sung.com>, "Kyungmin
Park" <kyungmin.park@...sung.com>, Chanwoo Choi <cw00.choi@...sung.com>,
Matthias Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
CC: <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <linux-mediatek@...ts.infradead.org>,
<Project_Global_Chrome_Upstream_Group@...iatek.com>,
<chun-jen.tseng@...iatek.com>
Subject: [PATCH v2 0/4] fixed mediatek-cpufreq has multi policy concurrency issue
For multi cluster SoC, the cpufreq->target_index() is re-enter function
for each policy to change CPU frequency. In the cirtical session must
use glocal mutex lock to avoid get wrong OPP.
Changes since v1:
- seperate more patch for detail change.
Mark Tseng (4):
cpufreq: mediatek: CCI support SoC , the transition_delay set to 10 ms
cpufreq: mediatek: using global lock avoid race condition
cpufreq: mediatek: Add CPUFREQ_ASYNC_NOTIFICATION flag
cpufreq: mediatek: data safety protect
drivers/cpufreq/mediatek-cpufreq.c | 65 ++++++++++++++++++++++--------
1 file changed, 49 insertions(+), 16 deletions(-)
--
2.45.2
Powered by blists - more mailing lists