From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m3286.qiye.163.com (mail-m3286.qiye.163.com [220.197.32.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 781D93546EA for ; Mon, 1 Jun 2026 10:59:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.32.86 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780311583; cv=none; b=bnNiOo8rQq2bYtkYkcyXeRmWD4JYAehSVhqgNmptPKiWWkD3+4Ex67OTDq6uUgiUg6Bot6/voHjVcOG/0ssGgPhVh1R6z5g71mJhgph+xl7bYUQCk3RZM3wjensO9gLpYHShMO+WEVRKEngDVQiG61MH1UMN/W1sKpxfRxlC0Nw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780311583; c=relaxed/simple; bh=EyYZUOZCxfPJ73SW5e6uaKhn4wTWnPuV4oZaJZE3h84=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GEP+pp6GVJzj+CZpQf+IeZpvc6NUg/dlNqxFtXGqeAsOYaeDMfbxrxtcM4G50tF+npefljNJF6mDWH87UZQINVGtaHBRpHlyB4JNruZAOXrEX+PmySRpyPq5NRjvEJY3Zr8Ge/O/pF8F9/NHmIPK6Mcmfd/XYtHU1vvDx0PvGCw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rock-chips.com; spf=pass smtp.mailfrom=rock-chips.com; dkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com header.b=AH7EC9Ux; arc=none smtp.client-ip=220.197.32.86 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rock-chips.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rock-chips.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com header.b="AH7EC9Ux" Received: from [172.16.12.77] (unknown [61.154.14.86]) by smtp.qiye.163.com (Hmail) with ESMTP id 4097ac413; Mon, 1 Jun 2026 18:54:25 +0800 (GMT+08:00) Message-ID: <2d2b6308-ae46-46fd-b1ce-e4f199b6eb27@rock-chips.com> Date: Mon, 1 Jun 2026 18:54:25 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] drm/rockchip: vop2: Fix layer cfg done timeout on multi-output setups To: Cristian Ciocaltea , Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter Cc: kernel@collabora.com, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260504-vop2-layer-cfg-tmout-v1-0-730226a7331e@collabora.com> Content-Language: en-US From: Andy Yan In-Reply-To: <20260504-vop2-layer-cfg-tmout-v1-0-730226a7331e@collabora.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-HM-Tid: 0a9e82d20feb09d8kunmd8c5247738e1b1 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFITzdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVlDGRgZVh0aH05NTxoaSRlDS1YVFA kWGhdVEwETFhoSFyQUDg9ZV1kYEgtZQVlNSlVKTk9VSk9VQ01ZV1kWGg8SFR0UWUFZT0tIVUpLSU 9PT0hVSktLVUpCS0tZBg++ DKIM-Signature: a=rsa-sha256; b=AH7EC9UxGBcgm/HY6FSXgbL+vmU1rG73HwI+2in9EM4d1KmBz3MCI0Lvcr8fTfIbF3+4DsiJd/N/f3rVwvxvq4dmDLaQ3xLM56AzMJgsqrVnOtQF31VVxXnJdc7spp+mgHqfXFP8VLgXCcgyoKRjZTSP+APE8DT+CyswWQg+9/I=; c=relaxed/relaxed; s=default; d=rock-chips.com; v=1; bh=0FP/SMdxTBNjb7CmLP/yRXS7a+fzZXcGFTKpDYjQ04I=; h=date:mime-version:subject:message-id:from; Hello Cristian, On 5/5/26 02:23, Cristian Ciocaltea wrote: > On RK3588/RK3568 boards with multiple active display outputs, start/stop > transitions may trigger a timeout during overlay layer configuration: > > rockchip-drm display-subsystem: [drm] *ERROR* wait layer cfg done timeout > > The shared OVL_LAYER_SEL and OVL_PORT_SEL shadow registers are committed > to the active configuration at the vsync of whichever Video Port is > selected by LAYERSEL_REGDONE_SEL. When two Video Ports race through > atomic commits, rk3568_vop2_setup_layer_mixer() has two issues that > cause the wait to poll for a value the hardware might not be able to > produce. > > Patch 1 fixes passing the wrong target to the wait function, since the > expected value was already overwritten with the current VP's new > layer_sel before reaching the wait. > > Patch 2 moves the wait before the LAYERSEL_REGDONE_SEL switch, so the > previous VP's vsync can still latch the pending configuration. > > Patches 3 through 5 contain only minor follow-up cleanup. > > Signed-off-by: Cristian Ciocaltea Thank you very much for your work, these fixes all look sensible. However, I haven't been able to construct a scenario via weston that reproduce these issues. Could you please tell me how you triggered them? > --- > Cristian Ciocaltea (5): > drm/rockchip: vop2: Fix wrong wait target in layer cfg done check > drm/rockchip: vop2: Wait for layer cfg done before switching LAYERSEL_REGDONE_SEL > drm/rockchip: vop2: Delay old_{layer|port}_sel updates in setup_layer_mixer() > drm/rockchip: vop2: Drop redundant zero-init in setup_layer_mixer() > drm/rockchip: vop2: Use vop2->old_layer_sel directly in wait_for_layer_cfg_done() > > drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 46 +++++++++++++--------------- > 1 file changed, 22 insertions(+), 24 deletions(-) > --- > base-commit: d4c14903bf5e28e740516c4fbb7db01e0dedf3af > change-id: 20260504-vop2-layer-cfg-tmout-73617a0a103c > >