LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: linux-next: build failure after merge of the final tree
From: Alan Modra @ 2012-07-06  6:08 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-kernel, linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120706130137.6aae96c0072af1f330249c0d@canb.auug.org.au>

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 built with our proof of concept hack to avoid ld -r.  I think
you'll find that these are all from ld -r output, as I assume no one
in kernel land writes drivers or whatever with 33M of text in a single
file.  Branches in that monstrous section can't even reach the
trampolines that ld inserts to extend branch reach.  Did I mention
that ld -r is a bad idea?

One workaround might be to compile with -ffunction-sections.

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply

* Re: 3.4.0-rc1: No init found
From: Suzuki K. Poulose @ 2012-07-06  5:20 UTC (permalink / raw)
  To: Tabi Timur-B04825
  Cc: Christian Kujau, linuxppc-dev@lists.ozlabs.org, LKML, Al Viro
In-Reply-To: <CAOZdJXVhtxoiY0kvsC+zgrETgd_MxTR+nf+6JDMV5Y-osqVqaw@mail.gmail.com>

On 07/06/2012 04:06 AM, Tabi Timur-B04825 wrote:
> On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose <suzuki@in.ibm.com> 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
>>>     WRAP    arch/powerpc/boot/zImage.pmac
>>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>>> wrapper(0x400000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>>     WRAP    arch/powerpc/boot/zImage.coff
>>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>>> wrapper(0x500000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>>     WRAP    arch/powerpc/boot/zImage.miboot
>>> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
>>> wrapper(0x400000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>>     Building modules, stage 2.
>>>     MODPOST 24 modules
>>> ------------
>>>
>>> I started to see these messages in January (around Linux 3.2.0), but never
>>> investigated what it was since the produced kernels continued to boot just
>>> fine.
>>
>>
>> The above change was added by me. The message is printed when the 'wrapper'
>> script finds that decompressed kernel overlaps the 'bootstrap code' which
>> does the decompression. So it shifts the 'address' of the bootstrap code to
>> the next higher MB. As such it is harmless.
>
> I see this message every time when I build the kernel.  I know it's
> harmless, but is this something that can be "fixed"?  That is, can we
> change some linker script (or whatever) to make 0x700000 the default
> value?

You could do this by setting the link_address by checking your platform,
like some of the other platforms (e.g, pseries, ps3 ).

Or

we could add a parameter to the wrapper script to set the link_address ?

Ben, Josh,
What do you think ?

  Or maybe modify the wrapper script to just automatically find
> the right spot without printing a message?

We need the message there for people who have restriction of a fixed 
link address. This would help them to handle the situation accordingly
than blindly failing on boot.

Thanks
Suzuki

^ permalink raw reply

* RE: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
From: Sethi Varun-B16395 @ 2012-07-06  4:02 UTC (permalink / raw)
  To: Wood Scott-B07421; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FDF8031.3090705@freescale.com>



> -----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.
>=20
> On 06/18/2012 02:19 PM, Sethi Varun-B16395 wrote:
> >
> >
> >> -----Original Message-----
> >> From: Wood Scott-B07421
> >> Sent: Tuesday, June 19, 2012 12:47 AM
> >> To: Sethi Varun-B16395
> >> Cc: Kumar Gala; Wood Scott-B07421; Linuxppc-dev@lists.ozlabs.org
> >> Subject: Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt
> support.
> >>
> >> On 06/18/2012 02:12 PM, Sethi Varun-B16395 wrote:
> >>>
> >>>
> >>>>>> +/*
> >>>>>>> + * Error interrupt registers
> >>>>>>> + */
> >>>>>>> +
> >>>>>>> +#define MPIC_ERR_INT_BASE	0x3900
> >>>>>>> +#define MPIC_ERR_INT_EISR	0x0000
> >>>>>>> +#define MPIC_ERR_INT_EIMR	0x0010
> >>>>>>> +
> >>>>>>> #define MPIC_MAX_IRQ_SOURCES	2048
> >>>>>>> #define MPIC_MAX_CPUS		32
> >>>>>>> #define MPIC_MAX_ISU		32
> >>>>>>>
> >>>>>>> #define MPIC_MAX_TIMER    8
> >>>>>>> #define MPIC_MAX_IPI      4
> >>>>>>> +#define MPIC_MAX_ERR      32
> >>>>>>
> >>>>>> Should probably be 64
> >>>>>
> >>>>> This patch supports MPIC 4.1 and EISR0.  When support is added for
> >>>>> EISR1 (didn't realize this was coming until your comment prompted
> >>>>> me to check...), this should be updated, but this change alone
> >>>>> would not make it work.
> >>>>
> >>>> Would prefer we handle this now rather than later (T4240 is going
> >>>> to need
> >>>> EISR1 support).
> >>> Hi Kumar,
> >>> As of now I don't have a proper mechanism to test this functionality.
> >>> I will submit a follow up patch for EISR1/EIMR1 support once I have
> >>> a mechanism to test this functionality.
> >>
> >> You could still write the code in a way that scales to multiple
> >> EISRs, and test that it works with EISR0.
> >>
> > Yes, but I would like to submit the patch once I have tested it.
>=20
> So test it the way I described, and submit. :-P
There just seem to be 32 error interrupts even in case of T4240, that means=
 there is no
need to handle multiple EISRs.

I have already submitted a revised patch for handling MPIC error interrupts=
.
[PATCH 3/3 v2] powerpc/mpic: FSL MPIC error interrupt support

-Varun

^ permalink raw reply

* Re: [PATCH v3] printk: Have printk() never buffer its data
From: Michael Neuling @ 2012-07-06  3:47 UTC (permalink / raw)
  To: Kay Sievers
  Cc: Greg Kroah-Hartman, LKML, Steven Rostedt, Paul E. McKenney,
	linuxppc-dev, Joe Perches, Andrew Morton, Wu Fengguang,
	Linus Torvalds, Ingo Molnar
In-Reply-To: <29711.1341545979@neuling.org>

Michael Neuling <mikey@neuling.org> wrote:

> Kay Sievers <kay@vrfy.org> wrote:
> 
> > On Fri, Jul 6, 2012 at 2:41 AM, Michael Neuling <mikey@neuling.org> 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't say
> > > it's "very early boot".  It's a secondary CPU coming up and the primary
> > > is waiting for it.  We've already configured the console when this
> > > happens.
> > 
> > Sounds like an early boot console.
> > 
> > >> > The output of 'dmesg' later looks always correct, right?
> > >
> > > No, dmesg also has the extra new lines: eg
> > >
> > > <4>NIP: c00000000004e234 LR: c00000000004e230 CTR: 0000000000000000
> > > <4>REGS: c00000007c3b7b50 TRAP: 0700   Tainted: G        W     (3.5.0-rc4-mikey)
> > > <4>MSR: 9000000000021032
> > > <4><
> > > <4>SF
> > > <4>,HV
> > > <4>,ME
> > > <4>,IR
> > > <4>,DR
> > > <4>,RI
> > > <4>>
> > > <4>  CR: 28000042  XER: 22000000
> > 
> > Can you please paste the output of /dev/kmsg of this section? So we
> > can see the timestamps and what really went into the record buffer.
> 
> Sure.
> 
> 4,89,24561;NIP: c000000000048164 LR: c000000000048160 CTR: 0000000000000000
> 4,90,24576;REGS: c00000007e59fb50 TRAP: 0700   Tainted: G        W     (3.5.0-rc4-mikey)
> 4,91,24583;MSR: 9000000000021032 
> 4,92,24586;<
> 4,93,24591;SF
> 4,94,24596;,HV
> 4,95,24601;,ME
> 4,96,24606;,IR
> 4,97,24611;,DR
> 4,98,24616;,RI
> 4,99,24619;>
> 4,100,24628;  CR: 28000042  XER: 22000000

FWIW, compiling with the parent commit gives this:

4,89,1712;NIP: c000000000048164 LR: c000000000048160 CTR: 0000000000000000
4,90,1713;REGS: c00000007e59fb50 TRAP: 0700   Tainted: G        W     (3.5.0-rc4-mikey)
4,91,1716;MSR: 9000000000021032 <SF,HV,ME,IR,DR,RI>  CR: 22000082  XER: 02000000

Mikey

> 
> > 
> > >> Could you possibly try this patch?
> > >
> > > Sorry, doesn't help.  It also reprints the entire boot log to the
> > > console once the console get inited.
> > 
> > Which is the normal behaviour to do that, right? We should not have
> > touched any of that logic.
> 
> Not until this patch you asked me to try.  Hence why I noted it.  
> 
> Mikey

^ permalink raw reply

* Re: [PATCH v3] printk: Have printk() never buffer its data
From: Michael Neuling @ 2012-07-06  3:39 UTC (permalink / raw)
  To: Kay Sievers
  Cc: Greg Kroah-Hartman, LKML, Steven Rostedt, Paul E. McKenney,
	linuxppc-dev, Joe Perches, Andrew Morton, Wu Fengguang,
	Linus Torvalds, Ingo Molnar
In-Reply-To: <CAPXgP12_F_H2XPpo2wFmb-u3jBdV__=h67R-LVYbqHuLh7tqLg@mail.gmail.com>

Kay Sievers <kay@vrfy.org> wrote:

> On Fri, Jul 6, 2012 at 2:41 AM, Michael Neuling <mikey@neuling.org> 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't say
> > it's "very early boot".  It's a secondary CPU coming up and the primary
> > is waiting for it.  We've already configured the console when this
> > happens.
> 
> Sounds like an early boot console.
> 
> >> > The output of 'dmesg' later looks always correct, right?
> >
> > No, dmesg also has the extra new lines: eg
> >
> > <4>NIP: c00000000004e234 LR: c00000000004e230 CTR: 0000000000000000
> > <4>REGS: c00000007c3b7b50 TRAP: 0700   Tainted: G        W     (3.5.0-rc4-mikey)
> > <4>MSR: 9000000000021032
> > <4><
> > <4>SF
> > <4>,HV
> > <4>,ME
> > <4>,IR
> > <4>,DR
> > <4>,RI
> > <4>>
> > <4>  CR: 28000042  XER: 22000000
> 
> Can you please paste the output of /dev/kmsg of this section? So we
> can see the timestamps and what really went into the record buffer.

Sure.

4,89,24561;NIP: c000000000048164 LR: c000000000048160 CTR: 0000000000000000
4,90,24576;REGS: c00000007e59fb50 TRAP: 0700   Tainted: G        W     (3.5.0-rc4-mikey)
4,91,24583;MSR: 9000000000021032 
4,92,24586;<
4,93,24591;SF
4,94,24596;,HV
4,95,24601;,ME
4,96,24606;,IR
4,97,24611;,DR
4,98,24616;,RI
4,99,24619;>
4,100,24628;  CR: 28000042  XER: 22000000

> 
> >> Could you possibly try this patch?
> >
> > Sorry, doesn't help.  It also reprints the entire boot log to the
> > console once the console get inited.
> 
> Which is the normal behaviour to do that, right? We should not have
> touched any of that logic.

Not until this patch you asked me to try.  Hence why I noted it.  

Mikey

^ permalink raw reply

* Re: linux-next: build failure after merge of the final tree
From: Stephen Rothwell @ 2012-07-06  3:01 UTC (permalink / raw)
  To: Alan Modra; +Cc: linux-kernel, linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120706005709.GB5805@bubble.grove.modra.org>

[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]

Hi Alan,

On Fri, 6 Jul 2012 10:27:10 +0930 Alan Modra <amodra@gmail.com> 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 kernel provides its own save/restore functions, and these get
> mashed into a .text containing normal functions with toc references by
> ld -r.  Well, you could stop using ld -r.  Otherwise, try
> 
>  .section ".text.save.restore","ax",@progbits

OK, so that helped a lot.  Now I get this:

drivers/built-in.o: In function `.idt77252_init_ubr.isra.10':
idt77252.c:(.text+0x1ff801c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.idt77252_init_tx':
idt77252.c:(.text+0x1ff8258): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.idt77252_change_qos':
idt77252.c:(.text+0x1ff86a0): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.idt77252_open':
idt77252.c:(.text+0x1ff898c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
idt77252.c:(.text+0x1ff8f4c): relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_22' defined in .text.save.restore section in arch/powerpc/lib/built-in.o
drivers/built-in.o: In function `.next_string':
solos-pci.c:(.text+0x1ff8f54): relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o
solos-pci.c:(.text+0x1ff8f64): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.print_buffer':
solos-pci.c:(.text+0x1ff904c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.atm_remove':
solos-pci.c:(.text+0x1ff91d4): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
solos-pci.c:(.text+0x1ff923c): relocation truncated to fit: R_PPC64_REL24 against symbol `.sysfs_remove_group' defined in .text section in fs/built-in.o
drivers/built-in.o: In function `.fpga_tx':
solos-pci.c:(.text+0x1ff950c): additional relocation overflows omitted from the output

I assume at this point, we are just too large.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* RE: rionet driver with MMIO DMA capability
From: Li Yang-R58472 @ 2012-07-06  2:51 UTC (permalink / raw)
  To: Vineeth, linux-embedded@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linuxppc-embedded@ozlabs.org,
	Wood Scott-B07421, mporter@kernel.crashing.org
  Cc: Alexandre Bounine, ranenikhil19@gmail.com
In-Reply-To: <CAFbQSaDWXTg429q-tTRvcgAEsA1OmHzFVhPNOmSRnWjMpSZfpA@mail.gmail.com>



> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+leoli=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Vineeth
> Sent: Wednesday, July 04, 2012 1:16 AM
> To: linux-embedded@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> linuxppc-embedded@ozlabs.org; Wood Scott-B07421;
> mporter@kernel.crashing.org
> Cc: ranenikhil19@gmail.com
> Subject: rionet driver with MMIO DMA capability
>=20
>=20
> Hi,
>=20
> With kernel mainstream version 3.5.rc-5 there's SRIO low level driver
> with DMA support for MMIO. But the rionet driver in the same kernel
> version doesnt support MMIO.
>=20
> We are trying to find the maximum bandwidth that we can achieve using our
> custom board's(quad MPC8641 )=A0 4-lane SRIO.
> Now we are worried how to use this SRIO low level driver effectively ?
>=20
> The RIOnet driver (with 3.5.-rc5) uses message based communication. This
> doesnt use the DMA capability of low level driver. with this we are
> getting a bandwidth of nearly 900Mbps, which is very less.
>=20
> Is there any example code or modified middle ware driver for rionet/ or
> any code which uses the low level driver apis with MMIO DMA??

We provided the support for DMA in the old BSPs but didn't got the luck to =
make it upstream.  I heard Alex (CCed) is working on an upstream-able versi=
on of the feature.  Probably he can help to provide some code.

Leo

^ permalink raw reply

* [PATCH] powerpc/numa: Avoid stupid uninitialized warning from gcc
From: Benjamin Herrenschmidt @ 2012-07-06  2:30 UTC (permalink / raw)
  To: linuxppc-dev

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 <benh@kernel.crashing.org>
---

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 7c28589..39b1597 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -641,7 +641,7 @@ static void __init parse_drconf_memory(struct device_node *memory)
 	unsigned int n, rc, ranges, is_kexec_kdump = 0;
 	unsigned long lmb_size, base, size, sz;
 	int nid;
-	struct assoc_arrays aa;
+	struct assoc_arrays aa = { .arrays = NULL };
 
 	n = of_get_drconf_memory(memory, &dm);
 	if (!n)

^ permalink raw reply related

* Re: linux-next: build failure after merge of the final tree
From: Alan Modra @ 2012-07-06  0:57 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-kernel, linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120706102151.fd4f769cf2aa3f753ad178bf@canb.auug.org.au>

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 .text containing normal functions with toc references by
ld -r.  Well, you could stop using ld -r.  Otherwise, try

 .section ".text.save.restore","ax",@progbits

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply

* Re: [PATCH v3] printk: Have printk() never buffer its data
From: Kay Sievers @ 2012-07-06  0:56 UTC (permalink / raw)
  To: Michael Neuling
  Cc: Greg Kroah-Hartman, LKML, Steven Rostedt, Paul E. McKenney,
	linuxppc-dev, Joe Perches, Andrew Morton, Wu Fengguang,
	Linus Torvalds, Ingo Molnar
In-Reply-To: <30233.1341535279@neuling.org>

On Fri, Jul 6, 2012 at 2:41 AM, Michael Neuling <mikey@neuling.org> 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't say
> it's "very early boot".  It's a secondary CPU coming up and the primary
> is waiting for it.  We've already configured the console when this
> happens.

Sounds like an early boot console.

>> > The output of 'dmesg' later looks always correct, right?
>
> No, dmesg also has the extra new lines: eg
>
> <4>NIP: c00000000004e234 LR: c00000000004e230 CTR: 0000000000000000
> <4>REGS: c00000007c3b7b50 TRAP: 0700   Tainted: G        W     (3.5.0-rc4-mikey)
> <4>MSR: 9000000000021032
> <4><
> <4>SF
> <4>,HV
> <4>,ME
> <4>,IR
> <4>,DR
> <4>,RI
> <4>>
> <4>  CR: 28000042  XER: 22000000

Can you please paste the output of /dev/kmsg of this section? So we
can see the timestamps and what really went into the record buffer.

>> Could you possibly try this patch?
>
> Sorry, doesn't help.  It also reprints the entire boot log to the
> console once the console get inited.

Which is the normal behaviour to do that, right? We should not have
touched any of that logic.

Thanks,
Kay

^ permalink raw reply

* Re: [PATCH v3] printk: Have printk() never buffer its data
From: Michael Neuling @ 2012-07-06  0:41 UTC (permalink / raw)
  To: Kay Sievers
  Cc: Greg Kroah-Hartman, LKML, Steven Rostedt, Paul E. McKenney,
	linuxppc-dev, Joe Perches, Andrew Morton, Wu Fengguang,
	Linus Torvalds, Ingo Molnar
In-Reply-To: <1341492628.834.3.camel@mop>

Kay Sievers <kay@vrfy.org> wrote:

> On Thu, 2012-07-05 at 13:47 +0200, Kay Sievers wrote:
> > On Thu, Jul 5, 2012 at 12:20 PM, Michael Neuling <mikey@neuling.org> 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 consistently in show_regs().  Every printk without a
> > > newline.  ie I get this:
> > > ---
> > > NIP: c000000000048164 LR: c000000000048160 CTR: 0000000000000000
> > > REGS: c00000007e59fb50 TRAP: 0700   Tainted: G        W     (3.5.0-rc5-mikey)
> > > MSR: 9000000000021032
> > > <
> > > SF
> > > ,HV
> > > ,ME
> > > ,IR
> > > ,DR
> > > ,RI
> > >>
> > >   CR: 28000042  XER: 22000000
> > > SOFTE: 0
> > > CFAR: c0000000007402f8
> > > TASK = c00000007e56bb40[0] 'swapper/1' THREAD: c00000007e59c000
> > >  CPU: 1
> > > ---
> > >
> > > It's consistent for printks without newlines in show_regs().  MSR
> > > through to XER should all be on the same line.
> > 
> > I see. Something to fix then, I'll have a look.
> > 
> > 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't say
it's "very early boot".  It's a secondary CPU coming up and the primary
is waiting for it.  We've already configured the console when this
happens.

> > 
> > The output of 'dmesg' later looks always correct, right?

No, dmesg also has the extra new lines: eg

<4>NIP: c00000000004e234 LR: c00000000004e230 CTR: 0000000000000000
<4>REGS: c00000007c3b7b50 TRAP: 0700   Tainted: G        W     (3.5.0-rc4-mikey)
<4>MSR: 9000000000021032 
<4><
<4>SF
<4>,HV
<4>,ME
<4>,IR
<4>,DR
<4>,RI
<4>>
<4>  CR: 28000042  XER: 22000000
<4>SOFTE: 0
<4>CFAR: c0000000008139b4
<4>TASK = c00000007c3a4e00[0] 'swapper/1' THREAD: c00000007c3b4000
<4> CPU: 1
<4>

> If it's an early printk issue like it looks like, where stuff got
> printed before we had any console registered, this might fix the issue
> you are seeing.
>
> Could you possibly try this patch?

Sorry, doesn't help.  It also reprints the entire boot log to the
console once the console get inited.

FWIW HVC RTAS is the console.

Mikey

> 
> Thanks,
> Kay
> 
> 
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -1957,6 +1951,12 @@ skip:
>  			 */
>  			console_idx = log_next(console_idx);
>  			console_seq++;
> +			/*
> +			 * We will get here again when we register a new
> +			 * CON_PRINTBUFFER console. Clear the flag so we
> +			 * will properly dump everything later.
> +			 */
> +			msg->flags &= ~LOG_NOCONS;
>  			goto skip;
>  		}
>  
> 

^ permalink raw reply

* Re: linux-next: build failure after merge of the final tree
From: Stephen Rothwell @ 2012-07-06  0:21 UTC (permalink / raw)
  To: Alan Modra; +Cc: linux-kernel, linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120705094348.GA5805@bubble.grove.modra.org>

[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]

Hi Alan,

On Thu, 5 Jul 2012 19:13:48 +0930 Alan Modra <amodra@gmail.com> 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 automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_savegpr0_29' extern
> > 
> > I got more than 60000 of these messages before I killed the link. :-(  I
> > am not sure what has changed to do this, but it may have been masked for
> > the past few releases due to other linking problems.
> 
> Let me guess.  You're using bleeding edge gcc but not binutils.

powerpc-linux-gcc (GCC) 4.6.3
GNU ld (GNU Binutils) 2.22

both built from upstream sources (by Tony).

> a) Recent gcc has fixed prologue and epilogue generation which now
>    properly makes use of out-of-line register save and restore
>    functions when compiling with -Os.
> b) Recent ld doesn't emit out-of-line save/restore function for ld -r,
>    but yours does.  You need my 2012-06-22 patch.
> c) Kernel uses ld -r for packaging.
> 
> (b) and (c) together mean you get a definition for _savegpr0_29 munged
> together with other functions.  That's bad.  If _savegpr0_29 wasn't
> emitted until the final link stage then it would be in a code section
> containing just save/restore functions.  ld will analyse that section
> and notice the absense of toc relocations; functions therein don't
> use the toc and can thus be called from any toc group without needing
> a toc adjusting stub.  In your case _savegpr0_29 is in a section that
> has toc relocations (from normal compiled code), so ld decides that
> any function in that section must have a proper value for the toc
> register.  But calls to _savegpr0_29 don't have a following nop to
> overwrite with a toc restore insn, hence the ld error.
> 
> Score another black mark for ld -r.

OK, the new toolchain may be the problem.  I changed from:

powerpc-linux-gcc (GCC) 4.6.0
GNU ld (GNU Binutils) 2.21

on June 20 and the current errors may have been masked an early bailout
after getting theses errors:

powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word':
(.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern

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?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
From: Scott Wood @ 2012-07-06  0:19 UTC (permalink / raw)
  To: Caraman Mihai Claudiu-B02008
  Cc: KVM list, Alexander Graf, <kvm-ppc@vger.kernel.org>,
	qemu-ppc@nongnu.org List, linuxppc-dev
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF15A82E@039-SN2MPN1-013.039d.mgd.msft.net>

On 07/04/2012 01:15 PM, Caraman Mihai Claudiu-B02008 wrote:
>> ________________________________________
>> From: Alexander Graf [agraf@suse.de]
>> Sent: Wednesday, July 04, 2012 6:45 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: <kvm-ppc@vger.kernel.org>; KVM list; linuxppc-dev; qemu-ppc@nongnu.org List; Benjamin Herrenschmidt
>> Subject: Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
>>
>> On 04.07.2012, at 17:27, Caraman Mihai Claudiu-B02008 wrote:
>>
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Wednesday, July 04, 2012 5:30 PM
>>>> To: Caraman Mihai Claudiu-B02008
>>>> Cc: <kvm-ppc@vger.kernel.org>; KVM list; linuxppc-dev; qemu-
>>>> ppc@nongnu.org List; Benjamin Herrenschmidt
>>>> Subject: Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM
>>>> kernel hooks
>>>>
>>>>
>>>> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>>>>
>>>>> Hook DO_KVM macro to 64-bit booke in a optimal way similar to 32-bit
>>>> booke
>>>>> see head_fsl_booke.S file. Extend interrupt handlers' parameter list
>>>> with
>>>>> interrupt vector numbers to accomodate the macro. Rework Guest Doorbell
>>>>> handler to use the proper GSRRx save/restore registers.
>>>>> Only the bolted version of tlb miss handers is addressed now.
>>>>>
>>>>> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>>>>> ---
>>>>> arch/powerpc/kernel/exceptions-64e.S |  114 ++++++++++++++++++++++++---
>>>> -------
>>>>> arch/powerpc/mm/tlb_low_64e.S        |   14 +++-
>>>>> 2 files changed, 92 insertions(+), 36 deletions(-)
>>>>>
>>>>> diff --git a/arch/powerpc/kernel/exceptions-64e.S
>>>> b/arch/powerpc/kernel/exceptions-64e.S
>>>>> index 06f7aec..a60f81f 100644
>>>>> --- a/arch/powerpc/kernel/exceptions-64e.S
>>>>> +++ b/arch/powerpc/kernel/exceptions-64e.S
>>>>> @@ -25,6 +25,8 @@
>>>>> #include <asm/ppc-opcode.h>
>>>>> #include <asm/mmu.h>
>>>>> #include <asm/hw_irq.h>
>>>>> +#include <asm/kvm_asm.h>
>>>>> +#include <asm/kvm_booke_hv_asm.h>
>>>>>
>>>>> /* XXX This will ultimately add space for a special exception save
>>>>> *     structure used to save things like SRR0/SRR1, SPRGs, MAS, etc...
>>>>> @@ -34,13 +36,24 @@
>>>>> */
>>>>> #define     SPECIAL_EXC_FRAME_SIZE  INT_FRAME_SIZE
>>>>>
>>>>> +#ifdef CONFIG_KVM_BOOKE_HV
>>>>> +#define KVM_BOOKE_HV_MFSPR(reg, spr)                               \
>>>>> +   BEGIN_FTR_SECTION                                       \
>>>>> +           mfspr   reg, spr;                               \
>>>>> +   END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
>>>>> +#else
>>>>> +#define KVM_BOOKE_HV_MFSPR(reg, spr)
>>>>> +#endif
>>>>
>>>> Bleks - this is ugly.
>>>
>>> I agree :) But I opted to keep the optimizations done for 32-bit.
>>>
>>>> Do we really need to open-code the #ifdef here?
>>>
>>> 32-bit implementation fortunately use asm macros, we can't nest defines.
>>>
>>>> Can't the feature section code determine that the feature is disabled and
>>>> just always not include the code?
>>>
>>> CPU_FTR_EMB_HV is set even if KVM is not configured.
>>
>> I don't get the point then. Why not have the whole DO_KVM masked under FTR_SECTION_IFSET(CPU_FTR_EMB_HV)? Are there book3s_64 implementations without HV? 
> 
> I guess you refer to book3e_64. I don't know all implementations but Embedded.HV category is optional.
> 
>> Can't we just mfspr unconditionally in DO_KVM?
> 
> I think Scott should better answer this question, I don't know why he opted for the other approach.

That was on 32-bit, where some of DO_KVM's users want SRR1 for their own
purposes.

>>>>> -.macro tlb_prolog_bolted addr
>>>>> +.macro tlb_prolog_bolted intnum addr
>>>>>     mtspr   SPRN_SPRG_TLB_SCRATCH,r13
>>>>>     mfspr   r13,SPRN_SPRG_PACA
>>>>>     std     r10,PACA_EXTLB+EX_TLB_R10(r13)
>>>>>     mfcr    r10
>>>>>     std     r11,PACA_EXTLB+EX_TLB_R11(r13)
>>>>> +#ifdef CONFIG_KVM_BOOKE_HV
>>>>> +BEGIN_FTR_SECTION
>>>>> +   mfspr   r11, SPRN_SRR1
>>>>> +END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
>>>>> +#endif
>>>>
>>>> This thing really should vanish behind DO_KVM :)
>>>
>>> Then let's do it first for 32-bit ;)
>>
>> You could #ifdef it in DO_KVM for 64-bit for now. IIRC it's not done on 32-bit because the register value is used even beyond DO_KVM there.
> 
> Nope, 32-bit code is also guarded by CONFIG_KVM_BOOKE_HV.

