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. > > > 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. > > > 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. 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
