All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	Jason Cooper <jason@lakedaemon.net>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
	Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>,
	linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 1/4] cpufreq: Add a cpufreq driver for Marvell Dove
Date: Wed, 4 Dec 2013 16:27:26 +0100	[thread overview]
Message-ID: <20131204152726.GC8062@lunn.ch> (raw)
In-Reply-To: <20131204145413.GD29200@e106331-lin.cambridge.arm.com>

> > +static int dove_cpufreq_target(struct cpufreq_policy *policy,
> > +			       unsigned int index)
> > +{
> > +	unsigned int state = dove_freq_table[index].driver_data;
> > +	unsigned long reg, cr;
> > +
> > +	local_irq_disable();
> > +
> > +	/* Mask IRQ and FIQ to CPU */
> > +	cr = readl(priv.pmu_cr);
> > +	cr |= MASK_IRQ | MASK_FIQ;
> > +	writel(cr, priv.pmu_cr);
> > +
> > +	/* Set/Clear the CPU_SLOW_EN bit */
> > +	reg = readl_relaxed(priv.dfs + DFS_CR);
> > +	reg &= ~L2_RATIO_MASK;
> > +
> > +	switch (state) {
> > +	case STATE_CPU_FREQ:
> > +		reg |= priv.xpratio;
> > +		reg &= ~CPU_SLOW_EN;
> > +		break;
> > +	case STATE_DDR_FREQ:
> > +		reg |= (priv.dpratio | CPU_SLOW_EN);
> > +		break;
> > +	}
> > +
> > +	/* Start the DFS process */
> > +	reg |= DFS_EN;
> > +
> > +	writel(reg, priv.dfs + DFS_CR);
> > +
> > +	/* Wait-for-Interrupt, while the hardware changes frequency */
> > +	cpu_do_idle();
> > +
> > +	local_irq_enable();
> 
> Just to check -- does the PMU automatically unmask IRQ and FIQ? 

The data sheet says so, yes.

> > +static int dove_cpufreq_probe(struct platform_device *pdev)
> > +{
> > +	struct device *cpu_dev;
> > +	struct resource *res;
> > +	int err, irq;
> > +
> > +	memset(&priv, 0, sizeof(priv));
> > +	priv.dev = &pdev->dev;
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +					   "cpufreq: DFS");
> > +	priv.dfs = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(priv.dfs))
> > +		return PTR_ERR(priv.dfs);
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +					   "cpufreq: PMU CR");
> > +	priv.pmu_cr = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(priv.pmu_cr))
> > +		return PTR_ERR(priv.pmu_cr);
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +					   "cpufreq: PMU Clk Div");
> > +	priv.pmu_clk_div = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(priv.pmu_clk_div))
> > +		return PTR_ERR(priv.pmu_clk_div);
> 
> I'd very much prefer that the PMU were described in the DT, and the
> driver probed based on that.

Please see my other response. We can discuss that there.
 
> > +
> > +	cpu_dev = get_cpu_device(0);
> > +
> > +	priv.cpu_clk = devm_clk_get(cpu_dev, "cpu_clk");
> > +	if (IS_ERR(priv.cpu_clk)) {
> > +		err = PTR_ERR(priv.cpu_clk);
> > +		goto out;
> > +	}
> 
> I think it would be better to describe the clocks as being fed to the
> PMU than directly to the CPU -- the PMU selects the appropriate clock
> and feeds it to the CPU.

The wording in the data sheet is not very clear:

    The PMU initiates new clock ratio values for the CPU subsystem
    clocks generation unit.

So to me, the PMU is not the clock consumer, it just controls the
clock generation unit. There is also a block diagram which shows the
"CPU Subsystem ClockGen" as being external to the PMU.
 
> Also, the clocks could be named better with respect to their logical
> function. One is the high-frequency default, and the other is a
> low-frequency option. They're both able to feed the CPU, and the fact
> that one also feeds the DDR isn't relevant to the CPU.

The data sheet uses the terms Turbo Speed and Slow Speed modes. So i
could call them turbo and slow? However, the current names follow the
kirkwood cpufreq driver. It also can swap between a fast clock and the
DDR clock. So i thought keeping the drivers similar would help with
the maintenance burden. 

    Andrew