Only in the TLB miss handlers, not the normal exception prolog.

-Scott

^ permalink raw reply

* Re: [Qemu-ppc] [RFC PATCH 04/17] KVM: PPC64: booke: Add guest computation mode for irq delivery
From: Scott Wood @ 2012-07-05 23:51 UTC (permalink / raw)
  To: Alexander Graf; +Cc: kvm-ppc, Mihai Caraman, qemu-ppc, linuxppc-dev, kvm
In-Reply-To: <E29E8A28-9993-4E6C-B41A-7C0AA51945F3@suse.de>

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)
>> 			set_guest_dear(vcpu, vcpu->arch.queued_dear);
>> -		kvmppc_set_msr(vcpu, vcpu->arch.shared->msr & msr_mask);
>> +		kvmppc_set_msr(vcpu, (vcpu->arch.shared->msr & msr_mask)
>> +				| msr_cm);
> 
> Please split this computation out into its own variable and apply the masking regardless. Something like
> 
> ulong new_msr = vcpu->arch.shared->msr;
> if (vcpu->arch.epcr & SPRN_EPCR_ICM)
>     new_msr |= MSR_CM;
> new_msr &= msr_mask;
> kvmppc_set_msr(vcpu, new_msr);

This will fail to clear MSR[CM] in the odd but legal situation where you
have MSR[CM] set but EPCR[ICM] unset.

-Scott

^ permalink raw reply

* Re: 3.4.0-rc1: No init found
From: Tabi Timur-B04825 @ 2012-07-05 22:36 UTC (permalink / raw)
  To: Suzuki K. Poulose
  Cc: Christian Kujau, linuxppc-dev@lists.ozlabs.org, LKML, Al Viro
In-Reply-To: <4F7C4058.6090405@in.ibm.com>

On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose <suzuki@in.ibm.com> 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
>>    WRAP    arch/powerpc/boot/zImage.pmac
>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>> wrapper(0x400000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>>    WRAP    arch/powerpc/boot/zImage.coff
>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>> wrapper(0x500000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>>    WRAP    arch/powerpc/boot/zImage.miboot
>> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
>> wrapper(0x400000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>>    Building modules, stage 2.
>>    MODPOST 24 modules
>> ------------
>>
>> I started to see these messages in January (around Linux 3.2.0), but nev=
er
>> investigated what it was since the produced kernels continued to boot ju=
st
>> fine.
>
>
> The above change was added by me. The message is printed when the 'wrappe=
r'
> script finds that decompressed kernel overlaps the 'bootstrap code' which
> does the decompression. So it shifts the 'address' of the bootstrap code =
to
> the next higher MB. As such it is harmless.

I see this message every time when I build the kernel.  I know it's
harmless, but is this something that can be "fixed"?  That is, can we
change some linker script (or whatever) to make 0x700000 the default
value?  Or maybe modify the wrapper script to just automatically find
the right spot without printing a message?

--=20
Timur Tabi
Linux kernel developer at Freescale=

^ permalink raw reply

* [PATCH] Revert "powerpc/p3060qds: Add support for P3060QDS board"
From: Timur Tabi @ 2012-07-05 22:07 UTC (permalink / raw)
  To: Kumar Gala, linuxppc-dev

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 <timur@freescale.com>
---
 arch/powerpc/boot/dts/fsl/p3060si-post.dtsi  |  302 --------------------------
 arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi   |  125 -----------
 arch/powerpc/boot/dts/p3060qds.dts           |  242 ---------------------
 arch/powerpc/configs/corenet32_smp_defconfig |    1 -
 arch/powerpc/platforms/85xx/Kconfig          |   12 -
 arch/powerpc/platforms/85xx/Makefile         |    1 -
 arch/powerpc/platforms/85xx/p3060_qds.c      |   77 -------
 7 files changed, 0 insertions(+), 760 deletions(-)
 delete mode 100644 arch/powerpc/boot/dts/fsl/p3060si-post.dtsi
 delete mode 100644 arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p3060qds.dts
 delete mode 100644 arch/powerpc/platforms/85xx/p3060_qds.c

diff --git a/arch/powerpc/boot/dts/fsl/p3060si-post.dtsi b/arch/powerpc/boot/dts/fsl/p3060si-post.dtsi
deleted file mode 100644
index b3e5692..0000000
--- a/arch/powerpc/boot/dts/fsl/p3060si-post.dtsi
+++ /dev/null
@@ -1,302 +0,0 @@
-/*
- * P3060 Silicon/SoC Device Tree Source (post include)
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *     * Redistributions of source code must retain the above copyright
- *       notice, this list of conditions and the following disclaimer.
- *     * Redistributions in binary form must reproduce the above copyright
- *       notice, this list of conditions and the following disclaimer in the
- *       documentation and/or other materials provided with the distribution.
- *     * Neither the name of Freescale Semiconductor nor the
- *       names of its contributors may be used to endorse or promote products
- *       derived from this software without specific prior written permission.
- *
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") as published by the Free Software
- * Foundation, either version 2 of that License or (at your option) any
- * later version.
- *
- * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
- * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
- * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
- * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
- * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-&lbc {
-	compatible = "fsl,p3060-elbc", "fsl,elbc", "simple-bus";
-	interrupts = <25 2 0 0>;
-	#address-cells = <2>;
-	#size-cells = <1>;
-};
-
-/* controller at 0x200000 */
-&pci0 {
-	compatible = "fsl,p3060-pcie", "fsl,qoriq-pcie-v2.2";
-	device_type = "pci";
-	#size-cells = <2>;
-	#address-cells = <3>;
-	bus-range = <0x0 0xff>;
-	clock-frequency = <33333333>;
-	interrupts = <16 2 1 15>;
-	pcie@0 {
-		reg = <0 0 0 0 0>;
-		#interrupt-cells = <1>;
-		#size-cells = <2>;
-		#address-cells = <3>;
-		device_type = "pci";
-		interrupts = <16 2 1 15>;
-		interrupt-map-mask = <0xf800 0 0 7>;
-		interrupt-map = <
-			/* IDSEL 0x0 */
-			0000 0 0 1 &mpic 40 1 0 0
-			0000 0 0 2 &mpic 1 1 0 0
-			0000 0 0 3 &mpic 2 1 0 0
-			0000 0 0 4 &mpic 3 1 0 0
-			>;
-	};
-};
-
-/* controller at 0x201000 */
-&pci1 {
-	compatible = "fsl,p3060-pcie", "fsl,qoriq-pcie-v2.2";
-	device_type = "pci";
-	#size-cells = <2>;
-	#address-cells = <3>;
-	bus-range = <0 0xff>;
-	clock-frequency = <33333333>;
-	interrupts = <16 2 1 14>;
-	pcie@0 {
-		reg = <0 0 0 0 0>;
-		#interrupt-cells = <1>;
-		#size-cells = <2>;
-		#address-cells = <3>;
-		device_type = "pci";
-		interrupts = <16 2 1 14>;
-		interrupt-map-mask = <0xf800 0 0 7>;
-		interrupt-map = <
-			/* IDSEL 0x0 */
-			0000 0 0 1 &mpic 41 1 0 0
-			0000 0 0 2 &mpic 5 1 0 0
-			0000 0 0 3 &mpic 6 1 0 0
-			0000 0 0 4 &mpic 7 1 0 0
-			>;
-	};
-};
-
-&rio {
-	compatible = "fsl,srio";
-	interrupts = <16 2 1 11>;
-	#address-cells = <2>;
-	#size-cells = <2>;
-	fsl,srio-rmu-handle = <&rmu>;
-	ranges;
-
-	port1 {
-		#address-cells = <2>;
-		#size-cells = <2>;
-		cell-index = <1>;
-	};
-
-	port2 {
-		#address-cells = <2>;
-		#size-cells = <2>;
-		cell-index = <2>;
-	};
-};
-
-&dcsr {
-	#address-cells = <1>;
-	#size-cells = <1>;
-	compatible = "fsl,dcsr", "simple-bus";
-
-	dcsr-epu@0 {
-		compatible = "fsl,dcsr-epu";
-		interrupts = <52 2 0 0
-			      84 2 0 0
-			      85 2 0 0>;
-		reg = <0x0 0x1000>;
-	};
-	dcsr-npc {
-		compatible = "fsl,dcsr-npc";
-		reg = <0x1000 0x1000 0x1000000 0x8000>;
-	};
-	dcsr-nxc@2000 {
-		compatible = "fsl,dcsr-nxc";
-		reg = <0x2000 0x1000>;
-	};
-	dcsr-corenet {
-		compatible = "fsl,dcsr-corenet";
-		reg = <0x8000 0x1000 0xB0000 0x1000>;
-	};
-	dcsr-dpaa@9000 {
-		compatible = "fsl,p3060-dcsr-dpaa", "fsl,dcsr-dpaa";
-		reg = <0x9000 0x1000>;
-	};
-	dcsr-ocn@11000 {
-		compatible = "fsl,p3060-dcsr-ocn", "fsl,dcsr-ocn";
-		reg = <0x11000 0x1000>;
-	};
-	dcsr-ddr@12000 {
-		compatible = "fsl,dcsr-ddr";
-		dev-handle = <&ddr1>;
-		reg = <0x12000 0x1000>;
-	};
-	dcsr-nal@18000 {
-		compatible = "fsl,p3060-dcsr-nal", "fsl,dcsr-nal";
-		reg = <0x18000 0x1000>;
-	};
-	dcsr-rcpm@22000 {
-		compatible = "fsl,p3060-dcsr-rcpm", "fsl,dcsr-rcpm";
-		reg = <0x22000 0x1000>;
-	};
-	dcsr-cpu-sb-proxy@40000 {
-		compatible = "fsl,dcsr-e500mc-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
-		cpu-handle = <&cpu0>;
-		reg = <0x40000 0x1000>;
-	};
-	dcsr-cpu-sb-proxy@41000 {
-		compatible = "fsl,dcsr-e500mc-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
-		cpu-handle = <&cpu1>;
-		reg = <0x41000 0x1000>;
-	};
-	dcsr-cpu-sb-proxy@44000 {
-		compatible = "fsl,dcsr-e500mc-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
-		cpu-handle = <&cpu4>;
-		reg = <0x44000 0x1000>;
-	};
-	dcsr-cpu-sb-proxy@45000 {
-		compatible = "fsl,dcsr-e500mc-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
-		cpu-handle = <&cpu5>;
-		reg = <0x45000 0x1000>;
-	};
-	dcsr-cpu-sb-proxy@46000 {
-		compatible = "fsl,dcsr-e500mc-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
-		cpu-handle = <&cpu6>;
-		reg = <0x46000 0x1000>;
-	};
-	dcsr-cpu-sb-proxy@47000 {
-		compatible = "fsl,dcsr-e500mc-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
-		cpu-handle = <&cpu7>;
-		reg = <0x47000 0x1000>;
-	};
-
-};
-
-&soc {
-	#address-cells = <1>;
-	#size-cells = <1>;
-	device_type = "soc";
-	compatible = "simple-bus";
-
-	soc-sram-error {
-		compatible = "fsl,soc-sram-error";
-		interrupts = <16 2 1 29>;
-	};
-
-	corenet-law@0 {
-		compatible = "fsl,corenet-law";
-		reg = <0x0 0x1000>;
-		fsl,num-laws = <32>;
-	};
-
-	ddr1: memory-controller@8000 {
-		compatible = "fsl,qoriq-memory-controller-v4.4", "fsl,qoriq-memory-controller";
-		reg = <0x8000 0x1000>;
-		interrupts = <16 2 1 23>;
-	};
-
-	cpc: l3-cache-controller@10000 {
-		compatible = "fsl,p3060-l3-cache-controller", "cache";
-		reg = <0x10000 0x1000
-		       0x11000 0x1000>;
-		interrupts = <16 2 1 27
-			      16 2 1 26>;
-	};
-
-	corenet-cf@18000 {
-		compatible = "fsl,corenet-cf";
-		reg = <0x18000 0x1000>;
-		interrupts = <16 2 1 31>;
-		fsl,ccf-num-csdids = <32>;
-		fsl,ccf-num-snoopids = <32>;
-	};
-
-	iommu@20000 {
-		compatible = "fsl,pamu-v1.0", "fsl,pamu";
-		reg = <0x20000 0x5000>;
-		interrupts = <
-			24 2 0 0
-			16 2 1 30>;
-	};
-
-/include/ "qoriq-rmu-0.dtsi"
-/include/ "qoriq-mpic.dtsi"
-
-	guts: global-utilities@e0000 {
-		compatible = "fsl,qoriq-device-config-1.0";
-		reg = <0xe0000 0xe00>;
-		fsl,has-rstcr;
-		#sleep-cells = <1>;
-		fsl,liodn-bits = <12>;
-	};
-
-	pins: global-utilities@e0e00 {
-		compatible = "fsl,qoriq-pin-control-1.0";
-		reg = <0xe0e00 0x200>;
-		#sleep-cells = <2>;
-	};
-
-	clockgen: global-utilities@e1000 {
-		compatible = "fsl,p3060-clockgen", "fsl,qoriq-clockgen-1.0";
-		reg = <0xe1000 0x1000>;
-		clock-frequency = <0>;
-	};
-
-	rcpm: global-utilities@e2000 {
-		compatible = "fsl,qoriq-rcpm-1.0";
-		reg = <0xe2000 0x1000>;
-		#sleep-cells = <1>;
-	};
-
-	sfp: sfp@e8000 {
-		compatible = "fsl,p3060-sfp", "fsl,qoriq-sfp-1.0";
-		reg	   = <0xe8000 0x1000>;
-	};
-
-	serdes: serdes@ea000 {
-		compatible = "fsl,p3060-serdes";
-		reg	   = <0xea000 0x1000>;
-	};
-
-/include/ "qoriq-dma-0.dtsi"
-/include/ "qoriq-dma-1.dtsi"
-/include/ "qoriq-espi-0.dtsi"
-	spi@110000 {
-		fsl,espi-num-chipselects = <4>;
-	};
-
-/include/ "qoriq-i2c-0.dtsi"
-/include/ "qoriq-i2c-1.dtsi"
-/include/ "qoriq-duart-0.dtsi"
-/include/ "qoriq-duart-1.dtsi"
-/include/ "qoriq-gpio-0.dtsi"
-/include/ "qoriq-usb2-mph-0.dtsi"
-	usb@210000 {
-		compatible = "fsl-usb2-mph-v2.2", "fsl,mpc85xx-usb2-mph", "fsl-usb2-mph";
-	};
-/include/ "qoriq-usb2-dr-0.dtsi"
-	usb@211000 {
-		compatible = "fsl-usb2-dr-v2.2", "fsl,mpc85xx-usb2-dr", "fsl-usb2-dr";
-	};
-/include/ "qoriq-sec4.1-0.dtsi"
-};
diff --git a/arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi
deleted file mode 100644
index 00c8e70..0000000
--- a/arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi
+++ /dev/null
@@ -1,125 +0,0 @@
-/*
- * P3060 Silicon/SoC Device Tree Source (pre include)
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *     * Redistributions of source code must retain the above copyright
- *       notice, this list of conditions and the following disclaimer.
- *     * Redistributions in binary form must reproduce the above copyright
- *       notice, this list of conditions and the following disclaimer in the
- *       documentation and/or other materials provided with the distribution.
- *     * Neither the name of Freescale Semiconductor nor the
- *       names of its contributors may be used to endorse or promote products
- *       derived from this software without specific prior written permission.
- *
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") as published by the Free Software
- * Foundation, either version 2 of that License or (at your option) any
- * later version.
- *
- * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
- * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
- * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
- * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
- * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-/dts-v1/;
-/ {
-	compatible = "fsl,P3060";
-	#address-cells = <2>;
-	#size-cells = <2>;
-	interrupt-parent = <&mpic>;
-
-	aliases {
-		ccsr = &soc;
-		dcsr = &dcsr;
-
-		serial0 = &serial0;
-		serial1 = &serial1;
-		serial2 = &serial2;
-		serial3 = &serial3;
-		pci0 = &pci0;
-		pci1 = &pci1;
-		usb0 = &usb0;
-		usb1 = &usb1;
-		dma0 = &dma0;
-		dma1 = &dma1;
-		msi0 = &msi0;
-		msi1 = &msi1;
-		msi2 = &msi2;
-
-		crypto = &crypto;
-		sec_jr0 = &sec_jr0;
-		sec_jr1 = &sec_jr1;
-		sec_jr2 = &sec_jr2;
-		sec_jr3 = &sec_jr3;
-		rtic_a = &rtic_a;
-		rtic_b = &rtic_b;
-		rtic_c = &rtic_c;
-		rtic_d = &rtic_d;
-		sec_mon = &sec_mon;
-	};
-
-	cpus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		cpu0: PowerPC,e500mc@0 {
-			device_type = "cpu";
-			reg = <0>;
-			next-level-cache = <&L2_0>;
-			L2_0: l2-cache {
-				next-level-cache = <&cpc>;
-			};
-		};
-		cpu1: PowerPC,e500mc@1 {
-			device_type = "cpu";
-			reg = <1>;
-			next-level-cache = <&L2_1>;
-			L2_1: l2-cache {
-				next-level-cache = <&cpc>;
-			};
-		};
-		cpu4: PowerPC,e500mc@4 {
-			device_type = "cpu";
-			reg = <4>;
-			next-level-cache = <&L2_4>;
-			L2_4: l2-cache {
-				next-level-cache = <&cpc>;
-			};
-		};
-		cpu5: PowerPC,e500mc@5 {
-			device_type = "cpu";
-			reg = <5>;
-			next-level-cache = <&L2_5>;
-			L2_5: l2-cache {
-				next-level-cache = <&cpc>;
-			};
-		};
-		cpu6: PowerPC,e500mc@6 {
-			device_type = "cpu";
-			reg = <6>;
-			next-level-cache = <&L2_6>;
-			L2_6: l2-cache {
-				next-level-cache = <&cpc>;
-			};
-		};
-		cpu7: PowerPC,e500mc@7 {
-			device_type = "cpu";
-			reg = <7>;
-			next-level-cache = <&L2_7>;
-			L2_7: l2-cache {
-				next-level-cache = <&cpc>;
-			};
-		};
-	};
-};
diff --git a/arch/powerpc/boot/dts/p3060qds.dts b/arch/powerpc/boot/dts/p3060qds.dts
deleted file mode 100644
index 9ae875c..0000000
--- a/arch/powerpc/boot/dts/p3060qds.dts
+++ /dev/null
@@ -1,242 +0,0 @@
-/*
- * P3060QDS Device Tree Source
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *     * Redistributions of source code must retain the above copyright
- *       notice, this list of conditions and the following disclaimer.
- *     * Redistributions in binary form must reproduce the above copyright
- *       notice, this list of conditions and the following disclaimer in the
- *       documentation and/or other materials provided with the distribution.
- *     * Neither the name of Freescale Semiconductor nor the
- *       names of its contributors may be used to endorse or promote products
- *       derived from this software without specific prior written permission.
- *
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") as published by the Free Software
- * Foundation, either version 2 of that License or (at your option) any
- * later version.
- *
- * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
- * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
- * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
- * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
- * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-/include/ "fsl/p3060si-pre.dtsi"
-
-/ {
-	model = "fsl,P3060QDS";
-	compatible = "fsl,P3060QDS";
-	#address-cells = <2>;
-	#size-cells = <2>;
-	interrupt-parent = <&mpic>;
-
-	memory {
-		device_type = "memory";
-	};
-
-	dcsr: dcsr@f00000000 {
-		ranges = <0x00000000 0xf 0x00000000 0x01008000>;
-	};
-
-	soc: soc@ffe000000 {
-		ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
-		reg = <0xf 0xfe000000 0 0x00001000>;
-		spi@110000 {
-			flash@0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "spansion,s25sl12801";
-				reg = <0>;
-				spi-max-frequency = <40000000>; /* input clock */
-				partition@u-boot {
-					label = "u-boot";
-					reg = <0x00000000 0x00100000>;
-					read-only;
-				};
-				partition@kernel {
-					label = "kernel";
-					reg = <0x00100000 0x00500000>;
-					read-only;
-				};
-				partition@dtb {
-					label = "dtb";
-					reg = <0x00600000 0x00100000>;
-					read-only;
-				};
-				partition@fs {
-					label = "file system";
-					reg = <0x00700000 0x00900000>;
-				};
-			};
-			flash@1 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "spansion,en25q32b";
-				reg = <1>;
-				spi-max-frequency = <40000000>; /* input clock */
-				partition@spi1 {
-					label = "spi1";
-					reg = <0x00000000 0x00400000>;
-				};
-			};
-			flash@2 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "atmel,at45db081d";
-				reg = <2>;
-				spi-max-frequency = <40000000>; /* input clock */
-				partition@spi1 {
-					label = "spi2";
-					reg = <0x00000000 0x00100000>;
-				};
-			};
-			flash@3 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "spansion,sst25wf040";
-				reg = <3>;
-				spi-max-frequency = <40000000>; /* input clock */
-				partition@spi3 {
-					label = "spi3";
-					reg = <0x00000000 0x00080000>;
-				};
-			};
-		};
-
-		i2c@118000 {
-			eeprom@51 {
-				compatible = "at24,24c256";
-				reg = <0x51>;
-			};
-			eeprom@53 {
-				compatible = "at24,24c256";
-				reg = <0x53>;
-			};
-			rtc@68 {
-				compatible = "dallas,ds3232";
-				reg = <0x68>;
-				interrupts = <0x1 0x1 0 0>;
-			};
-		};
-
-		usb0: usb@210000 {
-			phy_type = "ulpi";
-		};
-
-		usb1: usb@211000 {
-			dr_mode = "host";
-			phy_type = "ulpi";
-		};
-	};
-
-	rio: rapidio@ffe0c0000 {
-		reg = <0xf 0xfe0c0000 0 0x11000>;
-
-		port1 {
-			ranges = <0 0 0xc 0x20000000 0 0x10000000>;
-		};
-		port2 {
-			ranges = <0 0 0xc 0x30000000 0 0x10000000>;
-		};
-	};
-
-	lbc: localbus@ffe124000 {
-		reg = <0xf 0xfe124000 0 0x1000>;
-		ranges = <0 0 0xf 0xe8000000 0x08000000
-			  2 0 0xf 0xffa00000 0x00040000
-			  3 0 0xf 0xffdf0000 0x00008000>;
-
-		flash@0,0 {
-			compatible = "cfi-flash";
-			reg = <0 0 0x08000000>;
-			bank-width = <2>;
-			device-width = <2>;
-		};
-
-		nand@2,0 {
-			#address-cells = <1>;
-			#size-cells = <1>;
-			compatible = "fsl,elbc-fcm-nand";
-			reg = <0x2 0x0 0x40000>;
-
-			partition@0 {
-				label = "NAND U-Boot Image";
-				reg = <0x0 0x02000000>;
-				read-only;
-			};
-
-			partition@2000000 {
-				label = "NAND Root File System";
-				reg = <0x02000000 0x10000000>;
-			};
-
-			partition@12000000 {
-				label = "NAND Compressed RFS Image";
-				reg = <0x12000000 0x08000000>;
-			};
-
-			partition@1a000000 {
-				label = "NAND Linux Kernel Image";
-				reg = <0x1a000000 0x04000000>;
-			};
-
-			partition@1e000000 {
-				label = "NAND DTB Image";
-				reg = <0x1e000000 0x01000000>;
-			};
-
-			partition@1f000000 {
-				label = "NAND Writable User area";
-				reg = <0x1f000000 0x21000000>;
-			};
-		};
-
-		board-control@3,0 {
-			compatible = "fsl,p3060qds-fpga", "fsl,fpga-qixis";
-			reg = <3 0 0x100>;
-		};
-	};
-
-	pci0: pcie@ffe200000 {
-		reg = <0xf 0xfe200000 0 0x1000>;
-		ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x20000000
-			  0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
-		pcie@0 {
-			ranges = <0x02000000 0 0xe0000000
-				  0x02000000 0 0xe0000000
-				  0 0x20000000
-
-				  0x01000000 0 0x00000000
-				  0x01000000 0 0x00000000
-				  0 0x00010000>;
-		};
-	};
-
-	pci1: pcie@ffe201000 {
-		reg = <0xf 0xfe201000 0 0x1000>;
-		ranges = <0x02000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
-			  0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
-		pcie@0 {
-			ranges = <0x02000000 0 0xe0000000
-				  0x02000000 0 0xe0000000
-				  0 0x20000000
-
-				  0x01000000 0 0x00000000
-				  0x01000000 0 0x00000000
-				  0 0x00010000>;
-		};
-	};
-};
-
-/include/ "fsl/p3060si-post.dtsi"
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index b32d949..efce1d6 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -23,7 +23,6 @@ CONFIG_MODVERSIONS=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_P2041_RDB=y
 CONFIG_P3041_DS=y
