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? > 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 > 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. -- With best wishes Dmitry
