[PATCH 0/5] Initial DisplayPort OUI probing

[PATCH 0/5] Initial DisplayPort OUI probing

[Adam Jackson]

DisplayPort has an escape hatch by which devices can identify each other.
I'm not super thrilled that it does, since that's just a clever way of
getting the spec to explicitly bless interoperability bugs.  But it may
be useful information when debugging link training problems, and there's
a cute trick you can do on iMacs that I think will require knowing this
information, so we may as well fill it in.

Tested on a Lenovo T500 against a DP->VGA adaptor (which turns out to be
an ST Microelectronics chip, who knew) and an HP LP2480zx (which does
not advertise OUI support, but also harmlessly returns 0s for the OUI
registers if you read them anyway).

- ajax

[PATCH 1/5] drm/dp: Add DPCD OUI register defines

[Adam Jackson]

DisplayPort has an escape hatch by which sources and sinks can identify
each other.  We would prefer not to notice this, but I suspect we're
going to need to.

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 include/drm/drm_dp_helper.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 93df2d7..8ed85b9 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -213,6 +213,10 @@
 # define DP_TEST_NAK			    (1 << 1)
 # define DP_TEST_EDID_CHECKSUM_WRITE	    (1 << 2)
 
+#define DP_SOURCE_OUI			    0x300
+#define DP_SINK_OUI			    0x400
+#define DP_BRANCH_OUI			    0x500
+
 #define DP_SET_POWER                        0x600
 # define DP_SET_POWER_D0                    0x1
 # define DP_SET_POWER_D3                    0x2
-- 
1.7.7.6

[PATCH 2/5] drm/dp: Add DPCD defines for register 0x007

[Adam Jackson]

Low four bits are downstream port count.  High bit indicates peer OUI
support.  OUI matching will allow us to do additional per-sink handling
for things like DP->VGA bandwidth limits or (hopefully) the iMac-as-
display hack.

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 include/drm/drm_dp_helper.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8ed85b9..1744b18c 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -72,6 +72,10 @@
 
 #define DP_MAIN_LINK_CHANNEL_CODING         0x006
 
+#define DP_DOWN_STREAM_PORT_COUNT	    0x007
+#define  DP_PORT_COUNT_MASK		    0x0f
+#define  DP_OUI_SUPPORT			    (1 << 7)
+
 #define DP_EDP_CONFIGURATION_CAP            0x00d
 #define DP_TRAINING_AUX_RD_INTERVAL         0x00e
 
-- 
1.7.7.6

[PATCH 3/5] drm/i915/dp: Probe branch/sink OUIs

[Adam Jackson]

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 drivers/gpu/drm/i915/intel_dp.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4b63791..cc8e1ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1954,6 +1954,23 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
 	return false;
 }
 
+static void
+intel_dp_probe_oui(struct intel_dp *intel_dp)
+{
+	u8 buf[3];
+
+	if (!(intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
+		return;
+
+	if (intel_dp_aux_native_read_retry(intel_dp, DP_SINK_OUI, buf, 3))
+		DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
+			      buf[0], buf[1], buf[2]);
+
+	if (intel_dp_aux_native_read_retry(intel_dp, DP_BRANCH_OUI, buf, 3))
+		DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
+			      buf[0], buf[1], buf[2]);
+}
+
 static bool
 intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 *sink_irq_vector)
 {
@@ -2137,6 +2154,8 @@ intel_dp_detect(struct drm_connector *connector, bool force)
 	if (status != connector_status_connected)
 		return status;
 
+	intel_dp_probe_oui(intel_dp);
+
 	if (intel_dp->force_audio != HDMI_AUDIO_AUTO) {
 		intel_dp->has_audio = (intel_dp->force_audio == HDMI_AUDIO_ON);
 	} else {
-- 
1.7.7.6

[PATCH 4/5] drm/radeon/dp: Probe branch/sink OUIs

[Adam Jackson]

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 drivers/gpu/drm/radeon/atombios_dp.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index c57d856..9282649 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -533,6 +533,23 @@ u8 radeon_dp_getsinktype(struct radeon_connector *radeon_connector)
 					 dig_connector->dp_i2c_bus->rec.i2c_id, 0);
 }
 
