From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f48.google.com (mail-yx1-f48.google.com [74.125.224.48]) (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 9F86F1A6820 for ; Sat, 14 Mar 2026 14:13:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773497587; cv=none; b=qVg8bearAAOxfwowRtHSsM2hNX9uAJblPY20bI4aifJYDtJHuh2L6K8ijYrXVO1c0G5GPFf92i+KOhknWEyUh68UCpQSsWgHVX2oBILMwtVIK7+4aQn3Ip6enFqsB8hUz4y5HhXQutCnQqm4NVBpUgngYOqlOJ/E+8REfG40W2A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773497587; c=relaxed/simple; bh=dZfizOLvEhwTGQ+F1IZsC1RT3jKpyEuuiwgZF0wBGpw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=c2AZoMa8XUIb2bURn5V7xWX3z6Wj0eQNemN+/UIbKQ82IWyDr1vtyuZYHx2V74acJnysOYKEo3KxpgHPERNsq1W1qxtReq3FCshT/VtOQiWW2UJaL6RNtbyJE4uZj9tgV/0++5kxFviLpPe64OH0EcoTAbrJ82xiAX53rU259Sg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=J8RGHIj/; arc=none smtp.client-ip=74.125.224.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="J8RGHIj/" Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-64ca4dfdd88so3290243d50.0 for ; Sat, 14 Mar 2026 07:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1773497584; x=1774102384; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kb1CjrStBIIzJ9sGHwsiJsF+p3lIqo/Alx3Y+vVcnNg=; b=J8RGHIj/94YtEwXO0rRsU6IggjEFfmpk7B4pqVMWqz+nk8bGyvUxKfKDJhhXIQD016 tW+aZgloO6X5HcZ9A12EYuML1TUduL3iC9UXb/1NUrvWLP74Qh+viV6mzR+w6NqxjAMu zj91TTJmJQcpeLXbClAMeC759BB8t0pjCZU1aJDGN94XIYogR8nWQZtwhgTCvc1JAzwc ANziwIgKH9cjKB6LOhM27OoH7VID7j3qaDVXpBvTl3LLLwEEDlmZk2GhgpSJXZeMpq84 I0XAyzxPisULtsWmbtP1luwQuXaM5WamVU+2fuqyoAUuEIgoqiwdSTmWcha+cTbuIZZU bPTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773497585; x=1774102385; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kb1CjrStBIIzJ9sGHwsiJsF+p3lIqo/Alx3Y+vVcnNg=; b=s8wG3xn8xJr5ypU35WZNC+LAUfwKCIPhU1dXeBmdL9znkZ2d+YOtPwoeubSyDjpzD7 nPCPfUXxC9MmZqKV8NA1ogCumzNzfGAFo35GgyHswnaRhNgxKnoE81frKlG1SRwYQAP5 d7zCrWo0XcHjIczXz+zk6afjG+GvZ3UAaoXeeY2qwsMeo5p1EatE+efXA0mg55BjM/jw CJNaEuSNETYr7fVUy+FelHen1k+LEm43udZqVykmMSl+SW7loKTYZP0g/QyusIh/kGRY awb2jWY1fuR6OdswrCxqBh14nfY4rJYK95D5FvRwZ8u3prye1mSXWlV9/xXJwQOIMBw6 9cwQ== X-Forwarded-Encrypted: i=1; AJvYcCWQEynfo3qmXCDZUv9+zwKPoypBY3qtjVv/X+9+HWA1jNgYMq1FF2CYqtPHCDGzGWNfcnw6ewiJzqJC9Cg=@vger.kernel.org X-Gm-Message-State: AOJu0YydzkyL5pwQe2UlH+4dFGbdLXvajOVAKpPytSmOxjWnR4zhpZFm 4zog0PqrT7dPvXsT9SOI5nClWTZy3/ARx/pMoFdTRina2HR2sFy/UfUAJKHE/4XqCs4= X-Gm-Gg: ATEYQzwRo5vsjZcgbxydzlFrnDnGsuX5p+Xw/Vf73Um5yqDbWe43d1FB7XdzIREuGO5 5rWhvvG+Y586FdGAc8VqeH8fynQArHln/ptXLCFnGLc2ALpA5e0rxZLzxZHD7ADd5wJpyJkYPCb 8r1Ex0RF6uwrnKLYvBOFuV1/KmkqDk7+Gih4kfmESy3dKI6aseDnvXOmSbbG96V4iLQT6h4UT7S 1KochVmgF2mnMXLjEwguyoOf0VRyImX510zDQUnBlH+C1n3WOPz0BAXReIdCVDni/ufQNNUmReT KOEcNxaK2n6ZXKDLU/Y0ucjCutf7EGsHvVwdhuZHF9ap1dxBzCvVV7TbwGsGV7D7iNvuqp/nJHk kobXnC7oc6QTeth0ddMIiN9tsVkclUZFhYMXiq3W92/dcRwXqWNeg4zbx2VmPWiz0cHZVRcyeSn TKyZ2NkWjb3UkzvHmnJqmD+GVoLkZqlOnnEWSrrRb78uu+4t44Qxs= X-Received: by 2002:a53:ee65:0:b0:64d:6193:a752 with SMTP id 956f58d0204a3-64e62fc1f7amr5251930d50.28.1773497584611; Sat, 14 Mar 2026 07:13:04 -0700 (PDT) Received: from [100.64.0.1] ([170.85.103.33]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-64e65b39f56sm2709456d50.15.2026.03.14.07.13.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Mar 2026 07:13:04 -0700 (PDT) Message-ID: Date: Sat, 14 Mar 2026 09:13:03 -0500 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 1/4] riscv: dts: spacemit: k3: add clock tree To: Yixun Lan Cc: devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, spacemit@lists.linux.dev, linux-kernel@vger.kernel.org, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti References: <20260304-01-dts-uart-full-v1-0-50a0aa53a245@kernel.org> <20260304-01-dts-uart-full-v1-1-50a0aa53a245@kernel.org> <20260314085252-GKB415778@kernel.org> From: Samuel Holland Content-Language: en-US In-Reply-To: <20260314085252-GKB415778@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Yixun, On 2026-03-14 3:52 AM, Yixun Lan wrote: > On 20:44 Fri 13 Mar , Samuel Holland wrote: >> On 2026-03-04 1:36 AM, Yixun Lan wrote: >>> Add clock support to SpacemiT K3 SoC, the clock tree consist of several >>> blocks which are APBC, APMU, DCIU, MPUM. >>> >>> Signed-off-by: Yixun Lan >>> --- >>> arch/riscv/boot/dts/spacemit/k3.dtsi | 75 ++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 75 insertions(+) >>> >>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi >>> index b69cf81b5d55..e3d7f3102fd5 100644 >>> --- a/arch/riscv/boot/dts/spacemit/k3.dtsi >>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi >>> @@ -4,6 +4,7 @@ >>> * Copyright (c) 2026 Guodong Xu >>> */ >>> >>> +#include >>> #include >>> >>> /dts-v1/; >>> @@ -398,6 +399,36 @@ core3 { >>> }; >>> }; >>> >>> + clocks { >>> + vctcxo_1m: clock-1m { >>> + compatible = "fixed-clock"; >>> + clock-frequency = <1000000>; >>> + clock-output-names = "vctcxo_1m"; >>> + #clock-cells = <0>; >>> + }; >>> + >>> + vctcxo_24m: clock-24m { >>> + compatible = "fixed-clock"; >>> + clock-frequency = <24000000>; >>> + clock-output-names = "vctcxo_24m"; >>> + #clock-cells = <0>; >>> + }; >>> + >>> + vctcxo_3m: clock-3m { >>> + compatible = "fixed-clock"; >>> + clock-frequency = <3000000>; >>> + clock-output-names = "vctcxo_3m"; >>> + #clock-cells = <0>; >>> + }; >>> + >>> + osc_32k: clock-32k { >>> + compatible = "fixed-clock"; >>> + clock-frequency = <32000>; >>> + clock-output-names = "osc_32k"; >>> + #clock-cells = <0>; >>> + }; >> >> Are these clocks provided by SoC or by the board? Usually there's a crystal >> external to the SoC that provides the root of the clock tree. If these clocks >> are provided by the board, they (or at least the clock-frequency property) >> should be in the board DT, not the SoC dtsi. >> > It's true, as a quick check, osc_32k provided by P1 PMU, while vctcxo_24m is > a crystal, vctcxo_1m and vctcxo_3m are also marked as external in the clock > tree, but I would confirm them later.. In that case, osc_32k should ideally be a reference to the P1 PMU clock provider, not a fixed-clock. But this may be infeasible if it creates dependency loops (PMU depends on I2C, I2C depends on clocks, clocks depend on PMU). > I agree to move them out of SoC dtsi file - k3.dtsi, while due to all boards share > the same clock topology, what if I creating a k3-clock.dtsi and making it shared > between all board dts file? to avoid massive DTS duplication Yes, it is common practice to create a .dtsi file for things shared among several boards for a SoC (for example if they are all based on a reference platform). You may want to name it something more generic if more than just clocks can be shared (like k3-common.dtsi, compare jh7110-common.dtsi). >> Also, the /clocks node is out of order. >> > I will move osc_32k before vtccxo_1m, assuming it's the problem you > refered to? I mean that /clocks sorts alphabetically before /cpus. Your ordering of the fixed-clocks nodes themselves is fine. Regards, Samuel