From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 654E62BDC30 for ; Thu, 17 Jul 2025 12:27:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752755222; cv=none; b=J13NeG3jYMNMRO+5JH3YmlykNtc4WpH93+cG3KrDaNa0ROcoo5i7f7DPIMToVlidZ+kuLJzLmrkkLlhz9G/5kioF3Jwzv4yxP2llgpZg4VnZM2VYXCEgHYlgta+lquSPx2KMVDFFk6/cZ/P3+qZ95oDTrZQU0nVP3Ob5q1s78I4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752755222; c=relaxed/simple; bh=k1AU9RHb0Kl7CzIBQsz15cpKEvQJw6GvReja3qw8EDQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SiDxPIu0cNxKfJ1nJFC5aIeHmFc172Pcj+0r42MKQQNDltoggdmTit4gkE7wVu3F62y4TGJ9kUY8MmJXp1uSm4VjtpISITNBNgRG2rkMqhUi/SGV4mKSjN+7sqZTEVfzCpu6bLMfcqxHIGb575+S6QDf1znJpbwwjnC3CkJKu54= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=TE25JG2V; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="TE25JG2V" Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 56HBjQ2X002924 for ; Thu, 17 Jul 2025 12:26:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= IbmcROfOzVtWLlLwTUK701q3d6gz5yN28T/mfJ33MIw=; b=TE25JG2VN6qQdbFI +EPMUOzIJpT9ZbN4ZIkZATeVvy4GwUPV5dCscItU/HZvCgO6zt8HQRfg2IkbcAT+ /bRkQgCwvhtEQkpUQScqWrWuB+LunPUpfuPEa9/YyBRJ5RWfX3dru0yV6Ck8UISD QAoil+qyBsfyp0uBtBYRio7QFWo2/NrN7YMfHYntO4dGtjiBDS77+iZmAJKB8y6e YY5aSsLonYn4nSw5GocPrVGB5jgSgad6gzeOGzIhTJX9yDqeuCq7Bma8SyfEsfks Qfhx/IiDic3dsw1TEgmCJWQ8dpS53t20P6vudUZXZ9KFyP8FslENwvzt4Q2JV/IZ SmDm4g== Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 47xsuksdgj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 17 Jul 2025 12:26:59 +0000 (GMT) Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6f539358795so3308596d6.3 for ; Thu, 17 Jul 2025 05:26:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752755218; x=1753360018; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IbmcROfOzVtWLlLwTUK701q3d6gz5yN28T/mfJ33MIw=; b=JZopmWF/giGz9DqJJiZBbjbILWcKjz9IR6QGFZyidBYh4zkiMBIXBPfdkmNuJJ7Ol/ ezWTUEJ9u29hI0m3u85ksNoTg5KpafaqvA3wqy+y2dGCEcaOMsMVp/tup5CJVDKSOacA 5ZXBjdPUMHB8vYVSyTiEqfb3cCy3u/FK688ySnDzK2dFmw8fonc385INaqyXoTkqyunb /7Dxd4D5dxvrDgxOc1a9hybg0qIETZc8zY7rA5NxHcjMI2PnjdBSqnSGAsu2m0wlhw1e BcquHTL7rhizW/5VnYsjBPQXWHMWmm5TBaIgfWzp70IjoB/kGTLEx9+dw9bmLlKguoCS W7Dw== X-Forwarded-Encrypted: i=1; AJvYcCVZOY9FkAqnnO3SvNg3gyvLc049nR1lQB6IEH7yrx0wbwjs1qSuXJ2DXDhPduek6boKYGlWWGbp5ksj3cM=@vger.kernel.org X-Gm-Message-State: AOJu0YxV3zD8J5RLKPNg6uD66n1VXmyKLlRrVb6kflnxdDPyfDaEVjXo uCrQiVVhCGBTehhjgys3klY8JIosGySbbOZ8EqbmyPt53dk9hdMicEQwfmUz6kirmrghAkzJbDv w1dteT2ywbXEV3zuhZtya8RodE7Rc+oslpamLLoMpBUr6k0o5f9esWIjq+hmejhb1gKo= X-Gm-Gg: ASbGnctV6GhuwhK9CQXGLDF1I5hOw6gPZDB6gv7wRbJd8YWoMw5qMreTkP0J2TpG/Lv 7s6LP+88RsbNoC8wE2LJTb/GaX+Z5iGDKwSGv4etOr/FGttjNHIdWa1yAIJI3ssEsfq+79GYtbm mUxnqoTirnoFUDYT+fJ7UlP5HUeI0Dyxi6AQqgE0PVx4GAzVoxMBpoEp+FttFG07gKOMdYm9mP9 ERMS/AZv2+NmR1qWM9a+2R2urq9VI+jEtkk/HMV1PSfYYCL0Kq5uEnwGtayFjs/QspFHxQY9Apd ljCSe8WaonwFTZA8FWZ+Bgy0XXBn+AcIw9VL9gcLExZKkuc1ypCRxE3DnXCgTOxl7Tw4OxV99pP xhmiJJ01h4dbEhBp6CP4B X-Received: by 2002:a05:620a:4093:b0:7e3:302a:3e9d with SMTP id af79cd13be357-7e342ad54e7mr401316085a.7.1752755217814; Thu, 17 Jul 2025 05:26:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEWMwBx+PyOHxTxgnaS5xzRvQae4iwC7dd8Cj0Sms6zoxQGp+IkrMAc/iJ+gLrK8J7XJbyIqA== X-Received: by 2002:a05:620a:4093:b0:7e3:302a:3e9d with SMTP id af79cd13be357-7e342ad54e7mr401311985a.7.1752755217290; Thu, 17 Jul 2025 05:26:57 -0700 (PDT) Received: from [192.168.143.225] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ae6e7ee8d9fsm1336084466b.46.2025.07.17.05.26.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jul 2025 05:26:56 -0700 (PDT) Message-ID: Date: Thu, 17 Jul 2025 14:26:52 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 14/15] arm64: dts: qcom: Add initial Milos dtsi To: Luca Weiss , Will Deacon , Robin Murphy , Joerg Roedel , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "Rafael J. Wysocki" , Viresh Kumar , Manivannan Sadhasivam , Herbert Xu , "David S. Miller" , Vinod Koul , Bjorn Andersson , Konrad Dybcio , Robert Marko , Das Srinagesh , Thomas Gleixner , Jassi Brar , Amit Kucheria , Thara Gopinath , Daniel Lezcano , Zhang Rui , Lukasz Luba , Ulf Hansson Cc: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org, linux-mmc@vger.kernel.org References: <20250713-sm7635-fp6-initial-v2-0-e8f9a789505b@fairphone.com> <20250713-sm7635-fp6-initial-v2-14-e8f9a789505b@fairphone.com> <3e0299ad-766a-4876-912e-438fe2cc856d@oss.qualcomm.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: fg2o8IscFhOpgiU_zoMZvV5l-WQu7_Vz X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNzE3MDEwOSBTYWx0ZWRfX7WRlGj3vOwjq RX/m5A+keBt3q9uEFypsWQXiY2PqQG6qp9ab9IejoL/4XD5WaxtIji3nlMRdAIo569MeklR1/2M lDEeeJmog8sQpXNUHYnyhSV9lCM13ixxHAEHYnhTR0sPX2rbQJqORdJQX+8bs4Xv2yB8L4nF1ds 0IILatmWXUtUHbpvE6ev4eLdk73gVSDPkYkaSwfEjM9eP226530JL0EKrgrijZMh/UCSscCc5QZ jmCmBxjDpXn1T9q/n/MmC38xkumA3iiLQ2JNhs9mdbrYT/DYNJgvx4bgJ2HBgWYWmtc6yDcI58U f0UbrQ+sQd9ZE3tLIwaC3Gh6zYgM7RB13f7QSkO/jcheP/Ef8rk0tdouPXnY/yfQ+hl9EFQDwGN ro6yt119G98lxNGpFlZTN5wW5fhIgb2vvESQo9bV6hzcL3gEAc1+FX1cqRdiE0+3PUnnOOej X-Proofpoint-GUID: fg2o8IscFhOpgiU_zoMZvV5l-WQu7_Vz X-Authority-Analysis: v=2.4 cv=JJk7s9Kb c=1 sm=1 tr=0 ts=6878ec13 cx=c_pps a=UgVkIMxJMSkC9lv97toC5g==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=Wb1JkmetP80A:10 a=7CQSdrXTAAAA:8 a=6H0WHjuAAAAA:8 a=iHGpd6SFZaqAm2lpoLIA:9 a=QEXdDO2ut3YA:10 a=1HOtulTD9v-eNWfpl4qZ:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=Soq9LBFxuPC4vsCAQt-j:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.1.9,FMLib:17.12.80.40 definitions=2025-07-17_01,2025-07-17_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 mlxlogscore=999 adultscore=0 clxscore=1015 malwarescore=0 bulkscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505280000 definitions=main-2507170109 On 7/17/25 10:29 AM, Luca Weiss wrote: > On Mon Jul 14, 2025 at 1:06 PM CEST, Konrad Dybcio wrote: >> On 7/13/25 10:05 AM, Luca Weiss wrote: >>> Add a devicetree description for the Milos SoC, which is for example >>> Snapdragon 7s Gen 3 (SM7635). >>> >>> Signed-off-by: Luca Weiss >>> --- [...] >> >> [...] >> >>> + cpu-map { >>> + cluster0 { >>> + core0 { >>> + cpu = <&cpu0>; >>> + }; >>> + >>> + core1 { >>> + cpu = <&cpu1>; >>> + }; >>> + >>> + core2 { >>> + cpu = <&cpu2>; >>> + }; >>> + >>> + core3 { >>> + cpu = <&cpu3>; >>> + }; >>> + }; >>> + >>> + cluster1 { >>> + core0 { >>> + cpu = <&cpu4>; >>> + }; >>> + >>> + core1 { >>> + cpu = <&cpu5>; >>> + }; >>> + >>> + core2 { >>> + cpu = <&cpu6>; >>> + }; >>> + }; >>> + >>> + cluster2 { >>> + core0 { >>> + cpu = <&cpu7>; >>> + }; >>> + }; >>> + }; >> >> I'm getting mixed information about the core topology.. >> >> What does dmesg say wrt this line? >> >> CPU%u: Booted secondary processor 0x%010lx [0x%08x]\n > > [ 0.003570] CPU1: Booted secondary processor 0x0000000100 [0x410fd801] > [ 0.004738] CPU2: Booted secondary processor 0x0000000200 [0x410fd801] > [ 0.005783] CPU3: Booted secondary processor 0x0000000300 [0x410fd801] > [ 0.007206] CPU4: Booted secondary processor 0x0000000400 [0x410fd811] > [ 0.008206] CPU5: Booted secondary processor 0x0000000500 [0x410fd811] > [ 0.009073] CPU6: Booted secondary processor 0x0000000600 [0x410fd811] > [ 0.010406] CPU7: Booted secondary processor 0x0000000700 [0x410fd811] Okay, so the cache topology that I can make out of docs matches your dt.. As for the CPU map, we tended to simply throw all cores that are in the same "DSU cluster" [1] together, represented as a single CPU cluster. This is not what other vendors do though, it seems. And downstream has the same silver/gold/prime split as you did above. Looking at some docs, it seems like the prime core shares the cache bridge with the gold cluster so I'm not sure how separate it really is. There was a time when the MIDR_EL1 register would be more helpful, but according to [2], it would mean that each core is in its own cluster.. For reference exynos2200.dtsi seems to have the very same MPIDRs (though with cores that are a little older). One would expect the small cores that share the L2 to be within the same cluster [3]. All in all, I don't know what to tell you for sure.. [1] https://developer.arm.com/documentation/100453/0401/Technical-overview/Components?lang=en [2] https://developer.arm.com/documentation/102517/0004/AArch64-registers/AArch64-Identification-registers-summary/MPIDR-EL1--Multiprocessor-Affinity-Register?lang=en [3] https://developer.arm.com/documentation/102517/0004/The-Cortex-A520--core/Cortex-A520--core-configuration-options?lang=en [...] >> Does access control disallow accessing these on your prod-fused >> device? > > Hm, taking another look, this property should probably be moved to > device dts. > > Downstream has this in volcano.dtsi but volcano6i.dtsi (QCM6690?) and > volcano6ip.dtsi (QCS6690?) have a /delete-property/ for this, because > they have PCIe available. > > I don't think this has anything to do with secure boot fuses, but I > don't think I have tried enabling these clocks on my SB-off prototype. I wouldn't be so sure about sb-off being necessarily a difference, but I wouldn't object to a smoke test either ;) [...] >>> + interrupts = , >> >> pdc 26 > > You mean replace with > <&pdc 26 IRQ_TYPE_LEVEL_HIGH> (plus interrupts-extended)? Yes > I assume you got this from internal docs, but just to mention, > volcano-thermal.dtsi contains GIC_SPI 506 (+ 507 for tsens1). Right, I found it in the docs (but we most likely want the device to wake up from sleep and try to power off if it's too hot/cold) Konrad