WARNING: multiple messages have this Message-ID (diff)
From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/4] cpufreq: Add a cpufreq driver for Marvell Dove
Date: Wed, 4 Dec 2013 16:27:26 +0100	[thread overview]
Message-ID: <20131204152726.GC8062@lunn.ch> (raw)
In-Reply-To: <20131204145413.GD29200@e106331-lin.cambridge.arm.com>

> > +static int dove_cpufreq_target(struct cpufreq_policy *policy,
> > +			       unsigned int index)
> > +{
> > +	unsigned int state = dove_freq_table[index].driver_data;
> > +	unsigned long reg, cr;
> > +
> > +	local_irq_disable();
> > +
> > +	/* Mask IRQ and FIQ to CPU */
> > +	cr = readl(priv.pmu_cr);
> > +	cr |= MASK_IRQ | MASK_FIQ;
> > +	writel(cr, priv.pmu_cr);
> > +
> > +	/* Set/Clear the CPU_SLOW_EN bit */
> > +	reg = readl_relaxed(priv.dfs + DFS_CR);
> > +	reg &= ~L2_RATIO_MASK;
> > +
> > +	switch (state) {
> > +	case STATE_CPU_FREQ:
> > +		reg |= priv.xpratio;
> > +		reg &= ~CPU_SLOW_EN;
> > +		break;
> > +	case STATE_DDR_FREQ:
> > +		reg |= (priv.dpratio | CPU_SLOW_EN);
> > +		break;
> > +	}
> > +
> > +	/* Start the DFS process */
> > +	reg |= DFS_EN;
> > +
> > +	writel(reg, priv.dfs + DFS_CR);
> > +
> > +	/* Wait-for-Interrupt, while the hardware changes frequency */
> > +	cpu_do_idle();
> > +
> > +	local_irq_enable();
> 
> Just to check -- does the PMU automatically unmask IRQ and FIQ? 

The data sheet says so, yes.

> > +static int dove_cpufreq_probe(struct platform_device *pdev)
> > +{
> > +	struct device *cpu_dev;
> > +	struct resource *res;
> > +	int err, irq;
> > +
> > +	memset(&priv, 0, sizeof(priv));
> > +	priv.dev = &pdev->dev;
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +					   "cpufreq: DFS");
> > +	priv.dfs = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(priv.dfs))
> > +		return PTR_ERR(priv.dfs);
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +					   "cpufreq: PMU CR");
> > +	priv.pmu_cr = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(priv.pmu_cr))
> > +		return PTR_ERR(priv.pmu_cr);
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +					   "cpufreq: PMU Clk Div");
> > +	priv.pmu_clk_div = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(priv.pmu_clk_div))
> > +		return PTR_ERR(priv.pmu_clk_div);
> 
> I'd very much prefer that the PMU were described in the DT, and the
> driver probed based on that.

Please see my other response. We can discuss that there.
 
> > +
> > +	cpu_dev = get_cpu_device(0);
> > +
> > +	priv.cpu_clk = devm_clk_get(cpu_dev, "cpu_clk");
> > +	if (IS_ERR(priv.cpu_clk)) {
> > +		err = PTR_ERR(priv.cpu_clk);
> > +		goto out;
> > +	}
> 
> I think it would be better to describe the clocks as being fed to the
> PMU than directly to the CPU -- the PMU selects the appropriate clock
> and feeds it to the CPU.

The wording in the data sheet is not very clear:

    The PMU initiates new clock ratio values for the CPU subsystem
    clocks generation unit.

So to me, the PMU is not the clock consumer, it just controls the
clock generation unit. There is also a block diagram which shows the
"CPU Subsystem ClockGen" as being external to the PMU.
 
> Also, the clocks could be named better with respect to their logical
> function. One is the high-frequency default, and the other is a
> low-frequency option. They're both able to feed the CPU, and the fact
> that one also feeds the DDR isn't relevant to the CPU.

The data sheet uses the terms Turbo Speed and Slow Speed modes. So i
could call them turbo and slow? However, the current names follow the
kirkwood cpufreq driver. It also can swap between a fast clock and the
DDR clock. So i thought keeping the drivers similar would help with
the maintenance burden. 

    Andrew

  reply	other threads:[~2013-12-04 15:27 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04 14:17 [PATCH v4 0/4] Dove cpufreq driver Andrew Lunn
2013-12-04 14:17 ` Andrew Lunn
2013-12-04 14:17 ` [PATCH v4 1/4] cpufreq: Add a cpufreq driver for Marvell Dove Andrew Lunn
2013-12-04 14:17   ` Andrew Lunn
2013-12-04 14:33   ` Jason Cooper
2013-12-04 14:33     ` Jason Cooper
2013-12-04 14:56     ` Andrew Lunn
2013-12-04 14:56       ` Andrew Lunn
2013-12-04 15:01       ` Jason Cooper
2013-12-04 15:01         ` Jason Cooper
2013-12-04 14:54   ` Mark Rutland
2013-12-04 14:54     ` Mark Rutland
2013-12-04 15:27     ` Andrew Lunn [this message]
2013-12-04 15:27       ` Andrew Lunn
2013-12-05 18:23       ` Mark Rutland
2013-12-05 18:23         ` Mark Rutland
2013-12-17 21:41     ` [RFC PATCH v5 0/4] Dove Cpufreq driver Andrew Lunn
2013-12-17 21:41       ` Andrew Lunn
2013-12-17 21:41       ` [RFC PATCH v5 1/4] cpufreq: Add a cpufreq driver for Marvell Dove Andrew Lunn
2013-12-17 21:41         ` Andrew Lunn
2013-12-20  3:32         ` Jason Cooper
2013-12-20  3:32           ` Jason Cooper
2013-12-21 16:26           ` Andrew Lunn
2013-12-21 16:26             ` Andrew Lunn
2013-12-21 19:25             ` Jason Cooper
2013-12-21 19:25               ` Jason Cooper
2013-12-21 21:54               ` Andrew Lunn
2013-12-21 21:54                 ` Andrew Lunn
2013-12-22  4:00                 ` Jason Cooper
2013-12-22  4:00                   ` Jason Cooper
2013-12-17 21:41       ` [RFC PATCH v5 2/4] mvebu: Dove: Indicate the architecture supports cpufreq Andrew Lunn
2013-12-17 21:41         ` Andrew Lunn
2013-12-17 21:41       ` [RFC PATCH v5 3/4] mvebu: Dove: Enable cpufreq driver in defconfig Andrew Lunn
2013-12-17 21:41         ` Andrew Lunn
2013-12-17 21:41       ` [RFC PATCH v5 4/4] mvebu: Dove: Add PMU node for cpufreq driver Andrew Lunn
2013-12-17 21:41         ` Andrew Lunn
2013-12-16  8:40   ` [PATCH v4 1/4] cpufreq: Add a cpufreq driver for Marvell Dove Viresh Kumar
2013-12-16  8:40     ` Viresh Kumar
2013-12-17 22:06     ` Andrew Lunn
2013-12-17 22:06       ` Andrew Lunn
2013-12-04 14:17 ` [PATCH v4 2/4] mvebu: Dove: Instantiate cpufreq driver Andrew Lunn
2013-12-04 14:17   ` Andrew Lunn
2013-12-04 14:36   ` Mark Rutland
2013-12-04 14:36     ` Mark Rutland
2013-12-04 15:02     ` Andrew Lunn
2013-12-04 15:02       ` Andrew Lunn
2013-12-05 17:54       ` Mark Rutland
2013-12-05 17:54         ` Mark Rutland
2013-12-05 18:29         ` Andrew Lunn
2013-12-05 18:29           ` Andrew Lunn
2013-12-08  0:50           ` Jason Cooper
2013-12-08  0:50             ` Jason Cooper
2013-12-04 14:17 ` [PATCH v4 3/4] mvebu: Dove: Enable cpufreq driver in defconfig Andrew Lunn
2013-12-04 14:17   ` Andrew Lunn
2013-12-04 14:17 ` [PATCH v4 4/4] mvebu: Dove: Add clocks and DFS interrupt to cpu node in DT Andrew Lunn
2013-12-04 14:17   ` Andrew Lunn
2013-12-04 14:39   ` Mark Rutland
2013-12-04 14:39     ` Mark Rutland
2013-12-04 14:55     ` Mark Rutland
2013-12-04 14:55       ` Mark Rutland
2013-12-04 14:43   ` Jason Cooper
2013-12-04 14:43     ` Jason Cooper

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=20131204152726.GC8062@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=sebastian.hesselbarth@googlemail.com \
    --cc=viresh.kumar@linaro.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 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.