[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240110155148.6383-1-jason-jh.lin@mediatek.com>
Date: Wed, 10 Jan 2024 23:51:46 +0800
From: Jason-JH.Lin <jason-jh.lin@...iatek.com>
To: Jassi Brar <jassisinghbrar@...il.com>, Matthias Brugger
<matthias.bgg@...il.com>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>, Chun-Kuang Hu
<chunkuang.hu@...nel.org>
CC: <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<linux-mediatek@...ts.infradead.org>, Jason-ch Chen
<jason-ch.chen@...iatek.com>, Johnson Wang <johnson.wang@...iatek.com>,
"Jason-JH . Lin" <jason-jh.lin@...iatek.com>, Singo Chang
<singo.chang@...iatek.com>, Nancy Lin <nancy.lin@...iatek.com>, Shawn Sung
<shawn.sung@...iatek.com>,
<Project_Global_Chrome_Upstream_Group@...iatek.com>, Jason-jh Lin
<jason-jh.lin@...iatek.corp-partner.google.com>
Subject: [PATCH 0/2] Change GCE hardware timeout to software timeout
From: Jason-jh Lin <jason-jh.lin@...iatek.corp-partner.google.com>
Since the max value of GCE hardware interrupt timeout for wait and poll
instructions is about 1760ms.
It is not enough for the use case of ISP driver below:
GCE Thread A: wait for SOF and set event 1.
GCE Thread B: wait for event 1 and set event 2.
GCE Thread C: wait for event 2 and set event 3.
GCE Thread D: wait for event 3 and set event 4.
GCE Thread E: wait for event 4 and set EOF.
If all GCE Threads start at the same time, the latest GCE Thread E will
wait for event more than 2 seconds.
Therefore, we changed the hardware timeout to software timeout, making it
longer, more certain, and making it configurable by CMDQ client drivers.
Jason-JH.Lin (2):
mailbox: mtk-cmdq: Change GCE hardware timeout to software timeout
mailbox: mtk-cmdq: Add set GCE thread timeout interface
drivers/mailbox/mtk-cmdq-mailbox.c | 183 +++++++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 4 +
2 files changed, 187 insertions(+)
--
2.18.0
Powered by blists - more mailing lists