Update of_find_i2c_driver in fsl_soc.c to display a warning message if an
I2C node in the device tree isn't found in the i2c_devices[] array.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch fixes few cosmetic issues, also removes unused function,
makes some functions static and reduces #ifdef count.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch enabled MSI on 8544ds and 8572ds board.
So far only one MSI interrupt can generate on 8544 board.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch enable the MSI on 8610hpcd board.
Through the msi-available-ranges property, All the 256
msi interrupts can be tested on this board.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were setup for this chip.
Before using the MSI interrupt, PCI/PCIE device need to
ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
bitmap show which MSI interrupt was used, reserve bit in
the bitmap can be used to force the device use some designate
MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
for testing the all the MSI interrupts. The msi-available-ranges
property in the dts file was used for this purpose.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Binding document adding for Freescale PCIe MSI support.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Work around:
arch/arm/mach-pxa/tosa.c: In function `tosa_poweroff':
arch/arm/mach-pxa/tosa.c:470: error: `GPIO_OUT' undeclared (first use in this function)
arch/arm/mach-pxa/tosa.c:470: error: (Each undeclared identifier is reported only once
arch/arm/mach-pxa/tosa.c:470: error: for each function it appears in.)
The proper fix exists in the PXA branch of my kernel git tree, which
will be pushed during the next merge window.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As nothing in the code references to the PXA_SHARPSL_25x/27x,
we can drop that Kconfig case and permit all-zaurus builds.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Combine cm_x270_defconfig and em_x270_defconfig to allow running the
same kernel on both machines
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Convert the 'choice' into a 'menu' to allow multiple platforms to be
selected.
This means to do a build check across PXA, you don't end up spending
a lifetime building _twenty_ sodding kernels.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Adjust zones for PCI DMA only if machine_is_armcore() to allow running
the same kernel on different PXA machines.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The power manager and core clock registers aren't present in PXA3
CPUs. Move them out of pxa-regs.h into pxa2xx-regs.h, and include
pxa2xx-regs.h where necessary.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This fixes a build error introduced when the power manager
register definitions were moved into pxa2xx-regs.h.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Adds support for the USB High Speed Device Port on the AT91SAM9RL
system on chip. The AT91SAM9RL uses the same UDPHS IP as the AVR32 and
the AT91CAP9 (atmel_usba_udc driver).
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Update the help text for RTC_DRV_AT91SAM9 to mention that the
option apply to AT91CAP9 processors too, and enable it in the
defconfig.
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This is patch 2 of 2 adding support for the USB High Speed Device Port
on the AT91CAP9 system on chip. The AT91CAP9 uses the same UDPHS IP
as the AVR32 and the AT91SAM9RL.
This patch declares the UDPHS ressources in the at91cap9 (cpu and
adk board) files, wires up the atmel_usba_udc driver to them,
and activates the driver in the defconfig.
Signed-off-by: Stelian Pop <stelian@popies.net>
Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This is patch 1 of 2 adding support for the USB High Speed Device Port
on the AT91CAP9 system on chip. The AT91CAP9 uses the same UDPHS IP
as the AVR32 and the AT91SAM9RL.
This patch makes the generic AT91 adaptations, mainly dealing with
the addition of the UDPHS UTMI clock.
Signed-off-by: Stelian Pop <stelian@popies.net>
Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Convert the following AT91RM9200-based boards to the new-style UART
initialization:
- Conitec ARM&EVA
- Atmel AT91RM9200-DK
- Embest ATEB9200
- Atmel AT91RM9200-EK
- KwikByte KB920x
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Default config files for the three AT91-based boards available from
Calao Systems: USB_A9260, USB_A9263 and QIL_A9260.
Signed-off-by: Grégory Hermant <gregory.hermant@calao-systems.com>
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for three AT91-based boards available from Calao Systems:
USB_A9260, USB_A9263 and QIL_A9260.
Signed-off-by: Grégory Hermant <gregory.hermant@calao-systems.com>
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cleanup the YL9200 board-support file.
Other things fixed are:
- Use new-style UART initialization
- Register all LEDs as gpio_leds.
- NOR Flash error noted in comments fixed by increasing YL9200_FLASH_SIZE
- The only I2C device is the AT24C eeprom.
- Setup of NWAIT pin and programming of SMC controller for the LCD/VGA.
- Configure touchscreen interrupt pin.
Also adding the board to the KConfig and Makefile.
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
standby.S contains both PXA2 and PXA3 specific code. The PXA3
specific constants clash with the PXA2 ones, so give them a prefix.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When a dynamically allocated platform device is 'put', the platform
device's platform_data is kfree'd. This is bad if it's pointing at
static data. Use the provided function to register platform data
for these devices.
This also means we can mark the pcmcia ops structures as __initdata.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
cm_x270 and mainstone both register their PCMCIA devices using the same
name, resulting in a warning message from the kernel. Avoid this by
making the cm_x270 and mainstone PCMCIA initialisation conditional on
the machine type we're running on.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Don't register the LPD270 cpld_irq system device when we're not running
on a LPD270 machine - "cpld_irq" is also registered (separately) by
Lubbock and Mainstone.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The current __raw_write_can_lock macro tests whether the lock can be
locked by checking if it is equal to 0x80000000, whereas the lock
should be lockable if its value is 0 i.e. unlocked state is
represented by 0. Hence the macro should test the value of lock
against 0 and not 0x80000000.
Signed-off-by: Surinder Pal Singh <srplsnh@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
PSKTSEL can be routed to GPIO pin 104. This configuration is used by
HP iPAQ hx4700.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Acked-by: Jrgen Schindele <linux@schindele.name>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Some additional alternate gpio definitions relating
to FFUART and USB on the pxa27x. These are used on
the xbow imote2 platform.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add the IORESOURCE_IRQ_HIGHEDGE to the DM9000 IRQ resource
to stop the driver itself complaining it was not given
any flags to use.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add the IORESOURCE_IRQ_HIGHEDGE to the DM9000 IRQ resource
to stop the driver itself complaining it was not given
any flags to use.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Follow suit from kprobe implementations on other archs and make kretprobe_trampoline non-static. Ftrace implmentation (more specifically, kernel/trace/trace.c) requires access to it (see-> http://kerneltrap.org/mailarchive/linux-kernel/2008/5/27/1955234).
Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Define recently added XEN_ELFNOTEs, and use them appropriately.
Most significantly, this enables domain checkpointing (xm save -c).
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
On resume, the vcpu timer modes will not be restored. The timer
infrastructure doesn't do this for us, since it assumes the cpus
are offline. We can just poke the other vcpus into the right mode
directly though.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
If we're using vcpu_info mapping, then make sure its restored on all
processors before relasing them from stop_machine.
The only complication is that if this fails, we can't continue because
we've already made assumptions that the mapping is available (baked in
calls to the _direct versions of the functions, for example).
Fortunately this can only happen with a 32-bit hypervisor, which may
possibly run out of mapping space. On a 64-bit hypervisor, this is a
non-issue.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
When operating on an unpinned pagetable (ie, one under construction or
destruction), it isn't necessary to use a hypercall to update a
pud/pmd entry. Jan Beulich observed that a similar optimisation
avoided many thousands of hypercalls while doing a kernel build.
One tricky part is that early in the kernel boot there's no page
structure, so we can't check to see if the page is pinned. In that
case, we just always use the hypercall.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
iommu/gart support misses suspend/resume code, which can do bad stuff,
including memory corruption on resume. Prevent system suspend in case we
would be unable to resume.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Tested-by: Patrick <ragamuffin@datacomm.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Update the UV address macros to better describe the
fields of UV physical addresses. Improve comments
in the header files. Add additional MMR definitions.
Signed-off-by: Jack Steiner <steiner@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
In dynamic ftrace, the mcount function starts off pointing to a stub
function that just returns.
On start up, the call to the stub is modified to point to a "record_ip"
function. The job of the record_ip function is to add the function to
a pre-allocated hash list. If the function is already there, it simply is
ignored, otherwise it is added to the list.
Later, a ftraced daemon wakes up and calls kstop_machine if any functions
have been recorded, and changes the calls to the recorded functions to
a simple nop. If no functions were recorded, the daemon goes back to sleep.
The daemon wakes up once a second to see if it needs to update any newly
recorded functions into nops. Usually it does not, but if a lot of code
has been executed for the first time in the kernel, the ftraced daemon
will call kstop_machine to update those into nops.
The problem currently is that there's no way to stop the daemon from doing
this, and it can cause unneeded latencies (800us which for some is bothersome).
This patch adds a new file /debugfs/tracing/ftraced_enabled. If the daemon
is active, reading this will return "enabled\n" and "disabled\n" when the
daemon is not running. To disable the daemon, the user can echo "0" or
"disable" into this file, and "1" or "enable" to re-enable the daemon.
Since the daemon is used to convert the functions into nops to increase
the performance of the system, I also added that anytime something is
written into the ftraced_enabled file, kstop_machine will run if there
are new functions that have been detected that need to be converted.
This way the user can disable the daemon but still be able to control the
conversion of the mcount calls to nops by simply,
"echo 0 > /debugfs/tracing/ftraced_enabled"
when they need to do more conversions.
To see the number of converted functions:
"cat /debugfs/tracing/dyn_ftrace_total_info"
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This breaks up the mutual inclusion between headers ptrace.h and vm86.h
by moving some small part of vm86.h which is needed by ptrace.h into
processor-flags.h.
We also try to move #include lines to the top.
This has been compile tested on x86_32 and x86_64 defconfig, and run
through 'make headers_check'.
Cc: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Tracing functions via ftrace which have a kretprobe installed on them, can produce misleading output in their trace logs. E.g, consider the correct trace of the following sequence:
do_IRQ()
{
~
irq_enter();
~
}
Trace log (sample):
<idle>-0 [00] 4154504455.781616: irq_enter <- do_IRQ
But if irq_enter() has a kretprobe installed on it, the return value stored on the stack at each invocation is modified to divert the return to a kprobe trampoline function called kretprobe_trampoline(). So with this the trace would (currently) look like:
<idle>-0 [00] 4154504455.781616: irq_enter <- kretprobe_trampoline
Now this is quite misleading to the end user, as it suggests something that didn't actually happen. So just to avoid such misinterpretations, the inlined patch aims to output such a log as:
<idle>-0 [00] 4154504455.781616: irq_enter <- [unknown/kretprobe'd]
Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The touch_nmi_watchdog() routine on x86 ultimately calls
touch_softlockup_watchdog(). The problem is that to touch the
softlockup watchdog, the cpu_clock code has to be called which could
involve multiple cpu locks and can lead to a hard hang if one of the
locks is held by a processor that is not going to return anytime soon
(such as could be the case with kgdb or perhaps even with some other
kind of exception).
This patch causes the public version of the
touch_softlockup_watchdog() to defer the cpu clock access to a later
point.
The test case for this problem is to use the following kernel config
options:
CONFIG_KGDB_TESTS=y
CONFIG_KGDB_TESTS_ON_BOOT=y
CONFIG_KGDB_TESTS_BOOT_STRING="V1F100I100000"
It should be noted that kgdb test suite and these options were not
available until 2.6.26-rc2, so it was necessary to patch the kgdb
test suite during the bisection.
I would consider this patch a regression fix because the problem first
appeared in commit 27ec440779 when some
logic was added to try to periodically sync the clocks. It was
possible to work around this particular problem by simply not
performing the sync anytime the system was in a critical context.
This was ok until commit 3e51f33fcc,
which added config option CONFIG_HAVE_UNSTABLE_SCHED_CLOCK and some
multi-cpu locks to sync the clocks. It became clear that accessing
this code from an nmi was the source of the lockups. Avoiding the
access to the low level clock code from an code inside the NMI
processing also fixed the problem with the 27ec44... commit.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
