* Re: patches for 2.6.25
From: Jochen Friedrich @ 2008-01-21 17:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801211041100.14676@blarg.am.freescale.net>
Hi Kumar,
> I'm sure I missed some patches for 2.6.25, so please point any out that
> people would like to see get in.
What about this one, now that the fixed phy parts are in:
http://patchwork.ozlabs.org/linuxppc/patch?person=1023&id=15654
Thanks,
Jochen
^ permalink raw reply
* Re: Warp Watchdog
From: Sean MacLennan @ 2008-01-21 17:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080121080157.0b66c7fc@zod.rchland.ibm.com>
Josh Boyer wrote:
> I'm not thrilled with it being in the platform file itself. It should
> really go into drivers/watchdog. It's OK that the watchdog is tied to
> Warp, that really isn't an issue. Just make it depend on Warp in the
> Kconfig file. And you can select it in your board config so that it's
> built in-kernel and not as a module.
>
> The code itself looks pretty clean.
>
Thanks for the feedback. I think I was trying to convince myself that
the platform was a good place but honestly felt it should be in the
drivers/watchdog. So I moved it there.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 1/5] Warp Base Platform
From: Sean MacLennan @ 2008-01-21 17:55 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <478E9369.5090605@pikatech.com>
I finally got around to cleaning up the board driver, so the fpga init
function is now moved to the right place. The pika_dtm_start now asks
for the resources itself. This hopefully is the last patch to these
files for a while.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x && !CPM2 && !8xx && !PPC_83xx \
&& !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool "PIKA Warp"
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
+ Telephony Developers" link for more information.
+
#config LUAN
# bool "Luan"
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..0864d4f 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,5 @@ obj-$(CONFIG_BAMBOO) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
+obj-$(CONFIG_WARP) += warp-nand.o
diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
new file mode 100644
index 0000000..84ab78f
--- /dev/null
+++ b/arch/powerpc/platforms/44x/warp-nand.c
@@ -0,0 +1,105 @@
+/*
+ * PIKA Warp(tm) NAND flash specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ */
+
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/ndfc.h>
+
+#ifdef CONFIG_MTD_NAND_NDFC
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD0000000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+ .name = "kernel",
+ .offset = 0,
+ .size = 0x0200000
+ },
+ {
+ .name = "root",
+ .offset = 0x0200000,
+ .size = 0x3400000
+ },
+ {
+ .name = "user",
+ .offset = 0x3600000,
+ .size = 0x0A00000
+ },
+};
+
+struct ndfc_controller_settings warp_ndfc_settings = {
+ .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
+ .ndfc_erpn = 0,
+};
+
+static struct ndfc_chip_settings warp_chip0_settings = {
+ .bank_settings = 0x80002222,
+};
+
+struct platform_nand_ctrl warp_nand_ctrl = {
+ .priv = &warp_ndfc_settings,
+};
+
+static struct platform_device warp_ndfc_device = {
+ .name = "ndfc-nand",
+ .id = 0,
+ .dev = {
+ .platform_data = &warp_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+};
+
+static struct nand_ecclayout nand_oob_16 = {
+ .eccbytes = 3,
+ .eccpos = { 0, 1, 2, 3, 6, 7 },
+ .oobfree = { {.offset = 8, .length = 16} }
+};
+
+static struct platform_nand_chip warp_nand_chip0 = {
+ .nr_chips = 1,
+ .chip_offset = CS_NAND_0,
+ .nr_partitions = ARRAY_SIZE(nand_parts),
+ .partitions = nand_parts,
+ .chip_delay = 50,
+ .ecclayout = &nand_oob_16,
+ .priv = &warp_chip0_settings,
+};
+
+static struct platform_device warp_nand_device = {
+ .name = "ndfc-chip",
+ .id = 0,
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+ .dev = {
+ .platform_data = &warp_nand_chip0,
+ .parent = &warp_ndfc_device.dev,
+ }
+};
+
+static int warp_setup_nand_flash(void)
+{
+ platform_device_register(&warp_ndfc_device);
+ platform_device_register(&warp_nand_device);
+
+ return 0;
+}
+device_initcall(warp_setup_nand_flash);
+
+#endif
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
new file mode 100644
index 0000000..8f01563
--- /dev/null
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -0,0 +1,153 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
+ * 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/of_platform.h>
+#include <linux/kthread.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+
+#include "44x.h"
+
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "pika,warp");
+}
+
+define_machine(warp) {
+ .name = "Warp",
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+
+#define LED_GREEN (0x80000000 >> 0)
+#define LED_RED (0x80000000 >> 1)
+
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void __iomem *gpio_base = NULL;
+ unsigned leds;
+
+ if (gpio_base == NULL) {
+ struct device_node *np;
+
+ /* Power LEDS are on the second GPIO controller */
+ np = of_find_compatible_node(NULL, NULL, "ibm,gpio-440EP");
+ if (np)
+ np = of_find_compatible_node(np, NULL, "ibm,gpio-440EP");
+ if (np == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find gpio\n");
+ return;
+ }
+
+ gpio_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (gpio_base == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map gpio");
+ return;
+ }
+ }
+
+ leds = in_be32(gpio_base);
+
+ switch (green) {
+ case 0: leds &= ~LED_GREEN; break;
+ case 1: leds |= LED_GREEN; break;
+ }
+ switch (red) {
+ case 0: leds &= ~LED_RED; break;
+ case 1: leds |= LED_RED; break;
+ }
+
+ out_be32(gpio_base, leds);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+#ifdef CONFIG_SENSORS_AD7414
+static int pika_dtm_thread(void __iomem *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while (!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ return 0;
+}
+
+static int __init pika_dtm_start(void)
+{
+ struct task_struct *dtm_thread;
+ struct device_node *np;
+ struct resource res;
+ void __iomem *fpga;
+
+ np = of_find_compatible_node(NULL, NULL, "pika,fpga");
+ if (np == NULL)
+ return -ENOENT;
+
+ /* We do not call of_iomap here since it would map in the entire
+ * fpga space, which is over 8k.
+ */
+ if (of_address_to_resource(np, 0, &res)) {
+ of_node_put(np);
+ return -ENOENT;
+ }
+ of_node_put(np);
+
+ fpga = ioremap(res.start + 0x20, 4);
+ if (fpga == NULL)
+ return -ENOENT;
+
+ dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
+ if (IS_ERR(dtm_thread)) {
+ iounmap(fpga);
+ return PTR_ERR(dtm_thread);
+ }
+
+ return 0;
+}
+device_initcall(pika_dtm_start);
+#endif
^ permalink raw reply related
* RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Koss, Mike (Mission Systems) @ 2008-01-21 17:44 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, David Baird, linuxppc-embedded
In-Reply-To: <BAY115-W344A18C61627B3075C6281B23D0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
In case anyone is interested, I'm currently working on an
almost-kernel-ready version that will be self-contained based on the
LL-DMA version (the native MPMC port, not the PLB). It's based upon the
old adapter from MontaVista, that I originally ported to 2.6 and the
MPMC2. Unfortunately, it won't be ready for another few weeks since I'm
working on hardware images currently.
-- Mike
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Monday, January 21, 2008 3:54 AM
To: David Baird; linuxppc-embedded@ozlabs.org
Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
thanks for you reply david,
As far as I know the Linux driver for Xilinx PLB TEMAC was two parts :
1- adapter.c and 2- the rest of the driver files
Only adapter.c was really a linux related file and the rest of the files
were Xilinx generic driver code for PLB TEMAC.
correct?
then now, I know EDK 9.2 generates the needed Linux support package and
needed related files, so if this is the case can we use these files as
the needed driver in our linux kernel?
by the way, i did never hear about this git repository before...can you
describe us, where is it and how we can access it and which projects are
now hosted by it?
thanks
> Date: Mon, 21 Jan 2008 00:54:30 -0700
> From: dhbaird@gmail.com
> To: mamsadegh@hotmail.com
> Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>
> On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<mamsadegh@hotmail.com> wrote:
> > As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC
in
> > Virtex-4 FX devices to PLB bus,
> > now, in the new release of EDK , EDK 9.2 Xilinx has added a new
interface
> > core , which is called XPS_LL_TEMAC and has a different structure
than
> > normal PLB TEMAC. spacially it has some additional data transfer
buses.
> >
> > Now the question is,... is there any linux driver available for this
new
> > core?
>
> Yes there is, but I had to use the git sources at:
>
> git.xilinx.com
________________________________
[-- Attachment #2: Type: text/html, Size: 3216 bytes --]
^ permalink raw reply
* [PATCH} PIKA FPGA WDT driver
From: Sean MacLennan @ 2008-01-21 18:03 UTC (permalink / raw)
To: linuxppc-dev
The PIKA FPGA has a watchdog. It is currently only used on the Warp
board, but it could be used on other future PIKA products. We tend to
try to reuse FPGA code as much as possible.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 52dff40..fc1b9fe 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -666,6 +666,14 @@ config BOOKE_WDT
Please see Documentation/watchdog/watchdog-api.txt for
more information.
+config PIKA_WDT
+ tristate "PIKA FPGA Watchdog"
+ depends on WARP
+ default y
+ help
+ This enables the watchdog in the PIKA FPGA. Currently used on
+ the Warp platform.
+
# PPC64 Architecture
config WATCHDOG_RTAS
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 87483cc..efa4731 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
+obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
# PPC64 Architecture
obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
diff --git a/drivers/watchdog/pika_wdt.c b/drivers/watchdog/pika_wdt.c
new file mode 100644
index 0000000..074756b
--- /dev/null
+++ b/drivers/watchdog/pika_wdt.c
@@ -0,0 +1,124 @@
+/*
+ * PIKA FPGA based Watchdog Timer
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ */
+
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/reboot.h>
+#include <linux/uaccess.h>
+#include <linux/io.h>
+#include <linux/of_platform.h>
+#include <linux/watchdog.h>
+
+
+static void __iomem *pikawdt_fpga;
+
+
+static inline void pikawdt_ping(void)
+{ /* Any write will do */
+ unsigned reset = in_be32(pikawdt_fpga);
+ out_be32(pikawdt_fpga, reset);
+}
+
+static int pikawdt_open(struct inode *inode, struct file *file)
+{
+ unsigned reset;
+
+ /* Enable the watchdog. Note this is an implicit ping. */
+ reset = in_be32(pikawdt_fpga);
+ reset |= 0xf80; /* enable with max timeout - 15 seconds */
+ out_be32(pikawdt_fpga, reset);
+
+ return 0;
+}
+
+static int pikawdt_release(struct inode *inode, struct file *file)
+{
+ pikawdt_ping(); /* one last time */
+ return 0;
+}
+
+static ssize_t pikawdt_write(struct file *file, const char __user *buf, size_t count,
+ loff_t *ppos)
+{
+ pikawdt_ping();
+ return count;
+}
+
+/* We support the bare minimum to be conformant. */
+static int pikawdt_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ if (cmd == WDIOC_KEEPALIVE) {
+ pikawdt_ping();
+ return 0;
+ } else
+ return -EINVAL;
+}
+
+static const struct file_operations pikawdt_fops = {
+ .owner = THIS_MODULE,
+ .open = pikawdt_open,
+ .release = pikawdt_release,
+ .write = pikawdt_write,
+ .ioctl = pikawdt_ioctl,
+};
+
+static struct miscdevice pikawdt_miscdev = {
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &pikawdt_fops,
+};
+
+static int __init pikawdt_init(void)
+{
+ struct device_node *np;
+ struct resource res;
+ int ret;
+
+ if ((np = of_find_compatible_node(NULL, NULL, "pika,fpga")) == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find fpga\n");
+ return -ENOENT;
+ }
+
+ /* We do not call of_iomap here since it would map in the entire
+ * fpga space, which is over 8k.
+ */
+ ret = of_address_to_resource(np, 0, &res);
+ of_node_put(np);
+
+ if (ret) {
+ printk(KERN_ERR __FILE__ ": Unable to get FPGA address\n");
+ return ret;
+ }
+
+ pikawdt_fpga = ioremap(res.start + 0x14, 4);
+ if (pikawdt_fpga == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map FPGA\n");
+ return -ENOENT;
+ }
+
+ ret = misc_register(&pikawdt_miscdev);
+ if (ret) {
+ iounmap(pikawdt_fpga);
+ printk(KERN_ERR "pikawdt: cannot register miscdev on minor=%d (err=%d)\n",
+ WATCHDOG_MINOR, ret);
+ return ret;
+ }
+
+ return 0;
+}
+module_init(pikawdt_init);
+
+
+static void __exit pikawdt_exit(void)
+{
+ misc_deregister(&pikawdt_miscdev);
+
+ iounmap(pikawdt_fpga);
+}
+module_exit(pikawdt_exit);
^ permalink raw reply related
* Re: patches for 2.6.25
From: Scott Wood @ 2008-01-21 18:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801211041100.14676@blarg.am.freescale.net>
On Mon, Jan 21, 2008 at 10:43:11AM -0600, Kumar Gala wrote:
> I'm sure I missed some patches for 2.6.25, so please point any out that
> people would like to see get in.
How about Jochen Friedrich's 8xx cleanup patches that were posted
recently?
-Scott
^ permalink raw reply
* Early driver development resources
From: Benedict, Michael @ 2008-01-21 18:20 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I wrote a driver for a 4 segment digital display device. I have
a requirement that this device be used as early as possible to report
kernel bootup state. The driver itself is pretty simple, just using
in/out_be32() and udelay(). The problem is that I don't know how to use
hardware resources in the early stages of booting, before I can call
request_mem_region() and friends.
Can anyone recommend a book / documentation / reference code /
anything that demonstrates this, or at least could improve my
understanding enough to accomplish this?
Many thanks,
Michael
^ permalink raw reply
* RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Stephen Neuendorffer @ 2008-01-21 18:42 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, David Baird, linuxppc-embedded
In-Reply-To: <BAY115-W344A18C61627B3075C6281B23D0@phx.gbl>
Basically, git.xilinx.com has a tree with most of the xilinx-related
support already integrated and ported forward to a current kernel. It
also includes ongoing work to unify microblaze and powerpc device
drivers through flat device trees.
See:
http://www.mail-archive.com/linuxppc-embedded@ozlabs.org/msg28690.html
To use the git.xilinx.com tree you should *not* generate the driver code
directly into the Linux tree. Instead, you should generate the driver
code in a dummy directory and copy
arch/ppc/platforms/4xx/xparameters_ml*.h into the kernel tree.
The BSP generation process is designed older 2.6.10-era kernels and will
not work with recent kernels. =20
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Mohammad
Sadegh Sadri
> Sent: Monday, January 21, 2008 12:54 AM
> To: David Baird; linuxppc-embedded@ozlabs.org
> Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>=20
> thanks for you reply david,
>=20
> As far as I know the Linux driver for Xilinx PLB TEMAC was two parts :
1- adapter.c and 2- the rest
> of the driver files
>=20
> Only adapter.c was really a linux related file and the rest of the
files were Xilinx generic driver
> code for PLB TEMAC.
>=20
> correct?
>=20
> then now, I know EDK 9.2 generates the needed Linux support package
and needed related files, so if
> this is the case can we use these files as the needed driver in our
linux kernel?
>=20
> by the way, i did never hear about this git repository before...can
you describe us, where is it and
> how we can access it and which projects are now hosted by it?
>=20
>=20
> thanks
>=20
>=20
> > Date: Mon, 21 Jan 2008 00:54:30 -0700
> > From: dhbaird@gmail.com
> > To: mamsadegh@hotmail.com
> > Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
> >
> > On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<mamsadegh@hotmail.com> wrote:
> > > As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC
in
> > > Virtex-4 FX devices to PLB bus,
> > > now, in the new release of EDK , EDK 9.2 Xilinx has added a new
interface
> > > core , which is called XPS_LL_TEMAC and has a different structure
than
> > > normal PLB TEMAC. spacially it has some additional data transfer
buses.
> > >
> > > Now the question is,... is there any linux driver available for
this new
> > > core?
> >
> > Yes there is, but I had to use the git sources at:
> >
> > git.xilinx.com
>=20
>=20
> ________________________________
^ permalink raw reply
* Re: [PATCH] autodetect serial console on efika
From: Grant Likely @ 2008-01-21 18:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20080121152900.GA8664@aepfle.de>
On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
>
> Efika boards have to be booted with console=ttyPSC0 unless there is a
> graphics card plugged in. Detect if the firmware stdout is the serial
> connector.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
Hrrrum; I think this is a good idea, but I'm not thrilled with the
approach. Here are my concerns:
- Determining that linux,stdout-path points to a PSC should should be
done in common code. It's useful for all 5200 boards, not just the
Efika. (However, if 'failsafe' processing is efika specific, then it
can stay in efika.c). This might be best done within the PSC driver
itself, but I'm not sure.
- Recognizing a psc node should be done by inspecting the compatible
property, not by device_type and model properties.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Generated xilinx linux 2.6 image sections
From: Stephen Neuendorffer @ 2008-01-21 18:45 UTC (permalink / raw)
To: greenlean, linuxppc-embedded
In-Reply-To: <14997109.post@talk.nabble.com>
The testapps are generated using a different linker script.
Based on what you sent out, it looks like your EDK design has a memory
at 0x10000000, but this is
not reflected in the linux image you've generated. This makes me
suspect that you haven't generated the BSP and copied the appropriate
xparameters file over xparameters_xup.h (assuming you are using
CONFIG_XILINX_XUPV2P).
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of greenlean
> Sent: Monday, January 21, 2008 5:06 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Generated xilinx linux 2.6 image sections
>=20
>=20
> Hi all,
>=20
> I'm trying to boot the 2.6 xilinx kernel downloaded from their git
server in
> the XUPV2P board I'm really having troubles (I can't see anything in
the
> minicom console terminal). I'm not seeing anything, neither the
ucompressing
> kernel string nor the prompt with the memory addresses that kernel
prompt at
> first time, so I have started to distrust of anything.
>=20
> When I download the kernel using xmd, I see:
>=20
> XMD% dow imagen_UART16550_ml300.elf
> section, .text: 0x00400000-0x0040387b
> section, .data: 0x00404000-0x004e6fff
> section, .bss: 0x004e7000-0x004e919f
> Downloaded Program imagen_UART16550_ml300.elf
> Setting PC with Program Start Address 0x00400000
>=20
> and when I download some of the TestApp generated by EDK I see:
>=20
> XMD% dow perif.elf
> section, .vectors: 0xfffe0000-0xfffe20c3
> section, .text: 0x10000000-0x10003b7b
> section, .init: 0x10003b7c-0x10003b9f
> section, .fini: 0x10003ba0-0x10003bbf
> section, .boot0: 0xfffe20c4-0xfffe20d3
> section, .boot: 0xfffffffc-0xffffffff
> section, .rodata: 0x10003bc0-0x10004111
> section, .sdata2: 0x10004114-0x10004113
> section, .sbss2: 0x10004114-0x10004113
> section, .data: 0x10004114-0x10004243
> section, .got: 0x10004244-0x10004243
> section, .got1: 0x10004244-0x10004243
> section, .got2: 0x10004244-0x1000425f
> section, .ctors: 0x10004260-0x10004267
> section, .dtors: 0x10004268-0x1000426f
> section, .fixup: 0x10004270-0x1000426f
> section, .eh_frame: 0x10004270-0x10004277
> section, .jcr: 0x10004278-0x1000427b
> section, .gcc_except_table: 0x1000427c-0x100042
> section, .sdata: 0x1000427c-0x10004293
> section, .sbss: 0x10004294-0x100042a3
> section, .bss: 0x100042a4-0x10004473
> section, .stack: 0x10004474-0x1000647f
> section, .heap: 0x10006480-0x1000847f
> Downloaded Program perif.elf
> Setting PC with Program Start Address 0xfffffffc
>=20
> Does anybody know why the kernel elf don't have a boot section like
the
> TestApp generated by EDK?
>=20
> I suppossed this is because the image kernel is compressed, but
despite
> beeing compressed it should have a boot section or something similar
???
> It's right that the kernel start address is set to the 0x00400000??
>=20
> Or does the section .text contains all the kernel code to uncompresse
the
> code of the kernel??
>=20
>=20
>=20
> --
> View this message in context:
http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-
> tp14997109p14997109.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Patches added to master/for-2.6.25 branch of powerpc.git
From: Grant Likely @ 2008-01-21 18:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801172153v69d948e5hf01d963410123f38@mail.gmail.com>
On 1/17/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/17/08, Paul Mackerras <paulus@samba.org> wrote:
> > Grant Likely writes:
> >
> > > Paul, can you also please pull the following 52xx changes?
> >
> > Could you please re-do your tree and make sure the headline for each
> > commit starts with "[POWERPC]" (unless it isn't powerpc-specific, in
> > which case it probably shouldn't be in your tree...).
>
> Oops, I thought I had done that. Sorry, I'll get that respun ASAP.
Here you go; respun the 52xx patches as you requested. Please pull.
Also, can you please merge your 2.6.25 branch with Linus' top of tree?
There are some more patches which I'm withholding until then because
they'll cause nasty merge conflicts otherwise.
Thanks,
g.
The following changes since commit 52920df4aa9dd25836b8ed4dc0b177ea14c09e53:
Paul Mackerras (1):
Merge branch 'for-2.6.25' of
master.kernel.org:/.../olof/pasemi into for-2.6.25
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25
Grant Likely (2):
[POWERPC] mpc5200: eliminate mpc52xx_*_map_*() functions.
[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
John Rigby (2):
[POWERPC] Separate MPC52xx PSC FIFO registers from rest of PSC
[POWERPC] mpc5200: Cleanup checkpatch.pl problems in mpc52xx_uart.c
Marian Balakowicz (6):
[POWERPC] mpc5200: Add 'fsl,lpb' bus type for localplus bus
[POWERPC] mpc5200: Add common mpc52xx_setup_pci() routine
[POWERPC] mpc5200: Add TQM5200 DTS
[POWERPC] mpc5200: add CM5200 DTS
[POWERPC] mpc5200: Add Promess Motion-PRO DTS
[POWERPC] mpc5200: Add generic support for simple MPC5200 based boards
arch/powerpc/boot/dts/cm5200.dts | 236 +++++
arch/powerpc/boot/dts/lite5200.dts | 2 +-
arch/powerpc/boot/dts/lite5200b.dts | 2 +-
arch/powerpc/boot/dts/motionpro.dts | 309 ++++++
arch/powerpc/boot/dts/tqm5200.dts | 184 ++++
arch/powerpc/configs/lite5200_defconfig | 847 -----------------
arch/powerpc/configs/mpc5200_defconfig | 1286 ++++++++++++++++++++++++++
arch/powerpc/platforms/52xx/Kconfig | 27 +-
arch/powerpc/platforms/52xx/Makefile | 1 +
arch/powerpc/platforms/52xx/lite5200.c | 22 +-
arch/powerpc/platforms/52xx/lite5200_pm.c | 6 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 85 ++
arch/powerpc/platforms/52xx/mpc52xx_common.c | 63 +-
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 14 +
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 8 +-
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 8 +-
drivers/serial/mpc52xx_uart.c | 210 +++--
drivers/spi/mpc52xx_psc_spi.c | 9 +-
include/asm-powerpc/mpc52xx.h | 7 +-
include/asm-powerpc/mpc52xx_psc.h | 3 +
include/asm-ppc/mpc52xx_psc.h | 3 +
21 files changed, 2317 insertions(+), 1015 deletions(-)
create mode 100644 arch/powerpc/boot/dts/cm5200.dts
create mode 100644 arch/powerpc/boot/dts/motionpro.dts
create mode 100644 arch/powerpc/boot/dts/tqm5200.dts
delete mode 100644 arch/powerpc/configs/lite5200_defconfig
create mode 100644 arch/powerpc/configs/mpc5200_defconfig
create mode 100644 arch/powerpc/platforms/52xx/mpc5200_simple.c
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 18:58 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20080121185806.13486.56429.stgit@trillian.secretlab.ca>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
11 files changed, 12 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c b/arch/powerpc/platforms/82xx/mpc8272_ads.c
index fd83440..3fce6b3 100644
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -165,14 +165,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(mpc8272_ads))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc8272_ads, declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/82xx/pq2fads.c b/arch/powerpc/platforms/82xx/pq2fads.c
index 1be5005..68196e3 100644
--- a/arch/powerpc/platforms/82xx/pq2fads.c
+++ b/arch/powerpc/platforms/82xx/pq2fads.c
@@ -176,14 +176,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(pq2fads))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(pq2fads, declare_of_platform_devices);
define_machine(pq2fads)
{
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 1e570bb..dbdd4ad 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -110,15 +110,12 @@ static struct of_device_id mpc832x_ids[] = {
static int __init mpc832x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc832x_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc832x_ids, NULL);
return 0;
}
-device_initcall(mpc832x_declare_of_platform_devices);
+machine_device_initcall(mpc832x_mds, mpc832x_declare_of_platform_devices);
static void __init mpc832x_sys_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index ffb2e93..1b57028 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -63,9 +63,6 @@ static struct spi_board_info mpc832x_spi_boardinfo = {
static int __init mpc832x_spi_init(void)
{
- if (!machine_is(mpc832x_rdb))
- return 0;
-
par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
@@ -79,8 +76,7 @@ static int __init mpc832x_spi_init(void)
mpc83xx_spi_activate_cs,
mpc83xx_spi_deactivate_cs);
}
-
-device_initcall(mpc832x_spi_init);
+machine_device_initcall(mpc832x_rdb, mpc832x_spi_init);
/* ************************************************************************
*
@@ -123,15 +119,12 @@ static struct of_device_id mpc832x_ids[] = {
static int __init mpc832x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc832x_rdb))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc832x_ids, NULL);
return 0;
}
-device_initcall(mpc832x_declare_of_platform_devices);
+machine_device_initcall(mpc832x_rdb, mpc832x_declare_of_platform_devices);
void __init mpc832x_rdb_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 459fb72..2b8a0a3 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -115,13 +115,10 @@ static struct of_device_id mpc834x_ids[] = {
static int __init mpc834x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc834x_mds))
- return 0;
-
of_platform_bus_probe(NULL, mpc834x_ids, NULL);
return 0;
}
-device_initcall(mpc834x_declare_of_platform_devices);
+machine_device_initcall(mpc834x_mds, mpc834x_declare_of_platform_devices);
/*
* Called very early, MMU is off, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 2ac9890..db491ec 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -141,15 +141,12 @@ static struct of_device_id mpc836x_ids[] = {
static int __init mpc836x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc836x_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc836x_ids, NULL);
return 0;
}
-device_initcall(mpc836x_declare_of_platform_devices);
+machine_device_initcall(mpc836x_mds, mpc836x_declare_of_platform_devices);
static void __init mpc836x_mds_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index 9cdc32b..cfd0548 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -50,15 +50,12 @@ static struct of_device_id mpc837x_ids[] = {
static int __init mpc837x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc837x_mds))
- return 0;
-
/* Publish of_device */
of_platform_bus_probe(NULL, mpc837x_ids, NULL);
return 0;
}
-device_initcall(mpc837x_declare_of_platform_devices);
+machine_device_initcall(mpc837x_mds, mpc837x_declare_of_platform_devices);
static void __init mpc837x_mds_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index bccdc25..a3fa1b0 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -233,13 +233,10 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(mpc85xx_ads))
- return 0;
-
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc85xx_ads, declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 4d063ee..8b1de78 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -222,9 +222,6 @@ static int mpc85xx_cds_8259_attach(void)
struct device_node *cascade_node = NULL;
int cascade_irq;
- if (!machine_is(mpc85xx_cds))
- return 0;
-
/* Initialize the i8259 controller */
for_each_node_by_type(np, "interrupt-controller")
if (of_device_is_compatible(np, "chrp,iic")) {
@@ -262,8 +259,7 @@ static int mpc85xx_cds_8259_attach(void)
return 0;
}
-
-device_initcall(mpc85xx_cds_8259_attach);
+machine_device_initcall(mpc85xx_cds, mpc85xx_cds_8259_attach);
#endif /* CONFIG_PPC_I8259 */
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index e6c63a5..9f4f3aa 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -144,15 +144,12 @@ static struct of_device_id mpc85xx_ids[] = {
static int __init mpc85xx_publish_devices(void)
{
- if (!machine_is(mpc85xx_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL,mpc85xx_ids,NULL);
return 0;
}
-device_initcall(mpc85xx_publish_devices);
+machine_device_initcall(mpc85xx_mds, mpc85xx_publish_devices);
static void __init mpc85xx_mds_pic_init(void)
{
diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/powerpc/platforms/embedded6xx/ls_uart.c
index c99264c..9d891bd 100644
--- a/arch/powerpc/platforms/embedded6xx/ls_uart.c
+++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c
@@ -117,9 +117,6 @@ static int __init ls_uarts_init(void)
phys_addr_t phys_addr;
int len;
- if (!machine_is(linkstation))
- return 0;
-
avr = of_find_node_by_path("/soc10x/serial@80004500");
if (!avr)
return -EINVAL;
@@ -142,4 +139,4 @@ static int __init ls_uarts_init(void)
return 0;
}
-late_initcall(ls_uarts_init);
+machine_late_initcall(linkstation, ls_uarts_init);
^ permalink raw reply related
* [PATCH 1/2] [POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 18:58 UTC (permalink / raw)
To: galak, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/8xx/ep88xc.c | 5 ++---
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 5 ++---
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 5 ++---
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/ep88xc.c b/arch/powerpc/platforms/8xx/ep88xc.c
index c518b6c..88afa35 100644
--- a/arch/powerpc/platforms/8xx/ep88xc.c
+++ b/arch/powerpc/platforms/8xx/ep88xc.c
@@ -155,12 +155,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
/* Publish the QE devices */
- if (machine_is(ep88xc))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(ep88xc, declare_of_platform_devices);
define_machine(ep88xc) {
.name = "Embedded Planet EP88xC",
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index d2927a4..d7965f8 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -128,12 +128,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (machine_is(mpc86x_ads))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc86x_ads, declare_of_platform_devices);
define_machine(mpc86x_ads) {
.name = "MPC86x ADS",
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 2cf1b6a..6ef8e9e 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -264,12 +264,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
/* Publish the QE devices */
- if (machine_is(mpc885_ads))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc885_ads, declare_of_platform_devices);
define_machine(mpc885_ads) {
.name = "Freescale MPC885 ADS",
^ permalink raw reply related
* fixed phy support (warning related to FIXED_MII_100_FDX)
From: Kumar Gala @ 2008-01-21 19:19 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev list
Anton,
it looks like the "TI AR7 CPMAC Ethernet support" uses FIXED_PHY and
was selecting FIXED_MII_100_FDX which is gone.
Can you look into this. I get the following warning now:
scripts/kconfig/conf -s arch/powerpc/Kconfig
drivers/net/Kconfig:1713:warning: 'select' used by config symbol
'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
- k
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Kumar Gala @ 2008-01-21 19:27 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080121185812.13486.68032.stgit@trillian.secretlab.ca>
On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
I believe I got the 83xx and 85xx already. look at my tree.
- k
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 19:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6FA7C7C0-172D-4AD4-BDAF-A1E3845A63FE@kernel.crashing.org>
On 1/21/08, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
>
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> > arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> > arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> > arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> > arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> > arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
>
> I believe I got the 83xx and 85xx already. look at my tree.
Okay, I can drop those and repost.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 19:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801211135r5cde9f6t9b6ee323a48bc44c@mail.gmail.com>
On 1/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/21/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
> >
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > ---
> > >
> > > arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> > > arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> > > arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> > > arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> > > arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> > > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> > > arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
> >
> > I believe I got the 83xx and 85xx already. look at my tree.
>
> Okay, I can drop those and repost.
Actually, that's too much work... I'll wait until paulus pulls your
tree, rebase and then repost.
/me is lazy.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Kumar Gala @ 2008-01-21 19:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801211136u7f25bc38u3ef99b5cc750d850@mail.gmail.com>
On Jan 21, 2008, at 1:36 PM, Grant Likely wrote:
> On 1/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On 1/21/08, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>
>>> On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
>>>
>>>> From: Grant Likely <grant.likely@secretlab.ca>
>>>>
>>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>>> ---
>>>>
>>>> arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
>>>> arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
>>>> arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
>>>> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
>>>> arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
>>>> arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
>>>> arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
>>>> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
>>>> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
>>>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
>>>> arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
>>>
>>> I believe I got the 83xx and 85xx already. look at my tree.
>>
>> Okay, I can drop those and repost.
>
> Actually, that's too much work... I'll wait until paulus pulls your
> tree, rebase and then repost.
that's fine.
- k
^ permalink raw reply
* Re: Early driver development resources
From: Frank Bennett @ 2008-01-21 19:25 UTC (permalink / raw)
To: Benedict, Michael; +Cc: linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2F01@twx-exch01.twacs.local>
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
Benedict, Michael wrote:
> Hello,
> I wrote a driver for a 4 segment digital display device. I have
> a requirement that this device be used as early as possible to report
> kernel bootup state. The driver itself is pretty simple, just using
> in/out_be32() and udelay(). The problem is that I don't know how to use
> hardware resources in the early stages of booting, before I can call
> request_mem_region() and friends.
> Can anyone recommend a book / documentation / reference code /
> anything that demonstrates this, or at least could improve my
> understanding enough to accomplish this?
>
u-boot for embedded (or OpenBios) documentation, source code.
Look for splash screen code although you will want to make
multiple calls for various boot states. In the ISA days and now
PCI there are cards that display a two hex-digit POST progress
code which is a single x86, 8bit output instruction to port 0x80.
This may still be supported in closed source BIOS distributions.
Not sure what they do now with PCIe since it will take more than
a single, simple processor instruction.
-Frank Bennett
> Many thanks,
> Michael
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
*/Frank Bennett
President/*
Mathegraphics,LLC
613 Bentley Pl
Fort Collins,CO 80526
970-229-9269 (hm) 970-402-9269 (cell)
www.mathegraphics.com <http://www.mathegraphics.com>
bennett78@lpbroadband.net <mailto:bennett78@lpbroadband.net>
"I think there's a world market for about five computers."
-- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943
[-- Attachment #2: Type: text/html, Size: 3106 bytes --]
^ permalink raw reply
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: David Brownell @ 2008-01-21 20:01 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20080121103434.397382000@sunsite.dk>
On Monday 21 January 2008, Peter Korsgaard wrote:
> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> USB controllers. This patch series implements a HCD driver and shows the
> work-in-progress status of a gadget driver.
>
> I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25.
>
> Changes since v3:
> - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
> - The dummy platform_device's created per serial engine are gone.
> - Gadget driver (WIP)
>
> Comments are very much appreciated.
How does this relate to the "v3" patches posted 8-Jan by Grant Likely?
Is that the "v3" you were referring to?
It's confusing to see two different people submit two sets of patches
for the same driver, without any evident coordination...
- Dave
^ permalink raw reply
* [PATCH] Convert pfc8563 i2c driver from old style to new style
From: Jon Smirl @ 2008-01-21 20:09 UTC (permalink / raw)
To: i2c, linuxppc-dev
Convert pfc8563 i2c driver from old style to new style.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/rtc/rtc-pcf8563.c | 107 +++++++++++----------------------------------
1 files changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index b3317fc..8eff549 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -25,10 +25,6 @@
* located at 0x51 will pass the validation routine due to
* the way the registers are implemented.
*/
-static const unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Module parameters */
-I2C_CLIENT_INSMOD;
#define PCF8563_REG_ST1 0x00 /* status */
#define PCF8563_REG_ST2 0x01
@@ -72,9 +68,6 @@ struct pcf8563 {
int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
-static int pcf8563_detach(struct i2c_client *client);
-
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -257,98 +250,52 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
.set_time = pcf8563_rtc_set_time,
};
-static int pcf8563_attach(struct i2c_adapter *adapter)
+static int pcf8563_remove(struct i2c_client *client)
{
- return i2c_probe(adapter, &addr_data, pcf8563_probe);
+ struct rtc_device *rtc = i2c_get_clientdata(client);
+
+ if (rtc)
+ rtc_device_unregister(rtc);
+
+ return 0;
}
+static struct i2c_device_id pcf8563_id[] = {
+ {"pcf8563", 0},
+ {"rtc8564", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, pcf8563_id);
+
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id *id);
+
static struct i2c_driver pcf8563_driver = {
.driver = {
- .name = "pcf8563",
+ .name = "rtc-pcf8563",
},
.id = I2C_DRIVERID_PCF8563,
- .attach_adapter = &pcf8563_attach,
- .detach_client = &pcf8563_detach,
+ .probe = &pcf8563_probe,
+ .remove = &pcf8563_remove,
+ .id_table = pcf8563_id,
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
- struct pcf8563 *pcf8563;
- struct i2c_client *client;
+ int result;
struct rtc_device *rtc;
- int err = 0;
-
- dev_dbg(&adapter->dev, "%s\n", __FUNCTION__);
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C)) {
- err = -ENODEV;
- goto exit;
- }
-
- if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
- err = -ENOMEM;
- goto exit;
- }
-
- client = &pcf8563->client;
- client->addr = address;
- client->driver = &pcf8563_driver;
- client->adapter = adapter;
-
- strlcpy(client->name, pcf8563_driver.driver.name, I2C_NAME_SIZE);
-
- /* Verify the chip is really an PCF8563 */
- if (kind < 0) {
- if (pcf8563_validate_client(client) < 0) {
- err = -ENODEV;
- goto exit_kfree;
- }
- }
-
- /* Inform the i2c layer */
- if ((err = i2c_attach_client(client)))
- goto exit_kfree;
-
- dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
+ result = pcf8563_validate_client(client);
+ if (result)
+ return result;
rtc = rtc_device_register(pcf8563_driver.driver.name, &client->dev,
&pcf8563_rtc_ops, THIS_MODULE);
-
- if (IS_ERR(rtc)) {
- err = PTR_ERR(rtc);
- goto exit_detach;
- }
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
i2c_set_clientdata(client, rtc);
return 0;
-
-exit_detach:
- i2c_detach_client(client);
-
-exit_kfree:
- kfree(pcf8563);
-
-exit:
- return err;
-}
-
-static int pcf8563_detach(struct i2c_client *client)
-{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
- int err;
- struct rtc_device *rtc = i2c_get_clientdata(client);
-
- if (rtc)
- rtc_device_unregister(rtc);
-
- if ((err = i2c_detach_client(client)))
- return err;
-
- kfree(pcf8563);
-
- return 0;
}
static int __init pcf8563_init(void)
^ permalink raw reply related
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Grant Likely @ 2008-01-21 20:14 UTC (permalink / raw)
To: David Brownell; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <200801211201.41142.david-b@pacbell.net>
On 1/21/08, David Brownell <david-b@pacbell.net> wrote:
> On Monday 21 January 2008, Peter Korsgaard wrote:
> > The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> > USB controllers. This patch series implements a HCD driver and shows the
> > work-in-progress status of a gadget driver.
> >
> > I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25.
> >
> > Changes since v3:
> > - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
> > - The dummy platform_device's created per serial engine are gone.
> > - Gadget driver (WIP)
> >
> > Comments are very much appreciated.
>
> How does this relate to the "v3" patches posted 8-Jan by Grant Likely?
> Is that the "v3" you were referring to?
My v1, v2 and v3 postings were based on Peter's work from about a year
ago. I picked up the driver because Peter didn't have any time to
work on it.
Peter told me last week that this series merges the v3 patches with
work that he's done recently now that he has some time to do so again.
However, I don't know what the diff is between v3 and this new
series. I've also not done a full review, so I cannot make any
comment at this time.
Personally, I'd prefer to see the v3 series picked up now (as I
believe all outstanding comments from the list have been addressed)
and have new patches build on top of that, but that's just my
preference.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Peter Korsgaard @ 2008-01-21 20:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, dbrownell, linux-usb
In-Reply-To: <fa686aa40801210911q4ce90816tebafa46e68a3f980@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
>> Changes since v3:
>> - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
>> - The dummy platform_device's created per serial engine are gone.
>> - Gadget driver (WIP)
Grant> Can you please post/publish the diff between v3 and this series?
Sure, http://peter.korsgaard.com/c67x00-v3-v4.patch (not posting as
it's more than 100k)
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] autodetect serial console on efika
From: Olaf Hering @ 2008-01-21 20:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <fa686aa40801211045w7644cfc5tf11024bd0010b308@mail.gmail.com>
On Mon, Jan 21, Grant Likely wrote:
> On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
> >
> > Efika boards have to be booted with console=ttyPSC0 unless there is a
> > graphics card plugged in. Detect if the firmware stdout is the serial
> > connector.
> >
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> Hrrrum; I think this is a good idea, but I'm not thrilled with the
> approach. Here are my concerns:
>
> - Determining that linux,stdout-path points to a PSC should should be
> done in common code. It's useful for all 5200 boards, not just the
> Efika. (However, if 'failsafe' processing is efika specific, then it
> can stay in efika.c). This might be best done within the PSC driver
> itself, but I'm not sure.
> - Recognizing a psc node should be done by inspecting the compatible
> property, not by device_type and model properties.
I dont have any other 5200 hardware to test a different patch.
Please improve my version and submit it for inclusion.
^ permalink raw reply
* Re: [PATCH] autodetect serial console on efika
From: Grant Likely @ 2008-01-21 20:38 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20080121203459.GA9967@aepfle.de>
On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jan 21, Grant Likely wrote:
>
> > On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
> > >
> > > Efika boards have to be booted with console=ttyPSC0 unless there is a
> > > graphics card plugged in. Detect if the firmware stdout is the serial
> > > connector.
> > >
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >
> > Hrrrum; I think this is a good idea, but I'm not thrilled with the
> > approach. Here are my concerns:
> >
> > - Determining that linux,stdout-path points to a PSC should should be
> > done in common code. It's useful for all 5200 boards, not just the
> > Efika. (However, if 'failsafe' processing is efika specific, then it
> > can stay in efika.c). This might be best done within the PSC driver
> > itself, but I'm not sure.
> > - Recognizing a psc node should be done by inspecting the compatible
> > property, not by device_type and model properties.
>
> I dont have any other 5200 hardware to test a different patch.
> Please improve my version and submit it for inclusion.
Heh; that's okay, I and others can test on other hardware; but it's
still appropriate for you to move the matching code into the PSC
driver proper. Otherwise, getting it in to mainline for 2.6.25
depends on how much time I get free in the next 2 weeks.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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