similar to: [PATCH v4 5/7] drm/nouveau: utilize subconnector property for DP

This should probably be fixed to account for the scenario where an HDMI connector is plugged directly into the DP++ port. I don't think the dp.subconnector property will be valid in that case. (Unfortunately I don't remember how one detects that particular situation.) On Mon, Aug 26, 2019 at 9:22 AM Oleg Vasilev <oleg.vasilev at intel.com> wrote: > > Since DP-specific

From: Oleg Vasilev <oleg.vasilev at intel.com> Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: rebase Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b at intel.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com>

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Reviewed-by: Emil Velikov <emil.velikov at collabora.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 13

From: Oleg Vasilev <oleg.vasilev at intel.com> Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: rebase v3: renamed a function call Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b at intel.com> Signed-off-by: Oleg Vasilev

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Reviewed-by: Emil Velikov <emil.velikov at collabora.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b at intel.com>

On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote: > This should probably be fixed to account for the scenario where an > HDMI connector is plugged directly into the DP++ port. I don't think > the dp.subconnector property will be valid in that case. > (Unfortunately I don't remember how one detects that particular > situation.) One may or may not be able to detect

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++++++++++++ drivers/gpu/drm/nouveau/nouveau_dp.c | 9 +++++++++

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++++++++++++ drivers/gpu/drm/nouveau/nouveau_dp.c | 9 +++++++++

From: Oleg Vasilev <oleg.vasilev at intel.com> Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: rebase Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b at intel.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com>

Hi Oleg, On 2019/07/15, Oleg Vasilev wrote: > Since DP-specific information is stored in driver's structures, every > driver needs to implement subconnector property by itself. > > Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> > Cc: nouveau at lists.freedesktop.org > --- > drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++++++++++++ >

(adding Ville and Imre to the cc here, they might be interested to know about this, comments down below) On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > > We're going to be doing the same probing process in nouveau for > > determining downstream DP port capabilities, so let's deduplicate the > > work

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8a0f7994e1aeb..ee778ddc95fae 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -76,10 +76,10 @@

On Fri, 2020-08-21 at 01:37 +0300, Imre Deak wrote: > On Wed, Aug 19, 2020 at 05:34:15PM -0400, Lyude Paul wrote: > > (adding Ville and Imre to the cc here, they might be interested to know > > about > > this, comments down below) > > > > On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > > > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:

This adds support for querying the maximum clock rate of a downstream port on a DisplayPort connection. Generally, downstream ports refer to active dongles which can have their own pixel clock limits. Note as well, we also start marking the connector as disconnected if we can't read the DPCD, since we wouldn't be able to do anything without DPCD access anyway. Signed-off-by: Lyude Paul

This is another bit that we never implemented for nouveau: dongle detection. When a "dongle", e.g. an active display adaptor, is hooked up to the system and causes an HPD to be fired, we don't actually know whether or not there's anything plugged into the dongle without checking the sink count. As a result, plugging in a dongle without anything plugged into it currently results

We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_read_downstream_info(). Note that when we do this, we also do make some functional changes while we're at it: * We always clear the downstream port info before trying to read

On Wed, Aug 19, 2020 at 05:34:15PM -0400, Lyude Paul wrote: > (adding Ville and Imre to the cc here, they might be interested to know about > this, comments down below) > > On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > > > We're going to be doing the same probing process in nouveau for > >

On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > We're going to be doing the same probing process in nouveau for > determining downstream DP port capabilities, so let's deduplicate the > work by moving i915's code for handling this into a shared helper: > drm_dp_downstream_read_info(). > > Note that when we do this, we also do make some functional

Currently, the nv50_mstc_mode_valid() function is happy to take any and all modes, even the ones we can't actually support sometimes like interlaced modes. Luckily, the only difference between the mode validation that needs to be performed for MST vs. SST is that eventually we'll need to check the minimum PBN against the MSTB's full PBN capabilities (remember-we don't care about

We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_downstream_read_info(). Note that when we do this, we also do make some functional changes while we're at it: * We always clear the downstream port info before trying to read