All of lore.kernel.org
 help / color / mirror / Atom feed
From: Haylen Chu <heylenay@4d2.org>
To: Alex Elder <elder@riscstar.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Haylen Chu <heylenay@outlook.com>, Yixun Lan <dlan@gentoo.org>
Cc: linux-riscv@lists.infradead.org, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Inochi Amaoto <inochiama@outlook.com>,
	Chen Wang <unicornxdotw@foxmail.com>,
	Guodong Xu <guodong@riscstar.com>
Subject: Re: [PATCH v4 3/4] clk: spacemit: Add clock support for Spacemit K1 SoC
Date: Sat, 22 Feb 2025 09:40:47 +0000	[thread overview]
Message-ID: <Z7mbn_de-KV-yqQP@ketchup> (raw)
In-Reply-To: <Z7HNLq3DgJj7WKGI@ketchup>

Hi Alex,

Before answering the reply, I'd like to share some information on these
unconfirmed questions.

On Sun, Feb 16, 2025 at 11:34:06AM +0000, Haylen Chu wrote:
> On Thu, Feb 13, 2025 at 10:04:10PM -0600, Alex Elder wrote:
> > On 1/3/25 3:56 PM, Haylen Chu wrote:
> > > diff --git a/drivers/clk/spacemit/ccu-k1.c b/drivers/clk/spacemit/ccu-k1.c
> > > new file mode 100644
> > > index 000000000000..6fb0a12ec261
> > > --- /dev/null
> > > +++ b/drivers/clk/spacemit/ccu-k1.c

...

> The next clock is weird, and it's the only one of its kind.  It is not
> > represented in the clock tree diagram. It is a "factor 1" clock (so it
> > just passes the parent's rate through), and has no gate.  Do you know
> > why it's defined?  It is used only as one of the MPMU parent clocks.
> > Why isn't just the pll1_d7 clock used in its place?
> 
> It is represented in the diagram. The photo version of the diagram seems
> hard to search so I will ask the vendor to publish a PDF version if
> possible.
> 
> As the definition involves no hardware bits, I guess it's actually an
> alias listed to keep the tree structure in similar form. Will confirm
> this with the vendor.

Yes, it's confirmed as a placeholder.

> 
> > > +static CCU_FACTOR_DEFINE(pll1_d7_351p08, "pll1_d7_351p08", CCU_PARENT_HW(pll1_d7),
> > > +			 1, 1);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d6_409p6, "pll1_d6_409p6", CCU_PARENT_HW(pll1_d6),
> > > +		       MPMU_ACGR,
> > > +		       BIT(0), BIT(0), 0, 0);
> > > +static CCU_GATE_FACTOR_DEFINE(pll1_d12_204p8, "pll1_d12_204p8", CCU_PARENT_HW(pll1_d6),
> > > +			      MPMU_ACGR,
> > > +			      BIT(5), BIT(5), 0, 2, 1, 0);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d5_491p52, "pll1_d5_491p52", CCU_PARENT_HW(pll1_d5),
> > > +		       MPMU_ACGR,
> > > +		       BIT(21), BIT(21), 0, 0);
> > > +static CCU_GATE_FACTOR_DEFINE(pll1_d10_245p76, "pll1_d10_245p76", CCU_PARENT_HW(pll1_d5),
> > > +			      MPMU_ACGR,
> > > +			      BIT(18), BIT(18), 0, 2, 1, 0);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d4_614p4, "pll1_d4_614p4", CCU_PARENT_HW(pll1_d4),
> > > +		       MPMU_ACGR,
> > > +		       BIT(15), BIT(15), 0, 0);
> > > +static CCU_GATE_FACTOR_DEFINE(pll1_d52_47p26, "pll1_d52_47p26", CCU_PARENT_HW(pll1_d4),
> > > +			      MPMU_ACGR,
> > > +			      BIT(10), BIT(10), 0, 13, 1, 0);
> > > +static CCU_GATE_FACTOR_DEFINE(pll1_d78_31p5, "pll1_d78_31p5", CCU_PARENT_HW(pll1_d4),
> > > +			      MPMU_ACGR,
> > > +			      BIT(6), BIT(6), 0, 39, 2, 0);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d3_819p2, "pll1_d3_819p2", CCU_PARENT_HW(pll1_d3),
> > > +		       MPMU_ACGR,
> > > +		       BIT(14), BIT(14), 0, 0);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d2_1228p8, "pll1_d2_1228p8", CCU_PARENT_HW(pll1_d2),
> > > +		       MPMU_ACGR,
> > > +		       BIT(16), BIT(16), 0, 0);

...

> > I couldn't find the "ripc_clk" on the clock tree diagram.  It is
> > never used elsewhere, so I think this definition can go away.
> 
> I'm not sure whether the ripc_clk doesn't exist or it's just missing in
> both datasheet and clock tree diagram. Will confirm with the vendor.

It's just missing in the datasheet and clock tree diagram and now they
have been completed[1].

> > > +static CCU_GATE_DEFINE(ripc_clk, "ripc_clk", CCU_PARENT_NAME(vctcxo_24m),
> > > +		       MPMU_RIPCCR,
> > > +		       0x3, 0x3, 0x0,
> > > +		       0);
> > > +

....

> > > +static const struct clk_parent_data dpubit_parents[] = {
> > > +	CCU_PARENT_HW(pll1_d3_819p2),
> > > +	CCU_PARENT_HW(pll2_d2),
> > > +	CCU_PARENT_HW(pll2_d3),
> > > +	CCU_PARENT_HW(pll1_d2_1228p8),
> > > +	CCU_PARENT_HW(pll2_d4),
> > > +	CCU_PARENT_HW(pll2_d5),
> > 
> > The next two parent clocks are duplicates.  It looks this way on the
> > clock tree diagram as well.  Is this correct? Can you find out from
> > SpacemiT whether one of them is actually a different clock (like
> > pll2_d6 or something)?  It makes no sense to have two multiplexed
> > parent clocks with the same source.
> 
> Yes, will confirm it later. The register description[2] suggests it's
> wrong (there aren't two configuration for MIPI_BIT_CLK_SEL resulting in
> the same frequency).

The clock tree diagram (and the vendor driver) were wrong. The 7th.
parent should be pll2_d7 (427MHz * 7 is roughly 3GHz, which is PLL2's
frequency). The diagram has been corrected.

> > > +	CCU_PARENT_HW(pll2_d8),
> > > +	CCU_PARENT_HW(pll2_d8),
> > > +};
> > > +static CCU_DIV_FC_MUX_GATE_DEFINE(dpu_bit_clk, "dpu_bit_clk", dpubit_parents,
> > > +				  APMU_LCD_CLK_RES_CTRL1,
> > > +				  17, 3, BIT(31),
> > > +				  20, 3, BIT(16), BIT(16), 0x0,
> > > +				  0);
> > > +

...

> > > diff --git a/drivers/clk/spacemit/ccu_ddn.c b/drivers/clk/spacemit/ccu_ddn.c
> > > new file mode 100644
> > > index 000000000000..1df555888ecb
> > > --- /dev/null
> > > +++ b/drivers/clk/spacemit/ccu_ddn.c
> > > @@ -0,0 +1,140 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Spacemit clock type ddn
> > > + *
> > > + * Copyright (c) 2024 SpacemiT Technology Co. Ltd
> > > + * Copyright (c) 2024 Haylen Chu <heylenay@4d2.org>
> > > + */
> > > +
> > > +#include <linux/clk-provider.h>
> > > +
> > > +#include "ccu_ddn.h"
> > 
> > What does "DDN" stand for?
> 
> I'm not sure, the name is kept from the vendor driver. I could change it
> to a more descriptive name, like "fraction-factor".

It's abbreviated from "Divider Denominator Numerator", confirmed by the
vendor. Quite weird a name. I'll make the abbreviation and corresponding
explanation more clear in the next revision.

Thanks,
Haylen Chu

[1]: https://developer.spacemit.com/documentation?token=LCrKwWDasiJuROkVNusc2pWTnEb#part208

