* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1401311608590.12368-100000@netrider.rowland.org>
On Fri, Jan 31, 2014 at 04:13:19PM -0500, Alan Stern wrote:
> On Fri, 31 Jan 2014, Felipe Balbi wrote:
>
> > probe()
> > {
> > ...
> >
> > clk_get(dev, "fck");
> > clk_prepare(clk);
> > clk_enable(clk);
> > pm_runtime_set_active(dev);
> > pm_runtime_enable(dev);
> > pm_runtime_get_sync(dev);
> > ...
> > }
>
> > note that because of pm_runtime_set_active() that first
> > pm_runtime_get_sync() in probe() will simply increase the reference
> > counter without calling my ->runtime_resume() callback, which is exactly
> > what we want, as that would completely avoid situations of bad context
> > being restored because of that initial pm_runtime_get_sync().
>
> Very minor note... A slightly better way to do the same thing is:
>
> pm_runtime_set_active(dev);
> pm_runtime_get_noresume(dev);
> pm_runtime_enable(dev);
>
> The get_noresume says that you want to increment the usage counter
> without performing any callbacks, and doing it before the
> pm_runtime_enable avoids any window during which a runtime suspend
> might somehow occur.
aha, that's perfect :-) Thanks Alan.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/f29ba556/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: hisi: don't select SMP
From: Rob Herring @ 2014-01-31 22:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
SMP is a user configurable option, not a hardware feature and should not
be selected.
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/mach-hisi/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index 018ad67..8f4649b 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -12,6 +12,5 @@ config ARCH_HI3xxx
select HAVE_SMP
select PINCTRL
select PINCTRL_SINGLE
- select SMP
help
Support for Hisilicon Hi36xx/Hi37xx processor family
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 0/7] ARM: rockchip: add smp functionality
From: Heiko Stübner @ 2014-01-31 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4970034.fqvMoHdOyd@phil>
On Monday, 20. January 2014 16:41:43 Heiko St?bner wrote:
> This series enables the use of the additional cores on Rockchip
> Cortex-A9 SoCs.
So, two weeks without any general complaints, but I guess part of the more
general patches could use an ack.
Going forward, what would be best way to merge them?
As one pull request to arm-soc, or for example splitting them into the first
three patches going through the misc tree and the rockchip specific stuff going
through arm-soc? Or something else altogether?
> Heiko Stuebner (7):
> of: add functions to count number of elements in a property
One of the intermediate versions of this patch got a
Reviewed-by: Mark Rutland <mark.rutland@arm.com> .
Mark, is this still true for this variant addressing some additional wished
from Rob?
And this final version got a "Looks good" from Rob Herring in the original
thread, but a more formal "ack" might be nice :-) .
> dt-bindings: sram: describe option to reserve parts of the memory
> misc: sram: implement mmio-sram-reserved option
Philipp, you acked an intermediate version, and this v7 now should also
contain the two separate loops (1st gathering data and 2nd creating the pool
parts) you asked for.
Could I persuade you to take a look again?
Thanks
Heiko
> ARM: rockchip: add snoop-control-unit
> ARM: rockchip: add sram dt nodes and documentation
> ARM: rockchip: add power-management-unit
> ARM: rockchip: add smp bringup code
>
> .../devicetree/bindings/arm/rockchip/pmu.txt | 16 ++
> .../devicetree/bindings/arm/rockchip/smp-sram.txt | 23 +++
> Documentation/devicetree/bindings/misc/sram.txt | 8 +
> arch/arm/boot/dts/rk3066a.dtsi | 6 +
> arch/arm/boot/dts/rk3188.dtsi | 6 +
> arch/arm/boot/dts/rk3xxx.dtsi | 10 +
> arch/arm/mach-rockchip/Kconfig | 1 +
> arch/arm/mach-rockchip/Makefile | 1 +
> arch/arm/mach-rockchip/core.h | 22 +++
> arch/arm/mach-rockchip/headsmp.S | 30 +++
> arch/arm/mach-rockchip/platsmp.c | 208
> ++++++++++++++++++++ arch/arm/mach-rockchip/rockchip.c |
> 2 +
> drivers/misc/sram.c | 121 +++++++++++-
> drivers/of/base.c | 32 +++
> include/linux/of.h | 76 +++++++
> 15 files changed, 554 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt create mode
> 100644 arch/arm/mach-rockchip/core.h
> create mode 100644 arch/arm/mach-rockchip/headsmp.S
> create mode 100644 arch/arm/mach-rockchip/platsmp.c
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Felipe Balbi @ 2014-01-31 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1401311614100.12368-100000@netrider.rowland.org>
Hi,
On Fri, Jan 31, 2014 at 04:34:27PM -0500, Alan Stern wrote:
> On Fri, 31 Jan 2014, Felipe Balbi wrote:
>
> > Still TODO a commit log. Not for merging!!!!!
> >
> > NYET-Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >
> > This patch is an idea I've had recently in order to combine several different
> > PM implementations into the platform-bus.
> >
> > This patch is bare minimum for platforms which need to handle functional and
> > interface clocks but the whole thing is made optional.
> >
> > Note that this patch makes sure that by the time a platform_driver's probe is
> > called, we already have clocks enabled and pm_runtime_set_active() has been
> > called, thus making sure that a device driver's pm_runtime_get_sync() will
> > solely increase the pm usage counter.
> >
> > I have *NOT* tested this anywhere *YET*, but I suppose it shouldn't cause any
> > issues since the clock API has ref counting too.
> >
> > Would really like to get some review from several folks involved with ARM SoC
> > PM so that's the reason for the wide audience. If I have missed anybody, please
> > add them to Cc.
> >
> > As mentioned above, this is *NOT* meant for merging, but serves as a starting
> > point for discussing some convergence of several PM domain implementations on
> > different arch/arm/mach-* directories.
>
> You might want to copy the runtime-PM approach used by the PCI
> subsystem. It works like this:
>
> The core invokes a driver's probe routine with runtime PM
> enabled, the device in the ACTIVE state, and the usage counter
> incremented by 1.
>
> If the driver wants to support runtime PM, the probe routine
> can call pm_runtime_put_noidle.
>
> The core does pm_runtime_get_sync before invoking the driver's
> remove routine. At this point a runtime-PM-aware driver whould
> call pm_runtime_get_noresume, to balance the _put during probe.
>
> After invoking the remove routine, the core does a put_noidle
> (to balance the get_sync) and a final put_sync (to balance the
> increment before probe and to leave the device at low power.)
>
> A nice consequence is that everything is transparent for drivers that
> don't support runtime PM. The usage counter remains > 0 the entire
> time the driver is bound.
>
> Conversely, drivers that do support runtime PM merely have to add one
> call during probe and one during remove.
>
> There is one tricky aspect to all this. The driver core sets the
> dev->driver field before calling the subsystem core's probe routine.
> As a result, the subsystem has to be very careful about performing
> runtime PM before invoking the driver's probe routine. Otherwise you
> will end up calling the driver's runtime_resume callback before the
> driver's probe! (And of course, the same problem exists in reverse
> during remove.)
I can, certainly, do that and that would, most likely, simplify a whole
bunch of drivers. But that change, I suppose, would be a whole lot more
invasive. I'll spend some time studying PCI pm_runtime support, thanks
for the tip.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/8008aa52/attachment-0001.sig>
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Alan Stern @ 2014-01-31 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391191965-31102-1-git-send-email-balbi@ti.com>
On Fri, 31 Jan 2014, Felipe Balbi wrote:
> Still TODO a commit log. Not for merging!!!!!
>
> NYET-Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> This patch is an idea I've had recently in order to combine several different
> PM implementations into the platform-bus.
>
> This patch is bare minimum for platforms which need to handle functional and
> interface clocks but the whole thing is made optional.
>
> Note that this patch makes sure that by the time a platform_driver's probe is
> called, we already have clocks enabled and pm_runtime_set_active() has been
> called, thus making sure that a device driver's pm_runtime_get_sync() will
> solely increase the pm usage counter.
>
> I have *NOT* tested this anywhere *YET*, but I suppose it shouldn't cause any
> issues since the clock API has ref counting too.
>
> Would really like to get some review from several folks involved with ARM SoC
> PM so that's the reason for the wide audience. If I have missed anybody, please
> add them to Cc.
>
> As mentioned above, this is *NOT* meant for merging, but serves as a starting
> point for discussing some convergence of several PM domain implementations on
> different arch/arm/mach-* directories.
You might want to copy the runtime-PM approach used by the PCI
subsystem. It works like this:
The core invokes a driver's probe routine with runtime PM
enabled, the device in the ACTIVE state, and the usage counter
incremented by 1.
If the driver wants to support runtime PM, the probe routine
can call pm_runtime_put_noidle.
The core does pm_runtime_get_sync before invoking the driver's
remove routine. At this point a runtime-PM-aware driver whould
call pm_runtime_get_noresume, to balance the _put during probe.
After invoking the remove routine, the core does a put_noidle
(to balance the get_sync) and a final put_sync (to balance the
increment before probe and to leave the device at low power.)
A nice consequence is that everything is transparent for drivers that
don't support runtime PM. The usage counter remains > 0 the entire
time the driver is bound.
Conversely, drivers that do support runtime PM merely have to add one
call during probe and one during remove.
There is one tricky aspect to all this. The driver core sets the
dev->driver field before calling the subsystem core's probe routine.
As a result, the subsystem has to be very careful about performing
runtime PM before invoking the driver's probe routine. Otherwise you
will end up calling the driver's runtime_resume callback before the
driver's probe! (And of course, the same problem exists in reverse
during remove.)
Alan Stern
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Felipe Balbi @ 2014-01-31 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131200434.GR27282@n2100.arm.linux.org.uk>
Hi,
On Fri, Jan 31, 2014 at 08:04:35PM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 31, 2014 at 12:12:45PM -0600, Felipe Balbi wrote:
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 3a94b79..86aeb5b 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -484,6 +484,21 @@ static int platform_drv_probe(struct device *_dev)
> > if (ACPI_HANDLE(_dev))
> > acpi_dev_pm_attach(_dev, true);
> >
> > + dev->fck = devm_clk_get(_dev, "fck");
> > + dev->ick = devm_clk_get(_dev, "ick");
> > +
> > + if (!IS_ERR(dev->fck))
> > + clk_prepare_enable(dev->fck);
> > + else
> > + dev->fck = NULL;
> > +
> > + if (!IS_ERR(dev->ick))
> > + clk_prepare_enable(dev->ick);
> > + else
> > + dev->ick = NULL;
>
> If people are going to continue doing this (converting error values to
> NULL) can we please have a check in devm_clk_get() which prevents it
> returning NULL if the implementation happens to do so?
>
> It's either that or we force all users to conform to the API which
> specifies that the error values are defined by IS_ERR() returning
> true and everything else must be considered as a potential valid return.
The idea here was just to avoid IS_ERR() checks every time we want to
enable/disable a clock since clk API already copes with NULL pointers.
This also helps with the fact that platform_bus is also used with
platforms which don't have (or otherwise don't need) any clock control
whatsoever, thus made it optional.
If everybody prefers duplication of IS_ERR() all over the place, that's
fine too.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/af65712a/attachment.sig>
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Alan Stern @ 2014-01-31 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131164534.GL20736@saruman.home>
On Fri, 31 Jan 2014, Felipe Balbi wrote:
> probe()
> {
> ...
>
> clk_get(dev, "fck");
> clk_prepare(clk);
> clk_enable(clk);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
> ...
> }
> note that because of pm_runtime_set_active() that first
> pm_runtime_get_sync() in probe() will simply increase the reference
> counter without calling my ->runtime_resume() callback, which is exactly
> what we want, as that would completely avoid situations of bad context
> being restored because of that initial pm_runtime_get_sync().
Very minor note... A slightly better way to do the same thing is:
pm_runtime_set_active(dev);
pm_runtime_get_noresume(dev);
pm_runtime_enable(dev);
The get_noresume says that you want to increment the usage counter
without performing any callbacks, and doing it before the
pm_runtime_enable avoids any window during which a runtime suspend
might somehow occur.
Alan Stern
^ permalink raw reply
* NFS client broken in Linus' tip
From: Trond Myklebust @ 2014-01-31 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130153812.GA15937@n2100.arm.linux.org.uk>
On Thu, 2014-01-30 at 15:38 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> > On Thu, Jan 30, 2014 at 02:27:52PM +0000, Russell King - ARM Linux wrote:
> > > Yes and no. I still end up with an empty /etc/mtab, but the file now
> > > exists. However, I can create and echo data into /etc/mtab, but it seems
> > > that can't happen at boot time.
> >
> > Odd. Can you disable CONFIG_NFSD_V3_ACL for now to isolate the issue?
>
> Unfortunately, that results in some problem at boot time, which
> ultimately ends up with the other three CPUs being stopped, and
> hence the original reason scrolls off the screen before it can be
> read... even at 1920p.
>
Hi Russell,
The following patch fixes the issue for me.
Cheers
Trond
8<-------------------------------------------------------------
>From 59bc20fe862bd85fcad61427e8669603e789d163 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Fri, 31 Jan 2014 14:25:19 -0500
Subject: [PATCH] fs: get_acl() must be allowed to return EOPNOTSUPP
posix_acl_xattr_get requires get_acl() to return EOPNOTSUPP if the
filesystem cannot support acls. This is needed for NFS, which can't
know whether or not the server supports acls until it tries to get/set
one.
This patch converts posix_acl_chmod and posix_acl_create to deal with
EOPNOTSUPP return values from get_acl().
Reported-by: Russell King <linux@arm.linux.org.uk>
Link: http://lkml.kernel.org/r/20140130140834.GW15937 at n2100.arm.linux.org.uk
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro viro at zeniv.linux.org.uk>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
---
fs/posix_acl.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index 38bae5a0ea25..11c54fd51e16 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -521,8 +521,11 @@ posix_acl_chmod(struct inode *inode, umode_t mode)
return -EOPNOTSUPP;
acl = get_acl(inode, ACL_TYPE_ACCESS);
- if (IS_ERR_OR_NULL(acl))
+ if (IS_ERR_OR_NULL(acl)) {
+ if (acl == ERR_PTR(-EOPNOTSUPP))
+ return 0;
return PTR_ERR(acl);
+ }
ret = __posix_acl_chmod(&acl, GFP_KERNEL, mode);
if (ret)
@@ -544,14 +547,15 @@ posix_acl_create(struct inode *dir, umode_t *mode,
goto no_acl;
p = get_acl(dir, ACL_TYPE_DEFAULT);
- if (IS_ERR(p))
+ if (IS_ERR(p)) {
+ if (p == ERR_PTR(-EOPNOTSUPP))
+ goto apply_umask;
return PTR_ERR(p);
-
- if (!p) {
- *mode &= ~current_umask();
- goto no_acl;
}
+ if (!p)
+ goto apply_umask;
+
*acl = posix_acl_clone(p, GFP_NOFS);
if (!*acl)
return -ENOMEM;
@@ -575,6 +579,8 @@ posix_acl_create(struct inode *dir, umode_t *mode,
}
return 0;
+apply_umask:
+ *mode &= ~current_umask();
no_acl:
*default_acl = NULL;
*acl = NULL;
--
1.8.5.3
--
Trond Myklebust
Linux NFS client maintainer
^ permalink raw reply related
* [PATCH 1/4] ARM: STi: add stid127 soc support
From: Arnd Bergmann @ 2014-01-31 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EB96BB.6070800@st.com>
On Friday 31 January 2014, srinivas kandagatla wrote:
> > Sorry if I missed the initial review, but can you explain
> > why this is needed to start with?
>
> On ST SoCs the default value for L2 AUX_CTRL register is 0x0, so we set
> the way-size explicit here.
Unfortunately, we keep going back and forth on the L2 cache controller
setup between "it should work automatically" and "we don't want to
have configuration data in DT", where my personal opinion is that
the first one is more important here.
Now, there are a couple of properties that are defined in
Documentation/devicetree/bindings/arm/l2cc.txt to let some of the
things get set up automatically already. Can you check which bits
are missing there, if any? Are they better described as "configuration"
or "hardware" settings?
Arnd
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Rob Herring @ 2014-01-31 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391107002-21470-3-git-send-email-galak@codeaurora.org>
On Thu, Jan 30, 2014 at 12:36 PM, Kumar Gala <galak@codeaurora.org> wrote:
> Introduce a new mach-qcom that will support SoCs that intend to be
> multiplatform compatiable while keeping mach-msm to legacy SoC/board
> support that will not transition over to multiplatform.
>
> As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
> to mach-qcom.
>
> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> ---
[snip]
> diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
> new file mode 100644
> index 0000000..8830431
> --- /dev/null
> +++ b/arch/arm/mach-qcom/Kconfig
> @@ -0,0 +1,34 @@
> +config ARCH_QCOM
> + bool "Qualcomm Support" if ARCH_MULTI_V7
> + select ARCH_REQUIRE_GPIOLIB
> + select CLKSRC_OF
> + select GENERIC_CLOCKEVENTS
> + select ARM_GIC
> + select CPU_V7
CPU_V7 is already selected by MULTI_V7.
[snip]
> diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-qcom/smp.c
> similarity index 97%
> rename from arch/arm/mach-msm/platsmp.c
> rename to arch/arm/mach-qcom/smp.c
> index 42eb6b7..28364cb 100644
> --- a/arch/arm/mach-msm/platsmp.c
> +++ b/arch/arm/mach-qcom/smp.c
> @@ -2,6 +2,7 @@
> * Copyright (C) 2002 ARM Ltd.
> * All Rights Reserved
> * Copyright (c) 2010, Code Aurora Forum. All rights reserved.
> + * Copyright (c) 2014 The Linux Foundation. All rights reserved.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -20,7 +21,6 @@
> #include <asm/smp_plat.h>
>
> #include "scm-boot.h"
> -#include "common.h"
>
> #define VDD_SC1_ARRAY_CLAMP_GFS_CTL 0x35a0
> #define SCSS_CPU1CORE_RESET 0x2d80
> @@ -48,6 +48,15 @@ extern void secondary_startup(void);
>
> static DEFINE_SPINLOCK(boot_lock);
>
> +static void __ref msm_cpu_die(unsigned int cpu)
> +{
> +
> + asm("wfi"
> + :
> + :
> + : "memory", "cc");
> +}
I realize this is just a move, but there is a wfi() macro that can be
used here instead.
Rob
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Russell King - ARM Linux @ 2014-01-31 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391191965-31102-1-git-send-email-balbi@ti.com>
On Fri, Jan 31, 2014 at 12:12:45PM -0600, Felipe Balbi wrote:
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 3a94b79..86aeb5b 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -484,6 +484,21 @@ static int platform_drv_probe(struct device *_dev)
> if (ACPI_HANDLE(_dev))
> acpi_dev_pm_attach(_dev, true);
>
> + dev->fck = devm_clk_get(_dev, "fck");
> + dev->ick = devm_clk_get(_dev, "ick");
> +
> + if (!IS_ERR(dev->fck))
> + clk_prepare_enable(dev->fck);
> + else
> + dev->fck = NULL;
> +
> + if (!IS_ERR(dev->ick))
> + clk_prepare_enable(dev->ick);
> + else
> + dev->ick = NULL;
If people are going to continue doing this (converting error values to
NULL) can we please have a check in devm_clk_get() which prevents it
returning NULL if the implementation happens to do so?
It's either that or we force all users to conform to the API which
specifies that the error values are defined by IS_ERR() returning
true and everything else must be considered as a potential valid return.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Kumar Gala @ 2014-01-31 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3511712.H3ChLoqCm7@wuerfel>
On Jan 31, 2014, at 1:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 31 January 2014 13:25:25 Kumar Gala wrote:
>>> The hotplug.c change sticks out as something that isn't just a move
>>> of code to another place, but deletion of unused code. It would
>>> be nice to split that out into a separate change, possibly together
>>> with the trivial board.c and smp.c changes.
>>
>> That?s not 100% true, the hotplug.c code implemented msm_cpu_die, which moved into smp.c
>>
>> I can split out scm*/smp* into a patch to enable smp if that is really desired, but not exactly sure what it gets us.
>>
>
> It's not extremely important, I just prefer splitting patches
> that have any kind of functional change from trivial moves.
>
> If something happens to break for an unforseen reason, it's
> easier to bisect to the patch that does the change.
>
> Arnd
I?ll push my change to hotplug.c into the SMP patch set that Stephen started.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Arnd Bergmann @ 2014-01-31 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2B2190A4-6689-40D8-A3D7-BD2D882A2CF6@codeaurora.org>
On Friday 31 January 2014 13:25:25 Kumar Gala wrote:
> > The hotplug.c change sticks out as something that isn't just a move
> > of code to another place, but deletion of unused code. It would
> > be nice to split that out into a separate change, possibly together
> > with the trivial board.c and smp.c changes.
>
> That?s not 100% true, the hotplug.c code implemented msm_cpu_die, which moved into smp.c
>
> I can split out scm*/smp* into a patch to enable smp if that is really desired, but not exactly sure what it gets us.
>
It's not extremely important, I just prefer splitting patches
that have any kind of functional change from trivial moves.
If something happens to break for an unforseen reason, it's
easier to bisect to the patch that does the change.
Arnd
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Kumar Gala @ 2014-01-31 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401312020.16984.arnd@arndb.de>
On Jan 31, 2014, at 1:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 30 January 2014, Kumar Gala wrote:
>> Introduce a new mach-qcom that will support SoCs that intend to be
>> multiplatform compatiable while keeping mach-msm to legacy SoC/board
>> support that will not transition over to multiplatform.
>>
>> As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
>> to mach-qcom.
>>
>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>> ---
>> MAINTAINERS | 7 +++
>> arch/arm/Kconfig | 7 +--
>> arch/arm/Makefile | 1 +
>> arch/arm/boot/dts/Makefile | 6 +--
>> arch/arm/mach-msm/Kconfig | 45 +------------------
>> arch/arm/mach-msm/Makefile | 7 ---
>> arch/arm/mach-msm/hotplug.c | 51 ----------------------
>> arch/arm/mach-qcom/Kconfig | 34 +++++++++++++++
>> arch/arm/mach-qcom/Makefile | 5 +++
>> .../arm/{mach-msm/board-dt.c => mach-qcom/board.c} | 9 ++--
>> arch/arm/{mach-msm => mach-qcom}/scm-boot.c | 0
>> arch/arm/{mach-msm => mach-qcom}/scm-boot.h | 0
>> arch/arm/{mach-msm => mach-qcom}/scm.c | 0
>> arch/arm/{mach-msm => mach-qcom}/scm.h | 0
>> arch/arm/{mach-msm/platsmp.c => mach-qcom/smp.c} | 11 ++++-
>
> The hotplug.c change sticks out as something that isn't just a move
> of code to another place, but deletion of unused code. It would
> be nice to split that out into a separate change, possibly together
> with the trivial board.c and smp.c changes.
That?s not 100% true, the hotplug.c code implemented msm_cpu_die, which moved into smp.c
I can split out scm*/smp* into a patch to enable smp if that is really desired, but not exactly sure what it gets us.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Santosh Shilimkar @ 2014-01-31 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131164534.GL20736@saruman.home>
On Friday 31 January 2014 11:45 AM, Felipe Balbi wrote:
> On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote:
>> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
>>> On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
>>>> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
>>>>> Hi,
>>>>>
>>>>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
>>>>>> The Keystone PM management layer has been implemented using PM bus for
>>>>>> power management clocks. As result, most of Keystone drivers don't need
>>>>>> to manage clocks directly. They just need to enable runtime PM and use it
>>>>>> to handle their PM state and clocks.
>>>>>>
>>>>>> Hence, remove clock management code and switch to use runtime PM.
>>>>>>
>>>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>>>>
>>>>> quite a few weeks back I sent a series enabling runtime pm for all glue
>>>>> layers. I'll use that version instead, sorry.
>>>>>
>>>> That should be fine but you need to drop clk_*() related code
>>>> from that patch. I assume you will send refresh version of it then.
>>>
>>> why ? it makes no difference if you enable twice and disable twice.
>>>
>> Sure but why do you want to have the clock node handling code in drivers
>> if it is not needed. Isn't that better ?
>
> It might, but then way that I wanted to see it is so that I can make
> assumptions about the device state. From a driver perspective, what I
> would love to see is the ability to assume that when my probe gets
> called the device is already enabled. So if you can make sure that
> clk_enable() happens before my probe and that you call
> pm_runtime_set_active() before my probe too, then I can more than
> hapilly remove clk_* calls from the driver ;-)
>
> either that or maintain the driver like so:
>
> probe()
> {
> ...
>
> clk_get(dev, "fck");
> clk_prepare(clk);
> clk_enable(clk);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
> ...
> }
>
> runtime_suspend()
> {
> clk_disable(dev);
> }
>
> runtime_resume()
> {
> clk_enable(dev);
> }
>
> note that because of pm_runtime_set_active() that first
> pm_runtime_get_sync() in probe() will simply increase the reference
> counter without calling my ->runtime_resume() callback, which is exactly
> what we want, as that would completely avoid situations of bad context
> being restored because of that initial pm_runtime_get_sync().
>
Thanks for making your point bit clear.
> Then, we can even make pm_runtime completely async easily, because
> clk_prepare() was called only on probe() (or before it, for that
> matter).
>
> Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
> clk_enable() and pm_runtime_set_active() will be called properly before
> my probe, i'll be more than happy to comply with your request above as
> that will greatly simplify my driver.
>
Which is the case at least I see on Keystone. And hence the patch from
Grygorii works. I also noticed your proposal for wider platform to
enforce above behavior which seems to be a good idea.
> Just make, also, that if this clock is shared between dwc3-keystone
> wrapper and dwc3 core, you clk_get() on both driver's probe.
>
I understand. In summary, whichever patch you pick(yours) or Grygorii's,
its completely safe to remove the clock handling from Keystone USB driver.
Regards,
Santosh
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Arnd Bergmann @ 2014-01-31 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391107002-21470-3-git-send-email-galak@codeaurora.org>
On Thursday 30 January 2014, Kumar Gala wrote:
> Introduce a new mach-qcom that will support SoCs that intend to be
> multiplatform compatiable while keeping mach-msm to legacy SoC/board
> support that will not transition over to multiplatform.
>
> As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
> to mach-qcom.
>
> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> ---
> MAINTAINERS | 7 +++
> arch/arm/Kconfig | 7 +--
> arch/arm/Makefile | 1 +
> arch/arm/boot/dts/Makefile | 6 +--
> arch/arm/mach-msm/Kconfig | 45 +------------------
> arch/arm/mach-msm/Makefile | 7 ---
> arch/arm/mach-msm/hotplug.c | 51 ----------------------
> arch/arm/mach-qcom/Kconfig | 34 +++++++++++++++
> arch/arm/mach-qcom/Makefile | 5 +++
> .../arm/{mach-msm/board-dt.c => mach-qcom/board.c} | 9 ++--
> arch/arm/{mach-msm => mach-qcom}/scm-boot.c | 0
> arch/arm/{mach-msm => mach-qcom}/scm-boot.h | 0
> arch/arm/{mach-msm => mach-qcom}/scm.c | 0
> arch/arm/{mach-msm => mach-qcom}/scm.h | 0
> arch/arm/{mach-msm/platsmp.c => mach-qcom/smp.c} | 11 ++++-
The hotplug.c change sticks out as something that isn't just a move
of code to another place, but deletion of unused code. It would
be nice to split that out into a separate change, possibly together
with the trivial board.c and smp.c changes.
Arnd
^ permalink raw reply
* [PATCH 0/4] Split mach-msm into legacy and mach-qcom (multiplatform)
From: Olof Johansson @ 2014-01-31 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391107002-21470-1-git-send-email-galak@codeaurora.org>
On Thu, Jan 30, 2014 at 12:36:38PM -0600, Kumar Gala wrote:
> This is the starts of splitting the Qualcomm MSM platform into legacy support
> that we will not try and convert to multiplatform and multiplatform support.
> These patches are based on the 'CPU enable method based SMP' patches.
>
> I wanted to get these out for review, will add a few more patches for defconfig
> updates/additions, as well as some additional driver being enabled for ARCH_QCOM.
Series:
Acked-by: Olof Johansson <olof@lixom.net>
See comment on the MAINTAINERS addition; let me know how you prefer to send us
patches. We can apply from mailing lists we just need to know your preference.
-Olof
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Olof Johansson @ 2014-01-31 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391107002-21470-3-git-send-email-galak@codeaurora.org>
On Thu, Jan 30, 2014 at 12:36:40PM -0600, Kumar Gala wrote:
> Introduce a new mach-qcom that will support SoCs that intend to be
> multiplatform compatiable while keeping mach-msm to legacy SoC/board
> support that will not transition over to multiplatform.
>
> As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
> to mach-qcom.
>
> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> ---
> MAINTAINERS | 7 +++
> arch/arm/Kconfig | 7 +--
> arch/arm/Makefile | 1 +
> arch/arm/boot/dts/Makefile | 6 +--
> arch/arm/mach-msm/Kconfig | 45 +------------------
> arch/arm/mach-msm/Makefile | 7 ---
> arch/arm/mach-msm/hotplug.c | 51 ----------------------
> arch/arm/mach-qcom/Kconfig | 34 +++++++++++++++
> arch/arm/mach-qcom/Makefile | 5 +++
> .../arm/{mach-msm/board-dt.c => mach-qcom/board.c} | 9 ++--
> arch/arm/{mach-msm => mach-qcom}/scm-boot.c | 0
> arch/arm/{mach-msm => mach-qcom}/scm-boot.h | 0
> arch/arm/{mach-msm => mach-qcom}/scm.c | 0
> arch/arm/{mach-msm => mach-qcom}/scm.h | 0
> arch/arm/{mach-msm/platsmp.c => mach-qcom/smp.c} | 11 ++++-
> 15 files changed, 70 insertions(+), 113 deletions(-)
> delete mode 100644 arch/arm/mach-msm/hotplug.c
> create mode 100644 arch/arm/mach-qcom/Kconfig
> create mode 100644 arch/arm/mach-qcom/Makefile
> rename arch/arm/{mach-msm/board-dt.c => mach-qcom/board.c} (71%)
> rename arch/arm/{mach-msm => mach-qcom}/scm-boot.c (100%)
> rename arch/arm/{mach-msm => mach-qcom}/scm-boot.h (100%)
> rename arch/arm/{mach-msm => mach-qcom}/scm.c (100%)
> rename arch/arm/{mach-msm => mach-qcom}/scm.h (100%)
> rename arch/arm/{mach-msm/platsmp.c => mach-qcom/smp.c} (97%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a31a6e3..1817078 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1174,6 +1174,13 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> W: http://www.arm.linux.org.uk/
> S: Maintained
>
> +ARM/QUALCOMM SUPPORT
> +M: David Brown <davidb@codeaurora.org>
> +M: Kumar Gala <galak@codeaurora.org>
> +L: linux-arm-msm at vger.kernel.org
> +S: Maintained
> +F: arch/arm/mach-qcom/
Git repo? If you want us to apply patches for us we can do that, but if
you prefer to run a tree and do pull requests then you should have an
URL to it here.
-Olof
^ permalink raw reply
* [PATCH] Detect section mismatches in thumb relocations
From: David Long @ 2014-01-31 18:33 UTC (permalink / raw)
To: linux-arm-kernel
From: "David A. Long" <dave.long@linaro.org>
Add processing for normally encountered thumb relocation types so that
section mismatches will be detected.
Signed-off-by: David A. Long <dave.long@linaro.org>
---
scripts/mod/modpost.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 1785576..9e6c996 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1498,6 +1498,16 @@ static int addend_386_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
#define R_ARM_JUMP24 29
#endif
+#ifndef R_ARM_THM_CALL
+#define R_ARM_THM_CALL 10
+#endif
+#ifndef R_ARM_THM_JUMP24
+#define R_ARM_THM_JUMP24 30
+#endif
+#ifndef R_ARM_THM_JUMP19
+#define R_ARM_THM_JUMP19 51
+#endif
+
static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
{
unsigned int r_typ = ELF_R_TYPE(r->r_info);
@@ -1511,6 +1521,9 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
case R_ARM_PC24:
case R_ARM_CALL:
case R_ARM_JUMP24:
+ case R_ARM_THM_CALL:
+ case R_ARM_THM_JUMP24:
+ case R_ARM_THM_JUMP19:
/* From ARM ABI: ((S + A) | T) - P */
r->r_addend = (int)(long)(elf->hdr +
sechdr->sh_offset +
--
1.8.1.2
^ permalink raw reply related
* [PATCH] of: add vendor prefix for Allwinner Technology
From: Rob Herring @ 2014-01-31 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391045798-7053-1-git-send-email-emilio@elopez.com.ar>
On Wed, Jan 29, 2014 at 7:36 PM, Emilio L?pez <emilio@elopez.com.ar> wrote:
> We have been using the "allwinner" prefix for everything so far; let's
> document it here.
>
> Signed-off-by: Emilio L?pez <emilio@elopez.com.ar>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied.
Rob
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index edbb8d8..5a2904b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -7,6 +7,7 @@ ad Avionic Design GmbH
> adi Analog Devices, Inc.
> aeroflexgaisler Aeroflex Gaisler AB
> ak Asahi Kasei Corp.
> +allwinner Allwinner Technology Co., Ltd.
> altr Altera Corp.
> amcc Applied Micro Circuits Corporation (APM, formally AMCC)
> apm Applied Micro Circuits Corporation (APM)
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Felipe Balbi @ 2014-01-31 18:12 UTC (permalink / raw)
To: linux-arm-kernel
Still TODO a commit log. Not for merging!!!!!
NYET-Signed-off-by: Felipe Balbi <balbi@ti.com>
---
This patch is an idea I've had recently in order to combine several different
PM implementations into the platform-bus.
This patch is bare minimum for platforms which need to handle functional and
interface clocks but the whole thing is made optional.
Note that this patch makes sure that by the time a platform_driver's probe is
called, we already have clocks enabled and pm_runtime_set_active() has been
called, thus making sure that a device driver's pm_runtime_get_sync() will
solely increase the pm usage counter.
I have *NOT* tested this anywhere *YET*, but I suppose it shouldn't cause any
issues since the clock API has ref counting too.
Would really like to get some review from several folks involved with ARM SoC
PM so that's the reason for the wide audience. If I have missed anybody, please
add them to Cc.
As mentioned above, this is *NOT* meant for merging, but serves as a starting
point for discussing some convergence of several PM domain implementations on
different arch/arm/mach-* directories.
For OMAP, this has the added benefit of removing clock handling from
omap_device/omap_hwmod and, thus, dropping the need for so many DT_CLK() tables
under drivers/clk/ti/
drivers/base/platform.c | 169 ++++++++++++++++++++++++++++++++++++++--
include/linux/platform_device.h | 9 +++
2 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b79..86aeb5b 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -484,6 +484,21 @@ static int platform_drv_probe(struct device *_dev)
if (ACPI_HANDLE(_dev))
acpi_dev_pm_attach(_dev, true);
+ dev->fck = devm_clk_get(_dev, "fck");
+ dev->ick = devm_clk_get(_dev, "ick");
+
+ if (!IS_ERR(dev->fck))
+ clk_prepare_enable(dev->fck);
+ else
+ dev->fck = NULL;
+
+ if (!IS_ERR(dev->ick))
+ clk_prepare_enable(dev->ick);
+ else
+ dev->ick = NULL;
+
+ pm_runtime_set_active(_dev);
+
ret = drv->probe(dev);
if (ret && ACPI_HANDLE(_dev))
acpi_dev_pm_detach(_dev, true);
@@ -507,6 +522,14 @@ static int platform_drv_remove(struct device *_dev)
struct platform_device *dev = to_platform_device(_dev);
int ret;
+ if (!IS_ERR(dev->ick))
+ clk_disable_unprepare(dev->ick);
+
+ if (!IS_ERR(dev->fck))
+ clk_disable_unprepare(dev->fck);
+
+ pm_runtime_set_suspended(_dev);
+
ret = drv->remove(dev);
if (ACPI_HANDLE(_dev))
acpi_dev_pm_detach(_dev, true);
@@ -780,6 +803,59 @@ static int platform_legacy_resume(struct device *dev)
#endif /* CONFIG_PM_SLEEP */
+#ifdef CONFIG_PM_RUNTIME
+int platform_pm_runtime_suspend(struct device *dev)
+{
+ struct device_driver *drv = dev->driver;
+ struct platform_driver *pdrv = to_platform_driver(drv);
+ struct platform_device *pdev = to_platform_device(dev);
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_ICK, &pdrv->flags))
+ clk_disable(pdev->ick);
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_FCK, &pdrv->flags))
+ clk_disable(pdev->fck);
+
+ return ret;
+}
+
+int platform_pm_runtime_resume(struct device *dev)
+{
+ struct device_driver *drv = dev->driver;
+ struct platform_driver *pdrv = to_platform_driver(drv);
+ struct platform_device *pdev = to_platform_device(dev);
+ int ret;
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_ICK, &pdrv->flags)) {
+ ret = clk_enable(pdev->ick);
+ if (ret)
+ return ret;
+ }
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_FCK, &pdrv->flags)) {
+ ret = clk_enable(pdev->fck);
+ if (ret) {
+ clk_disable(pdev->ick);
+ return ret;
+ }
+ }
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret) {
+ clk_disable(pdev->ick);
+ clk_disable(pdev->fck);
+ return ret;
+ }
+
+ return ret;
+}
+#endif
+
#ifdef CONFIG_SUSPEND
int platform_pm_suspend(struct device *dev)
@@ -790,6 +866,9 @@ int platform_pm_suspend(struct device *dev)
if (!drv)
return 0;
+ if (pm_runtime_suspended(dev))
+ return 0;
+
if (drv->pm) {
if (drv->pm->suspend)
ret = drv->pm->suspend(dev);
@@ -802,12 +881,27 @@ int platform_pm_suspend(struct device *dev)
int platform_pm_resume(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct device_driver *drv = dev->driver;
int ret = 0;
if (!drv)
return 0;
+ ret = clk_enable(pdev->ick);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(pdev->fck);
+ if (ret) {
+ clk_disable(pdev->ick);
+ return ret;
+ }
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
if (drv->pm) {
if (drv->pm->resume)
ret = drv->pm->resume(dev);
@@ -815,7 +909,17 @@ int platform_pm_resume(struct device *dev)
ret = platform_legacy_resume(dev);
}
- return ret;
+ if (ret) {
+ clk_disable(pdev->ick);
+ clk_disable(pdev->fck);
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+
+ return ret;
+ }
+
+ return 0;
}
#endif /* CONFIG_SUSPEND */
@@ -830,6 +934,9 @@ int platform_pm_freeze(struct device *dev)
if (!drv)
return 0;
+ if (pm_runtime_suspended(dev))
+ return 0;
+
if (drv->pm) {
if (drv->pm->freeze)
ret = drv->pm->freeze(dev);
@@ -848,6 +955,20 @@ int platform_pm_thaw(struct device *dev)
if (!drv)
return 0;
+ ret = clk_enable(pdev->ick);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(pdev->fck);
+ if (ret) {
+ clk_disable(pdev->ick);
+ return ret;
+ }
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
if (drv->pm) {
if (drv->pm->thaw)
ret = drv->pm->thaw(dev);
@@ -855,7 +976,17 @@ int platform_pm_thaw(struct device *dev)
ret = platform_legacy_resume(dev);
}
- return ret;
+ if (ret) {
+ clk_disable(pdev->ick);
+ clk_disable(pdev->fck);
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+
+ return ret;
+ }
+
+ return 0;
}
int platform_pm_poweroff(struct device *dev)
@@ -866,6 +997,9 @@ int platform_pm_poweroff(struct device *dev)
if (!drv)
return 0;
+ if (pm_runtime_suspended(dev))
+ return 0;
+
if (drv->pm) {
if (drv->pm->poweroff)
ret = drv->pm->poweroff(dev);
@@ -884,6 +1018,20 @@ int platform_pm_restore(struct device *dev)
if (!drv)
return 0;
+ ret = clk_enable(pdev->ick);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(pdev->fck);
+ if (ret) {
+ clk_disable(pdev->ick);
+ return ret;
+ }
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
if (drv->pm) {
if (drv->pm->restore)
ret = drv->pm->restore(dev);
@@ -891,14 +1039,25 @@ int platform_pm_restore(struct device *dev)
ret = platform_legacy_resume(dev);
}
- return ret;
+ if (ret) {
+ clk_disable(pdev->ick);
+ clk_disable(pdev->fck);
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+
+ return ret;
+ }
+
+ return 0;
}
#endif /* CONFIG_HIBERNATE_CALLBACKS */
static const struct dev_pm_ops platform_dev_pm_ops = {
- .runtime_suspend = pm_generic_runtime_suspend,
- .runtime_resume = pm_generic_runtime_resume,
+ SET_RUNTIME_PM_OPS(platform_pm_runtime_suspend,
+ platform_pm_runtime_resume,
+ NULL)
USE_PLATFORM_PM_SLEEP_OPS
};
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 16f6654..91133f5 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -12,6 +12,7 @@
#define _PLATFORM_DEVICE_H_
#include <linux/device.h>
+#include <linux/clk.h>
#include <linux/mod_devicetable.h>
#define PLATFORM_DEVID_NONE (-1)
@@ -21,6 +22,10 @@ struct mfd_cell;
struct platform_device {
const char *name;
+
+ struct clk *fck;
+ struct clk *ick;
+
int id;
bool id_auto;
struct device dev;
@@ -179,8 +184,12 @@ struct platform_driver {
struct device_driver driver;
const struct platform_device_id *id_table;
bool prevent_deferred_probe;
+ unsigned long flags;
};
+#define PLATFORM_PM_RUNTIME_KEEP_ICK BIT(0)
+#define PLATFORM_PM_RUNTIME_KEEP_FCK BIT(1)
+
#define to_platform_driver(drv) (container_of((drv), struct platform_driver, \
driver))
--
1.8.5.2
^ permalink raw reply related
* Extending OPP bindings
From: Lorenzo Pieralisi @ 2014-01-31 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+Kq9C39xr9tY8gSX+6QFkNDqwmTyC+dBhLNcxKMweCpw@mail.gmail.com>
Hi Rob,
thanks for having a look.
On Fri, Jan 31, 2014 at 05:17:51PM +0000, Rob Herring wrote:
> On Fri, Jan 31, 2014 at 6:46 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > Hi Nishanth,
> >
> > On Fri, Jan 31, 2014 at 12:43:54AM +0000, Nishanth Menon wrote:
> >> Hi Sudeep,
> >>
> >> On 01/30/2014 07:43 AM, Sudeep Holla wrote:
> >>
> >> >
> >> > I am looking into a couple shortcomings in the current OPP bindings and
> >> > how to address them. Feel free to add to the list if you think of any more
> >> > issues that needs to be addressed or if and how any problem mentioned below
> >> > can be handled with the existing bindings.
> >> >
> >> > 1. indexing: currently there are no indices in the operating-points.
> >> indexing is based on frequency which is why the accessors use
> >> frequency to pull out the OPP data.
> >>
> >> indexing is a horrible idea - on platforms where OPP may be disabled
> >> or enabled for various reasons(see arch/arm/mach-imx/mach-imx6q.c,
> >> arch/arm/mach-omap2/board-omap3beagle.c etc) - the indexing you see in
> >> dts is just a myth that may not exist once the nodes are loaded and
> >> operated upon depending on SoC variations (example efuse describing
> >> which OPPs can be used and which not).
> >
> > I do not understand why. As long as a mapping from DT to data structures
> > in the kernel is done at boot, I can see how by indexing device nodes
> > can refer to specific OPPs. If they are disabled, amen, as long as we
> > can point at specific operating points that should be ok.
> >
> > Indexing does not mean that the index in the DT is the same as the one
> > allocated by the OS. Indexing is there to point at specific OPPs from
> > different DT nodes, a good example are clock bindings and that's exactly
> > how they work.
>
> That is not a good comparison. With clocks, you are describing which
> physical signal coming out of a hardware block much like interrupts.
> Granted the h/w is not typically documented that way for clocks
> although the numbering could correspond to register bit locations as
> interrupt numbers do. With OPP indexes, they are a totally made up
> software construct.
Well ok, it might be, what I know is that current OPPs do not allow
other nodes to reference their properties properly, I am not sure that adding
an index make things worse, actually they are already broken as they are.
> Perhaps OPPs should be nodes so new fields can be added easily and
> then you have a phandle for each OPP.
Yeah, but the end result is the same, it has more to do with how to
express dependencies with DT than the question on whether to use a phandle
or an index. If we have to add phandles so be it, it is still just a way
to reference properties for me.
> > Can you provide me with an example where the indexing would go wrong
> > please ?
>
> Putting s/w indexes into DT. Using cell-index for uarts to define
> their tty number was one example.
The idea was not related to using that index in the kernel at all, but
since you are all against using this mechanism, I think that's for a good
reason so we will not do that. How to do it, it has to be seen though.
> > Certainly relying on implicit ordering is not great either, actually I
> > would say that it is broken.
> >
> >> That said, the original OPP[1][2] series discussion started by trying
> >> to kill indexing precisely for the same reason.. once you have it - it
> >> becomes just crazy to deal with.
> >
> > I could not find any "index killing" :) discussion in there, but I will
> > keep reading.
> >
> >> > It's assumed that the list is either in ascending or descending
> >> > order of frequency but not explicit in the binding document.
> >> > There are arch/arm/boot/dts/* files with opps in both styles.
> >> it should not matter -> opp library should do an insertion sort and
> >> organize it in ascending order once all the data is inserted. (line
> >> 449ish in opp.c)
> >
> > That's OS details and they must not be mandated by the bindings.
> > We cannot rely on word of mouth for things to work, I do not like
> > implicit rules, so the bindings should speficy the ordering or better
> > a way to reference OPPs.
> >
> >> if you see issues with the insertion sort not functioning, it is a bug
> >> and should be easy to track down and fix.
> >
> > Problem is not the insertion sort, problem is that DT bindings do not
> > define a way to refer to a specific OPP, unless we do that implicitly
> > and again, I rest my case, that is broken.
> >
> >> > Few other bindings like thermal defines bindings like
> >> > cooling-{min,max}-state assuming some order which is broken IMO.
> >> Now that you bring it up, I missed it :(.. yeah, I might have
> >> preferred it to be min frequency and max_frequency - I agree it is
> >> probably broken. I'd let Eduardo comment more about it.
> >>
> >> >
> >> > One such use-case that came up recently[0] is the c-state latencies
> >> > which could be different for each OPP. It would be good if the
> >> > latencies are specified with the indices to OPP table to avoid
> >> > inconsistency between the bindings.
> >>
> >> You can define C states based on frequencies as well - which really
> >> makes sense - since that sounds really like our constraint (say
> >> valid-at-frequency "xyz"
> >
> > I do not think that's generic enough, I do not like the idea of looking
> > up frequencies (eg a C-state target_residency does not depend on the
> > frequency only - ie voltage and other factors play a role, it really
> > depends on an operating point- looking it up by frequency is misleading IMO).
>
> It seems we are trying to fit a square peg into a round hole here.
Do you mean that this is something not worth describing ? That it has to
be described differently ? Or that current DT semantics is not suitable for
describing it ?
We have to find a solution and we are keen on reworking it, otherwise we just
pretend there are no dependencies on the OPPs from other DT nodes, but I
am afraid that's already the case now.
Thank you,
Lorenzo
^ permalink raw reply
* [GIT PULL] arm64 patches for 3.14
From: Catalin Marinas @ 2014-01-31 18:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the arm64 patches below. Thanks.
The following changes since commit 883c057367014d20a14b5054e4eb0d81ce3bea5c:
arm64: fix typo in entry.S (2014-01-13 13:55:13 +0000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream
for you to fetch changes up to c2c93e5b7f3f42277ec25ff3746096abc0c0d0f7:
arm64: mm: Introduce PTE_WRITE (2014-01-31 11:30:49 +0000)
----------------------------------------------------------------
- Build fix with DMA_CMA enabled
- Introduction of PTE_WRITE to distinguish between writable but clean
and truly read-only pages
- FIQs enabling/disabling clean-up (they aren't used on arm64)
- CPU resume fix for the per-cpu offset restoring
- Code comment typos
----------------------------------------------------------------
Jingoo Han (3):
arm64: mm: use ubfm for dcache_line_size
arm64: mm: fix the function name in comment of __flush_dcache_area
arm64: mm: fix the function name in comment of cpu_do_switch_mm
Lorenzo Pieralisi (1):
arm64: kernel: fix per-cpu offset restore on resume
Nicolas Pitre (1):
arm64: FIQs are unused
Pankaj Dubey (1):
arm64: fix build error if DMA_CMA is enabled
Steve Capper (2):
arm64: mm: Remove PTE_BIT_FUNC macro
arm64: mm: Introduce PTE_WRITE
arch/arm64/include/asm/dma-contiguous.h | 1 -
arch/arm64/include/asm/pgtable.h | 93 ++++++++++++++++++++++-----------
arch/arm64/kernel/process.c | 6 ---
arch/arm64/kernel/smp.c | 2 -
arch/arm64/kernel/suspend.c | 8 +++
arch/arm64/mm/cache.S | 2 +-
arch/arm64/mm/proc-macros.S | 3 +-
arch/arm64/mm/proc.S | 2 +-
8 files changed, 74 insertions(+), 43 deletions(-)
--
Catalin
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Rob Herring @ 2014-01-31 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA8CFE.7020404@arm.com>
On Thu, Jan 30, 2014 at 11:33 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 30/01/14 17:28, Arnd Bergmann wrote:
>> On Thursday 30 January 2014, Ian Campbell wrote:
>>> mach-virt has existed for a while but it is not written down what it actually
>>> consists of. Although it seems a bit unusual to document a binding for an
>>> entire platform since mach-virt is entirely virtual it is helpful to have
>>> something to refer to in the absence of a single concrete implementation.
>>>
>>> I've done my best to capture the requirements based on the git log and my
>>> memory/understanding.
>>>
>>> While here remove the xenvm dts example, the Xen tools will now build a
>>> suitable mach-virt compatible dts when launching the guest.
>>
>> It might be worth noting in the changeset comment that the 'compatible'
>> string is actually no longer needed on newer kernels: All the members
>> of the machine descriptor are now the defaults (we should remove the
>> virt_init() function as well), and the fallback machine descriptor should
>> work just fine if any other string gets passed.
>
> I will ack the patch that removes the mach-virt directory altogether!
Did I never send that one out? I know I started something. Finding new
employment has had me distracted...
Rob
^ permalink raw reply
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Andy Gross @ 2014-01-31 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E2698B.6070001@metafoo.de>
On Fri, Jan 24, 2014 at 02:24:27PM +0100, Lars-Peter Clausen wrote:
> On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
> > Hi Lars,
> >
> > On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> >> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
> >> [...]
> >>> +/**
> >>> + * xilinx_vdma_device_control - Configure DMA channel of the device
> >>> + * @dchan: DMA Channel pointer
> >>> + * @cmd: DMA control command
> >>> + * @arg: Channel configuration
> >>> + *
> >>> + * Return: '0' on success and failure value on error
> >>> + */
> >>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
> >>> + enum dma_ctrl_cmd cmd, unsigned long arg)
> >>> +{
> >>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> >>> +
> >>> + switch (cmd) {
> >>> + case DMA_TERMINATE_ALL:
> >>> + xilinx_vdma_terminate_all(chan);
> >>> + return 0;
> >>> + case DMA_SLAVE_CONFIG:
> >>> + return xilinx_vdma_slave_config(chan,
> >>> + (struct xilinx_vdma_config *)arg);
> >>
> >> You really shouldn't be overloading the generic API with your own semantics.
> >> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
> >
> > Ok. The driver needs few additional configuration from the slave
> > device like Vertical
> > Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
> > suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
> > defined for Freescale drivers?
>
> In my opinion it is not a good idea to have driver implement a generic API,
> but at the same time let the driver have custom semantics for those API
> calls. It's a bit like having a gpio driver that expects 23 and 42 as the
> values passed to gpio_set_value instead of 0 and 1. It completely defeats
> the purpose of a generic API, namely that you are able to write generic code
> that makes use of the API without having to know about which implementation
> API it is talking to. The dmaengine framework provides the
> dmaengine_prep_interleaved_dma() function to setup two dimensional
> transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
>
The comments in the include/linux/dmaengine.h state that if you have
non-generic, non-fixed configuration then you can just create your own
structure and embed the dma_slave_config. Using the container_of you can get
back your structure.
I agree that we should always use the generic structure if possible, but
sometimes there are some non-standard things that you have to do for your
hardware. I am currently in a bind for adding some quirky features that are
required by peripherals who want to use the QCOM DMA devices.
If the context field in prep_slave_sg and prep_dma_cyclic was exposed to
everyone, that would allow an easy way to pass in hardware specific
configuration without bastardizing the slave_config. I noticed that rapidio is
the only consumer of that field and that they have their own prep function.
If we are not going to allow people to do their own slave_config when they need
to, then we need to remove the comments from the include file and expose the
context to the dmaengine_prep_slave_sg and dmaengine_prep_dma_cyclic.
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ 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