From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: linux-tegra@vger.kernel.org, Kyle Evans <kvans32@gmail.com>,
Mikko Perttunen <cyndis@kapsi.fi>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v1] gpu: host1x: Ignore clients initialization failure
Date: Fri, 3 Aug 2018 12:50:55 +0200 [thread overview]
Message-ID: <20180803105055.GC28546@ulmo> (raw)
In-Reply-To: <20180801150807.15926-1-digetx@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1564 bytes --]
On Wed, Aug 01, 2018 at 06:08:07PM +0300, Dmitry Osipenko wrote:
> From time to time new bugs are popping up, causing some host1x client to
> fail its initialization. Currently a single clients initialization failure
> causes whole host1x device registration to fail, as a result a single DRM
> sub-device initialization failure makes whole DRM initialization to fail.
> Let's ignore clients initialization failure, as a result display panel
> lights up even if some DRM clients (say GR2D or VIC) fail to initialize.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
> drivers/gpu/host1x/bus.c | 18 +++++++-----------
> 1 file changed, 7 insertions(+), 11 deletions(-)
This is actually done on purpose. I can't think of a case where we would
actively like to keep a half-broken DRM device operational. The errors
that you're talking about should only happen during development, and the
device not showing up is a pretty good indicator that something is wrong
as opposed to everything booting normally and then getting some cryptic
error at runtime because one of the clients didn't initialize.
From my perspective, all clients should always be operational in
whatever baseline version you use. If it isn't that's a bug that should
be fixed. Ideally those bugs should get fixed before making it into a
baseline version (mainline, linux-next, ...), so that this never impacts
even developers, unless they break it themselves, in which case refusing
to register the DRM device is a pretty good incentive to fix it.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-08-03 10:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-01 15:08 [PATCH v1] gpu: host1x: Ignore clients initialization failure Dmitry Osipenko
2018-08-03 10:50 ` Thierry Reding [this message]
2018-08-03 11:30 ` Dmitry Osipenko
2018-08-09 10:45 ` Thierry Reding
2018-08-09 12:53 ` Dmitry Osipenko
2018-08-09 13:10 ` Thierry Reding
2018-08-09 13:46 ` Dmitry Osipenko
2018-08-09 14:15 ` Thierry Reding
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=20180803105055.GC28546@ulmo \
--to=thierry.reding@gmail.com \
--cc=cyndis@kapsi.fi \
--cc=digetx@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kvans32@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).