This driver is now limited to just doing the basic clock board and FHC
chip initialization and registering the platform devices for the
per-board LEDs, which are driven by the new LEDS_STARFIRE driver.
The IRQ register handling is already confined purely to the device
tree code.
Signed-off-by: David S. Miller <davem@davemloft.net>
In order to make this week I also had to add an include
of linux/dma-mapping.h to asm/pci_32.h because drivers/pci/pci.c
really depends upon getting this header somehow.
Signed-off-by: David S. Miller <davem@davemloft.net>
The individual SBUS IOMMU arch code now sets the IOMMU information
directly into the OF device objects.
Signed-off-by: David S. Miller <davem@davemloft.net>
32-bit sparc just needed it to register the ioport procfs bits, do this
via an arch_initcall() instead.
Signed-off-by: David S. Miller <davem@davemloft.net>
This is in preparation for the subsequent asm/sbus.h removal.
Also, make these routines take a "struct device" or no
arguments, as appropriate.
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch removes the CVS keywords that weren't updated for a long time
from comments.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: David 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: David S. Miller <davem@davemloft.net>
We used to access the 64-bit IRQ IMAP and ICLR registers of bus
controllers 4-bytes in and as a 32-bit register word, since only the
low 32-bits were relevant. This seemed like a good idea at the time.
But the PCI-E controller requires full 8-byte 64-bit access to
these registers, so we switched over to accessing them fully.
SBUS was not adjusted properly, which broke interrupts completely.
Signed-off-by: David S. Miller <davem@davemloft.net>
Do not use IRQF_SHARED, these interrupt numbers should all
be unique.
Also use name strings without spaces in them just like
PCI controller drivers do, for consistency.
Signed-off-by: David S. Miller <davem@davemloft.net>
There are several IOMMU allocator bugs. Instead of trying to fix this
overly complicated code, just mirror the PCI IOMMU arena allocator
which is very stable and well stress tested.
I tried to make the code as identical as possible so we can switch
sun4u PCI and SBUS over to a common piece of IOMMU code. All that
will be need are two callbacks, one to do a full IOMMU flush and one
to do a streaming buffer flush.
This patch gets rid of a lot of hangs and mysterious crashes on SBUS
sparc64 systems, at least for me.
Signed-off-by: David S. Miller <davem@davemloft.net>
Totally unused.
We need to traverse the list of global IRQ translaters,
so storing it in the per-bus structures was useless.
Signed-off-by: David S. Miller <davem@davemloft.net>
I severely apologize, I was still learning how to program
in C when I wrote this stuff 10 years ago...
Signed-off-by: David S. Miller <davem@davemloft.net>
This is the long overdue conversion of sparc64 over to
the generic IRQ layer.
The kernel image is slightly larger, but the BSS is ~60K
smaller due to the reduced size of struct ino_bucket.
A lot of IRQ implementation details, including ino_bucket,
were moved out of asm-sparc64/irq.h and are now private to
arch/sparc64/kernel/irq.c, and most of the code in irq.c
totally disappeared.
One thing that's different at the moment is IRQ distribution,
we do it at enable_irq() time. If the cpu mask is ALL then
we round-robin using a global rotating cpu counter, else
we pick the first cpu in the mask to support single cpu
targetting. This is similar to what powerpc's XICS IRQ
support code does.
This works fine on my UP SB1000, and the SMP build goes
fine and runs on that machine, but lots of testing on
different setups is needed.
Signed-off-by: David S. Miller <davem@davemloft.net>