android-sdk/kernel-video.git
6 years agoMerge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
Vishal Mahaveer [Wed, 27 May 2015 13:16:46 +0000 (08:16 -0500)]
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android

* p-ti-linux-3.14.y-common:
  OMAPDSS: Reorder the Makefile so that LCD is loaded before HDMI
  Revert "TEMP: ARM: dts: dra7-evm: add i2c2 pinmux back in kernel"
  i2c: tvp5158: Enabling the enum_framesizes subdev op
  ARM: dts: dra7-evm: Add TVP5158 node
  ti_fragments: audio_display: Make VIP/VPE/TVP5158 a built-in
  i2c: tvp5158: Analog camera decoder driver

Change-Id: I14ac5fd2badd21d77a559e9ea76cba2a3a78190e
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
6 years agoOMAPDSS: Reorder the Makefile so that LCD is loaded before HDMI
Marcus Cooksey [Thu, 9 Apr 2015 18:49:13 +0000 (13:49 -0500)]
OMAPDSS: Reorder the Makefile so that LCD is loaded before HDMI

To comply with Android UI assumption of LCD being the primary display,
the display driver initialization sequence is reordered for LCD driver
initialization to occur before ALL other diplays.

This is necessary now that pinmux config occurs in bootloader.
Without this change hdmi could be initialized and set as primary display
thereby violating the Android UI assumption.

Change-Id: I215b55a3136201bbed7cc554cc7375b41f9e8706
Signed-off-by: Marcus Cooksey <mcooksey@ti.com>
6 years agoRevert "TEMP: ARM: dts: dra7-evm: add i2c2 pinmux back in kernel"
Marcus Cooksey [Thu, 9 Apr 2015 20:58:17 +0000 (15:58 -0500)]
Revert "TEMP: ARM: dts: dra7-evm: add i2c2 pinmux back in kernel"

This reverts commit 1ee4618aeb746e98b8cbc279564d306d1045ace4.

Change-Id: Icb4909078708bea01f5dc4254e71c491a28a4788
Signed-off-by: Marcus Cooksey <mcooksey@ti.com>
6 years agoi2c: tvp5158: Enabling the enum_framesizes subdev op
Rakesh Movva [Wed, 20 May 2015 01:14:28 +0000 (20:14 -0500)]
i2c: tvp5158: Enabling the enum_framesizes subdev op

This patch allows the VIP driver to call the enum_framsizes subdev
'op' so that it can return the corresct set of supported preview
sizes of the sensor.

Change-Id: I3aca8d913ba30c2cf82678f58bdb83d934d0a610
Signed-off-by: Rakesh Movva <r-movva@ti.com>
6 years agoARM: dts: dra7-evm: Add TVP5158 node
Rakesh Movva [Wed, 20 May 2015 04:56:18 +0000 (23:56 -0500)]
ARM: dts: dra7-evm: Add TVP5158 node

Adding the TVP5158 analog video decoder support which generates
BT656 embedded sync video. Add the device tree node and the
corresponding endpoint pair.

Change-Id: Id6d4df16fedbf321396b3fb4ee350f965f4b7367
Signed-off-by: Rakesh Movva <r-movva@ti.com>
6 years agoti_fragments: audio_display: Make VIP/VPE/TVP5158 a built-in
Rakesh Movva [Mon, 18 May 2015 16:04:58 +0000 (11:04 -0500)]
ti_fragments: audio_display: Make VIP/VPE/TVP5158 a built-in

VIP/VPE/TVP5158 are made as a built-in feature.

Change-Id: I348c221ca912480310abaa38650fdce6481809c6
Signed-off-by: Rakesh Movva <r-movva@ti.com>
6 years agoi2c: tvp5158: Analog camera decoder driver
Sathishkumar S [Sat, 31 Jan 2015 13:40:48 +0000 (19:10 +0530)]
i2c: tvp5158: Analog camera decoder driver

Add support for TVP5158 video decoder. This driver
does the default initialization for single channel
NTSC decode. It is tested with NTSC camera source.

Change-Id: Ia5f6bd038a5bcd5e7571afdc5447acbf575a97ef
Signed-off-by: Sathishkumar S <sathish.omap@gmail.com>
[Added multi channel support]
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
6 years agoMerge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
Subramaniam Chanderashekarapuram [Wed, 27 May 2015 00:47:44 +0000 (19:47 -0500)]
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android

* 'p-ti-linux-3.14.y-common':
  ASoC: davinci-mcasp: Logic low for inactive output slots

Change-Id: Ib1d102240291e1f59e71c8c6296e7d87e29abe1e
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
6 years agoMerge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android...
Subramaniam Chanderashekarapuram [Wed, 27 May 2015 00:25:34 +0000 (19:25 -0500)]
Merge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio into p-ti-linux-3.14.y-common

* 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio:
  ASoC: davinci-mcasp: Logic low for inactive output slots

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
6 years agoMerge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
Subramaniam Chanderashekarapuram [Wed, 27 May 2015 00:13:18 +0000 (19:13 -0500)]
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android

* 'p-ti-linux-3.14.y-common':
  ARM: dts: dra72-evm: Set MMC host controller capability properties
  ARM: dts: dra7-evm: Add IODELAY values for the UHS MMC modes
  mmc: omap_hsmmc: Add support to set IODELAY values for MMC DDR52
  ARM: dts: dra7-evm: MMC2 in DDR52 mode
  mmc: omap_hsmmc: Set MMC DDR52 also from dt property
  mmc: omap_hsmmc: Fix MMC DDR52 support

Change-Id: I869b4b1d9e4d3215047cb65d0c8524e2ebc3e3c1
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
6 years agoARM: dts: dra72-evm: Set MMC host controller capability properties
Kishon Vijay Abraham I [Mon, 25 May 2015 14:14:54 +0000 (19:44 +0530)]
ARM: dts: dra72-evm: Set MMC host controller capability properties

Added properties in device tree to indicate the MMC controller support
SDR12, SDR25 and DDR50 modes.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoARM: dts: dra7-evm: Add IODELAY values for the UHS MMC modes
Kishon Vijay Abraham I [Mon, 25 May 2015 14:14:53 +0000 (19:44 +0530)]
ARM: dts: dra7-evm: Add IODELAY values for the UHS MMC modes

Add IODELAY values for sdr12, sdr25, ddr50 and mmc ddr52 modes.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
6 years agommc: omap_hsmmc: Add support to set IODELAY values for MMC DDR52
Kishon Vijay Abraham I [Mon, 25 May 2015 14:14:52 +0000 (19:44 +0530)]
mmc: omap_hsmmc: Add support to set IODELAY values for MMC DDR52

commit e81ae6df66 (mmc: host: omap_hsmmc: Set appropriate
IODELAY values for various MMC modes) added support to set IODELAY
values for various MMC modes but failed to add support for
DDR52.
Add support to set IODELAY values for MMC DDR52 mode.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
6 years agoARM: dts: dra7-evm: MMC2 in DDR52 mode
Misael Lopez Cruz [Tue, 12 May 2015 23:56:03 +0000 (18:56 -0500)]
ARM: dts: dra7-evm: MMC2 in DDR52 mode

MMC2 was using high-speed timing by default which has lower
throughput than DDR52, which is also supported.  So switch
MMC2 to DDR52 mode.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
6 years agommc: omap_hsmmc: Set MMC DDR52 also from dt property
Misael Lopez Cruz [Tue, 12 May 2015 23:52:57 +0000 (18:52 -0500)]
mmc: omap_hsmmc: Set MMC DDR52 also from dt property

All other controller capabilities were set from dt property
but MMC DDR52 was missing.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
6 years agommc: omap_hsmmc: Fix MMC DDR52 support
Misael Lopez Cruz [Tue, 12 May 2015 23:49:28 +0000 (18:49 -0500)]
mmc: omap_hsmmc: Fix MMC DDR52 support

MMC DDR52 mode also requires the DDR bit set.

This fix is pretty much what's done in upstream commit 903101a
"mmc: omap_hsmmc: Fix UHS card with DDR50 support", except
that in ti-kernel-3.14 MMC DDR52 was broken, not UHS DDR50.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
6 years agoASoC: davinci-mcasp: Logic low for inactive output slots
Misael Lopez Cruz [Tue, 19 May 2015 18:05:15 +0000 (13:05 -0500)]
ASoC: davinci-mcasp: Logic low for inactive output slots

The default state when serializers are in inactive slots is Hi-Z.
In some cases, there are no additional components driving the data
lines to a safe state so they might have noise.

While in inactive slots, the McASP AXR pins configured as outputs
can be driven low through the serializer pin drive mode setting
(DISMOD) to prevent such noise.

Change-Id: I945a806fe1ad77a5f3d09e9fa039ae0366a5b088
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
6 years agoMerge branch 'p-android-3.14' into p-ti-linux-3.14.y-android
Praneeth Bajjuri [Fri, 22 May 2015 18:14:21 +0000 (13:14 -0500)]
Merge branch 'p-android-3.14' into p-ti-linux-3.14.y-android

* p-android-3.14:
  selinux: enable per-file labeling for debugfs files.
  cpufreq: interactive: Rearm governor timer at max freq
  cpufreq: interactive: Implement cluster-based min_sample_time
  cpufreq: interactive: Exercise hispeed settings at a policy level

Change-Id: I4978c630b92ef8dff68255ebdbd9c41fbe6db696
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'android-3.14' of https://android.googlesource.com/kernel/common into...
Praneeth Bajjuri [Fri, 22 May 2015 18:13:35 +0000 (13:13 -0500)]
Merge branch 'android-3.14' of https://android.googlesource.com/kernel/common into p-android-3.14

* 'android-3.14' of https://android.googlesource.com/kernel/common:
  selinux: enable per-file labeling for debugfs files.
  cpufreq: interactive: Rearm governor timer at max freq
  cpufreq: interactive: Implement cluster-based min_sample_time
  cpufreq: interactive: Exercise hispeed settings at a policy level

Change-Id: I8d4e490ea11e068b0add8ed92ee58af3a666ab25
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'p-android-3.14-linaro' into p-ti-linux-3.14.y-android
Praneeth Bajjuri [Fri, 22 May 2015 17:46:34 +0000 (12:46 -0500)]
Merge branch 'p-android-3.14-linaro' into p-ti-linux-3.14.y-android

* p-android-3.14-linaro:
  Revert "mmc: core: host: only use wakelock for detect work"

Change-Id: I0046343664e3864cac2221ad28e89730654e2990
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
Praneeth Bajjuri [Fri, 22 May 2015 17:46:19 +0000 (12:46 -0500)]
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android

* p-ti-linux-3.14.y-common:
  ARM: OMAP: Add function to install alternate secure dispatcher
  ARM: DRA7: hwmod: register timer12 only for GP device type

Change-Id: Ib57816544b3dbd1d836529f606fec006128e276b
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoARM: OMAP: Add function to install alternate secure dispatcher
Harinarayan Bhatta [Fri, 17 Apr 2015 05:09:11 +0000 (10:39 +0530)]
ARM: OMAP: Add function to install alternate secure dispatcher

This change adds the function omap_secure_dispatcher_switch
which is used to setup an alternate implemention of the function
omap_secure_dispatcher in omap-secure.c

Change-Id: Ib4b2579a5e5bef3e35adc3bce4f11f739c5a3851
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
6 years agoARM: DRA7: hwmod: register timer12 only for GP device type
Harinarayan Bhatta [Fri, 17 Apr 2015 04:57:01 +0000 (10:27 +0530)]
ARM: DRA7: hwmod: register timer12 only for GP device type

This update separates out timer12 into a different list
registered for GP devices only. On a HS device, timer12
is used in secure world and is not available for linux.

Change-Id: I6629680debbb399c8932d20ee860103211197843
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
6 years agoRevert "mmc: core: host: only use wakelock for detect work"
Praneeth Bajjuri [Fri, 22 May 2015 17:27:01 +0000 (12:27 -0500)]
Revert "mmc: core: host: only use wakelock for detect work"

This reverts commit 2f76feb8027a3452f6f6adfabea1638812b5d3fb.

This patch introduced memory leak
from : drivers/mmc/core/host.c
 wake_lock_init(&host->detect_wake_lock, WAKE_LOCK_SUSPEND,
 kasprintf(GFP_KERNEL, "%s_detect", mmc_hostname(host)));
--

Reverting for now . To be debugged further and provide better
fix accordingly

Change-Id: Ic29ede114ff7bcfd0ee0e15661e015fecbbed236
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
Praneeth Bajjuri [Thu, 21 May 2015 22:38:45 +0000 (17:38 -0500)]
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android

* p-ti-linux-3.14.y-common:
  TI-Integration: usb: musb: fix botched up merge (again)

Change-Id: I5e8621f4427baff14f38cac8fb26603fba1c3fe9
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel...
Praneeth Bajjuri [Thu, 21 May 2015 22:36:17 +0000 (17:36 -0500)]
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common

* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel:
  TI-Integration: usb: musb: fix botched up merge (again)

Change-Id: I8f5adc9e1e1e37c731e1d6405a071012e6064ebc
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoTI-Integration: usb: musb: fix botched up merge (again)
Sekhar Nori [Thu, 21 May 2015 16:28:58 +0000 (16:28 +0000)]
TI-Integration: usb: musb: fix botched up merge (again)

Merge bc058ac090e8 ("Merge tag 'v3.14.42' of
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into
ti-linux-3.14.y") was a botched up merge.

commit df47ad1ce42b ("TI-Integration: Fix merge conflict
on musb_core.c") tried to fix it up but only did it
partially.

commit d0f5c460aac2 ("TI-Integration: Cherry picking this
commit to fix merge issue") tried to finish the job by
cherry-picking commit 889ad3b60f9c ("usb: musb: try a race-free
wakeup") which was the commit introducing code botched up by
original merge.

While  doing this it was missed that a later commit 1007020e37f9
("usb: musb: fix device hotplug behind hub") had made further
fixes which now got reverted due to the cherry-pick. So,
cherry-picking an older commit to fix a bad merge was a bad idea.

This patch finally brings back code to where it should have
been after original merge bc058ac090e8.

Fixes: d0f5c460aac2 ("TI-Integration: Cherry picking this commit to fix merge issue")

Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoMerge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
Praneeth Bajjuri [Thu, 21 May 2015 19:20:34 +0000 (14:20 -0500)]
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android

* p-ti-linux-3.14.y-common:
  ARM: dtsi: dra7xx-jamr3: McASP2 is shared with DSP
  ARM: dts: dra72-evm: TEMP: Add pinmux for radio
  ARM: dts: dra72-evm: TEMP: Add pinmux for UART3

Change-Id: I230beaa2e1de926ae268b34369d88b8551f82297
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android...
Praneeth Bajjuri [Thu, 21 May 2015 19:19:11 +0000 (14:19 -0500)]
Merge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio into p-ti-linux-3.14.y-common

* 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio:
  ARM: dtsi: dra7xx-jamr3: McASP2 is shared with DSP
  ARM: dts: dra72-evm: TEMP: Add pinmux for radio
  ARM: dts: dra72-evm: TEMP: Add pinmux for UART3

Change-Id: I5a700c1fe78ac6e730ebf1f07dd8265322ee46c2
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoselinux: enable per-file labeling for debugfs files.
Stephen Smalley [Tue, 19 May 2015 17:59:12 +0000 (13:59 -0400)]
selinux: enable per-file labeling for debugfs files.

upstream commit 6f29997f4a3117169eeabd41dbea4c1bd94a739c

Add support for per-file labeling of debugfs files so that
we can distinguish them in policy.  This is particularly
important in Android where certain debugfs files have to be writable
by apps and therefore the debugfs directory tree can be read and
searched by all.

Since debugfs is entirely kernel-generated, the directory tree is
immutable by userspace, and the inodes are pinned in memory, we can
simply use the same approach as with proc and label the inodes from
policy based on pathname from the root of the debugfs filesystem.
Generalize the existing labeling support used for proc and reuse it
for debugfs too.

Change-Id: I6460fbed6bb6bd36eb8554ac8c4fdd574edf3b07
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
6 years agoARM: dtsi: dra7xx-jamr3: McASP2 is shared with DSP
Misael Lopez Cruz [Thu, 21 May 2015 05:38:44 +0000 (00:38 -0500)]
ARM: dtsi: dra7xx-jamr3: McASP2 is shared with DSP

McASP2 is configured and used from the DSP side, with the
exception of the PM resources that are taken care on the
MPU side.

Change-Id: If133a69de6c50b3aeb7a31edb557725b0753f39d
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
6 years agoARM: dts: dra72-evm: TEMP: Add pinmux for radio
Misael Lopez Cruz [Wed, 20 May 2015 17:09:16 +0000 (12:09 -0500)]
ARM: dts: dra72-evm: TEMP: Add pinmux for radio

Add pinmux settings for radio related modules (McASP2, McASP6, i2c4,
etc).  This is a temporary patch as all padconf settings are expected
to be moved to the bootloader, as already done for J6 / dra7-evm.

Change-Id: I6c59ce7446c40f2d8db9c017f095f070754e6c1d
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
6 years agoARM: dts: dra72-evm: TEMP: Add pinmux for UART3
Misael Lopez Cruz [Wed, 20 May 2015 15:37:07 +0000 (10:37 -0500)]
ARM: dts: dra72-evm: TEMP: Add pinmux for UART3

Add pinmux settings for UART3 used in Bluetooth.  This is a
temporary patch as all padconf settings are expected to be
moved to the bootloader, as already done for J6 / dra7-evm.

Change-Id: Idb861390be182eb296e2dc6e8aee7d6458a6543a
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
6 years agocpufreq: interactive: Rearm governor timer at max freq
Rohit Gupta [Sat, 7 Mar 2015 02:46:04 +0000 (18:46 -0800)]
cpufreq: interactive: Rearm governor timer at max freq

Interactive governor doesn't rearm per-cpu timer if target_freq is
equal to policy->max. However, this does not have clear performance
benefits. Profiling doesn't show any difference in benchmarks, games
or other workloads, if timers are always rearmed.

At same time, there are a few issues caused by not rearming timer
at policy->max.

1) min_sample_time enforcement is inconsistent

For target frequency that is lower than policy->max, it will not
drop until min_sample_time has passed since last frequency evaluation
selected current frequency. However, for policy->max, it will
always drop immediately as long as CPU has been run for longer than
min_sample_time. This is because timer is not running and thus
floor_freq and floor_validate_time is not updated.

Example: assume min_sample_time is 59ms and timer_rate is 20ms.
Frequency X < Y. Let's say CPU would pick the following frequencies
before accounting for min_sample_time in each 20ms sampling window.
Y, Y, Y, Y, X, X, X, X, X
If Y is not policy->max, the final target_freq after considering
min_sample_time will be Y, Y, Y, Y, *Y, *Y, X, X, X
* marks the windows where frequency is prevented from dropping.
If Y is policy->max, the final target_freq will be
Y, Y, Y, Y, X, X, X, X, X

2) Rearm timer in IDLE_START does not work as intended

IDLE_START/END is sent in arch_cpu_idle_enter/exit(). However, next
wake up is decided in tick_nohz_idle_enter(), which traverses the
timer list before idle notification is sent out. Therefore, rearming
timer in idle notification won't take effect until CPU wakes up at
least once. In rare scenarios when a CPU goes to idle and sleeps for a
long time immediately after a heavy load stops, it may not wake up
to drop its frequency vote for a long time, defeating the purpose of
having a slack_timer.

3) Need to rearm timer for policy->max change

commit 535a553fc1c4b4c3627c73214ade6326615a7463
(cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS) mentions the
problem of timer getting indefinitely pushed back due to frequency
changes in policy->min/max. However, it still cancels and rearms timer
if policy->max is increased, and same problem could still happen if
policy->max is frequently changing after the fix. The best solution is
to always rearm timer for each CPU even if it's running at
policy->max.

Rearming timers even if target_freq is policy->max solves these
problems cleanly. It also simplifies the design and code of interactive
governor.

Change-Id: I973853d2375ea6f697fa4cee04a89efe6b8bf735
Reviewed-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
6 years agocpufreq: interactive: Implement cluster-based min_sample_time
Junjie Wu [Tue, 24 Mar 2015 22:51:10 +0000 (15:51 -0700)]
cpufreq: interactive: Implement cluster-based min_sample_time

min_sample_time needs to be cluster-based to match
above_hispeed_delay. If each CPU keeps making local decisions, it's
possible min_sample_time is not correctly enforced at cluster level,
which results in undesired frequency drops.

Change-Id: Ia2ec2ad9b7a8d715d4408c924d6762b7e532e4b4
Reviewed-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
6 years agocpufreq: interactive: Exercise hispeed settings at a policy level
Saravana Kannan [Wed, 15 Oct 2014 19:44:18 +0000 (12:44 -0700)]
cpufreq: interactive: Exercise hispeed settings at a policy level

If a heavy task migrates between otherwise idle CPUs in a policy during
every sample window, the above hispeed delay window for the CPUs would get
restarted for every sample window. Due to the continuous restart of above
hispeed delay window, none of the CPUs would ever pick a target frequency
higher than hispeed frequency. This causes the policy's frequency to be
stuck at hispeed freq even if the load justifies a higher frequency.

To fix this, the above high speed delay window is restarted only when the
policy frequency changes. This ensures that tasks migrating between CPUs in
a policy are handled correctly.

Also, the hispeed load/frequency heuristic is only necessary when the
information is insufficient to determine if the load on the CPU needs at
least hispeed frequency. When the policy frequency is already at or above
hispeed frequency, if the CPU load% based on policy frequency is not above
hispeed load, then the information is clearly sufficient to determine that
the load on the CPU does not need hispeed frequency.

Therefore, compute CPU load% (which is used only to compare against hispeed
load) based on policy frequency instead of CPU target frequency.

Change-Id: I8b5dfe6c50bee567a6719f0980e3f7757876ce4b
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
6 years agoMerge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
Praneeth Bajjuri [Mon, 18 May 2015 21:18:43 +0000 (16:18 -0500)]
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android

* p-ti-linux-3.14.y-common:
  arm: dtsi: dra7x: Add Vision application board device tree
  video: serdes: Add TI FPDlink3 video (de)serializer driver

Change-Id: Ied9aedb40bd913227cac773f64fec97f54f0c571
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoarm: dtsi: dra7x: Add Vision application board device tree
Nikhil Devshatwar [Fri, 5 Dec 2014 10:01:26 +0000 (15:31 +0530)]
arm: dtsi: dra7x: Add Vision application board device tree

Vision app board is an application board which is designed
to work with TI dra7xx-evm specifically for multi camera use cases.

This board consists of:-
 OV10635 8bit camera with parallel interface.
* HDMI video receiver chip
* 3 GPIO expanders for configuring the video deserializers
* 6 video deserializers ( using FPDlink III)
  Each deserializer allows to connect one OV10635 camera via a video
  serializer connected over LVDS
* 6 serializer chips one each on the deserializer i2c  bus
* 6 OV10635 cameras one each on the deserializer i2c bus
* There are some CPLD muxes on the board which control the data
  routing of multiple video cameras. These muxes are controlled using
  gpio pins

Create a skeleton DTS file for vision app board.
Also add the device tree files for dra7-evm and dra72-evm with vision
app board.

Change-Id: I113857832c82d4ce4112911a3c7e4ad0adab73ad
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
6 years agovideo: serdes: Add TI FPDlink3 video (de)serializer driver
Nikhil Devshatwar [Sat, 6 Dec 2014 10:23:22 +0000 (15:53 +0530)]
video: serdes: Add TI FPDlink3 video (de)serializer driver

Add necessary documentation, Makefile, Kconfig and header files
Add support for DS90UB914Q/913Q 12bit video (de)serializer
Add support for DS90UB925/928 12bit video (de)serializer
- Register gpio chip for local gpios
- Register i2c adapter for remote bus
- Act as i2c bridge for all remote slave devices

Change-Id: Ic8046018fea04ed9faca8808a2519c1ea4754248
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
6 years agoMerge branch 'p-android-3.14' into p-ti-linux-3.14.y-android
Praneeth Bajjuri [Mon, 18 May 2015 19:05:20 +0000 (14:05 -0500)]
Merge branch 'p-android-3.14' into p-ti-linux-3.14.y-android

* p-android-3.14:
  suspend: Return error when pending wakeup source is found.

Change-Id: Ib943fa8c73bb0658695d94c9165c4b280be667e5
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'android-3.14' of https://android.googlesource.com/kernel/common into...
Praneeth Bajjuri [Mon, 18 May 2015 19:03:56 +0000 (14:03 -0500)]
Merge branch 'android-3.14' of https://android.googlesource.com/kernel/common into p-android-3.14

* 'android-3.14' of https://android.googlesource.com/kernel/common:
  suspend: Return error when pending wakeup source is found.

Change-Id: I2d85b4370b35878cfa14935b0d75572f21cd709c
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
Praneeth Bajjuri [Mon, 18 May 2015 18:55:33 +0000 (13:55 -0500)]
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android

* p-ti-linux-3.14.y-common: (75 commits)
  TI-Integration: Cherry picking this commit to fix merge issue
  TI-Integration: Fix merge conflict on musb_core.c
  dts: Adding entry for GC320.
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
  extcon: palmas: Support GPIO based USB ID detection
  usb: gadget: use $(srctree) instead of $(PWD) for includes
  ARM: dts: DRA7: Add standby info for IPU & DSPs
  ARM: dts: OMAP5: Add standby info for IPU and DSP
  ARM: dts: OMAP4: Add standby info for IPU and DSP
  Documentation: dt: update omap remoteproc binding for suspend
  remoteproc/omap: use consistent match data structures for all SoCs
  iommu/omap: add support for runtime auto suspend/resume
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: introduce new API for suspend/resume
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle
  ...

Change-Id: I179274d67ef5cee5c87f880e447072e05095d169
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel...
Praneeth Bajjuri [Mon, 18 May 2015 18:54:32 +0000 (13:54 -0500)]
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common

* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (74 commits)
  TI-Integration: Cherry picking this commit to fix merge issue
  TI-Integration: Fix merge conflict on musb_core.c
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
  extcon: palmas: Support GPIO based USB ID detection
  usb: gadget: use $(srctree) instead of $(PWD) for includes
  ARM: dts: DRA7: Add standby info for IPU & DSPs
  ARM: dts: OMAP5: Add standby info for IPU and DSP
  ARM: dts: OMAP4: Add standby info for IPU and DSP
  Documentation: dt: update omap remoteproc binding for suspend
  remoteproc/omap: use consistent match data structures for all SoCs
  iommu/omap: add support for runtime auto suspend/resume
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: introduce new API for suspend/resume
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle
  Linux 3.14.43
  ...

Change-Id: I93e347ad013ffa4aeeb5c1d088d79e0efc0c80e7
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoTI-Integration: Cherry picking this commit to fix merge issue
Sebastian Andrzej Siewior [Wed, 22 Oct 2014 20:09:33 +0000 (22:09 +0200)]
TI-Integration: Cherry picking this commit to fix merge issue

Cherry picking this commit to the top of the tree to fix a
merge of the stable that broke this file.  Half of the
issue was the merge conflict resolution the other half
was gits auto merging of the file.

usb: musb: try a race-free wakeup

Attaching a keyboard, using it as a wakeup via
|for f in $(find /sys/devices/ocp.3/47400000.usb -name wakeup)
|do
| echo enabled > $f
|done

going into standby
|  echo standby >  /sys/power/state

and now a wake up by a pressing a key.
What happens is that the system wakes up but the USB device is dead. The
USB stack tries to send a few control URBs but nothing comes back.
Eventually it gaves up and the device remains dead:
|[  632.559678] PM: Wakeup source USB1_PHY
|[  632.581074] PM: noirq resume of devices complete after 21.261 msecs
|[  632.607521] PM: early resume of devices complete after 10.360 msecs
|[  632.616854] net eth2: initializing cpsw version 1.12 (0)
|[  632.704126] net eth2: phy found : id is : 0x4dd074
|[  636.704048] libphy: 4a101000.mdio:00 - Link is Up - 1000/Full
|[  638.444620] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[  653.713435] usb 1-1: device descriptor read/64, error -110
|[  669.093435] usb 1-1: device descriptor read/64, error -110
|[  669.473424] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[  684.743436] usb 1-1: device descriptor read/64, error -110
|[  690.065097] PM: resume of devices complete after 57450.744 msecs
|[  690.076601] PM: Finishing wakeup.
|[  690.076627] Restarting tasks ...

It seems that since we got woken up via MUSB_INTR_RESUME the
musb_host_finish_resume() callback is executed before the
resume-callbacks of the PHY and glue layer are invoked. If I delay it
until the glue layer resumed then I don't see this problem.

I also move musb_host_resume_root_hub() into that callback since I don't
see any reason in doing anything resume-link if there are still pieces
not restored.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/usb/musb/musb_core.c

6 years agoMerge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux...
Texas Instruments Auto Merger [Mon, 18 May 2015 17:16:04 +0000 (12:16 -0500)]
Merge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux-3.14.y

TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-3.14.y

* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: DRA7: Add standby info for IPU & DSPs
  ARM: dts: OMAP5: Add standby info for IPU and DSP
  ARM: dts: OMAP4: Add standby info for IPU and DSP
  Documentation: dt: update omap remoteproc binding for suspend
  remoteproc/omap: use consistent match data structures for all SoCs
  iommu/omap: add support for runtime auto suspend/resume
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: introduce new API for suspend/resume
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle
  mailbox/omap: check for any unread messages during suspend
  mailbox/omap: add support for suspend/resume
  mailbox/omap: store mailbox interrupt type in omap_mbox_device

Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
6 years agosuspend: Return error when pending wakeup source is found.
Ruchi Kandoi [Thu, 7 May 2015 17:18:55 +0000 (10:18 -0700)]
suspend: Return error when pending wakeup source is found.

If a wakeup source is found to be pending in the last stage of suspend
after syscore suspend then the device doesn't suspend but the error is
not propogated which causes an error in the accounting for the number
of suspend aborts and successful suspends.

Change-Id: Ib63b4ead755127eaf03e3b303aab3c782ad02ed1
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
6 years agoMerge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Mon, 18 May 2015 16:13:27 +0000 (11:13 -0500)]
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y

Pull in the updated remoteproc feature branch that adds the support for
system suspend/resume for the IPU and DSP remote processors on OMAP4, OMAP5
and DRA7 (only IPUs). The feature branch also pulls in automatically the
dependent mailbox and iommu feature branches with suspend/resume support.

* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: DRA7: Add standby info for IPU & DSPs
  ARM: dts: OMAP5: Add standby info for IPU and DSP
  ARM: dts: OMAP4: Add standby info for IPU and DSP
  Documentation: dt: update omap remoteproc binding for suspend
  remoteproc/omap: use consistent match data structures for all SoCs
  iommu/omap: add support for runtime auto suspend/resume
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: introduce new API for suspend/resume
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle
  mailbox/omap: check for any unread messages during suspend
  mailbox/omap: add support for suspend/resume
  mailbox/omap: store mailbox interrupt type in omap_mbox_device

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoTI-Integration: Fix merge conflict on musb_core.c
Dan Murphy [Mon, 18 May 2015 16:08:42 +0000 (11:08 -0500)]
TI-Integration: Fix merge conflict on musb_core.c

Fix merge conflict resolution on musb_core.c file
where the hard coded time out delayed was taken
over the defined delay that was introduced in patch

889ad3b60f9c5f9cf6bd722603ed63d75a83af27
usb: musb: try a race-free wakeup

Signed-off-by: Dan Murphy <dmurphy@ti.com>
6 years agodts: Adding entry for GC320.
Gowtham Tammana [Thu, 11 Dec 2014 18:03:00 +0000 (12:03 -0600)]
dts: Adding entry for GC320.

GC320 entry is added to the dts file. Using crossbar index number
for interrupt mapping.

Change-Id: I3ff5644fbcc2ec74db40af945caac8436bafe3aa
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
6 years agoremoteproc/omap: add support for system suspend/resume
Suman Anna [Wed, 22 Apr 2015 23:57:09 +0000 (18:57 -0500)]
remoteproc/omap: add support for system suspend/resume

This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.

The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. There are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.

The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only when
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are also suspended by the remoteproc driver, and the suspend
process is completed by putting the remote processors into reset,
after which the Linux kernel can put the domain into further lower
power states as possible.

The resume sequence undoes the operations performed in the PM suspend
callback, by restoring the IOMMUs, starting the timers and finally
releasing the processors from reset. This requires that the remote
processor side OS be able to distinguish a power-resume boot from a
power-on/cold boot, restore the context of its private modules saved
during the suspend phase, and resume executing code from where it
was suspended.

The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device\
is put into. The management of the DDR contents will be managed by
the Linux kernel.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoMerge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integrat...
Dan Murphy [Mon, 18 May 2015 14:56:53 +0000 (09:56 -0500)]
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
  extcon: palmas: Support GPIO based USB ID detection
  usb: gadget: use $(srctree) instead of $(PWD) for includes

Signed-off-by: Dan Murphy <DMurphy@ti.com>
6 years agoARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
Roger Quadros [Wed, 13 May 2015 11:02:15 +0000 (14:02 +0300)]
ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2

The VBUS line of USB2 is connected to VBUS detect logic on
the PMIC. Use the palmas-usb driver to report VBUS events
to the USB driver.

As the palmas-usb driver supports GPIO based ID reporting
provide the GPIO for ID pin as well.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoextcon: palmas: Support GPIO based USB ID detection
Roger Quadros [Wed, 13 May 2015 11:02:14 +0000 (14:02 +0300)]
extcon: palmas: Support GPIO based USB ID detection

Some palmas based chip variants do not have OTG based ID logic.
For these variants we rely on GPIO based USB ID detection.

These chips do have VBUS comparator for VBUS detection so we
continue to use the old way of detecting VBUS.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agousb: gadget: use $(srctree) instead of $(PWD) for includes
Yegor Yefremov [Wed, 13 May 2015 17:09:20 +0000 (13:09 -0400)]
usb: gadget: use $(srctree) instead of $(PWD) for includes

[ Upstream commit fa31409a82ee050e52caad9e4c483fe3edca163a ]

Using $(PWD) breaks builds when make was invoked from outside
of the kernel tree.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Stiffler <j-stiffler@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoARM: dts: DRA7: Add standby info for IPU & DSPs
Suman Anna [Thu, 14 May 2015 03:32:51 +0000 (22:32 -0500)]
ARM: dts: DRA7: Add standby info for IPU & DSPs

Add the data for the "ti,rproc-standby-info" property for all
the DSP and IPU remoteproc processor nodes on DRA7xx family of
SoCs. This data is same for all DRA7 boards, and is required
by the OMAP remoteproc driver to implement suspend/resume for
the IPU & DSP remoteproc devices on DRA7 SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoARM: dts: OMAP5: Add standby info for IPU and DSP
Suman Anna [Thu, 14 May 2015 03:29:54 +0000 (22:29 -0500)]
ARM: dts: OMAP5: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes, applicable to
all OMAP5 boards. This is required by the OMAP remoteproc
driver to implement suspend/resume for the OMAP5 remoteproc
devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoARM: dts: OMAP4: Add standby info for IPU and DSP
Suman Anna [Thu, 14 May 2015 03:28:56 +0000 (22:28 -0500)]
ARM: dts: OMAP4: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes. This data is
common to all OMAP4 boards, and is required by the OMAP
remoteproc driver to implement suspend/resume for the OMAP4
remoteproc devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoDocumentation: dt: update omap remoteproc binding for suspend
Suman Anna [Thu, 14 May 2015 03:55:25 +0000 (22:55 -0500)]
Documentation: dt: update omap remoteproc binding for suspend

The OMAP remoteproc binding has been updated to add an additional
property, "ti,rproc-standby-info". The property is used to define
the standby register address required by the OMAP remoteproc driver
to check that a remote proessor has entered standby and ready to
be suspended during a system suspend or a runtime auto-suspend of
the corresponding remoteproc device.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoremoteproc/omap: use consistent match data structures for all SoCs
Suman Anna [Thu, 9 Apr 2015 01:26:53 +0000 (20:26 -0500)]
remoteproc/omap: use consistent match data structures for all SoCs

The OMAP remoteproc code currently stores the firmware names directly
in the match data fields for the OMAP4 & OMAP5 SoCs, while a separate
data structure (omap_rproc_fw_data) containing the device name and
firmware name is used for the processors on DRA7xx SoC family.

Switch the OMAP4 and OMAP5 SoCs also to use the same style as DRA7
SoCs for consistency. This also allows to easily add additional data
fields to this structure in the future if needed.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoMerge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux...
Suman Anna [Mon, 18 May 2015 02:03:33 +0000 (21:03 -0500)]
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y

Merge in the updated iommu feature branch into remoteproc tree to
pull in the suspend/resume support in the OMAP IOMMU driver. The
following are the main changes:
    - improvements in the OMAP iommu to perform the enabling &
      disabling of the IOMMU from within the runtime pm callbacks
    - two new API that needs to be invoked from the OMAP remoteproc
      driver to suspend/resume the IOMMU.
    - locked TLB save & restore logic
    - add needed pdata quirks to all supported IOMMUs

* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: add support for runtime auto suspend/resume
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: introduce new API for suspend/resume
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoMerge branch 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox into rproc...
Suman Anna [Mon, 18 May 2015 01:59:23 +0000 (20:59 -0500)]
Merge branch 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox into rproc-linux-3.14.y

Pull in the updated mailbox feature branch into the remoteproc tree,
this includes the suspend/resume support in the OMAP mailbox driver.

* 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox:
  mailbox/omap: check for any unread messages during suspend
  mailbox/omap: add support for suspend/resume
  mailbox/omap: store mailbox interrupt type in omap_mbox_device

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoiommu/omap: add support for runtime auto suspend/resume
Suman Anna [Tue, 12 May 2015 19:11:43 +0000 (14:11 -0500)]
iommu/omap: add support for runtime auto suspend/resume

This patches adds the support for the OMAP IOMMUs to be suspended
during the auto suspend/resume of the OMAP remoteproc devices. The
remote processors are auto suspended after a certain time of idle
or inactivity period. This is done by extending the suspend/resume
API added with an additional flag to indicate the auto-suspend.
The runtime auto-suspend simply decrements and increments the
runtime usage count of the IOMMU devices and let the context be
saved/restored using the existing runtime pm callbacks.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoiommu/omap: add logic to save/restore locked TLBs
Suman Anna [Tue, 12 May 2015 21:52:59 +0000 (16:52 -0500)]
iommu/omap: add logic to save/restore locked TLBs

The MMUs provide a mechanism to lock TLB entries to avoid
eviction and fetching of frequently used page table entries.
These TLBs lose context when the MMUs are turned OFF. Add the
logic to save and restore these locked TLBS during suspend
and resume respectively. There are no locked TLBs during
initial power ON, and they need not be saved during final
shutdown.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoiommu/omap: introduce new API for suspend/resume
Suman Anna [Tue, 12 May 2015 19:11:43 +0000 (14:11 -0500)]
iommu/omap: introduce new API for suspend/resume

The MMU registers for the remote processors lose their context
in Open Switch Retention (OSWR) or device OFF modes. Hence, the
context of the IOMMU needs to be saved before it is put to these
lower power state (OSWR/OFF) and restored before it is powered
up to ON again. The IOMMUs need to be active as long as the
client devices that are present behind the IOMMU are active.

This patch introduces two new API, omap_iommu_domain_suspend()
and omap_iommu_domain_resume() to allow the client users of the
IOMMU devices to suspend & resume the IOMMU devices during their
suspend/resume operations. The API leverages the pm runtime
framework API to implement suspend/resume functionality, and
invoke the runtime PM callbacks. The PM runtime_suspend and
runtime_callbacks already are used to enable, configure and
disable the IOMMUs during the attaching and detaching of the
client devices to the IOMMUs, and this code is reused during
suspend/resume.

NOTE:
There are two other existing API, omap_iommu_save_ctx() and
omap_iommu_restore_ctx(). These are left as is to support
suspend/resume of devices on legacy OMAP3 SoC.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoiommu/omap: streamline enable/disable through runtime pm callbacks
Suman Anna [Fri, 10 Apr 2015 21:18:07 +0000 (16:18 -0500)]
iommu/omap: streamline enable/disable through runtime pm callbacks

The OMAP IOMMU devices are typically present within the respective
client processor subsystem and have their own dedicated hard-reset
line. Enabling an IOMMU requires the reset line be deasserted and
the clocks be enabled before programming the necessary IOMMU
registers. The IOMMU disable sequence follow the reverse order of
enabling. The OMAP IOMMU driver programs the reset lines through
pdata ops to invoke the omap_device_assert/deassert_hardreset API.
The clocks are managed through the pm_runtime framework, and the
callbacks associated with the device's pm_domain, implemented in
the omap_device layer.

Streamline the enable and disable sequences in the OMAP IOMMU
driver by implementing all the above operations within the
runtime pm callbacks. All the OMAP devices have device pm_domain
callbacks plugged in the omap_device layer for automatic runtime
management of the clocks. Invoking the reset management functions
within the runtime pm callbacks in OMAP IOMMU driver therefore
requires that the default device's pm domain callbacks in the
omap_device layer be reset, as the ordering sequence for managing
the reset lines and clocks from the pm_domain callbacks don't gel
well with the implementation in the IOMMU driver callbacks. The
omap_device_enable/omap_device_idle functions are invoked through
the newly added pdata ops.

Consolidating all the device management sequences within the
runtime pm callbacks allows the driver to easily support both
system suspend/resume and runtime suspend/resume using common
code.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
Suman Anna [Fri, 15 May 2015 04:40:26 +0000 (23:40 -0500)]
ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU

The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata. The OMAP IOMMU driver now requires the platform
data ops for device_enable/idle on all the IOMMU devices to be
able to enable/disable the clocks and maintain the reference
count and the omap_hwmod state machine. So, add the iommu pdata
quirks for the OMAP3 ISP IOMMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
Suman Anna [Fri, 15 May 2015 16:00:35 +0000 (11:00 -0500)]
ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs

