linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joseph Lo <josephl@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Rob Herring <robh+dt@kernel.org>, Stephen Boyd <sboyd@kernel.org>
Cc: <linux-tegra@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-clk@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V3 4/8] memory: tegra: Add Tegra210 EMC clock driver
Date: Wed, 15 May 2019 16:42:12 +0800	[thread overview]
Message-ID: <648df201-eb63-6d26-3f90-02eba7624921@nvidia.com> (raw)
In-Reply-To: <74fad66b-a6e9-ffc9-c1c9-e88b841e9209@gmail.com>

On 5/15/19 1:04 AM, Dmitry Osipenko wrote:
> 10.05.2019 11:47, Joseph Lo пишет:
>> This is the initial patch for Tegra210 EMC clock driver, which doesn't
>> include the support code and detail sequence for clock scaling yet.
>>
>> The driver is designed to support LPDDR4 SDRAM. Because of the LPDDR4
>> devices need to do initial time training before it can be used, the
>> firmware will help to do that at early boot stage. Then, the trained
>> table for the rates we support will pass to the kernel via DT. So the
>> driver can get the trained table for clock scaling support.
>>
>> For the higher rate support (above 800MHz), the periodic training is
>> needed for the timing compensation. So basically, two methodologies for
>> clock scaling are supported, one is following the clock changing
>> sequence to update the EMC table to EMC registers and another is if the
>> rate needs periodic training, then we will start a timer to do that
>> periodically until it scales to the lower rate.
>>
>> Based on the work of Peter De Schrijver <pdeschrijver@nvidia.com>.
>>
>> Signed-off-by: Joseph Lo <josephl@nvidia.com>
>> ---
> 
> [snip]
> 
>> +static int tegra210_emc_probe(struct platform_device *pdev)
>> +{
>> +	int i;
>> +	unsigned long table_rate;
>> +	unsigned long current_rate;
>> +	struct device_node *np;
>> +	struct platform_device *mc;
>> +	struct tegra_emc *emc;
>> +	struct clk_init_data init;
>> +	struct clk *clk;
>> +	struct resource *r, res;
>> +	void *table_addr;
>> +
>> +	emc = devm_kzalloc(&pdev->dev, sizeof(*emc), GFP_KERNEL);
>> +	if (!emc)
>> +		return -ENOMEM;
>> +
>> +	np = of_parse_phandle(pdev->dev.of_node, "nvidia,memory-controller", 0);
>> +	if (!np) {
>> +		dev_err(&pdev->dev, "could not get memory controller\n");
>> +		return -ENOENT;
>> +	}
>> +
>> +	mc = of_find_device_by_node(np);
>> +	of_node_put(np);
>> +	if (!mc)
>> +		return -ENOENT;
>> +
>> +	emc->mc = platform_get_drvdata(mc);
>> +	if (!emc->mc)
>> +		return -EPROBE_DEFER;
>> +
>> +	emc->ram_code = tegra_read_ram_code();
> 
> emc->ram_code isn't used anywhere in the code.
> 
> I haven't checked other fields. Please remove everything that is unused.

Good catch, I missed this when clean up the code for V3.

> 
>> +	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	emc->emc_base[REG_EMC] = devm_ioremap_resource(&pdev->dev, r);
>> +	r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> +	emc->emc_base[REG_EMC0] = devm_ioremap_resource(&pdev->dev, r);
>> +	r = platform_get_resource(pdev, IORESOURCE_MEM, 2);
>> +	emc->emc_base[REG_EMC1] = devm_ioremap_resource(&pdev->dev, r);
> 
> Use devm_platform_ioremap_resource().
> 
>> +	for (i = 0; i < TEGRA_EMC_SRC_COUNT; i++) {
>> +		emc_src[i] = devm_clk_get(&pdev->dev,
>> +						emc_src_names[i]);
>> +		if (IS_ERR(emc_src[i])) {
>> +			dev_err(&pdev->dev, "Can not find EMC source clock\n");
>> +			return -ENODATA;
>> +		}
>> +	}
>> +
>> +	np = of_parse_phandle(pdev->dev.of_node, "memory-region", 0);
>> +	if (!np) {
>> +		dev_err(&pdev->dev, "could not find EMC table\n");
>> +		goto emc_clk_register;
>> +	}
>> +
>> +	if (!of_device_is_compatible(np, "nvidia,tegra210-emc-table") ||
>> +	    !of_device_is_available(np)) {
>> +		dev_err(&pdev->dev, "EMC table is invalid\n");
>> +		goto emc_clk_register;
>> +	}
>> +
>> +	of_address_to_resource(np, 0, &res);
>> +	table_addr = memremap(res.start, resource_size(&res), MEMREMAP_WB);
>> +	of_node_put(np);
>> +	if (!table_addr) {
>> +		dev_err(&pdev->dev, "could not map EMC table\n");
>> +		goto emc_clk_register;
>> +	}
>> +	emc->emc_table = (struct emc_table *)table_addr;
>> +
>> +	for (i = 0; i < TEGRA_EMC_MAX_FREQS; i++)
>> +		if (emc->emc_table[i].rev != 0)
>> +			emc->emc_table_size++;
>> +		else
>> +			break;
>> +
>> +	/* Init EMC rate statistic data */
>> +	emc_stats.clkchange_count = 0;
>> +	spin_lock_init(&emc_stats.spinlock);
>> +	emc_stats.last_update = get_jiffies_64();
>> +	emc_stats.last_sel = TEGRA_EMC_MAX_FREQS;
>> +
>> +	/* Check the supported sequence */
>> +	while (seq->table_rev) {
>> +		if (seq->table_rev == emc->emc_table[0].rev)
>> +			break;
>> +		seq++;
>> +	}
>> +	if (!seq->set_clock) {
>> +		seq = NULL;
>> +		dev_err(&pdev->dev, "Invalid EMC sequence for table Rev. %d\n",
>> +			emc->emc_table[0].rev);
>> +		goto emc_clk_register;
> 
> Why do you want to register EMC clock if something fails? KMSG will be
> flooded with errors coming from clk_set_rate.
> 

See patch 7 in the series, the legacy EMC clock will be removed later, 
so we need to register the EMC clock whether the table is ready or not. 
In that case, I mean if the table is not available, it will still 
register EMC clock at the rate that boot loader configured before kernel 
booting. So the MC clock can still work as expected, which is under EMC 
clock.

And I did test that, couldn't observe any KMSG in that case.

Thanks,
Joseph

  reply	other threads:[~2019-05-15  8:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10  8:47 [PATCH V3 0/8] Add EMC scaling support for Tegra210 Joseph Lo
2019-05-10  8:47 ` [PATCH V3 1/8] dt-bindings: memory: tegra: Add external memory controller binding " Joseph Lo
2019-05-14 16:28   ` Dmitry Osipenko
2019-05-15  7:17     ` Joseph Lo
2019-05-15 13:50       ` Dmitry Osipenko
2019-05-16  9:01         ` Joseph Lo
2019-05-16 14:39           ` Dmitry Osipenko
2019-05-10  8:47 ` [PATCH V3 2/8] clk: tegra: Add PLLP_UD and PLLMB_UD " Joseph Lo
2019-05-10  8:47 ` [PATCH V3 3/8] clk: tegra: Export functions for EMC clock scaling Joseph Lo
2019-05-14 16:29   ` Dmitry Osipenko
2019-05-15  7:25     ` Joseph Lo
2019-05-10  8:47 ` [PATCH V3 4/8] memory: tegra: Add Tegra210 EMC clock driver Joseph Lo
2019-05-13 16:54   ` Dmitry Osipenko
2019-05-14  9:22     ` Joseph Lo
2019-05-14 17:04   ` Dmitry Osipenko
2019-05-15  8:42     ` Joseph Lo [this message]
2019-05-15 15:25       ` Dmitry Osipenko
2019-05-16  7:52         ` Joseph Lo
2019-05-16 14:29           ` Dmitry Osipenko
2019-05-10  8:47 ` [PATCH V3 5/8] memory: tegra: Add EMC scaling support code for Tegra210 Joseph Lo
2019-05-13 17:02   ` Dmitry Osipenko
2019-05-14  8:47     ` Joseph Lo
2019-05-14 16:30   ` Dmitry Osipenko
2019-05-15 14:09   ` Dmitry Osipenko
2019-05-15 15:26   ` Dmitry Osipenko
2019-05-10  8:47 ` [PATCH V3 6/8] memory: tegra: Add EMC scaling sequence " Joseph Lo
2019-05-10  8:47 ` [PATCH V3 7/8] clk: tegra: Remove the old emc_mux clock " Joseph Lo
2019-05-10  8:47 ` [PATCH V3 8/8] arm64: tegra: Add external memory controller node " Joseph Lo

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=648df201-eb63-6d26-3f90-02eba7624921@nvidia.com \
    --to=josephl@nvidia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=thierry.reding@gmail.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;
as well as URLs for NNTP newsgroup(s).