| Age | Commit message (Collapse) | Author |
|---|
|
The Roland Quad/Octo-Capture devices use some unknown vendor-specific
mechanism to switch sample rates (and to manage other controls). To
prevent the driver from attempting to use any other than the default
44.1 kHz sample rate, use quirks to hide the other alternate settings.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
|
snd_card_register() registers all devices newly added since the last
call. However, the playback/capture streams are handled as one ALSA
device, so the second /dev device will not be registered if the PCM
streams are added in two steps.
QUIRK_AUTODETECT caused the probe callback to be called once for each
interface, which triggered this problem. Work around this by handling
this like the composite quirk, i.e., autodetecting all other interfaces
that might be used for PCM or MIDI.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
|
Remove all quirks that are no longer needed now that the generic Roland
quirks can handle the vendor-specific descriptors correctly.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
|
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
|
Add quirks to detect the various vendor-specific descriptors used by
Roland and Yamaha in most of their recent USB audio and MIDI devices.
Together with the previous patch, this should add audio/MIDI support for
the following USB devices:
- Edirol motion dive .tokyo performance package
- Roland MC-808 Synthesizer
- Roland BK-7m Synthesizer
- Roland VIMA JM-5/8 Synthesizer
- Roland SP-555 Sequencer
- Roland V-Synth GT Synthesizer
- Roland Music Atelier AT-75/100/300/350C/500/800/900/900C Organ
- Edirol V-Mixer M-200i/300/380/400/480/R-1000
- BOSS GT-10B Effects Processor
- Roland Fantom G6/G7/G8 Keyboard
- Cakewalk Sonar V-Studio 20/100/700 Audio Interface
- Roland GW-8 Keyboard
- Roland AX-Synth Keyboard
- Roland JUNO-Di/STAGE/Gi Keyboard
- Roland VB-99 Effects Processor
- Cakewalk UM-2G MIDI Interface
- Roland A-500S Keyboard
- Roland SD-50 Synthesizer
- Roland OCTAPAD SPD-30 Controller
- Roland Lucina AX-09 Synthesizer
- BOSS BR-800 Digital Recorder
- Roland DUO/TRI-CAPTURE (EX) Audio Interface
- BOSS RC-300 Loop Station
- Roland JUPITER-50/80 Keyboard
- Roland R-26 Recorder
- Roland SPD-SX Controller
- BOSS JS-10 Audio Player
- Roland TD-11/15/30 Drum Module
- Roland A-49/88 Keyboard
- Roland INTEGRA-7 Synthesizer
- Roland R-88 Recorder
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
|
All the Roland/Edirol/BOSS USB audio devices that need implicit feedback
show this unambiguously in their descriptors, so it might be a good idea
to let the driver detect this.
This should make playback work correctly (at least with Jack) with the
following devices:
- BOSS GT-100
- BOSS JS-8 Jam Station
- Edirol M-16DX
- Roland GAIA SH-01
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
|
Instead of reading bInterfaceProtocol from the descriptor whenever it's
needed, store this value in the audioformat structure. Besides
simplifying some code, this will allow us to correctly handle vendor-
specific devices where the descriptors are marked with other values.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
|
Commits fcf8058 (cpufreq: Simplify cpufreq_add_dev()) and aa77a52
(cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init())
changed the contents of the "related_cpus" sysfs attribute on systems
where acpi-cpufreq is used and user space can't get the list of CPUs
which are in the same hardware coordination CPU domain (provided by
the ACPI AML method _PSD) via "related_cpus" any more.
To make up for that loss add a new sysfs attribute "freqdomian_cpus"
for the acpi-cpufreq driver which exposes the list of CPUs in the
same domain regardless of whether it is coordinated by hardware or
software.
[rjw: Changelog, documentation]
References: https://bugzilla.kernel.org/show_bug.cgi?id=58761
Reported-by: Jean-Philippe Halimi <jean-philippe.halimi@exascale-computing.eu>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Whenever we are changing frequency of a cpu, we are calling PRECHANGE and
POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE
shouldn't be called twice contiguously.
This can happen due to bugs in users of __cpufreq_driver_target() or actual
cpufreq drivers who are sending these notifiers.
This patch adds some protection against this. Now, we keep track of the last
transaction and see if something went wrong.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* pm-cpufreq-arm:
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c2416: fix forgotten driver_data conversions
|
|
* pm-cpufreq-assorted: (21 commits)
cpufreq: powernow-k8: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: pcc: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: e_powersaver: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: ACPI: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: make __cpufreq_notify_transition() static
cpufreq: Fix minor formatting issues
cpufreq: Fix governor start/stop race condition
cpufreq: Simplify userspace governor
cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
cpufreq: kirkwood: Select CPU_FREQ_TABLE option
cpufreq: big.LITTLE needs cpufreq table
cpufreq: SPEAr needs cpufreq table
cpufreq: powerpc: Add cpufreq driver for Freescale e500mc SoCs
cpufreq: remove unnecessary cpufreq_cpu_{get|put}() calls
cpufreq: MAINTAINERS: Add git tree path for ARM specific updates
cpufreq: rename index as driver_data in cpufreq_frequency_table
cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
cpufreq: Move get_cpu_idle_time() to cpufreq.c
cpufreq: governors: Move get_governor_parent_kobj() to cpufreq.c
cpufreq: Add EXPORT_SYMBOL_GPL for have_governor_per_policy
...
|
|
* pm-cpufreq-Kconfig:
cpufreq: X86_AMD_FREQ_SENSITIVITY: select CPU_FREQ_TABLE
cpufreq: tegra: create CONFIG_ARM_TEGRA_CPUFREQ
cpufreq: S3C2416/S3C64XX: select CPU_FREQ_TABLE
cpufreq: pxa: select CPU_FREQ_TABLE
cpufreq: powerpc: CBE_RAS: select CPU_FREQ_TABLE
cpufreq: imx: select CPU_FREQ_TABLE
cpufreq: highbank: remove select CPU_FREQ_TABLE
cpufreq: exynos: select CPU_FREQ_TABLE
cpufreq: davinci: select CPU_FREQ_TABLE
cpufreq: cris: select CPU_FREQ_TABLE
cpufreq: blackfin: enable driver for CONFIG_BFIN_CPU_FREQ
|
|
ACPI Timer() opcode should return monotonically increasing clock with 100ns
granularity according the ACPI 5.0 spec.
Testing the current Timer() implementation with following ASL code (and an
additional debug print in acpi_os_sleep() to get the sleep times dumped out
to dmesg):
// Test: 10ms
Store(Timer, Local1)
Sleep(10)
Divide(Subtract(Timer, Local1), 10000,, Local1)
Sleep(Local1)
// Test: 200ms
Store(Timer, Local1)
Sleep(200)
Divide(Subtract(Timer, Local1), 10000,, Local1)
Sleep(Local1)
// Test 1300ms
Store(Timer, Local1)
Sleep(1300)
Divide(Subtract(Timer, Local1), 10000,, Local1)
Sleep(Local1)
The second sleep value is calculated using Timer(). If the implementation
is good enough we should be able to get the second value pretty close to
the first.
However, the current Timer() gives pretty bad sleep times:
[ 11.488100] ACPI: acpi_os_get_timer() TBD
[ 11.492150] ACPI: Sleep(10)
[ 11.502993] ACPI: Sleep(0)
[ 11.506315] ACPI: Sleep(200)
[ 11.706237] ACPI: Sleep(0)
[ 11.709550] ACPI: Sleep(1300)
[ 13.008929] ACPI: Sleep(0)
Fix this with the help of ktime_get(). Once the fix is applied and run
against the same ASL code we get:
[ 11.486786] ACPI: Sleep(10)
[ 11.499029] ACPI: Sleep(12)
[ 11.512350] ACPI: Sleep(200)
[ 11.712282] ACPI: Sleep(200)
[ 11.912170] ACPI: Sleep(1300)
[ 13.211577] ACPI: Sleep(1300)
That is much more closer to the values we expected.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's
_REG method will access that region. To allow the CMOS RTC region
handler to be installed before the EC _REG method is first invoked,
add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table.
References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
On HP Folio 13-2000, the BIOS defines a CMOS RTC Operation Region and
the EC's _REG methord accesses that region. Thus an appropriate
address space handler must be registered for that region before the
EC driver is loaded.
Introduce a mechanism for adding CMOS RTC address space handlers.
Register an ACPI scan handler for CMOS RTC devices such that, when
a device of that kind is detected during an ACPI namespace scan, a
common CMOS RTC operation region address space handler will be
installed for it.
References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Replace the use of buffer based logging of inode initialisation,
uses the new logical form to describe the range to be initialised
in recovery. We continue to "log" the inode buffers to push them
into the AIL and ensure that the inode create transaction is not
removed from the log before the inode buffers are written to disk.
Update the transaction identifier and reservations to match the
changed implementation.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
When we find a icreate transaction, we need to get and initialise
the buffers in the range that has been passed. Extract and verify
the information in the item record, then loop over the range
initialising and issuing the buffer writes delayed.
Support an arbitrary size range to initialise so that in
future when we allocate inodes in much larger chunks all kernels
that understand this transaction can still recover them.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
Define the log and space transaction sizes. Factor the current
create log reservation macro into the two logical halves and reuse
one half for the new icreate transactions. The icreate transaction
is transparent to all the high level create code - the
pre-calculated reservations will correctly set the reservations
dependent on whether the filesystem supports the icreate
transaction.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
Introduce the inode create log item type for logical inode create logging.
Instead of logging the changes in buffers, pass the range to be
initialised through the log by a new transaction type. This reduces
the amount of log space required to record initialisation during
allocation from about 128 bytes per inode to a small fixed amount
per inode extent to be initialised.
This requires a new log item type to track it through the log
and the AIL. This is a relatively simple item - most callbacks are
noops as this item has the same life cycle as the transaction.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
If we have a buffer that we have modified but we do not wish to
physically log in a transaction (e.g. we've logged a logical
change), we still need to ensure that transactional integrity is
maintained. Hence we must not move the tail of the log past the
transaction that the buffer is associated with before the buffer is
written to disk.
This means these special buffers still need to be included in the
transaction and added to the AIL just like a normal buffer, but we
do not want the modifications to the buffer written into the
transaction. IOWs, what we want is an "ordered buffer" that
maintains the same transactional life cycle as a physically logged
buffer, just without the transcribing of the modifications to the
log.
Hence we need to flag the buffer as an "ordered buffer" to avoid
including it in vector size calculations or formatting during the
transaction. Once the transaction is committed, the buffer appears
for all intents to be the same as a physically logged buffer as it
transitions through the log and AIL.
Relogging will also work just fine for such an ordered buffer - the
logical transaction will be replayed before the subsequent
modifications that relog the buffer, so everything will be
reconstructed correctly by recovery.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
And "ordered log vector" is a log vector that is used for
tracking a log item through the CIL and into the AIL as part of the
log checkpointing. These ordered log vectors are special in that
they are not written to to journal in any way, and are not accounted
to the checkpoint being written.
The reason for this behaviour is to allow operations to attach items
to transactions and have them follow the normal transactional
lifecycle without actually having to write them to the journal. This
allows logging of items that track high level logical changes and
writing them to the log, while the physical items being modified
pass through into the AIL and pin the tail of the log (and therefore
the logical item in the log) until all the modified items are
physically written to disk.
IOWs, it allows us to write metadata without physically logging
every individual change but still maintain the full transactional
integrity guarantees we currently have w.r.t. crash recovery.
This change modifies some of the CIL item insertion loops, as
ordered log vectors introduce some new constraints as they don't
track any data. One advantage of this change is that it combines
two log vector chain walks into a single pass, so there is less
overhead in the transaction commit pass as well. It also kills some
unused code in the log vector walk loop when committing the CIL.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
Long ago, bulkstat used to read inodes directly from the backing
buffer for speed. This had the unfortunate problem of being cache
incoherent with unlinks, and so xfs_ifree() had to mark the inode
as free directly in the backing buffer. bulkstat was changed some
time ago to use inode cache coherent lookups, and so will never see
unlinked inodes in it's lookups. Hence xfs_ifree() does not need to
touch the inode backing buffer anymore.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
When we are allocating a new inode, we read the inode cluster off
disk to increment the generation number. We are already using a
random generation number for newly allocated inodes, so if we are not
using the ikeep mode, we can just generate a new generation number
when we initialise the newly allocated inode.
This avoids the need for reading the inode buffer during inode
creation. This will speed up allocation of inodes in cold, partially
allocated clusters as they will no longer need to be read from disk
during allocation. It will also reduce the CPU overhead of inode
allocation by not having the process the buffer read, even on cache
hits.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
Dedicated small file workloads have been seeing significant free
space fragmentation causing premature inode allocation failure
when large inode sizes are in use. A particular test case showed
that a workload that runs to a real ENOSPC on 256 byte inodes would
fail inode allocation with ENOSPC about about 80% full with 512 byte
inodes, and at about 50% full with 1024 byte inodes.
The same workload, when run with -o allocsize=4096 on 1024 byte
inodes would run to being 100% full before giving ENOSPC. That is,
no freespace fragmentation at all.
The issue was caused by the specific IO pattern the application had
- the framework it was using did not support direct IO, and so it
was emulating it by using fadvise(DONT_NEED). The result was that
the data was getting written back before the speculative prealloc
had been trimmed from memory by the close(), and so small single
block files were being allocated with 2 blocks, and then having one
truncated away. The result was lots of small 4k free space extents,
and hence each new 8k allocation would take another 8k from
contiguous free space and turn it into 4k of allocated space and 4k
of free space.
Hence inode allocation, which requires contiguous, aligned
allocation of 16k (256 byte inodes), 32k (512 byte inodes) or 64k
(1024 byte inodes) can fail to find sufficiently large freespace and
hence fail while there is still lots of free space available.
There's a simple fix for this, and one that has precendence in the
allocator code already - don't do speculative allocation unless the
size of the file is larger than a certain size. In this case, that
size is the minimum default preallocation size:
mp->m_writeio_blocks. And to keep with the concept of being nice to
people when the files are still relatively small, cap the prealloc
to mp->m_writeio_blocks until the file goes over a stripe unit is
size, at which point we'll fall back to the current behaviour based
on the last extent size.
This will effectively turn off speculative prealloc for very small
files, keep preallocation low for small files, and behave as it
currently does for any file larger than a stripe unit. This
completely avoids the freespace fragmentation problem this
particular IO pattern was causing.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
Similar to bulkstat inode chunk readahead, we need to plug directory
data buffer readahead during getdents to ensure that we can merge
adjacent readahead requests and sort out of order requests optimally
before they are dispatched. This improves the readahead efficiency
and reduces the IO load it generates as the IO patterns are
significantly better for both contiguous and fragmented directories.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
I was running some tests on bulkstat on CRC enabled filesystems when
I noticed that all the IO being issued was 8k in size, regardless of
the fact taht we are issuing sequential 8k buffers for inodes
clusters. The IO size should be 16k for 256 byte inodes, and 32k for
512 byte inodes, but this wasn't happening.
blktrace showed that there was an explict plug and unplug happening
around each readahead IO from _xfs_buf_ioapply, and the unplug was
causing the IO to be issued immediately. Hence no opportunity was
being given to the elevator to merge adjacent readahead requests and
dispatch them as a single IO.
Add plugging around the inode chunk readahead dispatch loop in
bulkstat to ensure that we don't unplug the queue between adjacent
inode buffer readahead IOs and so we get fewer, larger IO requests
hitting the storage subsystem for bulkstat.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
NCT6775 does not support alarms for fans 4 and 5. Drop the attributes.
cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Driver displays wrong alarms for temperature attributes.
Turns out that temperature alarm bits are not fixed, but determined
by temperature source mapping. To fix the problem, walk through
the temperature sources to determine the correct alarm bit associated
with a given attribute.
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
GMT G762/763 fan speed PWM controller is connected directly to a fan
and performs closed-loop or open-loop control of the fan speed. Two
modes - PWM or DC - are supported by the chip. Introduced driver
provides various knobs to control the operations of the chip (via
sysfs interface). Specific characteristics of the system can be passed
either using board init code or via DT. Documentation for both the
driver and DT bindings are also provided.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Adding another way that is device tree to pass the shunt resistor
value to driver except for platform data.
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
[Guenter Roeck: Added missing of.h include]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Replace some written information with tables to improve readability
and to simplify adding newer devices in the future.
Signed-off-by: Robert Coulson <rob.coulson@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
These changes add DS1731 chip support to the ds1621 driver,
Kconfig, and documentation.
Signed-off-by: Robert Coulson <rob.coulson@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
This helps the kernel to find the right module once the device is
created.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
LM84 does not support minimum temperature registers.
Only create the respective sysfs attributes for other chips.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
|
|
Due to a lack of device and vendor identification registers, the
Dallas/Maxim DS16xx devices cannot be uniquely detected, sometimes
resulting in false positives. Therefore, the detect function is
being removed in favor of explicit device instantiation.
Signed-off-by: Robert Coulson <rob.coulson@gmail.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Add definitions, information, and code for ds1631 chip support
to the ds1621 driver.
Signed-off-by: Robert Coulson <rob.coulson@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
The ds1721 device can be configured for 9..12 bit resolutions;
add a sysfs attribute for userspace to configure this attribute.
The definition, description, details, and usage are shown in the
documentation and were crafted from an LM73 driver patch done by
Chris Verges & Guenter Roeck).
Signed-off-by: Robert Coulson <rob.coulson@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Update the ds1621 documentation, driver, and Kconfig with
ds1721 chip support.
Signed-off-by: Robert Coulson <rob.coulson@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
If a GFS2 file system is mounted with quotas and a file is grown
in such a way that its free blocks for the allocation are represented
in a secondary bitmap, GFS2 ran out of blocks in the transaction.
That resulted in "fatal: assertion "tr->tr_num_buf <= tr->tr_blocks".
This patch reserves extra blocks for the quota change so the
transaction has enough space.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/late
From Sekhar Nori:
Device Tree updates for DaVinci
This patch set updates da850 DTS files to enable use of
C pre-processor. Also updates pinctrl-single DT data
to go with changes done in that module to enable a
single register to service configuration of multiple
pins.
* tag 'davinci-for-v3.11/dt' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
ARM: davinci: da850: adopt to pinctrl-single change for configuring multiple pins
ARM: davinci: da850: Use #include for all device trees
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Use standard PM state macros PCI_Dx instead of numeric 0/1/2..
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
next/fixes-non-critical
From Nicolas Ferre:
Several fixes for:
- external irq on non-DT boards
- cpuidle code in some circumstances
- PMC code in relation with PLLB/PLL_UTMI/USB:
mainly for SAMA5D3 and AT91SAM9N12
* tag 'at91-fixes' of git://github.com/at91linux/linux-at91:
ARM: at91/PMC: use at91_usb_rate() for UTMI PLL
ARM: at91/PMC: fix at91sam9n12 USB FS init
ARM: at91/PMC: at91sam9n12 family has a PLLB
ARM: at91/PMC: sama5d3 family doesn't have a PLLB
ARM: at91: cpuidle: Fix target_residency
ARM: at91: fix at91_extern_irq usage for non-dt boards
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This makes the l2x0 initialization fail gracefully on non-ux500
systems.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Sending the right snapshot context with each write is required for
snapshots to work. Due to the ordering of calls, the snapshot context
is never set for any requests. This causes writes to the current
version of the image to be reflected in all snapshots, which are
supposed to be read-only.
This happens because rbd_osd_req_format_write() sets the snapshot
context based on obj_request->img_request. At this point, however,
obj_request->img_request has not been set yet, to the snapshot context
is set to NULL. Fix this by moving rbd_img_obj_request_add(), which
sets obj_request->img_request, before the osd request formatting
calls.
This resolves:
http://tracker.ceph.com/issues/5465
Reported-by: Karol Jurak <karol.jurak@gmail.com>
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>
|
|
Select PINCTRL_TZ1090_PDC from SOC_TZ1090 to enable the PDC pin
controller driver once it is merged, and instantiate it from
tz1090.dtsi.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
|
|
Select PINCTRL and PINCTRL_TZ1090 from SOC_TZ1090 to enable the main pin
controller driver once it is merged, and instantiate it from
tz1090.dtsi.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
|
|
The cache configuration of the boot cpu is now duplicated to secondary
cpus, so there's no need to check for cache aliasing again when a
secondary cpu is booted. Therefore remove the check from
secondary_start_kernel().
Signed-off-by: James Hogan <james.hogan@imgtec.com>
|
|
If the cache and page size configuration allows for cache aliasing to
occur we warn on boot, but the log messages are easy to miss and will
result is random crashes occuring in userland. Let's panic too in this
case so that the user immediately knows they need to fix the cache
configuration or configured page size.
Also fix the warning messages which display the cache and page sizes to
include newlines, and add the word "Potential" since an actual cache
alias hasn't been detected.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
|
|
Include *.dtsi files from *.dts using the preprocessor to set a good
example for future device tree files. Files included in the old way
don't get pre-processed.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Cc: devicetree-discuss@lists.ozlabs.org
|
|
Add symlink to include/dt-bindings from arch/metag/boot/dts/include/ to
match the one in arch/arm/... (see the commit below) so that
preprocessed device tree files can include various useful constant
definitions.
Commit c58299aa87544a590c62bda0bf52b69fa56cb8d5 ("kbuild: create an
"include chroot" for DT bindings") merged in v3.10-rc1.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: linux-kbuild@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
|
