Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp6295529imd; Wed, 31 Oct 2018 09:34:14 -0700 (PDT) X-Google-Smtp-Source: AJdET5cld21pXkwUHQIp38iyiZbDiy1SQ77/JcbX/IukqnjUUaWIYWHot7Iie2A6z++pYY2BOzSj X-Received: by 2002:a62:3a54:: with SMTP id h81-v6mr4075088pfa.119.1541003654149; Wed, 31 Oct 2018 09:34:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541003654; cv=none; d=google.com; s=arc-20160816; b=uV0RGPk1lYtEOfKSTZu38r0qgNVdWGpOF56txIJbbNiOaDJSmzPKd5m8kDA1k+OVHM 0pbGTVhtpUicL9IX/BxYjKvF2fpfiYeXa0nc2mFZtQwwNM9EnhMRcFaA1FyxCIMRnqIu Z7dn4kT6F7d9pYOO4UMByPTwHIm4cmviELNhyQV92u9k4L4N19T+RT7k19uvebAkypvT omamzbsp7l0u2bEc34ME3eHU8fdYl2rGc6bE9CLkMRyAgJzUO4DRzxC59Mo9dnZdhaYA BNB+9MrQXl0p0wpAjotBk2c2tXpYBOKZX/jz3LLW6ko6F8lac02hZjxwxaofYjDQ8JVj M0SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=cQLFGQe4fOeCpwKQ7L7mgaaR/FSz5b8sOVo3TDtfpcA=; b=eD7kVGM69ZK+hPJo0VNRn3ZyvRImjWrJ9X9WgxzkQ2n4Fjl75S9W0Fk8juTGKsJrCN TYLUOpRV3QUuqYeRV2FroEpOosj8bulBKjYELvsEoUCh6i6JVAwMw7hEDEC+ElwqO7Kk tSWFD8DO3LuioxFReZgoil1kUi1BWHvavk15NkboBtW6g97hgL4vcuViwwNbaLtk7vcZ hc/odJuaoMG1HY7DMjUtxJf0HDjxCwXtdBUT64+sHXpE4xWvoH7QGuoQkejsoZS4po/I kXHYn2lRaScrLpmcI/a7uFP5qx4+JPKPLzSC976XAKvqU+lZQQ7FUS2FttMCoQGB9auK 8NFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1-v6si26695326plr.64.2018.10.31.09.33.57; Wed, 31 Oct 2018 09:34:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729682AbeKABa2 (ORCPT + 99 others); Wed, 31 Oct 2018 21:30:28 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:43146 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726720AbeKABa1 (ORCPT ); Wed, 31 Oct 2018 21:30:27 -0400 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23991025AbeJaQbkPiy6m (ORCPT ); Wed, 31 Oct 2018 17:31:40 +0100 Date: Wed, 31 Oct 2018 16:31:40 +0000 (GMT) From: "Maciej W. Rozycki" To: Christoph Hellwig cc: iommu@lists.linux-foundation.org, Marek Szyprowski , Robin Murphy , Paul Burton , Greg Kroah-Hartman , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/6] dma-mapping: merge direct and noncoherent ops In-Reply-To: Message-ID: References: <20180914095808.22202-1-hch@lst.de> <20180914095808.22202-5-hch@lst.de> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 31 Oct 2018, Maciej W. Rozycki wrote: > > All the cache maintainance is already stubbed out when not enabled, > > but merging the two allows us to nicely handle the case where > > cache maintainance is required for some devices, but not others. > > FYI, you commit bc3ec75de545 ("dma-mapping: merge direct and noncoherent > ops") has caused: > > fddi0: DMA command request failed! > fddi0: Adapter open failed! > > with the `defxx' driver on my R4400SC TURBOchannel DECstation (but not the > R3400 one) and consequently the interface does not work anymore. Both are > non-coherent cache systems, however the R3400 implements the write-through > policy while the policy of the R4400SC is write-back (it also has 1MiB of > secondary cache), which I suspect is the reason of the difference. Doh! It would have helped if I actually had the right adapter installed in the R3400 box. I've got a spare one, which I have now plugged in there and the R3400 actually shows the same issue as the R4400SC does. So this has nothing to do WRT write-through vs write-back. Hmm, in `dfx_hw_dma_cmd_req' the driver polls the consumer block (which is write-only by the adapter and read-only by the host, except for the initialisation time before adapter's DMA engines have been started, and write-through vs write-back indeed does not matter for this kind of use) and there's no DMA synchronisation whatsoever in that. However the block has been allocated with `dma_zalloc_coherent', which means no synchronisation is supposed to be required. For non-coherent cache systems that essentially means an uncached memory allocation. Maciej