From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m19731117.qiye.163.com (mail-m19731117.qiye.163.com [220.197.31.117]) (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 5F4B224E4B5 for ; Thu, 30 Jul 2026 05:04:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.117 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785387893; cv=none; b=A302Qz/fKVyWIpHNuSeAHR2uCVdy/mRDUrgkbsZkw95AKXd9fYY4hYlGHnJg7YSuOuMIPcv+1tohQfOVP6wmkGzP1DBvmbBtOpvJRoutouWRM9jb2Z4BjZMCudXTQbrlT5pQE7GqoLjU/rVYqFTFxyX/WXdlKfAXBsEDIvH35C8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785387893; c=relaxed/simple; bh=oAVr4IQtjI/XofpE3vVHnpiy6Fow4V+cDr4p3SMasp8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DrvxYQjJfHT693b077SXCId4pXifgHjjAGTlLuypAHqJSbyKAFMYovFbIvNcZbcYM1K8XuYDb3hCAffD6rjwgIXO7stkPwaiqJk31pMVvi4W/L8Vr7Yau8+aDx3qFhvLiVtTLRyTJpYc1xETXlX/ElmRGQp6POnTU5xnrobLIuY= 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=InTrd8rE; arc=none smtp.client-ip=220.197.31.117 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="InTrd8rE" Received: from [127.0.0.1] (unknown [61.154.14.86]) by smtp.qiye.163.com (Hmail) with ESMTP id 481d48273; Thu, 30 Jul 2026 11:49:02 +0800 (GMT+08:00) Message-ID: Date: Thu, 30 Jul 2026 11:49:00 +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] drm/rockchip: vop2: give rk3576 VP2 a primary plane To: Tomonori Nakagawa , Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Andy Yan Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260729232450.13797-1-jack@supremeoverlordjabs.co> <24547ed2-0950-48be-92cb-bbb0e1653258@rock-chips.com> <7b6b347d-f5d9-45fe-8255-27e01f23578c@supremeoverlordjabs.co> Content-Language: en-US From: Chaoyi Chen In-Reply-To: <7b6b347d-f5d9-45fe-8255-27e01f23578c@supremeoverlordjabs.co> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-HM-Tid: 0a9fb123d26603a7kunme747ba0b4a4eb8 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFITzdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVkZHk4fVktLHRlCGk1CGE5KGVYVFA kWGhdVEwETFhoSFyQUDg9ZV1kYEgtZQVlNSlVKTk9VSk9VQ01ZV1kWGg8SFR0UWUFZT0tIVUpLSU 9PT0hVSktLVUpCS0tZBg++ DKIM-Signature: a=rsa-sha256; b=InTrd8rEXIAzz/o+tE2MmWAT/BagpE1/UvSTJclh6647mKFu5oSGVEKDY5NX9PrMvKoT1W+RcFFCT1rV820atajhNjkP/W3Qsyp55Xzod5LJQWw3w0jlzGbVn/UTkubXh6i+mc6r7HZGPQcQMoQ/uRJPL9XCToxlvFGQcTHNbwM=; s=default; c=relaxed/relaxed; d=rock-chips.com; v=1; bh=X7Mux6FE7z9fKIoWpY6C8S3xx1B7JjI8DMShzGceysM=; h=date:mime-version:subject:message-id:from; On 7/30/2026 11:39 AM, Tomonori Nakagawa wrote: > On 2026/07/30 10:56, Chaoyi Chen wrote: >> The description here is not accurate. VP2 can wire to different >> display interfaces which depending on your board configuration. > > You're right, thanks. VP2 isn't tied to DP - the VP-to-interface > routing is board/DT dependent. The actual issue is the plane topology: > on rk3576 the two Cluster windows (the only DRM_PLANE_TYPE_PRIMARY > windows) both have possible_vp_mask = BIT(0) | BIT(1), so they can only > attach to VP0/VP1. VP2's only attachable windows are the Esmart ones, > which are all DRM_PLANE_TYPE_OVERLAY. So whenever a board's DT wires any > output to video_port2, vop2_create_crtcs() finds no primary plane for it > and fails with -ENOENT ("no primary plane for vp 2"). > > I'll reword the commit message accordingly (dropping the DP framing) in > a v2. Does the fix itself - promoting Esmart0 to PRIMARY - look > acceptable, or would you prefer a different window or a driver-side > approach for VP2's primary? > > > No, it looks good to me. Let's see if anyone else has any opinions. -- Best, Chaoyi