On Thu, 2013-07-25 at 15:51 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
For an extern function, if the performance is not sensible, better to
have the return value which can indicate the failure with the negative
number.
The return value is
On Wed, Jul 24, 2013 at 3:08 PM, Benjamin Herrenschmidt
b...@au1.ibm.com wrote:
No, they resolve to the same thing under the hood. Did you do other
changes ? Could it be another unrelated kernel bug causing something
like use-after-free of network buffer or similar oddity unrelated to the
On 07/25/2013 01:51 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
For an extern function, if the performance is not sensible, better to
have the return value which can indicate the failure with the negative
number.
The return value is meaningless.
On 07/25/2013 02:03 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 15:51 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
For an extern function, if the performance is not sensible, better to
have the return value which can indicate the failure
On Thu, 2013-07-25 at 14:17 +0800, Chen Gang wrote:
Hmm... for an extern function (espeically have been implemented in
various modules), normally, we can assume it may fail in some cases
(although now, we don't know what cases can cause its failure).
If we don't have a good way to handle
On 07/25/2013 03:33 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 14:17 +0800, Chen Gang wrote:
Hmm... for an extern function (espeically have been implemented in
various modules), normally, we can assume it may fail in some cases
(although now, we don't know what cases can
On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
For my opinion: one fix may like below (assume have removed max_cpus)
which is more reasonable for code readers.
So instead of just failing to bring the secondary CPUs, but potentially
still having a working system, you crash during boot
On 07/25/2013 04:06 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
For my opinion: one fix may like below (assume have removed max_cpus)
which is more reasonable for code readers.
So instead of just failing to bring the secondary CPUs, but potentially
On Thu, 2013-07-25 at 16:22 +0800, Chen Gang wrote:
On 07/25/2013 04:06 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
For my opinion: one fix may like below (assume have removed max_cpus)
which is more reasonable for code readers.
So instead of
On 07/25/2013 04:28 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 16:22 +0800, Chen Gang wrote:
On 07/25/2013 04:06 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
For my opinion: one fix may like below (assume have removed max_cpus)
On Wed, Jul 24, 2013 at 03:32:49PM -0500, Scott Wood wrote:
On 07/24/2013 04:39:59 AM, Alexander Graf wrote:
On 24.07.2013, at 11:35, Gleb Natapov wrote:
On Wed, Jul 24, 2013 at 11:21:11AM +0200, Alexander Graf wrote:
Are not we going to use page_is_ram() from
e500_shadow_mas2_attrib()
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
The IPI handlers for both PPC_MSG_CALL_FUNC and PPC_MSG_CALL_FUNC_SINGLE
map to a common implementation - generic_smp_call_function_single_interrupt().
So, we can consolidate them and save one of the IPI message slots, (which are
precious,
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
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
For scalability and performance reasons, we want the broadcast timer
interrupts to be handled as efficiently as possible. Fixed IPI messages
are one of the most efficient mechanisms available - they are faster
than the smp_call_function
On ppc, in deep idle states, the lapic of the cpus gets switched off.
Hence make use of the broadcast framework to wakeup cpus in sleep state,
except that on ppc, we do not have an external device such as HPET, but
we use the lapic of a cpu itself as the broadcast device.
Instantiate two
In the current design of timer offload framework, the broadcast cpu should
*not* go into tickless idle so as to avoid missed wakeups on CPUs in deep idle
states.
Since we prevent the CPUs entering deep idle states from programming the lapic
of the
broadcast cpu for their respective next local
This patch hooks into the existing broadcast framework with the support that
this
patchset introduces for ppc, and the cpuidle driver backend
for powernv(posted out recently by Deepthi Dharwar) to add sleep state as
one of the deep idle states, in which the decrementer is switched off.
However
Let CPU DAI drivers set SDMA periperal type directly to support more
dma types(SPDIF, ESAI) other than only two for SSI.
This will easily allow some non-SSI drivers to use the imx-pcm-dma
as well.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
@Timur
Compile-passed with mpc85xx_defconfig by
On 10.07.2013, at 09:25, Michael Neuling wrote:
Alexander Graf ag...@suse.de wrote:
On 09.07.2013, at 06:24, Michael Neuling wrote:
Alexander Graf ag...@suse.de wrote:
On 04.07.2013, at 08:15, Bharat Bhushan wrote:
From: Bharat Bhushan bharat.bhus...@freescale.com
This
On 04.07.2013, at 08:57, Bharat Bhushan wrote:
KVM need this function when switching from vcpu to user-space
thread. My subsequent patch will use this function.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
Ben / Michael, please ack.
Alex
---
v5-v6
-
The current VFIO-on-POWER implementation supports only user mode
driven mapping, i.e. QEMU is sending requests to map/unmap pages.
However this approach is really slow, so we want to move that to KVM.
Since H_PUT_TCE can be extremely performance sensitive (especially with
network adapters where
On 07/25/2013 08:26 PM, Alexey Kardashevskiy wrote:
The current VFIO-on-POWER implementation supports only user mode
driven mapping, i.e. QEMU is sending requests to map/unmap pages.
However this approach is really slow, so we want to move that to KVM.
Since H_PUT_TCE can be extremely
Dear Sir,
We are using P1021rdb-pc board with p1021 processor.
1. compilation and build process is taking so much of time. How should I
reduce the time for linux build process?
2. In kernel configuration we are not able to select P1021rdb., When we
configured the board for
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
On Tue, Jul 23, 2013 at 05:31:16PM -0500, Scott Wood wrote:
On 06/06/2013 09:00:20 PM, Kevin Hao wrote:
Vector table: BAR=1 offset=
snip
PBA: BAR=1 offset=0800
As you can see, the only difference between these two logs is the
io resource
On Thu, Jul 25, 2013 at 09:14:25AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
Apart from the annoying colors, is there anything specific I should
be looking for? Some sort of error message, or output that actually
makes sense?
On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote:
In the current design of timer offload framework, the broadcast cpu should
*not* go into tickless idle so as to avoid missed wakeups on CPUs in deep
idle states.
Since we prevent the CPUs entering deep idle states from
On Thu, Jul 25, 2013 at 05:41:41PM +0800, Nicolin Chen wrote:
Let CPU DAI drivers set SDMA periperal type directly to support more
dma types(SPDIF, ESAI) other than only two for SSI.
This will easily allow some non-SSI drivers to use the imx-pcm-dma
as well.
Signed-off-by: Nicolin Chen
On Thu, Jul 25, 2013 at 06:07:55PM +0200, Alexander Graf wrote:
On 25.07.2013, at 10:50, Gleb Natapov wrote:
On Wed, Jul 24, 2013 at 03:32:49PM -0500, Scott Wood wrote:
On 07/24/2013 04:39:59 AM, Alexander Graf wrote:
On 24.07.2013, at 11:35, Gleb Natapov wrote:
On Wed, Jul 24,
On 25.07.2013, at 10:50, Gleb Natapov wrote:
On Wed, Jul 24, 2013 at 03:32:49PM -0500, Scott Wood wrote:
On 07/24/2013 04:39:59 AM, Alexander Graf wrote:
On 24.07.2013, at 11:35, Gleb Natapov wrote:
On Wed, Jul 24, 2013 at 11:21:11AM +0200, Alexander Graf wrote:
Are not we going to use
Yinghai is working on a regression fix (PCI: Separate stop and remove
devices in pciehp) that needs to go into v3.11, and his fix will be
simpler if we remove the module option for pciehp in v3.11. That will mean
he won't have to export pci_stop_bus_device() and pci_remove_bus_device()
for use by
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 +-
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
On Thu, Jul 25, 2013 at 05:41:41PM +0800, Nicolin Chen wrote:
Let CPU DAI drivers set SDMA periperal type directly to support more
dma types(SPDIF, ESAI) other than only two for SSI.
This will easily allow some non-SSI drivers to use the imx-pcm-dma
as well.
Applied, thanks.
signature.asc
On Thursday, July 25, 2013 11:57:20 AM Bjorn Helgaas 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
Acked-by: Rafael J. Wysocki
On Mon, Jul 15, 2013 at 5:52 AM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
Hi Alexandre,
Le Friday 28 June 2013 à 15:18 -0400, Alexandre Bounine a écrit :
The following set of patches modifies kernel RapidIO subsystem to enable build
and use of its components as loadable kernel modules. Combinations of
statically
linked and modular components are also supported.
On Mon, Jul 15, 2013 at 01:52:38PM +0200, Thomas Petazzoni wrote:
Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
infrastructure, it is desirable
On Wed, Jan 11, 2012 at 9:22 PM, Grant Likely grant.lik...@secretlab.ca wrote:
NO_IRQ is evil. Stop using it in arch/powerpc and powerpc device drivers
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 3e06696..55c6ff9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++
Cell and PSeries both implemented their own versions of a
cpu_bootable smp_op which do the same thing (well, the PSeries
one has support for more than 2 threads). Copy the PSeries one
to generic code, and rename it smp_generic_cpu_bootable.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
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:
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
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
Hi Frederic,
On 07/25/2013 07:00 PM, Frederic Weisbecker wrote:
On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote:
In the current design of timer offload framework, the broadcast cpu should
*not* go into tickless idle so as to avoid missed wakeups on CPUs in deep
idle states.
Hi Frederic,
On 07/25/2013 07:00 PM, Frederic Weisbecker wrote:
On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote:
In the current design of timer offload framework, the broadcast cpu should
*not* go into tickless idle so as to avoid missed wakeups on CPUs in deep
idle states.
On Fri, Jul 26, 2013 at 08:09:23AM +0530, Preeti U Murthy wrote:
Hi Frederic,
On 07/25/2013 07:00 PM, Frederic Weisbecker wrote:
Hi Preeti,
I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle
mode.
I read in the previous patch that's because in dynticks idle
From: Mingkai Hu mingkai...@freescale.com
C293PCIE board is a series of Freescale PCIe add-in cards to perform
as public key crypto accelerator or secure key management module.
- 512KB platform SRAM in addition to 512K L2 Cache/SRAM
- 512MB soldered DDR3 32bit memory
- CPLD System Logic
-
From: Mingkai Hu mingkai...@freescale.com
Add device tree for SEC 6.0 used on C29x silicon.
Signed-off-by: Mingkai Hu mingkai...@freescale.com
Signed-off-by: Po Liu po@freescale.com
---
Changes for v2:
- Remove the compatible sec v4.0/v4.4/v5.0;
- Add the device tree binding
From: Mingkai Hu mingkai...@freescale.com
Signed-off-by: Mingkai Hu mingkai...@freescale.com
Signed-off-by: Po Liu po@freescale.com
---
Changes for v2:
- None
arch/powerpc/boot/dts/fsl/c293si-post.dtsi | 193 +
arch/powerpc/boot/dts/fsl/c293si-pre.dtsi |
Hi Paul,
On 07/26/2013 08:49 AM, Paul Mackerras wrote:
On Fri, Jul 26, 2013 at 08:09:23AM +0530, Preeti U Murthy wrote:
Hi Frederic,
On 07/25/2013 07:00 PM, Frederic Weisbecker wrote:
Hi Preeti,
I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle
mode.
I read in
On Thu, Jul 25, 2013 at 3:58 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Wed, Jan 11, 2012 at 9:22 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
NO_IRQ is evil. Stop using it in arch/powerpc and powerpc device drivers
diff --git a/sound/soc/fsl/fsl_ssi.c
On 07/24/2013 08:38 AM, Chen Gang wrote:
On 07/23/2013 09:58 PM, Michael Ellerman wrote:
On Mon, Jul 22, 2013 at 03:02:53PM +0800, Chen Gang wrote:
Hello Maintainers:
With allmodconfig and EXTRA_CFLAGS=-W, it reports warnings below:
arch/powerpc/xmon/xmon.c:3027:6: warning: variable ‘i’
Hi Frederic,
I apologise for the confusion. As Paul pointed out maybe the usage of
the term lapic is causing a large amount of confusion. So please see the
clarification below. Maybe it will help answer your question.
On 07/26/2013 08:09 AM, Preeti U Murthy wrote:
Hi Frederic,
On 07/25/2013
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
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
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
For scalability and performance reasons, we want the broadcast timer
interrupts to be handled as efficiently as possible. Fixed IPI messages
are one of the most efficient mechanisms available - they are faster
than the smp_call_function
On ppc, in deep idle states, the local clock event device of CPUs gets
switched off. On PowerPC, the local clock event device is called the
decrementer. Make use of the broadcast framework to issue interrupts to
cpus in deep idle states on their timer events, except that on ppc, we
do not have an
This patch hooks into the existing broadcast framework with the support that
this
patchset introduces for ppc, and the cpuidle driver backend
for powernv(posted out recently by Deepthi Dharwar) to add sleep state as
one of the deep idle states, in which the decrementer is switched off.
However
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
The IPI handlers for both PPC_MSG_CALL_FUNC and PPC_MSG_CALL_FUNC_SINGLE
map to a common implementation - generic_smp_call_function_single_interrupt().
So, we can consolidate them and save one of the IPI message slots, (which are
precious,
Thanks, Gerhard.
I'll improve the code and return with the third version.
Best regards,
Alexander.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
In the current design of timer offload framework, the broadcast cpu should
*not* go into tickless idle so as to avoid missed wakeups on CPUs in deep idle
states.
Since we prevent the CPUs entering deep idle states from programming the
decrementer of the broadcast cpu for their respective next
For booke3e _PAGE_ENDIAN is not defined. Infact what is defined
is _PAGE_LENDIAN which is wrong and that should be _PAGE_ENDIAN.
There are no compilation errors as
arch/powerpc/include/asm/pte-common.h defines _PAGE_ENDIAN to 0
as it is not defined anywhere.
Signed-off-by: Bharat Bhushan
G bit in MAS2 indicates whether the page is Guarded.
There is no reason to stop guest setting G, so allow him.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/kvm/e500.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/e500.h
E bit in MAS2 bit indicates whether the page is accessed
in Little-Endian or Big-Endian byte order.
There is no reason to stop guest setting E, so allow him.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/kvm/e500.h |2 +-
1 files changed, 1 insertions(+), 1
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
65 matches
Mail list logo
