This fixes below build warning if CONFIG_OF is not set.
CC drivers/mfd/max77686.o
drivers/mfd/max77686.c:37:42: warning: 'max77686_pmic_dt_match' defined but not used [-Wunused-variable]
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This patch adds device tree support for mfd driver and adds
Documentation/devicetree/bindings/mfd/max77686.txt.
This patch also intialize max77686 pointer to NULL in max77686_i2c_probe
to silent a compile time warning.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Presently driver expects irq_gpio pin in platform data and maps it to irq
itself. But we can also directly specify the interrupt in DT or platform file.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
According to TRM, though we mask the interrupts in interrupt-mask register,
interrupt source-register still provide the status of the masked interrupts.
So we should apply irq_mask_cur to read interrupt source-register value before
handling.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
PMIC's regmap should be used to read pmic interrupt registers.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
device_init_wakeup uses the dev_name() of the device to set the
name of the wakeup_source which appears in
/sys/kernel/debug/wakeup_sources.
For a platform device, that name is not set until platform_device_add
calls dev_set_name.
So the call to device_init_wakeup() must be after the call to
platform_device_add().
Making this change causes correct names to appear in the
wakeup_sources file.
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
in hw design, 800 is mainly for pmic control, while 805 for audio.
but there are 3 registers which controls class D speaker property,
and they are defined in 800 i2c client domain. so 805 codec driver
needs to use 800 i2c client to access class D speaker reg for
audio path management. so add this workaround for the purpose to
let 805 access 800 i2c in some scenario.
Signed-off-by: Qiao Zhou <zhouqiao@marvell.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
88PM800 and 88PM805 are two discrete chips used for power management.
Hardware designer can use them together or only one of them according
to requirement.
88pm80x.c provides common i2c driver handling for both 800 and
805, such as i2c_driver init, regmap init, read/write api etc.
88pm800.c handles specifically for 800, such as chip init, irq
init/handle, mfd device register, including rtc, onkey, regulator(
to be add later) etc. besides that, 800 has three i2c device, one
regular i2c client, two other i2c dummy for gpadc and power purpose.
88pm805.c handles specifically for 805, such as chip init, irq
init/handle, mfd device register, including codec, headset/mic detect
etc.
the i2c operation of both 800 and 805 are via regmap, and 88pm80x-i2c
exported a group of r/w bulk r/w and bits set API for facility.
Signed-off-by: Qiao Zhou <zhouqiao@marvell.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The core and irq Arizona parts should be boolean as they depend on non
exported symbols.
This fixes the following build errors:
ERROR: "wm5102_aod" [drivers/mfd/arizona-irq.ko] undefined!
ERROR: "wm5102_irq" [drivers/mfd/arizona-irq.ko] undefined!
ERROR: "irq_set_chip_and_handler_name" [drivers/mfd/arizona-irq.ko] undefined!
ERROR: "wm5102_patch" [drivers/mfd/arizona-core.ko] undefined!
ERROR: "arizona_irq_init" [drivers/mfd/arizona-core.ko] undefined!
ERROR: "arizona_irq_exit" [drivers/mfd/arizona-core.ko] undefined!
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Now we have regcache sync region we can use it to do a more efficient
sync of the pin configuration after we reset the device during suspend.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Rather than open coding the enable GPIO control in the MFD core use the
API to push the management on to the regulator driver. The immediate
advantage is slight for most systems but this will in future allow device
configurations where an external regulator is used for DCVDD.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
mfd: Initial support for Wolfson Arizona platform and WM5102 devices
The Wolfson Arizona platform is used to provide common register
interface to a series of low power audio hub CODECs, starting with the
WM5102. Since the features of these devices work over a range of
subsystems an MFD core driver is provided to instantiate the subdevices
and arbitrate access between them.
As the new regmap wake IRQ functionality is used as part of the driver
it is incorporated as a dependency.
During conversion to regmap_irq this hunk was missing being moved
to MFD driver to put the chip into clear on read mode. Also as slave
is now set use it to determine which slave for the register call.
Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Due to a merge error the section of code passing the pdata for the
regulator driver to the mfd_add_devices via the children structure
was missing. This corrects this problem.
Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
an issue where the ULPI PHYs were not held in reset while initializing
the EHCI controller. However, it also changes behavior in
omap-usb-host.c omap_usbhs_init by releasing reset while the
configuration in that function was done.
This change caused a regression on BB-xM where USB would not function
if 'usb start' had been run from u-boot before booting. A change was
made to release reset a little bit earlier which fixed the issue on
BB-xM and did not cause any regressions on 3430 sdp, the board for
which the fix was originally made.
This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
before adding hcd.', (3aa2ae74) caused a regression on OMAP5.
The original fix to hold the EHCI controller in reset during
initialization was correct, however it appears that changing
omap_usbhs_init to not hold the PHYs in reset during it's
configuration was incorrect. This patch first reverts both fixes, and
then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
reset as the original patch had done. It also is sure to incorporate
the _cansleep change that has been made in the meantime.
I've tested this on Beagleboard xM, I'd really like to get an ack from
the 3430 sdp and OMAP5 guys before getting this merged.
v3 - Brown paper bag its too early in the morning actually run
git commit amend fix
v2 - Put cansleep gpiolib call outside of spinlock
Acked-by: Mantesh Sarashetti <mantesh@ti.com>
Tested-by: Mantesh Sarashetti <mantesh@ti.com>
Acked-by: Keshava Munegowda <keshava_mgowda@ti.com>
Tested-by: Keshava Munegowda <keshava_mgowda@ti.com>
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Axel Lin
Mark Brown
Samuel Ortiz
Yadwinder Singh Brar
NeilBrown
Qiao Zhou
Graeme Gregory
Russ Dill