Add ARM System Profiler example usage script

The ARM System Profiler driver exposes System Profiler registers via.
debugfs files. The user space can program and later capture metrics from
System Profiler by accessing these files.

This script stands as an example for the System Profiler's usage.

arm64/juno: Add device tree node for the system profiler

This patch adds a device node for the system profiler on Juno.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>

bus/arm-system-profiler: Basic driver for the ARM System Profiler

This patch implements a basic driver for the ARM System Profiler

The System Profiler registers are exposed symbolically via debugfs,
allowing root do manipulate and experiment with the profiler.
If an interrupt is defined for the profiler in the device tree and
ftrace is enabled, then captured data can be streamed out via trace
events.

The current user interface is minimal, with virtually no abstraction.

Future versions of the driver may substantially change the interface,
so it should be considered experimental for now.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>

Juno: Change I2C bus speed used for HDMI to 100kHz.

The I2C bus driver has problems under heavy load to keep the FIFO
filled. Combined with the auto-STOP setting baked into the hardware,
it spells disaster for conversations with HDMI chip, specially
around the boot time when we want to retrieve the EDID information.

Change the bus speed to 100kHz to increase the chance of servicing
the "FIFO empty" interrupt in time.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

i2c: designware: Add support for changing the bus rate based on DT info

The Designware I2C driver does not currently support changing the bus
speed even if the hardware is capable of switching to a slower frequency.
Add support for passing the clock frequency info in the device tree.
Only standard (100kHz) or fast (400kHz) speeds are supported.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

ASoC: dwc: Ensure FIFOs are flushed to prevent channel swap

If the FIFOs aren't flushed, the left/right channels may be swapped:
this may occur if the FIFOs are not empty when the streams start.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>

Juno: defconfig: Enable PL330 DMA and Designware I2S support

Enable PL330 DMA engine and Designware I2S support in the defconfig.
However, DMA and PL011 UART doesn't work, so comment out the DMA
channels in PL011 to work around hang in the boot.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

ALSA: pcm: 64 bit ARM has coherent DMA too

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>

Juno: Add I2S and TDA998x audio CODEC support.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>

ASoC: dwc: Add devicetree support for Designware I2S

Convert to driver to use either platform_data or device-tree for configuration
of the device.  When using device-tree, the I2S block's configuration is read
from the relevant registers: this reduces the amount of information required in
the device tree.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>

ASoC: dwc: Iterate over all channels

On the Designware core, the channels are independent and not combined
in higher registers.  So as more channels are added, more registers need
to be updated.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>

ASoC: dwc: Don't allow negative use counts

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>

ASoC: dwc: Allocate resources with platform_get_resource

Reorder allocations and use updated interface, platform_get_resource, to allocate
IO mapping.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>

drm: i2c: tda998x: Select appropriate sound clock rate

The average CTS value is based upon the (pixel) clock rate.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>

ASoC: tda998x: add a codec to the HDMI transmitter

This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.

The CODEC handles both I2S and S/PDIF input and does dynamic input
switch in the TDA998x I2C driver on start/stop audio streaming.

Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
[added reg documentation for the DT bindings]
Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: i2c: tda998x: Retry fetching the EDID if it fails first time.

Fetching the EDID from a connected monitor is an automated thing
with NXP TDA19988. But on some boards the fetching fails for the
first time silently without any indication that an error has occured.
More than that, subsequent fetches of the EDID succeed until the
monitor(s) are pluged out.

Add a function to validate the read EDID and retry if the block
retrieved is not valid.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

scpi: Increase the maximum number of DVFS OPPs

Signed-off-by: Filipe Rinaldi <filipe.rinaldi@arm.com>

scpi: Add voltage on the DVFS Info command

Newer versions of SCP added voltage as one of the parameters in the
DVFS Info command. This patch reads the voltage which can be used by
CPUFreq and Devfreq.

Signed-off-by: Filipe Rinaldi <filipe.rinaldi@arm.com>

arm64: report correct stack pointer in KSTK_ESP for compat tasks

The KSTK_ESP macro is used to determine the user stack pointer for a
given task. In particular, this is used to to report the '[stack]' VMA
in /proc/self/maps, which is used by Android to determine the stack
location for children of the main thread.

This patch fixes the macro to use user_stack_pointer instead of directly
returning sp. This means that we report w13 instead of sp, since the
former is used as the stack pointer when executing in AArch32 state.

Cc: <stable@vger.kernel.org>
Reported-by: Serban Constantinescu <Serban.Constantinescu@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Conflicts:
arch/arm64/include/asm/processor.h

arm64: Add brackets around user_stack_pointer()

Commit 5f888a1d33 (ARM64: perf: support dwarf unwinding in compat mode)
changes user_stack_pointer() to return the compat SP for 32-bit tasks
but without brackets around the whole definition, with possible issues
on the call sites (noticed with a subsequent fix for KSTK_ESP).

Fixes: 5f888a1d33c4 (ARM64: perf: support dwarf unwinding in compat mode)
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Revert "arm64: Juno: Disable CPU idle states for now."

