[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3ec20339-b176-4d39-8cbe-4577a782aeec@collabora.com>
Date: Tue, 12 Mar 2024 15:41:46 +0100
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Pin-yen Lin <treapking@...omium.org>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>
Cc: Chen-Yu Tsai <wenst@...omium.org>, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, Weiyi Lu <weiyi.lu@...iatek.com>,
linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
Bosi Zhang <u201911157@...t.edu.cn>, Nicolas Boichat
<drinkcat@...omium.org>, Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH v4] clk: mediatek: Do a runtime PM get on controllers
during probe
Il 12/03/24 12:51, Pin-yen Lin ha scritto:
> mt8183-mfgcfg has a mutual dependency with genpd during the probing
> stage, which leads to a deadlock in the following call stack:
>
> CPU0: genpd_lock --> clk_prepare_lock
> genpd_power_off_work_fn()
> genpd_lock()
> generic_pm_domain::power_off()
> clk_unprepare()
> clk_prepare_lock()
>
> CPU1: clk_prepare_lock --> genpd_lock
> clk_register()
> __clk_core_init()
> clk_prepare_lock()
> clk_pm_runtime_get()
> genpd_lock()
>
> Do a runtime PM get at the probe function to make sure clk_register()
> won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,
> do this on all mediatek clock controller probings because we don't
> believe this would cause any regression.
>
> Verified on MT8183 and MT8192 Chromebooks.
>
> Fixes: acddfc2c261b ("clk: mediatek: Add MT8183 clock support")
> Signed-off-by: Pin-yen Lin <treapking@...omium.org>
>
MT8195 Cherry Tomato - no issues as well.
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Powered by blists - more mailing lists