| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
If the PCI controller lacks the 'ranges' property nothing
is going to work.
Noticed by Al Viro.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PCI-E slot on T1000 connects directly to the Fire PCI chip with no
intervening bridges visible in the OBP tree.
Unfortunately the bus numbering of the device in that slot is
different (2) from the PCI host controller (0), and thus the
pci_bus_{read,write}_config_*() calls don't work out.
Complicating things further the Fire PCI controller has no config
space it responds to either.
For now treat this case specially so that devices in the slot work.
Longer term we need to perhaps cons up a dummy bridge between the Fire
and the PCI-E slot so that the bus hierarchy is complete inside of the
kernel and thus the bus numbering all works out right.
Signed-off-by: David 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: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
| |
In pci_determine_mem_io_space(), do not hard code the region sizes.
Instead, use the values given to us in the ranges property.
Thanks goes to Mikael Petterson for the original Xorg failure
bug repoert, and strace dumps from Mikael and Dmitry Artamonow.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
All the sun4u controllers do the same thing to compute the physical
I/O address to poke, and we can move the sun4v code into this common
location too.
This one needs a bit of testing, in particular the Sabre code had some
funny stuff that would break up u16 and/or u32 accesses into pieces
and I didn't think that was needed any more. If it is we need to find
out why and add back code to do it again.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
| |
Everything it contains can be hidden in pci_impl.h
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
| |
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
| |
Namely bus-range and ino-bitmap.
This allows us also to eliminate pci_controller_info's
pci_{first,last}_busno fields as only the pbm ones are
used now.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
| |
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
| |
It is only used in one spot and we can just fetch the
OF property right there.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
| |
It can be done for every PCI configuration using OF properties.
Signed-off-by: David 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: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
| |
Signed-off-by: Fabio Massimo Di Nitto <fabbione@ubuntu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For Hummingbird PCI controllers, we should create the root
PCI memory space resource as the full 4GB area, and then
allocate the IOMMU DMA translation window out of there.
The old code just assumed that the IOMMU DMA translation base
to the top of the 4GB area was unusable. This is not true on
many systems such as SB100 and SB150, where the IOMMU DMA
translation window sits at 0xc0000000->0xdfffffff.
So what would happen is that any device mapped by the firmware
at the top section 0xe0000000->0xffffffff would get remapped
by Linux somewhere else leading to all kinds of problems and
boot failures.
While we're here, report more cases of OBP resource assignment
conflicts. The only truly valid ones are ROM resource conflicts.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
| |
One thing this change pointed out was that we really should
pull the "get 'local-mac-address' property" logic into a helper
function all the network drivers can call.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
| |
Allow them to be enabled with "pci=irq_verbose" on the
boot command line.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
| |
It can be pushed even further down, but this is a first step.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
| |
this patch converts arch/sparc64 to kzalloc usage.
Crosscompile tested with allyesconfig.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
| |
If the top-level cnode had multi entries in it's "reg"
property, we'd fail. The buffer wasn't large enough in
such cases.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The whole algorithm was wrong. What we need to do is:
1) Walk each PCI bus above this device on the path to the
PCI controller nexus, and for each:
a) If interrupt-map exists, apply it, record IRQ controller node
b) Else, swivel interrupt number using PCI_SLOT(), use PCI bus
parent OBP node as controller node
c) Walk up to "controller node" until we hit the first PCI bus
in this domain, or "controller node" is the PCI controller
OBP node
2) If we walked to PCI controller OBP node, we're done.
3) Else, apply PCI controller interrupt-map to interrupt.
There is some stuff that needs to be checked out for ebus and
isa, but the PCI part is good to go.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
| |
When crawling up the PCI bus chain, stop at the first node
that has an interrupt-map property before we hit the root.
Also, if we use a bus interrupt-{map,mask} do not forget to
update the 'intmask' pointer as we do for the 'intmap' pointer.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
| |
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
| |
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
