From: Dario Binacchi <dario.binacchi@amarulasolutions.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-amarula@amarulasolutions.com,
Conor Dooley <conor+dt@kernel.org>,
Fabio Estevam <festevam@gmail.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Peng Fan <peng.fan@nxp.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Rob Herring <robh@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
Subject: Re: [PATCH 1/6] dt-bindings: clock: imx8m-anatop: support spread spectrum clocking
Date: Tue, 1 Oct 2024 08:29:21 +0200 [thread overview]
Message-ID: <CABGWkvrU507BHoP94Y7fEyFr=chuuy3o=oBHtuWRvwTw3GnxXw@mail.gmail.com> (raw)
In-Reply-To: <6c3e6071-822f-4230-b76b-276330de07ef@kernel.org>
On Mon, Sep 30, 2024 at 8:45 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 29/09/2024 22:00, Dario Binacchi wrote:
> >>
> >>
> >>> + properties:
> >>> + compatible:
> >>> + contains:
> >>> + enum:
> >>> + - fsl,imx8mm-anatop
> >>> +
> >>> +then:
> >>> + properties:
> >>> + fsl,ssc-clocks:
> >>
> >> Nope. Properties must be defined in top-level.
> >>
> >>> + $ref: /schemas/types.yaml#/definitions/phandle-array
> >>> + description:
> >>> + The phandles to the PLLs with spread spectrum clock generation
> >>> + hardware capability.
> >>
> >> These should be clocks.
> >
> > Sorry, but I can't understand what you're asking me.
> > Could you kindly explain it to me in more detail?
>
> You added new property instead of using existing one for this purpose:
> 'clocks'.
>
>
>
> Best regards,
> Krzysztof
>
I added this new property specifically for managing spread-spectrum.
Indeed, not all clocks/PLLs
managed by the node/peripheral support spread-spectrum, and the added
properties specify
parameters for enabling and tuning SSC for each individual PLL based
on the index of each list.
If I were to use the 'clocks' property and add a clock to this list
that does not support SSC, IMHO
the pairings would be less clear.
AFAIK the confusion arises from the fact that this node, which is a
clock controller, was used only
to export its base address, but perhaps it should have also exported
its clocks, which the other
clock controller does, as shown in:
Documentation/devicetree/bindings/clock/imx8m-clock.yaml.
If I consider its 'compatible' entries:
- 'fsl,imx8mm-ccm' -> drivers/clk/imx/clk-imx8mm.c
- 'fsl,imx8mn-ccm' -> drivers/clk/imx/clk-imx8mn.c
- 'fsl,imx8mp-ccm' -> drivers/clk/imx/clk-imx8mp.c
the probe function, triggered by fsl,imx8m{m,n,p}-ccm (and not
fsl,imx8m{m,n,p}-anatop),
retrieves the anatop node solely to get its base address, also
registering its clocks, which
I would have expected to be registered by another driver, specifically
the one for anatop:
static int imx8mn_clocks_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
void __iomem *base;
struct imx_pll14xx_ssc pll1443x_ssc;
int ret;
clk_hw_data = devm_kzalloc(dev, struct_size(clk_hw_data, hws,
IMX8MN_CLK_END), GFP_KERNEL);
if (WARN_ON(!clk_hw_data))
return -ENOMEM;
clk_hw_data->num = IMX8MN_CLK_END;
hws = clk_hw_data->hws;
hws[IMX8MN_CLK_DUMMY] = imx_clk_hw_fixed("dummy", 0);
hws[IMX8MN_CLK_24M] = imx_get_clk_hw_by_name(np, "osc_24m");
hws[IMX8MN_CLK_32K] = imx_get_clk_hw_by_name(np, "osc_32k");
hws[IMX8MN_CLK_EXT1] = imx_get_clk_hw_by_name(np, "clk_ext1");
hws[IMX8MN_CLK_EXT2] = imx_get_clk_hw_by_name(np, "clk_ext2");
hws[IMX8MN_CLK_EXT3] = imx_get_clk_hw_by_name(np, "clk_ext3");
hws[IMX8MN_CLK_EXT4] = imx_get_clk_hw_by_name(np, "clk_ext4");
np = of_find_compatible_node(NULL, NULL, "fsl,imx8mn-anatop");
base = devm_of_iomap(dev, np, 0, NULL);
of_node_put(np);
if (WARN_ON(IS_ERR(base))) {
ret = PTR_ERR(base);
goto unregister_hws;
}
hws[IMX8MN_AUDIO_PLL1_REF_SEL] = imx_clk_hw_mux("audio_pll1_ref_sel",
base + 0x0, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
hws[IMX8MN_AUDIO_PLL2_REF_SEL] = imx_clk_hw_mux("audio_pll2_ref_sel",
base + 0x14, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
hws[IMX8MN_VIDEO_PLL_REF_SEL] = imx_clk_hw_mux("video_pll_ref_sel",
base + 0x28, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
Thanks and regards,
Dario
--
Dario Binacchi
Senior Embedded Linux Developer
dario.binacchi@amarulasolutions.com
__________________________________
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
info@amarulasolutions.com
www.amarulasolutions.com
next prev parent reply other threads:[~2024-10-01 6:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-28 8:37 [PATCH 0/6] Support spread spectrum clocking for i.MX8{M,N,P} PLLs Dario Binacchi
2024-09-28 8:37 ` [PATCH 1/6] dt-bindings: clock: imx8m-anatop: support spread spectrum clocking Dario Binacchi
2024-09-28 12:09 ` Krzysztof Kozlowski
2024-09-29 20:00 ` Dario Binacchi
2024-09-30 6:45 ` Krzysztof Kozlowski
2024-10-01 6:29 ` Dario Binacchi [this message]
2024-10-03 10:46 ` Krzysztof Kozlowski
2024-10-05 8:57 ` Dario Binacchi
2024-10-06 13:13 ` Krzysztof Kozlowski
2024-10-07 15:02 ` Dario Binacchi
2024-10-08 8:20 ` Krzysztof Kozlowski
2024-10-08 9:16 ` Dario Binacchi
2024-10-23 14:58 ` Dario Binacchi
2024-10-23 17:49 ` Krzysztof Kozlowski
2024-10-28 10:32 ` Dario Binacchi
2024-09-28 8:37 ` [PATCH 2/6] clk: imx: pll14xx: support spread spectrum clock generation Dario Binacchi
2024-09-28 8:37 ` [PATCH 3/6] clk: imx8mm: " Dario Binacchi
2024-09-28 8:37 ` [PATCH 4/6] clk: imx8mn: " Dario Binacchi
2024-09-28 8:37 ` [PATCH 5/6] clk: imx8mp: don't lose the anatop device node Dario Binacchi
2024-09-28 8:37 ` [PATCH 6/6] clk: imx8mp: support spread spectrum clock generation Dario Binacchi
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='CABGWkvrU507BHoP94Y7fEyFr=chuuy3o=oBHtuWRvwTw3GnxXw@mail.gmail.com' \
--to=dario.binacchi@amarulasolutions.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-amarula@amarulasolutions.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=peng.fan@nxp.com \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=sboyd@kernel.org \
--cc=shawnguo@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).