This enables POWER8 doorbells on powernv.
v2 changes:
Only clear LPCR_PECE1 in fastsleep_loop() leave all other bits untouched.
Add select PPC_DOORBELL for CONFIG PPC_POWERNV/PSERIES
Michael Neuling (2):
powerpc/cpuidle: Only clear LPCR decrementer wakeup bit on fast sleep entry
Currently when entering fastsleep we clear all LPCR PECE bits.
This patch changes it to only clear the decrementer bit (ie. PECE1), which is
the only bit we really need to clear here. This is needed if we want to set
other wakeup causes like the PECEDH bit so we can use hypervisor doorbells on
This patch enables POWER8 doorbell IPIs on powernv.
Since doorbells can only IPI within a core, we test to see when we can use
doorbells and if not we fall back to XICS. This also enables hypervisor
doorbells to wakeup us up from nap/sleep via the LPCR PECEDH bit.
Based on tests by Anton, the
This enables POWER8 doorbells on powernv.
v2 changes:
Only clear LPCR_PECE1 in fastsleep_loop() leave all other bits untouched.
Add select PPC_DOORBELL for CONFIG PPC_POWERNV/PSERIES
Michael Neuling (2):
powerpc/cpuidle: Only clear LPCR decrementer wakeup bit on fast sleep entry
Currently when entering fastsleep we clear all LPCR PECE bits.
This patch changes it to only clear the decrementer bit (ie. PECE1), which is
the only bit we really need to clear here. This is needed if we want to set
other wakeup causes like the PECEDH bit so we can use hypervisor doorbells on
This patch enables POWER8 doorbell IPIs on powernv.
Since doorbells can only IPI within a core, we test to see when we can use
doorbells and if not we fall back to XICS. This also enables hypervisor
doorbells to wakeup us up from nap/sleep via the LPCR PECEDH bit.
Based on tests by Anton, the
Hi all,
I recently build linux next kernel in IBM Power7 platform, use default
config file copy from /boot/config-3.6.10-4.fc18.ppc64p7
[root@cena01 linux-next]# uname -a
Linux cena01.austin.ibm.com 3.15.0-rc1+ #47 SMP Thu Apr 24 20:59:46 CDT
2014 ppc64 ppc64 ppc64 GNU/Linux
[root@cena01
On Mon, May 12, 2014 at 12:59:19PM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2014-05-08 at 14:30 +0800, Wei Yang wrote:
During the EEH hotplug event, pcibios_setup_device() will be invoked two
times. And the last time will trigger a warning of re-attachment of iommu
group.
The two times
Commit 432481220 (ASoC: fsl-ssi: Use regmap) removed struct ccsr_ssi.
Unfortunately, the structure is still used. This causes
mpc85xx_smp_defconfig and mpc85xx_defconfig builds to fail with
sound/soc/fsl/fsl_dma.c:926:50:
error: invalid use of undefined type 'struct ccsr_ssi'
dma-ssi_stx_phys
On Wed, 2014-06-11 at 15:12 +0800, Wei Yang wrote:
Sorry for the long delay. It took me some time to investigate and test the
code.
Currently, the hotplug by qemu monitor command line has been verified. Two pci
device on the same bus have been hotpluged one by one successfully.
Another
This patch implements vmemmap_list_free() for vmemmap_free().
The freed entries will be removed from vmemmap_list, and form a freed list,
with next as the header. The next position in the last allocated page is kept
at the list tail.
When allocation, if there are freed entries left, get it from
This is to be called in vmemmap_free(), leave the implementation on BOOK3E
empty as before.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
Cc: Nathan Fontenot nf...@linux.vnet.ibm.com
---
arch/powerpc/mm/hash_utils_64.c |2 +-
arch/powerpc/mm/init_64.c | 22 ++
vmemmap_free() does the opposite of vmemap_populate().
This patch also puts vmemmap_free() and vmemmap_list_free() into
CONFIG_MEMMORY_HOTPLUG.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
Cc: Nathan Fontenot nf...@linux.vnet.ibm.com
---
arch/powerpc/mm/init_64.c | 85
vmemmap_populated() checks whether the [start, start + page_size) has valid
pfn numbers, to know whether a vmemmap mapping has been created that includes
this range.
Some range before end might not be checked by this loop:
sec11start..start11..sec11end/sec12start..endstart12..sec12end
Dne 11.6.2014 08:02, Mike Qiu napsal(a):
Hi all,
I recently build linux next kernel in IBM Power7 platform, use default
config file copy from /boot/config-3.6.10-4.fc18.ppc64p7
[root@cena01 linux-next]# uname -a
Linux cena01.austin.ibm.com 3.15.0-rc1+ #47 SMP Thu Apr 24 20:59:46 CDT
2014
On Tue, Jun 10 2014, Joonsoo Kim iamjoonsoo@lge.com wrote:
Without including device.h, build failure occurs.
In dma-contiguous.h, we try to access to dev-cma_area, so we need
device.h. In the past, we included it luckily by swap.h in
drivers/base/dma-contiguous.c. Swap.h includes node.h
As Ben suggested, it's meaningful to dump PE's location code
for site engineers when hitting EEH errors. The patch introduces
function eeh_pe_loc_get() to retireve the location code from
dev-tree so that we can output it when hitting EEH errors.
If primary PE bus is root bus, the PHB's dev-node
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Current code does not check for unhandled/unrecovered errors and return from
interrupt if it is recoverable exception which in-turn triggers same machine
check exception in a loop causing hypervisor to be unresponsive.
This patch fixes this
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Currently machine check handler does not check for stack overflow for
nested machine check. If we hit another MCE while inside the machine check
handler repeatedly from same address then we get into risk of stack
overflow which can cause huge
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
We don't see MCE counter getting increased in /proc/interrupts which gives
false impression of no MCE occurred even when there were MCE events.
The machine check early handling was added for PowerKVM and we missed to
increment the MCE count in the
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Currently we forward MCEs to guest which have been recovered by guest.
And for unhandled errors we do not deliver the MCE to guest. It looks like
with no support of FWNMI in qemu, guest just panics whenever we deliver the
recovered MCEs to guest.
On Wed, Jun 11, 2014 at 05:29:44PM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2014-06-11 at 15:12 +0800, Wei Yang wrote:
Sorry for the long delay. It took me some time to investigate and test the
code.
Currently, the hotplug by qemu monitor command line has been verified. Two
pci
device
The T2080 QorIQ multicore processor combines four dual-threaded e6500 Power
Architecture processor cores with high-performance datapath acceleration
logic and network and peripheral bus interfaces required for networking,
telecom/datacom, wireless infrastructure, and mil/aerospace applications.
Add support for Freescale T2080/T2081 QDS Development System Board.
The T2080QDS Development System is a high-performance computing,
evaluation, and development platform that supports T2080 QorIQ
Power Architecture processor, with following major features:
T2080QDS feature overview:
Processor:
T2080PCIe-RDB is a Freescale Reference Design Board that hosts T2080 SoC.
The board feature overview:
Processor:
- T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
DDR Memory:
- Single memory controller capable of supporting DDR3 and DDR3-LP devices
- 72bit 4GB DDR3-LP
On Wed, Jun 11, 2014 at 10:24:24AM +0200, Michal Marek wrote:
Dne 11.6.2014 08:02, Mike Qiu napsal(a):
make[1]: Circular arch/powerpc/boot/zImage.lds.S -
arch/powerpc/boot/zImage.lds dependency dropped.
make[1]: Circular arch/powerpc/boot/zImage.coff.lds.S -
arch/powerpc/boot/zImage.lds
Dne 11.6.2014 14:21, Michal Marek napsal(a):
On Wed, Jun 11, 2014 at 10:24:24AM +0200, Michal Marek wrote:
Dne 11.6.2014 08:02, Mike Qiu napsal(a):
make[1]: Circular arch/powerpc/boot/zImage.lds.S -
arch/powerpc/boot/zImage.lds dependency dropped.
make[1]: Circular
Hi Michal,
after ally you patch, it also has some issue, see below:
WARNING: 1 bad relocations
c1455040 R_PPC64_ADDR64uprobes_fetch_type_table
arch/powerpc/boot/Makefile:336: target
`arch/powerpc/boot/zImage.pseries' given more than once in the same rule.
gcc -m32
They're almost a duplicate of the boards array
and we can build them at run-time.
Signed-off-by: Laurentiu Tudor laurentiu.tu...@freescale.com
---
arch/powerpc/platforms/85xx/corenet_generic.c | 49 +++
1 file changed, 20 insertions(+), 29 deletions(-)
diff --git
The rule to create the final images uses a zImage.% pattern.
Unfortunately, this also matches the names of the zImage.*.lds linker
scripts, which appear as a dependency of the final images. This somehow
worked when $(srctree) used to be an absolute path, but now the pattern
matches too much. List
This is under Ubuntu Utopic Unicorn on a Power 8 system while simply
trying to build with the Ubuntu standard kernel config. It could be that
these issues come about because we do not have an rc1 yet but I wanted to
give some early notice. Also this is a new arch to me so I may not be
aware of how
Looking at arch/powerpc/include/asm/percpu.h I see that the per cpu offset
comes from a local_paca field and local_paca is in r13. That means that
for all percpu operations we first have to determine the address through a
memory access.
Would it be possible to put the paca at the beginning of
On Wed, 2014-06-11 at 14:37 -0500, Christoph Lameter wrote:
Looking at arch/powerpc/include/asm/percpu.h I see that the per cpu offset
comes from a local_paca field and local_paca is in r13. That means that
for all percpu operations we first have to determine the address through a
memory
On Wed, 2014-06-11 at 10:44 -0500, Christoph Lameter wrote:
This is under Ubuntu Utopic Unicorn on a Power 8 system while simply
trying to build with the Ubuntu standard kernel config. It could be that
these issues come about because we do not have an rc1 yet but I wanted to
give some early
On Tue, 2014-06-10 at 11:41 +1000, Gavin Shan wrote:
The patch adds new IOCTL commands for sPAPR VFIO container device
to support EEH functionality for PCI devices, which have been passed
through from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
On Thu, Jun 12, 2014 at 06:22:11AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2014-06-11 at 14:37 -0500, Christoph Lameter wrote:
Looking at arch/powerpc/include/asm/percpu.h I see that the per cpu offset
comes from a local_paca field and local_paca is in r13. That means that
for all
Commit 2749a2f26a7c (powerpc/book3s: Fix machine check handling for
unhandled errors) introduced a few ABIv2 issues.
We can maintain ABIv1 and ABIv2 compatibility by branching to the
function rather than the dot symbol.
Fixes: 2749a2f26a7c (powerpc/book3s: Fix machine check handling for
On Wed, Jun 11, 2014 at 12:13:52AM -0700, Guenter Roeck wrote:
Commit 432481220 (ASoC: fsl-ssi: Use regmap) removed struct ccsr_ssi.
Unfortunately, the structure is still used. This causes
mpc85xx_smp_defconfig and mpc85xx_defconfig builds to fail with
Applied, thanks,.
signature.asc
This v2 patch is good,
Tested-by: Mike Qiu qiud...@linux.vnet.ibm.com
On 06/11/2014 11:40 PM, Michal Marek wrote:
The rule to create the final images uses a zImage.% pattern.
Unfortunately, this also matches the names of the zImage.*.lds linker
scripts, which appear as a dependency of the
We can remove one call sites for clear_cma_bitmap() if we first
call it before checking error number.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/mm/cma.c b/mm/cma.c
index 1e1b017..01a0713 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -282,11 +282,12 @@ struct page *cma_alloc(struct
ppc kvm's cma area management needs alignment constraint on
cma region. So support it to prepare generalization of cma area
management functionality.
Additionally, add some comments which tell us why alignment
constraint is needed on cma region.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Currently, we should take the mutex for manipulating bitmap.
This job may be really simple and short so we don't need to sleep
if contended. So I change it to spinlock.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/mm/cma.c b/mm/cma.c
index 22a5b23..3085e8c 100644
--- a/mm/cma.c
We should free memory for bitmap when we find zone mis-match,
otherwise this memory will leak.
Additionally, I copy code comment from ppc kvm's cma code to notify
why we need to check zone mis-match.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/drivers/base/dma-contiguous.c
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others doesn't. This looks
bad to me, so I unify log format to print function name consistently.
Lastly, I add one more debug log on cma_activate_area().
Conventionally, we put output param to the end of param list.
cma_declare_contiguous() doesn't look like that, so change it.
Additionally, move down cma_areas reference code to the position
where it is really needed.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain
To prepare future generalization work on cma area management code,
we need to separate core cma management codes from DMA APIs.
We will extend these core functions to cover requirements of
ppc kvm's cma area management functionality in following patches.
This separation helps us not to touch DMA
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Acked-by: Michal Nazarewicz min...@mina86.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git
Joonsoo Kim iamjoonsoo@lge.com writes:
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others doesn't. This looks
bad to me, so I unify log format to print function name consistently.
Lastly, I
Joonsoo Kim iamjoonsoo@lge.com writes:
We should free memory for bitmap when we find zone mis-match,
otherwise this memory will leak.
Additionally, I copy code comment from ppc kvm's cma code to notify
why we need to check zone mis-match.
Signed-off-by: Joonsoo Kim
Joonsoo Kim iamjoonsoo@lge.com writes:
To prepare future generalization work on cma area management code,
we need to separate core cma management codes from DMA APIs.
We will extend these core functions to cover requirements of
ppc kvm's cma area management functionality in following
Joonsoo Kim iamjoonsoo@lge.com writes:
ppc kvm's cma area management needs alignment constraint on
cma region. So support it to prepare generalization of cma area
management functionality.
Additionally, add some comments which tell us why alignment
constraint is needed on cma region.
On Thu, Jun 12, 2014 at 12:21:39PM +0900, Joonsoo Kim wrote:
We should free memory for bitmap when we find zone mis-match,
otherwise this memory will leak.
Then, -stable stuff?
Additionally, I copy code comment from ppc kvm's cma code to notify
why we need to check zone mis-match.
Hi Joonsoo,
On Thu, Jun 12, 2014 at 12:21:38PM +0900, Joonsoo Kim wrote:
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others doesn't. This looks
bad to me, so I unify log format to print function
On Thu, Jun 12, 2014 at 12:21:40PM +0900, Joonsoo Kim wrote:
To prepare future generalization work on cma area management code,
we need to separate core cma management codes from DMA APIs.
We will extend these core functions to cover requirements of
ppc kvm's cma area management functionality
On Thu, Jun 12, 2014 at 10:11:19AM +0530, Aneesh Kumar K.V wrote:
Joonsoo Kim iamjoonsoo@lge.com writes:
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others doesn't. This looks
bad to
On Thu, Jun 12, 2014 at 02:18:53PM +0900, Minchan Kim wrote:
Hi Joonsoo,
On Thu, Jun 12, 2014 at 12:21:38PM +0900, Joonsoo Kim wrote:
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others
On Thu, Jun 12, 2014 at 12:21:41PM +0900, Joonsoo Kim wrote:
ppc kvm's cma area management needs alignment constraint on
cma region. So support it to prepare generalization of cma area
management functionality.
Additionally, add some comments which tell us why alignment
constraint is needed
On Thu, Jun 12, 2014 at 02:25:43PM +0900, Minchan Kim wrote:
On Thu, Jun 12, 2014 at 12:21:39PM +0900, Joonsoo Kim wrote:
We should free memory for bitmap when we find zone mis-match,
otherwise this memory will leak.
Then, -stable stuff?
I don't think so. This is just possible leak
60 matches
Mail list logo
