Freescale UPM can be used to adjust localbus timings or to generate
orbitrary, pre-programmed "patterns" on the external Localbus signals.
This patch implements few routines so drivers could work with UPMs in
safe and generic manner.
So far there is just one user of these routines: Freescale UPM NAND
driver.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch adds support for the 256k L2 cache found on some IBM/AMCC
4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
which currently "only" adds the L2 cache init code. Other common 4xx
stuff can be added later here.
The L2 cache handling code is a copy of Eugene's code in arch/ppc
with small modifications.
Tested on AMCC Taishan 440GX.
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Rename commproc.[ch] to cpm1.[ch] to be more consistent with cpm2. Also
rename cpm2_common.c to cpm2.c as suggested by Scott Wood. Adjust the
includes accordingly.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch extends the Ebony and Walnut platform code to instantiate
the existing ds1742 RTC class driver for the DS1743 RTC/NVRAM chip
found on both those boards. The patch uses a helper function to scan
the device tree and instantiate the appropriate platform_device based
on it, so it should be easy to extend for other boards which have mmio
mapped RTC chips.
Along with this, the device tree binding for the ds1743 chips is
tweaked, based on the existing DS1385 OF binding found at:
http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-it.txt
Although that document covers the NVRAM portion of the chip, whereas
here we're interested in the RTC portion, so it's not entirely clear
if that's a good model.
This implements only RTC class driver support - that is /dev/rtc0, not
/dev/rtc, and the low-level get/set time callbacks remain
unimplemented. That means in order to get at the clock you will
either need a modified version of hwclock which will look at
/dev/rtc0, or you'll need to configure udev to symlink rtc0 to rtc.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Do just enough to move the RapidIO support code for 85xx over from arch/ppc
into arch/powerpc and make it still build.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This adds base support code for the 4xx PCI-X bridge. It also provides
placeholders for the PCI and PCI-E version but they aren't supported
with this patch.
The bridges are configured based on device-tree properties.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Implement MSI support for PA Semi PWRficient platforms. MSI is done
through a special range of sources on the openpic controller, and they're
unfortunately breaking the usual concepts of how sources are programmed:
* The source is calculated as 512 + the value written into the MSI
register
* The vector for this source is added to the source and reported
through IACK
This means that for simplicity, it makes much more sense to just set the
vector to 0 for the source, since that's really the vector we expect to
see from IACK.
Also, the affinity/priority registers will affect 16 sources at a
time. To avoid most (simple) users from being limited by this, allocate
16 sources per device but use only one. This means that there's a total
of 32 sources.
If we get usage scenarions that need more sources, the allocator should
probably be revised to take an alignment argument and size, not just do
natural alignment.
Finally, since I'm already touching the MPIC names on pasemi, rename
the base one from the somewhat odd " PAS-OPIC " to "PASEMI-OPIC".
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch adds support for the core of the BestComm API
for the Freescale MPC5200(b). The BestComm engine is a
microcode-controlled / tasks-based DMA used by several
of the onchip devices.
Setting up the tasks / memory allocation and all common
low level functions are handled by this patch.
The specifics details of each tasks and their microcode
are split-out in separate patches.
This is not the official API, but a much cleaner one.
(hopefully)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
dcr.c is an arch/powerpc only thing. Compiling ppc405 arch/ppc kernels
throws warnings without this change.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
With these functions implemented we cooperate better with the generic
timekeeping code. This obsoletes the need for the timer sysdev as a bonus.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Commit 69331af, "Fixes and cleanups for earlyprintk aka boot console",
resulted in printk output prior to the initialization of the mpsc
console driver not being printed. That commit causes the mpsc's
CON_PRINTBUFFER flag to be cleared since udbg should have printed
the previous output.
I guess we can no longer ignore udbg. :)
This patch provides udbg_putc() and udbg_getc() functions for the
Marvell mv64x60 chips. These functions are enabled if an mv64x60
port is to be used as the console as determined from the device tree.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Acked-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Move
arch/powerpc/platforms/86xx/pci.c -> arch/powerpc/sysdev/fsl_pci.c
arch/powerpc/sysdev/fsl_pcie.h -> arch/powerpc/sysdev/fsl_pci.h
as the base to unify 83xx/85xx/86xx pci and pcie.
Add CONFIG_FSL_PCI to build fsl_pci.c for Freescale pci and pcie option.
The code still works for 86xx platforms.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The Axon bridge chip used on new Cell/B.E. based blade servers
comes with a DDR2 memory controller that can be used to
attach cheap memory modules, as opposed to the high-speed
XDR memory that is used by the CPU itself.
Since the memory controller does not participate in the
cache coherency protocol, we can not use the memory direcly
for Linux applications, but by providing a block device
it can be used for swap space, temporary file storage and
through the use of the direct_access block device operation
for mapping into user addresses, when it is mounted with
an appropriate file system.
Signed-off-by: Maxim Shchetynin <maxim@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
In order to use the RTC CMOS driver, each architecture must register a
platform device for the RTC.
This creates a function to register the platform device based on the RTC
device node and verifies that the RTC port against the hard-coded value
in asm/mc146818rtc.h.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
There are times that we need to know which controller we are on to decide
how to exclude devices properly. We now pass the pci_controller that we
are going to use down to the pci_exclude_device function. This will
greatly simplify being able to exclude the PHBs in multiple controller
setups.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
With both generic rtc and powerpc timer suspend / resume code now in the
(powerpc.git) tree, powerpc platforms using the generic timer and enabling
power management will have timer.o linked in the kernel, which they don't
need. Moreover, it will likely WARN_ON(!ppc_md.get_rtc_time), save
zero-time and return no error on suspend...
As a possible solution we can choose not to build timer.o when RTC_CLASS
is enabled. However, I can imagine systems with 2 rtc's, one served by the
ppc-rtc, another one generic built as a module, in which case using the
ppc-rtc for suspend / resume will be impossible. Not to say, that such a
configuration would be ugly...
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch adds PCI bridge support for the Marvell mv64x60 chip.
We also provide the ability to read/write the mv64x60 hotswap
register via sysfs if the hs_reg_valid property is set in the
device tree.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch creates platform_device entries for the Marvell mv64x60
MPSC (multi-protocol serial controller) ports, based on information
contained in the device tree.
This driver (like the other mv64x60 drivers) are unusual in that it
works on both the MIPS and PowerPC architectures. Because of that,
the drivers do not support the normal PowerPC of_platform_bus_type.
They support platform_bus_type instead.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
There are 3 interrupt groups each with its own status/mask registers.
We use a separate struct irq_chip for each interrupt group and handle
interrupts in two stages or levels: level 1 selects the appropriate
struct irq_chip, and level 2 selects individual interrupts within
that irq_chip.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
powerpc_flash_init() implements a broken way of probing for flash
devices supported by the physmap_of driver. It finds all nodes in the
device tree with device_type=="rom" and instantiates of_platform
devices for them. This is fundamentally incompatible with the normal
and correct way of probing for of_platform_bus_probe(). Platforms
which relied on powerpc_flash_init()s behaviour (none are in-tree)
will have to update their platform probing code to correctly probe
busses containing flash devices.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
MPIC U3/U4 MSI backend. Based on code from Segher, heavily hacked by me.
This only deals with MSI on U3/U4 MPICs, aka. CPC 9x5.
If we find a U3/U4 then we enable this backend, ie. take over the ppc_md
MSI hooks. We might need more elaborate logic in future to decide which
backend is enabled.
We need our own irq_chip so that we can do MSI masking/unmasking on
the device itself. We also need to mask explicitly on shutdown to make
sure we don't get bitten by lazy-disable semantics.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
