On Tue, Jul 02, 2013 at 07:30:37AM +0200, Thomas Petazzoni wrote:
> Dear Michael Ellerman,
>
> On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
> > On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
> > > Until now, the MSI architecture-specific functions could be overloaded
> >
From: "Aneesh Kumar K.V"
Older version of power architecture use Real Mode Offset register and Real Mode
Limit
Selector for mapping guest Real Mode Area. The guest RMA should be physically
contigous since we use the range when address translation is not enabled.
This patch switch RMA allocation
From: "Aneesh Kumar K.V"
Both RMA and hash page table request will be a multiple of 256K. We can use
a chunk size of 256K to track the free/used 256K chunk in the bitmap. This
should help to reduce the bitmap size.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 3 ++
From: "Aneesh Kumar K.V"
Powerpc architecture uses a hash based page table mechanism for mapping virtual
addresses to physical address. The architecture require this hash page table to
be physically contiguous. With KVM on Powerpc currently we use early reservation
mechanism for allocating guest
From: "Aneesh Kumar K.V"
We want to use CMA for allocating hash page table and real mode area for
PPC64. Hence move DMA contiguous related changes into a seperate config
so that ppc64 can enable CMA without requiring DMA contiguous.
Acked-by: Michal Nazarewicz
Acked-by: Paul Mackerras
Signed-o
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun
> Chen
> Sent: Thursday, June 20, 2013 1:23 PM
> To: b...@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> S
Incorporate the addition of hsize argument in write_buf callback
of pstore.
Signed-off-by: Aruna Balakrishnaiah
---
fs/pstore/ftrace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c
index 43b1280..76a4eeb 100644
--- a/fs/pstore/ftr
Dear Michael Ellerman,
On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
> On Mon, 2013-07-01 at 15:42 +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
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun
> Chen
> Sent: Thursday, June 20, 2013 1:23 PM
> To: b...@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> S
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun
> Chen
> Sent: Thursday, June 20, 2013 1:23 PM
> To: b...@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> S
On 07/01/2013 11:52 PM, Santosh Shilimkar wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup_
On Mon, Jul 01, 2013 at 08:00:06PM -0500, Scott Wood wrote:
> On 06/30/2013 02:35:21 AM, Kevin Hao wrote:
> >On Thu, Jun 27, 2013 at 09:19:06PM -0500, Scott Wood wrote:
> >> On 06/26/2013 09:00:34 PM, Kevin Hao wrote:
> >> >diff --git a/arch/powerpc/include/asm/mmu-book3e.h
> >> >b/arch/powerpc/inc
On Mon, Jul 01, 2013 at 07:30:45PM -0500, Scott Wood wrote:
> On 06/30/2013 02:33:10 AM, Kevin Hao wrote:
> >On Thu, Jun 27, 2013 at 08:47:27PM -0500, Scott Wood wrote:
> >> On 06/27/2013 08:36:37 PM, Kevin Hao wrote:
> >> >On Thu, Jun 27, 2013 at 02:58:34PM -0500, Scott Wood wrote:
> >> >> On 06/2
Please ignore this patch.
-Hongtao
> -Original Message-
> From: Jia Hongtao-B38951
> Sent: Tuesday, July 02, 2013 9:35 AM
> To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> Cc: ga...@kernel.crashing.org; Li Yang-R58472; Jia Hongtao-B38951
> Subject: [PATCH] powerpc/msi: Fix compile
mpic_get_primary_version() is not defined when not using MPIC.
The compile error log like:
arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe':
fsl_msi.c:(.text+0x150c): undefined reference to `fsl_mpic_primary_get_version'
Signed-off-by: Jia Hongtao
---
arch/powerpc/include/asm/mpic
mpic_get_primary_version() is not defined when not using MPIC.
The compile error log like:
arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe':
fsl_msi.c:(.text+0x150c): undefined reference to `fsl_mpic_primary_get_version'
Signed-off-by: Jia Hongtao
Signed-off-by: Jia Hongtao
---
a
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 02, 2013 7:59 AM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> ga...@kernel.crashing.org; Li Yang-R58472; Jia Hongtao-B38951
> Subject: Re: [PATCH V6] powerpc/MPIC: Add get_version API
o *'
> fs/pstore/ftrace.c:47:6: error: too few arguments to function
> 'psinfo->write_buf'
>
> Caused by commit 6bbbca735936 ("pstore: Pass header size in the pstore
> write callback").
>
> I have used the version from next-20130701 for today.
Interestin
On 02.07.2013, at 02:56, Scott Wood wrote:
> On 07/01/2013 07:18:21 PM, Alexander Graf wrote:
>> On 01.07.2013, at 17:35, Mihai Caraman wrote:
>> > On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
>> > common defines to indentify these numbers.
>> So why didn't this happen from
On 06/30/2013 02:35:21 AM, Kevin Hao wrote:
On Thu, Jun 27, 2013 at 09:19:06PM -0500, Scott Wood wrote:
> On 06/26/2013 09:00:34 PM, Kevin Hao wrote:
> >diff --git a/arch/powerpc/include/asm/mmu-book3e.h
> >b/arch/powerpc/include/asm/mmu-book3e.h
> >index 936db36..bf422db 100644
> >--- a/arch/pow
On 07/01/2013 07:18:21 PM, Alexander Graf wrote:
On 01.07.2013, at 17:35, Mihai Caraman wrote:
> On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
> common defines to indentify these numbers.
So why didn't this happen from the beginning?
Ask Kumar.
Why the change?
So we
t 6bbbca735936 ("pstore: Pass header size in the pstore
write callback").
I have used the version from next-20130701 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpApmxoFEH8V.pgp
Description: PGP signature
__
On Mon, 2013-07-01 at 15:42 +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 to
On 06/30/2013 02:33:10 AM, Kevin Hao wrote:
On Thu, Jun 27, 2013 at 08:47:27PM -0500, Scott Wood wrote:
> On 06/27/2013 08:36:37 PM, Kevin Hao wrote:
> >On Thu, Jun 27, 2013 at 02:58:34PM -0500, Scott Wood wrote:
> >> On 06/26/2013 09:00:33 PM, Kevin Hao wrote:
> >> >This is based on the codes in
On 01.07.2013, at 17:35, Mihai Caraman wrote:
> On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
> common defines to indentify these numbers.
So why didn't this happen from the beginning? Why the change?
Alex
>
> Signed-off-by: Mihai Caraman
> ---
> arch/powerpc/kernel/ex
On 07/01/2013 12:21:50 AM, Haijun Zhang wrote:
Add compatible of esdhc for below board:
p2041 p3041 p4080 p5020 p5040
Signed-off-by: Haijun Zhang
CC: Scott Wood
CC: Fleming Andrew-AFLEMING
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p3041si-post.d
On 07/01/2013 12:26:06 AM, Jia Hongtao wrote:
From: Hongtao Jia
MPIC version is useful information for both mpic_alloc() and
mpic_init().
The patch provide an API to get MPIC version for reusing the code.
Also, some other IP block may need MPIC version for their own use.
The API for external
Note to contributors: This is only a fraction of the outstanding patches
for FSL PPC. I haven't been able to process the entire backlog since
starting to help Kumar with this a few weeks ago. If your patch is still
"action required" in patchwork, I haven't forgotten it -- but it will not
make it
On Mon, 2013-07-01 at 17:36 -0500, Scott Wood wrote:
> I'll send it tonight after I verify no obvious breakage.
>
> I realize it's late, but I wasn't involved until a few weeks ago, and
> there was a large backlog (of which I've only been able to get through
> a portion so far). Most of what
On 07/01/2013 05:16:51 PM, Benjamin Herrenschmidt wrote:
On Mon, 2013-07-01 at 11:55 -0500, Scott Wood wrote:
> I've been picking patches and hope to send a pull request soon. I
> already have these patches queued up as part of it.
Hurry !
Next time, I'd like the bulk of your stuff around -rc2
Hi Ben !
Please pull mpc5xxx patches for v3.11. There are small cleanups
and fixes for mpc512x common code, mpc512x_defconfig updates and
soft reboot support for mpc5125 based boards.
Thanks,
Anatolij
The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:
Linux 3.10-rc2
On Mon, 2013-07-01 at 11:55 -0500, Scott Wood wrote:
> I've been picking patches and hope to send a pull request soon. I
> already have these patches queued up as part of it.
Hurry !
Next time, I'd like the bulk of your stuff around -rc2 or 3 if possible,
ie, keep feeding me rather than one bi
When Jeremy introduced the new device-tree based reserve map, he made
the code in early_reserve_mem_dt() bail out if it found one, thus not
reserving the initrd nor processing the old style map.
I hit problems with variants of kexec that didn't put the initrd in
the new style map either. While the
On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of th
On 06/30/2013 09:38:15 PM, Wang Dongsheng-B40534 wrote:
Hi Benjamin & Kumar & scott,
I am not sure who can apply these patches...
Scott already ACK these patches.
A few days ago Scott have a pull request, Scott can accept them? Or ?
[v3,1/4] powerpc/mpic: add irq_set_wake support
http://patch
On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
common defines to indentify these numbers.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kernel/exceptions-64e.S |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64e.S
On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
common defines to indentify these numbers.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kernel/head_fsl_booke.S | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_bo
Thanks Alex.
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Monday, July 01, 2013 8:05 PM
> To: Sethi Varun-B16395
> Cc: j...@8bytes.org; io...@lists.linux-foundation.org; linuxppc-
> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
> b...@kern
On Mon, 2013-07-01 at 15:41 +0530, Varun Sethi wrote:
> Following is a brief description of the PAMU hardware:
> PAMU determines what action to take and whether to authorize the action on
> the basis of the memory address, a Logical IO Device Number (LIODN), and
> PAACT table (logically) indexed by
On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> wrote:
>> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>>> Apart from waste of 32bit, what is the other concern you
>>> have ?
>>
>> You pass a u64 as a physical address whi
Now that we have weak versions for each of the PCI MSI architecture
functions, we can actually build the MSI support for all platforms,
regardless of whether they provide or not architecture-specific
versions of those functions. For this reason, the ARCH_SUPPORTS_MSI
hidden kconfig boolean becomes
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 switch all those functions to use
the 'weak' mechanism. This commit
Michal Nazarewicz writes:
> On Fri, Jun 28 2013, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> We want to use CMA for allocating hash page table and real mode area for
>> PPC64. Hence move DMA contiguous related changes into a seperate config
>> so that ppc64 can enable CMA without r
From: Catalin Udma
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
On Fri, Jun 28 2013, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> We want to use CMA for allocating hash page table and real mode area for
> PPC64. Hence move DMA contiguous related changes into a seperate config
> so that ppc64 can enable CMA without requiring DMA contiguous.
>
> Signed
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
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, June 28, 2013 10:29 AM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Wood Scott-
> B07421
> Subject: Re: [V2,2/2] powerpc/85xx: workaround for chips with MSI
> hardware errata
>
> On W
On 07/01/2013 09:59 AM, Geert Uytterhoeven wrote:
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
And I think the DT code should check if the u64 fits in phys_addr_t and
if does not it should write an error messa
On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
wrote:
> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>> Apart from waste of 32bit, what is the other concern you
>> have ?
>
> You pass a u64 as a physical address which is represented in other
> parts of the kernel (for a good reason)
So because those things always end up in trainwrecks... In 7846de406
we moved back the iommu initialization earlier, essentially undoing
37f02195b which was causing us endless trouble... except that in the
meantime we had merged 959c9bdd58 (to workaround the original breakage)
which is now ... brok
On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>
> Sebastian,
>
> Apart from waste of 32bit, what is the other concern you
> have ?
You pass a u64 as a physical address which is represented in other
parts of the kernel (for a good reason) by phys_addr_t.
> I really want to converge on this pa
On Sun, 30 Jun 2013 18:23:00 +0200
Gerhard Sittig wrote:
...
> In hindsight, I'd prefer to reword the subject to something more
> specific, unless it's too late for this now. I suggest:
>
> [PATCH] powerpc/mpc512x: commit re-generated defconfig
>
> But if the patch is already queued somewhere
53 matches
Mail list logo
