drm/nouveau/pm/gf100: remove undefined TEX.PM_UNKC8 mux

This mux only exists on GF108+ (except for GF110 one), but since it is
not used by the userspace we can drop it for now.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: allow zeroed signals to enable sources

Hardware signals index 0x00 are defined for some domains and they have
to be allowed to enable sources like the others.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm/nv50: TPC[0x3] must be used for PGRAPH muxs on G80

I thought that using TPC[0x0] like for G84:GT215 was sufficient on G80,
but it's actually not the case. According to NVIDIA PerfKit on Windows,
we have to configure PGRAPH related muxs on TPC[0x3] for this chipset.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm/nv50: fix wrong addr for ZCULL source on G80:GT215

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios: add opcodes 0x73 and 0x77

No known VBIOSes use these, but they are present in the actual VBIOS
table parsing logic. No harm in adding these too.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/platform: recognize GM20B

Allow the platform driver to recognize GM20B.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/device: recognize GM20B

Recognize GM20B and assign the right engines and subdevs.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/gr: add GM20B support

Add support for GM20B's graphics engine, based on GK20A. Note that this
code alone will not allow the engine to initialize on released devices
which require PMU-assisted secure boot.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo: add GM20B fifo

GM20B has a 512-channels FIFO similar to GK104.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/gr/gk20a: use same initialization sequence as nvgpu

GK20A's initialization was based on GK104, but differences exist in the
way the initial context is built and the initialization process itself.

This patch follows the same initialization sequence as nvgpu performs
to avoid bad surprises. Since the register bundles initialization also
differ considerably from GK104, the register packs are now loaded from
firmware files, again similarly to what is done with nvgpu.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/gr: use NVIDIA-provided external firmwares

NVIDIA will officially start providing GR firmwares through
linux-firmware for GPUs that require it. Change the GR firmware lookup
function to use these files.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm/gk104: add compute signals/sources

These signals and sources have been reverse engineered from CUPTI
(Linux). Graphics signals exposed by PerfKit (Windows only) will be
added later. I need to reverse engineer them and it's a bit painful.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm/gk104: re-use gf100_pm_ctor()

gk104_pm_ctor() is equal to gf100_pm_ctor().

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm/nv40: rename pcounter domains to 'pc' instead of 'pm'

This trivial patch makes thing more consistent since hardware signals
names are prefixed by 'pcXX'.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: expose name of domains

This is going to be very useful for GF100+ because each GPC can
have its own domain of counters.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/drm/nouveau/clk: fix tstate to pstate calculation

According to the tstate calculation in nvkm_clk_tstate(),
the range of tstate is from -(clk->state_nr - 1) to 0,
it mean the tstate is negative value. But in nvkm_pstate_work(),
it use (clk->state_nr - 1 - clk->tstate) to limit pstate,
it's not correct.
This patch fix it to use (clk->state_nr - 1 + clk->tstate) to
limit pstate.

Signed-off-by: Wei Ni <wni@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: some fixes related to sources

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: fix signals/sources for GT200+

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm/gf100: add compute signals/sources

These signals and sources have been reverse engineered from CUPTI
(Linux). Graphics signals exposed by PerfKit (Windows only) will be
added later. I need to reverse engineer them and it's a bit painful.

This commit also adds a new class for GF108 and GF117.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm/gf100: allow to share GPC, HUB and PART domains

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: stack perfdom class under perfmon

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: swap perfmon/perfdom code to avoid forward decl in next commit

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm/nv50: add compute and graphics signals/sources

These signals and sources have been reverse engineered from NVIDIA
PerfKit (Windows) and CUPTI (Linux), they will be used to build complex
hardware events from the userspace.

This commit also adds a new class for GT200.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: allow the userspace to configure sources

Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: allow to configure domains instead of simple counters

Configuring counters from the userspace require the kernel to handle some
logic related to performance counters. Basically, it has to find a free
slot to assign a counter, to handle extra counting modes like B4/B6 and it
must return and error when it can't configure a counter.

In my opinion, the kernel should not handle all of that logic but it
should only write the configuration sent by the userspace without
checking anything. In other words, it should overwrite the configuration
even if it's already counting and do not return any errors.

This patch allows the userspace to configure a domain instead of
separate counters. This has the advantage to move all of the logic to
the userspace.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: allow the userspace to schedule hardware counters

This adds a new method NVIF_PERFCTR_V0_INIT which starts a batch of
hardware counters for sampling. This will allow the userspace to start
a monitoring session using the INIT method and to stop it with SAMPLE,
for example before and after a frame is rendered.

This commit temporarily breaks nv_perfmon but this is going to be fixed
with the upcoming patch.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: implement NVIF_PERFMON_V0_QUERY_SOURCE method

This allows to query the ID, the mask and the user-readable name of
sources for each signal.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: allow to query the number of sources for a signal

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: add concept of sources

A source (or multiplexer) is a tuple addr+mask+shift which allows to
control a block of signals. The maximum number of sources that a signal
can define is arbitrary limited to 8 and this should be large enough.
This patch allows to define multi-level of sources for a signal.

Each different sources are stored to a global list and will be exposed
to the userspace through the nvif interface in order to avoid conflicts.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: allow to monitor hardware signal index 0x00

This signal index must be always allowed even if it's not clearly
defined in a domain in order to monitor a counter like 0x03020100
because it's the default value of signals.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: use hardware signals indexes instead of user-readable names

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: change signal iter to u16

16 bits is large enough to store the maximum number of signals available
for one domain (i.e. 256).

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: allow to query signals by domain

This will allow to configure performance counters with hardware signal
indexes instead of user-readable names in an upcoming patch.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: implement NVIF_PERFMON_V0_QUERY_DOMAIN method

This allows to query the number of available domains, including the
number of hardware counter and the number of signals per domain.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: prevent creating a perfctr object when signals are not found

Since a new class has been introduced to query signals, we can now
return an error when the userspace wants to monitor unknown signals.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: reorganize the nvif interface

This commit introduces the NVIF_IOCTL_NEW_V0_PERFMON class which will be
used in order to query domains, signals and sources. This separates the
querying and the counting interface.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: remove unused nvkm_perfsig_wrap() function

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pm: remove pmu signals

PDAEMON signals don't have to be exposed by the perfmon engine.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/clk/nv50: Enable user reclocking for NVA0

Tested on a few cards. Probably works quite well for most, given they should
all be GDDR3.

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gddr3: Add a few CL and WR entries observed on GTX260

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/ramnv50: GDDR3 script for NVA0

This looks surprisingly similar to scripts on earlier cards as well
but they don't seem to work just yet. That... and I don't have any, which
makes it a tough job to reverse engineer.

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios/ramcfg: Separate out RON pull value

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios/rammap: Parse perf mode as if it's a rammap entry

Some of the bits in there are similar to the bits in the gt215 rammap.

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/ramnv50: Ressurect timing code, use proper timing/rammap handlers

Might need some generalisation to < GT200. For those: use at your own risk!

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/ramgt215: No need to cuss like that

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/ramnv50: Make 0x100da0 per-partition

Like on GT215

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios/rammap: Pull DLLoff bit out of version 0x10 struct

In preparation of NV50 reclocking, where there is no version

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

remove unnecessary include

This was merged with core/device.h in an earlier commit, but somehow
never got removed.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Merge branch 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into drm-next

Here are some development updates for the Synopsis Designware HDMI driver,
which clean up some of the code, and start preparing to add audio support
to the driver.  This series of patches are based on a couple of dependent
commits from the ALSA tree.

Briefly, the updates are:
- move comments which should have moved with the phy values to the IMX
  part of the driver.
- clean up the phy configuration: to all lookups before starting to
  program the phy.
- clean up the HDMI clock regenerator code
- use the drm_hdmi_avi_infoframe_from_display_mode() helper which allows
  the code to be subsequently simplified
- remove the unused 'regmap' pointer in struct dw_hdmi
- use the bridge drm device rather than the connector (we're the bridge
  code)
- remove private hsync/vsync/interlaced flags, getting them from the
  DRM mode structure instead.
- implement interface functions to support audio - setting the audio
  sample rate, and enabling the audio clocks.
