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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 D0ABAC433E6 for ; Mon, 15 Feb 2021 20:40:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B163A64DF4 for ; Mon, 15 Feb 2021 20:40:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229703AbhBOUkQ (ORCPT ); Mon, 15 Feb 2021 15:40:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229675AbhBOUkJ (ORCPT ); Mon, 15 Feb 2021 15:40:09 -0500 Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C923CC0613D6 for ; Mon, 15 Feb 2021 12:39:28 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id d3so5696256qtr.10 for ; Mon, 15 Feb 2021 12:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndufresne-ca.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=izMPWC9xzdGUwutm2Q6mM8UrXkyQ+i4Rd0btbUUbmuE=; b=Qt0K1XUEVhzGGmGW9DPr+ZslPovr8CzYvRlVZE6qa5zt86N4A6SmndrbogZUwOO3Rt TTxPfxPpmSBrXu9xKVJq7pZpe4Wl6COfBzooWrSSYg+9FrV7melBNwwcmELOvVLX8PQH G6gR5DAFvW3LRvW8BMnuRS/Fc3+v10M4GMCNsjLDwrXu/fG0nWelO/ujXQWE/NFH6sGY 2kK4sQioDdTzWquAZrlDhFU4gDOZpGNZvVPYMFHaUic5i9uJo5REqwTQm9XtOf84CDmn iVGtl52LvSHafrOhRfg2DVIictloHr3dVciOJv3vyyoeSIXlJzGymZhO4ZvUJ7vePLCj pImg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=izMPWC9xzdGUwutm2Q6mM8UrXkyQ+i4Rd0btbUUbmuE=; b=D1fjomYVsyfEdInqokIxLfCpG0KKOZPYLlMutZDQ+VB3qrgK5SEyQgF7cjsDlI5K/0 XEeajY+WTluSMH64H+WGFPVVKfyWhfkI2nvbl+WAEbQiMNyyD+6cUMnf6glTXUWPKJgL dDdVvaCS8pzBRIso2Mx12x7kYdfV4w582P1Nuje92pngTysOZ4zdDuLf82p5chY5YYS6 gdbSyeYz9lFwLFMhvhqx686JSmw/QkKoxytx+2Xal8kLSDSYkNlj43qW2HboVT/6RF9R uswsfSQGmzW0SrpvfBMROBfbSLfxYP9tEd9q+SyY9NBGqTX9AE3/oD9tXDzTXUIfREvJ /yvw== X-Gm-Message-State: AOAM533aUzzdMvy95RaIW948Pka9LJ9b+Jbzn0m8fLEZr7dwMt1iFH7l XVJN4rwO47kAPJRB48s6+dvlWQ== X-Google-Smtp-Source: ABdhPJxWqkD3hf4mY/GDpcC4EsRa6i2RiBg3HXU3ro5LrIrS77GYinDVNo+FQ5vbq0WTSCZrhq389g== X-Received: by 2002:ac8:7456:: with SMTP id h22mr15833673qtr.297.1613421567977; Mon, 15 Feb 2021 12:39:27 -0800 (PST) Received: from nicolas-tpx395.lan (173-246-12-168.qc.cable.ebox.net. [173.246.12.168]) by smtp.gmail.com with ESMTPSA id i5sm13131110qkg.32.2021.02.15.12.39.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Feb 2021 12:39:27 -0800 (PST) Message-ID: Subject: Re: DMA-buf and uncached system memory From: Nicolas Dufresne To: Christian =?ISO-8859-1?Q?K=F6nig?= , linux-media , dri-devel , linaro-mm-sig@lists.linaro.org, lkml Cc: Sumit Semwal , Daniel Vetter , "Sharma, Shashank" Date: Mon, 15 Feb 2021 15:39:25 -0500 In-Reply-To: <91ff0bbb-ea3a-2663-3453-dea96ccd6dd8@amd.com> References: <91ff0bbb-ea3a-2663-3453-dea96ccd6dd8@amd.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le lundi 15 février 2021 à 09:58 +0100, Christian König a écrit : > Hi guys, > > we are currently working an Freesync and direct scan out from system > memory on AMD APUs in A+A laptops. > > On problem we stumbled over is that our display hardware needs to scan > out from uncached system memory and we currently don't have a way to > communicate that through DMA-buf. > > For our specific use case at hand we are going to implement something > driver specific, but the question is should we have something more > generic for this? Hopefully I'm getting this right, but this makes me think of a long standing issue I've met with Intel DRM and UVC driver. If I let the UVC driver allocate the buffer, and import the resulting DMABuf (cacheable memory written with a cpu copy in the kernel) into DRM, we can see cache artifact being displayed. While if I use the DRM driver memory (dumb buffer in that case) it's clean because there is a driver specific solution to that. There is no obvious way for userspace application to know what's is right/wrong way and in fact it feels like the kernel could solve this somehow without having to inform userspace (perhaps). > > After all the system memory access pattern is a PCIe extension and as > such something generic. > > Regards, > Christian.