On 10/17/2014 12:59 AM, kernelf...@gmail.com wrote:
To enter guest, primary hwtherad schedules the stopper func on
secondary threads and force them into NAP mode.
When exit to host,secondary threads hardcode to restore the stack,
then switch back to the stopper func, i.e host.
On 10/09/2014 05:18 PM, Anshuman Khandual wrote:
This patch enables support for hardware instruction breakpoints
on POWER8 with the help of a new register CIABR (Completed
Instruction Address Breakpoint Register). With this patch, single
hardware instruction breakpoint can be added and cleared
On 10/17/2014 12:59 AM, kernelf...@gmail.com wrote:
The secondary thread can only jump back to host until primary has set
up the env. Add host_ready field in kvm_vcore to sync this action.
Do we need to do this? We already synchronize among the sibling threads
when there is a need to enter the
On Mon, 2014-27-10 at 04:24:35 UTC, Ian Munsie wrote:
From: Ian Munsie imun...@au1.ibm.com
In certain circumstances the PSL can send an interrupt for a segment
Define PSL before using it please.
miss that the kernel has already handled. This can happen if multiple
translations for the same
On 10/17/2014 12:59 AM, kernelf...@gmail.com wrote:
(This is a place holder patch.)
We need to store the time base for host on secondary hwthread.
Later when switching back, we need to reprogram it with elapse
time.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
On 10/17/2014 01:00 AM, kernelf...@gmail.com wrote:
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
arch/powerpc/kvm/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 602eb51..de38566 100644
---
The build is broken with CONFIG_PPC32=y, CONFIG_FB_VGA16=y and
CONFIG_VGA_CONSOLE=n.
The problem is that vgacon_remap_base is not defined. It's used in:
#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
Which is used in the vga16fb.c code.
Digging down it seems vgacon_remap_base is never
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Acked-by: Sebastian Ott seb...@linux.vnet.ibm.com
---
arch/s390/include/asm/pci.h |1 +
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/ia64/include/asm/pci.h |3 ++-
arch/ia64/kernel/msi_ia64.c | 24 ++--
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
CC: David Vrabel david.vra...@citrix.com
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/x86/include/asm/pci.h |4
arch/x86/kernel/apic/io_apic.c | 25
Now there are a lot of weak arch MSI functions in MSI code.
These functions make MSI driver complex. Because people need
to know much which arch MSI function should be overrode and
which is not. Thierry introduced MSI chip framework to configure
MSI/MSI-X irq in arm. MSI chip framework is better
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/include/asm/octeon/pci-octeon.h |4 +++
arch/mips/pci/msi-octeon.c|
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/pci/pci-xlr.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Acked-by: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/include/asm/pci-bridge.h |8
This series is based on [PATCH 00/10] Save MSI chip in pci_sys_data,
https://lkml.org/lkml/2014/10/27/85.
This series is the v4 of Use MSI chip framework to configure MSI/MSI-X in all
platforms.
I split it out and post it together.
v3-new:
Some trivial changes in IA64/MSI: Use MSI controller
Save MSI controller in pci sysdata, add arch pcibios_msi_controller()
to extract out MSI controller.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/include/asm/pci.h |3 +++
arch/mips/pci/pci.c |9 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/iommu/irq_remapping.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
Now we can clean up MSI weak arch functions in x86.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/x86/include/asm/pci.h |5 +
arch/x86/include/asm/x86_init.h |4
arch/x86/kernel/apic/io_apic.c | 21 +
arch/x86/kernel/x86_init.c | 24
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X IRQ. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/include/asm/netlogic/xlp-hal/pcibus.h |1 +
arch/mips/pci/msi-xlp.c
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Acked-by: David S. Miller da...@davemloft.net
---
arch/sparc/kernel/pci.c | 20
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/tile/include/asm/pci.h |2 ++
arch/tile/kernel/pci_gx.c | 18 --
2 files
Now we use MSI controller in all platforms to configure
MSI/MSI-X. We can clean up the unused arch functions.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Reviewed-by: Lucas Stach l.st...@pengutronix.de
---
drivers/pci/msi.c | 90 ++
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/arm/mach-iop13xx/include/mach/pci.h |4
arch/arm/mach-iop13xx/iq81340mc.c|3
Many drivers use in_be16(), in_be32(), out_be16(), out_be32(), etc
to access to registrers in IO mapped memory.
What is the real purpose of those functions, and are they really needed ?
ioremap() maps the related areas as GUARDED, which means that accesses
can't be speculative. So what
On 27/10/14 13:59, Jani Nikula wrote:
While doing 'depends on' instead of 'select' is an easy fix for this,
I do dislike it quite a bit. It's a major pain to go around the kernel
config, trying to find all the dependencies that a particular driver
wants. If I need fb-foobar, I should just be
Commit dcb18694 : Fix ipi on Palmeto added a workaround to disable
going into fastsleep on Palmeto boards which was reported to fail
to boot when fastsleep was enabled. However it missed returning
an idle index. Fix this.
There is probably no harm in returning the index of fastsleep
although the
Hello,
I noticed the following warnings while building the upstream kernel as of
yesterday.
The commit I checked out at was cac7f2429872d3 : Linux 3.18-rc2.
Please verify if any of these can be fixed.
a. lib/cpumask.c: In function ‘cpumask_set_cpu_local_first’:
lib/cpumask.c:194:25:
CC arch/powerpc/mm/slice.o
In file included from ../arch/powerpc/mm/slice.c:33:0:
../include/linux/hugetlb.h:141:47: error: expected identifier or ‘(’ before
numeric constant
#define is_hugepage_only_range(mm, addr, len) 0
^
Ian Munsie imun...@au1.ibm.com writes:
From: Ian Munsie imun...@au1.ibm.com
In certain circumstances the PSL can send an interrupt for a segment
miss that the kernel has already handled. This can happen if multiple
translations for the same segment are queued in the PSL before the
kernel
From: leroy christophe
Many drivers use in_be16(), in_be32(), out_be16(), out_be32(), etc
to access to registrers in IO mapped memory.
What is the real purpose of those functions, and are they really needed ?
ioremap() maps the related areas as GUARDED, which means that accesses
pm_power_off is defined for all architectures. Move it to common code.
Have all architectures call do_kernel_power_off instead of pm_power_off.
Some architectures point pm_power_off to machine_power_off. For those,
call do_kernel_power_off from machine_power_off instead.
Acked-by: David Vrabel
Ping? We are planning to remove support for __get_cpu_var in the
3.19 merge period. I can move the definition for __get_cpu_var into the
powerpc per cpu definition instead if we cannot get this merged?
On Tue, 21 Oct 2014, Christoph Lameter wrote:
This still has not been merged and now powerpc
On Mon, 2014-10-27 at 13:52 +0100, leroy christophe wrote:
Many drivers use in_be16(), in_be32(), out_be16(), out_be32(), etc
to access to registrers in IO mapped memory.
What is the real purpose of those functions, and are they really needed ?
ioremap() maps the related areas as
On Fri, Oct 24, 2014 at 04:48:11PM -0700, Nicolin Chen wrote:
When cpu-dai is the DAI Master (CBM_CFx), it may need some configurations,
set_sysclk() call for eample, for cpu-dai side in the hw_params(), even if
the set_bias_level() has already taken care of the codec-dai side.
So this patch
On Mon, Oct 27, 2014 at 05:30:31PM +, Mark Brown wrote:
On Fri, Oct 24, 2014 at 04:48:11PM -0700, Nicolin Chen wrote:
When cpu-dai is the DAI Master (CBM_CFx), it may need some configurations,
set_sysclk() call for eample, for cpu-dai side in the hw_params(), even if
the
Andrea Arcangeli aarca...@redhat.com writes:
Hello,
On Mon, Oct 27, 2014 at 07:50:41AM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2014-10-24 at 09:22 -0700, James Bottomley wrote:
Parisc does this. As soon as one CPU issues a TLB purge, it's broadcast
to all the CPUs on the inter-CPU
Hi Aneesh,
On Mon, Oct 27, 2014 at 11:28:41PM +0530, Aneesh Kumar K.V wrote:
VM_BUG_ON(address ~HPAGE_PMD_MASK);
if (pmd_trans_huge(*pmdp)) {
pmd = pmdp_get_and_clear(vma-vm_mm, address, pmdp);
} else {
The only problematic path that needs IPI is the below
On Mon, 2014-10-27 at 10:57 -0500, Christoph Lameter wrote:
Ping? We are planning to remove support for __get_cpu_var in the
3.19 merge period. I can move the definition for __get_cpu_var into the
powerpc per cpu definition instead if we cannot get this merged?
Yes, yes, I know, we should
On Mon, 2014-10-27 at 15:05 +, David Laight wrote:
Unfortunately the functions sometimes contain additional (often
unneeded)
sequencing instructions - the driver may be able to perform multiple
operations between the sequencing instructions.
That's in part why some folks are working
On Tue, 2014-10-28 at 08:10 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2014-10-27 at 10:57 -0500, Christoph Lameter wrote:
Ping? We are planning to remove support for __get_cpu_var in the
3.19 merge period. I can move the definition for __get_cpu_var into the
powerpc per cpu definition
On Sat, 25 Oct 2014 16:14:19 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the hugepage directory.
I grabbed these. It would be
On Wed, 22 Oct 2014, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 18/10/14 00:13, Jani Nikula wrote:
Documentation/kbuild/kconfig-language.txt warns to use select with care,
and in general use select only for non-visible symbols and for symbols
with no dependencies, because select will force
Excerpts from Michael Ellerman's message of 2014-10-27 17:41:00 +1100:
On Mon, 2014-27-10 at 04:24:35 UTC, Ian Munsie wrote:
From: Ian Munsie imun...@au1.ibm.com
In certain circumstances the PSL can send an interrupt for a segment
Define PSL before using it please.
ok
The CXL driver
On Fri, Oct 24, 2014 at 07:03:57PM -0700, Nicolin Chen wrote:
Kernel dump (WARN_ON) ocurred during system boot-up inside regmap_write():
[ cut here ]
WARNING: CPU: 0 PID: 47 at kernel/locking/lockdep.c:2744
lockdep_trace_alloc+0xe8/0x108()
Applied, thanks. Please
Excerpts from Aneesh Kumar K.V's message of 2014-10-28 01:38:41 +1100:
I guess you are missing too many fixes in one patch.
1) One cleanup
2) Fix for masking ea correctly
3) And fix for not erroring out when a slb is already in the slb cache.
ok, I'll split it up
+/* This finds a free
This reverts commit bf7588a0859580a45c63cb082825d77c13eca357.
Ben says, The original code was fine, I think the bug was actually in
the userspace tool I was using (don't worry, nothing on the field uses
that interface yet and I can still fix the tool).
Signed-off-by: Michael Ellerman
On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote:
On Sat, 25 Oct 2014 16:14:19 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a
On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman m...@ellerman.id.au wrote:
On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote:
On Sat, 25 Oct 2014 16:14:19 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Update generic gup implementation with powerpc specific
On Mon, 2014-10-27 at 19:03 +0530, Preeti U Murthy wrote:
Hello,
I noticed the following warnings while building the upstream kernel as of
yesterday.
The commit I checked out at was cac7f2429872d3 : Linux 3.18-rc2.
Please verify if any of these can be fixed.
Patches welcome.
cheers
On Tue, 28 Oct 2014, Michael Ellerman wrote:
I'm happy to put it in a topic branch for 3.19, or move the definition or
whatever, your choice Christoph.
Get the patch merged please.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
From: Ian Munsie imun...@au1.ibm.com
This patch simplifies the process of finding a free segment table entry
by disabling the secondary hash. This reduces the number of possible
entries in the segment table for a given address from 16 to 8.
Due to the large segment sizes we use it is extremely
From: Ian Munsie imun...@au1.ibm.com
In certain circumstances the PSL (Power Service Layer, which provides
translation services for CXL hardware) can send an interrupt for a
segment miss that the kernel has already handled. This can happen if
multiple translations for the same segment are queued
In certain circumstances the PSL (Power Service Layer, which provides
translation services for CXL hardware) can send an interrupt for a segment miss
that the kernel has already handled. This can happen if multiple translations
for the same segment are queued in the PSL before the kernel has
From: Ian Munsie imun...@au1.ibm.com
This patch makes copro_calculate_slb mask the ESID by the correct mask
for 1T vs 256M segments.
This has no effect by itself as the extra bits were ignored, but it
makes debugging the segment table entries easier and means that we can
directly compare the
From: Ian Munsie imun...@au1.ibm.com
This moves the segment table hash calculation from cxl_load_segment into
find_free_sste since that is the only place it is actually used.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/misc/cxl/fault.c | 34 ++
1
On Tue, 2014-10-28 at 09:04 +1100, Michael Ellerman wrote:
On Tue, 2014-10-28 at 08:10 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2014-10-27 at 10:57 -0500, Christoph Lameter wrote:
Ping? We are planning to remove support for __get_cpu_var in the
3.19 merge period. I can move the
On Tue, 2014-10-28 at 12:15 +1100, Michael Ellerman wrote:
This reverts commit bf7588a0859580a45c63cb082825d77c13eca357.
Ben says, The original code was fine, I think the bug was actually in
the userspace tool I was using (don't worry, nothing on the field uses
that interface yet and I can
On Tue, Oct 28, 2014 at 12:19:04AM +, Mark Brown wrote:
On Fri, Oct 24, 2014 at 07:03:57PM -0700, Nicolin Chen wrote:
Kernel dump (WARN_ON) ocurred during system boot-up inside regmap_write():
[ cut here ]
WARNING: CPU: 0 PID: 47 at
On Mon, 2014-27-10 at 14:30:06 UTC, =?utf-8?q?C=C3=A9dric_Le_Goater?= wrote:
CC arch/powerpc/mm/slice.o
In file included from ../arch/powerpc/mm/slice.c:33:0:
../include/linux/hugetlb.h:141:47: error: expected identifier or â(â
before numeric constant
#define
Hi Segher,
On Wed, Sep 24, 2014 at 12:33:07PM +1000, Anton Blanchard wrote:
We are scratching our heads trying to remember details of the issue
right now. In retrospect we should have linked the gcc bugzilla or
gcc commit details in the kernel commit message :)
There have been many GCC
61 matches
Mail list logo
