* [GIT PULL v2] Renesas ARM Based SoC Boards Cleanups for v3.17
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM based SoC boards cleanups for v3.17.
This pull request is based on
"Renesas ARM Based SoC DT Timers Updates for v3.17",
tagged as renesas-dt-timers-for-v3.17,
which I have sent a pull request for.
In this pull-request cleanups are added on top of new development
due to the order in which the code was developed. In general
we prefer the reverse ordering.
v2 of this pull request is a rebase of v1 removing
a merge of defconfig changes at the base of the pull-request.
The motivation for that was to avoid attempts to use
genmai_defconfig after the board code it relies on has been removed.
Olof indicated he would prefer not to add that dependency.
The following changes since commit 9394af4314554d15762585a3464cefaa2e6d0420:
ARM: shmobile: genmai-reference: Enable MTU2 in device tree (2014-07-15 21:26:42 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-cleanup-boards-for-v3.17
for you to fetch changes up to d2904bb7cd21844ff5e720083b59a344487fcc9b:
ARM: shmobile: r7s72100: Remove legacy board support (2014-07-24 10:32:53 +0900)
----------------------------------------------------------------
Renesas ARM Based SoC Boards Cleanups for v3.17
d2904bb ARM: shmobile: r7s72100: Remove legacy board support
6f86033 ARM: shmobile: r7s72100: genmai: Remove legacy board file
5cebb8e ARM: shmobile: r7s72100: genmai: Remove reference board file
----------------------------------------------------------------
Laurent Pinchart (3):
ARM: shmobile: r7s72100: genmai: Remove reference board file
ARM: shmobile: r7s72100: genmai: Remove legacy board file
ARM: shmobile: r7s72100: Remove legacy board support
arch/arm/mach-shmobile/Kconfig | 17 --
arch/arm/mach-shmobile/Makefile | 3 -
arch/arm/mach-shmobile/Makefile.boot | 1 -
arch/arm/mach-shmobile/board-genmai-reference.c | 35 ----
arch/arm/mach-shmobile/board-genmai.c | 174 ------------------
arch/arm/mach-shmobile/clock-r7s72100.c | 231 ------------------------
arch/arm/mach-shmobile/r7s72100.h | 6 -
arch/arm/mach-shmobile/setup-r7s72100.c | 2 -
8 files changed, 469 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/board-genmai-reference.c
delete mode 100644 arch/arm/mach-shmobile/board-genmai.c
delete mode 100644 arch/arm/mach-shmobile/clock-r7s72100.c
delete mode 100644 arch/arm/mach-shmobile/r7s72100.h
^ permalink raw reply
* [PATCH 5/5] ARM: shmobile: sh73a0: add CMT1 clock support for DT
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1406164563.git.horms+renesas@verge.net.au>
This will be used when initialising CMT1 device using DT
until common clock framework support is added.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/clock-sh73a0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 4990e03..0d77f65 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -690,6 +690,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_ICK_ID("dsiphy_clk", "sh-mipi-dsi.0", &dsi0phy_clk),
CLKDEV_ICK_ID("dsiphy_clk", "sh-mipi-dsi.1", &dsi1phy_clk),
CLKDEV_ICK_ID("fck", "sh-cmt-48.1", &mstp_clks[MSTP329]), /* CMT1 */
+ CLKDEV_ICK_ID("fck", "e6138000.timer", &mstp_clks[MSTP329]), /* CMT1 */
CLKDEV_ICK_ID("fck", "sh-tmu.0", &mstp_clks[MSTP125]), /* TMU0 */
};
--
2.0.1
^ permalink raw reply related
* [PATCH 4/5] ARM: shmobile: r8a7740: add CMT1 clock support for DT
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1406164563.git.horms+renesas@verge.net.au>
This will be used when initialising CMT1 device using DT
until common clock framework support is added.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/clock-r8a7740.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 3f34b3f..2ffb560 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -602,6 +602,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_ICK_ID("fck", "sh-tmu.0", &mstp_clks[MSTP125]),
CLKDEV_ICK_ID("fck", "fff80000.timer", &mstp_clks[MSTP125]),
CLKDEV_ICK_ID("fck", "sh-cmt-48.1", &mstp_clks[MSTP329]),
+ CLKDEV_ICK_ID("fck", "e6138000.timer", &mstp_clks[MSTP329]),
CLKDEV_ICK_ID("host", "renesas_usbhs", &mstp_clks[MSTP416]),
CLKDEV_ICK_ID("func", "renesas_usbhs", &mstp_clks[MSTP407]),
CLKDEV_ICK_ID("phy", "renesas_usbhs", &mstp_clks[MSTP406]),
--
2.0.1
^ permalink raw reply related
* [PATCH 3/5] ARM: shmobile: r8a73a4: add CMT1 clock support for DT
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1406164563.git.horms+renesas@verge.net.au>
This will be used when initialising CMT1 device using DT
until common clock framework support is added.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/clock-r8a73a4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index 1d2fe05..9629851 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -604,6 +604,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("e6500000.i2c", &mstp_clks[MSTP318]),
CLKDEV_DEV_ID("e6510000.i2c", &mstp_clks[MSTP323]),
CLKDEV_ICK_ID("fck", "sh-cmt-48-gen2.1", &mstp_clks[MSTP329]),
+ CLKDEV_ICK_ID("fck", "e6130000.timer", &mstp_clks[MSTP329]),
CLKDEV_DEV_ID("e60b0000.i2c", &mstp_clks[MSTP409]),
CLKDEV_DEV_ID("e6540000.i2c", &mstp_clks[MSTP410]),
CLKDEV_DEV_ID("e6530000.i2c", &mstp_clks[MSTP411]),
--
2.0.1
^ permalink raw reply related
* [PATCH 2/5] ARM: shmobile: r8a7740: add TMU clock support for DT
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1406164563.git.horms+renesas@verge.net.au>
This will be used when initialising TMU devices using DT
until common clock framework support is added.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/clock-r8a7740.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 68592b7..3f34b3f 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -598,7 +598,9 @@ static struct clk_lookup lookups[] = {
/* ICK */
CLKDEV_ICK_ID("fck", "sh-tmu.1", &mstp_clks[MSTP111]),
+ CLKDEV_ICK_ID("fck", "fff90000.timer", &mstp_clks[MSTP111]),
CLKDEV_ICK_ID("fck", "sh-tmu.0", &mstp_clks[MSTP125]),
+ CLKDEV_ICK_ID("fck", "fff80000.timer", &mstp_clks[MSTP125]),
CLKDEV_ICK_ID("fck", "sh-cmt-48.1", &mstp_clks[MSTP329]),
CLKDEV_ICK_ID("host", "renesas_usbhs", &mstp_clks[MSTP416]),
CLKDEV_ICK_ID("func", "renesas_usbhs", &mstp_clks[MSTP407]),
--
2.0.1
^ permalink raw reply related
* [PATCH 1/5] ARM: shmobile: r8a7778: add TMU clock support for DT
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1406164563.git.horms+renesas@verge.net.au>
This will be used when initialising TMU devices using DT
until common clock framework support is added.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/clock-r8a7778.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a7778.c b/arch/arm/mach-shmobile/clock-r8a7778.c
index a6dd601..9407bac 100644
--- a/arch/arm/mach-shmobile/clock-r8a7778.c
+++ b/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -244,7 +244,9 @@ static struct clk_lookup lookups[] = {
CLKDEV_ICK_ID("src.7", "rcar_sound", &mstp_clks[MSTP524]),
CLKDEV_ICK_ID("src.8", "rcar_sound", &mstp_clks[MSTP523]),
CLKDEV_ICK_ID("fck", "sh-tmu.0", &mstp_clks[MSTP016]),
+ CLKDEV_ICK_ID("fck", "ffd80000.timer", &mstp_clks[MSTP016]),
CLKDEV_ICK_ID("fck", "sh-tmu.1", &mstp_clks[MSTP015]),
+ CLKDEV_ICK_ID("fck", "ffd81000.timer", &mstp_clks[MSTP015]),
};
void __init r8a7778_clock_init(void)
--
2.0.1
^ permalink raw reply related
* [GIT PULL] Third Round of Renesas ARM Based SoC Clock Updates for v3.17
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these third round of Renesas ARM based SoC clock updates for v3.17.
This pull request is based on the previous round of
such requests, tagged as renesas-clock2-for-v3.17,
which has already been pulled into the next/soc branch of arm-soc.
I apologise that this is being sent after the release of v3.16-rc6.
It has been queued up in next since well before then and not
sending this pull-request was an oversight on my part.
The now-tagged branch of this pull-requests is one of the branched merged
to form a base for "Renesas ARM Based SoC DT Timers Updates for v3.17". And
I believe its absence is the cause of the problem you flagged with regards
to the presence of changes outside of those listed for that pull-request.
The following changes since commit ff4ce48e1f163d945c037c1c90ce12950961d91d:
ARM: shmobile: sh73a0: add SCI clock support for DT (2014-07-12 15:15:39 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-clock3-for-v3.17
for you to fetch changes up to a0f7e7496d56ac2da7c684e2035815318c17973a:
ARM: shmobile: sh73a0: add CMT1 clock support for DT (2014-07-15 13:34:17 +0900)
----------------------------------------------------------------
Third Round of Renesas ARM Based SoC Clock Updates for v3.17
* Add legacy clocks for SCI for SoCs that do not yet have CCF support.
This is to allow timer devices to be enabled using DT and
will be removed after CCF support is added for each SoC.
This is in keeping with the approach taken for enabling
SCI (serial) devices using DT on these SoCs.
----------------------------------------------------------------
Simon Horman (5):
ARM: shmobile: r8a7778: add TMU clock support for DT
ARM: shmobile: r8a7740: add TMU clock support for DT
ARM: shmobile: r8a73a4: add CMT1 clock support for DT
ARM: shmobile: r8a7740: add CMT1 clock support for DT
ARM: shmobile: sh73a0: add CMT1 clock support for DT
arch/arm/mach-shmobile/clock-r8a73a4.c | 1 +
arch/arm/mach-shmobile/clock-r8a7740.c | 3 +++
arch/arm/mach-shmobile/clock-r8a7778.c | 2 ++
arch/arm/mach-shmobile/clock-sh73a0.c | 1 +
4 files changed, 7 insertions(+)
^ permalink raw reply
* [PATCH] ARM: shmobile: r8a7791: Fix SD2CKCR register address
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1406162627.git.horms+renesas@verge.net.au>
From: Shinobu Uehara <shinobu.uehara.xc@renesas.com>
59e79895b95892863617ce630fbda467f2470575
(ARM: shmobile: r8a7791: Add clocks)
added r8a7791 SD clocks when v3.14.
2c60a7df72711fb8b4be1e6aa651ab166a8931bc
(ARM: shmobile: Add SDHI devices for Koelsch DTS)
enabled SD on r8a7791 Koelsch when v3.15.
1299df03d7191ab4356c995dde8b912d3c8922e9
(ARM: shmobile: henninger: add SDHI0/2 DT support)
enable SD on r8a7791 Henninger when v3.16.
But r8a7791 SD clock had wrong address.
This patch fixup it.
[Kuninori Morimoto: tidyup for upstreaming]
Signed-off-by: Shinobu Uehara <shinobu.uehara.xc@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 8d7ffae..79f68ac 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -540,9 +540,9 @@
#clock-cells = <0>;
clock-output-names = "sd1";
};
- sd2_clk: sd3_clk at e615007c {
+ sd2_clk: sd3_clk at e615026c {
compatible = "renesas,r8a7791-div6-clock", "renesas,cpg-div6-clock";
- reg = <0 0xe615007c 0 4>;
+ reg = <0 0xe615026c 0 4>;
clocks = <&pll1_div2_clk>;
#clock-cells = <0>;
clock-output-names = "sd2";
--
2.0.1
^ permalink raw reply related
* [GIT PULL] Second Round of Renesas ARM Based SoC Fixes for v3.16
From: Simon Horman @ 2014-07-24 1:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these second round of Renesas ARM based SoC fixes for v3.16.
The first round of fixes was prior to the release of v3.16-rc1 so
this pull-request is based on v3.16-rc1.
I would like this change considered for v3.15-stable.
I can handle submitting it there if you like.
I do not think it is necessary to consider it for v3.14-stable
as although the incorrect code is present there it is not exercised
in that release.
The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-fixes2-for-v3.16
for you to fetch changes up to c9b227723d051184b9e78f20c75ae2f9d44a6ea2:
ARM: shmobile: r8a7791: Fix SD2CKCR register address (2014-07-23 08:55:12 +0900)
----------------------------------------------------------------
Second Round of Renesas ARM Based SoC Fixes for v3.16
* Fix SD2CKCR register address of r8a7791 (R-Car M2) SoC
This corrects a bug introduced in v3.14 by
59e79895b9589286 ("ARM: shmobile: r8a7791: Add clocks").
However, it does not manifest in mainline code until
SDHI devices were enabled on the Koelsch board in v3.15 by
2c60a7df72711fb8 ("ARM: shmobile: Add SDHI devices for Koelsch DTS").
It also manifests on the Henninger board when
SDHI devices were enabled in v3.16-rc1 by
1299df03d7191ab4 ("ARM: shmobile: henninger: add SDHI0/2 DT support")
----------------------------------------------------------------
Shinobu Uehara (1):
ARM: shmobile: r8a7791: Fix SD2CKCR register address
arch/arm/boot/dts/r8a7791.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 3/3] crypto: Add Allwinner Security System crypto accelerator
From: Herbert Xu @ 2014-07-24 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407232138.35268.marex@denx.de>
On Wed, Jul 23, 2014 at 09:38:35PM +0200, Marek Vasut wrote:
> On Wednesday, July 23, 2014 at 08:52:12 PM, Corentin LABBE wrote:
> > Le 23/07/2014 17:51, Marek Vasut a ?crit :
> > > On Wednesday, July 23, 2014 at 04:13:09 PM, Herbert Xu wrote:
> > >> On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
> > >>> On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> > >>>> On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> > >>>>>> + }
> > >>>>>> +#endif
> > >>>>>> +
> > >>>>>> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> > >>>>>> + err = crypto_register_shash(&sunxi_md5_alg);
> > >>>>>
> > >>>>> Do not use shash for such device. This is clearly and ahash (and
> > >>>>> async in general) device. The rule of a thumb here is that you use
> > >>>>> sync algos only for devices which have dedicated instructions for
> > >>>>> computing the transformation. For devices which are attached to some
> > >>>>> kind of bus, you use async algos (ahash etc).
> > >>>>
> > >>>> I'm sorry that I didn't catch this earlier but there is no such
> > >>>> rule.
> > >>>>
> > >>>> Unless you need the async interface you should stick to the sync
> > >>>> interfaces for the sake of simplicity.
> > >>>>
> > >>>> We have a number of existing drivers that are synchronous but
> > >>>> using the async interface. They should either be converted
> > >>>> over to the sync interface or made interrupt-driven if possible.
> > >>>
> > >>> Sure, but this device is interrupt driven and uses DMA to feed the
> > >>> crypto engine, therefore async, right ?
> > >>
> > >> If it's interrupt-driven, then yes it would certainly make sense to
> > >> be async. But all I see is polling in the latest posting, was the
> > >> first version different?
> > >
> > > I stand corrected then, sorry.
> > >
> > > Is it possible to use DMA to feed the crypto accelerator, Corentin?
> > >
> > > Best regards,
> > > Marek Vasut
> >
> > Yes, DMA is possible and will be implemented soon.
> > So if I have well understood, I keep using async interface.
>
> Yeah, in this case, using DMA and async interface combo is the way to go.
OK fair enough.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* DMA engine API issue (was: [PATCH/RFC 0/5] R-Car Gen2 DMAC hardware descriptor list support)
From: Kuninori Morimoto @ 2014-07-24 1:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wqb3a8jd.wl%kuninori.morimoto.gx@gmail.com>
Hi Laurent again
> > > The rsnd_soc_dai_trigger() function takes a spinlock, making the context
> > > atomic, which regmap doesn't like as it locks a mutex.
> > >
> > > It might be possible to fix this by setting the fast_io field in both the
> > > regmap_config and regmap_bus structures in sound/soc/sh/rcar/gen.c. regmap
> > > will then use a spinlock instead of a mutex. However, even if I believe that
> > > change makes sense and should be done, another atomic context issue will
> > > come from the rcar-dmac driver which allocates memory in the
> > > prep_dma_cyclic function, called by rsnd_dma_start() from
> > > rsnd_soc_dai_trigger() with the spinlock help.
> > >
> > > What context is the rsnd_soc_dai_trigger() function called in by the alsa
> > > core ? If it's guaranteed to be a sleepable context, would it make sense to
> > > replace the rsnd_priv spinlock with a mutex ?
> >
> > Answering myself here, that's not an option, as the trigger function is called
> > in atomic context (replacing the spinlock with a mutex produced a clear BUG)
> > due to snd_pcm_lib_write1() taking a spinlock.
> >
> > Now we have a core issue. On one side there's rsnd_soc_dai_trigger() being
> > called in atomic context, and on the other side the function ends up calling
> > dmaengine_prep_dma_cyclic() which needs to allocate memory. To make this more
> > func the DMA engine API is undocumented and completely silent on whether the
> > prep functions are allowed to sleep. The question is, who's wrong ?
> >
> > Now, if you're tempted to say that I'm wrong by allocating memory with
> > GFP_KERNEL in the DMA engine driver, please read on first :-) I've tried
> > replacing GFP_KERNEL with GFP_ATOMIC allocations, and then ran into a problem
> > more complex to solve.
> >
> > The rcar-dmac DMA engine driver uses runtime PM. When not used, the device is
> > suspended. The driver calls pm_runtime_get_sync() to resume the device, and
> > needs to do so when a descriptor is submitted. This operation, currently
> > performed in the tx_submit handler, could be moved to the prep_dma_cyclic or
> > issue_pending handler, but the three operations are called in a row from
> > rsnd_dma_start(), itself ultimately called from snd_pcm_lib_write1() with the
> > spinlock held. This means I have no place in my DMA engine driver where I can
> > resume the device.
> >
> > One could argue that the rcar-dmac driver could use a work queue to handle
> > power management. That's correct, but the additional complexity, which would
> > be required in *all* DMA engine drivers, seem too high to me. If we need to go
> > that way, this is really a task that the DMA engine core should handle.
> >
> > Let's start by answering the background question and updating the DMA engine
> > API documentation once and for good : in which context are drivers allowed to
> > call the prep, tx_submit and issue_pending functions ?
>
> rsnd driver (and sound/soc/sh/fsi driver too) is using prep_dma_cyclic() now,
> but, it had been used prep_slave_single() before.
> Then, it used work queue in dai_trigger function.
> How about to use same method in prep_dma_cyclic() ?
> Do you think your issue will be solved if sound driver calls prep_dma_cyclic()
> from work queue ?
Sorry, this doesn't solve issue.
dmaengine_prep_dma_cyclic() is used in
${LINUX}/sound/core/pcm_dmaengine.c,
and the situation is same as ours.
Hmm..
In my quick check, other DMAEngine drivers are using GFP_ATOMIC
in cyclic/prep_slave_sg functions...
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* DMA engine API issue (was: [PATCH/RFC 0/5] R-Car Gen2 DMAC hardware descriptor list support)
From: Kuninori Morimoto @ 2014-07-24 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28702317.aD0C1Ga3DS@avalon>
Hi Laurent
> > The rsnd_soc_dai_trigger() function takes a spinlock, making the context
> > atomic, which regmap doesn't like as it locks a mutex.
> >
> > It might be possible to fix this by setting the fast_io field in both the
> > regmap_config and regmap_bus structures in sound/soc/sh/rcar/gen.c. regmap
> > will then use a spinlock instead of a mutex. However, even if I believe that
> > change makes sense and should be done, another atomic context issue will
> > come from the rcar-dmac driver which allocates memory in the
> > prep_dma_cyclic function, called by rsnd_dma_start() from
> > rsnd_soc_dai_trigger() with the spinlock help.
> >
> > What context is the rsnd_soc_dai_trigger() function called in by the alsa
> > core ? If it's guaranteed to be a sleepable context, would it make sense to
> > replace the rsnd_priv spinlock with a mutex ?
>
> Answering myself here, that's not an option, as the trigger function is called
> in atomic context (replacing the spinlock with a mutex produced a clear BUG)
> due to snd_pcm_lib_write1() taking a spinlock.
>
> Now we have a core issue. On one side there's rsnd_soc_dai_trigger() being
> called in atomic context, and on the other side the function ends up calling
> dmaengine_prep_dma_cyclic() which needs to allocate memory. To make this more
> func the DMA engine API is undocumented and completely silent on whether the
> prep functions are allowed to sleep. The question is, who's wrong ?
>
> Now, if you're tempted to say that I'm wrong by allocating memory with
> GFP_KERNEL in the DMA engine driver, please read on first :-) I've tried
> replacing GFP_KERNEL with GFP_ATOMIC allocations, and then ran into a problem
> more complex to solve.
>
> The rcar-dmac DMA engine driver uses runtime PM. When not used, the device is
> suspended. The driver calls pm_runtime_get_sync() to resume the device, and
> needs to do so when a descriptor is submitted. This operation, currently
> performed in the tx_submit handler, could be moved to the prep_dma_cyclic or
> issue_pending handler, but the three operations are called in a row from
> rsnd_dma_start(), itself ultimately called from snd_pcm_lib_write1() with the
> spinlock held. This means I have no place in my DMA engine driver where I can
> resume the device.
>
> One could argue that the rcar-dmac driver could use a work queue to handle
> power management. That's correct, but the additional complexity, which would
> be required in *all* DMA engine drivers, seem too high to me. If we need to go
> that way, this is really a task that the DMA engine core should handle.
>
> Let's start by answering the background question and updating the DMA engine
> API documentation once and for good : in which context are drivers allowed to
> call the prep, tx_submit and issue_pending functions ?
rsnd driver (and sound/soc/sh/fsi driver too) is using prep_dma_cyclic() now,
but, it had been used prep_slave_single() before.
Then, it used work queue in dai_trigger function.
How about to use same method in prep_dma_cyclic() ?
Do you think your issue will be solved if sound driver calls prep_dma_cyclic()
from work queue ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Kexec on arm64
From: Geoff Levand @ 2014-07-24 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFdej00J2mJwcg2Cy6CHVuuQZ4uQ2zZg8oErGPi0uPejievB+Q@mail.gmail.com>
Hi Arun,
On Tue, 2014-07-22 at 18:55 +0530, Arun Chandran wrote:
> I tried the same dtb with UP configuration. For UP kernel to compile
> did the below modifications
I'll test and fixup the kexec UP build in the next few days.
...
> With the default target configuration "kexec -e" failed to execute
> in UP scenario also.
>
> But I had some luck when I did the same steps with L3 cache
> disabled. According to http://www.spinics.net/lists/arm-kernel/msg329541.html
> it has an L3 cache. Luckily I was able to disable it in u-boot.
>
> With the L3 cache disabled configuration I am able to
> do "kexec -e". Please see the log attached.
All memory management for the main cpu is done by the arch code. Kexec
and cpu hot plug only work with the secondary cpus, so the problem would
be in the arch memory code, either in setup_restart() for shutdown, or
in the startup code.
I guess setup_restart() is not doing something it needs to do for your
platform.
-Geoff
^ permalink raw reply
* [RFC] cpufreq: Add bindings for CPU clock sharing topology
From: Mike Turquette @ 2014-07-24 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpok-C+JCebjJkZExx6EjBctoyJF7fV71Vjj7bi1TAdXrFQ@mail.gmail.com>
Quoting Viresh Kumar (2014-07-20 05:07:32)
> On 19 July 2014 20:54, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> > Sorry for jumping late
>
> No, you aren't late. Its just 2 days old thread :)
>
> > but one of the point I was raising as part of your
> > other series was to extend the CPU topology bindings to cover the voltage
> > domain information which is probably what is really needed to let the
> > CPUfreq extract the information. Not sure if it was already discussed.
>
> Not it wasn't.
>
> > After all the CPU clocks, cluster, clock-gating, power domains are pretty much
> > related. So instead of having new binding for CPUFreq, I was wondering whether
> > we can extend the CPU topology binding information to include missing information.
> > Scheduler work anyway needs that information.
> >
> > Ref: Documentation/devicetree/bindings/arm/topology.txt
> >
> > Does that make sense ?
>
> Yeah it does, but I am not sure what exactly the bindings should look then.
> So, the most basic step could be moving the new bindings to topology.txt
> and name clock-master to dvfs-master.
>
> What else?
If we're going to model the hardware then the binding should not use the
CPU phandles in "clock-master" or "dvfs-master". The correct thing to
model for a given CPU is which clock consumes. It's not accurate to say
that one CPU is the "master", at least not in this context.
A previous approach tried to compare struct clk pointers, which is a bad
idea since those are just cookies and should not be deref'd by drivers.
However a similar approach would be to compare the phandle, right?
Regards,
Mike
>
> If its going to be much controversial then we *can* go for just dvfs bindings
> for now and then update them later.
>
> Doesn't make sense? :)
^ permalink raw reply
* [PATCH v2 1/2] clk: samsung: exynos4: Enable ARMCLK down feature
From: Mike Turquette @ 2014-07-24 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405694193-29643-1-git-send-email-k.kozlowski@samsung.com>
Quoting Krzysztof Kozlowski (2014-07-18 07:36:32)
> Enable ARMCLK down feature on all Exynos4 SoCs. The frequency of
> ARMCLK will be reduced upon entering idle mode (WFI or WFE).
>
> The feature behaves like very fast cpufreq ondemand governor. In idle
> mode this reduces energy consumption on full frequency chosen by
> cpufreq governor by approximately:
> - Trats2: 6.5% (153 mA -> 143 mA)
> - Trats: 33.0% (180 mA -> 120 mA)
> - Gear1: 27.0% (180 mA -> 130 mA)
Nice power savings! Just a quick question on this feature: the clock
frequency is changed in hardware as a result of WFI/WFE? And this only
happens when all CPUs in a cluster (e.g. all 4 CPUs in Exynos 4412) are
in WFI/WFE state?
Thanks,
Mike
>
> The patch uses simillar settings as Exynos5250 (clk-exynos5250.c),
> except it disables clock up feature and on Exynos4412 ARMCLK down is
> enabled for all 4 cores.
>
> Tested on Trats board (Exynos4210), Trats2 board (Exynos4412) and
> Samsung Gear 1 (Exynos4212).
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>
> ---
>
> Changes since v1:
> 1. Add PWR_CTRL registers to the list of saved clk registers on
> Exynos4x12. Suggested by Tomasz Figa.
> 2. Disable the clock up feature. (sug. Tomasz Figa)
> 3. Use macros for setting clock down ratio. (sug. Tomasz Figa)
> 4. Use num_possible_cpus() for exception on Exynos4x12. (sug. Tomasz
> Figa)
> 5. Enable the clock down feature also on Exynos4210 Trats board.
> ---
> drivers/clk/samsung/clk-exynos4.c | 46 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
> index 7f4a473a7ad7..86c7709dc6d6 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -114,11 +114,27 @@
> #define DIV_CPU1 0x14504
> #define GATE_SCLK_CPU 0x14800
> #define GATE_IP_CPU 0x14900
> +#define PWR_CTRL1 0x15020
> +#define E4X12_PWR_CTRL2 0x15024
> #define E4X12_DIV_ISP0 0x18300
> #define E4X12_DIV_ISP1 0x18304
> #define E4X12_GATE_ISP0 0x18800
> #define E4X12_GATE_ISP1 0x18804
>
> +/* Below definitions are used for PWR_CTRL settings */
> +#define PWR_CTRL1_CORE2_DOWN_RATIO(x) (((x) & 0x7) << 28)
> +#define PWR_CTRL1_CORE1_DOWN_RATIO(x) (((x) & 0x7) << 16)
> +#define PWR_CTRL1_DIV2_DOWN_EN (1 << 9)
> +#define PWR_CTRL1_DIV1_DOWN_EN (1 << 8)
> +#define PWR_CTRL1_USE_CORE3_WFE (1 << 7)
> +#define PWR_CTRL1_USE_CORE2_WFE (1 << 6)
> +#define PWR_CTRL1_USE_CORE1_WFE (1 << 5)
> +#define PWR_CTRL1_USE_CORE0_WFE (1 << 4)
> +#define PWR_CTRL1_USE_CORE3_WFI (1 << 3)
> +#define PWR_CTRL1_USE_CORE2_WFI (1 << 2)
> +#define PWR_CTRL1_USE_CORE1_WFI (1 << 1)
> +#define PWR_CTRL1_USE_CORE0_WFI (1 << 0)
> +
> /* the exynos4 soc type */
> enum exynos4_soc {
> EXYNOS4210,
> @@ -155,6 +171,7 @@ static unsigned long exynos4210_clk_save[] __initdata = {
> E4210_GATE_IP_LCD1,
> E4210_GATE_IP_PERIR,
> E4210_MPLL_CON0,
> + PWR_CTRL1,
> };
>
> static unsigned long exynos4x12_clk_save[] __initdata = {
> @@ -164,6 +181,8 @@ static unsigned long exynos4x12_clk_save[] __initdata = {
> E4X12_DIV_ISP,
> E4X12_DIV_CAM1,
> E4X12_MPLL_CON0,
> + PWR_CTRL1,
> + E4X12_PWR_CTRL2,
> };
>
> static unsigned long exynos4_clk_pll_regs[] __initdata = {
> @@ -1164,6 +1183,32 @@ static struct samsung_pll_clock exynos4x12_plls[nr_plls] __initdata = {
> VPLL_LOCK, VPLL_CON0, NULL),
> };
>
> +static void __init exynos4_core_down_clock(enum exynos4_soc soc)
> +{
> + unsigned int tmp;
> +
> + /*
> + * Enable arm clock down (in idle) and set arm divider
> + * ratios in WFI/WFE state.
> + */
> + tmp = (PWR_CTRL1_CORE2_DOWN_RATIO(7) | PWR_CTRL1_CORE1_DOWN_RATIO(7) |
> + PWR_CTRL1_DIV2_DOWN_EN | PWR_CTRL1_DIV1_DOWN_EN |
> + PWR_CTRL1_USE_CORE1_WFE | PWR_CTRL1_USE_CORE0_WFE |
> + PWR_CTRL1_USE_CORE1_WFI | PWR_CTRL1_USE_CORE0_WFI);
> + /* On Exynos4412 enable it also on core 2 and 3 */
> + if (num_possible_cpus() == 4)
> + tmp |= PWR_CTRL1_USE_CORE3_WFE | PWR_CTRL1_USE_CORE2_WFE |
> + PWR_CTRL1_USE_CORE3_WFI | PWR_CTRL1_USE_CORE2_WFI;
> + __raw_writel(tmp, reg_base + PWR_CTRL1);
> +
> + /*
> + * Disable the clock up feature on Exynos4x12, in case it was
> + * enabled by bootloader.
> + */
> + if (exynos4_soc == EXYNOS4X12)
> + __raw_writel(0x0, reg_base + E4X12_PWR_CTRL2);
> +}
> +
> /* register exynos4 clocks */
> static void __init exynos4_clk_init(struct device_node *np,
> enum exynos4_soc soc)
> @@ -1250,6 +1295,7 @@ static void __init exynos4_clk_init(struct device_node *np,
> samsung_clk_register_alias(ctx, exynos4_aliases,
> ARRAY_SIZE(exynos4_aliases));
>
> + exynos4_core_down_clock(soc);
> exynos4_clk_sleep_init();
>
> pr_info("%s clocks: sclk_apll = %ld, sclk_mpll = %ld\n"
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v2 14/16] cpufreq: Add cpufreq driver for Tegra124
From: Viresh Kumar @ 2014-07-24 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53D00A47.7050203@nvidia.com>
On 24 July 2014 00:47, Tuomas Tynkkynen <ttynkkynen@nvidia.com> wrote:
> It's this:
>
> +static int tegra124_cpufreq_probe(struct platform_device *pdev)
> +{
> [...]
> +
> + dfll_clk = of_clk_get_by_name(cpu_dev->of_node, "dfll");
> + if (IS_ERR(dfll_clk)) {
> + ret = PTR_ERR(dfll_clk);
> + goto out_put_cpu_clk;
> + }
This would search for clocks passed via DT, right? Why would we
get EPROBE_DEFER for that? Sorry for the stupid question.
--
viresh
^ permalink raw reply
* Kexec on arm64
From: Geoff Levand @ 2014-07-24 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFdej03nixSU=3h+HYk2E3Onb2P3--Di0GM+wCwLS6ZNH7UjEQ@mail.gmail.com>
Hi Arun,
On Tue, 2014-07-22 at 15:14 +0530, Arun Chandran wrote:
> # kexec -e
Please use 'kexec -d -e' here to get debug output.
> kexec version: 1kvm: exiting hardware virtualization
> 4.07.17.12.17-gbStarting new kernel
> 6cccb4
> Ump_spin_tanblaeb_lcpeu_d ite:127: oi dh:a n7d,l holding count: 0e
> kernel NULL pointer dereference at virtual address 00000291
> smp_spin_Itnaibtlei_cpaul_diie:12z7:i nigd :c 3g,r oholding couunpt :s 0u
It is hard to read this, please send the various outputs to different
streams.
> I think some of the secondary CPUs are not behaving as expected;
> As of now I don't have any clues for this.
I guess the cpu-return-addr is not correct. Try setting cpu-return-addr
to <0x0 0x1>. This will spin secondaries in secondary_holding_pen.
-Geoff
^ permalink raw reply
* [GIT PULL] ARM: mvebu: SoC changes for v3.17 (round 3)
From: Jason Cooper @ 2014-07-24 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMj1euJo-NPO-Ah18enuJc12u9ndaYo=9dM37pX_yX-wUw@mail.gmail.com>
On Wed, Jul 23, 2014 at 04:45:15PM -0700, Olof Johansson wrote:
> On Wed, Jul 23, 2014 at 4:41 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Wed, Jul 23, 2014 at 10:31:41PM +0200, Arnd Bergmann wrote:
> >> On Tuesday 22 July 2014, Jason Cooper wrote:
...
> >> > As usual (do I need to type this each time any more? :) ), this is an
> >> > incremental pull request from tags/mvebu-soc-3.17-2 up to
> >> > tags/mvebu-soc-3.17-3 on the mvebu/soc branch.
> >>
> >> It certainly helps me to have this information, but you can write it
> >> more briefly, e.g. "based on tags/mvebu-soc-3.17-2".
> >
> > Ahhhh.... Much more succinct. Thank you. On a side note, I wonder
> > what it would take to get 'git request-pull' smart enough to add that
> > information when handed a tag?
> >
> >> > The following changes since commit ba364fc752daeded072a5ef31e43b84cb1f9e5fd:
> >> >
> >> > ARM: Kirkwood: Remove mach-kirkwood (2014-07-13 22:13:39 +0000)
> >
> > eg:
> >
> > ARM: Kirkwood: Remove mach-kirkwood (tags/mvebu-soc-3.17-2)
>
> That only maps to the tag in your tree, which might or might not map
> directly to something that we know or care about. We do tend to keep
> naming similar, but not always identical. For example, the branch for
> that tag would be mvebu/soc2 in our tree.
Right, the goal was to automate 'based on tags/mvebu-soc-3.17-2' which
lets you guys know it's an incremental pull request.
> > Is the date of the base commit useful in any way in the pull request?
>
> I find the SHA to be useful, I will sometimes run "git branch
> --contains ba3ec57<...>" to see where the base is merged already. The
> date, for me, less so.
Ok, good to know.
thx,
Jason.
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC DT Timers Updates for v3.17
From: Olof Johansson @ 2014-07-24 0:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723235400.GA346@verge.net.au>
Ah, sorry. Got lost in the other pull requests.
On Wed, Jul 23, 2014 at 4:54 PM, Simon Horman <horms@verge.net.au> wrote:
> Hi Olof,
>
> I'd value your feedback on this if you have a moment.
>
> On Sun, Jul 20, 2014 at 10:51:25PM +0900, Simon Horman wrote:
>> On Fri, Jul 18, 2014 at 10:27:58PM -0700, Olof Johansson wrote:
>> > On Thu, Jul 17, 2014 at 09:40:20AM +0900, Simon Horman wrote:
>> > > Hi Olof, Hi Kevin, Hi Arnd,
>> > >
>> > > Please consider these Renesas ARM based SoC DT Timers updates for v3.17.
>> > >
>> > > This pull request is based on a merge of the following to provide
>> > > all dependencies and try to eliminate conflicts. It turns out the changes
>> > > in this pull requests are a nexus for dependencies due to modifying DT,
>> > > SoC, board and recently moved header files as well as requiring driver
>> > > changes.
>> > >
>> > > * The clockevents/renesas-timers-dt branch of Daniel Lezcano's tree.
>> > > He has indicated that this branch has stable commit ids and will
>> > > be included in v3.17. Olof and arm at kernel.org were CCed on the
>> > > thread where he, Laurent Pinchart and I discussed the use of that branch.
>> > >
>> > > The clockevents/renesas-timers-dt's branch is in turn based on v3.16-rc3.
>> > >
>> > > * "Third Round of Renesas ARM Based SoC DT Updates for v3.17",
>> > > tagged as renesas-dt3-for-v3.17, which I have sent a pull request for.
>> > >
>> > > * "Renesas ARM Based SoC Clock Updates for v3.17",
>> > > tagged as renesas-clock-for-v3.17, which you have merged
>> > > into next/soc
>> > >
>> > > * "Second Round of Renesas ARM Based SoC soc-cleanup Updates for v3.17",
>> > > tagged as renesas-soc-cleanup2-for-v3.17, which you have merged
>> > > into next/cleanup.
>> > >
>> > > * "Third Round of Renesas ARM Based SoC r8a7779 Multiplatform Updates for
>> > > v3.17", tagged as renesas-r8a7779-multiplatform3-for-v3.17, which
>> > > you have merged into next/soc
>> > >
>> > > * "Renesas ARM Based SoC Boards Updates for v3.17",
>> > > tagged as renesas-boards-for-v3.17, which you have merged
>> > > into next/boards
>> > >
>> > > * "Third Round of Renesas ARM Based SoC Updates for v3.17",
>> > > tagged as renesas-soc3-for-v3.17, which you have merged
>> > > into next/soc
>> > >
>> > >
>> > > The following changes since commit 5c174afd407acc7a90701900b279578151bc007f:
>> > >
>> > > Merge branch 'clockevents/renesas-timers-dt' of git://git.linaro.org/people/daniel.lezcano/linux into dt-timers-for-v3.17.base (2014-07-15 16:31:45 +0900)
>> > >
>> > > are available in the git repository at:
>> > >
>> > >
>> > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-timers-for-v3.17
>> > >
>> > > for you to fetch changes up to 9394af4314554d15762585a3464cefaa2e6d0420:
>> > >
>> > > ARM: shmobile: genmai-reference: Enable MTU2 in device tree (2014-07-15 21:26:42 +0900)
>> > >
>> > > ----------------------------------------------------------------
>> > > Renesas ARM Based SoC DT Timers Updates for v3.17
>> > >
>> > > * Enable timers using DT when booting boards without Legacy-C code
>> > >
>> > > ----------------------------------------------------------------
>> > > Laurent Pinchart (8):
>> > > ARM: shmobile: r8a7790: Add CMT devices to DT
>> > > ARM: shmobile: r8a7791: Add CMT devices to DT
>> > > ARM: shmobile: r8a7779: Add TMU devices to DT
>> > > ARM: shmobile: lager-reference: Enable CMT0 in device tree
>> > > ARM: shmobile: koelsch-reference: Enable CMT0 in device tree
>> > > ARM: shmobile: marzen-reference: Enable TMU0 in device tree
>> > > ARM: shmobile: r7s72100: Add MTU2 device to DT
>> > > ARM: shmobile: genmai-reference: Enable MTU2 in device tree
>> >
>> > Ok, this branch definitely contains a lot more than this. For dependent
>> > external branches such as clocksource, we still prefer to see a pull request so
>> > that we can merge in the dependency and get a clean diffstat when we do the
>> > merge of your branch, otherwise it gets awkward to compare that what we're
>> > getting is what you thought you sent (which is one of the things we check on
>> > merges).
>> >
>> > Please regenerate this pull request as appropriate.
>>
>> Hi Olof,
>>
>> FWIW, I believe that that the diffstat between
>> 5c174afd407acc7a90701900b279578151bc007f and
>> 9394af4314554d15762585a3464cefaa2e6d0420 is what was included in the
>> pull-request. But I guess that all the merged-in branches are hampering
>> your verification process.
>>
>> Would it help if things were arranged as follows?
>>
>> 1. Use the clocksource branch as a base and then;
>> 2. Merge in each of my branches (the ones listed above) and then;
>> 3. Add the patches on top
So there's nothing wrong per se with the way you arranged it, even
though it is more convenient for us from a review perspective to get
merges of branches at the tips of previous branch heads (i.e.
tags/merge requests). It just makes it easier to spot "Oh, that side
of the merge is from this branch that we've already reviewed", etc.
For generating pull requests for these complex merges, what we do when
sending stuff upstream is that we generate a dummy merge and
"manually" (through a script) generate the diffstat and shortlog from
that. Git can get confused about what is actually the merge-base
otherwise, which is what happened in this case for you.
-Olof
^ permalink raw reply
* [PATCH v2] cpufreq: tests: Providing cpufreq regression test
From: Rafael J. Wysocki @ 2014-07-23 23:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405926154-27214-1-git-send-email-l.majewski@samsung.com>
On Monday, July 21, 2014 09:02:34 AM Lukasz Majewski wrote:
> This commit adds first regression test "cpufreq_freq_test.sh" for the
> cpufreq subsystem.
First of all, I'm not seeing any explanation why this script should be
shipped with the kernel.
What regressions it tests against in particular and how it does that.
Please write that down in the changelog. It doesn't need to be very
detailed.
Second, I'm not sure this is the first such test (someone already
mentioned cpupower).
> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
>
> ---
> Changes for v2:
> - Replace *_PATCH with *_PATH for variables names
> - Corrected mistakes in the README file
> - Providing detailed explanation of the patch in the README file
> ---
> drivers/cpufreq/tests/README | 33 +++++++
> drivers/cpufreq/tests/cpufreq_freq_test.sh | 149 +++++++++++++++++++++++++++++
> 2 files changed, 182 insertions(+)
> create mode 100644 drivers/cpufreq/tests/README
> create mode 100755 drivers/cpufreq/tests/cpufreq_freq_test.sh
>
> diff --git a/drivers/cpufreq/tests/README b/drivers/cpufreq/tests/README
drivers/cpufreq/ is not a place for scripts.
We have scripts/ for that and you can add a "power" subdirectory in there
and put your script into it.
Alternatively, you can use the existing tools/power/ directory for that (but
then please add a subdirectory for your script).
> new file mode 100644
> index 0000000..3e9cd80
> --- /dev/null
> +++ b/drivers/cpufreq/tests/README
> @@ -0,0 +1,33 @@
> +This file contains list of cpufreq's available regression tests with a short
> +usage description.
> +
> +1. cpufreq_freq_test.sh
> +
> +Description:
> +------------
> +This script is supposed to test if cpufreq attributes exported by sysfs are
> +exposing correct values.
> +
> +To achieve this goal it saves the current governor and changes it to
> +"performance". Afterwards, it reads the "scaling_available_frequencies"
> +property. With the list of supported frequencies it is able to enforce each of
> +them by writing to "scaling_max_freq" attribute. To make the test more reliable
> +a superfluous load with gzip is created to be sure that we are running with
> +highest possible frequency. This high load is regulated with the 'sleep'
> +duration. After this time the "cpufreq_cur_freq" is read and compared with the
> +original value. As the last step the original governor is restored.
> +
> +This script can work with or without BOOST enabled and helps in spotting errors
> +related to cpufreq and common clock framework.
> +
> +Used attributes:
> +----------------
> +- "scaling_available_frequencies"
> +- "cpuinfo_cur_freq"
> +- "scaling_governor"
> +- "scaling_max_freq"
> +
> +Target devices:
> +---------------
> +
> +All devices which exports mentioned above sysfs attributes.
> \ No newline at end of file
> diff --git a/drivers/cpufreq/tests/cpufreq_freq_test.sh b/drivers/cpufreq/tests/cpufreq_freq_test.sh
> new file mode 100755
> index 0000000..c25f05c
> --- /dev/null
> +++ b/drivers/cpufreq/tests/cpufreq_freq_test.sh
> @@ -0,0 +1,149 @@
> +#!/bin/bash
> +#
> +# This file provides a simple mean to test if all declared freqs at
> +# "scaling_available_frequencies" can be set and if "cpuinfo_cur_freq"
> +# returns this value.
> +#
> +# Usage: ./cpufreq_freq_test.sh
> +# Requisite: Compiled in "performance" governor
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, you can access it online at
> +# http://www.gnu.org/licenses/gpl-2.0.html.
> +#
> +# Copyright (C) Samsung Electronics, 2014
> +#
> +# Author: Lukasz Majewski <l.majewski@samsung.com>
> +
> +set +x
> +
> +COLOUR_RED="\33[31m"
> +COLOUR_BLUE="\33[34m"
> +COLOUR_GREEN="\33[32m"
> +COLOUR_DEFAULT="\33[0m"
> +
> +T_PATH=/sys/devices/system/cpu/cpu0/cpufreq
> +BOOST_PATH=/sys/devices/system/cpu/cpufreq
> +
> +if [ ! -d "$T_PATH" ]; then
> + printf " $COLOUR_RED No path to CPUFREQ $COLOUR_DEFAULT\n"
> + exit 1
> +fi
> +
> +ERRORS=0
> +
> +OLD_GOV=`cat $T_PATH/scaling_governor`
> +echo "CURRENT GOVERNOR: $OLD_GOV"
> +echo "SET GOVERNOR: performance"
> +echo "performance" > $T_PATH/scaling_governor
> +
> +function test_freqs1 {
> + FREQS=`cat $1`
> + for I in $FREQS; do
> + cpufreq_set_freq $I
> + if [ "$2" ]; then
> + printf "$COLOUR_BLUE BOOST $COLOUR_DEFAULT" $I
> + fi
> + cpufreq_test_freq $I
> + done
> +}
> +
> +function test_freqs2 {
> + FREQ=`cat $1`
> + FREQS_ARRAY=($FREQ)
> +
> + for freq in ${FREQS_ARRAY[@]}
> + do
> + echo "REFERENCE FREQ: $freq"
> + for f in ${FREQS_ARRAY[@]}
> + do
> + cpufreq_set_freq $freq
> + echo -n "----> "
> + cpufreq_set_freq $f
> + cpufreq_test_freq $f
> + done
> + done
> +}
> +
> +function restore {
> + if [ -f $BOOST_PATH/boost ]; then
> + cpufreq_boost_state $BOOST_STATE
> + fi
> +
> + echo "SET GOVERNOR: $OLD_GOV"
> + echo $OLD_GOV > $T_PATH/scaling_governor
> +}
> +
> +function die {
> + printf " $COLOUR_RED FAILED $COLOUR_DEFAULT\n"
> + restore_gov
> + exit 1
> +}
> +
> +function cpufreq_test_freq {
> + gzip < /dev/urandom > /dev/null &
> + pid=$!
> + sleep 0.1
> + CURR_FREQ=`cat $T_PATH/cpuinfo_cur_freq`
> + if [ $1 -eq $CURR_FREQ ]; then
> + printf "\t$COLOUR_GREEN OK $COLOUR_DEFAULT\n"
> + else
> + printf "$COLOUR_RED CURRENT $CURR_FREQ $COLOUR_DEFAULT\n"
> + ERRORS=`expr $ERRORS + 1`
> + #die
> + fi
> + kill -9 $pid
> + wait $! 2>/dev/null
> +}
> +
> +function cpufreq_set_freq {
> + echo $1 > $T_PATH/scaling_max_freq || die $?
> + printf "FREQ:$COLOUR_GREEN %s $COLOUR_DEFAULT" $1
> +}
> +
> +function cpufreq_boost_state {
> + echo $1 > $BOOST_PATH/boost
> +}
> +
> +function cpufreq_boost_status {
> + cat $BOOST_PATH/boost
> +}
> +
> +if [ -f $BOOST_PATH/boost ]; then
> + echo "######################################"
> + echo "TEST BOOST OPERATION"
> + echo "######################################"
> +
> + BOOST_STATE=$(cpufreq_boost_status)
> + if [ $BOOST_STATE -eq 0 ]; then
> + cpufreq_boost_state 1
> + fi
> + test_freqs1 $T_PATH/scaling_boost_frequencies 1
> +fi
> +
> +echo "######################################"
> +echo "TEST AVAILABLE FREQS"
> +echo "######################################"
> +test_freqs1 $T_PATH/scaling_available_frequencies
> +
> +echo "######################################"
> +echo "TEST FREQS SWITCHING"
> +echo "######################################"
> +test_freqs2 $T_PATH/scaling_available_frequencies
> +
> +echo "######################################"
> +echo "ERRORS: $ERRORS"
> +echo "######################################"
> +
> +restore
> +exit 0
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC DT Timers Updates for v3.17
From: Simon Horman @ 2014-07-23 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140720135125.GB31336@verge.net.au>
Hi Olof,
I'd value your feedback on this if you have a moment.
On Sun, Jul 20, 2014 at 10:51:25PM +0900, Simon Horman wrote:
> On Fri, Jul 18, 2014 at 10:27:58PM -0700, Olof Johansson wrote:
> > On Thu, Jul 17, 2014 at 09:40:20AM +0900, Simon Horman wrote:
> > > Hi Olof, Hi Kevin, Hi Arnd,
> > >
> > > Please consider these Renesas ARM based SoC DT Timers updates for v3.17.
> > >
> > > This pull request is based on a merge of the following to provide
> > > all dependencies and try to eliminate conflicts. It turns out the changes
> > > in this pull requests are a nexus for dependencies due to modifying DT,
> > > SoC, board and recently moved header files as well as requiring driver
> > > changes.
> > >
> > > * The clockevents/renesas-timers-dt branch of Daniel Lezcano's tree.
> > > He has indicated that this branch has stable commit ids and will
> > > be included in v3.17. Olof and arm at kernel.org were CCed on the
> > > thread where he, Laurent Pinchart and I discussed the use of that branch.
> > >
> > > The clockevents/renesas-timers-dt's branch is in turn based on v3.16-rc3.
> > >
> > > * "Third Round of Renesas ARM Based SoC DT Updates for v3.17",
> > > tagged as renesas-dt3-for-v3.17, which I have sent a pull request for.
> > >
> > > * "Renesas ARM Based SoC Clock Updates for v3.17",
> > > tagged as renesas-clock-for-v3.17, which you have merged
> > > into next/soc
> > >
> > > * "Second Round of Renesas ARM Based SoC soc-cleanup Updates for v3.17",
> > > tagged as renesas-soc-cleanup2-for-v3.17, which you have merged
> > > into next/cleanup.
> > >
> > > * "Third Round of Renesas ARM Based SoC r8a7779 Multiplatform Updates for
> > > v3.17", tagged as renesas-r8a7779-multiplatform3-for-v3.17, which
> > > you have merged into next/soc
> > >
> > > * "Renesas ARM Based SoC Boards Updates for v3.17",
> > > tagged as renesas-boards-for-v3.17, which you have merged
> > > into next/boards
> > >
> > > * "Third Round of Renesas ARM Based SoC Updates for v3.17",
> > > tagged as renesas-soc3-for-v3.17, which you have merged
> > > into next/soc
> > >
> > >
> > > The following changes since commit 5c174afd407acc7a90701900b279578151bc007f:
> > >
> > > Merge branch 'clockevents/renesas-timers-dt' of git://git.linaro.org/people/daniel.lezcano/linux into dt-timers-for-v3.17.base (2014-07-15 16:31:45 +0900)
> > >
> > > are available in the git repository at:
> > >
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-timers-for-v3.17
> > >
> > > for you to fetch changes up to 9394af4314554d15762585a3464cefaa2e6d0420:
> > >
> > > ARM: shmobile: genmai-reference: Enable MTU2 in device tree (2014-07-15 21:26:42 +0900)
> > >
> > > ----------------------------------------------------------------
> > > Renesas ARM Based SoC DT Timers Updates for v3.17
> > >
> > > * Enable timers using DT when booting boards without Legacy-C code
> > >
> > > ----------------------------------------------------------------
> > > Laurent Pinchart (8):
> > > ARM: shmobile: r8a7790: Add CMT devices to DT
> > > ARM: shmobile: r8a7791: Add CMT devices to DT
> > > ARM: shmobile: r8a7779: Add TMU devices to DT
> > > ARM: shmobile: lager-reference: Enable CMT0 in device tree
> > > ARM: shmobile: koelsch-reference: Enable CMT0 in device tree
> > > ARM: shmobile: marzen-reference: Enable TMU0 in device tree
> > > ARM: shmobile: r7s72100: Add MTU2 device to DT
> > > ARM: shmobile: genmai-reference: Enable MTU2 in device tree
> >
> > Ok, this branch definitely contains a lot more than this. For dependent
> > external branches such as clocksource, we still prefer to see a pull request so
> > that we can merge in the dependency and get a clean diffstat when we do the
> > merge of your branch, otherwise it gets awkward to compare that what we're
> > getting is what you thought you sent (which is one of the things we check on
> > merges).
> >
> > Please regenerate this pull request as appropriate.
>
> Hi Olof,
>
> FWIW, I believe that that the diffstat between
> 5c174afd407acc7a90701900b279578151bc007f and
> 9394af4314554d15762585a3464cefaa2e6d0420 is what was included in the
> pull-request. But I guess that all the merged-in branches are hampering
> your verification process.
>
> Would it help if things were arranged as follows?
>
> 1. Use the clocksource branch as a base and then;
> 2. Merge in each of my branches (the ones listed above) and then;
> 3. Add the patches on top
^ permalink raw reply
* [PATCHv3 3/7] clk: mvebu: extend clk-cpu for dynamic frequency scaling
From: Thomas Petazzoni @ 2014-07-23 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404920715-19834-1-git-send-email-thomas.petazzoni@free-electrons.com>
+static int clk_cpu_on_set_rate(struct clk_hw *hwclk, unsigned long rate,
+ unsigned long parent_rate)
+{
+ u32 reg;
+ unsigned long fabric_div, target_div, cur_rate;
+ struct cpu_clk *cpuclk = to_cpu_clk(hwclk);
+
+ /*
+ * PMU DFS registers are not mapped, Device Tree does not
+ * describes them. We cannot change the frequency dynamically.
+ */
+ if (!cpuclk->pmu_dfs)
+ return -ENODEV;
+
+ cur_rate = __clk_get_rate(hwclk->clk);
+
+ reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL2_OFFSET);
+ fabric_div = (reg >> SYS_CTRL_CLK_DIVIDER_CTRL2_NBCLK_RATIO_SHIFT) &
+ SYS_CTRL_CLK_DIVIDER_MASK;
+
+ /* Frequency is going up */
+ if (rate == 2 * cur_rate)
+ target_div = fabric_div / 2;
+ /* Frequency is going down */
+ else
+ target_div = fabric_div;
+
+ if (target_div == 0)
+ target_div = 1;
+
+ reg = readl(cpuclk->pmu_dfs);
+ reg &= ~(PMU_DFS_RATIO_MASK << PMU_DFS_RATIO_SHIFT);
+ reg |= (target_div << PMU_DFS_RATIO_SHIFT);
+ writel(reg, cpuclk->pmu_dfs);
+
+ reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+ reg |= (SYS_CTRL_CLK_DIVIDER_CTRL_RESET_ALL <<
+ SYS_CTRL_CLK_DIVIDER_CTRL_RESET_SHIFT);
+ writel(reg, cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+
+ return mvebu_pmsu_dfs_request(cpuclk->cpu);
+}
+
+static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
+ unsigned long parent_rate)
+{
+ if (__clk_is_enabled(hwclk->clk))
+ return clk_cpu_on_set_rate(hwclk, rate, parent_rate);
+ else
+ return clk_cpu_off_set_rate(hwclk, rate, parent_rate);
This is racy. You don't hold the clk_enable lock so it could be enable
between the conditional check and executing clk_cpu_on_set_rate.
How do you ensure that secondary CPU clocks are not enabled/disabled
when changing rates?
Regards,
Mike
^ permalink raw reply
* [PATCHv3 2/7] ARM: mvebu: extend PMSU code to support dynamic frequency scaling
From: Mike Turquette @ 2014-07-23 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404920715-19834-3-git-send-email-thomas.petazzoni@free-electrons.com>
Quoting Thomas Petazzoni (2014-07-09 08:45:10)
> This commit adds the necessary code in the Marvell EBU PMSU driver to
> support dynamic frequency scaling. In essence, what this new code does
> is that it:
>
> * registers the frequency operating points supported by the CPU;
>
> * registers a clock notifier of the CPU clocks. The notifier function
Where does this code register a clock notifier callback?
> listens to the newly introduced APPLY_RATE_CHANGE event, and uses
I don't see APPLY_RATE_CHANGE referenced.
> that to finalize the frequency transition by doing the part of the
> procedure that involves the PMSU;
Thanks,
Mike
>
> * registers a platform device for the cpufreq-generic driver, which
> will take care of the CPU frequency transitions.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/mach-mvebu/pmsu.c | 162 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mvebu-pmsu.h | 20 ++++++
> 2 files changed, 182 insertions(+)
> create mode 100644 include/linux/mvebu-pmsu.h
>
> diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
> index 53a55c8..db7d9ab 100644
> --- a/arch/arm/mach-mvebu/pmsu.c
> +++ b/arch/arm/mach-mvebu/pmsu.c
> @@ -18,20 +18,26 @@
>
> #define pr_fmt(fmt) "mvebu-pmsu: " fmt
>
> +#include <linux/clk.h>
> #include <linux/cpu_pm.h>
> +#include <linux/delay.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/of_address.h>
> +#include <linux/of_device.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
> #include <linux/smp.h>
> #include <linux/resource.h>
> +#include <linux/slab.h>
> #include <asm/cacheflush.h>
> #include <asm/cp15.h>
> #include <asm/smp_plat.h>
> #include <asm/suspend.h>
> #include <asm/tlbflush.h>
> #include "common.h"
> +#include "armada-370-xp.h"
>
> static void __iomem *pmsu_mp_base;
>
> @@ -57,6 +63,10 @@ static void __iomem *pmsu_mp_base;
> #define PMSU_STATUS_AND_MASK_IRQ_MASK BIT(24)
> #define PMSU_STATUS_AND_MASK_FIQ_MASK BIT(25)
>
> +#define PMSU_EVENT_STATUS_AND_MASK(cpu) ((cpu * 0x100) + 0x120)
> +#define PMSU_EVENT_STATUS_AND_MASK_DFS_DONE BIT(1)
> +#define PMSU_EVENT_STATUS_AND_MASK_DFS_DONE_MASK BIT(17)
> +
> #define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu) ((cpu * 0x100) + 0x124)
>
> /* PMSU fabric registers */
> @@ -296,3 +306,155 @@ int __init armada_370_xp_cpu_pm_init(void)
>
> arch_initcall(armada_370_xp_cpu_pm_init);
> early_initcall(armada_370_xp_pmsu_init);
> +
> +static void mvebu_pmsu_dfs_request_local(void *data)
> +{
> + u32 reg;
> + u32 cpu = smp_processor_id();
> + unsigned long flags;
> +
> + local_irq_save(flags);
> +
> + /* Prepare to enter idle */
> + reg = readl(pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
> + reg |= PMSU_STATUS_AND_MASK_CPU_IDLE_WAIT |
> + PMSU_STATUS_AND_MASK_IRQ_MASK |
> + PMSU_STATUS_AND_MASK_FIQ_MASK;
> + writel(reg, pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
> +
> + /* Request the DFS transition */
> + reg = readl(pmsu_mp_base + PMSU_CONTROL_AND_CONFIG(cpu));
> + reg |= PMSU_CONTROL_AND_CONFIG_DFS_REQ;
> + writel(reg, pmsu_mp_base + PMSU_CONTROL_AND_CONFIG(cpu));
> +
> + /* The fact of entering idle will trigger the DFS transition */
> + wfi();
> +
> + /*
> + * We're back from idle, the DFS transition has completed,
> + * clear the idle wait indication.
> + */
> + reg = readl(pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
> + reg &= ~PMSU_STATUS_AND_MASK_CPU_IDLE_WAIT;
> + writel(reg, pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
> +
> + local_irq_restore(flags);
> +}
> +
> +int mvebu_pmsu_dfs_request(int cpu)
> +{
> + unsigned long timeout;
> + int hwcpu = cpu_logical_map(cpu);
> + u32 reg;
> +
> + /* Clear any previous DFS DONE event */
> + reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(hwcpu));
> + reg &= ~PMSU_EVENT_STATUS_AND_MASK_DFS_DONE;
> + writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(hwcpu));
> +
> + /* Mask the DFS done interrupt, since we are going to poll */
> + reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(hwcpu));
> + reg |= PMSU_EVENT_STATUS_AND_MASK_DFS_DONE_MASK;
> + writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(hwcpu));
> +
> + /* Trigger the DFS on the appropriate CPU */
> + smp_call_function_single(cpu, mvebu_pmsu_dfs_request_local,
> + NULL, false);
> +
> + /* Poll until the DFS done event is generated */
> + timeout = jiffies + HZ;
> + while (time_before(jiffies, timeout)) {
> + reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(hwcpu));
> + if (reg & PMSU_EVENT_STATUS_AND_MASK_DFS_DONE)
> + break;
> + udelay(10);
> + }
> +
> + if (time_after(jiffies, timeout))
> + return -ETIME;
> +
> + /* Restore the DFS mask to its original state */
> + reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(hwcpu));
> + reg &= ~PMSU_EVENT_STATUS_AND_MASK_DFS_DONE_MASK;
> + writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(hwcpu));
> +
> + return 0;
> +}
> +
> +static int __init armada_xp_pmsu_cpufreq_init(void)
> +{
> + struct device_node *np;
> + struct resource res;
> + int ret, cpu;
> +
> + if (!of_machine_is_compatible("marvell,armadaxp"))
> + return 0;
> +
> + /*
> + * In order to have proper cpufreq handling, we need to ensure
> + * that the Device Tree description of the CPU clock includes
> + * the definition of the PMU DFS registers. If not, we do not
> + * register the clock notifier and the cpufreq driver. This
> + * piece of code is only for compatibility with old Device
> + * Trees.
> + */
> + np = of_find_compatible_node(NULL, NULL, "marvell,armada-xp-cpu-clock");
> + if (!np)
> + return 0;
> +
> + ret = of_address_to_resource(np, 1, &res);
> + if (ret) {
> + pr_warn(FW_WARN "not enabling cpufreq, deprecated armada-xp-cpu-clock binding\n");
> + of_node_put(np);
> + return 0;
> + }
> +
> + of_node_put(np);
> +
> + /*
> + * For each CPU, this loop registers the operating points
> + * supported (which are the nominal CPU frequency and half of
> + * it), and registers the clock notifier that will take care
> + * of doing the PMSU part of a frequency transition.
> + */
> + for_each_possible_cpu(cpu) {
> + struct device *cpu_dev;
> + struct clk *clk;
> + int ret;
> +
> + cpu_dev = get_cpu_device(cpu);
> + if (!cpu_dev) {
> + pr_err("Cannot get CPU %d\n", cpu);
> + continue;
> + }
> +
> + clk = clk_get(cpu_dev, 0);
> + if (!clk) {
> + pr_err("Cannot get clock for CPU %d\n", cpu);
> + return -ENODEV;
> + }
> +
> + /*
> + * In case of a failure of dev_pm_opp_add(), we don't
> + * bother with cleaning up the registered OPP (there's
> + * no function to do so), and simply cancel the
> + * registration of the cpufreq device.
> + */
> + ret = dev_pm_opp_add(cpu_dev, clk_get_rate(clk), 0);
> + if (ret) {
> + clk_put(clk);
> + return ret;
> + }
> +
> + ret = dev_pm_opp_add(cpu_dev, clk_get_rate(clk) / 2, 0);
> + if (ret) {
> + clk_put(clk);
> + return ret;
> + }
> + }
> +
> + platform_device_register_simple("cpufreq-generic", -1, NULL, 0);
> + return 0;
> +}
> +
> +device_initcall(armada_xp_pmsu_cpufreq_init);
> diff --git a/include/linux/mvebu-pmsu.h b/include/linux/mvebu-pmsu.h
> new file mode 100644
> index 0000000..b918d07
> --- /dev/null
> +++ b/include/linux/mvebu-pmsu.h
> @@ -0,0 +1,20 @@
> +/*
> + * Copyright (C) 2012 Marvell
> + *
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __MVEBU_PMSU_H__
> +#define __MVEBU_PMSU_H__
> +
> +#ifdef CONFIG_MACH_MVEBU_V7
> +int mvebu_pmsu_dfs_request(int cpu);
> +#else
> +static inline int mvebu_pmsu_dfs_request(int cpu) { return -ENODEV; }
> +#endif
> +
> +#endif /* __MVEBU_PMSU_H__ */
> --
> 2.0.0
>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: SoC changes for v3.17 (round 3)
From: Olof Johansson @ 2014-07-23 23:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723234130.GM23220@titan.lakedaemon.net>
On Wed, Jul 23, 2014 at 4:41 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Wed, Jul 23, 2014 at 10:31:41PM +0200, Arnd Bergmann wrote:
>> On Tuesday 22 July 2014, Jason Cooper wrote:
>> > All,
>> >
>> > Here's the cpufreq changes I mentioned over the weekend. It's been in
>> > -next for a while. Once I get the new version of cpuidle from ThomasP,
>> > I'll push that as quickly as possible.
>>
>> Just for my information, is this coordinated with the cpufreq maintainers?
>> I remember being asked to ensure all cpufreq/cpuidle stuff has an Ack
>> from them, even stuff that doesn't touch drivers/cpufreq at all.
>
> Good to know.
>
>> The contents look good to me. I can merge them if there are no objections
>> from Viresh, feel free to send the next batch already without waiting
>> for me to pull.
>
> We've been coordinating with Viresh. He has an unsettled issue on his
> side he hopes to have resolved soon. Worst case scenario, he doesn't
> get the change in for v3.17, we'll have to do a minor DT fix on top of
> -rc1.
>
>> > As usual (do I need to type this each time any more? :) ), this is an
>> > incremental pull request from tags/mvebu-soc-3.17-2 up to
>> > tags/mvebu-soc-3.17-3 on the mvebu/soc branch.
>>
>> It certainly helps me to have this information, but you can write it
>> more briefly, e.g. "based on tags/mvebu-soc-3.17-2".
>
> Ahhhh.... Much more succinct. Thank you. On a side note, I wonder
> what it would take to get 'git request-pull' smart enough to add that
> information when handed a tag?
>
>> > The following changes since commit ba364fc752daeded072a5ef31e43b84cb1f9e5fd:
>> >
>> > ARM: Kirkwood: Remove mach-kirkwood (2014-07-13 22:13:39 +0000)
>
> eg:
>
> ARM: Kirkwood: Remove mach-kirkwood (tags/mvebu-soc-3.17-2)
That only maps to the tag in your tree, which might or might not map
directly to something that we know or care about. We do tend to keep
naming similar, but not always identical. For example, the branch for
that tag would be mvebu/soc2 in our tree.
>> >
>> > are available in the git repository at:
>> >
>> > git://git.infradead.org/linux-mvebu.git tags/mvebu-soc-3.17-3
>> >
>> > for you to fetch changes up to ba3ec5780bba27819bbc4f669e6c77418a00f14b:
>> >
>> > Merge branch 'mvebu/soc-cpufreq' into mvebu/soc (2014-07-22 20:46:48 +0000)
>> >
>> > ----------------------------------------------------------------
>
> Is the date of the base commit useful in any way in the pull request?
I find the SHA to be useful, I will sometimes run "git branch
--contains ba3ec57<...>" to see where the base is merged already. The
date, for me, less so.
-Olof
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Jason Cooper @ 2014-07-23 23:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723232909.GE28485@lunn.ch>
On Thu, Jul 24, 2014 at 01:29:09AM +0200, Andrew Lunn wrote:
> > On Wed, Jul 23, 2014 at 03:52:53PM -0700, Benoit Masson wrote:
> > > The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb,
> > > USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU.
> > >
> > > http://shop.lenovo.com/fr/fr/servers/network-storage/lenovoemc/ix4-300d/
> > > Signed-off-by: Benoit Masson <yahoo@perenite.com>
> > > ---
> > > arch/arm/boot/dts/Makefile | 3 +-
> > > arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 284 ++++++++++++++++++++++++
> > > 2 files changed, 286 insertions(+), 1 deletion(-)
> > > create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> > ...
> > > diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> > > new file mode 100644
> > > index 0000000..1f33cbc
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> > ...
> > > + /* Warning: you need both eth1 & 0 PHY initialized
> > > + (i.e having them up does the tweak)
> > > + for poweroff to shutdown otherwise it reboots */
> >
> > nit: multi-line comments are like this:
> >
> > /*
> > * Warning: you need both eth1 & 0 PHY initialized (i.e having
> > * them up does the tweak) for poweroff to shutdown otherwise it
> > * reboots
> > */
> >
> > If that's the only thing left, I'll fix it up when I pull it in. No
> > need to respin just for this.
>
> Hi Jason
>
> We should not really leave the i2c compatibility string as it is.
Agreed.
> Hopefully the OEM moved onto B1 stepping at some point. Although B1
> devices will work with the workaround, you get better performance
> without it.
>
> We should wait for Gregory to look at the quirk and soc-id code.
Yep.
thx,
Jason.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox