[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250214074353.1169864-1-chun-jen.tseng@mediatek.com>
Date: Fri, 14 Feb 2025 15:43:31 +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 v3 0/3] 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 v2:
- seperate more patch for detail change.
- remove CCI transition_delay patch
Mark Tseng (3):
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 | 63 ++++++++++++++++++++++--------
1 file changed, 46 insertions(+), 17 deletions(-)
--
2.45.2
Powered by blists - more mailing lists