From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/4] drm/i915: Disable displays at the user's request
Date: Tue, 6 Nov 2018 19:48:49 +0200 [thread overview]
Message-ID: <20181106174849.GE9144@intel.com> (raw)
In-Reply-To: <153993836279.19935.2454265445353016480@skylake-alporthouse-com>
On Fri, Oct 19, 2018 at 09:39:22AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-10-19 09:22:15)
> > On Mon, Oct 15, 2018 at 12:17:41PM +0100, Chris Wilson wrote:
> > > If the user passes i915.disable_display=1 we want to disable all the
> > > displays and associated HW like the powerwells on their behalf. Instead
> > > of short circuiting the HW probe, let it run and setup all the
> > > bookkeeping for the known HW. Afterwards, instead of taking over the
> > > BIOS fb and installing the fbcon, we shutdown all the outputs and
> > > teardown the bookkeeping, leaving us with no attached outputs or crtcs,
> > > and all the HW powered down.
> > >
> > > Open: wq flushes should be required but seem to deadlock the modprobe
> > > under CI.
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Imre Deak <imre.deak@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > i915.disable_display was for those server chips where doing all the init
> > resulted in a dead machine. So not sure we want this.
>
> For those server chips, we don't use i915.disable_display but detect when
> the fuses are lies and directly set num_pipes == 0. If we had such a
> machine in CI, you would already have seen a lot of the fun with KMS being
> allowed without any backing hw. Hence why Ville suggested we disable KMS
> for machines without pipes to avoid having to add a lot of defense
> around the driver.
>
> > What's the issue with power wells still being on and all that? On real hw
> > without display they won't exist, and I don't understand why we'd care for
> > testing.
>
> For testing. We do use .disable_display and expect rpm to still work, and
> to not get random display related failures interfering in displayless
> tests.
>
> Quite clearly we haven't been testing the displayless setups at all.
I definitely like the idea of testing this without requiring special
hardware. I guess another way to achieve the result of turning
everything off would be to 'modprobe i915 disable_display=0;
rmmod i915; modprobe i915 disable_display=1'. That should avoid the
need to have a special codepath for shutthing things down. Would that
suffice or is there a compelling reason for supporting this without
requiring the driver reload?
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-11-06 17:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 11:17 [PATCH 1/4] drm/i915/fbdev: Use an ordinary worker to avoid async deadlock Chris Wilson
2018-10-15 11:17 ` [PATCH 2/4] drm/i915/fbdev: Use i915/drm_i915_private consistently Chris Wilson
2018-10-15 11:17 ` [PATCH 3/4] drm/i915: Disable displays at the user's request Chris Wilson
2018-10-19 8:22 ` Daniel Vetter
2018-10-19 8:39 ` Chris Wilson
2018-11-06 17:48 ` Ville Syrjälä [this message]
2018-10-15 11:17 ` [PATCH 4/4] HAX: force i915.disable_display=1 Chris Wilson
2018-10-15 11:39 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/fbdev: Use an ordinary worker to avoid async deadlock Patchwork
2018-10-15 11:41 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-10-15 11:52 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-10-17 9:18 ` Patchwork
2018-10-19 8:23 ` [PATCH 1/4] " Daniel Vetter
2018-10-19 8:32 ` Chris Wilson
-- strict thread matches above, loose matches on Subject: below --
2018-09-13 13:16 [PATCH 1/4] drm/i915: Mark up a couple of KMS debug messages as such Chris Wilson
2018-09-13 13:16 ` [PATCH 3/4] drm/i915: Disable displays at the user's request Chris Wilson
2018-09-13 13:19 ` Chris Wilson
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=20181106174849.GE9144@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.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.