WARNING: multiple messages have this Message-ID (diff)
From: Haylen Chu <heylenay@4d2.org>
To: Alex Elder <elder@riscstar.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Haylen Chu <heylenay@outlook.com>, Yixun Lan <dlan@gentoo.org>
Cc: linux-riscv@lists.infradead.org, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Inochi Amaoto <inochiama@outlook.com>,
	Chen Wang <unicornxdotw@foxmail.com>,
	Guodong Xu <guodong@riscstar.com>
Subject: Re: [PATCH v4 3/4] clk: spacemit: Add clock support for Spacemit K1 SoC
Date: Sat, 22 Feb 2025 09:40:47 +0000	[thread overview]
Message-ID: <Z7mbn_de-KV-yqQP@ketchup> (raw)
In-Reply-To: <Z7HNLq3DgJj7WKGI@ketchup>

Hi Alex,

Before answering the reply, I'd like to share some information on these
unconfirmed questions.

On Sun, Feb 16, 2025 at 11:34:06AM +0000, Haylen Chu wrote:
> On Thu, Feb 13, 2025 at 10:04:10PM -0600, Alex Elder wrote:
> > On 1/3/25 3:56 PM, Haylen Chu wrote:
> > > diff --git a/drivers/clk/spacemit/ccu-k1.c b/drivers/clk/spacemit/ccu-k1.c
> > > new file mode 100644
> > > index 000000000000..6fb0a12ec261
> > > --- /dev/null
> > > +++ b/drivers/clk/spacemit/ccu-k1.c

...

> The next clock is weird, and it's the only one of its kind.  It is not
> > represented in the clock tree diagram. It is a "factor 1" clock (so it
> > just passes the parent's rate through), and has no gate.  Do you know
> > why it's defined?  It is used only as one of the MPMU parent clocks.
> > Why isn't just the pll1_d7 clock used in its place?
> 
> It is represented in the diagram. The photo version of the diagram seems
> hard to search so I will ask the vendor to publish a PDF version if
> possible.
> 
> As the definition involves no hardware bits, I guess it's actually an
> alias listed to keep the tree structure in similar form. Will confirm
> this with the vendor.

Yes, it's confirmed as a placeholder.

> 
> > > +static CCU_FACTOR_DEFINE(pll1_d7_351p08, "pll1_d7_351p08", CCU_PARENT_HW(pll1_d7),
> > > +			 1, 1);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d6_409p6, "pll1_d6_409p6", CCU_PARENT_HW(pll1_d6),
> > > +		       MPMU_ACGR,
> > > +		       BIT(0), BIT(0), 0, 0);
> > > +static CCU_GATE_FACTOR_DEFINE(pll1_d12_204p8, "pll1_d12_204p8", CCU_PARENT_HW(pll1_d6),
> > > +			      MPMU_ACGR,
> > > +			      BIT(5), BIT(5), 0, 2, 1, 0);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d5_491p52, "pll1_d5_491p52", CCU_PARENT_HW(pll1_d5),
> > > +		       MPMU_ACGR,
> > > +		       BIT(21), BIT(21), 0, 0);
> > > +static CCU_GATE_FACTOR_DEFINE(pll1_d10_245p76, "pll1_d10_245p76", CCU_PARENT_HW(pll1_d5),
> > > +			      MPMU_ACGR,
> > > +			      BIT(18), BIT(18), 0, 2, 1, 0);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d4_614p4, "pll1_d4_614p4", CCU_PARENT_HW(pll1_d4),
> > > +		       MPMU_ACGR,
> > > +		       BIT(15), BIT(15), 0, 0);
> > > +static CCU_GATE_FACTOR_DEFINE(pll1_d52_47p26, "pll1_d52_47p26", CCU_PARENT_HW(pll1_d4),
> > > +			      MPMU_ACGR,
> > > +			      BIT(10), BIT(10), 0, 13, 1, 0);
> > > +static CCU_GATE_FACTOR_DEFINE(pll1_d78_31p5, "pll1_d78_31p5", CCU_PARENT_HW(pll1_d4),
> > > +			      MPMU_ACGR,
> > > +			      BIT(6), BIT(6), 0, 39, 2, 0);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d3_819p2, "pll1_d3_819p2", CCU_PARENT_HW(pll1_d3),
> > > +		       MPMU_ACGR,
> > > +		       BIT(14), BIT(14), 0, 0);
> > > +
> > > +static CCU_GATE_DEFINE(pll1_d2_1228p8, "pll1_d2_1228p8", CCU_PARENT_HW(pll1_d2),
> > > +		       MPMU_ACGR,
> > > +		       BIT(16), BIT(16), 0, 0);

