* Define termios_1 functions for powerpc, s390, avr32 and frv
From: Paul Mackerras @ 2007-09-12 15:16 UTC (permalink / raw)
To: Linus Torvalds, akpm
Cc: Michael Neuling, hskinnemoen, heiko.carstens, linux-kernel,
linuxppc-dev, Alan Cox, davem
Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
on all architectures. However, powerpc, s390, avr32 and frv don't
currently define those functions since their termios struct didn't
need to be changed when the arbitrary baud rate stuff was added, and
thus the kernel won't currently build on those architectures.
This adds definitions of kernel_termios_to_user_termios_1 and
user_termios_to_kernel_termios_1 to include/asm-generic/termios.h
which are identical to kernel_termios_to_user_termios and
user_termios_to_kernel_termios respectively. The definitions are the
same because the "old" termios and "new" termios are in fact the same
on these architectures (which are the same ones that use
asm-generic/termios.h).
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Linus, this seems a bit cleaner than putting ifdefs in
drivers/char/tty_ioctl.c, and it fixes the compile error on powerpc.
Your choice whether to use this patch or Tony's.
diff --git a/include/asm-generic/termios.h b/include/asm-generic/termios.h
index 3769e6b..33dca30 100644
--- a/include/asm-generic/termios.h
+++ b/include/asm-generic/termios.h
@@ -63,6 +63,8 @@ static inline int kernel_termios_to_user_termio(struct termio __user *termio,
#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, sizeof(struct termios))
#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct termios))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u, sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k, sizeof(struct termios))
#endif /* __ARCH_TERMIO_GETPUT */
^ permalink raw reply related
* Re: [POWERPC] PCI Bug fix for MRM failure in PPC 440EPx
From: Kumar Gala @ 2007-09-12 15:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070912094536.013bf903@weaponx.rchland.ibm.com>
On Sep 12, 2007, at 9:45 AM, Josh Boyer wrote:
> On Thu, 30 Aug 2007 10:33:28 +0200
> Stefan Roese <ml@stefan-roese.de> wrote:
>
>> Problem Description and Fix : Memory Read Multiples(MRM) do not work
>> correctly on PPC 440EPX based systems. A PCI driver determines
>> whether
>> MRMs are supported by reading the PCI cache line size register. If
>> this
>> value is zero then MRMs are not supported. However some PCI drivers
>> write to the PCI cache line size register on initialization. This
>> results in MRMs being sent to system memory on 440EPX based systems.
>> Since MRMs do not work correctly in 440EPX based systems this may
>> cause
>> system hang. This patch solves this problem by modifying the PPC
>> platform specific PCI configuration register write function, by
>> forcing
>> any value written to PCI_CACHE_LINE_SIZE register to be 0. This
>> fix was
>> tested on different PCI cards : i.e. Silicon Image ATA card and Intel
>> E1000 GIGE card. On Silicon Image ATA card without this fix in place
>> creating a filesystem on IDE drive "mke2fs /dev/hda" was hanging the
>> system. MRMs issued by the PCI card were seen on the PCI analyzer
>> since
>> the Silicon Image driver was setting the PCI_CACHE_LINE_SIZE
>> register to
>> 255. With this patch the PCI_CACHE_LINE_SIZE register was 0 and only
>> Memory Reads were seen on PCI analyzer.
>>
>> Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>>
>> ---
>> I know this patch is a little "dirty", but perhaps somebody has a
>> better
>> idea to fix this problem. Thanks.
>
> For the peanut gallery, Stefan and I discussed this a bit on IRC today
> and a different approach for arch/powerpc is going to be looked at
> instead. Namely, introducing a new flag for indirect_type in the
> pci_controller structure to key off of instead of having ifdefs.
I assume you'll be adding to the 'quirk' flags that we already have
in place.
- k
^ permalink raw reply
* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Scott Wood @ 2007-09-12 15:19 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <46B96294322F7D458F9648B60E15112C85D755@zch01exm26.fsl.freescale.net>
On Wed, Sep 12, 2007 at 03:13:09AM -0700, Zhang Wei-r63237 wrote:
> I have a strange issue here. If I rename 'fsl,dma' to 'fsl,mpc8540-dma',
> the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
> DMA channel.
What tree are you using? Commit 804ace8881d211ac448082e871dd312132393049
in Paul's git tree should have fixed that.
-Scott
^ permalink raw reply
* Re: new NAPI interface broken for POWER architecture?
From: Arnd Bergmann @ 2007-09-12 15:18 UTC (permalink / raw)
To: Christoph Raisch
Cc: ossthema, Paul Mackerras, netdev, Jan-Bernd Themann, linuxppc-dev,
Michael Ellerman, shemminger, David Miller
In-Reply-To: <OF2D6ED296.BDB04FBF-ONC1257354.00473703-C1257354.0048406C@de.ibm.com>
On Wednesday 12 September 2007, Christoph Raisch wrote:
> David Miller <davem@davemloft.net> wrote on 12.09.2007 14:50:04:
>
> > I agree that it should be fixed, but we should also fix the IRQ
> > distribution scheme used on powerpc platforms which is totally
> > broken in these cases.
>
> This is definitely not something we can change in the HEA device driver
> alone.
> It could also affect any other networking cards on POWER (e1000,s2io...).
>
> Paul, Michael, Arndt, what is your opinion here?
The situation on Cell with the existing south bridge chips is that
interrupts _never_ get moved around, but are routed to specific
SMT threads by the firmware, while Linux does not interfere with
this.
We have been thinking about changing this so we can distribute
interrupts over all SMT threads in a given NUMA node, or even
over all logical CPUs in the system by reprogramming the
interrupt controller after each interrupt, but the current Axon bridge
chip will always have all devices routed to the same target CPU,
so it's unclear whether that is even an advantage.
Arnd <><
^ permalink raw reply
* Patches for 2.6.24
From: Grant Likely @ 2007-09-12 15:48 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev, Paul Mackerras
Kumar, can you please pick up the following patches and push them to paulus?
http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
http://patchwork.ozlabs.org/linuxppc/patch?id=13235
http://patchwork.ozlabs.org/linuxppc/patch?id=13249
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Patches for 2.6.24
From: Kumar Gala @ 2007-09-12 15:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <fa686aa40709120848x4720554jc46c8cd9ae3f355@mail.gmail.com>
On Sep 12, 2007, at 10:48 AM, Grant Likely wrote:
> Kumar, can you please pick up the following patches and push them
> to paulus?
>
> http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
I'll hand this one.
> http://patchwork.ozlabs.org/linuxppc/patch?id=13235
> http://patchwork.ozlabs.org/linuxppc/patch?id=13249
bootwrapper patches should be ack'd by david gibson and picked up by
paul at this point.
Did you have some other 834x defconfig updates as well?
- k
^ permalink raw reply
* Re: still using stabs debug format?
From: Kumar Gala @ 2007-09-12 16:00 UTC (permalink / raw)
To: bje, Ulrich Weigand
Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, Ed Swarthout
In-Reply-To: <0D968216-6743-498E-9723-F029FF3746C1@kernel.crashing.org>
Ben, Uli
Paul/BenH suggested that you might be able to help with my question.
> On Aug 17, 2007, at 7:54 PM, Segher Boessenkool wrote:
>
>>> Is anyone really still using the stabs format for kernel debug?
>>>
>>> can we kill off the .stabs references?
>>
>> What, you want to replace them with dwarf markup? Or just
>> get rid of the debug info completely?
>
> There are two users today:
>
> * N_SO for file information we can easily make into .file
> * N_FUN used in _GLOBAL() that marks it a 'function' is a bit
> misleading since we use this for both functions and data. Not sure
> what to do about that one, any suggestions?
#define _GLOBAL(n) \
.text; \
.stabs __stringify(n:F-1),N_FUN,0,0,n;\
.globl n; \
n:
this is the .stabs reference I'm trying to figure out what the dwarf
equiv would be.
- k
^ permalink raw reply
* Re: Patches for 2.6.24
From: Grant Likely @ 2007-09-12 16:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <B658701C-576E-459B-9FF4-BF43B429FCBB@kernel.crashing.org>
On 9/12/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 12, 2007, at 10:48 AM, Grant Likely wrote:
>
> > Kumar, can you please pick up the following patches and push them
> > to paulus?
> >
> > http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
>
> I'll hand this one.
>
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13235
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13249
>
> bootwrapper patches should be ack'd by david gibson and picked up by
> paul at this point.
Okay, David has already acked these. Paulus, can you please pick them up?
Thanks,
g.
>
> Did you have some other 834x defconfig updates as well?
I did; but it look like I need to rebase it again. I'll try to get
that done today.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-12 16:04 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <200709120917.29767.matthias.fuchs@esd-electronics.com>
Hi Matthias,
> I must admit, that the AMCC PowerPC's PCI interrupt capabilities could
> be better:-) In both directions the host CPU has to do PCI
> configuration cycles either to generate or acknowledge an interrupt.
> The later is problematic for some OS coming from Redmond: you
> have to do pci configuration cycles from interrupt level - and
> these OS do not 'like' that.
Yikes. I'm sure there were some headaches there.
> In later designs and where possible we also switched to alternative
> interrupt mechanisms (GPIO for target to host and gated flags in FPGA
> registers for the other direction). Multiple interrupt sources
> are identified by messages that are written to the other sides
> memory.
>
> I think we should stop this discussion because its a little bit
> off-topic on this list.
I think this particular piece of info is important on
this list. It'll help those looking for processor options
that happen to search back through the list messages.
I'm done now, I just wanted to satisfy my curiosity
(and I did learn how the host can interrupt the core!).
I know that Leonid has hardware with these CPUs on them,
and he wanted some feedback on the AMCCs as target processor.
I'd eliminated the processor before getting it fully into
a design; so your experience is a little further on.
However, the conclusion remains the same; try to avoid
using the 440EP as a PCI target device.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Vitaly Bordug @ 2007-09-12 16:07 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200709121013.51500.arnd@arndb.de>
On Wed, 12 Sep 2007 10:13:50 +0200
Arnd Bergmann wrote:
> On Wednesday 12 September 2007, Vitaly Bordug wrote:
>
> >
> > Well, it's more a rewrite than a move, based on 64-bit
> > implementation.
>
> ok.
>
> > > Could you perhaps split the patch into two separate changesets,
> > > one that makes both functions identical in place, and one that
> > > merges them to live in a common location?
> > >
> > I'm not sure I'm following what you are requesting. What is a
> > benefit of code duplication? I was thinking about, if it will look
> > good enough, to provide this function at generic level but changing
> > its name a little, while leaving old stuff in place, and
> > encouraging people to use it in favour of 32 or 64-bit-specific
> > approaches. That way we won't kill many boards at once(in case, for
> > example,odd dts with missed ranges for pci subnode).
>
> I wasn't suggesting to leave the duplicated code in, but rather to
> make the review easier by first modifying the code in place.
>
> If you're taking the 64 bit code as a base, you can for instance make
> the first patch leave pci_32 alone, and modify the 64 bit
> pci_process_bridge_OF_ranges to look exactly like the merged version.
> That allows us to see what changed in the 64 bit case.
>
> The second patch would then move the functions over, but leave the
> code identical to the result of the first patch.
>
ok, makes sense, will do it that way.
> > > > diff --git a/include/asm-powerpc/ppc-pci.h
> > > > b/include/asm-powerpc/ppc-pci.h index b847aa1..882b8bc 100644
> > > > --- a/include/asm-powerpc/ppc-pci.h
> > > > +++ b/include/asm-powerpc/ppc-pci.h
> > > > @@ -15,6 +15,13 @@
> > > > #include <linux/pci.h>
> > > > #include <asm/pci-bridge.h>
> > > >
> > > > +struct ranges_pci {
> > > > + unsigned int pci_space;
> > > > + u64 pci_addr;
> > > > + phys_addr_t phys_addr;
> > > > + u64 size;
> > > > +} __attribute__((packed));
> > > > +
> > >
> > > This structure definition uses unaligned members because of the
> > > 'packed' attribute. Is that really what you intended?
> > >
> > yes, exactly, because I'm mapping this struct on ranges extracted
> > from the dts instead of juggling with ranges[foo] offsets.
>
> I see. It does however look wrong to me, because you are using a
> hardcoded phys_addr_t type. This breaks when phys_addr has a
> different size from what you expect, e.g. when booting a pure 32 bit
> kernel on a machine that has a 64 bit physical address space.
>
I wondered around with "32 bit phys" and "64 bit phys" struct definitions first, but, well, it does not look good.
In fact it already verified with alike case (on 4xx), and I thought it would be fair tradeoff to have 64 bit ranges definition.
otoh, there might be cases when phys_addr_t is u64 and pci stuff resides on some 32-bit SoC bus. I will try to address that next iteration.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Define termios_1 functions for powerpc, s390, avr32 and frv
From: Linus Torvalds @ 2007-09-12 16:09 UTC (permalink / raw)
To: Paul Mackerras
Cc: Michael Neuling, hskinnemoen, heiko.carstens, linux-kernel,
linuxppc-dev, Alan Cox, akpm, davem
In-Reply-To: <18152.719.316280.579601@cargo.ozlabs.ibm.com>
On Thu, 13 Sep 2007, Paul Mackerras wrote:
>
> Linus, this seems a bit cleaner than putting ifdefs in
> drivers/char/tty_ioctl.c, and it fixes the compile error on powerpc.
> Your choice whether to use this patch or Tony's.
Yeah, I'll take this one. I just wanted to understand why it triggered at
all.
Andrew - I'm dropping Tony's patch you forwarded, but since it will still
apply cleanly, you should drop it manually from your queues.
Linus
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Jon Smirl @ 2007-09-12 16:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded, Domen Puncer, Babarovic Ivica
In-Reply-To: <fa686aa40709120814h6a73e4a5j5734d086401b0f2d@mail.gmail.com>
On 9/12/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 9/12/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 9/12/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> > > We have the OSELAS.BSP patch stack for the PCM030 working ontop of
> > > Linus' git. It still uses an older version of the Bestcom patches, so if
> > > you do some work in that area, please keep me informed about your
> > > progress.
> >
> > What is the best way to proceed? I need to be on current git since we
> > are integrating a wireless driver that is tracking current git and the
> > mac80211 work.
> >
> > I have Phytec (pcm030) and Efika hardware but I don't have a 5200lite.
> > Our prototype hardware uses the pcm030 module on a custom baseboard.
> >
> > The best thing for me would be to get a FEC driver merged. That is the
> > largest piece of code that is floating around. Getting that merged
> > would give me a stable base to build future patches on.
> >
> > I'd also like to get support for the pcm030 (minus real-time) merged.
> > That isn't a lot of code once FEC is in the kernel.
> >
> > Domen has posted this driver "[RFC PATCH v0.1] net driver: mpc52xx
> > fec". I can work on breaking that up, but I don't have a 5200lite so I
> > will have to port to pcm030. I don't want to start on this if someone
> > else is already doing it.
>
> Sylvain's bestcomm patches need be cleaned up and resubmitted before
> the next merge window opens. AFAIK, the code is pretty much ready,
> and all the comments have been addressed. All that is required is the
> final push to tidy the patchset and post to the list one more time.
> Sylvain said that he was going to get this done last weekend, but I
> haven't heard back from him yet.
>
> Sylvain, if you need help, please let me know. I'll happily take on
> the last bit of tidy work if that's what is needed to be finished
> before the merge window. (And it needs to be ready *before*, not
> during if I'm judging the prevailing winds correctly).
Is a version of this patch set that has been rebased to current git
available? If I have a starting point I can begin working on the
pcm030 support. pcm030 already works, it is just out of tree.
>
> Cheers,
> g.
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
> >
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-12 16:20 UTC (permalink / raw)
To: linuxppc-dev
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Updated device tree based on comments.
arch/powerpc/boot/dts/mpc8572ds.dts | 385 ++++++++
arch/powerpc/configs/mpc8572_ds_defconfig | 1496 +++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 31 +
arch/powerpc/sysdev/fsl_pci.c | 2 +
include/linux/pci_ids.h | 2 +
5 files changed, 1916 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8572ds.dts
create mode 100644 arch/powerpc/configs/mpc8572_ds_defconfig
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts
new file mode 100644
index 0000000..88ddf19
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -0,0 +1,385 @@
+/*
+ * MPC8572 DS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/ {
+ model = "fsl,MPC8572DS";
+ compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8572@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>;
+ bus-frequency = <0>;
+ clock-frequency = <0>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 00000000>; // Filled by U-Boot
+ };
+
+ soc8572@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges = <00000000 ffe00000 00100000>;
+ reg = <ffe00000 00001000>; // CCSRBAR & soc regs, remove once parse code for immrbase fixed
+ bus-frequency = <0>; // Filled out by uboot.
+
+ memory-controller@2000 {
+ compatible = "fsl,mpc8572-memory-controller";
+ reg = <2000 1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <12 2>;
+ };
+
+ memory-controller@6000 {
+ compatible = "fsl,mpc8572-memory-controller";
+ reg = <6000 1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <12 2>;
+ };
+
+ l2-cache-controller@20000 {
+ compatible = "fsl,mpc8572-l2-cache-controller";
+ reg = <20000 1000>;
+ cache-line-size = <20>; // 32 bytes
+ cache-size = <80000>; // L2, 512K
+ interrupt-parent = <&mpic>;
+ interrupts = <10 2>;
+ };
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3100 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ phy0: ethernet-phy@0 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <0>;
+ };
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <1>;
+ };
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <2>;
+ };
+ phy3: ethernet-phy@3 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <3>;
+ };
+ };
+
+ ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <1d 2 1e 2 22 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <23 2 24 2 28 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <26000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <1f 2 20 2 21 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy2>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@27000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <27000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <25 2 26 2 27 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy3>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,mpc8572-guts";
+ reg = <e0000 1000>;
+ fsl,has-rstcr;
+ };
+
+ mpic: pic@40000 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <40000 40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ };
+ };
+
+ pcie@ffe08000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <ffe08000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 80000000 80000000 0 20000000
+ 01000000 0 00000000 ffc00000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ interrupt-map-mask = <fb00 0 0 0>;
+ interrupt-map = <
+ /* IDSEL 0x11 - PCI slot 1 */
+ 8800 0 0 1 &mpic 2 1
+ 8800 0 0 2 &mpic 3 1
+ 8800 0 0 3 &mpic 4 1
+ 8800 0 0 4 &mpic 1 1
+
+ /* IDSEL 0x12 - PCI slot 2 */
+ 9000 0 0 1 &mpic 3 1
+ 9000 0 0 2 &mpic 4 1
+ 9000 0 0 3 &mpic 1 1
+ 9000 0 0 4 &mpic 2 1
+
+ // IDSEL 0x1c USB
+ e000 0 0 0 &i8259 c 2
+ e100 0 0 0 &i8259 9 2
+ e200 0 0 0 &i8259 a 2
+ e300 0 0 0 &i8259 b 2
+
+ // IDSEL 0x1d Audio
+ e800 0 0 0 &i8259 6 2
+
+ // IDSEL 0x1e Legacy
+ f000 0 0 0 &i8259 7 2
+ f100 0 0 0 &i8259 7 2
+
+ // IDSEL 0x1f IDE/SATA
+ f800 0 0 0 &i8259 e 2
+ f900 0 0 0 &i8259 5 2
+
+ >;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ uli1575@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <02000000 0 80000000
+ 02000000 0 80000000
+ 0 20000000
+ 01000000 0 00000000
+ 01000000 0 00000000
+ 0 00100000>;
+ isa@1e {
+ device_type = "isa";
+ #interrupt-cells = <2>;
+ #size-cells = <1>;
+ #address-cells = <2>;
+ reg = <f000 0 0 0 0>;
+ ranges = <1 0 01000000 0 0
+ 00001000>;
+ interrupt-parent = <&i8259>;
+
+ i8259: interrupt-controller@20 {
+ reg = <1 20 2
+ 1 a0 2
+ 1 4d0 2>;
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ interrupts = <9 2>;
+ interrupt-parent =
+ <&mpic>;
+ };
+
+ i8042@60 {
+ #size-cells = <0>;
+ #address-cells = <1>;
+ reg = <1 60 1 1 64 1>;
+ interrupts = <1 3 c 3>;
+ interrupt-parent =
+ <&i8259>;
+
+ keyboard@0 {
+ reg = <0>;
+ compatible = "pnpPNP,303";
+ };
+
+ mouse@1 {
+ reg = <1>;
+ compatible = "pnpPNP,f03";
+ };
+ };
+
+ rtc@70 {
+ compatible = "pnpPNP,b00";
+ reg = <1 70 2>;
+ };
+
+ gpio@400 {
+ reg = <1 400 80>;
+ };
+ };
+ };
+ };
+
+ };
+
+ pcie@ffe09000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <ffe09000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 a0000000 a0000000 0 20000000
+ 01000000 0 00000000 ffc10000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1a 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 4 1
+ 0000 0 0 2 &mpic 5 1
+ 0000 0 0 3 &mpic 6 1
+ 0000 0 0 4 &mpic 7 1
+ >;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ };
+ };
+
+ pcie@ffe0a000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <ffe0a000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 c0000000 c0000000 0 20000000
+ 01000000 0 00000000 ffc20000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1b 2>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 0 1
+ 0000 0 0 2 &mpic 1 1
+ 0000 0 0 3 &mpic 2 1
+ 0000 0 0 4 &mpic 3 1
+ >;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 3a5c3c4..4d44902 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -181,6 +181,23 @@ static int __init mpc8544_ds_probe(void)
}
}
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init mpc8572_ds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,MPC8572DS")) {
+#ifdef CONFIG_PCI
+ primary_phb_addr = 0x8000;
+#endif
+ return 1;
+ } else {
+ return 0;
+ }
+}
+
define_machine(mpc8544_ds) {
.name = "MPC8544 DS",
.probe = mpc8544_ds_probe,
@@ -194,3 +211,17 @@ define_machine(mpc8544_ds) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(mpc8572_ds) {
+ .name = "MPC8572 DS",
+ .probe = mpc8572_ds_probe,
+ .setup_arch = mpc85xx_ds_setup_arch,
+ .init_IRQ = mpc85xx_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = mpc85xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 114c90f..34cad96 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -255,5 +255,7 @@ DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533E, quirk_fsl_pcie_transpare
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544E, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544, quirk_fsl_pcie_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572E, quirk_fsl_pcie_transparent)
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_transparent);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 06d23e1..daedb60 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2100,6 +2100,8 @@
#define PCI_DEVICE_ID_MPC8533 0x0031
#define PCI_DEVICE_ID_MPC8544E 0x0032
#define PCI_DEVICE_ID_MPC8544 0x0033
+#define PCI_DEVICE_ID_MPC8572E 0x0040
+#define PCI_DEVICE_ID_MPC8572 0x0041
#define PCI_DEVICE_ID_MPC8641 0x7010
#define PCI_DEVICE_ID_MPC8641D 0x7011
--
1.5.2.4
^ permalink raw reply related
* Re: Which 2.6 kernel for MPC5200
From: Grant Likely @ 2007-09-12 16:21 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded, Domen Puncer, Babarovic Ivica
In-Reply-To: <9e4733910709120916v187b7b27sf108785261da5f2@mail.gmail.com>
On 9/12/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/12/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 9/12/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 9/12/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> > > > We have the OSELAS.BSP patch stack for the PCM030 working ontop of
> > > > Linus' git. It still uses an older version of the Bestcom patches, so if
> > > > you do some work in that area, please keep me informed about your
> > > > progress.
> > >
> > > What is the best way to proceed? I need to be on current git since we
> > > are integrating a wireless driver that is tracking current git and the
> > > mac80211 work.
> > >
> > > I have Phytec (pcm030) and Efika hardware but I don't have a 5200lite.
> > > Our prototype hardware uses the pcm030 module on a custom baseboard.
> > >
> > > The best thing for me would be to get a FEC driver merged. That is the
> > > largest piece of code that is floating around. Getting that merged
> > > would give me a stable base to build future patches on.
> > >
> > > I'd also like to get support for the pcm030 (minus real-time) merged.
> > > That isn't a lot of code once FEC is in the kernel.
> > >
> > > Domen has posted this driver "[RFC PATCH v0.1] net driver: mpc52xx
> > > fec". I can work on breaking that up, but I don't have a 5200lite so I
> > > will have to port to pcm030. I don't want to start on this if someone
> > > else is already doing it.
> >
> > Sylvain's bestcomm patches need be cleaned up and resubmitted before
> > the next merge window opens. AFAIK, the code is pretty much ready,
> > and all the comments have been addressed. All that is required is the
> > final push to tidy the patchset and post to the list one more time.
> > Sylvain said that he was going to get this done last weekend, but I
> > haven't heard back from him yet.
> >
> > Sylvain, if you need help, please let me know. I'll happily take on
> > the last bit of tidy work if that's what is needed to be finished
> > before the merge window. (And it needs to be ready *before*, not
> > during if I'm judging the prevailing winds correctly).
>
> Is a version of this patch set that has been rebased to current git
> available? If I have a starting point I can begin working on the
> pcm030 support. pcm030 already works, it is just out of tree.
I've got it it my tree. I'll try to push it out today.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Scott Wood @ 2007-09-12 16:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0709121119160.19430@blarg.am.freescale.net>
On Wed, Sep 12, 2007 at 11:20:06AM -0500, Kumar Gala wrote:
> + pcie@0 {
> + reg = <0 0 0 0 0>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> + uli1575@0 {
You need a ranges; in the pcie node, or else nothing can be translated
through it. Linux may let us get away with it currently, but other
parsing code won't.
> + i8259: interrupt-controller@20 {
> + reg = <1 20 2
> + 1 a0 2
> + 1 4d0 2>;
> + clock-frequency = <0>;
> + interrupt-controller;
> + device_type = "interrupt-controller";
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + built-in;
> + compatible = "chrp,iic";
> + interrupts = <9 2>;
> + interrupt-parent =
> + <&mpic>;
> + };
I'd get rid of clock-frequency and built-in.
-Scott
^ permalink raw reply
* [PATCH] [POWERPC] DTS cleanup
From: Kumar Gala @ 2007-09-12 16:54 UTC (permalink / raw)
To: linuxppc-dev
Removed the following cruft from .dts files:
* 32-bit in cpu node -- doesn't exist in any spec and not used by kernel
* built-in for non-standard buses (ISA, PCI)
* Removed #interrupt-cells in places they don't need to be set
* Fixed ranges on lite5200*
---
Exists in my for-2.6.24 branch
arch/powerpc/boot/dts/holly.dts | 1 -
arch/powerpc/boot/dts/kuroboxHD.dts | 2 --
arch/powerpc/boot/dts/kuroboxHG.dts | 2 --
arch/powerpc/boot/dts/lite5200.dts | 7 ++-----
arch/powerpc/boot/dts/lite5200b.dts | 7 ++-----
arch/powerpc/boot/dts/mpc7448hpc2.dts | 4 ----
arch/powerpc/boot/dts/mpc8272ads.dts | 5 -----
arch/powerpc/boot/dts/mpc8313erdb.dts | 3 ---
arch/powerpc/boot/dts/mpc832x_mds.dts | 4 ----
arch/powerpc/boot/dts/mpc832x_rdb.dts | 4 ----
arch/powerpc/boot/dts/mpc8349emitx.dts | 3 ---
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 3 ---
arch/powerpc/boot/dts/mpc834x_mds.dts | 3 ---
arch/powerpc/boot/dts/mpc836x_mds.dts | 4 ----
arch/powerpc/boot/dts/mpc8540ads.dts | 3 ---
arch/powerpc/boot/dts/mpc8541cds.dts | 3 ---
arch/powerpc/boot/dts/mpc8544ds.dts | 3 ---
arch/powerpc/boot/dts/mpc8548cds.dts | 3 ---
arch/powerpc/boot/dts/mpc8555cds.dts | 3 ---
arch/powerpc/boot/dts/mpc8560ads.dts | 5 -----
arch/powerpc/boot/dts/mpc8568mds.dts | 4 ----
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 4 ----
arch/powerpc/boot/dts/mpc866ads.dts | 5 -----
arch/powerpc/boot/dts/mpc885ads.dts | 5 -----
arch/powerpc/boot/dts/prpmc2800.dts | 1 -
25 files changed, 4 insertions(+), 87 deletions(-)
diff --git a/arch/powerpc/boot/dts/holly.dts b/arch/powerpc/boot/dts/holly.dts
index 80a4fab..2ecad82 100644
--- a/arch/powerpc/boot/dts/holly.dts
+++ b/arch/powerpc/boot/dts/holly.dts
@@ -35,7 +35,6 @@
timebase-frequency = <2faf080>;
clock-frequency = <23c34600>;
bus-frequency = <bebc200>;
- 32-bit;
};
};
diff --git a/arch/powerpc/boot/dts/kuroboxHD.dts b/arch/powerpc/boot/dts/kuroboxHD.dts
index 63ba351..7413839 100644
--- a/arch/powerpc/boot/dts/kuroboxHD.dts
+++ b/arch/powerpc/boot/dts/kuroboxHD.dts
@@ -50,7 +50,6 @@ build with: "dtc -f -I dts -O dtb -o kuroboxHD.dtb -V 16 kuroboxHD.dts"
soc10x { /* AFAICT need to make soc for 8245's uarts to be defined */
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
compatible = "mpc10x";
store-gathering = <0>; /* 0 == off, !0 == on */
@@ -104,7 +103,6 @@ build with: "dtc -f -I dts -O dtb -o kuroboxHD.dtb -V 16 kuroboxHD.dts"
compatible = "chrp,open-pic";
interrupt-controller;
reg = <80040000 40000>;
- built-in;
};
pci@fec00000 {
diff --git a/arch/powerpc/boot/dts/kuroboxHG.dts b/arch/powerpc/boot/dts/kuroboxHG.dts
index e8ce0e3..3d7ceb8 100644
--- a/arch/powerpc/boot/dts/kuroboxHG.dts
+++ b/arch/powerpc/boot/dts/kuroboxHG.dts
@@ -50,7 +50,6 @@ build with: "dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16 kuroboxHG.dts"
soc10x { /* AFAICT need to make soc for 8245's uarts to be defined */
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
compatible = "mpc10x";
store-gathering = <0>; /* 0 == off, !0 == on */
@@ -104,7 +103,6 @@ build with: "dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16 kuroboxHG.dts"
compatible = "chrp,open-pic";
interrupt-controller;
reg = <80040000 40000>;
- built-in;
};
pci@fec00000 {
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index d29308f..4783503 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -37,7 +37,6 @@
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
- 32-bit;
};
};
@@ -50,10 +49,9 @@
model = "fsl,mpc5200";
compatible = "mpc5200";
revision = ""; // from bootloader
- #interrupt-cells = <3>;
device_type = "soc";
- ranges = <0 f0000000 f0010000>;
- reg = <f0000000 00010000>;
+ ranges = <0 f0000000 0000c000>;
+ reg = <f0000000 0000c000>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
@@ -69,7 +67,6 @@
device_type = "interrupt-controller";
compatible = "mpc5200-pic";
reg = <500 80>;
- built-in;
};
gpt@600 { // General Purpose Timer
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index f242531..1db7257 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -37,7 +37,6 @@
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
- 32-bit;
};
};
@@ -50,10 +49,9 @@
model = "fsl,mpc5200b";
compatible = "mpc5200";
revision = ""; // from bootloader
- #interrupt-cells = <3>;
device_type = "soc";
- ranges = <0 f0000000 f0010000>;
- reg = <f0000000 00010000>;
+ ranges = <0 f0000000 0000c000>;
+ reg = <f0000000 0000c000>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
@@ -69,7 +67,6 @@
device_type = "interrupt-controller";
compatible = "mpc5200b-pic\0mpc5200-pic";
reg = <500 80>;
- built-in;
};
gpt@600 { // General Purpose Timer
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index c60ad34..70e8a2e 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -31,7 +31,6 @@
timebase-frequency = <0>; // 33 MHz, from uboot
clock-frequency = <0>; // From U-Boot
bus-frequency = <0>; // From U-Boot
- 32-bit;
};
};
@@ -44,7 +43,6 @@
tsi109@c0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "tsi-bridge";
compatible = "tsi109-bridge", "tsi108-bridge";
ranges = <00000000 c0000000 00010000>;
@@ -129,7 +127,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <7400 400>;
- built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
@@ -181,7 +178,6 @@
device_type = "pic-router";
#address-cells = <0>;
#interrupt-cells = <2>;
- built-in;
big-endian;
interrupts = <17 2>;
interrupt-parent = <&mpic>;
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts b/arch/powerpc/boot/dts/mpc8272ads.dts
index 4d09dca..4313054 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -29,7 +29,6 @@
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
- 32-bit;
};
};
@@ -38,7 +37,6 @@
#interrupt-cells = <2>;
interrupt-controller;
reg = <f8200000 f8200004>;
- built-in;
device_type = "pci-pic";
};
@@ -56,7 +54,6 @@
soc8272@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <00000000 f0000000 00053000>;
reg = <f0000000 10000>;
@@ -118,7 +115,6 @@
cpm@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "cpm";
model = "CPM2";
ranges = <00000000 00000000 20000>;
@@ -161,7 +157,6 @@
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
- built-in;
device_type = "cpm-pic";
compatible = "CPM2";
};
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
index c5adbe4..abd73a2 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -29,7 +29,6 @@
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
- 32-bit;
};
};
@@ -41,7 +40,6 @@
soc8313@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
@@ -207,7 +205,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
- built-in;
device_type = "ipic";
};
};
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index f158ed7..e88167d 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -29,7 +29,6 @@
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
- 32-bit;
};
};
@@ -46,7 +45,6 @@
soc8323@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
@@ -163,7 +161,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
- built-in;
device_type = "ipic";
};
@@ -333,7 +330,6 @@
#address-cells = <0>;
#interrupt-cells = <1>;
reg = <80 80>;
- built-in;
big-endian;
interrupts = <20 8 21 8>; //high:32 low:33
interrupt-parent = < &ipic >;
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 7c4beff..01393e6 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -29,7 +29,6 @@
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
- 32-bit;
};
};
@@ -41,7 +40,6 @@
soc8323@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
@@ -132,7 +130,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
- built-in;
device_type = "ipic";
};
@@ -292,7 +289,6 @@
#address-cells = <0>;
#interrupt-cells = <1>;
reg = <80 80>;
- built-in;
big-endian;
interrupts = <20 8 21 8>; //high:32 low:33
interrupt-parent = <&pic>;
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 502f47c..f98c785 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -28,7 +28,6 @@
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
- 32-bit;
};
};
@@ -40,7 +39,6 @@
soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
@@ -244,7 +242,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
- built-in;
device_type = "ipic";
};
};
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index 0b83871..7c89ff7 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@ -28,7 +28,6 @@
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
- 32-bit;
};
};
@@ -40,7 +39,6 @@
soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
@@ -176,7 +174,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
- built-in;
device_type = "ipic";
};
};
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 4810997..f4ba857 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -29,7 +29,6 @@
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
- 32-bit;
};
};
@@ -46,7 +45,6 @@
soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
@@ -332,7 +330,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
- built-in;
device_type = "ipic";
};
};
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index e3f7c12..f14e88e 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -34,7 +34,6 @@
timebase-frequency = <3EF1480>;
bus-frequency = <FBC5200>;
clock-frequency = <1F78A400>;
- 32-bit;
};
};
@@ -51,7 +50,6 @@
soc8360@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
@@ -178,7 +176,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
- built-in;
device_type = "ipic";
};
@@ -364,7 +361,6 @@
#address-cells = <0>;
#interrupt-cells = <1>;
reg = <80 80>;
- built-in;
big-endian;
interrupts = <20 8 21 8>; //high:32 low:33
interrupt-parent = < &ipic >;
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts b/arch/powerpc/boot/dts/mpc8540ads.dts
index fc8dff9..e038c04 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -30,7 +30,6 @@
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // 166 MHz
clock-frequency = <0>; // 825 MHz, from uboot
- 32-bit;
};
};
@@ -42,7 +41,6 @@
soc8540@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00100000>; // CCSRBAR 1M
@@ -268,7 +266,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
- built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
diff --git a/arch/powerpc/boot/dts/mpc8541cds.dts b/arch/powerpc/boot/dts/mpc8541cds.dts
index fb0b647..82f4b06 100644
--- a/arch/powerpc/boot/dts/mpc8541cds.dts
+++ b/arch/powerpc/boot/dts/mpc8541cds.dts
@@ -30,7 +30,6 @@
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // 166 MHz
clock-frequency = <0>; // 825 MHz, from uboot
- 32-bit;
};
};
@@ -42,7 +41,6 @@
soc8541@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00100000>; // CCSRBAR 1M
@@ -240,7 +238,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
- built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index 3e79bf0..a074700 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -30,7 +30,6 @@
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
- 32-bit;
};
};
@@ -42,7 +41,6 @@
soc8544@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
@@ -350,7 +348,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
- built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/boot/dts/mpc8548cds.dts
index d215d21..b88e806 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -30,7 +30,6 @@
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // 166 MHz
clock-frequency = <0>; // 825 MHz, from uboot
- 32-bit;
};
};
@@ -42,7 +41,6 @@
soc8548@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <00001000 e0001000 000ff000
80000000 80000000 10000000
@@ -394,7 +392,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
- built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
diff --git a/arch/powerpc/boot/dts/mpc8555cds.dts b/arch/powerpc/boot/dts/mpc8555cds.dts
index c3c8882..8622174 100644
--- a/arch/powerpc/boot/dts/mpc8555cds.dts
+++ b/arch/powerpc/boot/dts/mpc8555cds.dts
@@ -30,7 +30,6 @@
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // 166 MHz
clock-frequency = <0>; // 825 MHz, from uboot
- 32-bit;
};
};
@@ -42,7 +41,6 @@
soc8555@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00100000>; // CCSRBAR 1M
@@ -240,7 +238,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
- built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
diff --git a/arch/powerpc/boot/dts/mpc8560ads.dts b/arch/powerpc/boot/dts/mpc8560ads.dts
index 16dbe84..cf87c30 100644
--- a/arch/powerpc/boot/dts/mpc8560ads.dts
+++ b/arch/powerpc/boot/dts/mpc8560ads.dts
@@ -30,7 +30,6 @@
timebase-frequency = <04ead9a0>;
bus-frequency = <13ab6680>;
clock-frequency = <312c8040>;
- 32-bit;
};
};
@@ -42,7 +41,6 @@
soc8560@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
@@ -227,14 +225,12 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
- built-in;
device_type = "open-pic";
};
cpm@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "cpm";
model = "CPM2";
ranges = <0 0 c0000>;
@@ -249,7 +245,6 @@
interrupts = <2e 2>;
interrupt-parent = <&mpic>;
reg = <90c00 80>;
- built-in;
device_type = "cpm-pic";
};
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index b1dcfbe..c472a4b 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -34,7 +34,6 @@
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
- 32-bit;
};
};
@@ -51,7 +50,6 @@
soc8568@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00100000>;
@@ -258,7 +256,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
- built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
@@ -449,7 +446,6 @@
#address-cells = <0>;
#interrupt-cells = <1>;
reg = <80 80>;
- built-in;
big-endian;
interrupts = <2e 2 2e 2>; //high:30 low:30
interrupt-parent = <&mpic>;
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index b0166e5..a73b279 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -30,7 +30,6 @@
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // From uboot
clock-frequency = <0>; // From uboot
- 32-bit;
};
PowerPC,8641@1 {
device_type = "cpu";
@@ -42,7 +41,6 @@
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // From uboot
clock-frequency = <0>; // From uboot
- 32-bit;
};
};
@@ -54,7 +52,6 @@
soc8641@f8000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <00001000 f8001000 000ff000
80000000 80000000 20000000
@@ -366,7 +363,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
- built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
diff --git a/arch/powerpc/boot/dts/mpc866ads.dts b/arch/powerpc/boot/dts/mpc866ads.dts
index e5e7726..90f2293 100644
--- a/arch/powerpc/boot/dts/mpc866ads.dts
+++ b/arch/powerpc/boot/dts/mpc866ads.dts
@@ -30,7 +30,6 @@
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
- 32-bit;
interrupts = <f 2>; // decrementer interrupt
interrupt-parent = <&Mpc8xx_pic>;
};
@@ -44,7 +43,6 @@
soc866@ff000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 ff000000 00100000>;
reg = <ff000000 00000200>;
@@ -78,7 +76,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0 24>;
- built-in;
device_type = "mpc8xx-pic";
compatible = "CPM";
};
@@ -86,7 +83,6 @@
cpm@ff000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "cpm";
model = "CPM";
ranges = <0 0 4000>;
@@ -103,7 +99,6 @@
interrupts = <5 2 0 2>;
interrupt-parent = <&Mpc8xx_pic>;
reg = <930 20>;
- built-in;
device_type = "cpm-pic";
compatible = "CPM";
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts b/arch/powerpc/boot/dts/mpc885ads.dts
index dc7ab9c..e9aa9d0 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -30,7 +30,6 @@
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
- 32-bit;
interrupts = <f 2>; // decrementer interrupt
interrupt-parent = <&Mpc8xx_pic>;
};
@@ -44,7 +43,6 @@
soc885@ff000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "soc";
ranges = <0 ff000000 00100000>;
reg = <ff000000 00000200>;
@@ -98,7 +96,6 @@
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0 24>;
- built-in;
device_type = "mpc8xx-pic";
compatible = "CPM";
};
@@ -117,7 +114,6 @@
cpm@ff000000 {
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <2>;
device_type = "cpm";
model = "CPM";
ranges = <0 0 4000>;
@@ -134,7 +130,6 @@
interrupts = <5 2 0 2>;
interrupt-parent = <&Mpc8xx_pic>;
reg = <930 20>;
- built-in;
device_type = "cpm-pic";
compatible = "CPM";
};
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts b/arch/powerpc/boot/dts/prpmc2800.dts
index 5300b50..55684b6 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -47,7 +47,6 @@
mv64x60@f1000000 { /* Marvell Discovery */
#address-cells = <1>;
#size-cells = <1>;
- #interrupt-cells = <1>;
model = "mv64360"; /* Default */
compatible = "marvell,mv64x60";
clock-frequency = <7f28155>; /* 133.333333 MHz */
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-12 17:04 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070912163638.GA16326@ld0162-tx32.am.freescale.net>
On Sep 12, 2007, at 11:36 AM, Scott Wood wrote:
> On Wed, Sep 12, 2007 at 11:20:06AM -0500, Kumar Gala wrote:
>> + pcie@0 {
>> + reg = <0 0 0 0 0>;
>> + #size-cells = <2>;
>> + #address-cells = <3>;
>> + device_type = "pci";
>> + uli1575@0 {
>
> You need a ranges; in the pcie node, or else nothing can be translated
> through it. Linux may let us get away with it currently, but other
> parsing code won't.
ok, wasn't sure. will add that in.
>> + i8259: interrupt-controller@20 {
>> + reg = <1 20 2
>> + 1 a0 2
>> + 1 4d0 2>;
>> + clock-frequency = <0>;
>> + interrupt-controller;
>> + device_type = "interrupt-controller";
>> + #address-cells = <0>;
>> + #interrupt-cells = <2>;
>> + built-in;
>> + compatible = "chrp,iic";
>> + interrupts = <9 2>;
>> + interrupt-parent =
>> + <&mpic>;
>> + };
>
> I'd get rid of clock-frequency and built-in.
I'm leaving them for now to match the others, we can clean them all
up at the same time. Technically built-in is spec'd by the CHRP spec
for ISA/PCI.
As for clock-frequency, not sure where that came from.
- k
^ permalink raw reply
* Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Scott Wood @ 2007-09-12 17:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <AE69C5D1-3910-40F0-80E5-283FDB5199F5@kernel.crashing.org>
On Wed, Sep 12, 2007 at 12:04:20PM -0500, Kumar Gala wrote:
> I'm leaving them for now to match the others, we can clean them all
> up at the same time.
OK.
> Technically built-in is spec'd by the CHRP spec for ISA/PCI.
I looked in the CHRP I/O Device Reference and didn't see it, though I may
have been looking at the wrong document.
> As for clock-frequency, not sure where that came from.
I'm guessing copy-and-paste from mpic.
-Scott
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Domen Puncer @ 2007-09-12 17:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: Babarovic Ivica, Domen Puncer, linuxppc-embedded
In-Reply-To: <9e4733910709120916v187b7b27sf108785261da5f2@mail.gmail.com>
On 12/09/07 12:16 -0400, Jon Smirl wrote:
> On 9/12/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 9/12/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 9/12/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> > > > We have the OSELAS.BSP patch stack for the PCM030 working ontop of
> > > > Linus' git. It still uses an older version of the Bestcom patches, so if
> > > > you do some work in that area, please keep me informed about your
> > > > progress.
> > >
> > > What is the best way to proceed? I need to be on current git since we
> > > are integrating a wireless driver that is tracking current git and the
> > > mac80211 work.
> > >
> > > I have Phytec (pcm030) and Efika hardware but I don't have a 5200lite.
> > > Our prototype hardware uses the pcm030 module on a custom baseboard.
> > >
> > > The best thing for me would be to get a FEC driver merged. That is the
> > > largest piece of code that is floating around. Getting that merged
> > > would give me a stable base to build future patches on.
> > >
> > > I'd also like to get support for the pcm030 (minus real-time) merged.
> > > That isn't a lot of code once FEC is in the kernel.
> > >
> > > Domen has posted this driver "[RFC PATCH v0.1] net driver: mpc52xx
> > > fec". I can work on breaking that up, but I don't have a 5200lite so I
> > > will have to port to pcm030. I don't want to start on this if someone
> > > else is already doing it.
> >
> > Sylvain's bestcomm patches need be cleaned up and resubmitted before
> > the next merge window opens. AFAIK, the code is pretty much ready,
> > and all the comments have been addressed. All that is required is the
> > final push to tidy the patchset and post to the list one more time.
> > Sylvain said that he was going to get this done last weekend, but I
> > haven't heard back from him yet.
> >
> > Sylvain, if you need help, please let me know. I'll happily take on
> > the last bit of tidy work if that's what is needed to be finished
> > before the merge window. (And it needs to be ready *before*, not
> > during if I'm judging the prevailing winds correctly).
>
> Is a version of this patch set that has been rebased to current git
> available? If I have a starting point I can begin working on the
> pcm030 support. pcm030 already works, it is just out of tree.
I think these patches are "latest":
http://www.246tnt.com/mpc52xx/dev_full/
Applying them to -git should not be a problem, I don't remember anything
tricky, but if you have problems, I can send you patches agains mainline.
BTW. I posted FEC patch v2, which will hopefully be merged.
Domen
>
>
> >
> > Cheers,
> > g.
> > >
> > > --
> > > Jon Smirl
> > > jonsmirl@gmail.com
> > >
> >
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > grant.likely@secretlab.ca
> > (403) 399-0195
> >
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Nick Piggin @ 2007-09-11 19:19 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Heiko Schocher, linux-kernel, Detlev Zundel
In-Reply-To: <20070912100123.GA23182@kroah.com>
On Wednesday 12 September 2007 20:01, Greg KH wrote:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > I have developed a device driver and use the sysFS to export some
> > > registers to userspace.
> >
> > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > not to play around with registers from userspace.
> >
> > > I opened the sysFS File for one register and did some reads from this
> > > File, but I alwas becoming the same value from the register, whats not
> > > OK, because they are changing. So I found out that the sysFS caches
> > > the reads ... :-(
> >
> > Yes, it does. What you can do is close()ing the file handle between
> > accesses, which makes it work but is slow.
>
> Do an lseek back to 0 and then re-read, you will get called in your
> driver again.
Can you do a pread with offset 0 to avoid the two syscalls? (which some
people seem to be concerned about)
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Neil Brown @ 2007-09-12 17:57 UTC (permalink / raw)
To: Nick Piggin
Cc: Detlev Zundel, Greg KH, linux-kernel, linuxppc-dev,
Heiko Schocher
In-Reply-To: <200709120519.39960.nickpiggin@yahoo.com.au>
On Wednesday September 12, nickpiggin@yahoo.com.au wrote:
> On Wednesday 12 September 2007 20:01, Greg KH wrote:
> > On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > > I have developed a device driver and use the sysFS to export some
> > > > registers to userspace.
> > >
> > > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > > not to play around with registers from userspace.
> > >
> > > > I opened the sysFS File for one register and did some reads from this
> > > > File, but I alwas becoming the same value from the register, whats not
> > > > OK, because they are changing. So I found out that the sysFS caches
> > > > the reads ... :-(
> > >
> > > Yes, it does. What you can do is close()ing the file handle between
> > > accesses, which makes it work but is slow.
> >
> > Do an lseek back to 0 and then re-read, you will get called in your
> > driver again.
>
> Can you do a pread with offset 0 to avoid the two syscalls? (which some
> people seem to be concerned about)
No.
Looking in fs/sysfs/file.c, we notice the field "needs_read_fill" in
struct sysfs_buffer.
sysfs_read_file will only call fill_read_buffer (which calls the
->show routine) if this is 1;
It is cleared by fill_read_buffer and set to 1:
- at open
- by fill_write_buffer (i.e. if you write to the file descriptor)
- by sysfs_poll when an event was detected.
So currently you cannot simply open a sysfs file an read multiple
times.
One option would be to call fill_read_buffer if *ppos == 0.
I cannot see that being a problem in practice, but maybe there is a
reason why it wasn't done that way.
Another option might be to call fill_read_buffer also if
buffer->event != atomic_read(&attr_sd->s_event)
and require drivers to call sysfs_notify when they make a change that
should be noticed. But I doubt that is really important.
NeilBrown
^ permalink raw reply
* Re: [PATCH] phy: implement release function
From: Andy Fleming @ 2007-09-12 18:21 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070912112601.GE15556@localhost.localdomain>
On Sep 12, 2007, at 06:26, Anton Vorontsov wrote:
> Lately I've got this nice badness on mdio bus removal:
>
> Device 'e0103120:06' does not have a release() function, it is
> broken and must be fixed.
> ------------[ cut here ]------------
> Badness at drivers/base/core.c:107
> NIP: c015c1a8 LR: c015c1a8 CTR: c0157488
> REGS: c34bdcf0 TRAP: 0700 Not tainted (2.6.23-rc5-g9ebadfbb-dirty)
> MSR: 00029032 <EE,ME,IR,DR> CR: 24088422 XER: 00000000
> ...
> [c34bdda0] [c015c1a8] device_release+0x78/0x80 (unreliable)
> [c34bddb0] [c01354cc] kobject_cleanup+0x80/0xbc
> [c34bddd0] [c01365f0] kref_put+0x54/0x6c
> [c34bdde0] [c013543c] kobject_put+0x24/0x34
> [c34bddf0] [c015c384] put_device+0x1c/0x2c
> [c34bde00] [c0180e84] mdiobus_unregister+0x2c/0x58
> ...
>
> Though actually there is nothing broken, it just device
> subsystem core expects another "pattern" of resource managment.
>
> This patch implement phy device's release function, thus
> we're getting rid of this badness.
>
> Also small hidden bug fixed, hope none other introduced. ;-)
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Andy
^ permalink raw reply
* Please pull powerpc.git merge branch again
From: Paul Mackerras @ 2007-09-12 18:26 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 four small bug-fixes for embedded powerpc from Kumar, plus a
one-liner from Olof that I missed putting in the previous batch.
Thanks,
Paul.
arch/powerpc/kernel/legacy_serial.c | 2 +-
arch/powerpc/platforms/85xx/mpc8544_ds.c | 2 ++
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 ++
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 ++
arch/powerpc/platforms/Kconfig | 1 +
arch/powerpc/sysdev/cpm2_common.c | 2 +-
arch/ppc/kernel/head_8xx.S | 2 --
8 files changed, 10 insertions(+), 5 deletions(-)
commit ee56c47440ab04c6a35c835a9bcc4193304adf93
Author: Olof Johansson <olof@lixom.net>
Date: Wed Aug 22 19:26:37 2007 -0500
[POWERPC] Move serial_dev_init to device_initcall()
With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
initcall is now called before I/O space is setup, but it's dependent on
it being available.
Since there's no way to make dependencies between initcalls, we'll just
have to move it to device_initcall(). Yes, it's suboptimal but I'm not
aware of any better solution at this time, and it fixes a regression
from 2.6.22.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit fb4f0e8832e0075849b41b65f6bb9fdfa7593b99
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Mon Sep 10 14:57:34 2007 -0500
[POWERPC] Enable GENERIC_ISA_DMA if FSL_ULI1575 to fix compile issue
Since the ULI1575 has a ISA bus we need to enable the generic ISA dma
support for drivers that might expect it. Without this we get compile
errors like the following:
ound/built-in.o: In function `claim_dma_lock':
/home/galak/git/linux-8572/include/asm/dma.h:189: undefined reference to `dma_spin_lock'
/home/galak/git/linux-8572/include/asm/dma.h:189: undefined reference to `dma_spin_lock'
sound/built-in.o: In function `release_dma_lock':
/home/galak/git/linux-8572/include/asm/dma.h:195: undefined reference to `dma_spin_lock'
sound/built-in.o: In function `claim_dma_lock':
/home/galak/git/linux-8572/include/asm/dma.h:189: undefined reference to `dma_spin_lock'
/home/galak/git/linux-8572/include/asm/dma.h:189: undefined reference to `dma_spin_lock'
sound/built-in.o:/home/galak/git/linux-8572/include/asm/dma.h:195: more undefined references to `dma_spin_lock' follow
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 83fcdb4b352f74a8a74737aedeaf622c37140c73
Author: Scott Wood <scottwood@freescale.com>
Date: Wed Sep 5 14:29:10 2007 -0500
[POWERPC] cpm2: Fix off-by-one error in setbrg().
The hardware adds one to the BRG value to get the divider, so it must
be subtracted by software. Without this patch, characters will occasionally
be corrupted.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 36c50f729b77144cae8d43457fefca66a4eeff6a
Author: Jochen Friedrich <jochen@scram.de>
Date: Tue Aug 28 13:20:48 2007 +0200
[PPC] 8xx: Fix r3 trashing due to 8MB TLB page instantiation
Instantiation of 8MB pages on the TLB cache for the kernel static
mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations.
This ensures r3 gets saved and restored.
This has been posted to linuxppc-embedded by Marcelo Tosatti
<marcelo@kvack.org>, but only an incomplete version of the patch
has been applied in c51e078f82096a7d35ac8ec2416272e843a0e1c4.
This patch adds the rest of the fix.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 2af8569dc9f29c303bf4aa012d991afcfaeed0c3
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Mon Sep 10 14:30:33 2007 -0500
[POWERPC] 8{5,6}xx: Fix build issue with !CONFIG_PCI
We needed some ifdef CONFIG_PCI protection for pcibios_fixup so we
can build !CONFIG_PCI.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: S. Fricke @ 2007-09-12 18:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40709111205n5d9f9654m6f2b96d468dfd017@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]
Hello,
> > I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> > "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> >
> > THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> > paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
> > IRQ-2 on a mpc5200b?
>
> The irq number you pass into request_irq is a system-wide irq number;
> it doesn't necessarily map directly onto the MPC52xx irq number.
> Typically, you'd have a node for your device in the device tree which
> has a phandle back to the interrupt node and you would use
> irq_of_parse_and_map() to map it back to a system-wide irq number.
The IRQ-pin-2 belongs to "PIN-configuration-nodes" described in
"booting-without-of.txt"? Than, what is the QE for my MPC5200B?
Can u give me an example with a single IRQ of a configuration-node for a
dts?
TIA:
Silvio
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: fricke@jabber.org
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Grant Likely @ 2007-09-12 19:29 UTC (permalink / raw)
To: S. Fricke; +Cc: linuxppc-dev
In-Reply-To: <20070912183038.GA5682@sfrouter>
On 9/12/07, S. Fricke <silvio.fricke@googlemail.com> wrote:
> Hello,
>
> > > I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> > > "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> > >
> > > THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> > > paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
> > > IRQ-2 on a mpc5200b?
> >
> > The irq number you pass into request_irq is a system-wide irq number;
> > it doesn't necessarily map directly onto the MPC52xx irq number.
> > Typically, you'd have a node for your device in the device tree which
> > has a phandle back to the interrupt node and you would use
> > irq_of_parse_and_map() to map it back to a system-wide irq number.
>
> The IRQ-pin-2 belongs to "PIN-configuration-nodes" described in
> "booting-without-of.txt"? Than, what is the QE for my MPC5200B?
>
> Can u give me an example with a single IRQ of a configuration-node for a
> dts?
myreallycooldevice@0 {
interrupts = <1 2 3>;
interrupt-parent = <&mpc5200_pic>;
};
The interrupts property matches the size of the #interrupt-cells
property in the interrupt controller node. For the 5200-intc, each
interrupt is described by 3 cells; l1, l2 and sense which is a
reflection of the interrupt controller architecture. For IRQ0, l1=0,
l2=0; IRQ1, l1=1, l2=1; IRQ2, l1=1 and l2=2; IRQ3, l1=1, l2=3 Sense is
described in mpc52xx-device-tree-bindings.txt
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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