This reverts commit dd0f50e31b767c9e6c54c2971982047e7975a028.

The latest firmware has significantly improved the stability of
CPUidle/CPUfreq.

hmp: dont attempt to pull tasks if affinity doesn't allow it

When looking for a task to be idle-pulled, don't consider tasks
where the affinity does not allow that task to be placed on the
target CPU. Also ensure that tasks with restricted affinity
do not block selecting other unrestricted busy tasks.

Use the knowledge of target CPU more effectively in idle pull
by passing to hmp_get_heaviest_task when we know it, otherwise
only checking for general affinity matches with any of the CPUs
in the bigger HMP domain.

We still need to explicitly check affinity is allowed in idle pull
since if we find no match in hmp_get_heaviest_task we will return
the current one, which may not be affine to the new CPU despite
having high enough load. In this case, there is nothing to move.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

Revert "hmp: dont attempt to pull tasks if affinity doesn't allow it"

This reverts commit 95365d0a9ec7c16fbe25682998f898e400c27177.

sched: hmp: Change small task packing defaults for all platforms

All platforms other than TC2 default to enabling packing. Since TC2
shows no performance or energy degradation with this feature enabled
make it default enabled the same as everyone else.
Likewise, vendors have been including TC2 support in multi-machine
kernel builds so they expect the default thresholds to remain the
same when the TC2 #ifdef is removed.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

hmp: dont attempt to pull tasks if affinity doesn't allow it

When looking for a task to be idle-pulled, don't consider tasks
where the affinity does not allow that task to be placed on the
target CPU. Also ensure that tasks with restricted affinity
do not block selecting other unrestricted busy tasks.

Use the knowledge of target CPU more effectively in idle pull
by passing to hmp_get_heaviest_task when we know it, otherwise
only checking for general affinity matches with any of the CPUs
in the bigger HMP domain.

We still need to explicitly check affinity is allowed in idle pull
since if we find no match in hmp_get_heaviest_task we will return
the current one, which may not be affine to the new CPU despite
having high enough load. In this case, there is nothing to move.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

hmp: Use idle pull to perform forced up-migrations

When a normal forced up-migration takes place we stop the task to
be migrated while the target CPU becomes available. This delay can
range from 80us to 1500us on TC2 if the target CPU is in a deep idle
state.

Instead, interrupt the target CPU and ask it to pull a task.
This lets the current eligible task continue executing on the
original CPU while the target CPU wakes. Use a pinned timer to
prevent the pulling CPU going back into power-down with pending
up-migrations.

If we trigger for a nohz kick, it doesn't matter about triggering
for an idle pull since the idle_pull flag will be set when we
execute the softirq and we'll still do the idle pull.

If the target CPU is busy, we will not pull any tasks.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
[ Rebased on top of 1.1-Juno-rc0 ]
[ Add missing this_cpu in run_rebalance_domains() ]
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>

sched: hmp: unify active migration code

The HMP active migration code is functionally identical to the CFS
active migration code apart from one flag check. Share the code
and make the flag check optional.

Two wrapper functions allow the flag check to be present or not.

Thanks to tixy@linaro.org for pointing out the build break and a
good solution in an earlier version.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
[ Rebased on top of 1.1-Juno-rc0 ]
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>

hmp: sched: Clean up hmp_up_threshold checks into a utility fn

In anticipation of modifying the up_threshold handling, make all
instances use the same utility fn to check if a task is eligible
for up-migration. This also removes the previous difference in
threshold comparison where up-migration used '!<threshold' and
idle pull used '>threshold' to decide up-migration eligibility.
Make them both use '!<threshold' instead for consistency, although
this is unlikely to change any results.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

usb: Fix H20AHB driver for big-endian

Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Support PSCI reboot/shutdown

Hack in the extra function IDs in lieu of 'proper' PSCi 0.2 support.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Set the CEC I2C address based on the slave I2C address.

The two LSBs of the TDA998x's I2C address are set by pins
on the chip. The associated CEC peripheral's I2C address
is set in the same way, so base the CEC address on that
of the slave's address.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Revert "drm: i2c: tda998x: Retry fetching the EDID if it fails first time."

This reverts commit 7d0d4cedd12513703239172eb9a7a3465cb8a6ec.

This was a stopgap solution until the real bug was properly understood.
Now that I2C transactions can be relied on, we don't need this anymore.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

i2c: designware: prevent early stop on TX FIFO empty

If the Designware core is configured with IC_EMPTYFIFO_HOLD_MASTER_EN
set to zero, allowing the TX FIFO to become empty causes a STOP
condition to be generated on the I2C bus. If the transmit FIFO
threshold is set too high, an erroneous STOP condition can be
generated on long transfers - particularly where the interrupt
latency is extended.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: Re-add DMT modes for monitors

Commit 196e077dc165a307efbd9e7569f81bbdbcf18f65
"drm: don't add inferred modes for monitors that don't support them"

It remove the call add_inferred_modes when DRM_EDID_FEATURE_DEFAULT_GTF
in feature support field is zero, this remove all inferred modes
come from GTF or CVT range information, and also remove DMT modes,
this make me lost some avaiable modes for my TV.

Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

DRM: HDLCD: Enable compat IOCTL for 32-bit userspace.

32-bit userspace should be able to use double buffering in the
same way native binaries do, so enable it.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Enable Heterogenous Multi Processing by default

HMP needs more tuning but its usefulness has been proved
so enable it by default. There might still be corner cases
where issues will crop up, but for demos and evaluation
is should be ready to use.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

sched: hmp: fix out-of-range CPU possible

If someone hotplugs all the little CPUs while another CPU is handling
a wakeup, we can potentially return new_cpu == NR_CPUS from
hmp_select_slower_cpu (which is called internally by
hmp_best_little_cpu as well). We will use this to deref the
per_cpu rq array in hmp_next_down_delay which can go boom.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>

drm: hdlcd: Add debugfs entry for displaying current pixelclock value

When asking the hardware to set a new pixelclock value we might
timeout on values that are calculated during request and not
wait for the actual outcome of the clock setting. SCP could still
finish the brute force search for the best PLL settings and might
or might not set the requested resolution. To help track the
current value of the pixelclock, add a new entry in debugfs that
displays the HW programmed value vs the one that was requested
for the current running mode.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

juno: defconfig: Enable multi-touch HID devices in defconfig

mailbox: mhu: Acknowledge the interrupt only after data is pushed

According to the mailbox documentation the controller should ACK
the RX only after it has finished pushing the data up the link.

Signed-off-by: Punit Agrawal <Punit.Agrawal@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

mailbox: scpi: Free the mailbox channel when we fail to queue a message.

When sending an SCPI command we aquire a channel and queue the
message in the mailbox. If the queuing failed we were not releasing
the channel hence preventing everyone else from using it.

Signed-off-by: Punit Agrawal <Punit.Agrawal@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: hdlcd: Don't depend on VSYNC interrupt when setting new framebuffer.

VSYNC state is influenced by the DRM framework and cannot be relied
on when setting a new framebuffer base address and synchronising with
the hardware. Use the DMA_END interrupt as it is a more reliable way
of signaling the end of frame utilisation.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

mailbox: Pack SCPI structures used for messages.

The System Control Processor expects data sent in the messages
to be contiguos. When using unpacked structures to describe
the data being transmitted we increase the general size of the
message which leads to SCP rejecting our request.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: defconfig: Enable CPUidle driver by default.

Enable the arm64 CPUidle driver by default.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Juno: Comment out the secondary HDLCD controller

The HDLCD controllers on Juno share the same PLL for the pixel
clock output. If the secondary output is not connected to a
monitor with the same resolution as the primary output, or
to a monitor with VGA resolution, it will cause the pixel
clock to be set to the wrong value for the primary output.
Comment out the secondary HDLCD controller for now.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: i2c: tda998x: Retry fetching the EDID if it fails first time.

Fetching the EDID from a connected monitor is an automated thing
with NXP TDA19988. But on some boards the fetching fails for the
first time silently without any indication that an error has occured.
More than that, subsequent fetches of the EDID succeed until the
monitor(s) are pluged out.

Add a function to validate the read EDID and retry if the block
retrieved is not valid.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: hdlcd: Fix the picture tear when flipping framebuffers.

HDLCD contains logic in hardware to wait for VSYNC before updating
the start of framebuffer register, so we don't need to do it in
software. More than that, to remove any tearing we need to wait
for VSYNC after setting up a new framebuffer as releasing the old
fb while the hardware is still using it can cause artifacts.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Update README.md in preparation for Beta release.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Juno: Collect last remaining updates in preparation release.

Update the Mali device tree node label, register size resource,
update GICv2 register resource and remove UAS as a module from
defconfig. All small patches that were sitting in my inbox.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Update defconfig to bump the CMA buffer size to 32MB and enable ION.

These changes are needed to enable the HDLCD to do double
buffering correctly with Android and Mali drivers.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: arm: Add support for PRIME and dma_buf buffer sharing.

Add support for buffer sharing in HDLCD and implement proprietary
IOCTL from ARM Mali driver to get a file descriptor for the buffer.
This is used by the Mali kernel driver to import the buffers into
DDK and enable double buffering.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

staging: android: ion: Set the length of the DMA sg entries in buffer.

ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Juno: Disable CPU idle states for now.

CPU idle has not received enough testing to pass release status,
so we need to disable it for now.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: juno: Update defconfig to enable IPv6 options for Android

Android wants to use IPv6 features, so lets enable them.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

usb: fix hcd h20ahb driver depends

USB_EHCI_HCD_SYNOPSYS is not only dependent on USB_EHCI_HCD, but
also on USB_PHY. Otherwise kernel build has the following error:

  LD      init/built-in.o
drivers/built-in.o: In function `ehci_hcd_h20ahb_probe':
:(.text+0xb9bb4): undefined reference to `usb_add_phy_dev'

Signed-off-by: Alex Shi <alex.shi@linaro.org>

arm64: Juno: Carve out memory reserved for secure access.

Trusted Firmware 0.4 reserves the top 16MB of RAM available
in the first 4GB address space for the secure world use.
Carve out that memory from the device tree to avoid triggering
faults when accessing protected memory.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Merge remote-tracking branch 'sudeep/juno_freq+idle' into juno-release

Conflicts:
arch/arm64/boot/dts/juno.dts
arch/arm64/configs/defconfig
arch/arm64/kernel/topology.c
drivers/clk/clk-scpi.c
drivers/cpufreq/scpi-cpufreq.c
drivers/input/serio/ambakmi.c
drivers/mailbox/arm_mhu.c
include/uapi/linux/audit.h

fixup! mailbox: add support for ARM Message Handling Unit(MHU) controller

TODO:
Yet to identify on what paths we need to clear the RX status if the
protocol timed out and frees the channel. For now have it in startup,
shutdown and interrupt...

juno: add untuned C-state details to device tree

Also add hack to workaround mmaped timer access issue

Merge branch 'arm64/unstable/arm64-cpuidle' of git://linux-arm.org/linux-2.6-lp into juno_mhu_clk_dvfs

* 'arm64/unstable/arm64-cpuidle' of git://linux-arm.org/linux-2.6-lp:
  arm64: boot: dts: update rtsm aemv8 dts with PSCI and idle states
  drivers: cpuidle: CPU idle ARM64 driver
  arm64: add PSCI CPU_SUSPEND based cpu_suspend support
  drivers: cpuidle: implement OF based idle states infrastructure

Temp commit to add Juno DTS and additional configs

cpufreq: [HORRIBLE DIRTY HACK] get arm_big_little compiling on arm64

*******!!!!!!!!****** ONLY FOR TESTING *************!!!!!!!!!***************

Currently the addition of switcher code has created too much dependencies
to get this driver compiling on ARM64. For time being add dirty compilation
hacks to test CPUFreq on Juno.

****!!!!!!!***** THIS NEEDS TO BE REWORKED *********!!!!!!!!****************

Not-at-all-Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

cpufreq: arm_big_little: add SPCI interface driver

On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control including CPU DVFS. SCPI Message Protocol is used to
communicate with the SCPI.

This patch adds a interface driver for adding OPPs and registering
the arm_big_little cpufreq driver for such systems.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

clk: add support for clocks provided by system control processor

On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control. System Control and Power Interface(SCPI) Message Protocol
is defined for the communication between the Application Cores(AP)
and the SCP.

This patch adds support for the clocks provided by SCP using SCPI
protocol.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

mailbox: add support for System Control and Power Interface(SCPI) protocol

This patch add supports for System Control and Power Interface (SCPI)
Message Protocol used between the Application Cores(AP) and the System
Control Processor(SCP). The MHU peripheral provides a mechanism for
inter-processor communication between SCP's M3 processor and AP.

SCP offers control and management of the core/cluster power states,
various power domain DVFS including the core/cluster, certain system
clocks configuration, thermal sensors and many others.

This protocol library provides interface for all the client drivers using
SCPI to make use of the features offered by the SCP.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

mailbox: add support for ARM Message Handling Unit(MHU) controller

This patch adds support for ARM Message Handling Unit(MHU) controller
that provides control logic and interrupt generation to support
inter-processor communication between the Application Processor and
the System Control Processor(SCP).

This support is built on the existing common mailbox framework for
client/protocol drivers and controller drivers of Inter Processor
Communication(IPC). SCP controls most of the power management on the
Application Processors.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

arm64: add ARCH_HAS_OPP to allow enabling OPP library

The Operating Performance Point (OPP) Layer library is a generic
library used by CPUFREQ and DEVFREQ. It can be enabled only on the
platforms that specify ARCH_HAS_OPP option.

This patch selects that option in order to allow ARM64 based platforms
to use OPP library.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

arm64: restore alphabetic order in Kconfig

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Merge branches 'cpu_topology' and 'mailbox' into juno_mhu_clk_dvfs

* cpu_topology:
  arm64: topology: Provide relative power numbers for cores
  arm64: topology: Tell the scheduler about the relative power of cores
  arm64: topology: add MPIDR-based detection
  arm64: topology: Add support for topology DT bindings
  arm64: topology: Initialise default topology state immediately
  arm64: sched: Remove unused mc_capable() and smt_capable()

* mailbox:
  mailbox: Fix deleteing poll timer
  mailbox: Fix TX completion init
  mailbox: pl320: Introduce common API driver
  mailbox: Introduce framework for mailbox
  mailbox: rename pl320-ipc specific mailbox.h

arm64: topology: Provide relative power numbers for cores

Provide performance numbers to the scheduler to help it fill the cores in
the system on big.LITTLE systems. With the current scheduler this may
perform poorly for applications that try to do OpenMP style work over all
cores but should help for more common workloads. The current 32 bit ARM
implementation provides a similar estimate so this helps ensure that
work to improve big.LITTLE systems on ARMv7 systems performs similarly
on ARMv8 systems.

The power numbers are the same as for ARMv7 since it seems that the
expected differential between the big and little cores is very similar on
both ARMv7 and ARMv8.  In both ARMv7 and ARMv8 cases the numbers were
based on the published DMIPS numbers.

These numbers are just an initial and basic approximation for use with
the current scheduler, it is likely that both experience with silicon
and ongoing work on improving the scheduler will lead to further tuning
or will tune automatically at runtime and so make the specific choice of
numbers here less critical.

Signed-off-by: Mark Brown <broonie@linaro.org>

arm64: topology: Tell the scheduler about the relative power of cores

In heterogeneous systems like big.LITTLE systems the scheduler will be
able to make better use of the available cores if we provide power numbers
to it indicating their relative performance. Do this by parsing the CPU
nodes in the DT.

This code currently has no effect as no information on the relative
performance of the cores is provided.

Signed-off-by: Mark Brown <broonie@linaro.org>

arm64: topology: add MPIDR-based detection

Create cpu topology based on MPIDR. When hardware sets MPIDR to sane
values, this method will always work. Therefore it should also work well
as the fallback method. [1]

When we have multiple processing elements in the system, we create
the cpu topology by mapping each affinity level (from lowest to highest)
to threads (if they exist), cores, and clusters.

We combine data from all higher affinity levels into cluster_id
so we don't lose any information from MPIDR. [2]

[1] http://www.spinics.net/lists/arm-kernel/msg317445.html
[2] https://lkml.org/lkml/2014/4/23/703

[Raise the priority of the error message if we don't discover topology
now that we can read it from MPIDIR -- broonie]

Signed-off-by: Zi Shen Lim <zlim@broadcom.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

arm64: topology: Add support for topology DT bindings

Add support for parsing the explicit topology bindings to discover the
topology of the system.

Since it is not currently clear how to map multi-level clusters for the
scheduler all leaf clusters are presented to the scheduler at the same
level. This should be enough to provide good support for current systems.

Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

arm64: topology: Initialise default topology state immediately

As a legacy of the way 32 bit ARM did things the topology code uses a null
topology map by default and then overwrites it by mapping cores with no
information to a cluster by themselves later. In order to make it simpler
to reset things as part of recovering from parse failures in firmware
information directly set this configuration on init. A core will always be
its own sibling so there should be no risk of confusion with firmware
provided information.

Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

arm64: sched: Remove unused mc_capable() and smt_capable()

Remove unused and deprecated mc_capable() and smt_capable().

