Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp846345rdb; Fri, 22 Dec 2023 06:54:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IEMHylSsEY7aXuPpo/CMOWEABARaEzR1LpVsMf5Vis4L2U3vvi8Ry06nF3PVEFFFmwImjPi X-Received: by 2002:a17:90a:e40f:b0:28b:ac7d:a649 with SMTP id hv15-20020a17090ae40f00b0028bac7da649mr762424pjb.47.1703256872338; Fri, 22 Dec 2023 06:54:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703256872; cv=none; d=google.com; s=arc-20160816; b=gWffegZ6is9hwAlxeFZ/TjuLShpSjKoofQkJbUgFsH8TxnSbCbI3kMQ9dHznUgV8Uy 7/O8vizt58Y2Ne/PHiPUPdXHpWCI1lb/Msx0RRi4MfBsoccqTk6oYXSw7R07G66bunSl vx8Fr2MBrndDT7HqW3WTm/TIsbWqYn0Nu9uarVh4RG3++26BF4PX/teAk/tdc8H+uF21 vyr6PX43+DssfETSl4FidEVK2AGneYWCSA6M55cpy+N16VfVyiLgvY1tFT6yoseVrnVZ EQZ5IiRdHpFFYxVs0kRbiqXpRh7h621WJEOevrFuwZ393pWfkb2ez6ICMZB3IptK32Fj 1cNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=JaS8PAd13nD3ROAbnFEx3mutC/Qa6+DZnu2PmAOWJj0=; fh=gK3SJT/h4+ufsakmBCOVwbNDt46SemaSFdkMsX4i37k=; b=JjANktUIC3246nZrC2Or0foCAMJW4igubC+0k7s6djMFqqVFkSSTNjSB+ZioEjJiBv DO+jxvtmFhLiyzMsIceXfu3l1J1Bz0ic6CPBJitxHKT6+D8xqQepDld92r1ZgaOKT5qg 97cCatoQOA90ZV4oSzM9AHO2I88J7TQKcUFw0vRpQInfKzWpPzwdAC7PxFy+Fezs+BDu ITfSGKjiX/f2k0F3spzh8ECTZ4zsw9k99qSePqLFEsJIT7JtIqkLoC/U0jPkGSsadjVX 7SnlaQfzeK9AklhpI2W+WZJd3LUYcHZ6HGDw9mmOyACQoexKav5BgGNG4NRNiTbU5BIX 21Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=o+N++2V0; spf=pass (google.com: domain of linux-kernel+bounces-9794-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9794-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id t4-20020a17090b018400b0028bdf9b0a8csi3985528pjs.167.2023.12.22.06.54.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 06:54:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-9794-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=o+N++2V0; spf=pass (google.com: domain of linux-kernel+bounces-9794-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9794-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 035D8284BCB for ; Fri, 22 Dec 2023 14:54:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 47E1E23749; Fri, 22 Dec 2023 14:54:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o+N++2V0" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 757BF23741 for ; Fri, 22 Dec 2023 14:54:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8C44C433C8; Fri, 22 Dec 2023 14:54:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703256863; bh=h1sYjxXs/BoGIevsNfBe5AqphkFcDWhg0nXp3wZemrw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=o+N++2V07ZnRWHIxSTLxPZ0ATvi5IuRVHkipLU+T5nujnqrswaXe7S6V9UVyZeevT QorrWfbqmUj/zb7Ekn/MafDAWTo3CbPv4Ui+XHRKU0fpqCdmCyKGu6bHiJNP+aecy4 38RsSn9qmeF+aiY1z5mADjUrz1S70mz+IvuaEYcw4E8WIPaYqmLwWRIlwLWUf9raPa JT33J6ba8nZKkjwLzE0OBdvIaqKFjgGtYKo+8WmaJgHiPj7FIyWx9Tlgte30+zrLcu ZH4QkgIjb8N3s7YWAMvTCGbcR9dDWGwOLxMPoz+JAaTli38vawIupITp/Xj05CXJoE tZ3yt55pJtJ/A== Date: Fri, 22 Dec 2023 14:54:19 +0000 From: Conor Dooley To: Maxim Kochetkov Cc: Christoph Hellwig , Jiaxun Yang , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, robh@kernel.org, mpe@ellerman.id.au, aou@eecs.berkeley.edu, palmer@dabbelt.com, paul.walmsley@sifive.com Subject: Re: [PATCH 1/1] riscv: set ARCH_DMA_DEFAULT_COHERENT if RISCV_DMA_NONCOHERENT is not set Message-ID: <20231222-outburst-spoiling-75082a7826dd@spud> References: <20231221185152.327231-1-fido_max@inbox.ru> <20231221-discount-decade-e306e5878c46@spud> <20231222041428.GA2803@lst.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5//zPWq/C4g8xMfn" Content-Disposition: inline In-Reply-To: --5//zPWq/C4g8xMfn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 22, 2023 at 05:39:34PM +0300, Maxim Kochetkov wrote: >=20 >=20 > On 22.12.2023 07:14, Christoph Hellwig wrote: > > On Thu, Dec 21, 2023 at 10:27:33PM +0000, Jiaxun Yang wrote: > > >=20 > > >=20 > > > =E5=9C=A8 2023/12/21 20:29, Conor Dooley =E5=86=99=E9=81=93: > > > > + Christoph > > > >=20 > > > > I don't think this patch is correct. Regardless of whether we suppo= rt > > > > cache management operations, DMA is assumed to be coherent unless > > > > peripherals etc are specified to otherwise in DT (or however ACPI d= eals > > > > with that kind of thing). > > > >=20 > > > > What problem are you trying to solve here? > > > >=20 > > > > On Thu, Dec 21, 2023 at 09:51:52PM +0300, Maxim Kochetkov wrote: > > > > > Not all the RISCV are DMA coherent by default. > > >=20 > > > Sorry for chime in here. > > > IMO if your platform is not coherent by default, just insert > > > "dma-noncoherent" > > > at devicetree root node. > >=20 > > Exactly. ARCH_DMA_DEFAULT_COHERENTis a setting that just says for > > a given architecture assumes coherent unless otherwise specified, > > which has historically been the case for mips. Not setting it means > > non-coherent unless specified, which has historially been the case > > for arm. > >=20 > > RISC-V starte out without support for non-coherent DMA, and high ups > > in RISCV still told me in 2019 that RISC-V doesn't need cache > > management instructions because no new hardware would ever not be > > dma coherent. Yeah, right.. > >=20 > > Anyay, Linux for RISC-V has historically been coherent only and then > > coherent default, so this option is wrong, and you need to mark > > you platform as non-coherent by inserting dma-noncoherent somewhere. > >=20 > Conor, Christoph, Jiaxun, thanks for quick feedback! >=20 > The problem is very simple: > For non mips platforms dma_default_coherent is used at of_dma_is_coherent= () > and device_initialize(). > of_dma_is_coherent() affects only DT devices. And we can override it with > "dma-coherent"/"dma-noncoherent". ACPI devices can specify by > "attr =3D=3D DEV_DMA_COHERENT". But all other devices (platform_device, u= sb, I would have expected that usb devices "inherit" the value from the usb controller whose bus they are on. Similarly, platform devices are on a bus that should be marked as non-coherent if that is the case. Christoph certainly knows better how things operate here however. > etc..) do not have this feature. These devices will use value from > device_initialize(). And we have no possibility to change > dma_default_coherent value by disabling ARCH_DMA_DEFAULT_COHERENT. > Moreover, changing dma_default_coherent from false to true may cause > regression for other devices. How can there be a regression when dma has been coherent by default for the RISC-V kernel from day 1? > That is why I suggest possibility to disable > ARCH_DMA_DEFAULT_COHERENT by RISCV_DMA_NONCOHERENT option. > It will works like for PPC: > ..... > config PPC > bool > default y > # > # Please keep this list sorted alphabetically. > # > select ARCH_32BIT_OFF_T if PPC32 > select ARCH_DISABLE_KASAN_INLINE if PPC_RADIX_MMU > select ARCH_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE > ..... > Doesn't the option RISCV_DMA_NONCOHERENT say the DMA should be non-cohere= nt > by default? No. That option only controls whether or not support for cache management operations is built into the kernel. It is expected that this option can be enabled for multiplatform kernels, like those used by distributions, that will run on systems that are entirely coherent as well as those that are not. It does not work the same was as this PPC option appears to. Cheers, Conor. --5//zPWq/C4g8xMfn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZYWjGAAKCRB4tDGHoIJi 0kh4AQCy/DmyJqEzO0UfUNW7jC/E7LLYxcDZ3qSUEhKoIPC6YQEA8YqL9p+Ng/Qe cu7+3I0y2J9vgEUq7+8V2Z3ijNwgZQY= =cA60 -----END PGP SIGNATURE----- --5//zPWq/C4g8xMfn--