> -----Original Message----- > From: Christian König [mailto:deathsimple at vodafone.de] > Sent: Wednesday, January 04, 2017 10:13 PM > To: Yu, Xiangliang <Xiangliang.Yu at amd.com>; Zhou, David(ChunMing) > <David1.Zhou at amd.com>; amd-gfx at lists.freedesktop.org; Liu, Monk > <Monk.Liu at amd.com> > Subject: Re: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface > queue(KIQ) > > Am 04.01.2017 um 14:26 schrieb Yu, Xiangliang: > >>>> 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? > > Ah! So you only map it initially to fill in some data structure during > initialization? Yeah, in this case just map the BO temporary, fill in the data and > unmap it again. Yes. > > Sorry, judging from the comments I thought that you map/unmap the BO > multiple times on each IOCTL. That is really something we should try to avoid. > > Just make sure that you don't store the pointer returned by kmap anywhere, > it is only valid temporarily. Got it. Thanks!