ARM Versatile PCI config reads of one byte width have the lowest two
bits of the address cleared and result in reading from a wrong place
in the config space. This change is to use word size accesses like it is done for halfword reads.
Byte reads are used for retrieving the IRQ number of a PCI device and the problem was not exposed until 2.6.20 because the value read was discarded in drivers/pci/setup-irq.c (recently fixed).
Signed-off-by: Andrzej Zaborowski <andrew@openedhand.com>
Acked-by: Paul Brook <paul@codesourcery.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Uninline virq_to_hw and export it so modules can use it. The alternative
would be to export the irq_map array instead, but it's an infrequently
called function, and keeping the array unexported seems considerably
cleaner.
This is needed so that the pasemi_mac driver can be compiled as a module.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The recent change to cell_defconfig to enable cpufreq on Cell exposed
the fact that the cbe_cpufreq driver currently needs the PMI interface
code to compile, but Kconfig doesn't make sure that the PMI interface
code gets built if cbe_cpufreq is enabled.
In fact cbe_cpufreq can work without PMI, so this ifdefs out the code
that deals with PMI. This is a minimal solution for 2.6.22; a more
comprehensive solution will be merged for 2.6.23.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Commit 52ade9b3b9 changed the suspend code
ordering to execute pm_ops->prepare() after the device model per-device
.suspend() calls in order to fix some ACPI-related issues. Unfortunately, it
broke the at91 platform which assumed that pm_ops->prepare() would be called
before suspending devices.
at91 used pm_ops->prepare() to get notified of the target system sleep state,
so that it could use this information while suspending devices. However, with
the current suspend code ordering pm_ops->prepare() is called too late for
this purpose. Thus, at91 needs an additional method in 'struct pm_ops' that
will be used for notifying the platform of the target system sleep state.
Moreover, in the future such a method will also be needed by ACPI.
This patch adds the .set_target() method to 'struct pm_ops' and makes the
suspend code call it, if implemented, before executing the device model
per-device .suspend() calls. It also modifies the at91 code to use
pm_ops->set_target() instead of pm_ops->prepare().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 9215da3320 "fixed" the MTRR range
check to not allow any MTRR's under the 1MB mark (since that's where the
fixed MTRR's are active).
However, that was totally bogus, since it's normal (and almost required)
to have a large variable MTRR that starts at 0, and covers some large
percentage of the whole RAM, and then using the fixed MTRR's to override
that large MTRR to handle the special ISA hole in the 640k-1M region.
The old check was bogus too (checking that no variable MTRR is used that
is entirely under the 1MB range), but at least it wasn't actively
detrimental, because no sane situation would ever trigger such MTRR
usage in the first place.
That said, the whole notion of not allowing variable MTRR's in the low
1MB is just stupid, so rather than revert the commit, this just removes
the whole sad and unnecessary check entirely.
Cc: Jan Beulich <jbeulich@novell.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Luca Palermo <darkmage@sabayonlinux.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC64]: Add linux/pagemap.h to asm/tlb.h
[SPARC64]: Need to set state to IDLE during sun4v IRQ enable.
[SPARC64]: Fix VIRQ enabling.
[SPARC64]: Add irqs to mdesc_node.
The vdso64 portion of patch 74609f4536 for
fixing problems with NULL gettimeofday input mistakenly checks for a
null tz field twice, when it should be checking for null tz once, and
null tv once; by way of a r10/r11 typo.
Any application calling gettimeofday(&tv,NULL) will "fail".
This corrects that typo, and makes my G5 happy.
Tested on G5.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Cc: Tony Breeds <tony@bakeyournoodle.com>
Forwarded-by: Ben Herrenschmidt <benh@kernel.crashing.org>
[ Ben says: "I checked the 32 bits part of the change is correct. You
can probably blame me for originally writing the 2 versions with
inversed usage of r10 and r11, thus confusing Tony :-)"
Ben duly blamed. - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use the ppc64 style list management and allocation functions for
pci_controllers. This makes the pci_controller structs just a bit more
common between ppc32 & ppc64.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Moved the low hanging fruit that was either identical or close
to it between ppc32 & ppc64 for PCI into pci-common.c
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
In the places we can move to using pci_bus_to_host, this allows us
to make pci_bus_to_host static and remove its export.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Make the ppc32 pcibios_alloc_controller take a device node to match
the ppc64 prototypes and have it set arch_data.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Make the pci_controller struct use global_number for the PHB domain number
instead of index to match what ppc64 does and reuse its pci_domain_nr code.
Introduced a pci-common.c to handle shared code between ppc32 & ppc64.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
There are no in kernel users of any off these functions and some of
them were not even EXPORT_SYMBOL:
- pci_bus_io_base()
- pci_bus_io_base_phys()
- pci_bus_mem_base_phys()
- pci_resource_to_bus()
- phys_to_bus()
- pci_phys_to_bus()
- pci_bus_to_phys()
- pci_init_resource()
- resource_fixup()
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The Freescale PCI-e RC poses as a transparent bridge, but does not
implement the IO_BASE or IO_LIMIT registers in the config space. This
means that the code which initializes the bridge resources ends up
setting the IO resources erroneously. Add quick_fsl_pcie_transparent()
to handle this.
This change sets RC of mpc8641 to be a transparent bridge
for legacy I/O access and initializes the RC bridge resources
from the device tree.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
In pcibios_fixup_bus(), bridges that are subordinate
to transparent bridges were still relocating their
IORESOURCE_IO and IO_RESOURCE_MEM start and end values.
Fix this by preventing the transparent bridge from
relocating the start and end values, thus allowing the
subordinate non-transparent bridge full molestation rights.
Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Set IDE in ULI1575 to not 100% native mode, which forces
the IDE driver to probe the irq itself.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The Freescale PCI-e controllers have an issue in that they use the
PCI_PRIMARY_BUS register in the virtual P2P bridge to determine which
bus number to match on when generating a type 0 config cycle. The
issue is if we are renumbering bus numbers to match Linux we will try
setting the PCI_PRIMARY_BUS and will not know which bus number to use
for generating type 0 config cycles. We surpress writing the register
in the P2P bridge and always keep it at zero.
In the future when proper PCI domain support is working we should be
able to remove this.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The generic PCI config ops indirect support for ppc32 covers only two
cases (implicit vs explicit) type 0/1 config cycles via set_cfg_type.
Added a indirect_type bit mask to handle other variants.
Added support for PCI-e extended registers and moved the cfg_type
handling into the bit mask for ARCH=powerpc. We can also use this to
handle indirect quirks.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This adds device nodes for the PCI bridges as well as the ISA devices on
the newer revision MPC8641HPCN. It also adds the PCI ranges to the soc
node so that address translation for the ISA devices works properly.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Removed the remants of bus_offset and use self_busno in the mv64x60 case
and use pci_assign_all_buses on 83xx/85xx.
83xx/85xx have multiple PHBs and the firmwares on these devices tend not
to handle topologies with P2P bridges well so we let Linux just reassign
the bus numbers to match.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Added self_busno to pci_controller and indirect PCI ops to be set by
board code to indicate which bus number to use when talking to the PHB.
By default we use zero since the majority of controllers that have
implicit mechanisms to talk to the PHBs use a bus number of zero.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The user of the fsl_pcie code doesn't set bus_offset and 82xx doesn't
require it either. Remove the places in the code that reference it so
we can remove it all together.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Now that we have the pci_controller in the exclude function we can easy
figure out if the bus number is the PHB or not. The old style of using a
variable setup at init time was actually broken and would only work in
specific cases.
Signed-off-by: Kumar Gala <galak@kernel.crashing.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>
The hose->bus_offset is only used for PCI config cycles and the 52xx PCI
config code doesn't actually ever set bus_offset to a non-zero value.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The Freescale and Marvell PCI controllers dont require explicit setting for
type 1 config cycles. They handle producing them by implicitly looking at the
bus, devfn.
The TSI108 and 52xx don't use the generic PCI indirect code and thus don't
bother with set_cfg_type.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The TSI108 code and the 32 bit powermac and chrp platforms
have dependency on PCI that is not easy or desirable to get rid
of.
The easiest fix is to always select CONFIG_PCI if one of those
platforms is enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When CONFIG_PCI is disabled, the definitions for isa_io_base,
isa_mem_base and pci_dram_offset are entirely unused, but they
can result in link failure because they are defined in multiple
places.
The easiest fix is to just remove all these definitions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Many platforms currently define their own add_bridge function, some
of them globally. This breaks some multiplatform configurations.
Prefixing each of these functions with the platform name avoids
this problem.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The cores used in the MPC82xx/83xx/86xx embedded controllers are very similar
to those in the 32 bit general-purpose processors, so it makes sense to
treat them as the same CPU family.
Choosing between the embedded platforms and the multiplatform code is
now done in the platform menu, but functionally everything stays the
same.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Not all the world is an i386. Many architectures need 64-bit arguments to be
aligned in suitable pairs of registers, and the original
sys_sync_file_range(int, loff_t, loff_t, int) was therefore wasting an
argument register for padding after the first integer. Since we don't
normally have more than 6 arguments for system calls, that left no room for
the final argument on some architectures.
Fix this by introducing sys_sync_file_range2(int, int, loff_t, loff_t) which
all fits nicely. In fact, ARM already had that, but called it
sys_arm_sync_file_range. Move it to fs/sync.c and rename it, then implement
the needed compatibility routine. And stop the missing syscall check from
bitching about the absence of sys_sync_file_range() if we've implemented
sys_sync_file_range2() instead.
Tested on PPC32 and with 32-bit and 64-bit userspace on PPC64.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
asm-powerpc/processor.h declares, and arch/ppc/platforms/prep_setup.c
defines variables ucBoardRev, ucBoardRevMaj and ucBoardRevMin which
are used nowhere in the current kernel (neither in arch/ppc nor
arch/powerpc). This removes them.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Commit 2e60161337 split up
arch/powerpc/boot/of.c so that some OF functions can be used on
platforms that don't want to use the overall OF platform boot code.
This is useful on things like PReP which can have an OF implementation
which is useful for debugging output, but inadequate for booting.
However, that commit didn't export quite enough things to make a
usable OF console on a non-OF system. In particular, the device tree
manipulation performed to initialize the OF console code must
explicitly use the OF device tree, rather than the flattened device
tree, even if the system is otherwise booting using a flattened device
tree. This makes it so.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Commit 3d5134ee83 left debugging turned on
in arch/powerpc/kernel/pci_64.c. This turns it off again.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Currently iSeries will recalibrate the cputime_factors in the first
settimeofday() call.
It seems the reason for doing this is to ensure a resaonable time delta after
time_init(). On current kernels (with udev), this call is made 40-60 seconds
into the boot process, by moving it to a late initcall it is called
approximately 5 seconds after time_init() is called. This is sufficient to
recalibrate the timebase.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
CC: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
