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 ha
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 c
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 pote
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.
> >
>
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
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_shado
From: Srivatsa S. Bhat
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, since only 4 of those slots are av
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 architecture
From: Srivatsa S. Bhat
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 mechanism because the IPI handlers ar
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 different
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 ev
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 in
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
---
@Timur
Compile-passed with mpc85xx_defconfig by using gcc-4.6.3-noli
On 10.07.2013, at 09:25, Michael Neuling wrote:
> Alexander Graf wrote:
>
>>
>> On 09.07.2013, at 06:24, Michael Neuling wrote:
>>
>>> Alexander Graf wrote:
>>>
On 04.07.2013, at 08:15, Bharat Bhushan wrote:
> From: Bharat Bhushan
>
> This patchset moves the d
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
Ben / Michael, please ack.
Alex
> ---
> v5->v6
> - switch_booke_debug_regs() not guarded by
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 eac
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 perfo
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 p1021R
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/e65
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=
> > PBA: BAR=1 offset=0800
> >
> >
> >As you can see, the only difference between these two logs is the
> >io re
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 pro
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 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
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 b
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
---
arch/ia64/configs/generic_defconfig|2 +-
arch/ia64/configs/gensparse_defconfig |2 +-
arch/ia64/configs/tiger
Convert pciehp to be builtin only, with no module option.
Signed-off-by: Bjorn Helgaas
Acked-by: Rafael J. Wysocki
---
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 1
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.as
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
Acked-by: Rafael J. Wysocki
> ---
> arch/ia64/configs/ge
On Mon, Jul 15, 2013 at 5:52 AM, 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 to s
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 desira
On Wed, Jan 11, 2012 at 9:22 PM, Grant Likely 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
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -6
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
---
arch/powerpc/include/as
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
Conflicts:
arch/powerpc/platforms/cell/smp.c
arch/powerp
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 l
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
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 sta
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 sta
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 d
From: Mingkai Hu
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
- 64MB x16 NOR flash and 4GB
From: Mingkai Hu
Add device tree for SEC 6.0 used on C29x silicon.
Signed-off-by: Mingkai Hu
Signed-off-by: Po Liu
---
Changes for v2:
- Remove the compatible sec v4.0/v4.4/v5.0;
- Add the device tree binding file fsl-sec6.txt;
.../devicetree/bindings/crypto/fsl-sec6.txt
From: Mingkai Hu
Signed-off-by: Mingkai Hu
Signed-off-by: Po Liu
---
Changes for v2:
- None
arch/powerpc/boot/dts/fsl/c293si-post.dtsi | 193 +
arch/powerpc/boot/dts/fsl/c293si-pre.dtsi | 63 ++
2 files changed, 256 insertions(+)
create mode 1006
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
>>>
On Thu, Jul 25, 2013 at 3:58 PM, Geert Uytterhoeven
wrote:
> On Wed, Jan 11, 2012 at 9:22 PM, Grant Likely
> 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
>>
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: warn
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/201
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 2b0a576d
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 architecture
From: Srivatsa S. Bhat
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 mechanism because the IPI handlers ar
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 e
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 in
From: Srivatsa S. Bhat
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, since only 4 of those slots are av
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 loc
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
---
a
"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
---
arch/powerpc/kvm/e500.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.
"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
---
arch/powerpc/kvm/e500.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/
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, wh
61 matches
Mail list logo
