* Re: TASK_SIZE default 0x80000000 ?
From: Benjamin Herrenschmidt @ 2007-10-07 21:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <796C20BF-1592-4F07-B83B-5EA35CADBA01@kernel.crashing.org>
> Can you explain (a) further -- I'm assuming the BAT mapping is 1:1
> for that region?
>
> For (b) it looks like:
> * 40x, 44x, fsl-booke compare against TASK_SIZE in their software
> handlers.
> * 8xx still tests 0x80000000
> * 6xx (603) compares against KERNELBASE
>
> It would seem like we should set the default on 8xx & PReP to
> 0x80000000 and not allow it to be modified since that will break the
> world and for everything else move it to match KERNELBASE. Any
> issues with that?
The proper value is neither :-)
It should be compared against PAGE_OFFSET.
Ben.
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Scott Wood @ 2007-10-08 1:31 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071005210320.GE6663@mag.az.mvista.com>
Mark A. Greer wrote:
> Why? Because its only safe to download a zImage to certain "safe" locations.
> Where those "safe" locations are vary by firmware, firmware version, and
> zImage size. This is the issue we're discussing.
In theory, yes -- but in practice the odds of this particular heuristic
choosing an unsuitable address seem slim.
> I've already explained _why_ the link address matters WRT where its downloaded.
Sorry, I was being a bit too pendantic with respect to the distinction
between link and load address.
>>> Also, being able to control the link address (that is, the download
>>> address with some firmwares) is not a u-boot specific issue and we
>>> shouldn't make a u-boot specific solution.
>> How is this a u-boot specific solution?
>
> Because the hoops being jumped through in the patch(es) are to make
> u-boot happy and no other firmware.
No, the "hoops" (which I don't think are sufficiently complicated to
warrant such a name) are to address a generic issue with the bootwrapper
-- it wants to put the kernel at zero. It'd be really nice if, in the
absense of a vmlinux_alloc method, the generic code would do an ordinary
malloc() if there's not enough room at zero.
>> I'd much rather it be automatic than require the user to guess an
>> appropriate value (and be aware in the first place that it needs to be set).
>
> Sure, automatic is nice; conjuring up the magic to make it work in all
> situations isn't.
I think this heuristic would work in most situations, so if we do add a
manual override it should be an override, and not something that
everybody has to put up with.
> Having the link address--and therefore the download address on some
> systems--mysteriously and uncontrollably jump around based on the zImage
> size is asking for trouble.
It's a source of potential issues, but I think "asking for trouble" is
exaggerating somewhat.
-Scott
^ permalink raw reply
* Re: [PATCH 04/15] [POWERPC] CM5200 DTS
From: David Gibson @ 2007-10-08 1:50 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C112.9020506@semihalf.com>
On Sun, Oct 07, 2007 at 01:20:50PM +0200, Marian Balakowicz wrote:
>
> Add device tree source file for CM5200 board.
>
> Signed-off-by Marian Balakowicz <m8@semihalf.com>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
> ---
>
> cm5200.dts | 284 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 284 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
> new file mode 100644
> index 0000000..96d2ee4
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/cm5200.dts
> @@ -0,0 +1,284 @@
> +/*
> + * CM5200 board Device Tree Source
> + *
> + * Copyright (C) 2007 Semihalf
> + * Modified for CM5200 by Jan Wrobel <wrr@semihalf.com>
> + *
> + * Copyright 2006-2007 Secret Lab Technologies Ltd.
> + * Grant Likely <grant.likely@secretlab.ca>
> + *
> + * 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.
> + */
> +
> +/*
> + * WARNING: Do not depend on this tree layout remaining static just yet.
> + * The MPC5200 device tree conventions are still in flux
> + * Keep an eye on the linuxppc-dev mailing list for more details
> + */
> +
> +/ {
> + model = "cm5200";
> + compatible = "fsl,cm5200\0generic-mpc5200";
dtc now supports the syntax "fsl,cm5200", "generic-mpc5200" so you
don't need the ugly inline \0.
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,5200@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>;
> + i-cache-line-size = <20>;
> + d-cache-size = <4000>; // L1, 16K
> + i-cache-size = <4000>; // L1, 16K
> + timebase-frequency = <0>; // from bootloader
> + bus-frequency = <0>; // from bootloader
> + clock-frequency = <0>; // from bootloader
> + 32-bit;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <00000000 04000000>; // 64MB
> + };
> +
> + soc5200@f0000000 {
> + model = "fsl,mpc5200b";
> + compatible = "mpc5200";
> + revision = ""; // from bootloader
> + #interrupt-cells = <3>;
> + device_type = "soc";
> + ranges = <0 f0000000 f0010000>;
> + reg = <f0000000 00010000>;
> + bus-frequency = <0>; // from bootloader
> + system-frequency = <0>; // from bootloader
[snip]
> + flash@c000000 {
> + device_type = "rom";
> + compatible = "direct-mapped";
> + reg = <0c000000 02000000>;
> + probe-type = "CFI";
> + bank-width = <2>;
> + partitions = <00000000 00060000
> + 00060000 00020000
> + 00080000 00020000
> + 000a0000 00020000
> + 000c0000 00200000
> + 002c0000 01b40000
> + 01e00000 00200000>;
> + partition-names = "uboot\0env\0redund_env\0dtb\0kernel\0rootfs\0config";
> + };
First, this is the old flash binding, please use the new one.
Second, is the flash really part of the SoC?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 07/15] [POWERPC] Promess Motion-PRO DTS
From: David Gibson @ 2007-10-08 1:53 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C22D.5060805@semihalf.com>
On Sun, Oct 07, 2007 at 01:25:33PM +0200, Marian Balakowicz wrote:
>
> Add device tree source file for Motion-PRO board.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> ---
>
> motionpro.dts | 334 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 334 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
> new file mode 100644
> index 0000000..4b197c8
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/motionpro.dts
> @@ -0,0 +1,334 @@
> +/*
> + * Motion-PRO board Device Tree Source, based on Lite5200B DTS.
> + *
> + * Copyright (C) 2007 Semihalf
> + * Modified for CM5200 by Marian Balakowicz <m8@semihalf.com>
> + *
> + * Copyright 2006-2007 Secret Lab Technologies Ltd.
> + * Grant Likely <grant.likely@secretlab.ca>
> + *
> + * Copyright (C) 2007 DENX Software Engineering
> + *
> + * 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.
> + */
> +
> +/*
> + * WARNING: Do not depend on this tree layout remaining static just yet.
> + * The MPC5200 device tree conventions are still in flux
> + * Keep an eye on the linuxppc-dev mailing list for more details
> + */
> +
> +/ {
[snip]
> + kollmorgen {
> + device_type = "kollmorgen";
> + compatible = "kollmorgen";
> + reg = <50000000 ffff>;
> + interrupts = <1 1 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> + cpld {
> + device_type = "cpld";
> + compatible = "cpld";
> + reg = <50010000 ffff>;
> + };
> + anybus {
> + device_type = "anybus";
> + compatible = "anybus";
> + reg = <50020000 ffff>;
> + };
> + pro_module_general {
> + device_type = "pro_module_general";
> + compatible = "pro_module_general";
> + reg = <50020000 3>;
> + };
> + pro_module_dio {
> + device_type = "pro_module_dio";
> + compatible = "pro_module_dio";
> + reg = <50020800 2>;
> + };
Surely there must be some sort of bus controller above these devices..?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Nish Aravamudan @ 2007-10-08 3:47 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071005160322.GN4338@austin.ibm.com>
On 10/5/07, Linas Vepstas <linas@austin.ibm.com> wrote:
> On Thu, Oct 04, 2007 at 05:01:47PM -0700, Nish Aravamudan wrote:
> > On 10/2/07, Tony Breeds <tony@bakeyournoodle.com> wrote:
> > > On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
> > >
> > > > I realise it'll make the patch bigger, but this doesn't seem like a
> > > > particularly good name for the variable anymore.
> > >
> > > Sure, what about?
> > >
> > > Clarify when RTAS logging is enabled.
> > >
> > > Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> >
> > For what it's worth, on a different ppc64 box, this resolves a similar
> > panic for me.
> >
> > Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
>
> For the reasons explained, I'd really like to nack Tony's patch.
I see. Can you reply in this thread with the patch you mentioned in
your other reply? (or point me to a copy of it)
Thanks,
Nish
^ permalink raw reply
* Re: include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
From: Misbah khan @ 2007-10-08 4:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4705691A.9020509@freescale.com>
Timur Tabi-3 wrote:
>
> Kumar, this is what I get when I compile your 2.6.24 branch for the 8610:
>
> CC arch/powerpc/sysdev/fsl_soc.o
> In file included from arch/powerpc/sysdev/fsl_soc.c:40:
> include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
> make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
> make: *** [arch/powerpc/sysdev] Error 2
>
> I guess the file /asm/cpm2.h is not present in the kernel source , You
> need to go through the source and see what asm file is being provided for
> you to access the communication processor specific register (i assume you
> are accessing/assigning to processor register)
>
> Commenting out the "#include <asm/cpm.h>" in cpm2.h makes the compilation
> failure go away, but I don't know if that's the proper fix, since the 8610
> doesn't have a CPM.
>
> Are u including #include <asm/cpm.h> or <asm/cpm2.h> ???????
>
> Processor registers are memory mapped and you can access it directly by
> including proper asm file ,and writing to the structure element of the
> file by using Pointer to comm processor
>
> If you could let me know what is the operation that you need to perform on
> comm process register and which register you need to access then i could
> be in better position to help you
>
> Misbah
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/include-asm-cpm2.h%3A14%3A21%3A-error%3A-asm-cpm.h%3A-No-such-file-or-directory-tf4571911.html#a13090379
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Where are inb/outb macros?
From: Misbah khan @ 2007-10-08 6:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200710070146.51140.arnd@arndb.de>
inb/outb could be used from the usr space on x86 class PC-computer to access
to io ports this is what i assume that you are trying
You need to compile the program with -O option (expantion of Inline function
)
To perform io operation on ports ioprem/iopl system call must be used (To
get permissio to perform io operation)
Program must run as root
on non 86 platform try using /dev/port device file in the application
misbah
Arnd Bergmann wrote:
>
> On Saturday 06 October 2007, Benjamin Herrenschmidt wrote:
>> On Sun, 2007-10-07 at 00:47 +0400, Peter Lemenkov wrote:
>> > Hello All!
>> > I can't compile one small software title because of lack <sys/io.h>
>> > and inb/outb macros. What sould I do to overcome this obstacle?
>> >
>> > My linux distro is Fedora 7 if it is matter.
>>
>> They don't exist in user space on non-x86. You have to do things
>> differently. What is your software trying to do ? If it's trying to
>> access a PCI device IO space, you probably want to mmap it in sysfs and
>> write your own accessors with appropriate memory barriers.
>
> All cases where I've seen application software use <sys/io.h>, there was
> actually a full device driver in the kernel that already exported a
> high-level interface to user space. If that's the case here, the
> application
> should use that instead of sysfs.
>
> Arnd <><
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/Where-are-inb-outb-macros--tf4581135.html#a13091078
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Grant Likely @ 2007-10-08 6:21 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C0DA.2040606@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add arch/powerpc board support for TQM5200.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
Hmmm....
Both this patch and the CM5200 support patch (#6 in your series) are
pretty much clones of lite5200.c. I don't think this is the right
approach. Don't duplicate code in this way. Determine the common
bits and put them in a common place to be usable by any 5200 board
port.
It might even be better just to add a platform that matches on
compatible='mpc5200-generic' which is usable for mpc5200 boards that
don't need any custom setup by the kernel at platform setup time.
(which will probably be most 5200 boards).
More comments below. (And, yes, I realize that all these comments
also apply to lite5200.c).
> ---
>
> Kconfig | 5 +
> Makefile | 1
> tqm5200.c | 174 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 180 insertions(+)
>
> diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
> index 3ffaa06..7c828eb 100644
> --- a/arch/powerpc/platforms/52xx/Kconfig
> +++ b/arch/powerpc/platforms/52xx/Kconfig
> @@ -33,4 +33,9 @@ config PPC_LITE5200
> select PPC_MPC5200
> default n
>
> +config PPC_TQM5200
> + bool "TQM5200 Board"
> + depends on PPC_MULTIPLATFORM && PPC32
Hmmm; it's looking like every 52xx board is adding this boilerplate
"depends" line... That's probably sub-optimal. (More a general
thought than a comment on your patch)
> + select PPC_MPC5200
> + default n
>
> diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
> index b91e39c..4997ebf 100644
> --- a/arch/powerpc/platforms/52xx/Makefile
> +++ b/arch/powerpc/platforms/52xx/Makefile
> @@ -8,5 +8,6 @@ endif
>
> obj-$(CONFIG_PPC_EFIKA) += efika.o
> obj-$(CONFIG_PPC_LITE5200) += lite5200.o
> +obj-$(CONFIG_PPC_TQM5200) += tqm5200.o
>
> obj-$(CONFIG_PM) += mpc52xx_sleep.o mpc52xx_pm.o
> diff --git a/arch/powerpc/platforms/52xx/tqm5200.c b/arch/powerpc/platforms/52xx/tqm5200.c
> new file mode 100644
> index 0000000..780b79f
> --- /dev/null
> +++ b/arch/powerpc/platforms/52xx/tqm5200.c
> @@ -0,0 +1,174 @@
> +/*
> + * TQM5200 board support
> + *
> + * Written by: Grant Likely <grant.likely@secretlab.ca> for lite5200
> + * Adapted for tqm5200 by: Jan Wrobel <wrr@semihalf.com>
> + *
> + * Copyright (C) Secret Lab Technologies Ltd. 2006. All rights reserved.
> + * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
> + *
> + * Description:
> + * 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.
> + */
> +
> +#undef DEBUG
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/reboot.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/major.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +#include <linux/root_dev.h>
> +#include <linux/initrd.h>
> +
> +#include <asm/system.h>
> +#include <asm/atomic.h>
> +#include <asm/time.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/ipic.h>
> +#include <asm/bootinfo.h>
> +#include <asm/irq.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <sysdev/fsl_soc.h>
> +#include <asm/of_platform.h>
> +
> +#include <asm/mpc52xx.h>
> +
> +/* ************************************************************************
> + *
> + * Setup the architecture
> + *
> + */
> +static void __init
> +tqm5200_setup_cpu(void)
> +{
> + struct mpc52xx_gpio __iomem *gpio;
> + u32 port_config;
> +
> + /* Map zones */
> + gpio = mpc52xx_find_and_map("mpc5200-gpio");
> + if (!gpio) {
> + printk(KERN_ERR __FILE__ ": "
> + "Error while mapping GPIO register for port config. "
> + "Expect some abnormal behavior\n");
> + goto error;
> + }
> +
> + /* Set port config */
> + port_config = in_be32(&gpio->port_config);
> +
> + port_config &= ~0x00800000; /* 48Mhz internal, pin is GPIO */
> +
> + port_config &= ~0x00007000; /* USB port : Differential mode */
> + port_config |= 0x00001000; /* USB 1 only */
> +
> + port_config &= ~0x03000000; /* ATA CS is on csb_4/5 */
> + port_config |= 0x01000000;
Are you *sure* you want this? You should only be touching port_config
if firmware fails to set it up correctly. Don't blindly copy what was
done for the lite5200.
Lite5200 touches it because firmware does *not* do the right thing at
the moment.
> +
> + pr_debug("port_config: old:%x new:%x\n",
> + in_be32(&gpio->port_config), port_config);
> + out_be32(&gpio->port_config, port_config);
> +
> + /* Unmap zone */
> +error:
> + iounmap(gpio);
> +}
> +
> +static void __init tqm5200_setup_arch(void)
> +{
> + struct device_node *np;
> +
> + if (ppc_md.progress)
> + ppc_md.progress("tqm5200_setup_arch()", 0);
> +
> + np = of_find_node_by_type(NULL, "cpu");
> + if (np) {
> + unsigned int *fp =
> + (int *)of_get_property(np, "clock-frequency", NULL);
Unnecessary cast, and add 'const' to 'fp' declaration.
> + if (fp != 0)
Use NULL instead of 0 for pointer tests. 'if (fp)' is also good style here.
> + loops_per_jiffy = *fp / HZ;
> + else
> + loops_per_jiffy = 50000000 / HZ;
> + of_node_put(np);
> + }
> +
> + /* CPU & Port mux setup */
> + mpc52xx_setup_cpu();
> + tqm5200_setup_cpu();
> +
> +#ifdef CONFIG_PCI
> + np = of_find_node_by_type(NULL, "pci");
> + if (np) {
> + mpc52xx_add_bridge(np);
> + of_node_put(np);
> + }
> +#endif
> +
> +#ifdef CONFIG_BLK_DEV_INITRD
> + if (initrd_start)
> + /*
> + * We want the proper initrd behavior, i.e., launching of
> + * /linuxrc from the initial root file system, and not only
> + * mounting it as the normal root file system.
> + */
> + ROOT_DEV = 0x0;
> + else
> +#endif
> +#ifdef CONFIG_ROOT_NFS
> + ROOT_DEV = Root_NFS;
> +#else
> + ROOT_DEV = Root_HDA1;
> +#endif
Drop all this ROOT_DEV code. It's brain damaged.
> +
> +}
> +
> +void tqm5200_show_cpuinfo(struct seq_file *m)
> +{
> + struct device_node* np = of_find_all_nodes(NULL);
> + const char *model = NULL;
> +
> + if (np)
> + model = of_get_property(np, "model", NULL);
> +
> + seq_printf(m, "vendor\t\t: Freescale Semiconductor\n");
Freescale? Really?
> + seq_printf(m, "machine\t\t: %s\n", model ? model : "unknown");
> +
> + of_node_put(np);
> +}
> +
> +/*
> + * Called very early, MMU is off, device-tree isn't unflattened
> + */
> +static int __init tqm5200_probe(void)
> +{
> + unsigned long node = of_get_flat_dt_root();
> + const char *model = of_get_flat_dt_prop(node, "model", NULL);
> +
> + if (!of_flat_dt_is_compatible(node, "fsl,tqm5200"))
> + return 0;
> + pr_debug("%s board found\n", model ? model : "unknown");
Drop the pr_debug line and the setting of 'model' above. The platform
setup call prints out the name of the platform regardless.
> +
> + return 1;
> +}
> +
> +define_machine(tqm5200) {
> + .name = "tqm5200",
> + .probe = tqm5200_probe,
> + .setup_arch = tqm5200_setup_arch,
> + .init = mpc52xx_declare_of_platform_devices,
> + .init_IRQ = mpc52xx_init_irq,
> + .get_irq = mpc52xx_get_irq,
> + .show_cpuinfo = tqm5200_show_cpuinfo,
> + .calibrate_decr = generic_calibrate_decr,
> +};
>
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 01/15] [POWERPC] TQM5200 DTS
From: Grant Likely @ 2007-10-08 6:27 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708BFDD.9020900@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
> +
> + pci@0d00 {
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> + compatible = "mpc5200-pci";
> + reg = <d00 100>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3
> + c000 0 0 2 &mpc5200_pic 0 0 3
> + c000 0 0 3 &mpc5200_pic 0 0 3
> + c000 0 0 4 &mpc5200_pic 0 0 3>;
> + clock-frequency = <0>; // From boot loader
> + interrupts = <2 8 0 2 9 0 2 a 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + bus-range = <0 0>;
> + ranges = <42000000 0 80000000 80000000 0 10000000
> + 02000000 0 90000000 90000000 0 10000000
> + 01000000 0 00000000 a0000000 0 01000000>;
> + };
Also, the PCI node should no longer be a child of the 'soc' node. See
the latest lite5200.dts file in Paul Mackerras' powerpc tree for an
example.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 06/15] [POWERPC] CM5200 board support
From: Grant Likely @ 2007-10-08 6:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <20071007222930.a5b03174.sfr@canb.auug.org.au>
On 10/7/07, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Sun, 07 Oct 2007 13:24:18 +0200 Marian Balakowicz <m8@semihalf.com> wrote:
> >
> > +++ b/arch/powerpc/platforms/52xx/cm5200.c
> >
> > +#include <asm/prom.h>
> > +#include <asm/of_platform.h>
>
> Same comments as for tqm5200.c.
Ditto
g.
^ permalink raw reply
* Re: [PATCH 07/15] [POWERPC] Promess Motion-PRO DTS
From: Grant Likely @ 2007-10-08 6:44 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C22D.5060805@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add device tree source file for Motion-PRO board.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> ---
>
> motionpro.dts | 334 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 334 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
> new file mode 100644
> index 0000000..4b197c8
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/motionpro.dts
> @@ -0,0 +1,334 @@
> +/*
> + * Motion-PRO board Device Tree Source, based on Lite5200B DTS.
> + *
> + * Copyright (C) 2007 Semihalf
> + * Modified for CM5200 by Marian Balakowicz <m8@semihalf.com>
> + *
> + * Copyright 2006-2007 Secret Lab Technologies Ltd.
> + * Grant Likely <grant.likely@secretlab.ca>
> + *
> + * Copyright (C) 2007 DENX Software Engineering
> + *
> + * 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.
> + */
> +
> +/*
> + * WARNING: Do not depend on this tree layout remaining static just yet.
> + * The MPC5200 device tree conventions are still in flux
> + * Keep an eye on the linuxppc-dev mailing list for more details
> + */
> +
> +/ {
> + model = "fsl,motionpro";
> + // revision = "1.0";
> + compatible = "fsl,motionpro\0generic-mpc5200";
Not 'fsl,'
> + pci@0d00 {
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> + compatible = "mpc5200b-pci\0mpc5200-pci";
> + reg = <d00 100>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
> + c000 0 0 2 &mpc5200_pic 1 1 3
> + c000 0 0 3 &mpc5200_pic 1 2 3
> + c000 0 0 4 &mpc5200_pic 1 3 3
> +
> + c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
> + c800 0 0 2 &mpc5200_pic 1 2 3
> + c800 0 0 3 &mpc5200_pic 1 3 3
> + c800 0 0 4 &mpc5200_pic 0 0 3>;
> + clock-frequency = <0>; // From boot loader
> + interrupts = <2 8 0 2 9 0 2 a 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + bus-range = <0 0>;
> + ranges = <42000000 0 80000000 80000000 0 20000000
> + 02000000 0 a0000000 a0000000 0 10000000
> + 01000000 0 00000000 b0000000 0 01000000>;
> + };
PCI should no longer be a child of the soc node.
> +
> + spi@f00 {
> + device_type = "spi";
> + compatible = "mpc5200b-spi\0mpc5200-spi";
> + reg = <f00 20>;
> + interrupts = <2 d 0 2 e 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + usb@1000 {
> + device_type = "usb-ohci-be";
> + compatible = "mpc5200b-ohci\0mpc5200-ohci\0ohci-be";
> + reg = <1000 ff>;
> + interrupts = <2 6 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + bestcomm@1200 {
> + device_type = "dma-controller";
> + compatible = "mpc5200b-bestcomm\0mpc5200-bestcomm";
> + reg = <1200 80>;
> + interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> + 3 4 0 3 5 0 3 6 0 3 7 0
> + 3 8 0 3 9 0 3 a 0 3 b 0
> + 3 c 0 3 d 0 3 e 0 3 f 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + xlb@1f00 {
> + compatible = "mpc5200b-xlb\0mpc5200-xlb";
> + reg = <1f00 100>;
> + };
> +
> + serial@2000 { // PSC1
> + device_type = "serial";
> + compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
> + port-number = <0>; // Logical port assignment
> + cell-index = <0>;
> + reg = <2000 100>;
> + interrupts = <2 1 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + // PSC2 in spi master mode
> + spi@2200 { // PSC2
> + device_type = "spi";
> + compatible = "mpc5200b-psc-spi\0mpc5200-psc-spi";
> + cell-index = <1>;
> + reg = <2200 100>;
> + interrupts = <2 2 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + // PSC5 in uart mode example
Not an example if it is uncommented, change your comment.
> + serial@2800 { // PSC5
> + device_type = "serial";
> + compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
> + port-number = <4>; // Logical port assignment
> + cell-index = <4>;
> + reg = <2800 100>;
> + interrupts = <2 c 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + ethernet@3000 {
> + device_type = "network";
> + compatible = "mpc5200b-fec\0mpc5200-fec";
> + reg = <3000 800>;
> + mac-address = [ 02 03 04 05 06 07 ]; // Bad!
I really should fix this in the lite5200 device tree.
> + interrupts = <2 5 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + ata@3a00 {
> + device_type = "ata";
> + compatible = "mpc5200b-ata\0mpc5200-ata";
> + reg = <3a00 100>;
> + interrupts = <2 7 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + i2c@3d40 {
> + device_type = "i2c";
> + compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
> + cell-index = <1>;
> + reg = <3d40 40>;
> + interrupts = <2 10 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + fsl5200-clocking;
> + };
> + sram@8000 {
> + device_type = "sram";
> + compatible = "mpc5200b-sram\0mpc5200-sram\0sram";
> + reg = <8000 4000>;
> + };
> +
> + };
> + kollmorgen {
> + device_type = "kollmorgen";
> + compatible = "kollmorgen";
> + reg = <50000000 ffff>;
> + interrupts = <1 1 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> + cpld {
> + device_type = "cpld";
> + compatible = "cpld";
> + reg = <50010000 ffff>;
> + };
> + anybus {
> + device_type = "anybus";
> + compatible = "anybus";
> + reg = <50020000 ffff>;
> + };
> + pro_module_general {
> + device_type = "pro_module_general";
> + compatible = "pro_module_general";
compatible properties should use '<manufacturer>,' prefixes.
> + reg = <50020000 3>;
> + };
> + pro_module_dio {
> + device_type = "pro_module_dio";
> + compatible = "pro_module_dio";
> + reg = <50020800 2>;
> + };
So; what are 'kollmogens', 'anybusses' and 'pro_modules'? This stuff
have some documentation attached to it. If these are devices which
are only on this board; then I think you can just add comments about
each node to describe them. If they are devices which will appear on
other boards, you should describe them in
Documentation/powerpc/booting-without-of.txt.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 09/15] [POWERPC] Promess Motion-PRO board support
From: Grant Likely @ 2007-10-08 6:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <20071007223219.932e3f8a.sfr@canb.auug.org.au>
On 10/7/07, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Sun, 07 Oct 2007 13:28:48 +0200 Marian Balakowicz <m8@semihalf.com> wrote:
> >
> > +++ b/arch/powerpc/platforms/52xx/motionpro.c
>
> Same comments again.
Ditto.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 10/15] [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions.
From: Grant Likely @ 2007-10-08 6:47 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C343.30104@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add helper routine mpc52xx_find_and_map_path(). Extract common code to
> mpc52xx_map_node() and refactor mpc52xx_find_and_map().
>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
Looks good to me.
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* howto hibernate (suspend-to-disk) G4 PowerBook Titanium IV
From: Lixus Zoran @ 2007-10-08 7:08 UTC (permalink / raw)
To: Linuxppc-dev
Hello,
I own a Titanium PowerBook with a G4 processor.
It runs Ubuntu dapper 6.06 LTS.
Suspend to RAM works fine with pbbuttonsd.
But I would like to have hibernate (suspend-to-disk) working.
But if I replace "suspend-to-ram" by "suspend-to-disk" in
/etc/pbbuttonsd.conf and close the lid then it just blanks the screen,
even if X is not running.
I found a lot of approaches howto possible hibernate,
a) swsuspend http://suspend.sf.net
b) Suspend2 (this only works on i368 ?)
c) pbbuttonsd ?
d) uswsusp
e) pmdisk
but where should I put my effords in ?
TIA, Lixus
# cat /proc/cpuinfo
processor : 0
cpu : 7455, altivec supported
clock : 667.000000MHz
revision : 0.2 (pvr 8001 0302)
bogomips : 66.56
timebase : 33331380
machine : PowerBook3,5
motherboard : PowerBook3,5 MacRISC2 MacRISC Power Macintosh
detected as : 80 (PowerBook Titanium IV)
pmac flags : 0000001b
L2 cache : 256K unified
pmac-generation : NewWorld
^ permalink raw reply
* Re: [PATCH 11/15] [POWERPC] Motion-PRO: Add LED support.
From: Grant Likely @ 2007-10-08 7:10 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C380.3070707@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add LED driver for Promess Motion-PRO board.
>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
> ---
>
> arch/powerpc/configs/motionpro_defconfig | 3
> arch/powerpc/platforms/52xx/motionpro.c | 38 +++++
> drivers/leds/Kconfig | 7
> drivers/leds/Makefile | 1
> drivers/leds/leds-motionpro.c | 221 +++++++++++++++++++++++++++++++
> include/asm-powerpc/mpc52xx.h | 5
> 6 files changed, 274 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/configs/motionpro_defconfig b/arch/powerpc/configs/motionpro_defconfig
> index fcce47e..ce62123 100644
> --- a/arch/powerpc/configs/motionpro_defconfig
> +++ b/arch/powerpc/configs/motionpro_defconfig
> @@ -1,7 +1,7 @@
> #
> # Automatically generated make config: don't edit
> # Linux kernel version: 2.6.23-rc9
> -# Fri Oct 5 12:54:17 2007
> +# Fri Oct 5 15:18:42 2007
> #
> # CONFIG_PPC64 is not set
>
> @@ -610,6 +610,7 @@ CONFIG_LEDS_CLASS=y
> #
> # LED drivers
> #
> +CONFIG_LEDS_MOTIONPRO=y
>
> #
> # LED Triggers
> diff --git a/arch/powerpc/platforms/52xx/motionpro.c b/arch/powerpc/platforms/52xx/motionpro.c
> index 2cf8a47..c1bcfd2 100644
> --- a/arch/powerpc/platforms/52xx/motionpro.c
> +++ b/arch/powerpc/platforms/52xx/motionpro.c
> @@ -86,10 +86,48 @@ error:
> iounmap(gpio);
> }
>
> +
> +#ifdef CONFIG_LEDS_MOTIONPRO
> +
> +/* Initialize GPT register connected to LED. Turn off LED. */
> +static void motionpro_setup_led(const char *reg_path)
> +{
> + void __iomem *reg_addr;
> + u32 reg;
> +
> + reg_addr = mpc52xx_find_and_map_path(reg_path);
> + if (!reg_addr){
> + printk(KERN_ERR __FILE__ ": "
> + "LED setup error: can't map GPIO register %s\n",
> + reg_path);
> + return;
> + }
> +
> + reg = in_be32(reg_addr);
> + reg |= MPC52xx_GPT_ENABLE_OUTPUT;
> + reg &= ~MPC52xx_GPT_OUTPUT_1;
> + out_be32(reg_addr, reg);
Ideally, firmware should be doing this setup. Only do it here if
firmware cannot be updated to set these pins correctly.
> +
> + iounmap(reg_addr);
> +}
> +
> +/* Initialize Motionpro status and ready LEDs */
> +static void motionpro_setup_leds(void)
> +{
> + motionpro_setup_led("/soc5200@f0000000/gpt@660");
> + motionpro_setup_led("/soc5200@f0000000/gpt@670");
> +}
> +
> +#endif
> +
> static void __init motionpro_setup_arch(void)
> {
> struct device_node *np;
>
> +#ifdef CONFIG_LEDS_MOTIONPRO
> + motionpro_setup_leds();
> +#endif
Don't bother making this conditional (Unless the LED GPIO pins can
also have another function). This is a fixed property of the board,
so just set it up unconditionally.
> +
> if (ppc_md.progress)
> ppc_md.progress("motionpro_setup_arch()", 0);
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 4468cb3..f027009 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -55,6 +55,13 @@ config LEDS_TOSA
> This option enables support for the LEDs on Sharp Zaurus
> SL-6000 series.
>
> +config LEDS_MOTIONPRO
> + tristate "Motionpro LEDs Support"
> + depends on LEDS_CLASS
> + help
> + This option enables support for status and ready LEDs connected
> + to GPIO lines on Motionpro board.
> +
> config LEDS_S3C24XX
> tristate "LED Support for Samsung S3C24XX GPIO LEDs"
> depends on LEDS_CLASS && ARCH_S3C2410
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index f8995c9..6b45be1 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_LEDS_NET48XX) += leds-net48xx.o
> obj-$(CONFIG_LEDS_WRAP) += leds-wrap.o
> obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
> obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
> +obj-$(CONFIG_LEDS_MOTIONPRO) += leds-motionpro.o
> obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
>
> # LED Triggers
> diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
> new file mode 100644
> index 0000000..273e375
> --- /dev/null
> +++ b/drivers/leds/leds-motionpro.c
> @@ -0,0 +1,221 @@
> +/*
> + * LEDs driver for the Motionpro board.
> + *
> + * Copyright (C) 2007 Semihalf
> + *
> + * Author: Jan Wrobel <wrr@semihalf.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * 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., 51
> + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> + *
> + *
> + * This driver enables control over Motionpro's status and ready LEDs through
> + * sysfs. LEDs can be controlled by writing to sysfs files:
> + * class/leds/motionpro-(ready|status)led/(brightness|delay_off|delay_on).
> + * See Documentation/leds-class.txt for more details
> + *
> + * Before user issues first control command via sysfs, LED blinking is
> + * controlled by the kernel. By default status LED is blinking fast and ready
> + * LED is turned off.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/leds.h>
> +
> +#include <asm/mpc52xx.h>
> +#include <asm/io.h>
> +
> +/* Led status */
> +#define LED_NOT_REGISTERED 0
> +#define LED_KERNEL_CONTROLLED 1
> +#define LED_USER_CONTROLLED 2
> +
> +
> +/* Led control bits */
> +#define LED_ON MPC52xx_GPT_OUTPUT_1
> +
> +static void mpled_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness);
> +
> +static struct motionpro_led{
> + /* Protects the led data */
> + spinlock_t led_lock;
> +
> + /* Path to led's control register DTS node */
> + char *reg_path;
> +
> + /* Address to access led's register */
> + void __iomem *reg_addr;
> +
> + int status;
> +
> + /* Blinking timer used when led is controlled by the kernel */
> + struct timer_list kernel_mode_timer;
> +
> + /*
> + * Delay between blinks when led is controlled by the kernel.
> + * If set to 0 led blinking is off.
> + */
> + int kernel_mode_delay;
> +
> + struct led_classdev classdev;
> +}led[] = {
Split the structure definition and the table declaration. Easier to
follow if it is split.
> + {
> + .reg_path = "/soc5200@f0000000/gpt@660",
> + .reg_addr = 0,
> + .led_lock = SPIN_LOCK_UNLOCKED,
> + .status = LED_NOT_REGISTERED,
> + .kernel_mode_delay = HZ / 10,
> + .classdev = {
> + .name = "motionpro-statusled",
> + .brightness_set = mpled_set,
> + .default_trigger = "timer",
> + },
> + },
> + {
> + .reg_path = "/soc5200@f0000000/gpt@670",
> + .reg_addr = 0,
> + .led_lock = SPIN_LOCK_UNLOCKED,
> + .status = LED_NOT_REGISTERED,
> + .kernel_mode_delay = 0,
> + .classdev = {
> + .name = "motionpro-readyled",
> + .brightness_set = mpled_set,
> + .default_trigger = "timer",
> + }
> + }
> +};
> +
> +/* Timer event - blinks led before user takes control over it */
> +static void mpled_timer_toggle(unsigned long ptr)
> +{
> + struct motionpro_led *mled = (struct motionpro_led *) ptr;
> +
> + spin_lock_bh(&mled->led_lock);
> + if (mled->status == LED_KERNEL_CONTROLLED){
> + u32 reg = in_be32(mled->reg_addr);
> + reg ^= LED_ON;
> + out_be32(mled->reg_addr, reg);
> + led->kernel_mode_timer.expires = jiffies +
> + led->kernel_mode_delay;
> + add_timer(&led->kernel_mode_timer);
> + }
> + spin_unlock_bh(&mled->led_lock);
> +}
> +
> +
> +/*
> + * Turn on/off led according to user settings in sysfs.
> + * First call to this function disables kernel blinking.
> + */
> +static void mpled_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + struct motionpro_led *mled;
> + u32 reg;
> +
> + mled = container_of(led_cdev, struct motionpro_led, classdev);
> +
> + spin_lock_bh(&mled->led_lock);
> + mled->status = LED_USER_CONTROLLED;
> +
> + reg = in_be32(mled->reg_addr);
> + if (brightness)
> + reg |= LED_ON;
> + else
> + reg &= ~LED_ON;
> + out_be32(mled->reg_addr, reg);
> +
> + spin_unlock_bh(&mled->led_lock);
> +}
> +
> +static void mpled_init_led(void __iomem *reg_addr)
> +{
> + u32 reg = in_be32(reg_addr);
> + reg |= MPC52xx_GPT_ENABLE_OUTPUT;
> + reg &= ~LED_ON;
> + out_be32(reg_addr, reg);
> +}
> +
> +static void mpled_clean(void)
> +{
> + int i;
> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
> + if (led[i].status != LED_NOT_REGISTERED){
> + spin_lock_bh(&led[i].led_lock);
> + led[i].status = LED_NOT_REGISTERED;
> + spin_unlock_bh(&led[i].led_lock);
> + led_classdev_unregister(&led[i].classdev);
> + }
> + if (led[i].reg_addr){
> + iounmap(led[i].reg_addr);
> + led[i].reg_addr = 0;
> + }
> + }
> +}
> +
> +static int __init mpled_init(void)
> +{
> + int i, error;
> +
> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
> + led[i].reg_addr = mpc52xx_find_and_map_path(led[i].reg_path);
> + if (!led[i].reg_addr){
> + printk(KERN_ERR __FILE__ ": "
> + "Error while mapping GPIO register for LED %s\n",
> + led[i].classdev.name);
> + error = -EIO;
> + goto err;
> + }
> +
> + mpled_init_led(led[i].reg_addr);
> + led[i].status = LED_KERNEL_CONTROLLED;
> + if (led[i].kernel_mode_delay){
> + init_timer(&led[i].kernel_mode_timer);
> + led[i].kernel_mode_timer.function = mpled_timer_toggle;
> + led[i].kernel_mode_timer.data = (unsigned long)&led[i];
> + led[i].kernel_mode_timer.expires =
> + jiffies + led[i].kernel_mode_delay;
> + add_timer(&led[i].kernel_mode_timer);
> + }
> +
> + if ((error = led_classdev_register(NULL, &led[i].classdev)) < 0){
> + printk(KERN_ERR __FILE__ ": "
> + "Error while registering class device for LED "
> + "%s\n",
> + led[i].classdev.name);
> + goto err;
> + }
> + }
> +
> + printk("Motionpro LEDs driver initialized\n");
> + return 0;
> +err:
> + mpled_clean();
> + return error;
> +}
What happens when a kernel is built with support for this board and
another platform? It looks like this init code tries to setup the
LEDs unconditionally.
You might be better off renaming the gpt nodes as 'led' nodes and
writing a driver which matches something like 'promess,mp-gpt-led' in
the compatible property. That way your driver setup code only gets
called with there is a match in the device tree.
It also makes your setup code simpler. You don't need to hardcode the
path to the gpt node. You just need to search for matching
'compatible' nodes. In this case, setting the gpt device into output
mode is probably simpler as part of the led driver initialization
(again, assuming that firware hasn't set it up correctly first).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 12/15] [POWERPC] Add mpc52xx_restart(), mpc52xx_halt(), mpc52xx_power_off().
From: Grant Likely @ 2007-10-08 7:15 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C3B2.1050103@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add common MPC5200 helper routines: mpc52xx_restart(), mpc52xx_halt(),
> mpc52xx_power_off().
>
> This patch relies on Sascha Hauer's patch published in:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 45 +++++++++++++++++++++++++++
> include/asm-powerpc/mpc52xx.h | 7 ++++
> 2 files changed, 52 insertions(+)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> index b1cd7b0..e7087d7 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -88,6 +88,14 @@ mpc52xx_find_ipb_freq(struct device_node *node)
> }
> EXPORT_SYMBOL(mpc52xx_find_ipb_freq);
>
> +/*
> + * This variable is mapped in mpc52xx_setup_cpu() by a call to
> + * mpc52xx_find_and_map(), and used in mpc52xx_restart(). This is because
> + * mpc52xx_restart() can be called from interrupt context (e.g., watchdog
> + * interrupt handler), and mpc52xx_find_and_map() (ioremap() to be exact)
> + * can't be called from interrupt context.
> + */
> +volatile struct mpc52xx_gpt *mpc52xx_gpt0 = NULL;
>
> void __init
> mpc52xx_setup_cpu(void)
> @@ -95,6 +103,9 @@ mpc52xx_setup_cpu(void)
> struct mpc52xx_cdm __iomem *cdm;
> struct mpc52xx_xlb __iomem *xlb;
>
> + /* mpc52xx_gpt0 is mapped here and used in mpc52xx_restart */
> + mpc52xx_gpt0 = mpc52xx_find_and_map("mpc5200-gpt");
> +
> /* Map zones */
> cdm = mpc52xx_find_and_map("mpc5200-cdm");
> xlb = mpc52xx_find_and_map("mpc5200-xlb");
> @@ -138,3 +149,37 @@ mpc52xx_declare_of_platform_devices(void)
> "Error while probing of_platform bus\n");
> }
>
> +void
> +mpc52xx_restart(char *cmd)
> +{
> + local_irq_disable();
> +
> + /* Turn on the watchdog and wait for it to expire. It effectively
> + does a reset */
> + if (mpc52xx_gpt0) {
> + out_be32(&mpc52xx_gpt0->mode, 0x00000000);
> + out_be32(&mpc52xx_gpt0->count, 0x000000ff);
> + out_be32(&mpc52xx_gpt0->mode, 0x00009004);
> + } else
> + printk("mpc52xx_restart: Can't access gpt. "
> + "Restart impossible, system halted\n");
> +
> + while (1);
> +}
> +
> +void
> +mpc52xx_halt(void)
> +{
> + local_irq_disable();
> +
> + while (1);
> +}
> +
> +void
> +mpc52xx_power_off(void)
> +{
> + /* By default we don't have any way of shut down.
> + If a specific board wants to, it can set the power down
> + code to any hardware implementation dependent code */
> + mpc52xx_halt();
> +}
> diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
> index a431798..8dfb4de 100644
> --- a/include/asm-powerpc/mpc52xx.h
> +++ b/include/asm-powerpc/mpc52xx.h
> @@ -104,6 +104,9 @@ struct mpc52xx_gpt {
> u32 status; /* GPTx + 0X0c */
> };
>
> +/* Static instance of GPT0 */
> +extern volatile struct mpc52xx_gpt *mpc52xx_gpt0;
> +
No; don't make this a global symbol. Restrict it to the
mpc52xx_common file. Use a helper function if you need to too set the
value.
> /* GPIO */
> struct mpc52xx_gpio {
> u32 port_config; /* GPIO + 0x00 */
> @@ -257,6 +260,10 @@ extern unsigned int mpc52xx_get_irq(void);
>
> extern int __init mpc52xx_add_bridge(struct device_node *node);
>
> +extern void mpc52xx_restart(char *cmd);
> +extern void mpc52xx_halt(void);
> +extern void mpc52xx_power_off(void);
> +
> #endif /* __ASSEMBLY__ */
>
> #ifdef CONFIG_PM
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 00/15] [POWERPC] TQM5200, CM5200 and Motion-PRO support
From: Grant Likely @ 2007-10-08 7:16 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <47075FA7.3030108@semihalf.com>
On 10/6/07, Marian Balakowicz <m8@semihalf.com> wrote:
> Hello,
>
> The following series of patches adds arch/powerpc support for three MPC5200 based boards:
> TQM5200, CM5200 and Motion-PRO.
Thanks for the patch series.
g.
>
> Included are also patches with modifications to common 52xx code. New helper
> routine mpc52xx_find_and_map_path() is added, and is being used in LED driver
> for Motion-PRO. Another patch adds mpc52xx_restart(), mpc52xx_halt()
> and mpc52xx_power_off(). This modification has been around for some time now
> and relies on Sascha Hauer's patch.
>
> 01/15 [POWERPC] TQM5200 DTS
> 02/15 [POWERPC] TQM5200 defconfig
> 03/15 [POWERPC] TQM5200 board support
> 04/15 [POWERPC] cm5200 DTS
> 05/15 [POWERPC] cm5200 defconfig
> 06/15 [POWERPC] cm5200 board support
> 07/15 [POWERPC] Promess motionpro DTS
> 08/15 [POWERPC] Promess motionpro defconfig
> 09/15 [POWERPC] Promess motionpro board support
> 10/15 [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions.
> 11/15 [POWERPC] Motion-PRO: Add LED support.
> 12/15 [POWERPC] Add mpc52xx_restart(), mpc52xx_halt(), mpc52xx_power_off().
> 13/15 [POWERPC] Init restart/halt/power_off machine hooks for tqm5200.
> 14/15 [POWERPC] Init restart/halt/power_off machine hooks for cm5200.
> 15/15 [POWERPC] Init restart/halt/power_off machine hooks for motionpro.
>
> Comments and review notes are welcome.
>
> Cheers,
> Marian Balakowicz
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] Lite5200: Use comma delimiter format for lists in device tree
From: Grant Likely @ 2007-10-08 7:24 UTC (permalink / raw)
To: galak, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
DTC now supports "foo","bar" format for lists of strings; use the new
format on the lite5200 device trees.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/dts/lite5200.dts | 10 +++---
arch/powerpc/boot/dts/lite5200b.dts | 62 ++++++++++++++++++-----------------
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 324e1bd..bc45f5f 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200";
// revision = "1.0";
- compatible = "fsl,lite5200\0generic-mpc5200";
+ compatible = "fsl,lite5200","generic-mpc5200";
#address-cells = <1>;
#size-cells = <1>;
@@ -192,7 +192,7 @@
usb@1000 {
device_type = "usb-ohci-be";
- compatible = "mpc5200-ohci\0ohci-be";
+ compatible = "mpc5200-ohci","ohci-be";
reg = <1000 ff>;
interrupts = <2 6 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -293,7 +293,7 @@
i2c@3d00 {
device_type = "i2c";
- compatible = "mpc5200-i2c\0fsl-i2c";
+ compatible = "mpc5200-i2c","fsl-i2c";
cell-index = <0>;
reg = <3d00 40>;
interrupts = <2 f 0>;
@@ -303,7 +303,7 @@
i2c@3d40 {
device_type = "i2c";
- compatible = "mpc5200-i2c\0fsl-i2c";
+ compatible = "mpc5200-i2c","fsl-i2c";
cell-index = <1>;
reg = <3d40 40>;
interrupts = <2 10 0>;
@@ -312,7 +312,7 @@
};
sram@8000 {
device_type = "sram";
- compatible = "mpc5200-sram\0sram";
+ compatible = "mpc5200-sram","sram";
reg = <8000 4000>;
};
};
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index 3f74f73..a6bb1d0 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200b";
// revision = "1.0";
- compatible = "fsl,lite5200b\0generic-mpc5200";
+ compatible = "fsl,lite5200b","generic-mpc5200";
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@
system-frequency = <0>; // from bootloader
cdm@200 {
- compatible = "mpc5200b-cdm\0mpc5200-cdm";
+ compatible = "mpc5200b-cdm","mpc5200-cdm";
reg = <200 38>;
};
@@ -65,12 +65,12 @@
interrupt-controller;
#interrupt-cells = <3>;
device_type = "interrupt-controller";
- compatible = "mpc5200b-pic\0mpc5200-pic";
+ compatible = "mpc5200b-pic","mpc5200-pic";
reg = <500 80>;
};
gpt@600 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <0>;
reg = <600 10>;
@@ -80,7 +80,7 @@
};
gpt@610 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <1>;
reg = <610 10>;
@@ -89,7 +89,7 @@
};
gpt@620 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <2>;
reg = <620 10>;
@@ -98,7 +98,7 @@
};
gpt@630 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <3>;
reg = <630 10>;
@@ -107,7 +107,7 @@
};
gpt@640 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <4>;
reg = <640 10>;
@@ -116,7 +116,7 @@
};
gpt@650 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <5>;
reg = <650 10>;
@@ -125,7 +125,7 @@
};
gpt@660 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <6>;
reg = <660 10>;
@@ -134,7 +134,7 @@
};
gpt@670 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <7>;
reg = <670 10>;
@@ -143,7 +143,7 @@
};
rtc@800 { // Real time clock
- compatible = "mpc5200b-rtc\0mpc5200-rtc";
+ compatible = "mpc5200b-rtc","mpc5200-rtc";
device_type = "rtc";
reg = <800 100>;
interrupts = <1 5 0 1 6 0>;
@@ -152,7 +152,7 @@
mscan@900 {
device_type = "mscan";
- compatible = "mpc5200b-mscan\0mpc5200-mscan";
+ compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <0>;
interrupts = <2 11 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -161,7 +161,7 @@
mscan@980 {
device_type = "mscan";
- compatible = "mpc5200b-mscan\0mpc5200-mscan";
+ compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <1>;
interrupts = <2 12 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -169,14 +169,14 @@
};
gpio@b00 {
- compatible = "mpc5200b-gpio\0mpc5200-gpio";
+ compatible = "mpc5200b-gpio","mpc5200-gpio";
reg = <b00 40>;
interrupts = <1 7 0>;
interrupt-parent = <&mpc5200_pic>;
};
gpio-wkup@c00 {
- compatible = "mpc5200b-gpio-wkup\0mpc5200-gpio-wkup";
+ compatible = "mpc5200b-gpio-wkup","mpc5200-gpio-wkup";
reg = <c00 40>;
interrupts = <1 8 0 0 3 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -184,7 +184,7 @@
spi@f00 {
device_type = "spi";
- compatible = "mpc5200b-spi\0mpc5200-spi";
+ compatible = "mpc5200b-spi","mpc5200-spi";
reg = <f00 20>;
interrupts = <2 d 0 2 e 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -192,7 +192,7 @@
usb@1000 {
device_type = "usb-ohci-be";
- compatible = "mpc5200b-ohci\0mpc5200-ohci\0ohci-be";
+ compatible = "mpc5200b-ohci","mpc5200-ohci","ohci-be";
reg = <1000 ff>;
interrupts = <2 6 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -200,7 +200,7 @@
bestcomm@1200 {
device_type = "dma-controller";
- compatible = "mpc5200b-bestcomm\0mpc5200-bestcomm";
+ compatible = "mpc5200b-bestcomm","mpc5200-bestcomm";
reg = <1200 80>;
interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
3 4 0 3 5 0 3 6 0 3 7 0
@@ -210,13 +210,13 @@
};
xlb@1f00 {
- compatible = "mpc5200b-xlb\0mpc5200-xlb";
+ compatible = "mpc5200b-xlb","mpc5200-xlb";
reg = <1f00 100>;
};
serial@2000 { // PSC1
device_type = "serial";
- compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
+ compatible = "mpc5200b-psc-uart","mpc5200-psc-uart";
port-number = <0>; // Logical port assignment
cell-index = <0>;
reg = <2000 100>;
@@ -227,7 +227,7 @@
// PSC2 in ac97 mode example
//ac97@2200 { // PSC2
// device_type = "sound";
- // compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
+ // compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
// cell-index = <1>;
// reg = <2200 100>;
// interrupts = <2 2 0>;
@@ -247,7 +247,7 @@
// PSC4 in uart mode example
//serial@2600 { // PSC4
// device_type = "serial";
- // compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
+ // compatible = "mpc5200b-psc-uart","mpc5200-psc-uart";
// cell-index = <3>;
// reg = <2600 100>;
// interrupts = <2 b 0>;
@@ -257,7 +257,7 @@
// PSC5 in uart mode example
//serial@2800 { // PSC5
// device_type = "serial";
- // compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
+ // compatible = "mpc5200b-psc-uart","mpc5200-psc-uart";
// cell-index = <4>;
// reg = <2800 100>;
// interrupts = <2 c 0>;
@@ -267,7 +267,7 @@
// PSC6 in spi mode example
//spi@2c00 { // PSC6
// device_type = "spi";
- // compatible = "mpc5200b-psc-spi\0mpc5200-psc-spi";
+ // compatible = "mpc5200b-psc-spi","mpc5200-psc-spi";
// cell-index = <5>;
// reg = <2c00 100>;
// interrupts = <2 4 0>;
@@ -276,7 +276,7 @@
ethernet@3000 {
device_type = "network";
- compatible = "mpc5200b-fec\0mpc5200-fec";
+ compatible = "mpc5200b-fec","mpc5200-fec";
reg = <3000 800>;
mac-address = [ 02 03 04 05 06 07 ]; // Bad!
interrupts = <2 5 0>;
@@ -285,7 +285,7 @@
ata@3a00 {
device_type = "ata";
- compatible = "mpc5200b-ata\0mpc5200-ata";
+ compatible = "mpc5200b-ata","mpc5200-ata";
reg = <3a00 100>;
interrupts = <2 7 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -293,7 +293,7 @@
i2c@3d00 {
device_type = "i2c";
- compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
+ compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
cell-index = <0>;
reg = <3d00 40>;
interrupts = <2 f 0>;
@@ -303,7 +303,7 @@
i2c@3d40 {
device_type = "i2c";
- compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
+ compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
cell-index = <1>;
reg = <3d40 40>;
interrupts = <2 10 0>;
@@ -312,7 +312,7 @@
};
sram@8000 {
device_type = "sram";
- compatible = "mpc5200b-sram\0mpc5200-sram\0sram";
+ compatible = "mpc5200b-sram","mpc5200-sram","sram";
reg = <8000 4000>;
};
};
@@ -322,7 +322,7 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- compatible = "mpc5200b-pci\0mpc5200-pci";
+ compatible = "mpc5200b-pci","mpc5200-pci";
reg = <f0000d00 100>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
^ permalink raw reply related
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Wolfgang Denk @ 2007-10-08 7:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, tech-denx, Detlev Zundel, Marian Balakowicz
In-Reply-To: <fa686aa40710072321g3494b243w341e2b09117c3695@mail.gmail.com>
In message <fa686aa40710072321g3494b243w341e2b09117c3695@mail.gmail.com> you wrote:
>
> > + port_config &= ~0x03000000; /* ATA CS is on csb_4/5 */
> > + port_config |= 0x01000000;
>
> Are you *sure* you want this? You should only be touching port_config
> if firmware fails to set it up correctly. Don't blindly copy what was
> done for the lite5200.
>
> Lite5200 touches it because firmware does *not* do the right thing at
> the moment.
Why don't we fix it in U-Boot, then, and get rid of this in Linux?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The average woman would rather have beauty than brains, because the
average man can see better than he can think.
^ permalink raw reply
* [PATCH] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-08 7:53 UTC (permalink / raw)
To: linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
This is a first draft, please review and comment.
On a side node, I think booting-without-of.txt could get really unwieldly
in the near future. Perhaps the device tree bindings should be organized
differently and separated from the functional description of device tree
usage. Thoughts?
Cheers,
g.
Documentation/powerpc/booting-without-of.txt | 58 ++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 20e0e6c..a6d6056 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1850,6 +1850,64 @@ platforms are moved over to use the flattened-device-tree model.
More devices will be defined as this spec matures.
+ l) Xilinx ML300 Framebuffer
+
+ Simple framebuffer device from the ML300 reference design (also on the
+ ML403 reference design as well as others).
+
+ Required properties:
+ - compatible : Must include "xilinx,ml300-fb"
+ - reg : offset and length of the framebuffer register set
+
+ Optional properties:
+ - resolution : <xres yres> pixel resolution of framebuffer. Some
+ implementations use a different resolution. Default
+ is <d#640 d#480>
+ - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
+ Default is <d#1024 d#480>.
+ - rotate-display : rotate display 180 degrees.
+ - display-number : Logical number of display
+
+ m) Xilinx SystemACE
+
+ The Xilinx SystemACE device is used to program FPGAs from an FPGA
+ bitstream stored on a CF card. It can also be used as a generic CF
+ interface device.
+
+ Required properties:
+ - compatible : Must include "xilinx,sysace"
+ - reg : offset and length of SystemACE register set
+
+ Recommended properties:
+ - interrupt-parent, interrupts : Connection of device irq signal.
+
+ Optional properties:
+ - number : logical number of the SystemACE device based at 0.
+ - 8-bit (empty) : Set this property if the SystemACE must be in 8 bit mode
+
+ n) Xilinx EMAC and Xilinx TEMAC
+
+ Xilinx Ethernet devices. Uses common properties from other Ethernet
+ devices with the following constraints:
+
+ Required properties:
+ - compatible : Must include one of: "xilinx,plb-temac",
+ "xilinx,plb-emac", "xilinx-opb-emac"
+ - dma-mode : Must be one of "none", "simple", "sg" (sg == scatter gather)
+
+ o) Xilinx Uartlite
+
+ Xilinx uartlite devices are simple fixed speed serial ports. Uartlite
+ ports should be described in a node with the following properties.
+
+ Requred properties:
+ - compatible : Must include "xilinx,uartlite"
+ - reg : offset and length of uartlite register set
+
+ Recommended properties:
+ - port-number : logical port number of uartlite device based at 0.
+ - interrupt-parent, interrupts : Connection of device irq signal.
+
VII - Specifying interrupt information for devices
===================================================
^ permalink raw reply related
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Grant Likely @ 2007-10-08 7:54 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, tech-denx, Detlev Zundel, Marian Balakowicz
In-Reply-To: <20071008074409.5A6BE2486E@gemini.denx.de>
On 10/8/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <fa686aa40710072321g3494b243w341e2b09117c3695@mail.gmail.com> you wrote:
> >
> > > + port_config &= ~0x03000000; /* ATA CS is on csb_4/5 */
> > > + port_config |= 0x01000000;
> >
> > Are you *sure* you want this? You should only be touching port_config
> > if firmware fails to set it up correctly. Don't blindly copy what was
> > done for the lite5200.
> >
> > Lite5200 touches it because firmware does *not* do the right thing at
> > the moment.
>
> Why don't we fix it in U-Boot, then, and get rid of this in Linux?
Mostly because I haven't gotten to it yet. :-/
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Vitaly Bordug @ 2007-10-08 8:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EB9BE8E7-6437-403F-A7F4-953B393FDF51@kernel.crashing.org>
Hello Kumar,
On Fri, 5 Oct 2007 15:58:00 -0500
Kumar Gala wrote:
>=20
> On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
>=20
> > On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
> >> Hello.
> >>
> >> Anton Vorontsov wrote:
> >>
> >>> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
> >>> PCI/PCIe nodes, but actually it broke them even harder. ;-)
> >>
> >> Of course. But shouldn't those be the subnoses of the "soc" =20
> >> type node?
> >
> > Nope. PCI's ranges =3D <>; isn't in the SOC address space.
> >
> > Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add =20
> > 64-bit
> > phys addr support to 32-bit pci" that started using =20
> > of_translate_address()
> > for ranges, and of_translate_address() will not work if PCI placed =20
> > in the
> > SOC node. Not sure if that patch applied or not, though.
>=20
> I'm confused, what's the actual issue with PCI that this patch =20
> addresses?
>=20
=46rom what I can see, move of the PCI node out of the SoC node, inspired by =
the recent flame talk about it :)
I guess pretty soon, we'll have "proper" ranges parsing for pci, that does =
of_translate_address() and requires
either tuned-up parent ranges, or residing outside of the SoC node, this is=
the reason...
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--=20
Sincerely, Vitaly
^ permalink raw reply
* Re: Where are inb/outb macros?
From: Benjamin Herrenschmidt @ 2007-10-08 8:11 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-dev
In-Reply-To: <13091078.post@talk.nabble.com>
On Mon, 2007-10-08 at 00:09 -0700, Misbah khan wrote:
> inb/outb could be used from the usr space on x86 class PC-computer to access
> to io ports this is what i assume that you are trying
>
> You need to compile the program with -O option (expantion of Inline function
> )
>
> To perform io operation on ports ioprem/iopl system call must be used (To
> get permissio to perform io operation)
>
> Program must run as root
>
> on non 86 platform try using /dev/port device file in the application
"io ports" don't mean much on non-x86 platforms (or rather can have
multiple meanings) which is why I'm asking what is he trying to od in
the first place.
Ben.
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Geert Uytterhoeven @ 2007-10-08 8:27 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071006213542.954029915@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3001 bytes --]
On Sat, 6 Oct 2007 geoffrey.levand@am.sony.com wrote:
> --- a/arch/powerpc/platforms/ps3/os-area.c
> +++ b/arch/powerpc/platforms/ps3/os-area.c
> @@ -112,10 +114,91 @@ struct os_area_params {
> u8 _reserved_5[8];
> };
>
> +/**
> + * struct os_area_db - Shared flash memory database.
> + * @magic_num: Always '-db-' = 0x2d64622d.
^^^^^^^^^^
#define?
> @@ -242,6 +325,303 @@ static int __init verify_header(const st
> return 0;
> }
>
> +static int db_verify(const struct os_area_db *db)
> +{
> + if (db->magic_num != 0x2d64622dU) {
^^^^^^^^^^^
#define?
> +static void os_area_db_init(struct os_area_db *db)
> +{
> + /*
> + * item | start | size
> + * ----------+-------+-------
> + * header | 0 | 24
> + * index_64 | 24 | 64
> + * values_64 | 88 | 57*8 = 456
> + * index_32 | 544 | 64
> + * values_32 | 609 | 57*4 = 228
> + * index_16 | 836 | 64
> + * values_16 | 900 | 57*2 = 114
> + * end | 1014 | -
> + */
Lots of #defines and calculations?
> +
> + memset(db, 0, sizeof(struct os_area_db));
> +
> + db->magic_num = 0x2d64622dU;
^^^^^^^^^^^
#define?
> + db->version = 1;
> + db->index_64 = 24;
^^
> + db->count_64 = 57;
^^
> + db->index_32 = 544;
^^^
> + db->count_32 = 57;
^^
> + db->index_16 = 836;
^^^
> + db->count_16 = 57;
^^
#defines?
> +static void update_flash_db(void)
> +{
> + int result;
> + int file;
> + off_t offset;
> + ssize_t count;
> + static const unsigned int buf_len = 8 * OS_AREA_SEGMENT_SIZE;
> + const struct os_area_header *header;
> + struct os_area_db* db;
> +
> + /* Read in header and db from flash. */
> +
> + file = sys_open("/dev/ps3flash", O_RDWR, 0);
Ah, file operations from kernel space...
> @@ -264,6 +644,9 @@ static void os_area_queue_work_handler(s
> pr_debug("%s:%d of_find_node_by_path failed\n",
> __func__, __LINE__);
>
> +#if defined(CONFIG_PS3_FLASH) || defined(CONFIG_PS3_FLASH_MODULE)
> + update_flash_db();
> +#endif
Is this #ifdef needed? You don't reference ps3flash symbols directly, only by
opening /dev/ps3flash. If you always call update_flash_db(), you can print an
error message and the user will notice things haven't been written to flash.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Sascha Hauer @ 2007-10-08 8:48 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281112.18480.jbe@pengutronix.de>
Hi,
On Fri, Sep 28, 2007 at 11:12:17AM +0200, Juergen Beisert wrote:
> I tried with in_atomic(). The BUG report is gone, but the problem still
> exists.
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex: 36
> net eth0: rx: index: 24, outdex: 25
> PHY: f0003000:00 - Link is Down
> PHY: f0003000:00 - Link is Up - 100/Full
>
> The link is up again, but any connection is dead (no answers to ping etc.).
> But the serial console is still working. I'm not sure if the RT-Preempt patch
> *causes* this behavior or only *discover* it. Any idea?
We finally solved this problem. It has nothing to do with locking
though. The problem is that the bcom engine was not reenabled after
resetting the fec. The following patch solves this.
Reenable the bestcom engine after resetting the mpc52xx fec
controller.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec_mpc52xx/fec.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/drivers/net/fec_mpc52xx/fec.c
===================================================================
--- linux-2.6.orig/drivers/net/fec_mpc52xx/fec.c
+++ linux-2.6/drivers/net/fec_mpc52xx/fec.c
@@ -788,6 +788,9 @@ static void fec_reset(struct net_device
fec_alloc_rx_buffers(priv->rx_dmatsk);
+ bcom_enable(priv->rx_dmatsk);
+ bcom_enable(priv->tx_dmatsk);
+
fec_start(dev);
}
>
> Juergen
> --
> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Vertretung Sued/Muenchen, Germany
> Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox