* Re: [PATCH v2] powerpc/40x: Add APM8018X SOC support
From: Josh Boyer @ 2011-11-30 21:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Tanmay Inamdar, linux-kernel
In-Reply-To: <1322686997.29041.11.camel@pasglop>
On Wed, Nov 30, 2011 at 4:03 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2011-11-29 at 12:31 +0530, Tanmay Inamdar wrote:
>> The AppliedMicro APM8018X embedded processor targets embedded applications that
>> require low power and a small footprint. It features a PowerPC 405 processor
>> core built in a 65nm low-power CMOS process with a five-stage pipeline executing
>> up to one instruction per cycle. The family has 128-kbytes of on-chip memory,
>> a 128-bit local bus and on-chip DDR2 SDRAM controller with 16-bit interface.
>
> Thanks, looks much better.
Yes, agreed. So much better I already sent it to Ben in a pull request.
josh
^ permalink raw reply
* Re: [PATCH 4/6] powerpc/boot: Add extended precision shifts to the boot wrapper.
From: Tony Breeds @ 2011-11-30 23:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: LinuxPPC-dev
In-Reply-To: <CA+5PVA6kBquh2=sPy25PKGSMBWvoZFFvZjrL4bgdmddFgjyaQA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
On Wed, Nov 30, 2011 at 06:45:37AM -0500, Josh Boyer wrote:
> However, adding this code and wonderful and all but why do we need to
> add it? Changelog should say why.
Okay changelog updated to:
powerpc/boot: Add extended precision shifts to the boot wrapper.
The upcoming currituck patches will need to do 64-bit shifts which will
fail with undefined symbol without this patch.
I looked at linking against libgcc but we can't guarantee that libgcc
was compiled with soft-float. Also Using ../lib/div64.S or
../kernel/misc_32.S, this will break the build as the .o's need to be
built with different flags for the bootwrapper vs the kernel. So for
now the easiest option is to just copy code from
arch/powerpc/kernel/misc_32.S I don't think this code changes too often ;P
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/boot: Add mfdcrx
From: Tony Breeds @ 2011-11-30 23:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: LinuxPPC-dev
In-Reply-To: <F91E9007-5DA5-4E3A-993E-EA680DE08D79@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
On Wed, Nov 30, 2011 at 02:09:20PM +0100, Segher Boessenkool wrote:
> >+#define mfdcrx(rn) \
> >+ ({ \
> >+ unsigned long rval; \
> >+ asm volatile("mfdcrx %0,%1" : "=r"(rval) : "g"(rn)); \
> >+ rval; \
> >+ })
>
> "g" is never correct on PowerPC, you want "r" here. You can write
> this as a static inline btw, you only need the #define stuff when
> there is an "i" constraint involved.
Okay I'll change it to "i", mostly I used a #define to match the style
of m[tf]dcr. To be honnest I didn't know about the issue with "i"
constraints and static inlines.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/boot: Add mfdcrx
From: Tony Breeds @ 2011-11-30 23:35 UTC (permalink / raw)
To: Segher Boessenkool, Benjamin Herrenschmidt, Josh Boyer,
LinuxPPC-dev
In-Reply-To: <20111130233027.GC15560@thor.bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 176 bytes --]
On Thu, Dec 01, 2011 at 10:30:27AM +1100, Tony Breeds wrote:
> Okay I'll change it to "i", mostly I used a #define to match the style
Of course I menat "r" here.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Please pull 'next' branch of new 4xx tree
From: Stephen Rothwell @ 2011-11-30 23:41 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <CA+5PVA6ahzxWHqBiESw8x7RVC1n8hjqBPvMnQ8qfb=bpwMeuzQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Hi Josh,
On Wed, 30 Nov 2011 10:14:52 -0500 Josh Boyer <jwboyer@gmail.com> wrote:
>
> Stephen, can you switch the linux-next tree to use this instead?
>
> are available in the git repository at:
> git://git.infradead.org/users/jwboyer/powerpc-4xx.git next
I have switched to that now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 02/10] powerpc: Consolidate mpic_alloc() OF address translation
From: Paul Mackerras @ 2011-12-01 1:04 UTC (permalink / raw)
To: Kyle Moffett; +Cc: linuxppc-dev
In-Reply-To: <1322593117-29938-3-git-send-email-Kyle.D.Moffett@boeing.com>
On Tue, Nov 29, 2011 at 01:58:29PM -0500, Kyle Moffett wrote:
> diff --git a/arch/powerpc/platforms/powermac/pic.c b/arch/powerpc/platforms/powermac/pic.c
> index 901bfbd..44f9774 100644
> --- a/arch/powerpc/platforms/powermac/pic.c
> +++ b/arch/powerpc/platforms/powermac/pic.c
> @@ -498,15 +498,10 @@ static struct mpic * __init pmac_setup_one_mpic(struct device_node *np,
> int master)
> {
> const char *name = master ? " MPIC 1 " : " MPIC 2 ";
> - struct resource r;
> struct mpic *mpic;
> unsigned int flags = master ? MPIC_PRIMARY : 0;
> int rc;
>
> - rc = of_address_to_resource(np, 0, &r);
> - if (rc)
> - return NULL;
> -
This gets me an unused variable warning, which because we compile
arch/powerpc with -Werror is fatal:
CC arch/powerpc/platforms/powermac/pic.o
/home/paulus/kernel/kvm-merge/arch/powerpc/platforms/powermac/pic.c: In function ‘pmac_setup_one_mpic’:
/home/paulus/kernel/kvm-merge/arch/powerpc/platforms/powermac/pic.c:491:6: error: unused variable ‘rc’ [-Werror=unused-variable]
cc1: all warnings being treated as errors
Need to remove the declaration of rc as well.
Paul.
^ permalink raw reply
* Re: [PATCH 1/6] 44x/pci: Continue pci setup even if there is no sdr-base in the device-tree
From: Tony Breeds @ 2011-12-01 1:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: LinuxPPC-dev
In-Reply-To: <1322631973.21641.42.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On Wed, Nov 30, 2011 at 04:46:13PM +1100, Benjamin Herrenschmidt wrote:
> If you don't expect an sdr-base as part of the normal operations of that
> bridge, don't bring a message that makes me think something is wrong :-)
>
> Just changing the severity isn't enough. you should just remove the
> message and later on, print/warn/error out if you decide you actually
> need an sdr-base (such as in the backend).
Okay no problem.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] powerpc/nvram: Add spinlock to oops_to_nvram to prevent oops in compression code.
From: Anton Blanchard @ 2011-12-01 1:46 UTC (permalink / raw)
To: benh, paulus, hbabu, jkenisto; +Cc: linuxppc-dev
When issuing a system reset we almost always oops in the oops_to_nvram
code because multiple CPUs are using the deflate work area. Add a
spinlock to protect it.
To play it safe I'm using trylock to avoid locking up if the NVRAM
code oopses. This means we might miss multiple CPUs oopsing at exactly
the same time but I think it's best to play it safe for now. Once we
are happy with the reliability we can change it to a full spinlock.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/platforms/pseries/nvram.c
===================================================================
--- linux-build.orig/arch/powerpc/platforms/pseries/nvram.c 2011-12-01 09:44:27.205568463 +1100
+++ linux-build/arch/powerpc/platforms/pseries/nvram.c 2011-12-01 12:36:49.334478156 +1100
@@ -634,6 +634,8 @@ static void oops_to_nvram(struct kmsg_du
{
static unsigned int oops_count = 0;
static bool panicking = false;
+ static DEFINE_SPINLOCK(lock);
+ unsigned long flags;
size_t text_len;
unsigned int err_type = ERR_TYPE_KERNEL_PANIC_GZ;
int rc = -1;
@@ -664,6 +666,9 @@ static void oops_to_nvram(struct kmsg_du
if (clobbering_unread_rtas_event())
return;
+ if (!spin_trylock_irqsave(&lock, flags))
+ return;
+
if (big_oops_buf) {
text_len = capture_last_msgs(old_msgs, old_len,
new_msgs, new_len, big_oops_buf, big_oops_buf_sz);
@@ -679,4 +684,6 @@ static void oops_to_nvram(struct kmsg_du
(void) nvram_write_os_partition(&oops_log_partition, oops_buf,
(int) (sizeof(*oops_len) + *oops_len), err_type, ++oops_count);
+
+ spin_unlock_irqrestore(&lock, flags);
}
^ permalink raw reply
* Re: [PATCH] powerpc/nvram: Add spinlock to oops_to_nvram to prevent oops in compression code.
From: Benjamin Herrenschmidt @ 2011-12-01 2:11 UTC (permalink / raw)
To: Anton Blanchard; +Cc: jkenisto, paulus, linuxppc-dev
In-Reply-To: <20111201124645.24c6e54f@kryten>
On Thu, 2011-12-01 at 12:46 +1100, Anton Blanchard wrote:
> When issuing a system reset we almost always oops in the oops_to_nvram
> code because multiple CPUs are using the deflate work area. Add a
> spinlock to protect it.
>
> To play it safe I'm using trylock to avoid locking up if the NVRAM
> code oopses. This means we might miss multiple CPUs oopsing at exactly
> the same time but I think it's best to play it safe for now. Once we
> are happy with the reliability we can change it to a full spinlock.
How would we miss ?
trylock does loop on stwcx. failure, it doesn't loop if the lock is
-taken-, so if the lock is only used for actually dealing with the oops
the only "miss" is because somebody already got it... or am I missing
something ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/nvram: Add spinlock to oops_to_nvram to prevent oops in compression code.
From: Anton Blanchard @ 2011-12-01 2:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: jkenisto, paulus, linuxppc-dev
In-Reply-To: <1322705472.3729.11.camel@pasglop>
Hi Ben,
> How would we miss ?
>
> trylock does loop on stwcx. failure, it doesn't loop if the lock is
> -taken-, so if the lock is only used for actually dealing with the
> oops the only "miss" is because somebody already got it... or am I
> missing something ?
I'm thinking of two CPUs that enter at exactly the same time either
through a system reset or an ugly bug (writing junk at 0x900 so the
decrementer exception gets an oops). Probably unlikely enough that we
don't care.
Anton
^ permalink raw reply
* Re: lmb_alloc() and page memory overlap
From: Benjamin Herrenschmidt @ 2011-12-01 4:00 UTC (permalink / raw)
To: Prashant Bhole; +Cc: linuxppc-dev
In-Reply-To: <CAD6p20evHeESH1UwpB4rg8NTxndAtQW9C1S1bpJWFLmS-rOu5w@mail.gmail.com>
On Tue, 2011-11-29 at 18:51 +0530, Prashant Bhole wrote:
> Hi,
> I am using custom 460ex board with kernel version 2.6.30.
> I noticed that page_alloc() is returning a page whose memory
> is already allocated by lmb_alloc() while unflattening the device
> tree. As per my knowledge the memory allocated by lmb_alloc()
> should be reserved till the end, right?
This should have been fixed in memblock in recent kernel, at least I
believe it is. It looks like this is caused by overlapping lmb_reserve()
at boot (or lmb_reserve() overlapping an lmb_alloc'ated region which
boils down to the same thing).
Old lmb didn't deal with that well at all and that lead to corruption of
the lmb list. We fixed that in
8f7a66051b7523108c5aefb08c6a637e54aedc47
mm/memblock: properly handle overlaps and fix error path
Which got merged in 2.6.39.
If you absolutely need to stick to 2.6.30, you can try backporting the
fix to lmb.
Cheers,
Ben.
> Some more explanation of what I observed:
>
> unflatten_device_tree() allocates memory, which will be used
> for "struct node" objects in the device tree. I obtained base
> address of allocated memory in "unsigned long base_mem"
>
> Now I executed the following code after the kernel booted properly.
>
> ---------------------------------------------------------------
> extern unsigned long mem; // lmb_alloc() memory
> struct page *test_page = virt_to_page(mem);
> struct page *new_page = NULL;
>
> while(1)
> {
> new_page = NULL;
> new_page = alloc_page(GFP_KERNEL);
> if(!new_page)
> {
> printk("Allocation failed\n");
> while(1);
> }
> if(test_page == new_page)
> {
> printk("Memory already allocated by lmb_alloc\n");
> while(1);
> }
> }
> ---------------------------------------------------------------
>
> After many page allocations, I always hit the condition (test_page == new_page).
> Am I doing anything wrong here?
> Has anybody faced this kind of problem before?
>
>
> I also noticed that lmb_dump_all() shows 2 regions overlapping (last two):
>
> LMB configuration:
> rmo_size = 0x30000000
> memory.size = 0x30000000
> memory.cnt = 0x1
> memory[0x0] 0x0000000000000000 - 0x000000002fffffff, 0x30000000 bytes
> reserved.cnt = 0x6
> reserved[0x0] 0x0000000000000000 - 0x00000000006bffff, 0x6c0000 bytes
> reserved[0x1] 0x0000000000ffa000 - 0x0000000000ffcfff, 0x3000 bytes
> reserved[0x2] 0x000000002fdd0000 - 0x000000002fddffff, 0x10000 bytes
> reserved[0x3] 0x000000002fde4000 - 0x000000002fde9fff, 0x6000 bytes
> reserved[0x4] 0x000000002fdeb060 - 0x000000002ffff768, 0x214709 bytes
> reserved[0x5] 0x000000002fdee000 - 0x000000002ffff769, 0x21176a bytes
>
>
> Thanks,
> Prashant
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 6/6] 44x/currituck: Add support for the new IBM currituck platform
From: Tony Breeds @ 2011-12-01 4:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: LinuxPPC-dev
In-Reply-To: <1322634022.21641.61.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 4483 bytes --]
On Wed, Nov 30, 2011 at 05:20:22PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2011-11-30 at 16:24 +1100, Tony Breeds wrote:
> > + plb {
> > + compatible = "ibm,plb-4xx", "ibm,plb4"; /* Could be PLB6, doesn't matter */
>
> Then make it plb6 and add it to the probe list. Might have to whack it's
> configuration registers one day etc...
Done.
> > + * XXX: 1 TB address space, do we really care past
> > + * 4 GB and should we expand cell width?
> > + */
>
> For OPB probably not :-)
Fixed.
> That doesn't seem like a very useful pair of statements or useful debug
> message....
All the DBG cruft is gone.
> > + for(i = 0; i < MAX_RANKS; i++){
> > + reg = mfdcrx(DDR3_MR0CF + i);
> > + printf("%s: reg=0x%08x\r\n", __func__, reg);
>
> All that debug is pretty gross, keep it if you wish but make it a bit
> neater and/or wrap it in DBG
Yeah that was an oversight.
> > + if (reg & 0x01) {
>
> if (!(reg & 1))
> continue;
>
> avoids too much indent
Done.
> > + dt_fixup_memory(0x0ULL, ibm_currituck_memsize);
>
> Ok, I see why the global... I'd still prefer if the detect function just
> returned the value and the caller whacks the global.
Fixed.
> > + while ((devp = find_node_by_devtype(devp, "pci"))) {
> > + if (getprop(devp, "dma-ranges", &dma_ranges[0], sizeof(dma_ranges)) < 0) {
>
> Can't you replace &dma_ranges[0] with just dma_ranges ?
Yes, Fixed.
> > +#define SPRN_PIR 0x11E /* Processor Indentification Register */
>
> That should go elsewhere along with the other SPR definitions.
There isn't a std. place in the bootwrapper.
>
> > +void platform_init(void)
> > +{
> > + /* Cap the zImage to 512MB */
>
> Any reason ? If yes, please document it a bit more.
XXX
> > + node = fdt_node_offset_by_prop_value(_dtb_start, -1, "device_type",
> > + "cpu", sizeof("cpu"));
> > + if (!node)
> > + fatal("Cannot find cpu node\n");
>
> The above will return -a- CPU node... you have several and you don't
> know which one. You should probably iterate accross all of them.
I'm just trying to get the timebase-frequency, this willbe the same on
all CPUs (at least I hope so ;P) so I don't really care which CPU node I
get.
> > + /* FIXME: Check this works */
Grr that comment shouldn't be there. It does work :)
> > +#define PVR_476CURRITUCK 0x7ff50000
>
> My understanding is that the currituck was the platform, not the chip,
> and that the chip was called something like 476FPE, am I wrong ?
No you're correct, I was confused about the boundry between 476fpe and
currituck.
> > + cmplwi cr0,r3,PVR_476CURRITUCK@h
> > + beq head_start_47x
>
> So at some point, they gave us the magic foo to do with the PVR to
> identify any 476... I'll try to dig that out of my email archives.
Yeah I have that I'll work out the correct way to the the mask and
test.
> > +++ b/arch/powerpc/platforms/44x/ppc47x.c
>
> Call the file currituck.c
Sure.
> > +static void __devinit quirk_ppc_currituck_usb_fixup(struct pci_dev *dev)
> > +{
> > + pci_write_config_dword(dev, 0xe0, 0x0114231f);
> > + pci_write_config_dword(dev, 0xe4, 0x00006c40);
> > +}
>
> Pleae document better what you are doing here and also test
> that you are indeed on the right platform so you don't end up
> whacking bits on USB controllers on other platforms that happen
> to be compiled in the same binary.
Sure, no problem.
> Ok, I'll have to fixup that vs. Kyle patches but the good thing is that
> it will make things even simpler.
Thanks.
> Now pretty much everything in this platform file is generic I believe.
> We could move it all to ppc44x_simple.c. The only things that are not
> are the USB quirk and the interrupt fixup.
>
> The USB quirk which should have a compatible test for the platform to
> make sure we don't run it on something else. For such a simple quirk, I
> think it's fine ot have it in ppc44x_simple.c or in drivers/pci/quirk.c
>
> For the interrupt fixup, we can probably address it entirely in the
> device-tree, though that means exposing a bunch of on-board bridges
> which is only midly annoying.
>
> Anyways, we can discuss that (or maybe an even better option)
> tomorrow :-)
Okay I look forward to it :)
> Again, you are mixing the SoC with the board here. afaik, currituck is
> the board, not the SoC.
Fixed.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] 44x/currituck: Add support for the new IBM currituck platform
From: Tony Breeds @ 2011-12-01 4:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: LinuxPPC-dev
In-Reply-To: <6E90E509-7B5B-4475-A2B1-9F10FD943F4E@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
On Wed, Nov 30, 2011 at 07:23:40AM -0600, Kumar Gala wrote:
> Split the board support patches from the SoC support.
Will do, as I said to Ben I was confused.
> This seems like it should be PVR_476FPE
Yup. Fixed.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: lmb_alloc() and page memory overlap
From: Prashant Bhole @ 2011-12-01 4:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1322712006.3729.14.camel@pasglop>
On Thu, Dec 1, 2011 at 9:30 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2011-11-29 at 18:51 +0530, Prashant Bhole wrote:
>> Hi,
>> I am using custom 460ex board with kernel version 2.6.30.
>> I noticed that page_alloc() is returning a page whose memory
>> is already allocated by lmb_alloc() while unflattening the device
>> tree. As per my knowledge the memory allocated by lmb_alloc()
>> should be reserved till the end, right?
>
> This should have been fixed in memblock in recent kernel, at least I
> believe it is. It looks like this is caused by overlapping lmb_reserve()
> at boot (or lmb_reserve() overlapping an lmb_alloc'ated region which
> boils down to the same thing).
>
> Old lmb didn't deal with that well at all and that lead to corruption of
> the lmb list. We fixed that in
>
> 8f7a66051b7523108c5aefb08c6a637e54aedc47
>
> =A0 =A0mm/memblock: properly handle overlaps and fix error path
>
> Which got merged in 2.6.39.
>
> If you absolutely need to stick to 2.6.30, you can try backporting the
> fix to lmb.
>
> Cheers,
> Ben.
>
I need to stick to 2.6.30, will try backporting the fix. Is this the same t=
hing
which is causing the wrong page (already allocated memory) allocation?
>> Some more explanation of what I observed:
>>
>> unflatten_device_tree() allocates memory, which will be used
>> for "struct node" objects in the device tree. I obtained base
>> address of allocated memory in "unsigned long base_mem"
>>
>> Now I executed the following code after the kernel booted properly.
>>
>> ---------------------------------------------------------------
>> extern unsigned long mem; // lmb_alloc() memory
>> struct page *test_page =3D virt_to_page(mem);
>> struct page *new_page =3D NULL;
>>
>> while(1)
>> {
>> =A0 =A0 new_page =3D NULL;
>> =A0 =A0 new_page =3D alloc_page(GFP_KERNEL);
>> =A0 =A0 if(!new_page)
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 printk("Allocation failed\n");
>> =A0 =A0 =A0 =A0 while(1);
>> =A0 =A0 }
>> =A0 =A0 if(test_page =3D=3D new_page)
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 =A0printk("Memory already allocated by lmb_alloc\n");
>> =A0 =A0 =A0 =A0 =A0while(1);
>> =A0 =A0 }
>> }
>> ---------------------------------------------------------------
>>
>> After many page allocations, I always hit the condition (test_page =3D=
=3D new_page).
>> Am I doing anything wrong here?
>> Has anybody faced this kind of problem before?
>>
>>
>> I also noticed that lmb_dump_all() shows 2 regions overlapping (last two=
):
>>
>> LMB configuration:
>> =A0rmo_size =A0 =A0=3D 0x30000000
>> =A0memory.size =3D 0x30000000
>> =A0memory.cnt =A0=3D 0x1
>> =A0memory[0x0] =A0 =A00x0000000000000000 - 0x000000002fffffff, 0x3000000=
0 bytes
>> =A0reserved.cnt =A0=3D 0x6
>> =A0reserved[0x0] =A00x0000000000000000 - 0x00000000006bffff, 0x6c0000 by=
tes
>> =A0reserved[0x1] =A00x0000000000ffa000 - 0x0000000000ffcfff, 0x3000 byte=
s
>> =A0reserved[0x2] =A00x000000002fdd0000 - 0x000000002fddffff, 0x10000 byt=
es
>> =A0reserved[0x3] =A00x000000002fde4000 - 0x000000002fde9fff, 0x6000 byte=
s
>> =A0reserved[0x4] =A00x000000002fdeb060 - 0x000000002ffff768, 0x214709 by=
tes
>> =A0reserved[0x5] =A00x000000002fdee000 - 0x000000002ffff769, 0x21176a by=
tes
>>
>>
>> Thanks,
>> Prashant
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
Thanks,
Prashant
^ permalink raw reply
* Re: lmb_alloc() and page memory overlap
From: Benjamin Herrenschmidt @ 2011-12-01 4:28 UTC (permalink / raw)
To: Prashant Bhole; +Cc: linuxppc-dev
In-Reply-To: <CAD6p20eX5uq=w5JU19+-x=bAPJ9tBSDanH46n22S6SFuFXbP_Q@mail.gmail.com>
> > This should have been fixed in memblock in recent kernel, at least I
> > believe it is. It looks like this is caused by overlapping lmb_reserve()
> > at boot (or lmb_reserve() overlapping an lmb_alloc'ated region which
> > boils down to the same thing).
> >
> > Old lmb didn't deal with that well at all and that lead to corruption of
> > the lmb list. We fixed that in
> >
> > 8f7a66051b7523108c5aefb08c6a637e54aedc47
> >
> > mm/memblock: properly handle overlaps and fix error path
> >
> > Which got merged in 2.6.39.
> >
> > If you absolutely need to stick to 2.6.30, you can try backporting the
> > fix to lmb.
> >
> > Cheers,
> > Ben.
> >
>
> I need to stick to 2.6.30, will try backporting the fix. Is this the same thing
> which is causing the wrong page (already allocated memory) allocation?
I can't say for sure but it looks like it could be.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 6/6] 44x/currituck: Add support for the new IBM currituck platform
From: Tony Breeds @ 2011-12-01 4:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Josh Boyer, LinuxPPC-dev
In-Reply-To: <20111201040524.GF15560@thor.bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
On Thu, Dec 01, 2011 at 03:05:24PM +1100, Tony Breeds wrote:
> On Wed, Nov 30, 2011 at 05:20:22PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2011-11-30 at 16:24 +1100, Tony Breeds wrote:
<snip>
> > > +void platform_init(void)
> > > +{
> > > + /* Cap the zImage to 512MB */
> >
> > Any reason ? If yes, please document it a bit more.
>
> XXX
Where 'XXX' means come back and anser this point /before/ hitting send.
Basically is was lazyness.
Now that I know the memsize I'll allow the zImage to use it all but
512MB should be enought for anywone right?
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* ppc4xx simple vs SoC's
From: Benjamin Herrenschmidt @ 2011-12-01 5:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
Hi Josh !
I was helping Tony with some of the Currituck stuff when I noticed an
oddity...
So we have various "SoC" config symbols such as 440EP, 460SX, etc...
that in turn select various bits & pieces that enable support for that
SoC (such as EMAC4 support or FPU support). Those only act as "enables"
for compiling of the code, there is still going to be a runtime check of
course.
Those SoC config symbols are not user selectable, they are meant to be
themselves select'ed by the board Kconfig entries.
However, the entry for ppc44x_simple doesn't select any of these,
meaning for example, AFAIK, that you don't get EMAC4 etc... I'm
surprised things work at all !
What am I missing ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/fsl-pci: Allow 64-bit PCIe devices to DMA to any memory address
From: Kumar Gala @ 2011-12-01 6:03 UTC (permalink / raw)
To: linuxppc-dev
There is an issue on FSL-BookE 64-bit devices (P5020) in which PCIe
devices that are capable of doing 64-bit DMAs (like an Intel e1000) do
not function and crash the kernel if we have >4G of memory in the system.
The reason is that the existing code only sets up one inbound window for
access to system memory across PCIe. That window is limited to a 32-bit
address space. So on systems we'll end up utilizing SWIOTLB for dma
mappings. However SWIOTLB dma ops implement dma_alloc_coherent() as
dma_direct_alloc_coherent(). Thus we can end up with dma addresses that
are not accessible because of the inbound window limitation.
We could possibly set the SWIOTLB alloc_coherent op to
swiotlb_alloc_coherent() however that does not address the issue since
the swiotlb_alloc_coherent() will behave almost identical to
dma_direct_alloc_coherent() since the devices coherent_dma_mask will be
greater than any address allocated by swiotlb_alloc_coherent() and thus
we'll never bounce buffer it into a range that would be dma-able.
The easiest and best solution is to just make it so that a 64-bit
capable device is able to DMA to any internal system address.
We accomplish this by opening up a second inbound window that maps all
of memory above the internal SoC address width so we can set it up to
access all of the internal SoC address space if needed.
We than fixup the dma_ops and dma_offset for PCIe devices with a dma
mask greater than the maximum internal SoC address.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_pci.c | 55 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4ce547e..8f92446 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -65,6 +65,30 @@ static int __init fsl_pcie_check_link(struct pci_controller *hose)
}
#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
+
+#define MAX_PHYS_ADDR_BITS 40
+static u64 pci64_dma_offset = 1ull << MAX_PHYS_ADDR_BITS;
+
+static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
+{
+ if (!dev->dma_mask || !dma_supported(dev, dma_mask))
+ return -EIO;
+
+ /*
+ * Fixup PCI devices that are able to DMA to above the physical
+ * address width of the SoC such that we can address any internal
+ * SoC address from across PCI if needed
+ */
+ if ((dev->bus == &pci_bus_type) &&
+ dma_mask >= DMA_BIT_MASK(MAX_PHYS_ADDR_BITS)) {
+ set_dma_ops(dev, &dma_direct_ops);
+ set_dma_offset(dev, pci64_dma_offset);
+ }
+
+ *dev->dma_mask = dma_mask;
+ return 0;
+}
+
static int __init setup_one_atmu(struct ccsr_pci __iomem *pci,
unsigned int index, const struct resource *res,
resource_size_t offset)
@@ -228,6 +252,37 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
hose->dma_window_base_cur = 0x00000000;
hose->dma_window_size = (resource_size_t)sz;
+
+ /*
+ * if we have >4G of memory setup second PCI inbound window to
+ * let devices that are 64-bit address capable to work w/o
+ * SWIOTLB and access the full range of memory
+ */
+ if (sz != mem) {
+ mem_log = __ilog2_u64(mem);
+
+ /* Size window up if we dont fit in exact power-of-2 */
+ if ((1ull << mem_log) != mem)
+ mem_log++;
+
+ piwar = (piwar & ~PIWAR_SZ_MASK) | (mem_log - 1);
+
+ /* Setup inbound memory window */
+ out_be32(&pci->piw[win_idx].pitar, 0x00000000);
+ out_be32(&pci->piw[win_idx].piwbear,
+ pci64_dma_offset >> 44);
+ out_be32(&pci->piw[win_idx].piwbar,
+ pci64_dma_offset >> 12);
+ out_be32(&pci->piw[win_idx].piwar, piwar);
+
+ /*
+ * install our own dma_set_mask handler to fixup dma_ops
+ * and dma_offset
+ */
+ ppc_md.dma_set_mask = fsl_pci_dma_set_mask;
+
+ pr_info("%s: Setup 64-bit PCI DMA window\n", name);
+ }
} else {
u64 paddr = 0;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 07/10] powerpc/mpic: Don't open-code dcr_resource_start
From: Michael Ellerman @ 2011-12-01 6:58 UTC (permalink / raw)
To: Kyle Moffett; +Cc: linuxppc-dev
In-Reply-To: <1322593117-29938-8-git-send-email-Kyle.D.Moffett@boeing.com>
On Tue, 2011-11-29 at 13:58 -0500, Kyle Moffett wrote:
> Don't open-code the OpenFirmware "dcr-reg" property lookup trying to map
> DCR resources. This makes the code a bit easier to read.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
> arch/powerpc/sysdev/mpic.c | 7 ++-----
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index e0216ff..6916ba5 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -319,11 +319,8 @@ static void _mpic_map_dcr(struct mpic *mpic, struct device_node *node,
> struct mpic_reg_bank *rb,
> unsigned int offset, unsigned int size)
> {
> - const u32 *dbasep;
> -
> - dbasep = of_get_property(node, "dcr-reg", NULL);
> -
> - rb->dhost = dcr_map(node, *dbasep + offset, size);
> + phys_addr_t phys_addr = dcr_resource_start(node);
Gives me:
arch/powerpc/sysdev/mpic.c:321: error: too few arguments to function 'dcr_resource_start'
Because you're missing index:
unsigned int dcr_resource_start(const struct device_node *np, unsigned int index)
cheers
--
^ permalink raw reply
* Re: [PATCH 10/10] powerpc/mpic: Add in-core support for cascaded MPICs
From: Michael Ellerman @ 2011-12-01 6:59 UTC (permalink / raw)
To: Kyle Moffett; +Cc: linuxppc-dev
In-Reply-To: <1322593117-29938-11-git-send-email-Kyle.D.Moffett@boeing.com>
On Tue, 2011-11-29 at 13:58 -0500, Kyle Moffett wrote:
> diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
> index cd00ca8..a0f5d28 100644
> --- a/arch/powerpc/platforms/cell/setup.c
> +++ b/arch/powerpc/platforms/cell/setup.c
> @@ -215,15 +202,6 @@ static void __init mpic_init_IRQ(void)
> if (mpic == NULL)
> continue;
> mpic_init(mpic);
> -
> - virq = irq_of_parse_and_map(dn, 0);
> - if (virq == NO_IRQ)
> - continue;
> -
> - printk(KERN_INFO "%s : hooking up to IRQ %d\n",
> - dn->full_name, virq);
> - irq_set_handler_data(virq, mpic);
> - irq_set_chained_handler(virq, cell_mpic_cascade);
> }
> }
This leaves virq unused, which breaks the build.
cheers
--
^ permalink raw reply
* Add support for the currituck 476 platform from IBM (v2)
From: Tony Breeds @ 2011-12-01 7:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Josh Boyer; +Cc: LinuxPPC-dev
Patches 1 to 3
Modify the 44x PCI code to work with 476fpe/currituck.
Patch 4
Is an old patch by Christoph Egger that fell through the cracks somehow.
Patches 5 and 6
Modify the bootwrapper to handle 476fpe/currituck
Patch 7
The SoC support.
Patch 8
The currituck board support.
^ permalink raw reply
* [PATCH 1/8] 44x/pci: Use PCI_BASE_ADDRESS_MEM_PREFETCH rather than magic value.
From: Tony Breeds @ 2011-12-01 7:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Josh Boyer; +Cc: LinuxPPC-dev
In-Reply-To: <1322725164-4391-1-git-send-email-tony@bakeyournoodle.com>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This patch was somehow missed from the original series.
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 862f11b..16f5eba 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1739,7 +1739,7 @@ static void __init ppc4xx_configure_pciex_PIMs(struct ppc4xx_pciex_port *port,
/* Calculate window size */
sa = (0xffffffffffffffffull << ilog2(size));
if (res->flags & IORESOURCE_PREFETCH)
- sa |= 0x8;
+ sa |= PCI_BASE_ADDRESS_MEM_PREFETCH;
if (of_device_is_compatible(port->node, "ibm,plb-pciex-460sx"))
sa |= PCI_BASE_ADDRESS_MEM_TYPE_64;
--
1.7.6.4
^ permalink raw reply related
* [PATCH 2/8] 44x/pci: Add a want_sdr flag into ppc4xx_pciex_hwops
From: Tony Breeds @ 2011-12-01 7:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Josh Boyer; +Cc: LinuxPPC-dev
In-Reply-To: <1322725164-4391-1-git-send-email-tony@bakeyournoodle.com>
Currituck doesn't need nor use SDR so aborting the pci setup if there is
no sdr-base would be bad.
Add a flag to ppc4xx_pciex_hwops for the backends to state if they need
SDR and then only complain and abort if they do and it's not found in
the device tree.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 16f5eba..ab3293a 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -647,6 +647,7 @@ static unsigned int ppc4xx_pciex_port_count;
struct ppc4xx_pciex_hwops
{
+ bool want_sdr;
int (*core_init)(struct device_node *np);
int (*port_init_hw)(struct ppc4xx_pciex_port *port);
int (*setup_utl)(struct ppc4xx_pciex_port *port);
@@ -916,6 +917,7 @@ static int ppc440speB_pciex_init_utl(struct ppc4xx_pciex_port *port)
static struct ppc4xx_pciex_hwops ppc440speA_pcie_hwops __initdata =
{
+ .want_sdr = true,
.core_init = ppc440spe_pciex_core_init,
.port_init_hw = ppc440speA_pciex_init_port_hw,
.setup_utl = ppc440speA_pciex_init_utl,
@@ -924,6 +926,7 @@ static struct ppc4xx_pciex_hwops ppc440speA_pcie_hwops __initdata =
static struct ppc4xx_pciex_hwops ppc440speB_pcie_hwops __initdata =
{
+ .want_sdr = true,
.core_init = ppc440spe_pciex_core_init,
.port_init_hw = ppc440speB_pciex_init_port_hw,
.setup_utl = ppc440speB_pciex_init_utl,
@@ -1034,6 +1037,7 @@ static int ppc460ex_pciex_init_utl(struct ppc4xx_pciex_port *port)
static struct ppc4xx_pciex_hwops ppc460ex_pcie_hwops __initdata =
{
+ .want_sdr = true,
.core_init = ppc460ex_pciex_core_init,
.port_init_hw = ppc460ex_pciex_init_port_hw,
.setup_utl = ppc460ex_pciex_init_utl,
@@ -1181,6 +1185,7 @@ done:
}
static struct ppc4xx_pciex_hwops ppc460sx_pcie_hwops __initdata = {
+ .want_sdr = true,
.core_init = ppc460sx_pciex_core_init,
.port_init_hw = ppc460sx_pciex_init_port_hw,
.setup_utl = ppc460sx_pciex_init_utl,
@@ -1276,6 +1281,7 @@ static int ppc405ex_pciex_init_utl(struct ppc4xx_pciex_port *port)
static struct ppc4xx_pciex_hwops ppc405ex_pcie_hwops __initdata =
{
+ .want_sdr = true,
.core_init = ppc405ex_pciex_core_init,
.port_init_hw = ppc405ex_pciex_init_port_hw,
.setup_utl = ppc405ex_pciex_init_utl,
@@ -1972,13 +1978,15 @@ static void __init ppc4xx_probe_pciex_bridge(struct device_node *np)
}
port->node = of_node_get(np);
- pval = of_get_property(np, "sdr-base", NULL);
- if (pval == NULL) {
- printk(KERN_ERR "PCIE: missing sdr-base for %s\n",
- np->full_name);
- return;
+ if (ppc4xx_pciex_hwops->want_sdr == true) {
+ pval = of_get_property(np, "sdr-base", NULL);
+ if (pval == NULL) {
+ printk(KERN_ERR "PCIE: missing sdr-base for %s\n",
+ np->full_name);
+ return;
+ }
+ port->sdr_base = *pval;
}
- port->sdr_base = *pval;
/* Check if device_type property is set to "pci" or "pci-endpoint".
* Resulting from this setup this PCIe port will be configured
--
1.7.6.4
^ permalink raw reply related
* [PATCH 3/8] 44x/pci: Setup the dma_window properties for each pci_controller
From: Tony Breeds @ 2011-12-01 7:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Josh Boyer; +Cc: LinuxPPC-dev
In-Reply-To: <1322725164-4391-1-git-send-email-tony@bakeyournoodle.com>
Needed if you want to use swiotlb, harmless otherwise.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index ab3293a..45148ef 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -185,9 +185,15 @@ static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
out:
dma_offset_set = 1;
pci_dram_offset = res->start;
+ hose->dma_window_base_cur = res->start;
+ hose->dma_window_size = resource_size(res);
printk(KERN_INFO "4xx PCI DMA offset set to 0x%08lx\n",
pci_dram_offset);
+ printk(KERN_INFO "4xx PCI DMA window base to 0x%016llx\n",
+ (unsigned long long)hose->dma_window_base_cur);
+ printk(KERN_INFO "DMA window size 0x%016llx\n",
+ (unsigned long long)hose->dma_window_size);
return 0;
}
--
1.7.6.4
^ permalink raw reply related
* [PATCH 4/8] 44x: Removing dead CONFIG_PPC47x
From: Tony Breeds @ 2011-12-01 7:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Josh Boyer; +Cc: LinuxPPC-dev
In-Reply-To: <1322725164-4391-1-git-send-email-tony@bakeyournoodle.com>
From: Christoph Egger <siccegge@cs.fau.de>
CONFIG_PPC47x doesn't exist in Kconfig and no 476 processor calls this
function ppc44x_pin_tlb() as it has it's own ppc47x_pin_tlb().
This code is probably an artifact of the original 476 code that
shouldn't have made it upstream.
Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/mm/44x_mmu.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index f60e006..5d4e3ff 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -78,11 +78,7 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys)
"tlbwe %1,%3,%5\n"
"tlbwe %0,%3,%6\n"
:
-#ifdef CONFIG_PPC47x
- : "r" (PPC47x_TLB2_S_RWX),
-#else
: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
-#endif
"r" (phys),
"r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
"r" (entry),
--
1.7.6.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox