lkml.org 
[lkml]   [2014]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of locking srbm_gfx_cntl register
    Date
    Checking... we shouldn't need to call the lock from kfd any more.We should be able to do any required locking in radeon kgd code.

    >-----Original Message-----
    >From: Jerome Glisse [mailto:j.glisse@gmail.com]
    >Sent: Friday, July 11, 2014 12:35 PM
    >To: Oded Gabbay
    >Cc: David Airlie; Deucher, Alexander; linux-kernel@vger.kernel.org; dri-
    >devel@lists.freedesktop.org; Bridgman, John; Lewycky, Andrew; Joerg
    >Roedel; Gabbay, Oded; Koenig, Christian
    >Subject: Re: [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of locking
    >srbm_gfx_cntl register
    >
    >On Fri, Jul 11, 2014 at 12:50:07AM +0300, Oded Gabbay wrote:
    >> This patch adds a new interface to kfd2kgd_calls structure, which
    >> allows the kfd to lock and unlock the srbm_gfx_cntl register
    >
    >Why does kfd needs to lock this register if kfd can not access any of those
    >register ? This sounds broken to me, exposing a driver internal mutex to
    >another driver is not something i am fan of.
    >
    >Cheers,
    >Jérôme
    >
    >>
    >> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
    >> ---
    >> drivers/gpu/drm/radeon/radeon_kfd.c | 20 ++++++++++++++++++++
    >> include/linux/radeon_kfd.h | 4 ++++
    >> 2 files changed, 24 insertions(+)
    >>
    >> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c
    >> b/drivers/gpu/drm/radeon/radeon_kfd.c
    >> index 66ee36b..594020e 100644
    >> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
    >> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
    >> @@ -43,6 +43,10 @@ static void unkmap_mem(struct kgd_dev *kgd, struct
    >> kgd_mem *mem);
    >>
    >> static uint64_t get_vmem_size(struct kgd_dev *kgd);
    >>
    >> +static void lock_srbm_gfx_cntl(struct kgd_dev *kgd); static void
    >> +unlock_srbm_gfx_cntl(struct kgd_dev *kgd);
    >> +
    >> +
    >> static const struct kfd2kgd_calls kfd2kgd = {
    >> .allocate_mem = allocate_mem,
    >> .free_mem = free_mem,
    >> @@ -51,6 +55,8 @@ static const struct kfd2kgd_calls kfd2kgd = {
    >> .kmap_mem = kmap_mem,
    >> .unkmap_mem = unkmap_mem,
    >> .get_vmem_size = get_vmem_size,
    >> + .lock_srbm_gfx_cntl = lock_srbm_gfx_cntl,
    >> + .unlock_srbm_gfx_cntl = unlock_srbm_gfx_cntl,
    >> };
    >>
    >> static const struct kgd2kfd_calls *kgd2kfd; @@ -233,3 +239,17 @@
    >> static uint64_t get_vmem_size(struct kgd_dev *kgd)
    >>
    >> return rdev->mc.real_vram_size;
    >> }
    >> +
    >> +static void lock_srbm_gfx_cntl(struct kgd_dev *kgd) {
    >> + struct radeon_device *rdev = (struct radeon_device *)kgd;
    >> +
    >> + mutex_lock(&rdev->srbm_mutex);
    >> +}
    >> +
    >> +static void unlock_srbm_gfx_cntl(struct kgd_dev *kgd) {
    >> + struct radeon_device *rdev = (struct radeon_device *)kgd;
    >> +
    >> + mutex_unlock(&rdev->srbm_mutex);
    >> +}
    >> diff --git a/include/linux/radeon_kfd.h b/include/linux/radeon_kfd.h
    >> index c7997d4..40b691c 100644
    >> --- a/include/linux/radeon_kfd.h
    >> +++ b/include/linux/radeon_kfd.h
    >> @@ -81,6 +81,10 @@ struct kfd2kgd_calls {
    >> void (*unkmap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem);
    >>
    >> uint64_t (*get_vmem_size)(struct kgd_dev *kgd);
    >> +
    >> + /* SRBM_GFX_CNTL mutex */
    >> + void (*lock_srbm_gfx_cntl)(struct kgd_dev *kgd);
    >> + void (*unlock_srbm_gfx_cntl)(struct kgd_dev *kgd);
    >> };
    >>
    >> bool kgd2kfd_init(unsigned interface_version,
    >> --
    >> 1.9.1
    >>
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2014-07-11 20:41    [W:4.339 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site