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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 1FB19C432C2 for ; Thu, 26 Sep 2019 11:21:08 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E6D4A21A4A for ; Thu, 26 Sep 2019 11:21:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="F8GfhZf9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6D4A21A4A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GlGeXN8gHfg1Ozk6sjanLga50kqBZIQmO+lPvkiQSaQ=; b=F8GfhZf97RK704NOmIqhMzKjg pGqZjqz7CiVV6gyYYRwhsMs6cu2x87JD1BIxXytCr5KZBHQl8mFkwWhqRZDxnvmFp1zZ+XvYGmiR4 F6+0Tv11M0+YHdxKlYtPPch+CZrQpbnFV1BY1hTg4zMODXOouHxz5FLgY9tEHWRT9m2D3Ld1kIy2W 7SRh8uDHpW/oz3HSPm3vFACTzqZwEYJueq34FWQ+xm4Iq/Ru1V1Chpa++xqOQjLWNYqcI4LrK+eq0 W7aaHwELnjiiYKHrtTgmhHWD3yUvtF1kauMYelXz56KkmACd1ZtUQpjZwv7Ec6VkdBiCKg1543ybE iv7Laxm0A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDRpS-0006KA-Sr; Thu, 26 Sep 2019 11:20:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDRpP-0006Il-VX for linux-arm-kernel@lists.infradead.org; Thu, 26 Sep 2019 11:20:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9053B142F; Thu, 26 Sep 2019 04:20:53 -0700 (PDT) Received: from [192.168.1.124] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A8D1D3F67D; Thu, 26 Sep 2019 04:20:50 -0700 (PDT) Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters To: Nicolas Saenz Julienne , Rob Herring References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> From: Robin Murphy Message-ID: Date: Thu, 26 Sep 2019 12:20:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190926_042056_098779_2044ADF4 X-CRM114-Status: GOOD ( 20.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Matthias Brugger , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org, Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , xen-devel@lists.xenproject.org, Dan Williams , freedreno , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2019-09-26 11:44 am, Nicolas Saenz Julienne wrote: >>>>> Robin, have you looked into supporting multiple dma-ranges? It's the >>>>> next thing >>>>> we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in >>>>> the >>>>> works already. >>>> >>>> Multiple dma-ranges as far as configuring inbound windows should work >>>> already other than the bug when there's any parent translation. But if >>>> you mean supporting multiple DMA offsets and masks per device in the >>>> DMA API, there's nothing in the works yet. > > Sorry, I meant supporting multiple DMA offsets[1]. I think I could still make > it with a single DMA mask though. The main problem for supporting that case in general is the disgusting carving up of the physical memory map you may have to do to guarantee that a single buffer allocation cannot ever span two windows with different offsets. I don't think we ever reached a conclusion on whether that was even achievable in practice. >>> There's also the in-between step of making of_dma_get_range() return a >>> size based on all the dma-ranges entries rather than only the first one >>> - otherwise, something like [1] can lead to pretty unworkable default >>> masks. We implemented that when doing acpi_dma_get_range(), it's just >>> that the OF counterpart never caught up. >> >> Right. I suppose we assume any holes in the ranges are addressable by >> the device but won't get used for other reasons (such as no memory >> there). However, to be correct, the range of the dma offset plus mask >> would need to be within the min start and max end addresses. IOW, >> while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next >> power of 2, the 'correct' thing to do is round down. > > IIUC I also have this issue on my list. The RPi4 PCIe block has an integration > bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0000 > you get a 32bit DMA mask wich is not what you need. So far I faked it in the > device-tree but I guess it be better to add an extra check in > of_dma_configure(), decrease the mask and print some kind of warning stating > that DMA addressing is suboptimal. Yeah, there's just no way for masks to describe that the device can drive all the individual bits, just not in certain combinations :( The plan I have sketched out there is to merge dma_pfn_offset and bus_dma_mask into a "DMA range" descriptor, so we can then hang one or more of those off a device to properly cope with all these weird interconnects. Conceptually it feels pretty straightforward; I think most of the challenge is in implementing it efficiently. Plus there's the question of whether it could also subsume the dma_mask as well. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel