Dave Chinner [Mon, 14 Oct 2013 22:17:53 +0000 (09:17 +1100)]
xfs: remove unused transaction callback variables
We don't do callbacks at transaction commit time, no do we have any
infrastructure to set up or run such callbacks, so remove the
variables and typedefs for these operations. If we ever need to add
callbacks, we can reintroduce the variables at that time.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Ben Myers <bpm@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
Dave Chinner [Mon, 14 Oct 2013 22:17:52 +0000 (09:17 +1100)]
xfs: split dquot buffer operations out
Parts of userspace want to be able to read and modify dquot buffers
(e.g. xfs_db) so we need to split out the reading and writing of
these buffers so it is easy to shared code with libxfs in userspace.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ben Myers <bpm@sgi.com>
Dave Chinner [Mon, 14 Oct 2013 22:17:51 +0000 (09:17 +1100)]
xfs: unify directory/attribute format definitions
The on-disk format definitions for the directory and attribute
structures are spread across 3 header files right now, only one of
which is dedicated to defining on-disk structures and their
manipulation (xfs_dir2_format.h). Pull all the format definitions
into a single header file - xfs_da_format.h - and switch all the
code over to point at that.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Ben Myers <bpm@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
Dave Chinner [Tue, 22 Oct 2013 23:36:05 +0000 (10:36 +1100)]
xfs: create a shared header file for format-related information
All of the buffer operations structures are needed to be exported
for xfs_db, so move them all to a common location rather than
spreading them all over the place. They are verifying the on-disk
format, so while xfs_format.h might be a good place, it is not part
of the on disk format.
Hence we need to create a new header file that we centralise these
related definitions. Start by moving the bffer operations
structures, and then also move all the other definitions that have
crept into xfs_log_format.h and xfs_format.h as there was no other
shared header file to put them in.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ben Myers <bpm@sgi.com>
Marcel Holtmann [Wed, 23 Oct 2013 15:28:01 +0000 (08:28 -0700)]
Bluetooth: Fix limited discoverable mode for Zeevo modules
There is an old Panasonic module with a Zeevo chip in there that is
not really operating according to Bluetooth core specification when
it comes to setting the IAC LAP for limited discoverable mode.
For reference, this is the vendor information about this module:
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 1.2 (0x02) - Revision 196 (0x00c4)
LMP version: Bluetooth 1.2 (0x02) - Subversion 61 (0x003d)
Manufacturer: Zeevo, Inc. (18)
The module reports only the support for one IAC at a time. And that
is totally acceptable according to the Bluetooth core specification
since the minimum supported IAC is only one.
< HCI Command: Read Number of Supported IAC (0x03|0x0038) plen 0
> HCI Event: Command Complete (0x0e) plen 5
Read Number of Supported IAC (0x03|0x0038) ncmd 1
Status: Success (0x00)
Number of IAC: 1
The problem arises when trying to program two IAC into the module
on a controller that only supports one.
< HCI Command: Write Current IAC LAP (0x03|0x003a) plen 7
Number of IAC: 2
Access code: 0x9e8b00 (Limited Inquiry)
Access code: 0x9e8b33 (General Inquiry)
> HCI Event: Command Status (0x0f) plen 4
Write Current IAC LAP (0x03|0x003a) ncmd 1
Status: Unknown HCI Command (0x01)
While this looks strange, but according to the Bluetooth core
specification it is a legal operation. The controller has to
ignore the other values and only program as many as it supports.
This command shall clear any existing IACs and stores Num_Current_IAC
and the IAC_LAPs in to the controller. If Num_Current_IAC is greater
than Num_Support_IAC then only the first Num_Support_IAC shall be
stored in the controller, and a Command Complete event with error
code Success (0x00) shall be generated.
This specific controller has a bug here and just returns an error. So
in case the number of supported IAC is less than two and the limited
discoverable mode is requested, now only the LIAC is written to
the controller.
< HCI Command: Write Current IAC LAP (0x03|0x003a) plen 4
Number of IAC: 1
Access code: 0x9e8b00 (Limited Inquiry)
> HCI Event: Command Complete (0x0e) plen 4
Write Current IAC LAP (0x03|0x003a) ncmd 1
Status: Success (0x00)
All other controllers that only support one IAC seem to handle this
perfectly fine, but this fix will only write the LIAC for these
controllers as well.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
block: Enable sysfs nomerge control for I/O requests in the plug list
This patch enables the sysfs to control I/O request merge
functionality in the plug list. While this control has been
implemented for the request queue, it was dismissed in the plug list.
Therefore, block layer merges requests together (or attempt to merge)
even if the merge capability was disable using sysfs nomerge parameter
value 2.
This limitation is directly affects functionality of io_submit()
system call. The system call enables user to submit a bunch of IO
requests from user space using struct iocb **ios input argument.
However, the unconditioned merging functionality in the plug list
potentially merges these requests together down the road. Therefore,
there is no way to distinguish between an application sending bunch of
sequential IOs and an application sending one big IO. Ultimately, all
requests generated by the former app merge within the plug list
together and looks similar to the second app.
While the merging functionality is a desirable feature to improve the
performance of IO subsystem for some applications, it is not useful
for other application like ours at all.
Hebbar, Gururaja [Wed, 23 Oct 2013 12:30:14 +0000 (15:30 +0300)]
ASoC: davinci-evm: Add device tree binding
Device tree support for Davinci Machine driver
When the board boots with device tree, the driver will receive card,
codec, dai interface details (like the card name, DAPM routing map,
phandle for the audio components described in the dts file, codec mclk
speed). The card will be set up based on this information. Since the
routing is provided via DT we can mark the card fully routed so core
can take care of disconnecting the unused pins.
Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com> Signed-off-by: Darren Etheridge <detheridge@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org>
mfd: lpc_sch: Ignore resource conflicts when adding mfd cells
Currently probe of lpc_sch fails on Intel Poulsbo because of ACPI resource
conflicts. A solution is to set the ignore_resource_conflicts flag in the mfd cells.
Tested-by: Andreas Werner <andreas.werner@men.de> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@men.de> Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: ti_am335x_tscadc: Avoid possible deadlock of reg_lock
Since the addition of continuous sampling mode and shared irq support,
the reg_lock lock can be taken with and without interrupts. This patch
uses the *_irq* variant which should be used in order to avaoid a deadlock.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Laxman Dewangan [Tue, 22 Oct 2013 07:38:46 +0000 (13:08 +0530)]
mfd: Add support for ams AS3722 PMIC
The ams AS3722 is a compact system PMU suitable for mobile phones,
tablets etc. It has 4 DC/DC step-down regulators, 3 DC/DC step-down
controller, 11 LDOs, RTC, automatic battery, temperature and
over-current monitoring, 8 GPIOs, ADC and a watchdog.
Add MFD core driver for the AS3722 to support core functionality.
Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Florian Lobmaier <florian.lobmaier@ams.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Linus Walleij [Fri, 18 Oct 2013 09:51:45 +0000 (11:51 +0200)]
mfd: tc3589x: Detect the precise version
Instead of detecting the "tc3589x" and hard-coding the number of
GPIO pins to 24, encode all the possible subtypes and set the
number of GPIO pins from the type.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Charles Keepax [Mon, 14 Oct 2013 08:09:00 +0000 (09:09 +0100)]
mfd: arizona: Mark missing AOD registers as volatile
This registers ARIZONA_AOD_WKUP_AND_TRIG and ARIZONA_AOD_IRQ_RAW_STATUS
contain interrupt status bits and thus should be volatile. They are
correctly marked on wm5102 but not on wm5110, this patch changes this.
Furthermore volatile registers don't need defaults so remove those.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Charles Keepax [Thu, 3 Oct 2013 15:16:01 +0000 (16:16 +0100)]
mfd: arizona: Correct handling of device tree gpio defaults
When setting GPIO defaults we are required to make a distinction
between writing 0x0000 to the registers and leaving them untouched.
When we receive between 0x0000 and 0xFFFF (inclusive) from either
Platform Data or Device Tree, we should write the provided
configuration to the device. Conversely, when we receive >0xFFFF we
should leave the device configuration at its default setting.
This patch fixes a bug and ensures that configuration 0x0000 isn't
mistakenly written when the intention was to keep the default one.
Reported-by: Heather Lomond <heather.lomond@wolfsonmicro.com> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Lee Jones [Fri, 27 Sep 2013 13:25:55 +0000 (14:25 +0100)]
mfd: arizona: Only attempt to parse DT if platform data was not passed
If platform data is passed when probing the device then it should take
precedence over Device Tree. This patch saves cycles in the pdata case
and prevents error messages when DT is not passed.
Reported-by: Mark Brown <broonie@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
The driver only support the device tree and sub modules are populated
through platform, the registration of sub devices through mfd_add_devices
has been removed.
Hence in remove path of the driver, it is not require to call
mfd_remove_devices.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Andrzej Hajda [Fri, 27 Sep 2013 07:27:46 +0000 (09:27 +0200)]
mfd: max77693: Added device tree support
This patch adds only of_match_table. There are no device specific
properties.
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Andrzej Hajda [Wed, 21 Aug 2013 16:53:33 +0000 (18:53 +0200)]
mfd: max77693: Remove device wakeup from driver
The patch removes wakeup related code from the driver and plaftorm
data - it is already handled by i2c core using I2C_CLIENT_WAKE flag
from struct i2c_board_info. As a result MFD itself do not requires
platform data.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Mark Brown [Mon, 23 Sep 2013 18:14:32 +0000 (19:14 +0100)]
mfd: mc13xxx: Move SPI erratum workaround into SPI I/O function
Move the workaround for double sending AUDIO_CODEC and AUDIO_DAC writes
into the SPI core, aiding refactoring to eliminate the ASoC custom I/O
functions and avoiding the extra writes for I2C.
Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
projects / karo-tx-linux.git / log