Andy Shevchenko [Tue, 13 Oct 2015 17:09:19 +0000 (20:09 +0300)]
dmaengine: dw: some Intel devices has no memcpy support
Provide a flag to choose if the device does support memory-to-memory transfers.
At least this is not true for iDMA32 controller that might be supported in the
future. Besides that Intel BayTrail and Braswell users should not try this
feature due to HW specific behaviour.
Peter Ujfalusi [Fri, 16 Oct 2015 07:18:12 +0000 (10:18 +0300)]
ARM: DTS: am437x: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Fri, 16 Oct 2015 07:18:11 +0000 (10:18 +0300)]
ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Fri, 16 Oct 2015 07:18:10 +0000 (10:18 +0300)]
dmaengine: edma: New device tree binding
With the old binding and driver architecture we had many issues:
No way to assign eDMA channels to event queues, thus not able to tune the
system by moving specific DMA channels to low/high priority servicing. We
moved the cyclic channels to high priority within the code, but that was
just a workaround to this issue.
Memcopy was fundamentally broken: even if the driver scanned the DT/devices
in the booted system for direct DMA users (which is not effective when the
events are going through a crossbar) and created a map of 'used' channels,
this information was not really usable. Since via dmaengien API the eDMA
driver will be called with _some_ channel number, we would try to request
this channel when any channel is requested for memcpy. By luck we got
channel which is not used by any device most of the time so things worked,
but if a device would have been using the given channel, but not requested
it, the memcpy channel would have been waiting for HW event.
The old code had the am33xx/am43xx DMA event router handling embedded. This
should have been done in a separate driver since it is not part of the
actual eDMA IP.
There were no way to 'lock' PaRAM slots to be used by the DSP for example
when booting with DT.
In DT boot the edma node used more than one hwmod which is not a good
practice and the kernel prints warning because of this.
With the new bindings and the changes in the driver we can:
- No regression with Legacy binding and non DT boot
- DMA channels can be assigned to any TC (to set priority)
- PaRAM slots can be reserved for other cores to use
- Dynamic power management for CC and TCs, if only TC0 is used all other TC
can be powered down for example
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Fri, 16 Oct 2015 07:18:09 +0000 (10:18 +0300)]
dmaengine: Kconfig: edma: Select TI_DMA_CROSSBAR in case of ARCH_OMAP
Since the crossbar is needed for eDMA when it is used on OMAP like
platforms (am335x/am437x and later DRA7xx), select the crossbar to be built
if ARCH_OMAP is set.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Fri, 16 Oct 2015 07:18:08 +0000 (10:18 +0300)]
dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx
The DMA event crossbar on AM33xx/AM43xx is different from the one found in
DRA7x family.
Instead of a single event crossbar it has 64 identical mux attached to each
eDMA event line. When the 0 event mux is selected, the default mapped event
is going to be routed to the corresponding eDMA event line. If different
mux is selected, then the selected event is going to be routed to the given
eDMA event.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Fri, 16 Oct 2015 07:18:03 +0000 (10:18 +0300)]
dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq
edma_assign_channel_eventq() is a wrapper around edma_map_dmach_to_queue()
We can merge the content of the later so we will have only one function
to be used for mapping channels to given eventq
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Fri, 16 Oct 2015 07:18:01 +0000 (10:18 +0300)]
dmaengine: edma: Simplify function parameter list for channel operations
Instead of passing a pointer to struct edma_cc and the channel number,
pass only the pointer to the edma_chan structure for the given channel.
This struct contains all the information needed by the functions and the
use of this makes it obvious that most of the sanity checks can be removed
from the driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Fri, 16 Oct 2015 07:18:00 +0000 (10:18 +0300)]
dmaengine: edma: Optimize memcpy operation
If the transfer is shorted then 64K we can complete it with one ACNT burst
by configuring ACNT to the length of the copy, this require one paRAM slot.
Otherwise we use two paRAM slots for the copy:
slot1: will copy (length / 32767) number of 32767 byte long blocks
slot2: will be configured to copy the remaining data.
According to tests this patch increases the throughput of memcpy from
~3MB/s to 15MB/s
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Fri, 16 Oct 2015 07:17:59 +0000 (10:17 +0300)]
dmaengine: edma: Remove alignment constraint for memcpy
Despite the claim by the original commit adding the memcpy
support, eDMA does not have constraint on the alignment of src, dst
or length in increment mode.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
dmaengine: xgene-dma: Remove memcpy offload support due to performance drop
The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
computations. But the bandwidth of the entire DMA engine is shared
among all channels. This patch re-configures operations availability
such that one can achieve maximum performance for XOR and PQ
computation by removing the memory offload operations.
Peter Ujfalusi [Wed, 14 Oct 2015 11:43:06 +0000 (14:43 +0300)]
dmaengine: edma: Dynamic paRAM slot handling if HW supports it
If the eDMA3 has support for channel paRAM slot mapping we can utilize it
to allocate slots on demand and save precious slots for real transfers.
On am335x the eDMA has 64 channels which means we can unlock 64 paRAM
slots out from the available 256.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:43:03 +0000 (14:43 +0300)]
dmaengine: edma: Simplify and optimize ccerr interrupt handler
No need to run through the bits in QEMR and CCERR events since they will
not trigger any action, so just clearing the errors there is fine.
In case of the missed event the loop can be optimized so we spend less time
to handle the event.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:43:02 +0000 (14:43 +0300)]
dmaengine: edma: Move the pending error check into helper function
In the ccerr interrupt handler the code checks for pending errors in the
error status registers in two different places.
Move the check out to a helper function.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:43:01 +0000 (14:43 +0300)]
dmaengine: edma: Simplify the interrupt handling
With the merger of the arch/arm/common/edma.c code into the dmaengine
driver, there is no longer need to have per channel callback/data storage
for interrupt events.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:42:54 +0000 (14:42 +0300)]
dmaengine: edma: Allocate memory dynamically for bitmaps and structures
Instead of using defines to specify the size of different arrays and
bitmaps, allocate the memory for them based on the information we get from
the HW itself.
Since these defines are set based on the worst case, there are devices
where they are not valid.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:42:53 +0000 (14:42 +0300)]
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/
Move the code out from arch/arm/common and merge it inside of the dmaengine
driver.
This change is done with as minimal (if eny) functional change to the code
as possible to avoid introducing regression.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:42:51 +0000 (14:42 +0300)]
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA
Convert the eDMA platform device creation to use
struct platform_device_info XXXXXX __initconst and
platform_device_register_full()
This will allow us to cleanly specify the dma_mask for the devices in an
upcoming patch.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:42:50 +0000 (14:42 +0300)]
ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers
Since the driver stack no longer depends on lookup with id number in a
global array of pointers, the limitation for the number of eDMAs are no
longer needed. We can handle as many eDMAs in legacy and DT boot as we have
memory for them to allocate the needed structures.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:42:47 +0000 (14:42 +0300)]
ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine driver
If the of_dma_controller is registered in the non dmaengine driver we could
have race condition:
the of_dma_controller has been registered, but the dmaengine driver is not
yet probed. Drivers requesting DMA channels during this window will fail
since we do not yet have dmaengine drivers registered.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:42:46 +0000 (14:42 +0300)]
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver
Currently we have one device created to handle all (maximum 2) eDMAs in the
system.
With this change all eDMA instance will have it's own device/driver.
This change is needed for further cleanups in the eDMA driver stack since
the one device/driver to handle all eDMAs in the system was not flexible
enough and prevents the upcoming work.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Peter Ujfalusi [Wed, 14 Oct 2015 11:42:45 +0000 (14:42 +0300)]
dmaengine: edma: Simplify and optimize the edma_execute path
The code path in edma_execute() and edma_callback() can be simplified
and make it more optimal.
There is not need to call in to edma_execute() when the transfer
has been finished for example.
Also the handling of missed/first or next batch of paRAMs can
be done in a more optimal way.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
dmaengine: omap-dma: Enable packed accesses for cyclic transfers
The L3 throughput can be higher than expected when packed access
is not enabled. The ratio depends on the number of bytes in a
transaction and the EMIF interface width.
The throughput was measured for the following settings/cases:
* Case 1: Burst size of 64 bytes, packed access disabled
* Case 2: Burst size of 64 bytes, packed access enabled
* Case 3: Burst disabled, packed access disabled
Throughput measurements were done during McASP-based audio
playback on the Jacinto6 EVM using the omapconf tool [1]:
$ omapconf trace bw -m sdma_rd
From above measurements, case 2 is the only one that delivers
the expected throughput for the given audio parameters. For
that reason, the packed accesses are now enabled.
It's worth to mention that packed accesses cannot be enabled
for all addressing modes. In cyclic transfers, it can be
enabled in the source for MEM_TO_DEV and in dest for DEV_TO_MEM,
as they use post-increment mode which supports packed accesses.
Peter Ujfalusi:
From the TRM regarding to this:
"NOTE: Except in the constant addressing mode, the source or
destination must be specified as packed for burst transactions
to occur."
So w/o the packed setting the burst on the MEM side was not
enabled, this explains the numbers.
dmaengine: sun6i: Fix module autoload for OF platform driver
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
dmaengine: at_xdmac: fix memory leak in interleaved mode
In interleaved mode, when numf > 1, we have only one descriptor for the
transfer but this descriptor has to be added to the descs_list. If not,
when doing remove_xfer, the descriptor won't be put back in the
free_descs_list.
Jarkko Nikula [Fri, 4 Sep 2015 13:12:30 +0000 (16:12 +0300)]
dmaengine: acpi: Use ACPI_COMPANION() instead of acpi_bus_get_device()
Get pointer to the struct acpi_device by using ACPI_COMPANION() macro. This
is more efficient than using ACPI_HANDLE() and acpi_bus_get_device().
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Andy Shevchenko [Mon, 14 Sep 2015 08:55:41 +0000 (11:55 +0300)]
dmaengine: idma64: use lo_hi_readq() / lo_hi_writeq()
There are already helper functions to do 64-bit I/O on 32-bit machines, thus we
don't need to reinvent the wheel. In our case we can't use readq() / writeq()
even on 64-bit kernel since there is a hardware limitation (OCP bus is a 32-bit
bus).
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Andy Shevchenko [Mon, 14 Sep 2015 08:55:40 +0000 (11:55 +0300)]
dmaengine: idma64: make better performance on pause / resume
Accordingly to the documentation the CH_DRAIN bit enforses single bursts when
channel is going to be suspended. This, in case when channel will be resumed,
makes data to flow in non-optimal mode until DMA returns to full burst mode.
The fix differentiates pause / resume cycle from pause / terminate and sets
CH_DRAIN bit accordingly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
the symbol CONFIG_IDMA64 should rather be CONFIG_INTEL_IDMA64 to conform to
rest of the intel dmaengine drivers. This was found after sorting the
entries and trying to place this odd one
Merge tag 'cris-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris
Pull CRIS updates from Jesper Nilsson:
"Mostly removal of old cruft of which we can use a generic version, or
fixes for code not commonly run in the cris port, but also additions
to enable some good debug"
* tag 'cris-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris: (25 commits)
CRISv10: delete unused lib/dmacopy.c
CRISv10: delete unused lib/old_checksum.c
CRIS: fix switch_mm() lockdep splat
CRISv32: enable LOCKDEP_SUPPORT
CRIS: add STACKTRACE_SUPPORT
CRISv32: annotate irq enable in idle loop
CRISv32: add support for irqflags tracing
CRIS: UAPI: use generic types.h
CRIS: UAPI: use generic shmbuf.h
CRIS: UAPI: use generic msgbuf.h
CRIS: UAPI: use generic socket.h
CRIS: UAPI: use generic sembuf.h
CRIS: UAPI: use generic sockios.h
CRIS: UAPI: use generic auxvec.h
CRIS: UAPI: use generic headers via Kbuild
CRIS: UAPI: fix elf.h export
CRIS: don't make asm/elf.h depend on asm/user.h
CRIS: UAPI: fix ptrace.h
CRISv32: Squash compile warnings for axisflashmap
CRISv32: Add GPIO driver to the default configs
...
Linus Torvalds [Wed, 27 May 2015 22:32:15 +0000 (15:32 -0700)]
blk: rq_data_dir() should not return a boolean
rq_data_dir() returns either READ or WRITE (0 == READ, 1 == WRITE), not
a boolean value.
Now, admittedly the "!= 0" doesn't really change the value (0 stays as
zero, 1 stays as one), but it's not only redundant, it confuses gcc, and
causes gcc to warn about the construct
switch (rq_data_dir(req)) {
case READ:
...
case WRITE:
...
that we have in a few drivers.
Now, the gcc warning is silly and stupid (it seems to warn not about the
switch value having a different type from the case statements, but about
_any_ boolean switch value), but in this case the code itself is silly
and stupid too, so let's just change it, and get rid of warnings like
this:
drivers/block/hd.c: In function ‘hd_request’:
drivers/block/hd.c:630:11: warning: switch condition has boolean value [-Wswitch-bool]
switch (rq_data_dir(req)) {
The odd '!= 0' came in when "cmd_flags" got turned into a "u64" in
commit 5953316dbf90 ("block: make rq->cmd_flags be 64-bit") and is
presumably because the old code (that just did a logical 'and' with 1)
would then end up making the type of rq_data_dir() be u64 too.
But if we want to retain the old regular integer type, let's just cast
the result to 'int' rather than use that rather odd '!= 0'.
Fix up the writeback plugging introduced in commit d353d7587d02
("writeback: plug writeback at a high level") that then caused problems
due to the unplug happening with a spinlock held.
* writeback-plugging:
writeback: plug writeback in wb_writeback() and writeback_inodes_wb()
Revert "writeback: plug writeback at a high level"
writeback: plug writeback in wb_writeback() and writeback_inodes_wb()
We had to revert the pluggin in writeback_sb_inodes() because the
wb->list_lock is held, but we could easily plug at a higher level before
taking that lock, and unplug after releasing it. This does that.
Chris will run performance numbers, just to verify that this approach is
comparable to the alternative (we could just drop and re-take the lock
around the blk_finish_plug() rather than these two commits.
I'd have preferred waiting for actual performance numbers before picking
one approach over the other, but I don't want to release rc1 with the
known "sleeping function called from invalid context" issue, so I'll
pick this cleanup version for now. But if the numbers show that we
really want to plug just at the writeback_sb_inodes() level, and we
should just play ugly games with the spinlock, we'll switch to that.
Cc: Chris Mason <clm@fb.com> Cc: Josef Bacik <jbacik@fb.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Neil Brown <neilb@suse.de> Cc: Jan Kara <jack@suse.cz> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I didn't notice this when merging the thermal code from Zhang, but his
merge (commit 5a924a07f882: "Merge branches 'thermal-core' and
'thermal-intel' of .git into next") of the thermal-core and
thermal-intel branches was wrong.
In thermal-core, commit 17e8351a7739 ("thermal: consistently use int for
temperatures") converted the thermal layer to use "int" for
temperatures.
But in parallel, in the thermal-intel branch commit d0a12625d2ff
("thermal: Add Intel PCH thermal driver") added support for the intel
PCH thermal sensor using the old interfaces that used "unsigned long"
pointers.
This resulted in warnings like this:
drivers/thermal/intel_pch_thermal.c:184:14: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
.get_temp = pch_thermal_get_temp,
^
drivers/thermal/intel_pch_thermal.c:184:14: note: (near initialization for ‘tzd_ops.get_temp’)
drivers/thermal/intel_pch_thermal.c:186:19: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
.get_trip_temp = pch_get_trip_temp,
^
drivers/thermal/intel_pch_thermal.c:186:19: note: (near initialization for ‘tzd_ops.get_trip_temp’)
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
revert "ocfs2/dlm: use list_for_each_entry instead of list_for_each"
mm/early_ioremap: add explicit #include of asm/early_ioremap.h
fs/seq_file: convert int seq_vprint/seq_printf/etc... returns to void
selftests: enhance membarrier syscall test
selftests: add membarrier syscall test
sys_membarrier(): system-wide memory barrier (generic, x86)
MODSIGN: fix a compilation warning in extract-cert
Merge tag 'ntb-4.3' of git://github.com/jonmason/ntb
Pull NTB fixes from Jon Mason:
"NTB bug and documentation fixes, new device IDs, performance
improvements, and adding a mailing list to MAINTAINERS for NTB"
* tag 'ntb-4.3' of git://github.com/jonmason/ntb:
NTB: Fix range check on memory window index
NTB: Improve index handling in B2B MW workaround
NTB: Fix documentation for ntb_peer_db_clear.
NTB: Fix documentation for ntb_link_is_up
NTB: Use unique DMA channels for TX and RX
NTB: Remove dma_sync_wait from ntb_async_rx
NTB: Clean up QP stats info
NTB: Make the transport list in order of discovery
NTB: Add PCI Device IDs for Broadwell Xeon
NTB: Add flow control to the ntb_netdev
NTB: Add list to MAINTAINERS
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull more input updates from Dmitry Torokhov:
"Second round of updates for the input subsystem.
This introduces two brand new touchscreen drivers (Colibri and
imx6ul_tsc), some small driver fixes, and we are no longer report
errors from evdev_flush() as users do not really have a way of
handling errors, error codes that we were returning were not on the
list of errors supposed to be returned by close(), and errors were
causing issues with one of older versions of systemd"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: imx_keypad - remove obsolete comment
Input: touchscreen - add imx6ul_tsc driver support
Input: Add touchscreen support for Colibri VF50
Input: i8042 - lower log level for "no controller" message
Input: evdev - do not report errors form flush()
Input: elants_i2c - extend the calibration timeout to 12 seconds
Input: sparcspkr - fix module autoload for OF platform drivers
Input: regulator-haptic - fix module autoload for OF platform driver
Input: pwm-beeper - fix module autoload for OF platform driver
Input: ab8500-ponkey - Fix module autoload for OF platform driver
Input: cyttsp - remove unnecessary MODULE_ALIAS()
Input: elan_i2c - add ACPI ID "ELAN1000"
Merge tag 'pm+acpi-4.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more power management and ACPI updates from Rafael Wysocki:
"These are mostly fixes and cleanups on top of the previous PM+ACPI
pull request (cpufreq core and drivers, cpuidle, generic power domains
framework). Some of them didn't make to that pull request and some
fix issues introduced by it.
The only really new thing is the support for suspend frequency in the
cpufreq-dt driver, but it is needed to fix an issue with Exynos
platforms.
Specifics:
- build fix for the new Mediatek MT8173 cpufreq driver (Guenter
Roeck).
- generic power domains framework fixes (power on error code path,
subdomain removal) and cleanup of a deprecated API user (Geert
Uytterhoeven, Jon Hunter, Ulf Hansson).
- cpufreq-dt driver fixes including two fixes for bugs related to the
new Operating Performance Points Device Tree bindings introduced
recently (Viresh Kumar).
- suspend frequency support for the cpufreq-dt driver (Bartlomiej
Zolnierkiewicz, Viresh Kumar).
- cpufreq core cleanups (Viresh Kumar).
- intel_pstate driver fixes (Chen Yu, Kristen Carlson Accardi).
- additional sanity check in the cpuidle core (Xunlei Pang).
- fix for a comment related to CPU power management (Lina Iyer)"
* tag 'pm+acpi-4.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
intel_pstate: fix PCT_TO_HWP macro
intel_pstate: Fix user input of min/max to legal policy region
PM / OPP: Return suspend_opp only if it is enabled
cpufreq-dt: add suspend frequency support
cpufreq: allow cpufreq_generic_suspend() to work without suspend frequency
PM / OPP: add dev_pm_opp_get_suspend_opp() helper
staging: board: Migrate away from __pm_genpd_name_add_device()
cpufreq: Use __func__ to print function's name
cpufreq: staticize cpufreq_cpu_get_raw()
PM / Domains: Ensure subdomain is not in use before removing
cpufreq: Add ARM_MT8173_CPUFREQ dependency on THERMAL
cpuidle/coupled: Add sanity check for safe_state_index
PM / Domains: Try power off masters in error path of __pm_genpd_poweron()
cpufreq: dt: Tolerance applies on both sides of target voltage
cpufreq: dt: Print error on failing to mark OPPs as shared
cpufreq: dt: Check OPP count before marking them shared
kernel/cpu_pm: fix cpu_cluster_pm_exit comment
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull second round of SCSI updates from James Bottomley:
"There's one late arriving patch here (added today), fixing a build
issue which the scsi_dh patch set in here uncovered. Other than that,
everything has been incubated in -next and the checkers for a week.
The major pieces of this patch are a set patches facilitating better
integration between scsi and scsi_dh (the device handling layer used
by multi-path; all the dm parts are acked by Mike Snitzer).
This also includes driver updates for mp3sas, scsi_debug and an
assortment of bug fixes"
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (50 commits)
scsi_dh: fix randconfig build error
scsi: fix scsi_error_handler vs. scsi_host_dev_release race
fcoe: Convert use of __constant_htons to htons
mpt2sas: setpci reset kernel oops fix
pm80xx: Don't override ts->stat on IO_OPEN_CNX_ERROR_HW_RESOURCE_BUSY
lpfc: Fix possible use-after-free and double free in lpfc_mbx_cmpl_rdp_page_a2()
bfa: Fix incorrect de-reference of pointer
bfa: Fix indentation
scsi_transport_sas: Remove check for SAS expander when querying bay/enclosure IDs.
scsi_debug: resp_request: remove unused variable
scsi_debug: fix REPORT LUNS Well Known LU
scsi_debug: schedule_resp fix input variable check
scsi_debug: make dump_sector static
scsi_debug: vfree is null safe so drop the check
scsi_debug: use SCSI_W_LUN_REPORT_LUNS instead of SAM2_WLUN_REPORT_LUNS;
scsi_debug: define pr_fmt() for consistent logging
mpt2sas: Refcount fw_events and fix unsafe list usage
mpt2sas: Refcount sas_device objects and fix unsafe list usage
scsi_dh: return SCSI_DH_NOTCONN in scsi_dh_activate()
scsi_dh: don't allow to detach device handlers at runtime
...
Merge tag 'media/v4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
"A series of patches that move part of the code used to allocate memory
from the media subsystem to the mm subsystem"
[ The mm parts have been acked by VM people, and the series was
apparently in -mm for a while - Linus ]
* tag 'media/v4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()
[media] media: vb2: Remove unused functions
[media] media: vb2: Convert vb2_dc_get_userptr() to use frame vector
[media] media: vb2: Convert vb2_vmalloc_get_userptr() to use frame vector
[media] media: vb2: Convert vb2_dma_sg_get_userptr() to use frame vector
[media] vb2: Provide helpers for mapping virtual addresses
[media] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()
[media] mm: Provide new get_vaddr_frames() helper
[media] vb2: Push mmap_sem down to memops
Merge tag 'edac/v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac
Pull edac updates from Mauro Carvalho Chehab:
"Two EDAC fixes for Intel systems (Haswell and Ivy Bridge)"
* tag 'edac/v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac:
sb_edac: correctly fetch DIMM width on Ivy Bridge and Haswell
sb_edac: look harder for DDRIO on Haswell systems
Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
Pull thermal updates from Zhang Rui:
- use int instead of unsigned long to represent temperature to avoid
bogus overheat detection when negative temperature reported. From
Sascha Hauer.
- export available thermal governors information to user space via
sysfs. From Wei Ni.
- introduce new thermal driver for Wildcat Point platform controller
hub, which uses PCH thermal sensor and associated critical and hot
trip points. From Tushar Dave.
- add suuport for Intel Skylake and Denlow platforms in powerclamp
driver.
- some small cleanups in thermal core.
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
thermal: Add Intel PCH thermal driver
thermal: Add comment explaining test for critical temperature
thermal: Use IS_ENABLED instead of #ifdef
thermal: remove unnecessary call to thermal_zone_device_set_polling
thermal: trivial: fix typo in comment
thermal: consistently use int for temperatures
thermal: add available policies sysfs attribute
thermal/powerclamp: add cpu id for denlow platform
thermal/powerclamp: add cpu id for Skylake u/y
thermal/powerclamp: add cpu id for skylake h/s
mm/early_ioremap: add explicit #include of asm/early_ioremap.h
Commit 6b0f68e32ea8 ("mm: add utility for early copy from unmapped ram")
introduces a function copy_from_early_mem() into mm/early_ioremap.c
which itself calls early_memremap()/early_memunmap(). However, since
early_memunmap() has not been declared yet at this point in the .c file,
nor by any explicitly included header files, we are depending on a
transitive include of asm/early_ioremap.h to declare it, which is
fragile.
So instead, include this header explicitly.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Mark Salter <msalter@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Joe Perches [Fri, 11 Sep 2015 20:07:48 +0000 (13:07 -0700)]
fs/seq_file: convert int seq_vprint/seq_printf/etc... returns to void
The seq_<foo> function return values were frequently misused.
See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to
seq_has_overflowed() and make public")
All uses of these return values have been removed, so convert the
return types to void.
Miscellanea:
o Move seq_put_decimal_<type> and seq_escape prototypes closer the
other seq_vprintf prototypes
o Reorder seq_putc and seq_puts to return early on overflow
o Add argument names to seq_vprintf and seq_printf
o Update the seq_escape kernel-doc
o Convert a couple of leading spaces to tabs in seq_escape
Signed-off-by: Joe Perches <joe@perches.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Mark Brown <broonie@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Joerg Roedel <jroedel@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Update the membarrier syscall self-test to match the membarrier
interface. Extend coverage of the interface. Consider ENOSYS as a
"SKIP" test, since it is a valid configuration, but does not allow
testing the system call.
Here is an implementation of a new system call, sys_membarrier(), which
executes a memory barrier on all threads running on the system. It is
implemented by calling synchronize_sched(). It can be used to
distribute the cost of user-space memory barriers asymmetrically by
transforming pairs of memory barriers into pairs consisting of
sys_membarrier() and a compiler barrier. For synchronization primitives
that distinguish between read-side and write-side (e.g. userspace RCU
[1], rwlocks), the read-side can be accelerated significantly by moving
the bulk of the memory barrier overhead to the write-side.
The existing applications of which I am aware that would be improved by
this system call are as follows:
* Through Userspace RCU library (http://urcu.so)
- DNS server (Knot DNS) https://www.knot-dns.cz/
- Network sniffer (http://netsniff-ng.org/)
- Distributed object storage (https://sheepdog.github.io/sheepdog/)
- User-space tracing (http://lttng.org)
- Network storage system (https://www.gluster.org/)
- Virtual routers (https://events.linuxfoundation.org/sites/events/files/slides/DPDK_RCU_0MQ.pdf)
- Financial software (https://lkml.org/lkml/2015/3/23/189)
Those projects use RCU in userspace to increase read-side speed and
scalability compared to locking. Especially in the case of RCU used by
libraries, sys_membarrier can speed up the read-side by moving the bulk of
the memory barrier cost to synchronize_rcu().
* Direct users of sys_membarrier
- core dotnet garbage collector (https://github.com/dotnet/coreclr/issues/198)
Microsoft core dotnet GC developers are planning to use the mprotect()
side-effect of issuing memory barriers through IPIs as a way to implement
Windows FlushProcessWriteBuffers() on Linux. They are referring to
sys_membarrier in their github thread, specifically stating that
sys_membarrier() is what they are looking for.
To explain the benefit of this scheme, let's introduce two example threads:
Thread A (non-frequent, e.g. executing liburcu synchronize_rcu())
Thread B (frequent, e.g. executing liburcu
rcu_read_lock()/rcu_read_unlock())
In a scheme where all smp_mb() in thread A are ordering memory accesses
with respect to smp_mb() present in Thread B, we can change each
smp_mb() within Thread A into calls to sys_membarrier() and each
smp_mb() within Thread B into compiler barriers "barrier()".
Before the change, we had, for each smp_mb() pairs:
Thread A Thread B
previous mem accesses previous mem accesses
smp_mb() smp_mb()
following mem accesses following mem accesses
After the change, these pairs become:
Thread A Thread B
prev mem accesses prev mem accesses
sys_membarrier() barrier()
follow mem accesses follow mem accesses
As we can see, there are two possible scenarios: either Thread B memory
accesses do not happen concurrently with Thread A accesses (1), or they
do (2).
1) Non-concurrent Thread A vs Thread B accesses:
Thread A Thread B
prev mem accesses
sys_membarrier()
follow mem accesses
prev mem accesses
barrier()
follow mem accesses
In this case, thread B accesses will be weakly ordered. This is OK,
because at that point, thread A is not particularly interested in
ordering them with respect to its own accesses.
2) Concurrent Thread A vs Thread B accesses
Thread A Thread B
prev mem accesses prev mem accesses
sys_membarrier() barrier()
follow mem accesses follow mem accesses
In this case, thread B accesses, which are ensured to be in program
order thanks to the compiler barrier, will be "upgraded" to full
smp_mb() by synchronize_sched().
* Benchmarks
On Intel Xeon E5405 (8 cores)
(one thread is calling sys_membarrier, the other 7 threads are busy
looping)
1000 non-expedited sys_membarrier calls in 33s =3D 33 milliseconds/call.
* User-space user of this system call: Userspace RCU library
Both the signal-based and the sys_membarrier userspace RCU schemes
permit us to remove the memory barrier from the userspace RCU
rcu_read_lock() and rcu_read_unlock() primitives, thus significantly
accelerating them. These memory barriers are replaced by compiler
barriers on the read-side, and all matching memory barriers on the
write-side are turned into an invocation of a memory barrier on all
active threads in the process. By letting the kernel perform this
synchronization rather than dumbly sending a signal to every process
threads (as we currently do), we diminish the number of unnecessary wake
ups and only issue the memory barriers on active threads. Non-running
threads do not need to execute such barrier anyway, because these are
implied by the scheduler context switches.
The dynamic sys_membarrier availability check adds some overhead to
the read-side compared to the signal-based scheme, but besides that,
sys_membarrier slightly outperforms the signal-based scheme. However,
this non-expedited sys_membarrier implementation has a much slower grace
period than signal and memory barrier schemes.
Besides diminishing the number of wake-ups, one major advantage of the
membarrier system call over the signal-based scheme is that it does not
need to reserve a signal. This plays much more nicely with libraries,
and with processes injected into for tracing purposes, for which we
cannot expect that signals will be unused by the application.
An expedited version of this system call can be added later on to speed
up the grace period. Its implementation will likely depend on reading
the cpu_curr()->mm without holding each CPU's rq lock.
This patch adds the system call to x86 and to asm-generic.
[1] http://urcu.so
membarrier(2) man page:
MEMBARRIER(2) Linux Programmer's Manual MEMBARRIER(2)
NAME
membarrier - issue memory barriers on a set of threads
SYNOPSIS
#include <linux/membarrier.h>
int membarrier(int cmd, int flags);
DESCRIPTION
The cmd argument is one of the following:
MEMBARRIER_CMD_QUERY
Query the set of supported commands. It returns a bitmask of
supported commands.
MEMBARRIER_CMD_SHARED
Execute a memory barrier on all threads running on the system.
Upon return from system call, the caller thread is ensured that
all running threads have passed through a state where all memory
accesses to user-space addresses match program order between
entry to and return from the system call (non-running threads
are de facto in such a state). This covers threads from all pro=E2=80=90
cesses running on the system. This command returns 0.
The flags argument needs to be 0. For future extensions.
All memory accesses performed in program order from each targeted
thread is guaranteed to be ordered with respect to sys_membarrier(). If
we use the semantic "barrier()" to represent a compiler barrier forcing
memory accesses to be performed in program order across the barrier,
and smp_mb() to represent explicit memory barriers forcing full memory
ordering across the barrier, we have the following ordering table for
each pair of barrier(), sys_membarrier() and smp_mb():
The pair ordering is detailed as (O: ordered, X: not ordered):
barrier() smp_mb() sys_membarrier()
barrier() X X O
smp_mb() X O O
sys_membarrier() O O O
RETURN VALUE
On success, these system calls return zero. On error, -1 is returned,
and errno is set appropriately. For a given command, with flags
argument set to 0, this system call is guaranteed to always return the
same value until reboot.
ERRORS
ENOSYS System call is not implemented.
EINVAL Invalid arguments.
Linux 2015-04-15 MEMBARRIER(2)
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Nicholas Miell <nmiell@comcast.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: David Howells <dhowells@redhat.com> Cc: Pranith Kumar <bobby.prani@gmail.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
David Howells [Fri, 11 Sep 2015 20:07:36 +0000 (13:07 -0700)]
MODSIGN: fix a compilation warning in extract-cert
Fix the following warning when compiling extract-cert:
scripts/extract-cert.c: In function `write_cert':
scripts/extract-cert.c:89:2: warning: format not a string literal and no format arguments [-Wformat-security]
ERR(!i2d_X509_bio(wb, x509), cert_dst);
^
whereby the ERR() macro is taking cert_dst as the format string. "%s"
should be used as the format string as the path could contain special
characters.
Signed-off-by: David Howells <dhowells@redhat.com> Reported-by: Jim Davis <jim.epost@gmail.com>
Acked-by : David Woodhouse <david.woodhouse@intel.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull watchdog updates from Wim Van Sebroeck:
- new driver for NXP LPC18xx Watchdog Timer
- new driver for SAMA5D4 watchdog timer
- add support for MCP79 to nv_tco driver
- clean-up and improvement of the mpc8xxx watchdog driver
- improvements to gpio-wdt
- at91sam9_wdt clock improvements
... and other small fixes and improvements
* git://www.linux-watchdog.org/linux-watchdog: (25 commits)
Watchdog: Fix parent of watchdog_devices
watchdog: at91rm9200: Correct check for syscon_node_to_regmap() errors
watchdog: at91sam9: get and use slow clock
Documentation: dt: binding: atmel-sama5d4-wdt: for SAMA5D4 watchdog driver
watchdog: add a driver to support SAMA5D4 watchdog timer
watchdog: mpc8xxx: allow to compile for MPC512x
watchdog: mpc8xxx: use better error code when watchdog cannot be enabled
watchdog: mpc8xxx: use dynamic memory for device specific data
watchdog: mpc8xxx: use devm_ioremap_resource to map memory
watchdog: mpc8xxx: make use of of_device_get_match_data
watchdog: mpc8xxx: simplify registration
watchdog: mpc8xxx: remove dead code
watchdog: lpc18xx_wdt_get_timeleft() can be static
DT: watchdog: Add NXP LPC18xx Watchdog Timer binding documentation
watchdog: NXP LPC18xx Watchdog Timer Driver
watchdog: gpio-wdt: ping already at startup for always running devices
watchdog: gpio-wdt: be more strict about hw_algo matching
Documentation: watchdog: at91sam9_wdt: add clocks property
watchdog: booke_wdt: Use infrastructure to check timeout limits
watchdog: (nv_tco) add support for MCP79
...
Doing the block layer plug/unplug inside writeback_sb_inodes() is
broken, because that function is actually called with a spinlock held:
wb->list_lock, as pointed out by Chris Mason.
Chris suggested just dropping and re-taking the spinlock around the
blk_finish_plug() call (the plgging itself can happen under the
spinlock), and that would technically work, but is just disgusting.
We do something fairly similar - but not quite as disgusting because we
at least have a better reason for it - in writeback_single_inode(), so
it's not like the caller can depend on the lock being held over the
call, but in this case there just isn't any good reason for that
"release and re-take the lock" pattern.
[ In general, we should really strive to avoid the "release and retake"
pattern for locks, because in the general case it can easily cause
subtle bugs when the caller caches any state around the call that
might be invalidated by dropping the lock even just temporarily. ]
But in this case, the plugging should be easy to just move up to the
callers before the spinlock is taken, which should even improve the
effectiveness of the plug. So there is really no good reason to play
games with locking here.
I'll send off a test-patch so that Dave Chinner can verify that that
plug movement works. In the meantime this just reverts the problematic
commit and adds a comment to the function so that we hopefully don't
make this mistake again.
Reported-by: Chris Mason <clm@fb.com> Cc: Josef Bacik <jbacik@fb.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Neil Brown <neilb@suse.de> Cc: Jan Kara <jack@suse.cz> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>