- removal of broken pixel repetition support
- cleanup DVI vs HDMI sink handling
- enable audio only if connected device supports audio
- avoid double-enabling bridge in the sink path (once in mode_set, and
  again in commit)
- rename mis-named dw_hdmi_phy_enable_power()
- fix bridge enable/disable handing, so a plug-in event doesn't
  reconfigure the bridge if DRM has disabled the output
- fix from Vladimir Zapolskiy for the I2CM_ADDRESS macro name

These are primerily preparitory patches for the AHB audio driver and
the I2S audio driver (from Rockchip) for this IP.

* 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name
  drm: bridge/dw_hdmi: fix phy enable/disable handling
  drm: bridge/dw_hdmi: rename dw_hdmi_phy_enable_power()
  drm: bridge/dw_hdmi: avoid enabling interface in mode_set
  drm: bridge/dw_hdmi: enable audio only if sink supports audio
  drm: bridge/dw_hdmi: clean up HDMI vs DVI mode handling
  drm: bridge/dw_hdmi: don't support any pixel doubled modes
  drm: bridge/dw_hdmi: remove pixel repetition setting for all VICs
  drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio
  drm: bridge/dw_hdmi: introduce interface to setting sample rate
  drm: bridge/dw_hdmi: remove mhsyncpolarity/mvsyncpolarity/minterlaced
  drm: bridge/dw_hdmi: use our own drm_device
  drm: bridge/dw_hdmi: remove unused 'regmap' struct member
  drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little
  drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()
  drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator()
  drm: bridge/dw_hdmi: clean up phy configuration
  drm: imx/dw_hdmi: move phy comments
  drm/edid: add function to help find SADs

Merge tag 'vmwgfx-next-15-08-21' of git://people.freedesktop.org/~thomash/linux into drm-next

Pull request of 15-08-21

The third pull request for 4.3. Contains two fixes for regressions introduced
with previous pull requests.

* tag 'vmwgfx-next-15-08-21' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Remove duplicate ttm_bo_device_release
  drm/vmwgfx: Fix a circular locking dependency in the fbdev code

Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-next

- DP fixes for radeon and amdgpu
- IH ring fix for tonga and fiji
- Lots of GPU scheduler fixes
- Misc additional fixes

* 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux: (42 commits)
  drm/amdgpu: fix wait queue handling in the scheduler
  drm/amdgpu: remove extra parameters from scheduler callbacks
  drm/amdgpu: wake up scheduler only when neccessary
  drm/amdgpu: remove entity idle timeout v2
  drm/amdgpu: fix postclose order
  drm/amdgpu: use IB for copy buffer of eviction
  drm/amdgpu: adjust the judgement of removing fence callback
  drm/amdgpu: fix no sync_wait in copy_buffer
  drm/amdgpu: fix last_vm_update fence is not effetive for sched fence
  drm/amdgpu: add priv data to sched
  drm/amdgpu: add owner for sched fence
  drm/amdgpu: remove entity reference from sched fence
  drm/amdgpu: fix and cleanup amd_sched_entity_push_job
  drm/amdgpu: remove amdgpu_bo_list_clone
  drm/amdgpu: remove the context from amdgpu_job
  drm/amdgpu: remove unused parameters to amd_sched_create
  drm/amdgpu: remove sched_lock
  drm/amdgpu: remove prepare_job callback
  drm/amdgpu: cleanup a scheduler function name
  drm/amdgpu: reorder scheduler functions
  ...

drm/amdgpu: fix wait queue handling in the scheduler

Freeing up a queue after signalling it isn't race free.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: remove extra parameters from scheduler callbacks

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: wake up scheduler only when neccessary

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: remove entity idle timeout v2

Removing the entity from scheduling can deadlock the whole system.
Wait forever till the remaining IBs are scheduled.

v2: fix comment as well

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1)

drm/amdgpu: fix postclose order

The context needs to finish before everything else.

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: use IB for copy buffer of eviction

This aids handling buffers moves with the scheduler.

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian K?nig <christian.koenig@amd.com>

drm/amdgpu: adjust the judgement of removing fence callback

The fence in the array may be skipped if wait_all is false,
thus the related callback is not initialized with list head.
So removing this kind callback will cause NULL pointer reference.

Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>

drm/amdgpu: fix no sync_wait in copy_buffer

when eviction is happening, if don't handle
dependency, then the fence could be dead off.

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian K?nig <christian.koenig@amd.com>

drm/amdgpu: fix last_vm_update fence is not effetive for sched fence

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian K?nig <christian.koenig@amd.com>

drm/amdgpu: add priv data to sched

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian K?nig <christian.koenig@amd.com>

drm/amdgpu: add owner for sched fence

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian K?nig <christian.koenig@amd.com>

drm/amdgpu: remove entity reference from sched fence

Entity don't live as long as scheduler fences.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: fix and cleanup amd_sched_entity_push_job

Calling schedule() is probably the worse things we can do.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: remove amdgpu_bo_list_clone

Not used any more.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: remove the context from amdgpu_job

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: remove unused parameters to amd_sched_create

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: remove sched_lock

It isn't protecting anything.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: remove prepare_job callback

Not used any more.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: cleanup a scheduler function name

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: reorder scheduler functions

Keep run queue, entity and scheduler handling together.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: fix scheduler thread creation error checking

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: fix entity wakeup race condition

That actually didn't worked at all.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: cleanup entity picking

Cleanup function name, stop checking scheduler ready twice, but
check if kernel thread should stop instead.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: remove some more unused entity members v2

None of them are used any more.

v2: fix type in error message

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: fix user fences when scheduler is enabled

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

drm/amdgpu: fix fence wait in sync_fence, instead should be in sync_rings

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian K?nig <christian.koenig@amd.com>

drm/amdgpu: rework scheduler submission handling.

Remove active_hw_rq and it's protecting queue_lock, they are unused.

User 32bit atomic for hw_rq_count, 64bits for counting to three is a bit
overkill.

Cleanup the function name and remove incorrect comments.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>

drm/amdgpu: remove v_seq handling from the scheduler v2

Simply not used any more. Only keep 32bit atomic for fence sequence numbering.

v2: trivial rebase

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> (v1)
Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1)

drm/amdgpu: improve sa_bo->fence by kernel fence

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian K?nig <christian.koenig@amd.com>

drm/amdgpu: modify amdgpu_fence_wait_any() to amdgpu_fence_wait_multiple()

Rename the function and update the related code with this modified function.
Add the new parameter of bool wait_all.

If wait_all is true, it will return when all fences are signaled or timeout.
If wait_all is false, it will return when any fence is signaled or timeout.

Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Monk Liu <monk.liu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

drm/amdgpu: fix IH ring allocation for bus addresses (v2)

Use pci_alloc_consistent rather than kzalloc since we
need 256 byte aligned memory for the ring buffer.

v2: fix copy paste typo in free function noticed
by Jammy.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91749

Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Revert "drm/atomic: Call ww_acquire_done after check phase is complete"

This reverts commit 992cbf19b32900efa17850b9fa0031fd623edd4d.

Until we make fbdev layer atomic we can't call this.

Requested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com?
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'v4.2-rc8' into drm-next

Linux 4.2-rc8

Backmerge required for Intel so they can fix their -next tree up properly.

Linux 4.2-rc8

drm/mgag200: Add support for a new rev of G200e

- Added PLL algorithm for a new rev of G200e
- Removed the bandwidth limitation for the new G200e

Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/mgag200: Add support for a new G200eW3 chipset

- Added support for the new deviceID for G200eW3
- Added PLL algorithm for the G200eW3
- Added some initialization code for G200eW3

Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "A couple of major (hang and deadlock) fixes with fortunately fairly
  rare triggering conditions.  The PM oops is only really triggered by
  people using enclosure services (rare) and the fnic driver is mostly
  used in enterprise environments"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  SCSI: Fix NULL pointer dereference in runtime PM
  fnic: Use the local variable instead of I/O flag to acquire io_req_lock in fnic_queuecommand() to avoid deadloack

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

Pull MIPS bug fixes from Ralf Baechle:
 "Two more fixes for 4.2.

  One fixes a build issue with the LLVM assembler - LLVM assembler macro
  names are case sensitive, GNU as macro names are insensitive; the
  other corrects a license string (GPL v2, not GPLv2) such that the
  module loader will recognice the license correctly"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  FIRMWARE: bcm47xx_nvram: Fix module license.
  MIPS: Fix LLVM build issue.

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

Pull 9p regression fix from Al Viro:
 "Fix for breakage introduced when switching p9_client_{read,write}() to
  struct iov_iter * (went into 4.1)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  9p: ensure err is initialized to 0 in p9_client_read/write

9p: ensure err is initialized to 0 in p9_client_read/write

Some use of those functions were providing unitialized values to those
functions. Notably, when reading 0 bytes from an empty file on a 9P
filesystem, the return code of read() was not 0.

Tested with this simple program:

    #include <assert.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <unistd.h>

    int main(int argc, const char **argv)
    {
        assert(argc == 2);
        char buffer[256];
        int fd = open(argv[1], O_RDONLY|O_NOCTTY);
        assert(fd >= 0);
        assert(read(fd, buffer, 0) == 0);
        return 0;
    }

Cc: stable@vger.kernel.org # v4.1
Signed-off-by: Vincent Bernat <vincent@bernat.im>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:
 "Another couple of small ARM fixes.

  A patch from Masahiro Yamada who noticed that "make -jN all zImage"
  would end up generating bad images where N > 1, and a patch from
  Nicolas to fix the Marvell CPU user access optimisation code when page
  faults are disabled"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8418/1: add boot image dependencies to not generate invalid images
  ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage

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

Pull x86 fixes from Ingo Molnar:
 "Various low level fixes: fix more fallout from the FPU rework and the
  asm entry code rework, plus an MSI rework fix, and an idle-tracing fix"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/fpu/math-emu: Fix crash in fork()
  x86/fpu/math-emu: Fix math-emu boot crash
  x86/idle: Restore trace_cpu_idle to mwait_idle() calls
  x86/irq: Build correct vector mapping for multiple MSI interrupts
  Revert "sched/x86_64: Don't save flags on context switch"

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

Pull perf fixes from Ingo Molnar:
 "Tooling fixes: a 'perf record' deadlock fix plus debuggability fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf top: Show backtrace when handling a SIGSEGV on --stdio mode
  perf tools: Fix buildid processing
  perf tools: Make fork event processing more resilient
  perf tools: Avoid deadlock when map_groups are broken

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

Pull irq fixes from Thomas Gleixner:
 "A series of small fixlets for a regression visible on OMAP devices
  caused by the conversion of the OMAP interrupt chips to hierarchical
  interrupt domains.  Mostly one liners on the driver side plus a small
  helper function in the core to avoid open coded mess in the drivers"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/crossbar: Restore set_wake functionality
  irqchip/crossbar: Restore the mask on suspend behaviour
  ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism
  irqchip/crossbar: Restore the irq_set_type() mechanism
  genirq: Introduce irq_chip_set_type_parent() helper
  genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchy

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

Pull timer fixes from Thomas Gleixner:
 "Two minimalistic fixes for 4.2 regressions:

   - Eric fixed a thinko in the timer_list base switching code caused by
     the overhaul of the timer wheel.  It can cause a cpu to see the
     wrong base for a timer while we move the timer around.

   - Guenter fixed a regression for IMX if booted w/o device tree, where
     the timer interrupt is not initialized and therefor the machine
     fails to boot"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clocksource/imx: Fix boot with non-DT systems
  timer: Write timer->flags atomically

x86/fpu/math-emu: Fix crash in fork()

During later stages of math-emu bootup the following crash triggers:

 math_emulate: 0060:c100d0a8
 Kernel panic - not syncing: Math emulation needed in kernel
 CPU: 0 PID: 1511 Comm: login Not tainted 4.2.0-rc7+ #1012
 [...]
 Call Trace:
  [<c181d50d>] dump_stack+0x41/0x52
  [<c181c918>] panic+0x77/0x189
  [<c1003530>] ? math_error+0x140/0x140
  [<c164c2d7>] math_emulate+0xba7/0xbd0
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c1109c3c>] ? __alloc_pages_nodemask+0x12c/0x870
  [<c136ac20>] ? proc_clear_tty+0x40/0x70
  [<c136ac6e>] ? session_clear_tty+0x1e/0x30
  [<c1003530>] ? math_error+0x140/0x140
  [<c1003575>] do_device_not_available+0x45/0x70
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c18258e6>] error_code+0x5a/0x60
  [<c1003530>] ? math_error+0x140/0x140
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c100c205>] arch_dup_task_struct+0x25/0x30
  [<c1048cea>] copy_process.part.51+0xea/0x1480
  [<c115a8e5>] ? dput+0x175/0x200
  [<c136af70>] ? no_tty+0x30/0x30
  [<c1157242>] ? do_vfs_ioctl+0x322/0x540
  [<c104a21a>] _do_fork+0xca/0x340
  [<c1057b06>] ? SyS_rt_sigaction+0x66/0x90
  [<c104a557>] SyS_clone+0x27/0x30
  [<c1824a80>] sysenter_do_call+0x12/0x12

The reason is the incorrect assumption in fpu_copy(), that FNSAVE
can be executed from math-emu kernels as well.

Don't try to copy the registers, the soft state will be copied
by fork anyway, so the child task inherits the parent task's
soft math state.

With this fix applied math-emu kernels boot up fine on modern
hardware and the 'no387 nofxsr' boot options.

Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Bobby Powers <bobbypowers@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

x86/fpu/math-emu: Fix math-emu boot crash

On a math-emu bootup the following crash occurs:

Initializing CPU#0
------------[ cut here ]------------
kernel BUG at arch/x86/kernel/traps.c:779!
invalid opcode: 0000 [#1] SMP
[...]
EIP is at do_device_not_available+0xe/0x70
[...]
Call Trace:
 [<c18238e6>] error_code+0x5a/0x60
 [<c1002bd0>] ? math_error+0x140/0x140
 [<c100bbd9>] ? fpu__init_cpu+0x59/0xa0
 [<c1012322>] cpu_init+0x202/0x330
 [<c104509f>] ? __native_set_fixmap+0x1f/0x30
 [<c1b56ab0>] trap_init+0x305/0x346
 [<c1b548af>] start_kernel+0x1a5/0x35d
 [<c1b542b4>] i386_start_kernel+0x82/0x86

The reason is that in the following commit:

  b1276c48e91b ("x86/fpu: Initialize fpregs in fpu__init_cpu_generic()")

I failed to consider math-emu's limitation that it cannot execute the
FNINIT instruction in kernel mode.

The long term fix might be to allow math-emu to execute (certain) kernel
mode FPU instructions, but for now apply the safe (albeit somewhat ugly)
fix: initialize the emulation state explicitly without trapping out to
the FPU emulator.

Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>

drm/amdgpu: Don't link train DisplayPort on HPD until we get the dpcd

This is a port of:
DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd
to amdgpu.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd

Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a monitor
from a DisplayPort connector, then plugs that same monitor back in
seconds later on the same port without any other monitors connected), we
never probe for the dpcd before starting the initial link training. What
happens from there looks like this:

- GPU has only one monitor connected. It's connected via
  DisplayPort, and does not go through an adaptor of any sort.

- User unplugs DisplayPort connector from GPU.

- Change in HPD is detected by the driver, we probe every
  DisplayPort for a possible connection.

- Probe the port the user originally had the monitor connected
  on for it's dpcd. This fails, and we clear the first (and only
  the first) byte of the dpcd to indicate we no longer have a
  dpcd for this port.

- User plugs the previously disconnected monitor back into the
  same DisplayPort.

- radeon_connector_hotplug() is called before everyone else,
  and tries to handle the link training. Since only the first
  byte of the dpcd is zeroed, the driver is able to complete
  link training but does so against the wrong dpcd, causing it
  to initialize the link with the wrong settings.

- Display stays blank (usually), dpcd is probed after the
  initial link training, and the driver prints no obvious
  messages to the log.

In theory, since only one byte of the dpcd is chopped off (specifically,
the byte that contains the revision information for DisplayPort), it's
not entirely impossible that this bug may not show on certain monitors.
For instance, the only reason this bug was visible on my ASUS PB238
monitor was due to the fact that this monitor using the enhanced framing
symbol sequence, the flag for which is ignored if the radeon driver
thinks that the DisplayPort version is below 1.1.

Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org