The DSP processor subsystems in DRA7xx have two MMUs, one for the
processor port and another for an EDMA port. Both these MMUs share
a common reset line, and the reset management is done through the
pdata quirks for the MMU associated with the processor port, so the
DSP EDMA MMUs didn't need any pdata ops. The OMAP IOMMU driver now
requires the device_enable/idle platform data ops on all the IOMMU
devices to be able to enable/disable the clocks and maintain the
reference count and the omap_hwmod state machine. So, add the iommu
pdata quirks for the DSP EDMA MMUs.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
Suman Anna [Mon, 27 Apr 2015 23:05:08 +0000 (18:05 -0500)]
ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs

The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks. Plug in these pdata ops for all the existing IOMMUs,
both for non-DT devices, and for DT-devices through pdata quirks.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoiommu/omap: add pdata ops for omap_device_enable/idle
Suman Anna [Mon, 27 Apr 2015 22:26:21 +0000 (17:26 -0500)]
iommu/omap: add pdata ops for omap_device_enable/idle

Add two new platform data ops to allow the OMAP iommu driver to
be able to invoke the omap_device_enable and omap_device_idle
from within the driver. These are being added to streamline the
sequence between managing the hard reset lines and the clocks
during the suspend path, as the default device pm_domain callback
sequences in omap_device layer are not conducive for the OMAP
IOMMU driver.

This could have been done by expanding the existing pdata ops
for reset management (like in the OMAP remoteproc driver), but
this was chosen to avoid adding new code in a separate file in
the mach-omap2 layer.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 years agoMerge tag 'v3.14.43' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
Texas Instruments Auto Merger [Sun, 17 May 2015 17:12:07 +0000 (12:12 -0500)]
Merge tag 'v3.14.43' of git./linux/kernel/git/stable/linux-stable into ti-linux-3.14.y

This is the 3.14.43 stable release

* tag 'v3.14.43' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (52 commits)
  Linux 3.14.43
  kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform
  arm64: kvm: use inner-shareable barriers for inner-shareable maintenance
  KVM: ARM: vgic: Fix the overlap check action about setting the GICD & GICC base address.
  KVM: arm/arm64: vgic: fix GICD_ICFGR register accesses
  ARM: KVM: trap VM system registers until MMU and caches are ON
  ARM: KVM: add world-switch for AMAIR{0,1}
  ARM: KVM: introduce per-vcpu HYP Configuration Register
  ARM: KVM: fix ordering of 64bit coprocessor accesses
  ARM: KVM: fix handling of trapped 64bit coprocessor accesses
  ARM: KVM: force cache clean on page fault when caches are off
  arm64: KVM: flush VM pages before letting the guest enable caches
  ARM: KVM: introduce kvm_p*d_addr_end
  arm64: KVM: trap VM system registers until MMU and caches are ON
  arm64: KVM: allows discrimination of AArch32 sysreg access
  arm64: KVM: force cache clean on page fault when caches are off
  deal with deadlock in d_walk()
  ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers.
  ACPICA: Utilities: Cleanup to convert physical address printing formats.
  ACPICA: Utilities: Cleanup to enforce ACPI_PHYSADDR_TO_PTR()/ACPI_PTR_TO_PHYSADDR().
  ...

Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
6 years agoLinux 3.14.43
Greg Kroah-Hartman [Sun, 17 May 2015 16:54:01 +0000 (09:54 -0700)]
Linux 3.14.43

6 years agokvm: arm64: vgic: fix hyp panic with 64k pages on juno platform
Will Deacon [Fri, 25 Jul 2014 15:29:12 +0000 (16:29 +0100)]
kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

commit 63afbe7a0ac184ef8485dac4914e87b211b5bfaa upstream.

If the physical address of GICV isn't page-aligned, then we end up
creating a stage-2 mapping of the page containing it, which causes us to
map neighbouring memory locations directly into the guest.

As an example, consider a platform with GICV at physical 0x2c02f000
running a 64k-page host kernel. If qemu maps this into the guest at
0x80010000, then guest physical addresses 0x80010000 - 0x8001efff will
map host physical region 0x2c020000 - 0x2c02efff. Accesses to these
physical regions may cause UNPREDICTABLE behaviour, for example, on the
Juno platform this will cause an SError exception to EL3, which brings
down the entire physical CPU resulting in RCU stalls / HYP panics / host
crashing / wasted weeks of debugging.

SBSA recommends that systems alias the 4k GICV across the bounding 64k
region, in which case GICV physical could be described as 0x2c020000 in
the above scenario.

This patch fixes the problem by failing the vgic probe if the physical
base address or the size of GICV aren't page-aligned. Note that this
generated a warning in dmesg about freeing enabled IRQs, so I had to
move the IRQ enabling later in the probe.

Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Joel Schopp <joel.schopp@amd.com>
Cc: Don Dutile <ddutile@redhat.com>
Acked-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Joel Schopp <joel.schopp@amd.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoarm64: kvm: use inner-shareable barriers for inner-shareable maintenance
Will Deacon [Fri, 2 May 2014 15:24:14 +0000 (16:24 +0100)]
arm64: kvm: use inner-shareable barriers for inner-shareable maintenance

commit ee9e101c11478680d579bd20bb38a4d3e2514fe3 upstream.

In order to ensure completion of inner-shareable maintenance instructions
(cache and TLB) on AArch64, we can use the -ish suffix to the dsb
instruction.

This patch relaxes our dsb sy instructions to dsb ish where possible.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoKVM: ARM: vgic: Fix the overlap check action about setting the GICD & GICC base address.
Haibin Wang [Tue, 29 Apr 2014 06:49:17 +0000 (14:49 +0800)]
KVM: ARM: vgic: Fix the overlap check action about setting the GICD & GICC base address.

commit 30c2117085bc4e05d091cee6eba79f069b41a9cd upstream.

Currently below check in vgic_ioaddr_overlap will always succeed,
because the vgic dist base and vgic cpu base are still kept UNDEF
after initialization. The code as follows will be return forever.

if (IS_VGIC_ADDR_UNDEF(dist) || IS_VGIC_ADDR_UNDEF(cpu))
                return 0;

So, before invoking the vgic_ioaddr_overlap, it needs to set the
corresponding base address firstly.

Signed-off-by: Haibin Wang <wanghaibin.wang@huawei.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoKVM: arm/arm64: vgic: fix GICD_ICFGR register accesses
Andre Przywara [Thu, 10 Apr 2014 22:07:18 +0000 (00:07 +0200)]
KVM: arm/arm64: vgic: fix GICD_ICFGR register accesses

commit f2ae85b2ab3776b9e4e42e5b6fa090f40d396794 upstream.

Since KVM internally represents the ICFGR registers by stuffing two
of them into one word, the offset for accessing the internal
representation and the one for the MMIO based access are different.
So keep the original offset around, but adjust the internal array
offset by one bit.

Reported-by: Haibin Wang <wanghaibin.wang@huawei.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoARM: KVM: trap VM system registers until MMU and caches are ON
Marc Zyngier [Tue, 14 Jan 2014 18:00:55 +0000 (18:00 +0000)]
ARM: KVM: trap VM system registers until MMU and caches are ON

commit 8034699a42d68043b495c7e0cfafccd920707ec8 upstream.

In order to be able to detect the point where the guest enables
its MMU and caches, trap all the VM related system registers.

Once we see the guest enabling both the MMU and the caches, we
can go back to a saner mode of operation, which is to leave these
registers in complete control of the guest.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoARM: KVM: add world-switch for AMAIR{0,1}
Marc Zyngier [Wed, 22 Jan 2014 10:20:09 +0000 (10:20 +0000)]
ARM: KVM: add world-switch for AMAIR{0,1}

commit af20814ee927ed888288d98917a766b4179c4fe0 upstream.

HCR.TVM traps (among other things) accesses to AMAIR0 and AMAIR1.
In order to minimise the amount of surprise a guest could generate by
trying to access these registers with caches off, add them to the
list of registers we switch/handle.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoARM: KVM: introduce per-vcpu HYP Configuration Register
Marc Zyngier [Wed, 22 Jan 2014 09:43:38 +0000 (09:43 +0000)]
ARM: KVM: introduce per-vcpu HYP Configuration Register

commit ac30a11e8e92a03dbe236b285c5cbae0bf563141 upstream.

So far, KVM/ARM used a fixed HCR configuration per guest, except for
the VI/VF/VA bits to control the interrupt in absence of VGIC.

With the upcoming need to dynamically reconfigure trapping, it becomes
necessary to allow the HCR to be changed on a per-vcpu basis.

