mfd: Add MAX77xxx series MFD driver

Support the MAX77686 and MAX77802, in an attempt to avoid code duplication.
It seems easier to have one driver that can be tweaked for new PMICs than
a core driver with different clients.

Base MFD support is provided along with interrupts. The RTC and regulator
will use this base driver.

Original-Change-Id: Ifd5c5efb8fcb3d931ac89dac30144473b37580a5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit-int.chromium.org/35487
Reviewed-by: Doug Anderson <dianders@google.com>
Commit-Queue: Doug Anderson <dianders@google.com>
Tested-by: Doug Anderson <dianders@google.com>
(cherry picked from peach-alpha commit
	419a7a89084e5cc626696e7cf344c8c9fd9b9f29)

BUG=chrome-os-partner:19007
TEST=Build and boot on peach-pit and snow; MFD driver probes once config
option is added.

Change-Id: I36b86a326adb55aefa0ed5142c39a3e93f8795c0
[abrestic: squashed opmode enum fix]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56567

Conflicts:
	drivers/mfd/Kconfig
rtc: Add MAX77xxx series real-time-clock driver

This driver supports MAX77686 and MAX77802.

Original-Change-Id: I09b17c4186c7f6d9a391802c39ddd34953649cd2
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit-int.chromium.org/35488
Reviewed-by: Doug Anderson <dianders@google.com>
Commit-Queue: Doug Anderson <dianders@google.com>
Tested-by: Doug Anderson <dianders@google.com>
(cherry picked from peach-alpha commit
	2e699fe95678077268e9e28be1b117c3b1b094d1)

Conflicts:
	drivers/rtc/Kconfig

BUG=chrome-os-partner:19007
TEST=Build and boot on peach-pit and snow; RTC probes once config option is
added.

Change-Id: Iaab229a53458726a6bd8b39efd2b799d9ed2c785
[abrestic: fixed trivial Kconfig conflict; squashed range-checking fix]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56568

Conflicts:
	drivers/rtc/Kconfig
regulator: Add MAX77xxx series regulator driver

This driver supports MAX77686 and MAX77802. It does not support DVS and
SELB features of these PMICs.

Original-Change-Id: I59e1b9ac733f40e22308c8c4e8738f09ee429049
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit-int.chromium.org/35507
Reviewed-by: Doug Anderson <dianders@google.com>
Commit-Queue: Doug Anderson <dianders@google.com>
Tested-by: Doug Anderson <dianders@google.com>
(cherry picked from peach-alpha commit
	15a5c42ab9646632adcb68d4692ac9d6b68a75e6)

BUG=chrome-os-partner:19007,chrome-os-partner:18697
TEST=Build and boot on peach-pit and snow.

Change-Id: I12ee38bbc9aaf4e140a6975210e0d4fe2b53bca8
[abrestic: squashed opmode fix, ramp delay fix, addition of low-jitter
mode, and voltage select mask fix]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56569
Reviewed-by: Simon Glass <sjg@chromium.org>

Conflicts:
	drivers/regulator/Kconfig
	drivers/regulator/Makefile
rtc: max77xxx: fix max77802 register map

The register map for the max77802 is missing the register numbers for
RTCYEARA2 and RTCDATEA2.  Add them.

BUG=chrome-os-partner:19793
TEST=Build and boot on peach-pit.

Change-Id: I912b9283d5a47b2d562e81c3f2f439587fb3e27e
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56890
mfd: max77xxx: use correct IRQ status and mask registers

Although the PMIC interrupt status/mask regsiters are the same for both
the max77686 and max77802, the RTC interrupt registers are different.
This moves the RTC interrupt mask and status registers out of the register
map private to the RTC driver to max77{686,802}_rtc_reg enums and adds
irq_regs and irq_mask_regs fields in struct max77xxx_dev which map from
IRQ group to IRQ status and mask regsiter, respectively.

BUG=chrome-os-partner:19793
TEST=Build and boot on peach-pit and snow.  Set an rtc alarm:
localhost ~ # echo +2 > /sys/class/rtc/rtc0/wakealarm
and (from the console output) observe that an IRQ was received:
[ 1450.054837] max77xxx-rtc max77802-rtc: max77xxx_rtc_alarm_irq:irq(11)

