Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2860625pxj; Sun, 6 Jun 2021 17:07:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymO6wwjCkCL1Rv+z0ezcxLUpcOls/IQrNXYwDrcxmH/aBlLGRVy1+GG0J/CSYi4I/eYP/5 X-Received: by 2002:a05:6402:b1a:: with SMTP id bm26mr17444154edb.387.1623024465446; Sun, 06 Jun 2021 17:07:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623024465; cv=none; d=google.com; s=arc-20160816; b=dEonsbj1jXNVuU2V3DETtT+Zfcp/5ijx+4Hn+LocZjFIJD2y2VEe2tsSZqFHLpLOal Ei6O5uoIZFw1+7Y3v/RkBxa14efc9v8aD/Sk9vTWZQtzycExyt2wFGFyHVAoL0NQxxdN peantW5ZFlbqYWME50ZjPffDp0e2OmeFGgFE7dNqrCNlh1WpueV0xN+Dx5keFzWHAHJ0 kRo8tZ9eyxodmQqR/y7TyysEocXARyJ9GPQTxrNjyjgyAV6Afd0yYTPlLGpTPs5naJHI nWj0EKZbK8sYytkNN827NVDQT1LciBrZj7ag0pO+awb1aHwaM3/zkVnXWRgC9WC6wMGF uZzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=atz/fcsESOx4m+4QdyLdkqW2IvLkfkghNsC8hMHMoCA=; b=QkzxyoXYLk3m/mKwaXCpTFWi+e31Ur6K567xK3KepgVRsJSOOWyHStMBal7w++hn62 XGSGogkAAE7Z3LZx8kQj4fTppOFU3xQJC4/WAzLrEBrw9+UInFwpfj0Xozew2n5fycbP Jz3e57rAA2pe2oJmgXaUaVLjFmpx0aCu7pj3RT2Tg2ZGQNgGysuw/HsaxQyW5C44YOWN k1k31+U+pyzC6+qAeAVDdkqoy4aecrKRnh2xkEMLzhtp1+7LxhCVeHSK9LKCTf+/2ZfK Fu+RWE8qDtXFz5dGO2Y8mDxO1ndcv0qFywXUJHaG7yFMygIQgS+sZ8S+NMwkLZOp3DmE O5zA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KurZTjpi; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b20si8493383ejq.607.2021.06.06.17.07.23; Sun, 06 Jun 2021 17:07:45 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KurZTjpi; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230099AbhFGAGn (ORCPT + 99 others); Sun, 6 Jun 2021 20:06:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:42352 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229772AbhFGAGn (ORCPT ); Sun, 6 Jun 2021 20:06:43 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2419161244; Mon, 7 Jun 2021 00:04:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623024293; bh=atz/fcsESOx4m+4QdyLdkqW2IvLkfkghNsC8hMHMoCA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KurZTjpisOGAbiz8svMmX6uc4+SaRSwiEJJH43yI/4co87lGcqFgAAS4k6LCPkroD lHv1jHyzy7HV08taRk5MiYDAW/mWOr34psAtqjYh53vwxwdXV7PGnZw2mkkizTbvst fPOaZgRm/0/tRQcego1vRCK0JWhYbMd0L2sqlr5iKhZbYEKQwbxE0dWlLA8Qo1bOL4 Rni2BcHIbw53+0fLUm2WOqAFJO8ZqlVVbATNhg+e4pq8fOxApd7kzKAQbaOJ4A06mW iSOqOvVTZVOZE1hVm0gdM6256I/ydU8WXp8Txm6QT0h/6BvgKZeAVsiX7OMZ/Cr3mb Xhs8u93K9lyLw== Received: by mail-lf1-f49.google.com with SMTP id v22so21871577lfa.3; Sun, 06 Jun 2021 17:04:53 -0700 (PDT) X-Gm-Message-State: AOAM531LfmJv7F0SygchUyUpQ/i+MnLdK/zY4aydNvlp8ojhssQUG89Y H7Hbb+99bJI5UADRt0TwGMx1UrsQ8sr60vS66jw= X-Received: by 2002:a05:6512:218d:: with SMTP id b13mr10221837lft.346.1623024291473; Sun, 06 Jun 2021 17:04:51 -0700 (PDT) MIME-Version: 1.0 References: <1621400656-25678-1-git-send-email-guoren@kernel.org> <20210519052048.GA24853@lst.de> <20210519064435.GA3076809@x1> <20210519065352.GA31590@lst.de> <29733b0931d9dd6a2f0b6919067c7efe@mailhost.ics.forth.gr> In-Reply-To: <29733b0931d9dd6a2f0b6919067c7efe@mailhost.ics.forth.gr> From: Guo Ren Date: Mon, 7 Jun 2021 08:04:40 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support To: Nick Kossifidis Cc: Christoph Hellwig , Drew Fustini , Anup Patel , Palmer Dabbelt , wefu@redhat.com, =?UTF-8?B?V2VpIFd1ICjlkLTkvJ8p?= , linux-riscv , Linux Kernel Mailing List , linux-arch , linux-sunxi@lists.linux.dev, Guo Ren , Paul Walmsley , Benjamin Koch , Matteo Croce , Wei Fu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 7, 2021 at 2:14 AM Nick Kossifidis wrote: > > =CE=A3=CF=84=CE=B9=CF=82 2021-05-20 04:45, Guo Ren =CE=AD=CE=B3=CF=81=CE= =B1=CF=88=CE=B5: > > On Wed, May 19, 2021 at 2:53 PM Christoph Hellwig wrote: > >> > >> 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 JH7= 100 > >> > [1] [2] too as it has peripherals on a non-coherent interconnect. GM= AC, > >> > USB and SDIO require that the L2 cache must be manually flushed afte= r > >> > 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. > > It's a very big MIPS smell. What's the attribute of the uncached > > window? (uncached + strong-order/ uncached + weak, most vendors still > > use AXI interconnect, how to deal with a bufferable attribute?) In > > fact, customers' drivers use different ways to deal with DMA memory in > > non-coherent SOC. Most riscv SOC vendors are from ARM, so giving them > > the same way in DMA memory is a smart choice. So using PTE attributes > > is more suitable. > > > > See: > > https://github.com/riscv/virtual-memory/blob/main/specs/611-virtual-mem= ory-diff.pdf > > 4.4.1 > > The draft supports custom attribute bits in PTE. > > > > Not only it doesn't support custom attributes on PTEs: > > "Bits63=E2=80=9354 are reserved for future standard use and must be zeroe= d by > software for forward compatibility." > > It also goes further to say that: > > "if any of these bits are set, a page-fault exception is raised" In RISC-V VM TG, A C-bit discussion is raised. So it's a comm idea to support it. Let Linux support custom PTE attributes won't get any side effect in practi= ce. IMO: We needn't waste a bit in PTE, but the custom idea in PTE reserved bits is necessary. Because Allwinner D1 needs custom PTE bits in reserved bits to work around. So I recommend just remove the "C" bit in PTE, but allow vendors to define their own PTE attributes in reserved bits. I've found a way to compact different PTE attributes of different vendors during the Linux boot stage. That means we still could use One Image for all vendors in Linux --=20 Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/