* [PATCH 1/3] powerpc: Add support for Wind River SBC8641D board
From: Paul Gortmaker @ 2008-04-10 23:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
In-Reply-To: <1207869739-19892-1-git-send-email-paul.gortmaker@windriver.com>
This adds support for the Wind River SBC8641D board, based
largely on the mpc86xx_hpcn support. The biggest difference is
the lack of the Uli and the i8259 cascade, which simplifies things.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/platforms/86xx/Kconfig | 8 ++-
arch/powerpc/platforms/86xx/Makefile | 1 +
arch/powerpc/platforms/86xx/sbc8641d.c | 171 ++++++++++++++++++++++++++++++++
3 files changed, 179 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/86xx/sbc8641d.c
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 21d1135..7442c58 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -11,6 +11,12 @@ config MPC8641_HPCN
help
This option enables support for the MPC8641 HPCN board.
+config SBC8641D
+ bool "Wind River SBC8641D"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the WRS SBC8641D board.
+
config MPC8610_HPCD
bool "Freescale MPC8610 HPCD"
select DEFAULT_UIMAGE
@@ -24,7 +30,7 @@ config MPC8641
select FSL_PCI if PCI
select PPC_UDBG_16550
select MPIC
- default y if MPC8641_HPCN
+ default y if MPC8641_HPCN || SBC8641D
config MPC8610
bool
diff --git a/arch/powerpc/platforms/86xx/Makefile b/arch/powerpc/platforms/86xx/Makefile
index c967063..1b9b4a9 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -4,4 +4,5 @@
obj-$(CONFIG_SMP) += mpc86xx_smp.o
obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
+obj-$(CONFIG_SBC8641D) += sbc8641d.o
obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
diff --git a/arch/powerpc/platforms/86xx/sbc8641d.c b/arch/powerpc/platforms/86xx/sbc8641d.c
new file mode 100644
index 0000000..c7516be
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/sbc8641d.c
@@ -0,0 +1,171 @@
+/*
+ * SBC8641D board specific routines
+ *
+ * Copyright 2008 Wind River Systems Inc.
+ *
+ * By Paul Gortmaker (see MAINTAINERS for contact information)
+ *
+ * Based largely on the 8641 HPCN support by Freescale Semiconductor 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/stddef.h>
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/kdev_t.h>
+#include <linux/delay.h>
+#include <linux/seq_file.h>
+#include <linux/of_platform.h>
+
+#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/machdep.h>
+#include <asm/pci-bridge.h>
+#include <asm/mpc86xx.h>
+#include <asm/prom.h>
+#include <mm/mmu_decl.h>
+#include <asm/udbg.h>
+
+#include <asm/mpic.h>
+
+#include <sysdev/fsl_pci.h>
+#include <sysdev/fsl_soc.h>
+
+#include "mpc86xx.h"
+
+#undef DEBUG
+
+#ifdef DEBUG
+#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
+#else
+#define DBG(fmt...) do { } while(0)
+#endif
+
+void __init
+sbc8641_init_irq(void)
+{
+ struct mpic *mpic1;
+ struct device_node *np;
+ struct resource res;
+
+ /* Determine PIC address. */
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (np == NULL)
+ return;
+ of_address_to_resource(np, 0, &res);
+
+ /* Alloc mpic structure and per isu has 16 INT entries. */
+ mpic1 = mpic_alloc(np, res.start,
+ MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
+ 0, 256, " MPIC ");
+ BUG_ON(mpic1 == NULL);
+
+ mpic_init(mpic1);
+}
+
+static void __init
+sbc8641_setup_arch(void)
+{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
+
+ if (ppc_md.progress)
+ ppc_md.progress("sbc8641_setup_arch()", 0);
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,mpc8641-pcie")
+ fsl_add_bridge(np, 0);
+#endif
+
+ printk("SBC8641 board from Wind River\n");
+
+#ifdef CONFIG_SMP
+ mpc86xx_smp_init();
+#endif
+}
+
+
+void
+sbc8641_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ uint memsize = total_memory;
+ const char *model = "";
+ uint svid = mfspr(SPRN_SVR);
+
+ seq_printf(m, "Vendor\t\t: Wind River Systems\n");
+
+ root = of_find_node_by_path("/");
+ if (root)
+ model = of_get_property(root, "model", NULL);
+ seq_printf(m, "Machine\t\t: %s\n", model);
+ of_node_put(root);
+
+ seq_printf(m, "SVR\t\t: 0x%x\n", svid);
+ seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
+}
+
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init sbc8641_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "mpc86xx"))
+ return 1; /* Looks good */
+
+ return 0;
+}
+
+long __init
+mpc86xx_time_init(void)
+{
+ unsigned int temp;
+
+ /* Set the time base to zero */
+ mtspr(SPRN_TBWL, 0);
+ mtspr(SPRN_TBWU, 0);
+
+ temp = mfspr(SPRN_HID0);
+ temp |= HID0_TBEN;
+ mtspr(SPRN_HID0, temp);
+ asm volatile("isync");
+
+ return 0;
+}
+
+static __initdata struct of_device_id of_bus_ids[] = {
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(sbc8641, declare_of_platform_devices);
+
+define_machine(sbc8641) {
+ .name = "SBC8641D",
+ .probe = sbc8641_probe,
+ .setup_arch = sbc8641_setup_arch,
+ .init_IRQ = sbc8641_init_irq,
+ .show_cpuinfo = sbc8641_show_cpuinfo,
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .time_init = mpc86xx_time_init,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+};
--
1.5.4.3
^ permalink raw reply related
* [PATCH 0/3] Support for Wind River SBC8641D board
From: Paul Gortmaker @ 2008-04-10 23:22 UTC (permalink / raw)
To: linuxppc-dev
The following patches add support for the Wind River SBC8641D board.
I've done it by starting with the current mpc8641_hpcn support and
then making the changes from there, so it should be 1:1 comparable
with the HPCN platform, which aids in tracking/applying future changes.
The SBC8641D support essentially boils down to trimming back stuff
from the HPCN platform, as this board doesn't have the Uli and all
the devices/busses etc. that the HPCN cascades from that. Plus of
course, the dts changes for the localbus specifics.
Patches that aren't included here, but submitted separately are the
support for the Broadcom 5464 quad PHY and the ability to have the
Gianfar TBIPA be auto assigned (since this board puts a PHY at 0x1f).
I expect the defconfig will probably be in an 86xx subdir, based on
what Kumar sent today, but for now it is still in configs. I'm hoping
to see this queued up for 26, if all goes well.
Thanks,
Paul.
^ permalink raw reply
* Re: patches for 2.6.26
From: Josh Boyer @ 2008-04-10 22:50 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080410.151616.204291886.davem@davemloft.net>
On Thu, 2008-04-10 at 15:16 -0700, David Miller wrote:
> From: Laurent Pinchart <laurentp@cse-semaphore.com>
> Date: Thu, 10 Apr 2008 17:20:36 +0200
>
> > On Thursday 10 April 2008 16:21, Kumar Gala wrote:
> > > Guy's
> > >
> > > if you have work you want in 2.6.26 related to Freescale PPC's let me
> > > know. Ideally you can provide links to the patches in
> > > http://patchwork.ozlabs.org/linuxppc/
> >
> > Could you please add this one ?
> >
> > fs_enet: Don't call NAPI functions when NAPI is not used.
> > http://patchwork.ozlabs.org/linuxppc/patch?id=17055
>
> I kindly request that PPC folks send networking driver patches through
> the normal channels so that the networking experts on netdev and
> people like Jeff Garzik can review such changes.
Normally we do. But we appreciate the reminder. Particularly since it
reminded me that I need to chase Jeff down about the ibm_newemac patches
that were sent a while ago.
josh
^ permalink raw reply
* Re: [PATCH 0/5] dynamic detection of gianfar TPIPA
From: David Miller @ 2008-04-10 22:17 UTC (permalink / raw)
To: paul.gortmaker; +Cc: scottwood, linuxppc-dev, linux-net
In-Reply-To: <1207849922-2436-1-git-send-email-paul.gortmaker@windriver.com>
Please use netdev@vger.kernel.org for patch and development
discussion, linux-net is for user discussions only.
^ permalink raw reply
* Re: patches for 2.6.26
From: David Miller @ 2008-04-10 22:16 UTC (permalink / raw)
To: laurentp; +Cc: linuxppc-dev
In-Reply-To: <200804101720.36975.laurentp@cse-semaphore.com>
From: Laurent Pinchart <laurentp@cse-semaphore.com>
Date: Thu, 10 Apr 2008 17:20:36 +0200
> On Thursday 10 April 2008 16:21, Kumar Gala wrote:
> > Guy's
> >
> > if you have work you want in 2.6.26 related to Freescale PPC's let me
> > know. Ideally you can provide links to the patches in
> > http://patchwork.ozlabs.org/linuxppc/
>
> Could you please add this one ?
>
> fs_enet: Don't call NAPI functions when NAPI is not used.
> http://patchwork.ozlabs.org/linuxppc/patch?id=17055
I kindly request that PPC folks send networking driver patches through
the normal channels so that the networking experts on netdev and
people like Jeff Garzik can review such changes.
In fact this patch here is a bug fix and belongs in the tree right
now, instead of waiting for 2.6.26
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
From: Benjamin Herrenschmidt @ 2008-04-10 21:58 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200804101537.27417.sr@denx.de>
On Thu, 2008-04-10 at 15:37 +0200, Stefan Roese wrote:
>
> Now I have to re-check to see what you really have in mind. Do you think about
> creating two different PCIe nodes, one for root-complex and one for endpoint
> functionality? Or is your idea to add a property to the existing PCIe
> device-tree node (like "mode = endpoint"), or perhaps change the device_type
> from "pci" to "pci-endpoint"? I would vote for the latter.
Make the name and type of the node different. The rest can mostly stay
the same.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
From: Benjamin Herrenschmidt @ 2008-04-10 21:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Linux-Arch, linuxppc-dev, takata, linux-m32r, Paul Mackerras
In-Reply-To: <20080410032354.90CB1DDF0F@ozlabs.org>
> +#ifndef thread_info_cache_init
> +#define thread_info_cache_init do { } while(0)
> +#endif
> +
Blah ! Missing a pair of () here. Ooops. I'll send a fixed patch.
Ben.
^ permalink raw reply
* [PATCH] CPM: Always use new binding.
From: Scott Wood @ 2008-04-10 20:45 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The kconfig entry can go away once arch/ppc and references to the config in
drivers are removed.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/platforms/82xx/Kconfig | 3 -
arch/powerpc/platforms/85xx/Kconfig | 8 -
arch/powerpc/platforms/8xx/Kconfig | 4 -
arch/powerpc/platforms/Kconfig | 8 +-
arch/powerpc/sysdev/cpm1.c | 112 -------
arch/powerpc/sysdev/cpm2.c | 97 -------
arch/powerpc/sysdev/cpm_common.c | 3 -
arch/powerpc/sysdev/fsl_soc.c | 541 -----------------------------------
8 files changed, 1 insertions(+), 775 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
index 4fad6c7..917ac88 100644
--- a/arch/powerpc/platforms/82xx/Kconfig
+++ b/arch/powerpc/platforms/82xx/Kconfig
@@ -11,7 +11,6 @@ config MPC8272_ADS
select 8260
select FSL_SOC
select PQ2_ADS_PCI_PIC if PCI
- select PPC_CPM_NEW_BINDING
help
This option enables support for the MPC8272 ADS board
@@ -22,7 +21,6 @@ config PQ2FADS
select 8260
select FSL_SOC
select PQ2_ADS_PCI_PIC if PCI
- select PPC_CPM_NEW_BINDING
help
This option enables support for the PQ2FADS board
@@ -31,7 +29,6 @@ config EP8248E
select 8272
select 8260
select FSL_SOC
- select PPC_CPM_NEW_BINDING
select MDIO_BITBANG
help
This enables support for the Embedded Planet EP8248E board.
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 28bc6e5..7ff29d5 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -19,7 +19,6 @@ config MPC8540_ADS
config MPC8560_ADS
bool "Freescale MPC8560 ADS"
select DEFAULT_UIMAGE
- select PPC_CPM_NEW_BINDING
select CPM2
help
This option enables support for the MPC 8560 ADS board
@@ -48,7 +47,6 @@ config MPC85xx_DS
config KSI8560
bool "Emerson KSI8560"
- select PPC_CPM_NEW_BINDING
select DEFAULT_UIMAGE
help
This option enables support for the Emerson KSI8560 board
@@ -60,14 +58,12 @@ config STX_GP3
board.
select CPM2
select DEFAULT_UIMAGE
- select PPC_CPM_NEW_BINDING
config TQM8540
bool "TQ Components TQM8540"
help
This option enables support for the TQ Components TQM8540 board.
select DEFAULT_UIMAGE
- select PPC_CPM_NEW_BINDING
select TQM85xx
config TQM8541
@@ -75,7 +71,6 @@ config TQM8541
help
This option enables support for the TQ Components TQM8541 board.
select DEFAULT_UIMAGE
- select PPC_CPM_NEW_BINDING
select TQM85xx
select CPM2
@@ -84,7 +79,6 @@ config TQM8555
help
This option enables support for the TQ Components TQM8555 board.
select DEFAULT_UIMAGE
- select PPC_CPM_NEW_BINDING
select TQM85xx
select CPM2
@@ -93,7 +87,6 @@ config TQM8560
help
This option enables support for the TQ Components TQM8560 board.
select DEFAULT_UIMAGE
- select PPC_CPM_NEW_BINDING
select TQM85xx
select CPM2
@@ -106,7 +99,6 @@ config SBC8548
config SBC8560
bool "Wind River SBC8560"
select DEFAULT_UIMAGE
- select PPC_CPM_NEW_BINDING if CPM2
help
This option enables support for the Wind River SBC8560 board
diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
index 7fd224c..6fc849e 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -18,7 +18,6 @@ config MPC8XXFADS
config MPC86XADS
bool "MPC86XADS"
select CPM1
- select PPC_CPM_NEW_BINDING
help
MPC86x Application Development System by Freescale Semiconductor.
The MPC86xADS is meant to serve as a platform for s/w and h/w
@@ -27,7 +26,6 @@ config MPC86XADS
config MPC885ADS
bool "MPC885ADS"
select CPM1
- select PPC_CPM_NEW_BINDING
help
Freescale Semiconductor MPC885 Application Development System (ADS).
Also known as DUET.
@@ -37,7 +35,6 @@ config MPC885ADS
config PPC_EP88XC
bool "Embedded Planet EP88xC (a.k.a. CWH-PPC-885XN-VE)"
select CPM1
- select PPC_CPM_NEW_BINDING
help
This enables support for the Embedded Planet EP88xC board.
@@ -47,7 +44,6 @@ config PPC_EP88XC
config PPC_ADDER875
bool "Analogue & Micro Adder 875"
select CPM1
- select PPC_CPM_NEW_BINDING
select REDBOOT
help
This enables support for the Analogue & Micro Adder 875
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index a578b96..f38c50b 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -290,13 +290,7 @@ config CPM2
config PPC_CPM_NEW_BINDING
bool
depends on CPM1 || CPM2
- help
- Select this if your board has been converted to use the new
- device tree bindings for CPM, and no longer needs the
- ioport callbacks or the platform device glue code.
-
- The fs_enet and cpm_uart drivers will be built as
- of_platform devices.
+ default y
config AXON_RAM
tristate "Axon DDR2 memory device driver"
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index 3eceeb5..58292a0 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -44,9 +44,6 @@
#define CPM_MAP_SIZE (0x4000)
-#ifndef CONFIG_PPC_CPM_NEW_BINDING
-static void m8xx_cpm_dpinit(void);
-#endif
cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */
immap_t __iomem *mpc8xx_immr;
static cpic8xx_t __iomem *cpic_reg;
@@ -229,12 +226,7 @@ void __init cpm_reset(void)
out_be32(&siu_conf->sc_sdcr, 1);
immr_unmap(siu_conf);
-#ifdef CONFIG_PPC_CPM_NEW_BINDING
cpm_muram_init();
-#else
- /* Reclaim the DP memory for our use. */
- m8xx_cpm_dpinit();
-#endif
}
static DEFINE_SPINLOCK(cmd_lock);
@@ -293,110 +285,6 @@ cpm_setbrg(uint brg, uint rate)
CPM_BRG_EN | CPM_BRG_DIV16);
}
-#ifndef CONFIG_PPC_CPM_NEW_BINDING
-/*
- * dpalloc / dpfree bits.
- */
-static spinlock_t cpm_dpmem_lock;
-/*
- * 16 blocks should be enough to satisfy all requests
- * until the memory subsystem goes up...
- */
-static rh_block_t cpm_boot_dpmem_rh_block[16];
-static rh_info_t cpm_dpmem_info;
-
-#define CPM_DPMEM_ALIGNMENT 8
-static u8 __iomem *dpram_vbase;
-static phys_addr_t dpram_pbase;
-
-static void m8xx_cpm_dpinit(void)
-{
- spin_lock_init(&cpm_dpmem_lock);
-
- dpram_vbase = cpmp->cp_dpmem;
- dpram_pbase = get_immrbase() + offsetof(immap_t, im_cpm.cp_dpmem);
-
- /* Initialize the info header */
- rh_init(&cpm_dpmem_info, CPM_DPMEM_ALIGNMENT,
- sizeof(cpm_boot_dpmem_rh_block) /
- sizeof(cpm_boot_dpmem_rh_block[0]),
- cpm_boot_dpmem_rh_block);
-
- /*
- * Attach the usable dpmem area.
- * XXX: This is actually crap. CPM_DATAONLY_BASE and
- * CPM_DATAONLY_SIZE are a subset of the available dparm. It varies
- * with the processor and the microcode patches applied / activated.
- * But the following should be at least safe.
- */
- rh_attach_region(&cpm_dpmem_info, CPM_DATAONLY_BASE, CPM_DATAONLY_SIZE);
-}
-
-/*
- * Allocate the requested size worth of DP memory.
- * This function returns an offset into the DPRAM area.
- * Use cpm_dpram_addr() to get the virtual address of the area.
- */
-unsigned long cpm_dpalloc(uint size, uint align)
-{
- unsigned long start;
- unsigned long flags;
-
- spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc(&cpm_dpmem_info, size, "commproc");
- spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
-
- return (uint)start;
-}
-EXPORT_SYMBOL(cpm_dpalloc);
-
-int cpm_dpfree(unsigned long offset)
-{
- int ret;
- unsigned long flags;
-
- spin_lock_irqsave(&cpm_dpmem_lock, flags);
- ret = rh_free(&cpm_dpmem_info, offset);
- spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
-
- return ret;
-}
-EXPORT_SYMBOL(cpm_dpfree);
-
-unsigned long cpm_dpalloc_fixed(unsigned long offset, uint size, uint align)
-{
- unsigned long start;
- unsigned long flags;
-
- spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc_fixed(&cpm_dpmem_info, offset, size, "commproc");
- spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
-
- return start;
-}
-EXPORT_SYMBOL(cpm_dpalloc_fixed);
-
-void cpm_dpdump(void)
-{
- rh_dump(&cpm_dpmem_info);
-}
-EXPORT_SYMBOL(cpm_dpdump);
-
-void *cpm_dpram_addr(unsigned long offset)
-{
- return (void *)(dpram_vbase + offset);
-}
-EXPORT_SYMBOL(cpm_dpram_addr);
-
-uint cpm_dpram_phys(u8 *addr)
-{
- return (dpram_pbase + (uint)(addr - dpram_vbase));
-}
-EXPORT_SYMBOL(cpm_dpram_phys);
-#endif /* !CONFIG_PPC_CPM_NEW_BINDING */
-
struct cpm_ioport16 {
__be16 dir, par, odr_sor, dat, intr;
__be16 res[3];
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 803b59c..f2fc1a5 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -46,10 +46,6 @@
#include <sysdev/fsl_soc.h>
-#ifndef CONFIG_PPC_CPM_NEW_BINDING
-static void cpm2_dpinit(void);
-#endif
-
cpm_cpm2_t __iomem *cpmp; /* Pointer to comm processor space */
/* We allocate this here because it is used almost exclusively for
@@ -71,11 +67,7 @@ void __init cpm2_reset(void)
/* Reclaim the DP memory for our use.
*/
-#ifdef CONFIG_PPC_CPM_NEW_BINDING
cpm_muram_init();
-#else
- cpm2_dpinit();
-#endif
/* Tell everyone where the comm processor resides.
*/
@@ -346,95 +338,6 @@ int cpm2_smc_clk_setup(enum cpm_clk_target target, int clock)
return ret;
}
-#ifndef CONFIG_PPC_CPM_NEW_BINDING
-/*
- * dpalloc / dpfree bits.
- */
-static spinlock_t cpm_dpmem_lock;
-/* 16 blocks should be enough to satisfy all requests
- * until the memory subsystem goes up... */
-static rh_block_t cpm_boot_dpmem_rh_block[16];
-static rh_info_t cpm_dpmem_info;
-static u8 __iomem *im_dprambase;
-
-static void cpm2_dpinit(void)
-{
- spin_lock_init(&cpm_dpmem_lock);
-
- /* initialize the info header */
- rh_init(&cpm_dpmem_info, 1,
- sizeof(cpm_boot_dpmem_rh_block) /
- sizeof(cpm_boot_dpmem_rh_block[0]),
- cpm_boot_dpmem_rh_block);
-
- im_dprambase = cpm2_immr;
-
- /* Attach the usable dpmem area */
- /* XXX: This is actually crap. CPM_DATAONLY_BASE and
- * CPM_DATAONLY_SIZE is only a subset of the available dpram. It
- * varies with the processor and the microcode patches activated.
- * But the following should be at least safe.
- */
- rh_attach_region(&cpm_dpmem_info, CPM_DATAONLY_BASE, CPM_DATAONLY_SIZE);
-}
-
-/* This function returns an index into the DPRAM area.
- */
-unsigned long cpm_dpalloc(uint size, uint align)
-{
- unsigned long start;
- unsigned long flags;
-
- spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc(&cpm_dpmem_info, size, "commproc");
- spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
-
- return (uint)start;
-}
-EXPORT_SYMBOL(cpm_dpalloc);
-
-int cpm_dpfree(unsigned long offset)
-{
- int ret;
- unsigned long flags;
-
- spin_lock_irqsave(&cpm_dpmem_lock, flags);
- ret = rh_free(&cpm_dpmem_info, offset);
- spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
-
- return ret;
-}
-EXPORT_SYMBOL(cpm_dpfree);
-
-/* not sure if this is ever needed */
-unsigned long cpm_dpalloc_fixed(unsigned long offset, uint size, uint align)
-{
- unsigned long start;
- unsigned long flags;
-
- spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc_fixed(&cpm_dpmem_info, offset, size, "commproc");
- spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
-
- return start;
-}
-EXPORT_SYMBOL(cpm_dpalloc_fixed);
-
-void cpm_dpdump(void)
-{
- rh_dump(&cpm_dpmem_info);
-}
-EXPORT_SYMBOL(cpm_dpdump);
-
-void *cpm_dpram_addr(unsigned long offset)
-{
- return (void *)(im_dprambase + offset);
-}
-EXPORT_SYMBOL(cpm_dpram_addr);
-#endif /* !CONFIG_PPC_CPM_NEW_BINDING */
-
struct cpm2_ioports {
u32 dir, par, sor, odr, dat;
u32 res[3];
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 165981c..cb7df2d 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -58,7 +58,6 @@ void __init udbg_init_cpm(void)
}
#endif
-#ifdef CONFIG_PPC_CPM_NEW_BINDING
static spinlock_t cpm_muram_lock;
static rh_block_t cpm_boot_muram_rh_block[16];
static rh_info_t cpm_muram_info;
@@ -199,5 +198,3 @@ dma_addr_t cpm_muram_dma(void __iomem *addr)
return muram_pbase + ((u8 __iomem *)addr - muram_vbase);
}
EXPORT_SYMBOL(cpm_muram_dma);
-
-#endif /* CONFIG_PPC_CPM_NEW_BINDING */
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 2c5388c..642e45e 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -735,547 +735,6 @@ err:
arch_initcall(fsl_usb_of_init);
-#ifndef CONFIG_PPC_CPM_NEW_BINDING
-#ifdef CONFIG_CPM2
-
-extern void init_scc_ioports(struct fs_uart_platform_info*);
-
-static const char fcc_regs[] = "fcc_regs";
-static const char fcc_regs_c[] = "fcc_regs_c";
-static const char fcc_pram[] = "fcc_pram";
-static char bus_id[9][BUS_ID_SIZE];
-
-static int __init fs_enet_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *fs_enet_dev;
- struct resource res;
- int ret;
-
- for (np = NULL, i = 0;
- (np = of_find_compatible_node(np, "network", "fs_enet")) != NULL;
- i++) {
- struct resource r[4];
- struct device_node *phy, *mdio;
- struct fs_platform_info fs_enet_data;
- const unsigned int *id, *phy_addr, *phy_irq;
- const void *mac_addr;
- const phandle *ph;
- const char *model;
-
- memset(r, 0, sizeof(r));
- memset(&fs_enet_data, 0, sizeof(fs_enet_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
- r[0].name = fcc_regs;
-
- ret = of_address_to_resource(np, 1, &r[1]);
- if (ret)
- goto err;
- r[1].name = fcc_pram;
-
- ret = of_address_to_resource(np, 2, &r[2]);
- if (ret)
- goto err;
- r[2].name = fcc_regs_c;
- fs_enet_data.fcc_regs_c = r[2].start;
-
- of_irq_to_resource(np, 0, &r[3]);
-
- fs_enet_dev =
- platform_device_register_simple("fsl-cpm-fcc", i, &r[0], 4);
-
- if (IS_ERR(fs_enet_dev)) {
- ret = PTR_ERR(fs_enet_dev);
- goto err;
- }
-
- model = of_get_property(np, "model", NULL);
- if (model == NULL) {
- ret = -ENODEV;
- goto unreg;
- }
-
- mac_addr = of_get_mac_address(np);
- if (mac_addr)
- memcpy(fs_enet_data.macaddr, mac_addr, 6);
-
- ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
-
- if (phy == NULL) {
- ret = -ENODEV;
- goto unreg;
- }
-
- phy_addr = of_get_property(phy, "reg", NULL);
- fs_enet_data.phy_addr = *phy_addr;
-
- phy_irq = of_get_property(phy, "interrupts", NULL);
-
- id = of_get_property(np, "device-id", NULL);
- fs_enet_data.fs_no = *id;
- strcpy(fs_enet_data.fs_type, model);
-
- mdio = of_get_parent(phy);
- ret = of_address_to_resource(mdio, 0, &res);
- if (ret) {
- of_node_put(phy);
- of_node_put(mdio);
- goto unreg;
- }
-
- fs_enet_data.clk_rx = *((u32 *)of_get_property(np,
- "rx-clock", NULL));
- fs_enet_data.clk_tx = *((u32 *)of_get_property(np,
- "tx-clock", NULL));
-
- if (strstr(model, "FCC")) {
- int fcc_index = *id - 1;
- const unsigned char *mdio_bb_prop;
-
- fs_enet_data.dpram_offset = (u32)cpm_dpram_addr(0);
- fs_enet_data.rx_ring = 32;
- fs_enet_data.tx_ring = 32;
- fs_enet_data.rx_copybreak = 240;
- fs_enet_data.use_napi = 0;
- fs_enet_data.napi_weight = 17;
- fs_enet_data.mem_offset = FCC_MEM_OFFSET(fcc_index);
- fs_enet_data.cp_page = CPM_CR_FCC_PAGE(fcc_index);
- fs_enet_data.cp_block = CPM_CR_FCC_SBLOCK(fcc_index);
-
- snprintf((char*)&bus_id[(*id)], BUS_ID_SIZE, "%x:%02x",
- (u32)res.start, fs_enet_data.phy_addr);
- fs_enet_data.bus_id = (char*)&bus_id[(*id)];
- fs_enet_data.init_ioports = init_fcc_ioports;
-
- mdio_bb_prop = of_get_property(phy, "bitbang", NULL);
- if (mdio_bb_prop) {
- struct platform_device *fs_enet_mdio_bb_dev;
- struct fs_mii_bb_platform_info fs_enet_mdio_bb_data;
-
- fs_enet_mdio_bb_dev =
- platform_device_register_simple("fsl-bb-mdio",
- i, NULL, 0);
- memset(&fs_enet_mdio_bb_data, 0,
- sizeof(struct fs_mii_bb_platform_info));
- fs_enet_mdio_bb_data.mdio_dat.bit =
- mdio_bb_prop[0];
- fs_enet_mdio_bb_data.mdio_dir.bit =
- mdio_bb_prop[1];
- fs_enet_mdio_bb_data.mdc_dat.bit =
- mdio_bb_prop[2];
- fs_enet_mdio_bb_data.mdio_port =
- mdio_bb_prop[3];
- fs_enet_mdio_bb_data.mdc_port =
- mdio_bb_prop[4];
- fs_enet_mdio_bb_data.delay =
- mdio_bb_prop[5];
-
- fs_enet_mdio_bb_data.irq[0] = phy_irq[0];
- fs_enet_mdio_bb_data.irq[1] = -1;
- fs_enet_mdio_bb_data.irq[2] = -1;
- fs_enet_mdio_bb_data.irq[3] = phy_irq[0];
- fs_enet_mdio_bb_data.irq[31] = -1;
-
- fs_enet_mdio_bb_data.mdio_dat.offset =
- (u32)&cpm2_immr->im_ioport.iop_pdatc;
- fs_enet_mdio_bb_data.mdio_dir.offset =
- (u32)&cpm2_immr->im_ioport.iop_pdirc;
- fs_enet_mdio_bb_data.mdc_dat.offset =
- (u32)&cpm2_immr->im_ioport.iop_pdatc;
-
- ret = platform_device_add_data(
- fs_enet_mdio_bb_dev,
- &fs_enet_mdio_bb_data,
- sizeof(struct fs_mii_bb_platform_info));
- if (ret)
- goto unreg;
- }
-
- of_node_put(phy);
- of_node_put(mdio);
-
- ret = platform_device_add_data(fs_enet_dev, &fs_enet_data,
- sizeof(struct
- fs_platform_info));
- if (ret)
- goto unreg;
- }
- }
- return 0;
-
-unreg:
- platform_device_unregister(fs_enet_dev);
-err:
- return ret;
-}
-
-arch_initcall(fs_enet_of_init);
-
-static const char scc_regs[] = "regs";
-static const char scc_pram[] = "pram";
-
-static int __init cpm_uart_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *cpm_uart_dev;
- int ret;
-
- for (np = NULL, i = 0;
- (np = of_find_compatible_node(np, "serial", "cpm_uart")) != NULL;
- i++) {
- struct resource r[3];
- struct fs_uart_platform_info cpm_uart_data;
- const int *id;
- const char *model;
-
- memset(r, 0, sizeof(r));
- memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
-
- r[0].name = scc_regs;
-
- ret = of_address_to_resource(np, 1, &r[1]);
- if (ret)
- goto err;
- r[1].name = scc_pram;
-
- of_irq_to_resource(np, 0, &r[2]);
-
- cpm_uart_dev =
- platform_device_register_simple("fsl-cpm-scc:uart", i, &r[0], 3);
-
- if (IS_ERR(cpm_uart_dev)) {
- ret = PTR_ERR(cpm_uart_dev);
- goto err;
- }
-
- id = of_get_property(np, "device-id", NULL);
- cpm_uart_data.fs_no = *id;
-
- model = of_get_property(np, "model", NULL);
- strcpy(cpm_uart_data.fs_type, model);
-
- cpm_uart_data.uart_clk = ppc_proc_freq;
-
- cpm_uart_data.tx_num_fifo = 4;
- cpm_uart_data.tx_buf_size = 32;
- cpm_uart_data.rx_num_fifo = 4;
- cpm_uart_data.rx_buf_size = 32;
- cpm_uart_data.clk_rx = *((u32 *)of_get_property(np,
- "rx-clock", NULL));
- cpm_uart_data.clk_tx = *((u32 *)of_get_property(np,
- "tx-clock", NULL));
-
- ret =
- platform_device_add_data(cpm_uart_dev, &cpm_uart_data,
- sizeof(struct
- fs_uart_platform_info));
- if (ret)
- goto unreg;
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(cpm_uart_dev);
-err:
- return ret;
-}
-
-arch_initcall(cpm_uart_of_init);
-#endif /* CONFIG_CPM2 */
-
-#ifdef CONFIG_8xx
-
-extern void init_scc_ioports(struct fs_platform_info*);
-extern int platform_device_skip(const char *model, int id);
-
-static int __init fs_enet_mdio_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *mdio_dev;
- struct resource res;
- int ret;
-
- for (np = NULL, i = 0;
- (np = of_find_compatible_node(np, "mdio", "fs_enet")) != NULL;
- i++) {
- struct fs_mii_fec_platform_info mdio_data;
-
- memset(&res, 0, sizeof(res));
- memset(&mdio_data, 0, sizeof(mdio_data));
-
- ret = of_address_to_resource(np, 0, &res);
- if (ret)
- goto err;
-
- mdio_dev =
- platform_device_register_simple("fsl-cpm-fec-mdio",
- res.start, &res, 1);
- if (IS_ERR(mdio_dev)) {
- ret = PTR_ERR(mdio_dev);
- goto err;
- }
-
- mdio_data.mii_speed = ((((ppc_proc_freq + 4999999) / 2500000) / 2) & 0x3F) << 1;
-
- ret =
- platform_device_add_data(mdio_dev, &mdio_data,
- sizeof(struct fs_mii_fec_platform_info));
- if (ret)
- goto unreg;
- }
- return 0;
-
-unreg:
- platform_device_unregister(mdio_dev);
-err:
- return ret;
-}
-
-arch_initcall(fs_enet_mdio_of_init);
-
-static const char *enet_regs = "regs";
-static const char *enet_pram = "pram";
-static const char *enet_irq = "interrupt";
-static char bus_id[9][BUS_ID_SIZE];
-
-static int __init fs_enet_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *fs_enet_dev = NULL;
- struct resource res;
- int ret;
-
- for (np = NULL, i = 0;
- (np = of_find_compatible_node(np, "network", "fs_enet")) != NULL;
- i++) {
- struct resource r[4];
- struct device_node *phy = NULL, *mdio = NULL;
- struct fs_platform_info fs_enet_data;
- const unsigned int *id;
- const unsigned int *phy_addr;
- const void *mac_addr;
- const phandle *ph;
- const char *model;
-
- memset(r, 0, sizeof(r));
- memset(&fs_enet_data, 0, sizeof(fs_enet_data));
-
- model = of_get_property(np, "model", NULL);
- if (model == NULL) {
- ret = -ENODEV;
- goto unreg;
- }
-
- id = of_get_property(np, "device-id", NULL);
- fs_enet_data.fs_no = *id;
-
- if (platform_device_skip(model, *id))
- continue;
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
- r[0].name = enet_regs;
-
- mac_addr = of_get_mac_address(np);
- if (mac_addr)
- memcpy(fs_enet_data.macaddr, mac_addr, 6);
-
- ph = of_get_property(np, "phy-handle", NULL);
- if (ph != NULL)
- phy = of_find_node_by_phandle(*ph);
-
- if (phy != NULL) {
- phy_addr = of_get_property(phy, "reg", NULL);
- fs_enet_data.phy_addr = *phy_addr;
- fs_enet_data.has_phy = 1;
-
- mdio = of_get_parent(phy);
- ret = of_address_to_resource(mdio, 0, &res);
- if (ret) {
- of_node_put(phy);
- of_node_put(mdio);
- goto unreg;
- }
- }
-
- model = of_get_property(np, "model", NULL);
- strcpy(fs_enet_data.fs_type, model);
-
- if (strstr(model, "FEC")) {
- r[1].start = r[1].end = irq_of_parse_and_map(np, 0);
- r[1].flags = IORESOURCE_IRQ;
- r[1].name = enet_irq;
-
- fs_enet_dev =
- platform_device_register_simple("fsl-cpm-fec", i, &r[0], 2);
-
- if (IS_ERR(fs_enet_dev)) {
- ret = PTR_ERR(fs_enet_dev);
- goto err;
- }
-
- fs_enet_data.rx_ring = 128;
- fs_enet_data.tx_ring = 16;
- fs_enet_data.rx_copybreak = 240;
- fs_enet_data.use_napi = 1;
- fs_enet_data.napi_weight = 17;
-
- snprintf((char*)&bus_id[i], BUS_ID_SIZE, "%x:%02x",
- (u32)res.start, fs_enet_data.phy_addr);
- fs_enet_data.bus_id = (char*)&bus_id[i];
- fs_enet_data.init_ioports = init_fec_ioports;
- }
- if (strstr(model, "SCC")) {
- ret = of_address_to_resource(np, 1, &r[1]);
- if (ret)
- goto err;
- r[1].name = enet_pram;
-
- r[2].start = r[2].end = irq_of_parse_and_map(np, 0);
- r[2].flags = IORESOURCE_IRQ;
- r[2].name = enet_irq;
-
- fs_enet_dev =
- platform_device_register_simple("fsl-cpm-scc", i, &r[0], 3);
-
- if (IS_ERR(fs_enet_dev)) {
- ret = PTR_ERR(fs_enet_dev);
- goto err;
- }
-
- fs_enet_data.rx_ring = 64;
- fs_enet_data.tx_ring = 8;
- fs_enet_data.rx_copybreak = 240;
- fs_enet_data.use_napi = 1;
- fs_enet_data.napi_weight = 17;
-
- snprintf((char*)&bus_id[i], BUS_ID_SIZE, "%s", "fixed@10:1");
- fs_enet_data.bus_id = (char*)&bus_id[i];
- fs_enet_data.init_ioports = init_scc_ioports;
- }
-
- of_node_put(phy);
- of_node_put(mdio);
-
- ret = platform_device_add_data(fs_enet_dev, &fs_enet_data,
- sizeof(struct
- fs_platform_info));
- if (ret)
- goto unreg;
- }
- return 0;
-
-unreg:
- platform_device_unregister(fs_enet_dev);
-err:
- return ret;
-}
-
-arch_initcall(fs_enet_of_init);
-
-static int __init fsl_pcmcia_of_init(void)
-{
- struct device_node *np;
- /*
- * Register all the devices which type is "pcmcia"
- */
- for_each_compatible_node(np, "pcmcia", "fsl,pq-pcmcia")
- of_platform_device_create(np, "m8xx-pcmcia", NULL);
- return 0;
-}
-
-arch_initcall(fsl_pcmcia_of_init);
-
-static const char *smc_regs = "regs";
-static const char *smc_pram = "pram";
-
-static int __init cpm_smc_uart_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *cpm_uart_dev;
- int ret;
-
- for (np = NULL, i = 0;
- (np = of_find_compatible_node(np, "serial", "cpm_uart")) != NULL;
- i++) {
- struct resource r[3];
- struct fs_uart_platform_info cpm_uart_data;
- const int *id;
- const char *model;
-
- memset(r, 0, sizeof(r));
- memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
-
- r[0].name = smc_regs;
-
- ret = of_address_to_resource(np, 1, &r[1]);
- if (ret)
- goto err;
- r[1].name = smc_pram;
-
- r[2].start = r[2].end = irq_of_parse_and_map(np, 0);
- r[2].flags = IORESOURCE_IRQ;
-
- cpm_uart_dev =
- platform_device_register_simple("fsl-cpm-smc:uart", i, &r[0], 3);
-
- if (IS_ERR(cpm_uart_dev)) {
- ret = PTR_ERR(cpm_uart_dev);
- goto err;
- }
-
- model = of_get_property(np, "model", NULL);
- strcpy(cpm_uart_data.fs_type, model);
-
- id = of_get_property(np, "device-id", NULL);
- cpm_uart_data.fs_no = *id;
- cpm_uart_data.uart_clk = ppc_proc_freq;
-
- cpm_uart_data.tx_num_fifo = 4;
- cpm_uart_data.tx_buf_size = 32;
- cpm_uart_data.rx_num_fifo = 4;
- cpm_uart_data.rx_buf_size = 32;
-
- ret =
- platform_device_add_data(cpm_uart_dev, &cpm_uart_data,
- sizeof(struct
- fs_uart_platform_info));
- if (ret)
- goto unreg;
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(cpm_uart_dev);
-err:
- return ret;
-}
-
-arch_initcall(cpm_smc_uart_of_init);
-
-#endif /* CONFIG_8xx */
-#endif /* CONFIG_PPC_CPM_NEW_BINDING */
-
static int __init of_fsl_spi_probe(char *type, char *compatible, u32 sysclk,
struct spi_board_info *board_infos,
unsigned int num_board_infos,
--
1.5.4.4
^ permalink raw reply related
* Re: [PATCH] [v5] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-10 20:08 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <200804101544.44457.arnd@arndb.de>
On Thu, 2008-04-10 at 15:44 +0200, Arnd Bergmann wrote:
> On Tuesday 08 April 2008, Jerone Young wrote:
> > +static struct sleep_mode modes[] = {
> > + { .name = "wait", .entry = &ppc44x_idle },
> > + { .name = "spin", .entry = NULL },
> > +};
> > +
> > +int __init ppc44x_idle_init(void)
> > +{
> > + void *func = modes[current_mode].entry;
> > + ppc_md.power_save = func;
> > + return 0;
> > +}
> > +
> > +arch_initcall(ppc44x_idle_init);
> > +
> > +static int __init idle_param(char *p)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(modes); i++) {
> > + if (!strcmp(modes[i].name, p)) {
> > + current_mode = i;
> > + break;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +early_param("idle", idle_param);
>
> ok, sorry to steal the show again, now that everyone seems to be happy
> with the current code, but isn't this equivalent to the simple
Well it could be this simple. But the current code leaves a lot more
room to add different type waits or spins if need be (if they are ever
needed ... though none off the top of my head at the moment)...but it
does allow you to create another wait state for whatever reason a lot
easier.
So I really don't think this needs to change. Unless everyone really
feels that it just has to be.
>
> static int __init idle_param(char *p)
> {
> if (!strcmp(modes[i].name, "spin"))
> ppc_md.power_save = NULL;
> }
> early_param("idle", idle_param);
>
> if you statically initialize the ppc_md.power_save function to ppc44x_idle
> in the platform setup files?
The idea is to not statically initialize ppc_md.power_save to
ppc44x_idle in each platform setup file.
>
> Arnd <><
^ permalink raw reply
* Re: [PATCH 6/13] devres: implement managed iomap interface
From: Kumar Gala @ 2008-04-10 19:40 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Tejun Heo, linux-ide, gregkh, linux-kernel, linuxppc-dev, jgarzik,
alan
In-Reply-To: <47FE5B76.40409@ru.mvista.com>
On Apr 10, 2008, at 1:24 PM, Sergei Shtylyov wrote:
> Kumar Gala wrote:
>
>>>>>> Those functions are going to break on 32-bit platforms with
>>>>>> extended physical address (well, that's starting with Pentiums
>>>>>> which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
>>>>>> PowerPC 44x). You should have used resource_size_t for the
>>>>>> 'offset' parameter. As this most probably means that libata is
>>>>>> broken on such platforms, I'm going to submit a patch...
>
>>>> It's broken with drivers using MMIO, I meant to say.
>
>>> Oops, I meant PCI drivers here, at least for the time being. And
>>> it looks like that was a false alarm. :-]
>
>>>>> Yeah, right please go ahead. But I wonder whether any BIOS was
>>>>> actually crazy enough to map mmio region above 4G on 32bit
>>>>> machine.
>
>>>> This is a *hardware* mapping on some non-x86 platforms (like
>>>> PPC 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels
>>>> have special hooks called from ioremap() which help create an
>>>> illusion that the PCI memory space on such platforms (not only
>>>> it) is mapped below 4 GB; arch/powerpc/ kernel doesn't do this
>>>> anymore -- hence this newly encountered issue.
>
>>> I thought that pcim_iomap() used devm_ioremap() or something --
>>> which of course turned to be wrong. devm_ioremap() alone is yet
>>> safe since there are no users for it amongst PPC 44x platform
>>> device drivers...
>
>> but there is no reason not to make it work properly. For example
>> I believe libata uses devm_* and the fsl SATA driver (non-PCI)
>> will need to work in cases similar to the 44x.
>
> Well, as for sata_fsl, it calls of_iomap() which does The Right
> Thing.
Fair, but I don't see why we should introduce new APIs that are
already "broken". We went through a lot of effort to clean up and
introduce resource_t (and clearly still have some bugs) for the >32-
bit physical address problem.
- k
^ permalink raw reply
* Re: [PATCH 6/13] devres: implement managed iomap interface
From: Sergei Shtylyov @ 2008-04-10 18:24 UTC (permalink / raw)
To: Kumar Gala
Cc: Tejun Heo, linux-ide, gregkh, linux-kernel, linuxppc-dev, jgarzik,
alan
In-Reply-To: <59A939C7-75AF-4C0F-8199-4C31D174AEA9@kernel.crashing.org>
Kumar Gala wrote:
>>>>> Those functions are going to break on 32-bit platforms with
>>>>> extended physical address (well, that's starting with Pentiums
>>>>> which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
>>>>> PowerPC 44x). You should have used resource_size_t for the
>>>>> 'offset' parameter. As this most probably means that libata is
>>>>> broken on such platforms, I'm going to submit a patch...
>>> It's broken with drivers using MMIO, I meant to say.
>> Oops, I meant PCI drivers here, at least for the time being. And it
>> looks like that was a false alarm. :-]
>>>> Yeah, right please go ahead. But I wonder whether any BIOS was
>>>> actually crazy enough to map mmio region above 4G on 32bit machine.
>>> This is a *hardware* mapping on some non-x86 platforms (like PPC
>>> 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have
>>> special hooks called from ioremap() which help create an illusion
>>> that the PCI memory space on such platforms (not only it) is mapped
>>> below 4 GB; arch/powerpc/ kernel doesn't do this anymore -- hence
>>> this newly encountered issue.
>> I thought that pcim_iomap() used devm_ioremap() or something --
>> which of course turned to be wrong. devm_ioremap() alone is yet safe
>> since there are no users for it amongst PPC 44x platform device
>> drivers...
> but there is no reason not to make it work properly. For example I
> believe libata uses devm_* and the fsl SATA driver (non-PCI) will need
> to work in cases similar to the 44x.
Well, as for sata_fsl, it calls of_iomap() which does The Right Thing.
> - k
WBR, Sergei
^ permalink raw reply
* Re: ppc440 caches - change proposal [RFC]
From: Josh Boyer @ 2008-04-10 18:03 UTC (permalink / raw)
To: Grant Likely; +Cc: John Bonesio, Linuxppc-dev
In-Reply-To: <fa686aa40804091250u1f532cddj9e3897969a98349c@mail.gmail.com>
On Wed, 9 Apr 2008 13:50:43 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <john.bonesio@xilinx.com> wrote:
> > I understand that many people are using a bootloader that already sets up the
> > cache for the kernel, but I'm wondering if Xilinx boards are really a special
> > case, or if there may be other non-Xilinx related systems that would also not
> > be using a bootloader.
>
> I think there are very few cases of platforms not using some form of firmware.
Indeed.
> > I also understand the desire to avoid code that does the same work more than
> > once, but I wonder if in this case, it's creating too strong a dependence on
> > the specific behavior of a certain bootloader.
> > I also wonder if arch/powerpc is being made more complex by trying to split
> > out this code change into a Xilinx specific area, when the change could just
> > be rolled into head_40x.S and we could do away with virtex405-head.S.
>
> In general, I think that the wrapper does not want to touch the cache
> settings. In the common case where firmware exists and sets up the
> cache then to turn off the cache again would throw away what firmware
> already had in cache and slow down the boot.
>
> That being said, I'm not the bootwrapper expert. If other think that
> it belongs in head_40x.S then I have no objections.
>
> Josh, any thoughts?
This may or may not be OK. In the general case, I think Grant is right
in that the wrapper tends to avoid mucking with cache settings that
were already setup by the firmware.
For 405 specifically, it could go either way. And we actually already
ignore the cache settings for real mode anyway once it gets to
MMU_init_hw, but I wouldn't be surprised if an assumption was made
there as well.
josh
^ permalink raw reply
* Re: [PATCH 6/13] devres: implement managed iomap interface
From: Kumar Gala @ 2008-04-10 17:44 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Tejun Heo, linux-ide, gregkh, linux-kernel, linuxppc-dev, jgarzik,
alan
In-Reply-To: <47FE46AC.5000901@ru.mvista.com>
On Apr 10, 2008, at 11:56 AM, Sergei Shtylyov wrote:
> Hello, I wrote:
>
>>>> Those functions are going to break on 32-bit platforms with
>>>> extended physical address (well, that's starting with Pentiums
>>>> which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
>>>> PowerPC 44x). You should have used resource_size_t for the
>>>> 'offset' parameter. As this most probably means that libata is
>>>> broken on such platforms, I'm going to submit a patch...
>
>> It's broken with drivers using MMIO, I meant to say.
>
> Oops, I meant PCI drivers here, at least for the time being. And
> it looks like that was a false alarm. :-]
>
>>> Yeah, right please go ahead. But I wonder whether any BIOS was
>>> actually crazy enough to map mmio region above 4G on 32bit machine.
>
>> This is a *hardware* mapping on some non-x86 platforms (like PPC
>> 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have
>> special hooks called from ioremap() which help create an illusion
>> that the PCI memory space on such platforms (not only it) is mapped
>> below 4 GB; arch/powerpc/ kernel doesn't do this anymore -- hence
>> this newly encountered issue.
>
> I thought that pcim_iomap() used devm_ioremap() or something --
> which of course turned to be wrong. devm_ioremap() alone is yet safe
> since there are no users for it amongst PPC 44x platform device
> drivers...
but there is no reason not to make it work properly. For example I
believe libata uses devm_* and the fsl SATA driver (non-PCI) will need
to work in cases similar to the 44x.
- k
^ permalink raw reply
* Re: How to pass information from the bootloader to the kernel ?
From: Kumar Gala @ 2008-04-10 17:41 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804101751.00618.laurentp@cse-semaphore.com>
On Apr 10, 2008, at 10:50 AM, Laurent Pinchart wrote:
> Hi everybody,
>
> I need to pass a limited amount of information from the boot loader
> to the
> Linux kernel, such as the boot mode chosen by the user or the last
> boot
> reason (power up, reset, watchdog, ...).
>
> What is the best way to pass that kind of information from the boot
> loader to
> the kernel ? Should I use the device tree ?
>
> I thought about populating the chosen node with the data I need.
> This could
> make sense for the boot mode, but I feel like I would abuse the
> chosen node
> if I used it to pass other "non user chosen" information.
using chosen is fine, just remember to prefix properties with some
vendor prefix.
- k
^ permalink raw reply
* Re: [PATCH 6/13] devres: implement managed iomap interface
From: Sergei Shtylyov @ 2008-04-10 16:56 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, gregkh, linux-kernel, linuxppc-dev, jgarzik, alan
In-Reply-To: <47FB8751.3040301@ru.mvista.com>
Hello, I wrote:
>>> Those functions are going to break on 32-bit platforms with
>>> extended physical address (well, that's starting with Pentiums which
>>> had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC
>>> 44x). You should have used resource_size_t for the 'offset'
>>> parameter. As this most probably means that libata is broken on such
>>> platforms, I'm going to submit a patch...
> It's broken with drivers using MMIO, I meant to say.
Oops, I meant PCI drivers here, at least for the time being. And it looks
like that was a false alarm. :-]
>> Yeah, right please go ahead. But I wonder whether any BIOS was
>> actually crazy enough to map mmio region above 4G on 32bit machine.
> This is a *hardware* mapping on some non-x86 platforms (like PPC 44x
> or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special
> hooks called from ioremap() which help create an illusion that the PCI
> memory space on such platforms (not only it) is mapped below 4 GB;
> arch/powerpc/ kernel doesn't do this anymore -- hence this newly
> encountered issue.
I thought that pcim_iomap() used devm_ioremap() or something -- which of
course turned to be wrong. devm_ioremap() alone is yet safe since there are no
users for it amongst PPC 44x platform device drivers...
MBR, Sergei
^ permalink raw reply
* Re: Kernel Panic - not syncing: Attempted to kill init!
From: Sreen Tallam @ 2008-04-10 16:53 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080410085030.GA27907@Chamillionaire.breakpoint.cc>
Hi Sebastian,
Thank you for looking into this issue.
But I am not using udev. And my /dev is empty, there is no devices in there.
Any more hints on this. I would appreciate your follow up.
Thanks,
Sreen
On Thu, Apr 10, 2008 at 1:50 AM, Sebastian Siewior
<linuxppc-embedded@ml.breakpoint.cc> wrote:
> * Sreen Tallam | 2008-04-09 19:07:01 [-0700]:
>
>
> >VFS: Mounted root (jffs2 filesystem) readonly.
> >Freeing unused kernel memory: 156k init
> >Warning: unable to open an initial console.
> >init/main.c -- 819
> >init/main.c -- 821
> >init/main.c -- 844
> >init/main.c -- 704 -- /sbin/tallam_init<0>Kernel panic - not syncing:
> >Attempted to kill init!
> >Call Trace:
> >[C3FE7E60] [C0006D98] (unreliable)
> >[C3FE7EA0] [C001F150]
> >[C3FE7EF0] [C0023630]
> >[C3FE7F30] [C0023734]
> >[C3FE7F40] [C000DBC0]
> > <0>Rebooting in 180 seconds..
> >
>
> This looks like you are missing /dev/console and probably /dev/null. You
> need atleast those two nodes in your rootfs if you are using udev. You
> will need a static /dev if you don't use udev/mdev.
>
> >Thanks,
> >Sreen
> Sebastian
>
^ permalink raw reply
* Re: [PATCH 2 of 3] [KVM] Add DCR access information to struct kvm_run
From: Josh Boyer @ 2008-04-10 16:47 UTC (permalink / raw)
To: David Gibson; +Cc: kvm-devel, linuxppc-dev, kvm-ppc-devel, Hollis Blanchard
In-Reply-To: <20080408035441.GA18501@localhost.localdomain>
On Tue, 8 Apr 2008 13:54:41 +1000
David Gibson <dwg@au1.ibm.com> wrote:
> On Mon, Apr 07, 2008 at 10:25:32PM -0500, Hollis Blanchard wrote:
> > On Monday 07 April 2008 20:11:28 David Gibson wrote:
> > > On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote:
> > > > 1 file changed, 7 insertions(+)
> > > > include/linux/kvm.h | 7 +++++++
> > > >
> > > >
> > > > Device Control Registers are essentially another address space found on
> > > > PowerPC 4xx processors, analogous to PIO on x86. DCRs are always 32 bits,
> > > > and are identified by a 32-bit number.
> > >
> > > Well... 10-bit, actually.
> >
> > The mtdcrux description in the ppc440x6 user manual says the following:
> >
> > Let the contents of register RA denote a Device Control Register.
> > The contents of GPR[RS] are placed into the designated Device Control
> > Register.
> >
> > I take that to mean that we must worry about 32 bits worth of DCR numbers.
> > Perhaps I should say "no more than" rather than "always".
>
> I think that's less misleading. mtdcrux is very new, anything which
> only has the mtdcr instruction certainly can't take DCR numbers above
> 10 bits, and I would expect that even on chips with mtdcrux the DCR
> bus is probably still only 10-bits, although it could be extended.
http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/C94B06BE313211B887257110006EFFBD/$file/460migrate.pdf
page 4. "DCR Address Space Increased to 32 bits".
I realize that the above is for 460 cores, but I would not be surprised
at all if that shows up in a future 440 core. 440x6 already seems to
be a conglomeration of some of the features 460 has.
josh
^ permalink raw reply
* Re: [PATCH] FCC: fix confused base / offset
From: Scott Wood @ 2008-04-10 16:38 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linuxppc-dev
In-Reply-To: <20080410104655.GH10465@pengutronix.de>
Sascha Hauer wrote:
> See bottom of this mail. The board really is a 8260 based board. Our
> bootloader does not fill in the clock values, so they are hardcoded. I'm
> not very sure about the muram entries because the dpram is organized
> slightly different on the 8260. It has some dedicated FCC space and I
> don't know how to properly encode this in the device tree.
I think the FCC space should just be left out.
>> Does the PHY negotiate OK?
>
> Well I put some printks into the phy_read/write functions so I can say
> that it at least properly talks to the phy.
Do you get a console message indicating that the link came up?
> soc@f0000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> device_type = "soc";
> compatible = "fsl,mpc8272", "fsl,pq2-soc";
Change the 8272 references to 8260.
> // Temporary -- will go away once kernel uses ranges for get_immrbase().
> reg = <f0000000 00053000>;
This can go away now.
> cpm@119c0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
> reg = <119c0 30>;
> ranges;
>
> muram@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 10000>;
>
> data@0 {
> compatible = "fsl,cpm-muram-data";
> reg = <0 2000 8000 800>;
reg should be <0 4000>. Don't include parameter RAM here.
> ethernet@11300 {
ethernet@11320
> device_type = "network";
> compatible = "fsl,mpc8272-fcc-enet",
> "fsl,cpm2-fcc-enet";
> reg = <11320 20 8500 100 113b0 30>;
reg = <11320 20 8500 100 113b0 1>;
> local-mac-address = [ 80 10 20 30 40 50 ];
> interrupts = <21 2>;
interrupts = <21 8>;
-Scott
^ permalink raw reply
* Re: How to pass information from the bootloader to the kernel ?
From: Grant Likely @ 2008-04-10 16:36 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804101751.00618.laurentp@cse-semaphore.com>
On Thu, Apr 10, 2008 at 9:50 AM, Laurent Pinchart
<laurentp@cse-semaphore.com> wrote:
> Hi everybody,
>
> I need to pass a limited amount of information from the boot loader to the
> Linux kernel, such as the boot mode chosen by the user or the last boot
> reason (power up, reset, watchdog, ...).
>
> What is the best way to pass that kind of information from the boot loader to
> the kernel ? Should I use the device tree ?
>
> I thought about populating the chosen node with the data I need. This could
> make sense for the boot mode, but I feel like I would abuse the chosen node
> if I used it to pass other "non user chosen" information.
Using the chosen node should be fine. Just prefix your new properties
with your company name or something so that you don't get namespace
collisions. However, whatever you do; document it first and post your
documentation to the mailing list for review.
Cheers,
g.
>
> Best regards,
>
> --
> Laurent Pinchart
> CSE Semaphore Belgium
>
> Chaussee de Bruxelles, 732A
> B-1410 Waterloo
> Belgium
>
> T +32 (2) 387 42 59
> F +32 (2) 387 42 75
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* How to pass information from the bootloader to the kernel ?
From: Laurent Pinchart @ 2008-04-10 15:50 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
Hi everybody,
I need to pass a limited amount of information from the boot loader to the
Linux kernel, such as the boot mode chosen by the user or the last boot
reason (power up, reset, watchdog, ...).
What is the best way to pass that kind of information from the boot loader to
the kernel ? Should I use the device tree ?
I thought about populating the chosen node with the data I need. This could
make sense for the boot mode, but I feel like I would abuse the chosen node
if I used it to pass other "non user chosen" information.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
From: Sebastian Siewior @ 2008-04-10 15:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <049046C0-900B-449D-AA81-18A023E21C83@kernel.crashing.org>
* Kumar Gala | 2008-04-10 10:33:11 [-0500]:
>>>I also added updating the defconfig to enable the driver by default.
>>I just noticed that commit 049c9d455 renamed the ids. I couldn't find
>>this commit in your git tree. Did you rename the ids in the .dts file
>>(or want me to do this)?
>
>I think they are already in sync am I missing something?
Ah, the .dts has mpc8544* and eloplus* so it should be fine. Just got
confused by the another commit.
>- k
Sebastian
^ permalink raw reply
* Re: patches for 2.6.26
From: Kumar Gala @ 2008-04-10 15:36 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804101720.36975.laurentp@cse-semaphore.com>
On Apr 10, 2008, at 10:20 AM, Laurent Pinchart wrote:
> On Thursday 10 April 2008 16:21, Kumar Gala wrote:
>> Guy's
>>
>> if you have work you want in 2.6.26 related to Freescale PPC's let me
>> know. Ideally you can provide links to the patches in
>> http://patchwork.ozlabs.org/linuxppc/
>
> Could you please add this one ?
>
> fs_enet: Don't call NAPI functions when NAPI is not used.
> http://patchwork.ozlabs.org/linuxppc/patch?id=17055
Jeff Garzik should ack this first. (you'll want to send to netdev and
Jeff).
(also ask him if he want it to go via netdev or ppc tree's).
- k
^ permalink raw reply
* Re: [PATCH v2] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
From: Kumar Gala @ 2008-04-10 15:33 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080410151206.GA21517@www.tglx.de>
On Apr 10, 2008, at 10:12 AM, Sebastian Siewior wrote:
> * Kumar Gala | 2008-04-10 09:46:39 [-0500]:
>
>>> This is a modified entry I found in the documentation for the 8544.
>>>
>>> Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
>>> ---
>>> arch/powerpc/boot/dts/mpc8544ds.dts | 41 +++++++++++++++++++
>>> ++
>>> +++++++++
>>> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 +++++++++
>>> 2 files changed, 54 insertions(+), 0 deletions(-)
>>
>> applied.
> Thank you.
>
>> I also added updating the defconfig to enable the driver by default.
> I just noticed that commit 049c9d455 renamed the ids. I couldn't find
> this commit in your git tree. Did you rename the ids in the .dts file
> (or want me to do this)?
I think they are already in sync am I missing something?
- k
^ permalink raw reply
* Re: [PATCH v2] E500 Make steal_context SMP-safe.
From: Kumar Gala @ 2008-04-10 15:31 UTC (permalink / raw)
To: Randy Vinson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <47F509CC.9010205@mvista.com>
On Apr 3, 2008, at 11:46 AM, Randy Vinson wrote:
> When steal_context is used on SMP systems, it can steal a context in
> use by one of the other processors. This patch adds context tracking
> to
> prevent this as suggested by BenH.
Can we be more descriptive in the problem/bug symptom in the
description.
otherwise this looks ok to me. I'd like BenH to ack as well since
he's been look at this code recently.
>
> Signed-off-by: Randy Vinson <rvinson@mvista.com>
> ---
> The previous version of this patch had some unnecessary code which
> has been
> removed in this version.
>
> Note: This is a proof-of-concept patch. This isn't my area of
> expertise,
> so I'd greatly appreciate any guidance I can get. I'm considering the
> use of for_each_online_cpu() instead of for_each_possible_cpu() and
> possibly putting the changes under a CONFIG_SMP switch to prevent
> unnecessary
> overhead in the non-SMP case.
for_each_online_cpu() is probably better. I'm guessing this optimizes
pretty well in the !CONFIG_SMP case.
- k
^ permalink raw reply
* Re: State of the MPC5200 PSC AC97 driver
From: Matt Sealey @ 2008-04-10 15:25 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev, Sylvain Munaut, spitzauer_77
In-Reply-To: <47FDEF9B.5000506@semihalf.com>
I have a copy of the driver I hacked to work with the new PSC framework
but it doesn't "work" anymore - I have no idea why.
Mail me privately if you want it, I have no time to make patches or
look for a good reason for the breakages, but it compiles at least.
The Efika hack should be gone now (irrelevant since we released a firmware
that obseletes it) and the other fixmes should be by the wayside
considering the fscking thing doesn't play sound anymore...
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Marian Balakowicz wrote:
> Hi Sylvain,
>
> Last year you have posted a MPC5200 PSC AC97 driver patch
> "[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface."
> with the following comment:
>
>> Not quite a clean driver, but it get things done (well, mostly).
>> Only included to be able to test functionalityi/usage of
>> the BestComm driver.
>
> There are various FIXMEs and commented out code here and there.
> Could you elaborate a bit on the overall state of the driver's
> functionality,
> which areas need improvement and attention?
>
> Seems that you mainly tested BestComm with this driver, what was the
> overall
> BestComm performance, any issues here? Did you use any specific test setup
> involving some dedicated application, etc.?
>
> Did anyone else tried it and/or has a updated version or can share
> experience?
>
> Thanks in advance.
>
> Cheers,
> m.
^ 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