+static void radeon_dp_probe_oui(struct radeon_connector *radeon_connector)
+{
+	struct radeon_connector_atom_dig *dig_connector = radeon_connector->con_priv;
+	u8 buf[3];
+
+	if (!(dig_connector->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
+		return;
+
+	if (radeon_dp_aux_native_read(radeon_connector, DP_SINK_OUI, buf, 3, 0))
+		DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
+			      buf[0], buf[1], buf[2]);
+
+	if (radeon_dp_aux_native_read(radeon_connector, DP_BRANCH_OUI, buf, 3, 0))
+		DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
+			      buf[0], buf[1], buf[2]);
+}
+
 bool radeon_dp_getdpcd(struct radeon_connector *radeon_connector)
 {
 	struct radeon_connector_atom_dig *dig_connector = radeon_connector->con_priv;
@@ -546,6 +563,9 @@ bool radeon_dp_getdpcd(struct radeon_connector *radeon_connector)
 		for (i = 0; i < 8; i++)
 			DRM_DEBUG_KMS("%02x ", msg[i]);
 		DRM_DEBUG_KMS("\n");
+
+		radeon_dp_probe_oui(radeon_connector);
+
 		return true;
 	}
 	dig_connector->dpcd[0] = 0;
-- 
1.7.7.6

[PATCH 5/5] drm/nouveau/dp: Probe branch/sink OUIs

[Adam Jackson]

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 drivers/gpu/drm/nouveau/nouveau_dp.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c
index d996134..bc50c7d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -510,6 +510,25 @@ nouveau_dp_dpms(struct drm_encoder *encoder, int mode, u32 datarate,
 		nouveau_dp_link_train(encoder, datarate, func);
 }
 
+static void
+nouveau_dp_probe_oui(struct drm_device *dev, nouveau_i2c_chan *auxch,
+		     u8 *dpcd)
+{
+	u8 buf[3];
+
+	if (!(dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
+		return;
+
+	if (!auxch_tx(dev, auxch->drive, 9, DP_SINK_OUI, buf, 3))
+		NV_DEBUG_KMS(dev, "Sink OUI: %02hx%02hx%02hx\n",
+			     buf[0], buf[1], buf[2]);
+
+	if (!auxch_tx(dev, auxch->drive, 9, DP_BRANCH_OUI, buf, 3))
+		NV_DEBUG_KMS(dev, "Branch OUI: %02hx%02hx%02hx\n",
+			     buf[0], buf[1], buf[2]);
+
+}
+
 bool
 nouveau_dp_detect(struct drm_encoder *encoder)
 {
@@ -544,6 +563,8 @@ nouveau_dp_detect(struct drm_encoder *encoder)
 	NV_DEBUG_KMS(dev, "maximum: %dx%d\n",
 		     nv_encoder->dp.link_nr, nv_encoder->dp.link_bw);
 
+	nouveau_dp_probe_oui(dev, auxch, dpcd);
+
 	return true;
 }
 
-- 
1.7.7.6

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 776 bytes --]

On Mon, 2012-05-14 at 16:05 -0400, Adam Jackson wrote:
> DisplayPort has an escape hatch by which devices can identify each other.
> I'm not super thrilled that it does, since that's just a clever way of
> getting the spec to explicitly bless interoperability bugs.  But it may
> be useful information when debugging link training problems, and there's
> a cute trick you can do on iMacs that I think will require knowing this
> information, so we may as well fill it in.
> 
> Tested on a Lenovo T500 against a DP->VGA adaptor (which turns out to be
> an ST Microelectronics chip, who knew) and an HP LP2480zx (which does
> not advertise OUI support, but also harmlessly returns 0s for the OUI
> registers if you read them anyway).

Bump.  Any takers?

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Jerome Glisse]

On Mon, May 21, 2012 at 1:41 PM, Adam Jackson <ajax@redhat.com> wrote:
> On Mon, 2012-05-14 at 16:05 -0400, Adam Jackson wrote:
>> DisplayPort has an escape hatch by which devices can identify each other.
>> I'm not super thrilled that it does, since that's just a clever way of
>> getting the spec to explicitly bless interoperability bugs.  But it may
>> be useful information when debugging link training problems, and there's
>> a cute trick you can do on iMacs that I think will require knowing this
>> information, so we may as well fill it in.
>>
>> Tested on a Lenovo T500 against a DP->VGA adaptor (which turns out to be
>> an ST Microelectronics chip, who knew) and an HP LP2480zx (which does
>> not advertise OUI support, but also harmlessly returns 0s for the OUI
>> registers if you read them anyway).
>
> Bump.  Any takers?
>
> - ajax
>

Radeon & core drm part looks good to me, so Reviewed-by: Jerome Glisse
<jglisse@redhat.com>

But i am not sure how useful this is, i want to blind my eyes and keep
thinking no hw manufacturer will abuse the oui stuff.

Cheers,
Jerome

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Daniel Vetter]

On Mon, May 21, 2012 at 01:41:47PM -0400, Adam Jackson wrote:
> On Mon, 2012-05-14 at 16:05 -0400, Adam Jackson wrote:
> > DisplayPort has an escape hatch by which devices can identify each other.
> > I'm not super thrilled that it does, since that's just a clever way of
> > getting the spec to explicitly bless interoperability bugs.  But it may
> > be useful information when debugging link training problems, and there's
> > a cute trick you can do on iMacs that I think will require knowing this
> > information, so we may as well fill it in.
> > 
> > Tested on a Lenovo T500 against a DP->VGA adaptor (which turns out to be
> > an ST Microelectronics chip, who knew) and an HP LP2480zx (which does
> > not advertise OUI support, but also harmlessly returns 0s for the OUI
> > registers if you read them anyway).
> 
> Bump.  Any takers?

I have no clue about this (still trying to get hold of the dp spec), but I
fear we need this. So

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Alex Deucher]

On Mon, May 21, 2012 at 2:47 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, May 21, 2012 at 01:41:47PM -0400, Adam Jackson wrote:
>> On Mon, 2012-05-14 at 16:05 -0400, Adam Jackson wrote:
>> > DisplayPort has an escape hatch by which devices can identify each other.
>> > I'm not super thrilled that it does, since that's just a clever way of
>> > getting the spec to explicitly bless interoperability bugs.  But it may
>> > be useful information when debugging link training problems, and there's
>> > a cute trick you can do on iMacs that I think will require knowing this
>> > information, so we may as well fill it in.
>> >
>> > Tested on a Lenovo T500 against a DP->VGA adaptor (which turns out to be
>> > an ST Microelectronics chip, who knew) and an HP LP2480zx (which does
>> > not advertise OUI support, but also harmlessly returns 0s for the OUI
>> > registers if you read them anyway).
>>
>> Bump.  Any takers?
>
> I have no clue about this (still trying to get hold of the dp spec), but I
> fear we need this. So
>

I'm pretty sure it's needed for looking up the display topology for
things like DP 1.2 MST.  We probably need to decide on some changes to
the DRM KMS topology to deal with multiple displays being driven from
a single connector (sub-connectors maybe?).  A single port could
potentially drive a HDMI monitor or a DVI monitor or one or more DP
monitors.

Acked-by: Alex Deucher <alexander.deucher@amd.com>

> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> --
> Daniel Vetter
> Mail: daniel@ffwll.ch
> Mobile: +41 (0)79 365 57 48
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]

On Mon, 2012-05-21 at 15:27 -0400, Alex Deucher wrote:

> I'm pretty sure it's needed for looking up the display topology for
> things like DP 1.2 MST.  We probably need to decide on some changes to
> the DRM KMS topology to deal with multiple displays being driven from
> a single connector (sub-connectors maybe?).  A single port could
> potentially drive a HDMI monitor or a DVI monitor or one or more DP
> monitors.
> 
> Acked-by: Alex Deucher <alexander.deucher@amd.com>

I had been considering MST to be multiple CRTCs and some quasi-virtual
connectors.  Does that not match the hardware?

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Alex Deucher]

On Mon, May 21, 2012 at 4:11 PM, Adam Jackson <ajax@redhat.com> wrote:
> On Mon, 2012-05-21 at 15:27 -0400, Alex Deucher wrote:
>
>> I'm pretty sure it's needed for looking up the display topology for
>> things like DP 1.2 MST.  We probably need to decide on some changes to
>> the DRM KMS topology to deal with multiple displays being driven from
>> a single connector (sub-connectors maybe?).  A single port could
>> potentially drive a HDMI monitor or a DVI monitor or one or more DP
>> monitors.
>>
>> Acked-by: Alex Deucher <alexander.deucher@amd.com>
>
> I had been considering MST to be multiple CRTCs and some quasi-virtual
> connectors.  Does that not match the hardware?

That's the basic idea.  At the hw level you have multiple crtcs and
digital encoders feeding a single digital phy which is wired to a
connector on the board.  The phy takes care of muxing the source
streams.  MST works by enclosing multiple video streams (plus optional
secondary streams like audio) into VC (virtual channel) packets.  The
VC packets are scheduled into timeslots in the main link timing.
Setup is via aux.  The DP bus starts to look more like a network.
Additionally, you can tunnel other things like USB.  Should be "fun."

Alex

>
> - ajax

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1468 bytes --]

