Re: Device Tree & PCI
> [EMAIL PROTECTED] { > interrupt-map-mask = <0f800 0 0 7>; > interrupt-map = < > /* IDSEL 0x10 */ > 8000 0 0 1 &PCI_INT 1 > > /* IDSEL 0x11 */ > 8800 0 0 1 &PCI_INT 2 > > /* IDSEL 0x12 */ > 9000 0 0 1 &PCI_INT 3 > > /* IDSEL 0x13 */ > 9800 0 0 1 &PCI_INT 4>; > }; Your PCI bridge node needs more than those 2 properties. At the very least it needs device_type "pci" and name "pci" (rather than pci-bridge) to make the kernel parser happier, it also needs a proper class code and a "reg" property providing its configuration address (devfn) so that the kernel can do the matching between what it finds on the PCI bus and that node. Basically, you need to make sure the function pci_device_to_OF_node() works for your bridge or the interrupt resolution will not work. I'd suggest you add debugging to that function to dump what it's doing so you can get your tree in order. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
Hi Jon, On Fri, 11 Jan 2008 20:20:15 +0100, Jean Delvare wrote: > > +{ > > + /* only powerpc drivers implement the id_table, > > +* it is empty on other platforms */ > > + if (id) { > > + while (id->name[0]) { > > + if (strcmp(client->driver_name, id->name) == 0) > > This doesn't look right to me. You should be comparing client->name, > not client->driver_name, with id->name. Where id_table is implemented, > client->driver_name might not even be set. I see that the next patch in > the series makes use of client->driver_name as well, so your code > "works"... but this ain't correct still. Err, scratch this (and related comments), I just realized what you were trying to do. That's different from what I had in mind and so I read your code wrong. I'll read it (and test it) again not making this incorrect assumption and my comments will likely be different after that. Well, I still think that it needs to be changed a bit, but probably not in the direction I suggested at first (which, I realize now, has its own share of issues - so it's not fair to me to point you there.) Sorry for the trouble. I'll post updated comments later today, but I'm also pretty busy with other issues, some of which need to be solved before 2.6.24 is released so I can't really delay them. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Sat, Jan 12, 2008 at 06:57:24PM +1100, Benjamin Herrenschmidt wrote: > > On Sat, 2008-01-12 at 08:26 +0100, Stefan Roese wrote: > > > > We shouldn't make it too complicated. We can always select different > > settings > > in the defconfig file. My thinking here is to better wast a little > > memory > > with a potential performance improvement. Just me 0.02$ > > If it gets really critical, then we can move those settings to the > device-tree. Come on guys, it's not that critical. I guess I just don't trust a certain company :) -- Eugene ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
On Fri, 11 Jan 2008 15:16:57 -0500, Jon Smirl wrote: > On 1/11/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > Secondly, it promotes OF device names as acceptable aliases. This I > > don't think I agree with. While I see some value in moving the OF name > > -> Linux name translation to the drivers themselves (even though I > > don't see this as a mandatory move either), this doesn't imply that OF > > names should be used as aliases. I don't like the idea that different > > architectures will name the same device differently in a visible way. > > This could easily break user-space code that makes assumptions on the > > device names (libsensors comes to mind.) So, I think that this part > > will need some more discussion. > > They're aliases. On the x86 my e1000 Ethernet driver loads using this > alias name: > "pci:v8086d1010sv*sd*bc*sc*i*" > In fact, the e1000 driver has 63 alias names in addition to "e1000" > > But it's still the e1000 driver after it is loaded. > [EMAIL PROTECTED]:/home/linux/drivers/net/e1000$ lsmod | grep e1000 > e1000 115968 0 > > Loading a I2C driver with an OF alias name is not going to change the > module name after it is loaded. In fact, once the module is in memory > there's no way to tell what name was used to load it. Of course. That's not what I was worried about... what I was worried about is something your patch set doesn't do but I misread the code and I thought it was doing. I'll read it again before I make more comments on this. > OF device names are set by the Open Firmware committee. It is not > reasonable to force the Linux names back into Open Firmware since this > would force the other operating systems using Open Firmware to adopt > the Linux names. I never meant to force the Linux names into Open Firmware. It wouldn't make sense especially when the Linux names are invented by random contributors with no specific rules, and can even change over time. What I meant is that the translation from Open Firmware device name to Linux device name could happen in different ways. Making module aliases out of the is one possibility but this is not the only one. I am curious why the translation could not happen "offline". As I understand it, you're getting the device names from these .dts files. However you're not parsing them in the kernel directly, are you? I presume that you have some tool that converts these files into C code that the kernel can use? This conversion tool could translate the names. > This issue hasn't been visible before since there was a global table > in the PowerPC code mapping all known Open Firmware names into linux > names. Keeping this as a global table doesn't scale. The mapping needs > to be done by each device individually. Looking at your patch set, I see only 11 entries in the table (in arch/powerpc/sysdev/fsl_soc.c) that patch #2 deletes. Are there more in other files? I'm asking because 11 entries hardly qualifies as "doesn't scale". I sure hope that you're not doing all this for the sole purpose of getting rid of this 11-element table. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
On 1/12/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > On Fri, 11 Jan 2008 15:16:57 -0500, Jon Smirl wrote: > > On 1/11/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > Secondly, it promotes OF device names as acceptable aliases. This I > > > don't think I agree with. While I see some value in moving the OF name > > > -> Linux name translation to the drivers themselves (even though I > > > don't see this as a mandatory move either), this doesn't imply that OF > > > names should be used as aliases. I don't like the idea that different > > > architectures will name the same device differently in a visible way. > > > This could easily break user-space code that makes assumptions on the > > > device names (libsensors comes to mind.) So, I think that this part > > > will need some more discussion. > > > > They're aliases. On the x86 my e1000 Ethernet driver loads using this > > alias name: > > "pci:v8086d1010sv*sd*bc*sc*i*" > > In fact, the e1000 driver has 63 alias names in addition to "e1000" > > > > But it's still the e1000 driver after it is loaded. > > [EMAIL PROTECTED]:/home/linux/drivers/net/e1000$ lsmod | grep e1000 > > e1000 115968 0 > > > > Loading a I2C driver with an OF alias name is not going to change the > > module name after it is loaded. In fact, once the module is in memory > > there's no way to tell what name was used to load it. > > Of course. That's not what I was worried about... what I was worried > about is something your patch set doesn't do but I misread the code and > I thought it was doing. I'll read it again before I make more comments > on this. > > > OF device names are set by the Open Firmware committee. It is not > > reasonable to force the Linux names back into Open Firmware since this > > would force the other operating systems using Open Firmware to adopt > > the Linux names. > > I never meant to force the Linux names into Open Firmware. It wouldn't > make sense especially when the Linux names are invented by random > contributors with no specific rules, and can even change over time. > > What I meant is that the translation from Open Firmware device name to > Linux device name could happen in different ways. Making module aliases > out of the is one possibility but this is not the only one. > > I am curious why the translation could not happen "offline". As I > understand it, you're getting the device names from these .dts files. > However you're not parsing them in the kernel directly, are you? I > presume that you have some tool that converts these files into C code > that the kernel can use? This conversion tool could translate the names. Those dts files are for embedded devices that were specifically developed for Linux. All of the PowerPC Macs in the world have a device tree in ROM that was developed by Apple following the Open Firmware standard. Same thing for Sun boxes, but I'm not working on those. The kernel has an existing mechanism for handling translations like these, the alias scheme. > > This issue hasn't been visible before since there was a global table > > in the PowerPC code mapping all known Open Firmware names into linux > > names. Keeping this as a global table doesn't scale. The mapping needs > > to be done by each device individually. > > Looking at your patch set, I see only 11 entries in the table (in > arch/powerpc/sysdev/fsl_soc.c) that patch #2 deletes. Are there more in > other files? I'm asking because 11 entries hardly qualifies as "doesn't > scale". I sure hope that you're not doing all this for the sole purpose > of getting rid of this 11-element table. Currently developers add entries to the table in their private builds for the i2c devices they are using. Another way to avoid adding a table entry is to create a platform device in the platform code. But this support is being extended to audio codecs too. There are hundreds of audio codecs. The whole purpose of this code is to dynamically load the correct i2c and audio drivers by reading the device tree instead of having static i2s/codec devices for every possible platform combination. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
On 1/12/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi Jon, > > On Fri, 11 Jan 2008 20:20:15 +0100, Jean Delvare wrote: > > > +{ > > > + /* only powerpc drivers implement the id_table, > > > +* it is empty on other platforms */ > > > + if (id) { > > > + while (id->name[0]) { > > > + if (strcmp(client->driver_name, id->name) == 0) > > > > This doesn't look right to me. You should be comparing client->name, > > not client->driver_name, with id->name. Where id_table is implemented, > > client->driver_name might not even be set. I see that the next patch in > > the series makes use of client->driver_name as well, so your code > > "works"... but this ain't correct still. > > Err, scratch this (and related comments), I just realized what you were > trying to do. That's different from what I had in mind and so I read > your code wrong. I'll read it (and test it) again not making this > incorrect assumption and my comments will likely be different after > that. Well, I still think that it needs to be changed a bit, but > probably not in the direction I suggested at first (which, I realize > now, has its own share of issues - so it's not fair to me to point you > there.) The common scheme used elsewhere in the kernel for handling more than one device in a single driver is aliases. The i2c code's existing driver_name/type combination is a different way of implementing the same feature. But there is no real need for driver_name/type on any platform if aliases are used. Back in version 10 or 11 I had code in there which replaced the two fields with aliases on all platforms but too many people objected so I removed it.. IMHO, driver_name/type should be removed in new style drivers and replaced with aliases on all platforms since aliases are the standard kernel mechanism. > > Sorry for the trouble. I'll post updated comments later today, but I'm > also pretty busy with other issues, some of which need to be solved > before 2.6.24 is released so I can't really delay them. > > -- > Jean Delvare > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
Stefan Roese wrote: > You define here one gpio node that covers both gpio controllers of the 440EP. > I suggest to use two nodes here, like: > > GPIO0: [EMAIL PROTECTED] { > compatible = "ibm,gpio-440ep"; > reg = ; > }; > > GPIO1: [EMAIL PROTECTED] { > compatible = "ibm,gpio-440ep"; > reg = ; > }; > > Best regards, > Stefan > Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts new file mode 100644 index 000..dc1499d --- /dev/null +++ b/arch/powerpc/boot/dts/warp.dts @@ -0,0 +1,239 @@ +/* + * Device Tree Source for PIKA Warp + * + * Copyright (c) 2008 PIKA Technologies + * Sean MacLennan <[EMAIL PROTECTED]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without + * any warranty of any kind, whether express or implied. + */ + +/ { + #address-cells = <2>; + #size-cells = <1>; + model = "pika,warp"; + compatible = "pika,warp"; + dcr-parent = <&/cpus/[EMAIL PROTECTED]>; + + aliases { + ethernet0 = &EMAC0; + serial0 = &UART0; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + [EMAIL PROTECTED] { + device_type = "cpu"; + model = "PowerPC,440EP"; + reg = <0>; + clock-frequency = <0>; /* Filled in by zImage */ + timebase-frequency = <0>; /* Filled in by zImage */ + i-cache-line-size = <20>; + d-cache-line-size = <20>; + i-cache-size = <8000>; + d-cache-size = <8000>; + dcr-controller; + dcr-access-method = "native"; + }; + }; + + memory { + device_type = "memory"; + reg = <0 0 0>; /* Filled in by zImage */ + }; + + UIC0: interrupt-controller0 { + compatible = "ibm,uic-440ep","ibm,uic"; + interrupt-controller; + cell-index = <0>; + dcr-reg = <0c0 009>; + #address-cells = <0>; + #size-cells = <0>; + #interrupt-cells = <2>; + }; + + UIC1: interrupt-controller1 { + compatible = "ibm,uic-440ep","ibm,uic"; + interrupt-controller; + cell-index = <1>; + dcr-reg = <0d0 009>; + #address-cells = <0>; + #size-cells = <0>; + #interrupt-cells = <2>; + interrupts = <1e 4 1f 4>; /* cascade */ + interrupt-parent = <&UIC0>; + }; + + SDR0: sdr { + compatible = "ibm,sdr-440ep"; + dcr-reg = <00e 002>; + }; + + CPR0: cpr { + compatible = "ibm,cpr-440ep"; + dcr-reg = <00c 002>; + }; + + plb { + compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4"; + #address-cells = <2>; + #size-cells = <1>; + ranges; + clock-frequency = <0>; /* Filled in by zImage */ + + SDRAM0: sdram { + compatible = "ibm,sdram-440ep", "ibm,sdram-405gp"; + dcr-reg = <010 2>; + }; + + DMA0: dma { + compatible = "ibm,dma-440ep", "ibm,dma-440gp"; + dcr-reg = <100 027>; + }; + + MAL0: mcmal { + compatible = "ibm,mcmal-440ep", "ibm,mcmal-440gp", "ibm,mcmal"; + dcr-reg = <180 62>; + num-tx-chans = <4>; + num-rx-chans = <2>; + interrupt-parent = <&MAL0>; + interrupts = <0 1 2 3 4>; + #interrupt-cells = <1>; + #address-cells = <0>; + #size-cells = <0>; + interrupt-map = ; + }; + + POB0: opb { + compatible = "ibm,opb-440ep", "ibm,opb-440gp", "ibm,opb"; + #address-cells = <1>; + #size-cells = <1>; + ranges = < 0 8000 + 8000 0 8000 8000>; + interrupt-parent = <&UIC1>; + interrupts = <7 4>; + clock-frequency = <0>; /* Filled in by zImage */ + + EBC0: ebc { + compatible = "ibm,ebc-440ep", "ibm,ebc-440gp", "ibm,ebc";
Re: [PATCH 1/5] Warp Base Platform
Please ignore the last patch. I left in a debug to check that the non-ad7414 case works. Cheers, Sean Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 66a3d8c..b3e4c35 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -469,7 +469,7 @@ config MCA config PCI bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \ || PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \ - || PPC_PS3 + || PPC_PS3 || 44x default y if !40x && !CPM2 && !8xx && !PPC_83xx \ && !PPC_85xx && !PPC_86xx default PCI_PERMEDIA if !4xx && !CPM2 && !8xx diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index d248013..a95409e 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -53,6 +53,19 @@ config RAINIER help This option enables support for the AMCC PPC440GRX evaluation board. +config WARP + bool "PIKA Warp" + depends on 44x + default n + select 440EP + help + This option enables support for the PIKA Warp(tm) Appliance. The Warp + is a small computer replacement with up to 9 ports of FXO/FXS plus VOIP + stations and trunks. + + See http://www.pikatechnologies.com/ and follow the "PIKA for Computer + Telephony Developers" link for more information. + #config LUAN # bool "Luan" # depends on 44x @@ -75,6 +88,7 @@ config 440EP select PPC_FPU select IBM440EP_ERR42 select IBM_NEW_EMAC_ZMII + select USB_ARCH_HAS_OHCI config 440EPX bool diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile index a2a0dc1..7aaee9d 100644 --- a/arch/powerpc/platforms/44x/Makefile +++ b/arch/powerpc/platforms/44x/Makefile @@ -5,3 +5,5 @@ obj-$(CONFIG_BAMBOO)+= bamboo.o obj-$(CONFIG_SEQUOIA) += sequoia.o obj-$(CONFIG_KATMAI) += katmai.o obj-$(CONFIG_RAINIER) += rainier.o +obj-$(CONFIG_WARP) += warp.o +#obj-$(CONFIG_WARP)+= warp-nand.o diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c new file mode 100644 index 000..0053958 --- /dev/null +++ b/arch/powerpc/platforms/44x/warp-nand.c @@ -0,0 +1,92 @@ +/* + * PIKA Warp(tm) NAND flash specific routines + * + * Copyright (c) 2008 PIKA Technologies + * Sean MacLennan <[EMAIL PROTECTED]> + */ + +#include +#include +#include +#include +#include +#include + + +#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */ + +#define WARP_NAND_FLASH_REG_ADDR 0xD000UL +#define WARP_NAND_FLASH_REG_SIZE 0x2000 + +static struct resource warp_ndfc = { + .start = WARP_NAND_FLASH_REG_ADDR, + .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE, + .flags = IORESOURCE_MEM, +}; + +static struct mtd_partition nand_parts[] = { + { + .name = "nand", + .offset = 0, + .size = MTDPART_SIZ_FULL, + } +}; + +struct ndfc_controller_settings warp_ndfc_settings = { + .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1), + .ndfc_erpn = 0, +}; + +static struct ndfc_chip_settings warp_chip0_settings = { + .bank_settings = 0x8000, +}; + +struct platform_nand_ctrl warp_nand_ctrl = { + .priv = &warp_ndfc_settings, +}; + +static struct platform_device warp_ndfc_device = { + .name = "ndfc-nand", + .id = 0, + .dev = { + .platform_data = &warp_nand_ctrl, + }, + .num_resources = 1, + .resource = &warp_ndfc, +}; + +static struct nand_ecclayout nand_oob_16 = { + .eccbytes = 3, + .eccpos = { 0, 1, 2, 3, 6, 7 }, + .oobfree = { {.offset = 8, .length = 16} } +}; + +static struct platform_nand_chip warp_nand_chip0 = { + .nr_chips = 1, + .chip_offset = CS_NAND_0, + .nr_partitions = ARRAY_SIZE(nand_parts), + .partitions = nand_parts, + .chip_delay = 50, + .ecclayout = &nand_oob_16, + .priv = &warp_chip0_settings, +}; + +static struct platform_device warp_nand_device = { + .name = "ndfc-chip", + .id = 0, + .num_resources = 1, + .resource = &warp_ndfc, + .dev = { + .platform_data = &warp_nand_chip0, + .parent = &warp_ndfc_device.dev, + } +}; + +static int warp_setup_nand_flash(void) +{ + platform_device_register(&warp_ndfc_device); + platform_device_register(&warp_nand_device); + + return 0; +} +device_initcall(warp_setup_nand_flash); diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c new file mode 100644 index 000..97d5c33 --- /dev/null +++ b/arch/powerpc/platforms/44x/warp.c @@ -0,0 +1,186 @@ +/* + * PIKA Warp(tm) board specific routines + * + * Copyright (c) 2008 PIKA Technologies + * Sean
Re: [PATCH 1/5] Warp Base Platform
Stefan Roese wrote: > > You are accessing the 440EP GPIO controller here right? Then you really > should > use big endian access routines. From you code I assume that you have > connected the LED signals to GPIO00 and GPIO01. I suggest to use code that > looks like this: > > #define LED_GREEN (0x8000 >> 0) > #define LED_RED (0x8000 >> 1) > > leds = in_be32(gpio_base); > > switch (green) { > case 0: leds &= ~LED_GREEN; break; > case 1: leds |= LED_GREEN; break; > } > switch (red) { > case 0: leds &= ~LED_RED; break; > case 1: leds |= LED_RED; break; > } > >outbe32(leds, gpio_base); > > And when you change the dts to describe both GPIO controllers you should map > the 2nd one and remove the 0x100 offset above as I have done above. > > Best regards, > Stefan > Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 66a3d8c..b3e4c35 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -469,7 +469,7 @@ config MCA config PCI bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \ || PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \ - || PPC_PS3 + || PPC_PS3 || 44x default y if !40x && !CPM2 && !8xx && !PPC_83xx \ && !PPC_85xx && !PPC_86xx default PCI_PERMEDIA if !4xx && !CPM2 && !8xx diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index d248013..a95409e 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -53,6 +53,19 @@ config RAINIER help This option enables support for the AMCC PPC440GRX evaluation board. +config WARP + bool "PIKA Warp" + depends on 44x + default n + select 440EP + help + This option enables support for the PIKA Warp(tm) Appliance. The Warp + is a small computer replacement with up to 9 ports of FXO/FXS plus VOIP + stations and trunks. + + See http://www.pikatechnologies.com/ and follow the "PIKA for Computer + Telephony Developers" link for more information. + #config LUAN # bool "Luan" # depends on 44x @@ -75,6 +88,7 @@ config 440EP select PPC_FPU select IBM440EP_ERR42 select IBM_NEW_EMAC_ZMII + select USB_ARCH_HAS_OHCI config 440EPX bool diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile index a2a0dc1..7aaee9d 100644 --- a/arch/powerpc/platforms/44x/Makefile +++ b/arch/powerpc/platforms/44x/Makefile @@ -5,3 +5,5 @@ obj-$(CONFIG_BAMBOO)+= bamboo.o obj-$(CONFIG_SEQUOIA) += sequoia.o obj-$(CONFIG_KATMAI) += katmai.o obj-$(CONFIG_RAINIER) += rainier.o +obj-$(CONFIG_WARP) += warp.o +#obj-$(CONFIG_WARP)+= warp-nand.o diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c new file mode 100644 index 000..0053958 --- /dev/null +++ b/arch/powerpc/platforms/44x/warp-nand.c @@ -0,0 +1,92 @@ +/* + * PIKA Warp(tm) NAND flash specific routines + * + * Copyright (c) 2008 PIKA Technologies + * Sean MacLennan <[EMAIL PROTECTED]> + */ + +#include +#include +#include +#include +#include +#include + + +#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */ + +#define WARP_NAND_FLASH_REG_ADDR 0xD000UL +#define WARP_NAND_FLASH_REG_SIZE 0x2000 + +static struct resource warp_ndfc = { + .start = WARP_NAND_FLASH_REG_ADDR, + .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE, + .flags = IORESOURCE_MEM, +}; + +static struct mtd_partition nand_parts[] = { + { + .name = "nand", + .offset = 0, + .size = MTDPART_SIZ_FULL, + } +}; + +struct ndfc_controller_settings warp_ndfc_settings = { + .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1), + .ndfc_erpn = 0, +}; + +static struct ndfc_chip_settings warp_chip0_settings = { + .bank_settings = 0x8000, +}; + +struct platform_nand_ctrl warp_nand_ctrl = { + .priv = &warp_ndfc_settings, +}; + +static struct platform_device warp_ndfc_device = { + .name = "ndfc-nand", + .id = 0, + .dev = { + .platform_data = &warp_nand_ctrl, + }, + .num_resources = 1, + .resource = &warp_ndfc, +}; + +static struct nand_ecclayout nand_oob_16 = { + .eccbytes = 3, + .eccpos = { 0, 1, 2, 3, 6, 7 }, + .oobfree = { {.offset = 8, .length = 16} } +}; + +static struct platform_nand_chip warp_nand_chip0 = { + .nr_chips = 1, + .chip_offset = CS_NAND_0, + .nr_partitions = ARRAY_SIZE(nand_parts), + .partitions = nand_parts, + .chip_delay = 50, + .ecclayout = &nand_oob_16, + .priv = &warp_chip0_settings, +}; + +static struct platform_device warp_nand_device
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Anton Vorontsov wrote: > Otherwise oops will happen if ethernet device has not been opened: > > Unable to handle kernel paging request for data at address 0x014c > Faulting instruction address: 0xc016f7f0 > Oops: Kernel access of bad area, sig: 11 [#1] > MPC85xx > NIP: c016f7f0 LR: c01722a0 CTR: > REGS: c79ddc70 TRAP: 0300 Not tainted (2.6.24-rc3-g820a386b) > MSR: 00029000 CR: 20004428 XER: 2000 > DEAR: 014c, ESR: > TASK = c789f5e0[999] 'snmpd' THREAD: c79dc000 > GPR00: c01aceb8 c79ddd20 c789f5e0 c79ddd3c c79ddd64 > GPR08: c7845b60 c79dde3c c01ace80 20004422 200249fc 02a0 100da728 > GPR16: 100c 20022078 0009 200220e0 bfc85558 > GPR24: c79ddd3c c02e0e70 c022fc64 c7845800 bfc85498 > NIP [c016f7f0] phy_ethtool_gset+0x0/0x4c > LR [c01722a0] fs_get_settings+0x18/0x28 > Call Trace: > [c79ddd20] [c79dde38] 0xc79dde38 (unreliable) > [c79ddd30] [c01aceb8] dev_ethtool+0x294/0x11ec > [c79dde30] [c01aaa44] dev_ioctl+0x454/0x6a8 > [c79ddeb0] [c019b9d4] sock_ioctl+0x84/0x230 > [c79dded0] [c007ded8] do_ioctl+0x34/0x8c > [c79ddee0] [c007dfbc] vfs_ioctl+0x8c/0x41c > [c79ddf10] [c007e38c] sys_ioctl+0x40/0x74 > [c79ddf40] [c000d4c0] ret_from_syscall+0x0/0x3c > Instruction dump: > 8163 800b0030 2f80 419e0010 7c0803a6 4e800021 7c691b78 80010014 > 7d234b78 38210010 7c0803a6 4e800020 <8003014c> 7c6b1b78 3860 90040004 > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > Acked-by: Vitaly Bordug <[EMAIL PROTECTED]> > --- > > Just resending it, it feels like it got lost during holidays. > > drivers/net/fs_enet/fs_enet-main.c | 11 +-- > 1 files changed, 9 insertions(+), 2 deletions(-) applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: Only deal with apple fix if res is memory
On Jan 11, 2008, at 4:03 PM, Benjamin Herrenschmidt wrote: > > On Fri, 2008-01-11 at 10:38 -0600, Kumar Gala wrote: >> Ben, >> >> Will this impact the apple fix? I'm getting some _IO cases hitting >> this. > > No, your fix is right, it's a bug to compare against pci_mem_offset > and > not check if it's a memory resource in the first place. I would > suggest > that you do the res->flags test first in the if () statement for > clarity > though. ok, will clean up the patch and resend. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
On Sat, Jan 12, 2008 at 12:27:05AM -0700, Grant Grundler wrote: > Looking at setup-bus.c:pci_bridge_check_ranges(), I'm concluding that: > [7] is IO Range. > [8] is MMIO > [9] is Prefetchable MMIO > [10] no clue...maybe used by host PCI bus controllers. #10 is for cardbus bridges, IIRC. > 0x10 is 1MB and would be the minimum MMIO range that can be allocated. > So that looks right too. Probably need to find out what is allocating > 0xe000 instead. I believe that the setup-bus code just tried to allocate 1M ROM of some device using prefetchable window of the bridge :00:00.0. That failed, probably because there is no MEM space left on the root bus, which is perfectly OK. Then, the ROM might be successfully allocated in the non-prefetchable MMIO space. So, I don't see any problem in this situation. The only thing I could suggest is to lower the log level in that message from KERN_ERR to KERN_WARNING... Ivan. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Hi Sean, On Sat, 12 Jan 2008 15:42:45 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote: > > +++ b/arch/powerpc/platforms/44x/warp.c > +static int __init warp_probe(void) > +{ > + unsigned long root = of_get_flat_dt_root(); > + > + if (!of_flat_dt_is_compatible(root, "pika,warp")) > + return 0; > + > + return 1; I should have noticed this earlier and it is really only a simple cleanup but it could be done if you do another respin. return of_flat_dt_is_compatible(root, "pika,warp"); > +void warp_set_power_leds(int green, int red) > +{ > + static void __iomem *gpio_base = NULL; > + unsigned leds; > + > + if (gpio_base == NULL) { > + struct device_node *np, *from; > + int i; > + > + /* Power LEDS are on the second GPIO controller */ > + for (from = NULL, i = 0; i < 2; ++i, from = np) { > + np = of_find_compatible_node(from, NULL, > "ibm,gpio-440EP"); > + if (np == NULL) { > + printk(KERN_ERR __FILE__ ": Unable to find > gpio\n"); > + return; > + } > + } struct device_node *np; int i = 0; for_each_compatible_node(np, NULL, "ibm,gpio-440EP") if (i++ == 1) break; if (i < 2) { printk(KERN_ERR __FILE__ ": Unable to find gpio\n"); return; } or struct device_node *np = of_find_compatible_node(NULL, NULL, "ibm,gpio-440EP"); if (np) np = of_find_compatible_node(np, NULL, "ibm,gpio-440EP"); if (!np) { printk(KERN_ERR __FILE__ ": Unable to find gpio\n"); return; } One small thing - all three solutions assume that the device tree routines return the nodes in the order that they are in the dts file ... which is OK for now, but something to consider. > + gpio_base = of_iomap(np, 0); of_node_put(np); > +static int __devinit warp_fpga_init(void) > + irq = irq_of_parse_and_map(np, 0); > + if (irq == NO_IRQ) { of_node_put(np); > + printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n"); > + return -EBUSY; > + } > + > + /* We do not call of_iomap here since it would map in the entire > + * fpga space, which is over 8k. > + */ > + if (of_address_to_resource(np, 0, &res)) { of_node_put(np); > + printk(KERN_ERR __FILE__ ": Unable to get FPGA address\n"); > + return -ENOENT; > + } of_node_put(np); -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgphazTYnCgLR.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev