On Mon, Feb 02, 2026 at 03:15:14PM +0800, Jun Nie wrote: > Dmitry Baryshkov <[email protected]> 于2026年1月27日周二 03:06写道： > > > > On Mon, Jan 26, 2026 at 09:29:44PM +0800, Jun Nie wrote: > > > Dmitry Baryshkov <[email protected]> 于2026年1月26日周一 > > > 20:31写道： > > > > > > > > On Mon, Jan 26, 2026 at 08:01:00PM +0800, Jun Nie wrote: > > > > > Dmitry Baryshkov <[email protected]> 于2026年1月26日周一 > > > > > 18:49写道： > > > > > > > > > > > > On 26/01/2026 12:29, Jun Nie wrote: > > > > > > > Dmitry Baryshkov <[email protected]> > > > > > > > 于2026年1月26日周一 18:13写道： > > > > > > >> > > > > > > >> On 26/01/2026 12:06, Jun Nie wrote: > > > > > > >>> Dmitry Baryshkov <[email protected]> > > > > > > >>> 于2026年1月22日周四 18:22写道： > > > > > > >>>> > > > > > > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > > > > > >>>>> Dmitry Baryshkov <[email protected]> > > > > > > >>>>> 于2026年1月21日周三 17:30写道： > > > > > > >>>>>> > > > > > > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > > > > >>>>>>> Currently, plane splitting and SSPP allocation occur during > > > > > > >>>>>>> the plane > > > > > > >>>>>>> check phase. Defer these operations until > > > > > > >>>>>>> dpu_assign_plane_resources() > > > > > > >>>>>>> is called from the CRTC side to ensure the topology > > > > > > >>>>>>> information 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 > > > > > > >>>> doesn'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 > > > > > > >>> occur > > > > > > >>> 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 > > > > > > >>> splitting > > > > > > >>> 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 > > > > > > >>> from > > > > > > >>> the CRTC check is available. > > > > > > >> > > > > > > >> > > > > > > > Thanks for the patience! > > > > > > > > > > > > > > > > > > > > > Currently, splitting plane into SSPP rectangles and 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. 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 > > > > > > disabled. > > > > > > 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 > > > > > unify 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 > > > > > > > splitting > > > > > > > > > > > > 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 > > > > determined > > > > 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, > > > > Where? > > The pipe is decided in dpu_crtc_get_topology(). Change to quad-pipe > is made in later patch. So I drop this in this patch message below.
The pipe isn't decides in that function. > > > > > hardware feature and virtual plane enablement. The decidsion of > > > > decision > > > > > 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 > > > > will? Do you mean, after this patch? If so, please use imperative > > language. See Documentation/process/submitting-patches.rst > > Yes, it is in later patch. So drop it in this patch message. > > It is possible to keep plane check unchanged, and rely on re-allocation > in later stage to support quad-pipe, if quad-pipe use case is detected. > But to unify the allocation logic for both non-virtual and virtual plane > use cases, and to centralize resource management, we'd better defer > the allocation. Which allocation? The non-virtual-planes case is more or less static. > > > > > > > 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. > > > > > > > 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. > > > How about this commit message? It is more coherent with the change > in this patch. > > > Currently, a plane maps to at most two hardware pipes, and SSPP > allocation occurs during the plane check phase. However, when virtual > planes are enabled, SSPP re-allocation can occur within > dpu_assign_plane_resources() during the CRTC check. There is no _allocation_ for non-virtual-plane case. The SSPP are statically assigned to the planes. > > To support future quad-pipe topologies, which require allocating two > SSPPs with four rectangles by default, it is more efficient to perform > the primary allocation in a single pass rather than relying on later > re-allocations. So defer the allocation to CRTC check phase by default. > Allocation logic for both non-virtual and virtual plane use cases is > unified in this way. > > > -- > > With best wishes > > Dmitry -- With best wishes Dmitry
