> On Mon, 2012-06-25 at 18:40 -0700, Linus Torvalds wrote:
> > On Mon, Jun 25, 2012 at 5:56 PM, Kay Sievers wrote:
> > >
> > > Buffering has nice effects though:
> > > It makes continuation lines appear as one record in the buffer, not as
> > > n individual prints with n headers.
> >
> > As I alr
From: "Aneesh Kumar K.V"
Don't open code the same
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/cell/beat_htab.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/cell/beat_htab.c
b/arch/powerpc/platforms/cell/beat_htab.c
index 943c9d3.
From: "Aneesh Kumar K.V"
Don't open code the same
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/cell/beat_htab.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/cell/beat_htab.c
b/arch/powerpc/platforms/cell/beat_htab.c
index 943c9d3.
From: "Aneesh Kumar K.V"
This patch simplify hpte_decode for easy switching of virtual address to
virtual page number in the later patch
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/hash_native_64.c | 49 ++
1 file changed, 28 insertions(+), 21 dele
From: "Aneesh Kumar K.V"
This patch makes the high psizes mask as an unsigned char array
so that we can have more than 16TB. Currently we support upto
64TB
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/mmu-hash64.h |7 ++-
arch/powerpc/include/asm/page_64.h|7 ++-
ar
From: "Aneesh Kumar K.V"
This patch convert different functions to take virtual page number
instead of virtual address. Virtual page number is virtual address
shifted right by VPN_SHIFT (12) bits. This enable us to have an
address range of upto 76 bits.
Signed-off-by: Aneesh Kumar K.V
---
arch
From: "Aneesh Kumar K.V"
With larger vsid we need to track more bits of ESID in slb cache
for slb invalidate.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/paca.h |2 +-
arch/powerpc/mm/slb_low.S |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff -
On 07/05/2012 05:41 AM, Li Zhong wrote:
> On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote:
>> On 07/04/2012 01:00 PM, Li Zhong wrote:
>>> On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote:
> Looking through the emails it seems that there is an issue with alias
> strings.
>>
Hi,
This patchset include patches for supporting 64TB with ppc64. I haven't booted
this on hardware with 64TB memory yet. But they boot fine on real hardware with
less memory. Changes extend VSID bits to 38 bits for a 256MB segment
and 26 bits for 1TB segments.
Changes from V1:
* Drop the usage
From: "Aneesh Kumar K.V"
As we keep increasing PGTABLE_RANGE we need not increase the virual
map area for kernel.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pgtable-ppc64.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pgtable
From: "Aneesh Kumar K.V"
Increase max addressable range to 64TB. This is not tested on
real hardware yet.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/mmu-hash64.h|8
arch/powerpc/include/asm/pgtable-ppc64-4k.h |2 +-
arch/powerpc/include/asm/pgtable-p
From: "Aneesh Kumar K.V"
Rename the variable to better reflect the values. No functional change
in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s.h |2 +-
arch/powerpc/include/asm/machdep.h |6 +--
arch/powerpc/include/asm/mmu-hash64.h |
From: "Aneesh Kumar K.V"
Increase the number of valid VSID bits in slbmte instruction.
We will use the new bits when we increase valid VSID bits.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/slb_low.S |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerp
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested':
(.text+0x4): sibling call optimization to `_savegpr0_29' does not allow
automatic multiple TOCs; recompile with -m
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, July 04, 2012 4:41 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; qemu-...@nongnu.org
> Subject: Re: [Qemu-ppc] [RFC PATCH 04/
On Thu, 2012-07-05 at 12:23 +0400, Glauber Costa wrote:
> On 07/05/2012 05:41 AM, Li Zhong wrote:
> > On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote:
> >> On 07/04/2012 01:00 PM, Li Zhong wrote:
> >>> On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote:
> > Looking through the em
On Thu, Jul 05, 2012 at 06:33:45PM +1000, Stephen Rothwell wrote:
> powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested':
> (.text+0x4): sibling call optimization to `_savegpr0_29' does not allow
> automatic multiple TOCs; recompile with -mminimal-toc or
> -fno-optimize-si
On Wed, Jul 04, 2012 at 10:19:54AM -0500, Tabi Timur-B04825 wrote:
> Zhao Chenhui wrote:
> > On Tue, Jul 03, 2012 at 10:17:12PM -0500, Tabi Timur-B04825 wrote:
> >> Zhao Chenhui wrote:
> >>> If the guts variable is NULL, it indicates there is error in dts or
> >>> kernel.
> >>> We should fix the e
Kay Sievers wrote:
> On Thu, Jul 5, 2012 at 10:39 AM, Kay Sievers wrote:
> > On Thu, Jul 5, 2012 at 9:03 AM, Michael Neuling wrote:
> >>> On Mon, 2012-06-25 at 18:40 -0700, Linus Torvalds wrote:
> >
> >>> > I think it might be a great idea to buffer for logging in order to
> >>> > generate one
On Thu, Jul 5, 2012 at 9:03 AM, Michael Neuling wrote:
>> On Mon, 2012-06-25 at 18:40 -0700, Linus Torvalds wrote:
>> > I think it might be a great idea to buffer for logging in order to
>> > generate one individual buffer record there.
>> >
>> > But it needs to be printed as it is generated.
>>
On Thu, Jul 5, 2012 at 10:39 AM, Kay Sievers wrote:
> On Thu, Jul 5, 2012 at 9:03 AM, Michael Neuling wrote:
>>> On Mon, 2012-06-25 at 18:40 -0700, Linus Torvalds wrote:
>
>>> > I think it might be a great idea to buffer for logging in order to
>>> > generate one individual buffer record there.
>
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, July 04, 2012 4:50 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; qemu-...@nongnu.org
> Subject: Re: [Qemu-ppc] [RFC PATCH 0
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
> ow...@vger.kernel.org] On Behalf Of Alexander Graf
> Sent: Wednesday, July 04, 2012 4:56 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
On Thu, Jul 5, 2012 at 12:20 PM, Michael Neuling wrote:
> I can only make 2) happen on SMP. It's when the second CPU is coming up
> and it's printing something. The first CPU isn't printing anything at
> this stage (there is no garbled console here) so I don't think it's a
> race. I see it con
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, July 04, 2012 4:34 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; qemu-...@nongnu.org
> Subject: Re: [Qemu-ppc] [RFC PATCH 03/
On 07/05/2012 01:49 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Wednesday, July 04, 2012 4:34 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; qemu-...@n
On Thu, 2012-07-05 at 13:47 +0200, Kay Sievers wrote:
> On Thu, Jul 5, 2012 at 12:20 PM, Michael Neuling wrote:
>
> > I can only make 2) happen on SMP. It's when the second CPU is coming up
> > and it's printing something. The first CPU isn't printing anything at
> > this stage (there is no gar
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, July 05, 2012 3:13 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; qemu-...@nongnu.org
> Subject: Re: [Qemu-ppc] [RFC PATCH 03/1
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, July 05, 2012 1:03 AM
> To: Stephen Rothwell
> Cc: linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; Yoder
> Stuart-B08248; ppc-dev
> Subject: Re: linux-next: build failure after merge of the kvm
From: Stuart Yoder
Signed-off-by: Stuart Yoder
---
-v4: fixed build issues in exception-64s.h and exceptions-64s.S
arch/powerpc/include/asm/exception-64s.h |4 ++--
arch/powerpc/include/asm/thread_info.h |6 ++
arch/powerpc/kernel/entry_32.S | 24 -
In order to enable the DIU video controller on the P1022DS, the FPGA needs
to be switched to "indirect mode", where the localbus is disabled and
the FPGA is accessed via writes to localbus chip select signals CS0 and CS1.
To obtain the address of CS0 and CS1, the platform driver uses an "indirect
Zhao Chenhui wrote:
> If the guts node is missing, this code snippet will be skipped. If the guts
> node is existed,
> the return value of of_iomap(), namely guts, will be tested. If it is NULL,
> it shows
> that there is error in dts, or the ioremap() in of_iomap() failed. I think
> these errors
On Tue, Jul 3, 2012 at 5:21 AM, Zhao Chenhui wrote:
> Do hardware timebase sync. Firstly, stop all timebases, and transfer
> the timebase value of the boot core to the other core. Finally,
> start all timebases.
>
> Only apply to dual-core chips, such as MPC8572, P2020, etc.
>
> Signed-off-by: Zha
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Wednesday, June 27, 2012 1:16 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; qemu-...@nongnu.org; Anton Blanchard
> Su
On 07/03/2012 10:45 PM, Zhao Chenhui wrote:
> On Tue, Jul 03, 2012 at 10:17:12PM -0500, Tabi Timur-B04825 wrote:
>> Zhao Chenhui wrote:
>>> If the guts variable is NULL, it indicates there is error in dts or kernel.
>>> We should fix the error, rather than ignore it.
>>
>> And that's why there's a
This reverts commit 96cc017c5b7ec095ef047d3c1952b6b6bbf98943.
The P3060 was cancelled before it went into production, so there's no point
in supporting it.
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/fsl/p3060si-post.dtsi | 302 --
arch/powerpc/boot/dts/fsl/p30
On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose wrote:
>> Not sure if this is related, but at the end of each kernel compilation,
>> the following messages are printed:
>>
>>
>>SYSMAP System.map
>>SYSMAP .tmp_System.map
>>WRAParch/powerpc/boot/zImage.pmac
>> INFO:
On 07/04/2012 08:40 AM, Alexander Graf wrote:
> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>> @@ -381,7 +386,8 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu
>> *vcpu,
>> set_guest_esr(vcpu, vcpu->arch.queued_esr);
>> if (update_dear == true)
>>
On 07/04/2012 01:15 PM, Caraman Mihai Claudiu-B02008 wrote:
>>
>> From: Alexander Graf [ag...@suse.de]
>> Sent: Wednesday, July 04, 2012 6:45 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: ; KVM list; linuxppc-dev; qemu-...@nongnu.org
>> List; Benjamin Herre
Hi Alan,
On Thu, 5 Jul 2012 19:13:48 +0930 Alan Modra wrote:
>
> On Thu, Jul 05, 2012 at 06:33:45PM +1000, Stephen Rothwell wrote:
> > powerpc64-linux-ld: drivers/built-in.o: In function
> > `.gpiochip_is_requested':
> > (.text+0x4): sibling call optimization to `_savegpr0_29' does not allow
>
Kay Sievers wrote:
> On Thu, 2012-07-05 at 13:47 +0200, Kay Sievers wrote:
> > On Thu, Jul 5, 2012 at 12:20 PM, Michael Neuling wrote:
> >
> > > I can only make 2) happen on SMP. It's when the second CPU is coming up
> > > and it's printing something. The first CPU isn't printing anything at
On Fri, Jul 6, 2012 at 2:41 AM, Michael Neuling wrote:
>> > Does this happen only very early during bootup, or also later when the
>> > box fully initialized?
>
> I'm seeing during boot but not later (xmon (ppc kernel debugger) doesn't
> see it if I do 'echo x > /proc/sysrq-trigger') . I wouldn'
On Fri, Jul 06, 2012 at 10:21:51AM +1000, Stephen Rothwell wrote:
> which have now been fixed. So would a simple patch that puts the
> _savegpr etc functions in their own section (defined how?) fix this for
> us?
Ah, the kernel provides its own save/restore functions, and these get
mashed into a
Newer gcc are being a bit blind here (it's pretty obvious we don't
reach the code path using the array if we haven't initialized the
pointer) but none of that is performance critical so let's just
silence it.
Signed-off-by: Benjamin Herrenschmidt
---
diff --git a/arch/powerpc/mm/numa.c b/arch/po
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+leoli=freescale@lists.ozlabs.org] On Behalf Of Vineeth
> Sent: Wednesday, July 04, 2012 1:16 AM
> To: linux-embed...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> linuxppc-embed...@ozlabs.org; Wood Scott-B07
Hi Alan,
On Fri, 6 Jul 2012 10:27:10 +0930 Alan Modra wrote:
>
> On Fri, Jul 06, 2012 at 10:21:51AM +1000, Stephen Rothwell wrote:
> > which have now been fixed. So would a simple patch that puts the
> > _savegpr etc functions in their own section (defined how?) fix this for
> > us?
>
> Ah, the
Kay Sievers wrote:
> On Fri, Jul 6, 2012 at 2:41 AM, Michael Neuling wrote:
>
> >> > Does this happen only very early during bootup, or also later when the
> >> > box fully initialized?
> >
> > I'm seeing during boot but not later (xmon (ppc kernel debugger) doesn't
> > see it if I do 'echo x >
Michael Neuling wrote:
> Kay Sievers wrote:
>
> > On Fri, Jul 6, 2012 at 2:41 AM, Michael Neuling wrote:
> >
> > >> > Does this happen only very early during bootup, or also later when the
> > >> > box fully initialized?
> > >
> > > I'm seeing during boot but not later (xmon (ppc kernel debug
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, June 19, 2012 12:53 AM
> To: Sethi Varun-B16395
> Cc: Wood Scott-B07421; Kumar Gala; Linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
>
> On 06/18/2012 02:19 PM, Sethi
On 07/06/2012 04:06 AM, Tabi Timur-B04825 wrote:
On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose wrote:
Not sure if this is related, but at the end of each kernel compilation,
the following messages are printed:
SYSMAP System.map
SYSMAP .tmp_System.map
WRAParc
On Fri, Jul 06, 2012 at 01:01:37PM +1000, Stephen Rothwell wrote:
> solos-pci.c:(.text+0x1ff923c): relocation truncated to fit: R_PPC64_REL24
^
> I assume at this point, we are just too large.
Yeah, but not in total. I didn't see any of these in the allyes
kernel I b
51 matches
Mail list logo