-CONFIG_P3060_QDS=y
 CONFIG_P4080_DS=y
 CONFIG_P5020_DS=y
 CONFIG_HIGHMEM=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index b3370be..0e77f5f 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -216,18 +216,6 @@ config P3041_DS
 	help
 	  This option enables support for the P3041 DS board
 
-config P3060_QDS
-	bool "Freescale P3060 QDS"
-	select DEFAULT_UIMAGE
-	select PPC_E500MC
-	select PHYS_64BIT
-	select SWIOTLB
-	select GPIO_MPC8XXX
-	select HAS_RAPIDIO
-	select PPC_EPAPR_HV_PIC
-	help
-	  This option enables support for the P3060 QDS board
-
 config P4080_DS
 	bool "Freescale P4080 DS"
 	select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 50280cc..3fee687 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_P1022_DS)    += p1022_ds.o
 obj-$(CONFIG_P1023_RDS)   += p1023_rds.o
 obj-$(CONFIG_P2041_RDB)   += p2041_rdb.o corenet_ds.o
 obj-$(CONFIG_P3041_DS)    += p3041_ds.o corenet_ds.o
-obj-$(CONFIG_P3060_QDS)   += p3060_qds.o corenet_ds.o
 obj-$(CONFIG_P4080_DS)    += p4080_ds.o corenet_ds.o
 obj-$(CONFIG_P5020_DS)    += p5020_ds.o corenet_ds.o
 obj-$(CONFIG_STX_GP3)	  += stx_gp3.o
diff --git a/arch/powerpc/platforms/85xx/p3060_qds.c b/arch/powerpc/platforms/85xx/p3060_qds.c
deleted file mode 100644
index 081cf4a..0000000
--- a/arch/powerpc/platforms/85xx/p3060_qds.c
+++ /dev/null
@@ -1,77 +0,0 @@
-/*
- * P3060 QDS Setup
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#include <linux/kernel.h>
-#include <linux/interrupt.h>
-#include <linux/phy.h>
-#include <asm/machdep.h>
-#include <asm/udbg.h>
-#include <asm/mpic.h>
-#include <linux/of_platform.h>
-#include <sysdev/fsl_soc.h>
-#include <sysdev/fsl_pci.h>
-#include <asm/ehv_pic.h>
-#include "corenet_ds.h"
-
-/*
- * Called very early, device-tree isn't unflattened
- */
-static int __init p3060_qds_probe(void)
-{
-	unsigned long root = of_get_flat_dt_root();
-#ifdef CONFIG_SMP
-	extern struct smp_ops_t smp_85xx_ops;
-#endif
-
-	if (of_flat_dt_is_compatible(root, "fsl,P3060QDS"))
-		return 1;
-
-	/* Check if we're running under the Freescale hypervisor */
-	if (of_flat_dt_is_compatible(root, "fsl,P3060QDS-hv")) {
-		ppc_md.init_IRQ = ehv_pic_init;
-		ppc_md.get_irq = ehv_pic_get_irq;
-		ppc_md.restart = fsl_hv_restart;
-		ppc_md.power_off = fsl_hv_halt;
-		ppc_md.halt = fsl_hv_halt;
-#ifdef CONFIG_SMP
-		/*
-		 * Disable the timebase sync operations because we can't write
-		 * to the timebase registers under the hypervisor.
-		 */
-		smp_85xx_ops.give_timebase = NULL;
-		smp_85xx_ops.take_timebase = NULL;
-#endif
-		return 1;
-	}
-
-	return 0;
-}
-
-define_machine(p3060_qds) {
-	.name			= "P3060 QDS",
-	.probe			= p3060_qds_probe,
-	.setup_arch		= corenet_ds_setup_arch,
-	.init_IRQ		= corenet_ds_pic_init,
-#ifdef CONFIG_PCI
-	.pcibios_fixup_bus	= fsl_pcibios_fixup_bus,
-#endif
-	.get_irq		= mpic_get_coreint_irq,
-	.restart		= fsl_rstcr_restart,
-	.calibrate_decr		= generic_calibrate_decr,
-	.progress		= udbg_progress,
-	.power_save		= e500_idle,
-};
-
-machine_device_initcall(p3060_qds, corenet_ds_publish_devices);
-
-#ifdef CONFIG_SWIOTLB
-machine_arch_initcall(p3060_qds, swiotlb_setup_bus_notifier);
-#endif
-- 
1.7.3.4

^ permalink raw reply related

* Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
From: Scott Wood @ 2012-07-05 17:11 UTC (permalink / raw)
  To: Zhao Chenhui
  Cc: Wood Scott-B07421, Li Yang-R58472, Zhao Chenhui-B35336,
	Tabi Timur-B04825, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120704034545.GA6196@localhost.localdomain>

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 warning message.  Crashing the kernel is not 
>> going to fix anything.
>>
> 
> This error likely crashes the kenel somewhere.

Only if you're doing cpu hotplug or kexec.

-Scott

^ permalink raw reply

* RE: [RFC PATCH 13/17] PowerPC: booke64: Use SPRG0/3 scratch for bolted TLB miss & crit int
From: Caraman Mihai Claudiu-B02008 @ 2012-07-05 15:51 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: qemu-ppc@nongnu.org, Anton Blanchard,
	linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
	kvm-ppc@vger.kernel.org
In-Reply-To: <1340748983.3732.32.camel@pasglop>

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBXZWRuZXNkYXks
IEp1bmUgMjcsIDIwMTIgMToxNiBBTQ0KPiBUbzogQ2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAw
OA0KPiBDYzoga3ZtLXBwY0B2Z2VyLmtlcm5lbC5vcmc7IGt2bUB2Z2VyLmtlcm5lbC5vcmc7IGxp
bnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZzsgcWVtdS1wcGNAbm9uZ251Lm9yZzsgQW50
b24gQmxhbmNoYXJkDQo+IFN1YmplY3Q6IFJlOiBbUkZDIFBBVENIIDEzLzE3XSBQb3dlclBDOiBi
b29rZTY0OiBVc2UgU1BSRzAvMyBzY3JhdGNoIGZvcg0KPiBib2x0ZWQgVExCIG1pc3MgJiBjcml0
IGludA0KPiANCj4gT24gTW9uLCAyMDEyLTA2LTI1IGF0IDE1OjI2ICswMzAwLCBNaWhhaSBDYXJh
bWFuIHdyb3RlOg0KPiA+IEVtYmVkZGVkLkh5cGVydmlzb3IgY2F0ZWdvcnkgZGVmaW5lcyBHU1BS
RzAuLjMgcGh5c2ljYWwgcmVnaXN0ZXJzIGZvcg0KPiBndWVzdHMuDQo+ID4gQXZvaWQgU1BSRzQt
NyB1c2FnZSBhcyBzY3JhdGNoIGluIGhvc3QgZXhjZXB0aW9uIGhhbmRsZXJzLCBvdGhlcndpc2UN
Cj4gZ3Vlc3QNCj4gPiBTUFJHNC03IHJlZ2lzdGVycyB3aWxsIGJlIGNsb2JiZXJlZC4NCj4gPiBG
b3IgYm9sdGVkIFRMQiBtaXNzIGV4Y2VwdGlvbiBoYW5kbGVycywgd2hpY2ggaXMgdGhlIHZlcnNp
b24gY3VycmVudGx5DQo+ID4gc3VwcG9ydGVkIGJ5IEtWTSwgdXNlIFNQUk5fU1BSR19HRU5fU0NS
QVRDSCAoYWthIFNQUkcwKSBpbnN0ZWFkIG9mDQo+ID4gU1BSTl9TUFJHX1RMQl9TQ1JBVENIIChh
a2EgU1BSRzYpIGFuZCByZXBsYWNlIFRMQiB3aXRoIEdFTiBQQUNBIHNsb3RzDQo+IHRvDQo+ID4g
a2VlcCBjb25zaXRlbmN5Lg0KPiA+IEZvciBjcml0aWNhbCBleGNlcHRpb24gaGFuZGxlciB1c2Ug
U1BSRzMgaW5zdGVhZCBvZiBTUFJHNy4NCj4gDQo+IEJld2FyZSB3aXRoIFNQUkczIHVzYWdlLiBJ
dCdzIHVzZXIgc3BhY2UgdmlzaWJsZSBhbmQgd2UgcGxhbiB0byB1c2UgaXQNCj4gZm9yIG90aGVy
IHRoaW5ncyAoc2VlIEFudG9uJ3MgcGF0Y2ggdG8gc3RpY2sgdG9wb2xvZ3kgaW5mb3JtYXRpb24g
aW4NCj4gdGhlcmUgZm9yIHVzZSBieSB0aGUgdmRzbykuIElmIHlvdSBjbG9iYmVyIGl0LCB5b3Ug
bWF5IHdhbnQgdG8gcmVzdG9yZQ0KPiBpdCBsYXRlci4NCg0KSW4gYm9va2UzZSBjYXNlIFNQUkcz
IHdpbGwgbm90IGJlIGNsb2JiZXJlZCBieSB0aGUgZ3Vlc3RzIHdoaWNoIGFjY2VzcyBHU1BSRzMs
DQpidXQgYnkgdGhlIGhvc3QgZXhjZXB0aW9uIGhhbmRsZXIuIFRoaXMgbWVhbnMgdGhhdCB3ZSB3
aWxsIGhhdmUgdG8gcmVzdG9yZSBTUFJHMw0KZXZlbiBpbiB0aGUgYWJzZW5jZSBvZiBLVk0uDQoN
Ck15IHByb3Bvc2FsIGlzIHRvIGFkZCBhIFBBQ0Egc2xvdCBmb3IgcjEzIGFuZCBzYXZlIGl0IGlu
IHRoZSBzYW1lIHdheSB5b3UgZGlkIHdpdGgNCnIxMiBpbiBUTEJfTUlTU19QUk9MT0cuIFRoZW4g
d2UgY2FuIHJlc3RvcmUgU1BSRzMgcmlnaHQgaW4gdGhlIHByb2xvZyB0aHVzIGFsc28NCmF2b2lk
aW5nIHRvIGRlYWwgd2l0aCBpdCBpbiBLVk0uDQoNClRoZSBFWENFUFRJT05fUFJPTE9HIGlzIGEg
Y29tbW9uIGRlZmluZSBmb3IgR0VOL0RCRy9DUklUL01DLCB3ZSB1c2UgYWRkaXRpb24gZGVmaW5l
cw0KdG8gc3BlY2lhbGl6ZSBqdXN0IHRoZSBDUklUIGNhc2UuDQoNCj4gSSB0aGluayBBbnRvbidz
IHBhdGNoIHNob3VsZCBwdXQgdGhlICJwcm9wZXIiIHZhbHVlIHdlIHdhbnQgaW4gdGhlIFBBQ0EN
Cj4gYW55d2F5IHNpbmNlIHdlIGFsc28gbmVlZCB0byByZXN0b3JlIGl0IG9uIGV4aXQgZnJvbSBL
Vk0sIHNvIHlvdSBjYW4NCj4gc3RpbGwgdXNlIGl0IGFzIHNjcmF0Y2gsIGp1c3QgcmVzdG9yZSB0
aGUgdmFsdWUgYmVmb3JlIGdvaW5nIHRvIEMuDQoNCkkganVzdCBzYXcgbGFzdCBpdGVyYXRpb24g
b2YgQW50b24ncyB2c2RvIHBhdGNoIHRoYXQgbWF0Y2hlcyB5b3VyIGRlc2NyaXB0aW9uLg0KDQpD
aGVlcnMsDQotTWlrZQ0K

