From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f52.google.com (mail-yx1-f52.google.com [74.125.224.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DFBA33970F for ; Mon, 26 Jan 2026 13:29:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.224.52 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769434199; cv=pass; b=oarzYp3wwTXtq3ZtQQJYVyxmZA/S1vrtRdBjpqb/5ES12ImtlZ2FSVsKdiGYCtQg81H0ao2JLcUYA9hk/QqF7islA4IRcXpH7WfmjxA6znWVYYMBi77YzIB4Eb+Gtf7cTEu3ppnuv0J8UmMTv2ZtcH4D3VEeI9L/fg21fFWUuBY= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769434199; c=relaxed/simple; bh=VhdpWK7kO7qkYEVQukaKkH6CQSMUVKXWtBqo51Fh59g=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dMs0S1+8njknaDtVgkuTQjNkjWxHx7hXpRZTUZ3vQXzNRziJJT2qnfELJcMnMBO8wv5XeYhGaKI52IJg1Zyl8/MeCIV8NKAs5xSs0qXeD/sTaA4cNauV9g/jArHikYahPlbsPPI0akbbNhCSfiY8x70Lx8HJEImtAN7Koox786M= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=qo9N7EYd; arc=pass smtp.client-ip=74.125.224.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="qo9N7EYd" Received: by mail-yx1-f52.google.com with SMTP id 956f58d0204a3-6496b6903c9so1315393d50.2 for ; Mon, 26 Jan 2026 05:29:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769434196; cv=none; d=google.com; s=arc-20240605; b=RELlCyIO13cEK9SXaXi9CrdJFO3gN0HN/8uiNLTYETBaT0OpendSzQ4CXJA4bQYXOE mNZ3XURhAepUonrKj1+G2P8mU72JQKLQpdN7LwCBwQX3nqF1o7mb3m1Y2WuPft791AIp 3ybvyHtMq3mrAEfClfkRoWZwruQ/8tMAsUaOP1uBgnLXAqcAjPxBYti6DmJROuvUdCPI 9YSC3JJMplmo7EdR/8qU+2yDZn28ijCTrs9bHbC8V9anXHaBAJBS6P5Xt0lO7SYJaLhY Hf/ZQIMp93RMFgNtEuB730ieu7v/kkBAc1DUCXzOY+8C11p40ogn0coVd+fqdDCulxuq ybfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ajOlSiOtNMWfjsoQse/ifbqmB3q8/dPWLyWb9EMEP9E=; fh=Xo1gEvUwhcTiVV2dYolL207Zw0eHdTPsnBhTtjb/F64=; b=NGxzaTrKMmoJII5HpeRlk70+ASB2uG7QOidefZ43zpNmFlDVEWhxUKQQ0C+JNEayrx xxUxb0XGPjm55fvlP60Ne2NYonnce3Ud7AsiUz7zbeekiqCurSmTkaPxBHDY3JIewNeH Cb8My880MXO4cH2iuKAgYbOtLXWStA+bo7DFMSg+qwNBUY9o/S0XuqohDZsyv3Gu7a8g JzZdtfrd6nhSmjsFci5XwQAXrB2brJ+GzGIVqBGMRxwuP7shOARVNdb9G9VUTXNpn6cC 8ns1tD7jIKbDl7SE2m37rAm6A9r0Ojc9f7L5ad+EHRAF7zaqs05aJodLVJuoyRkrcS6f eSSA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1769434196; x=1770038996; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ajOlSiOtNMWfjsoQse/ifbqmB3q8/dPWLyWb9EMEP9E=; b=qo9N7EYd6lFqI+p4wFc5hdZ1RE3OQMGpopoLoECq5f7C3j7/qPxM2XpCIjPfCqrpLd OQa6Ux3PU9xp3VNBy6S+8undOddfoN3/Vi2nURZMiAxxuSogaR1d63Y8F55VDZt2kOFz zJ0WIkvwey12aTmYRIzXvZSoie/lEwbFkGY2EBH32MgRo6OGU/Myyo7J6qm8jhwvGqYj dvHodiJ/hqaRe9MlSiyhBss4NnhRomfuTdipI3FiuOYRMfkpag10VXJ3afDsZcRLwdyD ZOvDb/9dwveE00/pwOb+YwCgetbYH128VmQjy9WzJmFBU2ZmA5PqAp3dqz0i1lkd6XKz ZQGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769434196; x=1770038996; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ajOlSiOtNMWfjsoQse/ifbqmB3q8/dPWLyWb9EMEP9E=; b=Sl4rzEEGl2OPtCq2pg7xW4VNLwqZU+nAMLs0FHG011PLR2hmI/AfW4xZaJXmnlq0la 9ZlN2gSY/N77VNkcJNO87hRXwex5cOfR3A9g7fUIHroTav3iq0E948/Sx5Yjl6ImdJUR 1vhop/YB3JtcAX1FuQiacQAHdNXYtvQFwaI73Drdz0vKAt09dj+rfsl5HoSvAWTbAWss kQBnExwGsSdFhjk/MbM5wm9c2VqH8gBXN0IU+MR+mTeZiMYVieSaGAp5DKmodGtGiCzc H+J6qoaPbxw07XKM5g5awLDSPO/n5ums4NIewcvhdDoznweZQglI2HtQitWuDoP0lIAj /TmQ== X-Forwarded-Encrypted: i=1; AJvYcCU71q7U4YX/qdtSNlXWyLXAFOt8Ft6Ot2iBmH1UHmrIVsDLK6IEhQNJ8MNs9jkGaHLunqa2+MUi/nVpjv4=@vger.kernel.org X-Gm-Message-State: AOJu0Yy96Me6aGURSV+gJnmWkdfw9IvaP0sPZGFRoSjq0FHFgCk63gBc 9xUIabs2xGkhh++jtK6bOTtGwGt7dbSfKqgW2+YYmAwHreGv4lvfix7td2UrxgJRqOXtaK8wdUs SNGuo5Ed36oh9wGhajtQZQnH9QlXwnpTtSFY0XX8jNA== X-Gm-Gg: AZuq6aKM/TC37IhkU87pOQADjKebUB5tIWurOCDmtj7uFd9mbsfSpZJhl76Idkvb+Qm UBim1Etaiu3LKqNh/OVFE3k+dq40gMOe+xVR9756saaCSr+xdmG9+ZywlzyRLY0l2rz1au0ugPk 9lr9yXgYB88rH6xVM7gwj7hMt4tSpWYy4K/e54lGnJfG5/irbz2VbR5BL7h5PvzBL/Ku7MWROe0 ag59bW1BoKDKgK2dZZ2Pmri4iClkglrGZ+Az90CWQOScSSTEgqAWEFO6UEKm6lOidgmMnwy2dPI o45WvqvHqlWeFSJd X-Received: by 2002:a53:ac89:0:b0:649:6074:9d3c with SMTP id 956f58d0204a3-64970c9fdf9mr3532659d50.54.1769434196536; Mon, 26 Jan 2026 05:29:56 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260121-msm-next-quad-pipe-split-v17-0-6eb6d8675ca2@linaro.org> <20260121-msm-next-quad-pipe-split-v17-2-6eb6d8675ca2@linaro.org> <6kzd2g4hgffqz5ipaqbourgiefuxxh3njj44n35blo37z6hhhj@us7lzlgmjuld> <91d590de-fa00-4df3-923f-b49ad00cd9da@oss.qualcomm.com> <7c3yxfkadtkd6xs6aiupcamykx75c2tieakc7n4a2jyymz6kzz@4gflcto2nbkj> In-Reply-To: <7c3yxfkadtkd6xs6aiupcamykx75c2tieakc7n4a2jyymz6kzz@4gflcto2nbkj> From: Jun Nie Date: Mon, 26 Jan 2026 21:29:44 +0800 X-Gm-Features: AZwV_QhrhzX3QFcHeAIEwxeWZf4Y6oIwMBcL2-B9HiItZYabjyPzZqC41KwRdrs Message-ID: Subject: Re: [PATCH v17 2/4] drm/msm/dpu: Defer SSPP allocation until CRTC check To: Dmitry Baryshkov Cc: Abhinav Kumar , Dmitry Baryshkov , Sean Paul , Marijn Suijten , David Airlie , Simona Vetter , Rob Clark , Neil Armstrong , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dmitry Baryshkov =E4=BA=8E2026=E5=B9=B4= 1=E6=9C=8826=E6=97=A5=E5=91=A8=E4=B8=80 20:31=E5=86=99=E9=81=93=EF=BC=9A > > On Mon, Jan 26, 2026 at 08:01:00PM +0800, Jun Nie wrote: > > Dmitry Baryshkov =E4=BA=8E2026=E5= =B9=B41=E6=9C=8826=E6=97=A5=E5=91=A8=E4=B8=80 18:49=E5=86=99=E9=81=93=EF=BC= =9A > > > > > > On 26/01/2026 12:29, Jun Nie wrote: > > > > Dmitry Baryshkov =E4=BA=8E2026= =E5=B9=B41=E6=9C=8826=E6=97=A5=E5=91=A8=E4=B8=80 18:13=E5=86=99=E9=81=93=EF= =BC=9A > > > >> > > > >> On 26/01/2026 12:06, Jun Nie wrote: > > > >>> Dmitry Baryshkov =E4=BA=8E202= 6=E5=B9=B41=E6=9C=8822=E6=97=A5=E5=91=A8=E5=9B=9B 18:22=E5=86=99=E9=81=93= =EF=BC=9A > > > >>>> > > > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > > >>>>> Dmitry Baryshkov =E4=BA=8E2= 026=E5=B9=B41=E6=9C=8821=E6=97=A5=E5=91=A8=E4=B8=89 17:30=E5=86=99=E9=81=93= =EF=BC=9A > > > >>>>>> > > > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > >>>>>>> Currently, plane splitting and SSPP allocation occur during t= he plane > > > >>>>>>> check phase. Defer these operations until dpu_assign_plane_re= sources() > > > >>>>>>> is called from the CRTC side to ensure the topology informati= on from > > > >>>>>>> the CRTC check is available. > > > >>>>>> > > > >>>>>> Why is it important? What is broken otherwise? > > > >>>>> > > > >>>>> I see. Thanks! Will add below lines in next version. > > > >>>>> > > > >>>>> By default, the plane check occurs before the CRTC check. > > > >>>>> Without topology information from the CRTC, plane splitting > > > >>>>> cannot be properly executed. Consequently, the SSPP > > > >>>>> engine starts without a valid memory address, which triggers > > > >>>>> an IOMMU warning. > > > >>>> > > > >>>> What is plane splitting? Write commit message for somebody who d= oesn't > > > >>>> exactly know what is going on. > > > >>> > > > >>> Thanks for the suggestion! Any more revise is needed? > > > >> > > > >> Sadly enough the text below is not a significant improvement. > > > >> > > > >>> > > > >>> Currently, splitting plane into SSPP rectangles the allocation oc= cur > > > >>> during the plane check phase, so that a plane can be supported by > > > >>> multiple hardware pipe. > > > >> > > > >> What does this mean? Without virtual planes in place, there are no > > > >> multiple hardware pipes. > > > >> > > > >>> While pipe topology is decided in CRTC check. > > > >> > > > >> ?? What does it mean here? > > > >> > > > >>> By default, the plane check occurs before the CRTC check in DRM > > > >>> framework. Without topology information from the CRTC, plane spli= tting > > > >>> cannot be properly executed. > > > >> > > > >> What does 'properly' mean here? How is it executed? What happens? > > > >> > > > >>> Consequently, the SSPP engine starts > > > >>> without a valid memory address, which triggers IOMMU warning. > > > >> > > > >> IOMMU faults. There are no "warnings". > > > >> > > > >>> > > > >>> Defer above plane operations until dpu_assign_plane_resources() > > > >>> is called from the CRTC side to ensure the topology information f= rom > > > >>> the CRTC check is available. > > > >> > > > >> > > > > Thanks for the patience! > > > > > > > > > > > > Currently, splitting plane into SSPP rectangles and allocation occu= r > > > > during the plane check phase. When virtual plane is enabled to supp= ort > > > > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so th= at > > > > a plane can be supported by 4 hardware pipes. And pipe number is > > > > > > number of pipes > > > > > > > decided in CRTC check per interface number, resolution and hardware > > > > feature. > > > > > > Okay, but IOMMU errors were reported with virtual planes being disabl= ed. > > > So how is it relevant? > > > > After revise of splitting plane into pipes, the number of pipes will be= decided > > by CRTC check for both virtual plane and non-virtual plane case to unif= y the > > plane handling, instead of assumption of 2 pipes at most. > > This needs to be explicitly written. > > > > > > > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > > framework. Without topology information from the CRTC, plane splitt= ing > > > > > > WHat is plane splitting? > > > > How about: s/plane splitting/splitting plane into pipes ? > > This plane is not being split into anything. It's being mapped onto hw > pipes. But before that, the number of necessary hw pipes is being determi= ned > based on foo, bar an baz, Thanks for the correction! Currently, plane is mapped onto at most 2 hardware pipes and 1 SSPP allocation occur during the plane check phase. When virtual plane is enabled to support quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that a plane can be supported by 4 hardware pipes. After revise of quad-pipe, the number of pipes is decided in CRTC check per number of interfaces, resolution, clock rate constrain, hardware feature and virtual plane enablement. The decidsion of number of pipes will happen in CRTC check for both virtual plane and non-virtual plane case to unify the plane handling. Before that, the the number of necessary hw pipes is being determined based on resolution and clock rate constrain. By default, the plane check occurs before the CRTC check in DRM framework. Without topology information from the CRTC, plane mapping will be skipped for the first time as number of pipe is 0. Consequently, the SSPP engine starts without a valid memory address, which triggers IOMMU fault. Defer above plane related operations until dpu_assign_plane_resources() is called from the CRTC side to ensure the topology information from the CRTC check is available. > > > > > > > > > > will be skipped for the first time as pipe number is 0. Consequentl= y, > > > > the SSPP engine starts without a valid memory address, which trigge= rs > > > > IOMMU fault. > > > > > > > > Defer above plane related operations until dpu_assign_plane_resourc= es() > > > > is called from the CRTC side to ensure the topology information fro= m > > > > the CRTC check is available. > > > > > > > > Regards, > > > > Jun > > > >> > > > >> -- > > > >> With best wishes > > > >> Dmitry > > > > > > > > > -- > > > With best wishes > > > Dmitry > > -- > With best wishes > Dmitry