1. 25 3月, 2015 1 次提交
  2. 22 1月, 2015 1 次提交
  3. 10 1月, 2015 3 次提交
    • O
    • O
      drm/radeon: Impl. new gtt allocate/free functions · ceae881b
      Oded Gabbay 提交于
      This patch adds the implementation of the gtt interface functions.
      
      The allocate function will allocate a single bo, pin and map it to kernel
      memory. It will return the gpu address and cpu ptr as arguments.
      
      v2:
      
      The bulk of the allocations in the GART is for MQDs. MQDs represent active
      user-mode queues, which are on the current runlist. It is important to
      remember that active queues doesn't necessarily mean scheduled/running
      queues, especially if there is over-subscription of queues or more than a
      single HSA process.
      
      Because the scheduling of the user-mode queues is done by the CP firmware,
      amdkfd doesn't have any indication if the queue is scheduled or not. If the
      CP will try to schedule a queue, and its MQD is not present, this will
      probably stuck the CP permanently, as it will load garbage from the GART
      (the address of the MQD is given to the CP inside the runlist packet).
      
      In addition, there are a couple of small allocations which also should
      always be pinned - runlist packets (2 packets) and HPDs. runlist packets can
      be quite large, depending on number of processes and queues.
      
      This new allocate function represents the short/mid-term solution of limiting
      the total memory consumption to around 4MB by default.
      
      The long-term solution is to create a mechanism through which radeon/ttm can
      ask amdkfd to clear GART/VRAM memory due to memory pressure.
      Then, amdkfd will preempt the running queues and wait until the memory pressure
      is over. After that, amdkfd will reschedule the queues.
      Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      Reviewed-by: NAlexey Skidanov <Alexey.skidanov@amd.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      ceae881b
    • B
      drm/radeon: Implement SDMA interface functions · a84a9903
      Ben Goz 提交于
      This patch implements the new SDMA interface functions. It also adds defines
      and structures related to SDMA registers.
      
      v2: Removed init_sdma_engines() from interface. Initialization is done in
      radeon.
      
      v3:
      - Removed unused defines.
      - Added SDMA_ prefix to defines that didn't have them.
      Signed-off-by: NBen Goz <ben.goz@amd.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      a84a9903
  4. 29 12月, 2014 1 次提交
    • O
      drm/radeon: Init amdkfd only if it was compiled · 38c2adfb
      Oded Gabbay 提交于
      This patch changes the radeon_kfd_init(), which is used to initialize the
      interface between radeon and amdkfd, so the interface will be initialized only
      if amdkfd was build, either as module or inside the kernel image.
      
      In the modules case, the symbol_request() will be used (same as old code). In
      the in-image compilation case, a direct call to kgd2kfd_init() will be done.
      For other cases, radeon_kfd_init() will just return false.
      
      This patch is necessary because in case of the following specific
      configuration: kernel 32-bit, no modules support, random kernel base and no
      hibernation, the symbol_request() doesn't work as expected - it doesn't return
      NULL if the symbol doesn't exists - which makes the kernel panic.
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      38c2adfb
  5. 17 12月, 2014 1 次提交
  6. 04 1月, 2015 1 次提交
  7. 09 12月, 2014 1 次提交
  8. 09 11月, 2014 1 次提交
  9. 03 1月, 2015 2 次提交
  10. 15 7月, 2014 1 次提交
    • O
      drm/radeon: Add radeon <--> amdkfd interface · e28740ec
      Oded Gabbay 提交于
      This patch adds the interface between the radeon driver and the amdkfd driver.
      The interface implementation is contained in radeon_kfd.c and radeon_kfd.h.
      
      The interface itself is represented by a pointer to struct
      kfd_dev. The pointer is located inside radeon_device structure.
      
      All the register accesses that amdkfd need are done using this interface. This
      allows us to avoid direct register accesses in amdkfd proper,  while also
      avoiding locking between amdkfd and radeon.
      
      The single exception is the doorbells that are used in both of the drivers.
      However, because they are located in separate pci bar pages, the danger of
      sharing registers between the drivers is minimal.
      
      Having said that, we are planning to move the doorbells as well to radeon.
      
      v3:
      
      Add interface for sa manager init and fini. The init function will allocate a
      buffer on system memory and pin it to the GART address space via the radeon sa
      manager.
      
      All mappings of buffers to GART address space are done via the radeon sa
      manager. The interface of allocate memory will use the radeon sa manager to sub
      allocate from the single buffer that was allocated during the init function.
      
      Change lower_32/upper_32 calls to use linux macros
      
      Add documentation for the interface
      
      v4:
      
      Change ptr field type in kgd_mem from uint32_t* to void* to match to type that
      is returned by radeon_sa_bo_cpu_addr
      
      v5:
      
      Change format of mqd structure to work with latest KV firmware
      Add support for AQL queues creation to enable working with open-source HSA
      runtime.
      Move generic kfd-->kgd interface and other generic kgd definitions to a generic
      header file that will be used by AMD's radeon and amdgpu drivers
      Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      e28740ec