mtd maps
Are mtd maps still in drivers/mtd/maps or has that all moved to the platform code? I have an mtd map for the mpc8560ads but it's in mtd/maps. Greg W
I2C RTC recommendations?
Ed Goforth wrote: I'm looking to add a RTC to a custom 440gx-based board. The board developer has indicated that they would prefer use an I2C device (vs. eg. something like the DS1743 that's on the reference board). I got my board equipped with Epson's RX-8025 SA/NB RTC module. I managed to get it working with a few hacks to a 8564 RTC driver from Stefan Eletzhofer This RTC module is also from Epson. So far everything works fine. I don't really know why board designers decided for it but I suppose the main concern was price. :D regards, Ivica
modem control for 8xx serial
Hi all, Has anyone implemented modem control in arch/ppc/8xx_io/serial.c. I don't want to reinvent the wheel if someone's already done it. I'll be glad to do the dirty work and submit it if anyone is interested. Thanks, David H.
[PATCH 1/3] PPC440EP SoC and Bamboo board support
Hello all, This adds support for the IBM/AMCC PPC440EP SoC and the Bamboo reference board. Any comments would be appreciated. Regards, Wade Farnsworth Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com -- next part -- A non-text attachment was scrubbed... Name: ibm440ep-ppc.patch Type: text/x-patch Size: 82336 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/4a67c59b/attachment.bin
[PATCH 1/3] PPC440EP SoC and Bamboo board support
On Tue, Mar 15, 2005 at 10:17:19AM -0700, Wade Farnsworth wrote:
Hello all,
This adds support for the IBM/AMCC PPC440EP SoC and the Bamboo reference
board. Any comments would be appreciated.
[snip]
diff -uprN linux-2.6.11-bk7/arch/ppc/platforms/4xx/ibm440ep.c
linux-2.6.11-bk7-440ep/arch/ppc/platforms/4xx/ibm440ep.c
--- linux-2.6.11-bk7/arch/ppc/platforms/4xx/ibm440ep.c1969-12-31
17:00:00.0 -0700
+++ linux-2.6.11-bk7-440ep/arch/ppc/platforms/4xx/ibm440ep.c 2005-03-11
16:26:19.0 -0700
@@ -0,0 +1,176 @@
+/*
+ * arch/ppc/platforms/4xx/ibm440ep.c
+ *
+ * PPC440EP I/O descriptions
+ *
+ * Wade Farnsworth wfarnsworth at mvista.com
+ * Copyright 2004 MontaVista Software Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+#include linux/init.h
+#include linux/module.h
+#include platforms/4xx/ibm440ep.h
+#include asm/ocp.h
+
+static struct ocp_func_emac_data ibm440ep_emac0_def = {
+ .rgmii_idx = -1, /* No RGMII */
+ .rgmii_mux = -1, /* No RGMII */
+ .zmii_idx = 0,/* ZMII device index */
+ .zmii_mux = 0,/* ZMII input of this EMAC */
+ .mal_idx= 0,/* MAL device index */
+ .mal_rx_chan= 0,/* MAL rx channel number */
+ .mal_tx_chan= 0,/* MAL tx channel number */
+ .wol_irq= 61, /* WOL interrupt number */
+ .mdio_idx = -1, /* No shared MDIO */
+ .tah_idx= -1, /* No TAH */
+};
+
+static struct ocp_func_emac_data ibm440ep_emac1_def = {
+ .rgmii_idx = -1, /* No RGMII */
+ .rgmii_mux = -1, /* No RGMII */
+ .zmii_idx = 0,/* ZMII device index */
+ .zmii_mux = 1,/* ZMII input of this EMAC */
+ .mal_idx= 0,/* MAL device index */
+ .mal_rx_chan= 1,/* MAL rx channel number */
+ .mal_tx_chan= 2,/* MAL tx channel number */
+ .wol_irq= 63, /* WOL interrupt number */
+ .mdio_idx = -1, /* No shared MDIO */
+ .tah_idx= -1, /* No TAH */
+};
+OCP_SYSFS_EMAC_DATA()
+
+static struct ocp_func_mal_data ibm440ep_mal0_def = {
+ .num_tx_chans = 4,/* Number of TX channels */
+ .num_rx_chans = 2,/* Number of RX channels */
+ .txeob_irq = 10, /* TX End Of Buffer IRQ */
+ .rxeob_irq = 11, /* RX End Of Buffer IRQ */
+ .txde_irq = 33, /* TX Descriptor Error IRQ */
+ .rxde_irq = 34, /* RX Descriptor Error IRQ */
+ .serr_irq = 32, /* MAL System Error IRQ*/
+};
+OCP_SYSFS_MAL_DATA()
+
+static struct ocp_func_iic_data ibm440ep_iic0_def = {
+ .fast_mode = 0,/* Use standad mode (100Khz) */
+};
+
+static struct ocp_func_iic_data ibm440ep_iic1_def = {
+ .fast_mode = 0,/* Use standad mode (100Khz) */
+};
+OCP_SYSFS_IIC_DATA()
+
+struct ocp_def core_ocp[] = {
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_OPB,
+ .index= 0,
+ .paddr= 0xEF60,
+ .irq = OCP_IRQ_NA,
+ .pm = OCP_CPM_NA,
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_16550,
+ .index= 0,
+ .paddr= PPC440EP_UART0_ADDR,
+ .irq = UART0_INT,
+ .pm = IBM_CPM_UART0,
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_16550,
+ .index= 1,
+ .paddr= PPC440EP_UART1_ADDR,
+ .irq = UART1_INT,
+ .pm = IBM_CPM_UART1,
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_16550,
+ .index= 2,
+ .paddr= PPC440EP_UART2_ADDR,
+ .irq = UART2_INT,
+ .pm = IBM_CPM_UART2,
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_16550,
+ .index= 3,
+ .paddr= PPC440EP_UART3_ADDR,
+ .irq = UART3_INT,
+ .pm = IBM_CPM_UART3,
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_IIC,
+ .index= 0,
+ .paddr= PPC440EP_IIC0_ADDR,
Do we need PPC440EP_IIC0_ADDR define? I think not, please, don't
introduce useless defines which are only used in one file. Use numbers
directly, it helps readability. Please, look at how this is
handled in other 4xx platform files.
+ .irq
[PATCH 2/3] PPC440EP: ibm_emac phy mode bug fix
This patch fixes a bug in drivers/net/ibm_emac/ibm_emac_core.c where if the MDI0 bit is set in the ZMII_FER register, then the phy mode is not detected properly, and SMII is selected by default. This only occurs on platforms where the phy_mode field of struct ocp_func_emac_data is not used. Regards, Wade Farnsworth Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ibm440ep-ibm_emac-bugfix.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/6c18a936/attachment.txt
[PATCH 3/3] PPC440EP IBM EMAC support
This patch adds support to the IBM EMAC ethernet driver for the 440EP. Regards, Wade Farnsworth Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ibm440ep-ibm_emac.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/6c5cbc97/attachment.txt
[patch] mpc8560ads mtd map
Add an MTD map for the flash on the mpc8560ads board.
Signed-off-by: Greg Weeks greg.weeks at timesys.com
--- /dev/null
+++ ppc-mpc8560ads/drivers/mtd/maps/mpc85xxads.c
@@ -0,0 +1,104 @@
+/*
+ * $Id$
+ *
+ * Mapping for Motorola MPC85xxADS flash
+ *
+ * Greg Weeks greg.weeks at timesys.com
+ *
+ * Copyright 2004 Timesys Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/mtd/mtd.h
+#include linux/mtd/map.h
+#include linux/mtd/partitions.h
+#include linux/config.h
+#include asm/io.h
+#include platforms/85xx/mpc85xx_ads_common.h
+
+static struct mtd_info *flash;
+
+static struct map_info mpc85xxads_map = {
+ .name = mpc85xxads-flash,
+ .size = MPC85XXADS_FLASH_SIZE,
+ .bankwidth =4,
+};
+
+static struct mtd_partition mpc85xxads_partitions[] = {
+ {
+ .name = Linux JFFS2 Filesystem,
+ .offset = 0x0,
+ .size = 0x0080,
+ },
+ {
+ .name = Linux Kernel,
+ .offset = 0x0080,
+ .size = 0x0020,
+ },
+ {
+ .name = Linux INITRD,
+ .offset = 0x00a0,
+ .size = 0x0058,
+ },
+ {
+ .name = Bootloader,
+ .offset = 0x00f8,
+ .size = 0x0008,
+ }
+};
+
+int __init mpc85xxads_map_init(void)
+{
+ unsigned long mpc85xxads_flash_base = MPC85XXADS_FLASH_BASE;
+
+ mpc85xxads_map.phys = mpc85xxads_flash_base;
+ mpc85xxads_map.virt = (unsigned
long)ioremap(mpc85xxads_flash_base, mpc85xxads_map.size);
+
+ if (!mpc85xxads_map.virt) {
+ printk(Failed to ioremap flash\n);
+ return -EIO;
+ }
+
+ simple_map_init(mpc85xxads_map);
+
+ flash = do_map_probe(cfi_probe, mpc85xxads_map);
+ if (flash) {
+ flash-owner = THIS_MODULE;
+ add_mtd_partitions(flash, mpc85xxads_partitions,
+ ARRAY_SIZE(mpc85xxads_partitions));
+ } else {
+ iounmap((void *)mpc85xxads_map.virt);
+ printk(map probe failed for flash\n);
+ return -ENXIO;
+ }
+
+ return 0;
+}
+
+static void __exit mpc85xxads_map_exit(void)
+{
+ if (flash) {
+ del_mtd_partitions(flash);
+ map_destroy(flash);
+ }
+
+ if (mpc85xxads_map.virt) {
+ iounmap((void *)mpc85xxads_map.virt);
+ mpc85xxads_map.virt = 0;
+ }
+}
+
+module_init(mpc85xxads_map_init);
+module_exit(mpc85xxads_map_exit);
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Greg Weeks greg.weeks at timesys.com);
+MODULE_DESCRIPTION(MTD map and partitions for Motorola MPC85xxADS);
--- ppc-mpc8560ads/arch/ppc/platforms/85xx/mpc85xx_ads_common.h-orig
+++ ppc-mpc8560ads/arch/ppc/platforms/85xx/mpc85xx_ads_common.h
@@ -47,4 +47,7 @@
#define MPC85XX_PCI1_IO_SIZE 0x0100
+#define MPC85XXADS_FLASH_BASE 0xff00
+#define MPC85XXADS_FLASH_SIZE 0x0100
+
#endif /* __MACH_MPC85XX_ADS_H__ */
--- ppc-mpc8560ads/drivers/mtd/maps/Kconfig-orig
+++ ppc-mpc8560ads/drivers/mtd/maps/Kconfig
@@ -667,5 +667,12 @@
help
This enables access to the flash chip on the Sharp SL Series
of PDAs.
+config MTD_MPC85XXADS
+ tristate Flash device mapped on the MPC85XXADS board
+ depends on MTD_CFI MTD_CFI_INTELEXT MTD_PARTITIONS
MPC8560_ADS
+ help
+ This enables access to the Flash on the MPC85xxADS boards.
+ If you have such a board, say 'Y'.
+
endmenu
--- ppc-mpc8560ads/drivers/mtd/maps/Makefile-orig
+++ ppc-mpc8560ads/drivers/mtd/maps/Makefile
[PATCH 1/3] PPC440EP SoC and Bamboo board support
On Tue, 2005-03-15 at 11:41, Eugene Surovegin wrote: [snip] diff -uprN linux-2.6.11-bk7/include/asm-ppc/reg.h linux-2.6.11-bk7-440ep/include/asm-ppc/reg.h --- linux-2.6.11-bk7/include/asm-ppc/reg.h 2005-03-11 16:25:22.0 -0700 +++ linux-2.6.11-bk7-440ep/include/asm-ppc/reg.h2005-03-14 10:05:47.0 -0700 @@ -449,6 +449,8 @@ #define PVR_STB03XXX 0x4031 #define PVR_NP405H 0x4141 #define PVR_NP405L 0x4161 +#define PVR_440EP_RA 0x42221850 +#define PVR_440EP_RB 0x422218D3 I don't think it's needed. There are plans to get rid of all not-used PVR defines. The PVR for the Rev A is needed for a workaround in the IBM EMAC code (see patch 3/3). If there is a better way to do this, or if it would be better to put the PVR define somewhere else, please let me know. Thanks for your comments. Regards, Wade Farnsworth
[patch] mpc8560ads mtd map
Greg Weeks wrote: Add an MTD map for the flash on the mpc8560ads board. Signed-off-by: Greg Weeks greg.weeks at timesys.com snip Most of the code in this patch can be eliminated if you set up the table in your platform file and use the proper CONFIG_MTD_xxx options. Mark
modem control for 8xx serial
In message OF53FB4D54.F4DBA8F0-ON85256FC5.0053C4E5-85256FC5.00542475 at nanometrics.ca you wrote: Has anyone implemented modem control in arch/ppc/8xx_io/serial.c. I don't Sure. See the Linux trees on our CVS server. And read the FAQ section in the DULG, too. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie
RFC: PHY Abstraction Layer II
Hi Andy, I finally found some time to review your phy abstraction code. I haven't reviewed the low level MII functions; I focused mostly on its API to the net driver and whether it has the necessary hooks to handle the various hardware that I know. General comment: nice, clean code. No serious style or Linux kernel core API issues that I can see. Specific comments follow. - It isn't obvious what has to be done in net drivers to hook up this code. Consider writing a Documentation/networking/phy.txt to describe typical net driver code changes needed. - If a net driver is modified to use your new code, should it use any functions from mii.c at all? I guess I'm unclear about the relationship with mii.c. - netif_carrier_on()/off() calls are done by mii.c on link state changes. Consider doing the same inside your phy code. - Some hardware does not use a separate irq for phy but instead indicates phy events via the ethernet chip's irq. There are registered phy_driver callbacks to handle things like read/clear/ack interrupt status. But if my ethernet device's phy interrupt is effectively one or more bits in the ethernet chip's status register (where there is no separate phy interrupt), how would this hook into your phy code? For example, in the interrupt handler of mv643xx_eth, we check status bits that indicate link state change from the same register that indicates rx/tx packet events. Also, NAPI drivers will disable irqs and poll for tx/rx while there is work to do. If they have a combined tx/rx/phy interrupt then does this pose other issues for hooking up the new phy code? - What determines whether the phy driver uses interrupts or polling? - The callback registered in phy_connect() is called when phy link changes are detected. It is passed a struct device*. How about letting the net driver register its struct net_device* which would be passed back in the callback? It is likely that the callback will need access to net driver data anyway. Some net drivers will need to reconfigure their ethernet chip for duplex/speed setting changes, for example. Passing in the struct net_device* also lets the phy code call netif_xxx() functions such as netif_carrier_on()/off() mentioned earlier as well as the netif_msg_xxx message control macros. - The callback function is only called by the phy timer poll as far as I can tell. Shouldn't it also be called in the phy interrupt handler when link state changes? - Have all phy printk messages controlled by the netif_msg_ macros. - Many drivers use mii.c to implement ethtool functions. I don't see equivalents in your new code. - Does include/linux/phy.h represent a public API for use by net drivers or is it also the internal API used by various C files in your phy code? It seems to contain some data/defs that are private to the implementation. Separate some members of struct phy_device into public and private parts and move the private bits into separate files away from include/linux? - phy_sanitize_settings() / phy_force_reduction() I don't understand why this is done. Are you trying to handle link negotiation in software for phy chips that can't autoneg? Other minor notes:- - Rename register_mdiobus() -- mdiobus_register()? - I personally try to avoid listing parameter names in function header comment blocks; they seldom contain useful info and they're a maintenance overhead. If it would be useful for docbook-generated documentation then ok, but your comment blocks don't follow that format anyway. I hope this was useful. /james Andy Fleming wrote: On Mar 10, 2005, at 17:01, James Chapman wrote: Hi Andy, Can you elaborate on why this phy abstraction is needed? In your original post, you mentioned that you were going to post a patch to show how your code would be hooked up in an existing net driver. Did I miss it? It would help in understanding the pros and cons of using genphy over using plain old mii.c. Hi James, I haven't posted it yet, since it's a large patch (it deletes a lot of code from my driver), but I can give a basic overview of how my driver hooks into this code: 1) The driver connects to the PHY when opened, calling phy_connect, and then clears some bits to declare functionality it doesn't support (my driver, for instance, does not support gigabit in half-duplex mode). 2) The driver implements a function which reads the speed/duplex settings, and modifies the controller registers as appropriate (also bringing the carrier up and down depending on link state). My driver needs to note whether it's gigabit or not (for GMII vs MII mode), and the duplex (to set the MAC full or half). Both of those steps are very straightforward. The PHY layer will invoke the callback whenever the link state changes, so the controller will always be up-to-date. 3) The third step is the part
[PATCH 3/3] PPC440EP IBM EMAC support
On Tue, Mar 15, 2005 at 11:58:54AM -0700, Wade Farnsworth wrote: This patch adds support to the IBM EMAC ethernet driver for the 440EP. Regards, Wade Farnsworth Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com --- linux-2.6.11-bk7/drivers/net/ibm_emac/ibm_emac_phy.c 2005-03-02 00:38:13.0 -0700 +++ linux-2.6.11-bk7-440ep/drivers/net/ibm_emac/ibm_emac_phy.c 2005-03-11 16:32:01.0 -0700 @@ -27,6 +27,12 @@ #include ibm_emac_phy.h +#ifdef CONFIG_BAMBOO +#define BAMBOO_REV0 (mfspr(PVR) == PVR_440EP_RA) +#else +#define BAMBOO_REV0 0 +#endif + I really don't like it. Chip revision doesn't imply which board this code is running on. Please, think of some other way to do this or drop this completely. -- Eugene
[patch] mpc8560ads mtd map
Mark A. Greer wrote: Greg Weeks wrote: Add an MTD map for the flash on the mpc8560ads board. Signed-off-by: Greg Weeks greg.weeks at timesys.com snip Most of the code in this patch can be eliminated if you set up the table in your platform file and use the proper CONFIG_MTD_xxx options. Mark Yep, I pulled this off our 2.6.4 kernel tree. I think it should be in the platform code, but I've not tried moving it yet. That should get rid of the map file and the Kconfig changes to support it. Greg Weeks
[PATCH 3/3] PPC440EP IBM EMAC support
On Tue, Mar 15, 2005 at 11:22:16AM -0800, Eugene Surovegin wrote: On Tue, Mar 15, 2005 at 11:58:54AM -0700, Wade Farnsworth wrote: This patch adds support to the IBM EMAC ethernet driver for the 440EP. Regards, Wade Farnsworth Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com --- linux-2.6.11-bk7/drivers/net/ibm_emac/ibm_emac_phy.c2005-03-02 00:38:13.0 -0700 +++ linux-2.6.11-bk7-440ep/drivers/net/ibm_emac/ibm_emac_phy.c 2005-03-11 16:32:01.0 -0700 @@ -27,6 +27,12 @@ #include ibm_emac_phy.h +#ifdef CONFIG_BAMBOO +#define BAMBOO_REV0 (mfspr(PVR) == PVR_440EP_RA) +#else +#define BAMBOO_REV0 0 +#endif + I really don't like it. Chip revision doesn't imply which board this code is running on. Please, think of some other way to do this or drop this completely. Or to phrase this differently, it's better to avoid any board specific code/defines in network driver. -- Eugene
440EP FPU patch
This patch (against vanilla 2.4.11.3) breaks out the FPU code for PowerPC into a common .S code for all the head*.S files. Less cargo-culted code. Wade, you may want to integrate this into your 440EP patch. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpu-ppc-fpu.patch Type: text/x-patch Size: 19624 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/8300a5d6/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/8300a5d6/attachment.pgp
[PATCH 2.6.11] ppc32: update Radstone ppc7d platform for enet/i2c
-- next part -- An embedded and charset-unspecified text was scrubbed... Name: ppc7d-platdata.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/9dd92948/attachment.txt
[patch] mpc8560ads mtd platform
Add an MTD partitions in the platform code for the mpc8560ads board. Signed-off-by: Greg Weeks greg.weeks at timesys.com -- next part -- A non-text attachment was scrubbed... Name: mpc8560ads.mtd.paltform.patch Type: text/x-patch Size: 4168 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/6f458064/attachment.bin
mtd maps
On Tue, Mar 15, 2005 at 11:44:00AM -0700, Mark A. Greer wrote: Greg Weeks wrote: Are mtd maps still in drivers/mtd/maps or has that all moved to the platform code? I have an mtd map for the mpc8560ads but it's in mtd/maps. The mtd code has changed so that platform code can get at the routines to set up the maps from there. arch/ppc/platforms/katana.c has its mtd maps there and I recently posted a patch that moves it for the chestnut as well. I think its a good idea to move them to the platform code since the mtd maps are platform specific anyway. Plus its one less place to add/edit a file. But that's just my $0.02... But keep in mind that this currently only applies in the case where you need to map chips of the same type. Some boards have multiple chip types and physmap doesn't yet support that. -Matt
[PATCH 3/3] PPC440EP IBM EMAC support
On Tue, Mar 15, 2005 at 11:22:16AM -0800, Eugene Surovegin wrote: On Tue, Mar 15, 2005 at 11:58:54AM -0700, Wade Farnsworth wrote: This patch adds support to the IBM EMAC ethernet driver for the 440EP. Regards, Wade Farnsworth Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com --- linux-2.6.11-bk7/drivers/net/ibm_emac/ibm_emac_phy.c2005-03-02 00:38:13.0 -0700 +++ linux-2.6.11-bk7-440ep/drivers/net/ibm_emac/ibm_emac_phy.c 2005-03-11 16:32:01.0 -0700 @@ -27,6 +27,12 @@ #include ibm_emac_phy.h +#ifdef CONFIG_BAMBOO +#define BAMBOO_REV0 (mfspr(PVR) == PVR_440EP_RA) +#else +#define BAMBOO_REV0 0 +#endif + I really don't like it. Chip revision doesn't imply which board this code is running on. Please, think of some other way to do this or drop this completely. Wade and I talked about this one before and there is no direct way to detect the board revision on this platform. Given that, I think that if the PVR of the 440EP in a Bamboo board does imply the board revision, then this is appropriate. -Matt
[PATCH 3/3] PPC440EP IBM EMAC support
On Tue, Mar 15, 2005 at 11:24:24AM -0800, Eugene Surovegin wrote: On Tue, Mar 15, 2005 at 11:22:16AM -0800, Eugene Surovegin wrote: On Tue, Mar 15, 2005 at 11:58:54AM -0700, Wade Farnsworth wrote: This patch adds support to the IBM EMAC ethernet driver for the 440EP. Regards, Wade Farnsworth Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com --- linux-2.6.11-bk7/drivers/net/ibm_emac/ibm_emac_phy.c 2005-03-02 00:38:13.0 -0700 +++ linux-2.6.11-bk7-440ep/drivers/net/ibm_emac/ibm_emac_phy.c 2005-03-11 16:32:01.0 -0700 @@ -27,6 +27,12 @@ #include ibm_emac_phy.h +#ifdef CONFIG_BAMBOO +#define BAMBOO_REV0 (mfspr(PVR) == PVR_440EP_RA) +#else +#define BAMBOO_REV0 0 +#endif + I really don't like it. Chip revision doesn't imply which board this code is running on. Please, think of some other way to do this or drop this completely. Or to phrase this differently, it's better to avoid any board specific code/defines in network driver. Indeed it's better. However, I made the suggestion that it's not worth the effort to add in another hook to provide board specific phy help to ibm_emac/ at this time. I think the hack can exist until a proper hook can be added to the phy lib stuff that should be used in the future. If you think that's too far off, we can go ahead and add another hook so the hack can be moved into bamboo.c where it ideally belongs. -Matt
440EP FPU patch
On Tue, Mar 15, 2005 at 02:27:57PM -0500, McMullan, Jason wrote: This patch (against vanilla 2.4.11.3) breaks out the FPU code for PowerPC into a common .S code for all the head*.S files. Less cargo-culted code. Wade, you may want to integrate this into your 440EP patch. Hi Jason, Can you change CONFIG_FPU-CONFIG_PPC_FPU? Otherwise, this looks like exactly what we need to me. -Matt
[PATCH 1/3] PPC440EP SoC and Bamboo board support
I think your setup for BAMBOO_PCIL0_PTM1MS is actually incorrect. According to the AMCC 440EP docs, BAMBOO_PCIL0_PTM1MS is a mask, so the correct code should look more like: memory_size = 0x - (memory_size - 1); PCI_WRITEL(memory_size | 1, BAMBOO_PCIL0_PTM1MS); (assuming 'memory_size' is a power of 2) -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/df535600/attachment.pgp
440EP FPU patch
Jason, A few comments: 1. Change config option to CONFIG_PPC_FPU 2. split out altivec support into a separate file, most likely just move it into vector.S 3. Get ride of the C++ comments - kumar On Mar 15, 2005, at 1:27 PM, McMullan, Jason wrote: ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded Date: March 15, 2005 1:43:37 PM CST Subject: Date: March 15, 2005 1:43:37 PM CST Subject: ATT110571.txtcpu-ppc-fpu.patch signature.asc
[PATCH 1/3] PPC440EP SoC and Bamboo board support
On Tue, 2005-03-15 at 13:58, Jason McMullan wrote: I think your setup for BAMBOO_PCIL0_PTM1MS is actually incorrect. According to the AMCC 440EP docs, BAMBOO_PCIL0_PTM1MS is a mask, so the correct code should look more like: memory_size = 0x - (memory_size - 1); PCI_WRITEL(memory_size | 1, BAMBOO_PCIL0_PTM1MS); (assuming 'memory_size' is a power of 2) Jason, I think you're right. Your way is much more concise too. Thanks, Wade Farnsworth
440EP FPU patch
On Tue, 2005-03-15 at 15:09 -0600, Kumar Gala wrote: 1. Change config option to CONFIG_PPC_FPU 2. split out altivec support into a separate file, most likely just move it into vector.S 3. Get ride of the C++ comments Changes made, as per your suggestions, and new patch attached. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpu-ppc-fpu.patch Type: text/x-patch Size: 19842 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/b1694b75/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/b1694b75/attachment.pgp
[PATCH 2.6.12] ppc32: Patch for changed dev-bus_id format
ppc32: Patch for changed dev-bus_id format + some misc fixups - Recent changes to drivers/base/platform.c:platform_device_register() changed the format of dev-bus_id (there is now a '.' between the name instance (e.g., the old mpsc0 is now mpsc.0)). This field is used by some platform's platform_notify() routine to identify the dev entry. This patch updates the bus_id value compared to include the dot. - Fix an bad macro name change by a previous patch. - Some coding style fixups, etc. Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: bus_id_fixups.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/737687d0/attachment.txt
[PATCH 2.6.11] ppc32: update Radstone ppc7d platform
ppc32: Radstone PPC7D platform update - Recent mv643xx #define name changes broke the PPC7D platform compile. Fixed by this patch. - Change default platform config to add mv643xx_eth and mv64xxx-i2c config options. - Add i2c platform data and update to cope with recent platform device name change. Signed-off-by: James Chapman jchapman at katalix.com Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ppc7d-2.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/7f7ab745/attachment.txt
[PATCH 2.6.12] ppc32: Clean up mv64x60 bootwrapper support
ppc32: Clean up mv64x60 bootwrapper support This patch removes the call to mv64x60_init() in arch/ppc/boot/simple/head.S and now uses the 'load_kernel()' hook to call to have mv64x60-specific code called. This means that the mv64x60 code will be called after the bootwrapper has relocated itself. The platforms affected by this change are updated by this patch as well. Depends on patch: http://ozlabs.org/pipermail/linuxppc-embedded/2005-March/017269.html Please apply. Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ppc32_bootwrapper.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/251bdcc1/attachment.txt
mtd maps
On Tue, 2005-03-15 at 13:32 -0700, Matt Porter wrote: On Tue, Mar 15, 2005 at 11:44:00AM -0700, Mark A. Greer wrote: Greg Weeks wrote: Are mtd maps still in drivers/mtd/maps or has that all moved to the platform code? I have an mtd map for the mpc8560ads but it's in mtd/maps. The mtd code has changed so that platform code can get at the routines to set up the maps from there. arch/ppc/platforms/katana.c has its mtd maps there and I recently posted a patch that moves it for the chestnut as well. I think its a good idea to move them to the platform code since the mtd maps are platform specific anyway. Plus its one less place to add/edit a file. But that's just my $0.02... But keep in mind that this currently only applies in the case where you need to map chips of the same type. Some boards have multiple chip types and physmap doesn't yet support that. There is a driver in MTD CVS now called mphysmap (untested I believe), that might be able to deal with that. Eventually. josh
[PATCH 1/3] PPC440EP SoC and Bamboo board support
On Tue, 2005-03-15 at 10:17 -0700, Wade Farnsworth wrote: Hello all, This adds support for the IBM/AMCC PPC440EP SoC and the Bamboo reference board. Any comments would be appreciated. Isn't the NAND chip on that board a 64MiB chip? If so, the BAMBOO_NAND_FLASH_SIZE define is wrong. It should be 0x400. Also, are there any plans to add MTD support for the NAND controller found on those boards? thx, josh
[PATCH 2.6.11] ppc32: update Radstone ppc7d platform
Mark A. Greer mgreer at mvista.com wrote:
+ppc7d_fixup_i2c_pdata(struct platform_device *pdev)
+{
+struct mv64xxx_i2c_pdata *pdata;
+int i;
+
+pdata = pdev-dev.platform_data;
+if (pdata == NULL) {
+pdata = kmalloc(GFP_KERNEL, sizeof(*pdata));
I'll switch those kmalloc args around for you.
