clk: exynos5410: Add in pdma clock gates

The pdma clocks had an ID but weren't listed in the clock tree.  Add
them.
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
i2c: exynos5: sepecified on clkin to use i2c-exynos5

later, this commit revert surely.
usb: misc: usb3503: Adding device tree entry 'secondary-refclk'

This patch is to add a property 'secondary-refclk' to select
the secondary REFCLK frequencies for odroid-xu.
You can select the secondary frequencies in the device tree.

usb3503@08{
	...
	secondary-refclk;
	...
};
 ARM: dts: exynos5410-odroidxu: Add usb VBUS GPIOs

Add device tree entries for the GPIO thar control USB port power on
Odroid-xu
usb: dwc3: Add vbus setup function to the exynos dwc3
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>
i2c: exynos-i2c: remove retries as i2c-core already does that

One of the comments on the upstream patch is to remove the retries
as i2c-core handles retries.
Also remove the adap class unless it is necessary.
BUG=None
TEST=booted on peach and verified i2c working properly

Change-Id: I1611cf2d999c927211744cf9a0a3c2be876bf1b2
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64201
Tested-by: naveen krishna chatradhi <naveen@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: naveen krishna chatradhi <naveen@chromium.org>
i2c: exynos-i2c: Fix transfer length calculation.

The transfer length calculation didn't consider the part that was
already transferred.  So if we split a message to fit the FIFO space,
the length used will be incorrect.

BUG=chrome-os-partner:20737
TEST=run "amixer -c 0 cset numid=31" and it does not timeout.

Change-Id: Ia045f0c9c91ba8e0e5fb8e44d7b18e5812ea811c
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64901
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
i2c: exynos5: consider bus busy as an error condition and reset

This patch makes the bus busy condition to be considered as an
error state (after 100ms interval) and resets the bus.

Also set the number of retries to 3 so that the i2c core retries
the transfer in that case.

BUG=chrome-os-partner:22834,chrome-os-partner:22837
TEST=Stress i2c bus on Pit.  For example:
  localhost ~ # while true; do i2cget -f -y 4 0x9 0x42; done
would occasionally produce i2c failures, but now it does not.

Change-Id: Id6b92998a6551cc8309ce2f42af3eea844a6a4f6
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170282
Reviewed-by: Doug Anderson <dianders@chromium.org>
i2c: exynos5: don't wait for bus to go idle after an error

If the transfer failed due to an error (e.g. timeout, no device), then
don't bother waiting for the bus to go idle - we're going to reset the
bus anyway.

Also clean up the return paths in exynos5_i2c_xfer_msg() since they're
all the same now.

BUG=chrome-os-partner:22837
TEST=i2cdetect no longer takes a long time.

Change-Id: I978c0108430c110305c7811e4efdd20e0640f5f2
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170370
Reviewed-by: Doug Anderson <dianders@chromium.org>
i2c: exynos-i2c: Fix race in clearing IRQ/signaling completion

The exynos5_i2c_irq() had a race in it where it would signal that it
was complete() and _then_ clear its IRQ.  This is not such a good idea
since the completion will effectively release control over the device.

I could confirm that this was a problem by adding a simple udelay(10)
in the driver after the complete() call.  The device wouldn't even
boot all the way.

To fix this, change the order of the complete call to avoid the race.

BUG=chrome-os-partner:22834,chrome-os-partner:22837
TEST=Try to find a place to put a delay to causes a boot crash; can't.
TEST=Stress the i2c bus by reading a lot.

Change-Id: I2b2cb1eaf5f77f14e9b8532e2fee86b31c5fa2b5
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170307
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
i2c: exynos5: Fix handling of TRANS_DONE and interrupts in general

We found that we would occasionally fail to see TRANS_DONE being set
while polling for it in exynos5_i2c_wait_bus_idle(), leading to the
theory that reading the TRANS_STATUS register at exactly the wrong
time could cause us to miss TRANS_DONE.  Instead of polling for it,
let's wait for the INT_I2C interrupt indicating the completion of
the transaction to fire.  This also requires interrupts to be enabled
before starting the transaction to ensure that we don't miss any
INT_I2C interrupts.  Because FIFO interrupts may occur before the
transaction is actually started, a spinlock is introduced which makes
enabling interrupts and starting the transfer atomic with respect to
the interrupt handler.

BUG=chrome-os-partner:22837
TEST=Insert WARNs into failure paths and see that nothing gets printed
out when stressing the i2c bus with reads and writes.

Change-Id: I2feb9ba2f99938df1db6b60ea49a7a05848a3fc6
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170556

Conflicts:
	drivers/i2c/busses/i2c-exynos5.c