1. 17 7月, 2014 1 次提交
    • B
      amdkfd: Add kernel queue module · ed6e6a34
      Ben Goz 提交于
      The kernel queue module enables the amdkfd to establish kernel queues, not
      exposed to user space.
      
      The kernel queues are used for HIQ (HSA Interface Queue) and DIQ (Debug
      Interface Queue) operations
      
      v3: Removed use of internal typedefs and added use of the new gart allocation
      functions
      
      v4: Fixed a miscalculation in kernel queue wrapping
      
      v5:
      
      Move amdkfd from drm/radeon/ to drm/amd/
      Change format of mqd structure to match latest KV firmware
      Add support for AQL queues creation to enable working with open-source HSA
      runtime
      Add define for kernel queue size
      Various fixes
      Signed-off-by: NBen Goz <ben.goz@amd.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      ed6e6a34
  2. 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
  3. 13 3月, 2014 1 次提交
  4. 05 7月, 2013 2 次提交
  5. 01 7月, 2013 8 次提交
  6. 26 4月, 2013 1 次提交
    • B
      drm/nve0: magic up some support for GF117 · 3f196a04
      Ben Skeggs 提交于
      Seen in the wild, don't have the hardware but this hacks things up to
      treat it the same as GF119 for now.
      
      Should be relatively safe, I'd be very surprised if anything major
      changed outside of PGRAPH.  PGRAPH (3D etc) is disabled by default
      however until it's confirmed working.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      3f196a04
  7. 03 10月, 2012 2 次提交
  8. 21 12月, 2011 2 次提交
  9. 20 9月, 2011 1 次提交
  10. 23 6月, 2011 1 次提交
    • B
      drm/nvc0/gr: import and use our own fuc by default · 0411de85
      Ben Skeggs 提交于
      The ability to use NVIDIA's fuc has been retained *temporarily* in order
      to better debug any issues that may be lingering in our initial attempt
      at writing this ucode.  Once I'm fairly confident we're okay, it'll be
      removed.
      
      There's a number of things not implemented by this fuc currently, but
      most of it is sets of state that our context setup would not have used
      anyway.  No doubt we'll find out what they're for at some point, and
      implement it if required.
      
      This has been tested on 0xc0/0xc4 thus far, and from what I could tell
      it worked as well as NVIDIA's.  It's also been tested on 0xc1, but even
      with NVIDIA's fuc that chipset doesn't work correctly with nouveau yet.
      
      0xc3/0xc8/0xce should in theory be supported too, but I don't have the
      hardware to check that.
      
      There's no doubt numerous bugs to squash yet, please report any!
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      0411de85