* 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
* Re: patches for 2.6.26
From: Laurent Pinchart @ 2008-04-10 15:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <D9A4BB4A-970C-4E9E-9174-BA8C0191CCA2@kernel.crashing.org>
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
--
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
^ permalink raw reply
* RE: Access physical memory via mmap() on ppc440epx.
From: Leonid @ 2008-04-10 15:15 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C033A9D08@ehost011-3.exch011.intermedia.net>
Hi, Josh:
I have double checked, mmap64 doesn't work either. This is the piece of
code which does re-mapping:
unsigned long long StartAddressL =3D 0x100000000ULL | StartAddress;
mmap_addr =3D (unsigned int) mmap64(NULL,=20
size,=20
PROT_READ | PROT_WRITE,
MAP_SHARED,=20
dev_mem_fd,=20
StartAddressL);
While in GDB I can see variables' values:
(gdb) p/x mmap_addr
$1 =3D 0x30028000
(gdb) p/x StartAddressL
No symbol "StartAddressL" in current context.
(gdb) p/x StartAddress
$2 =3D 0xfc240000
(gdb) p/x size
$3 =3D 0x60000
(gdb)
This call returns successfully, but when I stop the board and dump TLB
entries (I have BDI2000 connected) on BDI2000 screen, there is no entry
with this physical address.
However when I also do re-mapping (using ioremap64()) in kernel driver
(physical address is different - 0xea000000), this is the code:
if((mcfp_ebi_baseptr =3D ioremap64 (0x1ea000000ULL, 512)) =3D=3D NULL) {
...
When I stop in debugger right after remapping, TLB entry shows up but
somewhat non-completed yet:
10 : 00 00000000 1KB -0 -> 1_ea000000 U:0000 -I-G- XWRXWR
Later, when I stop board right BEFORE actual accessing memory, the entry
is
present:
23 : 00 d1050000 4KB V0 -> 1_ea000000 U:0000 -IMG- ----WR
And kernel driver is working.
So something is definitely wrong with mmap/mmap64 call itself. Should I
use different parameters?=20
Thanks,
Leonid.
-----Original Message-----
From: linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org] On =
Behalf
Of Leonid
Sent: Wednesday, April 02, 2008 3:51 PM
To: Josh Boyer
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: Access physical memory via mmap() on ppc440epx.
Hi, Josh:
I have resolved my kernel driver problem, it was my own bug, didn't have
anything to do with memory remapping itself. Your suggestion to move to
ioremap64() did resolve problem completely.
I still need investigate mmap() crash. Apparently switch to mmap64()
didn't help, but it could be some another bug, I'll double check.
Thanks,
Leonid.=20
-----Original Message-----
From: linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org] On =
Behalf
Of Leonid
Sent: Tuesday, April 01, 2008 9:30 PM
To: Josh Boyer
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: Access physical memory via mmap() on ppc440epx.
Hi, Josh:
Thank you for your suggestion. Somehow it didn't work with mmap (may be,
my mistake, I'll double check), however it partially helped me with my
another problem.
I have kernel driver where I need read/write some HW device, connected
on address 0xea000000, chip select 4. This chip select configured
properly, here are EBC registers:
440EPx>rd ebc0_b4cr
ebc0_b4cr: 0xea01a000 -368992256
440EPx>rd ebc0_b4ap
ebc0_b4ap: 0x03037000 50556928
>From u-boot I can read/write this address with no problem (I use md/mw
commands).
In my driver I tried to ioremap() this address and any attempt to access
led to crash, same as with mmap().
When, following your suggestion, I used address 0x1ea00000 and
ioremap64(), crashes disappeared!
I even can write, but when I read data back I see least significant byte
of each 16 bits word only (bus is configured 16 bits width).=20
What can it be?
Thanks,
Leonid.=20
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com]
Sent: Tuesday, April 01, 2008 6:44 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Access physical memory via mmap() on ppc440epx.
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>=20
> I am trying to read from NOR flash, located on address 0xfc000000, on
my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>=20
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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