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
next prev parent 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