Re: Boot hang when setting console=none with MPC5200B custom board
Hi Sylvain: Humm I see, here is the node I'm creating in the initial ramdisk, so they are there before mdev is launched in one of my init scripts. [snip] I additionally have tty0 c 4 0 which might be important here, plus a lot of other crap (should clean up there...;-). I don't use a ramdisk, but have the /dev folder in the flash jffs2 image. In the init script, I say /bin/mount -t tmpfs ramfs /dev mdev -s mkdir /dev/pts mkdir /dev/shm chmod 1777 /dev/shm and then tty0 is gone. So to be honest I'm not absolutely sure it's necessary. My inittab contains ::sysinit:/etc/init.d/rcS ::respawn:-/bin/sh ::shutdown:/etc/init.d/rcS stop ::restart:/sbin/init ::respawn:/sbin/dropbear -F With this, I can access the board through ssh (dropbear). The dmesg output lists console=tty0 as expected. All PSC's are in the device tree, btw, and available as serial ports. Hth, Albrecht. Traumziele - von Beschreibung bis Buchung jetzt kompakt auf den Reise-Seiten von Arcor.de! http://www.arcor.de/rd/footer.reise ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fixes for MPC512x PSC
Hi Steve: A while ago I posted a patch which improves the baud rate calculation of the '5200, but also refactors the driver a little bit so it also influences the '512x. However, there has been some confusion about the config regs of the 521x's uart. It would be great if you colud have a look at the patch http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-March/081477.html, in particular function mpc512x_psc_set_baudrate(), and comment on it. Some more infor is in the thread http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-March/080867.html. Thanks in advance, Albrecht. - Original Nachricht Von: Steve Deiters stevedeit...@basler.com An: linuxppc-dev@lists.ozlabs.org Datum: 23.04.2010 02:13 Betreff: [PATCH] Fixes for MPC512x PSC This will apply on the mpc512x-v2.6.33-devel branch of the DENX git repository. This is all mostly based on what was in the Freescale LTIB release from the Freescale website. On a somewhat unrelated note, does anyone know if the Freescale LTIB drivers have been merged into any newer kernel versions? In particular, I could not find a branch that has drivers for the newer NAND Flash controller that was in the LTIB version. In clock.c replaced clk_enable with mpc5121_clk_enable as clk_functions is not yet set. Added initialization of the FIFO address and size registers based on device tree. Removed port-number property from mpc5121ads device tree as the driver doesn't use it. Made sure PSC clocks are enabled early for console. Made sure interrupt is requested with IRQF_SHARED as they share the FIFO irq. Moved initialization of CSR to mpc52xx_uart_set_termios so it is done for the MPC512x and also so it is done early in the console setup. Traumziele - von Beschreibung bis Buchung jetzt kompakt auf den Reise-Seiten von Arcor.de! http://www.arcor.de/rd/footer.reise ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fixes for MPC512x PSC
On Thu, 22 Apr 2010 19:13:21 -0500 Steve Deiters stevedeit...@basler.com wrote: This will apply on the mpc512x-v2.6.33-devel branch of the DENX git repository. This is all mostly based on what was in the Freescale LTIB release from the Freescale website. Please don't use mpc512x-v2.6.33-devel branch, it is obsolete. Fixes to serial PSC driver have been merged into mainline kernel, so with v2.6.34-rc5 you do not need all this stuff your patch addresses. On a somewhat unrelated note, does anyone know if the Freescale LTIB drivers have been merged into any newer kernel versions? In particular, I could not find a branch that has drivers for the newer NAND Flash controller that was in the LTIB version. Pull from mtd-2.6 tree [1] to get newer mpc512x NAND driver. [1] http://git.infradead.org/mtd-2.6.git Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][RESEND] ehea: error handling improvement
On 04/22/2010 07:36 AM, David Miller wrote: From: Thomas Kleintkl...@de.ibm.com Date: Wed, 21 Apr 2010 11:10:55 +0200 Reset a port's resources only if they're actually in an error state Signed-off-by: Thomas Kleintkl...@de.ibm.com --- Patch created against net-2.6 I thought you were sorry for wasting my time and that you were going to follow the directions I gave you last time, and I quote: 3) These are not appropriate for net-2.6 as we are deep in the -rcX series at this point and only the most diabolical bug fixes are appropriate. Therefore, please generate these against net-next-2.6, thanks. And here you are generating your patches against net-2.6. Heck, you even feel it's worth mentioning explicitly. Guilty! Allows no excuse. Screwed it. Deeply sorry. Lucky for you the patches happen to apply cleanly to net-next-2.6 so I've put them there. Thanks! Thomas -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [GIT PULL] Perf probe support for PowerPC, from Ian Munsie
* Paul Mackerras pau...@samba.org wrote: Ingo, Please pull my perf.git master branch: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/perf.git master It has two commits from Ian Munsie that allow us to access local variables with perf probe on PowerPC. We also need a commit in Ben's powerpc-next branch for it to function, but it compiles without that. Thanks, Paul. --- The following changes since commit 6eca8cc35b50af1037bc919106dd6dd332c959c2: Frederic Weisbecker (1): perf: Fix perf probe build error are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/perf.git master Ian Munsie (2): perf: Move arch specific code into separate arch directory perf probe: Add PowerPC DWARF register number mappings tools/perf/Makefile | 36 ++-- tools/perf/arch/powerpc/Makefile |4 + tools/perf/arch/powerpc/util/dwarf-regs.c | 88 + tools/perf/arch/x86/Makefile |4 + tools/perf/arch/x86/util/dwarf-regs.c | 75 tools/perf/util/include/dwarf-regs.h |8 +++ tools/perf/util/probe-finder.c| 55 +- 7 files changed, 211 insertions(+), 59 deletions(-) create mode 100644 tools/perf/arch/powerpc/Makefile create mode 100644 tools/perf/arch/powerpc/util/dwarf-regs.c create mode 100644 tools/perf/arch/x86/Makefile create mode 100644 tools/perf/arch/x86/util/dwarf-regs.c create mode 100644 tools/perf/util/include/dwarf-regs.h Pulled, thanks a lot Paul! Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: My MDIO is acting strange
linux 2.6.22 is working correctly on my board. So, I think this is due to the difference between them. I will check the boot time difference between 2.6.22 and my new port. Hope that will give me a clue. 2010/4/23 Andy Fleming aflem...@gmail.com: On Thu, Apr 22, 2010 at 9:36 PM, Peter Pan pppeterpp...@gmail.com wrote: I'm porting Linux 2.6.32.6 to my MPC8247 based board. Our FCC1 and FCC2 are used as 100MBps ethernet ports. MDIO is used to connect with PHY chip. During boot, the of driver is checking the PHYID, it gets all Fs. But after I comment the following lines: //if ((phy_id 0x1fff) == 0x1fff) // return NULL; I can use my FCC ethernet normally after boot into console. This means that your PHY can work without any initialization, and implies the problem is with your MDIO bus. I checked that while boot, all the read bit from MDIO pin is 1, that makes no TA bit, and no PHYID. I'm wondering why is that happening. Possible reasons include the board being wired incorrectly (so the PHY is not responding to MDIO commands), or software being configured incorrectly to use the wrong pins for MDIO. That's my guess. Andy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Initcall ordering
I'm having trouble with the I2C devices on my 8347 platform. The problem is that I2C device probe() functions are only called once, as the I2C bus is being initialized (in this case fsl_i2c_init()) I have 2 devices on this bus, one device gets it's initcall before fsl_i2c_init, the second one does not :-( This means that the second device is never probed. What can I do about this? Has the problem been seen before? I can provide more data, as required. note: I'm currently using 2.6.28, but I will be moving to 2.6.32 soon in case it matters, but I'd rather find/understand/fix this in 2.6.28 if possible. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] fsl_pq_mdio: Fix kernel oops during OF address translation
Old P1020RDB device trees were not specifing tbipa address for
MDIO nodes, which is now causing this kernel oops:
...
eth2: TX BD ring size for Q[6]: 256
eth2: TX BD ring size for Q[7]: 256
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0015504
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c0015504] memcpy+0x3c/0x9c
LR [c000a9f8] __of_translate_address+0xfc/0x21c
Call Trace:
[df839e00] [c000a94c] __of_translate_address+0x50/0x21c (unreliable)
[df839e50] [c01a33e8] get_gfar_tbipa+0xb0/0xe0
...
The old device trees are buggy, though having a dead ethernet is
better than a dead kernel, so fix the issue by using of_iomap().
Also, a somewhat similar issue exist in the probe() routine, though
there the oops is only a possibility. Nonetheless, fix it too.
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
drivers/net/fsl_pq_mdio.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index d5160ed..3acac5f 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -205,8 +205,6 @@ static int fsl_pq_mdio_find_free(struct mii_bus *new_bus)
static u32 __iomem *get_gfar_tbipa(struct fsl_pq_mdio __iomem *regs, struct
device_node *np)
{
struct gfar __iomem *enet_regs;
- u32 __iomem *ioremap_tbipa;
- u64 addr, size;
/*
* This is mildly evil, but so is our hardware for doing this.
@@ -220,9 +218,7 @@ static u32 __iomem *get_gfar_tbipa(struct fsl_pq_mdio
__iomem *regs, struct devi
return enet_regs-tbipa;
} else if (of_device_is_compatible(np, fsl,etsec2-mdio) ||
of_device_is_compatible(np, fsl,etsec2-tbi)) {
- addr = of_translate_address(np, of_get_address(np, 1, size,
NULL));
- ioremap_tbipa = ioremap(addr, size);
- return ioremap_tbipa;
+ return of_iomap(np, 1);
} else
return NULL;
}
@@ -279,6 +275,7 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
u32 __iomem *tbipa;
struct mii_bus *new_bus;
int tbiaddr = -1;
+ const u32 *addrp;
u64 addr = 0, size = 0;
int err = 0;
@@ -297,8 +294,19 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
new_bus-priv = priv;
fsl_pq_mdio_bus_name(new_bus-id, np);
+ addrp = of_get_address(np, 0, size, NULL);
+ if (!addrp) {
+ err = -EINVAL;
+ goto err_free_bus;
+ }
+
/* Set the PHY base address */
- addr = of_translate_address(np, of_get_address(np, 0, size, NULL));
+ addr = of_translate_address(np, addrp);
+ if (addr == OF_BAD_ADDR) {
+ err = -EINVAL;
+ goto err_free_bus;
+ }
+
map = ioremap(addr, size);
if (!map) {
err = -ENOMEM;
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] gianfar: Fix potential oops during OF address translation
gianfar driver may pass NULL pointer to the of_translate_address(),
which may lead to a kernel oops. Fix this by using of_iomap(), which
is also much simpler and shorter.
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
drivers/net/gianfar.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 080d1ce..df49af3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -549,12 +549,8 @@ static int gfar_parse_group(struct device_node *np,
struct gfar_private *priv, const char *model)
{
u32 *queue_mask;
- u64 addr, size;
-
- addr = of_translate_address(np,
- of_get_address(np, 0, size, NULL));
- priv-gfargrp[priv-num_grps].regs = ioremap(addr, size);
+ priv-gfargrp[priv-num_grps].regs = of_iomap(np, 0);
if (!priv-gfargrp[priv-num_grps].regs)
return -ENOMEM;
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Initcall ordering
On 04/23/2010 09:56 AM, Gary Thomas wrote: I'm having trouble with the I2C devices on my 8347 platform. The problem is that I2C device probe() functions are only called once, as the I2C bus is being initialized (in this case fsl_i2c_init()) I have 2 devices on this bus, one device gets it's initcall before fsl_i2c_init, the second one does not :-( This means that the second device is never probed. What can I do about this? Has the problem been seen before? I can provide more data, as required. note: I'm currently using 2.6.28, but I will be moving to 2.6.32 soon in case it matters, but I'd rather find/understand/fix this in 2.6.28 if possible. A possibly related question: how can I2C devices work as modules when the device address + probe info is in the device tree? Given the behaviour I'm seeing (I2C device probes only happen when the bus is enumerated), how is this supposed to work? ... maybe I'm missing something fundamental? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] add icswx support
Add Power7 icswx co-processor instruction support.
Signed-off-by: Sonny Rao sonny...@linux.vnet.ibm.com
Signed-off-by: Tseng-Hui (Frank) Lin th...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/mmu-hash64.h |3 +
arch/powerpc/include/asm/mmu_context.h |4 ++
arch/powerpc/include/asm/reg.h |3 +
arch/powerpc/mm/mmu_context_hash64.c | 79
4 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index 2102b21..ba5727d 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -421,6 +421,9 @@ typedef struct {
#ifdef CONFIG_PPC_SUBPAGE_PROT
struct subpage_prot_table spt;
#endif /* CONFIG_PPC_SUBPAGE_PROT */
+ unsigned long acop;
+#define HASH64_MAX_PID (0x)
+ unsigned int pid;
} mm_context_t;
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
index 26383e0..d6c8841 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -78,6 +78,10 @@ static inline void switch_mm(struct mm_struct *prev,
struct mm_struct *next,
#define deactivate_mm(tsk,mm) do { } while (0)
+extern void switch_cop(struct mm_struct *next);
+extern int use_cop(unsigned long acop, struct task_struct *task);
+extern void disuse_cop(unsigned long acop, struct mm_struct *mm);
+
/*
* After we have set current-mm to a new value, this activates
* the context for the new mm so we see the new mappings.
diff --git a/arch/powerpc/include/asm/reg.h
b/arch/powerpc/include/asm/reg.h
index 5572e86..30503f8 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -516,6 +516,9 @@
#define SPRN_SIAR 780
#define SPRN_SDAR 781
+#define SPRN_ACOP 31
+#define SPRN_PID48
+
#define SPRN_PA6T_MMCR0 795
#define PA6T_MMCR0_EN0 0x0001UL
#define PA6T_MMCR0_EN1 0x0002UL
diff --git a/arch/powerpc/mm/mmu_context_hash64.c
b/arch/powerpc/mm/mmu_context_hash64.c
index 2535828..d0a79f6 100644
--- a/arch/powerpc/mm/mmu_context_hash64.c
+++ b/arch/powerpc/mm/mmu_context_hash64.c
@@ -18,6 +18,7 @@
#include linux/mm.h
#include linux/spinlock.h
#include linux/idr.h
+#include linux/percpu.h
#include linux/module.h
#include linux/gfp.h
@@ -25,6 +26,82 @@
static DEFINE_SPINLOCK(mmu_context_lock);
static DEFINE_IDA(mmu_context_ida);
+static DEFINE_IDA(cop_ida);
+
+/* Lazy switch the ACOP register */
+static DEFINE_PER_CPU(unsigned long, acop_reg);
+
+void switch_cop(struct mm_struct *next)
+{
+ mtspr(SPRN_PID, next-context.pid);
+ if (next-context.pid
+ __get_cpu_var(acop_reg) != next-context.acop) {
+ mtspr(SPRN_ACOP, next-context.acop);
+ __get_cpu_var(acop_reg) = next-context.acop;
+ }
+}
+
+int use_cop(unsigned long acop, struct task_struct *task)
+{
+ int pid;
+ int err;
+ struct mm_struct *mm = get_task_mm(task);
+
+ if (!mm)
+ return -EINVAL;
+
+ if (!mm-context.pid) {
+ if (!ida_pre_get(cop_ida, GFP_KERNEL))
+ return -ENOMEM;
+again:
+ spin_lock(mmu_context_lock);
+ err = ida_get_new_above(cop_ida, 1, pid);
+ spin_unlock(mmu_context_lock);
+
+ if (err == -EAGAIN)
+ goto again;
+ else if (err)
+ return err;
+
+ if (pid HASH64_MAX_PID) {
+ spin_lock(mmu_context_lock);
+ ida_remove(cop_ida, pid);
+ spin_unlock(mmu_context_lock);
+ return -EBUSY;
+ }
+ mm-context.pid = pid;
+ mtspr(SPRN_PID, mm-context.pid);
+ }
+ mm-context.acop |= acop;
+
+ get_cpu_var(acop_reg) = mm-context.acop;
+ mtspr(SPRN_ACOP, mm-context.acop);
+ put_cpu_var(acop_reg);
+
+ return mm-context.pid;
+}
+EXPORT_SYMBOL(use_cop);
+
+void disuse_cop(unsigned long acop, struct mm_struct *mm)
+{
+ if (WARN_ON(!mm))
+ return;
+
+ mm-context.acop = ~acop;
+ if (!mm-context.acop) {
+ spin_lock(mmu_context_lock);
+ ida_remove(cop_ida, mm-context.pid);
+ spin_unlock(mmu_context_lock);
+ mm-context.pid = 0;
+ mtspr(SPRN_PID, 0);
+ } else {
+ get_cpu_var(acop_reg) = mm-context.acop;
+ mtspr(SPRN_ACOP, mm-context.acop);
+ put_cpu_var(acop_reg);
+ }
+ mmput(mm);
+}
+EXPORT_SYMBOL(disuse_cop);
/*
* The proto-VSID space has 2^35 - 1 segments available for user
mappings.
@@ -94,6 +171,8 @@ EXPORT_SYMBOL_GPL(__destroy_context);
void destroy_context(struct mm_struct *mm)
{
__destroy_context(mm-context.id);
+ if
Re: [PATCH 1/2] fsl_pq_mdio: Fix kernel oops during OF address translation
From: Anton Vorontsov avoront...@mvista.com Date: Fri, 23 Apr 2010 21:12:35 +0400 Old P1020RDB device trees were not specifing tbipa address for MDIO nodes, which is now causing this kernel oops: ... eth2: TX BD ring size for Q[6]: 256 eth2: TX BD ring size for Q[7]: 256 Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0015504 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0015504] memcpy+0x3c/0x9c LR [c000a9f8] __of_translate_address+0xfc/0x21c Call Trace: [df839e00] [c000a94c] __of_translate_address+0x50/0x21c (unreliable) [df839e50] [c01a33e8] get_gfar_tbipa+0xb0/0xe0 ... The old device trees are buggy, though having a dead ethernet is better than a dead kernel, so fix the issue by using of_iomap(). Also, a somewhat similar issue exist in the probe() routine, though there the oops is only a possibility. Nonetheless, fix it too. Signed-off-by: Anton Vorontsov avoront...@mvista.com Seems reasonable, applied to net-2.6 thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] gianfar: Fix potential oops during OF address translation
From: Anton Vorontsov avoront...@mvista.com Date: Fri, 23 Apr 2010 21:12:44 +0400 gianfar driver may pass NULL pointer to the of_translate_address(), which may lead to a kernel oops. Fix this by using of_iomap(), which is also much simpler and shorter. Signed-off-by: Anton Vorontsov avoront...@mvista.com Also applied to net-2.6, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] add icswx support
On Fri, 2010-04-23 at 17:04 -0500, Tseng-Hui (Frank) Lin wrote:
Add Power7 icswx co-processor instruction support.
Please provide a -much- more detailed explanation of what it is, what it
does and why it requires hooking into the MMU context switch code. _I_
know these things but nobody else on the list does which limits the
ability of people to review your patch.
Signed-off-by: Sonny Rao sonny...@linux.vnet.ibm.com
Signed-off-by: Tseng-Hui (Frank) Lin th...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/mmu-hash64.h |3 +
arch/powerpc/include/asm/mmu_context.h |4 ++
arch/powerpc/include/asm/reg.h |3 +
arch/powerpc/mm/mmu_context_hash64.c | 79
4 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index 2102b21..ba5727d 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -421,6 +421,9 @@ typedef struct {
#ifdef CONFIG_PPC_SUBPAGE_PROT
struct subpage_prot_table spt;
#endif /* CONFIG_PPC_SUBPAGE_PROT */
+ unsigned long acop;
+#define HASH64_MAX_PID (0x)
+ unsigned int pid;
Please add a comment as to what those two fields are about, something
like acop; /* mask of enabled coprocessor types */ and pid /* pid
value used with coprocessors */ or something like that.
} mm_context_t;
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
index 26383e0..d6c8841 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -78,6 +78,10 @@ static inline void switch_mm(struct mm_struct *prev,
struct mm_struct *next,
#define deactivate_mm(tsk,mm)do { } while (0)
+extern void switch_cop(struct mm_struct *next);
+extern int use_cop(unsigned long acop, struct task_struct *task);
^ remove that space
+extern void disuse_cop(unsigned long acop, struct mm_struct *mm);
I'd prefer drop or forget :-)
+
/*
* After we have set current-mm to a new value, this activates
* the context for the new mm so we see the new mappings.
diff --git a/arch/powerpc/include/asm/reg.h
b/arch/powerpc/include/asm/reg.h
index 5572e86..30503f8 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -516,6 +516,9 @@
#define SPRN_SIAR780
#define SPRN_SDAR781
+#define SPRN_ACOP 31
+#define SPRN_PID 48
+
Remove the definition of SPRN_PID from reg_booke.h to avoid a double
definition then.
#define SPRN_PA6T_MMCR0 795
#define PA6T_MMCR0_EN0 0x0001UL
#define PA6T_MMCR0_EN1 0x0002UL
diff --git a/arch/powerpc/mm/mmu_context_hash64.c
b/arch/powerpc/mm/mmu_context_hash64.c
index 2535828..d0a79f6 100644
--- a/arch/powerpc/mm/mmu_context_hash64.c
+++ b/arch/powerpc/mm/mmu_context_hash64.c
@@ -18,6 +18,7 @@
#include linux/mm.h
#include linux/spinlock.h
#include linux/idr.h
+#include linux/percpu.h
#include linux/module.h
#include linux/gfp.h
@@ -25,6 +26,82 @@
static DEFINE_SPINLOCK(mmu_context_lock);
static DEFINE_IDA(mmu_context_ida);
+static DEFINE_IDA(cop_ida);
+
+/* Lazy switch the ACOP register */
+static DEFINE_PER_CPU(unsigned long, acop_reg);
+
+void switch_cop(struct mm_struct *next)
+{
+ mtspr(SPRN_PID, next-context.pid);
+ if (next-context.pid
+ __get_cpu_var(acop_reg) != next-context.acop) {
+ mtspr(SPRN_ACOP, next-context.acop);
+ __get_cpu_var(acop_reg) = next-context.acop;
+ }
+}
The above doesn't appear to be called anywhere ?
+int use_cop(unsigned long acop, struct task_struct *task)
+{
+ int pid;
+ int err;
+ struct mm_struct *mm = get_task_mm(task);
+
+ if (!mm)
+ return -EINVAL;
+
+ if (!mm-context.pid) {
+ if (!ida_pre_get(cop_ida, GFP_KERNEL))
+ return -ENOMEM;
+again:
+ spin_lock(mmu_context_lock);
+ err = ida_get_new_above(cop_ida, 1, pid);
+ spin_unlock(mmu_context_lock);
+
+ if (err == -EAGAIN)
+ goto again;
+ else if (err)
+ return err;
+
+ if (pid HASH64_MAX_PID) {
+ spin_lock(mmu_context_lock);
+ ida_remove(cop_ida, pid);
+ spin_unlock(mmu_context_lock);
+ return -EBUSY;
+ }
+ mm-context.pid = pid;
+ mtspr(SPRN_PID, mm-context.pid);
Shouldn't the above be ?
if (mm == current-active_mm)
mtspr()
+ }
+ mm-context.acop |= acop;
Locking ?
+ get_cpu_var(acop_reg) = mm-context.acop;
+ mtspr(SPRN_ACOP, mm-context.acop);
Same comment about testing for current.
+ put_cpu_var(acop_reg);
+
+ return
Re: Initcall ordering
Hi Gary,
(adding linux-i2c)
On Fri, Apr 23, 2010 at 09:56:07AM -0600, Gary Thomas wrote:
I'm having trouble with the I2C devices on my 8347 platform.
The problem is that I2C device probe() functions are only called
once, as the I2C bus is being initialized (in this case fsl_i2c_init())
I have 2 devices on this bus, one device gets it's initcall
before fsl_i2c_init, the second one does not :-( This means
that the second device is never probed.
Can you try this patch?
From: Wolfram Sang w.s...@pengutronix.de
Date: Sat, 24 Apr 2010 03:18:16 +0200
Subject: [PATCH] i2c/mpc: use subsys_initcall() to allow early usage of devices
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
drivers/i2c/busses/i2c-mpc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index f1321f7..32a3bae 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -693,13 +693,12 @@ static int __init fsl_i2c_init(void)
of_register_platform_driver failed (%i)\n, rv);
return rv;
}
+subsys_initcall(fsl_i2c_init);
static void __exit fsl_i2c_exit(void)
{
of_unregister_platform_driver(mpc_i2c_driver);
}
-
-module_init(fsl_i2c_init);
module_exit(fsl_i2c_exit);
MODULE_AUTHOR(Adrian Cox adr...@humboldt.co.uk);
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
