Re: [PATCH v2] deb-pkg: Add support for powerpc little endian
On Fri, Sep 5, 2014 at 3:55 AM, Michael Neuling wrote: > On Fri, 2014-09-05 at 09:13 +0200, Gabriel Paubert wrote: >> On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote: >> > The Debian powerpc little endian architecture is called ppc64le. This >> >> Huh? ppc64le or ppc64el? > > ppc64el. Commit message is wrong. Fixed below. Yay! Just like every other architecture, we continue to have the deb based distros call it one thing, and the RPM based distros call it another. At least we're consistent in our inconsistency. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: flush_icache_range on AMCC 44x targets
On Tue, Apr 30, 2013 at 02:17:59PM +0200, Mike wrote: >Hi, > >i was reading trough arch/powerpc/kernel/misc32.S looking at the icbi and >iccci instructions, from whats on print in >http://s.eeweb.com/members/kvks_kumar/answers/1356585717-PPC440_UM2013.pdf(page >272) iccci should be used once in the power-on / reset routine, and >as far as flush_icache_range goes presumably before icbi is called? I'm not understanding your question. >So should not flush_icache_range go >#ifdef CONFIG_44x >iccci0, r0 >#endif >icbi0,r6 The icbi isn't ever executed on 44x at all. >arch/powerpc/kernel/misc32.S: >/* > * Write any modified data cache blocks out to memory > * and invalidate the corresponding instruction cache blocks. > * This is a no-op on the 601. > * > * flush_icache_range(unsigned long start, unsigned long stop) > */ >_KPROBE(__flush_icache_range) >BEGIN_FTR_SECTION >blr/* for 601, do nothing */ >END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) >lir5,L1_CACHE_BYTES-1 >andcr3,r3,r5 >subfr4,r3,r4 >addr4,r4,r5 >srwi.r4,r4,L1_CACHE_SHIFT >beqlr >mtctrr4 >mrr6,r3 >1:dcbst0,r3 >addir3,r3,L1_CACHE_BYTES >bdnz1b >sync/* wait for dcbst's to get to ram */ >#ifndef CONFIG_44x This part above is "if not defined CONFIG_44X", which means execute everything below here until you hit #else if you are running on a processor that isn't 4xx. >mtctrr4 >2:icbi0,r6 >addir6,r6,L1_CACHE_BYTES >bdnz2b >#else Otherwise, use iccci. Which is what you're sort of suggesting be done. >/* Flash invalidate on 44x because we are passed kmapped addresses and > this doesn't work for userspace pages due to the virtually tagged > icache. Sigh. */ >iccci0, r0 >#endif So. I think the code is already doing what you think it should? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/4xx: Fix warning in kilauea.dtb
On Mon, Jun 03, 2013 at 12:00:24PM +0100, Ian Campbell wrote:
>Currently I see:
> DTC arch/powerpc/boot/kilauea.dtb
>Warning (reg_format): "reg" property in /plb/ppc4xx-msi@C1000 has invalid
>length (12 bytes) (#address-cells == 1, #size-cells == 1)
>
>It appears that unlike the other plarforms handled by 3fb7933850fa
>"powerpc/4xx: Adding PCIe MSI support" this platform does not use
>address-cells=2.
Right, it's a 405, not a 440. I should have caught that in the initial
review.
>Signed-off-by: Ian Campbell
>Cc: Rupjyoti Sarmah
>Cc: Tirumala R Marri
>Cc: Josh Boyer
That address should bounce. It hasn't been active in almost 2 years.
>Cc: Benjamin Herrenschmidt
>Cc: Paul Mackerras
>Cc: linuxppc-dev@lists.ozlabs.org
>Cc: linux-ker...@vger.kernel.org
Acked-by: Josh Boyer
>---
> arch/powerpc/boot/dts/kilauea.dts |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/powerpc/boot/dts/kilauea.dts
>b/arch/powerpc/boot/dts/kilauea.dts
>index 1613d6e..5ba7f01 100644
>--- a/arch/powerpc/boot/dts/kilauea.dts
>+++ b/arch/powerpc/boot/dts/kilauea.dts
>@@ -406,7 +406,7 @@
>
> MSI: ppc4xx-msi@C1000 {
> compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
>- reg = < 0x0 0xEF62 0x100>;
>+ reg = <0xEF62 0x100>;
> sdr-base = <0x4B0>;
> msi-data = <0x>;
> msi-mask = <0x>;
>--
>1.7.10.4
>
>___
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pull request: scottwood/linux.git next
On Mon, Aug 19, 2013 at 7:47 PM, Benjamin Herrenschmidt wrote: > On Mon, 2013-08-19 at 17:56 -0500, Scott Wood wrote: >> If we use the generic CPU target then mftb won't get turned into mfspr >> (I assume this is what you meant by "tricky asm"). Does mfspr work >> everywhere, including from userspace? Or do we need to patch? What >> about 403GCX which seems to need some special SPR (I could leave the >> existing ifdef alone, but what about vdso)? > > I think mfspr works everywhere we care about but I might be mistaken :-) > I don't think anybody have tried booting a 403 in a long time. I > would be surprised if it still worked. I think I have one buried somewhere in my garage. I'm not digging it out. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/40x: remove unused "config 405GPR"
On Thu, Mar 14, 2013 at 9:47 AM, Paul Bolle wrote: > The last user of Kconfig symbol 405GPR got removed in release v3.2. > Remove this symbol too. > > Signed-off-by: Paul Bolle Acked-by: Josh Boyer > --- > arch/powerpc/platforms/40x/Kconfig | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/powerpc/platforms/40x/Kconfig > b/arch/powerpc/platforms/40x/Kconfig > index a392d12..7b7a77c 100644 > --- a/arch/powerpc/platforms/40x/Kconfig > +++ b/arch/powerpc/platforms/40x/Kconfig > @@ -119,9 +119,6 @@ config 405EZ > select IBM_EMAC_MAL_CLR_ICINTSTAT > select IBM_EMAC_MAL_COMMON_ERR > > -config 405GPR > - bool > - > config XILINX_VIRTEX > bool > select DEFAULT_UIMAGE > -- > 1.7.11.7 > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove unused "config 405EP"
On Mon, Apr 8, 2013 at 7:27 AM, Paul Bolle wrote: > All users of Kconfig symbol 405EP were removed in release v2.6.27. > Remove this symbol (and a useless select of it) too. > > Signed-off-by: Paul Bolle Acked-by: Josh Boyer > --- > 0) Tested by grepping the tree only. > > 1) There's also a Kconfig symbol EP405. Let's hope no one ever made a > typo with either of these two symbols! > > arch/powerpc/platforms/40x/Kconfig | 4 > 1 file changed, 4 deletions(-) > > diff --git a/arch/powerpc/platforms/40x/Kconfig > b/arch/powerpc/platforms/40x/Kconfig > index 7b7a77c..bd40bbb 100644 > --- a/arch/powerpc/platforms/40x/Kconfig > +++ b/arch/powerpc/platforms/40x/Kconfig > @@ -20,7 +20,6 @@ config HOTFOOT > bool "Hotfoot" > depends on 40x > default n > - select 405EP > select PPC40x_SIMPLE > select PCI > help > @@ -105,9 +104,6 @@ config 405GP > select IBM405_ERR51 > select IBM_EMAC_ZMII > > -config 405EP > - bool > - > config 405EX > bool > select IBM_EMAC_EMAC4 > -- > 1.7.11.7 > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fixes return issues in uic_init_one
On Mon, Jun 30, 2014 at 12:02 AM, Nicholas Krause wrote: > This patch fixes the FIXME messages for returning a ENOMEM error > if uic is not allocated and if uic->irqhost is not allocated a > IRQ domain that is linear returns EIO. > > Signed-off-by: Nicholas Krause NAK. You didn't actually fix anything here. In fact, you changed the semantics of what uic_init_one returns and the function that calls doesn't change for negative return codes. You also didn't do similar changes for the rest of the error conditions in within the same function, making it inconsistent with itself. NULL is the appropriate return for errors in this function. The FIXME about panicing is because without a UIC, the boards can't service interrupts at all. A board that doesn't work might as well panic, but that panic is actually done in uic_init_tree appropriately. If you're going to change anything, just remove the comment. josh > --- > arch/powerpc/sysdev/uic.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c > index 9203393..f95010a 100644 > --- a/arch/powerpc/sysdev/uic.c > +++ b/arch/powerpc/sysdev/uic.c > @@ -239,7 +239,7 @@ static struct uic * __init uic_init_one(struct > device_node *node) > > uic = kzalloc(sizeof(*uic), GFP_KERNEL); > if (! uic) > - return NULL; /* FIXME: panic? */ > + return -ENOMEM; > > raw_spin_lock_init(&uic->lock); > indexp = of_get_property(node, "cell-index", &len); > @@ -261,7 +261,7 @@ static struct uic * __init uic_init_one(struct > device_node *node) > uic->irqhost = irq_domain_add_linear(node, NR_UIC_INTS, &uic_host_ops, > uic); > if (! uic->irqhost) > - return NULL; /* FIXME: panic? */ > + return -EIO; > > /* Start with all interrupts disabled, level and non-critical */ > mtdcr(uic->dcrbase + UIC_ER, 0); > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/4xx: Fix warning in kilauea.dtb
On Mon, Nov 25, 2013 at 4:40 AM, Ian Campbell wrote:
> Currently I see:
> DTC arch/powerpc/boot/kilauea.dtb
> Warning (reg_format): "reg" property in /plb/ppc4xx-msi@C1000 has invalid
> length (12 bytes) (#address-cells == 1, #size-cells == 1)
>
> It appears that unlike the other platforms handled by 3fb7933850fa
> "powerpc/4xx: Adding PCIe MSI support" this platform does not use
> address-cells=2.
>
> Signed-off-by: Ian Campbell
> Acked-by: Josh Boyer
> Cc: Rupjyoti Sarmah
> Cc: Tirumala R Marri
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND...)
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org
> ---
> Resending, this hasn't been picked up since June
> http://patchwork.ozlabs.org/patch/248234/
Ben, please pick this up.
josh
> ---
> arch/powerpc/boot/dts/kilauea.dts |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/kilauea.dts
> b/arch/powerpc/boot/dts/kilauea.dts
> index 1613d6e..5ba7f01 100644
> --- a/arch/powerpc/boot/dts/kilauea.dts
> +++ b/arch/powerpc/boot/dts/kilauea.dts
> @@ -406,7 +406,7 @@
>
> MSI: ppc4xx-msi@C1000 {
> compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
> - reg = < 0x0 0xEF62 0x100>;
> + reg = <0xEF62 0x100>;
> sdr-base = <0x4B0>;
> msi-data = <0x>;
> msi-mask = <0x>;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc476: Enable a linker work around for IBM errata #46
On Mon, Feb 24, 2014 at 2:00 AM, Alistair Popple wrote: > This patch adds an option to enable a work around for an icache bug on > 476 that can cause execution of stale instructions when falling > through pages (IBM errata #46). It requires a recent version of > binutils which supports the --ppc476-workaround option. > > The work around enables the appropriate linker options and ensures > that all module output sections are aligned to 4K page boundaries. The > work around is only required when building modules. What happens if you're using 64K pages? Is the alignment 4K always, or does it need to be aligned to PAGE_SIZE? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Update ppc4xx maintainer
Alistair Popple has volunteered to take over maintainership of the ppc4xx stuff upstream. Switch the MAINTAINERS entry over to him. Signed-off-by: Josh Boyer --- MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1ecfde1..6d220c8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5245,11 +5245,10 @@ F: arch/powerpc/platforms/512x/ F: arch/powerpc/platforms/52xx/ LINUX FOR POWERPC EMBEDDED PPC4XX -M: Josh Boyer +M: Alistair Popple M: Matt Porter W: http://www.penguinppc.org/ L: linuxppc-dev@lists.ozlabs.org -T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git S: Maintained F: arch/powerpc/platforms/40x/ F: arch/powerpc/platforms/44x/ -- 1.8.5.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing operand for tlbie instruction on Power7
On Wed, Oct 7, 2015 at 5:13 AM, Michael Ellerman wrote: > On Wed, 2015-10-07 at 02:19 -0500, Segher Boessenkool wrote: >> On Wed, Oct 07, 2015 at 05:00:49PM +1100, Michael Ellerman wrote: >> > > It's also worth noting that the __flush_power7 uses tlbiel instead of >> > > tlbie. >> > >> > Yeah that's a good point. It's not clear if the swsusp code wants to a >> > local or >> > a global invalidate. >> >> If I read the code right, this is called on the boot CPU when all the >> non-boot CPUs are still (potentially) down, so if you would do a global >> invalidate the non-boot CPUs might not even notice, so those need to do >> a (local) invalidate after being brought up anyway? Or they probably >> need it before being brought down at all? You figure it out, it makes >> my brain hurt :-) > > A good rule would be that every cpu does a local invalidate before turning on > the MMU. That would work for this case and also for kexec, kdump, junk left by > firmare etc. But I don't think we do that consistently in a way that works for > this code at the moment. > >> > As an alternative, can you try adding a .machine push / .machine "power4" / >> > .machine pop, around the tlbie. That should tell the assembler to drop >> > back to >> > power4 mode for that instruction, which should then do the right thing. >> > There >> > are some examples in that file. >> >> That will get the assembler to not complain, but it will assemble the wrong >> instruction: the power7 instruction has the same opcode (but different >> semantics). So if you assemble a "tlbie r4" in power4 mode, a newer CPU >> will see it as a "tlbie r4,r0" and do the wrong thing. > > Yeah, it would basically maintain the existing behaviour which is wrong but a > known quantity. I suspect no one has ever run this on Power7 or in fact > anything other than G5 or Book3E. Likely not, but leaving it broken just because it is known behavior seems pretty weird to me. I think Fedora will look at simply disabling hibernation on ppc64 so the file isn't built at all. Seems to be a safer option. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing operand for tlbie instruction on Power7
On Wed, Oct 7, 2015 at 8:10 PM, Michael Ellerman wrote: > On Wed, 2015-10-07 at 10:31 -0400, Josh Boyer wrote: >> On Wed, Oct 7, 2015 at 5:13 AM, Michael Ellerman wrote: >> > On Wed, 2015-10-07 at 02:19 -0500, Segher Boessenkool wrote: >> >> On Wed, Oct 07, 2015 at 05:00:49PM +1100, Michael Ellerman wrote: >> >> > > It's also worth noting that the __flush_power7 uses tlbiel instead of >> >> > > tlbie. >> >> > >> >> > Yeah that's a good point. It's not clear if the swsusp code wants to a >> >> > local or >> >> > a global invalidate. >> >> >> >> If I read the code right, this is called on the boot CPU when all the >> >> non-boot CPUs are still (potentially) down, so if you would do a global >> >> invalidate the non-boot CPUs might not even notice, so those need to do >> >> a (local) invalidate after being brought up anyway? Or they probably >> >> need it before being brought down at all? You figure it out, it makes >> >> my brain hurt :-) >> > >> > A good rule would be that every cpu does a local invalidate before turning >> > on >> > the MMU. That would work for this case and also for kexec, kdump, junk >> > left by >> > firmare etc. But I don't think we do that consistently in a way that works >> > for >> > this code at the moment. >> > >> >> > As an alternative, can you try adding a .machine push / .machine >> >> > "power4" / >> >> > .machine pop, around the tlbie. That should tell the assembler to drop >> >> > back to >> >> > power4 mode for that instruction, which should then do the right thing. >> >> > There >> >> > are some examples in that file. >> >> >> >> That will get the assembler to not complain, but it will assemble the >> >> wrong >> >> instruction: the power7 instruction has the same opcode (but different >> >> semantics). So if you assemble a "tlbie r4" in power4 mode, a newer CPU >> >> will see it as a "tlbie r4,r0" and do the wrong thing. >> > >> > Yeah, it would basically maintain the existing behaviour which is wrong >> > but a >> > known quantity. I suspect no one has ever run this on Power7 or in fact >> > anything other than G5 or Book3E. >> >> Likely not, but leaving it broken just because it is known behavior >> seems pretty weird to me. > > In a universe where I have infinite time to fix random things we would > obviously do a proper fix :) > >> I think Fedora will look at simply disabling hibernation on ppc64 so the file >> isn't built at all. Seems to be a safer option. > > It's safer for sure. Though you might have some G5 users who are using it and > notice it being disabled. The 5 of them will notice it being disabled and then they'll realize they either get a working kernel minus hibernation, or they get no kernel at all because it doesn't compile. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Wed, Aug 10, 2011 at 2:26 PM, Josh Boyer wrote: > Hi Ben, > > Finally somewhat caught up. Now that -rc1 is out, here are some > patches for the next merge window. > > josh > > The following changes since commit 53d1e658df6e26d62500410719aaee2b82067c03: > > Merge branch 'devicetree/merge' of > git://git.secretlab.ca/git/linux-2.6 (2011-08-04 06:37:07 -1000) > > are available in the git repository at: > > ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Ben, ping? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data
On Wed, Aug 31, 2011 at 6:36 PM, Greg KH wrote: > On Tue, Aug 30, 2011 at 08:29:21AM -0700, Tirumala Marri wrote: >> <-Original Message- >> mailto:pratyush.an...@st.com] >> > > > > > > > > < >> > > > < >> >> <--- >> < include/linux/usb/dwc_otg.h | 274 >> >> [Tirumala Marri] I am not sure how to separate your changes. But we need >> More time as our initial patches are still pending. > > pending where? Have you submitted them for inclusion? > 13 times in fact. Each time, more comments and fixes need. Par for the course with a vendor driver, but in this case Pratyush thought the APM guys had let it die and tried to carry it forward. I guess APM has been sitting on it for more than 4 months now. Anyway, hope that clears up some of the confusion. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 15/21] powerpc: drop unused Kconfig symbols
On Fri, Oct 14, 2011 at 8:30 AM, Paul Bolle wrote: > Signed-off-by: Paul Bolle > --- > arch/powerpc/Kconfig | 22 -- > arch/powerpc/platforms/40x/Kconfig | 5 - > arch/powerpc/platforms/Kconfig.cputype | 8 > arch/powerpc/platforms/embedded6xx/Kconfig | 4 > arch/powerpc/platforms/prep/Kconfig | 9 - > arch/powerpc/platforms/wsp/Kconfig | 5 - > 6 files changed, 0 insertions(+), 53 deletions(-) For the 40x change: Acked-by: Josh Boyer josh > diff --git a/arch/powerpc/platforms/40x/Kconfig > b/arch/powerpc/platforms/40x/Kconfig > index d733d7c..4bd3a27 100644 > --- a/arch/powerpc/platforms/40x/Kconfig > +++ b/arch/powerpc/platforms/40x/Kconfig > @@ -115,11 +115,6 @@ config PPC40x_SIMPLE > help > This option enables the simple PowerPC 40x platform support. > > -# 40x specific CPU modules, selected based on the board above. > -config NP405H > - bool > - #depends on ASH > - > # OAK doesn't exist but wanted to keep this around for any future 403GCX > boards > config 403GCX > bool > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd/nand: Add NAND chip ID to support Micron 4k pagesize NAND chip
On Tue, Nov 22, 2011 at 4:23 AM, Shengzhou Liu wrote: > Add NAND chip ID 0x38 in ids table to support Micron 4k large-page NAND chip. > > Signed-off-by: Shengzhou Liu > --- > drivers/mtd/nand/nand_ids.c | 1 + You really need to send this to the MTD list and have it go through that tree. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: dts: Fix canyonlands EMAC interrupt map
On Tue, Nov 22, 2011 at 2:11 AM, Tanmay Inamdar wrote:
> Fixing interrupt mapping of EMAC for canyonlands
>
> Signed-off-by: Tanmay Inamdar
As far as I can tell, your changes aren't really changing anything
just making it a bit clearer, correct? If so, do you mind if I change
the commit log to "clear up" instead of fix?
josh
> ---
> arch/powerpc/boot/dts/canyonlands.dts | 16 ++--
> 1 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> b/arch/powerpc/boot/dts/canyonlands.dts
> index 3dc75de..c76bbcd 100644
> --- a/arch/powerpc/boot/dts/canyonlands.dts
> +++ b/arch/powerpc/boot/dts/canyonlands.dts
> @@ -360,13 +360,11 @@
> EMAC0: ethernet@ef600e00 {
> device_type = "network";
> compatible = "ibm,emac-460ex", "ibm,emac4sync";
> - interrupt-parent = <&EMAC0>;
> - interrupts = <0x0 0x1>;
> - #interrupt-cells = <1>;
> + interrupt-parent = <&UIC2>;
> #address-cells = <0>;
> #size-cells = <0>;
> - interrupt-map = - /*Wake*/ 0x1 &UIC2 0x14
> 0x4>;
> + interrupts = + /*Wake*/0x14 0x4>;
> reg = <0xef600e00 0x00c4>;
> local-mac-address = []; /* Filled
> in by U-Boot */
> mal-device = <&MAL0>;
> @@ -390,13 +388,11 @@
> EMAC1: ethernet@ef600f00 {
> device_type = "network";
> compatible = "ibm,emac-460ex", "ibm,emac4sync";
> - interrupt-parent = <&EMAC1>;
> - interrupts = <0x0 0x1>;
> - #interrupt-cells = <1>;
> + interrupt-parent = <&UIC2>;
> #address-cells = <0>;
> #size-cells = <0>;
> - interrupt-map = - /*Wake*/ 0x1 &UIC2 0x15
> 0x4>;
> + interrupts = + /*Wake*/0x15 0x4>;
> reg = <0xef600f00 0x00c4>;
> local-mac-address = []; /* Filled
> in by U-Boot */
> mal-device = <&MAL0>;
> --
> 1.6.1.rc3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: dts: Fix canyonlands EMAC interrupt map
On Tue, Nov 22, 2011 at 9:15 AM, Tanmay Inamdar wrote: > > On Tue, Nov 22, 2011 at 5:00 PM, Josh Boyer wrote: >> >> On Tue, Nov 22, 2011 at 2:11 AM, Tanmay Inamdar wrote: >> > Fixing interrupt mapping of EMAC for canyonlands >> > >> > Signed-off-by: Tanmay Inamdar >> >> As far as I can tell, your changes aren't really changing anything >> just making it a bit clearer, correct? If so, do you mind if I change >> the commit log to "clear up" instead of fix? > > Actually Rob Herring's commit > (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=dc9372808412edbc653a675a526c2ee6c0c14a91) > breaks the interrupt mapping in EMAC driver. > I am trying to fix this issue by mapping interrupts in different way. I see. That should have been in the commit log then. I'll add something like that to it. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: 44x: Add mtd ndfc to the ppx44x defconfig
On Tue, Nov 22, 2011 at 6:50 PM, Tony Breeds wrote: > Signed-off-by: Tony Breeds Acked-by: Josh Boyer Ben, I don't have anything particularly urgent for 3.2 and this seems like it is well within the 3.2 window (defconfig updates usually come later). Want to pick this up yourself, or do you want me to prep a tree somewhere? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: 44x: Add mtd ndfc to the ppx44x defconfig
On Tue, Nov 22, 2011 at 8:34 PM, Benjamin Herrenschmidt wrote: > On Tue, 2011-11-22 at 20:04 -0500, Josh Boyer wrote: >> On Tue, Nov 22, 2011 at 6:50 PM, Tony Breeds wrote: >> > Signed-off-by: Tony Breeds >> >> Acked-by: Josh Boyer >> >> Ben, I don't have anything particularly urgent for 3.2 and this seems >> like it is well within the 3.2 window (defconfig updates usually come >> later). Want to pick this up yourself, or do you want me to prep a >> tree somewhere? > > I'm working on 3.3 right now, so I'd rather you throw this in there, I > doesn't seem to be particularily urgent for 3.2 is it? (who actually Urgent, no. I'll get a tree going after the holidays. > uses 4xx_defconfig ?) The linux-next tree builds it. It would have caught a compile error in the NDFC driver much earlier if we had it enabled in the defconfig. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/40x: Add APM8018X SOC support
On Wed, Nov 23, 2011 at 4:44 AM, Tanmay Inamdar wrote:
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index b177caa..3f2cc36 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -978,3 +978,9 @@ config PPC_LIB_RHEAP
> bool
>
> source "arch/powerpc/kvm/Kconfig"
> +
> +config UART_16550_WORD_ADDRESSABLE
> + bool
> + default n
> + help
> + Enable this if your UART 16550 is word addressable.
Ugh. What is this for? More specifically, if the UART requires word
reads and writes, shouldn't it be using reg-shift/reg-offset in the
device tree? I'm confused why UDBG would need this sort of code, but
the runtime serial driver doesn't?
> diff --git a/arch/powerpc/boot/dts/klondike.dts
> b/arch/powerpc/boot/dts/klondike.dts
> + OCM: ocm@2000 {
> + compatible = "ibm,ocm";
> + status = "enabled";
> + cell-index = <1>;
> + reg = < 0x2000 0x1f000 /* 128K - 4K NAND */
> + 0xfffe 0x1f000>; /* 128K - 4K I2C */
> + bootmode = "nand";
> + };
What is this? There's nothing in the kernel or in this patch that
binds with "ibm,ocm". Also, that 'bootmode' property doesn't seem
like a hardware value, but a human descriptor of something that
switches it to boot from NAND.
> + crypto: crypto@4000 {
> + device_type = "crypto";
> + compatible = "405ex-crypto", "amcc,ppc405ex-crypto",
> "amcc,ppc4xx-crypto";
Why is the "405ex-crypto" string there?
> + EDMA: edma@4008 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "amcc,edma";
> + device_type = "dma";
> + /*complQ-fifo-memory = "ocm";*/
> + cell-index = <0>;
> + reg = <0x4008 0x0001>;
> + dcr-reg = <0x060 0x09f>;
> +
> + interrupt-parent = <&UIC0>;
> + interrupts = + /*EDMA Err */ 0x6 4 >;
> +
> + dma-channel@0 {
> + compatible = "amcc,edma-channel";
> + /*descriptor-memory = "ocm";*/
> + cell-index = <0>;
> + dcr-reg = <0x006a 0x006b>;
> + };
> + };
What's this? Again, nothing binds to "amcc,edma" in the kernel or
patch. At the very least this (and OCM above) need some binding
descriptions added to Documentation/devicetree/bindings/powerpc/4xx/
> +
> + MSI: dwc_pcie-msi@4009 {
> + compatible = "amcc,dwc_pcie-msi", "dwc_pcie-msi";
> + status = "ok";
Is the status property something that is set by U-Boot, or will it
always be "ok"? If the latter, I don't think you need to specify it
at all.
> + reg = <0x4009 0x100>;
> + interrupts =<0x0 0x1 0x2 0x3>;
> + interrupt-parent = <&MSI>;
> + #interrupt-cells = <1>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + interrupt-map = <0x0 &UIC0 0x0C 0x1
> + 0x1 &UIC0 0x0D 0x1
> + 0x2 &UIC0 0x0E 0x1
> + 0x3 &UIC0 0x0F 0x1>;
> + };
Same binding comment here.
> +
> + AHB: ahb {
> + device_type = "ahb";
I doubt the device_type is needed.
> + compatible = "amcc,405ex-ahb", "ibm,ahb";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + clock-frequency = <0>; /* Filled in by U-Boot */
Same binding comment for ahb.
> +
> + lcd: lcd@5806 {
> + device_type = "lcd";
Drop device_type.
> + compatible = "apm,apm-lcd","apm,db9000";
> + version = "apm-1.1";
Why is 'version' there? Version of what? The hardware itself, the
driver? I doubt this is needed.
> + reg = <0x5806 0x1000>;
> + interrupt-parent = <&UIC0>;
> + /*
> + * interrupt index 0 for chip 1.0
> + * interrupt index 1 for chip 1.1
> + */
> + interrupts = <0x1c 2 0x1c 4>;
> + };
Same binding comment for apm,apm-lcd. I'm just going to assert again
that anything that doesn't have a defined b
Re: [PATCH v3 1/8] [44x] Fix typo in KEXEC Kconfig dependency
On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose wrote: > Kexec is not supported on 47x. 47x is a variant of 44x with slightly > different MMU and SMP support. There was a typo in the Kconfig > dependency for KEXEC. This patch fixes the same. > > Signed-off-by: Suzuki K. Poulose > Cc: Kumar Gala > Cc: Josh Boyer > Cc: linux ppc dev Ben already took this one for 3.2. I should have added my Acked-by a while ago. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose wrote: > The current implementation of CONFIG_RELOCATABLE in BookE is based > on mapping the page aligned kernel load address to KERNELBASE. This > approach however is not enough for platforms, where the TLB page size > is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used > currently in BookE to DYNAMIC_MEMSTART to reflect the actual method. > > The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the > dynamic relocations will be introduced in the later in the patch series. > > This change would allow the use of the old method of RELOCATABLE for > platforms which can afford to enforce the page alignment (platforms with > smaller TLB size). I'm OK with the general direction, but this touches a lot of non-4xx code. I'd prefer it if Ben took this directly on whatever final solution is done. > I haven tested this change only on 440x. I don't have an FSL BookE to verify > the changes there. > > Scott, > Could you please test this patch on FSL and let me know the results ? Scott, did you ever get around to testing this? In my opinion, this shouldn't go in without a Tested-by: from someone that tried it on an FSL platform. > Suggested-by: Scott Wood > > Signed-off-by: Suzuki K. Poulose > Cc: Scott Wood > Cc: Kumar Gala > Cc: Benjamin Herrenschmidt > Cc: linux ppc dev > --- > > arch/powerpc/Kconfig | 50 > - > arch/powerpc/configs/44x/iss476-smp_defconfig | 2 + > arch/powerpc/include/asm/kdump.h | 5 ++- > arch/powerpc/include/asm/page.h | 4 +- > arch/powerpc/kernel/crash_dump.c | 4 +- > arch/powerpc/kernel/head_44x.S | 4 ++ > arch/powerpc/kernel/head_fsl_booke.S | 2 + > arch/powerpc/kernel/machine_kexec.c | 2 + > arch/powerpc/kernel/prom_init.c | 2 + > arch/powerpc/mm/44x_mmu.c | 2 + > 10 files changed, 47 insertions(+), 30 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index d7c2d1a..8d4f789 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -363,7 +363,8 @@ config KEXEC > config CRASH_DUMP > bool "Build a kdump crash kernel" > depends on PPC64 || 6xx || FSL_BOOKE > - select RELOCATABLE if PPC64 || FSL_BOOKE > + select RELOCATABLE if PPC64 > + select DYNAMIC_MEMSTART if FSL_BOOKE > help > Build a kernel suitable for use as a kdump capture kernel. > The same kernel binary can be used as production kernel and dump > @@ -841,23 +842,36 @@ config LOWMEM_CAM_NUM > int "Number of CAMs to use to map low memory" if LOWMEM_CAM_NUM_BOOL > default 3 > > -config RELOCATABLE > - bool "Build a relocatable kernel (EXPERIMENTAL)" > +config DYNAMIC_MEMSTART OK, so my one bikeshed comment here. We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for 64-bit. Then throughout almost the rest of the patch, all we're doing is duplicating what RELOCATABLE already did (e.g. if ! either thing). It works, but it is kind of ugly. Instead, could we define a helper config variable that can be used in place of that construct? Something like: config NONSTATIC_KERNEL (or whatever) bool default n ... config DYNAMIC_MEMSTART select NONSTATIC_KERNEL ... config RELOCATABLE select NONSTATIC_KERNEL Then you can do this kind of thing: default "0x0200" if PPC_STD_MMU && CRASH_DUMP && !(NONSTATIC_KERNEL) #if defined(CONFIG_CRASH_DUMP) && !(defined(CONFIG_NONSTATIC_KERNEL)) instead of this: default "0x0200" if PPC_STD_MMU && CRASH_DUMP && !(RELOCATABLE || DYNAMIC_MEMSTART) #if defined(CONFIG_CRASH_DUMP) && !(defined(CONFIG_RELOCATABLE) || \ defined(CONFIG_DYNAMIC_MEMSTART)) while still allowing for differences between RELOCATABLE and DYNAMIC_MEMSTART. Thoughts? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sam460ex, sm501 incorrect device id with kernel >=linux-2.6.39
On Sun, Nov 27, 2011 at 11:37 AM, acrux wrote: > > Acube Sam460ex has SM502 as onboard video. > I got this with any kernel newer than 2.6.38.x thus the framebuffer is lost > too: > > root@sam4x0:~# diff dmesg-2.6.38.8 dmesg-2.6.39.4 > 1,2c1,3 > < Using PowerPC 44x Platform machine description > < Linux version 2.6.38.8-Sam460ex (root@sam4x0) (gcc version 4.5.3 (CRUX PPC) > ) #1 Fri Nov 11 22:07:53 CET 2011 > --- >> Using Canyonlands machine description >> Initializing cgroup subsys cpu You seem to have switched from using the generic PowerPC 44x platform, to using a Canyonlands kernel and/or DTB. Not sure why that is, but it's probably not helping your issues at all. >> Linux version 2.6.39.4-Sam460ex (root@sam4x0) (gcc version 4.5.3 (CRUX PPC) >> ) #1 Fri Nov 11 19:06:02 CET 2011 > 17c18 > [cut] > 161,179c165,167 > < sm501 0001:00:06.0: SM501 At f548: Version 050100c0, 64 Mb, IRQ 19 > --- >> sm501 0001:00:06.0: incorrect device id c105 Something is reading the device ID in the wrong endian (and probably everything else). josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Decode correct MSR bits in oops output
On Mon, Nov 28, 2011 at 11:04 AM, Kumar Gala wrote:
>
> On Nov 24, 2011, at 11:35 PM, Anton Blanchard wrote:
>
>>
>> On a 64bit book3s machine I have an oops from a system reset that
>> claims the book3e CE bit was set:
>>
>> MSR: 80021032 CR: 24004082 XER: 0010
>>
>> On a book3s machine system reset sets IBM bit 46 and 47 depending on
>> the power saving mode. Separate the definitions by type and for
>> completeness add the rest of the bits in.
>>
>> Signed-off-by: Anton Blanchard
>> ---
>>
>> Index: linux-build/arch/powerpc/kernel/process.c
>> ===
>> --- linux-build.orig/arch/powerpc/kernel/process.c 2011-11-25
>> 13:22:24.294919094 +1100
>> +++ linux-build/arch/powerpc/kernel/process.c 2011-11-25 13:36:23.213834524
>> +1100
>> @@ -584,16 +584,32 @@ static struct regbit {
>> unsigned long bit;
>> const char *name;
>> } msr_bits[] = {
>> +#if defined(CONFIG_PPC64) && !defined(CONFIG_BOOKE)
>> + {MSR_SF, "SF"},
>> + {MSR_HV, "HV"},
>> +#endif
>> + {MSR_VEC, "VEC"},
>> + {MSR_VSX, "VSX"},
>> +#ifdef CONFIG_BOOKE
>> + {MSR_CE, "CE"},
>> +#endif
>> {MSR_EE, "EE"},
>> {MSR_PR, "PR"},
>> {MSR_FP, "FP"},
>> - {MSR_VEC, "VEC"},
>> - {MSR_VSX, "VSX"},
>> {MSR_ME, "ME"},
>> - {MSR_CE, "CE"},
>> +#ifdef CONFIG_BOOKE
>> {MSR_DE, "DE"},
>> +#else
>> + {MSR_SE, "SE"},
>> + {MSR_BE, "BE"},
>> +#endif
>> {MSR_IR, "IR"},
>> {MSR_DR, "DR"},
>> + {MSR_PMM, "PMM"},
>> +#ifndef CONFIG_BOOKE
>> + {MSR_RI, "RI"},
>
> We have 'RI' on some BOOKE so lets allow for it to be decoded
>
>> + {MSR_LE, "LE"},
>> +#endif
>> {0, NULL}
>> };
>
> Since you're fixing this can you add the following for CONFIG_BOOKE:
>
> MSR_GS, MSR_UCLE, MSR_PMM, MSR_CM
Those don't exist on 4xx, so CONFIG_BOOKE doesn't seem appropriate.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Decode correct MSR bits in oops output
On Mon, Nov 28, 2011 at 2:30 PM, Scott Wood wrote: > On 11/28/2011 10:23 AM, Josh Boyer wrote: >> On Mon, Nov 28, 2011 at 11:04 AM, Kumar Gala >> wrote: >>> >>> Since you're fixing this can you add the following for CONFIG_BOOKE: >>> >>> MSR_GS, MSR_UCLE, MSR_PMM, MSR_CM >> >> Those don't exist on 4xx, so CONFIG_BOOKE doesn't seem appropriate. > > They're defined by book3e of ISA 2.06. 4xx existed before that, sadly (as did CONFIG_BOOKE). > Not all bits are going to exist on all CPUs -- does 4xx use these bits > to mean something different? No, marked as reserved. However, given the patch shows up in human readable output, I don't think we want reserved bits being decoded and showing up inadvertently. Could introduce BOOK3E_32 to cover cases like this. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Decode correct MSR bits in oops output
On Mon, Nov 28, 2011 at 3:04 PM, Scott Wood wrote: > On 11/28/2011 01:46 PM, Josh Boyer wrote: >> On Mon, Nov 28, 2011 at 2:30 PM, Scott Wood wrote: >>> On 11/28/2011 10:23 AM, Josh Boyer wrote: >>>> On Mon, Nov 28, 2011 at 11:04 AM, Kumar Gala >>>> wrote: >>>>> >>>>> Since you're fixing this can you add the following for CONFIG_BOOKE: >>>>> >>>>> MSR_GS, MSR_UCLE, MSR_PMM, MSR_CM > > PMM is not just BookE, and is already present in the patch. > > RI is present on e500mc (despite being reserved in book3e), so might not > want to stick that inside #ifndef CONFIG_BOOKE. > >>> Not all bits are going to exist on all CPUs -- does 4xx use these bits >>> to mean something different? >> >> No, marked as reserved. However, given the patch shows up in human >> readable output, I don't think we want reserved bits being decoded and >> showing up inadvertently. > > Do the bits ever actually get set on 4xx (documented or otherwise), or > is this a theoretical concern? > > If 4xx must be excluded, use something like: > #if defined(CONFIG_BOOKE) && !defined(CONFIG_4xx) I was going for something a bit simpler. Basically, CONFIG_BOOKE should be treated as a legacy Kconfig variable that has nothing to do with ISA 2.06 because it existed before that and is used by things that aren't compliant with 2.06 (both FSL and 4xx). If we use it for things that show up on these non-compliant CPUs, we'll have to continually add the !defined(WHATEVER) and that just gets ugly over time. > Do we also need to patch out things like MSR_VEC at runtime, in case it > randomly shows up on a pre-Altivec CPU? > >> Could introduce BOOK3E_32 to cover cases like this. > > Why _32? These bits apply to 64-bit as well. MSR_CM is only for 64-bit. Because CONFIG_BOOK3E depeonds on PPC_BOOK3E_64. So either that dependency needs to go so it's selectable elsewhere, or a similarly intended PPC_BOOK3E_32 needs to get created. Or something. > UCLE and PMM are present on pre-2.06 e500 cores as well. Sigh. Maybe there is no way to get un-ugly. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] 44x: Removing dead CONFIG_PPC47x
On Wed, Nov 30, 2011 at 12:23 AM, Tony Breeds wrote: > From: Christoph Egger > > CONFIG_PPC47x doesn't exist in Kconfig, therefore removing all > references for it from the source code. > > Signed-off-by: Christoph Egger > --- > 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 That doesn't look right. The code is there doing something, why is it just being removed? I would think the change would be to use CONFIG_PPC_47x? Or if the code there isn't needed any longer, the changelog should say why. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/6] powerpc/boot: Add extended precision shifts to the boot wrapper.
On Wed, Nov 30, 2011 at 12:48 AM, Benjamin Herrenschmidt wrote: > On Wed, 2011-11-30 at 16:23 +1100, Tony Breeds wrote: >> Code copied from arch/powerpc/kernel/misc_32.S >> >> Signed-off-by: Tony Breeds >> --- >> arch/powerpc/boot/div64.S | 52 >> + >> 1 files changed, 52 insertions(+), 0 deletions(-) > > Should we just link with libgcc ? :-) Please tell me you're joking. However, adding this code and wonderful and all but why do we need to add it? Changelog should say why. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On Mon, Nov 28, 2011 at 5:59 PM, Scott Wood wrote: > On 11/23/2011 10:47 AM, Josh Boyer wrote: >> On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose >> wrote: >>> The current implementation of CONFIG_RELOCATABLE in BookE is based >>> on mapping the page aligned kernel load address to KERNELBASE. This >>> approach however is not enough for platforms, where the TLB page size >>> is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used >>> currently in BookE to DYNAMIC_MEMSTART to reflect the actual method. > > Should reword the config help to make it clear what the alignment > restriction is, or where to find the information for a particular > platform. Someone reading "page aligned" without any context that we're > talking about special large pages is going to think 4K -- and on e500, > many large page sizes are supported, so the required alignment is found > in Linux init code rather than a CPU manual. > >>> >>> The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the >>> dynamic relocations will be introduced in the later in the patch series. >>> >>> This change would allow the use of the old method of RELOCATABLE for >>> platforms which can afford to enforce the page alignment (platforms with >>> smaller TLB size). >> >> I'm OK with the general direction, but this touches a lot of non-4xx >> code. I'd prefer it if Ben took this directly on whatever final >> solution is done. >> >>> I haven tested this change only on 440x. I don't have an FSL BookE to verify >>> the changes there. >>> >>> Scott, >>> Could you please test this patch on FSL and let me know the results ? >> >> Scott, did you ever get around to testing this? In my opinion, this >> shouldn't go in without a Tested-by: from someone that tried it on an >> FSL platform. > > Booted OK for me on e500v2 with RAM starting at 256M. > > Tested-by: Scott Wood > >> We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for >> 64-bit. Then throughout almost the rest of the patch, all we're doing >> is duplicating what RELOCATABLE already did (e.g. if ! either thing). >> It works, but it is kind of ugly. >> >> Instead, could we define a helper config variable that can be used in >> place of that construct? Something like: >> >> config NONSTATIC_KERNEL (or whatever) >> bool >> default n >> >> ... >> >> config DYNAMIC_MEMSTART >> >> select NONSTATIC_KERNEL >> >> ... >> >> config RELOCATABLE >> >> select NONSTATIC_KERNEL > > I agree. Suzie do you think you could respin this patch with the suggested changes and include Scott's Tested-by? The rest of the series looks fine and I'd like to get it included in my next branch. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of new 4xx tree
Hi Ben, I have a new 4xx tree setup now. Two small commits for the next branch are queued up. I'd like to get the patch series from Suzie and Tony included soon as well, but thought I'd start with these to get things rolling. Stephen, can you switch the linux-next tree to use this instead? josh The following changes since commit fa8cbaaf5a68f62db3f9a8444ecbb940b47984cb: powerpc+sparc64/mm: Remove hack in mmap randomize layout (2011-11-28 11:42:09 +1100) are available in the git repository at: git://git.infradead.org/users/jwboyer/powerpc-4xx.git next Josh Boyer (1): MAINTAINERS: Update PowerPC 4xx git tree Tanmay Inamdar (1): powerpc/40x: Add APM8018X SOC support MAINTAINERS |2 +- arch/powerpc/boot/dts/klondike.dts | 227 +++ arch/powerpc/configs/40x/klondike_defconfig | 55 +++ arch/powerpc/kernel/cputable.c | 13 ++ arch/powerpc/platforms/40x/Kconfig | 11 ++ arch/powerpc/platforms/40x/ppc40x_simple.c |1 + 6 files changed, 308 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/boot/dts/klondike.dts create mode 100644 arch/powerpc/configs/40x/klondike_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/40x: Add APM8018X SOC support
On Wed, Nov 30, 2011 at 4:03 PM, Benjamin Herrenschmidt 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc4xx simple vs SoC's
On Thu, Dec 1, 2011 at 12:39 AM, Benjamin Herrenschmidt wrote: > 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. Yep, and they are. > 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 ? CONFIG_PPC44x_SIMPLE is selected by the board Kconfig values, which also select all of the SoC Kconfig options they need as well. ppc44x_simple started as a way to basically avoid duplicating a bunch of board.c files, but it's still "driven" from the board options. So hopefully that explains how things are working today. The question now is whether you would like something different? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add support for OpenBlockS 600
On Fri, Dec 2, 2011 at 1:40 AM, Olof Johansson wrote: > Hi, > > On Thu, Dec 1, 2011 at 9:35 PM, Benjamin Herrenschmidt > wrote: > >> arch/powerpc/boot/dts/obs600.dts | 314 >> > > It'd be nice to have dtsi files for the SoCs, there's a lot of boiler > plate in there. That shouldn't hold up this specific patch though. That sounds like a cleanup project for me. I just need to figure out how they work and find time. >> arch/powerpc/boot/wrapper | 22 ++- >> arch/powerpc/configs/40x/obs600_defconfig | 83 > > A new single-board defconfig? On arm that is a strong NACK, I'd say > it's a bad idea on powerpc as well. I like them. Particularly when they're the output of savedefconfig. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/8] 44x/476fpe: Add 476fpe SoC code
On Sat, Dec 3, 2011 at 5:11 AM, Tony Breeds wrote: > On Sat, Dec 03, 2011 at 07:58:17AM +1100, Benjamin Herrenschmidt wrote: >> On Thu, 2011-12-01 at 18:39 +1100, Tony Breeds wrote: >> > Based on original work by David 'Shaggy' Kliekamp. >> >> Typo in Shaggy's last name :-) > > Rats! > > Looks like I stuffed it up once. Do you need me to respin with these > changes or are the minor enough to be done as the patches are applied? If the plan is to have them go through my tree, I can fix them up when I apply them. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On Wed, Dec 7, 2011 at 7:40 AM, Suzuki Poulose wrote: > Josh, > > I rebased my patches to 3.2.0-rc3 and was able to verify it on my QEMU > setup. > However I am facing problems getting the my boards booted with the network > cards > (even without the patches). Here is what I see : > > > Creating 2 MTD partitions on "1ff80.large-flash": > 0x-0x0038 : "fs" > 0x0038-0x0040 : "firmware" > PPC 4xx OCP EMAC driver, version 3.54 > mal0: failed to map interrupts ! That's the problem. There was a bogus commit that was added to the generic OF code that prevented the normal mapping that the MAL nodes do from working. It was later reverted after Benh told Linus it was bogus. I don't remember which -rc that wound up in, but if you move to 3.2-rc4 that should help. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the 4xx tree with the powerpc tree
On Thu, Dec 8, 2011 at 8:38 PM, Stephen Rothwell wrote:
> Hi Josh,
>
> Today's linux-next merge of the 4xx tree got a conflict in
> arch/powerpc/platforms/40x/ppc40x_simple.c between commit 11eab297f57b
> ("powerpc: Add support for OpenBlockS 600") from the powerpc tree and
> commit d5b9ee7b514e ("powerpc/40x: Add APM8018X SOC support") from the
> 4xx tree.
I blame BenH. I sent him a pull request with d5b9ee7b514e in it
before he went and updated his tree. Still not pulled afaik. Guess
I'll be rebasing my next branch tomorrow to pick up a series from Tony
Breeds, unless Ben handles the outstanding pull before I wake up :).
> I fixed it up (see below) and can carry the fix as necessary.
Looks correct to me. Hopefully you won't have to carry it long.
>
> [Josh: I have changed you contact address to the above]
Thank you.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 3/7] [ppc] Process dynamic relocations for kernel
On Fri, Dec 9, 2011 at 6:47 AM, Suzuki K. Poulose wrote: > > Signed-off-by: Suzuki K. Poulose > Signed-off-by: Josh Poimboeuf > Cc: Paul Mackerras > Cc: Benjamin Herrenschmidt > Cc: Alan Modra > Cc: Kumar Gala > Cc: linuxppc-dev > --- > > arch/powerpc/Kconfig | 42 > ++--- > arch/powerpc/Makefile | 6 +++-- > arch/powerpc/kernel/Makefile | 2 ++ > arch/powerpc/kernel/vmlinux.lds.S | 8 ++- > arch/powerpc/relocs_check.pl | 7 ++ > 5 files changed, 44 insertions(+), 21 deletions(-) You're missing the whole reloc_32.S file in this patch. Forget to do a git-add? Can you resend just this patch with that fixed up? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of new 4xx tree (updated)
On Wed, Nov 30, 2011 at 10:14 AM, Josh Boyer wrote: > Hi Ben, > > I have a new 4xx tree setup now. Two small commits for the next > branch are queued up. I'd like to get the patch series from Suzie and > Tony included soon as well, but thought I'd start with these to get > things rolling. I've updated my next branch to include the Currituck changes from Tony. Suzie's patches from today look good, but he has an error in one of them that is missing a file, so I'll have to send those on once that is fixed. Please pull this time ;) josh The following changes since commit fa8cbaaf5a68f62db3f9a8444ecbb940b47984cb: powerpc+sparc64/mm: Remove hack in mmap randomize layout (2011-11-28 11:42:09 +1100) are available in the git repository at: git://git.infradead.org/users/jwboyer/powerpc-4xx.git next Christoph Egger (1): powerpc/44x: Removing dead CONFIG_PPC47x Josh Boyer (1): MAINTAINERS: Update PowerPC 4xx git tree Tanmay Inamdar (1): powerpc/40x: Add APM8018X SOC support Tony Breeds (7): powerpc/44x: pci: Use PCI_BASE_ADDRESS_MEM_PREFETCH rather than magic value. powerpc/44x: pci: Add a want_sdr flag into ppc4xx_pciex_hwops powerpc/44x: pci: Setup the dma_window properties for each pci_controller powerpc/boot: Add extended precision shifts to the boot wrapper. powerpc/boot: Add mfdcrx powerpc/476fpe: Add 476fpe SoC code powerpc/47x: Add support for the new IBM currituck platform MAINTAINERS |2 +- arch/powerpc/boot/Makefile |5 +- arch/powerpc/boot/dcr.h |6 + arch/powerpc/boot/div64.S| 52 ++ arch/powerpc/boot/dts/currituck.dts | 237 ++ arch/powerpc/boot/dts/klondike.dts | 227 arch/powerpc/boot/treeboot-currituck.c | 119 + arch/powerpc/boot/wrapper|3 + arch/powerpc/configs/40x/klondike_defconfig | 55 ++ arch/powerpc/configs/44x/currituck_defconfig | 110 arch/powerpc/include/asm/reg.h |1 + arch/powerpc/kernel/cputable.c | 27 +++ arch/powerpc/kernel/head_44x.S |2 + arch/powerpc/mm/44x_mmu.c|4 - arch/powerpc/platforms/40x/Kconfig | 11 ++ arch/powerpc/platforms/40x/ppc40x_simple.c |1 + arch/powerpc/platforms/44x/Kconfig | 14 ++ arch/powerpc/platforms/44x/Makefile |1 + arch/powerpc/platforms/44x/currituck.c | 204 ++ arch/powerpc/sysdev/ppc4xx_pci.c | 85 +- arch/powerpc/sysdev/ppc4xx_pci.h |7 + 21 files changed, 1159 insertions(+), 14 deletions(-) create mode 100644 arch/powerpc/boot/dts/currituck.dts create mode 100644 arch/powerpc/boot/dts/klondike.dts create mode 100644 arch/powerpc/boot/treeboot-currituck.c create mode 100644 arch/powerpc/configs/40x/klondike_defconfig create mode 100644 arch/powerpc/configs/44x/currituck_defconfig create mode 100644 arch/powerpc/platforms/44x/currituck.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
On Tue, Dec 20, 2011 at 7:44 AM, Vinh Nguyen Huu Tuong
wrote:
> This patch extends PCI-E driver to support PCI-E for APM821xx SoC on
> Bluestone board.
>
> Signed-off-by: Vinh Nguyen Huu Tuong
> +static int apm821xx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
> +{
> + u32 val;
> + u32 utlset1;
> + u32 timeout;
> +
> + /*
> + * Do a software reset on PCIe ports.
> + * This code is to fix the issue that pci drivers doesn't re-assign
> + * bus number for PCIE devices after Uboot
> + * scanned and configured all the buses (eg. PCIE NIC IntelPro/1000
> + * PT quad port, SAS LSI 1064E)
> + */
> +
> + mtdcri(SDR0, PESDR0_460EX_PHY_CTL_RST + (port->index * 0x55), 0x0);
> + mdelay(10);
> +
> + if (port->endpoint)
> + val = PTYPE_LEGACY_ENDPOINT << 20;
> + else
> + val = PTYPE_ROOT_PORT << 20;
> +
> + if (port->index == 0) {
> + val |= LNKW_X1 << 12;
> + utlset1 = 0x;
> + } else {
> + val |= LNKW_X4 << 12;
> + utlset1 = 0x20101101;
> + }
> +
> + mtdcri(SDR0, port->sdr_base + PESDRn_DLPSET, val);
> + mtdcri(SDR0, port->sdr_base + PESDRn_UTLSET1, utlset1);
> + mtdcri(SDR0, port->sdr_base + PESDRn_UTLSET2, 0x0101);
> +
> + switch (port->index) {
> + case 0:
> + mtdcri(SDR0, PESDR0_460EX_L0CDRCTL, 0x3230);
> + mtdcri(SDR0, PESDR0_460EX_L0DRV, 0x0130);
> + mtdcri(SDR0, PESDR0_460EX_L0CLK, 0x0006);
> +
> + mtdcri(SDR0, PESDR0_460EX_PHY_CTL_RST, 0x1000);
> + mdelay(50);
> + mtdcri(SDR0, PESDR0_460EX_PHY_CTL_RST, 0x3000);
> + break;
> +
> + case 1:
> + mtdcri(SDR0, PESDR1_460EX_L0CDRCTL, 0x3230);
> + mtdcri(SDR0, PESDR1_460EX_L1CDRCTL, 0x3230);
> + mtdcri(SDR0, PESDR1_460EX_L2CDRCTL, 0x3230);
> + mtdcri(SDR0, PESDR1_460EX_L3CDRCTL, 0x3230);
> + mtdcri(SDR0, PESDR1_460EX_L0DRV, 0x0130);
> + mtdcri(SDR0, PESDR1_460EX_L1DRV, 0x0130);
> + mtdcri(SDR0, PESDR1_460EX_L2DRV, 0x0130);
> + mtdcri(SDR0, PESDR1_460EX_L3DRV, 0x0130);
> + mtdcri(SDR0, PESDR1_460EX_L0CLK, 0x0006);
> + mtdcri(SDR0, PESDR1_460EX_L1CLK, 0x0006);
> + mtdcri(SDR0, PESDR1_460EX_L2CLK, 0x0006);
> + mtdcri(SDR0, PESDR1_460EX_L3CLK, 0x0006);
> +
> + mtdcri(SDR0, PESDR1_460EX_PHY_CTL_RST, 0x1000);
> + break;
> + }
Do we need a default case here to catch oddness and exit the function?
> +
> + mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
> + mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) |
> + (PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTPYN));
> +
> + /* Poll for PHY reset */
> + timeout = 0;
> + while ((!(mfdcri(SDR0, PESDR0_460EX_RSTSTA +
> + (port->index * 0x55)) & 0x1)) &&
> + (timeout < PCIE_PHY_RESET_TIMEOUT)) {
> + udelay(10);
> + timeout++;
> + }
> +
> + if (timeout < PCIE_PHY_RESET_TIMEOUT) {
> + mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
> + (mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) &
> + ~(PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTDL)) |
> + PESDRx_RCSSET_RSTPYN);
> +
> + port->has_ibpre = 1;
> +
> + return 0;
> + } else {
> + printk(KERN_INFO "PCIE: Can't reset PHY\n");
> + return -1;
> + }
If we can't reset the PHY, does this whole function essentially fail?
Do the devices not get renumbered, etc? If so, you probably want to
make that KERN_ERR.
> @@ -1751,9 +1856,9 @@ static void __init ppc4xx_configure_pciex_PIMs(struct
> ppc4xx_pciex_port *port,
> * if it works
> */
> out_le32(mbase + PECFG_PIM0LAL, 0x);
> - out_le32(mbase + PECFG_PIM0LAH, 0x);
> + out_le32(mbase + PECFG_PIM0LAH, 0x0008); /* Moving on HB
> */
> out_le32(mbase + PECFG_PIM1LAL, 0x);
> - out_le32(mbase + PECFG_PIM1LAH, 0x);
> + out_le32(mbase + PECFG_PIM1LAH, 0x000c); /* Moving on HB
> */
> out_le32(mbase + PECFG_PIM01SAH, 0x);
> out_le32(mbase + PECFG_PIM01SAL, 0x);
Why are these values changed, and are those changes only needed on APM821xx?
> diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h
> b/arch/powerpc/sysdev/ppc4xx_pci.h
> index 32ce763..faf3017 100644
> --- a/arch/powerpc/sysdev/ppc4xx_pci.h
> +++ b/arch/powerpc/sysdev/ppc4xx_pci.h
> @@ -441,6 +441,7 @@
> /*
> * Config space register offset
Please pull 'next' branch of 4xx tree
Hi Ben, This is the relocatable series from Suzie that has been brewing for quite a while. I also included a small fix for currituck that I hit when I was building various kernels. NOTE: To build anything config that includes the NDFC driver, you need the fix Tony posted and is in linux-next to the ndfc driver. I didn't include it here since it is already queued up in the MTD tree. josh The following changes since commit 3f53638c805f75989f4b4be07efcfd173cdd5e2d: powerpc: Fix old bug in prom_init setting of the color (2011-12-19 14:41:25 +1100) are available in the git repository at: git://git.infradead.org/users/jwboyer/powerpc-4xx.git next Josh Boyer (1): powerpc/44x: Fix build error on currituck platform Suzuki Poulose (7): powerpc: Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE powerpc/44x: Enable DYNAMIC_MEMSTART for 440x powerpc: Process dynamic relocations for kernel powerpc: Define virtual-physical translations for RELOCATABLE powerpc/44x: Enable CONFIG_RELOCATABLE for PPC44x powerpc/44x: Enable CRASH_DUMP for 440x powerpc/boot: Change the load address for the wrapper to fit the kernel arch/powerpc/Kconfig | 45 +- arch/powerpc/Makefile |6 +- arch/powerpc/boot/wrapper | 20 +++ arch/powerpc/configs/44x/iss476-smp_defconfig |3 +- arch/powerpc/include/asm/kdump.h |4 +- arch/powerpc/include/asm/page.h | 89 ++- arch/powerpc/kernel/Makefile |2 + arch/powerpc/kernel/crash_dump.c |4 +- arch/powerpc/kernel/head_44x.S| 105 + arch/powerpc/kernel/head_fsl_booke.S |2 +- arch/powerpc/kernel/machine_kexec.c |2 +- arch/powerpc/kernel/prom_init.c |2 +- arch/powerpc/kernel/reloc_32.S| 208 + arch/powerpc/kernel/vmlinux.lds.S |8 +- arch/powerpc/mm/44x_mmu.c |2 +- arch/powerpc/mm/init_32.c |7 + arch/powerpc/platforms/44x/currituck.c|2 +- arch/powerpc/relocs_check.pl | 14 ++- 18 files changed, 496 insertions(+), 29 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build warnings after merge of the 4xx tree
On Tue, Dec 20, 2011 at 7:13 PM, Stephen Rothwell wrote:
> Hi Josh,
>
> After merging the 4xx tree, today's linux-next build (powerpc ppc64_defconfig)
> produced these warnings:
>
> WARN: Uncompressed kernel (size 0xe32858) overlaps the address of the
> wrapper()
> WARN: Fixing the link_address of wrapper to (0xf0)
> WARN: Uncompressed kernel (size 0xd6c9e8) overlaps the address of the
> wrapper(0x40)
> WARN: Fixing the link_address of wrapper to (0xe0)
>
> Introduced by commit c55aef0e5bc6 ("powerpc/boot: Change the load address
> for the wrapper to fit the kernel"). Maybe "WARN" is not the best
> prefix for this. To me it implies that something may go wrong and there
> is something to be fixed ... If this is purely informational, then maybe
> "INFO" would be better.
INFO indeed would be better. I'll try and whip up a patch tomorrow
unless Suzie beats me to it.
Sorry about that. I saw the WARN during my testing, but the commit
log explicitly mentioned it an brainwashed me into thinking it was OK.
I blame holiday-itis.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Tue, Dec 20, 2011 at 11:23 AM, Josh Boyer wrote: > Hi Ben, > > This is the relocatable series from Suzie that has been brewing for quite a > while. I also included a small fix for currituck that I hit when I was > building > various kernels. > > NOTE: To build anything config that includes the NDFC driver, you need the fix > Tony posted and is in linux-next to the ndfc driver. I didn't include it here > since it is already queued up in the MTD tree. > I've added Suzie's patch from today to change the WARN to INFO in the boot wrapper thing. Updated tree info below. josh The following changes since commit 3f53638c805f75989f4b4be07efcfd173cdd5e2d: powerpc: Fix old bug in prom_init setting of the color (2011-12-19 14:41:25 +1100) are available in the git repository at: git://git.infradead.org/users/jwboyer/powerpc-4xx.git next Josh Boyer (1): powerpc/44x: Fix build error on currituck platform Suzuki Poulose (8): powerpc: Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE powerpc/44x: Enable DYNAMIC_MEMSTART for 440x powerpc: Process dynamic relocations for kernel powerpc: Define virtual-physical translations for RELOCATABLE powerpc/44x: Enable CONFIG_RELOCATABLE for PPC44x powerpc/44x: Enable CRASH_DUMP for 440x powerpc/boot: Change the load address for the wrapper to fit the kernel powerpc/boot: Change the WARN to INFO for boot wrapper overlap message arch/powerpc/Kconfig | 45 +- arch/powerpc/Makefile |6 +- arch/powerpc/boot/wrapper | 20 +++ arch/powerpc/configs/44x/iss476-smp_defconfig |3 +- arch/powerpc/include/asm/kdump.h |4 +- arch/powerpc/include/asm/page.h | 89 ++- arch/powerpc/kernel/Makefile |2 + arch/powerpc/kernel/crash_dump.c |4 +- arch/powerpc/kernel/head_44x.S| 105 + arch/powerpc/kernel/head_fsl_booke.S |2 +- arch/powerpc/kernel/machine_kexec.c |2 +- arch/powerpc/kernel/prom_init.c |2 +- arch/powerpc/kernel/reloc_32.S| 208 + arch/powerpc/kernel/vmlinux.lds.S |8 +- arch/powerpc/mm/44x_mmu.c |2 +- arch/powerpc/mm/init_32.c |7 + arch/powerpc/platforms/44x/currituck.c|2 +- arch/powerpc/relocs_check.pl | 14 ++- 18 files changed, 496 insertions(+), 29 deletions(-) create mode 100644 arch/powerpc/kernel/reloc_32.S ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
On Tue, Dec 20, 2011 at 11:47 PM, Vinh Huu Tuong Nguyen
wrote:
>> +
>> + mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
>> + mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) |
>> + (PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTPYN));
>> +
>> + /* Poll for PHY reset */
>> + timeout = 0;
>> + while ((!(mfdcri(SDR0, PESDR0_460EX_RSTSTA +
>> + (port->index * 0x55)) & 0x1)) &&
>> + (timeout < PCIE_PHY_RESET_TIMEOUT)) {
>> + udelay(10);
>> + timeout++;
>> + }
>> +
>> + if (timeout < PCIE_PHY_RESET_TIMEOUT) {
>> + mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
>> + (mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) &
>> + ~(PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTDL)) |
>> + PESDRx_RCSSET_RSTPYN);
>> +
>> + port->has_ibpre = 1;
>> +
>> + return 0;
>> + } else {
>> + printk(KERN_INFO "PCIE: Can't reset PHY\n");
>> + return -1;
>> + }
>
> If we can't reset the PHY, does this whole function essentially fail?
> Do the devices not get renumbered, etc? If so, you probably want to
> make that KERN_ERR.
> [Vinh Nguyen] if we can't reset the PHY, maybe the device can't work
> properly. I will update codes to return the error in case PHY can't reset.
OK.
>> @@ -1751,9 +1856,9 @@ static void __init
> ppc4xx_configure_pciex_PIMs(struct ppc4xx_pciex_port *port,
>> * if it works
>> */
>> out_le32(mbase + PECFG_PIM0LAL, 0x);
>> - out_le32(mbase + PECFG_PIM0LAH, 0x);
>> + out_le32(mbase + PECFG_PIM0LAH, 0x0008); /* Moving
> on HB */
>> out_le32(mbase + PECFG_PIM1LAL, 0x);
>> - out_le32(mbase + PECFG_PIM1LAH, 0x);
>> + out_le32(mbase + PECFG_PIM1LAH, 0x000c); /* Moving
> on HB */
>> out_le32(mbase + PECFG_PIM01SAH, 0x);
>> out_le32(mbase + PECFG_PIM01SAL, 0x);
>
> Why are these values changed, and are those changes only needed on
> APM821xx?
> [Vinh Nguyen] In system memory map of 460EX chip, we have an "alias DDR
> SDRAM" area that is Local Memory Alias for HB(high bandwidth), so we tried
> to initialize it for speedup. For APM821xx, although we didn't mention
> about this area, this configuration still works well. So we keep it.
This function isn't just called for 460EX or APM821xx SoCs. It's
called on any 4xx SoC with PCIe configured.
Is this change going to work on them all? If not, it needs to be
conditionalized.
>> diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h
> b/arch/powerpc/sysdev/ppc4xx_pci.h
>> index 32ce763..faf3017 100644
>> --- a/arch/powerpc/sysdev/ppc4xx_pci.h
>> +++ b/arch/powerpc/sysdev/ppc4xx_pci.h
>> @@ -441,6 +441,7 @@
>> /*
>> * Config space register offsets
>> */
>> +#define PECFG_ECDEVCTL 0x060
>> #define PECFG_ECRTCTL 0x074
>>
>> #define PECFG_BAR0LMPA 0x210
>> @@ -448,6 +449,7 @@
>> #define PECFG_BAR1MPA 0x218
>> #define PECFG_BAR2LMPA 0x220
>> #define PECFG_BAR2HMPA 0x224
>> +#define PECFG_ECDEVCAPPA 0x25c
>>
>> #define PECFG_PIMEN 0x33c
>> #define PECFG_PIM0LAL 0x340
>> @@ -494,5 +496,7 @@ enum
>> LNKW_X8 = 0x8
>> };
>>
>> +/* Timout for reset phy */
>> +#define PCIE_PHY_RESET_TIMEOUT 10
>
> Is this value applicable to all the 44x devices with PCI-e?
> [Vinh Nguyen] At this time, we only checked this on APM821xx chips.
Then it should probably be conditionalized somehow. Or put as a
worst-case value that will work for them all.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/currituck: Fix up missing MPIC_PRIMARY flag
On Thu, Dec 22, 2011 at 11:21 AM, Kyle Moffett wrote: > The 44x/currituck platform didn't get updated when the MPIC code > inverted the flag from MPIC_PRIMARY => !MPIC_SECONDARY. Fix it up. > > Signed-off-by: Kyle Moffett I already included this fixup in my 4xx tree 'next' branch. A pull request was sent to Ben as well. http://git.infradead.org/users/jwboyer/powerpc-4xx.git/commitdiff/eb975652b8fa0c4f08a52744d34bdebf66589d4b josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc44x/watchdog: Select WATCHDOG_NOWAYOUT option
On Fri, Jul 13, 2012 at 7:50 AM, Kumar Gala wrote: > > On Jul 12, 2012, at 9:44 PM, Jiang Lu wrote: > >> On PPC44x core, the WRC(Watchdog-timer Reset Control) field of TCR >> of timer can not reset by software after set to a non-zero value. >> Which means software can not reset the timeout behaviour of watchdog timer. >> >> This patch selects WATCHDOG_NOWAYOUT option for 44x platforms to >> indicate the watchdog timer can not be disabled once fired. >> >> Signed-off-by: Jiang Lu >> --- >> drivers/watchdog/Kconfig |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) > > I believe this is not 44x specific, but how Book-E watchdog is architected. That is my understanding as well. >> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >> index 3709624..41f3dff 100644 >> --- a/drivers/watchdog/Kconfig >> +++ b/drivers/watchdog/Kconfig >> @@ -1084,6 +1084,7 @@ config PIKA_WDT >> config BOOKE_WDT >> tristate "PowerPC Book-E Watchdog Timer" >> depends on BOOKE || 4xx >> + select WATCHDOG_NOWAYOUT if 44x > > This should probably be 'select WATCHDOG_NOWAYOUT if BOOKE' I kind of disagree with this change. It's a user selectable option for a reason. Right now, if the option is not set we call booke_wdt_disable which indeed does not actually _disable_ the WDT, but it does set the timer period to the maxium value. We could go one step further and implement a simple timer that pops and calls booke_wdt_ping if WATCHDOG_NOWAYOUT is not set, then rearms itself. That would leave the user with the ability to perform recovery of the userspace process that exited or died and was responsible for pinging the watchdog. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc44x/watchdog: Select WATCHDOG_NOWAYOUT option
On Mon, Jul 16, 2012 at 4:28 PM, Tabi Timur-B04825 wrote: > On Fri, Jul 13, 2012 at 7:25 AM, Josh Boyer wrote: > >> Right now, if the option is not set we call booke_wdt_disable which >> indeed does not actually _disable_ the WDT, but it does set the timer >> period to the maxium value. We could go one step further and implement >> a simple timer that pops and calls booke_wdt_ping if WATCHDOG_NOWAYOUT >> is not set, then rearms itself. That would leave the user with the >> ability to perform recovery of the userspace process that exited or >> died and was responsible for pinging the watchdog. > > I think the maximum value is still decades or centuries, so there's no > real reason to complicate the code. I have no idea about FSL cores, but the 4xx maximum value selects TBU bit 31. When that bit flips is going to be determined by the speed of the clock driving TB. Most of the 4xx implementations I have seen use the CPU clock, so to take the example from the 44x user manuals, a 400 MHz clock results in a maximum time period of ~21 seconds. Multiply by 3 to get the time before the WDT actually does a reset and you're at about 1min. > The NOWAYOUT feature is working as designed, so I don't understand the > need for this patch. NOWAYOUT is working. The patch was basically forcing it on, even if the end user doesn't want the behavior described. From what you've said, that simply doesn't matter in the FSL case because the machine will run for a really long time. On 4xx, something needs to be done to keep the machine running if the user doesn't want the NOWAYOUT behavior, which is why I suggested a kernel timer. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][upstream] TDM Framework
On Fri, Jul 20, 2012 at 8:54 AM, Michael Ellerman wrote: > On Fri, 2012-07-20 at 18:05 +0530, sand...@freescale.com wrote: >> From: Sandeep Singh >> >> TDM Framework is an attempt to provide a platform independent layer which can >> offer a standard interface for TDM access to different client modules. >> Beneath, the framework layer can house different types of TDM drivers to >> handle >> various TDM devices, the hardware intricacies of the devices being completely >> taken care by TDM drivers. > > TDM ? And here I was thinking I was the only one scratching his head. All I could come up with was Time Division Multiplexing. Protip: If you use an acronym a billion times in a patch, expand it at least in one place. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
On Tue, Jul 3, 2012 at 4:52 AM, Vinh Nguyen Huu Tuong wrote:
> This patch consists of:
> - Add driver for OCM component
> - Export OCM Information at /sys/kernel/debug/ppc4xx_ocm/info
>
> Signed-off-by: Vinh Nguyen Huu Tuong
Acked-by: Josh Boyer
Ben, could you pick this up? I have nothing else queued in the 4xx
tree at all.
josh
> ---
> arch/powerpc/boot/dts/bluestone.dts |8 +
> arch/powerpc/include/asm/ppc4xx_ocm.h | 45
> arch/powerpc/platforms/44x/Kconfig|8 +
> arch/powerpc/sysdev/Makefile |1 +
> arch/powerpc/sysdev/ppc4xx_ocm.c | 415
> +
> 5 files changed, 477 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/include/asm/ppc4xx_ocm.h
> create mode 100644 arch/powerpc/sysdev/ppc4xx_ocm.c
>
> diff --git a/arch/powerpc/boot/dts/bluestone.dts
> b/arch/powerpc/boot/dts/bluestone.dts
> index 9d4917a..7daaca3 100644
> --- a/arch/powerpc/boot/dts/bluestone.dts
> +++ b/arch/powerpc/boot/dts/bluestone.dts
> @@ -107,6 +107,14 @@
> interrupt-parent = <&UIC0>;
> };
>
> + OCM: ocm@40004 {
> + compatible = "ibm,ocm";
> + status = "ok";
> + cell-index = <1>;
> + /* configured in U-Boot */
> + reg = <4 0x0004 0x8000>; /* 32K */
> + };
> +
> SDR0: sdr {
> compatible = "ibm,sdr-apm821xx";
> dcr-reg = <0x00e 0x002>;
> diff --git a/arch/powerpc/include/asm/ppc4xx_ocm.h
> b/arch/powerpc/include/asm/ppc4xx_ocm.h
> new file mode 100644
> index 000..6ce9046
> --- /dev/null
> +++ b/arch/powerpc/include/asm/ppc4xx_ocm.h
> @@ -0,0 +1,45 @@
> +/*
> + * PowerPC 4xx OCM memory allocation support
> + *
> + * (C) Copyright 2009, Applied Micro Circuits Corporation
> + * Victor Gallardo (vgalla...@amcc.com)
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef __ASM_POWERPC_PPC4XX_OCM_H__
> +#define __ASM_POWERPC_PPC4XX_OCM_H__
> +
> +#define PPC4XX_OCM_NON_CACHED 0
> +#define PPC4XX_OCM_CACHED 1
> +
> +#if defined(CONFIG_PPC4xx_OCM)
> +
> +void *ppc4xx_ocm_alloc(phys_addr_t *phys, int size, int align,
> + int flags, const char *owner);
> +void ppc4xx_ocm_free(const void *virt);
> +
> +#else
> +
> +#define ppc4xx_ocm_alloc(phys, size, align, flags, owner) NULL
> +#define ppc4xx_ocm_free(addr) ((void)0)
> +
> +#endif /* CONFIG_PPC4xx_OCM */
> +
> +#endif /* __ASM_POWERPC_PPC4XX_OCM_H__ */
> diff --git a/arch/powerpc/platforms/44x/Kconfig
> b/arch/powerpc/platforms/44x/Kconfig
> index 8abf6fb8..0effe9f 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -252,6 +252,14 @@ config PPC4xx_GPIO
> help
> Enable gpiolib support for ppc440 based boards
>
> +config PPC4xx_OCM
> + bool "PPC4xx On Chip Memory (OCM) support"
> + depends on 4xx
> + select PPC_LIB_RHEAP
> + help
> + Enable OCM support for PowerPC 4xx platforms with on chip memory,
> + OCM provides the fast place for memory access to improve
> performance.
> +
> # 44x specific CPU modules, selected based on the board above.
> config 440EP
> bool
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 1bd7ecb..6f768e2 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_PPC_INDIRECT_PCI)+= indirect_pci.o
> obj-$(CONFIG_PPC_I8259)+= i8259.o
> obj-$(CONFIG_IPIC) += ipic.o
> obj-$(CONFIG_4xx) += uic.o
> +obj-$(CONFIG_PPC4xx_OCM) += ppc4xx_ocm.o
> obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
> obj-$(CONFIG_XILINX_VIRTEX)
Re: [PATCH] PPC: Enable the Watchdog vector for 405
On Sun, Sep 30, 2012 at 7:27 PM, Jason Gunthorpe
wrote:
> Move the body of the PIT exception out of line to make room.
What boards did you test this on? What driver are you using for the
watchdog?
> Signed-off-by: Jason Gunthorpe
> ---
> arch/powerpc/kernel/head_40x.S | 26 +-
> arch/powerpc/kernel/traps.c|2 +-
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
> index 4989661..7edd7b1 100644
> --- a/arch/powerpc/kernel/head_40x.S
> +++ b/arch/powerpc/kernel/head_40x.S
> @@ -431,29 +431,19 @@ label:
>
> /* 0x1000 - Programmable Interval Timer (PIT) Exception */
> START_EXCEPTION(0x1000, Decrementer)
> - NORMAL_EXCEPTION_PROLOG
> - lis r0,TSR_PIS@h
> - mtspr SPRN_TSR,r0 /* Clear the PIT exception */
> - addir3,r1,STACK_FRAME_OVERHEAD
> - EXC_XFER_LITE(0x1000, timer_interrupt)
> + b pit_longer
>
> -#if 0
> /* NOTE:
> - * FIT and WDT handlers are not implemented yet.
> + * FIT handler is not implemented yet.
> */
>
> /* 0x1010 - Fixed Interval Timer (FIT) Exception
> */
> - STND_EXCEPTION(0x1010, FITException, unknown_exception)
> +// STND_EXCEPTION(0x1010, FITException, unknown_exception)
Please just move the #endif for the #if 0 up instead of putting a C++
style comment here.
> /* 0x1020 - Watchdog Timer (WDT) Exception
> */
> -#ifdef CONFIG_BOOKE_WDT
> CRITICAL_EXCEPTION(0x1020, WDTException, WatchdogException)
> -#else
> - CRITICAL_EXCEPTION(0x1020, WDTException, unknown_exception)
> -#endif
> -#endif
Please leave this wrapped in CONFIG_BOOKE_WDT. I don't agree with
unconditionally enabling this for every 405 chip out there.
> /* 0x1100 - Data TLB Miss Exception
> * As the name implies, translation is not in the MMU, so search the
> @@ -738,6 +728,16 @@ label:
> (MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)), \
> NOCOPY, crit_transfer_to_handler, ret_from_crit_exc)
>
> + /* Programmable Interval Timer (PIT) Exception. The PIT runs into
> + the space reserved for other exceptions, so we branch down
> + to here. */
> +pit_longer:
> + NORMAL_EXCEPTION_PROLOG
> + lis r0,TSR_PIS@h
> + mtspr SPRN_TSR,r0 /* Clear the PIT exception */
> + addir3,r1,STACK_FRAME_OVERHEAD
> + EXC_XFER_LITE(0x1000, timer_interrupt)
> +
> /*
> * The other Data TLB exceptions bail out to this point
> * if they can't resolve the lightweight TLB fault.
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index ae0843f..0701ec1 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -1514,7 +1514,7 @@ void unrecoverable_exception(struct pt_regs *regs)
> die("Unrecoverable exception", regs, SIGABRT);
> }
>
> -#ifdef CONFIG_BOOKE_WDT
> +#if defined(CONFIG_BOOKE_WDT) | defined(CONFIG_40x)
Pretty sure you meant || here? Thought if you just enable the existing
config option, I don't think you'd need to edit this file at all.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Enable the Watchdog vector for 405
On Mon, Oct 1, 2012 at 12:25 PM, Jason Gunthorpe wrote: > On Mon, Oct 01, 2012 at 08:16:29AM -0400, Josh Boyer wrote: >> On Sun, Sep 30, 2012 at 7:27 PM, Jason Gunthorpe >> wrote: >> > Move the body of the PIT exception out of line to make room. >> >> What boards did you test this on? What driver are you using for the >> watchdog? > > Tested on a 405F6 core (Xilinx's variant), the board is custom, and > the control for the watchdog SPRs was bundled into a watchdog driver > for the board's watchdog controller. > >> > /* 0x1020 - Watchdog Timer (WDT) Exception >> > */ >> > -#ifdef CONFIG_BOOKE_WDT >> > CRITICAL_EXCEPTION(0x1020, WDTException, WatchdogException) >> > -#else >> > - CRITICAL_EXCEPTION(0x1020, WDTException, unknown_exception) >> > -#endif >> > -#endif >> >> Please leave this wrapped in CONFIG_BOOKE_WDT. I don't agree with >> unconditionally enabling this for every 405 chip out there. > > What are you concerned with? If some core varient does not put a > watchdog there, then you still get a panic from the default watchdog > exception handler.. I'm concerned with the fact that you've moved PIT and now enabled something that's been enabled for years. There's no need to do it like that. >> > -#ifdef CONFIG_BOOKE_WDT >> > +#if defined(CONFIG_BOOKE_WDT) | defined(CONFIG_40x) >> >> Pretty sure you meant || here? Thought if you just enable the existing >> config option, I don't think you'd need to edit this file at all. > > Yes, I didn't want to use BOOKE_WDT because I have not tested that > driver, nor do I want that driver included in my kernel.. I think the > watchdog driver in use should be orthogonal to having the exception > wired in? And it certainly can be. Just make the driver a module and don't install it or load it. The #ifdef will still evaluate to true. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 31/32] perf powerpc: Use uapi/unistd.h to fix build error
On Sun, Nov 18, 2012 at 9:29 AM, Arnaldo Carvalho de Melo wrote: > From: Sukadev Bhattiprolu > > Use the 'unistd.h' from arch/powerpc/include/uapi to build the perf tool. This would work for powerpc, but at least s390x and ARM have the same build issue. Why would we fix this piecemeal per-arch? David Howells has a patch that _should_ fix it for all of them at once. Is there a reason that isn't going in? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 31/32] perf powerpc: Use uapi/unistd.h to fix build error
On Mon, Nov 19, 2012 at 10:07 AM, Arnaldo Carvalho de Melo wrote: > Em Mon, Nov 19, 2012 at 08:29:09AM -0500, Josh Boyer escreveu: >> On Sun, Nov 18, 2012 at 9:29 AM, Arnaldo Carvalho de Melo >> wrote: >> > From: Sukadev Bhattiprolu > >> > Use the 'unistd.h' from arch/powerpc/include/uapi to build the perf tool. >> >> This would work for powerpc, but at least s390x and ARM have the same >> build issue. Why would we fix this piecemeal per-arch? >> >> David Howells has a patch that _should_ fix it for all of them at once. >> Is there a reason that isn't going in? > > David rebased his patch on top of my perf/core branch, I just tested it > and all works as expected, so I'd say he should push that branch > upstream as I can't just cherry pick some csets, it needs a merge that > involves more than just tools/perf AFAIK. OK... is perf/core (all 32 commits) headed into 3.7? Because the perf build is broken in 3.7-rcX, and we're at the point where Linus gets kind of picky about what he accepts. So we'd need your branch and David's to fix compile issues. And then we'd need Xiao Guangrong's fixes for 'perf kvm' to only build on x86. That's quite a number of fixes we need just to get perf to compile. Is someone other than me keeping track of that? I would just like people to stop wondering when perf builds on non-x86 architectures will work. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [GIT PULL 0/8] perf/urgent fixes
On Fri, Nov 23, 2012 at 7:20 PM, Arnaldo Carvalho de Melo
wrote:
> Hi Ingo,
>
> Tested using a cross-compiler and directly on a Raspberry pi (ARM)
> with
> raspbian.
>
> Please consider pulling.
>
> - Arnaldo
>
> The following changes since commit 18423d3562f396206e0928a71177eeb2edfed077:
>
> Merge tag 'perf-urgent-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
> (2012-11-13 18:51:51 +0100)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
> tags/perf-urgent-for-mingo
>
> for you to fetch changes up to 7321090f6751c9987c26a8c81c63680d16a614d7:
>
> perf kvm: Fix building perf kvm on non x86 arches (2012-11-23 20:40:17
> -0300)
>
>
> perf/urgent fixes
>
> . Don't build 'perf kvm stat" on non-x86 arches, fix from Xiao Guangrong.
>
> . UAPI fixes to get perf building again in non-x86 arches, from David Howells.
>
> Signed-off-by: Arnaldo Carvalho de Melo
>
>
> Arnaldo Carvalho de Melo (1):
> Merge tag 'perf-uapi-20121119' of
> git://git.infradead.org/users/dhowells/linux-headers into perf/urgent
>
> David Howells (6):
> x86: Export asm/{svm.h,vmx.h,perf_regs.h}
> Merge branch 'x86-pre-uapi' into perf-uapi
> tools: Define a Makefile function to do subdir processing
> tools: Honour the O= flag when tool build called from a higher Makefile
> tools: Pass the target in descend
> perf: Make perf build for x86 with UAPI disintegration applied
>
> Sukadev Bhattiprolu (1):
> perf powerpc: Use uapi/unistd.h to fix build error
>
> Xiao Guangrong (2):
> perf kvm: Rename perf_kvm to perf_kvm_stat
> perf kvm: Fix building perf kvm on non x86 arches
I probably sound like a broken record at this point, but I've not seen
this go into any tip branch, nor is it in Linus' tree. Hopefully this
gets pulled before 3.7 is released.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/44x: Add more changes for APM821XX EMAC driver
On Fri, Feb 17, 2012 at 3:07 AM, Duc Dang wrote:
> This patch includes:
>
> Configure EMAC PHY clock source (clock from PHY or internal clock).
>
> Do not advertise PHY half duplex capability as APM821XX EMAC does not
> support half duplex mode.
>
> Add changes to support configuring jumbo frame for APM821XX EMAC.
>
> Signed-off-by: Duc Dang
This should have been sent to netdev. CC'ing them now.
Ben and David, I can take this change through the 4xx tree if it looks OK to
both of you. The pre-requisite DTS patch will go through my tree, so it might
make sense to keep them together.
josh
> ---
> drivers/net/ethernet/ibm/emac/core.c | 26 +-
> drivers/net/ethernet/ibm/emac/core.h | 13 +++--
> drivers/net/ethernet/ibm/emac/emac.h |5 -
> 3 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/ibm/emac/core.c
> b/drivers/net/ethernet/ibm/emac/core.c
> index ed79b2d..de620f1 100644
> --- a/drivers/net/ethernet/ibm/emac/core.c
> +++ b/drivers/net/ethernet/ibm/emac/core.c
> @@ -434,6 +434,11 @@ static inline u32 emac_iff2rmr(struct net_device *ndev)
> else if (!netdev_mc_empty(ndev))
> r |= EMAC_RMR_MAE;
>
> + if (emac_has_feature(dev, EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE)) {
> + r &= ~EMAC4_RMR_MJS_MASK;
> + r |= EMAC4_RMR_MJS(ndev->mtu);
> + }
> +
> return r;
> }
>
> @@ -965,6 +970,7 @@ static int emac_resize_rx_ring(struct emac_instance *dev,
> int new_mtu)
> int rx_sync_size = emac_rx_sync_size(new_mtu);
> int rx_skb_size = emac_rx_skb_size(new_mtu);
> int i, ret = 0;
> + int mr1_jumbo_bit_change = 0;
>
> mutex_lock(&dev->link_lock);
> emac_netif_stop(dev);
> @@ -1013,7 +1019,14 @@ static int emac_resize_rx_ring(struct emac_instance
> *dev, int new_mtu)
> }
> skip:
> /* Check if we need to change "Jumbo" bit in MR1 */
> - if ((new_mtu > ETH_DATA_LEN) ^ (dev->ndev->mtu > ETH_DATA_LEN)) {
> + if (emac_has_feature(dev, EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE))
> + mr1_jumbo_bit_change = (new_mtu > ETH_DATA_LEN) ||
> + (dev->ndev->mtu > ETH_DATA_LEN);
> + else
> + mr1_jumbo_bit_change = (new_mtu > ETH_DATA_LEN) ^
> + (dev->ndev->mtu > ETH_DATA_LEN);
> +
> + if (mr1_jumbo_bit_change) {
> /* This is to prevent starting RX channel in emac_rx_enable() */
> set_bit(MAL_COMMAC_RX_STOPPED, &dev->commac.flags);
>
> @@ -2471,6 +2484,7 @@ static int __devinit emac_init_phy(struct emac_instance
> *dev)
>
> /* Disable any PHY features not supported by the platform */
> dev->phy.def->features &= ~dev->phy_feat_exc;
> + dev->phy.features &= ~dev->phy_feat_exc;
>
> /* Setup initial link parameters */
> if (dev->phy.features & SUPPORTED_Autoneg) {
> @@ -2568,6 +2582,10 @@ static int __devinit emac_init_config(struct
> emac_instance *dev)
> if (of_device_is_compatible(np, "ibm,emac-405ex") ||
> of_device_is_compatible(np, "ibm,emac-405exr"))
> dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
> + if (of_device_is_compatible(np, "ibm,emac-apm821xx"))
> + dev->features |= (EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE
> + | EMAC_FTR_APM821XX_NO_HALF_DUPLEX
> + | EMAC_FTR_460EX_PHY_CLK_FIX);
> } else if (of_device_is_compatible(np, "ibm,emac4")) {
> dev->features |= EMAC_FTR_EMAC4;
> if (of_device_is_compatible(np, "ibm,emac-440gx"))
> @@ -2818,6 +2836,12 @@ static int __devinit emac_probe(struct platform_device
> *ofdev)
> dev->stop_timeout = STOP_TIMEOUT_100;
> INIT_DELAYED_WORK(&dev->link_work, emac_link_timer);
>
> + /* Some SoCs like APM821xx does not support Half Duplex mode. */
> + if (emac_has_feature(dev, EMAC_FTR_APM821XX_NO_HALF_DUPLEX))
> + dev->phy_feat_exc = (SUPPORTED_1000baseT_Half
> + | SUPPORTED_100baseT_Half
> + | SUPPORTED_10baseT_Half);
> +
> /* Find PHY if any */
> err = emac_init_phy(dev);
> if (err != 0)
> diff --git a/drivers/net/ethernet/ibm/emac/core.h
> b/drivers/net/ethernet/ibm/emac/core.h
> index fa3ec57..9dea85a 100644
> --- a/drivers/net/ethernet/ibm/emac/core.h
> +++ b/drivers/net/ethernet/ibm/emac/core.h
> @@ -325,7 +325,14 @@ struct emac_instance {
> * Set if we need phy clock workaround for 460ex or 460gt
> */
> #define EMAC_FTR_460EX_PHY_CLK_FIX 0x0400
> -
> +/*
> + * APM821xx requires Jumbo frame size set explicitly
> + */
> +#define EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE 0x0800
> +/*
> + * APM821xx does not support Half Duplex mode
> + */
> +#define EMAC_FTR_APM821XX_NO_HALF_DUPLEX 0x1000
>
> /* Right now, we don't quite handle the always/
Re: [PATCH 1/3] powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
On Tue, Dec 20, 2011 at 7:43 AM, Vinh Nguyen Huu Tuong wrote: > This patch consists of: > - Fix the pvr mask for checking pvr in cputable.c > - Fix the cpu name as consistent with cpu name is describled in dts file > > Signed-off-by: Vinh Nguyen Huu Tuong > --- I was waiting to see if you would submit a new series with patch 3/3 fixed for the comments I made. Seems you haven't yet or I missed it entirely. For now, I'll take this patch as it's stand-alone. The DTS and PCI driver patches will need to be submitted together again. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for APM821xx SoC and Bluestone board
On Wed, Feb 29, 2012 at 3:47 AM, Mai La wrote:
> This patch consists of:
> - Enable PCI MSI as default for Bluestone board
> - Define number of MSI interrupt for Maui APM821xx
What is Maui? Is that the same thing as Bluestone?
> - Fix returning ENODEV as finding MSI node
> - Fix MSI physical high and low address
> - Keep MSI data logically
>
> Signed-off-by: Mai La
Wow. So there are a lot of bugfixes here. I'm surprised this ever worked at
all with some of the things you're fixing. Nice to see.
> ---
> arch/powerpc/platforms/44x/Kconfig | 2 ++
> arch/powerpc/sysdev/ppc4xx_msi.c | 28 ++--
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/platforms/44x/Kconfig
> b/arch/powerpc/platforms/44x/Kconfig
> index fcf6bf2..9f04ce3 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -23,6 +23,8 @@ config BLUESTONE
> default n
> select PPC44x_SIMPLE
> select APM821xx
> + select PCI_MSI
> + select PPC4xx_MSI
> select IBM_EMAC_RGMII
> help
> This option enables support for the APM APM821xx Evaluation board.
> diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c
> b/arch/powerpc/sysdev/ppc4xx_msi.c
> index 1c2d7af..6103908 100644
> --- a/arch/powerpc/sysdev/ppc4xx_msi.c
> +++ b/arch/powerpc/sysdev/ppc4xx_msi.c
> @@ -31,7 +31,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> @@ -43,7 +43,12 @@
> #define PEIH_FLUSH0 0x30
> #define PEIH_FLUSH1 0x38
> #define PEIH_CNTRST 0x48
> +
> +#ifdef CONFIG_APM821xx
> +#define NR_MSI_IRQS 8
> +#else
> #define NR_MSI_IRQS 4
> +#endif
Hm. Do you think this is going to change quite a bit depending on which SoC
is being used? If so, it might be better to introduce a Kconfig variable
that just defines this instead. Something like:
config 4xx_MSI_IRQS
int "Number of MSI IRQs"
depends on 4xx
default "8" if APM821xx
default "4" if !APM821xx
If there aren't going to be a wide variety of numbers, then the simple ifdef
you have is probably sufficient.
> struct ppc4xx_msi {
> u32 msi_addr_lo;
> @@ -150,12 +155,11 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device
> *dev,
> if (!sdr_addr)
> return -1;
>
> - SDR0_WRITE(sdr_addr, (u64)res.start >> 32); /*HIGH addr */
> - SDR0_WRITE(sdr_addr + 1, res.start & 0x); /* Low addr */
> -
> + mtdcri(SDR0, *sdr_addr, res.start >> 32); /*HIGH addr */
> + mtdcri(SDR0, *sdr_addr + 1, res.start & 0x);/* Low addr */
Don't you still want the (u64) cast on res.start?
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is for the sole use of the intended recipient(s) and contains information
> that is confidential and proprietary to AppliedMicro Corporation or its
> subsidiaries.
> It is to be used solely for the purpose of furthering the parties' business
> relationship.
> All unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by reply
> e-mail
> and destroy all copies of the original message.
Is there a way you can drop this? Others from APM seem to have figured out
how to do that, so hopefully it won't be a big problem.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/2] powerpc/44x: Add new compatible value for EMAC node of APM821XX dts file.
On Tue, Mar 6, 2012 at 5:08 PM, David Miller wrote: > From: Duc Dang > Date: Mon, 5 Mar 2012 17:57:42 +0700 > >> This compatible value will be used to distinguish some special features of >> APM821XX EMAC: no half duplex mode support, configuring jumbo frame. >> >> Signed-off-by: Duc Dang > > Applied. So I guess we're taking these through your tree? I guess that works out well enough since the other patches I was going to send to Ben aren't panning out anyway. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
On Thu, Mar 8, 2012 at 10:35 PM, Benjamin Herrenschmidt wrote: > On Fri, 2012-03-09 at 10:17 +0700, Mai La wrote: >> This patch consists of: >> - Enable PCI MSI as default for Bluestone board >> - Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone >> board >> - Fix returning ENODEV as finding MSI node >> - Fix MSI physical high and low address >> - Keep MSI data logically >> >> Signed-off-by: Mai La >> --- > >> index 7b4df37..c86231e 100644 >> --- a/arch/powerpc/sysdev/Kconfig >> +++ b/arch/powerpc/sysdev/Kconfig >> @@ -20,6 +20,12 @@ config PPC_MSI_BITMAP >> default y if FSL_PCI >> default y if PPC4xx_MSI >> >> +config PPC4xx_NR_MSI_IRQS >> + int "Number of PCI MSI interrupts" >> + depends on PCI_MSI && PPC4xx_MSI >> + default "4" if !APM821xx >> + default "8" if APM821xx >> + > > .../... > >> +#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS > > ARGH. > > We asked to -NOT MAKE THIS A COMPILE TIME OPTION- Actually, I asked for basically exactly above. I was _wrong_ in asking, but it was asked for. > CONFIG_foo is as bad as your previous ifdef, in fact you just added a > useless config option here. > > Make that number dynamic. Count the entries in the device-tree (or add > a property with the number in it, whatever you fancy the most) but make > it something detected at RUNTIME ! My apologies Mai. Ben is correct here and I should have thought more about my suggestion before I made it. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] Kdump support for PPC_47x
On Wed, Mar 14, 2012 at 6:22 AM, Suzuki K. Poulose wrote: > The following series implements Kexec/Kdump support for > PPC_47x based platforms. Doesn't support SMP yet. > > I have tested these patches on simics simulator for ppc476. Do you happen to know if these work in the IBM Instruction Set Simulator for 47x? That would be the only commonly available 476 platform that I'm aware of. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] [v3] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
On Mon, Mar 12, 2012 at 4:07 AM, Mai La wrote:
> diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c
> b/arch/powerpc/sysdev/ppc4xx_msi.c
> index 1c2d7af..63989d0 100644
> --- a/arch/powerpc/sysdev/ppc4xx_msi.c
> +++ b/arch/powerpc/sysdev/ppc4xx_msi.c
> @@ -28,10 +28,11 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> @@ -43,13 +44,14 @@
> #define PEIH_FLUSH0 0x30
> #define PEIH_FLUSH1 0x38
> #define PEIH_CNTRST 0x48
> -#define NR_MSI_IRQS 4
> +
> +int msi_irqs;
This should be static.
> struct ppc4xx_msi {
> u32 msi_addr_lo;
> u32 msi_addr_hi;
> void __iomem *msi_regs;
> - int msi_virqs[NR_MSI_IRQS];
> + int *msi_virqs;
> struct msi_bitmap bitmap;
> struct device_node *msi_dev;
> };
> @@ -61,7 +63,7 @@ static int ppc4xx_msi_init_allocator(struct platform_device
> *dev,
> {
> int err;
>
> - err = msi_bitmap_alloc(&msi_data->bitmap, NR_MSI_IRQS,
> + err = msi_bitmap_alloc(&msi_data->bitmap, msi_irqs,
> dev->dev.of_node);
> if (err)
> return err;
> @@ -83,6 +85,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int
> nvec, int type)
> struct msi_desc *entry;
> struct ppc4xx_msi *msi_data = &ppc4xx_msi;
>
> + msi_data->msi_virqs = kmalloc((msi_irqs) * sizeof(int),
> + GFP_KERNEL);
> +
What happens if this allocation fails? Unlikely perhaps, but we should still
probably try and handle the error.
> list_for_each_entry(entry, &dev->msi_list, list) {
> int_no = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
> if (int_no >= 0)
> @@ -234,6 +241,10 @@ static int __devinit ppc4xx_msi_probe(struct
> platform_device *dev)
> goto error_out;
> }
>
> + msi_irqs = of_irq_count(dev->dev.of_node);
> + if (!msi_irqs)
> + return -1;
> +
Maybe return -ENODEV here instead of -1? It probably doesn't matter at the
moment, but if anything actually checked why the probe function failed, that
would be more descriptive.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of 4xx tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ben, A small pull request for linux-next. This adds some commits for Bluestone from APM, and updates the location of my tree in MAINTAINERS back to kernel.org. Stephen, could you change linux-next to pull from this tree instead of the infradead one? josh The following changes since commit 01e8ec4417d3c484986af0adaa0ae6632e0a59cd: powerpc: Fix power4/970 idle code regression with lockdep (2012-03-16 09:28:17 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Josh Boyer (1): MAINTAINERS: Update PowerPC 4xx tree Vinh Nguyen Huu Tuong (3): powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board powerpc/44x: Add additional device support for APM821xx SoC and Bluestone board MAINTAINERS|2 +- arch/powerpc/boot/dts/bluestone.dts| 127 +++- arch/powerpc/kernel/cputable.c |2 +- arch/powerpc/platforms/44x/Kconfig |1 + arch/powerpc/platforms/44x/ppc44x_simple.c |2 +- arch/powerpc/sysdev/ppc4xx_pci.c | 70 +++ 6 files changed, 199 insertions(+), 5 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPY0LZAAoJEKMba9ckhs/WDZ4P/2GQjY6H939+bCfRrTE7TwiB U7HSyTyY4Cai6hCj02tAK8RAFQ0OQHQcPfuVSTHoc3hN3lqhtlJV4ishK7fCAwii 2UTBXs+IAUhbx+6wJtmpEvist6Cx1sxsU4iJBVBuyqZxELF0S/5Xwg6aOKE0vwsH aL+hiw8zqoCYTbJZ4PE7vf18Iq+PZeVOAlYyFl9r6vKkY4KvQga7vgE2m/uNvueu WQevSUSLbhknHZfGaQL8MMjLA7yzGmGIyZI/rxkop7xZ2HFuvaahUNBCfsPslUAp vi7P8h9bPKuN6A6MeSza/l3CIR7tIUvv+uBbCNNlLYBy3+4Xpk6hT6vD94y3nvqK 5kY2vjxTHQmHw8kh4ojnT9OaBnMCLA+dB4V+GejbtNkv/V5Aw3Flv6ILMQVu1dWq 4588bcKY0Xj+mqQbd5yQQGVTJBGXC/k6eDLrzYhOEQU5cSogdGK5kgyv2ydc+5/Z I/5dQymM2htXUuR6oD0RNIEWWriFGaLvFiZbJJSnxB9s+o6o77AXossxNL0gOEPr cqr9ZpSuNujaGN2HzTen1TJNAwCM09PES5vhZDdxDC7prtwR+Ke7ElIbDQsRZF34 jcj7WOeyF38C4G01epdCTYzhKe4I1WyT9ugcjE4LOvYfCuI01II142772/hwBC8+ Icccdg6ASNE8cx62TxDl =SHv8 -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
On Wed, Mar 21, 2012 at 8:10 AM, Robert Berger wrote: > Hi, > > Up to 3.2.x I was able to compile a mainline kernel for the kilauea > board, but... > > http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81 > > shows, that mfdcrx was introduced in the v3.3 kernel. > > The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the > ELDK 4.2) this assembly instruction is not known and the build breaks. Sigh. GCC 4.2 is pretty old at this point. > There are some obvious workarounds, like using a more recent toolchain > (e.g ELDK 5.x) or use make -k to keep on compiling even when there is an > error as much as possible;) That would be the most expedient option, yes. > What puzzles me is that also stuff for boards is being compiled which is > not really needed like treeboot-currituck.c even when I configure the > kernel for a kilauea board. > > Is this on purpose and if so why? All of the stuff in arch/powerpc/boot/ is built regardless of the configured board and stuffed into a wrapper.a archive. Then the individual board targets are built and the necessary pieces are pulled from the wrapper.a file. > Please advise. If upgrading ELDK is an option for you, it will get you the quickest solution. Otherwise we'll need to figure out how to stub out the instruction in boot/dcr.h and use the asm long trick. Ew. I can look at that next week. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
On Sat, Mar 24, 2012 at 7:53 PM, Benjamin Herrenschmidt wrote: > On Wed, 2012-03-21 at 17:25 +0100, Wolfgang Denk wrote: >> > > The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes >> with the >> > > ELDK 4.2) this assembly instruction is not known and the build >> breaks. >> > >> > Sigh. GCC 4.2 is pretty old at this point. >> >> But still rock-solid ... We use it a lot, especially as reference for >> more recent (and sometimes more broken) versions of GCC. > > Isn't this a binutils rather than gcc issue ? Pretty much. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt wrote: > On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote: > >> Hi Josh Boyer, >> >> just wanted to add that I'm experiencing the same problem that Robert >> reported, but on 8xx instead of 4xx. The mpc8xx does not support the >> mfdcrx instruction, so maybe it's more to it than just a binutils bug? > > The kernel shouldn't have tried to build that instruction on 8xx, though > I suppose if it's in arch/powerpc/boot, we are a bit too eager at > building everything including what's not relevant, we might to be a bit > more careful at excluding 4xx stuff on a 8xx kernel. It's still a binutils issue. Sounds like the toolchain being used to build the 8xx kernel is specifically built for 8xx. A generally built binutils should have worked fine (assuming it was new enough), since we pass -mcpu=405. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
On Mon, Apr 2, 2012 at 5:08 PM, Benjamin Herrenschmidt wrote: > On Mon, 2012-04-02 at 08:10 -0400, Josh Boyer wrote: >> On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt >> wrote: >> > On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote: >> > >> >> Hi Josh Boyer, >> >> >> >> just wanted to add that I'm experiencing the same problem that Robert >> >> reported, but on 8xx instead of 4xx. The mpc8xx does not support the >> >> mfdcrx instruction, so maybe it's more to it than just a binutils bug? >> > >> > The kernel shouldn't have tried to build that instruction on 8xx, though >> > I suppose if it's in arch/powerpc/boot, we are a bit too eager at >> > building everything including what's not relevant, we might to be a bit >> > more careful at excluding 4xx stuff on a 8xx kernel. >> >> It's still a binutils issue. Sounds like the toolchain being used to >> build the 8xx kernel is specifically built for 8xx. A generally built >> binutils should have worked fine (assuming it was new enough), since >> we pass -mcpu=405. > > Still, it makes sense to limit the building of the wrappers to the CPU > family of the kernel... Oh, I'm not really disagreeing with that. I think I said as much about 4 years ago, but at the time the prevailing opinion was what we currently have. I never really understood why. Out with the old, in with the sane. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] powerpc: dts: klondike: Add UART nodes
On Tue, Apr 3, 2012 at 11:57 AM, Grant Likely wrote:
> On Mon, 2 Apr 2012 12:09:05 +0530, Tanmay Inamdar wrote:
>> Adding UART nodes in Klondike device tree file.
>>
>> Signed-off-by: Tanmay Inamdar
>> ---
>> :100644 100644 4ff2852... d5bf2e1... M
>> arch/powerpc/boot/dts/klondike.dts
>> arch/powerpc/boot/dts/klondike.dts | 24
>> 1 files changed, 24 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/boot/dts/klondike.dts
>> b/arch/powerpc/boot/dts/klondike.dts
>> index 4ff2852..d5bf2e1 100644
>> --- a/arch/powerpc/boot/dts/klondike.dts
>> +++ b/arch/powerpc/boot/dts/klondike.dts
>> @@ -222,6 +222,30 @@
>> #size-cells = <1>;
>> ranges;
>> clock-frequency = <0>;
>> +
>> + UART0: serial@50001000 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <0x50001000 0x0100>;
>> + virtual-reg = <0x50001000>;
>
> Why do you need virtual-reg? The kernel should handle all iomapping
> properly without this.
Right. It's been used for platforms that actually use the
zImage/treeImage wrapper for printf support, but this uses u-boot as
far as I know. It shouldn't need it.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] Kdump support for 47x
On Wed, Apr 25, 2012 at 5:22 AM, Suzuki K. Poulose wrote: > On 04/16/2012 01:56 PM, Suzuki K. Poulose wrote: >> >> The following series implements Kexec/Kdump support for >> PPC_47x based platforms. Doesn't support SMP yet. >> >> I have tested these patches on the following simulators: >> 1) simics >> 2) IBM ISS for ppc476. >> >> Changes since V1: >> * Initialize the SPRN_PID to kernel pid (0) before the TLB operations in >> setup_map_47x >> >> > > Josh, > > Did you get a chance to look at this ? Not yet. I'll try to get to this and some other patches APM submitted before the end of the week. Apologies for the delay. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2 5/5] powerpc: kernel: 16650 UART reg-shift support
On Mon, Apr 9, 2012 at 3:20 AM, Tanmay Inamdar wrote:
> In APM8018X SOC, UART register address space has been relocated to 32-bit
> data boundaries for APB bus implementation.
> Current legacy_serial driver ignores the reg-shift property. This patch
> modifies legacy_serial.c and udbg_16550.c to work with above mentioned UARTs.
>
> Signed-off-by: Tanmay Inamdar
> ---
> :100644 100644 8338aef... f5fc106... M arch/powerpc/include/asm/udbg.h
> :100644 100644 bedd12e... d523b7d... M arch/powerpc/kernel/legacy_serial.c
> :100644 100644 6837f83... e0cb7dc... M arch/powerpc/kernel/udbg_16550.c
> arch/powerpc/include/asm/udbg.h | 2 +-
> arch/powerpc/kernel/legacy_serial.c | 16 +---
> arch/powerpc/kernel/udbg_16550.c | 64 ++
> 3 files changed, 52 insertions(+), 30 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
> index 8338aef..f5fc106 100644
> --- a/arch/powerpc/include/asm/udbg.h
> +++ b/arch/powerpc/include/asm/udbg.h
> @@ -29,7 +29,7 @@ extern void udbg_printf(const char *fmt, ...)
> extern void udbg_progress(char *s, unsigned short hex);
>
> extern void udbg_init_uart(void __iomem *comport, unsigned int speed,
> - unsigned int clock);
> + unsigned int clock, unsigned int regshift);
> extern unsigned int udbg_probe_uart_speed(void __iomem *comport,
> unsigned int clock);
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c
> b/arch/powerpc/kernel/legacy_serial.c
> index bedd12e..d523b7d 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -33,6 +33,7 @@ static struct legacy_serial_info {
> unsigned int clock;
> int irq_check_parent;
> phys_addr_t taddr;
> + unsigned int regshift;
> } legacy_serial_infos[MAX_LEGACY_SERIAL_PORTS];
>
> static struct __initdata of_device_id legacy_serial_parents[] = {
> @@ -42,6 +43,7 @@ static struct __initdata of_device_id
> legacy_serial_parents[] = {
> {.compatible = "ibm,opb",},
> {.compatible = "simple-bus",},
> {.compatible = "wrs,epld-localbus",},
> + {.compatible = "apm,apb",},
> {},
> };
>
> @@ -163,11 +165,6 @@ static int __init add_legacy_soc_port(struct device_node
> *np,
> if (of_get_property(np, "clock-frequency", NULL) == NULL)
> return -1;
>
> - /* if reg-shift or offset, don't try to use it */
> - if ((of_get_property(np, "reg-shift", NULL) != NULL) ||
> - (of_get_property(np, "reg-offset", NULL) != NULL))
> - return -1;
> -
So we explicitly didn't support reg-shift before. I'm guessing there is
a reason for that, but I don't recall what. Ben?
Also, why do you need to use the legacy serial driver at all for this
SOC? As far as I remember, the OF serial driver should be sufficient.
> +static unsigned int reg_shift;
> +#define ns16550_offset(addr) (addr - (unsigned char *)udbg_comport)
> +
> static struct NS16550 __iomem *udbg_comport;
>
> +static inline u8 serial_read(unsigned char *addr)
> +{
> + u32 offset = ns16550_offset(addr) << reg_shift;
> + return readb(udbg_comport + offset);
> +}
> +
> +static inline void serial_write(unsigned char *addr, char val)
> +{
> + u32 offset = ns16550_offset(addr) << reg_shift;
> + writeb(val, udbg_comport + offset);
> +}
> +
I don't think readb/writeb are correct here. Why did you switch to
using those instead of sticking with in_8/out_8?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2 2/5] powerpc: 40x: Add AHB, APB of_device_ids
On Mon, Apr 9, 2012 at 3:20 AM, Tanmay Inamdar wrote: > Adding of_device_id's for AHB and APB buses used in klondike (APM8018X) in > platforms/40x/ppc40x_simple.c file > > Signed-off-by: Tanmay Inamdar You should probably combine the first 3 patches in this series into one patch. Otherwise you run the risk of changing the DTS to something the kernel can't support. At the least, this change should be patch 1 in the series, and you can probably combine the two DTS changes. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of 4xx tree
Hi Ben, A few patches from Suzie for 47x kexec/kdump support, and some MSI patches from Mai La. josh The following changes since commit ec34a6814988f17506733c1e8b058ce46602591d: powerpc: Remove old powerpc specific ptrace getregs/setregs calls (2012-04-30 15:37:28 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next for you to fetch changes up to 9c6b2353dfb80ae843b831c03fc53ddc5c3949ff: powerpc/44x: Add PCI MSI node for Maui APM821xx SoC and Bluestone board in DTS (2012-05-03 08:58:21 -0400) Mai La (2): powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board powerpc/44x: Add PCI MSI node for Maui APM821xx SoC and Bluestone board in DTS Suzuki Poulose (3): powerpc/44x: Fix/Initialize PID to kernel PID before the TLB search powerpc/47x: Kernel support for KEXEC powerpc/47x: Enable CRASH_DUMP arch/powerpc/Kconfig|4 +- arch/powerpc/boot/dts/bluestone.dts | 25 + arch/powerpc/kernel/misc_32.S | 203 +-- arch/powerpc/platforms/44x/Kconfig |2 + arch/powerpc/sysdev/ppc4xx_msi.c| 42 +--- 5 files changed, 252 insertions(+), 24 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Wed, May 2, 2012 at 9:51 AM, Josh Boyer wrote: > Hi Ben, > > A few patches from Suzie for 47x kexec/kdump support, and some MSI patches > from Mai La. > > josh > > The following changes since commit ec34a6814988f17506733c1e8b058ce46602591d: > > powerpc: Remove old powerpc specific ptrace getregs/setregs calls > (2012-04-30 15:37:28 +1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Bump? There's also one small addition on top to fix a build error with -Werror. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc -next rebase WARNING
On Tue, May 22, 2012 at 12:40 AM, Benjamin Herrenschmidt wrote: > On Tue, 2012-05-22 at 11:51 +1000, Benjamin Herrenschmidt wrote: >> Folks, bad news ... my fault. >> >> I accidentally forgot a --signoff on a git am command last week, meaning >> that a pair of patches are in -next and not signed off by me. >> >> For various (legal) reasons that cannot go into Linus tree as-is, so I >> have to rebase the tree to fix it. >> >> Sorry about that ... > > Note that the rebase only affects the top 3 commits, so if your > tree is based on something older you're fine (Kumar, you seem to > be ok, I haven't checked Josh). Should be fine. Even if not, all 4 of its users will manage to cope. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
On Tue, Jun 12, 2012 at 8:40 PM, Benjamin Herrenschmidt wrote: > On Tue, 2012-06-12 at 17:26 +0700, Vinh Huu Tuong Nguyen wrote: >> > -Original Message- >> > From: Vinh Nguyen Huu Tuong [mailto:vhtngu...@apm.com] >> > Sent: Monday, May 07, 2012 10:53 AM >> > To: Benjamin Herrenschmidt; Paul Mackerras; Josh Boyer; Matt Porter; >> > Grant Likely; Rob Herring; Duc Dang; David S. Miller; Kumar Gala; Li >> > Yang; Ashish Kalra; Anatolij Gustschin; Liu Gang; linuxppc- >> > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; devicetree- >> > disc...@lists.ozlabs.org >> > Cc: Vinh Nguyen Huu Tuong >> > Subject: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx >> > SoC and Bluestone board > > Such a CC list won't get you any good will. Send it only to the relevant > mailing lists with possibly the -one- concerned maintainer on CC. I > doubt Dave Miller or Matt Porter give any damn about those patches. > > As for why it wasn't reviewed yet, well, reviewers are a finite resource > with limited time dedicated to it. If the patch is properly formed and > was posted to the linuxppc-...@ozlabs.org, it should be tracked on > patchwork.ozlabs.org and won't be lost. Double check it's there (if it's > not, then the patch was probably corrupt). It's there. I just missed it until today. My apologies Vinh. I'll do a more formal review tomorrow, but at first glance I'm concerned with the sysfs usage. The files in sysfs are supposed to be one file per value, and you see to have something akin to /proc/meminfo in the sysfs file being created. Perhaps that would be better either split into unique file names per field in sysfs, or in a debugfs file instead? Again, I'll review more closely tomrorow. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
On Sun, May 6, 2012 at 11:52 PM, Vinh Nguyen Huu Tuong
wrote:
> This patch consists of:
> - Add driver for OCM component
> - Export OCM Information at /sys/class/ocm/ocminfo
Again, apologies for the delay. Aside from the incorrect sysfs usage
I pointed out in my other reply, I have just a few comments/questions
below.
> diff --git a/arch/powerpc/boot/dts/bluestone.dts
> b/arch/powerpc/boot/dts/bluestone.dts
> index 7bda373..2687c11 100644
> --- a/arch/powerpc/boot/dts/bluestone.dts
> +++ b/arch/powerpc/boot/dts/bluestone.dts
> @@ -107,6 +107,14 @@
> interrupt-parent = <&UIC0>;
> };
>
> + OCM1: ocm@40004 {
> + compatible = "ibm,ocm";
> + status = "ok";
> + cell-index = <1>;
> + /* configured in U-Boot */
> + reg = <4 0x0004 0x8000>; /* 32K */
> + };
> +
> SDR0: sdr {
> compatible = "ibm,sdr-apm821xx";
> dcr-reg = <0x00e 0x002>;
> diff --git a/arch/powerpc/include/asm/ppc4xx_ocm.h
> b/arch/powerpc/include/asm/ppc4xx_ocm.h
> new file mode 100644
> index 000..ff7f386
> --- /dev/null
> +++ b/arch/powerpc/include/asm/ppc4xx_ocm.h
> @@ -0,0 +1,47 @@
> +/*
> + * PowerPC 4xx OCM memory allocation support
> + *
> + * (C) Copyright 2009, Applied Micro Circuits Corporation
> + * Victor Gallardo (vgalla...@amcc.com)
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef __ASM_POWERPC_PPC4xx_OCM_H__
> +#define __ASM_POWERPC_PPC4xx_OCM_H__
> +
> +#include
> +
> +#define OCM_NON_CACHED 0
> +#define OCM_CACHED 1
> +
> +#if defined(CONFIG_PPC4xx_OCM)
> +
> +void *ocm_alloc(phys_addr_t *phys, int size, int align,
> + int flags, const char *owner);
> +void ocm_free(const void *virt);
> +
> +#else
> +
> +#define ocm_alloc(phys, size, align, flags, owner) NULL
> +#define ocm_free(addr) ((void)0)
> +
> +#endif /* CONFIG_PPC4xx_OCM */
> +
> +#endif /* __ASM_POWERPC_PPC4xx_OCM_H__ */
I don't see any users of this header included in the patch. I'm going
to guess that follow-on drivers/users are queued once this is in the
tree? Also, you might want to name these 'ppc4xx_ocm_alloc' or
similar. The concept of OCM isn't limited to ppc4xx or even SoCs, so
just using 'ocm' in the global kernel namespace might not be great.
> diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c
> b/arch/powerpc/sysdev/ppc4xx_ocm.c
> new file mode 100644
> index 000..ba3e450
> --- /dev/null
> +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
> @@ -0,0 +1,420 @@
> +#include
> +#include
> +#include
Why do you need proc_fs.h?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define OCM_DISABLED 0
> +#define OCM_ENABLED 1
> +
> +struct ocm_block {
> + struct list_head list;
> + void __iomem *addr;
> + int size;
> + const char *owner;
> +};
> +
> +/* non-cached or cached region */
> +struct ocm_region {
> + phys_addr_t phys;
> + void __iomem *virt;
> +
> + int memtotal;
> + int memfree;
> +
> + rh_info_t *rh;
> + struct list_head list;
> +};
There's some interesting whitespace usage in these struct definitions.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc44x - how do i optimize driver for tlb hits
On Fri, Sep 24, 2010 at 02:43:52PM +1000, Benjamin Herrenschmidt wrote: >> The DMA is what I use in the "real world case" to get data into and out >> of these buffers. However, I can disable the DMA completely and do only >> the kmalloc. In this case I still see the same poor performance. My >> prefetching is part of my algo using the dcbt instructions. I know the >> instructions are effective b/c without them the algo is much less >> performant. So yes, my prefetches are explicit. > >Could be some "effect" of the cache structure, L2 cache, cache geometry >(number of ways etc...). You might be able to alleviate that by changing >the "stride" of your prefetch. > >Unfortunately, I'm not familiar enough with the 440 micro architecture >and its caches to be able to help you much here. Also, doesn't kmalloc have a limit to the size of the request it will let you allocate? I know in the distant past you could allocate 128K with kmalloc, and 2M with an explicit call to get_free_pages. Anything larger than that had to use vmalloc. The limit might indeed be higher now, but a 4MB kmalloc buffer sounds very large, given that it would be contiguous pages. Two of them even less so. >> Ok, I will give that a try ... in addition, is there an easy way to use >> any sort of gprof like tool to see the system performance? What about >> looking at the 44x performance counters in some meaningful way? All >> the experiments point to the fetching being slower in the full program >> as opposed to the algo in a testbench, so I want to determine what it is >> that could cause that. > >Does it have any useful performance counters ? I didn't think it did but >I may be mistaken. No, it doesn't. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] 476: Set CCR2[DSTI] to prevent isync from flushing shadow TLB
On Fri, Sep 24, 2010 at 01:01:36PM -0500, Dave Kleikamp wrote: >When the DSTI (Disable Shadow TLB Invalidate) bit is set in the CCR2 >register, the isync command does not flush the shadow TLB (iTLB & dTLB). > >However, since the shadow TLB does not contain context information, we >want the shadow TLB flushed in situations where we are switching context. >In those situations, we explicitly clear the DSTI bit before performing >isync, and set it again afterward. We also need to do the same when we >perform isync after explicitly flushing the TLB. > >Th setting of the DSTI bit is dependent on >CONFIG_PPC_47x_DISABLE_SHADOW_TLB_INVALIDATE. When we are confident that >the feature works as expected, the option can probably be removed. You're defaulting it to 'y' in the Kconfig. Technically someone could turn it off I guess, but practice mostly shows that nobody mucks with the defaults. Do you want it to default 'n' for now if you aren't confident in it just quite yet? (Linus also has some kind of gripe with new options being default 'y', but I don't recall all the details and I doubt he'd care about something in low-level PPC code.) josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of 4xx tree
Hi Ben, A few small updates for the next branch. A new board/SoC from AMCC, and some 476 changes from Shaggy. Please pull. josh The following changes since commit 9f5f9ffe50e90ed73040d2100db8bfc341cee352: powerpc/perf: Fix sampling enable for PPC970 (2010-09-23 17:03:56 +1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Dave Kleikamp (2): powerpc/476: Set CCR2[DSTI] to prevent isync from flushing shadow TLB powerpc/476: lazy flush_tlb_mm for nohash architectures Josh Boyer (1): powerpc/44x: Update ppc44x_defconfig Tirumala Marri (1): powerpc/44x: Add support for the AMCC APM821xx SoC arch/powerpc/boot/dts/bluestone.dts | 254 ++ arch/powerpc/configs/44x/bluestone_defconfig | 68 +++ arch/powerpc/configs/ppc44x_defconfig|9 +- arch/powerpc/include/asm/reg_booke.h |4 + arch/powerpc/kernel/cpu_setup_44x.S |1 + arch/powerpc/kernel/cputable.c | 15 ++ arch/powerpc/kernel/head_44x.S | 25 +++ arch/powerpc/mm/mmu_context_nohash.c | 154 ++-- arch/powerpc/mm/mmu_decl.h |8 + arch/powerpc/mm/tlb_nohash.c | 28 +++- arch/powerpc/mm/tlb_nohash_low.S | 14 ++- arch/powerpc/platforms/44x/Kconfig | 16 ++ arch/powerpc/platforms/44x/misc_44x.S| 26 +++ arch/powerpc/platforms/44x/ppc44x_simple.c |1 + 14 files changed, 602 insertions(+), 21 deletions(-) create mode 100644 arch/powerpc/boot/dts/bluestone.dts create mode 100644 arch/powerpc/configs/44x/bluestone_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie wrote: > From: Ian Munsie > > I haven't tested booting a little endian kernel on any of these targets, > but they all claim to be 44x so my little endian trampoline should work > on all of them, so wire it up on: > > bamboo > katmai > kilauea > rainer > sam440ep > sequoia > warp > yosemite > ebony > > Signed-off-by: Ian Munsie I see no reason to do this at all. If you haven't tested them and there is no demand, there's no reason to wire them up. Some might actively want to disallow LE mode anyway, like the Warp or Sam440EP. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
On Fri, Oct 1, 2010 at 5:18 AM, Kumar Gala wrote: > > On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote: > >> >> diff --git a/arch/powerpc/platforms/Kconfig.cputype >> b/arch/powerpc/platforms/Kconfig.cputype >> index d361f81..074ff12 100644 >> --- a/arch/powerpc/platforms/Kconfig.cputype >> +++ b/arch/powerpc/platforms/Kconfig.cputype >> @@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY >> bool >> >> endmenu >> + >> +config ARCH_SUPPORTS_LITTLE_ENDIAN >> + bool >> + >> +config CPU_LITTLE_ENDIAN >> + bool "Build little endian kernel" >> + depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL >> + default n >> + help >> + This option selects whether a big endian or little endian kernel will >> + be built. >> + >> + Note that if building a little endian kernel, CROSS_COMPILE must >> + point to a toolchain capable of targetting little endian powerpc, >> + while the toolchain specified by CROSS32_COMPILE must be capable of >> + targetting *BIG* endian PowerPC. >> -- >> 1.7.1 > > Shouldn't we have something that limits to the sub-arch'es that actually > support it? I doubt I'm ever going to make FSL-Book-e support LE. Yes, it should. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Introduce support for little endian PowerPC
On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala wrote: > > On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote: > >> Some PowerPC processors can be run in either big or little endian modes, some >> others can map selected pages of memory as little endian, which allows the >> same >> thing. Until now we have only supported the default big endian mode in Linux. >> This patch set introduces little endian support for the 44x family of PowerPC >> processors. > > From a community aspect is anyone actually going to use this? Is this going > to be the equivalent of voyager on x86? I've got nothing against some of the > endian clean ups this introduces. However the changes to misc_32.S are a bit > ugly from a readability point of view. Just seems like this is likely to > bit-rot pretty quickly. I'm with Kumar on this one. Why would we want to support this? I can't say I would be very willing to help anyone run in LE mode, let alone have it randomly selectable. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Introduce support for little endian PowerPC
On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie wrote: > This patch set in combination with a patched GCC, binutils, uClibc and > buildroot has allowed for a full proof of concept little endian environment on > a 440 Taishan board, which was able to successfully run busybox, OpenSSH and a > handful of other userspace programs without problems. Aside from my general "uh, why?" stance, I'm very very hesitant to integrate anything in the kernel that doesn'.t have released patches on the toolchain side. Also, which uClibc? The old and crusty uClibc that uses the horrible linuxthreads, or the somewhat less crusty that just switched to NPTL (which hasn't been verified on normal PowerPC that I recall). Why not use glibc... > This is not yet complete support for little endian PowerPC, some outstanding > issues that I am aware of are: > * We only support 32bit PowerPC for now (and indeed, only 44x) > * The vdso has not been fixed to be endian agnostic - any userspace program > accessing it will get an unexpected result. > * I have not touched PCI at all > * Remaining device tree accesses still need to be examined to ensure they are > correctly handling the endianess of the device tree. > * Any other driver that uses the device tree is likely be broken for the > same reason. > * I've included a patch for the alignment handler, however it is as yet > completely untested due to a property of the hardware I've been using for > testing. I'm not meeting to detract here, but the Kconfig should be dependent on && BROKEN until the above is fixed. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie wrote: > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index d361f81..074ff12 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY > bool > > endmenu > + > +config ARCH_SUPPORTS_LITTLE_ENDIAN > + bool > + > +config CPU_LITTLE_ENDIAN > + bool "Build little endian kernel" > + depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL > + default n > + help > + This option selects whether a big endian or little endian kernel > will > + be built. > + > + Note that if building a little endian kernel, CROSS_COMPILE must > + point to a toolchain capable of targetting little endian powerpc, > + while the toolchain specified by CROSS32_COMPILE must be capable of > + targetting *BIG* endian PowerPC. Have you tested this support with a userspace containing floating point instructions? I wonder if CONFIG_MATH_EMULATION is going to need work at all, and if the boards with an actual FPU (440EP, 440EPx, 460EX, etc) would have issues. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 1/1] powerpc: enable ARCH_DMA_ADDR_T_64BIT with ARCH_PHYS_ADDR_T_64BIT
On Fri, Oct 1, 2010 at 5:12 PM, wrote: > From: FUJITA Tomonori > > Signed-off-by: FUJITA Tomonori > Cc: Benjamin Herrenschmidt > Signed-off-by: Andrew Morton > --- > > arch/powerpc/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff -puN > arch/powerpc/Kconfig~powerpc-enable-arch_dma_addr_t_64bit-with-arch_phys_addr_t_64bit > arch/powerpc/Kconfig > --- > a/arch/powerpc/Kconfig~powerpc-enable-arch_dma_addr_t_64bit-with-arch_phys_addr_t_64bit > +++ a/arch/powerpc/Kconfig > @@ -16,6 +16,9 @@ config WORD_SIZE > config ARCH_PHYS_ADDR_T_64BIT > def_bool PPC64 || PHYS_64BIT > > +config ARCH_DMA_ADDR_T_64BIT > + def_bool ARCH_PHYS_ADDR_T_64BIT > + I seemed to have missed what this is about entirely. Is there some place I can look that describes what that is supposed to do? The PPC 4xx boards set PHYS_ADDR_T_64BIT because the MMU uses 36 bit addressing, but the CPU is only 32 bits. I want to make sure this DMA thing isn't going to cause problems. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
On Tue, Oct 5, 2010 at 9:28 PM, Ian Munsie wrote: > Excerpts from Josh Boyer's message of Fri Oct 01 21:27:37 +1000 2010: >> > From: Ian Munsie >> > >> > I haven't tested booting a little endian kernel on any of these targets, >> > but they all claim to be 44x so my little endian trampoline should work >> > on all of them, so wire it up on: >> > >> > bamboo >> > katmai >> > kilauea >> > rainer >> > sam440ep >> > sequoia >> > warp >> > yosemite >> > ebony >> >> I see no reason to do this at all. If you haven't tested them and >> there is no demand, there's no reason to wire them up. Some might >> actively want to disallow LE mode anyway, like the Warp or Sam440EP. > > I wasn't aware that the Warp and Sam440EP disallowed LE mode - I'll > definitely unwire them and move the ARCH_SUPPORTS_LITTLE_ENDIAN to just > the sub-arch's that support it. Well, Warp and Sam440EP are production boards for actual companies. The rest are all just eval boards. I don't know if the board maintainers care either way, I was just using them as examples of cases where someone might. > As for the other boards, I would like to wire them up if they are able > to support LE mode - If anyone has one handy I would love to hear if > they are able to begin booting a LE kernel with these patches, or when & > how they fail. I'd avoid anything with an FPU until that gets tested. So no bamboo, sequoia, canyonlands, etc. I noticed that canyonlands isn't even covered. I'm guessing that's because we don't need to create a wrapper for it because U-Boot does direct loading of vmlinux and the DTB itself. Has anyone done any work with getting U-Boot to work in LE mode or at least load LE vmlinux images? The majority of new boards are going to be using U-Boot and it's ability to load the DTB/FDT, so that would be something that needs addressing. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] Powerpc/4xx: Add suspend and idle support
On Thu, Oct 07, 2010 at 12:07:16PM -0700, Victor Gallardo wrote:
>Add suspend/resume support for all 4xx compatible CPUs.
>See /sys/power/state for available power states configured in.
>
>Add two different idle states (idle-wait and idle-doze)
>controlled via sysfs. Default is idle-wait.
> cat /sys/devices/system/cpu/cpu0/idle
> [wait] doze
>
>To save additional power, use idle-doze.
> echo doze > /sys/devices/system/cpu/cpu0/idle
> cat /sys/devices/system/cpu/cpu0/idle
> wait [doze]
>
>Signed-off-by: Victor Gallardo
>---
> Documentation/powerpc/dts-bindings/4xx/cpm.txt | 43 +++
> arch/powerpc/Kconfig | 13 +-
> arch/powerpc/platforms/44x/Makefile|5 +-
> arch/powerpc/sysdev/Makefile |1 +
> arch/powerpc/sysdev/ppc4xx_cpm.c | 339
> 5 files changed, 397 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/4xx/cpm.txt
> create mode 100644 arch/powerpc/sysdev/ppc4xx_cpm.c
>
>diff --git a/Documentation/powerpc/dts-bindings/4xx/cpm.txt
>b/Documentation/powerpc/dts-bindings/4xx/cpm.txt
>new file mode 100644
>index 000..9635df8
>--- /dev/null
>+++ b/Documentation/powerpc/dts-bindings/4xx/cpm.txt
>@@ -0,0 +1,43 @@
>+PPC4xx Clock Power Management (CPM) node
>+
>+Required properties:
>+ - compatible: compatible list, currently only "ibm,cpm"
>+ - dcr-access-method : "native"
>+ - dcr-reg : < DCR register range >
>+
>+Optional properties:
>+ - er-offset : All 4xx SoCs with a CPM controller have
>+one of two different order for the CPM
>+registers. Some have the CPM registers
>+in the following order (ER,FR,SR). The
>+others have them in the following order
>+(SR,ER,FR). For the second case set
>+er-offset = <1>.
>+ - unused-units : specifier consist of one cell. For each
>+bit in the cell, the corresponding bit
>+in CPM will be set to turn off unused
>+devices.
>+ - idle-doze : specifier consist of one cell. For each
>+bit in the cell, the corresponding bit
>+in CPM will be set to turn off unused
>+devices. This is usually just CPM[CPU].
>+ - standby : specifier consist of one cell. For each
>+bit in the cell, the corresponding bit
>+in CPM will be set on standby and
>+restored on resume.
>+ - suspend : specifier consist of one cell. For each
>+bit in the cell, the corresponding bit
>+in CPM will be set on suspend (mem) and
>+restored on resume.
So the difference, from what I can tell, between standby and suspend is
really only what devices are turned off. I don't see any code to put
the DRAM into self-refresh mode, etc. If that is the case, perhaps we
could add a bit of description as to the different kinds of devices that
may be disabled in one mode but not the other.
>+
>+Example:
>+CPM0: cpm {
>+compatible = "ibm,cpm";
>+dcr-access-method = "native";
>+dcr-reg = <0x160 0x003>;
>+ er-offset = <0>;
>+unused-units = <0x0100>;
>+idle-doze = <0x0200>;
>+standby = <0xfeff>;
>+standby = <0xfeff791d>;
One of these two should be illustrating suspend.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] Powerpc/4xx: Add suspend and idle support
On Thu, Oct 07, 2010 at 12:07:16PM -0700, Victor Gallardo wrote:
I hit send too soon on my earlier response. My apologies.
>--- /dev/null
>+++ b/arch/powerpc/sysdev/ppc4xx_cpm.c
>@@ -0,0 +1,339 @@
>+/*
>+ * PowerPC 4xx Clock and Power Management
>+ *
>+ * Copyright (C) 2010, Applied Micro Circuits Corporation
>+ * Victor Gallardo (vgalla...@apm.com)
>+ *
>+ * Based on arch/powerpc/platforms/44x/idle.c:
>+ * Jerone Young
>+ * Copyright 2008 IBM Corp.
>+ *
>+ * Based on arch/powerpc/sysdev/fsl_pmc.c:
>+ * Anton Vorontsov
>+ * Copyright 2009 MontaVista Software, Inc.
>+ *
>+ * See file CREDITS for list of people who contributed to this
>+ * project.
>+ *
>+ * 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.
>+ *
>+ * This program is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>+ * GNU General Public License for more details.
>+ *
>+ * You should have received a copy of the GNU General Public License
>+ * along with this program; if not, write to the Free Software
>+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>+ * MA 02111-1307 USA
>+ */
>+
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+#define CPM_ER0
>+#define CPM_FR1
>+#define CPM_SR2
>+
>+#define CPM_IDLE_WAIT 0
>+#define CPM_IDLE_DOZE 1
>+
>+struct cpm {
>+ dcr_host_t dcr_host;
>+ unsigned intdcr_offset[3];
>+ unsigned intpowersave_off;
>+ unsigned intunused;
>+ unsigned intidle_doze;
>+ unsigned intstandby;
>+ unsigned intsuspend;
>+};
>+
>+static struct cpm cpm;
>+
>+struct cpm_idle_mode {
>+ unsigned int enabled;
>+ const char *name;
>+};
>+
>+static struct cpm_idle_mode idle_mode[] = {
>+ [CPM_IDLE_WAIT] = { 1, "wait" }, /* default */
>+ [CPM_IDLE_DOZE] = { 0, "doze" },
>+};
>+
>+static void cpm_set(unsigned int cpm_reg, unsigned int mask)
>+{
>+ unsigned int value;
>+
>+ value = dcr_read(cpm.dcr_host, cpm.dcr_offset[cpm_reg]);
>+ value |= mask;
>+ dcr_write(cpm.dcr_host, cpm.dcr_offset[cpm_reg], value);
>+}
This doesn't seem to do any sort of verification that the class 2 and
class 3 devices actually got disabled. Or at least I don't see where we
verify anything in the SR.
Maybe in practice it doesn't matter, but we should add a comment that say
we just expect them to eventually go off when they can.
>+
>+static void cpm_idle_wait(void)
>+{
>+ unsigned long msr_save;
>+
>+ /* save off initial state */
>+ msr_save = mfmsr();
>+ /* sync required when CPM0_ER[CPU] is set */
>+ mb();
>+ /* set wait state MSR */
>+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
>+ isync();
>+ /* return to initial state */
>+ mtmsr(msr_save);
>+ isync();
>+}
>+
>+static void cpm_idle_sleep(unsigned int mask)
>+{
>+ unsigned int er_save;
>+
>+ /* update CPM_ER state */
>+ er_save = dcr_read(cpm.dcr_host, cpm.dcr_offset[CPM_ER]);
>+ dcr_write(cpm.dcr_host, cpm.dcr_offset[CPM_ER],
>+er_save | mask);
>+
>+ /* go to wait state */
>+ cpm_idle_wait();
>+
>+ /* restore CPM_ER state */
>+ dcr_write(cpm.dcr_host, cpm.dcr_offset[CPM_ER], er_save);
>+}
For my clarification, the CPU is a class 2 device and we expect that the
logic between the CPU and the CPM allows us to do the write to make it
sleep, but not actually sleep until we set the idle state?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] v2 476: Set CCR2[DSTI] to prevent isync from flushing shadow TLB
On Tue, Oct 12, 2010 at 02:40:13PM -0500, Dave Kleikamp wrote: >Josh, >Please pull this patch. I just found a bone-headed mistake that makes >the whole patch a no-op. I'll need to fix it and put it through a bit >of testing before I can re-submit it. OK. I should have looked more closely myself. I did think it odd that it was changing head_44x.S but didn't follow up. Ben, since you haven't pulled my -next branch yet, don't ;). I'll fix this up in my tree and resend a request tomorrow. josh > >The other patch in this series should be okay. > >Thanks, >Shaggy > >On Mon, 2010-09-27 at 16:56 -0500, Dave Kleikamp wrote: >> When the DSTI (Disable Shadow TLB Invalidate) bit is set in the CCR2 >> register, the isync command does not flush the shadow TLB (iTLB & dTLB). >> >> However, since the shadow TLB does not contain context information, we >> want the shadow TLB flushed in situations where we are switching context. >> In those situations, we explicitly clear the DSTI bit before performing >> isync, and set it again afterward. We also need to do the same when we >> perform isync after explicitly flushing the TLB. >> >> Signed-off-by: Dave Kleikamp >> --- >> arch/powerpc/include/asm/reg_booke.h |4 >> arch/powerpc/kernel/head_44x.S| 25 + >> arch/powerpc/mm/tlb_nohash_low.S | 14 +- >> arch/powerpc/platforms/44x/misc_44x.S | 26 ++ >> 4 files changed, 68 insertions(+), 1 deletions(-) >> > > --- snip --- > >> --- a/arch/powerpc/kernel/head_44x.S >> +++ b/arch/powerpc/kernel/head_44x.S > >Not only is this in the wrong place (non-47x initialization) but ... > >> @@ -861,6 +877,15 @@ skpinv: addir4,r4,1 /* >> Increment */ >> isync >> #endif /* CONFIG_PPC_EARLY_DEBUG_44x */ >> >> +BEGIN_MMU_FTR_SECTION >> +mfspr r3,SPRN_CCR2_476 >> +/* With CCR2(DSTI) set, isync does not invalidate the shadow TLB */ >> +orisr3,r3,ccr2_476_d...@h >> +rlwinm r3,r3,0,~CCR2_476_DSTI > >^^^ This instruction doesn't belong at all. It clears the bit right >after setting it. This one was just introduced removing the config >option, but it was in the wrong place all along. > >> +mtspr SPRN_CCR2_476,r3 >> +isync >> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) >> + >> /* Establish the interrupt vector offsets */ >> SET_IVOR(0, CriticalInput); >> SET_IVOR(1, MachineCheck); > >I wasn't diligent enough checking a year-old patch that I got back to >work on. The code is very similar in two places and the patch applied >to the wrong section. > >Thanks, >Shaggy >-- >Dave Kleikamp >IBM Linux Technology Center > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Tue, Sep 28, 2010 at 09:09:41AM -0400, Josh Boyer wrote: >Hi Ben, > >A few small updates for the next branch. A new board/SoC from AMCC, and >some 476 changes from Shaggy. Please pull. OK, below is a fixed up tree that drops the patch Shaggy said was broken, and rebases on top of your new -next branch. Please pull. josh The following changes since commit 4108d9ba9091c55cfb968d42dd7dcae9a098b876: powerpc/Makefiles: Change to new flag variables (2010-10-13 16:19:22 +1100) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Dave Kleikamp (1): powerpc/476: lazy flush_tlb_mm for nohash architectures Josh Boyer (1): powerpc/44x: Update ppc44x_defconfig Tirumala Marri (1): powerpc/44x: Add support for the AMCC APM821xx SoC arch/powerpc/boot/dts/bluestone.dts | 254 ++ arch/powerpc/configs/44x/bluestone_defconfig | 68 +++ arch/powerpc/configs/ppc44x_defconfig|9 +- arch/powerpc/kernel/cpu_setup_44x.S |1 + arch/powerpc/kernel/cputable.c | 15 ++ arch/powerpc/mm/mmu_context_nohash.c | 154 ++-- arch/powerpc/mm/mmu_decl.h |8 + arch/powerpc/mm/tlb_nohash.c | 28 +++- arch/powerpc/platforms/44x/Kconfig | 16 ++ arch/powerpc/platforms/44x/ppc44x_simple.c |1 + 10 files changed, 534 insertions(+), 20 deletions(-) create mode 100644 arch/powerpc/boot/dts/bluestone.dts create mode 100644 arch/powerpc/configs/44x/bluestone_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Thu, Oct 14, 2010 at 11:56:15AM +1100, Benjamin Herrenschmidt wrote: >On Wed, 2010-10-13 at 09:16 -0400, Josh Boyer wrote: >> On Tue, Sep 28, 2010 at 09:09:41AM -0400, Josh Boyer wrote: >> >Hi Ben, >> > >> >A few small updates for the next branch. A new board/SoC from AMCC, and >> >some 476 changes from Shaggy. Please pull. >> >> OK, below is a fixed up tree that drops the patch Shaggy said was >> broken, and rebases on top of your new -next branch. Please pull. > >please, rebase again without Shaggy's lazy flush patch. I'll handle that >one separately, I think it needs a little bit more massaging. The following changes since commit 4108d9ba9091c55cfb968d42dd7dcae9a098b876: powerpc/Makefiles: Change to new flag variables (2010-10-13 16:19:22 +1100) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Josh Boyer (1): powerpc/44x: Update ppc44x_defconfig Tirumala Marri (1): powerpc/44x: Add support for the AMCC APM821xx SoC arch/powerpc/boot/dts/bluestone.dts | 254 ++ arch/powerpc/configs/44x/bluestone_defconfig | 68 +++ arch/powerpc/configs/ppc44x_defconfig|9 +- arch/powerpc/kernel/cpu_setup_44x.S |1 + arch/powerpc/kernel/cputable.c | 15 ++ arch/powerpc/platforms/44x/Kconfig | 16 ++ arch/powerpc/platforms/44x/ppc44x_simple.c |1 + 7 files changed, 360 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/bluestone.dts create mode 100644 arch/powerpc/configs/44x/bluestone_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: eabi supported
On Sun, Oct 31, 2010 at 07:54:48PM +0100, Oliver Kowalke wrote: >Hi, > >could you tell me which Linux distribution does support powerpc with >eabi (embedded abi)? > >I tried 'T2 Project' but it doesn't offer ABI selection in its config >script. eabi isn't really used all that much on powerpc. I don't know of a community distro that supports powerpc in general, much less with eabi. You might be able to get it from one of the embedded linux vendors, but you'd have to contact them. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: All Applied micro boards are failing with current mainline kernel
On Fri, Oct 29, 2010 at 11:06 PM, Rupjyoti Sarmah wrote: > Hi , > > APM boards Canyonlands/Kilauea/Glacier/Katmai/Sequoia are all failing > during booting. What kernel version? What config? Have you tried a git bisect to see when it broke? Etc, etc. Also, CC'ing linuxppc-dev would have been a good idea. Not many on lkml are even going to know what you're talking about with such sparse details. josh > > Call trace is same for all > > > Call Trace: > > [df835d70] [c02d27cc] emac_probe+0xf28/0x12a8 (unreliable) > > [df835e50] [c023c7cc] platform_driver_probe_shim+0x40/0x54 > > [df835e60] [c01bf354] platform_drv_probe+0x20/0x30 > > [df835e70] [c01bde68] driver_probe_device+0x148/0x1ac > > [df835e90] [c01be17c] __driver_attach+0xa4/0xa8 > > [df835eb0] [c01bcfa4] bus_for_each_dev+0x60/0x9c > > [df835ee0] [c01bdbbc] driver_attach+0x24/0x34 > > [df835ef0] [c01bd94c] bus_add_driver+0x1b8/0x274 > > [df835f20] [c01be3d8] driver_register+0x6c/0x160 > > [df835f40] [c01bf6c4] platform_driver_register+0x68/0x78 > > [df835f50] [c023c998] of_register_platform_driver+0xa8/0xc4 > > [df835f60] [c0393e88] emac_init+0x1ac/0x1dc > > [df835fa0] [c0001574] do_one_initcall+0x160/0x1a8 > > [df835fd0] [c037a1e8] kernel_init+0xcc/0x174 > > [df835ff0] [c000c5b0] kernel_thread+0x4c/0x68 > > Instruction dump: > > 419e016c 2f87 419e0164 38130774 901a00d0 381306b0 901a00d4 7f43d378 > > 4bf91d89 817a01a0 3921 380b0008 <7d400028> 7d4a4b78 7d40012d 40a2fff4 > > ---[ end trace dac0cf4779f83901 ]--- > > > Regards, > Rup > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: All Applied micro boards are failing with current mainline kernel
On Mon, Nov 1, 2010 at 9:22 AM, Josh Boyer wrote: > On Fri, Oct 29, 2010 at 11:06 PM, Rupjyoti Sarmah wrote: >> Hi , >> >> APM boards Canyonlands/Kilauea/Glacier/Katmai/Sequoia are all failing >> during booting. > > What kernel version? What config? Have you tried a git bisect to see > when it broke? Etc, etc. >> >> Call trace is same for all >> >> >> Call Trace: >> >> [df835d70] [c02d27cc] emac_probe+0xf28/0x12a8 (unreliable) >> >> [df835e50] [c023c7cc] platform_driver_probe_shim+0x40/0x54 >> >> [df835e60] [c01bf354] platform_drv_probe+0x20/0x30 >> >> [df835e70] [c01bde68] driver_probe_device+0x148/0x1ac >> >> [df835e90] [c01be17c] __driver_attach+0xa4/0xa8 >> >> [df835eb0] [c01bcfa4] bus_for_each_dev+0x60/0x9c >> >> [df835ee0] [c01bdbbc] driver_attach+0x24/0x34 >> >> [df835ef0] [c01bd94c] bus_add_driver+0x1b8/0x274 >> >> [df835f20] [c01be3d8] driver_register+0x6c/0x160 >> >> [df835f40] [c01bf6c4] platform_driver_register+0x68/0x78 >> >> [df835f50] [c023c998] of_register_platform_driver+0xa8/0xc4 >> >> [df835f60] [c0393e88] emac_init+0x1ac/0x1dc >> >> [df835fa0] [c0001574] do_one_initcall+0x160/0x1a8 >> >> [df835fd0] [c037a1e8] kernel_init+0xcc/0x174 >> >> [df835ff0] [c000c5b0] kernel_thread+0x4c/0x68 >> >> Instruction dump: >> >> 419e016c 2f87 419e0164 38130774 901a00d0 381306b0 901a00d4 7f43d378 >> >> 4bf91d89 817a01a0 3921 380b0008 <7d400028> 7d4a4b78 7d40012d 40a2fff4 >> >> ---[ end trace dac0cf4779f83901 ]--- A git bisect between 2.6.36 (working) and Linus tip (traceback) points to: e6484930d7c73d324bccda7d43d131088da697b9 net: allocate tx queues in register_netdevice as causing this. I'm not entirely sure why yet, but the commit message seems slightly off to me. It claims to make TX queue allocation identical to RX, but from what I can tell, most of the RX queue logic is hidden behind CONFIG_RPS, which is not set in my config at all (and can't be due to a dep on CONFIG_SMP). This change doesn't guard anything behind that. A few hints would be appreciated. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: All Applied micro boards are failing with current mainline kernel
On Mon, Nov 1, 2010 at 11:36 AM, Stephen Rothwell wrote: > Hi Josh, > > On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer wrote: >> >> A few hints would be appreciated. > > Remove the call to netif_stop_queue() from emac_probe(). Apparently, > calling this before register_netdev() is now wrong (maybe always was). Yeah, I just discovered that myself. I'm wondering 1) why we do that in that function? 2) If it needs to be removed entirely, or moved to after the register_netdev call 3) If the call to netif_carrier_off also needs similar attention. I can whip up a patch to remove those calls or move them after the register, but I don't want to do that without knowing which one is "right". josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: All Applied micro boards are failing with current mainline kernel
On Mon, Nov 1, 2010 at 11:51 AM, David Miller wrote: >> I can whip up a patch to remove those calls or move them after the >> register, but I don't want to do that without knowing which one is >> "right". > > I've already taken care of this. Thanks! josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATHC v1] PPC4xx: Adding PCI(E) MSI support
On Wed, Nov 03, 2010 at 11:11:33PM +1100, Michael Ellerman wrote: >> +struct device_node *msi_dev = NULL; >> +const u32 *count; >> + >> +msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi"); >> +if (msi_dev) >> +return -ENODEV; >> + You also leak a reference to the node here, as there is never a call to of_node_put. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc44x:PHY fixup for USB on canyonlands board
On Wed, Nov 10, 2010 at 05:07:15PM +0530, Rupjyoti Sarmah wrote:
>This fix is a reset for USB PHY that requires some amount of time for power to
>be stable on Canyonlands.
>
>Signed-off-by: Rupjyoti Sarmah
>---
> arch/powerpc/boot/dts/canyonlands.dts | 11
> arch/powerpc/platforms/44x/44x.h |5 ++
> arch/powerpc/platforms/44x/Kconfig|7 ++
> arch/powerpc/platforms/44x/Makefile |1 +
> arch/powerpc/platforms/44x/ppc44x_fixup.c | 90 +
> 5 files changed, 114 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/44x/ppc44x_fixup.c
Is this just for canyonlands? If so, it's probably better off in a
caynonlands specific file, or a function that gets called in the common
platform file if the model matches canyonlands. It seems a bit overkill
to introduce an entire new file and Kconfig option for this.
>
>diff --git a/arch/powerpc/boot/dts/canyonlands.dts
>b/arch/powerpc/boot/dts/canyonlands.dts
>index a303703..d6e9ba2 100644
>--- a/arch/powerpc/boot/dts/canyonlands.dts
>+++ b/arch/powerpc/boot/dts/canyonlands.dts
>@@ -171,6 +171,11 @@
> 0x5 0x4>; /* AHBDMA */
> };
>
>+ CPLD: c...@e100 {
>+ compatible = "apm, ppc460ex-bcsr";
>+ reg = <4 0xe100 0x9>;
>+ };
Normally we don't leave a space in compatible properties.
>+
> POB0: opb {
> compatible = "ibm,opb-460ex", "ibm,opb";
> #address-cells = <1>;
>@@ -320,6 +325,12 @@
> interrupts = <0x3 0x4>;
> };
>
>+ GPIO0: g...@ef600b00 {
>+ compatible = "apm,ppc44x-gpio-base";
>+ reg = <0xef600b00 0x0048>;
>+ gpio-controller;
>+ };
We already have "ibm,ppc4xx-gpio" as an established compatible field for
4xx GPIO. As far as I know, this is not a different kind of GPIO
controller than what is found on the other boards, so we should stick
with the existing property.
>+
> ZMII0: emac-z...@ef600d00 {
> compatible = "ibm,zmii-460ex", "ibm,zmii";
> reg = <0xef600d00 0x000c>;
>diff --git a/arch/powerpc/platforms/44x/44x.h
>b/arch/powerpc/platforms/44x/44x.h
>index dbc4d2b..bc2ab7a 100644
>--- a/arch/powerpc/platforms/44x/44x.h
>+++ b/arch/powerpc/platforms/44x/44x.h
>@@ -4,4 +4,9 @@
> extern u8 as1_readb(volatile u8 __iomem *addr);
> extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
>
>+#define BCSR_USB_EN 0x11
>+#define GPIO0_OSRH0xC
>+#define GPIO0_TSRH0x14
>+#define GPIO0_ISR1H 0x34
>+
> #endif /* __POWERPC_PLATFORMS_44X_44X_H */
>diff --git a/arch/powerpc/platforms/44x/Kconfig
>b/arch/powerpc/platforms/44x/Kconfig
>index 0f979c5..9ca4aaa 100644
>--- a/arch/powerpc/platforms/44x/Kconfig
>+++ b/arch/powerpc/platforms/44x/Kconfig
>@@ -117,12 +117,19 @@ config CANYONLANDS
> default n
> select PPC44x_SIMPLE
> select 460EX
>+ select 44X_FIXUP
> select PCI
> select PPC4xx_PCI_EXPRESS
> select IBM_NEW_EMAC_RGMII
> select IBM_NEW_EMAC_ZMII
> help
> This option enables support for the AMCC PPC460EX evaluation board.
>+config 44X_FIXUP
>+ bool "4xx_fixup"
>+ depends on 44x
>+ default n
>+ help
>+This option enables supporting APM PPC4XX based evaluation board
>fixups.
>
> config GLACIER
> bool "Glacier"
>diff --git a/arch/powerpc/platforms/44x/Makefile
>b/arch/powerpc/platforms/44x/Makefile
>index 82ff326..d4bfb97 100644
>--- a/arch/powerpc/platforms/44x/Makefile
>+++ b/arch/powerpc/platforms/44x/Makefile
>@@ -1,6 +1,7 @@
> obj-$(CONFIG_44x) := misc_44x.o idle.o
> obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
> obj-$(CONFIG_EBONY) += ebony.o
>+obj-$(CONFIG_44X_FIXUP) += ppc44x_fixup.o
> obj-$(CONFIG_SAM440EP)+= sam440ep.o
> obj-$(CONFIG_WARP)+= warp.o
> obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
>diff --git a/arch/powerpc/platforms/44x/ppc44x_fixup.c
>b/arch/powerpc/platforms/44x/ppc44x_fixup.c
>new file mode 100644
>index 000..4e254eb
>--- /dev/null
>+++ b/arch/powerpc/platforms/44x/ppc44x_fixup.c
>@@ -0,0 +1,90 @@
>+/*
>+ * This contain fixup code for Applied Micro ppc44x series of processors.
>+ *
>+ * Copyright (c) 2010, Applied Micro Circuits Corporation
>+ * Author: Rupjyoti Sarmah
>+ *
>+ * 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.
>+ *
>+ * This program is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * ME
Re: [PATCH] Fix float to unsigned conversion failure with SPE enabled
On Sat, Nov 13, 2010 at 11:11 PM, Hai Shan wrote:
> Fixed the failure on converting minus float to unsigned int with SPE enabled
>
> Signed-off-by: Hai Shan
You should make sure to send PowerPC patches to linuxppc-dev.
josh
> ---
> arch/powerpc/math-emu/math_efp.c | 17 +
> 1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/math-emu/math_efp.c
> b/arch/powerpc/math-emu/math_efp.c
> index 41f4ef3..338a128 100644
> --- a/arch/powerpc/math-emu/math_efp.c
> +++ b/arch/powerpc/math-emu/math_efp.c
> @@ -320,7 +320,9 @@ int do_spe_mathemu(struct pt_regs *regs)
> } else {
> _FP_ROUND_ZERO(1, SB);
> }
> - FP_TO_INT_S(vc.wp[1], SB, 32, ((func & 0x3) != 0));
> + /* SB_s: convert from minus float to unsigned int */
> + FP_TO_INT_S(vc.wp[1], SB, 32,
> + ((func & 0x3) != 0) || SB_s);
> goto update_regs;
>
> default:
> @@ -458,7 +460,11 @@ cmp_s:
> } else {
> _FP_ROUND_ZERO(2, DB);
> }
> - FP_TO_INT_D(vc.wp[1], DB, 32, ((func & 0x3) != 0));
> + /* DB_s: convert from minus long double to
> + * unsigned long long
> + */
> + FP_TO_INT_D(vc.wp[1], DB, 32,
> + ((func & 0x3) != 0) || DB_s);
> goto update_regs;
>
> default:
> @@ -589,8 +595,11 @@ cmp_d:
> _FP_ROUND_ZERO(1, SB0);
> _FP_ROUND_ZERO(1, SB1);
> }
> - FP_TO_INT_S(vc.wp[0], SB0, 32, ((func & 0x3) != 0));
> - FP_TO_INT_S(vc.wp[1], SB1, 32, ((func & 0x3) != 0));
> + /* SB*_s: convert from minus float to unsigned int */
> + FP_TO_INT_S(vc.wp[0], SB0, 32,
> + ((func & 0x3) != 0) || SB0_s);
> + FP_TO_INT_S(vc.wp[1], SB1, 32,
> + ((func & 0x3) != 0) || SB1_s);
> goto update_regs;
>
> default:
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Update a comment
On Mon, Nov 15, 2010 at 3:21 AM, Alessio Igor Bogani wrote: > The commit 5e3d20a remove bkl from startup code so setup_arch() it isn't > called > with bkl held anymore. Update the comment on top of that function. > > This work was supported by a hardware donation from the CE Linux Forum. You should make sure to send powerpc patches to linuxppc-dev. > > Signed-off-by: Alessio Igor Bogani > --- > arch/powerpc/kernel/setup_64.c | 5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c > index 2a178b0..71f44e5 100644 > --- a/arch/powerpc/kernel/setup_64.c > +++ b/arch/powerpc/kernel/setup_64.c > @@ -497,9 +497,8 @@ static void __init emergency_stack_init(void) > } > > /* > - * Called into from start_kernel, after lock_kernel has been called. > - * Initializes bootmem, which is unsed to manage page allocation until > - * mem_init is called. > + * Called into from start_kernel this initializes bootmem, which is unsed > + * to manage page allocation until mem_init is called. You might as well fix the typo while you're there. unsed->used josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Sun, Nov 21, 2010 at 6:05 PM, Michael Ellerman wrote: > On Fri, 2010-11-19 at 17:02 +1100, Michael Neuling wrote: >> > On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote: >> > > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman >> > > > > au> wrote: >> > > > >> > > > I vote for: >> > > >=20 >> > > > -> Exception: 401 (Instruction Access) at f7937794 >> > >=20 >> > > Or: >> > >=20 >> > > =E2=98=9B Exception: 401 (Instruction Access) at f7937794 >> > >> > Let's get serious, it's _really_ like a phone call: >> > >> > =E2=98=8E Exception: 401 (Instruction Access) at f7937794 >> >> We need a dedicated NACK char! > > ␕! Surely it would be: ☣ josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
