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=-18.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL 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 3B0C3C433E6 for ; Fri, 29 Jan 2021 01:24:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EE7FA64DFD for ; Fri, 29 Jan 2021 01:24:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231764AbhA2BYH (ORCPT ); Thu, 28 Jan 2021 20:24:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231601AbhA2BYF (ORCPT ); Thu, 28 Jan 2021 20:24:05 -0500 Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A4CAC061574 for ; Thu, 28 Jan 2021 17:23:25 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id b5so4087910vsh.3 for ; Thu, 28 Jan 2021 17:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sjkb6yXWtZ9Sxv1/gNdqQbGBoN1+dPLaicMA2ZT6rNM=; b=iCLYU3fuPsvJZltkAom5unfVux3qbx/84SoQSmqh5RtsiImcrCdGMT31C6+1ENMBLS 0+LRiLAsmRhmOFQ5Q3GHbyu5aZ74aQkQRyaA63MegeLEXfmWLspArV+SQzI3/B/1cGxJ 1rQ42u/3utf0mvm4yEsRiVY+BSTy3WgKy9UUCY1jQR27gxY3lKBZJ2MjQvlH/Y3jc8R5 O3KBn5Wfuxbpq3cWKoGssSVuk/IPGSipcB70yiVvVwUkdP1OYGYUTRRJlSo87uQH/33A B+txLKIct1lZEOxXRo12HH2AlAlcCOCVY8UJXBD8D02HEcysxUof5gYWcOYymjgwUMGv a2ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sjkb6yXWtZ9Sxv1/gNdqQbGBoN1+dPLaicMA2ZT6rNM=; b=tWiGXtHOJuuOcfgtfJlw48UdSe5TMpIqNWffrDTXGZ5cySFgXViJ1spVl5qkahB5z+ tTt4CIvoFXtXwfvCAWSQ0QjazGicZYylM5PtCuA3u5goI7DM3C1B2Mb7uPJMCE+dqE9F 0MjgWDQ+TLKKP0GZDgO1O9qJblCl9jBjNRgAPdVFdZmJDtf5yLP7+YaO+qMrM8d7secb EPA8+dbQqoszBMUKgkQtqg9WA8mbv2boEFcXiYsdTc4/6mqdHP5HvPeRqlpcutXb79HY eH+oCa47wEo2cnXu8mquz2hf4JxHgARYD3jZ5dkxY2djZInXYDMbd4CRAAysuv4DjBuj WpAQ== X-Gm-Message-State: AOAM530Zf1AdTO3AbE+4uK6OItEWQMkvuxYlzi6RnX46ItPQyP+Xe3pZ 1aodggbPOvwkqbHkDvsIQ6ZXpHqykaKxTi91E4P+SQ== X-Google-Smtp-Source: ABdhPJzvSoHd4aqU6Cv8LKu9Sl0lIJ7bapX7TwH6WxQlYBY8b93nG65hR4r/fmD0J1GnGIrVHo0uyX2Ku496O34Z6ik= X-Received: by 2002:a67:f810:: with SMTP id l16mr1395266vso.41.1611883403850; Thu, 28 Jan 2021 17:23:23 -0800 (PST) MIME-Version: 1.0 References: <20201003040257.62768-1-john.stultz@linaro.org> <20201003040257.62768-8-john.stultz@linaro.org> <20201008115101.4qi6wh3hhkb6krg5@DESKTOP-E1NTVVP.localdomain> In-Reply-To: From: Daniel Mentz Date: Thu, 28 Jan 2021 17:23:12 -0800 Message-ID: Subject: Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap To: John Stultz Cc: Brian Starkey , lkml , Sumit Semwal , Liam Mark , Laura Abbott , Hridya Valsaraju , Suren Baghdasaryan , Sandeep Patil , Chris Goldsworthy , =?UTF-8?Q?=C3=98rjan_Eide?= , Robin Murphy , Ezequiel Garcia , Simon Ser , James Jones , linux-media , dri-devel , nd Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 16, 2020 at 12:04 PM John Stultz wrote: > > On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote: > > On Sat, Oct 03, 2020 at 04:02:57AM +0000, John Stultz wrote: > > > @@ -393,6 +424,16 @@ static int system_heap_allocate(struct dma_heap *heap, > > > /* just return, as put will call release and that will free */ > > > return ret; > > > } > > > + > > > + /* > > > + * For uncached buffers, we need to initially flush cpu cache, since > > > + * the __GFP_ZERO on the allocation means the zeroing was done by the > > > + * cpu and thus it is likely cached. Map (and implicitly flush) it out > > > + * now so we don't get corruption later on. > > > + */ > > > + if (buffer->uncached) > > > + dma_map_sgtable(dma_heap_get_dev(heap), table, DMA_BIDIRECTIONAL, 0); > > > > Do we have to keep this mapping around for the entire lifetime of the > > buffer? > > Yea, I guess we can just map and unmap it right there. It will look a > little absurd, but that sort of aligns with your next point. > > > Also, this problem (and solution) keeps lingering around. It really > > feels like there should be a better way to solve "clean the linear > > mapping all the way to DRAM", but I don't know what that should be. > > Yea, something better here would be nice... In ION, we had a little helper function named ion_buffer_prep_noncached that called arch_dma_prep_coherent() on all sg entries like so for_each_sg(table->sgl, sg, table->orig_nents, i) arch_dma_prep_coherent(sg_page(sg), sg->length); Would that help?