Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp844978ybh; Tue, 10 Mar 2020 09:17:27 -0700 (PDT) X-Google-Smtp-Source: ADFU+vv6u6MSeotb4vqsSx0i/CqmP/9S9w53caenmbj5o+f6aRrH2vm7vdpkN01TmUHhlIFqUA7x X-Received: by 2002:a9d:6a99:: with SMTP id l25mr10004242otq.316.1583857047382; Tue, 10 Mar 2020 09:17:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583857047; cv=none; d=google.com; s=arc-20160816; b=C4TGDt7sEXcMxvQ/mS0XQQJySMxY1MvPWKBsenQOaCO5LF0kswlEDe/L4jldg6ev4V 42Podzs+fhpqb6GYkIOBaamtweBIl2srK+YV4ge6RaMShWC2cvj29ieeOkNJ1Lca0pGV LeJEFF8tt2+ARTJbBl8QvEIuHIbmhbpIrEZGQc1U8lUZZRQQIz6c1b2JRfL8ReU97OQn 21CcBa5dp5pgKxwYtzQM0zA87T83QNZ/ri53XBG1y/fN3g7gI7X9TOw98qhd2xoiuLnl bxYAHMmfayacpCiB6FT84O9YYgiavuMuj5TniXfaGLvksKBHNa4oETOBrtrhVQepuZ/c OoHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=f4P2jqxepK2YvD5xLyqQNP9TsLKKzrGfiH32ZffxMSM=; b=I3I0r52s0U1fk3iuA6zawWDv4bU+ynS+ufvKmXQXHFCaxdjWwco/HmD2IQWfcfs0FV duqvJ4mzGZX0v0vo9AQRcxFE/TtEdFRHvv+qL/0alfQ5Rd+ilSCYThn3MTxyzlFaOUsW Fc1vfNayWAtcOwEs25UnsxJgsTHU+mlK1dSne5MvASUBwR3Jx6uMkxaVaqjTTro9PmXt 7OsJdbm8pDbYpqRcAXWlR1iPNW3GiLQ5JsNsBeOlx5H4eUnSlSbGuYEdZbuM4EmrtgCU Up5QGjY/Gi9zZETwa1JaSLlJMxj1ivKDr6izJ0Z4uqyZRYMXYB6M8LX4Z84GZiMZbYON 9Uxw== 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 y9si3394196oia.47.2020.03.10.09.17.14; Tue, 10 Mar 2020 09:17:27 -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 S1727050AbgCJQQT (ORCPT + 99 others); Tue, 10 Mar 2020 12:16:19 -0400 Received: from foss.arm.com ([217.140.110.172]:39112 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726395AbgCJQQS (ORCPT ); Tue, 10 Mar 2020 12:16:18 -0400 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 5FF9F1FB; Tue, 10 Mar 2020 09:16:18 -0700 (PDT) Received: from [10.1.196.37] (e121345-lin.cambridge.arm.com [10.1.196.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C81913F67D; Tue, 10 Mar 2020 09:16:16 -0700 (PDT) Subject: Re: [PATCH] ARM: dts: dra7: Add bus_dma_limit for L3 bus To: Tony Lindgren , Tero Kristo Cc: Roger Quadros , hch@lst.de, robh+dt@kernel.org, nm@ti.com, nsekhar@ti.com, linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200310115309.31354-1-rogerq@ti.com> <20200310154829.GS37466@atomide.com> From: Robin Murphy Message-ID: Date: Tue, 10 Mar 2020 16:16:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200310154829.GS37466@atomide.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/03/2020 3:48 pm, Tony Lindgren wrote: > * Tero Kristo [200310 14:46]: >> On 10/03/2020 13:53, Roger Quadros wrote: >>> The L3 interconnect can access only 32-bits of address. >>> Add the dma-ranges property to reflect this limit. >>> >>> This will ensure that no device under L3 is >>> given > 32-bit address for DMA. >>> >>> Issue was observed only with SATA on DRA7-EVM with 4GB RAM >>> and CONFIG_ARM_LPAE enabled. This is because the controller >>> can perform 64-bit DMA and was setting the dma_mask to 64-bit. >>> >>> Setting the correct bus_dma_limit fixes the issue. >> >> This seems kind of messy to modify almost every DT node because of this.... >> Are you sure this is the only way to get it done? No way to modify the sata >> node only which is impacted somehow? >> >> Also, what if you just pass 0xffffffff to the dma-ranges property? That >> would avoid modifying every node I guess. > > Also, I think these interconnects are not limited to 32-bit access. > So yeah I too would prefer a top level dma-ranges property assuming > that works. > > I guess there dma-ranges should not be 0xffffffff though if > limited to 2GB :) It should work fine to just describe the Q3 and Q4 DDR regions as the DMA range, i.e.: ocp { ... dma-ranges = <0x80000000 0 0x80000000 0x80000000>; ... }; That would certainly be far less invasive :) Robin.