[PATCH] [POWERPC] 86xx: mpc8610_hpcd: add support for NOR and NAND flashes
This patch adds device tree nodes for NOR and NAND flashes and places
board-control node inside the localbus.
defconfig and board file updated appropriately.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 39 +++-
arch/powerpc/configs/mpc8610_hpcd_defconfig | 88 ++-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c |1 +
3 files changed, 124 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index bba234e..64c8e78 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -46,9 +46,42 @@
reg = <0x 0x2000>; // 512M at 0x0
};
- [EMAIL PROTECTED] {
- compatible = "fsl,fpga-pixis";
- reg = <0xe800 32>; // pixis at 0xe800
+ [EMAIL PROTECTED] {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8610-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <19 2>;
+ interrupt-parent = <&mpic>;
+ ranges = <0 0 0xf800 0x0800
+ 1 0 0xf000 0x0800
+ 2 0 0xe840 0x8000
+ 3 0 0xe800 0x0020>;
+
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x800>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <1 0 0x800>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+"fsl,elbc-fcm-nand";
+ reg = <2 0 0x8000>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,fpga-pixis";
+ reg = <3 0 0x20>;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig
b/arch/powerpc/configs/mpc8610_hpcd_defconfig
index f9e53bd..7e5b9ce 100644
--- a/arch/powerpc/configs/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig
@@ -358,7 +358,93 @@ CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+# CONFIG_MTD_OF_PARTS is not set
+# CONFIG_MTD_AR7_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+CONFIG_MTD_NAND=y
+# CONFIG_MTD_NAND_VERIFY_WRITE is not set
+# CONFIG_MTD_NAND_ECC_SMC is not set
+# CONFIG_MTD_NAND_MUSEUM_IDS is not set
+CONFIG_MTD_NAND_IDS=y
+# CONFIG_MTD_NAND_DISKONCHIP is not set
+# CONFIG_MTD_NAND_CAFE is not set
+# CONFIG_MTD_NAND_NANDSIM is not set
+# CONFIG_MTD_NAND_PLATFORM is not set
+CONFIG_MTD_NAND_FSL_ELBC=y
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CO
powerpc-next branch and 2.6.27?
Paul, Now that 2.6.26-rc1 is out, will your powerpc-next branch be used for work queued up for 2.6.27? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
How to link a .o with all modules
Sam, We have a case in powerpc in which we want to link some library routines with all module objects. The routines are intended for handling out-of-line function call register save/restore so having them as EXPORT_SYMBOL() is counter productive (we do also need to link the same "library" code into the kernel). Any suggestions on how to handle this? thanks - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] 86xx: mpc8610_hpcd: add support for NOR and NAND flashes
This patch adds device tree nodes for NOR and NAND flashes and places
board-control node inside the localbus.
defconfig and board file updated appropriately.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Heh, this is v2. The flash setup on the MPC8610 tricked me.
There is single NAND package, but with four physical NAND
chips inside. Each occupy its own localbus CE line, i.e. bank.
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 60 +-
arch/powerpc/configs/mpc8610_hpcd_defconfig | 88 ++-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c |1 +
3 files changed, 145 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index bba234e..08a780d 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -46,9 +46,63 @@
reg = <0x 0x2000>; // 512M at 0x0
};
- [EMAIL PROTECTED] {
- compatible = "fsl,fpga-pixis";
- reg = <0xe800 32>; // pixis at 0xe800
+ [EMAIL PROTECTED] {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8610-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <19 2>;
+ interrupt-parent = <&mpic>;
+ ranges = <0 0 0xf800 0x0800
+ 1 0 0xf000 0x0800
+ 2 0 0xe840 0x8000
+ 4 0 0xe844 0x8000
+ 5 0 0xe848 0x8000
+ 6 0 0xe84c 0x8000
+ 3 0 0xe800 0x0020>;
+
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x800>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <1 0 0x800>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+"fsl,elbc-fcm-nand";
+ reg = <2 0 0x8000>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+"fsl,elbc-fcm-nand";
+ reg = <4 0 0x8000>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+"fsl,elbc-fcm-nand";
+ reg = <5 0 0x8000>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+"fsl,elbc-fcm-nand";
+ reg = <6 0 0x8000>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,fpga-pixis";
+ reg = <3 0 0x20>;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig
b/arch/powerpc/configs/mpc8610_hpcd_defconfig
index f9e53bd..7e5b9ce 100644
--- a/arch/powerpc/configs/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig
@@ -358,7 +358,93 @@ CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+# CONFIG_MTD_OF_PARTS is not set
+# CONFIG_MTD_AR7_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CO
Re: How to link a .o with all modules
On Sun, May 04, 2008 at 01:22:38PM -0500, Kumar Gala wrote: > Sam, > > We have a case in powerpc in which we want to link some library > routines with all module objects. The routines are intended for > handling out-of-line function call register save/restore so having > them as EXPORT_SYMBOL() is counter productive (we do also need to link > the same "library" code into the kernel). > > Any suggestions on how to handle this? I assume you have the .o file build somewhere as part of the normal kernel build. Then you in arch/powerpc/Makefile adds the following assignment: LDFLAGS_MODULE += arch/powerpc/lib/my_magic_file.o kbuild will then during the modpost stage link this file on all modules. To add the same file to the kernel just include it in a obj-y += my_magic_file.o One trap is that my_magic_file.o needs to be built for a modules build too. I think you need to assign it to always: always := my_magic_file.o to accomplish this. So in the end we will have: arch/powerpc/Makefile: LDFLAGS_MODULE += arch/powerpc/lib/my_magic_file.o arch/powerpc/lib/Makefile: always := my_magic_file.o obj-y += my_magic_file.o Let me know if this does address your question. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: how to check for "optional" ppc chip features (MSR_BE)
On Thu, 2008-05-01 at 22:48 -0500, Kumar Gala wrote: > > Look at arch/powerpc/kernel/cputable.c to see how we handle issues > like this. > Oh and classic pitfall: If you define a new feature bit, make sure CPU_FTRS_POSSIBLE is updated to contain it in cputable.h Also, It may not be totally clear, but: PPC_FEATURE_* are exposed to userspace via AT_HWCAP CPU_FTR_* are kernel internal (and can be used for runtime patching of assembly code). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: how to check for "optional" ppc chip features (MSR_BE)
> Oh and classic pitfall: If you define a new feature bit, make sure > CPU_FTRS_POSSIBLE is updated to contain it in cputable.h Yeah, all that stuff I could figure out as needed. What I really meant was, where is the big official table of which chips behave which ways that you base all code that on? Actually, I don't really care as long as you all are happy to be responsible for figuring out what matters. With the patch I posted to use MSR_BE, I took Kumar Gala's word as gospel that all the chips on which we use MSR_SE also have MSR_BE. If that's not right, then I hope you'd like to pick a feature bit, populate the tables, etc., and fix the definition of arch_has_block_step() as appropriate. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to link a .o with all modules
H. Peter Anvin writes: > Why is having them as an EXPORT_SYMBOL() counterproductive? It sounds > like *exactly* what you need -- and then having the kernel provide the > same code to modules, instead of replication...? It means we would go through a trampoline just to call little things like __ucmpdi2, which seems a bit unnecessary. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to link a .o with all modules
Kumar Gala wrote: Sam, We have a case in powerpc in which we want to link some library routines with all module objects. The routines are intended for handling out-of-line function call register save/restore so having them as EXPORT_SYMBOL() is counter productive (we do also need to link the same "library" code into the kernel). Why is having them as an EXPORT_SYMBOL() counterproductive? It sounds like *exactly* what you need -- and then having the kernel provide the same code to modules, instead of replication...? -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
WARNING: mutexes are preferred for single holder semaphores
This is a bit OT, but I got the warning in the subject from checkpatch.pl for a piece of code. The code *is* using a mutex. Does it actually mean I shouldn't use a mutex? The code declares a global mutex: static DECLARE_MUTEX(list_lock); The odds of two accesses to the list_lock at the same time are zero. But it would be Very Bad(tm) if it did happen. Since the odds of contention are near zero, the cost of the mutex is near zero, so I put it in. I think I can safely ignore the warning, but I want to make sure Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: how to check for "optional" ppc chip features (MSR_BE)
On Sun, 2008-05-04 at 16:12 -0700, Roland McGrath wrote: > > Oh and classic pitfall: If you define a new feature bit, make sure > > CPU_FTRS_POSSIBLE is updated to contain it in cputable.h > > Yeah, all that stuff I could figure out as needed. What I really meant > was, where is the big official table of which chips behave which ways that > you base all code that on? There isn't any ... > Actually, I don't really care as long as you > all are happy to be responsible for figuring out what matters. With the > patch I posted to use MSR_BE, I took Kumar Gala's word as gospel that all > the chips on which we use MSR_SE also have MSR_BE. If that's not right, > then I hope you'd like to pick a feature bit, populate the tables, etc., > and fix the definition of arch_has_block_step() as appropriate. I'll have to check with Paul, we'll scrub the IBM parts, and Kumar can dbl check the "classic 32" FSL parts. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: WARNING: mutexes are preferred for single holder semaphores
On Sun, 2008-05-04 at 20:41 -0400, Sean MacLennan wrote: > This is a bit OT, but I got the warning in the subject from > checkpatch.pl for a piece of code. The code *is* using a mutex. Does it > actually mean I shouldn't use a mutex? > > The code declares a global mutex: > > static DECLARE_MUTEX(list_lock); .. which is a semaphore :( [see include/linux/semaphore.h] I think you want DEFINE_MUTEX(). Yes, this is completely ridiculous. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Phytec pcm030 board support
On Fri, Apr 25, 2008 at 03:48:05PM +0200, Sascha Hauer wrote: > Add board support for the Phytec pcm030 mpc5200b based board. It > does not need any platform specific fixups and as such is handled > as a mpc5200 simple platform. Those still whingeing about how horrible and hard and tedious the new world of device trees is, take note. We've certainly had some teething problems as we all figure out how to use the device tree properly. But this is the payoff: support for a new board added with one text file. It's only going to get more common. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: WARNING: mutexes are preferred for single holder semaphores
On Mon, 05 May 2008 11:06:55 +1000 "Michael Ellerman" <[EMAIL PROTECTED]> wrote: > On Sun, 2008-05-04 at 20:41 -0400, Sean MacLennan wrote: > > This is a bit OT, but I got the warning in the subject from > > checkpatch.pl for a piece of code. The code *is* using a mutex. > > Does it actually mean I shouldn't use a mutex? > > > > The code declares a global mutex: > > > > static DECLARE_MUTEX(list_lock); > > .. which is a semaphore :( [see include/linux/semaphore.h] > > I think you want DEFINE_MUTEX(). > > Yes, this is completely ridiculous. > > cheers > Ok, that fixed it, once I changed all the up and down calls :p Thanks. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: WARNING: mutexes are preferred for single holder semaphores
Sean MacLennan writes: > This is a bit OT, but I got the warning in the subject from > checkpatch.pl for a piece of code. The code *is* using a mutex. Does it > actually mean I shouldn't use a mutex? I don't require zero checkpatch warnings or errors on patches before I accept them. If what checkpatch is saying is rubbish, just ignore it. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: WARNING: mutexes are preferred for single holder semaphores
On Sun, 2008-05-04 at 20:41 -0400, Sean MacLennan wrote: > This is a bit OT, but I got the warning in the subject from > checkpatch.pl for a piece of code. The code *is* using a mutex. Does it > actually mean I shouldn't use a mutex? > > The code declares a global mutex: > > static DECLARE_MUTEX(list_lock); > > The odds of two accesses to the list_lock at the same time are zero. > But it would be Very Bad(tm) if it did happen. Since the odds of > contention are near zero, the cost of the mutex is near zero, so I put > it in. > > I think I can safely ignore the warning, but I want to make sure Show us the code... It could be a bug in checkpatch or you using the wrong functions somewhere ... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix of_i2c include for module compilation
Jochen Friedrich writes: > -#ifdef CONFIG_OF_I2C > +#if defined(CONFIG_OF_I2C) || defined(CONFIG_OF_I2C_MODULE) > > void of_register_i2c_devices(struct i2c_adapter *adap, >struct device_node *adap_node); Why do we have that ifdef there at all? There's only that one external declaration within it, so the #ifdef and #endif could just be removed. If the ifdef hadn't been there in the first place we wouldn't have had this problem. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: WARNING: mutexes are preferred for single holder semaphores
On Mon, 05 May 2008 13:38:39 +1000 "Benjamin Herrenschmidt" <[EMAIL PROTECTED]> wrote: > Show us the code... It could be a bug in checkpatch or you using > the wrong functions somewhere ... The change to DEFINE_MUTEX and changing up/down to mutex_lock/mutex_unlock solved the problem. The code is GPLed but not currently available on the net. It is basically a little driver that registers a character device and then passes out the minor numbers to the PIKA board drivers. It was written to isolate all the character/sysfs code to one place since we have five drivers, and many debug drivers, that use it. If anybody is really interested, I can post it here. I doubt it will ever be submitted to the mainline kernel however. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] More useful cputable defaults
Changes the cputable so that various CPU families that have an exclusive
CONFIG_ option have a more sensible default entry to patch if the specific
processor hasn't been identified.
This makes the kernel more generally useful when booted on an unknown
PVR for things like new 4xx variants.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 53 +
1 file changed, 43 insertions(+), 10 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/cputable.c 2008-05-05
13:43:02.0 +1000
+++ linux-work/arch/powerpc/kernel/cputable.c 2008-05-05 13:47:52.0
+1000
@@ -1207,6 +1207,18 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_4xx,
.platform = "ppc405",
},
+ { /* default match */
+ .pvr_mask = 0x,
+ .pvr_value = 0x,
+ .cpu_name = "(generic 40x PPC)",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc405",
+ }
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
@@ -1397,8 +1409,18 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_440A,
.platform = "ppc440",
},
+ { /* default match */
+ .pvr_mask = 0x,
+ .pvr_value = 0x,
+ .cpu_name = "(generic 44x PPC)",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc440",
+ }
#endif /* CONFIG_44x */
-#ifdef CONFIG_FSL_BOOKE
#ifdef CONFIG_E200
{ /* e200z5 */
.pvr_mask = 0xfff0,
@@ -1427,7 +1449,19 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_e200,
.platform = "ppc5554",
},
-#elif defined(CONFIG_E500)
+ { /* default match */
+ .pvr_mask = 0x,
+ .pvr_value = 0x,
+ .cpu_name = "(generic E200 PPC)",
+ .cpu_features = CPU_FTRS_E200,
+ .cpu_user_features = COMMON_USER_BOOKE |
+ PPC_FEATURE_HAS_EFP_SINGLE |
+ PPC_FEATURE_UNIFIED_CACHE,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_e200,
+ .platform = "ppc5554",
+#endif /* CONFIG_E200 */
+#ifdef CONFIG_E500
{ /* e500 */
.pvr_mask = 0x,
.pvr_value = 0x8020,
@@ -1463,20 +1497,19 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_e500,
.platform = "ppc8548",
},
-#endif
-#endif
-#if !CLASSIC_PPC
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
- .cpu_name = "(generic PPC)",
- .cpu_features = CPU_FTRS_GENERIC_32,
- .cpu_user_features = PPC_FEATURE_32,
+ .cpu_name = "(generic E500 PPC)",
+ .cpu_features = CPU_FTRS_E500,
+ .cpu_user_features = COMMON_USER_BOOKE |
+ PPC_FEATURE_HAS_SPE_COMP |
+ PPC_FEATURE_HAS_EFP_SINGLE_COMP,
.icache_bsize = 32,
.dcache_bsize = 32,
+ .machine_check = machine_check_e500,
.platform = "powerpc",
- }
-#endif /* !CLASSIC_PPC */
+#endif /* CONFIG_E500 */
#endif /* CONFIG_PPC32 */
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/5] macintosh: therm_pm72: driver_lock semaphore to mutex
On Fri, 2008-05-02 at 13:34 -0700, [EMAIL PROTECTED] wrote: > From: Daniel Walker <[EMAIL PROTECTED]> > > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Cc: Paul Mackerras <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 3/5] machintosh: ADB driver: adb_handler_sem semaphore to mutex
On Fri, 2008-05-02 at 13:34 -0700, [EMAIL PROTECTED] wrote: > From: Daniel Walker <[EMAIL PROTECTED]> > > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Cc: Paul Mackerras <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/5] macintosh: qindfarm_smu_sat: semaphore to mutex
On Fri, 2008-05-02 at 13:34 -0700, [EMAIL PROTECTED] wrote: > From: Daniel Walker <[EMAIL PROTECTED]> > > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Cc: Paul Mackerras <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: WARNING: mutexes are preferred for single holder semaphores
On Mon, May 05, 2008 at 12:13:43PM +1000, Paul Mackerras wrote: > Sean MacLennan writes: > > > This is a bit OT, but I got the warning in the subject from > > checkpatch.pl for a piece of code. The code *is* using a mutex. Does it > > actually mean I shouldn't use a mutex? > > I don't require zero checkpatch warnings or errors on patches before I > accept them. If what checkpatch is saying is rubbish, just ignore it. Current versions don't spew much rubbish anymore, and this one certainly isn't. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
