Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>

This patch adds a new kernel module parameter to amdkfd,
called send_sigterm.

This parameter specifies whether amdkfd should send the
SIGTERM signal to an HSA process, when the following conditions
occur:

1. The GPU triggers an exception regarding a kernel that was
   issued by this process.

2. The HSA process isn't waiting on an event that handles
   this exception.

The default behavior is not to send a SIGTERM and suffice
with a dmesg error print.

Reviewed-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>

The current code can only support one kgd instance. We have to
support multiple kgd instances in one system. i.e two amdgpu or two
radeon or one amdgpu + one radeon or more than two kgd instances.

Signed-off-by: Xihan Zhang <xihan.zhang@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

Pull drm updates from Dave Airlie:
 "This is the main drm pull, it has a shared branch with some alsa
  crossover but everything should be acked by relevant people.

  New drivers:
     - ATMEL HLCDC driver
     - designware HDMI core support (used in multiple SoCs).

  core:
     - lots more atomic modesetting work, properties and atomic ioctl
       (hidden under option)
     - bridge rework allows support for Samsung exynos chromebooks to
       work finally.
     - some more panels supported

  i915:
     - atomic plane update support
     - DSI uses shared DSI infrastructure
     - Skylake basic support is all merged now
     - component framework used for i915/snd-hda interactions
     - write-combine cpu memory mappings
     - engine init code refactored
     - full ppgtt enabled where execlists are enabled.
     - cherryview rps/gpu turbo and pipe CRC support.

  radeon:
     - indirect draw support for evergreen/cayman
     - SMC and manual fan control for SI/CI
     - Displayport audio support

  amdkfd:
     - SDMA usermode queue support
     - replace suballocator usage with more suitable one
     - rework for allowing interfacing to more than radeon

  nouveau:
     - major renaming in prep for later splitting work
     - merge arm platform driver into nouveau
     - GK20A reclocking support

  msm:
     - conversion to atomic modesetting
     - YUV support for mdp4/5
     - eDP support
     - hw cursor for mdp5

  tegra:
     - conversion to atomic modesetting
     - better suspend/resume support for child devices

  rcar-du:
     - interlaced support

  imx:
     - move to using dw_hdmi shared support
     - mode_fixup support

  sti:
     - DVO support
     - HDMI infoframe support

  exynos:
     - refactoring and cleanup, removed lots of internal unnecessary
       abstraction
     - exynos7 DECON display controller support

  Along with the usual bunch of fixes, cleanups etc"

* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (724 commits)
  drm/radeon: fix voltage setup on hawaii
  drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary
  drm/radeon: only enable kv/kb dpm interrupts once v3
  drm/radeon: workaround for CP HW bug on CIK
  drm/radeon: Don't try to enable write-combining without PAT
  drm/radeon: use 0-255 rather than 0-100 for pwm fan range
  drm/i915: Clamp efficient frequency to valid range
  drm/i915: Really ignore long HPD pulses on eDP
  drm/exynos: Add DECON driver
  drm/i915: Correct the base value while updating LP_OUTPUT_HOLD in MIPI_PORT_CTRL
  drm/i915: Insert a command barrier on BLT/BSD cache flushes
  drm/i915: Drop vblank wait from intel_dp_link_down
  drm/exynos: fix NULL pointer reference
  drm/exynos: remove exynos_plane_dpms
  drm/exynos: remove mode property of exynos crtc
  drm/exynos: Remove exynos_plane_dpms() call with no effect
  drm/i915: Squelch overzealous uncore reset WARN_ON
  drm/i915: Take runtime pm reference on hangcheck_info
  drm/i915: Correct the IOSF Dev_FN field for IOSF transfers
  drm/exynos: fix DMA_ATTR_NO_KERNEL_MAPPING usage
  ...

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

This backmerges drm-fixes into drm-next mainly for the amdkfd
stuff, I'm not 100% confident, but it builds and the amdkfd
folks can fix anything up.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Conflicts:
	drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
	drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

This patch replaces the two current amdkfd module parameters with a new one.

The current parameters that are being replaced are:

- Maximum number of HSA processes
- Maximum number of queues per process

The new parameter that replaces them is called "Maximum queues per device"

This replacement achieves two goals:

- Allows the user to have as many HSA processes as it wants (until
  a maximum of 512 HSA processes in Kaveri).

- Removes the limitation the user had on maximum number of queues per HSA
  process. E.g. the user can now have processes which only have one queue and
  other processes which have hundreds of queues, while before the user
  couldn't have more than 128 queues per process (as default).

The default value of the new parameter is 4096 (32 * 128, which were the
defaults of the old parameters). There is almost no additional GART memory
required for the default case. As a reminder, this amount of queues requires a
little bit below 4MB of GART memory.

v2:
In addition, This patch defines a new counter for queues accounting in the DQM
structure. This is done because the current counter only counts active queues
which allows the user to create more queues than the
max_num_of_queues_per_device module parameter allows.

However, we need the current counter for the runlist packet build process, so
the solution is to have a dedicated counter for this accounting.

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Ben Goz <ben.goz@amd.com>

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

This patch adds a new parameter to the amdkfd driver. This parameter enables
the user to select the scheduling policy of the CP. The choices are:

* CP Scheduling with support for over-subscription
* CP Scheduling without support for over-subscription
* Without CP Scheduling

Note that the third option (Without CP scheduling) is only for debug purposes
and bringup of new H/W. As such, it is _not_ guaranteed to work at all times on
all H/W versions.

v3: Fixed description of parameter, changed the permissions to read_only, added
a verification of the value and added documentation

v5: Set default sched_policy to HWS as it is now supported by firmware

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>