Re: [PATCH 2/3] powerpc: Remove -fno-omit-frame-pointer workarounds
Ben, Can you ACK or take this patch too. Thanks, -- Steve On Fri, 2009-03-20 at 19:44 +0300, Anton Vorontsov wrote: > The workarounds aren't needed any longer since the top level Makefile > doesn't pass -fno-omit-frame-pointer cflag for PowerPC. > > Signed-off-by: Anton Vorontsov > --- > arch/powerpc/Makefile|5 - > arch/powerpc/kernel/Makefile | 12 ++-- > arch/powerpc/platforms/powermac/Makefile |2 +- > lib/Kconfig.debug|6 +++--- > 4 files changed, 10 insertions(+), 15 deletions(-) > > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile > index 551fc58..1dd7748 100644 > --- a/arch/powerpc/Makefile > +++ b/arch/powerpc/Makefile > @@ -120,11 +120,6 @@ ifeq ($(CONFIG_6xx),y) > KBUILD_CFLAGS+= -mcpu=powerpc > endif > > -# Work around a gcc code-gen bug with -fno-omit-frame-pointer. > -ifeq ($(CONFIG_FUNCTION_TRACER),y) > -KBUILD_CFLAGS+= -mno-sched-epilog > -endif > - > cpu-as-$(CONFIG_4xx) += -Wa,-m405 > cpu-as-$(CONFIG_6xx) += -Wa,-maltivec > cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec > diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile > index dfec3d2..f86caeb 100644 > --- a/arch/powerpc/kernel/Makefile > +++ b/arch/powerpc/kernel/Makefile > @@ -14,14 +14,14 @@ endif > > ifdef CONFIG_FUNCTION_TRACER > # Do not trace early boot code > -CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog > -CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog > -CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog > -CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog > +CFLAGS_REMOVE_cputable.o = -pg > +CFLAGS_REMOVE_prom_init.o = -pg > +CFLAGS_REMOVE_btext.o = -pg > +CFLAGS_REMOVE_prom.o = -pg > # do not trace tracer code > -CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog > +CFLAGS_REMOVE_ftrace.o = -pg > # timers used by tracing > -CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog > +CFLAGS_REMOVE_time.o = -pg > endif > > obj-y:= cputable.o ptrace.o syscalls.o \ > diff --git a/arch/powerpc/platforms/powermac/Makefile > b/arch/powerpc/platforms/powermac/Makefile > index 50f1693..0eb8781 100644 > --- a/arch/powerpc/platforms/powermac/Makefile > +++ b/arch/powerpc/platforms/powermac/Makefile > @@ -2,7 +2,7 @@ CFLAGS_bootx_init.o += -fPIC > > ifdef CONFIG_FUNCTION_TRACER > # Do not trace early boot code > -CFLAGS_REMOVE_bootx_init.o = -pg -mno-sched-epilog > +CFLAGS_REMOVE_bootx_init.o = -pg > endif > > obj-y+= pic.o setup.o time.o feature.o pci.o > \ > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index fc8cd1f..713620d 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -493,7 +493,7 @@ config LOCKDEP > bool > depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT > && LOCKDEP_SUPPORT > select STACKTRACE > - select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND > + select FRAME_POINTER if !MIPS && !ARM_UNWIND > select KALLSYMS > select KALLSYMS_ALL > > @@ -866,13 +866,13 @@ config FAULT_INJECTION_STACKTRACE_FILTER > depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT > depends on !X86_64 > select STACKTRACE > - select FRAME_POINTER if !PPC > + select FRAME_POINTER > help > Provide stacktrace filter for fault-injection capabilities > > config LATENCYTOP > bool "Latency measuring infrastructure" > - select FRAME_POINTER if !MIPS && !PPC > + select FRAME_POINTER if !MIPS > select KALLSYMS > select KALLSYMS_ALL > select STACKTRACE ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
Ben, Can you ACK this patch? Or even take it in your tree? Thanks, -- Steve On Fri, 2009-03-20 at 19:44 +0300, Anton Vorontsov wrote: > This patch introduces ARCH_HAS_NORMAL_FRAME_POINTERS Kconfig symbol. > When defined, the top level Makefile won't add -fno-omit-frame-pointer > cflag (the flag is useless in PowerPC kernels, and also makes gcc > generate wrong code). > > Also move ARCH_WANT_FRAME_POINTERS's help text. > > Signed-off-by: Anton Vorontsov > --- > Makefile |7 +-- > arch/powerpc/Kconfig |1 + > lib/Kconfig.debug| 16 ++-- > 3 files changed, 16 insertions(+), 8 deletions(-) > > diff --git a/Makefile b/Makefile > index 46c04c5..bf41b05 100644 > --- a/Makefile > +++ b/Makefile > @@ -538,9 +538,12 @@ KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) > endif > > ifdef CONFIG_FRAME_POINTER > -KBUILD_CFLAGS+= -fno-omit-frame-pointer -fno-optimize-sibling-calls > + KBUILD_CFLAGS += -fno-optimize-sibling-calls > + ifndef ARCH_HAS_NORMAL_FRAME_POINTERS > +KBUILD_CFLAGS+= -fno-omit-frame-pointer > + endif > else > -KBUILD_CFLAGS+= -fomit-frame-pointer > + KBUILD_CFLAGS += -fomit-frame-pointer > endif > > ifdef CONFIG_DEBUG_INFO > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 97f9a64..4587e66 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -113,6 +113,7 @@ config PPC > select HAVE_FUNCTION_TRACER > select HAVE_FUNCTION_GRAPH_TRACER > select ARCH_WANT_OPTIONAL_GPIOLIB > + select ARCH_HAS_NORMAL_FRAME_POINTERS > select HAVE_IDE > select HAVE_IOREMAP_PROT > select HAVE_EFFICIENT_UNALIGNED_ACCESS > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 4b63b6b..fc8cd1f 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -661,20 +661,24 @@ config DEBUG_NOTIFIERS > This is a relatively cheap check but if you care about maximum > performance, say N. > > -# > -# Select this config option from the architecture Kconfig, if it > -# it is preferred to always offer frame pointers as a config > -# option on the architecture (regardless of KERNEL_DEBUG): > -# > config ARCH_WANT_FRAME_POINTERS > bool > help > + Select this config option from the architecture Kconfig, if it > + it is preferred to always offer frame pointers as a config > + option on the architecture (regardless of KERNEL_DEBUG). > + > +config ARCH_HAS_NORMAL_FRAME_POINTERS > + bool > + help > + Architectures should select this symbol if their ABI implies > + having a frame pointer. > > config FRAME_POINTER > bool "Compile the kernel with frame pointers" > depends on DEBUG_KERNEL && \ > (CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \ > - AVR32 || SUPERH || BLACKFIN || MN10300) || \ > + AVR32 || SUPERH || BLACKFIN || MN10300 || PPC) || \ > ARCH_WANT_FRAME_POINTERS > default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS > help ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
Ug, My Red Hat email was not being updated. I totally missed this
thread.
On Fri, 2009-03-20 at 20:57 +0100, Ingo Molnar wrote:
> * Anton Vorontsov wrote:
>
> > On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > >
> > > * Anton Vorontsov wrote:
> > >
> > > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> > > > up menu"), despite the "clean up" in its purpose, introduced
> > > > behavioural change for Kconfig symbols: we no longer able to
> > > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> > > > yet implemented).
> > >
> > > Could you please solve this by implementing proper
> > > irqflag-tracing support? It's been available upstream for almost
> > > three years. It's needed for lockdep support as well, etc.
> >
> > Breaking things via clean up patches is an interesting method of
> > encouraging something to implement. ;-)
> >
> > Surely I'll look into implementing irqflags tracing, but
> > considering that no one ever needed this for almost three years,
> > [...]
>
> Weird, there's no lockdep support?
I've discussed this with several people before. lockdep exists for
PPC64, but apparently it does not work for PPC32. There's been ongoing
work in this area, but unfortunately, nothing stable has come out of it.
I believe Dale was the last one to be working on this.
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 11/11] mmc: Add OpenFirmware bindings for SDHCI driver
On Sat, Mar 21, 2009 at 09:15:25AM +0900, yamazaki wrote:
> Hi
>
> Thank you for your reply.
> I know RICOH has PCI SD/MMC controller. But R5C807 RICOH is not the PCI device
> which is probably new product.
Ah, then it must be connected via MPC8347's localbus.
Well, then you need 2.6.29-rcX kernels, for example
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
is suitable.
Untar it and apply the patches (they'll apply fine on that
kernel). Then you'll need some device tree additions for
your MPC8347 board, something like this:
local...@e0005000 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "fsl,mpc8347-localbus",
"fsl,pq2pro-localbus";
reg = <0xe0005000 0xd8>;
ranges = <0x1 0x0 0xf000 0x1000>;
// ^^ change the 0xf000 to the actual address
sd...@1,0 {
compatible = "ricoh,r5c807", "generic-sdhci";
reg = <0x1 0x0 0x1000>;
interrupts = ;
interrupt-parent = <&ipic>;
// if needed, clock-frequency = ;
};
};
Note that I'm not sure what endiannes you'll get when connecting
the ricoh chip to the big-endinan host...
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 11/11] mmc: Add OpenFirmware bindings for SDHCI driver
Hi Thank you for your reply. I know RICOH has PCI SD/MMC controller. But R5C807 RICOH is not the PCI device which is probably new product. I made the "sdhci-of.c" from patch file,then I compiled it. But is was not succeeded. I thought the reason is the format of "the struct sdhci_of_data" is defferent from the kernel 2.6.28.7, That is why I sent this question. >Hi! > >On Fri, Mar 20, 2009 at 08:28:39AM +0900, yamazaki wrote: >> Hi all, >> >> I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD. >> I have to write the driver of SDHCI driver(using R5C807 RICOH). > >RICOH? It should be a PCI SD/MMC controller, so you even don't >need any patches to make it work in 2.6.28.7. Just make sure your >.config file has following symbols enabled: > >CONFIG_MMC_SDHCI=y >CONFIG_MMC_SDHCI_PCI=y >CONFIG_MMC_RICOH_MMC=y > >-- >Anton Vorontsov >email: cbouatmai...@gmail.com >irc://irc.freenode.net/bd2 >___ >Linuxppc-dev mailing list >Linuxppc-dev@ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc-dev yamazaki-se...@jcom.home.ne.jp ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linuxppc-dev@lists.ozlabs.org
Eduard Fuchs wrote: >>> Can I initialize the video card in uboot too? >> Yes, indeed you can. In a recent version of U-Boot, search for >> 'CONFIG_BIOSEMU' in include/configs/*. We tested this on a sequoia >> board, so include/configs/sequoia.h should be a good start for this. > > Thanks. > > I tried to include BIOSEMU and RADEON_FB in my u-boot. Bios emulator seems to > be properly loaded, but when u-boot attempt to read or write Radeon's > registers, the board freezes. >From the U-Boot output below it seems that the Radeon register access works already. At least one register read access succeeded before "videoboot: Booting PCI video card bus 0, function 0, device 7" output. > What means exactly the value of "VIDEO_IO_OFFSET" in the config file? It is the base address of an address range accesses to which are translated to an I/O access on PCI by the PCI bridge. > There is a u-boot's output when I init the VIDEO_IO_OFFSET with PCI's I/O > base > address: > > > INFO : PCI0_IO : base - 0xd800 size - 1M bytes > INFO : PCI0_MEM0: base - 0x8000 size - 1024M bytes > INFO : PCI0_MEM1: base - 0xc000 size - 128M bytes > INFO : PCI0_MEM2: base - 0xc800 size - 128M bytes > INFO : PCI0_MEM3: base - 0xd000 size - 128M bytes > . > PCI Scan: Found Bus 0, Device 7, Function 0 > PCI Scan: Found Bus 0, Device 7, Function 1 > PCI Scan: Found Bus 0, Device 9, Function 0 > PCI Scan: Found Bus 0, Device 10, Function 0 > Video: ATI Radeon video card (1002, 5960) found @(0:7:0) > videoboot: Booting PCI video card bus 0, function 0, device 7 > E 0 F00P0F000NI00PMS0EG 0F00 Is the address translation for PCI I/O configured by some BAT? Best regards, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 37/43] powerpc: Remove extra semicolon in fsl_soc.c
2.6.28-stable review patch. If anyone has any objections, please let us know. -- From: Johns Daniel TSEC/MDIO will not work with older device trees because of a semicolon at the end of a macro resulting in an empty for loop body. This fix only applies to 2.6.28; this code is gone in 2.6.29, according to Grant Likely! Signed-off-by: Johns Daniel Acked-by: Grant Likely Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/sysdev/fsl_soc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/sysdev/fsl_soc.c +++ b/arch/powerpc/sysdev/fsl_soc.c @@ -257,7 +257,7 @@ static int __init gfar_mdio_of_init(void gfar_mdio_of_init_one(np); /* try the deprecated version */ - for_each_compatible_node(np, "mdio", "gianfar"); + for_each_compatible_node(np, "mdio", "gianfar") gfar_mdio_of_init_one(np); return 0; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 19/32] powerpc: Remove extra semicolon in fsl_soc.c
2.6.27-stable review patch. If anyone has any objections, please let us know. -- From: Johns Daniel TSEC/MDIO will not work with older device trees because of a semicolon at the end of a macro resulting in an empty for loop body. This fix only applies to 2.6.28; this code is gone in 2.6.29, according to Grant Likely! Signed-off-by: Johns Daniel Acked-by: Grant Likely Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/sysdev/fsl_soc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/sysdev/fsl_soc.c +++ b/arch/powerpc/sysdev/fsl_soc.c @@ -255,7 +255,7 @@ static int __init gfar_mdio_of_init(void gfar_mdio_of_init_one(np); /* try the deprecated version */ - for_each_compatible_node(np, "mdio", "gianfar"); + for_each_compatible_node(np, "mdio", "gianfar") gfar_mdio_of_init_one(np); return 0; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 11/11] mmc: Add OpenFirmware bindings for SDHCI driver
Hi! On Fri, Mar 20, 2009 at 08:28:39AM +0900, yamazaki wrote: > Hi all, > > I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD. > I have to write the driver of SDHCI driver(using R5C807 RICOH). RICOH? It should be a PCI SD/MMC controller, so you even don't need any patches to make it work in 2.6.28.7. Just make sure your .config file has following symbols enabled: CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PCI=y CONFIG_MMC_RICOH_MMC=y -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2.6.29] ucc_geth: Fix oops when using fixed-link support
commit b1c4a9dddf09fe99b8f88252718ac5b357363dc4 ("ucc_geth: Change
uec phy id to the same format as gianfar's") introduced a regression
in the ucc_geth driver that causes this oops when fixed-link is used:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0151270
Oops: Kernel access of bad area, sig: 11 [#1]
TMCUTU
NIP: c0151270 LR: c0151270 CTR: c0017760
REGS: cf81fa60 TRAP: 0300 Not tainted (2.6.29-rc8)
MSR: 9032 CR: 24024042 XER: 2000
DAR: , DSISR: 2000
TASK = cf81cba0[1] 'swapper' THREAD: cf81e000
GPR00: c0151270 cf81fb10 cf81cba0 c0272e20 c025f354 1e80
cf86b08c
GPR08: d1068200 cb74 0600 d106c200 42024042 10085148 0fffd000
0ffc81a0
GPR16: 0001 0001 007ffeb0 c000 cf83f36c
cf83f000
GPR24: 0030 cf83f360 cf81fb20 d106c200 2000 1e80
cf83f360
NIP [c0151270] ucc_geth_open+0x330/0x1efc
LR [c0151270] ucc_geth_open+0x330/0x1efc
Call Trace:
[cf81fb10] [c0151270] ucc_geth_open+0x330/0x1efc (unreliable)
[cf81fba0] [c0187638] dev_open+0xbc/0x12c
[cf81fbc0] [c0187e38] dev_change_flags+0x8c/0x1b0
This patch fixes the issue by removing offending (and somewhat
duplicate) code from init_phy() routine, and changes _probe()
function to use uec_mdio_bus_name().
Also, since we fully construct phy_bus_id in the _probe() routine,
we no longer need ->phy_address and ->mdio_bus fields in
ucc_geth_info structure.
I wish the patch would be a bit shorter, but it seems like the only
way to fix the issue in a sane way. Luckily, the patch has been
tested with real PHYs and fixed-link, so no further regressions
expected.
Reported-by: Joakim Tjernlund
Signed-off-by: Anton Vorontsov
Tested-by: Joakim Tjernlund
---
On Fri, Mar 20, 2009 at 09:46:13PM +0100, Joakim Tjernlund wrote:
[...]
> > I would suggest something along these lines (unfortunately
> > right now I can't test it on real HW, only compile-tested):
>
> Tested here, works fine for fixed-link PHYs, thanks.
> I left the
> priv->oldlink = 0;
> priv->oldspeed = 0;
> priv->oldduplex = -1;
> in though. Seemed like a good idea.
Yeah, good catch.
> Tested By: Joakim Tjernlund
Thanks!
I found a QE board to test this patch, so now we have real PHY
and fixed-links known to work.
drivers/net/ucc_geth.c | 34 ++
drivers/net/ucc_geth.h |3 +--
2 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e879868..1f61e42 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1536,32 +1536,15 @@ static void adjust_link(struct net_device *dev)
static int init_phy(struct net_device *dev)
{
struct ucc_geth_private *priv = netdev_priv(dev);
- struct device_node *np = priv->node;
- struct device_node *phy, *mdio;
- const phandle *ph;
- char bus_name[MII_BUS_ID_SIZE];
- const unsigned int *id;
+ struct ucc_geth_info *ug_info = priv->ug_info;
struct phy_device *phydev;
- char phy_id[BUS_ID_SIZE];
priv->oldlink = 0;
priv->oldspeed = 0;
priv->oldduplex = -1;
- ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
- mdio = of_get_parent(phy);
-
- id = of_get_property(phy, "reg", NULL);
-
- of_node_put(phy);
- of_node_put(mdio);
-
- uec_mdio_bus_name(bus_name, mdio);
- snprintf(phy_id, sizeof(phy_id), "%s:%02x",
-bus_name, *id);
-
- phydev = phy_connect(dev, phy_id, &adjust_link, 0, priv->phy_interface);
+ phydev = phy_connect(dev, ug_info->phy_bus_id, &adjust_link, 0,
+priv->phy_interface);
if (IS_ERR(phydev)) {
printk("%s: Could not attach to PHY\n", dev->name);
@@ -3629,10 +3612,12 @@ static int ucc_geth_probe(struct of_device* ofdev,
const struct of_device_id *ma
ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
fixed_link = of_get_property(np, "fixed-link", NULL);
if (fixed_link) {
- snprintf(ug_info->mdio_bus, MII_BUS_ID_SIZE, "0");
- ug_info->phy_address = fixed_link[0];
+ snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
+PHY_ID_FMT, "0", fixed_link[0]);
phy = NULL;
} else {
+ char bus_name[MII_BUS_ID_SIZE];
+
ph = of_get_property(np, "phy-handle", NULL);
phy = of_find_node_by_phandle(*ph);
@@ -3643,7 +3628,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
prop = of_get_property(phy, "reg", NULL);
if (prop == NULL)
return -1;
- ug_info->phy_address = *prop;
/* Set the bus id */
mdio = of_get_parent(phy);
@@ -3657,7 +3641,9 @@ static int ucc_ge
Re: [PATCH v2] powerpc: Add support for CoreInt delivery of interrupts on MPIC
On Fri, 2009-03-20 at 06:47 -0500, Kumar Gala wrote: > On Mar 20, 2009, at 12:48 AM, Benjamin Herrenschmidt wrote: > > > On Wed, 2009-03-11 at 10:18 -0500, Kumar Gala wrote: > >> CoreInt provides a mechansim to deliver the IRQ vector directly > >> into the core on an interrupt (via the SPR EPR) rather than having > >> to go IACK on the PIC. This is suppose to provide an improvment > >> in interrupt latency by reducing the time to get the IRQ vector. > >> > >> Signed-off-by: Kumar Gala > >> --- > >> * Fixed MPIC_GREG_GCONF_COREINT flag to be 0x6000 as per spec > >> and pointed about by Dave > > > > Are you sure ? That's 2 bits ... > > Yeah. We expanded the mode field to two bits (mask would be 0x6000) > > 0x00 = pass through (interrupts routed to IRQ0) > 0x01 = Mixed mode > 0x10 = reserved > 0x11 = External proxy / coreint Ah ok, that's a bit funny but should do. Maybe worth a comment though. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
David Gibson wrote:
> On Thu, Mar 19, 2009 at 04:26:44PM +0100, Wolfgang Grandegger wrote:
>> This patch adds support for the "socrates" board based on the MPC8544.
>> Supported are Ethernet, serial console, I2C, I2C-based RTC and
>> temperature sensors, NOR and NAND flash, PCI, USB, CAN and Lime
>> display controller.
>>
>> The multiplexing of FPGA interrupts onto PowerPC interrupt lines is
>> supported through our own fpga_pic interrupt controller driver.
>>
>> For example the SJA1000 controller is level low sensitive connected to
>> fpga_pic line 2 and is routed to the second (of three) irq lines to
>> the CPU:
>
> A few minor device tree nits.
>
>> +soc8...@e000 {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +device_type = "soc";
>> +
>> +ranges = <0x 0xe000 0x0010>;
>> +reg = <0xe000 0x1000>; // CCSRBAR 1M
>> +bus-frequency = <0>;// Filled in by U-Boot
>> +compatible = "fsl,socrates-immr", "simple-bus";
>
> This should probably refer to 8544 instead of socrates. Unless you
> really do have a board-specific version of the SoC...
OK, that should then be:
+compatible = "fsl,mpc8544-immr", "simple-bus";
It should always be with the prefix "mpc", I guess. But some of the
following compatible names are without that prefix:
$ grep -h '\-l2-cache-controller' *
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,mpc8536-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8541-l2-cache-controller";
compatible = "fsl,8544-l2-cache-controller";
compatible = "fsl,8548-l2-cache-controller";
compatible = "fsl,8555-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8568-l2-cache-controller";
compatible = "fsl,mpc8572-l2-cache-controller";
compatible = "fsl,mpc8572-l2-cache-controller";
compatible = "fsl,mpc8572-l2-cache-controller";
compatible = "fsl,8548-l2-cache-controller";
compatible = "fsl,8560-l2-cache-controller";
compatible = "fsl,mpc8544-l2-cache-controller";
compatible = "fsl,mpc8544-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,mpc8548-l2-cache-controller";
compatible = "fsl,mpc8548-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
That's confusing.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fw: [PATCH] ucc_geth: Correct fixed_link OOPS.
Anton Vorontsov wrote on 20/03/2009 21:07:40: > > On Fri, Mar 20, 2009 at 08:43:56PM +0100, Joakim Tjernlund wrote: > > hmm, this mail didn't seem to reach the lists. Resending > > > > Jocke > > - Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42 - > > > > From: > > Joakim Tjernlund > > To: > > le...@freescale.com, net...@vger.kernel.org, linuxppc-dev@ozlabs.org > > Cc: > > Joakim Tjernlund > > Date: > > 20/03/2009 18:01 > > Subject: > > [PATCH] ucc_geth: Correct fixed_link OOPS. > > > > > > > > fixed_link(PHY less) mode will get you an NULL > > deference as it does not have a phy-handle. > > Correct by using already probed information. > > > > Signed-off-by: Joakim Tjernlund > > --- > > > > The below fixes the problem and seems like the right thing to do. > > Can we have this in 2.6.29? > > > > drivers/net/ucc_geth.c | 17 + > > 1 files changed, 1 insertions(+), 16 deletions(-) [SNIP] > > This effectivly breaks boards where Gianfar is using UCC's MDIO > bus (i.e. breaks commit b1c4a9dddf09fe99b8f88252718ac5b357363dc4, > which is the cause of fixed-link breakage, btw). And, your patch > is line-wrapped and tabs are substituted by white spaces... Yes, I noticed that afterwards. It is our "great" new mailsystem that gets in the way. I really need to find another mailsystem as Lotus/Domino gets in my way too often :( > > I would suggest something along these lines (unfortunately > right now I can't test it on real HW, only compile-tested): Tested here, works fine for fixed-link PHYs, thanks. I left the priv->oldlink = 0; priv->oldspeed = 0; priv->oldduplex = -1; in though. Seemed like a good idea. Tested By: Joakim Tjernlund Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
On Fri, Mar 20, 2009 at 08:57:43PM +0100, Ingo Molnar wrote:
>
> * Anton Vorontsov wrote:
>
> > On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > >
> > > * Anton Vorontsov wrote:
> > >
> > > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> > > > up menu"), despite the "clean up" in its purpose, introduced
> > > > behavioural change for Kconfig symbols: we no longer able to
> > > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> > > > yet implemented).
> > >
> > > Could you please solve this by implementing proper
> > > irqflag-tracing support? It's been available upstream for almost
> > > three years. It's needed for lockdep support as well, etc.
> >
> > Breaking things via clean up patches is an interesting method of
> > encouraging something to implement. ;-)
> >
> > Surely I'll look into implementing irqflags tracing, but
> > considering that no one ever needed this for almost three years,
> > [...]
>
> Weird, there's no lockdep support?
*ashamed*: apparently no such support currently exist for PPC32. ;-)
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
Hi Kumar,
Kumar Gala wrote:
>
> On Mar 19, 2009, at 10:26 AM, Wolfgang Grandegger wrote:
>
>> +m...@24520 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +compatible = "fsl,gianfar-mdio";
>> +reg = <0x24520 0x20>;
>> +
>> +phy0: ethernet-...@0 {
>> +interrupt-parent = <&mpic>;
>> +interrupts = <0 1>;
>> +reg = <0>;
>> +device_type = "ethernet-phy";
>> +};
>> +phy1: ethernet-...@1 {
>> +interrupt-parent = <&mpic>;
>> +interrupts = <0 1>;
>> +reg = <1>;
>> +device_type = "ethernet-phy";
>> +};
>> +tbi0: tbi-...@11 {
>> +reg = <0x11>;
>> +device_type = "tbi-phy";
>> +};
>> +};
>> +
>> +m...@26520 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +compatible = "fsl,gianfar-tbi";
>> +reg = <0x26520 0x20>;
>> +
>> +tbi1: tbi-...@11 {
>> +reg = <0x11>;
>> +device_type = "tbi-phy";
>> +};
>> +};
>> +
>> +enet0: ether...@24000 {
>> +cell-index = <0>;
>> +device_type = "network";
>> +model = "eTSEC";
>> +compatible = "gianfar";
>> +reg = <0x24000 0x1000>;
>> +local-mac-address = [ 00 00 00 00 00 00 ];
>> +interrupts = <29 2 30 2 34 2>;
>> +interrupt-parent = <&mpic>;
>> +phy-handle = <&phy0>;
>> +tbi-handle = <&tbi0>;
>> +phy-connection-type = "rgmii-id";
>> +};
>> +
>
> See Anton's recent post in moving the mdio node under the ethernet.
> Please match.
I have fixed it for the socrates board. Is there a GIT tree with that
modifications which I can base my patches on, also for the one for the
TQM8548 posted recently:
http://ozlabs.org/pipermail/linuxppc-dev/2009-March/069364.html
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
David Gibson wrote:
> On Thu, Mar 19, 2009 at 04:26:44PM +0100, Wolfgang Grandegger wrote:
[snip]
> [snip[
>> +disp...@2,0 {
>> +compatible = "fujitsu,lime";
>
> This compat string looks slightly worryingly non-specific.
The node is for the Lime graphic controller from Fujitsu. What does
worry you?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fw: [PATCH] ucc_geth: Correct fixed_link OOPS.
On Fri, Mar 20, 2009 at 08:43:56PM +0100, Joakim Tjernlund wrote:
> hmm, this mail didn't seem to reach the lists. Resending
>
> Jocke
> - Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42 -
>
> From:
> Joakim Tjernlund
> To:
> le...@freescale.com, net...@vger.kernel.org, linuxppc-dev@ozlabs.org
> Cc:
> Joakim Tjernlund
> Date:
> 20/03/2009 18:01
> Subject:
> [PATCH] ucc_geth: Correct fixed_link OOPS.
>
>
>
> fixed_link(PHY less) mode will get you an NULL
> deference as it does not have a phy-handle.
> Correct by using already probed information.
>
> Signed-off-by: Joakim Tjernlund
> ---
>
> The below fixes the problem and seems like the right thing to do.
> Can we have this in 2.6.29?
>
> drivers/net/ucc_geth.c | 17 +
> 1 files changed, 1 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index dc2f8f2..12e5c3d 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -1536,11 +1536,6 @@ static void adjust_link(struct net_device *dev)
> static int init_phy(struct net_device *dev)
> {
> struct ucc_geth_private *priv = netdev_priv(dev);
> -struct device_node *np = priv->node;
> -struct device_node *phy, *mdio;
> -const phandle *ph;
> -char bus_name[MII_BUS_ID_SIZE];
> -const unsigned int *id;
> struct phy_device *phydev;
> char phy_id[BUS_ID_SIZE];
>
> @@ -1548,18 +1543,8 @@ static int init_phy(struct net_device *dev)
> priv->oldspeed = 0;
> priv->oldduplex = -1;
>
> -ph = of_get_property(np, "phy-handle", NULL);
> -phy = of_find_node_by_phandle(*ph);
> -mdio = of_get_parent(phy);
> -
> -id = of_get_property(phy, "reg", NULL);
> -
> -of_node_put(phy);
> -of_node_put(mdio);
> -
> -uec_mdio_bus_name(bus_name, mdio);
> snprintf(phy_id, sizeof(phy_id), "%s:%02x",
> -bus_name, *id);
> + priv->ug_info->mdio_bus,
> priv->ug_info->phy_address);
>
> phydev = phy_connect(dev, phy_id, &adjust_link, 0,
> priv->phy_interface);
This effectivly breaks boards where Gianfar is using UCC's MDIO
bus (i.e. breaks commit b1c4a9dddf09fe99b8f88252718ac5b357363dc4,
which is the cause of fixed-link breakage, btw). And, your patch
is line-wrapped and tabs are substituted by white spaces...
I would suggest something along these lines (unfortunately
right now I can't test it on real HW, only compile-tested):
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e879868..58b78ed 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1536,32 +1536,11 @@ static void adjust_link(struct net_device *dev)
static int init_phy(struct net_device *dev)
{
struct ucc_geth_private *priv = netdev_priv(dev);
- struct device_node *np = priv->node;
- struct device_node *phy, *mdio;
- const phandle *ph;
- char bus_name[MII_BUS_ID_SIZE];
- const unsigned int *id;
+ struct ucc_geth_info *ug_info = priv->ug_info;
struct phy_device *phydev;
- char phy_id[BUS_ID_SIZE];
-
- priv->oldlink = 0;
- priv->oldspeed = 0;
- priv->oldduplex = -1;
-
- ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
- mdio = of_get_parent(phy);
-
- id = of_get_property(phy, "reg", NULL);
- of_node_put(phy);
- of_node_put(mdio);
-
- uec_mdio_bus_name(bus_name, mdio);
- snprintf(phy_id, sizeof(phy_id), "%s:%02x",
-bus_name, *id);
-
- phydev = phy_connect(dev, phy_id, &adjust_link, 0, priv->phy_interface);
+ phydev = phy_connect(dev, ug_info->phy_bus_id, &adjust_link, 0,
+priv->phy_interface);
if (IS_ERR(phydev)) {
printk("%s: Could not attach to PHY\n", dev->name);
@@ -3629,10 +3608,12 @@ static int ucc_geth_probe(struct of_device* ofdev,
const struct of_device_id *ma
ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
fixed_link = of_get_property(np, "fixed-link", NULL);
if (fixed_link) {
- snprintf(ug_info->mdio_bus, MII_BUS_ID_SIZE, "0");
- ug_info->phy_address = fixed_link[0];
+ snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
+PHY_ID_FMT, "0", fixed_link[0]);
phy = NULL;
} else {
+ char bus_name[MII_BUS_ID_SIZE];
+
ph = of_get_property(np, "phy-handle", NULL);
phy = of_find_node_by_phandle(*ph);
@@ -3643,7 +3624,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
prop = of_get_property(p
Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
* Anton Vorontsov wrote:
> On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> >
> > * Anton Vorontsov wrote:
> >
> > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> > > up menu"), despite the "clean up" in its purpose, introduced
> > > behavioural change for Kconfig symbols: we no longer able to
> > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> > > yet implemented).
> >
> > Could you please solve this by implementing proper
> > irqflag-tracing support? It's been available upstream for almost
> > three years. It's needed for lockdep support as well, etc.
>
> Breaking things via clean up patches is an interesting method of
> encouraging something to implement. ;-)
>
> Surely I'll look into implementing irqflags tracing, but
> considering that no one ever needed this for almost three years,
> [...]
Weird, there's no lockdep support?
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Fw: [PATCH] ucc_geth: Correct fixed_link OOPS.
hmm, this mail didn't seem to reach the lists. Resending
Jocke
- Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42 -
From:
Joakim Tjernlund
To:
le...@freescale.com, net...@vger.kernel.org, linuxppc-dev@ozlabs.org
Cc:
Joakim Tjernlund
Date:
20/03/2009 18:01
Subject:
[PATCH] ucc_geth: Correct fixed_link OOPS.
fixed_link(PHY less) mode will get you an NULL
deference as it does not have a phy-handle.
Correct by using already probed information.
Signed-off-by: Joakim Tjernlund
---
The below fixes the problem and seems like the right thing to do.
Can we have this in 2.6.29?
drivers/net/ucc_geth.c | 17 +
1 files changed, 1 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index dc2f8f2..12e5c3d 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1536,11 +1536,6 @@ static void adjust_link(struct net_device *dev)
static int init_phy(struct net_device *dev)
{
struct ucc_geth_private *priv = netdev_priv(dev);
-struct device_node *np = priv->node;
-struct device_node *phy, *mdio;
-const phandle *ph;
-char bus_name[MII_BUS_ID_SIZE];
-const unsigned int *id;
struct phy_device *phydev;
char phy_id[BUS_ID_SIZE];
@@ -1548,18 +1543,8 @@ static int init_phy(struct net_device *dev)
priv->oldspeed = 0;
priv->oldduplex = -1;
-ph = of_get_property(np, "phy-handle", NULL);
-phy = of_find_node_by_phandle(*ph);
-mdio = of_get_parent(phy);
-
-id = of_get_property(phy, "reg", NULL);
-
-of_node_put(phy);
-of_node_put(mdio);
-
-uec_mdio_bus_name(bus_name, mdio);
snprintf(phy_id, sizeof(phy_id), "%s:%02x",
-bus_name, *id);
+ priv->ug_info->mdio_bus,
priv->ug_info->phy_address);
phydev = phy_connect(dev, phy_id, &adjust_link, 0,
priv->phy_interface);
--
1.6.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
>
> * Anton Vorontsov wrote:
>
> > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> > up menu"), despite the "clean up" in its purpose, introduced
> > behavioural change for Kconfig symbols: we no longer able to
> > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> > yet implemented).
>
> Could you please solve this by implementing proper irqflag-tracing
> support? It's been available upstream for almost three years. It's
> needed for lockdep support as well, etc.
Breaking things via clean up patches is an interesting method of
encouraging something to implement. ;-)
Surely I'll look into implementing irqflags tracing, but considering
that no one ever needed this for almost three years, and that we
explicitly have the code to deal with tracing-w/o-irqflags, can we
please restore the old behaviour?
At least for 2.6.30, because I don't think I'll have enough time to
implement/test/push irqflags tracing support in time for 2.6.30-rc1.
Thanks,
p.s.
It would make more sense if 40ada30f's commit message would state
that tracing w/o irqflags is now obsolete, or better, if it was
discussed on some mailinglist, so that we'd have some time to
adapt the architecture-specific code.
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fix for __div64_32 locks when using some 64 bit numbers
Hi Ben: I was wondering if you have any change to look into and test the propose fix I suggested in my previous post. I'd like to know if the fix is correct. Thanks for your attention, Benjamin Herrenschmidt wrote: > > On Tue, 2009-03-17 at 14:15 -0700, davidastro wrote: >> I found a bug when using the function __div64_32 in assembly in a 32 bit >> ppc >> architecture unit. >> >> I tried the numbers 5583456504800 for the dividend and 4294967079 for >> the divisor. When passing these two numbers to the function __div64_32, >> I >> had a software lock. I searched for possible patches online and in >> different >> forums but I could not find anything related to the assembly >> implementation >> to this function (I would have to apologize if somebody already found a >> fix >> :-) ). >> >> Anyway, when analyzing the assembly code, I found out with gdb the >> problem. >> I am not an expert in ppc architecture but I read the documentation and I >> am >> pretty sure I solved the issue (I have been testing for couple of days >> using >> random 64 to 32 number combinations with good results). >> >> Who or Where should I post the fix to be reviewed. > > Here is fine :-) > > Ben. > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > -- View this message in context: http://www.nabble.com/Fix-for-__div64_32-locks-when-using-some-64-bit-numbers-tp22567864p22627440.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
* Anton Vorontsov wrote:
> commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> up menu"), despite the "clean up" in its purpose, introduced
> behavioural change for Kconfig symbols: we no longer able to
> select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> yet implemented).
Could you please solve this by implementing proper irqflag-tracing
support? It's been available upstream for almost three years. It's
needed for lockdep support as well, etc.
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 0/3] Tracers vs. CALLER_ADDR on PowerPC
On Fri, Mar 20, 2009 at 07:44:04PM +0300, Anton Vorontsov wrote: > Hi all, > > Here is another approach to fixing tracers vs. CALLER_ADDR problem > on PowerPC. > > Preface for those who don't know or forgot what the problem is: > > Gcc frame pointers do nothing useful on PowerPC (they're harmful, > actually), and thus lib/Kconfig.debug makes CONFIG_FRAME_POINTER > unselectable on PPC targets, but CALLER_ADDR macros are available > only with CONFIG_FRAME_POINTER, therefore tracing is completely > useless on PowerPC: > > [...] > -0 0X.h32us+: 0:140:R + [000] 1733:120:S mvtsd > -0 0X.h39us+: 0 (0) > -0 0X..3 72us : 0 (0) > -0 0X..3 73us : 0:140:R ==> [000] 1733:120:R mvtsd > > While it should look like this: > > [...] > -0 0X.h32us+: 0:140:R + [000] 1740:120:S mvtsd > -0 0X.h39us+: hrtimer_wakeup (__run_hrtimer) > -0 0X..3 87us : cpu_idle (__got2_end) > -0 0X..3 89us : 0:140:R ==> [000] 1740:120:R mvtsd > > I've tried to fix the issue via expanding the #ifdef in the ftrace.h: > http://lkml.org/lkml/2009/1/31/141 > > Then Steven Rostedt suggested to implement something more generic, > i.e. HAVE_NORMAL_FRAME_POINTERS Kconfig symbol. > > I found a way to solve the problem w/o additional symbols, but > with some Makefile magic (http://lkml.org/lkml/2009/2/4/273). > But because of top-level Makefile issues on other arches > (http://lkml.org/lkml/2009/2/14/89) I had to abandon the approach. Oh, and btw, I'm aware of commit c79a61f55773d2519fd0525bf58385f7d20752d3 Author: Uwe Kleine-Koenig Date: Fri Feb 27 21:30:03 2009 +0100 tracing: make CALLER_ADDRx overwriteable But I think the patch set is still applicable, considering that it removes gcc bug workaround in a nice way, and makes CONFIG_FRAME_POINTER available on PowerPC, thus other code can rely on that. If not, I can just fill-in the asm/ftrace.h for PowerPC. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they should select FRAME_POINTER. Otherwise traces are meaningless. Signed-off-by: Anton Vorontsov --- kernel/trace/Kconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 774aba7..9fc98a7 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -107,6 +107,7 @@ config IRQSOFF_TRACER select TRACE_IRQFLAGS select TRACING select TRACER_MAX_TRACE + select FRAME_POINTER help This option measures the time spent in irqs-off critical sections, with microsecond accuracy. @@ -128,6 +129,7 @@ config PREEMPT_TRACER depends on PREEMPT select TRACING select TRACER_MAX_TRACE + select FRAME_POINTER help This option measures the time spent in preemption off critical sections, with microsecond accuracy. @@ -156,6 +158,7 @@ config SCHED_TRACER select TRACING select CONTEXT_SWITCH_TRACER select TRACER_MAX_TRACE + select FRAME_POINTER help This tracer tracks the latency of the highest priority task to be scheduled in, starting from the point it has woken up. -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: Remove -fno-omit-frame-pointer workarounds
The workarounds aren't needed any longer since the top level Makefile doesn't pass -fno-omit-frame-pointer cflag for PowerPC. Signed-off-by: Anton Vorontsov --- arch/powerpc/Makefile|5 - arch/powerpc/kernel/Makefile | 12 ++-- arch/powerpc/platforms/powermac/Makefile |2 +- lib/Kconfig.debug|6 +++--- 4 files changed, 10 insertions(+), 15 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 551fc58..1dd7748 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -120,11 +120,6 @@ ifeq ($(CONFIG_6xx),y) KBUILD_CFLAGS += -mcpu=powerpc endif -# Work around a gcc code-gen bug with -fno-omit-frame-pointer. -ifeq ($(CONFIG_FUNCTION_TRACER),y) -KBUILD_CFLAGS += -mno-sched-epilog -endif - cpu-as-$(CONFIG_4xx) += -Wa,-m405 cpu-as-$(CONFIG_6xx) += -Wa,-maltivec cpu-as-$(CONFIG_POWER4)+= -Wa,-maltivec diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index dfec3d2..f86caeb 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -14,14 +14,14 @@ endif ifdef CONFIG_FUNCTION_TRACER # Do not trace early boot code -CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog -CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog -CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog -CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog +CFLAGS_REMOVE_cputable.o = -pg +CFLAGS_REMOVE_prom_init.o = -pg +CFLAGS_REMOVE_btext.o = -pg +CFLAGS_REMOVE_prom.o = -pg # do not trace tracer code -CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog +CFLAGS_REMOVE_ftrace.o = -pg # timers used by tracing -CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog +CFLAGS_REMOVE_time.o = -pg endif obj-y := cputable.o ptrace.o syscalls.o \ diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile index 50f1693..0eb8781 100644 --- a/arch/powerpc/platforms/powermac/Makefile +++ b/arch/powerpc/platforms/powermac/Makefile @@ -2,7 +2,7 @@ CFLAGS_bootx_init.o += -fPIC ifdef CONFIG_FUNCTION_TRACER # Do not trace early boot code -CFLAGS_REMOVE_bootx_init.o = -pg -mno-sched-epilog +CFLAGS_REMOVE_bootx_init.o = -pg endif obj-y += pic.o setup.o time.o feature.o pci.o \ diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index fc8cd1f..713620d 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -493,7 +493,7 @@ config LOCKDEP bool depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT select STACKTRACE - select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND + select FRAME_POINTER if !MIPS && !ARM_UNWIND select KALLSYMS select KALLSYMS_ALL @@ -866,13 +866,13 @@ config FAULT_INJECTION_STACKTRACE_FILTER depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT depends on !X86_64 select STACKTRACE - select FRAME_POINTER if !PPC + select FRAME_POINTER help Provide stacktrace filter for fault-injection capabilities config LATENCYTOP bool "Latency measuring infrastructure" - select FRAME_POINTER if !MIPS && !PPC + select FRAME_POINTER if !MIPS select KALLSYMS select KALLSYMS_ALL select STACKTRACE -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
This patch introduces ARCH_HAS_NORMAL_FRAME_POINTERS Kconfig symbol. When defined, the top level Makefile won't add -fno-omit-frame-pointer cflag (the flag is useless in PowerPC kernels, and also makes gcc generate wrong code). Also move ARCH_WANT_FRAME_POINTERS's help text. Signed-off-by: Anton Vorontsov --- Makefile |7 +-- arch/powerpc/Kconfig |1 + lib/Kconfig.debug| 16 ++-- 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 46c04c5..bf41b05 100644 --- a/Makefile +++ b/Makefile @@ -538,9 +538,12 @@ KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) endif ifdef CONFIG_FRAME_POINTER -KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls + KBUILD_CFLAGS+= -fno-optimize-sibling-calls + ifndef ARCH_HAS_NORMAL_FRAME_POINTERS +KBUILD_CFLAGS += -fno-omit-frame-pointer + endif else -KBUILD_CFLAGS += -fomit-frame-pointer + KBUILD_CFLAGS+= -fomit-frame-pointer endif ifdef CONFIG_DEBUG_INFO diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 97f9a64..4587e66 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -113,6 +113,7 @@ config PPC select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_GRAPH_TRACER select ARCH_WANT_OPTIONAL_GPIOLIB + select ARCH_HAS_NORMAL_FRAME_POINTERS select HAVE_IDE select HAVE_IOREMAP_PROT select HAVE_EFFICIENT_UNALIGNED_ACCESS diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 4b63b6b..fc8cd1f 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -661,20 +661,24 @@ config DEBUG_NOTIFIERS This is a relatively cheap check but if you care about maximum performance, say N. -# -# Select this config option from the architecture Kconfig, if it -# it is preferred to always offer frame pointers as a config -# option on the architecture (regardless of KERNEL_DEBUG): -# config ARCH_WANT_FRAME_POINTERS bool help + Select this config option from the architecture Kconfig, if it + it is preferred to always offer frame pointers as a config + option on the architecture (regardless of KERNEL_DEBUG). + +config ARCH_HAS_NORMAL_FRAME_POINTERS + bool + help + Architectures should select this symbol if their ABI implies + having a frame pointer. config FRAME_POINTER bool "Compile the kernel with frame pointers" depends on DEBUG_KERNEL && \ (CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \ -AVR32 || SUPERH || BLACKFIN || MN10300) || \ +AVR32 || SUPERH || BLACKFIN || MN10300 || PPC) || \ ARCH_WANT_FRAME_POINTERS default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS help -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 0/3] Tracers vs. CALLER_ADDR on PowerPC
Hi all, Here is another approach to fixing tracers vs. CALLER_ADDR problem on PowerPC. Preface for those who don't know or forgot what the problem is: Gcc frame pointers do nothing useful on PowerPC (they're harmful, actually), and thus lib/Kconfig.debug makes CONFIG_FRAME_POINTER unselectable on PPC targets, but CALLER_ADDR macros are available only with CONFIG_FRAME_POINTER, therefore tracing is completely useless on PowerPC: [...] -0 0X.h32us+: 0:140:R + [000] 1733:120:S mvtsd -0 0X.h39us+: 0 (0) -0 0X..3 72us : 0 (0) -0 0X..3 73us : 0:140:R ==> [000] 1733:120:R mvtsd While it should look like this: [...] -0 0X.h32us+: 0:140:R + [000] 1740:120:S mvtsd -0 0X.h39us+: hrtimer_wakeup (__run_hrtimer) -0 0X..3 87us : cpu_idle (__got2_end) -0 0X..3 89us : 0:140:R ==> [000] 1740:120:R mvtsd I've tried to fix the issue via expanding the #ifdef in the ftrace.h: http://lkml.org/lkml/2009/1/31/141 Then Steven Rostedt suggested to implement something more generic, i.e. HAVE_NORMAL_FRAME_POINTERS Kconfig symbol. I found a way to solve the problem w/o additional symbols, but with some Makefile magic (http://lkml.org/lkml/2009/2/4/273). But because of top-level Makefile issues on other arches (http://lkml.org/lkml/2009/2/14/89) I had to abandon the approach. So, this patch set combines Steven Rostedt's idea and a small Makefile change, so that now only top-level Makefile has to know about the new symbol, and the rest of the kernel can stay with using CONFIG_FRAME_POINTER. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ucc_geth broken w.r.t fixed_link PHY
Trying to upgrade to latest linus latest just to see if it still works I
get this:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0151270
Oops: Kernel access of bad area, sig: 11 [#1]
TMCUTU
NIP: c0151270 LR: c0151270 CTR: c0017760
REGS: cf81fa60 TRAP: 0300 Not tainted (2.6.29-rc8)
MSR: 9032 CR: 24024042 XER: 2000
DAR: , DSISR: 2000
TASK = cf81cba0[1] 'swapper' THREAD: cf81e000
GPR00: c0151270 cf81fb10 cf81cba0 c0272e20 c025f354 1e80
cf86b08c
GPR08: d1068200 cb74 0600 d106c200 42024042 10085148 0fffd000
0ffc81a0
GPR16: 0001 0001 007ffeb0 c000 cf83f36c
cf83f000
GPR24: 0030 cf83f360 cf81fb20 d106c200 2000 1e80
cf83f360
NIP [c0151270] ucc_geth_open+0x330/0x1efc
LR [c0151270] ucc_geth_open+0x330/0x1efc
Call Trace:
[cf81fb10] [c0151270] ucc_geth_open+0x330/0x1efc (unreliable)
[cf81fba0] [c0187638] dev_open+0xbc/0x12c
[cf81fbc0] [c0187e38] dev_change_flags+0x8c/0x1b0
[cf81fbe0] [c02a5e94] tm_icn_address+0x5f0/0x1038
[cf81fd70] [c00038b0] do_one_initcall+0x34/0x1dc
[cf81ffd0] [c02887dc] kernel_init+0x90/0x10c
[cf81fff0] [c00106a4] kernel_thread+0x4c/0x68
Instruction dump:
7c0004ac 914b0144 3800 807f02b4 3c80c027 901f02ac 38842e20 38a0
937f02a8 3b410010 937f02b0 48022ef9 <8063> 4bebc8c9 7c7d1b78 48023155
---[ end trace 5e5a8c89939b0ba3 ]---
gdb vmlinux shows:
(gdb) list *0xc0151270
0xc0151270 is in ucc_geth_open (drivers/net/ucc_geth.c:1552).
1547priv->oldlink = 0;
1548priv->oldspeed = 0;
1549priv->oldduplex = -1;
1550
1551ph = of_get_property(np, "phy-handle", NULL);
1552phy = of_find_node_by_phandle(*ph);
1553mdio = of_get_parent(phy);
1554
1555id = of_get_property(phy, "reg", NULL);
1556
Tunrsn out that my fixed_link PHY doesn't work anymore. I don't have a
phy-handle in
in my of tree. Instead I got fixed-link:
enet2: u...@3200 { //UCC4
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <4>;
cell-index = <4>;
reg = <3200 200>;
interrupts = <23>;
interrupt-parent = <&qeic>;
mac-address = [ 00 11 22 33 44 99 ];
rx-clock = <17>; //CLK7, 23
tx-clock = <18>; //CLK8, 24
fixed-link = <19 1 1 100 0 0>;
phy-connection-type = "mii";
pio-handle = <&pio4>;
};
So what is broken, ucc_geth or my OF tree?
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
linuxppc-dev@lists.ozlabs.org
Am Freitag 20 März 2009 11:51:11 schrieb Detlev Zundel: > Hi Eduard, > > > Am Mittwoch 18 März 2009 00:05:00 schrieb Benjamin Herrenschmidt: > >> On Tue, 2009-03-17 at 16:30 +0100, Eduard Fuchs wrote: > >> > Hi all, > >> > > >> > since several days I'm trying to run an ATI 9250 (PCI) graphic card > >> > under Linux Kernel 2.6.27.19. Nevertheless without success. The kernel > >> > shows the following message: > >> > > >> > videoboot: Booting PCI video card bus 0, function 0, device 7 > >> > biosEmu: undefined interrupt 15h called! > >> > biosEmu/bios.int42: unknown function AH=0x0, AL=0x7, BL=0x0 > >> > >> The above comes from some patches you added to the kernel ? You should > >> probably do the softboot in the firmware instead... > > > > Yes. I'm using the videoboot-2.6x.patch (this patch contain also the > > xf86emu from www.scitechsoft.com). With this pach the radeon card work > > properly with 2.6.12 kernel version. On the 2.6.27 kernel the "videoboot" > > fetch the bios from the video card and start them in the xf86emu. > > > > Can I initialize the video card in uboot too? > > Yes, indeed you can. In a recent version of U-Boot, search for > 'CONFIG_BIOSEMU' in include/configs/*. We tested this on a sequoia > board, so include/configs/sequoia.h should be a good start for this. Thanks. I tried to include BIOSEMU and RADEON_FB in my u-boot. Bios emulator seems to be properly loaded, but when u-boot attempt to read or write Radeon's registers, the board freezes. What means exactly the value of "VIDEO_IO_OFFSET" in the config file? There is a u-boot's output when I init the VIDEO_IO_OFFSET with PCI's I/O base address: INFO : PCI0_IO : base - 0xd800 size - 1M bytes INFO : PCI0_MEM0: base - 0x8000 size - 1024M bytes INFO : PCI0_MEM1: base - 0xc000 size - 128M bytes INFO : PCI0_MEM2: base - 0xc800 size - 128M bytes INFO : PCI0_MEM3: base - 0xd000 size - 128M bytes . PCI Scan: Found Bus 0, Device 7, Function 0 PCI Scan: Found Bus 0, Device 7, Function 1 PCI Scan: Found Bus 0, Device 9, Function 0 PCI Scan: Found Bus 0, Device 10, Function 0 Video: ATI Radeon video card (1002, 5960) found @(0:7:0) videoboot: Booting PCI video card bus 0, function 0, device 7 E 0 F00P0F000NI00PMS0EG 0F00 and after that follows board reset. Best regards. Eduard Fuchs ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] tracing: Fix TRACING_SUPPORT dependency
commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean up
menu"), despite the "clean up" in its purpose, introduced behavioural
change for Kconfig symbols: we no longer able to select tracing
support on PPC32 (because IRQFLAGS_SUPPORT isn't yet implemented).
The IRQFLAGS_SUPPORT is not mandatory for most tracers, tracing core
has a special case for platforms w/o irqflags (which, by the way, has
become useless as of the commit above).
This patch restores the old behaviour, and thus brings the tracing
back on PPC32.
p.s.
The IRQSOFF_TRACER (which is the only tracer that requires IRQFLAGS
support) still depends on TRACE_IRQFLAGS_SUPPORT Kconfig symbol.
Signed-off-by: Anton Vorontsov
---
kernel/trace/Kconfig |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ee70841..774aba7 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -63,7 +63,6 @@ config TRACING
#
config TRACING_SUPPORT
bool
- depends on TRACE_IRQFLAGS_SUPPORT
depends on STACKTRACE_SUPPORT
default y
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: suspend-to-mem on the mpc8349e-mitx-gp?
Li Yang-R58472 wrote: However, the code should treat "mem" as "standby" on chips that don't support deep sleep. What does the device tree Well, shouldn't the valid() callback reject unsupported states instead of covering up? I don't think so, in this case. The user is not asking for "sleep" or deep sleep"; they are asking for a power state that meets the definition of "standby" (which sleep does) or which meets the definition of "mem" (which both sleep and deep sleep do). When the user asks for "mem", we provide the lowest power mode that qualifies. I'm willing to change it if there's substantial existing practice to the contrary, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Fwd: Re: IDE cable detection on Apple PowerBook]
On Fri, 20 Mar 2009 12:40:29 +0100 Bartlomiej Zolnierkiewicz wrote: > Moreover the underlying issue is non-PMAC specific and asks for generic > resolution, please see: > > http://bugzilla.kernel.org/show_bug.cgi?id=12734#c13 > > for previous discussion. > > In the very least case it should be a generic kernel parameter, i.e. > "ide_core.ignore_cables" and iff the current "ide_core.ignore_cable=" > is not enough. TOMARI, could please look into it? > > Thanks, > Bart It works! As the internal IDE controller is detected as ide0, I passed "ide_core.ignore_cable=0" to the kernel, and the drive works in UDMA/100 mode. This method seems much cleaner way to solve the problem. Thank you, Bart, Ben and Anton. % dmesg |grep hda Kernel command line: root=/dev/hda4 ro ide_core.ignore_cable=0 hda: CORE_PATA, ATA DISK drive hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hda: UDMA/100 mode selected hda: max request size: 512KiB hda: 252411904 sectors (129234 MB), CHS=16383/255/63 hda: cache flushes supported hda: [mac] hda1 hda2 hda3 hda4 hda5 hda6 hda7 XFS mounting filesystem hda4 Ending clean XFS mount for filesystem: hda4 Adding 846672k swap on /dev/hda5. Priority:-1 extents:1 across:846672k -- TOMARI Hisanobu ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linuxppc-dev@lists.ozlabs.org
Hi Eduard, > Am Mittwoch 18 März 2009 00:05:00 schrieb Benjamin Herrenschmidt: >> On Tue, 2009-03-17 at 16:30 +0100, Eduard Fuchs wrote: >> > Hi all, >> > >> > since several days I'm trying to run an ATI 9250 (PCI) graphic card under >> > Linux Kernel 2.6.27.19. Nevertheless without success. The kernel shows >> > the following message: >> > >> > videoboot: Booting PCI video card bus 0, function 0, device 7 >> > biosEmu: undefined interrupt 15h called! >> > biosEmu/bios.int42: unknown function AH=0x0, AL=0x7, BL=0x0 >> >> The above comes from some patches you added to the kernel ? You should >> probably do the softboot in the firmware instead... > > Yes. I'm using the videoboot-2.6x.patch (this patch contain also the xf86emu > from www.scitechsoft.com). With this pach the radeon card work properly with > 2.6.12 kernel version. On the 2.6.27 kernel the "videoboot" fetch the bios > from the video card and start them in the xf86emu. > > Can I initialize the video card in uboot too? Yes, indeed you can. In a recent version of U-Boot, search for 'CONFIG_BIOSEMU' in include/configs/*. We tested this on a sequoia board, so include/configs/sequoia.h should be a good start for this. Cheers Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
Grant Likely wrote:
> I agree 100% with David's comments, and I have some additional ones below.
OK.
> On Thu, Mar 19, 2009 at 9:26 AM, Wolfgang Grandegger
> wrote:
>> + soc8...@e000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>
> Drop device_type here too.
>
>> +
>> + ranges = <0x 0xe000 0x0010>;
>> + reg = <0xe000 0x1000>; // CCSRBAR 1M
>> + bus-frequency = <0>;// Filled in by U-Boot
>> + compatible = "fsl,socrates-immr", "simple-bus";
>
> As David said, fix this to be SoC specific, not board specific.
>
>> + localbus {
>> + compatible = "fsl,socrates-localbus",
>> +"fsl,mpc85xx-localbus",
>> +"fsl,pq3-localbus";
>
> 1st entry shouldn't be there.
> 2nd entry should specify exact chip
> 3rd entry I don't like much, but others may debate me on it
> Also, add "simple-bus" to this list. (important for a later comment)
OK.
>
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + reg = <0xe0005000 0x40>;
>> +
>> + ranges = <0 0 0xfc00 0x0400
>> + 2 0 0xc800 0x0400
>> + 3 0 0xc000 0x0010
>> + >; /* Overwritten by U-Boot */
>
> Just curious, why is U-Boot overwriting the ranges property?
Because there are boards without FPGA or graphic controller on the local
bus.
>> + fpga_pic: fpga-...@3,10 {
>> + compatible = "abb,socrates-fpga-pic";
>
> Is 'abb' the companies' stock ticker symbol? If not, then use the
> real name and not an abbreviation.
Yes.
>> Index: linux-2.6/arch/powerpc/boot/wrapper
>> ===
>> --- linux-2.6.orig/arch/powerpc/boot/wrapper
>> +++ linux-2.6/arch/powerpc/boot/wrapper
>> @@ -183,7 +183,7 @@ cuboot*)
>> *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555|*-ksi8560*)
>> platformo=$object/cuboot-85xx-cpm2.o
>> ;;
>> -*-mpc85*|*-tqm85*|*-sbc85*)
>> +*-mpc85*|*-tqm85*|*-sbc85*|*-socrates)
>> platformo=$object/cuboot-85xx.o
>> ;;
>
> Is this a new or old platform? Can U-Boot on the board boot with a
> uImage + dtb instead of a cuImage? I'd prefer to avoid adding new
> cuImages to the wrapper script if at all possible.
It's a new platform. Therefore I will drop cuboot support.
>> Index: linux-2.6/arch/powerpc/configs/85xx/socrates_defconfig
>> ===
>> --- /dev/null
>> +++ linux-2.6/arch/powerpc/configs/85xx/socrates_defconfig
>
> Is a socrates-specific defconfig really warranted?
>
>> --- linux-2.6.orig/arch/powerpc/platforms/85xx/Makefile
>> +++ linux-2.6/arch/powerpc/platforms/85xx/Makefile
>> @@ -13,4 +13,6 @@ obj-$(CONFIG_STX_GP3) += stx_gp3.o
>> obj-$(CONFIG_TQM85xx)+= tqm85xx.o
>> obj-$(CONFIG_SBC8560) += sbc8560.o
>> obj-$(CONFIG_SBC8548) += sbc8548.o
>> +obj-$(CONFIG_SOCRATES)+= socrates.o
>> +obj-$(CONFIG_SOCRATES)+= socrates_fpga_pic.o
>
> The pic stuff isn't all that big. Personally I'd roll it all into the
> socrates.c file.
Well,
$ wc -l socrates_fpga_pic.c
156 socrates.c
320 socrates_fpga_pic.c
Personally, I'd prefer to separate the pic from the board init code,
especially with that size.
>> --- /dev/null
>> +++ linux-2.6/arch/powerpc/platforms/85xx/socrates.c
>> +static void __init socrates_pic_init(void)
>> +{
>> + struct mpic *mpic;
>> + struct resource r;
>> + struct device_node *np;
>> +
>> + np = of_find_node_by_type(NULL, "open-pic");
>> + if (!np) {
>> + printk(KERN_ERR "Could not find open-pic node\n");
>> + return;
>> + }
>> +
>> + if (of_address_to_resource(np, 0, &r)) {
>> + printk(KERN_ERR "Could not map mpic register space\n");
>> + of_node_put(np);
>> + return;
>> + }
>> +
>> + mpic = mpic_alloc(np, r.start,
>> + MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
>> + 0, 256, " OpenPIC ");
>> + BUG_ON(mpic == NULL);
>> + of_node_put(np);
>> +
>> + mpic_init(mpic);
>
> Heh, this is a block of code cloned between all the 85xx boards it
> seems. Smells like a small refactoring candidate. This isn't really
> a critique of this patch, but I noticed it so I thought I'd mention
> it.
>
>> +static void socrates_show_cpuinfo(struct seq_file *m)
>> +{
>> + uint pvid, svid, phid1;
>> + uint memsize = total_memory;
>> +
>> + pvid = mfspr(SPRN_PVR);
>> + svid = mfspr(SPRN_SVR);
>> +
>> + seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
>> + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
>> +
>> + /* Display cpu Pll s
Re: [PATCH v2] powerpc: Add support for CoreInt delivery of interrupts on MPIC
On Mar 20, 2009, at 12:48 AM, Benjamin Herrenschmidt wrote: On Wed, 2009-03-11 at 10:18 -0500, Kumar Gala wrote: CoreInt provides a mechansim to deliver the IRQ vector directly into the core on an interrupt (via the SPR EPR) rather than having to go IACK on the PIC. This is suppose to provide an improvment in interrupt latency by reducing the time to get the IRQ vector. Signed-off-by: Kumar Gala --- * Fixed MPIC_GREG_GCONF_COREINT flag to be 0x6000 as per spec and pointed about by Dave Are you sure ? That's 2 bits ... Yeah. We expanded the mode field to two bits (mask would be 0x6000) 0x00 = pass through (interrupts routed to IRQ0) 0x01 = Mixed mode 0x10 = reserved 0x11 = External proxy / coreint - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Xilinx cygwin linux cross recommendations ?
David H. Lynch Jr. wrote: > I have no experience with ELDK. > Have you used it ? Do you like it ? > > When I started I mostly did a roll my own environment using crosstool. > I would have stuck to that except I can not get uclibc and it has > not been updated in a long time. > Crosstool-ng did not support the ppc last time I looked. Look again - PowerPC is quite well supported by CrossTool-ng > Today I use buildroot - mostly just to build a toolchain - I have > never been able to get it to do many of the other things it is capable of. > > I am not particularly fond (serious understatement) of "integrated > solve all the problems of the world" environments, they rarely work, and > you must think inside their box. > > I would be ecstatic with just a cygwin-linux-ppc-uclibc tool chain. > Why not just skip the torture (CygWin) and just run a virtual machine on Windows [I assume you _have_ to have Windows]. Both VM-Ware and VirtualBox handle this problem beautifully. Then you have *Linux* for your development environment, not some cobbled set of pieces... > > Grant Likely wrote: >> On Thu, Mar 19, 2009 at 5:59 PM, David H. Lynch Jr. wrote: >> >>>Does anyone have experience sugestions for building ppc/linux apps >>> or even ppc kernels under windows. >>> >> I hear rumors that there is a Windows version of ELDK. >> >> > > -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH -tip 4/9] power: add kernel_trap_sp()
Ananth N Mavinakayanahalli wrote: > On Fri, Mar 20, 2009 at 04:42:40PM +1100, Benjamin Herrenschmidt wrote: >> On Thu, 2009-03-19 at 17:10 -0400, Masami Hiramatsu wrote: >>> Add kernel_trap_sp() on powerpc, based on systemtap's runtime/regs.h. >>> >>> Signed-off-by: Masami Hiramatsu >> I haven't looked at the usage of it, but it's weird to have something >> call "kernel_trap_sp" that returns the -user- stack pointer... is >> this really what's expected here ? > > In the current usage scenario, this gets called only with a pt_regs > snapshot from in kernel. user_stack_pointer() is a misnomer though; > all this macro needs is to return the stack pointer from the given > pt_regs. Indeed, I expect kernel_trap_sp() returns the top of stack from pt_regs in the kernel. Why I'm using user_stack_pointer() for kernel_trap_sp() is just that the definitions of both are same... Perhaps, should I define as below, even it is same as user_stack_pointer()? #define kernel_trap_sp(regs) ((regs)->gpr[1]) Thank you, > > Ananth > -- > 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/ -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhira...@redhat.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc/86xx: Move gianfar mdio nodes under the ethernet nodes
Anton Vorontsov wrote: Currently it doesn't matter where the mdio nodes are placed, but with power management support (i.e. when sleep = <> properties will take effect), mdio nodes placement will become important: mdio controller is a part of the ethernet block, so the mdio nodes should be placed correctly. Otherwise we may wrongly assume that MDIO controllers are available during sleep. Suggested-by: Scott Wood Suggested-by: Kumar Gala Signed-off-by: Anton Vorontsov --- arch/powerpc/boot/dts/gef_ppc9a.dts| 39 --- arch/powerpc/boot/dts/gef_sbc310.dts | 39 --- arch/powerpc/boot/dts/gef_sbc610.dts | 39 --- arch/powerpc/boot/dts/mpc8641_hpcn.dts | 157 +++- arch/powerpc/boot/dts/sbc8641d.dts | 156 +++- arch/powerpc/platforms/86xx/gef_ppc9a.c|1 + arch/powerpc/platforms/86xx/gef_sbc310.c |1 + arch/powerpc/platforms/86xx/gef_sbc610.c |1 + arch/powerpc/platforms/86xx/mpc8610_hpcd.c |1 + arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |1 + arch/powerpc/platforms/86xx/sbc8641d.c |1 + 11 files changed, 237 insertions(+), 199 deletions(-) Tested on ppc9a. Other GE Fanuc boards look sane. Tested-by: Martyn Welch Martyn -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
AW: spidev.c driver on the ppc8247 (kernel 2.6.27.19)
Hi Daniel,
sorry, my example was incomplete...
for a fast you can add in your platform file something like this:
..
#ifdef CONFIG_SPI_IDS8247
#include
#include
#include
#endif
#ifdef CONFIG_SPI_IDS8247
#define GPIO_CS (224+22)
static void ids8247_spi_activate_cs(u8 cs, u8 polarity)
{
pr_debug("%s %d %d\n", __func__, cs, polarity);
//gpio_set_value(GPIO_CS, (int)polarity);
}
static void ids8247_spi_deactivate_cs(u8 cs, u8 polarity)
{
pr_debug("%s %d %d\n", __func__, cs, polarity);
//gpio_set_value(GPIO_CS, (int)(!polarity));
}
static struct mmc_spi_platform_data ids8247_mmc_pdata = {
.ocr_mask = MMC_VDD_32_33,
};
static struct spi_board_info ids8247_spi_boardinfo = {
.bus_num = 0,
.chip_select = 0,
.max_speed_hz = 2000,
.modalias = "mmc_spi",
.platform_data = &ids8247_mmc_pdata,
};
static __init int ids8247_spi_setup(void)
{
int ret = 0;
struct platform_device *spi_dev;
struct resource r[3];
struct device_node *np = NULL;
struct fsl_spi_platform_data spi_data;
/*if (!gpio_get_value(GPIO_CS))
return;
*/
if( (np = of_find_compatible_node(NULL, "spi", "platform-mapped")) ==0 )
return 0;
//fsl_get_sys_freq();
memset(&spi_data, 0, sizeof(struct fsl_spi_platform_data));
spi_data.activate_cs = ids8247_spi_activate_cs;
spi_data.deactivate_cs = ids8247_spi_deactivate_cs;
spi_data.bus_num = 0;
spi_data.max_chipselect = 1;
memset(r, 0, sizeof(struct resource)*3);
ret = of_address_to_resource(np, 0, &r[0]);
if (ret)
goto spi_err;
ret = of_address_to_resource(np, 1, &r[1]);
if (ret)
goto spi_err;
ret = of_irq_to_resource(np, 0, &r[2]);
if (ret == NO_IRQ)
goto spi_err;
spi_data.qe_mode = 0;
spi_data.sysclk = 2475;
spi_dev = platform_device_register_simple("ids8247_spi", 0, &r[0], 3);
if (IS_ERR(spi_dev)) {
ret = PTR_ERR(spi_dev);
return ret;
}
ret = platform_device_add_data(spi_dev,
&spi_data,
sizeof(struct fsl_spi_platform_data));
if(ret) {
platform_device_unregister(spi_dev);
return ret;
}
of_node_put(np);
return spi_register_board_info(&ids8247_spi_boardinfo, 1);
spi_err:
of_node_put(np);
return -1;
}
arch_initcall(ids8247_spi_setup);
#endif /* CONFIG_SPI_IDS8247 */
..
Sorry, i know it looks very dirty...
Regards
Sergej.
Von: Daniel Ng [daniel.ng1...@gmail.com]
Gesendet: Freitag, 20. März 2009 02:19
An: Stepanov, Sergej
Cc: linuxppc-dev@ozlabs.org
Betreff: Re: spidev.c driver on the ppc8247 (kernel 2.6.27.19)
On Thu, Mar 19, 2009 at 7:32 PM, Daniel Ng wrote:
>
> So, I tried to call spidev_probe() directly from the probe() function
> of my SPI Controller driver. However in this case spidev_probe()
> failed because its call to device_create_drvdata() failed with error
> code ENODEV. Why would this be?
>
> This is how I make the call from my SPI Controller driver:
>
> spidev_probe(to_spi_device(&ofdev->dev));
>
> And this is the relevant code in spidev_probe():
>
> dev = device_create_drvdata(spidev_class, &spi->dev, spidev->devt,
> spidev, "spidev%d.%d",
> /*spi->master->bus_num*/0, spi->chip_select);
It looks like spidev_class was uninitialised because spidev_init() had
not yet been called. To force spidev_init() to be called before my SPI
Controller's driver initialisation, I just used:
subsys_initcall(spidev_init);
This seems to do the job...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6] powerpc/mm: Merge various PTE bits and accessors definitions (v3)
On Fri, 2009-03-20 at 16:34 +1100, Benjamin Herrenschmidt wrote: > Index: linux-work/arch/powerpc/include/asm/pgtable-ppc64.h > === > --- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc64.h 2009-03-20 > 15:49:51.0 +1100 > +++ linux-work/arch/powerpc/include/asm/pgtable-ppc64.h 2009-03-20 > 15:52:59.0 +1100 > @@ -80,82 +80,8 @@ > * Include the PTE bits definitions > */ > #include > +#include https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc: expect all devices calling dma ops to have archdata set
* Kumar Gala | 2009-03-19 08:40:52 [-0500]: >Now that we set archdata for of_platform and platform devices via >platform_notify() we no longer need to special case having a NULL device >pointer or NULL archdata. It should be a driver error if this condition >shows up and the driver should be fixed. > >Signed-off-by: Kumar Gala Acked-by: Benjamin Krill Tested on QPACE node card. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] powerpc: setup default archdata for {of_}platform via bus_register_notifier
* Kumar Gala | 2009-03-19 08:40:51 [-0500]: >Since a number of powerpc chips are SoCs we end up having dma-able >devices that are registered as platform or of_platform devices. We need >to hook the archdata to setup proper dma_ops for these devices. > >Rather than having to add a bus_notify to each platform we add a default >one at the highest priority (called first) to set the default dma_ops for >of_platform and platform devices to dma_direct_ops. This allows platform >code to override the ops by providing their own notifier call back. > >In the future to enable >4G DMA support on ppc32 we can hook swiotlb ops. > >Signed-off-by: Kumar Gala Acked-by: Benjamin Krill Tested on QPACE node card. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
* Kumar Gala | 2009-03-19 08:40:50 [-0500]: >This will allow us to remove the ppc32 specific checks in get_dma_ops() >that defaults to dma_direct_ops if the archdata is NULL. We really >should always have archdata set to something going forward. > >Signed-off-by: Kumar Gala Acked-by: Benjamin Krill Tested on QPACE node card. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH -tip 4/9] power: add kernel_trap_sp()
On Fri, Mar 20, 2009 at 04:42:40PM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2009-03-19 at 17:10 -0400, Masami Hiramatsu wrote: > > Add kernel_trap_sp() on powerpc, based on systemtap's runtime/regs.h. > > > > Signed-off-by: Masami Hiramatsu > > I haven't looked at the usage of it, but it's weird to have something > call "kernel_trap_sp" that returns the -user- stack pointer... is > this really what's expected here ? In the current usage scenario, this gets called only with a pt_regs snapshot from in kernel. user_stack_pointer() is a misnomer though; all this macro needs is to return the stack pointer from the given pt_regs. Ananth ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
