Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
On Thu, Jul 11, 2013 at 12:42:31AM -0400, Vince Weaver wrote: On Wed, 10 Jul 2013, Ingo Molnar wrote: Exactly - PMUs enumerated in /sys should be self-identifying, it's a hardware topology after all ... Anytime userspace is forced to look into /proc, or into weird places in /sys it's a FAIL really. well on x86 you have to look at /proc/cpuinfo to get the vendor/family/model number. Should we add some specifier under sys? It's probably too late though as all userspace event libs will have to look at /proc/cpuinfo anyway to be backwards compatible. If it's a new library implementing a new feature then no I don't think it needs to be backward compatible. It's just a choice the library makes as to what extent it depends on new kernel features. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4 V2] powerpc/85xx: Add support for 85xx cpu type detection
+#define IS_SVR_REV(svr, maj, min) \ + ((SVR_MAJ(svr) == (maj)) (SVR_MIN(svr) == (min))) I don't think IS_SVR_REV is needed. Callers can just do if (SVR_REV(svr) == 0x30) or whatever, especially since we're relying on them to do this for greater/less than comparisons. Not only that, I'd guess that 'maj' and 'min' are likely to be constants - so you'd want to combine them and compare against 'svr' rather than have two conditionals. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
On 07/10/2013 03:32 AM, Alexander Graf wrote:
On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote:
This adds special support for huge pages (16MB). The reference
counting cannot be easily done for such pages in real mode (when
MMU is off) so we added a list of huge pages. It is populated in
virtual mode and get_page is called just once per a huge page.
Real mode handlers check if the requested page is huge and in the list,
then no reference counting is done, otherwise an exit to virtual mode
happens. The list is released at KVM exit. At the moment the fastest
card available for tests uses up to 9 huge pages so walking through this
list is not very expensive. However this can change and we may want
to optimize this.
Signed-off-by: Paul Mackerraspau...@samba.org
Signed-off-by: Alexey Kardashevskiya...@ozlabs.ru
---
Changes:
2013/06/27:
* list of huge pages replaces with hashtable for better performance
So the only thing your patch description really talks about is not true
anymore?
* spinlock removed from real mode and only protects insertion of new
huge [ages descriptors into the hashtable
2013/06/05:
* fixed compile error when CONFIG_IOMMU_API=n
2013/05/20:
* the real mode handler now searches for a huge page by gpa (used to be pte)
* the virtual mode handler prints warning if it is called twice for the same
huge page as the real mode handler is expected to fail just once - when a
huge
page is not in the list yet.
* the huge page is refcounted twice - when added to the hugepage list and
when used in the virtual mode hcall handler (can be optimized but it will
make the patch less nice).
Signed-off-by: Alexey Kardashevskiya...@ozlabs.ru
---
arch/powerpc/include/asm/kvm_host.h | 25 +
arch/powerpc/kernel/iommu.c | 6 ++-
arch/powerpc/kvm/book3s_64_vio.c| 104
+---
arch/powerpc/kvm/book3s_64_vio_hv.c | 21 ++--
4 files changed, 146 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 53e61b2..a7508cf 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -30,6 +30,7 @@
#includelinux/kvm_para.h
#includelinux/list.h
#includelinux/atomic.h
+#includelinux/hashtable.h
#includeasm/kvm_asm.h
#includeasm/processor.h
#includeasm/page.h
@@ -182,10 +183,34 @@ struct kvmppc_spapr_tce_table {
u32 window_size;
struct iommu_group *grp;/* used for IOMMU groups */
struct vfio_group *vfio_grp;/* used for IOMMU groups */
+DECLARE_HASHTABLE(hash_tab, ilog2(64));/* used for IOMMU groups */
+spinlock_t hugepages_write_lock;/* used for IOMMU groups */
struct { struct { unsigned long put, indir, stuff; } rm, vm; } stat;
struct page *pages[0];
};
+/*
+ * The KVM guest can be backed with 16MB pages.
+ * In this case, we cannot do page counting from the real mode
+ * as the compound pages are used - they are linked in a list
+ * with pointers as virtual addresses which are inaccessible
+ * in real mode.
+ *
+ * The code below keeps a 16MB pages list and uses page struct
+ * in real mode if it is already locked in RAM and inserted into
+ * the list or switches to the virtual mode where it can be
+ * handled in a usual manner.
+ */
+#define KVMPPC_SPAPR_HUGEPAGE_HASH(gpa)hash_32(gpa 24, 32)
+
+struct kvmppc_spapr_iommu_hugepage {
+struct hlist_node hash_node;
+unsigned long gpa;/* Guest physical address */
+unsigned long hpa;/* Host physical address */
+struct page *page;/* page struct of the very first subpage */
+unsigned long size;/* Huge page size (always 16MB at the moment) */
+};
+
struct kvmppc_linear_info {
void*base_virt;
unsigned long base_pfn;
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 51678ec..e0b6eca 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -999,7 +999,8 @@ int iommu_free_tces(struct iommu_table *tbl, unsigned
long entry,
if (!pg) {
ret = -EAGAIN;
} else if (PageCompound(pg)) {
-ret = -EAGAIN;
+/* Hugepages will be released at KVM exit */
+ret = 0;
} else {
if (oldtce TCE_PCI_WRITE)
SetPageDirty(pg);
@@ -1009,6 +1010,9 @@ int iommu_free_tces(struct iommu_table *tbl,
unsigned long entry,
struct page *pg = pfn_to_page(oldtce PAGE_SHIFT);
if (!pg) {
ret = -EAGAIN;
+} else if (PageCompound(pg)) {
+/* Hugepages will be released at KVM exit */
+ret = 0;
} else {
if (oldtce TCE_PCI_WRITE)
SetPageDirty(pg);
diff --git
RE: [PATCH 1/4 V2] powerpc/85xx: Add support for 85xx cpu type detection
Thanks. Regards Haijun. -Original Message- From: David Laight [mailto:david.lai...@aculab.com] Sent: Thursday, July 11, 2013 4:44 PM To: Wood Scott-B07421; Zhang Haijun-B42677 Cc: Zhao Chenhui-B35336; linux-...@vger.kernel.org; Wrobel Heinz-R39252; Fleming Andy-AFLEMING; Zhang Haijun-B42677; cbouatmai...@gmail.com; c...@laptop.org; linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061 Subject: RE: [PATCH 1/4 V2] powerpc/85xx: Add support for 85xx cpu type detection +#define IS_SVR_REV(svr, maj, min) \ + ((SVR_MAJ(svr) == (maj)) (SVR_MIN(svr) == (min))) I don't think IS_SVR_REV is needed. Callers can just do if (SVR_REV(svr) == 0x30) or whatever, especially since we're relying on them to do this for greater/less than comparisons. Not only that, I'd guess that 'maj' and 'min' are likely to be constants - so you'd want to combine them and compare against 'svr' rather than have two conditionals. [Haijun Wrote:] yes, e.g: 1.0, 1.1 or 2.0. 'Major revision field' + '.' + 'Minor revision field ' I had resent the patch(V2). I'm not so clear about what you want to express.^_^ David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: enable the math emulation for the corenet64_smp_defconfig
On Wed, Jul 10, 2013 at 04:40:03PM -0500, Scott Wood wrote: On 07/09/2013 08:49:52 PM, Kevin Hao wrote: I got the following error on my t4240qds board. ntpd[2713]: unhandled signal 4 at 0fd5b448 nip 0fd5b448 lr 0fd5b424 code 30001 The root cause is that the float point instruction 'fsqrt' is used. But this instruction is not implemented on e6500 core. Even this does seem a gcc bug, I would like to enable the math emulation in the kernel to workaround this kind of issue. I'll apply this, but we should add PPC_WARN_EMULATED to math-emu so that people know when their toolchain is emitting things that require emulation. Sure. It'd also be nice if we had an option to only include the portions of math-emu that are known to be missing in some CPUs (excluding CPUs that are missing the entire FPU, of course). Besides its effect on kernel image size, in my experience math-emu adds a non-trivial amount of time to a kernel build. Sounds reasonable. I will give it a try. Thanks, Kevin -Scott pgpdB800Itn4E.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
On 11.07.2013, at 10:57, Alexey Kardashevskiy wrote:
On 07/10/2013 03:32 AM, Alexander Graf wrote:
On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote:
This adds special support for huge pages (16MB). The reference
counting cannot be easily done for such pages in real mode (when
MMU is off) so we added a list of huge pages. It is populated in
virtual mode and get_page is called just once per a huge page.
Real mode handlers check if the requested page is huge and in the list,
then no reference counting is done, otherwise an exit to virtual mode
happens. The list is released at KVM exit. At the moment the fastest
card available for tests uses up to 9 huge pages so walking through this
list is not very expensive. However this can change and we may want
to optimize this.
Signed-off-by: Paul Mackerraspau...@samba.org
Signed-off-by: Alexey Kardashevskiya...@ozlabs.ru
---
Changes:
2013/06/27:
* list of huge pages replaces with hashtable for better performance
So the only thing your patch description really talks about is not true
anymore?
* spinlock removed from real mode and only protects insertion of new
huge [ages descriptors into the hashtable
2013/06/05:
* fixed compile error when CONFIG_IOMMU_API=n
2013/05/20:
* the real mode handler now searches for a huge page by gpa (used to be pte)
* the virtual mode handler prints warning if it is called twice for the same
huge page as the real mode handler is expected to fail just once - when a
huge
page is not in the list yet.
* the huge page is refcounted twice - when added to the hugepage list and
when used in the virtual mode hcall handler (can be optimized but it will
make the patch less nice).
Signed-off-by: Alexey Kardashevskiya...@ozlabs.ru
---
arch/powerpc/include/asm/kvm_host.h | 25 +
arch/powerpc/kernel/iommu.c | 6 ++-
arch/powerpc/kvm/book3s_64_vio.c| 104
+---
arch/powerpc/kvm/book3s_64_vio_hv.c | 21 ++--
4 files changed, 146 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 53e61b2..a7508cf 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -30,6 +30,7 @@
#includelinux/kvm_para.h
#includelinux/list.h
#includelinux/atomic.h
+#includelinux/hashtable.h
#includeasm/kvm_asm.h
#includeasm/processor.h
#includeasm/page.h
@@ -182,10 +183,34 @@ struct kvmppc_spapr_tce_table {
u32 window_size;
struct iommu_group *grp;/* used for IOMMU groups */
struct vfio_group *vfio_grp;/* used for IOMMU groups */
+DECLARE_HASHTABLE(hash_tab, ilog2(64));/* used for IOMMU groups */
+spinlock_t hugepages_write_lock;/* used for IOMMU groups */
struct { struct { unsigned long put, indir, stuff; } rm, vm; } stat;
struct page *pages[0];
};
+/*
+ * The KVM guest can be backed with 16MB pages.
+ * In this case, we cannot do page counting from the real mode
+ * as the compound pages are used - they are linked in a list
+ * with pointers as virtual addresses which are inaccessible
+ * in real mode.
+ *
+ * The code below keeps a 16MB pages list and uses page struct
+ * in real mode if it is already locked in RAM and inserted into
+ * the list or switches to the virtual mode where it can be
+ * handled in a usual manner.
+ */
+#define KVMPPC_SPAPR_HUGEPAGE_HASH(gpa)hash_32(gpa 24, 32)
+
+struct kvmppc_spapr_iommu_hugepage {
+struct hlist_node hash_node;
+unsigned long gpa;/* Guest physical address */
+unsigned long hpa;/* Host physical address */
+struct page *page;/* page struct of the very first subpage */
+unsigned long size;/* Huge page size (always 16MB at the moment) */
+};
+
struct kvmppc_linear_info {
void*base_virt;
unsigned long base_pfn;
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 51678ec..e0b6eca 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -999,7 +999,8 @@ int iommu_free_tces(struct iommu_table *tbl, unsigned
long entry,
if (!pg) {
ret = -EAGAIN;
} else if (PageCompound(pg)) {
-ret = -EAGAIN;
+/* Hugepages will be released at KVM exit */
+ret = 0;
} else {
if (oldtce TCE_PCI_WRITE)
SetPageDirty(pg);
@@ -1009,6 +1010,9 @@ int iommu_free_tces(struct iommu_table *tbl,
unsigned long entry,
struct page *pg = pfn_to_page(oldtce PAGE_SHIFT);
if (!pg) {
ret = -EAGAIN;
+} else if (PageCompound(pg)) {
+/* Hugepages will be released at KVM exit */
+ret = 0;
} else {
if (oldtce TCE_PCI_WRITE)
[PATCH] mmc: dt: add host-off-card-on dt property
Add host-off-card-on dt property and parse it to support the quirk SDHCI_QUIRK2_HOST_OFF_CARD_ON. Signed-off-by: Wei Ni w...@nvidia.com --- Documentation/devicetree/bindings/mmc/mmc.txt |2 ++ drivers/mmc/host/sdhci-pltfm.c|3 +++ 2 files changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 85aada2..95ebe3e 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -28,6 +28,8 @@ Optional properties: - cap-mmc-highspeed: MMC high-speed timing is supported - cap-power-off-card: powering off the card is safe - cap-sdio-irq: enable SDIO IRQ signalling on this interface +- host-off-card-on: when resume, denote that card keeps power + but host controller does not, so that it will reset sdhci all. *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the normal and inverted diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index cd0f1f6..b3730cc 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -89,6 +89,9 @@ void sdhci_get_of_property(struct platform_device *pdev) if (of_get_property(np, no-1-8-v, NULL)) host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V; + if (of_get_property(np, host-off-card-on, NULL)) + host-quirks2 |= SDHCI_QUIRK2_HOST_OFF_CARD_ON; + if (of_device_is_compatible(np, fsl,p2020-rev1-esdhc)) host-quirks |= SDHCI_QUIRK_BROKEN_DMA; -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: enable the math emulation for the corenet64_smp_defconfig
It'd also be nice if we had an option to only include the portions of math-emu that are known to be missing in some CPUs (excluding CPUs that are missing the entire FPU, of course). Besides its effect on kernel image size, in my experience math-emu adds a non-trivial amount of time to a kernel build. Sounds reasonable. I will give it a try. It also ought to be possible to use the FPU when emulating the missing instructions - rather than using the full 'soft' FPU. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On 11.07.2013, at 07:12, Alexey Kardashevskiy wrote: On 07/10/2013 08:05 PM, Alexander Graf wrote: On 10.07.2013, at 07:00, Alexey Kardashevskiy wrote: On 07/10/2013 03:02 AM, Alexander Graf wrote: On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote: This adds real mode handlers for the H_PUT_TCE_INDIRECT and H_STUFF_TCE hypercalls for QEMU emulated devices such as IBMVIO devices or emulated PCI. These calls allow adding multiple entries (up to 512) into the TCE table in one call which saves time on transition to/from real mode. We don't mention QEMU explicitly in KVM code usually. This adds a tce_tmp cache to kvm_vcpu_arch to save valid TCEs (copied from user and verified) before writing the whole list into the TCE table. This cache will be utilized more in the upcoming VFIO/IOMMU support to continue TCE list processing in the virtual mode in the case if the real mode handler failed for some reason. This adds a guest physical to host real address converter and calls the existing H_PUT_TCE handler. The converting function is going to be fully utilized by upcoming VFIO supporting patches. This also implements the KVM_CAP_PPC_MULTITCE capability, so in order to support the functionality of this patch, QEMU needs to query for this capability and set the hcall-multi-tce hypertas property only if the capability is present, otherwise there will be serious performance degradation. Same as above. But really you're only giving recommendations here. What's the point? Please describe what the benefit of this patch is, not what some other random subsystem might do with the benefits it brings. Signed-off-by: Paul Mackerraspau...@samba.org Signed-off-by: Alexey Kardashevskiya...@ozlabs.ru --- Changelog: 2013/07/06: * fixed number of wrong get_page()/put_page() calls 2013/06/27: * fixed clear of BUSY bit in kvmppc_lookup_pte() * H_PUT_TCE_INDIRECT does realmode_get_page() now * KVM_CAP_SPAPR_MULTITCE now depends on CONFIG_PPC_BOOK3S_64 * updated doc 2013/06/05: * fixed mistype about IBMVIO in the commit message * updated doc and moved it to another section * changed capability number 2013/05/21: * added kvm_vcpu_arch::tce_tmp * removed cleanup if put_indirect failed, instead we do not even start writing to TCE table if we cannot get TCEs from the user and they are invalid * kvmppc_emulated_h_put_tce is split to kvmppc_emulated_put_tce and kvmppc_emulated_validate_tce (for the previous item) * fixed bug with failthrough for H_IPI * removed all get_user() from real mode handlers * kvmppc_lookup_pte() added (instead of making lookup_linux_pte public) Signed-off-by: Alexey Kardashevskiya...@ozlabs.ru --- Documentation/virtual/kvm/api.txt | 25 +++ arch/powerpc/include/asm/kvm_host.h | 9 ++ arch/powerpc/include/asm/kvm_ppc.h | 16 +- arch/powerpc/kvm/book3s_64_vio.c| 154 ++- arch/powerpc/kvm/book3s_64_vio_hv.c | 260 arch/powerpc/kvm/book3s_hv.c| 41 - arch/powerpc/kvm/book3s_hv_rmhandlers.S | 6 + arch/powerpc/kvm/book3s_pr_papr.c | 37 - arch/powerpc/kvm/powerpc.c | 3 + 9 files changed, 517 insertions(+), 34 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 6365fef..762c703 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2362,6 +2362,31 @@ calls by the guest for that service will be passed to userspace to be handled. +4.86 KVM_CAP_PPC_MULTITCE + +Capability: KVM_CAP_PPC_MULTITCE +Architectures: ppc +Type: vm + +This capability means the kernel is capable of handling hypercalls +H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user +space. This significanly accelerates DMA operations for PPC KVM guests. significanly? Please run this through a spell checker. +The user space should expect that its handlers for these hypercalls s/The// +are not going to be called. Is user space guaranteed they will not be called? Or can it still happen? ... if user space previously registered LIOBN in KVM (via KVM_CREATE_SPAPR_TCE or similar calls). ok? How about this? The hypercalls mentioned above may or may not be processed successfully in the kernel based fast path. If they can not be handled by the kernel, they will get passed on to user space. So user space still has to have an implementation for these despite the in kernel acceleration. --- The target audience for this documentation is user space KVM API users. Someone developing kvm tool for example. They want to know implications specific CAPs have. There is also KVM_CREATE_SPAPR_TCE_IOMMU but it is not in the kernel yet and may never get there. +In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest, +the user space might have to advertise it for the guest. For example,
Re: [PATCH] powerpc/85xx: enable the math emulation for the corenet64_smp_defconfig
On Thu, Jul 11, 2013 at 11:04:06AM +0100, David Laight wrote: It'd also be nice if we had an option to only include the portions of math-emu that are known to be missing in some CPUs (excluding CPUs that are missing the entire FPU, of course). Besides its effect on kernel image size, in my experience math-emu adds a non-trivial amount of time to a kernel build. Sounds reasonable. I will give it a try. It also ought to be possible to use the FPU when emulating the missing instructions - rather than using the full 'soft' FPU. Yes, it is another option. But it may seem a bit risky to do these floating point arithmetic in kernel space. Do we really want do that? Thanks, Kevin David pgp7uoRrB5Qb8.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
On Tue, Jul 09, 2013 at 04:05:30PM +0100, Vince Weaver wrote: On Tue, 9 Jul 2013, Peter Zijlstra wrote: On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote: So something like they have on ARM? vince@pandaboard:/sys/bus/event_source/devices$ ls -l lrwxrwxrwx 1 root root 0 Jul 8 21:57 ARMv7 Cortex-A9 - ../../../devices/ARMv7 Cortex-A9 lrwxrwxrwx 1 root root 0 Jul 8 21:57 breakpoint - ../../../devices/breakpoint lrwxrwxrwx 1 root root 0 Jul 8 21:57 software - ../../../devices/software lrwxrwxrwx 1 root root 0 Jul 8 21:57 tracepoint - ../../../devices/tracepoint Right so what I remember of the ARM case is that their /proc/cpuinfo isn't sufficient to identify their PMU. And they don't have a cpuid like instruction at all. libpfm4 uses the CPU part : 0xc09 line in /proc/cpuinfo on ARM, and that's enough for the processors PAPI supports (Cortex A8/A9/A15 plus the 1176 on the raspberry-pi). I'm guessing it wouldn't be enough if we wanted to support *all* ARMs with PMUs. The CPU part you cite is actually A9-specific, so you probably want to probe each CPU specifically. Take a look at the cpuinfo parsing in OProfile (used by operf). And speaking of ARM, I should be railing at them for breaking the ABI too, with their (understandable yet still ABI breaking) decision to remove BogoMIPS from /proc/cpuinfo. That change will impact PAPI as well as various other programs I maintain that have the misfortune of parsing that file. Really? Why are you checking for that line at all? Will ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On 11.07.2013, at 12:54, Alexey Kardashevskiy wrote: On 07/11/2013 08:11 PM, Alexander Graf wrote: On 11.07.2013, at 07:12, Alexey Kardashevskiy wrote: On 07/10/2013 08:05 PM, Alexander Graf wrote: On 10.07.2013, at 07:00, Alexey Kardashevskiy wrote: On 07/10/2013 03:02 AM, Alexander Graf wrote: On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote: This adds real mode handlers for the H_PUT_TCE_INDIRECT and H_STUFF_TCE hypercalls for QEMU emulated devices such as IBMVIO devices or emulated PCI. These calls allow adding multiple entries (up to 512) into the TCE table in one call which saves time on transition to/from real mode. We don't mention QEMU explicitly in KVM code usually. This adds a tce_tmp cache to kvm_vcpu_arch to save valid TCEs (copied from user and verified) before writing the whole list into the TCE table. This cache will be utilized more in the upcoming VFIO/IOMMU support to continue TCE list processing in the virtual mode in the case if the real mode handler failed for some reason. This adds a guest physical to host real address converter and calls the existing H_PUT_TCE handler. The converting function is going to be fully utilized by upcoming VFIO supporting patches. This also implements the KVM_CAP_PPC_MULTITCE capability, so in order to support the functionality of this patch, QEMU needs to query for this capability and set the hcall-multi-tce hypertas property only if the capability is present, otherwise there will be serious performance degradation. Same as above. But really you're only giving recommendations here. What's the point? Please describe what the benefit of this patch is, not what some other random subsystem might do with the benefits it brings. Signed-off-by: Paul Mackerraspau...@samba.org Signed-off-by: Alexey Kardashevskiya...@ozlabs.ru --- Changelog: 2013/07/06: * fixed number of wrong get_page()/put_page() calls 2013/06/27: * fixed clear of BUSY bit in kvmppc_lookup_pte() * H_PUT_TCE_INDIRECT does realmode_get_page() now * KVM_CAP_SPAPR_MULTITCE now depends on CONFIG_PPC_BOOK3S_64 * updated doc 2013/06/05: * fixed mistype about IBMVIO in the commit message * updated doc and moved it to another section * changed capability number 2013/05/21: * added kvm_vcpu_arch::tce_tmp * removed cleanup if put_indirect failed, instead we do not even start writing to TCE table if we cannot get TCEs from the user and they are invalid * kvmppc_emulated_h_put_tce is split to kvmppc_emulated_put_tce and kvmppc_emulated_validate_tce (for the previous item) * fixed bug with failthrough for H_IPI * removed all get_user() from real mode handlers * kvmppc_lookup_pte() added (instead of making lookup_linux_pte public) Signed-off-by: Alexey Kardashevskiya...@ozlabs.ru --- Documentation/virtual/kvm/api.txt | 25 +++ arch/powerpc/include/asm/kvm_host.h | 9 ++ arch/powerpc/include/asm/kvm_ppc.h | 16 +- arch/powerpc/kvm/book3s_64_vio.c| 154 ++- arch/powerpc/kvm/book3s_64_vio_hv.c | 260 arch/powerpc/kvm/book3s_hv.c| 41 - arch/powerpc/kvm/book3s_hv_rmhandlers.S | 6 + arch/powerpc/kvm/book3s_pr_papr.c | 37 - arch/powerpc/kvm/powerpc.c | 3 + 9 files changed, 517 insertions(+), 34 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 6365fef..762c703 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2362,6 +2362,31 @@ calls by the guest for that service will be passed to userspace to be handled. +4.86 KVM_CAP_PPC_MULTITCE + +Capability: KVM_CAP_PPC_MULTITCE +Architectures: ppc +Type: vm + +This capability means the kernel is capable of handling hypercalls +H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user +space. This significanly accelerates DMA operations for PPC KVM guests. significanly? Please run this through a spell checker. +The user space should expect that its handlers for these hypercalls s/The// +are not going to be called. Is user space guaranteed they will not be called? Or can it still happen? ... if user space previously registered LIOBN in KVM (via KVM_CREATE_SPAPR_TCE or similar calls). ok? How about this? The hypercalls mentioned above may or may not be processed successfully in the kernel based fast path. If they can not be handled by the kernel, they will get passed on to user space. So user space still has to have an implementation for these despite the in kernel acceleration. --- The target audience for this documentation is user space KVM API users. Someone developing kvm tool for example. They want to know implications specific CAPs have. There is also KVM_CREATE_SPAPR_TCE_IOMMU but it is not in the kernel yet and may never get there. +In order to enable
[PATCH 2/2] powerpc/math-emu: keep track of the instructions unimplemented by FPU
Some cores (such as Freescale BookE) don't implement all floating
point instructions in ISA. But some gcc versions do use these
instructions. So we would have to enable the math emulation in this
case. Add this to emulated instructions tracking statistics so that
the user has a way to know that its toolcahin emit these unimplemented
floating point instructions.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/math-emu/math.c | 50 +++-
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/math-emu/math.c b/arch/powerpc/math-emu/math.c
index 18ce6a7..9a98b6c 100644
--- a/arch/powerpc/math-emu/math.c
+++ b/arch/powerpc/math-emu/math.c
@@ -10,6 +10,7 @@
#include asm/sfp-machine.h
#include math-emu/double.h
+#include asm/emulated_ops.h
#define FLOATFUNC(x) extern int x(void *, void *, void *, void *)
@@ -222,10 +223,17 @@ do_mathemu(struct pt_regs *regs)
int idx = 0;
int (*func)(void *, void *, void *, void *);
int type = 0;
- int eflag, trap;
+ int eflag, trap, ret = -ENOSYS;
+ int has_hw_fpu = 0;
- if (get_user(insn, (u32 *)pc))
- return -EFAULT;
+#ifdef CONFIG_PPC_FPU
+ has_hw_fpu = 1;
+#endif
+
+ if (get_user(insn, (u32 *)pc)) {
+ ret = -EFAULT;
+ goto out;
+ }
switch (insn 26) {
case LFS: func = lfs; type = D; break;
@@ -249,7 +257,7 @@ do_mathemu(struct pt_regs *regs)
case STFDUX:func = stfd;type = XEU; break;
case STFIWX:func = stfiwx; type = XE; break;
default:
- goto illegal;
+ goto out;
}
break;
@@ -267,7 +275,7 @@ do_mathemu(struct pt_regs *regs)
case FNMSUBS: func = fnmsubs; type = ABC; break;
case FNMADDS: func = fnmadds; type = ABC; break;
default:
- goto illegal;
+ goto out;
}
break;
@@ -287,7 +295,7 @@ do_mathemu(struct pt_regs *regs)
case FNMSUB:func = fnmsub; type = ABC; break;
case FNMADD:func = fnmadd; type = ABC; break;
default:
- goto illegal;
+ goto out;
}
break;
}
@@ -309,12 +317,12 @@ do_mathemu(struct pt_regs *regs)
case MFFS: func = mffs;type = X; break;
case MTFSF: func = mtfsf; type = XFLB;break;
default:
- goto illegal;
+ goto out;
}
break;
default:
- goto illegal;
+ goto out;
}
switch (type) {
@@ -347,7 +355,7 @@ do_mathemu(struct pt_regs *regs)
case DU:
idx = (insn 16) 0x1f;
if (!idx)
- goto illegal;
+ goto out;
sdisp = (insn 0x);
op0 = (void *)current-thread.TS_FPR((insn 21) 0x1f);
@@ -375,7 +383,7 @@ do_mathemu(struct pt_regs *regs)
if (((insn 1) 0x3ff) == STFIWX)
op1 = (void *)(regs-gpr[(insn 11) 0x1f]);
else
- goto illegal;
+ goto out;
} else {
op1 = (void *)(regs-gpr[idx] + regs-gpr[(insn 11)
0x1f]);
}
@@ -417,7 +425,7 @@ do_mathemu(struct pt_regs *regs)
break;
default:
- goto illegal;
+ goto out;
}
/*
@@ -425,9 +433,8 @@ do_mathemu(struct pt_regs *regs)
* if flushed into the thread_struct before attempting
* emulation
*/
-#ifdef CONFIG_PPC_FPU
- flush_fp_to_thread(current);
-#endif
+ if (has_hw_fpu)
+ flush_fp_to_thread(current);
eflag = func(op0, op1, op2, op3);
@@ -437,8 +444,10 @@ do_mathemu(struct pt_regs *regs)
}
trap = record_exception(regs, eflag);
- if (trap)
- return 1;
+ if (trap) {
+ ret = 1;
+ goto out;
+ }
switch (type) {
case DU:
@@ -451,8 +460,11 @@ do_mathemu(struct pt_regs *regs)
}
regs-nip += 4;
- return 0;
+ ret = 0;
+
+out:
+ if (has_hw_fpu ret = 0)
+ PPC_WARN_EMULATED(math, regs);
-illegal:
- return -ENOSYS;
+ return ret;
}
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] powerpc/math-emu: two patches for the emulation of the FPU unimplemented instructions
These two patches are for the emulation of the FPU unimplemented instructions. The first is just a bit optimization for the FPU state flush. The second is requested by Scott. Kevin Hao (2): powerpc/math-emu: move the flush FPU state function into do_mathemu powerpc/math-emu: keep track of the instructions unimplemented by FPU arch/powerpc/kernel/traps.c | 9 arch/powerpc/math-emu/math.c | 53 +++- 2 files changed, 37 insertions(+), 25 deletions(-) -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/math-emu: move the flush FPU state function into do_mathemu
By doing this we can make sure that the FPU state is only flushed to
the thread struct when it is really needed.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/kernel/traps.c | 9 -
arch/powerpc/math-emu/math.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index bf33c22..58a8065 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1131,15 +1131,6 @@ void __kprobes program_check_exception(struct pt_regs
*regs)
* instruction or only on FP instructions, whether there is a
* pattern to occurrences etc. -dgibson 31/Mar/2003
*/
-
- /*
-* If we support a HW FPU, we need to ensure the FP state
-* if flushed into the thread_struct before attempting
-* emulation
-*/
-#ifdef CONFIG_PPC_FPU
- flush_fp_to_thread(current);
-#endif
switch (do_mathemu(regs)) {
case 0:
emulate_single_step(regs);
diff --git a/arch/powerpc/math-emu/math.c b/arch/powerpc/math-emu/math.c
index 3fe8e35..18ce6a7 100644
--- a/arch/powerpc/math-emu/math.c
+++ b/arch/powerpc/math-emu/math.c
@@ -420,6 +420,15 @@ do_mathemu(struct pt_regs *regs)
goto illegal;
}
+ /*
+* If we support a HW FPU, we need to ensure the FP state
+* if flushed into the thread_struct before attempting
+* emulation
+*/
+#ifdef CONFIG_PPC_FPU
+ flush_fp_to_thread(current);
+#endif
+
eflag = func(op0, op1, op2, op3);
if (insn 1) {
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On Thu, 2013-07-11 at 15:12 +1000, Alexey Kardashevskiy wrote: Any debug code is prohibited? Ok, I'll remove. Debug code that requires code changes is prohibited, yes. Debug code that is runtime switchable (pr_debug, trace points, etc) are allowed. Bollox. $ grep DBG\( arch/powerpc/ -r | wc -l 418 Also pr_devel is not runtime switchable in normal kernels either and still an official kernel interface. Is there any easy way to enable just this specific udbg_printf (not all of them at once)? Trace points do not work in real mode as we figured out. The cleaner way to do it is to use some kind of local macro that you enable/disable by changing a #define at the top of the function, possibly several. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
On Thu, 2013-07-11 at 11:52 +0200, Alexander Graf wrote: Where exactly (it is rather SPAPR_TCE_IOMMU but does not really matter)? Select it on KVM_BOOK3S_64? CONFIG_KVM_BOOK3S_64_HV? CONFIG_KVM_BOOK3S_64_PR? PPC_BOOK3S_64? I'd say the most logical choice would be to check the Makefile and see when it gets compiled. For those cases we want it enabled. What *what* gets compiled ? You know our Makefile, it's crap :-) We enable built-in things when CONFIG_KVM=m (which means you cannot take a kernel build with CONFIG_KVM not set, enable CONFIG_KVM=m, and just build the module, it won't work). We could use KVM_BOOK3S_64 maybe ? I am trying to imagine a configuration where we really do not want IOMMU_API. Ben mentioned PPC32 and embedded PPC64 and that's it so any of BOOK3S (KVM_BOOK3S_64 is the best) should be fine, no? book3s_32 doesn't want this, but any book3s_64 implementation could potentially use it, yes. That's pretty much what the Makefile tells you too :). Not really no. But that would do. You could have give a more useful answer in the first place though rather than stringing him along. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On Thu, 2013-07-11 at 12:11 +0200, Alexander Graf wrote: So I must add one more ioctl to enable MULTITCE in kernel handling. Is it what you are saying? I can see KVM_CHECK_EXTENSION but I do not see KVM_ENABLE_EXTENSION or anything like that. KVM_ENABLE_CAP. It's how we enable sPAPR capabilities too. But in that case I don't see the point. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote: And that's bad. Jeez, seriously. Don't argue this case. We enable new features individually unless we're 100% sure we can keep everything working. In this case an ENABLE_CAP doesn't hurt at all, because user space still needs to handle the hypercalls if it wants them anyways. But you get debugging for free for example. An ENABLE_CAP is utterly pointless. More bloat. But you seem to like it :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote: There are 2 ways of dealing with this: 1) Call the ENABLE_CAP on every vcpu. That way one CPU may handle this hypercall in the kernel while another one may not. The same as we handle PAPR today. 2) Create a new ENABLE_CAP for the vm. I think in this case option 1 is fine - it's how we handle everything else already. So, you are now asking him to chose between a gross horror or adding a new piece of infrastructure for something that is entirely pointless to begin with ? Come on, give him a break. That stuff is fine as it is. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/math-emu: keep track of the instructions unimplemented by FPU
On Thu, 2013-07-11 at 20:21 +0800, Kevin Hao wrote:
Some cores (such as Freescale BookE) don't implement all floating
point instructions in ISA. But some gcc versions do use these
instructions. So we would have to enable the math emulation in this
case. Add this to emulated instructions tracking statistics so that
the user has a way to know that its toolcahin emit these unimplemented
floating point instructions.
That patch is gross, it makes the function even more nasty than it
already is. Besides, CONFIG_PPC_FPU doesn't mean you have a HW FPU,
you need to check the CPU feature bits.
Also the caller already does PPC_WARN_EMULATED, so this patch makes
you call it twice or am I missing something ?
Cheers,
Ben.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/math-emu/math.c | 50
+++-
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/math-emu/math.c b/arch/powerpc/math-emu/math.c
index 18ce6a7..9a98b6c 100644
--- a/arch/powerpc/math-emu/math.c
+++ b/arch/powerpc/math-emu/math.c
@@ -10,6 +10,7 @@
#include asm/sfp-machine.h
#include math-emu/double.h
+#include asm/emulated_ops.h
#define FLOATFUNC(x) extern int x(void *, void *, void *, void *)
@@ -222,10 +223,17 @@ do_mathemu(struct pt_regs *regs)
int idx = 0;
int (*func)(void *, void *, void *, void *);
int type = 0;
- int eflag, trap;
+ int eflag, trap, ret = -ENOSYS;
+ int has_hw_fpu = 0;
- if (get_user(insn, (u32 *)pc))
- return -EFAULT;
+#ifdef CONFIG_PPC_FPU
+ has_hw_fpu = 1;
+#endif
+
+ if (get_user(insn, (u32 *)pc)) {
+ ret = -EFAULT;
+ goto out;
+ }
switch (insn 26) {
case LFS: func = lfs; type = D; break;
@@ -249,7 +257,7 @@ do_mathemu(struct pt_regs *regs)
case STFDUX:func = stfd;type = XEU; break;
case STFIWX:func = stfiwx; type = XE; break;
default:
- goto illegal;
+ goto out;
}
break;
@@ -267,7 +275,7 @@ do_mathemu(struct pt_regs *regs)
case FNMSUBS: func = fnmsubs; type = ABC; break;
case FNMADDS: func = fnmadds; type = ABC; break;
default:
- goto illegal;
+ goto out;
}
break;
@@ -287,7 +295,7 @@ do_mathemu(struct pt_regs *regs)
case FNMSUB:func = fnmsub; type = ABC; break;
case FNMADD:func = fnmadd; type = ABC; break;
default:
- goto illegal;
+ goto out;
}
break;
}
@@ -309,12 +317,12 @@ do_mathemu(struct pt_regs *regs)
case MFFS: func = mffs;type = X; break;
case MTFSF: func = mtfsf; type = XFLB;break;
default:
- goto illegal;
+ goto out;
}
break;
default:
- goto illegal;
+ goto out;
}
switch (type) {
@@ -347,7 +355,7 @@ do_mathemu(struct pt_regs *regs)
case DU:
idx = (insn 16) 0x1f;
if (!idx)
- goto illegal;
+ goto out;
sdisp = (insn 0x);
op0 = (void *)current-thread.TS_FPR((insn 21) 0x1f);
@@ -375,7 +383,7 @@ do_mathemu(struct pt_regs *regs)
if (((insn 1) 0x3ff) == STFIWX)
op1 = (void *)(regs-gpr[(insn 11) 0x1f]);
else
- goto illegal;
+ goto out;
} else {
op1 = (void *)(regs-gpr[idx] + regs-gpr[(insn 11)
0x1f]);
}
@@ -417,7 +425,7 @@ do_mathemu(struct pt_regs *regs)
break;
default:
- goto illegal;
+ goto out;
}
/*
@@ -425,9 +433,8 @@ do_mathemu(struct pt_regs *regs)
* if flushed into the thread_struct before attempting
* emulation
*/
-#ifdef CONFIG_PPC_FPU
- flush_fp_to_thread(current);
-#endif
+ if (has_hw_fpu)
+ flush_fp_to_thread(current);
eflag = func(op0, op1, op2, op3);
@@ -437,8 +444,10 @@ do_mathemu(struct pt_regs *regs)
}
trap = record_exception(regs, eflag);
- if (trap)
- return 1;
+ if (trap) {
+ ret = 1;
+ goto out;
+ }
switch (type) {
case DU:
@@ -451,8 +460,11 @@ do_mathemu(struct pt_regs *regs)
}
regs-nip += 4;
- return 0;
+ ret = 0;
+
+out:
+ if
Re: [PATCH 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
On 11.07.2013, at 14:37, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 11:52 +0200, Alexander Graf wrote: Where exactly (it is rather SPAPR_TCE_IOMMU but does not really matter)? Select it on KVM_BOOK3S_64? CONFIG_KVM_BOOK3S_64_HV? CONFIG_KVM_BOOK3S_64_PR? PPC_BOOK3S_64? I'd say the most logical choice would be to check the Makefile and see when it gets compiled. For those cases we want it enabled. What *what* gets compiled ? You know our Makefile, it's crap :-) We enable built-in things when CONFIG_KVM=m (which means you cannot take a kernel build with CONFIG_KVM not set, enable CONFIG_KVM=m, and just build the module, it won't work). We could use KVM_BOOK3S_64 maybe ? If either a =m or a =y option selects a =y option, it gets selected regardless, no? So it shouldn't really matter where we attach it FWIW. I am trying to imagine a configuration where we really do not want IOMMU_API. Ben mentioned PPC32 and embedded PPC64 and that's it so any of BOOK3S (KVM_BOOK3S_64 is the best) should be fine, no? book3s_32 doesn't want this, but any book3s_64 implementation could potentially use it, yes. That's pretty much what the Makefile tells you too :). Not really no. But that would do. You could have give a more useful answer in the first place though rather than stringing him along. Sorry, I figured it was obvious. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On 11.07.2013, at 14:39, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote: And that's bad. Jeez, seriously. Don't argue this case. We enable new features individually unless we're 100% sure we can keep everything working. In this case an ENABLE_CAP doesn't hurt at all, because user space still needs to handle the hypercalls if it wants them anyways. But you get debugging for free for example. An ENABLE_CAP is utterly pointless. More bloat. But you seem to like it :-) I don't like bloat usually. But Alexey even had an #ifdef DEBUG in there to selectively disable in-kernel handling of multi-TCE. Not calling ENABLE_CAP would give him exactly that without ugly #ifdefs in the kernel. Alex Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On 07/11/2013 10:51 PM, Alexander Graf wrote: On 11.07.2013, at 14:39, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote: And that's bad. Jeez, seriously. Don't argue this case. We enable new features individually unless we're 100% sure we can keep everything working. In this case an ENABLE_CAP doesn't hurt at all, because user space still needs to handle the hypercalls if it wants them anyways. But you get debugging for free for example. An ENABLE_CAP is utterly pointless. More bloat. But you seem to like it :-) I don't like bloat usually. But Alexey even had an #ifdef DEBUG in there to selectively disable in-kernel handling of multi-TCE. Not calling ENABLE_CAP would give him exactly that without ugly #ifdefs in the kernel. No, it would not give m anithing. My ugly debug was to disable realmode only and still leave virtual mode on, not to disable both real and virtual modes. It is a lot easier to disable in kernel handling in QEMU. -- Alexey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
On Thu, 2013-07-11 at 14:50 +0200, Alexander Graf wrote: Not really no. But that would do. You could have give a more useful answer in the first place though rather than stringing him along. Sorry, I figured it was obvious. It wasn't no, because of the mess with modules and the nasty Makefile we have in there. Even I had to scratch my head for a bit :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On Thu, 2013-07-11 at 14:51 +0200, Alexander Graf wrote: I don't like bloat usually. But Alexey even had an #ifdef DEBUG in there to selectively disable in-kernel handling of multi-TCE. Not calling ENABLE_CAP would give him exactly that without ugly #ifdefs in the kernel. I don't see much point in disabling it... but ok, if that's a valuable feature, then shoot some VM level ENABLE_CAP (please don't iterate all VCPUs, that's gross). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On 11.07.2013, at 14:33, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 15:12 +1000, Alexey Kardashevskiy wrote: Any debug code is prohibited? Ok, I'll remove. Debug code that requires code changes is prohibited, yes. Debug code that is runtime switchable (pr_debug, trace points, etc) are allowed. Bollox. $ grep DBG\( arch/powerpc/ -r | wc -l 418 Also pr_devel is not runtime switchable in normal kernels either and still an official kernel interface. Is there any easy way to enable just this specific udbg_printf (not all of them at once)? Trace points do not work in real mode as we figured out. The cleaner way to do it is to use some kind of local macro that you enable/disable by changing a #define at the top of the function, possibly several. If you do that in a way that doesn't bitrot, that's acceptable, yes. Something that leaves cpp compile checks working while optimizing out the debug code. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On 07/11/2013 10:58 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 14:51 +0200, Alexander Graf wrote: I don't like bloat usually. But Alexey even had an #ifdef DEBUG in there to selectively disable in-kernel handling of multi-TCE. Not calling ENABLE_CAP would give him exactly that without ugly #ifdefs in the kernel. I don't see much point in disabling it... but ok, if that's a valuable feature, then shoot some VM level ENABLE_CAP (please don't iterate all VCPUs, that's gross). No use for me whatsoever as I only want to disable real more handlers and keep virtual mode handlers enabled (sometime, for debug only) and this capability is not about that - I can easily just not enable it in QEMU with the exactly the same effect. So please, fellas, decide whether I should iterate vcpu's or add ENABLE_CAP per KVM. Thanks. -- Alexey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] KVM: PPC: Add support for multiple-TCE hcalls
On 11.07.2013, at 15:13, Alexey Kardashevskiy wrote: On 07/11/2013 10:58 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 14:51 +0200, Alexander Graf wrote: I don't like bloat usually. But Alexey even had an #ifdef DEBUG in there to selectively disable in-kernel handling of multi-TCE. Not calling ENABLE_CAP would give him exactly that without ugly #ifdefs in the kernel. I don't see much point in disabling it... but ok, if that's a valuable feature, then shoot some VM level ENABLE_CAP (please don't iterate all VCPUs, that's gross). No use for me whatsoever as I only want to disable real more handlers and keep virtual mode handlers enabled (sometime, for debug only) and this capability is not about that - I can easily just not enable it in QEMU with the exactly the same effect. So please, fellas, decide whether I should iterate vcpu's or add ENABLE_CAP per KVM. Thanks. Thinking hard about this it might actually be ok to not have an ENABLE_CAP for this, if kernel code always works properly, because from the guest's point of view nothing changes - it either gets handled by kernel or by user space. And user space either handles it or doesn't, so it's ok. Just leave it out this time. But be very weary of adding new features without an ENABLE_CAP switch. They might be guest visible changes. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
On 11.07.2013, at 15:41, chandrashekar shastri wrote: Hi All, I complied the latest kernel 3.10.0+ pulled from the git on top of 3.10.0-rc5+ by enabling the new Virtualiztaion features. The compliation was sucessfull, when I rebooted the machine it fails to boot with error as systemd [1] : Failed to mount /dev : no such device. Is it problem with the KVM module? Very unlikely. You're probably missing generic config options in your .config file. But this is very off topic for a) this thread and b) these mailing lists. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
On 07/11/2013 11:41 PM, chandrashekar shastri wrote: Hi All, I complied the latest kernel 3.10.0+ pulled from the git on top of 3.10.0-rc5+ by enabling the new Virtualiztaion features. The compliation was sucessfull, when I rebooted the machine it fails to boot with error as systemd [1] : Failed to mount /dev : no such device. Is it problem with the KVM module? Wrong thread actually, would be better if you started the new one. And you may want to try this - http://patchwork.ozlabs.org/patch/256027/ -- Alexey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
On Wed, Jul 10, 2013 at 06:43:54PM +0800, Nicolin Chen wrote:
The code enabled SSIEN when triggered by SNDRV_PCM_TRIGGER_START,
so move the disable code to SNDRV_PCM_TRIGGER_STOP for symmetric.
This also allows us to use the SSI driver more flexible so that
it can support some use cases like aplay S16_LE.wav S24_LE.wav
which would call the driver in sequence like:
startup()-hw_params(S16_LE)-trigger(START)-tirgger(STOP)-
hw_params(S24_LE)-trigger(START)-tirgger(STOP)-shutdown()
If we disable SSIEN in shutdown(), the second hw_params() would
bypass the sample bits setting while using symmetric_rate.
Signed-off-by: Nicolin Chen b42...@freescale.com
Acked-by: Shawn Guo shawn@linaro.org
---
sound/soc/fsl/fsl_ssi.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 2f2d837..b6ab341 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -510,6 +510,9 @@ static int fsl_ssi_trigger(struct snd_pcm_substream
*substream, int cmd,
write_ssi_mask(ssi-scr, CCSR_SSI_SCR_TE, 0);
else
write_ssi_mask(ssi-scr, CCSR_SSI_SCR_RE, 0);
+
+ if ((read_ssi(ssi-scr) (CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE))
== 0)
+ write_ssi_mask(ssi-scr, CCSR_SSI_SCR_SSIEN, 0);
break;
default:
@@ -534,15 +537,6 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream
*substream,
ssi_private-first_stream = ssi_private-second_stream;
ssi_private-second_stream = NULL;
-
- /*
- * If this is the last active substream, disable the SSI.
- */
- if (!ssi_private-first_stream) {
- struct ccsr_ssi __iomem *ssi = ssi_private-ssi;
-
- write_ssi_mask(ssi-scr, CCSR_SSI_SCR_SSIEN, 0);
- }
}
static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()
On 07/10/2013 10:00:33 PM, tiejun.chen wrote:
On 07/11/2013 03:15 AM, Scott Wood wrote:
On 07/10/2013 01:02:19 AM, Tiejun Chen wrote:
We should ensure the preemption cannot occur while calling
get_paca()
insdide hard_irq_disable(), otherwise the paca_struct may be the
wrong one just after. And btw, we may update timing stats in this
case.
The soft-ee mechanism depends on accessing the PACA directly via r13
to avoid
this. We probably should be using inline asm to read was_enabled
rather than
Yes.
hoping the compiler doesn't do anything silly.
Do you recommend I should directly replace get_paca() with local_paca
inside hard_irq_disable()?
#define hard_irq_disable() do {\
u8 _was_enabled = get_paca()-soft_enabled; \
- u8 _was_enabled = local_paca-soft_enabled;
But is this safe for all scenarios?
get_paca() is just a #define for local_paca. It won't make a
difference, other than to evade the debug check.
In practice, it's unlikely that GCC would do anything other than a load
directly from r13, but to be sure we should use inline asm to do the
load, just like arch_local_save_flags and arch_local_irq_disable do.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4 V2] powerpc/85xx: Add support for 85xx cpu type detection
On 07/11/2013 03:43:35 AM, David Laight wrote: +#define IS_SVR_REV(svr, maj, min) \ + ((SVR_MAJ(svr) == (maj)) (SVR_MIN(svr) == (min))) I don't think IS_SVR_REV is needed. Callers can just do if (SVR_REV(svr) == 0x30) or whatever, especially since we're relying on them to do this for greater/less than comparisons. Not only that, I'd guess that 'maj' and 'min' are likely to be constants - so you'd want to combine them and compare against 'svr' rather than have two conditionals. Yes, that's what I meant -- 0x30 would represent revision 3.0. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/math-emu: keep track of the instructions unimplemented by FPU
On 07/11/2013 07:45:21 AM, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 20:21 +0800, Kevin Hao wrote: Some cores (such as Freescale BookE) don't implement all floating point instructions in ISA. But some gcc versions do use these instructions. So we would have to enable the math emulation in this case. Add this to emulated instructions tracking statistics so that the user has a way to know that its toolcahin emit these unimplemented floating point instructions. That patch is gross, it makes the function even more nasty than it already is. Besides, CONFIG_PPC_FPU doesn't mean you have a HW FPU, you need to check the CPU feature bits. Also the caller already does PPC_WARN_EMULATED, so this patch makes you call it twice or am I missing something ? Sorry, that was my fault -- for some reason I didn't see that when I grepped for PPC_WARN_EMULATED looking for math stuff, and thus requested it be added. In any case, I don't see why it should be conditional on having an FPU (and indeed, the warning in the caller isn't conditional). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 答复: [PATCH] Powerpc/t4240: change the compatible flags for t4240qds board
On 07/10/2013 08:02:31 PM, Zhang Haijun-B42677 wrote: Also make sure that you only do this for quirks that are actually board- specific. In your last patch you had two quirks keyed off of the board, one of which is keyed off of the SoC for other chips. [Haijun Wrote:] Actually there are only one board with T4240 Soc. What about customer boards? In any case, it's not a reason to look for the wrong thing. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
Hi All, I complied the latest kernel 3.10.0+ pulled from the git on top of 3.10.0-rc5+ by enabling the new Virtualiztaion features. The compliation was sucessfull, when I rebooted the machine it fails to boot with error as systemd [1] : Failed to mount /dev : no such device. Is it problem with the KVM module? Thanks, Shastri On 07/11/2013 06:26 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 14:50 +0200, Alexander Graf wrote: Not really no. But that would do. You could have give a more useful answer in the first place though rather than stringing him along. Sorry, I figured it was obvious. It wasn't no, because of the mess with modules and the nasty Makefile we have in there. Even I had to scratch my head for a bit :-) Ben. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
On 07/11/2013 11:54 AM, Mark Brown wrote: The code enabled SSIEN when triggered by SNDRV_PCM_TRIGGER_START, so move the disable code to SNDRV_PCM_TRIGGER_STOP for symmetric. Applied, thanks. Don't you need an ACK from the maintainer of the driver before applying it? I haven't had a chance to test it yet. -- Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
On Wed, Jul 10, 2013 at 06:43:54PM +0800, Nicolin Chen wrote: The code enabled SSIEN when triggered by SNDRV_PCM_TRIGGER_START, so move the disable code to SNDRV_PCM_TRIGGER_STOP for symmetric. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
On Thu, 11 Jul 2013, Will Deacon wrote: On Tue, Jul 09, 2013 at 04:05:30PM +0100, Vince Weaver wrote: libpfm4 uses the CPU part : 0xc09 line in /proc/cpuinfo on ARM, and that's enough for the processors PAPI The CPU part you cite is actually A9-specific, so you probably want to probe each CPU specifically. Take a look at the cpuinfo parsing in OProfile (used by operf). I meant we use the CPU part line to probe things. I just cut and pasted from a Cortex A9 I had handy as an example. And speaking of ARM, I should be railing at them for breaking the ABI too, with their (understandable yet still ABI breaking) decision to remove BogoMIPS from /proc/cpuinfo. That change will impact PAPI as well as various other programs I maintain that have the misfortune of parsing that file. Really? Why are you checking for that line at all? Old programs. PAPI dates back to the day when processor frequency was meaningful (and stable). In cases where MHz wasn't reported in cpuinfo (mostly MIPS and ARM) it tries to estimate it based on BogoMIPS. Not the sanest thing to do, but it worked well enough at the time. We recently fixed things so it should do something reasonable if BogoMIPS is missing, but if users wrote their code poorly they can get divide by zero errors if BogoMIPS suddenly goes missing from /proc/cpuinfo (and yes we have had a low but non-zero number of users report bugs of this type). Other programs I have (like linux_logo and ll) are 15+ years old and simply print the BogoMIPS value for historical reasons. So they won't break if the value goes away but it's still sad to see it go. Vince ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 V4] powerpc/85xx: add the P1020RDB-PD DTS support
On 07/09/2013 09:24:57 PM, Haijun Zhang wrote:
+ nand@1,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,p1020-fcm-nand,
+fsl,elbc-fcm-nand;
+ reg = 0x1 0x0 0x4;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = 0x0 0x0010;
+ label = NAND U-Boot Image;
+ read-only;
+ };
+
+ partition@10 {
+ /* 1MB for DTB Image */
+ reg = 0x0010 0x0010;
+ label = NAND DTB Image;
+ };
+
+ partition@20 {
+ /* 4MB for Linux Kernel Image */
+ reg = 0x0020 0x0040;
+ label = NAND Linux Kernel Image;
+ };
+
+ partition@60 {
+ /* 96MB for File System Image */
+ reg = 0x0060 0x0600;
+ label = NAND FILE System Image;
+ };
This accounts for 102 MiB of the flash. The rest is just unused? Why
not increase the filesystem partition?
Also, why capitalize FILE?
+ spi@7000 {
+ flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25sl12801;
+ reg = 0;
+ /* input clock */
+ spi-max-frequency = 4000;
+
+ partition@0 {
+ /* 512KB for u-boot Bootloader
Image */
+ reg = 0x0 0x0008;
+ label = SPI U-Boot Image;
+ read-only;
+ };
+
+ partition@8 {
+ /* 512KB for DTB Image*/
+ reg = 0x0008 0x0008;
+ label = SPI DTB Image;
+ };
+
+ partition@10 {
+ /* 4MB for Linux Kernel Image */
+ reg = 0x0010 0x0040;
+ label = SPI Linux Kernel
Image;
+ };
+
+ partition@50 {
+ /* 7MB for FS System Image */
+ reg = 0x0050 0x0070;
+ label = SPI File System Image;
+ };
+ };
Likewise.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Inbound PCI and Memory Corruption
On Wed, Jul 10, 2013 at 2:40 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Did you get any traces that show the flow that happens around a case of corruption ? Well, I captured a lot of data, both logging kernel output and capturing PCI traffic. I've put the full console log output on pastebin at http://pastebin.com/ZFYbneNR The initial corruption is a starting address of 0xe94f17f8. Looking at the dumped data: Slab corruption: fib6_nodes start=e94f17f8, len=32 Redzone: 0x9f911029d74e35b/0xd4bed90f1c6f0806. Last user: [06040001](0x6040001) 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ff ff ff ff ff ff Prev obj: start=e94f17c0, len=32 Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Last user: [ (null)](0x0) 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 Next obj: start=e94f1830, len=32 Redzone: 0xd4bed90f1c6f0aca/0xafba11029d74e35b. Last user: [ (null)](0x0) 000: 0d 5b 00 00 00 00 00 00 0a ca 0d 01 00 00 00 00 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bd 3e The first corrupted byte is at address 0xe94f1802. Looking at the dump of all the DMA mappings this range is never mapped. Nor is there a single PCI write to this mapped address either. However, I did find some correlation to a PCI write to a near address. From the PCI capture: Command | Address | Data | /BE Mem Wr | 294F1810 | | | | | 0011 | | | | | 0FD9BED4 | | | 06086F1C | | | 00080100 | | | 01000406 | | | 0FD9BED4 | | | CA0A6F1C | | | 5B0D | | | | | | 010DCA0A | | | | | | | | | | | | | | | 3EBD | 1100 The data in this write looks very much like the pattern in the detected slab corruption. Looking at the PCI trace, it doesn't appear to be the incoming PCI data (unless the PCI Inbound Address Translation registers are misconfigured). Yet clearly these are corrupted with ethernet traffic. Thanks, Pete ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
kernel hang when initializing usb
Hi Tony/Greg/Liu, I'am Ravi working on a P2040 based custom board which has a compact flash connected to USB port via CYPRESS USB to IDE bridge. I am able to see the USB mass storage device from uboot but when I boot to kernel it hangs. Below is the dump that shows the part where it hangs. I have added some debug prints and narrowed down that the hang happens when it is trying to write to port status(portsc) register. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver 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: Before invoking reset ehci_fsl_setup got invoked.. Before invoking ehci_readl Before invoking ehci_halt ehci_writel invoked with val=0x0, reg=0xf125e148 Before invoking ehci_init Before invoking ehci_reset ehci_writel invoked with val=0x80002, reg=0xf125e140 ehci_writel invoked with val=0x3, reg=0xf125e1a8 Before invoking ehci_fsl_reinit Entering ehci_fsl_usb_setup with op_mode=0x1 have_sysif_regs=0x1 Completed SNOOPing of 4GB space Before invoking ehci_fsl_setup_phy with phy_mode=0x2 Entering ehci_fsl_setup_phy, portsc=0x0 port_offset=0x0 port_status_addr=0xf125e184 Before invoking mdelay, cntrlr_ver=0x1 Before invoking ehci_writel, portsc=0x0 port_offset=0x0 port_status_addr=0xf125e184 ehci_writel invoked with val=0x0, reg=0xf125e184 Kernel I am using is Linux version 3.0.51-rt75 and it looks like it has all the required patches described in the thread(http://thread.gmane.org/gmane.linux.usb.general/58763/focus=58795) but I still see the hang. Can one you give some pointers to troubleshoot what may be causing this hang Below is the email in which Tony had mentioned that he is also seeing the hang even after applying all the prescribed patches. Tony were you able to find the cause for the hang ? If so can you please share what was the fix that you made. Re: [ 011/108] powerpc/usb: fix bug of kernel hang when initializing usb Remove Highlighting [In reply to] Greg KH gregkh [at] linuxfoundation writes: 3.0-stable review patch. If anyone has any objections, please let me know. -- From: Shengzhou Liu Shengzhou.Liu [at] freescale commit 28c56ea1431421dec51b7b229369e991481453df upstream. If USB UTMI PHY is not enable, writing to portsc register will lead to kernel hang during boot up. I apologize for the late response, but I was encountering this same hang (on an 8315) and applied this patch. (For what it's worth, I'm only seeing it after many warm boots; a cold boot / hard power cycle solves the issue, but since this is eventually going to be locked up in a box without a console...) I encountered the hang again this evening, so this fix (plus the snoop fix) is not sufficientl Reading through the original thread, it seems that an additional delay might be required: http://article.gmane.org/gmane.linux.usb.general/58795 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). However, I never saw a patch to that effect. I'm assuming (hoping!) it's something as simple as: diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c index 09fd214..d58c1c6 100644 --- a/drivers/usb/host/ehci-fsl.c +++ b/drivers/usb/host/ehci-fsl.c @@ -236,6 +236,7 @@ static void ehci_fsl_setup_phy(struct ehci_hcd *ehci, case FSL_USB2_PHY_UTMI: /* enable UTMI PHY */ setbits32(non_ehci + FSL_SOC_USB_CTRL, CTRL_UTMI_PHY_EN); + msleep(5); portsc |= PORT_PTS_UTMI; break; case FSL_USB2_PHY_NONE: But confirmation would be nice. Also, which SDK kernel was this compared against? I just downloaded the 8315ERDB BSP, and the kernel there doesn't seem to have any of this in it. There was also the follow-on patch that enabled snooping (to deal with cache coherency?): http://article.gmane.org/gmane.linux.usb.general/58798 (If there was a formal patch there, it looks like it got scrambled on gmane, and I can't find another list archive.) Is that also needed for consistent results here? (Or are we wandering astray from -stable material?) Thanks, Tony. Thanks Regards, Ravi.. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
visible memory seems wrong in kexec crash dump kernel
Hi, I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system with 8GB of memory. (It's an embedded system and I can't do much about the fact that it's using older software.) I booted the original kernel with crashkernel=224M@32M in the boot args. I then loaded the crash kernel with: ./kexec -p vmlinux.kontron.strip --append=root=/dev/mtdblock0 rw rootfstype=jffs2 panic=5 1 maxcpus=1 noirqdistrib reset_devices Then I triggered a crash: echo 1 /proc/sys/kernel/sysrq echo c /proc/sysrq-trigger When the crash kernel came up, it had elfcorehdr=48392K savemaxmem=8192M in the kernel boot args, and free showed the system as having 7908652 KB of total memory instead of the expected 224MB. Do I need to manually specify some options to kexec in order to preserve the memory of the original system? I seem to recall that kexec did this automatically on x86 systems. Thanks, Chris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: visible memory seems wrong in kexec crash dump kernel
On 07/11/2013 02:55 PM, Chris Friesen wrote: Hi, I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system with 8GB of memory. (It's an embedded system and I can't do much about the fact that it's using older software.) I should probably clarify this...I may be able to update kexec, I can't update the kernel but I can backport more recent code if necessary. Looking at the version of kexec that I have, it seems like where x86 uses memmap= to specify the memory map usable by the capture kernel, powerpc does something different. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
AUTO: Michael Barry is out of the office (returning 15/07/2013)
I am out of the office until 15/07/2013. Note: This is an automated response to your message Linuxppc-dev Digest, Vol 107, Issue 89 sent on 11/07/2013 18:17:55. This is the only notification you will receive while this person is away. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
21 stable powerpc patches showing up in 3.11-rc1?
Ben,
Why do I have 21 patches from you marked for -stable trees in the
3.11-rc1 merge window, like the one quoted below? All of these look
serious enough that they should have gone into the 3.10-rc releases,
especially as the date of when they were submitted gave you plenty of
time to get them merged.
So why wait for 3.11-rc1? Are you not expecting anyone to run a 3.10.0
kernel on powerpc? If so, why would they want to wait for 3.10.1?
What is broken in our development process that caused this?
greg k-h
commit: b14b6260efeee6eb8942c6e6420e31281892acb6
From: Michael Ellerman mich...@ellerman.id.au
Date: Tue, 25 Jun 2013 17:47:57 +1000
Subject: powerpc: Wire up the HV facility unavailable exception
Similar to the facility unavailble exception, except the facilities are
controlled by HFSCR.
Adapt the facility_unavailable_exception() so it can be called for
either the regular or Hypervisor facility unavailable exceptions.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
CC: sta...@vger.kernel.org [v3.10]
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/exceptions-64s.S | 15 +++
arch/powerpc/kernel/traps.c | 16
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 6ee74f8..359d949 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -347,6 +347,12 @@ facility_unavailable_trampoline:
EXCEPTION_PROLOG_0(PACA_EXGEN)
b facility_unavailable_pSeries
+hv_facility_unavailable_trampoline:
+ . = 0xf80
+ SET_SCRATCH0(r13)
+ EXCEPTION_PROLOG_0(PACA_EXGEN)
+ b facility_unavailable_hv
+
#ifdef CONFIG_CBE_RAS
STD_EXCEPTION_HV(0x1200, 0x1202, cbe_system_error)
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0x1202)
@@ -525,6 +531,8 @@ denorm_done:
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0xf40)
STD_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0xf60)
+ STD_EXCEPTION_HV_OOL(0xf82, facility_unavailable)
+ KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xf82)
/*
* An interrupt came in while soft-disabled. We set paca-irq_happened, then:
@@ -836,6 +844,12 @@ facility_unavailable_relon_trampoline:
EXCEPTION_PROLOG_0(PACA_EXGEN)
b facility_unavailable_relon_pSeries
+hv_facility_unavailable_relon_trampoline:
+ . = 0x4f80
+ SET_SCRATCH0(r13)
+ EXCEPTION_PROLOG_0(PACA_EXGEN)
+ b facility_unavailable_relon_hv
+
STD_RELON_EXCEPTION_PSERIES(0x5300, 0x1300, instruction_breakpoint)
#ifdef CONFIG_PPC_DENORMALISATION
. = 0x5500
@@ -1174,6 +1188,7 @@ __end_handlers:
STD_RELON_EXCEPTION_PSERIES_OOL(0xf20, altivec_unavailable)
STD_RELON_EXCEPTION_PSERIES_OOL(0xf40, vsx_unavailable)
STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable)
+ STD_RELON_EXCEPTION_HV_OOL(0xf80, facility_unavailable)
#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
/*
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 11f4488..4a87fcb 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1299,10 +1299,18 @@ void facility_unavailable_exception(struct pt_regs
*regs)
EBB,
TAR,
};
- char *facility;
+ char *facility, *prefix;
u64 value;
- value = mfspr(SPRN_FSCR) 56;
+ if (regs-trap == 0xf60) {
+ value = mfspr(SPRN_FSCR);
+ prefix = ;
+ } else {
+ value = mfspr(SPRN_HFSCR);
+ prefix = Hypervisor ;
+ }
+
+ value = value 56;
/* We restore the interrupt state now */
if (!arch_irq_disabled_regs(regs))
@@ -1313,8 +1321,8 @@ void facility_unavailable_exception(struct pt_regs
*regs)
else
facility = unknown;
- pr_err(Facility '%s' unavailable, exception at 0x%lx, MSR=%lx\n,
- facility, regs-nip, regs-msr);
+ pr_err(%sFacility '%s' unavailable, exception at 0x%lx, MSR=%lx\n,
+ prefix, facility, regs-nip, regs-msr);
if (user_mode(regs)) {
_exception(SIGILL, regs, ILL_ILLOPC, regs-nip);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: visible memory seems wrong in kexec crash dump kernel
On 07/11/2013 03:22 PM, Chris Friesen wrote: On 07/11/2013 02:55 PM, Chris Friesen wrote: Hi, I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system with 8GB of memory. (It's an embedded system and I can't do much about the fact that it's using older software.) I should probably clarify this...I may be able to update kexec, I can't update the kernel but I can backport more recent code if necessary. Looking at the version of kexec that I have, it seems like where x86 uses memmap= to specify the memory map usable by the capture kernel, powerpc does something different. After some experimenting, it looks like in the capture kernel /dev/oldmem might actually refer to the memory owned by the old kernel. However, there doesn't seem to be anything preventing me from trampling it from within the capture kernel--I can create a tmpfs filesystem in memory and write gigs of data to it even though the capture kernel is only supposed to have 224MB. I think I got it to work properly once, but since then I haven't been able to get uncorrupted data out of /dev/oldmem. (My original kernel reserves a chunk of memory for logging and passes the offset/size to the capture kernel via kexec kernel args.) Chris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V5] powerpc/85xx: add the P1020RDB-PD DTS support
Overview of P1020RDB-PD device:
- DDR3 2GB
- NOR flash 64MB
- NAND flash 128MB
- SPI flash 16MB
- I2C EEPROM 256Kb
- eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
- eTSEC2 (SGMII PHY)
- eTSEC3 (RGMII PHY)
- SDHC
- 1 USB ports
- TDM ports
- PCIe
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
Signed-off-by: Xie Xiaobo-R63061 x@freescale.com
CC: Scott Wood scottw...@freescale.com
---
changes for v5:
- change the size of nand file system
arch/powerpc/boot/dts/p1020rdb-pd.dts | 280 ++
1 file changed, 280 insertions(+)
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pd.dts
diff --git a/arch/powerpc/boot/dts/p1020rdb-pd.dts
b/arch/powerpc/boot/dts/p1020rdb-pd.dts
new file mode 100644
index 000..ffbda25
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb-pd.dts
@@ -0,0 +1,280 @@
+/*
+ * P1020 RDB-PD Device Tree Source (32-bit address map)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ fsl/p1020si-pre.dtsi
+/ {
+ model = fsl,P1020RDB-PD;
+ compatible = fsl,P1020RDB-PD;
+
+ memory {
+ device_type = memory;
+ };
+
+ lbc: localbus@ffe05000 {
+ reg = 0x0 0xffe05000 0x0 0x1000;
+
+ /* NOR, NAND flash, L2 switch and CPLD */
+ ranges = 0x0 0x0 0x0 0xec00 0x0400
+ 0x1 0x0 0x0 0xff80 0x0004
+ 0x2 0x0 0x0 0xffa0 0x0002
+ 0x3 0x0 0x0 0xffb0 0x0002;
+
+ nor@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x400;
+ bank-width = 2;
+ device-width = 1;
+
+ partition@0 {
+ /* 128KB for DTB Image */
+ reg = 0x0 0x0002;
+ label = NOR DTB Image;
+ };
+
+ partition@2 {
+ /* 3.875 MB for Linux Kernel Image */
+ reg = 0x0002 0x003e;
+ label = NOR Linux Kernel Image;
+ };
+
+ partition@40 {
+ /* 58MB for Root file System */
+ reg = 0x0040 0x03a0;
+ label = NOR Root File System;
+ };
+
+ partition@3e0 {
+ /* This location must not be altered */
+ /* 1M for Vitesse 7385 Switch firmware */
+ reg = 0x3e0 0x0010;
+ label = NOR Vitesse-7385 Firmware;
+ read-only;
+ };
+
+ partition@3f0 {
+ /* This location must not be altered */
+ /* 512KB for u-boot Bootloader Image */
+
Re: visible memory seems wrong in kexec crash dump kernel
On Thu, Jul 11, 2013 at 03:22:49PM -0600, Chris Friesen wrote: On 07/11/2013 02:55 PM, Chris Friesen wrote: Hi, I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system with 8GB of memory. (It's an embedded system and I can't do much about the fact that it's using older software.) I should probably clarify this...I may be able to update kexec, I can't update the kernel but I can backport more recent code if necessary. Looking at the version of kexec that I have, it seems like where x86 uses memmap= to specify the memory map usable by the capture kernel, powerpc does something different. From memory, it's been years, on powerpc we add properties to the memory nodes in the device tree that specify which memory is usable. The properties are called linux,usable-memory, and in modern kernels they are read in early_init_dt_scan_memory(). cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/math-emu: keep track of the instructions unimplemented by FPU
On Thu, Jul 11, 2013 at 10:45:21PM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-11 at 20:21 +0800, Kevin Hao wrote:
Some cores (such as Freescale BookE) don't implement all floating
point instructions in ISA. But some gcc versions do use these
instructions. So we would have to enable the math emulation in this
case. Add this to emulated instructions tracking statistics so that
the user has a way to know that its toolcahin emit these unimplemented
floating point instructions.
That patch is gross, it makes the function even more nasty than it
already is. Besides, CONFIG_PPC_FPU doesn't mean you have a HW FPU,
you need to check the CPU feature bits.
Also the caller already does PPC_WARN_EMULATED, so this patch makes
you call it twice or am I missing something ?
There are two invocations of do_mathemu() in the traps.c. The one in the
function program_check_exception() doesn't call the PPC_WARN_EMULATED.
This is also the one I try to fix. Of course my patch will definitely corrupt
the one in function SoftwareEmulation(). I will respin a new patch to
fix this. Sorry for my mistake.
Thanks,
Kevin
Cheers,
Ben.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/math-emu/math.c | 50
+++-
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/math-emu/math.c b/arch/powerpc/math-emu/math.c
index 18ce6a7..9a98b6c 100644
--- a/arch/powerpc/math-emu/math.c
+++ b/arch/powerpc/math-emu/math.c
@@ -10,6 +10,7 @@
#include asm/sfp-machine.h
#include math-emu/double.h
+#include asm/emulated_ops.h
#define FLOATFUNC(x) extern int x(void *, void *, void *, void *)
@@ -222,10 +223,17 @@ do_mathemu(struct pt_regs *regs)
int idx = 0;
int (*func)(void *, void *, void *, void *);
int type = 0;
- int eflag, trap;
+ int eflag, trap, ret = -ENOSYS;
+ int has_hw_fpu = 0;
- if (get_user(insn, (u32 *)pc))
- return -EFAULT;
+#ifdef CONFIG_PPC_FPU
+ has_hw_fpu = 1;
+#endif
+
+ if (get_user(insn, (u32 *)pc)) {
+ ret = -EFAULT;
+ goto out;
+ }
switch (insn 26) {
case LFS: func = lfs; type = D; break;
@@ -249,7 +257,7 @@ do_mathemu(struct pt_regs *regs)
case STFDUX:func = stfd;type = XEU; break;
case STFIWX:func = stfiwx; type = XE; break;
default:
- goto illegal;
+ goto out;
}
break;
@@ -267,7 +275,7 @@ do_mathemu(struct pt_regs *regs)
case FNMSUBS: func = fnmsubs; type = ABC; break;
case FNMADDS: func = fnmadds; type = ABC; break;
default:
- goto illegal;
+ goto out;
}
break;
@@ -287,7 +295,7 @@ do_mathemu(struct pt_regs *regs)
case FNMSUB:func = fnmsub; type = ABC; break;
case FNMADD:func = fnmadd; type = ABC; break;
default:
- goto illegal;
+ goto out;
}
break;
}
@@ -309,12 +317,12 @@ do_mathemu(struct pt_regs *regs)
case MFFS: func = mffs;type = X; break;
case MTFSF: func = mtfsf; type = XFLB;break;
default:
- goto illegal;
+ goto out;
}
break;
default:
- goto illegal;
+ goto out;
}
switch (type) {
@@ -347,7 +355,7 @@ do_mathemu(struct pt_regs *regs)
case DU:
idx = (insn 16) 0x1f;
if (!idx)
- goto illegal;
+ goto out;
sdisp = (insn 0x);
op0 = (void *)current-thread.TS_FPR((insn 21) 0x1f);
@@ -375,7 +383,7 @@ do_mathemu(struct pt_regs *regs)
if (((insn 1) 0x3ff) == STFIWX)
op1 = (void *)(regs-gpr[(insn 11) 0x1f]);
else
- goto illegal;
+ goto out;
} else {
op1 = (void *)(regs-gpr[idx] + regs-gpr[(insn 11)
0x1f]);
}
@@ -417,7 +425,7 @@ do_mathemu(struct pt_regs *regs)
break;
default:
- goto illegal;
+ goto out;
}
/*
@@ -425,9 +433,8 @@ do_mathemu(struct pt_regs *regs)
* if flushed into the thread_struct before attempting
* emulation
*/
-#ifdef CONFIG_PPC_FPU
- flush_fp_to_thread(current);
-#endif
+ if (has_hw_fpu)
+ flush_fp_to_thread(current);
eflag = func(op0, op1, op2, op3);
@@ -437,8
Re: [PATCH 2/2] powerpc/math-emu: keep track of the instructions unimplemented by FPU
On Thu, Jul 11, 2013 at 09:30:02AM -0500, Scott Wood wrote: On 07/11/2013 07:45:21 AM, Benjamin Herrenschmidt wrote: On Thu, 2013-07-11 at 20:21 +0800, Kevin Hao wrote: Some cores (such as Freescale BookE) don't implement all floating point instructions in ISA. But some gcc versions do use these instructions. So we would have to enable the math emulation in this case. Add this to emulated instructions tracking statistics so that the user has a way to know that its toolcahin emit these unimplemented floating point instructions. That patch is gross, it makes the function even more nasty than it already is. Besides, CONFIG_PPC_FPU doesn't mean you have a HW FPU, you need to check the CPU feature bits. Also the caller already does PPC_WARN_EMULATED, so this patch makes you call it twice or am I missing something ? Sorry, that was my fault -- for some reason I didn't see that when I grepped for PPC_WARN_EMULATED looking for math stuff, and thus requested it be added. In any case, I don't see why it should be conditional on having an FPU (and indeed, the warning in the caller isn't conditional). I thought it only made sense to warn only for the case when the core does have a FPU but some unimplemented floating instructions are emulated. As for the core which doesn't have a FPU at all and we explicitly enable the math emulation it may seems a little redundant to warn in this case. But after a second thought, this is the statistics of all the emulated instructions, so it does seem reasonable to warn in all cases. I will remove the dependancy on FPU. Thanks, Kevin -Scott pgpmTtbKmzCPL.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/math-emu: keep track of the instructions unimplemented by FPU
On Fri, 2013-07-12 at 10:07 +0800, Kevin Hao wrote: There are two invocations of do_mathemu() in the traps.c. The one in the function program_check_exception() doesn't call the PPC_WARN_EMULATED. This is also the one I try to fix. Of course my patch will definitely corrupt the one in function SoftwareEmulation(). I will respin a new patch to fix this. Sorry for my mistake. Put the call in the caller (in program_check_exception). It keeps the code in math-emu simpler and is consistent with what we do elsewhere. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
Hi Timur, On Thu, Jul 11, 2013 at 12:14:56PM -0500, ti...@tabi.org wrote: Don't you need an ACK from the maintainer of the driver before applying it? I haven't had a chance to test it yet. If I'm not missing some part of branch updating, it looks like Mark hasn't pushed it to the branch yet. Please test it for me. Thank you. Best regards, Nicolin Chen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
Nicolin Chen wrote: Hi Timur, On Thu, Jul 11, 2013 at 12:14:56PM -0500, ti...@tabi.org wrote: Don't you need an ACK from the maintainer of the driver before applying it? I haven't had a chance to test it yet. If I'm not missing some part of branch updating, it looks like Mark hasn't pushed it to the branch yet. Please test it for me. Thank you. I definitely want to. Unfortunately, I'm literally in the middle of moving into a new house, and so everything is packed up. I won't be able to look at it for another week. -- Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, July 11, 2013 5:43 AM
To: Wang Dongsheng-B40534
Cc: Wang Dongsheng-B40534; b...@kernel.crashing.org; Wood Scott-B07421;
johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org;
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] powerpc/hibernate: add restore mmu context after
resume
On 07/10/2013 05:11:54 AM, Wang Dongsheng-B40534 wrote:
Hi scott ben,
About this patch do you have any suggestions?
Thanks
- dongsheng
-Original Message-
From: Wang Dongsheng-B40534
Sent: Sunday, June 09, 2013 6:38 PM
To: b...@kernel.crashing.org
Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-
B40534
Subject: [PATCH 2/2] powerpc/hibernate: add restore mmu context
after
resume
add restore_mmu_context to replace switch_mmu_context in
restore_processor_state, because the switch_mmu_context will do a
whole pile of stuff that are probably completely unnecessary.
There just need to restore the existing process context, and
invalidate TLB for boot core.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/include/asm/tlbflush.h | 2 ++
arch/powerpc/kernel/swsusp.c| 4 +---
arch/powerpc/mm/tlb_nohash.c| 12
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/tlbflush.h
b/arch/powerpc/include/asm/tlbflush.h
index 61a5927..c401fe3 100644
--- a/arch/powerpc/include/asm/tlbflush.h
+++ b/arch/powerpc/include/asm/tlbflush.h
@@ -44,6 +44,8 @@ extern void local_flush_tlb_page(struct
vm_area_struct
*vma, unsigned long vmadd
extern void __local_flush_tlb_page(struct mm_struct *mm, unsigned
long
vmaddr,
int tsize, int ind);
+extern void restore_mmu_context(void);
+
#ifdef CONFIG_SMP
extern void flush_tlb_mm(struct mm_struct *mm); extern void
flush_tlb_page(struct vm_area_struct *vma, unsigned
long
vmaddr);
diff --git a/arch/powerpc/kernel/swsusp.c
b/arch/powerpc/kernel/swsusp.c
index eae33e1..0b104d7 100644
--- a/arch/powerpc/kernel/swsusp.c
+++ b/arch/powerpc/kernel/swsusp.c
@@ -32,7 +32,5 @@ void save_processor_state(void)
void restore_processor_state(void)
{
-#ifdef CONFIG_PPC32
- switch_mmu_context(current-active_mm, current-active_mm);
-#endif
+ restore_mmu_context();
}
diff --git a/arch/powerpc/mm/tlb_nohash.c
b/arch/powerpc/mm/tlb_nohash.c
index df32a83..a5a0708 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -39,10 +39,12 @@
#include linux/of_fdt.h
#include linux/hugetlb.h
+#include asm/current.h
#include asm/tlbflush.h
#include asm/tlb.h
#include asm/code-patching.h
#include asm/hugetlb.h
+#include asm/mmu_context.h
#include mmu_decl.h
@@ -193,6 +195,16 @@ void local_flush_tlb_page(struct
vm_area_struct *vma,
unsigned long vmaddr)
}
EXPORT_SYMBOL(local_flush_tlb_page);
+void restore_mmu_context(void)
+{
+ struct mm_struct *mm = current-active_mm;
+
+ set_context(mm-context.id, mm-pgd);
+
+ _tlbil_all();
+}
+EXPORT_SYMBOL(restore_mmu_context);
What about targets that don't use tlb_nohash.c?
Yes, you are right, if we used PPC_STD_MMU, compilation error will occur.
And _tlbil_all should be remove, because all of the tlb already invalidated in
swsusp_*.S .
So we should invalid tlb in swsusp_asm64.S swsusp_booke.S on freescale
platform.
How about add restore_mmu_context(struct mm_struct* mm) into
arch/powerpc/include/asm/mmu_context.h
Path: arch/powerpc/include/asm/mmu_context.h
static void restore_mmu_context(struct mm_struct *mm)
{
set_context(mm-context.id, mm-pgd);
}
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
On Thu, Jul 11, 2013 at 11:00:15PM -0500, Timur Tabi wrote: I definitely want to. Unfortunately, I'm literally in the middle of moving into a new house, and so everything is packed up. I won't be able to look at it for another week. Oh, I see. Actually we've been using this patch for quite a while, it should be okay. And I still have some patches pending for the fsl_ssi.c, but looks like it'll be better for me to wait after you settle down. Hope everything will run smoothly during your house-moving. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
Nicolin Chen wrote: Oh, I see. Actually we've been using this patch for quite a while, it should be okay. Have you tested it on PowerPC? -- Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
On Thu, Jul 11, 2013 at 11:13:32PM -0500, Timur Tabi wrote: Have you tested it on PowerPC? Not actually. But I think it won't break the work flow since the SSI modules on two platform should be literally identical. But if you still have concern with it, you can ask Mark to wait and test it later. I'm okay with your decision. Thanks, Nicolin Chen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/math-emu: keep track of the instructions unimplemented by FPU
On Fri, Jul 12, 2013 at 01:56:03PM +1000, Benjamin Herrenschmidt wrote: On Fri, 2013-07-12 at 10:07 +0800, Kevin Hao wrote: There are two invocations of do_mathemu() in the traps.c. The one in the function program_check_exception() doesn't call the PPC_WARN_EMULATED. This is also the one I try to fix. Of course my patch will definitely corrupt the one in function SoftwareEmulation(). I will respin a new patch to fix this. Sorry for my mistake. Put the call in the caller (in program_check_exception). It keeps the code in math-emu simpler and is consistent with what we do elsewhere. Sure. V2 coming soon. Thanks, Kevin Cheers, Ben. pgpSJyLieBhOv.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 07/10/2013 12:48 AM, Scott Wood wrote: On 07/05/2013 01:27:05 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add the device tree nodes for them. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 90 +++ arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 90 +++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +- 3 files changed, 182 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi Please update Documentation/devicetree/bindings/powerpc/fsl/dma.txt for the new compatible and dgsr1. OK, thanks. What's more, some text string in the driver and Kconfig files should be updated too, e.g. Elo / Elo Plus DMA may be changed to Elo series DMA, will send out v3 patches soon. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/2] powerpc/math-emu: move the flush FPU state function into do_mathemu
By doing this we can make sure that the FPU state is only flushed to
the thread struct when it is really needed.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.
arch/powerpc/kernel/traps.c | 9 -
arch/powerpc/math-emu/math.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index bf33c22..58a8065 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1131,15 +1131,6 @@ void __kprobes program_check_exception(struct pt_regs
*regs)
* instruction or only on FP instructions, whether there is a
* pattern to occurrences etc. -dgibson 31/Mar/2003
*/
-
- /*
-* If we support a HW FPU, we need to ensure the FP state
-* if flushed into the thread_struct before attempting
-* emulation
-*/
-#ifdef CONFIG_PPC_FPU
- flush_fp_to_thread(current);
-#endif
switch (do_mathemu(regs)) {
case 0:
emulate_single_step(regs);
diff --git a/arch/powerpc/math-emu/math.c b/arch/powerpc/math-emu/math.c
index 3fe8e35..18ce6a7 100644
--- a/arch/powerpc/math-emu/math.c
+++ b/arch/powerpc/math-emu/math.c
@@ -420,6 +420,15 @@ do_mathemu(struct pt_regs *regs)
goto illegal;
}
+ /*
+* If we support a HW FPU, we need to ensure the FP state
+* if flushed into the thread_struct before attempting
+* emulation
+*/
+#ifdef CONFIG_PPC_FPU
+ flush_fp_to_thread(current);
+#endif
+
eflag = func(op0, op1, op2, op3);
if (insn 1) {
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/2] powerpc/math-emu: two patches for the emulation of the FPU unimplemented instructions
v2: Tweak the patch 2 as suggested by Benjamin and Scott. v1: These two patches are for the emulation of the FPU unimplemented instructions. The first is just a bit optimization for the FPU state flush. The second is requested by Scott. Kevin Hao (2): powerpc/math-emu: move the flush FPU state function into do_mathemu powerpc: introduce function emulate_math() arch/powerpc/kernel/traps.c | 88 +--- arch/powerpc/math-emu/math.c | 9 + 2 files changed, 43 insertions(+), 54 deletions(-) -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc: introduce function emulate_math()
There are two invocations of do_mathemu() in traps.c. And the codes
in these two places are almost the same. Introduce a locale function
to eliminate the duplication. With this change we can also make sure
that in program_check_exception() the PPC_WARN_EMULATED is invoked for
the correctly emulated math instructions.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2:
* Don't depend on the FPU for the PPC_WARN_EMULATED.
* Invoke the PPC_WARN_EMULATED in the caller of do_mathemu().
* Introduce a new function to eliminate the code duplication.
arch/powerpc/kernel/traps.c | 79 +++--
1 file changed, 34 insertions(+), 45 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 58a8065..217724a 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1052,11 +1052,41 @@ int is_valid_bugaddr(unsigned long addr)
return is_kernel_addr(addr);
}
+#ifdef CONFIG_MATH_EMULATION
+static int emulate_math(struct pt_regs *regs)
+{
+ int ret;
+ extern int do_mathemu(struct pt_regs *regs);
+
+ ret = do_mathemu(regs);
+ if (ret = 0)
+ PPC_WARN_EMULATED(math, regs);
+
+ switch (ret) {
+ case 0:
+ emulate_single_step(regs);
+ return 0;
+ case 1: {
+ int code = 0;
+ code = __parse_fpscr(current-thread.fpscr.val);
+ _exception(SIGFPE, regs, code, regs-nip);
+ return 0;
+ }
+ case -EFAULT:
+ _exception(SIGSEGV, regs, SEGV_MAPERR, regs-nip);
+ return 0;
+ }
+
+ return -1;
+}
+#else
+static inline int emulate_math(struct pt_regs *regs) { return -1; }
+#endif
+
void __kprobes program_check_exception(struct pt_regs *regs)
{
enum ctx_state prev_state = exception_enter();
unsigned int reason = get_reason(regs);
- extern int do_mathemu(struct pt_regs *regs);
/* We can now get here via a FP Unavailable exception if the core
* has no FPU, in that case the reason flags will be 0 */
@@ -1122,7 +1152,6 @@ void __kprobes program_check_exception(struct pt_regs
*regs)
if (!arch_irq_disabled_regs(regs))
local_irq_enable();
-#ifdef CONFIG_MATH_EMULATION
/* (reason REASON_ILLEGAL) would be the obvious thing here,
* but there seems to be a hardware bug on the 405GP (RevD)
* that means ESR is sometimes set incorrectly - either to
@@ -1131,22 +1160,8 @@ void __kprobes program_check_exception(struct pt_regs
*regs)
* instruction or only on FP instructions, whether there is a
* pattern to occurrences etc. -dgibson 31/Mar/2003
*/
- switch (do_mathemu(regs)) {
- case 0:
- emulate_single_step(regs);
- goto bail;
- case 1: {
- int code = 0;
- code = __parse_fpscr(current-thread.fpscr.val);
- _exception(SIGFPE, regs, code, regs-nip);
- goto bail;
- }
- case -EFAULT:
- _exception(SIGSEGV, regs, SEGV_MAPERR, regs-nip);
+ if (!emulate_math(regs))
goto bail;
- }
- /* fall through on any other errors */
-#endif /* CONFIG_MATH_EMULATION */
/* Try to emulate it if we should. */
if (reason (REASON_ILLEGAL | REASON_PRIVILEGED)) {
@@ -1425,11 +1440,6 @@ void performance_monitor_exception(struct pt_regs *regs)
#ifdef CONFIG_8xx
void SoftwareEmulation(struct pt_regs *regs)
{
- extern int do_mathemu(struct pt_regs *);
-#if defined(CONFIG_MATH_EMULATION)
- int errcode;
-#endif
-
CHECK_FULL_REGS(regs);
if (!user_mode(regs)) {
@@ -1437,31 +1447,10 @@ void SoftwareEmulation(struct pt_regs *regs)
die(Kernel Mode Software FPU Emulation, regs, SIGFPE);
}
-#ifdef CONFIG_MATH_EMULATION
- errcode = do_mathemu(regs);
- if (errcode = 0)
- PPC_WARN_EMULATED(math, regs);
-
- switch (errcode) {
- case 0:
- emulate_single_step(regs);
- return;
- case 1: {
- int code = 0;
- code = __parse_fpscr(current-thread.fpscr.val);
- _exception(SIGFPE, regs, code, regs-nip);
- return;
- }
- case -EFAULT:
- _exception(SIGSEGV, regs, SEGV_MAPERR, regs-nip);
+ if (!emulate_math(regs))
return;
- default:
- _exception(SIGILL, regs, ILL_ILLOPC, regs-nip);
- return;
- }
-#else
+
_exception(SIGILL, regs, ILL_ILLOPC, regs-nip);
-#endif
}
#endif /* CONFIG_8xx */
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
[PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation
From: Wang Dongsheng dongsheng.w...@freescale.com Update the 64-bit hibernation code to support Book E CPUs. Some registers and instructions are not defined for Book3e (SDR reg, tlbia instruction). SDR: Storage Description Register. Book3S and Book3E have different address translation mode, we do not need HTABORG HTABSIZE to translate virtual address to real address. More registers are saved in BookE-64bit.(TCR, SPRG1) Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- v2: * Remove: Save SPRG0, SPRG2-SPRG7. SPRG1 should be saved, the paca will be saved here. * Add: Invaild tlbs. * Modify: Code style, add whitespace after commas. diff --git a/arch/powerpc/kernel/swsusp_asm64.S b/arch/powerpc/kernel/swsusp_asm64.S index 86ac1d9..f530350 100644 --- a/arch/powerpc/kernel/swsusp_asm64.S +++ b/arch/powerpc/kernel/swsusp_asm64.S @@ -46,10 +46,19 @@ #define SL_r29 0xe8 #define SL_r30 0xf0 #define SL_r31 0xf8 -#define SL_SIZESL_r31+8 +#define SL_SPRG1 0x100 +#define SL_TCR 0x108 +#define SL_SIZESL_TCR+8 /* these macros rely on the save area being * pointed to by r11 */ + +#define SAVE_SPR(register) \ + mfspr r0, SPRN_##register ;\ + std r0, SL_##register(r11) +#define RESTORE_SPR(register) \ + ld r0, SL_##register(r11) ;\ + mtspr SPRN_##register, r0 #define SAVE_SPECIAL(special) \ mf##special r0 ;\ std r0, SL_##special(r11) @@ -103,8 +112,15 @@ _GLOBAL(swsusp_arch_suspend) SAVE_REGISTER(r30) SAVE_REGISTER(r31) SAVE_SPECIAL(MSR) - SAVE_SPECIAL(SDR1) SAVE_SPECIAL(XER) +#ifdef CONFIG_PPC_BOOK3S_64 + SAVE_SPECIAL(SDR1) +#else + SAVE_SPR(TCR) + + /* Save SPRG1, SPRG1 be used save paca */ + SAVE_SPR(SPRG1) +#endif /* we push the stack up 128 bytes but don't store the * stack pointer on the stack like a real stackframe */ @@ -151,6 +167,7 @@ copy_page_loop: bne+copyloop nothing_to_copy: +#ifdef CONFIG_PPC_BOOK3S_64 /* flush caches */ lis r3, 0x10 mtctr r3 @@ -167,6 +184,7 @@ nothing_to_copy: sync tlbia +#endif ld r11,swsusp_save_area_ptr@toc(r2) @@ -208,16 +226,39 @@ nothing_to_copy: RESTORE_REGISTER(r29) RESTORE_REGISTER(r30) RESTORE_REGISTER(r31) + +#ifdef CONFIG_PPC_BOOK3S_64 /* can't use RESTORE_SPECIAL(MSR) */ ld r0, SL_MSR(r11) mtmsrd r0, 0 RESTORE_SPECIAL(SDR1) +#else + /* Restore SPRG1, be used to save paca */ + ld r0, SL_SPRG1(r11) + mtsprg 1, r0 + + RESTORE_SPECIAL(MSR) + + /* Restore TCR and clear any pending bits in TSR. */ + RESTORE_SPR(TCR) + lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h + mtspr SPRN_TSR, r0 + + /* Kick decrementer */ + li r0, 1 + mtdec r0 +#endif RESTORE_SPECIAL(XER) sync + /* Invalidate all tlbs */ + bl _tlbil_all + addir1,r1,-128 +#ifdef CONFIG_PPC_BOOK3S_64 bl slb_flush_and_rebolt +#endif bl do_after_copyback addir1,r1,128 -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