...

> > I couldn't find the "ripc_clk" on the clock tree diagram.  It is
> > never used elsewhere, so I think this definition can go away.
> 
> I'm not sure whether the ripc_clk doesn't exist or it's just missing in
> both datasheet and clock tree diagram. Will confirm with the vendor.

It's just missing in the datasheet and clock tree diagram and now they
have been completed[1].

> > > +static CCU_GATE_DEFINE(ripc_clk, "ripc_clk", CCU_PARENT_NAME(vctcxo_24m),
> > > +		       MPMU_RIPCCR,
> > > +		       0x3, 0x3, 0x0,
> > > +		       0);
> > > +

....

> > > +static const struct clk_parent_data dpubit_parents[] = {
> > > +	CCU_PARENT_HW(pll1_d3_819p2),
> > > +	CCU_PARENT_HW(pll2_d2),
> > > +	CCU_PARENT_HW(pll2_d3),
> > > +	CCU_PARENT_HW(pll1_d2_1228p8),
> > > +	CCU_PARENT_HW(pll2_d4),
> > > +	CCU_PARENT_HW(pll2_d5),
> > 
> > The next two parent clocks are duplicates.  It looks this way on the
> > clock tree diagram as well.  Is this correct? Can you find out from
> > SpacemiT whether one of them is actually a different clock (like
> > pll2_d6 or something)?  It makes no sense to have two multiplexed
> > parent clocks with the same source.
> 
> Yes, will confirm it later. The register description[2] suggests it's
> wrong (there aren't two configuration for MIPI_BIT_CLK_SEL resulting in
> the same frequency).

The clock tree diagram (and the vendor driver) were wrong. The 7th.
parent should be pll2_d7 (427MHz * 7 is roughly 3GHz, which is PLL2's
frequency). The diagram has been corrected.

> > > +	CCU_PARENT_HW(pll2_d8),
> > > +	CCU_PARENT_HW(pll2_d8),
> > > +};
> > > +static CCU_DIV_FC_MUX_GATE_DEFINE(dpu_bit_clk, "dpu_bit_clk", dpubit_parents,
> > > +				  APMU_LCD_CLK_RES_CTRL1,
> > > +				  17, 3, BIT(31),
> > > +				  20, 3, BIT(16), BIT(16), 0x0,
> > > +				  0);
> > > +

...

> > > diff --git a/drivers/clk/spacemit/ccu_ddn.c b/drivers/clk/spacemit/ccu_ddn.c
> > > new file mode 100644
> > > index 000000000000..1df555888ecb
> > > --- /dev/null
> > > +++ b/drivers/clk/spacemit/ccu_ddn.c
> > > @@ -0,0 +1,140 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Spacemit clock type ddn
> > > + *
> > > + * Copyright (c) 2024 SpacemiT Technology Co. Ltd
> > > + * Copyright (c) 2024 Haylen Chu <heylenay@4d2.org>
> > > + */
> > > +
> > > +#include <linux/clk-provider.h>
> > > +
> > > +#include "ccu_ddn.h"
> > 
> > What does "DDN" stand for?
> 
> I'm not sure, the name is kept from the vendor driver. I could change it
> to a more descriptive name, like "fraction-factor".

It's abbreviated from "Divider Denominator Numerator", confirmed by the
vendor. Quite weird a name. I'll make the abbreviation and corresponding
explanation more clear in the next revision.

Thanks,
Haylen Chu

