* Re: Driver for device behind a PCI-VME bridge
From: Johan Borkhuis @ 2007-08-20 8:45 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-embedded
In-Reply-To: <929bf310708200140w6efc57f6k81a1339845059e2d@mail.gmail.com>
Hello Konstantin,
Konstantin Boyanov wrote:
> Hi list,
>
> I'm currently reading the LDD 3rd Edition and trying to create a
> device driver for a custom device located on VME bus. I have already
> linux 2.6.15 running on the master board, as well as the device driver
> for the PCI-VME bridge. The main problem I have is understanding how
> to "attach" my driver for the custom device to the bridge device driver.
> The bridge device driver is implemented as a class, i.e. doesn't
> define a new bus type. Should I define a new class for my driver, or
> should I connect it somehow to the existing one (maybe by something as
> "subclass")?
> All I want to do is to redirect I/O reads and writes to the VME bus,
> but I got no clue as to how to use the existing VME bridge driver for
> this purpose. After I get through this I think all other things (VME
> interrupt registration & handling, etc.) will be straightforward.
> The LDD 3rd book states that defining a new bus type is the last thing
> one would like to do, instead defining a class is far better approach.
> Why is that?
>
> Any recommendations and sharing of practical experience are highly
> appreciated.
I am also working on a VME-board. What I did was use mmap to map
specific parts of the VME-memory into user space.
BTW: what kind of board and Linux-flavor are you using?
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Driver for device behind a PCI-VME bridge
From: Konstantin Boyanov @ 2007-08-20 8:40 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
Hi list,
I'm currently reading the LDD 3rd Edition and trying to create a device
driver for a custom device located on VME bus. I have already linux
2.6.15running on the master board, as well as the device driver for
the PCI-VME
bridge. The main problem I have is understanding how to "attach" my driver
for the custom device to the bridge device driver.
The bridge device driver is implemented as a class, i.e. doesn't define a
new bus type. Should I define a new class for my driver, or should I connect
it somehow to the existing one (maybe by something as "subclass")?
All I want to do is to redirect I/O reads and writes to the VME bus, but I
got no clue as to how to use the existing VME bridge driver for this
purpose. After I get through this I think all other things (VME interrupt
registration & handling, etc.) will be straightforward.
The LDD 3rd book states that defining a new bus type is the last thing one
would like to do, instead defining a class is far better approach. Why is
that?
Any recommendations and sharing of practical experience are highly
appreciated.
Best Regards,
Konstantin
[-- Attachment #2: Type: text/html, Size: 1200 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Domen Puncer @ 2007-08-20 8:31 UTC (permalink / raw)
To: Matt Sealey; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <46C8643B.7010104@genesi-usa.com>
On 19/08/07 16:39 +0100, Matt Sealey wrote:
> Domen,
>
> Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
> Linux with more fixups. The Efika PHY isn't going to change to something
> else and it's a bog standard no-frills MII PHY anyway.
Fine with me, but I'm worried people won't update nvramrc.
Currently I have this:
--- start ---
s" /builtin" find-device
new-device
1 encode-int s" #address-cells" property
0 encode-int s" #size-cells" property
s" mdio" 2dup device-name device-type
s" mpc5200b-fec-phy" s" compatible" property
0xf0003000 0x400 reg
0x2 encode-int
0x5 encode-int
0x3 encode-int
encode+ encode+
s" interupts" property
new-device
s" ethernet-phy@0" device-name
s" ethernet-phy" device-type
0 encode-int s" reg" property
my-self \ save our phandle to stack
ihandle>phandle
finish-device
finish-device
s" /builtin/ethernet" find-device
encode-int \ phy's phandle
s" phy-handle" property
device-end
--- end ---
But I have a problem with it, possibly due to my not-knowledge of Forth.
Compatible keep getting set to:
compatible "/builtin/etherne"
<spin>
> If you insist on using prom_init and fixups, yaboot has the best
> examples of call-method and interpret, both readable and fairly
> easily available.
Thanks.
Domen
> > On 10/08/07 11:51 +0200, Domen Puncer wrote:
> >> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> >> ===================================================================
> >> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
> >> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> >> + mdio@3000 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + device_type = "mdio";
> >> + compatible = "mpc5200b-fec-phy";
> >> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> >> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> >> + interrupt-parent = <&mpc5200_pic>;
> >> +
> >> + phy0:ethernet-phy@0 {
> >> + device_type = "ethernet-phy";
> >> + reg = <0>;
> >> + };
> >> };
> >
> > I am struggling with this part on Efika.
> > I would like to add this to the device tree from
> > fixup_device_tree_efika() (arch/powerpc/kernel/prom_init.c).
> >
> > AFAICS client-services doesn't offer anything like new-device,
> > so I guess "interpret" or "call-method" will have to be used.
> >
> > I have read some docs, but I'm still wandering in the dark.
> > Can I please get an example?
> > Pretty please with a cherry on top?
> >
> >
> > Domen
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 0/3 v2] Remove need for include/asm-ppc
From: David Gibson @ 2007-08-20 6:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0708181203320.31362@blarg.am.freescale.net>
On Sat, Aug 18, 2007 at 12:05:36PM -0500, Kumar Gala wrote:
> This patch series removes the need for include/asm-ppc in the ARCH=powerpc
> build for ppc32. They exist in the following git tree:
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
>
> posting here for everyone else to see.
>
> Updated with changes suggested by Arnd & Segher. (removal 82xx pci header
> and moving some headers under platforms if not globally needed).
Nice! I'm hoping the next step after this is to do the other way
around - make ARCH=ppc builds independent of things in arch/powerpc or
include/asm-powerpc, which is almost the more important change.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/3 v2][POWERPC] Stop include asm-ppc when building ARCH=powerpc for ppc32
From: Paul Mackerras @ 2007-08-20 5:57 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
In-Reply-To: <18121.11392.459659.535657@cargo.ozlabs.ibm.com>
I wrote:
> On 32-bit powermac, I get:
>
> CC [M] drivers/macintosh/ans-lcd.o
> /home/paulus/kernel/powerpc/drivers/macintosh/ans-lcd.c:17:25: error: asm/ans-lcd.h: No such file or directory
>
> plus a whole pile of things undefined after that.
And on mpc7448_hpc2 I get
CC arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.o
In file included from /home/paulus/kernel/powerpc/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c:43:
/home/paulus/kernel/powerpc/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.h:19:25: error: asm/ppcboot.h: No such file or directory
Paul.
^ permalink raw reply
* some error about nfs
From: 李明 @ 2007-08-20 5:55 UTC (permalink / raw)
To: linux-arch; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
hello,everyone
when I open nfs on my linux server, and set the bootargs in the uboot, there is some error like this:
IP-Config: Device `off' not found.
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
lec.c: Aug 20 2007 13:01:25 initialized
Looking up port of RPC 100003/2 on 192.168.2.172
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.2.172
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /home/lim/Ramdisk
what is wrong, and what should I do ?
--------------
李 明
MSN:lim.live@msn.com
务实奋斗，不断挑战
2007-08-20
[-- Attachment #2: man_016.gif --]
[-- Type: image/gif, Size: 1729 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3 v2][POWERPC] Stop include asm-ppc when building ARCH=powerpc for ppc32
From: Paul Mackerras @ 2007-08-20 5:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0708181210390.31362@blarg.am.freescale.net>
Kumar Gala writes:
> We no longer have any dependancies on include/asm-ppc so we can get ride
> of the makefile hacks to include it in the build process.
On 32-bit powermac, I get:
CC [M] drivers/macintosh/ans-lcd.o
/home/paulus/kernel/powerpc/drivers/macintosh/ans-lcd.c:17:25: error: asm/ans-lcd.h: No such file or directory
plus a whole pile of things undefined after that.
Paul.
^ permalink raw reply
* Please pull Kumar's fixes-2.6.23 branch
From: Paul Mackerras @ 2007-08-20 5:27 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git fixes-2.6.23
to get four commits from Kumar that fix some bugs in the platform
support for Freescale PowerPC platforms.
One of the commits looks rather large, but that is because rather than
fix the same bugs in two places, Kumar moved a chunk of almost
identical code for two platforms into a single file that is used for
both platforms, and fixed the bugs in one place. Also, the affected
files are only used on some Freescale embedded platforms, so the
number of users that could be affected by this is small.
Thanks,
Paul.
arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
arch/powerpc/kernel/traps.c | 4
arch/powerpc/platforms/85xx/Kconfig | 1
arch/powerpc/platforms/85xx/mpc8544_ds.c | 214 ++---------------------
arch/powerpc/platforms/86xx/Kconfig | 1
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224 ++-----------------------
arch/powerpc/platforms/Kconfig | 8 +
arch/powerpc/platforms/Makefile | 3
arch/powerpc/platforms/fsl_uli1575.c | 255 ++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_soc.c | 1
arch/powerpc/sysdev/rtc_cmos_setup.c | 17 +-
include/asm-powerpc/reg_booke.h | 12 +
13 files changed, 389 insertions(+), 553 deletions(-)
create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
commit 0af666fa6cf4bc639fb6170600b5fb0d8b6504b9
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Fri Aug 17 08:23:06 2007 -0500
[POWERPC] Fix 8xx compile failure
CC arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/fsl_soc.c: In function fsl_pcmcia_of_init:
arch/powerpc/sysdev/fsl_soc.c:1109: error: implicit declaration of function of_platform_device_create
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 86d7a9a9c4775f864e6bc5f5da66ef9ea3715734
Author: Becky Bruce <becky.bruce@freescale.com>
Date: Thu Aug 2 15:37:15 2007 -0500
[POWERPC] Fix FSL BookE machine check reporting
Reserved MCSR bits on FSL BookE parts may have spurious values
when mcheck occurs. Mask these off when printing the MCSR to
avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
for e500 - this bit doesn't actually have any meaning.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit b66510cb9992d204f216049e9c01d432c7635f6c
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Aug 16 23:55:55 2007 -0500
[POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
The interrupt routing in the device trees for the ULI M1575 was
inproperly using the interrupt line field as pci function. Fixed
up the device tree's to actual conform for to specification and
changed the interrupt mapping code so it just uses a static mapping
setup as follows:
PIRQA - IRQ9
PIRQB - IRQ10
PIRQC - IRQ11
PIRQD - IRQ12
USB 1.1 OCHI (1c.0) - IRQ12
USB 1.1 OCHI (1c.1) - IRQ9
USB 1.1 OCHI (1c.2) - IRQ10
USB 1.1 ECHI (1c.3) - IRQ11
LAN (1b.0) - IRQ6
AC97 (1d.0) - IRQ6
Modem (1d.1) - IRQ6
HD Audio (1d.2) - IRQ6
SATA (1f.1) - IRQ5
SMB (1e.1) - IRQ7
PMU (1e.2) - IRQ7
PATA (1f.0) - IRQ14/15
Took the oppurtunity to refactor the code into a single file so we
don't have to duplicate these fixes on the two current boards in the
tree and several forth coming boards that will also need the code.
Fixed RTC support that requires a dummy memory read on the P2P bridge
to unlock the RTC and setup the default of the RTC alarm registers to
match with a basic x86 style CMOS RTC.
Moved code that poked ISA registers to a FIXUP_FINAL quirk to ensure
the PCI IO space has been setup properly before we start poking ISA
registers at random locations.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit ada3ea6fcde45abc55e2af0e564455fd7f943a79
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Aug 16 23:44:00 2007 -0500
[POWERPC] Add interrupt resource for RTC CMOS driver
The RTC CMOS driver expects the interrupt to be a resource of the platform
device. Use a fixed interrupt value of 8 since on PPC if we are using this
its off an i8259 which we ensure has interrupt numbers 0..15.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
^ permalink raw reply
* [PATCH] [POWERPC] iSeries: clean up lparmap mess
From: Stephen Rothwell @ 2007-08-20 4:58 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
We need to have xLparMap in ead_64.S so that it is at a fixed address
(because the linker will not resolve (address & 0xffffffff) for us).
But the assembler miscalculates the KERNEL_VSID() expressions. So put
the confusing expressions into asm-offset.c.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/Makefile | 7 -------
arch/powerpc/kernel/asm-offsets.c | 8 ++++++++
arch/powerpc/kernel/head_64.S | 27 +++++++++++++++++++--------
arch/powerpc/kernel/lparmap.c | 32 --------------------------------
include/asm-powerpc/iseries/lpar_map.h | 3 +++
include/asm-powerpc/page_64.h | 2 +-
6 files changed, 31 insertions(+), 48 deletions(-)
delete mode 100644 arch/powerpc/kernel/lparmap.c
This has been built and booted for iseries_defconfig and ppc64_defconfig
and built for allmodconfig. Tony Breeds cross built
arch/powerpc/kernel/head_64.s on i386 for me and we verified the
constants all had the correct values.
Segher: this was plan C :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index b0cb2e6..5987912 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -80,13 +80,6 @@ ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
obj-y += iomap.o
endif
-ifeq ($(CONFIG_PPC_ISERIES),y)
-CFLAGS_lparmap.s += -g0
-extra-y += lparmap.s
-$(obj)/head_64.o: $(obj)/lparmap.s
-AFLAGS_head_64.o += -I$(obj)
-endif
-
else
# stuff used from here for ARCH=ppc
smpobj-$(CONFIG_SMP) += smp.o
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 2cb1d94..a408053 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -312,5 +312,13 @@ int main(void)
#ifdef CONFIG_BUG
DEFINE(BUG_ENTRY_SIZE, sizeof(struct bug_entry));
#endif
+
+#ifdef CONFIG_PPC_ISERIES
+ /* the assembler miscalculates the VSID values */
+ DEFINE(PAGE_OFFSET_ESID, GET_ESID(PAGE_OFFSET));
+ DEFINE(PAGE_OFFSET_VSID, KERNEL_VSID(PAGE_OFFSET));
+ DEFINE(VMALLOC_START_ESID, GET_ESID(VMALLOC_START));
+ DEFINE(VMALLOC_START_VSID, KERNEL_VSID(VMALLOC_START));
+#endif
return 0;
}
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 1718000..1e6d9cc 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -34,6 +34,7 @@
#include <asm/iseries/lpar_map.h>
#include <asm/thread_info.h>
#include <asm/firmware.h>
+#include <asm/page_64.h>
#define DO_SOFT_DISABLE
@@ -1519,8 +1520,8 @@ _GLOBAL(do_stab_bolted)
* Space for CPU0's segment table.
*
* On iSeries, the hypervisor must fill in at least one entry before
- * we get control (with relocate on). The address is give to the hv
- * as a page number (see xLparMap in lpardata.c), so this must be at a
+ * we get control (with relocate on). The address is given to the hv
+ * as a page number (see xLparMap below), so this must be at a
* fixed address (the linker can't compute (u64)&initial_stab >>
* PAGE_SHIFT).
*/
@@ -1542,12 +1543,22 @@ fwnmi_data_area:
* both pSeries and iSeries */
#ifdef CONFIG_PPC_ISERIES
. = LPARMAP_PHYS
-#include "lparmap.s"
-/*
- * This ".text" is here for old compilers that generate a trailing
- * .note section when compiling .c files to .s
- */
- .text
+ .globl xLparMap
+xLparMap:
+ .quad HvEsidsToMap /* xNumberEsids */
+ .quad HvRangesToMap /* xNumberRanges */
+ .quad STAB0_PAGE /* xSegmentTableOffs */
+ .zero 40 /* xRsvd */
+ /* xEsids (HvEsidsToMap entries of 2 quads) */
+ .quad PAGE_OFFSET_ESID /* xKernelEsid */
+ .quad PAGE_OFFSET_VSID /* xKernelVsid */
+ .quad VMALLOC_START_ESID /* xKernelEsid */
+ .quad VMALLOC_START_VSID /* xKernelVsid */
+ /* xRanges (HvRangesToMap entries of 3 quads) */
+ .quad HvPagesToMap /* xPages */
+ .quad 0 /* xOffset */
+ .quad PAGE_OFFSET_VSID << (SID_SHIFT - HW_PAGE_SHIFT) /* xVPN */
+
#endif /* CONFIG_PPC_ISERIES */
. = 0x8000
diff --git a/arch/powerpc/kernel/lparmap.c b/arch/powerpc/kernel/lparmap.c
deleted file mode 100644
index af11285..0000000
--- a/arch/powerpc/kernel/lparmap.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2005 Stephen Rothwell IBM Corp.
- *
- * 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.
- */
-#include <asm/mmu.h>
-#include <asm/pgtable.h>
-#include <asm/iseries/lpar_map.h>
-
-/* The # is to stop gcc trying to make .text nonexecutable */
-const struct LparMap __attribute__((__section__(".text #"))) xLparMap = {
- .xNumberEsids = HvEsidsToMap,
- .xNumberRanges = HvRangesToMap,
- .xSegmentTableOffs = STAB0_PAGE,
-
- .xEsids = {
- { .xKernelEsid = GET_ESID(PAGE_OFFSET),
- .xKernelVsid = KERNEL_VSID(PAGE_OFFSET), },
- { .xKernelEsid = GET_ESID(VMALLOC_START),
- .xKernelVsid = KERNEL_VSID(VMALLOC_START), },
- },
-
- .xRanges = {
- { .xPages = HvPagesToMap,
- .xOffset = 0,
- .xVPN = KERNEL_VSID(PAGE_OFFSET) << (SID_SHIFT - HW_PAGE_SHIFT),
- },
- },
-};
diff --git a/include/asm-powerpc/iseries/lpar_map.h b/include/asm-powerpc/iseries/lpar_map.h
index 2ec384d..5e9f3e1 100644
--- a/include/asm-powerpc/iseries/lpar_map.h
+++ b/include/asm-powerpc/iseries/lpar_map.h
@@ -22,6 +22,8 @@
#include <asm/types.h>
+#endif
+
/*
* The iSeries hypervisor will set up mapping for one or more
* ESID/VSID pairs (in SLB/segment registers) and will set up
@@ -56,6 +58,7 @@
/* Hypervisor initially maps 32MB of the load area */
#define HvPagesToMap 8192
+#ifndef __ASSEMBLY__
struct LparMap {
u64 xNumberEsids; // Number of ESID/VSID pairs
u64 xNumberRanges; // Number of VA ranges to map
diff --git a/include/asm-powerpc/page_64.h b/include/asm-powerpc/page_64.h
index 4ceb113..56a2df0 100644
--- a/include/asm-powerpc/page_64.h
+++ b/include/asm-powerpc/page_64.h
@@ -28,7 +28,7 @@
/* Segment size */
#define SID_SHIFT 28
-#define SID_MASK 0xfffffffffUL
+#define SID_MASK ASM_CONST(0xfffffffff)
#define ESID_MASK 0xfffffffff0000000UL
#define GET_ESID(x) (((x) >> SID_SHIFT) & SID_MASK)
--
1.5.2.4
^ permalink raw reply related
* Re: Please pull from 'for-2.6.24' branch
From: Paul Mackerras @ 2007-08-20 4:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070817084623.3e9835d0@weaponx.rchland.ibm.com>
Josh Boyer writes:
> Josh Boyer (10):
> Rename 4xx paths to 40x
> 4xx Kconfig cleanup
> Rename 44x bootwrapper
> 4xx bootwrapper reworks
> 40x MMU
> 40x decrementer fixes
> Fix 40x build
> Bamboo DTS
> Bamboo board support
> Bamboo zImage wrapper
Could you re-do these with [POWERPC] at the start of the summary line?
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH 6/7 v2] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Scott Wood @ 2007-08-20 1:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <55FCD650-548C-40C9-8B1E-16259EF93F1D@kernel.crashing.org>
On Sat, Aug 18, 2007 at 11:36:24AM -0500, Kumar Gala wrote:
> This patch seems to mix moving to using the device tree directly w/o
> some other modifications. Can it be broken into those two changes as
> they'd be easier to review.
The last iteration of these patches, I got complaints that I was
splitting them up too fine-grained. I don't think it's productive to
keep iterating on exactly how much is in any given patch until I hit the
right combination of granularity and whoever happens to be reading e-mail
when I submit.
In the case of this particular patch, most of what isn't directly related
to converting to using the device tree directly is fixing problems that I
encountered in doing so -- what value is there in coming up with
intermediary versions that kind-of-sort-of make sense, on a good day, if
you don't look to closely? The existing codebase is crap, and if every
logical change were its own patch, the patchset would be ten times as
long, and take ten times as long to produce. Note that I did separate
what I thought were the more relevant-to-review and/or highly indpendent
changes.
The major thing I see in this patch that could have been usefully
separated out was the conversion of mii_bitbang.c to use the generic code
introduced by patch 1. However, that would require retrieving and
retesting the intermediate version, and I don't think there's sufficient
damage to reviewability (apart perhaps from diff's stupidity in thinking
that a single "{" is relevant common ground between completely unrelated
chunks of code) relative to the cost in preparing such a split.
Is there anything of the actual content of the patch that you object to,
or have a question about?
-Scott
^ permalink raw reply
* Re: LINKSTATION default config update for linux-2.6.23-rc3
From: Segher Boessenkool @ 2007-08-19 19:18 UTC (permalink / raw)
To: Jonathan Li; +Cc: linuxppc-dev, g.liakhovetski
In-Reply-To: <9050bda20708191111n497e1565h87eb9a2423a6ba56@mail.gmail.com>
> Please update the default config in linux-2.6.23 for the LINKSTATION
> board with the following changes:
>
> SK98LIN SysKonnect driver is deprecated. Use SKGE instead.
/me confused...
None of SK98LIN, SKGE, SKY2 are in the linkstation_defconfig --
not unsurprisingly, since the hardware doesn't contain any such
chip.
Segher
^ permalink raw reply
* LINKSTATION default config update for linux-2.6.23-rc3
From: Jonathan Li @ 2007-08-19 18:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: g.liakhovetski
Hello,
Please update the default config in linux-2.6.23 for the LINKSTATION
board with the following changes:
SK98LIN SysKonnect driver is deprecated. Use SKGE instead.
Regards,
Jon
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Matt Sealey @ 2007-08-19 15:39 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070818100643.GA31233@nd47.coderock.org>
Domen,
Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
Linux with more fixups. The Efika PHY isn't going to change to something
else and it's a bog standard no-frills MII PHY anyway.
I think it is a distinction that the OF docs forgot to make, that the
client interface is *all those Forth words* and not just the 6 or 7
distinct, special callable functions like claim (they exist because of
the simple fact that claiming memory shouldn't involve claiming memory
and such other paradoxes) and call-method. Call-method is a perfectly
valid way of doing things.
But, I'd really recommend you please think of a different way.. if you
want to spec out a device tree entry for it I'll update my script which
I am probably going to stick as an 'official' Genesi support file in
the next week.
If you insist on using prom_init and fixups, yaboot has the best
examples of call-method and interpret, both readable and fairly
easily available.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Domen Puncer wrote:
> Hi!
>
> On 10/08/07 11:51 +0200, Domen Puncer wrote:
>> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
>> ===================================================================
>> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
>> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
>> + mdio@3000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + device_type = "mdio";
>> + compatible = "mpc5200b-fec-phy";
>> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
>> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
>> + interrupt-parent = <&mpc5200_pic>;
>> +
>> + phy0:ethernet-phy@0 {
>> + device_type = "ethernet-phy";
>> + reg = <0>;
>> + };
>> };
>
> I am struggling with this part on Efika.
> I would like to add this to the device tree from
> fixup_device_tree_efika() (arch/powerpc/kernel/prom_init.c).
>
> AFAICS client-services doesn't offer anything like new-device,
> so I guess "interpret" or "call-method" will have to be used.
>
> I have read some docs, but I'm still wandering in the dark.
> Can I please get an example?
> Pretty please with a cherry on top?
>
>
> Domen
^ permalink raw reply
* Re: [PATCH 1/2] Add scaled time to taskstats based process accounting
From: Michael Neuling @ 2007-08-19 13:12 UTC (permalink / raw)
To: balbir
Cc: Benjamin, Jay Lan, linux-kernel, linuxppc-dev, Paul Mackerras,
Andrew Morton
In-Reply-To: <46C805B0.1000300@linux.vnet.ibm.com>
In message <46C805B0.1000300@linux.vnet.ibm.com> you wrote:
> Andrew Morton wrote:
> >>
> >> unsigned int rt_priority;
> >> - cputime_t utime, stime;
> >> + cputime_t utime, stime, utimescaled, stimescaled;
> >
> > Adding 8 or 16 bytes to the task_struct for all architectures for something
> > which only powerpc uses?
> >
> > Is there any prospect that other CPUs can use this?
> >
>
> Hi, Andrew,
>
> There is definitely the prospect for other architectures to use this
> feature
>
> x86 provides the APERF and MPERF model specific registers.
> The ratio of APERF to MPERF gives the current scaled load on the
> system (acpi-cpufreq, get_measured_perf()) I have been looking at
> exploiting this functionality for x-series, but ran into a problem;
> as per the specification, APERF and MPERF are to be reset to 0
> upon reading them. As a result, I am still figuring out a good
> way to share the data amongst the ondemand governor and utimescaled
> statistics.
>
> I think for now, we can
>
> 1. Put utimescaled and stimescaled under an #ifdef for ARCH_POWERPC
... or even #ifdef TASKSTATS
> 2. Add utimescaled and stimescaled and add a big fat comment stating
> that work for other architectures is on it's way.
>
> In either case, I think the functionality is useful and can be
> exploited by other architectures. The powerpc port is complete and
> I think the implementation would provide a good reference for
> other implementations to follow.
>
> --
> Warm Regards,
> Balbir Singh
> Linux Technology Center
> IBM, ISTL
>
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Sergei Shtylyov @ 2007-08-19 12:59 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20070807032806.GE15619@localhost.localdomain>
Hello.
I'm having sort of vacation, mostly away from computer, hence my belated
reply...
David Gibson wrote:
>>>>>Can you describe some of the options for *not* direct mapped flash
>>>>>chips - I can't reasonably come up with a way of describing the
>>>>>distinction when I've never seen NOR flash other than direct mapped.
>>>> You're lucky to live in the single-endian world. Once you're in bi-endian
>>>>one, all kinds of strange mappings become possible. I've seen the MIPS
>> Well, not necessarily -- 16-bit only accesses are always possibly (no
>>dount this would be a strange mapping however)...
> I have no idea what you're getting at here.
The code fragment that I've posted before -- it used readw() in read8()
method of the mapping.
>>>>mapping driver which required swapping flash bytes in s/w in BE mode, i.e.
>>>>couldn't be served by physmap, yet that's not all... here's the code of its
>>>>map read*() methods:
>>>Aha! Ok, now I understand the sorts of situations you're talking
>>>about. By "not direct mapped", I thought you were talking about some
>>>kind of access via address/data registers on some indirect bus
>>>controller, rather than weird variations on endianness and
>>>bit-swizzling.
>> No, that would be just too ridiculous for a NOR flash -- I hope. :-)
> Heh. In my experience, very little is so ridiculous that some
> embedded vendor won't do it.
Right. :-)
>>>Hrm.. this is a property of how the flash is wired onto the bus,
>>>rather than of the flash chips themselves,
>> Indeed.
>>>so I'm not entirely sure where description of it belongs.
>> So, you're saying that the 1:1 address correspondence rule stops to apply
>>here?
> Well.. it all depends what exactly you consider the address space of
> the flash bank. By which I mean the whole shmozzle represented by the
> device node, not the individual flash chips. It's not immediately
> obvious whether or not that should include any swizzling done by the
> bus wiring.
> It would be possible, I guess, to define a 'swizzled-ranges' property
> or something which allows child devices to be embedded in the parent's
> address range in a not-direct way. However, the swizzling on the
> flash bank is really a property of the flash bank, not of the parent
> bus - requiring it to be encoded in the parent is pretty yucky -
> especially if the flash bank is just part of a larger chunk of bus
> address space, defined by a single large ranges entry in the parent.
[...]
>>>>>>>+ - reg : Address range of the flash chip
>>>>>>>+ - bank-width : Width (in bytes) of the flash bank. Equal to the device width
>>>>>>>+ times the number of interleaved chips.
>>>>>>>+ - device-width : (optional) Width of a single flash chip. If omitted,
>>>>>>>+ assumed to be equal to 'bank-width'.
>>>>>> Why then not just introduce the "interleave" prop and obsolete the
>>>>>>"bank-width"?
>>>>>Because they're equivalent information, and bank-width is what the
>>>>>code ends up actually caring about. I don't see any reason to prefer
>>>>>giving the interleave.
>>>> Well, "device-width" is not the thing that we care about either. ;-)
>>>Well, yes but we need to encode it somehow. Segher preferred
>>>device-width to interleave, because it's closer to a description of
>>>the actual hardware, rather than an abstration decribing its wiring.
>>>In other words I *still* don't see any reason to prefer giving the
>>>interleave.
Well, for example, enable "Flash chip driver advanced configuration
options" (appers in the "RAM/ROM/Flash chip drivers menu" when you enable CFI
probe, and it has a choice of bus widths 8 to 256 bits (here buswidth == bank
width) and *interleave factors* 1 to 8...
>> I wasn't talking of "interleave" preference over "device-width", I was
>>talking about obsoleting "bank-width" with this pair.
> Whatever. You haven't given any argument to prefer interleave over
> either device-width or bank-width.
Consistency? The bank width is a product of the chip width and interleave
factor. However, I don't insist. The MTD core itself has a different view on
the CFI flash geometry: bank width (which is a property of a mapping driver)
and interleave (which is a property of a chip driver).
>>>>>>>Index: working-2.6/drivers/mtd/maps/physmap_of.c
>>>>>>>===================================================================
>>>>>>>--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:11.000000000 +1000
>>>>>>>+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:14.000000000 +1000
>>>>[...]
>>>>>>>@@ -221,6 +297,14 @@ err_out:
>>>>>>>
>>>>>>>static struct of_device_id of_physmap_match[] = {
>>>>>>> {
>>>>>>>+ .compatible = "cfi-flash",
>>>>>>>+ .data = (void *)"cfi_probe",
>>>>>>>+ },
>>>>>>>+ {
>>>>>>>+ .compatible = "jedec-flash",
>>>>>>>+ .data = (void *)"jedec_probe",
>>>>>>>+ },
>>>>>>>+ {
>>>>>> This would also trigger on non-linearly mapped CFI or JEDEC
>>>>>>flashes which is not a good idea -- however, as we're using the MTD
>>>>>>probing code anyway, it will just fail, so it's not luckily is not a
>>>>>>fatal design flaw.
>>>>>Well, if there's nothing else to distinguish them. Which there isn't
>>>>>yet, but will need to be: see above about incomplete - helpful
>>>>>suggestions about how to describe the mapping would be more useful
>>>>>than merely pointing out the lack.
>>>> I was thinking about adding "direct-mapped" prop... but maybe adding
>>>>"ranges" to the parent node (that's "ebc") would indeed ensure that the flash
>>>>is mapped 1:1 to the EBC's parent bus also.
>>>The ebc already has a ranges property. But that can't describe the
>> Not in the device tree that started that thread -- I haven't seen another.
> Ah sorry. The ranges property isn't in the dts, it's added by the
> bootwrapper based on the EBC register contents.
Cool. :-)
>>>sorts of bit-swizzling you're talking about.
>> Let's hear what Segher says (if he's not yet tired of all this :-).
>>>>>>>Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
>>>>>>>===================================================================
>>>>>>>--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
>>>>>>>+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
>>>>>>[...]
>>>>>>>@@ -158,14 +161,20 @@
>>>>>>> };
>>>>>>> large-flash@2,0 {
>>>>>> Hmm... what does @2,0 mean? :-O
>>>>>EBC chip select 2, offset 0.
>>>> Well, so this node is under some kind of local bus node -- that's good.
>>>>Didn't know that the spec allows commas after @...
>>>Well, now you do. I believe USB usually uses that format, too.
>> USB what, hosts or devices?
> Devices.
And what the comma-separated numbers mean there?
[...]
WBR, Sergei
^ permalink raw reply
* Re: 2.6.23-rc3 broken on G5
From: Andreas Schwab @ 2007-08-19 12:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18119.42120.893384.555002@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Andreas Schwab writes:
>
>> 1.25 GB. It also has an nvidia gfx card, in case it matters.
>
> Could you try this patch and see if it fixes it? It puts the code
> back to being a bit closer to what it was before.
That didn't change anything visibly.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/2] Add scaled time to taskstats based process accounting
From: Balbir Singh @ 2007-08-19 8:56 UTC (permalink / raw)
To: Andrew Morton
Cc: Michael Neuling, Benjamin, Jay Lan, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <20070817115951.e1368a7d.akpm@linux-foundation.org>
Andrew Morton wrote:
>>
>> unsigned int rt_priority;
>> - cputime_t utime, stime;
>> + cputime_t utime, stime, utimescaled, stimescaled;
>
> Adding 8 or 16 bytes to the task_struct for all architectures for something
> which only powerpc uses?
>
> Is there any prospect that other CPUs can use this?
>
Hi, Andrew,
There is definitely the prospect for other architectures to use this
feature
x86 provides the APERF and MPERF model specific registers.
The ratio of APERF to MPERF gives the current scaled load on the
system (acpi-cpufreq, get_measured_perf()) I have been looking at
exploiting this functionality for x-series, but ran into a problem;
as per the specification, APERF and MPERF are to be reset to 0
upon reading them. As a result, I am still figuring out a good
way to share the data amongst the ondemand governor and utimescaled
statistics.
I think for now, we can
1. Put utimescaled and stimescaled under an #ifdef for ARCH_POWERPC
2. Add utimescaled and stimescaled and add a big fat comment stating
that work for other architectures is on it's way.
In either case, I think the functionality is useful and can be
exploited by other architectures. The powerpc port is complete and
I think the implementation would provide a good reference for
other implementations to follow.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Josh Boyer @ 2007-08-19 1:57 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <46C79E33.8090600@dlasys.net>
On Sat, 18 Aug 2007 21:34:43 -0400
"David H. Lynch Jr." <dhlii@dlasys.net> wrote:
> arch/boot/simple/embed_config.c jusst seems to be a random collection
> of board specific code anyway.
> A giant case statement implimented with #ifdef's. It is just
> screaming to be done some better way.
You mean like a device tree? ;)
josh
^ permalink raw reply
* Re: 2.6.23-rc3 broken on G5
From: Paul Mackerras @ 2007-08-19 2:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jey7g9i3qk.fsf@sykes.suse.de>
Andreas Schwab writes:
> 1.25 GB. It also has an nvidia gfx card, in case it matters.
Could you try this patch and see if it fixes it? It puts the code
back to being a bit closer to what it was before.
Paul.
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index a73d2d7..1cef209 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -226,8 +226,12 @@ void slb_initialize(void)
vflags = SLB_VSID_KERNEL | vmalloc_llp;
/* Invalidate the entire SLB (even slot 0) & all the ERATS */
+ asm volatile("isync":::"memory");
+ asm volatile("slbmte %0,%0"::"r" (0) : "memory");
+ asm volatile("isync; slbia; isync":::"memory");
+
slb_shadow_update(PAGE_OFFSET, lflags, 0);
- asm volatile("isync; slbia; sync; slbmte %0,%1; isync" ::
+ asm volatile("slbmte %0,%1; isync" ::
"r" (get_slb_shadow()->save_area[0].vsid),
"r" (get_slb_shadow()->save_area[0].esid) : "memory");
^ permalink raw reply related
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: David H. Lynch Jr. @ 2007-08-19 1:34 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <87vebryfrv.fsf@sleipner.barco.com>
arch/boot/simple/embed_config.c jusst seems to be a random collection of
board specific code anyway.
A giant case statement implimented with #ifdef's. It is just screaming
to be done some better way.
Peter Korsgaard wrote:
>>>>>> "WR" == Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> writes:
>>>>>>
>
> Hi,
>
> WR> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
> WR> index 5b87779..05631fe 100644
> WR> --- a/arch/ppc/boot/simple/Makefile
> WR> +++ b/arch/ppc/boot/simple/Makefile
> WR> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6) += embed_config.o
> WR> boot-$(CONFIG_8xx) += embed_config.o
> WR> boot-$(CONFIG_8260) += embed_config.o
> WR> boot-$(CONFIG_EP405) += embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML300) += embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML403) += embed_config.o
> WR> +boot-$(CONFIG_XILINX_VIRTEX) += embed_config.o
>
> Don't do that. Other boards with Xilinx FPGAs don't necessarily need
> embed_config.c
>
> WR> boot-$(CONFIG_BSEIP) += iic.o
> WR> boot-$(CONFIG_MBX) += iic.o pci.o qspan_pci.o
> WR> boot-$(CONFIG_MV64X60) += misc-mv64x60.o
> WR> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
> WR> index 840bff2..e0b8954 100644
> WR> --- a/arch/ppc/boot/simple/embed_config.c
> WR> +++ b/arch/ppc/boot/simple/embed_config.c
> WR> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
> WR> }
> WR> #endif /* WILLOW */
>
> WR> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
> WR> +#if defined(CONFIG_XILINX_VIRTEX)
> WR> void
> WR> embed_config(bd_t ** bdp)
>
> .. And if they do, they might have another embed_config (E.G. if the
> bootloader provides a valid struct bd_t).
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Best Linux tree for Xilinx support.
From: David H. Lynch Jr. @ 2007-08-19 1:29 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C02053B0F@ehost011-3.exch011.intermedia.net>
Leonid wrote:
> I deem such approach is not very good one. I'm using precisely same IP
> cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs
> which means (OK, may be cores are different somewhat for different FPGAs
> but low level Xilinx code is the same). That means at least 2 different
> CPU architectures (PPC and Microblaze).
>
Most device drivers are outside the arch tree, only board specific
configuration
is inside.
While there is a great deal of similarity between the microblaze and
ppc code that
would be under the arch tree's they are still as distinct as
different architecures.
Maybe there would be some way to share some of the code, but for the
most part
the similar or identical code falls outside the arch tree.
> A How EDK project parameters get into Linux kernel? This is huge issue
> which can be divided on several items.
>
Xilinx has their own idea's and thus far they do not seem to fit
well with the
norms of Linux kernel developers. It is extremely unlikely the latter
will change.
I did the BSP for the Pico E1x series of boards. While it is based
heavily on Grant's
MLXXX work that I am trying to track, very little of it is even xilinx
specific.
One the key distinctions between FPGA based systems and typical
systems is that
the core is very very small. In a Pico E1x, you can only count on:
A processor,
an MMU,
memory,
and some serial (or pseudo serial) device capable of functioning as
a console.
Flash, Ethernet, Specific Uarts, Even interrupts and interrupt
handling are
all optional.
> A.2. There is also a question how these definitions get into .c and Make
> files. Petalogix has interesting solution when they bump all XILINX
> parameters to autoconf.h and .config files thus making them available
> for both compiler and make. What's your approach?
>
With all respect to Petalogix and the significant work they have
done, I can not see migrating all
the xparameters.h values into .config being adopted. Besides little
of none of those values are
needed outside the core of the BSP.
I am not particular enamored with the CONFIG_VIRTEX or
CONFIG_VIRTEX_4 flags either. There is very very little that knowing
the exact FPGA tells Linux. As an example Pico E12's, E14's and E16's
are fundimentally very similar, despite having different form factors,
being on different cards (CF, CardBus, ExpressBus), and using different
Xilinx parts (sometimes on the same model)
I beleive that the long term effort is to put everything into device
tree's
then the device information for the product is
dynamically created, or stored in flash or otherwise provided to
Linux
at boot. But that is pretty close to the extent of my knowledge of
device
trees at this time.
> A.4. Is it assumed that Xilinx low level code will stay intact as it is
> supplied with EDK package or you are going to prepare special Linux
> Xilinx set (mostly because of name convention)?
>
I do not beleive anyone is anticipating the Xilinx EDK code making
its way into
a kernel.org Linux source.
> B How drivers get registered - via platform devices structure in
> virtex.c file or something different?
>
I beleive the current approach is mostly using platform devices - though
individual drivers may vary. I beleive the longterm approach is to use
device
trees - I am not sure how the two interrelate.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* [PATCH 3/3 v2][POWERPC] Stop include asm-ppc when building ARCH=powerpc for ppc32
From: Kumar Gala @ 2007-08-18 17:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0708181207530.31362@blarg.am.freescale.net>
We no longer have any dependancies on include/asm-ppc so we can get ride
of the makefile hacks to include it in the build process.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Actually remove all the bits related to include fixup, not just comment
them out :)
arch/powerpc/Makefile | 17 +----------------
1 files changed, 1 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 6c1e36c..d6ab02e 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -63,8 +63,7 @@ endif
LDFLAGS_vmlinux := -Bstatic
-# The -Iarch/$(ARCH)/include is temporary while we are merging
-CPPFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -Iarch/$(ARCH)/include
+CPPFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH)
AFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH)
CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc
CFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -ffixed-r2 -mmultiple
@@ -72,9 +71,6 @@ CPPFLAGS += $(CPPFLAGS-y)
AFLAGS += $(AFLAGS-y)
CFLAGS += -msoft-float -pipe $(CFLAGS-y)
CPP = $(CC) -E $(CFLAGS)
-# Temporary hack until we have migrated to asm-powerpc
-LINUXINCLUDE-$(CONFIG_PPC32) := -Iarch/$(ARCH)/include
-LINUXINCLUDE += $(LINUXINCLUDE-y)
CHECKFLAGS += -m$(SZ) -D__powerpc__ -D__powerpc$(SZ)__
@@ -172,19 +168,8 @@ install:
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
-archmrproper:
- $(Q)rm -rf arch/$(ARCH)/include
-
archprepare: checkbin
-ifeq ($(CONFIG_PPC32),y)
-# Temporary hack until we have migrated to asm-powerpc
-include/asm: arch/$(ARCH)/include/asm
-arch/$(ARCH)/include/asm: FORCE
- $(Q)if [ ! -d arch/$(ARCH)/include ]; then mkdir -p arch/$(ARCH)/include; fi
- $(Q)ln -fsn $(srctree)/include/asm-$(OLDARCH) arch/$(ARCH)/include/asm
-endif
-
# Use the file '.tmp_gas_check' for binutils tests, as gas won't output
# to stdout and these checks are run even on install targets.
TOUT := .tmp_gas_check
--
1.5.2.2
^ permalink raw reply related
* [PATCH 2/3 v2][POWERPC] Copy over headers from arch/ppc to arch/powerpc that we need
From: Kumar Gala @ 2007-08-18 17:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0708181206070.31362@blarg.am.freescale.net>
To build arch/powerpc without including asm-ppc/ we need these files
in asm-powerpc/
Moved some headers under arch/powerpc/platforms if they were only used by
platform files and fixed up the source file includes to match the new
locations
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Moved mpc10x.h, gg2.h, hydra.h into platforms. Removed new file diffs
from the patch.
arch/powerpc/platforms/chrp/gg2.h | 61 ++
arch/powerpc/platforms/chrp/hydra.h | 102 ++
arch/powerpc/platforms/chrp/pci.c | 4 +-
arch/powerpc/platforms/chrp/setup.c | 4 +-
arch/powerpc/platforms/embedded6xx/linkstation.c | 3 +-
arch/powerpc/platforms/embedded6xx/ls_uart.c | 3 +-
arch/powerpc/platforms/embedded6xx/mpc10x.h | 180 ++++
include/asm-powerpc/8xx_immap.h | 564 ++++++++++
include/asm-powerpc/commproc.h | 692 ++++++++++++
include/asm-powerpc/cpm2.h | 1248 ++++++++++++++++++++++
include/asm-powerpc/highmem.h | 135 +++
include/asm-powerpc/immap_cpm2.h | 648 +++++++++++
include/asm-powerpc/kgdb.h | 57 +
include/asm-powerpc/mpc52xx_psc.h | 191 ++++
14 files changed, 3886 insertions(+), 6 deletions(-)
create mode 100644 arch/powerpc/platforms/chrp/gg2.h
create mode 100644 arch/powerpc/platforms/chrp/hydra.h
create mode 100644 arch/powerpc/platforms/embedded6xx/mpc10x.h
create mode 100644 include/asm-powerpc/8xx_immap.h
create mode 100644 include/asm-powerpc/commproc.h
create mode 100644 include/asm-powerpc/cpm2.h
create mode 100644 include/asm-powerpc/highmem.h
create mode 100644 include/asm-powerpc/immap_cpm2.h
create mode 100644 include/asm-powerpc/kgdb.h
create mode 100644 include/asm-powerpc/mpc52xx_psc.h
diff --git a/arch/powerpc/platforms/chrp/pci.c b/arch/powerpc/platforms/chrp/pci.c
index 0c6dba9..fd80703 100644
--- a/arch/powerpc/platforms/chrp/pci.c
+++ b/arch/powerpc/platforms/chrp/pci.c
@@ -11,9 +11,7 @@
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/irq.h>
-#include <asm/hydra.h>
#include <asm/prom.h>
-#include <asm/gg2.h>
#include <asm/machdep.h>
#include <asm/sections.h>
#include <asm/pci-bridge.h>
@@ -21,6 +19,8 @@
#include <asm/rtas.h>
#include "chrp.h"
+#include "gg2.h"
+#include "hydra.h"
/* LongTrail */
void __iomem *gg2_pci_config_base;
diff --git a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
index dde5ef4..03ccf1a 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -37,12 +37,10 @@
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/prom.h>
-#include <asm/gg2.h>
#include <asm/pci-bridge.h>
#include <asm/dma.h>
#include <asm/machdep.h>
#include <asm/irq.h>
-#include <asm/hydra.h>
#include <asm/sections.h>
#include <asm/time.h>
#include <asm/i8259.h>
@@ -51,6 +49,8 @@
#include <asm/xmon.h>
#include "chrp.h"
+#include "gg2.h"
+#include "hydra.h"
void rtas_indicator_progress(char *, unsigned short);
diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c b/arch/powerpc/platforms/embedded6xx/linkstation.c
index 8c60e02..61ca02c 100644
--- a/arch/powerpc/platforms/embedded6xx/linkstation.c
+++ b/arch/powerpc/platforms/embedded6xx/linkstation.c
@@ -18,9 +18,10 @@
#include <asm/time.h>
#include <asm/prom.h>
#include <asm/mpic.h>
-#include <asm/mpc10x.h>
#include <asm/pci-bridge.h>
+#include "mpc10x.h"
+
static struct mtd_partition linkstation_physmap_partitions[] = {
{
.name = "mtd_firmimg",
diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/powerpc/platforms/embedded6xx/ls_uart.c
index f7a4def..0d9f150 100644
--- a/arch/powerpc/platforms/embedded6xx/ls_uart.c
+++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c
@@ -4,10 +4,11 @@
#include <linux/serial_reg.h>
#include <linux/serial_8250.h>
#include <asm/io.h>
-#include <asm/mpc10x.h>
#include <asm/prom.h>
#include <asm/termbits.h>
+#include "mpc10x.h"
+
static void __iomem *avr_addr;
static unsigned long avr_clock;
--
1.5.2.2
^ permalink raw reply related
* [PATCH 1/3 v2][POWERPC] Remove old includes from arch/ppc
From: Kumar Gala @ 2007-08-18 17:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0708181203320.31362@blarg.am.freescale.net>
Remove includes of files that existed in arch/ppc that we dont need in
arch/powerpc anymore. The following includes were removed:
<asm/amigappc.h>
<asm/bootinfo.h>
<asm/ppcboot.h>
<asm/ppc_sys.h>
<asm/residual.h>
<asm/m8260_pci.h>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Added m8260_pci.h to the cleanup.
arch/powerpc/kernel/setup_32.c | 2 --
arch/powerpc/platforms/52xx/lite5200.c | 1 -
arch/powerpc/platforms/82xx/m82xx_pci.h | 2 --
arch/powerpc/platforms/82xx/mpc82xx.c | 1 -
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 1 -
arch/powerpc/platforms/82xx/pq2ads.h | 1 -
arch/powerpc/platforms/83xx/mpc832x_mds.c | 1 -
arch/powerpc/platforms/83xx/mpc834x_itx.c | 1 -
arch/powerpc/platforms/83xx/mpc834x_mds.c | 1 -
arch/powerpc/platforms/83xx/mpc836x_mds.c | 1 -
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 1 -
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 -
arch/powerpc/platforms/8xx/m8xx_setup.c | 4 ++--
arch/powerpc/platforms/8xx/mpc86xads.h | 1 -
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 1 -
arch/powerpc/platforms/8xx/mpc885ads.h | 1 -
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 1 -
arch/powerpc/platforms/chrp/smp.c | 1 -
arch/powerpc/platforms/embedded6xx/ls_uart.c | 1 -
arch/powerpc/platforms/powermac/bootx_init.c | 1 -
20 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 7ec6ba5..a288a5f 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -18,13 +18,11 @@
#include <linux/cpu.h>
#include <linux/console.h>
-#include <asm/residual.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/processor.h>
#include <asm/pgtable.h>
#include <asm/setup.h>
-#include <asm/amigappc.h>
#include <asm/smp.h>
#include <asm/elf.h>
#include <asm/cputable.h>
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 84bd3da..ce3f695 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -35,7 +35,6 @@
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/ipic.h>
-#include <asm/bootinfo.h>
#include <asm/irq.h>
#include <asm/prom.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/82xx/m82xx_pci.h b/arch/powerpc/platforms/82xx/m82xx_pci.h
index 9cd8893..65e38a7 100644
--- a/arch/powerpc/platforms/82xx/m82xx_pci.h
+++ b/arch/powerpc/platforms/82xx/m82xx_pci.h
@@ -8,8 +8,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#include <asm/m8260_pci.h>
-
#define SIU_INT_IRQ1 ((uint)0x13 + CPM_IRQ_OFFSET)
#ifndef _IO_BASE
diff --git a/arch/powerpc/platforms/82xx/mpc82xx.c b/arch/powerpc/platforms/82xx/mpc82xx.c
index cc9900d..c706871 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx.c
@@ -36,7 +36,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
#include <asm/mpc8260.h>
#include <asm/irq.h>
diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 2d1b05b..c0a0c56 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -37,7 +37,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
#include <asm/mpc8260.h>
#include <asm/irq.h>
diff --git a/arch/powerpc/platforms/82xx/pq2ads.h b/arch/powerpc/platforms/82xx/pq2ads.h
index 5b5cca6..6f749b7 100644
--- a/arch/powerpc/platforms/82xx/pq2ads.h
+++ b/arch/powerpc/platforms/82xx/pq2ads.h
@@ -23,7 +23,6 @@
#define __MACH_ADS8260_DEFS
#include <linux/seq_file.h>
-#include <asm/ppcboot.h>
/* For our show_cpuinfo hooks. */
#define CPUINFO_VENDOR "Freescale Semiconductor"
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 2c8e641..61e3f1c 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -32,7 +32,6 @@
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/ipic.h>
-#include <asm/bootinfo.h>
#include <asm/irq.h>
#include <asm/prom.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index 47ba544..6d06645 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -30,7 +30,6 @@
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/ipic.h>
-#include <asm/bootinfo.h>
#include <asm/irq.h>
#include <asm/prom.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 4c9ff9c..f8aba9a 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -30,7 +30,6 @@
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/ipic.h>
-#include <asm/bootinfo.h>
#include <asm/irq.h>
#include <asm/prom.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 84b5893..69970b9 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -38,7 +38,6 @@
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/ipic.h>
-#include <asm/bootinfo.h>
#include <asm/irq.h>
#include <asm/prom.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 6a171e9..0402334 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -35,7 +35,6 @@
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/ipic.h>
-#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
#include <asm/mpc85xx.h>
#include <asm/irq.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index be25ecd..53830c9 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -38,7 +38,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
#include <asm/mpc85xx.h>
#include <asm/irq.h>
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
index f169355..f00c8d1 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -36,13 +36,11 @@
#include <asm/mmu.h>
#include <asm/reg.h>
-#include <asm/residual.h>
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/mpc8xx.h>
#include <asm/8xx_immap.h>
#include <asm/machdep.h>
-#include <asm/bootinfo.h>
#include <asm/time.h>
#include <asm/prom.h>
#include <asm/fs_pd.h>
@@ -55,7 +53,9 @@ struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
#endif
void m8xx_calibrate_decr(void);
+#ifdef CONFIG_8xx_WDT
extern void m8xx_wdt_handler_install(bd_t *bp);
+#endif
extern int cpm_pic_init(void);
extern int cpm_get_irq(void);
diff --git a/arch/powerpc/platforms/8xx/mpc86xads.h b/arch/powerpc/platforms/8xx/mpc86xads.h
index 59bad2f..dd10cd2 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads.h
+++ b/arch/powerpc/platforms/8xx/mpc86xads.h
@@ -15,7 +15,6 @@
#ifndef __ASM_MPC86XADS_H__
#define __ASM_MPC86XADS_H__
-#include <asm/ppcboot.h>
#include <sysdev/fsl_soc.h>
/* U-Boot maps BCSR to 0xff080000 */
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index d881647..8f64f48 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -31,7 +31,6 @@
#include <asm/processor.h>
#include <asm/system.h>
#include <asm/time.h>
-#include <asm/ppcboot.h>
#include <asm/mpc8xx.h>
#include <asm/8xx_immap.h>
#include <asm/commproc.h>
diff --git a/arch/powerpc/platforms/8xx/mpc885ads.h b/arch/powerpc/platforms/8xx/mpc885ads.h
index 7c31aec..14db124 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads.h
+++ b/arch/powerpc/platforms/8xx/mpc885ads.h
@@ -15,7 +15,6 @@
#ifndef __ASM_MPC885ADS_H__
#define __ASM_MPC885ADS_H__
-#include <asm/ppcboot.h>
#include <sysdev/fsl_soc.h>
/* U-Boot maps BCSR to 0xff080000 */
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index bd5ff7a..d3da385 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -32,7 +32,6 @@
#include <asm/processor.h>
#include <asm/system.h>
#include <asm/time.h>
-#include <asm/ppcboot.h>
#include <asm/mpc8xx.h>
#include <asm/8xx_immap.h>
#include <asm/commproc.h>
diff --git a/arch/powerpc/platforms/chrp/smp.c b/arch/powerpc/platforms/chrp/smp.c
index a137d13..10a4a4d 100644
--- a/arch/powerpc/platforms/chrp/smp.c
+++ b/arch/powerpc/platforms/chrp/smp.c
@@ -26,7 +26,6 @@
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/smp.h>
-#include <asm/residual.h>
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/mpic.h>
diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/powerpc/platforms/embedded6xx/ls_uart.c
index d0bee9f..f7a4def 100644
--- a/arch/powerpc/platforms/embedded6xx/ls_uart.c
+++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c
@@ -5,7 +5,6 @@
#include <linux/serial_8250.h>
#include <asm/io.h>
#include <asm/mpc10x.h>
-#include <asm/ppc_sys.h>
#include <asm/prom.h>
#include <asm/termbits.h>
diff --git a/arch/powerpc/platforms/powermac/bootx_init.c b/arch/powerpc/platforms/powermac/bootx_init.c
index 9d73d02..cf66091 100644
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -17,7 +17,6 @@
#include <asm/prom.h>
#include <asm/page.h>
#include <asm/bootx.h>
-#include <asm/bootinfo.h>
#include <asm/btext.h>
#include <asm/io.h>
--
1.5.2.2
^ permalink raw reply related
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