Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1274206 > unrolled thread
| Started by | cpaul@redhat.com |
|---|---|
| First post | 2015-11-20 17:00 +0100 |
| Last post | 2015-11-23 10:00 +0100 |
| Articles | 9 — 6 participants |
Back to article view | Back to linux.kernel
[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt cpaul@redhat.com - 2015-11-20 17:00 +0100
Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt Daniel Stone <daniel@fooishbar.org> - 2015-11-21 15:50 +0100
Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt Lyude <cpaul@redhat.com> - 2015-11-23 03:50 +0100
RE: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt "Deucher, Alexander" <Alexander.Deucher@amd.com> - 2015-11-23 15:40 +0100
Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt Lyude <cpaul@redhat.com> - 2015-11-23 16:50 +0100
Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt Lyude <cpaul@redhat.com> - 2015-11-23 18:50 +0100
Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt Daniel Vetter <daniel@ffwll.ch> - 2015-11-23 10:00 +0100
Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt Christian König <christian.koenig@amd.com> - 2015-11-21 16:00 +0100
Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt Daniel Vetter <daniel@ffwll.ch> - 2015-11-23 10:00 +0100
| From | cpaul@redhat.com |
|---|---|
| Date | 2015-11-20 17:00 +0100 |
| Subject | [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qwWgp-IS-1@gated-at.bofh.it> |
From: Stephen Chandler Paul <cpaul@redhat.com>
HPD signals on DVI ports can be fired off before the pins required for
DDC probing actually make contact, due to the pins for HPD making
contact first. This results in a HPD signal being asserted but DDC
probing failing, resulting in hotplugging occasionally failing.
This is somewhat rare on most cards (depending on what angle you plug
the DVI connector in), but on some cards it happens constantly. The
Radeon R5 on the machine used for testing this patch for instance, runs
into this issue just about every time I try to hotplug a DVI monitor and
as a result hotplugging almost never works.
Rescheduling the hotplug work for a second when we run into an HPD
signal with a failing DDC probe usually gives enough time for the rest
of the connector's pins to make contact, and fixes this issue.
Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com>
---
So this one has kind of been a tough sell with Jerome, mostly because it's
somewhat of a hack. Unfortunately however I've managed to find machines where
DVI hotplugging literally doesn't work without a patch like this. We've already
tried a couple of ways of handling the situation of retriggering ddc probes:
* Trying the DDC probe in the radeon_dvi_detect() function multiple times.
* Trying to reschedule the hotplug_work task whenever DDC probing fails on DVI
but we got a hpd signal (this ended up being a much more complicated patch
then anticipated)
* Doing what we do right now, which is just triggering userspace to rescan all
the ports when the hpd signal is asserted by the DVI port but there's no DDC
probe, and repeating until at least a second passes.
All of these actually work, but I guess it's a question of which one is less of
a hack. If anyone here can think of a cleaner way of handling this feel free to
let me know.
drivers/gpu/drm/radeon/radeon.h | 3 +++
drivers/gpu/drm/radeon/radeon_connectors.c | 20 +++++++++++++++++---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 ++
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b6cbd81..d63f0fe 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2460,6 +2460,9 @@ struct radeon_device {
/* amdkfd interface */
struct kfd_dev *kfd;
+ /* last time we received an hpd signal */
+ unsigned long hpd_time;
+
struct mutex mn_lock;
DECLARE_HASHTABLE(mn_hash, 7);
};
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5a2cafb..4ee9440 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1228,19 +1228,33 @@ radeon_dvi_detect(struct drm_connector *connector, bool force)
const struct drm_encoder_helper_funcs *encoder_funcs;
int i, r;
enum drm_connector_status ret = connector_status_disconnected;
- bool dret = false, broken_edid = false;
+ bool dret = false, broken_edid = false, hpd_unchanged;
r = pm_runtime_get_sync(connector->dev->dev);
if (r < 0)
return connector_status_disconnected;
- if (!force && radeon_check_hpd_status_unchanged(connector)) {
+ hpd_unchanged = radeon_check_hpd_status_unchanged(connector);
+ if (!force && hpd_unchanged) {
ret = connector->status;
goto exit;
}
- if (radeon_connector->ddc_bus)
+ if (radeon_connector->ddc_bus) {
dret = radeon_ddc_probe(radeon_connector, false);
+
+ /* Sometimes the pins required for the DDC probe on DVI
+ * connectors don't make contact at the same time that the ones
+ * for HPD do. If the DDC probe fails even though we had an HPD
+ * signal, signal userspace to try again */
+ if (!dret && !hpd_unchanged &&
+ connector->status != connector_status_connected &&
+ time_before(jiffies, rdev->hpd_time + msecs_to_jiffies(1000))) {
+ DRM_DEBUG_KMS("%s: hpd asserted but ddc probe failed, retrying\n",
+ connector->name);
+ drm_sysfs_hotplug_event(dev);
+ }
+ }
if (dret) {
radeon_connector->detected_by_load = false;
radeon_connector_free_edid(connector);
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 171d3e4..579c22c 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -79,6 +79,8 @@ static void radeon_hotplug_work_func(struct work_struct *work)
struct drm_mode_config *mode_config = &dev->mode_config;
struct drm_connector *connector;
+ rdev->hpd_time = jiffies;
+
/* we can race here at startup, some boards seem to trigger
* hotplug irqs when they shouldn't. */
if (!rdev->mode_info.mode_config_initialized)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Daniel Stone <daniel@fooishbar.org> |
|---|---|
| Date | 2015-11-21 15:50 +0100 |
| Subject | Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qxhEd-6AU-13@gated-at.bofh.it> |
| In reply to | #1274206 |
Hi, On 21 November 2015 at 14:22, Christian König <christian.koenig@amd.com> wrote: > On 20.11.2015 16:52, cpaul@redhat.com wrote: >> This is somewhat rare on most cards (depending on what angle you plug >> the DVI connector in), but on some cards it happens constantly. The >> Radeon R5 on the machine used for testing this patch for instance, runs >> into this issue just about every time I try to hotplug a DVI monitor and >> as a result hotplugging almost never works. >> >> Rescheduling the hotplug work for a second when we run into an HPD >> signal with a failing DDC probe usually gives enough time for the rest >> of the connector's pins to make contact, and fixes this issue. >> >> Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com> > > > Yeah, that's something I always wondered a about bit as well. > > Debouncing is something very common done in electronics, but as far as I > know the HPD pins don't necessary have an RC circuit so we might need to > handle this case in software here. > > A delay of something between 10-30ms between the last HPD interrupt and > further processing of the signal doesn't sounds like such a bad idea. > > Retrying on the other hand doesn't necessarily improve the situation cause > the delay introduced by this might not be enough. > > So I would rather vote for a fixed delay between an HPD interrupt and > actually starting to process anything. Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. those on marginal power) which send you HPD storms as well. But DP relies on 'short HPD' pulses which can be as brief as 2ms. So attempting to totally debounce all HPD won't work. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lyude <cpaul@redhat.com> |
|---|---|
| Date | 2015-11-23 03:50 +0100 |
| Subject | Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qxPmy-44f-1@gated-at.bofh.it> |
| In reply to | #1274672 |
On Sat, 2015-11-21 at 16:22 +0100, Christian König wrote: > On 21.11.2015 15:49, Daniel Stone wrote: > > Hi, > > > > On 21 November 2015 at 14:22, Christian König <christian.koenig@amd > > .com> wrote: > > > On 20.11.2015 16:52, cpaul@redhat.com wrote: > > > > This is somewhat rare on most cards (depending on what angle > > > > you plug > > > > the DVI connector in), but on some cards it happens constantly. > > > > The > > > > Radeon R5 on the machine used for testing this patch for > > > > instance, runs > > > > into this issue just about every time I try to hotplug a DVI > > > > monitor and > > > > as a result hotplugging almost never works. > > > > > > > > Rescheduling the hotplug work for a second when we run into an > > > > HPD > > > > signal with a failing DDC probe usually gives enough time for > > > > the rest > > > > of the connector's pins to make contact, and fixes this issue. > > > > > > > > Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com> > > > > > > Yeah, that's something I always wondered a about bit as well. > > > > > > Debouncing is something very common done in electronics, but as > > > far as I > > > know the HPD pins don't necessary have an RC circuit so we might > > > need to > > > handle this case in software here. > > > > > > A delay of something between 10-30ms between the last HPD > > > interrupt and > > > further processing of the signal doesn't sounds like such a bad > > > idea. Unfortunately the delay needed to make hotplugging work on the system mentioned in the commit log can actually be over 700ms. > > > > > > Retrying on the other hand doesn't necessarily improve the > > > situation cause > > > the delay introduced by this might not be enough. Yeah, but I would think it would make sense to retry here so long as we back off after a certain time. This would also have the benefit of skipping this delay on systems that don't need it. > > > > > > So I would rather vote for a fixed delay between an HPD interrupt > > > and > > > actually starting to process anything. > > Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. > > those > > on marginal power) which send you HPD storms as well. But DP relies > > on > > 'short HPD' pulses which can be as brief as 2ms. So attempting to > > totally debounce all HPD won't work. > Well the discussion so far was about HPD on DVI only. > > I'm not so deep into DP, but why should it uses HPD pulses of less > than 2ms? This is part of the DP spec iirc. This being said though, the issue here with the HPD signal coming before the connector is ready only happens on DVI. I haven't ever run into this issue with any HDMI cables or DP cables, so I'm against imposing this on all connectors. One of the solutions I've been thinking about with this: In radeon_dvi_detect(), if we get a real hotplug signal retry the DDC probe until at least a second has passed, after which we back off and assume the port is disconnected. > > Regards, > Christian. > > > > > Cheers, > > Daniel > -- Cheers, Lyude -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Deucher, Alexander" <Alexander.Deucher@amd.com> |
|---|---|
| Date | 2015-11-23 15:40 +0100 |
| Subject | RE: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qy0rE-30z-13@gated-at.bofh.it> |
| In reply to | #1275018 |
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMeXVkZSBbbWFpbHRvOmNwYXVs QHJlZGhhdC5jb21dDQo+IFNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMjIsIDIwMTUgOTo0NSBQTQ0K PiBUbzogS29lbmlnLCBDaHJpc3RpYW47IERhbmllbCBTdG9uZQ0KPiBDYzogRGV1Y2hlciwgQWxl eGFuZGVyOyBEYXZpZCBBaXJsaWU7IGRyaS1kZXZlbDsgTGludXggS2VybmVsIE1haWxpbmcgTGlz dDsNCj4gSmVyb21lIEdsaXNzZTsgQmVuamFtaW4gVGlzc29pcmVzDQo+IFN1YmplY3Q6IFJlOiBb UEFUQ0hdIGRybS9yYWRlb246IFJldHJ5IEREQyBwcm9iaW5nIG9uIERWSSBvbiBmYWlsdXJlIGlm IHdlDQo+IGdvdCBhbiBIUEQgaW50ZXJydXB0DQo+IA0KPiBPbiBTYXQsIDIwMTUtMTEtMjEgYXQg MTY6MjIgKzAxMDAsIENocmlzdGlhbiBLw7ZuaWcgd3JvdGU6DQo+ID4gT24gMjEuMTEuMjAxNSAx NTo0OSwgRGFuaWVsIFN0b25lIHdyb3RlOg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ID4gT24gMjEg Tm92ZW1iZXIgMjAxNSBhdCAxNDoyMiwgQ2hyaXN0aWFuIEvDtm5pZyA8Y2hyaXN0aWFuLmtvZW5p Z0BhbWQNCj4gPiA+IC5jb20+IHdyb3RlOg0KPiA+ID4gPiBPbiAyMC4xMS4yMDE1IDE2OjUyLCBj cGF1bEByZWRoYXQuY29tIHdyb3RlOg0KPiA+ID4gPiA+IFRoaXMgaXMgc29tZXdoYXQgcmFyZSBv biBtb3N0IGNhcmRzIChkZXBlbmRpbmcgb24gd2hhdCBhbmdsZQ0KPiA+ID4gPiA+IHlvdSBwbHVn DQo+ID4gPiA+ID4gdGhlIERWSSBjb25uZWN0b3IgaW4pLCBidXQgb24gc29tZSBjYXJkcyBpdCBo YXBwZW5zIGNvbnN0YW50bHkuDQo+ID4gPiA+ID4gVGhlDQo+ID4gPiA+ID4gUmFkZW9uIFI1IG9u IHRoZSBtYWNoaW5lIHVzZWQgZm9yIHRlc3RpbmcgdGhpcyBwYXRjaCBmb3INCj4gPiA+ID4gPiBp bnN0YW5jZSwgcnVucw0KPiA+ID4gPiA+IGludG8gdGhpcyBpc3N1ZSBqdXN0IGFib3V0IGV2ZXJ5 IHRpbWUgSSB0cnkgdG8gaG90cGx1ZyBhIERWSQ0KPiA+ID4gPiA+IG1vbml0b3IgYW5kDQo+ID4g PiA+ID4gYXMgYSByZXN1bHQgaG90cGx1Z2dpbmcgYWxtb3N0IG5ldmVyIHdvcmtzLg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gUmVzY2hlZHVsaW5nIHRoZSBob3RwbHVnIHdvcmsgZm9yIGEgc2Vjb25k IHdoZW4gd2UgcnVuIGludG8gYW4NCj4gPiA+ID4gPiBIUEQNCj4gPiA+ID4gPiBzaWduYWwgd2l0 aCBhIGZhaWxpbmcgRERDIHByb2JlIHVzdWFsbHkgZ2l2ZXMgZW5vdWdoIHRpbWUgZm9yDQo+ID4g PiA+ID4gdGhlIHJlc3QNCj4gPiA+ID4gPiBvZiB0aGUgY29ubmVjdG9yJ3MgcGlucyB0byBtYWtl IGNvbnRhY3QsIGFuZCBmaXhlcyB0aGlzIGlzc3VlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU2ln bmVkLW9mZi1ieTogU3RlcGhlbiBDaGFuZGxlciBQYXVsIDxjcGF1bEByZWRoYXQuY29tPg0KPiA+ ID4gPg0KPiA+ID4gPiBZZWFoLCB0aGF0J3Mgc29tZXRoaW5nIEkgYWx3YXlzIHdvbmRlcmVkIGEg YWJvdXQgYml0IGFzIHdlbGwuDQo+ID4gPiA+DQo+ID4gPiA+IERlYm91bmNpbmcgaXMgc29tZXRo aW5nIHZlcnkgY29tbW9uIGRvbmUgaW4gZWxlY3Ryb25pY3MsIGJ1dCBhcw0KPiA+ID4gPiBmYXIg YXMgSQ0KPiA+ID4gPiBrbm93IHRoZSBIUEQgcGlucyBkb24ndCBuZWNlc3NhcnkgaGF2ZSBhbiBS QyBjaXJjdWl0IHNvIHdlIG1pZ2h0DQo+ID4gPiA+IG5lZWQgdG8NCj4gPiA+ID4gaGFuZGxlIHRo aXMgY2FzZSBpbiBzb2Z0d2FyZSBoZXJlLg0KPiA+ID4gPg0KPiA+ID4gPiBBIGRlbGF5IG9mIHNv bWV0aGluZyBiZXR3ZWVuIDEwLTMwbXMgYmV0d2VlbiB0aGUgbGFzdCBIUEQNCj4gPiA+ID4gaW50 ZXJydXB0IGFuZA0KPiA+ID4gPiBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHNpZ25hbCBkb2Vz bid0IHNvdW5kcyBsaWtlIHN1Y2ggYSBiYWQNCj4gPiA+ID4gaWRlYS4NCj4gVW5mb3J0dW5hdGVs eSB0aGUgZGVsYXkgbmVlZGVkIHRvIG1ha2UgaG90cGx1Z2dpbmcgd29yayBvbiB0aGUgc3lzdGVt DQo+IG1lbnRpb25lZCBpbiB0aGUgY29tbWl0IGxvZyBjYW4gYWN0dWFsbHkgYmUgb3ZlciA3MDBt cy4NCj4gPiA+ID4NCj4gPiA+ID4gUmV0cnlpbmcgb24gdGhlIG90aGVyIGhhbmQgZG9lc24ndCBu ZWNlc3NhcmlseSBpbXByb3ZlIHRoZQ0KPiA+ID4gPiBzaXR1YXRpb24gY2F1c2UNCj4gPiA+ID4g dGhlIGRlbGF5IGludHJvZHVjZWQgYnkgdGhpcyBtaWdodCBub3QgYmUgZW5vdWdoLg0KPiBZZWFo LCBidXQgSSB3b3VsZCB0aGluayBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIHJldHJ5IGhlcmUgc28g bG9uZyBhcyB3ZQ0KPiBiYWNrIG9mZiBhZnRlciBhIGNlcnRhaW4gdGltZS4gVGhpcyB3b3VsZCBh bHNvIGhhdmUgdGhlIGJlbmVmaXQgb2YNCj4gc2tpcHBpbmcgdGhpcyBkZWxheSBvbiBzeXN0ZW1z IHRoYXQgZG9uJ3QgbmVlZCBpdC4NCj4gPiA+ID4NCj4gPiA+ID4gU28gSSB3b3VsZCByYXRoZXIg dm90ZSBmb3IgYSBmaXhlZCBkZWxheSBiZXR3ZWVuIGFuIEhQRCBpbnRlcnJ1cHQNCj4gPiA+ID4g YW5kDQo+ID4gPiA+IGFjdHVhbGx5IHN0YXJ0aW5nIHRvIHByb2Nlc3MgYW55dGhpbmcuDQo+ID4g PiBZZXMtaXNoLiBEZWJvdW5jaW5nIGlzIHVzZWZ1bCwgYW5kIGlnbm9yaW5nIGJ1Z2d5IGRldmlj ZXMgKGUuZy4NCj4gPiA+IHRob3NlDQo+ID4gPiBvbiBtYXJnaW5hbCBwb3dlcikgd2hpY2ggc2Vu ZCB5b3UgSFBEIHN0b3JtcyBhcyB3ZWxsLiBCdXQgRFAgcmVsaWVzDQo+ID4gPiBvbg0KPiA+ID4g J3Nob3J0IEhQRCcgcHVsc2VzIHdoaWNoIGNhbiBiZSBhcyBicmllZiBhcyAybXMuIFNvIGF0dGVt cHRpbmcgdG8NCj4gPiA+IHRvdGFsbHkgZGVib3VuY2UgYWxsIEhQRCB3b24ndCB3b3JrLg0KPiA+ IFdlbGwgdGhlIGRpc2N1c3Npb24gc28gZmFyIHdhcyBhYm91dCBIUEQgb24gRFZJIG9ubHkuDQo+ ID4NCj4gPiBJJ20gbm90IHNvIGRlZXAgaW50byBEUCwgYnV0IHdoeSBzaG91bGQgaXQgdXNlcyBI UEQgcHVsc2VzIG9mIGxlc3MNCj4gPiB0aGFuIDJtcz8NCj4gVGhpcyBpcyBwYXJ0IG9mIHRoZSBE UCBzcGVjIGlpcmMuIFRoaXMgYmVpbmcgc2FpZCB0aG91Z2gsIHRoZSBpc3N1ZQ0KPiBoZXJlIHdp dGggdGhlIEhQRCBzaWduYWwgY29taW5nIGJlZm9yZSB0aGUgY29ubmVjdG9yIGlzIHJlYWR5IG9u bHkNCj4gaGFwcGVucyBvbiBEVkkuIEkgaGF2ZW4ndCBldmVyIHJ1biBpbnRvIHRoaXMgaXNzdWUg d2l0aCBhbnkgSERNSSBjYWJsZXMNCj4gb3IgRFAgY2FibGVzLCBzbyBJJ20gYWdhaW5zdCBpbXBv c2luZyB0aGlzIG9uIGFsbCBjb25uZWN0b3JzLg0KPiANCj4gT25lIG9mIHRoZSBzb2x1dGlvbnMg SSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHdpdGggdGhpczogSW4NCj4gcmFkZW9uX2R2aV9kZXRl Y3QoKSwgaWYgd2UgZ2V0IGEgcmVhbCBob3RwbHVnIHNpZ25hbCByZXRyeSB0aGUgRERDDQo+IHBy b2JlIHVudGlsIGF0IGxlYXN0IGEgc2Vjb25kIGhhcyBwYXNzZWQsIGFmdGVyIHdoaWNoIHdlIGJh Y2sgb2ZmIGFuZA0KPiBhc3N1bWUgdGhlIHBvcnQgaXMgZGlzY29ubmVjdGVkLg0KDQpGV0lXLCB0 aGVyZSBhcmUgcmVnaXN0ZXJzIHRvIGFkanVzdCBob3cgbG9uZyB0aGUgaHBkIG5lZWRzIHRvIGJl IGFzc2VydGVkIGJlZm9yZSB0aGUgaHBkIGNvbm5lY3Rpb24gYW5kIHNob3J0IHB1bHNlIGludGVy cnVwdHMgYXJlIHRyaWdnZXJlZC4gIFNlZSBEQ19IUER4X0NPTlRST0wuICBNYXliZSBhZGp1c3Rp bmcgdGhlbSB3b3VsZCBoZWxwLiAgV2UgY3VycmVudGx5IGp1c3Qgd3JpdGUgdGhlIGRlZmF1bHQg dmFsdWUsIGJ1dCBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gUk1XIHRoZSB2YWx1ZSBpbiBjYXNlIHRo ZXJlIGlzIGEgc3BlY2lhbCBnb2xkZW4gdmFsdWUgc2V0IGJ5IHRoZSB2YmlvcyBhdCBpbml0IHRp bWUuDQoNCkFsZXgNCg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBDaHJpc3RpYW4uDQo+ID4NCj4g PiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPiBEYW5pZWwNCj4gPg0KPiAtLQ0KPiBDaGVlcnMsDQo+ IAlMeXVkZQ0KDQo= -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lyude <cpaul@redhat.com> |
|---|---|
| Date | 2015-11-23 16:50 +0100 |
| Subject | Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qy1xo-3M1-23@gated-at.bofh.it> |
| In reply to | #1275441 |
On Mon, 2015-11-23 at 14:20 +0000, Deucher, Alexander wrote: > > -----Original Message----- > > From: Lyude [mailto:cpaul@redhat.com] > > Sent: Sunday, November 22, 2015 9:45 PM > > To: Koenig, Christian; Daniel Stone > > Cc: Deucher, Alexander; David Airlie; dri-devel; Linux Kernel Mailing List; > > Jerome Glisse; Benjamin Tissoires > > Subject: Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we > > got an HPD interrupt > > > > On Sat, 2015-11-21 at 16:22 +0100, Christian König wrote: > > > On 21.11.2015 15:49, Daniel Stone wrote: > > > > Hi, > > > > > > > > On 21 November 2015 at 14:22, Christian König <christian.koenig@amd > > > > .com> wrote: > > > > > On 20.11.2015 16:52, cpaul@redhat.com wrote: > > > > > > This is somewhat rare on most cards (depending on what angle > > > > > > you plug > > > > > > the DVI connector in), but on some cards it happens constantly. > > > > > > The > > > > > > Radeon R5 on the machine used for testing this patch for > > > > > > instance, runs > > > > > > into this issue just about every time I try to hotplug a DVI > > > > > > monitor and > > > > > > as a result hotplugging almost never works. > > > > > > > > > > > > Rescheduling the hotplug work for a second when we run into an > > > > > > HPD > > > > > > signal with a failing DDC probe usually gives enough time for > > > > > > the rest > > > > > > of the connector's pins to make contact, and fixes this issue. > > > > > > > > > > > > Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com> > > > > > > > > > > Yeah, that's something I always wondered a about bit as well. > > > > > > > > > > Debouncing is something very common done in electronics, but as > > > > > far as I > > > > > know the HPD pins don't necessary have an RC circuit so we might > > > > > need to > > > > > handle this case in software here. > > > > > > > > > > A delay of something between 10-30ms between the last HPD > > > > > interrupt and > > > > > further processing of the signal doesn't sounds like such a bad > > > > > idea. > > Unfortunately the delay needed to make hotplugging work on the system > > mentioned in the commit log can actually be over 700ms. > > > > > > > > > > Retrying on the other hand doesn't necessarily improve the > > > > > situation cause > > > > > the delay introduced by this might not be enough. > > Yeah, but I would think it would make sense to retry here so long as we > > back off after a certain time. This would also have the benefit of > > skipping this delay on systems that don't need it. > > > > > > > > > > So I would rather vote for a fixed delay between an HPD interrupt > > > > > and > > > > > actually starting to process anything. > > > > Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. > > > > those > > > > on marginal power) which send you HPD storms as well. But DP relies > > > > on > > > > 'short HPD' pulses which can be as brief as 2ms. So attempting to > > > > totally debounce all HPD won't work. > > > Well the discussion so far was about HPD on DVI only. > > > > > > I'm not so deep into DP, but why should it uses HPD pulses of less > > > than 2ms? > > This is part of the DP spec iirc. This being said though, the issue > > here with the HPD signal coming before the connector is ready only > > happens on DVI. I haven't ever run into this issue with any HDMI cables > > or DP cables, so I'm against imposing this on all connectors. > > > > One of the solutions I've been thinking about with this: In > > radeon_dvi_detect(), if we get a real hotplug signal retry the DDC > > probe until at least a second has passed, after which we back off and > > assume the port is disconnected. > > FWIW, there are registers to adjust how long the hpd needs to be asserted > before the hpd connection and short pulse interrupts are triggered. See > DC_HPDx_CONTROL. Maybe adjusting them would help. We currently just write > the default value, but it might be better to RMW the value in case there is a > special golden value set by the vbios at init time. > This sounds like a much better idea. I'm going to try to come up with a patch that adjusts these by default for DVI ports. > Alex > > > > > > > Regards, > > > Christian. > > > > > > > > > > > Cheers, > > > > Daniel > > > > > -- > > Cheers, > > Lyude > -- Cheers, Lyude -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lyude <cpaul@redhat.com> |
|---|---|
| Date | 2015-11-23 18:50 +0100 |
| Subject | Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qy3px-51A-25@gated-at.bofh.it> |
| In reply to | #1275500 |
On Mon, 2015-11-23 at 10:43 -0500, Lyude wrote: > On Mon, 2015-11-23 at 14:20 +0000, Deucher, Alexander wrote: > > > -----Original Message----- > > > From: Lyude [mailto:cpaul@redhat.com] > > > Sent: Sunday, November 22, 2015 9:45 PM > > > To: Koenig, Christian; Daniel Stone > > > Cc: Deucher, Alexander; David Airlie; dri-devel; Linux Kernel Mailing > > > List; > > > Jerome Glisse; Benjamin Tissoires > > > Subject: Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we > > > got an HPD interrupt > > > > > > On Sat, 2015-11-21 at 16:22 +0100, Christian König wrote: > > > > On 21.11.2015 15:49, Daniel Stone wrote: > > > > > Hi, > > > > > > > > > > On 21 November 2015 at 14:22, Christian König <christian.koenig@amd > > > > > .com> wrote: > > > > > > On 20.11.2015 16:52, cpaul@redhat.com wrote: > > > > > > > This is somewhat rare on most cards (depending on what angle > > > > > > > you plug > > > > > > > the DVI connector in), but on some cards it happens constantly. > > > > > > > The > > > > > > > Radeon R5 on the machine used for testing this patch for > > > > > > > instance, runs > > > > > > > into this issue just about every time I try to hotplug a DVI > > > > > > > monitor and > > > > > > > as a result hotplugging almost never works. > > > > > > > > > > > > > > Rescheduling the hotplug work for a second when we run into an > > > > > > > HPD > > > > > > > signal with a failing DDC probe usually gives enough time for > > > > > > > the rest > > > > > > > of the connector's pins to make contact, and fixes this issue. > > > > > > > > > > > > > > Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com> > > > > > > > > > > > > Yeah, that's something I always wondered a about bit as well. > > > > > > > > > > > > Debouncing is something very common done in electronics, but as > > > > > > far as I > > > > > > know the HPD pins don't necessary have an RC circuit so we might > > > > > > need to > > > > > > handle this case in software here. > > > > > > > > > > > > A delay of something between 10-30ms between the last HPD > > > > > > interrupt and > > > > > > further processing of the signal doesn't sounds like such a bad > > > > > > idea. > > > Unfortunately the delay needed to make hotplugging work on the system > > > mentioned in the commit log can actually be over 700ms. > > > > > > > > > > > > Retrying on the other hand doesn't necessarily improve the > > > > > > situation cause > > > > > > the delay introduced by this might not be enough. > > > Yeah, but I would think it would make sense to retry here so long as we > > > back off after a certain time. This would also have the benefit of > > > skipping this delay on systems that don't need it. > > > > > > > > > > > > So I would rather vote for a fixed delay between an HPD interrupt > > > > > > and > > > > > > actually starting to process anything. > > > > > Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. > > > > > those > > > > > on marginal power) which send you HPD storms as well. But DP relies > > > > > on > > > > > 'short HPD' pulses which can be as brief as 2ms. So attempting to > > > > > totally debounce all HPD won't work. > > > > Well the discussion so far was about HPD on DVI only. > > > > > > > > I'm not so deep into DP, but why should it uses HPD pulses of less > > > > than 2ms? > > > This is part of the DP spec iirc. This being said though, the issue > > > here with the HPD signal coming before the connector is ready only > > > happens on DVI. I haven't ever run into this issue with any HDMI cables > > > or DP cables, so I'm against imposing this on all connectors. > > > > > > One of the solutions I've been thinking about with this: In > > > radeon_dvi_detect(), if we get a real hotplug signal retry the DDC > > > probe until at least a second has passed, after which we back off and > > > assume the port is disconnected. > > > > FWIW, there are registers to adjust how long the hpd needs to be asserted > > before the hpd connection and short pulse interrupts are triggered. See > > DC_HPDx_CONTROL. Maybe adjusting them would help. We currently just write > > the default value, but it might be better to RMW the value in case there is > > a > > special golden value set by the vbios at init time. > > > This sounds like a much better idea. I'm going to try to come up with a patch > that adjusts these by default for DVI ports. Ignore this; we can't get a long enough delay using those registers to fix the issue so we'll still have to handle this in software. > > Alex > > > > > > > > > > Regards, > > > > Christian. > > > > > > > > > > > > > > Cheers, > > > > > Daniel > > > > > > > -- > > > Cheers, > > > Lyude > > -- Cheers, Lyude -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Daniel Vetter <daniel@ffwll.ch> |
|---|---|
| Date | 2015-11-23 10:00 +0100 |
| Subject | Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qxV8B-7TP-1@gated-at.bofh.it> |
| In reply to | #1274672 |
On Sat, Nov 21, 2015 at 02:49:20PM +0000, Daniel Stone wrote: > Hi, > > On 21 November 2015 at 14:22, Christian König <christian.koenig@amd.com> wrote: > > On 20.11.2015 16:52, cpaul@redhat.com wrote: > >> This is somewhat rare on most cards (depending on what angle you plug > >> the DVI connector in), but on some cards it happens constantly. The > >> Radeon R5 on the machine used for testing this patch for instance, runs > >> into this issue just about every time I try to hotplug a DVI monitor and > >> as a result hotplugging almost never works. > >> > >> Rescheduling the hotplug work for a second when we run into an HPD > >> signal with a failing DDC probe usually gives enough time for the rest > >> of the connector's pins to make contact, and fixes this issue. > >> > >> Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com> > > > > > > Yeah, that's something I always wondered a about bit as well. > > > > Debouncing is something very common done in electronics, but as far as I > > know the HPD pins don't necessary have an RC circuit so we might need to > > handle this case in software here. > > > > A delay of something between 10-30ms between the last HPD interrupt and > > further processing of the signal doesn't sounds like such a bad idea. > > > > Retrying on the other hand doesn't necessarily improve the situation cause > > the delay introduced by this might not be enough. > > > > So I would rather vote for a fixed delay between an HPD interrupt and > > actually starting to process anything. > > Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. those > on marginal power) which send you HPD storms as well. But DP relies on > 'short HPD' pulses which can be as brief as 2ms. So attempting to > totally debounce all HPD won't work. In our experience in i915 DP hpd works perfectly on all machines. At least we never had to add timeout hacks to settle hpd, storm handling code isn't enabled for DP either and we always checked hpd status bits to decide whether something is connected or not. hdmi/dvi is the troublemaker which needs settling time and storm handling. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Christian König <christian.koenig@amd.com> |
|---|---|
| Date | 2015-11-21 16:00 +0100 |
| Subject | Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qxhEd-6AU-15@gated-at.bofh.it> |
| In reply to | #1274206 |
On 20.11.2015 16:52, cpaul@redhat.com wrote:
> From: Stephen Chandler Paul <cpaul@redhat.com>
>
> HPD signals on DVI ports can be fired off before the pins required for
> DDC probing actually make contact, due to the pins for HPD making
> contact first. This results in a HPD signal being asserted but DDC
> probing failing, resulting in hotplugging occasionally failing.
>
> This is somewhat rare on most cards (depending on what angle you plug
> the DVI connector in), but on some cards it happens constantly. The
> Radeon R5 on the machine used for testing this patch for instance, runs
> into this issue just about every time I try to hotplug a DVI monitor and
> as a result hotplugging almost never works.
>
> Rescheduling the hotplug work for a second when we run into an HPD
> signal with a failing DDC probe usually gives enough time for the rest
> of the connector's pins to make contact, and fixes this issue.
>
> Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com>
Yeah, that's something I always wondered a about bit as well.
Debouncing is something very common done in electronics, but as far as I
know the HPD pins don't necessary have an RC circuit so we might need to
handle this case in software here.
A delay of something between 10-30ms between the last HPD interrupt and
further processing of the signal doesn't sounds like such a bad idea.
Retrying on the other hand doesn't necessarily improve the situation
cause the delay introduced by this might not be enough.
So I would rather vote for a fixed delay between an HPD interrupt and
actually starting to process anything.
Regards,
Christian.
> ---
> So this one has kind of been a tough sell with Jerome, mostly because it's
> somewhat of a hack. Unfortunately however I've managed to find machines where
> DVI hotplugging literally doesn't work without a patch like this. We've already
> tried a couple of ways of handling the situation of retriggering ddc probes:
>
> * Trying the DDC probe in the radeon_dvi_detect() function multiple times.
> * Trying to reschedule the hotplug_work task whenever DDC probing fails on DVI
> but we got a hpd signal (this ended up being a much more complicated patch
> then anticipated)
> * Doing what we do right now, which is just triggering userspace to rescan all
> the ports when the hpd signal is asserted by the DVI port but there's no DDC
> probe, and repeating until at least a second passes.
>
> All of these actually work, but I guess it's a question of which one is less of
> a hack. If anyone here can think of a cleaner way of handling this feel free to
> let me know.
>
> drivers/gpu/drm/radeon/radeon.h | 3 +++
> drivers/gpu/drm/radeon/radeon_connectors.c | 20 +++++++++++++++++---
> drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 ++
> 3 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index b6cbd81..d63f0fe 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2460,6 +2460,9 @@ struct radeon_device {
> /* amdkfd interface */
> struct kfd_dev *kfd;
>
> + /* last time we received an hpd signal */
> + unsigned long hpd_time;
> +
> struct mutex mn_lock;
> DECLARE_HASHTABLE(mn_hash, 7);
> };
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 5a2cafb..4ee9440 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -1228,19 +1228,33 @@ radeon_dvi_detect(struct drm_connector *connector, bool force)
> const struct drm_encoder_helper_funcs *encoder_funcs;
> int i, r;
> enum drm_connector_status ret = connector_status_disconnected;
> - bool dret = false, broken_edid = false;
> + bool dret = false, broken_edid = false, hpd_unchanged;
>
> r = pm_runtime_get_sync(connector->dev->dev);
> if (r < 0)
> return connector_status_disconnected;
>
> - if (!force && radeon_check_hpd_status_unchanged(connector)) {
> + hpd_unchanged = radeon_check_hpd_status_unchanged(connector);
> + if (!force && hpd_unchanged) {
> ret = connector->status;
> goto exit;
> }
>
> - if (radeon_connector->ddc_bus)
> + if (radeon_connector->ddc_bus) {
> dret = radeon_ddc_probe(radeon_connector, false);
> +
> + /* Sometimes the pins required for the DDC probe on DVI
> + * connectors don't make contact at the same time that the ones
> + * for HPD do. If the DDC probe fails even though we had an HPD
> + * signal, signal userspace to try again */
> + if (!dret && !hpd_unchanged &&
> + connector->status != connector_status_connected &&
> + time_before(jiffies, rdev->hpd_time + msecs_to_jiffies(1000))) {
> + DRM_DEBUG_KMS("%s: hpd asserted but ddc probe failed, retrying\n",
> + connector->name);
> + drm_sysfs_hotplug_event(dev);
> + }
> + }
> if (dret) {
> radeon_connector->detected_by_load = false;
> radeon_connector_free_edid(connector);
> diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> index 171d3e4..579c22c 100644
> --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> @@ -79,6 +79,8 @@ static void radeon_hotplug_work_func(struct work_struct *work)
> struct drm_mode_config *mode_config = &dev->mode_config;
> struct drm_connector *connector;
>
> + rdev->hpd_time = jiffies;
> +
> /* we can race here at startup, some boards seem to trigger
> * hotplug irqs when they shouldn't. */
> if (!rdev->mode_info.mode_config_initialized)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Daniel Vetter <daniel@ffwll.ch> |
|---|---|
| Date | 2015-11-23 10:00 +0100 |
| Subject | Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt |
| Message-ID | <qxV8C-7TP-17@gated-at.bofh.it> |
| In reply to | #1274674 |
On Sat, Nov 21, 2015 at 03:22:07PM +0100, Christian König wrote:
> On 20.11.2015 16:52, cpaul@redhat.com wrote:
> >From: Stephen Chandler Paul <cpaul@redhat.com>
> >
> >HPD signals on DVI ports can be fired off before the pins required for
> >DDC probing actually make contact, due to the pins for HPD making
> >contact first. This results in a HPD signal being asserted but DDC
> >probing failing, resulting in hotplugging occasionally failing.
> >
> >This is somewhat rare on most cards (depending on what angle you plug
> >the DVI connector in), but on some cards it happens constantly. The
> >Radeon R5 on the machine used for testing this patch for instance, runs
> >into this issue just about every time I try to hotplug a DVI monitor and
> >as a result hotplugging almost never works.
> >
> >Rescheduling the hotplug work for a second when we run into an HPD
> >signal with a failing DDC probe usually gives enough time for the rest
> >of the connector's pins to make contact, and fixes this issue.
> >
> >Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com>
>
> Yeah, that's something I always wondered a about bit as well.
>
> Debouncing is something very common done in electronics, but as far as I
> know the HPD pins don't necessary have an RC circuit so we might need to
> handle this case in software here.
>
> A delay of something between 10-30ms between the last HPD interrupt and
> further processing of the signal doesn't sounds like such a bad idea.
>
> Retrying on the other hand doesn't necessarily improve the situation cause
> the delay introduced by this might not be enough.
>
> So I would rather vote for a fixed delay between an HPD interrupt and
> actually starting to process anything.
Might be interesting to compare what we do in i915 in latest kernels:
- in the hpd handler we check the hpd status bits before probing the edid.
This will take care of slow unplug case where we get the hpd
interrupt/status change, but i2c is still working.
- but because crap screens (or whatever it is) if hpd is _not_ set we
retest the status for 30ms (and bail out as soon as hpd status is
asserted). This seems to be enough time to settle all screens.
Note that this is in intel_hdmi.c since native dvi ports on intel hw also
always supported hdmi features. Not sure whether we could extract this
into some kind of helper and share.
-Daniel
>
> Regards,
> Christian.
>
> >---
> >So this one has kind of been a tough sell with Jerome, mostly because it's
> >somewhat of a hack. Unfortunately however I've managed to find machines where
> >DVI hotplugging literally doesn't work without a patch like this. We've already
> >tried a couple of ways of handling the situation of retriggering ddc probes:
> >
> >* Trying the DDC probe in the radeon_dvi_detect() function multiple times.
> >* Trying to reschedule the hotplug_work task whenever DDC probing fails on DVI
> > but we got a hpd signal (this ended up being a much more complicated patch
> > then anticipated)
> >* Doing what we do right now, which is just triggering userspace to rescan all
> > the ports when the hpd signal is asserted by the DVI port but there's no DDC
> > probe, and repeating until at least a second passes.
> >
> >All of these actually work, but I guess it's a question of which one is less of
> >a hack. If anyone here can think of a cleaner way of handling this feel free to
> >let me know.
> >
> > drivers/gpu/drm/radeon/radeon.h | 3 +++
> > drivers/gpu/drm/radeon/radeon_connectors.c | 20 +++++++++++++++++---
> > drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 ++
> > 3 files changed, 22 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> >index b6cbd81..d63f0fe 100644
> >--- a/drivers/gpu/drm/radeon/radeon.h
> >+++ b/drivers/gpu/drm/radeon/radeon.h
> >@@ -2460,6 +2460,9 @@ struct radeon_device {
> > /* amdkfd interface */
> > struct kfd_dev *kfd;
> >+ /* last time we received an hpd signal */
> >+ unsigned long hpd_time;
> >+
> > struct mutex mn_lock;
> > DECLARE_HASHTABLE(mn_hash, 7);
> > };
> >diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
> >index 5a2cafb..4ee9440 100644
> >--- a/drivers/gpu/drm/radeon/radeon_connectors.c
> >+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> >@@ -1228,19 +1228,33 @@ radeon_dvi_detect(struct drm_connector *connector, bool force)
> > const struct drm_encoder_helper_funcs *encoder_funcs;
> > int i, r;
> > enum drm_connector_status ret = connector_status_disconnected;
> >- bool dret = false, broken_edid = false;
> >+ bool dret = false, broken_edid = false, hpd_unchanged;
> > r = pm_runtime_get_sync(connector->dev->dev);
> > if (r < 0)
> > return connector_status_disconnected;
> >- if (!force && radeon_check_hpd_status_unchanged(connector)) {
> >+ hpd_unchanged = radeon_check_hpd_status_unchanged(connector);
> >+ if (!force && hpd_unchanged) {
> > ret = connector->status;
> > goto exit;
> > }
> >- if (radeon_connector->ddc_bus)
> >+ if (radeon_connector->ddc_bus) {
> > dret = radeon_ddc_probe(radeon_connector, false);
> >+
> >+ /* Sometimes the pins required for the DDC probe on DVI
> >+ * connectors don't make contact at the same time that the ones
> >+ * for HPD do. If the DDC probe fails even though we had an HPD
> >+ * signal, signal userspace to try again */
> >+ if (!dret && !hpd_unchanged &&
> >+ connector->status != connector_status_connected &&
> >+ time_before(jiffies, rdev->hpd_time + msecs_to_jiffies(1000))) {
> >+ DRM_DEBUG_KMS("%s: hpd asserted but ddc probe failed, retrying\n",
> >+ connector->name);
> >+ drm_sysfs_hotplug_event(dev);
> >+ }
> >+ }
> > if (dret) {
> > radeon_connector->detected_by_load = false;
> > radeon_connector_free_edid(connector);
> >diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> >index 171d3e4..579c22c 100644
> >--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> >+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> >@@ -79,6 +79,8 @@ static void radeon_hotplug_work_func(struct work_struct *work)
> > struct drm_mode_config *mode_config = &dev->mode_config;
> > struct drm_connector *connector;
> >+ rdev->hpd_time = jiffies;
> >+
> > /* we can race here at startup, some boards seem to trigger
> > * hotplug irqs when they shouldn't. */
> > if (!rdev->mode_info.mode_config_initialized)
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web