[RFC PATCH v2] KVM: PPC: vfio kvm device: support spapr tce
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v2:
* it does not try to introduce a realmode search function.
Instead, liobn-to-iommu-group lookup is done by VFIO KVM device
in virtual mode and the result (iommu_group pointer) is cached
in kvm_arch so the realmode handlers do not use VFIO KVM device for that.
And the iommu groups get released on KVM termination.
I tried this, seems viable.
Did not I miss anything? Thanks.
---
arch/powerpc/include/asm/kvm_host.h | 3 ++
arch/powerpc/kvm/Kconfig| 1 +
arch/powerpc/kvm/Makefile | 3 ++
include/linux/vfio.h| 3 ++
include/uapi/linux/kvm.h| 1 +
virt/kvm/vfio.c | 74 +
6 files changed, 85 insertions(+)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 48dbe8b..e1163d7 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -293,6 +293,9 @@ struct kvm_arch {
#ifdef CONFIG_KVM_XICS
struct kvmppc_xics *xics;
#endif
+#ifdef CONFIG_KVM_VFIO
+ struct kvm_vfio *vfio;
+#endif
};
/*
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 61b3535..d1b7f64 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -60,6 +60,7 @@ config KVM_BOOK3S_64
select KVM_BOOK3S_64_HANDLER
select KVM
select SPAPR_TCE_IOMMU
+ select KVM_VFIO
---help---
Support running unmodified book3s_64 and book3s_32 guest kernels
in virtual machines on book3s_64 host processors.
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 6646c95..2438d2e 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -87,6 +87,9 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
book3s_xics.o
+kvm-book3s_64-objs-$(CONFIG_KVM_VFIO) += \
+ $(KVM)/vfio.o \
+
kvm-book3s_64-module-objs := \
$(KVM)/kvm_main.o \
$(KVM)/eventfd.o \
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 24579a0..681e19b 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -97,4 +97,7 @@ extern struct vfio_group *vfio_group_get_external_user(struct
file *filep);
extern void vfio_group_put_external_user(struct vfio_group *group);
extern int vfio_external_user_iommu_id(struct vfio_group *group);
+extern struct iommu_group *vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn);
+
#endif /* VFIO_H */
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7c1a349..a74ad16 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -847,6 +847,7 @@ struct kvm_device_attr {
#define KVM_DEV_VFIO_GROUP1
#define KVM_DEV_VFIO_GROUP_ADD 1
#define KVM_DEV_VFIO_GROUP_DEL 2
+#define KVM_DEV_VFIO_SPAPR_TCE_LIOBN 2
/*
* ioctls for VM fds
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index ca4260e..f9271d5 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -22,6 +22,9 @@
struct kvm_vfio_group {
struct list_head node;
struct vfio_group *vfio_group;
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ uint64_t liobn;
+#endif
};
struct kvm_vfio {
@@ -188,12 +191,76 @@ static int kvm_vfio_set_group(struct kvm_device *dev,
long attr, u64 arg)
return -ENXIO;
}
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+static int kvm_vfio_set_spapr_tce_liobn(struct kvm_device *dev,
+ long attr, u64 arg)
+{
+ struct kvm_vfio *kv = dev-private;
+ struct vfio_group *vfio_group;
+ struct kvm_vfio_group *kvg;
+ void __user *argp = (void __user *)arg;
+ struct fd f;
+ int32_t fd;
+ uint64_t liobn = attr;
+
+ if (get_user(fd, (int32_t __user *)argp))
+ return -EFAULT;
+
+ f = fdget(fd);
+ if (!f.file)
+ return -EBADF;
+
+ vfio_group = kvm_vfio_group_get_external_user(f.file);
+ fdput(f);
+
+ list_for_each_entry(kvg, kv-group_list, node) {
+ if (kvg-vfio_group == vfio_group) {
+ WARN_ON(kvg-liobn);
+ kvg-liobn = liobn;
+ kvm_vfio_group_put_external_user(vfio_group);
+ return 0;
+ }
+ }
+
+ kvm_vfio_group_put_external_user(vfio_group);
+
+ return -ENXIO;
+}
+
+struct iommu_group *vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn)
+{
+ struct kvm_vfio_group *kvg;
+
+ if (!kvm-arch.vfio)
+ return NULL;
+
+ list_for_each_entry(kvg, kvm-arch.vfio-group_list, node) {
+ if (kvg-liobn == liobn) {
+ int group_id = vfio_external_user_iommu_id(
+ kvg-vfio_group);
+ struct
[PATCH] powerpc: memcpy optimization for 64bit LE
Unaligned stores take alignment exceptions on POWER7 running in little-endian. This is a dumb little-endian base memcpy that prevents unaligned stores. It is replaced by the VMX memcpy at boot. Signed-off-by: Philippe Bergheaud fe...@linux.vnet.ibm.com --- arch/powerpc/include/asm/string.h |4 arch/powerpc/kernel/ppc_ksyms.c |2 -- arch/powerpc/lib/Makefile |2 -- arch/powerpc/lib/memcpy_64.S | 19 +++ 4 files changed, 19 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/include/asm/string.h b/arch/powerpc/include/asm/string.h index 0dffad6..e40010a 100644 --- a/arch/powerpc/include/asm/string.h +++ b/arch/powerpc/include/asm/string.h @@ -10,9 +10,7 @@ #define __HAVE_ARCH_STRNCMP #define __HAVE_ARCH_STRCAT #define __HAVE_ARCH_MEMSET -#ifdef __BIG_ENDIAN__ #define __HAVE_ARCH_MEMCPY -#endif #define __HAVE_ARCH_MEMMOVE #define __HAVE_ARCH_MEMCMP #define __HAVE_ARCH_MEMCHR @@ -24,9 +22,7 @@ extern int strcmp(const char *,const char *); extern int strncmp(const char *, const char *, __kernel_size_t); extern char * strcat(char *, const char *); extern void * memset(void *,int,__kernel_size_t); -#ifdef __BIG_ENDIAN__ extern void * memcpy(void *,const void *,__kernel_size_t); -#endif extern void * memmove(void *,const void *,__kernel_size_t); extern int memcmp(const void *,const void *,__kernel_size_t); extern void * memchr(const void *,int,__kernel_size_t); diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c index 526ad5c..0c2dd60 100644 --- a/arch/powerpc/kernel/ppc_ksyms.c +++ b/arch/powerpc/kernel/ppc_ksyms.c @@ -147,9 +147,7 @@ EXPORT_SYMBOL(__ucmpdi2); #endif long long __bswapdi2(long long); EXPORT_SYMBOL(__bswapdi2); -#ifdef __BIG_ENDIAN__ EXPORT_SYMBOL(memcpy); -#endif EXPORT_SYMBOL(memset); EXPORT_SYMBOL(memmove); EXPORT_SYMBOL(memcmp); diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 5310132..6670361 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -23,9 +23,7 @@ obj-y += checksum_$(CONFIG_WORD_SIZE).o obj-$(CONFIG_PPC64)+= checksum_wrappers_64.o endif -ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),) obj-$(CONFIG_PPC64)+= memcpy_power7.o memcpy_64.o -endif obj-$(CONFIG_PPC_EMULATE_SSTEP)+= sstep.o ldstfp.o diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S index d2bbbc8..358cf74 100644 --- a/arch/powerpc/lib/memcpy_64.S +++ b/arch/powerpc/lib/memcpy_64.S @@ -12,10 +12,28 @@ .align 7 _GLOBAL(memcpy) BEGIN_FTR_SECTION +#ifdef __LITTLE_ENDIAN__ + cmpdi cr7,r5,0 /* dumb little-endian memcpy */ +#else std r3,48(r1) /* save destination pointer for return value */ +#endif FTR_SECTION_ELSE b memcpy_power7 ALT_FTR_SECTION_END_IFCLR(CPU_FTR_VMX_COPY) +#ifdef __LITTLE_ENDIAN__ + addi r5,r5,-1 + addi r9,r3,-1 + add r5,r3,r5 + subf r5,r9,r5 + addi r4,r4,-1 + mtctr r5 + beqlr cr7 +1: + lbzu r10,1(r4) + stbu r10,1(r9) + bdnz 1b + blr +#else PPC_MTOCRF(0x01,r5) cmpldi cr1,r5,16 neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry @@ -201,3 +219,4 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_LD_STD) stb r0,0(r3) 4: ld r3,48(r1) /* return dest pointer */ blr +#endif -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
On 11/05/2013 01:27 AM, Jason Gunthorpe wrote:
Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
present' made the call to phy_scan optional, if the DT has a link to
the phy node.
However phy_scan has the side effect of calling phy_addr_set, which
writes the phy MDIO address to the ethernet controller. If phy_addr_set
is not called, and the bootloader has not set the correct address then
the driver will fail to function.
Tested on Kirkwood.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
Jason,
thanks for catching this! I do my kirkwood testing on Dockstar,
which has PHY addr 0x0 - also the reset default, which may be
why it slipped through.
Acked-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 2c210ec..00e43b5 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2890,6 +2890,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
PHY_INTERFACE_MODE_GMII);
if (!mp-phy)
err = -ENODEV;
+ phy_addr_set(mp, mp-phy-addr);
} else if (pd-phy_addr != MV643XX_ETH_PHY_NONE) {
mp-phy = phy_scan(mp, pd-phy_addr);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
Li Xiubo wrote: But fsl-ssi.o and fsl-spdif.o is based PowrePC platform? Which we can see from the comments. fsl_ssi was originally PPC-only, but it now supports PPC and ARM. You can see that from the git history. If there are any comments that say PPC but are not PPC-specific, that should be fixed. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 08:53:44PM +, Paul E. McKenney wrote:
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
Some comments below. I believe that opcodes need to be fixed for IA64.
I am unsure of the ifdefs and opcodes for arm64, but the ARM folks should
be able to tell us.
[...]
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 60f15e274e6d..a804093d6891 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -53,10 +53,36 @@
#define smp_mb() barrier()
#define smp_rmb()barrier()
#define smp_wmb()barrier()
+
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p, v)
\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
What data sizes do these accessors operate on? Assuming that we want
single-copy atomicity (with respect to interrupts in the UP case), we
probably want a check to stop people passing in things like structs.
#else
#define smp_mb() dmb(ish)
#define smp_rmb()smp_mb()
#define smp_wmb()dmb(ishst)
+
Seems like there should be some sort of #ifdef condition to distinguish
between these. My guess is something like:
#if __LINUX_ARM_ARCH__ 7
But I must defer to the ARM guys. For all I know, they might prefer
arch/arm to stick with smp_mb() and have arch/arm64 do the ldar and stlr.
Yes. For arch/arm/, I'd rather we stick with the smp_mb() for the time
being. We don't (yet) have any 32-bit ARMv8 support, and the efforts towards
a single zImage could do without minor variations like this, not to mention
the usual backlash I get whenever introducing something that needs a
relatively recent binutils.
+#define smp_store_release(p, v)
\
+do { \
+ asm volatile (stlr %w0 [%1] : : r (v), r (p) : memory);\
+} while (0)
+
+#define smp_load_acquire(p) \
+do { \
+ typeof(p) ___p1;\
+ asm volatile (ldar %w0, [%1] \
+ : =r (___p1) : r (p) : memory); \
+ return ___p1; \
+} while (0)
#endif
#define read_barrier_depends() do { } while(0)
diff --git a/arch/arm64/include/asm/barrier.h
b/arch/arm64/include/asm/barrier.h
index d4a63338a53c..0da2d4ebb9a8 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -35,10 +35,38 @@
#define smp_mb() barrier()
#define smp_rmb()barrier()
#define smp_wmb()barrier()
+
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p, v)
\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#else
+
#define smp_mb() asm volatile(dmb ish : : : memory)
#define smp_rmb()asm volatile(dmb ishld : : : memory)
#define smp_wmb()asm volatile(dmb ishst : : : memory)
+
+#define smp_store_release(p, v)
\
+do { \
+ asm volatile (stlr %w0 [%1] : : r (v), r (p) : memory);\
Missing comma between the operands. Also, that 'w' output modifier enforces
a 32-bit store (same early question about sizes). Finally, it might be more
efficient to use =Q for the addressing mode, rather than take the address
of p manually.
+} while (0)
+
+#define smp_load_acquire(p) \
+do { \
+ typeof(p) ___p1;
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote:
On Mon, Nov 04, 2013 at 08:53:44PM +, Paul E. McKenney wrote:
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
Some comments below. I believe that opcodes need to be fixed for IA64.
I am unsure of the ifdefs and opcodes for arm64, but the ARM folks should
be able to tell us.
[ . . . ]
+} while (0)
+
+#define smp_load_acquire(p) \
+do { \
+ typeof(p) ___p1;\
+ asm volatile (ldar %w0, [%1] \
+ : =r (___p1) : r (p) : memory); \
+ return ___p1; \
Similar comments here wrt Q constraint.
Random other question: have you considered how these accessors should behave
when presented with __iomem pointers?
Should we have something to make sparse yell if not __kernel or some such?
Thanx, Paul
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] IBM Akebono: Add support to the OHCI platform driver for Akebono
On Tue, 5 Nov 2013, Alistair Popple wrote:
The IBM Akebono board has a OHCI compliant USB host interface. This
patch adds support for it to the OHCI platform driver.
As we use device tree to pass platform specific data instead of
platform data we remove the check for platform data and instead
provide reasonable defaults if no platform data is present. This is
similar to what is currently done in ehci-platform.c.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/ohci-platform.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ohci-platform.c
b/drivers/usb/host/ohci-platform.c
index a4c6410..4331454 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -23,6 +23,8 @@
#include linux/usb/ohci_pdriver.h
#include linux/usb.h
#include linux/usb/hcd.h
+#include linux/slab.h
+#include linux/of.h
#include ohci.h
@@ -55,6 +57,8 @@ static const struct ohci_driver_overrides
platform_overrides __initconst = {
.reset =ohci_platform_reset,
};
+static struct usb_ohci_pdata ohci_platform_defaults;
+
static int ohci_platform_probe(struct platform_device *dev)
{
struct usb_hcd *hcd;
@@ -63,14 +67,14 @@ static int ohci_platform_probe(struct platform_device
*dev)
int irq;
int err = -ENOMEM;
- if (!pdata) {
- WARN_ON(1);
- return -ENODEV;
- }
-
if (usb_disabled())
return -ENODEV;
+ /* Platforms using DT don't always provide platform data.
+ * This should provide reasonable defaults. */
/*
* The accepted format for multi-line
* comments is like this.
*/
+ if (!pdata)
+ dev-dev.platform_data = pdata = ohci_platform_defaults;
+
irq = platform_get_irq(dev, 0);
if (irq 0) {
dev_err(dev-dev, no irq provided);
@@ -171,6 +175,11 @@ static int ohci_platform_resume(struct device *dev)
#define ohci_platform_resume NULL
#endif /* CONFIG_PM */
+static const struct of_device_id ohci_of_match[] = {
+ { .compatible = ibm,akebono-ohci, },
+ {},
+};
+
static const struct platform_device_id ohci_platform_table[] = {
{ ohci-platform, 0 },
{ }
@@ -191,6 +200,7 @@ static struct platform_driver ohci_platform_driver = {
.owner = THIS_MODULE,
.name = ohci-platform,
.pm = ohci_platform_pm_ops,
+ .of_match_table = ohci_of_match,
}
};
Update the comment formatting, and then you can resubmit with
Acked-by: Alan Stern st...@rowland.harvard.edu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
On Tue, 5 Nov 2013, Alistair Popple wrote:
The IBM Akebono board has an EHCI compliant USB host interface. This
patch adds support for it to the EHCI platform driver.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/ehci-platform.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-platform.c
b/drivers/usb/host/ehci-platform.c
index f6b790c..0a67616 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -203,9 +203,10 @@ static int ehci_platform_resume(struct device *dev)
#define ehci_platform_resume NULL
#endif /* CONFIG_PM */
-static const struct of_device_id vt8500_ehci_ids[] = {
+static const struct of_device_id ehci_platform_ids[] = {
{ .compatible = via,vt8500-ehci, },
{ .compatible = wm,prizm-ehci, },
+ { .compatible = ibm,akebono-ehci, },
{}
};
@@ -229,7 +230,7 @@ static struct platform_driver ehci_platform_driver = {
.owner = THIS_MODULE,
.name = ehci-platform,
.pm = ehci_platform_pm_ops,
- .of_match_table = vt8500_ehci_ids,
+ .of_match_table = ehci_platform_ids,
}
};
Acked-by: Alan Stern st...@rowland.harvard.edu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote: [...] --- a/drivers/net/ethernet/ibm/emac/Kconfig +++ b/drivers/net/ethernet/ibm/emac/Kconfig @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII bool default n +config IBM_EMAC_RGMII_WOL + bool + default n + [...] So no-one can even build-test this at present! Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote:
+
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p, v)
\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
What data sizes do these accessors operate on? Assuming that we want
single-copy atomicity (with respect to interrupts in the UP case), we
probably want a check to stop people passing in things like structs.
Fair enough; I think we should restrict to native word sizes same as we
do for atomics.
Something like so perhaps:
#ifdef CONFIG_64BIT
#define __check_native_word(t) (sizeof(t) == 4 || sizeof(t) == 8)
#else
#define __check_native_word(t) (sizeof(t) == 4)
#endif
#define smp_store_release(p, v) \
do {\
BUILD_BUG_ON(!__check_native_word(p)); \
smp_mb(); \
ACCESS_ONCE(p) = (v); \
} while (0)
+#define smp_store_release(p, v)
\
+do { \
+ asm volatile (stlr %w0 [%1] : : r (v), r (p) : memory);\
Missing comma between the operands. Also, that 'w' output modifier enforces
a 32-bit store (same early question about sizes). Finally, it might be more
efficient to use =Q for the addressing mode, rather than take the address
of p manually.
so something like:
asm volatile (stlr %0, [%1] : : r (v), =Q (p) : memory);
?
My inline asm foo is horrid and I mostly get by with copy paste from a
semi similar existing form :/
Random other question: have you considered how these accessors should behave
when presented with __iomem pointers?
A what? ;-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
On Tue, 2013-11-05 at 10:04 -0500, Alan Stern wrote:
On Tue, 5 Nov 2013, Alistair Popple wrote:
The IBM Akebono board has an EHCI compliant USB host interface. This
patch adds support for it to the EHCI platform driver.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/ehci-platform.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-platform.c
b/drivers/usb/host/ehci-platform.c
index f6b790c..0a67616 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -203,9 +203,10 @@ static int ehci_platform_resume(struct device *dev)
#define ehci_platform_resume NULL
#endif /* CONFIG_PM */
-static const struct of_device_id vt8500_ehci_ids[] = {
+static const struct of_device_id ehci_platform_ids[] = {
{ .compatible = via,vt8500-ehci, },
{ .compatible = wm,prizm-ehci, },
+ { .compatible = ibm,akebono-ehci, },
{}
};
Why ? Do we need to add an entry for every platform in there ? Besides,
it probably should be the SoC name not the platform here
Why not simply a generic compatible usb-ehci ? It's a standard
programming interface, there are no specific quirks, we shouldn't
need to have to add new entries to the driver like that for every
new SoC/platform.
@@ -229,7 +230,7 @@ static struct platform_driver ehci_platform_driver = {
.owner = THIS_MODULE,
.name = ehci-platform,
.pm = ehci_platform_pm_ops,
- .of_match_table = vt8500_ehci_ids,
+ .of_match_table = ehci_platform_ids,
}
};
Acked-by: Alan Stern st...@rowland.harvard.edu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Tue, 2013-11-05 at 18:16 +, Ben Hutchings wrote: On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote: [...] --- a/drivers/net/ethernet/ibm/emac/Kconfig +++ b/drivers/net/ethernet/ibm/emac/Kconfig @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII bool default n +config IBM_EMAC_RGMII_WOL + bool + default n + [...] So no-one can even build-test this at present! Patch 7/7 adds the select to the platform, isn't that sufficient ? It's an SoC bit so there's little point making it generally selectable by the user. Alistair: The commit name should be different, it's not a PHY you are adding, it's a PHY interface (the PHY itself is off chip). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2] KVM: PPC: vfio kvm device: support spapr tce
On Tue, 2013-11-05 at 19:05 +1100, Alexey Kardashevskiy wrote:
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v2:
* it does not try to introduce a realmode search function.
Instead, liobn-to-iommu-group lookup is done by VFIO KVM device
in virtual mode and the result (iommu_group pointer) is cached
in kvm_arch so the realmode handlers do not use VFIO KVM device for that.
And the iommu groups get released on KVM termination.
I tried this, seems viable.
Did not I miss anything? Thanks.
A commit message ;)
---
arch/powerpc/include/asm/kvm_host.h | 3 ++
arch/powerpc/kvm/Kconfig| 1 +
arch/powerpc/kvm/Makefile | 3 ++
include/linux/vfio.h| 3 ++
include/uapi/linux/kvm.h| 1 +
virt/kvm/vfio.c | 74
+
6 files changed, 85 insertions(+)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 48dbe8b..e1163d7 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -293,6 +293,9 @@ struct kvm_arch {
#ifdef CONFIG_KVM_XICS
struct kvmppc_xics *xics;
#endif
+#ifdef CONFIG_KVM_VFIO
+ struct kvm_vfio *vfio;
+#endif
};
/*
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 61b3535..d1b7f64 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -60,6 +60,7 @@ config KVM_BOOK3S_64
select KVM_BOOK3S_64_HANDLER
select KVM
select SPAPR_TCE_IOMMU
+ select KVM_VFIO
---help---
Support running unmodified book3s_64 and book3s_32 guest kernels
in virtual machines on book3s_64 host processors.
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 6646c95..2438d2e 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -87,6 +87,9 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
book3s_xics.o
+kvm-book3s_64-objs-$(CONFIG_KVM_VFIO) += \
+ $(KVM)/vfio.o \
+
kvm-book3s_64-module-objs := \
$(KVM)/kvm_main.o \
$(KVM)/eventfd.o \
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 24579a0..681e19b 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -97,4 +97,7 @@ extern struct vfio_group
*vfio_group_get_external_user(struct file *filep);
extern void vfio_group_put_external_user(struct vfio_group *group);
extern int vfio_external_user_iommu_id(struct vfio_group *group);
+extern struct iommu_group *vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn);
+
Nope, this doesn't go in vfio.h, it's a function provided by kvm. It
should be named as such too, kvm_vfio_... It also depends on both
CONFIG_KVM_VFIO and CONFIG_SPAPR_TCE_IOMMU and needs stub version
otherwise. Is just _liobn specific enough or does it need a spapr_tce
thrown in to avoid confusion with embedded ppc folks?
#endif /* VFIO_H */
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7c1a349..a74ad16 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -847,6 +847,7 @@ struct kvm_device_attr {
#define KVM_DEV_VFIO_GROUP 1
#define KVM_DEV_VFIO_GROUP_ADD 1
#define KVM_DEV_VFIO_GROUP_DEL 2
+#define KVM_DEV_VFIO_SPAPR_TCE_LIOBN2
I wonder if it would be better architecturally if this was an attribute
rather than a new group, ex:
#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN 3
It's a mouthful, but we are setting an attribute of a VFIO group, so it
makes sense. kvm_device_attr.addr would then need to point to a struct
containing both the fd and liobn.
Whatever we come up with need a documentation addition in
Documentation/virtual/kvm/devices/vfio.txt.
/*
* ioctls for VM fds
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index ca4260e..f9271d5 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -22,6 +22,9 @@
struct kvm_vfio_group {
struct list_head node;
struct vfio_group *vfio_group;
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ uint64_t liobn;
Why is liobn an unsigned long in the exported function but a uint64_t
here?
+#endif
};
struct kvm_vfio {
@@ -188,12 +191,76 @@ static int kvm_vfio_set_group(struct kvm_device *dev,
long attr, u64 arg)
return -ENXIO;
}
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+static int kvm_vfio_set_spapr_tce_liobn(struct kvm_device *dev,
+ long attr, u64 arg)
+{
+ struct kvm_vfio *kv = dev-private;
+ struct vfio_group *vfio_group;
+ struct kvm_vfio_group *kvg;
+ void __user *argp = (void __user *)arg;
+ struct fd f;
+ int32_t fd;
+ uint64_t liobn = attr;
+
+ if (get_user(fd, (int32_t __user *)argp))
+ return -EFAULT;
+
+ f = fdget(fd);
+ if (!f.file)
+
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
On 11/05/2013 11:12 PM, Arnaud Ebalard wrote: Hi Jason, Jason Gunthorpe jguntho...@obsidianresearch.com writes: Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node present' made the call to phy_scan optional, if the DT has a link to the phy node. However phy_scan has the side effect of calling phy_addr_set, which writes the phy MDIO address to the ethernet controller. If phy_addr_set is not called, and the bootloader has not set the correct address then the driver will fail to function. Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102 (Armada 370 based) which I had put on a todo list and temporarily Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta, are you sure it is (was) related to Jason's fix? Sebastian workarounded by including a 'ping whatever' call in my u-boot env in order to force it to do the init. Without it, I was unable to properly use the interface. With your fix, after multiple reboots to test it, everything works as expected. So, FWIW: Tested-by: Arnaud Ebalard a...@natisbad.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
Hi Jason, Jason Gunthorpe jguntho...@obsidianresearch.com writes: Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node present' made the call to phy_scan optional, if the DT has a link to the phy node. However phy_scan has the side effect of calling phy_addr_set, which writes the phy MDIO address to the ethernet controller. If phy_addr_set is not called, and the bootloader has not set the correct address then the driver will fail to function. Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102 (Armada 370 based) which I had put on a todo list and temporarily workarounded by including a 'ping whatever' call in my u-boot env in order to force it to do the init. Without it, I was unable to properly use the interface. With your fix, after multiple reboots to test it, everything works as expected. So, FWIW: Tested-by: Arnaud Ebalard a...@natisbad.org Cheers, a+ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
[snip]
+/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
+static inline int rgmii_valid_mode(int phy_mode)
+{
+ return phy_mode == PHY_MODE_GMII ||
+ phy_mode == PHY_MODE_MII ||
+ phy_mode == PHY_MODE_RGMII ||
+ phy_mode == PHY_MODE_TBI ||
+ phy_mode == PHY_MODE_RTBI;
+}
+
+static inline const char *rgmii_mode_name(int mode)
+{
+ switch (mode) {
+ case PHY_MODE_RGMII:
+ return RGMII;
+ case PHY_MODE_TBI:
+ return TBI;
+ case PHY_MODE_GMII:
+ return GMII;
+ case PHY_MODE_MII:
+ return MII;
+ case PHY_MODE_RTBI:
+ return RTBI;
+ default:
+ BUG();
+ }
Any reasons why you are duplicating what is available in
drivers/of/of_net.c ::of_get_phy_mode()?
--
Florian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
On Tue, Nov 05, 2013 at 11:12:00PM +0100, Arnaud Ebalard wrote: Hi Jason, Jason Gunthorpe jguntho...@obsidianresearch.com writes: Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node present' made the call to phy_scan optional, if the DT has a link to the phy node. However phy_scan has the side effect of calling phy_addr_set, which writes the phy MDIO address to the ethernet controller. If phy_addr_set is not called, and the bootloader has not set the correct address then the driver will fail to function. Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102 (Armada 370 based) which I had put on a todo list and temporarily readynas duo v2? thx, Jason. workarounded by including a 'ping whatever' call in my u-boot env in order to force it to do the init. Without it, I was unable to properly use the interface. With your fix, after multiple reboots to test it, everything works as expected. So, FWIW: Tested-by: Arnaud Ebalard a...@natisbad.org Cheers, a+ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote: On Tue, 2013-11-05 at 18:16 +, Ben Hutchings wrote: On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote: [...] --- a/drivers/net/ethernet/ibm/emac/Kconfig +++ b/drivers/net/ethernet/ibm/emac/Kconfig @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII bool default n +config IBM_EMAC_RGMII_WOL + bool + default n + [...] So no-one can even build-test this at present! Patch 7/7 adds the select to the platform, isn't that sufficient ? I suppose so, but I don't think that went to netdev. It's an SoC bit so there's little point making it generally selectable by the user. I think a better way to do this is: config IBM_EMAC_RGMII_WOL bool IBM EMAC RGMII wake-on-LAN support depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST default y if MY_WONDERFUL_NEW_SOC Then anyone making an API change that affects this driver can check that it still complies. Ben. Alistair: The commit name should be different, it's not a PHY you are adding, it's a PHY interface (the PHY itself is off chip). -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
Hi, Sebastian Hesselbarth sebastian.hesselba...@gmail.com writes: On 11/05/2013 11:12 PM, Arnaud Ebalard wrote: Hi Jason, Jason Gunthorpe jguntho...@obsidianresearch.com writes: Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node present' made the call to phy_scan optional, if the DT has a link to the phy node. However phy_scan has the side effect of calling phy_addr_set, which writes the phy MDIO address to the ethernet controller. If phy_addr_set is not called, and the bootloader has not set the correct address then the driver will fail to function. Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102 (Armada 370 based) which I had put on a todo list and temporarily Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta, are you sure it is (was) related to Jason's fix? Thanks for pointing this, Sebastian and my apologies for the noise. Jason's fix is indeed for a file which is not compiled for my RN102. As the problem perfectly matched the issue I had and current kernel w/ the patch applied does indeed fix it, I did not try and do the test w/o the patch applied. It would have showed the problem was fixed by something else in 3.12. Well, I spent some time digging the changes on mvneta.c and: commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c Author: Thomas Petazzoni thomas.petazz...@free-electrons.com Date: Wed Sep 4 16:21:18 2013 +0200 net: mvneta: properly disable HW PHY polling and ensure adjust_link() works This commit fixes a long-standing bug that has been reported by many users: on some Armada 370 platforms, only the network interface that has been used in U-Boot to tftp the kernel works properly in Linux. The other network interfaces can see a 'link up', but are unable to transmit data. The reports were generally made on the Armada 370-based Mirabox, but have also been given on the Armada 370-RD board. [SNIP] $ git tag --contains 714086029116 v3.12 v3.12-rc1 v3.12-rc2 v3.12-rc3 v3.12-rc4 v3.12-rc5 v3.12-rc6 v3.12-rc7 So the problem was indeed fixed at the beginning of 3.12 series by Thomas. Anyway, my bad and thanks again for pointing it out. Cheers, a+ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Tue, 5 Nov 2013 10:47:22 Florian Fainelli wrote:
[snip]
+/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
+static inline int rgmii_valid_mode(int phy_mode)
+{
+ return phy_mode == PHY_MODE_GMII ||
+ phy_mode == PHY_MODE_MII ||
+ phy_mode == PHY_MODE_RGMII ||
+ phy_mode == PHY_MODE_TBI ||
+ phy_mode == PHY_MODE_RTBI;
+}
+
+static inline const char *rgmii_mode_name(int mode)
+{
+ switch (mode) {
+ case PHY_MODE_RGMII:
+ return RGMII;
+ case PHY_MODE_TBI:
+ return TBI;
+ case PHY_MODE_GMII:
+ return GMII;
+ case PHY_MODE_MII:
+ return MII;
+ case PHY_MODE_RTBI:
+ return RTBI;
+ default:
+ BUG();
+ }
Any reasons why you are duplicating what is available in
drivers/of/of_net.c ::of_get_phy_mode()?
Unless I'm missing something of_get_phy_mode() is going the other way.
rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I
couldn't find any obvious kernel method to do this but maybe I missed it?
Regards,
Alistair
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
2013/11/5 Alistair Popple alist...@popple.id.au:
On Tue, 5 Nov 2013 10:47:22 Florian Fainelli wrote:
[snip]
+/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
+static inline int rgmii_valid_mode(int phy_mode)
+{
+ return phy_mode == PHY_MODE_GMII ||
+ phy_mode == PHY_MODE_MII ||
+ phy_mode == PHY_MODE_RGMII ||
+ phy_mode == PHY_MODE_TBI ||
+ phy_mode == PHY_MODE_RTBI;
+}
+
+static inline const char *rgmii_mode_name(int mode)
+{
+ switch (mode) {
+ case PHY_MODE_RGMII:
+ return RGMII;
+ case PHY_MODE_TBI:
+ return TBI;
+ case PHY_MODE_GMII:
+ return GMII;
+ case PHY_MODE_MII:
+ return MII;
+ case PHY_MODE_RTBI:
+ return RTBI;
+ default:
+ BUG();
+ }
Any reasons why you are duplicating what is available in
drivers/of/of_net.c ::of_get_phy_mode()?
Unless I'm missing something of_get_phy_mode() is going the other way.
rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I
couldn't find any obvious kernel method to do this but maybe I missed it?
Right, rgmii_mode_name() just has informative purposes and should be
removed, I would suggest using standard device tree bindings property
(phy-mode) anyway such that you could use of_get_phy_mode() and use
phy_interface_t types.
--
Florian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Tue, 5 Nov 2013 23:11:50 Ben Hutchings wrote: On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote: [snip] It's an SoC bit so there's little point making it generally selectable by the user. I think a better way to do this is: config IBM_EMAC_RGMII_WOL bool IBM EMAC RGMII wake-on-LAN support depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST default y if MY_WONDERFUL_NEW_SOC Then anyone making an API change that affects this driver can check that it still complies. The method used in this patch is the same as what is currently used by the other IBM EMAC PHY interfaces (eg. config IBM_EMAC_ZMII etc). I'm happy to send a patch to update all of those as well for consistency but that would mean adding what each platform requires into EMACS Kconfig as well. Personally I think it is nicer to keep the definitions of what each platform requires in one place (ie. arch/powerpc/platforms/44x/Kconfig) as it is consistent with what we do for other 44x drivers, however I am happy to use the above method if people think it's better. Alternatively we could do something like this: config IBM_EMAC_RGMII_WOL bool default y if COMPILE_TEST default n This would leave the platform dependencies as they are currently but still allow compile testing. Regards, Alistair Ben. Alistair: The commit name should be different, it's not a PHY you are adding, it's a PHY interface (the PHY itself is off chip). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Tue, 5 Nov 2013 16:16:08 Florian Fainelli wrote: [snip] 2013/11/5 Alistair Popple alist...@popple.id.au: Any reasons why you are duplicating what is available in drivers/of/of_net.c ::of_get_phy_mode()? Unless I'm missing something of_get_phy_mode() is going the other way. rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I couldn't find any obvious kernel method to do this but maybe I missed it? Right, rgmii_mode_name() just has informative purposes and should be removed, I would suggest using standard device tree bindings property (phy-mode) anyway such that you could use of_get_phy_mode() and use phy_interface_t types. Ok, that's what is currently done in the core IBM EMAC driver. As this is used just for informative purposes I will remove it. Thanks. Regards, Alistair ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
On Wed, 2013-11-06 at 12:38 +1100, Alistair Popple wrote: Right, rgmii_mode_name() just has informative purposes and should be removed, I would suggest using standard device tree bindings property (phy-mode) anyway such that you could use of_get_phy_mode() and use phy_interface_t types. Ok, that's what is currently done in the core IBM EMAC driver. As this is used just for informative purposes I will remove it. Thanks. Why ? Information is useful... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
2013/11/5 Benjamin Herrenschmidt b...@kernel.crashing.org:
On Wed, 2013-11-06 at 12:38 +1100, Alistair Popple wrote:
Right, rgmii_mode_name() just has informative purposes and should be
removed, I would suggest using standard device tree bindings
property
(phy-mode) anyway such that you could use of_get_phy_mode() and use
phy_interface_t types.
Ok, that's what is currently done in the core IBM EMAC driver. As this
is used
just for informative purposes I will remove it. Thanks.
Why ? Information is useful...
Not the way they are currently handled:
+ /* Check if we need to attach to a RGMII */
+ if (!rgmii_valid_mode(mode)) {
+ dev_err(ofdev-dev, unsupported settings !\n);
Considering that nothing useful is being printed, that or nothing at
all really looks identical to me.
--
Florian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V5 1/2] powerpc/85xx: Add QE common init function
Hi Scott,
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, September 28, 2013 1:01 AM
To: Xie Xiaobo-R63061
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V5 1/2] powerpc/85xx: Add QE common init function
On Thu, 2013-09-26 at 17:37 +0800, Xie Xiaobo wrote:
+#ifdef CONFIG_QUICC_ENGINE
+void __init mpc85xx_qe_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe);
+ if (!np) {
+ np = of_find_node_by_name(NULL, qe);
+ if (!np) {
+ pr_err(%s: Could not find Quicc Engine node\n,
+ __func__);
+ return;
+ }
+ }
+
+ qe_reset();
+ of_node_put(np);
You're missing the of_device_is_available() check:
I will add this check, thanks.
- np = of_find_compatible_node(NULL, NULL, fsl,qe);
- if (!np) {
- np = of_find_node_by_name(NULL, qe);
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board support
Hi Scott,
-Original Message-
From: Wood Scott-B07421
Sent: Friday, September 27, 2013 5:27 AM
To: Xie Xiaobo-R63061
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Johnston Michael-
R49610
Subject: Re: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board support
+ /* CS2 for Display */
+ ssd1289@2,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = ssd1289;
+ reg = 0x2 0x 0x0002
+ 0x2 0x0002 0x0002;
+ };
Node names should be generic. What does ssd1289 do? If this is
actually the display device, then it should be called
display@2,0.
OK. The ssd1289 is a LCD controller.
How about a vendor prefix on that compatible? Why
#address-cells/#size- cells despite no child nodes? Where is a
binding that says what each of those two reg resources mean?
I will add the vendor prefix. I review the ssd1289 driver, and the
#address-cells/#size-cells were un-used. I will remove them.
And a binding?
Why do you need two separate reg resources rather than just 2 0 4?
Will they ever be discontiguous?
[Xie] I review the ssd1289 driver code, and found the driver need two
reg resources,
The device tree describes the hardware, not the current state of Linux
drivers. Especially drivers that aren't yet in Linux. :-)
OK, I will remain the display node.
if change the dts, the driver also should be modified accordingly. So
I remove the ssd1289 node from this patch. I will submit new patch
include the dts modification, ssd1289 driver and the binding.
Ideally all devices (and bindings) should be described when the device
tree is initally added, regardless of whether you have a driver yet.
I will add a binding document for the ssd1289 device.
-Scott
- Xiaobo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/boot: Properly handle the base of boot wrapper
The wrapper script needs an explicit rule for the of boot wrapper (generic wrapper, similar to pseries). Before 0c9fa29149d3726e14262aeb0c8461a948cc9d56 it was hanlded implicitly by the statement: platformo=$object/$platform.o But now that epapr.o needs to be added, that doesn't work and an explicit rule must be added. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/boot/wrapper | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index ac16e99..2e1af74 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -147,6 +147,10 @@ link_address='0x40' make_space=y case $platform in +of) +platformo=$object/of.o $object/epapr.o +make_space=n +;; pseries) platformo=$object/of.o $object/epapr.o link_address='0x400' ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
But fsl-ssi.o and fsl-spdif.o is based PowrePC platform? Which we can see from the comments. fsl_ssi was originally PPC-only, but it now supports PPC and ARM. You can see that from the git history. If there are any comments that say PPC but are not PPC-specific, that should be fixed. Yes, find it. The comments is in sound/soc/fsl/Makefile : +++ # Freescale PowerPC SSI/DMA Platform Support --- But fsl-spdif.o is also under it. And this is also support ARM and PowerPC platforms at the same time ? If so, the comments should be modified to : +++ # Freescale PowerPC and ARM SSI/DMA Platform Support --- Best Regards, Xiubo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
Li Xiubo wrote: If there are any comments that say PPC but are not PPC-specific, that should be fixed. Yes, find it. The comments is in sound/soc/fsl/Makefile : +++ # Freescale PowerPC SSI/DMA Platform Support --- But fsl-spdif.o is also under it. And this is also support ARM and PowerPC platforms at the same time ? If so, the comments should be modified to : +++ # Freescale PowerPC and ARM SSI/DMA Platform Support --- Yes, this should be changed. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
On Wed, 6 Nov 2013 06:52:13 Benjamin Herrenschmidt wrote:
[snip]
Why ? Do we need to add an entry for every platform in there ? Besides,
it probably should be the SoC name not the platform here
Why not simply a generic compatible usb-ehci ? It's a standard
programming interface, there are no specific quirks, we shouldn't
need to have to add new entries to the driver like that for every
new SoC/platform.
Actually a grep of usb-ehci turns up the ehci-ppc-of driver which I somehow
missed. This driver works and uses .compatible = usb-ehci so I can use that
instead if that is preferable?
However it is basically the same as the ehci-platform driver so I guess at
some point the two should be merged...
@@ -229,7 +230,7 @@ static struct platform_driver ehci_platform_driver =
{
.owner = THIS_MODULE,
.name = ehci-platform,
.pm = ehci_platform_pm_ops,
- .of_match_table = vt8500_ehci_ids,
+ .of_match_table = ehci_platform_ids,
}
};
Acked-by: Alan Stern st...@rowland.harvard.edu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
If there are any comments that say PPC but are not PPC-specific, that should be fixed. Yes, find it. The comments is in sound/soc/fsl/Makefile : +++ # Freescale PowerPC SSI/DMA Platform Support --- But fsl-spdif.o is also under it. And this is also support ARM and PowerPC platforms at the same time ? If so, the comments should be modified to : +++ # Freescale PowerPC and ARM SSI/DMA Platform Support --- Yes, this should be changed. How about : + # Freescale PowerPC and ARM SSI/DMA/SAI/SPDIF Platform Support - ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
On Wed, 2013-11-06 at 14:50 +1100, Alistair Popple wrote: Actually a grep of usb-ehci turns up the ehci-ppc-of driver which I somehow missed. This driver works and uses .compatible = usb-ehci so I can use that instead if that is preferable? However it is basically the same as the ehci-platform driver so I guess at some point the two should be merged... I think the split predates the grand unification of of driver and platform, so yes they should. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/kvm: simplify the entering logic for secondary thread
On Tue, Nov 05, 2013 at 03:42:42PM +0800, Liu Ping Fan wrote: After the primary vcpu changes vcore_state to VCORE_RUNNING, there is very little chance to schedule to secondary vcpu. So if we change the Why do you say there is very little chance to run the secondary vcpu? code sequence around set vcore_state to VCORE_RUNNING and disable preemption, we lost little. But we simplify the entering logi, based on the fact that if primary vcpu runs, the secondary vcpu can not be scheduled. If a vcpu does a hypercall or something else that requires the host (kernel or userspace) to do something, that can happen in the context of the vcpu task for that vcpu. That vcpu task can run on another core (unless it has been pinned). When it is finished we would like the vcpu to continue executing in the guest as soon as possible. The code that you remove in this patch enables that to happen without having to wait until the other threads exit the guest. So I don't think it is a good idea to remove this code. Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/kvm: fix rare but potential deadlock scene
On Tue, Nov 05, 2013 at 03:42:43PM +0800, Liu Ping Fan wrote: Since kvmppc_hv_find_lock_hpte() is called from both virtmode and realmode, so it can trigger the deadlock. Good catch, we should have preemption disabled while ever we have a HPTE locked. @@ -474,8 +474,10 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu *vcpu, gva_t eaddr, } /* Find the HPTE in the hash table */ + preempt_disable(); index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v, HPTE_V_VALID | HPTE_V_ABSENT); + preempt_enable(); Which means we need to add the preempt_enable after unlocking the HPTE, not here. Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/kvm: remove redundant assignment
On Tue, Nov 05, 2013 at 03:42:44PM +0800, Liu Ping Fan wrote:
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 28160ac..7682837 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -731,7 +731,6 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
struct kvm_vcpu *vcpu,
lock_rmap(rmap);
/* Check if we might have been invalidated; let the guest retry if so */
- ret = RESUME_GUEST;
if (mmu_notifier_retry(vcpu-kvm, mmu_seq)) {
unlock_rmap(rmap);
goto out_unlock;
Acked-by: Paul Mackerras pau...@samba.org
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, November 05, 2013 8:40 AM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wood Scott-B07421 Sent: Tuesday, November 05, 2013 5:52 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Sun, 2013-11-03 at 22:04 -0600, Wang Dongsheng-B40534 wrote: -Original Message- From: Wang Dongsheng-B40534 Sent: Monday, October 21, 2013 11:11 AM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wood Scott-B07421 Sent: Saturday, October 19, 2013 3:22 AM To: Wang Dongsheng-B40534 Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 2:46 PM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Thursday, October 17, 2013 11:22 AM To: Bhushan Bharat-R65777; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 11:20 AM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Thursday, October 17, 2013 8:16 AM To: Bhushan Bharat-R65777; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 1:01 AM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, October 15, 2013 2:51 PM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle From: Wang Dongsheng dongsheng.w...@freescale.com Add a sys interface to enable/diable pw20 state or altivec idle, and control the wait entry time. Enable/Disable interface: 0, disable. 1, enable. /sys/devices/system/cpu/cpuX/pw20_state /sys/devices/system/cpu/cpuX/altivec_idle Set wait time interface:(Nanosecond) /sys/devices/system/cpu/cpuX/pw20_wait_time /sys/devices/system/cpu/cpuX/altivec_idle_wait _t ime Example: Base on TBfreq is 41MHZ. 1~48(ns): TB[63] 49~97(ns): TB[62] 98~195(ns): TB[61] 196~390(ns): TB[60] 391~780(ns): TB[59] 781~1560(ns): TB[58] ... Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *v5: Change get_idle_ticks_bit function implementation. *v4: Move code from 85xx/common.c to kernel/sysfs.c. Remove has_pw20_altivec_idle function. Change wait entry_bit to wait time.
Re: [PATCH 2/3] powerpc/kvm: fix rare but potential deadlock scene
On Wed, Nov 6, 2013 at 1:04 PM, Paul Mackerras pau...@samba.org wrote: On Tue, Nov 05, 2013 at 03:42:43PM +0800, Liu Ping Fan wrote: Since kvmppc_hv_find_lock_hpte() is called from both virtmode and realmode, so it can trigger the deadlock. Good catch, we should have preemption disabled while ever we have a HPTE locked. @@ -474,8 +474,10 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu *vcpu, gva_t eaddr, } /* Find the HPTE in the hash table */ + preempt_disable(); index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v, HPTE_V_VALID | HPTE_V_ABSENT); + preempt_enable(); Which means we need to add the preempt_enable after unlocking the HPTE, not here. Yes. Sorry, but I am not sure about whether we can call preempt_disable/enable() in realmode. I think since thread_info is allocated with linear address, so we can use preempt_disable/enable() inside kvmppc_hv_find_lock_hpte(), right? Thanks and regards, Pingfan Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: memcpy optimization for 64bit LE
Philippe Bergheaud fe...@linux.vnet.ibm.com wrote: Unaligned stores take alignment exceptions on POWER7 running in little-endian. This is a dumb little-endian base memcpy that prevents unaligned stores. It is replaced by the VMX memcpy at boot. Is this any faster than the generic version? Mikey Signed-off-by: Philippe Bergheaud fe...@linux.vnet.ibm.com --- arch/powerpc/include/asm/string.h |4 arch/powerpc/kernel/ppc_ksyms.c |2 -- arch/powerpc/lib/Makefile |2 -- arch/powerpc/lib/memcpy_64.S | 19 +++ 4 files changed, 19 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/include/asm/string.h b/arch/powerpc/include/asm/string.h index 0dffad6..e40010a 100644 --- a/arch/powerpc/include/asm/string.h +++ b/arch/powerpc/include/asm/string.h @@ -10,9 +10,7 @@ #define __HAVE_ARCH_STRNCMP #define __HAVE_ARCH_STRCAT #define __HAVE_ARCH_MEMSET -#ifdef __BIG_ENDIAN__ #define __HAVE_ARCH_MEMCPY -#endif #define __HAVE_ARCH_MEMMOVE #define __HAVE_ARCH_MEMCMP #define __HAVE_ARCH_MEMCHR @@ -24,9 +22,7 @@ extern int strcmp(const char *,const char *); extern int strncmp(const char *, const char *, __kernel_size_t); extern char * strcat(char *, const char *); extern void * memset(void *,int,__kernel_size_t); -#ifdef __BIG_ENDIAN__ extern void * memcpy(void *,const void *,__kernel_size_t); -#endif extern void * memmove(void *,const void *,__kernel_size_t); extern int memcmp(const void *,const void *,__kernel_size_t); extern void * memchr(const void *,int,__kernel_size_t); diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c index 526ad5c..0c2dd60 100644 --- a/arch/powerpc/kernel/ppc_ksyms.c +++ b/arch/powerpc/kernel/ppc_ksyms.c @@ -147,9 +147,7 @@ EXPORT_SYMBOL(__ucmpdi2); #endif long long __bswapdi2(long long); EXPORT_SYMBOL(__bswapdi2); -#ifdef __BIG_ENDIAN__ EXPORT_SYMBOL(memcpy); -#endif EXPORT_SYMBOL(memset); EXPORT_SYMBOL(memmove); EXPORT_SYMBOL(memcmp); diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 5310132..6670361 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -23,9 +23,7 @@ obj-y += checksum_$(CONFIG_WORD_SIZE).o obj-$(CONFIG_PPC64) += checksum_wrappers_64.o endif -ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),) obj-$(CONFIG_PPC64) += memcpy_power7.o memcpy_64.o -endif obj-$(CONFIG_PPC_EMULATE_SSTEP) += sstep.o ldstfp.o diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S index d2bbbc8..358cf74 100644 --- a/arch/powerpc/lib/memcpy_64.S +++ b/arch/powerpc/lib/memcpy_64.S @@ -12,10 +12,28 @@ .align 7 _GLOBAL(memcpy) BEGIN_FTR_SECTION +#ifdef __LITTLE_ENDIAN__ + cmpdi cr7,r5,0 /* dumb little-endian memcpy */ +#else std r3,48(r1) /* save destination pointer for return value */ +#endif FTR_SECTION_ELSE b memcpy_power7 ALT_FTR_SECTION_END_IFCLR(CPU_FTR_VMX_COPY) +#ifdef __LITTLE_ENDIAN__ + addi r5,r5,-1 + addi r9,r3,-1 + add r5,r3,r5 + subf r5,r9,r5 + addi r4,r4,-1 + mtctr r5 + beqlr cr7 +1: + lbzu r10,1(r4) + stbu r10,1(r9) + bdnz 1b + blr +#else PPC_MTOCRF(0x01,r5) cmpldi cr1,r5,16 neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry @@ -201,3 +219,4 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_LD_STD) stb r0,0(r3) 4: ld r3,48(r1) /* return dest pointer */ blr +#endif -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/kvm: simplify the entering logic for secondary thread
On Wed, Nov 6, 2013 at 1:01 PM, Paul Mackerras pau...@samba.org wrote: On Tue, Nov 05, 2013 at 03:42:42PM +0800, Liu Ping Fan wrote: After the primary vcpu changes vcore_state to VCORE_RUNNING, there is very little chance to schedule to secondary vcpu. So if we change the Why do you say there is very little chance to run the secondary vcpu? code sequence around set vcore_state to VCORE_RUNNING and disable preemption, we lost little. But we simplify the entering logi, based on the fact that if primary vcpu runs, the secondary vcpu can not be scheduled. If a vcpu does a hypercall or something else that requires the host (kernel or userspace) to do something, that can happen in the context of the vcpu task for that vcpu. That vcpu task can run on another core (unless it has been pinned). When it is finished we would like the vcpu to continue executing in the guest as soon as possible. The code that you remove in this patch enables that to happen without having to wait until the other threads exit the guest. So I don't think it is a good idea to remove this code. Yes, you are right. Thanks and regards, Pingfan Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH] ehci-platform: Merge ppc-of EHCI driver into the ehci-platform driver
Currently the ppc-of driver uses the compatibility string
usb-ehci. This means platforms that use device-tree and implement an
EHCI compatible interface have to either use the ppc-of driver or add
a compatible line to the ehci-platform driver. It would be more
appropriate for the platform driver to be compatible with usb-ehci
as non-powerpc platforms are also beginning to utilise device-tree.
This patch merges the device tree property parsing from ehci-ppc-of
into the platform driver and adds a usb-ehci compatibility
string. The existing ehci-ppc-of driver is renamed to ehci-440epx as
it contains platform specific work arounds for the 440EPX SoC.
Signed-off-by: Alistair Popple alist...@popple.id.au
---
So I could submit something like this that essentially merges the ppc-of
driver into the platform driver instead of adding the ibm,akebono-ehci
compatible line to the platform driver.
However I'm still fairly new to device-tree so I'm not sure what (if any) the
broader impact would be. A quick grep for usb-ehci turned up a couple of ARM
device tree's using it however they all provided their own drivers and don't
select CONFIG_USB_EHCI_HCD_PLATFORM so I'm guess they shouldn't be impacted.
I have attempted to fix up any PowerPC device trees/configs, although I wasn't
sure if usb-ehci should remain in sequoia.dts or not given that it needs to
use the 440EPX specific driver.
Also this hasn't been tested (beyond compilation) yet.
arch/powerpc/boot/dts/sequoia.dts |2 +-
arch/powerpc/configs/44x/canyonlands_defconfig |1 +
drivers/usb/host/Kconfig |8 +-
drivers/usb/host/ehci-440epx.c | 236
drivers/usb/host/ehci-hcd.c|6 +-
drivers/usb/host/ehci-platform.c | 18 +-
drivers/usb/host/ehci-ppc-of.c | 236
7 files changed, 261 insertions(+), 246 deletions(-)
create mode 100644 drivers/usb/host/ehci-440epx.c
delete mode 100644 drivers/usb/host/ehci-ppc-of.c
diff --git a/arch/powerpc/boot/dts/sequoia.dts
b/arch/powerpc/boot/dts/sequoia.dts
index b1d3292..e28371e 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -153,7 +153,7 @@
};
USB0: ehci@e300 {
- compatible = ibm,usb-ehci-440epx, usb-ehci;
+ compatible = ibm,usb-ehci-440epx;
interrupt-parent = UIC0;
interrupts = 0x1a 0x4;
reg = 0x 0xe300 0x0090 0x
0xe390 0x0070;
diff --git a/arch/powerpc/configs/44x/canyonlands_defconfig
b/arch/powerpc/configs/44x/canyonlands_defconfig
index d5be93e..16dc37f 100644
--- a/arch/powerpc/configs/44x/canyonlands_defconfig
+++ b/arch/powerpc/configs/44x/canyonlands_defconfig
@@ -75,6 +75,7 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_MON=y
CONFIG_USB_EHCI_HCD=m
+CONFIG_USB_EHCI_HCD_PLATFORM=m
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
CONFIG_USB_OHCI_HCD_PPC_OF_LE=y
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index b3f20d7..b8d7c24 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,13 +188,13 @@ config USB_EHCI_TEGRA
This driver enables support for the internal USB Host Controllers
found in NVIDIA Tegra SoCs. The controllers are EHCI compliant.
-config USB_EHCI_HCD_PPC_OF
- bool EHCI support for PPC USB controller on OF platform bus
- depends on PPC_OF
+config USB_EHCI_HCD_440EPX
+ bool EHCI support for PPC USB controller on 440EPX
+ depends on PPC_OF 440EPX
default y
---help---
Enables support for the USB controller present on the PowerPC
- OpenFirmware platform bus.
+ 440EPX SoC.
config USB_EHCI_SH
bool EHCI support for SuperH USB controller
diff --git a/drivers/usb/host/ehci-440epx.c b/drivers/usb/host/ehci-440epx.c
new file mode 100644
index 000..4223700
--- /dev/null
+++ b/drivers/usb/host/ehci-440epx.c
@@ -0,0 +1,236 @@
+/*
+ * EHCI HCD (Host Controller Driver) for USB.
+ *
+ * Bus Glue for PPC On-Chip EHCI driver on the of_platform bus
+ * Tested on AMCC PPC 440EPx
+ *
+ * Valentine Barshak vbars...@ru.mvista.com
+ *
+ * Based on ehci-ppc-soc.c by Stefan Roese s...@denx.de
+ * and ohci-ppc-of.c by Sylvain Munaut t...@246tnt.com
+ *
+ * This file is licenced under the GPL.
+ */
+
+#include linux/err.h
+#include linux/signal.h
+
+#include linux/of.h
+#include linux/of_platform.h
+
+
+static const struct hc_driver ehci_440epx_hc_driver = {
+ .description= hcd_name,
+ .product_desc = OF EHCI,
+ .hcd_priv_size = sizeof(struct ehci_hcd),
+
+ /*
+* generic hardware linkage
+*/
+ .irq= ehci_irq,
+ .flags = HCD_MEMORY |
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message- From: Bhushan Bharat-R65777 Sent: Wednesday, November 06, 2013 1:25 PM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, November 05, 2013 8:40 AM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wood Scott-B07421 Sent: Tuesday, November 05, 2013 5:52 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Sun, 2013-11-03 at 22:04 -0600, Wang Dongsheng-B40534 wrote: -Original Message- From: Wang Dongsheng-B40534 Sent: Monday, October 21, 2013 11:11 AM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wood Scott-B07421 Sent: Saturday, October 19, 2013 3:22 AM To: Wang Dongsheng-B40534 Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 2:46 PM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Thursday, October 17, 2013 11:22 AM To: Bhushan Bharat-R65777; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 11:20 AM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Thursday, October 17, 2013 8:16 AM To: Bhushan Bharat-R65777; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 1:01 AM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, October 15, 2013 2:51 PM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle From: Wang Dongsheng dongsheng.w...@freescale.com Add a sys interface to enable/diable pw20 state or altivec idle, and control the wait entry time. Enable/Disable interface: 0, disable. 1, enable. /sys/devices/system/cpu/cpuX/pw20_state /sys/devices/system/cpu/cpuX/altivec_idle Set wait time interface:(Nanosecond) /sys/devices/system/cpu/cpuX/pw20_wait_time /sys/devices/system/cpu/cpuX/altivec_idle_wa it _t ime Example: Base on TBfreq is 41MHZ. 1~48(ns): TB[63] 49~97(ns): TB[62] 98~195(ns): TB[61] 196~390(ns): TB[60] 391~780(ns): TB[59] 781~1560(ns): TB[58] ...
