mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Théo Lebrun" <theo.lebrun@bootlin.com>
To: "Stephen Boyd" <sboyd@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Rob Herring" <robh@kernel.org>
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Vladimir Kondratiev" <vladimir.kondratiev@mobileye.com>,
	"Grégory Clement" <gregory.clement@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Tawfik Bayouk" <tawfik.bayouk@mobileye.com>
Subject: Re: [PATCH RESEND v3 4/4] clk: eyeq: add driver
Date: Tue, 24 Sep 2024 16:53:43 +0200	[thread overview]
Message-ID: <D4ELMFAUQYZ7.3LXGQZJSX68UF@bootlin.com> (raw)
In-Reply-To: <586966c515e15f455973e7c55bd3ac5e.sboyd@kernel.org>

Hello Stephen,

Only answering to questions to which I have answers.
The rest is addressed for next revision.

On Wed Sep 18, 2024 at 7:28 AM CEST, Stephen Boyd wrote:
> Quoting Théo Lebrun (2024-07-30 09:04:46)
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index 3e9099504fad..31f48edf855c 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -218,6 +218,19 @@ config COMMON_CLK_EN7523
> >           This driver provides the fixed clocks and gates present on Airoha
> >           ARM silicon.
> >  
> > +config COMMON_CLK_EYEQ
> > +       bool "Clock driver for the Mobileye EyeQ platform"
> > +       depends on 64BIT # for readq()
> > +       depends on OF || COMPILE_TEST
>
> What's the OF build dependency? If there isn't one please remove this
> line.

There is none (at least we have a compat layer that means we can build
even with CONFIG_OF=n). Removed in next revision.

>
> > +               *mult = *mult * 0x100000 + FIELD_GET(PCSR1_FRAC_IN, r1);
> > +       }
> > +
> > +       if (!*mult || !*div)
> > +               return -EINVAL;
> > +
> > +       /* Spread spectrum. */
> > +       if (!(r1 & (PCSR1_RESET | PCSR1_DIS_SSCG))) {
> > +               /*
> > +                * Spread is 1/1000 parts of frequency, accuracy is half of
> > +                * that. To get accuracy, convert to ppb (parts per billion).
> > +                */
> > +               u32 spread = FIELD_GET(PCSR1_SPREAD, r1);
> > +
> > +               *acc = spread * 500000;
>
> Where does 500000 come from? Half a billion?

In addition to the above comment, I added this to clarify:

	 * acc = spread * 1e6 / 2
	 *   with acc in parts per billion and,
	 *        spread in parts per thousand.

[...]

> > +
> > +static const struct eqc_early_match_data eqc_eyeq6h_central_early_match_data = {
> > +       .early_pll_count        = ARRAY_SIZE(eqc_eyeq6h_central_early_plls),
> > +       .early_plls             = eqc_eyeq6h_central_early_plls,
> > +       .nb_late_clks = 0,
> > +};
> > +
> > +/* Required early for UART. */
>
> Is this required for earlycon? Where is the UART not a device driver
> that needs to get clks early?

The UART is PL011. It is an AMBA device, those get probed before
platform devices by of_platform_bus_create(). "pll-per" must be
available at that time.

[...]

> > +static void __init eqc_init(struct device_node *np)
[...]
> > +       spin_lock(&eqc_list_slock);
>
> I don't see how the spinlock provides any value. This function will run
> before any struct devices have been created.

Indeed no clash can happen. Will remove.

>
> > +       list_add_tail(&priv->list, &eqc_list);
>
> The list is also kind of unnecessary. Set a bool in the match_data and
> move on? We could have some sort of static_assert() check to make sure
> if there's a CLK_OF_DECLARE_DRIVER() then the bool is set in the
> match_data for the driver. Such a design is cheaper than taking a lock,
> adding to a list.

This list's main goal is not to know what was early-inited. Its only
reason for existence is that we want to get, at eqc_probe(), the cells
pointer allocated at eqc_init().

struct eqc_priv {
	/* this field is why we store priv inside a linked list: */
	struct clk_hw_onecell_data	*cells;
	/* the rest, we don't care much: */
	const struct eqc_early_match_data *early_data;
	const struct eqc_match_data	*data;
	void __iomem			*base;
	struct device_node		*np;
	struct list_head		list;
};

I do not see how to do that with a bool. We could put the pointer into
the match data, but that would mean we'd have to make them writable
(currently static const data). We are talking about a linked list with
two items in the worst case (EyeQ6H), accessed twice.

The reason we store the whole of priv: simpler code and we avoid mapping
registers twice (once at eqc_init() and once at eqc_probe()).

Can you confirm the current static linked list approach (without any
spinlock) will be good for next revision?

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


  reply	other threads:[~2024-09-24 14:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-30 16:04 [PATCH RESEND v3 0/4] Add Mobileye EyeQ clock support Théo Lebrun
2024-07-30 16:04 ` [PATCH RESEND v3 1/4] Revert "dt-bindings: clock: mobileye,eyeq5-clk: add bindings" Théo Lebrun
2024-07-30 16:04 ` [PATCH RESEND v3 2/4] dt-bindings: clock: add Mobileye EyeQ6L/EyeQ6H clock indexes Théo Lebrun
2024-07-30 16:04 ` [PATCH RESEND v3 3/4] clk: divider: Introduce CLK_DIVIDER_EVEN_INTEGERS flag Théo Lebrun
2024-09-18  4:52   ` Stephen Boyd
2024-07-30 16:04 ` [PATCH RESEND v3 4/4] clk: eyeq: add driver Théo Lebrun
2024-09-18  5:28   ` Stephen Boyd
2024-09-24 14:53     ` Théo Lebrun [this message]
2024-07-30 16:06 ` [PATCH RESEND v3 0/4] Add Mobileye EyeQ clock support Théo Lebrun
2024-08-28 15:16 ` Théo Lebrun

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=D4ELMFAUQYZ7.3LXGQZJSX68UF@bootlin.com \
    --to=theo.lebrun@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregory.clement@bootlin.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tawfik.bayouk@mobileye.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vladimir.kondratiev@mobileye.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®