[PATCH] powerpc/btext: Fix CONFIG_PPC_EARLY_DEBUG_BOOTX on ppc32
The rmci stuff only exists on 64-bit
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/btext.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c
index 0428992..41c011c 100644
--- a/arch/powerpc/kernel/btext.c
+++ b/arch/powerpc/kernel/btext.c
@@ -52,7 +52,7 @@ extern void rmci_off(void);
static inline void rmci_maybe_on(void)
{
-#ifdef CONFIG_PPC_EARLY_DEBUG_BOOTX
+#if defined(CONFIG_PPC_EARLY_DEBUG_BOOTX) defined(CONFIG_PPC64)
if (!(mfmsr() MSR_DR))
rmci_on();
#endif
@@ -60,7 +60,7 @@ static inline void rmci_maybe_on(void)
static inline void rmci_maybe_off(void)
{
-#ifdef CONFIG_PPC_EARLY_DEBUG_BOOTX
+#if defined(CONFIG_PPC_EARLY_DEBUG_BOOTX) defined(CONFIG_PPC64)
if (!(mfmsr() MSR_DR))
rmci_off();
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Work around gcc miscompilation of __pa() on 64-bit
On 64-bit, __pa(static_var) gets miscompiled by recent versions of gcc as something like: addis 3,2,.LANCHOR1+4611686018427387904@toc@ha addi 3,3,.LANCHOR1+4611686018427387904@toc@l This ends up effectively ignoring the offset, since its bottom 32 bits are zero, and means that the result of __pa() still has 0xC in the top nibble. This happens with gcc 4.8.1, at least. To work around this, for 64-bit we make __pa() use an AND operator, and for symmetry, we make __va() use an OR operator. Using an AND operator rather than a subtraction ends up with slightly shorter code since it can be done with a single clrldi instruction, whereas it takes three instructions to form the constant (-PAGE_OFFSET) and add it on. (Note that MEMORY_START is always 0 on 64-bit.) Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/Kconfig| 1 + arch/powerpc/include/asm/page.h | 10 ++ 2 files changed, 11 insertions(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index dbd9d3c..9cf59816d 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -979,6 +979,7 @@ config RELOCATABLE must live at a different physical address than the primary kernel. +# This value must have zeroes in the bottom 60 bits otherwise lots will break config PAGE_OFFSET hex default 0xc000 diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index 988c812..b9f4262 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -211,9 +211,19 @@ extern long long virt_phys_offset; #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) + VIRT_PHYS_OFFSET)) #define __pa(x) ((unsigned long)(x) - VIRT_PHYS_OFFSET) #else +#ifdef CONFIG_PPC64 +/* + * gcc miscompiles (unsigned long)(static_var) - PAGE_OFFSET + * with -mcmodel=medium, so we use and | instead of - and + on 64-bit. + */ +#define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET)) +#define __pa(x) ((unsigned long)(x) 0x0fffUL) + +#else /* 32-bit, non book E */ #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) + PAGE_OFFSET - MEMORY_START)) #define __pa(x) ((unsigned long)(x) - PAGE_OFFSET + MEMORY_START) #endif +#endif /* * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI, -- 1.8.4.rc3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, Aug 27, 2013 at 02:19:58PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote: Gleb, any chance you can put this (and the next one) into a tree to lock in the numbers ? Applied it. Sorry for slow response, was on vocation and still go through the email backlog. Thanks. Since it's not in a topic branch that I can pull, I'm going to just cherry-pick them. However, they are in your queue branch, not next branch. Should I still assume this is a stable branch and that the numbers aren't going to change ? Queue will become next after I will test it and if test will fail the commit hash may change, but since you are going to cherry-pick and this does not preserve commit hash it does not matter. -- Gleb. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor
/proc/powerpc/lparcfg is an ancient facility (though still actively used)
which allows access to some informations relative to the partition when
running underneath a PAPR compliant hypervisor.
It makes no sense on non-pseries machines. However, currently, not only
can it be created on these if the kernel has pseries support, but accessing
it on such a machine will crash due to trying to do hypervisor calls.
In fact, it should also not do HV calls on older pseries that didn't have
an hypervisor either.
Finally, it has the plumbing to be a module but is a bool Kconfig option.
This fixes the whole lot by turning it into a machine_device_initcall
that is only created on pseries, and adding the necessary hypervisor
check before calling the H_GET_EM_PARMS hypercall
CC: sta...@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Next I'll move it to arch/powerpc/platforms/pseries but in a separate
patch.
arch/powerpc/kernel/lparcfg.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index d92f387..e2a0a16 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -35,7 +35,13 @@
#include asm/vdso_datapage.h
#include asm/vio.h
#include asm/mmu.h
+#include asm/machdep.h
+
+/*
+ * This isn't a module but we expose that to userspace
+ * via /proc so leave the definitions here
+ */
#define MODULE_VERS 1.9
#define MODULE_NAME lparcfg
@@ -418,7 +424,8 @@ static void parse_em_data(struct seq_file *m)
{
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
- if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+ if (firmware_has_feature(FW_FEATURE_LPAR)
+ plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
seq_printf(m, power_mode_data=%016lx\n, retbuf[0]);
}
@@ -677,7 +684,6 @@ static int lparcfg_open(struct inode *inode, struct file
*file)
}
static const struct file_operations lparcfg_fops = {
- .owner = THIS_MODULE,
.read = seq_read,
.write = lparcfg_write,
.open = lparcfg_open,
@@ -699,14 +705,4 @@ static int __init lparcfg_init(void)
}
return 0;
}
-
-static void __exit lparcfg_cleanup(void)
-{
- remove_proc_subtree(powerpc/lparcfg, NULL);
-}
-
-module_init(lparcfg_init);
-module_exit(lparcfg_cleanup);
-MODULE_DESCRIPTION(Interface for LPAR configuration data);
-MODULE_AUTHOR(Dave Engebretsen);
-MODULE_LICENSE(GPL);
+machine_device_initcall(pseries, lparcfg_init);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, Aug 27, 2013 at 02:22:42PM +1000, Benjamin Herrenschmidt wrote: On Tue, 2013-08-27 at 14:19 +1000, Benjamin Herrenschmidt wrote: On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote: Gleb, any chance you can put this (and the next one) into a tree to lock in the numbers ? Applied it. Sorry for slow response, was on vocation and still go through the email backlog. Thanks. Since it's not in a topic branch that I can pull, I'm going to just cherry-pick them. However, they are in your queue branch, not next branch. Should I still assume this is a stable branch and that the numbers aren't going to change ? Oh and Alexey mentions that there are two capabilities and you only applied one :-) Another one is: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO ? -- Gleb. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Work around gcc miscompilation of __pa() on 64-bit
On Tue, Aug 27, 2013 at 04:07:49PM +1000, Paul Mackerras wrote: On 64-bit, __pa(static_var) gets miscompiled by recent versions of gcc as something like: addis 3,2,.LANCHOR1+4611686018427387904@toc@ha addi 3,3,.LANCHOR1+4611686018427387904@toc@l I might argue that this isn't a miscompilation, since -mcmodel=medium assumes everything can be accessed within +/-2G of the toc pointer, but it's definitely a problem since gas and/or ld don't give an overflow error. They would except for the fact that our ABI has a hole in it. We have relocs that error on 16-bit overflow, eg. addi 3,2,x@toc will give an error if x is more than +/-32k from the toc pointer, but @ha and _HA/_HI relocs don't error on 32-bit overflow. (They can't, because they were really designed to be used in HIHGESTA, HIGHERA, HA, LO sequences to build up 64-bit values.) The proper fix is to define a whole slew of new relocations and reloc specifiers, and modify everything to use them, but that seems like too much bother. I had ideas once upon a time to implement gas and ld options that makes @ha and _HA report overflows, but haven't found one of those round tuits. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are 3 bug fixes that should probably go into 3.11 since I'm also tagging them for stable. Once fixes our old /proc/powerpc/lparcfg file which provides partition informations when running under our hypervisor and also acts as a user-triggerable Oops when hot :-( The other two respectively are a one liner to fix a HVSI protocol handshake problem causing the console to fail to show up on a bunch of machines until we reach userspace, which I deem annoying enough to warrant going to stable, and a nasty gcc miscompile causing us to pass virtual instead of physical addresses to the firmware under some circumstances. Cheers, Ben. The following changes since commit 28e61cc466d8daace4b0f04ba2b83e0bd68f5832: powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs (2013-08-09 18:07:12 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to d220980b701d838560a70de691b53be007e99e78: powerpc/hvsi: Increase handshake timeout from 200ms to 400ms. (2013-08-27 16:59:56 +1000) Benjamin Herrenschmidt (1): powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor Eugene Surovegin (1): powerpc/hvsi: Increase handshake timeout from 200ms to 400ms. Paul Mackerras (1): powerpc: Work around gcc miscompilation of __pa() on 64-bit arch/powerpc/Kconfig| 1 + arch/powerpc/include/asm/page.h | 10 ++ arch/powerpc/kernel/lparcfg.c | 22 +- drivers/tty/hvc/hvsi_lib.c | 4 ++-- 4 files changed, 22 insertions(+), 15 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, 2013-08-27 at 09:40 +0300, Gleb Natapov wrote: Thanks. Since it's not in a topic branch that I can pull, I'm going to just cherry-pick them. However, they are in your queue branch, not next branch. Should I still assume this is a stable branch and that the numbers aren't going to change ? Queue will become next after I will test it and if test will fail the commit hash may change, but since you are going to cherry-pick and this does not preserve commit hash it does not matter. Right, as long as the actual cap and ioctl numbers remain stable :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, 2013-08-27 at 09:41 +0300, Gleb Natapov wrote: Oh and Alexey mentions that there are two capabilities and you only applied one :-) Another one is: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO ? Yes, thanks ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] Register bootmem pages
On Tue, 2013-08-27 at 13:44 +1000, Benjamin Herrenschmidt wrote:
So I still feel very uncomfortable with that stuff
For example, x86 calls register_page_bootmem_info_node() at boot time,
which does that strange get_page_bootmem on the NODE_DATA itself at
boot time, we don't. Should we ?
Bah, call me an idiot ... I was looking at the code without your patch
and not realizing that this is exactly what your patch does :-)
.../...
There's a whole pile of totally undocumented / uncommented generic code
with horrible function names in there whose sematic is very very
unclear.
Now, if we call that thing, are we expected to have
register_paqe_bootmem_memmap() to actually do something right? I assume
that means actually calling get_page_bootmem() on the various struct
page that comprise the vmemmap.
Well, we can probably implement that since we maintain a list of all the
vmemap pages... However, we don't implement vmemmap_free(). Should we ?
This still stands, should we actually register the pages of the
vmemmap or not ?
What happens if we remove a chunk of memory and then plug it back in ?
Will it try to re-create a new vmemmap chunk for that area (where we
haven't removed the previous one) ? That might cause problems if we end
up putting duplicate entries in the hash table ... should we implement
vmemmap_free and actual unmap the segments ?
Cheers,
Ben.
---
arch/powerpc/mm/init_64.c |4
arch/powerpc/mm/mem.c |9 +
mm/Kconfig|2 +-
3 files changed, 14 insertions(+), 1 deletion(-)
Index: linux/arch/powerpc/mm/init_64.c
===
--- linux.orig/arch/powerpc/mm/init_64.c
+++ linux/arch/powerpc/mm/init_64.c
@@ -300,5 +300,9 @@ void vmemmap_free(unsigned long start, u
{
}
+void register_page_bootmem_memmap(unsigned long section_nr,
+ struct page *start_page, unsigned long size)
+{
+}
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
Index: linux/arch/powerpc/mm/mem.c
===
--- linux.orig/arch/powerpc/mm/mem.c
+++ linux/arch/powerpc/mm/mem.c
@@ -297,12 +297,21 @@ void __init paging_init(void)
}
#endif /* ! CONFIG_NEED_MULTIPLE_NODES */
+static void __init register_page_bootmem_info(void)
+{
+ int i;
+
+ for_each_online_node(i)
+ register_page_bootmem_info_node(NODE_DATA(i));
+}
+
void __init mem_init(void)
{
#ifdef CONFIG_SWIOTLB
swiotlb_init(0);
#endif
+ register_page_bootmem_info();
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
set_max_mapnr(max_pfn);
free_all_bootmem();
Index: linux/mm/Kconfig
===
--- linux.orig/mm/Kconfig
+++ linux/mm/Kconfig
@@ -183,7 +183,7 @@ config MEMORY_HOTPLUG_SPARSE
config MEMORY_HOTREMOVE
bool Allow for memory hot remove
select MEMORY_ISOLATION
- select HAVE_BOOTMEM_INFO_NODE if X86_64
+ select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
depends on MEMORY_HOTPLUG ARCH_ENABLE_MEMORY_HOTREMOVE
depends on MIGRATION
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c: powermac: fix return path on error
On Mon, 2013-08-19 at 15:18 +0200, Wolfram Sang wrote:
We want to bail out immediately if i2c_add_adapter failed and not try to
register child nodes with a nilled adapter structure.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/i2c/busses/i2c-powermac.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..bb81773 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -446,6 +446,7 @@ static int i2c_powermac_probe(struct platform_device *dev)
printk(KERN_ERR i2c-powermac: Adapter %s registration
failed\n, adapter-name);
memset(adapter, 0, sizeof(*adapter));
+ return rc;
}
printk(KERN_INFO PowerMac i2c bus %s registered\n, adapter-name);
@@ -455,7 +456,7 @@ static int i2c_powermac_probe(struct platform_device *dev)
*/
i2c_powermac_register_devices(adapter, bus);
- return rc;
+ return 0;
}
static struct platform_driver i2c_powermac_driver = {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Set the NOTE type for SPE regset
The regset defintion for SPE doesn't have the core_note_type
set, which prevents it from being dumped. Add the note type
NT_PPC_SPE for SPE regset.
Signed-off-by: Suzuki K Poulose suz...@in.ibm.com
Cc: Roland McGrath rol...@hack.frob.com
---
arch/powerpc/kernel/ptrace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9a0d24c..16edc5d 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -657,7 +657,7 @@ static const struct user_regset native_regsets[] = {
#endif
#ifdef CONFIG_SPE
[REGSET_SPE] = {
- .n = 35,
+ .core_note_type = NT_PPC_SPE, .n = 35,
.size = sizeof(u32), .align = sizeof(u32),
.active = evr_active, .get = evr_get, .set = evr_set
},
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/irq: remove the unneeded flag PACA_IRQ_EE_EDGE
On Thu, 2013-04-11 at 09:32 +0800, Kevin Hao wrote: In order to support the Book3E external proxy, the flag PACA_IRQ_EE_EDGE was introduced in patch 7230c564 (powerpc: Rework lazy-interrupt handling). But it turns out that this is not needed. And it is also not used by any code in the current kernel. According to the PowerISA 2.0.6, the content of EPR (External Proxy Register) is valid until MSR[EE] is set to 1. Since we never enable the hard irq before replaying a external interrupt. That means we still can get the valid interrupt vector from EPR when replaying irq. I assume you understand why that patch is broken and this is superseeded by your more recent series to actually make use of PACA_IRQ_EE_EDGE right ? :-) (Just making sure I can take that one out of patchwork). Signed-off-by: Kevin Hao haoke...@gmail.com --- arch/powerpc/include/asm/hw_irq.h| 1 - arch/powerpc/kernel/exceptions-64e.S | 1 - arch/powerpc/kernel/irq.c| 8 3 files changed, 10 deletions(-) diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h index e45c494..8bf0789 100644 --- a/arch/powerpc/include/asm/hw_irq.h +++ b/arch/powerpc/include/asm/hw_irq.h @@ -24,7 +24,6 @@ #define PACA_IRQ_DBELL 0x02 #define PACA_IRQ_EE 0x04 #define PACA_IRQ_DEC 0x08 /* Or FIT */ -#define PACA_IRQ_EE_EDGE 0x10 /* BookE only */ #endif /* CONFIG_PPC64 */ diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index 42a756e..64f2fbd 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++ b/arch/powerpc/kernel/exceptions-64e.S @@ -701,7 +701,6 @@ kernel_dbg_exc: .endm masked_interrupt_book3e_0x500: - // XXX When adding support for EPR, use PACA_IRQ_EE_EDGE masked_interrupt_book3e PACA_IRQ_EE 1 masked_interrupt_book3e_0x900: diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c index 4f97fe3..dbc1c05 100644 --- a/arch/powerpc/kernel/irq.c +++ b/arch/powerpc/kernel/irq.c @@ -171,14 +171,6 @@ notrace unsigned int __check_irq_replay(void) return 0x500; #ifdef CONFIG_PPC_BOOK3E - /* Finally check if an EPR external interrupt happened - * this bit is typically set if we need to handle another - * edge interrupt from within the MPIC EPR handler - */ - local_paca-irq_happened = ~PACA_IRQ_EE_EDGE; - if (happened PACA_IRQ_EE_EDGE) - return 0x500; - local_paca-irq_happened = ~PACA_IRQ_DBELL; if (happened PACA_IRQ_DBELL) return 0x280; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
is 0xac, the next two numbers are taken - 0xad for KVM_KVMCLOCK_CTRL and
0xac was also taken by KVM_SET_ONE_REG :(
0xae for KVM_ARM_VCPU_INIT. So the KVM_CREATE_SPAPR_TCE_IOMMU ioclt gets
0xaf.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/08/15 v8:
* fixed comment again
2013/08/15:
* fixed mistype in comments
* fixed commit message which says what uses ioctls 0xad and 0xae
2013/07/16:
* changed the number
2013/07/11:
* changed order in a file, added comment about a gap in ioctl number
---
include/uapi/linux/kvm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 99c2533..bd94127 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
+#define KVM_CAP_SPAPR_TCE_IOMMU 95
#ifdef KVM_CAP_IRQ_ROUTING
@@ -933,6 +934,11 @@ struct kvm_s390_ucas_mapping {
#define KVM_ARM_SET_DEVICE_ADDR_IOW(KVMIO, 0xab, struct
kvm_arm_device_addr)
/* Available with KVM_CAP_PPC_RTAS */
#define KVM_PPC_RTAS_DEFINE_TOKEN _IOW(KVMIO, 0xac, struct
kvm_rtas_token_args)
+/* 0xad is taken by KVM_KVMCLOCK_CTRL */
+/* 0xae is taken by KVM_ARM_VCPU_INIT */
+/* Available with KVM_CAP_SPAPR_TCE_IOMMU */
+#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, \
+ struct kvm_create_spapr_tce_iommu)
Why not use KVM_CREATE_DEVICE API for that?
/* ioctl for vm fd */
#define KVM_CREATE_DEVICE _IOWR(KVMIO, 0xe0, struct kvm_create_device)
--
1.8.3.2
--
Gleb.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/irq: remove the unneeded flag PACA_IRQ_EE_EDGE
On Tue, Aug 27, 2013 at 05:53:24PM +1000, Benjamin Herrenschmidt wrote: On Thu, 2013-04-11 at 09:32 +0800, Kevin Hao wrote: In order to support the Book3E external proxy, the flag PACA_IRQ_EE_EDGE was introduced in patch 7230c564 (powerpc: Rework lazy-interrupt handling). But it turns out that this is not needed. And it is also not used by any code in the current kernel. According to the PowerISA 2.0.6, the content of EPR (External Proxy Register) is valid until MSR[EE] is set to 1. Since we never enable the hard irq before replaying a external interrupt. That means we still can get the valid interrupt vector from EPR when replaying irq. I assume you understand why that patch is broken and this is superseeded by your more recent series to actually make use of PACA_IRQ_EE_EDGE right ? :-) Yes. (Just making sure I can take that one out of patchwork). Definitely. Thanks, Kevin pgpYUSm1hmse4.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
On 08/27/2013 05:56 PM, Gleb Natapov wrote:
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
is 0xac, the next two numbers are taken - 0xad for KVM_KVMCLOCK_CTRL and
0xac was also taken by KVM_SET_ONE_REG :(
0xae for KVM_ARM_VCPU_INIT. So the KVM_CREATE_SPAPR_TCE_IOMMU ioclt gets
0xaf.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/08/15 v8:
* fixed comment again
2013/08/15:
* fixed mistype in comments
* fixed commit message which says what uses ioctls 0xad and 0xae
2013/07/16:
* changed the number
2013/07/11:
* changed order in a file, added comment about a gap in ioctl number
---
include/uapi/linux/kvm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 99c2533..bd94127 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
+#define KVM_CAP_SPAPR_TCE_IOMMU 95
#ifdef KVM_CAP_IRQ_ROUTING
@@ -933,6 +934,11 @@ struct kvm_s390_ucas_mapping {
#define KVM_ARM_SET_DEVICE_ADDR _IOW(KVMIO, 0xab, struct
kvm_arm_device_addr)
/* Available with KVM_CAP_PPC_RTAS */
#define KVM_PPC_RTAS_DEFINE_TOKEN _IOW(KVMIO, 0xac, struct
kvm_rtas_token_args)
+/* 0xad is taken by KVM_KVMCLOCK_CTRL */
+/* 0xae is taken by KVM_ARM_VCPU_INIT */
+/* Available with KVM_CAP_SPAPR_TCE_IOMMU */
+#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, \
+struct kvm_create_spapr_tce_iommu)
Why not use KVM_CREATE_DEVICE API for that?
Because when I came up with my ioctl first time, it was not in upstream and
since then nobody pointed me to this new ioctl :)
So my stuff is not going to upstream again. Heh. Ok. I'll implement it.
/* ioctl for vm fd */
#define KVM_CREATE_DEVICE _IOWR(KVMIO, 0xe0, struct kvm_create_device)
--
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/3] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
From: Wang Dongsheng dongsheng.w...@freescale.com E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec idle patches. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 64264bf..d4160ca 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -1053,6 +1053,8 @@ #define PVR_8560 0x8020 #define PVR_VER_E500V1 0x8020 #define PVR_VER_E500V2 0x8021 +#define PVR_VER_E6500 0x8040 + /* * For the 8xx processors, all of them report the same PVR family for * the PowerPC core. The various versions of these processors must be diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index ed8f836..86ede76 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -170,6 +170,7 @@ #define SPRN_L2CSR10x3FA /* L2 Data Cache Control and Status Register 1 */ #define SPRN_DCCR 0x3FA /* Data Cache Cacheability Register */ #define SPRN_ICCR 0x3FB /* Instruction Cache Cacheability Register */ +#define SPRN_PWRMGTCR0 0x3FB /* Power management control register 0 */ #define SPRN_SVR 0x3FF /* System Version Register */ /* -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/3] powerpc/85xx: add hardware automatically enter altivec idle state
From: Wang Dongsheng dongsheng.w...@freescale.com
Each core's AltiVec unit may be placed into a power savings mode
by turning off power to the unit. Core hardware will automatically
power down the AltiVec unit after no AltiVec instructions have
executed in N cycles. The AltiVec power-control is triggered by hardware.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*v2:
Remove:
delete setup_idle_hw_governor function.
delete Fix erratum for rev1.
Move:
move setup_* into __setup/restore_cpu_e6500.
diff --git a/arch/powerpc/include/asm/reg_booke.h
b/arch/powerpc/include/asm/reg_booke.h
index 86ede76..8364bbe 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -217,6 +217,9 @@
#defineCCR1_DPC0x0100 /* Disable L1 I-Cache/D-Cache parity
checking */
#defineCCR1_TCS0x0080 /* Timer Clock Select */
+/* Bit definitions for PWRMGTCR0. */
+#define PWRMGTCR0_ALTIVEC_IDLE (1 22) /* Altivec idle enable */
+
/* Bit definitions for the MCSR. */
#define MCSR_MCS 0x8000 /* Machine Check Summary */
#define MCSR_IB0x4000 /* Instruction PLB Error */
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index bfb18c7..90bbb46 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -58,6 +58,7 @@ _GLOBAL(__setup_cpu_e6500)
#ifdef CONFIG_PPC64
bl .setup_altivec_ivors
#endif
+ bl setup_altivec_idle
bl __setup_cpu_e5500
mtlrr6
blr
@@ -119,6 +120,7 @@ _GLOBAL(__setup_cpu_e5500)
_GLOBAL(__restore_cpu_e6500)
mflrr5
bl .setup_altivec_ivors
+ bl setup_altivec_idle
bl __restore_cpu_e5500
mtlrr5
blr
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index d0861a0..93b563b 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -11,6 +11,16 @@
#include mpc85xx.h
+#define MAX_BIT64
+
+#define ALTIVEC_COUNT_OFFSET 16
+#define ALTIVEC_IDLE_COUNT_MASK0x003f
+
+/*
+ * FIXME - We don't know the AltiVec application scenarios.
+ */
+#define ALTIVEC_IDLE_TIME_BIT 14 /* 1ms */
+
static struct of_device_id __initdata mpc85xx_common_ids[] = {
{ .type = soc, },
{ .compatible = soc, },
@@ -80,3 +90,38 @@ void __init mpc85xx_cpm2_pic_init(void)
irq_set_chained_handler(irq, cpm2_cascade);
}
#endif
+
+static bool has_pw20_altivec_idle(void)
+{
+ u32 pvr;
+
+ pvr = mfspr(SPRN_PVR);
+
+ /* PW20 AltiVec idle feature only exists for E6500 */
+ if (PVR_VER(pvr) != PVR_VER_E6500)
+ return false;
+
+ return true;
+}
+
+void setup_altivec_idle(void)
+{
+ u32 altivec_idle;
+
+ if (!has_pw20_altivec_idle())
+ return;
+
+ /* Enable Altivec Idle */
+ altivec_idle = mfspr(SPRN_PWRMGTCR0);
+ altivec_idle |= PWRMGTCR0_ALTIVEC_IDLE;
+
+ /* Set Automatic AltiVec Idle Count */
+ /* clear count */
+ altivec_idle = ~ALTIVEC_IDLE_COUNT_MASK;
+
+ /* set count */
+ altivec_idle |=
+ ((MAX_BIT - ALTIVEC_IDLE_TIME_BIT) ALTIVEC_COUNT_OFFSET);
+
+ mtspr(SPRN_PWRMGTCR0, altivec_idle);
+}
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/3] powerpc/85xx: add hardware automatically enter pw20 state
From: Wang Dongsheng dongsheng.w...@freescale.com
Using hardware features make core automatically enter PW20 state.
Set a TB count to hardware, the effective count begins when PW10
is entered. When the effective period has expired, the core will
proceed from PW10 to PW20 if no exit conditions have occurred during
the period.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
Remove:
delete setup_idle_hw_governor function.
delete Fix erratum for rev1.
Move:
move setup_* into __setup/restore_cpu_e6500.
diff --git a/arch/powerpc/include/asm/reg_booke.h
b/arch/powerpc/include/asm/reg_booke.h
index 8364bbe..e846495 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -219,6 +219,7 @@
/* Bit definitions for PWRMGTCR0. */
#define PWRMGTCR0_ALTIVEC_IDLE (1 22) /* Altivec idle enable */
+#define PWRMGTCR0_PW20_WAIT(1 14) /* PW20 state enable bit */
/* Bit definitions for the MCSR. */
#define MCSR_MCS 0x8000 /* Machine Check Summary */
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 90bbb46..295ccb5 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -59,6 +59,7 @@ _GLOBAL(__setup_cpu_e6500)
bl .setup_altivec_ivors
#endif
bl setup_altivec_idle
+ bl setup_pw20_idle
bl __setup_cpu_e5500
mtlrr6
blr
@@ -121,6 +122,7 @@ _GLOBAL(__restore_cpu_e6500)
mflrr5
bl .setup_altivec_ivors
bl setup_altivec_idle
+ bl setup_pw20_idle
bl __restore_cpu_e5500
mtlrr5
blr
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index 93b563b..cdd526e 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -15,12 +15,22 @@
#define ALTIVEC_COUNT_OFFSET 16
#define ALTIVEC_IDLE_COUNT_MASK0x003f
+#define PW20_COUNT_OFFSET 8
+#define PW20_IDLE_COUNT_MASK 0x3f00
/*
* FIXME - We don't know the AltiVec application scenarios.
*/
#define ALTIVEC_IDLE_TIME_BIT 14 /* 1ms */
+/*
+ * FIXME - We don't know, what time should we let the core into PW20 state.
+ * because we don't know the current state of the cpu load. And threads are
+ * independent, so we can not know the state of different thread has been
+ * idle.
+ */
+#define PW20_IDLE_TIME_BIT 14 /* 1ms */
+
static struct of_device_id __initdata mpc85xx_common_ids[] = {
{ .type = soc, },
{ .compatible = soc, },
@@ -125,3 +135,25 @@ void setup_altivec_idle(void)
mtspr(SPRN_PWRMGTCR0, altivec_idle);
}
+
+void setup_pw20_idle(void)
+{
+ u32 pw20_idle;
+
+ if (!has_pw20_altivec_idle())
+ return;
+
+ pw20_idle = mfspr(SPRN_PWRMGTCR0);
+
+ /* Set PW20_WAIT bit, Enable PW20 State */
+ pw20_idle |= PWRMGTCR0_PW20_WAIT;
+
+ /* Set Automatic PW20 Core Idle Count */
+ /* clear count */
+ pw20_idle = ~PW20_IDLE_COUNT_MASK;
+
+ /* set count */
+ pw20_idle |= ((MAX_BIT - PW20_IDLE_TIME_BIT) PW20_COUNT_OFFSET);
+
+ mtspr(SPRN_PWRMGTCR0, pw20_idle);
+}
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Work around gcc miscompilation of __pa() on 64-bit
On Tue, Aug 27, 2013 at 04:42:35PM +0930, Alan Modra wrote: On Tue, Aug 27, 2013 at 04:07:49PM +1000, Paul Mackerras wrote: On 64-bit, __pa(static_var) gets miscompiled by recent versions of gcc as something like: addis 3,2,.LANCHOR1+4611686018427387904@toc@ha addi 3,3,.LANCHOR1+4611686018427387904@toc@l I might argue that this isn't a miscompilation, since -mcmodel=medium assumes everything can be accessed within +/-2G of the toc pointer, And there's the bug right there... the assumption that this number that I want to compute is the address of something that can be accessed. It isn't, and gcc shouldn't treat it as such (not unless I do something like subsequently casting it back to a pointer and dereferencing that). but it's definitely a problem since gas and/or ld don't give an overflow error. They would except for the fact that our ABI has a hole in it. Well, that and the fact that the code in gcc that generates instructions to compute addresses blindly uses addis; addi even when the offset involved is way too large for that to possibly work. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/2] fs: supply inode uid/gid setting interface
Subject: Re: [PATCH 0/2] fs: supply inode uid/gid setting interface On 2013/8/23 12:10, Greg KH wrote: On Fri, Aug 23, 2013 at 10:48:36AM +0800, Rui Xiang wrote: This patchset implements an accessor functions to set uid/gid in inode struct. Just finish code clean up. Why? It can introduce a new function to reduce some codes. Just clean up. In what sense is it a 'cleanup' ? To my mind it just means that anyone reading the code has to go and look at another file in order to see what the function does (it might be expected to be more complex). It also adds run time cost, while probably not directly measurable I suspect it more than doubles the execution time of that code fragment - do that everywhere and the system will run like a sick pig. The only real use for accessor functions is when you don't want the structure offset to be public. In this case that is obviously not the case since all the drivers are directly accessing other members of the structure. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/powernv: Create opal sysfs directory
Create /sys/firmware/opal directory. We wil use this
interface to fetch opal error logs, firmware update, etc.
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |3 +++
arch/powerpc/platforms/powernv/opal.c | 21 -
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ba6ffe6..4432b7a 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -523,6 +523,9 @@ typedef struct oppanel_line {
uint64_tline_len;
} oppanel_line_t;
+/* /sys/firmware/opal */
+extern struct kobject *opal_kobj;
+
/* API functions */
int64_t opal_console_write(int64_t term_number, int64_t *length,
const uint8_t *buffer);
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 106301f..1c48a68 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -17,11 +17,15 @@
#include linux/interrupt.h
#include linux/notifier.h
#include linux/slab.h
+#include linux/kobject.h
#include asm/opal.h
#include asm/firmware.h
#include powernv.h
+/* /sys/firmware/opal */
+struct kobject *opal_kobj;
+
struct opal {
u64 base;
u64 entry;
@@ -369,6 +373,17 @@ static irqreturn_t opal_interrupt(int irq, void *data)
return IRQ_HANDLED;
}
+static int opal_sysfs_init(void)
+{
+ opal_kobj = kobject_create_and_add(opal, firmware_kobj);
+ if (!opal_kobj) {
+ pr_warn(kobject_create_and_add opal failed\n);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
static int __init opal_init(void)
{
struct device_node *np, *consoles;
@@ -412,7 +427,11 @@ static int __init opal_init(void)
(0x%x)\n, rc, irq, hwirq);
opal_irqs[i] = irq;
}
- return 0;
+
+ /* Create opal kobject under /sys/firmware */
+ rc = opal_sysfs_init();
+
+ return rc;
}
subsys_initcall(opal_init);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 06/11] pstore: Add decompression support to pstore
On Friday 23 August 2013 04:34 AM, Seiji Aguchi wrote: -Original Message- From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Aruna Balakrishnaiah Sent: Friday, August 16, 2013 9:18 AM To: linuxppc-...@ozlabs.org; tony.l...@intel.com; linux-ker...@vger.kernel.org; keesc...@chromium.org Cc: jkeni...@linux.vnet.ibm.com; ana...@in.ibm.com; b...@kernel.crashing.org; cbouatmai...@gmail.com; mah...@linux.vnet.ibm.com; ccr...@android.com Subject: [RFC PATCH v2 06/11] pstore: Add decompression support to pstore Based on the flag 'compressed' set or not, pstore will decompress the data returning a plain text file. If decompression fails for a particular record it will have the compressed data in the file which can be decompressed with 'openssl' command line tool. If the decompression fails and openssl doesn't work, the worst case is that users can't read the entry. In that case, pstore is meaningless at all. If decompression fails and openssl doesn't work. We have python module zlib to decompress the zlib data. zlib.decompress() should do the trick. Also, for users who want to get a single panic message, a compression is not needed. So, I think we still have to support non-compression mode. (IMO, pstore can take kdump as a model. Kdump supports both compression and non-compression mode.) But, if you think my comment is outside this patchset, it's OK. We can make it with a separate patch. Seiji ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v8 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: Hongbo Zhang hongbo.zh...@freescale.com Hi DMA and DT maintainers, please have a look at these V8 patches. Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. V7-V8 changes: - change the word mapping to specifier for reg and interrupts description V6-V7 changes: - only remove unnecessary CHIP-dma explanations in [1/3] V5-V6 changes: - minor updates of descriptions in binding document and Kconfig - remove [4/4], that should be another patch in future V4-V5 changes: - update description in the dt binding document, to make it more resonable - add new patch [4/4] to eliminate a compiling warning which already exists for a long time V3-V4 changes: - introduce new patch [1/3] to revise the legacy dma binding document - and then add new paragraph to describe new dt node binding in [2/3] - rebase to latest kernel v3.11-rc1 V2-V3 changes: - edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt - edit text string in Kconfig and the driver files, using elo series to mention all the current elo* V1-V2 changes: - removed the codes handling the register dgsr1, since it isn't used currently - renamed the DMA DT compatible to fsl,elo3-dma - renamed the new dts files to elo3-dma-n.dtsi Hongbo Zhang (3): DMA: Freescale: revise device tree binding document DMA: Freescale: Add new 8-channel DMA engine device tree nodes DMA: Freescale: update driver to support 8-channel DMA engine .../devicetree/bindings/powerpc/fsl/dma.txt| 128 ++-- arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 + arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 + arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- drivers/dma/Kconfig|9 +- drivers/dma/fsldma.c |9 +- drivers/dma/fsldma.h |2 +- 8 files changed, 271 insertions(+), 47 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 -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v8 1/3] DMA: Freescale: revise device tree binding document
From: Hongbo Zhang hongbo.zh...@freescale.com This patch updates the discription of each type of DMA controller and its channels, it is preparation for adding another new DMA controller binding, it also fixes some defects of indent for text alignment at the same time. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 62 +--- 1 file changed, 27 insertions(+), 35 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bc..ddf17af 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -1,33 +1,29 @@ -* Freescale 83xx DMA Controller +* Freescale DMA Controllers -Freescale PowerPC 83xx have on chip general purpose DMA controllers. +** Freescale Elo DMA Controller + This is a little-endian DMA controller, used in Freescale mpc83xx series + chips such as mpc8315, mpc8349, mpc8379 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma, where CHIP is the processor -(mpc8349, mpc8360, etc.) and the second is -fsl,elo-dma -- reg : registers mapping for DMA general status reg -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- compatible: must include fsl,elo-dma +- reg : registers specifier for DMA general status reg +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - cell-index: controller index. 0 for controller @ 0x8100 -- interrupts: interrupt mapping for DMA IRQ +- interrupts: interrupt specifier for DMA IRQ - interrupt-parent : optional, if needed for interrupt mapping - - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma-channel, where CHIP is the processor -(mpc8349, mpc8350, etc.) and the second is -fsl,elo-dma-channel. However, see note below. -- reg : registers mapping for channel +- compatible: must include fsl,elo-dma-channel + However, see note below. +- reg : registers specifier for channel - cell-index: dma channel index starts at 0. Optional properties: -- interrupts: interrupt mapping for DMA channel IRQ - (on 83xx this is expected to be identical to - the interrupts property of the parent node) +- interrupts: interrupt specifier for DMA channel IRQ + (on 83xx this is expected to be identical to + the interrupts property of the parent node) - interrupt-parent : optional, if needed for interrupt mapping Example: @@ -70,30 +66,26 @@ Example: }; }; -* Freescale 85xx/86xx DMA Controller - -Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers. +** Freescale EloPlus DMA Controller + This is DMA controller with extended addresses and chaining, mainly used in + Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as mpc8540, mpc8641 + p4080, bsc9131 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma, where CHIP is the processor -(mpc8540, mpc8540, etc.) and the second is -fsl,eloplus-dma -- reg : registers mapping for DMA general status reg +- compatible: must include fsl,eloplus-dma +- reg : registers specifier for DMA general status reg - cell-index: controller index. 0 for controller @ 0x21000, 1 for controller @ 0xc000 -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma-channel, where CHIP is the processor -(mpc8540, mpc8560, etc.) and the second is -fsl,eloplus-dma-channel. However, see note below. +- compatible: must include fsl,eloplus-dma-channel + However, see note below. - cell-index: dma channel index starts at 0. -- reg : registers mapping for channel --
[PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Hongbo Zhang hongbo.zh...@freescale.com
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 232 insertions(+), 4 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
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : registers specifier for DMA general status reg
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include fsl,eloplus-dma-channel
+- reg : registers specifier for channel
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elo3-dma;
+ reg = 0x100300 0x4 0x100600 0x4;
+ ranges = 0x0 0x100100 0x500;
+ dma-channel@0 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ interrupts = 28 2 0 0;
+ };
+ dma-channel@80 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x80 0x80;
+ interrupts = 29 2 0 0;
+ };
+ dma-channel@100 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x100 0x80;
+ interrupts = 30 2 0 0;
+ };
+ dma-channel@180 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x180 0x80;
+ interrupts = 31 2 0 0;
+ };
+ dma-channel@300 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x300 0x80;
+ interrupts = 76 2 0 0;
+ };
+ dma-channel@380 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x380 0x80;
+ interrupts = 77 2 0 0;
+ };
+ dma-channel@400 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x400 0x80;
+ interrupts = 78 2 0 0;
+ };
+ dma-channel@480 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x480 0x80;
+ interrupts = 79 2 0 0;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = 0xe2000 0x1000;
};
-/include/ qoriq-dma-0.dtsi
+/include/ elo3-dma-0.dtsi
dma@100300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x580; /* DMA1LIODNR */
};
-/include/ qoriq-dma-1.dtsi
+/include/ elo3-dma-1.dtsi
dma@101300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x584; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
new file mode 100644
index 000..69a3277
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
@@ -0,0 +1,81 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x10 ]
+ *
+ * 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
[PATCH v8 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
drivers/dma/Kconfig |9 +
drivers/dma/fsldma.c |9 ++---
drivers/dma/fsldma.h |2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
- tristate Freescale Elo and Elo Plus DMA support
+ tristate Freescale Elo series DMA support
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate Freescale MPC512x built-in DMA engine support
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev-feature != chan-feature);
chan-dev = fdev-dev;
- chan-id = ((res.start - 0x100) 0xfff) 7;
+ chan-id = (res.start 0xfff) 0x300 ?
+ ((res.start - 0x100) 0xfff) 7 :
+ ((res.start - 0x200) 0xfff) 7;
if (chan-id = FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev-dev, too many channels for device\n);
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+ { .compatible = fsl,elo3-dma, },
{ .compatible = fsl,eloplus-dma, },
{ .compatible = fsl,elo-dma, },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
- pr_info(Freescale Elo / Elo Plus DMA driver\n);
+ pr_info(Freescale Elo series DMA driver\n);
return platform_driver_register(fsldma_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION(Freescale Elo / Elo Plus DMA driver);
+MODULE_DESCRIPTION(Freescale Elo series DMA driver);
MODULE_LICENSE(GPL);
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs; /* DGSR register base */
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
As for the property name, I'd prefer fsl,sata-speed-limit or fsl,sata- max-generation. Shaohui, do the driver bits look OK? [S.H] The driver part is OK. I also tested it on p5040, the SATA worked as expected. Best Regards, Shaohui Xie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
On Tue, Aug 27, 2013 at 06:42:18PM +1000, Alexey Kardashevskiy wrote:
On 08/27/2013 05:56 PM, Gleb Natapov wrote:
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
is 0xac, the next two numbers are taken - 0xad for KVM_KVMCLOCK_CTRL and
0xac was also taken by KVM_SET_ONE_REG :(
0xae for KVM_ARM_VCPU_INIT. So the KVM_CREATE_SPAPR_TCE_IOMMU ioclt gets
0xaf.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/08/15 v8:
* fixed comment again
2013/08/15:
* fixed mistype in comments
* fixed commit message which says what uses ioctls 0xad and 0xae
2013/07/16:
* changed the number
2013/07/11:
* changed order in a file, added comment about a gap in ioctl number
---
include/uapi/linux/kvm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 99c2533..bd94127 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
+#define KVM_CAP_SPAPR_TCE_IOMMU 95
#ifdef KVM_CAP_IRQ_ROUTING
@@ -933,6 +934,11 @@ struct kvm_s390_ucas_mapping {
#define KVM_ARM_SET_DEVICE_ADDR _IOW(KVMIO, 0xab, struct
kvm_arm_device_addr)
/* Available with KVM_CAP_PPC_RTAS */
#define KVM_PPC_RTAS_DEFINE_TOKEN _IOW(KVMIO, 0xac, struct
kvm_rtas_token_args)
+/* 0xad is taken by KVM_KVMCLOCK_CTRL */
+/* 0xae is taken by KVM_ARM_VCPU_INIT */
+/* Available with KVM_CAP_SPAPR_TCE_IOMMU */
+#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, \
+ struct kvm_create_spapr_tce_iommu)
Why not use KVM_CREATE_DEVICE API for that?
Because when I came up with my ioctl first time, it was not in upstream and
since then nobody pointed me to this new ioctl :)
Sorry about that :(. The ioctl exists for a while now, but with v8 patch I
imaging your patch series predates it.
So my stuff is not going to upstream again. Heh. Ok. I'll implement it.
Thanks! Should I keep KVM_CAP_SPAPR_MULTITCE capability patch or can I
drop it for now?
--
Gleb.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 1/3] DMA: Freescale: revise device tree binding document
On Tue, Aug 27, 2013 at 11:42:01AM +0100, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com This patch updates the discription of each type of DMA controller and its channels, it is preparation for adding another new DMA controller binding, it also fixes some defects of indent for text alignment at the same time. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 62 +--- 1 file changed, 27 insertions(+), 35 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bc..ddf17af 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -1,33 +1,29 @@ -* Freescale 83xx DMA Controller +* Freescale DMA Controllers -Freescale PowerPC 83xx have on chip general purpose DMA controllers. +** Freescale Elo DMA Controller + This is a little-endian DMA controller, used in Freescale mpc83xx series + chips such as mpc8315, mpc8349, mpc8379 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is - fsl,CHIP-dma, where CHIP is the processor - (mpc8349, mpc8360, etc.) and the second is - fsl,elo-dma -- reg : registers mapping for DMA general status reg -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- compatible: must include fsl,elo-dma We should list the other values that may be in the list also, unless they are really of no consequence, in which case their presence in dt is questionable. +- reg : registers specifier for DMA general status reg +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - cell-index: controller index. 0 for controller @ 0x8100 -- interrupts: interrupt mapping for DMA IRQ +- interrupts: interrupt specifier for DMA IRQ - interrupt-parent : optional, if needed for interrupt mapping - - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is - fsl,CHIP-dma-channel, where CHIP is the processor - (mpc8349, mpc8350, etc.) and the second is - fsl,elo-dma-channel. However, see note below. -- reg : registers mapping for channel +- compatible: must include fsl,elo-dma-channel + However, see note below. Again, I think we should list the other entries that may be in the list. Otherwise it's not clear what the binding defines. Similarly for the other compatible list definitions below... +- reg : registers specifier for channel - cell-index: dma channel index starts at 0. I realise you haven't changed it, but it's unclear what the cell-index property is (and somewhat confusingly there seem to be multiple defnitions). It might be worth clarifying it while performing the other cleanup. Optional properties: -- interrupts: interrupt mapping for DMA channel IRQ - (on 83xx this is expected to be identical to -the interrupts property of the parent node) +- interrupts: interrupt specifier for DMA channel IRQ + (on 83xx this is expected to be identical to + the interrupts property of the parent node) - interrupt-parent : optional, if needed for interrupt mapping Example: @@ -70,30 +66,26 @@ Example: }; }; -* Freescale 85xx/86xx DMA Controller - -Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers. +** Freescale EloPlus DMA Controller + This is DMA controller with extended addresses and chaining, mainly used in + Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as mpc8540, mpc8641 + p4080, bsc9131 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is - fsl,CHIP-dma, where CHIP is the processor - (mpc8540, mpc8540, etc.) and the second is - fsl,eloplus-dma -- reg : registers mapping for DMA general status reg +- compatible: must include fsl,eloplus-dma +- reg : registers specifier for DMA general status reg - cell-index: controller index. 0 for controller @ 0x21000, 1 for controller @ 0xc000 -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- ranges: describes the
Re: [PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On Tue, Aug 27, 2013 at 11:42:02AM +0100, 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 adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 232 insertions(+), 4 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
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and
Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : registers specifier for DMA general status reg
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA
controller
+
+- DMA channel nodes:
+- compatible: must include fsl,eloplus-dma-channel
+- reg : registers specifier for channel
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elo3-dma;
+ reg = 0x100300 0x4 0x100600 0x4;
Is that one reg entry where #size-cells=2 and #address-cells=2?
That's what the binding implies (given it only describes a single reg
entry).
if it's two entries, we should make that explicit (both in the binding
and example):
reg = 0x100300 0x4,
0x100600 0x4;
+ ranges = 0x0 0x100100 0x500;
If it is one reg entry then the example ranges property isn't big enough
to contain the parent-bus-address.
+ dma-channel@0 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ interrupts = 28 2 0 0;
+ };
+ dma-channel@80 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x80 0x80;
+ interrupts = 29 2 0 0;
+ };
+ dma-channel@100 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x100 0x80;
+ interrupts = 30 2 0 0;
+ };
+ dma-channel@180 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x180 0x80;
+ interrupts = 31 2 0 0;
+ };
+ dma-channel@300 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x300 0x80;
+ interrupts = 76 2 0 0;
+ };
+ dma-channel@380 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x380 0x80;
+ interrupts = 77 2 0 0;
+ };
+ dma-channel@400 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x400 0x80;
+ interrupts = 78 2 0 0;
+ };
+ dma-channel@480 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x480 0x80;
+ interrupts = 79 2 0 0;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = 0xe2000 0x1000;
};
-/include/ qoriq-dma-0.dtsi
+/include/ elo3-dma-0.dtsi
dma@100300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x580; /* DMA1LIODNR */
};
-/include/ qoriq-dma-1.dtsi
+/include/ elo3-dma-1.dtsi
dma@101300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x584; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
new file mode 100644
index 000..69a3277
---
Re: [PATCH][RFC] pci: fsl: rework PCIe driver compatible with Layerscape
Hi Scott,
Thanks for your comments, please see my replies inline.
On 08/24/2013 05:45 AM, Scott Wood wrote:
On Mon, 2013-08-19 at 20:23 +0800, Minghuan Lian wrote:
The Freescale's Layerscape series processors will use ARM cores.
The LS1's PCIe controllers is the same as T4240's. So it's better
the PCIe controller driver can support PowerPC and ARM
simultaneously. This patch is for this purpose. It derives
the common functions from arch/powerpc/sysdev/fsl_pci.c to
drivers/pci/host/pcie-fsl.c and leaves several platform-dependent
functions which should be implemented in platform files.
Signed-off-by: Minghuan Lianminghuan.l...@freescale.com
---
Based on upstream master 3.11-rc6
The function has been tested on P5020DS and P3041DS and T4240QDS boards
For mpc83xx and mpc86xx, I only did compile test.
I assume you'll test on these (and older mpc85xx) before this becomes
non-RFC?
[Minghuan] I will try to test on the relevant boards and list them.
arch/powerpc/Kconfig | 1 +
arch/powerpc/sysdev/fsl_pci.c | 591 ++
arch/powerpc/sysdev/fsl_pci.h | 91 --
drivers/edac/mpc85xx_edac.c | 10 -
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-fsl.c | 734 ++
include/linux/fsl/fsl-pcie.h | 176 ++
8 files changed, 1008 insertions(+), 600 deletions(-)
create mode 100644 drivers/pci/host/pcie-fsl.c
create mode 100644 include/linux/fsl/fsl-pcie.h
Please use -M -C with git format-patch.
Why pcie rather than pci? Is non-express not supported by these new
files?
[Minghuan] Using pci is more accurate. I selected 'pcie' because the
new file is
mainly for PCI Express controller, but it does contain two pci
boards(mpc8610,
mpc8540) support. I will change to 'pci'.
@@ -259,15 +258,6 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
/* we only need the error registers */
r.start += 0xe00;
-
- if (!devm_request_mem_region(op-dev, r.start, resource_size(r),
- pdata-name)) {
- printk(KERN_ERR %s: Error while requesting mem region\n,
- __func__);
- res = -EBUSY;
- goto err;
- }
-
pdata-pci_vbase = devm_ioremap(op-dev, r.start, resource_size(r));
if (!pdata-pci_vbase) {
printk(KERN_ERR %s: Unable to setup PCI err regs\n, __func__);
Could you explain this part?
[Minghuan] The new pci driver used devm_ioremap_resource() to map reg space.
So PCI EDAC driver would encounter an error when calling
devm_request_mem_region()
because pci device reg space has been assigned to pci driver. And EDAC
is only to
handler the error, has no reason to request exclusive PCI device reg space.
diff --git a/drivers/pci/host/pcie-fsl.c b/drivers/pci/host/pcie-fsl.c
new file mode 100644
index 000..6e767d4
--- /dev/null
+++ b/drivers/pci/host/pcie-fsl.c
@@ -0,0 +1,734 @@
+/*
+ * 85xx/86xx/LS PCI/PCIE common driver support
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Moved from arch/power/fsl_pci.c
That's not the right pathname.
[Minghuan] Sorry, I will fix it.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/string.h
+#include linux/init.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_pci.h
+#include linux/pci_regs.h
+#include linux/platform_device.h
+#include linux/resource.h
+#include linux/types.h
+#include linux/memblock.h
+#include linux/fsl/fsl-pcie.h
You don't need an fsl- prefix if it's in the fsl/ directory.
[Minghuan] No, I will remove 'fsl-' prefix.
+static int fsl_pcie_write_config(struct fsl_pcie *pcie, int bus, int devfn,
+int offset, int len, u32 val)
+{
+ void __iomem *cfg_data;
+ u32 bus_no, reg;
+
+ if (pcie-indirect_type INDIRECT_TYPE_NO_PCIE_LINK) {
+ if (bus != pcie-first_busno)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ if (devfn != 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ }
+
+ if (fsl_pci_exclude_device(pcie, bus, devfn))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ bus_no = (bus == pcie-first_busno) ?
+ pcie-self_busno : bus;
+
+ if (pcie-indirect_type INDIRECT_TYPE_EXT_REG)
+ reg = ((offset 0xf00) 16) | (offset 0xfc);
+ else
+ reg = offset 0xfc;
+
+ if (pcie-indirect_type INDIRECT_TYPE_BIG_ENDIAN)
+ out_be32(pcie-regs-config_addr,
+(0x8000 | (bus_no 16) | (devfn 8) | reg));
+
Re: [alsa-devel] [PATCH v11] ASoC: fsl: Add S/PDIF machine driver
On Tue, Aug 27, 2013 at 10:01:08AM +0800, Nicolin Chen wrote: On Fri, Aug 23, 2013 at 08:13:53PM +0100, Mark Brown wrote: I think this patch hasn't been applied yet, already been acked though. Is there any problem in it? You've allowed less than one working day for a response here - Monday was a holiday in the UK. Something like a week is normally a minimum for this sort of thing, especially in a case like this where there has been extensive discussion. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [alsa-devel] [PATCH v11] ASoC: fsl: Add S/PDIF machine driver
Oh, I didn't mean to push this. Sorry that I wasn't aware of it. I'll be more patient next time. Best regards, Nicolin Chen From: Mark Brown [broo...@kernel.org] Sent: Tuesday, August 27, 2013 10:50 PM To: Chen Guangyu-B42378 Cc: Stephen Warren; mark.rutl...@arm.com; devicet...@vger.kernel.org; alsa-de...@alsa-project.org; l...@metafoo.de; s.ha...@pengutronix.de; tomasz.f...@gmail.com; rob.herr...@calxeda.com; p.za...@pengutronix.de; shawn@linaro.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [alsa-devel] [PATCH v11] ASoC: fsl: Add S/PDIF machine driver On Tue, Aug 27, 2013 at 10:01:08AM +0800, Nicolin Chen wrote: On Fri, Aug 23, 2013 at 08:13:53PM +0100, Mark Brown wrote: I think this patch hasn't been applied yet, already been acked though. Is there any problem in it? You've allowed less than one working day for a response here - Monday was a holiday in the UK. Something like a week is normally a minimum for this sort of thing, especially in a case like this where there has been extensive discussion. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v3.11-rc7
On Tue, 27 Aug 2013, Geert Uytterhoeven wrote:
JFYI, when comparing v3.11-rc7 to v3.11-rc6[3], the summaries are:
- build errors: +15/-9
+ /scratch/kisskb/src/arch/powerpc/sysdev/mpic.c: error: case label does not
reduce to an integer constant: = 892:9, 904:9, 900:9, 896:9
+ /scratch/kisskb/src/drivers/net/ethernet/amd/lance.c: error: implicit
declaration of function 'isa_bus_to_virt'
[-Werror=implicit-function-declaration]: = 1204:6
+ /scratch/kisskb/src/drivers/net/ethernet/amd/lance.c: error: implicit
declaration of function 'isa_virt_to_bus'
[-Werror=implicit-function-declaration]: = 575:2
+ /scratch/kisskb/src/drivers/net/ethernet/amd/ni65.c: error: implicit
declaration of function 'isa_bus_to_virt'
[-Werror=implicit-function-declaration]: = 756:4
+ /scratch/kisskb/src/drivers/net/ethernet/amd/ni65.c: error: implicit
declaration of function 'isa_virt_to_bus'
[-Werror=implicit-function-declaration]: = 586:2
+ /scratch/kisskb/src/drivers/net/ethernet/cirrus/cs89x0.c: error: implicit
declaration of function 'isa_virt_to_bus'
[-Werror=implicit-function-declaration]: = 896:1
+ /scratch/kisskb/src/drivers/scsi/aha1542.c: error: implicit declaration of
function 'isa_page_to_bus' [-Werror=implicit-function-declaration]: = 674:4
+ /scratch/kisskb/src/drivers/scsi/aha1542.c: error: implicit declaration of
function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]: = 477:3
+ /scratch/kisskb/src/drivers/scsi/wd7000.c: error: implicit declaration of
function 'isa_bus_to_virt' [-Werror=implicit-function-declaration]: = 1055:2
+ /scratch/kisskb/src/drivers/scsi/wd7000.c: error: implicit declaration of
function 'isa_page_to_bus' [-Werror=implicit-function-declaration]: = 1121:4
+ error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]: = N/A
powerpc-randconfig
+ /scratch/kisskb/src/drivers/usb/host/ohci-pci.c: error: 'ohci_resume'
undeclared (first use in this function): = 310:34
+ /scratch/kisskb/src/drivers/usb/host/ohci-pci.c: error: 'ohci_suspend'
undeclared (first use in this function): = 309:35
20 configs suppressed ;-)
[1] http://kisskb.ellerman.id.au/kisskb/head/6579/ (all 120 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/6556/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V6 0/7] POWER/cpuidle: Generic IBM-POWER cpuidle driver enabled for PSERIES and POWERNV platforms
This patch series consolidates the backend cpuidle driver for pSeries and powernv platforms with minimal code duplication. Current existing backend driver for pseries has been moved to drivers/cpuidle and has been extended to accommodate powernv idle power mgmt states. As seen in V1 of this patch series, having a separate powernv backend driver results in too much code duplication, which is less elegant and can pose maintenance problems going further. Using the cpuidle framework to exploit platform low power idle states management can take advantage of advanced heuristics, tunables and features provided by framework. The statistics and tracing infrastructure provided by the cpuidle framework also helps in enabling power management related tools and help tune the system and applications. Earlier in 3.3 kernel, pSeries idle state management was modified to exploit the cpuidle framework and the end goal of this patch is to have powernv platform also to hook its idle states into cpuidle framework with minimal code duplication between both platforms. This series aims to maintain compatibility and functionality to existing pseries and powernv idle cpu management code. There are no new functions or idle states added as part of this series. This can be extended by adding more states to this existing framework. This patch series has been tested on both PSERIES and POWERNV platform and is based on v3.11-rc6 kernel version. With this patch series, the powernv cpuidle functionalities are on-par with pSeries idle management. V1 - http://lkml.org/lkml/2013/7/23/143 V2 - https://lkml.org/lkml/2013/7/30/872 V3 - http://comments.gmane.org/gmane.linux.ports.ppc.embedded/63093 V4 - https://lkml.org/lkml/2013/8/22/25 V5 - http://lkml.org/lkml/2013/8/22/184 Changes in V6: = * Made changes in Patch3: Generic POWER cpuidle driver in V5 by breaking down to multiple patches, as there were multiple changes including moving the file location. * Remove MAX_IDLE_STATE macro and kernel command line for IBM-POWER systems. * Make backend driver a built-in, instead of a module. As building this as a module is currently not possible. * Generic backend driver minor cleanups. * First two patches in V5 are not a part of the series, as they are generic cleanups, already pushed into the tree. Changes in V5: = * As per the discussions in the community, this patch series enables cpuidle backend driver only for IBM-POWER platforms. File is re-named from drivers/cpuidle/cpuidle-powerpc.c to drivers/cpuidle/cpuildle-ibm-power.c New back-end cpuidle driver is called IBM-POWER-Idle. * General cleanups on the accessors front that was introduced in previous version. Changes in V4: = * This patch series includes generic backend driver cpuidle cleanups including, replacing the driver and device initialisation routines with cpuidle_register function. * Enable CPUIDLE framework only for POWER and POWERNV platforms. Changes in V3: = * This patch series does not include smt-snooze-delay fixes. This will be taken up later on. * Integrated POWERPC driver in drivers/cpuidle. Enabled for all of POWERPC platform. Currently has PSERIES and POWERNV support. No compile time flags in .c file. This will be one consolidated binary that does a run time detection based on platform and take decisions accordingly. * Enabled CPUIDLE framwork for all of PPC64. Changes in V2: = * Merged the backend driver posted out for powernv in V1 with pSeries to create a single powerpc driver but this had compile time flags. Deepthi Dharwar (7): pseries/cpuidle: Move processor_idle.c to drivers/cpuidle. pseries/cpuidle: Use cpuidle_register() for initialisation. pseries/cpuidle: Make pseries_idle backend driver a non-module. pseries/cpuidle: Remove MAX_IDLE_STATE macro. POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES. POWER/cpuidle: Enable powernv cpuidle support. powernv/cpuidle: Enable idle powernv cpu to call into the cpuidle framework. arch/powerpc/include/asm/processor.h|2 arch/powerpc/platforms/powernv/setup.c | 14 + arch/powerpc/platforms/pseries/Kconfig |9 - arch/powerpc/platforms/pseries/Makefile |1 arch/powerpc/platforms/pseries/processor_idle.c | 360 --- drivers/cpuidle/Kconfig |5 drivers/cpuidle/Kconfig.powerpc | 10 + drivers/cpuidle/Makefile|2 drivers/cpuidle/cpuidle-ibm-power.c | 316 9 files changed, 347 insertions(+), 372 deletions(-) delete mode 100644 arch/powerpc/platforms/pseries/processor_idle.c create mode 100644 drivers/cpuidle/Kconfig.powerpc create mode 100644 drivers/cpuidle/cpuidle-ibm-power.c -- Deepthi ___
[PATCH V6 1/7] pseries/cpuidle: Move processor_idle.c to drivers/cpuidle.
Move the file from arch specific pseries/processor_idle.c
to drivers/cpuidle/cpuidle-ibm-power.c
Make the relevant Makefile and Kconfig changes.
This will enable having a common backend cpuidle driver
for POWER platform going forward.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/processor.h|2
arch/powerpc/platforms/pseries/Kconfig |9 -
arch/powerpc/platforms/pseries/Makefile |1
arch/powerpc/platforms/pseries/processor_idle.c | 360 ---
drivers/cpuidle/Kconfig |5
drivers/cpuidle/Kconfig.powerpc | 10 +
drivers/cpuidle/Makefile|2
drivers/cpuidle/cpuidle-ibm-power.c | 360 +++
8 files changed, 378 insertions(+), 371 deletions(-)
delete mode 100644 arch/powerpc/platforms/pseries/processor_idle.c
create mode 100644 drivers/cpuidle/Kconfig.powerpc
create mode 100644 drivers/cpuidle/cpuidle-ibm-power.c
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index e378ccc..ab444ff 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -430,7 +430,7 @@ enum idle_boot_override {IDLE_NO_OVERRIDE = 0,
IDLE_POWERSAVE_OFF};
extern int powersave_nap; /* set if nap mode can be used in idle loop */
extern void power7_nap(void);
-#ifdef CONFIG_PSERIES_IDLE
+#ifdef CONFIG_CPU_IDLE_IBM_POWER
extern void update_smt_snooze_delay(int cpu, int residency);
#else
static inline void update_smt_snooze_delay(int cpu, int residency) {}
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index 62b4f80..bb59bb0 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -119,12 +119,3 @@ config DTL
which are accessible through a debugfs file.
Say N if you are unsure.
-
-config PSERIES_IDLE
- bool Cpuidle driver for pSeries platforms
- depends on CPU_IDLE
- depends on PPC_PSERIES
- default y
- help
- Select this option to enable processor idle state management
- through cpuidle subsystem.
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 8ae0103..4b22379 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
obj-$(CONFIG_CMM) += cmm.o
obj-$(CONFIG_DTL) += dtl.o
obj-$(CONFIG_IO_EVENT_IRQ) += io_event_irq.o
-obj-$(CONFIG_PSERIES_IDLE) += processor_idle.o
ifeq ($(CONFIG_PPC_PSERIES),y)
obj-$(CONFIG_SUSPEND) += suspend.o
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
deleted file mode 100644
index c905b99..000
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ /dev/null
@@ -1,360 +0,0 @@
-/*
- * processor_idle - idle state cpuidle driver.
- * Adapted from drivers/idle/intel_idle.c and
- * drivers/acpi/processor_idle.c
- *
- */
-
-#include linux/kernel.h
-#include linux/module.h
-#include linux/init.h
-#include linux/moduleparam.h
-#include linux/cpuidle.h
-#include linux/cpu.h
-#include linux/notifier.h
-
-#include asm/paca.h
-#include asm/reg.h
-#include asm/machdep.h
-#include asm/firmware.h
-#include asm/runlatch.h
-#include asm/plpar_wrappers.h
-
-struct cpuidle_driver pseries_idle_driver = {
- .name = pseries_idle,
- .owner= THIS_MODULE,
-};
-
-#define MAX_IDLE_STATE_COUNT 2
-
-static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
-static struct cpuidle_device __percpu *pseries_cpuidle_devices;
-static struct cpuidle_state *cpuidle_state_table;
-
-static inline void idle_loop_prolog(unsigned long *in_purr)
-{
- *in_purr = mfspr(SPRN_PURR);
- /*
-* Indicate to the HV that we are idle. Now would be
-* a good time to find other work to dispatch.
-*/
- get_lppaca()-idle = 1;
-}
-
-static inline void idle_loop_epilog(unsigned long in_purr)
-{
- get_lppaca()-wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
- get_lppaca()-idle = 0;
-}
-
-static int snooze_loop(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- unsigned long in_purr;
- int cpu = dev-cpu;
-
- idle_loop_prolog(in_purr);
- local_irq_enable();
- set_thread_flag(TIF_POLLING_NRFLAG);
-
- while ((!need_resched()) cpu_online(cpu)) {
- ppc64_runlatch_off();
- HMT_low();
- HMT_very_low();
- }
-
- HMT_medium();
- clear_thread_flag(TIF_POLLING_NRFLAG);
- smp_mb();
-
- idle_loop_epilog(in_purr);
-
- return index;
-}
-
-static void check_and_cede_processor(void)
-{
- /*
-
[PATCH V6 3/7] pseries/cpuidle: Make pseries_idle backend driver a non-module.
Currently pseries_idle cpuidle backend driver cannot be
built as a module due to dependencies. Therefore the driver has
to be built in. The dependency is around update_snooze_delay() defined
in cpuidle driver and called from kernel/sysfs.c.
This patch is removes all the module related code.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
drivers/cpuidle/cpuidle-ibm-power.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
b/drivers/cpuidle/cpuidle-ibm-power.c
index b42b948..262db3c 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -288,17 +288,4 @@ static int __init pseries_processor_idle_init(void)
return 0;
}
-static void __exit pseries_processor_idle_exit(void)
-{
-
- unregister_cpu_notifier(setup_hotplug_notifier);
- cpuidle_unregister(pseries_idle_driver);
- return;
-}
-
-module_init(pseries_processor_idle_init);
-module_exit(pseries_processor_idle_exit);
-
-MODULE_AUTHOR(Deepthi Dharwar deep...@linux.vnet.ibm.com);
-MODULE_DESCRIPTION(Cpuidle driver for POWER);
-MODULE_LICENSE(GPL);
+device_initcall(pseries_processor_idle_init);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V6 2/7] pseries/cpuidle: Use cpuidle_register() for initialisation.
This patch replaces the cpuidle driver and devices initialisation
calls with a single generic cpuidle_register() call
and also includes minor refactoring of the code around it.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
drivers/cpuidle/cpuidle-ibm-power.c | 80 +--
1 file changed, 12 insertions(+), 68 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
b/drivers/cpuidle/cpuidle-ibm-power.c
index c905b99..b42b948 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -1,5 +1,5 @@
/*
- * processor_idle - idle state cpuidle driver.
+ * cpuidle-ibm-power - idle state cpuidle driver.
* Adapted from drivers/idle/intel_idle.c and
* drivers/acpi/processor_idle.c
*
@@ -28,7 +28,6 @@ struct cpuidle_driver pseries_idle_driver = {
#define MAX_IDLE_STATE_COUNT 2
static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
-static struct cpuidle_device __percpu *pseries_cpuidle_devices;
static struct cpuidle_state *cpuidle_state_table;
static inline void idle_loop_prolog(unsigned long *in_purr)
@@ -52,13 +51,12 @@ static int snooze_loop(struct cpuidle_device *dev,
int index)
{
unsigned long in_purr;
- int cpu = dev-cpu;
idle_loop_prolog(in_purr);
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);
- while ((!need_resched()) cpu_online(cpu)) {
+ while (!need_resched()) {
ppc64_runlatch_off();
HMT_low();
HMT_very_low();
@@ -187,7 +185,7 @@ static int pseries_cpuidle_add_cpu_notifier(struct
notifier_block *n,
{
int hotcpu = (unsigned long)hcpu;
struct cpuidle_device *dev =
- per_cpu_ptr(pseries_cpuidle_devices, hotcpu);
+ per_cpu(cpuidle_devices, hotcpu);
if (dev cpuidle_get_driver()) {
switch (action) {
@@ -244,50 +242,6 @@ static int pseries_cpuidle_driver_init(void)
return 0;
}
-/* pseries_idle_devices_uninit(void)
- * unregister cpuidle devices and de-allocate memory
- */
-static void pseries_idle_devices_uninit(void)
-{
- int i;
- struct cpuidle_device *dev;
-
- for_each_possible_cpu(i) {
- dev = per_cpu_ptr(pseries_cpuidle_devices, i);
- cpuidle_unregister_device(dev);
- }
-
- free_percpu(pseries_cpuidle_devices);
- return;
-}
-
-/* pseries_idle_devices_init()
- * allocate, initialize and register cpuidle device
- */
-static int pseries_idle_devices_init(void)
-{
- int i;
- struct cpuidle_driver *drv = pseries_idle_driver;
- struct cpuidle_device *dev;
-
- pseries_cpuidle_devices = alloc_percpu(struct cpuidle_device);
- if (pseries_cpuidle_devices == NULL)
- return -ENOMEM;
-
- for_each_possible_cpu(i) {
- dev = per_cpu_ptr(pseries_cpuidle_devices, i);
- dev-state_count = drv-state_count;
- dev-cpu = i;
- if (cpuidle_register_device(dev)) {
- printk(KERN_DEBUG \
- cpuidle_register_device %d failed!\n, i);
- return -EIO;
- }
- }
-
- return 0;
-}
-
/*
* pseries_idle_probe()
* Choose state table for shared versus dedicated partition
@@ -295,9 +249,6 @@ static int pseries_idle_devices_init(void)
static int pseries_idle_probe(void)
{
- if (!firmware_has_feature(FW_FEATURE_SPLPAR))
- return -ENODEV;
-
if (cpuidle_disable != IDLE_NO_OVERRIDE)
return -ENODEV;
@@ -306,10 +257,13 @@ static int pseries_idle_probe(void)
return -EPERM;
}
- if (get_lppaca()-shared_proc)
- cpuidle_state_table = shared_states;
- else
- cpuidle_state_table = dedicated_states;
+ if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+ if (get_lppaca()-shared_proc)
+ cpuidle_state_table = shared_states;
+ else
+ cpuidle_state_table = dedicated_states;
+ } else
+ return -ENODEV;
return 0;
}
@@ -323,22 +277,14 @@ static int __init pseries_processor_idle_init(void)
return retval;
pseries_cpuidle_driver_init();
- retval = cpuidle_register_driver(pseries_idle_driver);
+ retval = cpuidle_register(pseries_idle_driver, NULL);
if (retval) {
printk(KERN_DEBUG Registration of pseries driver failed.\n);
return retval;
}
- retval = pseries_idle_devices_init();
- if (retval) {
- pseries_idle_devices_uninit();
- cpuidle_unregister_driver(pseries_idle_driver);
- return retval;
- }
-
register_cpu_notifier(setup_hotplug_notifier);
printk(KERN_DEBUG pseries_idle_driver
[PATCH V6 5/7] POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES.
This patch includes cleanup and refactoring of the
existing code to make the driver POWER generic.
* Re-naming the functions from pseries to generic power.
* Re-naming the backend driver from pseries_idle to
ibm-power-idle.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
drivers/cpuidle/cpuidle-ibm-power.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
b/drivers/cpuidle/cpuidle-ibm-power.c
index 14ebdb4..162deda 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -20,8 +20,8 @@
#include asm/runlatch.h
#include asm/plpar_wrappers.h
-struct cpuidle_driver pseries_idle_driver = {
- .name = pseries_idle,
+struct cpuidle_driver power_idle_driver = {
+ .name = ibm_power_idle,
.owner= THIS_MODULE,
};
@@ -178,7 +178,7 @@ void update_smt_snooze_delay(int cpu, int residency)
drv-states[1].target_residency = residency;
}
-static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
+static int power_cpuidle_add_cpu_notifier(struct notifier_block *n,
unsigned long action, void *hcpu)
{
int hotcpu = (unsigned long)hcpu;
@@ -209,16 +209,16 @@ static int pseries_cpuidle_add_cpu_notifier(struct
notifier_block *n,
}
static struct notifier_block setup_hotplug_notifier = {
- .notifier_call = pseries_cpuidle_add_cpu_notifier,
+ .notifier_call = power_cpuidle_add_cpu_notifier,
};
/*
- * pseries_cpuidle_driver_init()
+ * power_cpuidle_driver_init()
*/
-static int pseries_cpuidle_driver_init(void)
+static int power_cpuidle_driver_init(void)
{
int idle_state;
- struct cpuidle_driver *drv = pseries_idle_driver;
+ struct cpuidle_driver *drv = power_idle_driver;
drv-state_count = 0;
for (idle_state = 0; idle_state max_idle_state; ++idle_state) {
@@ -237,10 +237,10 @@ static int pseries_cpuidle_driver_init(void)
}
/*
- * pseries_idle_probe()
+ * power_idle_probe()
* Choose state table for shared versus dedicated partition
*/
-static int pseries_idle_probe(void)
+static int power_idle_probe(void)
{
if (cpuidle_disable != IDLE_NO_OVERRIDE)
@@ -260,24 +260,24 @@ static int pseries_idle_probe(void)
return 0;
}
-static int __init pseries_processor_idle_init(void)
+static int __init power_processor_idle_init(void)
{
int retval;
- retval = pseries_idle_probe();
+ retval = power_idle_probe();
if (retval)
return retval;
- pseries_cpuidle_driver_init();
- retval = cpuidle_register(pseries_idle_driver, NULL);
+ power_cpuidle_driver_init();
+ retval = cpuidle_register(power_idle_driver, NULL);
if (retval) {
- printk(KERN_DEBUG Registration of pseries driver failed.\n);
+ printk(KERN_DEBUG Registration of ibm_power_idle driver
failed.\n);
return retval;
}
register_cpu_notifier(setup_hotplug_notifier);
- printk(KERN_DEBUG pseries_idle_driver registered\n);
+ printk(KERN_DEBUG ibm_power_idle registered\n);
return 0;
}
-device_initcall(pseries_processor_idle_init);
+device_initcall(power_processor_idle_init);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V6 4/7] pseries/cpuidle: Remove MAX_IDLE_STATE macro.
This patch removes the usage of MAX_IDLE_STATE macro
and dead code around it. The number of states
are determined at run time based on the cpuidle
state table selected on a given platform
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
drivers/cpuidle/cpuidle-ibm-power.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
b/drivers/cpuidle/cpuidle-ibm-power.c
index 262db3c..14ebdb4 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -25,9 +25,7 @@ struct cpuidle_driver pseries_idle_driver = {
.owner= THIS_MODULE,
};
-#define MAX_IDLE_STATE_COUNT 2
-
-static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
+static int max_idle_state;
static struct cpuidle_state *cpuidle_state_table;
static inline void idle_loop_prolog(unsigned long *in_purr)
@@ -133,7 +131,7 @@ static int shared_cede_loop(struct cpuidle_device *dev,
/*
* States for dedicated partition case.
*/
-static struct cpuidle_state dedicated_states[MAX_IDLE_STATE_COUNT] = {
+static struct cpuidle_state dedicated_states[] = {
{ /* Snooze */
.name = snooze,
.desc = snooze,
@@ -153,7 +151,7 @@ static struct cpuidle_state
dedicated_states[MAX_IDLE_STATE_COUNT] = {
/*
* States for shared partition case.
*/
-static struct cpuidle_state shared_states[MAX_IDLE_STATE_COUNT] = {
+static struct cpuidle_state shared_states[] = {
{ /* Shared Cede */
.name = Shared Cede,
.desc = Shared Cede,
@@ -223,11 +221,7 @@ static int pseries_cpuidle_driver_init(void)
struct cpuidle_driver *drv = pseries_idle_driver;
drv-state_count = 0;
-
- for (idle_state = 0; idle_state MAX_IDLE_STATE_COUNT; ++idle_state) {
-
- if (idle_state max_idle_state)
- break;
+ for (idle_state = 0; idle_state max_idle_state; ++idle_state) {
/* is the state not enabled? */
if (cpuidle_state_table[idle_state].enter == NULL)
@@ -252,16 +246,14 @@ static int pseries_idle_probe(void)
if (cpuidle_disable != IDLE_NO_OVERRIDE)
return -ENODEV;
- if (max_idle_state == 0) {
- printk(KERN_DEBUG pseries processor idle disabled.\n);
- return -EPERM;
- }
-
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
- if (get_lppaca()-shared_proc)
+ if (get_lppaca()-shared_proc) {
cpuidle_state_table = shared_states;
- else
+ max_idle_state = ARRAY_SIZE(shared_states);
+ } else {
cpuidle_state_table = dedicated_states;
+ max_idle_state = ARRAY_SIZE(dedicated_states);
+ }
} else
return -ENODEV;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V6 6/7] POWER/cpuidle: Enable powernv cpuidle support.
The following patch extends the current power backend
idle driver to the powernv platform.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
drivers/cpuidle/cpuidle-ibm-power.c | 39 ---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
b/drivers/cpuidle/cpuidle-ibm-power.c
index 162deda..f8905c3 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -48,9 +48,10 @@ static int snooze_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- unsigned long in_purr;
+ unsigned long in_purr = 0;
- idle_loop_prolog(in_purr);
+ if (firmware_has_feature(FW_FEATURE_SPLPAR))
+ idle_loop_prolog(in_purr);
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);
@@ -64,7 +65,8 @@ static int snooze_loop(struct cpuidle_device *dev,
clear_thread_flag(TIF_POLLING_NRFLAG);
smp_mb();
- idle_loop_epilog(in_purr);
+ if (firmware_has_feature(FW_FEATURE_SPLPAR))
+ idle_loop_epilog(in_purr);
return index;
}
@@ -128,6 +130,15 @@ static int shared_cede_loop(struct cpuidle_device *dev,
return index;
}
+static int nap_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ ppc64_runlatch_off();
+ power7_idle();
+ return index;
+}
+
/*
* States for dedicated partition case.
*/
@@ -161,6 +172,23 @@ static struct cpuidle_state shared_states[] = {
.enter = shared_cede_loop },
};
+static struct cpuidle_state powernv_states[] = {
+ { /* Snooze */
+ .name = snooze,
+ .desc = snooze,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 0,
+ .target_residency = 0,
+ .enter = snooze_loop },
+ { /* NAP */
+ .name = NAP,
+ .desc = NAP,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 10,
+ .target_residency = 100,
+ .enter = nap_loop },
+};
+
void update_smt_snooze_delay(int cpu, int residency)
{
struct cpuidle_driver *drv = cpuidle_get_driver();
@@ -254,6 +282,11 @@ static int power_idle_probe(void)
cpuidle_state_table = dedicated_states;
max_idle_state = ARRAY_SIZE(dedicated_states);
}
+
+ } else if (firmware_has_feature(FW_FEATURE_OPALv3)) {
+ cpuidle_state_table = powernv_states;
+ max_idle_state = ARRAY_SIZE(powernv_states);
+
} else
return -ENODEV;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V6 7/7] powernv/cpuidle: Enable idle powernv cpu to call into the cpuidle framework.
This patch enables idle cpu on the powernv platform to hook on to the cpuidle
framework, if available, else call on to default idle platform
code.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/setup.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 84438af..fc62f21 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -25,6 +25,7 @@
#include linux/of.h
#include linux/interrupt.h
#include linux/bug.h
+#include linux/cpuidle.h
#include asm/machdep.h
#include asm/firmware.h
@@ -175,6 +176,17 @@ static void __init pnv_setup_machdep_rtas(void)
}
#endif /* CONFIG_PPC_POWERNV_RTAS */
+void powernv_idle(void)
+{
+ /* Hook to cpuidle framework if available, else
+* call on default platform idle code
+*/
+ if (cpuidle_idle_call()) {
+ HMT_low();
+ HMT_very_low();
+ }
+}
+
static int __init pnv_probe(void)
{
unsigned long root = of_get_flat_dt_root();
@@ -205,7 +217,7 @@ define_machine(powernv) {
.show_cpuinfo = pnv_show_cpuinfo,
.progress = pnv_progress,
.machine_shutdown = pnv_shutdown,
- .power_save = power7_idle,
+ .power_save = powernv_idle,
.calibrate_decr = generic_calibrate_decr,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ppc: bpf_jit: support MOD operation
commit b6069a9570 (filter: add MOD operation) added generic
support for modulus operation in BPF.
This patch brings JIT support for PPC64
Signed-off-by: Vladimir Murzin murzi...@gmail.com
---
arch/powerpc/net/bpf_jit_comp.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index bf56e33..96f24dc 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -193,6 +193,28 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32
*image,
PPC_MUL(r_A, r_A, r_scratch1);
}
break;
+ case BPF_S_ALU_MOD_X: /* A %= X; */
+ ctx-seen |= SEEN_XREG;
+ PPC_CMPWI(r_X, 0);
+ if (ctx-pc_ret0 != -1) {
+ PPC_BCC(COND_EQ, addrs[ctx-pc_ret0]);
+ } else {
+ PPC_BCC_SHORT(COND_NE, (ctx-idx*4)+12);
+ PPC_LI(r_ret, 0);
+ PPC_JMP(exit_addr);
+ }
+ PPC_DIVWU(r_scratch1, r_A, r_X);
+ PPC_MUL(r_scratch1, r_X, r_scratch1);
+ PPC_SUB(r_A, r_A, r_scratch1);
+ break;
+ case BPF_S_ALU_MOD_K: /* A %= K; */
+#define r_scratch2 (r_scratch1 + 1)
+ PPC_LI32(r_scratch2, K);
+ PPC_DIVWU(r_scratch1, r_A, r_scratch2);
+ PPC_MUL(r_scratch1, r_scratch2, r_scratch1);
+ PPC_SUB(r_A, r_A, r_scratch1);
+#undef r_scratch2
+ break;
case BPF_S_ALU_DIV_X: /* A /= X; */
ctx-seen |= SEEN_XREG;
PPC_CMPWI(r_X, 0);
--
1.8.1.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Critical Interrupt Input
Both methods you described seem to work. We are currently using the
method of clearing the partially written TLB. Seems to be working but
we're still testing. Thanks.
.
.
.
mfspr r5,SPRN_CSRR0;
lis r12,finish_tlb_load_44x@h
ori r12,r12,finish_tlb_load_44x@l;
addir11,r12,finish_tlb_load_44x_end-finish_tlb_load_44x;
cmplw cr0,r5,r12;
cmplw cr1,r5,r11;
ble cr0,3f;
bge cr1,3f;
li r12,0;
mr r5,r11
tlbwe r12,r13,PPC44x_TLB_XLAT;
tlbwe r12,r13,PPC44x_TLB_PAGEID; /* Clear PAGEID */
tlbwe r12,r13,PPC44x_TLB_ATTRIB; /* Clear ATTRIB */
isync
.
.
.
On Wed, 2013-08-21 at 09:08 +1000, Benjamin Herrenschmidt wrote:
On Tue, 2013-08-20 at 15:48 -0700, Henry Bausley wrote:
Ben,
After your hints I suspected the read of a real world i/o variable *piom
which came from ioremap_nocache in the 3 line critical interrupt handler
void critintr_handler(void *dev)
{
critintrcount++; // increment a variable
iodata = *piom; // read an I/O location
mtdcr(0x0c0, 0x2000); // clear critical interrupt
}
is what caused the problem. Commenting it out seems to make the system
stable.
Right, definitely would do that. BTW. You may want to use proper IO
accessors while at it, to get the right memory barriers etc...
This led us to disable the critical interrupt when in the
DataTLBError44x and InstructionTLBError44x exceptions. Now the critical
interrupt handler seems to make things more stable when reading real
world i/o for our application.
/* Data TLB Error Interrupt */
START_EXCEPTION(DataTLBError44x)
mtspr SPRN_SPRG_WSCRATCH0, r10 /* Save some working */
+ mfmsr r10 /* Disable the */
+ rlwinm r10,r10,0,15,13 /* MSR's CE bit */
+ mtmsr r10
Do you see any potential problems with this approach?
If so can you advise us on how to better take care of this.
- You potentially still have an exposure ... between the mtspr to
scratch and the mfmsr, a CRIC can occur, causing a re-entrancy which
would than clobber the scratch register. That can be handled by saving
that scratc SPRG into the stack frame on entry/exit from the crit
interrupt. Look at crit_transfer_to_handler, how it already handles
MMUCR:
mfspr r0,SPRN_MMUCR
stw r0,MMUCR(r11)
Probably add saving of the SPRG_WSCRATCH0 in there (need to add a frame
slot for it) and do the restore in RESTORE_MMU_REGS
- You need to handle Instructions TLB miss as well
- You add overhead to the TLB miss handlers which are fairly
performance critical pieces of code. You might be able to alleviate
that by making the whole thing support re-entrancy properly but that's
harder. To do that you would have to:
* Save *all* the SPRGs used by the TLB miss during crit entry/exit
* Detect in crit_transfer_to_handler (check the CSRR0 bounds) that
the crit code interrupted finish_tlb_load_44x before or at the
last tlbwe instruction. In that case, immediately clear the
partially written TLB entry (index in r13) and change the
return address to skip right past the last tlbwe.
Cheers,
Ben.
On Tue, 2013-08-20 at 06:56 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-19 at 12:00 -0700, Henry Bausley wrote:
Support does appear to be present but there is a problem returning
back to user space I suspect.
Probably a problem with TLB misses vs. crit interrupts.
A critical interrupt can re-enter a TLB miss.
I can see two potential issues there:
- A bug where we don't properly restore something (I thought we did
save and restore MMUCR though, but that's worth dbl checking if it works
properly) accross the crit entry/exit
- Something in your crit code causing a TLB miss (the
kernel .text/.data/.bss should be bolted but anything else can). We
don't currently support re-entering the TLB miss that way.
If we were to support the latter, we'd need to detect on entering a crit
that the PC is within the TLB miss handler, and setup a return context
to the original instruction (replay the miss) rather than trying to
resume it..
Cheers,
Ben.
What fails is it causes Linux user space programs to get Segmentation
errors.
Issuing a simple ls causes a segmentation fault sometimes. The shell
gets terminated
and you cannot log back in. INIT: Id T0 respawning too fast:
disabled for 5 minutes pops up.
However, the critical interrupt handler keeps running. I know this by
adding the reading
of a physical I/O location in the handler and can see it is being read
on the scope.
The only code in the handler is below.
Re: Critical Interrupt Input
On Tue, 2013-08-27 at 15:11 -0700, Henry Bausley wrote:
Both methods you described seem to work. We are currently using the
method of clearing the partially written TLB. Seems to be working but
we're still testing. Thanks.
Feel free to send me us patch for review :-)
Cheers,
Ben.
.
.
.
mfspr r5,SPRN_CSRR0;
lis r12,finish_tlb_load_44x@h
ori r12,r12,finish_tlb_load_44x@l;
addir11,r12,finish_tlb_load_44x_end-finish_tlb_load_44x;
cmplw cr0,r5,r12;
cmplw cr1,r5,r11;
ble cr0,3f;
bge cr1,3f;
li r12,0;
mr r5,r11
tlbwe r12,r13,PPC44x_TLB_XLAT;
tlbwe r12,r13,PPC44x_TLB_PAGEID; /* Clear PAGEID */
tlbwe r12,r13,PPC44x_TLB_ATTRIB;/* Clear ATTRIB */
isync
.
.
.
On Wed, 2013-08-21 at 09:08 +1000, Benjamin Herrenschmidt wrote:
On Tue, 2013-08-20 at 15:48 -0700, Henry Bausley wrote:
Ben,
After your hints I suspected the read of a real world i/o variable *piom
which came from ioremap_nocache in the 3 line critical interrupt handler
void critintr_handler(void *dev)
{
critintrcount++; // increment a variable
iodata = *piom; // read an I/O location
mtdcr(0x0c0, 0x2000); // clear critical interrupt
}
is what caused the problem. Commenting it out seems to make the system
stable.
Right, definitely would do that. BTW. You may want to use proper IO
accessors while at it, to get the right memory barriers etc...
This led us to disable the critical interrupt when in the
DataTLBError44x and InstructionTLBError44x exceptions. Now the critical
interrupt handler seems to make things more stable when reading real
world i/o for our application.
/* Data TLB Error Interrupt */
START_EXCEPTION(DataTLBError44x)
mtspr SPRN_SPRG_WSCRATCH0, r10 /* Save some working */
+ mfmsr r10 /* Disable the */
+ rlwinm r10,r10,0,15,13 /* MSR's CE bit */
+ mtmsr r10
Do you see any potential problems with this approach?
If so can you advise us on how to better take care of this.
- You potentially still have an exposure ... between the mtspr to
scratch and the mfmsr, a CRIC can occur, causing a re-entrancy which
would than clobber the scratch register. That can be handled by saving
that scratc SPRG into the stack frame on entry/exit from the crit
interrupt. Look at crit_transfer_to_handler, how it already handles
MMUCR:
mfspr r0,SPRN_MMUCR
stw r0,MMUCR(r11)
Probably add saving of the SPRG_WSCRATCH0 in there (need to add a frame
slot for it) and do the restore in RESTORE_MMU_REGS
- You need to handle Instructions TLB miss as well
- You add overhead to the TLB miss handlers which are fairly
performance critical pieces of code. You might be able to alleviate
that by making the whole thing support re-entrancy properly but that's
harder. To do that you would have to:
* Save *all* the SPRGs used by the TLB miss during crit entry/exit
* Detect in crit_transfer_to_handler (check the CSRR0 bounds) that
the crit code interrupted finish_tlb_load_44x before or at the
last tlbwe instruction. In that case, immediately clear the
partially written TLB entry (index in r13) and change the
return address to skip right past the last tlbwe.
Cheers,
Ben.
On Tue, 2013-08-20 at 06:56 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-19 at 12:00 -0700, Henry Bausley wrote:
Support does appear to be present but there is a problem returning
back to user space I suspect.
Probably a problem with TLB misses vs. crit interrupts.
A critical interrupt can re-enter a TLB miss.
I can see two potential issues there:
- A bug where we don't properly restore something (I thought we did
save and restore MMUCR though, but that's worth dbl checking if it works
properly) accross the crit entry/exit
- Something in your crit code causing a TLB miss (the
kernel .text/.data/.bss should be bolted but anything else can). We
don't currently support re-entering the TLB miss that way.
If we were to support the latter, we'd need to detect on entering a crit
that the PC is within the TLB miss handler, and setup a return context
to the original instruction (replay the miss) rather than trying to
resume it..
Cheers,
Ben.
What fails is it causes Linux user space programs to get Segmentation
errors.
Issuing a simple ls causes a segmentation fault sometimes. The shell
gets terminated
and you cannot log back in. INIT: Id T0 respawning too fast:
disabled for 5 minutes pops up.
However, the
Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
On 08/27/2013 08:58 PM, Gleb Natapov wrote:
On Tue, Aug 27, 2013 at 06:42:18PM +1000, Alexey Kardashevskiy wrote:
On 08/27/2013 05:56 PM, Gleb Natapov wrote:
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
is 0xac, the next two numbers are taken - 0xad for KVM_KVMCLOCK_CTRL and
0xac was also taken by KVM_SET_ONE_REG :(
0xae for KVM_ARM_VCPU_INIT. So the KVM_CREATE_SPAPR_TCE_IOMMU ioclt gets
0xaf.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/08/15 v8:
* fixed comment again
2013/08/15:
* fixed mistype in comments
* fixed commit message which says what uses ioctls 0xad and 0xae
2013/07/16:
* changed the number
2013/07/11:
* changed order in a file, added comment about a gap in ioctl number
---
include/uapi/linux/kvm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 99c2533..bd94127 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
+#define KVM_CAP_SPAPR_TCE_IOMMU 95
#ifdef KVM_CAP_IRQ_ROUTING
@@ -933,6 +934,11 @@ struct kvm_s390_ucas_mapping {
#define KVM_ARM_SET_DEVICE_ADDR _IOW(KVMIO, 0xab, struct
kvm_arm_device_addr)
/* Available with KVM_CAP_PPC_RTAS */
#define KVM_PPC_RTAS_DEFINE_TOKEN _IOW(KVMIO, 0xac, struct
kvm_rtas_token_args)
+/* 0xad is taken by KVM_KVMCLOCK_CTRL */
+/* 0xae is taken by KVM_ARM_VCPU_INIT */
+/* Available with KVM_CAP_SPAPR_TCE_IOMMU */
+#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, \
+ struct kvm_create_spapr_tce_iommu)
Why not use KVM_CREATE_DEVICE API for that?
Because when I came up with my ioctl first time, it was not in upstream and
since then nobody pointed me to this new ioctl :)
Sorry about that :(. The ioctl exists for a while now, but with v8 patch I
imaging your patch series predates it.
The ioctl I made up is basically a copy of KVM_CREATE_SPAPR_TCE which does
the same thing for emulated devices and it is there for quite a while but
it is not really extensible. And these two ioctls share some bits of code.
Now we will have 2 pieces of code which do almost the same thing but in a
different way. Kinda sucks :(
So my stuff is not going to upstream again. Heh. Ok. I'll implement it.
Thanks! Should I keep KVM_CAP_SPAPR_MULTITCE capability patch or can I
drop it for now?
Please keep it, it is unrelated to the IOMMU-VFIO thing.
--
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 13/31] clk: wrap I/O access for improved portability
Quoting Anatolij Gustschin (2013-08-23 15:05:39) On Fri, 02 Aug 2013 15:30:00 -0700 Mike Turquette mturque...@linaro.org wrote: Quoting Gerhard Sittig (2013-07-22 05:14:40) the common clock drivers were motivated/initiated by ARM development and apparently assume little endian peripherals wrap register/peripherals access in the common code (div, gate, mux) in preparation of adding COMMON_CLK support for other platforms Signed-off-by: Gerhard Sittig g...@denx.de I've taken this into clk-next for testing. regmap deserves investigation but I don't think your series should be blocked on that. We can always overhaul the basic clock primitives with regmap support later on if that makes sense. Mike, I cannot see it in clk-next branch of git://git.linaro.org/people/mturquette/linux.git Can you please check? Or am I looking in the wrong place? You were looking in the right place but I had not pushed out the latest patches from my local branch. It should be there now. Regards, Mike Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
On Wed, 2013-08-28 at 10:51 +1000, Alexey Kardashevskiy wrote: The ioctl I made up is basically a copy of KVM_CREATE_SPAPR_TCE which does the same thing for emulated devices and it is there for quite a while but it is not really extensible. And these two ioctls share some bits of code. Now we will have 2 pieces of code which do almost the same thing but in a different way. Kinda sucks :( Right. Thus the question, Gleb, we can either: - Keep Alexey patch as-is allowing us to *finally* merge that stuff that's been around for monthes - Convert *both* existing TCE objects to the new KVM_CREATE_DEVICE, and have some backward compat code for the old one. I don't think it makes sense to have the emulated TCE and IOMMU TCE objects use a fundamentally different API and infrastructure. So my stuff is not going to upstream again. Heh. Ok. I'll implement it. Thanks! Should I keep KVM_CAP_SPAPR_MULTITCE capability patch or can I drop it for now? Please keep it, it is unrelated to the IOMMU-VFIO thing. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pseries: Move lparcfg.c to platforms/pseries
This file is entirely pseries specific nowadays, so move it out
of arch/powerpc/kernel where it doesn't belong anymore.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/Makefile | 1 -
arch/powerpc/kernel/lparcfg.c| 710 ---
arch/powerpc/platforms/pseries/Makefile | 1 +
arch/powerpc/platforms/pseries/lparcfg.c | 710 +++
4 files changed, 711 insertions(+), 711 deletions(-)
delete mode 100644 arch/powerpc/kernel/lparcfg.c
create mode 100644 arch/powerpc/platforms/pseries/lparcfg.c
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 5b280f5..445cb6e 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_PPC_RTAS)+= rtas.o rtas-rtc.o
$(rtaspci-y-y)
obj-$(CONFIG_PPC_RTAS_DAEMON) += rtasd.o
obj-$(CONFIG_RTAS_FLASH) += rtas_flash.o
obj-$(CONFIG_RTAS_PROC)+= rtas-proc.o
-obj-$(CONFIG_LPARCFG) += lparcfg.o
obj-$(CONFIG_IBMVIO) += vio.o
obj-$(CONFIG_IBMEBUS) += ibmebus.o
obj-$(CONFIG_EEH) += eeh.o eeh_pe.o eeh_dev.o eeh_cache.o \
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
deleted file mode 100644
index e738007..000
--- a/arch/powerpc/kernel/lparcfg.c
+++ /dev/null
@@ -1,710 +0,0 @@
-/*
- * PowerPC64 LPAR Configuration Information Driver
- *
- * Dave Engebretsen engeb...@us.ibm.com
- *Copyright (c) 2003 Dave Engebretsen
- * Will Schmidt wills...@us.ibm.com
- *SPLPAR updates, Copyright (c) 2003 Will Schmidt IBM Corporation.
- *seq_file updates, Copyright (c) 2004 Will Schmidt IBM Corporation.
- * Nathan Lynch nath...@austin.ibm.com
- *Added lparcfg_write, Copyright (C) 2004 Nathan Lynch IBM Corporation.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- *
- * This driver creates a proc file at /proc/ppc64/lparcfg which contains
- * keyword - value pairs that specify the configuration of the partition.
- */
-
-#include linux/module.h
-#include linux/types.h
-#include linux/errno.h
-#include linux/proc_fs.h
-#include linux/init.h
-#include linux/seq_file.h
-#include linux/slab.h
-#include asm/uaccess.h
-#include asm/lppaca.h
-#include asm/hvcall.h
-#include asm/firmware.h
-#include asm/rtas.h
-#include asm/time.h
-#include asm/prom.h
-#include asm/vdso_datapage.h
-#include asm/vio.h
-#include asm/mmu.h
-#include asm/machdep.h
-
-
-/*
- * This isn't a module but we expose that to userspace
- * via /proc so leave the definitions here
- */
-#define MODULE_VERS 1.9
-#define MODULE_NAME lparcfg
-
-/* #define LPARCFG_DEBUG */
-
-/*
- * Track sum of all purrs across all processors. This is used to further
- * calculate usage values by different applications
- */
-static unsigned long get_purr(void)
-{
- unsigned long sum_purr = 0;
- int cpu;
-
- for_each_possible_cpu(cpu) {
- struct cpu_usage *cu;
-
- cu = per_cpu(cpu_usage_array, cpu);
- sum_purr += cu-current_tb;
- }
- return sum_purr;
-}
-
-/*
- * Methods used to fetch LPAR data when running on a pSeries platform.
- */
-
-struct hvcall_ppp_data {
- u64 entitlement;
- u64 unallocated_entitlement;
- u16 group_num;
- u16 pool_num;
- u8 capped;
- u8 weight;
- u8 unallocated_weight;
- u16 active_procs_in_pool;
- u16 active_system_procs;
- u16 phys_platform_procs;
- u32 max_proc_cap_avail;
- u32 entitled_proc_cap_avail;
-};
-
-/*
- * H_GET_PPP hcall returns info in 4 parms.
- * entitled_capacity,unallocated_capacity,
- * aggregation, resource_capability).
- *
- * R4 = Entitled Processor Capacity Percentage.
- * R5 = Unallocated Processor Capacity Percentage.
- * R6 (AABBCCDDEEFFGGHH).
- * - reserved (0)
- * - reserved (0)
- * - Group Number
- * - Pool Number.
- * R7 (IIJJKKLLMMNNOOPP).
- * XX - reserved. (0)
- *XX - bit 0-6 reserved (0). bit 7 is Capped indicator.
- * XX - variable processor Capacity Weight
- *XX - Unallocated Variable Processor Capacity Weight.
- * - Active processors in Physical Processor Pool.
- * - Processors active on platform.
- * R8 (RRSS). if ibm,partition-performance-parameters-level = 1
- * - Physical platform procs allocated to virtualization.
- * XX - Max procs capacity % available to the partitions pool.
- * XX - Entitled procs capacity % available to the
- *partitions
[PATCH v12] ASoC: fsl: Add S/PDIF machine driver
This patch implements a device-tree-only machine driver for Freescale
i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
fsl_spdif.c drivers.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
Changelog
v11-v12:
* Dropped unused spdif_pdev.
* Register spdif-dit/dir depending on DT bool property.
v10-v11:
* Use boolean properties for spdif-out/in switch instead of codec phandles.
* Accordingly create dummy codec driver in probe() instead of DT nodes.
.../devicetree/bindings/sound/imx-audio-spdif.txt | 34 +
sound/soc/fsl/Kconfig | 11 ++
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/imx-spdif.c | 148
4 files changed, 195 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
create mode 100644 sound/soc/fsl/imx-spdif.c
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
new file mode 100644
index 000..7d13479
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
@@ -0,0 +1,34 @@
+Freescale i.MX audio complex with S/PDIF transceiver
+
+Required properties:
+
+ - compatible : fsl,imx-audio-spdif
+
+ - model : The user-visible name of this sound complex
+
+ - spdif-controller : The phandle of the i.MX S/PDIF controller
+
+
+Optional properties:
+
+ - spdif-out : This is a boolean property. If present, the transmitting
+function of S/PDIF will be enabled, indicating there's a physical
+S/PDIF out connector/jack on the board or it's connecting to some
+other IP block, such as an HDMI encoder/display-controller.
+
+ - spdif-in : This is a boolean property. If present, the receiving
+function of S/PDIF will be enabled, indicating there's a physical
+S/PDIF in connector/jack on the board.
+
+* Note: At least one of these two properties should be set in the DT binding.
+
+
+Example:
+
+sound-spdif {
+ compatible = fsl,imx-audio-spdif;
+ model = imx-spdif;
+ spdif-controller = spdif;
+ spdif-out;
+ spdif-in;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index cd088cc..a708380 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -193,6 +193,17 @@ config SND_SOC_IMX_SGTL5000
Say Y if you want to add support for SoC audio on an i.MX board with
a sgtl5000 codec.
+config SND_SOC_IMX_SPDIF
+ tristate SoC Audio support for i.MX boards with S/PDIF
+ select SND_SOC_IMX_PCM_DMA
+ select SND_SOC_FSL_SPDIF
+ select SND_SOC_FSL_UTILS
+ select SND_SOC_SPDIF
+ help
+ SoC Audio support for i.MX boards with S/PDIF
+ Say Y if you want to add support for SoC audio on an i.MX board with
+ a S/DPDIF.
+
config SND_SOC_IMX_MC13783
tristate SoC Audio support for I.MX boards with mc13783
depends on MFD_MC13783 ARM
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 4b5970e..e2aaff7 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -45,6 +45,7 @@ snd-soc-mx27vis-aic32x4-objs := mx27vis-aic32x4.o
snd-soc-wm1133-ev1-objs := wm1133-ev1.o
snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
snd-soc-imx-wm8962-objs := imx-wm8962.o
+snd-soc-imx-spdif-objs :=imx-spdif.o
snd-soc-imx-mc13783-objs := imx-mc13783.o
obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
@@ -53,4 +54,5 @@ obj-$(CONFIG_SND_SOC_MX27VIS_AIC32X4) +=
snd-soc-mx27vis-aic32x4.o
obj-$(CONFIG_SND_MXC_SOC_WM1133_EV1) += snd-soc-wm1133-ev1.o
obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
obj-$(CONFIG_SND_SOC_IMX_WM8962) += snd-soc-imx-wm8962.o
+obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
obj-$(CONFIG_SND_SOC_IMX_MC13783) += snd-soc-imx-mc13783.o
diff --git a/sound/soc/fsl/imx-spdif.c b/sound/soc/fsl/imx-spdif.c
new file mode 100644
index 000..816013b
--- /dev/null
+++ b/sound/soc/fsl/imx-spdif.c
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/module.h
+#include linux/of_platform.h
+#include sound/soc.h
+
+struct imx_spdif_data {
+ struct snd_soc_dai_link dai[2];
+ struct snd_soc_card card;
+ struct platform_device *txdev;
+ struct platform_device *rxdev;
+};
+
+static int imx_spdif_audio_probe(struct platform_device *pdev)
+{
+ struct device_node *spdif_np, *np = pdev-dev.of_node;
+ struct imx_spdif_data *data;
+ int ret = 0, num_links = 0;
+
+ spdif_np = of_parse_phandle(np, spdif-controller, 0);
+ if (!spdif_np) {
+
