Pull timer and x86 fix from Ingo Molnar:
"A CLOCK_TAI early expiry fix and an x86 microcode driver oops fix"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
hrtimer: Fix incorrect tai offset calculation for non high-res timer systems
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, microcode: Return error from driver init code when loader is disabled
Allow users the option to disable the driver for any hardware
which does not support HWP.
Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull scheduler fixes from Ingo Molnar:
"Misc fixes"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/deadline: Fix deadline parameter modification handling
sched/wait: Remove might_sleep() from wait_event_cmd()
sched: Fix crash if cpuset_cpumask_can_shrink() is passed an empty cpumask
sched/fair: Avoid using uninitialized variable in preferred_group_nid()
IOMMU operations can be expensive and it's not very difficult for a
user to give us a lot of work to do for a map or unmap operation.
Killing a large VM will vfio assigned devices can result in soft
lockups and IOMMU tracing shows that we can easily spend 80% of our
time with need-resched set. A sprinkling of conf_resched() calls
after map and unmap calls has a very tiny affect on performance
while resulting in traces with <1% of calls overflowing into needs-
resched.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
We still need a validate_link_af() handler with an appropriate nla policy,
similarly as we have in IPv4 case, otherwise size validations are not being
done properly in that case.
Fixes: f53adae4ea ("net: ipv6: add tokenized interface identifier support")
Fixes: bc91b0f07a ("ipv6: addrconf: implement address generation modes")
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull sound fixes from Takashi Iwai:
"Hopefully the final pull request for 3.19: this ended up with a
slightly higher volume than wished, but I put them all as they are
either stable or 3.19 regression fixes.
Most of commits are from ASoC, and have been stewed for a while in
linux-next. The only change in the common code is the regression
fixes for ASoC AC97 stuff wrt device registrations. The rest are
device-specific, mostly small fixes in various ASoC drivers and ak411x
on ice1724 boards"
* tag 'sound-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: Intel: fix sst firmware path for cht-bsw-rt5672
ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs
ASoC: sgtl5000: add delay before first I2C access
MAINTAINERS: ASoC: add maintainer for Intel BDW/HSW ASoC driver
ASoC: atmel_ssc_dai: fix the setting for DSP mode
ASoC: sgtl5000: Use shift mask when setting codec mode
ASoC: tlv320aic3x: Fix data delay configuration
ALSA: ak411x: Fix stall in work callback
ASoC: Intel: Used lock version to update shim registers
ASoC: wm8731: init mutex in i2c init path
ASoC: atmel_ssc_dai: fix start event for I2S mode
ASoC: rt5640: Add RT5642 ACPI ID for Intel Baytrail
ASoC: wm97xx: Reset AC'97 device before registering it
ASoC: Add support for allocating AC'97 device before registering it
There are a couple bugs with the error handling in this function.
1) If we can't allocate "rx_ring->rx_skbuff" then we should call
dma_free_coherent() but we don't.
2) free_rx_ring() frees "rx_ring->rx_skbuff_dma" and "rx_ring->rx_skbuff"
so calling it in a loop causes a double free.
Also it was a bit confusing how we sometimes freed things before doing
the goto. I've cleaned it up so it does error handling in normal kernel
style.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The aurora_inv_range(), aurora_clean_range() and aurora_flush_range()
functions are highly redundant, both in source and in object code, and
they are harder to understand than necessary.
By moving the range loop into the aurora_pa_range() function, they
become trivial wrappers, and the object code start looking like what
one would expect for an optimal implementation.
Further optimization may be possible by using the per-CPU "virtual"
registers to avoid the spinlocks in most cases.
(on Armada 370 RD and Armada XP GP, boot tested, plus a little bit of
DMA traffic by reading data from a SD card)
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The aurora cache controller is the only remaining user of a couple
of functions in this file and are completely unused when that is
disabled, leading to build warnings:
arch/arm/mm/cache-l2x0.c:167:13: warning: 'l2x0_cache_sync' defined but not used [-Wunused-function]
arch/arm/mm/cache-l2x0.c:184:13: warning: 'l2x0_flush_all' defined but not used [-Wunused-function]
arch/arm/mm/cache-l2x0.c:194:13: warning: 'l2x0_disable' defined but not used [-Wunused-function]
With the knowledge that the code is now aurora-specific, we can
simplify it noticeably:
- The pl310 errata workarounds are not needed on aurora and can be removed
- As confirmed by Thomas Petazzoni from the data sheet, the cache_wait()
macro is never needed.
- No need to hold the lock across atomic cache sync
- We can load the l2x0_base into a local variable across operations
There should be no functional change in this patch, but readability
and the generated object code improves, along with avoiding the
warnings.
(on Armada 370 RD and Armada XP GP, boot tested, plus a little bit of
DMA traffic by reading data from a SD card)
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We currently map invalid and reserved pages, such as often occur from
mapping MMIO regions of a VM through the IOMMU, using single pages.
There's really no reason we can't instead follow the methodology we
use for normal pages and find the largest possible physically
contiguous chunk for mapping. The only difference is that we don't
do locked memory accounting for these since they're not back by RAM.
In most applications this will be a very minor improvement, but when
graphics and GPGPU devices are in play, MMIO BARs become non-trivial.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
When unmapping DMA entries we try to rely on the IOMMU API behavior
that allows the IOMMU to unmap a larger area than requested, up to
the size of the original mapping. This works great when the IOMMU
supports superpages *and* they're in use. Otherwise, each PAGE_SIZE
increment is unmapped separately, resulting in poor performance.
Instead we can use the IOVA-to-physical-address translation provided
by the IOMMU API and unmap using the largest contiguous physical
memory chunk available, which is also how vfio/type1 would have
mapped the region. For a synthetic 1TB guest VM mapping and shutdown
test on Intel VT-d (2M IOMMU pagesize support), this achieves about
a 30% overall improvement mapping standard 4K pages, regardless of
IOMMU superpage enabling, and about a 40% improvement mapping 2M
hugetlbfs pages when IOMMU superpages are not available. Hugetlbfs
with IOMMU superpages enabled is effectively unchanged.
Unfortunately the same algorithm does not work well on IOMMUs with
fine-grained superpages, like AMD-Vi, costing about 25% extra since
the IOMMU will automatically unmap any power-of-two contiguous
mapping we've provided it. We add a routine and a domain flag to
detect this feature, leaving AMD-Vi unaffected by this unmap
optimization.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Merge misc fixes from Andrew Morton:
"7 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm/debug_pagealloc: fix build failure on ppc and some other archs
nilfs2: fix deadlock of segment constructor over I_SYNC flag
MAINTAINERS: remove SUPERH website
memcg, shmem: fix shmem migration to use lrucare
mm: export "high_memory" symbol on !MMU
.mailmap: update Konstantin Khlebnikov's email address
mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range
Pull MIPS fixes from Ralf Baechle:
"The pending MIPS fixes for 3.19. All across the field and nothing
particularly severe or dramatic"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: (23 commits)
IRQCHIP: mips-gic: Avoid rerouting timer IRQs for smp-cmp
MIPS: Fix syscall_get_nr for the syscall exit tracing.
MIPS: elf2ecoff: Ignore PT_MIPS_ABIFLAGS program headers.
MIPS: elf2ecoff: Rewrite main processing loop to switch.
MIPS: fork: Fix MSA/FPU/DSP context duplication race
MIPS: Fix C0_Pagegrain[IEC] support.
MIPS: traps: Fix inline asm ctc1 missing .set hardfloat
MIPS: mipsregs.h: Add write_32bit_cp1_register()
MIPS: Fix kernel lockup or crash after CPU offline/online
MIPS: OCTEON: fix kernel crash when offlining a CPU
MIPS: ARC: Fix build error.
MIPS: IRQ: Fix disable_irq on CPU IRQs
MIPS: smp-mt,smp-cmp: Enable all HW IRQs on secondary CPUs
MIPS: Fix restart of indirect syscalls
MIPS: ELF: fix loading o32 binaries on 64-bit kernels
MIPS: mips-cm: Fix sparse warnings
MIPS: Kconfig: Fix recursive dependency.
MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.
MIPS: JZ4740: Fixup #include's (sparse)
MIPS: Wire up execveat(2).
...
This patch enhances debugging with the GPE reference count messages added.
No functional changes.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch implementes the QR_EC flushing support.
Grace periods are implemented from the detection of an SCI_EVT to the
submission/completion of the QR_EC transaction. During this period, all
EC command transactions are allowed to be submitted.
Note that query periods and event periods are intentionally distiguished to
allow further improvements.
1. Query period: from the detection of an SCI_EVT to the sumission of the
QR_EC command. This period is used for storming prevention, as currently
QR_EC is deferred to a work queue rather than directly issued from the
IRQ context even there is no other transactions pending, so malicous
SCI_EVT GPE can act like "level triggered" to trigger a GPE storm. We
need to be prepared for this. And in the future, we may change it to be
a part of the advance_transaction() where we will try QR_EC submission
in appropriate positions to avoid such GPE storming.
2. Event period: from the detection of an SCI_EVT to the completion of the
QR_EC command. We may extend it to the completion of _Qxx evaluation.
This is actually a grace period for event flushing, but we only flush
queries due to the reason stated in known issue 1. That's also why we
use EC_FLAGS_EVENT_xxx. During this period, QR_EC transactions need to
pass the flushable submission check.
In this patch, the following flags are implemented:
1. EC_FLAGS_EVENT_ENABLED: this is derived from the old
EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT handlings.
With this flag, the logics implemented by the original flag are
extended:
1. Old logic: unless both of the flags are set, the event poller will
not be scheduled, and
2. New logic: as soon as both of the flags are set, the evet poller will
be scheduled.
2. EC_FLAGS_EVENT_DETECTED: this is also derived from the old
EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT detection. It thus
can be used to indicate the storming prevention period for query
submission.
acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to
implement this period so that acpi_set_gpe() can be invoked under the
"reference count > 0" condition.
3. EC_FLAGS_EVENT_PENDING: this is newly added to indicate the grace period
for event flushing (query flushing for now).
acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to
implement this period so that the flushing process can wait until the
event handling (query transaction for now) to be completed.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch refines EC command storm prevention support.
Current command storming code is wrong, when the storming condition is
detected, it only flags the condition without doing anything for the
current command but performing storming prevention for the follow-up
commands. So:
1. The first command which suffers from the storming still suffers from
storming.
2. The follow-up commands which may not suffer from the storming are
unconditionally forced into the storming prevention mode.
Ideally, we should only enable storm prevention immediately after detection
for the current command so that the next command can try the
power/performance efficient interrupt mode again.
This patch improves the command storm prevention by disabling GPE right
after the detection and re-enabling it right before completing the command
transaction using the GPE storming prevention APIs. This thus deploys the
following GPE handling model:
1. acpi_enable_gpe()/acpi_disable_gpe() for reference count changes:
This set of APIs are used for EC usage reference counting.
2. acpi_set_gpe(ACPI_GPE_ENABLE)/acpi_set_gpe(ACPI_GPE_DISABLE):
This set of APIs are used for preventing GPE storm. They must be invoked
when the reference count > 0.
Note that as the storming prevention should always happen when there is
an outstanding request, or GPE enabling value will be messed up by the
races. This patch also adds BUG_ON() to enforces this rule to prevent
future bugs.
The msleep(1) used after completing a transaction is useless now as this
sounds like a guard time only useful for platforms that need the
EC_FLAGS_MSI quirks while we have fixed GPE race issues using the previous
raw handler mode enabling. It is kept to avoid regressions. A seperate
patch which deletes EC_FLAGS_MSI quirks should take care of deleting it.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch implements the EC command flushing support.
During the grace period indicated by EC_FLAGS_STARTED and EC_FLAGS_STOPPED,
all submitted EC command transactions can be completed and new submissions
are prevented before suspending so that the EC hardware can be ensured to
be in the idle state when the system is resumed.
There is a good indicator for flush support:
All acpi_ec_submit_request() is invoked after checking driver state with
acpi_ec_started() except the first one. This means all code paths can be
flushed as fast as possible by discarding the requests occurred after the
flush operation. The reference increased for such kind of code path is
wrapped by acpi_ec_submit_flushable_request().
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
By using the 2 flags, we can indicate an inter-mediate state where the
current transactions should be completed while the new transactions should
be dropped.
The comparison of the old flag and the new flags:
Old New
about to set BLOCKED STOPPED set / STARTED set
BLOCKED set STOPPED clear / STARTED clear
BLOCKED clear STOPPED clear / STARTED set
A new period can be indicated by the 2 flags. The new period is between the
point where we are about to set BLOCKED and the point when the BLOCKED is
set. The new flags facilitate us with acpi_ec_started() check to allow the
EC transaction to be submitted during the new period. This period thus can
be used as a grace period for the EC transaction flushing.
The only functional change after applying this patch is:
1. The GPE enabling/disabling is protected by the EC specific lock. We can
do this because of recent ACPICA GPE API enhancement. This is reasonable
as the GPE disabling/enabling state should only be determined by the EC
driver's state machine which is protected by the EC spinlock.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART, GPIO found on AMD CZ and
later chipsets. It based on example intel LPSS. Now, it can
support AMD I2C, UART and GPIO.
Signed-off-by: Ken Xue <Ken.Xue@amd.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
This parameter helps a lot for latency-bound workloads---in particular
I tested it with O_DSYNC writes with a battery-backed disk in the host.
In this case, writes are fast (because the data doesn't have to go all
the way to the platters) but they cannot be merged by either the host or
the guest. KVM's performance here is usually around 30% of bare metal,
or 50% if you use cache=directsync or cache=writethrough (these
parameters avoid that the guest sends pointless flush requests, and
at the same time they are not slow because of the battery-backed cache).
The bad performance happens because on every halt the host CPU decides
to halt itself too. When the interrupt comes, the vCPU thread is then
migrated to a new physical CPU, and in general the latency is horrible
because the vCPU thread has to be scheduled back in.
With this patch performance reaches 60-65% of bare metal and, more
important, 99% of what you get if you use idle=poll in the guest. This
means that the tunable gets rid of this particular bottleneck, and more
work can be done to improve performance in the kernel or QEMU.
Of course there is some price to pay; every time an otherwise idle vCPUs
is interrupted by an interrupt, it will poll unnecessarily and thus
impose a little load on the host. The above results were obtained with
a mostly random value of the parameter (500000), and the load was around
1.5-2.5% CPU usage on one of the host's core for each idle guest vCPU.
The patch also adds a new stat, /sys/kernel/debug/kvm/halt_successful_poll,
that can be used to tune the parameter. It counts how many HLT
instructions received an interrupt during the polling period; each
successful poll avoids that Linux schedules the VCPU thread out and back
in, and may also avoid a likely trip to C1 and back for the physical CPU.
While the VM is idle, a Linux 4 VCPU VM halts around 10 times per second.
Of these halts, almost all are failed polls. During the benchmark,
instead, basically all halts end within the polling period, except a more
or less constant stream of 50 per second coming from vCPUs that are not
running the benchmark. The wasted time is thus very low. Things may
be slightly different for Windows VMs, which have a ~10 ms timer tick.
The effect is also visible on Marcelo's recently-introduced latency
test for the TSC deadline timer. Though of course a non-RT kernel has
awful latency bounds, the latency of the timer is around 8000-10000 clock
cycles compared to 20000-120000 without setting halt_poll_ns. For the TSC
deadline timer, thus, the effect is both a smaller average latency and
a smaller variance.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Merge "Samsung CPUIdle updates for v3.20" from Kukjin Kim:
- adds coupled cpuidle support for exynos4210
: fix for Exynos platform PM code preparing it for the coupled
cpuidle support and adds coupled cpuidle AFTR mode on exynos4210
Note this is mostrly based on earlier cpuidle-exynos4210 driver
from Daniel Lezcano and Bart updated.
* tag 'samsung-cpuidle' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
cpuidle: exynos: add coupled cpuidle support for exynos4210
ARM: EXYNOS: apply S5P_CENTRAL_SEQ_OPTION fix only when necessary
Signed-off-by: Olof Johansson <olof@lixom.net>
For assigning sysfs entries for a card device from the driver,
introduce a new helper function, snd_card_add_dev_attr(). In this
way, we can avoid the possible race between the device registration
and the sysfs addition / removal.
The driver can pass a new attribute group to add freely. This has to
be called before snd_card_register().
Currently, up to two extra groups can be added. More than that, it'll
return an error.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While commit 7e36ef8205 ("IB/core: Temporarily disable
ex_query_device uverb") is correct as it makes the extended
QUERY_DEVICE uverb (which came as part of commit 5a77abf9a9
("IB/core: Add support for extended query device caps") and commit
860f10a799 ("IB/core: Add flags for on demand paging support")) not
available to userspace, it doesn't address the initial issue regarding
ib_copy_to_udata() [1][2].
Additionally, further discussions around this new uverb seems to
conclude it would require a different data structure than the one
currently described in <rdma/ib_user_verbs.h> [3].
Both of these issues require a revert of the changes, so this patch
partially reverts commit 8cdd312cfe ("IB/mlx5: Implement the ODP
capability query verb") and commit 860f10a799 ("IB/core: Add flags
for on demand paging support") and fully reverts commit 5a77abf9a9
("IB/core: Add support for extended query device caps").
[1] "Re: [PATCH v3 06/17] IB/core: Add support for extended query device caps"
http://mid.gmane.org/1418733236.2779.26.camel@opteya.com
[2] "Re: [PATCH] IB/core: Temporarily disable ex_query_device uverb"
http://mid.gmane.org/1423067503.3030.83.camel@opteya.com
[3] "RE: [PATCH v1 1/5] IB/uverbs: ex_query_device: answer must not depend on request's comp_mask"
http://mid.gmane.org/2807E5FD2F6FDA4886F6618EAC48510E0CC12C30@CRSMSX101.amr.corp.intel.com
Cc: Eli Cohen <eli@mellanox.com>
Cc: Haggai Eran <haggaie@mellanox.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Shachar Raindel <raindel@mellanox.com>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Merge "Samsung exynos_defconfig updates for v3.20" from Kukjin Kim:
- Enable CONFIG_LOCKUP_DETECTOR
: to detect hard lockup and soft lockup
- Enable PMIC and MUIC
: for battery charger, fuel-gauge, regulators
- Enable CONFIG_FHANDLE
: this is required by systemd
* tag 'samsung-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: exynos_defconfig: Enable CONFIG_FHANDLE
ARM: exynos_defconfig: Enable PMIC and MUIC drivers for Gears and Trats2
ARM: exynos_defconfig: Enable CONFIG_LOCKUP_DETECTOR
ARM: exynos_defconfig: Enable LM90 driver
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "ARM: mvebu: DT changes for v3.20 (round 2)" from Gregory CLEMENT:
Relicense all Armada dts{i} files under dual license of GPLv2+ and
X11. This should make it easier to reuse these files with other
operating systems and boot loaders.
* tag 'mvebu-dt-3.20-3' of git://git.infradead.org/linux-mvebu: (27 commits)
ARM: mvebu: armada-xp-synology-ds414: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-openblocks-ax3-4: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-netgear-rn2120: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-mv78460: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-mv78260: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-mv78230: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-matrix: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-lenovo-ix4-300d: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-gp: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-db: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-xp-axpwifiap: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-38x: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-388-rd: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-385: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-388-db: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-380: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-375: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-375-db: Relicense the device tree under GPLv2+/X11
ARM: mvebu: armada-370-xp: Relicense the device tree under GPLv2+/X11
...
Signed-off-by: Olof Johansson <olof@lixom.net>
with the patchset to add CSR atlas7 support, the below stuff
has no user now:
SIRFSOC_VA
sirfsoc_map_lluart
sirfsoc_map_scu
the related patches missed to drop them.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
this patch fixes following sparse warning:
processor_thermal_device.c:188:6: warning: symbol 'proc_thermal_remove' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Merge "ARM: Keystone soc config updates for 3.20" from Santosh Shilimkar:
Keystone DEVTMPFS config update for 3.20
* tag 'keystone-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone:
ARM: config: add DEVTMPFS option by default to keystone config
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "soc: ti: Keystone Navigator SOC driver updates for 3.20" from Santosh
Shilimkar:
Keystone Navigator SOC driver updates for 3.20
- Makefile tweak so that knav_qmss and knav_dma can be made loadable
modules without depedency issues.
- Few more exports to support ARM allmodconfig.
- Marking knav_range_setup_acc_irq() local function as static.
* tag 'drivers-soc-ti' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone:
soc: ti: knav_qmss_queue: change knav_range_setup_acc_irq to static
soc: ti: knav_qmss_queue: makefile tweak to build as dynamic module
soc: ti: knav_qmss_queue: export API calls for use by user driver
Signed-off-by: Olof Johansson <olof@lixom.net>
Now that we can specify which PMU variant we're likely to deal with, do
so in the omap board code. This will allow us to split the ARMv6, ARMv7,
and XScale PMU drivers.
The unnecessary include of asm/pmu.h is also removed.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Olof Johansson <olof@lixom.net>
Now that we can specify which PMU variant we're likely to deal with, do
so in the iop board code. This will allow us to split the ARMv6, ARMv7,
and XScale PMU drivers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Olof Johansson <olof@lixom.net>
Now that we can specify which PMU variant we're likely to deal with, do
so in the realview board code. This will allow us to split the ARMv6,
ARMv7, and XScale PMU drivers.
The Realview EB may be used with ARMv6 or ARMv7 CPUs, but luckily
there's only a single ARMv7 CPU, so we can match that explicitly to
determine whether or not we have an ARMv7 PMU.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "omap device tree changes for v3.20, part 3" from Tony Lindgren:
Device tree related chages for omaps to fix dm816x syscon,
fix various devices for gta04, and add USB nodes for am57xx
and dra7.
* tag 'omap-for-v3.20/dt-pt3-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: am57xx-beagle-x15: Fix USB2 mode
ARM: dts: am57xx-beagle-x15: Add extcon nodes for USB
ARM: dts: dra72-evm: Add extcon nodes for USB
ARM: dts: dra7-evm: Add extcon nodes for USB
ARM: dts: Fix dm816x pinctrl and syscon so they are children of SCM
ARM: dts: omap3-gta04: Disable keypad
ARM: dts: omap3-gta04: only power DSS when necessary.
ARM: dts: omap3-gta04: add gyroscope
ARM: dts: omap3-gta04: enable power-off for wifi card.
ARM: dts: omap3-gta04: add comments about gpios
ARM: dts: omap3-gta04: Add ramp value for twl4030 audio
ARM: dts: omap3-gta04: Enable power-off using twl4030
ARM: dts: omap3-gta04: Fix a GPIO line for bma180 node
ARM: dts: omap3-gta04: Enable twl audio vibra support
ARM: dts: omap3-gta04: Enable mcbps2 necessary for audio
ARM: dts: omap3-gta04: Fix audio node malformatting
ARM: dts: omap3-gta04: Fix backup-battery charging in devicetree file.
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "ARM: rockchip: third (and last) batch of dts updates for 3.20" from
Heiko Stübner:
Change are regulator nodes for the cpu and gpu regulators on the act8846
variant of the rk3288-evb and the setting of a clock for the watchdog.
Also the lcd and hdmi controllers on both the firefly and the evb get
enabled and let us now boot into fbcon console sucessfully.
* tag 'v3.20-rockchip-dts3' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
ARM: dts: rockchip: move the hdmi ddc-i2c-bus property to the actual boards
ARM: dts: rockchip: enable vops and hdmi output on rk3288-firefly and -evb
ARM: dts: rockchip: housekeeping off i2c0 on rk3288-evb boards
ARM: dts: rockchip: add cpu and gpu regulators to rk3288-evb-act8846
ARM: dts: rockchip: add rk3288 watchdog clock
clk: rockchip: add id for watchdog pclk on rk3288
clk: rockchip: add clock IDs for the PVTM clocks
clk: rockchip: add clock ID for usbphy480m_src
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "Fix git repositories for Broadcom SoCs (v3.20)" from Florian Fianelli:
This pull request fixes the github.com/broadcom URLs which had one too many
"git." in front of all git repositories.
* tag 'arm-soc/for-3.20/maintainer' of http://github.com/broadcom/stblinux:
MAINTAINERS: fix git repositories for Broadcom SoCs
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "at91: cleanup/soc for 3.20 #4" from Nicolas Ferre:
Fourth cleanup/soc batch for 3.20:
- merge all the at91sam9 code and remove the empty SoC-specific files
- remove the at91_boot_soc that is now useless in a DT context
- move the sram code in PM code as it's now only used there
- some file + function name changes after this big cleanup
* tag 'at91-soc4' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91:
ARM: at91/trivial: unify functions and machine names
ARM: at91: remove at91_dt_initialize and machine init_early()
ARM: at91: change board files into SoC files
ARM: at91: remove at91_boot_soc
ARM: at91: move alternative initial mapping to board-dt-sama5.c
ARM: at91: merge all SOC_AT91SAM9xxx
ARM: at91: at91rm9200: set idle and restart from rm9200_dt_device_init()
ARM: at91: board-dt-sama5: add phy_fixup to override NAND_Tree
ARM: at91/dt: sam9263: Add missing clocks to lcdc node
ARM: at91: sama5d3: dt: correct the sound route
ARM: at91/dt: sama5d4: fix the timer reg length
Signed-off-by: Olof Johansson <olof@lixom.net>
* Add support for beamforming
* Enable stuck queue detection for iwlmvm
* A few fixes for EBS scan
* Fixes for various failure paths
* Improvements for TDLS Offchannel
Linus Torvalds