* Re: linux-next: build warning after merge of the final tree
From: Stephen Rothwell @ 2012-12-17 3:34 UTC (permalink / raw)
To: Andrew Morton
Cc: Paul Thompson, linux-kernel, linux-next, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20121217142238.a0840563304419bb345ac25f@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
Hi all,
On Mon, 17 Dec 2012 14:22:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the final tree, today's linux-next build (powerpc allnoconfig)
> produced this warning:
>
> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS && (IRQ_DOMAIN && DEBUG_FS || MAY_HAVE_SPARSE_IRQ))
>
> I don't know what introduced that.
Actually probably caused by commit a1eaa3bc8247 ("Kconfig: fix Irq
Subsystem menu") from the akpm tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH][RFC] mmc, sd: do not read switch, if the host do not support high speed
From: Heiko Schocher @ 2012-12-17 7:27 UTC (permalink / raw)
To: linux-mmc; +Cc: Heiko Schocher, linuxppc-dev, Wolfgang Denk, Dieter Schaffner
If the host controller do not support high speed, do not send the
read switch CMD 6. Same as done in mmc_sd_switch_hs().
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Dieter Schaffner <Dieter.Schaffner@ids.de>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-mmc@vger.kernel.org
---
drivers/mmc/core/sd.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
Found this on a MPC8313 based system with mmc over spi and a Transcend
2 GB SD card running a 2.6.37.6 kernel. Without this patch I get this
when reading the CMD6:
mmc1: starting CMD6 arg 00fffff1 flags 000000b5
mmc1: blksz 64 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.2: mmc_spi: CMD6, resp R1
mmc_spi spi1.2: mmc_spi: read block, 64 bytes
mmc_spi spi1.2: read error ffffff92 (-110)
mmc_spi spi1.2: read status -110
mmc1: req done (CMD6): 0: 00000000 00000000 00000000 00000000
mmc1: 0 bytes transferred: -110
Adding for example a longer timeout for the CMD6 did not helped.
With this patch the transcend card gets detected and can be used
fine. Here the infos from the card, shown in the sysfs:
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/cid
1b534d3030303030100bc3874c00c10b
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/csd
007fff325b5a83baf6dbdfff0e8000b5
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/date
01/2012
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/erase_size
512
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/fwrev
0x0
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/hwrev
0x1
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/manfid
0x00001b
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/name
00000
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/oemid
0x534d
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/preferred_erase_size
4194304
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/scr
0225800000000000
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/serial
0x0bc3874c
-bash-3.2# cat /sys/bus/mmc/devices/mmc0\:0000/type
SD
So the question raises, is this a known bug and/or a valid patch?
Other patches known to help here?
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 49da4df..3142df0 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -268,6 +268,10 @@ static int mmc_read_switch(struct mmc_card *card)
return 0;
}
+ /* no need, if the host do not support high speed */
+ if (!(card->host->caps & MMC_CAP_SD_HIGHSPEED))
+ return 0;
+
err = -EIO;
status = kmalloc(64, GFP_KERNEL);
--
1.7.7.6
^ permalink raw reply related
* Re: [git pull] Please pull powerpc.git next branch
From: Anatolij Gustschin @ 2012-12-17 8:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <1355517897.19932.136.camel@pasglop>
Hi Ben,
On Sat, 15 Dec 2012 07:44:57 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
...
> Overall it's pretty quiet, or rather I've been pretty poor at
> picking things up from patchwork and reviewing them this time
> around and Kumar no better on the FSL side it seems...
Could you please also include some 5xxx patches for v3.8 in your pull
request? I've submitted a pull request for them last week
http://patchwork.ozlabs.org/patch/205138
Thanks,
Anatolij
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2012-12-17 10:06 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <20121217093036.65cb7cef@wker>
On Mon, 2012-12-17 at 09:30 +0100, Anatolij Gustschin wrote:
> > Overall it's pretty quiet, or rather I've been pretty poor at
> > picking things up from patchwork and reviewing them this time
> > around and Kumar no better on the FSL side it seems...
>
> Could you please also include some 5xxx patches for v3.8 in your pull
> request? I've submitted a pull request for them last week
>
> http://patchwork.ozlabs.org/patch/205138
Last week is a bit late :-) However, I think your tree was in -next
before that wasn't it ? In which case it's ok, I can include it tomorrow
and ask Linus to pick it up.
Cheers,
Ben
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Anatolij Gustschin @ 2012-12-17 10:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <1355738785.5397.17.camel@pasglop>
On Mon, 17 Dec 2012 21:06:25 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
...
> Last week is a bit late :-) However, I think your tree was in -next
> before that wasn't it ? In which case it's ok, I can include it tomorrow
> and ask Linus to pick it up.
yes, 5xxx tree was in -next before that.
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch
From: Anton Blanchard @ 2012-12-17 11:33 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: Kumar Gala, paulus, linuxppc-dev
In-Reply-To: <D5CF6D4A-8F60-4853-9F7C-EFE5133CEB33@pobox.com>
Hi Jimi,
> I know this is a little late, but shouldn't these power7 specific
> thingies be in "obj-$(CONFIG_PPC_BOOK3S_64)". The reason I ask is
> that my compiler pukes on "dcbtst" and as I deal with that I wanted
> to point this out.
I guess we could do that. It's a bit strange your assembler is
complaining about the dcbtst instructions since we wrap them with
power4:
.machine push
.machine "power4"
dcbt r0,r4,0b01000
dcbt r0,r7,0b01010
dcbtst r0,r9,0b01000
dcbtst r0,r10,0b01010
eieio
dcbt r0,r8,0b01010 /* GO */
.machine pop
Anton
^ permalink raw reply
* [PATCH] PPC: Add support for CTS-1000 GPIO controlled system poweroff
From: Ben Collins @ 2012-12-17 14:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Vihar Rai, Jack Smith
CTS-1000 is based on P4080. GPIO 27 is used to signal the FPGA to
switch off power, and also associates IRQ 8 with front-panel button
press (which we use to call orderly_poweroff()).
The relevant device-tree looks like this:
gpio0: gpio@130000 {
compatible =3D "fsl,qoriq-gpio";
reg =3D <0x130000 0x1000>;
interrupts =3D <55 2 0 0>;
#gpio-cells =3D <2>;
gpio-controller;
/* Allows powering off the system via GPIO signal. */
gpio-halt@27 {
compatible =3D "sgy,gpio-halt";
gpios =3D <&gpio0 27 0>;
interrupts =3D <8 1 0 0>;
};
};
Because the driver cannot match on sgy,gpio-halt (because the node is =
never
processed through of_platform), it matches on fsl,qoriq-gpio and then
checks child nodes for the matching sgy,gpio-halt. This also ensures =
that
the GPIO controller is detected prior to sgy_cts1000's probe callback,
since that node wont match via of_platform until the controller is
registered.
Also, because the GPIO handler for triggering system poweroff might =
sleep,
the IRQ uses a workqueue to call orderly_poweroff().
As a final note, this driver may be expanded for other features specific =
to
the CTS-1000.
Signed-off-by: Ben Collins <ben.c@servergy.com>
Cc: Jack Smith <jack.s@servergy.com>
Cc: Vihar Rai <vihar.r@servergy.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/Kconfig | 8 ++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/sgy_cts1000.c | 176 =
+++++++++++++++++++++++++++++
3 files changed, 185 insertions(+)
create mode 100644 arch/powerpc/platforms/85xx/sgy_cts1000.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig =
b/arch/powerpc/platforms/85xx/Kconfig
index 02d02a0..651788c 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -245,6 +245,14 @@ config P4080_DS
help
This option enables support for the P4080 DS board
=20
+config SGY_CTS1000
+ tristate "Servergy CTS-1000 support"
+ select GPIOLIB
+ select OF_GPIO
+ depends on P4080_DS
+ help
+ Enable this to support functionality in Servergy's CTS-1000 =
systems.
+
endif # PPC32
=20
config P5020_DS
diff --git a/arch/powerpc/platforms/85xx/Makefile =
b/arch/powerpc/platforms/85xx/Makefile
index 76f679c..9db31dc 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_KSI8560) +=3D ksi8560.o
obj-$(CONFIG_XES_MPC85xx) +=3D xes_mpc85xx.o
obj-$(CONFIG_GE_IMP3A) +=3D ge_imp3a.o
obj-$(CONFIG_PPC_QEMU_E500) +=3D qemu_e500.o
+obj-$(CONFIG_SGY_CTS1000) +=3D sgy_cts1000.o
diff --git a/arch/powerpc/platforms/85xx/sgy_cts1000.c =
b/arch/powerpc/platforms/85xx/sgy_cts1000.c
new file mode 100644
index 0000000..611e92f
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/sgy_cts1000.c
@@ -0,0 +1,176 @@
+/*
+ * Servergy CTS-1000 Setup
+ *
+ * Maintained by Ben Collins <ben.c@servergy.com>
+ *
+ * Copyright 2012 by Servergy, Inc.
+ *
+ * This program is free software; you can redistribute it and/or =
modify it
+ * under the terms of the GNU General Public License as published by =
the
+ * Free Software Foundation; either version 2 of the License, or (at =
your
+ * option) any later version.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/of_gpio.h>
+#include <linux/workqueue.h>
+#include <linux/reboot.h>
+#include <linux/interrupt.h>
+
+#include <asm/machdep.h>
+
+static struct device_node *halt_node;
+
+static struct of_device_id child_match[] =3D {
+ {
+ .compatible =3D "sgy,gpio-halt",
+ },
+ {},
+};
+
+static void gpio_halt_wfn(struct work_struct *work)
+{
+ /* Likely wont return */
+ orderly_poweroff(true);
+}
+static DECLARE_WORK(gpio_halt_wq, gpio_halt_wfn);
+
+static void gpio_halt_cb(void)
+{
+ enum of_gpio_flags flags;
+ int trigger, gpio;
+
+ if (!halt_node)
+ return;
+
+ gpio =3D of_get_gpio_flags(halt_node, 0, &flags);
+
+ if (!gpio_is_valid(gpio))
+ return;
+
+ trigger =3D (flags =3D=3D OF_GPIO_ACTIVE_LOW);
+
+ printk(KERN_INFO "gpio-halt: triggering GPIO.\n");
+
+ /* Probably wont return */
+ gpio_set_value(gpio, trigger);
+}
+
+/* This IRQ means someone pressed the power button and it is waiting =
for us
+ * to handle the shutdown/poweroff. */
+static irqreturn_t gpio_halt_irq(int irq, void *__data)
+{
+ printk(KERN_INFO "gpio-halt: shutdown due to power button =
IRQ.\n");
+ schedule_work(&gpio_halt_wq);
+
+ return IRQ_HANDLED;
+};
+
+static int __devinit gpio_halt_probe(struct platform_device *pdev)
+{
+ enum of_gpio_flags flags;
+ struct device_node *node =3D pdev->dev.of_node;
+ int gpio, err, irq;
+ int trigger;
+
+ if (!node)
+ return -ENODEV;
+
+ /* If there's no matching child, this isn't really an error */
+ halt_node =3D of_find_matching_node(node, child_match);
+ if (!halt_node)
+ return 0;
+
+ /* Technically we could just read the first one, but punish
+ * DT writers for invalid form. */
+ if (of_gpio_count(halt_node) !=3D 1)
+ return -EINVAL;
+
+ /* Get the gpio number relative to the dynamic base. */
+ gpio =3D of_get_gpio_flags(halt_node, 0, &flags);
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+
+ err =3D gpio_request(gpio, "gpio-halt");
+ if (err) {
+ printk(KERN_ERR "gpio-halt: error requesting GPIO =
%d.\n",
+ gpio);
+ halt_node =3D NULL;
+ return err;
+ }
+
+ trigger =3D (flags =3D=3D OF_GPIO_ACTIVE_LOW);
+
+ gpio_direction_output(gpio, !trigger);
+
+ /* Now get the IRQ which tells us when the power button is hit =
*/
+ irq =3D irq_of_parse_and_map(halt_node, 0);
+ err =3D request_irq(irq, gpio_halt_irq, IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING, "gpio-halt", halt_node);
+ if (err) {
+ printk(KERN_ERR "gpio-halt: error requesting IRQ %d for =
"
+ "GPIO %d.\n", irq, gpio);
+ gpio_free(gpio);
+ halt_node =3D NULL;
+ return err;
+ }
+
+ /* Register our halt function */
+ ppc_md.halt =3D gpio_halt_cb;
+ ppc_md.power_off =3D gpio_halt_cb;
+
+ printk(KERN_INFO "gpio-halt: registered GPIO %d (%d trigger, %d"
+ " irq).\n", gpio, trigger, irq);
+
+ return 0;
+}
+
+static int __devexit gpio_halt_remove(struct platform_device *pdev)
+{
+ if (halt_node) {
+ int gpio =3D of_get_gpio(halt_node, 0);
+ int irq =3D irq_of_parse_and_map(halt_node, 0);
+
+ free_irq(irq, halt_node);
+
+ ppc_md.halt =3D NULL;
+ ppc_md.power_off =3D NULL;
+
+ gpio_free(gpio);
+
+ halt_node =3D NULL;
+ }
+
+ return 0;
+}
+
+static struct of_device_id gpio_halt_match[] =3D {
+ /* We match on the gpio bus itself and scan the children since =
they
+ * wont be matched against us. We know the bus wont match until =
it
+ * has been registered too. */
+ {
+ .compatible =3D "fsl,qoriq-gpio",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, gpio_halt_match);
+
+static struct platform_driver gpio_halt_driver =3D {
+ .driver =3D {
+ .name =3D "gpio-halt",
+ .owner =3D THIS_MODULE,
+ .of_match_table =3D gpio_halt_match,
+ },
+ .probe =3D gpio_halt_probe,
+ .remove =3D __devexit_p(gpio_halt_remove),
+};
+
+module_platform_driver(gpio_halt_driver);
+
+MODULE_DESCRIPTION("Driver to support GPIO triggered system halt for =
Servergy CTS-1000 Systems.");
+MODULE_VERSION("1.0");
+MODULE_AUTHOR("Ben Collins <ben.c@servergy.com>");
+MODULE_LICENSE("GPL");
--=20
1.7.10.4
^ permalink raw reply related
* Re: linux-next: build warning after merge of the final tree
From: Andrew Morton @ 2012-12-17 20:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Thompson, linux-kernel, linux-next, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20121217143415.252a2f60076d1ba03807df55@canb.auug.org.au>
On Mon, 17 Dec 2012 14:34:15 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Mon, 17 Dec 2012 14:22:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the final tree, today's linux-next build (powerpc allnoconfig)
> > produced this warning:
> >
> > warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS && (IRQ_DOMAIN && DEBUG_FS || MAY_HAVE_SPARSE_IRQ))
> >
> > I don't know what introduced that.
>
> Actually probably caused by commit a1eaa3bc8247 ("Kconfig: fix Irq
> Subsystem menu") from the akpm tree.
kconfig-fix-irq-subsystem-menu.patch was causing various problems so I
have dropped it.
^ permalink raw reply
* [PATCH v3] NTP: Add a CONFIG_RTC_SYSTOHC configuration
From: Jason Gunthorpe @ 2012-12-17 21:30 UTC (permalink / raw)
To: John Stultz
Cc: Alessandro Zummo, rtc-linux, linux-kernel, Thomas Gleixner,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <50CBB917.7090502@linaro.org>
The purpose of this option is to allow ARM/etc systems that rely on the
class RTC subsystem to have the same kind of automatic NTP based
synchronization that we have on PC platforms. Today ARM does not
implement update_persistent_clock and makes extensive use of the class
RTC system.
When enabled CONFIG_RTC_SYSTOHC will provide a generic
rtc_update_persistent_clock that stores the current time in the RTC and
is intended complement the existing CONFIG_RTC_HCTOSYS option that loads
the RTC at boot.
Like with RTC_HCTOSYS the platform's update_persistent_clock is used
first, if it works. Platforms with mixed class RTC and non-RTC drivers
need to return ENODEV when class RTC should be used. Such an update for
PPC is included in this patch.
Long term, implementations of update_persistent_clock should migrate to
proper class RTC drivers and use CONFIG_RTC_SYSTOHC instead.
Tested on ARM kirkwood and PPC405
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
---
arch/powerpc/kernel/time.c | 2 +-
drivers/rtc/Kconfig | 10 +++++++++-
drivers/rtc/Makefile | 1 +
drivers/rtc/systohc.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/rtc.h | 1 +
kernel/time/ntp.c | 16 ++++++++++++----
6 files changed, 68 insertions(+), 6 deletions(-)
create mode 100644 drivers/rtc/systohc.c
v3 changes:
- Test menuconfig, reorder options to look better, fix kconfig
RTC_HCTOSYS_DEVICE to be 'or' not 'and'
- Change the function name to rtc_set_ntp_time to avoid confusing
this api with the distinct *_persistant_clock stuff
- Fix typo in the ENODEV test to be || not &&
- Fully retest on ARM+PPC
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index ce4cb77..bc844a8 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -667,7 +667,7 @@ int update_persistent_clock(struct timespec now)
struct rtc_time tm;
if (!ppc_md.set_rtc_time)
- return 0;
+ return -ENODEV;
to_tm(now.tv_sec + 1 + timezone_offset, &tm);
tm.tm_year -= 1900;
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 19c03ab..b377e96 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -25,9 +25,17 @@ config RTC_HCTOSYS
the value read from a specified RTC device. This is useful to avoid
unnecessary fsck runs at boot time, and to network better.
+config RTC_SYSTOHC
+ bool "Set the RTC time based on NTP synchronization"
+ default y
+ help
+ If you say yes here, the system time (wall clock) will be stored
+ in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11
+ minutes if userspace reports synchronized NTP status.
+
config RTC_HCTOSYS_DEVICE
string "RTC used to set the system time"
- depends on RTC_HCTOSYS = y
+ depends on RTC_HCTOSYS = y || RTC_SYSTOHC = y
default "rtc0"
help
The RTC device that will be used to (re)initialize the system
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56297f0..69d11f1 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -6,6 +6,7 @@ ccflags-$(CONFIG_RTC_DEBUG) := -DDEBUG
obj-$(CONFIG_RTC_LIB) += rtc-lib.o
obj-$(CONFIG_RTC_HCTOSYS) += hctosys.o
+obj-$(CONFIG_RTC_SYSTOHC) += systohc.o
obj-$(CONFIG_RTC_CLASS) += rtc-core.o
rtc-core-y := class.o interface.o
diff --git a/drivers/rtc/systohc.c b/drivers/rtc/systohc.c
new file mode 100644
index 0000000..bf3e242
--- /dev/null
+++ b/drivers/rtc/systohc.c
@@ -0,0 +1,44 @@
+/*
+ * 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 published by
+ * the Free Software Foundation.
+ *
+ */
+#include <linux/rtc.h>
+#include <linux/time.h>
+
+/**
+ * rtc_set_ntp_time - Save NTP synchronized time to the RTC
+ * @now: Current time of day
+ *
+ * Replacement for the NTP platform function update_persistent_clock
+ * that stores time for later retrieval by rtc_hctosys.
+ *
+ * Returns 0 on successful RTC update, -ENODEV if a RTC update is not
+ * possible at all, and various other -errno for specific temporary failure
+ * cases.
+ *
+ * If temporary failure is indicated the caller should try again 'soon'
+ */
+int rtc_set_ntp_time(struct timespec now)
+{
+ struct rtc_device *rtc;
+ struct rtc_time tm;
+ int err = -ENODEV;
+
+ if (now.tv_nsec < (NSEC_PER_SEC >> 1))
+ rtc_time_to_tm(now.tv_sec, &tm);
+ else
+ rtc_time_to_tm(now.tv_sec + 1, &tm);
+
+ rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
+ if (rtc) {
+ /* rtc_hctosys exclusively uses UTC, so we call set_time here,
+ * not set_mmss. */
+ if (rtc->ops && (rtc->ops->set_time || rtc->ops->set_mmss))
+ err = rtc_set_time(rtc, &tm);
+ rtc_class_close(rtc);
+ }
+
+ return err;
+}
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 9531845..11d05f9 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -138,6 +138,7 @@ extern void rtc_device_unregister(struct rtc_device *rtc);
extern int rtc_read_time(struct rtc_device *rtc, struct rtc_time *tm);
extern int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm);
extern int rtc_set_mmss(struct rtc_device *rtc, unsigned long secs);
+extern int rtc_set_ntp_time(struct timespec now);
int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm);
extern int rtc_read_alarm(struct rtc_device *rtc,
struct rtc_wkalrm *alrm);
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 24174b4..313b161 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -15,6 +15,7 @@
#include <linux/time.h>
#include <linux/mm.h>
#include <linux/module.h>
+#include <linux/rtc.h>
#include "tick-internal.h"
@@ -483,8 +484,7 @@ out:
return leap;
}
-#ifdef CONFIG_GENERIC_CMOS_UPDATE
-
+#if defined(CONFIG_GENERIC_CMOS_UPDATE) || defined(CONFIG_RTC_SYSTOHC)
static void sync_cmos_clock(struct work_struct *work);
static DECLARE_DELAYED_WORK(sync_cmos_work, sync_cmos_clock);
@@ -510,14 +510,22 @@ static void sync_cmos_clock(struct work_struct *work)
}
getnstimeofday(&now);
- if (abs(now.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2)
+ if (abs(now.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2) {
+ fail = -ENODEV;
+#ifdef CONFIG_GENERIC_CMOS_UPDATE
fail = update_persistent_clock(now);
+#endif
+#ifdef CONFIG_RTC_SYSTOHC
+ if (fail == -ENODEV)
+ fail = rtc_set_ntp_time(now);
+#endif
+ }
next.tv_nsec = (NSEC_PER_SEC / 2) - now.tv_nsec - (TICK_NSEC / 2);
if (next.tv_nsec <= 0)
next.tv_nsec += NSEC_PER_SEC;
- if (!fail)
+ if (!fail || fail == -ENODEV)
next.tv_sec = 659;
else
next.tv_sec = 0;
--
1.7.5.4
^ permalink raw reply related
* [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2012-12-17 23:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel list
In-Reply-To: <1355517897.19932.136.camel@pasglop>
On Sat, 2012-12-15 at 07:44 +1100, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> Finally managed to get my head away from some other distractions
> to put this pull request together, sorry for the lateness :-)
>
> The main highlight is probably some base POWER8 support. There's
> more to come such as transactional memory support but that will
> wait for the next one. (next merge window)
>
> Overall it's pretty quiet, or rather I've been pretty poor at
> picking things up from patchwork and reviewing them this time
> around and Kumar no better on the FSL side it seems...
So it looks like I'm an idiot and totally failed to put your email
address on the CC list of that pull request :-)
This is an updated version with Anatolij 52xx which I hadn't merged back
then but have now (it's all be in -next for a while).
Cheers,
Ben.
The following changes since commit b69f0859dc8e633c5d8c06845811588fe17e68b3:
Linux 3.7-rc8 (2012-12-03 11:22:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
for you to fetch changes up to 376bddd34433065aeb9b9a140870537feecf90ef:
Merge remote-tracking branch 'agust/next' into next (2012-12-18 10:22:27 +1100)
----------------------------------------------------------------
Akinobu Mita (3):
powerpc/iommu: Use bitmap library
powerpc: Remove BITOP_MASK and BITOP_WORD from asm/bitops.h
powerpc: Use asm-generic/bitops/le.h
Andreas Schwab (1):
powerpc/powermac/cpufreq_32: Set non-infinite transition time for 7447A driver
Anton Blanchard (3):
powerpc: Move most of setup.h out of uapi
powerpc: Remove stale function prototypes from setup.h
powerpc: Fix CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n build
Aravinda Prasad (1):
powerpc/ptrace: Enable hardware breakpoint upon re-registering
Benjamin Herrenschmidt (6):
powerpc/powernv: Fix OPAL debug entry
Merge branch 'dt' into next
Merge branch 'merge' into next
Merge remote-tracking branch 'kumar/next' into next
powerpc+of: Rename and fix OF reconfig notifier error inject module
Merge remote-tracking branch 'agust/next' into next
Dan Horák (1):
fbdev: Add GXT4000P and GXT6500P support to the gxt4500 driver
Gavin Shan (1):
powerpc/pnv: Avoid bogus output
Ian Munsie (5):
powerpc: Add set_mode hcall
powerpc: Add wrappers to enable/disable relocation on exceptions
powerpc: Move get_longbusy_msecs into hvcall.h and remove duplicate function
powerpc: Enable relocation on during exceptions at boot
powerpc: Disable relocation on exceptions when kexecing
Jia Hongtao (1):
powerpc/fsl-pci: Add PCI controller ATMU PM support
JoonSoo Kim (1):
powerpc: Change free_bootmem() to kfree()
Julia Lawall (1):
powerpc/rtas_flash: Eliminate possible double free
K.Prasad (1):
powerpc/hw-breakpoint: Use generic hw-breakpoint interfaces for new PPC ptrace flags
Li Zhong (1):
powerpc: Fix MAX_STACK_TRACE_ENTRIES too low warning !
Matthew McClintock (1):
powerpc: dtc is required to build dtb files
Michael Ellerman (12):
powerpc/udbg: Remove unused udbg_read()
powerpc/xmon: Remove unused xmon_expect() & xmon_read_poll()
powerpc/xmon: Remove empty xmon_map_scc()
powerpc/xmon: Make xmon_getchar() static
powerpc/xmon: Merge start.c into nonstdio.c
powerpc/xmon: Remove renaming #defines of scanhex() and skipbl()
powerpc/xmon: Remove unused #defines
powerpc/xmon: Use STACK_FRAME_OVERHEAD in xmon_show_stack()
powerpc/xmon: Fiddle xmon_depth_to_print logic in xmon_show_stack()
powerpc/xmon: Fallback to printk() in xmon_printf() if udbg is not setup
powerpc: Remove no longer used ppc_md.idle_loop()
powerpc/perf: Add missing L2 constraint handling in Power7 PMU
Michael Neuling (16):
powerpc/ptrace: Fix spelling mistake
powerpc/ptrace: Remove unused addr parameter in ppc_del_hwdebug()
powerpc: make POWER7 setup code name generic
powerpc: Add POWER8 setup code
powerpc: POWER8 cputable entry
powerpc: Fix denorm symbol name
powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8
powerpc: Add POWER8 architected mode to cputable
powerpc: Whitespace changes in exception64s.S
powerpc: Remove unessessary 0x3000 location enforcement
powerpc: Make load_hander handle upto 64k offset
powerpc: Turn syscall handler into macros
powerpc: Add new macros needed for relocation on exceptions
powerpc: Add relocation on exception vector handlers
powerpc: Move initial mfspr LPCR out of __init_LPCR
powerpc: Setup relocation on exceptions for bare metal systems
Nathan Fontenot (6):
powerpc+of: Add /proc device tree updating to of node add/remove
powerpc+of: Move of_drconf_cell struct definition to asm/prom.h
powerpc+of: Add of node/property notification chain for adds and removes
powerpc+of: Rename the drivers/of prom_* functions to of_*
powerpc+of: Remove the pSeries_reconfig.h file
powerpc+of: Export of_reconfig_notifier_[register,unregister]
Nishanth Aravamudan (1):
powerpc/pseries: Double NR_CPUS in defconfig
Srinivas Kandagatla (2):
powerpc/sysdev: Use module_platform_driver macro
powerpc/mpc52xx: use module_platform_driver macro
Stefan Roese (1):
powerpc: mpc5200: Add a3m071 board support
Sukadev Bhattiprolu (1):
powerpc/perf: Use uapi/unistd.h to fix build error
Timur Tabi (3):
drivers/virt: the Freescale hypervisor driver doesn't need to check MSR[GS]
powerpc/86xx: fsl_pcibios_fixup_bus requires CONFIG_PCI
powerpc/512x: don't compile any platform DIU code if the DIU is not enabled
Tony Breeds (2):
powerpc/47x: Use the new ppc-opcode infrastructure
powerpc: Add asm/debug.h to get powerpc_debugfs_root
Tushar Behera (1):
powerpc/85xx: p1022ds: Use NULL instead of 0 for pointers
Varun Sethi (1):
powerpc/iommu/fsl: Add PAMU bypass enable register to ccsr_guts struct
Wei Yongjun (1):
powerpc/windfarm: Use module_i2c_driver to simplify the code
Xuelin Shi (1):
powerpc/dma/raidengine: add raidengine device
Yang Li (1):
powerpc: Fix typos in Freescale copyright claims
York Sun (1):
powerpc/mpc85xx: Change spin table to cached memory
.../devicetree/bindings/powerpc/fsl/raideng.txt | 81 +++++
Documentation/powerpc/ptrace.txt | 16 +
arch/arm/mach-mxs/mach-mxs.c | 2 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/dts/a3m071.dts | 144 +++++++++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 6 +
arch/powerpc/boot/dts/fsl/qoriq-raid1.0-0.dtsi | 85 ++++++
arch/powerpc/configs/pseries_defconfig | 2 +-
arch/powerpc/include/asm/bitops.h | 75 +----
arch/powerpc/include/asm/cputable.h | 12 +-
arch/powerpc/include/asm/dbell.h | 2 +-
arch/powerpc/include/asm/exception-64s.h | 97 +++++-
arch/powerpc/include/asm/firmware.h | 4 +-
arch/powerpc/include/asm/fsl_gtm.h | 2 +-
arch/powerpc/include/asm/fsl_guts.h | 4 +-
arch/powerpc/include/asm/hvcall.h | 23 +-
arch/powerpc/include/asm/immap_qe.h | 2 +-
arch/powerpc/include/asm/machdep.h | 3 -
arch/powerpc/include/asm/mmu.h | 1 +
arch/powerpc/include/asm/pSeries_reconfig.h | 47 ---
arch/powerpc/include/asm/ppc-opcode.h | 6 +-
arch/powerpc/include/asm/prom.h | 16 +
arch/powerpc/include/asm/qe.h | 2 +-
arch/powerpc/include/asm/qe_ic.h | 2 +-
arch/powerpc/include/asm/reg.h | 3 +
arch/powerpc/include/asm/rtas.h | 5 +
arch/powerpc/include/asm/setup.h | 29 ++
arch/powerpc/include/asm/ucc.h | 2 +-
arch/powerpc/include/asm/ucc_fast.h | 2 +-
arch/powerpc/include/asm/ucc_slow.h | 2 +-
arch/powerpc/include/asm/udbg.h | 1 -
arch/powerpc/include/uapi/asm/setup.h | 31 --
arch/powerpc/kernel/Makefile | 2 +-
.../{cpu_setup_power7.S => cpu_setup_power.S} | 32 +-
arch/powerpc/kernel/cputable.c | 38 +++
arch/powerpc/kernel/entry_64.S | 2 +
arch/powerpc/kernel/exceptions-64s.S | 308 ++++++++++++++++----
arch/powerpc/kernel/head_64.S | 6 +-
arch/powerpc/kernel/idle.c | 3 -
arch/powerpc/kernel/iommu.c | 16 +-
arch/powerpc/kernel/machine_kexec.c | 14 +-
arch/powerpc/kernel/machine_kexec_64.c | 8 +-
arch/powerpc/kernel/pci_32.c | 2 +-
arch/powerpc/kernel/prom.c | 7 +-
arch/powerpc/kernel/prom_init.c | 11 +-
arch/powerpc/kernel/ptrace.c | 90 +++++-
arch/powerpc/kernel/rtas.c | 1 -
arch/powerpc/kernel/rtas_flash.c | 4 +-
arch/powerpc/kernel/setup_64.c | 5 +
arch/powerpc/kernel/udbg.c | 23 --
arch/powerpc/mm/numa.c | 12 -
arch/powerpc/mm/tlb_nohash_low.S | 15 +-
arch/powerpc/perf/power7-pmu.c | 17 +-
arch/powerpc/platforms/512x/Kconfig | 1 -
arch/powerpc/platforms/512x/mpc5121_ads.c | 3 +
arch/powerpc/platforms/512x/mpc512x.h | 11 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 25 +-
arch/powerpc/platforms/52xx/lite5200.c | 2 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 16 +-
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 8 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 2 +-
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 8 +-
arch/powerpc/platforms/85xx/smp.c | 49 +++-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 2 +
arch/powerpc/platforms/powermac/cpufreq_32.c | 5 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 25 +-
arch/powerpc/platforms/ps3/os-area.c | 6 +-
arch/powerpc/platforms/pseries/dlpar.c | 34 +--
arch/powerpc/platforms/pseries/firmware.c | 1 +
arch/powerpc/platforms/pseries/hotplug-cpu.c | 8 +-
arch/powerpc/platforms/pseries/hotplug-memory.c | 60 ++--
arch/powerpc/platforms/pseries/iommu.c | 10 +-
arch/powerpc/platforms/pseries/mobility.c | 4 +-
arch/powerpc/platforms/pseries/plpar_wrappers.h | 31 ++
arch/powerpc/platforms/pseries/reconfig.c | 119 +-------
arch/powerpc/platforms/pseries/setup.c | 77 ++++-
arch/powerpc/platforms/pseries/smp.c | 1 -
arch/powerpc/sysdev/fsl_gtm.c | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 37 ++-
arch/powerpc/sysdev/pmi.c | 13 +-
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe_ic.h | 2 +-
arch/powerpc/sysdev/qe_lib/qe_io.c | 2 +-
arch/powerpc/sysdev/qe_lib/ucc.c | 2 +-
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 2 +-
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 2 +-
arch/powerpc/sysdev/qe_lib/usb.c | 2 +-
arch/powerpc/xmon/Makefile | 2 +-
arch/powerpc/xmon/nonstdio.c | 53 ++--
arch/powerpc/xmon/nonstdio.h | 6 -
arch/powerpc/xmon/start.c | 34 ---
arch/powerpc/xmon/xmon.c | 26 +-
drivers/crypto/nx/nx-842.c | 20 +-
drivers/crypto/nx/nx.c | 1 -
drivers/infiniband/hw/ehca/hcp_if.c | 20 --
drivers/macintosh/smu.c | 2 +-
drivers/macintosh/windfarm_fcu_controls.c | 14 +-
drivers/macintosh/windfarm_lm75_sensor.c | 14 +-
drivers/macintosh/windfarm_max6690_sensor.c | 13 +-
drivers/macintosh/windfarm_smu_sat.c | 13 +-
drivers/net/ethernet/ibm/ehea/ehea_phyp.h | 20 --
drivers/of/base.c | 142 ++++++++-
drivers/video/Kconfig | 8 +-
drivers/video/gxt4500.c | 15 +-
drivers/virt/fsl_hypervisor.c | 3 -
include/linux/of.h | 29 +-
lib/Kconfig.debug | 10 +-
lib/Makefile | 4 +-
...nject.c => of-reconfig-notifier-error-inject.c} | 22 +-
tools/perf/perf.h | 1 +
117 files changed, 1546 insertions(+), 839 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
create mode 100644 arch/powerpc/boot/dts/a3m071.dts
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-raid1.0-0.dtsi
delete mode 100644 arch/powerpc/include/asm/pSeries_reconfig.h
create mode 100644 arch/powerpc/include/asm/setup.h
rename arch/powerpc/kernel/{cpu_setup_power7.S => cpu_setup_power.S} (80%)
delete mode 100644 arch/powerpc/xmon/start.c
rename lib/{pSeries-reconfig-notifier-error-inject.c => of-reconfig-notifier-error-inject.c} (51%)
^ permalink raw reply
* Re: [PATCH] powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch
From: Peter Bergner @ 2012-12-18 0:26 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: paulus, linuxppc-dev, Kumar Gala, Anton Blanchard
In-Reply-To: <20121217223333.6cb00476@kryten>
On Mon, 2012-12-17 at 22:33 +1100, Anton Blanchard wrote:
> Hi Jimi,
>
> > I know this is a little late, but shouldn't these power7 specific
> > thingies be in "obj-$(CONFIG_PPC_BOOK3S_64)". The reason I ask is
> > that my compiler pukes on "dcbtst" and as I deal with that I wanted
> > to point this out.
>
> I guess we could do that. It's a bit strange your assembler is
> complaining about the dcbtst instructions since we wrap them with
> power4:
>
> .machine push
> .machine "power4"
> dcbt r0,r4,0b01000
> dcbt r0,r7,0b01010
> dcbtst r0,r9,0b01000
> dcbtst r0,r10,0b01010
> eieio
> dcbt r0,r8,0b01010 /* GO */
> .machine pop
Jimi, are you using an "old" binutils from before my patch that
changed the operand order for these types of instructions?
http://sourceware.org/ml/binutils/2009-02/msg00044.html
Peter
^ permalink raw reply
* tqm5200s phy link toggles between up and down
From: Johannes Braun @ 2012-12-18 9:44 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I hope someone could help me with my problem. Currently I am porting
a new kernel (3.3.8) for a tqm5200s based board.
The previous kernel was 2.6.23. The new kernel version is needed because
of support for a wireless card.
The new kernel has problems with my ethernet PHY. The problem occurs only
with our hardware. Not with the TQ eval board.
The eval board uses a Intel PHY. Our board uses a Marvel 88E6085 PHY.
I have tested the new kernel on the eval board and everything runs fine.
But After booting the kernel on our hardware, the ethernet connection is
going up and down and loops between these two states.
This is the log output:
[ 38.608305] PHY: f0003000:00 - Link is Down
[ 41.708310] PHY: f0003000:00 - Link is Up - 10/Half
[ 43.744304] PHY: f0003000:00 - Link is Down
[ 46.844309] PHY: f0003000:00 - Link is Up - 10/Half
I also had a look inside the driver in
Drivers/net/ethernet/freescale/fec_mpc52xx.c
and made a printk output to the link adjust method,
which is called everytime before the link is going down.
/* based on generic_adjust_link from fs_enet-main.c */
static void
mpc52xx_fec_adjust_link(struct net_device *dev)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
struct phy_device *phydev = priv->phydev;
int new_state = 0;
printk( KERN_INFO "%s->%s: entering...",
__FILE__, __func__ );
if (phydev->link != PHY_DOWN) {
if (phydev->duplex != priv->duplex) {
struct mpc52xx_fec __iomem *fec = priv->fec;
u32 rcntrl;
u32 tcntrl;
...
...
This is the output with the above printk:
[ 35.589485] PHY: f0003000:00 - Link is Down
[ 40.752753] drivers/net/ethernet/freescale/fec_mpc52xx.c
->mpc52xx_fec_adjust_link: entering...
[ 40.761494] PHY: f0003000:00 - Link is Up - 10/Half
[ 42.796746] drivers/net/ethernet/freescale/fec_mpc52xx.c
->mpc52xx_fec_adjust_link: entering...
[ 42.805485] PHY: f0003000:00 - Link is Down
[ 49.000755] drivers/net/ethernet/freescale/fec_mpc52xx.c
->mpc52xx_fec_adjust_link: entering...
[ 49.009497] PHY: f0003000:00 - Link is Up - 10/Half
As I noticed the problem occurs also with a 2.6.24 kernel.
Seems that the driver was rewritten and moved from drivers/net/fec_mpc52xx/
to drivers/net/ethernet/freescale/fec_mpc52xx.c.
I am note shure where to search for the problem. The PHY link seems to be in
some kind of auto-negotiating loop of going up and down? Has anyone had this
problem before, or does someone has a tip to fix this problem?
Best regards
Johannes
^ permalink raw reply
* Re: tqm5200s phy link toggles between up and down
From: Wolfgang Grandegger @ 2012-12-18 10:05 UTC (permalink / raw)
To: Johannes Braun; +Cc: linuxppc-dev
In-Reply-To: <50D03E16.1080903@grandegger.com>
On 12/18/2012 10:57 AM, Wolfgang Grandegger wrote:
> On 12/18/2012 10:44 AM, Johannes Braun wrote:
>> Hello,
>>
>> I hope someone could help me with my problem. Currently I am porting
>> a new kernel (3.3.8) for a tqm5200s based board.
>
> This is not really a new kernel.
>
>> The previous kernel was 2.6.23. The new kernel version is needed because
>> of support for a wireless card.
>>
>> The new kernel has problems with my ethernet PHY. The problem occurs only
>> with our hardware. Not with the TQ eval board.
>> The eval board uses a Intel PHY. Our board uses a Marvel 88E6085 PHY.
>
> Is it a PHY or a switch? If is a switch you need to configure a fixed
> link to the switch. This can be done via dts file.
Here is an example:
http://lxr.linux.no/#linux+v3.7.1/arch/powerpc/boot/dts/charon.dts#L129
> Note the the DSA also supports this chip.
See http://lwn.net/Articles/302333/. But I think it lacks device tree
support.
Wolfgang.
^ permalink raw reply
* Re: tqm5200s phy link toggles between up and down
From: Wolfgang Grandegger @ 2012-12-18 9:57 UTC (permalink / raw)
To: Johannes Braun; +Cc: linuxppc-dev
In-Reply-To: <CADwvPCuBcSnXz1LYYf2ydfdCcz1tV5eBZufEDh5LCaZrmY7W4Q@mail.gmail.com>
On 12/18/2012 10:44 AM, Johannes Braun wrote:
> Hello,
>
> I hope someone could help me with my problem. Currently I am porting
> a new kernel (3.3.8) for a tqm5200s based board.
This is not really a new kernel.
> The previous kernel was 2.6.23. The new kernel version is needed because
> of support for a wireless card.
>
> The new kernel has problems with my ethernet PHY. The problem occurs only
> with our hardware. Not with the TQ eval board.
> The eval board uses a Intel PHY. Our board uses a Marvel 88E6085 PHY.
Is it a PHY or a switch? If is a switch you need to configure a fixed
link to the switch. This can be done via dts file.
Note the the DSA also supports this chip.
Wolfgang.
^ permalink raw reply
* Re: tqm5200s phy link toggles between up and down
From: Johannes Braun @ 2012-12-18 11:01 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <50D03FCE.9060003@grandegger.com>
>> This is not really a new kernel.
Yes this is right. But it is the first Kernel which supports our
wireless card without problems.
>> Is it a PHY or a switch? If is a switch you need to configure a fixed
>> link to the switch. This can be done via dts file.
According to the marvell website it is a switch with integrated phy.
> Here is an example:
> http://lxr.linux.no/#linux+v3.7.1/arch/powerpc/boot/dts/charon.dts#L129
I had a look at this example and compared it to my *.dtb file. The
difference was, the fixed-link tag in the section ethernet@3000 { ...
};.
I added "fixed-link = <1 1 100 0 0>;" to my tqm5200.dtb and now it works.
I am new to powerpc development and I hope it is ok to ask what this
fixed-link with the numbers "1 1 100 0 0" does? Is it the address to
the PHY?
2012/12/18 Wolfgang Grandegger <wg@grandegger.com>:
> On 12/18/2012 10:57 AM, Wolfgang Grandegger wrote:
>> On 12/18/2012 10:44 AM, Johannes Braun wrote:
>>> Hello,
>>>
>>> I hope someone could help me with my problem. Currently I am porting
>>> a new kernel (3.3.8) for a tqm5200s based board.
>>
>> This is not really a new kernel.
>>
>>> The previous kernel was 2.6.23. The new kernel version is needed because
>>> of support for a wireless card.
>>>
>>> The new kernel has problems with my ethernet PHY. The problem occurs only
>>> with our hardware. Not with the TQ eval board.
>>> The eval board uses a Intel PHY. Our board uses a Marvel 88E6085 PHY.
>>
>> Is it a PHY or a switch? If is a switch you need to configure a fixed
>> link to the switch. This can be done via dts file.
>
> Here is an example:
>
> http://lxr.linux.no/#linux+v3.7.1/arch/powerpc/boot/dts/charon.dts#L129
>
>> Note the the DSA also supports this chip.
>
> See http://lwn.net/Articles/302333/. But I think it lacks device tree
> support.
>
> Wolfgang.
>
^ permalink raw reply
* [PATCH]powerpc: Corrected include header path in kvm_para.h
From: Bharat Bhushan @ 2012-12-18 11:21 UTC (permalink / raw)
To: linuxppc-dev, kvm, kvm-ppc, agraf; +Cc: Bharat Bhushan
The include/uapi/asm/kvm_para.h includes
<include/uapi/asm/epapr_hcalls.h> but the correct reference
should be <include/asm/epapr_hcalls.h> as this is the place
where make install_header installs the header files for
userspace.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
arch/powerpc/include/uapi/asm/kvm_para.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/kvm_para.h b/arch/powerpc/include/uapi/asm/kvm_para.h
index ed0e025..e3af328 100644
--- a/arch/powerpc/include/uapi/asm/kvm_para.h
+++ b/arch/powerpc/include/uapi/asm/kvm_para.h
@@ -78,7 +78,7 @@ struct kvm_vcpu_arch_shared {
#define KVM_HCALL_TOKEN(num) _EV_HCALL_TOKEN(EV_KVM_VENDOR_ID, num)
-#include <uapi/asm/epapr_hcalls.h>
+#include <asm/epapr_hcalls.h>
#define KVM_FEATURE_MAGIC_PAGE 1
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH]powerpc: Corrected include header path in kvm_para.h
From: Alexander Graf @ 2012-12-18 12:21 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: Bharat Bhushan, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <1355829688-32545-1-git-send-email-bharat.bhushan@freescale.com>
On 18.12.2012, at 12:21, Bharat Bhushan wrote:
> The include/uapi/asm/kvm_para.h includes
> <include/uapi/asm/epapr_hcalls.h> but the correct reference
> should be <include/asm/epapr_hcalls.h> as this is the place
> where make install_header installs the header files for
> userspace.
>=20
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Thanks, applied to kvm-ppc-next (with CC to stable@vger).
Alex
> ---
> arch/powerpc/include/uapi/asm/kvm_para.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>=20
> diff --git a/arch/powerpc/include/uapi/asm/kvm_para.h =
b/arch/powerpc/include/uapi/asm/kvm_para.h
> index ed0e025..e3af328 100644
> --- a/arch/powerpc/include/uapi/asm/kvm_para.h
> +++ b/arch/powerpc/include/uapi/asm/kvm_para.h
> @@ -78,7 +78,7 @@ struct kvm_vcpu_arch_shared {
>=20
> #define KVM_HCALL_TOKEN(num) _EV_HCALL_TOKEN(EV_KVM_VENDOR_ID, =
num)
>=20
> -#include <uapi/asm/epapr_hcalls.h>
> +#include <asm/epapr_hcalls.h>
>=20
> #define KVM_FEATURE_MAGIC_PAGE 1
>=20
> --=20
> 1.7.0.4
>=20
>=20
^ permalink raw reply
* Re: [PATCH] powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch
From: Jimi Xenidis @ 2012-12-18 13:21 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Kumar Gala, paulus, linuxppc-dev
In-Reply-To: <20121217223333.6cb00476@kryten>
On Dec 17, 2012, at 5:33 AM, Anton Blanchard <anton@samba.org> wrote:
>=20
> Hi Jimi,
>=20
>> I know this is a little late, but shouldn't these power7 specific
>> thingies be in "obj-$(CONFIG_PPC_BOOK3S_64)". The reason I ask is
>> that my compiler pukes on "dcbtst" and as I deal with that I wanted
>> to point this out.
>=20
> I guess we could do that.
I think it is the right idea since it is unclear that your optimizations =
would actually help an embedded system where most of these cache =
prefetches are NOPs and only wait decode/dispatch cycles.
> It's a bit strange your assembler is
> complaining about the dcbtst instructions since we wrap them with
> power4:
Not really, the binutils is a little old (RHEL 6.2), unfortunately it =
_is_ the toolchain most people are using at the moment.
It will take me a while to get everyone using newer ones since most are =
scientists using the packages they get.
My suggestion was really for correctness, My current patches for BG/Q =
introduce a macro replacement.
-jx
>=20
> .machine push
> .machine "power4"
> dcbt r0,r4,0b01000
> dcbt r0,r7,0b01010
> dcbtst r0,r9,0b01000
> dcbtst r0,r10,0b01010
> eieio
> dcbt r0,r8,0b01010 /* GO */
> .machine pop
>=20
> Anton
^ permalink raw reply
* Re: [PATCH] powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch
From: Jimi Xenidis @ 2012-12-18 13:28 UTC (permalink / raw)
To: Peter Bergner; +Cc: paulus, linuxppc-dev, Kumar Gala, Anton Blanchard
In-Reply-To: <1355790373.5180.26.camel@otta>
On Dec 17, 2012, at 6:26 PM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> On Mon, 2012-12-17 at 22:33 +1100, Anton Blanchard wrote:
>> Hi Jimi,
>>=20
>>> I know this is a little late, but shouldn't these power7 specific
>>> thingies be in "obj-$(CONFIG_PPC_BOOK3S_64)". The reason I ask is
>>> that my compiler pukes on "dcbtst" and as I deal with that I wanted
>>> to point this out.
>>=20
>> I guess we could do that. It's a bit strange your assembler is
>> complaining about the dcbtst instructions since we wrap them with
>> power4:
>>=20
>> .machine push
>> .machine "power4"
>> dcbt r0,r4,0b01000
>> dcbt r0,r7,0b01010
>> dcbtst r0,r9,0b01000
>> dcbtst r0,r10,0b01010
>> eieio
>> dcbt r0,r8,0b01010 /* GO */
>> .machine pop
>=20
> Jimi, are you using an "old" binutils from before my patch that
> changed the operand order for these types of instructions?
>=20
> http://sourceware.org/ml/binutils/2009-02/msg00044.html
Actually, this confused me as well, that embedded has the same =
instruction encoding but different mnemonic.
I was under the impression that the assembler made no instruction =
decisions based on CPU.
So your only hint would be that '0b' prefix.
Does AS even see that?
If not, then without a _normalizing_ macro, I think will need that =
obj-$(CONFIG_PPC_BOOK3S_64) and .S files with the two can never be =
shared.
-jx
>=20
> Peter
>=20
>=20
^ permalink raw reply
* RE: [PATCH] powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch
From: David Laight @ 2012-12-18 14:14 UTC (permalink / raw)
To: Jimi Xenidis, Peter Bergner
Cc: Kumar Gala, linuxppc-dev, paulus, Anton Blanchard
In-Reply-To: <16080DCD-0E42-43E9-93E3-D3076637DCB1@pobox.com>
> >> dcbt r0,r8,0b01010 /* GO */
> >> .machine pop
> >
> > Jimi, are you using an "old" binutils from before my patch that
> > changed the operand order for these types of instructions?
> >
> > http://sourceware.org/ml/binutils/2009-02/msg00044.html
>=20
> Actually, this confused me as well, that embedded has the same
> instruction encoding but different mnemonic.
That it utterly horrid!
> I was under the impression that the assembler made no instruction =
decisions based on CPU.
> So your only hint would be that '0b' prefix.
> Does AS even see that?
Or maybe see the 'r' prefix.
I know they tend to be absent making ppc asm even more unreadable.
It isn't as though the mnemonics were designed at a time when
the source file size or difference in decode time (or code space)
would be significant.
Otherwise it is a complete recipe for disaster.
David
^ permalink raw reply
* Re: [PATCH] powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch
From: Peter Bergner @ 2012-12-18 16:31 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: paulus, linuxppc-dev, Kumar Gala, Anton Blanchard
In-Reply-To: <16080DCD-0E42-43E9-93E3-D3076637DCB1@pobox.com>
On Tue, 2012-12-18 at 07:28 -0600, Jimi Xenidis wrote:
> On Dec 17, 2012, at 6:26 PM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> > Jimi, are you using an "old" binutils from before my patch that
> > changed the operand order for these types of instructions?
> >
> > http://sourceware.org/ml/binutils/2009-02/msg00044.html
>
> Actually, this confused me as well, that embedded has the same instruction
> encoding but different mnemonic.
The mnemonic is the same (ie, dcbtst), and yes, the encoding is the same.
All that is different is the accepted operand ordering...and yes, it is
very unfortunate the operand ordering is different between embedded and
server. :(
> I was under the impression that the assembler made no instruction decisions
> based on CPU. So your only hint would be that '0b' prefix.
> Does AS even see that?
GAS definitely makes decisions based on CPU (ie, -m<cpu> option). Below is
the GAS code used in recognizing the dcbtst instruction. This shows that
the "server" operand ordering is enabled for POWER4 and later cpus while
the "embedded" operand ordering is enabled for pre POWER4 cpus (yes, not
exactly a server versus embedded trigger, but that's we agreed on to
mitigate breaking any old asm code out there).
{"dcbtst", X(31,246), X_MASK, POWER4, PPCNONE, {RA0, RB, CT}},
{"dcbtst", X(31,246), X_MASK, PPC|PPCVLE, POWER4, {CT, RA0, RB}},
GAS doesn't look at how the operands are written to try and guess what
operand ordering you are attempting to use. Rather, it knows what ordering
it expects and the values had better match that ordering.
Peter
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Linus Torvalds @ 2012-12-18 18:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Linux Kernel list
In-Reply-To: <1355787094.5397.30.camel@pasglop>
On Mon, Dec 17, 2012 at 3:31 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sat, 2012-12-15 at 07:44 +1100, Benjamin Herrenschmidt wrote:
>> Hi Linus !
>>
>> Finally managed to get my head away from some other distractions
>> to put this pull request together, sorry for the lateness :-)
>>
>> The main highlight is probably some base POWER8 support. There's
>> more to come such as transactional memory support but that will
>> wait for the next one. (next merge window)
>>
>> Overall it's pretty quiet, or rather I've been pretty poor at
>> picking things up from patchwork and reviewing them this time
>> around and Kumar no better on the FSL side it seems...
>
> So it looks like I'm an idiot and totally failed to put your email
> address on the CC list of that pull request :-)
.. yeah, that helps.
Anyway, I've pulled it in, but got a conflict on the kernel_thread
cleanups from Al. And since the conflict was in the powerpc assembly
code that I don't really know the details of, I did the
straightforward resolve of it, but I'd like you to check it out.
(I haven't pushed it out yet, I'm waiting for the allmodconfig to
finish compiling, so if you see this email quickly, but don't see the
powerpc merge yet, just wait a few minutes)
Linus
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/book3e: load critical/machine/debug exception stack
From: Tabi Timur-B04825 @ 2012-12-18 22:10 UTC (permalink / raw)
To: Tiejun Chen
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
jason.wessel@windriver.com
In-Reply-To: <1351147410-17452-1-git-send-email-tiejun.chen@windriver.com>
On Thu, Oct 25, 2012 at 1:43 AM, Tiejun Chen <tiejun.chen@windriver.com> wr=
ote:
> We always alloc critical/machine/debug check exceptions. This is
> different from the normal exception. So we should load these exception
> stack properly like we did for booke.
Tiejun,
I'm a little confused by these patches, because the actual critical
exception handlers are still commented out:
/* Critical Input Interrupt */
START_EXCEPTION(critical_input);
CRIT_EXCEPTION_PROLOG(0x100, BOOKE_INTERRUPT_CRITICAL,
PROLOG_ADDITION_NONE)
// EXCEPTION_COMMON(0x100, PACA_EXCRIT, INTS_DISABLE)
// bl special_reg_save_crit
// CHECK_NAPPING();
// addi r3,r1,STACK_FRAME_OVERHEAD
// bl .critical_exception
// b ret_from_crit_except
b .
Are you working on fixing this? I'm trying to fix it, too, but I
think you're way ahead of me.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH] powerpc: Add support for context switching the TAR register
From: Ian Munsie @ 2012-12-19 6:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Neuling, linuxppc-dev, Ian Munsie, Matt Evans
From: Ian Munsie <imunsie@au1.ibm.com>
This patch adds support for enabling and context switching the Target
Address Register in Power8. The TAR is a new special purpose register
that can be used for computed branches with the bctar[l] (branch
conditional to TAR) instruction in the same manner as the count and link
registers.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/include/asm/cputable.h | 3 ++-
arch/powerpc/include/asm/processor.h | 1 +
arch/powerpc/include/asm/reg.h | 3 +++
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/cpu_setup_power.S | 7 +++++++
arch/powerpc/kernel/entry_64.S | 16 ++++++++++++++++
6 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 74458e69..cbbec56a 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -172,6 +172,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_ICSWX LONG_ASM_CONST(0x1000000000000000)
#define CPU_FTR_VMX_COPY LONG_ASM_CONST(0x2000000000000000)
#define CPU_FTR_TM LONG_ASM_CONST(0x4000000000000000)
+#define CPU_FTR_BCTAR LONG_ASM_CONST(0x8000000000000000)
#ifndef __ASSEMBLY__
@@ -417,7 +418,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_DSCR | CPU_FTR_SAO | \
CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
- CPU_FTR_DBELL | CPU_FTR_TM_COMP)
+ CPU_FTR_DBELL | CPU_FTR_TM_COMP | CPU_FTR_BCTAR)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 8b2bf7a..cbbd82d 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -275,6 +275,7 @@ struct thread_struct {
unsigned long dscr;
int dscr_inherit;
#endif
+ unsigned long tar;
};
#define ARCH_MIN_TASKALIGN 16
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 5c9fe38..1fa8a56 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -257,6 +257,9 @@
#define SPRN_HRMOR 0x139 /* Real mode offset register */
#define SPRN_HSRR0 0x13A /* Hypervisor Save/Restore 0 */
#define SPRN_HSRR1 0x13B /* Hypervisor Save/Restore 1 */
+#define SPRN_FSCR 0x099 /* Facility Status & Control Register */
+#define FSCR_TAR (1<<8) /* Enable Target Adress Register */
+#define SPRN_TAR 0x32f /* Target Address Register */
#define SPRN_LPCR 0x13E /* LPAR Control Register */
#define LPCR_VPM0 (1ul << (63-0))
#define LPCR_VPM1 (1ul << (63-1))
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 42a4243..77e941e 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -145,6 +145,7 @@ int main(void)
DEFINE(TM_FRAME_SIZE, STACK_FRAME_OVERHEAD +
sizeof(struct pt_regs) + 16);
#endif /* CONFIG_TRANSACTIONAL_MEM */
+ DEFINE(THREAD_TAR, offsetof(struct thread_struct, tar));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, local_flags));
diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
index 57cf140..d29facb 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -56,6 +56,7 @@ _GLOBAL(__setup_cpu_power8)
mfspr r3,SPRN_LPCR
oris r3, r3, LPCR_AIL_3@h
bl __init_LPCR
+ bl __init_FSCR
bl __init_TLB
mtlr r11
blr
@@ -112,6 +113,12 @@ __init_LPCR:
isync
blr
+__init_FSCR:
+ mfspr r3,SPRN_FSCR
+ ori r3,r3,FSCR_TAR
+ mtspr SPRN_FSCR,r3
+ blr
+
__init_TLB:
/* Clear the TLB */
li r6,128
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index b3590c3..253885d 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -451,6 +451,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_DSCR)
std r23,_CCR(r1)
std r1,KSP(r3) /* Set old stack pointer */
+BEGIN_FTR_SECTION
+ /*
+ * Back up the TAR across context switches. Note that the TAR is not
+ * available for use in the kernel. (To provide this, the TAR should
+ * be backed up/restored on exception entry/exit instead, and be in
+ * pt_regs. FIXME, this should be in pt_regs anyway (for debug).)
+ */
+ mfspr r0,SPRN_TAR
+ std r0,THREAD_TAR(r3)
+END_FTR_SECTION_IFSET(CPU_FTR_BCTAR)
+
#ifdef CONFIG_SMP
/* We need a sync somewhere here to make sure that if the
* previous task gets rescheduled on another CPU, it sees all
@@ -533,6 +544,11 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT)
mr r1,r8 /* start using new stack pointer */
std r7,PACAKSAVE(r13)
+BEGIN_FTR_SECTION
+ ld r0,THREAD_TAR(r4)
+ mtspr SPRN_TAR,r0
+END_FTR_SECTION_IFSET(CPU_FTR_BCTAR)
+
#ifdef CONFIG_ALTIVEC
BEGIN_FTR_SECTION
ld r0,THREAD_VRSAVE(r4)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/5] perf/Power7: Use macros to identify perf events
From: Sukadev Bhattiprolu @ 2012-12-19 7:26 UTC (permalink / raw)
To: Peter Zijlstra, Paul Mackerras, Ingo Molnar,
Arnaldo Carvalho de Melo, Anton Blanchard, Jiri Olsa,
robert.richter, linuxppc-dev, linux-kernel
Cc: sukadev
Define and use macros to identify perf events codes This would make it
easier and more readable when these event codes need to be used in more
than one place.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/perf/power7-pmu.c | 28 ++++++++++++++++++++--------
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 441af08..44e70d2 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -51,6 +51,18 @@
#define MMCR1_PMCSEL_MSK 0xff
/*
+ * Power7 event codes.
+ */
+#define PME_PM_CYC 0x1e
+#define PME_PM_GCT_NOSLOT_CYC 0x100f8
+#define PME_PM_CMPLU_STALL 0x4000a
+#define PME_PM_INST_CMPL 0x2
+#define PME_PM_LD_REF_L1 0xc880
+#define PME_PM_LD_MISS_L1 0x400f0
+#define PME_PM_BRU_FIN 0x10068
+#define PME_PM_BRU_MPRED 0x400f6
+
+/*
* Layout of constraint bits:
* 6666555555555544444444443333333333222222222211111111110000000000
* 3210987654321098765432109876543210987654321098765432109876543210
@@ -296,14 +308,14 @@ static void power7_disable_pmc(unsigned int pmc, unsigned long mmcr[])
}
static int power7_generic_events[] = {
- [PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
- [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x100f8, /* GCT_NOSLOT_CYC */
- [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x4000a, /* CMPLU_STALL */
- [PERF_COUNT_HW_INSTRUCTIONS] = 2,
- [PERF_COUNT_HW_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU*/
- [PERF_COUNT_HW_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
- [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x10068, /* BRU_FIN */
- [PERF_COUNT_HW_BRANCH_MISSES] = 0x400f6, /* BR_MPRED */
+ [PERF_COUNT_HW_CPU_CYCLES] = PME_PM_CYC,
+ [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = PME_PM_GCT_NOSLOT_CYC,
+ [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = PME_PM_CMPLU_STALL,
+ [PERF_COUNT_HW_INSTRUCTIONS] = PME_PM_INST_CMPL,
+ [PERF_COUNT_HW_CACHE_REFERENCES] = PME_PM_LD_REF_L1,
+ [PERF_COUNT_HW_CACHE_MISSES] = PME_PM_LD_MISS_L1,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = PME_PM_BRU_FIN,
+ [PERF_COUNT_HW_BRANCH_MISSES] = PME_PM_BRU_MPRED,
};
#define C(x) PERF_COUNT_HW_CACHE_##x
--
1.7.1
^ permalink raw reply related
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