The fix here is to mimic what KVM/arm64 already does: a per vcpu HCR
field, initialized at setup time.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoARM: KVM: fix ordering of 64bit coprocessor accesses
Marc Zyngier [Tue, 21 Jan 2014 18:56:26 +0000 (18:56 +0000)]
ARM: KVM: fix ordering of 64bit coprocessor accesses

commit 547f781378a22b65c2ab468f235c23001b5924da upstream.

Commit 240e99cbd00a (ARM: KVM: Fix 64-bit coprocessor handling)
added an ordering dependency for the 64bit registers.

The order described is: CRn, CRm, Op1, Op2, 64bit-first.

Unfortunately, the implementation is: CRn, 64bit-first, CRm...

Move the 64bit test to be last in order to match the documentation.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoARM: KVM: fix handling of trapped 64bit coprocessor accesses
Marc Zyngier [Tue, 21 Jan 2014 18:56:26 +0000 (18:56 +0000)]
ARM: KVM: fix handling of trapped 64bit coprocessor accesses

commit 46c214dd595381c880794413facadfa07fba5c95 upstream.

Commit 240e99cbd00a (ARM: KVM: Fix 64-bit coprocessor handling)
changed the way we match the 64bit coprocessor access from
user space, but didn't update the trap handler for the same
set of registers.

The effect is that a trapped 64bit access is never matched, leading
to a fault being injected into the guest. This went unnoticed as we
didn't really trap any 64bit register so far.

Placing the CRm field of the access into the CRn field of the matching
structure fixes the problem. Also update the debug feature to emit the
expected string in case of failing match.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoARM: KVM: force cache clean on page fault when caches are off
Marc Zyngier [Tue, 14 Jan 2014 19:13:10 +0000 (19:13 +0000)]
ARM: KVM: force cache clean on page fault when caches are off

commit 159793001d7d85af17855630c94f0a176848e16b upstream.

In order for a guest with caches disabled to observe data written
contained in a given page, we need to make sure that page is
committed to memory, and not just hanging in the cache (as guest
accesses are completely bypassing the cache until it decides to
enable it).

For this purpose, hook into the coherent_cache_guest_page
function and flush the region if the guest SCTLR
register doesn't show the MMU and caches as being enabled.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoarm64: KVM: flush VM pages before letting the guest enable caches
Marc Zyngier [Wed, 15 Jan 2014 12:50:23 +0000 (12:50 +0000)]
arm64: KVM: flush VM pages before letting the guest enable caches

commit 9d218a1fcf4c6b759d442ef702842fae92e1ea61 upstream.

When the guest runs with caches disabled (like in an early boot
sequence, for example), all the writes are diectly going to RAM,
bypassing the caches altogether.

Once the MMU and caches are enabled, whatever sits in the cache
becomes suddenly visible, which isn't what the guest expects.

A way to avoid this potential disaster is to invalidate the cache
when the MMU is being turned on. For this, we hook into the SCTLR_EL1
trapping code, and scan the stage-2 page tables, invalidating the
pages/sections that have already been mapped in.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoARM: KVM: introduce kvm_p*d_addr_end
Marc Zyngier [Tue, 18 Feb 2014 14:29:03 +0000 (14:29 +0000)]
ARM: KVM: introduce kvm_p*d_addr_end

commit a3c8bd31af260a17d626514f636849ee1cd1f63e upstream.

The use of p*d_addr_end with stage-2 translation is slightly dodgy,
as the IPA is 40bits, while all the p*d_addr_end helpers are
taking an unsigned long (arm64 is fine with that as unligned long
is 64bit).

The fix is to introduce 64bit clean versions of the same helpers,
and use them in the stage-2 page table code.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoarm64: KVM: trap VM system registers until MMU and caches are ON
Marc Zyngier [Tue, 14 Jan 2014 18:00:55 +0000 (18:00 +0000)]
arm64: KVM: trap VM system registers until MMU and caches are ON

commit 4d44923b17bff283c002ed961373848284aaff1b upstream.

In order to be able to detect the point where the guest enables
its MMU and caches, trap all the VM related system registers.

Once we see the guest enabling both the MMU and the caches, we
can go back to a saner mode of operation, which is to leave these
registers in complete control of the guest.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoarm64: KVM: allows discrimination of AArch32 sysreg access
Marc Zyngier [Tue, 21 Jan 2014 10:55:17 +0000 (10:55 +0000)]
arm64: KVM: allows discrimination of AArch32 sysreg access

commit 2072d29c46b73e39b3c6c56c6027af77086f45fd upstream.

The current handling of AArch32 trapping is slightly less than
perfect, as it is not possible (from a handler point of view)
to distinguish it from an AArch64 access, nor to tell a 32bit
from a 64bit access either.

Fix this by introducing two additional flags:
- is_aarch32: true if the access was made in AArch32 mode
- is_32bit: true if is_aarch32 == true and a MCR/MRC instruction
  was used to perform the access (as opposed to MCRR/MRRC).

This allows a handler to cover all the possible conditions in which
a system register gets trapped.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoarm64: KVM: force cache clean on page fault when caches are off
Marc Zyngier [Tue, 14 Jan 2014 19:13:10 +0000 (19:13 +0000)]
arm64: KVM: force cache clean on page fault when caches are off

commit 2d58b733c87689d3d5144e4ac94ea861cc729145 upstream.

In order for the guest with caches off to observe data written
contained in a given page, we need to make sure that page is
committed to memory, and not just hanging in the cache (as
guest accesses are completely bypassing the cache until it
decides to enable it).

For this purpose, hook into the coherent_icache_guest_page
function and flush the region if the guest SCTLR_EL1
register doesn't show the MMU  and caches as being enabled.
The function also get renamed to coherent_cache_guest_page.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodeal with deadlock in d_walk()
Al Viro [Sun, 26 Oct 2014 23:31:10 +0000 (19:31 -0400)]
deal with deadlock in d_walk()

commit ca5358ef75fc69fee5322a38a340f5739d997c10 upstream.

... by not hitting rename_retry for reasons other than rename having
happened.  In other words, do _not_ restart when finding that
between unlocking the child and locking the parent the former got
into __dentry_kill().  Skip the killed siblings instead...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Ben Hutchings <ben@decadent.org.uk>
[hujianyang: Backported to 3.14 refer to the work of Ben Hutchings in 3.2:
 - Adjust context to make __dentry_kill() apply to d_kill()]
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers.
Lv Zheng [Mon, 13 Apr 2015 03:48:52 +0000 (11:48 +0800)]
ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers.

commit 1d0a0b2f6df2bf2643fadc990eb143361eca6ada upstream.

ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6

For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT
and ACPI_FORMAT_UINT64() instead of
ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT().

This patch also removes above replaced macros as there are no users.

This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.

Link: https://github.com/acpica/acpica/commit/b6061237
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: George G. Davis <george_davis@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPICA: Utilities: Cleanup to convert physical address printing formats.
Lv Zheng [Mon, 13 Apr 2015 03:48:46 +0000 (11:48 +0800)]
ACPICA: Utilities: Cleanup to convert physical address printing formats.

commit cc2080b0e5a7c6c33ef5e9ffccbc2b8f6f861393 upstream.

ACPICA commit 7f06739db43a85083a70371c14141008f20b2198

For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to
convert the %p formats.

This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.

Link: https://github.com/acpica/acpica/commit/7f06739d
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
[gdavis: Apply changes to drivers/acpi/acpica/{tbutils,tbxfload}.c]
Signed-off-by: George G. Davis <george_davis@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPICA: Utilities: Cleanup to enforce ACPI_PHYSADDR_TO_PTR()/ACPI_PTR_TO_PHYSADDR().
Lv Zheng [Mon, 13 Apr 2015 03:48:37 +0000 (11:48 +0800)]
ACPICA: Utilities: Cleanup to enforce ACPI_PHYSADDR_TO_PTR()/ACPI_PTR_TO_PHYSADDR().

commit 6d3fd3cc33d50e4c0d0c0bd172de02caaec3127c upstream.

ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf

There are code pieces converting pointers using "(acpi_physical_address) x"
or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them.

Known issues:
1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field
   For the conversions around the table fields, it is better to fix it with
   alignment also fixed. So this patch doesn't modify such code. There
   should be no functional problem by leaving them unchanged.

Link: https://github.com/acpica/acpica/commit/154f6d07
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: George G. Davis <george_davis@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address.
Lv Zheng [Mon, 13 Apr 2015 03:48:18 +0000 (11:48 +0800)]
ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address.

commit f254e3c57b9d952e987502aefa0804c177dd2503 upstream.

ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3

