Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1721233pxj; Wed, 19 May 2021 12:18:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynrv5ahHTgiz2U4hJjS8fBv2lPCsiRB1OpUexkhZjVsQiSjwxsCRM9FW/wfrJKWgisWFBx X-Received: by 2002:a05:6638:2728:: with SMTP id m40mr678491jav.55.1621451906386; Wed, 19 May 2021 12:18:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621451906; cv=none; d=google.com; s=arc-20160816; b=sMjVEk/X+Yn/ymSxvZXcw48jC26DLQ/gK6R0Q0ngb5l3TJaMmbVmN0ictu+JWrpxYm 4S929Yh6OhbwCGs8Jw9Xo5jGm/+2LCK6IABu5Lg4HI5WGsONVoXZQbgKiWfXRGVsR30f rv6RqU6bn/cpZh6V4hkCUQzAcI88zxAgNMKZUZsQdlNKU6tLA76tcXh3LuDSogYdQ2cB PxSD2EMLglcth146ZI72S7qa40KDEy1qMj1lRq1yUr/JlojTCkYDKoKckEsmdPwE/zJf 65aZxUMERpa8/me/+Ai6epIUsDrwNkm2EtNKcYKH2GobUPQT/QM6h3zFoMmWSpC9OLgJ 41UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=mY+vRMeF8lkRaTxvv68JZ8qH/tT60qVcaqdlP8y9OIQ=; b=nEF+qaMgF8vf8AMUlB0UjXYDr7qGr/dM2nHptByrjFzChVC/FKPO88YBPRtLHEa8WT Qcovzl9eRc4nGTO708CtvDzRZXRg8O2td0FfoPqJ99LXLG2BmXD1zM+52zxOgEuwmaV8 kus4Ijs1BuYluTXMdwsY7jUguDknZoHfpeZmVtQU699eMBh91C+e2vVO2xz8735l3Rxu F0SWV6lpacAxDMVCN8hOukk1EB3TCvgGFJ+sLz/FcvJnNRn8EZgY/hRXRbvQ2Lvp9GtU BHdwqDi0M1fz1q8gBEBcPpluKfAMJ7FUp8J+k1q/97I+26jW1braFNBNgkYshtwjmgCk ZDVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t10si534457ilf.139.2021.05.19.12.18.12; Wed, 19 May 2021 12:18:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237502AbhESGzQ (ORCPT + 99 others); Wed, 19 May 2021 02:55:16 -0400 Received: from verein.lst.de ([213.95.11.211]:36955 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231147AbhESGzQ (ORCPT ); Wed, 19 May 2021 02:55:16 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id C1D4B67373; Wed, 19 May 2021 08:53:52 +0200 (CEST) Date: Wed, 19 May 2021 08:53:52 +0200 From: Christoph Hellwig To: Drew Fustini Cc: Guo Ren , Christoph Hellwig , Anup Patel , Palmer Dabbelt , wefu@redhat.com, lazyparser@gmail.com, linux-riscv , Linux Kernel Mailing List , linux-arch , linux-sunxi@lists.linux.dev, Guo Ren , paul.walmsley@sifive.com, Nick Kossifidis , Benjamin Koch , Matteo Croce , Wei Fu Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Message-ID: <20210519065352.GA31590@lst.de> References: <1621400656-25678-1-git-send-email-guoren@kernel.org> <20210519052048.GA24853@lst.de> <20210519064435.GA3076809@x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210519064435.GA3076809@x1> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 18, 2021 at 11:44:35PM -0700, Drew Fustini wrote: > This patch series looks like it might be useful for the StarFive JH7100 > [1] [2] too as it has peripherals on a non-coherent interconnect. GMAC, > USB and SDIO require that the L2 cache must be manually flushed after > DMA operations if the data is intended to be shared with U74 cores [2]. Not too much, given that the SiFive lineage CPUs have an uncached window, that is a totally different way to allocate uncached memory. > There is the RISC-V Cache Management Operation, or CMO, task group [3] > but I am not sure if that can help the SoC's that have already been > fabbed like the the D1 and the JH7100. It does, because unimplemented instructions trap into M-mode, where they can be emulated. Or to summarize things. Non-coherent DMA (and not coherent as title in this series) requires two things: 1) allocating chunks of memory that is marked as not cachable 2) instructions to invalidate and/or writeback cache lines none of which currently exists in RISV-V. Hacking vendor specific cruft into the kernel doesn't scale, as shown perfectly by this series which requires to hard code vendor specific non-standardized extensions in a kernel that makes it specific to that implementation. What we need to do is to standardize a way to do this properly, and then after that figure out a way to quirk in non-compliant implementations in a way that does not harm the general kernel.