* Re: [PATCH] Fix vmemmap warning in init_64..c
From: Geert Uytterhoeven @ 2007-10-17 8:55 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071017043024.GE9814@bakeyournoodle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1728 bytes --]
On Wed, 17 Oct 2007, Tony Breeds wrote:
> Use the right printk format to silence the following warning.
>
> CC arch/powerpc/mm/init_64.o
> arch/powerpc/mm/init_64.c: In function 'vmemmap_populate':
> arch/powerpc/mm/init_64.c:243: warning: format '%p' expects type 'void *', but argument 4 has type 'long unsigned int'
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
>
> Also a whitespace fix while I'm there.
>
> arch/powerpc/mm/init_64.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index 702d884..6720b1c 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -240,7 +240,7 @@ int __meminit vmemmap_populate(struct page *start_page,
> return -ENOMEM;
>
> printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
^^
> - "physical %p.\n", start, p, __pa(p));
> + "physical %08lx.\n", start, p, __pa(p));
^^
Anyone with memory outside 32-bit (`%08lx') space?
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: vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Benjamin Herrenschmidt @ 2007-10-17 9:01 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-fbdev-devel
In-Reply-To: <Pine.LNX.4.62.0710171047430.29856@pademelon.sonytel.be>
On Wed, 2007-10-17 at 10:49 +0200, Geert Uytterhoeven wrote:
> >
> > So VGACON probably doesn't work either on 32bit. I'm guessing
> arch/powerpc
> > doesn't support PREP.
>
> It's not only useful for PREP, but also for CHRP.
>
> > How best could this be fixed up? Or should I just let the thing
> > be? This is obviously not a new thing, and I don't have any
> hardware
> > that supports this stuff either.
>
> I remember this problem was present when I still had a working
> LongTrail (which
> is CHRP), long before arch/powerpc/ was created.
It's all very old stuff that needs to be dusted. If you have a setup
where legacy VGA is useable, feel free to do a bit of work on that :-)
Ben.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Paul Mackerras @ 2007-10-17 10:27 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710161622v50484122s6ddbf6c4dc4b1e3f@mail.gmail.com>
Grant Likely writes:
> There are remaining outstanding comments; but my opinion is that they
> should be addressed in subsequent patches (performance optimization
> for mp5200b boards and making the sram management code a generic
> interface usable by other SoC support code).
>
> If you agree; please pull into your tree.
I'll pull it on the understanding that the remaining issues will in
fact be addressed in the near term.
Paul.
^ permalink raw reply
* Re: PPC440EPx GPIO control help
From: Josh Boyer @ 2007-10-17 10:49 UTC (permalink / raw)
To: Jeff Mock; +Cc: linuxppc-embedded
In-Reply-To: <4715A9D9.6090308@mock.com>
On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote:
> David Hawkins wrote:
> >> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21.
> >> What I would want to do is to control (write and read values to) its
> >> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and
> >> inportb(0x378) to read. I read the PPC440EPx manual but I find it
> >> difficult to understand.
> >>
> >> Could anyone show me any tutorial or some sample codes?
> >
> > I copied the code below from some test code I wrote for a TS7300
> > board (uses an ARM EP9302 processor). However, since its user-space
> > code it should work fine.
> >
>
> I might be a little out of date, but I think you must write your own
> driver to wiggle the GPIO pins on a 440 processor. I just finished a
> project using a 440GX with a 2.6.15 kernel (we froze the code about 8
> months ago).
>
> The 440 powerPC core is a 32-bit processor with 36-bit physical
> addresses. The physical address for the GPIO pins is someplace above
> 4GB. An mmap() of /dev/mem only lets you map the lower 4GB of the
> address space, as a result you can't write a user space program on the
> 440 to wiggle the GPIO pins. (This was true with 2.6.15, I can't speak
> for later kernels).
This depends on the 440 chip itself. If I recall correctly, the
440EP(x) chips don't have I/O above 4GB.
josh
^ permalink raw reply
* Re: [PATCH 01/15] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-10-17 11:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710071036u164f2cbaob8cfa4ebc0b1ed1c@mail.gmail.com>
Grant Likely wrote:
>> + memory {
>> + device_type = "memory";
>> + reg = <00000000 04000000>; // 64MB
>> + };
>> +
>> + soc5200@f0000000 {
>
> I think we're moving to the convetion of naming these nodes
> "soc@<addr>" now. (You can drop the 5200 for the node name)
Seems that this will not be painless, U-boot uses hardcoded
paths with 'soc5200', so the appropriate patch will be needed.
That may be ok for new boards but what do we do with lite5200,
where U-boot upgrade is not always an option?
m.
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: David Miller @ 2007-10-17 11:22 UTC (permalink / raw)
To: michael; +Cc: sparclinux, sfr, paulus, linuxppc-dev
In-Reply-To: <dadd2b9540369b9e2c6773b2a60021dadafa58e2.1192605144.git.michael@ellerman.id.au>
From: Michael Ellerman <michael@ellerman.id.au>
Date: Wed, 17 Oct 2007 17:12:27 +1000 (EST)
> Use of_get_pci_dev_node() in axon_msi.c. Switch to including <linux/of.h>
> so we get the prototype.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
I find it ironic that you add of_get_pci_dev_node() as a function
which gets the node and grabs a reference to it, and then the very
first usage you make of it doesn't drop the reference at all.
That reference grabbing aspect of the new interface is obviously very
useful! :-)
Kidding aside (I realize that in this case probably the driver never
unregisters and therefore the reference never needs to be released)
it's really much nicer to add facilities when you have patches in hand
that actually use them.
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: David Miller @ 2007-10-17 11:23 UTC (permalink / raw)
To: michael; +Cc: sparclinux, sfr, paulus, linuxppc-dev
In-Reply-To: <20071017.042229.95059231.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 17 Oct 2007 04:22:29 -0700 (PDT)
> From: Michael Ellerman <michael@ellerman.id.au>
> Date: Wed, 17 Oct 2007 17:12:27 +1000 (EST)
>
> > Use of_get_pci_dev_node() in axon_msi.c. Switch to including <linux/of.h>
> > so we get the prototype.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>
> I find it ironic that you add of_get_pci_dev_node() as a function
> which gets the node and grabs a reference to it, and then the very
> first usage you make of it doesn't drop the reference at all.
Ignore this poor attempt at humor, I misread your patch :)
^ permalink raw reply
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Marian Balakowicz @ 2007-10-17 11:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710072321g3494b243w341e2b09117c3695@mail.gmail.com>
Grant Likely wrote:
> 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).
Agree, will try more generic approach.
>> +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.
Yes, that's needed, but will be moved to U-boot.
>> +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?
Well, not really...
Something like
seq_printf(m, "Vendor\t\t: TQ Components\n");
seq_printf(m, "Machine\t\t: %s\n", model);
and model set to 'tqc,tqm5200' would be more accurate but going for
compatible='mpc5200-generic' platform we may need to drop Vendor line
anyway.
m.
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Benjamin Herrenschmidt @ 2007-10-17 11:36 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, paulus, linuxppc-dev, sfr
In-Reply-To: <20071017.042229.95059231.davem@davemloft.net>
> I find it ironic that you add of_get_pci_dev_node() as a function
> which gets the node and grabs a reference to it, and then the very
> first usage you make of it doesn't drop the reference at all.
>
> That reference grabbing aspect of the new interface is obviously very
> useful! :-)
>
> Kidding aside (I realize that in this case probably the driver never
> unregisters and therefore the reference never needs to be released)
> it's really much nicer to add facilities when you have patches in hand
> that actually use them.
I think in this case, it's mostly a matter of consistency... pretty much
everything that returns a device_node grabs a reference... except
pci_device_to_OF_node :-)
I think Michael is trying to address that, and axon-msi happens to be
something he wrote so a good candidate for an initial conversion :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Marian Balakowicz @ 2007-10-17 11:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071008150449.GB4289@loki.buserror.net>
Scott Wood wrote:
>
>> +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");
>> + seq_printf(m, "machine\t\t: %s\n", model ? model : "unknown");
>> +
>> + of_node_put(np);
>> +}
>
> Get rid of this.
Agree, that may be overhead in some cases. But there would be also
cases where printing out a machine name would be informative. CM5200
is one such example, there are several variants of the hw and platform
name is too generic.
Other situation would be adding compatible='mpc5200-generic' platform
where platform name would not provide any details.
m.
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-17 12:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40710161237t54688b71g9c7cf9acdac2b744@mail.gmail.com>
Hello.
Grant Likely-2 wrote:
>
> On 10/16/07, aauer1 <aauer1@gmx.at> wrote:
>>
>> The on-chip memories are disabled. Only the BRAM is enabled. Now, we also
>> use
>> the ELDK 4.1 from Denx and the included cross compiler. The result is the
>> same... the Kernel stops at "Now booting the kernel". Now, we also have
>> an
>> USB JTAG cable. So, we can debug the memory.
>> Probably, anyone has another idea.
>
> There are two common reasons for this behaviour:
> 1. kernel crashes before the console is configured
> 2. the console is not configured correctly.
>
> In both cases; finding a way to look at __log_buf is the fastest way
> to figure out what is going on.
>
>
I was able to look at the __log_buf variable with the JTAG cable. So, I
recognized that the kernel doesn't halt after the "No booting the kernel"
message. There are many output messages in the __log_buf variable until it
stops at with a "Kernel panic" because the rootfs is not found (but this is
the minor problem).
Now, I know that the kernel boots but I don't get an output with my Xilinx
UartLite module. Are there some kernel modules which must be activated??
Btw. I have used the Linux-2.6-virtex kernel from
http://git.secretlab.ca/git/ and another Kernel (2.6.23 from kernel.org) -
both with the same result.
Thanks a lot,
Andreas
--
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13252272
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: dtc: Restore missing code for testcases
From: Jon Loeliger @ 2007-10-17 12:11 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071017012357.GE28260@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Recent commits 333542fabf8720b881e992a5abca32ef4bcb841a and
> fd1bf3a5ae46962528ef89a824261a88830758a2 added new testcases to dtc.
> However, although the testcases were added to the Makefile and
> run_tests.sh, one of the .c files for the testcase was omitted from
> the patch in each case.
>
> This patch restores the missing testcase code.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
> jdl, you should
> really run a "make check" before committing my patches...
In the past, I have. I confess, this last round I only
compiled tested things. I'm really still catching up some...
jdl
^ permalink raw reply
* Re: dtc: Improve -Odts output
From: Jon Loeliger @ 2007-10-17 12:15 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071017023910.GH28260@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch makes improvements to the way properties are printed when
> in dtc is producing dts output.
> - Characters which need escaping are now properly handled when
> printing properties as strings
> - The heuristics for what format to use for a property are
> improved so that 'compatible' properties will be displayed as
> expected.
> - escapes.dts is altered to better demonstrate the changes,
> and the string_escapes testcase is adjusted accordingly.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: PPC440EPx GPIO control help
From: Misbah khan @ 2007-10-17 12:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1192618194.13993.25.camel@localhost.localdomain>
I Prefer that you write a coustem driver. map the GPIO address (Either make
use of mapped area of GPIO that u may find in the source for comercial
kernel or else map the physical address in the driver and access it ).
---Misbah
Josh Boyer-4 wrote:
>
> On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote:
>> David Hawkins wrote:
>> >> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21.
>> >> What I would want to do is to control (write and read values to) its
>> >> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and
>> >> inportb(0x378) to read. I read the PPC440EPx manual but I find it
>> >> difficult to understand.
>> >>
>> >> Could anyone show me any tutorial or some sample codes?
>> >
>> > I copied the code below from some test code I wrote for a TS7300
>> > board (uses an ARM EP9302 processor). However, since its user-space
>> > code it should work fine.
>> >
>>
>> I might be a little out of date, but I think you must write your own
>> driver to wiggle the GPIO pins on a 440 processor. I just finished a
>> project using a 440GX with a 2.6.15 kernel (we froze the code about 8
>> months ago).
>>
>> The 440 powerPC core is a 32-bit processor with 36-bit physical
>> addresses. The physical address for the GPIO pins is someplace above
>> 4GB. An mmap() of /dev/mem only lets you map the lower 4GB of the
>> address space, as a result you can't write a user space program on the
>> 440 to wiggle the GPIO pins. (This was true with 2.6.15, I can't speak
>> for later kernels).
>
> This depends on the 440 chip itself. If I recall correctly, the
> 440EP(x) chips don't have I/O above 4GB.
>
> josh
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/PPC440EPx-GPIO-control-help-tf4638058.html#a13252501
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 04/15] [POWERPC] CM5200 DTS
From: Marian Balakowicz @ 2007-10-17 12:22 UTC (permalink / raw)
To: David Gibson, linuxppc-dev
In-Reply-To: <20071008015021.GA12499@localhost.localdomain>
David Gibson wrote:
> [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.
Ok.
> Second, is the flash really part of the SoC?
Not directly, it is attached to LocalPlus Bus Controller, which is
part of the SoC. And the soc@ is currently the only recognized of bus
for mpc5200, so if we want to move it to some other place new bindings
will need to be defined for lpc (LocalPlus Controller) bus. But I am
not quite sure where this should be attached. Bus is under LPC which
is a part of the SoC, but on the other hand Soc address range covers
only device control registers not the address space LPC may handle
(that may be varied). Any ideas?
m.
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-10-17 12:45 UTC (permalink / raw)
To: benh
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel,
Steven Rostedt
In-Reply-To: <1192497543.19073.0.camel@pasglop>
Hello.
Benjamin Herrenschmidt wrote:
>> Eh... poor you. Tony got clockevent driver reengineered for no apparent
>>reason. And he's introduced the jiffy drift by deleting the main loop from
>>timer_interrupt(). Yet this borken version was preferred to what was known
>>working since about 2.6.18 and included into 2.6.21-rt patchset. I don't like
>>that policy. Will you be pushing fixes from -rt to PowerPC, or will it fall on
>>my shoulders now?
> Possibly because whatever implementation existed before was never
> provided in a mergeable form
The fact that vDSO calls were removed out of the necessity (because having
the broken TOD stuff removed was better than to leave it in place producing
inexact results) doesn't mean that everything in the patches provided was
broken and of no use. Yet you want everything removed in favor of somewhat
dubious implementation.
> and pushed to -rt bypassing the powerpc architecture maintainer ?
There was no bypassing, everything was submitted publicly via this list.
The -rt patch (via the hrtimers patchset) was the place to merge the hrtimers
code at thiat time, and nobody showed any interest in making the code better,
i.e. amending vDSO stuff, for months... (The question also is why Tony was
submitting his patches also to linux-rt-users while they were known not to
apply to the -rt patch.)
> Ben.
WBR, Sergei
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-10-17 12:49 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some a collection of fixes for powerpc, plus a set of commits
that add some new driver code for the "bestcomm" hardware on some
Freescale embedded PowerPC chips.
Thanks,
Paul.
arch/powerpc/Kconfig | 4
arch/powerpc/boot/dts/lite5200b.dts | 18 +
arch/powerpc/configs/bamboo_defconfig | 7
arch/powerpc/configs/celleb_defconfig | 7
arch/powerpc/configs/chrp32_defconfig | 7
arch/powerpc/configs/ebony_defconfig | 7
arch/powerpc/configs/g5_defconfig | 7
arch/powerpc/configs/holly_defconfig | 7
arch/powerpc/configs/iseries_defconfig | 7
arch/powerpc/configs/kilauea_defconfig | 7
arch/powerpc/configs/linkstation_defconfig | 7
arch/powerpc/configs/lite5200_defconfig | 7
arch/powerpc/configs/maple_defconfig | 8
arch/powerpc/configs/mpc7448_hpc2_defconfig | 5
arch/powerpc/configs/mpc8272_ads_defconfig | 7
arch/powerpc/configs/mpc8313_rdb_defconfig | 7
arch/powerpc/configs/mpc832x_mds_defconfig | 5
arch/powerpc/configs/mpc832x_rdb_defconfig | 5
arch/powerpc/configs/mpc834x_itx_defconfig | 5
arch/powerpc/configs/mpc834x_itxgp_defconfig | 5
arch/powerpc/configs/mpc834x_mds_defconfig | 5
arch/powerpc/configs/mpc836x_mds_defconfig | 5
arch/powerpc/configs/mpc8540_ads_defconfig | 7
arch/powerpc/configs/mpc8544_ds_defconfig | 7
arch/powerpc/configs/mpc8560_ads_defconfig | 7
arch/powerpc/configs/mpc8568mds_defconfig | 7
arch/powerpc/configs/mpc8572_ds_defconfig | 7
arch/powerpc/configs/mpc85xx_cds_defconfig | 7
arch/powerpc/configs/mpc8610_hpcd_defconfig | 7
arch/powerpc/configs/mpc8641_hpcn_defconfig | 7
arch/powerpc/configs/mpc866_ads_defconfig | 5
arch/powerpc/configs/pasemi_defconfig | 7
arch/powerpc/configs/pmac32_defconfig | 7
arch/powerpc/configs/ppc64_defconfig | 11
arch/powerpc/configs/pq2fads_defconfig | 7
arch/powerpc/configs/prpmc2800_defconfig | 5
arch/powerpc/configs/ps3_defconfig | 7
arch/powerpc/configs/pseries_defconfig | 11
arch/powerpc/configs/sequoia_defconfig | 7
arch/powerpc/configs/walnut_defconfig | 7
arch/powerpc/kernel/entry_64.S | 6
arch/powerpc/kernel/ibmebus.c | 263 +++-------
arch/powerpc/kernel/of_device.c | 80 +++
arch/powerpc/kernel/of_platform.c | 70 ---
arch/powerpc/kernel/setup_64.c | 13
arch/powerpc/kernel/time.c | 2
arch/powerpc/kernel/vdso64/sigtramp.S | 11
arch/powerpc/lib/Makefile | 5
arch/powerpc/lib/rheap.c | 15 +
arch/powerpc/math-emu/math.c | 13
arch/powerpc/mm/hash_utils_64.c | 3
arch/powerpc/mm/init_64.c | 2
arch/powerpc/mm/slb.c | 3
arch/powerpc/platforms/Kconfig | 4
arch/powerpc/platforms/Kconfig.cputype | 1
arch/powerpc/platforms/iseries/htab.c | 4
arch/powerpc/platforms/iseries/vio.c | 2
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/bestcomm/Kconfig | 39 +
arch/powerpc/sysdev/bestcomm/Makefile | 14 +
arch/powerpc/sysdev/bestcomm/ata.c | 154 ++++++
arch/powerpc/sysdev/bestcomm/ata.h | 37 +
arch/powerpc/sysdev/bestcomm/bcom_ata_task.c | 67 +++
arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.c | 78 +++
arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.c | 91 +++
arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c | 63 ++
arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c | 69 +++
arch/powerpc/sysdev/bestcomm/bestcomm.c | 528 ++++++++++++++++++++
arch/powerpc/sysdev/bestcomm/bestcomm.h | 190 +++++++
arch/powerpc/sysdev/bestcomm/bestcomm_priv.h | 334 +++++++++++++
arch/powerpc/sysdev/bestcomm/fec.c | 270 ++++++++++
arch/powerpc/sysdev/bestcomm/fec.h | 61 ++
arch/powerpc/sysdev/bestcomm/gen_bd.c | 260 ++++++++++
arch/powerpc/sysdev/bestcomm/gen_bd.h | 48 ++
arch/powerpc/sysdev/bestcomm/sram.c | 177 +++++++
arch/powerpc/sysdev/bestcomm/sram.h | 54 ++
arch/powerpc/sysdev/fsl_pci.c | 2
arch/ppc/Kconfig | 6
drivers/infiniband/hw/ehca/ehca_classes.h | 2
drivers/infiniband/hw/ehca/ehca_eq.c | 6
drivers/infiniband/hw/ehca/ehca_main.c | 32 +
drivers/net/ehea/ehea.h | 2
drivers/net/ehea/ehea_main.c | 72 +--
include/asm-powerpc/cputable.h | 3
include/asm-powerpc/ibmebus.h | 38 -
include/asm-powerpc/of_device.h | 4
include/asm-ppc/mpc52xx_psc.h | 10
include/linux/of_device.h | 5
88 files changed, 3010 insertions(+), 483 deletions(-)
create mode 100644 arch/powerpc/sysdev/bestcomm/Kconfig
create mode 100644 arch/powerpc/sysdev/bestcomm/Makefile
create mode 100644 arch/powerpc/sysdev/bestcomm/ata.c
create mode 100644 arch/powerpc/sysdev/bestcomm/ata.h
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_ata_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.h
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
create mode 100644 arch/powerpc/sysdev/bestcomm/fec.c
create mode 100644 arch/powerpc/sysdev/bestcomm/fec.h
create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.c
create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.h
create mode 100644 arch/powerpc/sysdev/bestcomm/sram.c
create mode 100644 arch/powerpc/sysdev/bestcomm/sram.h
Anton Blanchard (4):
[POWERPC] Enable SLUB in *_defconfig
[POWERPC] Quieten clockevent printk
[POWERPC] Quieten cache information at boot
[POWERPC] Enable NO_HZ and high res timers for pseries and ppc64 configs
Benjamin Herrenschmidt (1):
[POWERPC] Fix 64 bits vDSO DWARF info for CR register
Domen Puncer (1):
[POWERPC] mpc52xx: device tree changes for FEC and MDIO
Joachim Fenkes (4):
[POWERPC] Move of_device allocation into of_device.[ch]
[POWERPC] ibmebus: Remove bus match/probe/remove functions
[POWERPC] ibmebus: Add device creation and bus probing based on of_device
[POWERPC] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
Kumar Gala (1):
[POWERPC] Fix handling of stfiwx math emulation
Olof Johansson (2):
[POWERPC] Fix 1TB segment detection
[POWERPC] Add 1TB workaround for PA6T
Stephen Rothwell (2):
[POWERPC] Fix copyright symbol
[POWERPC] Fix iSeries_hpte_insert prototype
Sylvain Munaut (7):
[POWERPC] exports rheap symbol to modules
[POWERPC] rheap: Changes config mechanism
[POWERPC] mpc52xx: Update mpc52xx_psc structure with B revision changes
[POWERPC] bestcomm: core bestcomm support for Freescale MPC5200
[POWERPC] bestcomm: ATA task support
[POWERPC] bestcomm: FEC task support
[POWERPC] bestcomm: GenBD task support
Tony Breeds (1):
[POWERPC] Fix vmemmap warning in init_64.c
Tony Li (1):
[POWERPC] Add missing semicolon for fsl_pci.c
^ permalink raw reply
* [PATCH 0/4] [POWERPC] MPC5200: update gpt binding, add restart support
From: Marian Balakowicz @ 2007-10-17 12:56 UTC (permalink / raw)
To: linuxppc-dev
This is a reworked version of patches to MPC5200 common code that were send
together with the TQM5200/CM5200/Motion-PRO board support chnages.
As there are some open issues in a board support code and to avoid
additional respin I would like to have those reviewed first.
[PATCH 1/4] [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions
[PATCH 2/4] [POWERPC] Update device tree binding for mpc5200 gpt
[PATCH 3/4] [POWERPC] Add restart support for mpc52xx based platforms
[PATCH 4/4] [POWERPC] Enable restart support for lite5200 board
Cheers,
Marian Balakowicz
^ permalink raw reply
* [PATCH 1/4] [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions
From: Marian Balakowicz @ 2007-10-17 12:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47160689.4020301@semihalf.com>
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>
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/52xx/mpc52xx_common.c | 21 +++++++++++++++++----
include/asm-powerpc/mpc52xx.h | 1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 3bc201e..74b4b41 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -19,14 +19,12 @@ #include <asm/prom.h>
#include <asm/mpc52xx.h>
-void __iomem *
-mpc52xx_find_and_map(const char *compatible)
+static void __iomem *
+mpc52xx_map_node(struct device_node *ofn)
{
- struct device_node *ofn;
const u32 *regaddr_p;
u64 regaddr64, size64;
- ofn = of_find_compatible_node(NULL, NULL, compatible);
if (!ofn)
return NULL;
@@ -42,8 +40,23 @@ mpc52xx_find_and_map(const char *compati
return ioremap((u32)regaddr64, (u32)size64);
}
+
+void __iomem *
+mpc52xx_find_and_map(const char *compatible)
+{
+ return mpc52xx_map_node(
+ of_find_compatible_node(NULL, NULL, compatible));
+}
+
EXPORT_SYMBOL(mpc52xx_find_and_map);
+void __iomem *
+mpc52xx_find_and_map_path(const char *path)
+{
+ return mpc52xx_map_node(of_find_node_by_path(path));
+}
+
+EXPORT_SYMBOL(mpc52xx_find_and_map_path);
/**
* mpc52xx_find_ipb_freq - Find the IPB bus frequency for a device
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 24751df..9cf05f9 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -242,6 +242,7 @@ #endif /* __ASSEMBLY__ */
#ifndef __ASSEMBLY__
extern void __iomem * mpc52xx_find_and_map(const char *);
+extern void __iomem * mpc52xx_find_and_map_path(const char *path);
extern unsigned int mpc52xx_find_ipb_freq(struct device_node *node);
extern void mpc5200_setup_xlb_arbiter(void);
extern void mpc52xx_declare_of_platform_devices(void);
^ permalink raw reply related
* [PATCH 2/4] [POWERPC] Update device tree binding for mpc5200 gpt
From: Marian Balakowicz @ 2007-10-17 12:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47160689.4020301@semihalf.com>
Add 'fsl,' prefix to 'compatible' property for gpt nodes.
Add 'fsl,' prefix to empty, GPT0 specific 'has-wdt' property.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
Documentation/powerpc/mpc52xx-device-tree-bindings.txt | 4 +-
arch/powerpc/boot/dts/lite5200.dts | 26 +++++------------
arch/powerpc/boot/dts/lite5200b.dts | 26 +++++------------
drivers/char/watchdog/mpc5200_wdt.c | 4 +-
4 files changed, 22 insertions(+), 38 deletions(-)
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
index e59fcbb..fedf7ef 100644
--- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -185,7 +185,7 @@ bestcomm@<addr> dma-controller mpc5200-
Recommended soc5200 child nodes; populate as needed for your board
name device_type compatible Description
---- ----------- ---------- -----------
-gpt@<addr> gpt mpc5200-gpt General purpose timers
+gpt@<addr> gpt fsl,mpc5200-gpt General purpose timers
rtc@<addr> rtc mpc5200-rtc Real time clock
mscan@<addr> mscan mpc5200-mscan CAN bus controller
pci@<addr> pci mpc5200-pci PCI bridge
@@ -213,7 +213,7 @@ cell-index int When multiple devices ar
5) General Purpose Timer nodes (child of soc5200 node)
On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
design supports the internal wdt, then the device node for GPT0 should
-include the empty property 'has-wdt'.
+include the empty property 'fsl,has-wdt'.
6) PSC nodes (child of soc5200 node)
PSC nodes can define the optional 'port-number' property to force assignment
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index bc45f5f..6731763 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -70,18 +70,16 @@
};
gpt@600 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <0>;
reg = <600 10>;
interrupts = <1 9 0>;
interrupt-parent = <&mpc5200_pic>;
- has-wdt;
+ fsl,has-wdt;
};
gpt@610 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <1>;
reg = <610 10>;
interrupts = <1 a 0>;
@@ -89,8 +87,7 @@
};
gpt@620 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <2>;
reg = <620 10>;
interrupts = <1 b 0>;
@@ -98,8 +95,7 @@
};
gpt@630 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <3>;
reg = <630 10>;
interrupts = <1 c 0>;
@@ -107,8 +103,7 @@
};
gpt@640 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <4>;
reg = <640 10>;
interrupts = <1 d 0>;
@@ -116,8 +111,7 @@
};
gpt@650 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <5>;
reg = <650 10>;
interrupts = <1 e 0>;
@@ -125,8 +119,7 @@
};
gpt@660 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <6>;
reg = <660 10>;
interrupts = <1 f 0>;
@@ -134,8 +127,7 @@
};
gpt@670 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <7>;
reg = <670 10>;
interrupts = <1 10 0>;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index a6bb1d0..9d12f28 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -70,18 +70,16 @@
};
gpt@600 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <0>;
reg = <600 10>;
interrupts = <1 9 0>;
interrupt-parent = <&mpc5200_pic>;
- has-wdt;
+ fsl,has-wdt;
};
gpt@610 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <1>;
reg = <610 10>;
interrupts = <1 a 0>;
@@ -89,8 +87,7 @@
};
gpt@620 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <2>;
reg = <620 10>;
interrupts = <1 b 0>;
@@ -98,8 +95,7 @@
};
gpt@630 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <3>;
reg = <630 10>;
interrupts = <1 c 0>;
@@ -107,8 +103,7 @@
};
gpt@640 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <4>;
reg = <640 10>;
interrupts = <1 d 0>;
@@ -116,8 +111,7 @@
};
gpt@650 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <5>;
reg = <650 10>;
interrupts = <1 e 0>;
@@ -125,8 +119,7 @@
};
gpt@660 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <6>;
reg = <660 10>;
interrupts = <1 f 0>;
@@ -134,8 +127,7 @@
};
gpt@670 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <7>;
reg = <670 10>;
interrupts = <1 10 0>;
diff --git a/drivers/char/watchdog/mpc5200_wdt.c b/drivers/char/watchdog/mpc5200_wdt.c
index 564143d..9aaba7a 100644
--- a/drivers/char/watchdog/mpc5200_wdt.c
+++ b/drivers/char/watchdog/mpc5200_wdt.c
@@ -174,7 +174,7 @@ static int mpc5200_wdt_probe(struct of_d
const void *has_wdt;
int size;
- has_wdt = of_get_property(op->node, "has-wdt", NULL);
+ has_wdt = of_get_property(op->node, "fsl,has-wdt", NULL);
if (!has_wdt)
return -ENODEV;
@@ -253,7 +253,7 @@ static int mpc5200_wdt_shutdown(struct o
}
static struct of_device_id mpc5200_wdt_match[] = {
- { .compatible = "mpc5200-gpt", },
+ { .compatible = "fsl,mpc5200-gpt", },
{},
};
static struct of_platform_driver mpc5200_wdt_driver = {
^ permalink raw reply related
* [PATCH 3/4] [POWERPC] Add restart support for mpc52xx based platforms
From: Marian Balakowicz @ 2007-10-17 13:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47160689.4020301@semihalf.com>
Add common helper routines: mpc52xx_map_wdt() and mpc52xx_restart().
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 | 3 +
2 files changed, 48 insertions(+)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 74b4b41..553937b 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -18,6 +18,13 @@ #include <asm/io.h>
#include <asm/prom.h>
#include <asm/mpc52xx.h>
+/*
+ * This variable is mapped in mpc52xx_map_wdt() and used in mpc52xx_restart().
+ * Permanent mapping is required because mpc52xx_restart() can be called
+ * from interrupt context while node mapping (which calls iorenmap())
+ * cannot be used at such point.
+ */
+static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
static void __iomem *
mpc52xx_map_node(struct device_node *ofn)
@@ -126,3 +133,41 @@ mpc52xx_declare_of_platform_devices(void
"Error while probing of_platform bus\n");
}
+void __init
+mpc52xx_map_wdt(void)
+{
+ const void *has_wdt;
+ struct device_node *np;
+
+ /* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
+ * possibly from a interrupt context. */
+
+ for (np = NULL;
+ (np = of_find_compatible_node(np, NULL, "fsl,mpc5200-gpt")) != NULL;
+ ) {
+ /* wdt is only implement on gpt0, check has-wdt property. */
+ has_wdt = of_get_property(np, "fsl,has-wdt", NULL);
+ if (has_wdt) {
+ mpc52xx_wdt = mpc52xx_map_node(np);
+ break;
+ }
+ }
+}
+
+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_wdt) {
+ out_be32(&mpc52xx_wdt->mode, 0x00000000);
+ out_be32(&mpc52xx_wdt->count, 0x000000ff);
+ out_be32(&mpc52xx_wdt->mode, 0x00009004);
+ } else
+ printk("mpc52xx_restart: Can't access wdt. "
+ "Restart impossible, system halted.\n");
+
+ while (1);
+}
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 9cf05f9..39f619f 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -252,6 +252,9 @@ extern unsigned int mpc52xx_get_irq(void
extern int __init mpc52xx_add_bridge(struct device_node *node);
+extern void __init mpc52xx_map_wdt(void);
+extern void mpc52xx_restart(char *cmd);
+
#endif /* __ASSEMBLY__ */
#ifdef CONFIG_PM
^ permalink raw reply related
* [PATCH 4/4] [POWERPC] Enable restart support for lite5200 board
From: Marian Balakowicz @ 2007-10-17 13:02 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47160689.4020301@semihalf.com>
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
lite5200.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 0caa3d9..ce9e3ee 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -143,6 +143,9 @@ #endif
/* Some mpc5200 & mpc5200b related configuration */
mpc5200_setup_xlb_arbiter();
+ /* Map wdt for mpc52xx_restart() */
+ mpc52xx_map_wdt();
+
#ifdef CONFIG_PM
mpc52xx_suspend.board_suspend_prepare = lite5200_suspend_prepare;
mpc52xx_suspend.board_resume_finish = lite5200_resume_finish;
@@ -193,5 +196,6 @@ define_machine(lite5200) {
.init = mpc52xx_declare_of_platform_devices,
.init_IRQ = mpc52xx_init_irq,
.get_irq = mpc52xx_get_irq,
+ .restart = mpc52xx_restart,
.calibrate_decr = generic_calibrate_decr,
};
^ permalink raw reply related
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2007-10-17 13:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18197.58241.482810.3553@cargo.ozlabs.ibm.com>
On 10/17/07, Paul Mackerras <paulus@samba.org> wrote:
> Grant Likely writes:
>
> > There are remaining outstanding comments; but my opinion is that they
> > should be addressed in subsequent patches (performance optimization
> > for mp5200b boards and making the sram management code a generic
> > interface usable by other SoC support code).
> >
> > If you agree; please pull into your tree.
>
> I'll pull it on the understanding that the remaining issues will in
> fact be addressed in the near term.
agreed
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Merge dtc
From: Grant Likely @ 2007-10-17 13:15 UTC (permalink / raw)
To: Grant Likely, Paul Mackerras, Josh Boyer, linuxppc-dev
In-Reply-To: <20071017052220.GA3801@localhost.localdomain>
On 10/16/07, David Gibson <dwg@au1.ibm.com> wrote:
> On Tue, Oct 16, 2007 at 07:17:01AM -0600, Grant Likely wrote:
> > On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > This very large patch incorporates a copy of dtc into the kernel
> > > source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> > > longer an external dependency to build kernels with configurations
> > > which need a dtb file.
> >
> > Powerpc is probably not going to be the only user of dtc. Microblaze
> > will be using it too. Can it be put somewhere more common?
>
> Well, I guess we can move it to scripts/ when microblaze starts using
> it.
>
> Also, tell me more about this microblaze, I'm certainly interested in
> new users of dtc...
It's a 'soft processor'. Implemented in the fabric of an FPGA. It's
a ucLinux target. Xilinx Virtex and Xilinx MicroBlaze targets share a
lot of common devices.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: linux-2.6.git: cannot build PS3 image
From: Geert Uytterhoeven @ 2007-10-17 13:23 UTC (permalink / raw)
To: Scott Wood, Kumar Gala; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0710121531250.757@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2283 bytes --]
On Fri, 12 Oct 2007, Geert Uytterhoeven wrote:
> On Fri, 12 Oct 2007, Geert Uytterhoeven wrote:
> > On current linux-2.6.git (782e3b3b3804c38d5130c7f21d7ec7bf6709023f), I get:
> >
> > | WRAP arch/powerpc/boot/zImage.ps3
> > | DTC: dts->dtb on file "/usr/people/geert.nba/ps3/ps3-linux-2.6/arch/powerpc/boot/dts/ps3.dts"
> > | ln: accessing `arch/powerpc/boot/zImage.ps3': No such file or directory
> >
> > `make V=1' gives:
> >
> > | /bin/sh ps3-linux-2.6/arch/powerpc/boot/wrapper -c -o arch/powerpc/boot/zImage.ps3 -p ps3 -C "ppu-" -s ps3-linux-2.6/arch/powerpc/boot/dts/ps3.dts vmlinux
> > | DTC: dts->dtb on file "ps3-linux-2.6/arch/powerpc/boot/dts/ps3.dts"
> > | ln: accessing `arch/powerpc/boot/zImage.ps3': No such file or directory
> >
> > I don't see a change to arch/powerpc/boot/Makefile that could explain this.
>
> After bisecting between 2.6.23 and current, I found the culprit:
>
> > commit 11c146cc19df337f4af42dade9e4fca33c5a54ee
> > Author: Scott Wood <scottwood@freescale.com>
> > Date: Fri Sep 14 14:58:25 2007 -0500
> >
> > [POWERPC] 8xx/wrapper: Embedded Planet EP88xC support
> Below is a quick and dirty temporary fix:
>
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index 39b27e5..795f988 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -232,7 +232,7 @@ base=0x`${CROSS}nm "$ofile" | grep ' _start$' | cut -d' ' -f1`
> entry=`${CROSS}objdump -f "$ofile" | grep '^start address ' | cut -d' ' -f3`
>
> if [ -n "$binary" ]; then
> - mv "$ofile" "$ofile".elf
> + cp "$ofile" "$ofile".elf
> ${CROSS}objcopy -O binary "$ofile".elf "$ofile".bin
> fi
No comments?
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
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