devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Chen <peter.chen@cixtech.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh@kernel.org>,
	krzk+dt@kernel.org, Conor Dooley <conor+dt@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, cix-kernel-upstream@cixtech.com,
	"Fugang . duan" <fugang.duan@cixtech.com>
Subject: Re: [PATCH 6/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support
Date: Mon, 24 Feb 2025 18:39:54 +0800	[thread overview]
Message-ID: <Z7xMeub9i74a_19g@nchen-desktop> (raw)
In-Reply-To: <0bd5af6c-979b-4403-b1e7-5847979a8780@kernel.org>

On 25-02-24 09:06:23, Krzysztof Kozlowski wrote:
> >> Your "in fact" is not really related to the problem described. If you
> >> put it in the correct place, drivers will work just as fine.
> >
> > You also mentioned that in your comments. Yes, indeed the board dts file
> > could remap physical controller index as different board serial number,
> > but it is not what we would like to do (at least for CIX platforms).
> > In our both HW and SW documents, we have fixed our uart usage cases,
> > for example, UART2 as AP serial ports. UART0-UART1 as uart application,eg
> > bluetooth. Customer will do their design to follow above rules, and
> > it avoids each customer writing this alias at their board file.
> 
> Follow standard rules, you don't get an exception. That's not a property
> of the SoC.

Okay. I see below documents describes it:

Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml:23:  serialN aliases should be
in a .dts file instead of in a .dtsi file.
Documentation/devicetree/usage-model.rst:327:at all.  The /chosen, /aliases, and /memory nodes are
informational

> >>>
> >>>>
> >>>>> +       sky1_fixed_clocks: fixed-clocks {
> >>>>> +               uartclk: uartclk {
> >>>>> +                       compatible = "fixed-clock";
> >>>>> +                       #clock-cells = <0>;
> >>>>> +                       clock-frequency = <100000000>;
> >>>>> +                       clock-output-names = "uartclk";
> >>>>
> >>>>> +               uart_apb_pclk: uart_apb_pclk {
> >>>>> +                       compatible = "fixed-clock";
> >>>>> +                       #clock-cells = <0>;
> >>>>> +                       clock-frequency = <200000000>;
> >>>>> +                       clock-output-names = "apb_pclk";
> >>>>
> >>>>
> >>>> Clock names don't need "clk" in them, and there should
> >>>> be no underscore -- use '-' instead of '_' when separating
> >>>> strings in DT.
> >>>
> >>> Will change to:
> >>> uart_apb: clock-uart-apb {
> >>
> >> No, instead explain why this is part of SoC - or what are you missing
> >> here - and use preferred naming.
> >
> > It is in SoC part, APB clock uses to visit register, and the function
> > amba_get_enable_pclk at file drivers/amba/bus.c needs it during uart
> > device probes. It uses common Arm uart pl011 IP, the binding doc
> > described at: Documentation/devicetree/bindings/serial/pl011.yaml
> 
> So you added fake clock? Everything you wrote is not the reason to add
> such clock.

Not a fake clock, it is the real clocks, but depends on firmware open
their parents and configure their rate. It could let others do their
upstream work based on workable console.

Which option you would like to accept?
- Option-1: use fixed clock in this initial version, and will be
replaced later. 
uart_apb: clock-200000000 {
	compatible = "fixed-clock";
	#clock-cells = <0>;
	clock-frequency = <200000000>;
	clock-output-names = "apb_pclk";
};

uart_clk: clock-200000000 {
	compatible = "fixed-clock";
	#clock-cells = <0>;
	clock-frequency = <100000000>;
	clock-output-names = "uart_clk";
};

uart2: uart@040d0000 {
	compatible = "arm,pl011", "arm,primecell";
	reg = <0x0 0x040d0000 0x0 0x1000>;
	interrupts = <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>;
	clock-names = "uartclk", "apb_pclk";
	clocks = <&uart_clk>, <&uart_apb>;
	status = "disabled";
};

- Option-2: delete the console uart node and its fixed clock.
In that way, the user could boot the kernel at orion-o6 board,
but could not use its console.

-- 

Best regards,
Peter

  reply	other threads:[~2025-02-24 10:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-20  8:40 [PATCH 0/6] arm64: Introduce CIX P1 (SKY1) SoC Peter Chen
2025-02-20  8:40 ` [PATCH 1/6] dt-bindings: arm: add " Peter Chen
2025-02-20 12:18   ` Krzysztof Kozlowski
2025-02-20  8:40 ` [PATCH 2/6] dt-bindings: vendor-prefixes: Add CIX Technology Group Co., Ltd Peter Chen
2025-02-20 12:18   ` Krzysztof Kozlowski
2025-02-20 13:04     ` Peter Chen
2025-02-20  8:40 ` [PATCH 3/6] MAINTAINERS: Add CIX SoC maintainer entry Peter Chen
2025-02-20  8:40 ` [PATCH 4/6] arm64: Kconfig: add ARCH_CIX for cix silicons Peter Chen
2025-02-20 12:18   ` Krzysztof Kozlowski
2025-02-20 13:03     ` Peter Chen
2025-02-20  8:40 ` [PATCH 5/6] arm64: defconfig: Enable CIX SoC Peter Chen
2025-02-20 12:19   ` Krzysztof Kozlowski
2025-02-20 13:02     ` Peter Chen
2025-02-20  8:40 ` [PATCH 6/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support Peter Chen
2025-02-20 10:58   ` Arnd Bergmann
2025-02-20 12:30     ` Peter Chen
2025-02-21 11:42       ` Krzysztof Kozlowski
2025-02-24  2:26         ` Peter Chen
2025-02-24  8:06           ` Krzysztof Kozlowski
2025-02-24 10:39             ` Peter Chen [this message]
2025-02-24 12:07               ` Krzysztof Kozlowski
2025-02-25  1:24                 ` Peter Chen
2025-02-20 12:23   ` Krzysztof Kozlowski
2025-02-21 22:46   ` Rob Herring
2025-02-24  6:09     ` Peter Chen
2025-02-22 20:05   ` Marcin Juszkiewicz
2025-02-24 11:36     ` Peter Chen
2025-02-24 14:06       ` Marcin Juszkiewicz
2025-02-25  3:21         ` Peter Chen
2025-02-20 21:29 ` [PATCH 0/6] arm64: Introduce CIX P1 (SKY1) SoC Rob Herring (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z7xMeub9i74a_19g@nchen-desktop \
    --to=peter.chen@cixtech.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=cix-kernel-upstream@cixtech.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fugang.duan@cixtech.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).