Message ID | 598b1026fdf9989bc48e5e10d1034b37947d3b80.1705388518.git.unicorn_wang@outlook.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-27063-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:42cf:b0:101:a8e8:374 with SMTP id q15csp97166dye; Mon, 15 Jan 2024 23:21:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IHcPXmAU/3K13n1P4AuPl0xSxqMxUWK75rvTo1AMBashypy07laEpDpo9oQ2kQOklkyzDwy X-Received: by 2002:a05:6358:3e52:b0:175:611a:8e94 with SMTP id k18-20020a0563583e5200b00175611a8e94mr8012829rwd.55.1705389699269; Mon, 15 Jan 2024 23:21:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705389699; cv=none; d=google.com; s=arc-20160816; b=elHExOPpVvxXXclHifiA8eTXbrY1KSbD9jogEir03qBWMlJ5ymwreKpOg4pH+rg1pg 3caJowaAVCstzhnpPL0ar/h2uCU4wCkvrPizLCP7fS1r2pwzEi/tFOocNs7Ahniqqxxi /mroEDHgN4J1zHzlV12Mr9gpyP/mfMVw3qJd4ibB7JZsLgDDgVNgHgmv1jjEFRvTt0CT T8NwoEkdz9IltfWjlubh4E8VB56VNHRd4BoG/Njdkfj2fcldAnOf5ug6okR82RgmYZ1H ZIOQ+MzMzeEBSxaSv6/5sCLMEs9jkth259ESNJlgzvjZwev0pxgMmfK/CQoQMA6dBLp3 qcHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=VXfVxRdbpg0Jjrtfyh2r9z1d0R31xJqLPqzwKtIlUvk=; fh=KH8xm6lWnQmjdwi1VtR18ptPhMUvoKU3JPF7cI3jXZo=; b=dPjLcKhqcnD4o+2sLGqPl9ApYjA1z6wDPDunKKIC4cruneQpW14cWJQTw9IscdI5Ql NUhPi4zsF+5PzCE7KdIKvsuxnXPEKJRPuo6+8/Ss4NbUHCULezU8THLk5JN2jaLg13i9 lDDYfcTF9gDVKLdR6mlmNTa3B6lHH8hzXYgfxLY2AknCz2ax/YFx9vXcdle+kDWM51RE pD/kW/8WSdHXz/9RE3dtOR5Qmx0oOxFlA0zcXtjowgp6zCEwCy/C+nkWHCTvAhjXoXHs LDYhfaFTRX/PreIf2CsPCF3FrgT5mzo5cn0VIIL6AcFU+syNw3qUeqFQGi1H3BjoQpqJ 2GuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=mRBJXYKB; spf=pass (google.com: domain of linux-kernel+bounces-27063-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-27063-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id z13-20020aa7888d000000b006d9a572baeesi10530597pfe.165.2024.01.15.23.21.38 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 23:21:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-27063-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=mRBJXYKB; spf=pass (google.com: domain of linux-kernel+bounces-27063-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-27063-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 4CE8BB22A7F for <ouuuleilei@gmail.com>; Tue, 16 Jan 2024 07:21:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6D6F61119B; Tue, 16 Jan 2024 07:21:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mRBJXYKB" Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) (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 818EB10A21; Tue, 16 Jan 2024 07:21:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-207f801a0a4so1312129fac.1; Mon, 15 Jan 2024 23:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705389683; x=1705994483; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=VXfVxRdbpg0Jjrtfyh2r9z1d0R31xJqLPqzwKtIlUvk=; b=mRBJXYKBzQMVxgFm4n1QuCw6BKYYhmaNZAUBuEMmo3HG3nNG0sT/FdFXIGX2r/587z /Lhjxo51hvUF2QiceIHLS+7ZDcZtuKFc3/DVeNdgbvxQ6BXlC1eZuc/SDAT8PGkkVE8m wHzwOQYfP8MS6vNClyPfHTsMXYEiS/pl5kPPlDFV+jBb51bOzSDqntkP2IU3RTGT3fPc 6ca5/ViG+CgdLJFDGaytMjzrjHsuglIPmUH15P0IAUGONOjW8KcJoSILtcjM7axPFVmJ pRW9/55LGKZcxQD2QXrUjJuOCLe5UaY4yyBVwdU916ymSJjCvj2TBQ5TSwOrj3qJERuB 0XHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705389683; x=1705994483; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VXfVxRdbpg0Jjrtfyh2r9z1d0R31xJqLPqzwKtIlUvk=; b=K0SiCkN0uy5X38XIlLE0z2muZxu1rbjFBCFHX6M34zH9BHuo1KhvEK3AyeEy2szDM1 ZIT/ewFGUZZP05x2YRZm0SEEy4xHJkS+bBP0hWbG1Tvf3WCtvyANjAsfjS7rtLpHb8Dg tG4djJChhXqMJhyN9GbTC+8r3KlaaOi7soNGcloNePTkRkUQnyb18A+JpUjzuuYQ521l 7uD3yqJrGQUxKTKoFY6tYlsZwh3NqGrvzIj8SB7XTMxYaEJgeLzOFNdg6Nsb2btGcciS 9t1CMqVK0OWQdUIXwthjua/rDApLFCakxLfmjli7uMeQpj3M9fjVAhxdsn+EOtRqyHfa te3A== X-Gm-Message-State: AOJu0Yz+yLfKiEKGGl4oRqdSEwWYnfEhbu7yhGkEfYGXU2MdxwABXttB N7wZ3Lt7t5VbWCEMPZRzGuI= X-Received: by 2002:a05:6870:a10d:b0:203:e9cc:486e with SMTP id m13-20020a056870a10d00b00203e9cc486emr8835946oae.107.1705389683421; Mon, 15 Jan 2024 23:21:23 -0800 (PST) Received: from localhost.localdomain ([122.8.183.87]) by smtp.gmail.com with ESMTPSA id ds13-20020a0568306c0d00b006e0c65ba0b4sm253289otb.13.2024.01.15.23.21.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 23:21:23 -0800 (PST) From: Chen Wang <unicornxw@gmail.com> To: aou@eecs.berkeley.edu, chao.wei@sophgo.com, conor@kernel.org, krzysztof.kozlowski+dt@linaro.org, mturquette@baylibre.com, palmer@dabbelt.com, paul.walmsley@sifive.com, richardcochran@gmail.com, robh+dt@kernel.org, sboyd@kernel.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, haijiao.liu@sophgo.com, xiaoguang.xing@sophgo.com, guoren@kernel.org, jszhang@kernel.org, inochiama@outlook.com, samuel.holland@sifive.com Cc: Chen Wang <unicorn_wang@outlook.com> Subject: [PATCH v8 2/5] dt-bindings: soc: sophgo: Add Sophgo system control module Date: Tue, 16 Jan 2024 15:21:15 +0800 Message-Id: <598b1026fdf9989bc48e5e10d1034b37947d3b80.1705388518.git.unicorn_wang@outlook.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <cover.1705388518.git.unicorn_wang@outlook.com> References: <cover.1705388518.git.unicorn_wang@outlook.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788230709219418748 X-GMAIL-MSGID: 1788230709219418748 |
Series |
None
|
|
Commit Message
Chen Wang
Jan. 16, 2024, 7:21 a.m. UTC
From: Chen Wang <unicorn_wang@outlook.com> Add documentation to describe Sophgo System Control for SG2042. Signed-off-by: Chen Wang <unicorn_wang@outlook.com> --- .../soc/sophgo/sophgo,sg2042-sysctrl.yaml | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml
Comments
On 16/01/2024 08:21, Chen Wang wrote: > From: Chen Wang <unicorn_wang@outlook.com> > > Add documentation to describe Sophgo System Control for SG2042. > > Signed-off-by: Chen Wang <unicorn_wang@outlook.com> > --- > .../soc/sophgo/sophgo,sg2042-sysctrl.yaml | 46 +++++++++++++++++++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml > > diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml > new file mode 100644 > index 000000000000..7b50bb56b4cf > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml > @@ -0,0 +1,46 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Sophgo SG2042 SoC system control > + > +maintainers: > + - Chen Wang <unicorn_wang@outlook.com> > + > +description: > + The Sophgo system control is a registers block (SYS_CTRL), providing multiple > + low level platform functions like chip configuration, clock control, etc. > + > +properties: > + compatible: > + const: sophgo,sg2042-sysctrl > + > + reg: > + maxItems: 1 > + > + clock-controller: > + # Child node Drop the comment, it is obvious. It cannot be anything else. > + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# > + type: object Why isn't this merged here? You do not need the child node really... unless the clock inputs are specific to that clock controller and you will have here more devices? But where are they in such case? > + > +required: > + - compatible > + - reg > + - clock-controller > + > +additionalProperties: false > + > +examples: > + - | > + system-control@30010000 { Why did you change the name? Please provide detailed changelog with explanation of such changes. > + compatible = "sophgo,sg2042-sysctrl"; > + reg = <0x30010000 0x1000>; > + Best regards, Krzysztof
On 2024/1/16 18:06, Krzysztof Kozlowski wrote: > On 16/01/2024 08:21, Chen Wang wrote: >> From: Chen Wang <unicorn_wang@outlook.com> >> >> Add documentation to describe Sophgo System Control for SG2042. >> >> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> >> --- >> .../soc/sophgo/sophgo,sg2042-sysctrl.yaml | 46 +++++++++++++++++++ >> 1 file changed, 46 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >> >> diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >> new file mode 100644 >> index 000000000000..7b50bb56b4cf >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >> @@ -0,0 +1,46 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Sophgo SG2042 SoC system control >> + >> +maintainers: >> + - Chen Wang <unicorn_wang@outlook.com> >> + >> +description: >> + The Sophgo system control is a registers block (SYS_CTRL), providing multiple >> + low level platform functions like chip configuration, clock control, etc. >> + >> +properties: >> + compatible: >> + const: sophgo,sg2042-sysctrl >> + >> + reg: >> + maxItems: 1 >> + >> + clock-controller: >> + # Child node > Drop the comment, it is obvious. It cannot be anything else. > >> + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# >> + type: object > Why isn't this merged here? You do not need the child node really... > unless the clock inputs are specific to that clock controller and you > will have here more devices? But where are they in such case? I don't see more devices will be included later. It should be ok to merge them into one. >> + >> +required: >> + - compatible >> + - reg >> + - clock-controller >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + system-control@30010000 { > Why did you change the name? Please provide detailed changelog with > explanation of such changes. I changed the name due to I find the TRM(https://github.com/sophgo/sophgo-doc/blob/main/SG2042/TRM/source/system-control.rst) call it "system control", so I changed it in v8. Which one do you prefer? I'm not sure if there are any requirements for this? >> + compatible = "sophgo,sg2042-sysctrl"; >> + reg = <0x30010000 0x1000>; >> + > Best regards, > Krzysztof >
On 16/01/2024 12:37, Chen Wang wrote: > > On 2024/1/16 18:06, Krzysztof Kozlowski wrote: >> On 16/01/2024 08:21, Chen Wang wrote: >>> From: Chen Wang <unicorn_wang@outlook.com> >>> >>> Add documentation to describe Sophgo System Control for SG2042. >>> >>> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> >>> --- >>> .../soc/sophgo/sophgo,sg2042-sysctrl.yaml | 46 +++++++++++++++++++ >>> 1 file changed, 46 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>> new file mode 100644 >>> index 000000000000..7b50bb56b4cf >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>> @@ -0,0 +1,46 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Sophgo SG2042 SoC system control >>> + >>> +maintainers: >>> + - Chen Wang <unicorn_wang@outlook.com> >>> + >>> +description: >>> + The Sophgo system control is a registers block (SYS_CTRL), providing multiple >>> + low level platform functions like chip configuration, clock control, etc. >>> + >>> +properties: >>> + compatible: >>> + const: sophgo,sg2042-sysctrl >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + clock-controller: >>> + # Child node >> Drop the comment, it is obvious. It cannot be anything else. >> >>> + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# >>> + type: object >> Why isn't this merged here? You do not need the child node really... >> unless the clock inputs are specific to that clock controller and you >> will have here more devices? But where are they in such case? > I don't see more devices will be included later. It should be ok to > merge them into one. >>> + >>> +required: >>> + - compatible >>> + - reg >>> + - clock-controller >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + system-control@30010000 { >> Why did you change the name? Please provide detailed changelog with >> explanation of such changes. > > I changed the name due to I find the > TRM(https://github.com/sophgo/sophgo-doc/blob/main/SG2042/TRM/source/system-control.rst) > call it "system control", so I changed it in v8. > > Which one do you prefer? I'm not sure if there are any requirements for > this? Node names should be generic and follow common guidelines, not match your TRM. Please use the same name all other devices use for the same class. Best regards, Krzysztof
On 2024/1/16 19:37, Chen Wang wrote: > > On 2024/1/16 18:06, Krzysztof Kozlowski wrote: >> On 16/01/2024 08:21, Chen Wang wrote: >>> From: Chen Wang <unicorn_wang@outlook.com> >>> >>> Add documentation to describe Sophgo System Control for SG2042. >>> >>> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> >>> --- >>> .../soc/sophgo/sophgo,sg2042-sysctrl.yaml | 46 >>> +++++++++++++++++++ >>> 1 file changed, 46 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>> >>> diff --git >>> a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>> >>> new file mode 100644 >>> index 000000000000..7b50bb56b4cf >>> --- /dev/null >>> +++ >>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>> @@ -0,0 +1,46 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: >>> http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Sophgo SG2042 SoC system control >>> + >>> +maintainers: >>> + - Chen Wang <unicorn_wang@outlook.com> >>> + >>> +description: >>> + The Sophgo system control is a registers block (SYS_CTRL), >>> providing multiple >>> + low level platform functions like chip configuration, clock >>> control, etc. >>> + >>> +properties: >>> + compatible: >>> + const: sophgo,sg2042-sysctrl >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + clock-controller: >>> + # Child node >> Drop the comment, it is obvious. It cannot be anything else. >> >>> + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# >>> + type: object >> Why isn't this merged here? You do not need the child node really... >> unless the clock inputs are specific to that clock controller and you >> will have here more devices? But where are they in such case? > I don't see more devices will be included later. It should be ok to > merge them into one. hi, Krzysztof, After some double check, I find we will have more devices in system-control. For example, in the SYS_CTRL area, there is also a section of registers used to control the "General Purpose Interrupt". The pcie controller of sg2042 will use this interrupt controller which is defined in SYS_CTRL, we will add it in later work. Specifically, the distribution (offset) of registers in SYS_CTRL is as follows: - 0x0C0 ~ 0x0FC: for some PLL clocks : - ...... - 0x2E0 ~ 0x30C: for General Purpose Interrupt: - ...... - 0x368 ~ 0x3FC: For some gate clocks So it seems that it is still necessary to keep the current child node method, and it will also facilitate future expansion. What do you think, please feel free let me know. Thanks, Chen
On 2024/1/18 13:29, Chen Wang wrote: > > On 2024/1/16 19:37, Chen Wang wrote: >> >> On 2024/1/16 18:06, Krzysztof Kozlowski wrote: >>> On 16/01/2024 08:21, Chen Wang wrote: >>>> From: Chen Wang <unicorn_wang@outlook.com> >>>> >>>> Add documentation to describe Sophgo System Control for SG2042. >>>> >>>> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> >>>> --- >>>> .../soc/sophgo/sophgo,sg2042-sysctrl.yaml | 46 >>>> +++++++++++++++++++ >>>> 1 file changed, 46 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>> >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>> >>>> new file mode 100644 >>>> index 000000000000..7b50bb56b4cf >>>> --- /dev/null >>>> +++ >>>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>> @@ -0,0 +1,46 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: >>>> http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Sophgo SG2042 SoC system control >>>> + >>>> +maintainers: >>>> + - Chen Wang <unicorn_wang@outlook.com> >>>> + >>>> +description: >>>> + The Sophgo system control is a registers block (SYS_CTRL), >>>> providing multiple >>>> + low level platform functions like chip configuration, clock >>>> control, etc. >>>> + >>>> +properties: >>>> + compatible: >>>> + const: sophgo,sg2042-sysctrl >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + clock-controller: >>>> + # Child node >>> Drop the comment, it is obvious. It cannot be anything else. >>> >>>> + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# >>>> + type: object >>> Why isn't this merged here? You do not need the child node really... >>> unless the clock inputs are specific to that clock controller and you >>> will have here more devices? But where are they in such case? >> I don't see more devices will be included later. It should be ok to >> merge them into one. > > hi, Krzysztof, > > After some double check, I find we will have more devices in > system-control. For example, in the SYS_CTRL area, there is also a > section of registers used to control the "General Purpose Interrupt". > The pcie controller of sg2042 will use this interrupt controller which > is defined in SYS_CTRL, we will add it in later work. > > Specifically, the distribution (offset) of registers in SYS_CTRL is as > follows: > > - 0x0C0 ~ 0x0FC: for some PLL clocks : > > - ...... > > - 0x2E0 ~ 0x30C: for General Purpose Interrupt: > > - ...... > > - 0x368 ~ 0x3FC: For some gate clocks > > So it seems that it is still necessary to keep the current child node > method, and it will also facilitate future expansion. > > What do you think, please feel free let me know. > > Thanks, > > Chen hi, Krzysztof, Can you please take a look if you have time, looking forward to your reply. Thanks, Chen > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On 18/01/2024 06:29, Chen Wang wrote: > > On 2024/1/16 19:37, Chen Wang wrote: >> >> On 2024/1/16 18:06, Krzysztof Kozlowski wrote: >>> On 16/01/2024 08:21, Chen Wang wrote: >>>> From: Chen Wang <unicorn_wang@outlook.com> >>>> >>>> Add documentation to describe Sophgo System Control for SG2042. >>>> >>>> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> >>>> --- >>>> .../soc/sophgo/sophgo,sg2042-sysctrl.yaml | 46 >>>> +++++++++++++++++++ >>>> 1 file changed, 46 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>> >>>> new file mode 100644 >>>> index 000000000000..7b50bb56b4cf >>>> --- /dev/null >>>> +++ >>>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>> @@ -0,0 +1,46 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: >>>> http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Sophgo SG2042 SoC system control >>>> + >>>> +maintainers: >>>> + - Chen Wang <unicorn_wang@outlook.com> >>>> + >>>> +description: >>>> + The Sophgo system control is a registers block (SYS_CTRL), >>>> providing multiple >>>> + low level platform functions like chip configuration, clock >>>> control, etc. >>>> + >>>> +properties: >>>> + compatible: >>>> + const: sophgo,sg2042-sysctrl >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + clock-controller: >>>> + # Child node >>> Drop the comment, it is obvious. It cannot be anything else. >>> >>>> + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# >>>> + type: object >>> Why isn't this merged here? You do not need the child node really... >>> unless the clock inputs are specific to that clock controller and you >>> will have here more devices? But where are they in such case? >> I don't see more devices will be included later. It should be ok to >> merge them into one. > > hi, Krzysztof, > > After some double check, I find we will have more devices in > system-control. For example, in the SYS_CTRL area, there is also a > section of registers used to control the "General Purpose Interrupt". > The pcie controller of sg2042 will use this interrupt controller which > is defined in SYS_CTRL, we will add it in later work. > I expect then all devices to be documented. Best regards, Krzysztof
On 2024/1/22 16:10, Krzysztof Kozlowski wrote: > On 18/01/2024 06:29, Chen Wang wrote: >> On 2024/1/16 19:37, Chen Wang wrote: >>> On 2024/1/16 18:06, Krzysztof Kozlowski wrote: >>>> On 16/01/2024 08:21, Chen Wang wrote: >>>>> From: Chen Wang <unicorn_wang@outlook.com> >>>>> >>>>> Add documentation to describe Sophgo System Control for SG2042. >>>>> >>>>> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> >>>>> --- >>>>> .../soc/sophgo/sophgo,sg2042-sysctrl.yaml | 46 >>>>> +++++++++++++++++++ >>>>> 1 file changed, 46 insertions(+) >>>>> create mode 100644 >>>>> Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>>> >>>>> diff --git >>>>> a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>>> >>>>> new file mode 100644 >>>>> index 000000000000..7b50bb56b4cf >>>>> --- /dev/null >>>>> +++ >>>>> b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml >>>>> @@ -0,0 +1,46 @@ >>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>>>> +%YAML 1.2 >>>>> +--- >>>>> +$id: >>>>> http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml# >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>> + >>>>> +title: Sophgo SG2042 SoC system control >>>>> + >>>>> +maintainers: >>>>> + - Chen Wang <unicorn_wang@outlook.com> >>>>> + >>>>> +description: >>>>> + The Sophgo system control is a registers block (SYS_CTRL), >>>>> providing multiple >>>>> + low level platform functions like chip configuration, clock >>>>> control, etc. >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + const: sophgo,sg2042-sysctrl >>>>> + >>>>> + reg: >>>>> + maxItems: 1 >>>>> + >>>>> + clock-controller: >>>>> + # Child node >>>> Drop the comment, it is obvious. It cannot be anything else. >>>> >>>>> + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# >>>>> + type: object >>>> Why isn't this merged here? You do not need the child node really... >>>> unless the clock inputs are specific to that clock controller and you >>>> will have here more devices? But where are they in such case? >>> I don't see more devices will be included later. It should be ok to >>> merge them into one. >> hi, Krzysztof, >> >> After some double check, I find we will have more devices in >> system-control. For example, in the SYS_CTRL area, there is also a >> section of registers used to control the "General Purpose Interrupt". >> The pcie controller of sg2042 will use this interrupt controller which >> is defined in SYS_CTRL, we will add it in later work. >> > I expect then all devices to be documented. hi, Krzysztof. First, I'm very sorry for having double-checked with you for this system controller and child node issue, but this time I'm sure there should be no more child nodes except the clock and interrupt controllers, though there are some other registers in SYS_CTRL section, but we will not use them till now. One question, when you say "to be documented", do you mean I need write binding/yaml files for other child node? But they exceed the scope of this patchset (this patchset is for clock support only). That's why I suggest just add clock-controller in this patchset and to add the interrupt controller in another patchset for pcie support. This mechanism should be suitable for our expansion. Thanks, Chen > > Best regards, > Krzysztof >
On 22/01/2024 11:11, Chen Wang wrote: >>>>>> + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# >>>>>> + type: object >>>>> Why isn't this merged here? You do not need the child node really... >>>>> unless the clock inputs are specific to that clock controller and you >>>>> will have here more devices? But where are they in such case? >>>> I don't see more devices will be included later. It should be ok to >>>> merge them into one. >>> hi, Krzysztof, >>> >>> After some double check, I find we will have more devices in >>> system-control. For example, in the SYS_CTRL area, there is also a >>> section of registers used to control the "General Purpose Interrupt". >>> The pcie controller of sg2042 will use this interrupt controller which >>> is defined in SYS_CTRL, we will add it in later work. >>> >> I expect then all devices to be documented. > > hi, Krzysztof. > > First, I'm very sorry for having double-checked with you for this system > controller and child node issue, but this time I'm sure there should be > no more child nodes except the clock and interrupt controllers, though > there are some other registers in SYS_CTRL section, but we will not use > them till now. > > One question, when you say "to be documented", do you mean I need write > binding/yaml files for other child node? But they exceed the scope of > this patchset (this patchset is for clock support only). That's why I That's not true. The scope of this patch is to add DT binding description for your device. If you choose any other scope, I don't agree and I am not going to provide positive review. > suggest just add clock-controller in this patchset and to add the > interrupt controller in another patchset for pcie support. This > mechanism should be suitable for our expansion. How then are you going to solve the requirement: "DO attempt to make bindings complete even"? https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L17 Best regards, Krzysztof
On 2024/1/22 20:56, Krzysztof Kozlowski wrote: > On 22/01/2024 11:11, Chen Wang wrote: >>>>>>> + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# >>>>>>> + type: object >>>>>> Why isn't this merged here? You do not need the child node really... >>>>>> unless the clock inputs are specific to that clock controller and you >>>>>> will have here more devices? But where are they in such case? >>>>> I don't see more devices will be included later. It should be ok to >>>>> merge them into one. >>>> hi, Krzysztof, >>>> >>>> After some double check, I find we will have more devices in >>>> system-control. For example, in the SYS_CTRL area, there is also a >>>> section of registers used to control the "General Purpose Interrupt". >>>> The pcie controller of sg2042 will use this interrupt controller which >>>> is defined in SYS_CTRL, we will add it in later work. >>>> >>> I expect then all devices to be documented. >> hi, Krzysztof. >> >> First, I'm very sorry for having double-checked with you for this system >> controller and child node issue, but this time I'm sure there should be >> no more child nodes except the clock and interrupt controllers, though >> there are some other registers in SYS_CTRL section, but we will not use >> them till now. >> >> One question, when you say "to be documented", do you mean I need write >> binding/yaml files for other child node? But they exceed the scope of >> this patchset (this patchset is for clock support only). That's why I > That's not true. The scope of this patch is to add DT binding > description for your device. If you choose any other scope, I don't > agree and I am not going to provide positive review. > >> suggest just add clock-controller in this patchset and to add the >> interrupt controller in another patchset for pcie support. This >> mechanism should be suitable for our expansion. > How then are you going to solve the requirement: "DO attempt to make > bindings complete even"? > > https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L17 Learned and I will try to make bindings for system-controller device complete, thanks. > > Best regards, > Krzysztof >
diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml new file mode 100644 index 000000000000..7b50bb56b4cf --- /dev/null +++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2042-sysctrl.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/sophgo/sophgo,sg2042-sysctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo SG2042 SoC system control + +maintainers: + - Chen Wang <unicorn_wang@outlook.com> + +description: + The Sophgo system control is a registers block (SYS_CTRL), providing multiple + low level platform functions like chip configuration, clock control, etc. + +properties: + compatible: + const: sophgo,sg2042-sysctrl + + reg: + maxItems: 1 + + clock-controller: + # Child node + $ref: /schemas/clock/sophgo,sg2042-sysclk.yaml# + type: object + +required: + - compatible + - reg + - clock-controller + +additionalProperties: false + +examples: + - | + system-control@30010000 { + compatible = "sophgo,sg2042-sysctrl"; + reg = <0x30010000 0x1000>; + + clock-controller { + compatible = "sophgo,sg2042-sysclk"; + clocks = <&cgi_main>, <&cgi_dpll0>, <&cgi_dpll1>; + #clock-cells = <1>; + }; + };