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=-12.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 1C94FC47095 for ; Wed, 7 Oct 2020 12:57:42 +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 8BB6D2080A for ; Wed, 7 Oct 2020 12:57:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jV4/sDHT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BB6D2080A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de 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-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UxaUFTd2PIW4G8X61zUU6JmCKVGTJHqXInANCkDFy+c=; b=jV4/sDHTALsQkGl3TFmfOD0fq qLHHckbQN6YIORjtcj2eVEb5i+2yGPsvrwWqg4Lh1ArspHhiwXR6+tUJiwmXaNuTfFw+a22OxvQVs 4Axr+4w9LEziU/eq8j9oX7UxBlU8TRPxt4e//3n7BXfyHdOquHUzfs57qqa+RkSjZaMr5/UEhKjAc 0+kY3/yzaZ4DqTyUIkjf0ArB2912X7IQZ0TenwGYyL78BwGS9Q0yeSxhNPt/4OCt8R8KzCqwT3Ypt +X14e1mGs6US04+9LB7Lfvm5ycL/Z53GwovvAN6jJui7lrPxWPaBGF+28/wwU9VhMbbrT4TKRQ720 HlLlLV61w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ90h-0005q1-CN; Wed, 07 Oct 2020 12:57:35 +0000 Received: from mx2.suse.de ([195.135.220.15]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ90d-0005oJ-1U; Wed, 07 Oct 2020 12:57:32 +0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7E8B3B1FA; Wed, 7 Oct 2020 12:57:28 +0000 (UTC) Subject: Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion To: Daniel Vetter , =?UTF-8?Q?Christian_K=c3=b6nig?= 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> <20201002095830.GH438822@phenom.ffwll.local> From: Thomas Zimmermann Message-ID: <5bf40546-8da9-1649-22da-a982f1e8d9c3@suse.de> Date: Wed, 7 Oct 2020 14:57:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201002095830.GH438822@phenom.ffwll.local> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201007_085731_330566_A82BDC74 X-CRM114-Status: GOOD ( 44.82 ) 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 , =?UTF-8?Q?Heiko_St=c3=bcbner?= , 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 , Alex Deucher , "open list:DMA BUFFER SHARING FRAMEWORK" , Lucas Stach Content-Type: multipart/mixed; boundary="===============2833149448897706010==" Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============2833149448897706010== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A04G9t256jlYlZevsaZFScYx8JwBsN4Kq" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A04G9t256jlYlZevsaZFScYx8JwBsN4Kq Content-Type: multipart/mixed; boundary="eO0KkNElTwku9CAInc7DmPRt4uql8oe3b"; protected-headers="v1" From: Thomas Zimmermann To: Daniel Vetter , =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: 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 , =?UTF-8?Q?Heiko_St=c3=bcbner?= , 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" Message-ID: <5bf40546-8da9-1649-22da-a982f1e8d9c3@suse.de> Subject: Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion 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> <20201002095830.GH438822@phenom.ffwll.local> In-Reply-To: <20201002095830.GH438822@phenom.ffwll.local> --eO0KkNElTwku9CAInc7DmPRt4uql8oe3b Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Am 02.10.20 um 11:58 schrieb Daniel Vetter: > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: >> On Wed, Sep 30, 2020 at 2:34 PM Christian K=C3=B6nig >> wrote: >>> >>> Am 30.09.20 um 11:47 schrieb Daniel Vetter: >>>> On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian K=C3=B6nig wrote= : >>>>> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: >>>>>> Hi >>>>>> >>>>>> Am 30.09.20 um 10:05 schrieb Christian K=C3=B6nig: >>>>>>> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann: >>>>>>>> Hi Christian >>>>>>>> >>>>>>>> Am 29.09.20 um 17:35 schrieb Christian K=C3=B6nig: >>>>>>>>> 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 insi= de 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-sparc6= 4 >>>>>>>> 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 throug= h 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. Boch= s >>>>>> 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_o= bj >>>>> 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? Ther= e's >>>> too many places in ttm drivers where is_iomem and related stuff is u= sed to >>>> be able to convert it all in one go. An intermediate state with a bu= nch 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 rem= ove >>> 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. >=20 > Ok I started reviewing this a bit more in-depth, and I think this is a = bit > too much of a de-tour. >=20 > 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 j= ust > immediately follows up with converting that full object map into a > pointer. >=20 > So I think what we really want here is: > - new function >=20 > int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map);= >=20 > _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. >=20 > - 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 tt= m > and gem driver. >=20 > This is maybe a good follow-up, since it should allow us to ditch qui= te > a bit of the vram helper code for this more generic stuff. I also mig= ht > have missed some special-cases here, but from a quick look everything= > just pins the buffer to the current location and that's it. >=20 > Also this obviously requires Christian's generic ttm_bo_pin rework > first. >=20 > - roll the above out to drivers. >=20 > Christian/Thomas, thoughts on this? I agree on the goals, but what is the immediate objective here? Adding ttm_bo_vmap() does not work out easily, as struct ttm_bo_kmap_obj is a central part of the internals of TTM. struct ttm_bo_kmap_obj has more internal state that struct dma_buf_map, so they are not easily convertible either. What you propose seems to require a reimplementation of the existing ttm_bo_kmap() code. That is it's own patch series. I'd rather go with some variant of the existing patch and add ttm_bo_vmap() in a follow-up. Best regards Thomas >=20 > 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 w= ide > roll-out for now. >=20 > Cheers, Daniel >=20 >> -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/tt= m_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= =2E >>>>>>>>>> + */ >>>>>>>>>> +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 =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 __iome= m *)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-b= uf-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_s= et() 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 =3D false; >>>>>>>>>> } >>>>>>>>>> +/** >>>>>>>>>> + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping struc= ture 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 str= uctures >>>>>>>>>> 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%= 2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02= %7C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3= dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3D= HdHOA%2F1VcIX%2F7YtfYTiAqYEvw7Ag%2FS%2BxS5VwJKOv5y0%3D&reserved=3D0 >>>>>>>> _______________________________________________ >>>>>>>> amd-gfx mailing list >>>>>>>> amd-gfx@lists.freedesktop.org >>>>>>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=3D02%7C= 01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd8= 961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2= B5HKCsTrksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%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%7= C01%7Cchristian.koenig%40amd.com%7C472c3d655a61411deb6708d86525d1b8%7C3dd= 8961fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DHd= HOA%2F1VcIX%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%7C3dd896= 1fe4884e608e11a82d994e183d%7C0%7C0%7C637370560438965013&sdata=3DH%2B5= HKCsTrksRV2EyEiFGSTyS79jsWCmJimSMoJYusx8%3D&reserved=3D0 >>> >> >> >> --=20 >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch >=20 --=20 Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany (HRB 36809, AG N=C3=BCrnberg) Gesch=C3=A4ftsf=C3=BChrer: Felix Imend=C3=B6rffer --eO0KkNElTwku9CAInc7DmPRt4uql8oe3b-- --A04G9t256jlYlZevsaZFScYx8JwBsN4Kq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQFIBAEBCAAyFiEEchf7rIzpz2NEoWjlaA3BHVMLeiMFAl99uzYUHHR6aW1tZXJt YW5uQHN1c2UuZGUACgkQaA3BHVMLeiPFlAf/dShA6MXCEFDqVh7Q2aekDDfCOwKP 86fkrX8xWfiHNET9AoewUP7K9m5+iArIbwelpHBUNV2q7EUKG8xVuK5S55bz6xxq 3vSlROkD+JZvgovXr5BuGyfn2Wfh9XI9+rs3+OtERgtJfNhjEpNok5rukvNAoFzG ePSAUBcIN7Ezb5O93zT45pI5YwQYe9ZyFiLVztXAZ67edwZbZN8NBp5OrnAhP8Po 57jSeNoEnzwhVF7+V+tgRYYA8y7Bz7VNTbqaJoEBvqDhQQsrt0KLshFG9NQY/srf /fO1NoHVLPTajZPPYmd9F/2xDImwGoZF2MDLL30AFoRRynTMiWtqixUpJQ== =sTNF -----END PGP SIGNATURE----- --A04G9t256jlYlZevsaZFScYx8JwBsN4Kq-- --===============2833149448897706010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip --===============2833149448897706010==--