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

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

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

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

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 Signed-off-by: Jeevan B <jeevan.b at intel.com>

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

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

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

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

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

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

This is mainly for dropping interlaced modes on DP connectors if the GPU would otherwise display garbage or EVO timesout. It also adds experimental detection of the HDMI clock limit we currently hard limit depending on the GPU generation. Starting with GF110 GPUs, we can retrieve the limit directly from the GPU and may make the hdmimhz parameter obsolete. Testing this series with 2560x1440 or

small update to my last version I sent out. Patches 3-6 are optional and should only improve detecting the max clocks for HDMI and DP, but they didn't underwent big testing and I am a bit concerned, that it might break detecting the DP limits on some boards. Karol Herbst (6): kms/nv50: move nv50_mstm out of the dp union in nouveau_encoder kms/nv50: reject interlaced modes if the hardware

The following commit from about a year ago removed nouveau_dp_dpms() which did steps required to suspend and resume a monitor connected via DisplayPort. commit 0a0afd282fd715dd63d64b243299a64da14f8e8d Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Feb 18 23:17:53 2013 -0500 drm/nv50-/disp: move DP link training to core and train from supervisor My computer with

On 5 May 2014 01:43, Ben Skeggs <skeggsb at gmail.com> wrote: > On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote: >> The following commit from about a year ago removed nouveau_dp_dpms() which >> did steps required to suspend and resume a monitor connected via DisplayPort. >> >> commit 0a0afd282fd715dd63d64b243299a64da14f8e8d