On Mon, 2012-05-21 at 16:35 -0400, Alex Deucher wrote:
> On Mon, May 21, 2012 at 4:11 PM, Adam Jackson <ajax@redhat.com> wrote:
> > I had been considering MST to be multiple CRTCs and some quasi-virtual
> > connectors.  Does that not match the hardware?
> 
> That's the basic idea.  At the hw level you have multiple crtcs and
> digital encoders feeding a single digital phy which is wired to a
> connector on the board.  The phy takes care of muxing the source
> streams.  MST works by enclosing multiple video streams (plus optional
> secondary streams like audio) into VC (virtual channel) packets.  The
> VC packets are scheduled into timeslots in the main link timing.
> Setup is via aux.  The DP bus starts to look more like a network.

Right, my question was more whether there'd be an issue with using CRTCs
and connectors as we already have them, or whether it's something new
we'd need to teach userspace about.  Certainly it might be ugly to have
DP-0.0 through DP-0.16, but functionally it doesn't seem like a big
deal.

> Additionally, you can tunnel other things like USB.  Should be "fun."

Yeah, ethernet too if the marketing material is to be believed.
Definitely going to need a more sophisticated bandwidth calculator at
minimum.  How complete is the USB support?  Like, do isochronous
transfers have to work?  They already don't work very well on real USB,
I can't imagine it working better on a contended link.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Alex Deucher]

On Mon, May 21, 2012 at 5:09 PM, Adam Jackson <ajax@redhat.com> wrote:
> On Mon, 2012-05-21 at 16:35 -0400, Alex Deucher wrote:
>> On Mon, May 21, 2012 at 4:11 PM, Adam Jackson <ajax@redhat.com> wrote:
>> > I had been considering MST to be multiple CRTCs and some quasi-virtual
>> > connectors.  Does that not match the hardware?
>>
>> That's the basic idea.  At the hw level you have multiple crtcs and
>> digital encoders feeding a single digital phy which is wired to a
>> connector on the board.  The phy takes care of muxing the source
>> streams.  MST works by enclosing multiple video streams (plus optional
>> secondary streams like audio) into VC (virtual channel) packets.  The
>> VC packets are scheduled into timeslots in the main link timing.
>> Setup is via aux.  The DP bus starts to look more like a network.
>
> Right, my question was more whether there'd be an issue with using CRTCs
> and connectors as we already have them, or whether it's something new
> we'd need to teach userspace about.  Certainly it might be ugly to have
> DP-0.0 through DP-0.16, but functionally it doesn't seem like a big
> deal.

Exposing DP-0.0 to DP-0.x would probably be the easiest, but it's
certainly ugly.  I suppose ideally we'd make monitors a top level
object and allow a one to many abstraction between connectors and
monitors. Or expose some sort of connector bus that would just have
one endpoint on legacy connectors, but support advanced topologies on
DP 1.2.

It could get a little tricky teaching the current driver how to do an
MST modeset since right now the drm encoders generally represent both
the digital encoder and phy hardware.  Ideally we'd have some extra
level of abstraction, but that could be kept internal to the drivers.

>
>> Additionally, you can tunnel other things like USB.  Should be "fun."
>
> Yeah, ethernet too if the marketing material is to be believed.
> Definitely going to need a more sophisticated bandwidth calculator at
> minimum.  How complete is the USB support?  Like, do isochronous
> transfers have to work?  They already don't work very well on real USB,
> I can't imagine it working better on a contended link.

I don't know.  All I know was gleaned from snippets that I read in
marketing and internal docs.  I'm sure our display team knows the
finer points.  This seems like a place were we could share some common
kernel infrastructure across drivers.

Alex

>
> - ajax

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Dave Airlie]

On Mon, May 14, 2012 at 9:05 PM, Adam Jackson <ajax@redhat.com> wrote:
> DisplayPort has an escape hatch by which devices can identify each other.
> I'm not super thrilled that it does, since that's just a clever way of
> getting the spec to explicitly bless interoperability bugs.  But it may
> be useful information when debugging link training problems, and there's
> a cute trick you can do on iMacs that I think will require knowing this
> information, so we may as well fill it in.
>
> Tested on a Lenovo T500 against a DP->VGA adaptor (which turns out to be
> an ST Microelectronics chip, who knew) and an HP LP2480zx (which does
> not advertise OUI support, but also harmlessly returns 0s for the OUI
> registers if you read them anyway).

I've taken this after I fixed nouveau compile you missed a struct on
the probe function,

So hopefully someone on nouveau + DP can see it works.

Dave.