From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD83AC47423 for ; Fri, 2 Oct 2020 09:58:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 605F2207EA for ; Fri, 2 Oct 2020 09:58:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="Kv9fFmws" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387712AbgJBJ6i (ORCPT ); Fri, 2 Oct 2020 05:58:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgJBJ6i (ORCPT ); Fri, 2 Oct 2020 05:58:38 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2607EC0613D0 for ; Fri, 2 Oct 2020 02:58:36 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id z4so1120006wrr.4 for ; Fri, 02 Oct 2020 02:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=Kv9fFmwsLnH3rxc4YORHIlCmE7gMf2ANx+U1VpZfjN8Kq3n/95x+iLFFYY69i5o/VM aXKz1OGxaPgu4YEY2NOXjk9cQA0FvF45c+2KvuEJGmF6wRE5OG+7rgoxKuBnH3Yb2xng VP9WbgOJz1wPpF8BMrgVCxTdasm5/jVPq77KY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=XV24Kzu8dgCZimWhZQBbeyDV3ZWdelmlpNA2yU3IwD6Mm6Djv5L6W+aW742HqVe3Y1 yopPECNOjls1SEm+rBOyfsGvwN3I8Xw0ZlZa//6p7kcJ30pehYTlAjM+/eOus2X/ctBc 80iTylHCoxq+ExmWkGpDqKHUTfWi79N/zaRcVaRQ3fN4OQ9esfm2rCz3lf1Od/lUPo8C 77+mqwKgGt92Hpp+Er6YiaJX2fMuxW+nMF5fx7VQYA9yDLMOQH2LSb2jin6xfR9z5TmG x8yCt5pR4glcgy/1VaGpplls5Lm/BB7xktdpBx4TAmHq/oO+Pd5BJfcFVf9neTB1MEug gq5w== X-Gm-Message-State: AOAM531Ot0h0dXtvk10XxQMhm4S0nbCERyKrPSqIj4gYqQ3uhAEdBEUg 2HS0pokzGr+KMXgiB3uT+FSgXw== X-Google-Smtp-Source: ABdhPJyaxWM6azv8IiEEW0NJpIjAdBSSpixIyMrO0zJEmyGJ5I3RnUPpVbxcJ/Exwy9Zm9yRUkU4Bg== X-Received: by 2002:a5d:5751:: with SMTP id q17mr2092527wrw.409.1601632714647; Fri, 02 Oct 2020 02:58:34 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q18sm1109551wre.78.2020.10.02.02.58.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 02:58:33 -0700 (PDT) Date: Fri, 2 Oct 2020 11:58:30 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Thomas Zimmermann , Maarten Lankhorst , Maxime Ripard , Dave Airlie , Sam Ravnborg , Alex Deucher , Gerd Hoffmann , Lucas Stach , Russell King , Christian Gmeiner , Inki Dae , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Kukjin Kim , Krzysztof Kozlowski , Qiang Yu , Ben Skeggs , Rob Herring , Tomeu Vizoso , Steven Price , Alyssa Rosenzweig , Sandy Huang , Heiko =?iso-8859-1?Q?St=FCbner?= , Hans de Goede , Sean Paul , "Anholt, Eric" , Oleksandr Andrushchenko , Huang Rui , Sumit Semwal , Emil Velikov , Luben Tuikov , apaneers@amd.com, Linus Walleij , Melissa Wen , "Wilson, Chris" , Qinglang Miao , linux-samsung-soc , lima@lists.freedesktop.org, Nouveau Dev , The etnaviv authors , amd-gfx list , "open list:VIRTIO CORE, NET..." , "moderated list:DMA BUFFER SHARING FRAMEWORK" , "open list:ARM/Rockchip SoC..." , dri-devel , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" , "moderated list:DRM DRIVERS FOR XEN" , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" Subject: Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion Message-ID: <20201002095830.GH438822@phenom.ffwll.local> References: <20200929151437.19717-1-tzimmermann@suse.de> <20200929151437.19717-3-tzimmermann@suse.de> <8fad0114-064a-4ed5-c21d-d1b4294de0a1@amd.com> <2614314a-81f7-4722-c400-68d90e48e09a@suse.de> <8a84f62b-33f3-f44c-52af-c859a0e0d1fb@gmail.com> <07972ada-9135-3743-a86b-487f610c509f@suse.de> <20200930094712.GW438822@phenom.ffwll.local> <8479d0aa-3826-4f37-0109-55daca515793@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > On Wed, Sep 30, 2020 at 2:34 PM Christian König > wrote: > > > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote: > > >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: > > >>> Hi > > >>> > > >>> Am 30.09.20 um 10:05 schrieb Christian König: > > >>>> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: > > >>>>> Hi Christian > > >>>>> > > >>>>> Am 29.09.20 um 17:35 schrieb Christian König: > > >>>>>> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: > > >>>>>>> The new helper ttm_kmap_obj_to_dma_buf() extracts address and location > > >>>>>>> from and instance of TTM's kmap_obj and initializes struct dma_buf_map > > >>>>>>> with these values. Helpful for TTM-based drivers. > > >>>>>> We could completely drop that if we use the same structure inside TTM as > > >>>>>> well. > > >>>>>> > > >>>>>> Additional to that which driver is going to use this? > > >>>>> As Daniel mentioned, it's in patch 3. The TTM-based drivers will > > >>>>> retrieve the pointer via this function. > > >>>>> > > >>>>> I do want to see all that being more tightly integrated into TTM, but > > >>>>> not in this series. This one is about fixing the bochs-on-sparc64 > > >>>>> problem for good. Patch 7 adds an update to TTM to the DRM TODO list. > > >>>> I should have asked which driver you try to fix here :) > > >>>> > > >>>> In this case just keep the function inside bochs and only fix it there. > > >>>> > > >>>> All other drivers can be fixed when we generally pump this through TTM. > > >>> Did you take a look at patch 3? This function will be used by VRAM > > >>> helpers, nouveau, radeon, amdgpu and qxl. If we don't put it here, we > > >>> have to duplicate the functionality in each if these drivers. Bochs > > >>> itself uses VRAM helpers and doesn't touch the function directly. > > >> Ah, ok can we have that then only in the VRAM helpers? > > >> > > >> Alternative you could go ahead and use dma_buf_map in ttm_bo_kmap_obj > > >> directly and drop the hack with the TTM_BO_MAP_IOMEM_MASK. > > >> > > >> What I want to avoid is to have another conversion function in TTM because > > >> what happens here is that we already convert from ttm_bus_placement to > > >> ttm_bo_kmap_obj and then to dma_buf_map. > > > Hm I'm not really seeing how that helps with a gradual conversion of > > > everything over to dma_buf_map and assorted helpers for access? There's > > > too many places in ttm drivers where is_iomem and related stuff is used to > > > be able to convert it all in one go. An intermediate state with a bunch of > > > conversions seems fairly unavoidable to me. > > > > Fair enough. I would just have started bottom up and not top down. > > > > Anyway feel free to go ahead with this approach as long as we can remove > > the new function again when we clean that stuff up for good. > > Yeah I guess bottom up would make more sense as a refactoring. But the > main motivation to land this here is to fix the __mmio vs normal > memory confusion in the fbdev emulation helpers for sparc (and > anything else that needs this). Hence the top down approach for > rolling this out. Ok I started reviewing this a bit more in-depth, and I think this is a bit too much of a de-tour. Looking through all the callers of ttm_bo_kmap almost everyone maps the entire object. Only vmwgfx uses to map less than that. Also, everyone just immediately follows up with converting that full object map into a pointer. So I think what we really want here is: - new function int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); _vmap name since that's consistent with both dma_buf functions and what's usually used to implement this. Outside of the ttm world kmap usually just means single-page mappings using kmap() or it's iomem sibling io_mapping_map* so rather confusing name for a function which usually is just used to set up a vmap of the entire buffer. - a helper which can be used for the drm_gem_object_funcs vmap/vunmap functions for all ttm drivers. We should be able to make this fully generic because a) we now have dma_buf_map and b) drm_gem_object is embedded in the ttm_bo, so we can upcast for everyone who's both a ttm and gem driver. This is maybe a good follow-up, since it should allow us to ditch quite a bit of the vram helper code for this more generic stuff. I also might have missed some special-cases here, but from a quick look everything just pins the buffer to the current location and that's it. Also this obviously requires Christian's generic ttm_bo_pin rework first. - roll the above out to drivers. Christian/Thomas, thoughts on this? I think for the immediate need of rolling this out for vram helpers and fbdev code we should be able to do this, but just postpone the driver wide roll-out for now. Cheers, Daniel > -Daniel > > > > > Christian. > > > > > -Daniel > > > > > >> Thanks, > > >> Christian. > > >> > > >>> Best regards > > >>> Thomas > > >>> > > >>>> Regards, > > >>>> Christian. > > >>>> > > >>>>> Best regards > > >>>>> Thomas > > >>>>> > > >>>>>> Regards, > > >>>>>> Christian. > > >>>>>> > > >>>>>>> Signed-off-by: Thomas Zimmermann > > >>>>>>> --- > > >>>>>>> include/drm/ttm/ttm_bo_api.h | 24 ++++++++++++++++++++++++ > > >>>>>>> include/linux/dma-buf-map.h | 20 ++++++++++++++++++++ > > >>>>>>> 2 files changed, 44 insertions(+) > > >>>>>>> > > >>>>>>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h > > >>>>>>> index c96a25d571c8..62d89f05a801 100644 > > >>>>>>> --- a/include/drm/ttm/ttm_bo_api.h > > >>>>>>> +++ b/include/drm/ttm/ttm_bo_api.h > > >>>>>>> @@ -34,6 +34,7 @@ > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> +#include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> @@ -486,6 +487,29 @@ static inline void *ttm_kmap_obj_virtual(struct > > >>>>>>> ttm_bo_kmap_obj *map, > > >>>>>>> return map->virtual; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * ttm_kmap_obj_to_dma_buf_map > > >>>>>>> + * > > >>>>>>> + * @kmap: A struct ttm_bo_kmap_obj returned from ttm_bo_kmap. > > >>>>>>> + * @map: Returns the mapping as struct dma_buf_map > > >>>>>>> + * > > >>>>>>> + * Converts struct ttm_bo_kmap_obj to struct dma_buf_map. If the memory > > >>>>>>> + * is not mapped, the returned mapping is initialized to NULL. > > >>>>>>> + */ > > >>>>>>> +static inline void ttm_kmap_obj_to_dma_buf_map(struct ttm_bo_kmap_obj > > >>>>>>> *kmap, > > >>>>>>> + struct dma_buf_map *map) > > >>>>>>> +{ > > >>>>>>> + bool is_iomem; > > >>>>>>> + void *vaddr = ttm_kmap_obj_virtual(kmap, &is_iomem); > > >>>>>>> + > > >>>>>>> + if (!vaddr) > > >>>>>>> + dma_buf_map_clear(map); > > >>>>>>> + else if (is_iomem) > > >>>>>>> + dma_buf_map_set_vaddr_iomem(map, (void __force __iomem *)vaddr); > > >>>>>>> + else > > >>>>>>> + dma_buf_map_set_vaddr(map, vaddr); > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * ttm_bo_kmap > > >>>>>>> * > > >>>>>>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h > > >>>>>>> index fd1aba545fdf..2e8bbecb5091 100644 > > >>>>>>> --- a/include/linux/dma-buf-map.h > > >>>>>>> +++ b/include/linux/dma-buf-map.h > > >>>>>>> @@ -45,6 +45,12 @@ > > >>>>>>> * > > >>>>>>> * dma_buf_map_set_vaddr(&map. 0xdeadbeaf); > > >>>>>>> * > > >>>>>>> + * To set an address in I/O memory, use dma_buf_map_set_vaddr_iomem(). > > >>>>>>> + * > > >>>>>>> + * .. code-block:: c > > >>>>>>> + * > > >>>>>>> + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf); > > >>>>>>> + * > > >>>>>>> * Test if a mapping is valid with either dma_buf_map_is_set() or > > >>>>>>> * dma_buf_map_is_null(). > > >>>>>>> * > > >>>>>>> @@ -118,6 +124,20 @@ static inline void dma_buf_map_set_vaddr(struct > > >>>>>>> dma_buf_map *map, void *vaddr) > > >>>>>>> map->is_iomem = false; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping structure to > > >>>>>>> an address in I/O memory > > >>>>>>> + * @map: The dma-buf mapping structure > > >>>>>>> + * @vaddr_iomem: An I/O-memory address > > >>>>>>> + * > > >>>>>>> + * Sets the address and the I/O-memory flag. > > >>>>>>> + */ > > >>>>>>> +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_map *map, > > >>>>>>> + void __iomem *vaddr_iomem) > > >>>>>>> +{ > > >>>>>>> + map->vaddr_iomem = vaddr_iomem; > > >>>>>>> + map->is_iomem = true; > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * dma_buf_map_is_equal - Compares two dma-buf mapping structures > > >>>>>>> for equality > > >>>>>>> * @lhs: The dma-buf mapping structure > > >>>>>> _______________________________________________ > > >>>>>> dri-devel mailing list > > >>>>>> dri-devel@lists.freedesktop.org > > >>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=HdHOA%2F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=0 > > >>>>> _______________________________________________ > > >>>>> amd-gfx mailing list > > >>>>> amd-gfx@lists.freedesktop.org > > >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=H%2B5HKCsTrksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=0 > > >>>> _______________________________________________ > > >>>> dri-devel mailing list > > >>>> dri-devel@lists.freedesktop.org > > >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=HdHOA%2F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=0 > > >>>> > > >>> _______________________________________________ > > >>> amd-gfx mailing list > > >>> amd-gfx@lists.freedesktop.org > > >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=H%2B5HKCsTrksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=0 > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion Date: Fri, 2 Oct 2020 11:58:30 +0200 Message-ID: <20201002095830.GH438822@phenom.ffwll.local> References: <20200929151437.19717-1-tzimmermann@suse.de> <20200929151437.19717-3-tzimmermann@suse.de> <8fad0114-064a-4ed5-c21d-d1b4294de0a1@amd.com> <2614314a-81f7-4722-c400-68d90e48e09a@suse.de> <8a84f62b-33f3-f44c-52af-c859a0e0d1fb@gmail.com> <07972ada-9135-3743-a86b-487f610c509f@suse.de> <20200930094712.GW438822@phenom.ffwll.local> <8479d0aa-3826-4f37-0109-55daca515793@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Thomas Zimmermann , Maarten Lankhorst , Maxime Ripard , Dave Airlie , Sam Ravnborg , Alex Deucher , Gerd Hoffmann , Lucas Stach , Russell King , Christian Gmeiner , Inki Dae , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Kukjin Kim , Krzysztof Kozlowski , Qiang Yu , Ben Skeggs , Rob Herring , Tomeu Vizoso List-Id: nouveau.vger.kernel.org On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > On Wed, Sep 30, 2020 at 2:34 PM Christian König > wrote: > > > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote: > > >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: > > >>> Hi > > >>> > > >>> Am 30.09.20 um 10:05 schrieb Christian König: > > >>>> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: > > >>>>> Hi Christian > > >>>>> > > >>>>> Am 29.09.20 um 17:35 schrieb Christian König: > > >>>>>> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: > > >>>>>>> The new helper ttm_kmap_obj_to_dma_buf() extracts address and location > > >>>>>>> from and instance of TTM's kmap_obj and initializes struct dma_buf_map > > >>>>>>> with these values. Helpful for TTM-based drivers. > > >>>>>> We could completely drop that if we use the same structure inside TTM as > > >>>>>> well. > > >>>>>> > > >>>>>> Additional to that which driver is going to use this? > > >>>>> As Daniel mentioned, it's in patch 3. The TTM-based drivers will > > >>>>> retrieve the pointer via this function. > > >>>>> > > >>>>> I do want to see all that being more tightly integrated into TTM, but > > >>>>> not in this series. This one is about fixing the bochs-on-sparc64 > > >>>>> problem for good. Patch 7 adds an update to TTM to the DRM TODO list. > > >>>> I should have asked which driver you try to fix here :) > > >>>> > > >>>> In this case just keep the function inside bochs and only fix it there. > > >>>> > > >>>> All other drivers can be fixed when we generally pump this through TTM. > > >>> Did you take a look at patch 3? This function will be used by VRAM > > >>> helpers, nouveau, radeon, amdgpu and qxl. If we don't put it here, we > > >>> have to duplicate the functionality in each if these drivers. Bochs > > >>> itself uses VRAM helpers and doesn't touch the function directly. > > >> Ah, ok can we have that then only in the VRAM helpers? > > >> > > >> Alternative you could go ahead and use dma_buf_map in ttm_bo_kmap_obj > > >> directly and drop the hack with the TTM_BO_MAP_IOMEM_MASK. > > >> > > >> What I want to avoid is to have another conversion function in TTM because > > >> what happens here is that we already convert from ttm_bus_placement to > > >> ttm_bo_kmap_obj and then to dma_buf_map. > > > Hm I'm not really seeing how that helps with a gradual conversion of > > > everything over to dma_buf_map and assorted helpers for access? There's > > > too many places in ttm drivers where is_iomem and related stuff is used to > > > be able to convert it all in one go. An intermediate state with a bunch of > > > conversions seems fairly unavoidable to me. > > > > Fair enough. I would just have started bottom up and not top down. > > > > Anyway feel free to go ahead with this approach as long as we can remove > > the new function again when we clean that stuff up for good. > > Yeah I guess bottom up would make more sense as a refactoring. But the > main motivation to land this here is to fix the __mmio vs normal > memory confusion in the fbdev emulation helpers for sparc (and > anything else that needs this). Hence the top down approach for > rolling this out. Ok I started reviewing this a bit more in-depth, and I think this is a bit too much of a de-tour. Looking through all the callers of ttm_bo_kmap almost everyone maps the entire object. Only vmwgfx uses to map less than that. Also, everyone just immediately follows up with converting that full object map into a pointer. So I think what we really want here is: - new function int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); _vmap name since that's consistent with both dma_buf functions and what's usually used to implement this. Outside of the ttm world kmap usually just means single-page mappings using kmap() or it's iomem sibling io_mapping_map* so rather confusing name for a function which usually is just used to set up a vmap of the entire buffer. - a helper which can be used for the drm_gem_object_funcs vmap/vunmap functions for all ttm drivers. We should be able to make this fully generic because a) we now have dma_buf_map and b) drm_gem_object is embedded in the ttm_bo, so we can upcast for everyone who's both a ttm and gem driver. This is maybe a good follow-up, since it should allow us to ditch quite a bit of the vram helper code for this more generic stuff. I also might have missed some special-cases here, but from a quick look everything just pins the buffer to the current location and that's it. Also this obviously requires Christian's generic ttm_bo_pin rework first. - roll the above out to drivers. Christian/Thomas, thoughts on this? I think for the immediate need of rolling this out for vram helpers and fbdev code we should be able to do this, but just postpone the driver wide roll-out for now. Cheers, Daniel > -Daniel > > > > > Christian. > > > > > -Daniel > > > > > >> Thanks, > > >> Christian. > > >> > > >>> Best regards > > >>> Thomas > > >>> > > >>>> Regards, > > >>>> Christian. > > >>>> > > >>>>> Best regards > > >>>>> Thomas > > >>>>> > > >>>>>> Regards, > > >>>>>> Christian. > > >>>>>> > > >>>>>>> Signed-off-by: Thomas Zimmermann > > >>>>>>> --- > > >>>>>>> include/drm/ttm/ttm_bo_api.h | 24 ++++++++++++++++++++++++ > > >>>>>>> include/linux/dma-buf-map.h | 20 ++++++++++++++++++++ > > >>>>>>> 2 files changed, 44 insertions(+) > > >>>>>>> > > >>>>>>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h > > >>>>>>> index c96a25d571c8..62d89f05a801 100644 > > >>>>>>> --- a/include/drm/ttm/ttm_bo_api.h > > >>>>>>> +++ b/include/drm/ttm/ttm_bo_api.h > > >>>>>>> @@ -34,6 +34,7 @@ > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> +#include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> @@ -486,6 +487,29 @@ static inline void *ttm_kmap_obj_virtual(struct > > >>>>>>> ttm_bo_kmap_obj *map, > > >>>>>>> return map->virtual; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * ttm_kmap_obj_to_dma_buf_map > > >>>>>>> + * > > >>>>>>> + * @kmap: A struct ttm_bo_kmap_obj returned from ttm_bo_kmap. > > >>>>>>> + * @map: Returns the mapping as struct dma_buf_map > > >>>>>>> + * > > >>>>>>> + * Converts struct ttm_bo_kmap_obj to struct dma_buf_map. If the memory > > >>>>>>> + * is not mapped, the returned mapping is initialized to NULL. > > >>>>>>> + */ > > >>>>>>> +static inline void ttm_kmap_obj_to_dma_buf_map(struct ttm_bo_kmap_obj > > >>>>>>> *kmap, > > >>>>>>> + struct dma_buf_map *map) > > >>>>>>> +{ > > >>>>>>> + bool is_iomem; > > >>>>>>> + void *vaddr = ttm_kmap_obj_virtual(kmap, &is_iomem); > > >>>>>>> + > > >>>>>>> + if (!vaddr) > > >>>>>>> + dma_buf_map_clear(map); > > >>>>>>> + else if (is_iomem) > > >>>>>>> + dma_buf_map_set_vaddr_iomem(map, (void __force __iomem *)vaddr); > > >>>>>>> + else > > >>>>>>> + dma_buf_map_set_vaddr(map, vaddr); > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * ttm_bo_kmap > > >>>>>>> * > > >>>>>>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h > > >>>>>>> index fd1aba545fdf..2e8bbecb5091 100644 > > >>>>>>> --- a/include/linux/dma-buf-map.h > > >>>>>>> +++ b/include/linux/dma-buf-map.h > > >>>>>>> @@ -45,6 +45,12 @@ > > >>>>>>> * > > >>>>>>> * dma_buf_map_set_vaddr(&map. 0xdeadbeaf); > > >>>>>>> * > > >>>>>>> + * To set an address in I/O memory, use dma_buf_map_set_vaddr_iomem(). > > >>>>>>> + * > > >>>>>>> + * .. code-block:: c > > >>>>>>> + * > > >>>>>>> + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf); > > >>>>>>> + * > > >>>>>>> * Test if a mapping is valid with either dma_buf_map_is_set() or > > >>>>>>> * dma_buf_map_is_null(). > > >>>>>>> * > > >>>>>>> @@ -118,6 +124,20 @@ static inline void dma_buf_map_set_vaddr(struct > > >>>>>>> dma_buf_map *map, void *vaddr) > > >>>>>>> map->is_iomem = false; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping structure to > > >>>>>>> an address in I/O memory > > >>>>>>> + * @map: The dma-buf mapping structure > > >>>>>>> + * @vaddr_iomem: An I/O-memory address > > >>>>>>> + * > > >>>>>>> + * Sets the address and the I/O-memory flag. > > >>>>>>> + */ > > >>>>>>> +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_map *map, > > >>>>>>> + void __iomem *vaddr_iomem) > > >>>>>>> +{ > > >>>>>>> + map->vaddr_iomem = vaddr_iomem; > > >>>>>>> + map->is_iomem = true; > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * dma_buf_map_is_equal - Compares two dma-buf mapping structures > > >>>>>>> for equality > > >>>>>>> * @lhs: The dma-buf mapping structure > > >>>>>> _______________________________________________ > > >>>>>> dri-devel mailing list > > >>>>>> dri-devel@lists.freedesktop.org > > >>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=HdHOA%2F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=0 > > >>>>> _______________________________________________ > > >>>>> amd-gfx mailing list > > >>>>> amd-gfx@lists.freedesktop.org > > >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=H%2B5HKCsTrksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=0 > > >>>> _______________________________________________ > > >>>> dri-devel mailing list > > >>>> dri-devel@lists.freedesktop.org > > >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=HdHOA%2F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=0 > > >>>> > > >>> _______________________________________________ > > >>> amd-gfx mailing list > > >>> amd-gfx@lists.freedesktop.org > > >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=H%2B5HKCsTrksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=0 > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFE40C4363D for ; Fri, 2 Oct 2020 09:58:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6F711206DD for ; Fri, 2 Oct 2020 09:58:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jCDzvQ//"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="Kv9fFmws" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F711206DD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=I02jyY2HVZQcXNDEY8k+4sfU6cXNldAkGydut+XD/Mc=; b=jCDzvQ//SPHB6dPcvVWSX83hg De9ZnwY+jNMz2/sPjo4Y41zsVkpDiqU1pm1AGDyAoIiKPeT5/8aOQmTBbzdDSf/3eVOHKjwouk6Dz ydvjR1vte8VreLUhNxGjskWUYUFDqX3S7mygEQ7uyp+g7ZGXk4IXER0h5Uy32MR3/mzgzk+ExNV5D aPJ8TZXbRK8e6EirkVtuLPBYjN05exsICKKT9A1rHhe+9uRZBrkyR7S3ffh8dmeYLooNLDm/3yjF9 7QFjJn5Ls/Bw/EdbxEQ96328Z7W3LXr+GILwQKuaDwNCWzQoKNgHDbAGp1tFMDdCTkxoZHQrFeMZy LewjBvc9g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOHpo-000181-Nh; Fri, 02 Oct 2020 09:58:40 +0000 Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOHpj-00016l-Sy for linux-rockchip@lists.infradead.org; Fri, 02 Oct 2020 09:58:39 +0000 Received: by mail-wr1-x442.google.com with SMTP id x14so1093189wrl.12 for ; Fri, 02 Oct 2020 02:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=Kv9fFmwsLnH3rxc4YORHIlCmE7gMf2ANx+U1VpZfjN8Kq3n/95x+iLFFYY69i5o/VM aXKz1OGxaPgu4YEY2NOXjk9cQA0FvF45c+2KvuEJGmF6wRE5OG+7rgoxKuBnH3Yb2xng VP9WbgOJz1wPpF8BMrgVCxTdasm5/jVPq77KY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=k98k/072PDAuSEFILXjBl0aNSYgFlvUOrsmKoflc+c8iiwnJwTwIzZf4rHrF3MPuZ9 Eubs8/BV5sFm2hpBGyZnfpJ8RoEOI+B+5vmHr77s6BryWuIn13i1DS6DrydOvAaTC/3d QXD2gbiNmKBTlp9xWFVMsYELPEUt5FmdtuYGdf25EAQJc5Pjdo8bvL154se4gBU/efGX ykk1f4WITb2mThdQh69fh4Rr0lU18QgCQeeymuEHOfKZ6+p8B7G6w0UjD9qDLFOVCaY8 mihU3DKSpw5Y/8yYpPWtofIoS4PmcInmaQQh+HUNCr437FXvOxDo/dfD/Csq+7VxrXRr RzBA== X-Gm-Message-State: AOAM5326GdcQwfuuCQDT/99Jp0VRhq2Op7aSa2Df0TD0/+TNwevIKnFZ y1ztKrhqPFM+55Vl1J24x4OhNQ== X-Google-Smtp-Source: ABdhPJyaxWM6azv8IiEEW0NJpIjAdBSSpixIyMrO0zJEmyGJ5I3RnUPpVbxcJ/Exwy9Zm9yRUkU4Bg== X-Received: by 2002:a5d:5751:: with SMTP id q17mr2092527wrw.409.1601632714647; Fri, 02 Oct 2020 02:58:34 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q18sm1109551wre.78.2020.10.02.02.58.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 02:58:33 -0700 (PDT) Date: Fri, 2 Oct 2020 11:58:30 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion Message-ID: <20201002095830.GH438822@phenom.ffwll.local> References: <20200929151437.19717-1-tzimmermann@suse.de> <20200929151437.19717-3-tzimmermann@suse.de> <8fad0114-064a-4ed5-c21d-d1b4294de0a1@amd.com> <2614314a-81f7-4722-c400-68d90e48e09a@suse.de> <8a84f62b-33f3-f44c-52af-c859a0e0d1fb@gmail.com> <07972ada-9135-3743-a86b-487f610c509f@suse.de> <20200930094712.GW438822@phenom.ffwll.local> <8479d0aa-3826-4f37-0109-55daca515793@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201002_055835_995237_387C7E1B X-CRM114-Status: GOOD ( 52.55 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Luben Tuikov , Heiko =?iso-8859-1?Q?St=FCbner?= , Dave Airlie , Nouveau Dev , Linus Walleij , dri-devel , "Wilson, Chris" , Melissa Wen , "Anholt, Eric" , Huang Rui , Gerd Hoffmann , Sam Ravnborg , Sumit Semwal , Emil Velikov , Rob Herring , linux-samsung-soc , Joonyoung Shim , lima@lists.freedesktop.org, Oleksandr Andrushchenko , Krzysztof Kozlowski , Steven Price , "open list:ARM/Rockchip SoC..." , Kukjin Kim , Alyssa Rosenzweig , Russell King , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" , Ben Skeggs , Maarten Lankhorst , The etnaviv authors , Maxime Ripard , Inki Dae , Hans de Goede , Christian Gmeiner , "moderated list:DRM DRIVERS FOR XEN" , "open list:VIRTIO CORE, NET..." , Sean Paul , apaneers@amd.com, Linux ARM , "moderated list:DMA BUFFER SHARING FRAMEWORK" , amd-gfx list , Tomeu Vizoso , Seung-Woo Kim , Sandy Huang , Kyungmin Park , Qinglang Miao , Qiang Yu , Thomas Zimmermann , Alex Deucher , "open list:DMA BUFFER SHARING FRAMEWORK" , Lucas Stach Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > On Wed, Sep 30, 2020 at 2:34 PM Christian K=F6nig > wrote: > > > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian K=F6nig wrote: > > >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: > > >>> Hi > > >>> > > >>> Am 30.09.20 um 10:05 schrieb Christian K=F6nig: > > >>>> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: > > >>>>> Hi Christian > > >>>>> > > >>>>> Am 29.09.20 um 17:35 schrieb Christian K=F6nig: > > >>>>>> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: > > >>>>>>> The new helper ttm_kmap_obj_to_dma_buf() extracts address and l= ocation > > >>>>>>> from and instance of TTM's kmap_obj and initializes struct dma_= buf_map > > >>>>>>> with these values. Helpful for TTM-based drivers. > > >>>>>> We could completely drop that if we use the same structure insid= e TTM as > > >>>>>> well. > > >>>>>> > > >>>>>> Additional to that which driver is going to use this? > > >>>>> As Daniel mentioned, it's in patch 3. The TTM-based drivers will > > >>>>> retrieve the pointer via this function. > > >>>>> > > >>>>> I do want to see all that being more tightly integrated into TTM,= but > > >>>>> not in this series. This one is about fixing the bochs-on-sparc64 > > >>>>> problem for good. Patch 7 adds an update to TTM to the DRM TODO l= ist. > > >>>> I should have asked which driver you try to fix here :) > > >>>> > > >>>> In this case just keep the function inside bochs and only fix it t= here. > > >>>> > > >>>> All other drivers can be fixed when we generally pump this through= TTM. > > >>> Did you take a look at patch 3? This function will be used by VRAM > > >>> helpers, nouveau, radeon, amdgpu and qxl. If we don't put it here, = we > > >>> have to duplicate the functionality in each if these drivers. Bochs > > >>> itself uses VRAM helpers and doesn't touch the function directly. > > >> Ah, ok can we have that then only in the VRAM helpers? > > >> > > >> Alternative you could go ahead and use dma_buf_map in ttm_bo_kmap_obj > > >> directly and drop the hack with the TTM_BO_MAP_IOMEM_MASK. > > >> > > >> What I want to avoid is to have another conversion function in TTM b= ecause > > >> what happens here is that we already convert from ttm_bus_placement = to > > >> ttm_bo_kmap_obj and then to dma_buf_map. > > > Hm I'm not really seeing how that helps with a gradual conversion of > > > everything over to dma_buf_map and assorted helpers for access? There= 's > > > too many places in ttm drivers where is_iomem and related stuff is us= ed to > > > be able to convert it all in one go. An intermediate state with a bun= ch of > > > conversions seems fairly unavoidable to me. > > > > Fair enough. I would just have started bottom up and not top down. > > > > Anyway feel free to go ahead with this approach as long as we can remove > > the new function again when we clean that stuff up for good. > = > Yeah I guess bottom up would make more sense as a refactoring. But the > main motivation to land this here is to fix the __mmio vs normal > memory confusion in the fbdev emulation helpers for sparc (and > anything else that needs this). Hence the top down approach for > rolling this out. Ok I started reviewing this a bit more in-depth, and I think this is a bit too much of a de-tour. Looking through all the callers of ttm_bo_kmap almost everyone maps the entire object. Only vmwgfx uses to map less than that. Also, everyone just immediately follows up with converting that full object map into a pointer. So I think what we really want here is: - new function int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); _vmap name since that's consistent with both dma_buf functions and what's usually used to implement this. Outside of the ttm world kmap usually just means single-page mappings using kmap() or it's iomem sibling io_mapping_map* so rather confusing name for a function which usually is just used to set up a vmap of the entire buffer. - a helper which can be used for the drm_gem_object_funcs vmap/vunmap functions for all ttm drivers. We should be able to make this fully generic because a) we now have dma_buf_map and b) drm_gem_object is embedded in the ttm_bo, so we can upcast for everyone who's both a ttm and gem driver. This is maybe a good follow-up, since it should allow us to ditch quite a bit of the vram helper code for this more generic stuff. I also might have missed some special-cases here, but from a quick look everything just pins the buffer to the current location and that's it. Also this obviously requires Christian's generic ttm_bo_pin rework first. - roll the above out to drivers. Christian/Thomas, thoughts on this? I think for the immediate need of rolling this out for vram helpers and fbdev code we should be able to do this, but just postpone the driver wide roll-out for now. Cheers, Daniel > -Daniel > = > > > > Christian. > > > > > -Daniel > > > > > >> Thanks, > > >> Christian. > > >> > > >>> Best regards > > >>> Thomas > > >>> > > >>>> Regards, > > >>>> Christian. > > >>>> > > >>>>> Best regards > > >>>>> Thomas > > >>>>> > > >>>>>> Regards, > > >>>>>> Christian. > > >>>>>> > > >>>>>>> Signed-off-by: Thomas Zimmermann > > >>>>>>> --- > > >>>>>>> include/drm/ttm/ttm_bo_api.h | 24 ++++++++++++++++++++++++ > > >>>>>>> include/linux/dma-buf-map.h | 20 ++++++++++++++++++++ > > >>>>>>> 2 files changed, 44 insertions(+) > > >>>>>>> > > >>>>>>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm= _bo_api.h > > >>>>>>> index c96a25d571c8..62d89f05a801 100644 > > >>>>>>> --- a/include/drm/ttm/ttm_bo_api.h > > >>>>>>> +++ b/include/drm/ttm/ttm_bo_api.h > > >>>>>>> @@ -34,6 +34,7 @@ > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> +#include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> @@ -486,6 +487,29 @@ static inline void *ttm_kmap_obj_virtual(s= truct > > >>>>>>> ttm_bo_kmap_obj *map, > > >>>>>>> return map->virtual; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * ttm_kmap_obj_to_dma_buf_map > > >>>>>>> + * > > >>>>>>> + * @kmap: A struct ttm_bo_kmap_obj returned from ttm_bo_kmap. > > >>>>>>> + * @map: Returns the mapping as struct dma_buf_map > > >>>>>>> + * > > >>>>>>> + * Converts struct ttm_bo_kmap_obj to struct dma_buf_map. If t= he memory > > >>>>>>> + * is not mapped, the returned mapping is initialized to NULL. > > >>>>>>> + */ > > >>>>>>> +static inline void ttm_kmap_obj_to_dma_buf_map(struct ttm_bo_k= map_obj > > >>>>>>> *kmap, > > >>>>>>> + struct dma_buf_map *map) > > >>>>>>> +{ > > >>>>>>> + bool is_iomem; > > >>>>>>> + void *vaddr =3D ttm_kmap_obj_virtual(kmap, &is_iomem); > > >>>>>>> + > > >>>>>>> + if (!vaddr) > > >>>>>>> + dma_buf_map_clear(map); > > >>>>>>> + else if (is_iomem) > > >>>>>>> + dma_buf_map_set_vaddr_iomem(map, (void __force __iomem= *)vaddr); > > >>>>>>> + else > > >>>>>>> + dma_buf_map_set_vaddr(map, vaddr); > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * ttm_bo_kmap > > >>>>>>> * > > >>>>>>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-bu= f-map.h > > >>>>>>> index fd1aba545fdf..2e8bbecb5091 100644 > > >>>>>>> --- a/include/linux/dma-buf-map.h > > >>>>>>> +++ b/include/linux/dma-buf-map.h > > >>>>>>> @@ -45,6 +45,12 @@ > > >>>>>>> * > > >>>>>>> * dma_buf_map_set_vaddr(&map. 0xdeadbeaf); > > >>>>>>> * > > >>>>>>> + * To set an address in I/O memory, use dma_buf_map_set_vaddr_= iomem(). > > >>>>>>> + * > > >>>>>>> + * .. code-block:: c > > >>>>>>> + * > > >>>>>>> + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf); > > >>>>>>> + * > > >>>>>>> * Test if a mapping is valid with either dma_buf_map_is_se= t() or > > >>>>>>> * dma_buf_map_is_null(). > > >>>>>>> * > > >>>>>>> @@ -118,6 +124,20 @@ static inline void dma_buf_map_set_vaddr(s= truct > > >>>>>>> dma_buf_map *map, void *vaddr) > > >>>>>>> map->is_iomem =3D false; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping struct= ure to > > >>>>>>> an address in I/O memory > > >>>>>>> + * @map: The dma-buf mapping structure > > >>>>>>> + * @vaddr_iomem: An I/O-memory address > > >>>>>>> + * > > >>>>>>> + * Sets the address and the I/O-memory flag. > > >>>>>>> + */ > > >>>>>>> +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_= map *map, > > >>>>>>> + void __iomem *vaddr_iomem) > > >>>>>>> +{ > > >>>>>>> + map->vaddr_iomem =3D vaddr_iomem; > > >>>>>>> + map->is_iomem =3D true; > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * dma_buf_map_is_equal - Compares two dma-buf mapping stru= ctures > > >>>>>>> for equality > > >>>>>>> * @lhs: The dma-buf mapping structure > > >>>>>> _______________________________________________ > > >>>>>> dri-devel mailing list > > >>>>>> dri-devel@lists.freedesktop.org > > >>>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C= 01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd896= 1fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHdHOA%2= F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 > > >>>>> _______________________________________________ > > >>>>> amd-gfx mailing list > > >>>>> amd-gfx@lists.freedesktop.org > > >>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C01%= 7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe= 4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5HKCsT= rksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 > > >>>> _______________________________________________ > > >>>> dri-devel mailing list > > >>>> dri-devel@lists.freedesktop.org > > >>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C01= %7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961f= e4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHdHOA%2F1= VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 > > >>>> > > >>> _______________________________________________ > > >>> amd-gfx mailing list > > >>> amd-gfx@lists.freedesktop.org > > >>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C01%7C= christian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe48= 84e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5HKCsTrk= sRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 > > > = > = > -- = > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- = Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05D59C47426 for ; Fri, 2 Oct 2020 09:58:44 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 65776206DD for ; Fri, 2 Oct 2020 09:58:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="Kv9fFmws" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 65776206DD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=virtualization-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id B0BCA204D6; Fri, 2 Oct 2020 09:58:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ANnvlR3BGWW; Fri, 2 Oct 2020 09:58:40 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by silver.osuosl.org (Postfix) with ESMTP id 3D8BC20346; Fri, 2 Oct 2020 09:58:40 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1EC86C0889; Fri, 2 Oct 2020 09:58:40 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4E736C0051 for ; Fri, 2 Oct 2020 09:58:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 142B620346 for ; Fri, 2 Oct 2020 09:58:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxYgBNm09nVr for ; Fri, 2 Oct 2020 09:58:37 +0000 (UTC) X-Greylist: delayed 00:10:30 by SQLgrey-1.7.6 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by silver.osuosl.org (Postfix) with ESMTPS id 87B29203A7 for ; Fri, 2 Oct 2020 09:58:36 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id c18so1104597wrm.9 for ; Fri, 02 Oct 2020 02:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=Kv9fFmwsLnH3rxc4YORHIlCmE7gMf2ANx+U1VpZfjN8Kq3n/95x+iLFFYY69i5o/VM aXKz1OGxaPgu4YEY2NOXjk9cQA0FvF45c+2KvuEJGmF6wRE5OG+7rgoxKuBnH3Yb2xng VP9WbgOJz1wPpF8BMrgVCxTdasm5/jVPq77KY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=KqHjuLc9TkVKYwtj370DV/ZbJlQYwr1UykQe1cVemzZZoUBeY96sCzY6exD9d9gVBH 6wDcMsvzHw4blm1XzQ/6lmUcbY8CH215HNp9L1bRZzseoS7UlcKs37foI9M27NWu6UWF fqqBbtprTAdGj+4TEkL85zYblBFo7WRiJp01WMvfs2c71xr8gARfUbxsLiB4ZAcCn0gu 3ydflUELbNPB+z1ssfdykPFWFyYa7IihhvVxYIUxAO4EXuqMl43BY1bQjmQaGvzcxZto 0TpFcsNn9Z9IHumiw7RTIts2c9a5UsSi7pxZU2ZaDn6YHe5UCndAfGLE+XhsXDyr6Nu1 7aGg== X-Gm-Message-State: AOAM531zXmYIhRHroFtC3cLmU8eBnjs9dC0bFRdhcaTLrPgfSa5oS+dw aSNSVndvB/uBGluH/0V0WWQVrA== X-Google-Smtp-Source: ABdhPJyaxWM6azv8IiEEW0NJpIjAdBSSpixIyMrO0zJEmyGJ5I3RnUPpVbxcJ/Exwy9Zm9yRUkU4Bg== X-Received: by 2002:a5d:5751:: with SMTP id q17mr2092527wrw.409.1601632714647; Fri, 02 Oct 2020 02:58:34 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q18sm1109551wre.78.2020.10.02.02.58.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 02:58:33 -0700 (PDT) Date: Fri, 2 Oct 2020 11:58:30 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion Message-ID: <20201002095830.GH438822@phenom.ffwll.local> References: <20200929151437.19717-1-tzimmermann@suse.de> <20200929151437.19717-3-tzimmermann@suse.de> <8fad0114-064a-4ed5-c21d-d1b4294de0a1@amd.com> <2614314a-81f7-4722-c400-68d90e48e09a@suse.de> <8a84f62b-33f3-f44c-52af-c859a0e0d1fb@gmail.com> <07972ada-9135-3743-a86b-487f610c509f@suse.de> <20200930094712.GW438822@phenom.ffwll.local> <8479d0aa-3826-4f37-0109-55daca515793@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 Cc: Luben Tuikov , Heiko =?iso-8859-1?Q?St=FCbner?= , Dave Airlie , Nouveau Dev , Linus Walleij , dri-devel , "Wilson, Chris" , Melissa Wen , "Anholt, Eric" , Huang Rui , Sam Ravnborg , Sumit Semwal , Emil Velikov , Rob Herring , linux-samsung-soc , Joonyoung Shim , lima@lists.freedesktop.org, Oleksandr Andrushchenko , Krzysztof Kozlowski , Steven Price , "open list:ARM/Rockchip SoC..." , Kukjin Kim , Alyssa Rosenzweig , Russell King , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" , Ben Skeggs , Maarten Lankhorst , The etnaviv authors , Maxime Ripard , Inki Dae , Hans de Goede , Christian Gmeiner , "moderated list:DRM DRIVERS FOR XEN" , "open list:VIRTIO CORE, NET..." , Sean Paul , apaneers@amd.com, Linux ARM , "moderated list:DMA BUFFER SHARING FRAMEWORK" , amd-gfx list , Tomeu Vizoso , Seung-Woo Kim , Sandy Huang , Kyungmin Park , Qinglang Miao , Qiang Yu , Thomas Zimmermann , Alex Deucher , "open list:DMA BUFFER SHARING FRAMEWORK" , Lucas Stach X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > On Wed, Sep 30, 2020 at 2:34 PM Christian K=F6nig > wrote: > > > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian K=F6nig wrote: > > >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: > > >>> Hi > > >>> > > >>> Am 30.09.20 um 10:05 schrieb Christian K=F6nig: > > >>>> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: > > >>>>> Hi Christian > > >>>>> > > >>>>> Am 29.09.20 um 17:35 schrieb Christian K=F6nig: > > >>>>>> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: > > >>>>>>> The new helper ttm_kmap_obj_to_dma_buf() extracts address and l= ocation > > >>>>>>> from and instance of TTM's kmap_obj and initializes struct dma_= buf_map > > >>>>>>> with these values. Helpful for TTM-based drivers. > > >>>>>> We could completely drop that if we use the same structure insid= e TTM as > > >>>>>> well. > > >>>>>> > > >>>>>> Additional to that which driver is going to use this? > > >>>>> As Daniel mentioned, it's in patch 3. The TTM-based drivers will > > >>>>> retrieve the pointer via this function. > > >>>>> > > >>>>> I do want to see all that being more tightly integrated into TTM,= but > > >>>>> not in this series. This one is about fixing the bochs-on-sparc64 > > >>>>> problem for good. Patch 7 adds an update to TTM to the DRM TODO l= ist. > > >>>> I should have asked which driver you try to fix here :) > > >>>> > > >>>> In this case just keep the function inside bochs and only fix it t= here. > > >>>> > > >>>> All other drivers can be fixed when we generally pump this through= TTM. > > >>> Did you take a look at patch 3? This function will be used by VRAM > > >>> helpers, nouveau, radeon, amdgpu and qxl. If we don't put it here, = we > > >>> have to duplicate the functionality in each if these drivers. Bochs > > >>> itself uses VRAM helpers and doesn't touch the function directly. > > >> Ah, ok can we have that then only in the VRAM helpers? > > >> > > >> Alternative you could go ahead and use dma_buf_map in ttm_bo_kmap_obj > > >> directly and drop the hack with the TTM_BO_MAP_IOMEM_MASK. > > >> > > >> What I want to avoid is to have another conversion function in TTM b= ecause > > >> what happens here is that we already convert from ttm_bus_placement = to > > >> ttm_bo_kmap_obj and then to dma_buf_map. > > > Hm I'm not really seeing how that helps with a gradual conversion of > > > everything over to dma_buf_map and assorted helpers for access? There= 's > > > too many places in ttm drivers where is_iomem and related stuff is us= ed to > > > be able to convert it all in one go. An intermediate state with a bun= ch of > > > conversions seems fairly unavoidable to me. > > > > Fair enough. I would just have started bottom up and not top down. > > > > Anyway feel free to go ahead with this approach as long as we can remove > > the new function again when we clean that stuff up for good. > = > Yeah I guess bottom up would make more sense as a refactoring. But the > main motivation to land this here is to fix the __mmio vs normal > memory confusion in the fbdev emulation helpers for sparc (and > anything else that needs this). Hence the top down approach for > rolling this out. Ok I started reviewing this a bit more in-depth, and I think this is a bit too much of a de-tour. Looking through all the callers of ttm_bo_kmap almost everyone maps the entire object. Only vmwgfx uses to map less than that. Also, everyone just immediately follows up with converting that full object map into a pointer. So I think what we really want here is: - new function int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); _vmap name since that's consistent with both dma_buf functions and what's usually used to implement this. Outside of the ttm world kmap usually just means single-page mappings using kmap() or it's iomem sibling io_mapping_map* so rather confusing name for a function which usually is just used to set up a vmap of the entire buffer. - a helper which can be used for the drm_gem_object_funcs vmap/vunmap functions for all ttm drivers. We should be able to make this fully generic because a) we now have dma_buf_map and b) drm_gem_object is embedded in the ttm_bo, so we can upcast for everyone who's both a ttm and gem driver. This is maybe a good follow-up, since it should allow us to ditch quite a bit of the vram helper code for this more generic stuff. I also might have missed some special-cases here, but from a quick look everything just pins the buffer to the current location and that's it. Also this obviously requires Christian's generic ttm_bo_pin rework first. - roll the above out to drivers. Christian/Thomas, thoughts on this? I think for the immediate need of rolling this out for vram helpers and fbdev code we should be able to do this, but just postpone the driver wide roll-out for now. Cheers, Daniel > -Daniel > = > > > > Christian. > > > > > -Daniel > > > > > >> Thanks, > > >> Christian. > > >> > > >>> Best regards > > >>> Thomas > > >>> > > >>>> Regards, > > >>>> Christian. > > >>>> > > >>>>> Best regards > > >>>>> Thomas > > >>>>> > > >>>>>> Regards, > > >>>>>> Christian. > > >>>>>> > > >>>>>>> Signed-off-by: Thomas Zimmermann > > >>>>>>> --- > > >>>>>>> include/drm/ttm/ttm_bo_api.h | 24 ++++++++++++++++++++++++ > > >>>>>>> include/linux/dma-buf-map.h | 20 ++++++++++++++++++++ > > >>>>>>> 2 files changed, 44 insertions(+) > > >>>>>>> > > >>>>>>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm= _bo_api.h > > >>>>>>> index c96a25d571c8..62d89f05a801 100644 > > >>>>>>> --- a/include/drm/ttm/ttm_bo_api.h > > >>>>>>> +++ b/include/drm/ttm/ttm_bo_api.h > > >>>>>>> @@ -34,6 +34,7 @@ > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> +#include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> @@ -486,6 +487,29 @@ static inline void *ttm_kmap_obj_virtual(s= truct > > >>>>>>> ttm_bo_kmap_obj *map, > > >>>>>>> return map->virtual; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * ttm_kmap_obj_to_dma_buf_map > > >>>>>>> + * > > >>>>>>> + * @kmap: A struct ttm_bo_kmap_obj returned from ttm_bo_kmap. > > >>>>>>> + * @map: Returns the mapping as struct dma_buf_map > > >>>>>>> + * > > >>>>>>> + * Converts struct ttm_bo_kmap_obj to struct dma_buf_map. If t= he memory > > >>>>>>> + * is not mapped, the returned mapping is initialized to NULL. > > >>>>>>> + */ > > >>>>>>> +static inline void ttm_kmap_obj_to_dma_buf_map(struct ttm_bo_k= map_obj > > >>>>>>> *kmap, > > >>>>>>> + struct dma_buf_map *map) > > >>>>>>> +{ > > >>>>>>> + bool is_iomem; > > >>>>>>> + void *vaddr =3D ttm_kmap_obj_virtual(kmap, &is_iomem); > > >>>>>>> + > > >>>>>>> + if (!vaddr) > > >>>>>>> + dma_buf_map_clear(map); > > >>>>>>> + else if (is_iomem) > > >>>>>>> + dma_buf_map_set_vaddr_iomem(map, (void __force __iomem= *)vaddr); > > >>>>>>> + else > > >>>>>>> + dma_buf_map_set_vaddr(map, vaddr); > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * ttm_bo_kmap > > >>>>>>> * > > >>>>>>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-bu= f-map.h > > >>>>>>> index fd1aba545fdf..2e8bbecb5091 100644 > > >>>>>>> --- a/include/linux/dma-buf-map.h > > >>>>>>> +++ b/include/linux/dma-buf-map.h > > >>>>>>> @@ -45,6 +45,12 @@ > > >>>>>>> * > > >>>>>>> * dma_buf_map_set_vaddr(&map. 0xdeadbeaf); > > >>>>>>> * > > >>>>>>> + * To set an address in I/O memory, use dma_buf_map_set_vaddr_= iomem(). > > >>>>>>> + * > > >>>>>>> + * .. code-block:: c > > >>>>>>> + * > > >>>>>>> + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf); > > >>>>>>> + * > > >>>>>>> * Test if a mapping is valid with either dma_buf_map_is_se= t() or > > >>>>>>> * dma_buf_map_is_null(). > > >>>>>>> * > > >>>>>>> @@ -118,6 +124,20 @@ static inline void dma_buf_map_set_vaddr(s= truct > > >>>>>>> dma_buf_map *map, void *vaddr) > > >>>>>>> map->is_iomem =3D false; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping struct= ure to > > >>>>>>> an address in I/O memory > > >>>>>>> + * @map: The dma-buf mapping structure > > >>>>>>> + * @vaddr_iomem: An I/O-memory address > > >>>>>>> + * > > >>>>>>> + * Sets the address and the I/O-memory flag. > > >>>>>>> + */ > > >>>>>>> +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_= map *map, > > >>>>>>> + void __iomem *vaddr_iomem) > > >>>>>>> +{ > > >>>>>>> + map->vaddr_iomem =3D vaddr_iomem; > > >>>>>>> + map->is_iomem =3D true; > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * dma_buf_map_is_equal - Compares two dma-buf mapping stru= ctures > > >>>>>>> for equality > > >>>>>>> * @lhs: The dma-buf mapping structure > > >>>>>> _______________________________________________ > > >>>>>> dri-devel mailing list > > >>>>>> dri-devel@lists.freedesktop.org > > >>>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C= 01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd896= 1fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHdHOA%2= F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 > > >>>>> _______________________________________________ > > >>>>> amd-gfx mailing list > > >>>>> amd-gfx@lists.freedesktop.org > > >>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C01%= 7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe= 4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5HKCsT= rksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 > > >>>> _______________________________________________ > > >>>> dri-devel mailing list > > >>>> dri-devel@lists.freedesktop.org > > >>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C01= %7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961f= e4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHdHOA%2F1= VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 > > >>>> > > >>> _______________________________________________ > > >>> amd-gfx mailing list > > >>> amd-gfx@lists.freedesktop.org > > >>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C01%7C= christian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe48= 84e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5HKCsTrk= sRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 > > > = > = > -- = > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- = Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CFB55C47425 for ; Fri, 2 Oct 2020 09:58:40 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 85FA7206DD for ; Fri, 2 Oct 2020 09:58:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="Kv9fFmws" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 85FA7206DD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2F8CB6E91E; Fri, 2 Oct 2020 09:58:37 +0000 (UTC) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2116B6E05F for ; Fri, 2 Oct 2020 09:58:36 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id c18so1104595wrm.9 for ; Fri, 02 Oct 2020 02:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=Kv9fFmwsLnH3rxc4YORHIlCmE7gMf2ANx+U1VpZfjN8Kq3n/95x+iLFFYY69i5o/VM aXKz1OGxaPgu4YEY2NOXjk9cQA0FvF45c+2KvuEJGmF6wRE5OG+7rgoxKuBnH3Yb2xng VP9WbgOJz1wPpF8BMrgVCxTdasm5/jVPq77KY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=FtJmi8b+YgVNKW+LK9sLG6uogV5GuLxj6ZSUx3LCBC9cqSnGQ2ZJClZJYjQwkmgT5h NrhmO/8XDxKrHduWTHp5BXQdYvJlD+wiz4l2O4wrzPFB4QCg4ThJgNmOJzufqnag2gVs Uk7giLNWE7MkFU2urtjdh771Mftpqm1x1Eky5WEirWRB93ZWn83SjiW67b5Q/fwbt9nt bzzcAe0PwbJpr7WOcx6OkowxevAl93Cf1Q1jF9t9/BR0Ky68fJUJQWRlJKB6B5TfPY/F RXq/javOvJPPR3i8/DZhW6mTyfBRK2pEle0gR+il6Zz+RwSi4CdeuIwPGooiMD6psswf 5Q8w== X-Gm-Message-State: AOAM531GHGXVvvwZJg5n3AfhS2UF/Lhm+3Vz7R/bQhnRm6rxvv+kUcnd H3EBO4Tf1xS+SyrS7n9dnJZ1TA== X-Google-Smtp-Source: ABdhPJyaxWM6azv8IiEEW0NJpIjAdBSSpixIyMrO0zJEmyGJ5I3RnUPpVbxcJ/Exwy9Zm9yRUkU4Bg== X-Received: by 2002:a5d:5751:: with SMTP id q17mr2092527wrw.409.1601632714647; Fri, 02 Oct 2020 02:58:34 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q18sm1109551wre.78.2020.10.02.02.58.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 02:58:33 -0700 (PDT) Date: Fri, 2 Oct 2020 11:58:30 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion Message-ID: <20201002095830.GH438822@phenom.ffwll.local> References: <20200929151437.19717-1-tzimmermann@suse.de> <20200929151437.19717-3-tzimmermann@suse.de> <8fad0114-064a-4ed5-c21d-d1b4294de0a1@amd.com> <2614314a-81f7-4722-c400-68d90e48e09a@suse.de> <8a84f62b-33f3-f44c-52af-c859a0e0d1fb@gmail.com> <07972ada-9135-3743-a86b-487f610c509f@suse.de> <20200930094712.GW438822@phenom.ffwll.local> <8479d0aa-3826-4f37-0109-55daca515793@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Luben Tuikov , Dave Airlie , Nouveau Dev , dri-devel , "Wilson, Chris" , Melissa Wen , Huang Rui , Gerd Hoffmann , Sam Ravnborg , Emil Velikov , linux-samsung-soc , Joonyoung Shim , lima@lists.freedesktop.org, Oleksandr Andrushchenko , Krzysztof Kozlowski , Steven Price , "open list:ARM/Rockchip SoC..." , Kukjin Kim , Alyssa Rosenzweig , Russell King , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" , Ben Skeggs , The etnaviv authors , Hans de Goede , "moderated list:DRM DRIVERS FOR XEN" , "open list:VIRTIO CORE, NET..." , Sean Paul , apaneers@amd.com, Linux ARM , "moderated list:DMA BUFFER SHARING FRAMEWORK" , amd-gfx list , Tomeu Vizoso , Seung-Woo Kim , Sandy Huang , Kyungmin Park , Qinglang Miao , Qiang Yu , Thomas Zimmermann , Alex Deucher , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > On Wed, Sep 30, 2020 at 2:34 PM Christian K=F6nig > wrote: > > > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian K=F6nig wrote: > > >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: > > >>> Hi > > >>> > > >>> Am 30.09.20 um 10:05 schrieb Christian K=F6nig: > > >>>> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: > > >>>>> Hi Christian > > >>>>> > > >>>>> Am 29.09.20 um 17:35 schrieb Christian K=F6nig: > > >>>>>> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: > > >>>>>>> The new helper ttm_kmap_obj_to_dma_buf() extracts address and l= ocation > > >>>>>>> from and instance of TTM's kmap_obj and initializes struct dma_= buf_map > > >>>>>>> with these values. Helpful for TTM-based drivers. > > >>>>>> We could completely drop that if we use the same structure insid= e TTM as > > >>>>>> well. > > >>>>>> > > >>>>>> Additional to that which driver is going to use this? > > >>>>> As Daniel mentioned, it's in patch 3. The TTM-based drivers will > > >>>>> retrieve the pointer via this function. > > >>>>> > > >>>>> I do want to see all that being more tightly integrated into TTM,= but > > >>>>> not in this series. This one is about fixing the bochs-on-sparc64 > > >>>>> problem for good. Patch 7 adds an update to TTM to the DRM TODO l= ist. > > >>>> I should have asked which driver you try to fix here :) > > >>>> > > >>>> In this case just keep the function inside bochs and only fix it t= here. > > >>>> > > >>>> All other drivers can be fixed when we generally pump this through= TTM. > > >>> Did you take a look at patch 3? This function will be used by VRAM > > >>> helpers, nouveau, radeon, amdgpu and qxl. If we don't put it here, = we > > >>> have to duplicate the functionality in each if these drivers. Bochs > > >>> itself uses VRAM helpers and doesn't touch the function directly. > > >> Ah, ok can we have that then only in the VRAM helpers? > > >> > > >> Alternative you could go ahead and use dma_buf_map in ttm_bo_kmap_obj > > >> directly and drop the hack with the TTM_BO_MAP_IOMEM_MASK. > > >> > > >> What I want to avoid is to have another conversion function in TTM b= ecause > > >> what happens here is that we already convert from ttm_bus_placement = to > > >> ttm_bo_kmap_obj and then to dma_buf_map. > > > Hm I'm not really seeing how that helps with a gradual conversion of > > > everything over to dma_buf_map and assorted helpers for access? There= 's > > > too many places in ttm drivers where is_iomem and related stuff is us= ed to > > > be able to convert it all in one go. An intermediate state with a bun= ch of > > > conversions seems fairly unavoidable to me. > > > > Fair enough. I would just have started bottom up and not top down. > > > > Anyway feel free to go ahead with this approach as long as we can remove > > the new function again when we clean that stuff up for good. > = > Yeah I guess bottom up would make more sense as a refactoring. But the > main motivation to land this here is to fix the __mmio vs normal > memory confusion in the fbdev emulation helpers for sparc (and > anything else that needs this). Hence the top down approach for > rolling this out. Ok I started reviewing this a bit more in-depth, and I think this is a bit too much of a de-tour. Looking through all the callers of ttm_bo_kmap almost everyone maps the entire object. Only vmwgfx uses to map less than that. Also, everyone just immediately follows up with converting that full object map into a pointer. So I think what we really want here is: - new function int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); _vmap name since that's consistent with both dma_buf functions and what's usually used to implement this. Outside of the ttm world kmap usually just means single-page mappings using kmap() or it's iomem sibling io_mapping_map* so rather confusing name for a function which usually is just used to set up a vmap of the entire buffer. - a helper which can be used for the drm_gem_object_funcs vmap/vunmap functions for all ttm drivers. We should be able to make this fully generic because a) we now have dma_buf_map and b) drm_gem_object is embedded in the ttm_bo, so we can upcast for everyone who's both a ttm and gem driver. This is maybe a good follow-up, since it should allow us to ditch quite a bit of the vram helper code for this more generic stuff. I also might have missed some special-cases here, but from a quick look everything just pins the buffer to the current location and that's it. Also this obviously requires Christian's generic ttm_bo_pin rework first. - roll the above out to drivers. Christian/Thomas, thoughts on this? I think for the immediate need of rolling this out for vram helpers and fbdev code we should be able to do this, but just postpone the driver wide roll-out for now. Cheers, Daniel > -Daniel > = > > > > Christian. > > > > > -Daniel > > > > > >> Thanks, > > >> Christian. > > >> > > >>> Best regards > > >>> Thomas > > >>> > > >>>> Regards, > > >>>> Christian. > > >>>> > > >>>>> Best regards > > >>>>> Thomas > > >>>>> > > >>>>>> Regards, > > >>>>>> Christian. > > >>>>>> > > >>>>>>> Signed-off-by: Thomas Zimmermann > > >>>>>>> --- > > >>>>>>> include/drm/ttm/ttm_bo_api.h | 24 ++++++++++++++++++++++++ > > >>>>>>> include/linux/dma-buf-map.h | 20 ++++++++++++++++++++ > > >>>>>>> 2 files changed, 44 insertions(+) > > >>>>>>> > > >>>>>>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm= _bo_api.h > > >>>>>>> index c96a25d571c8..62d89f05a801 100644 > > >>>>>>> --- a/include/drm/ttm/ttm_bo_api.h > > >>>>>>> +++ b/include/drm/ttm/ttm_bo_api.h > > >>>>>>> @@ -34,6 +34,7 @@ > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> +#include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> @@ -486,6 +487,29 @@ static inline void *ttm_kmap_obj_virtual(s= truct > > >>>>>>> ttm_bo_kmap_obj *map, > > >>>>>>> return map->virtual; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * ttm_kmap_obj_to_dma_buf_map > > >>>>>>> + * > > >>>>>>> + * @kmap: A struct ttm_bo_kmap_obj returned from ttm_bo_kmap. > > >>>>>>> + * @map: Returns the mapping as struct dma_buf_map > > >>>>>>> + * > > >>>>>>> + * Converts struct ttm_bo_kmap_obj to struct dma_buf_map. If t= he memory > > >>>>>>> + * is not mapped, the returned mapping is initialized to NULL. > > >>>>>>> + */ > > >>>>>>> +static inline void ttm_kmap_obj_to_dma_buf_map(struct ttm_bo_k= map_obj > > >>>>>>> *kmap, > > >>>>>>> + struct dma_buf_map *map) > > >>>>>>> +{ > > >>>>>>> + bool is_iomem; > > >>>>>>> + void *vaddr =3D ttm_kmap_obj_virtual(kmap, &is_iomem); > > >>>>>>> + > > >>>>>>> + if (!vaddr) > > >>>>>>> + dma_buf_map_clear(map); > > >>>>>>> + else if (is_iomem) > > >>>>>>> + dma_buf_map_set_vaddr_iomem(map, (void __force __iomem= *)vaddr); > > >>>>>>> + else > > >>>>>>> + dma_buf_map_set_vaddr(map, vaddr); > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * ttm_bo_kmap > > >>>>>>> * > > >>>>>>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-bu= f-map.h > > >>>>>>> index fd1aba545fdf..2e8bbecb5091 100644 > > >>>>>>> --- a/include/linux/dma-buf-map.h > > >>>>>>> +++ b/include/linux/dma-buf-map.h > > >>>>>>> @@ -45,6 +45,12 @@ > > >>>>>>> * > > >>>>>>> * dma_buf_map_set_vaddr(&map. 0xdeadbeaf); > > >>>>>>> * > > >>>>>>> + * To set an address in I/O memory, use dma_buf_map_set_vaddr_= iomem(). > > >>>>>>> + * > > >>>>>>> + * .. code-block:: c > > >>>>>>> + * > > >>>>>>> + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf); > > >>>>>>> + * > > >>>>>>> * Test if a mapping is valid with either dma_buf_map_is_se= t() or > > >>>>>>> * dma_buf_map_is_null(). > > >>>>>>> * > > >>>>>>> @@ -118,6 +124,20 @@ static inline void dma_buf_map_set_vaddr(s= truct > > >>>>>>> dma_buf_map *map, void *vaddr) > > >>>>>>> map->is_iomem =3D false; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping struct= ure to > > >>>>>>> an address in I/O memory > > >>>>>>> + * @map: The dma-buf mapping structure > > >>>>>>> + * @vaddr_iomem: An I/O-memory address > > >>>>>>> + * > > >>>>>>> + * Sets the address and the I/O-memory flag. > > >>>>>>> + */ > > >>>>>>> +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_= map *map, > > >>>>>>> + void __iomem *vaddr_iomem) > > >>>>>>> +{ > > >>>>>>> + map->vaddr_iomem =3D vaddr_iomem; > > >>>>>>> + map->is_iomem =3D true; > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * dma_buf_map_is_equal - Compares two dma-buf mapping stru= ctures > > >>>>>>> for equality > > >>>>>>> * @lhs: The dma-buf mapping structure > > >>>>>> _______________________________________________ > > >>>>>> dri-devel mailing list > > >>>>>> dri-devel@lists.freedesktop.org > > >>>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C= 01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd896= 1fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHdHOA%2= F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 > > >>>>> _______________________________________________ > > >>>>> amd-gfx mailing list > > >>>>> amd-gfx@lists.freedesktop.org > > >>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C01%= 7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe= 4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5HKCsT= rksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 > > >>>> _______________________________________________ > > >>>> dri-devel mailing list > > >>>> dri-devel@lists.freedesktop.org > > >>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C01= %7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961f= e4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHdHOA%2F1= VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 > > >>>> > > >>> _______________________________________________ > > >>> amd-gfx mailing list > > >>> amd-gfx@lists.freedesktop.org > > >>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C01%7C= christian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe48= 84e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5HKCsTrk= sRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 > > > = > = > -- = > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- = Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CD1CC4363D for ; Fri, 2 Oct 2020 09:58:39 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8373D206E3 for ; Fri, 2 Oct 2020 09:58:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="Kv9fFmws" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8373D206E3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5D4B16E919; Fri, 2 Oct 2020 09:58:37 +0000 (UTC) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by gabe.freedesktop.org (Postfix) with ESMTPS id 304EB6E0AD for ; Fri, 2 Oct 2020 09:58:36 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id k10so1109903wru.6 for ; Fri, 02 Oct 2020 02:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=Kv9fFmwsLnH3rxc4YORHIlCmE7gMf2ANx+U1VpZfjN8Kq3n/95x+iLFFYY69i5o/VM aXKz1OGxaPgu4YEY2NOXjk9cQA0FvF45c+2KvuEJGmF6wRE5OG+7rgoxKuBnH3Yb2xng VP9WbgOJz1wPpF8BMrgVCxTdasm5/jVPq77KY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=mEkpAjpBBFBC2OSbPf1rcPxheU+j8eHJKLr+XyTj9VA=; b=GFEnRRKRcZA0MLxm1GTlPj5Ysp0ygF8ic6G8Fw9JEFDIHOghg0WrzfTVDunjAn6k4o d4MWpC7RoPLtZSRSkCjUSPbtivIHH553F6NyiiRQjYd+rtXmKFdqqSJkDCBS/9kaw2gM vj7Romy05MU+F2013ZXtKuHSvtoTYAwCwrisxvU4U5/JGuYcXBNuwdWXPDQvtLymrHJm wkcaB7DGYFuNOka1liQHq/lKurKIySlEZ6Dh4+xTcwok4juyzMEqrQrK5+wSNIYUtq5A 0qHOxzRyb5UmZsetxP7q/VM4HroDhOrinlHvk/Yt6VakTRlQ5XBaFUEkJP3mPmwwCST/ Lu0g== X-Gm-Message-State: AOAM533DXBfBHLFE0Dvd0Oj2L0Vfhd0Y4S8Lr849v7ZNYLdQNk/ozBjG Q/R03lnFCWSWuM++iCTyApbwkQ== X-Google-Smtp-Source: ABdhPJyaxWM6azv8IiEEW0NJpIjAdBSSpixIyMrO0zJEmyGJ5I3RnUPpVbxcJ/Exwy9Zm9yRUkU4Bg== X-Received: by 2002:a5d:5751:: with SMTP id q17mr2092527wrw.409.1601632714647; Fri, 02 Oct 2020 02:58:34 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q18sm1109551wre.78.2020.10.02.02.58.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 02:58:33 -0700 (PDT) Date: Fri, 2 Oct 2020 11:58:30 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion Message-ID: <20201002095830.GH438822@phenom.ffwll.local> References: <20200929151437.19717-1-tzimmermann@suse.de> <20200929151437.19717-3-tzimmermann@suse.de> <8fad0114-064a-4ed5-c21d-d1b4294de0a1@amd.com> <2614314a-81f7-4722-c400-68d90e48e09a@suse.de> <8a84f62b-33f3-f44c-52af-c859a0e0d1fb@gmail.com> <07972ada-9135-3743-a86b-487f610c509f@suse.de> <20200930094712.GW438822@phenom.ffwll.local> <8479d0aa-3826-4f37-0109-55daca515793@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Luben Tuikov , Heiko =?iso-8859-1?Q?St=FCbner?= , Dave Airlie , Nouveau Dev , Linus Walleij , dri-devel , "Wilson, Chris" , Melissa Wen , "Anholt, Eric" , Huang Rui , Gerd Hoffmann , Sam Ravnborg , Sumit Semwal , Emil Velikov , Rob Herring , linux-samsung-soc , Joonyoung Shim , lima@lists.freedesktop.org, Oleksandr Andrushchenko , Krzysztof Kozlowski , Steven Price , "open list:ARM/Rockchip SoC..." , Kukjin Kim , Alyssa Rosenzweig , Russell King , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" , Ben Skeggs , Maarten Lankhorst , The etnaviv authors , Maxime Ripard , Inki Dae , Hans de Goede , Christian Gmeiner , "moderated list:DRM DRIVERS FOR XEN" , "open list:VIRTIO CORE, NET..." , Sean Paul , apaneers@amd.com, Linux ARM , "moderated list:DMA BUFFER SHARING FRAMEWORK" , amd-gfx list , Tomeu Vizoso , Seung-Woo Kim , Sandy Huang , Kyungmin Park , Qinglang Miao , Qiang Yu , Thomas Zimmermann , Alex Deucher , "open list:DMA BUFFER SHARING FRAMEWORK" , Lucas Stach Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > On Wed, Sep 30, 2020 at 2:34 PM Christian K=F6nig > wrote: > > > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian K=F6nig wrote: > > >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: > > >>> Hi > > >>> > > >>> Am 30.09.20 um 10:05 schrieb Christian K=F6nig: > > >>>> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: > > >>>>> Hi Christian > > >>>>> > > >>>>> Am 29.09.20 um 17:35 schrieb Christian K=F6nig: > > >>>>>> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann: > > >>>>>>> The new helper ttm_kmap_obj_to_dma_buf() extracts address and l= ocation > > >>>>>>> from and instance of TTM's kmap_obj and initializes struct dma_= buf_map > > >>>>>>> with these values. Helpful for TTM-based drivers. > > >>>>>> We could completely drop that if we use the same structure insid= e TTM as > > >>>>>> well. > > >>>>>> > > >>>>>> Additional to that which driver is going to use this? > > >>>>> As Daniel mentioned, it's in patch 3. The TTM-based drivers will > > >>>>> retrieve the pointer via this function. > > >>>>> > > >>>>> I do want to see all that being more tightly integrated into TTM,= but > > >>>>> not in this series. This one is about fixing the bochs-on-sparc64 > > >>>>> problem for good. Patch 7 adds an update to TTM to the DRM TODO l= ist. > > >>>> I should have asked which driver you try to fix here :) > > >>>> > > >>>> In this case just keep the function inside bochs and only fix it t= here. > > >>>> > > >>>> All other drivers can be fixed when we generally pump this through= TTM. > > >>> Did you take a look at patch 3? This function will be used by VRAM > > >>> helpers, nouveau, radeon, amdgpu and qxl. If we don't put it here, = we > > >>> have to duplicate the functionality in each if these drivers. Bochs > > >>> itself uses VRAM helpers and doesn't touch the function directly. > > >> Ah, ok can we have that then only in the VRAM helpers? > > >> > > >> Alternative you could go ahead and use dma_buf_map in ttm_bo_kmap_obj > > >> directly and drop the hack with the TTM_BO_MAP_IOMEM_MASK. > > >> > > >> What I want to avoid is to have another conversion function in TTM b= ecause > > >> what happens here is that we already convert from ttm_bus_placement = to > > >> ttm_bo_kmap_obj and then to dma_buf_map. > > > Hm I'm not really seeing how that helps with a gradual conversion of > > > everything over to dma_buf_map and assorted helpers for access? There= 's > > > too many places in ttm drivers where is_iomem and related stuff is us= ed to > > > be able to convert it all in one go. An intermediate state with a bun= ch of > > > conversions seems fairly unavoidable to me. > > > > Fair enough. I would just have started bottom up and not top down. > > > > Anyway feel free to go ahead with this approach as long as we can remove > > the new function again when we clean that stuff up for good. > = > Yeah I guess bottom up would make more sense as a refactoring. But the > main motivation to land this here is to fix the __mmio vs normal > memory confusion in the fbdev emulation helpers for sparc (and > anything else that needs this). Hence the top down approach for > rolling this out. Ok I started reviewing this a bit more in-depth, and I think this is a bit too much of a de-tour. Looking through all the callers of ttm_bo_kmap almost everyone maps the entire object. Only vmwgfx uses to map less than that. Also, everyone just immediately follows up with converting that full object map into a pointer. So I think what we really want here is: - new function int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); _vmap name since that's consistent with both dma_buf functions and what's usually used to implement this. Outside of the ttm world kmap usually just means single-page mappings using kmap() or it's iomem sibling io_mapping_map* so rather confusing name for a function which usually is just used to set up a vmap of the entire buffer. - a helper which can be used for the drm_gem_object_funcs vmap/vunmap functions for all ttm drivers. We should be able to make this fully generic because a) we now have dma_buf_map and b) drm_gem_object is embedded in the ttm_bo, so we can upcast for everyone who's both a ttm and gem driver. This is maybe a good follow-up, since it should allow us to ditch quite a bit of the vram helper code for this more generic stuff. I also might have missed some special-cases here, but from a quick look everything just pins the buffer to the current location and that's it. Also this obviously requires Christian's generic ttm_bo_pin rework first. - roll the above out to drivers. Christian/Thomas, thoughts on this? I think for the immediate need of rolling this out for vram helpers and fbdev code we should be able to do this, but just postpone the driver wide roll-out for now. Cheers, Daniel > -Daniel > = > > > > Christian. > > > > > -Daniel > > > > > >> Thanks, > > >> Christian. > > >> > > >>> Best regards > > >>> Thomas > > >>> > > >>>> Regards, > > >>>> Christian. > > >>>> > > >>>>> Best regards > > >>>>> Thomas > > >>>>> > > >>>>>> Regards, > > >>>>>> Christian. > > >>>>>> > > >>>>>>> Signed-off-by: Thomas Zimmermann > > >>>>>>> --- > > >>>>>>> include/drm/ttm/ttm_bo_api.h | 24 ++++++++++++++++++++++++ > > >>>>>>> include/linux/dma-buf-map.h | 20 ++++++++++++++++++++ > > >>>>>>> 2 files changed, 44 insertions(+) > > >>>>>>> > > >>>>>>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm= _bo_api.h > > >>>>>>> index c96a25d571c8..62d89f05a801 100644 > > >>>>>>> --- a/include/drm/ttm/ttm_bo_api.h > > >>>>>>> +++ b/include/drm/ttm/ttm_bo_api.h > > >>>>>>> @@ -34,6 +34,7 @@ > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> +#include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> #include > > >>>>>>> @@ -486,6 +487,29 @@ static inline void *ttm_kmap_obj_virtual(s= truct > > >>>>>>> ttm_bo_kmap_obj *map, > > >>>>>>> return map->virtual; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * ttm_kmap_obj_to_dma_buf_map > > >>>>>>> + * > > >>>>>>> + * @kmap: A struct ttm_bo_kmap_obj returned from ttm_bo_kmap. > > >>>>>>> + * @map: Returns the mapping as struct dma_buf_map > > >>>>>>> + * > > >>>>>>> + * Converts struct ttm_bo_kmap_obj to struct dma_buf_map. If t= he memory > > >>>>>>> + * is not mapped, the returned mapping is initialized to NULL. > > >>>>>>> + */ > > >>>>>>> +static inline void ttm_kmap_obj_to_dma_buf_map(struct ttm_bo_k= map_obj > > >>>>>>> *kmap, > > >>>>>>> + struct dma_buf_map *map) > > >>>>>>> +{ > > >>>>>>> + bool is_iomem; > > >>>>>>> + void *vaddr =3D ttm_kmap_obj_virtual(kmap, &is_iomem); > > >>>>>>> + > > >>>>>>> + if (!vaddr) > > >>>>>>> + dma_buf_map_clear(map); > > >>>>>>> + else if (is_iomem) > > >>>>>>> + dma_buf_map_set_vaddr_iomem(map, (void __force __iomem= *)vaddr); > > >>>>>>> + else > > >>>>>>> + dma_buf_map_set_vaddr(map, vaddr); > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * ttm_bo_kmap > > >>>>>>> * > > >>>>>>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-bu= f-map.h > > >>>>>>> index fd1aba545fdf..2e8bbecb5091 100644 > > >>>>>>> --- a/include/linux/dma-buf-map.h > > >>>>>>> +++ b/include/linux/dma-buf-map.h > > >>>>>>> @@ -45,6 +45,12 @@ > > >>>>>>> * > > >>>>>>> * dma_buf_map_set_vaddr(&map. 0xdeadbeaf); > > >>>>>>> * > > >>>>>>> + * To set an address in I/O memory, use dma_buf_map_set_vaddr_= iomem(). > > >>>>>>> + * > > >>>>>>> + * .. code-block:: c > > >>>>>>> + * > > >>>>>>> + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf); > > >>>>>>> + * > > >>>>>>> * Test if a mapping is valid with either dma_buf_map_is_se= t() or > > >>>>>>> * dma_buf_map_is_null(). > > >>>>>>> * > > >>>>>>> @@ -118,6 +124,20 @@ static inline void dma_buf_map_set_vaddr(s= truct > > >>>>>>> dma_buf_map *map, void *vaddr) > > >>>>>>> map->is_iomem =3D false; > > >>>>>>> } > > >>>>>>> +/** > > >>>>>>> + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping struct= ure to > > >>>>>>> an address in I/O memory > > >>>>>>> + * @map: The dma-buf mapping structure > > >>>>>>> + * @vaddr_iomem: An I/O-memory address > > >>>>>>> + * > > >>>>>>> + * Sets the address and the I/O-memory flag. > > >>>>>>> + */ > > >>>>>>> +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_= map *map, > > >>>>>>> + void __iomem *vaddr_iomem) > > >>>>>>> +{ > > >>>>>>> + map->vaddr_iomem =3D vaddr_iomem; > > >>>>>>> + map->is_iomem =3D true; > > >>>>>>> +} > > >>>>>>> + > > >>>>>>> /** > > >>>>>>> * dma_buf_map_is_equal - Compares two dma-buf mapping stru= ctures > > >>>>>>> for equality > > >>>>>>> * @lhs: The dma-buf mapping structure > > >>>>>> _______________________________________________ > > >>>>>> dri-devel mailing list > > >>>>>> dri-devel@lists.freedesktop.org > > >>>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C= 01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd896= 1fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHdHOA%2= F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 > > >>>>> _______________________________________________ > > >>>>> amd-gfx mailing list > > >>>>> amd-gfx@lists.freedesktop.org > > >>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C01%= 7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe= 4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5HKCsT= rksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 > > >>>> _______________________________________________ > > >>>> dri-devel mailing list > > >>>> dri-devel@lists.freedesktop.org > > >>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C01= %7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961f= e4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHdHOA%2F1= VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 > > >>>> > > >>> _______________________________________________ > > >>> amd-gfx mailing list > > >>> amd-gfx@lists.freedesktop.org > > >>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C01%7C= christian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8961fe48= 84e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5HKCsTrk= sRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 > > > = > = > -- = > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- = Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx