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

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>

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>

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

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

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

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

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:

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

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

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

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

On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä <ville.syrjala at linux.intel.com> wrote: > > 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. >