From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Cc: Yanmin Zhang <yanmin.zhang@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Rajesh Shah <rajesh.shah@intel.com>,
linuxppc-dev@ozlabs.org,
linux-pci maillist <linux-pci@atrey.karlin.mff.cuni.cz>
Subject: Re: pci error recovery procedure
Date: Mon, 04 Sep 2006 19:03:12 +1000 [thread overview]
Message-ID: <1157360592.22705.46.camel@localhost.localdomain> (raw)
In-Reply-To: <1157348850.20092.304.camel@ymzhang-perf.sh.intel.com>
> As you know, all functions of a device share the same bus number and 5 bit dev number.
> They just have different 3 bit function number. We could deduce if functions are in the same
> device (slot).
Until you have a P2P bridge ...
> Thanks. Now I understand why you specified mmio_enabled and slot_reset. They are just
> to map to pSeries platform hardware operation steps. I know little about pSeries hardware,
> but is it possible to merge such hardware steps from software point of view?
One of the ideas we had when defining those steps is to be precise
enough to let drivers who _can_ deal with those fine grained pSeries
step implement them, but also have the fallback to slot reset whenever
possible.
Now, if in practice, after actually implementing this in a number of
drivers, we see that slot reset is the only ever used path, then we
might want to simplify things a bit. I didn't want to impose that
restriction in the initial design though.
It's my understanding that doing no slot reset (hardware reset) but just
re-enabling MMIO, DMA and clearing pending error status in the PCI
config space is, as far as the driver is concerned, almost functionally
equivalent to a PCIe link reset. That is, the link reset might not (or
will not) actually reset the hardware beyond the PCIe link layer.
Thus we could simplify the split between link reset / hard reset. The
former is an attempt at recovery with only resetting the PCI path to the
device, which on PCIe becomes a link reset, and on old PCI, just
clearing of the various error bits along the path (and on pSeries,
re-enabling MMIO and DMA access). However, there is still the problem
that if you do that, on pSeries at least, you really want to 1- enable
MMIO, 2- soft reset the card using MMIO, that is make sure all pending
DMA is stopped, and 3- re-enable DMA. While if we collapse that into a
single 'link reset' type of operation, we'll end up re-enabling MMIO and
DMA before the driver has a chance to stop pending DMA's and thus
increase the chance that we crap out due to a pending DMA on the chip.
Ben.
next prev parent reply other threads:[~2006-09-04 9:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1157008212.20092.36.camel@ymzhang-perf.sh.intel.com>
2006-08-31 17:50 ` pci error recovery procedure Linas Vepstas
2006-09-01 3:33 ` Zhang, Yanmin
2006-09-01 21:25 ` Linas Vepstas
2006-09-04 5:47 ` Zhang, Yanmin
2006-09-04 9:03 ` Benjamin Herrenschmidt [this message]
2006-09-05 2:32 ` Zhang, Yanmin
2006-09-05 19:01 ` Linas Vepstas
2006-09-06 1:26 ` Zhang, Yanmin
2006-09-06 20:01 ` Linas Vepstas
2006-09-07 1:56 ` Zhang, Yanmin
2006-09-05 18:50 ` Linas Vepstas
2006-09-05 21:19 ` Benjamin Herrenschmidt
2006-09-06 1:35 ` Zhang, Yanmin
2006-09-05 19:17 ` Linas Vepstas
2006-09-06 2:04 ` Zhang, Yanmin
2006-09-06 20:39 ` Linas Vepstas
2006-09-07 3:18 ` Zhang, Yanmin
2006-09-12 19:38 ` Linas Vepstas
2006-09-01 3:42 ` Zhang, Yanmin
2006-09-01 9:04 ` Zhang, Yanmin
2006-09-01 21:32 ` Linas Vepstas
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=1157360592.22705.46.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linuxppc-dev@ozlabs.org \
--cc=rajesh.shah@intel.com \
--cc=yanmin.zhang@intel.com \
--cc=yanmin_zhang@linux.intel.com \
/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).