Exposing i2c_mutex to the userland to be consumed by the HDCP driver.

BUG=chrome-os-partner:18028
TEST=Tested by acquiring gmbus mutex for 2ms every 2s and observing
the impact to touchpad. @bleung and @adlr signed off after the
investigation.

Change-Id: I739bab98266a0068063792d9884e2f24287d2d1e
Signed-off-by: Gediminas Ramanauskas <gedis@chromium.org>
Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/44101
Reviewed-by: Jay Kim <yongjaek@chromium.org>
Tested-by: Jay Kim <yongjaek@chromium.org>
CHROMIUM: ASoC: max98088 - fix element type of the register cache.

The registers of max98088 are 8 bits, not 16 bits. This bug causes the
contents of registers to be overwritten with bad values when the codec
is suspended and then resumed.

BUG=chrome-os-partner:20335
TEST=suspend and resume, and the audio continues to play

Change-Id: I4a0a25dde3dbda479766f9718b95f809f73adb78
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59754
Reviewed-by: Dylan Reid <dgreid@chromium.org>
UPSTREAM: ARM: 7513/1: Make sure dtc is built before running it

'make dtbs' in a clean tree will try running the dtc before actually
building it.  Make these rules depend upon the scripts to build it.

BUG=chromium:253588
TEST=With clean and dirty tree try building dtbs in parallel with the
rest of the kernel.

Change-Id: I5316f0a9619977f2efee6d6ce3296f89609d59f6
Cc: <stable@vger.kernel.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Doug Anderson <dianders@chromium.org>
(cherry picked from commit 70b0476a2394de4f4e32e0b67288d80ff71ca963)
Reviewed-on: https://gerrit.chromium.org/gerrit/59804
Reviewed-by: Mike Frysinger <vapier@chromium.org>
ARM: Fix dtb dependency to use order-only prerequisites

The %.dtb dependency is specified to depend on the PHONY "scripts".
That means that it'll build every time even if the underlying dtb file
hasn't been touched.  Use an order-only prerequisites to fix this.
Also mark "dtbs" as PHONY for correctness.

This was broken in (70b0476 ARM: 7513/1: Make sure dtc is built before
running it).