^ permalink raw reply

* Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
From: Tabi Timur-B04825 @ 2012-07-05 15:31 UTC (permalink / raw)
  To: Zhao Chenhui-B35336
  Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <1341310879-5468-1-git-send-email-chenhui.zhao@freescale.com>

On Tue, Jul 3, 2012 at 5:21 AM, Zhao Chenhui <chenhui.zhao@freescale.com> w=
rote:
> 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: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>

Acked-by: Timur Tabi <timur@freescale.com>

--=20
Timur Tabi
Linux kernel developer at Freescale=

^ permalink raw reply

* Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
From: Timur Tabi @ 2012-07-05 15:30 UTC (permalink / raw)
  To: Zhao Chenhui
  Cc: Wood Scott-B07421, Li Yang-R58472, Zhao Chenhui-B35336,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120705102529.GA7982@localhost.localdomain>

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 are fatal errors, so I print an error info and return.

Ok, I see your point now.  I'm concerned about what might happen if
someone else updates mpc85xx_smp_init() in the future, but there's nothing
actually wrong with your patch today.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* [PATCH] powerpc/85xx: use the BRx registers to enable indirect mode on the P1022DS
From: Timur Tabi @ 2012-07-05 15:08 UTC (permalink / raw)
  To: Kumar Gala, linuxppc-dev

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
pixis mode" device tree node.  This node assumes that the localbus 'ranges'
property is sorted in chip-select order.  That is, reg value 0 maps to
CS0, reg value 1 maps to CS1, etc.  This is how the 'ranges' property is
supposed to be arranged.

Unfortunately, the 'ranges' property is often mis-arranged, and not just on
the P1022DS.  Linux normally does not care, since it does not program the
localbus.  But the indirect-mode code on the P1022DS does care.

The "proper" fix is to have U-Boot fix the 'ranges' property, but this would
be too cumbersome.  The names and 'reg' properties of all the localbus
devices would also need to be updated, and determining which localbus device
maps to which chip select is board-specific.

Instead, we determine the CS0/CS1 base addresses the same way that U-boot
does -- by reading the BRx registers directly and mapping them to physical
addresses.  This code is simpler and more reliable, and it does not require
a U-boot or device tree change.

Since the indirect pixis device tree node is no longer needed, the node is
deleted from the DTS.

Signed-off-by: Timur Tabi <timur@freescale.com>
---
 arch/powerpc/boot/dts/p1022ds.dtsi     |   16 -----
 arch/powerpc/platforms/85xx/p1022_ds.c |  106 ++++++++++++++++++++++++++++----
 2 files changed, 93 insertions(+), 29 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi b/arch/powerpc/boot/dts/p1022ds.dtsi
index 7cdb505..1b0673e 100644
--- a/arch/powerpc/boot/dts/p1022ds.dtsi
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -33,22 +33,6 @@
  */
 
 &board_lbc {
-	/*
-	 * This node is used to access the pixis via "indirect" mode,
-	 * which is done by writing the pixis register index to chip
-	 * select 0 and the value to/from chip select 1.  Indirect
-	 * mode is the only way to access the pixis when DIU video
-	 * is enabled.  Note that this assumes that the first column
-	 * of the 'ranges' property above is the chip select number.
-	 */
-	board-control@0,0 {
-		compatible = "fsl,p1022ds-indirect-pixis";
-		reg = <0x0 0x0 1	/* CS0 */
-		       0x1 0x0 1>;	/* CS1 */
-		interrupt-parent = <&mpic>;
-		interrupts = <8 0 0 0>;
-	};
-
 	nor@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index f700c81..978330c 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -27,6 +27,7 @@
 #include <sysdev/fsl_pci.h>
 #include <asm/udbg.h>
 #include <asm/fsl_guts.h>
+#include <asm/fsl_lbc.h>
 #include "smp.h"
 
 #include "mpc85xx.h"
@@ -142,17 +143,73 @@ static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port,
 {
 }
 
+struct fsl_law {
+	u32	lawbar;
+	u32	reserved1;
+	u32	lawar;
+	u32	reserved[5];
+};
+
+#define LAWBAR_MASK	0x00F00000
+#define LAWBAR_SHIFT	12
+
+#define LAWAR_EN	0x80000000
+#define LAWAR_TGT_MASK	0x01F00000
+#define LAW_TRGT_IF_LBC	(0x04 << 20)
+
+#define LAWAR_MASK	(LAWAR_EN | LAWAR_TGT_MASK)
+#define LAWAR_MATCH	(LAWAR_EN | LAW_TRGT_IF_LBC)
+
+#define BR_BA		0xFFFF8000
+
+/*
+ * Map a BRx value to a physical address
+ *
+ * The localbus BRx registers only store the lower 32 bits of the address.  To
+ * obtain the upper four bits, we need to scan the LAW table.  The entry which
+ * maps to the localbus will contain the upper four bits.
+ */
+static phys_addr_t lbc_br_to_phys(const void *ecm, unsigned int count, u32 br)
+{
+#ifndef CONFIG_PHYS_64BIT
+	/*
+	 * If we only have 32-bit addressing, then the BRx address *is* the
+	 * physical address.
+	 */
+	return br & BR_BA;
+#else
+	const struct fsl_law *law = ecm + 0xc08;
+	unsigned int i;
+
+	for (i = 0; i < count; i++) {
+		u64 lawbar = in_be32(&law[i].lawbar);
+		u32 lawar = in_be32(&law[i].lawar);
+
+		if ((lawar & LAWAR_MASK) == LAWAR_MATCH)
+			/* Extract the upper four bits */
+			return (br & BR_BA) | ((lawbar & LAWBAR_MASK) << 12);
+	}
+
+	return 0;
+#endif
+}
+
 /**
  * p1022ds_set_monitor_port: switch the output to a different monitor port
- *
  */
 static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
 {
 	struct device_node *guts_node;
-	struct device_node *indirect_node = NULL;
+	struct device_node *lbc_node = NULL;
+	struct device_node *law_node = NULL;
 	struct ccsr_guts __iomem *guts;
+	struct fsl_lbc_regs *lbc = NULL;
+	void *ecm = NULL;
 	u8 __iomem *lbc_lcs0_ba = NULL;
 	u8 __iomem *lbc_lcs1_ba = NULL;
+	phys_addr_t cs0_addr, cs1_addr;
+	const __be32 *iprop;
+	unsigned int num_laws;
 	u8 b;
 
 	/* Map the global utilities registers. */
@@ -168,25 +225,43 @@ static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
 		goto exit;
 	}
 
-	indirect_node = of_find_compatible_node(NULL, NULL,
-					     "fsl,p1022ds-indirect-pixis");
-	if (!indirect_node) {
-		pr_err("p1022ds: missing pixis indirect mode node\n");
+	lbc_node = of_find_compatible_node(NULL, NULL, "fsl,p1022-elbc");
+	if (!lbc_node) {
+		pr_err("p1022ds: missing localbus node\n");
 		goto exit;
 	}
 
-	lbc_lcs0_ba = of_iomap(indirect_node, 0);
-	if (!lbc_lcs0_ba) {
-		pr_err("p1022ds: could not map localbus chip select 0\n");
+	lbc = of_iomap(lbc_node, 0);
+	if (!lbc) {
+		pr_err("p1022ds: could not map localbus node\n");
 		goto exit;
 	}
 
-	lbc_lcs1_ba = of_iomap(indirect_node, 1);
-	if (!lbc_lcs1_ba) {
-		pr_err("p1022ds: could not map localbus chip select 1\n");
+	law_node = of_find_compatible_node(NULL, NULL, "fsl,ecm-law");
+	if (!law_node) {
+		pr_err("p1022ds: missing local access window node\n");
 		goto exit;
 	}
 
+	ecm = of_iomap(law_node, 0);
+	if (!ecm) {
+		pr_err("p1022ds: could not map local access window node\n");
+		goto exit;
+	}
+
+	iprop = of_get_property(law_node, "fsl,num-laws", 0);
+	if (!iprop) {
+		pr_err("p1022ds: LAW node is missing fsl,num-laws property\n");
+		goto exit;
+	}
+	num_laws = be32_to_cpup(iprop);
+
+	cs0_addr = lbc_br_to_phys(ecm, num_laws, in_be32(&lbc->bank[0].br));
+	cs1_addr = lbc_br_to_phys(ecm, num_laws, in_be32(&lbc->bank[1].br));
+
+	lbc_lcs0_ba = ioremap(cs0_addr, 1);
+	lbc_lcs1_ba = ioremap(cs1_addr, 1);
+
 	/* Make sure we're in indirect mode first. */
 	if ((in_be32(&guts->pmuxcr) & PMUXCR_ELBCDIU_MASK) !=
 	    PMUXCR_ELBCDIU_DIU) {
@@ -254,10 +329,15 @@ exit:
 		iounmap(lbc_lcs1_ba);
 	if (lbc_lcs0_ba)
 		iounmap(lbc_lcs0_ba);
+	if (lbc)
+		iounmap(lbc);
+	if (ecm)
+		iounmap(ecm);
 	if (guts)
 		iounmap(guts);
 
-	of_node_put(indirect_node);
+	of_node_put(law_node);
+	of_node_put(lbc_node);
 	of_node_put(guts_node);
 }
 
-- 
1.7.3.4

^ permalink raw reply related

* [PATCH v4] PPC: use CURRENT_THREAD_INFO instead of open coded assembly
From: Stuart Yoder @ 2012-07-05 14:41 UTC (permalink / raw)
  To: agraf, linuxppc-dev, benh; +Cc: sfr, Stuart Yoder

From: Stuart Yoder <stuart.yoder@freescale.com>

Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
---
-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 ++++++++++++------------
 arch/powerpc/kernel/entry_64.S           |   14 +++++++-------
 arch/powerpc/kernel/exceptions-64e.S     |    2 +-
 arch/powerpc/kernel/exceptions-64s.S     |    2 +-
 arch/powerpc/kernel/head_fsl_booke.S     |    2 +-
 arch/powerpc/kernel/idle_6xx.S           |    4 ++--
 arch/powerpc/kernel/idle_book3e.S        |    2 +-
 arch/powerpc/kernel/idle_e500.S          |    4 ++--
 arch/powerpc/kernel/idle_power4.S        |    2 +-
 arch/powerpc/kernel/misc_32.S            |    4 ++--
 arch/powerpc/kvm/bookehv_interrupts.S    |    6 +-----
 arch/powerpc/mm/hash_low_32.S            |    8 ++++----
 arch/powerpc/sysdev/6xx-suspend.S        |    2 +-
 15 files changed, 44 insertions(+), 42 deletions(-)

diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index d58fc4e..a43c147 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -293,7 +293,7 @@ label##_hv:								\
 
 #define RUNLATCH_ON				\
 BEGIN_FTR_SECTION				\
-	clrrdi	r3,r1,THREAD_SHIFT;		\
+	CURRENT_THREAD_INFO(r3, r1);		\
 	ld	r4,TI_LOCAL_FLAGS(r3);		\
 	andi.	r0,r4,_TLF_RUNLATCH;		\
 	beql	ppc64_runlatch_on_trampoline;	\
@@ -332,7 +332,7 @@ label##_common:							\
 #ifdef CONFIG_PPC_970_NAP
 #define FINISH_NAP				\
 BEGIN_FTR_SECTION				\
-	clrrdi	r11,r1,THREAD_SHIFT;		\
+	CURRENT_THREAD_INFO(r11, r1);		\
 	ld	r9,TI_LOCAL_FLAGS(r11);		\
 	andi.	r10,r9,_TLF_NAPPING;		\
 	bnel	power4_fixup_nap;		\
diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
index 68831e9..faf9352 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -22,6 +22,12 @@
 
 #define THREAD_SIZE		(1 << THREAD_SHIFT)
 
+#ifdef CONFIG_PPC64
+#define CURRENT_THREAD_INFO(dest, sp)	clrrdi dest, sp, THREAD_SHIFT
+#else
+#define CURRENT_THREAD_INFO(dest, sp)	rlwinm dest, sp, 0, 0, 31-THREAD_SHIFT
+#endif
+
 #ifndef __ASSEMBLY__
 #include <linux/cache.h>
 #include <asm/processor.h>
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index ba3aeb4..bad42e3 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -92,7 +92,7 @@ crit_transfer_to_handler:
 	mfspr	r8,SPRN_SPRG_THREAD
 	lwz	r0,KSP_LIMIT(r8)
 	stw	r0,SAVED_KSP_LIMIT(r11)
-	rlwimi	r0,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r0, r1)
 	stw	r0,KSP_LIMIT(r8)
 	/* fall through */
 #endif
@@ -112,7 +112,7 @@ crit_transfer_to_handler:
 	mfspr	r8,SPRN_SPRG_THREAD
 	lwz	r0,KSP_LIMIT(r8)
 	stw	r0,saved_ksp_limit@l(0)
-	rlwimi	r0,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r0, r1)
 	stw	r0,KSP_LIMIT(r8)
 	/* fall through */
 #endif
@@ -158,7 +158,7 @@ transfer_to_handler:
 	tophys(r11,r11)
 	addi	r11,r11,global_dbcr0@l
 #ifdef CONFIG_SMP
-	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r9, r1)
 	lwz	r9,TI_CPU(r9)
 	slwi	r9,r9,3
 	add	r11,r11,r9
@@ -179,7 +179,7 @@ transfer_to_handler:
 	ble-	stack_ovf		/* then the kernel stack overflowed */
 5:
 #if defined(CONFIG_6xx) || defined(CONFIG_E500)
-	rlwinm	r9,r1,0,0,31-THREAD_SHIFT
+	CURRENT_THREAD_INFO(r9, r1)
 	tophys(r9,r9)			/* check local flags */
 	lwz	r12,TI_LOCAL_FLAGS(r9)
 	mtcrf	0x01,r12
@@ -333,7 +333,7 @@ _GLOBAL(DoSyscall)
 	mtmsr	r11
 1:
 #endif /* CONFIG_TRACE_IRQFLAGS */
-	rlwinm	r10,r1,0,0,(31-THREAD_SHIFT)	/* current_thread_info() */
+	CURRENT_THREAD_INFO(r10, r1)
 	lwz	r11,TI_FLAGS(r10)
 	andi.	r11,r11,_TIF_SYSCALL_T_OR_A
 	bne-	syscall_dotrace
@@ -354,7 +354,7 @@ ret_from_syscall:
 	bl	do_show_syscall_exit
 #endif
 	mr	r6,r3
-	rlwinm	r12,r1,0,0,(31-THREAD_SHIFT)	/* current_thread_info() */
+	CURRENT_THREAD_INFO(r12, r1)
 	/* disable interrupts so current_thread_info()->flags can't change */
 	LOAD_MSR_KERNEL(r10,MSR_KERNEL)	/* doesn't include MSR_EE */
 	/* Note: We don't bother telling lockdep about it */
@@ -815,7 +815,7 @@ ret_from_except:
 
 user_exc_return:		/* r10 contains MSR_KERNEL here */
 	/* Check current_thread_info()->flags */
-	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r9, r1)
 	lwz	r9,TI_FLAGS(r9)
 	andi.	r0,r9,_TIF_USER_WORK_MASK
 	bne	do_work
