This patch adds OF initialization support for the FIMC driver.
The binding documentation can be found at Documentation/devicetree/
bindings/media/samsung-fimc.txt.
The syscon regmap interface is used to serialize access to the
shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
FIMC drivers. The DRM driver uses this interface for setting up
the FIFO data link between FIMD and FIMC IP blocks, while the V4L2
one for setting up a data link between the camera ISP and FIMC for
camera capture. The CAMBLK registers are not accessed any more
through a statically mapped IO. Synchronized access to these
registers is required for simultaneous operation of the camera
ISP and the DRM IPP on Exynos4x12.
The driver data and driver_ids static data structures are removed
since Exynos4 is going to be a dt-only platform and there is
currently no board file in mainline that defines platform data
for the FIMC IPP, i.e. uses it.
Camera input signal polarities are not currently parsed from the
device tree.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The clocks handling is refactored and a "mux" clock handling is
added to account for changes in the clocks driver. After switching
to the common clock framework the sclk_fimc clock is now split
into two clocks: a gate and a mux clock. In order to retain the
exisiting functionality two additional consumer clocks are passed
to the driver from device tree: "mux" and "parent". Then the driver
sets "parent" clock as a parent clock of the "mux" clock. These two
additional clocks are optional, and should go away when there is a
standard way of setting up parent clocks on DT platforms.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
There is no need for explicit calls of devm_kfree(), as
the allocated memory will be freed during driver's detach.
Remove the redundant devm_kfree() calls from probe() and
remove() callbacks.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Common Clock Framework introduced the need to prepare clocks before
enabling them, otherwise clk_enable() fails. This patch adds clk_prepare_enable
and clk_disable_unprepare() calls to the driver.
This patch also removes clk_disable() from fimd_remove() as it will be done
by pm_runtime_put_sync.
Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
kvm_target_cpus() checks the compatibility of the used CPU with
KVM, which is currently limited to ARM Cortex-A15 cores.
However by calling it only once on any random CPU it assumes that
all cores are the same, which is not necessarily the case (for example
in Big.Little).
[ I cut some of the commit message and changed the formatting of the
code slightly to pass checkpatch and look more like the rest of the
kvm/arm init code - Christoffer ]
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
The CONFIG_KVM_ARM_MAX_VCPUS symbol is needed in order to build the
kernel/context_tracking.c code, which includes the vgic data structures
implictly through the kvm headers. Definining the symbol to zero
on builds without KVM resolves this build error:
In file included from include/linux/kvm_host.h:33:0,
from kernel/context_tracking.c:18:
arch/arm/include/asm/kvm_host.h:28:23: warning: "CONFIG_KVM_ARM_MAX_VCPUS" is not defined [-Wundef]
#define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
^
arch/arm/include/asm/kvm_vgic.h:34:24: note: in expansion of macro 'KVM_MAX_VCPUS'
#define VGIC_MAX_CPUS KVM_MAX_VCPUS
^
arch/arm/include/asm/kvm_vgic.h:38:6: note: in expansion of macro 'VGIC_MAX_CPUS'
#if (VGIC_MAX_CPUS > 8)
^
In file included from arch/arm/include/asm/kvm_host.h:41:0,
from include/linux/kvm_host.h:33,
from kernel/context_tracking.c:18:
arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
} percpu[VGIC_MAX_CPUS];
^
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <cdall@cs.columbia.edu>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
Unless I'm mistaken, the size field was encoded 4 bits off and a wrong
value was used for 64-bit FP registers.
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
We use the vfp_host pointer to store the host VFP context, should
the guest start using VFP itself.
Actually, we can use this pointer in a more generic way to store
CPU speficic data, and arm64 is using it to dump the whole host
state before switching to the guest.
Simply rename the vfp_host field to host_cpu_context, and the
corresponding type to kvm_cpu_context_t. No change in functionnality.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
Most of the capabilities are common to both arm and arm64, but
we still need to handle the exceptions.
Introduce kvm_arch_dev_ioctl_check_extension, which both architectures
implement (in the 32bit case, it just returns 0).
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
Now that we have the necessary infrastructure to boot a hotplugged CPU
at any point in time, wire a CPU notifier that will perform the HYP
init for the incoming CPU.
Note that this depends on the platform code and/or firmware to boot the
incoming CPU with HYP mode enabled and return to the kernel by following
the normal boot path (HYP stub installed).
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
runtime mappings, as pages are manipulated from PL1 exclusively
The hotplug problem mandates that we keep two sets of page tables
(boot and runtime). The TLB problem mandates that we're able to
transition from one PGD to another while in HYP, invalidating the TLBs
in the process.
To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All we
need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel text
The vectors page seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical memory,
it is unlikely to use the last 64kB (I doubt we'll ever support KVM
on a system with something like 4MB of RAM, but patches are very
welcome).
Let's call this VA the trampoline VA.
Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd
The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the same
physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).
Note that we keep the boot mapping permanently (it is not strictly an
idmap anymore) to allow for CPU hotplug in later patches.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
There is no point in freeing HYP page tables differently from Stage-2.
They now have the same requirements, and should be dealt with the same way.
Promote unmap_stage2_range to be The One True Way, and get rid of a number
of nasty bugs in the process (good thing we never actually called free_hyp_pmds
before...).
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
We're about to move to an init procedure where we rely on the
fact that the init code fits in a single page. Make sure we
align the idmap text on a vector alignment, and that the code is
not bigger than a single page.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
After the HYP page table rework, it is pretty easy to let the KVM
code provide its own idmap, rather than expecting the kernel to
provide it. It takes actually less code to do so.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
The current code for creating HYP mapping doesn't like to wrap
around zero, which prevents from mapping anything into the last
page of the virtual address space.
It doesn't take much effort to remove this limitation, making
the code more consistent with the rest of the kernel in the process.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
The way we populate HYP mappings is a bit convoluted, to say the least.
Passing a pointer around to keep track of the current PFN is quite
odd, and we end-up having two different PTE accessors for no good
reason.
Simplify the whole thing by unifying the two PTE accessors, passing
a pgprot_t around, and moving the various validity checks to the
upper layers.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
In clocksource/arm_arch_timer.h we define useful symbolic constants.
Let's use them to make the KVM arch_timer code clearer.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <cdall@cs.columbia.edu>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
In order to be able to correctly profile what is happening on the
host, we need to be able to identify when we're running on the guest,
and log these events differently.
Perf offers a simple way to register callbacks into KVM. Mimic what
x86 does and enjoy being able to profile your KVM host.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
Due to MQ support we may allocate a whole bunch of rx queues but
never use them. With this patch we'll safe the space used by
the receive buffers until they are actually in use:
sh-4.2# free -h
total used free shared buffers cached
Mem: 490M 35M 455M 0B 0B 4.1M
-/+ buffers/cache: 31M 459M
Swap: 0B 0B 0B
sh-4.2# ethtool -L eth0 combined 8
sh-4.2# free -h
total used free shared buffers cached
Mem: 490M 162M 327M 0B 0B 4.1M
-/+ buffers/cache: 158M 331M
Swap: 0B 0B 0B
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We call lock_page when we need to update a page after readpage.
Between grab and lock page, the page can be truncated by other thread.
So, we should check the page after lock_page whether it was truncated or not.
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
In order to avoid build_free_nid lock contention, let's change the order of
function calls as follows.
At first, check whether there is enough free nids.
- If available, just get a free nid with spin_lock without any overhead.
- Otherwise, conduct build_free_nids.
: scan nat pages, journal nat entries, and nat cache entries.
We should consider carefullly not to serve free nids intermediately made by
build_free_nids.
We can get stable free nids only after build_free_nids is done.
Reviewed-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Commit a4b6a77b77 ("module: fix symbol
versioning with symbol prefixes") broke the MODVERSIONS loading of any
module using memcmp (e.g. ipv6) on x86_32, as it's defined to
__builtin_memcmp which is expanded by VMLINUX_SYMBOL_STR. Use
__VMLINUX_SYMBOL_STR instead which doesn't expand the argument.
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: <stable@vger.kernel.org> # 3.9
This can help when debugging the free nid allocation flows.
Reviewed-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
This patch enables the initial Timer on coldfire 532x systems.
Without this, the scheduler will not be triggered and the system hangs,
after all sequential code is executed. It should also apply on later kernel
versions.
Signed-off-by: Christian Gieseler <christiangieseler@yahoo.de>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Add a configuration switch for supporting the Freescale M5373EVB board.
It is based on the newly added ColdFire 537x CPU support.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 537x family is very similar internally to the ColdFire 532x
family. So with just a little extra configuration we can configure and
target them as well.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The M532x CPU platform support can be used on more ColdFire CPU families
than just the 532x types. So rename and reconfigure it to reflect that.
The ColdFire 537x family has virtualy identical internals to the 532x,
and so it will be able to share this code when we add support for them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The current CONFIG_M532x support definitions are actually common to a larger
set of version 3 ColdFire CPU types. In the future we want to add support for
the 537x family. It is very similar to the 532x internally, and will be able
to use most of the same definitions.
Create a CONFIG_M53xx option that is enabled to support any of the common
532x and 537x CPU types. Convert the current users of CONFIG_M532x to use
CONFIG_M53xx instead.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The contents of the m68k asm/dbg.h are never used, remove the file and
remove the one reference to it.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
For coldfire with MMU enabled, data cache did not follow the configuration but
was configured in writethrough mode.
Signed-off-by: Stany MARCEL <stany.marcel@novasys-ingenierie.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Checks introduced in commit 4991e7251 ("romfs: do not use
mtd->get_unmapped_area directly") re-introduce problems fixed in the earlier
commit 2b4b2482e ("romfs: fix romfs_get_unmapped_area() argument check").
If a flat binary app is located at the end of a romfs, its page aligned
length may be outside of the romfs filesystem. The flat binary loader, via
nommu do_mmap_pgoff(), page aligns the length it is mmaping. So simple
offset+size checks will fail - returning EINVAL.
We can truncate the length to keep it inside the romfs filesystem, and that
also keeps the call to mtd_get_unmapped_area() happy.
Are there any side effects to truncating the size here though?
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Kconfig symbol ROMVECSIZE is unused since commit
f84f52a5c1 ("m68knommu: clean up linker
script"). Let's clean up its Kconfig entry too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Merge in the clksrc/cleanup branch to avoid a silly merge conflict. For
some reason two versions of the same patch were merged in two
branches. Resolve this here to avoid merge conflicts down the road,
since it can be confusing to tell which version is the one to keep.
* clksrc/cleanup:
clocksource: make CLOCKSOURCE_OF_DECLARE type safe
Signed-off-by: Olof Johansson <olof@lixom.net>
Conflicts:
include/linux/clocksource.h
Commit 5800043 (cpufreq: convert cpufreq_driver to using RCU) causes
the following call trace to be spit on boot:
BUG: sleeping function called from invalid context at /scratch/rafael/work/linux-pm/mm/slab.c:3179
in_atomic(): 0, irqs_disabled(): 0, pid: 292, name: systemd-udevd
2 locks held by systemd-udevd/292:
#0: (subsys mutex){+.+.+.}, at: [<ffffffff8146851a>] subsys_interface_register+0x4a/0xe0
#1: (rcu_read_lock){.+.+.+}, at: [<ffffffff81538210>] cpufreq_add_dev_interface+0x60/0x5e0
Pid: 292, comm: systemd-udevd Not tainted 3.9.0-rc8+ #323
Call Trace:
[<ffffffff81072c90>] __might_sleep+0x140/0x1f0
[<ffffffff811581c2>] kmem_cache_alloc+0x42/0x2b0
[<ffffffff811e7179>] sysfs_new_dirent+0x59/0x130
[<ffffffff811e63cb>] sysfs_add_file_mode+0x6b/0x110
[<ffffffff81538210>] ? cpufreq_add_dev_interface+0x60/0x5e0
[<ffffffff810a3254>] ? __lock_is_held+0x54/0x80
[<ffffffff811e647d>] sysfs_add_file+0xd/0x10
[<ffffffff811e6541>] sysfs_create_file+0x21/0x30
[<ffffffff81538280>] cpufreq_add_dev_interface+0xd0/0x5e0
[<ffffffff81538210>] ? cpufreq_add_dev_interface+0x60/0x5e0
[<ffffffffa000337f>] ? acpi_processor_get_platform_limit+0x32/0xbb [processor]
[<ffffffffa022f540>] ? do_drv_write+0x70/0x70 [acpi_cpufreq]
[<ffffffff810a3254>] ? __lock_is_held+0x54/0x80
[<ffffffff8106c97e>] ? up_read+0x1e/0x40
[<ffffffff8106e632>] ? __blocking_notifier_call_chain+0x72/0xc0
[<ffffffff81538dbd>] cpufreq_add_dev+0x62d/0xae0
[<ffffffff815389b8>] ? cpufreq_add_dev+0x228/0xae0
[<ffffffff81468569>] subsys_interface_register+0x99/0xe0
[<ffffffffa014d000>] ? 0xffffffffa014cfff
[<ffffffff81535d5d>] cpufreq_register_driver+0x9d/0x200
[<ffffffffa014d000>] ? 0xffffffffa014cfff
[<ffffffffa014d0e9>] acpi_cpufreq_init+0xe9/0x1000 [acpi_cpufreq]
[<ffffffff810002fa>] do_one_initcall+0x11a/0x170
[<ffffffff810b4b87>] load_module+0x1cf7/0x2920
[<ffffffff81322580>] ? ddebug_proc_open+0xb0/0xb0
[<ffffffff816baee0>] ? retint_restore_args+0xe/0xe
[<ffffffff810b5887>] sys_init_module+0xd7/0x120
[<ffffffff816bb6d2>] system_call_fastpath+0x16/0x1b
which is quite obvious, because that commit put (multiple instances
of) sysfs_create_file() under rcu_read_lock()/rcu_read_unlock(),
although sysfs_create_file() may cause memory to be allocated with
GFP_KERNEL and that may sleep, which is not permitted in RCU read
critical section.
Revert the buggy commit altogether along with some changes on top
of it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge in the gic cleanup since it has a handful of annoying internal conflicts
with soc development branches. All of them are delete/delete conflicts.
* gic/cleanup:
irqchip: vic: add include of linux/irq.h
irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
irqchip: gic: Call handle_bad_irq() directly
arm: Move chained_irq_(enter|exit) to a generic file
arm: Move the set_handle_irq and handle_arch_irq declarations to asm/irq.h
Signed-off-by: Olof Johansson <olof@lixom.net>
Conflicts:
arch/arm/mach-shmobile/smp-emev2.c
arch/arm/mach-shmobile/smp-r8a7779.c
arch/arm/mach-shmobile/smp-sh73a0.c
arch/arm/mach-socfpga/platsmp.c
Merging in fixes since there's a conflict in the omap4 clock tables caused by
it.
* fixes: (245 commits)
ARM: highbank: fix cache flush ordering for cpu hotplug
ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock
arm: mvebu: Fix the irq map function in SMP mode
Fix GE0/GE1 init on ix2-200 as GE0 has no PHY
ARM: S3C24XX: Fix interrupt pending register offset of the EINT controller
ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
ARM i.MX6: Fix ldb_di clock selection
ARM: imx: provide twd clock lookup from device tree
ARM: imx35 Bugfix admux clock
ARM: clk-imx35: Bugfix iomux clock
+ Linux 3.9-rc6
Signed-off-by: Olof Johansson <olof@lixom.net>
Conflicts:
arch/arm/mach-omap2/cclock44xx_data.c
Add quirk for VT6306 wake bit behavior.
VT6306 seems to reread the wrong descriptor when the wake bit is
written. work around by putting a copy of the branch address in the
first descriptor of the block.
[Stefan R: This fixes the known broken video reception via gstreamer
on VIA VT6306. 100% repeatable testcase:
$ gst-launch-0.10 dv1394src \! dvdemux \! dvdec \! xvimagesink
with a camcorder or other DV source connected. Likewise for MPEG2-TS
reception via gstreamer, e.g. from TV settop boxes.
Perhaps this also fixes dv4l on VT6306, but this is as yet untested.
Kino, dvgrab or FFADO had not been affected by this chip quirk.
Additional comments from Andy:]
I've looked into some problems with the wake bit on a vt6306 family
chip (1106:3044, rev 46).
I used this firewire card in a mythtv setup (ISO receive MPEG2 stream)
with Debian 2.6.32 kernels for ~2 years without problems.
Since upgrading to 3.2, I've been having problems with the input stream
freezing -- input data stops until I restart mythtv (I expect closing
and reopening the device would be sufficient). This happens
infrequently, maybe one out of 20 recordings. I eventually determined
that the problem is more likely to occur if the system is loaded.
I isolated the kernel version as the triggering SW factor and then
specifically the change from dualbuffer back to packet-per-buffer DMA
mode.
The possibility that the controller does not properly respond to the
wake bit was suggested in
https://bugzilla.redhat.com/show_bug.cgi?id=415841, but not proven.
Based on the fact that dualbuffer mode worked while packet-per-buffer
has trouble, I guessed that upon seeing the wake bit written, the vt6306
controller only checks the branch address in the first descriptor of the
block, even if that is not the correct place to look (because the block
has multiple descriptors).
This theory seems to be correct. When the ISO reception is hung, I am
able to resume it by manually writing the branch address to the first
descriptor in the block, and then writing the wake bit.
I've had luck so far with the attached patch, so I'm including it. It's
probably not a complete solution -- I haven't tested transmit modes to
see whether they have a similar issue.
I doubt that the quirk test is any cheaper than just writing the extra
branch address in all cases, but it does reduce the risk of breaking
other hardware.
[Stefan R: omitted QUIRK_NO_MSI from VT6306 quirks table entry,
changed whitespace]
Signed-off-by: Andy Leiserson <andy@leiserson.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
A pci device can be removed while in its suspended state. If the ohci
host controller is suspended, the PHY is also in low-power mode and
LPS is disabled. If LPS is disabled, most of the host registers aren't
accessible, including IntMaskClear. Furthermore, access to these registers
when LPS is disabled can cause hard lockups on some hardware. Since
interrupts are already disabled in this mode, further action is
unnecessary.
Test LPS before attempting to write IntMaskClear to disable interrupts.
[Stefan R: whitespace changes]
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
A pci device can be removed while in its suspended state.
Because the ohci driver freed the irq to suspend, free_irq() is
called twice; once from pci_remove() and again from pci_suspend(),
which issues the warning below [1].
Rather than allocate the irq in the .enable() path, move the
allocation to .probe(). Consequently, the irq is not reallocated
upon pci_resume() and thus is not freed upon pci_suspend().
[1] Warning reported by Mark Einon <mark.einon@gmail.com> when
suspending an MSI MS-1727 GT740 laptop on Ubuntu 3.5.0-22-generic
WARNING: at ./kernel/irq/manage.c:1198 __free_irq+0xa3/0x1e0()
Hardware name: MS-1727
Trying to free already-free IRQ 16
Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables <...snip...>
Pid: 4, comm: kworker/0:0 Tainted: P O 3.5.0-22-generic #34-Ubuntu
Call Trace:
[<ffffffff81051c1f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff81051d16>] warn_slowpath_fmt+0x46/0x50
[<ffffffff8103fa39>] ? default_spin_lock_flags+0x9/0x10
[<ffffffff810df6b3>] __free_irq+0xa3/0x1e0
[<ffffffff810df844>] free_irq+0x54/0xc0
[<ffffffffa005a27e>] pci_remove+0x6e/0x210 [firewire_ohci]
[<ffffffff8135ae7f>] pci_device_remove+0x3f/0x110
[<ffffffff8141fdbc>] __device_release_driver+0x7c/0xe0
[<ffffffff8141fe4c>] device_release_driver+0x2c/0x40
[<ffffffff8141f5f1>] bus_remove_device+0xe1/0x120
[<ffffffff8141cd1a>] device_del+0x12a/0x1c0
[<ffffffff8141cdc6>] device_unregister+0x16/0x30
[<ffffffff81354784>] pci_stop_bus_device+0x94/0xa0
[<ffffffffa0091c67>] acpiphp_disable_slot+0xb7/0x1a0 [acpiphp]
[<ffffffffa0090716>] ? get_slot_status+0x46/0xc0 [acpiphp]
[<ffffffffa0091d7d>] acpiphp_check_bridge.isra.15+0x2d/0xf0 [acpiphp]
[<ffffffffa0092442>] _handle_hotplug_event_bridge+0x372/0x4d0 [acpiphp]
[<ffffffff81390f8c>] ? acpi_os_execute_deferred+0x2f/0x34
[<ffffffff8116e22d>] ? kfree+0xed/0x110
[<ffffffff8107086a>] process_one_work+0x12a/0x420
[<ffffffffa00920d0>] ? _handle_hotplug_event_func+0x1d0/0x1d0 [acpiphp]
[<ffffffff8107141e>] worker_thread+0x12e/0x2f0
[<ffffffff810712f0>] ? manage_workers.isra.26+0x200/0x200
[<ffffffff81075f13>] kthread+0x93/0xa0
[<ffffffff8168d024>] kernel_thread_helper+0x4/0x10
[<ffffffff81075e80>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff8168d020>] ? gs_change+0x13/0x13
Reported-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
No need to crash and burn if S/G element sizes cannot be set to our
liking; just leave a message in the log.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The old IEEE 1394 driver stack was removed in v2.6.37. That made the
checks for two Kconfig (module) macros unneeded, since they will now
always evaluate to true. Remove these two checks.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJReVkKAAoJEA0Cl+kVi2xqQMQP/3r2I9lir6uKXF/WIFgzYMUp
6PHaISZex6gvBOUmVKo2akkH8iqQNNqQLjt0TQ/ZMQ3HByj0A6qZ+RnMZhReNs1d
6tu/PaE5pV5cp4I97fx0MyHoLsySqmC9fbwM78YDCb4hwpcDLpvK45CMvQ4Uc56N
xvIC0DGhLK5kZrBy3+SolfHvOMn3F5Lfc6+VpZxxZgTUS1oMTtTwe/iUOjnhEL5C
Qnjkpc2R4IERMRNtNgeWOwjMwj+vHv2tIz0K+3/hXe34AqYX0gFYm2mB88Bi5tK8
lUt7e1hz9QKobPgike7rCtj/Ap8EkFuC0yGLOiLHA21HeyiTLCkV77ennSs/00kc
ijeQmG382C8CqDvjKpXhaP7gPQQcUIC95EncS1ts+iM/dcbUjbYdiV677QjARm+U
BMIw/fzTIs3uI2TRA7RMzQtlsbTfdVtVZJJx2HfpiKdpQWhT+B+mCS/KOf22D9cj
KGoF7AKvLAUIlbYdgB2eloavM3tAYTJtuWQEnmp//YtcOUVaESDRn/01Y7lDYpLX
VF8jayav4pu2cDiSnvFDsBj7gGlFhdcu4pPwpoRvKVKeKJZJHwo/0Yv0f3dNbqKa
2loO9AdgSH//g5Y3SPbVBr4HYCSpn+S0K63hmwXhpxbHtQsj2D1OQ640YSggdkj1
tU4rwoM24digFbOZvrQk
=sRUG
-----END PGP SIGNATURE-----
Merge tag 'late-exynos-v3-for-v3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into late/dt
From Kukjin Kim:
This allows that device tree enables platform to setup a runtime IO
mapping for the chip id
* tag 'late-exynos-v3-for-v3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: dts: Add chip-id controller node on Exynos4/5 SoC
ARM: EXYNOS: Create virtual I/O mapping for Chip-ID controller using device tree
Signed-off-by: Olof Johansson <olof@lixom.net>
This patch adds basic device tree sources for Universal C210 board.
Currently support includes:
- eMMC
- serial
- max8952 and max8998 voltage regulators.
- gpio-keys
More support will be added in further patches.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