Both were added recently by f6e763b93a6c ("arm64: topology:
Implement basic CPU topology support"). Uses of both were removed
by 8e7fbcbc22c1 ("sched: Remove stale power aware scheduling
remnants and dysfunctional knobs").

Signed-off-by: Zi Shen Lim <zlim@broadcom.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

mailbox: Fix deleteing poll timer

Try to delete the timer only if it was init/used.

Signed-off-by: LeyFoon Tan <lftan.linux@gmail.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

mailbox: Fix TX completion init

For fast TX the complete could be called before being initialized as follows
 mbox_send_message --> poll_txdone --> tx_tick --> complete(&chan->tx_complete)

Init the completion early enough to fix the race.

Signed-off-by: LeyFoon Tan <lftan.linux@gmail.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

mailbox: pl320: Introduce common API driver

Convert the PL320 controller driver to work with the common
mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
to work with thee API. Drop the obsoleted driver pl320-ipc.c

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

mailbox: Introduce framework for mailbox

Introduce common framework for client/protocol drivers and
controller drivers of Inter-Processor-Communication (IPC).

Client driver developers should have a look at
 include/linux/mailbox_client.h to understand the part of
the API exposed to client drivers.
Similarly controller driver developers should have a look
at include/linux/mailbox_controller.h

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

mailbox: rename pl320-ipc specific mailbox.h

The patch 30058677 "ARM / highbank: add support for pl320 IPC"
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.

Acked-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Linux 3.15-rc8

Merge branch 'merge' of git://git./linux/kernel/git/benh/powerpc

Pull powerpc fix from Ben Herrenschmidt:
 "Here's just one trivial patch to wire up sys_renameat2 which I seem to
  have completely missed so far.

  (My test build scripts fwd me warnings but miss the ones generated for
  missing syscalls)"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Wire renameat2() syscall

Merge branch 'upstream' of git://git.linux-mips.org/ralf/upstream-linus

Pull MIPS fixes from Ralf Baechle:
 "A fair number of fixes across the field.  Nothing terribly
  complicated; the one liners in below changelog should be fairly
  descriptive.

  Noteworthy is the SB1 change which the result of changes to binutils
  resulting in one big gas warning for most files being assembled as
  well as the asid_cache and branch emulation fixes which fix corruption
  or possible uninteded behaviour of kernel or application code.  The
  remainder of fixes are more platforms or subsystem specific"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: R46000: Fix Micro-assembler field overflow for R4600 V2
  MIPS: ptrace: Avoid smp_processor_id() in preemptible code
  MIPS: Lemote 2F: cs5536: mfgpt: use raw locks
  MIPS: SB1: Fix excessive kernel warnings.
  MIPS: RC32434: fix broken PCI resource initialization
  MIPS: malta: memory.c: Initialize the 'memsize' variable
  MIPS: Fix typo when reporting cache and ftlb errors for ImgTec cores
  MIPS: Fix inconsistancy of __NR_Linux_syscalls value
  MIPS: Fix branch emulation of branch likely instructions.
  MIPS: Fix a typo error in AUDIT_ARCH definition
  MIPS: Change type of asid_cache to unsigned long

Merge branch 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull scheduler fixes from Ingo Molnar:
 "Various fixlets, mostly related to the (root-only) SCHED_DEADLINE
  policy, but also a hotplug bug fix and a fix for a NR_CPUS related
  overallocation bug causing a suspend/resume regression"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Fix hotplug vs. set_cpus_allowed_ptr()
  sched/cpupri: Replace NR_CPUS arrays
  sched/deadline: Replace NR_CPUS arrays
  sched/deadline: Restrict user params max value to 2^63 ns
  sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE
  sched: Disallow sched_attr::sched_policy < 0
  sched: Make sched_setattr() correctly return -EFBIG

powerpc: Wire renameat2() syscall

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Merge branch 'core-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull core futex/rtmutex fixes from Thomas Gleixner:
 "Three fixlets for long standing issues in the futex/rtmutex code
  unearthed by Dave Jones syscall fuzzer:

   - Add missing early deadlock detection checks in the futex code
   - Prevent user space from attaching a futex to kernel threads
   - Make the deadlock detector of rtmutex work again

  Looks large, but is more comments than code change"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  rtmutex: Fix deadlock detector for real
  futex: Prevent attaching to kernel threads
  futex: Add another early deadlock detection check

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "Mostly quiet now:

  i915:
    fixing userspace visiblie issues, all stable marked

  radeon:
    one more pll fix, two crashers, one suspend/resume regression"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: Resume fbcon last
  drm/radeon: only allocate necessary size for vm bo list
  drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission
  drm/radeon: avoid crash if VM command submission isn't available
  drm/radeon: lower the ref * post PLL maximum once more
  drm/i915: Prevent negative relocation deltas from wrapping
  drm/i915: Only copy back the modified fields to userspace from execbuffer
  drm/i915: Fix dynamic allocation of physical handles

dcache: add missing lockdep annotation

lock_parent() very much on purpose does nested locking of dentries, and
is careful to maintain the right order (lock parent first).  But because
it didn't annotate the nested locking order, lockdep thought it might be
a deadlock on d_lock, and complained.

Add the proper annotation for the inner locking of the child dentry to
make lockdep happy.

Introduced by commit 046b961b45f9 ("shrink_dentry_list(): take parent's
->d_lock earlier").

Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drm/radeon: Resume fbcon last

So a few people complained that

commit 177cf92de4aa97ec1435987e91696ed8b5023130
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 1 22:14:59 2014 +0200

    drm/crtc-helpers: fix dpms on logic

which was merged into 3.15-rc1, broke resume on radeons. Strangely git
bisect lead everyone to

commit 25f397a429dfa43f22c278d0119a60a343aa568f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jul 19 18:57:11 2013 +0200

    drm/crtc-helper: explicit DPMS on after modeset

which was merged long ago and actually part of 3.14.

Digging deeper I've noticed (again) that the call to
drm_helper_resume_force_mode in the radeon resume handlers was a no-op
previously because everything gets shut down on suspend. radeon does
this with explicit calls to drm_helper_connector_dpms with DPMS_OFF.
But with 177c we now force the dpms state to ON, so suddenly
resume_force_mode actually forced the crtcs back on.

This is the intention of the change after all, the problem is that
radeon resumes the fbdev console layer _before_ restoring the display,
through calling fb_set_suspend. And fbcon does an immediate ->set_par,
which in turn causes the same forced mode restore to happen.

Two concurrent modeset operations didn't lead to happiness. Fix this
by delaying the fbcon resume until the end of the readeon resum
functions.

v2: Fix up a bit of the spelling fail.

References: https://lkml.org/lkml/2014/5/29/1043
References: https://lkml.org/lkml/2014/5/2/388
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751
Tested-by: Ken Moffat <zarniwhoop@ntlworld.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ken Moffat <zarniwhoop@ntlworld.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>

Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes

this is the next pull request for stashed up radeon fixes for 3.15. This is finally calming down with only four patches in this pull request.

* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
  drm/radeon: only allocate necessary size for vm bo list
  drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission
  drm/radeon: avoid crash if VM command submission isn't available
  drm/radeon: lower the ref * post PLL maximum once more

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input subsystem fixes from Dmitry Torokhov:
 "A couple of driver/build fixups and also redone quirk for Synaptics
  touchpads on Lenovo boxes (now using PNP IDs instead of DMI data to
  limit number of quirks)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: synaptics - change min/max quirk table to pnp-id matching
  Input: synaptics - add a matches_pnp_id helper function
  Input: synaptics - T540p - unify with other LEN0034 models
  Input: synaptics - add min/max quirk for the ThinkPad W540
  Input: ambakmi - request a shared interrupt for AMBA KMI devices
  Input: pxa27x-keypad - fix generating scancode
  Input: atmel-wm97xx - only build for AVR32
  Input: fix ps2/serio module dependency

Merge tag 'firewire-fixes' of git://git./linux/kernel/git/ieee1394/linux1394

Pull firewire fix from Stefan Richter:
 "A regression fix for the IEEE 1394 subsystem: re-enable IRQ-based
  asynchronous request reception at addresses below 128 TB"

* tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
  firewire: revert to 4 GB RDMA, fix protocols using Memory Space

Merge tag 'dm-3.15-fixes-3' of git://git./linux/kernel/git/device-mapper/linux-dm

Pull device-mapper fixes from Mike Snitzer:
 "A dm-cache stable fix to split discards on cache block boundaries
  because dm-cache cannot yet handle discards that span cache blocks.

  Really fix a dm-mpath LOCKDEP warning that was introduced in -rc1.

  Add a 'no_space_timeout' control to dm-thinp to restore the ability to
  queue IO indefinitely when no data space is available.  This fixes a
  change in behavior that was introduced in -rc6 where the timeout
  couldn't be disabled"

* tag 'dm-3.15-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm mpath: really fix lockdep warning
  dm cache: always split discards on cache block boundaries
  dm thin: add 'no_space_timeout' dm-thin-pool module param

x86_64: expand kernel stack to 16K

While I play inhouse patches with much memory pressure on qemu-kvm,
3.14 kernel was randomly crashed. The reason was kernel stack overflow.

When I investigated the problem, the callstack was a little bit deeper
by involve with reclaim functions but not direct reclaim path.

I tried to diet stack size of some functions related with alloc/reclaim
so did a hundred of byte but overflow was't disappeard so that I encounter
overflow by another deeper callstack on reclaim/allocator path.

Of course, we might sweep every sites we have found for reducing
stack usage but I'm not sure how long it saves the world(surely,
lots of developer start to add nice features which will use stack
agains) and if we consider another more complex feature in I/O layer
and/or reclaim path, it might be better to increase stack size(
meanwhile, stack usage on 64bit machine was doubled compared to 32bit
while it have sticked to 8K. Hmm, it's not a fair to me and arm64
already expaned to 16K. )

So, my stupid idea is just let's expand stack size and keep an eye
toward stack consumption on each kernel functions via stacktrace of ftrace.
For example, we can have a bar like that each funcion shouldn't exceed 200K
and emit the warning when some function consumes more in runtime.
Of course, it could make false positive but at least, it could make a
chance to think over it.

I guess this topic was discussed several time so there might be
strong reason not to increase kernel stack size on x86_64, for me not
knowing so Ccing x86_64 maintainers, other MM guys and virtio
maintainers.

Here's an example call trace using up the kernel stack:

         Depth    Size   Location    (51 entries)
         -----    ----   --------
   0)     7696      16   lookup_address
   1)     7680      16   _lookup_address_cpa.isra.3
   2)     7664      24   __change_page_attr_set_clr
   3)     7640     392   kernel_map_pages
   4)     7248     256   get_page_from_freelist
   5)     6992     352   __alloc_pages_nodemask
   6)     6640       8   alloc_pages_current
   7)     6632     168   new_slab
   8)     6464       8   __slab_alloc
   9)     6456      80   __kmalloc
  10)     6376     376   vring_add_indirect
  11)     6000     144   virtqueue_add_sgs
  12)     5856     288   __virtblk_add_req
  13)     5568      96   virtio_queue_rq
  14)     5472     128   __blk_mq_run_hw_queue
  15)     5344      16   blk_mq_run_hw_queue
  16)     5328      96   blk_mq_insert_requests
  17)     5232     112   blk_mq_flush_plug_list
  18)     5120     112   blk_flush_plug_list
  19)     5008      64   io_schedule_timeout
  20)     4944     128   mempool_alloc
  21)     4816      96   bio_alloc_bioset
  22)     4720      48   get_swap_bio
  23)     4672     160   __swap_writepage
  24)     4512      32   swap_writepage
  25)     4480     320   shrink_page_list
  26)     4160     208   shrink_inactive_list
  27)     3952     304   shrink_lruvec
  28)     3648      80   shrink_zone
  29)     3568     128   do_try_to_free_pages
  30)     3440     208   try_to_free_pages
  31)     3232     352   __alloc_pages_nodemask
  32)     2880       8   alloc_pages_current
  33)     2872     200   __page_cache_alloc
  34)     2672      80   find_or_create_page
  35)     2592      80   ext4_mb_load_buddy
  36)     2512     176   ext4_mb_regular_allocator
  37)     2336     128   ext4_mb_new_blocks
  38)     2208     256   ext4_ext_map_blocks
  39)     1952     160   ext4_map_blocks
  40)     1792     384   ext4_writepages
  41)     1408      16   do_writepages
  42)     1392      96   __writeback_single_inode
  43)     1296     176   writeback_sb_inodes
  44)     1120      80   __writeback_inodes_wb
  45)     1040     160   wb_writeback
  46)      880     208   bdi_writeback_workfn
  47)      672     144   process_one_work
  48)      528     112   worker_thread
  49)      416     240   kthread
  50)      176     176   ret_from_fork

[ Note: the problem is exacerbated by certain gcc versions that seem to
  generate much bigger stack frames due to apparently bad coalescing of
  temporaries and generating too many spills.  Rusty saw gcc-4.6.4 using
  35% more stack on the virtio path than 4.8.2 does, for example.

  Minchan not only uses such a bad gcc version (4.6.3 in his case), but
  some of the stack use is due to debugging (CONFIG_DEBUG_PAGEALLOC is
  what causes that kernel_map_pages() frame, for example). But we're
  clearly getting too close.

  The VM code also seems to have excessive stack frames partly for the
  same compiler reason, triggered by excessive inlining and lots of
  function arguments.

  We need to improve on our stack use, but in the meantime let's do this
  simple stack increase too.  Unlike most earlier reports, there is
  nothing simple that stands out as being really horribly wrong here,
  apart from the fact that the stack frames are just bigger than they
  should need to be.        - Linus ]

Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S Tsirkin <mst@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: PJ Waskiewicz <pjwaskiewicz@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'for-linus-2' of git://git./linux/kernel/git/viro/vfs

Pull vfs dcache livelock fix from Al Viro:
 "Fixes for livelocks in shrink_dentry_list() introduced by fixes to
  shrink list corruption; the root cause was that trylock of parent's
  ->d_lock could be disrupted by d_walk() happening on other CPUs,
  resulting in shrink_dentry_list() making no progress *and* the same
  d_walk() being called again and again for as long as
  shrink_dentry_list() doesn't get past that mess.

  The solution is to have shrink_dentry_list() treat that trylock
  failure not as 'try to do the same thing again', but 'lock them in the
  right order'"