@@ -835,7 +835,7 @@ restore_user:
 /* N.B. the only way to get here is from the beq following ret_from_except. */
 resume_kernel:
 	/* check current_thread_info->preempt_count */
-	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r9, r1)
 	lwz	r0,TI_PREEMPT(r9)
 	cmpwi	0,r0,0		/* if non-zero, just restore regs and return */
 	bne	restore
@@ -852,7 +852,7 @@ resume_kernel:
 	bl	trace_hardirqs_off
 #endif
 1:	bl	preempt_schedule_irq
-	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r9, r1)
 	lwz	r3,TI_FLAGS(r9)
 	andi.	r0,r3,_TIF_NEED_RESCHED
 	bne-	1b
@@ -1122,7 +1122,7 @@ ret_from_debug_exc:
 	lwz	r10,SAVED_KSP_LIMIT(r1)
 	stw	r10,KSP_LIMIT(r9)
 	lwz	r9,THREAD_INFO-THREAD(r9)
-	rlwinm	r10,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r10, r1)
 	lwz	r10,TI_PREEMPT(r10)
 	stw	r10,TI_PREEMPT(r9)
 	RESTORE_xSRR(SRR0,SRR1);
@@ -1156,7 +1156,7 @@ load_dbcr0:
 	lis	r11,global_dbcr0@ha
 	addi	r11,r11,global_dbcr0@l
 #ifdef CONFIG_SMP
-	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r9, r1)
 	lwz	r9,TI_CPU(r9)
 	slwi	r9,r9,3
 	add	r11,r11,r9
@@ -1197,7 +1197,7 @@ recheck:
 	LOAD_MSR_KERNEL(r10,MSR_KERNEL)
 	SYNC
 	MTMSRD(r10)		/* disable interrupts */
-	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r9, r1)
 	lwz	r9,TI_FLAGS(r9)
 	andi.	r0,r9,_TIF_NEED_RESCHED
 	bne-	do_resched
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index ed1718f..ba943b9 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -146,7 +146,7 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
 	REST_2GPRS(7,r1)
 	addi	r9,r1,STACK_FRAME_OVERHEAD
 #endif
-	clrrdi	r11,r1,THREAD_SHIFT
+	CURRENT_THREAD_INFO(r11, r1)
 	ld	r10,TI_FLAGS(r11)
 	andi.	r11,r10,_TIF_SYSCALL_T_OR_A
 	bne-	syscall_dotrace
@@ -181,7 +181,7 @@ syscall_exit:
 	bl	.do_show_syscall_exit
 	ld	r3,RESULT(r1)
 #endif
-	clrrdi	r12,r1,THREAD_SHIFT
+	CURRENT_THREAD_INFO(r12, r1)
 
 	ld	r8,_MSR(r1)
 #ifdef CONFIG_PPC_BOOK3S
@@ -262,7 +262,7 @@ syscall_dotrace:
 	ld	r7,GPR7(r1)
 	ld	r8,GPR8(r1)
 	addi	r9,r1,STACK_FRAME_OVERHEAD
-	clrrdi	r10,r1,THREAD_SHIFT
+	CURRENT_THREAD_INFO(r10, r1)
 	ld	r10,TI_FLAGS(r10)
 	b	.Lsyscall_dotrace_cont
 
@@ -499,7 +499,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT)
 2:
 #endif /* !CONFIG_PPC_BOOK3S */
 
-	clrrdi	r7,r8,THREAD_SHIFT	/* base of new stack */
+	CURRENT_THREAD_INFO(r7, r8)  /* base of new stack */
 	/* Note: this uses SWITCH_FRAME_SIZE rather than INT_FRAME_SIZE
 	   because we don't need to leave the 288-byte ABI gap at the
 	   top of the kernel stack. */
@@ -559,7 +559,7 @@ _GLOBAL(ret_from_except_lite)
 #endif /* CONFIG_PPC_BOOK3E */
 
 #ifdef CONFIG_PREEMPT
-	clrrdi	r9,r1,THREAD_SHIFT	/* current_thread_info() */
+	CURRENT_THREAD_INFO(r9, r1)
 	li	r0,_TIF_NEED_RESCHED	/* bits to check */
 	ld	r3,_MSR(r1)
 	ld	r4,TI_FLAGS(r9)
@@ -574,7 +574,7 @@ _GLOBAL(ret_from_except_lite)
 	beq	restore		/* if not, just restore regs and return */
 
 	/* Check current_thread_info()->flags */
-	clrrdi	r9,r1,THREAD_SHIFT
+	CURRENT_THREAD_INFO(r9, r1)
 	ld	r4,TI_FLAGS(r9)
 	andi.	r0,r4,_TIF_USER_WORK_MASK
 	bne	do_work
@@ -782,7 +782,7 @@ do_work:
 1:	bl	.preempt_schedule_irq
 
 	/* Re-test flags and eventually loop */
-	clrrdi	r9,r1,THREAD_SHIFT
+	CURRENT_THREAD_INFO(r9, r1)
 	ld	r4,TI_FLAGS(r9)
 	andi.	r0,r4,_TIF_NEED_RESCHED
 	bne	1b
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 7215cc2..2f86db6 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -222,7 +222,7 @@ exc_##n##_bad_stack:							    \
  * interrupts happen before the wait instruction.
  */
 #define CHECK_NAPPING()							\
-	clrrdi	r11,r1,THREAD_SHIFT;					\
+	CURRENT_THREAD_INFO(r11, r1);					\
 	ld	r10,TI_LOCAL_FLAGS(r11);				\
 	andi.	r9,r10,_TLF_NAPPING;					\
 	beq+	1f;							\
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 1c06d29..8ad3468 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -851,7 +851,7 @@ BEGIN_FTR_SECTION
 	bne-	do_ste_alloc		/* If so handle it */
 END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB)
 
-	clrrdi	r11,r1,THREAD_SHIFT
+	CURRENT_THREAD_INFO(r11, r1)
 	lwz	r0,TI_PREEMPT(r11)	/* If we're in an "NMI" */
 	andis.	r0,r0,NMI_MASK@h	/* (i.e. an irq when soft-disabled) */
 	bne	77f			/* then don't call hash_page now */
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 1f4434a..7e7bd88 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -192,7 +192,7 @@ _ENTRY(__early_start)
 	li	r0,0
 	stwu	r0,THREAD_SIZE-STACK_FRAME_OVERHEAD(r1)
 
-	rlwinm  r22,r1,0,0,31-THREAD_SHIFT      /* current thread_info */
+	CURRENT_THREAD_INFO(r22, r1)
 	stw	r24, TI_CPU(r22)
 
 	bl	early_init
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index 15c611d..1686916 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -135,7 +135,7 @@ BEGIN_FTR_SECTION
 	DSSALL
 	sync
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
-	rlwinm	r9,r1,0,0,31-THREAD_SHIFT	/* current thread_info */
+	CURRENT_THREAD_INFO(r9, r1)
 	lwz	r8,TI_LOCAL_FLAGS(r9)	/* set napping bit */
 	ori	r8,r8,_TLF_NAPPING	/* so when we take an exception */
 	stw	r8,TI_LOCAL_FLAGS(r9)	/* it will return to our caller */
@@ -158,7 +158,7 @@ _GLOBAL(power_save_ppc32_restore)
 	stw	r9,_NIP(r11)		/* make it do a blr */
 
 #ifdef CONFIG_SMP
-	rlwinm	r12,r11,0,0,31-THREAD_SHIFT
+	CURRENT_THREAD_INFO(r12, r11)
 	lwz	r11,TI_CPU(r12)		/* get cpu number * 4 */
 	slwi	r11,r11,2
 #else
diff --git a/arch/powerpc/kernel/idle_book3e.S b/arch/powerpc/kernel/idle_book3e.S
index ff007b5..4c7cb400 100644
--- a/arch/powerpc/kernel/idle_book3e.S
+++ b/arch/powerpc/kernel/idle_book3e.S
@@ -60,7 +60,7 @@ _GLOBAL(book3e_idle)
 1:	/* Let's set the _TLF_NAPPING flag so interrupts make us return
 	 * to the right spot
 	*/
-	clrrdi	r11,r1,THREAD_SHIFT
+	CURRENT_THREAD_INFO(r11, r1)
 	ld	r10,TI_LOCAL_FLAGS(r11)
 	ori	r10,r10,_TLF_NAPPING
 	std	r10,TI_LOCAL_FLAGS(r11)
diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S
index 4f0ab85..1544866 100644
--- a/arch/powerpc/kernel/idle_e500.S
+++ b/arch/powerpc/kernel/idle_e500.S
@@ -21,7 +21,7 @@
 	.text
 
 _GLOBAL(e500_idle)
-	rlwinm	r3,r1,0,0,31-THREAD_SHIFT	/* current thread_info */
+	CURRENT_THREAD_INFO(r3, r1)
 	lwz	r4,TI_LOCAL_FLAGS(r3)	/* set napping bit */
 	ori	r4,r4,_TLF_NAPPING	/* so when we take an exception */
 	stw	r4,TI_LOCAL_FLAGS(r3)	/* it will return to our caller */
@@ -96,7 +96,7 @@ _GLOBAL(power_save_ppc32_restore)
 	stw	r9,_NIP(r11)		/* make it do a blr */
 
 #ifdef CONFIG_SMP
-	rlwinm	r12,r1,0,0,31-THREAD_SHIFT
+	CURRENT_THREAD_INFO(r12, r1)
 	lwz	r11,TI_CPU(r12)		/* get cpu number * 4 */
 	slwi	r11,r11,2
 #else
diff --git a/arch/powerpc/kernel/idle_power4.S b/arch/powerpc/kernel/idle_power4.S
index 2c71b0f..e3edaa1 100644
--- a/arch/powerpc/kernel/idle_power4.S
+++ b/arch/powerpc/kernel/idle_power4.S
@@ -59,7 +59,7 @@ BEGIN_FTR_SECTION
 	DSSALL
 	sync
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
-	clrrdi	r9,r1,THREAD_SHIFT	/* current thread_info */
+	CURRENT_THREAD_INFO(r9, r1)
 	ld	r8,TI_LOCAL_FLAGS(r9)	/* set napping bit */
 	ori	r8,r8,_TLF_NAPPING	/* so when we take an exception */
 	std	r8,TI_LOCAL_FLAGS(r9)	/* it will return to our caller */
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 386d57f..407e293 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -179,7 +179,7 @@ _GLOBAL(low_choose_750fx_pll)
 	mtspr	SPRN_HID1,r4
 
 	/* Store new HID1 image */
-	rlwinm	r6,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r6, r1)
 	lwz	r6,TI_CPU(r6)
 	slwi	r6,r6,2
 	addis	r6,r6,nap_save_hid1@ha
@@ -699,7 +699,7 @@ _GLOBAL(kernel_thread)
 #ifdef CONFIG_SMP
 _GLOBAL(start_secondary_resume)
 	/* Reset stack */
-	rlwinm	r1,r1,0,0,(31-THREAD_SHIFT)	/* current_thread_info() */
+	CURRENT_THREAD_INFO(r1, r1)
 	addi	r1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD
 	li	r3,0
 	stw	r3,0(r1)		/* Zero the stack frame pointer	*/
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
index 0fa2ef7..c8c7a04 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -161,11 +161,7 @@
 	mtspr	SPRN_EPLC, r8
 
 	/* disable preemption, so we are sure we hit the fixup handler */
-#ifdef CONFIG_PPC64
-	clrrdi	r8,r1,THREAD_SHIFT
-#else
-	rlwinm	r8,r1,0,0,31-THREAD_SHIFT       /* current thread_info */
-#endif
+	CURRENT_THREAD_INFO(r8, r1)
 	li	r7, 1
 	stw	r7, TI_PREEMPT(r8)
 
diff --git a/arch/powerpc/mm/hash_low_32.S b/arch/powerpc/mm/hash_low_32.S
index b13d589..115347f 100644
--- a/arch/powerpc/mm/hash_low_32.S
+++ b/arch/powerpc/mm/hash_low_32.S
@@ -184,7 +184,7 @@ _GLOBAL(add_hash_page)
 	add	r3,r3,r0		/* note create_hpte trims to 24 bits */
 
 #ifdef CONFIG_SMP
-	rlwinm	r8,r1,0,0,(31-THREAD_SHIFT) /* use cpu number to make tag */
+	CURRENT_THREAD_INFO(r8, r1)	/* use cpu number to make tag */
 	lwz	r8,TI_CPU(r8)		/* to go in mmu_hash_lock */
 	oris	r8,r8,12
 #endif /* CONFIG_SMP */
@@ -545,7 +545,7 @@ _GLOBAL(flush_hash_pages)
 #ifdef CONFIG_SMP
 	addis	r9,r7,mmu_hash_lock@ha
 	addi	r9,r9,mmu_hash_lock@l
-	rlwinm	r8,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r8, r1)
 	add	r8,r8,r7
 	lwz	r8,TI_CPU(r8)
 	oris	r8,r8,9
@@ -639,7 +639,7 @@ _GLOBAL(flush_hash_patch_B)
  */
 _GLOBAL(_tlbie)
 #ifdef CONFIG_SMP
-	rlwinm	r8,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r8, r1)
 	lwz	r8,TI_CPU(r8)
 	oris	r8,r8,11
 	mfmsr	r10
@@ -677,7 +677,7 @@ _GLOBAL(_tlbie)
  */
 _GLOBAL(_tlbia)
 #if defined(CONFIG_SMP)
-	rlwinm	r8,r1,0,0,(31-THREAD_SHIFT)
+	CURRENT_THREAD_INFO(r8, r1)
 	lwz	r8,TI_CPU(r8)
 	oris	r8,r8,10
 	mfmsr	r10
diff --git a/arch/powerpc/sysdev/6xx-suspend.S b/arch/powerpc/sysdev/6xx-suspend.S
index 21cda08..cf48e9c 100644
--- a/arch/powerpc/sysdev/6xx-suspend.S
+++ b/arch/powerpc/sysdev/6xx-suspend.S
@@ -29,7 +29,7 @@ _GLOBAL(mpc6xx_enter_standby)
 	ori	r5, r5, ret_from_standby@l
 	mtlr	r5
 
-	rlwinm	r5, r1, 0, 0, 31-THREAD_SHIFT
+	CURRENT_THREAD_INFO(r5, r1)
 	lwz	r6, TI_LOCAL_FLAGS(r5)
 	ori	r6, r6, _TLF_SLEEPING
 	stw	r6, TI_LOCAL_FLAGS(r5)
-- 
1.7.3.4

^ permalink raw reply related

* RE: linux-next: build failure after merge of the kvm-ppc tree
From: Yoder Stuart-B08248 @ 2012-07-05 14:20 UTC (permalink / raw)
  To: Alexander Graf, Stephen Rothwell
  Cc: linux-next@vger.kernel.org, ppc-dev, linux-kernel@vger.kernel.org
In-Reply-To: <92A87EB2-E859-456C-85DE-7F0A4CC5F127@suse.de>



> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, July 05, 2012 1:03 AM
> To: Stephen Rothwell
> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Yoder Stuar=
t-B08248; ppc-dev
> Subject: Re: linux-next: build failure after merge of the kvm-ppc tree
>=20
>=20
> On 05.07.2012, at 07:49, Stephen Rothwell wrote:
>=20
> > Hi Alexander,
> >
> > After merging the kvm-ppc tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> > arch/powerpc/kernel/exceptions-64s.S:479: Error: wrong number of operan=
ds
> > arch/powerpc/kernel/exceptions-64s.S:486: Error: wrong number of operan=
ds
> > arch/powerpc/kernel/exceptions-64s.S:486: Error: wrong number of operan=
ds
> > arch/powerpc/kernel/exceptions-64s.S:487: Error: wrong number of operan=
ds
> > arch/powerpc/kernel/exceptions-64s.S:487: Error: wrong number of operan=
ds
> > arch/powerpc/kernel/exceptions-64s.S:494: Error: wrong number of operan=
ds
> > arch/powerpc/kernel/exceptions-64s.S:494: Error: wrong number of operan=
ds
> >
> > Caused by commit bc8cc4993e19 ("PPC: use CURRENT_THREAD_INFO instead of
> > open coded assembly").  The fact that this patch has problems was alrea=
dy
> > pointed out on the linuxppc-dev mailing list and it clearly hasn't been
> > build tested.
> >
> > I have used the version of the kvm-ppc tree from next-20120703 for toda=
y.
>=20
> Ah, yes, thanks. I kept the old, broken version in my tree to make sure I=
 have the dependencies for (and
> don't forget) the (hopefully good) patches that follow on top, but was pl=
anning to replace it once we
> have a new version of the CURRENT_THREAD_INFO one.
>=20
> Stuart, could you please send a new version of the CURRENT_THREAD_INFO pa=
tch?

Yes, will send that shortly.

Stuart

^ permalink raw reply

* RE: [Qemu-ppc] [RFC PATCH 03/17] KVM: PPC64: booke: Add EPCR support in sregs
From: Caraman Mihai Claudiu-B02008 @ 2012-07-05 12:54 UTC (permalink / raw)
  To: Alexander Graf
  Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
	kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <4FF584AE.1080805@suse.de>

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, July 05, 2012 3:13 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
> Subject: Re: [Qemu-ppc] [RFC PATCH 03/17] KVM: PPC64: booke: Add EPCR
> support in sregs
>=20
> On 07/05/2012 01:49 PM, Caraman Mihai Claudiu-B02008 wrote:
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Wednesday, July 04, 2012 4:34 PM
> >> To: Caraman Mihai Claudiu-B02008
> >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> >> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
> >> Subject: Re: [Qemu-ppc] [RFC PATCH 03/17] KVM: PPC64: booke: Add EPCR
> >> support in sregs
> >>
> >>
> >> On 25.06.2012, at 14:26, Mihai Caraman wrote:
> >>
> >>> Add KVM_SREGS_E_64 feature and EPCR spr support in get/set sregs
> >>> for 64-bit hosts.
> >> Please also implement a ONE_REG interface while at it. Over time, I'd
> >> like to move towards ONE_REG instead of the messy regs/sregs API.
> > ONE_REG doesn't seem to be implemented at all for book3e, I looked at
> > kvm_vcpu_ioctl_set_one_reg/kvm_vcpu_ioctl_get_one_reg in booke.c file.
> >
> > I can take care of it soon but in a different patch set. It's ok like
> this?
>=20
> Do it in a different patch, but as part of this patch set.

Hmm ... then if you don't disagree I will do it as a prerequisite patch sin=
ce I want
to keep this patchset strictly for 64-bit support.
I am not familiar with ONE_REG, is qemu tailored to use it? I need a way to=
 test it.

-Mike

^ permalink raw reply

* Re: [PATCH v3] printk: Have printk() never buffer its data
From: Kay Sievers @ 2012-07-05 12:50 UTC (permalink / raw)
  To: Michael Neuling
  Cc: Greg Kroah-Hartman, LKML, Steven Rostedt, Paul E. McKenney,
	linuxppc-dev, Joe Perches, Andrew Morton, Wu Fengguang,
	Linus Torvalds, Ingo Molnar
In-Reply-To: <CAPXgP11+j+fDexHHmAZbBBidtrydrpWeh3DGWOhkuoybNj9skA@mail.gmail.com>

On Thu, 2012-07-05 at 13:47 +0200, Kay Sievers wrote:
> On Thu, Jul 5, 2012 at 12:20 PM, Michael Neuling <mikey@neuling.org> 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 consistently in show_regs().  Every printk without a
> > newline.  ie I get this:
> > ---
> > NIP: c000000000048164 LR: c000000000048160 CTR: 0000000000000000
> > REGS: c00000007e59fb50 TRAP: 0700   Tainted: G        W     (3.5.0-rc5-mikey)
> > MSR: 9000000000021032
> > <
> > SF
> > ,HV
> > ,ME
> > ,IR
> > ,DR
> > ,RI
> >>
> >   CR: 28000042  XER: 22000000
> > SOFTE: 0
> > CFAR: c0000000007402f8
> > TASK = c00000007e56bb40[0] 'swapper/1' THREAD: c00000007e59c000
> >  CPU: 1
> > ---
> >
> > It's consistent for printks without newlines in show_regs().  MSR
> > through to XER should all be on the same line.
> 
> I see. Something to fix then, I'll have a look.
> 
> Does this happen only very early during bootup, or also later when the
> box fully initialized?
> 
> The output of 'dmesg' later looks always correct, right?

If it's an early printk issue like it looks like, where stuff got
printed before we had any console registered, this might fix the issue
you are seeing.

Could you possibly try this patch?

Thanks,
Kay


--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1957,6 +1951,12 @@ skip:
 			 */
 			console_idx = log_next(console_idx);
 			console_seq++;
+			/*
+			 * We will get here again when we register a new
+			 * CON_PRINTBUFFER console. Clear the flag so we
+			 * will properly dump everything later.
+			 */
+			msg->flags &= ~LOG_NOCONS;
 			goto skip;
 		}
 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox