[V2 1/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >> Am 28.12.2016 um 03:59 schrieb Yu, Xiangliang:
> >>>> -----Original Message-----
> >>>> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On
> >>>> Behalf Of zhoucm1
> >>>> Sent: Wednesday, December 28, 2016 10:32 AM
> >>>> To: Yu, Xiangliang <Xiangliang.Yu at amd.com>; amd-
> >>>> gfx at lists.freedesktop.org
> >>>> Cc: Liu, Monk <Monk.Liu at amd.com>
> >>>> Subject: Re: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface
> >>>> queue(KIQ)
> >>>>
> >>>>
> >>>>
> >>>> On 2016å¹´12æ??28æ?¥ 10:27, Yu, Xiangliang wrote:
> >>>>> +
> >>>>>> +	amdgpu_bo_kunmap(kiq->eop_obj);
> >>>>>> +
> >>>> I see it is in many places, which is don't need I think,
> >>>> amdgpu_bo_free_kernel will handle it if I'm correct.
> >>> Memory kmap should be free ASAP from memory management point.
> >> No, that is completely unnecessary as long as you don't run a 32bit
> >> system with tight address space.
> > We can't decide what OS to use.  I agree with monk's comment that better
> to unmap it if cpu don't use.
> 
> No it isn't. As I said this is only necessary on 32bit systems with tight address
> space. In other words we simply don't really support that configuration any
> more.
> 
> If you don't need it then why do you want to kmap it in the first place?
> 

In my patch, first get mqd address to fill out mqd context through kmap, then setup compute queue with kiq ring.

And I see there are lot of similar usage in amdgpu, for example, gfx_v8_0_rlc_init function. Could you help to explain it?




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux