public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: "Christian König" <deathsimple@vodafone.de>,
	kexec@lists.infradead.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/3] drm/radeon kexec fixes
Date: Wed, 11 Sep 2013 10:53:06 +0200	[thread overview]
Message-ID: <20130911085306.GA359@x4> (raw)
In-Reply-To: <CADnq5_MH3+VeLZzpRmHtU-BZzL680e_0577wk0honT002+3GZQ@mail.gmail.com>

On 2013.09.10 at 16:40 -0400, Alex Deucher wrote:
> On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> > Alex Deucher <alexdeucher@gmail.com> writes:
> >
> >> On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf
> >> <markus@trippelsdorf.de> wrote:
> >>
> >>> IIRC Alex said the sanity checks are expensive and boot-time could be
> >>> improved by dropping them. Maybe he can chime in?
> >>
> >> They shouldn't be necessary with a proper shutdown, but in this
> >> particular case, they are not very expensive.  What is expensive is
> >> having a separate sanity check functions for all the various hw blocks
> >> to teardown everything on startup prior to starting it up in case
> >> kexec, etc. left the system in a bad state.  It ends up amounting to a
> >> full tear down sequence followed by a full start up sequence every
> >> time you load the driver.
> >>
> >> I can't really comment on the first patch, but the rest seem fine.
> >
> > Let me reask the question just a little bit.
> >
> > Is it the sanity checks that are expensive?  Or is it the
> > reinitialization that is triggered by the sanity checks that is
> > expensive?
> >
> > From what Christian said in the other reply it sounds like this is a
> > game we will never completely win, but it would be nice to have half a
> > chance in the kexec on panic case to have video.  So I am curious to
> > know if the checks are expensive when we are coming at hardware in a
> > clean state.
> 
> The particular sanity checks from this patch set are not expensive,
> but we had previously discussed more extensive sanity checks for other
> aspects of the chips in prior conversations.  Prior to this patch set,
> the hw is not torn down properly (might have been in the middle of DMA
> for example) when kexec happens.  That's why the sanity checks were
> added in the first place.  With this patch set, the sanity checks
> shouldn't be necessary.

I think you're talking past each other. 
What Eric worries about is the »kexec on panic« case, where the shutdown
method *isn't* called. In this case the sanity checks, that are only
superfluous when the hardware was shutdown normally during kexec (the
default case), may actually help. And because the checks aren't
expensive, it wouldn't hurt to just leave them in place.

-- 
Markus

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2013-09-11  8:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-08 12:09 [PATCH 0/3] drm/radeon kexec fixes Markus Trippelsdorf
2013-09-08 12:10 ` [PATCH 1/3] kexec: get rid of late printk Markus Trippelsdorf
2013-09-08 20:11   ` Daniel Vetter
2013-09-08 20:42     ` Bruno Prémont
2013-09-08 12:10 ` [PATCH 2/3] drm/radeon: Implement radeon_pci_shutdown Markus Trippelsdorf
2013-09-09 13:32   ` Konrad Rzeszutek Wilk
2013-09-08 12:11 ` [PATCH 3/3] drm/radeon: get rid of r100_restore_sanity hack Markus Trippelsdorf
2013-09-09  0:32 ` [PATCH 0/3] drm/radeon kexec fixes Eric W. Biederman
2013-09-09  9:21   ` Markus Trippelsdorf
2013-09-09  9:38     ` Christian König
2013-09-11  9:01       ` Markus Trippelsdorf
2013-09-11  9:10         ` Christian König
2013-09-11 13:30         ` Alex Deucher
2013-09-09 13:04     ` Alex Deucher
2013-09-10 18:27       ` Eric W. Biederman
2013-09-10 20:40         ` Alex Deucher
2013-09-11  8:53           ` Markus Trippelsdorf [this message]
2013-09-11  9:21             ` Christian König
2013-09-11 13:40             ` Alex Deucher

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=20130911085306.GA359@x4 \
    --to=markus@trippelsdorf.de \
    --cc=alexdeucher@gmail.com \
    --cc=deathsimple@vodafone.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.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