From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel.vetter@intel.com>,
intel-gfx@lists.freedesktop.org, Todd Broch <tbroch@chromium.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] drm/i915: hide errors when probing for a reverse display port
Date: Wed, 29 Jul 2015 11:20:23 -0400 [thread overview]
Message-ID: <20150729152022.GC2743@mail.corp.redhat.com> (raw)
In-Reply-To: <20150728161831.GF16528@nuc-i3427.alporthouse.com>
On Jul 28 2015 or thereabouts, Chris Wilson wrote:
> On Tue, Jul 28, 2015 at 12:03:28PM -0400, Benjamin Tissoires wrote:
> > We check the polarity of the attached dp, so it is normal to fail.
> > Do not send errors to the users.
>
> if (probe) DRM_DEBUG else DRM_ERROR is fairly offensive.
>
> It strikes me that you could make each of these functions report the
> failure to the caller (have the caller even do so error handling!) and
> as part of that have the caller report an error and so demote all of
> these to DRM_DEBUG_KMS().
Yes, sorry for that. I will change it to return an actual error code and
the error string if I still need to use these functions given Sivakumar
ideas.
>
> Who knows, actually doing some error handling may make monitor training
> more reliable! Or we may even get carried away and report the failure
> all the way back to userspace.
That would be a very good improvement indeed. But I can already tell you
that I will not do it by myself, I already have too much on my plate.
I'll do my share for this feature, but don't count on me for the whole
error handling rewrite :)
Cheers,
Benjamin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel.vetter@intel.com>,
intel-gfx@lists.freedesktop.org, Todd Broch <tbroch@chromium.org>,
linux-kernel@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: hide errors when probing for a reverse display port
Date: Wed, 29 Jul 2015 11:20:23 -0400 [thread overview]
Message-ID: <20150729152022.GC2743@mail.corp.redhat.com> (raw)
In-Reply-To: <20150728161831.GF16528@nuc-i3427.alporthouse.com>
On Jul 28 2015 or thereabouts, Chris Wilson wrote:
> On Tue, Jul 28, 2015 at 12:03:28PM -0400, Benjamin Tissoires wrote:
> > We check the polarity of the attached dp, so it is normal to fail.
> > Do not send errors to the users.
>
> if (probe) DRM_DEBUG else DRM_ERROR is fairly offensive.
>
> It strikes me that you could make each of these functions report the
> failure to the caller (have the caller even do so error handling!) and
> as part of that have the caller report an error and so demote all of
> these to DRM_DEBUG_KMS().
Yes, sorry for that. I will change it to return an actual error code and
the error string if I still need to use these functions given Sivakumar
ideas.
>
> Who knows, actually doing some error handling may make monitor training
> more reliable! Or we may even get carried away and report the failure
> all the way back to userspace.
That would be a very good improvement indeed. But I can already tell you
that I will not do it by myself, I already have too much on my plate.
I'll do my share for this feature, but don't count on me for the whole
error handling rewrite :)
Cheers,
Benjamin
next prev parent reply other threads:[~2015-07-29 15:20 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 16:03 [PATCH 0/3] drm/i915: fix USB Type-C reversed connector Benjamin Tissoires
2015-07-28 16:03 ` Benjamin Tissoires
2015-07-28 16:03 ` [PATCH 1/3] drm/i915: add parameters to dp_start_link_train and dp_complete_link_train Benjamin Tissoires
2015-07-28 16:03 ` Benjamin Tissoires
2015-07-28 16:03 ` [PATCH 2/3] drm/i915: hide errors when probing for a reverse display port Benjamin Tissoires
2015-07-28 16:03 ` Benjamin Tissoires
2015-07-28 16:18 ` [Intel-gfx] " Chris Wilson
2015-07-29 15:20 ` Benjamin Tissoires [this message]
2015-07-29 15:20 ` Benjamin Tissoires
2015-07-28 16:03 ` [PATCH 3/3] drm/i915: Support DDI lane reversal for DP Benjamin Tissoires
2015-07-28 16:03 ` Benjamin Tissoires
2015-07-29 8:26 ` Sivakumar Thulasimani
2015-07-29 8:26 ` [Intel-gfx] " Sivakumar Thulasimani
2015-07-29 15:22 ` Benjamin Tissoires
2015-07-29 15:22 ` [Intel-gfx] " Benjamin Tissoires
2015-07-30 4:13 ` Sivakumar Thulasimani
2015-07-30 4:13 ` [Intel-gfx] " Sivakumar Thulasimani
2015-07-30 14:44 ` Benjamin Tissoires
2015-07-30 14:44 ` [Intel-gfx] " Benjamin Tissoires
2015-08-05 19:34 ` Benjamin Tissoires
2015-08-05 19:34 ` [Intel-gfx] " Benjamin Tissoires
2015-08-06 9:41 ` Sivakumar Thulasimani
2015-08-06 9:41 ` [Intel-gfx] " Sivakumar Thulasimani
2015-08-14 23:27 ` Stéphane Marchesin
2015-08-14 23:27 ` [Intel-gfx] " Stéphane Marchesin
2015-08-17 20:06 ` Benjamin Tissoires
2015-08-17 20:06 ` [Intel-gfx] " Benjamin Tissoires
2015-08-26 12:09 ` Sivakumar Thulasimani
2015-08-26 12:09 ` [Intel-gfx] " Sivakumar Thulasimani
2015-08-26 14:29 ` Benjamin Tissoires
2015-08-26 14:29 ` [Intel-gfx] " Benjamin Tissoires
2015-08-27 5:24 ` Sivakumar Thulasimani
2015-08-27 5:24 ` [Intel-gfx] " Sivakumar Thulasimani
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=20150729152022.GC2743@mail.corp.redhat.com \
--to=benjamin.tissoires@redhat.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tbroch@chromium.org \
/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.