OSPMs like Linux expect an acpi_physical_address returning value from
acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't
equal to sizeof (acpi_physical_address):
  drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default]
  In file included from include/acpi/acpi.h:64:0,
                   from include/linux/acpi.h:36,
                   from drivers/acpi/osl.c:41:
  include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *'
This patch corrects acpi_find_root_pointer().

Link: https://github.com/acpica/acpica/commit/7d9fd643
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: George G. Davis <george_davis@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agosound/oss: fix deadlock in sequencer_ioctl(SNDCTL_SEQ_OUTOFBAND)
Alexey Khoroshilov [Fri, 17 Apr 2015 23:53:25 +0000 (02:53 +0300)]
sound/oss: fix deadlock in sequencer_ioctl(SNDCTL_SEQ_OUTOFBAND)

commit bc26d4d06e337ade069f33d3f4377593b24e6e36 upstream.

A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND)
on /dev/sequencer with TMR_ECHO midi event.

In this case the control flow is:
sound_ioctl()
-> case SND_DEV_SEQ:
   case SND_DEV_SEQ2:
     sequencer_ioctl()
     -> case SNDCTL_SEQ_OUTOFBAND:
          spin_lock_irqsave(&lock,flags);
          play_event();
          -> case EV_TIMING:
               seq_timing_event()
               -> case TMR_ECHO:
                    seq_copy_to_input()
                    -> spin_lock_irqsave(&lock,flags);

It seems that spin_lock_irqsave() around play_event() is not necessary,
because the only other call location in seq_startplay() makes the call
without acquiring spinlock.

So, the patch just removes spinlocks around play_event().
By the way, it removes unreachable code in seq_timing_event(),
since (seq_mode == SEQ_2) case is handled in the beginning.

Compile tested only.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agommc: sh_mmcif: Fix timeout value for command request
Takeshi Kihara [Wed, 29 Apr 2015 17:03:51 +0000 (02:03 +0900)]
mmc: sh_mmcif: Fix timeout value for command request

commit bad4371d87d1d1ed1aecd9c9cc21c41ac3f289c8 upstream.

f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
changed the timeout value from 1000 jiffies to 1s. In the case where
HZ is 1000 the values are the same. However, for smaller HZ values the
timeout is now smaller, 1s instead of 10s in the case of HZ=100.

Since the timeout occurs in spite of a normal data transfer a timeout of
10s seems more appropriate. This restores the previous timeout in the
case where HZ=100 and results in an increase over the previous timeout
for larger values of HZ.

Fixes: f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[horms: rewrote changelog to refer to HZ]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agommc: core: add missing pm event in mmc_pm_notify to fix hib restore
Grygorii Strashko [Thu, 23 Apr 2015 10:43:43 +0000 (13:43 +0300)]
mmc: core: add missing pm event in mmc_pm_notify to fix hib restore

commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream.

The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:

WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access

Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().

Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agommc: card: Don't access RPMB partitions for normal read/write
Chuanxiao Dong [Tue, 12 Aug 2014 04:01:30 +0000 (12:01 +0800)]
mmc: card: Don't access RPMB partitions for normal read/write

commit 4e93b9a6abc0d028daf3c8a00cb77b679d8a4df4 upstream.

During kernel boot, it will try to read some logical sectors
of each block device node for the possible partition table.

But since RPMB partition is special and can not be accessed
by normal eMMC read / write CMDs, it will cause below error
messages during kernel boot:
...
 mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
 mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
 mmcblk0rpmb: retrying using single block read
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 end_request: I/O error, dev mmcblk0rpmb, sector 0
 Buffer I/O error on device mmcblk0rpmb, logical block 0
 end_request: I/O error, dev mmcblk0rpmb, sector 8
 Buffer I/O error on device mmcblk0rpmb, logical block 1
 end_request: I/O error, dev mmcblk0rpmb, sector 16
 Buffer I/O error on device mmcblk0rpmb, logical block 2
 end_request: I/O error, dev mmcblk0rpmb, sector 24
 Buffer I/O error on device mmcblk0rpmb, logical block 3
...

This patch will discard the access request in eMMC queue if
it is RPMB partition access request. By this way, it avoids
trigger above error messages.

Fixes: 090d25fe224c ("mmc: core: Expose access to RPMB partition")
Signed-off-by: Yunpeng Gao <yunpeng.gao@intel.com>
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Tested-by: Michael Shigorin <mike@altlinux.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agopinctrl: Don't just pretend to protect pinctrl_maps, do it for real
Doug Anderson [Fri, 1 May 2015 16:01:27 +0000 (09:01 -0700)]
pinctrl: Don't just pretend to protect pinctrl_maps, do it for real

commit c5272a28566b00cce79127ad382406e0a8650690 upstream.

Way back, when the world was a simpler place and there was no war, no
evil, and no kernel bugs, there was just a single pinctrl lock.  That
was how the world was when (57291ce pinctrl: core device tree mapping
table parsing support) was written.  In that case, there were
instances where the pinctrl mutex was already held when
pinctrl_register_map() was called, hence a "locked" parameter was
passed to the function to indicate that the mutex was already locked
(so we shouldn't lock it again).

A few years ago in (42fed7b pinctrl: move subsystem mutex to
pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
...but (oops) we forgot to re-think about the whole "locked" parameter
for pinctrl_register_map().  Basically the "locked" parameter appears
to still refer to whether the bigger pinctrl_dev mutex is locked, but
we're using it to skip locks of our (now separate) pinctrl_maps_mutex.

That's kind of a bad thing(TM).  Probably nobody noticed because most
of the calls to pinctrl_register_map happen at boot time and we've got
synchronous device probing.  ...and even cases where we're
asynchronous don't end up actually hitting the race too often.  ...but
after banging my head against the wall for a bug that reproduced 1 out
of 1000 reboots and lots of looking through kgdb, I finally noticed
this.

Anyway, we can now safely remove the "locked" parameter and go back to
a war-free, evil-free, and kernel-bug-free world.

Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/radeon: more strictly validate the UVD codec
Christian König [Thu, 7 May 2015 13:19:24 +0000 (15:19 +0200)]
drm/radeon: more strictly validate the UVD codec

commit d52cdfa4a0c6406bbfb33206341eaf1fb1555994 upstream.

MPEG 2/4 are only supported since UVD3.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/radeon: make UVD handle checking more strict
Christian König [Thu, 7 May 2015 13:19:23 +0000 (15:19 +0200)]
drm/radeon: make UVD handle checking more strict

commit a1b403da70e038ca6c6c6fe434d1d873546873a3 upstream.

Invalid messages can crash the hw otherwise.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/radeon: disable semaphores for UVD V1 (v2)
Christian König [Fri, 1 May 2015 10:34:12 +0000 (12:34 +0200)]
drm/radeon: disable semaphores for UVD V1 (v2)

commit 013ead48a843442e63b9426e3bd5df18ca5d054a upstream.

Hardware doesn't seem to work correctly, just block userspace in this case.

v2: add missing defines

Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/i915: Add missing MacBook Pro models with dual channel LVDS
Lukas Wunner [Mon, 4 May 2015 13:06:49 +0000 (15:06 +0200)]
drm/i915: Add missing MacBook Pro models with dual channel LVDS

commit 3916e3fd81021fb795bfbdb17f375b6b3685bced upstream.

Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models
shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz)
as a BTO option, both versions used dual channel LVDS even though
the smaller one would have fit into a single channel.

Notes:
  Bug report showing that the MacBookPro8,2 with 1440x900 uses dual
  channel LVDS (this lead to it being hardcoded in intel_lvds.c by
  Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc):
    https://bugzilla.kernel.org/show_bug.cgi?id=42842

  If i915.lvds_channel_mode=2 is missing even though the machine needs
  it, every other vertical line is white and consequently, only the left
  half of the screen is visible (verified by myself on a MacBookPro9,1).

  Forum posting concerning a MacBookPro6,2 with 1440x900, author is
  using i915.lvds_channel_mode=2 on the kernel command line, proving
  that the machine uses dual channels:
    https://bbs.archlinux.org/viewtopic.php?id=185770

  Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all
  MacBook Pro "A1286" models, and that model number encompasses the
  MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's
  driven with dual channel LVDS:
    http://www.ebay.com/itm/-/400690878560
    http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286
    http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf

  Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones
  with i915 graphics and dual channel LVDS, so that list should be
  complete. And the 8,2 is already in intel_lvds.c.

  Possible motivation to use dual channel LVDS even on the 1440x900
  models: Reduce the number of different parts, i.e. use identical logic
  boards and display cabling on both versions and the only differing
  component is the panel.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Jani Nikula <jani.nikula@intel.com>
[Jani: included notes in the commit message for posterity]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>