[1]: https://developer.spacemit.com/documentation?token=LCrKwWDasiJuROkVNusc2pWTnEb#part208

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2025-02-22  9:41 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-03 21:56 [PATCH v4 0/4] Add clock controller support for SpacemiT K1 Haylen Chu
2025-01-03 21:56 ` Haylen Chu
2025-01-03 21:56 ` [PATCH v4 1/4] dt-bindings: clock: spacemit: Add clock controllers of Spacemit K1 SoC Haylen Chu
2025-01-03 21:56   ` Haylen Chu
2025-01-04  9:58   ` Krzysztof Kozlowski
2025-01-04  9:58     ` Krzysztof Kozlowski
2025-01-15  7:29     ` Haylen Chu
2025-01-15  7:29       ` Haylen Chu
2025-01-03 21:56 ` [PATCH v4 2/4] dt-bindings: soc: spacemit: Add spacemit,k1-syscon Haylen Chu
2025-01-03 21:56   ` Haylen Chu
2025-01-04 10:07   ` Krzysztof Kozlowski
2025-01-04 10:07     ` Krzysztof Kozlowski
2025-02-11  5:15     ` Haylen Chu
2025-02-11  5:15       ` Haylen Chu
2025-02-11  8:03       ` Krzysztof Kozlowski
2025-02-11  8:03         ` Krzysztof Kozlowski
2025-02-13 11:14         ` Haylen Chu
2025-02-13 11:14           ` Haylen Chu
2025-02-13 18:07           ` Krzysztof Kozlowski
2025-02-13 18:07             ` Krzysztof Kozlowski
2025-02-15  8:41             ` Haylen Chu
2025-02-15  8:41               ` Haylen Chu
2025-02-21 23:40               ` Alex Elder
2025-02-21 23:40                 ` Alex Elder
2025-02-22  9:59                 ` Krzysztof Kozlowski
2025-02-22  9:59                   ` Krzysztof Kozlowski
2025-02-22 10:48                   ` Haylen Chu
2025-02-22 10:48                     ` Haylen Chu
2025-02-22 11:50                     ` Krzysztof Kozlowski
2025-02-22 11:50                       ` Krzysztof Kozlowski
2025-02-24 10:17                       ` Haylen Chu
2025-02-24 10:17                         ` Haylen Chu
2025-02-25  8:12                         ` Krzysztof Kozlowski
2025-02-25  8:12                           ` Krzysztof Kozlowski
2025-02-25 21:14                           ` Alex Elder
2025-02-25 21:14                             ` Alex Elder
2025-02-22  9:52               ` Krzysztof Kozlowski
2025-02-22  9:52                 ` Krzysztof Kozlowski
2025-02-22 11:36                 ` Haylen Chu
2025-02-22 11:36                   ` Haylen Chu
2025-01-03 21:56 ` [PATCH v4 3/4] clk: spacemit: Add clock support for Spacemit K1 SoC Haylen Chu
2025-01-03 21:56   ` Haylen Chu
2025-01-16  5:25   ` Samuel Holland
2025-01-16  5:25     ` Samuel Holland
2025-01-21 17:01     ` Haylen Chu
2025-01-21 17:01       ` Haylen Chu
2025-02-14  4:04   ` Alex Elder
2025-02-14  4:04     ` Alex Elder
2025-02-16 11:34     ` Haylen Chu
2025-02-16 11:34       ` Haylen Chu
2025-02-21 21:10       ` Alex Elder
2025-02-21 21:10         ` Alex Elder
2025-02-22  9:57         ` Haylen Chu
2025-02-22  9:57           ` Haylen Chu
2025-02-22  9:40       ` Haylen Chu [this message]
2025-02-22  9:40         ` Haylen Chu
2025-03-03  9:41     ` Haylen Chu
2025-03-03  9:41       ` Haylen Chu
2025-03-03 14:10       ` Alex Elder
2025-03-03 14:10         ` Alex Elder
2025-01-03 21:56 ` [PATCH v4 4/4] riscv: dts: spacemit: Add clock controller for K1 Haylen Chu
2025-01-03 21:56   ` Haylen Chu

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=Z7mbn_de-KV-yqQP@ketchup \
    --to=heylenay@4d2.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlan@gentoo.org \
    --cc=elder@riscstar.com \
    --cc=guodong@riscstar.com \
    --cc=heylenay@outlook.com \
    --cc=inochiama@outlook.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=unicornxdotw@foxmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.