BUG=chromium:253588
TEST=manually 'make exynos5250-snow.dtb' and see:
  make[2]: `arch/arm/boot/exynos5250-snow.dtb' is up to date.
TEST=touch 'arch/arm/boot/dts/exynos5250-snow.dts' and repeat.  See:
  DTC     arch/arm/boot/exynos5250-snow.dtb
TEST=manually 'make dtbs' and see that it still works.

This has been posted upstream:
  https://patchwork.kernel.org/patch/2773591/

Change-Id: I4b0fe2c7551c5774ba348c53fd437c978ed6cfcf
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59822
Reviewed-by: Mike Frysinger <vapier@chromium.org>
CHROMIUM: config: Renormalize splitconfig

Ran ./chromeos/scripts/kernelconfig oldconfig and hit return for
inquiries.

Signed-off-by: Todd Broch <tbroch@chromium.org>

BUG=None
TEST=Compiled and booted on one device.

Change-Id: I91250e120a5c63f9947cb00871482db9b1220e21
Reviewed-on: https://gerrit.chromium.org/gerrit/59931
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
CHROMIUM: config: governor: Set desired governor at boot.

Exynos based platforms boot with ondemand governor and then transition
to interactive governor once laptop-mode tools is launched.

While there's nothing particularly bad about that its unnecessary and
poses some trickiness for managing cpufreq outside of laptop-mode tools.

Changing to desired governor at boot will allow us to disable that
portion of laptop-mode tools:

  /etc/laptop-mode/conf.d/cpufreq.conf
  CONTROL_CPU_FREQUENCY=0

CL modifies default governor for Exynos platforms to interactive
while leaving others on ondemand.

Signed-off-by: Todd Broch <tbroch@chromium.org>

BUG=chrome-os-partner:18927
TEST=manual,
1. build kernel on x86 & exynos

2. On Exynos based platforms see
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor is interactive
even with laptop-mode disabled (as described above).

Change-Id: I9818225945ee530af2296012ddc912855365ca84
Reviewed-on: https://gerrit.chromium.org/gerrit/59702
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
CHROMIUM: power: Publish additional charger properties.

The host command to EC, EC_CMD_POWER_INFO, provides additional charger
related info which can be useful.  For example in developer mode its
exposed via ectool powerinfo

     AC Voltage: 5230 mV
     System Voltage: 11521 mV
     System Current: 451 mA
     System Power: 5195 mW
     USB Device Type: 0x20010
     USB Current Limit: 348 mA

Currently the kernel driver only interprets the USB Device Type.  By
publishing system values (voltage, current & power) userland daemons
can better understand power usage.  For example,

  tot_ua=$(cat /sys/class/power_supply/cros_ec-charger/current_now)
  bat_ua=$(cat /sys/class/power_supply/sbs-6-000b/current_now)
  sys_ua=$(( $tot_ua - $bat_ua ))

where:
  bat_ua: current, in uamps, that is devoted to charging
  tot_ua: current, in uamps, of the complete system
  sys_ua: current, in uamps, that is being consumed by system
          (excluding charging)

Change adds voltage, current and power properties.  The values are
returned when AC is detected ... zero otherwise.

Signed-off-by: Todd Broch <tbroch@chromium.org>

BUG=chrome-os-partner:19442
TEST=manual,
1. Compare results of ectool powerinfo to
   /sys/class/power_supply_cros_ec-charger/<property>
2. Verify sys/class/power_supply_cros_ec-charger/<property> goto zero
   in absence of AC

Change-Id: I8aff8e5fa102cd54d9f729622221e3c10583314e
Reviewed-on: https://gerrit.chromium.org/gerrit/60137
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Daniel Erat <derat@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
cpufreq: exynos: allow to set default maximum frequency from device tree

When the cpu node in the device tree has the "clock-frequency-limit" attribute
set, the cpufreq policy maximum frequency is set to the given frequency
value.
This allows the firmware to give a hint about what is the acceptable
operating range to avoid exceeding the available power envelope.
The setting can be reset from userspace by using the cpufreq sysfs
interface.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chrome-os-partner:18927
TEST=on Spring, run with a firmware passing clock-frequency-limit=800000 in
the device tree, and see the "Capping CPU0 frequency to 800 Mhz" trace
in the kernel log and the CPU frequency not going higher than 800Mhz
after startup.

Change-Id: I89a40b977ad56c05ce53d47baa8d78da0cf3c5c3
Reviewed-on: https://gerrit.chromium.org/gerrit/55790
Commit-Queue: Todd Broch <tbroch@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
CHROMIUM: drm/anx7808: Set infoframes at startup.

Evidently the interrupt bit for new packets is not necessarily set at startup.
Copy infoframes downstream once anyway.

BUG=chrome-os-partner:19909, chrome-os-partner:19999
TEST=Manually see that Coby and Dell monitors come up more quickly and more
reliably than before.

Change-Id: I7f376c4f9817088df0b2d5867e60aa11b1a03d52
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60355
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: power: sbs: Add detail to battery reg read failure warning

I just saw this message in /var/log/messages:
kernel: [13504.789422] Failed to read word data

That message isn't very helpful...
Luckily git grep could find that string, so I know who to blame :)

Let's give this message some context (use dev_warn) and add a bit more
detail in case someone needs to debug such an error some day.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chromium:255441,chrome-os-partner:10617
TEST=Disconnect battery and see detailed kernel warnings

Change-Id: I13fbff624002c9449252f8ba309e0007aacb4c69
Reviewed-on: https://gerrit.chromium.org/gerrit/60337
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: iommu/exynos: add missing cache flush for removed pagetable entries

This commit adds cache flush for removed small page and large page
entries in exynos_iommu_unmap(). Missing cache flush of removed
page table entries can cause missing page fault interrupt when a
master IP accesses an unmapped area.

[ patch posted 12/26/2012 but not accepted/applied upstream:
    https://patchwork.kernel.org/patch/1910401/
]

BUG=chromium:219207
TEST=build/boot.

Change-Id: I5a3a91c0df667a5044d1155933749189ff3439ba
Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60565
Reviewed-by: Doug Anderson <dianders@chromium.org>
FIXUP: iommu/exynos: Add iommu driver for Exynos Platforms

Exynos driver landed upstream as:
  2a96536 iommu/exynos: Add iommu driver for EXYNOS Platforms
...and in our tree as:
  08ab20c iommu/exynos: Add iommu driver for Exynos Platforms

3.8 kernel sysmmu_block() function polls the device to make sure the
BLOCK was acknowledged by the IOMMU. Backport this to 3.4 kernel.

BUG=chromium:219207
TEST=build/boot. run hardware_storageFio autotest.

Change-Id: I7b6850673cf1fa1a0cb4becdcde98aaf5992199b
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60564
Reviewed-by: Doug Anderson <dianders@chromium.org>
CHROMIUM: iommu/exynos: warn if we can't block IOMMU

The "BLOCK" state appears to be required to correctly invalidate
IOMMU TLB entries. If we can't unblock or invalidate an entry,
make noise about it.

BUG=none
TEST=none (code review)

Change-Id: I7f0a7e8406330f612721b6f0ced52a5f18ea8155
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60681
Reviewed-by: Doug Anderson <dianders@chromium.org>
CHROMIUM: ASoC: samsung dma - Don't set params on error.

If there is an error configuring DMA, clear the params member of the
runtime data.  This member being non-NULL signals that the dma should
be flushed and released.  If the setup fails, this will oops on a null
dereference.

BUG=chromium:244545
TEST=manual, play and record audio on daisy/spring.

Change-Id: I5caa762a9d65deec3774a78a92f12b7813d4eef4
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60720
Reviewed-by: Grant Grundler <grundler@chromium.org>
CHROMIUM: mmc: dw_mmc: don't queue up a card detect at slot startup

The MMC subsystem handles looking for a card at probe time.  Queuing
up our own can race with the rest of the MMC subsystem and cause
problems if we get unlucky with timing.  Just remove our own
detection.

Specifically, I found that with just the right set of printouts in my
system that one of the three SD/MMC devices in my system was having
trouble probing.  It would get an err -123 (-ENOMEDIUM) during probe.
I found that the source of the error was in
dw_mci_work_routine_card().  Adding more printouts to the code
sometimes made this error go away, so it's a little touchy.

You can see a snippet with my printouts in it (printouts were in
set_ios() on an exynos5420 board with some of our local patches):

[    4.216595] dwmmc_exynos 12210000.dwmmc1: Using internal DMA controller.
[    4.395935] dwmmc_exynos 12210000.dwmmc1: Version ID is 250a
[    4.401948] dwmmc_exynos 12210000.dwmmc1: DW MMC controller at irq 108, 64 bit host data width, 64 deep fifo
[    4.424430] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.453975] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.459592] mmc_host mmc1: Bus speed (slot 0) = 100000000Hz (slot req 400000Hz, actual 400000HZ div = 125)
[    4.484258] dwmmc_exynos 12210000.dwmmc1: 1 slots initialized
[    4.485406] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.487606] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.489794] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.509757] mmc1: error -123 whilst initialising SDIO card

While digging I found that doing our own card detection at init time
didn't appear to be necessary.  If I remove this code then cards that
are in the system at bootup are still detected just fine.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>

[ This change has landed in kernel-next chromeos-3.8 branch:
    https://gerrit.chromium.org/gerrit/#/c/59499/
]

BUG=chrome-os-partner:16073
TEST=build/boot on snow and spring.
    ./run_remote_tests.sh --board=$B --remote=$IP power_SuspendStress/control.bareDaily

Change-Id: I948140d0c9da6508bc0a73e55fa7785f83b8df4d
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60827
Reviewed-by: Doug Anderson <dianders@chromium.org>
s5p-mfc: Update v6 encoder buffer sizes

Fix buffer sizes needed for MFC encoding as is
expected by v6 firmware,

BUG=chrome-os-partner:18019
TEST=build, run on CrOS snow

Change-Id: I184d381a39a37a1a55cf1988049bcbd1cc08c723
Signed-off-by: avnd kiran <avnd.kiran@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57445
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: kiran <kiran@chromium.org>
Tested-by: kiran <kiran@chromium.org>
s5p-mfc: add support for VIDIOC_{G,S}_CROP to encoder

Allow userspace to set the crop rect of the input image buffer to
encode.

BUG=chrome-os-partner:18019
TEST=build, run on CrOS snow

Change-Id: I726e541473ef75d3788195ccecea7cce5af35be4
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56858
Commit-Queue: kiran <kiran@chromium.org>
Tested-by: kiran <kiran@chromium.org>
MALI: kbase_debug: Make checkpatch happy

 (a) s/printk(KERN_*/pr_*
 (b) fix line lengths

In theory, these should really be dev_dbg, with the mali device name
instead of "Mali<>".

Note: Also, remove an extra layer of indenting from some macro bodies,
and get rid of an old doxygen comment that refers to an earlier version
of KBASE_DEBUG_PRINT_WARN called KBASEP_DEBUG_WARN_OUT.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chrome-os-partner:20550
TEST=checkpatch is happy

Change-Id: Ia523621c94435fcea339350b72b380405cf1d105
Reviewed-on: https://gerrit.chromium.org/gerrit/60320
Reviewed-by: Jason Rudd <jasonruddarm@gmail.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: john rees <john.rees@arm.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
MALI: Simplify KBASEP_DEBUG_PRINT trace format

Printing "__FILE__:__LINE__:__func__" is less verbose without losing any
meaning.

Since the kbase can get littered with these strings, this saves a little
bit of memory, too.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chrome-os-partner:20550
TEST=builds clean

Change-Id: I2f2189ca083ccddd3f705efc50d3a96e294aeba6
Reviewed-on: https://gerrit.chromium.org/gerrit/60321
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Jason Rudd <jasonruddarm@gmail.com>
Reviewed-by: john rees <john.rees@arm.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
MALI: kbase_debug: Allow printing function names only

With git grep and modern IDEs, function names are trivial to locate.
Allow the option to print just the function name and skip printing (and
storing) the file & line number.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chrome-os-partner:20550
TEST=test all 4 combinations of KBASE_DEBUG_SKIP_TRACE and
  KBASE_DEBUG_SKIP_FUNCTION

Change-Id: If2c5d85141d40e3e8341a756f4addfa2e51281cf
Reviewed-on: https://gerrit.chromium.org/gerrit/60322
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>