RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, August 4, 2021 8:09 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ;
> Ville Syrjälä ; Wentland, Harry 
> ; Daniel Vetter ;
> Sean Paul ; Maarten Lankhorst 
> ; Maxime Ripard ;
> Thomas Zimmermann ; David Airlie ; 
> Daniel Vetter ; Deucher,
> Alexander ; Siqueira, Rodrigo 
> ; Pillai, Aurabindo
> ; Eryk Brol ; Bas Nieuwenhuizen 
> ; Cornij, Nikola
> ; Jani Nikula ; Manasi Navare 
> ; Ankit Nautiyal
> ; José Roberto de Souza ; 
> Sean Paul ; Ben Skeggs
> ; sta...@vger.kernel.org
> 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!
> >
> > 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'

RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, August 11, 2021 4:45 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ;
> Ville Syrjälä ; Daniel Vetter 
> ; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ; 
> Thomas Zimmermann ;
> David Airlie ; Daniel Vetter ; Deucher, 
> Alexander ; Siqueira,
> Rodrigo ; Pillai, Aurabindo 
> ; Eryk Brol ; Bas
> Nieuwenhuizen ; Cornij, Nikola 
> ; Jani Nikula ; Manasi
> Navare ; Ankit Nautiyal 
> ; José Roberto de Souza ;
> Sean Paul ; Ben Skeggs ; 
> sta...@vger.kernel.org
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> On Wed, 2021-08-04 at 07:13 +, Lin, Wayne wrote:
> > [Public]
> >
> > > -Original Message-
> > > From: Lyude Paul 
> > > Sent: Wednesday, August 4, 2021 8:09 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> > > Cc: Kazlauskas, Nicholas ; Wentland,
> > > Harry < harry.wentl...@amd.com>; Zuo, Jerry ; Wu,
> > > Hersen ; Juston Li < juston...@intel.com>; Imre
> > > Deak ; Ville Syrjälä
> > > ; Wentland, Harry <
> > > harry.wentl...@amd.com>; Daniel Vetter ;
> > > Sean Paul ; Maarten Lankhorst <
> > > maarten.lankho...@linux.intel.com>; Maxime Ripard
> > > ; Thomas Zimmermann ; David
> > > Airlie ; Daniel Vetter ; Deucher,
> > > Alexander ; Siqueira, Rodrigo <
> > > rodrigo.sique...@amd.com>; Pillai, Aurabindo
> > > ; Eryk Brol ; Bas
> > > Nieuwenhuizen ; Cornij, Nikola
> > > ; Jani Nikula ; Manasi
> > > Navare ; Ankit Nautiyal
> > > ; José Roberto de Souza
> > > ; Sean Paul ; Ben
> > > Skeggs ; sta...@vger.kernel.org
> > > 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'

RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, August 19, 2021 2:59 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ;
> Ville Syrjälä ; Daniel Vetter 
> ; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ; 
> Thomas Zimmermann ;
> David Airlie ; Daniel Vetter ; Deucher, 
> Alexander ; Siqueira,
> Rodrigo ; Pillai, Aurabindo 
> ; Eryk Brol ; Bas
> Nieuwenhuizen ; Cornij, Nikola 
> ; Jani Nikula ; Manasi
> Navare ; Ankit Nautiyal 
> ; José Roberto de Souza ;
> Sean Paul ; Ben Skeggs ; 
> sta...@vger.kernel.org
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> On Wed, 2021-08-11 at 09:49 +, Lin, Wayne wrote:
> > [Public]
> >
> > > -Original Message-
> > > From: Lyude Paul 
> > > Sent: Wednesday, August 11, 2021 4:45 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> > > Cc: Kazlauskas, Nicholas ; Wentland,
> > > Harry < harry.wentl...@amd.com>; Zuo, Jerry ; Wu,
> > > Hersen ; Juston Li < juston...@intel.com>; Imre
> > > Deak ; Ville Syrjälä
> > > ; Daniel Vetter <
> > > daniel.vet...@ffwll.ch>; Sean Paul ; Maarten
> > > Lankhorst ; Maxime Ripard
> > > ; Thomas Zimmermann ; David
> > > Airlie ; Daniel Vetter ; Deucher,
> > > Alexander ; Siqueira, Rodrigo
> > > ; Pillai, Aurabindo <
> > > aurabindo.pil...@amd.com>; Eryk Brol ; Bas
> > > Nieuwenhuizen ; Cornij, Nikola <
> > > nikola.cor...@amd.com>; Jani Nikula ; Manasi
> > > Navare ; Ankit Nautiyal <
> > > ankit.k.nauti...@intel.com>; José Roberto de Souza
> > > ; Sean Paul ; Ben
> > > Skeggs ; sta...@vger.kernel.org
> > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for
> > > connected end device
> > >
> > > On Wed, 2021-08-04 at 07:13 +, Lin, Wayne wrote:
> > > > [Public]
> > > >
> > > > > -Original Message-
> > > > > From: Lyude Paul 
> > > > > Sent: Wednesday, August 4, 2021 8:09 AM
> > > > > To: Lin, Wayne ;
> > > > > dri-devel@lists.freedesktop.org
> > > > > Cc: Kazlauskas, Nicholas ;
> > > > > Wentland, Harry < harry.wentl...@amd.com>; Zuo, Jerry
> > > > > ; Wu, Hersen ; Juston Li
> > > > > < juston...@intel.com>; Imre Deak ; Ville
> > > > > Syrjälä ; Wentland, Harry <
> > > > > harry.wentl...@amd.com>; Daniel Vetter ;
> > > > > Sean Paul ; Maarten Lankhorst <
> > > > > maarten.lankho...@linux.intel.com>; Maxime Ripard
> > > > > ; Thomas Zimmermann ;
> > > > > David Airlie ; Daniel Vetter
> > > > > ; Deucher, Alexander
> > > > > ; Siqueira, Rodrigo <
> > > > > rodrigo.sique...@amd.com>; Pillai, Aurabindo
> > > > > ; Eryk Brol ; Bas
> > > > > Nieuwenhuizen ; Cornij, Nikola
> > > > > ; Jani Nikula ;
> > > > > Manasi Navare ; Ankit Nautiyal
> > > > > ; José Roberto de Souza
> > > > > ; Sean Paul ; Ben
> > > > > Skeggs ; sta...@vger.kernel.org
> > > > > 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 elabor

RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, August 21, 2021 4:48 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ;
> Ville Syrjälä ; Daniel Vetter 
> ; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ; 
> Thomas Zimmermann ;
> David Airlie ; Daniel Vetter ; Deucher, 
> Alexander ; Siqueira,
> Rodrigo ; Pillai, Aurabindo 
> ; Bas Nieuwenhuizen
> ; Cornij, Nikola ; Jani 
> Nikula ; Manasi Navare
> ; Ankit Nautiyal ; 
> José Roberto de Souza ; Sean
> Paul ; Ben Skeggs ; 
> sta...@vger.kernel.org
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> On Fri, 2021-08-20 at 11:20 +, Lin, Wayne wrote:
> > [Public]
> >
> > > -Original Message-
> > > From: Lyude Paul 
> > > Sent: Thursday, August 19, 2021 2:59 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> > > Cc: Kazlauskas, Nicholas ; Wentland,
> > > Harry < harry.wentl...@amd.com>; Zuo, Jerry ; Wu,
> > > Hersen ; Juston Li < juston...@intel.com>; Imre
> > > Deak ; Ville Syrjälä
> > > ; Daniel Vetter <
> > > daniel.vet...@ffwll.ch>; Sean Paul ; Maarten
> > > Lankhorst ; Maxime Ripard
> > > ; Thomas Zimmermann ; David
> > > Airlie ; Daniel Vetter ; Deucher,
> > > Alexander ; Siqueira, Rodrigo
> > > ; Pillai, Aurabindo <
> > > aurabindo.pil...@amd.com>; Eryk Brol ; Bas
> > > Nieuwenhuizen ; Cornij, Nikola <
> > > nikola.cor...@amd.com>; Jani Nikula ; Manasi
> > > Navare ; Ankit Nautiyal <
> > > ankit.k.nauti...@intel.com>; José Roberto de Souza
> > > ; Sean Paul ; Ben
> > > Skeggs ; sta...@vger.kernel.org
> > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for
> > > connected end device
> > >
> > > On Wed, 2021-08-11 at 09:49 +, Lin, Wayne wrote:
> > > > [Public]
> > > >
> > > > > -Original Message-
> > > > > From: Lyude Paul 
> > > > > Sent: Wednesday, August 11, 2021 4:45 AM
> > > > > To: Lin, Wayne ;
> > > > > dri-devel@lists.freedesktop.org
> > > > > Cc: Kazlauskas, Nicholas ;
> > > > > Wentland, Harry < harry.wentl...@amd.com>; Zuo, Jerry
> > > > > ; Wu, Hersen ; Juston Li
> > > > > < juston...@intel.com>; Imre Deak ; Ville
> > > > > Syrjälä ; Daniel Vetter <
> > > > > daniel.vet...@ffwll.ch>; Sean Paul ; Maarten
> > > > > Lankhorst ; Maxime Ripard
> > > > > ; Thomas Zimmermann ;
> > > > > David Airlie ; Daniel Vetter
> > > > > ; Deucher, Alexander
> > > > > ; Siqueira, Rodrigo
> > > > > ; Pillai, Aurabindo <
> > > > > aurabindo.pil...@amd.com>; Eryk Brol ; Bas
> > > > > Nieuwenhuizen ; Cornij, Nikola <
> > > > > nikola.cor...@amd.com>; Jani Nikula ;
> > > > > Manasi Navare ; Ankit Nautiyal <
> > > > > ankit.k.nauti...@intel.com>; José Roberto de Souza
> > > > > ; Sean Paul ; Ben
> > > > > Skeggs ; sta...@vger.kernel.org
> > > > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for
> > > > > connected end device
> > > > >
> > > > > On Wed, 2021-08-04 at 07:13 +, Lin, Wayne wrote:
> > > > > > [Public]
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Lyude Paul 
> > > > > > > Sent: Wednesday, August 4, 2021 8:09 AM
> > > > > > > To: Lin, Wayne ;
> > > > > > > dri-devel@lists.freedesktop.org
> > > > > > > Cc: Kazlauskas, Nicholas ;
> > > > > > > Wentland, Harry < harry.wentl...@amd.com>; Zuo, Jerry
> > > > > > > ; Wu, Hersen ;
> > > > > > > Juston Li < juston...@intel.com>; Imre Deak
> > > > > > > ; Ville Syrjälä
> > > > > > > ; Wentland, Harry <
> > > > > > > harry.wentl...@amd.com>; Daniel Vetter
> > > > > > > ; Sean Paul ;
> > > > > > > Maarten Lankhorst < maarten.lankho...@linux.intel.com>;
> > > > > > > Maxime Ripard ; Thomas Zimmermann
> > > > > > > ; David Airlie 

RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

> -Original Message-
> From: Lyude Paul 
> Sent: Tuesday, August 24, 2021 5:18 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ;
> Ville Syrjälä ; Daniel Vetter 
> ; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ; 
> Thomas Zimmermann ;
> David Airlie ; Daniel Vetter ; Deucher, 
> Alexander ; Siqueira,
> Rodrigo ; Pillai, Aurabindo 
> ; Bas Nieuwenhuizen
> ; Cornij, Nikola ; Jani 
> Nikula ; Manasi Navare
> ; Ankit Nautiyal ; 
> José Roberto de Souza ; Sean
> Paul ; Ben Skeggs ; 
> sta...@vger.kernel.org
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> [snip]
>
> I think I might still be misunderstanding something, some comments below
>
> On Mon, 2021-08-23 at 06:33 +, Lin, Wayne wrote:
> > > > Hi Lyude,
> > > >
> > > > Really thankful for willing to explain in such details. Really
> > > > appreciate.
> > > >
> > > > I'm trying to fix some problems that observed after these 2
> > > > patches
> > > > * 09b974e8983 drm/amd/amdgpu_dm/mst: Remove ->destroy_connector()
> > > > callback
> > > > * 72dc0f51591 drm/dp_mst: Remove
> > > > drm_dp_mst_topology_cbs.destroy_connector
> > > >
> > > > With above patches, we now change to remove dc_sink when connector
> > > > is about to be destroyed. However, we found out that connectors
> > > > won't get destroyed after hotplugs. Thus, after few times
> > > > hotplugs, we won't create any new dc_sink since number of sink is
> > > > exceeding our limitation. As the result of that, I'm trying to
> > > > figure out why the refcount of connectors won't get zero.
> > > >
> > > > Based on my analysis, I found out that if we connect a sst monitor
> > > > to a mst hub then connect the hub to the system, and then unplug
> > > > the sst monitor from the hub. E.g.
> > > > src - mst hub - sst monitor => src - mst hub  (unplug) sst monitor
> > > >
> > > > Within this case, we won't try to put refcount of the sst monitor.
> > > > Which is what I tried to resolve by [PATCH 3/4].
> > > > But here comes a problem which is confusing me that if I can
> > > > destroy connector in this case. By comparing to another case, if
> > > > now mst hub is connected with a mst monitor like this:
> > > > src - mst hub - mst monitor => src - mst hub  (unplug) mst monitor
> > > >
> > > > We will put the topology refcount of mst monitor's branching unit
> > > > in and
> > > > drm_dp_port_set_pdt() and eventually call
> > > > drm_dp_delayed_destroy_port() to unregister the connector of the
> > > > logical port. So following the same rule, I think to dynamically
> > > > unregister a mst connector is what we want and should be
> > > > reasonable to also destroy sst connectors in my case. But this
> > > > conflicts the idea what we have here. We want to create connectors for 
> > > > all output ports.
> > > > So if dynamically creating/destroying connectors is what we want,
> > > > when is the appropriate time for us to create one is what I'm 
> > > > considering.
> > > >
> > > > Take the StartTech hub DP 1to4 DP output ports for instance. This
> > > > hub, internally, is constructed by  3 1-to-2 mst branch chips. 2
> > > > output ports of 1st chip are hardwired to another 2 chips. It's
> > > > how it makes it to support 1-to-4 mst branching. So within this
> > > > case, the internal
> > > > 2 output ports of 1st chip is not connecting to a stream sink and
> > > > will never get connected to one.  Thus, I'm thinking maybe the
> > > > best timing to attach a connector to a port is when the port is
> > > > connected, and the connected PDT is determined as a stream sink.
> > > >
> > > > Sorry if I misunderstand anything here and really thanks for your
> > > > time to shed light on this : ) Thanks Lyude.
> > >
> > > It's no problem, it is my job after all! Sorry for how long my
> > > responses have been taking, but my plate seems to be finally
> > > clearing up for the foreseeable future.
> > >
> > > That being said - it sounds like with this we still aren't actually
>

RE: [PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical ports

[Lin, Wayne]

[AMD Public Use]

> -Original Message-
> From: Imre Deak 
> Sent: Monday, February 1, 2021 8:02 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Lin, Wayne ; Lyude Paul 
> Subject: [PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical ports
>
> Caching EDIDs for physical ports prevents updating the EDID if a port gets 
> reconnected via a Connection Status Notification message,
> fix this.
>
> Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
> Cc: Wayne Lin 
> Cc: Lyude Paul 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index deb7995f42fa..309afe61afdd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2302,7 +2302,8 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch 
> *mstb,
>  }
>
>  if (port->pdt != DP_PEER_DEVICE_NONE &&
> -drm_dp_mst_is_end_device(port->pdt, port->mcs)) {
> +drm_dp_mst_is_end_device(port->pdt, port->mcs) &&
> +port->port_num >= DP_MST_LOGICAL_PORT_0) {
Hi Imre Deak,

Thanks for the patch!
Just curious that you mean we don't want to fetch the EDID of the sst monitor 
like below case?
Src->MST device ->SST monitor
I thought we still need to get the EDID even the monitor is connected to the 
physical output port of mst device.
Maybe what we should fix here is why the EDID is not get updated once 
reconnected via CSN message?

Thanks!
>  port->cached_edid = drm_get_edid(port->connector,
>   &port->aux.ddc);
>  drm_connector_set_tile_property(port->connector);
> --
> 2.25.1
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical ports

[Lin, Wayne]

[AMD Official Use Only - Internal Distribution Only]

> -Original Message-
> From: Imre Deak 
> Sent: Tuesday, February 2, 2021 7:22 PM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; Lyude Paul 
> Subject: Re: [PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical ports
>
> On Tue, Feb 02, 2021 at 03:38:16AM +, Lin, Wayne wrote:
> > [AMD Public Use]
> >
> > > -Original Message-
> > > From: Imre Deak 
> > > Sent: Monday, February 1, 2021 8:02 PM
> > > To: dri-devel@lists.freedesktop.org
> > > Cc: Lin, Wayne ; Lyude Paul 
> > > Subject: [PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical
> > > ports
> > >
> > > Caching EDIDs for physical ports prevents updating the EDID if a
> > > port gets reconnected via a Connection Status Notification message, fix 
> > > this.
> > >
> > > Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device
> > > case")
> > > Cc: Wayne Lin 
> > > Cc: Lyude Paul 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index deb7995f42fa..309afe61afdd 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -2302,7 +2302,8 @@ drm_dp_mst_port_add_connector(struct
> > > drm_dp_mst_branch *mstb,  }
> > >
> > >  if (port->pdt != DP_PEER_DEVICE_NONE &&
> > > -drm_dp_mst_is_end_device(port->pdt, port->mcs)) {
> > > +drm_dp_mst_is_end_device(port->pdt, port->mcs) &&
> > > +port->port_num >= DP_MST_LOGICAL_PORT_0) {
> > Hi Imre Deak,
> >
> > Thanks for the patch!
> > Just curious that you mean we don't want to fetch the EDID of the sst
> > monitor like below case?
> >
> > Src->MST device ->SST monitor
>
> The intention of the mst cached_edid logic is to cache the EDID for logical 
> ports where the EDID cannot change anyway. The EDID on
> physical ports is fetched during connector probing just as for any other 
> connector.
>
> > I thought we still need to get the EDID even the monitor is connected
> > to the physical output port of mst device.
>
> For sinks attached to phyisical ports we get the EDID whenever probing the 
> corresponding connector.
>
> > Maybe what we should fix here is why the EDID is not get updated once
> > reconnected via CSN message?
>
> This patch fixes the problem that we stopped updating the EDID for physical 
> connectors. After this change it will get updated when
> probing such connectors.
>
Appreciate for the explanation.
Thanks!
> > Thanks!
> > >  port->cached_edid = drm_get_edid(port->connector,
> > >   &port->aux.ddc);
> > >  drm_connector_set_tile_property(port->connector);
> > > --
> > > 2.25.1
> > Regards,
> > Wayne Lin
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr

[Lin, Wayne]

[AMD Public Use]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, February 23, 2021 1:09 AM
> To: Lin, Wayne 
> Cc: Brol, Eryk ; Zhuo, Qingqing ; 
> sta...@vger.kernel.org; Zuo, Jerry
> ; dri-devel@lists.freedesktop.org; Kazlauskas, Nicholas 
> 
> Subject: Re: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr
>
> On Mon, Feb 22, 2021 at 07:02:03PM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 22, 2021 at 12:00:26PM +0800, Wayne Lin wrote:
> > > [Why & How]
> > > According to DP spec, broadcast message LCT equals to 1 and LCR
> > > equals to 6. Current implementation is incorrect. Fix it.
> > >
> > > Signed-off-by: Wayne Lin 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 10 --
> > >  1 file changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 17dbed0a9800..713ef3b42054 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -2727,8 +2727,14 @@ static int set_hdr_from_dst_qlock(struct 
> > > drm_dp_sideband_msg_hdr *hdr,
> > >  else
> > >  hdr->broadcast = 0;
> > >  hdr->path_msg = txmsg->path_msg;
> > > -hdr->lct = mstb->lct;
> > > -hdr->lcr = mstb->lct - 1;
> > > +if (hdr->broadcast) {
> > > +hdr->lct = 1;
> > > +hdr->lcr = 6;
> > > +} else {
> > > +hdr->lct = mstb->lct;
> > > +hdr->lcr = mstb->lct - 1;
> > > +}
> > > +
> > >  if (mstb->lct > 1)
> > >  memcpy(hdr->rad, mstb->rad, mstb->lct / 2);
> >
> > We should also do something about RAD no?
>
> Just skip the RAD stuff by s/mstb->lct/hdr->lct/ here I guess?
Thanks Ville!
Since LCT=1, broadcast message doesn't have a RAD and this is taken
care while we're constructing the header in drm_dp_encode_sideband_msg_hdr().
In drm_dp_encode_sideband_msg_hdr(), we skip stuffing RAD if LCT=1.
>
> --
> Ville Syrjälä
> Intel
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/2] drm/dp_mst: Set CLEAR_PAYLOAD_ID_TABLE as broadcast

[Lin, Wayne]

[AMD Public Use]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, February 23, 2021 1:00 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; Brol, Eryk ; Zhuo, 
> Qingqing ;
> sta...@vger.kernel.org; Zuo, Jerry ; Kazlauskas, Nicholas 
> ; Dhinakaran
> Pandiyan 
> Subject: Re: [PATCH 2/2] drm/dp_mst: Set CLEAR_PAYLOAD_ID_TABLE as broadcast
>
> On Mon, Feb 22, 2021 at 12:00:27PM +0800, Wayne Lin wrote:
> > [Why & How]
> > According to DP spec, CLEAR_PAYLOAD_ID_TABLE is a path broadcast
> > request message and current implementation is incorrect. Fix it.
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 713ef3b42054..6d73559046e5 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1072,6 +1072,7 @@ static void build_clear_payload_id_table(struct
> > drm_dp_sideband_msg_tx *msg)
> >
> >  req.req_type = DP_CLEAR_PAYLOAD_ID_TABLE;
> >  drm_dp_encode_sideband_req(&req, msg);
> > +msg->path_msg = true;
> >  }
> >
> >  static int build_enum_path_resources(struct drm_dp_sideband_msg_tx
> > *msg, @@ -2722,7 +2723,8 @@ static int set_hdr_from_dst_qlock(struct
> > drm_dp_sideband_msg_hdr *hdr,
> >
> >  req_type = txmsg->msg[0] & 0x7f;
> >  if (req_type == DP_CONNECTION_STATUS_NOTIFY ||
> > -req_type == DP_RESOURCE_STATUS_NOTIFY)
> > +req_type == DP_RESOURCE_STATUS_NOTIFY ||
> > +req_type == DP_CLEAR_PAYLOAD_ID_TABLE)
> >  hdr->broadcast = 1;
>
> Looks correct.
> Reviewed-by: Ville Syrjälä 
>
> Hmm. Looks like we're missing DP_POWER_DOWN_PHY and DP_POWER_UP_PHY here as 
> well. We do try to send them as path
> requests, but apparently forget to mark them as broadcast messages.
Hi Ville,
I also look up the spec but DP_POWER_DOWN_PHY & DP_POWER_UP_PHY seems to be 
defined as path or node request only. Not broadcast message. Please correct me 
if I'm wrong here.
Appreciate for your time!
>
> >  else
> >  hdr->broadcast = 0;
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7C
> > Wayne.Lin%40amd.com%7C372bbed7b5354ca05f5608d8d753533a%7C3dd8961fe4884
> > e608e11a82d994e183d%7C0%7C0%7C637496100180287539%7CUnknown%7CTWFpbGZsb
> > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> > 7C1000&sdata=2uhm9Nf31hfhf%2FbmwfqYW7b6ay9swWb8oS10Uc%2FVFRQ%3D&am
> > p;reserved=0
>
> --
> Ville Syrjälä
> Intel
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr

[Lin, Wayne]

[AMD Public Use]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, February 23, 2021 9:26 PM
> To: Lin, Wayne 
> Cc: Brol, Eryk ; Zhuo, Qingqing ; 
> sta...@vger.kernel.org; Zuo, Jerry
> ; dri-devel@lists.freedesktop.org; Kazlauskas, Nicholas 
> 
> Subject: Re: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr
>
> On Tue, Feb 23, 2021 at 05:32:32AM +, Lin, Wayne wrote:
> > [AMD Public Use]
> >
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Tuesday, February 23, 2021 1:09 AM
> > > To: Lin, Wayne 
> > > Cc: Brol, Eryk ; Zhuo, Qingqing
> > > ; sta...@vger.kernel.org; Zuo, Jerry
> > > ; dri-devel@lists.freedesktop.org; Kazlauskas,
> > > Nicholas 
> > > Subject: Re: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr
> > >
> > > On Mon, Feb 22, 2021 at 07:02:03PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Feb 22, 2021 at 12:00:26PM +0800, Wayne Lin wrote:
> > > > > [Why & How]
> > > > > According to DP spec, broadcast message LCT equals to 1 and LCR
> > > > > equals to 6. Current implementation is incorrect. Fix it.
> > > > >
> > > > > Signed-off-by: Wayne Lin 
> > > > > Cc: sta...@vger.kernel.org
> > > > > ---
> > > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 10 --
> > > > >  1 file changed, 8 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > index 17dbed0a9800..713ef3b42054 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > @@ -2727,8 +2727,14 @@ static int set_hdr_from_dst_qlock(struct
> > > > > drm_dp_sideband_msg_hdr *hdr,  else  hdr->broadcast = 0;
> > > > > hdr->path_msg = txmsg->path_msg;
> > > > > -hdr->lct = mstb->lct;
> > > > > -hdr->lcr = mstb->lct - 1;
> > > > > +if (hdr->broadcast) {
> > > > > +hdr->lct = 1;
> > > > > +hdr->lcr = 6;
> > > > > +} else {
> > > > > +hdr->lct = mstb->lct;
> > > > > +hdr->lcr = mstb->lct - 1;
> > > > > +}
> > > > > +
> > > > >  if (mstb->lct > 1)
> > > > >  memcpy(hdr->rad, mstb->rad, mstb->lct / 2);
> > > >
> > > > We should also do something about RAD no?
> > >
> > > Just skip the RAD stuff by s/mstb->lct/hdr->lct/ here I guess?
> > Thanks Ville!
> > Since LCT=1, broadcast message doesn't have a RAD and this is taken
> > care while we're constructing the header in 
> > drm_dp_encode_sideband_msg_hdr().
> > In drm_dp_encode_sideband_msg_hdr(), we skip stuffing RAD if LCT=1.
>
> Ugh. How many levels of these do we really need...
> Either way I'd prefer the code be consistent so you don't have to sacrifice 
> so many brain cells to understand what should be trivial
> details.
Hi Ville,
Ya I know.. Currently it goes few levels to encapsulate the final mst packet.
>From my understanding, this function is trying to prepare needed data and the 
>actual mst packet header is constructed in drm_dp_encode_sideband_msg_hdr().
However, I will push another version by your suggestion.
Thanks for your time!
>
> --
> Ville Syrjälä
> Intel
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2 0/2] Set CLEAR_PAYLOAD_ID_TABLE as broadcast request

[Lin, Wayne]

[AMD Public Use]

Thanks Lyude!

Regards,
Wayne

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, February 25, 2021 2:09 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; sta...@vger.kernel.org; Kazlauskas, 
> Nicholas ; Wentland, Harry
> ; Zuo, Jerry ; Brol, Eryk 
> ; Zhuo, Qingqing
> 
> Subject: Re: [PATCH v2 0/2] Set CLEAR_PAYLOAD_ID_TABLE as broadcast request
>
> also - I meant to reply to v2, not v1 :). Just so you don't worry that I 
> pushed the wrong patch series version
>
> On Wed, 2021-02-24 at 18:15 +0800, Wayne Lin wrote:
> > While testing MST hotplug events on daisy chain monitors, find out
> > that CLEAR_PAYLOAD_ID_TABLE is not broadcasted and payload id table is
> > not reset. Dig in deeper and find out two parts needed to be fixed.
> >
> > 1. Link_Count_Total & Link_Count_Remaining of Broadcast message are
> > incorrect. Should set lct=1 & lcr=6 2. CLEAR_PAYLOAD_ID_TABLE request
> > message is not set as path broadcast request message. Should fix this.
> >
> > Changes since v1:
> > *Refer to the suggestion from Ville Syrjala. While preparing hdr-rad,
> > take broadcast case into consideration.
> >
> > Wayne Lin (2):
> >   drm/dp_mst: Revise broadcast msg lct & lcr
> >   drm/dp_mst: Set CLEAR_PAYLOAD_ID_TABLE as broadcast
> >
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 17 -
> >  1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > --
> > 2.17.1
> >
>
> --
> Sincerely,
>Lyude Paul (she/her)
>Software Engineer at Red Hat
>
> Note: I deal with a lot of emails and have a lot of bugs on my plate. If 
> you've asked me a question, are waiting for a review/merge on a
> patch, etc. and I haven't responded in a while, please feel free to send me 
> another email to check on my status. I don't bite!

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs

[Lin, Wayne]

[Public]

> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, March 16, 2022 8:48 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref 
> histories from debugfs
>
> (Adding this back to the dri-devel mailing list since I didn't notice it got
> dropped from there)
>
> Hm, some comments on this issue down below. Sorry for the delayed response, I
> was going to try this right after I finished the MST legacy removal but that's
> ending up taking longer than I hoped.
>
> On Tue, 2022-03-08 at 01:46 +, Lin, Wayne wrote:
> > [AMD Official Use Only]
> >
> > Oops...
> > I didn't notice that I replied to wrong mail previously : P
> > Sorry for the confusion and reply to the correct thread.
> >
> > Good day!
> > I probably know why you can't reproduce the issue there. Please refer to the
> > attached
> > patch file which makes me easier to explain this.
> >
> > In dm_dp_mst_get_modes(), we will create a new dc_sink by calling
> > dc_link_add_remote_sink() and add that dc_sink into the array dc_link-
> > >remote_sinks[].
> > However, if we find that aconnector->dc_sink is not null, then we won't
> > create a new
> > dc_sink for that aconnector and won't add the sink to the array dc_link-
> > >remote_sinks[].
> >
> > When the issue that I mentioned before occurs, we won't be able to release
> > the dc_sink
> > for the aconnector when we unplug the sst monitor. Hence, we can't create
> > new dc_sink
> > for the latter on connected new stream sink of that port. Which leads to two
> > issues
> > 1. Unplug monitor and plug in another monitor "to the same port"
> > =>  Since we use the same dc_sink to reflect the capability of the new
> > connected stream
> > sink, we might send out inappropriate stream to the new connected sink.
> > 2. Because we can't release dc_sink in the array dc_link->remote_sinks[],
> > when we
> > plug/unplug sst monitor to more than 4 different mst port, we will break the
> > criteria
> > "dc_link->sink_count >= MAX_SINKS_PER_LINK" in
> > link_add_remote_sink_helper().
>
> Ok, a lot of this seems to be happening in amdgpu which certainly explains why
> I had so much trouble following along with this originally (also, having
> learned a bit more about how DC works definitely has helped a bit). I already
> see a bunch of issues though with how this code is structured that would
> definitely break things, though note I haven't sat down and tried this on a
> real machine yet - will try tomorrow.
>
> So - it seems like dc_sink == a bunch of hotplugging state for a dm connector,
> which actually tells me for one that this is definitely the wrong spot for
> this code. get_modes() really should just handle filling out DRM modes and
> pretty much nothing else, because callers from DRM aren't going to expect
> side-effects like this when get_modes() is called - which could potentially
> lead to all sorts of weirdness down the line if the DRM call paths that use
> this ever change. i915 and nouveau have good examples of what these functions
> should typically look like, and amdgpu actually seems to mostly follow this
> advice for it's other get_modes() callback.
>
> Note there's also another problem here: the assumption "no EDID ==
> disconnected" isn't correct. It's totally possible to run into EDID-less
> displays if the display is some ancient pre-historic relic, or if the ROM (or
> EEPROM? can't remember what type of chip computer displays tend to use...) 
> chip
> in the monitor containing the EDID has died. Note that the second situation is
> suprisingly more common then one might think! I ran into a 140Hz 4k ASUS
> display where this happened, and I know another friend of mine who had the ROM
> in their display die randomly as well.
>
> So with this being said: I, think the solution here is actually just to
> add/remove dc_sink from dm_dp_mst_detect() based on the CSN, and drop the
> calls from get_modes()? detect() should always be called before the connector
> has been removed, and we could use the return status from
> drm_dp_mst_detect_port() in order to tell whether or not we should add/remove
> the dc_sink.

Thank you Lyude for guiding me through! After your elaboration, I think I 
roughly
know the idea from drm perspective now. Let me get through this and will get 
back
to you.

>
> If you don't get to it first tomorrow, I'll see if I can reproduce this
&g

RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, September 2, 2021 6:00 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ;
> Ville Syrjälä ; Daniel Vetter 
> ; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ; 
> Thomas Zimmermann ;
> David Airlie ; Daniel Vetter ; Deucher, 
> Alexander ; Siqueira,
> Rodrigo ; Pillai, Aurabindo 
> ; Bas Nieuwenhuizen
> ; Cornij, Nikola ; Jani 
> Nikula ; Manasi Navare
> ; Ankit Nautiyal ; 
> José Roberto de Souza ; Sean
> Paul ; Ben Skeggs ; 
> sta...@vger.kernel.org
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> Actually - did some more thinking, and I think we shouldn't try to make 
> changes like this until we actually know what the problem is
> here. I could try to figure out what the actual race conditions I was facing 
> before with trying to add/destroy connectors based on PDT,
> but we still don't even actually have a clear idea of what's broken here. I'd 
> much rather us figure out exactly how this leak is
> happening before considering making changes like this, because we have no way 
> of knowing if we've properly fixed it or not if we
> don't know what the problem is in the first place.
>
> I'm still happy to write up the topology debugging stuff I mentioned to you 
> if you think that would help you debug this issue - since
> that would make it a lot easier for you to track down what references are 
> keeping a connector alive (and additkionally, where those
> references were taken in code. thanks
> stack_depot!)
Hi Lyude,
Sorry for late response. A bit busy on other stuff recently..

Really really thankful for all your help : ) I'm also glad to have the 
debugging tool if it won’t bother you too much. But before debugging,
I need to have consensus with you about where do we expect to release resource 
allocated for a stream sink when it's reported as
disconnected. Previous patch suggests releasing resource when connector is 
destroyed which will happen when topology refcount
reaches zero (i.e. unplug mstb from topology). But when the case is receiving 
CSN notifying connection change, we don't try to destroy
connector in this case now. And this is not caused by topology/malloc refcount 
leak since I don't expect neither one of them get
decrease to zero under this case (topology of mstbs and ports is not changed). 
Hence, my plan was to also try to destroy connector under
this case and the reason is reasonable to me as described in previous mail. 
With this patch set, I can see connectors eventually get
successfully destroyed after userspace committing set_crtc() to free connectors 
(although also need a fix on the connector refcount
grabbed by drm_client_modeset_probe() under specific scenario).

I think the main problem I encountered here is that I couldn't find a place 
that notify us to release resource allocated for a disconnected
stream sink when receive CSN. If we decide not to destroy connector under this 
case, then I probably need some guidance about where
to do the release work.

Thanks again Lyude!
>
> On Tue, 2021-08-31 at 18:47 -0400, Lyude Paul wrote:
> > (I am going to try responding to this tomorrow btw. I haven't been
> > super busy this week, but this has been a surprisingly difficult email
> > to respond to because I need to actually need to do a deep dive some
> > of the MST helpers tomorrow to figure out more of the specifics on why
> > I realized we couldn't just hot add/remove port->connector here).
> >
> > On Wed, 2021-08-25 at 03:35 +, Lin, Wayne wrote:
> > > [Public]
> > >
> > > > -Original Message-
> > > > From: Lyude Paul 
> > > > Sent: Tuesday, August 24, 2021 5:18 AM
> > > > To: Lin, Wayne ;
> > > > dri-devel@lists.freedesktop.org
> > > > Cc: Kazlauskas, Nicholas ; Wentland,
> > > > Harry ; Zuo, Jerry ;
> > > > Wu, Hersen ; Juston Li ;
> > > > Imre Deak ; Ville Syrjälä
> > > > ; Daniel Vetter
> > > > ; Sean Paul ; Maarten
> > > > Lankhorst ; Maxime Ripard
> > > > ; Thomas Zimmermann ;
> > > > David Airlie ; Daniel Vetter ;
> > > > Deucher, Alexander ; Siqueira, Rodrigo
> > > > ; Pillai, Aurabindo
> > > > ; Bas Nieuwenhuizen
> > > > ; Cornij, Nikola ;
> > > > Jani Nikula ; Manasi Navare
> > > > ; Ankit Nautiyal
> > > > ; José Roberto de Souza
> > > > ; Sean Paul ; Ben
> > > > Skeggs ; sta...@vger.kernel.org
&

RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

Thanks Lyude! And sorry for late reply.
I'm also struggling for other tasks so haven't get through your detail 
elaboration honestly.
Would like to take time to think through your elaboration : ) Anyway, will 
response it ASAP.

Thanks again!

> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, October 13, 2021 5:17 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ; Ville
> Syrjälä ; Daniel Vetter 
> ; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ; 
> Thomas Zimmermann ; David Airlie
> ; Daniel Vetter ; Deucher, Alexander 
> ; Siqueira, Rodrigo
> ; Pillai, Aurabindo ; Bas 
> Nieuwenhuizen ; Cornij,
> Nikola ; Jani Nikula ; Manasi 
> Navare ; Ankit Nautiyal
> ; José Roberto de Souza ; 
> Sean Paul ; Ben Skeggs
> ; sta...@vger.kernel.org
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> OK - got sidetracked by an issue at work but I just resumed working on this 
> today, should hopefully have it done at the start of next week at
> the latest (hooray for having time to do things upstream again! :).
>
> On Tue, 2021-09-14 at 08:46 +, Lin, Wayne wrote:
> > [Public]
> >
> > > -Original Message-
> > > From: Lyude Paul 
> > > Sent: Thursday, September 2, 2021 6:00 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> > > Cc: Kazlauskas, Nicholas ; Wentland,
> > > Harry ; Zuo, Jerry ; Wu,
> > > Hersen ; Juston Li ; Imre
> > > Deak ; Ville Syrjälä
> > > ; Daniel Vetter
> > > ; Sean Paul ; Maarten
> > > Lankhorst ; Maxime Ripard
> > > ; Thomas Zimmermann ; David
> > > Airlie ; Daniel Vetter ; Deucher,
> > > Alexander ; Siqueira, Rodrigo
> > > ; Pillai, Aurabindo
> > > ; Bas Nieuwenhuizen
> > > ; Cornij, Nikola ;
> > > Jani Nikula ; Manasi Navare
> > > ; Ankit Nautiyal
> > > ; José Roberto de Souza
> > > ; Sean Paul ; Ben
> > > Skeggs ; sta...@vger.kernel.org
> > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for
> > > connected end device
> > >
> > > Actually - did some more thinking, and I think we shouldn't try to
> > > make changes like this until we actually know what the problem is
> > > here. I could try to figure out what the actual race conditions I
> > > was facing before with trying to add/destroy connectors based on
> > > PDT, but we still don't even actually have a clear idea of what's broken 
> > > here.
> > > I'd much rather us figure out exactly how this leak is happening
> > > before considering making changes like this, because we have no way
> > > of knowing if we've properly fixed it or not if we don't know what
> > > the problem is in the first place.
> > >
> > > I'm still happy to write up the topology debugging stuff I mentioned
> > > to you if you think that would help you debug this issue - since
> > > that would make it a lot easier for you to track down what
> > > references are keeping a connector alive (and additkionally, where
> > > those references were taken in code. thanks
> > > stack_depot!)
> > Hi Lyude,
> > Sorry for late response. A bit busy on other stuff recently..
> >
> > Really really thankful for all your help : ) I'm also glad to have the
> > debugging tool if it won’t bother you too much. But before debugging,
> > I need to have consensus with you about where do we expect to release
> > resource allocated for a stream sink when it's reported as
> > disconnected. Previous patch suggests releasing resource when
> > connector is destroyed which will happen when topology refcount
> > reaches zero (i.e. unplug mstb from topology). But when the case is
> > receiving CSN notifying connection change, we don't try to destroy
> > connector in this case now. And this is not caused by topology/malloc
> > refcount leak since I don't expect neither one of them get decrease to
> > zero under this case (topology of mstbs and ports is not changed).
> > Hence, my plan was to also try to destroy connector under this case
> > and the reason is reasonable to me as described in previous mail.
> > With this patch set, I can see connectors eventually get successfully
> > destroyed after userspace committing set_crtc() to free connectors
> > (although also need a fix on the connector refcount grabbed by
> > drm_client_modeset_probe

RE: [PATCH 3/4] drm/amd/display: Add DP 2.0 MST DC Support

[Lin, Wayne]

[Public]

> -Original Message-
> From: Bhawanpreet Lakha 
> Sent: Thursday, October 21, 2021 3:47 AM
> To: Zuo, Jerry ; dri-devel@lists.freedesktop.org; 
> ly...@redhat.com
> Cc: Wentland, Harry ; Lin, Wayne ; 
> Kazlauskas, Nicholas
> ; Lipski, Mikita ; 
> intel-...@lists.freedesktop.org
> Subject: [PATCH 3/4] drm/amd/display: Add DP 2.0 MST DC Support
>
> From: Fangzhi Zuo 
>
> Signed-off-by: Fangzhi Zuo 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c  |  14 +
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++  
> .../gpu/drm/amd/display/dc/core/dc_link_dp.c  |  19 ++
>  drivers/gpu/drm/amd/display/dc/dc_link.h  |   7 +
>  drivers/gpu/drm/amd/display/dc/dc_stream.h|  13 +
>  5 files changed, 333 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 8be04be19124..935a50d6e933 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -2354,6 +2354,11 @@ static enum surface_update_type 
> check_update_surfaces_for_stream(
>   if (stream_update->dsc_config)
>   su_flags->bits.dsc_changed = 1;
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + if (stream_update->mst_bw_update)
> + su_flags->bits.mst_bw = 1;
> +#endif
> +
>   if (su_flags->raw != 0)
>   overall_type = UPDATE_TYPE_FULL;
>
> @@ -2731,6 +2736,15 @@ static void commit_planes_do_stream_update(struct dc 
> *dc,
>   if (stream_update->dsc_config)
>   dp_update_dsc_config(pipe_ctx);
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + if (stream_update->mst_bw_update) {
> + if (stream_update->mst_bw_update->is_increase)
> + dc_link_increase_mst_payload(pipe_ctx, 
> stream_update->mst_bw_update->mst_stream_bw);
> + else
> + dc_link_reduce_mst_payload(pipe_ctx, 
> stream_update->mst_bw_update->mst_stream_bw);
> + }
> +#endif
> +
>   if (stream_update->pending_test_pattern) {
>   dc_link_dp_set_test_pattern(stream->link,
>   stream->test_pattern.type,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index e5d6cbd7ea78..b23972b6a27c 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -3232,6 +3232,9 @@ static struct fixed31_32 get_pbn_from_timing(struct 
> pipe_ctx *pipe_ctx)  static void
> update_mst_stream_alloc_table(
>   struct dc_link *link,
>   struct stream_encoder *stream_enc,
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename 
> stream_enc to dio_stream_enc?
> +#endif
>   const struct dp_mst_stream_allocation_table *proposed_table)  {
>   struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = { 0 
> }; @@ -3267,6 +3270,9 @@ static void
> update_mst_stream_alloc_table(
>   work_table[i].slot_count =
>   
> proposed_table->stream_allocations[i].slot_count;
>   work_table[i].stream_enc = stream_enc;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + work_table[i].hpo_dp_stream_enc = hpo_dp_stream_enc; 
> #endif
>   }
>   }
>
> @@ -3389,6 +3395,10 @@ enum dc_status dc_link_allocate_mst_payload(struct 
> pipe_ctx *pipe_ctx)
>   struct dc_link *link = stream->link;
>   struct link_encoder *link_encoder = NULL;
>   struct stream_encoder *stream_encoder = pipe_ctx->stream_res.stream_enc;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + struct hpo_dp_link_encoder *hpo_dp_link_encoder = link->hpo_dp_link_enc;
> + struct hpo_dp_stream_encoder *hpo_dp_stream_encoder =
> +pipe_ctx->stream_res.hpo_dp_stream_enc;
> +#endif
>   struct dp_mst_stream_allocation_table proposed_table = {0};
>   struct fixed31_32 avg_time_slots_per_mtp;
>   struct fixed31_32 pbn;
> @@ -3416,7 +3426,14 @@ enum dc_status dc_link_allocate_mst_payload(struct 
> pipe_ctx *pipe_ctx)
>   &proposed_table,
>   true)) {
>   update_mst_stream_alloc_table(
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + link,
> + pipe_ctx-&g

RE: [PATCH 3/4] drm/amd/display: Add DP 2.0 MST DC Support

[Lin, Wayne]

[Public]

Hi Bhawan,
It looks good to me. Thanks!
Reviewed-by: Wayne Lin 

Regards,
Wayne
> -Original Message-
> From: Bhawanpreet Lakha 
> Sent: Thursday, October 21, 2021 11:16 PM
> To: Zuo, Jerry ; dri-devel@lists.freedesktop.org; 
> ly...@redhat.com
> Cc: intel-...@lists.freedesktop.org; Wentland, Harry 
> ; Lin, Wayne ; Kazlauskas,
> Nicholas ; Lipski, Mikita 
> ; Lakha, Bhawanpreet
> 
> Subject: [PATCH 3/4] drm/amd/display: Add DP 2.0 MST DC Support
>
> From: Fangzhi Zuo 
>
> [Why]
> configure/call DC interface for DP2 mst support. This is needed to make DP2 
> mst work.
>
> [How]
> - add encoding type, logging, mst update/reduce payload functions
>
> Use the link encoding to determine the DP type (1.4 or 2.0) and add a flag to 
> dc_stream_update to determine whether to increase/reduce
> payloads.
>
> v2:
> * add DP_UNKNOWN_ENCODING handling
>
> Signed-off-by: Fangzhi Zuo 
> Signed-off-by: Bhawanpreet Lakha 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c  |  14 +
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 292 ++  
> .../gpu/drm/amd/display/dc/core/dc_link_dp.c  |  19 ++
>  drivers/gpu/drm/amd/display/dc/dc_link.h  |   7 +
>  drivers/gpu/drm/amd/display/dc/dc_stream.h|  13 +
>  5 files changed, 345 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 8be04be19124..935a50d6e933 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -2354,6 +2354,11 @@ static enum surface_update_type 
> check_update_surfaces_for_stream(
>   if (stream_update->dsc_config)
>   su_flags->bits.dsc_changed = 1;
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + if (stream_update->mst_bw_update)
> + su_flags->bits.mst_bw = 1;
> +#endif
> +
>   if (su_flags->raw != 0)
>   overall_type = UPDATE_TYPE_FULL;
>
> @@ -2731,6 +2736,15 @@ static void commit_planes_do_stream_update(struct dc 
> *dc,
>   if (stream_update->dsc_config)
>   dp_update_dsc_config(pipe_ctx);
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + if (stream_update->mst_bw_update) {
> + if (stream_update->mst_bw_update->is_increase)
> + dc_link_increase_mst_payload(pipe_ctx, 
> stream_update->mst_bw_update->mst_stream_bw);
> + else
> + dc_link_reduce_mst_payload(pipe_ctx, 
> stream_update->mst_bw_update->mst_stream_bw);
> + }
> +#endif
> +
>   if (stream_update->pending_test_pattern) {
>   dc_link_dp_set_test_pattern(stream->link,
>   stream->test_pattern.type,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index e5d6cbd7ea78..ec5f107bc85a 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -3232,6 +3232,9 @@ static struct fixed31_32 get_pbn_from_timing(struct 
> pipe_ctx *pipe_ctx)  static void
> update_mst_stream_alloc_table(
>   struct dc_link *link,
>   struct stream_encoder *stream_enc,
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename 
> stream_enc to dio_stream_enc?
> +#endif
>   const struct dp_mst_stream_allocation_table *proposed_table)  {
>   struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = { 0 
> }; @@ -3267,6 +3270,9 @@ static void
> update_mst_stream_alloc_table(
>   work_table[i].slot_count =
>   
> proposed_table->stream_allocations[i].slot_count;
>   work_table[i].stream_enc = stream_enc;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + work_table[i].hpo_dp_stream_enc = hpo_dp_stream_enc; 
> #endif
>   }
>   }
>
> @@ -3389,6 +3395,10 @@ enum dc_status dc_link_allocate_mst_payload(struct 
> pipe_ctx *pipe_ctx)
>   struct dc_link *link = stream->link;
>   struct link_encoder *link_encoder = NULL;
>   struct stream_encoder *stream_encoder = pipe_ctx->stream_res.stream_enc;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + struct hpo_dp_link_encoder *hpo_dp_link_encoder = link->hpo_dp_link_enc;
> + struct hpo_dp_stream_encoder *hpo_dp_stream_encoder =
> +pipe_ctx->stream_r

RE: [PATCH 4/4] drm/amd/display: Add DP 2.0 MST DM Support

[Lin, Wayne]

[AMD Official Use Only]

Hi Bhawan,
Just a nitpick below. With that fixed, feel free to add:
Reviewed-by: Wayne Lin 

Thanks!

Regards,
Wayne
> -Original Message-
> From: Bhawanpreet Lakha 
> Sent: Thursday, October 21, 2021 3:47 AM
> To: Zuo, Jerry ; dri-devel@lists.freedesktop.org; 
> ly...@redhat.com
> Cc: Wentland, Harry ; Lin, Wayne ; 
> Kazlauskas, Nicholas
> ; Lipski, Mikita ; 
> intel-...@lists.freedesktop.org; Lakha, Bhawanpreet
> 
> Subject: [PATCH 4/4] drm/amd/display: Add DP 2.0 MST DM Support
>
> [Why]
> Add DP2 MST and debugfs support
>
> [How]
> Update the slot info based on the link encoding format
>
> Signed-off-by: Bhawanpreet Lakha 
> Signed-off-by: Fangzhi Zuo 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++  
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |
> 3 ++  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  5 +++-
>  3 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e56f73e299ef..875425ee91d0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -10741,6 +10741,8 @@ static int amdgpu_dm_atomic_check(struct drm_device 
> *dev,  #if defined(CONFIG_DRM_AMD_DC_DCN)
>   struct dsc_mst_fairness_vars vars[MAX_PIPES];  #endif
> + struct drm_dp_mst_topology_state *mst_state;
> + struct drm_dp_mst_topology_mgr *mgr;
>
>   trace_amdgpu_dm_atomic_check_begin(state);
>
> @@ -10948,6 +10950,33 @@ static int amdgpu_dm_atomic_check(struct drm_device 
> *dev,
>   lock_and_validation_needed = true;
>   }
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + /* set the slot info for each mst_state based on the link encoding 
> format */
> + for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
> + struct amdgpu_dm_connector *aconnector;
> + struct drm_connector *connector;
> + struct drm_connector_list_iter iter;
> + u8 link_coding_cap;
> +
> + if (!mgr->mst_state )
> + continue;
> +
> + drm_connector_list_iter_begin(dev, &iter);
> + drm_for_each_connector_iter(connector, &iter) {
> + int id = connector->index;
> +
> + if (id == mst_state->mgr->conn_base_id) {
> + aconnector = to_amdgpu_dm_connector(connector);
> + link_coding_cap = 
> dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
> + drm_dp_mst_update_slots(mst_state, 
> link_coding_cap);
> +
> + break;
> + }
> + }
> + drm_connector_list_iter_end(&iter);
> +
> + }
> +#endif
>   /**
>* Streams and planes are reset when there are changes that affect
>* bandwidth. Anything that affects bandwidth needs to go through diff 
> --git
> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 9b3ad56607bb..1a68a674913c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -294,6 +294,9 @@ static ssize_t dp_link_settings_write(struct file *f, 
> const char __user *buf,
>   case LINK_RATE_RBR2:
>   case LINK_RATE_HIGH2:
>   case LINK_RATE_HIGH3:
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + case LINK_RATE_UHBR10:
> +#endif
>   break;
>   default:
>   valid_input = false;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 6169488e2011..53b5cc7b0679 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -219,6 +219,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
>   struct drm_dp_mst_topology_mgr *mst_mgr;
>   struct drm_dp_mst_port *mst_port;
>   bool ret;
> + u8 link_coding_cap;
>
>   aconnector = (struct amdgpu_dm_connector *)stream->dm_stream_context;
>   /* Accessing the connector state is required for vcpi_slots allocation 
> @@ -238,6 +239,8 @@ bool
> dm_helpers_dp_mst_write_payload_allocation_table(
>
>   mst_port = aconnector->port;
>
> + link_coding_cap =
> +dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
> +
>   if

RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

Hi Lyude!
Apologize for replying late and really thanks for elaborating in such details!
Following are some of my thoughts : )

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, September 18, 2021 1:48 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ; Ville
> Syrjälä ; Daniel Vetter 
> ; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ; 
> Thomas Zimmermann ; David Airlie
> ; Daniel Vetter ; Deucher, Alexander 
> ; Siqueira, Rodrigo
> ; Pillai, Aurabindo ; Bas 
> Nieuwenhuizen ; Cornij,
> Nikola ; Jani Nikula ; Manasi 
> Navare ; Ankit Nautiyal
> ; José Roberto de Souza ; 
> Sean Paul ; Ben Skeggs
> ; sta...@vger.kernel.org
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> Sorry about the slow response, this week XDC has been going on and I've been 
> mostly paying attention to that.
>
> On Tue, 2021-09-14 at 08:46 +, Lin, Wayne wrote:
> > [Public]
> >
> > > -----Original Message-
> > > From: Lyude Paul 
> > > Sent: Thursday, September 2, 2021 6:00 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> > > Cc: Kazlauskas, Nicholas ; Wentland,
> > > Harry ; Zuo, Jerry ; Wu,
> > > Hersen ; Juston Li ; Imre
> > > Deak ; Ville Syrjälä
> > > ; Daniel Vetter
> > > ; Sean Paul ; Maarten
> > > Lankhorst ; Maxime Ripard
> > > ; Thomas Zimmermann ; David
> > > Airlie ; Daniel Vetter ; Deucher,
> > > Alexander ; Siqueira, Rodrigo
> > > ; Pillai, Aurabindo
> > > ; Bas Nieuwenhuizen
> > > ; Cornij, Nikola ;
> > > Jani Nikula ; Manasi Navare
> > > ; Ankit Nautiyal
> > > ; José Roberto de Souza
> > > ; Sean Paul ; Ben
> > > Skeggs ; sta...@vger.kernel.org
> > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for
> > > connected end device
> > >
> > > Actually - did some more thinking, and I think we shouldn't try to
> > > make changes like this until we actually know what the problem is
> > > here. I could try to figure out what the actual race conditions I
> > > was facing before with trying to add/destroy connectors based on
> > > PDT, but we still don't even actually have a clear idea of what's broken 
> > > here.
> > > I'd much rather us figure out exactly how this leak is happening
> > > before considering making changes like this, because we have no way
> > > of knowing if we've properly fixed it or not if we don't know what
> > > the problem is in the first place.
> > >
> > > I'm still happy to write up the topology debugging stuff I mentioned
> > > to you if you think that would help you debug this issue - since
> > > that would make it a lot easier for you to track down what
> > > references are keeping a connector alive (and additkionally, where
> > > those references were taken in code. thanks
> > > stack_depot!)
> > Hi Lyude,
> > Sorry for late response. A bit busy on other stuff recently..
> >
> > Really really thankful for all your help : ) I'm also glad to have the
> > debugging tool if it won’t bother you too much. But before debugging,
>
> no problem! I will get to it early next week then
>
> > I need to have consensus with you about where do we expect to release
> > resource allocated for a stream sink when it's reported as
> > disconnected. Previous patch suggests releasing resource when
> > connector is destroyed which will happen when topology refcount
> > reaches zero (i.e. unplug mstb from topology). But when the case is
> > receiving CSN notifying connection change, we don't try to destroy
> > connector in this case now. And this is not caused by topology/malloc
> > refcount leak since I don't expect neither one of them get decrease to
> > zero under this case (topology of mstbs and ports is not changed).
> > Hence, my plan was to also try to destroy connector under
>
> Ah - I wonder if this might have been where some of the confusion here came 
> from. So-both mstbs and ports (assume I'm talking the actual
> drm_dp_mst_port and drm_dp_mst_branch structs here) are supposed to have 
> non-zero topology refcounts as long as there is a valid path
> between the port or mstb, and our source. This also means that for ports, the 
> drm_connector associated with these ports should stay
> around as long as the port is reachable from the sink
> - regardl

RE: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs

[Lin, Wayne]

[Public]

Hey Lyude,

Sorry, just got chance to get back to this and BIG THANKS to elaborating in 
such details!
Following are some of my comments : )

> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, January 19, 2022 9:59 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref 
> histories from debugfs
>
> Hey - so, the original issue here was that payloads were not always deleted 
> when we expected them to be - correct?

Actually, what I was trying to do is not relevant to payload maintenance. What 
I wanted to do is having a way to notify
amdgpu to release its enumerated resource "dc_sink" when unplug event occurs. 
Currently, under specific scenarios,
we can't release remote "dc_sink" and ends up can't allocate resource for new 
connected monitors. I'll explain the scenario
underneath.

So, get back to the main issue that I was trying to solve when I pushed the 
patchset:
https://patchwork.kernel.org/project/dri-devel/cover/20210720160342.11415-1-wayne@amd.com/

I was trying to fix some problems that I observed after these 2 patches
* 09b974e8983 drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback
* 72dc0f51591 drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connector

With above patches, it changes our flow to remove dc_sink (by calling 
dc_link_remote_sink()) when connector is about to be
destroyed. And let's see below use cases:
a). Disconnection happens between mst branch devices
e.g.
src - 1st_mstb - 2nd_mstb - sst_monitor => src - 1st_mstb (disconnect) 2nd_mstb 
- sst_monitor

In above case, after receiving CSN, we will put topology reference count of 2nd 
mstb and its port which connected to the sst monitor.
As you suggested before, we will destroy 2nd mst branch device and its all 
ports due to there is no more mst path can route to them.
As the result of that, we at end call drm_dp_delayed_destroy_port() and 
unregister/put the drm connector and eventually call
 dc_link_remote_sink() to release the dc_sinck we enumerate for the specific 
stream sink of sst_monitor.

However, in below case:
b). Disconnection happens between mst branch devices and SST monitor
e.g.
src - 1st_mstb - sst_monitor => src - 1st_mstb (disconnect)  sst_monitor

In this case, which is the case having problem, it definitely won't decrease 
the topology references count of the port of 1st_mstb which
was connected to the sst monitor to zero since the port is still existing in 
the topology. Same as the malloc reference since the port can't get
destroyed. Hence, the port still exists and we won't call 
drm_dp_delayed_destroy_port() to unregister and put the drm connector. As the
result of that, we can't release corresponding remote dc_sink under this case. 
And after few times hotplugs, we can't create any new
dc_sink since the number of stream sink is exceeding our limitation.

Hence, what I'm thinking here is to register a callback function for notifying 
us that the remote sink is detached. This just aligns what we do
for handling long HPD event (unplug monitor from system) of legacy DP (none 
mst). For which case, once we detect long HPD event
indicating the monitor is detached, we will immediately try to release the 
dc_link->local_sink and fire hotplug event to upper layer.
Same as here, once receives a CSN message notifying a drm connector is changed 
from connected to disconnected, trigger the callback
function and we can try to release the dc_sink resource.

>
> If I'm remembering that correctly, then (and I'm not 100% sure on this yet) I 
> might already have noticed something very possibly wonky in
> how we handle payload allocations currently, that I found while working on 
> the non-atomic removal branch that I linked to you in my
> previous response. Basically, in the
> step1() function it looks like that we follow this general flow with updating
> payloads:
>
>  * Loop through proposed payloads and compare to previously programmed
>payloads
> - If a payload has a different allocation then it previously did, update 
> the
>   payload
> - If the payload is new, create it
> - If a payload no longer has an allocation, remove the payload
>
> At first glance this seems totally correct - but I'm not actually entirely 
> convinced it is? Particularly because it seems like the order in which
> we do creation/deletion of payloads is totally arbitrary. To explain what I 
> mean by that, consider a state transition like this:
>
> vcpi_slots=15 vcpi_slots=35 vcpi_slots=14
> | 1 | 2 ||
>
> Let's say we want to increase payload #1 from 15 to 50, and disable payload 
> #2 in the same atomic commit on DRM's side. If the order we
> update payloads is entirely arbitr

RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

[Lin, Wayne]

[Public]

Thanks Lyude for patiently guiding on this : )
Would like to learn more as following

> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, October 27, 2021 3:35 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry 
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li 
> ; Imre Deak ;
> Ville Syrjälä ; Daniel Vetter 
> ; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ; 
> Thomas Zimmermann ;
> David Airlie ; Daniel Vetter ; Deucher, 
> Alexander ; Siqueira,
> Rodrigo ; Pillai, Aurabindo 
> ; Bas Nieuwenhuizen
> ; Cornij, Nikola ; Jani 
> Nikula ; Manasi Navare
> ; Ankit Nautiyal ; 
> José Roberto de Souza ; Sean
> Paul ; Ben Skeggs ; 
> sta...@vger.kernel.org
> Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end 
> device
>
> Comments below
>
> On Tue, 2021-10-26 at 03:50 +, Lin, Wayne wrote:
> > [Public]
> >
> > Hi Lyude!
> > Apologize for replying late and really thanks for elaborating in such
> > details!
> > Following are some of my thoughts : )
> >
> > > -Original Message-
> > > From: Lyude Paul 
> > > Sent: Saturday, September 18, 2021 1:48 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> > > Cc: Kazlauskas, Nicholas ; Wentland,
> > > Harry ; Zuo, Jerry ; Wu,
> > > Hersen ; Juston Li ; Imre
> > > Deak ; Ville Syrjälä
> > > ; Daniel Vetter
> > > ; Sean Paul ; Maarten
> > > Lankhorst ; Maxime Ripard
> > > ; Thomas Zimmermann ; David
> > > Airlie ; Daniel Vetter ; Deucher,
> > > Alexander ; Siqueira, Rodrigo
> > > ; Pillai, Aurabindo
> > > ; Bas Nieuwenhuizen
> > > ; Cornij, Nikola ;
> > > Jani Nikula ; Manasi Navare
> > > ; Ankit Nautiyal
> > > ; José Roberto de Souza
> > > ; Sean Paul ; Ben
> > > Skeggs ; sta...@vger.kernel.org
> > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for
> > > connected end device
> > >
> > > Sorry about the slow response, this week XDC has been going on and
> > > I've been mostly paying attention to that.
> > >
> > > On Tue, 2021-09-14 at 08:46 +, Lin, Wayne wrote:
> > > > [Public]
> > > >
> > > > > -Original Message-
> > > > > From: Lyude Paul 
> > > > > Sent: Thursday, September 2, 2021 6:00 AM
> > > > > To: Lin, Wayne ;
> > > > > dri-devel@lists.freedesktop.org
> > > > > Cc: Kazlauskas, Nicholas ;
> > > > > Wentland, Harry ; Zuo, Jerry
> > > > > ; Wu, Hersen ; Juston Li
> > > > > ; Imre Deak ; Ville
> > > > > Syrjälä ; Daniel Vetter
> > > > > ; Sean Paul ; Maarten
> > > > > Lankhorst ; Maxime Ripard
> > > > > ; Thomas Zimmermann ;
> > > > > David Airlie ; Daniel Vetter
> > > > > ; Deucher, Alexander
> > > > > ; Siqueira, Rodrigo
> > > > > ; Pillai, Aurabindo
> > > > > ; Bas Nieuwenhuizen
> > > > > ; Cornij, Nikola
> > > > > ; Jani Nikula ;
> > > > > Manasi Navare ; Ankit Nautiyal
> > > > > ; José Roberto de Souza
> > > > > ; Sean Paul ; Ben
> > > > > Skeggs ; sta...@vger.kernel.org
> > > > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for
> > > > > connected end device
> > > > >
> > > > > Actually - did some more thinking, and I think we shouldn't try
> > > > > to make changes like this until we actually know what the
> > > > > problem is here. I could try to figure out what the actual race
> > > > > conditions I was facing before with trying to add/destroy
> > > > > connectors based on PDT, but we still don't even actually have a
> > > > > clear idea of what's broken here.
> > > > > I'd much rather us figure out exactly how this leak is happening
> > > > > before considering making changes like this, because we have no
> > > > > way of knowing if we've properly fixed it or not if we don't
> > > > > know what the problem is in the first place.
> > > > >
> > > > > I'm still happy to write up the topology debugging stuff I
> > > > > mentioned to you if you think that would help you debug this
> > > > > issue - since that would make it a lot easier for you to track
> > >

RE: [PATCH] drm/amd/display: Fix unused variable warning

[Lin, Wayne]

[AMD Official Use Only - Internal Distribution Only]

Thanks Arnd.

Reviewed-by: Wayne Lin 

-Original Message-
From: Arnd Bergmann 
Sent: Sunday, January 3, 2021 10:03 PM
To: Wentland, Harry ; Li, Sun peng (Leo) 
; Deucher, Alexander ; Koenig, 
Christian ; David Airlie ; Daniel 
Vetter ; R, Bindu ; Lin, Wayne 

Cc: Arnd Bergmann ; Kazlauskas, Nicholas 
; Siqueira, Rodrigo ; 
Pillai, Aurabindo ; Wang, Chao-kai (Stylon) 
; Simon Ser ; Brol, Eryk 
; Bas Nieuwenhuizen ; Lakha, 
Bhawanpreet ; dri-devel@lists.freedesktop.org; 
linux-ker...@vger.kernel.org
Subject: [PATCH] drm/amd/display: Fix unused variable warning

From: Arnd Bergmann 

Some of the newly added code is hidden inside of #ifdef blocks, but one 
variable is unused when debugfs is disabled:

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8370:8: error: 
unused variable 'configure_crc' [-Werror,-Wunused-variable]

Change the #ifdef to an if(IS_ENABLED()) check to fix the warning and avoid 
adding more #ifdefs.

Fixes: c920888c604d ("drm/amd/display: Expose new CRC window property")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 42b0fdb72e7b..5071b55ad0f6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8379,8 +8379,7 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
 acrtc->dm_irq_params.stream = dm_new_crtc_state->stream;
 manage_dm_interrupts(adev, acrtc, true);
 }
-#ifdef CONFIG_DEBUG_FS
-if (new_crtc_state->active &&
+if (IS_ENABLED(CONFIG_DEBUG_FS) && new_crtc_state->active &&
 amdgpu_dm_is_valid_crc_source(dm_new_crtc_state->crc_src)) {
 /**
  * Frontend may have changed so reapply the CRC capture @@ -8401,7 +8400,6 @@ 
static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
 amdgpu_dm_crtc_configure_crc_source(
 crtc, dm_new_crtc_state, dm_new_crtc_state->crc_src);
 }
-#endif
 }

 for_each_new_crtc_in_state(state, crtc, new_crtc_state, j) diff --git 
a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
index 0235bfb246e5..eba2f1d35d07 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
@@ -46,13 +46,13 @@ static inline bool amdgpu_dm_is_valid_crc_source(enum 
amdgpu_dm_pipe_crc_source  }

 /* amdgpu_dm_crc.c */
-#ifdef CONFIG_DEBUG_FS
 bool amdgpu_dm_crc_window_is_default(struct dm_crtc_state *dm_crtc_state);  
bool amdgpu_dm_crc_window_changed(struct dm_crtc_state *dm_new_crtc_state,
 struct dm_crtc_state *dm_old_crtc_state);  int 
amdgpu_dm_crtc_configure_crc_source(struct drm_crtc *crtc,
 struct dm_crtc_state *dm_crtc_state,
 enum amdgpu_dm_pipe_crc_source source);
+#ifdef CONFIG_DEBUG_FS
 int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char 
*src_name);  int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
  const char *src_name,
--
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 3/3] Revert "drm/amd/display: Expose new CRC window property"

[Lin, Wayne]

[AMD Public Use]

Thanks Siqueira.
Comments below.

> -Original Message-
> From: Siqueira, Rodrigo 
> Sent: Friday, January 8, 2021 4:53 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Lin, Wayne ; Deucher, Alexander 
> ; Wentland, Harry
> ; Li, Roman ; R, Bindu 
> ; Daniel Vetter 
> Subject: [PATCH 3/3] Revert "drm/amd/display: Expose new CRC window property"
>
> This reverts commit 110d586ba77ed573eb7464ca69b6490ec0b70c5f.
>
> Cc: Wayne Lin 
> Cc: Alexander Deucher 
> Cc: Harry Wentland 
> Cc: Roman Li 
> Cc: Bindu R 
> Cc: Daniel Vetter 
> Signed-off-by: Rodrigo Siqueira 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 +-  
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |
> 19 ---  .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c |  56 +--
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h |   3 -
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c |   2 +
>  5 files changed, 12 insertions(+), 210 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a06554745238..0515ed0d125c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -938,41 +938,6 @@ static void mmhub_read_system_context(struct 
> amdgpu_device *adev, struct dc_phy_  }  #endif
>
> -#ifdef CONFIG_DEBUG_FS
> -static int create_crtc_crc_properties(struct amdgpu_display_manager *dm) -{
> -dm->crc_win_x_start_property =
> -drm_property_create_range(adev_to_drm(dm->adev),
> -  DRM_MODE_PROP_ATOMIC,
> -  "AMD_CRC_WIN_X_START", 0, U16_MAX);
> -if (!dm->crc_win_x_start_property)
> -return -ENOMEM;
> -
> -dm->crc_win_y_start_property =
> -drm_property_create_range(adev_to_drm(dm->adev),
> -  DRM_MODE_PROP_ATOMIC,
> -  "AMD_CRC_WIN_Y_START", 0, U16_MAX);
> -if (!dm->crc_win_y_start_property)
> -return -ENOMEM;
> -
> -dm->crc_win_x_end_property =
> -drm_property_create_range(adev_to_drm(dm->adev),
> -  DRM_MODE_PROP_ATOMIC,
> -  "AMD_CRC_WIN_X_END", 0, U16_MAX);
> -if (!dm->crc_win_x_end_property)
> -return -ENOMEM;
> -
> -dm->crc_win_y_end_property =
> -drm_property_create_range(adev_to_drm(dm->adev),
> -  DRM_MODE_PROP_ATOMIC,
> -  "AMD_CRC_WIN_Y_END", 0, U16_MAX);
> -if (!dm->crc_win_y_end_property)
> -return -ENOMEM;
> -
> -return 0;
> -}
> -#endif
> -
>  static int amdgpu_dm_init(struct amdgpu_device *adev)  {
>  struct dc_init_data init_data;
> @@ -1119,10 +1084,6 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
>
>  dc_init_callbacks(adev->dm.dc, &init_params);
>  }
> -#endif
> -#ifdef CONFIG_DEBUG_FS
> -if (create_crtc_crc_properties(&adev->dm))
> -DRM_ERROR("amdgpu: failed to create crc property.\n");
>  #endif
>  if (amdgpu_dm_initialize_drm_device(adev)) {
>  DRM_ERROR(
> @@ -5456,64 +5417,12 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
>  state->crc_src = cur->crc_src;
>  state->cm_has_degamma = cur->cm_has_degamma;
>  state->cm_is_degamma_srgb = cur->cm_is_degamma_srgb; -#ifdef CONFIG_DEBUG_FS
> -state->crc_window = cur->crc_window;
> -#endif
> +
>  /* TODO Duplicate dc_stream after objects are stream object is flattened */
>
>  return &state->base;
>  }
>
> -#ifdef CONFIG_DEBUG_FS
> -static int amdgpu_dm_crtc_atomic_set_property(struct drm_crtc *crtc,
> -struct drm_crtc_state *crtc_state,
> -struct drm_property *property,
> -uint64_t val)
> -{
> -struct drm_device *dev = crtc->dev;
> -struct amdgpu_device *adev = drm_to_adev(dev);
> -struct dm_crtc_state *dm_new_state =
> -to_dm_crtc_state(crtc_state);
> -
> -if (property == adev->dm.crc_win_x_start_property)
> -dm_new_state->crc_window.x_start = val;
> -else if (property == adev->dm.crc_win_y_start_property)
> -dm_new_state->crc_window.y_start = val;
> -else if (property == adev->dm.crc_win_x_end_property)
> -dm_new_state->crc_window.x_end = val;
> -else if (property == adev->dm.crc_win_y_end_property)
> -dm_new_state->crc_window.y_end = val;
> -else
> -return -EINVAL;
> -
> -return 0;
> -}
> -
> -static int amdgpu_dm_crtc_atomic_get_property(struct drm_crtc *crtc,
> -const struct drm_crtc_state *state,
> -struct drm_property *property,
> -uint64_t *val)
> -{
> -struct drm_device *dev = crtc->dev;
> -struct amdgpu_device *adev = drm_to_adev(dev);
> -struct dm_crtc_state *dm_state =
> -to_dm_crtc_state(state);
> -
> -if (property == adev->dm.crc_win_x_start_property)

RE: [PATCH v2] drm/edid: ignore the CEA modes not defined in CEA-861-D

[Lin, Wayne]

[AMD Official Use Only - General]

Thanks William!

After fixing few typos below, feel free to add:

Acked-by: Wayne Lin 

> -Original Message-
> From: William Tseng 
> Sent: Monday, June 13, 2022 12:27 PM
> To: dri-devel@lists.freedesktop.org
> Cc: William Tseng ; Ville Syrjälä
> ; Jani Nikula ; 
> Lin,
> Wayne ; Lee Shawn C 
> Subject: [PATCH v2] drm/edid: ignore the CEA modes not defined in CEA-
> 861-D
> 
> This is a workaround for HDMI 1.4 sink which has a CEA mode with higher vic
> than what is defined in CEA-861-D.
> 
> As an example, a HDMI 1.4 sink has the video format 2560x1080p to be
> displayed and the video format is indicated by both SVD (with vic 90 and
> pictuure aspect ratio 64:27) and DTD.  When connecting to such sink, source

Typo - picture
> can't output the video format in SVD because an error is returned by
> drm_hdmi_avi_infoframe_from_display_mode(), which can't fill the
> infoframe with pictuure aspect ratio 64:27 and the vic, which is originally 90

Typo - picture
> and is changed to 0 by drm_mode_cea_vic().
> 
> To work around it, do not set the vic 0 so the corresponding mode may be
> accepted in drm_hdmi_avi_infoframe_from_display_mode() and be
> dispalyed.
> 
> Cc: Ville Syrjälä 
> Cc: Jani Nikula 
> Cc: Wayne Lin 
> Cc: Lee Shawn C 
> Signed-off-by: William Tseng 
> ---
>  drivers/gpu/drm/drm_edid.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bc43e1b32092..a4582627ec9d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5876,7 +5876,8 @@ static u8 drm_mode_hdmi_vic(const struct
> drm_connector *connector,  }
> 
>  static u8 drm_mode_cea_vic(const struct drm_connector *connector,
> -const struct drm_display_mode *mode)
> +const struct drm_display_mode *mode,
> +bool is_hdmi2_sink)
>  {
>   u8 vic;
> 
> @@ -5896,7 +5897,7 @@ static u8 drm_mode_cea_vic(const struct
> drm_connector *connector,
>* HDMI 2.0 VIC range: 1 <= VIC <= 107 (CEA-861-F). So we
>* have to make sure we dont break HDMI 1.4 sinks.
>*/
> - if (!is_hdmi2_sink(connector) && vic > 64)
> + if (!is_hdmi2_sink && vic > 64)
>   return 0;
> 
>   return vic;
> @@ -5927,7 +5928,7 @@
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> *frame,
>   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>   frame->pixel_repeat = 1;
> 
> - vic = drm_mode_cea_vic(connector, mode);
> + vic = drm_mode_cea_vic(connector, mode, true);
>   hdmi_vic = drm_mode_hdmi_vic(connector, mode);
> 
>   frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE; @@ -
> 5971,7 +5972,8 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
>   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
>   }
> 
> - frame->video_code = vic;
> + frame->video_code = drm_mode_cea_vic(connector, mode,
> + is_hdmi2_sink(connector));
>   frame->picture_aspect = picture_aspect;
>   frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
>   frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
> --
> 2.17.1

RE: [PATCH v2] drm/edid: ignore the CEA modes not defined in CEA-861-D

[Lin, Wayne]

[Public]



> -Original Message-
> From: Tseng, William 
> Sent: Monday, June 13, 2022 4:05 PM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Ville Syrjälä ; Jani Nikula
> ; Lee, Shawn C 
> Subject: RE: [PATCH v2] drm/edid: ignore the CEA modes not defined in CEA-
> 861-D
> 
> Thanks Wayne for the comment.
> I don't quite understand what the typos are.
> Could you elaborate on them?
> Thank you.
> 
> -Original Message-
> From: Lin, Wayne 
> Sent: Monday, June 13, 2022 3:25 PM
> To: Tseng, William ; dri-
> de...@lists.freedesktop.org
> Cc: Ville Syrjälä ; Jani Nikula
> ; Lee, Shawn C 
> Subject: RE: [PATCH v2] drm/edid: ignore the CEA modes not defined in CEA-
> 861-D
> 
> [AMD Official Use Only - General]
> 
> Thanks William!
> 
> After fixing few typos below, feel free to add:
> 
> Acked-by: Wayne Lin 
> 
> > -Original Message-
> > From: William Tseng 
> > Sent: Monday, June 13, 2022 12:27 PM
> > To: dri-devel@lists.freedesktop.org
> > Cc: William Tseng ; Ville Syrjälä
> > ; Jani Nikula
> > ; Lin, Wayne ; Lee
> > Shawn C 
> > Subject: [PATCH v2] drm/edid: ignore the CEA modes not defined in CEA-
> > 861-D
> >
> > This is a workaround for HDMI 1.4 sink which has a CEA mode with
> > higher vic than what is defined in CEA-861-D.
> >
> > As an example, a HDMI 1.4 sink has the video format 2560x1080p to be
> > displayed and the video format is indicated by both SVD (with vic 90
> > and pictuure aspect ratio 64:27) and DTD.  When connecting to such

Hi William,
Change "pictuure aspect ratio" to "picture aspect ratio ".

> > sink, source
> 
> Typo - picture
> > can't output the video format in SVD because an error is returned by
> > drm_hdmi_avi_infoframe_from_display_mode(), which can't fill the
> > infoframe with pictuure aspect ratio 64:27 and the vic, which is

Same here.

> > originally 90
> 
> Typo - picture
> > and is changed to 0 by drm_mode_cea_vic().
> >
> > To work around it, do not set the vic 0 so the corresponding mode may
> > be accepted in drm_hdmi_avi_infoframe_from_display_mode() and be
> > dispalyed.
> >
> > Cc: Ville Syrjälä 
> > Cc: Jani Nikula 
> > Cc: Wayne Lin 
> > Cc: Lee Shawn C 
> > Signed-off-by: William Tseng 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index bc43e1b32092..a4582627ec9d 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -5876,7 +5876,8 @@ static u8 drm_mode_hdmi_vic(const struct
> > drm_connector *connector,  }
> >
> >  static u8 drm_mode_cea_vic(const struct drm_connector *connector,
> > -  const struct drm_display_mode *mode)
> > +  const struct drm_display_mode *mode,
> > +  bool is_hdmi2_sink)
> >  {
> > u8 vic;
> >
> > @@ -5896,7 +5897,7 @@ static u8 drm_mode_cea_vic(const struct
> > drm_connector *connector,
> >  * HDMI 2.0 VIC range: 1 <= VIC <= 107 (CEA-861-F). So we
> >  * have to make sure we dont break HDMI 1.4 sinks.
> >  */
> > -   if (!is_hdmi2_sink(connector) && vic > 64)
> > +   if (!is_hdmi2_sink && vic > 64)
> > return 0;
> >
> > return vic;
> > @@ -5927,7 +5928,7 @@
> > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > *frame,
> > if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > frame->pixel_repeat = 1;
> >
> > -   vic = drm_mode_cea_vic(connector, mode);
> > +   vic = drm_mode_cea_vic(connector, mode, true);
> > hdmi_vic = drm_mode_hdmi_vic(connector, mode);
> >
> > frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE; @@ -
> > 5971,7 +5972,8 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> > hdmi_avi_infoframe *frame,
> > picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> > }
> >
> > -   frame->video_code = vic;
> > +   frame->video_code = drm_mode_cea_vic(connector, mode,
> > +   is_hdmi2_sink(connector));
> > frame->picture_aspect = picture_aspect;
> > frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
> > frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
> > --
> > 2.17.1
--
Regards,
Wayne Lin

RE: [PATCH 1/3] drm/display/dp_mst: Don't validate port refs in drm_dp_check_and_send_link_address()

[Lin, Wayne]

[Public]

Thanks, Lyude.

Feel free to add
Reviewed-by: Wayne Lin 

> -Original Message-
> From: Lyude Paul 
> Sent: Friday, June 3, 2022 4:18 AM
> To: dri-devel@lists.freedesktop.org
> Cc: David Airlie ; Daniel Vetter ; Thomas
> Zimmermann ; Lin, Wayne
> ; Jani Nikula ; Lakha,
> Bhawanpreet ; Rajkumar Subbiah
> ; open list 
> Subject: [PATCH 1/3] drm/display/dp_mst: Don't validate port refs in
> drm_dp_check_and_send_link_address()
> 
> Drive-by cleanup, we don't need to validate the port references here as we
> already previously went through the effort of refactoring things such that
> we're guaranteed to be able to access ->mstb and ->port safely from
> drm_dp_check_and_send_link_address(), since the only two places in the
> codebase that drop an MST reference in such a way that it would remove it
> from the topology are both protected under probe_lock.
> 
> Thanks for that, past Lyude!
> 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 22 +--
>  1 file changed, 6 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 67b3b9697da7..d84673b3294b 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -2666,24 +2666,14 @@ static int
> drm_dp_check_and_send_link_address(struct drm_dp_mst_topology_mgr
> *mg
>   }
> 
>   list_for_each_entry(port, &mstb->ports, next) {
> - struct drm_dp_mst_branch *mstb_child = NULL;
> -
> - if (port->input || !port->ddps)
> + if (port->input || !port->ddps || !port->mstb)
>   continue;
> 
> - if (port->mstb)
> - mstb_child =
> drm_dp_mst_topology_get_mstb_validated(
> - mgr, port->mstb);
> -
> - if (mstb_child) {
> - ret = drm_dp_check_and_send_link_address(mgr,
> -  mstb_child);
> - drm_dp_mst_topology_put_mstb(mstb_child);
> - if (ret == 1)
> - changed = true;
> - else if (ret < 0)
> - return ret;
> - }
> + ret = drm_dp_check_and_send_link_address(mgr, port-
> >mstb);
> + if (ret == 1)
> + changed = true;
> + else if (ret < 0)
> + return ret;
>   }
> 
>   return changed;
> --
> 2.35.3

--
Regards,
Wayne

RE: [PATCH 3/3] drm/dp_mst: Get rid of old comment in drm_atomic_get_mst_topology_state docs

[Lin, Wayne]

[Public]

Hi Lyude,

Feel free to add
Reviewed-by: Wayne Lin 

> -Original Message-
> From: Lyude Paul 
> Sent: Friday, June 3, 2022 4:18 AM
> To: dri-devel@lists.freedesktop.org
> Cc: David Airlie ; Daniel Vetter ; Thomas
> Zimmermann ; Lin, Wayne
> ; Jani Nikula ; Lakha,
> Bhawanpreet ; Rajkumar Subbiah
> ; open list 
> Subject: [PATCH 3/3] drm/dp_mst: Get rid of old comment in
> drm_atomic_get_mst_topology_state docs
> 
> We don't actually care about connection_mutex here anymore, so let's get
> rid of the comment mentioning it in this function's kdocs.
> 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index d6e595b95f07..9f96132a5d74 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -5458,8 +5458,7 @@
> EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
>   *
>   * This function wraps drm_atomic_get_priv_obj_state() passing in the MST
> atomic
>   * state vtable so that the private object state returned is that of a MST
> - * topology object. Also, drm_atomic_get_private_obj_state() expects the
> caller
> - * to care of the locking, so warn if don't hold the connection_mutex.
> + * topology object.
>   *
>   * RETURNS:
>   *
> --
> 2.35.3

--
Regards,
Wayne Lin

RE: [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not VCPI slots

[Lin, Wayne]

[Public]

Thank you Lyude for addressing this!

VCPI is also a confusing naming to me at first glance since it stands for 
Virtual Channel Payload Identification which is just an ID number ( we can 
 look up these payload IDs In DPCD 0x2C1 ~0x2FF).

I also look up left VCPI terms in rest of the code. Seems like we still can 
modify 
some parts here? Like:

/**
 * struct drm_dp_vcpi - Virtual Channel Payload Identifier
 * @vcpi: Virtual channel ID.
 * @pbn: Payload Bandwidth Number for this channel
 * @aligned_pbn: PBN aligned with slot size
 * @num_slots: number of slots for this PBN
 */
struct drm_dp_vcpi {
int vcpi;
int pbn;
int aligned_pbn;
int num_slots;
};

Would like to change the structure name to  "struct drm_dp_mst_vcp {}" to 
represent
the virtual channel payload. Not specific to the ID.
Would like to know your thoughts : )

> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, June 8, 2022 3:29 AM
> To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Lin, Wayne ; Ville Syrjälä
> ; Zuo, Jerry ; Jani Nikula
> ; Imre Deak ; Daniel Vetter
> ; Sean Paul ; Wentland, Harry
> ; Li, Sun peng (Leo) ;
> Siqueira, Rodrigo ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Jani Nikula
> ; Joonas Lahtinen
> ; Rodrigo Vivi ;
> Tvrtko Ursulin ; Ben Skeggs
> ; Karol Herbst ; Kazlauskas,
> Nicholas ; Li, Roman
> ; Shih, Jude ; Simon Ser
> ; Wu, Hersen ; Thomas
> Zimmermann ; Lakha, Bhawanpreet
> ; José Roberto de Souza
> ; He Ying ; Matt Roper
> ; Sean Paul ; Hans
> Verkuil ; Fernando Ramos ;
> Javier Martinez Canillas ; open list  ker...@vger.kernel.org>; open list:INTEL DRM DRIVERS  g...@lists.freedesktop.org>
> Subject: [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not
> VCPI slots
> 
> VCPI is only sort of the correct term here, originally the majority of this 
> code
> simply referred to timeslots vaguely as "slots" - and since I started working
> on it and adding atomic functionality, the name "VCPI slots" has been used to
> represent time slots.
> 
> Now that we actually have consistent access to the DisplayPort spec thanks to
> VESA, I now know this isn't actually the proper term - as the specification
> refers to these as time slots.
> 
> Since we're trying to make this code as easy to figure out as possible, let's
> take this opportunity to correct this nomenclature and call them by their
> proper name - timeslots. Likewise, we rename various functions
> appropriately, along with replacing references in the kernel documentation
> and various debugging messages.
> 
> It's important to note that this patch series leaves the legacy MST code
> untouched for the most part, which is fine since we'll be removing it soon
> anyhow. There should be no functional changes in this series.
> 
> Signed-off-by: Lyude Paul 
> Cc: Wayne Lin 
> Cc: Ville Syrjälä 
> Cc: Fangzhi Zuo 
> Cc: Jani Nikula 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> Cc: Sean Paul 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   2 +-
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  28 ++---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 106 +-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   5 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |   4 +-
>  include/drm/display/drm_dp_mst_helper.h   |   6 +-
>  6 files changed, 75 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ad4571190a90..f84a4ad736d8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7393,7 +7393,7 @@ static int dm_encoder_helper_atomic_check(struct
> drm_encoder *encoder,
>   clock = adjusted_mode->clock;
>   dm_new_connector_state->pbn =
> drm_dp_calc_pbn_mode(clock, bpp, false);
>   }
> - dm_new_connector_state->vcpi_slots =
> drm_dp_atomic_find_vcpi_slots(state,
> + dm_new_connector_state->vcpi_slots =
> +drm_dp_atomic_find_time_slots(state,
> 
> mst_mgr,
> 
> mst_port,
> 
> dm_new_connector_state->pbn, diff --git
> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 9221b6690a4a..e40ff51e7be0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -378,7 +378,7 @@ static int dm_dp_mst_atomic_check(struct
> drm_conn

RE: [RESEND RFC 06/18] drm/display/dp_mst: Add some missing kdocs for atomic MST structs

[Lin, Wayne]

[Public]



> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, June 8, 2022 3:29 AM
> To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Lin, Wayne ; Ville Syrjälä
> ; Zuo, Jerry ; Jani Nikula
> ; Imre Deak ; Daniel Vetter
> ; Sean Paul ; David Airlie
> ; Daniel Vetter ; Thomas Zimmermann
> ; Deucher, Alexander
> ; Lakha, Bhawanpreet
> ; open list 
> Subject: [RESEND RFC 06/18] drm/display/dp_mst: Add some missing kdocs
> for atomic MST structs
> 
> Since we're about to start adding some stuff here, we may as well fill in any
> missing documentation that we forgot to write.
> 
> Signed-off-by: Lyude Paul 
> Cc: Wayne Lin 
> Cc: Ville Syrjälä 
> Cc: Fangzhi Zuo 
> Cc: Jani Nikula 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> Cc: Sean Paul 
> ---
>  include/drm/display/drm_dp_mst_helper.h | 24
> 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 8ab4f14f2344..eb0ea578b227 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -542,19 +542,43 @@ struct drm_dp_payload {
> 
>  #define to_dp_mst_topology_state(x) container_of(x, struct
> drm_dp_mst_topology_state, base)
> 
> +/**
> + * struct drm_dp_mst_atomic_payload - Atomic state struct for an MST
> +payload
> + *
> + * The primary atomic state structure for a given MST payload. Stores
> +information like current
> + * bandwidth allocation, intended action for this payload, etc.
> + */
>  struct drm_dp_mst_atomic_payload {
> + /** @port: The MST port assigned to this payload */
>   struct drm_dp_mst_port *port;
> + /** @time_slots: The number of timeslots allocated to this payload

Hi Lyude,
Would like to also indicate that the timeslots is allocated from source DP Tx
to immediate downstream DP Rx.

> */
>   int time_slots;
> + /** @pbn: The payload bandwidth for this payload */
>   int pbn;
> + /** @dsc_enabled: Whether or not this payload has DSC enabled */
>   bool dsc_enabled;
> +
> + /** @next: The list node for this payload */
>   struct list_head next;
>  };
> 
> +/**
> + * struct drm_dp_mst_topology_state - DisplayPort MST topology atomic
> +state
> + *
> + * This struct represents the atomic state of the toplevel DisplayPort
> +MST manager  */
>  struct drm_dp_mst_topology_state {
> + /** @base: Base private state for atomic */
>   struct drm_private_state base;
> +
> + /** @payloads: The list of payloads being created/destroyed in this
> +state */
>   struct list_head payloads;
> + /** @mgr: The topology manager */
>   struct drm_dp_mst_topology_mgr *mgr;
> +
> + /** @total_avail_slots: The total number of slots this topology can
> +handle (63 or 64) */
>   u8 total_avail_slots;

I would prefer not using the term "available" which is a bit conflicting with
the idea in the reply of ENUM_PATH_RESOURCES - full PBN & available PBN.
Maybe better to change to use "full_slots"?

Not yet finish all the patches. Will try to go through all the patches recently 
: )

> + /** @start_slot: The first usable time slot in this topology (1 or 0)
> +*/
>   u8 start_slot;
>  };
> 
> --
> 2.35.3

--
Regards,
Wayne Lin

RE: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs

[Lin, Wayne]

[AMD Official Use Only]

Thank you Lyude!

So, in short, I'm trying to register a call back function to listen to unplug 
event within MST topology.

Removal of local monitor from system can be detected by HPD pin and it 
therefore triggers HW interrupt.
We then release corresponding resource for the specific stream sink in sequence.

However, unplug event within MST topology is broadcasted by CSN sideband 
message which is handled by
drm layer in drm_dp_mst_topology.c, not by our driver. In order to follow the 
same sequence as we have
for removal of local monitor, I want to know is there any code path to notify 
driver the unplug event within
MST topology.

Currently, removal of remote monitors by removing its connected mst branch 
device from the topology, such
unplug event eventually call drm_dp_delayed_destroy_port() and we can try to 
release resource for those
stream sinks under this sequence. However, there is no code path for the case 
when remove stream sinks
directly from the topology (i.e. not remove monitors by indirectly removing its 
connected branch device).
As the result, the rough idea that I want to do is adding up a notification for 
this case.

Thank you for your time!

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, February 3, 2022 4:12 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref 
> histories from debugfs
>
> JFYI I should be able to respond to this soon, I think I'm following your
> issue a bit more (haven't gotten to go through the patches too so I'm probably
> going to see if I can reproduce it locally as well. Sorry for the delay -
> dealing with some X.org stuff and work issues at the moment
>
> On Tue, 2022-01-25 at 08:32 +, Lin, Wayne wrote:
> > [Public]
> >
> > Hey Lyude,
> >
> > Sorry, just got chance to get back to this and BIG THANKS to elaborating in
> > such details!
> > Following are some of my comments : )
> >
> > > -Original Message-
> > > From: Lyude Paul 
> > > Sent: Wednesday, January 19, 2022 9:59 AM
> > > To: Lin, Wayne 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref
> > > histories from debugfs
> > >
> > > Hey - so, the original issue here was that payloads were not always
> > > deleted when we expected them to be - correct?
> >
> > Actually, what I was trying to do is not relevant to payload maintenance.
> > What I wanted to do is having a way to notify
> > amdgpu to release its enumerated resource "dc_sink" when unplug event
> > occurs. Currently, under specific scenarios,
> > we can't release remote "dc_sink" and ends up can't allocate resource for
> > new connected monitors. I'll explain the scenario
> > underneath.
> >
> > So, get back to the main issue that I was trying to solve when I pushed the
> > patchset:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-
> devel%2Fcover%2F20210720160342.11415-1-
> Wayne.Lin%40amd.com%2F&data=04%7C01%7Cwayne.lin%40amd.com%7C2e19d9321b5f4e948c1208d9e6884f24%7C3dd8961fe488
> 4e608e11a82d994e183d%7C0%7C0%7C637794295422403301%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rvtwQioO3pT1BoHb7S532msRa61gP1vIyE8AB7M9I4E%3D&reserved=0
> >
> > I was trying to fix some problems that I observed after these 2 patches
> > * 09b974e8983 drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback
> > * 72dc0f51591 drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connector
> >
> > With above patches, it changes our flow to remove dc_sink (by calling
> > dc_link_remote_sink()) when connector is about to be
> > destroyed. And let's see below use cases:
> > a). Disconnection happens between mst branch devices
> > e.g.
> > src - 1st_mstb - 2nd_mstb - sst_monitor => src - 1st_mstb (disconnect)
> > 2nd_mstb - sst_monitor
> >
> > In above case, after receiving CSN, we will put topology reference count of
> > 2nd mstb and its port which connected to the sst monitor.
> > As you suggested before, we will destroy 2nd mst branch device and its all
> > ports due to there is no more mst path can route to them.
> > As the result of that, we at end call drm_dp_delayed_destroy_port() and
> > unregister/put the drm connector and eventually call
> >  dc_link_remote_sink() to release the dc_sinck we enumerate for the specific
> > stream sink of sst_monitor.
> >
> > Howe

RE: [2/2] drm/amd: use fixed dsc bits-per-pixel from edid

[Lin, Wayne]

[Public]

Hi,

Thanks for the patch and it LGTM.
Feel free to add
Reviewed-by: Wayne Lin 

> -Original Message-
> From: Yaroslav Bolyukin 
> Sent: Sunday, February 13, 2022 9:31 PM
> To: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; 
> amd-...@lists.freedesktop.org
> Cc: Thomas Zimmermann ; David Airlie ; 
> Rodrigo Siqueira ; Pan,
> Xinhui ; Leo Li ; Alex Deucher 
> ; Christian K?nig
> ; Yaroslav Bolyukin 
> Subject: [2/2] drm/amd: use fixed dsc bits-per-pixel from edid
>
> VESA vendor header from DisplayID spec may contain fixed bit per pixel rate, 
> it should be respected by drm driver
>
> Signed-off-by: Yaroslav Bolyukin 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 ++
>  drivers/gpu/drm/amd/display/dc/core/dc_stream.c   | 3 ++-
>  drivers/gpu/drm/amd/display/dc/dc_types.h | 3 +++
>  3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 29f07c26d..b34dd89ae 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -118,6 +118,8 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
>
>   edid_caps->edid_hdmi = connector->display_info.is_hdmi;
>
> + edid_caps->dsc_fixed_bits_per_pixel_x16 =
> +connector->display_info.dp_dsc_bpp;
> +
>   sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, &sads);
>   if (sad_count <= 0)
>   return result;
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> index 57cf4cb82..f8516ec70 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> @@ -105,6 +105,8 @@ static bool dc_stream_construct(struct dc_stream_state 
> *stream,
>
>   /* EDID CAP translation for HDMI 2.0 */
>   stream->timing.flags.LTE_340MCSC_SCRAMBLE = 
> dc_sink_data->edid_caps.lte_340mcsc_scramble;
> + stream->timing.dsc_fixed_bits_per_pixel_x16 =
> + dc_sink_data->edid_caps.dsc_fixed_bits_per_pixel_x16;
>
>   memset(&stream->timing.dsc_cfg, 0, sizeof(stream->timing.dsc_cfg));
>   stream->timing.dsc_cfg.num_slices_h = 0; @@ -738,4 +740,3 @@ void 
> dc_stream_log(const struct dc *dc, const struct
> dc_stream_state *stream)
>   "\tlink: %d\n",
>   stream->link->link_index);
>  }
> -
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h 
> b/drivers/gpu/drm/amd/display/dc/dc_types.h
> index 0285a4b38..ce2e11d70 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_types.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
> @@ -227,6 +227,9 @@ struct dc_edid_caps {
>   bool edid_hdmi;
>   bool hdr_supported;
>
> + /* DisplayPort caps */
> + uint32_t dsc_fixed_bits_per_pixel_x16;
> +
>   struct dc_panel_patch panel_patch;
>  };
>
--
Regards,
Wayne Lin

RE: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs

[Lin, Wayne]

[AMD Official Use Only - General]

Thank you Lyude!

I just have a tentative patch set to deal with this. Would like to give a test 
on some platforms first.
If the result is positive, will send out for review immediately.

Thanks for tracking on this : )

Regards,
Wayne Lin

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, April 21, 2022 7:01 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref 
> histories from debugfs
>
> Hey! Figured I'd check if there's been any status updates here since it's been
> a while, just to make sure I haven't dropped this issue from my radar. No
> problem if you're busy :)
>
> On Wed, 2022-03-16 at 10:46 +, Lin, Wayne wrote:
> > [Public]
> >
> > > -Original Message-----
> > > From: Lyude Paul 
> > > Sent: Wednesday, March 16, 2022 8:48 AM
> > > To: Lin, Wayne 
> > > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref
> > > histories from debugfs
> > >
> > > (Adding this back to the dri-devel mailing list since I didn't notice it
> > > got
> > > dropped from there)
> > >
> > > Hm, some comments on this issue down below. Sorry for the delayed
> > > response, I
> > > was going to try this right after I finished the MST legacy removal but
> > > that's
> > > ending up taking longer than I hoped.
> > >
> > > On Tue, 2022-03-08 at 01:46 +, Lin, Wayne wrote:
> > > > [AMD Official Use Only]
> > > >
> > > > Oops...
> > > > I didn't notice that I replied to wrong mail previously : P
> > > > Sorry for the confusion and reply to the correct thread.
> > > >
> > > > Good day!
> > > > I probably know why you can't reproduce the issue there. Please refer to
> > > > the
> > > > attached
> > > > patch file which makes me easier to explain this.
> > > >
> > > > In dm_dp_mst_get_modes(), we will create a new dc_sink by calling
> > > > dc_link_add_remote_sink() and add that dc_sink into the array dc_link-
> > > > > remote_sinks[].
> > > > However, if we find that aconnector->dc_sink is not null, then we won't
> > > > create a new
> > > > dc_sink for that aconnector and won't add the sink to the array dc_link-
> > > > > remote_sinks[].
> > > >
> > > > When the issue that I mentioned before occurs, we won't be able to
> > > > release
> > > > the dc_sink
> > > > for the aconnector when we unplug the sst monitor. Hence, we can't
> > > > create
> > > > new dc_sink
> > > > for the latter on connected new stream sink of that port. Which leads to
> > > > two
> > > > issues
> > > > 1. Unplug monitor and plug in another monitor "to the same port"
> > > > =>  Since we use the same dc_sink to reflect the capability of the new
> > > > connected stream
> > > > sink, we might send out inappropriate stream to the new connected sink.
> > > > 2. Because we can't release dc_sink in the array dc_link-
> > > > >remote_sinks[],
> > > > when we
> > > > plug/unplug sst monitor to more than 4 different mst port, we will break
> > > > the
> > > > criteria
> > > > "dc_link->sink_count >= MAX_SINKS_PER_LINK" in
> > > > link_add_remote_sink_helper().
> > >
> > > Ok, a lot of this seems to be happening in amdgpu which certainly explains
> > > why
> > > I had so much trouble following along with this originally (also, having
> > > learned a bit more about how DC works definitely has helped a bit). I
> > > already
> > > see a bunch of issues though with how this code is structured that would
> > > definitely break things, though note I haven't sat down and tried this on
> > > a
> > > real machine yet - will try tomorrow.
> > >
> > > So - it seems like dc_sink == a bunch of hotplugging state for a dm
> > > connector,
> > > which actually tells me for one that this is definitely the wrong spot for
> > > this code. get_modes() really should just handle filling out DRM modes and
> > > pretty much nothing else, because callers from DRM are

Re: [PATCH] drm/dp_mst: Lower down debug info level when receive NAK

[Lin, Wayne]

[Public]

Thank you Lyude!

Regards,
Wayne

From: Lyude Paul 
Sent: Friday, April 29, 2022 00:45
To: Lin, Wayne; dri-devel@lists.freedesktop.org
Cc: ville.syrj...@linux.intel.com; Wentland, Harry; Zuo, Jerry; Siqueira, 
Rodrigo
Subject: Re: [PATCH] drm/dp_mst: Lower down debug info level when receive NAK

Reviewed-by: Lyude Paul 

Will push to drm-misc-next in a bit

On Thu, 2022-04-28 at 20:49 +0800, Wayne Lin wrote:
> [Why]
> It's reasonable that we receive NAK while doing DP_REMOTE_DPCD_READ.
> Downstream device might reply NAK with the reason and source should
> react accordingly.
>
> e.g.
> 1. When downstream device can't handle corresponding message in time,
> it then replies NAK as reason been set as DEFER.
> 2. When multi-function branch-sink device doesn't enumerate virtual
> DP peer devices for those multi-function down facing ports. Without
> virtual DPCD, branch device might reply NAK with reason as BAD_PARAM
> indicating this port can't do aux DPCD read.
>
> It's expected result. Not an error.
>
> [How]
> Use drm_dbg_kms() to replace drm_err() when receive NAK.
>
> Changes since v1:
> * drm_dp_mst_topology.c file path changed. Folder was rename from
>  'dp' to 'display'
>
> Signed-off-by: Wayne Lin 
> Reviewed-by: Harry Wentland 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 8526aae75c6d..f27aa0b95bea 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3557,9 +3557,8 @@ static int drm_dp_send_dpcd_read(struct
> drm_dp_mst_topology_mgr *mgr,
> if (ret < 0)
> goto fail_free;
>
> -   /* DPCD read should never be NACKed */
> if (txmsg->reply.reply_type == 1) {
> -   drm_err(mgr->dev, "mstb %p port %d: DPCD read on addr 0x%x
> for %d bytes NAKed\n",
> +   drm_dbg_kms(mgr->dev, "mstb %p port %d: DPCD read on addr
> 0x%x for %d bytes NAKed\n",
> mstb, port->port_num, offset, size);
> ret = -EIO;
> goto fail_free;

--
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

RE: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs

[Lin, Wayne]

[Public]

Hi Lyude,

Just a heads-up that I should be able to push my patch set out for code review
next week. Thanks for your kind help all the time!

Regards,
Wayne

> -Original Message-
> From: Lin, Wayne
> Sent: Monday, April 25, 2022 1:02 PM
> To: Lyude Paul 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Subject: RE: [PATCH] WIP: drm/dp_mst: Add support for dumping topology
> ref histories from debugfs
> 
> Thank you Lyude!
> 
> I just have a tentative patch set to deal with this. Would like to give a 
> test on
> some platforms first.
> If the result is positive, will send out for review immediately.
> 
> Thanks for tracking on this : )
> 
> Regards,
> Wayne Lin
> 
> > -Original Message-
> > From: Lyude Paul 
> > Sent: Thursday, April 21, 2022 7:01 AM
> > To: Lin, Wayne 
> > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology
> ref histories from debugfs
> >
> > Hey! Figured I'd check if there's been any status updates here since it's
> been
> > a while, just to make sure I haven't dropped this issue from my radar. No
> > problem if you're busy :)
> >
> > On Wed, 2022-03-16 at 10:46 +0000, Lin, Wayne wrote:
> > > [Public]
> > >
> > > > -Original Message-
> > > > From: Lyude Paul 
> > > > Sent: Wednesday, March 16, 2022 8:48 AM
> > > > To: Lin, Wayne 
> > > > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > > > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping
> topology ref
> > > > histories from debugfs
> > > >
> > > > (Adding this back to the dri-devel mailing list since I didn't notice it
> > > > got
> > > > dropped from there)
> > > >
> > > > Hm, some comments on this issue down below. Sorry for the delayed
> > > > response, I
> > > > was going to try this right after I finished the MST legacy removal but
> > > > that's
> > > > ending up taking longer than I hoped.
> > > >
> > > > On Tue, 2022-03-08 at 01:46 +, Lin, Wayne wrote:
> > > > > [AMD Official Use Only]
> > > > >
> > > > > Oops...
> > > > > I didn't notice that I replied to wrong mail previously : P
> > > > > Sorry for the confusion and reply to the correct thread.
> > > > >
> > > > > Good day!
> > > > > I probably know why you can't reproduce the issue there. Please
> refer to
> > > > > the
> > > > > attached
> > > > > patch file which makes me easier to explain this.
> > > > >
> > > > > In dm_dp_mst_get_modes(), we will create a new dc_sink by calling
> > > > > dc_link_add_remote_sink() and add that dc_sink into the array
> dc_link-
> > > > > > remote_sinks[].
> > > > > However, if we find that aconnector->dc_sink is not null, then we
> won't
> > > > > create a new
> > > > > dc_sink for that aconnector and won't add the sink to the array
> dc_link-
> > > > > > remote_sinks[].
> > > > >
> > > > > When the issue that I mentioned before occurs, we won't be able to
> > > > > release
> > > > > the dc_sink
> > > > > for the aconnector when we unplug the sst monitor. Hence, we can't
> > > > > create
> > > > > new dc_sink
> > > > > for the latter on connected new stream sink of that port. Which leads
> to
> > > > > two
> > > > > issues
> > > > > 1. Unplug monitor and plug in another monitor "to the same port"
> > > > > =>  Since we use the same dc_sink to reflect the capability of the new
> > > > > connected stream
> > > > > sink, we might send out inappropriate stream to the new connected
> sink.
> > > > > 2. Because we can't release dc_sink in the array dc_link-
> > > > > >remote_sinks[],
> > > > > when we
> > > > > plug/unplug sst monitor to more than 4 different mst port, we will
> break
> > > > > the
> > > > > criteria
> > > > > "dc_link->sink_count >= MAX_SINKS_PER_LINK" in
> > > > > link_add_remote_sink_helper().
> > > >
> > &g

RE: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into the atomic state

[Lin, Wayne]

[Public]



> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, August 4, 2022 4:28 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Ville Syrjälä ; Zuo, Jerry
> ; Jani Nikula ; Imre Deak
> ; Daniel Vetter ; Sean Paul
> ; Wentland, Harry ; Li, Sun
> peng (Leo) ; Siqueira, Rodrigo
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Jani Nikula
> ; Joonas Lahtinen
> ; Rodrigo Vivi ;
> Tvrtko Ursulin ; Ben Skeggs
> ; Karol Herbst ; Kazlauskas,
> Nicholas ; Li, Roman
> ; Shih, Jude ; Simon Ser
> ; Lakha, Bhawanpreet
> ; Mikita Lipski ;
> Claudio Suarez ; Chen, Ian ; Colin Ian
> King ; Wu, Hersen ; Liu,
> Wenjing ; Lei, Jun ; Strauss,
> Michael ; Ma, Leo ;
> Thomas Zimmermann ; José Roberto de Souza
> ; He Ying ; Anshuman
> Gupta ; Andi Shyti
> ; Ashutosh Dixit ;
> Juston Li ; Sean Paul ;
> Fernando Ramos ; Luo Jiaxing
> ; Javier Martinez Canillas ;
> open list ; open list:INTEL DRM DRIVERS
> 
> Subject: Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info
> into the atomic state
> 
> On Tue, 2022-07-05 at 09:10 +, Lin, Wayne wrote:
> > > +struct drm_dp_mst_port;
> > > +
> > >   /* DP MST stream allocation (payload bandwidth number) */
> > >   struct dc_dp_mst_stream_allocation {
> > >    uint8_t vcp_id;
> > >    /* number of slots required for the DP stream in
> > >    * transport packet */
> > >    uint8_t slot_count;
> > > + /* The MST port this is on, this is used to associate DC MST
> > > + payloads
> > > with their
> > > + * respective DRM payloads allocations, and can be ignored on non-
> > > Linux.
> > > + */
> >
> > Is it necessary for adding this new member? Since this is for setting
> > the DC HW and not relating to drm.
> 
> I don't entirely know, honestly. The reasons I did it:
> 
>  * Mapping things from DRM to DC and from DC to DRM is really confusing for
>outside contributors like myself, so it wasn't even really clear to me if
>there was another way to reconstruct the DRM context from the spots
> where
>we call from DC up to DM (not a typo, see next point).
>  * These DC structs for MST are already layer mixing as far as I can tell,
>just not in an immediately obvious way. While this struct itself is for DC,
>there's multiple spots where we pass the DC payload structs down from
> DM to
>DC, then pass them back up from DC to DM and have to figure out how to
>reconstruct the DRM context that we actually need to use the MST helpers
>from that. So, that kind of further complicates the confusion of where
>layers should be separated.
>  * As far as I'm aware with C there shouldn't be any issue with adding a
>pointer to a struct whose contents are undefined. IMHO, this is also
>preferable to just using void* because then at least you get some hint as
>to the actual type of the data and avoid the possibility of casting it to
>the wrong type. So tl;dr, on any platform even outside of Linux with a
>reasonably compliant compiler this should still build just fine. It'll even
>give you the added bonus of warning people if they try to access the
>contents of this member in DC on non-Linux platforms. If void* is preferred
>though I'm fine with switching it to that.
> 
> --
> Cheers, Lyude Paul (she/her) Software Engineer at Red Hat

Hi Lyude,

Thanks for your time!
I was thinking that our DC just mainly takes care of HW related programming. 
Struct dc_dp_mst_stream_allocation is only used to construct a copy of the 
virtual 
channel payload ID and slots count of payload allocation table determined by
dm/drm. ID and slots are only things required for programming HW registers.
I think there shouldn't be any spots to try to construct the DRM context from
this dc struct since there is no such concept in HW level. Our HW should only 
take care of local DP link and it doesn't have overall topology info.

Thanks!

Regards,
Wayne

RE: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected

[Lin, Wayne]

[Public]



> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, August 3, 2022 6:12 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Ville Syrjälä ; Zuo, Jerry
> ; Jani Nikula ; Imre Deak
> ; Daniel Vetter ; Sean Paul
> ; David Airlie ; Daniel Vetter
> ; Thomas Zimmermann ; Lakha,
> Bhawanpreet ; open list  ker...@vger.kernel.org>
> Subject: Re: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing
> payloads if last connected port isn't connected
> 
> On Tue, 2022-07-05 at 08:45 +, Lin, Wayne wrote:
> > [Public]
> >
> >
> >
> > > -Original Message-
> > > From: Lyude Paul 
> > > Sent: Wednesday, June 8, 2022 3:30 AM
> > > To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org;
> > > amd- g...@lists.freedesktop.org
> > > Cc: Lin, Wayne ; Ville Syrjälä
> > > ; Zuo, Jerry ;
> > > Jani Nikula ; Imre Deak
> > > ; Daniel Vetter ; Sean
> > > Paul ; David Airlie ; Daniel
> > > Vetter ; Thomas Zimmermann
> ;
> > > Lakha, Bhawanpreet ; open list
> > > 
> > > Subject: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing
> > > payloads if last connected port isn't connected
> > >
> > > In the past, we've ran into strange issues regarding errors in
> > > response to trying to destroy payloads after a port has been
> > > unplugged. We fixed this back in:
> > >
> > > This is intended to replace the workaround that was added here:
> > >
> > > commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > > ports in stale topology")
> > >
> > > which was intended fix to some of the payload leaks that were
> > > observed before, where we would attempt to determine if the port was
> > > still connected to the topology before updating payloads using
> > > drm_dp_mst_port_downstream_of_branch. This wasn't a particularly
> > > good solution, since one of the points of still having port and mstb
> > > validation is to avoid sending messages to newly disconnected
> > > branches wherever possible
> > > - thus the required use of drm_dp_mst_port_downstream_of_branch
> > > would indicate something may be wrong with said validation.
> > >
> > > It seems like it may have just been races and luck that made
> > > drm_dp_mst_port_downstream_of_branch work however, as while I
> was
> > > trying to figure out the true cause of this issue when removing the
> > > legacy MST code - I discovered an important excerpt in section
> > > 2.14.2.3.3.6 of the DP
> > > 2.0
> > > specs:
> > >
> > > "BAD_PARAM - This reply is transmitted when a Message Transaction
> > > parameter is in error; for example, the next port number is invalid
> > > or /no device is connected/ to the port associated with the port number."
> > >
> > > Sure enough - removing the calls to
> > > drm_dp_mst_port_downstream_of_branch()
> > > and instead checking the ->ddps field of the parent port to see
> > > whether we should release a given payload or not seems to totally
> > > fix the issue. This does actually make sense to me, as it seems the
> > > implication is that given a topology where an MSTB is removed, the
> > > payload for the MST parent's port will be released automatically if
> > > that port is also marked as disconnected.
> > > However, if there's another parent in the chain after that which is
> > > connected
> > > - payloads must be released there with an ALLOCATE_PAYLOAD message.
> > >
> > > So, let's do that!
> > >
> > > Signed-off-by: Lyude Paul 
> > > Cc: Wayne Lin 
> > > Cc: Ville Syrjälä 
> > > Cc: Fangzhi Zuo 
> > > Cc: Jani Nikula 
> > > Cc: Imre Deak 
> > > Cc: Daniel Vetter 
> > > Cc: Sean Paul 
> > > ---
> > >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 51
> > > +++
> > >  1 file changed, 17 insertions(+), 34 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > index dd314586bac3..70adb8db4335 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > @@ -3137,7 +3137,7 @@ static struct drm_dp_mst_port
&

RE: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected

[Lin, Wayne]

[Public]



> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, June 8, 2022 3:30 AM
> To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Lin, Wayne ; Ville Syrjälä
> ; Zuo, Jerry ; Jani Nikula
> ; Imre Deak ; Daniel Vetter
> ; Sean Paul ; David Airlie
> ; Daniel Vetter ; Thomas Zimmermann
> ; Lakha, Bhawanpreet
> ; open list 
> Subject: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if
> last connected port isn't connected
> 
> In the past, we've ran into strange issues regarding errors in response to
> trying to destroy payloads after a port has been unplugged. We fixed this
> back in:
> 
> This is intended to replace the workaround that was added here:
> 
> commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> ports in stale topology")
> 
> which was intended fix to some of the payload leaks that were observed
> before, where we would attempt to determine if the port was still
> connected to the topology before updating payloads using
> drm_dp_mst_port_downstream_of_branch. This wasn't a particularly good
> solution, since one of the points of still having port and mstb validation is 
> to
> avoid sending messages to newly disconnected branches wherever possible
> - thus the required use of drm_dp_mst_port_downstream_of_branch
> would indicate something may be wrong with said validation.
> 
> It seems like it may have just been races and luck that made
> drm_dp_mst_port_downstream_of_branch work however, as while I was
> trying to figure out the true cause of this issue when removing the legacy
> MST code - I discovered an important excerpt in section 2.14.2.3.3.6 of the DP
> 2.0
> specs:
> 
> "BAD_PARAM - This reply is transmitted when a Message Transaction
> parameter is in error; for example, the next port number is invalid or /no
> device is connected/ to the port associated with the port number."
> 
> Sure enough - removing the calls to
> drm_dp_mst_port_downstream_of_branch()
> and instead checking the ->ddps field of the parent port to see whether we
> should release a given payload or not seems to totally fix the issue. This 
> does
> actually make sense to me, as it seems the implication is that given a
> topology where an MSTB is removed, the payload for the MST parent's port
> will be released automatically if that port is also marked as disconnected.
> However, if there's another parent in the chain after that which is connected
> - payloads must be released there with an ALLOCATE_PAYLOAD message.
> 
> So, let's do that!
> 
> Signed-off-by: Lyude Paul 
> Cc: Wayne Lin 
> Cc: Ville Syrjälä 
> Cc: Fangzhi Zuo 
> Cc: Jani Nikula 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> Cc: Sean Paul 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 51 +++
>  1 file changed, 17 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index dd314586bac3..70adb8db4335 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3137,7 +3137,7 @@ static struct drm_dp_mst_port
> *drm_dp_get_last_connected_port_to_mstb(struct drm  static struct
> drm_dp_mst_branch *  drm_dp_get_last_connected_port_and_mstb(struct
> drm_dp_mst_topology_mgr *mgr,
>   struct drm_dp_mst_branch *mstb,
> - int *port_num)
> + struct drm_dp_mst_port **last_port)
>  {
>   struct drm_dp_mst_branch *rmstb = NULL;
>   struct drm_dp_mst_port *found_port;
> @@ -3153,7 +3153,8 @@
> drm_dp_get_last_connected_port_and_mstb(struct
> drm_dp_mst_topology_mgr *mgr,
> 
>   if (drm_dp_mst_topology_try_get_mstb(found_port-
> >parent)) {
>   rmstb = found_port->parent;
> - *port_num = found_port->port_num;
> + *last_port = found_port;
> + drm_dp_mst_get_port_malloc(found_port);
>   } else {
>   /* Search again, starting from this parent */
>   mstb = found_port->parent;
> @@ -3170,7 +3171,7 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
>  int pbn)
>  {
>   struct drm_dp_sideband_msg_tx *txmsg;
> - struct drm_dp_mst_branch *mstb;
> + struct drm_dp_mst_branch *mstb = NULL;
>   int ret, port_num;
>   u8 sinks[DRM_DP_MAX_SDP_STREAMS];
> 

RE: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into the atomic state

[Lin, Wayne]

[Public]



> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, June 8, 2022 3:30 AM
> To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Lin, Wayne ; Ville Syrjälä
> ; Zuo, Jerry ; Jani Nikula
> ; Imre Deak ; Daniel Vetter
> ; Sean Paul ; Wentland, Harry
> ; Li, Sun peng (Leo) ;
> Siqueira, Rodrigo ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Jani Nikula
> ; Joonas Lahtinen
> ; Rodrigo Vivi ;
> Tvrtko Ursulin ; Ben Skeggs
> ; Karol Herbst ; Kazlauskas,
> Nicholas ; Li, Roman
> ; Shih, Jude ; Simon Ser
> ; Lakha, Bhawanpreet
> ; Mikita Lipski ;
> Claudio Suarez ; Chen, Ian ; Colin Ian
> King ; Wu, Hersen ; Liu,
> Wenjing ; Lei, Jun ; Strauss,
> Michael ; Ma, Leo ;
> Thomas Zimmermann ; José Roberto de Souza
> ; He Ying ; Anshuman
> Gupta ; Andi Shyti
> ; Ashutosh Dixit ;
> Juston Li ; Sean Paul ;
> Fernando Ramos ; Luo Jiaxing
> ; Javier Martinez Canillas ;
> open list ; open list:INTEL DRM DRIVERS
> 
> Subject: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into
> the atomic state
> 
> Now that we've finally gotten rid of the non-atomic MST users leftover in
> the kernel, we can finally get rid of all of the legacy payload code we
> have and move as much as possible into the MST atomic state structs. The
> main purpose of this is to make the MST code a lot less confusing to work
> on, as there's a lot of duplicated logic that doesn't really need to be
> here. As well, this should make introducing features like fallback link
> retraining and DSC support far easier.
> 
> Since the old payload code was pretty gnarly and there's a Lot of changes
> here, I expect this might be a bit difficult to review. So to make things
> as easy as possible for reviewers, I'll sum up how both the old and new
> code worked here (it took me a while to figure this out too!).
> 
> The old MST code basically worked by maintaining two different payload
> tables - proposed_vcpis, and payloads. proposed_vcpis would hold the
> modified payload we wanted to push to the topology, while payloads held
> the
> payload table that was currently programmed in hardware. Modifications to
> proposed_vcpis would be handled through drm_dp_allocate_vcpi(),
> drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then,
> they
> would be pushed via drm_dp_mst_update_payload_step1() and
> drm_dp_mst_update_payload_step2().
> 
> Furthermore, it's important to note how adding and removing VC payloads
> actually worked with drm_dp_mst_update_payload_step1(). When a VC
> payload
> is removed from the VC table, all VC payloads which come after the removed
> VC payload's slots must have their time slots shifted towards the start of
> the table. The old code handles this by looping through the entire payload
> table and recomputing the start slot for every payload in the topology from
> scratch. While very much overkill, this ends up doing the right thing
> because we always order the VCPIs for payloads from first to last starting
> timeslot.
> 
> It's important to also note that drm_dp_mst_update_payload_step2() isn't
> actually limited to updating a single payload - the driver can use it to
> queue up multiple payload changes so that as many of them can be sent as
> possible before waiting for the ACT.

Hi Lyude,

I have concern for updating payload table multiple times for multiple payload
changes before sending the ACT. Also consult with one branch vendor, they 
say their fw will expect receiving one ALLOCATE_PAYLOAD after setting DPCD
002c0h bit 0 (VC payload ID table updated).

Thanks!
> 
> drm_dp_mst_update_payload_step2() is pretty self explanatory and
> basically
> the same between the old and new code, save for the fact we don't have a
> second step for deleting payloads anymore -and thus rename it to
> drm_dp_mst_add_payload_step2().
> 
> The new payload code stores all of the current payload info within the MST
> atomic state and computes as much of the state as possible ahead of time.
> This has the one exception of the starting timeslots for payloads, which
> can't be determined at atomic check time since the starting time slots will
> vary depending on what order CRTCs are enabled in the atomic state - which
> varies from driver to driver. These are still stored in the atomic MST
> state, but are only copied from the old MST state during atomic commit
> time. Likewise, this is when new start slots are determined.
> 
> Adding/removing payloads now works much more closely to how things are
> described in the spec. When we delete a payload, we loop through the
> 

RE: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)

[Lin, Wayne]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Saturday, October 26, 2019 3:20 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
> 
> On Mon, Oct 21, 2019 at 06:28:18AM +, Lin, Wayne wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Monday, October 14, 2019 10:42 PM
> > > To: Lin, Wayne 
> > > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> > > Subject: Re: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio
> > > (WIP)
> > >
> > > On Mon, Oct 14, 2019 at 09:27:07AM +, Lin, Wayne wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ville Syrjala 
> > > > > Sent: Friday, October 4, 2019 10:19 PM
> > > > > To: dri-devel@lists.freedesktop.org
> > > > > Cc: intel-...@lists.freedesktop.org; Lin, Wayne
> > > > > 
> > > > > Subject: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio
> > > > > (WIP)
> > > > >
> > > > > From: Ville Syrjälä 
> > > > >
> > > > > I think this should provide most of necessary logic for adding
> > > > > aspecr ratios to the HDMI 4k modes.
> > > > >
> > > > > Cc: Wayne Lin 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_edid.c | 37
> > > > > +++--
> > > > >  1 file changed, 31 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_edid.c
> > > > > b/drivers/gpu/drm/drm_edid.c index
> > > > > c7f9f7ca75a2..c76814edc784 100644
> > > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > > @@ -3210,6 +3210,11 @@ static enum hdmi_picture_aspect
> > > > > drm_get_cea_aspect_ratio(const u8 video_code)
> > > > >   return edid_cea_modes[video_code].picture_aspect_ratio;
> > > > >  }
> > > > >
> > > > > +static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const
> > > > > +u8
> > > > > +video_code) {
> > > > > + return edid_4k_modes[video_code].picture_aspect_ratio;
> > > > > +}
> > > > > +
> > > >
> > > > There are no picture_aspect_ratio attributes defined for modes in
> > > > edid_4k_modes[] now. Should add on those definitions.
> > > >
> > > > >  /*
> > > > >   * Calculate the alternate clock for HDMI modes (those from the
> > > > > HDMI vendor
> > > > >   * specific block).
> > > > > @@ -3236,6 +3241,9 @@ static u8
> > > > > drm_match_hdmi_mode_clock_tolerance(const struct
> > > > > drm_display_mode
> > > *to_
> > > > >   if (!to_match->clock)
> > > > >   return 0;
> > > > >
> > > > > + if (to_match->picture_aspect_ratio)
> > > > > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > > > > +
> > > > >   for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> > > > >   const struct drm_display_mode *hdmi_mode =
> > > &edid_4k_modes[vic];
> > > > >   unsigned int clock1, clock2;
> > > > > @@ -3271,6 +3279,9 @@ static u8 drm_match_hdmi_mode(const
> struct
> > > > > drm_display_mode *to_match)
> > > > >   if (!to_match->clock)
> > > > >   return 0;
> > > > >
> > > > > + if (to_match->picture_aspect_ratio)
> > > > > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > > > > +
> > > > >   for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> > > > >   const struct drm_display_mode *hdmi_mode =
> > > &edid_4k_modes[vic];
> > > > >   unsigned int clock1, clock2;
> > > >
> > > > Current code in drm_match_hdmi_mdoe() &
> > > > drm_match_hdmi_mode_clock_tolerance()
> > > > use hdmi_mode_alternate_clock() to find alternate clocks.
> > > > In hdmi_mode_alternate_clock()

Re: [PATCH] drm/dp_mst: clear time slots for ports invalid

[Lin, Wayne]

[AMD Official Use Only - Internal Distribution Only]

Pinged.
Hi, can someone help to review please.

Thanks a lot.

Regards,
Wayne


From: Wayne Lin 
Sent: Friday, December 6, 2019 16:39
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Kazlauskas, Nicholas; Wentland, Harry; Zuo, Jerry; ly...@redhat.com; 
sta...@vger.kernel.org; Lin, Wayne
Subject: [PATCH] drm/dp_mst: clear time slots for ports invalid

[Why]
When change the connection status in a MST topology, mst device
which detect the event will send out CONNECTION_STATUS_NOTIFY messgae.

e.g. src-mst-mst-sst => src-mst (unplug) mst-sst

Currently, under the above case of unplugging device, ports which have
been allocated payloads and are no longer in the topology still occupy
time slots and recorded in proposed_vcpi[] of topology manager.

If we don't clean up the proposed_vcpi[], when code flow goes to try to
update payload table by calling drm_dp_update_payload_part1(), we will
fail at checking port validation due to there are ports with proposed
time slots but no longer in the mst topology. As the result of that, we
will also stop updating the DPCD payload table of down stream port.

[How]
While handling the CONNECTION_STATUS_NOTIFY message, add a detection to
see if the event indicates that a device is unplugged to an output port.
If the detection is true, then iterrate over all proposed_vcpi[] to
see whether a port of the proposed_vcpi[] is still in the topology or
not. If the port is invalid, set its num_slots to 0.

Thereafter, when try to update payload table by calling
drm_dp_update_payload_part1(), we can successfully update the DPCD
payload table of down stream port and clear the proposed_vcpi[] to NULL.

Signed-off-by: Wayne Lin 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5306c47dc820..2e236b6275c4 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2318,7 +2318,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch 
*mstb,
 {
struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
struct drm_dp_mst_port *port;
-   int old_ddps, ret;
+   int old_ddps, old_input, ret, i;
u8 new_pdt;
bool dowork = false, create_connector = false;

@@ -2349,6 +2349,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch 
*mstb,
}

old_ddps = port->ddps;
+   old_input = port->input;
port->input = conn_stat->input_port;
port->mcs = conn_stat->message_capability_status;
port->ldps = conn_stat->legacy_device_plug_status;
@@ -2373,6 +2374,27 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch 
*mstb,
dowork = false;
}

+   if (!old_input && old_ddps != port->ddps && !port->ddps) {
+   for (i = 0; i < mgr->max_payloads; i++) {
+   struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
+   struct drm_dp_mst_port *port_validated;
+
+   if (vcpi) {
+   port_validated =
+   container_of(vcpi, struct 
drm_dp_mst_port, vcpi);
+   port_validated =
+   
drm_dp_mst_topology_get_port_validated(mgr, port_validated);
+   if (!port_validated) {
+   mutex_lock(&mgr->payload_lock);
+   vcpi->num_slots = 0;
+   mutex_unlock(&mgr->payload_lock);
+   } else {
+   
drm_dp_mst_topology_put_port(port_validated);
+   }
+   }
+   }
+   }
+
if (port->connector)
drm_modeset_unlock(&mgr->base.lock);
else if (create_connector)
--
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/dp_mst: clear time slots for ports invalid

[Lin, Wayne]

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, December 21, 2019 8:12 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/dp_mst: clear time slots for ports invalid
> 
> Mhh-I think I understand the problem you're trying to solve here but I think 
> this
> solution might be a bit overkill. When I did the rework of topology references
> for ports, I made it so that we can guarantee memory access to a port without
> it needing to be a valid part of the topology. As well, all parents of the 
> port are
> guaranteed to be accessible for as long as the child is. Take a look at:
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F01.org%
> 2Flinuxgraphics%2Fgfx-docs%2Fdrm%2Fgpu%2Fdrm-kms-helpers.html%23refco
> unt-relationships-in-a-topology&data=02%7C01%7Cwayne.lin%40amd.co
> m%7C722655b546c049dc081908d785aa6758%7C3dd8961fe4884e608e11a82d
> 994e183d%7C0%7C0%7C637124839257213115&sdata=Ctha3ja8kleeFOp
> PpA7EwDV1is81RAMsjqd1P6463ak%3D&reserved=0
> 
> It's also worth noting that because of this there's a lot of
> get_port_validated()/put_port_validated() calls in the MST helpers that are
> now bogus and need to be removed once I get a chance. For new code we
> should limit the use of topology references to sections of code where we need
> a guarantee that resources on the port/branch (such as a drm connector, dp
> aux port, etc.) won't go away for as long as we need to use them.
> 
> Do you think we could change this patch so instead of removing it from the
> proposed payloads on the CONNECTION_STATUS_NOTIFY, we keep the port's
> memory allocation around until it's been removed from the proposed payloads
> table and clean it up there on the next payload update?
> 
Really appreciate for your time and comments in detail.

In this patch, I wanted to just set the proposed_vcpi->num_slots to 0 for those
ports which are no longer in the topology due to there is no need to allocate 
time
slots for these port. And expect those vcpi will be updated during next update 
of 
payload ID table by drm_dp_update_payload_part1(). 

I tried to use drm_dp_mst_topology_get_port_validated() as a helper to 
decide whether a port is in the topology or not. Use this function to iterate 
over
all ports that all proposed_vcpi[] drive to. If one port is not in the 
topology, set the
num_slots of the proposed_vcpi for this port to 0. With num_slots as 0, these 
proposed_vcpi will be clean up in next payload table update by 
drm_dp_update_payload_part1(). If a port is still in the topology, then release
the reference count which was acquired previously from
drm_dp_mst_topology_get_port_validated() and do nothing.

I didn't mean to kill invalid ports on receiving CONNECTION_STATUS_NOTIFY.
Sorry if I misuse or misunderstand something here?

> On Fri, 2019-12-06 at 16:39 +0800, Wayne Lin wrote:
> > [Why]
> > When change the connection status in a MST topology, mst device which
> > detect the event will send out CONNECTION_STATUS_NOTIFY messgae.
> >
> > e.g. src-mst-mst-sst => src-mst (unplug) mst-sst
> >
> > Currently, under the above case of unplugging device, ports which have
> > been allocated payloads and are no longer in the topology still occupy
> > time slots and recorded in proposed_vcpi[] of topology manager.
> >
> > If we don't clean up the proposed_vcpi[], when code flow goes to try
> > to update payload table by calling drm_dp_update_payload_part1(), we
> > will fail at checking port validation due to there are ports with
> > proposed time slots but no longer in the mst topology. As the result
> > of that, we will also stop updating the DPCD payload table of down stream
> port.
> >
> > [How]
> > While handling the CONNECTION_STATUS_NOTIFY message, add a detection
> > to see if the event indicates that a device is unplugged to an output port.
> > If the detection is true, then iterrate over all proposed_vcpi[] to
> > see whether a port of the proposed_vcpi[] is still in the topology or
> > not. If the port is invalid, set its num_slots to 0.
> >
> > Thereafter, when try to update payload table by calling
> > drm_dp_update_payload_part1(), we can successfully update the DPCD
> > payload table of down stream port and clear the proposed_vcpi[] to NULL.
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 24
> +++-
> >  1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/driv

Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

[Lin, Wayne]

[AMD Official Use Only - Internal Distribution Only]

> 
> From: Jani Nikula 
> Sent: Monday, December 30, 2019 19:15
> To: Lin, Wayne; dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Zuo, Jerry; Kazlauskas, Nicholas; Lin, Wayne
> Subject: Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
>
> On Mon, 30 Dec 2019, Wayne Lin  wrote:
> > [Why]
> > According to DP spec, it should shift left 4 digits for NO_STOP_BIT
> > in REMOTE_I2C_READ message. Not 5 digits.
> >
> > [How]
> > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
> > drm_dp_encode_sideband_req().
>
> Which commit introduced the issue? Fixes: tag. Does it need a stable
> backport? Does this fix a user visible bug?
>
> BR,
> Jani.
>
Thanks for your time and reminder.

It seems like the issue has been there since very beginning.(commit: ad7f8a1).
It doesn't introduce user visible bug under my test cases, but this affects the 
I2C signal
between I2C master and I2C slave. Not pretty sure if there is any eeprom will 
reset
the written offset once received I2C stop. If so, that might cause wrongly 
reading EDID.
I will Cc to stable. Thanks.
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 1d1bfa49ca2b..0557e225ff67 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct 
> > drm_dp_sideband_msg_req_body *req,
> >   memcpy(&buf[idx], 
> > req->u.i2c_read.transactions[i].bytes, 
> > req->u.i2c_read.transactions[i].num_bytes);
> >   idx += req->u.i2c_read.transactions[i].num_bytes;
> >
> > - buf[idx] = 
> > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5;
> > + buf[idx] = 
> > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
> >   buf[idx] |= 
> > (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
> >   idx++;
> >   }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

[Lin, Wayne]

[AMD Official Use Only - Internal Distribution Only]

> 
> From: Wentland, Harry 
> Sent: Monday, December 30, 2019 23:26
> To: Lin, Wayne; dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: ly...@redhat.com; Zuo, Jerry; Kazlauskas, Nicholas; Wentland, Harry
> Subject: Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
>
> On 2019-12-30 2:05 a.m., Wayne Lin wrote:
> > [Why]
> > According to DP spec, it should shift left 4 digits for NO_STOP_BIT
> > in REMOTE_I2C_READ message. Not 5 digits.
> >
> > [How]
> > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
> > drm_dp_encode_sideband_req().
> >
> > Signed-off-by: Wayne Lin 
>
> Good catch. Looks like this has been there since the beginning of MST in
> the kernel. How did you find this? Did this cause bad EDID reads or some
> other problem? If so the commit message should probably mention it.
>
> Harry
Thanks for your time.

I found this while I was trying to debug MST issues by using AUX monitor.
So far, I don't observe problems that relate to this under my test cases and 
environment.
However, this bit might affect the I2C signal generated by I2C master, I will 
mention more
in the commit message.

Thanks.
>
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 1d1bfa49ca2b..0557e225ff67 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct 
> > drm_dp_sideband_msg_req_body *req,
> >   memcpy(&buf[idx], 
> > req->u.i2c_read.transactions[i].bytes, 
> > req->u.i2c_read.transactions[i].num_bytes);
> >   idx += req->u.i2c_read.transactions[i].num_bytes;
> >
> > - buf[idx] = 
> > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5;
> > + buf[idx] = 
> > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
> >   buf[idx] |= 
> > (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
> >   idx++;
> >   }
> >
--
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

回覆: [PATCH] drm/dp_mst: Avoid NULL pointer dereference

[Lin, Wayne]

[AMD Public Use]



> -原始郵件-
> 寄件者: Lyude Paul 
> 寄件日期: Saturday, January 4, 2020 4:35 AM
> 收件者: Lin, Wayne ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> 副本: Kazlauskas, Nicholas ; Wentland,
> Harry ; Lipski, Mikita ;
> Zuo, Jerry ; sta...@vger.kernel.org
> 主旨: Re: [PATCH] drm/dp_mst: Avoid NULL pointer dereference
> 
> Back from the holidays!
> 
> Reviewed-by: Lyude Paul 
> 
> Do you need me to push this to drm-misc?
> 
Thanks for your time!
And yes, please help to push this to drm-misc.

> On Thu, 2019-12-26 at 10:31 +0800, Wayne Lin wrote:
> > [Why]
> > Found kernel NULL pointer dereference under the below situation:
> >
> > src — HDMI_Monitor   src — HDMI_Monitor
> > e.g.:   \=>
> >  MSTB — MSTB (unplug) MSTB — MSTB
> >
> > When display 1 HDMI and 2 DP daisy chain monitors, unplugging the dp
> > cable connected to source causes kernel NULL pointer dereference at
> > drm_dp_mst_atomic_check_bw_limit(). When calculating pbn_limit, if
> > branch is null, accessing "&branch->ports" causes the problem.
> >
> > [How]
> > Judge branch is null or not at the beginning. If it is null, return 0.
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 7d2d31eaf003..a6473e3ab448 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -4707,6 +4707,9 @@ int drm_dp_mst_atomic_check_bw_limit(struct
> > drm_dp_mst_branch *branch,
> > struct drm_dp_vcpi_allocation *vcpi;
> > int pbn_limit = 0, pbn_used = 0;
> >
> > +   if (!branch)
> > +   return 0;
> > +
> > list_for_each_entry(port, &branch->ports, next) {
> > if (port->mstb)
> > if (drm_dp_mst_atomic_check_bw_limit(port->mstb,
> > mst_state))
> --
> Cheers,
>   Lyude Paul
--
Best regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

回覆: [PATCH] drm/dp_mst: clear time slots for ports invalid

[Lin, Wayne]

[AMD Public Use]



> -原始郵件-
> 寄件者: Lyude Paul 
> 寄件日期: Saturday, January 4, 2020 7:34 AM
> 收件者: Lin, Wayne ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> 副本: Kazlauskas, Nicholas ; Wentland,
> Harry ; Zuo, Jerry ;
> sta...@vger.kernel.org
> 主旨: Re: [PATCH] drm/dp_mst: clear time slots for ports invalid
> 
> On Wed, 2019-12-25 at 06:45 +, Lin, Wayne wrote:
> > > -Original Message-
> > > From: Lyude Paul 
> > > Sent: Saturday, December 21, 2019 8:12 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> > > amd-...@lists.freedesktop.org
> > > Cc: Kazlauskas, Nicholas ; Wentland,
> > > Harry ; Zuo, Jerry ;
> > > sta...@vger.kernel.org
> > > Subject: Re: [PATCH] drm/dp_mst: clear time slots for ports invalid
> > >
> > > Mhh-I think I understand the problem you're trying to solve here but
> > > I think this solution might be a bit overkill. When I did the rework
> > > of topology references for ports, I made it so that we can guarantee
> > > memory access to a port without it needing to be a valid part of the
> > > topology. As well, all parents of the port are guaranteed to be
> > > accessible for as long as the child is. Take a look at:
> > >
> > >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F01
> > > .org%
> > > 2Flinuxgraphics%2Fgfx-docs%2Fdrm%2Fgpu%2Fdrm-kms-
> helpers.html%23refc
> > > o
> > > unt-relationships-in-a-
> topology&data=02%7C01%7Cwayne.lin%40amd.c
> > > o
> m%7C722655b546c049dc081908d785aa6758%7C3dd8961fe4884e608e11a82d
> > >
> 994e183d%7C0%7C0%7C637124839257213115&sdata=Ctha3ja8kleeFOp
> > > PpA7EwDV1is81RAMsjqd1P6463ak%3D&reserved=0
> > >
> > > It's also worth noting that because of this there's a lot of
> > > get_port_validated()/put_port_validated() calls in the MST helpers
> > > that are now bogus and need to be removed once I get a chance. For
> > > new code we should limit the use of topology references to sections
> > > of code where we need a guarantee that resources on the port/branch
> > > (such as a drm connector, dp aux port, etc.) won't go away for as
> > > long as we need to use them.
> > >
> > > Do you think we could change this patch so instead of removing it
> > > from the proposed payloads on the CONNECTION_STATUS_NOTIFY, we
> keep
> > > the port's memory allocation around until it's been removed from the
> > > proposed payloads table and clean it up there on the next payload
> > > update?
> > >
> > Really appreciate for your time and comments in detail.
> >
> > In this patch, I wanted to just set the proposed_vcpi->num_slots to 0
> > for those ports which are no longer in the topology due to there is no
> > need to allocate time slots for these port. And expect those vcpi will
> > be updated during next update of payload ID table by
> > drm_dp_update_payload_part1().
> >
> > I tried to use drm_dp_mst_topology_get_port_validated() as a helper to
> > decide whether a port is in the topology or not. Use this function to
> > iterate over all ports that all proposed_vcpi[] drive to. If one port
> > is not in the topology, set the num_slots of the proposed_vcpi for
> > this port to 0. With num_slots as 0, these proposed_vcpi will be clean
> > up in next payload table update by drm_dp_update_payload_part1(). If a
> > port is still in the topology, then release the reference count which
> > was acquired previously from
> > drm_dp_mst_topology_get_port_validated() and do nothing.
> >
> > I didn't mean to kill invalid ports on receiving
> CONNECTION_STATUS_NOTIFY.
> > Sorry if I misuse or misunderstand something here?
> 
> Ahh, it seems I made the mistake here then because from your explanation
> you're using the API exactly as intended :). All of this has me wondering if
> some day we should try to get rid of the payload tracking we have and move
> it into atomic. But, that's a problem for another day.
> 
> Anyway-one small change below:
> 
> >
> > > On Fri, 2019-12-06 at 16:39 +0800, Wayne Lin wrote:
> > > > [Why]
> > > > When change the connection status in a MST topology, mst device
> > > > which detect the event will send out CONNECTION_STATUS_NOTIFY
> messgae.
> > > >
> > > > e.g. src-mst-mst-sst => src-mst (unplug) mst-sst
> > > >
> > > > Currently, under the above case of unplugging devic

RE: [PATCH v2] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, January 4, 2020 6:02 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH v2] drm/dp_mst: correct the shifting in
> DP_REMOTE_I2C_READ
> 
> Oh! Just a friendly tip, I fixed this before pushing your patch:
> 
> ➜  drm-maint git:(drm-misc-fixes) dim push
> dim: 0b1d54cedbb4 ("drm/dp_mst: correct the shifting in
> DP_REMOTE_I2C_READ"): Fixes: SHA1 needs at least 12 digits:
> dim: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper (v0.6))
> dim: ERROR: issues in commits detected, aborting
> 
> For the future, we have a set of DRM maintainer tools (they're quite useful
> for people who aren't maintainers though!) that you can use to make sure
> your patch is formatted correctly ahead of time:
> 
> https://drm.pages.freedesktop.org/maintainer-tools/dim.html>
>
> Particularly useful commands:
>  * dim sparse # Checks for trivial code issues, like set but unused variables
>  * dim checkpatch # Checks for code style issues
>  * dim fixes $COMMIT_ID # Adds an appropriately formatted Fixes: tag
>  * dim cite $COMMIT_ID # Adds an appropriately formatted Reference: tag
>
Really appreciate for your time!
I will have a look on this. Thanks a lot.
 
> On Fri, 2020-01-03 at 13:50 +0800, Wayne Lin wrote:
> > [Why]
> > According to DP spec, it should shift left 4 digits for NO_STOP_BIT in
> > REMOTE_I2C_READ message. Not 5 digits.
> >
> > In current code, NO_STOP_BIT is always set to zero which means I2C
> > master is always generating a I2C stop at the end of each I2C write
> > transaction while handling REMOTE_I2C_READ sideband message. This
> > issue might have the generated I2C signal not meeting the requirement.
> > Take random read in I2C for instance, I2C master should generate a
> > repeat start to start to read data after writing the read address.
> > This issue will cause the I2C master to generate a stop-start rather
> > than a re-start which is not expected in I2C random read.
> >
> > [How]
> > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case
> > in drm_dp_encode_sideband_req().
> >
> > Changes since
> >
> v1:(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >
> patchwork.kernel.org%2Fpatch%2F11312667%2F&data=02%7C01%7Cw
> ayne.li
> >
> n%40amd.com%7Ce4299c1721bd4bcb486708d790989148%7C3dd8961fe4884e
> 608e11a
> >
> 82d994e183d%7C0%7C0%7C637136857271065549&sdata=eoxiRojffBepY
> YoQbjp
> > j8b6R%2BkwaOQWBoU%2Fu8lY5gIQ%3D&reserved=0)
> > * Add more descriptions in commit and cc to stable
> >
> > Fixes: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper
> > (v0.6))
> > Reviewed-by: Harry Wentland 
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 1cf5f8b8bbb8..9d24c98bece1 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct
> > drm_dp_sideband_msg_req_body *req,
> > memcpy(&buf[idx], req-
> > >u.i2c_read.transactions[i].bytes, req-
> > >u.i2c_read.transactions[i].num_bytes);
> > idx += req->u.i2c_read.transactions[i].num_bytes;
> >
> > -   buf[idx] = (req-
> > >u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5;
> > +   buf[idx] = (req-
> > >u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
> > buf[idx] |= (req-
> > >u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
> > idx++;
> > }
> --
> Cheers,
>   Lyude Paul
--
Best Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, January 8, 2020 2:57 AM
> To: Lin, Wayne 
> Cc: Jani Nikula ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Zuo, Jerry
> ; Kazlauskas, Nicholas
> 
> Subject: Re: [PATCH] drm/dp_mst: correct the shifting in
> DP_REMOTE_I2C_READ
> 
> On Tue, Dec 31, 2019 at 03:30:47AM +, Lin, Wayne wrote:
> > [AMD Official Use Only - Internal Distribution Only]
> >
> > > 
> > > From: Jani Nikula 
> > > Sent: Monday, December 30, 2019 19:15
> > > To: Lin, Wayne; dri-devel@lists.freedesktop.org;
> > > amd-...@lists.freedesktop.org
> > > Cc: Zuo, Jerry; Kazlauskas, Nicholas; Lin, Wayne
> > > Subject: Re: [PATCH] drm/dp_mst: correct the shifting in
> > > DP_REMOTE_I2C_READ
> > >
> > > On Mon, 30 Dec 2019, Wayne Lin  wrote:
> > > > [Why]
> > > > According to DP spec, it should shift left 4 digits for
> > > > NO_STOP_BIT in REMOTE_I2C_READ message. Not 5 digits.
> > > >
> > > > [How]
> > > > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ
> > > > case in drm_dp_encode_sideband_req().
> > >
> > > Which commit introduced the issue? Fixes: tag. Does it need a stable
> > > backport? Does this fix a user visible bug?
> > >
> > > BR,
> > > Jani.
> > >
> > Thanks for your time and reminder.
> >
> > It seems like the issue has been there since very beginning.(commit:
> ad7f8a1).
> > It doesn't introduce user visible bug under my test cases, but this
> > affects the I2C signal between I2C master and I2C slave. Not pretty
> > sure if there is any eeprom will reset the written offset once received I2C
> stop. If so, that might cause wrongly reading EDID.
> > I will Cc to stable. Thanks.
> 
> The segment address should be reset on STOP. So large EDIDs should fail.
> IIRC we had a bug report of some sort about this which I tried to fix by
> confgiuring .no_stop_bit correctly, but apparently I failed to double check
> that the bit get stuffed onto the wire correctly.
> 
> Ah yes,
> https://bugs.freedesktop.org/show_bug.cgi?id=108081
> So you may have just fixed that one, although we seem to have closed it
> already.

Thanks for your time and the explanation.
> 
> > > > Signed-off-by: Wayne Lin 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index 1d1bfa49ca2b..0557e225ff67 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct
> drm_dp_sideband_msg_req_body *req,
> > > >   memcpy(&buf[idx], 
> > > > req->u.i2c_read.transactions[i].bytes,
> req->u.i2c_read.transactions[i].num_bytes);
> > > >   idx +=
> > > > req->u.i2c_read.transactions[i].num_bytes;
> > > >
> > > > - buf[idx] = 
> > > > (req->u.i2c_read.transactions[i].no_stop_bit &
> 0x1) << 5;
> > > > + buf[idx] =
> > > > + (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
> > > >   buf[idx] |= (req-
> >u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
> > > >   idx++;
> > > >   }
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
> > --
> > Wayne Lin
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-
> devel&data=02%7C01%7C
> >
> Wayne.Lin%40amd.com%7C7a299e0e845242312acb08d793a36e63%7C3dd896
> 1fe4884
> >
> e608e11a82d994e183d%7C0%7C0%7C637140202457938159&sdata=yK4I
> 7fgenrR
> > f%2FXrs5jKXv%2BmOZdjV7dl%2BiNUJcsxnXG0%3D&reserved=0
> 
> --
> Ville Syrjälä
> Intel
--
Best regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI 2.0

[Lin, Wayne]

From: Ville Syrjälä 
Sent: Thursday, October 3, 2019 21:29
To: Lin, Wayne 
Cc: dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org ; Li, Sun peng 
(Leo) ; Kazlauskas, Nicholas 
Subject: Re: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI 2.0

On Thu, Oct 03, 2019 at 06:49:05AM +, Lin, Wayne wrote:
>
>
> 
> From: Ville Syrjälä 
> Sent: Wednesday, October 2, 2019 19:58
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org ; 
> amd-...@lists.freedesktop.org ; Li, Sun peng 
> (Leo) ; Kazlauskas, Nicholas 
> Subject: Re: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI 2.0
>
> On Tue, Sep 24, 2019 at 01:26:21PM +0800, Wayne Lin wrote:
> > In HDMI 1.4 defines 4k modes without specific aspect ratio.
> > However, in HDMI 2.0, adds aspect ratio attribute to distinguish different
> > 4k modes.
> >
> > According to Appendix E of HDMI 2.0 spec, source should use VSIF to
> > indicate VIC mode only when the mode is one defined in HDMI 1.4b 4K modes.
> > Otherwise, use AVI infoframes to convey VIC.
> >
> > eg: VIC_103 should use AVI infoframes and VIC_93 use VSIF
> >
> > When the sink is HDMI 2.0, current code in
> > drm_hdmi_avi_infoframe_from_display_mode will also force mode VIC_103 to
> > have VIC value 0. This violates the spec and needs to be corrected.
>
> > Where is that being done? We only set the AVI VIC to zero if we're going
> > to use the HDMI VIC instead.
>
> Appreciate for your time and apologize for not explaining it clearly.
> Current code in drm_hdmi_avi_infoframe_from_display_mode() will call
> drm_match_hdmi_mode() to set up vendor_if_vic. By checking
> drm_valid_hdmi_vic(vendor_if_vic) to see if the vic info should be conveyed 
> by avi
> or not.
>
> But in drm_match_hdmi_mode(), code doesn't enable match_flags with
> DRM_MODE_MATCH_ASPECT_RATIO. I think it's due to HDMI1.4b doesn't specify
> 4K mode conveyed by HDMI VIC with particular aspect ratio. But in Appendix E 
> of
> HDMI 2.0 spec, it specify only 4k modes with particular aspect ratio should 
> use VSIF to convey.
> Hence, when the sink support HDMI 2.0 and set the mode to be VIC_103, calling
> drm_match_hdmi_mode(mode) will return vendor_if_vic = 3 (VIC_93 and VIC_103 
> are having
> the same timing but different aspect ratio). Thereafter will set the  
> frame->video_code to 0.
> However, VIC_103 should use AVI VIC according to HDMI 2.0 spec (only VIC: 93, 
> 94, 95 &
> 98 should use VSIF).
>
> This patch try to revise that, when the sink support HDMI 2.0, 
> drm_match_hdmi_mode()
> should also take aspect ratio into consideration.
> But for easy reading, I add another function "drm_match_hdmi_1_4_mode" to do 
> so.

> Seems rather convoluted. I think we should just add the aspect ratios
> to edid_4k_modes[]. Or is there some problem with that approach?

Thanks for your time.

Since HDMI 1.4b doesn't require edid_4k_modes[] with specific aspect ratio, 
modes as the same
timing in edid_4k_modes[] but with different aspect ratios are also expected to 
convey VIC by
VSIF to HDMI 1.4 sink. Might can't guarantee that there wont't be any 
compatibility side effect with
that approach when the sink is HDMI 1.4b .

>
> > The same situation occurs in drm_hdmi_vendor_infoframe_from_display_mode
> > and should set HDMI_VIC when the mode is one defined in HDMI 1.4b 4K
> > modes.
>
> > Yes, and we do that. "vic = drm_match_hdmi_mode(mode);"
>
> > Apart from adding the aspect ratios I don't really understand what
> > you're trying to achieve here.
>
> For HDMI 2.0 sink, drm_match_hdmi_mode() should also take aspect ratio into 
> consideration.
> Once again, very appreciate for your time.
>
> > ---
> >  drivers/gpu/drm/drm_edid.c | 95 --
> >  1 file changed, 92 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 649cfd8b4200..0fea9bf4ec67 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -1306,6 +1306,37 @@ static const struct drm_display_mode edid_4k_modes[] 
> > = {
> >  .vrefresh = 24, },
> >  };
> >
> > +/*
> > + * 4k modes of HDMI 1.4 defined in HDMI 2.0. Index using the VIC.
> > + */
> > +static const struct drm_display_mode hdmi_1_4_edid_4k_modes[] = {
> > + /* 0 - dummy, VICs start at 1 */
> > + { },
> > + /* 1 - 3840x2160@30Hz */
> > + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
> > + 

RE: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI 2.0

[Lin, Wayne]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Friday, October 4, 2019 10:24 PM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Li, Sun
> peng (Leo) ; Kazlauskas, Nicholas
> 
> Subject: Re: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI
> 2.0
> 
> On Fri, Oct 04, 2019 at 10:41:20AM +, Lin, Wayne wrote:
> >
> >
> > 
> > From: Ville Syrjälä 
> > Sent: Thursday, October 3, 2019 21:29
> > To: Lin, Wayne 
> > Cc: dri-devel@lists.freedesktop.org ;
> > amd-...@lists.freedesktop.org ; Li, Sun
> > peng (Leo) ; Kazlauskas, Nicholas
> > 
> > Subject: Re: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI
> > 2.0
> >
> > On Thu, Oct 03, 2019 at 06:49:05AM +, Lin, Wayne wrote:
> > >
> > >
> > > 
> > > From: Ville Syrjälä 
> > > Sent: Wednesday, October 2, 2019 19:58
> > > To: Lin, Wayne 
> > > Cc: dri-devel@lists.freedesktop.org
> > > ; amd-...@lists.freedesktop.org
> > > ; Li, Sun peng (Leo)
> > > ; Kazlauskas, Nicholas
> > > 
> > > Subject: Re: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under
> > > HDMI 2.0
> > >
> > > On Tue, Sep 24, 2019 at 01:26:21PM +0800, Wayne Lin wrote:
> > > > In HDMI 1.4 defines 4k modes without specific aspect ratio.
> > > > However, in HDMI 2.0, adds aspect ratio attribute to distinguish
> > > > different 4k modes.
> > > >
> > > > According to Appendix E of HDMI 2.0 spec, source should use VSIF
> > > > to indicate VIC mode only when the mode is one defined in HDMI 1.4b 4K
> modes.
> > > > Otherwise, use AVI infoframes to convey VIC.
> > > >
> > > > eg: VIC_103 should use AVI infoframes and VIC_93 use VSIF
> > > >
> > > > When the sink is HDMI 2.0, current code in
> > > > drm_hdmi_avi_infoframe_from_display_mode will also force mode
> > > > VIC_103 to have VIC value 0. This violates the spec and needs to be
> corrected.
> > >
> > > > Where is that being done? We only set the AVI VIC to zero if we're
> > > > going to use the HDMI VIC instead.
> > >
> > > Appreciate for your time and apologize for not explaining it clearly.
> > > Current code in drm_hdmi_avi_infoframe_from_display_mode() will call
> > > drm_match_hdmi_mode() to set up vendor_if_vic. By checking
> > > drm_valid_hdmi_vic(vendor_if_vic) to see if the vic info should be
> > > conveyed by avi or not.
> > >
> > > But in drm_match_hdmi_mode(), code doesn't enable match_flags with
> > > DRM_MODE_MATCH_ASPECT_RATIO. I think it's due to HDMI1.4b doesn't
> > > specify 4K mode conveyed by HDMI VIC with particular aspect ratio.
> > > But in Appendix E of HDMI 2.0 spec, it specify only 4k modes with
> particular aspect ratio should use VSIF to convey.
> > > Hence, when the sink support HDMI 2.0 and set the mode to be
> > > VIC_103, calling
> > > drm_match_hdmi_mode(mode) will return vendor_if_vic = 3 (VIC_93 and
> > > VIC_103 are having the same timing but different aspect ratio). Thereafter
> will set the  frame->video_code to 0.
> > > However, VIC_103 should use AVI VIC according to HDMI 2.0 spec (only
> > > VIC: 93, 94, 95 &
> > > 98 should use VSIF).
> > >
> > > This patch try to revise that, when the sink support HDMI 2.0,
> > > drm_match_hdmi_mode() should also take aspect ratio into consideration.
> > > But for easy reading, I add another function
> "drm_match_hdmi_1_4_mode" to do so.
> >
> > > Seems rather convoluted. I think we should just add the aspect
> > > ratios to edid_4k_modes[]. Or is there some problem with that approach?
> >
> > Thanks for your time.
> >
> > Since HDMI 1.4b doesn't require edid_4k_modes[] with specific aspect
> > ratio, modes as the same timing in edid_4k_modes[] but with different
> > aspect ratios are also expected to convey VIC by VSIF to HDMI 1.4
> > sink. Might can't guarantee that there wont't be any compatibility side 
> > effect
> with that approach when the sink is HDMI 1.4b .
> 
> I think adding them should be fine. But while checking the existing code I
> noticed a few problems, so I sent out some fixes (cc:d you).

Thanks for your time and sorry for late reply.
I will try out those received fixes and leave messages there.

> 
> --
> Ville Syrjälä
> Intel

--
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)

[Lin, Wayne]

> -Original Message-
> From: Ville Syrjala 
> Sent: Friday, October 4, 2019 10:19 PM
> To: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; Lin, Wayne 
> Subject: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
> 
> From: Ville Syrjälä 
> 
> I think this should provide most of necessary logic for adding aspecr ratios 
> to
> the HDMI 4k modes.
> 
> Cc: Wayne Lin 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c | 37 +++--
>  1 file changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> c7f9f7ca75a2..c76814edc784 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3210,6 +3210,11 @@ static enum hdmi_picture_aspect
> drm_get_cea_aspect_ratio(const u8 video_code)
>   return edid_cea_modes[video_code].picture_aspect_ratio;
>  }
> 
> +static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const u8
> +video_code) {
> + return edid_4k_modes[video_code].picture_aspect_ratio;
> +}
> +

There are no picture_aspect_ratio attributes defined for modes in 
edid_4k_modes[] now. Should add on those definitions.

>  /*
>   * Calculate the alternate clock for HDMI modes (those from the HDMI
> vendor
>   * specific block).
> @@ -3236,6 +3241,9 @@ static u8
> drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_
>   if (!to_match->clock)
>   return 0;
> 
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
>   for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
>   const struct drm_display_mode *hdmi_mode =
> &edid_4k_modes[vic];
>   unsigned int clock1, clock2;
> @@ -3271,6 +3279,9 @@ static u8 drm_match_hdmi_mode(const struct
> drm_display_mode *to_match)
>   if (!to_match->clock)
>   return 0;
> 
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
>   for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
>   const struct drm_display_mode *hdmi_mode =
> &edid_4k_modes[vic];
>   unsigned int clock1, clock2;

Current code in drm_match_hdmi_mdoe() & drm_match_hdmi_mode_clock_tolerance()
use hdmi_mode_alternate_clock() to find alternate clocks.
In hdmi_mode_alternate_clock(), it adds an exception for VIC 4 mode 
(4096x2160@24)
due to there is no alternate clock defined for that mode in HDMI1.4b. But 
HDMI2.0 adds
23.98Hz for that mode. Maybe we should also revise that part.

> @@ -5218,6 +5229,7 @@
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> *frame,
>const struct drm_display_mode *mode)  {
>   enum hdmi_picture_aspect picture_aspect;
> + u8 vic, hdmi_vic;
>   int err;
> 
>   if (!frame || !mode)
> @@ -5230,7 +5242,8 @@
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> *frame,
>   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>   frame->pixel_repeat = 1;
> 
> - frame->video_code = drm_mode_cea_vic(connector, mode);
> + vic = drm_mode_cea_vic(connector, mode);
> + hdmi_vic = drm_mode_hdmi_vic(connector, mode);
> 
>   frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> 
> @@ -5244,11 +5257,15 @@
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> *frame,
> 
>   /*
>* Populate picture aspect ratio from either
> -  * user input (if specified) or from the CEA mode list.
> +  * user input (if specified) or from the CEA/HDMI mode lists.
>*/
>   picture_aspect = mode->picture_aspect_ratio;
> - if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
> - picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
> + if (picture_aspect == HDMI_PICTURE_ASPECT_NONE) {
> + if (vic)
> + picture_aspect = drm_get_cea_aspect_ratio(vic);
> + else if (hdmi_vic)
> + picture_aspect = drm_get_hdmi_aspect_ratio(hdmi_vic);
> + }
> 
>   /*
>* The infoframe can't convey anything but none, 4:3 @@ -5256,12
> +5273,20 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
>* we can only satisfy it by specifying the right VIC.
>*/
>   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
> - if (picture_aspect !=
> - drm_get_cea_aspect_ratio(frame->video_code))
> + if (vic) {
> + 

RE: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)

[Lin, Wayne]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Monday, October 14, 2019 10:42 PM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
> 
> On Mon, Oct 14, 2019 at 09:27:07AM +, Lin, Wayne wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjala 
> > > Sent: Friday, October 4, 2019 10:19 PM
> > > To: dri-devel@lists.freedesktop.org
> > > Cc: intel-...@lists.freedesktop.org; Lin, Wayne 
> > > Subject: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
> > >
> > > From: Ville Syrjälä 
> > >
> > > I think this should provide most of necessary logic for adding
> > > aspecr ratios to the HDMI 4k modes.
> > >
> > > Cc: Wayne Lin 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_edid.c | 37
> > > +++--
> > >  1 file changed, 31 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index
> > > c7f9f7ca75a2..c76814edc784 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3210,6 +3210,11 @@ static enum hdmi_picture_aspect
> > > drm_get_cea_aspect_ratio(const u8 video_code)
> > >   return edid_cea_modes[video_code].picture_aspect_ratio;
> > >  }
> > >
> > > +static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const u8
> > > +video_code) {
> > > + return edid_4k_modes[video_code].picture_aspect_ratio;
> > > +}
> > > +
> >
> > There are no picture_aspect_ratio attributes defined for modes in
> > edid_4k_modes[] now. Should add on those definitions.
> >
> > >  /*
> > >   * Calculate the alternate clock for HDMI modes (those from the
> > > HDMI vendor
> > >   * specific block).
> > > @@ -3236,6 +3241,9 @@ static u8
> > > drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode
> *to_
> > >   if (!to_match->clock)
> > >   return 0;
> > >
> > > + if (to_match->picture_aspect_ratio)
> > > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > > +
> > >   for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> > >   const struct drm_display_mode *hdmi_mode =
> &edid_4k_modes[vic];
> > >   unsigned int clock1, clock2;
> > > @@ -3271,6 +3279,9 @@ static u8 drm_match_hdmi_mode(const struct
> > > drm_display_mode *to_match)
> > >   if (!to_match->clock)
> > >   return 0;
> > >
> > > + if (to_match->picture_aspect_ratio)
> > > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > > +
> > >   for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> > >   const struct drm_display_mode *hdmi_mode =
> &edid_4k_modes[vic];
> > >   unsigned int clock1, clock2;
> >
> > Current code in drm_match_hdmi_mdoe() &
> > drm_match_hdmi_mode_clock_tolerance()
> > use hdmi_mode_alternate_clock() to find alternate clocks.
> > In hdmi_mode_alternate_clock(), it adds an exception for VIC 4 mode
> > (4096x2160@24) due to there is no alternate clock defined for that
> > mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode. Maybe we
> should also revise that part.
> 
> I'm tempted to just remove that exception. I have a hard time imagining it
> causing serious problems.

Thanks for your time.
I've run smoke test and CTS to verify these patches (with adding the aspect 
ratio 
attribute to edid_4k_modes[] and removing the exception for23.98Hz). So far it
looks good on my environment. Is there any further modification should be done
on these patches?

> 
> >
> > > @@ -5218,6 +5229,7 @@
> > > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > > *frame,
> > >const struct drm_display_mode *mode)  {
> > >   enum hdmi_picture_aspect picture_aspect;
> > > + u8 vic, hdmi_vic;
> > >   int err;
> > >
> > >   if (!frame || !mode)
> > > @@ -5230,7 +5242,8 @@
> > > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > > *frame,
> > >   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > >   frame->pixel_repeat = 1;
> > >
> > > - frame->video_code = drm_mode

RE: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.

[Lin, Wayne]

[AMD Public Use]

Hi Paul,

Thanks for the mail!

I tried to solve this problem by having restriction on sending one msg at a 
time due to hub/dock compatibility problems.
>From my experience, some branch devices don't handle well on interleaved 
>replies (Dock from HP I think)
As the result of that, correct me if I'm wrong, I remember most gpu vendors 
just send one down request at a time now in windows environment.
I would suggest the original solution :)

Thanks!
> -Original Message-
> From: Sean Paul 
> Sent: Friday, February 14, 2020 5:15 AM
> To: dri-devel@lists.freedesktop.org
> Cc: ly...@redhat.com; Lin, Wayne ; Sean Paul
> ; Maarten Lankhorst
> ; Maxime Ripard ;
> David Airlie 
> Subject: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.
> 
> From: Sean Paul 
> 
> Now that we can support multiple simultaneous replies, remove the
> restrictions placed on sending new tx msgs.
> 
> This patch essentially just reverts commit
>   5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time") now
> that the problem is solved in a different way.
> 
> Cc: Wayne Lin 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 14 ++
>  include/drm/drm_dp_mst_helper.h   |  6 --
>  2 files changed, 2 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 7e6a82efdfc02..cbf0bb0ddeb84 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1203,8 +1203,6 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
>   txmsg->state == DRM_DP_SIDEBAND_TX_SENT) {
>   mstb->tx_slots[txmsg->seqno] = NULL;
>   }
> - mgr->is_waiting_for_dwn_reply = false;
> -
>   }
>  out:
>   if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) { @@
> -1214,7 +1212,6 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
>   }
>   mutex_unlock(&mgr->qlock);
> 
> - drm_dp_mst_kick_tx(mgr);
>   return ret;
>  }
> 
> @@ -2797,11 +2794,9 @@ static void process_single_down_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr)
>   ret = process_single_tx_qlock(mgr, txmsg, false);
>   if (ret == 1) {
>   /* txmsg is sent it should be in the slots now */
> - mgr->is_waiting_for_dwn_reply = true;
>   list_del(&txmsg->next);
>   } else if (ret) {
>   DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> - mgr->is_waiting_for_dwn_reply = false;
>   list_del(&txmsg->next);
>   if (txmsg->seqno != -1)
>   txmsg->dst->tx_slots[txmsg->seqno] = NULL; @@ -2841,8
> +2836,7 @@ static void drm_dp_queue_down_tx(struct
> drm_dp_mst_topology_mgr *mgr,
>   drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
>   }
> 
> - if (list_is_singular(&mgr->tx_msg_downq) &&
> - !mgr->is_waiting_for_dwn_reply)
> + if (list_is_singular(&mgr->tx_msg_downq))
>   process_single_down_tx_qlock(mgr);
>   mutex_unlock(&mgr->qlock);
>  }
> @@ -3822,7 +3816,6 @@ static int drm_dp_mst_handle_down_rep(struct
> drm_dp_mst_topology_mgr *mgr)
>   mutex_lock(&mgr->qlock);
>   txmsg->state = DRM_DP_SIDEBAND_TX_RX;
>   mstb->tx_slots[seqno] = NULL;
> - mgr->is_waiting_for_dwn_reply = false;
>   mutex_unlock(&mgr->qlock);
> 
>   wake_up_all(&mgr->tx_waitq);
> @@ -3830,9 +3823,6 @@ static int drm_dp_mst_handle_down_rep(struct
> drm_dp_mst_topology_mgr *mgr)
>   return 0;
> 
>  out_clear_reply:
> - mutex_lock(&mgr->qlock);
> - mgr->is_waiting_for_dwn_reply = false;
> - mutex_unlock(&mgr->qlock);
>   if (msg)
>   memset(msg, 0, sizeof(struct drm_dp_sideband_msg_rx));
>  out:
> @@ -4670,7 +4660,7 @@ static void drm_dp_tx_work(struct work_struct
> *work)
>   struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct
> drm_dp_mst_topology_mgr, tx_work);
> 
>   mutex_lock(&mgr->qlock);
> - if (!list_empty(&mgr->tx_msg_downq)
> && !mgr->is_waiting_for_dwn_reply)
> + if (!list_empty(&mgr->tx_msg_downq))
>   process_single_down_tx_qlock(mgr);
>   mutex_unlock(&mgr->qlock);
>  }
> diff --git a/include/drm/drm_dp_mst_helper.h
> b/include/drm/drm_dp_mst_helper.h index 7d0341f94ce1b..fcc30e64c8e7e
> 10064

RE: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Sean Paul 
> Sent: Saturday, February 15, 2020 12:09 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; ly...@redhat.com; Sean Paul
> ; Maarten Lankhorst
> ; Maxime Ripard ;
> David Airlie 
> Subject: Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.
> 
> On Fri, Feb 14, 2020 at 12:58 AM Lin, Wayne  wrote:
> >
> > [AMD Public Use]
> >
> > Hi Paul,
> >
> > Thanks for the mail!
> >
> > I tried to solve this problem by having restriction on sending one msg at a
> time due to hub/dock compatibility problems.
> > From my experience, some branch devices don't handle well on
> > interleaved replies (Dock from HP I think)
> 
> Hi Wayne,
> Hmm, that's interesting, do you have a part number of the failing dock so I 
> can
> test it?
> 
Hi Paul,

Sorry but it's been quite a while. I can't exactly tell the part number. 
If I remember correctly, when the specific branch device receives interleaved 
replies,
it just doesn't reply to any requests.

> > As the result of that, correct me if I'm wrong, I remember most gpu vendors
> just send one down request at a time now in windows environment.
> > I would suggest the original solution :)
> 
> I can't really say what happens on the Windows side of the world, but I 
> suppose
> that makes sense if this is a widespread issue with docks. I do worry about 
> the
> performance hit.
> 
> If indeed this is a problem, could we ratelimit per branch device instead of
> globally? Even that would be better than serializing everything.
> 
Since the problem was because some branch devices can't simultaneously handle 
two replies, I'm afraid that we might still encounter the same problem?
 
Thanks!
> Sean
> 
> >
> > Thanks!
> > > -Original Message-
> > > From: Sean Paul 
> > > Sent: Friday, February 14, 2020 5:15 AM
> > > To: dri-devel@lists.freedesktop.org
> > > Cc: ly...@redhat.com; Lin, Wayne ; Sean Paul
> > > ; Maarten Lankhorst
> > > ; Maxime Ripard
> > > ; David Airlie 
> > > Subject: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.
> > >
> > > From: Sean Paul 
> > >
> > > Now that we can support multiple simultaneous replies, remove the
> > > restrictions placed on sending new tx msgs.
> > >
> > > This patch essentially just reverts commit
> > >   5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time")
> now
> > > that the problem is solved in a different way.
> > >
> > > Cc: Wayne Lin 
> > > Signed-off-by: Sean Paul 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 14 ++
> > >  include/drm/drm_dp_mst_helper.h   |  6 --
> > >  2 files changed, 2 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 7e6a82efdfc02..cbf0bb0ddeb84 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -1203,8 +1203,6 @@ static int drm_dp_mst_wait_tx_reply(struct
> > > drm_dp_mst_branch *mstb,
> > >   txmsg->state == DRM_DP_SIDEBAND_TX_SENT) {
> > >   mstb->tx_slots[txmsg->seqno] = NULL;
> > >   }
> > > - mgr->is_waiting_for_dwn_reply = false;
> > > -
> > >   }
> > >  out:
> > >   if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
> > > @@
> > > -1214,7 +1212,6 @@ static int drm_dp_mst_wait_tx_reply(struct
> > > drm_dp_mst_branch *mstb,
> > >   }
> > >   mutex_unlock(&mgr->qlock);
> > >
> > > - drm_dp_mst_kick_tx(mgr);
> > >   return ret;
> > >  }
> > >
> > > @@ -2797,11 +2794,9 @@ static void
> > > process_single_down_tx_qlock(struct
> > > drm_dp_mst_topology_mgr *mgr)
> > >   ret = process_single_tx_qlock(mgr, txmsg, false);
> > >   if (ret == 1) {
> > >   /* txmsg is sent it should be in the slots now */
> > > - mgr->is_waiting_for_dwn_reply = true;
> > >   list_del(&txmsg->next);
> > >   } else if (ret) {
> > >   DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> > > - mgr->is_waiting_for_dwn_reply = false;
> >

RE: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Sean Paul 
> Sent: Wednesday, February 19, 2020 1:15 AM
> To: Lin, Wayne 
> Cc: Sean Paul ; dri-devel@lists.freedesktop.org;
> ly...@redhat.com; Sean Paul ; Maarten Lankhorst
> ; Maxime Ripard ;
> David Airlie 
> Subject: Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.
> 
> On Tue, Feb 18, 2020 at 10:52:06AM -0500, Sean Paul wrote:
> > On Mon, Feb 17, 2020 at 07:08:37AM +, Lin, Wayne wrote:
> > > [AMD Public Use]
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Sean Paul 
> > > > Sent: Saturday, February 15, 2020 12:09 AM
> > > > To: Lin, Wayne 
> > > > Cc: dri-devel@lists.freedesktop.org; ly...@redhat.com; Sean Paul
> > > > ; Maarten Lankhorst
> > > > ; Maxime Ripard
> > > > ; David Airlie 
> > > > Subject: Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.
> > > >
> > > > On Fri, Feb 14, 2020 at 12:58 AM Lin, Wayne 
> wrote:
> > > > >
> > > > > [AMD Public Use]
> > > > >
> > > > > Hi Paul,
> > > > >
> > > > > Thanks for the mail!
> > > > >
> > > > > I tried to solve this problem by having restriction on sending
> > > > > one msg at a
> > > > time due to hub/dock compatibility problems.
> > > > > From my experience, some branch devices don't handle well on
> > > > > interleaved replies (Dock from HP I think)
> > > >
> > > > Hi Wayne,
> > > > Hmm, that's interesting, do you have a part number of the failing
> > > > dock so I can test it?
> > > >
> > > Hi Paul,
> > >
> > > Sorry but it's been quite a while. I can't exactly tell the part number.
> > > If I remember correctly, when the specific branch device receives
> > > interleaved replies, it just doesn't reply to any requests.
> > >
> > > > > As the result of that, correct me if I'm wrong, I remember most
> > > > > gpu vendors
> > > > just send one down request at a time now in windows environment.
> > > > > I would suggest the original solution :)
> > > >
> > > > I can't really say what happens on the Windows side of the world,
> > > > but I suppose that makes sense if this is a widespread issue with
> > > > docks. I do worry about the performance hit.
> > > >
> > > > If indeed this is a problem, could we ratelimit per branch device
> > > > instead of globally? Even that would be better than serializing 
> > > > everything.
> > > >
> > > Since the problem was because some branch devices can't
> > > simultaneously handle two replies, I'm afraid that we might still 
> > > encounter
> the same problem?
> > >
> >
> > Hi Wayne,
> > Thanks for clarifying. I'm a bit hesitant to scrap this idea without
> > solid evidence that this is a common problem. Do you have any hubs
> > around AMD that you could try my patchset with?
Hi Paul,
Sure! I will see what I have at hand and try your patch set. It might take
me some time but I will update this as soon as possible. :)

Thanks!
> 
> Oh, if you can test the set, you'll also need this patch as well :-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3814,7 +3814,9 @@ static bool drm_dp_get_one_sb_msg(struct
> drm_dp_mst_topology_mgr *mgr, bool up,
> int basereg = up ? DP_SIDEBAND_MSG_UP_REQ_BASE :
>DP_SIDEBAND_MSG_DOWN_REP_BASE;
> 
> -   *mstb = NULL;
> +   if (mstb)
> +   *mstb = NULL;
> +
> *seqno = -1;
> 
> len = min(mgr->max_dpcd_transaction_bytes, 16);
> 
> 
> > Perhaps we could get some hard data? I'm happy to test things on my
> > end, but I probably shouldn't just start buying a bunch of random HP
> > docks in hopes one of them exhibits the issue :)
> >
> > To add anecdote to anecdote, everything on my desk seems to work with
> > interleaved replies.
> >
> > Since HDCP spec requires the host to verify each channel's encryption
> > every <2s, we're going to be increasing the amount of sideband traffic
> > a fair amount, so I would like to ensure we're doing 

RE: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.

[Lin, Wayne]

[AMD Public Use]


> -Original Message-
> From: Sean Paul  
> Sent: Friday, March 6, 2020 1:19 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; ly...@redhat.com; Sean Paul 
> ; Maarten Lankhorst 
> ; Maxime Ripard ; 
> David Airlie 
> Subject: Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.
> 
> On Wed, Feb 19, 2020 at 6:00 AM Lin, Wayne  wrote:
> >
> > [AMD Public Use]
> >
> >
> >
> > > -Original Message-
> > > From: Sean Paul 
> > > Sent: Wednesday, February 19, 2020 1:15 AM
> > > To: Lin, Wayne 
> > > Cc: Sean Paul ; dri-devel@lists.freedesktop.org; 
> > > ly...@redhat.com; Sean Paul ; Maarten 
> > > Lankhorst ; Maxime Ripard 
> > > ; David Airlie 
> > > Subject: Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.
> > >
> > > On Tue, Feb 18, 2020 at 10:52:06AM -0500, Sean Paul wrote:
> > > > On Mon, Feb 17, 2020 at 07:08:37AM +, Lin, Wayne wrote:
> > > > > [AMD Public Use]
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Sean Paul 
> > > > > > Sent: Saturday, February 15, 2020 12:09 AM
> > > > > > To: Lin, Wayne 
> > > > > > Cc: dri-devel@lists.freedesktop.org; ly...@redhat.com; Sean 
> > > > > > Paul ; Maarten Lankhorst 
> > > > > > ; Maxime Ripard 
> > > > > > ; David Airlie 
> > > > > > Subject: Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg 
> > > > > > restriction.
> > > > > >
> > > > > > On Fri, Feb 14, 2020 at 12:58 AM Lin, Wayne 
> > > > > > 
> > > wrote:
> > > > > > >
> > > > > > > [AMD Public Use]
> > > > > > >
> > > > > > > Hi Paul,
> > > > > > >
> > > > > > > Thanks for the mail!
> > > > > > >
> > > > > > > I tried to solve this problem by having restriction on 
> > > > > > > sending one msg at a
> > > > > > time due to hub/dock compatibility problems.
> > > > > > > From my experience, some branch devices don't handle well on 
> > > > > > > interleaved replies (Dock from HP I think)
> > > > > >
> > > > > > Hi Wayne,
> > > > > > Hmm, that's interesting, do you have a part number of the 
> > > > > > failing dock so I can test it?
> > > > > >
> > > > > Hi Paul,
> > > > >
> > > > > Sorry but it's been quite a while. I can't exactly tell the part 
> > > > > number.
> > > > > If I remember correctly, when the specific branch device 
> > > > > receives interleaved replies, it just doesn't reply to any requests.
> > > > >
> > > > > > > As the result of that, correct me if I'm wrong, I remember 
> > > > > > > most gpu vendors
> > > > > > just send one down request at a time now in windows environment.
> > > > > > > I would suggest the original solution :)
> > > > > >
> > > > > > I can't really say what happens on the Windows side of the 
> > > > > > world, but I suppose that makes sense if this is a widespread 
> > > > > > issue with docks. I do worry about the performance hit.
> > > > > >
> > > > > > If indeed this is a problem, could we ratelimit per branch 
> > > > > > device instead of globally? Even that would be better than 
> > > > > > serializing everything.
> > > > > >
> > > > > Since the problem was because some branch devices can't 
> > > > > simultaneously handle two replies, I'm afraid that we might 
> > > > > still encounter
> > > the same problem?
> > > > >
> > > >
> > > > Hi Wayne,
> > > > Thanks for clarifying. I'm a bit hesitant to scrap this idea 
> > > > without solid evidence that this is a common problem. Do you have 
> > > > any hubs around AMD that you could try my patchset with?
> > Hi Paul,
> > Sure! I will see what I have at hand and try your patch set. It might 
> > take me some time but I will update this as soon as possible. :)
> >
&g

RE: [PATCH] drm/dp_mst: Have DP_Tx send one msg at a time

[Lin, Wayne]

[AMD Public Use]

Thanks for your time and hope you get well soon!

-Original Message-
From: Lyude Paul  
Sent: Tuesday, January 14, 2020 1:59 AM
To: Lin, Wayne ; dri-devel@lists.freedesktop.org; 
amd-...@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Wentland, Harry 
; Zuo, Jerry 
Subject: Re: [PATCH] drm/dp_mst: Have DP_Tx send one msg at a time

Hey! Haven't taken a look at this patch yet but just wanted to let you know I'm 
going to try to get to most of the stuff you've got pending for me. I came down 
with a really nasty cold last week so sorry if you've had any other patches 
waiting until now!

On Mon, 2020-01-13 at 17:36 +0800, Wayne Lin wrote:
> [Why]
> Noticed this while testing MST with the 4 ports MST hub from 
> StarTech.com. Sometimes can't light up monitors normally and get the 
> error message as 'sideband msg build failed'.
> 
> Look into aux transactions, found out that source sometimes will send 
> out another down request before receiving the down reply of the 
> previous down request. On the other hand, in drm_dp_get_one_sb_msg(), 
> current code doesn't handle the interleaved replies case. Hence, 
> source can't build up message completely and can't light up monitors.
> 
> [How]
> For good compatibility, enforce source to send out one down request at 
> a time. Add a flag, is_waiting_for_dwn_reply, to determine if the 
> source can send out a down request immediately or not.
> 
> - Check the flag before calling process_single_down_tx_qlock to send 
> out a msg
> - Set the flag when successfully send out a down request
> - Clear the flag when successfully build up a down reply
> - Clear the flag when find erros during sending out a down request
> - Clear the flag when find errors during building up a down reply
> - Clear the flag when timeout occurs during waiting for a down reply
> - Use drm_dp_mst_kick_tx() to try to send another down request in 
> queue at the end of drm_dp_mst_wait_tx_reply() (attempt to send out 
> messages in queue when errors occur)
> 
> Cc: Lyude Paul 
> Signed-off-by: Wayne Lin 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
>  include/drm/drm_dp_mst_helper.h   |  6 ++
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 4395d5cc0645..3542af15387a 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1195,6 +1195,8 @@ static int drm_dp_mst_wait_tx_reply(struct 
> drm_dp_mst_branch *mstb,
>   txmsg->state == DRM_DP_SIDEBAND_TX_SENT) {
>   mstb->tx_slots[txmsg->seqno] = NULL;
>   }
> + mgr->is_waiting_for_dwn_reply = false;
> +
>   }
>  out:
>   if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) { @@ 
> -1204,6 +1206,7 @@ static int drm_dp_mst_wait_tx_reply(struct 
> drm_dp_mst_branch *mstb,
>   }
>   mutex_unlock(&mgr->qlock);
>  
> + drm_dp_mst_kick_tx(mgr);
>   return ret;
>  }
>  
> @@ -2770,9 +2773,11 @@ static void process_single_down_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr)
>   ret = process_single_tx_qlock(mgr, txmsg, false);
>   if (ret == 1) {
>   /* txmsg is sent it should be in the slots now */
> + mgr->is_waiting_for_dwn_reply = true;
>   list_del(&txmsg->next);
>   } else if (ret) {
>   DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> + mgr->is_waiting_for_dwn_reply = false;
>   list_del(&txmsg->next);
>   if (txmsg->seqno != -1)
>   txmsg->dst->tx_slots[txmsg->seqno] = NULL; @@ -2812,7 
> +2817,8 @@ 
> static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
>   drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
>   }
>  
> - if (list_is_singular(&mgr->tx_msg_downq))
> + if (list_is_singular(&mgr->tx_msg_downq) &&
> + !mgr->is_waiting_for_dwn_reply)
>   process_single_down_tx_qlock(mgr);
>   mutex_unlock(&mgr->qlock);
>  }
> @@ -3743,6 +3749,7 @@ static int drm_dp_mst_handle_down_rep(struct 
> drm_dp_mst_topology_mgr *mgr)
>   mutex_lock(&mgr->qlock);
>   txmsg->state = DRM_DP_SIDEBAND_TX_RX;
>   mstb->tx_slots[slot] = NULL;
> + mgr->is_waiting_for_dwn_reply = false;
>   mutex_unlock(&mgr->qlock);
>  
>   wake_up_all(&mgr->tx_waitq);
> @@ -3752,6 +3759,9 @@ static int drm_dp_mst_handle_down_rep(struct 
>

RE: [PATCH 1/2] drm/dp_mst: Add a function to determine the mst end device

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, January 15, 2020 5:16 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry 
> Subject: Re: [PATCH 1/2] drm/dp_mst: Add a function to determine the mst end
> device
> 
> This patch series looks awesome so far, thank you for the great work! This
> patch looks great, I think we should just squash it into the next patch though
> since we don't use this function until then.
> 
Thanks for your time.
I will squash it in the new version.

> On Wed, 2020-01-08 at 16:44 +0800, Wayne Lin wrote:
> > [Why]
> > For later usage convenience, add the function
> > drm_dp_mst_is_dp_mst_end_device() to decide whether a peer device
> > connected to a DFP is mst end device. Which also indicates if the peer
> > device is capable of handling message or not.
> >
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index eebf325d7f48..8f54b241db08 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1918,6 +1918,22 @@ static u8 drm_dp_calculate_rad(struct
> > drm_dp_mst_port *port,
> > return parent_lct + 1;
> >  }
> >
> > +static bool drm_dp_mst_is_dp_mst_end_device(u8 pdt, bool mcs) {
> > +   switch (pdt) {
> > +   case DP_PEER_DEVICE_DP_LEGACY_CONV:
> > +   case DP_PEER_DEVICE_SST_SINK:
> > +   return true;
> > +   case DP_PEER_DEVICE_MST_BRANCHING:
> > +   /* For sst branch device */
> > +   if (!mcs)
> > +   return true;
> > +
> > +   return false;
> > +   }
> > +   return true;
> > +}
> > +
> >  static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8
> > new_pdt)  {
> > struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> --
> Cheers,
>   Lyude Paul
--
Best regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/2] drm/dp_mst: Handle SST-only branch device case

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, January 15, 2020 5:19 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry ; Ville Syrjälä
> ; Wentland, Harry 
> Subject: Re: [PATCH 2/2] drm/dp_mst: Handle SST-only branch device case
> 
> On Wed, 2020-01-08 at 16:44 +0800, Wayne Lin wrote:
> > [Why]
> > While handling LINK_ADDRESS reply, current code expects a peer device
> > can handle sideband message once the peer device type is reported as
> > DP_PEER_DEVICE_MST_BRANCHING. However, when the connected device
> is a
> > SST branch case, it can't handle the sideband message(MST_CAP=0 in
> > DPCD 00021h).
> >
> > Current code will try to send LINK_ADDRESS to SST branch device and
> > end up with message timeout and monitor can't display normally. As the
> > result of that, we should take SST branch device into account.
> >
> > [How]
> > According to DP 1.4 spec, we can use Peer_Device_Type as
> > DP_PEER_DEVICE_MST_BRANCHING and Message_Capability_Status as 0 to
> > indicate peer device as a SST-only branch device.
> >
> > Fix following:
> > - Take SST-only branch device case into account in
> > drm_dp_port_set_pdt() and add a new parameter 'new_mcs'. Take sst
> > branch device case as the same case as
> DP_PEER_DEVICE_DP_LEGACY_CONV
> > and DP_PEER_DEVICE_SST_SINK. All original handling logics remain.
> > - Take SST-only branch device case into account in
> > drm_dp_mst_port_add_connector().
> > - Fix some parts in drm_dp_mst_handle_link_address_port() to have SST
> > branch device case into consideration.
> > - Fix the arguments of drm_dp_port_set_pdt() in
> > drm_dp_mst_handle_conn_stat().
> > - Have SST branch device also report
> > connector_status_connected when the ddps is true in
> > drm_dp_mst_detect_port()
> > - Fix the arguments of drm_dp_port_set_pdt() in
> > drm_dp_delayed_destroy_port()
> >
> > Fixes: c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add
> > more
> > locking")
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Cc: Lyude Paul 
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 131
> > +-
> >  1 file changed, 68 insertions(+), 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 8f54b241db08..4395d5cc0645 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1934,73 +1934,74 @@ static bool
> drm_dp_mst_is_dp_mst_end_device(u8
> > pdt, bool mcs)
> > return true;
> >  }
> >
> > -static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8
> > new_pdt)
> > +static int
> > +drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt,
> > +   bool new_mcs)
> >  {
> > struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> > struct drm_dp_mst_branch *mstb;
> > u8 rad[8], lct;
> > int ret = 0;
> >
> > -   if (port->pdt == new_pdt)
> > +   if (port->pdt == new_pdt && port->mcs == new_mcs)
> > return 0;
> >
> > /* Teardown the old pdt, if there is one */
> > -   switch (port->pdt) {
> > -   case DP_PEER_DEVICE_DP_LEGACY_CONV:
> > -   case DP_PEER_DEVICE_SST_SINK:
> > -   /*
> > -* If the new PDT would also have an i2c bus, don't bother
> > -* with reregistering it
> > -*/
> > -   if (new_pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
> > -   new_pdt == DP_PEER_DEVICE_SST_SINK) {
> > -   port->pdt = new_pdt;
> > -   return 0;
> > -   }
> > +   if (port->pdt != DP_PEER_DEVICE_NONE) {
> > +   if (drm_dp_mst_is_dp_mst_end_device(port->pdt, port->mcs)) {
> > +   /*
> > +* If the new PDT would also have an i2c bus,
> > +* don't bother with reregistering it
> > +*/
> > +   if (new_pdt != DP_PEER_DEVICE_NONE &&
> > +   drm_dp_mst_is_dp_mst_end_device(new_pdt, new_mcs))
> > {
> > +   port->pdt = new_pdt;
> > +   port->mcs = new_mcs;
> > +   return 0;
&

RE: [PATCH] drm/dp_mst: Have DP_Tx send one msg at a time

[Lin, Wayne]

[AMD Public Use]

Appreciate for your time.
Thanks!

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, January 16, 2020 5:58 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry 
> Subject: Re: [PATCH] drm/dp_mst: Have DP_Tx send one msg at a time
> 
> Reviewed-by: Lyude Paul 
> 
> I will push this to drm-misc-fixes in just a moment, thanks!
> 
> On Mon, 2020-01-13 at 17:36 +0800, Wayne Lin wrote:
> > [Why]
> > Noticed this while testing MST with the 4 ports MST hub from
> > StarTech.com. Sometimes can't light up monitors normally and get the
> > error message as 'sideband msg build failed'.
> >
> > Look into aux transactions, found out that source sometimes will send
> > out another down request before receiving the down reply of the
> > previous down request. On the other hand, in drm_dp_get_one_sb_msg(),
> > current code doesn't handle the interleaved replies case. Hence,
> > source can't build up message completely and can't light up monitors.
> >
> > [How]
> > For good compatibility, enforce source to send out one down request at
> > a time. Add a flag, is_waiting_for_dwn_reply, to determine if the
> > source can send out a down request immediately or not.
> >
> > - Check the flag before calling process_single_down_tx_qlock to send
> > out a msg
> > - Set the flag when successfully send out a down request
> > - Clear the flag when successfully build up a down reply
> > - Clear the flag when find erros during sending out a down request
> > - Clear the flag when find errors during building up a down reply
> > - Clear the flag when timeout occurs during waiting for a down reply
> > - Use drm_dp_mst_kick_tx() to try to send another down request in
> > queue at the end of drm_dp_mst_wait_tx_reply() (attempt to send out
> > messages in queue when errors occur)
> >
> > Cc: Lyude Paul 
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
> >  include/drm/drm_dp_mst_helper.h   |  6 ++
> >  2 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 4395d5cc0645..3542af15387a 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1195,6 +1195,8 @@ static int drm_dp_mst_wait_tx_reply(struct
> > drm_dp_mst_branch *mstb,
> > txmsg->state == DRM_DP_SIDEBAND_TX_SENT) {
> > mstb->tx_slots[txmsg->seqno] = NULL;
> > }
> > +   mgr->is_waiting_for_dwn_reply = false;
> > +
> > }
> >  out:
> > if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) { @@
> > -1204,6 +1206,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> > drm_dp_mst_branch *mstb,
> > }
> > mutex_unlock(&mgr->qlock);
> >
> > +   drm_dp_mst_kick_tx(mgr);
> > return ret;
> >  }
> >
> > @@ -2770,9 +2773,11 @@ static void process_single_down_tx_qlock(struct
> > drm_dp_mst_topology_mgr *mgr)
> > ret = process_single_tx_qlock(mgr, txmsg, false);
> > if (ret == 1) {
> > /* txmsg is sent it should be in the slots now */
> > +   mgr->is_waiting_for_dwn_reply = true;
> > list_del(&txmsg->next);
> > } else if (ret) {
> > DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> > +   mgr->is_waiting_for_dwn_reply = false;
> > list_del(&txmsg->next);
> > if (txmsg->seqno != -1)
> > txmsg->dst->tx_slots[txmsg->seqno] = NULL; @@ -2812,7
> +2817,8 @@
> > static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
> > drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> > }
> >
> > -   if (list_is_singular(&mgr->tx_msg_downq))
> > +   if (list_is_singular(&mgr->tx_msg_downq) &&
> > +   !mgr->is_waiting_for_dwn_reply)
> > process_single_down_tx_qlock(mgr);
> > mutex_unlock(&mgr->qlock);
> >  }
> > @@ -3743,6 +3749,7 @@ static int drm_dp_mst_handle_down_rep(struct
> > drm_dp_mst_topology_mgr *mgr)
> > mutex_lock(&mgr->qlock);
> > txmsg->state = DRM_DP_SIDEBAND_TX_RX;
> > mstb->tx_slots[slot] = NULL;
> > +

RE: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology mgr

[Lin, Wayne]

[AMD Public Use]

Sorry for any inconvenience I brought.
Thank you so much Lyude, I will have a look on that fix patch later.

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, January 18, 2020 4:45 AM
> To: Sean Paul 
> Cc: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org; Zuo, Jerry ; Kazlauskas,
> Nicholas ; sta...@vger.kernel.org
> Subject: Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology
> mgr
> 
> Yeah that's fine with me, I'll send out a revert for this in just a moment
> 
> On Fri, 2020-01-17 at 15:43 -0500, Sean Paul wrote:
> > On Fri, Jan 17, 2020 at 3:27 PM Lyude Paul  wrote:
> > > On Fri, 2020-01-17 at 11:19 -0500, Sean Paul wrote:
> > > > On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne 
> wrote:
> > > > >
> > > > > > -Original Message-----
> > > > > > From: Lyude Paul 
> > > > > > Sent: Saturday, December 7, 2019 3:57 AM
> > > > > > To: Lin, Wayne ;
> > > > > > dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > > > > > Cc: Kazlauskas, Nicholas ;
> > > > > > Wentland, Harry ; Zuo, Jerry
> > > > > > ; sta...@vger.kernel.org
> > > > > > Subject: Re: [PATCH v2] drm/dp_mst: Remove VCPI while
> > > > > > disabling topology mgr
> > > > > >
> > > > > > On Fri, 2019-12-06 at 14:24 -0500, Lyude Paul wrote:
> > > > > > > Reviewed-by: Lyude Paul 
> > > > > > >
> > > > > > > I'll go ahead and push this to drm-misc-next-fixes right
> > > > > > > now, thanks!
> > > > > >
> > > > > > Whoops-meant to say drm-misc-next here, anyway, pushed!
> > > > > Thanks for your time!
> > > > >
> > > >
> > > > I'm getting the following warning on unplug with this patch:
> > > >
> >
> > \snip
> >
> > > I think I've got a better fix for this that should avoid that
> > > problem, I'll write up a patch and send it out in a bit
> >
> > Thanks Lyude! Should we revert this patch for the time being?
> >
> > > --
> > > Cheers,
> > > Lyude Paul
> > >
> --
> Cheers,
>   Lyude Paul
--
Best regards,
Wayne
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/dp_mst: Fix clearing payload state on topology disable

[Lin, Wayne]

[AMD Official Use Only - Internal Distribution Only]

Hi Lyude,

I also notice one thing that I was not aware of before. Since we're clearing 
payloads here, maybe we should also call drm_dp_mst_put_port_malloc() to put 
malloc refcounts here?

Appreciate for all your help! :)


From: Lyude Paul 
Sent: Thursday, January 23, 2020 07:43
To: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org; Sean Paul; Lin, Wayne; Maarten Lankhorst; 
Maxime Ripard; David Airlie; Daniel Vetter; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v2 1/2] drm/dp_mst: Fix clearing payload state on topology 
disable

On Wed, 2020-01-22 at 22:51 +0200, Ville Syrjälä wrote:
> On Wed, Jan 22, 2020 at 02:43:20PM -0500, Lyude Paul wrote:
> > The issues caused by:
> >
> > 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr")
> >
> > Prompted me to take a closer look at how we clear the payload state in
> > general when disabling the topology, and it turns out there's actually
> > two subtle issues here.
> >
> > The first is that we're not grabbing &mgr.payload_lock when clearing the
> > payloads in drm_dp_mst_topology_mgr_set_mst(). Seeing as the canonical
> > lock order is &mgr.payload_lock -> &mgr.lock (because we always want
> > &mgr.lock to be the inner-most lock so topology validation always
> > works), this makes perfect sense. It also means that -technically- there
> > could be racing between someone calling
> > drm_dp_mst_topology_mgr_set_mst() to disable the topology, along with a
> > modeset occurring that's modifying the payload state at the same time.
> >
> > The second is the more obvious issue that Wayne Lin discovered, that
> > we're not clearing proposed_payloads when disabling the topology.
> >
> > I actually can't see any obvious places where the racing caused by the
> > first issue would break something, and it could be that some of our
> > higher-level locks already prevent this by happenstance, but better safe
> > then sorry. So, let's make it so that drm_dp_mst_topology_mgr_set_mst()
> > first grabs &mgr.payload_lock followed by &mgr.lock so that we never
> > race when modifying the payload state. Then, we also clear
> > proposed_payloads to fix the original issue of enabling a new topology
> > with a dirty payload state. This doesn't clear any of the drm_dp_vcpi
> > structures, but those are getting destroyed along with the ports anyway.
> >
> > Changes since v1:
> > * Use sizeof(mgr->payloads[0])/sizeof(mgr->proposed_vcpis[0]) instead -
> >   vsyrjala
> >
> > Cc: Sean Paul 
> > Cc: Wayne Lin 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Lyude Paul 
> > ---
> >  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 3649e82b963d..23cf46bfef74 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3501,6 +3501,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > drm_dp_mst_topology_mgr *mgr, bool ms
> > int ret = 0;
> > struct drm_dp_mst_branch *mstb = NULL;
> >
> > +   mutex_lock(&mgr->payload_lock);
> > mutex_lock(&mgr->lock);
> > if (mst_state == mgr->mst_state)
> > goto out_unlock;
> > @@ -3559,7 +3560,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > drm_dp_mst_topology_mgr *mgr, bool ms
> > /* this can fail if the device is gone */
> > drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
> > ret = 0;
> > -   memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct
> > drm_dp_payload));
> > +   memset(mgr->payloads, 0,
> > +  mgr->max_payloads * sizeof(mgr->payloads[0]));
> > +   memset(mgr->proposed_vcpis, 0,
> > +  mgr->max_payloads * sizeof(mgr->proposed_vcpis[0]));
> > mgr->payload_mask = 0;
> > set_bit(0, &mgr->payload_mask);
> > mgr->vcpi_mask = 0;
> > @@ -3568,6 +3572,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > drm_dp_mst_topology_mgr *mgr, bool ms
> >
> >  out_unlock:
> > mutex_unlock(&mgr->lock);
> > +   mutex_unlock(&mgr->payload_lock);
>
> Locking order looks sane. Not entirely sure what the implications of
> clearing all that stuff outside of a proper mode

RE: [PATCH] drm/amd/dm/mst: Ignore payload update failures on disable

[Lin, Wayne]

[AMD Public Use]

Hi Lyude,

Thanks for the patch!
I'm wondering if this error still occurs with this patch applied
https://patchwork.kernel.org/patch/11274363/
I tried to clean up all mgr->proposed_vcpis[] in this patch so
drm_dp_update_payload_part1() will skip all invalid ports.

However, I'm also thinking to improve this patch.
Maybe it is better to do cleaning proposed_vcpis[] in 
dm_helpers_dp_mst_write_payload_allocation_table() due to
it is the actual place that DC try to update the status for a specific 
VC stream. If it's reasonable then I'll do that in the future :)

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, January 25, 2020 2:57 AM
> To: Lipski, Mikita ; Wentland, Harry
> ; amd-...@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Wentland, Harry ; Li,
> Sun peng (Leo) ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
> ; Lakha, Bhawanpreet ;
> Lipski, Mikita ; Sam Ravnborg ;
> David Francis ; Tsai, Martin
> ; Chris Wilson ; Lee, Alvin
> ; Jean Delvare ;
> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Lin, Wayne
> 
> Subject: Re: [PATCH] drm/amd/dm/mst: Ignore payload update failures on
> disable
> 
> 
> 
> On Fri, 2020-01-24 at 11:39 -0500, Mikita Lipski wrote:
> >
> > On 1/24/20 9:55 AM, Harry Wentland wrote:
> > > On 2020-01-23 7:06 p.m., Lyude Paul wrote:
> > > > Disabling a display on MST can potentially happen after the entire
> > > > MST topology has been removed, which means that we can't
> > > > communicate with the topology at all in this scenario. Likewise,
> > > > this also means that we can't properly update payloads on the
> > > > topology and as such, it's a good idea to ignore payload update failures
> when disabling displays.
> > > > Currently, amdgpu makes the mistake of halting the payload update
> > > > process when any payload update failures occur, resulting in
> > > > leaving DC's local copies of the payload tables out of date.
> > > >
> > > > This ends up causing problems with hotplugging MST topologies, and
> > > > causes modesets on the second hotplug to fail like so:
> > > >
> > > > [drm] Failed to updateMST allocation table forpipe idx:1
> > > > [ cut here ]
> > > > WARNING: CPU: 5 PID: 1511 at
> > > > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677
> > > > update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked
> > > > in: cdc_ether usbnet fuse xt_conntrack nf_conntrack
> > > > nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4
> > > > nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc
> > > > sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek
> > > > snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc
> > > > snd_hda_intel videobuf2_memops
> > > > videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul
> > > > snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core
> > > > ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device
> > > > snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi
> > > > ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq
> > > > ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched
> mmc_core
> > > > i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt
> > > > fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152
> > > > mii nvme r8169 nvme_core rtsx_pci pinctrl_amd
> > > > CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G   O
> 5.5.0-
> > > > rc7Lyude-Test+ #4
> > > > Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS
> R12ET22W(0.22 )
> > > > 01/31/2019
> > > > RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu]
> > > > Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f
> > > > b6 06
> > > > 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f>
> > > > 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00
> > > > RSP: 0018:ac428127f5b0 EFLAGS: 00010202
> > > > RAX: 0002 RBX: 8d1e166eee80 RCX:
> 
> > > > RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610
> > > > RBP: ac428127f640 R08: c03d94a8 R09: 
> > > > R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1

RE: [PATCH] drm/dp_mst: Convert drm_dp_mst_topology_mgr.is_waiting_for_dwn_reply to bitfield

[Lin, Wayne]

[AMD Public Use]

Reviewed-by: Wayne Lin 

Thanks!

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, January 23, 2020 3:49 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Lin, Wayne ; Maarten Lankhorst
> ; Maxime Ripard ;
> David Airlie ; Daniel Vetter ;
> linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/dp_mst: Convert
> drm_dp_mst_topology_mgr.is_waiting_for_dwn_reply to bitfield
> 
> Small nitpick that I noticed a second ago - we can save some space in the
> struct by making this a bitfield and sticking it with the rest of the 
> bitfields. Also,
> some small cleanup to the kdocs for this member.
> 
> There should be no functional changes in this patch.
> 
> Signed-off-by: Lyude Paul 
> Cc: Wayne Lin 
> ---
>  include/drm/drm_dp_mst_helper.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drm_dp_mst_helper.h
> b/include/drm/drm_dp_mst_helper.h index bcb39da9adb4..58bbab3684b5
> 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -590,6 +590,11 @@ struct drm_dp_mst_topology_mgr {
>*/
>   bool payload_id_table_cleared : 1;
> 
> + /**
> +  * @is_waiting_for_dwn_reply: whether we're waiting for a down reply.
> +  */
> + bool is_waiting_for_dwn_reply : 1;
> +
>   /**
>* @mst_primary: Pointer to the primary/first branch device.
>*/
> @@ -619,11 +624,6 @@ struct drm_dp_mst_topology_mgr {
>*/
>   struct mutex qlock;
> 
> - /**
> -  * @is_waiting_for_dwn_reply: indicate whether is waiting for down
> reply
> -  */
> - bool is_waiting_for_dwn_reply;
> -
>   /**
>* @tx_msg_downq: List of pending down replies.
>*/
> --
> 2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI 2.0

[Lin, Wayne]

From: Ville Syrjälä 
Sent: Wednesday, October 2, 2019 19:58
To: Lin, Wayne 
Cc: dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org ; Li, Sun peng 
(Leo) ; Kazlauskas, Nicholas 
Subject: Re: [PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI 2.0

On Tue, Sep 24, 2019 at 01:26:21PM +0800, Wayne Lin wrote:
> In HDMI 1.4 defines 4k modes without specific aspect ratio.
> However, in HDMI 2.0, adds aspect ratio attribute to distinguish different
> 4k modes.
>
> According to Appendix E of HDMI 2.0 spec, source should use VSIF to
> indicate VIC mode only when the mode is one defined in HDMI 1.4b 4K modes.
> Otherwise, use AVI infoframes to convey VIC.
>
> eg: VIC_103 should use AVI infoframes and VIC_93 use VSIF
>
> When the sink is HDMI 2.0, current code in
> drm_hdmi_avi_infoframe_from_display_mode will also force mode VIC_103 to
> have VIC value 0. This violates the spec and needs to be corrected.

> Where is that being done? We only set the AVI VIC to zero if we're going
> to use the HDMI VIC instead.

Appreciate for your time and apologize for not explaining it clearly.
Current code in drm_hdmi_avi_infoframe_from_display_mode() will call
drm_match_hdmi_mode() to set up vendor_if_vic. By checking
drm_valid_hdmi_vic(vendor_if_vic) to see if the vic info should be conveyed by 
avi
or not.

But in drm_match_hdmi_mode(), code doesn't enable match_flags with
DRM_MODE_MATCH_ASPECT_RATIO. I think it's due to HDMI1.4b doesn't specify
4K mode conveyed by HDMI VIC with particular aspect ratio. But in Appendix E of
HDMI 2.0 spec, it specify only 4k modes with particular aspect ratio should use 
VSIF to convey.
Hence, when the sink support HDMI 2.0 and set the mode to be VIC_103, calling
drm_match_hdmi_mode(mode) will return vendor_if_vic = 3 (VIC_93 and VIC_103 are 
having
the same timing but different aspect ratio). Thereafter will set the  
frame->video_code to 0.
However, VIC_103 should use AVI VIC according to HDMI 2.0 spec (only VIC: 93, 
94, 95 &
98 should use VSIF).

This patch try to revise that, when the sink support HDMI 2.0, 
drm_match_hdmi_mode()
should also take aspect ratio into consideration.
But for easy reading, I add another function "drm_match_hdmi_1_4_mode" to do so.

> The same situation occurs in drm_hdmi_vendor_infoframe_from_display_mode
> and should set HDMI_VIC when the mode is one defined in HDMI 1.4b 4K
> modes.

> Yes, and we do that. "vic = drm_match_hdmi_mode(mode);"

> Apart from adding the aspect ratios I don't really understand what
> you're trying to achieve here.

For HDMI 2.0 sink, drm_match_hdmi_mode() should also take aspect ratio into 
consideration.
Once again, very appreciate for your time.

> ---
>  drivers/gpu/drm/drm_edid.c | 95 --
>  1 file changed, 92 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 649cfd8b4200..0fea9bf4ec67 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1306,6 +1306,37 @@ static const struct drm_display_mode edid_4k_modes[] = 
> {
>  .vrefresh = 24, },
>  };
>
> +/*
> + * 4k modes of HDMI 1.4 defined in HDMI 2.0. Index using the VIC.
> + */
> +static const struct drm_display_mode hdmi_1_4_edid_4k_modes[] = {
> + /* 0 - dummy, VICs start at 1 */
> + { },
> + /* 1 - 3840x2160@30Hz */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
> +3840, 4016, 4104, 4400, 0,
> +2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 2 - 3840x2160@25Hz */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
> +3840, 4896, 4984, 5280, 0,
> +2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 3 - 3840x2160@24Hz */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
> +3840, 5116, 5204, 5500, 0,
> +2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 4 - 4096x2160@24Hz (SMPTE) */
> + { DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 297000,
> +4096, 5116, 5204, 5500, 0,
> +2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135, 
> }

RE: [PATCH V2 1/2] drm/edid: Add aspect ratios to HDMI 4K modes

[Lin, Wayne]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Friday, November 29, 2019 11:09 PM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Subject: Re: [PATCH V2 1/2] drm/edid: Add aspect ratios to HDMI 4K modes
> 
> On Mon, Nov 18, 2019 at 06:18:31PM +0800, Wayne Lin wrote:
> > [Why]
> > HDMI 2.0 adds aspect ratio attribute to distinguish different 4k
> > modes. According to Appendix E of HDMI 2.0 spec, source should use
> > VSIF to indicate video mode only when the mode is one defined in HDMI
> > 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC.
> >
> > Current code doesn't take aspect ratio into consideration while
> > constructing avi infoframe. Should modify that.
> >
> > [How]
> > Inherit Ville Syrjälä's work
> > "drm/edid: Prep for HDMI VIC aspect ratio" at
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fpatch%2F11174639%2F&data=02%7C01%7CWayne.L
> in%40
> >
> amd.com%7C1fbbc9d617234af5f3d408d774de0a7c%7C3dd8961fe4884e608e1
> 1a82d9
> >
> 94e183d%7C0%7C0%7C637106369315352334&sdata=QPW9CnwgPkl2DIn
> bymfaYT%
> > 2F6jxdmVaTMKEMN69VBFcQ%3D&reserved=0
> >
> > Add picture_aspect_ratio attributes to edid_4k_modes[] and construct
> > VIC and HDMI_VIC by taking aspect ratio into consideration.
> >
> > v2: Correct missing initializer error at adding aspect ratio of SMPTE
> > mode.
> >
> > Signed-off-by: Wayne Lin 
> 
> Our CI didn't complain about anything that looked relevant, so I went ahead an
> pushed these to drm-misc-next.
> 
> Thanks for the patches.

Many thanks for your time.
> 
> --
> Ville Syrjälä
> Intel

--
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/dp_mst: Correct the bug in drm_dp_update_payload_part1()

[Lin, Wayne]

> -Original Message-
> From: Lyude Paul 
> Sent: Tuesday, December 3, 2019 8:23 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry 
> Subject: Re: [PATCH] drm/dp_mst: Correct the bug in
> drm_dp_update_payload_part1()
> 
> On Mon, 2019-12-02 at 11:58 +0800, Wayne Lin wrote:
> > [Why]
> > If the payload_state is DP_PAYLOAD_DELETE_LOCAL in series, current
> > code doesn't delete the payload at current index and just move the
> > index to next one after shuffling payloads.
> >
> > [How]
> > After shuffling payloads, decide whether to move on index or not
> > according to payload_state of current payload.
> >
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 81e92b260d7a..8da5d461ea01 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3176,7 +3176,8 @@ int drm_dp_update_payload_part1(struct
> > drm_dp_mst_topology_mgr *mgr)
> > drm_dp_mst_topology_put_port(port);
> > }
> >
> > -   for (i = 0; i < mgr->max_payloads; i++) {
> > +   for (i = 0; i < mgr->max_payloads;
> > +   (mgr->payloads[i].payload_state == DP_PAYLOAD_DELETE_LOCAL) ?
> > i : i++) {
> 
> Took me a moment to figure out what this line was actually doing. Nice catch
> by the way!
> 
> Anyway: let's just drop this line to avoid making things confusing to read, 
> drop
> i++ from the for loop instead, and just rewrite it so it looks like this:
> 
> for (i = 0; i < mgr->max_payloads; /* do nothing */) {
>   if (mgr->payloads[i].payload_state != DP_PAYLOAD_DELETE_LOCAL) {
>   i++;
>   continue;
>   }
> 
> With those changes, this patch is:
> 
> Reviewed-by: Lyude Paul 
> 

Thanks for your time and sorry for not well organized code.
I will send you the v2 right away. Thanks!
 
> I can go ahead and push these patches to drm-misc for you once you've sent
> me the v2
> > if (mgr->payloads[i].payload_state != DP_PAYLOAD_DELETE_LOCAL)
> > continue;
> >
> --
> Cheers,
>   Lyude Paul
--
BR,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/dp_mst: Remove VCPI while disabling topology mgr

[Lin, Wayne]

> -Original Message-
> From: Lyude Paul 
> Sent: Tuesday, December 3, 2019 8:03 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry 
> Subject: Re: [PATCH] drm/dp_mst: Remove VCPI while disabling topology mgr
> 
> I'm, not entirely sure what this patch is trying to accomplish. I'm guessing
> maybe we're leaving stale VCPI allocations from the previous topology
> enablement and then somehow trying to use those again when allocating
> payloads? The patch looks correct at least.
> 
Thanks for your time and the comment.

Yes, this patch is trying to address the problem you mentioned.
Once unplug a DP MST capable device, driver will call 
drm_dp_mst_topology_mgr_set_mst() to reset mgr->payloads but it doesn't
reset the mgr->proposed_vcpis. If it doesn't reset the proposed_vcpi, code will
fail at checking port validation once plug in MST device later. 
Once MST capable device plug in again and try to allocate payloads by calling
drm_dp_update_payload_part1(), this function will iterate over all proposed
virtual channels and check each port validation to see if the specified port is 
still
in the topology. Since there are stale VCPI allocations from the previous 
topology
enablement in proposed_vcpi[], code flow will fail and reurn EINVAL.

> If this patch is fixing an issue, such as displays not turning on with 
> amdgpu, I'd
> definitely mention it in more detail here and Cc to stable if applicable.

Thanks for your comment. I will Cc to sta...@vger.kernel.org and amend the 
message in more detail in next version.

> Also, one nitpick below:

Thanks, I'll modify it.
> 
> On Mon, 2019-12-02 at 11:57 +0800, Wayne Lin wrote:
> > [Why]
> > While disabling mst topology manager in
> > drm_dp_mst_topology_mgr_set_mst(), now just reset the mgr->payloads
> > but doesn't handle the mgr->proposed_vcpis.
> >
> > [How]
> > Remove mgr->proposed_vcpis to NULL.
> >
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index ae5809a1f19a..81e92b260d7a 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3386,6 +3386,7 @@ static int drm_dp_get_vc_payload_bw(u8
> > dp_link_bw,
> > u8  dp_link_count)
> >  int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr
> > *mgr, bool mst_state)  {
> > int ret = 0;
> > +   int i = 0;
> > struct drm_dp_mst_branch *mstb = NULL;
> >
> > mutex_lock(&mgr->lock);
> > @@ -3446,10 +3447,21 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > drm_dp_mst_topology_mgr *mgr, bool ms
> > /* this can fail if the device is gone */
> > drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
> > ret = 0;
> > +   mutex_lock(&mgr->payload_lock);
> > memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct
> > drm_dp_payload));
> > mgr->payload_mask = 0;
> > set_bit(0, &mgr->payload_mask);
> > +   for (i = 0; i < mgr->max_payloads; i++) {
> > +   struct drm_dp_vcpi *tmp_vcpi = mgr->proposed_vcpis[i];
> > +
> > +   if (tmp_vcpi) {
> > +   tmp_vcpi->vcpi = 0;
> > +   tmp_vcpi->num_slots = 0;
> > +   }
> > +   mgr->proposed_vcpis[i] = NULL;
> > +   }
> > mgr->vcpi_mask = 0;
> > +   mutex_unlock(&mgr->payload_lock);
> 
> bikeshed: I'd just rename tmp_vcpi here to vcpi, but I'll leave that up to you
> > }
> >
> >  out_unlock:
> --
> Cheers,
>   Lyude Paul
--
BR,
Wayne Lin

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology mgr

[Lin, Wayne]

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, December 7, 2019 3:57 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology
> mgr
> 
> On Fri, 2019-12-06 at 14:24 -0500, Lyude Paul wrote:
> > Reviewed-by: Lyude Paul 
> >
> > I'll go ahead and push this to drm-misc-next-fixes right now, thanks!
> 
> Whoops-meant to say drm-misc-next here, anyway, pushed!
Thanks for your time!

> >
> > On Thu, 2019-12-05 at 17:00 +0800, Wayne Lin wrote:
> > > [Why]
> > >
> > > This patch is trying to address the issue observed when hotplug DP
> > > daisy chain monitors.
> > >
> > > e.g.
> > > src-mstb-mstb-sst -> src (unplug) mstb-mstb-sst -> src-mstb-mstb-sst
> > > (plug in again)
> > >
> > > Once unplug a DP MST capable device, driver will call
> > > drm_dp_mst_topology_mgr_set_mst() to disable MST. In this function,
> > > it cleans data of topology manager while disabling mst_state.
> > > However, it doesn't clean up the proposed_vcpis of topology manager.
> > > If proposed_vcpi is not reset, once plug in MST daisy chain monitors
> > > later, code will fail at checking port validation while trying to
> > > allocate payloads.
> > >
> > > When MST capable device is plugged in again and try to allocate
> > > payloads by calling drm_dp_update_payload_part1(), this function
> > > will iterate over all proposed virtual channels to see if any
> > > proposed VCPI's num_slots is greater than 0. If any proposed VCPI's
> > > num_slots is greater than 0 and the port which the specific virtual
> > > channel directed to is not in the topology, code then fails at the
> > > port validation. Since there are stale VCPI allocations from the
> > > previous topology enablement in proposed_vcpi[], code will fail at
> > > port validation and reurn EINVAL.
> > >
> > > [How]
> > >
> > > Clean up the data of stale proposed_vcpi[] and reset
> > > mgr->proposed_vcpis to NULL while disabling mst in
> drm_dp_mst_topology_mgr_set_mst().
> > >
> > > Changes since v1:
> > > *Add on more details in commit message to describe the issue which
> > > the patch is trying to fix
> > >
> > > Signed-off-by: Wayne Lin 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 12 
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index ae5809a1f19a..bf4f745a4edb 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -3386,6 +3386,7 @@ static int drm_dp_get_vc_payload_bw(u8
> > > dp_link_bw,
> > > u8  dp_link_count)
> > >  int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr
> > > *mgr, bool mst_state)  {
> > >   int ret = 0;
> > > + int i = 0;
> > >   struct drm_dp_mst_branch *mstb = NULL;
> > >
> > >   mutex_lock(&mgr->lock);
> > > @@ -3446,10 +3447,21 @@ int
> drm_dp_mst_topology_mgr_set_mst(struct
> > > drm_dp_mst_topology_mgr *mgr, bool ms
> > >   /* this can fail if the device is gone */
> > >   drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
> > >   ret = 0;
> > > + mutex_lock(&mgr->payload_lock);
> > >   memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct
> > > drm_dp_payload));
> > >   mgr->payload_mask = 0;
> > >   set_bit(0, &mgr->payload_mask);
> > > + for (i = 0; i < mgr->max_payloads; i++) {
> > > + struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
> > > +
> > > + if (vcpi) {
> > > + vcpi->vcpi = 0;
> > > + vcpi->num_slots = 0;
> > > + }
> > > + mgr->proposed_vcpis[i] = NULL;
> > > + }
> > >   mgr->vcpi_mask = 0;
> > > + mutex_unlock(&mgr->payload_lock);
> > >   }
> > >
> > >  out_unlock:
> --
> Cheers,
>   Lyude Paul

--
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_connector: add additional aspect ratio values

[Lin, Wayne]

From: Ville Syrjälä 
Sent: Saturday, August 24, 2019 02:41
To: Lin, Wayne 
Cc: dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org ; Li, Sun peng 
(Leo) ; Kazlauskas, Nicholas 
Subject: Re: [PATCH] drm/drm_connector: add additional aspect ratio values

On Thu, Aug 22, 2019 at 05:50:02PM -0400, Wayne Lin wrote:
> For HDMI2.0 CTS item - HF1-35, it verifies if the source generates
> video timing "64:27" video format correctly.
>
> eg: (vic-76) 1920x1080p@60Hz,24bpp
>
> This patch add on "64:27" and "256:135" to drm_aspect_ratio_enum_list.
> Thereafter, one can specify the aspect ratio to "64:27" or "256:135"
> after creating aspect ratio property.
>
> Change-Id: Ifc9df54e8e8f78e70960fcd737a3a57e49c81152
> Signed-off-by: Wayne Lin 
> ---
>  drivers/gpu/drm/drm_connector.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 3a0cacb71235..c0629a01d08e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -772,6 +772,8 @@ static const struct drm_prop_enum_list 
> drm_aspect_ratio_enum_list[] = {
>{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
>{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
>{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
> + { DRM_MODE_PICTURE_ASPECT_64_27, "64:27" },
> + { DRM_MODE_PICTURE_ASPECT_256_135, "256:135" },

> Not 100% sure we want to expose these via the property because the
> infoframe can't convey these independently from the VIC.

Agree with that it can't be independent from the VIC.
When building up hdmi avi infoframe by using 
"drm_hdmi_avi_infoframe_from_display_mode" in drm_edid,
it will refer to the VIC to set up the aspect ratio if the aspect ratio is not 
specified in mode.
However, if the aspect ratio is specified to a value other than none, current 
logic of code will use the specified value.

The main reason of this patch is for capable indicating the exact VIC wanted.
There are some modes defined in CTA-861 with same timing but different aspect 
ratio.
eg: VIC 103 & VIC 93
Without these new definitions, we cannot distinguish these different modes and 
might set a wrong VIC in AVI infoframe.

>  };
>
>  static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] Fix observed mst problems with StarTech hub

[Lin, Wayne]

[Public]

Thanks Lyude for the review!

For the 1st patch, it's trying to fix the patch
7617e9621bf2 ("drm/dp_mst: clear time slots for ports invalid").

As for the 2nd one, it's my first time to test on this hub and I not
yet know the exact regression point. I'm also not quite sure if this
regression is caused by driver or just behavior changes from upper layer.
I was thinking that this patch is just an enhancement for our mst
helper functions and should be applicable for older kernel versions.

Thanks for your time!

Regards,
Wayne

> From: Lyude Paul 
> Sent: Saturday, June 12, 2021 06:43
> To: Lin, Wayne; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas; Wentland, Harry; Zuo, Jerry; Pillai, Aurabindo
> Subject: Re: [PATCH 0/2] Fix observed mst problems with StarTech hub
>
> haha. turns out it actually was a good thing I was busy with work today,
> because I ended up testing some backports and running into the exact same MST
> bug these patches appear to fix. How convienent :)
>
> anyway-I looked over this and this looks good to me (and IMO, I like these
> fixes more then the workarounds they replace!). The one thing we do need to
> fix here though is this appears to definitely fix a regression, so we need to
> make sure we actually bisect the issue that this patch is fixing so we can add
> the appropriate Fixes: and Cc: tags so that these fixes get backported to
> earlier stable kernel versions.
>
> I definitely need this fix in asap though for my own work, so I am going to
> see if I can start bisecting this. If I manage to figure out what's breaking
> it before my workday ends today I'll just add my R-b and push this upstream,
> otherwise I'll probably just push this first thing on monday. If you see this
> message beforethen and know what kernel version introduced this issue, feel
> free to respond ;)
>
> On Fri, 2021-05-28 at 21:55 +0800, Wayne Lin wrote:
> > Use Startech 1to3 DP hub to do some mst hotplug tests and find some
> > light up issues.
> >
> > 1. ACT polling timeout:
> >Which is due to we didn't update DPCD payload table but still try
> >to send ACT and polling for "ACT Handled" bit
> > 2. Not all monitors light up:
> >Due to we wrongly set unavailable VCP ID for new streams
> >
> > Wayne Lin (2):
> >   drm/dp_mst: Do not set proposed vcpi directly
> >   drm/dp_mst: Avoid to mess up payload table by ports in stale topology
> >
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 65 ---
> >  1 file changed, 39 insertions(+), 26 deletions(-)
> >
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat

Re: [PATCH 2/2] drm/dp_mst: Avoid to mess up payload table by ports in stale topology

[Lin, Wayne]

[Public]


> From: Lyude Paul 
> Sent: Wednesday, June 16, 2021 03:44
> To: Lin, Wayne; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas; Wentland, Harry; Zuo, Jerry; Pillai, Aurabindo
> Subject: Re: [PATCH 2/2] drm/dp_mst: Avoid to mess up payload table by ports 
> in stale topology
>
> On Fri, 2021-05-28 at 21:55 +0800, Wayne Lin wrote:
> > [Why]
> > After unplug/hotplug hub from the system, userspace might start to
> > clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi()
> > to release stale VCPI of those ports which are not relating to current
> > topology, we have chane to wrongly clear active payload table entry for
> > current topology.
> >
> > E.g.
> > We have allocated VCPI 1 in current payload table and we call
> > drm_dp_mst_deallocate_vcpi() to clean VCPI 1 in stale topology. In
> > drm_dp_mst_deallocate_vcpi(), it will call drm_dp_mst_put_payload_id()
> > tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we
> > want to allocate a new payload stream, it will find ID 1 is available by
> > drm_dp_mst_assign_payload_id(). However, ID 1 is being used
> >
> > [How]
> > Check target sink is relating to current topology or not before doing
> > any payload table update.
> > Searching upward to find the target sink's relevant root branch device.
> > If the found root branch device is not the same root of current
> > topology, don't update payload table.
> >
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 29 +++
> >  1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 5fc261014a20..3d988d54df89 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -94,6 +94,9 @@ static int drm_dp_mst_register_i2c_bus(struct
> > drm_dp_mst_port *port);
> >  static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port);
> >  static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr);
> >
> > +static bool drm_dp_mst_port_downstream_of_branch(struct drm_dp_mst_port
> > *port,
> > +struct drm_dp_mst_branch
> > *branch);
> > +
> >  #define DBG_PREFIX "[dp_mst]"
> >
> >  #define DP_STR(x) [DP_ ## x] = #x
> > @@ -3360,6 +3363,7 @@ int drm_dp_update_payload_part1(struct
> > drm_dp_mst_topology_mgr *mgr)
> > struct drm_dp_mst_port *port;
> > int i, j;
> > int cur_slots = 1;
> > +   bool skip;
> >
> > mutex_lock(&mgr->payload_lock);
> > for (i = 0; i < mgr->max_payloads; i++) {
> > @@ -3374,6 +3378,14 @@ int drm_dp_update_payload_part1(struct
> > drm_dp_mst_topology_mgr *mgr)
> > port = container_of(vcpi, struct drm_dp_mst_port,
> > vcpi);
> >
> > +   mutex_lock(&mgr->lock);
> > +   skip = !drm_dp_mst_port_downstream_of_branch(port,
> > mgr->mst_primary);
> > +   mutex_unlock(&mgr->lock);
> > +
> > +   if (skip) {
> > +   DRM_DEBUG_KMS("Virtual channel %d is not in
> > current topology\n", i);
>
> sorry I totally missed this on my first look - but this is the wrong debugging
> macro (drm_dbg_kms() should be used) and as well, this patch doesn't actually
> apply because it needs to be rebased against drm-tip. Could you fix this,
> rebase the patches, and send a new version along with the fixes tags I
> mentioned earlier? You can generate them using the dim tool here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-intel.html#labeling-fixes-before-pushing
>

Thanks for your time! Will do.

> > +   continue;
> > +   }
> > /* Validated ports don't matter if we're releasing
> >  * VCPI
> >  */
> > @@ -3473,6 +3485,7 @@ int drm_dp_update_payload_part2(struct
> > drm_dp_mst_topology_mgr *mgr)
> > struct drm_dp_mst_port *port;
> > int i;
> > int ret = 0;
> > +   bool skip;
> >
> > mutex_lock(&mgr->payload_lock);
> > for (i = 0; i < mgr->max_payloads; i+

Re: [PATCH] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()

[Lin, Wayne]

[Public]

Really sorry for the mistake that I made and any inconvenience it brought.
Thanks José and Lyude.

Regards,
Wayne


> From: Lyude Paul 
> Sent: Thursday, June 17, 2021 03:47
> To: José Roberto de Souza; intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Lin, Wayne
> Subject: Re: [PATCH] drm/dp_mst: Add missing drm parameters to recently added 
> call to drm_dbg_kms()
>
> Reviewed-by: Lyude Paul 
>
> Will go ahead and push this to drm-misc-next-fixes, thanks
>
> On Wed, 2021-06-16 at 12:44 -0700, José Roberto de Souza wrote:
> > Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > ports in stale topology") added to calls to drm_dbg_kms() but it
> > missed the first parameter, the drm device breaking the build.
> >
> > Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in
> > stale topology")
> > Cc: Wayne Lin 
> > Cc: Lyude Paul 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 9ac148efd9e43..ad0795afc21cf 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3389,7 +3389,9 @@ int drm_dp_update_payload_part1(struct
> > drm_dp_mst_topology_mgr *mgr)
> > mutex_unlock(&mgr->lock);
> >
> > if (skip) {
> > -   drm_dbg_kms("Virtual channel %d is not in
> > current topology\n", i);
> > +   drm_dbg_kms(mgr->dev,
> > +   "Virtual channel %d is not in
> > current topology\n",
> > +   i);
> > continue;
> > }
> > /* Validated ports don't matter if we're releasing
> > @@ -3404,7 +3406,8 @@ int drm_dp_update_payload_part1(struct
> > drm_dp_mst_topology_mgr *mgr)
> > payload->start_slot =
> > req_payload.start_slot;
> > continue;
> > } else {
> > -   drm_dbg_kms("Fail:set
> > payload to invalid sink");
> > +   drm_dbg_kms(mgr->dev,
> > +   "Fail:set
> > payload to invalid sink");
> > mutex_unlock(&mgr-
> > >payload_lock);
> > return -EINVAL;
> > }
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat

Re: [PATCH v2 1/2] drm/dp_mst: Do not set proposed vcpi directly

[Lin, Wayne]

[AMD Official Use Only]


> From: Wentland, Harry 
> Sent: Thursday, June 17, 2021 03:53
> To: Lin, Wayne; dri-devel@lists.freedesktop.org
> Cc: ly...@redhat.com; Kazlauskas, Nicholas; Zuo, Jerry; Pillai, Aurabindo; 
> Maarten Lankhorst; Maxime Ripard; Thomas Zimmermann; sta...@vger.kernel.org
> Subject: Re: [PATCH v2 1/2] drm/dp_mst: Do not set proposed vcpi directly
>
>
>
> On 2021-06-15 11:55 p.m., Wayne Lin wrote:
> > [Why]
> > When we receive CSN message to notify one port is disconnected, we will
> > implicitly set its corresponding num_slots to 0. Later on, we will
> > eventually call drm_dp_update_payload_part1() to arrange down streams.
> >
> > In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[]
> > to do the update. Not specific to a target sink only. For example, if we
> > light up 2 monitors, Monitor_A and Monitor_B, and then we unplug
> > Monitor_B. Later on, when we call drm_dp_update_payload_part1() to try
> > to update payload for Monitor_A, we'll also implicitly clean payload for
> > Monitor_B at the same time. And finally, when we try to call
> > drm_dp_update_payload_part1() to clean payload for Monitor_B, we will do
> > nothing at this time since payload for Monitor_B has been cleaned up
> > previously.
> >
> > For StarTech 1to3 DP hub, it seems like if we didn't update DPCD payload
> > ID table then polling for "ACT Handled"(BIT_1 of DPCD 002C0h) will fail
> > and this polling will last for 3 seconds.
> >
> > Therefore, guess the best way is we don't set the proposed_vcpi[]
> > diretly. Let user of these herlper functions to set the proposed_vcpi
> > directly.
> >
> > [How]
> > 1. Revert commit 7617e9621bf2 ("drm/dp_mst: clear time slots for ports
> > invalid")
> > 2. Tackle the issue in previous commit by skipping those trasient
> > proposed VCPIs. These stale VCPIs shoulde be explicitly cleared by
> > user later on.
> >
> > Changes since v1:
> > * Change debug macro to use drm_dbg_kms() instead
> > * Amend the commit message to add Fixed & Cc tags
> >
> > Signed-off-by: Wayne Lin 
> > Fixes: 7617e9621bf2 ("drm/dp_mst: clear time slots for ports invalid")
> > Cc: Lyude Paul 
> > Cc: Wayne Lin 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc:  # v5.5+
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 36 ---
> >  1 file changed, 10 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 32b7f8983b94..b41b837db66d 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2501,7 +2501,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch 
> > *mstb,
> >  {
> >   struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> >   struct drm_dp_mst_port *port;
> > - int old_ddps, old_input, ret, i;
> > + int old_ddps, ret;
> >   u8 new_pdt;
> >   bool new_mcs;
> >   bool dowork = false, create_connector = false;
> > @@ -2533,7 +2533,6 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch 
> > *mstb,
> >   }
> >
> >   old_ddps = port->ddps;
> > - old_input = port->input;
> >   port->input = conn_stat->input_port;
> >   port->ldps = conn_stat->legacy_device_plug_status;
> >   port->ddps = conn_stat->displayport_device_plug_status;
> > @@ -2555,28 +2554,6 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch 
> > *mstb,
> >   dowork = false;
> >   }
> >
> > - if (!old_input && old_ddps != port->ddps && !port->ddps) {
> > - for (i = 0; i < mgr->max_payloads; i++) {
> > - struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
> > - struct drm_dp_mst_port *port_validated;
> > -
> > - if (!vcpi)
> > - continue;
> > -
> > - port_validated =
> > - container_of(vcpi, struct drm_dp_mst_port, 
> > vcpi);
> > - port_validated =
> > - drm_dp_mst_topology_get_port_validated(mgr, 
> > port_validated);
> > - if (!port_validated) {
> > -  

RE: [Cc: drm-misc folks] Re: [Intel-gfx] [CI 1/4] drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs

[Lin, Wayne]

[Public]

Add Mario for awareness.

> -Original Message-
> From: Jani Nikula 
> Sent: Friday, February 10, 2023 6:48 PM
> To: Lyude Paul ; imre.d...@intel.com; Wentland,
> Harry ; Deucher, Alexander
> ; Daniel Vetter 
> Cc: sta...@vger.kernel.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; Ville Syrjälä ; 
> Ben
> Skeggs ; Lin, Wayne ; Karol
> Herbst ; Thomas Zimmermann
> 
> Subject: Re: [Cc: drm-misc folks] Re: [Intel-gfx] [CI 1/4] drm/i915/dp_mst:
> Add the MST topology state for modesetted CRTCs
> 
> On Thu, 09 Feb 2023, Lyude Paul  wrote:
> > On Tue, 2023-02-07 at 14:59 +0200, Imre Deak wrote:
> >> Hi all,
> >>
> >> On Mon, Feb 06, 2023 at 01:48:53PM +0200, Imre Deak wrote:
> >> > Add the MST topology for a CRTC to the atomic state if the driver
> >> > needs to force a modeset on the CRTC after the encoder compute
> >> > config functions are called.
> >> >
> >> > Later the MST encoder's disable hook also adds the state, but that
> >> > isn't guaranteed to work (since in that hook getting the state may
> >> > fail, which can't be handled there). This should fix that, while a
> >> > later patch fixes the use of the MST state in the disable hook.
> >> >
> >> > v2: Add missing forward struct declartions, caught by hdrtest.
> >> > v3: Factor out intel_dp_mst_add_topology_state_for_connector() used
> >> > later in the patchset.
> >> >
> >> > Cc: Lyude Paul 
> >> > Cc: Ville Syrjälä 
> >> > Cc: sta...@vger.kernel.org # 6.1
> >> > Reviewed-by: Ville Syrjälä  # v2
> >> > Reviewed-by: Lyude Paul 
> >> > Signed-off-by: Imre Deak 
> >>
> >> Is it ok to merge these 4 patches (also at [1]), via the i915 tree?
> >>
> >> If so could it be also acked from the AMD and Nouveau side?
> >
> > Whichever branch works best for y'all is fine by me, if it's via
> > i915's tree I guess we might need to back-merge drm-misc at some point
> > so I can write up equivalent fixes for nouveau as well.
> >
> > (Added Thomas Zimmermann to Cc)
> 
> I suggest merging the series via drm-misc-next-fixes branch, to get them to
> Linus' tree in the upcoming merge window. They all apply cleanly there. The
> drivers can backmerge them from drm-next in the mean time, or wait for
> v6.3-rc1.
> 
> Daniel acked this (well, any -next-fixes branch) on IRC yesterday, obviously
> ack from me too.
> 
> I take the above as Lyude's ack for nouveau.
> 
> Harry, Wayne, do you agree with this, ack for merging the AMD part via drm-
> misc-next-fixes? (Alex suggested to get your input.)
> 

Thank you Imre, Lyude and Jani.
That looks good to me and I agree with that.

Thanks!

Regards,
Wayne
> 
> BR,
> Jani.
> 
> 
> >
> >>
> >> [1] https://patchwork.freedesktop.org/series/113703/
> >>
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_display.c |  4 ++
> >> > drivers/gpu/drm/i915/display/intel_dp_mst.c  | 61
> >> > 
> drivers/gpu/drm/i915/display/intel_dp_mst.h
> >> > |  4 ++
> >> >  3 files changed, 69 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> > b/drivers/gpu/drm/i915/display/intel_display.c
> >> > index 12ade593c..38106cf63b3b9 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> > @@ -5936,6 +5936,10 @@ int intel_modeset_all_pipes(struct
> intel_atomic_state *state,
> >> >  if (ret)
> >> >  return ret;
> >> >
> >> > +ret = intel_dp_mst_add_topology_state_for_crtc(state, 
> >> > crtc);
> >> > +if (ret)
> >> > +return ret;
> >> > +
> >> >  ret = intel_atomic_add_affected_planes(state, crtc);
> >> >  if (ret)
> >> >  return ret;
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> >> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> >> > index 8b0e4defa3f10..f3cb12dcfe0a7 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> >> > @@ -1223,3 +1223,64 @@ bool intel_dp_ms

RE: [PATCH] drm/amdgpu/dm/mst: Fix incorrect usage of drm_dp_add_payload_part2()

[Lin, Wayne]

[Public]



> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, October 6, 2022 3:37 AM
> To: Siqueira, Rodrigo ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Wentland, Harry ; Li, Sun peng (Leo)
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Zuo, Jerry
> ; Lin, Wayne ; Chen, Ian
> ; Mikita Lipski ; Mahfooz,
> Hamza ; Claudio Suarez ; Colin
> Ian King ; Jani Nikula ; open
> list 
> Subject: Re: [PATCH] drm/amdgpu/dm/mst: Fix incorrect usage of
> drm_dp_add_payload_part2()
> 
> On Tue, 2022-10-04 at 16:46 -0400, Rodrigo Siqueira Jordao wrote:
> >
> > On 2022-10-04 16:24, Lyude Paul wrote:
> > > Yikes, it appears somehow I totally made a mistake here. We're
> > > currently checking to see if drm_dp_add_payload_part2() returns a
> > > non-zero value to indicate success. That's totally wrong though, as
> > > this function only returns a zero value on success - not the other way
> around.
> > >
> > > So, fix that.
> > >
> > > Signed-off-by: Lyude Paul 
> > > Issue:
> > >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > tlab.freedesktop.org%2Fdrm%2Famd%2F-
> %2Fissues%2F2171&data=05%7C0
> > >
> 1%7Cwayne.lin%40amd.com%7Ccd5a63120e064f4bb6aa08daa7090baf%7C3d
> d8961
> > >
> fe4884e608e11a82d994e183d%7C0%7C0%7C638005954559719396%7CUnkno
> wn%7CT
> > >
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXV
> > >
> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=nMIGnUKS6EDrdKJ0rR%2BAh
> FRa4ST0%2
> > > BYr9bILmXv40yv0%3D&reserved=0
> > > Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into
> > > the atomic state")
> > > ---
> > >   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2
> +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > index b8077fcd4651..00598def5b39 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > +++
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > @@ -297,7 +297,7 @@ bool
> dm_helpers_dp_mst_send_payload_allocation(
> > >   clr_flag = MST_ALLOCATE_NEW_PAYLOAD;
> > >   }
> > >
> > > - if (enable && drm_dp_add_payload_part2(mst_mgr, mst_state-
> >base.state, payload)) {
> > > + if (enable && drm_dp_add_payload_part2(mst_mgr,
> > > +mst_state->base.state, payload) == 0) {

Hi Lyude,

This line changes the original logic a bit. The 'if' case was trying to catch 
failure 
while sending ALLOCATE_PAYLOAD. If the msg fails, set the set_flag to false.
If succeed, set the set_flag to true and clear the clr_flag. 

Sorry if the code wording misleading. Thanks!

> > >   amdgpu_dm_set_mst_status(&aconnector->mst_status,
> > >   set_flag, false);
> > >   } else {
> >
> > Hi Lyude,
> >
> > Maybe I'm missing something, but I can't find the
> > drm_dp_add_payload_part2() function on amd-staging-drm-next. Which
> > repo are you using?
> 
> If it's not on amd-staging-drm-next then it likely hasn't gotten backported to
> amd's branch yet and is in drm-misc-next
> 
> >
> > Thanks
> > Siqueira
> >
> 
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
--
Regards,
Wayne Lin

RE: [PATCH 1/2] drm/amdgpu/mst: Stop ignoring error codes and deadlocking

[Lin, Wayne]

[Public]



> -Original Message-
> From: Lyude Paul 
> Sent: Tuesday, November 15, 2022 5:55 AM
> To: Lin, Wayne ; amd-...@lists.freedesktop.org
> Cc: Wentland, Harry ; sta...@vger.kernel.org;
> Li, Sun peng (Leo) ; Siqueira, Rodrigo
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Kazlauskas,
> Nicholas ; Pillai, Aurabindo
> ; Li, Roman ; Zuo, Jerry
> ; Wu, Hersen ; Thomas
> Zimmermann ; Mahfooz, Hamza
> ; Hung, Alex ; Francis,
> David ; Mikita Lipski ; Liu,
> Wenjing ; open list:DRM DRIVERS  de...@lists.freedesktop.org>; open list 
> Subject: Re: [PATCH 1/2] drm/amdgpu/mst: Stop ignoring error codes and
> deadlocking
> 
> On Wed, 2022-11-09 at 09:48 +, Lin, Wayne wrote:
> > >   }
> > > - if (!drm_dp_mst_atomic_check(state) && !debugfs_overwrite) {
> > > + ret = drm_dp_mst_atomic_check(state);
> > > + if (ret == 0 && !debugfs_overwrite) {
> > >   set_dsc_configs_from_fairness_vars(params, vars, count, 
> > > k);
> > > - return true;
> > > + return 0;
> > > + } else if (ret == -EDEADLK) {
> > > + return ret;
> >
> > I think we should return here whenever there is an error. Not just for
> > EDEADLK case.
> 
> Are we sure about this one? I think we may actually want to make this so it
> returns on ret != -ENOSPC, since we want the function to continue if there's
> no space in the atomic state available so it can try recomputing things with
> compression enabled. On ret == 0 it should return early without doing
> compression, and on ret == -ENOSPC it should just continue the function
> from there
> 
Oh, right.. Thanks for saving me from causing disaster : )

> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
--
Regards,
Wayne

RE: [PATCH v2 1/4] drm/amdgpu/mst: Stop ignoring error codes and deadlocking

[Lin, Wayne]

[Public]

All the patch set looks good to me. Feel free to add:
Reviewed-by: Wayne Lin 

Again, thank you Lyude for helping on this!!!

Regards,
Wayne
> -Original Message-
> From: Lyude Paul 
> Sent: Tuesday, November 15, 2022 6:18 AM
> To: amd-...@lists.freedesktop.org
> Cc: Wentland, Harry ; sta...@vger.kernel.org;
> Li, Sun peng (Leo) ; Siqueira, Rodrigo
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Kazlauskas,
> Nicholas ; Pillai, Aurabindo
> ; Li, Roman ; Zuo, Jerry
> ; Wu, Hersen ; Lin, Wayne
> ; Thomas Zimmermann ;
> Mahfooz, Hamza ; Hung, Alex
> ; Mikita Lipski ; Liu,
> Wenjing ; Francis, David
> ; open list:DRM DRIVERS  de...@lists.freedesktop.org>; open list 
> Subject: [PATCH v2 1/4] drm/amdgpu/mst: Stop ignoring error codes and
> deadlocking
> 
> It appears that amdgpu makes the mistake of completely ignoring the return
> values from the DP MST helpers, and instead just returns a simple true/false.
> In this case, it seems to have come back to bite us because as a result of
> simply returning false from compute_mst_dsc_configs_for_state(), amdgpu
> had no way of telling when a deadlock happened from these helpers. This
> could definitely result in some kernel splats.
> 
> V2:
> * Address Wayne's comments (fix another bunch of spots where we weren't
>   passing down return codes)
> 
> Signed-off-by: Lyude Paul 
> Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share")
> Cc: Harry Wentland 
> Cc:  # v5.6+
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  18 +-
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 235 ++--
> --
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |  12 +-
>  3 files changed, 147 insertions(+), 118 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 0db2a88cd4d7b..852a2100c6b38 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6462,7 +6462,7 @@ static int
> dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
>   struct drm_connector_state *new_con_state;
>   struct amdgpu_dm_connector *aconnector;
>   struct dm_connector_state *dm_conn_state;
> - int i, j;
> + int i, j, ret;
>   int vcpi, pbn_div, pbn, slot_num = 0;
> 
>   for_each_new_connector_in_state(state, connector,
> new_con_state, i) { @@ -6509,8 +6509,11 @@ static int
> dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
>   dm_conn_state->pbn = pbn;
>   dm_conn_state->vcpi_slots = slot_num;
> 
> - drm_dp_mst_atomic_enable_dsc(state, aconnector-
> >port, dm_conn_state->pbn,
> -  false);
> + ret = drm_dp_mst_atomic_enable_dsc(state,
> aconnector->port,
> +dm_conn_state-
> >pbn, false);
> + if (ret < 0)
> + return ret;
> +
>   continue;
>   }
> 
> @@ -9523,10 +9526,9 @@ static int amdgpu_dm_atomic_check(struct
> drm_device *dev,
> 
>  #if defined(CONFIG_DRM_AMD_DC_DCN)
>   if (dc_resource_is_dsc_encoding_supported(dc)) {
> - if (!pre_validate_dsc(state, &dm_state, vars)) {
> - ret = -EINVAL;
> + ret = pre_validate_dsc(state, &dm_state, vars);
> + if (ret != 0)
>   goto fail;
> - }
>   }
>  #endif
> 
> @@ -9621,9 +9623,9 @@ static int amdgpu_dm_atomic_check(struct
> drm_device *dev,
>   }
> 
>  #if defined(CONFIG_DRM_AMD_DC_DCN)
> - if (!compute_mst_dsc_configs_for_state(state, dm_state-
> >context, vars)) {
> + ret = compute_mst_dsc_configs_for_state(state, dm_state-
> >context, vars);
> + if (ret) {
> 
>   DRM_DEBUG_DRIVER("compute_mst_dsc_configs_for_state()
> failed\n");
> - ret = -EINVAL;
>   goto fail;
>   }
> 
> diff --git
> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 6ff96b4bdda5c..bba2e8aaa2c20 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -703,13 +703,13 @@ static int bpp_x16_from_pbn(struct
> dsc_mst_fairness_params param, int pbn

RE: [PATCH 1/2] drm/amdgpu/mst: Stop ignoring error codes and deadlocking

[Lin, Wayne]

[Public]

Thanks, Lyude!
Comments inline.

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, November 5, 2022 7:59 AM
> To: amd-...@lists.freedesktop.org
> Cc: Wentland, Harry ; sta...@vger.kernel.org;
> Li, Sun peng (Leo) ; Siqueira, Rodrigo
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Kazlauskas,
> Nicholas ; Pillai, Aurabindo
> ; Li, Roman ; Zuo, Jerry
> ; Wu, Hersen ; Lin, Wayne
> ; Thomas Zimmermann ;
> Mahfooz, Hamza ; Hung, Alex
> ; Francis, David ; Mikita
> Lipski ; Liu, Wenjing ;
> open list:DRM DRIVERS ; open list  ker...@vger.kernel.org>
> Subject: [PATCH 1/2] drm/amdgpu/mst: Stop ignoring error codes and
> deadlocking
> 
> It appears that amdgpu makes the mistake of completely ignoring the return
> values from the DP MST helpers, and instead just returns a simple true/false.
> In this case, it seems to have come back to bite us because as a result of
> simply returning false from compute_mst_dsc_configs_for_state(), amdgpu
> had no way of telling when a deadlock happened from these helpers. This
> could definitely result in some kernel splats.
> 
> Signed-off-by: Lyude Paul 
> Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share")
> Cc: Harry Wentland 
> Cc:  # v5.6+
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  18 +--
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 107 ++--
> --
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |  12 +-
>  3 files changed, 73 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 0db2a88cd4d7b..6f76b2c84cdb5 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6462,7 +6462,7 @@ static int
> dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
>   struct drm_connector_state *new_con_state;
>   struct amdgpu_dm_connector *aconnector;
>   struct dm_connector_state *dm_conn_state;
> - int i, j;
> + int i, j, ret;
>   int vcpi, pbn_div, pbn, slot_num = 0;
> 
>   for_each_new_connector_in_state(state, connector,
> new_con_state, i) { @@ -6509,8 +6509,11 @@ static int
> dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
>   dm_conn_state->pbn = pbn;
>   dm_conn_state->vcpi_slots = slot_num;
> 
> - drm_dp_mst_atomic_enable_dsc(state, aconnector-
> >port, dm_conn_state->pbn,
> -  false);
> + ret = drm_dp_mst_atomic_enable_dsc(state,
> aconnector->port,
> +dm_conn_state-
> >pbn, false);
> + if (ret != 0)
> + return ret;
> +
>   continue;
>   }
> 
> @@ -9523,10 +9526,9 @@ static int amdgpu_dm_atomic_check(struct
> drm_device *dev,
> 
>  #if defined(CONFIG_DRM_AMD_DC_DCN)
>   if (dc_resource_is_dsc_encoding_supported(dc)) {
> - if (!pre_validate_dsc(state, &dm_state, vars)) {
> - ret = -EINVAL;
> + ret = pre_validate_dsc(state, &dm_state, vars);
> + if (ret != 0)
>   goto fail;
> - }
>   }
>  #endif
> 
> @@ -9621,9 +9623,9 @@ static int amdgpu_dm_atomic_check(struct
> drm_device *dev,
>   }
> 
>  #if defined(CONFIG_DRM_AMD_DC_DCN)
> - if (!compute_mst_dsc_configs_for_state(state, dm_state-
> >context, vars)) {
> + ret = compute_mst_dsc_configs_for_state(state, dm_state-
> >context, vars);
> + if (ret) {
> 
>   DRM_DEBUG_DRIVER("compute_mst_dsc_configs_for_state()
> failed\n");
> - ret = -EINVAL;
>   goto fail;
>   }
> 
> diff --git
> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 6ff96b4bdda5c..30bc2e5058b70 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -864,25 +864,25 @@ static bool try_disable_dsc(struct
> drm_atomic_state *state,
>   return true;
>  }
> 
> -static bool compute_mst_dsc_configs_for_link(struct drm_atomic_state
> *state,
> -  struct dc_state *dc_state,
> -  s

RE: [PATCH 2/2] drm/display/dp_mst: Fix drm_dp_mst_add_affected_dsc_crtcs() return code

[Lin, Wayne]

[AMD Official Use Only - General]

Hi Lyude,

It LGTM. Feel free to add 
Reviewed-by: Wayne Lin 

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, November 5, 2022 7:59 AM
> To: amd-...@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; David Airlie ; Daniel Vetter
> ; Jani Nikula ; Thomas
> Zimmermann ; Lin, Wayne
> ; Imre Deak ; Mikita Lipski
> ; Deucher, Alexander
> ; open list:DRM DRIVERS  de...@lists.freedesktop.org>; open list 
> Subject: [PATCH 2/2] drm/display/dp_mst: Fix
> drm_dp_mst_add_affected_dsc_crtcs() return code
> 
> Looks like that we're accidentally dropping a pretty important return code
> here. For some reason, we just return -EINVAL if we fail to get the MST
> topology state. This is wrong: error codes are important and should never be
> squashed without being handled, which here seems to have the potential to
> cause a deadlock.
> 
> Signed-off-by: Lyude Paul 
> Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on
> affected DSC MST CRTCs")
> Cc:  # v5.6+
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index ecd22c038c8c0..51a46689cda70 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -5186,7 +5186,7 @@ int drm_dp_mst_add_affected_dsc_crtcs(struct
> drm_atomic_state *state, struct drm
>   mst_state = drm_atomic_get_mst_topology_state(state, mgr);
> 
>   if (IS_ERR(mst_state))
> - return -EINVAL;
> + return PTR_ERR(mst_state);
> 
>   list_for_each_entry(pos, &mst_state->payloads, next) {
> 
> --
> 2.37.3

RE: [PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer

[Lin, Wayne]

[AMD Official Use Only - General]



> -Original Message-
> From: Jani Nikula 
> Sent: Monday, April 17, 2023 6:30 PM
> To: Jeff Layton ; Lyude Paul ; Lin,
> Wayne ; Alex Deucher 
> Cc: David Airlie ; Daniel Vetter ;
> Deucher, Alexander ; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully
> handle NULL state pointer
> 
> On Mon, 17 Apr 2023, Jeff Layton  wrote:
> > On Mon, 2023-04-17 at 11:44 +0300, Jani Nikula wrote:
> >> On Fri, 14 Apr 2023, Lyude Paul  wrote:
> >> > On Fri, 2023-04-14 at 13:35 +0300, Jani Nikula wrote:
> >> > > On Fri, 14 Apr 2023, Jeff Layton  wrote:
> >> > > > On Fri, 2023-04-14 at 04:40 +, Lin, Wayne wrote:
> >> > > > > [Public]
> >> > > > >
> >> > > > > Hi Jeff,
> >> > > > >
> >> > > > > Thanks. I might need more information to understand why we
> >> > > > > can't retrieve the drm atomic state. Also , "Failed to create
> >> > > > > MST payload for port" indicates error while configuring DPCD
> >> > > > > payload ID table. Could you help to provide log with KMS +
> ATOMIC + DP debug on please? Thanks in advance!
> >> > > > >
> >> > > > > Regards,
> >> > > > > Wayne
> >> > > > >
> >> > > >
> >> > > > Possibly. I'm not that familiar with display driver debugging.
> >> > > > Can you send me some directions on how to crank up that sort of
> debug logging?
> >> > > >
> >> > > > Note that this problem is _very_ intermittent too: I went about
> >> > > > 2 weeks between crashes, and then I got 3 in one day. I'd
> >> > > > rather not run with a lot of debug logging for a long time if
> >> > > > that's what this is going to require, as this is my main workstation.
> >> > > >
> >> > > > The last time I got this log message, my proposed patch did
> >> > > > prevent the box from oopsing, so I'd really like to see it go
> >> > > > in unless it's just categorically wrong for the caller to pass
> >> > > > down a NULL state pointer to drm_dp_add_payload_part2.
> >> > >
> >> > > Cc: Lyude.
> >> > >
> >> > > Looks like the state parameter was added in commit 4d07b0bc4034
> >> > > ("drm/display/dp_mst: Move all payload info into the atomic
> >> > > state") and its only use is to get at state->dev for debug logging.
> >> > >
> >> > > What's the plan for the parameter? Surely something more than
> >> > > that! :)
> >> >
> >> > I don't think there was any plan for that, or at least I certainly
> >> > don't even remember adding that D:. It must totally have been by
> >> > mistake and snuck by review, if that's the only thing that we're
> >> > using it for I'd say it's definitely fine to just drop it entirely
> >>
> >> I guess we could use two patches then, first replace state->dev with
> >> mgr->dev as something that can be backported as needed, and second
> >> mgr->drop
> >> the state parameter altogether.
> >>
> >> Jeff, up for it? At least the first one?
> >>
> >>
> >> BR,
> >> Jani.
> >>
> >
> > Sure. I'm happy to test patches if you send them along.
> 
> I was hoping to lure you into sending patches. ;)
> 
> Anyway, I'm not working on this.
> 
> 
Hi Jeff,

I probably know the root cause. 
But it doesn't need to use the state in the end, I will just rely on the patch 
that Jani suggested to fix it. I can help to provide the patch later : )

> BR,
> Jani.
> 
> >
> > Thanks,
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

--
Regards,
Wayne

RE: [PATCH] drm/dp_mst: Clear MSG_RDY flag before sending new message

[Lin, Wayne]

[Public]

Hi Jani Nikula,

Appreciate your time and feedback! Will adjust the patch.
Some comments inline.

> -Original Message-
> From: Jani Nikula 
> Sent: Tuesday, April 18, 2023 4:53 PM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: ly...@redhat.com; imre.d...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
> ; Lin, Wayne ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/dp_mst: Clear MSG_RDY flag before sending new
> message
> 
> On Tue, 18 Apr 2023, Wayne Lin  wrote:
> > [Why & How]
> > The sequence for collecting down_reply/up_request from source
> > perspective should be:
> >
> > Request_n->repeat (get partial reply of Request_n->clear message ready
> > flag to ack DPRX that the message is received) till all partial
> > replies for Request_n are received->new Request_n+1.
> >
> > While assembling partial reply packets, reading out DPCD DOWN_REP
> > Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be
> wrapped
> > up as a complete operation for reading out a reply packet.
> > Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
> > be risky. e.g. If the reply of the new request has overwritten the
> > DPRX DOWN_REP Sideband MSG buffer before source writing ack to clear
> > DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
> > for the new request. Should handle the up request in the same way.
> >
> > In drm_dp_mst_hpd_irq(), we don't clear MSG_RDY flag before caliing
> > drm_dp_mst_kick_tx(). Fix that.
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 ++
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 22
> +++
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  3 +++
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 ++
> >  4 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 77277d90b6e2..5313a5656598 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -3166,6 +3166,8 @@ static void dm_handle_mst_sideband_msg(struct
> amdgpu_dm_connector *aconnector)
> > for (retry = 0; retry < 3; retry++) {
> > uint8_t wret;
> >
> > +   /* MSG_RDY ack is done in drm*/
> > +   esi[1] &= ~(DP_DOWN_REP_MSG_RDY |
> DP_UP_REQ_MSG_RDY);
> 
> Why do the masking within the retry loop?
> 
> > wret = drm_dp_dpcd_write(
> > &aconnector->dm_dp_aux.aux,
> > dpcd_addr + 1,
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 51a46689cda7..02aad713c67c 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -4054,6 +4054,9 @@ int drm_dp_mst_hpd_irq(struct
> > drm_dp_mst_topology_mgr *mgr, u8 *esi, bool *handl  {
> > int ret = 0;
> > int sc;
> > +   const int tosend = 1;
> > +   int retries = 0;
> > +   u8 buf = 0;
> 
> All of these should be in tighter scope.
> 
> > *handled = false;
> > sc = DP_GET_SINK_COUNT(esi[0]);
> >
> > @@ -4072,6 +4075,25 @@ int drm_dp_mst_hpd_irq(struct
> drm_dp_mst_topology_mgr *mgr, u8 *esi, bool *handl
> > *handled = true;
> > }
> >
> > +   if (*handled) {
> 
> That should check for DP_DOWN_REP_MSG_RDY and
> DP_UP_REQ_MSG_RDY only, right? If those are not set, we didn't do
> anything with them, and should not ack.

Right. I was thinking the sink count change will accompany the CSN
up request message. I'll change it to be more clear. Thanks.
> 
> > +   buf = esi[1] & (DP_DOWN_REP_MSG_RDY |
> DP_UP_REQ_MSG_RDY);
> > +   do {
> > +   ret = drm_dp_dpcd_write(mgr->aux,
> > +
>   DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0,
> > +   &buf,
> > +   tosend);
> 
> We should probably have a helper function to do the acking, similar to
> intel_dp_ack_sink_irq_esi(), which could be used both by this function and
> the drivers.
> 
> > +

RE: [PATCH] drm/dp_mst: Clear MSG_RDY flag before sending new message

[Lin, Wayne]

[Public]

Much appreciated, Ville and Jani!

To tackle this MST message ack event now, probably I could just pull out the 
drm_dp_mst_kick_tx() out of drm_dp_mst_hpd_irq() and make it the second 
step function to handle mst hpd irq? Would like to know your thoughts : )

Again, thanks for your time!

Regards,
Wayne Lin

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, April 18, 2023 10:01 PM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; imre.d...@intel.com; jani.nik...@intel.com; Wentland,
> Harry ; Zuo, Jerry ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/dp_mst: Clear MSG_RDY flag before sending new
> message
> 
> On Tue, Apr 18, 2023 at 02:09:05PM +0800, Wayne Lin wrote:
> > [Why & How]
> > The sequence for collecting down_reply/up_request from source
> > perspective should be:
> >
> > Request_n->repeat (get partial reply of Request_n->clear message ready
> > flag to ack DPRX that the message is received) till all partial
> > replies for Request_n are received->new Request_n+1.
> >
> > While assembling partial reply packets, reading out DPCD DOWN_REP
> > Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be
> wrapped
> > up as a complete operation for reading out a reply packet.
> > Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
> > be risky. e.g. If the reply of the new request has overwritten the
> > DPRX DOWN_REP Sideband MSG buffer before source writing ack to clear
> > DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
> > for the new request. Should handle the up request in the same way.
> >
> > In drm_dp_mst_hpd_irq(), we don't clear MSG_RDY flag before caliing
> > drm_dp_mst_kick_tx(). Fix that.
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 ++
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 22
> +++
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  3 +++
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 ++
> >  4 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 77277d90b6e2..5313a5656598 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -3166,6 +3166,8 @@ static void dm_handle_mst_sideband_msg(struct
> amdgpu_dm_connector *aconnector)
> > for (retry = 0; retry < 3; retry++) {
> > uint8_t wret;
> >
> > +   /* MSG_RDY ack is done in drm*/
> > +   esi[1] &= ~(DP_DOWN_REP_MSG_RDY |
> DP_UP_REQ_MSG_RDY);
> > wret = drm_dp_dpcd_write(
> > &aconnector->dm_dp_aux.aux,
> > dpcd_addr + 1,
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 51a46689cda7..02aad713c67c 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -4054,6 +4054,9 @@ int drm_dp_mst_hpd_irq(struct
> > drm_dp_mst_topology_mgr *mgr, u8 *esi, bool *handl  {
> > int ret = 0;
> > int sc;
> > +   const int tosend = 1;
> > +   int retries = 0;
> > +   u8 buf = 0;
> > *handled = false;
> > sc = DP_GET_SINK_COUNT(esi[0]);
> >
> > @@ -4072,6 +4075,25 @@ int drm_dp_mst_hpd_irq(struct
> drm_dp_mst_topology_mgr *mgr, u8 *esi, bool *handl
> > *handled = true;
> > }
> >
> > +   if (*handled) {
> > +   buf = esi[1] & (DP_DOWN_REP_MSG_RDY |
> DP_UP_REQ_MSG_RDY);
> > +   do {
> > +   ret = drm_dp_dpcd_write(mgr->aux,
> > +
>   DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0,
> > +   &buf,
> > +   tosend);
> > +
> > +   if (ret == tosend)
> > +   break;
> > +
> > +   retries++;
> > +   } while (retries < 5);
> 
> What's with this magic retry loop?
> 
> Not sure I like the whole thing though. Splitting the irq ack semi-randomly
> between driver vs. multiple helpers doesn't feel great to me.
> 
> As a whole 

RE: [PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer

[Lin, Wayne]

[Public]

Hi Jeff,

Thanks. I might need more information to understand why we can't retrieve
the drm atomic state. Also , "Failed to create MST payload for port" indicates
error while configuring DPCD payload ID table. Could you help to provide log
with KMS + ATOMIC + DP debug on please? Thanks in advance!

Regards,
Wayne

> -Original Message-
> From: Alex Deucher 
> Sent: Thursday, April 13, 2023 8:59 PM
> To: Jani Nikula ; Lin, Wayne
> 
> Cc: Jeff Layton ; David Airlie ;
> Daniel Vetter ; Deucher, Alexander
> ; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully
> handle NULL state pointer
> 
> + Wayne
> 
> On Thu, Apr 13, 2023 at 8:31 AM Jani Nikula 
> wrote:
> >
> > On Thu, 13 Apr 2023, Jeff Layton  wrote:
> > > I've been experiencing some intermittent crashes down in the display
> > > driver code. The symptoms are ususally a line like this in dmesg:
> > >
> > > amdgpu :30:00.0: [drm] Failed to create MST payload for port
> > > 6d3a3885: -5
> > >
> > > ...followed by an Oops due to a NULL pointer dereference.
> > >
> > > The real bug is probably in the caller of this function, which is
> > > passing it a NULL state pointer, but this patch at least keeps my
> > > machine from oopsing when this occurs.
> >
> > My fear is that papering over this makes the root cause harder to find.
> >
> > Cc: Harry, Alex
> >
> >
> > BR,
> > Jani.
> >
> >
> > >
> > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > > Signed-off-by: Jeff Layton 
> > > ---
> > >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > index 38dab76ae69e..87ad406c50f9 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > @@ -3404,7 +3404,8 @@ int drm_dp_add_payload_part2(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > >
> > >   /* Skip failed payloads */
> > >   if (payload->vc_start_slot == -1) {
> > > - drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
> failed, skipping part 2\n",
> > > + drm_dbg_kms(state ? state->dev : NULL,
> > > + "Part 1 of payload creation for %s failed,
> > > + skipping part 2\n",
> > >   payload->port->connector->name);
> > >   return -EIO;
> > >   }
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center

RE: [PATCH v2] drm/dp_mst: Clear MSG_RDY flag before sending new message

[Lin, Wayne]

[Public]

Hi Lyude and Jani,

Could you help to review please? Thanks for your time!

Regards,
Wayne Lin
> -Original Message-
> From: Wayne Lin 
> Sent: Thursday, April 27, 2023 3:29 PM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: ly...@redhat.com; ville.syrj...@linux.intel.com; jani.nik...@intel.com;
> imre.d...@intel.com; Wentland, Harry ; Zuo,
> Jerry ; Lin, Wayne ;
> sta...@vger.kernel.org
> Subject: [PATCH v2] drm/dp_mst: Clear MSG_RDY flag before sending new
> message
> 
> [Why]
> The sequence for collecting down_reply from source perspective should
> be:
> 
> Request_n->repeat (get partial reply of Request_n->clear message ready
> flag to ack DPRX that the message is received) till all partial replies for
> Request_n are received->new Request_n+1.
> 
> Now there is chance that drm_dp_mst_hpd_irq() will fire new down request
> in the tx queue when the down reply is incomplete. Source is restricted to
> generate interveleaved message transactions so we should avoid it.
> 
> Also, while assembling partial reply packets, reading out DPCD DOWN_REP
> Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be
> wrapped up as a complete operation for reading out a reply packet.
> Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
> be risky. e.g. If the reply of the new request has overwritten the DPRX
> DOWN_REP Sideband MSG buffer before source writing one to clear
> DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply for
> the new request. Should handle the up request in the same way.
> 
> [How]
> Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ
> event, driver calls drm_dp_mst_hpd_irq_step2() and might trigger
> drm_dp_mst_kick_tx() only when there is no on going message transaction.
> 
> Changes since v1:
> * Reworked on review comments received
> -> Adjust the fix to let driver explicitly kick off new down request
> when mst irq event is handled and acked
> -> Adjust the commit message
> 
> Signed-off-by: Wayne Lin 
> Cc: sta...@vger.kernel.org
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  8 ++---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 35
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c   |  5 ++-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  5 ++-
>  include/drm/display/drm_dp_mst_helper.h   |  4 +--
>  5 files changed, 45 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1ad67c2a697e..48bdcb2ee9b1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3259,10 +3259,9 @@ static void dm_handle_mst_sideband_msg(struct
> amdgpu_dm_connector *aconnector)
>   DRM_DEBUG_DRIVER("ESI %02x %02x %02x\n", esi[0], esi[1],
> esi[2]);
>   /* handle HPD short pulse irq */
>   if (aconnector->mst_mgr.mst_state)
> - drm_dp_mst_hpd_irq(
> - &aconnector->mst_mgr,
> - esi,
> - &new_irq_handled);
> + drm_dp_mst_hpd_irq_step1(&aconnector-
> >mst_mgr,
> +  esi,
> +  &new_irq_handled);
> 
>   if (new_irq_handled) {
>   /* ACK at DPCD to notify down stream */ @@ -3281,6
> +3280,7 @@ static void dm_handle_mst_sideband_msg(struct
> amdgpu_dm_connector *aconnector)
>   break;
>   }
> 
> + drm_dp_mst_hpd_irq_step2(&aconnector-
> >mst_mgr);
>   /* check if there is new irq to be handled */
>   dret = drm_dp_dpcd_read(
>   &aconnector->dm_dp_aux.aux,
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 70df29fe92db..2e0a38a6509c 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -4045,7 +4045,7 @@ static int drm_dp_mst_handle_up_req(struct
> drm_dp_mst_topology_mgr *mgr)  }
> 
>  /**
> - * drm_dp_mst_hpd_irq() - MST hotplug IRQ notify
> + * drm_dp_mst_hpd_irq_step1() - MST hotplug IRQ notify
>   * @mgr: manager to notify irq for.
>   * @esi: 4 bytes from SINK_COUNT_ESI
>   * @handled: whether the hpd interrupt was consumed or not @@ -4055,7
> +4055,7 @@ static int drm_dp_mst_handle_up_req(

RE: [PATCH v2] drm/dp_mst: Clear MSG_RDY flag before sending new message

[Lin, Wayne]

[Public]

Hi,

Ping again for code review. Much appreciated!

Regards,
Wayne

> -Original Message-
> From: Lin, Wayne
> Sent: Monday, May 8, 2023 5:49 PM
> To: ly...@redhat.com; jani.nik...@intel.com; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; imre.d...@intel.com; Wentland, Harry
> ; Zuo, Jerry ;
> sta...@vger.kernel.org
> Subject: RE: [PATCH v2] drm/dp_mst: Clear MSG_RDY flag before sending
> new message
> 
> [Public]
> 
> Hi Lyude and Jani,
> 
> Could you help to review please? Thanks for your time!
> 
> Regards,
> Wayne Lin
> > -Original Message-
> > From: Wayne Lin 
> > Sent: Thursday, April 27, 2023 3:29 PM
> > To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Cc: ly...@redhat.com; ville.syrj...@linux.intel.com;
> > jani.nik...@intel.com; imre.d...@intel.com; Wentland, Harry
> > ; Zuo, Jerry ; Lin,
> Wayne
> > ; sta...@vger.kernel.org
> > Subject: [PATCH v2] drm/dp_mst: Clear MSG_RDY flag before sending new
> > message
> >
> > [Why]
> > The sequence for collecting down_reply from source perspective should
> > be:
> >
> > Request_n->repeat (get partial reply of Request_n->clear message ready
> > flag to ack DPRX that the message is received) till all partial
> > replies for Request_n are received->new Request_n+1.
> >
> > Now there is chance that drm_dp_mst_hpd_irq() will fire new down
> > request in the tx queue when the down reply is incomplete. Source is
> > restricted to generate interveleaved message transactions so we should
> avoid it.
> >
> > Also, while assembling partial reply packets, reading out DPCD
> > DOWN_REP Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag
> should
> > be wrapped up as a complete operation for reading out a reply packet.
> > Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
> > be risky. e.g. If the reply of the new request has overwritten the
> > DPRX DOWN_REP Sideband MSG buffer before source writing one to clear
> > DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
> > for the new request. Should handle the up request in the same way.
> >
> > [How]
> > Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ
> > event, driver calls drm_dp_mst_hpd_irq_step2() and might trigger
> > drm_dp_mst_kick_tx() only when there is no on going message transaction.
> >
> > Changes since v1:
> > * Reworked on review comments received
> > -> Adjust the fix to let driver explicitly kick off new down request
> > when mst irq event is handled and acked
> > -> Adjust the commit message
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  8 ++---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 35
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  5 ++-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  5 ++-
> >  include/drm/display/drm_dp_mst_helper.h   |  4 +--
> >  5 files changed, 45 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 1ad67c2a697e..48bdcb2ee9b1 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -3259,10 +3259,9 @@ static void
> dm_handle_mst_sideband_msg(struct
> > amdgpu_dm_connector *aconnector)
> > DRM_DEBUG_DRIVER("ESI %02x %02x %02x\n", esi[0], esi[1],
> esi[2]);
> > /* handle HPD short pulse irq */
> > if (aconnector->mst_mgr.mst_state)
> > -   drm_dp_mst_hpd_irq(
> > -   &aconnector->mst_mgr,
> > -   esi,
> > -   &new_irq_handled);
> > +   drm_dp_mst_hpd_irq_step1(&aconnector-
> > >mst_mgr,
> > +esi,
> > +&new_irq_handled);
> >
> > if (new_irq_handled) {
> > /* ACK at DPCD to notify down stream */ @@ -3281,6
> > +3280,7 @@ static void dm_handle_mst_sideband_msg(struct
> > amdgpu_dm_connector *aconnector)
> > break;
> > }
> >
> > +   drm_dp_mst_hpd_irq_step2(&aconnector-
> &

RE: [PATCH v2] drm/dp_mst: Clear MSG_RDY flag before sending new message

[Lin, Wayne]

[Public]

Hi Jani,
Thanks for your time!
Comments inline.

> -Original Message-
> From: Jani Nikula 
> Sent: Tuesday, May 16, 2023 6:34 PM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: ly...@redhat.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> ; Lin, Wayne ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH v2] drm/dp_mst: Clear MSG_RDY flag before sending new
> message
>
> On Thu, 27 Apr 2023, Wayne Lin  wrote:
> > [Why]
> > The sequence for collecting down_reply from source perspective should
> > be:
> >
> > Request_n->repeat (get partial reply of Request_n->clear message ready
> > flag to ack DPRX that the message is received) till all partial
> > replies for Request_n are received->new Request_n+1.
> >
> > Now there is chance that drm_dp_mst_hpd_irq() will fire new down
> > request in the tx queue when the down reply is incomplete. Source is
> > restricted to generate interveleaved message transactions so we should
> > avoid it.
> >
> > Also, while assembling partial reply packets, reading out DPCD
> > DOWN_REP Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag
> should
> > be wrapped up as a complete operation for reading out a reply packet.
> > Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
> > be risky. e.g. If the reply of the new request has overwritten the
> > DPRX DOWN_REP Sideband MSG buffer before source writing one to clear
> > DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
> > for the new request. Should handle the up request in the same way.
> >
> > [How]
> > Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ
> > event, driver calls drm_dp_mst_hpd_irq_step2() and might trigger
> > drm_dp_mst_kick_tx() only when there is no on going message transaction.
> >
> > Changes since v1:
> > * Reworked on review comments received
> > -> Adjust the fix to let driver explicitly kick off new down request
> > when mst irq event is handled and acked
> > -> Adjust the commit message
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  8 ++---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 35
> ---
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  5 ++-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  5 ++-
> >  include/drm/display/drm_dp_mst_helper.h   |  4 +--
> >  5 files changed, 45 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 1ad67c2a697e..48bdcb2ee9b1 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -3259,10 +3259,9 @@ static void
> dm_handle_mst_sideband_msg(struct amdgpu_dm_connector *aconnector)
> > DRM_DEBUG_DRIVER("ESI %02x %02x %02x\n", esi[0],
> esi[1], esi[2]);
> > /* handle HPD short pulse irq */
> > if (aconnector->mst_mgr.mst_state)
> > -   drm_dp_mst_hpd_irq(
> > -   &aconnector->mst_mgr,
> > -   esi,
> > -   &new_irq_handled);
> > +   drm_dp_mst_hpd_irq_step1(&aconnector->mst_mgr,
> > +esi,
> > +&new_irq_handled);
> >
> > if (new_irq_handled) {
> > /* ACK at DPCD to notify down stream */ @@ -
> 3281,6 +3280,7 @@
> > static void dm_handle_mst_sideband_msg(struct amdgpu_dm_connector
> *aconnector)
> > break;
> > }
> >
> > +   drm_dp_mst_hpd_irq_step2(&aconnector-
> >mst_mgr);
> > /* check if there is new irq to be handled */
> > dret = drm_dp_dpcd_read(
> > &aconnector->dm_dp_aux.aux,
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 70df29fe92db..2e0a38a6509c 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -4045,7 +4045,7 @@ static int drm_dp_mst_handle_up_req(struct
> > drm_dp_mst_topology_mgr *mgr) 

RE: [PATCH 3/3] drm/mst: adjust the function drm_dp_remove_payload_part2()

[Lin, Wayne]

[AMD Official Use Only - General]

> -Original Message-
> From: Imre Deak 
> Sent: Friday, August 4, 2023 11:32 PM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> drm_dp_remove_payload_part2()
>
> On Fri, Aug 04, 2023 at 02:20:29PM +0800, Wayne Lin wrote:
> > [...]
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index e04f87ff755a..4270178f95f6 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3382,8 +3382,7 @@
> EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> >   * drm_dp_remove_payload_part2() - Remove an MST payload locally
> >   * @mgr: Manager to use.
> >   * @mst_state: The MST atomic state
> > - * @old_payload: The payload with its old state
> > - * @new_payload: The payload with its latest state
> > + * @payload: The payload with its latest state
> >   *
> >   * Updates the starting time slots of all other payloads which would have
> been shifted towards
> >   * the start of the payload ID table as a result of removing a
> > payload. Driver should call this @@ -3392,25 +3391,36 @@
> EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> >   */
> >  void drm_dp_remove_payload_part2(struct drm_dp_mst_topology_mgr
> *mgr,
> >  struct drm_dp_mst_topology_state
> *mst_state,
> > -const struct drm_dp_mst_atomic_payload
> *old_payload,
> > -struct drm_dp_mst_atomic_payload
> *new_payload)
> > +struct drm_dp_mst_atomic_payload
> *payload)
> >  {
> > struct drm_dp_mst_atomic_payload *pos;
> > +   u8 time_slots_to_remove;
> > +   u8 next_payload_vc_start = mgr->next_start_slot;
> > +
> > +   /* Find the current allocated time slot number of the payload */
> > +   list_for_each_entry(pos, &mst_state->payloads, next) {
> > +   if (pos != payload &&
> > +   pos->vc_start_slot > payload->vc_start_slot &&
> > +   pos->vc_start_slot < next_payload_vc_start)
> > +   next_payload_vc_start = pos->vc_start_slot;
> > +   }
> > +
> > +   time_slots_to_remove = next_payload_vc_start -
> > +payload->vc_start_slot;
>
> Imo, the intuitive way would be to pass the old payload state to this 
> function -
> which already contains the required time_slots param - and refactor things
> instead moving vc_start_slot from the payload state to mgr suggested by Ville
> earlier.
>
> --Imre

Hi Imre,
Thanks for your feedback!
I understand it's functionally correct. But IMHO, it's still a bit conceptually
different between the time slot in old state and the time slot in current 
payload
table. My thought is the time slot at the moment when we are removing the
payload would be a better choice. And with this, we can also simplify some
codes. Especially remove workaround in amd driver. In fact, DRM mst code
maintains the payload table and all the time slot info is in it already. We 
don't
really have to pass a new parameter.

>
> > /* Remove local payload allocation */
> > list_for_each_entry(pos, &mst_state->payloads, next) {
> > -   if (pos != new_payload && pos->vc_start_slot > new_payload-
> >vc_start_slot)
> > -   pos->vc_start_slot -= old_payload->time_slots;
> > +   if (pos != payload && pos->vc_start_slot > payload-
> >vc_start_slot)
> > +   pos->vc_start_slot -= time_slots_to_remove;
> > }
> > -   new_payload->vc_start_slot = -1;
> > +   payload->vc_start_slot = -1;
> >
> > mgr->payload_count--;
> > -   mgr->next_start_slot -= old_payload->time_slots;
> > +   mgr->next_start_slot -= time_slots_to_remove;
> >
> > -   if (new_payload->delete)
> > -   drm_dp_mst_put_port_malloc(new_payload->port);
> > +   if (payload->delete)
> > +   drm_dp_mst_put_port_malloc(payload->port);
> >
> > -   new_payload->payload_allocation_status =
> DRM_DP_MST_PAYLOAD_ALLOCATION_NONE;
> > +   payload->payload_allocation_status =
> > +DRM_DP_MST_PAYLOAD_ALLOCATION_NONE;
> >  }

--
Regards,
Wayne

RE: [PATCH v4] drm/dp_mst: Clear MSG_RDY flag before sending new message

[Lin, Wayne]

[Public]

> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, June 8, 2023 8:26 PM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: ly...@redhat.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> ; Lin, Wayne ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH v4] drm/dp_mst: Clear MSG_RDY flag before sending new
> message
>
> On Thu, 08 Jun 2023, Wayne Lin  wrote:
> > [Why]
> > The sequence for collecting down_reply from source perspective should
> > be:
> >
> > Request_n->repeat (get partial reply of Request_n->clear message ready
> > flag to ack DPRX that the message is received) till all partial
> > replies for Request_n are received->new Request_n+1.
> >
> > Now there is chance that drm_dp_mst_hpd_irq() will fire new down
> > request in the tx queue when the down reply is incomplete. Source is
> > restricted to generate interveleaved message transactions so we should
> > avoid it.
> >
> > Also, while assembling partial reply packets, reading out DPCD
> > DOWN_REP Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag
> should
> > be wrapped up as a complete operation for reading out a reply packet.
> > Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
> > be risky. e.g. If the reply of the new request has overwritten the
> > DPRX DOWN_REP Sideband MSG buffer before source writing one to clear
> > DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
> > for the new request. Should handle the up request in the same way.
> >
> > [How]
> > Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ
> > event, driver calls drm_dp_mst_hpd_irq_send_new_request() and might
> > trigger drm_dp_mst_kick_tx() only when there is no on going message
> > transaction.
> >
> > Changes since v1:
> > * Reworked on review comments received
> > -> Adjust the fix to let driver explicitly kick off new down request
> > when mst irq event is handled and acked
> > -> Adjust the commit message
> >
> > Changes since v2:
> > * Adjust the commit message
> > * Adjust the naming of the divided 2 functions and add a new input
> >   parameter "ack".
> > * Adjust code flow as per review comments.
> >
> > Changes since v3:
> > * Update the function description of drm_dp_mst_hpd_irq_handle_event
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 ++--
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 54
> ---
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  7 +--
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 12 +++--
> >  include/drm/display/drm_dp_mst_helper.h   |  7 ++-
> >  5 files changed, 82 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index d5cec03eaa8d..597c3368bcfb 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -3236,6 +3236,7 @@ static void dm_handle_mst_sideband_msg(struct
> > amdgpu_dm_connector *aconnector)  {
> > u8 esi[DP_PSR_ERROR_STATUS - DP_SINK_COUNT_ESI] = { 0 };
> > u8 dret;
> > +   u8 ack;
> > bool new_irq_handled = false;
> > int dpcd_addr;
> > int dpcd_bytes_to_read;
> > @@ -3265,34 +3266,36 @@ static void
> dm_handle_mst_sideband_msg(struct amdgpu_dm_connector *aconnector)
> > process_count < max_process_count) {
> > u8 retry;
> > dret = 0;
> > +   ack = 0;
> >
> > process_count++;
> >
> > DRM_DEBUG_DRIVER("ESI %02x %02x %02x\n", esi[0],
> esi[1], esi[2]);
> > /* handle HPD short pulse irq */
> > if (aconnector->mst_mgr.mst_state)
> > -   drm_dp_mst_hpd_irq(
> > -   &aconnector->mst_mgr,
> > -   esi,
> > -   &new_irq_handled);
> > +   drm_dp_mst_hpd_irq_handle_event(&aconnector-
> >mst_mgr,
> > +   esi,
> > +   &ack,
> > +   &new_irq_handled);
> >
> > if (new_irq

RE: [PATCH v4] drm/dp_mst: Clear MSG_RDY flag before sending new message

[Lin, Wayne]

[Public]

> -Original Message-
> From: Jani Nikula 
> Sent: Friday, June 9, 2023 4:53 PM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: ly...@redhat.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> ; sta...@vger.kernel.org
> Subject: RE: [PATCH v4] drm/dp_mst: Clear MSG_RDY flag before sending new
> message
>
> >> > bool *handled)
> >> > +int drm_dp_mst_hpd_irq_handle_event(struct
> drm_dp_mst_topology_mgr
> >> *mgr, const u8 *esi,
> >> > +   u8 *ack, bool *handled)
> >> >  {
> >> > int ret = 0;
> >> > int sc;
> >> > @@ -4078,18 +4089,47 @@ int drm_dp_mst_hpd_irq(struct
> >> drm_dp_mst_topology_mgr *mgr, u8 *esi, bool *handl
> >> > if (esi[1] & DP_DOWN_REP_MSG_RDY) {
> >> > ret = drm_dp_mst_handle_down_rep(mgr);
> >> > *handled = true;
> >> > +   *ack |= DP_DOWN_REP_MSG_RDY;
> >>
> >> My idea was that esi and ack would be the same size buffers, so the
> >> caller wouldn't have to worry where exactly to point ack to.
> >>
> >> I think the asymmetry here is misleading, with ack and esi having to
> >> point at different locations.
> >>
> > Thanks, Jani.
> >
> > But Event status Indicator Files (DPCD 0x2000h ~ 0x21FFH) are not all
> > designed to be ack clear, e.g. esi[0] here. My thought is to be
> > precise about what is handled and what is going to be ack clear.
> > Otherwise, write ack[0] to DPCD 0x2002h is not reasonable.
>
> The point is that you have the same indexes everywhere, even if ack[0] ends
> up being unused.
>
> Handle esi[1] & DP_DOWN_REP_MSG_RDY, set ack[1] |=
> DP_DOWN_REP_MSG_RDY.
>
> Similar pattern everywhere, drm core and drivers. The only place that needs to
> know the difference is where the ack is written back to DPCD.
>
> If we end up adding more helpers for drm core handling ESI, we'll keep
> repeating the same pattern, instead of passing individual u8 acks everywhere,
> with the driver having to figure out what pointers to pass.
>
> BR,
> Jani.
Thanks, Jani.
Will update another version.

Regards,
Wayne
>
>
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center

RE: [PATCH v5] drm/dp_mst: Clear MSG_RDY flag before sending new message

[Lin, Wayne]

[AMD Official Use Only - General]

Noted. Thanks, Lyude!

Regards,
Wayne Lin

> -Original Message-
> From: Lyude Paul 
> Sent: Tuesday, June 13, 2023 6:34 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; jani.nik...@intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> ; sta...@vger.kernel.org
> Subject: Re: [PATCH v5] drm/dp_mst: Clear MSG_RDY flag before sending new
> message
>
> FWIW: Should have a response to this very soon, figured out the cause of my
> MST issues so I should be able to test this very soon
>
> On Fri, 2023-06-09 at 18:49 +0800, Wayne Lin wrote:
> > [Why]
> > The sequence for collecting down_reply from source perspective should
> > be:
> >
> > Request_n->repeat (get partial reply of Request_n->clear message ready
> > flag to ack DPRX that the message is received) till all partial
> > replies for Request_n are received->new Request_n+1.
> >
> > Now there is chance that drm_dp_mst_hpd_irq() will fire new down
> > request in the tx queue when the down reply is incomplete. Source is
> > restricted to generate interveleaved message transactions so we should
> > avoid it.
> >
> > Also, while assembling partial reply packets, reading out DPCD
> > DOWN_REP Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag
> should
> > be wrapped up as a complete operation for reading out a reply packet.
> > Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
> > be risky. e.g. If the reply of the new request has overwritten the
> > DPRX DOWN_REP Sideband MSG buffer before source writing one to clear
> > DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
> > for the new request. Should handle the up request in the same way.
> >
> > [How]
> > Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ
> > event, driver calls drm_dp_mst_hpd_irq_send_new_request() and might
> > trigger drm_dp_mst_kick_tx() only when there is no on going message
> > transaction.
> >
> > Changes since v1:
> > * Reworked on review comments received
> > -> Adjust the fix to let driver explicitly kick off new down request
> > when mst irq event is handled and acked
> > -> Adjust the commit message
> >
> > Changes since v2:
> > * Adjust the commit message
> > * Adjust the naming of the divided 2 functions and add a new input
> >   parameter "ack".
> > * Adjust code flow as per review comments.
> >
> > Changes since v3:
> > * Update the function description of drm_dp_mst_hpd_irq_handle_event
> >
> > Changes since v4:
> > * Change ack of drm_dp_mst_hpd_irq_handle_event() to be an array align
> >   the size of esi[]
> >
> > Signed-off-by: Wayne Lin 
> > Cc: sta...@vger.kernel.org
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +--
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 54
> ---
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  7 +--
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 12 +++--
> >  include/drm/display/drm_dp_mst_helper.h   |  7 ++-
> >  5 files changed, 81 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index d5cec03eaa8d..ec629b4037e4 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -3263,6 +3263,7 @@ static void dm_handle_mst_sideband_msg(struct
> > amdgpu_dm_connector *aconnector)
> >
> > while (dret == dpcd_bytes_to_read &&
> > process_count < max_process_count) {
> > +   u8 ack[DP_PSR_ERROR_STATUS - DP_SINK_COUNT_ESI] = {};
> > u8 retry;
> > dret = 0;
> >
> > @@ -3271,28 +3272,29 @@ static void
> dm_handle_mst_sideband_msg(struct amdgpu_dm_connector *aconnector)
> > DRM_DEBUG_DRIVER("ESI %02x %02x %02x\n", esi[0],
> esi[1], esi[2]);
> > /* handle HPD short pulse irq */
> > if (aconnector->mst_mgr.mst_state)
> > -   drm_dp_mst_hpd_irq(
> > -   &aconnector->mst_mgr,
> > -   esi,
> > -   &new_irq_handled);
> > +   drm_dp_mst_hpd_irq_handle_event(&aconnector-
> >mst_mgr,
> > + 

RE: [PATCH 3/3] drm/mst: adjust the function drm_dp_remove_payload_part2()

[Lin, Wayne]

[AMD Official Use Only - General]

> -Original Message-
> From: Imre Deak 
> Sent: Tuesday, August 8, 2023 12:00 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> drm_dp_remove_payload_part2()
>
> On Mon, Aug 07, 2023 at 02:43:02AM +, Lin, Wayne wrote:
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Imre Deak 
> > > Sent: Friday, August 4, 2023 11:32 PM
> > > To: Lin, Wayne 
> > > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> > > ly...@redhat.com; jani.nik...@intel.com;
> > > ville.syrj...@linux.intel.com; Wentland, Harry
> > > ; Zuo, Jerry 
> > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > drm_dp_remove_payload_part2()
> > >
> > > On Fri, Aug 04, 2023 at 02:20:29PM +0800, Wayne Lin wrote:
> > > > [...]
> > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > index e04f87ff755a..4270178f95f6 100644
> > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > @@ -3382,8 +3382,7 @@
> > > EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> > > >   * drm_dp_remove_payload_part2() - Remove an MST payload locally
> > > >   * @mgr: Manager to use.
> > > >   * @mst_state: The MST atomic state
> > > > - * @old_payload: The payload with its old state
> > > > - * @new_payload: The payload with its latest state
> > > > + * @payload: The payload with its latest state
> > > >   *
> > > >   * Updates the starting time slots of all other payloads which
> > > > would have
> > > been shifted towards
> > > >   * the start of the payload ID table as a result of removing a
> > > > payload. Driver should call this @@ -3392,25 +3391,36 @@
> > > EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> > > >   */
> > > >  void drm_dp_remove_payload_part2(struct
> drm_dp_mst_topology_mgr
> > > *mgr,
> > > >  struct drm_dp_mst_topology_state
> > > *mst_state,
> > > > -const struct drm_dp_mst_atomic_payload
> > > *old_payload,
> > > > -struct drm_dp_mst_atomic_payload
> > > *new_payload)
> > > > +struct drm_dp_mst_atomic_payload
> > > *payload)
> > > >  {
> > > > struct drm_dp_mst_atomic_payload *pos;
> > > > +   u8 time_slots_to_remove;
> > > > +   u8 next_payload_vc_start = mgr->next_start_slot;
> > > > +
> > > > +   /* Find the current allocated time slot number of the payload */
> > > > +   list_for_each_entry(pos, &mst_state->payloads, next) {
> > > > +   if (pos != payload &&
> > > > +   pos->vc_start_slot > payload->vc_start_slot &&
> > > > +   pos->vc_start_slot < next_payload_vc_start)
> > > > +   next_payload_vc_start = pos->vc_start_slot;
> > > > +   }
> > > > +
> > > > +   time_slots_to_remove = next_payload_vc_start -
> > > > +payload->vc_start_slot;
> > >
> > > Imo, the intuitive way would be to pass the old payload state to
> > > this function - which already contains the required time_slots param
> > > - and refactor things instead moving vc_start_slot from the payload
> > > state to mgr suggested by Ville earlier.
> > >
> > > --Imre
> >
> > Hi Imre,
> > Thanks for your feedback!
> >
> > I understand it's functionally correct. But IMHO, it's still a bit
> > conceptually different between the time slot in old state and the time
> > slot in current payload table. My thought is the time slot at the
> > moment when we are removing the payload would be a better choice.
>
> Yes, they are different. The old state contains the time slot the payload was
> added with in a preceding commit and so the time slot value which should be
> used when removing the same payload in the current commit.
>
> The new state contains a time slot value with which the payload will be added
> in the

RE: [Patch v2 2/3] drm/mst: Refactor the flow for payload allocation/removement

[Lin, Wayne]

[AMD Official Use Only - General]

Thanks for your time, Lyude!

Regards,
Wayne

> -Original Message-
> From: Lyude Paul 
> Sent: Tuesday, August 8, 2023 4:23 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> allocation/removement
>
> Oo! This is a wonderful idea so far - keeping track of the status of
> allocations like this solves a lot of problems, especially with regards to 
> the fact
> this actually seems to make it possible for us to have much better handling of
> payload failures in drivers - especially in situations like suspend/resume. 
> The
> naming changes here are awesome too.
>
> I think this patch is good as far as I can tell review-wise! I haven't been 
> able to
> test it quite yet but I'll do it asap.
>
> On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote:
> > [Why]
> > Today, the allocation/deallocation steps and status is a bit unclear.
> >
> > For instance, payload->vc_start_slot = -1 stands for "the failure of
> > updating DPCD payload ID table" and can also represent as "payload is
> > not allocated yet". These two cases should be handled differently and
> > hence better to distinguish them for better understanding.
> >
> > [How]
> > Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and
> > ALLOCATION_REMOTE to distinguish different allocation status. Adjust
> > the code to handle different status accordingly for better
> > understanding the sequence of payload allocation and payload
> removement.
> >
> > For payload creation, the procedure should look like this:
> > DRM part 1:
> > * step 1 - update sw mst mgr variables to add a new payload
> > * step 2 - add payload at immediate DFP DPCD payload table
> >
> > Driver:
> > * Add new payload in HW and sync up with DFP by sending ACT
> >
> > DRM Part 2:
> > * Send ALLOCATE_PAYLOAD sideband message to allocate bandwidth along
> the
> >   virtual channel.
> >
> > And as for payload removement, the procedure should look like this:
> > DRM part 1:
> > * step 1 - Send ALLOCATE_PAYLOAD sideband message to release bandwidth
> >along the virtual channel
> > * step 2 - Clear payload allocation at immediate DFP DPCD payload
> > table
> >
> > Driver:
> > * Remove the payload in HW and sync up with DFP by sending ACT
> >
> > DRM part 2:
> > * update sw mst mgr variables to remove the payload
> >
> > Note that it's fine to fail when communicate with the branch device
> > connected at immediate downstrean-facing port, but updating variables
> > of SW mst mgr and HW configuration should be conducted anyway. That's
> > because it's under commit_tail and we need to complete the HW
> programming.
>
> yay!
>
> >
> > Changes since v1:
> > * Remove the set but not use variable 'old_payload' in function
> >   'nv50_msto_prepare'. Catched by kernel test robot 
> >
> > Signed-off-by: Wayne Lin 
> > ---
> >  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  20 ++-
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 159 +++--
> -
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  18 +-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  21 +--
> >  include/drm/display/drm_dp_mst_helper.h   |  23 ++-
> >  5 files changed, 153 insertions(+), 88 deletions(-)
> >
> > diff --git
> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index d9a482908380..9ad509279b0a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -219,7 +219,7 @@ static void dm_helpers_construct_old_payload(
> > /* Set correct time_slots/PBN of old payload.
> >  * other fields (delete & dsc_enabled) in
> >  * struct drm_dp_mst_atomic_payload are don't care fields
> > -* while calling drm_dp_remove_payload()
> > +* while calling drm_dp_remove_payload_part2()
> >  */
> > for (i = 0; i < current_link_table.stream_count; i++) {
> > dc_alloc =
> > @@ -262,13 +262,12 @@ bool
> > dm_helpers_dp_mst_write_payload_allocation_table(
> >
> > mst_mgr = &aconnector->mst_root->mst_mgr;
&g

RE: [PATCH 3/3] drm/mst: adjust the function drm_dp_remove_payload_part2()

[Lin, Wayne]

[AMD Official Use Only - General]

> -Original Message-
> From: Imre Deak 
> Sent: Saturday, August 19, 2023 1:46 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> drm_dp_remove_payload_part2()
>
> On Tue, Aug 08, 2023 at 03:47:47AM +, Lin, Wayne wrote:
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Imre Deak 
> > > Sent: Tuesday, August 8, 2023 12:00 AM
> > > To: Lin, Wayne 
> > > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> > > ly...@redhat.com; jani.nik...@intel.com;
> > > ville.syrj...@linux.intel.com; Wentland, Harry
> > > ; Zuo, Jerry 
> > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > drm_dp_remove_payload_part2()
> > >
> > > On Mon, Aug 07, 2023 at 02:43:02AM +, Lin, Wayne wrote:
> > > > [AMD Official Use Only - General]
> > > >
> > > > > -Original Message-
> > > > > From: Imre Deak 
> > > > > Sent: Friday, August 4, 2023 11:32 PM
> > > > > To: Lin, Wayne 
> > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > amd-...@lists.freedesktop.org; ly...@redhat.com;
> > > > > jani.nik...@intel.com; ville.syrj...@linux.intel.com; Wentland,
> > > > > Harry ; Zuo, Jerry 
> > > > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > > > drm_dp_remove_payload_part2()
> > > > >
> > > > > On Fri, Aug 04, 2023 at 02:20:29PM +0800, Wayne Lin wrote:
> > > > > > [...]
> > > > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > index e04f87ff755a..4270178f95f6 100644
> > > > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > @@ -3382,8 +3382,7 @@
> > > > > EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> > > > > >   * drm_dp_remove_payload_part2() - Remove an MST payload
> locally
> > > > > >   * @mgr: Manager to use.
> > > > > >   * @mst_state: The MST atomic state
> > > > > > - * @old_payload: The payload with its old state
> > > > > > - * @new_payload: The payload with its latest state
> > > > > > + * @payload: The payload with its latest state
> > > > > >   *
> > > > > >   * Updates the starting time slots of all other payloads
> > > > > > which would have
> > > > > been shifted towards
> > > > > >   * the start of the payload ID table as a result of removing
> > > > > > a payload. Driver should call this @@ -3392,25 +3391,36 @@
> > > > > EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> > > > > >   */
> > > > > >  void drm_dp_remove_payload_part2(struct
> > > drm_dp_mst_topology_mgr
> > > > > *mgr,
> > > > > >  struct drm_dp_mst_topology_state
> > > > > *mst_state,
> > > > > > -const struct drm_dp_mst_atomic_payload
> > > > > *old_payload,
> > > > > > -struct drm_dp_mst_atomic_payload
> > > > > *new_payload)
> > > > > > +struct drm_dp_mst_atomic_payload
> > > > > *payload)
> > > > > >  {
> > > > > > struct drm_dp_mst_atomic_payload *pos;
> > > > > > +   u8 time_slots_to_remove;
> > > > > > +   u8 next_payload_vc_start = mgr->next_start_slot;
> > > > > > +
> > > > > > +   /* Find the current allocated time slot number of the payload */
> > > > > > +   list_for_each_entry(pos, &mst_state->payloads, next) {
> > > > > > +   if (pos != payload &&
> > > > > > +   pos->vc_start_slot > payload->vc_start_slot &&
> > > > > > +   pos->vc_start_slot < next_payload_vc_start)
> > > > > > +   next_payload_vc_start = pos->vc_start_slot;
> > > &

RE: [Patch v2 2/3] drm/mst: Refactor the flow for payload allocation/removement

[Lin, Wayne]

[Public]

Thanks, Lyude!
Should I push another version to fix the indention?

> -Original Message-
> From: Lyude Paul 
> Sent: Friday, August 18, 2023 6:17 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> allocation/removement
>
> Two small comments:
>
> On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote:
> > [Why]
> > Today, the allocation/deallocation steps and status is a bit unclear.
> >
> > For instance, payload->vc_start_slot = -1 stands for "the failure of
> > updating DPCD payload ID table" and can also represent as "payload is
> > not allocated yet". These two cases should be handled differently and
> > hence better to distinguish them for better understanding.
> >
> > [How]
> > Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and
> > ALLOCATION_REMOTE to distinguish different allocation status. Adjust
> > the code to handle different status accordingly for better
> > understanding the sequence of payload allocation and payload
> removement.
> >
> > For payload creation, the procedure should look like this:
> > DRM part 1:
> > * step 1 - update sw mst mgr variables to add a new payload
> > * step 2 - add payload at immediate DFP DPCD payload table
> >
> > Driver:
> > * Add new payload in HW and sync up with DFP by sending ACT
> >
> > DRM Part 2:
> > * Send ALLOCATE_PAYLOAD sideband message to allocate bandwidth along
> the
> >   virtual channel.
> >
> > And as for payload removement, the procedure should look like this:
> > DRM part 1:
> > * step 1 - Send ALLOCATE_PAYLOAD sideband message to release bandwidth
> >along the virtual channel
> > * step 2 - Clear payload allocation at immediate DFP DPCD payload
> > table
> >
> > Driver:
> > * Remove the payload in HW and sync up with DFP by sending ACT
> >
> > DRM part 2:
> > * update sw mst mgr variables to remove the payload
> >
> > Note that it's fine to fail when communicate with the branch device
> > connected at immediate downstrean-facing port, but updating variables
> > of SW mst mgr and HW configuration should be conducted anyway. That's
> > because it's under commit_tail and we need to complete the HW
> programming.
> >
> > Changes since v1:
> > * Remove the set but not use variable 'old_payload' in function
> >   'nv50_msto_prepare'. Catched by kernel test robot 
> >
> > Signed-off-by: Wayne Lin 
> > ---
> >  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  20 ++-
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 159 +++--
> -
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  18 +-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  21 +--
> >  include/drm/display/drm_dp_mst_helper.h   |  23 ++-
> >  5 files changed, 153 insertions(+), 88 deletions(-)
> >
> > diff --git
> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index d9a482908380..9ad509279b0a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -219,7 +219,7 @@ static void dm_helpers_construct_old_payload(
> > /* Set correct time_slots/PBN of old payload.
> >  * other fields (delete & dsc_enabled) in
> >  * struct drm_dp_mst_atomic_payload are don't care fields
> > -* while calling drm_dp_remove_payload()
> > +* while calling drm_dp_remove_payload_part2()
> >  */
> > for (i = 0; i < current_link_table.stream_count; i++) {
> > dc_alloc =
> > @@ -262,13 +262,12 @@ bool
> > dm_helpers_dp_mst_write_payload_allocation_table(
> >
> > mst_mgr = &aconnector->mst_root->mst_mgr;
> > mst_state = to_drm_dp_mst_topology_state(mst_mgr->base.state);
> > -
> > -   /* It's OK for this to fail */
> > new_payload = drm_atomic_get_mst_payload_state(mst_state,
> > aconnector->mst_output_port);
> >
> > if (enable) {
> > target_payload = new_payload;
> >
> > +   /* It's OK for this to fail */
> > drm_dp_add_payload_part1(mst_mgr, mst_state,
> new_payload);
> > } else {
> > /* constru

RE: [Patch v2 2/3] drm/mst: Refactor the flow for payload allocation/removement

[Lin, Wayne]

[Public]

Hi Lyude,

I'm afraid that I don't have the permissions to push and would like to have
your help. Thanks!

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, August 24, 2023 5:00 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> allocation/removement
>
> Sure - you're also welcome to push the first two patches after fixing the
> indentation if you'd like
>
> On Wed, 2023-08-23 at 03:19 +, Lin, Wayne wrote:
> > [Public]
> >
> > Thanks, Lyude!
> > Should I push another version to fix the indention?
> >
> > > -----Original Message-
> > > From: Lyude Paul 
> > > Sent: Friday, August 18, 2023 6:17 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> > > amd-...@lists.freedesktop.org
> > > Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> > > imre.d...@intel.com; Wentland, Harry ; Zuo,
> > > Jerry 
> > > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> > > allocation/removement
> > >
> > > Two small comments:
> > >
> > > On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote:
> > > > [Why]
> > > > Today, the allocation/deallocation steps and status is a bit unclear.
> > > >
> > > > For instance, payload->vc_start_slot = -1 stands for "the failure
> > > > of updating DPCD payload ID table" and can also represent as
> > > > "payload is not allocated yet". These two cases should be handled
> > > > differently and hence better to distinguish them for better 
> > > > understanding.
> > > >
> > > > [How]
> > > > Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and
> > > > ALLOCATION_REMOTE to distinguish different allocation status.
> > > > Adjust the code to handle different status accordingly for better
> > > > understanding the sequence of payload allocation and payload
> > > removement.
> > > >
> > > > For payload creation, the procedure should look like this:
> > > > DRM part 1:
> > > > * step 1 - update sw mst mgr variables to add a new payload
> > > > * step 2 - add payload at immediate DFP DPCD payload table
> > > >
> > > > Driver:
> > > > * Add new payload in HW and sync up with DFP by sending ACT
> > > >
> > > > DRM Part 2:
> > > > * Send ALLOCATE_PAYLOAD sideband message to allocate bandwidth
> > > > along
> > > the
> > > >   virtual channel.
> > > >
> > > > And as for payload removement, the procedure should look like this:
> > > > DRM part 1:
> > > > * step 1 - Send ALLOCATE_PAYLOAD sideband message to release
> bandwidth
> > > >along the virtual channel
> > > > * step 2 - Clear payload allocation at immediate DFP DPCD payload
> > > > table
> > > >
> > > > Driver:
> > > > * Remove the payload in HW and sync up with DFP by sending ACT
> > > >
> > > > DRM part 2:
> > > > * update sw mst mgr variables to remove the payload
> > > >
> > > > Note that it's fine to fail when communicate with the branch
> > > > device connected at immediate downstrean-facing port, but updating
> > > > variables of SW mst mgr and HW configuration should be conducted
> > > > anyway. That's because it's under commit_tail and we need to
> > > > complete the HW
> > > programming.
> > > >
> > > > Changes since v1:
> > > > * Remove the set but not use variable 'old_payload' in function
> > > >   'nv50_msto_prepare'. Catched by kernel test robot
> > > > 
> > > >
> > > > Signed-off-by: Wayne Lin 
> > > > ---
> > > >  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  20 ++-
> > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 159
> > > > +++--
> > > -
> > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  18 +-
> > > >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  21 +--
> > > >  include/drm/display/drm_dp_mst_helper.h   |  23 ++-
> > > >  5 files changed,

RE: [PATCH] Revert "drm/dp_mst: Remove single tx msg restriction."

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Wentland, Harry 
> Sent: Friday, April 24, 2020 1:53 AM
> To: Lyude Paul ; dri-devel@lists.freedesktop.org
> Cc: David Airlie ; linux-ker...@vger.kernel.org; Sean Paul
> ; Thomas Zimmermann ;
> Lin, Wayne ; Lin, Wayne 
> Subject: Re: [PATCH] Revert "drm/dp_mst: Remove single tx msg restriction."
> 
> On 2020-04-23 12:42 p.m., Lyude Paul wrote:
> > This reverts commit 6bb0942e8f46863a745489cce27efe5be2a3885e.
> >
> > Unfortunately it would appear that the rumors we've heard of sideband
> > message interleaving not being very well supported are true. On the
> > Lenovo ThinkPad Thunderbolt 3 dock that I have, interleaved messages
> > appear to just get dropped:
> >
> >   [drm:drm_dp_mst_wait_tx_reply [drm_kms_helper]] timedout msg send
> >   571ddfd0 2 1
> >   [dp_mst] txmsg cur_offset=2 cur_len=2 seqno=1 state=SENT path_msg=1
> dst=00
> >   [dp_mst]  type=ENUM_PATH_RESOURCES contents:
> >   [dp_mst]  port=2
> >
> > DP descriptor for this hub:
> >   OUI 90-cc-24 dev-ID SYNA3  HW-rev 1.0 SW-rev 3.12 quirks 0x0008
> >
> > It would seem like as well that this is a somewhat well known issue in
> > the field. From section 5.4.2 of the DisplayPort 2.0 specification:
> >
> >   There are MST Sink/Branch devices in the field that do not handle
> >   interleaved message transactions.
> >
> >   To facilitate message transaction handling by downstream devices, an
> >   MST Source device shall generate message transactions in an atomic
> >   manner (i.e., the MST Source device shall not concurrently interleave
> >   multiple message transactions). Therefore, an MST Source device shall
> >   clear the Message_Sequence_No value in the Sideband_MSG_Header to
> 0.
> >
> >   MST Source devices that support field policy updates by way of
> >   software should update the policy to forego the generation of
> >   interleaved message transactions.
> >
Hi Paul,

Appreciate for your time!
Didn't notice it on DP 2.0 spec before :)

Acked-by: Wayne Lin 

> > This is a bit disappointing, as features like HDCP require that we
> > send a sideband request every ~2 seconds for each active stream.
> > However, there isn't really anything in the specification that allows
> > us to accurately probe for interleaved messages.
> >
> > If it ends up being that we -really- need this in the future, we might
> > be able to whitelist hubs where interleaving is known to work-or maybe
> > try some sort of heuristics. But for now, let's just play it safe and
> > not use it.
> >
> 
> Sounds like the DP spec would need an addition bit to indicate actual support
> of interleaved messages by the RX.
> 
> Acked-by: Harry Wentland 
> 
> Harry
> 
> > Signed-off-by: Lyude Paul 
> > Fixes: 6bb0942e8f46 ("drm/dp_mst: Remove single tx msg restriction.")
> > Cc: Wayne Lin 
> > Cc: Sean Paul 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
> >  include/drm/drm_dp_mst_helper.h   |  5 +
> >  2 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 21f10ceb3d6c..03a1496f6120 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1205,6 +1205,8 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> > txmsg->state == DRM_DP_SIDEBAND_TX_SENT) {
> > mstb->tx_slots[txmsg->seqno] = NULL;
> > }
> > +   mgr->is_waiting_for_dwn_reply = false;
> > +
> > }
> >  out:
> > if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) { @@
> > -1214,6 +1216,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> > }
> > mutex_unlock(&mgr->qlock);
> >
> > +   drm_dp_mst_kick_tx(mgr);
> > return ret;
> >  }
> >
> > @@ -2789,9 +2792,11 @@ static void process_single_down_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr)
> > ret = process_single_tx_qlock(mgr, txmsg, false);
> > if (ret == 1) {
> > /* txmsg is sent it should be in the slots now */
> > +   mgr->is_waiting_for_dwn_reply = true;
> > list_del(&txmsg->next);
> > } else if (ret) {
> > DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> > +   mgr->is_w

RE: [Patch v2 2/3] drm/mst: Refactor the flow for payload allocation/removement

[Lin, Wayne]

[Public]

Thank you Lyude and Alex!

Regards,
Wayne
> -Original Message-
> From: Alex Deucher 
> Sent: Saturday, September 2, 2023 3:38 AM
> To: Lyude Paul 
> Cc: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org; jani.nik...@intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> ; ville.syrj...@linux.intel.com
> Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> allocation/removement
>
> On Thu, Aug 31, 2023 at 6:45 PM Lyude Paul  wrote:
> >
> > On Thu, 2023-08-24 at 04:12 +, Lin, Wayne wrote:
> > > [Public]
> > >
> > > Hi Lyude,
> > >
> > > I'm afraid that I don't have the permissions to push and would like
> > > to have your help. Thanks!
> >
> > Whoops, sorry I only just noticed this message. I set a reminder on my
> > phone to bug me to push it tomorrow :), sorry about the delay
> >
>
> Wayne, I don't see why we couldn't give you commit permissions for drm-
> misc.
>
> Alex
>
> > >
> > > > -Original Message-
> > > > From: Lyude Paul 
> > > > Sent: Thursday, August 24, 2023 5:00 AM
> > > > To: Lin, Wayne ;
> > > > dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > > > Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> > > > imre.d...@intel.com; Wentland, Harry ;
> > > > Zuo, Jerry 
> > > > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> > > > allocation/removement
> > > >
> > > > Sure - you're also welcome to push the first two patches after
> > > > fixing the indentation if you'd like
> > > >
> > > > On Wed, 2023-08-23 at 03:19 +, Lin, Wayne wrote:
> > > > > [Public]
> > > > >
> > > > > Thanks, Lyude!
> > > > > Should I push another version to fix the indention?
> > > > >
> > > > > > -Original Message-
> > > > > > From: Lyude Paul 
> > > > > > Sent: Friday, August 18, 2023 6:17 AM
> > > > > > To: Lin, Wayne ;
> > > > > > dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > > > > > Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> > > > > > imre.d...@intel.com; Wentland, Harry ;
> > > > > > Zuo, Jerry 
> > > > > > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for
> > > > > > payload allocation/removement
> > > > > >
> > > > > > Two small comments:
> > > > > >
> > > > > > On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote:
> > > > > > > [Why]
> > > > > > > Today, the allocation/deallocation steps and status is a bit 
> > > > > > > unclear.
> > > > > > >
> > > > > > > For instance, payload->vc_start_slot = -1 stands for "the
> > > > > > > failure of updating DPCD payload ID table" and can also
> > > > > > > represent as "payload is not allocated yet". These two cases
> > > > > > > should be handled differently and hence better to distinguish them
> for better understanding.
> > > > > > >
> > > > > > > [How]
> > > > > > > Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and
> > > > > > > ALLOCATION_REMOTE to distinguish different allocation status.
> > > > > > > Adjust the code to handle different status accordingly for
> > > > > > > better understanding the sequence of payload allocation and
> > > > > > > payload
> > > > > > removement.
> > > > > > >
> > > > > > > For payload creation, the procedure should look like this:
> > > > > > > DRM part 1:
> > > > > > > * step 1 - update sw mst mgr variables to add a new payload
> > > > > > > * step 2 - add payload at immediate DFP DPCD payload table
> > > > > > >
> > > > > > > Driver:
> > > > > > > * Add new payload in HW and sync up with DFP by sending ACT
> > > > > > >
> > > > > > > DRM Part 2:
> > > > > > > * Send ALLOCATE_PAYLOAD sideband message to allocate
> > > > > > > bandwidth alon

RE: [PATCH 3/3] drm/mst: adjust the function drm_dp_remove_payload_part2()

[Lin, Wayne]

[AMD Official Use Only - General]

> -Original Message-
> From: Imre Deak 
> Sent: Friday, August 25, 2023 9:56 PM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> drm_dp_remove_payload_part2()
>
> On Wed, Aug 23, 2023 at 03:16:44AM +, Lin, Wayne wrote:
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Imre Deak 
> > > Sent: Saturday, August 19, 2023 1:46 AM
> > > To: Lin, Wayne 
> > > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> > > ly...@redhat.com; jani.nik...@intel.com;
> > > ville.syrj...@linux.intel.com; Wentland, Harry
> > > ; Zuo, Jerry 
> > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > drm_dp_remove_payload_part2()
> > >
> > > On Tue, Aug 08, 2023 at 03:47:47AM +, Lin, Wayne wrote:
> > > > [AMD Official Use Only - General]
> > > >
> > > > > -Original Message-
> > > > > From: Imre Deak 
> > > > > Sent: Tuesday, August 8, 2023 12:00 AM
> > > > > To: Lin, Wayne 
> > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > amd-...@lists.freedesktop.org; ly...@redhat.com;
> > > > > jani.nik...@intel.com; ville.syrj...@linux.intel.com; Wentland,
> > > > > Harry ; Zuo, Jerry 
> > > > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > > > drm_dp_remove_payload_part2()
> > > > >
> > > > > On Mon, Aug 07, 2023 at 02:43:02AM +, Lin, Wayne wrote:
> > > > > > [AMD Official Use Only - General]
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Imre Deak 
> > > > > > > Sent: Friday, August 4, 2023 11:32 PM
> > > > > > > To: Lin, Wayne 
> > > > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > > > amd-...@lists.freedesktop.org; ly...@redhat.com;
> > > > > > > jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> > > > > > > Wentland, Harry ; Zuo, Jerry
> > > > > > > 
> > > > > > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > > > > > drm_dp_remove_payload_part2()
> > > > > > >
> > > > > > > On Fri, Aug 04, 2023 at 02:20:29PM +0800, Wayne Lin wrote:
> > > > > > > > [...]
> > > > > > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > > > index e04f87ff755a..4270178f95f6 100644
> > > > > > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > > > @@ -3382,8 +3382,7 @@
> > > > > > > EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> > > > > > > >   * drm_dp_remove_payload_part2() - Remove an MST payload
> > > locally
> > > > > > > >   * @mgr: Manager to use.
> > > > > > > >   * @mst_state: The MST atomic state
> > > > > > > > - * @old_payload: The payload with its old state
> > > > > > > > - * @new_payload: The payload with its latest state
> > > > > > > > + * @payload: The payload with its latest state
> > > > > > > >   *
> > > > > > > >   * Updates the starting time slots of all other payloads
> > > > > > > > which would have
> > > > > > > been shifted towards
> > > > > > > >   * the start of the payload ID table as a result of
> > > > > > > > removing a payload. Driver should call this @@ -3392,25
> > > > > > > > +3391,36 @@
> > > > > > > EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> > > > > > > >   */
> > > > > > > >  void drm_dp_remove_payload_part2(struct
> > > > > drm_dp_mst_topology_mgr
> > > > > > > *mgr,
> > > > > > > >  struct
> > > > > > > > drm_dp_mst_topolog

RE: [PATCH 3/3] drm/mst: adjust the function drm_dp_remove_payload_part2()

[Lin, Wayne]

[Public]

> -Original Message-
> From: Imre Deak 
> Sent: Saturday, September 9, 2023 3:18 AM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> drm_dp_remove_payload_part2()
>
> On Thu, Sep 07, 2023 at 03:44:39AM +, Lin, Wayne wrote:
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Imre Deak 
> > > Sent: Friday, August 25, 2023 9:56 PM
> > > To: Lin, Wayne 
> > > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> > > ly...@redhat.com; jani.nik...@intel.com;
> > > ville.syrj...@linux.intel.com; Wentland, Harry
> > > ; Zuo, Jerry 
> > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > drm_dp_remove_payload_part2()
> > >
> > > On Wed, Aug 23, 2023 at 03:16:44AM +, Lin, Wayne wrote:
> > > > [AMD Official Use Only - General]
> > > >
> > > > > -Original Message-
> > > > > From: Imre Deak 
> > > > > Sent: Saturday, August 19, 2023 1:46 AM
> > > > > To: Lin, Wayne 
> > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > amd-...@lists.freedesktop.org; ly...@redhat.com;
> > > > > jani.nik...@intel.com; ville.syrj...@linux.intel.com; Wentland,
> > > > > Harry ; Zuo, Jerry 
> > > > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > > > drm_dp_remove_payload_part2()
> > > > >
> > > > > On Tue, Aug 08, 2023 at 03:47:47AM +, Lin, Wayne wrote:
> > > > > > [AMD Official Use Only - General]
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Imre Deak 
> > > > > > > Sent: Tuesday, August 8, 2023 12:00 AM
> > > > > > > To: Lin, Wayne 
> > > > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > > > amd-...@lists.freedesktop.org; ly...@redhat.com;
> > > > > > > jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> > > > > > > Wentland, Harry ; Zuo, Jerry
> > > > > > > 
> > > > > > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > > > > > drm_dp_remove_payload_part2()
> > > > > > >
> > > > > > > On Mon, Aug 07, 2023 at 02:43:02AM +, Lin, Wayne wrote:
> > > > > > > > [AMD Official Use Only - General]
> > > > > > > >
> > > > > > > > > -Original Message-
> > > > > > > > > From: Imre Deak 
> > > > > > > > > Sent: Friday, August 4, 2023 11:32 PM
> > > > > > > > > To: Lin, Wayne 
> > > > > > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > > > > > amd-...@lists.freedesktop.org; ly...@redhat.com;
> > > > > > > > > jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> > > > > > > > > Wentland, Harry ; Zuo, Jerry
> > > > > > > > > 
> > > > > > > > > Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> > > > > > > > > drm_dp_remove_payload_part2()
> > > > > > > > >
> > > > > > > > > On Fri, Aug 04, 2023 at 02:20:29PM +0800, Wayne Lin wrote:
> > > > > > > > > > [...]
> > > > > > > > > > diff --git
> > > > > > > > > > a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > > > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > > > > > index e04f87ff755a..4270178f95f6 100644
> > > > > > > > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > > > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > > > > > @@ -3382,8 +3382,7 @@
> > > > > > > > > EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> > > > > > > > > >   * drm_dp_remove_payload_part2() - Remove an MST
> > > > > > > > > > payload
> > > > > locally
> > > > > >

RE: [PATCH 3/3] drm/mst: adjust the function drm_dp_remove_payload_part2()

[Lin, Wayne]

[Public]

> -Original Message-
> From: Imre Deak 
> Sent: Tuesday, September 12, 2023 7:19 PM
> To: Lin, Wayne 
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
> 
> Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> drm_dp_remove_payload_part2()
>
> On Tue, Sep 12, 2023 at 07:26:29AM +, Lin, Wayne wrote:
> > [Public]
> > [...]
> > >
> > > I'd like to be sure that the payload is removed with the size it was
> > > added with in the previous commit and as I wrote above not depend
> > > for this on the new payload state with a mixture of old/current/new 
> > > states.
> > > Based on that I'd be ok for instance with a new
> > >
> > > int drm_dp_remove_port_payload(mgr, mst_state, port)
> > >
> > > function which looks up / removes the payload with the time_slots
> > > calculated based on the payload table as in your patch and returns
> > > the calculated time_slots.
> > >
> > > The AMD driver could call the above function and the current
> > > drm_dp_remove_payload(mgr, mst_state, old_payload) function would be
> > >
> > >   time_slots = drm_dp_remove_port_payload(mgr, mst_state,
> > > old_payload->port);
> > >   WARN_ON(time_slots != old_payload->time_slots);
> > >
> > > --Imre
> >
> > Sorry but I might not fully understand what you suggested here. Would
> > like to know if you agree on referring to the time slot number of the
> > payload table at the moment is better then referring
> > old_payload->time_slots for drm_dp_remove_payload()? If you agree on
> > that, my patch actually is just replacing old_payload->time_slots with
> > the more appropriate one. Not adding mixture of old/current but replacing
> the old with the current one.
>
> The new_payload state contains a mixture of old/current/new state at the
> moment and this patch adds more dependency on that, recalculating the old
> payload size from that state. For i915 this recalculation isn't needed, the 
> size is
> already available in the old payload state.
>

I see. Thanks, Imre. So it's about the idea to have another patch to extract 
things
like vc_start_slot out of mst state.

> > And like what I explained in previous example, when calling
> > drm_dp_remove_payload(), the time slot number to be removed shouldn't
> > be constrained to the one in previous commit. The number in the
> > payload table when we're about to remove the payload might be a better
> > choice. Could you elaborate more what's the mixture that this patch is
> adding on, please?
> >
> > As for the changing suggestion, are you suggesting to create a new
> > function
> > drm_dp_remove_port_payload() to wrap up the calculation in my patch?
> > If so, I think that's the consensus to use current time slot number to 
> > replace
> the one in old_payload.
> > Therefore, it doesn't have to pass old_payload to
> > drm_dp_remove_port_payload(), and "WARN_ON(time_slots !=
> > old_payload->time_slots);" is not appropriate as for the example that I gave
> previously.
>
> I meant something like the following:

The change looks good to me. I'll update the patch. Thanks for the help.

>
> diff --git
> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index cbef4ff28cd8a..0555433d8050b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -343,7 +343,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
>   struct amdgpu_dm_connector *aconnector;
>   struct drm_dp_mst_topology_state *mst_state;
>   struct drm_dp_mst_topology_mgr *mst_mgr;
> - struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
> + struct drm_dp_mst_atomic_payload *new_payload;
>   enum mst_progress_status set_flag =
> MST_ALLOCATE_NEW_PAYLOAD;
>   enum mst_progress_status clr_flag =
> MST_CLEAR_ALLOCATED_PAYLOAD;
>   int ret = 0;
> @@ -366,9 +366,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
>   if (enable) {
>   ret = drm_dp_add_payload_part2(mst_mgr, mst_state-
> >base.state, new_payload);
>   } else {
> - dm_helpers_construct_old_payload(stream->link, mst_state-
> >pbn_div,
> -  new_payload, old_payload);
> - drm_dp_remove_pa

RE: [PATCH 2/3] drm/dp_mst: Skip CSN if topology probing is not done yet

[Lin, Wayne]

[Public]

> -Original Message-
> From: Lyude Paul 
> Sent: Saturday, June 29, 2024 1:40 AM
> To: Lin, Wayne ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Cc: jani.nik...@intel.com; imre.d...@intel.com; dan...@ffwll.ch; Wentland,
> Harry ; Zuo, Jerry ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH 2/3] drm/dp_mst: Skip CSN if topology probing is not
> done yet
>
> On Thu, 2024-06-27 at 09:04 +, Lin, Wayne wrote:
> >
> > I understand your concern. My patch will just check whether mst
> > manager starts the probing process or not by confirming whether we
> > sent LINK_ADDRESS to the 1st mst branch already. It will drop the CSN
> > event only when the event comes earlier than the probing. The CSN
> > events occur during topology probing should still have chance to be
> > handled after probing process release the
> > mgr->probe_lock
> > I think. Does this make sense to you please? Thanks!
>
> Yeah - that seems like the perfect solution :), sounds good to me

Thanks, Lyude!
Could you help to merge drm changes - the [PATCH 1/3] and this one
[PATCH 2/3] then please? The last one [PATCH 3/3], changes in amd only,
I'll ping a gain for review. Appreciate : )

>
> >
> > > > } else if (up_req->msg.req_type ==
> > > > DP_RESOURCE_STATUS_NOTIFY) {
> > > > const struct drm_dp_resource_status_notify *res_stat =
> > > > &up_req->msg.u.resource_stat;
> > >
> > > --
> > > 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