[Public]

> -----Original Message-----
> From: Lyude Paul <[email protected]>
> Sent: Wednesday, August 11, 2021 4:45 AM
> To: Lin, Wayne <[email protected]>; [email protected]
> Cc: Kazlauskas, Nicholas <[email protected]>; Wentland, Harry 
> <[email protected]>; Zuo, Jerry
> <[email protected]>; Wu, Hersen <[email protected]>; Juston Li 
> <[email protected]>; Imre Deak <[email protected]>;
> Ville Syrjälä <[email protected]>; Daniel Vetter 
> <[email protected]>; Sean Paul <[email protected]>; Maarten Lankhorst
> <[email protected]>; Maxime Ripard <[email protected]>; 
> Thomas Zimmermann <[email protected]>;
> David Airlie <[email protected]>; Daniel Vetter <[email protected]>; Deucher, 
> Alexander <[email protected]>; Siqueira,
> Rodrigo <[email protected]>; Pillai, Aurabindo 
> <[email protected]>; Eryk Brol <[email protected]>; Bas
> Nieuwenhuizen <[email protected]>; Cornij, Nikola 
> <[email protected]>; Jani Nikula <[email protected]>; Manasi
> Navare <[email protected]>; Ankit Nautiyal 
> <[email protected]>; José Roberto de Souza <[email protected]>;
> Sean Paul <[email protected]>; Ben Skeggs <[email protected]>; 
> [email protected]
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> On Wed, 2021-08-04 at 07:13 +0000, Lin, Wayne wrote:
> > [Public]
> >
> > > -----Original Message-----
> > > From: Lyude Paul <[email protected]>
> > > Sent: Wednesday, August 4, 2021 8:09 AM
> > > To: Lin, Wayne <[email protected]>; [email protected]
> > > Cc: Kazlauskas, Nicholas <[email protected]>; Wentland,
> > > Harry < [email protected]>; Zuo, Jerry <[email protected]>; Wu,
> > > Hersen <[email protected]>; Juston Li < [email protected]>; Imre
> > > Deak <[email protected]>; Ville Syrjälä
> > > <[email protected]>; Wentland, Harry <
> > > [email protected]>; Daniel Vetter <[email protected]>;
> > > Sean Paul <[email protected]>; Maarten Lankhorst <
> > > [email protected]>; Maxime Ripard
> > > <[email protected]>; Thomas Zimmermann <[email protected]>; David
> > > Airlie <[email protected]>; Daniel Vetter <[email protected]>; Deucher,
> > > Alexander <[email protected]>; Siqueira, Rodrigo <
> > > [email protected]>; Pillai, Aurabindo
> > > <[email protected]>; Eryk Brol <[email protected]>; Bas
> > > Nieuwenhuizen <[email protected]>; Cornij, Nikola
> > > <[email protected]>; Jani Nikula <[email protected]>; Manasi
> > > Navare <[email protected]>; Ankit Nautiyal
> > > <[email protected]>; José Roberto de Souza
> > > <[email protected]>; Sean Paul <[email protected]>; Ben
> > > Skeggs <[email protected]>; [email protected]
> > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for
> > > connected end device
> > >
> > > On Tue, 2021-08-03 at 19:58 -0400, Lyude Paul wrote:
> > > > On Wed, 2021-07-21 at 00:03 +0800, Wayne Lin wrote:
> > > > > [Why]
> > > > > Currently, we will create connectors for all output ports no
> > > > > matter it's connected or not. However, in MST, we can only
> > > > > determine whether an output port really stands for a "connector"
> > > > > till it is connected and check its peer device type as an end device.
> > > >
> > > > What is this commit trying to solve exactly? e.g. is AMD currently
> > > > running into issues with there being too many DRM connectors or
> > > > something like that?
> > > > Ideally this is behavior I'd very much like us to keep as-is
> > > > unless there's good reason to change it.
> > Hi Lyude,
> > Really appreciate for your time to elaborate in such detail. Thanks!
> >
> > I come up with this commit because I observed something confusing when
> > I was analyzing MST connectors' life cycle. Take the topology instance
> > you mentioned below
> >
> > Root MSTB -> Output_Port 1 -> MSTB 1.1 ->Output_Port 1(Connected w/
> > display)
> >                     |
> > -
> > >Output_Port 2 (Disconnected)
> >                     -> Output_Port 2 -> MSTB 2.1 ->Output_Port 1
> > (Disconnected)
> >
> > -> Output_Port 2 (Disconnected) Which is exactly the topology of
> > Startech DP 1-to-4 hub. There are 3 1-to-2 branch chips within this
> > hub. With our MST implementation today, we'll create drm connectors
> > for all output ports. Hence, we totally create 6 drm connectors here.
> > However, Output ports of Root MSTB are not connected to a stream sink.
> > They are connected with branch devices.
> > Thus, creating drm connector for such port looks a bit strange to me
> > and increases complexity to tracking drm connectors.  My thought is we
> > only need to create drm connector for those connected end device. Once
> > output port is connected then we can determine whether to add on a drm
> > connector for this port based on the peer device type.
> > Hence, this commit doesn't try to break the locking logic but add more
> > constraints when We try to add drm connector. Please correct me if I
> > misunderstand anything here. Thanks!
>
> Sorry-I will respond to this soon, some more stuff came up at work so it 
> might take me a day or two
No worries. Much appreciated for your time!
>
> > > >
> > > > Some context here btw - there's a lot of subtleties with MST
> > > > locking that isn't immediately obvious. It's been a while since I
> > > > wrote this code, but if I recall correctly one of those subtleties
> > > > is that trying to create/destroy connectors on the fly when ports
> > > > change types introduces a lot of potential issues with locking and
> > > > some very complicated state transitions. Note that because we
> > > > maintain the topology as much as possible across suspend/resumes
> > > > this means there's a lot of potential state transitions with
> > > > drm_dp_mst_port and drm_dp_mst_branch we need to handle that would
> > > > typically be impossible to run into otherwise.
> > > >
> > > > An example of this, if we were to try to prune connectors based on
> > > > PDT on the fly: assume we have a simple topology like this
> > > >
> > > > Root MSTB -> Port 1 -> MSTB 1.1 (Connected w/ display)
> > > >           -> Port 2 -> MSTB 2.1
> > > >
> > > > We suspend the system, unplug MSTB 1.1, and then resume. Once the
> > > > system starts reprobing, it will notice that MSTB 1.1 has been
> > > > disconnected. Since we no longer have a PDT, we decide to
> > > > unregister our connector. But there's a catch! We had a display
> > > > connected to MSTB 1.1, so even after unregistering the connector
> > > > it's going to stay around until userspace has committed a new mode
> > > > with the connector disabled.
> > > >
> > > > Now - assuming we're still in the same spot in the resume
> > > > processs, let's assume somehow MSTB 1.1 is suddenly plugged back
> > > > in. Once we've finished responding to the hotplug event, we will
> > > > have created a connector for it. Now we've hit a bug - userspace
> > > > hasn't removed the previous zombie connector which means we have
> > > > references to the drm_dp_mst_port in our atomic state and
> > > > potentially also our payload tables (?? unsure about this one).
> > >
> > > Whoops. One thing I totally forgot to mention here: the reason this
> > > is a problem is because we'd now have two drm_connectors which both
> > > have the same drm_dp_mst_port pointer.
> > >
> > > >
> > > > So then how do we manage to add/remove connectors for input
> > > > connectors on the fly? Well, that's one of the fun
> > > > normally-impossible state transitions I mentioned before.
> > > > According to the spec input ports are always disconnected, so
> > > > we'll never receive a CSN for them. This means
> > I think input ports' DisplayPort_Device_Plug_Status field is still set to 1?
> > But yes,
> > according to DP1.4 spec 2.11.9.3, when MST device whose DPRX detected
> > the connection status change shall broadcast CSN downstream only.
> > Hence, we'll never receive a CSN for this case.
> > > > in theory the only possible way we could have a connector go from
> > > > being an input connector to an output connector connector would be
> > > > if the entire topology was swapped out during suspend/resume, and
> > > > the input/output ports in the two topologies topology happen to be
> > > > in different places.
> > > > Since we only have to reprobe once during resume before we get
> > > > hotplugging enabled, we're guaranteed this state transition will
> > > > only happen once in this state - which means the second replug I
> > > > described in the previous paragraph can never happen.
> > > >
> > > > Note that while I don't actually know if there's topologies with
> > > > input ports at indexes other than 0, since the specification isn't
> > > > super clear on this bit we play it safe and assume it is possible.
> > Based on DP1.4 spec 2.5.1. Physical input ports are assigned smaller
> > port numbers than physical output ports. For concentrator product, if
> > there are 2 input ports of it's branch device, then their port numbers
> > are port 0 & port
> > 1
> > which can refer to figure 2-122 of DP1.4.
> > > >
> > > > Anyway-this is -all- based off my memory, so please point out
> > > > anything here that I've explained that doesn't make sense or
> > > > doesn't seem correct :). It's totally possible I might have 
> > > > misremembered something.
> > Thanks again Lyude! Much appreciated for your time and help! And
> > please correct me if I misunderstand anything here : )
> > > >
> > > > >
> > > > > In current code, we have chance to create connectors for output
> > > > > ports connected with branch device and these are redundant connectors.
> > > > > e.g.
> > > > > StarTech 1-to-4 DP hub is constructed by internal 2 layer 1-to-2
> > > > > branch devices. Creating connectors for such internal output
> > > > > ports are redundant.
> > > > >
> > > > > [How]
> > > > > Put constraint on creating connector for connected end device only.
> > > > >
> > > > > Fixes: 6f85f73821f6 ("drm/dp_mst: Add basic topology reprobing
> > > > > when
> > > > > resuming")
> > > > > Cc: Juston Li <[email protected]>
> > > > > Cc: Imre Deak <[email protected]>
> > > > > Cc: Ville Syrjälä <[email protected]>
> > > > > Cc: Harry Wentland <[email protected]>
> > > > > Cc: Daniel Vetter <[email protected]>
> > > > > Cc: Sean Paul <[email protected]>
> > > > > Cc: Lyude Paul <[email protected]>
> > > > > Cc: Maarten Lankhorst <[email protected]>
> > > > > Cc: Maxime Ripard <[email protected]>
> > > > > Cc: Thomas Zimmermann <[email protected]>
> > > > > Cc: David Airlie <[email protected]>
> > > > > Cc: Daniel Vetter <[email protected]>
> > > > > Cc: Alex Deucher <[email protected]>
> > > > > Cc: Nicholas Kazlauskas <[email protected]>
> > > > > Cc: Rodrigo Siqueira <[email protected]>
> > > > > Cc: Aurabindo Pillai <[email protected]>
> > > > > Cc: Eryk Brol <[email protected]>
> > > > > Cc: Bas Nieuwenhuizen <[email protected]>
> > > > > Cc: Nikola Cornij <[email protected]>
> > > > > Cc: Wayne Lin <[email protected]>
> > > > > Cc: "Ville Syrjälä" <[email protected]>
> > > > > Cc: Jani Nikula <[email protected]>
> > > > > Cc: Manasi Navare <[email protected]>
> > > > > Cc: Ankit Nautiyal <[email protected]>
> > > > > Cc: "José Roberto de Souza" <[email protected]>
> > > > > Cc: Sean Paul <[email protected]>
> > > > > Cc: Ben Skeggs <[email protected]>
> > > > > Cc: [email protected]
> > > > > Cc: <[email protected]> # v5.5+
> > > > > Signed-off-by: Wayne Lin <[email protected]>
> > > > > ---
> > > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 7 ++++++-
> > > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > index 51cd7f74f026..f13c7187b07f 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > @@ -2474,7 +2474,8 @@ drm_dp_mst_handle_link_address_port(struct
> > > > > drm_dp_mst_branch *mstb,
> > > > >
> > > > >         if (port->connector)
> > > > >                 drm_modeset_unlock(&mgr->base.lock);
> > > > > -       else if (!port->input)
> > > > > +       else if (!port->input && port->pdt !=
> > > > > +DP_PEER_DEVICE_NONE &&
> > > > > +                drm_dp_mst_is_end_device(port->pdt, port->mcs))
> > > > >                 drm_dp_mst_port_add_connector(mstb, port);
> > > > >
> > > > >         if (send_link_addr && port->mstb) { @@ -2557,6 +2558,10
> > > > > @@ drm_dp_mst_handle_conn_stat(struct
> > > > > drm_dp_mst_branch
> > > > > *mstb,
> > > > >                 dowork = false;
> > > > >         }
> > > > >
> > > > > +       if (!port->input && !port->connector && new_pdt !=
> > > > > DP_PEER_DEVICE_NONE &&
> > > > > +           drm_dp_mst_is_end_device(new_pdt, new_mcs))
> > > > > +               create_connector = true;
> > > > > +
> > > > >         if (port->connector)
> > > > >                 drm_modeset_unlock(&mgr->base.lock);
> > > > >         else if (create_connector)
> > > >
> > >
> > > --
> > > Cheers,
> > >  Lyude Paul (she/her)
> > >  Software Engineer at Red Hat
> > Regards,
> > Wayne Lin
> >
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
--
Regards,
Wayne Lin

Reply via email to