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>

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>

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>

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

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>

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

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>

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>

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

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

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>

This was merged with core/device.h in an earlier commit, but somehow
never got removed.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

- 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
  ...

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>

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>

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>

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)

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>

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>

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>

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>

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-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>

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

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>

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>

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

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

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

It isn't protecting anything.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

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

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

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>

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

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>

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>

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>

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