From: Jerome Glisse <j.glisse@gmail.com>
To: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "Andrew Lewycky" <Andrew.Lewycky@amd.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 06/83] drm/radeon: Add kfd-->kgd interfaces of memory allocation/mapping
Date: Fri, 11 Jul 2014 12:32:38 -0400 [thread overview]
Message-ID: <20140711163237.GG1870@gmail.com> (raw)
In-Reply-To: <1405029027-6085-5-git-send-email-oded.gabbay@amd.com>
On Fri, Jul 11, 2014 at 12:50:06AM +0300, Oded Gabbay wrote:
> This patch adds new interfaces to kfd2kgd_calls structure.
>
> The new interfaces allow the kfd driver to :
>
> 1. Allocated video memory through the radeon driver
> 2. Map and unmap video memory with GPUVM through the radeon driver
> 3. Map and unmap system memory with GPUVM through the radeon driver
>
> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
> ---
> drivers/gpu/drm/radeon/radeon_kfd.c | 129 ++++++++++++++++++++++++++++++++++++
> include/linux/radeon_kfd.h | 23 +++++++
> 2 files changed, 152 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c b/drivers/gpu/drm/radeon/radeon_kfd.c
> index 1b859b5..66ee36b 100644
> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
> @@ -25,9 +25,31 @@
> #include <drm/drmP.h>
> #include "radeon.h"
>
> +struct kgd_mem {
> + struct radeon_bo *bo;
> + u32 domain;
> +};
> +
> +static int allocate_mem(struct kgd_dev *kgd, size_t size, size_t alignment,
> + enum kgd_memory_pool pool, struct kgd_mem **memory_handle);
> +
> +static void free_mem(struct kgd_dev *kgd, struct kgd_mem *memory_handle);
> +
> +static int gpumap_mem(struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *vmid0_address);
> +static void ungpumap_mem(struct kgd_dev *kgd, struct kgd_mem *mem);
> +
> +static int kmap_mem(struct kgd_dev *kgd, struct kgd_mem *mem, void **ptr);
> +static void unkmap_mem(struct kgd_dev *kgd, struct kgd_mem *mem);
> +
> static uint64_t get_vmem_size(struct kgd_dev *kgd);
>
> static const struct kfd2kgd_calls kfd2kgd = {
> + .allocate_mem = allocate_mem,
> + .free_mem = free_mem,
> + .gpumap_mem = gpumap_mem,
> + .ungpumap_mem = ungpumap_mem,
> + .kmap_mem = kmap_mem,
> + .unkmap_mem = unkmap_mem,
> .get_vmem_size = get_vmem_size,
> };
>
> @@ -96,6 +118,113 @@ void radeon_kfd_device_fini(struct radeon_device *rdev)
> }
> }
>
> +static u32 pool_to_domain(enum kgd_memory_pool p)
> +{
> + switch (p) {
> + case KGD_POOL_FRAMEBUFFER: return RADEON_GEM_DOMAIN_VRAM;
> + default: return RADEON_GEM_DOMAIN_GTT;
> + }
> +}
> +
> +static int allocate_mem(struct kgd_dev *kgd, size_t size, size_t alignment,
> + enum kgd_memory_pool pool, struct kgd_mem **memory_handle)
> +{
> + struct radeon_device *rdev = (struct radeon_device *)kgd;
> + struct kgd_mem *mem;
> + int r;
> +
> + mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
> + if (!mem)
> + return -ENOMEM;
> +
> + mem->domain = pool_to_domain(pool);
> +
> + r = radeon_bo_create(rdev, size, alignment, true, mem->domain, NULL, &mem->bo);
> + if (r) {
> + kfree(mem);
> + return r;
> + }
> +
> + *memory_handle = mem;
> + return 0;
> +}
> +
> +static void free_mem(struct kgd_dev *kgd, struct kgd_mem *mem)
> +{
> + /* Assume that KFD will never free gpumapped or kmapped memory. This is not quite settled. */
> + radeon_bo_unref(&mem->bo);
> + kfree(mem);
> +}
> +
> +static int gpumap_mem(struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *vmid0_address)
> +{
> + int r;
> +
> + r = radeon_bo_reserve(mem->bo, true);
> +
> + /*
> + * ttm_bo_reserve can only fail if the buffer reservation lock
> + * is held in circumstances that would deadlock
> + */
> + BUG_ON(r != 0);
> + r = radeon_bo_pin(mem->bo, mem->domain, vmid0_address);
> + radeon_bo_unreserve(mem->bo);
> +
> + return r;
> +}
What is lifetime of such object ? Are they limited in size and number ? How
can the GFX side ie radeon force unmap them ?
Because pining is a big NO we only pin a handfull of buffer and the only
thing we allow userspace to pin are front buffer associated with crtc
which means there is a limited number of such buffer and there is a
legitimate use for pining them.
To me this looks like anyone can pin vram and thus starve the GFX side,
read DDOS.
Cheers,
Jérôme
> +
> +static void ungpumap_mem(struct kgd_dev *kgd, struct kgd_mem *mem)
> +{
> + int r;
> +
> + r = radeon_bo_reserve(mem->bo, true);
> +
> + /*
> + * ttm_bo_reserve can only fail if the buffer reservation lock
> + * is held in circumstances that would deadlock
> + */
> + BUG_ON(r != 0);
> + r = radeon_bo_unpin(mem->bo);
> +
> + /*
> + * This unpin only removed NO_EVICT placement flags
> + * and should never fail
> + */
> + BUG_ON(r != 0);
> + radeon_bo_unreserve(mem->bo);
> +}
> +
> +static int kmap_mem(struct kgd_dev *kgd, struct kgd_mem *mem, void **ptr)
> +{
> + int r;
> +
> + r = radeon_bo_reserve(mem->bo, true);
> +
> + /*
> + * ttm_bo_reserve can only fail if the buffer reservation lock
> + * is held in circumstances that would deadlock
> + */
> + BUG_ON(r != 0);
> + r = radeon_bo_kmap(mem->bo, ptr);
> + radeon_bo_unreserve(mem->bo);
> +
> + return r;
> +}
> +
> +static void unkmap_mem(struct kgd_dev *kgd, struct kgd_mem *mem)
> +{
> + int r;
> +
> + r = radeon_bo_reserve(mem->bo, true);
> + /*
> + * ttm_bo_reserve can only fail if the buffer reservation lock
> + * is held in circumstances that would deadlock
> + */
> + BUG_ON(r != 0);
> + radeon_bo_kunmap(mem->bo);
> + radeon_bo_unreserve(mem->bo);
> +}
> +
> static uint64_t get_vmem_size(struct kgd_dev *kgd)
> {
> struct radeon_device *rdev = (struct radeon_device *)kgd;
> diff --git a/include/linux/radeon_kfd.h b/include/linux/radeon_kfd.h
> index 28cddf5..c7997d4 100644
> --- a/include/linux/radeon_kfd.h
> +++ b/include/linux/radeon_kfd.h
> @@ -36,6 +36,14 @@ struct pci_dev;
> struct kfd_dev;
> struct kgd_dev;
>
> +struct kgd_mem;
> +
> +enum kgd_memory_pool {
> + KGD_POOL_SYSTEM_CACHEABLE = 1,
> + KGD_POOL_SYSTEM_WRITECOMBINE = 2,
> + KGD_POOL_FRAMEBUFFER = 3,
> +};
> +
> struct kgd2kfd_shared_resources {
> void __iomem *mmio_registers; /* Mapped pointer to GFX MMIO registers. */
>
> @@ -57,6 +65,21 @@ struct kgd2kfd_calls {
> };
>
> struct kfd2kgd_calls {
> + /* Memory management. */
> + int (*allocate_mem)(struct kgd_dev *kgd,
> + size_t size,
> + size_t alignment,
> + enum kgd_memory_pool pool,
> + struct kgd_mem **memory_handle);
> +
> + void (*free_mem)(struct kgd_dev *kgd, struct kgd_mem *memory_handle);
> +
> + int (*gpumap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *vmid0_address);
> + void (*ungpumap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem);
> +
> + int (*kmap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem, void **ptr);
> + void (*unkmap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem);
> +
> uint64_t (*get_vmem_size)(struct kgd_dev *kgd);
> };
>
> --
> 1.9.1
>
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <j.glisse@gmail.com>
To: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "David Airlie" <airlied@linux.ie>,
"Alex Deucher" <alexander.deucher@amd.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"John Bridgman" <John.Bridgman@amd.com>,
"Andrew Lewycky" <Andrew.Lewycky@amd.com>,
"Joerg Roedel" <joro@8bytes.org>,
"Oded Gabbay" <oded.gabbay@amd.com>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 06/83] drm/radeon: Add kfd-->kgd interfaces of memory allocation/mapping
Date: Fri, 11 Jul 2014 12:32:38 -0400 [thread overview]
Message-ID: <20140711163237.GG1870@gmail.com> (raw)
In-Reply-To: <1405029027-6085-5-git-send-email-oded.gabbay@amd.com>
On Fri, Jul 11, 2014 at 12:50:06AM +0300, Oded Gabbay wrote:
> This patch adds new interfaces to kfd2kgd_calls structure.
>
> The new interfaces allow the kfd driver to :
>
> 1. Allocated video memory through the radeon driver
> 2. Map and unmap video memory with GPUVM through the radeon driver
> 3. Map and unmap system memory with GPUVM through the radeon driver
>
> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
> ---
> drivers/gpu/drm/radeon/radeon_kfd.c | 129 ++++++++++++++++++++++++++++++++++++
> include/linux/radeon_kfd.h | 23 +++++++
> 2 files changed, 152 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c b/drivers/gpu/drm/radeon/radeon_kfd.c
> index 1b859b5..66ee36b 100644
> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
> @@ -25,9 +25,31 @@
> #include <drm/drmP.h>
> #include "radeon.h"
>
> +struct kgd_mem {
> + struct radeon_bo *bo;
> + u32 domain;
> +};
> +
> +static int allocate_mem(struct kgd_dev *kgd, size_t size, size_t alignment,
> + enum kgd_memory_pool pool, struct kgd_mem **memory_handle);
> +
> +static void free_mem(struct kgd_dev *kgd, struct kgd_mem *memory_handle);
> +
> +static int gpumap_mem(struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *vmid0_address);
> +static void ungpumap_mem(struct kgd_dev *kgd, struct kgd_mem *mem);
> +
> +static int kmap_mem(struct kgd_dev *kgd, struct kgd_mem *mem, void **ptr);
> +static void unkmap_mem(struct kgd_dev *kgd, struct kgd_mem *mem);
> +
> static uint64_t get_vmem_size(struct kgd_dev *kgd);
>
> static const struct kfd2kgd_calls kfd2kgd = {
> + .allocate_mem = allocate_mem,
> + .free_mem = free_mem,
> + .gpumap_mem = gpumap_mem,
> + .ungpumap_mem = ungpumap_mem,
> + .kmap_mem = kmap_mem,
> + .unkmap_mem = unkmap_mem,
> .get_vmem_size = get_vmem_size,
> };
>
> @@ -96,6 +118,113 @@ void radeon_kfd_device_fini(struct radeon_device *rdev)
> }
> }
>
> +static u32 pool_to_domain(enum kgd_memory_pool p)
> +{
> + switch (p) {
> + case KGD_POOL_FRAMEBUFFER: return RADEON_GEM_DOMAIN_VRAM;
> + default: return RADEON_GEM_DOMAIN_GTT;
> + }
> +}
> +
> +static int allocate_mem(struct kgd_dev *kgd, size_t size, size_t alignment,
> + enum kgd_memory_pool pool, struct kgd_mem **memory_handle)
> +{
> + struct radeon_device *rdev = (struct radeon_device *)kgd;
> + struct kgd_mem *mem;
> + int r;
> +
> + mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
> + if (!mem)
> + return -ENOMEM;
> +
> + mem->domain = pool_to_domain(pool);
> +
> + r = radeon_bo_create(rdev, size, alignment, true, mem->domain, NULL, &mem->bo);
> + if (r) {
> + kfree(mem);
> + return r;
> + }
> +
> + *memory_handle = mem;
> + return 0;
> +}
> +
> +static void free_mem(struct kgd_dev *kgd, struct kgd_mem *mem)
> +{
> + /* Assume that KFD will never free gpumapped or kmapped memory. This is not quite settled. */
> + radeon_bo_unref(&mem->bo);
> + kfree(mem);
> +}
> +
> +static int gpumap_mem(struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *vmid0_address)
> +{
> + int r;
> +
> + r = radeon_bo_reserve(mem->bo, true);
> +
> + /*
> + * ttm_bo_reserve can only fail if the buffer reservation lock
> + * is held in circumstances that would deadlock
> + */
> + BUG_ON(r != 0);
> + r = radeon_bo_pin(mem->bo, mem->domain, vmid0_address);
> + radeon_bo_unreserve(mem->bo);
> +
> + return r;
> +}
What is lifetime of such object ? Are they limited in size and number ? How
can the GFX side ie radeon force unmap them ?
Because pining is a big NO we only pin a handfull of buffer and the only
thing we allow userspace to pin are front buffer associated with crtc
which means there is a limited number of such buffer and there is a
legitimate use for pining them.
To me this looks like anyone can pin vram and thus starve the GFX side,
read DDOS.
Cheers,
Jérôme
> +
> +static void ungpumap_mem(struct kgd_dev *kgd, struct kgd_mem *mem)
> +{
> + int r;
> +
> + r = radeon_bo_reserve(mem->bo, true);
> +
> + /*
> + * ttm_bo_reserve can only fail if the buffer reservation lock
> + * is held in circumstances that would deadlock
> + */
> + BUG_ON(r != 0);
> + r = radeon_bo_unpin(mem->bo);
> +
> + /*
> + * This unpin only removed NO_EVICT placement flags
> + * and should never fail
> + */
> + BUG_ON(r != 0);
> + radeon_bo_unreserve(mem->bo);
> +}
> +
> +static int kmap_mem(struct kgd_dev *kgd, struct kgd_mem *mem, void **ptr)
> +{
> + int r;
> +
> + r = radeon_bo_reserve(mem->bo, true);
> +
> + /*
> + * ttm_bo_reserve can only fail if the buffer reservation lock
> + * is held in circumstances that would deadlock
> + */
> + BUG_ON(r != 0);
> + r = radeon_bo_kmap(mem->bo, ptr);
> + radeon_bo_unreserve(mem->bo);
> +
> + return r;
> +}
> +
> +static void unkmap_mem(struct kgd_dev *kgd, struct kgd_mem *mem)
> +{
> + int r;
> +
> + r = radeon_bo_reserve(mem->bo, true);
> + /*
> + * ttm_bo_reserve can only fail if the buffer reservation lock
> + * is held in circumstances that would deadlock
> + */
> + BUG_ON(r != 0);
> + radeon_bo_kunmap(mem->bo);
> + radeon_bo_unreserve(mem->bo);
> +}
> +
> static uint64_t get_vmem_size(struct kgd_dev *kgd)
> {
> struct radeon_device *rdev = (struct radeon_device *)kgd;
> diff --git a/include/linux/radeon_kfd.h b/include/linux/radeon_kfd.h
> index 28cddf5..c7997d4 100644
> --- a/include/linux/radeon_kfd.h
> +++ b/include/linux/radeon_kfd.h
> @@ -36,6 +36,14 @@ struct pci_dev;
> struct kfd_dev;
> struct kgd_dev;
>
> +struct kgd_mem;
> +
> +enum kgd_memory_pool {
> + KGD_POOL_SYSTEM_CACHEABLE = 1,
> + KGD_POOL_SYSTEM_WRITECOMBINE = 2,
> + KGD_POOL_FRAMEBUFFER = 3,
> +};
> +
> struct kgd2kfd_shared_resources {
> void __iomem *mmio_registers; /* Mapped pointer to GFX MMIO registers. */
>
> @@ -57,6 +65,21 @@ struct kgd2kfd_calls {
> };
>
> struct kfd2kgd_calls {
> + /* Memory management. */
> + int (*allocate_mem)(struct kgd_dev *kgd,
> + size_t size,
> + size_t alignment,
> + enum kgd_memory_pool pool,
> + struct kgd_mem **memory_handle);
> +
> + void (*free_mem)(struct kgd_dev *kgd, struct kgd_mem *memory_handle);
> +
> + int (*gpumap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *vmid0_address);
> + void (*ungpumap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem);
> +
> + int (*kmap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem, void **ptr);
> + void (*unkmap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem);
> +
> uint64_t (*get_vmem_size)(struct kgd_dev *kgd);
> };
>
> --
> 1.9.1
>
next prev parent reply other threads:[~2014-07-11 16:32 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-10 21:50 [PATCH 02/83] drm/radeon: reduce number of free VMIDs and pipes in KV Oded Gabbay
2014-07-10 21:50 ` [PATCH 03/83] drm/radeon: Report doorbell configuration to kfd Oded Gabbay
2014-07-11 16:16 ` Jerome Glisse
2014-07-11 16:16 ` Jerome Glisse
2014-07-10 21:50 ` [PATCH 04/83] drm/radeon: Add radeon <--> kfd interface Oded Gabbay
2014-07-10 22:38 ` Joe Perches
2014-07-10 22:38 ` Joe Perches
2014-07-11 16:24 ` Jerome Glisse
2014-07-11 16:24 ` Jerome Glisse
2014-07-17 11:55 ` Oded Gabbay
2014-07-10 21:50 ` [PATCH 05/83] drm/radeon: Add kfd-->kgd interface to get virtual ram size Oded Gabbay
2014-07-11 16:27 ` Jerome Glisse
2014-07-11 16:27 ` Jerome Glisse
2014-07-10 21:50 ` [PATCH 06/83] drm/radeon: Add kfd-->kgd interfaces of memory allocation/mapping Oded Gabbay
2014-07-11 16:32 ` Jerome Glisse [this message]
2014-07-11 16:32 ` Jerome Glisse
2014-07-10 21:50 ` [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of locking srbm_gfx_cntl register Oded Gabbay
2014-07-11 16:34 ` Jerome Glisse
2014-07-11 16:34 ` Jerome Glisse
2014-07-11 17:48 ` Bridgman, John
2014-07-11 17:48 ` Bridgman, John
2014-07-12 0:36 ` Bridgman, John
2014-07-12 0:36 ` Bridgman, John
2014-07-12 0:37 ` Bridgman, John
2014-07-12 0:37 ` Bridgman, John
2014-07-10 21:50 ` [PATCH 08/83] drm/radeon: Add calls to initialize and finalize kfd from radeon Oded Gabbay
2014-07-11 16:36 ` Jerome Glisse
2014-07-11 16:36 ` Jerome Glisse
2014-07-17 11:57 ` Oded Gabbay
2014-07-17 11:57 ` Oded Gabbay
2014-07-17 12:29 ` Christian König
2014-07-17 12:29 ` Christian König
2014-07-17 12:30 ` Oded Gabbay
2014-07-17 12:30 ` Oded Gabbay
2014-07-17 12:45 ` Christian König
2014-07-17 13:31 ` Daniel Vetter
2014-07-17 13:31 ` Daniel Vetter
2014-07-10 21:50 ` [PATCH 09/83] hsa/radeon: Add code base of hsa driver for AMD's GPUs Oded Gabbay
2014-07-11 17:04 ` Jerome Glisse
2014-07-11 17:04 ` Jerome Glisse
2014-07-11 17:28 ` Joe Perches
2014-07-11 17:28 ` Joe Perches
2014-07-17 11:51 ` Oded Gabbay
2014-07-17 11:51 ` Oded Gabbay
2014-07-11 17:40 ` Daniel Vetter
2014-07-11 17:40 ` Daniel Vetter
2014-07-11 18:02 ` Bridgman, John
2014-07-11 18:02 ` Bridgman, John
2014-07-11 18:10 ` Jerome Glisse
2014-07-11 18:10 ` Jerome Glisse
2014-07-11 18:46 ` Bridgman, John
2014-07-11 18:46 ` Bridgman, John
2014-07-11 18:51 ` Jerome Glisse
2014-07-11 18:51 ` Jerome Glisse
2014-07-11 18:56 ` Bridgman, John
2014-07-11 18:56 ` Bridgman, John
2014-07-11 19:22 ` Jerome Glisse
2014-07-11 19:22 ` Jerome Glisse
2014-07-11 19:38 ` Joe Perches
2014-07-11 19:38 ` Joe Perches
2014-07-17 11:51 ` Oded Gabbay
2014-07-17 11:51 ` Oded Gabbay
2014-07-10 21:50 ` [PATCH 10/83] hsa/radeon: Add initialization and unmapping of doorbell aperture Oded Gabbay
2014-07-10 21:50 ` [PATCH 11/83] hsa/radeon: Add scheduler code Oded Gabbay
2014-07-11 18:25 ` Jerome Glisse
2014-07-11 18:25 ` Jerome Glisse
2014-07-17 11:57 ` Oded Gabbay
2014-07-17 11:57 ` Oded Gabbay
2014-07-10 21:50 ` [PATCH 12/83] hsa/radeon: Add kfd mmap handler Oded Gabbay
2014-07-11 18:47 ` Jerome Glisse
2014-07-11 18:47 ` Jerome Glisse
2014-07-10 21:50 ` [PATCH 13/83] hsa/radeon: Add 2 new IOCTL to kfd, CREATE_QUEUE and DESTROY_QUEUE Oded Gabbay
2014-07-11 19:19 ` Jerome Glisse
2014-07-11 19:19 ` Jerome Glisse
2014-07-11 21:01 ` Jerome Glisse
2014-07-11 21:01 ` Jerome Glisse
2014-07-11 21:42 ` Dave Airlie
2014-07-11 21:42 ` Dave Airlie
2014-07-14 7:33 ` Gabbay, Oded
2014-07-14 7:33 ` Gabbay, Oded
2014-07-10 21:50 ` [PATCH 14/83] hsa/radeon: Update MAINTAINERS and CREDITS files Oded Gabbay
2014-07-10 21:50 ` [PATCH 15/83] hsa/radeon: Add interrupt handling module Oded Gabbay
2014-07-11 19:57 ` Jerome Glisse
2014-07-11 19:57 ` Jerome Glisse
2014-07-10 21:50 ` [PATCH 16/83] hsa/radeon: Add the isr function of the KFD scehduler Oded Gabbay
2014-07-10 21:50 ` [PATCH 17/83] hsa/radeon: Handle deactivation of queues using interrupts Oded Gabbay
2014-07-10 21:50 ` [PATCH 18/83] hsa/radeon: Enable interrupts in KFD scheduler Oded Gabbay
2014-07-10 21:50 ` [PATCH 19/83] hsa/radeon: Enable/Disable KFD interrupt module Oded Gabbay
2014-07-10 21:50 ` [PATCH 20/83] hsa/radeon: Add interrupt callback function to kgd2kfd interface Oded Gabbay
2014-07-10 21:50 ` [PATCH 21/83] hsa/radeon: Add kgd-->kfd interfaces for suspend and resume Oded Gabbay
2014-07-10 21:50 ` [PATCH 22/83] drm/radeon: Add calls to suspend and resume of kfd driver Oded Gabbay
2014-07-10 21:50 ` [PATCH 23/83] drm/radeon/cik: Don't touch int of pipes 1-7 Oded Gabbay
2014-07-10 21:50 ` [PATCH 24/83] drm/radeon/cik: Call kfd isr function Oded Gabbay
2014-07-10 21:50 ` [PATCH 25/83] hsa/radeon: fix the OEMID assignment in kfd_topology Oded Gabbay
2014-07-10 21:50 ` [PATCH 26/83] hsa/radeon: Make binding of process to device permanent Oded Gabbay
[not found] ` <1405029027-6085-1-git-send-email-oded.gabbay-5C7GfCeVMHo@public.gmane.org>
2014-07-10 21:50 ` [PATCH 27/83] hsa/radeon: Implement hsaKmtSetMemoryPolicy Oded Gabbay
2014-07-10 21:50 ` Oded Gabbay
2014-07-11 16:05 ` [PATCH 02/83] drm/radeon: reduce number of free VMIDs and pipes in KV Jerome Glisse
2014-07-11 16:05 ` Jerome Glisse
2014-07-11 16:18 ` Christian König
2014-07-11 16:18 ` Christian König
2014-07-11 16:22 ` Alex Deucher
2014-07-11 16:22 ` Alex Deucher
2014-07-11 17:07 ` Bridgman, John
2014-07-11 17:07 ` Bridgman, John
2014-07-11 17:59 ` Ilyes Gouta
2014-07-11 22:54 ` Bridgman, John
2014-07-11 22:54 ` Bridgman, John
2014-07-12 9:00 ` Christian König
2014-07-12 9:00 ` Christian König
2014-07-14 7:31 ` Michel Dänzer
2014-07-14 7:31 ` Michel Dänzer
2014-07-14 7:38 ` Michel Dänzer
2014-07-14 7:58 ` Christian König
2014-07-17 11:47 ` Oded Gabbay
2014-07-17 11:47 ` Oded Gabbay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140711163237.GG1870@gmail.com \
--to=j.glisse@gmail.com \
--cc=Andrew.Lewycky@amd.com \
--cc=alexander.deucher@amd.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oded.gabbay@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.