* 'for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  dentry_kill() doesn't need the second argument now
  dealing with the rest of shrink_dentry_list() livelock
  shrink_dentry_list(): take parent's ->d_lock earlier
  expand dentry_kill(dentry, 0) in shrink_dentry_list()
  split dentry_kill()
  lift the "already marked killed" case into shrink_dentry_list()

dentry_kill() doesn't need the second argument now

it's 1 in the only remaining caller.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

dealing with the rest of shrink_dentry_list() livelock

We have the same problem with ->d_lock order in the inner loop, where
we are dropping references to ancestors.  Same solution, basically -
instead of using dentry_kill() we use lock_parent() (introduced in the
previous commit) to get that lock in a safe way, recheck ->d_count
(in case if lock_parent() has ended up dropping and retaking ->d_lock
and somebody managed to grab a reference during that window), trylock
the inode->i_lock and use __dentry_kill() to do the rest.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

shrink_dentry_list(): take parent's ->d_lock earlier

The cause of livelocks there is that we are taking ->d_lock on
dentry and its parent in the wrong order, forcing us to use
trylock on the parent's one.  d_walk() takes them in the right
order, and unfortunately it's not hard to create a situation
when shrink_dentry_list() can't make progress since trylock
keeps failing, and shrink_dcache_parent() or check_submounts_and_drop()
keeps calling d_walk() disrupting the very shrink_dentry_list() it's
waiting for.

Solution is straightforward - if that trylock fails, let's unlock
the dentry itself and take locks in the right order.  We need to
stabilize ->d_parent without holding ->d_lock, but that's doable
using RCU.  And we'd better do that in the very beginning of the
loop in shrink_dentry_list(), since the checks on refcount, etc.
would need to be redone anyway.

That deals with a half of the problem - killing dentries on the
shrink list itself.  Another one (dropping their parents) is
in the next commit.

locking parent is interesting - it would be easy to do rcu_read_lock(),
lock whatever we think is a parent, lock dentry itself and check
if the parent is still the right one.  Except that we need to check
that *before* locking the dentry, or we are risking taking ->d_lock
out of order.  Fortunately, once the D1 is locked, we can check if
D2->d_parent is equal to D1 without the need to lock D2; D2->d_parent
can start or stop pointing to D1 only under D1->d_lock, so taking
D1->d_lock is enough.  In other words, the right solution is
rcu_read_lock/lock what looks like parent right now/check if it's
still our parent/rcu_read_unlock/lock the child.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

drm/radeon: only allocate necessary size for vm bo list

No need to always allocate the theoretical maximum here.

Signed-off-by: Christian König <christian.koenig@amd.com>

drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission

It hangs the hardware.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org