* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:51 UTC (permalink / raw)
To: Grant Likely
Cc: Mark Brown, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024135950.GV8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> > >
> > > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > > when calling regulator_register(regulator_desc, dev, ...) from
> > > > regulator driver, the regulator core will be able to find all nodes under
> > > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> > >
> > > Please provide concrete examples of the bindings you're talking about,
> > > the really important thing here is how sane the bindings look and I've
> > > really got no idea what any of what you're talking about will look like
> > > or if they make sense.
> > >
> > The only thing different from what I attached last time is the
> > compatible string added to 'regulators' node.
> >
> > ecspi@70010000 { /* ECSPI1 */
> > fsl,spi-num-chipselects = <2>;
> > cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> > <&gpio3 25 0>; /* GPIO4_25 */
> > status = "okay";
> >
> > pmic: mc13892@0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,mc13892";
> > spi-max-frequency = <6000000>;
> > reg = <0>;
> > mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
> >
> > regulators {
> > compatible = "fsl,mc13892-regulator";
> >
> > sw1reg: mc13892_sw1 {
> > regulator-min-uV = <600000>;
> > regulator-max-uV = <1375000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > sw2reg: mc13892_sw2 {
> > regulator-min-uV = <900000>;
> > regulator-max-uV = <1850000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > ......
> > };
> >
> > leds {
> > ......
> > };
> >
> > buttons {
> > ......
> > };
> > };
> >
> > flash: at45db321d@1 {
> > ......
> > };
> > };
> >
> > > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > > "fsl,mc13892-regulators").
> > >
> > > It's not immediately obvious to me that having a binding for the
> > > regulators separately makes sense, it's not a usefully distinct device.
> > >
> > Fair point. Actually, I also hate to have the finding of node
> > 'regulators' plugged into regulator driver. What about following
> > change to address Grant's concern on global device tree search?
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 8fe132d..29dcf90 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
>
> of_find_node_by_name() doesn't work that way. The first argument is a
> starting point, but it doesn't restrict the search to children of a
> node.
>
> for_each_child_of_node() is what you want to use when iterating over
> the children which unfortunately changes the structure of this
> function.
>
The dev->parent->of_node is meant to point to node 'pmic: mc13892@0'.
And the intention here is not to iterate over the children, but to
start a search from a reasonable point rather than the top root node.
--
Regards,
Shawn
^ permalink raw reply
* Re: 3.0.4 kernel oops in i2c ?
From: Hermann Lauer @ 2011-10-24 14:43 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20111014144345.GB5070@lemon.iwr.uni-heidelberg.de>
On Mon, Oct 24, 2011 at 03:26:56PM +0200, Josip Rodin wrote:
> On Fri, Oct 14, 2011 at 04:43:45PM +0200, Hermann Lauer wrote:
> > when starting 3.0.4 on a V880 a non fatal oops happens when loading
> > i2c stuff. Proably there is a problem with i2c on the machine,
> > as the rsc "env" cmd shows "E880_FSP: ERROR getting FP stats ---> 9"
> > errors. An old 2.6.26-2-sparc64-smp (Debian 2.6.26-26lenny2) kernel
> > produces no oops.
>
> Can you try the stable Debian 2.6.32 kernel at least?
>
> Anything that helps you reduce the amount of git bisect...
2.6.32-5-sparc64-smp (Debian 2.6.32-38) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Oct 3 09:43:44 UTC 2011
is starting fine without oops. Thanks for caring,
Hermann
>
> --
> 2. That which causes joy or happiness.
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: Hermann.Lauer@iwr.uni-heidelberg.de
^ permalink raw reply
* [PATCH 05/10] user namespace: clamp down users of cap_raised
From: Serge E. Hallyn @ 2011-10-24 14:43 UTC (permalink / raw)
To: David Howells
Cc: Andrew G. Morgan, linux-kernel, ebiederm, akpm, oleg, richard,
mikevs, segoon, gregkh, eparis, Serge E. Hallyn
In-Reply-To: <14652.1319014868@redhat.com>
A few modules are using cap_raised(current_cap(), cap) to authorize
actions. This means that tasks which are privileged in non-initial
user namespaces will be deemed privileged. The privilege should only
be granted if the task is in the initial user namespace.
Switching the calls to capable() would change the behavior - it would
cause the LSM capable hooks to be called, and set PF_SUPERPRIV if
the capability was used. So instead, put in an explicit check and
refuse privilege if the caller is not in init_user_ns.
Changelog:
Oct 23: Use a nice macro to make the code shorter and easier to read,
per advice from Andrew Morgan and David Howells.
Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Andrew Morgan <morgan@kernel.org>
Cc: Vasiliy Kulikov <segoon@openwall.com>
Cc: David Howells <dhowells@redhat.com>
---
drivers/block/drbd/drbd_nl.c | 2 +-
drivers/md/dm-log-userspace-transfer.c | 2 +-
drivers/staging/pohmelfs/config.c | 2 +-
drivers/video/uvesafb.c | 2 +-
include/linux/cred.h | 2 ++
5 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index 0feab26..f799b15 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -2297,7 +2297,7 @@ static void drbd_connector_callback(struct cn_msg *req, struct netlink_skb_parms
return;
}
- if (!cap_raised(current_cap(), CAP_SYS_ADMIN)) {
+ if (!IN_ROOT_USER_NS() || !cap_raised(current_cap(), CAP_SYS_ADMIN)) {
retcode = ERR_PERM;
goto fail;
}
diff --git a/drivers/md/dm-log-userspace-transfer.c b/drivers/md/dm-log-userspace-transfer.c
index 1f23e04..126a79b 100644
--- a/drivers/md/dm-log-userspace-transfer.c
+++ b/drivers/md/dm-log-userspace-transfer.c
@@ -134,7 +134,7 @@ static void cn_ulog_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp)
{
struct dm_ulog_request *tfr = (struct dm_ulog_request *)(msg + 1);
- if (!cap_raised(current_cap(), CAP_SYS_ADMIN))
+ if (!IN_ROOT_USER_NS() || !cap_raised(current_cap(), CAP_SYS_ADMIN))
return;
spin_lock(&receiving_list_lock);
diff --git a/drivers/staging/pohmelfs/config.c b/drivers/staging/pohmelfs/config.c
index b6c42cb..327c047 100644
--- a/drivers/staging/pohmelfs/config.c
+++ b/drivers/staging/pohmelfs/config.c
@@ -525,7 +525,7 @@ static void pohmelfs_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *n
{
int err;
- if (!cap_raised(current_cap(), CAP_SYS_ADMIN))
+ if (!IN_ROOT_USER_NS() || !cap_raised(current_cap(), CAP_SYS_ADMIN))
return;
switch (msg->flags) {
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 7f8472c..94e0e9d 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -73,7 +73,7 @@ static void uvesafb_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *ns
struct uvesafb_task *utask;
struct uvesafb_ktask *task;
- if (!cap_raised(current_cap(), CAP_SYS_ADMIN))
+ if (!IN_ROOT_USER_NS() || !cap_raised(current_cap(), CAP_SYS_ADMIN))
return;
if (msg->seq >= UVESAFB_TASKS_MAX)
diff --git a/include/linux/cred.h b/include/linux/cred.h
index 4030896..2f75da7 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -359,9 +359,11 @@ static inline void put_cred(const struct cred *_cred)
#ifdef CONFIG_USER_NS
#define current_user_ns() (current_cred_xxx(user_ns))
+#define IN_ROOT_USER_NS() (current_user_ns() == &init_user_ns)
#else
extern struct user_namespace init_user_ns;
#define current_user_ns() (&init_user_ns)
+#define IN_ROOT_USER_NS() (1)
#endif
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Rob Herring @ 2011-10-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre@atmel.com>
On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
>
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
>
This comment is out of date for serial.
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> V3:
> - additional clock lookup for device tree handling
> - devices disabled in dtsi file so that only useful devices are
> enabled in dts files
>
> V2: foundation for AT91SAM generic support
> - device tree focused board file
> - inclusion of USART DT support
> - early USART and NAND still using platform data
>
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Rob
^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Rob Herring @ 2011-10-24 14:44 UTC (permalink / raw)
To: Nicolas Ferre
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
>
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
>
This comment is out of date for serial.
> Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> ---
> V3:
> - additional clock lookup for device tree handling
> - devices disabled in dtsi file so that only useful devices are
> enabled in dts files
>
> V2: foundation for AT91SAM generic support
> - device tree focused board file
> - inclusion of USART DT support
> - early USART and NAND still using platform data
>
Reviewed-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Rob
^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Rob Herring @ 2011-10-24 14:44 UTC (permalink / raw)
To: Nicolas Ferre
Cc: grant.likely, linux-kernel, linux-arm-kernel, devicetree-discuss,
plagnioj
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre@atmel.com>
On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
>
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
>
This comment is out of date for serial.
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> V3:
> - additional clock lookup for device tree handling
> - devices disabled in dtsi file so that only useful devices are
> enabled in dts files
>
> V2: foundation for AT91SAM generic support
> - device tree focused board file
> - inclusion of USART DT support
> - early USART and NAND still using platform data
>
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Rob
^ permalink raw reply
* Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
From: Bob Breuer @ 2011-10-24 14:45 UTC (permalink / raw)
To: Kai Tietz
Cc: xunxun, Richard Henderson, qemu-devel, Mark Cave-Ayland,
gcc@gcc.gnu.org
In-Reply-To: <CAEwic4Zey2f6fzSOAiGtyxuBnN2zSPwQCcDdTDdL8-DOiqC2GQ@mail.gmail.com>
Kai Tietz wrote:
> Hi,
>
> For trunk-version I have a tentative patch for this issue. On 4.6.x
> and older branches this doesn't work, as here we can't differenciate
> that easy between ms- and sysv-abi.
>
> But could somebody give this patch a try?
>
> Regards,
> Kai
>
> ChangeLog
>
> * config/i386/i386.c (ix86_frame_pointer_required): Enforce use of
> frame-pointer for 32-bit ms-abi, if setjmp is used.
>
> Index: i386.c
> ===================================================================
> --- i386.c (revision 180099)
> +++ i386.c (working copy)
> @@ -8391,6 +8391,10 @@
> if (SUBTARGET_FRAME_POINTER_REQUIRED)
> return true;
>
> + /* For older 32-bit runtimes setjmp requires valid frame-pointer. */
> + if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
> + return true;
> +
> /* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER
> turns off the frame pointer by default. Turn it back on now if
> we've not got a leaf function. */
>
For a gcc 4.7 snapshot, this does fix the longjmp problem that I
encountered. So aside from specifying -fno-omit-frame-pointer for
affected files, what can be done for 4.6?
Bob
^ permalink raw reply
* [PATCH v5 0/7] arm: pmu: support pmu/perf on OMAP4
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patches support pmu irq routed from CTI, such as implemented
on OMAP4:
- introduce some CTI helpers and registers' definition
- introduce .enable_irq and .disable_irq into platform_data,
so perf irq handler can handle irq correctly if it is routed
from CTI on OMAP4
- configure CTI on OMAP4 so that perf can work on OMAP4
The patches have been tested Ok on Pandaboard, and 'perf' does work
after applying them.
v5:
- build pmu device from hwmod
- support runtime pm
v4:
- some minor fix(add __iomem, comments, checkpatch warning...)
v3:
- fix typo of patch 2/3 title, pointed by Will
- move cti addresses to plat/omap44xx.h, suggested by
Santosh Shilimkar
v2:
- move cti related code out of perf_event.c
- introduce .enable_irq and .disable_irq into platform_data
as suggested by Will.
v1:
- rebase the patch set against 2.6.38-rc6-next-20110301, fix
conflicts, which is pointed out by Will Deacon
arch/arm/include/asm/cti.h | 179 ++++++++++++++++++++++++++++
arch/arm/include/asm/pmu.h | 15 ++-
arch/arm/kernel/perf_event.c | 20 +++-
arch/arm/kernel/pmu.c | 12 ++-
arch/arm/mach-omap2/devices.c | 126 +++++++++++++++++++-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++
arch/arm/plat-omap/include/plat/omap44xx.h | 3 +
7 files changed, 367 insertions(+), 14 deletions(-)
thanks,
--
Lei Ming
^ permalink raw reply
* [PATCH v5 1/7] arm: introduce cross trigger interface helpers
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
OMAP4 uses cross trigger interface(CTI) to route
performance monitor irq to GIC, so introduce cti
helpers to make access for cti easily.
Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/include/asm/cti.h | 179 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/cti.h
diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
new file mode 100644
index 0000000..a0ada3e
--- /dev/null
+++ b/arch/arm/include/asm/cti.h
@@ -0,0 +1,179 @@
+#ifndef __ASMARM_CTI_H
+#define __ASMARM_CTI_H
+
+#include <asm/io.h>
+
+/* The registers' definition is from section 3.2 of
+ * Embedded Cross Trigger Revision: r0p0
+ */
+#define CTICONTROL 0x000
+#define CTISTATUS 0x004
+#define CTILOCK 0x008
+#define CTIPROTECTION 0x00C
+#define CTIINTACK 0x010
+#define CTIAPPSET 0x014
+#define CTIAPPCLEAR 0x018
+#define CTIAPPPULSE 0x01c
+#define CTIINEN 0x020
+#define CTIOUTEN 0x0A0
+#define CTITRIGINSTATUS 0x130
+#define CTITRIGOUTSTATUS 0x134
+#define CTICHINSTATUS 0x138
+#define CTICHOUTSTATUS 0x13c
+#define CTIPERIPHID0 0xFE0
+#define CTIPERIPHID1 0xFE4
+#define CTIPERIPHID2 0xFE8
+#define CTIPERIPHID3 0xFEC
+#define CTIPCELLID0 0xFF0
+#define CTIPCELLID1 0xFF4
+#define CTIPCELLID2 0xFF8
+#define CTIPCELLID3 0xFFC
+
+/* The below are from section 3.6.4 of
+ * CoreSight v1.0 Architecture Specification
+ */
+#define LOCKACCESS 0xFB0
+#define LOCKSTATUS 0xFB4
+
+/* write this value to LOCKACCESS will unlock the module, and
+ * other value will lock the module
+ */
+#define LOCKCODE 0xC5ACCE55
+
+/**
+ * struct cti - cross trigger interface struct
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out_for_irq: triger out number which will cause
+ * the @irq happen
+ *
+ * cti struct used to operate cti registers.
+ */
+struct cti {
+ void __iomem *base;
+ int irq;
+ int trig_out_for_irq;
+};
+
+/**
+ * cti_init - initialize the cti instance
+ * @cti: cti instance
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out: triger out number which will cause
+ * the @irq happen
+ *
+ * called by machine code to pass the board dependent
+ * @base, @irq and @trig_out to cti.
+ */
+static inline void cti_init(struct cti *cti,
+ void __iomem *base, int irq, int trig_out)
+{
+ cti->base = base;
+ cti->irq = irq;
+ cti->trig_out_for_irq = trig_out;
+}
+
+/**
+ * cti_map_trigger - use the @chan to map @trig_in to @trig_out
+ * @cti: cti instance
+ * @trig_in: trigger in number
+ * @trig_out: trigger out number
+ * @channel: channel number
+ *
+ * This function maps one trigger in of @trig_in to one trigger
+ * out of @trig_out using the channel @chan.
+ */
+static inline void cti_map_trigger(struct cti *cti,
+ int trig_in, int trig_out, int chan)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINEN + trig_in * 4);
+ val |= BIT(chan);
+ __raw_writel(val, base + CTIINEN + trig_in * 4);
+
+ val = __raw_readl(base + CTIOUTEN + trig_out * 4);
+ val |= BIT(chan);
+ __raw_writel(val, base + CTIOUTEN + trig_out * 4);
+}
+
+/**
+ * cti_enable - enable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_enable(struct cti *cti)
+{
+ __raw_writel(0x1, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_disable - disable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_disable(struct cti *cti)
+{
+ __raw_writel(0, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_irq_ack - clear the cti irq
+ * @cti: cti instance
+ *
+ * clear the cti irq
+ */
+static inline void cti_irq_ack(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINTACK);
+ val |= BIT(cti->trig_out_for_irq);
+ __raw_writel(val, base + CTIINTACK);
+}
+
+/**
+ * cti_unlock - unlock cti module
+ * @cti: cti instance
+ *
+ * unlock the cti module, or else any writes to the cti
+ * module is not allowed.
+ */
+static inline void cti_unlock(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (val & 1) {
+ val = LOCKCODE;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+
+/**
+ * cti_lock - lock cti module
+ * @cti: cti instance
+ *
+ * lock the cti module, so any writes to the cti
+ * module will be not allowed.
+ */
+static inline void cti_lock(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (!(val & 1)) {
+ val = ~LOCKCODE;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+#endif
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 2/7] arm: pmu: allow platform specific irq enable/disable handling
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.
This patch is for support of pmu irq routed from CTI on omap4.
Acked-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/include/asm/pmu.h | 15 ++++++++++++---
arch/arm/kernel/perf_event.c | 15 ++++++++++++---
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index b7e82c4..3af5e39 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -22,13 +22,22 @@ enum arm_pmu_type {
/*
* struct arm_pmu_platdata - ARM PMU platform data
*
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ * interrupt and passed the address of the low level handler,
+ * and can be used to implement any platform specific handling
+ * before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ * request_irq and be used to handle some platform specific
+ * irq enablement
+ * @disable_irq: an optional handler which will be called before
+ * free_irq and be used to handle some platform specific
+ * irq disablement
*/
struct arm_pmu_platdata {
irqreturn_t (*handle_irq)(int irq, void *dev,
irq_handler_t pmu_handler);
+ void (*enable_irq)(int irq);
+ void (*disable_irq)(int irq);
};
#ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 53c9c26..f367780 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -426,14 +426,18 @@ armpmu_reserve_hardware(void)
pr_warning("unable to request IRQ%d for ARM perf "
"counters\n", irq);
break;
- }
+ } else if (plat && plat->enable_irq)
+ plat->enable_irq(irq);
}
if (err) {
for (i = i - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat && plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, NULL);
+ }
}
release_pmu(ARM_PMU_DEVICE_CPU);
pmu_device = NULL;
@@ -446,11 +450,16 @@ static void
armpmu_release_hardware(void)
{
int i, irq;
+ struct arm_pmu_platdata *plat =
+ dev_get_platdata(&pmu_device->dev);
for (i = pmu_device->num_resources - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat && plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, NULL);
+ }
}
armpmu->stop();
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 3/7] arm: perf: support device with other non-irq resources
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
omap4 may create device via hwmod, which can create resources
automatically, so may include some non-irq resources.
This patch supports device with other non-irq resources.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/kernel/perf_event.c | 5 +++--
arch/arm/kernel/pmu.c | 12 ++++++++++--
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index f367780..d91dba2 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -19,6 +19,7 @@
#include <linux/platform_device.h>
#include <linux/spinlock.h>
#include <linux/uaccess.h>
+#include <linux/cpumask.h>
#include <asm/cputype.h>
#include <asm/irq.h>
@@ -414,7 +415,7 @@ armpmu_reserve_hardware(void)
return -ENODEV;
}
- for (i = 0; i < pmu_device->num_resources; ++i) {
+ for (i = 0; i < nr_cpu_ids; ++i) {
irq = platform_get_irq(pmu_device, i);
if (irq < 0)
continue;
@@ -453,7 +454,7 @@ armpmu_release_hardware(void)
struct arm_pmu_platdata *plat =
dev_get_platdata(&pmu_device->dev);
- for (i = pmu_device->num_resources - 1; i >= 0; --i) {
+ for (i = nr_cpu_ids - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
if (irq >= 0) {
if (plat && plat->disable_irq)
diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
index c53474f..0e9c908 100644
--- a/arch/arm/kernel/pmu.c
+++ b/arch/arm/kernel/pmu.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/cpumask.h>
#include <asm/pmu.h>
@@ -172,8 +173,15 @@ init_cpu_pmu(void)
if (irqs == 1 && !irq_can_set_affinity(platform_get_irq(pdev, 0)))
return 0;
- for (i = 0; i < irqs; ++i) {
- err = set_irq_affinity(platform_get_irq(pdev, i), i);
+ for (i = 0; i < nr_cpu_ids; ++i) {
+ int irq;
+
+ irq = platform_get_irq(pdev, i);
+
+ if (irq < 0)
+ continue;
+
+ err = set_irq_affinity(irq, i);
if (err)
break;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
So that access to cross trigger interface can be allowed, which
will be introduce in later patches.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 393afac..c7289a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+static struct omap_hwmod_class omap44xx_emu_hwmod_class = {
+ .name = "emu",
+};
+
+static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
+ { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+/*emu hwmod*/
+static struct omap_hwmod omap44xx_emu_hwmod = {
+ .name = "emu",
+ .class = &omap44xx_emu_hwmod_class,
+ .clkdm_name = "emu_sys_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .mpu_irqs = omap44xx_emu_irqs,
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5422,6 +5446,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
+ /*emu class*/
+ &omap44xx_emu_hwmod,
NULL,
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 5/7] arm: omap4: create pmu device via hwmod
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:
emu, l3_instr, l3_main_3
so build the arm-pmu device via the three hwmods.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 61 ++++++++++++++++++++++++++++++++++++++---
1 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0f8e0eb..6e16274 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -384,14 +384,67 @@ static struct platform_device omap_pmu_device = {
.num_resources = 1,
};
-static void omap_init_pmu(void)
+static struct arm_pmu_platdata omap4_pmu_data;
+static struct omap_device_pm_latency omap_pmu_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static struct platform_device* __init omap4_init_pmu(void)
{
- if (cpu_is_omap24xx())
+ int id = -1;
+ const char *hw;
+ struct platform_device *pd;
+ struct omap_hwmod* oh[3];
+ char *dev_name = "arm-pmu";
+
+ hw = "l3_main_3";
+ oh[0] = omap_hwmod_lookup(hw);
+ if (!oh[0]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+ hw = "l3_instr";
+ oh[1] = omap_hwmod_lookup(hw);
+ if (!oh[1]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+ hw = "emu";
+ oh[2] = omap_hwmod_lookup(hw);
+ if (!oh[2]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+
+ pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
+ sizeof(omap4_pmu_data),
+ omap_pmu_latency,
+ ARRAY_SIZE(omap_pmu_latency), 0);
+ WARN(IS_ERR(pd), "Can't build omap_device for %s.\n",
+ dev_name);
+ return pd;
+}
+static void __init omap_init_pmu(void)
+{
+ if (cpu_is_omap24xx()) {
omap_pmu_device.resource = &omap2_pmu_resource;
- else if (cpu_is_omap34xx())
+ } else if (cpu_is_omap34xx()) {
omap_pmu_device.resource = &omap3_pmu_resource;
- else
+ } else if (cpu_is_omap44xx()) {
+ struct platform_device *pd;
+
+ pd = omap4_init_pmu();
+ if (!pd)
+ return;
+ omap_device_enable(pd);
+ return;
+ } else {
return;
+ }
platform_device_register(&omap_pmu_device);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 6/7] arm: omap4: support pmu
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
about "Oprofile on Pandaboard / Omap4" on pandaboard at googlegroups.com.
Acked-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Woodruff Richard <r-woodruff2@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 60 +++++++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/omap44xx.h | 3 +
2 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 6e16274..bc791e0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -23,6 +23,7 @@
#include <asm/mach-types.h>
#include <asm/mach/map.h>
#include <asm/pmu.h>
+#include <asm/cti.h>
#include <plat/tc.h>
#include <plat/board.h>
@@ -393,6 +394,57 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
},
};
+static struct cti omap4_cti[2];
+
+static void omap4_enable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_enable(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_enable(&omap4_cti[1]);
+}
+
+static void omap4_disable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_disable(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_disable(&omap4_cti[1]);
+}
+
+static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_irq_ack(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_irq_ack(&omap4_cti[1]);
+
+ return handler(irq, dev);
+}
+
+static void __init omap4_configure_pmu_irq(void)
+{
+ void __iomem *base0;
+ void __iomem *base1;
+
+ base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+ base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+ if (!base0 && !base1) {
+ pr_err("ioremap for OMAP4 CTI failed\n");
+ return;
+ }
+
+ /*configure CTI0 for pmu irq routing*/
+ cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
+ cti_unlock(&omap4_cti[0]);
+ cti_map_trigger(&omap4_cti[0], 1, 6, 2);
+
+ /*configure CTI1 for pmu irq routing*/
+ cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
+ cti_unlock(&omap4_cti[1]);
+ cti_map_trigger(&omap4_cti[1], 1, 6, 2);
+}
+
static struct platform_device* __init omap4_init_pmu(void)
{
int id = -1;
@@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
return NULL;
}
+ omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ omap4_pmu_data.enable_irq = omap4_enable_cti;
+ omap4_pmu_data.disable_irq = omap4_disable_cti;
+
pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
sizeof(omap4_pmu_data),
omap_pmu_latency,
@@ -440,7 +496,9 @@ static void __init omap_init_pmu(void)
pd = omap4_init_pmu();
if (!pd)
return;
- omap_device_enable(pd);
+
+ omap_device_enable(&od->pdev);
+ omap4_configure_pmu_irq();
return;
} else {
return;
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..4637980 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -57,5 +57,8 @@
#define OMAP44XX_HSUSB_OHCI_BASE (L4_44XX_BASE + 0x64800)
#define OMAP44XX_HSUSB_EHCI_BASE (L4_44XX_BASE + 0x64C00)
+#define OMAP44XX_CTI0_BASE 0x54148000
+#define OMAP44XX_CTI1_BASE 0x54149000
+
#endif /* __ASM_ARCH_OMAP44XX_H */
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 7/7] arm: omap4: pmu: support runtime pm
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index bc791e0..ab4de0d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/pm_runtime.h>
#include <mach/hardware.h>
#include <mach/irqs.h>
@@ -395,9 +396,11 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
};
static struct cti omap4_cti[2];
+static struct platform_device *pmu_dev;
static void omap4_enable_cti(int irq)
{
+ pm_runtime_get_sync(&pmu_dev->dev);
if (irq == OMAP44XX_IRQ_CTI0)
cti_enable(&omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
@@ -410,6 +413,7 @@ static void omap4_disable_cti(int irq)
cti_disable(&omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
cti_disable(&omap4_cti[1]);
+ pm_runtime_put(&pmu_dev->dev);
}
static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
@@ -497,8 +501,11 @@ static void __init omap_init_pmu(void)
if (!pd)
return;
- omap_device_enable(&od->pdev);
+ pmu_dev= pd;
+ pm_runtime_enable(&pd->dev);
+ pm_runtime_get_sync(&pd->dev);
omap4_configure_pmu_irq();
+ pm_runtime_put(&pd->dev);
return;
} else {
return;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic
From: Oleg Nesterov @ 2011-10-24 14:41 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli
Cc: Srikar Dronamraju, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
Linux-mm, Arnaldo Carvalho de Melo, Linus Torvalds,
Jonathan Corbet, Masami Hiramatsu, Hugh Dickins,
Christoph Hellwig, Thomas Gleixner, Andi Kleen, Andrew Morton,
Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111022072030.GB24475@in.ibm.com>
On 10/22, Ananth N Mavinakayanahalli wrote:
>
> On Wed, Oct 19, 2011 at 11:53:44PM +0200, Oleg Nesterov wrote:
> > Finally, add UTASK_SSTEP_TRAPPED state/code to handle the case when
> > xol insn itself triggers the signal.
> >
> > In this case we should restart the original insn even if the task is
> > already SIGKILL'ed (say, the coredump should report the correct ip).
> > This is even more important if the task has a handler for SIGSEGV/etc,
> > The _same_ instruction should be repeated again after return from the
> > signal handler, and SSTEP can never finish in this case.
>
> Oleg,
>
> Not sure I understand this completely...
I hope you do not think I do ;)
> When you say 'correct ip' you mean the original vaddr where we now have
> a uprobe breakpoint and not the xol copy, right?
Yes,
> Coredump needs to report the correct ip, but should it also not report
> correctly the instruction that caused the signal? Ergo, shouldn't we
> put the original instruction back at the uprobed vaddr?
OK, now I see what you mean. I was confused by the "restore the original
instruction before _restart_" suggestion.
Agreed! it would be nice to "hide" these int3's if we dump the core, but
I think this is a bit off-topic. It makes sense to do this in any case,
even if the core-dumping was triggered by another thread/insn. It makes
sense to remove all int3's, not only at regs->ip location. But how can
we do this? This is nontrivial.
And. Even worse. Suppose that you do "gdb probed_application". Now you
see int3's in the disassemble output. What can we do?
I think we can do nothing, at least currently. This just reflects the
fact that uprobe connects to inode, not to process/mm/etc.
What do you think?
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v5 0/7] arm: pmu: support pmu/perf on OMAP4
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony; +Cc: linux-arm-kernel, linux-omap, khilman, paul
Hi,
This patches support pmu irq routed from CTI, such as implemented
on OMAP4:
- introduce some CTI helpers and registers' definition
- introduce .enable_irq and .disable_irq into platform_data,
so perf irq handler can handle irq correctly if it is routed
from CTI on OMAP4
- configure CTI on OMAP4 so that perf can work on OMAP4
The patches have been tested Ok on Pandaboard, and 'perf' does work
after applying them.
v5:
- build pmu device from hwmod
- support runtime pm
v4:
- some minor fix(add __iomem, comments, checkpatch warning...)
v3:
- fix typo of patch 2/3 title, pointed by Will
- move cti addresses to plat/omap44xx.h, suggested by
Santosh Shilimkar
v2:
- move cti related code out of perf_event.c
- introduce .enable_irq and .disable_irq into platform_data
as suggested by Will.
v1:
- rebase the patch set against 2.6.38-rc6-next-20110301, fix
conflicts, which is pointed out by Will Deacon
arch/arm/include/asm/cti.h | 179 ++++++++++++++++++++++++++++
arch/arm/include/asm/pmu.h | 15 ++-
arch/arm/kernel/perf_event.c | 20 +++-
arch/arm/kernel/pmu.c | 12 ++-
arch/arm/mach-omap2/devices.c | 126 +++++++++++++++++++-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++
arch/arm/plat-omap/include/plat/omap44xx.h | 3 +
7 files changed, 367 insertions(+), 14 deletions(-)
thanks,
--
Lei Ming
^ permalink raw reply
* Re: [PATCH 00/36] Staging: cx25821: Clean up patch series
From: Leonid V. Fedorenchik @ 2011-10-24 14:46 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Greg KH, Namhyung Kim, Palash Bandyopadhyay, Joe Perches,
Ilia Mirkin, Youquan Song, devel, linux-kernel
In-Reply-To: <4EA47CF8.2090504@redhat.com>
On Sun, 23 Oct 2011 22:45:44 +0200
Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em 23-10-2011 17:24, Leonid V. Fedorenchik escreveu:
> >
> > Thank you. Should I send my future patches for this driver directly to you?
>
> The better is if you could send them to linux-media@vger.kernel.org. Patchwork
> will catch them and put on my queue automatically.
OK, will do. :)
>
> Thanks,
> Mauro
Leonid V. Fedorenchik
^ permalink raw reply
* [PATCH v5 1/7] arm: introduce cross trigger interface helpers
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
OMAP4 uses cross trigger interface(CTI) to route
performance monitor irq to GIC, so introduce cti
helpers to make access for cti easily.
Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/include/asm/cti.h | 179 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/cti.h
diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
new file mode 100644
index 0000000..a0ada3e
--- /dev/null
+++ b/arch/arm/include/asm/cti.h
@@ -0,0 +1,179 @@
+#ifndef __ASMARM_CTI_H
+#define __ASMARM_CTI_H
+
+#include <asm/io.h>
+
+/* The registers' definition is from section 3.2 of
+ * Embedded Cross Trigger Revision: r0p0
+ */
+#define CTICONTROL 0x000
+#define CTISTATUS 0x004
+#define CTILOCK 0x008
+#define CTIPROTECTION 0x00C
+#define CTIINTACK 0x010
+#define CTIAPPSET 0x014
+#define CTIAPPCLEAR 0x018
+#define CTIAPPPULSE 0x01c
+#define CTIINEN 0x020
+#define CTIOUTEN 0x0A0
+#define CTITRIGINSTATUS 0x130
+#define CTITRIGOUTSTATUS 0x134
+#define CTICHINSTATUS 0x138
+#define CTICHOUTSTATUS 0x13c
+#define CTIPERIPHID0 0xFE0
+#define CTIPERIPHID1 0xFE4
+#define CTIPERIPHID2 0xFE8
+#define CTIPERIPHID3 0xFEC
+#define CTIPCELLID0 0xFF0
+#define CTIPCELLID1 0xFF4
+#define CTIPCELLID2 0xFF8
+#define CTIPCELLID3 0xFFC
+
+/* The below are from section 3.6.4 of
+ * CoreSight v1.0 Architecture Specification
+ */
+#define LOCKACCESS 0xFB0
+#define LOCKSTATUS 0xFB4
+
+/* write this value to LOCKACCESS will unlock the module, and
+ * other value will lock the module
+ */
+#define LOCKCODE 0xC5ACCE55
+
+/**
+ * struct cti - cross trigger interface struct
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out_for_irq: triger out number which will cause
+ * the @irq happen
+ *
+ * cti struct used to operate cti registers.
+ */
+struct cti {
+ void __iomem *base;
+ int irq;
+ int trig_out_for_irq;
+};
+
+/**
+ * cti_init - initialize the cti instance
+ * @cti: cti instance
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out: triger out number which will cause
+ * the @irq happen
+ *
+ * called by machine code to pass the board dependent
+ * @base, @irq and @trig_out to cti.
+ */
+static inline void cti_init(struct cti *cti,
+ void __iomem *base, int irq, int trig_out)
+{
+ cti->base = base;
+ cti->irq = irq;
+ cti->trig_out_for_irq = trig_out;
+}
+
+/**
+ * cti_map_trigger - use the @chan to map @trig_in to @trig_out
+ * @cti: cti instance
+ * @trig_in: trigger in number
+ * @trig_out: trigger out number
+ * @channel: channel number
+ *
+ * This function maps one trigger in of @trig_in to one trigger
+ * out of @trig_out using the channel @chan.
+ */
+static inline void cti_map_trigger(struct cti *cti,
+ int trig_in, int trig_out, int chan)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINEN + trig_in * 4);
+ val |= BIT(chan);
+ __raw_writel(val, base + CTIINEN + trig_in * 4);
+
+ val = __raw_readl(base + CTIOUTEN + trig_out * 4);
+ val |= BIT(chan);
+ __raw_writel(val, base + CTIOUTEN + trig_out * 4);
+}
+
+/**
+ * cti_enable - enable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_enable(struct cti *cti)
+{
+ __raw_writel(0x1, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_disable - disable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_disable(struct cti *cti)
+{
+ __raw_writel(0, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_irq_ack - clear the cti irq
+ * @cti: cti instance
+ *
+ * clear the cti irq
+ */
+static inline void cti_irq_ack(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINTACK);
+ val |= BIT(cti->trig_out_for_irq);
+ __raw_writel(val, base + CTIINTACK);
+}
+
+/**
+ * cti_unlock - unlock cti module
+ * @cti: cti instance
+ *
+ * unlock the cti module, or else any writes to the cti
+ * module is not allowed.
+ */
+static inline void cti_unlock(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (val & 1) {
+ val = LOCKCODE;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+
+/**
+ * cti_lock - lock cti module
+ * @cti: cti instance
+ *
+ * lock the cti module, so any writes to the cti
+ * module will be not allowed.
+ */
+static inline void cti_lock(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (!(val & 1)) {
+ val = ~LOCKCODE;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+#endif
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic
From: Oleg Nesterov @ 2011-10-24 14:41 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli
Cc: Srikar Dronamraju, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
Linux-mm, Arnaldo Carvalho de Melo, Linus Torvalds,
Jonathan Corbet, Masami Hiramatsu, Hugh Dickins,
Christoph Hellwig, Thomas Gleixner, Andi Kleen, Andrew Morton,
Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111022072030.GB24475@in.ibm.com>
On 10/22, Ananth N Mavinakayanahalli wrote:
>
> On Wed, Oct 19, 2011 at 11:53:44PM +0200, Oleg Nesterov wrote:
> > Finally, add UTASK_SSTEP_TRAPPED state/code to handle the case when
> > xol insn itself triggers the signal.
> >
> > In this case we should restart the original insn even if the task is
> > already SIGKILL'ed (say, the coredump should report the correct ip).
> > This is even more important if the task has a handler for SIGSEGV/etc,
> > The _same_ instruction should be repeated again after return from the
> > signal handler, and SSTEP can never finish in this case.
>
> Oleg,
>
> Not sure I understand this completely...
I hope you do not think I do ;)
> When you say 'correct ip' you mean the original vaddr where we now have
> a uprobe breakpoint and not the xol copy, right?
Yes,
> Coredump needs to report the correct ip, but should it also not report
> correctly the instruction that caused the signal? Ergo, shouldn't we
> put the original instruction back at the uprobed vaddr?
OK, now I see what you mean. I was confused by the "restore the original
instruction before _restart_" suggestion.
Agreed! it would be nice to "hide" these int3's if we dump the core, but
I think this is a bit off-topic. It makes sense to do this in any case,
even if the core-dumping was triggered by another thread/insn. It makes
sense to remove all int3's, not only at regs->ip location. But how can
we do this? This is nontrivial.
And. Even worse. Suppose that you do "gdb probed_application". Now you
see int3's in the disassemble output. What can we do?
I think we can do nothing, at least currently. This just reflects the
fact that uprobe connects to inode, not to process/mm/etc.
What do you think?
Oleg.
^ permalink raw reply
* [PATCH v5 2/7] arm: pmu: allow platform specific irq enable/disable handling
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.
This patch is for support of pmu irq routed from CTI on omap4.
Acked-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/include/asm/pmu.h | 15 ++++++++++++---
arch/arm/kernel/perf_event.c | 15 ++++++++++++---
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index b7e82c4..3af5e39 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -22,13 +22,22 @@ enum arm_pmu_type {
/*
* struct arm_pmu_platdata - ARM PMU platform data
*
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ * interrupt and passed the address of the low level handler,
+ * and can be used to implement any platform specific handling
+ * before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ * request_irq and be used to handle some platform specific
+ * irq enablement
+ * @disable_irq: an optional handler which will be called before
+ * free_irq and be used to handle some platform specific
+ * irq disablement
*/
struct arm_pmu_platdata {
irqreturn_t (*handle_irq)(int irq, void *dev,
irq_handler_t pmu_handler);
+ void (*enable_irq)(int irq);
+ void (*disable_irq)(int irq);
};
#ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 53c9c26..f367780 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -426,14 +426,18 @@ armpmu_reserve_hardware(void)
pr_warning("unable to request IRQ%d for ARM perf "
"counters\n", irq);
break;
- }
+ } else if (plat && plat->enable_irq)
+ plat->enable_irq(irq);
}
if (err) {
for (i = i - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat && plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, NULL);
+ }
}
release_pmu(ARM_PMU_DEVICE_CPU);
pmu_device = NULL;
@@ -446,11 +450,16 @@ static void
armpmu_release_hardware(void)
{
int i, irq;
+ struct arm_pmu_platdata *plat =
+ dev_get_platdata(&pmu_device->dev);
for (i = pmu_device->num_resources - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat && plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, NULL);
+ }
}
armpmu->stop();
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:47 UTC (permalink / raw)
To: Mark Brown
Cc: patches, tony, devicetree-discuss, Rajendra Nayak, linux-kernel,
Grant Likely, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024134930.GD26033@opensource.wolfsonmicro.com>
On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
>
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
> >
>
> Is that going to do the right thing if you've got a MFD which does
> register each regulator as a separate device?
Based on my understanding, 1:1 is just a special case of N:1. I
failed to see any problem having it work with registering each
regulator as a separate device.
> Might be best to just
> search within dev and get drivers to pass the "real" device in when
> registering the regulator rather than the virtual device.
>
It should also work, but it will also change the API slightly for
non-dt users. I'm not sure it's something we want.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024134930.GD26033@opensource.wolfsonmicro.com>
On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
>
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
> >
>
> Is that going to do the right thing if you've got a MFD which does
> register each regulator as a separate device?
Based on my understanding, 1:1 is just a special case of N:1. I
failed to see any problem having it work with registering each
regulator as a separate device.
> Might be best to just
> search within dev and get drivers to pass the "real" device in when
> registering the regulator rather than the virtual device.
>
It should also work, but it will also change the API slightly for
non-dt users. I'm not sure it's something we want.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v5 3/7] arm: perf: support device with other non-irq resources
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
omap4 may create device via hwmod, which can create resources
automatically, so may include some non-irq resources.
This patch supports device with other non-irq resources.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/kernel/perf_event.c | 5 +++--
arch/arm/kernel/pmu.c | 12 ++++++++++--
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index f367780..d91dba2 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -19,6 +19,7 @@
#include <linux/platform_device.h>
#include <linux/spinlock.h>
#include <linux/uaccess.h>
+#include <linux/cpumask.h>
#include <asm/cputype.h>
#include <asm/irq.h>
@@ -414,7 +415,7 @@ armpmu_reserve_hardware(void)
return -ENODEV;
}
- for (i = 0; i < pmu_device->num_resources; ++i) {
+ for (i = 0; i < nr_cpu_ids; ++i) {
irq = platform_get_irq(pmu_device, i);
if (irq < 0)
continue;
@@ -453,7 +454,7 @@ armpmu_release_hardware(void)
struct arm_pmu_platdata *plat =
dev_get_platdata(&pmu_device->dev);
- for (i = pmu_device->num_resources - 1; i >= 0; --i) {
+ for (i = nr_cpu_ids - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
if (irq >= 0) {
if (plat && plat->disable_irq)
diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
index c53474f..0e9c908 100644
--- a/arch/arm/kernel/pmu.c
+++ b/arch/arm/kernel/pmu.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/cpumask.h>
#include <asm/pmu.h>
@@ -172,8 +173,15 @@ init_cpu_pmu(void)
if (irqs == 1 && !irq_can_set_affinity(platform_get_irq(pdev, 0)))
return 0;
- for (i = 0; i < irqs; ++i) {
- err = set_irq_affinity(platform_get_irq(pdev, i), i);
+ for (i = 0; i < nr_cpu_ids; ++i) {
+ int irq;
+
+ irq = platform_get_irq(pdev, i);
+
+ if (irq < 0)
+ continue;
+
+ err = set_irq_affinity(irq, i);
if (err)
break;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
So that access to cross trigger interface can be allowed, which
will be introduce in later patches.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 393afac..c7289a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+static struct omap_hwmod_class omap44xx_emu_hwmod_class = {
+ .name = "emu",
+};
+
+static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
+ { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+/*emu hwmod*/
+static struct omap_hwmod omap44xx_emu_hwmod = {
+ .name = "emu",
+ .class = &omap44xx_emu_hwmod_class,
+ .clkdm_name = "emu_sys_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .mpu_irqs = omap44xx_emu_irqs,
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5422,6 +5446,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
+ /*emu class*/
+ &omap44xx_emu_hwmod,
NULL,
};
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.