From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82A1A27CCE0 for ; Fri, 28 Nov 2025 14:50:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764341411; cv=none; b=qSPO1grv5Os2QNfaQJ4QVFUxmf+lAMp5PJaj5H8TIig3riMpbIpU2vNK4u8TZCzFZqLGeL6L1s8rS6fmhJ4Xx+PTn8adhIfGB0eZHDygJWbFgn2yRa9CdG25I93sMYyI3P8hoPdufT4bP6rl2m2feBKg32+IGyI4jjiwah4O1sA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764341411; c=relaxed/simple; bh=nTkbVvpUtjAIHCBonM33WYaWtmIemiIMbxDkrx+Twqk=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=G+L7D7NDvIbOBKnxEG+dhUe26MTERH4vewTg8d+fd2t3+whELBx0FQx37EjB6QnBMwrSlaV/Xnb5HQPb2NLJTK1q70bK+orVwKCpr4UGiKIU0DpzJfIW2u9qaL85fhROyo8fx1vj+i/WbG170VXNGnAddrk7ZNn3ZZasPB4K0ZM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=marek.ca; spf=pass smtp.mailfrom=marek.ca; dkim=pass (2048-bit key) header.d=marek.ca header.i=@marek.ca header.b=f3TSc92r; arc=none smtp.client-ip=209.85.160.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=marek.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=marek.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=marek.ca header.i=@marek.ca header.b="f3TSc92r" Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-4edaf8773c4so22715331cf.1 for ; Fri, 28 Nov 2025 06:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marek.ca; s=google; t=1764341408; x=1764946208; darn=vger.kernel.org; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject:from:to:cc :subject:date:message-id:reply-to; bh=HpfAFQMp1xHMgOgHhrR5E+/fQJMd6mYb+jU9coTyvY8=; b=f3TSc92rkdX6eYHM3NRYrVUZIQFi9MbOvLz7OufLVNEiRH4mLXlXFxCwDvzhcNRD+c GfoGhsiuF93IBDnKMSXUBShAATJBkRX63/xm5ddmsKzhLnoq0OvXkzaQQrhgmGxdjl2E L6SajQTCR5KE7HYUA7/v/4Bg03yHHCZbYOlVlve6vAhRWn2o1ufHZeTzMQ99gdo5hYcc VC4fnaZEiQfWfoTB1l97OH1KsZp4W0YD7qeMGMYm6YKsW4oYSa3EYJ45cO5vaT8m3hdL esUTzMt9WrY019xnsRfx7B4hVw7EEdplEokMdEYL46HkwV2LeyIhomSjIxZ6bhxmI4cG taGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764341408; x=1764946208; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HpfAFQMp1xHMgOgHhrR5E+/fQJMd6mYb+jU9coTyvY8=; b=JCHNdC3XG2nynlCT7V7fm/L4cETseiQnnk+WDR5jIG+obInMJbxZIrvvmySLCwS71u /FX1QLc1Q78gEbKzFt0/pS9CgT8g3NBaEIjTd8vtjuo0T48/yN0nY8XYVQFGuBI7iPfl f8pLVRXRgSwPasrJDchId4cJuuvDl2cgW/x214ep5M+XPot3v45u4lm+nwUjxqvF906L VGnuMjW1Ph5v/XD2fhAsGokCrdmAgvlESoebyNKufx0jhA2wkauJYR7cZ5mig0g2ZZC9 1m0lbpyfGtUXgzid6+0pQeKuRsr9trButy4G73Ejysy8wI7tTuaW5gBtG39ZQFepkNHC ZOCQ== X-Forwarded-Encrypted: i=1; AJvYcCVYJL0OEWqYKQiTPUIsQhJ0dq2nzHnZAaP1nPPNqAV43YPsxwqcrugjDdMP7FHe2j5TuSY//Lljsz3rvfc=@vger.kernel.org X-Gm-Message-State: AOJu0YxH4BwmITv9SJd9EovywX03LoyBIoIeR8ve8/XlJ/Zb0NfX+bcN C9vF8MRYo0oszpp/oPxiiJAJYwj7h+Jx2HHt2rjI9uKEHJpIJw8I0vV8H3hpXn3L41BW5/SxDoh 8Cy8Y X-Gm-Gg: ASbGncsZTQep/plvSGAc8GP/PaypirkMKGGAb/bEPXvdrlfLZ5lVg4Uym+CiZHRzbDb h9y3ZZNElTFi7rxsLV2ONeyY7YpjeOGYVgZyb+FciEnqFsQZuasFIndXvGdAdbY+0QGNJhgKUXG b3Dj3d+aHtUDWBCcffinVMyMrNLfe7PBEMT81uOFZ2UPPRsDM7rm2PQJXmLPd79ZgqfYQMXz8VX 1uKueHfeooCfOJPygBl3PTPXBsJSyC8ov9zYXRnXZwg4AGzM9pkBeciJH9RgNcf4ufK1LctTGmR 58vJbF6SpOHqXC3u7eEsrPqL44tds1/JgZPtrDHUV5N9O2gLVPjylL+teOZYfgwGm2rZfvaMjZk I4f353XIhGv0zgOLyek0eNswg2VlHlXLTj0xWP217+jFvPvpCSwRUrVjNFN8Stbs16jEcCSuABh 1UIAMlVA4kWQYjcGvwjlhGNc2ZIod6Na+h+aYoFErb9i0tFDIFalPkLnTo3w== X-Google-Smtp-Source: AGHT+IEGpjV3bSnYDTTWhr58JDFbUqpfq94fzqL86V2vpJeh6MsJfw9tDhQWpWylfqV/kNO8QyYE8A== X-Received: by 2002:ac8:5889:0:b0:4ed:6324:f53f with SMTP id d75a77b69052e-4ee58ad4ea2mr422901721cf.39.1764341407930; Fri, 28 Nov 2025 06:50:07 -0800 (PST) Received: from [192.168.0.189] (modemcable125.110-19-135.mc.videotron.ca. [135.19.110.125]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4efd3444557sm26556521cf.30.2025.11.28.06.50.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Nov 2025 06:50:07 -0800 (PST) Subject: Re: [PATCH] arm64: dts: qcom: x1e: bus is 40-bits (fix 64GB models) To: Konrad Dybcio , Stephan Gerhold Cc: linux-arm-msm@vger.kernel.org, Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sibi Sankar , Abel Vesa , Rajendra Nayak , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list References: <20251127212943.24480-1-jonathan@marek.ca> <1f2c4e5b-2d7d-41cd-9772-374e3de46a50@oss.qualcomm.com> From: Jonathan Marek Message-ID: <45bee524-d960-5b24-83bd-4dfb3e78fb1d@marek.ca> Date: Fri, 28 Nov 2025 09:49:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <1f2c4e5b-2d7d-41cd-9772-374e3de46a50@oss.qualcomm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/28/25 5:52 AM, Konrad Dybcio wrote: > On 11/28/25 11:26 AM, Stephan Gerhold wrote: >> On Thu, Nov 27, 2025 at 04:29:42PM -0500, Jonathan Marek wrote: >>> Unlike the phone SoCs this was copied from, x1e has a 40-bit physical bus. >>> The upper address space is used to support more than 32GB of memory. >>> >>> This fixes issues when DMA buffers are allocated outside the 36-bit range. >>> >>> Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") >>> Signed-off-by: Jonathan Marek >>> --- >>> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi >>> index cff34d1c74b60..cd34ce5dfd63a 100644 >>> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi >>> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi >>> @@ -792,8 +792,8 @@ soc: soc@0 { >>> >>> #address-cells = <2>; >>> #size-cells = <2>; >>> - dma-ranges = <0 0 0 0 0x10 0>; >>> - ranges = <0 0 0 0 0x10 0>; >>> + dma-ranges = <0 0 0 0 0x100 0>; >>> + ranges = <0 0 0 0 0x100 0>; >>> >> >> Could you clarify which "issues" (crashes?) you are referring to? >> >> We need to distinguish two distinct use cases here, which are both >> (somewhat) supported upstream: Running in EL1 with the Gunyah hypervisor >> with the regular DTB and in EL2 with the x1-el2.dtbo applied. >> >> # EL2 with x1-el2.dtbo >> >> For EL2, I think the 40-bit dma-ranges should indeed work correctly, so >> we could add your proposed change inside x1-el2.dtso. I'm not sure which >> issues we are fixing with that though (besides correctness of the >> hardware description). In EL2, all DMA devices should be behind an >> IOMMU. In this case, the dma-ranges limit the size of the I/O virtual >> addresses (DMA addresses) that are given to the devices. The IOMMU maps >> the DMA buffers to arbitrary physical memory addresses (including >> outside of the 36-bit range, dma-ranges limits only the DMA address). > > I've been carrying something similar in my working tree for quite > some time too.. The USB4 PCIe controllers have BAR spaces in the >36b > region, so this will be necessary anyway. > > As for the broken-firmware laptops, there's only so much we can do. > A fix for this has been *long* released, but it's up to the OEMs to > pull it in. > > > I'm not fully sure, but I think certain subsystems still have the 36b > address limitation (camera?), so it would be good to know whether that > needs to be accounted for > > Konrad > Most devices only support 32-bit address space, and use a 32-bit DMA mask (which is the default, I think?) to only get 32-bit virtual addresses. Camera driver can set a 36-bit DMA mask if it wants to use its whole range. This patch is about the physical addresses, not virtual. Every device can access the full range (without this, the iommu dma driver thinks buffers with physical addresses outside 36-bit range are not accessible, and tries to use bounce buffers)