* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Liu Qiang-B32616 @ 2012-02-17 3:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329448660.2892.42.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDE3LCAyMDEyIDExOjE4IEFNDQo+IFRvOiBMaXUgUWlhbmctQjMyNjE2DQo+IENjOiBq
Z2FyemlrQHBvYm94LmNvbTsgbGludXgtaWRlQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtDQo+
IGRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+IFN1
YmplY3Q6IFJFOiBbUEFUQ0ggVjIgUkVTRU5EXSBmc2wtc2F0YTogSS9PIGxvYWQgYmFsYW5jaW5n
DQo+IA0KPiBPbiBGcmksIDIwMTItMDItMTcgYXQgMDE6NTQgKzAwMDAsIExpdSBRaWFuZy1CMzI2
MTYgd3JvdGU6DQo+ID4gVGhlIGRlZmF1bHQgd2lsbCBiZSBzZXQgaW4gYSBjb21tb24gaW50ZXJm
YWNlDQo+ID4gZnNsX3NhdGFfc2V0X2lycV9jb2FsZXNjaW5nIHdoZW4gaW5pdGlhbGl6ZSB0aGUg
Y29udHJvbGxlci4gVGhpcw0KPiA+IGludGVyZmFjZSB3aWxsIGNoZWNrIHRoZSByYW5nZSBvZiBp
bnRyIGNvdW50IGFuZCB0aWNrcyBhbmQgbWFrZSBzdXJlDQo+IHRoZSB2YWx1ZXMgYXJlIHJlYXNv
bmFibHkuDQo+IA0KPiBBbGxyaWdodCwgYnV0IHRoZSBjdXJyZW50IGRlZmF1bHRzIGFyZSBiYXNp
Y2FsbHkgbm8gY29hbGVzY2luZyByaWdodCA/DQo+IA0KPiA+IEl0J3MgaGFyZCB0byBmaW5kIGEg
YWdncmVzc2l2ZSB2YWx1ZSB0byBhZGFwdCBhbGwgc2NlbmFyaW9zLCBzbyBJIHVzZQ0KPiA+IGVj
aG8gdG8gYWRqdXN0IHRoZSB2YWx1ZS4gSSByZW1lbWJlciBQNTAyMCBoYXZlIHNvbWUgcGVyZm9y
bWFuY2UgaXNzdWUsDQo+IEkgd2lsbCBjaGVjayBpdC4NCj4gPiBCVFcsIHdoaWNoIGZpbGVzeXN0
ZW0gZG8geW91IHVzZT8gRXh0MiBpcyBsb3dlciB0aGFuIGV4dDQgYmVjYXVzZQ0KPiA+IG1ldGFk
YXRhIGlzIGNvbnRpbnVvdXNseSB3cm90ZSB0byBkaXNrLiBZb3UgY2FuIHRyeSBleHQ0IG9yIHhm
cy4NCj4gDQo+IGV4dDMgYXQgdGhlIG1vbWVudCwgSSBwbGFuIHRvIHN3aXRjaCB0byBleHQ0IHdo
ZW4gSSBmaW5pc2ggdGhhdCBmc2NrIHBhc3MNCj4gd2hpY2ggaXMgdGFraW5nIGhvdXJzLi4uIEkg
YW0gbm90IGF3YXJlIG9mIHRoZSA1MDIwIHBlcmZvcm1hbmNlIGlzc3VlcywNCj4gaXMgdGhpcyBz
b21ldGhpbmcgZG9jdW1lbnRlZCBhbmQvb3IgZml4YWJsZSA/DQo+IA0KDQpNeSBwYXRjaCBtYXkg
bm90IG1lZXQgeW91ciByZXF1aXJlbWVudDooDQpGb3IgeW91ciBwZXJmb3JtYW5jZSByZXF1aXJl
bWVudCwgSSBzdWdnZXN0IHVzZSBleHQ0IGZpbGVzeXN0ZW0gYW5kIFNTRC4NCg0KVGhhbmtzLg0K
DQo+IENoZWVycywNCj4gQmVuLg0KPiANCj4gDQoNCg==
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Pan Jiafei-B37022 @ 2012-02-17 3:20 UTC (permalink / raw)
To: Liu Shengzhou-B36685, Benjamin Herrenschmidt
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3F453DDFF675A64A89321A1F3528102170A6FF@039-SN1MPN1-004.039d.mgd.msft.net>
FYI, I once fixed this issue when backport P5020 BSP for WR Linux, The foll=
owing is the patch which I have submitted to linuxbj-internal.
From: linuxbj-internal-bounces@linux.freescale.net [mailto:linuxbj-internal=
-bounces@linux.freescale.net] On Behalf Of Pan Jiafei-B37022
Sent: Friday, December 16, 2011 12:49 PM
To: linuxbj-internal@linux.freescale.net
Cc: Pan Jiafei-B37022
Subject: [Linuxbj-internal] [PATCH] USB: ehci-fsl: Turn on cache snooping o=
n MPC8xxx
If a MPC8xxx was being used, 'have_sysif_regs' should be set and
it should setup cache snooping for all the 4GB space on both PPC32
and PPC64.
Signed-off-by: Pan Jiafei <Jiafei.Pan@freescale.com>
---
drivers/usb/host/ehci-fsl.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 90534cc..ee14fa7 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -260,21 +260,18 @@ static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
if (pdata->have_sysif_regs) {
temp =3D in_be32(non_ehci + FSL_SOC_USB_CTRL);
out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
- }
-#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
- /*
- * Turn on cache snooping hardware, since some PowerPC platforms
- * wholly rely on hardware to deal with cache coherent
- */
+ /*
+ * Turn on cache snooping hardware, since some PowerPC platforms
+ * wholly rely on hardware to deal with cache coherent
+ */
- /* Setup Snooping for all the 4GB space */
- /* SNOOP1 starts from 0x0, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
- /* SNOOP2 starts from 0x80000000, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
-#endif
+ /* Setup Snooping for all the 4GB space */
+ /* SNOOP1 starts from 0x0, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
+ /* SNOOP2 starts from 0x80000000, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_=
2GB);
+ }
if ((pdata->operating_mode =3D=3D FSL_USB2_DR_HOST) ||
(pdata->operating_mode =3D=3D FSL_USB2_DR_OTG))
--=20
1.7.5.1
> -----Original Message-----
> From: linuxppc-dev-bounces+jiafei.pan=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+jiafei.pan=3Dfreescale.com@lists.ozlabs.org]
> On Behalf Of Liu Shengzhou-B36685
> Sent: Friday, February 17, 2012 10:33 AM
> To: Benjamin Herrenschmidt
> Cc: linux-usb@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH] powerpc/usb: fix bug of kernel hang when
> initializing usb
>=20
>=20
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Friday, February 17, 2012 8:03 AM
> > To: Liu Shengzhou-B36685
> > Cc: linux-usb@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] powerpc/usb: fix bug of kernel hang when
> > initializing usb
> >
> > On Fri, 2012-02-17 at 09:58 +1100, Benjamin Herrenschmidt wrote:
> > > On Thu, 2012-02-16 at 18:02 +0800, Shengzhou Liu wrote:
> > > > If USB UTMI PHY is not enable, writing to portsc register will
> > > > lead to kernel hang during boot up.
> > > >
> > > > Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> > > > ---
> > > > Apply for master branch of
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-
> > 2.6.git
> > > > Tested on P5020DS, the issue was reported by Benjamin Herrenschmidt=
.
> > >
> > > This fixes the hang, but sadly doesn't make USB work. I now get:
> >
> > .../...
> >
> > Ok, found the problem.
> >
> > First, the SDK kernel had a delay after setting that bit, I added that
> > back in. This is not what fixed it but it looks like the right thing
> > to do, though please, use msleep rather than udelay here if possible
> > (not in atomic context).
> >
> > Then, the real culprit is (CC'ing Kumar and Scott to figure out why)
> > this statement:
> >
> > #if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> > /*
> > * Turn on cache snooping hardware, since some PowerPC platforms
> > * wholly rely on hardware to deal with cache coherent
> > */
> >
> > /* Setup Snooping for all the 4GB space */
> > /* SNOOP1 starts from 0x0, size 2G */
> > out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
> > /* SNOOP2 starts from 0x80000000, size 2G */
> > out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 |
> SNOOP_SIZE_2GB);
> > #endif
> >
> > I'm building a 64-bit kernel so this isn't compiled and it looks like
> > the EHCI is thus not snooping.
> >
> > By removing the defined(CONFIG_PPC32) part of the statement, my
> > problem goes away.
> >
> > Cheers,
> > Ben.
> >
> >
>=20
> [Shengzhou] I tested the patch with 32bit P5020DS, USB worked well. Not
> tested with 64-bit kernel.
> Glad to you had found the problem in case of 64-bit, thanks!
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Benjamin Herrenschmidt @ 2012-02-17 3:18 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Liu Qiang-B32616, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <94F013E7935FF44C83EBE7784D62AD3F0574273C@039-SN2MPN1-023.039d.mgd.msft.net>
On Fri, 2012-02-17 at 03:09 +0000, Li Yang-R58472 wrote:
> >I tried a debian install on the p5020ds here and I find SATA to be
> >extremely slow, generating millions of interrupts. I think the
> defaults
> >should be a lot more aggressive at coalescing.
>
> The P5020 has a hardware problem with SATA, making it generate more
> interrupts than it should. A new revision of the silicon will fix it.
Ok cool. With a bit of luck you guys can send me a new silicon when it's
available then :-) (The one in the board you got me seems to be in a
socket).
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Benjamin Herrenschmidt @ 2012-02-17 3:17 UTC (permalink / raw)
To: Liu Qiang-B32616
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <BCB48C05FCE8BC4D9E61E841ECBE6DB702B97D@039-SN2MPN1-013.039d.mgd.msft.net>
On Fri, 2012-02-17 at 01:54 +0000, Liu Qiang-B32616 wrote:
> The default will be set in a common interface fsl_sata_set_irq_coalescing when
> initialize the controller. This interface will check the range of intr count
> and ticks and make sure the values are reasonably.
Allright, but the current defaults are basically no coalescing right ?
> It's hard to find a aggressive value to adapt all scenarios, so I use echo to adjust
> the value. I remember P5020 have some performance issue, I will check it.
> BTW, which filesystem do you use? Ext2 is lower than ext4 because metadata is
> continuously wrote to disk. You can try ext4 or xfs.
ext3 at the moment, I plan to switch to ext4 when I finish that fsck
pass which is taking hours... I am not aware of the 5020 performance
issues, is this something documented and/or fixable ?
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Li Yang-R58472 @ 2012-02-17 3:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Liu Qiang-B32616
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329439216.2892.36.camel@pasglop>
>I tried a debian install on the p5020ds here and I find SATA to be
>extremely slow, generating millions of interrupts. I think the defaults
>should be a lot more aggressive at coalescing.
The P5020 has a hardware problem with SATA, making it generate more interru=
pts than it should. A new revision of the silicon will fix it.
- Leo
^ permalink raw reply
* [PATCH 2/2] powerpc: add support for MPIC message register API
From: Jia Hongtao @ 2012-02-17 2:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meador_inge, b38951
In-Reply-To: <1329446943-9732-1-git-send-email-B38951@freescale.com>
Some MPIC implementations contain one or more blocks of message registers
that are used to send messages between cores via IPIs. A simple API has
been added to access (get/put, read, write, etc ...) these message registers.
The available message registers are initially discovered via nodes in the
device tree. A separate commit contains a binding for the message register
nodes.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
This patch is an update for : http://patchwork.ozlabs.org/patch/98075/
Meador Inge addressed the following points from Ben's feedback:
* Drop the 'mpic_msgr.msr' field.
* Drop the 'mpic_msgr.mer' field in favor of address arithmetic off of 'mpic_msgr.addr'.
* Document the API.
* Disable MPIC register in 'mpic_msgr_put'.
* Put locking in 'mpic_msgr_disable'.
* s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/g.
* Make 'mpic_msgr_write' and 'mpic_msgr_read' 'static inline'.
I just fixed the checkpatch errors and addressed the following item:
* In 'mpic_msgr_set_destination' have a wrapper that goes from Linux
CPU number to HW CPU number.
arch/powerpc/include/asm/mpic_msgr.h | 132 ++++++++++++++++
arch/powerpc/platforms/Kconfig | 8 +
arch/powerpc/sysdev/Makefile | 2 +
arch/powerpc/sysdev/mpic_msgr.c | 282 ++++++++++++++++++++++++++++++++++
4 files changed, 424 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpic_msgr.h
create mode 100644 arch/powerpc/sysdev/mpic_msgr.c
diff --git a/arch/powerpc/include/asm/mpic_msgr.h b/arch/powerpc/include/asm/mpic_msgr.h
new file mode 100644
index 0000000..3ec37dc
--- /dev/null
+++ b/arch/powerpc/include/asm/mpic_msgr.h
@@ -0,0 +1,132 @@
+/*
+ * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+
+#ifndef _ASM_MPIC_MSGR_H
+#define _ASM_MPIC_MSGR_H
+
+#include <linux/types.h>
+#include <linux/spinlock.h>
+
+struct mpic_msgr {
+ u32 __iomem *base;
+ u32 __iomem *mer;
+ int irq;
+ unsigned char in_use;
+ raw_spinlock_t lock;
+ int num;
+};
+
+/* Get a message register
+ *
+ * @reg_num: the MPIC message register to get
+ *
+ * A pointer to the message register is returned. If
+ * the message register asked for is already in use, then
+ * EBUSY is returned. If the number given is not associated
+ * with an actual message register, then ENODEV is returned.
+ * Successfully getting the register marks it as in use.
+ */
+extern struct mpic_msgr *mpic_msgr_get(unsigned int reg_num);
+
+/* Relinquish a message register
+ *
+ * @msgr: the message register to return
+ *
+ * Disables the given message register and marks it as free.
+ * After this call has completed successully the message
+ * register is available to be acquired by a call to
+ * mpic_msgr_get.
+ */
+extern void mpic_msgr_put(struct mpic_msgr *msgr);
+
+/* Enable a message register
+ *
+ * @msgr: the message register to enable
+ *
+ * The given message register is enabled for sending
+ * messages.
+ */
+extern void mpic_msgr_enable(struct mpic_msgr *msgr);
+
+/* Disable a message register
+ *
+ * @msgr: the message register to disable
+ *
+ * The given message register is disabled for sending
+ * messages.
+ */
+extern void mpic_msgr_disable(struct mpic_msgr *msgr);
+
+/* Write a message to a message register
+ *
+ * @msgr: the message register to write to
+ * @message: the message to write
+ *
+ * The given 32-bit message is written to the given message
+ * register. Writing to an enabled message registers fires
+ * an interrupt.
+ */
+static inline void mpic_msgr_write(struct mpic_msgr *msgr, u32 message)
+{
+ out_be32(msgr->base, message);
+}
+
+/* Read a message from a message register
+ *
+ * @msgr: the message register to read from
+ *
+ * Returns the 32-bit value currently in the given message register.
+ * Upon reading the register any interrupts for that register are
+ * cleared.
+ */
+static inline u32 mpic_msgr_read(struct mpic_msgr *msgr)
+{
+ return in_be32(msgr->base);
+}
+
+/* Clear a message register
+ *
+ * @msgr: the message register to clear
+ *
+ * Clears any interrupts associated with the given message register.
+ */
+static inline void mpic_msgr_clear(struct mpic_msgr *msgr)
+{
+ (void) mpic_msgr_read(msgr);
+}
+
+/* Set the destination CPU for the message register
+ *
+ * @msgr: the message register whose destination is to be set
+ * @cpu_num: the Linux CPU number to bind the message register to
+ *
+ * Note that the CPU number given is the CPU number used by the kernel
+ * and *not* the actual hardware CPU number.
+ */
+static inline void mpic_msgr_set_destination(struct mpic_msgr *msgr,
+ u32 cpu_num)
+{
+ out_be32(msgr->base, 1 << get_hard_smp_processor_id(cpu_num));
+}
+
+/* Get the IRQ number for the message register
+ * @msgr: the message register whose IRQ is to be returned
+ *
+ * Returns the IRQ number associated with the given message register.
+ * NO_IRQ is returned if this message register is not capable of
+ * receiving interrupts. What message register can and cannot receive
+ * interrupts is specified in the device tree for the system.
+ */
+static inline int mpic_msgr_get_irq(struct mpic_msgr *msgr)
+{
+ return msgr->irq;
+}
+
+#endif
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index eb294a6..fc4f5580 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -87,6 +87,14 @@ config MPIC_WEIRD
bool
default n
+config MPIC_MSGR
+ bool "MPIC message register support"
+ depends on MPIC
+ default n
+ help
+ Enables support for the MPIC message registers. These
+ registers are used for inter-processor communication.
+
config PPC_I8259
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5e37b47..1951dc7 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,8 @@ ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+mpic-msgr-obj-$(CONFIG_MPIC_MSGR) += mpic_msgr.o
+obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
obj-$(CONFIG_PPC_EPAPR_HV_PIC) += ehv_pic.o
fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
obj-$(CONFIG_PPC_MSI_BITMAP) += msi_bitmap.o
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
new file mode 100644
index 0000000..6e7fa38
--- /dev/null
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -0,0 +1,282 @@
+/*
+ * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
+ *
+ * Some ideas based on un-pushed work done by Vivek Mahajan, Jason Jin, and
+ * Mingkai Hu from Freescale Semiconductor, 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; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/list.h>
+#include <linux/of_platform.h>
+#include <linux/errno.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+#include <asm/mpic_msgr.h>
+
+#define MPIC_MSGR_REGISTERS_PER_BLOCK 4
+#define MPIC_MSGR_STRIDE 0x10
+#define MPIC_MSGR_MER_OFFSET 0x100
+#define MSGR_INUSE 0
+#define MSGR_FREE 1
+
+static struct mpic_msgr **mpic_msgrs;
+static unsigned int mpic_msgr_count;
+
+static inline void _mpic_msgr_mer_write(struct mpic_msgr *msgr, u32 value)
+{
+ out_be32(msgr->mer, value);
+}
+
+static inline u32 _mpic_msgr_mer_read(struct mpic_msgr *msgr)
+{
+ return in_be32(msgr->mer);
+}
+
+static inline void _mpic_msgr_disable(struct mpic_msgr *msgr)
+{
+ u32 mer = _mpic_msgr_mer_read(msgr);
+
+ _mpic_msgr_mer_write(msgr, mer & ~(1 << msgr->num));
+}
+
+struct mpic_msgr *mpic_msgr_get(unsigned int reg_num)
+{
+ unsigned long flags;
+ struct mpic_msgr *msgr;
+
+ /* Assume busy until proven otherwise. */
+ msgr = ERR_PTR(-EBUSY);
+
+ if (reg_num >= mpic_msgr_count)
+ return ERR_PTR(-ENODEV);
+
+ raw_spin_lock_irqsave(&msgr->lock, flags);
+ if (mpic_msgrs[reg_num]->in_use == MSGR_FREE) {
+ msgr = mpic_msgrs[reg_num];
+ msgr->in_use = MSGR_INUSE;
+ }
+ raw_spin_unlock_irqrestore(&msgr->lock, flags);
+
+ return msgr;
+}
+EXPORT_SYMBOL_GPL(mpic_msgr_get);
+
+void mpic_msgr_put(struct mpic_msgr *msgr)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&msgr->lock, flags);
+ msgr->in_use = MSGR_FREE;
+ _mpic_msgr_disable(msgr);
+ raw_spin_unlock_irqrestore(&msgr->lock, flags);
+}
+EXPORT_SYMBOL_GPL(mpic_msgr_put);
+
+void mpic_msgr_enable(struct mpic_msgr *msgr)
+{
+ unsigned long flags;
+ u32 mer;
+
+ raw_spin_lock_irqsave(&msgr->lock, flags);
+ mer = _mpic_msgr_mer_read(msgr);
+ _mpic_msgr_mer_write(msgr, mer | (1 << msgr->num));
+ raw_spin_unlock_irqrestore(&msgr->lock, flags);
+}
+EXPORT_SYMBOL_GPL(mpic_msgr_enable);
+
+void mpic_msgr_disable(struct mpic_msgr *msgr)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&msgr->lock, flags);
+ _mpic_msgr_disable(msgr);
+ raw_spin_unlock_irqrestore(&msgr->lock, flags);
+}
+EXPORT_SYMBOL_GPL(mpic_msgr_disable);
+
+/* The following three functions are used to compute the order and number of
+ * the message register blocks. They are clearly very inefficent. However,
+ * they are called *only* a few times during device initialization.
+ */
+static unsigned int mpic_msgr_number_of_blocks(void)
+{
+ unsigned int count;
+ struct device_node *aliases;
+
+ count = 0;
+ aliases = of_find_node_by_name(NULL, "aliases");
+
+ if (aliases) {
+ char buf[32];
+
+ for (;;) {
+ snprintf(buf, sizeof(buf), "mpic-msgr-block%d", count);
+ if (!of_find_property(aliases, buf, NULL))
+ break;
+
+ count += 1;
+ }
+ }
+
+ return count;
+}
+
+static unsigned int mpic_msgr_number_of_registers(void)
+{
+ return mpic_msgr_number_of_blocks() * MPIC_MSGR_REGISTERS_PER_BLOCK;
+}
+
+static int mpic_msgr_block_number(struct device_node *node)
+{
+ struct device_node *aliases;
+ unsigned int index, number_of_blocks;
+ char buf[64];
+
+ number_of_blocks = mpic_msgr_number_of_blocks();
+ aliases = of_find_node_by_name(NULL, "aliases");
+ if (!aliases)
+ return -1;
+
+ for (index = 0; index < number_of_blocks; ++index) {
+ struct property *prop;
+
+ snprintf(buf, sizeof(buf), "mpic-msgr-block%d", index);
+ prop = of_find_property(aliases, buf, NULL);
+ if (node == of_find_node_by_path(prop->value))
+ break;
+ }
+
+ return index == number_of_blocks ? -1 : index;
+}
+
+/* The probe function for a single message register block.
+ */
+static __devinit int mpic_msgr_probe(struct platform_device *dev)
+{
+ void __iomem *msgr_block_addr;
+ int block_number;
+ struct resource rsrc;
+ unsigned int i;
+ unsigned int irq_index;
+ struct device_node *np = dev->dev.of_node;
+ unsigned int receive_mask;
+ const unsigned int *prop;
+
+ if (!np) {
+ dev_err(&dev->dev, "Device OF-Node is NULL");
+ return -EFAULT;
+ }
+
+ /* Allocate the message register array upon the first device
+ * registered.
+ */
+ if (!mpic_msgrs) {
+ mpic_msgr_count = mpic_msgr_number_of_registers();
+ dev_info(&dev->dev, "Found %d message registers\n",
+ mpic_msgr_count);
+
+ mpic_msgrs = kzalloc(sizeof(struct mpic_msgr) * mpic_msgr_count,
+ GFP_KERNEL);
+ if (!mpic_msgrs) {
+ dev_err(&dev->dev,
+ "No memory for message register blocks\n");
+ return -ENOMEM;
+ }
+ }
+ dev_info(&dev->dev, "Of-device full name %s\n", np->full_name);
+
+ /* IO map the message register block. */
+ of_address_to_resource(np, 0, &rsrc);
+ msgr_block_addr = ioremap(rsrc.start, rsrc.end - rsrc.start);
+ if (!msgr_block_addr) {
+ dev_err(&dev->dev, "Failed to iomap MPIC message registers");
+ return -EFAULT;
+ }
+
+ /* Ensure the block has a defined order. */
+ block_number = mpic_msgr_block_number(np);
+ if (block_number < 0) {
+ dev_err(&dev->dev,
+ "Failed to find message register block alias\n");
+ return -ENODEV;
+ }
+ dev_info(&dev->dev, "Setting up message register block %d\n",
+ block_number);
+
+ /* Grab the receive mask which specifies what registers can receive
+ * interrupts.
+ */
+ prop = of_get_property(np, "mpic-msgr-receive-mask", NULL);
+ receive_mask = (prop) ? *prop : 0xF;
+
+ /* Build up the appropriate message register data structures. */
+ for (i = 0, irq_index = 0; i < MPIC_MSGR_REGISTERS_PER_BLOCK; ++i) {
+ struct mpic_msgr *msgr;
+ unsigned int reg_number;
+
+ msgr = kzalloc(sizeof(struct mpic_msgr), GFP_KERNEL);
+ if (!msgr) {
+ dev_err(&dev->dev, "No memory for message register\n");
+ return -ENOMEM;
+ }
+
+ reg_number = block_number * MPIC_MSGR_REGISTERS_PER_BLOCK + i;
+ msgr->base = msgr_block_addr + i * MPIC_MSGR_STRIDE;
+ msgr->mer = msgr->base + MPIC_MSGR_MER_OFFSET;
+ msgr->in_use = MSGR_FREE;
+ msgr->num = i;
+ raw_spin_lock_init(&msgr->lock);
+
+ if (receive_mask & (1 << i)) {
+ struct resource irq;
+
+ if (of_irq_to_resource(np, irq_index, &irq) == NO_IRQ) {
+ dev_err(&dev->dev,
+ "Missing interrupt specifier");
+ kfree(msgr);
+ return -EFAULT;
+ }
+ msgr->irq = irq.start;
+ irq_index += 1;
+ } else {
+ msgr->irq = NO_IRQ;
+ }
+
+ mpic_msgrs[reg_number] = msgr;
+ mpic_msgr_disable(msgr);
+ dev_info(&dev->dev, "Register %d initialized: irq %d\n",
+ reg_number, msgr->irq);
+
+ }
+
+ return 0;
+}
+
+static const struct of_device_id mpic_msgr_ids[] = {
+ {
+ .compatible = "fsl,mpic-v3.1-msgr",
+ .data = NULL,
+ },
+ {}
+};
+
+static struct platform_driver mpic_msgr_driver = {
+ .driver = {
+ .name = "mpic-msgr",
+ .owner = THIS_MODULE,
+ .of_match_table = mpic_msgr_ids,
+ },
+ .probe = mpic_msgr_probe,
+};
+
+static __init int mpic_msgr_init(void)
+{
+ return platform_driver_register(&mpic_msgr_driver);
+}
+subsys_initcall(mpic_msgr_init);
--
1.7.5.1
^ permalink raw reply related
* [PATCH 1/2] powerpc: document the FSL MPIC message register binding
From: Jia Hongtao @ 2012-02-17 2:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meador_inge, b38951
This binding documents how the message register blocks found in some FSL
MPIC implementations shall be represented in a device tree.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 ++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
new file mode 100644
index 0000000..b4ae70e
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
@@ -0,0 +1,62 @@
+* FSL MPIC Message Registers
+
+This binding specifies what properties must be available in the device tree
+representation of the message register blocks found in some FSL MPIC
+implementations.
+
+Required properties:
+
+ - compatible: Specifies the compatibility list for the message register
+ block. The type shall be <string> and the value shall be of the form
+ "fsl,mpic-v<version>-msgr", where <version> is the version number of
+ the MPIC containing the message registers.
+
+ - reg: Specifies the base physical address(s) and size(s) of the
+ message register block's addressable register space. The type shall be
+ <prop-encoded-array>.
+
+ - interrupts: Specifies a list of interrupt source and level-sense pairs.
+ The type shall be <prop-encoded-array>. The length shall be equal to
+ the number of registers that are available for receiving interrupts.
+
+Optional properties:
+
+ - mpic-msgr-receive-mask: Specifies what registers in the containing block
+ are allowed to receive interrupts. The value is a bit mask where a set
+ bit at bit 'n' indicates that message register 'n' can receive interrupts.
+ The type shall be <prop-encoded-array>. If not present, then all of
+ the message registers in the block are available.
+
+Aliases:
+
+ An alias should be created for every message register block. They are not
+ required, though. However, a particular implementation of this binding
+ may require aliases to be present. Aliases are of the form
+ 'mpic-msgr-block<n>', where <n> is an integer specifying the block's number.
+ Numbers shall start at 0.
+
+Example:
+
+ aliases {
+ mpic-msgr-block0 = &mpic_msgr_block0;
+ mpic-msgr-block1 = &mpic_msgr_block1;
+ };
+
+ mpic_msgr_block0: mpic-msgr-block@41400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x41400 0x200>;
+ // Message registers 0 and 2 in this block can receive interrupts on
+ // sources 0xb0 and 0xb2, respectively.
+ interrupts = <0xb0 2 0xb2 2>;
+ mpic-msgr-receive-mask = <0x5>;
+ };
+
+ mpic_msgr_block1: mpic-msgr-block@42400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x42400 0x200>;
+ // Message registers 0 and 2 in this block can receive interrupts on
+ // sources 0xb4 and 0xb6, respectively.
+ interrupts = <0xb4 2 0xb6 2>;
+ mpic-msgr-receive-mask = <0x5>;
+ };
+
--
1.7.5.1
^ permalink raw reply related
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Liu Shengzhou-B36685 @ 2012-02-17 2:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329436955.2892.32.camel@pasglop>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbmphbWluIEhlcnJlbnNj
aG1pZHQgW21haWx0bzpiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmddDQo+IFNlbnQ6IEZyaWRheSwg
RmVicnVhcnkgMTcsIDIwMTIgODowMyBBTQ0KPiBUbzogTGl1IFNoZW5nemhvdS1CMzY2ODUNCj4g
Q2M6IGxpbnV4LXVzYkB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMu
b3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2VycGMvdXNiOiBmaXggYnVnIG9mIGtlcm5l
bCBoYW5nIHdoZW4NCj4gaW5pdGlhbGl6aW5nIHVzYg0KPiANCj4gT24gRnJpLCAyMDEyLTAyLTE3
IGF0IDA5OjU4ICsxMTAwLCBCZW5qYW1pbiBIZXJyZW5zY2htaWR0IHdyb3RlOg0KPiA+IE9uIFRo
dSwgMjAxMi0wMi0xNiBhdCAxODowMiArMDgwMCwgU2hlbmd6aG91IExpdSB3cm90ZToNCj4gPiA+
IElmIFVTQiBVVE1JIFBIWSBpcyBub3QgZW5hYmxlLCB3cml0aW5nIHRvIHBvcnRzYyByZWdpc3Rl
ciB3aWxsIGxlYWQNCj4gPiA+IHRvIGtlcm5lbCBoYW5nIGR1cmluZyBib290IHVwLg0KPiA+ID4N
Cj4gPiA+IFNpZ25lZC1vZmYtYnk6IFNoZW5nemhvdSBMaXUgPFNoZW5nemhvdS5MaXVAZnJlZXNj
YWxlLmNvbT4NCj4gPiA+IC0tLQ0KPiA+ID4gQXBwbHkgZm9yIG1hc3RlciBicmFuY2ggb2YNCj4g
PiA+IGdpdDovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2YWxk
cy9saW51eC0NCj4gMi42LmdpdA0KPiA+ID4gVGVzdGVkIG9uIFA1MDIwRFMsIHRoZSBpc3N1ZSB3
YXMgcmVwb3J0ZWQgYnkgQmVuamFtaW4gSGVycmVuc2NobWlkdC4NCj4gPg0KPiA+IFRoaXMgZml4
ZXMgdGhlIGhhbmcsIGJ1dCBzYWRseSBkb2Vzbid0IG1ha2UgVVNCIHdvcmsuIEkgbm93IGdldDoN
Cj4gDQo+ICAuLi4vLi4uDQo+IA0KPiBPaywgZm91bmQgdGhlIHByb2JsZW0uDQo+IA0KPiBGaXJz
dCwgdGhlIFNESyBrZXJuZWwgaGFkIGEgZGVsYXkgYWZ0ZXIgc2V0dGluZyB0aGF0IGJpdCwgSSBh
ZGRlZCB0aGF0DQo+IGJhY2sgaW4uIFRoaXMgaXMgbm90IHdoYXQgZml4ZWQgaXQgYnV0IGl0IGxv
b2tzIGxpa2UgdGhlIHJpZ2h0IHRoaW5nIHRvDQo+IGRvLCB0aG91Z2ggcGxlYXNlLCB1c2UgbXNs
ZWVwIHJhdGhlciB0aGFuIHVkZWxheSBoZXJlIGlmIHBvc3NpYmxlIChub3QNCj4gaW4gYXRvbWlj
IGNvbnRleHQpLg0KPiANCj4gVGhlbiwgdGhlIHJlYWwgY3VscHJpdCBpcyAoQ0MnaW5nIEt1bWFy
IGFuZCBTY290dCB0byBmaWd1cmUgb3V0IHdoeSkNCj4gdGhpcyBzdGF0ZW1lbnQ6DQo+IA0KPiAj
aWYgZGVmaW5lZChDT05GSUdfUFBDMzIpICYmICFkZWZpbmVkKENPTkZJR19OT1RfQ09IRVJFTlRf
Q0FDSEUpDQo+IAkvKg0KPiAJICogVHVybiBvbiBjYWNoZSBzbm9vcGluZyBoYXJkd2FyZSwgc2lu
Y2Ugc29tZSBQb3dlclBDIHBsYXRmb3Jtcw0KPiAJICogd2hvbGx5IHJlbHkgb24gaGFyZHdhcmUg
dG8gZGVhbCB3aXRoIGNhY2hlIGNvaGVyZW50DQo+IAkgKi8NCj4gDQo+IAkvKiBTZXR1cCBTbm9v
cGluZyBmb3IgYWxsIHRoZSA0R0Igc3BhY2UgKi8NCj4gCS8qIFNOT09QMSBzdGFydHMgZnJvbSAw
eDAsIHNpemUgMkcgKi8NCj4gCW91dF9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19VU0JfU05PT1Ax
LCAweDAgfCBTTk9PUF9TSVpFXzJHQik7DQo+IAkvKiBTTk9PUDIgc3RhcnRzIGZyb20gMHg4MDAw
MDAwMCwgc2l6ZSAyRyAqLw0KPiAJb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9TTk9P
UDIsIDB4ODAwMDAwMDAgfA0KPiBTTk9PUF9TSVpFXzJHQik7ICNlbmRpZg0KPiANCj4gSSdtIGJ1
aWxkaW5nIGEgNjQtYml0IGtlcm5lbCBzbyB0aGlzIGlzbid0IGNvbXBpbGVkIGFuZCBpdCBsb29r
cyBsaWtlDQo+IHRoZSBFSENJIGlzIHRodXMgbm90IHNub29waW5nLg0KPiANCj4gQnkgcmVtb3Zp
bmcgdGhlIGRlZmluZWQoQ09ORklHX1BQQzMyKSBwYXJ0IG9mIHRoZSBzdGF0ZW1lbnQsIG15IHBy
b2JsZW0NCj4gZ29lcyBhd2F5Lg0KPiANCj4gQ2hlZXJzLA0KPiBCZW4uDQo+IA0KPiANCg0KW1No
ZW5nemhvdV0gSSB0ZXN0ZWQgdGhlIHBhdGNoIHdpdGggMzJiaXQgUDUwMjBEUywgVVNCIHdvcmtl
ZCB3ZWxsLiBOb3QgdGVzdGVkIHdpdGggNjQtYml0IGtlcm5lbC4NCkdsYWQgdG8geW91IGhhZCBm
b3VuZCB0aGUgcHJvYmxlbSBpbiBjYXNlIG9mIDY0LWJpdCwgdGhhbmtzIQ0K
^ permalink raw reply
* Re: [PATCH v4 2/3] KVM: PPC: epapr: Add idle hcall support for host
From: Alexander Graf @ 2012-02-17 2:20 UTC (permalink / raw)
To: Liu Yu-B13201
Cc: <linuxppc-dev@ozlabs.org>, <kvm@vger.kernel.org>,
<kvm-ppc@vger.kernel.org>, Wood Scott-B07421
In-Reply-To: <4CA99838F21AB847ACC344051E2317090571EB39@039-SN2MPN1-022.039d.mgd.msft.net>
On 17.02.2012, at 03:13, Liu Yu-B13201 wrote:
>=20
>=20
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Thursday, February 16, 2012 6:20 PM
>> To: Liu Yu-B13201
>> Cc: <kvm-ppc@vger.kernel.org>; <kvm@vger.kernel.org>; <linuxppc-
>> dev@ozlabs.org>; Wood Scott-B07421; Liu Yu-B13201
>> Subject: Re: [PATCH v4 2/3] KVM: PPC: epapr: Add idle hcall support =
for
>> host
>>=20
>>=20
>>=20
>> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>>=20
>>> And add a new flag definition in kvm_ppc_pvinfo to indicate whether
>>> host support EV_IDLE hcall.
>>>=20
>>> Signed-off-by: Liu Yu <yu.liu@freescale.com>
>>> ---
>>> v4:
>>> no change
>>>=20
>>> arch/powerpc/include/asm/kvm_para.h | 14 ++++++++++++--
>>> arch/powerpc/kvm/powerpc.c | 8 ++++++++
>>> include/linux/kvm.h | 2 ++
>>> 3 files changed, 22 insertions(+), 2 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/include/asm/kvm_para.h
>>> b/arch/powerpc/include/asm/kvm_para.h
>>> index 7b754e7..81a34c9 100644
>>> --- a/arch/powerpc/include/asm/kvm_para.h
>>> +++ b/arch/powerpc/include/asm/kvm_para.h
>>> @@ -75,9 +75,19 @@ struct kvm_vcpu_arch_shared { };
>>>=20
>>> #define KVM_SC_MAGIC_R0 0x4b564d21 /* "KVM!" */
>>> -#define HC_VENDOR_KVM (42 << 16)
>>> +
>>> +#include <asm/epapr_hcalls.h>
>>> +
>>> +/* ePAPR Hypercall Vendor ID */
>>> +#define HC_VENDOR_EPAPR (EV_EPAPR_VENDOR_ID << 16)
>>> +#define HC_VENDOR_KVM (EV_KVM_VENDOR_ID << 16)
>>> +
>>> +/* ePAPR Hypercall Token */
>>> +#define HC_EV_IDLE EV_IDLE
>>> +
>>> +/* ePAPR Hypercall Return Codes */
>>> #define HC_EV_SUCCESS 0
>>> -#define HC_EV_UNIMPLEMENTED 12
>>> +#define HC_EV_UNIMPLEMENTED EV_UNIMPLEMENTED
>>>=20
>>> #define KVM_FEATURE_MAGIC_PAGE 1
>>>=20
>>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>>> index 0e21d15..03ebd5d 100644
>>> --- a/arch/powerpc/kvm/powerpc.c
>>> +++ b/arch/powerpc/kvm/powerpc.c
>>> @@ -81,6 +81,10 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu)
>>>=20
>>> /* Second return value is in r4 */
>>> break;
>>> + case HC_VENDOR_EPAPR | HC_EV_IDLE:
>>> + r =3D HC_EV_SUCCESS;
>>> + kvm_vcpu_block(vcpu);
>>> + break;
>>> default:
>>> r =3D HC_EV_UNIMPLEMENTED;
>>> break;
>>> @@ -746,6 +750,10 @@ static int kvm_vm_ioctl_get_pvinfo(struct
>> kvm_ppc_pvinfo *pvinfo)
>>> pvinfo->hcall[2] =3D inst_sc;
>>> pvinfo->hcall[3] =3D inst_nop;
>>>=20
>>> +#ifdef CONFIG_BOOKE
>>> + pvinfo->flags |=3D KVM_PPC_PVINFO_FLAGS_EV_IDLE; #endif
>>> +
>>> return 0;
>>> }>=20
>>=20
>> Why limit it to booke? The less ifdefs our code has, the better :)
>=20
> The code here tells userspace that kvm support ev_idle.
> But I'm not sure if the ev_idle code works for other platforms.
>=20
> So I think we should keep the ifdef until other platform test the code =
:)
But the implementation is in generic code and is not #ifdef'ed, so a =
guest could still call it just fine. It looks simple enough to work =
without major testing on different platforms, so I'd say just expose it =
and be done :)
Alex
^ permalink raw reply
* RE: [PATCH v4 2/3] KVM: PPC: epapr: Add idle hcall support for host
From: Liu Yu-B13201 @ 2012-02-17 2:13 UTC (permalink / raw)
To: Alexander Graf
Cc: <linuxppc-dev@ozlabs.org>, <kvm@vger.kernel.org>,
<kvm-ppc@vger.kernel.org>, Wood Scott-B07421
In-Reply-To: <F0023B33-6AF3-4805-B50E-2ED285F8B1B0@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, February 16, 2012 6:20 PM
> To: Liu Yu-B13201
> Cc: <kvm-ppc@vger.kernel.org>; <kvm@vger.kernel.org>; <linuxppc-
> dev@ozlabs.org>; Wood Scott-B07421; Liu Yu-B13201
> Subject: Re: [PATCH v4 2/3] KVM: PPC: epapr: Add idle hcall support for
> host
>=20
>=20
>=20
> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>=20
> > And add a new flag definition in kvm_ppc_pvinfo to indicate whether
> > host support EV_IDLE hcall.
> >
> > Signed-off-by: Liu Yu <yu.liu@freescale.com>
> > ---
> > v4:
> > no change
> >
> > arch/powerpc/include/asm/kvm_para.h | 14 ++++++++++++--
> > arch/powerpc/kvm/powerpc.c | 8 ++++++++
> > include/linux/kvm.h | 2 ++
> > 3 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_para.h
> > b/arch/powerpc/include/asm/kvm_para.h
> > index 7b754e7..81a34c9 100644
> > --- a/arch/powerpc/include/asm/kvm_para.h
> > +++ b/arch/powerpc/include/asm/kvm_para.h
> > @@ -75,9 +75,19 @@ struct kvm_vcpu_arch_shared { };
> >
> > #define KVM_SC_MAGIC_R0 0x4b564d21 /* "KVM!" */
> > -#define HC_VENDOR_KVM (42 << 16)
> > +
> > +#include <asm/epapr_hcalls.h>
> > +
> > +/* ePAPR Hypercall Vendor ID */
> > +#define HC_VENDOR_EPAPR (EV_EPAPR_VENDOR_ID << 16)
> > +#define HC_VENDOR_KVM (EV_KVM_VENDOR_ID << 16)
> > +
> > +/* ePAPR Hypercall Token */
> > +#define HC_EV_IDLE EV_IDLE
> > +
> > +/* ePAPR Hypercall Return Codes */
> > #define HC_EV_SUCCESS 0
> > -#define HC_EV_UNIMPLEMENTED 12
> > +#define HC_EV_UNIMPLEMENTED EV_UNIMPLEMENTED
> >
> > #define KVM_FEATURE_MAGIC_PAGE 1
> >
> > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> > index 0e21d15..03ebd5d 100644
> > --- a/arch/powerpc/kvm/powerpc.c
> > +++ b/arch/powerpc/kvm/powerpc.c
> > @@ -81,6 +81,10 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu)
> >
> > /* Second return value is in r4 */
> > break;
> > + case HC_VENDOR_EPAPR | HC_EV_IDLE:
> > + r =3D HC_EV_SUCCESS;
> > + kvm_vcpu_block(vcpu);
> > + break;
> > default:
> > r =3D HC_EV_UNIMPLEMENTED;
> > break;
> > @@ -746,6 +750,10 @@ static int kvm_vm_ioctl_get_pvinfo(struct
> kvm_ppc_pvinfo *pvinfo)
> > pvinfo->hcall[2] =3D inst_sc;
> > pvinfo->hcall[3] =3D inst_nop;
> >
> > +#ifdef CONFIG_BOOKE
> > + pvinfo->flags |=3D KVM_PPC_PVINFO_FLAGS_EV_IDLE; #endif
> > +
> > return 0;
> > }>=20
>
> Why limit it to booke? The less ifdefs our code has, the better :)
The code here tells userspace that kvm support ev_idle.
But I'm not sure if the ev_idle code works for other platforms.
So I think we should keep the ifdef until other platform test the code :)
Thanks,
Yu
^ permalink raw reply
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Liu Qiang-B32616 @ 2012-02-17 1:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329439216.2892.36.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDE3LCAyMDEyIDg6NDAgQU0NCj4gVG86IExpdSBRaWFuZy1CMzI2MTYNCj4gQ2M6IGpn
YXJ6aWtAcG9ib3guY29tOyBsaW51eC1pZGVAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy0NCj4g
ZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4gU3Vi
amVjdDogUmU6IFtQQVRDSCBWMiBSRVNFTkRdIGZzbC1zYXRhOiBJL08gbG9hZCBiYWxhbmNpbmcN
Cj4gDQo+IE9uIFdlZCwgMjAxMi0wMi0xNSBhdCAxMzo0OSArMDgwMCwgUWlhbmcgTGl1IHdyb3Rl
Og0KPiBdDQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvYXRhL3NhdGFfZnNsLmMgYi9kcml2ZXJz
L2F0YS9zYXRhX2ZzbC5jIGluZGV4DQo+ID4gMDEyMGIwZC4uZDY1NzdiOSAxMDA2NDQNCj4gPiAt
LS0gYS9kcml2ZXJzL2F0YS9zYXRhX2ZzbC5jDQo+ID4gKysrIGIvZHJpdmVycy9hdGEvc2F0YV9m
c2wuYw0KPiA+IEBAIC02LDcgKzYsNyBAQA0KPiA+ICAgKiBBdXRob3I6IEFzaGlzaCBLYWxyYSA8
YXNoaXNoLmthbHJhQGZyZWVzY2FsZS5jb20+DQo+ID4gICAqIExpIFlhbmcgPGxlb2xpQGZyZWVz
Y2FsZS5jb20+DQo+ID4gICAqDQo+ID4gLSAqIENvcHlyaWdodCAoYykgMjAwNi0yMDA3LCAyMDEx
IEZyZWVzY2FsZSBTZW1pY29uZHVjdG9yLCBJbmMuDQo+ID4gKyAqIENvcHlyaWdodCAoYykgMjAw
Ni0yMDA3LCAyMDExLTIwMTIgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IsIEluYy4NCj4gPiAgICoN
Cj4gPiAgICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlICBpdCBhbmQvb3INCj4gbW9kaWZ5IGl0DQo+ID4gICAqIHVuZGVyICB0aGUgdGVybXMgb2Yg
IHRoZSBHTlUgR2VuZXJhbCAgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkDQo+ID4gYnkgdGhl
IEBAIC0yNiw2ICsyNiwxNSBAQCAgI2luY2x1ZGUgPGFzbS9pby5oPiAgI2luY2x1ZGUNCj4gPiA8
bGludXgvb2ZfcGxhdGZvcm0uaD4NCj4gPg0KPiA+ICtzdGF0aWMgdW5zaWduZWQgaW50IGludHJf
Y29hbGVzY2luZ19jb3VudDsNCj4gPiArbW9kdWxlX3BhcmFtKGludHJfY29hbGVzY2luZ19jb3Vu
dCwgaW50LCBTX0lSVUdPKTsNCj4gPiArTU9EVUxFX1BBUk1fREVTQyhpbnRyX2NvYWxlc2Npbmdf
Y291bnQsDQo+ID4gKwkJCQkgIklOVCBjb2FsZXNjaW5nIGNvdW50IHRocmVzaG9sZCAoMS4uMzEp
Iik7DQo+ID4gKw0KPiA+ICtzdGF0aWMgdW5zaWduZWQgaW50IGludHJfY29hbGVzY2luZ190aWNr
czsNCj4gPiArbW9kdWxlX3BhcmFtKGludHJfY29hbGVzY2luZ190aWNrcywgaW50LCBTX0lSVUdP
KTsNCj4gPiArTU9EVUxFX1BBUk1fREVTQyhpbnRyX2NvYWxlc2NpbmdfdGlja3MsDQo+ID4gKwkJ
CQkgIklOVCBjb2FsZXNjaW5nIHRpbWVyIHRocmVzaG9sZCBpbiBBSEIgdGlja3MiKTsNCj4gDQo+
IFlvdSBkb24ndCBzZWVtIHRvIHByb3ZpZGUgdmVyeSB1c2VmdWwgZGVmYXVsdHMuLi4gZm9yIGV4
YW1wbGUsDQo+IGludHJfY29hbGVzY2luZ19jb3VudCBzdGFydHMgYXQgMCB3aGljaCBpc24ndCBl
dmVuIGluIHJhbmdlICh0aGUgY29kZQ0KPiBmaXhlcyB0aGF0IHVwIGJ1dCBzdGlsbC4uLikuDQo+
IA0KPiBJIHRyaWVkIGEgZGViaWFuIGluc3RhbGwgb24gdGhlIHA1MDIwZHMgaGVyZSBhbmQgSSBm
aW5kIFNBVEEgdG8gYmUNCj4gZXh0cmVtZWx5IHNsb3csIGdlbmVyYXRpbmcgbWlsbGlvbnMgb2Yg
aW50ZXJydXB0cy4gSSB0aGluayB0aGUgZGVmYXVsdHMNCj4gc2hvdWxkIGJlIGEgbG90IG1vcmUg
YWdncmVzc2l2ZSBhdCBjb2FsZXNjaW5nLg0KDQpIZWxsbyBCZW4sDQoNClRoZSBkZWZhdWx0IHdp
bGwgYmUgc2V0IGluIGEgY29tbW9uIGludGVyZmFjZSBmc2xfc2F0YV9zZXRfaXJxX2NvYWxlc2Np
bmcgd2hlbg0KaW5pdGlhbGl6ZSB0aGUgY29udHJvbGxlci4gVGhpcyBpbnRlcmZhY2Ugd2lsbCBj
aGVjayB0aGUgcmFuZ2Ugb2YgaW50ciBjb3VudA0KYW5kIHRpY2tzIGFuZCBtYWtlIHN1cmUgdGhl
IHZhbHVlcyBhcmUgcmVhc29uYWJseS4NCg0KSXQncyBoYXJkIHRvIGZpbmQgYSBhZ2dyZXNzaXZl
IHZhbHVlIHRvIGFkYXB0IGFsbCBzY2VuYXJpb3MsIHNvIEkgdXNlIGVjaG8gdG8gYWRqdXN0DQp0
aGUgdmFsdWUuIEkgcmVtZW1iZXIgUDUwMjAgaGF2ZSBzb21lIHBlcmZvcm1hbmNlIGlzc3VlLCBJ
IHdpbGwgY2hlY2sgaXQuDQpCVFcsIHdoaWNoIGZpbGVzeXN0ZW0gZG8geW91IHVzZT8gRXh0MiBp
cyBsb3dlciB0aGFuIGV4dDQgYmVjYXVzZSBtZXRhZGF0YSBpcyANCmNvbnRpbnVvdXNseSB3cm90
ZSB0byBkaXNrLiBZb3UgY2FuIHRyeSBleHQ0IG9yIHhmcy4NCg0KVGhhbmtzLg0KDQo+IA0KPiBD
aGVlcnMsDQo+IEJlbi4NCj4gDQo+ID4gIC8qIENvbnRyb2xsZXIgaW5mb3JtYXRpb24gKi8NCj4g
PiAgZW51bSB7DQo+ID4gIAlTQVRBX0ZTTF9RVUVVRV9ERVBUSAk9IDE2LA0KPiA+IEBAIC04Myw2
ICs5MiwxNiBAQCBlbnVtIHsNCj4gPiAgfTsNCj4gPg0KPiA+ICAvKg0KPiA+ICsgKiBJbnRlcnJ1
cHQgQ29hbGVzY2luZyBDb250cm9sIFJlZ2lzdGVyIGJpdGRlZnMgICovIGVudW0gew0KPiA+ICsJ
SUNDX01JTl9JTlRfQ09VTlRfVEhSRVNIT0xECT0gMSwNCj4gPiArCUlDQ19NQVhfSU5UX0NPVU5U
X1RIUkVTSE9MRAk9ICgoMSA8PCA1KSAtIDEpLA0KPiA+ICsJSUNDX01JTl9JTlRfVElDS1NfVEhS
RVNIT0xECT0gMCwNCj4gPiArCUlDQ19NQVhfSU5UX1RJQ0tTX1RIUkVTSE9MRAk9ICgoMSA8PCAx
OSkgLSAxKSwNCj4gPiArCUlDQ19TQUZFX0lOVF9USUNLUwkJPSAxLA0KPiA+ICt9Ow0KPiA+ICsN
Cj4gPiArLyoNCj4gPiAgKiBIb3N0IENvbnRyb2xsZXIgY29tbWFuZCByZWdpc3RlciBzZXQgLSBw
ZXIgcG9ydCAgKi8gIGVudW0geyBAQA0KPiA+IC0yNjMsOCArMjgyLDY1IEBAIHN0cnVjdCBzYXRh
X2ZzbF9ob3N0X3ByaXYgew0KPiA+ICAJdm9pZCBfX2lvbWVtICpjc3JfYmFzZTsNCj4gPiAgCWlu
dCBpcnE7DQo+ID4gIAlpbnQgZGF0YV9zbm9vcDsNCj4gPiArCXN0cnVjdCBkZXZpY2VfYXR0cmli
dXRlIGludHJfY29hbGVzY2luZzsNCj4gPiAgfTsNCj4gPg0KPiA+ICtzdGF0aWMgdm9pZCBmc2xf
c2F0YV9zZXRfaXJxX2NvYWxlc2Npbmcoc3RydWN0IGF0YV9ob3N0ICpob3N0LA0KPiA+ICsJCXVu
c2lnbmVkIGludCBjb3VudCwgdW5zaWduZWQgaW50IHRpY2tzKSB7DQo+ID4gKwlzdHJ1Y3Qgc2F0
YV9mc2xfaG9zdF9wcml2ICpob3N0X3ByaXYgPSBob3N0LT5wcml2YXRlX2RhdGE7DQo+ID4gKwl2
b2lkIF9faW9tZW0gKmhjcl9iYXNlID0gaG9zdF9wcml2LT5oY3JfYmFzZTsNCj4gPiArDQo+ID4g
KwlpZiAoY291bnQgPiBJQ0NfTUFYX0lOVF9DT1VOVF9USFJFU0hPTEQpDQo+ID4gKwkJY291bnQg
PSBJQ0NfTUFYX0lOVF9DT1VOVF9USFJFU0hPTEQ7DQo+ID4gKwllbHNlIGlmIChjb3VudCA8IElD
Q19NSU5fSU5UX0NPVU5UX1RIUkVTSE9MRCkNCj4gPiArCQljb3VudCA9IElDQ19NSU5fSU5UX0NP
VU5UX1RIUkVTSE9MRDsNCj4gPiArDQo+ID4gKwlpZiAodGlja3MgPiBJQ0NfTUFYX0lOVF9USUNL
U19USFJFU0hPTEQpDQo+ID4gKwkJdGlja3MgPSBJQ0NfTUFYX0lOVF9USUNLU19USFJFU0hPTEQ7
DQo+ID4gKwllbHNlIGlmICgoSUNDX01JTl9JTlRfVElDS1NfVEhSRVNIT0xEID09IHRpY2tzKSAm
Jg0KPiA+ICsJCQkoY291bnQgPiBJQ0NfTUlOX0lOVF9DT1VOVF9USFJFU0hPTEQpKQ0KPiA+ICsJ
CXRpY2tzID0gSUNDX1NBRkVfSU5UX1RJQ0tTOw0KPiA+ICsNCj4gPiArCXNwaW5fbG9jaygmaG9z
dC0+bG9jayk7DQo+ID4gKwlpb3dyaXRlMzIoKGNvdW50IDw8IDI0IHwgdGlja3MpLCBoY3JfYmFz
ZSArIElDQyk7DQo+ID4gKw0KPiA+ICsJaW50cl9jb2FsZXNjaW5nX2NvdW50ID0gY291bnQ7DQo+
ID4gKwlpbnRyX2NvYWxlc2NpbmdfdGlja3MgPSB0aWNrczsNCj4gPiArCXNwaW5fdW5sb2NrKCZo
b3N0LT5sb2NrKTsNCj4gPiArDQo+ID4gKwlEUFJJTlRLKCJpbnRycnVwdCBjb2FsZXNjaW5nLCBj
b3VudCA9IDB4JXgsIHRpY2tzID0gJXhcbiIsDQo+ID4gKwkJCWludHJfY29hbGVzY2luZ19jb3Vu
dCwgaW50cl9jb2FsZXNjaW5nX3RpY2tzKTsNCj4gPiArCURQUklOVEsoIklDQyByZWdpc3RlciBz
dGF0dXM6IChoY3IgYmFzZTogMHgleCkgPSAweCV4XG4iLA0KPiA+ICsJCQloY3JfYmFzZSwgaW9y
ZWFkMzIoaGNyX2Jhc2UgKyBJQ0MpKTsgfQ0KPiA+ICsNCj4gPiArc3RhdGljIHNzaXplX3QgZnNs
X3NhdGFfaW50cl9jb2FsZXNjaW5nX3Nob3coc3RydWN0IGRldmljZSAqZGV2LA0KPiA+ICsJCXN0
cnVjdCBkZXZpY2VfYXR0cmlidXRlICphdHRyLCBjaGFyICpidWYpIHsNCj4gPiArCXJldHVybiBz
cHJpbnRmKGJ1ZiwgIiVkCSVkXG4iLA0KPiA+ICsJCQlpbnRyX2NvYWxlc2NpbmdfY291bnQsIGlu
dHJfY29hbGVzY2luZ190aWNrcyk7IH0NCj4gPiArDQo+ID4gK3N0YXRpYyBzc2l6ZV90IGZzbF9z
YXRhX2ludHJfY29hbGVzY2luZ19zdG9yZShzdHJ1Y3QgZGV2aWNlICpkZXYsDQo+ID4gKwkJc3Ry
dWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsDQo+ID4gKwkJY29uc3QgY2hhciAqYnVmLCBzaXpl
X3QgY291bnQpDQo+ID4gK3sNCj4gPiArCXVuc2lnbmVkIGludCBjb2FsZXNjaW5nX2NvdW50LAlj
b2FsZXNjaW5nX3RpY2tzOw0KPiA+ICsNCj4gPiArCWlmIChzc2NhbmYoYnVmLCAiJWQlZCIsDQo+
ID4gKwkJCQkmY29hbGVzY2luZ19jb3VudCwNCj4gPiArCQkJCSZjb2FsZXNjaW5nX3RpY2tzKSAh
PSAyKSB7DQo+ID4gKwkJcHJpbnRrKEtFUk5fRVJSICJmc2wtc2F0YTogd3JvbmcgcGFyYW1ldGVy
IGZvcm1hdC5cbiIpOw0KPiA+ICsJCXJldHVybiAtRUlOVkFMOw0KPiA+ICsJfQ0KPiA+ICsNCj4g
PiArCWZzbF9zYXRhX3NldF9pcnFfY29hbGVzY2luZyhkZXZfZ2V0X2RydmRhdGEoZGV2KSwNCj4g
PiArCQkJY29hbGVzY2luZ19jb3VudCwgY29hbGVzY2luZ190aWNrcyk7DQo+ID4gKw0KPiA+ICsJ
cmV0dXJuIHN0cmxlbihidWYpOw0KPiA+ICt9DQo+ID4gKw0KPiA+ICBzdGF0aWMgaW5saW5lIHVu
c2lnbmVkIGludCBzYXRhX2ZzbF90YWcodW5zaWduZWQgaW50IHRhZywNCj4gPiAgCQkJCQl2b2lk
IF9faW9tZW0gKmhjcl9iYXNlKQ0KPiA+ICB7DQo+ID4gQEAgLTM0NiwxMCArNDIyLDEwIEBAIHN0
YXRpYyB1bnNpZ25lZCBpbnQgc2F0YV9mc2xfZmlsbF9zZyhzdHJ1Y3QNCj4gYXRhX3F1ZXVlZF9j
bWQgKnFjLCB2b2lkICpjbWRfZGVzYywNCj4gPiAgCQkJKHVuc2lnbmVkIGxvbmcgbG9uZylzZ19h
ZGRyLCBzZ19sZW4pOw0KPiA+DQo+ID4gIAkJLyogd2FybiBpZiBlYWNoIHMvZyBlbGVtZW50IGlz
IG5vdCBkd29yZCBhbGlnbmVkICovDQo+ID4gLQkJaWYgKHNnX2FkZHIgJiAweDAzKQ0KPiA+ICsJ
CWlmICh1bmxpa2VseShzZ19hZGRyICYgMHgwMykpDQo+ID4gIAkJCWF0YV9wb3J0X2VycihxYy0+
YXAsICJzL2cgYWRkciB1bmFsaWduZWQgOiAweCVsbHhcbiIsDQo+ID4gIAkJCQkgICAgICh1bnNp
Z25lZCBsb25nIGxvbmcpc2dfYWRkcik7DQo+ID4gLQkJaWYgKHNnX2xlbiAmIDB4MDMpDQo+ID4g
KwkJaWYgKHVubGlrZWx5KHNnX2xlbiAmIDB4MDMpKQ0KPiA+ICAJCQlhdGFfcG9ydF9lcnIocWMt
PmFwLCAicy9nIGxlbiB1bmFsaWduZWQgOiAweCV4XG4iLA0KPiA+ICAJCQkJICAgICBzZ19sZW4p
Ow0KPiA+DQo+ID4gQEAgLTEyNDUsNiArMTMyMSwxMyBAQCBzdGF0aWMgaW50IHNhdGFfZnNsX2lu
aXRfY29udHJvbGxlcihzdHJ1Y3QNCj4gYXRhX2hvc3QgKmhvc3QpDQo+ID4gIAlpb3dyaXRlMzIo
MHgwMDAwMEZGRkYsIGhjcl9iYXNlICsgQ0UpOw0KPiA+ICAJaW93cml0ZTMyKDB4MDAwMDBGRkZG
LCBoY3JfYmFzZSArIERFKTsNCj4gPg0KPiA+ICsgCS8qDQo+ID4gKwkgKiByZXNldCB0aGUgbnVt
YmVyIG9mIGNvbW1hbmQgY29tcGxldGUgYml0cyB3aGljaCB3aWxsIGNhdXNlIHRoZQ0KPiA+ICsJ
ICogaW50ZXJydXB0IHRvIGJlIHNpZ25hbGVkDQo+ID4gKwkgKi8NCj4gPiArCWZzbF9zYXRhX3Nl
dF9pcnFfY29hbGVzY2luZyhob3N0LCBpbnRyX2NvYWxlc2NpbmdfY291bnQsDQo+ID4gKwkJCWlu
dHJfY29hbGVzY2luZ190aWNrcyk7DQo+ID4gKw0KPiA+ICAJLyoNCj4gPiAgCSAqIGhvc3QgY29u
dHJvbGxlciB3aWxsIGJlIGJyb3VnaHQgb24tbGluZSwgZHVyaW5nIHh4X3BvcnRfc3RhcnQoKQ0K
PiA+ICAJICogY2FsbGJhY2ssIHRoYXQgc2hvdWxkIGFsc28gaW5pdGlhdGUgdGhlIE9PQiwgQ09N
SU5JVCBzZXF1ZW5jZSBAQA0KPiA+IC0xMzA5LDcgKzEzOTIsNyBAQCBzdGF0aWMgaW50IHNhdGFf
ZnNsX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UNCj4gKm9mZGV2KQ0KPiA+ICAJdm9pZCBf
X2lvbWVtICpjc3JfYmFzZSA9IE5VTEw7DQo+ID4gIAlzdHJ1Y3Qgc2F0YV9mc2xfaG9zdF9wcml2
ICpob3N0X3ByaXYgPSBOVUxMOw0KPiA+ICAJaW50IGlycTsNCj4gPiAtCXN0cnVjdCBhdGFfaG9z
dCAqaG9zdDsNCj4gPiArCXN0cnVjdCBhdGFfaG9zdCAqaG9zdCA9IE5VTEw7DQo+ID4gIAl1MzIg
dGVtcDsNCj4gPg0KPiA+ICAJc3RydWN0IGF0YV9wb3J0X2luZm8gcGkgPSBzYXRhX2ZzbF9wb3J0
X2luZm9bMF07IEBAIC0xMzU2LDYNCj4gKzE0MzksMTANCj4gPiBAQCBzdGF0aWMgaW50IHNhdGFf
ZnNsX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKm9mZGV2KQ0KPiA+DQo+ID4gIAkvKiBh
bGxvY2F0ZSBob3N0IHN0cnVjdHVyZSAqLw0KPiA+ICAJaG9zdCA9IGF0YV9ob3N0X2FsbG9jX3Bp
bmZvKCZvZmRldi0+ZGV2LCBwcGksIFNBVEFfRlNMX01BWF9QT1JUUyk7DQo+ID4gKwlpZiAoIWhv
c3QpIHsNCj4gPiArCQlyZXR2YWwgPSAtRU5PTUVNOw0KPiA+ICsJCWdvdG8gZXJyb3JfZXhpdF93
aXRoX2NsZWFudXA7DQo+ID4gKwl9DQo+ID4NCj4gPiAgCS8qIGhvc3QtPmlvbWFwIGlzIG5vdCB1
c2VkIGN1cnJlbnRseSAqLw0KPiA+ICAJaG9zdC0+cHJpdmF0ZV9kYXRhID0gaG9zdF9wcml2Ow0K
PiA+IEBAIC0xMzczLDEwICsxNDYwLDI0IEBAIHN0YXRpYyBpbnQgc2F0YV9mc2xfcHJvYmUoc3Ry
dWN0DQo+ID4gcGxhdGZvcm1fZGV2aWNlICpvZmRldikNCj4gPg0KPiA+ICAJZGV2X3NldF9kcnZk
YXRhKCZvZmRldi0+ZGV2LCBob3N0KTsNCj4gPg0KPiA+ICsJaG9zdF9wcml2LT5pbnRyX2NvYWxl
c2Npbmcuc2hvdyA9IGZzbF9zYXRhX2ludHJfY29hbGVzY2luZ19zaG93Ow0KPiA+ICsJaG9zdF9w
cml2LT5pbnRyX2NvYWxlc2Npbmcuc3RvcmUgPSBmc2xfc2F0YV9pbnRyX2NvYWxlc2Npbmdfc3Rv
cmU7DQo+ID4gKwlzeXNmc19hdHRyX2luaXQoJmhvc3RfcHJpdi0+aW50cl9jb2FsZXNjaW5nLmF0
dHIpOw0KPiA+ICsJaG9zdF9wcml2LT5pbnRyX2NvYWxlc2NpbmcuYXR0ci5uYW1lID0gImludHJf
Y29hbGVzY2luZyI7DQo+ID4gKwlob3N0X3ByaXYtPmludHJfY29hbGVzY2luZy5hdHRyLm1vZGUg
PSBTX0lSVUdPIHwgU19JV1VTUjsNCj4gPiArCXJldHZhbCA9IGRldmljZV9jcmVhdGVfZmlsZSho
b3N0LT5kZXYsICZob3N0X3ByaXYtPmludHJfY29hbGVzY2luZyk7DQo+ID4gKwlpZiAocmV0dmFs
KQ0KPiA+ICsJCWdvdG8gZXJyb3JfZXhpdF93aXRoX2NsZWFudXA7DQo+ID4gKw0KPiA+ICAJcmV0
dXJuIDA7DQo+ID4NCj4gPiAgZXJyb3JfZXhpdF93aXRoX2NsZWFudXA6DQo+ID4NCj4gPiArCWlm
IChob3N0KSB7DQo+ID4gKwkJZGV2X3NldF9kcnZkYXRhKCZvZmRldi0+ZGV2LCBOVUxMKTsNCj4g
PiArCQlhdGFfaG9zdF9kZXRhY2goaG9zdCk7DQo+ID4gKwl9DQo+ID4gKw0KPiA+ICAJaWYgKGhj
cl9iYXNlKQ0KPiA+ICAJCWlvdW5tYXAoaGNyX2Jhc2UpOw0KPiA+ICAJaWYgKGhvc3RfcHJpdikN
Cj4gPiBAQCAtMTM5MCw2ICsxNDkxLDggQEAgc3RhdGljIGludCBzYXRhX2ZzbF9yZW1vdmUoc3Ry
dWN0IHBsYXRmb3JtX2RldmljZQ0KPiAqb2ZkZXYpDQo+ID4gIAlzdHJ1Y3QgYXRhX2hvc3QgKmhv
c3QgPSBkZXZfZ2V0X2RydmRhdGEoJm9mZGV2LT5kZXYpOw0KPiA+ICAJc3RydWN0IHNhdGFfZnNs
X2hvc3RfcHJpdiAqaG9zdF9wcml2ID0gaG9zdC0+cHJpdmF0ZV9kYXRhOw0KPiA+DQo+ID4gKwlk
ZXZpY2VfcmVtb3ZlX2ZpbGUoJm9mZGV2LT5kZXYsICZob3N0X3ByaXYtPmludHJfY29hbGVzY2lu
Zyk7DQo+ID4gKw0KPiA+ICAJYXRhX2hvc3RfZGV0YWNoKGhvc3QpOw0KPiA+DQo+ID4gIAlkZXZf
c2V0X2RydmRhdGEoJm9mZGV2LT5kZXYsIE5VTEwpOw0KPiA+IC0tDQo+ID4gMS42LjQNCj4gPg0K
PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gPiBMaW51eHBwYy1kZXYgbWFpbGluZyBsaXN0DQo+ID4gTGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcNCj4gPiBodHRwczovL2xpc3RzLm96bGFicy5vcmcvbGlzdGluZm8vbGludXhwcGMt
ZGV2DQo+IA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Kumar Gala @ 2012-02-17 1:27 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1329394210-1014-1-git-send-email-leoli@freescale.com>
On Feb 16, 2012, at 6:10 AM, Li Yang wrote:
> Fix the problem that large physical address support cannot be
> disabled when some platforms which only provides 36-bit support
> are selected. According to the philosophy of kernel config
> enabling a platform support doesn't mean the kernel is only
> running on that platform. Remove the auto selection of PHYS_64BIT
> option for these platforms. They will need to use a 36bit default
> config that selects PHYS_64BIT explicitly.
>=20
> The reason why we need to keep PHYS_64BIT option configurable is
> that enabling it cause negative performance impact on various
> aspects like TLB miss and physical address manipulating. We should
> not enable it unless really needed, e.g. use large memory of 4GB
> or bigger.
>=20
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
Nak, this isn't correct.
For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & =
P5020DS only a 36-bit physical address map is supported by u-boot and =
the device tree. This was a decision that was made to NOT support =
32-bit address map for these boards and accept the performance =
implication of it to reduce the # of builds, etc.
Additionally, outside of maybe P2041RDB I believe the majority of these =
boards ship with 4G of DDR (but that off the top of my head) and thus =
require the 36-bit / PHYS_64BIT support to be enabled.
- k
^ permalink raw reply
* Re: 5020 SATA fix
From: Kumar Gala @ 2012-02-17 1:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Xulei, linuxppc-dev
In-Reply-To: <1329438578.2892.34.camel@pasglop>
On Feb 16, 2012, at 6:29 PM, Benjamin Herrenschmidt wrote:
> Hi Lei !
>=20
> In your SDK kernel I see this commit:
>=20
> 92c0ce1e599e788ffc0908739db9bd5e0dbdad69
> sata_fsl: Add the workaround for SATA-A005 erratum on =
P2040/P3041/P5020
>=20
> Without this commit, SATA doesn't work on the p5020ds board that FSL
> just sent me. I see this was committed in June last year, any reason =
why
> this is not upstream yet ?
>=20
> Any objection to me just sending it upstream ?
>=20
> Cheers,
> Ben.
>=20
In general we've avoided sending erratum fixes for non-production =
silicon upstream.
- k
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-02-17 0:57 UTC (permalink / raw)
To: Timur Tabi; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F3D5D84.2040609@freescale.com>
On Thu, Feb 16, 2012 at 01:48:20PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
>
> > No. I don't have the ability to connect my P2020 up to an FPGA to
> > recreate the DMA workload that causes this on my 8349EA. I can run the
> > dmatest module, if you'd like.
>
> I just want to make sure your patch doesn't break 85xx.
>
I tried both with and without this patch on my P2020 COM Express board.
With both kernels, the board locks up after 20 minutes or so, no
messages to the serial console.
I wouldn't be surprised if there are some memory problems with this
board. In any case, I don't have any reason to believe that this patch
causes any trouble: the board dies without it.
However, the patch doesn't break DMA on 85xx. If I unload the dmatest
module after 10 minutes or so, it claims to have passed many thousands
of tests without problems.
My 8349EA test boards (15 of them) have been running their normal DMA
workload plus dmatest on the unused 4th channel, all without errors, for
several hours. ~2.5 million successful tests per board, as I write this.
Ira
^ permalink raw reply
* Re: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Benjamin Herrenschmidt @ 2012-02-17 0:40 UTC (permalink / raw)
To: Qiang Liu; +Cc: linux-ide, jgarzik, linuxppc-dev, linux-kernel
In-Reply-To: <1329284944-17943-1-git-send-email-qiang.liu@freescale.com>
On Wed, 2012-02-15 at 13:49 +0800, Qiang Liu wrote:
]
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
> index 0120b0d..d6577b9 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -6,7 +6,7 @@
> * Author: Ashish Kalra <ashish.kalra@freescale.com>
> * Li Yang <leoli@freescale.com>
> *
> - * Copyright (c) 2006-2007, 2011 Freescale Semiconductor, Inc.
> + * Copyright (c) 2006-2007, 2011-2012 Freescale Semiconductor, 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
> @@ -26,6 +26,15 @@
> #include <asm/io.h>
> #include <linux/of_platform.h>
>
> +static unsigned int intr_coalescing_count;
> +module_param(intr_coalescing_count, int, S_IRUGO);
> +MODULE_PARM_DESC(intr_coalescing_count,
> + "INT coalescing count threshold (1..31)");
> +
> +static unsigned int intr_coalescing_ticks;
> +module_param(intr_coalescing_ticks, int, S_IRUGO);
> +MODULE_PARM_DESC(intr_coalescing_ticks,
> + "INT coalescing timer threshold in AHB ticks");
You don't seem to provide very useful defaults... for example,
intr_coalescing_count starts at 0 which isn't even in range
(the code fixes that up but still...).
I tried a debian install on the p5020ds here and I find SATA to be
extremely slow, generating millions of interrupts. I think the defaults
should be a lot more aggressive at coalescing.
Cheers,
Ben.
> /* Controller information */
> enum {
> SATA_FSL_QUEUE_DEPTH = 16,
> @@ -83,6 +92,16 @@ enum {
> };
>
> /*
> + * Interrupt Coalescing Control Register bitdefs */
> +enum {
> + ICC_MIN_INT_COUNT_THRESHOLD = 1,
> + ICC_MAX_INT_COUNT_THRESHOLD = ((1 << 5) - 1),
> + ICC_MIN_INT_TICKS_THRESHOLD = 0,
> + ICC_MAX_INT_TICKS_THRESHOLD = ((1 << 19) - 1),
> + ICC_SAFE_INT_TICKS = 1,
> +};
> +
> +/*
> * Host Controller command register set - per port
> */
> enum {
> @@ -263,8 +282,65 @@ struct sata_fsl_host_priv {
> void __iomem *csr_base;
> int irq;
> int data_snoop;
> + struct device_attribute intr_coalescing;
> };
>
> +static void fsl_sata_set_irq_coalescing(struct ata_host *host,
> + unsigned int count, unsigned int ticks)
> +{
> + struct sata_fsl_host_priv *host_priv = host->private_data;
> + void __iomem *hcr_base = host_priv->hcr_base;
> +
> + if (count > ICC_MAX_INT_COUNT_THRESHOLD)
> + count = ICC_MAX_INT_COUNT_THRESHOLD;
> + else if (count < ICC_MIN_INT_COUNT_THRESHOLD)
> + count = ICC_MIN_INT_COUNT_THRESHOLD;
> +
> + if (ticks > ICC_MAX_INT_TICKS_THRESHOLD)
> + ticks = ICC_MAX_INT_TICKS_THRESHOLD;
> + else if ((ICC_MIN_INT_TICKS_THRESHOLD == ticks) &&
> + (count > ICC_MIN_INT_COUNT_THRESHOLD))
> + ticks = ICC_SAFE_INT_TICKS;
> +
> + spin_lock(&host->lock);
> + iowrite32((count << 24 | ticks), hcr_base + ICC);
> +
> + intr_coalescing_count = count;
> + intr_coalescing_ticks = ticks;
> + spin_unlock(&host->lock);
> +
> + DPRINTK("intrrupt coalescing, count = 0x%x, ticks = %x\n",
> + intr_coalescing_count, intr_coalescing_ticks);
> + DPRINTK("ICC register status: (hcr base: 0x%x) = 0x%x\n",
> + hcr_base, ioread32(hcr_base + ICC));
> +}
> +
> +static ssize_t fsl_sata_intr_coalescing_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d %d\n",
> + intr_coalescing_count, intr_coalescing_ticks);
> +}
> +
> +static ssize_t fsl_sata_intr_coalescing_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + unsigned int coalescing_count, coalescing_ticks;
> +
> + if (sscanf(buf, "%d%d",
> + &coalescing_count,
> + &coalescing_ticks) != 2) {
> + printk(KERN_ERR "fsl-sata: wrong parameter format.\n");
> + return -EINVAL;
> + }
> +
> + fsl_sata_set_irq_coalescing(dev_get_drvdata(dev),
> + coalescing_count, coalescing_ticks);
> +
> + return strlen(buf);
> +}
> +
> static inline unsigned int sata_fsl_tag(unsigned int tag,
> void __iomem *hcr_base)
> {
> @@ -346,10 +422,10 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
> (unsigned long long)sg_addr, sg_len);
>
> /* warn if each s/g element is not dword aligned */
> - if (sg_addr & 0x03)
> + if (unlikely(sg_addr & 0x03))
> ata_port_err(qc->ap, "s/g addr unaligned : 0x%llx\n",
> (unsigned long long)sg_addr);
> - if (sg_len & 0x03)
> + if (unlikely(sg_len & 0x03))
> ata_port_err(qc->ap, "s/g len unaligned : 0x%x\n",
> sg_len);
>
> @@ -1245,6 +1321,13 @@ static int sata_fsl_init_controller(struct ata_host *host)
> iowrite32(0x00000FFFF, hcr_base + CE);
> iowrite32(0x00000FFFF, hcr_base + DE);
>
> + /*
> + * reset the number of command complete bits which will cause the
> + * interrupt to be signaled
> + */
> + fsl_sata_set_irq_coalescing(host, intr_coalescing_count,
> + intr_coalescing_ticks);
> +
> /*
> * host controller will be brought on-line, during xx_port_start()
> * callback, that should also initiate the OOB, COMINIT sequence
> @@ -1309,7 +1392,7 @@ static int sata_fsl_probe(struct platform_device *ofdev)
> void __iomem *csr_base = NULL;
> struct sata_fsl_host_priv *host_priv = NULL;
> int irq;
> - struct ata_host *host;
> + struct ata_host *host = NULL;
> u32 temp;
>
> struct ata_port_info pi = sata_fsl_port_info[0];
> @@ -1356,6 +1439,10 @@ static int sata_fsl_probe(struct platform_device *ofdev)
>
> /* allocate host structure */
> host = ata_host_alloc_pinfo(&ofdev->dev, ppi, SATA_FSL_MAX_PORTS);
> + if (!host) {
> + retval = -ENOMEM;
> + goto error_exit_with_cleanup;
> + }
>
> /* host->iomap is not used currently */
> host->private_data = host_priv;
> @@ -1373,10 +1460,24 @@ static int sata_fsl_probe(struct platform_device *ofdev)
>
> dev_set_drvdata(&ofdev->dev, host);
>
> + host_priv->intr_coalescing.show = fsl_sata_intr_coalescing_show;
> + host_priv->intr_coalescing.store = fsl_sata_intr_coalescing_store;
> + sysfs_attr_init(&host_priv->intr_coalescing.attr);
> + host_priv->intr_coalescing.attr.name = "intr_coalescing";
> + host_priv->intr_coalescing.attr.mode = S_IRUGO | S_IWUSR;
> + retval = device_create_file(host->dev, &host_priv->intr_coalescing);
> + if (retval)
> + goto error_exit_with_cleanup;
> +
> return 0;
>
> error_exit_with_cleanup:
>
> + if (host) {
> + dev_set_drvdata(&ofdev->dev, NULL);
> + ata_host_detach(host);
> + }
> +
> if (hcr_base)
> iounmap(hcr_base);
> if (host_priv)
> @@ -1390,6 +1491,8 @@ static int sata_fsl_remove(struct platform_device *ofdev)
> struct ata_host *host = dev_get_drvdata(&ofdev->dev);
> struct sata_fsl_host_priv *host_priv = host->private_data;
>
> + device_remove_file(&ofdev->dev, &host_priv->intr_coalescing);
> +
> ata_host_detach(host);
>
> dev_set_drvdata(&ofdev->dev, NULL);
> --
> 1.6.4
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* 5020 SATA fix
From: Benjamin Herrenschmidt @ 2012-02-17 0:29 UTC (permalink / raw)
To: Xulei; +Cc: linuxppc-dev
Hi Lei !
In your SDK kernel I see this commit:
92c0ce1e599e788ffc0908739db9bd5e0dbdad69
sata_fsl: Add the workaround for SATA-A005 erratum on P2040/P3041/P5020
Without this commit, SATA doesn't work on the p5020ds board that FSL
just sent me. I see this was committed in June last year, any reason why
this is not upstream yet ?
Any objection to me just sending it upstream ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Benjamin Herrenschmidt @ 2012-02-17 0:02 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329433132.2892.30.camel@pasglop>
On Fri, 2012-02-17 at 09:58 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-02-16 at 18:02 +0800, Shengzhou Liu wrote:
> > If USB UTMI PHY is not enable, writing to portsc register will lead to
> > kernel hang during boot up.
> >
> > Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> > ---
> > Apply for master branch of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > Tested on P5020DS, the issue was reported by Benjamin Herrenschmidt.
>
> This fixes the hang, but sadly doesn't make USB work. I now get:
.../...
Ok, found the problem.
First, the SDK kernel had a delay after setting that bit, I added that
back in. This is not what fixed it but it looks like the right thing to
do, though please, use msleep rather than udelay here if possible (not
in atomic context).
Then, the real culprit is (CC'ing Kumar and Scott to figure out why)
this statement:
#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
/*
* Turn on cache snooping hardware, since some PowerPC platforms
* wholly rely on hardware to deal with cache coherent
*/
/* Setup Snooping for all the 4GB space */
/* SNOOP1 starts from 0x0, size 2G */
out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
/* SNOOP2 starts from 0x80000000, size 2G */
out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
#endif
I'm building a 64-bit kernel so this isn't compiled and it looks like
the EHCI is thus not snooping.
By removing the defined(CONFIG_PPC32) part of the statement, my problem
goes away.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 00/27] irq_domain generalization and rework
From: Russell King - ARM Linux @ 2012-02-16 23:26 UTC (permalink / raw)
To: Andrew Morton
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120216145219.0f1c1b98.akpm@linux-foundation.org>
On Thu, Feb 16, 2012 at 02:52:19PM -0800, Andrew Morton wrote:
> On Thu, 16 Feb 2012 02:09:01 -0700
> Grant Likely <grant.likely@secretlab.ca> wrote:
> > This series generalizes the "irq_host" infrastructure from powerpc
> > so that it can be used by all architectures and renames it to "irq_domain".
>
> drivers/mfd/twl-core.c is fairly horked on i386 allmodconfig:
>
> drivers/mfd/twl-core.c: In function 'twl_probe':
> drivers/mfd/twl-core.c:1218: error: implicit declaration of function 'irq_alloc_descs'
> drivers/mfd/twl-core.c:1226: error: implicit declaration of function 'irq_domain_add_legacy'
> drivers/mfd/twl-core.c:1227: error: 'irq_domain_simple_ops' undeclared (first use in this function)
> drivers/mfd/twl-core.c:1227: error: (Each undeclared identifier is reported only once
> drivers/mfd/twl-core.c:1227: error: for each function it appears in.)
>
> This is today's linux-next so it has rmk's "ARM: omap: fix broken
> twl-core dependencies and ifdefs" in there, which looks like it
> attempts to repair this stuff.
Yes, you're the third to report this breakage.
Grant's response on Tuesday over this was:
| This is irq_domain related. It's related to an API change. I'm
| tracking to get it solved, either by moving the twl commit into the
| irqdomain branch or by deferring the api change to v3.5.
|
| I've also got a patch that converts x86 over to the new api, but I
| don't have sufficient review to put it into the irqdomain tree yet.
> btw, Russell, regarding this comment in include/linux/irq.h:
>
> /*
> * Please do not include this file in generic code. There is currently
> * no requirement for any architecture to implement anything held
> * within this file.
> *
> * Thanks. --rmk
> */
>
> A quick grep indicates that we've lost this battle ;) Is the comments
> still true? Should we stop discouraging inclusion of linux/irq.h?
> Does anyone even know that it's discouraged ;)
It's still true for any platform which hasn't been converted to genirq,
as such a platform would not have asm/hw_irq.h. That said, since
genirq, it's now necessary for any driver which contains interrupt
controller code like GPIO drivers. So I suspect the comment should now
be lost, even though it's not really a replacement for asm/irq.h.
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Benjamin Herrenschmidt @ 2012-02-16 22:58 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329386540-12341-1-git-send-email-Shengzhou.Liu@freescale.com>
On Thu, 2012-02-16 at 18:02 +0800, Shengzhou Liu wrote:
> If USB UTMI PHY is not enable, writing to portsc register will lead to
> kernel hang during boot up.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> Apply for master branch of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Tested on P5020DS, the issue was reported by Benjamin Herrenschmidt.
This fixes the hang, but sadly doesn't make USB work. I now get:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
/soc@ffe000000/usb@210000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 44, io mem 0xffe210000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
fsl-ehci fsl-ehci.1: irq 45, io mem 0xffe211000
fsl-ehci fsl-ehci.1: USB 2.0 started, EHCI 1.00
.../...
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
<remove device, re-plug it>
usb 1-1: new full-speed USB device number 3 using fsl-ehci
hub 1-0:1.0: unable to enumerate USB device on port 1
<remove again, re-plug it>
usb 1-1: new full-speed USB device number 4 using fsl-ehci
usb 1-1: device descriptor read/64, error -110
The blurb about "invalid dr_mode property" makes me think there's some
kind of disagreement between the device-tree coming with the machine and
what upstream expects. Basically the DT doesn't contain a dr_mode
property at all (which should be fine, host mode is what I want, but I
suspect some stuff aren't being configured properly by u-boot either...)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 00/27] irq_domain generalization and rework
From: Andrew Morton @ 2012-02-16 22:52 UTC (permalink / raw)
To: Grant Likely
Cc: Russell King, devicetree-discuss, linux-kernel, Milton Miller,
Rob Herring, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1329383368-12122-1-git-send-email-grant.likely@secretlab.ca>
On Thu, 16 Feb 2012 02:09:01 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
>
> This series generalizes the "irq_host" infrastructure from powerpc
> so that it can be used by all architectures and renames it to "irq_domain".
drivers/mfd/twl-core.c is fairly horked on i386 allmodconfig:
drivers/mfd/twl-core.c: In function 'twl_probe':
drivers/mfd/twl-core.c:1218: error: implicit declaration of function 'irq_alloc_descs'
drivers/mfd/twl-core.c:1226: error: implicit declaration of function 'irq_domain_add_legacy'
drivers/mfd/twl-core.c:1227: error: 'irq_domain_simple_ops' undeclared (first use in this function)
drivers/mfd/twl-core.c:1227: error: (Each undeclared identifier is reported only once
drivers/mfd/twl-core.c:1227: error: for each function it appears in.)
This is today's linux-next so it has rmk's "ARM: omap: fix broken
twl-core dependencies and ifdefs" in there, which looks like it
attempts to repair this stuff.
It's looking for things which are in both linux/irq.h and in
linux/irqdomain.h.
btw, Russell, regarding this comment in include/linux/irq.h:
/*
* Please do not include this file in generic code. There is currently
* no requirement for any architecture to implement anything held
* within this file.
*
* Thanks. --rmk
*/
A quick grep indicates that we've lost this battle ;) Is the comments
still true? Should we stop discouraging inclusion of linux/irq.h?
Does anyone even know that it's discouraged ;)
^ permalink raw reply
* Re: [PATCH 1/2 v4] powerpc/85xx: Add p1025rdb platform support
From: Tabi Timur-B04825 @ 2012-02-16 21:07 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329206783-12190-1-git-send-email-B32736@freescale.com>
On Tue, Feb 14, 2012 at 2:06 AM, Zhicheng Fan <B32736@freescale.com> wrote:
> From: Zhicheng Fan <b32736@freescale.com>
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 2/2 v4] powerpc/dts: Add dts for p1025rdb board
From: Tabi Timur-B04825 @ 2012-02-16 21:06 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329206783-12190-2-git-send-email-B32736@freescale.com>
On Tue, Feb 14, 2012 at 2:06 AM, Zhicheng Fan <B32736@freescale.com> wrote:
> From: Zhicheng Fan <b32736@freescale.com>
>
> P1025RDB Overview
> ------------------
> 1Gbyte DDR3 SDRAM
> 32 Mbyte NAND flash
> 16Mbyte NOR flash
> 16 Mbyte SPI flash
> SD connector to interface with the SD memory card
> Real-time clock on I2C bus
>
> PCIe:
> - x1 PCIe slot
> - x1 mini-PCIe slot
>
> 10/100/1000 BaseT Ethernet ports:
> - eTSEC1, RGMII: one 10/100/1000 port using AtherosTM AR8021
> - eTSEC2, SGMII: one 10/100/1000 port using VitesseTM VSC8221
> - eTSEC3, RGMII: one 10/100/1000 port using AtherosTM AR8021
>
> USB 2.0 port:
> - Two USB2.0 Type A receptacles
> - One USB2.0 signal to Mini PCIe slot
>
> Dual RJ45 UART ports:
> - DUART interface: supports two UARTs up to 115200 bps for console displa=
y
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 1/2 v5] powerpc/85xx: Add Quicc Engine support for p1025rdb
From: Tabi Timur-B04825 @ 2012-02-16 21:05 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329289091-26231-1-git-send-email-B32736@freescale.com>
On Wed, Feb 15, 2012 at 12:58 AM, Zhicheng Fan <B32736@freescale.com> wrote=
:
> From: Zhicheng Fan <b32736@freescale.com>
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: tlb flushing on Power
From: Benjamin Herrenschmidt @ 2012-02-16 20:31 UTC (permalink / raw)
To: Seth Jennings; +Cc: Robert Jennings, linuxppc-dev, Nitin Gupta, Dave Hansen
In-Reply-To: <4F3D38D3.4020903@linux.vnet.ibm.com>
On Thu, 2012-02-16 at 11:11 -0600, Seth Jennings wrote:
> Just wanted to bump you again about this. You mentioned that if I wanted to
> do a cpu-local flush of a single tlb entry, that there would have to be a new
> hook. Is that right?
>
> I've been looking through the powerpc arch and I thought that I might have
> found the power analog to __flush_tlb_one() for x86 in local_flush_tlb_page()
> with a NULL vma argument. This doesn't seem to work though, as indicated
> by a crash when I tried it. After looking in tlbflush.h again, it seems
> that local_flush_tlb_page() is a no-op when CONFIG_PPC_STD_MMU_64 is set,
> as are almost ALL of the tlb flushing functions... which makes no sense to
> me.
>
> Any help you (or anyone) can give me would be greatly appreciated.
On ppc64 with hash-table MMU, we handle the flushes very differently.
PTEs that are modified are added to a list at the time of the
modification and either flushed immediately if no lazy tlb batching is
in progress or flushed when leaving the lazy tlb op.
This is to avoid a problem where we might otherwise, under some
circumstances, create a new TLB which can be hashed in to the hash table
before the previous one has been flushed out. That would lead to a dup
in the hash table which is architecturally illegal.
This happens via the call to hpte_need_flush() in pte_update().
Unfortunately, it will always consider all kernel mappings as global,
so the per-cpu "optimization" won't be usable in this case, at least
not until we add some kind of additional argument to that function.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Timur Tabi @ 2012-02-16 19:48 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120216194655.GD9262@ovro.caltech.edu>
Ira W. Snyder wrote:
> No. I don't have the ability to connect my P2020 up to an FPGA to
> recreate the DMA workload that causes this on my 8349EA. I can run the
> dmatest module, if you'd like.
I just want to make sure your patch doesn't break 85xx.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox