[RFC/PATCH 0/3] Attempt at making 32bit BAT assignment more intelligent
Here is my attempt to make BAT allocations dynamic instead of hard coded. The first patch changes setbat() to dynamically assign BATs instead of requiring the caller to select a BAT on its own. A primary user of setbat is mmu_mapin_ram() which used to hard code BATs 2 and 3 for mapping as much of RAM as can fit in 2 BATs. The first patch changes the routine to try to use as many BATs as it needs to map all of RAM. (Note: I've still got BAT0 reserved for mapping RAM, so even if lots of other users of setbat() appear, RAM is guaranteed to be allocated at least 1 BAT). The first patch also adds an ioremap_bat() function which works like ioremap(), but uses BATs instead of page tables and can be called really early (before MMU_init()). ioremap_bat() mappings persist after MMU_init is called too so it can be used to map all of an SoC's IMMR region, or any other IO device for that matter. I've seen about a 2.5% performance improvement by using this on a simple network workload with SoC registers BAT mapped. The second patch is just a utility function required by the third patch. The third patch is a new user of ioremap_bat() to implement early debug support for the mpc5200 platform. The first patch is the one I really want feedback on. It shouldn't break any 32 bit platforms, but I need testing to make sure. Also, this is my first attempt at messing with MMU code, so please let me know if I'm doing anything foolish or dangerous. Kumar, Josh; I'd appreciate testing to make sure patch 1 doesn't break stuff. Thanks, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Grant Likely [EMAIL PROTECTED]
ioremap_bat() is useful for things like mapping SoC internally memory mapped
register and early text because it allows mappings to devices to be setup
early in the boot process where they are needed, and the mappings persist
after the MMU is configured.
Without ioremap_bat(), setting up the MMU would cause the early text
mappings to get lost and mostly likely result in a kernel panic on the next
attempt at output.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup_32.c |9 ++
arch/powerpc/mm/init_32.c|7 --
arch/powerpc/mm/mmu_decl.h |4 +
arch/powerpc/mm/pgtable_32.c |2 -
arch/powerpc/mm/ppc_mmu_32.c | 148 --
arch/powerpc/sysdev/cpm_common.c |2 -
include/asm-powerpc/pgalloc-32.h |2 +
7 files changed, 140 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 066e65c..7b25b57 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -113,6 +113,15 @@ notrace unsigned long __init early_init(unsigned long
dt_ptr)
*/
notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
{
+ /* Do the bare minimum to start allocting from the IO region so
+* that ioremap_bat() works */
+#ifdef CONFIG_HIGHMEM
+ ioremap_base = PKMAP_BASE;
+#else
+ ioremap_base = 0xfe00UL;/* for now, could be 0xf000 */
+#endif /* CONFIG_HIGHMEM */
+ ioremap_bot = ioremap_base;
+
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 388ceda..a3d9b4e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -169,13 +169,6 @@ void __init MMU_init(void)
ppc_md.progress(MMU:mapin, 0x301);
mapin_ram();
-#ifdef CONFIG_HIGHMEM
- ioremap_base = PKMAP_BASE;
-#else
- ioremap_base = 0xfe00UL;/* for now, could be 0xf000 */
-#endif /* CONFIG_HIGHMEM */
- ioremap_bot = ioremap_base;
-
/* Map in I/O resources */
if (ppc_md.progress)
ppc_md.progress(MMU:setio, 0x302);
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index fab3cfa..5027736 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -29,8 +29,8 @@ extern void hash_preload(struct mm_struct *mm, unsigned long
ea,
#ifdef CONFIG_PPC32
extern void mapin_ram(void);
extern int map_page(unsigned long va, phys_addr_t pa, int flags);
-extern void setbat(int index, unsigned long virt, phys_addr_t phys,
- unsigned int size, int flags);
+extern int setbat(unsigned long virt, phys_addr_t phys,
+ unsigned int size, int flags);
extern void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, int flags, unsigned int pid);
extern void invalidate_tlbcam_entry(int index);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 2001abd..e96f745 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -55,8 +55,6 @@ extern void hash_page_sync(void);
#ifdef HAVE_BATS
extern phys_addr_t v_mapped_by_bats(unsigned long va);
extern unsigned long p_mapped_by_bats(phys_addr_t pa);
-void setbat(int index, unsigned long virt, phys_addr_t phys,
- unsigned int size, int flags);
#else /* !HAVE_BATS */
#define v_mapped_by_bats(x)(0UL)
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index c53145f..62c4603 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -72,41 +72,44 @@ unsigned long p_mapped_by_bats(phys_addr_t pa)
return 0;
}
+/**
+ * mmu_mapin_ram - Map as much of RAM as possible into kernel space using BATs
+ */
unsigned long __init mmu_mapin_ram(void)
{
#ifdef CONFIG_POWER4
return 0;
#else
unsigned long tot, bl, done;
- unsigned long max_size = (25620);
+ int rc;
if (__map_without_bats) {
printk(KERN_DEBUG RAM mapped without BATs\n);
return 0;
}
- /* Set up BAT2 and if necessary BAT3 to cover RAM. */
-
- /* Make sure we don't map a block larger than the
- smallest alignment of the physical address. */
+ /* Set up BATs to cover RAM. */
tot = total_lowmem;
- for (bl = 12810; bl max_size; bl = 1) {
- if (bl * 2 tot)
+ done = 0;
+ while (done tot) {
+ /* determine the smallest block size need to map the region.
+* Don't use a BAT mapping if the remaining region is less
+* that 128k */
+ if (tot - done = 12810)
break;
- }
-
- setbat(2, KERNELBASE, 0, bl, _PAGE_RAM);
- done = (unsigned long)bat_addrs[2].limit -
[RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the node pointed to by the
linux,stdout-path property in the chosen node.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
drivers/of/base.c | 24
include/linux/of.h |1 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..10c6a46 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -473,3 +473,27 @@ int of_modalias_node(struct device_node *node, char
*modalias, int len)
}
EXPORT_SYMBOL_GPL(of_modalias_node);
+/**
+ * of_lookup_stdout - find node pointed to by chosen linux,stdout-path property
+ *
+ * This routine returns a pointer to the stdout node or NULL on failure
+ */
+struct device_node __init *of_lookup_stdout(void)
+{
+ struct device_node *chosen, *stdout_node;
+ const char *stdout_path;
+
+ chosen = of_find_node_by_path(/chosen);
+ if (!chosen)
+ return NULL;
+
+ stdout_path = of_get_property(chosen, linux,stdout-path, NULL);
+ if (!stdout_path) {
+ of_node_put(chosen);
+ return NULL;
+ }
+
+ stdout_node = of_find_node_by_path(stdout_path);
+ of_node_put(chosen);
+ return stdout_node;
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index 79886ad..e8b215b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -71,5 +71,6 @@ extern int of_n_size_cells(struct device_node *np);
extern const struct of_device_id *of_match_node(
const struct of_device_id *matches, const struct device_node *node);
extern int of_modalias_node(struct device_node *node, char *modalias, int len);
+struct device_node __init *of_lookup_stdout(void);
#endif /* _LINUX_OF_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH 3/3] powerpc/52xx: add udbg and early debug support for PSC serial console
From: Grant Likely [EMAIL PROTECTED]
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
arch/powerpc/Kconfig.debug | 11 +++
arch/powerpc/kernel/udbg.c |2
arch/powerpc/platforms/52xx/lite5200.c |6 +
arch/powerpc/platforms/52xx/mpc5200_simple.c |3 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 109 ++
include/asm-powerpc/mpc52xx.h|1
include/asm-powerpc/udbg.h |1
7 files changed, 131 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 8c8aadb..26e12d6 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -210,6 +210,12 @@ config PPC_EARLY_DEBUG_40x
inbuilt serial port. This works on chips with a 16550 compatible
UART. Xilinx chips with uartlite cannot use this option.
+config PPC_EARLY_DEBUG_5200
+ bool MPC5200 PSC serial port
+ depends on PPC_MPC52xx
+ help
+ Select this to enable early debugging for the Freescale MPC5200 SoC.
+
config PPC_EARLY_DEBUG_CPM
bool Early serial debugging for Freescale CPM-based serial ports
depends on SERIAL_CPM
@@ -239,6 +245,11 @@ config PPC_EARLY_DEBUG_40x_PHYSADDR
depends on PPC_EARLY_DEBUG_40x
default 0xef600300
+config PPC_EARLY_DEBUG_5200_PHYSADDR
+ hex Early debug PSC UART physical address
+ depends on PPC_EARLY_DEBUG_5200
+ default 0xf0002000
+
config PPC_EARLY_DEBUG_CPM_ADDR
hex CPM UART early debug transmit descriptor address
depends on PPC_EARLY_DEBUG_CPM
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index 7d6c9bb..a3a0c13 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -57,6 +57,8 @@ void __init udbg_early_init(void)
#elif defined(CONFIG_PPC_EARLY_DEBUG_40x)
/* PPC40x debug */
udbg_init_40x_realmode();
+#elif defined(CONFIG_PPC_EARLY_DEBUG_5200)
+ udbg_init_mpc5200();
#elif defined(CONFIG_PPC_EARLY_DEBUG_CPM)
udbg_init_cpm();
#endif
diff --git a/arch/powerpc/platforms/52xx/lite5200.c
b/arch/powerpc/platforms/52xx/lite5200.c
index 6d584f4..0685c2c 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -25,6 +25,7 @@
#include asm/machdep.h
#include asm/prom.h
#include asm/mpc52xx.h
+#include asm/udbg.h
/*
*
@@ -182,7 +183,8 @@ static int __init lite5200_probe(void)
if (!of_flat_dt_is_compatible(node, fsl,lite5200)
!of_flat_dt_is_compatible(node, fsl,lite5200b))
return 0;
- pr_debug(%s board found\n, model ? model : unknown);
+
+ udbg_printf(%s board found\n, model ? model : unknown);
return 1;
}
@@ -191,9 +193,11 @@ define_machine(lite5200) {
.name = lite5200,
.probe = lite5200_probe,
.setup_arch = lite5200_setup_arch,
+ .init_early = mpc52xx_udbg_init,
.init = mpc52xx_declare_of_platform_devices,
.init_IRQ = mpc52xx_init_irq,
.get_irq= mpc52xx_get_irq,
.restart= mpc52xx_restart,
.calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
};
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c
b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index a3bda0b..16daf9d 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -30,6 +30,7 @@
#include asm/prom.h
#include asm/machdep.h
#include asm/mpc52xx.h
+#include asm/udbg.h
/*
* Setup the architecture
@@ -78,9 +79,11 @@ define_machine(mpc5200_simple_platform) {
.name = mpc5200-simple-platform,
.probe = mpc5200_simple_probe,
.setup_arch = mpc5200_simple_setup_arch,
+ .init_early = mpc52xx_udbg_init,
.init = mpc52xx_declare_of_platform_devices,
.init_IRQ = mpc52xx_init_irq,
.get_irq= mpc52xx_get_irq,
.restart= mpc52xx_restart,
.calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
};
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 4d5fd1d..dcbeb06 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -10,7 +10,7 @@
*
*/
-#undef DEBUG
+#define DEBUG
#include linux/kernel.h
#include linux/spinlock.h
@@ -18,6 +18,18 @@
#include asm/io.h
#include asm/prom.h
#include asm/mpc52xx.h
+#include asm/udbg.h
+#include asm/pgalloc.h
+#include mm/mmu_decl.h
+
+/* Programmable Serial Controller (PSC) status register bits */
+#define MPC52xx_PSC_SR 0x04
+#define MPC52xx_PSC_SR_RXRDY 0x0100
+#define MPC52xx_PSC_SR_RXFULL
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. Nice. You don't feel like converting all the places that currently do it by hand to use this do you :) cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Grant Likely [EMAIL PROTECTED] Date: Wed, 06 Aug 2008 00:02:44 -0600 of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. Signed-off-by: Grant Likely [EMAIL PROTECTED] On sparc platforms this is obtained differently. We obtain the 32-bit instance value of /chosen/stdout and convert that into a prom device node path using instance-to-path. If this of_lookup_stdout() is going into generic OF code, it should be done in a way that works on all platforms. All of these linux,* properties and node names are powerpc platform specific. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. Nice. You don't feel like converting all the places that currently do it by hand to use this do you :) Yep, I'll do this. :-) g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, Aug 6, 2008 at 12:32 AM, David Miller [EMAIL PROTECTED] wrote: From: Grant Likely [EMAIL PROTECTED] Date: Wed, 06 Aug 2008 00:02:44 -0600 of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. Signed-off-by: Grant Likely [EMAIL PROTECTED] On sparc platforms this is obtained differently. We obtain the 32-bit instance value of /chosen/stdout and convert that into a prom device node path using instance-to-path. How about if I modify it to try both methods? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
On Tue, 2008-08-05 at 17:16 +1000, Benjamin Herrenschmidt wrote: On Tue, 2008-08-05 at 16:47 +1200, Paul Collins wrote: It's about four years old. It was in storage for about six months and I got it repaired a few weeks ago (display cable and inverter). The sort of crazy crap I've been reporting certainly smacks of memory corruption. But on the other hand, 2.6.25 (Debian's) and 2.6.26 (my own) have been trouble-free. Any chance you can bisect the problem ? Ok, so I can reproduce on a few 32 bits configs with ftrace enabled. Looks like some non volatile GPRs get corrupted. I don't know yet if ftrace is the culprit though, I couldn't find anything obviously wrong with the mcount implementation we have. It looks like the corrupted GPR has been saved/restored on the stack and that the corruption is due to the stack itself being written to. It's not clear by whome though and in what circumstances. We'll have to dig more. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patches for 2.6.27... (Kumar Gala)
Hello Kumar, On Wed Jul 2 19:58:03 EST 2008 Heiko Schocher wrote: On Wednesday 02 July 2008, Kumar Gala wrote: Please point out any patches that have been posted but havent made it into a git tree related to Freescale chips. Here are 2 patches that I'd like to see in 2.6.27. They haven't made into any git tree as far as I know. http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058118.html http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057972.html Can you tell me, if these patches go into the Tree? I had generally acks for this boards, but didnt see them in any tree yet? Are there some more issues? TIA Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/6] powerpc: update flash size and partition in mpc8272ads dts
Make the flash size 8M to be consistent with the module comes with board.
Add predefined partitions for the flash. Add ethernet port aliases.
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8272ads.dts | 38 +
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index 2a1929a..b2ce4c0 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -17,6 +17,11 @@
#address-cells = 1;
#size-cells = 1;
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ };
+
cpus {
#address-cells = 1;
#size-cells = 0;
@@ -46,15 +51,38 @@
#size-cells = 1;
reg = 0xf0010100 0x40;
- ranges = 0x0 0x0 0xfe00 0x200
+ ranges = 0x0 0x0 0xff80 0x80
0x1 0x0 0xf450 0x8000
0x3 0x0 0xf820 0x8000;
[EMAIL PROTECTED],0 {
- compatible = jedec-flash;
- reg = 0x0 0x0 0x200;
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ probe-type = CFI;
+ reg = 0x0 0x0 0x80;
bank-width = 4;
device-width = 1;
+ [EMAIL PROTECTED] {
+ label = hrcw;
+ reg = 0x0 0x4;
+ };
+ [EMAIL PROTECTED] {
+ label = fs;
+ reg = 0x4 0x54;
+ };
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0x58 0x18;
+ };
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0x70 0x4;
+ };
+ [EMAIL PROTECTED] {
+ label = u-boot-env;
+ reg = 0x74 0x4;
+ };
};
[EMAIL PROTECTED],0 {
@@ -192,7 +220,7 @@
};
};
- [EMAIL PROTECTED] {
+ enet0: [EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc8272-fcc-enet,
fsl,cpm2-fcc-enet;
@@ -205,7 +233,7 @@
fsl,cpm-command = 0x12000300;
};
- [EMAIL PROTECTED] {
+ enet1: [EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc8272-fcc-enet,
fsl,cpm2-fcc-enet;
--
1.5.5.1.248.g4b17
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/6] powerpc: export cpm2_immr symbol for CPM2 drivers to compile as module
Signed-off-by: Li Yang [EMAIL PROTECTED] --- arch/powerpc/sysdev/cpm2.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c index f1c3395..021480e 100644 --- a/arch/powerpc/sysdev/cpm2.c +++ b/arch/powerpc/sysdev/cpm2.c @@ -52,6 +52,7 @@ cpm_cpm2_t __iomem *cpmp; /* Pointer to comm processor space */ * the communication processor devices. */ cpm2_map_t __iomem *cpm2_immr; +EXPORT_SYMBOL(cpm2_immr); #define CPM_MAP_SIZE (0x4) /* 256k - the PQ3 reserve this amount of space for CPM as it is larger -- 1.5.5.1.248.g4b17 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/6] powerpc: update QE/CPM2 headers for USB support
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/include/asm/immap_cpm2.h |9 +++--
arch/powerpc/include/asm/immap_qe.h |9 +++--
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_cpm2.h
b/arch/powerpc/include/asm/immap_cpm2.h
index 4080bab..d4f069b 100644
--- a/arch/powerpc/include/asm/immap_cpm2.h
+++ b/arch/powerpc/include/asm/immap_cpm2.h
@@ -554,14 +554,11 @@ typedef struct usb_ctlr {
u8 usb_usadr;
u8 usb_uscom;
u8 res1[1];
- u16 usb_usep1;
- u16 usb_usep2;
- u16 usb_usep3;
- u16 usb_usep4;
+ __be16 usb_usep[4];
u8 res2[4];
- u16 usb_usber;
+ __be16 usb_usber;
u8 res3[2];
- u16 usb_usbmr;
+ __be16 usb_usbmr;
u8 usb_usbs;
u8 res4[7];
} usb_cpm2_t;
diff --git a/arch/powerpc/include/asm/immap_qe.h
b/arch/powerpc/include/asm/immap_qe.h
index 3c2fced..08d616a 100644
--- a/arch/powerpc/include/asm/immap_qe.h
+++ b/arch/powerpc/include/asm/immap_qe.h
@@ -215,10 +215,7 @@ struct usb_ctlr {
u8 usb_usadr;
u8 usb_uscom;
u8 res1[1];
- __be16 usb_usep1;
- __be16 usb_usep2;
- __be16 usb_usep3;
- __be16 usb_usep4;
+ __be16 usb_usep[4];
u8 res2[4];
__be16 usb_usber;
u8 res3[2];
@@ -472,8 +469,8 @@ extern phys_addr_t get_qe_base(void);
static inline unsigned long immrbar_virt_to_phys(void *address)
{
- if ( ((u32)address = (u32)qe_immr)
- ((u32)address ((u32)qe_immr + QE_IMMAP_SIZE)) )
+ if (((u32)address = (u32)qe_immr)
+ ((u32)address ((u32)qe_immr + QE_IMMAP_SIZE)))
return (unsigned long)(address - (u32)qe_immr +
(u32)get_qe_base());
return (unsigned long)virt_to_phys(address);
--
1.5.5.1.248.g4b17
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/6] powerpc: add USB peripheral support to MPC8272ADS
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8272ads.dts |8
arch/powerpc/platforms/82xx/mpc8272_ads.c | 25 +
arch/powerpc/platforms/82xx/pq2ads.h |3 +++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index b2ce4c0..75cc94c 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -256,6 +256,14 @@
#address-cells = 1;
#size-cells = 0;
};
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,qe_udc;
+ reg = 0x11b60 0x40 0x8b00 0x100;
+ interrupts = 11 8;
+ interrupt-parent = PIC;
+ mode = slave;
+ };
};
PIC: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c
b/arch/powerpc/platforms/82xx/mpc8272_ads.c
index 8054c68..69781e6 100644
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -23,6 +23,7 @@
#include asm/udbg.h
#include asm/machdep.h
#include asm/time.h
+#include asm/fs_pd.h
#include platforms/82xx/pq2.h
@@ -100,11 +101,22 @@ static struct cpm_pin mpc8272_ads_pins[] = {
/* I2C */
{3, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
{3, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
+
+ /* USB */
+ {2, 20, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY}, /* output enable */
+ {2, 11, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, /* RP */
+ {2, 10, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, /* RN */
+ {3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, /* Rxd */
+ {3, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY}, /* TN */
+ {3, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY}, /* TP */
+ {2, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, /* Usb_clk */
};
static void __init init_ioports(void)
{
int i;
+ cpmux_t __iomem *im_cpmux;
+ u32 reg;
for (i = 0; i ARRAY_SIZE(mpc8272_ads_pins); i++) {
struct cpm_pin *pin = mpc8272_ads_pins[i];
@@ -119,6 +131,13 @@ static void __init init_ioports(void)
cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_TX);
cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK15, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK16, CPM_CLK_TX);
+
+ /* USB use clock of SCC3 */
+ cpm2_clk_setup(CPM_CLK_SCC3, CPM_CLK8, CPM_CLK_TX);
+ /* SCC3 cannot be used in NMSI mode */
+ im_cpmux = cpm2_map(im_cpmux);
+ reg = in_be32(im_cpmux-cmx_scr);
+ out_be32(im_cpmux-cmx_scr, reg | CMXSCR_SC3);
}
static void __init mpc8272_ads_setup_arch(void)
@@ -150,6 +169,12 @@ static void __init mpc8272_ads_setup_arch(void)
clrbits32(bcsr[3], BCSR3_FETHIEN2);
setbits32(bcsr[3], BCSR3_FETH2_RST);
+ /* Enabling USB support in BCSR */
+ np = of_find_compatible_node(NULL, NULL, fsl,qe_udc);
+ if (np != NULL) {
+ clrbits32(bcsr[3], BCSR3_USB_EN);
+ clrbits32(bcsr[3], BCSR3_USB_HI_SPEED);
+ }
iounmap(bcsr);
init_ioports();
diff --git a/arch/powerpc/platforms/82xx/pq2ads.h
b/arch/powerpc/platforms/82xx/pq2ads.h
index 984db42..d0e82e2 100644
--- a/arch/powerpc/platforms/82xx/pq2ads.h
+++ b/arch/powerpc/platforms/82xx/pq2ads.h
@@ -43,6 +43,9 @@
#define BCSR1_RS232_EN2((uint)0x0100) /* 0 ==enable */
#define BCSR3_FETHIEN2 ((uint)0x1000) /* 0 == enable*/
#define BCSR3_FETH2_RST((uint)0x8000) /* 0 == reset */
+#define BCSR3_USB_EN ((uint)0x8000)/* 0 == enable*/
+#define BCSR3_USB_HI_SPEED ((uint)0x4000) /* 0 == highspeed */
+#define BCSR3_USBVCC ((uint)0x2000) /* 0 == disable */
/* cpm serial driver works with constants below */
--
1.5.5.1.248.g4b17
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 15 ++-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 19 -
arch/powerpc/platforms/83xx/mpc83xx.h |1 +
arch/powerpc/platforms/83xx/usb.c | 67 +
4 files changed, 100 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index a3b76a7..596377b 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -235,6 +235,17 @@
0 2 1 0 1 0; /* MDC */
};
+ pio_usb: [EMAIL PROTECTED] {
+ pio-map =
+ /* port pin dir open_drain assignment has_irq */
+ 1 2 1 0 3 0/* USBOE */
+ 1 3 1 0 3 0/* USBTP */
+ 1 8 1 0 1 0/* USBTN */
+ 1 10 2 0 3 0/* USBRXD */
+ 1 9 2 1 3 0/* USBRP */
+ 1 11 2 1 3 0; /* USBRN */
+ };
+
};
};
@@ -280,11 +291,13 @@
};
[EMAIL PROTECTED] {
- compatible = qe_udc;
+ compatible = fsl,qe_udc;
reg = 0x6c0 0x40 0x8b00 0x100;
interrupts = 11;
interrupt-parent = qeic;
mode = slave;
+ usb-clock = 21;
+ pio-handle = pio_usb;
};
enet0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 9d46e5b..92afd40 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -93,6 +93,12 @@ static void __init mpc836x_mds_setup_arch(void)
for (np = NULL; (np = of_find_node_by_name(np, ucc)) != NULL;)
par_io_of_config(np);
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe_udc);
+ if (np) {
+ par_io_of_config(np);
+ qe_usb_clock_set(np);
+ }
}
if ((np = of_find_compatible_node(NULL, network, ucc_geth))
@@ -127,9 +133,20 @@ static void __init mpc836x_mds_setup_arch(void)
iounmap(immap);
}
- iounmap(bcsr_regs);
of_node_put(np);
}
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe_udc);
+ if (np != NULL) {
+ /* Set the TESCs run on RGMII mode */
+ bcsr_regs[8] = ~0xf0;
+ /* Enable the USB Device PHY */
+ bcsr_regs[13] = ~0x0f;
+ udelay(1000);
+ bcsr_regs[13] |= 0x05;
+ of_node_put(np);
+ }
+ iounmap(bcsr_regs);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h
b/arch/powerpc/platforms/83xx/mpc83xx.h
index 2a7cbab..d025b47 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -63,5 +63,6 @@ extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
extern int mpc834x_usb_cfg(void);
extern int mpc831x_usb_cfg(void);
+extern int qe_usb_clock_set(struct device_node *np);
#endif /* __MPC83XX_H__ */
diff --git a/arch/powerpc/platforms/83xx/usb.c
b/arch/powerpc/platforms/83xx/usb.c
index cc99c28..3d04ab5 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -18,6 +18,7 @@
#include asm/io.h
#include asm/prom.h
#include sysdev/fsl_soc.h
+#include asm/qe.h
#include mpc83xx.h
@@ -240,3 +241,69 @@ int mpc837x_usb_cfg(void)
return ret;
}
#endif /* CONFIG_PPC_MPC837x */
+
+#ifdef CONFIG_QUICC_ENGINE
+/* QE USB_CLOCK configure functions */
+int qe_usb_clock_set(struct device_node *np)
+{
+ u32 tmpreg = 0;
+ struct qe_mux *qemux = NULL;
+ const int *clock;
+
+ qemux = qe_immr-qmx;
+
+ clock = of_get_property(np, usb-clock, NULL);
+ if (!clock)
+ return -EINVAL;
+
+ /* CLK21 - USBCLK on MPC8360-PB*/
+ tmpreg = in_be32(qemux-cmxgcr) ~QE_CMXGCR_USBCS;
+ switch (*clock) {
+ case 21:
+ tmpreg |= 0x8;
+ out_be32(qemux-cmxgcr, tmpreg);
+ par_io_config_pin(2, 20, 2, 0, 1, 0); /* PC20 for CLK21 */
+ break;
+ case 19:
+ tmpreg |= 0x7;
+ out_be32(qemux-cmxgcr, tmpreg);
+ par_io_config_pin(2, 18, 2, 0, 1, 0); /*
[PATCH 6/6] powerpc: add 82xx platform level support to SEC engine
Initialize base and size of SEC memory region and bus priority for SEC.
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/include/asm/immap_cpm2.h |7 +--
arch/powerpc/platforms/82xx/mpc8272_ads.c |1 +
arch/powerpc/platforms/82xx/pq2.c | 19 +++
arch/powerpc/platforms/82xx/pq2.h |1 +
4 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_cpm2.h
b/arch/powerpc/include/asm/immap_cpm2.h
index d4f069b..71de9d0 100644
--- a/arch/powerpc/include/asm/immap_cpm2.h
+++ b/arch/powerpc/include/asm/immap_cpm2.h
@@ -115,10 +115,13 @@ typedef structmem_ctlr {
u32 memc_immr;
u32 memc_pcibr0;
u32 memc_pcibr1;
- u8 res10[16];
+ u32 secbr;
+ u8 res10[4];
+ u32 secmr;
+ u8 res11[4];
u32 memc_pcimsk0;
u32 memc_pcimsk1;
- u8 res11[52];
+ u8 res12[52];
} memctl_cpm2_t;
/* System Integration Timers.
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c
b/arch/powerpc/platforms/82xx/mpc8272_ads.c
index 69781e6..a98d97c 100644
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -179,6 +179,7 @@ static void __init mpc8272_ads_setup_arch(void)
init_ioports();
pq2_init_pci();
+ pq2_init_sec();
if (ppc_md.progress)
ppc_md.progress(mpc8272_ads_setup_arch(), finish, 0);
diff --git a/arch/powerpc/platforms/82xx/pq2.c
b/arch/powerpc/platforms/82xx/pq2.c
index 1b75902..bacb136 100644
--- a/arch/powerpc/platforms/82xx/pq2.c
+++ b/arch/powerpc/platforms/82xx/pq2.c
@@ -22,6 +22,8 @@
#include platforms/82xx/pq2.h
#define RMR_CSRE 0x0001
+#define PQ2_SECMR_128K 0xfffe
+#define PQ2_ALRH_SEC 0x30126745
void pq2_restart(char *cmd)
{
@@ -35,6 +37,23 @@ void pq2_restart(char *cmd)
panic(Restart failed\n);
}
+void __init pq2_init_sec(void)
+{
+ struct device_node *np = NULL;
+ struct resource res;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,talitos);
+ if (!np)
+ return;
+
+ of_address_to_resource(np, 0, res);
+ printk(KERN_INFO Setting SECBR and SECMR\n);
+ out_be32(cpm2_immr-im_memctl.secbr, (u32)res.start);
+ out_be32(cpm2_immr-im_memctl.secmr, PQ2_SECMR_128K);
+ out_be32(cpm2_immr-im_siu_conf.siu_82xx.sc_ppc_alrh, PQ2_ALRH_SEC);
+ of_node_put(np);
+}
+
#ifdef CONFIG_PCI
static int pq2_pci_exclude_device(struct pci_controller *hose,
u_char bus, u8 devfn)
diff --git a/arch/powerpc/platforms/82xx/pq2.h
b/arch/powerpc/platforms/82xx/pq2.h
index a41f84a..98d3c3c 100644
--- a/arch/powerpc/platforms/82xx/pq2.h
+++ b/arch/powerpc/platforms/82xx/pq2.h
@@ -2,6 +2,7 @@
#define _PQ2_H
void pq2_restart(char *cmd);
+void pq2_init_sec(void);
#ifdef CONFIG_PCI
int pq2ads_pci_init_irq(void);
--
1.5.5.1.248.g4b17
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] net/fs_enet: remove redundant messages for performance
Currently when we do a packet flood to the Ethernet port, the console
reports error every time when a packet is dropped. This is too
redundant and cost performance. Remove message for this type of event.
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
drivers/net/fs_enet/mac-fcc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index 0a97fc2..1c7ef81 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -126,7 +126,7 @@ out:
#define FCC_NAPI_RX_EVENT_MSK (FCC_ENET_RXF | FCC_ENET_RXB)
#define FCC_RX_EVENT (FCC_ENET_RXF)
#define FCC_TX_EVENT (FCC_ENET_TXB)
-#define FCC_ERR_EVENT_MSK (FCC_ENET_TXE | FCC_ENET_BSY)
+#define FCC_ERR_EVENT_MSK (FCC_ENET_TXE)
static int setup_data(struct net_device *dev)
{
--
1.5.5.1.248.g4b17
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Grant Likely [EMAIL PROTECTED] Date: Wed, 6 Aug 2008 00:35:24 -0600 On Wed, Aug 6, 2008 at 12:32 AM, David Miller [EMAIL PROTECTED] wrote: From: Grant Likely [EMAIL PROTECTED] Date: Wed, 06 Aug 2008 00:02:44 -0600 of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. Signed-off-by: Grant Likely [EMAIL PROTECTED] On sparc platforms this is obtained differently. We obtain the 32-bit instance value of /chosen/stdout and convert that into a prom device node path using instance-to-path. How about if I modify it to try both methods? Sure, that would be nice. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Hi Grant, On Wed, 6 Aug 2008 00:34:04 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. Nice. You don't feel like converting all the places that currently do it by hand to use this do you :) Yep, I'll do this. :-) Could you also send an email to Dave Miller to see if he has any objections to this function being generic (since the Sparc guys share this code). -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpyGyJkll8RU.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Stephen Rothwell [EMAIL PROTECTED] Date: Wed, 6 Aug 2008 17:42:33 +1000 Hi Grant, On Wed, 6 Aug 2008 00:34:04 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. Nice. You don't feel like converting all the places that currently do it by hand to use this do you :) Yep, I'll do this. :-) Could you also send an email to Dave Miller to see if he has any objections to this function being generic (since the Sparc guys share this code). I already voiced my concerns. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/6] powerpc: add USB peripheral support to MPC8272ADS
Hi Li,
On Wed, 6 Aug 2008 15:04:43 +0800 Li Yang [EMAIL PROTECTED] wrote:
@@ -150,6 +169,12 @@ static void __init mpc8272_ads_setup_arch(void)
clrbits32(bcsr[3], BCSR3_FETHIEN2);
setbits32(bcsr[3], BCSR3_FETH2_RST);
+ /* Enabling USB support in BCSR */
+ np = of_find_compatible_node(NULL, NULL, fsl,qe_udc);
+ if (np != NULL) {
of_node_put(np);
+ clrbits32(bcsr[3], BCSR3_USB_EN);
+ clrbits32(bcsr[3], BCSR3_USB_HI_SPEED);
+ }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp8ccU0tfaOE.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
Hi Li,
On Wed, 6 Aug 2008 15:04:44 +0800 Li Yang [EMAIL PROTECTED] wrote:
@@ -93,6 +93,12 @@ static void __init mpc836x_mds_setup_arch(void)
for (np = NULL; (np = of_find_node_by_name(np, ucc)) != NULL;)
par_io_of_config(np);
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe_udc);
+ if (np) {
+ par_io_of_config(np);
+ qe_usb_clock_set(np);
of_node_put(np);
+ }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpdR9mfLPshr.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, 6 Aug 2008 17:42:33 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: Could you also send an email to Dave Miller to see if he has any objections to this function being generic (since the Sparc guys share this code). So I should read ahead :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpinAKqgbXKd.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: inline assembly r0 SOS
Kevin Diggs [EMAIL PROTECTED] writes:
Jeremy Kerr wrote:
Hi Kevin,
/*
* Turn r3 (range) into a rotate count for the selected
range. * 0 - 23, 1 - 31
*/
__asm__ __volatile__ ( slwi %0,%0,3\n
addi %0,%0,23\n
rlwnm %0,%1,%0,30,31\n:
=r(ret):
r(config),0(range)
);
Wouldn't this be much simpler in plain C?
I just knew someone was gonna try to rain on my rlwnm'in fun parade!
Wonder if the C code can be made to compile down to 3 instructions?
This will do:
unsigned int get_PLL_range(unsigned int range, unsigned int config)
{
range = range * 8 + 23;
return ((config range) | (config (32 - range))) 3;
}
The special pattern ((a n) | (a (32 - n))) is recognized by gcc as
a rotate operation.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On (05/08/08 10:53), Dave Hansen didst pronounce: On Tue, 2008-08-05 at 17:28 +0100, Mel Gorman wrote: Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it suits this patch. However, I don't see what you gain. By reusing hugetlbfs, we get things like proper reservations which we can do for MAP_PRIVATE these days. Again, we could call that sort of thing directly if the reservation layer was split out separate from hugetlbfs but I still don't see the gain for all that churn. What am I missing? This is good for getting us incremental functionality. It is probably the smallest amount of code to get it functional. I'm not keen on the idea of introducing another specialised path just for stacks. Testing coverage is tricky enough as it is and problems still slip through occasionally. Maybe going through hugetlbfs is less than ideal, but at least it is a shared path. My concern is that we're going down a path that all large page usage should be through the one and only filesystem. Once we establish that dependency, it is going to be awfully hard to undo it; Not much harder than it is to write any alternative in the first place :/ just think of all of the inherent behavior in hugetlbfs. So, we better be sure that the filesystem really is the way to go, especially if we're going to start having other areas of the kernel depend on it internally. So far, it is working out as a decent model. It is able to track reservations and deal with the differences between SHARED and PRIVATE without massive difficulties. While we could add another specialised path to directly insert the pages into pagetables for private mappings, I find it hard to justify adding more test coverage problems. There might be minimal gains to be had in lock granularity but that's about it. That said, this particular patch doesn't appear *too* bound to hugetlb itself. But, some of its limitations *do* come from the filesystem, like its inability to handle VM_GROWS... The lack of VM_GROWSX is an issue, but on its own it does not justify the amount of churn necessary to support direct pagetable insertions for MAP_ANONYMOUS|MAP_PRIVATE. I think we'd need another case or two that would really benefit from direct insertions to pagetables instead of hugetlbfs so that the path would get adequately tested. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kconfig debug help
On Tue, 5 Aug 2008, John Linn wrote: Thanks Josh, I just came to the conclusion it was busted somehow in the mainline after repeating it there. It was fixed in mainline by commit 22127f246dc37ed5bea0915f7860002ba6d87da7 Author: Sam Ravnborg [EMAIL PROTECTED] Date: Mon Aug 4 22:18:07 2008 +0200 kconfig: always write out .config Always write out .config also in the case where config did not change. This fixes: http://bugzilla.kernel.org/show_bug.cgi?id=11230 -Original Message- From: Josh Boyer [mailto:[EMAIL PROTECTED] On Behalf Of Josh Boyer Sent: Tuesday, August 05, 2008 4:49 PM To: John Linn Cc: linuxppc-dev@ozlabs.org Subject: Re: Kconfig debug help On Tue, 2008-08-05 at 15:37 -0600, John Linn wrote: I'm trying to debug some Kconfig problems and am looking for a way to get more debug output. I have used KBUILD_VERBOSE=1 on the command line and it didn't help much. I'm seeing an issue with creating a new defconfig file for a board. I get the .config created, then copy it to a defconfig, and then it doesn't do anything when I run make with the defconfig file. Yeah, I hit that myself this weekend. It's a bug in the Kconfig area. It's 1/2 fixed in the latest Linus and powerpc trees. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis 293-0376800-10 GEBA-BE-BB___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
David Miller writes: On sparc platforms this is obtained differently. We obtain the 32-bit instance value of /chosen/stdout and convert that into a prom device node path using instance-to-path. That's actually exactly what we do too, the linux,stdout-path property is just a cache of the result of that process. The difference is that we have to do it early on while we still have OF around, while you can do it later. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Paul Mackerras [EMAIL PROTECTED] Date: Wed, 6 Aug 2008 20:21:04 +1000 David Miller writes: On sparc platforms this is obtained differently. We obtain the 32-bit instance value of /chosen/stdout and convert that into a prom device node path using instance-to-path. That's actually exactly what we do too, the linux,stdout-path property is just a cache of the result of that process. The difference is that we have to do it early on while we still have OF around, while you can do it later. I do it right when I build the in-kernel OBP tree. Then I cache these results in: extern struct device_node *of_console_device; extern char *of_console_path; extern char *of_console_options; which are declared in asm/prom.h I could compute it even earlier and just store a phandle instead of a device_node pointer. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'for-2.6.27' branch of 4xx tree
Hi Paul, Please grab the tree below. It contains some fixes for the PIKA Warp board, and some much needed defconfig updates for .27. josh The following changes since commit 2e1e9212ed8c532c6b324de77d3cafef5d2bc846: Linus Torvalds (1): Merge git://git.kernel.org/.../lethal/sh-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.27 Josh Boyer (1): powerpc/4xx: Update defconfig files for 2.6.27-rc1 Sean MacLennan (3): powerpc/4xx: Cleanup Warp for i2c driver changes. powerpc/44x: Warp DTS changes for board updates powerpc/44x: Incorrect NOR offset in Warp DTS Valentine Barshak (1): powerpc/44x: Adjust warp-nand resource end address arch/powerpc/boot/dts/warp.dts | 22 ++- arch/powerpc/configs/40x/ep405_defconfig | 207 + arch/powerpc/configs/40x/kilauea_defconfig | 196 + arch/powerpc/configs/40x/makalu_defconfig | 196 + arch/powerpc/configs/40x/walnut_defconfig | 203 + arch/powerpc/configs/44x/bamboo_defconfig | 206 + arch/powerpc/configs/44x/canyonlands_defconfig | 116 +--- arch/powerpc/configs/44x/ebony_defconfig | 207 + arch/powerpc/configs/44x/katmai_defconfig | 259 - arch/powerpc/configs/44x/rainier_defconfig | 207 + arch/powerpc/configs/44x/sam440ep_defconfig| 109 ++-- arch/powerpc/configs/44x/sequoia_defconfig | 207 + arch/powerpc/configs/44x/taishan_defconfig | 208 + arch/powerpc/configs/44x/virtex5_defconfig | 100 +-- arch/powerpc/configs/44x/warp_defconfig| 232 +++- arch/powerpc/configs/ppc40x_defconfig | 374 +++- arch/powerpc/configs/ppc44x_defconfig | 375 ++-- arch/powerpc/platforms/44x/warp-nand.c |2 +- arch/powerpc/platforms/44x/warp.c | 25 +- 19 files changed, 2540 insertions(+), 911 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
Hello Li,
On Wed, Aug 06, 2008 at 03:04:44PM +0800, Li Yang wrote:
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 15 ++-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 19 -
arch/powerpc/platforms/83xx/mpc83xx.h |1 +
arch/powerpc/platforms/83xx/usb.c | 67
+
4 files changed, 100 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index a3b76a7..596377b 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -235,6 +235,17 @@
0 2 1 0 1 0; /* MDC */
};
+ pio_usb: [EMAIL PROTECTED] {
+ pio-map =
+ /* port pin dir open_drain assignment has_irq */
+ 1 2 1 0 3 0/* USBOE */
+ 1 3 1 0 3 0/* USBTP */
+ 1 8 1 0 1 0/* USBTN */
+ 1 10 2 0 3 0/* USBRXD */
+ 1 9 2 1 3 0/* USBRP */
+ 1 11 2 1 3 0; /* USBRN */
+ };
+
};
};
@@ -280,11 +291,13 @@
};
[EMAIL PROTECTED] {
- compatible = qe_udc;
+ compatible = fsl,qe_udc;
You might want to reuse existing bindings as described in
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt.
reg = 0x6c0 0x40 0x8b00 0x100;
interrupts = 11;
interrupt-parent = qeic;
mode = slave;
I'd suggest to rename this to peripheral as we use for fsl dual-role
usb controller.
+ usb-clock = 21;
+ pio-handle = pio_usb;
Can we not introduce new pio maps? The pio setup should be done
by the firmware, or at least fixed up via the board file, as in
arch/powerpc/platforms/83xx/mpc832x_rdb.c.
[...]
+#ifdef CONFIG_QUICC_ENGINE
+/* QE USB_CLOCK configure functions */
+int qe_usb_clock_set(struct device_node *np)
We already have this function, in arch/powerpc/sysdev/qe_lib/usb.c
It does not parse any of properties though, driver should do this.
+{
+ u32 tmpreg = 0;
+ struct qe_mux *qemux = NULL;
+ const int *clock;
+
+ qemux = qe_immr-qmx;
+
+ clock = of_get_property(np, usb-clock, NULL);
+ if (!clock)
+ return -EINVAL;
+
+ /* CLK21 - USBCLK on MPC8360-PB*/
+ tmpreg = in_be32(qemux-cmxgcr) ~QE_CMXGCR_USBCS;
+ switch (*clock) {
+ case 21:
+ tmpreg |= 0x8;
+ out_be32(qemux-cmxgcr, tmpreg);
+ par_io_config_pin(2, 20, 2, 0, 1, 0); /* PC20 for CLK21 */
No, pio config is very board-specific. This should be done by the
firmware (ideally) or by the board file.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH]: [MPC5200] Add ATA DMA support
Hi,
Tim Yamin wrote:
This patch adds MDMA/UDMA support (using BestComm for DMA) on the
MPC5200 platform.
Based heavily on previous work by Freescale (Bernard Kuhn, John
Rigby) and Domen Puncer.
Using a SanDisk Extreme IV CF card I get read speeds of approximately
26.70 MB/sec.
The BestComm ATA task priority was changed to maximum in
bestcomm_priv.h; this fixes a deadlock issue I was experiencing when
heavy DMA was occuring on both the ATA and Ethernet BestComm tasks,
e.g. when downloading a large file over a LAN to disk.
There's also what I believe to be a hardware bug if you have high
levels of BestComm ATA DMA activity along with heavy LocalPlus Bus
activity; the address bus seems to sometimes get corrupted with ATA
commands while the LocalPlus Bus operation is still active (i.e. Chip
Select is asserted).
I've asked Freescale about this but have not received a reply yet --
if anybody from Freescale has any ideas please contact me; I can
supply some analyzer traces if needed. Therefore, for now, do not
enable DMA if you need reliable LocalPlus Bus unless you do a fixup
in your driver as follows:
Locking example:
while (test_and_set_bit(0, pata_mpc52xx_ata_dma_lock) != 0)
{
struct bcom_task_2 *tsk = pata_mpc52xx_ata_dma_task;
if(bcom_buffer_done_2(tsk))
return 1;
}
return 0;
(Save the return value to `flags`)
Unlocking example:
if(flags == 0)
clear_bit(0, pata_mpc52xx_ata_dma_lock);
Comments and testing would of course be very welcome.
Thanks,
Signed-off-by: Tim Yamin [EMAIL PROTECTED]
Sorry for testing this patch so late, but I get these if I apply your
patch to 2.6.24.7 and use it with my Sandisk Extreme IV 4GB card:
...
[0.999514] ata: MPC52xx IDE/ATA libata driver
[1.00] scsi0 : mpc52xx_ata
[1.010969] ata1: PATA max UDMA/33 ata_regs 0xf0003a00 irq 135
[1.168588] ata1.00: CFA: SanDisk SDCFX3-4096, HDX 4.31, max MWDMA2
[1.175156] ata1.00: 8027712 sectors, multi 0: LBA
[1.181098] ata1.00: configured for MWDMA2
[1.196589] scsi 0:0:0:0: Direct-Access ATA SanDisk SDCFX3-4
HDX PQ: 0 ANSI: 5
[1.206949] sd 0:0:0:0: [sda] 8027712 512-byte hardware sectors (4110
MB)
[1.214281] sd 0:0:0:0: [sda] Write Protect is off
[1.219803] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[1.230407] sd 0:0:0:0: [sda] 8027712 512-byte hardware sectors (4110
MB)
[1.237678] sd 0:0:0:0: [sda] Write Protect is off
[1.243129] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[1.252684] sda:3ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2 frozen
[ 31.260361] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0
dma 4096 in
[ 31.260377] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 31.275689] ata1.00: status: { DRDY }
[ 31.279545] ata1: soft resetting link
[ 31.435535] ata1.00: configured for MWDMA2
[ 31.439933] ata1: EH complete
[ 61.443060] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 61.450451] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0
dma 4096 in
[ 61.450467] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 61.465777] ata1.00: status: { DRDY }
[ 61.469632] ata1: soft resetting link
[ 61.625541] ata1.00: configured for MWDMA2
[ 61.629938] ata1: EH complete
...
[ 363.394140] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 363.401534] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0
dma 4096 in
[ 363.401550] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 363.416889] ata1.00: status: { DRDY }
[ 363.420717] ata1: soft resetting link
[ 363.576538] ata1.00: configured for MWDMA1
[ 363.580927] sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
[ 363.587499] sd 0:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
[ 363.594157] Descriptor sense data with sense descriptors (in hex):
[ 363.600593] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 363.607248] 00 00 00 00
[ 363.610615] sd 0:0:0:0: [sda] ASC=0x0 ASCQ=0x0
[ 363.615334] end_request: I/O error, dev sda, sector 0
[ 363.620600] Buffer I/O error on device sda, logical block 0
[ 363.626475] unable to read partition table
[ 363.631014] ata1: EH complete
[ 363.635081] sd 0:0:0:0: [sda] Attached SCSI removable disk
And if I boot via NFS, the kernel can continue to boot after that point.
With a non-DMA card everything is fine.
Best regards,
Daniel.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: [MPC5200] Add ATA DMA support
On Wed, Aug 6, 2008 at 12:58 PM, Daniel Schnell [EMAIL PROTECTED] wrote: Hi, Sorry for testing this patch so late, but I get these if I apply your patch to 2.6.24.7 and use it with my Sandisk Extreme IV 4GB card: Hi, What board are you using? DMA requires a few more signals to be routed through correctly to the CF card slot so maybe that's your problem... Tim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unconditional link object arch/powerpc/lib/crtsavres.o breaks module build
Sam, please have a look at bug 11143. http://bugzilla.kernel.org/show_bug.cgi?id=11143 arch/powerpc/lib/crtsavres.o is added inconditionally to the linker flags, but there is no rule to actually create the object file. This breaks building external modules on 32bit powerpc since 2.6.26. Thanks, Olaf ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc update for in-kernel version
So we asked about this a while ago and I haven't seen anything yet, but is there going to be an update to the version of DTC that is in the kernel tree? 1.2 is out now, would be a good idea to update soon. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH]: Remove bogons from the iSeries console
The iSeries driver calls into the n_tty ldisc code directly for some bizarre reason. I previously tagged this with a query but this actually does need fixing as n_tty methods when you have a different ldisc set are not a good thing to call. In n_tty mode this change should have no effect, the core tty layer has always called the ldisc ioctl method *anyway* and will call the one for the right ldisc. Signed-off-by: Alan Cox [EMAIL PROTECTED] --- drivers/char/viocons.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/char/viocons.c b/drivers/char/viocons.c index 65fb848..f48892b 100644 --- a/drivers/char/viocons.c +++ b/drivers/char/viocons.c @@ -705,10 +705,6 @@ static int viotty_ioctl(struct tty_struct *tty, struct file *file, case KDSKBLED: return 0; } - /* FIXME: WTF is this being called for ??? */ - lock_kernel(); - ret = n_tty_ioctl(tty, file, cmd, arg); - unlock_kernel(); return ret; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH]: [MPC5200] Add ATA DMA support
Tim Yamin wrote: On Wed, Aug 6, 2008 at 12:58 PM, Daniel Schnell [EMAIL PROTECTED] wrote: Hi, Sorry for testing this patch so late, but I get these if I apply your patch to 2.6.24.7 and use it with my Sandisk Extreme IV 4GB card: Hi, What board are you using? DMA requires a few more signals to be routed through correctly to the CF card slot so maybe that's your problem... Hi, We are using our own MPC5200B based board. Can you be a bit more specific about which signals have to be routed ? Best regards, Daniel Schnell. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc update for in-kernel version
On Aug 6, 2008, at 7:43 AM, Josh Boyer wrote: So we asked about this a while ago and I haven't seen anything yet, but is there going to be an update to the version of DTC that is in the kernel tree? 1.2 is out now, would be a good idea to update soon. is there any reason to update to 1.2 for 2.6.27? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2 V3] powerpc - Make the irq reverse mapping tree lockless
Hi , here is V3 for the powerpc IRQ radix tree reverse mapping rework. V2 - V3: from comments by Benjamin Herrenschmidt and Daniel Walker - Move the initialization of the radix tree back into irq_late_init() and insert pre-existing irqs into the tree at that time. - One whitespace cleanup. V1 - V2: from comments by Michael Ellerman - Initialize the XICS radix tree in xics code and only for that irq_host rather than doing it for all the hosts in the powerpc irq generic code (although the hosts list only contain one entry at the moment). - Add a comment in irq_radix_revmap_lookup() stating why it is safe to perform a lookup even if the radix tree has not been initialized yet. The goal of this patchset is to simplify the locking constraints on the radix tree used for IRQ reverse mapping on the pSeries machines and provide lockless access to this tree. This also solves the following BUG under preempt-rt: BUG: sleeping function called from invalid context swapper(1) at kernel/rtmutex.c:739 in_atomic():1 [0002], irqs_disabled():1 Call Trace: [c001e20f3340] [c0010370] .show_stack+0x70/0x1bc (unreliable) [c001e20f33f0] [c0049380] .__might_sleep+0x11c/0x138 [c001e20f3470] [c02a2f64] .__rt_spin_lock+0x3c/0x98 [c001e20f34f0] [c00c3f20] .kmem_cache_alloc+0x68/0x184 [c001e20f3590] [c0193f3c] .radix_tree_node_alloc+0xf0/0x144 [c001e20f3630] [c0195190] .radix_tree_insert+0x18c/0x2fc [c001e20f36f0] [c000c710] .irq_radix_revmap+0x1a4/0x1e4 [c001e20f37b0] [c003b3f0] .xics_startup+0x30/0x54 [c001e20f3840] [c008b864] .setup_irq+0x26c/0x370 [c001e20f38f0] [c008ba68] .request_irq+0x100/0x158 [c001e20f39a0] [c01ee9c0] .hvc_open+0xb4/0x148 [c001e20f3a40] [c01d72ec] .tty_open+0x200/0x368 [c001e20f3af0] [c00ce928] .chrdev_open+0x1f4/0x25c [c001e20f3ba0] [c00c8bf0] .__dentry_open+0x188/0x2c8 [c001e20f3c50] [c00c8dec] .do_filp_open+0x50/0x70 [c001e20f3d70] [c00c8e8c] .do_sys_open+0x80/0x148 [c001e20f3e20] [c000928c] .init_post+0x4c/0x100 [c001e20f3ea0] [c03c0e0c] .kernel_init+0x428/0x478 [c001e20f3f90] [c0027448] .kernel_thread+0x4c/0x68 The root cause of this bug lies in the fact that the XICS interrupt controller uses a radix tree for its reverse irq mapping and that we cannot allocate the tree nodes (even GFP_ATOMIC) with preemption disabled. In fact, we have 2 nested preemption disabling when we want to allocate a new node: - setup_irq() does a spin_lock_irqsave() before calling xics_startup() which then calls irq_radix_revmap() to insert a new node in the tree - irq_radix_revmap() also does a spin_lock_irqsave() (in irq_radix_wrlock()) before the radix_tree_insert() Also, if an IRQ gets registered before the tree is initialized (namely the IPI), it will be inserted into the tree in interrupt context once the tree have been initialized, hence the need for a spin_lock_irqsave() in the insertion path. This serie is split into 2 patches: - The first patch splits irq_radix_revmap() into its 2 components: one for lookup and one for insertion into the radix tree and moves the insertion of pre-existing irq into the tree at irq_late_init() time. - The second patch makes the radix tree fully lockless on the lookup side. Here is the diffstat for the whole patchset: arch/powerpc/include/asm/irq.h| 19 - arch/powerpc/kernel/irq.c | 148 ++-- arch/powerpc/platforms/pseries/xics.c | 11 +-- 3 files changed, 85 insertions(+), 93 deletions(-) Thanks, Sebastien. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc - Separate the irq radix tree insertion and lookup
irq_radix_revmap() currently serves 2 purposes, irq mapping lookup
and insertion which happen in interrupt and process context respectively.
Separate the function into its 2 components, one for lookup only and one
for insertion only.
Fix the only user of the revmap tree (XICS) to use the new functions.
Also, move the insertion into the radix tree of those irqs that were
requested before it was initialized at said tree initialization.
Mutual exclusion between the tree initialization and readers/writers is
handled via an atomic variable (revmap_trees_allocated) set when the tree
has been initialized and checked before any reader or writer access just
like we used to check for tree.gfp_mask != 0 before.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/include/asm/irq.h| 18 ++-
arch/powerpc/kernel/irq.c | 76 -
arch/powerpc/platforms/pseries/xics.c | 11 ++---
3 files changed, 74 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index a372f76..0a51376 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -236,15 +236,27 @@ extern unsigned int irq_find_mapping(struct irq_host
*host,
extern unsigned int irq_create_direct_mapping(struct irq_host *host);
/**
- * irq_radix_revmap - Find a linux virq from a hw irq number.
+ * irq_radix_revmap_insert - Insert a hw irq to linux virq number mapping.
+ * @host: host owning this hardware interrupt
+ * @virq: linux irq number
+ * @hwirq: hardware irq number in that host space
+ *
+ * This is for use by irq controllers that use a radix tree reverse
+ * mapping for fast lookup.
+ */
+extern void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
+ irq_hw_number_t hwirq);
+
+/**
+ * irq_radix_revmap_lookup - Find a linux virq from a hw irq number.
* @host: host owning this hardware interrupt
* @hwirq: hardware irq number in that host space
*
* This is a fast path, for use by irq controller code that uses radix tree
* revmaps
*/
-extern unsigned int irq_radix_revmap(struct irq_host *host,
-irq_hw_number_t hwirq);
+extern unsigned int irq_radix_revmap_lookup(struct irq_host *host,
+ irq_hw_number_t hwirq);
/**
* irq_linear_revmap - Find a linux virq from a hw irq number.
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index d972dec..dc8663a 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -441,6 +441,7 @@ static LIST_HEAD(irq_hosts);
static DEFINE_SPINLOCK(irq_big_lock);
static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
static unsigned int irq_radix_writer;
+static atomic_t revmap_trees_allocated = ATOMIC_INIT(0);
struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
static struct irq_host *irq_default_host;
@@ -822,7 +823,7 @@ void irq_dispose_mapping(unsigned int virq)
break;
case IRQ_HOST_MAP_TREE:
/* Check if radix tree allocated yet */
- if (host-revmap_data.tree.gfp_mask == 0)
+ if (atomic_read(revmap_trees_allocated) == 0)
break;
irq_radix_wrlock(flags);
radix_tree_delete(host-revmap_data.tree, hwirq);
@@ -875,43 +876,55 @@ unsigned int irq_find_mapping(struct irq_host *host,
EXPORT_SYMBOL_GPL(irq_find_mapping);
-unsigned int irq_radix_revmap(struct irq_host *host,
- irq_hw_number_t hwirq)
+unsigned int irq_radix_revmap_lookup(struct irq_host *host,
+irq_hw_number_t hwirq)
{
- struct radix_tree_root *tree;
struct irq_map_entry *ptr;
- unsigned int virq;
+ unsigned int virq = NO_IRQ;
unsigned long flags;
WARN_ON(host-revmap_type != IRQ_HOST_MAP_TREE);
- /* Check if the radix tree exist yet. We test the value of
-* the gfp_mask for that. Sneaky but saves another int in the
-* structure. If not, we fallback to slow mode
+ /*
+* Check if the radix tree exist yet.
+* If not, we fallback to slow mode
*/
- tree = host-revmap_data.tree;
- if (tree-gfp_mask == 0)
+ if (atomic_read(revmap_trees_allocated) == 0)
return irq_find_mapping(host, hwirq);
/* Now try to resolve */
irq_radix_rdlock(flags);
- ptr = radix_tree_lookup(tree, hwirq);
+ ptr = radix_tree_lookup(host-revmap_data.tree, hwirq);
irq_radix_rdunlock(flags);
/* Found it, return */
- if (ptr) {
+ if (ptr)
virq = ptr - irq_map;
- return virq;
- }
- /* If not there,
[PATCH 2/2] powerpc - Make the irq reverse mapping radix tree lockless
The radix trees used by interrupt controllers for their irq reverse mapping
(currently only the XICS found on pSeries) have a complex locking scheme
dating back to before the advent of the lockless radix tree.
Take advantage of this and of the fact that the items of the tree are
pointers to a static array (irq_map) elements which can never go under us
to simplify the locking.
Concurrency between readers and writers is handled by the intrinsic
properties of the lockless radix tree. Concurrency between writers is handled
with a spinlock added to the irq_host structure.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/include/asm/irq.h |1 +
arch/powerpc/kernel/irq.c | 74 ++--
2 files changed, 12 insertions(+), 63 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 0a51376..72fd036 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -119,6 +119,7 @@ struct irq_host {
} linear;
struct radix_tree_root tree;
} revmap_data;
+ spinlock_t tree_lock;
struct irq_host_ops *ops;
void*host_data;
irq_hw_number_t inval_irq;
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index dc8663a..7a19103 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -439,8 +439,6 @@ void do_softirq(void)
static LIST_HEAD(irq_hosts);
static DEFINE_SPINLOCK(irq_big_lock);
-static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
-static unsigned int irq_radix_writer;
static atomic_t revmap_trees_allocated = ATOMIC_INIT(0);
struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
@@ -584,57 +582,6 @@ void irq_set_virq_count(unsigned int count)
irq_virq_count = count;
}
-/* radix tree not lockless safe ! we use a brlock-type mecanism
- * for now, until we can use a lockless radix tree
- */
-static void irq_radix_wrlock(unsigned long *flags)
-{
- unsigned int cpu, ok;
-
- spin_lock_irqsave(irq_big_lock, *flags);
- irq_radix_writer = 1;
- smp_mb();
- do {
- barrier();
- ok = 1;
- for_each_possible_cpu(cpu) {
- if (per_cpu(irq_radix_reader, cpu)) {
- ok = 0;
- break;
- }
- }
- if (!ok)
- cpu_relax();
- } while(!ok);
-}
-
-static void irq_radix_wrunlock(unsigned long flags)
-{
- smp_wmb();
- irq_radix_writer = 0;
- spin_unlock_irqrestore(irq_big_lock, flags);
-}
-
-static void irq_radix_rdlock(unsigned long *flags)
-{
- local_irq_save(*flags);
- __get_cpu_var(irq_radix_reader) = 1;
- smp_mb();
- if (likely(irq_radix_writer == 0))
- return;
- __get_cpu_var(irq_radix_reader) = 0;
- smp_wmb();
- spin_lock(irq_big_lock);
- __get_cpu_var(irq_radix_reader) = 1;
- spin_unlock(irq_big_lock);
-}
-
-static void irq_radix_rdunlock(unsigned long flags)
-{
- __get_cpu_var(irq_radix_reader) = 0;
- local_irq_restore(flags);
-}
-
static int irq_setup_virq(struct irq_host *host, unsigned int virq,
irq_hw_number_t hwirq)
{
@@ -789,7 +736,6 @@ void irq_dispose_mapping(unsigned int virq)
{
struct irq_host *host;
irq_hw_number_t hwirq;
- unsigned long flags;
if (virq == NO_IRQ)
return;
@@ -825,9 +771,9 @@ void irq_dispose_mapping(unsigned int virq)
/* Check if radix tree allocated yet */
if (atomic_read(revmap_trees_allocated) == 0)
break;
- irq_radix_wrlock(flags);
+ spin_lock(host-tree_lock);
radix_tree_delete(host-revmap_data.tree, hwirq);
- irq_radix_wrunlock(flags);
+ spin_unlock(host-tree_lock);
break;
}
@@ -881,7 +827,6 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
{
struct irq_map_entry *ptr;
unsigned int virq = NO_IRQ;
- unsigned long flags;
WARN_ON(host-revmap_type != IRQ_HOST_MAP_TREE);
@@ -893,9 +838,11 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
return irq_find_mapping(host, hwirq);
/* Now try to resolve */
- irq_radix_rdlock(flags);
+ /*
+* No rcu_read_lock(ing) needed, the ptr returned can't go under us
+* as it's referencing an entry in the static irq_map table.
+*/
ptr = radix_tree_lookup(host-revmap_data.tree, hwirq);
- irq_radix_rdunlock(flags);
/* Found it, return */
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, Aug 6, 2008 at 4:21 AM, Paul Mackerras [EMAIL PROTECTED] wrote: David Miller writes: On sparc platforms this is obtained differently. We obtain the 32-bit instance value of /chosen/stdout and convert that into a prom device node path using instance-to-path. That's actually exactly what we do too, the linux,stdout-path property is just a cache of the result of that process. The difference is that we have to do it early on while we still have OF around, while you can do it later. It's not what we do with flattened device trees blobs though. In the flattened tree we're not using a /chosen/stdout property, just the linux,stdout-path one. The question that remains is; should there be? Should the dt blobs use /chosen/stdout also? (I'm not familiar enough with real OF to know the answer. I'm assuming that an instance value is not the same as a phandle). g. Paul. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc update for in-kernel version
On Wed, 6 Aug 2008 08:29:30 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 7:43 AM, Josh Boyer wrote: So we asked about this a while ago and I haven't seen anything yet, but is there going to be an update to the version of DTC that is in the kernel tree? 1.2 is out now, would be a good idea to update soon. is there any reason to update to 1.2 for 2.6.27? Probably not at this point in the lifecycle. We brought this up before the merge window opened though, so I'm just wondering what the general plan is. Seems lots of fixes and such are getting put out, but not pulled into the kernel. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. ns16550 nodes get matched if the parent claims simple-bus. If extra stuff needs to be done to use that port, then bad things happen. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
On Aug 6, 2008, at 8:41 AM, Grant Likely wrote: On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/ e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. did they have a fix? ns16550 nodes get matched if the parent claims simple-bus. If extra stuff needs to be done to use that port, then bad things happen. extra stuff.. not sure what you mean. I'm guessing you me other config for the port to work. In my case that isn't the situation. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
On Wed, Aug 06, 2008 at 08:47:29AM -0500, Kumar Gala wrote: On Aug 6, 2008, at 8:41 AM, Grant Likely wrote: On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/ e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. did they have a fix? Yes, they added code to check another property. If the reg-shift or reg-offset properties were present, then it didn't try to use the port ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: Remove bogons from the iSeries console
Hi Alan, On Wed, 6 Aug 2008 14:06:29 +0100 Alan Cox [EMAIL PROTECTED] wrote: The iSeries driver calls into the n_tty ldisc code directly for some bizarre reason. I previously tagged this with a query but this actually does need fixing as n_tty methods when you have a different ldisc set are not a good thing to call. In n_tty mode this change should have no effect, the core tty layer has always called the ldisc ioctl method *anyway* and will call the one for the right ldisc. Signed-off-by: Alan Cox [EMAIL PROTECTED] I will take your word for it as I have no idea. This driver needs to be deprecated anyway (in favour of hcv_iseries). You may consider this Acked-by: Stephen Rothwell [EMAIL PROTECTED] as defacto iSeries maintainer. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp6TXvM1T16D.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 6, 2008, at 1:02 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] ioremap_bat() is useful for things like mapping SoC internally memory mapped register and early text because it allows mappings to devices to be setup early in the boot process where they are needed, and the mappings persist after the MMU is configured. Without ioremap_bat(), setting up the MMU would cause the early text mappings to get lost and mostly likely result in a kernel panic on the next attempt at output. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- why can't we just do this in ioremap itself? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH] Link the bootwrapper as a position-independent executable
Instead we now link the bootwrapper with -pie to get a position-
independent executable, and process the relocations in the dynamic
relocation section that the linker puts into the executable.
Hurray! Looks good, just a few nits...
+ bl .+4
+p_base:mflrr10 /* r10 now points to runtime addr of
p_base */
bl p_base instead?
+10:or. r8,r0,r9/* skip relocation if we don't have both */
beq 3f
Either the code or the comment is wrong -- the code says skip
relocation
if we don't have either.
+ cmpwi r0,22 /* R_PPC_RELATIVE */
+ bne 3f
It would be nice if there was some way to complain (at build time?)
if there are unhandled relocations present. Prevents a lot of headaches
when things go wrong (and they will ;-) )
4: dcbfr0,r9
icbir0,r9
Fix these while you're at it? It's not r0, it's 0.
+ .dynsym : { *(.dynsym) }
+ .dynstr : { *(.dynstr) }
+ .dynamic :
+ {
+__dynamic_start = .;
+*(.dynamic)
+ }
+ .hash : { *(.hash) }
+ .interp : { *(.interp) }
+ .rela.dyn : { *(.rela*) }
Do some of these sections need alignment?
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH]: [MPC5200] Add ATA DMA support
Hi, Daniel Schnell wrote: Tim Yamin wrote: On Wed, Aug 6, 2008 at 12:58 PM, Daniel Schnell [EMAIL PROTECTED] wrote: Hi, Sorry for testing this patch so late, but I get these if I apply your patch to 2.6.24.7 and use it with my Sandisk Extreme IV 4GB card: Hi, What board are you using? DMA requires a few more signals to be routed through correctly to the CF card slot so maybe that's your problem... Hi, We are using our own MPC5200B based board. Can you be a bit more specific about which signals have to be routed ? After checking our schematics with Tim Yamin, we found that our board has not the DMA lines connected. It seems I have to wait some time before I get an updated board and can test UDMA again Sorry for the noise, although this was important for us to know. Best regards, Daniel. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: inline assembly r0 SOS
unsigned int get_PLL_range(unsigned int range, unsigned int config)
{
range = range * 8 + 23;
return ((config range) | (config (32 - range))) 3;
}
The special pattern ((a n) | (a (32 - n))) is recognized by
gcc as
a rotate operation.
It's only valid for 1 = n = 31 though, so for input range 0 or 1.
(*)
If that's the whole range needed, much simpler code is possible...
Segher
(*) or 0x or 0xfffe, but somehow I doubt that was intended.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Big include file move breaks user mode
On Tuesday 05 August 2008, Sean MacLennan wrote: Should include/asm be a link to arch/powerpc/include/asm? The user space headers are provided by your distribution, not by the kernel, so include/asm should be a directory, not a symlink. If you are building your own distro, don't just copy the files but rather use 'make headers_install' to get a sanitized version. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Big include file move breaks user mode
On Wed, 6 Aug 2008 16:51:40 +0200 Arnd Bergmann [EMAIL PROTECTED] wrote: The user space headers are provided by your distribution, not by the kernel, so include/asm should be a directory, not a symlink. If you are building your own distro, don't just copy the files but rather use 'make headers_install' to get a sanitized version. Sorry, I forgot to reply to the list :( Kumar mentioned the make headers_install and I got it working with our build system. So everything is back on track. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6] powerpc: export cpm2_immr symbol for CPM2 drivers to compile as module
On Wed, Aug 06, 2008 at 03:04:41PM +0800, Li Yang wrote: Signed-off-by: Li Yang [EMAIL PROTECTED] --- arch/powerpc/sysdev/cpm2.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c index f1c3395..021480e 100644 --- a/arch/powerpc/sysdev/cpm2.c +++ b/arch/powerpc/sysdev/cpm2.c @@ -52,6 +52,7 @@ cpm_cpm2_t __iomem *cpmp; /* Pointer to comm processor space */ * the communication processor devices. */ cpm2_map_t __iomem *cpm2_immr; +EXPORT_SYMBOL(cpm2_immr); This is uneeded if you'll start using cpm_muram_* functions from include/asm-powerpc/cpm.h. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver
On Wed, Aug 6, 2008 at 2:16 AM, Li Yang [EMAIL PROTECTED] wrote: +/*- + * Mask definitions for usb BD * + **/ +#define QE_SIZEOF_BD sizeof(struct qe_bd) + +#define BD_BUFFER_ARG(bd) (((struct qe_bd *)bd)-buf) +#define BD_BUFFER_CLEAR(bd) out_be32((BD_BUFFER_ARG(bd)), 0); +#define BD_BUFFER(bd) in_be32((BD_BUFFER_ARG(bd))) +#define BD_STATUS_AND_LENGTH_SET(bd, val) out_be32((u32 *)bd, val) +#define BD_STATUS_AND_LENGTH(bd)in_be32((u32 *)bd) +#define BD_BUFFER_SET(bd, buffer) out_be32((BD_BUFFER_ARG(bd)), \ + (u32)(buffer)) Delete all of these. Don't use these silly macros at all. Reference the structure fields directly, and use the in_ and out_ functions directly. Using macros like these encourages unnecessary typecasts. struct qe_bd has been defined, so you should use it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
It's not what we do with flattened device trees blobs though. In the flattened tree we're not using a /chosen/stdout property, just the linux,stdout-path one. The question that remains is; should there be? Should the dt blobs use /chosen/stdout also? (I'm not familiar enough with real OF to know the answer. I'm assuming that an instance value is not the same as a phandle). ihandles and phandles are not the same thing in OF. Since in the flat world we cannot have instances, we should use phandles instead of ihandles for the things in /chosen. I thought we agreed on that already, perhaps I am wrong? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
test - ignore
test - ignore ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely [EMAIL PROTECTED] wrote: From: Grant Likely [EMAIL PROTECTED] of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. I thought linux,stdout-path is deprecated are we're supposed to be using the aliases node instead? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: add SSI-to-DMA properties to Freescale MPC8610 HPCD device tree
Add the fsl,playback-dma and fsl,capture-dma properties to the Freescale
MPC8610 HPCD device tree. These properties connect the SSI nodes to the
DMA nodes for the DMA channels that the SSI should use. Also update the
ssi.txt documentation.
These properties will be needed when the ASoC V2 version of the Freescale
MPC8610 device drivers are merged into the mainline.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Documentation/powerpc/dts-bindings/fsl/ssi.txt | 15 +++
arch/powerpc/boot/dts/mpc8610_hpcd.dts |8 +---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
index d100555..5d98413 100644
--- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
@@ -24,6 +24,12 @@ Required properties:
rj-master - r.j., SSI is clock master
ac97-slave - AC97 mode, SSI is clock slave
ac97-master - AC97 mode, SSI is clock master
+- fsl,playback-dma: phandle to a DMA node for the DMA channel to use for
+ playback of audio. This is typically dictated by SOC
+ design. See the notes below.
+- fsl,capture-dma: phandle to a DMA node for the DMA channel to use for
+ capture (recording) of audio. This is typically dictated
+ by SOC design. See the notes below.
Optional properties:
- codec-handle : phandle to a 'codec' node that defines an audio
@@ -36,3 +42,12 @@ Child 'codec' node required properties:
Child 'codec' node optional properties:
- clock-frequency : The frequency of the input clock, which typically
comes from an on-board dedicated oscillator.
+
+Notes on fsl,playback-dma and fsl,capture-dma:
+
+On SOCs that have an SSI, specific DMA channels are hard-wired for playback
+and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for
+playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for
+playback and DMA channel 3 for capture. The developer can choose which
+DMA controller to use, but the channels themselves are hard-wired. The
+purpose of these two properties is to represent this hardware design.
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 666185f..2a2b84f 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -202,7 +202,7 @@
fsl,has-rstcr;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
compatible = fsl,mpc8610-ssi;
cell-index = 0;
reg = 0x16000 0x100;
@@ -210,6 +210,8 @@
interrupts = 62 2;
fsl,mode = i2s-slave;
codec-handle = cs4270;
+ fsl,playback-dma = dma00;
+ fsl,capture-dma = dma01;
};
[EMAIL PROTECTED] {
@@ -228,7 +230,7 @@
reg = 0x21300 0x4; /* DMA general status register */
ranges = 0x0 0x21100 0x200;
- [EMAIL PROTECTED] {
+ dma00: [EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
fsl,eloplus-dma-channel;
cell-index = 0;
@@ -236,7 +238,7 @@
interrupt-parent = mpic;
interrupts = 20 2;
};
- [EMAIL PROTECTED] {
+ dma01: [EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
fsl,eloplus-dma-channel;
cell-index = 1;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: Remove bogons from the iSeries console
On Thu, Aug 07, 2008 at 12:10:06AM +1000, Stephen Rothwell wrote: Hi Alan, On Wed, 6 Aug 2008 14:06:29 +0100 Alan Cox [EMAIL PROTECTED] wrote: The iSeries driver calls into the n_tty ldisc code directly for some bizarre reason. I previously tagged this with a query but this actually does need fixing as n_tty methods when you have a different ldisc set are not a good thing to call. In n_tty mode this change should have no effect, the core tty layer has always called the ldisc ioctl method *anyway* and will call the one for the right ldisc. Signed-off-by: Alan Cox [EMAIL PROTECTED] I will take your word for it as I have no idea. This driver needs to be deprecated anyway (in favour of hcv_iseries). ... You already marked it as Obsolete more than 2 years ago, and due the kconfig dependencies most people anyway won't even see the option (since they have HVC_ISERIES enabled). IMHO a candidate for a straight removal? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Segher Boessenkool wrote: It's not what we do with flattened device trees blobs though. In the flattened tree we're not using a /chosen/stdout property, just the linux,stdout-path one. The question that remains is; should there be? Should the dt blobs use /chosen/stdout also? (I'm not familiar enough with real OF to know the answer. I'm assuming that an instance value is not the same as a phandle). The difference between a phandle and an ihandle is similar to the difference between (the inode of) an executable files on disk and (the process id of) a running process. A phandle refers to the static information that describes a device, while an ihandle refers to a particular (out of potentially several) active instantiation of the OFW driver for that devices. An instance value is a data item that can have a different value for each of the running instances of a given driver. In the analogy, an instance value is like a data segment variable. Given an ihandle, you can get the corresponding phandle with ihandlephandle. You can't go from phandle to ihandle, because that direction is one-to-many. Why you you ever need more than one running instance of a given driver? For leaf devices, it is pretty rare to have multiple instances. Multiple instances are more often used for intermediate nodes. The same intermediate node - for example a usb node - is often the parent of several leaf nodes that are active simultaneously. When you open a device, its device tree parents up to the root are implicitly opened. Each such instance can hold dynamic state on behalf of its children. ihandles and phandles are not the same thing in OF. Since in the flat world we cannot have instances, we should use phandles instead of ihandles for the things in /chosen. I thought we agreed on that already, perhaps I am wrong? Segher ___ devicetree-discuss mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/6] powerpc: add USB peripheral support to MPC8272ADS
On Wed, Aug 06, 2008 at 03:04:43PM +0800, Li Yang wrote:
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8272ads.dts |8
arch/powerpc/platforms/82xx/mpc8272_ads.c | 25 +
arch/powerpc/platforms/82xx/pq2ads.h |3 +++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index b2ce4c0..75cc94c 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -256,6 +256,14 @@
#address-cells = 1;
#size-cells = 0;
};
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,qe_udc;
fsl,mpc8272-usb, fsl,cpm2-usb.
Where is fsl,qe_udc documented or used (other than in the BCSR setup)?
What does udc mean (the only reference to it in the 8272 manual is
under ATM)?
+ mode = slave;
Please document this property.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] powerpc: add 82xx platform level support to SEC engine
On Wed, Aug 06, 2008 at 03:04:45PM +0800, Li Yang wrote:
diff --git a/arch/powerpc/platforms/82xx/pq2.c
b/arch/powerpc/platforms/82xx/pq2.c
index 1b75902..bacb136 100644
--- a/arch/powerpc/platforms/82xx/pq2.c
+++ b/arch/powerpc/platforms/82xx/pq2.c
@@ -22,6 +22,8 @@
#include platforms/82xx/pq2.h
#define RMR_CSRE 0x0001
+#define PQ2_SECMR_128K 0xfffe
+#define PQ2_ALRH_SEC 0x30126745
void pq2_restart(char *cmd)
{
@@ -35,6 +37,23 @@ void pq2_restart(char *cmd)
panic(Restart failed\n);
}
+void __init pq2_init_sec(void)
+{
+ struct device_node *np = NULL;
+ struct resource res;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,talitos);
This is an obsolete binding.
See Documentation/powerpc/dts-bindings/fsl/sec.txt.
+ if (!np)
+ return;
+
+ of_address_to_resource(np, 0, res);
+ printk(KERN_INFO Setting SECBR and SECMR\n);
This is an unnecessary printk().
+ out_be32(cpm2_immr-im_memctl.secbr, (u32)res.start);
+ out_be32(cpm2_immr-im_memctl.secmr, PQ2_SECMR_128K);
+ out_be32(cpm2_immr-im_siu_conf.siu_82xx.sc_ppc_alrh, PQ2_ALRH_SEC);
Please put some comments here explaining what you're doing, such as
/* Map the SEC registers */, and /* Lower the SEC arbitration priority */.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
On Wed, Aug 06, 2008 at 03:04:44PM +0800, Li Yang wrote:
[EMAIL PROTECTED] {
- compatible = qe_udc;
+ compatible = fsl,qe_udc;
[snip]
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe_udc);
+ if (np) {
+ par_io_of_config(np);
+ qe_usb_clock_set(np);
+ }
What about existing device trees in use?
+ printk(KERN_ERR Unsupport usb-clock input pin\n);
s/Unsupport/Unsupported/
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote: On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. ns16550 nodes get matched if the parent claims simple-bus. If extra stuff needs to be done to use that port, then bad things happen. If extra stuff needs to be done, it shouldn't claim to be a simple-bus. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
The problem (in my case) is that the legacy-serial driver doesn't accept all of the 16550 configurations accepted by the regular ns16550 driver. The problem is not related to simple-bus, but only became visible when simple-bus bindings are used because the legacy-serial driver specifically looks for an ns16550 node contained by a simple-bus. Most likely the hpcn_defconfig disables the legacy-serial driver altogether. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Scott Wood Sent: Wednesday, August 06, 2008 10:36 AM To: [EMAIL PROTECTED] Cc: ppc-dev list Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote: On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. ns16550 nodes get matched if the parent claims simple-bus. If extra stuff needs to be done to use that port, then bad things happen. If extra stuff needs to be done, it shouldn't claim to be a simple-bus. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Big include file move breaks user mode
Hi, Sean MacLennan wrote: On Wed, 6 Aug 2008 16:51:40 +0200 Arnd Bergmann [EMAIL PROTECTED] wrote: The user space headers are provided by your distribution, not by the kernel, so include/asm should be a directory, not a symlink. If you are building your own distro, don't just copy the files but rather use 'make headers_install' to get a sanitized version. Sorry, I forgot to reply to the list :( Kumar mentioned the make headers_install and I got it working with our build system. So everything is back on track. Heh, you might also consider using off the shelf build systems, such as the T2 SDE: http://t2-project.org To avoid re-inventing the wheel again and again. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Big include file move breaks user mode
Hi, Sean MacLennan wrote: On Wed, 6 Aug 2008 16:51:40 +0200 Arnd Bergmann [EMAIL PROTECTED] wrote: The user space headers are provided by your distribution, not by the kernel, so include/asm should be a directory, not a symlink. If you are building your own distro, don't just copy the files but rather use 'make headers_install' to get a sanitized version. Sorry, I forgot to reply to the list :( Kumar mentioned the make headers_install and I got it working with our build system. So everything is back on track. Heh, you might also consider using off the shelf build systems, such as the T2 SDE: http://t2-project.org To avoid re-inventing the whell again and again. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
Do you know what the CONFIG_ option is called for the legacy driver. - k On Aug 6, 2008, at 1:02 PM, Stephen Neuendorffer wrote: The problem (in my case) is that the legacy-serial driver doesn't accept all of the 16550 configurations accepted by the regular ns16550 driver. The problem is not related to simple-bus, but only became visible when simple-bus bindings are used because the legacy-serial driver specifically looks for an ns16550 node contained by a simple-bus. Most likely the hpcn_defconfig disables the legacy-serial driver altogether. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Scott Wood Sent: Wednesday, August 06, 2008 10:36 AM To: [EMAIL PROTECTED] Cc: ppc-dev list Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote: On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. ns16550 nodes get matched if the parent claims simple-bus. If extra stuff needs to be done to use that port, then bad things happen. If extra stuff needs to be done, it shouldn't claim to be a simple-bus. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
I was thinking it's CONFIG_PPC_UDBG_16550. -- John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Kumar Gala Sent: Wednesday, August 06, 2008 12:39 PM To: Stephen Neuendorffer Cc: Scott Wood; ppc-dev list Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible Do you know what the CONFIG_ option is called for the legacy driver. - k On Aug 6, 2008, at 1:02 PM, Stephen Neuendorffer wrote: The problem (in my case) is that the legacy-serial driver doesn't accept all of the 16550 configurations accepted by the regular ns16550 driver. The problem is not related to simple-bus, but only became visible when simple-bus bindings are used because the legacy-serial driver specifically looks for an ns16550 node contained by a simple-bus. Most likely the hpcn_defconfig disables the legacy-serial driver altogether. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Scott Wood Sent: Wednesday, August 06, 2008 10:36 AM To: [EMAIL PROTECTED] Cc: ppc-dev list Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote: On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. ns16550 nodes get matched if the parent claims simple-bus. If extra stuff needs to be done to use that port, then bad things happen. If extra stuff needs to be done, it shouldn't claim to be a simple-bus. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
Andrew Morton [EMAIL PROTECTED] writes: Do we expect that this change will be replicated in other memory-intensive apps? (I do). The catch with 2MB pages on x86 is that x86 CPUs generally have much less 2MB TLB entries than 4K entries. So if you're unlucky and access a lot of mappings you might actually thrash more with them. That is why they are not necessarily an universal win. -Andi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Big include file move breaks user mode
On Aug 6, 2008, at 12:44 PM, René Rebe wrote: Heh, you might also consider using off the shelf build systems, such as the T2 SDE: http://t2-project.org To avoid re-inventing the wheel again and again. Yours, Whee.. another rootfs build system. Why we can't converge some of these towards so we have a larger community is beyond me. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Wed, 2008-08-06 at 10:02 +0100, Mel Gorman wrote: That said, this particular patch doesn't appear *too* bound to hugetlb itself. But, some of its limitations *do* come from the filesystem, like its inability to handle VM_GROWS... The lack of VM_GROWSX is an issue, but on its own it does not justify the amount of churn necessary to support direct pagetable insertions for MAP_ANONYMOUS|MAP_PRIVATE. I think we'd need another case or two that would really benefit from direct insertions to pagetables instead of hugetlbfs so that the path would get adequately tested. I'm jumping around here a bit, but I'm trying to get to the core of what my problem with these patches is. I'll see if I can close the loop here. The main thing this set of patches does that I care about is take an anonymous VMA and replace it with a hugetlb VMA. It does this on a special cue, but does it nonetheless. This patch has crossed a line in that it is really the first *replacement* of a normal VMA with a hugetlb VMA instead of the creation of the VMAs at the user's request. I'm really curious what the plan is to follow up on this. Will this stack stuff turn out to be one-off code, or is this *the* route for getting transparent large pages in the future? Because of the limitations like its inability to grow the VMA, I can't imagine that this would be a generic mechanism that we can use elsewhere. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: to schedule() or not to schedule() ?
On Wednesday 06 August 2008, Kevin Diggs wrote: For the purpose of learning, there is no direct, correct way to yield the cpu when in a timer fired routine, right? No, in a timer, you interrupt a totally unrelated thread, so sleeping would prevent that from running on, as well as preventing other timers from being run, so it's not an option. One thing that might work for you would be to re-arm the existing timer and return from your function, so you get back to it after a short while. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Delete completed ppc removal task from feature removal file.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- unless this is in someone's tree already. diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index c239554..17cab3c 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -205,19 +205,6 @@ Who: Tejun Heo [EMAIL PROTECTED] --- -What: The arch/ppc and include/asm-ppc directories -When: Jun 2008 -Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64 - platforms. Currently there are efforts underway to port the remaining - arch/ppc platforms to the merged tree. New submissions to the arch/ppc - tree have been frozen with the 2.6.22 kernel release and that tree will - remain in bug-fix only mode until its scheduled removal. Platforms - that are not ported by June 2008 will be removed due to the lack of an - interested maintainer. -Who: linuxppc-dev@ozlabs.org - - What: i386/x86_64 bzImage symlinks When: April 2010 Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 1:02 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] ioremap_bat() is useful for things like mapping SoC internally memory mapped register and early text because it allows mappings to devices to be setup early in the boot process where they are needed, and the mappings persist after the MMU is configured. Without ioremap_bat(), setting up the MMU would cause the early text mappings to get lost and mostly likely result in a kernel panic on the next attempt at output. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- why can't we just do this in ioremap itself? I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 6, 2008, at 4:54 PM, Grant Likely wrote: On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 1:02 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] ioremap_bat() is useful for things like mapping SoC internally memory mapped register and early text because it allows mappings to devices to be setup early in the boot process where they are needed, and the mappings persist after the MMU is configured. Without ioremap_bat(), setting up the MMU would cause the early text mappings to get lost and mostly likely result in a kernel panic on the next attempt at output. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- why can't we just do this in ioremap itself? I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
ioremap_bat() is useful for things like mapping SoC internally memory mapped
register and early text because it allows mappings to devices to be setup
early in the boot process where they are needed, and the mappings persist
after the MMU is configured.
Without ioremap_bat(), setting up the MMU would cause the early text
mappings to get lost and mostly likely result in a kernel panic on the next
attempt at output.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
First comment, make the name more generic. This facility could be
implemented on processors without BATs using different techniques.
Maybe ioremap_block() or ioremap_early() or something like that.
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 066e65c..7b25b57 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -113,6 +113,15 @@ notrace unsigned long __init early_init(unsigned long
dt_ptr)
*/
notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
{
+ /* Do the bare minimum to start allocting from the IO region so
+ * that ioremap_bat() works */
+#ifdef CONFIG_HIGHMEM
+ ioremap_base = PKMAP_BASE;
+#else
+ ioremap_base = 0xfe00UL;/* for now, could be 0xf000 */
+#endif /* CONFIG_HIGHMEM */
+ ioremap_bot = ioremap_base;
+
Can't these be statically initialized ? If not, then do a function call
to mm/ please. Something like mm_init_early().
+ /* BAT mappings must be 128k aligned */
+ if (addr != _ALIGN_DOWN(addr, 128 10))
+ return NULL;
Mustn't they be naturally aligned on their size ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
Kumar Gala wrote: On Aug 6, 2008, at 4:54 PM, Grant Likely wrote: I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, Why is it silly? It seems silly to me to complicate ioremap() with knowing when to use BATs and when not to use them. especially since we expect there to only be one actual invocation of the API for serial console access. I could also see a BAT (or equivalent) being used for IMMR-space, or other frequently accessed registers, to save TLB entries. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 6, 2008 at 4:11 PM, Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 4:54 PM, Grant Likely wrote: On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 1:02 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] ioremap_bat() is useful for things like mapping SoC internally memory mapped register and early text because it allows mappings to devices to be setup early in the boot process where they are needed, and the mappings persist after the MMU is configured. Without ioremap_bat(), setting up the MMU would cause the early text mappings to get lost and mostly likely result in a kernel panic on the next attempt at output. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- why can't we just do this in ioremap itself? I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. there is a bunch of error checking and difference in semantics that you need to fix. details please? I agree that it can be tightened up in some areas, but I'd like to know if you've seen something I haven't. I think introduce a new API for this is silly, I don't think so. I actually prefer it being an different API. It forces the caller to understand what the function does. It forces the programmer to think and to understand the effect of mapping large io blocks. especially since we expect there to only be one actual invocation of the API for serial console access. Actually, this is not only for early serial. Early serial just happens to be the first user. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 6, 2008 at 4:26 PM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
ioremap_bat() is useful for things like mapping SoC internally memory mapped
register and early text because it allows mappings to devices to be setup
early in the boot process where they are needed, and the mappings persist
after the MMU is configured.
Without ioremap_bat(), setting up the MMU would cause the early text
mappings to get lost and mostly likely result in a kernel panic on the next
attempt at output.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
First comment, make the name more generic. This facility could be
implemented on processors without BATs using different techniques.
Maybe ioremap_block() or ioremap_early() or something like that.
okay
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 066e65c..7b25b57 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -113,6 +113,15 @@ notrace unsigned long __init early_init(unsigned long
dt_ptr)
*/
notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
{
+ /* Do the bare minimum to start allocting from the IO region so
+ * that ioremap_bat() works */
+#ifdef CONFIG_HIGHMEM
+ ioremap_base = PKMAP_BASE;
+#else
+ ioremap_base = 0xfe00UL;/* for now, could be 0xf000 */
+#endif /* CONFIG_HIGHMEM */
+ ioremap_bot = ioremap_base;
+
Can't these be statically initialized ? If not, then do a function call
to mm/ please. Something like mm_init_early().
heh, I had just moved this code block without thinking about it. I'll
investigate and see what I can do.
+ /* BAT mappings must be 128k aligned */
+ if (addr != _ALIGN_DOWN(addr, 128 10))
+ return NULL;
Mustn't they be naturally aligned on their size ?
I'm not sure what you're asking. Are you asking about this particular
test, or are you asking why I don't also test the size?
I do this particular test to make absolute sure that the caller
absolutely understands the limitations of the block mapping. If they
call this with something that isn't 128k aligned, then I make it fail
immediately so the coder is forced to go and understand what they are
allowed to do. Basically, I'm reinforcing the fact that this is not
the same as ioremap().
I haven't decided yet if I should test size in the same way. Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 6, 2008 at 4:28 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. Actually, that is exactly what I am in the process of doing right now for all the 5200 platforms. It is a performance win with no apparent downside. Next I want to investigate if it makes sense to do it for PCI IO regions. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH] Link the bootwrapper as a position-independent executable
Segher Boessenkool writes:
Hurray! Looks good, just a few nits...
Thanks for reviewing.
+ bl .+4
+p_base:mflrr10 /* r10 now points to runtime addr of
p_base */
bl p_base instead?
I went back and forth on that. I ended up with it that way to
emphasize that the bl does need to branch to the *next* instruction
for the idiom to work.
+10:or. r8,r0,r9/* skip relocation if we don't have
both */
beq 3f
Either the code or the comment is wrong -- the code says skip
relocation
if we don't have either.
Ah, operator precedence rules in English. :) I (and I think most
native English speakers) would parse my comment as don't (have both)
whereas I think you parsed it as (don't have) both. Similarly what
you say the code says parses as don't (have either) for me rather
than (don't have) either. IOW, don't have either means both are
missing.
Anyway I can change the comment to say we need both to do
relocation. OK?
+ cmpwi r0,22 /* R_PPC_RELATIVE */
+ bne 3f
It would be nice if there was some way to complain (at build time?)
if there are unhandled relocations present. Prevents a lot of headaches
when things go wrong (and they will ;-) )
Yes, that would be a good idea. There is one extra relocation when I
build for pSeries, which was for _platform_stack_top (which is
undefined), which we're OK ignoring.
4: dcbfr0,r9
icbir0,r9
Fix these while you're at it? It's not r0, it's 0.
Yeah.
+ .dynsym : { *(.dynsym) }
+ .dynstr : { *(.dynstr) }
+ .dynamic :
+ {
+__dynamic_start = .;
+*(.dynamic)
+ }
+ .hash : { *(.hash) }
+ .interp : { *(.interp) }
+ .rela.dyn : { *(.rela*) }
Do some of these sections need alignment?
I suppose they should ideally be 4-byte aligned. We don't actually
use .dynsym, .dynstr, .hash or .interp, but I couldn't find any way to
make the linker omit them.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Thu, Aug 07, 2008 at 08:28:29AM +1000, Benjamin Herrenschmidt wrote: there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. The m68k arch code does something similar with TT registers and ioremap, but it's a little hackish currently. If there was a more generic way to handle it, that would make things a little cleaner. In the m68k implementation, there are just exceptions in the ioremap code that are hard wired to know about the ranges that are normally set earlier. Since the ranges end up being in multiple files, it's more fragile to change what is mapped in these blocks. Brad Boyer [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: Remove bogons from the iSeries console
Alan Cox writes: --- a/drivers/char/viocons.c +++ b/drivers/char/viocons.c @@ -705,10 +705,6 @@ static int viotty_ioctl(struct tty_struct *tty, struct file *file, case KDSKBLED: return 0; } - /* FIXME: WTF is this being called for ??? */ - lock_kernel(); - ret = n_tty_ioctl(tty, file, cmd, arg); - unlock_kernel(); return ret; } I think you want return -ENOIOCTLCMD rather than return ret since ret is uninitialized with your patch applied. I agree the call to n_tty_ioctl is bogus but I think we just want to return -ENOIOCTLCMD. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: Remove bogons from the iSeries console
On Thu, 7 Aug 2008 09:43:28 +1000 Paul Mackerras [EMAIL PROTECTED] wrote: Alan Cox writes: --- a/drivers/char/viocons.c +++ b/drivers/char/viocons.c @@ -705,10 +705,6 @@ static int viotty_ioctl(struct tty_struct *tty, struct file *file, case KDSKBLED: return 0; } - /* FIXME: WTF is this being called for ??? */ - lock_kernel(); - ret = n_tty_ioctl(tty, file, cmd, arg); - unlock_kernel(); return ret; } I think you want return -ENOIOCTLCMD rather than return ret since ret is uninitialized with your patch applied. I agree the call to n_tty_ioctl is bogus but I think we just want to return -ENOIOCTLCMD. Agreed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] of/powerpc: remove include of linux/of_platform.h from asm/of_platform.h
Now that we have removed all inclusions of asm/of_platform.h, this
compatibility include can be removed.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/include/asm/of_platform.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/of_platform.h
b/arch/powerpc/include/asm/of_platform.h
index 18659ef..53b4650 100644
--- a/arch/powerpc/include/asm/of_platform.h
+++ b/arch/powerpc/include/asm/of_platform.h
@@ -11,9 +11,6 @@
*
*/
-/* This is just here during the transition */
-#include linux/of_platform.h
-
/* Platform drivers register/unregister */
static inline int of_register_platform_driver(struct of_platform_driver *drv)
{
--
1.5.6.3
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: Remove bogons from the iSeries console
On Thu, 7 Aug 2008, Paul Mackerras wrote: I think you want return -ENOIOCTLCMD rather than return ret since ret is uninitialized with your patch applied. Actually, nobody has apparently ever even tried compiling that function even before. Yes, 'ret' became uninitialized, but since it was never declared, it doesn't matter - it wouldn't compile anyway. I agree the call to n_tty_ioctl is bogus but I think we just want to return -ENOIOCTLCMD. I made that change, and in the spirit of that file I also didn't even try to compile it. So if the end result sexually assaults your pets, don't blame me. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, Aug 06, 2008 at 06:25:48PM +0200, Segher Boessenkool wrote: It's not what we do with flattened device trees blobs though. In the flattened tree we're not using a /chosen/stdout property, just the linux,stdout-path one. The question that remains is; should there be? Should the dt blobs use /chosen/stdout also? (I'm not familiar enough with real OF to know the answer. I'm assuming that an instance value is not the same as a phandle). ihandles and phandles are not the same thing in OF. Since in the flat world we cannot have instances, we should use phandles instead of ihandles for the things in /chosen. I thought we agreed on that already, perhaps I am wrong? Not that I recall. In general we've been avoiding using anything that traditionally contains an ihandle; hence the direct use of linux,stdout-path when using a flat tree. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
On Wed, Aug 6, 2008 at 11:35 AM, Scott Wood [EMAIL PROTECTED] wrote: On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote: On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote: I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600) system. If I remove the 'simple-bus' compatible from the soc node in the .dts it works. Otherwise it hangs at but and looks to be crashed in the serial driver due to accessing memory at 0. I've tried the same .dts (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. The Xilinx folks hit something similar. ns16550 nodes get matched if the parent claims simple-bus. If extra stuff needs to be done to use that port, then bad things happen. If extra stuff needs to be done, it shouldn't claim to be a simple-bus. Heh, no, not the bus. :-) Extra stuff to use the serial device. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH] Link the bootwrapper as a position-independent executable
+ bl .+4
+p_base:mflrr10 /* r10 now points to runtime addr of
p_base */
bl p_base instead?
I went back and forth on that. I ended up with it that way to
emphasize that the bl does need to branch to the *next* instruction
for the idiom to work.
Right, I see. Make it even more obvious? Use bcl 20,31,$+4 instead
(so people will have to look it up before changing this code, not
because
it is a few cycles faster ;-) ), add an empty line before the label, or
even put an actual comment there? :-)
+10:or. r8,r0,r9/* skip relocation if we don't have both */
beq 3f
Either the code or the comment is wrong -- the code says skip
relocation
if we don't have either.
Ah, operator precedence rules in English. :)
While I don't think that double (and triple) negations in English are
not overused and confusing...
I (and I think most
native English speakers) would parse my comment as don't (have both)
whereas I think you parsed it as (don't have) both. Similarly what
you say the code says parses as don't (have either) for me rather
than (don't have) either. IOW, don't have either means both are
missing.
... that is exactly what I meant: the code skips relocation only if
both are missing.
Anyway I can change the comment to say we need both to do
relocation. OK?
Please do -- but also change the code to match :-)
+ .dynsym : { *(.dynsym) }
+ .dynstr : { *(.dynstr) }
+ .dynamic :
+ {
+__dynamic_start = .;
+*(.dynamic)
+ }
+ .hash : { *(.hash) }
+ .interp : { *(.interp) }
+ .rela.dyn : { *(.rela*) }
Do some of these sections need alignment?
I suppose they should ideally be 4-byte aligned.
Ideally, yes; I was questioning whether the ABI requires it. It will
only cost a few bytes of object size so let's just do it?
We don't actually
use .dynsym, .dynstr, .hash or .interp, but I couldn't find any way to
make the linker omit them.
Assign those input sections to the /DISCARD/ output section (and do
that early enough in the linker script so they aren't picked up by
some other wildcard). Something like
/DISCARD/ : { *(.dynstr .dynsym .hash .interp) }
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
problem in booting kernel with mpc836x_mds.dtb
Hi, I have the following problem, when i am trying to boot linux on MPC8360E MDS board with the mpc836x_mds.dtb created using dtc and mpc836x_mds.dts in from /arch/powerpc/boot/platforms/dts/ directory of linux-2.6.22 version. fdt_chosen: FDT_ERR_BADMAGIC after this it is trying to re boot. how to resolve this issue, so i need to apply any pathces to mpc836x_mds.dts file. NOTE: i am using dtc compiled from linux-2.6.26 version. Regards Surendra ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 6, 2008, at 5:28 PM, Benjamin Herrenschmidt wrote: there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. why should they be permanent.. We could implement reference counting around the regions and free BATs if the count = 0. I'm more concerned about this being implemented around the existing ioremap core in __ioremap(). We can easily use a flag bit to say use large mappings or the fact that mem_init_done == 0. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
why can't we just do this in ioremap itself? I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. there is a bunch of error checking and difference in semantics that you need to fix. details please? I agree that it can be tightened up in some areas, but I'd like to know if you've seen something I haven't. The alignment checks for one? Why does the caller need to ensure alignment.. we just force alignment in __ioremap().. we should be doing the same thing here. I think introduce a new API for this is silly, I don't think so. I actually prefer it being an different API. It forces the caller to understand what the function does. It forces the programmer to think and to understand the effect of mapping large io blocks. Ok.. My feeling is the same core logic should be used so I don't have to fix 2 places in the future. especially since we expect there to only be one actual invocation of the API for serial console access. Actually, this is not only for early serial. Early serial just happens to be the first user. Than this really should be done as part of __ioremap() since you have to deal with doing different things depending on how mem_init_done is set. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH] Link the bootwrapper as a position-independent executable
Segher Boessenkool writes: ... that is exactly what I meant: the code skips relocation only if both are missing. Doh! You're right, thanks. Serves me right for being so clever. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc update for in-kernel version
On Wed, Aug 06, 2008 at 09:35:22AM -0400, Josh Boyer wrote: On Wed, 6 Aug 2008 08:29:30 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 7:43 AM, Josh Boyer wrote: So we asked about this a while ago and I haven't seen anything yet, but is there going to be an update to the version of DTC that is in the kernel tree? 1.2 is out now, would be a good idea to update soon. is there any reason to update to 1.2 for 2.6.27? Probably not at this point in the lifecycle. We brought this up before the merge window opened though, so I'm just wondering what the general plan is. Seems lots of fixes and such are getting put out, but not pulled into the kernel. There isn't really a general plan, someone just needed to get around to assembling the patch. I just sent out a patch which updates the in-kernel dtc and libfdt to 1.2. Longer term, once microblaze support goes into mainline, we probably should move the in-kernel copy to scripts/ and/or lib/ so that powerpc and microblaze can share it. It would be nice to have some better automagical way of pulling the dtc git tree into a kernel git tree, but I haven't gotten my heard around the gittery involved. There's a bit more to it than simply importing the dtc tree verbatim into the kernel tree - the pulls from upstream would need to be co-ordinated in some cases with updates to the in-kernel makefiles, libfdt_env.h and users of dtc and libfdt. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
- Original Message Follows -
From: Michael Ellerman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED],
linuxppc-dev@ozlabs.org, Segher Boessenkool
[EMAIL PROTECTED]
Subject: Re: [PATCH] powerpc: EOI spurious irqs during boot
so they can be reenabled later
Date: Wed, 06 Aug 2008 14:53:54 +1000
On Tue, 2008-08-05 at 20:55 -0600, miltonm wrote:
- Original Message Follows -
From: Michael Ellerman [EMAIL PROTECTED]
To: Paul Mackerras [EMAIL PROTECTED]
Cc: linuxppc-dev@ozlabs.org, Milton Miller
[EMAIL PROTECTED], Segher Boessenkool
[EMAIL PROTECTED]
Subject: [PATCH] powerpc: EOI spurious irqs during boot
so they can be reenabled later
Date: Wed, 6 Aug 2008 12:03:37 +1000 (EST)
I really dislike this great big if in the middle of a
function.
we called this function from two different call sites
where the
choice of which to call was based on their environment.
Please move the call to eoi the hwirq to the callers,
who know which path to take.
It's not pretty, but the alternative is worse I think:
Well, it needs a bit of refinement.
From 0a908825c8de6cd4c26288aba8c5b7fe3ed0a69f Mon Sep 17
00:00:00 2001 From: Michael Ellerman
[EMAIL PROTECTED] Date: Tue, 5 Aug 2008 22:34:48
+1000 Subject: [PATCH] powerpc: EOI spurious irqs during
boot so they can be reenabled later
In the xics code, if we receive an irq during boot that
hasn't been setup yet - ie. we have no reverse mapping for
it - we mask the irq so we don't hear from it again.
Later on if someone request_irq()'s that irq, we'll unmask
it but it will still never fire. This is because we never
EOI'ed the irq when we originally received it - when it
was spurious.
This can be reproduced trivially by banging the keyboard
while kexec'ing on a P5 LPAR, even though the hvc_console
driver request's the console irq, the console is
non-functional because we're receiving no console
interrupts.
So when we receive a spurious irq mask it and then EOI it.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/xics.c | 74
++---
1 files changed, 50 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c index
0fc830f..754706c 100644 ---
a/arch/powerpc/platforms/pseries/xics.c +++
b/arch/powerpc/platforms/pseries/xics.c @@ -90,7 +90,7 @@
static inline unsigned int direct_xirr_info_get(void)
{
int cpu = smp_processor_id();
-return in_be32(xics_per_cpu[cpu]-xirr.word);
+return in_be32(xics_per_cpu[cpu]-xirr.word)
0x00ff;
}
static inline void direct_xirr_info_set(int value)
@@ -124,7 +124,8 @@ static inline unsigned int
lpar_xirr_info_get(void)
lpar_rc = plpar_xirr(return_value);
if (lpar_rc != H_SUCCESS)
panic( bad return code xirr - rc = %lx \n,
lpar_rc); -return (unsigned int)return_value;
+
+return (unsigned int)return_value 0x00ff;
}
No, don't put the 0x00FF here.
(1) this is not get_vector
(2) we can take advantage of the full value
Instead we need a macro to extract this out.
The value returned is the value that is supposed to be used
to EOI. The top byte is the old priority of the CPPR and
the bottom 3 is the vector. xics has priority levels
even though linux does not, and hence can allow limited
nesting. we use that to allow
only ipis to nest hardware irqs, but once we take an eoi we
actually drop and let
any new hwirq in. that's a seperate bug/hole.
static inline void lpar_xirr_info_set(int value)
@@ -321,49 +322,74 @@ static unsigned int
xics_startup(unsigned int virq)
return 0;
}
+static void xics_eoi_hwirq_direct(unsigned int hwirq)
+{
+iosync();
+direct_xirr_info_set((0xff 24) | hwirq);
+}
+
static void xics_eoi_direct(unsigned int virq)
{
-unsigned int irq = (unsigned int)irq_map[virq].hwirq;
+xics_eoi_hwirq_direct((unsigned
int)irq_map[virq].hwirq); +}
+static void xics_eoi_hwirq_lpar(unsigned int hwirq)
+{
iosync();
-direct_xirr_info_set((0xff 24) | irq);
+lpar_xirr_info_set((0xff 24) | hwirq);
}
-
static void xics_eoi_lpar(unsigned int virq)
{
-unsigned int irq = (unsigned int)irq_map[virq].hwirq;
-
-iosync();
-lpar_xirr_info_set((0xff 24) | irq);
+xics_eoi_hwirq_lpar((unsigned
int)irq_map[virq].hwirq);
}
so if we undo this part
static inline unsigned int xics_remap_irq(unsigned int
vec)
{
-unsigned int irq;
-
-vec = 0x00ff;
-
-if (vec == XICS_IRQ_SPURIOUS)
-return NO_IRQ;
-irq = irq_radix_revmap(xics_host, vec);
-if (likely(irq != NO_IRQ))
-return irq;
+return irq_radix_revmap(xics_host, vec);
+}
-printk(KERN_ERR Interrupt %u (real) is invalid,
-disabling it.\n, vec);
-xics_mask_real_irq(vec);
-return NO_IRQ;
Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
On Wed, 2008-08-06 at 12:29 -0500, Scott Wood wrote:
On Wed, Aug 06, 2008 at 03:04:44PM +0800, Li Yang wrote:
[EMAIL PROTECTED] {
- compatible = qe_udc;
+ compatible = fsl,qe_udc;
[snip]
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe_udc);
+ if (np) {
+ par_io_of_config(np);
+ qe_usb_clock_set(np);
+ }
What about existing device trees in use?
This node was never used in existing device trees for mainline kernel.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/6] powerpc: add USB peripheral support to MPC8272ADS
On Wed, 2008-08-06 at 12:19 -0500, Scott Wood wrote:
On Wed, Aug 06, 2008 at 03:04:43PM +0800, Li Yang wrote:
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8272ads.dts |8
arch/powerpc/platforms/82xx/mpc8272_ads.c | 25 +
arch/powerpc/platforms/82xx/pq2ads.h |3 +++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index b2ce4c0..75cc94c 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -256,6 +256,14 @@
#address-cells = 1;
#size-cells = 0;
};
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,qe_udc;
fsl,mpc8272-usb, fsl,cpm2-usb.
Where is fsl,qe_udc documented or used (other than in the BCSR setup)?
What does udc mean (the only reference to it in the 8272 manual is
under ATM)?
udc is a common name for USB device mode drivers to work with Linux
gadget. We will have two separate drivers for USB host and device.
Probably we can have two compatibles fsl,qe_udc and fsl,qe-usb-host
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/iseries: remove the old viocons driver
This driver was declared obsolete over 2 years ago, the alternative
console driver for legacy iSeries (hvc_iseries) was made the default
over 1 year ago and this driver has been build broken for over 3
months, so remove it.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/iseries/Kconfig | 11 +-
drivers/char/Kconfig |2 +-
drivers/char/Makefile |1 -
drivers/char/viocons.c | 1167
4 files changed, 2 insertions(+), 1179 deletions(-)
delete mode 100644 drivers/char/viocons.c
diff --git a/arch/powerpc/platforms/iseries/Kconfig
b/arch/powerpc/platforms/iseries/Kconfig
index ea3e541..45ffd8e 100644
--- a/arch/powerpc/platforms/iseries/Kconfig
+++ b/arch/powerpc/platforms/iseries/Kconfig
@@ -7,15 +7,6 @@ config PPC_ISERIES
menu iSeries device drivers
depends on PPC_ISERIES
-config VIOCONS
- bool iSeries Virtual Console Support (Obsolete)
- depends on !HVC_ISERIES
- default n
- help
- This is the old virtual console driver for legacy iSeries.
- You should use the iSeries Hypervisor Virtual Console
- support instead.
-
config VIODASD
tristate iSeries Virtual I/O disk support
help
@@ -38,5 +29,5 @@ endmenu
config VIOPATH
bool
- depends on VIOCONS || VIODASD || VIOCD || VIOTAPE || ISERIES_VETH
+ depends on VIODASD || VIOCD || VIOTAPE || ISERIES_VETH
default y
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index d0ac944..caff851 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -8,7 +8,7 @@ config VT
bool Virtual terminal if EMBEDDED
depends on !S390
select INPUT
- default y if !VIOCONS
+ default y
---help---
If you say Y here, you will get support for terminal devices with
display and keyboard devices. These are called virtual because you
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 8a161c3..6850f6d 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_RAW_DRIVER) += raw.o
obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
obj-$(CONFIG_MSPEC)+= mspec.o
obj-$(CONFIG_MMTIMER) += mmtimer.o
-obj-$(CONFIG_VIOCONS) += viocons.o
obj-$(CONFIG_VIOTAPE) += viotape.o
obj-$(CONFIG_HVCS) += hvcs.o
obj-$(CONFIG_IBM_BSR) += bsr.o
diff --git a/drivers/char/viocons.c b/drivers/char/viocons.c
deleted file mode 100644
index 7feeb77..000
--- a/drivers/char/viocons.c
+++ /dev/null
@@ -1,1167 +0,0 @@
-/* -*- linux-c -*-
- *
- * drivers/char/viocons.c
- *
- * iSeries Virtual Terminal
- *
- * Authors: Dave Boutcher [EMAIL PROTECTED]
- * Ryan Arnold [EMAIL PROTECTED]
- * Colin Devilbiss [EMAIL PROTECTED]
- * Stephen Rothwell
- *
- * (C) Copyright 2000, 2001, 2002, 2003, 2004 IBM Corporation
- *
- * 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) anyu later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#include linux/kernel.h
-#include linux/proc_fs.h
-#include linux/errno.h
-#include linux/vmalloc.h
-#include linux/mm.h
-#include linux/console.h
-#include linux/module.h
-#include asm/uaccess.h
-#include linux/init.h
-#include linux/wait.h
-#include linux/spinlock.h
-#include asm/ioctls.h
-#include linux/kd.h
-#include linux/tty.h
-#include linux/tty_flip.h
-#include linux/sysrq.h
-
-#include asm/firmware.h
-#include asm/iseries/vio.h
-#include asm/iseries/hv_lp_event.h
-#include asm/iseries/hv_call_event.h
-#include asm/iseries/hv_lp_config.h
-#include asm/iseries/hv_call.h
-
-#ifdef CONFIG_VT
-#error You must turn off CONFIG_VT to use CONFIG_VIOCONS
-#endif
-
-#define VIOTTY_MAGIC (0x0DCB)
-#define VTTY_PORTS 10
-
-#define VIOCONS_KERN_WARN KERN_WARNING viocons:
-#define VIOCONS_KERN_INFO KERN_INFO viocons:
-
-static DEFINE_SPINLOCK(consolelock);
-static DEFINE_SPINLOCK(consoleloglock);
-
-static int vio_sysrq_pressed;
-
-#define VIOCHAR_NUM_BUF16
-
-/*
- * Our port information. We store a pointer to one entry in the
- * tty_driver_data
- */
-static struct port_info {
- int magic;
- struct tty_struct *tty;
- HvLpIndex lp;
- u8 vcons;
- u64 seq;/* sequence number of last HV send
