Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
On Fri, 9 Mar 2012 14:46:45 +1100 Anton Blanchard an...@samba.org wrote: Hi Ben, Looks like something that got fixed but the new patches from Bjorn aren't in next yet. I'll fwd you the patch separately to apply on top of what you have see if that helps (to confirm that's indeed the issue). Thanks, confirmed that it fixes it. Patch below in case anyone else is hitting it. Anton -- On Sat, 2012-03-03 at 08:52 +1100, Benjamin Herrenschmidt wrote: Or give me a chance to dig :-) I'll have a look next week. This is indeed what bjorn suspected on irc, this patch fixes it: (Bjorn, please fold it in the original offending patch) Thanks guys; I'll push the fixes to -next when I get to a real network (at the airport now about to run out of battery with a crappy connection). Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 09/24] PCI, powerpc: Register busn_res for root buses
On Thu, 23 Feb 2012 12:51:30 -0800
Bjorn Helgaas bhelg...@google.com wrote:
On Thu, Feb 23, 2012 at 12:25 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 10 Feb 2012 08:35:58 +1100
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Thu, 2012-02-09 at 11:24 -0800, Bjorn Helgaas wrote:
My point is that the interface between the arch and the PCI core
should be simply the arch telling the core this is the range of bus
numbers you can use. If the firmware doesn't give you the HW limits,
that's the arch's problem. If you want to assume 0..255 are
available, again, that's the arch's decision.
But the answer to the question what bus numbers are available to me
depends only on the host bridge HW configuration. It does not depend
on what pci_scan_child_bus() found. Therefore, I think we can come up
with a design where pci_bus_update_busn_res_end() is unnecessary.
In an ideal world yes. In a world where there are reverse engineered
platforms on which we aren't 100% sure how thing actually work under the
hood and have the code just adapt on what's there (and try to fix it
up -sometimes-), thinks can get a bit murky :-)
But yes, I see your point. As for what is the correct setting that
needs to be done so that the patch doesn't end up a regression for us,
I'll have to dig into some ancient HW to dbl check a few things. I hope
0...255 will just work but I can't guarantee it.
What I'll probably do is constraint the core to the values in
hose-min/max, and update selected platforms to put 0..255 in there when
I know for sure they can cope.
But I think the point is, can't we intiialize the busn resource after
the first last bus numbers have been determined? E.g. rather than
Yinghai's current:
+ pci_bus_insert_busn_res(bus, hose-first_busno, hose-last_busno);
+
/* Get probe mode and perform scan */
mode = PCI_PROBE_NORMAL;
if (node ppc_md.pci_probe_mode)
@@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct
pci_controller *hose)
of_scan_bus(node, bus);
}
- if (mode == PCI_PROBE_NORMAL)
+ if (mode == PCI_PROBE_NORMAL) {
+ pci_bus_update_busn_res_end(bus, 255);
hose-last_busno = bus-subordinate =
pci_scan_child_bus(bus);
+ pci_bus_update_busn_res_end(bus, bus-subordinate);
+ }
we'd have something more like:
/* Get probe mode and perform scan */
mode = PCI_PROBE_NORMAL;
if (node ppc_md.pci_probe_mode)
@@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct
pci_controller *hose)
of_scan_bus(node, bus);
}
if (mode == PCI_PROBE_NORMAL)
hose-last_busno = bus-subordinate =
pci_scan_child_bus(bus);
+ pci_bus_insert_busn_res(bus, hose-first_busno, hose-last_busno);
since we should have the final bus range by then? Setting the end to
255 and then changing it again doesn't make sense; and definitely makes
the code hard to follow.
I have two issues here:
1) hose-last_busno is currently the highest bus number found by
pci_scan_child_bus(). If I understand correctly,
pci_bus_insert_busn_res() is supposed to update the core's idea of the
host bridge's bus number aperture. (Actually, I guess it just updates
the *end* of the aperture, since we supply the start directly to
pci_scan_root_bus()). The aperture and the highest bus number we
found are not related, except that we should have:
hose-first_busno = bus-subordinate = hose-last_busno
If we set the aperture to [first_busno - last_busno], we artificially
prevent some hotplug.
Oh true, we'll need to allocate any extra bus number space somehow so
that hot plug of bridges is possible in the future w/o renumbering
(until our glorious future when we can move resources on the fly by
stopping drivers).
2) We already have a way to add resources to a root bus: the
pci_add_resource() used to add I/O port and MMIO apertures. I think
it'd be a lot simpler to just use that same interface for the bus
number aperture, e.g.,
pci_add_resource(resources, hose-io_space);
pci_add_resource(resources, hose-mem_space);
pci_add_resource(resources, hose-busnr_space);
bus = pci_scan_root_bus(dev, next_busno, pci_ops, sysdata, resources);
This is actually a bit redundant, since next_busno should be the
same as hose-busnr_space-start. So if we adopted this approach, we
might want to eventually drop the next_busno argument.
Yeah that would be nice, the call would certainly make more sense that
way.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
On Fri, 23 Jul 2010 14:56:28 +0100
Ben Hutchings bhutchi...@solarflare.com wrote:
commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 PCI: MSI: Remove
unsafe and unnecessary hardware access changed read_msi_msg_desc() to
return the last MSI message written instead of reading it from the
device, since it may be called while the device is in a reduced
power state.
However, the pSeries platform code really does need to read messages
from the device, since they are initially written by firmware.
Therefore:
- Restore the previous behaviour of read_msi_msg_desc()
- Add new functions get_cached_msi_msg{,_desc}() which return the
last MSI message written
- Use the new functions where appropriate
Signed-off-by: Ben Hutchings bhutchi...@solarflare.com
---
Compile-tested only.
Applied to linux-next with Michael's ack, thanks. I hope it actually
works, I didn't see a tested-by!
--
Jesse Barnes, Intel Open Source Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] PCI fixes
On Wed, 9 Jun 2010 16:14:10 -0700 (PDT) Linus Torvalds torva...@linux-foundation.org wrote: On Wed, 9 Jun 2010, Jesse Barnes wrote: Nothing too big here; I do have a couple of fixes in the queue that aren't included here though. I'll be pulling them together over the next couple of days. Hmm. None of these seem to really be relevant. The fact that one is from me doesn't make me any more eager to pull. Are any of these real regressions (the missing parenthesis one seems to be the only one that could be serious, but I didn't grep for actual use). Ok I've updated the tree to cover the regressions reported so far, including the printk change so we get fewer spurious reports. Note it hasn't gone through linux-next yet, but the patches are all small and have each been tested individually. There's one change in particular I'd like you (along with the cc'd arch maintainers) to review: commit 837c4ef13c44296bb763a0ca0e84a076592474cf Author: Yinghai Lu yinghai...@oracle.com Date: Thu Jun 3 13:43:03 2010 -0700 PCI: clear bridge resource range if BIOS assigned bad one This fixes a regression rather minimally, but may have side effects I'm not seeing. An alternative to that fix would be to revert commit d65245c3297ac63abc51a976d92f45f2195d2854 Author: Yinghai Lu ying...@kernel.org Date: Fri Jan 22 01:02:23 2010 -0800 PCI: don't shrink bridge resources but it seems that's a bit more risky at this point, since it could affect hotplug and rescan cases. Really this code needs to be reworked, especially in light of the revert of 977d17bb1749517b353874ccdc9b85abc7a58c2a which tried (and failed) to perform aggressive reallocation when devices weren't configured. I'll try to find some time next week to work on that. The following changes since commit 9dda696f0de87a2e5cfabb147e28c76b7d3c6846: Linus Torvalds (1): Merge branch 'release' of git://git.kernel.org/.../aegl/linux-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 for-linus Bjorn Helgaas (1): PCI: change resource collision messages from KERN_ERR to KERN_INFO Jesse Barnes (1): Revert PCI: create function symlinks in /sys/bus/pci/slots/N/ Jiri Slaby (1): PCI: hotplug/cpqphp, fix NULL dereference Yinghai Lu (1): PCI: clear bridge resource range if BIOS assigned bad one Documentation/ABI/testing/sysfs-bus-pci | 40 - arch/microblaze/pci/pci-common.c|1 + arch/mn10300/unit-asb2305/pci-asb2305.c |1 + arch/powerpc/kernel/pci-common.c|1 + arch/x86/pci/i386.c |2 + drivers/pci/hotplug/cpqphp_core.c |7 drivers/pci/pci-sysfs.c | 37 --- drivers/pci/setup-res.c | 10 +++--- drivers/pci/slot.c | 48 --- 9 files changed, 17 insertions(+), 130 deletions(-) Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Proposal to move PCI out of arch/powerpc and into drivers/of
On Fri, 26 Feb 2010 16:07:59 -0700 John Linn john.l...@xilinx.com wrote: Hi all, We are in the process of putting PCI/PCIe into the microblaze architecture. In order to not duplicate/fork the PCI code in Powerpc, we're proposing to move the PCI code from arch/powerpc into drivers/of such that it would be common code for Powerpc and MicroBlaze. This would be the 1st part of a refactoring that would occur with the PCI code. Ben H., would you mind if that happened (move arch/powerpc/kernel/pci* to drivers/of/*)? Dave and Ben have been talking about this for awhile; seems like a good excuse to do it. IIRC they had even thought about just dumping the code directly into drivers/pci so that API updates won't get missed... -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 0/5] PCI: try pci=use_crs again
On Tue, 23 Feb 2010 10:24:15 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: Historically, Linux has assumed a single PCI host bridge, with that bridge claiming all the address space left after RAM and legacy devices are taken out. If the system contains multiple host bridges, we can no longer operate under that assumption. We have to know what parts of the address space are claimed by each bridge so that when we assign resources to a PCI device, we take them from a range claimed by the upstream host bridge. On x86 and ia64, we use ACPI to enumerate all the PCI host bridges in the system, and part of the host bridge description is the _CRS (current resource settings property, which lists the address space used by the bridge. On x86, we currently ignore most of the _CRS information. This patch series changes this, so we will use _CRS to learn about the host bridge windows. Since most x86 machines with multiple host bridges are relatively new, this series only turns this on for machines with BIOS dates of 2008 or newer. Changes from v4 to v5: - Add EXPORT_SYMBOL_GPL(pci_bus_resource_n) for module builds. Thanks, it built this time. Pushed to my linux-next branch. -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/5] PCI: split up pci_read_bridge_bases()
On Wed, 17 Feb 2010 13:19:52 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: No functional change; this breaks up pci_read_bridge_bases() into separate pieces for the I/O, memory, and prefetchable memory windows, similar to how Yinghai recently split up pci_setup_bridge() in 68e84ff3bdc. Signed-off-by: Bjorn Helgaas bjorn.helg...@hp.com --- Applied this series, thanks Bjorn. Hopefully this one will successfully run the linux-next gauntlet too. :) -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/5] PCI: split up pci_read_bridge_bases()
On Wed, 17 Feb 2010 13:19:52 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: No functional change; this breaks up pci_read_bridge_bases() into separate pieces for the I/O, memory, and prefetchable memory windows, similar to how Yinghai recently split up pci_setup_bridge() in 68e84ff3bdc. Signed-off-by: Bjorn Helgaas bjorn.helg...@hp.com --- Had to drop these again, got: Kernel: arch/x86/boot/bzImage is ready (#16) MODPOST 2245 modules ERROR: pci_bus_resource_n [drivers/pcmcia/yenta_socket.ko] undefined! ERROR: pci_bus_resource_n [drivers/pcmcia/rsrc_nonstatic.ko] undefined! ERROR: pci_bus_resource_n [drivers/pci/hotplug/shpchp.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 when building. -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] PCI-E broken on PPC (regression)
On Wed, 17 Feb 2010 16:22:59 -0800 (PST) David Miller da...@davemloft.net wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Wed, 27 Jan 2010 13:10:56 +1100 I'll try do make ppc catch up with some of that see how it goes. FWIW I'm taking care of syncing up sparc in this area right now. I just noticed the -dma_mask assignment got moved as well. Really, any change made to drivers/pci/probe.c is going to require powerpc and sparc changes these days. We should and will commonize our OpenFirmware PCI device probing code under driver/pci but until that happens a real effort needs to be put in place to at least ping Benjamin and myself when changes are going in to drivers/pci/probe.c Ok I'll include you guys on further changes. -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] PCI-E broken on PPC (regression)
On Wed, 27 Jan 2010 13:10:56 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Cc'ing Ben for PPC. Ben, should PPC use pci_scan_device when probing its root busses? Sounds like it just uses pci_device_add for each one it finds instead? If you don't actually need scanning (though what about hotplug?) we can move the call to device_add instead... Ok so I looked at the code and the problem goes way beyond root busses. Basically, powerpc can use the code in arch/powerpc/kernel/pci_of_scan.c to generate the pci_dev without using config space probing or at least using as little of it as possible, using the firmware device-tree information instead. This is also probably going to be moved to a more generic place and extended to be used optionally by other architectures. I think sparc does something similar in fact in arch/sparc/kernel/pci.c (of_create_pci_dev()) though it would be logical to have sparc and powerpc share the same implementation here in the long run and I believe Grant Likely is working on it. That means that potentially, pci_dev will be created on those archs for which pci_setup_device() is never called. Thus we need to be very careful when adding initializations there that at least we (myself and davem) are notified of that so we can mirror them in our code, or even better, if people doing so put them there too... So as far as I can tell, we are missing that set_pcie_port_type(), so we need to add it to sparc and powerpc (and so make the function non-static in drivers/pci/probe.c). We are also missing the manipulation of dev-slot in fact, so that will need to be fixed too. set_pcie_hotplug_bridge() might be something we want to add too, it's not totally clear yet due to possible issues with our firmwares. pci_fixup_device(pci_fixup_early,...) as well in fact. I'll try do make ppc catch up with some of that see how it goes. Thanks Ben. Any refactoring we need to handle this stuff better is fine with me too. I guess on some platforms calling pci_setup_device may cause problems with special platform devices? -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/pci: Add calls to set_pcie_port_type() and set_pcie_hotplug_bridge()
On Wed, 27 Jan 2010 14:10:03 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: We are missing these when building the pci_dev from scratch off the Open Firmware device-tree Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/kernel/pci_of_scan.c |2 ++ drivers/pci/probe.c |4 ++-- include/linux/pci.h |4 3 files changed, 8 insertions(+), 2 deletions(-) Jesse, can I have an ack for the generic bits ? Note that I couldn't test on a pSeries machine with PCI-E as all such machines in ozlabs currently have all their partitions with PCI-E devices in them in FAIL state in ABAT and our admin is out. Yeah, generic bits look fine. Acked-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] PCI-E broken on PPC (regression)
On Wed, 27 Jan 2010 16:01:21 -0800 (PST) David Miller da...@davemloft.net wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Thu, 28 Jan 2010 09:00:12 +1100 On Wed, 2010-01-27 at 08:26 -0800, Jesse Barnes wrote: Thanks Ben. Any refactoring we need to handle this stuff better is fine with me too. I guess on some platforms calling pci_setup_device may cause problems with special platform devices? Well, we don't call pci_setup_device() because part of the deal is to avoid all of that config space reading that it does :-) Especially in the case of some of the IBM EADS bridges which don't let you access everything we may want. Same problem on sparc64, it's not safe to poke config space arbitrarily. Some PCI controllers even have bugs which cause them to hang if you try to access some parts of the host controller's PCI config space. Ok, that's what I thought. We'll need to make these functions available then... -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] PCI-E broken on PPC (regression)
On Mon, 25 Jan 2010 11:42:29 -0200 Breno Leitao lei...@linux.vnet.ibm.com wrote: Hello, I found that qlge is broken on PPC, and it got broken after commit 06a1cbafb253c4c60d6a54a994887f5fbceabcc0. It happens because dev-pcie is not set on PPC, because the function set_pcie_port_type(), who sets dev-pcie, is not being called on PPC PCI code. You mean dev-is_pcie? Why isn't pci_scan_device calling pci_setup_device for you? That should do the proper PCIe init depending on the device, along with extracting other device info... -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] PCI-E broken on PPC (regression)
On Mon, 25 Jan 2010 12:38:49 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 25 Jan 2010 11:42:29 -0200 Breno Leitao lei...@linux.vnet.ibm.com wrote: Hello, I found that qlge is broken on PPC, and it got broken after commit 06a1cbafb253c4c60d6a54a994887f5fbceabcc0. It happens because dev-pcie is not set on PPC, because the function set_pcie_port_type(), who sets dev-pcie, is not being called on PPC PCI code. You mean dev-is_pcie? Why isn't pci_scan_device calling pci_setup_device for you? That should do the proper PCIe init depending on the device, along with extracting other device info... Cc'ing Ben for PPC. Ben, should PPC use pci_scan_device when probing its root busses? Sounds like it just uses pci_device_add for each one it finds instead? If you don't actually need scanning (though what about hotplug?) we can move the call to device_add instead... -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
On Wed, 09 Dec 2009 17:52:13 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: The cardbus code creates PCI devices without ever going through the necessary fixup bits and pieces that normal PCI devices go through. There's in fact a commented out call to pcibios_fixup_bus() in there, it's commented because ... it doesn't work. I could make pcibios_fixup_bus() do the right thing on powerpc easily but I felt it cleaner instead to provide a specific hook pci_fixup_cardbus for which a weak empty implementation is provided by the PCI core. This fixes cardbus on powerbooks and probably all other PowerPC platforms which was broken completely for ever on some platforms and since 2.6.31 on others such as PowerBooks when we made the DMA ops mandatory (since those are setup by the fixups). Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Applied, thanks. Had to fix up a conflict since someone had helpfully changed the comment from a // to a /* .. */ in cardbus.c. -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
On Wed, 09 Dec 2009 17:52:13 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: The cardbus code creates PCI devices without ever going through the necessary fixup bits and pieces that normal PCI devices go through. There's in fact a commented out call to pcibios_fixup_bus() in there, it's commented because ... it doesn't work. I could make pcibios_fixup_bus() do the right thing on powerpc easily but I felt it cleaner instead to provide a specific hook pci_fixup_cardbus for which a weak empty implementation is provided by the PCI core. This fixes cardbus on powerbooks and probably all other PowerPC platforms which was broken completely for ever on some platforms and since 2.6.31 on others such as PowerBooks when we made the DMA ops mandatory (since those are setup by the fixups). Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- Note: In the long run we might want to streamline the hooks for fixing up new devices vs. new busses and make some stuff common between cardbus and PCI hotplug which is actually a mess. This is a quick fix that makes it work again in the meantime, and that I would like to see in 2.6.31 and 2.6.32 stable at least. Another option if you prefer is I can make my pcibios_fixup_bus() do the right thing in all cases I believe (by testing bus-is_added to skip stuff that must not be done twice) and we can remove the comment and stick the call in #ifdef CONFIG_PPC but I felt that solution was a tad cleaner. Olof, once that's in you should be able to remove the hack you have in the PA-Semi code to work around this. Oops, looks like this fails for the modular case? I get an unresolved symbol error when building this with my default config... Care to resend with the fix against my for-linus branch? Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
On Wed, 09 Dec 2009 17:52:13 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: The cardbus code creates PCI devices without ever going through the necessary fixup bits and pieces that normal PCI devices go through. There's in fact a commented out call to pcibios_fixup_bus() in there, it's commented because ... it doesn't work. I could make pcibios_fixup_bus() do the right thing on powerpc easily but I felt it cleaner instead to provide a specific hook pci_fixup_cardbus for which a weak empty implementation is provided by the PCI core. This fixes cardbus on powerbooks and probably all other PowerPC platforms which was broken completely for ever on some platforms and since 2.6.31 on others such as PowerBooks when we made the DMA ops mandatory (since those are setup by the fixups). Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Ah the link failure was my fault. I had fixed up the conflict incorrectly. It's applied now. -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] Support for PCI Express reset type
On Thu, 30 Jul 2009 15:33:21 -0700 Mike Mason mm...@us.ibm.com wrote: This is the first of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery. By default, the EEH framework on powerpc does what's known as a hot reset during recovery of a PCI Express device. We've found a case where the device needs a fundamental reset to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that indicates whether the device requires a fundamental reset during recovery. These patches supersede the previously submitted patch that implemented a fundamental reset bit field. Please review and let me know of any concerns. Signed-off-by: Mike Mason mm...@us.ibm.com Signed-off-by: Richard Lary rl...@us.ibm.com Ok, applied this series to my linux-next branch, it looks pretty reasonable to me. For future patches, please cc me, and include the subsystem in the subject, along with a specific description of the patch, e.g. PCI: add PCIe fundamental reset interface, PCI: document PCIe fundamental reset, or for arch specific patches, PCI/powerpc: implement support for PCIe fundamental reset. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] pci/msi: Use #ifdefs instead of weak functions
On Sunday, January 18, 2009 4:31 pm Michael Ellerman wrote: Weak functions aren't all they're cracked up to be. They lead to incorrect binaries with some toolchains, they require us to have empty functions we otherwise wouldn't, and the unused code is not elided (as of gcc 4.3.2 anyway). So replace the weak MSI arch hooks with the #define foo foo idiom. We no longer need empty versions of arch_setup/teardown_msi_irq(). This is less source (by 1 line!), and results in smaller binaries too: text data bss dec hex filename 9354300 1693916 678424 11726640 b2ef30 build/powerpc/vmlinux-before 9354052 1693852 678424 11726328 b2edf8 build/powerpc/vmlinux-after Also smaller on x86_64 and arm (iop13xx). Signed-off-by: Michael Ellerman mich...@ellerman.id.au Applied to my linux-next branch, thanks Michael. -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] pci: Workaround invalid P2P bridge bus numbers
On Tuesday, October 21, 2008 3:33 pm Benjamin Herrenschmidt wrote: On Tue, 2008-10-21 at 09:36 -0500, Ayman El-Khashab wrote: Ayman, can you double check that this variant of the patch still fixes your problem ? Thanks ! I've tried it out and it is working correctly with my devices. The subordinate bus numbers on all the ports are correct. Thanks ! Great, pushed to linux-next. Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] pci: Workaround invalid P2P bridge bus numbers
On Monday, October 20, 2008 4:06 pm Benjamin Herrenschmidt wrote: Some firmware fail to properly configure P2P bridges, leaving them with invalid bus numbers. In some cases, this happens on some embedded 4xx boards as the result of the kernel allocating different bus space than the firmware does to host bridges while not setting pcibios_assign_all_busses() for various reasons. In other cases, it can just be bogus firmware. This adds some sanity checking to the PCI probing code. If a bridge is found whose primary bus number doesn't match the bus it's sitting on, or whose secondary bus number not strictly above it's primary bus number, then the bridge bus numbers are deconfigured in the first pass of pci_scan_bridge() to be re-assigned in the second pass. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Ayman, can you double check that this variant of the patch still fixes your problem ? Thanks ! Sure, seems straightforward enough, I'll wait for Ayman's Tested-by before pushing. Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add legacy PCI access via sysfs (v3)
On Monday, October 13, 2008 5:55 pm Benjamin Herrenschmidt wrote: This patch adds support for legacy_io and legacy_mem files in bus class directories in sysfs for powerpc Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Ok, applied this one. Should be pushing to Linus soon. Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add legacy PCI access via sysfs
On Monday, October 13, 2008 7:07 am Josh Boyer wrote: On Fri, Oct 10, 2008 at 10:39:18AM -0700, Jesse Barnes wrote: On Thursday, October 9, 2008 7:50 pm Benjamin Herrenschmidt wrote: This patch adds support for legacy_io and legacy_mem files in bus class directories in sysfs for powerpc Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Applied to linux-next, thanks. Is that targeted towards .28 or .29? Ben has a 4xx specific patch that depends on this one, and I just need to know which version to bring that in for. I was planning on sending it for .28. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add legacy PCI access via sysfs
On Thursday, October 9, 2008 7:50 pm Benjamin Herrenschmidt wrote: This patch adds support for legacy_io and legacy_mem files in bus class directories in sysfs for powerpc Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- This is version 2, slightly different approach for getting at VGA memory which works a lot better with bridges providing a separate ISA Memory hole (which is the case of most of them). Also tested on a variety of hardware with a little tool using x86emu to run VGA BIOSes, do VBE calls and whack text mode. This patch relies on its generic counterpart, posted previously being applied first. Jesse, due to the dependency, it's better if we have both in the powerpc tree -or- both in the PCI tree, what do you think is best ? Either that or I have to delay applying it to powerpc until you get the generic part in. Ah I was worried the first one might need a respin, but it applied fine, so I'll go ahead and apply this one too. Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add legacy PCI access via sysfs
On Thursday, October 9, 2008 7:50 pm Benjamin Herrenschmidt wrote: This patch adds support for legacy_io and legacy_mem files in bus class directories in sysfs for powerpc Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Applied to linux-next, thanks. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/2] pci: Add ability to mmap legacy_io on some platforms
On Friday, October 3, 2008 2:49 am Benjamin Herrenschmidt wrote: This adds the ability to mmap legacy IO space to the legacy_io files in sysfs on platforms that support it. This will allow to clean up X to use this instead of /dev/mem for legacy IO accesses such as those performed by Int10. While at it I moved pci_create/remove_legacy_files() to pci-sysfs.c where I think they belong, thus making more things statis in there and cleaned up some spurrious prototypes in the ia64 pci.h file Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- I didn't have a chance to test that I didn't break ia64, so I would be if somebody could give it a spin there ! Thanks ! arch/ia64/include/asm/pci.h | 12 - arch/ia64/pci/pci.c |7 ++- drivers/pci/pci-sysfs.c | 93 +--- drivers/pci/pci.h | 6 ++ drivers/pci/probe.c | 66 --- 5 files changed, 102 insertions(+), 82 deletions(-) Heh, is it obvious that this code originated on ia64 and no one ever ported it to another platform until now? :) Tony and/or Bjorn, do you want to take a look and make sure this is ok? If so I can take the whole thing into the PCI tree. Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/2] powerpc: Add legacy PCI access via sysfs
On Friday, October 3, 2008 2:49 am Benjamin Herrenschmidt wrote:
+ /* WARNING: The generic code is idiotic. It gets passed a pointer
+ * to what can be a 1, 2 or 4 byte quantity and always reads that
+ * as a u32, which means that we have to correct the location of
+ * the data read within those 32 bits for size 1 and 2
+ */
+ switch(size) {
+ case 1:
+ out_8(addr, val 24);
+ return 1;
+ case 2:
+ if (port 1)
+ return -EINVAL;
+ out_le16(addr, val 16);
+ return 2;
+ case 4:
+ if (port 3)
+ return -EINVAL;
+ out_le32(addr, val);
+ return 4;
+ }
+ return -EINVAL;
Feel free to change the generic code if it makes things easier for you, the
only limitation is that we have to live within the generic sysfs read/write
functions. Obviously I didn't worry about it when doing this code on ia64...
Jesse
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/2] powerpc: Add legacy PCI access via sysfs
On Friday, October 3, 2008 2:52 pm Benjamin Herrenschmidt wrote: On Fri, 2008-10-03 at 08:59 -0700, Jesse Barnes wrote: Feel free to change the generic code if it makes things easier for you, the only limitation is that we have to live within the generic sysfs read/write functions. Obviously I didn't worry about it when doing this code on ia64... I started to do that and then decided not to bother... Well than you can at least update the comment in the ppc platform code from The generic code is idiotic to The generic code is idiotic and I'm too lazy to fix it. :) -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] hotplug/rpaphp: remove unused error path code
On Monday, August 18, 2008 6:45 pm Stephen Rothwell wrote: Commit f46753c5e354b857b20ab8e0fe7b2579831dc369 (PCI: introduce pci_slot) removed the need for this error path. Eliminate this warning: drivers/pci/hotplug/rpaphp_slot.c: In function 'rpaphp_register_slot': drivers/pci/hotplug/rpaphp_slot.c:151: warning: label 'sysfs_fail' defined but not used Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] Applied to linux-next, thanks. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: pci-current tree build failure
On Monday, July 28, 2008 5:52 pm Stephen Rothwell wrote: Hi Jesse, Today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/iommu.c:54: error: static declaration of 'iommu_num_pages' follows non-static declaration include/linux/iommu-helper.h:11: error: previous declaration of 'iommu_num_pages' was here Caused by commit 3bc9f79ee1ddc913be0a6d3592036683ef8a3148 (iommu: add iommu_num_pages helper function) which introduced a global version of a function that powerpc has a different version of. I am not sure that the two do the same thing - in fact they don't since powerpc can have a 64k page size and still need to use a 4k iommu pages. I applied the patch below (which I personally hate :-)) Hopefully my ppc machine will arrive soon and I can build test boot things so this won't happen in the future. Joerg, what do you think here? Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Tuesday, June 10, 2008 8:29 pm Nick Piggin wrote: On Wednesday 11 June 2008 05:19, Jesse Barnes wrote: On Tuesday, June 10, 2008 12:05 pm Roland Dreier wrote: me too. That's the whole basis for readX_relaxed() and its cohorts: we make our weirdest machines (like altix) conform to the x86 norm. Then where it really kills us we introduce additional semantics to selected drivers that enable us to recover I/O speed on the abnormal platforms. Except as I pointed out before, Altix doesn't conform to the norm and many (most?) drivers are missing mmiowb()s that are needed for Altix. Just no one has plugged most devices into an Altix (or haven't stressed the driver in a way that exposes problems of IO ordering between CPUs). It would be a great thing to use the powerpc trick of setting a flag that is tested by spin_unlock()/mutex_unlock() and automatically doing the mmiowb() if needed, and then killing off mmiowb() entirely. Yeah I think that's what Nick's guidelines would guarantee. And Jes is already working on the spin_unlock change you mentioned, so mmiowb() should be history soon (in name only, assuming Nick also introduces the I/O barriers he talked about for ordering the looser accessors it would still be there but would be called io_wmb or something). Exactly, yes. I guess everybody has had good intentions here, but as noticed, what is lacking is coordination and documentation. You mention strong ordering WRT spin_unlock, which suggests that you would prefer to take option #2 (the current powerpc one): io/io is ordered and io is contained inside spinlocks, but io/cacheable in general is not ordered. I was thinking it would be good for the weaker accessors, but now that I think about it you could just use the new io_* barrier functions. I didn't mean to imply that I wasn't in favor of the io/cacheable ordering as well. For any high performance drivers that are well maintained (ie. the ones where slowdown might be noticed), everyone should have a pretty good handle on memory ordering requirements, so it shouldn't take long to go through and convert them to relaxed accessors. Yep. Thanks for working on this, Nick, it's definitely a good thing that you're taking control of it. :) Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Monday, June 09, 2008 11:56 pm Nick Piggin wrote: So that still doesn't tell us what *minimum* level of ordering we should provide in the cross platform readl/writel API. Some relatively sane suggestions would be: - as strong as x86. guaranteed not to break drivers that work on x86, but slower on some archs. To me, this is most pleasing. It is much much easier to notice something is going a little slower and to work out how to use weaker ordering there, than it is to debug some once-in-a-bluemoon breakage caused by just the right architecture, driver, etc. It totally frees up the driver writer from thinking about barriers, provided they get the locking right. - ordered WRT other IO accessors, constrained within spinlocks, but not cacheable memory. This is what powerpc does now. It's a little faster for them, and probably covers the vast majority of drivers, but there are real possibilities to get it wrong (trivial example: using bit locks or mutexes or any kind of open coded locking or lockless synchronisation can break). - (less sane) same as above, but not ordered WRT spinlocks. This is what ia64 (sn2) does. From a purist POV, it is a little less arbitrary than powerpc, but in practice, it will break a lot more drivers than powerpc. I was kind of joking about taking control of this issue :) But seriously, it needs a decision to be made. I vote for #1. My rationale: I'm still finding relatively major (well, found maybe 4 or 5 in the last couple of years) bugs in the mm subsystem due to memory ordering problems. This is apparently one of the most well reviewed and tested bit of code in the kernel by people who know all about memory ordering. Not to mention that mm/ does not have to worry about IO ordering at all. Then apparently driver are the least reviewed and tested. Connect dots. Now that doesn't leave waker ordering architectures lumped with slow old x86 semantics. Think of it as giving them the benefit of sharing x86 development and testing :) We can then formalise the relaxed __ accessors to be more complete (ie. +/- byteswapping). I'd also propose to add io_rmb/io_wmb/io_mb that order io/io access, to help architectures like sn2 where the io/cacheable barrier is pretty expensive. Any comments? FWIW that approach sounds pretty good to me. Arches that suffer from performance penalties can still add lower level primitives and port selected drivers over, so really they won't be losing much. AFAICT though drivers will still have to worry about regular memory ordering issues; they'll just be safe from I/O related ones. :) Still, the simplification is probably worth it. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Tuesday, June 10, 2008 12:05 pm Roland Dreier wrote: me too. That's the whole basis for readX_relaxed() and its cohorts: we make our weirdest machines (like altix) conform to the x86 norm. Then where it really kills us we introduce additional semantics to selected drivers that enable us to recover I/O speed on the abnormal platforms. Except as I pointed out before, Altix doesn't conform to the norm and many (most?) drivers are missing mmiowb()s that are needed for Altix. Just no one has plugged most devices into an Altix (or haven't stressed the driver in a way that exposes problems of IO ordering between CPUs). It would be a great thing to use the powerpc trick of setting a flag that is tested by spin_unlock()/mutex_unlock() and automatically doing the mmiowb() if needed, and then killing off mmiowb() entirely. Yeah I think that's what Nick's guidelines would guarantee. And Jes is already working on the spin_unlock change you mentioned, so mmiowb() should be history soon (in name only, assuming Nick also introduces the I/O barriers he talked about for ordering the looser accessors it would still be there but would be called io_wmb or something). Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26-rc5-mm1: procfs whine
On Monday, June 09, 2008 1:48 am Andrew Morton wrote: At boot, using http://userweb.kernel.org/~akpm/config-g5.txt on a mac g5: io scheduler cfq registered proc_dir_entry '00' already registered Call Trace: [c0017a0fbb70] [c00120fc] .show_stack+0x58/0x1dc (unreliable) [c0017a0fbc20] [c01415a8] .proc_register+0x218/0x260 [c0017a0fbcd0] [c01419d4] .proc_mkdir_mode+0x40/0x74 [c0017a0fbd50] [c01e6640] .pci_proc_attach_device+0x90/0x134 [c0017a0fbdf0] [c05e5250] .pci_proc_init+0x68/0xa0 [c0017a0fbe70] [c05c0cd4] .kernel_init+0x228/0x49c [c0017a0fbf90] [c0026e0c] .kernel_thread+0x4c/0x68 nvidiafb: Device ID: 10de0141 Maybe something in the powerpc PCI init code changed recently? It looks like pci_bus_add_devices() is getting called more than once (or at least pci_bus_add_device() for this specific device). Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Friday, May 30, 2008 2:36 am Jes Sorensen wrote: James Bottomley wrote: The only way to guarantee ordering in the above setup, is to either make writel() fully ordered or adding the mmiowb()'s inbetween the two writel's. On Altix you have to go and read from the PCI brige to ensure all writes to it have been flushed, which is also what mmiowb() is doing. If writel() was to guarantee this ordering, it would make every writel() call extremely expensive :-( So if a read from the bridge achieves the same effect, can't we just put one after the writes within the spinlock (an unrelaxed one). That way this whole sequence will look like a well understood PCI posting flush rather than have to muck around with little understood (at least by most driver writers) io barriers? Hmmm, I think mmiowb() does some sort of status read from the bridge, I am not sure if it's enough to just do a regular readl(). I'm adding Jeremy to the list, he should know for sure. I think a read from the target host bridge is enough. What mmiowb() does though is to read a *local* host bridge register, which contains a count of the number of PIO ops still in flight on their way to their target bridge. When it reaches 0, all PIOs have arrived at the target host bridge (they still may be bufferd), so ordering is guaranteed. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Thursday, May 29, 2008 2:40 pm Benjamin Herrenschmidt wrote: On Thu, 2008-05-29 at 10:47 -0400, Jes Sorensen wrote: The only way to guarantee ordering in the above setup, is to either make writel() fully ordered or adding the mmiowb()'s inbetween the two writel's. On Altix you have to go and read from the PCI brige to ensure all writes to it have been flushed, which is also what mmiowb() is doing. If writel() was to guarantee this ordering, it would make every writel() call extremely expensive :-( Interesting. I've always been taught by ia64 people that mmiowb() was intended to be used solely between writel() and spin_unlock(). Well, that *was* true, afaik, but maybe these days multipath isn't just for fail-over. If that's true, then yeah making every single writeX ordered would be the only way to go... If this is a performance problem, then provide relaxed variants and use them in selected drivers. Sounds reasonable. That way drivers just work and important drivers can be optimized. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix rpadlpar pci hotplug driver sysfs usage
On Thursday, May 29, 2008 8:39 pm Benjamin Herrenschmidt wrote: When Greg fixed the sysfs usage of that driver a while back, he seem to have introduced a bug where the quotes are added around the name of our specific sysfs files, thus breaking the user space tool. This fixes it. Tested DLPAR operations on a POWER6 machine successfully. Do you think this is important enough for 2.6.26? Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
Move bridge enable from pcibios_enable_resources() to
platform_pci_enable_device() so the former matches other
architectures and can be shared.
I really like the direction of these patches. Getting PCI resources assigned
devices setup correctly for new arches has always been a bit more trouble
than it should be...
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: work6/arch/arm/kernel/bios32.c
===
--- work6.orig/arch/arm/kernel/bios32.c 2008-02-27 11:25:29.0
-0700
+++ work6/arch/arm/kernel/bios32.c2008-02-27 11:55:59.0 -0700
@@ -683,15 +683,32 @@
cmd |= PCI_COMMAND_MEMORY;
}
+ if (cmd != old_cmd) {
+ printk(PCI: enabling device %s (%04x - %04x)\n,
+pci_name(dev), old_cmd, cmd);
Probably worth giving this printk a prefix at some point (doesn't matter for
this patchset though since you're just moving it around).
Rest of it looks good.
Jesse
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] PARISC: move PERR SERR enables out of pcibios_enable_resources()
On Thursday, February 28, 2008 9:31 am Grant Grundler wrote: In general, I'm wondering if the check for device class would be sufficient here to NOT enable PERR/SERR for graphics automatically. While disabling PERR was the right thing for older mostly write devices of the 1990's and early 2000, it might not be correct for current 3-D graphics devices which use host mem to buffer processed results. I'm thinking of Intel graphics controllers in particular but I don't know any details of how they actually work. Well, in general chipset devices aren't required to support parity checking, AIUI; Intel gfx devices don't bother (PERR enable is hardwired to 0). I'm also a bit concerned about this now becuase (IIRC) AGP didn't implement parity though it looked like PCI protocol. PCI-e certainly does but it's possible BIOS/Firmware disable parity generation on the host bridge when connected to a gfx device. We wouldn't want to enable parity checking on a PCI-e gfx device in this case and I hope someone (perhaps at Intel) could double check this. I'd have to ping our BIOS folks to see if that's the case, but I doubt it. It would be a bad idea to disable any PCIe error reporting (including legacy error mapping) just because a gfx device was attached. Apparently the AMD PCIe parts include PERR generation, so disabling upstream reporting at boot time seems like it would be an outright bug; it should be left up to driver OS software. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
On Monday, March 03, 2008 12:35 pm Benjamin Herrenschmidt wrote: On Mon, 2008-03-03 at 09:59 -0800, Jesse Barnes wrote: On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote: Move bridge enable from pcibios_enable_resources() to platform_pci_enable_device() so the former matches other architectures and can be shared. I really like the direction of these patches. Getting PCI resources assigned devices setup correctly for new arches has always been a bit more trouble than it should be... You'll noticed that I recently moved powerpc to something more common to x86 in the are of resource allocation. Still -slightly- different but I do believe there is room for somebody with some skills to try to turn some of that into generic code. Yeah, I think that would be a good thing to shoot for. Even on PCs there are times when we need resource allocation to be done (or re-done) by the kernel for hotplug or just because the platform is pared down enough that it doesn't to it all by itself. I might be able to find time to look into that myself in the next few weeks; I think we even have some open PCI bugs that could be solved by better resource allocation. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
On Thursday, February 14, 2008 1:40 am Martin Mares wrote: Hi Greg! I have no idea, it sounds like a PPC specific thing, not anything the PCI core does, right? So I'll add the ppc list to the cc: and ask if anyone there has any ideas? Unfortunately, this is not PPC specific at all -- proc_attach_device() calls pci_proc_domain(bus), which is an arch-specific hook turning on the weird behavior I described. This hook can return non-zero even on x86 if there are buses outside domain 0. I think that the hook itself is correct, it only should trigger more consistent behavior of the generic code :) Would it be acceptable for the PPC folks to modify the code to add domain numbers to the device numbers in /proc/bus/pci/devices in the same format as the bus directories already have? If so, I will cook up a patch. I've run into this too, on machines with many domains. It's unfortunate that there's no way to preserve compatibility, but I agree that the brokenness may as well be consistent. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: wmb vs mmiowb
On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote: Of course, the normal memory barrier would usually be a spin_unlock() or something like that, not a wmb(). In fact, I don't think the powerpc implementation (as an example of this) will actually synchronize with anything *but* a spin_unlock(). We are even more sneaky in the sense that we set a per-cpu flag on any MMIO write and do the sync automatically in spin_unlock() :-) Yeah, that's a reasonable thing to do, and in fact I think there's code to do something similar when a task is switched out (this keeps user level drivers from having do mmiowb() type things). FWIW, I think I had an earlier version of the patch that used the name pioflush() or something similar, the only confusing thing about that name is that the primitive doesn't actually force I/Os down to the device level, just to the closest bridge. It'll be interesting to see if upcoming x86 designs share this problem (e.g. large HT or CSI topologies). Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: wmb vs mmiowb
Yeah, they keep threatening to use this instead, but I'm not sure how easy it would be. Also they may have more devices/drivers to worry about than sn2, so maybe changing over would mean too much driver debugging (well auditing really since it's not that hard to know where to put them). Irix actually had an io_unlock() routine that did this implicitly, but iirc that was shot down for Linux... Why was it shot down? Seems like a pretty good idea to me ;) Well, like Linus said, it had some significant downsides (though I think Irix had fewer lock types, so the multiplicative effect wasn't so bad there). I'm clueless when it comes to drivers, but I see a lot of mmiowb() that are not paired with spin_unlock. How are these obvious? (ie. what is the pattern?) It looks like some might be lockless FIFOs (or maybe I'm just not aware of where the locks are). Can you just quickly illustrate the problem being solved? Wow, it certainly has proliferated since it was added to the tree. :) I didn't audit all the uses, but it seems like many of them get it right, i.e. mmiowb() before spin_unlock() where PIO has been done. I'd have to look carefully to see whether lockless usages are correct, it's likely they're not. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: wmb vs mmiowb
On Wednesday, August 22, 2007 11:07 am Linus Torvalds wrote: It really seems like it is some completely different concept from a barrier. And it shows, on the platform where it really matters (sn2), where the thing actually spins. I agree that it probably isn't a write barrier per se. Think of it as a tie two subsystems together thing. Right, maybe it's not the best name, but as long as you separate your memory access types, you can think of it as a real write barrier, just for mmio accesses (well uncached access really). (And it doesn't just matter on sn2. It also matters on powerpc64, although I think they just set a flag and do the *real* sync in the spin_unlock() path). Yeah, they keep threatening to use this instead, but I'm not sure how easy it would be. Also they may have more devices/drivers to worry about than sn2, so maybe changing over would mean too much driver debugging (well auditing really since it's not that hard to know where to put them). Irix actually had an io_unlock() routine that did this implicitly, but iirc that was shot down for Linux... Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
