* Re: [git pull] Please pull from powerpc.git merge branch
From: Dave Jones @ 2008-07-16 4:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <1216172043.7740.136.camel@pasglop>
On Wed, Jul 16, 2008 at 11:34:03AM +1000, Ben Herrenschmidt wrote:
> Linus,
>
> I apologize in advance for the couple of merge commits in there. I
> merged your tree yesterday in order to fix a (fairly minor) conflict,
> and waited for our autobuilder to test a whole bunch of configs
> overnight before asking you to pull, at which point, sfr informed me of
> a bunch of this time non-trivial conflicts with whatever you pulled in
> the meantime...
>
> So here it is with 2 merge csets at the top, I'll try to do better next
> time. I don't want to rebase or my sub-maintainers will hate me.
>
> So please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Boom!
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
/builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
/builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
.config is at http://davej.fedorapeople.org/kernel-2.6.27-ppc.config
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-16 5:01 UTC (permalink / raw)
To: Dave Jones
Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list,
Kumar Gala
In-Reply-To: <20080716042042.GA13212@redhat.com>
On Wed, 2008-07-16 at 00:20 -0400, Dave Jones wrote:
> On Wed, Jul 16, 2008 at 11:34:03AM +1000, Ben Herrenschmidt wrote:
> > Linus,
> >
> > I apologize in advance for the couple of merge commits in there. I
> > merged your tree yesterday in order to fix a (fairly minor) conflict,
> > and waited for our autobuilder to test a whole bunch of configs
> > overnight before asking you to pull, at which point, sfr informed me of
> > a bunch of this time non-trivial conflicts with whatever you pulled in
> > the meantime...
> >
> > So here it is with 2 merge csets at the top, I'll try to do better next
> > time. I don't want to rebase or my sub-maintainers will hate me.
> >
> > So please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
> Boom!
>
> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
>
> .config is at http://davej.fedorapeople.org/kernel-2.6.27-ppc.config
Kumar, I think that's your realm, what's up there ?
Cheers,
Ben.
^ permalink raw reply
* Re: DTC: libfdt Install Woes
From: David Gibson @ 2008-07-16 5:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1216149974.20700.14.camel@ld0161-tx32>
On Tue, Jul 15, 2008 at 02:26:14PM -0500, Jon Loeliger wrote:
> David,
>
> Somewhat recently, the DTC commit 6a6c972cdf9e
> "dtc: Clean up included Makefile fragments"
> removed this line
>
> LIBFDT_INCLUDES = fdt.h libfdt.h
>
> from the libfdt/Makefile.libfdt. As a result,
> the standalone "make install" is onw failing.
Oops, that was a bit silly of me.
>
> We could put that line back, or remove the
> top-level Makefile install target that is
> trying to use this definition.
>
> I'm not sure which direction you want to head here.
I'd prefer to go with changing the top-level Makefile target.
--
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
* [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: fkan @ 2008-07-16 5:33 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Victor Gallardo
From: Victor Gallardo <vgallard@amcc.com>
ppc4xx: Add AMCC Arches 460GT eval board support
Signed-off-by: Victor Gallardo <vgallard@amcc.com>
---
arch/powerpc/platforms/44x/Kconfig | 18 ++++++++
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/arches.c | 76 +++++++++++++++++++++++++++++++++++
3 files changed, 95 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/arches.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 6abe913..95d1217 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -77,6 +77,16 @@ config CANYONLANDS
help
This option enables support for the AMCC PPC460EX evaluation board.
+config ARCHES
+ bool "Arches"
+ depends on 44x
+ default n
+ select 460GT
+ select PCI
+ select PPC4xx_PCI_EXPRESS
+ help
+ This option enables support for the AMCC PPC460GT Arches board.
+
config YOSEMITE
bool "Yosemite"
depends on 44x
@@ -149,6 +159,14 @@ config 460EX
select IBM_NEW_EMAC_ZMII
select IBM_NEW_EMAC_TAH
+config 460GT
+ bool
+ select PPC_FPU
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_RGMII
+ select IBM_NEW_EMAC_ZMII
+ select IBM_NEW_EMAC_TAH
+
# 44x errata/workaround config symbols, selected by the CPU models above
config IBM440EP_ERR42
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 774165f..86a4823 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_CANYONLANDS) += canyonlands.o
+obj-$(CONFIG_ARCHES) += arches.o
diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms/44x/arches.c
new file mode 100644
index 0000000..6d6aa66
--- /dev/null
+++ b/arch/powerpc/platforms/44x/arches.c
@@ -0,0 +1,76 @@
+/*
+ * Arches board specific routines
+ *
+ * (C) Copyright 2008
+ * Victor Gallardo, Applied Micro Circuits Corp., vgallardo@amcc.com.
+ * Adam Graham, Applied Micro Circuits Corp., agraham@amcc.com.
+ *
+ * Based on the Canyonlands code by
+ * Stefan Roese <sr@denx.de>
+ * Copyright 2008 DENX Software Engineering
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include <linux/init.h>
+#include <linux/of_platform.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+
+static __initdata struct of_device_id arches_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init arches_device_probe(void)
+{
+ of_platform_bus_probe(NULL, arches_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(arches, arches_device_probe);
+
+static int __init arches_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "amcc,arches"))
+ return 0;
+
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
+ return 1;
+}
+
+define_machine(arches) {
+ .name = "Arches",
+ .probe = arches_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
--
1.5.5
^ permalink raw reply related
* [PATCH] Add AMCC Arches DTS
From: fkan @ 2008-07-16 5:34 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Victor Gallardo
From: Victor Gallardo <vgallard@amcc.com>
ppc4xx: Add AMCC Arches DTS
Signed-off-by: Victor Gallardo <vgallard@amcc.com>
---
arch/powerpc/boot/dts/arches.dts | 522 ++++++++++++++++++++++++++++++++++++++
1 files changed, 522 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/arches.dts
diff --git a/arch/powerpc/boot/dts/arches.dts b/arch/powerpc/boot/dts/arches.dts
new file mode 100644
index 0000000..459cec2
--- /dev/null
+++ b/arch/powerpc/boot/dts/arches.dts
@@ -0,0 +1,522 @@
+/*
+ * Device Tree Source for AMCC Arches (dual 460GT board)
+ *
+ * (C) Copyright 2008
+ * Victor Gallardo, Applied Micro Circuits Corp., vgallardo@amcc.com.
+ * Adam Graham, Applied Micro Circuits Corp., agraham@amcc.com.
+ *
+ * Based on the glacier.dts file
+ * Stefan Roese <sr@denx.de>
+ * Copyright 2008 DENX Software Engineering
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,arches";
+ compatible = "amcc,arches";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,460GT";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ 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 U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460gt","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-460gt","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>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <a 4 b 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0f0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <10 4 11 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460gt";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460gt";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460gt", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460gt", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460gt", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <20>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 6 4
+ /*RXEOB*/ 7 4
+ /*SERR*/ 3 4
+ /*TXDE*/ 4 4
+ /*RXDE*/ 5 4>;
+ desc-base-addr-high = <8>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-460gt", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <b0000000 4 b0000000 50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-460gt", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ interrupts = <6 4>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl256n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 1e0000>;
+ };
+ partition@1e0000 {
+ label = "dtb";
+ reg = <1e0000 20000>;
+ };
+ partition@200000 {
+ label = "ramdisk";
+ reg = <200000 1400000>;
+ };
+ partition@1600000 {
+ label = "jffs2";
+ reg = <1600000 400000>;
+ };
+ partition@1a00000 {
+ label = "user";
+ reg = <1a00000 2560000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1d 4>;
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4>;
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-460gt", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601500 8>;
+ has-mdio;
+ };
+
+ RGMII1: emac-rgmii@ef601600 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601600 8>;
+ has-mdio;
+ };
+
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601350 30>;
+ };
+
+ TAH1: emac-tah@ef601450 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601450 30>;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 10 4
+ /*Wake*/ 1 &UIC2 14 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 11 4
+ /*Wake*/ 1 &UIC2 15 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <8>;
+ cell-index = <1>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ tah-device = <&TAH1>;
+ tah-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
+ };
+
+ EMAC2: ethernet@ef601100 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC2>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 12 4
+ /*Wake*/ 1 &UIC2 16 4>;
+ reg = <ef601100 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <2>;
+ mal-rx-channel = <10>;
+ cell-index = <2>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
+ };
+
+ EMAC3: ethernet@ef601200 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC3>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 13 4
+ /*Wake*/ 1 &UIC2 17 4>;
+ reg = <ef601200 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <3>;
+ mal-rx-channel = <18>;
+ cell-index = <3>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
+ };
+ };
+
+ PCIX0: pci@c0ec00000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pcix-460gt", "ibm,plb-pcix";
+ primary;
+ large-inbound-windows;
+ enable-msi-hole;
+ reg = <c 0ec00000 8 /* Config space access */
+ 0 0 0 /* no IACK cycles */
+ c 0ed00000 4 /* Special cycles */
+ c 0ec80000 100 /* Internal registers */
+ c 0ec80100 fc>; /* Internal messaging registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+ 01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 0 to 0x3f */
+ bus-range = <0 3f>;
+
+ /* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
+ interrupt-map-mask = <0000 0 0 0>;
+ interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
+ };
+
+ PCIE0: pciex@d00000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <d 00000000 20000000 /* Config space access */
+ c 08010000 00001000>; /* Registers */
+ dcr-reg = <100 020>;
+ sdr-base = <300>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+ 01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 40 to 0x7f */
+ bus-range = <40 7f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <1>; /* port number */
+ reg = <d 20000000 20000000 /* Config space access */
+ c 08011000 00001000>; /* Registers */
+ dcr-reg = <120 020>;
+ sdr-base = <340>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+ 01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 80 to 0xbf */
+ bus-range = <80 bf>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.5
^ permalink raw reply related
* [PATCH] Add AMCC Arches defconfig file
From: fkan @ 2008-07-16 5:37 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Victor Gallardo
From: Victor Gallardo <vgallard@amcc.com>
ppc4xx: Add AMCC Arches defconfig file
Signed-off-by: Victor Gallardo <vgallard@amcc.com>
---
arch/powerpc/configs/44x/arches_defconfig | 737 +++++++++++++++++++++++++++++
1 files changed, 737 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/configs/44x/arches_defconfig
diff --git a/arch/powerpc/configs/44x/arches_defconfig b/arch/powerpc/configs/44x/arches_defconfig
new file mode 100644
index 0000000..55396c9
--- /dev/null
+++ b/arch/powerpc/configs/44x/arches_defconfig
@@ -0,0 +1,737 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.26-rc5
+# Mon Jun 30 15:41:11 2008
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+# CONFIG_6xx is not set
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+# CONFIG_40x is not set
+CONFIG_44x=y
+# CONFIG_E200 is not set
+CONFIG_4xx=y
+CONFIG_BOOKE=y
+CONFIG_PTE_64BIT=y
+CONFIG_PHYS_64BIT=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
+CONFIG_PPC_MERGE=y
+CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
+CONFIG_IRQ_PER_CPU=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_OF=y
+CONFIG_PPC_UDBG_16550=y
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+# CONFIG_DEFAULT_UIMAGE is not set
+CONFIG_PPC_DCR_NATIVE=y
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_PPC_DCR=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_CGROUPS is not set
+# CONFIG_GROUP_SCHED is not set
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+# CONFIG_RELAY is not set
+# CONFIG_NAMESPACES is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=""
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SYSCTL=y
+CONFIG_EMBEDDED=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_SYSCTL_SYSCALL_CHECK=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_COMPAT_BRK=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLUB_DEBUG=y
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
+# CONFIG_SLOB is not set
+# CONFIG_PROFILING is not set
+# CONFIG_MARKERS is not set
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+# CONFIG_HAVE_DMA_ATTRS is not set
+CONFIG_PROC_PAGE_MONITOR=y
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+# CONFIG_BLK_DEV_BSG is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+CONFIG_CLASSIC_RCU=y
+CONFIG_PPC4xx_PCI_EXPRESS=y
+
+#
+# Platform support
+#
+# CONFIG_PPC_MPC512x is not set
+# CONFIG_PPC_MPC5121 is not set
+# CONFIG_PPC_CELL is not set
+# CONFIG_PPC_CELL_NATIVE is not set
+# CONFIG_PQ2ADS is not set
+# CONFIG_BAMBOO is not set
+# CONFIG_EBONY is not set
+# CONFIG_SEQUOIA is not set
+# CONFIG_TAISHAN is not set
+# CONFIG_KATMAI is not set
+# CONFIG_RAINIER is not set
+# CONFIG_WARP is not set
+# CONFIG_CANYONLANDS is not set
+CONFIG_ARCHES=y
+# CONFIG_YOSEMITE is not set
+CONFIG_460GT=y
+# CONFIG_IPIC is not set
+# CONFIG_MPIC is not set
+# CONFIG_MPIC_WEIRD is not set
+# CONFIG_PPC_I8259 is not set
+# CONFIG_PPC_RTAS is not set
+# CONFIG_MMIO_NVRAM is not set
+# CONFIG_PPC_MPC106 is not set
+# CONFIG_PPC_970_NAP is not set
+# CONFIG_PPC_INDIRECT_IO is not set
+# CONFIG_GENERIC_IOMAP is not set
+# CONFIG_CPU_FREQ is not set
+# CONFIG_FSL_ULI1575 is not set
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+CONFIG_TICK_ONESHOT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_300 is not set
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+# CONFIG_SCHED_HRTICK is not set
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_MATH_EMULATION is not set
+# CONFIG_IOMMU_HELPER is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_HAS_WALK_MEMORY=y
+CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
+CONFIG_PAGEFLAGS_EXTENDED=y
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_RESOURCES_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
+CONFIG_VIRT_TO_BUS=y
+CONFIG_FORCE_MAX_ZONEORDER=11
+CONFIG_PROC_DEVICETREE=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE=""
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_ZONE_DMA=y
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_4xx_SOC=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+CONFIG_PCI_SYSCALL=y
+# CONFIG_PCIEPORTBUS is not set
+CONFIG_ARCH_SUPPORTS_MSI=y
+# CONFIG_PCI_MSI is not set
+CONFIG_PCI_LEGACY=y
+# CONFIG_PCI_DEBUG is not set
+# CONFIG_PCCARD is not set
+# CONFIG_HOTPLUG_PCI is not set
+# CONFIG_HAS_RAPIDIO is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_PAGE_OFFSET=0xc0000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_PHYSICAL_START=0x00000000
+CONFIG_TASK_SIZE=0xc0000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_ARPD is not set
+# CONFIG_SYN_COOKIES is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_NETWORK_SECMARK is not set
+# CONFIG_NETFILTER is not set
+# CONFIG_IP_DCCP is not set
+# CONFIG_IP_SCTP is not set
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_CAN is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_AF_RXRPC is not set
+
+#
+# Wireless
+#
+# CONFIG_CFG80211 is not set
+# CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
+# CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
+# CONFIG_NET_9P is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+CONFIG_FW_LOADER=y
+# CONFIG_DEBUG_DRIVER is not set
+# CONFIG_DEBUG_DEVRES is not set
+# CONFIG_SYS_HYPERVISOR is not set
+CONFIG_CONNECTOR=y
+CONFIG_PROC_EVENTS=y
+# CONFIG_MTD is not set
+CONFIG_OF_DEVICE=y
+# CONFIG_PARPORT is not set
+CONFIG_BLK_DEV=y
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_CPQ_DA is not set
+# CONFIG_BLK_CPQ_CISS_DA is not set
+# CONFIG_BLK_DEV_DAC960 is not set
+# CONFIG_BLK_DEV_UMEM is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_SX8 is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=35000
+# CONFIG_BLK_DEV_XIP is not set
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+# CONFIG_XILINX_SYSACE is not set
+# CONFIG_MISC_DEVICES is not set
+CONFIG_HAVE_IDE=y
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+# CONFIG_SCSI_DMA is not set
+# CONFIG_SCSI_NETLINK is not set
+# CONFIG_ATA is not set
+# CONFIG_MD is not set
+# CONFIG_FUSION is not set
+
+#
+# IEEE 1394 (FireWire) support
+#
+# CONFIG_FIREWIRE is not set
+# CONFIG_IEEE1394 is not set
+# CONFIG_I2O is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NETDEVICES_MULTIQUEUE is not set
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_MACVLAN is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+# CONFIG_VETH is not set
+# CONFIG_ARCNET is not set
+# CONFIG_PHYLIB is not set
+CONFIG_NET_ETHERNET=y
+# CONFIG_MII is not set
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+# CONFIG_CASSINI is not set
+# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+CONFIG_IBM_NEW_EMAC=y
+CONFIG_IBM_NEW_EMAC_RXB=256
+CONFIG_IBM_NEW_EMAC_TXB=256
+CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
+CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
+CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
+# CONFIG_IBM_NEW_EMAC_DEBUG is not set
+CONFIG_IBM_NEW_EMAC_ZMII=y
+CONFIG_IBM_NEW_EMAC_RGMII=y
+CONFIG_IBM_NEW_EMAC_TAH=y
+CONFIG_IBM_NEW_EMAC_EMAC4=y
+# CONFIG_NET_PCI is not set
+# CONFIG_B44 is not set
+# CONFIG_NETDEV_1000 is not set
+# CONFIG_NETDEV_10000 is not set
+# CONFIG_TR is not set
+
+#
+# Wireless LAN
+#
+# CONFIG_WLAN_PRE80211 is not set
+# CONFIG_WLAN_80211 is not set
+# CONFIG_IWLWIFI_LEDS is not set
+# CONFIG_WAN is not set
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+# CONFIG_ISDN is not set
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+# CONFIG_INPUT is not set
+
+#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+CONFIG_DEVKMEM=y
+# CONFIG_SERIAL_NONSTANDARD is not set
+# CONFIG_NOZOMI is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+# CONFIG_SERIAL_8250_PCI is not set
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_RSA is not set
+
+#
+# Non-8250 serial port support
+#
+# CONFIG_SERIAL_UARTLITE is not set
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+# CONFIG_SERIAL_JSM is not set
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_LEGACY_PTYS=y
+CONFIG_LEGACY_PTY_COUNT=256
+# CONFIG_IPMI_HANDLER is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
+# CONFIG_RAW_DRIVER is not set
+# CONFIG_TCG_TPM is not set
+CONFIG_DEVPORT=y
+# CONFIG_I2C is not set
+# CONFIG_SPI is not set
+# CONFIG_W1 is not set
+# CONFIG_POWER_SUPPLY is not set
+# CONFIG_HWMON is not set
+# CONFIG_THERMAL is not set
+# CONFIG_WATCHDOG is not set
+
+#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+# CONFIG_SSB is not set
+
+#
+# Multifunction device drivers
+#
+# CONFIG_MFD_SM501 is not set
+# CONFIG_HTC_PASIC3 is not set
+
+#
+# Multimedia devices
+#
+
+#
+# Multimedia core support
+#
+# CONFIG_VIDEO_DEV is not set
+# CONFIG_DVB_CORE is not set
+# CONFIG_VIDEO_MEDIA is not set
+
+#
+# Multimedia drivers
+#
+CONFIG_DAB=y
+
+#
+# Graphics support
+#
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+# CONFIG_VGASTATE is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=m
+# CONFIG_FB is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Display device support
+#
+# CONFIG_DISPLAY_SUPPORT is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_MMC is not set
+# CONFIG_MEMSTICK is not set
+# CONFIG_NEW_LEDS is not set
+# CONFIG_ACCESSIBILITY is not set
+# CONFIG_INFINIBAND is not set
+# CONFIG_EDAC is not set
+# CONFIG_RTC_CLASS is not set
+# CONFIG_DMADEVICES is not set
+# CONFIG_UIO is not set
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_EXT4DEV_FS is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_OCFS2_FS is not set
+CONFIG_DNOTIFY=y
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_PROC_SYSCTL=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_TMPFS_POSIX_ACL is not set
+# CONFIG_HUGETLB_PAGE is not set
+# CONFIG_CONFIGFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+CONFIG_CRAMFS=y
+# CONFIG_VXFS_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_ROMFS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+CONFIG_NETWORK_FILESYSTEMS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+# CONFIG_NFS_V4 is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
+# CONFIG_RPCSEC_GSS_KRB5 is not set
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+# CONFIG_NLS is not set
+# CONFIG_DLM is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+# CONFIG_GENERIC_FIND_FIRST_BIT is not set
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
+CONFIG_CRC32=y
+# CONFIG_CRC7 is not set
+# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_PLIST=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_WARN_DEPRECATED=y
+CONFIG_ENABLE_MUST_CHECK=y
+CONFIG_FRAME_WARN=1024
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_UNUSED_SYMBOLS is not set
+CONFIG_DEBUG_FS=y
+# CONFIG_HEADERS_CHECK is not set
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_DEBUG_SHIRQ is not set
+CONFIG_DETECT_SOFTLOCKUP=y
+CONFIG_SCHED_DEBUG=y
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_TIMER_STATS is not set
+# CONFIG_DEBUG_OBJECTS is not set
+# CONFIG_SLUB_DEBUG_ON is not set
+# CONFIG_SLUB_STATS is not set
+# CONFIG_DEBUG_RT_MUTEXES is not set
+# CONFIG_RT_MUTEX_TESTER is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
+# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
+# CONFIG_DEBUG_KOBJECT is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_DEBUG_INFO is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_DEBUG_WRITECOUNT is not set
+# CONFIG_DEBUG_LIST is not set
+# CONFIG_DEBUG_SG is not set
+# CONFIG_BOOT_PRINTK_DELAY is not set
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_BACKTRACE_SELF_TEST is not set
+# CONFIG_FAULT_INJECTION is not set
+# CONFIG_SAMPLES is not set
+# CONFIG_KGDB is not set
+# CONFIG_DEBUG_STACKOVERFLOW is not set
+# CONFIG_DEBUG_STACK_USAGE is not set
+# CONFIG_DEBUG_PAGEALLOC is not set
+CONFIG_DEBUGGER=y
+# CONFIG_XMON is not set
+# CONFIG_IRQSTACKS is not set
+# CONFIG_VIRQ_DEBUG is not set
+# CONFIG_BDI_SWITCH is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+# CONFIG_SECURITY_FILE_CAPABILITIES is not set
+# CONFIG_CRYPTO is not set
+# CONFIG_PPC_CLOCK is not set
+# CONFIG_VIRTUALIZATION is not set
--
1.5.5
^ permalink raw reply related
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Jean Delvare @ 2008-07-16 7:46 UTC (permalink / raw)
To: David Hubbard
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Hans de Goede
In-Reply-To: <4dfa50520807150831i519a3a43n635ab7e58d35ba5e@mail.gmail.com>
Hi David,
On Tue, 15 Jul 2008 09:31:29 -0600, David Hubbard wrote:
> On Tue, Jul 15, 2008 at 2:36 AM, Jean Delvare <khali@linux-fr.org> wrote:
> > I always assumed that there was no way to know in advance if a
> > Super-I/O (LPC) chip was present or not, let alone the exact model of
> > the chip. The I/O addresses are decoded by the Super-I/O chip itself,
> > and in general it has no relation to PCI. And I've never seen ports
> > 0x2e/0x2f nor 0x4e/0x4f listed in /proc/ioports.
> >
> > But of course if there is a way to know, we should use it. Avoiding
> > random access to I/O ports, even if they are relatively standard in
> > this case, is always good.
>
> I looked at my lspci output and did a little researching, and I think
> the only thing we can deduce is that there is an LPC bridge, so
> looking for a SuperIO is a good idea. If there is no LPC bridge
> listed, I can't say whether probing the ports is a good idea or not.
Machines I have here have an "ISA bridge" PCI device. Some of them have
"LPC" in their name, but not all, and anyway the kernel only knows the
device ID, not its user-friendly name:
VIA:
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
Intel:
00:01.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 01)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
nVidia:
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
One of these machines has a LPC bridge but no (detected) Super-I/O chip.
The VIA and nVidia machines do not have "LPC" in their bridge name, but
they do have a Super-I/O chip, while the first Intel machine doesn't.
As a conclusion, there is no clear relationship between the presence of
an ISA or LPC bridge and the presence of a Super-I/O chip. All we can
say is that apparently all PC systems have an ISA bridge. So indeed we
can probably make the probes conditional upon the presence of an "ISA
bridge" PCI device. That's very easy to test. In practice it might be
equivalent to making the driver x86-only.
--
Jean Delvare
^ permalink raw reply
* Re: [patch 9/9] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
From: Arnd Bergmann @ 2008-07-16 7:54 UTC (permalink / raw)
To: Roland Dreier; +Cc: Mark Nelson, linuxppc-dev, cbe-oss-dev
In-Reply-To: <ada7ibmd115.fsf@cisco.com>
On Wednesday 16 July 2008, Roland Dreier wrote:
> =A0> Strong ordering is only active when both the bridge and the IOMMU en=
able
> =A0> it, but for correctly written drivers, this only results in a slowdo=
wn.
>=20
> So when would someone use this dma attribute? =A0As a hack to fix drivers
> where the real fix is too complicated?
This is used in the Axon PCIe endpoint drivers, e.g. in the Roadrunner
machine. The reason was to improve roundtrip latency by doing only
mmio stores, not loads, on each side of the PCIe connection, which
turn into posted DMA operations on the other end. With relaxed ordering,
the posted writes may be observed out of order. Strong ordering makes
sure they arrive in-order without having to do a non-posted mmio read
or eieio operation on the receiver side.
Arnd <><
^ permalink raw reply
* Re: Videomode 800x480
From: Alex_SYS @ 2008-07-16 8:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <487CEC85.2070801@denx.de>
Hello,
Alex_SYS wrote:
> Hello, I have the problem that I need a Framebuffer resolution 800x480!
> Since now I have filled the fb_info, var and fix Structs!
> But there was the problem with the resolution!
> I have found out that the problem is the videomode!
> In modedb there is unfortunately no 800x480 Videomode, and I have tried my
> own 800x480 Struct, but the Kernel does`t want my settings (I tried to
> change an 800x600 to 800x480 only by changing yres to 480).
> Can someone tell me please a working fb_videomode struct for 800x480?
Values for 800x480 fb_videomode depend on the TFT-panel that
you are using. Without the spec of this panel it is hard to guess.
It is also hard to guess the value for .pixclock as we do not know
if internal or external clock is used as the source for display
reference clock. What is the value of GDC DCM0 register (at
offset 0x1fd0000 or 0x1fd0100 from the GDC base)?
Try something like this:
.xres = 800
.yres = 480
.pixclock = 40000
.left_margin = 86
.right_margin = 42
.upper_margin = 33
.lower_margin = 10
.hsync_len = 128
.vsync_len = 2
> The syncs are setted up by U-Boot .
>then you probably should retrieve proper values for fb_videomode
>from display controller registers set up by U-Boot. If you do not
>have the spec for your panel, it is the way to go. Consult the
>GDC manual (Display control registers section) and
>Documentation/fb/framebuffer.txt in the linux source tree.
Hello, the physical settings for sync are made by U-Boot and working!
But in Lunux when I use 800x480, the screen is well, but the Kernel crashes
at Bootup!
Using 800x600 works!
Now I need only "Dummy" settings, that I can tell Linux I would like 800x480
and the Kernel doesn`t crash!
I don`t know exactly why the Kernel crashes, I know only that the modedB
800x600 and so on work!
I will try your settings immediately!
Thanks
Alex
Best regards,
Anatolij
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
View this message in context: http://www.nabble.com/Videomode-800x480-tp18470632p18482586.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Arnd Bergmann @ 2008-07-16 8:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dave Jones, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <20080716042042.GA13212@redhat.com>
On Wednesday 16 July 2008, Dave Jones wrote:
> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
FS_ENET and EP8248E both select MDIO_BITBANG, but not PHYLIB or MII, which
looks broken to me.
Also, I think it would be useful to split out the bitbang
driver from ep8248e.c, so that you can build it as a loadable
module if you want to have PHYLIB loadable.
Arnd <><
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Rene Herman @ 2008-07-16 8:09 UTC (permalink / raw)
To: Jean Delvare
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Hans de Goede, David Hubbard
In-Reply-To: <20080716094602.4379e0ff@hyperion.delvare>
On 16-07-08 09:46, Jean Delvare wrote:
> As a conclusion, there is no clear relationship between the presence
> of an ISA or LPC bridge and the presence of a Super-I/O chip. All we
> can say is that apparently all PC systems have an ISA bridge. So
> indeed we can probably make the probes conditional upon the presence
> of an "ISA bridge" PCI device. That's very easy to test. In practice
> it might be equivalent to making the driver x86-only.
And foregoing non (pre-) PCI. Admittedly, that might not be much of an
issue and I don't know if "Super-I/O" is maybe even defined such as to
make it a NON issue but I do for example remember my old 386 chipset
providing for extended serial rates which I thought was way cool back
then. If that's Super-I/O (or something that should/could be covered by
the infrastructure at least) then PCI wouldn't be helpful.
Rene.
^ permalink raw reply
* WRITING AN SOC DRIVER WITHOUT DMA
From: dinesh @ 2008-07-16 9:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080712083939.15025.31192.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 202 bytes --]
Hi,
I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i want to do data transfer to and from device myself using BUFFER DESCRIPTOR not with the usual DMA transfer.
Please help me.
[-- Attachment #2: Type: text/html, Size: 444 bytes --]
^ permalink raw reply
* Re: [lm-sensors] [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-16 9:12 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <20080711145613.14380360@hyperion.delvare>
Hi Jean,
Jean Delvare wrote:
> Hi Wolfgang,
>
> On Fri, 11 Jul 2008 14:40:58 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> There's no "detection" involved for the new-style i2c devices.
>>> Presumably you are still using the old binding model, not taking
>>> benefit of the patch at all. Use i2c_register_board_info() to
>>> instantiate your "ds75" i2c device from you board's platform code, and
>>> it should work.
>> I have some general question on I2C device probing. Our board does have
>> two I2C buses. On the first on, there is an RTC at addr 0x32 and a DS75
>> at 0x4c. Both are defined in the Flattened Device Tree and therefore
>> i2c_register_board_info() will be called for them. On the second bus,
>> there are other I2C devices. Nevertheless, probing for RTC and DS75 at
>> addr 0x32 and 0x4c will be performed also on that bus. Is this the
>> normal/intended behavior? Can such probing be suppressed?
>
> Probing isn't supposed to happen at all for RTC chips. There are a few
> drivers which remain to be converted though (rtc-ds1672, rtc-max6900,
> rtc-pcf8583.) If you use one of these and would like to help converting
> it, please tell me (and Alessandro Zummo.)
OK. We ported an old RTC driver for the Epson RX8025 for our board.
Unfortunately, it did not use the new bindings but I fixed that in the
meantime. It will be posted for kernel inclusion soon.
> For hwmon chips, probing only occurs if the i2c adapter accepts to be
> probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
> you do not want a given i2c bus to be probed, then do not set the flag
> for that bus.
I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
for the MPC:
http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
If I disable it, the LM75 driver only probes the addresses of the I2C
nodes defined in the FDT DTS file. I wonder if this should not be the
default behaviour for kernels using OF platform description. For this
reason, I have put Linuxppc-dev ML on CC. I also realized, that there
are some patches for OF I2C pending. I will check.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Jean Delvare @ 2008-07-16 9:33 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <487DBB92.1070100@grandegger.com>
Hi Wolfgang,
On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > For hwmon chips, probing only occurs if the i2c adapter accepts to be
> > probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
> > you do not want a given i2c bus to be probed, then do not set the flag
> > for that bus.
>
> I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
> for the MPC:
>
> http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
>
> If I disable it, the LM75 driver only probes the addresses of the I2C
> nodes defined in the FDT DTS file. I wonder if this should not be the
> default behaviour for kernels using OF platform description. For this
> reason, I have put Linuxppc-dev ML on CC. I also realized, that there
> are some patches for OF I2C pending. I will check.
The problem is that at this point in time, only a couple hwmon drivers
have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
would break most systems.
I have a set of patches converting most hwmon drivers to new-style i2c.
I plan to send it to Linus later today. Once all drivers are converted,
everyone can start adding device definitions to platform code. And only
once this is done for all platforms, you may remove I2C_CLASS_HWMON
from the i2c-mpc driver.
But even then, you can't exclude the possibility that some people want
to keep relying on the auto-detection mode. In that case, the setting
of the I2C_CLASS_HWMON flag should become an attribute of eacg i2c-mpc
device.
Anyway, this is something for every platform community to decide and
work on. As the i2c subsystem maintainer, I made my best so that
everything (sensible) is possible. But in the end it's up to the
"users" (i.e. platform developers and maintainers) to make the decision
of how things should work in their area. I can give advice on migration
paths, but I can't take decisions for them.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-16 9:50 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <20080716113311.384d211e@hyperion.delvare>
Hi Jean;
Jean Delvare wrote:
> Hi Wolfgang,
>
> On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> For hwmon chips, probing only occurs if the i2c adapter accepts to be
>>> probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
>>> you do not want a given i2c bus to be probed, then do not set the flag
>>> for that bus.
>> I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
>> for the MPC:
>>
>> http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
>>
>> If I disable it, the LM75 driver only probes the addresses of the I2C
>> nodes defined in the FDT DTS file. I wonder if this should not be the
>> default behaviour for kernels using OF platform description. For this
>> reason, I have put Linuxppc-dev ML on CC. I also realized, that there
>> are some patches for OF I2C pending. I will check.
>
> The problem is that at this point in time, only a couple hwmon drivers
> have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> would break most systems.
>
> I have a set of patches converting most hwmon drivers to new-style i2c.
> I plan to send it to Linus later today. Once all drivers are converted,
> everyone can start adding device definitions to platform code. And only
> once this is done for all platforms, you may remove I2C_CLASS_HWMON
> from the i2c-mpc driver.
Of course.
> But even then, you can't exclude the possibility that some people want
> to keep relying on the auto-detection mode. In that case, the setting
I understood that this is only true for the HWMON devices. Why the
special treatment?
> of the I2C_CLASS_HWMON flag should become an attribute of eacg i2c-mpc
> device.
Yep, as probing might not be acceptable in some cases, I makes sense to
add a property to suppress probing:
i2c@3000 {
...
compatible = "fsl-i2c";
dfsrr;
no-probing;
rtc@32 {
compatible = "epson,rx8025";
reg = <0x32>;
};
dtt@4c {
compatible = "dallas,ds75";
reg = <0x4c>;
};
};
> Anyway, this is something for every platform community to decide and
> work on. As the i2c subsystem maintainer, I made my best so that
> everything (sensible) is possible. But in the end it's up to the
> "users" (i.e. platform developers and maintainers) to make the decision
> of how things should work in their area. I can give advice on migration
> paths, but I can't take decisions for them.
I'm going to prepare a patch for that purpose.
Wolfgang.
^ permalink raw reply
* Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
From: Nobin Mathew @ 2008-07-16 10:07 UTC (permalink / raw)
To: dinesh; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <1216199130.749.4.camel@dinesh.dua>
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hi dinesh,
If you are working on ARM, see the ARM AACi code, in sound/arm/aaci.c
Thanks
Nobin Mathew.
On 7/16/08, dinesh <dinesh.dua@coraltele.com> wrote:
>
> Hi,
> I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i
> want to do data transfer to and from device myself using BUFFER DESCRIPTOR
> not with the usual DMA transfer.
> Please help me.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
[-- Attachment #2: Type: text/html, Size: 1025 bytes --]
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Jean Delvare @ 2008-07-16 10:10 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <487DC457.6000103@grandegger.com>
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > The problem is that at this point in time, only a couple hwmon drivers
> > have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> > would break most systems.
> >
> > I have a set of patches converting most hwmon drivers to new-style i2c.
> > I plan to send it to Linus later today. Once all drivers are converted,
> > everyone can start adding device definitions to platform code. And only
> > once this is done for all platforms, you may remove I2C_CLASS_HWMON
> > from the i2c-mpc driver.
>
> Of course.
>
> > But even then, you can't exclude the possibility that some people want
> > to keep relying on the auto-detection mode. In that case, the setting
>
> I understood that this is only true for the HWMON devices. Why the
> special treatment?
Not really. There are other I2C_CLASS_* flags, just check <linux/i2c.h>.
What makes hwmon a bit different is the historical context. Originally,
the hwmon drivers were written for PCs, which have no per-system
platform code, so declaring the devices was simply not an option.
Additionally, i2c was maintained as part of the lm-sensors project
itself. This determined the probe-everything approach that has ruled
the i2c subsystem until recently. I've spent (with a few other
developers) the past few years drawing a clear separation between i2c
and hwmon, and now making it possible to declare i2c devices where
possible. This is a lot of work if you want to do this without breaking
any system out there (which is my case.)
> > of the I2C_CLASS_HWMON flag should become an attribute of each i2c-mpc
> > device.
>
> Yep, as probing might not be acceptable in some cases, I makes sense to
> add a property to suppress probing:
It'd rather make no-probing the default if possible. My understanding
is that all systems using i2c-mpc should have proper platform data.
But then again, that's not really my business. The decision is left to
the actual users of this i2c bus driver.
--
Jean Delvare
^ permalink raw reply
* Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
From: dinesh @ 2008-07-16 10:13 UTC (permalink / raw)
To: Nobin Mathew; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <8d6898730807160307g4455597ck921d55da8f51455d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]
no i am working on powerpc. MPC8323
-----Original Message-----
From: Nobin Mathew <nobin.mathew@gmail.com>
To: dinesh <dinesh.dua@coraltele.com>
Cc: Grant Likely <grant.likely@secretlab.ca>, linuxppc-dev@ozlabs.org,
alsa-devel@alsa-project.org, liam.girdwood@wolfsonmicro.com
Subject: Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
Date: Wed, 16 Jul 2008 15:37:54 +0530
Hi dinesh,
If you are working on ARM, see the ARM AACi code, in sound/arm/aaci.c
Thanks
Nobin Mathew.
On 7/16/08, dinesh <dinesh.dua@coraltele.com> wrote:
>
> Hi,
> I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i
> want to do data transfer to and from device myself using BUFFER DESCRIPTOR
> not with the usual DMA transfer.
> Please help me.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[-- Attachment #2: Type: text/html, Size: 2198 bytes --]
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-16 10:23 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <20080716121059.2dbbfebe@hyperion.delvare>
Jean Delvare wrote:
> On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> The problem is that at this point in time, only a couple hwmon drivers
>>> have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
>>> would break most systems.
>>>
>>> I have a set of patches converting most hwmon drivers to new-style i2c.
>>> I plan to send it to Linus later today. Once all drivers are converted,
>>> everyone can start adding device definitions to platform code. And only
>>> once this is done for all platforms, you may remove I2C_CLASS_HWMON
>>> from the i2c-mpc driver.
>> Of course.
>>
>>> But even then, you can't exclude the possibility that some people want
>>> to keep relying on the auto-detection mode. In that case, the setting
>> I understood that this is only true for the HWMON devices. Why the
>> special treatment?
>
> Not really. There are other I2C_CLASS_* flags, just check <linux/i2c.h>.
>
> What makes hwmon a bit different is the historical context. Originally,
> the hwmon drivers were written for PCs, which have no per-system
> platform code, so declaring the devices was simply not an option.
> Additionally, i2c was maintained as part of the lm-sensors project
> itself. This determined the probe-everything approach that has ruled
> the i2c subsystem until recently. I've spent (with a few other
> developers) the past few years drawing a clear separation between i2c
> and hwmon, and now making it possible to declare i2c devices where
> possible. This is a lot of work if you want to do this without breaking
> any system out there (which is my case.)
I can image. Thanks for the explanation.
>
>>> of the I2C_CLASS_HWMON flag should become an attribute of each i2c-mpc
>>> device.
>> Yep, as probing might not be acceptable in some cases, I makes sense to
>> add a property to suppress probing:
>
> It'd rather make no-probing the default if possible. My understanding
> is that all systems using i2c-mpc should have proper platform data.
Yep, unfortunately, HWMON devices are not defined in most cases.
> But then again, that's not really my business. The decision is left to
> the actual users of this i2c bus driver.
A RFC patch is in preparation.
Wolfgang.
^ permalink raw reply
* [RFC] I2C: fsl-i2c: make device probing configurable via FDT
From: Wolfgang Grandegger @ 2008-07-16 10:47 UTC (permalink / raw)
Cc: Jean Delvare, Linuxppc-dev
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property "probe" of the FDT I2C device node:
i2c@3000 {
...
compatible = "fsl-i2c";
probe;
...
};
Assuming that systems using fsl-i2c should have proper platform data,
probing is disabled by default. Unfortunately, that's not the case and
various DTS files would require to be updated.
There have already been some discussion on this subject with Jean
under the following thread:
http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060008.html
Please comment.
Thanks,
Wolfgang.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/sysdev/fsl_soc.c | 4 ++++
drivers/i2c/busses/i2c-mpc.c | 17 ++++++++++++++---
include/linux/fsl_devices.h | 1 +
3 files changed, 19 insertions(+), 3 deletions(-)
Index: linux-2.6-denx/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- linux-2.6-denx.orig/drivers/i2c/busses/i2c-mpc.c
+++ linux-2.6-denx/drivers/i2c/busses/i2c-mpc.c
@@ -306,13 +306,21 @@ static const struct i2c_algorithm mpc_al
.functionality = mpc_functionality,
};
-static struct i2c_adapter mpc_ops = {
+static struct i2c_adapter mpc_probe_ops = {
.owner = THIS_MODULE,
.name = "MPC adapter",
.id = I2C_HW_MPC107,
.algo = &mpc_algo,
.class = I2C_CLASS_HWMON,
- .timeout = 1,
+ .timeout = 1,
+};
+
+static struct i2c_adapter mpc_ops = {
+ .owner = THIS_MODULE,
+ .name = "MPC adapter",
+ .id = I2C_HW_MPC107,
+ .algo = &mpc_algo,
+ .timeout = 1,
};
static int fsl_i2c_probe(struct platform_device *pdev)
@@ -354,7 +362,10 @@ static int fsl_i2c_probe(struct platform
mpc_i2c_setclock(i2c);
platform_set_drvdata(pdev, i2c);
- i2c->adap = mpc_ops;
+ (i2c->flags & FSL_I2C_DEV_PROBE)
+ i2c->adap = mpc_probe_ops;
+ else
+ i2c->adap = mpc_ops;
i2c->adap.nr = pdev->id;
i2c_set_adapdata(&i2c->adap, i2c);
i2c->adap.dev.parent = &pdev->dev;
Index: linux-2.6-denx/arch/powerpc/sysdev/fsl_soc.c
===================================================================
--- linux-2.6-denx.orig/arch/powerpc/sysdev/fsl_soc.c
+++ linux-2.6-denx/arch/powerpc/sysdev/fsl_soc.c
@@ -518,6 +518,10 @@ static int __init fsl_i2c_of_init(void)
if (flags)
i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
+ flags = of_get_property(np, "probe", NULL);
+ if (flags)
+ i2c_data.device_flags |= FSL_I2C_DEV_PROBE;
+
ret =
platform_device_add_data(i2c_dev, &i2c_data,
sizeof(struct
Index: linux-2.6-denx/include/linux/fsl_devices.h
===================================================================
--- linux-2.6-denx.orig/include/linux/fsl_devices.h
+++ linux-2.6-denx/include/linux/fsl_devices.h
@@ -82,6 +82,7 @@ struct fsl_i2c_platform_data {
/* Flags related to I2C device features */
#define FSL_I2C_DEV_SEPARATE_DFSRR 0x00000001
#define FSL_I2C_DEV_CLOCK_5200 0x00000002
+#define FSL_I2C_DEV_PROBE 0x00000004
enum fsl_usb2_operating_modes {
FSL_USB2_MPH_HOST,
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-16 11:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kumar Gala, Linux Kernel list, linuxppc-dev, Dave Jones, akpm,
Linus Torvalds
In-Reply-To: <200807161051.12545.arnd@arndb.de>
On Wed, 2008-07-16 at 10:51 +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Dave Jones wrote:
> > arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> > /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
> > /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
>
> FS_ENET and EP8248E both select MDIO_BITBANG, but not PHYLIB or MII, which
> looks broken to me.
>
> Also, I think it would be useful to split out the bitbang
> driver from ep8248e.c, so that you can build it as a loadable
> module if you want to have PHYLIB loadable.
On that note... I already run it through an autobuilder with a bunch of
configs before uploading (though obviously not this one). Kumar, can you
send me 2 or 3 configs you believe cover a reasonable range of the fsl
stuff that I could stick into my list for next time ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches DTS
From: Josh Boyer @ 2008-07-16 11:39 UTC (permalink / raw)
To: fkan; +Cc: linuxppc-dev, Victor Gallardo, linuxppc-embedded
In-Reply-To: <1216186476-28018-1-git-send-email-fkan@amcc.com>
On Tue, 15 Jul 2008 22:34:36 -0700
fkan@amcc.com wrote:
> From: Victor Gallardo <vgallard@amcc.com>
>
> ppc4xx: Add AMCC Arches DTS
>
> Signed-off-by: Victor Gallardo <vgallard@amcc.com>
> ---
> arch/powerpc/boot/dts/arches.dts | 522 ++++++++++++++++++++++++++++++++++++++
> 1 files changed, 522 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/arches.dts
>
> diff --git a/arch/powerpc/boot/dts/arches.dts b/arch/powerpc/boot/dts/arches.dts
> new file mode 100644
> index 0000000..459cec2
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/arches.dts
> @@ -0,0 +1,522 @@
> +/*
> + * Device Tree Source for AMCC Arches (dual 460GT board)
> + *
> + * (C) Copyright 2008
> + * Victor Gallardo, Applied Micro Circuits Corp., vgallardo@amcc.com.
> + * Adam Graham, Applied Micro Circuits Corp., agraham@amcc.com.
> + *
> + * Based on the glacier.dts file
> + * Stefan Roese <sr@denx.de>
> + * Copyright 2008 DENX Software Engineering
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +/ {
Could you convert this to a dts-v1 file please? All the in-tree DTS
files are dts-v1 and I'd very much like to keep it that way.
> + #address-cells = <2>;
> + #size-cells = <1>;
> + model = "amcc,arches";
> + compatible = "amcc,arches";
> + dcr-parent = <&/cpus/cpu@0>;
> +
> + aliases {
> + ethernet0 = &EMAC0;
> + ethernet1 = &EMAC1;
> + serial0 = &UART0;
> + serial1 = &UART1;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + model = "PowerPC,460GT";
> + reg = <0>;
> + clock-frequency = <0>; /* Filled in by U-Boot */
> + timebase-frequency = <0>; /* Filled in by U-Boot */
> + i-cache-line-size = <20>;
> + d-cache-line-size = <20>;
> + i-cache-size = <8000>;
> + d-cache-size = <8000>;
> + dcr-controller;
> + dcr-access-method = "native";
> + };
If this is a dual-460GT, why is there only one CPU node listed? Is it
simply because Linux will only see one CPU as it is an AMP
configuration?
josh
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Josh Boyer @ 2008-07-16 11:50 UTC (permalink / raw)
To: fkan; +Cc: linuxppc-dev, Victor Gallardo, linuxppc-embedded
In-Reply-To: <1216186406-27993-1-git-send-email-fkan@amcc.com>
On Tue, 15 Jul 2008 22:33:26 -0700
fkan@amcc.com wrote:
> From: Victor Gallardo <vgallard@amcc.com>
>=20
> ppc4xx: Add AMCC Arches 460GT eval board support=20
>=20
> Signed-off-by: Victor Gallardo <vgallard@amcc.com>
=46rom what I can tell, you don't even need this patch or the defconfig.
Nothing differs at this point from Glacier other than the DTS. Since
U-Boot is your loader, it should be able to pass the different DTS to a
kernel that supports Cayonlands and have no issues.
> ---
> arch/powerpc/platforms/44x/Kconfig | 18 ++++++++
> arch/powerpc/platforms/44x/Makefile | 1 +
> arch/powerpc/platforms/44x/arches.c | 76 +++++++++++++++++++++++++++++=
++++++
> 3 files changed, 95 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/44x/arches.c
>=20
> diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/=
44x/Kconfig
> index 6abe913..95d1217 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -77,6 +77,16 @@ config CANYONLANDS
> help
> This option enables support for the AMCC PPC460EX evaluation board.
>=20
> +config ARCHES
> + bool "Arches"
> + depends on 44x
> + default n
> + select 460GT
> + select PCI
> + select PPC4xx_PCI_EXPRESS
> + help
> + This option enables support for the AMCC PPC460GT Arches board.
If you do want to have explicit support for Arches, that's fine. Look
at how Yosemite is supported. It just reuses Bamboo. You could do the
same.
> config YOSEMITE
> bool "Yosemite"
> depends on 44x
> @@ -149,6 +159,14 @@ config 460EX
> select IBM_NEW_EMAC_ZMII
> select IBM_NEW_EMAC_TAH
>=20
> +config 460GT
> + bool
> + select PPC_FPU
> + select IBM_NEW_EMAC_EMAC4
> + select IBM_NEW_EMAC_RGMII
> + select IBM_NEW_EMAC_ZMII
> + select IBM_NEW_EMAC_TAH
I don't see a reason to add this at all. 460EX and 460GT select the
same set of options.
> # 44x errata/workaround config symbols, selected by the CPU models above
> config IBM440EP_ERR42
> bool
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms=
/44x/Makefile
> index 774165f..86a4823 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER) +=3D rainier.o
> obj-$(CONFIG_WARP) +=3D warp.o
> obj-$(CONFIG_WARP) +=3D warp-nand.o
> obj-$(CONFIG_CANYONLANDS) +=3D canyonlands.o
> +obj-$(CONFIG_ARCHES) +=3D arches.o
Here you would just have:
obj-$(CONFIG_ARCHES) +=3D cayonlands.o
> diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms=
/44x/arches.c
> new file mode 100644
> index 0000000..6d6aa66
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/arches.c
And then you don't need this file at all. Just add a
"amcc,canyonlands" string to your root node compatible property.
josh
^ permalink raw reply
* Re: [RFC] I2C: fsl-i2c: make device probing configurable via FDT
From: Jean Delvare @ 2008-07-16 12:05 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linuxppc-dev
In-Reply-To: <487DD1BD.8040701@grandegger.com>
Hi Wolfgang,
On Wed, 16 Jul 2008 12:47:25 +0200, Wolfgang Grandegger wrote:
> Currently, the I2C buses are probed for HWMON I2C devices, which might
> not be acceptable in same cases. This patch makes device probing
> configurable through the property "probe" of the FDT I2C device node:
>
> i2c@3000 {
> ...
> compatible = "fsl-i2c";
> probe;
> ...
> };
>
> Assuming that systems using fsl-i2c should have proper platform data,
> probing is disabled by default. Unfortunately, that's not the case and
> various DTS files would require to be updated.
>
> There have already been some discussion on this subject with Jean
> under the following thread:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060008.html
>
> Please comment.
>
> Thanks,
>
> Wolfgang.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 4 ++++
> drivers/i2c/busses/i2c-mpc.c | 17 ++++++++++++++---
> include/linux/fsl_devices.h | 1 +
> 3 files changed, 19 insertions(+), 3 deletions(-)
>
> Index: linux-2.6-denx/drivers/i2c/busses/i2c-mpc.c
> ===================================================================
> --- linux-2.6-denx.orig/drivers/i2c/busses/i2c-mpc.c
> +++ linux-2.6-denx/drivers/i2c/busses/i2c-mpc.c
> @@ -306,13 +306,21 @@ static const struct i2c_algorithm mpc_al
> .functionality = mpc_functionality,
> };
>
> -static struct i2c_adapter mpc_ops = {
> +static struct i2c_adapter mpc_probe_ops = {
> .owner = THIS_MODULE,
> .name = "MPC adapter",
> .id = I2C_HW_MPC107,
> .algo = &mpc_algo,
> .class = I2C_CLASS_HWMON,
> - .timeout = 1,
> + .timeout = 1,
Your patch is adding undesirable leading white space.
> +};
> +
> +static struct i2c_adapter mpc_ops = {
> + .owner = THIS_MODULE,
> + .name = "MPC adapter",
> + .id = I2C_HW_MPC107,
> + .algo = &mpc_algo,
> + .timeout = 1,
> };
I don't think you need 2 separate structures. Just set the class field
at runtime (see below.)
>
> static int fsl_i2c_probe(struct platform_device *pdev)
> @@ -354,7 +362,10 @@ static int fsl_i2c_probe(struct platform
> mpc_i2c_setclock(i2c);
> platform_set_drvdata(pdev, i2c);
>
> - i2c->adap = mpc_ops;
> + (i2c->flags & FSL_I2C_DEV_PROBE)
Missing if? :)
> + i2c->adap = mpc_probe_ops;
> + else
> + i2c->adap = mpc_ops;
Or just:
i2c->adap = mpc_ops;
if (i2c->flags & FSL_I2C_DEV_PROBE)
i2c->adap.flags = I2C_CLASS_HWMON;
> i2c->adap.nr = pdev->id;
> i2c_set_adapdata(&i2c->adap, i2c);
> i2c->adap.dev.parent = &pdev->dev;
> Index: linux-2.6-denx/arch/powerpc/sysdev/fsl_soc.c
> ===================================================================
> --- linux-2.6-denx.orig/arch/powerpc/sysdev/fsl_soc.c
> +++ linux-2.6-denx/arch/powerpc/sysdev/fsl_soc.c
> @@ -518,6 +518,10 @@ static int __init fsl_i2c_of_init(void)
> if (flags)
> i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
>
> + flags = of_get_property(np, "probe", NULL);
> + if (flags)
> + i2c_data.device_flags |= FSL_I2C_DEV_PROBE;
> +
> ret =
> platform_device_add_data(i2c_dev, &i2c_data,
> sizeof(struct
> Index: linux-2.6-denx/include/linux/fsl_devices.h
> ===================================================================
> --- linux-2.6-denx.orig/include/linux/fsl_devices.h
> +++ linux-2.6-denx/include/linux/fsl_devices.h
> @@ -82,6 +82,7 @@ struct fsl_i2c_platform_data {
> /* Flags related to I2C device features */
> #define FSL_I2C_DEV_SEPARATE_DFSRR 0x00000001
> #define FSL_I2C_DEV_CLOCK_5200 0x00000002
> +#define FSL_I2C_DEV_PROBE 0x00000004
>
> enum fsl_usb2_operating_modes {
> FSL_USB2_MPH_HOST,
As a side note: in general it is not a good idea to use a template for
struct i2c_adapter. This structure is relatively large compared to the
few fields you need to set. If you insist on having a template, it
should at least be marked either const or __initdata.
--
Jean Delvare
^ permalink raw reply
* Re: [RFC] I2C: fsl-i2c: make device probing configurable via FDT
From: Jon Smirl @ 2008-07-16 12:47 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Jean Delvare, Linuxppc-dev
In-Reply-To: <487DD1BD.8040701@grandegger.com>
On 7/16/08, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Currently, the I2C buses are probed for HWMON I2C devices, which might
> not be acceptable in same cases. This patch makes device probing
> configurable through the property "probe" of the FDT I2C device node:
All this patch seems to be doing is removing class I2C_CLASS_HWMON via
a device tree flag, PROBE.
Why do you need to do this? The OF conversion patch that is working
its way through the system lets you put the address of the device into
the device tree node. Probing shouldn't be necessary at all.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox