Re: [PATCH 4/4] kvm: powerpc: set cache coherency only for RAM pages
On Fri, 2013-07-26 at 11:16 +0530, Bharat Bhushan wrote:
If the page is RAM then map this as cacheable and coherent (set M bit)
otherwise this page is treated as I/O and map this as cache inhibited
and guarded (set I + G)
This helps setting proper MMU mapping for direct assigned device.
NOTE: There can be devices that require cacheable mapping, which is not yet
supported.
Why don't you do like server instead and enforce the use of the same I
and M bits as the corresponding qemu PTE ?
Cheers,
Ben.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/kvm/e500_mmu_host.c | 24 +++-
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/e500_mmu_host.c
b/arch/powerpc/kvm/e500_mmu_host.c
index 1c6a9d7..5cbdc8f 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -64,13 +64,27 @@ static inline u32 e500_shadow_mas3_attrib(u32 mas3, int
usermode)
return mas3;
}
-static inline u32 e500_shadow_mas2_attrib(u32 mas2, int usermode)
+static inline u32 e500_shadow_mas2_attrib(u32 mas2, pfn_t pfn)
{
+ u32 mas2_attr;
+
+ mas2_attr = mas2 MAS2_ATTRIB_MASK;
+
+ if (kvm_is_mmio_pfn(pfn)) {
+ /*
+ * If page is not RAM then it is treated as I/O page.
+ * Map it with cache inhibited and guarded (set I + G).
+ */
+ mas2_attr |= MAS2_I | MAS2_G;
+ return mas2_attr;
+ }
+
+ /* Map RAM pages as cacheable (Not setting I in MAS2) */
#ifdef CONFIG_SMP
- return (mas2 MAS2_ATTRIB_MASK) | MAS2_M;
-#else
- return mas2 MAS2_ATTRIB_MASK;
+ /* Also map as coherent (set M) in SMP */
+ mas2_attr |= MAS2_M;
#endif
+ return mas2_attr;
}
/*
@@ -313,7 +327,7 @@ static void kvmppc_e500_setup_stlbe(
/* Force IPROT=0 for all guest mappings. */
stlbe-mas1 = MAS1_TSIZE(tsize) | get_tlb_sts(gtlbe) | MAS1_VALID;
stlbe-mas2 = (gvaddr MAS2_EPN) |
- e500_shadow_mas2_attrib(gtlbe-mas2, pr);
+ e500_shadow_mas2_attrib(gtlbe-mas2, pfn);
stlbe-mas7_3 = ((u64)pfn PAGE_SHIFT) |
e500_shadow_mas3_attrib(gtlbe-mas7_3, pr);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvm: powerpc: set cache coherency only for RAM pages
On 26.07.2013, at 10:26, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-26 at 11:16 +0530, Bharat Bhushan wrote:
If the page is RAM then map this as cacheable and coherent (set M bit)
otherwise this page is treated as I/O and map this as cache inhibited
and guarded (set I + G)
This helps setting proper MMU mapping for direct assigned device.
NOTE: There can be devices that require cacheable mapping, which is not yet
supported.
Why don't you do like server instead and enforce the use of the same I
and M bits as the corresponding qemu PTE ?
Specifically, Ben is talking about this code:
/* Translate to host virtual address */
hva = __gfn_to_hva_memslot(memslot, gfn);
/* Look up the Linux PTE for the backing page */
pte_size = psize;
pte = lookup_linux_pte(pgdir, hva, writing, pte_size);
if (pte_present(pte)) {
if (writing !pte_write(pte))
/* make the actual HPTE be read-only */
ptel = hpte_make_readonly(ptel);
is_io = hpte_cache_bits(pte_val(pte));
pa = pte_pfn(pte) PAGE_SHIFT;
}
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4] kvm: powerpc: set cache coherency only for RAM pages
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, July 26, 2013 1:57 PM
To: Bhushan Bharat-R65777
Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org;
ag...@suse.de; Wood Scott-B07421; Bhushan Bharat-R65777
Subject: Re: [PATCH 4/4] kvm: powerpc: set cache coherency only for RAM pages
On Fri, 2013-07-26 at 11:16 +0530, Bharat Bhushan wrote:
If the page is RAM then map this as cacheable and coherent (set M
bit) otherwise this page is treated as I/O and map this as cache
inhibited and guarded (set I + G)
This helps setting proper MMU mapping for direct assigned device.
NOTE: There can be devices that require cacheable mapping, which is not yet
supported.
Why don't you do like server instead and enforce the use of the same I and M
bits as the corresponding qemu PTE ?
Ben/Alex, I will look into the code. Can you please describe how this is
handled on server?
Thanks
-Bharat
Cheers,
Ben.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/kvm/e500_mmu_host.c | 24 +++-
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/e500_mmu_host.c
b/arch/powerpc/kvm/e500_mmu_host.c
index 1c6a9d7..5cbdc8f 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -64,13 +64,27 @@ static inline u32 e500_shadow_mas3_attrib(u32 mas3, int
usermode)
return mas3;
}
-static inline u32 e500_shadow_mas2_attrib(u32 mas2, int usermode)
+static inline u32 e500_shadow_mas2_attrib(u32 mas2, pfn_t pfn)
{
+ u32 mas2_attr;
+
+ mas2_attr = mas2 MAS2_ATTRIB_MASK;
+
+ if (kvm_is_mmio_pfn(pfn)) {
+ /*
+* If page is not RAM then it is treated as I/O page.
+* Map it with cache inhibited and guarded (set I + G).
+*/
+ mas2_attr |= MAS2_I | MAS2_G;
+ return mas2_attr;
+ }
+
+ /* Map RAM pages as cacheable (Not setting I in MAS2) */
#ifdef CONFIG_SMP
- return (mas2 MAS2_ATTRIB_MASK) | MAS2_M;
-#else
- return mas2 MAS2_ATTRIB_MASK;
+ /* Also map as coherent (set M) in SMP */
+ mas2_attr |= MAS2_M;
#endif
+ return mas2_attr;
}
/*
@@ -313,7 +327,7 @@ static void kvmppc_e500_setup_stlbe(
/* Force IPROT=0 for all guest mappings. */
stlbe-mas1 = MAS1_TSIZE(tsize) | get_tlb_sts(gtlbe) | MAS1_VALID;
stlbe-mas2 = (gvaddr MAS2_EPN) |
- e500_shadow_mas2_attrib(gtlbe-mas2, pr);
+ e500_shadow_mas2_attrib(gtlbe-mas2, pfn);
stlbe-mas7_3 = ((u64)pfn PAGE_SHIFT) |
e500_shadow_mas3_attrib(gtlbe-mas7_3, pr);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4] kvm: powerpc: set cache coherency only for RAM pages
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
Behalf Of Alexander Graf
Sent: Friday, July 26, 2013 2:20 PM
To: Benjamin Herrenschmidt
Cc: Bhushan Bharat-R65777; kvm-...@vger.kernel.org; k...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Bhushan Bharat-R65777
Subject: Re: [PATCH 4/4] kvm: powerpc: set cache coherency only for RAM pages
On 26.07.2013, at 10:26, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-26 at 11:16 +0530, Bharat Bhushan wrote:
If the page is RAM then map this as cacheable and coherent (set M
bit) otherwise this page is treated as I/O and map this as cache
inhibited and guarded (set I + G)
This helps setting proper MMU mapping for direct assigned device.
NOTE: There can be devices that require cacheable mapping, which is not yet
supported.
Why don't you do like server instead and enforce the use of the same I
and M bits as the corresponding qemu PTE ?
Specifically, Ben is talking about this code:
/* Translate to host virtual address */
hva = __gfn_to_hva_memslot(memslot, gfn);
/* Look up the Linux PTE for the backing page */
pte_size = psize;
pte = lookup_linux_pte(pgdir, hva, writing, pte_size);
if (pte_present(pte)) {
if (writing !pte_write(pte))
/* make the actual HPTE be read-only */
ptel = hpte_make_readonly(ptel);
is_io = hpte_cache_bits(pte_val(pte));
pa = pte_pfn(pte) PAGE_SHIFT;
}
Ok
Thanks
-Bharat
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body
of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states
-Original Message- From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm- ow...@vger.kernel.org] On Behalf Of Preeti U Murthy Sent: Thursday, July 25, 2013 5:03 PM To: b...@kernel.crashing.org; paul.gortma...@windriver.com; pau...@samba.org; sha...@linux.vnet.ibm.com; ga...@kernel.crashing.org; fweis...@gmail.com; paul...@linux.vnet.ibm.com; mich...@ellerman.id.au; a...@arndb.de; linux...@vger.kernel.org; rost...@goodmis.org; r...@sisk.pl; john.stu...@linaro.org; t...@linutronix.de; Zhao Chenhui-B35336; deep...@linux.vnet.ibm.com; ge...@infradead.org; linux- ker...@vger.kernel.org; srivatsa.b...@linux.vnet.ibm.com; schwidef...@de.ibm.com; sva...@linux.vnet.ibm.com; linuxppc- d...@lists.ozlabs.org Subject: [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states On PowerPC, when CPUs enter deep idle states, their local timers are switched off. The responsibility of waking them up at their next timer event, needs to be handed over to an external device. On PowerPC, we do not have an external device equivalent to HPET, which is currently done on architectures like x86. Instead we assign the local timer of one of the CPUs to do this job. I don't know much about the deep idle states. But is it necessary to turn off the timer in these states? I mean the extra work needed on the booting CPU and re-syncing Time Base after wakeup might defeat the power consumption benefit of turning off the timer. Btw, the Open PIC has an internal timer. Can we use it as the wakeup event? Regards, Leo This patchset is an attempt to make use of the existing timer broadcast framework in the kernel to meet the above requirement, except that the tick broadcast device is the local timer of the boot CPU. This patch series is ported ontop of 3.11-rc1 + the cpuidle driver backend for powernv posted by Deepthi Dharwar recently. The current design and implementation supports the ONESHOT tick mode. It does not yet support the PERIODIC tick mode. This patch is tested with NOHZ_FULL off. Patch[1/5], Patch[2/5]: optimize the broadcast mechanism on ppc. Patch[3/5]: Introduces the core of the timer offload framework on powerpc. Patch[4/5]: The cpu doing the broadcast should not go into tickless idle. Patch[5/5]: Add a deep idle state to the cpuidle state table on powernv. Patch[5/5] is the patch that ultimately makes use of the timer offload framework that the patches Patch[1/5] to Patch[4/5] build. --- Preeti U Murthy (3): cpuidle/ppc: Add timer offload framework to support deep idle states cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints cpuidle/ppc: Add longnap state to the idle states on powernv Srivatsa S. Bhat (2): powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC) powerpc: Implement broadcast timer interrupt as an IPI message arch/powerpc/include/asm/smp.h |3 + arch/powerpc/include/asm/time.h |3 + arch/powerpc/kernel/smp.c | 23 -- arch/powerpc/kernel/time.c | 84 +++ arch/powerpc/platforms/cell/interrupt.c |2 - arch/powerpc/platforms/powernv/Kconfig |1 arch/powerpc/platforms/powernv/processor_idle.c | 48 + arch/powerpc/platforms/ps3/smp.c|2 - kernel/time/tick-sched.c|7 ++ 9 files changed, 161 insertions(+), 12 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v6 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: Hongbo Zhang hongbo.zh...@freescale.com Hi Vinod, Dan, Scott and Leo, please have a look at these V6 patches. Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. 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| 118 +++- 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, 268 insertions(+), 40 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 v6 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 ed703d9..c9f81b9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -130,6 +130,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 mapping 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 mapping for channel
+- interrupts: interrupt mapping 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 of
[PATCH v6 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| 52 +--- 1 file changed, 24 insertions(+), 28 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bc..ed703d9 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -1,33 +1,31 @@ -* 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 +- compatible: must include fsl,elo-dma, and a fsl,CHIP-dma is + optional, where CHIP is the processor name. - reg : registers mapping for DMA general status reg -- 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. - cell-index: controller index. 0 for controller @ 0x8100 - interrupts: interrupt mapping 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. +- compatible: must include fsl,elo-dma-channel, and a + fsl,CHIP-dma-channel is optional, where CHIP is + the processor name, However, see note below. - reg : registers mapping 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) + (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,27 +68,25 @@ 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 +- compatible: must include fsl,eloplus-dma, and a fsl,CHIP-dma is + optional, where CHIP is the processor name. - reg : registers mapping 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, and a + fsl,CHIP-dma-channel is optional, where CHIP is + the processor name, However, see note below. - cell-index: dma channel index starts at 0. - reg
[PATCH v6 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: [PATCH 5/7] rapidio: add modular build option for the subsystem core
Hi Alexandre, Le Friday 28 June 2013 à 15:18 -0400, Alexandre Bounine a écrit : Add a configuration option to build RapidIO subsystem core code as a loadable kernel module. Currently this option is available only for x86-based platforms, with the additional patch for PowerPC planned to be provided later. This patch replaces kernel command line parameter riohdid= with its module-specific analog rapidio.hdid=. Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com Cc: Matt Porter mpor...@kernel.crashing.org Cc: Li Yang le...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org Cc: Andre van Herk andre.van.h...@prodrive.nl Cc: Micha Nelissen micha.nelis...@prodrive.nl Cc: Stef van Os stef.van...@prodrive.nl Cc: Jean Delvare jdelv...@suse.de --- arch/x86/Kconfig |4 ++-- drivers/rapidio/Makefile |4 +++- drivers/rapidio/rio.c| 27 ++- 3 files changed, 19 insertions(+), 16 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fe120da..583ac42 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2246,11 +2246,11 @@ source drivers/pcmcia/Kconfig source drivers/pci/hotplug/Kconfig config RAPIDIO - bool RapidIO support + tristate RapidIO support Is there a reason why this was only done for x86 and not for mips and powerpc? depends on PCI default n help - If you say Y here, the kernel will include drivers and + If enabled this option will include drivers and the core infrastructure code to support RapidIO interconnect devices. -- Jean Delvare Suse L3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Suggestion] powerpc: xmon: about 'longjmp' related warning.
On 07/26/2013 07:45 PM, Chen Gang wrote:
c0080d30: 00 00 04 ac .long 0x4ac
c0080d34: 60 00 00 00 nop
c0080d38: 60 00 00 00 nop
c0080d3c: 60 00 00 00 nop
816 case 'm':
817 cmd = inchar();
818 switch (cmd) {
819 case 'm':
820 case 's':
821 case 'd':
822 memops(cmd);
823 break;
824 case 'l':
825 memlocate();
826 break;
827 case 'z':
828 memzcan();
829 break;
830 case 'i':
831 show_mem(0);
832 break;
833 default:
834 termch = cmd;
835 memex();
836 }
837 break;
c0080d40: 4b ff df b1 bl c007ecf0 .inchar
Oh, sorry again, the comments above is incorrect, please skip them (816
-- 837)
If want to see the related code directly, please search '680(r1)' (which
mean 'fromipi')
Thanks.
--
Chen Gang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/7] rapidio: add modular build option for the subsystem core
Hi Jean, -Original Message- From: Jean Delvare [mailto:jdelv...@suse.de] Sent: Friday, July 26, 2013 7:01 AM ... skip @@ -2246,11 +2246,11 @@ source drivers/pcmcia/Kconfig source drivers/pci/hotplug/Kconfig config RAPIDIO - bool RapidIO support + tristate RapidIO support Is there a reason why this was only done for x86 and not for mips and powerpc? I need to make a configuration patch for MIPS and PowerPC platforms that deals with built-in RapidIO controllers available in some embedded SoCs. For generic platforms with PCIe controllers 'tristate' changes similar to x86 are good enough. I think it was mentioned in PATCH 0/7 that we will have a follow-up patch a bit later. depends on PCI default n help - If you say Y here, the kernel will include drivers and + If enabled this option will include drivers and the core infrastructure code to support RapidIO interconnect devices. -- Jean Delvare Suse L3 Alex. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] PCI: hotplug: Convert to be builtin only, not modular
On Thu, Jul 25, 2013 at 10:57 AM, Bjorn Helgaas bhelg...@google.com wrote: Convert CONFIG_HOTPLUG_PCI from tristate to bool. This only affects the hotplug core; several of the hotplug drivers can still be modules. Signed-off-by: Bjorn Helgaas bhelg...@google.com --- arch/ia64/configs/generic_defconfig|2 +- arch/ia64/configs/gensparse_defconfig |2 +- arch/ia64/configs/tiger_defconfig |2 +- arch/ia64/configs/xen_domu_defconfig |2 +- arch/powerpc/configs/ppc64_defconfig |2 +- arch/powerpc/configs/ppc64e_defconfig |2 +- arch/powerpc/configs/pseries_defconfig |2 +- arch/sh/configs/sh03_defconfig |2 +- drivers/pci/hotplug/Kconfig|5 + 9 files changed, 9 insertions(+), 12 deletions(-) Acked-by: Yinghai Lu ying...@kernel.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] PCI: pciehp: Convert pciehp to be builtin only, not modular
On Thu, Jul 25, 2013 at 10:57 AM, Bjorn Helgaas bhelg...@google.com wrote: Convert pciehp to be builtin only, with no module option. Signed-off-by: Bjorn Helgaas bhelg...@google.com Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com --- drivers/pci/pcie/Kconfig |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig index 569f82f..3b94cfc 100644 --- a/drivers/pci/pcie/Kconfig +++ b/drivers/pci/pcie/Kconfig @@ -14,15 +14,12 @@ config PCIEPORTBUS # Include service Kconfig here # config HOTPLUG_PCI_PCIE - tristate PCI Express Hotplug driver + bool PCI Express Hotplug driver depends on HOTPLUG_PCI PCIEPORTBUS help Say Y here if you have a motherboard that supports PCI Express Native Hotplug - To compile this driver as a module, choose M here: the - module will be called pciehp. - When in doubt, say N. source drivers/pci/pcie/aer/Kconfig Acked-by: Yinghai Lu ying...@kernel.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
On Fri, Jul 26, 2013 at 11:19:13AM +1000, Anton Blanchard wrote: Hi Neil, Sorry I'm a bit late to the thread, I've ben swamped. Has someone tested this with kexec/kdump? Thats why the origional patch was created, because when kexec loads the kernel at a different physical address, the relocations messed with the module crc's, and modules couldn't load during the kexec boot. Assuming that kernaddr_start gets set appropriately during boot, using PHYSICAL_START should be fine, but I wanted to check, and don't currently have access to a powerpc system to do so. Neil I tested a relocatable kernel forced to run at a non zero physical address (ie basically kdump). I verified CRCs were bad with your original patch backed out, and were good with this patch applied. Anton Perfect, sounds like a sufficient test to me. Acked-by: Neil Horman nhor...@tuxdriver.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states
Hi Li, On 07/26/2013 03:35 PM, Li Yang-R58472 wrote: -Original Message- From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm- ow...@vger.kernel.org] On Behalf Of Preeti U Murthy Sent: Thursday, July 25, 2013 5:03 PM To: b...@kernel.crashing.org; paul.gortma...@windriver.com; pau...@samba.org; sha...@linux.vnet.ibm.com; ga...@kernel.crashing.org; fweis...@gmail.com; paul...@linux.vnet.ibm.com; mich...@ellerman.id.au; a...@arndb.de; linux...@vger.kernel.org; rost...@goodmis.org; r...@sisk.pl; john.stu...@linaro.org; t...@linutronix.de; Zhao Chenhui-B35336; deep...@linux.vnet.ibm.com; ge...@infradead.org; linux- ker...@vger.kernel.org; srivatsa.b...@linux.vnet.ibm.com; schwidef...@de.ibm.com; sva...@linux.vnet.ibm.com; linuxppc- d...@lists.ozlabs.org Subject: [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states On PowerPC, when CPUs enter deep idle states, their local timers are switched off. The responsibility of waking them up at their next timer event, needs to be handed over to an external device. On PowerPC, we do not have an external device equivalent to HPET, which is currently done on architectures like x86. Instead we assign the local timer of one of the CPUs to do this job. I don't know much about the deep idle states. But is it necessary to turn off the timer in these states? I mean the extra work needed on the booting CPU and re-syncing Time Base after wakeup might defeat the power consumption benefit of turning off the timer. The idle state that CPUs should enter into is chosen by the cpuidle governor. And the target residency and the wakeup latency of the idle states among others, are the factors considered by the governor before choosing an idle state for a CPU. So deep idle states which have a higher target residency and wakeup latency, but that have huge power savings, are usually targeted by the governors when there are large periods of idle, i.e. CPUs tend to remain idle for long. Depending on the workload running, large periods of idle could be rare, in which case deep idle states are not even entered into. But if the workload is such that it is woken up occasionally to do work, with large periods of idle in between, deep idle states are targeted. In such a scenario, the power savings that such idle states yield is significant to offset the overhead of the factors that you mention, which will need to be done occasionally. Hence for an almost completely idle system, having such deep idle states fetches enormous power savings. Btw, the Open PIC has an internal timer. Can we use it as the wakeup event? I am not aware of such a device on PowerPC. Even if there is one, it is important to investigate what happens to it in deep idle states. If it is intended to be switched off in one of the deep idle states, again the idea that this patchset brings in has to be the fall-back solution. My point is, it is good to have the timer offload framework implementation because we cannot continue to rely on external devices being there to aid us in situations when the local timer devices of CPUs have to be turned off in deep idle states. Regards, Leo Regards Preeti U Murthy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4] kvm: powerpc: set cache coherency only for RAM pages
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
Behalf Of Alexander Graf
Sent: Friday, July 26, 2013 2:20 PM
To: Benjamin Herrenschmidt
Cc: Bhushan Bharat-R65777; kvm-...@vger.kernel.org; k...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Bhushan Bharat-R65777
Subject: Re: [PATCH 4/4] kvm: powerpc: set cache coherency only for RAM pages
On 26.07.2013, at 10:26, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-26 at 11:16 +0530, Bharat Bhushan wrote:
If the page is RAM then map this as cacheable and coherent (set M
bit) otherwise this page is treated as I/O and map this as cache
inhibited and guarded (set I + G)
This helps setting proper MMU mapping for direct assigned device.
NOTE: There can be devices that require cacheable mapping, which is not yet
supported.
Why don't you do like server instead and enforce the use of the same I
and M bits as the corresponding qemu PTE ?
Specifically, Ben is talking about this code:
/* Translate to host virtual address */
hva = __gfn_to_hva_memslot(memslot, gfn);
/* Look up the Linux PTE for the backing page */
pte_size = psize;
pte = lookup_linux_pte(pgdir, hva, writing, pte_size);
if (pte_present(pte)) {
if (writing !pte_write(pte))
/* make the actual HPTE be read-only */
ptel = hpte_make_readonly(ptel);
is_io = hpte_cache_bits(pte_val(pte));
pa = pte_pfn(pte) PAGE_SHIFT;
}
Will not searching the Linux PTE is a overkill?
=Bharat
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Update compilation flags with core specific options
On Jul 25, 2013, at 6:54 AM, Catalin Udma wrote: If CONFIG_E500 is enabled, the compilation flags are updated specifying the target core -mcpu=e5500/e500mc/8540 Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500 The assembler option is redundant if the -mcpu= flag is set. The patch fixes the kernel compilation problem for e5500/e6500 when using gcc option -mcpu=e5500/e6500. Signed-off-by: Catalin Udma catalin.u...@freescale.com --- changes for v2: - update also KBUILD_AFLAGS with -mcpu and -msoft-float flags arch/powerpc/Makefile | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) Is the assembler redundant for older toolchains? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Convert platforms to smp_generic_cpu_bootable
On Jul 25, 2013, at 5:02 PM, Andy Fleming wrote: T4, Cell, powernv, and pseries had the same implementation, so switch them to use a generic version. A2 apparently had a version, but removed it at some point, so we remove the declaration, too. Signed-off-by: Andy Fleming aflem...@freescale.com Conflicts: arch/powerpc/platforms/cell/smp.c arch/powerpc/platforms/powernv/smp.c arch/powerpc/platforms/pseries/smp.c Change-Id: If12e2f83f7187ee5982dca9f89c68e0600f0cc49 clean this up for sending upstream. - k --- arch/powerpc/platforms/85xx/smp.c|1 + arch/powerpc/platforms/cell/smp.c| 15 +-- arch/powerpc/platforms/powernv/smp.c | 18 +- arch/powerpc/platforms/pseries/smp.c | 18 +- arch/powerpc/platforms/wsp/wsp.h |1 - 5 files changed, 4 insertions(+), 49 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
On Mon, Jul 22, 2013 at 09:41:34PM -0500, Scott Wood wrote:
[...]
+static void esdhc_get_voltage(struct sdhci_host *host,
+struct platform_device *pdev)
+{
+}
Don't duplicate this code. Move it somewhere common and share it.
[Haijun Wrote:] So, move it drivers/mmc/host/sdhci-pltfm.c and
share it as
Sdhc_get_voltage()?
I'll let the MMC maintainer say what the appropriate place would
be... Don't capitalize the function name, though. :-)
Somewhere in drivers/mmc/core/core.c, near mmc_vddrange_to_ocrmask() would
be most appropriate, IMO. #ifdef CONFIG_OF would be needed, though.
Thanks,
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 V2] mmc: esdhc: get voltage from dts file
On Thu, Jul 25, 2013 at 08:38:11AM +0800, Haijun Zhang wrote: Add voltage-range support in esdhc of T4, So we can choose to read voltages from dts file as one optional. If we can get a valid voltage-range from device node, we use this voltage as the final voltage support. Else we still read from capacity or from other provider. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com Signed-off-by: Anton Vorontsov cbouatmai...@gmail.com Development process nitpick... The code originated from me, but I did not sign off this patch... Per Documentation/SubmittingPatches: The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. The order of the sign-off lines also has a meaning. Putting my sign off below yours means that I was not only involved in the development of the patch but also somehow approved the patch (but I did not :). [..] +void sdhci_get_voltage(struct platform_device *pdev) You still duplicate the code... Per my previous email, this should probably go into mmc/core (with the function renamed to something more generic, of course.) Thanks, Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] powerpc/85xx: Add SEC6.0 device tree
On 07/25/2013 09:41:17 PM, Po Liu wrote:
+=
+Job Ring (JR) Node
+
+Child of the crypto node defines data processing interface to
SEC 6
+across the peripheral bus for purposes of processing
+cryptographic descriptors. The specified address
+range can be made visible to one (or more) cores.
+The interrupt defined for this node is controlled within
+the address range of this node.
+
+ - compatible
+ Usage: required
+ Value type: string
+ Definition: Must include fsl,sec-v6.0-job-ring, if it is
+ back compatible with old version, better add them all.
Please don't use colloquialisms such as [you'd] better do this in a
formal specification.
Just say 'Must include fsl,sec-v6.0-job-ring' and leave it at that,
like the other bindings do.
+===
+Full Example
+
+Since some chips may embeded with more than one SEC 6, we abstract
+all the same properties into one file qoriq-sec6.0-0.dtsi. Each chip
+want to binding the node could simply include it in its own device
+node tree. Below is full example in C293PCIE:
Replace this with:
Since some chips may contain more than one SEC, the dtsi contains only
the node contents, not the node itself. A chip using the SEC should
include the dtsi inside each SEC node. Example:
+In qoriq-sec6.0-0.dtsi:
+
+ compatible = fsl,sec-v6.0;
+ fsl,sec-era = 6;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ jr@1000 {
+ compatible = fsl,sec-v6.0-job-ring,
+fsl,sec-v5.2-job-ring,
+fsl,sec-v5.0-job-ring,
+fsl,sec-v4.4-job-ring,
+fsl,sec-v4.0-job-ring;
+ reg= 0x1000 0x1000;
+ };
+
+ jr@2000 {
+ compatible = fsl,sec-v6.0-job-ring,
+fsl,sec-v5.2-job-ring,
+fsl,sec-v5.0-job-ring,
+fsl,sec-v4.4-job-ring,
+fsl,sec-v4.0-job-ring;
+ reg= 0x2000 0x1000;
+ };
+
+In the C293 device tree, we add the include of public property:
+
+crypto@a {
+/include/ qoriq-sec6.0-0.dtsi
+ };
Whitespace
+
+ crypto@a {
+ reg = 0xa 0x2;
+ ranges = 0x0 0xa 0x2;
+
+ jr@1000{
+ interrupts = 49 2 0 0;
+ };
+ jr@2000{
+ interrupts = 50 2 0 0;
+ };
+ };
You could combine the above like this:
crypto@a {
reg = 0xa 0x2;
ranges = 0 0xa 0x2;
/include/ qoriq-sec6.0-0.dtsi
jr@1000 {
interrupts = 49 2 0 0;
};
jr@2000 {
interrupts = 50 2 0 0;
};
};
Why is it qoriq-sec6.0-0.dtsi and not qoriq-sec6.0-dtsi?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc/85xx: Add C293PCIE board support
On 07/25/2013 09:41:19 PM, Po Liu wrote:
+ partition@190 {
+ /* 7MB for User Area */
+ reg = 0x0190 0x0070;
+ label = NAND User area;
+ };
+
+ partition@200 {
+ /* 96MB for Root File System */
+ reg = 0x0200 0x0600;
+ label = NAND Root File System;
+ };
+
+ partition@800 {
+ /* 3968MB for Others */
+ reg = 0x0800 0xF800;
+ label = NAND Others;
+ };
Again, what is the difference between user area and others? I'm
not even sure why it needs to be separate from root file system, but
at least the root filesystem should be larger given the size of the
overall flash.
Also please use lowercase for hex.
+ };
+
+ cpld@2,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,c293pcie-cpld;
+ reg = 0x2 0x0 0x20;
+ };
Remove #address-cells/#size-cells
+ partition@58 {
+ /* 10.5MB for Compressed RFS Image */
+ reg = 0x0058 0x00a8;
+ label = SPI Flash Compressed RFSImage;
+ };
Space before Image. Why specifiy that it's compressed, versus some
other filesystem type?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages
On 07/25/2013 03:50:42 AM, Gleb Natapov wrote: Why ppc uses page_is_ram() for mmap? How should I know? But looking at the function it does it only as a fallback if ppc_md.phys_mem_access_prot() is not provided. Making access to MMIO noncached as a safe fallback makes sense. There's only one current implementation of ppc_md.phys_mem_access_prot(), which is pci_phys_mem_access_prot(), which also uses page_is_ram(). If page_is_ram() returns false then it checks for write-combining PCI. But yes, we would want to call ppc_md.phys_mem_access_prot() if present. Copying from the host PTE would be ideal if doesn't come with a noticeable performance impact compared to other methods, but one way or another we want to be sure we match. It is also make sense to allow noncached access to reserved ram sometimes. Perhaps, but that's not KVM's decision to make. You should get the same result as if you mmaped it -- because QEMU already did and we need to be consistent. Not to mention the large page kernel mapping that will have been done on e500... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
On 07/25/2013 07:54:53 AM, Kevin Hao wrote: The reason is that the ppc kernel assume that the BARs starting at 0 is unset and will reassign it later. There is a bug in the previous kernel, so the kernel maybe not work well for qemu in this case. But I think this has been fixed by the commit c5df457f (powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources). What ensures that the reassignment will not assign zero? I'm not doubting the result that it does, but I'm having a hard time seeing it in the code. Or are you saying that the resource assignment code will run twice, rather than just saying that we won't trust the firmware when we find zero? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SIGSTKSZ/MINSIGSTKSZ too small on 64bit
Alan Modra amo...@gmail.com wrote on 07/26/2013 12:05:28 AM: Alan Modra amo...@gmail.com 07/26/2013 12:05 AM To Anton Blanchard an...@samba.org, cc Michael Neuling mi...@neuling.org, Ryan Arnold/Rochester/ IBM@IBMUS, linuxppc-dev@lists.ozlabs.org Subject Re: SIGSTKSZ/MINSIGSTKSZ too small on 64bit On Fri, Jul 26, 2013 at 12:23:25PM +1000, Anton Blanchard wrote: Hi, Alan has been looking at a glibc test fail. His analysis shows SEGVs in signal handlers using sigaltstack, and that MINSIGSTKSZ and SIGSTKSZ are too small. We increased the size of rt_sigframe in commit 2b0a576d15e0 (powerpc: Add new transactional memory state to the signal context) but didn't bump either SIGSTKSZ and MINSIGSTKSZ. We need to do that in both the kernel and glibc, but I'm a bit worried we could have broken existing applications that use sigaltstack. Before VSX changes, struct rt_sigframe size was 1920 plus 128 for __SIGNAL_FRAMESIZE giving ppc64 exactly the default MINSIGSTKSZ of 2048. After VSX, ucontext increased by 256 bytes. Oops, we're over MINSIGSTKSZ. Add another ucontext for TM and rt_sigframe is now at 3872, giving actual MINSIGSTKSZ of 4000. The glibc testcase that I was looking at was tst-cancel21, which allocates 2*SIGSTKSZ (not because the test is trying to be conservative, but because the test actually has nested signal stack frames). We blew the allocation by 48 bytes when using current mainline gcc to compile glibc (le ppc64). The required stack depth in _dl_lookup_symbol_x from the top of the next signal frame was 10944 bytes. I guess you'd want to add 288 to that, implying an actual SIGSTKSZ of 11232. I think we want #define MINSIGSTKSZ 4096 #define SIGSTKSZ 16384 frame size r1 #0 0x295cdaec in _dl_lookup_symbol_x(memset) 190 #1 0x295d3c4c in _dl_fixup() b0 10003310160 #2 0x295dc818 in _dl_runtime_resolve() b0 10003310210 #3 0x1f59ea8c in uw_init_context_1() a30 100033102c0 #4 0x1f59f560 in libc:_Unwind_ForcedUnwind() c90 10003310cf0 #5 0x1ffb9538 in pt:_Unwind_ForcedUnwind()90 10003311980 #6 0x1ffb6418 in __pthread_unwind() 70 10003311a10 #7 0x1ffaaeb0 in sigcancel_handler() 70 10003311a80 #8 signal handler called 1ffe0448 tramp fa0 10003311af0 10003311b70 rt_sigframe 10003311c58 sigcontext.gp_regs 10003311dd8 sigcontext.fp_regs 10003311ee0 sigcontext.v_regs 10003311ef0 sigcontext.vmx 100033128d8 rt_sigframe.pinfo offset d68 10003312968 rt_sigframe.abigap 10003312a88 end + 8 alignment #9 0x1ffb6f9c in 80 10003312a90 #10 0x1ffb6f84 in10003312b10 #11 0x100020f4 in delete_temp_files() 80 10003312dc0 #12 0x10002198 in 10003313070 #13 signal handler called #14 0x1ffb6f9c in ?? () #15 0x1ffb6f84 in ?? () #16 0x10002274 in ?? () #17 0x10002430 in ?? () #18 0x10002644 in ?? () #19 0x10001a1c in ?? () #20 0x1fe17f0c in ?? () #21 0x1fe18134 in ?? () #22 0x in ?? () Adhemerval and I were just looking at the signal stack frames and I'd noticed the increase in size due to the addition of the HTM bits so this is great timing. I tried a sigstack.h patch that increased the values as you indicated and it cleaned up the failing tst-cancel21* testcases on POWER8. I didn't try it on POWER7 yet. Ryan S. Arnold___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/8] powerpc/fsl_booke: protect the access to MAS7 with MMU_FTR_BIG_PHYS
On 07/04/2013 07:54:07 AM, Kevin Hao wrote: diff --git a/arch/powerpc/kernel/fsl_booke_entry_mapping.S b/arch/powerpc/kernel/fsl_booke_entry_mapping.S index a92c79b..2201f84 100644 --- a/arch/powerpc/kernel/fsl_booke_entry_mapping.S +++ b/arch/powerpc/kernel/fsl_booke_entry_mapping.S @@ -88,9 +88,11 @@ skpinv: addi r6,r6,1 /* Increment */ 1: mflrr7 mfspr r8,SPRN_MAS3 -#ifdef CONFIG_PHYS_64BIT +BEGIN_MMU_FTR_SECTION mfspr r23,SPRN_MAS7 -#endif +MMU_FTR_SECTION_ELSE + li r23,0 +ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_BIG_PHYS) and r8,r6,r8 subfic r9,r6,-4096 and r9,r9,r7 diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index d10a7ca..a04a48d 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -82,7 +82,11 @@ _ENTRY(_start); and r19,r3,r18 /* r19 = page offset */ andcr31,r20,r18 /* r31 = page base */ or r31,r31,r19 /* r31 = devtree phys addr */ +BEGIN_MMU_FTR_SECTION mfspr r30,SPRN_MAS7 +MMU_FTR_SECTION_ELSE + li r30,0 +ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_BIG_PHYS) Code patching hasn't been done yet at this point. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/8] powerpc: enable the relocatable support for the fsl booke 32bit kernel
On 07/04/2013 07:54:09 AM, Kevin Hao wrote: This is based on the codes in the head_44x.S. Since we always align to 256M before mapping the PAGE_OFFSET for a relocatable kernel, we also change the init tlb map to 256M size. Signed-off-by: Kevin Hao haoke...@gmail.com --- v2: Move the code to set kernstart_addr and virt_phys_offset to a c function. So we can expand it easily later. Hi Scott, I still use the 256M align for the init tlb as in v1 for the following reasons: * This should be the most possible case in reality. There is no most possible case. It's either possible (and supported) or not. And having less than 256M is definitely possible. The 8540 reference board has 64M. AMP scenarios that start on a 64M-aligned but not 256M-aligned address are also something I've done. * This is just for very early booting code and should not be a big issue if the first tlb entry shrink to a less size later. We can probably get away with it most of the time is not a very good justification. What's wrong with the suggestion I made last time, of basing the size on the alignment of the address? + /* +* We have the runtime (virutal) address of our base. +* We calculate our shift of offset from a 256M page. +* We could map the 256M page we belong to at PAGE_OFFSET and +* get going from there. +*/ + lis r4,KERNELBASE@h + ori r4,r4,KERNELBASE@l + rlwinm r6,r25,0,0xfff /* r6 = PHYS_START % 256M */ + rlwinm r5,r4,0,0xfff /* r5 = KERNELBASE % 256M */ + subfr3,r5,r6/* r3 = r6 - r5 */ + add r3,r4,r3 /* Required Virutal Address */ s/Virutal/Virtual/ -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 4/8] powerpc/fsl_booke: set the tlb entry for the kernel address in AS1
On 07/04/2013 07:54:10 AM, Kevin Hao wrote: We use the tlb1 entries to map low mem to the kernel space. In the current code, it assumes that the first tlb entry would cover the kernel image. But this is not true for some special cases, such as when we run a relocatable kernel above the 256M or set CONFIG_KERNEL_START above 256M. So we choose to switch to address space 1 before setting these tlb entries. If you're doing this, then I see even less reason to use such a large boot TLB1 entry. Signed-off-by: Kevin Hao haoke...@gmail.com --- A new patch in v2. arch/powerpc/kernel/head_fsl_booke.S | 81 arch/powerpc/mm/fsl_booke_mmu.c | 2 + arch/powerpc/mm/mmu_decl.h | 2 + 3 files changed, 85 insertions(+) diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 134064d..0cbfe95 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -1172,6 +1172,87 @@ __secondary_hold_acknowledge: #endif /* + * Create a tbl entry s/tbl/tlb/ diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c index 5fe271c..8f60ef8 100644 --- a/arch/powerpc/mm/fsl_booke_mmu.c +++ b/arch/powerpc/mm/fsl_booke_mmu.c @@ -222,7 +222,9 @@ void __init adjust_total_lowmem(void) /* adjust lowmem size to __max_low_memory */ ram = min((phys_addr_t)__max_low_memory, (phys_addr_t)total_lowmem); + i = switch_to_as1(); __max_low_memory = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM); + restore_to_as0(i); Wouldn't it be simpler to just run out of AS1 from the end of fsl_booke_entry_mapping.S, similar to what U-Boot does? With ESEL being changed to something non-conflicting, of course. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
On 07/04/2013 07:54:13 AM, Kevin Hao wrote:
@@ -1222,6 +1266,9 @@ _GLOBAL(switch_to_as1)
/*
* Restore to the address space 0 and also invalidate the tlb entry
created
* by switch_to_as1.
+ * r3 - the tlb entry which should be invalidated
+ * r4 - __pa(PAGE_OFFSET in AS0) - pa(PAGE_OFFSET in AS1)
+ * r5 - device tree virtual address
*/
_GLOBAL(restore_to_as0)
mflrr0
@@ -1230,7 +1277,15 @@ _GLOBAL(restore_to_as0)
0: mflrr9
addir9,r9,1f - 0b
- mfmsr r7
+ /*
+ * We may map the PAGE_OFFSET in AS0 to a different physical
address,
+ * so we need calculate the right jump and device tree address
based
+* on the offset passed by r4.
+ */
Whitespace
+ subfr9,r4,r9
+ subfr5,r4,r5
+
+2: mfmsr r7
li r8,(MSR_IS | MSR_DS)
andcr7,r7,r8
@@ -1249,9 +1304,19 @@ _GLOBAL(restore_to_as0)
mtspr SPRN_MAS1,r9
tlbwe
isync
+
+ cmpwi r4,0
+ bne 3f
mtlrr0
blr
+ /*
+* The PAGE_OFFSET will map to a different physical address,
+* jump to _start to do another relocation again.
+ */
+3: mr r3,r5
+ bl _start
+
/*
* We put a few things here that have to be page-aligned. This stuff
* goes at the beginning of the data segment, which is page-aligned.
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c
b/arch/powerpc/mm/fsl_booke_mmu.c
index 8f60ef8..dd283fd 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -224,7 +224,7 @@ void __init adjust_total_lowmem(void)
i = switch_to_as1();
__max_low_memory = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM);
- restore_to_as0(i);
+ restore_to_as0(i, 0, 0);
The device tree virtual address is zero?
pr_info(Memory CAM mapping: );
for (i = 0; i tlbcam_index - 1; i++)
@@ -245,30 +245,56 @@ void setup_initial_memory_limit(phys_addr_t
first_memblock_base,
}
#ifdef CONFIG_RELOCATABLE
-notrace void __init relocate_init(phys_addr_t start)
+int __initdata is_second_reloc;
+notrace void __init relocate_init(u64 dt_ptr, phys_addr_t start)
{
unsigned long base = KERNELBASE;
- /*
-* Relocatable kernel support based on processing of dynamic
-* relocation entries.
-* Compute the virt_phys_offset :
-* virt_phys_offset = stext.run - kernstart_addr
-*
- * stext.run = (KERNELBASE ~0xfff) + (kernstart_addr
0xfff)
-* When we relocate, we have :
-*
-* (kernstart_addr 0xfff) = (stext.run 0xfff)
-*
-* hence:
-* virt_phys_offset = (KERNELBASE ~0xfff) -
-* (kernstart_addr ~0xfff)
-*
-*/
kernstart_addr = start;
- start = ~0xfff;
- base = ~0xfff;
- virt_phys_offset = base - start;
+ if (!is_second_reloc) {
Since it's at the end of a function and one side is much shorter than
the
other, please do:
if (is_second_reloc) {
virt_phys_offset = PAGE_OFFSET - memstart_addr;
return;
}
/* the rest of the code goes here without having to indent
everything */
Otherwise, please use positive logic for if/else constructs.
+ phys_addr_t size;
+
+ /*
+ * Relocatable kernel support based on processing of
dynamic
+ * relocation entries. Before we get the real
memstart_addr,
+* We will compute the virt_phys_offset like this:
+* virt_phys_offset = stext.run - kernstart_addr
+*
+* stext.run = (KERNELBASE ~0xfff) +
+ *(kernstart_addr
0xfff)
+* When we relocate, we have :
+*
+ * (kernstart_addr 0xfff) = (stext.run
0xfff)
+*
+* hence:
+* virt_phys_offset = (KERNELBASE ~0xfff) -
+ * (kernstart_addr
~0xfff)
+*
+*/
+ start = ~0xfff;
+ base = ~0xfff;
+ virt_phys_offset = base - start;
+ early_get_first_memblock_info(__va(dt_ptr), size);
+ /*
+ * We now get the memstart_addr, then we should check
if this
+ * address is the same as what the PAGE_OFFSET map to
now. If
+ * not we have to change the map of PAGE_OFFSET to
memstart_addr
+* and do a second relocation.
+*/
+ if (start != memstart_addr) {
+ unsigned long ram;
+ int n, offset = memstart_addr - start;
+
+ is_second_reloc = 1;
+ ram = size;
+ n = switch_to_as1();
+ map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM);
Do we really need this
Re: [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info
On 07/04/2013 07:54:12 AM, Kevin Hao wrote:
For a relocatable kernel since it can be loaded at any place, there
is no any relation between the kernel start addr and the
memstart_addr.
So we can't calculate the memstart_addr from kernel start addr. And
also we can't wait to do the relocation after we get the real
memstart_addr from device tree because it is so late. So introduce
a new function we can use to get the first memblock address and size
in a very early stage (before machine_init).
Signed-off-by: Kevin Hao haoke...@gmail.com
---
A new patch in v2.
arch/powerpc/kernel/prom.c | 24
include/linux/of_fdt.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index eb23ac9..9a69d2d 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -753,6 +753,30 @@ void __init early_init_devtree(void *params)
DBG( - early_init_devtree()\n);
}
+#ifdef CONFIG_RELOCATABLE
+/*
+ * This function run before early_init_devtree, so we have to init
+ * initial_boot_params. Since early_init_dt_scan_memory_ppc will be
+ * executed again in early_init_devtree, we have to reinitialize the
+ * memblock data before return.
+ */
+void __init early_get_first_memblock_info(void *params, phys_addr_t
*size)
+{
+ /* Setup flat device-tree pointer */
+ initial_boot_params = params;
+
+ /* Scan memory nodes and rebuild MEMBLOCKs */
+ of_scan_flat_dt(early_init_dt_scan_root, NULL);
+ of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
+
+ if (size)
+ *size = first_memblock_size;
+
+ /* Undo what early_init_dt_scan_memory_ppc does to memblock */
+ memblock_reinit();
+}
+#endif
Wouldn't it be simpler to set a flag so that
early_init_dt_add_memory_arch() doesn't mess with memblocks on the
first pass?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SIGSTKSZ/MINSIGSTKSZ too small on 64bit
On Fri, Jul 26, 2013 at 04:31:34PM -0500, Ryan Arnold wrote: Adhemerval and I were just looking at the signal stack frames and I'd noticed the increase in size due to the addition of the HTM bits so this is great timing. I tried a sigstack.h patch that increased the values as you indicated and it cleaned up the failing tst-cancel21* testcases on POWER8. I didn't try it on POWER7 yet. I've tested on power7 using a copy of sysdeps/unix/sysv/linux/sparc/bits/sigstack.h as sysdeps/unix/sysv/linux/powerpc/bits/sigstack.h -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch implements a back-end cpuidle driver for
powernv calling power7_nap and snooze idle states.
This can be extended by adding more idle states
in the future to the existing framework.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/Kconfig |9 +
arch/powerpc/platforms/powernv/Makefile |1
arch/powerpc/platforms/powernv/processor_idle.c | 239
+++
3 files changed, 249 insertions(+)
create mode 100644 arch/powerpc/platforms/powernv/processor_idle.c
diff --git a/arch/powerpc/platforms/powernv/Kconfig
b/arch/powerpc/platforms/powernv/Kconfig
index c24684c..ace2d22 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -20,3 +20,12 @@ config PPC_POWERNV_RTAS
default y
select PPC_ICS_RTAS
select PPC_RTAS
+
+config POWERNV_IDLE
+ bool CPUIdle driver for powernv platform
+ depends on CPU_IDLE
+ depends on PPC_POWERNV
+ default y
+ help
+ Select this option to enable processor idle state management
+ through cpuidle subsystem.
diff --git a/arch/powerpc/platforms/powernv/Makefile
b/arch/powerpc/platforms/powernv/Makefile
index 7fe5951..c0e44eb 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -4,3 +4,4 @@ obj-y += opal-rtc.o opal-nvram.o
obj-$(CONFIG_SMP)+= smp.o
obj-$(CONFIG_PCI)+= pci.o pci-p5ioc2.o pci-ioda.o
obj-$(CONFIG_EEH)+= eeh-ioda.o eeh-powernv.o
+obj-$(CONFIG_POWERNV_IDLE) += processor_idle.o
diff --git a/arch/powerpc/platforms/powernv/processor_idle.c
b/arch/powerpc/platforms/powernv/processor_idle.c
new file mode 100644
index 000..f43ad91a
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/processor_idle.c
@@ -0,0 +1,239 @@
+/*
+ * processor_idle - idle state cpuidle driver.
+ */
+
+#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/machdep.h
+#include asm/runlatch.h
+
+struct cpuidle_driver powernv_idle_driver = {
+ .name = powernv_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 *powernv_cpuidle_devices;
+static struct cpuidle_state *cpuidle_state_table;
+
+static int snooze_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int cpu = dev-cpu;
+
+ local_irq_enable();
+ set_thread_flag(TIF_POLLING_NRFLAG);
+
+ while ((!need_resched()) cpu_online(cpu)) {
+ ppc64_runlatch_off();
+ HMT_very_low();
+ }
Why are you using the cpu_online test here ?
+
+ HMT_medium();
+ clear_thread_flag(TIF_POLLING_NRFLAG);
+ smp_mb();
+ 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.
+ */
+static struct cpuidle_state powernv_states[MAX_IDLE_STATE_COUNT] = {
+ { /* 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 },
+};
+
+static int powernv_cpuidle_add_cpu_notifier(struct notifier_block *n,
+ unsigned long action, void *hcpu)
+{
+ int hotcpu = (unsigned long)hcpu;
+ struct cpuidle_device *dev =
+ per_cpu_ptr(powernv_cpuidle_devices, hotcpu);
+
+ if (dev cpuidle_get_driver()) {
+ switch (action) {
+ case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
+ cpuidle_pause_and_lock();
+ cpuidle_enable_device(dev);
+ cpuidle_resume_and_unlock();
+ break;
+
+ case CPU_DEAD:
+ case CPU_DEAD_FROZEN:
+ cpuidle_pause_and_lock();
+ cpuidle_disable_device(dev);
+ cpuidle_resume_and_unlock();
+ break;
+
+ default:
+ return NOTIFY_DONE;
+ }
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block
Re: [PATCH 2/3] cpuidle/powernv: Enable idle powernv cpu to call into the cpuidle framework.
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch enables idle powernv cpu to hook on to the cpuidle
framework, if available, else call on to default idle platform
code.
Why do you need to do that ?
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/setup.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 84438af..97d0951 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
@@ -196,6 +197,15 @@ static int __init pnv_probe(void)
return 1;
}
+void powernv_idle(void)
+{
+ /* Hook to cpuidle framework if available, else
+ * call on default platform idle code
+ */
+ if (cpuidle_idle_call())
+ power7_idle();
+}
+
define_machine(powernv) {
.name = PowerNV,
.probe = pnv_probe,
@@ -205,7 +215,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,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
