It is totally unnecessary as the needed information is properly
encoded in the resources.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On the root PCI bus, the OBP device tree lists device 3 twice.
Once as 'pm' and once as 'lomp'.

Everything goes downhill from there.

Ignore the second instance to workaround this.

Thanks to Kövedi_Krisztián for the bug report and
testing the fix.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

1) sun4{u,v}_build_msi() have improper return value handling.

   We should always return negative error codes, instead of
   using the magic value "0" which could in fact be a valid
   MSI number.

2) sun4{u,v}_build_msi() should return -ENOMEM instead of
   calling prom_prom() halt with kzalloc() of the interrupt
   data fails.

3) We 'remembered' the MSI number using a singleton in the
   struct device archdata area, this doesn't work for MSI-X
   which can cause multiple MSIs assosciated with one device.

   Delete that archdata member, and instead store the MSI
   number in the IRQ chip data area.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fully unify all of the DMA ops so that subordinate bus types to
the DMA operation providers (such as ebus, isa, of_device) can
work transparently.

Basically, we just make sure that for every system device we
create, the dev->archdata 'iommu' and 'stc' fields are filled
in.

Then we have two platform variants of the DMA ops, one for SUN4U which
actually programs the real hardware, and one for SUN4V which makes
hypervisor calls.

This also fixes the crashes in parport_pc on sparc64, reported by
Meelis Roos.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Don't provide fake PCI config space for sun4u.

Also, put back the funny host controller space handling that
at least Sabre needs.  You have to read PCI host controller
registers at their nature size otherwise you get zeros instead
of correct values.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This fixes the IDE controller not showing up on Netra-T1
systems.

Just like Simba bridges, some PCI bridges can lack the
'ranges' OBP property.  So we handle this similarly to
the existing Simba code:

1) In of_device register address resolving, we push the
   translation to the parent.

2) In PCI device scanning, we interrogate the PCI config
   space registers of the PCI bus device in order to resolve
   the resources, just like the generic Linux PCI probing
   code does.

With much help and testing from Fabio, who also reported
the initial problem.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NFabio Massimo Di Nitto <fabbione@ubuntu.com>

These messages were very useful when bringing up the
OBP based PCI device scan code, but it's just a lot
of noise every bootup now especially on big machines.

The messages can be re-enabled via 'ofpci_debug=1' on
the kernel command line.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Noticed by Meelis Roos.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Otherwise MSI explodes because pci_msi_init_pci_dev() does not
get invoked.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Everything it contains can be hidden in pci_impl.h
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The idea is to move more and more things into the pbm,
with the eventual goal of eliminating the pci_controller_info
entirely as there really isn't any need for it.

This stage of the transformations requires some reworking of
the PCI error interrupt handling.

It might be tricky to get rid of the pci_controller_info parenting for
a few reasons:

1) When we get an uncorrectable or correctable error we want
   to interrogate the IOMMU and streaming cache of both
   PBMs for error status.  These errors come from the UPA
   front-end which is shared between the two PBM PCI bus
   segments.

   Historically speaking this is why I choose the datastructure
   hierarchy of pci_controller_info-->pci_pbm_info

2) The probing does a portid/devhandle match to look for the
   'other' pbm, but this is entirely an artifact and can be
   eliminated trivially.

What we could do to solve #1 is to have a "buddy" pointer from one pbm
to another.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove includes of <linux/smp_lock.h> where it is not used/needed.
Suggested by Al Viro.

Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
sparc64, and arm (all 59 defconfigs).
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

apb_calc_first_last(), apb_fake_ranges(), pci_of_scan_bus(),
of_scan_pci_bridge(), pci_of_scan_bus(), and pci_scan_one_pbm()
should all be __devinit.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some minor refactoring in the generic code was necessary for
this:

1) This controller requires 8-byte access to the interrupt map
   and clear register.  They are 64-bits on all the other
   SBUS and PCI controllers anyways, so this was easy to cure.

2) The IMAP register has a different layout and some bits that we
   need to preserve, so use a read/modify/write when making
   changes to the IMAP register in generic code.

3) Flushing the entire IOMMU TLB is best done with a single write
   to a register on this PCI controller, add a iommu->iommu_flushinv
   for this.

Still lacks MSI support, that will come later.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

set_irq_msi() currently connects an irq_desc to an msi_desc. The archs call
it at some point in their setup routine, and then the generic code sets up the
reverse mapping from the msi_desc back to the irq.

set_irq_msi() should do both connections, making it the one and only call
required to connect an irq with it's MSI desc and vice versa.

The arch code MUST call set_irq_msi(), and it must do so only once it's sure
it's not going to fail the irq allocation.

Given that there's no need for the arch to return the irq anymore, the return
value from the arch setup routine just becomes 0 for success and anything else
for failure.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This helps deal with the invisible bridge that sits between
the host controller and the top-most visisble PCI devices
on hypervisor systems.

