devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Jon Hunter <jonathanh@nvidia.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Joseph Lo <josephl@nvidia.com>,
	linux-tegra@vger.kernel.org, devicetree@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 09/14] memory: tegra: Add EMC scaling support code for Tegra210
Date: Tue, 14 Apr 2020 16:54:42 +0200	[thread overview]
Message-ID: <20200414145442.GJ3593749@ulmo> (raw)
In-Reply-To: <a9afb1b5-3141-4923-c7fa-194228081e1b@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3062 bytes --]

On Thu, Apr 09, 2020 at 10:16:46PM +0300, Dmitry Osipenko wrote:
> 09.04.2020 20:52, Thierry Reding пишет:
> ...
> > +static int tegra210_emc_set_rate(struct device *dev,
> > +				 const struct tegra210_clk_emc_config *config)
> > +{
> > +	struct tegra210_emc *emc = dev_get_drvdata(dev);
> > +	struct tegra210_emc_timing *timing = NULL;
> > +	unsigned long rate = config->rate;
> > +	s64 last_change_delay;
> > +	unsigned long flags;
> > +	unsigned int i;
> > +
> > +	if (rate == emc->last->rate * 1000UL)
> > +		return 0;
> 
> Couldn't all the rates be expressed in Hz? Then you won't need all these
> multiplications by 1000.

The EMC table is generated with kHz and I'd rather not change the values
in those entries. There's only a few cases where we need to convert from
one to the other, and they are always only when we compare a CCF rate to
the EMC rate, so I think it's fairly explicit when it's needed.

> > +	for (i = 0; i < emc->num_timings; i++) {
> > +		if (emc->timings[i].rate * 1000UL == rate) {
> > +			timing = &emc->timings[i];
> > +			break;
> > +		}
> > +	}
> > +
> > +	if (!timing)
> > +		return -EINVAL;
> > +
> > +	if (rate > 204000000 && !timing->trained)
> > +		return -EINVAL;
> > +
> > +	emc->next = timing;
> > +	last_change_delay = ktime_us_delta(ktime_get(), emc->clkchange_time);
> > +
> > +	/* XXX use non-busy-looping sleep? */
> > +	if ((last_change_delay >= 0) &&
> > +	    (last_change_delay < emc->clkchange_delay))
> > +		udelay(emc->clkchange_delay - (int)last_change_delay);
> > +
> > +	spin_lock_irqsave(&emc->lock, flags);
> > +	tegra210_emc_set_clock(emc, config->value);
> > +	emc->clkchange_time = ktime_get();
> > +	emc->last = timing;
> > +	spin_unlock_irqrestore(&emc->lock, flags);
> > +
> > +	return 0;
> > +}
> 
> I'd suggest to check how much time invocation of ktime_get() takes, at
> least it came to a surprise to me in a case of the tegra-cpuidle driver.
> 
> It may be well over the emc->clkchange_delay.

I assume that at least each invocation would take roughly the same
amount of time? Since we only use the value to compute the time since
the last clock change the result should always be valid. In the worst
case if ktime_get() really takes that long we may be waiting longer
than we need to, but that wouldn't be all that bad either. Changing
the EMC clock rate isn't something that you want to do a lot.

> ...
> > +static int tegra210_emc_probe(struct platform_device *pdev)
> > +{
> ...
> > +	emc->clkchange_delay = 100;
> > +	emc->training_interval = 100;
> 
> Not sure why these aren't a constant with the code.. ?

The idea is to make them easily tunable without having to go hunt for
them later on. We don't use them in a lot of computations, so making
them constants isn't going to buy us a lot. Also, none of these code
paths are really hot, so I like the flexibility that this gives us in
being able to quickly tweak if we ever need to without having to worry
that we'll forget a location.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-04-14 14:54 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09 17:52 [PATCH v6 00/14] Add EMC scaling support for Tegra210 Thierry Reding
2020-04-09 17:52 ` [PATCH v6 01/14] dt-bindings: reserved-memory: Introduce memory-region-names Thierry Reding
2020-04-15 16:23   ` Rob Herring
2020-04-09 17:52 ` [PATCH v6 02/14] of: reserved-memory: Support lookup of regions by name Thierry Reding
2020-04-15 16:24   ` Rob Herring
2020-04-15 23:35     ` Thierry Reding
2020-04-16  0:58       ` Rob Herring
2020-04-09 17:52 ` [PATCH v6 03/14] of: reserved-memory: Support multiple regions per device Thierry Reding
2020-04-15 16:25   ` Rob Herring
2020-04-09 17:52 ` [PATCH v6 04/14] clk: tegra: Rename Tegra124 EMC clock source file Thierry Reding
2020-04-14 16:48   ` Dmitry Osipenko
2020-04-14 17:14     ` Thierry Reding
2020-04-09 17:52 ` [PATCH v6 05/14] clk: tegra: Add PLLP_UD and PLLMB_UD for Tegra210 Thierry Reding
2020-04-09 17:52 ` [PATCH v6 06/14] clk: tegra: Export functions for EMC clock scaling Thierry Reding
2020-04-09 17:52 ` [PATCH v6 07/14] clk: tegra: Implement Tegra210 EMC clock Thierry Reding
2020-04-09 18:24   ` Dmitry Osipenko
2020-04-14 14:34     ` Thierry Reding
2020-04-14 15:18       ` Dmitry Osipenko
2020-04-14 17:10         ` Thierry Reding
2020-04-14 20:22           ` Dmitry Osipenko
2020-04-10 20:49   ` Dmitry Osipenko
2020-04-14 14:36     ` Thierry Reding
2020-04-09 17:52 ` [PATCH v6 08/14] dt-bindings: memory: tegra: Add external memory controller binding for Tegra210 Thierry Reding
2020-04-15 16:27   ` Rob Herring
2020-04-09 17:52 ` [PATCH v6 09/14] memory: tegra: Add EMC scaling support code " Thierry Reding
2020-04-09 19:00   ` Dmitry Osipenko
2020-04-14 14:45     ` Thierry Reding
2020-04-09 19:16   ` Dmitry Osipenko
2020-04-14 14:54     ` Thierry Reding [this message]
2020-04-14 20:50       ` Dmitry Osipenko
2020-04-09 23:56   ` Dmitry Osipenko
2020-04-11 20:39     ` Dmitry Osipenko
2020-04-14 15:05       ` Thierry Reding
2020-04-14 15:32         ` Dmitry Osipenko
2020-04-14 15:02     ` Thierry Reding
2020-04-10 14:25   ` Dmitry Osipenko
2020-04-14 15:08     ` Thierry Reding
2020-04-10 14:26   ` Dmitry Osipenko
2020-04-14 15:39     ` Thierry Reding
2020-04-10 20:46   ` Dmitry Osipenko
2020-04-14 15:41     ` Thierry Reding
2020-04-14 20:39   ` Dmitry Osipenko
2020-04-14 20:46   ` Dmitry Osipenko
2020-04-14 20:56     ` Dmitry Osipenko
2020-04-09 17:52 ` [PATCH v6 10/14] memory: tegra: Add EMC scaling sequence " Thierry Reding
2020-04-10 14:18   ` Dmitry Osipenko
2020-04-14 15:45     ` Thierry Reding
2020-04-14 16:27       ` Dmitry Osipenko
2020-04-14 20:03         ` Thierry Reding
2020-04-09 17:52 ` [PATCH v6 11/14] memory: tegra: Support derated timings on Tegra210 Thierry Reding
2020-04-09 23:44   ` Dmitry Osipenko
2020-04-14 15:47     ` Thierry Reding
2020-04-14 16:25       ` Dmitry Osipenko
2020-04-10 14:28   ` Dmitry Osipenko
2020-04-14 16:29     ` Thierry Reding
2020-04-14 16:40   ` Dmitry Osipenko
2020-04-14 16:48     ` Thierry Reding
2020-04-09 17:52 ` [PATCH v6 12/14] arm64: tegra: Add external memory controller node for Tegra210 Thierry Reding
2020-04-09 17:52 ` [PATCH v6 13/14] arm64: tegra: Hook up EMC cooling device Thierry Reding
2020-04-09 17:52 ` [PATCH v6 14/14] clk: tegra: Remove the old emc_mux clock for Tegra210 Thierry Reding

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=20200414145442.GJ3593749@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=josephl@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@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).