Change-Id: I503496ff983a23d30b3dda33dc30554a4a690840
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56891
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
mfd: max77xxx: add suspend and resume callbacks

This adds suspend and resume callbacks to the max77xxx driver which
enable and disable the max77xxx IRQ as a wakeup source, respectively.

BUG=chrome-os-partner:19793
TEST=Build and boot on peach-pit and snow.  Suspend and resume
successfully via rtcwake:
localhost ~ # rtcwake -m mem -s 10

Change-Id: I0d8578f9efe2dee00d9fe3dc4924bf40ec6bc74d
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56892
Reviewed-by: Simon Glass <sjg@chromium.org>
mfd: max77xxx: handle pending interrupts on resume

If we were woken by an interrupt from the max77xxx PMIC, it may still
need to be ACK'ed during resume otherwise future interrupts may not be
delivered.  Run the max77xxx IRQ handler during resume to ensure that
all pending interrupts have been ACK'ed.

BUG=chrome-os-partner:19793
TEST=Suspend/resume using rtcwake on peach-pit and snow; observe that
the RTC interrupt is always ACK'ed during resume.  In dmesg:
[   79.035426] max77xxx-rtc max77686-rtc: max77xxx_rtc_alarm_irq:irq(11)

Change-Id: I03f591fa0f5853517ed3f2fc53faf6f914aa1bac
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57148
Reviewed-by: Simon Glass <sjg@chromium.org>
mfd: max77xxx: Support using a nonzero DVS index for BUCKs

At the moment, the max77xxx driver doesn't support the GPIO-DVS
feature of the max77686 and max77802.  The existing code always just
assumed that the DVS and SELB lines on the PMIC were hardwired to 0.
That meant that updating the voltages invloved updating "slot 1"
(index 0) of the BUCK config registers.

One downside of using slot 1 of the PMIC is that, on all boards I've
seen including exynos5420-pit, slot 1 is automatically selected at
warm reset time.  Also on all boards that I've seen, warm reset is not
communicated to the max77xxx PMIC.  That means that if we modify slot
1 and do a warm reset we'll be running at voltages that may be lower
than the initial power on voltages of the board.  This can make it
difficult for the bootloader to come up at full speed.

There is no downside to the kernel using a different slot, so we can
be a little kinder to the bootloader by allowing the kernel to specify
a different slot to run in.

Note that this change _doesn't_ enable GPIO-DVS support: it merely
changes which default DVS slot the kernel works with.  This change
doesn't preclude someone later coming along and enabling GPIO-DVS
support if they found it useful, so long as they were aware of any
assumptions that the bootloader makes about the state of slot 1 at
warm reset time.

Note also that bindings and code are based loosely on the
max8997-regulator bindings, which actually does support DVS.

BUG=chrome-os-partner:21430
TEST=Boot up the system; seems reliable.
TEST=suspend_stress_test
TEST=Run tests as per chrome-os-partner:21341

Change-Id: I33ef19a67149e487ef993e7c8d4326c2f1d90edb
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63779
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
mfd: max77xxx: Preserve firmware voltage at bootup

In the change (ba7ece1 mfd: max77xxx: Support using a nonzero DVS
index for BUCKs) I added the feature for the kernel to use a non-zero
DVS slot.  This had the unintended side effect of ignoring the voltage
that the firmware had set the system up in--not a good idea.  Change
the regulator code to preserve the firmware's values by copying them
over to the new slot.

BUG=chrome-os-partner:21430
TEST=Manual:
Before (after a cold reset):
  dmesg | grep vdd_arm
  => [    2.632594] vdd_arm: 800 <--> 1500 mV at 1000 mV
Before (in some cases after a warm reset):
  dmesg | grep vdd_arm
  => [    2.606735] vdd_arm: 800 <--> 1500 mV at 900 mV
After (always):
  dmesg | grep vdd_arm
  => [    2.632594] vdd_arm: 800 <--> 1500 mV at 1262 mV

Change-Id: Ic7d9647912d4227c1492ca3aa10b506fcc3e41f5
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64651
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
mfd: max77xxx: correct dvs index value calculation

This patch corrects the calculation to retrive DVS index value set by
firmware. Currently, suppose firmware set index as 1, the old code
returned value 8, which is wrong.

BUG=chrome-os-partner:21687
TEST=build and booted on peach.
     /wo this patch kernel will not boot till prompt if firmware sets other
     than DVS1.
TEST=tested with other infight firmware CLs, where firmware use DVS slot2
TEST=suspend_stress_test over 20 times and multiple warmreset.
TEST=put some custom prints in driver and by chaning various DVS slot in
     firmware. can see kernel reads it right.

Change-Id: I39779bdd1f57d572411403240350598a911529fd
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65699
FIXME: avoid temporary about lock on boot

later, rever commit after resolve.
ARM: dts: exynos5410-odroidxu adding DT entries for the PMIC

Conflicts:
	arch/arm/boot/dts/exynos5410-odroidxu.dts
ARM: dts: exynos5410: add i2c and hsi2c device nodes

This adds device-tree nodes for the i2c and high-speed i2c busses
on Exynos 5410 platforms.
ARM: dts: exynos5410: Enable ehci-5p/ohci-exynos support

Add device node entry for ehci-s5p and ohci-exynos on
    exynos5410, to add support for usb 2.0
ARM: dts: exynos5410: Enabling samsung-usb2phy driver on exynos5410

Adding device tree node for Samsung-usb2phy to exynos5410
along with necessary device data to be parsed.
ARM: dts: exynos5410: Enabling samsung-usb3phy driver on exynos5410

Adding device tree node for Samsung-usb3phy on exynos5410
along with necessary device data to be parsed.
ARM: dts: exynos5410: Enable exynos-dwc3 support on exynos5410

Add device node entry for exynos-dwc3 on exynos5410,
to add support for usb 3.0.
ARM: dts: smdk5410: Enable USB support on odroid-xu

Add device node entries for usb 2.0 and usb 3.0,
in order to start using USB on odroid-xu.

Conflicts:
	arch/arm/boot/dts/exynos5410-odroidxu.dts
i2c: exynos5: add High Speed I2C controller driver

Adds support for High Speed I2C driver found in Exynos5 and
later SoCs from Samsung.

Driver only supports Device Tree method.

Changes since v1:
1. Added FIFO functionality
2. Added High speed mode functionality
3. Remove SMBUS_QUICK
4. Remove the debugfs functionality
5. Use devm_* functions where ever possible
6. Driver is free from GPIO configs (only supports pinctrl method)
7. Use OF data string "clock-frequency" to get the bus operating frequencies
8. Split the clock divisor calculation function
9. Add resets for the failed transacton cases
10. few other bug fixes and cosmetic changes

Based on v9 of the driver posted upstream:
      https://patchwork.kernel.org/patch/2581911/

BUG=chrome-os-partner:19007
TEST=i2c should be working once the config is enabled

Change-Id: I2522716ad6e52e386dab506e9d1d2119bd5715b9
Signed-off-by: Taekgyun Ko <taeggyun.ko@samsung.com>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Simon Glass <sjg@google.com>
Tested-by: Andrew Bresticker <abrestic@google.com>
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
[abrestic: squashed interruptible fix, build fix, and documentation fixes]
Signed-off-by: Andrew Bresticker <abrestic@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56216
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
i2c: exynos5: use 100khz by default in fast-mode

The Exynos 5 hsi2c driver currently uses a 1Mhz bus frequency by default
in both fast-mode and high-speed mode.  Since many peripherals, and
perhaps the hsi2c controller itself, do not support fast-mode at 1Mhz,
use 100khz by default instead.

This also fixes the documentation which incorrectly states that the default
bus frequency is 100khz in both modes.

BUG=chrome-os-partner:18993
TEST=Build and boot on peach-pit; i2c still works.

Change-Id: I6a2caf803faa55b8ab574d149ba130093576f4b2
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57080
Reviewed-by: Doug Anderson <dianders@chromium.org>