For example, on T1000 the bus-range property says 2 --> 4
and so there is a PCI express bridge at bus 2, devfn 0, etc.

So if we don't force the dummy host controller to bus zero,
we'll try to create two devices with the same domain/bus/devfn
triplet.

Also, add some more log diagnostics to make debugging stuff like this
easyer.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We fake up a dummy one in all cases because that is the simplest
thing to do and it happens to be necessary for hypervisor systems.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Based upon a similar patch for x86_64 written by
Stephen Hemminger.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We don't do the "Simba APB is a PBM" bogosity for Sabre
controllers any longer, so this pbms_same_domain thing
is no longer necessary.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All the implementations can be identical and generic, so
no need for controller specific methods.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The SIMBA APB bridge is strange, it is a PCI bridge but it lacks
some standard OF properties, in particular it lacks a 'ranges'
property.

What you have to do is read the IO and MEM range registers in
the APB bridge to determine the ranges handled by each bridge.
So fill in the bus resources by doing that.

Since we now handle this quirk in the generic PCI and OF device
probing layers, we can flat out eliminate all of that code from
the sabre pci controller driver.

In fact we can thus eliminate completely another quirk of the sabre
driver.  It tried to make the two APB bridges look like PBMs but that
makes zero sense now (and it's questionable whether it ever made sense).
So now just use pbm_A and probe the whole PCI hierarchy using that as
the root.

This simplification allows many future cleanups to occur.

Also, I've found yet another quirk that needs to be worked around
while testing this.  You can't use the 'class-code' OF firmware
property, especially for IDE controllers.  We have to read the value
out of PCI config space or else we'll see the value the device was
showing before it was programmed into native mode.

I'm starting to think it might be wise to just read all of the values
out of PCI config space instead of using the OF properties. :-/
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Need to traverse recursively down child busses else we only
get the file created under devices at the top-level.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The only user was bus_dvma_to_mem() which is no longer used
by any driver, so kill that, and the export of pci_memspace_mask.

The only user now is the PCI mmap support code.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Almost entirely taken from the 64-bit PowerPC PCI code.

This allowed to eliminate a ton of cruft from the sparc64
PCI layer.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix section mismatch in arch/sparc/kernel/pcic.c and 
arch/sparc64/kernel/pci.c.
Signed-off-by: NRobert Reif <reif@earthlink.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Need to use get_irq_msi() not get_irq_data().
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is kind of hokey, we could use the hardware provided facilities
much better.

MSIs are assosciated with MSI Queues.  MSI Queues generate interrupts
when any MSI assosciated with it is signalled.  This suggests a
two-tiered IRQ dispatch scheme:

	MSI Queue interrupt --> queue interrupt handler
		MSI dispatch --> driver interrupt handler

But we just get one-level under Linux currently.  What I'd like to do
is possibly stick the IRQ actions into a per-MSI-Queue data structure,
and dispatch them form there, but the generic IRQ layer doesn't
provide a way to do that right now.

So, the current kludge is to "ACK" the interrupt by processing the
MSI Queue data structures and ACK'ing them, then we run the actual
handler like normal.

We are wasting a lot of useful information, for example the MSI data
and address are provided with ever MSI, as well as a system tick if
available.  If we could pass this into the IRQ handler it could help
with certain things, in particular for PCI-Express error messages.

The MSI entries on sparc64 also tell you exactly which bus/device/fn
sent the MSI, which would be great for error handling when no
registered IRQ handler can service the interrupt.

We override the disable/enable IRQ chip methods in sun4v_msi, so we
have to call {mask,unmask}_msi_irq() directly from there.  This is
another ugly wart.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The setting of the CACHE_LINE_SIZE register in sparc64's pci
initialisation code isn't quite adequate as the device may have
incompatible requirements.  The generic code tests for this, so switch
sparc64 over to using it.

Since sparc64 has different L1 cache line size and PCI cache line size,
it would need to override the generic code like i386 and ia64 do.  We
know what the cache line size is at compile time though, so introduce a
new optional constant PCI_CACHE_LINE_BYTES.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NDavid Miller <davem@davemloft.net>
Acked-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Do IRQ determination generically by parsing the PROM properties,
and using IRQ controller drivers for final resolution.

One immediate positive effect is that all of the IRQ frobbing
in the EBUS, ISA, and PCI controller layers has been eliminated.
We just look up the of_device and use the properly computed
value.

The PCI controller irq_build() routines are gone and no longer
used.  Unfortunately sbus_build_irq() has to remain as there is
a direct reference to this in the sunzilog driver.  That can be
killed off once the sparc32 side of this is written and the
sunzilog driver is transformed into an "of" bus driver.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Based on a patch series originally from Vivek Goyal <vgoyal@in.ibm.com>

Cc: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Allow them to be enabled with "pci=irq_verbose" on the
boot command line.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>