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 A20ADC433DF for ; Fri, 16 Oct 2020 10:09:29 +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 7627720848 for ; Fri, 16 Oct 2020 10:09:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DgTdWn80" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7627720848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ravnborg.org 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=/Fx7Kd2ziyLiNKGKFVz2Q9tuD4mxDeL1sElPviFj6gI=; b=DgTdWn80d0/9SMkXkYDjfYe9/ 1yYz96P5V1d5X8oQzCZSQm3r6z6djD0ySnsEHjArxz2lWAPcuuUP9Ui7cJUFIq+rJuGB28rOvfnPt hNE+YeelJ7lsWRrsHhTTUTbXUu+paAMAAvA0/pjVO9cY4Rfmw39deqPz0OF2lxW8qA6IJsKlDAzDD hOAlA1gtI1/+1UYOMwtXjduTWedRX6qFHn0nDw/1lK18QkNcQ3fgUGMOu3Av55J8sfGp8qpUPWsbD a3GCK/l5bnEVd5+l7ql0ObUv494cjI6y9xRbEMr6VLsez11MR/2JR2xkXvOviPBB0p/NPOfyNznmf Vwc1Wn81w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kTMfl-00059L-8w; Fri, 16 Oct 2020 10:09:17 +0000 Received: from asavdk3.altibox.net ([109.247.116.14]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kTMfi-00057t-3k; Fri, 16 Oct 2020 10:09:15 +0000 Received: from ravnborg.org (unknown [188.228.123.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk3.altibox.net (Postfix) with ESMTPS id DC35220027; Fri, 16 Oct 2020 12:08:55 +0200 (CEST) Date: Fri, 16 Oct 2020 12:08:54 +0200 From: Sam Ravnborg To: Thomas Zimmermann Subject: Re: [PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces Message-ID: <20201016100854.GA1042954@ravnborg.org> References: <20201015123806.32416-1-tzimmermann@suse.de> <20201015123806.32416-10-tzimmermann@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201015123806.32416-10-tzimmermann@suse.de> X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=S433PrkP c=1 sm=1 tr=0 a=S6zTFyMACwkrwXSdXUNehg==:117 a=S6zTFyMACwkrwXSdXUNehg==:17 a=kj9zAlcOel0A:10 a=7gkXJVJtAAAA:8 a=0A2xud3A4b7FAmx5SMIA:9 a=7a1rlSNJFqSX5uOf:21 a=OU_kl8OV53ZSq-ss:21 a=CjuIK1q_8ugA:10 a=E9Po1WZjFZOl8hwRPBS3:22 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201016_060914_404820_4C561BF4 X-CRM114-Status: GOOD ( 30.58 ) 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@amd.com, heiko@sntech.de, airlied@linux.ie, nouveau@lists.freedesktop.org, linus.walleij@linaro.org, dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk, melissa.srw@gmail.com, eric@anholt.net, ray.huang@amd.com, kraxel@redhat.com, sumit.semwal@linaro.org, emil.velikov@collabora.com, robh@kernel.org, linux-samsung-soc@vger.kernel.org, jy0922.shim@samsung.com, lima@lists.freedesktop.org, oleksandr_andrushchenko@epam.com, krzk@kernel.org, steven.price@arm.com, linux-rockchip@lists.infradead.org, kgene@kernel.org, alyssa.rosenzweig@collabora.com, linux+etnaviv@armlinux.org.uk, spice-devel@lists.freedesktop.org, bskeggs@redhat.com, maarten.lankhorst@linux.intel.com, etnaviv@lists.freedesktop.org, mripard@kernel.org, inki.dae@samsung.com, hdegoede@redhat.com, christian.gmeiner@gmail.com, xen-devel@lists.xenproject.org, virtualization@lists.linux-foundation.org, sean@poorly.run, apaneers@amd.com, linux-arm-kernel@lists.infradead.org, linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org, tomeu.vizoso@collabora.com, sw0312.kim@samsung.com, hjc@rock-chips.com, kyungmin.park@samsung.com, miaoqinglang@huawei.com, yuq825@gmail.com, daniel@ffwll.ch, alexander.deucher@amd.com, linux-media@vger.kernel.org, christian.koenig@amd.com, l.stach@pengutronix.de Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org Hi Thomas. On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote: > To do framebuffer updates, one needs memcpy from system memory and a > pointer-increment function. Add both interfaces with documentation. > > Signed-off-by: Thomas Zimmermann Looks good. Reviewed-by: Sam Ravnborg > --- > include/linux/dma-buf-map.h | 72 +++++++++++++++++++++++++++++++------ > 1 file changed, 62 insertions(+), 10 deletions(-) > > diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h > index 2e8bbecb5091..6ca0f304dda2 100644 > --- a/include/linux/dma-buf-map.h > +++ b/include/linux/dma-buf-map.h > @@ -32,6 +32,14 @@ > * accessing the buffer. Use the returned instance and the helper functions > * to access the buffer's memory in the correct way. > * > + * The type :c:type:`struct dma_buf_map ` and its helpers are > + * actually independent from the dma-buf infrastructure. When sharing buffers > + * among devices, drivers have to know the location of the memory to access > + * the buffers in a safe way. :c:type:`struct dma_buf_map ` > + * solves this problem for dma-buf and its users. If other drivers or > + * sub-systems require similar functionality, the type could be generalized > + * and moved to a more prominent header file. > + * > * Open-coding access to :c:type:`struct dma_buf_map ` is > * considered bad style. Rather then accessing its fields directly, use one > * of the provided helper functions, or implement your own. For example, > @@ -51,6 +59,14 @@ > * > * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf); > * > + * Instances of struct dma_buf_map do not have to be cleaned up, but > + * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings > + * always refer to system memory. > + * > + * .. code-block:: c > + * > + * dma_buf_map_clear(&map); > + * > * Test if a mapping is valid with either dma_buf_map_is_set() or > * dma_buf_map_is_null(). > * > @@ -73,17 +89,19 @@ > * if (dma_buf_map_is_equal(&sys_map, &io_map)) > * // always false > * > - * Instances of struct dma_buf_map do not have to be cleaned up, but > - * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings > - * always refer to system memory. > + * A set up instance of struct dma_buf_map can be used to access or manipulate > + * the buffer memory. Depending on the location of the memory, the provided > + * helpers will pick the correct operations. Data can be copied into the memory > + * with dma_buf_map_memcpy_to(). The address can be manipulated with > + * dma_buf_map_incr(). > * > - * The type :c:type:`struct dma_buf_map ` and its helpers are > - * actually independent from the dma-buf infrastructure. When sharing buffers > - * among devices, drivers have to know the location of the memory to access > - * the buffers in a safe way. :c:type:`struct dma_buf_map ` > - * solves this problem for dma-buf and its users. If other drivers or > - * sub-systems require similar functionality, the type could be generalized > - * and moved to a more prominent header file. > + * .. code-block:: c > + * > + * const void *src = ...; // source buffer > + * size_t len = ...; // length of src > + * > + * dma_buf_map_memcpy_to(&map, src, len); > + * dma_buf_map_incr(&map, len); // go to first byte after the memcpy > */ > > /** > @@ -210,4 +228,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map *map) > } > } > > +/** > + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping > + * @dst: The dma-buf mapping structure > + * @src: The source buffer > + * @len: The number of byte in src > + * > + * Copies data into a dma-buf mapping. The source buffer is in system > + * memory. Depending on the buffer's location, the helper picks the correct > + * method of accessing the memory. > + */ > +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void *src, size_t len) > +{ > + if (dst->is_iomem) > + memcpy_toio(dst->vaddr_iomem, src, len); > + else > + memcpy(dst->vaddr, src, len); > +} > + > +/** > + * dma_buf_map_incr - Increments the address stored in a dma-buf mapping > + * @map: The dma-buf mapping structure > + * @incr: The number of bytes to increment > + * > + * Increments the address stored in a dma-buf mapping. Depending on the > + * buffer's location, the correct value will be updated. > + */ > +static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr) > +{ > + if (map->is_iomem) > + map->vaddr_iomem += incr; > + else > + map->vaddr += incr; > +} > + > #endif /* __DMA_BUF_MAP_H__ */ > -- > 2.28.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip