From: Imre Deak <imre.deak@intel.com>
To: Lyude Paul <lyude@redhat.com>
Cc: David Airlie <airlied@linux.ie>,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>,
open list <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
Thomas Zimmermann <tzimmermann@suse.de>,
Wambui Karuga <wambui.karugax@gmail.com>
Subject: Re: [Intel-gfx] [RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()
Date: Mon, 24 Aug 2020 18:46:26 +0300 [thread overview]
Message-ID: <20200824154626.GA19658@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <597b83ace909f97bfefbe15ffbb0370c2101ff0f.camel@redhat.com>
On Fri, Aug 21, 2020 at 01:43:39PM -0400, Lyude Paul wrote:
> [...]
> > The wording is a bit unclear, but as I understand the Standard only
> > calls for the above:
> >
> > """
> > A DP upstream device shall read the capability from DPCD Addresses 00080h
> > through 00083h. A DP Branch device with multiple DFPs shall report the
> > detailed
> > capability information of the lowest DFP number to which a downstream device
> > is connected, consistent with the DisplayID or legacy EDID access routing
> > policy
> > of an SST-only DP Branch device as described in Section 2.1.4.1.
> > """
>
> So-I saw this too, but notice the use of the language "A /DP Branch/ device with
> multiple DFPs shall report the detailed…". This makes me think it's implying
> that this is a requirement for MSTBs and not SST sinks, just a guess.
Not sure either. The above could also refer to an SST branch device with
multiple DFPs (for instance a DP Replicator branch device).
--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Imre Deak <imre.deak-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "David Airlie" <airlied-cv59FeDIM0c@public.gmane.org>,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
"Lucas De Marchi"
<lucas.demarchi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"open list"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
"Gwan-gyeong Mun"
<gwan-gyeong.mun-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Manasi Navare"
<manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Uma Shankar"
<uma.shankar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"José Roberto de Souza"
<jose.souza-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Rodrigo Vivi"
<rodrigo.vivi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Sean Paul" <sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org>,
"Ville Syrjala"
<ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
"Wambui Karuga"
<wambui.karugax-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()
Date: Mon, 24 Aug 2020 18:46:26 +0300 [thread overview]
Message-ID: <20200824154626.GA19658@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <597b83ace909f97bfefbe15ffbb0370c2101ff0f.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Fri, Aug 21, 2020 at 01:43:39PM -0400, Lyude Paul wrote:
> [...]
> > The wording is a bit unclear, but as I understand the Standard only
> > calls for the above:
> >
> > """
> > A DP upstream device shall read the capability from DPCD Addresses 00080h
> > through 00083h. A DP Branch device with multiple DFPs shall report the
> > detailed
> > capability information of the lowest DFP number to which a downstream device
> > is connected, consistent with the DisplayID or legacy EDID access routing
> > policy
> > of an SST-only DP Branch device as described in Section 2.1.4.1.
> > """
>
> So-I saw this too, but notice the use of the language "A /DP Branch/ device with
> multiple DFPs shall report the detailed…". This makes me think it's implying
> that this is a requirement for MSTBs and not SST sinks, just a guess.
Not sure either. The above could also refer to an SST branch device with
multiple DFPs (for instance a DP Replicator branch device).
--Imre
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
WARNING: multiple messages have this Message-ID (diff)
From: Imre Deak <imre.deak@intel.com>
To: Lyude Paul <lyude@redhat.com>
Cc: "David Airlie" <airlied@linux.ie>,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
"Lucas De Marchi" <lucas.demarchi@intel.com>,
"open list" <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
"Gwan-gyeong Mun" <gwan-gyeong.mun@intel.com>,
"Manasi Navare" <manasi.d.navare@intel.com>,
"Uma Shankar" <uma.shankar@intel.com>,
"José Roberto de Souza" <jose.souza@intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Sean Paul" <sean@poorly.run>,
"Wambui Karuga" <wambui.karugax@gmail.com>
Subject: Re: [RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()
Date: Mon, 24 Aug 2020 18:46:26 +0300 [thread overview]
Message-ID: <20200824154626.GA19658@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <597b83ace909f97bfefbe15ffbb0370c2101ff0f.camel@redhat.com>
On Fri, Aug 21, 2020 at 01:43:39PM -0400, Lyude Paul wrote:
> [...]
> > The wording is a bit unclear, but as I understand the Standard only
> > calls for the above:
> >
> > """
> > A DP upstream device shall read the capability from DPCD Addresses 00080h
> > through 00083h. A DP Branch device with multiple DFPs shall report the
> > detailed
> > capability information of the lowest DFP number to which a downstream device
> > is connected, consistent with the DisplayID or legacy EDID access routing
> > policy
> > of an SST-only DP Branch device as described in Section 2.1.4.1.
> > """
>
> So-I saw this too, but notice the use of the language "A /DP Branch/ device with
> multiple DFPs shall report the detailed…". This makes me think it's implying
> that this is a requirement for MSTBs and not SST sinks, just a guess.
Not sure either. The above could also refer to an SST branch device with
multiple DFPs (for instance a DP Replicator branch device).
--Imre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Imre Deak <imre.deak@intel.com>
To: Lyude Paul <lyude@redhat.com>
Cc: "Sean Paul" <sean@poorly.run>,
"Ville Syrjala" <ville.syrjala@linux.intel.com>,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@linux.ie>,
"Lucas De Marchi" <lucas.demarchi@intel.com>,
"open list" <linux-kernel@vger.kernel.org>,
"Gwan-gyeong Mun" <gwan-gyeong.mun@intel.com>,
"Manasi Navare" <manasi.d.navare@intel.com>,
"Uma Shankar" <uma.shankar@intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"José Roberto de Souza" <jose.souza@intel.com>,
"Wambui Karuga" <wambui.karugax@gmail.com>
Subject: Re: [RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()
Date: Mon, 24 Aug 2020 18:46:26 +0300 [thread overview]
Message-ID: <20200824154626.GA19658@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <597b83ace909f97bfefbe15ffbb0370c2101ff0f.camel@redhat.com>
On Fri, Aug 21, 2020 at 01:43:39PM -0400, Lyude Paul wrote:
> [...]
> > The wording is a bit unclear, but as I understand the Standard only
> > calls for the above:
> >
> > """
> > A DP upstream device shall read the capability from DPCD Addresses 00080h
> > through 00083h. A DP Branch device with multiple DFPs shall report the
> > detailed
> > capability information of the lowest DFP number to which a downstream device
> > is connected, consistent with the DisplayID or legacy EDID access routing
> > policy
> > of an SST-only DP Branch device as described in Section 2.1.4.1.
> > """
>
> So-I saw this too, but notice the use of the language "A /DP Branch/ device with
> multiple DFPs shall report the detailed…". This makes me think it's implying
> that this is a requirement for MSTBs and not SST sinks, just a guess.
Not sure either. The above could also refer to an SST branch device with
multiple DFPs (for instance a DP Replicator branch device).
--Imre
next prev parent reply other threads:[~2020-08-24 15:46 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 20:04 [Intel-gfx] [RFC 00/20] drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-12 0:10 ` [Intel-gfx] " Ben Skeggs
2020-08-12 0:10 ` Ben Skeggs
2020-08-12 0:10 ` Ben Skeggs
2020-08-11 20:04 ` [Intel-gfx] [RFC 02/20] drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 03/20] drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 04/20] drm/nouveau/kms/nv50-: Use macros for DP registers " Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 05/20] drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 06/20] drm/nouveau/kms: Search for encoders' connectors properly Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 07/20] drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 08/20] drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 09/20] drm/i915/dp: Extract drm_dp_has_mst() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-19 15:03 ` [Intel-gfx] " Sean Paul
2020-08-19 15:03 ` Sean Paul
2020-08-19 15:03 ` Sean Paul
2020-08-19 15:03 ` Sean Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 10/20] drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-12 0:11 ` [Intel-gfx] " Ben Skeggs
2020-08-12 0:11 ` Ben Skeggs
2020-08-12 0:11 ` Ben Skeggs
2020-08-11 20:04 ` [Intel-gfx] [RFC 11/20] drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 12/20] drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-19 15:15 ` [Intel-gfx] " Sean Paul
2020-08-19 15:15 ` Sean Paul
2020-08-19 15:15 ` Sean Paul
2020-08-19 15:15 ` Sean Paul
2020-08-19 17:28 ` [Intel-gfx] " Lyude Paul
2020-08-19 17:28 ` Lyude Paul
2020-08-19 17:28 ` Lyude Paul
2020-08-19 17:28 ` Lyude Paul
2020-08-19 21:34 ` [Intel-gfx] " Lyude Paul
2020-08-19 21:34 ` Lyude Paul
2020-08-19 21:34 ` Lyude Paul
2020-08-20 22:37 ` [Intel-gfx] " Imre Deak
2020-08-20 22:37 ` Imre Deak
2020-08-20 22:37 ` Imre Deak
2020-08-21 17:43 ` [Intel-gfx] " Lyude Paul
2020-08-21 17:43 ` Lyude Paul
2020-08-21 17:43 ` Lyude Paul
2020-08-21 17:43 ` Lyude Paul
2020-08-24 15:46 ` Imre Deak [this message]
2020-08-24 15:46 ` Imre Deak
2020-08-24 15:46 ` Imre Deak
2020-08-24 15:46 ` Imre Deak
2020-08-11 20:04 ` [Intel-gfx] [RFC 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 15/20] drm/i915/dp: Extract drm_dp_has_sink_count() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-19 15:20 ` [Intel-gfx] " Sean Paul
2020-08-19 15:20 ` Sean Paul
2020-08-19 15:20 ` Sean Paul
2020-08-19 15:20 ` Sean Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 16/20] drm/i915/dp: Extract drm_dp_get_sink_count() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-19 15:25 ` [Intel-gfx] " Sean Paul
2020-08-19 15:25 ` Sean Paul
2020-08-19 15:25 ` Sean Paul
2020-08-19 15:25 ` Sean Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-12 0:13 ` [Intel-gfx] " Ben Skeggs
2020-08-12 0:13 ` Ben Skeggs
2020-08-12 0:13 ` Ben Skeggs
2020-08-11 20:04 ` [Intel-gfx] [RFC 18/20] drm/nouveau/kms: Don't change EDID when it hasn't actually changed Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 19/20] drm/i915/dp: Extract drm_dp_read_dpcd_caps() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-19 15:29 ` [Intel-gfx] " Sean Paul
2020-08-19 15:29 ` Sean Paul
2020-08-19 15:29 ` Sean Paul
2020-08-19 15:29 ` Sean Paul
2020-08-20 16:07 ` [Intel-gfx] " Lyude Paul
2020-08-20 16:07 ` Lyude Paul
2020-08-20 16:07 ` Lyude Paul
2020-08-20 16:07 ` Lyude Paul
2020-08-20 16:49 ` [Intel-gfx] " Lyude Paul
2020-08-20 16:49 ` Lyude Paul
2020-08-20 16:49 ` Lyude Paul
2020-08-20 16:49 ` Lyude Paul
2020-08-11 20:04 ` [Intel-gfx] [RFC 20/20] drm/nouveau/kms: Start using drm_dp_read_dpcd_caps() Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-11 20:04 ` Lyude Paul
2020-08-12 0:14 ` [Intel-gfx] [Nouveau] " Ben Skeggs
2020-08-12 0:14 ` Ben Skeggs
2020-08-12 0:14 ` Ben Skeggs
2020-08-12 0:14 ` Ben Skeggs
2020-08-11 21:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 Patchwork
2020-08-11 21:04 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-08-11 21:27 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-08-11 21:50 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev2) Patchwork
2020-08-11 21:51 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-08-11 22:13 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-08-11 22:17 ` Lyude Paul
2020-08-11 22:44 ` Lyude Paul
2020-08-11 23:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev3) Patchwork
2020-08-11 23:07 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-08-11 23:28 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200824154626.GA19658@ideak-desk.fi.intel.com \
--to=imre.deak@intel.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
--cc=tzimmermann@suse.de \
--cc=wambui.karugax@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.