search for: nouveau_dp_probe_dpcd

...tation that the source will check the sink count and reprobe the connector if it's changed - something we don't actually do. As a result, nothing will happen if the user plugs the dongle in before plugging something into the dongle. So, let's fix this by checking the sink count in both nouveau_dp_probe_dpcd() and nouveau_dp_irq(), and reprobing the connector if things change. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_dp.c | 54 ++++++++++++++++++++--- drivers/gpu/drm/nouveau/nouveau_encoder.h | 2 + 2 files changed, 51 insertions(+), 5 deletions(...

...------------- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index d701f09aea645..bb85d81c25244 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -44,7 +44,6 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector, struct nv50_mstm *mstm = NULL; int ret; u8 *dpcd = outp->dp.dpcd; - u8 tmp; ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE); if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) { @@ -56,19 +55,10 @@ nouveau_dp_pro...

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

...++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index f41fa513023fd..a4e07d116972f 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -55,15 +55,13 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector, int ret; u8 *dpcd = outp->dp.dpcd; - ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE); - if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) { - ret = drm_dp_read_desc(aux, &outp->dp.desc, - drm_dp_is_b...

...ntime_put_autosuspend(connector->dev->dev); return ret; diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 005750aeb6d4f..ad852e572cfec 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -61,6 +61,11 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector, mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd); } + ret = drm_dp_read_downstream_info(aux, dpcd, + outp->dp.downstream_ports); + if (ret < 0) + return connector_status_disconnected; + return connector_status_connected; } @@ -176,8...

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

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

Looking at both i915 and nouveau DP drivers, both are setting the first LTTPR (if found) in transparent mode first and then in non-transparent mode, just like the DP v2.0 specification mentions in section 3.6.6.1. Being part of the standard, setting the LTTPR in a specific operation mode can be easily moved in the generic framework. So do that by adding a new helper. Then, the msm DP driver is

Looking at both i915 and nouveau DP drivers, both are setting the first LTTPR (if found) in transparent mode first and then in non-transparent mode, just like the DP v2.0 specification mentions in section 3.6.6.1. Being part of the standard, setting the LTTPR in a specific operation mode can be easily moved in the generic framework. So do that by adding a new helper. Then, the msm DP driver is

Looking at both i915 and nouveau DP drivers, both are setting the first LTTPR (if found) in transparent mode first and then in non-transparent mode, just like the DP v2.0 specification mentions in section 3.6.6.1. Being part of the standard, setting the LTTPR in a specific operation mode can be easily moved in the generic framework. So do that by adding a new helper. Then, the msm DP driver is