libfdt: Add function to explicitly expand aliases
Kumar has already added alias expansion to fdt_path_offset().
However, in some circumstances it may be convenient for the user of
libfdt to explicitly get the string expansion of an alias. This patch
adds a function to do this, fdt_get_alias(), and uses it to implement
fdt_path_offset().
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/libfdt/fdt_ro.c
===
--- dtc.orig/libfdt/fdt_ro.c2008-08-20 15:59:56.0 +1000
+++ dtc/libfdt/fdt_ro.c 2008-08-20 15:59:56.0 +1000
@@ -141,17 +141,12 @@ int fdt_path_offset(const void *fdt, con
/* see if we have an alias */
if (*path != '/') {
- const char *q;
- int aliasoffset = fdt_path_offset(fdt, "/aliases");
-
- if (aliasoffset < 0)
- return -FDT_ERR_BADPATH;
+ const char *q = strchr(path, '/');
- q = strchr(path, '/');
if (!q)
q = end;
- p = fdt_getprop_namelen(fdt, aliasoffset, path, q - p, NULL);
+ p = fdt_get_alias_namelen(fdt, p, q - p);
if (!p)
return -FDT_ERR_BADPATH;
offset = fdt_path_offset(fdt, p);
@@ -302,6 +297,23 @@ uint32_t fdt_get_phandle(const void *fdt
return fdt32_to_cpu(*php);
}
+const char *fdt_get_alias_namelen(const void *fdt,
+ const char *name, int namelen)
+{
+ int aliasoffset;
+
+ aliasoffset = fdt_path_offset(fdt, "/aliases");
+ if (aliasoffset < 0)
+ return NULL;
+
+ return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
+}
+
+const char *fdt_get_alias(const void *fdt, const char *name)
+{
+ return fdt_get_alias_namelen(fdt, name, strlen(name));
+}
+
int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
{
int pdepth = 0, p = 0;
Index: dtc/libfdt/libfdt.h
===
--- dtc.orig/libfdt/libfdt.h2008-08-20 15:59:56.0 +1000
+++ dtc/libfdt/libfdt.h 2008-08-20 15:59:56.0 +1000
@@ -459,6 +459,32 @@ static inline void *fdt_getprop_w(void *
uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
/**
+ * fdt_get_namelen - get alias based on substring
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_get_alias(), but only examine the first namelen
+ * characters of name for matching the alias name.
+ */
+const char *fdt_get_alias_namelen(const void *fdt,
+ const char *name, int namelen);
+
+/**
+ * fdt_get_alias - retreive the path referenced by a given alias
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ *
+ * fdt_get_alias() retrieves the value of a given alias. That is, the
+ * value of the property named 'name' in the node /aliases.
+ *
+ * returns:
+ * a pointer to the expansion of the alias named 'name', of it exists
+ * NULL, if the given alias or the /aliases node does not exist
+ */
+const char *fdt_get_alias(const void *fdt, const char *name);
+
+/**
* fdt_get_path - determine the full path of a node
* @fdt: pointer to the device tree blob
* @nodeoffset: offset of the node whose path to find
Index: dtc/tests/get_alias.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/get_alias.c 2008-08-20 15:59:56.0 +1000
@@ -0,0 +1,58 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_get_alias()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "tests.h"
+#include "testdata.h"
+
+void check_alias(void *fdt, const char *path, const char *alias)
+{
+ const char *aliaspath;
+
+ aliaspath = fdt_get_alias(fdt, alias);
+
+ if (path && !aliaspath)
+ FAIL("fdt_get_alias(%s) failed\n", alias);
+
+ if (strcmp(aliaspath, path) != 0)
+ FAIL("fd
Re: [PATCH 4/5] powerpc: Make the 64-bit kernel as a position-independent executable
Geert Uytterhoeven writes: > This part broke ppc32: > > | arch/powerpc/kernel/prom.c: In function 'early_init_devtree': > | arch/powerpc/kernel/prom.c:1166: error: '__end_interrupts' undeclared > (first use in this function) > | arch/powerpc/kernel/prom.c:1166: error: (Each undeclared identifier is > reported only once > | arch/powerpc/kernel/prom.c:1166: error: for each function it appears in.) I'm not totally surprised I broke ppc32 somewhere along the line there. :) I think we will end up with having to have a #ifdef CONFIG_RELOCATABLE in there or maybe a test on PHYSICAL_START. It will depend a bit on whether we want to make relocatable 32-bit kernels as PIEs as well. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix memory leaks in QE library
On Mon, Aug 18, 2008 at 04:12:08PM -0500, Timur Tabi wrote: > Fix two memory leaks in the Freescale QE library: add a missing kfree() in > ucc_fast_init() if the ioremap() fails, and update ucc_fast_free() to call > iounmap() on uf_regs. It's been pointed out in http://bugzilla.kernel.org/show_bug.cgi?id=11371 that ucc_slow suffers from the same (welll clsoe enough) 2 problems. Care to fix them aswell? Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Improve message for vio bus entitlement panic
Robert Jennings writes: > Add information regarding the available and required entitlement amounts > to the message displayed for the panic when insufficient entitlement is > provided at boot. I'll queue this up for 2.6.28, unless you tell me it's needed for 2.6.27. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc - Make the irq reverse mapping radix tree lockless
BTW. It would be good to try to turn the GFP_ATOMIC into GFP_KERNEL, maybe using a semaphore instead of a lock to protect insertion vs. initialisation. The old scheme was fine because if the atomic allocation failed, it could fallback to the linear search and try again on the next interrupt. Not anymore. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc - Make the irq reverse mapping radix tree lockless
On Wed, 2008-08-06 at 15:30 +0200, Sebastien Dugue wrote:
> 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.
No need for a spinlock in the irq_host. Make it one global lock, it's
not like scalability of irq_create_mapping() was a big deal and there's
usually only one of those type of hosts anyway.
>
> 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,
>
Re: [PATCH 1/2] powerpc - Separate the irq radix tree insertion and lookup
On Wed, 2008-08-06 at 15:30 +0200, Sebastien Dugue wrote: > irq_radix_revmap() currently serves 2 purposes, irq mapping lookup > and insertion which happen in interrupt and process context respectively. Sounds good, a few nits and it should be good to go. > 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. The atomic doesn't need to be such. Could just be a global. In fact, I don't like your synchronization too much between the init and _insert. What I'd do is, turn your atomic into a simple int - do smp_wmb() and set it to 1 after the tree is initialized, then smb_wmb() again and set it to 2 after the tree has been filled by the init code - in the revmap_lookup path just test that it's >1, no need for a barrier. At worst you'll use the slow path instead of the fast path some time during boot, no big deal. - in the insert path, do an smp_rb() and if it's >0 do the insert with the lock - in the init pre-insert path, use the lock inside the loop for each insertion. that means you may get concurrent attempt to insert but the lock will help there and turn them into 2 insertions of the same translation. Is that a big deal ? If it is, make it be a lookup+insert. Ben. > > 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_h
Re: [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M
Anton Vorontsov writes: > > What do you do about the exception vectors? > > Making a trampoline code in place of exception vectors. See this patch: > > [PATCH 8/8] powerpc: last bits to support kdump on ppc32 It would probably be worth looking at whether we could do a relocatable 32-bit kernel by linking it as a PIE and processing the dynamic relocations at boot time (like the patches I posted recently for 64-bit). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get some more bug-fixes for powerpc. Paul. arch/powerpc/kernel/crash_dump.c | 31 + arch/powerpc/kernel/ibmebus.c | 12 --- arch/powerpc/kernel/vio.c |2 +- arch/powerpc/platforms/cell/spufs/run.c | 15 +++--- arch/powerpc/platforms/cell/spufs/sched.c | 11 -- drivers/of/device.c | 10 + 6 files changed, 50 insertions(+), 31 deletions(-) Brian King (1): powerpc: Fix vio_bus_probe oops on probe error Ilpo Järvinen (1): powerpc/spufs: Remove invalid semicolon after if statement Jeremy Kerr (2): powerpc/spufs: fix npc setting for NOSCHED contexts powerpc/spufs: reference context while dropping state mutex in scheduler Joachim Fenkes (1): powerpc/ibmebus: Restore "name" sysfs attribute on ibmebus devices Michael Ellerman (1): powerpc: Fix /dev/oldmem interface for kdump ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: CONFIG_BOOTX_TEXT breaks PowerBook 3400 with BootX
On Wed, 2008-08-20 at 03:23 +1000, Finn Thain wrote: > Hi All, > > When I build kernels with CONFIG_BOOTX_TEXT enabled I can't boot a PB 3400 > with BootX. I get a black screen with "Welcome to Linux" at the top, then > it appears to hang. Debian kernels are configured this way and suffer the > same problem. > > I don't know if Quik is affected. It is a bit of a hassle at install time > since the (mediabay) floppy drive can't co-exist with the (mediabay) > CDROM, so I'm using BootX to do the Debian install. > > The Debian Sarge 2.6.8-4 kernel does not seem to have this problem though > kernel.org 2.6.16 and later versions do. > > Any ideas? How "late" have you tried ? I remember fixing something at one point... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] kvmppc: magic page paravirtualization - guest part
Hi Christian, One very minor nit. On Tue, Aug 19, 2008 at 12:36:43PM +0200, [EMAIL PROTECTED] wrote: > [diffstat] > mm/page_alloc.c|1 > void kvm_guest_init(void); > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -550,6 +550,7 @@ > prefetchw(p + 1); > __ClearPageReserved(p); > set_page_count(p, 0); > + > } > > set_page_refcounted(page); I guess this is a leftover from some debugging but still should be killed :) Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Tue, 2008-08-19 at 16:58 -0700, Jeremy Fitzhardinge wrote: > Benjamin Herrenschmidt wrote: > >> Ok, there are two cases where it's ok : > >> > >> 1 - in stop_machine, considering we are not touching code executed in > >> NMI handlers. > >> 2 - when using my replace_instruction_safe() which uses a temporary > >> breakpoint when doing the instruction replacement. > >> > >> In those cases you could use text_poke_early(). > >> > > > > Note that vmap/vunmap will be very slow. > > > > Don't we have Nick's speedups now? Not sure what speedups this is, but it's stlil not something you want to do a lot ... setting up and tearing down MMU mappings isn't something I'd like to see happening on a per-mcount basis. Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Benjamin Herrenschmidt wrote: >> Ok, there are two cases where it's ok : >> >> 1 - in stop_machine, considering we are not touching code executed in >> NMI handlers. >> 2 - when using my replace_instruction_safe() which uses a temporary >> breakpoint when doing the instruction replacement. >> >> In those cases you could use text_poke_early(). >> > > Note that vmap/vunmap will be very slow. > Don't we have Nick's speedups now? J ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibmebus/of_platform: Move "name" sysfs attribute into generic OF devices
Joachim Fenkes writes: > > Is this a bugfix that is needed for 2.6.27? > > Yes, definitely. The eHCA userspace driver relies on the name attribute to > check for valid adapters (it checks that the name is "lhca"), so with the > name attribute gone, eHCA userspace will cease to work. OK, I'll put it in. Please, in future, always say explicitly if you think a patch needs to go in to the kernel we're currently stablizing. Otherwise, I'll generally assume it's for the next merge window. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DMA Cache problem on PPC8248.
Hi All, We are using PPC8248 provided by freescale and the kernel 2.6.10. I believe we have cache problem. We are allocating DMA buffers in our driver. If we increase the DMA buffer size the board hangs/halts(when try to load more applications). If we reduce the DMA buffer size, then we can run all our applications. Is there any way I can get around this problem. Thanks Jayasri ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
> I don't know the status of these platforms > > asm-blackfin/irq.h:#define NO_IRQ ((unsigned int)(-1)) > asm-mn10300/irq.h:#define NO_IRQ INT_MAX > asm-parisc/irq.h:#define NO_IRQ (-1) In need of fixing, assuming they actually use NO_IRQ for anything - don't be mislead by the fact they may have old defines lying around. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
> > Ok, there are two cases where it's ok : > > 1 - in stop_machine, considering we are not touching code executed in > NMI handlers. > 2 - when using my replace_instruction_safe() which uses a temporary > breakpoint when doing the instruction replacement. > > In those cases you could use text_poke_early(). Note that vmap/vunmap will be very slow. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
> Register GPR30 is always zero... (also true for the other oops) >From my experiments, -a- non volatile register gets corrupted. Not always the same and not always with the same value. The corruption -seems- to happen due to corruption of the location on the stack where it was saved to / restored from in a previous function call or interrupt. I haven't yet tracked down what actually whacks the stack. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
On 8/19/08, Alan Cox <[EMAIL PROTECTED]> wrote: > > Shouldn't this be > > > > > - if (client->irq <= NO_IRQ) > > > > instead of > > > NO_IRQ is obsolete. client->irq != is the test and IRQ numbers are > unsigned. I don't know the status of these platforms asm-blackfin/irq.h:#define NO_IRQ ((unsigned int)(-1)) asm-mn10300/irq.h:#define NO_IRQINT_MAX asm-parisc/irq.h:#define NO_IRQ (-1) -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
On Tue, Aug 19, 2008 at 04:39:09PM -0400, Jon Smirl wrote:
> On 8/12/08, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> > On a PowerPC board with ds1374 RTC I'm getting this error while
> > RTC tries to probe:
> >
> > rtc-ds1374 0-0068: unable to request IRQ
> >
> > This happens because I2C probing code (drivers/of/of_i2c.c) is
> > specifying IRQ0 for 'no irq' case, which is correct.
>
> Shouldn't this be
>
> > - if (client->irq <= NO_IRQ)
>
> instead of
>
> > - if (client->irq < 0)
> > + if (client->irq <= 0)
>
> Since NO_IRQ can vary by platform (0 or -1)?
First of all, NO_IRQ is not defined for every architecture. You can't
use it for truly cross-platform drivers.
Secondly, "<= 0" will work for both NO_IRQ == 0 and NO_IRQ == -1,
since client->irq is signed type.
As for false positives, I don't believe that there is any platform
that use IRQ0 for external interrupts.
[...]
> In of_i2c.c shouldn't there be an error check?
>
> info.irq = irq_of_parse_and_map(node, 0);
>
> if (info.irq < NO_IRQ) {report error; continue }
irq_of_parse_and_map() returns unsigned type, plus it is defined
only for PowerPC, and for PowerPC NO_IRQ is always 0.
--
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: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Tue, 19 Aug 2008, Mathieu Desnoyers wrote:
>
> Ok, there are two cases where it's ok :
>
> 1 - in stop_machine, considering we are not touching code executed in
> NMI handlers.
> 2 - when using my replace_instruction_safe() which uses a temporary
> breakpoint when doing the instruction replacement.
>
> In those cases you could use text_poke_early().
>
> See
> http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=blob;f=arch/x86/kernel/immediate.c;h=7789e2c75bf03e645f15759d5dff0c1698493f92;hb=HEAD
>
> For a use example. Basically it looks like :
>
>
> 360 pages[0] = virt_to_page((void *)bypass_eip);
> 361 vaddr = vmap(pages, 1, VM_MAP, PAGE_KERNEL);
> 362 BUG_ON(!vaddr);
> 363 text_poke_early(&vaddr[bypass_eip & ~PAGE_MASK],
> 364 (void *)addr, size);
> 365 /*
> 366 * Fill the rest with nops.
> 367 */
> 368 len = NR_NOPS - size;
> 369 add_nops((void *)
> 370 &vaddr[(bypass_eip & ~PAGE_MASK) + size],
> 371 len);
> 372 print_dbg_bytes("inserted nops",
> 373 &vaddr[(bypass_eip & ~PAGE_MASK) + size], len);
> 374 vunmap(vaddr);
vunmap can not be called with interrupts disabled, and this is exactly
what my code does.
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
> Shouldn't this be > > > - if (client->irq <= NO_IRQ) > > instead of NO_IRQ is obsolete. client->irq != is the test and IRQ numbers are unsigned. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
On 8/12/08, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On a PowerPC board with ds1374 RTC I'm getting this error while
> RTC tries to probe:
>
> rtc-ds1374 0-0068: unable to request IRQ
>
> This happens because I2C probing code (drivers/of/of_i2c.c) is
> specifying IRQ0 for 'no irq' case, which is correct.
Shouldn't this be
> - if (client->irq <= NO_IRQ)
instead of
> - if (client->irq < 0)
> + if (client->irq <= 0)
Since NO_IRQ can vary by platform (0 or -1)? Work is underway to get
everyone onto NO_IRQ=0 but I don't know if it is finished yet. It is
much cleaner to use the NO_IRQ define.
In of_i2c.c shouldn't there be an error check?
info.irq = irq_of_parse_and_map(node, 0);
if (info.irq < NO_IRQ) {report error; continue }
>
> The driver handles this incorrectly, though. This patch fixes it.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> drivers/rtc/rtc-ds1374.c | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
> index 640acd2..a150418 100644
> --- a/drivers/rtc/rtc-ds1374.c
> +++ b/drivers/rtc/rtc-ds1374.c
> @@ -173,7 +173,7 @@ static int ds1374_read_alarm(struct device *dev, struct
> rtc_wkalrm *alarm)
> int cr, sr;
> int ret = 0;
>
> - if (client->irq < 0)
> + if (client->irq <= 0)
> return -EINVAL;
>
> mutex_lock(&ds1374->mutex);
> @@ -212,7 +212,7 @@ static int ds1374_set_alarm(struct device *dev, struct
> rtc_wkalrm *alarm)
> int cr;
> int ret = 0;
>
> - if (client->irq < 0)
> + if (client->irq <= 0)
> return -EINVAL;
>
> ret = ds1374_read_time(dev, &now);
> @@ -381,7 +381,7 @@ static int ds1374_probe(struct i2c_client *client,
> if (ret)
> goto out_free;
>
> - if (client->irq >= 0) {
> + if (client->irq > 0) {
> ret = request_irq(client->irq, ds1374_irq, 0,
> "ds1374", client);
> if (ret) {
> @@ -401,7 +401,7 @@ static int ds1374_probe(struct i2c_client *client,
> return 0;
>
> out_irq:
> - if (client->irq >= 0)
> + if (client->irq > 0)
> free_irq(client->irq, client);
>
> out_free:
> @@ -414,7 +414,7 @@ static int __devexit ds1374_remove(struct i2c_client
> *client)
> {
> struct ds1374 *ds1374 = i2c_get_clientdata(client);
>
> - if (client->irq >= 0) {
> + if (client->irq > 0) {
> mutex_lock(&ds1374->mutex);
> ds1374->exiting = 1;
> mutex_unlock(&ds1374->mutex);
>
> --
> 1.5.6.3
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Tue, 19 Aug 2008, Eran Liberty wrote: > Steven Rostedt wrote: > > > > > Testing tracer sched_switch: PASSED > > > Testing tracer ftrace: PASSED > > > Testing dynamic ftrace: PASSED Do you have PREEMPT_TRACER enabled, or any other tracer for that matter? -- Steve > > > > > > Oops: Exception in kernel mode, sig: 11 [#1] > > > Exsw1600 > > > Modules linked in: > > > NIP: c00bbb20 LR: c00bbb20 CTR: > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
> "Anton" == Anton Vorontsov <[EMAIL PROTECTED]> writes: Anton> On a PowerPC board with ds1374 RTC I'm getting this error while Anton> RTC tries to probe: Anton> rtc-ds1374 0-0068: unable to request IRQ Anton> This happens because I2C probing code (drivers/of/of_i2c.c) is Anton> specifying IRQ0 for 'no irq' case, which is correct. Anton> The driver handles this incorrectly, though. This patch fixes it. Great, I was just about to send a similar patch. Another advantage of using 0 for 'no irq' is for I2C_BOARD_INFO(). With that you can simply not assign anything to .irq instead of having to set it to -1. Acked-by: Peter Korsgaard <[EMAIL PROTECTED]> -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] Rework PowerPC 44x board support
On Tue, 19 Aug 2008 20:26:12 +0200 Stefan Roese <[EMAIL PROTECTED]> wrote: > On Tuesday 19 August 2008, Josh Boyer wrote: > > The following patch series reworks the board support code for PowerPC 44x > > platforms. It eliminates a number of redundant .c files and add a > > ppc44x_simple.c file that has an explicit list of boards that are supported > > by it. This is the same mechanism that Grant Likely has used for MPC 5200 > > boards. > > > > It also adds some more explicit support for Glacier and Yosemite boards, as > > those boards were using a board level compatible property in their DTS > > files that was a bit confusing. > > > > Review would be appreciated. Tested on Sequoia, and I plan on testing on > > as many boards as I can before committing to my tree. > > Looks great at first glance. I'll try to do some testing here too in the next > few days. That would be much appreciated. I have a number of the effected boards, but I don't have them all so any testing you can do would be awesome. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] Rework PowerPC 44x board support
On Tuesday 19 August 2008, Josh Boyer wrote: > The following patch series reworks the board support code for PowerPC 44x > platforms. It eliminates a number of redundant .c files and add a > ppc44x_simple.c file that has an explicit list of boards that are supported > by it. This is the same mechanism that Grant Likely has used for MPC 5200 > boards. > > It also adds some more explicit support for Glacier and Yosemite boards, as > those boards were using a board level compatible property in their DTS > files that was a bit confusing. > > Review would be appreciated. Tested on Sequoia, and I plan on testing on > as many boards as I can before committing to my tree. Looks great at first glance. I'll try to do some testing here too in the next few days. Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: qemu platform patches
On Aug 18, 2008, at 9:17 PM, Miklos Vajna wrote: Hi! I recently started to search for a solution to boot a Linux-2.6-based kernel in qemu-system-ppc. Google found two of your interesting patches: http://patchwork.ozlabs.org/linuxppc/patchcontent?id=13689 http://patchwork.ozlabs.org/linuxppc/patchcontent?id=13690 ... Sadly the build fails at your qemu.c, with: BOOTCC arch/powerpc/boot/qemu.o arch/powerpc/boot/qemu.c: In function 'tree_fixups': arch/powerpc/boot/qemu.c:203: warning: implicit declaration of function 'dt_find_initrd' arch/powerpc/boot/qemu.c: In function 'platform_init': arch/powerpc/boot/qemu.c:230: error: 'struct platform_ops' has no member named 'find_vmlinuz' make[1]: *** [arch/powerpc/boot/qemu.o] Error 1 make: *** [zImage] Error 2 Two questions: 1) Do you remember what was the exact commit you worked with, where qemu.c compiled fine? (In case you have newer patches somewhere, I'm interested as well :) ) From those messages, there were other patches posted about the same time that did some radical splits to the zImage infrastructure code, allowing it to become a helper instead of just a contained image. And I do have later patches that were working (better). I have even booted a linux-next kernel just before 2.6.27 opened, after doing some fixups. However, I suffer from wanting to perferct the function of the patches and never get the base part out :-). For instance, when working with 2.6.27, I got ISA memory working and some video output. Also, the ide-generic driver now has to be enabled on the command line to give the same function we previously had. That, combined with kernel for ppc-qemu is my hobby and my work keeps interrupting me. The current state is: Rob Landley's Firmware Linux has a ppc_rom.bin (and source) written by me that probes qemu nvram for the size of memory, location of a command line (-append) and initrd (-initrd), patching a device tree linked into it, then parses the kernel (or other elf file) loaded via -elf a kernel and jumps into it whereever it was loaded. The kernel has a corresponding platform patch that only recognises qemu (based on the kernel patch you found). The version Rob has works on 2.6.25.9 with serial, ide, and isa ne2000. Since then I got isa memory to enable video (with hacks and you only see 1/4 of the screen). http://landley.net/hg/firmware/raw-file/6f1e69d7e7f5/sources/toys/make- ppc_rom.tar.bz2 http://landley.net/hg/firmware/raw-file/59e22ea53e6a/sources/patches/ linux-ppcqemu.patch http://landley.net/hg/firmware/raw-file/0d8e80202e94/sources/patches/ linux-2.6.23-ppcne2khack.patch 2) I'm not exactly sure about the build process in the case of qemu, using your patches. Am I right about I just have to compile the kernel, I'll be given a ppc_rom.bin and the usual vmlinux file, then I can boot these with qemu? The version that you have built a rom out of the code in arch/powerpc/boot after patching. The new version builds the rom in a shell script. Either way, it activated by calling it ppc_rom.bin and pointing QEMU's library drectory to it with the -L flag. This code works for qemu -kernel when the kernel is patched to recogonise the qemu platform specified in the device-tree. Going forward, it probably needs to become a dtbImage or a combination rom and optional image. Hopefully the rest is clear, currently I have 2.4.36.1 in qemu and it would be really time to upgrade to 2.6 :) People were successfully able to get arch/ppc kernel to boot as last ase 2.6.26, at least until they got to userspace. That doesn't provide a way forward, as ppc is now removed, but it may provide a temporary option. I can't promise a timeframe, but I do want to get the patches updated and out. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
CONFIG_BOOTX_TEXT breaks PowerBook 3400 with BootX
Hi All, When I build kernels with CONFIG_BOOTX_TEXT enabled I can't boot a PB 3400 with BootX. I get a black screen with "Welcome to Linux" at the top, then it appears to hang. Debian kernels are configured this way and suffer the same problem. I don't know if Quik is affected. It is a bit of a hassle at install time since the (mediabay) floppy drive can't co-exist with the (mediabay) CDROM, so I'm using BootX to do the Debian install. The Debian Sarge 2.6.8-4 kernel does not seem to have this problem though kernel.org 2.6.16 and later versions do. Any ideas? Tia, Finn ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
>
> On Mon, 18 Aug 2008, Mathieu Desnoyers wrote:
>
> > * Steven Rostedt ([EMAIL PROTECTED]) wrote:
> > >
> > > On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote:
> > >
> > > >
> > > > > Hmm, this was originally copied from x86, where we did a cmpxchg, but
> > > > > that
> > > > > is probably not needed since all of this is done in kstop_machine.
> > > > > Also,
> > > > > only the "get" is needed. If we don't fault there, we wont fault on
> > > > > the
> > > > > put (unless we have permissions wrong, and that would be a bug).
> > > >
> > > > Would it ? How do we make sure the kernel text is mapped writeable ?
> > >
> > > We map it writeable if FTRACE is enabled.
> > >
> >
> > Argh. See text_poke(). It's there exactly for this purpose on x86.
> >
>
> OK, I just tried text_poke and it unfortunately fails. The problem is that
> it requires that the text you are changing is aligned and fits on one
> page. We have no control over that.
>
> -- Steve
>
Ok, there are two cases where it's ok :
1 - in stop_machine, considering we are not touching code executed in
NMI handlers.
2 - when using my replace_instruction_safe() which uses a temporary
breakpoint when doing the instruction replacement.
In those cases you could use text_poke_early().
See
http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=blob;f=arch/x86/kernel/immediate.c;h=7789e2c75bf03e645f15759d5dff0c1698493f92;hb=HEAD
For a use example. Basically it looks like :
360 pages[0] = virt_to_page((void *)bypass_eip);
361 vaddr = vmap(pages, 1, VM_MAP, PAGE_KERNEL);
362 BUG_ON(!vaddr);
363 text_poke_early(&vaddr[bypass_eip & ~PAGE_MASK],
364 (void *)addr, size);
365 /*
366 * Fill the rest with nops.
367 */
368 len = NR_NOPS - size;
369 add_nops((void *)
370 &vaddr[(bypass_eip & ~PAGE_MASK) + size],
371 len);
372 print_dbg_bytes("inserted nops",
373 &vaddr[(bypass_eip & ~PAGE_MASK) + size], len);
374 vunmap(vaddr);
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 18 Aug 2008, Mathieu Desnoyers wrote: > * Steven Rostedt ([EMAIL PROTECTED]) wrote: > > > > On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote: > > > > > > > > > Hmm, this was originally copied from x86, where we did a cmpxchg, but > > > > that > > > > is probably not needed since all of this is done in kstop_machine. > > > > Also, > > > > only the "get" is needed. If we don't fault there, we wont fault on the > > > > put (unless we have permissions wrong, and that would be a bug). > > > > > > Would it ? How do we make sure the kernel text is mapped writeable ? > > > > We map it writeable if FTRACE is enabled. > > > > Argh. See text_poke(). It's there exactly for this purpose on x86. > OK, I just tried text_poke and it unfortunately fails. The problem is that it requires that the text you are changing is aligned and fits on one page. We have no control over that. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] powerpc: Make the 64-bit kernel as a position-independent executable
On Wed, 13 Aug 2008, Paul Mackerras wrote: > --- a/arch/powerpc/kernel/prom.c > +++ b/arch/powerpc/kernel/prom.c > @@ -1163,7 +1163,9 @@ void __init early_init_devtree(void *params) > parse_early_param(); > > /* Reserve LMB regions used by kernel, initrd, dt, etc... */ > - lmb_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START); > + lmb_reserve(0, __end_interrupts - _stext); > + lmb_reserve(__pa(__end_interrupts), > + klimit - (unsigned long)__end_interrupts); > reserve_kdump_trampoline(); > reserve_crashkernel(); > early_reserve_mem(); This part broke ppc32: | arch/powerpc/kernel/prom.c: In function 'early_init_devtree': | arch/powerpc/kernel/prom.c:1166: error: '__end_interrupts' undeclared (first use in this function) | arch/powerpc/kernel/prom.c:1166: error: (Each undeclared identifier is reported only once | arch/powerpc/kernel/prom.c:1166: error: for each function it appears in.) After applying the patch below, I was able to build and boot a kernel for the Sequoia. Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> --- arch/powerpc/kernel/prom.c |4 1 file changed, 4 insertions(+) --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -1163,9 +1163,13 @@ void __init early_init_devtree(void *par parse_early_param(); /* Reserve LMB regions used by kernel, initrd, dt, etc... */ +#ifdef CONFIG_PPC64 lmb_reserve(0, __end_interrupts - _stext); lmb_reserve(__pa(__end_interrupts), klimit - (unsigned long)__end_interrupts); +#else + lmb_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START); +#endif reserve_kdump_trampoline(); reserve_crashkernel(); early_reserve_mem(); 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 · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[alsa-devel] [PATCH v2] duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
Takashi Iwai wrote:
> At Tue, 19 Aug 2008 08:15:05 +0200 (CEST),
> Johannes Berg wrote:
>> roel kluin wrote:
>>> untested, is it correct?
>> not a clue, do you know how long ago that was? :)
>> does the driver check endianness anywhere?
>
> AFAIK snd-aoa supports only bit-endian formats (at least in
> sound/aoa/soundbus/i2sbus-pcm.c), so this addition makes little
> sense.
>
> Better to drop the duplicated words there.
Thanks Johannes and Takashi,
FWIW this removes the duplicates.
---
Remove duplicate assignment of SNDRV_PCM_FMTBIT_S{16,24}_BE bits
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/sound/aoa/codecs/snd-aoa-codec-tas.c
b/sound/aoa/codecs/snd-aoa-codec-tas.c
index 7a16a33..6c515b2 100644
--- a/sound/aoa/codecs/snd-aoa-codec-tas.c
+++ b/sound/aoa/codecs/snd-aoa-codec-tas.c
@@ -654,15 +654,13 @@ static struct snd_kcontrol_new bass_control = {
static struct transfer_info tas_transfers[] = {
{
/* input */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
- SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
SNDRV_PCM_RATE_48000,
.transfer_in = 1,
},
{
/* output */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
- SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
SNDRV_PCM_RATE_48000,
.transfer_in = 0,
},
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc, scc: duplicate SCC_UHC_USBCEN
Kou Ishizaki wrote:
>
> Roel,
>
>> untested, is it correct?
>
> Your patch is correct.
>
> Thanks for your pointing it out and sending the patch. I tested your
> patch and it works good.
>
> Fortunately, this bug is not fatal because it seems that the SCC-UHC
> sets SCC_UHC_USBEN and SCC_UHC_USBCEN at once.
>
>
> Your patch does not contain 'Signed-off-by' line. Could you re-post it
> with your sign?
Sorry for that and thanks for testing.
---
duplicate SCC_UHC_USBCEN
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/platforms/cell/celleb_scc_uhc.c
b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
index d63b720..b086f33 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_uhc.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
@@ -31,7 +31,7 @@
static inline int uhc_clkctrl_ready(u32 val)
{
- const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBCEN;
+ const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBEN;
return((val & mask) == mask);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 9/9] powerpc/44x: Add explicit Yosemite support
Add the Yosemite board to the explicitly supported list for ppc44x_simple
boards and remove the compatible entry for bamboo from the DTS file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/yosemite.dts |2 +-
arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/yosemite.dts
b/arch/powerpc/boot/dts/yosemite.dts
index e39422a..1fa3cb4 100644
--- a/arch/powerpc/boot/dts/yosemite.dts
+++ b/arch/powerpc/boot/dts/yosemite.dts
@@ -15,7 +15,7 @@
#address-cells = <2>;
#size-cells = <1>;
model = "amcc,yosemite";
- compatible = "amcc,yosemite","amcc,bamboo";
+ compatible = "amcc,yosemite";
dcr-parent = <&{/cpus/[EMAIL PROTECTED]>;
aliases {
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c
b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 4e78e04..43b8db9 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -49,6 +49,7 @@ static char *board[] __initdata = {
"amcc,rainier",
"amcc,sequoia",
"amcc,taishan",
+ "amcc,yosemite",
NULL
};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/9] powerpc/44x: Add explicit support for AMCC Glacier
Add explicit support for the AMCC Glacier eval board to Kconfig and the
ppc44x_simple file. Also removes the cayonlands compatible entry from the
DTS file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/glacier.dts |2 +-
arch/powerpc/platforms/44x/Kconfig | 11 +++
arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
3 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/glacier.dts
b/arch/powerpc/boot/dts/glacier.dts
index 24cf0db..f3787a2 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -14,7 +14,7 @@
#address-cells = <2>;
#size-cells = <1>;
model = "amcc,glacier";
- compatible = "amcc,glacier", "amcc,canyonlands";
+ compatible = "amcc,glacier";
dcr-parent = <&{/cpus/[EMAIL PROTECTED]>;
aliases {
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index e0bea83..f8ef279 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -92,6 +92,17 @@ config CANYONLANDS
help
This option enables support for the AMCC PPC460EX evaluation board.
+config GLACIER
+ bool "Glacier"
+ depends on 44x
+ default n
+ select PPC44x_SIMPLE
+ select 460EX # Odd since it uses 460GT but the effects are the same
+ select PCI
+ select PPC4xx_PCI_EXPRESS
+ help
+ This option enables support for the AMCC PPC460GT evaluation board.
+
config YOSEMITE
bool "Yosemite"
depends on 44x
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c
b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 067cddb..4e78e04 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -43,6 +43,7 @@ machine_device_initcall(ppc44x_simple, ppc44x_device_probe);
static char *board[] __initdata = {
"amcc,bamboo",
"amcc,cayonlands",
+ "amcc,glacier",
"ibm,ebony",
"amcc,katmai",
"amcc,rainier",
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/9] powerpc/44x: Migrate Taishan support to ppc44x_simple
Migrate the AMCC Taishan board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig |1 +
arch/powerpc/platforms/44x/Makefile |1 -
arch/powerpc/platforms/44x/taishan.c | 72 --
3 files changed, 1 insertions(+), 73 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/taishan.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 84e2a70..e0bea83 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -40,6 +40,7 @@ config TAISHAN
bool "Taishan"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440GX
select PCI
help
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index a8a92c1..6981331 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,7 +1,6 @@
obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY)+= ebony.o
-obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
diff --git a/arch/powerpc/platforms/44x/taishan.c
b/arch/powerpc/platforms/44x/taishan.c
deleted file mode 100644
index 49c78b2..000
--- a/arch/powerpc/platforms/44x/taishan.c
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
- * Taishan board specific routines based off ebony.c code
- * original copyrights below
- *
- * Matt Porter <[EMAIL PROTECTED]>
- * Copyright 2002-2005 MontaVista Software Inc.
- *
- * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
- * Copyright (c) 2003-2005 Zultys Technologies
- *
- * Rewritten and ported to the merged powerpc tree:
- * Copyright 2007 David Gibson <[EMAIL PROTECTED]>, IBM Corporation.
- *
- * Modified from ebony.c for taishan:
- * Copyright 2007 Hugh Blemings <[EMAIL PROTECTED]>, 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) any later version.
- */
-
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static __initdata struct of_device_id taishan_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init taishan_device_probe(void)
-{
- of_platform_bus_probe(NULL, taishan_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(taishan, taishan_device_probe);
-
-/*
- * Called very early, MMU is off, device-tree isn't unflattened
- */
-static int __init taishan_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,taishan"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(taishan) {
- .name = "Taishan",
- .probe = taishan_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq= uic_get_irq,
- .restart= ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/9] powerpc/44x: Migrate Sequoia support to ppc44x_simple
Migrate the AMCC Sequoia board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig |1 +
arch/powerpc/platforms/44x/Makefile |1 -
arch/powerpc/platforms/44x/sequoia.c | 63 --
3 files changed, 1 insertions(+), 64 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/sequoia.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 89e7f1f..84e2a70 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -31,6 +31,7 @@ config SEQUOIA
bool "Sequoia"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440EPX
help
This option enables support for the AMCC PPC440EPX evaluation board.
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index c201af6..a8a92c1 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -3,7 +3,6 @@ obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY)+= ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
-obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/sequoia.c
b/arch/powerpc/platforms/44x/sequoia.c
deleted file mode 100644
index 49eb73d..000
--- a/arch/powerpc/platforms/44x/sequoia.c
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * Sequoia board specific routines
- *
- * Valentine Barshak <[EMAIL PROTECTED]>
- * Copyright 2007 MontaVista Software Inc.
- *
- * Based on the Bamboo code by
- * Josh Boyer <[EMAIL PROTECTED]>
- * Copyright 2007 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) any later version.
- */
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-static __initdata struct of_device_id sequoia_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init sequoia_device_probe(void)
-{
- of_platform_bus_probe(NULL, sequoia_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(sequoia, sequoia_device_probe);
-
-static int __init sequoia_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,sequoia"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(sequoia) {
- .name = "Sequoia",
- .probe = sequoia_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq= uic_get_irq,
- .restart= ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/9] powerpc/44x: Migrate Rainier support to ppc44x_simple
Migrate the AMCC Rainier board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig |1 +
arch/powerpc/platforms/44x/Makefile |1 -
arch/powerpc/platforms/44x/rainier.c | 62 --
3 files changed, 1 insertions(+), 63 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/rainier.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 66d4499..89e7f1f 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -60,6 +60,7 @@ config RAINIER
bool "Rainier"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440GRX
select PCI
help
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 2eb1cbe..c201af6 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,7 +4,6 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
-obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/rainier.c
b/arch/powerpc/platforms/44x/rainier.c
deleted file mode 100644
index 4f1ff84..000
--- a/arch/powerpc/platforms/44x/rainier.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Rainier board specific routines
- *
- * Valentine Barshak <[EMAIL PROTECTED]>
- * Copyright 2007 MontaVista Software Inc.
- *
- * Based on the Bamboo code by
- * Josh Boyer <[EMAIL PROTECTED]>
- * Copyright 2007 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) any later version.
- */
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static __initdata struct of_device_id rainier_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init rainier_device_probe(void)
-{
- of_platform_bus_probe(NULL, rainier_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(rainier, rainier_device_probe);
-
-static int __init rainier_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,rainier"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(rainier) {
- .name = "Rainier",
- .probe = rainier_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq= uic_get_irq,
- .restart= ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/9] powerpc/44x: Migrate Katmai support to ppc44x_simple
Migrate the AMCC Katmai board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig |1 +
arch/powerpc/platforms/44x/Makefile |1 -
arch/powerpc/platforms/44x/katmai.c | 62 ---
3 files changed, 1 insertions(+), 63 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/katmai.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 92ba2d8..66d4499 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -49,6 +49,7 @@ config KATMAI
bool "Katmai"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440SPe
select PCI
select PPC4xx_PCI_EXPRESS
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 0ab626d..2eb1cbe 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,7 +4,6 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
-obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
diff --git a/arch/powerpc/platforms/44x/katmai.c
b/arch/powerpc/platforms/44x/katmai.c
deleted file mode 100644
index 44f4b3a..000
--- a/arch/powerpc/platforms/44x/katmai.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Katmai board specific routines
- *
- * Benjamin Herrenschmidt <[EMAIL PROTECTED]>
- * Copyright 2007 IBM Corp.
- *
- * Based on the Bamboo code by
- * Josh Boyer <[EMAIL PROTECTED]>
- * Copyright 2007 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) any later version.
- */
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static __initdata struct of_device_id katmai_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init katmai_device_probe(void)
-{
- of_platform_bus_probe(NULL, katmai_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(katmai, katmai_device_probe);
-
-static int __init katmai_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,katmai"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(katmai) {
- .name = "Katmai",
- .probe = katmai_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq= uic_get_irq,
- .restart= ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/9] powerpc/44x: Migrate Canyonlands support to ppc44x_simple
Migrate the AMCC Canyonlands board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig |1 +
arch/powerpc/platforms/44x/Makefile |1 -
arch/powerpc/platforms/44x/canyonlands.c | 63 --
3 files changed, 1 insertions(+), 64 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/canyonlands.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 0958285..92ba2d8 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -81,6 +81,7 @@ config CANYONLANDS
bool "Canyonlands"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 460EX
select PCI
select PPC4xx_PCI_EXPRESS
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index ca18a32..0ab626d 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -8,5 +8,4 @@ obj-$(CONFIG_KATMAI)+= katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
-obj-$(CONFIG_CANYONLANDS) += canyonlands.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/canyonlands.c
b/arch/powerpc/platforms/44x/canyonlands.c
deleted file mode 100644
index 3949289..000
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * Canyonlands board specific routines
- *
- * Copyright 2008 DENX Software Engineering, Stefan Roese <[EMAIL PROTECTED]>
- *
- * Based on the Katmai code by
- * Benjamin Herrenschmidt <[EMAIL PROTECTED]>
- * Copyright 2007 IBM Corp.
- * Josh Boyer <[EMAIL PROTECTED]>
- * Copyright 2007 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) any later version.
- */
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static __initdata struct of_device_id canyonlands_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init canyonlands_device_probe(void)
-{
- of_platform_bus_probe(NULL, canyonlands_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(canyonlands, canyonlands_device_probe);
-
-static int __init canyonlands_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,canyonlands"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(canyonlands) {
- .name = "Canyonlands",
- .probe = canyonlands_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq= uic_get_irq,
- .restart= ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/9] powerpc/44x: Migrate Bamboo support to ppc44x_simple
Migrate the AMCC Bamboo board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig |2 +
arch/powerpc/platforms/44x/Makefile |2 -
arch/powerpc/platforms/44x/bamboo.c | 62 ---
3 files changed, 2 insertions(+), 64 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/bamboo.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 97c634c..0958285 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -2,6 +2,7 @@ config BAMBOO
bool "Bamboo"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440EP
select PCI
help
@@ -90,6 +91,7 @@ config YOSEMITE
bool "Yosemite"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440EP
select PCI
help
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 73c1df5..ca18a32 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -2,8 +2,6 @@ obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY)+= ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
-obj-$(CONFIG_BAMBOO) += bamboo.o
-obj-$(CONFIG_YOSEMITE) += bamboo.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
diff --git a/arch/powerpc/platforms/44x/bamboo.c
b/arch/powerpc/platforms/44x/bamboo.c
deleted file mode 100644
index cef169e..000
--- a/arch/powerpc/platforms/44x/bamboo.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Bamboo board specific routines
- *
- * Wade Farnsworth <[EMAIL PROTECTED]>
- * Copyright 2004 MontaVista Software Inc.
- *
- * Rewritten and ported to the merged powerpc tree:
- * Josh Boyer <[EMAIL PROTECTED]>
- * Copyright 2007 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) any later version.
- */
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static __initdata struct of_device_id bamboo_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init bamboo_device_probe(void)
-{
- of_platform_bus_probe(NULL, bamboo_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(bamboo, bamboo_device_probe);
-
-static int __init bamboo_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,bamboo"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(bamboo) {
- .name = "Bamboo",
- .probe = bamboo_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq= uic_get_irq,
- .restart= ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
This adds a common board file for almost all of the "simple" PowerPC 44x
boards that exist today. This is intended to be a single place to add
support for boards that do not differ in platform support from most of the
evaluation boards that are used as reference platforms. Boards that have
specific requirements or custom hardware setup should still have their own
board.c file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig |7 +++
arch/powerpc/platforms/44x/Makefile|1 +
arch/powerpc/platforms/44x/ppc44x_simple.c | 81
3 files changed, 89 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/ppc44x_simple.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 249ba01..97c634c 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -127,6 +127,13 @@ config XILINX_VIRTEX440_GENERIC_BOARD
Most Virtex 5 designs should use this unless it needs to do some
special configuration at board probe time.
+config PPC44x_SIMPLE
+ bool "Simple PowerPC 44x board support"
+ depends on 44x
+ default n
+ help
+ This option enables the simple PowerPC 44x platform support.
+
# 44x specific CPU modules, selected based on the board above.
config 440EP
bool
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 8d0b1a1..73c1df5 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_44x) := misc_44x.o idle.o
+obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY)+= ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c
b/arch/powerpc/platforms/44x/ppc44x_simple.c
new file mode 100644
index 000..067cddb
--- /dev/null
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -0,0 +1,81 @@
+/*
+ * Generic PowerPC 44x platform support
+ *
+ * Copyright 2008 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; version 2 of the License.
+ *
+ * This implements simple platform support for PowerPC 44x chips. This is
+ * mostly used for eval boards or other simple and "generic" 44x boards. If
+ * your board has custom functions or hardware, then you will likely want to
+ * implement your own board.c file to accommodate it.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static __initdata struct of_device_id ppc44x_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init ppc44x_device_probe(void)
+{
+ of_platform_bus_probe(NULL, ppc44x_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(ppc44x_simple, ppc44x_device_probe);
+
+static char *board[] __initdata = {
+ "amcc,bamboo",
+ "amcc,cayonlands",
+ "ibm,ebony",
+ "amcc,katmai",
+ "amcc,rainier",
+ "amcc,sequoia",
+ "amcc,taishan",
+ NULL
+};
+
+static int __init ppc44x_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ int i = 0;
+
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(root, board[i]))
+ break;
+ i++;
+ }
+
+ if (board[i] != NULL) {
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+ return 1;
+ }
+
+ return 0;
+}
+
+define_machine(ppc44x_simple) {
+ .name = "PowerPC 44x Platform",
+ .probe = ppc44x_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/9] Rework PowerPC 44x board support
The following patch series reworks the board support code for PowerPC 44x platforms. It eliminates a number of redundant .c files and add a ppc44x_simple.c file that has an explicit list of boards that are supported by it. This is the same mechanism that Grant Likely has used for MPC 5200 boards. It also adds some more explicit support for Glacier and Yosemite boards, as those boards were using a board level compatible property in their DTS files that was a bit confusing. Review would be appreciated. Tested on Sequoia, and I plan on testing on as many boards as I can before committing to my tree. josh Josh Boyer (9): powerpc/44x: Add PowerPC 44x simple platform support powerpc/44x: Migrate Bamboo support to ppc44x_simple powerpc/44x: Migrate Canyonlands support to ppc44x_simple powerpc/44x: Migrate Katmai support to ppc44x_simple powerpc/44x: Migrate Rainier support to ppc44x_simple powerpc/44x: Migrate Sequoia support to ppc44x_simple powerpc/44x: Migrate Taishan support to ppc44x_simple powerpc/44x: Add explicit support for AMCC Glacier powerpc/44x: Add explicit Yosemite support arch/powerpc/boot/dts/glacier.dts |2 +- arch/powerpc/boot/dts/yosemite.dts |2 +- arch/powerpc/platforms/44x/Kconfig | 25 arch/powerpc/platforms/44x/Makefile|8 +-- arch/powerpc/platforms/44x/bamboo.c| 62 - arch/powerpc/platforms/44x/canyonlands.c | 63 - arch/powerpc/platforms/44x/katmai.c| 62 - arch/powerpc/platforms/44x/ppc44x_simple.c | 83 arch/powerpc/platforms/44x/rainier.c | 62 - arch/powerpc/platforms/44x/sequoia.c | 63 - arch/powerpc/platforms/44x/taishan.c | 72 11 files changed, 111 insertions(+), 393 deletions(-) delete mode 100644 arch/powerpc/platforms/44x/bamboo.c delete mode 100644 arch/powerpc/platforms/44x/canyonlands.c delete mode 100644 arch/powerpc/platforms/44x/katmai.c create mode 100644 arch/powerpc/platforms/44x/ppc44x_simple.c delete mode 100644 arch/powerpc/platforms/44x/rainier.c delete mode 100644 arch/powerpc/platforms/44x/sequoia.c delete mode 100644 arch/powerpc/platforms/44x/taishan.c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
On Tue, Aug 19, 2008 at 11:26:28AM +0200, Laurent Pinchart wrote:
[...]
> > I didn't say "SOC-specific". I said "SOC-model specific", which
> > means that the driver would be not portable even across QE chips
> > (i.e. MPC8323 vs. MPC8360, you can assume that the "CLK12" function
> > is having same PAR/ODR/DAT/DIR bits).
>
> If I'm not mistaken, the PAR bit is used to select between GPIO and
> dedicated mode by definition. It should be safe to assume that setting
> a GPIO in dedicated mode requires the PAR bit to be set. But as I
> stated above, we can ignore that for now until a hardware use case
> comes up.
One more thing: you're assuming that there is one par bit, but
there are two par bits for QE chips. Which one would you set in
set_dedicated()? ;-)
> > > > > If, for some
> > > > > reason (driver not loaded, ...), no GPIO user shows up for that
> > > > > pin, it will stay configured in dedicated mode.
> > > >
> > > > Yes.
> > > >
> > > > > It might be better to set the PAR bit unconditionally in
> > > >
> > > > Why it might be better?
> > >
> > > Because, as explained a few lines down, the board initialization code
> > > will be able to configure a pin in a known state (PAR not set) at boot
> > > time until a driver requests the pin to be switched to dedicated mode.
> >
> > You can do this as I described above. But prior to this, yes, you have
> > to configure the pins and let Linux save these values. There is no other
> > way to pass this information, unfortunately.
>
> Ok.
>
> I started implementing CPM2 dedicated mode support to be used in the
> CPM UART driver for RTS/CTS flow control, and soon realized there was
> a show stopper. The CPM UART driver is mostly CPM1/CPM2 agnostic.
> I can't use a function such as cpm2_gpio32_set_dedicated, as that
> wouldn't work on a CPM1 (at least not on all its ports). I could call
> the right function depending on which port the GPIO is on, but that's
> really hackish and would defeat the purpose of using GPIOs.
You can easily refactor cpm gpio code so that you'll have
common cpm structure with platform-specific "GPIO API extension"
callbacks. Something like this:
/*
* generic structure, does not know anything about cpm1/2/qe, or
* ports width.
*/
struct cpm_gpio_chip {
struct of_mm_gpio_chip mm_gc;
spinlock_t lock;
void (*set_dedicated)(unsigned int gpio);
};
struct cpm1_gpio16_chip {
struct cpm_gpio_chip cpgc;
/* shadowed data register to clear/set bits safely */
u16 cpdata;
};
void cpm_gpio_set_dedicated(unsigned int gpio)
{
struct gpio_chip *gc = gpio_to_chip(gpio);
struct of_gpio_chip *ofgc = to_of_gpio_chip(gc);
struct cpm_gpio_chip *cpgc = to_cpm_gpio_chip(ofgc);
if (cpgc->set_dedicated)
cpgc->set_dedicated(gc->base - gpio);
}
> What we
> really need there is a set_dedicated/set_option/set_whatever function
> in the GPIO API :-/
Won't happen. ;-)
--
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] powerpc/spufs: Remove invalid semicolon after if statement
Hi Ilpo, > - if (new_state == SPU_UTIL_USER); > + if (new_state == SPU_UTIL_USER) Thanks, good catch. applied to spufs.git. Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
* Eran Liberty ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
>> Can you also give us
>>
>> objdump -S --start-address=0xC00BB724 vmlinux | head 20
>>
>> ?
>>
>> Then we could compare the result with the OOPS instruction dump :
>>
>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
>> 73c1 7f83e378 7fa4eb78 4082002f <> 2f83 409e0030 801b32a0
>>
>> Mathieu
>>
>>
>
> to give you more context I have run:
> > powerpc-linux-gnu-objdump -S --start-address=0xC00BB700 vmlinux | head -n
> 60
>
> the discrepancy starts at address:
> c00bb720: 40 82 00 30 <=> 40 82 00 2f
> c00bb724: 4b ff fe 61 <=> 00 00 00 00
>
Ah !
I think I see what could be wrong :
First we have :
static unsigned int ftrace_nop = 0x6000;
We probably replace the original function call by this nop.
Then we do :
notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
{
static unsigned int op;
/*
* It would be nice to just use create_function_call, but that will
* update the code itself. Here we need to just return the
* instruction that is going to be modified, without modifying the
* code.
*/
addr = GET_ADDR(addr);
/* Set to "bl addr" */
op = 0x4801 | (ftrace_calc_offset(ip, addr) & 0x03fc);
/*
* No locking needed, this must be called via kstop_machine
* which in essence is like running on a uniprocessor machine.
*/
return (unsigned char *)&op;
}
And I guess we must be doing a 0x4801 | 0x0; or something ?
Also, we have to consider that POWERPC 64 functions are :
/* PowerPC64's functions are data that points to the functions */
And this does not seem to hold for ppc32. Therefore, it is strange to me
that the same code is used for the update.. are we updating the correct
site ?
Mathieu
> vmlinux: file format elf32-powerpc
>
> Disassembly of section .text:
>
> c00bb700 :
> * d_lookup() is protected against the concurrent renames in some unrelated
> * directory using the seqlockt_t rename_lock.
> */
>
> struct dentry * d_lookup(struct dentry * parent, struct qstr * name)
> {
> c00bb700: 7c 3f 0b 78 mr r31,r1
> c00bb704: 90 01 00 24 stw r0,36(r1)
> c00bb708: 7c 7c 1b 78 mr r28,r3
> c00bb70c: 7c 9d 23 78 mr r29,r4
> c00bb710: 83 db 32 a0 lwz r30,12960(r27)
> {
>unsigned ret;
>
> repeat:
>ret = sl->sequence;
>smp_rmb();
> c00bb714: 73 c0 00 01 andi. r0,r30,1
>struct dentry * dentry = NULL;
>unsigned long seq;
>
>do {
>seq = read_seqbegin(&rename_lock);
>dentry = __d_lookup(parent, name);
> c00bb718: 7f 83 e3 78 mr r3,r28
> c00bb71c: 7f a4 eb 78 mr r4,r29
>if (unlikely(ret & 1)) {
> c00bb720: 40 82 00 30 bne-c00bb750
> c00bb724: 4b ff fe 61 bl c00bb584 <__d_lookup>
>if (dentry)
> c00bb728: 2f 83 00 00 cmpwi cr7,r3,0
> c00bb72c: 40 9e 00 30 bne-cr7,c00bb75c
> *
> * If sequence value changed then writer changed data while in section.
> */
> static __always_inline int read_seqretry(const seqlock_t *sl, unsigned
> start)
> {
>smp_rmb();
> c00bb730: 80 1b 32 a0 lwz r0,12960(r27)
>break;
>} while (read_seqretry(&rename_lock, seq));
> c00bb734: 7f 80 f0 00 cmpwcr7,r0,r30
> c00bb738: 41 9e 00 24 beq-cr7,c00bb75c
> /* Start of read calculation -- fetch last complete writer token */
> static __always_inline unsigned read_seqbegin(const seqlock_t *sl)
> {
>unsigned ret;
>
> repeat:
> c00bb73c: 7c 1e 03 78 mr r30,r0
>ret = sl->sequence;
>smp_rmb();
> c00bb740: 73 c0 00 01 andi. r0,r30,1
>struct dentry * dentry = NULL;
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Mathieu Desnoyers wrote:
Can you also give us
objdump -S --start-address=0xC00BB724 vmlinux | head 20
?
Then we could compare the result with the OOPS instruction dump :
7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
73c1 7f83e378 7fa4eb78 4082002f <> 2f83 409e0030 801b32a0
Mathieu
to give you more context I have run:
> powerpc-linux-gnu-objdump -S --start-address=0xC00BB700 vmlinux |
head -n 60
the discrepancy starts at address:
c00bb720: 40 82 00 30 <=> 40 82 00 2f
c00bb724: 4b ff fe 61 <=> 00 00 00 00
vmlinux: file format elf32-powerpc
Disassembly of section .text:
c00bb700 :
* d_lookup() is protected against the concurrent renames in some unrelated
* directory using the seqlockt_t rename_lock.
*/
struct dentry * d_lookup(struct dentry * parent, struct qstr * name)
{
c00bb700: 7c 3f 0b 78 mr r31,r1
c00bb704: 90 01 00 24 stw r0,36(r1)
c00bb708: 7c 7c 1b 78 mr r28,r3
c00bb70c: 7c 9d 23 78 mr r29,r4
c00bb710: 83 db 32 a0 lwz r30,12960(r27)
{
unsigned ret;
repeat:
ret = sl->sequence;
smp_rmb();
c00bb714: 73 c0 00 01 andi. r0,r30,1
struct dentry * dentry = NULL;
unsigned long seq;
do {
seq = read_seqbegin(&rename_lock);
dentry = __d_lookup(parent, name);
c00bb718: 7f 83 e3 78 mr r3,r28
c00bb71c: 7f a4 eb 78 mr r4,r29
if (unlikely(ret & 1)) {
c00bb720: 40 82 00 30 bne-c00bb750
c00bb724: 4b ff fe 61 bl c00bb584 <__d_lookup>
if (dentry)
c00bb728: 2f 83 00 00 cmpwi cr7,r3,0
c00bb72c: 40 9e 00 30 bne-cr7,c00bb75c
*
* If sequence value changed then writer changed data while in section.
*/
static __always_inline int read_seqretry(const seqlock_t *sl, unsigned
start)
{
smp_rmb();
c00bb730: 80 1b 32 a0 lwz r0,12960(r27)
break;
} while (read_seqretry(&rename_lock, seq));
c00bb734: 7f 80 f0 00 cmpwcr7,r0,r30
c00bb738: 41 9e 00 24 beq-cr7,c00bb75c
/* Start of read calculation -- fetch last complete writer token */
static __always_inline unsigned read_seqbegin(const seqlock_t *sl)
{
unsigned ret;
repeat:
c00bb73c: 7c 1e 03 78 mr r30,r0
ret = sl->sequence;
smp_rmb();
c00bb740: 73 c0 00 01 andi. r0,r30,1
struct dentry * dentry = NULL;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Clock / Timebase / Bus Frequencies Help
Hi Richard, Thanks for your response, i have fixed the problem. The problem was while U-boot is doing boardsetup it is filling incorrect frequencies which causes the problem. Regards Surendra > Hi, > > Is it really hanging? > Or is it just sending console output somewhere else? > Try pinging the board after you think its hung. Can you ssh in and dmesg > to find out what went wrong? > I've had two problems similar to this recently. The first was that the > serial clock frequency was wrong in the dts file. > The second was schoolboy error when the console was handed over to ttyS1 > when I was plugged in to ttyS0. > If that all fails - put a scope on your serial port and see what its > really doing. > Good luck, > > > > > Richard. > > [EMAIL PROTECTED] wrote: >> Hi, >> >> I have a similar problem with custom MPC8360 board. >> I am able to boot Linux with the mpc836x_dts.dtb provided by freescale. >> but when use dtb customised for my board i am unable to boot Linux. >> It is hanging after the console handover to real console from boot >> console. >> >> I am filling all the frequencies properly, can someone help me to fix >> this >> Where to set the baud rate in dts file. >> >> Here is the log: >> >> >> => tftp $loadaddr /nfk684/vpm_test/uImage >> Using FSL UEC0 device >> TFTP from server 192.168.0.2; our IP address is 192.168.0.100 >> Filename '/nfk684/vpm_test/uImage'. >> Load address: 0x20 >> Loading: >> # >> ## >> done >> Bytes transferred = 1095689 (10b809 hex) >> => tftp $fdtaddr /nfk684/vpm_test/mpc8360_vpm.dtb >> Using FSL UEC0 device >> TFTP from server 192.168.0.2; our IP address is 192.168.0.100 >> Filename '/nfk684/vpm_test/mpc8360_vpm.dtb'. >> Load address: 0x40 >> Loading: # >> done >> Bytes transferred = 12288 (3000 hex) >> => bootm $loadaddr - $fdtaddr >> ## Booting image at 0020 ... >>Image Name: Linux-2.6.22 >>Image Type: PowerPC Linux Kernel Image (gzip compressed) >>Data Size:1095625 Bytes = 1 MB >>Load Address: >>Entry Point: >>Verifying Checksum ... OK >>Uncompressing Kernel Image ... OK >>Booting using the fdt at 0x40 >> Probing machine type >> Using MPC8360 VPM machine description >> Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 >> 4.0.0)) >> #17 Fri Aug 15 16:13:41 CDT 2008 >> setup_arch: bootmem >> mpc8360_vpm_setup_arch() >> Bad clock source for time stamp 1 >> Bad clock source for time stamp 2 >> arch: exit >> Zone PFN ranges: >> DMA 0 ->65536 >> Normal 65536 ->65536 >> early_node_map[1] active PFN ranges >> 0:0 ->65536 >> Built 1 zonelists. Total pages: 65024 >> Kernel command line: root=/dev/ram rw console=ttyS1,115200 >> IPIC (128 IRQ sources) at fdefc700 >> QEIC (64 IRQ sources) at fdefb080 >> PID hash table entries: 1024 (order: 10, 4096 bytes) >> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) >> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) >> Memory: 257280k/262144k available (2152k kernel code, 4624k reserved, >> 96k >> data, >> 80k bss, 128k init) >> Mount-cache hash table entries: 512 >> NET: Registered protocol family 16 >> >> Generic PHY: Registered new driver >> SCSI subsystem initialized >> NET: Registered protocol family 2 >> IP route cache hash table entries: 2048 (order: 1, 8192 bytes) >> TCP established hash table entries: 8192 (order: 4, 65536 bytes) >> TCP bind hash table entries: 8192 (order: 3, 32768 bytes) >> TCP: Hash tables configured (established 8192 bind 8192) >> TCP reno registered >> JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. >> io scheduler noop registered >> io scheduler anticipatory registered (default) >> io scheduler deadline registered >> io scheduler cfq registered >> Generic RTC Driver v1.07 >> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing >> disabled >> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A >> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A >> console handover: boot [udbg0] -> real [ttyS1] >> >> Regards >> Surendra >> >> >> >>> On Mon, Aug 18, 2008 at 07:52:12AM -0400, [EMAIL PROTECTED] wrote: >>> We've got an 8347 based board very similar to the A&M asp8347. Core clock is 400MHz. Bus clock is 2Hz. According to the data sheet for the 8347, the decrementer clock runs at a quarter of the rate of the bus clock. I have two questions: In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my system clock runs approximately 4 times too fast. Can anyone point me in the direction of an explanation for the div by 16 rather than 4? >>> It's a bug, which I pointed out here: >>> http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html >>> >>> If I change
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
* Eran Liberty ([EMAIL PROTECTED]) wrote:
> Steven Rostedt wrote:
>> On Mon, 18 Aug 2008, Eran Liberty wrote:
>>
>>
>>> Steven Rostedt wrote:
>>>
Eran Liberty wrote:
> After compiling a kernel with ftrace I started to experience all sorts
> of
> crashes.
>
Just to make sure...
ftrace enables markers too, and RCU has tracing with the markers. This
may
not be the problem, but I just want to eliminate as many variables as
possible.
Could you disable ftrace, but keep the markers on too. Also, could you
enable ftrace again and turn on the FTRACE_STARTUP_TEST.
>>> for the fun of it I took out all my propriety modules; so now its a non
>>> tainted kernel.
>>>
>>> Here is the matrix:
>>>
>>> !FTRACE x !MARKERS => stable
>>> !FTRACE x MARKERS => stable
>>> FTRACE x !MARKERS => n/a (FTRACE forces MARKERS)
>>> FTRACE x MARKERS => unstable
>>> FTRACE x FTRACE_STARTUP_TEST x MARKERS => unstable + tests passed
>>>
>>
>> Thanks
>>
>>
>>> Testing tracer sched_switch: PASSED
>>> Testing tracer ftrace: PASSED
>>> Testing dynamic ftrace: PASSED
>>>
>>> Oops: Exception in kernel mode, sig: 11 [#1]
>>> Exsw1600
>>> Modules linked in:
>>> NIP: c00bbb20 LR: c00bbb20 CTR:
>>>
>>
>> Could you load this into gdb for me and show me the output of:
>>
>> gdb> li *0xc00bbb20
>>
>> (Assuming you compiled with debuginfo on)
>>
>> and...
>>
>> gdb> disass 0xc00bbb20
>>
>>
>>> REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2)
>>> MSR: 00029000 CR: 24082282 XER: 2000
>>> TASK = ddcce060[1707] 'find' THREAD: dd5b
>>> GPR00: dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b
>>> 100234ec
>>> GPR08: c080 00019330 dd5b1d20 24000288 100ad874 100936f8
>>> 1008a1d0
>>> GPR16: 10083f80 dd5b1e2c dd5b1d68 fff4 c038 dd5b1d60 dd5b1d58
>>> dd802084
>>> GPR24: dc3d7700 dd802018 dd5b1d68 c038 dd801180 dd5b1d68
>>> dd5b1d00
>>> NIP [c00bbb20] d_lookup+0x40/0x90
>>> LR [c00bbb20] d_lookup+0x40/0x90
>>> Call Trace:
>>> [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable)
>>> [dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220
>>> [dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54
>>> [dd5b1dc0] [c00b1288] path_walk+0x58/0xe0
>>> [dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c
>>> [dd5b1e20] [c00b20f4] user_path_at+0x64/0xac
>>> [dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74
>>> [dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48
>>> [dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c
>>> [dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c
>>> Instruction dump:
>>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
>>> 73c1 7f83e378 7fa4eb78 4082002f <> 2f83 409e0030 801b32a0
>>>
>>
>> Ouch! we have a instruction. I'm almost done with the new mcount
>> record for PPC (I have it done for ppc64, I'm just porting it to 32). I'm
>> thinking this new code may solve your issues too. I hate the daemon.
>>
>> -- Steve
>>
>>
>>
>
> I have attached ddd. Up on crashing it points on this line
>
> struct dentry * d_lookup(struct dentry * parent, struct qstr * name)
> {
>struct dentry * dentry = NULL;
>unsigned long seq;
> do {
>seq = read_seqbegin(&rename_lock);
>dentry = __d_lookup(parent, name); < ddd marker
>if (dentry)
>break;
>} while (read_seqretry(&rename_lock, seq));
>return dentry;
> }
>
> (gdb) bt
> #0 d_lookup (parent=0xdd801180, name=0xd99b3d68) at fs/dcache.c:1361
> #1 0xc00ae7c8 in real_lookup (nd=, name= optimized out>, parent=0xdd801180) at fs/namei.c:507
> #2 do_lookup (nd=0xd99b3e28, name=0xd99b3d68, path=0xd99b3d58) at
> fs/namei.c:825
> #3 0xc00b0684 in __link_path_walk (name=0xddc23009 "", nd=0xd99b3e28) at
> fs/namei.c:982
> #4 0xc00b0e8c in link_path_walk (nd=, name= optimized out>) at fs/namei.c:570
> #5 path_walk (name=0xddc23000 "/proc/mtd", nd=0xd99b3e28) at
> fs/namei.c:1041
> #6 0xc00b0ffc in do_path_lookup (dfd=,
> name=0xddc23000 "/proc/mtd", flags=, nd=0xd99b3e28) at
> fs/namei.c:1091
> #7 0xc00b1cf8 in user_path_at (dfd=-100, name=,
> flags=0, path=0xd99b3e98) at fs/namei.c:1334
> #8 0xc00a8c98 in vfs_lstat_fd (dfd=-578809472, name=0xd99b3d68 "",
> stat=0xd99b3ed8) at fs/stat.c:83
> #9 0xc00a8d6c in vfs_lstat (name=0xd99b3d68 "", stat=0xd99b3d58) at
> fs/stat.c:93
> #10 0xc00a8db4 in sys_lstat64 (filename=0xdd801180 "", statbuf=0xbfe285d8)
> at fs/stat.c:381
> #11 0xc0010554 in syscall_dotrace_cont ()
>
> both cp & lr points to 0xC00BB724
> (gdb) info registers
> r0 0x00
> r1 0xd99b3d003650829568
> r2 0xddccf2e03721196256
> r3 0xdd8011803716157824
> r4 0xd99b3d683650829672
> r5 0xd99b3d583650829656
> r6 0xdd822a5b3716295259
> r7 0x100234ec268580076
> r8 0xc0
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
* Eran Liberty ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers wrote: >> Can you check if, at some point during the system execution (starting >> from boot), 0xdd5b1d58 is an address where a module is loaded ? (the >> module can be later unloaded, what I wonder is if this address would >> appear to have had a loaded+unloaded module). >> >> Actually, could you try to compile your kernel without "MODULE_UNLOAD" ? >> >> Mathieu >> > No modules... > > ~ # uname -a > Linux 2.6.27-rc2 #6 Tue Aug 19 12:33:34 IDT 2008 ppc unknown > ~ # gunzip /proc/config.gz -c | grep UNLOAD > # CONFIG_MODULE_UNLOAD is not set > ~ # gunzip /proc/config.gz -c | grep FTRACE > CONFIG_HAVE_FTRACE=y > CONFIG_HAVE_DYNAMIC_FTRACE=y > CONFIG_FTRACE=y > CONFIG_DYNAMIC_FTRACE=y > CONFIG_FTRACE_SELFTEST=y > CONFIG_FTRACE_STARTUP_TEST=y > ~ # gunzip /proc/config.gz -c | grep MARKERS > CONFIG_MARKERS=y > ~ # lsmod > Module Size Used by > ~ # while [ 1 ] ; do find / > /dev/null ; echo . ; done > . > Oops: Exception in kernel mode, sig: 11 [#1] > Exsw1600 > Modules linked in: > NIP: c00bb724 LR: c00bb724 CTR: > REGS: d8b59c50 TRAP: 0700 Not tainted (2.6.27-rc2) > MSR: 00029000 CR: 24082282 XER: 2000 > TASK = dbc68de0[1712] 'find' THREAD: d8b58000 > GPR00: d8b59d00 dbc68de0 dd801180 d8b59d68 d8b59d58 dd8019db > 100234ec > GPR08: c080 00019330 d8b59d20 24000288 100ad874 100936f8 > 1008a1d0 > GPR16: 10083f80 d8b59e2c d8b59d68 fff4 c038 d8b59d60 d8b59d58 > dd802084 Register GPR30 is always zero... (also true for the other oops) > GPR24: ddc69500 dd802018 d8b59d68 c038 dd801180 d8b59d68 > d8b59d00 > NIP [c00bb724] d_lookup+0x40/0x90 > LR [c00bb724] d_lookup+0x40/0x90 > Call Trace: > [d8b59d00] [d8b59d58] 0xd8b59d58 (unreliable) > [d8b59d20] [c00ae7c8] do_lookup+0xe8/0x220 > [d8b59d50] [c00b0684] __link_path_walk+0x5a4/0xd54 > [d8b59dc0] [c00b0e8c] path_walk+0x58/0xe0 > [d8b59df0] [c00b0ffc] do_path_lookup+0x78/0x13c > [d8b59e20] [c00b1cf8] user_path_at+0x64/0xac > [d8b59e90] [c00a8c98] vfs_lstat_fd+0x34/0x74 > [d8b59ec0] [c00a8d6c] vfs_lstat+0x30/0x48 > [d8b59ed0] [c00a8db4] sys_lstat64+0x30/0x5c > [d8b59f40] [c0010554] ret_from_syscall+0x0/0x3c > Instruction dump: > 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0 Just like this instruction... maybe related ? Mathieu > 73c1 7f83e378 7fa4eb78 4082002f <> 2f83 409e0030 801b32a0 > ---[ end trace 7766edd310cd3442 ]--- > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc, scc: duplicate SCC_UHC_USBCEN
Roel,
> untested, is it correct?
Your patch is correct.
Thanks for your pointing it out and sending the patch. I tested your
patch and it works good.
Fortunately, this bug is not fatal because it seems that the SCC-UHC
sets SCC_UHC_USBEN and SCC_UHC_USBCEN at once.
Your patch does not contain 'Signed-off-by' line. Could you re-post it
with your sign?
> ---
> arch/powerpc/platforms/cell/celleb_scc.h:224:
> #define SCC_UHC_USBEN 0x0001
> #define SCC_UHC_USBCEN 0x0002
>
> ---
> diff --git a/arch/powerpc/platforms/cell/celleb_scc_uhc.c
> b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
> index d63b720..b086f33 100644
> --- a/arch/powerpc/platforms/cell/celleb_scc_uhc.c
> +++ b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
> @@ -31,7 +31,7 @@
>
> static inline int uhc_clkctrl_ready(u32 val)
> {
> - const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBCEN;
> + const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBEN;
> return((val & mask) == mask);
> }
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
Best regards,
Kou Ishizaki
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
cpm2: Fix race condition in CPM2 GPIO library.
The CPM2 GPIO library code uses the non thread-safe clrbits32/setbits32
macros. This patch protects them with a spinlock.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/cpm_common.c | 37 ++---
1 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 53da8a0..00d3d17 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -254,15 +254,11 @@ static int cpm2_gpio32_get(struct gpio_chip *gc, unsigned
int gpio)
return !!(in_be32(&iop->dat) & pin_mask);
}
-static void cpm2_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+static void __cpm2_gpio32_set(struct of_mm_gpio_chip *mm_gc, u32 pin_mask,
+ int value)
{
- struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
struct cpm2_ioports __iomem *iop = mm_gc->regs;
- unsigned long flags;
- u32 pin_mask = 1 << (31 - gpio);
-
- spin_lock_irqsave(&cpm2_gc->lock, flags);
if (value)
cpm2_gc->cpdata |= pin_mask;
@@ -270,6 +266,18 @@ static void cpm2_gpio32_set(struct gpio_chip *gc, unsigned
int gpio, int value)
cpm2_gc->cpdata &= ~pin_mask;
out_be32(&iop->dat, cpm2_gc->cpdata);
+}
+
+static void cpm2_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
+
+ spin_lock_irqsave(&cpm2_gc->lock, flags);
+
+ __cpm2_gpio32_set(mm_gc, pin_mask, value);
spin_unlock_irqrestore(&cpm2_gc->lock, flags);
}
@@ -277,14 +285,17 @@ static void cpm2_gpio32_set(struct gpio_chip *gc,
unsigned int gpio, int value)
static int cpm2_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int
val)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
struct cpm2_ioports __iomem *iop = mm_gc->regs;
- u32 pin_mask;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
- pin_mask = 1 << (31 - gpio);
+ spin_lock_irqsave(&cpm2_gc->lock, flags);
setbits32(&iop->dir, pin_mask);
+ __cpm2_gpio32_set(mm_gc, pin_mask, val);
- cpm2_gpio32_set(gc, gpio, val);
+ spin_unlock_irqrestore(&cpm2_gc->lock, flags);
return 0;
}
@@ -292,13 +303,17 @@ static int cpm2_gpio32_dir_out(struct gpio_chip *gc,
unsigned int gpio, int val)
static int cpm2_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
struct cpm2_ioports __iomem *iop = mm_gc->regs;
- u32 pin_mask;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
- pin_mask = 1 << (31 - gpio);
+ spin_lock_irqsave(&cpm2_gc->lock, flags);
clrbits32(&iop->dir, pin_mask);
+ spin_unlock_irqrestore(&cpm2_gc->lock, flags);
+
return 0;
}
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Clock / Timebase / Bus Frequencies Help
Scott, Thanks for that - you're right - redboot has the wrong crystal frequency in the cdl for our board. Cheers, Richard. Scott Wood wrote: On Mon, Aug 18, 2008 at 07:52:12AM -0400, [EMAIL PROTECTED] wrote: We've got an 8347 based board very similar to the A&M asp8347. Core clock is 400MHz. Bus clock is 2Hz. According to the data sheet for the 8347, the decrementer clock runs at a quarter of the rate of the bus clock. I have two questions: In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my system clock runs approximately 4 times too fast. Can anyone point me in the direction of an explanation for the div by 16 rather than 4? It's a bug, which I pointed out here: http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is passed in, then the clock runs more accurately. However, its still not correct. This gives a decrementer frequency of Hz, but if I hard code the value to 6600Hz, the clock runs accurately. Can anyone shed any light on why the value passed in by the boot loader (redboot) seems to be inaccurate. Redboot probably has the wrong crystal frequency hardcoded. -Scott ___ 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: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Steven Rostedt wrote:
On Mon, 18 Aug 2008, Eran Liberty wrote:
Steven Rostedt wrote:
Eran Liberty wrote:
After compiling a kernel with ftrace I started to experience all sorts of
crashes.
Just to make sure...
ftrace enables markers too, and RCU has tracing with the markers. This may
not be the problem, but I just want to eliminate as many variables as
possible.
Could you disable ftrace, but keep the markers on too. Also, could you
enable ftrace again and turn on the FTRACE_STARTUP_TEST.
for the fun of it I took out all my propriety modules; so now its a non
tainted kernel.
Here is the matrix:
!FTRACE x !MARKERS => stable
!FTRACE x MARKERS => stable
FTRACE x !MARKERS => n/a (FTRACE forces MARKERS)
FTRACE x MARKERS => unstable
FTRACE x FTRACE_STARTUP_TEST x MARKERS => unstable + tests passed
Thanks
Testing tracer sched_switch: PASSED
Testing tracer ftrace: PASSED
Testing dynamic ftrace: PASSED
Oops: Exception in kernel mode, sig: 11 [#1]
Exsw1600
Modules linked in:
NIP: c00bbb20 LR: c00bbb20 CTR:
Could you load this into gdb for me and show me the output of:
gdb> li *0xc00bbb20
(Assuming you compiled with debuginfo on)
and...
gdb> disass 0xc00bbb20
REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2)
MSR: 00029000 CR: 24082282 XER: 2000
TASK = ddcce060[1707] 'find' THREAD: dd5b
GPR00: dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b 100234ec
GPR08: c080 00019330 dd5b1d20 24000288 100ad874 100936f8 1008a1d0
GPR16: 10083f80 dd5b1e2c dd5b1d68 fff4 c038 dd5b1d60 dd5b1d58 dd802084
GPR24: dc3d7700 dd802018 dd5b1d68 c038 dd801180 dd5b1d68 dd5b1d00
NIP [c00bbb20] d_lookup+0x40/0x90
LR [c00bbb20] d_lookup+0x40/0x90
Call Trace:
[dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable)
[dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220
[dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54
[dd5b1dc0] [c00b1288] path_walk+0x58/0xe0
[dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c
[dd5b1e20] [c00b20f4] user_path_at+0x64/0xac
[dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74
[dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48
[dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c
[dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c
Instruction dump:
7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
73c1 7f83e378 7fa4eb78 4082002f <> 2f83 409e0030 801b32a0
Ouch! we have a instruction. I'm almost done with the new mcount
record for PPC (I have it done for ppc64, I'm just porting it to 32). I'm
thinking this new code may solve your issues too. I hate the daemon.
-- Steve
I have attached ddd. Up on crashing it points on this line
struct dentry * d_lookup(struct dentry * parent, struct qstr * name)
{
struct dentry * dentry = NULL;
unsigned long seq;
do {
seq = read_seqbegin(&rename_lock);
dentry = __d_lookup(parent, name); < ddd marker
if (dentry)
break;
} while (read_seqretry(&rename_lock, seq));
return dentry;
}
(gdb) bt
#0 d_lookup (parent=0xdd801180, name=0xd99b3d68) at fs/dcache.c:1361
#1 0xc00ae7c8 in real_lookup (nd=, name=optimized out>, parent=0xdd801180) at fs/namei.c:507
#2 do_lookup (nd=0xd99b3e28, name=0xd99b3d68, path=0xd99b3d58) at
fs/namei.c:825
#3 0xc00b0684 in __link_path_walk (name=0xddc23009 "", nd=0xd99b3e28)
at fs/namei.c:982
#4 0xc00b0e8c in link_path_walk (nd=, name=optimized out>) at fs/namei.c:570
#5 path_walk (name=0xddc23000 "/proc/mtd", nd=0xd99b3e28) at
fs/namei.c:1041
#6 0xc00b0ffc in do_path_lookup (dfd=,
name=0xddc23000 "/proc/mtd", flags=, nd=0xd99b3e28)
at fs/namei.c:1091
#7 0xc00b1cf8 in user_path_at (dfd=-100, name=,
flags=0, path=0xd99b3e98) at fs/namei.c:1334
#8 0xc00a8c98 in vfs_lstat_fd (dfd=-578809472, name=0xd99b3d68 "",
stat=0xd99b3ed8) at fs/stat.c:83
#9 0xc00a8d6c in vfs_lstat (name=0xd99b3d68 "", stat=0xd99b3d58) at
fs/stat.c:93
#10 0xc00a8db4 in sys_lstat64 (filename=0xdd801180 "",
statbuf=0xbfe285d8) at fs/stat.c:381
#11 0xc0010554 in syscall_dotrace_cont ()
both cp & lr points to 0xC00BB724
(gdb) info registers
r0 0x00
r1 0xd99b3d003650829568
r2 0xddccf2e03721196256
r3 0xdd8011803716157824
r4 0xd99b3d683650829672
r5 0xd99b3d583650829656
r6 0xdd822a5b3716295259
r7 0x100234ec268580076
r8 0xc0803229614080
r9 0x19330103216
r100x65535
r110xd99b3d203650829600
r120x24000288603980424
r130x100ad874269146228
r140x100936f8269039352
r150x1008a1d0269001168
r160x10083f80268976000
r170xd99b3e2c3650829868
r180xd99b3d683650829672
r190xfff44294967284
r200xc03832248954
Re: [PATCH 1/4] kvmppc: read device tree hypervisor node infrastructure
On Tue, 2008-08-19 at 07:52 -0400, Josh Boyer wrote:
> On Tue, 2008-08-19 at 12:36 +0200, [EMAIL PROTECTED] wrote:
> > diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/powerpc/kernel/kvm.c
> > @@ -0,0 +1,30 @@
>
> > +#include
> > +#include
> > +#include
> > +
> > +void __init kvm_guest_init(void)
> > +{
> > + if (!kvm_para_available())
> > + return;
> > +}
>
> This looks really odd. You have a void function that checks the return
> value of another function and returns if not true or.. returns if true.
> Why bother with the if at all?
Nevermind. I see you add more code below this in patch 3. Still looks
odd by itself, but makes more sense when the whole series is applied.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/oprofile: avoid double free of profile buffer
On 11.08.08 09:25:43, Arnd Bergmann wrote: > From: Carl Love <[EMAIL PROTECTED]> > > If an error occurs on opcontrol start, the event and per cpu buffers > are released. If later opcontrol shutdown is called then the free > function will be called again to free buffers that no longer > exist. This results in a kernel oops. The following changes > prevent the call to delete buffers that don't exist. > > Signed-off-by: Carl Love <[EMAIL PROTECTED]> > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> Acked-by: Robert Richter <[EMAIL PROTECTED]> -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] kvmppc: read device tree hypervisor node infrastructure
On Tue, 2008-08-19 at 12:36 +0200, [EMAIL PROTECTED] wrote:
> diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/powerpc/kernel/kvm.c
> @@ -0,0 +1,30 @@
> +#include
> +#include
> +#include
> +
> +void __init kvm_guest_init(void)
> +{
> + if (!kvm_para_available())
> + return;
> +}
This looks really odd. You have a void function that checks the return
value of another function and returns if not true or.. returns if true.
Why bother with the if at all?
One could ask the same about the entire function, but it does look
cleaner to call kvm_guest_init that kvm_para_available directly from
other code.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote: > Dependent on the already existing CONFIG_KVM_GUEST config option this patch > changes wrteei to wrtee allowing the hypervisor to rewrite those to > nontrapping > instructions. Maybe we should split the kvm guest otpimizations in two parts > one for the overhead free optimizations and on for the rest that might add > some complexity for non virtualized execution (like this one). > > Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> How significant is the performance impact of this change for non-virtualized systems? If it's very low, maybe you should not bother with the #ifdef, and if it's noticable, you might be better off using dynamic patching for this. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part
On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote:
> +static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
> +{
> + register unsigned long hcall asm ("r0") = nr;
> + register unsigned long arg1 asm ("r3") = p1;
> + register long ret asm ("r11");
> +
> + asm volatile(".long %1"
> + : "=r"(ret)
> + : "i"(KVM_HYPERCALL_BIN), "r"(hcall), "r"(arg1)
> + : "r4", "r5", "r6", "r7", "r8",
> + "r9", "r10", "r12", "cc");
> + return ret;
> +}
What is the reasoning for making the calling convention different from
all the existing hcall interfaces here?
pseries uses r3 for the hcall number, lv1 and beat use r11, so using
r0 just for the sake of being different seems counterintuitive.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibmebus/of_platform: Move "name" sysfs attribute into generic OF devices
Paul Mackerras <[EMAIL PROTECTED]> wrote on 19.08.2008 06:14:00: > > Recent of_platform changes made of_bus_type_init() overwrite the bus type's > > .dev_attrs list, so move ibmebus' "name" attribute (which is needed by eHCA > > userspace support) into generic OF device code. Tested on POWER. > > Is this a bugfix that is needed for 2.6.27? Yes, definitely. The eHCA userspace driver relies on the name attribute to check for valid adapters (it checks that the name is "lhca"), so with the name attribute gone, eHCA userspace will cease to work. Regards, Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Clock / Timebase / Bus Frequencies Help
Hi, Is it really hanging? Or is it just sending console output somewhere else? Try pinging the board after you think its hung. Can you ssh in and dmesg to find out what went wrong? I've had two problems similar to this recently. The first was that the serial clock frequency was wrong in the dts file. The second was schoolboy error when the console was handed over to ttyS1 when I was plugged in to ttyS0. If that all fails - put a scope on your serial port and see what its really doing. Good luck, Richard. [EMAIL PROTECTED] wrote: Hi, I have a similar problem with custom MPC8360 board. I am able to boot Linux with the mpc836x_dts.dtb provided by freescale. but when use dtb customised for my board i am unable to boot Linux. It is hanging after the console handover to real console from boot console. I am filling all the frequencies properly, can someone help me to fix this Where to set the baud rate in dts file. Here is the log: => tftp $loadaddr /nfk684/vpm_test/uImage Using FSL UEC0 device TFTP from server 192.168.0.2; our IP address is 192.168.0.100 Filename '/nfk684/vpm_test/uImage'. Load address: 0x20 Loading: # ## done Bytes transferred = 1095689 (10b809 hex) => tftp $fdtaddr /nfk684/vpm_test/mpc8360_vpm.dtb Using FSL UEC0 device TFTP from server 192.168.0.2; our IP address is 192.168.0.100 Filename '/nfk684/vpm_test/mpc8360_vpm.dtb'. Load address: 0x40 Loading: # done Bytes transferred = 12288 (3000 hex) => bootm $loadaddr - $fdtaddr ## Booting image at 0020 ... Image Name: Linux-2.6.22 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1095625 Bytes = 1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0x40 Probing machine type Using MPC8360 VPM machine description Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #17 Fri Aug 15 16:13:41 CDT 2008 setup_arch: bootmem mpc8360_vpm_setup_arch() Bad clock source for time stamp 1 Bad clock source for time stamp 2 arch: exit Zone PFN ranges: DMA 0 ->65536 Normal 65536 ->65536 early_node_map[1] active PFN ranges 0:0 ->65536 Built 1 zonelists. Total pages: 65024 Kernel command line: root=/dev/ram rw console=ttyS1,115200 IPIC (128 IRQ sources) at fdefc700 QEIC (64 IRQ sources) at fdefb080 PID hash table entries: 1024 (order: 10, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 257280k/262144k available (2152k kernel code, 4624k reserved, 96k data, 80k bss, 128k init) Mount-cache hash table entries: 512 NET: Registered protocol family 16 Generic PHY: Registered new driver SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A console handover: boot [udbg0] -> real [ttyS1] Regards Surendra On Mon, Aug 18, 2008 at 07:52:12AM -0400, [EMAIL PROTECTED] wrote: We've got an 8347 based board very similar to the A&M asp8347. Core clock is 400MHz. Bus clock is 2Hz. According to the data sheet for the 8347, the decrementer clock runs at a quarter of the rate of the bus clock. I have two questions: In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my system clock runs approximately 4 times too fast. Can anyone point me in the direction of an explanation for the div by 16 rather than 4? It's a bug, which I pointed out here: http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is passed in, then the clock runs more accurately. However, its still not correct. This gives a decrementer frequency of Hz, but if I hard code the value to 6600Hz, the clock runs accurately. Can anyone shed any light on why the value passed in by the boot loader (redboot) seems to be inaccurate. Redboot probably has the wrong crystal frequency hardcoded. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxp
[PATCH 1/4] kvmppc: read device tree hypervisor node infrastructure
From: Christian Ehrhardt <[EMAIL PROTECTED]>
This patch adds the guest portion of the device tree based host->guest
communication. Using the device tree infrastructure this patch implements
kvm_para_available and kvm_arch_para_features (in this patch just the
infrastructure, no specific feature registered).
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
---
[diffstat]
arch/powerpc/kernel/Makefile |2 ++
arch/powerpc/kernel/kvm.c | 30 ++
arch/powerpc/kernel/setup_32.c |3 +++
arch/powerpc/platforms/44x/Kconfig |7 +++
include/asm-powerpc/kvm_para.h | 37 ++---
5 files changed, 76 insertions(+), 3 deletions(-)
[diff]
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -80,6 +80,8 @@
obj-$(CONFIG_8XX_MINIMAL_FPEMU) += softemu8xx.o
+obj-$(CONFIG_KVM_GUEST)+= kvm.o
+
ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
obj-y += iomap.o
endif
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/kernel/kvm.c
@@ -0,0 +1,30 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * 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, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * Authors:
+ * Hollis Blanchard <[EMAIL PROTECTED]>
+ * Christian Ehrhardt <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+
+void __init kvm_guest_init(void)
+{
+ if (!kvm_para_available())
+ return;
+}
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -319,5 +320,7 @@
ppc_md.setup_arch();
if ( ppc_md.progress ) ppc_md.progress("arch: exit", 0x3eab);
+ kvm_guest_init();
+
paging_init();
}
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -152,3 +152,10 @@
# 44x errata/workaround config symbols, selected by the CPU models above
config IBM440EP_ERR42
bool
+
+config KVM_GUEST
+ bool "KVM Guest support"
+ depends on EXPERIMENTAL
+ help
+ This option enables various optimizations for running under the KVM
+ hypervisor.
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -14,7 +14,9 @@
*
* Copyright IBM Corp. 2008
*
- * Authors: Hollis Blanchard <[EMAIL PROTECTED]>
+ * Authors:
+ * Hollis Blanchard <[EMAIL PROTECTED]>
+ * Christian Ehrhardt <[EMAIL PROTECTED]>
*/
#ifndef __POWERPC_KVM_PARA_H__
@@ -22,15 +24,50 @@
#ifdef __KERNEL__
+#include
+
+static struct kvmppc_para_features {
+ char *dtcell;
+ int feature;
+} para_features[] = {
+};
+
static inline int kvm_para_available(void)
{
- return 0;
+ struct device_node *dn;
+ int ret;
+
+ dn = of_find_node_by_path("/hypervisor");
+ ret = !!dn;
+
+ of_node_put(dn);
+
+ return ret;
}
static inline unsigned int kvm_arch_para_features(void)
{
- return 0;
+ struct device_node *dn;
+ const int *dtval;
+ unsigned int features = 0;
+ int i;
+
+ dn = of_find_node_by_path("/hypervisor");
+ if (!dn)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(para_features); i++) {
+ dtval = of_get_property(dn, para_features[i].dtcell, NULL);
+ if (dtval && *dtval == 1)
+ features |= (1 << para_features[i].feature);
+ }
+
+ of_node_put(dn);
+
+ return features;
}
+
+void kvm_guest_init(void);
#endif /* __KERNEL__ */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] kvmppc: magic page paravirtualization - guest part
From: Christian Ehrhardt <[EMAIL PROTECTED]>
This patch adds the guest handling for the magic page mechanism. A Hypervisor
can modify the device tree passed to the guest. Using that already existing
interface a guest can simply detect available hypervisor features and agree
on the supported ones using hypercalls.
In this example it is checked for the feature switch "feature,pv-magicpage"
in the hypervisor node and additional data which represents the size the
hypervisor requests in "data,pv-magicpage-size".
When the guest reads that data and wants to support it the memory is allocated
and passed to the hypervisor using the KVM_HCALL_RESERVE_MAGICPAGE hypercall.
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
---
[diffstat]
arch/powerpc/kernel/kvm.c | 51 +
include/asm-powerpc/fixmap.h | 10 +++-
include/asm-powerpc/kvm_para.h | 26
mm/page_alloc.c|1
4 files changed, 87 insertions(+), 1 deletion(-)
[diff]
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -22,9 +22,60 @@
#include
#include
#include
+#include
+#include
+
+/*
+ * this is guest memory granted to the hypervisor;
+ * the hypervisor can place data in this area and rewrite
+ * privileged instructions to read from this area without
+ * trapping.
+ * Only the Hypervisor needs to be aware of the structure layout
+ * which makes the guest more felxible - the guest only guarantees
+ * the size which is requested by the hypervisor and read from a
+ * device tree entry.
+ */
+static void *kvm_magicpage;
+
+static void __init kvmppc_register_magic_page(void)
+{
+ unsigned long gvaddr;
+ unsigned long gpaddr;
+ int size;
+ long err;
+
+ size = kvmppc_pv_read_data(KVM_PVDATA_MAGICPAGE_SIZE);
+ if (size < 0) {
+ printk(KERN_ERR "%s: couldn't read size for kvmppc style "
+ "paravirtualization support (got %d)\n",
+ __func__, size);
+ return;
+ }
+
+ /* FIXME Guest SMP needs that percpu which */
+ kvm_magicpage = alloc_bootmem(size);
+ if (!kvm_magicpage) {
+ printk(KERN_ERR "%s - failed to allocate %d bytes\n",
+__func__, size);
+ return;
+ }
+ gpaddr = (unsigned long)__pa(kvm_magicpage);
+ gvaddr = fix_to_virt(FIX_KVM_PV);
+
+ err = kvm_hypercall2(KVM_HCALL_RESERVE_MAGICPAGE, gvaddr, gpaddr);
+ if (err)
+ printk(KERN_ERR "%s: couldn't register pv mem\n", __func__);
+ else
+ printk(KERN_NOTICE "%s: registered %d bytes for pv mem support"
+ " (gvaddr 0x%08lx gpaddr 0x%08lx)\n",
+__func__, size, gvaddr, gpaddr);
+}
void __init kvm_guest_init(void)
{
if (!kvm_para_available())
return;
+
+ if (kvm_para_has_feature(KVM_FEATURE_PPCPV_MAGICPAGE))
+ kvmppc_register_magic_page();
}
diff --git a/include/asm-powerpc/fixmap.h b/include/asm-powerpc/fixmap.h
--- a/include/asm-powerpc/fixmap.h
+++ b/include/asm-powerpc/fixmap.h
@@ -36,7 +36,7 @@
*
* these 'compile-time allocated' memory buffers are
* fixed-size 4k pages. (or larger if used with an increment
- * highger than 1) use fixmap_set(idx,phys) to associate
+ * higher than 1) use fixmap_set(idx,phys) to associate
* physical memory with fixmap indices.
*
* TLB entries of such buffers will not be flushed across
@@ -44,6 +44,14 @@
*/
enum fixed_addresses {
FIX_HOLE,
+#ifdef CONFIG_KVM_GUEST
+ /*
+* reserved virtual address space for paravirtualization - needs to be
+* <=32k away from base address 0 to be able to reach it with
+* immediate addressing using base 0 instead of needing a register.
+*/
+ FIX_KVM_PV,
+#endif
#ifdef CONFIG_HIGHMEM
FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -28,10 +28,18 @@
#define KVM_HYPERCALL_BIN 0x03ff
+#define KVM_HCALL_RESERVE_MAGICPAGE0
+
+#define KVM_PVDATA_MAGICPAGE_SIZE "data,pv-magicpage-size"
+
+/* List of PV features supported, returned as a bitfield */
+#define KVM_FEATURE_PPCPV_MAGICPAGE0
+
static struct kvmppc_para_features {
char *dtcell;
int feature;
} para_features[] = {
+ { "feature,pv-magicpage", KVM_FEATURE_PPCPV_MAGICPAGE }
};
static inline int kvm_para_available(void)
@@ -67,6 +75,24 @@
of_node_put(dn);
return features;
+}
+
+/* reads the specified data field out of the hypervisor node */
+static inline int kvmppc_pv_read_data(char *dtcell)
+{
+ struct de
[PATCH 0/4][RFC] kvmppc: paravirtualization interface - guest part v2
From: Christian Ehrhardt <[EMAIL PROTECTED]> This patch series implements a paravirtualization interface using: - the device tree mechanism to pass hypervisor informations to the guest - hypercalls for guest->host calls - an example exploiter of that interface (magic page) Version 2 includes changes to the feedback of my last submission and is now tested against the implemented and working host part. The host part discussion can be found on [EMAIL PROTECTED] The used hypercall ABI was already discussed on the embedded-hypervisor mailing list and is available at http://kvm.qumranet.com/kvmwiki/PowerPC_Hypercall_ABI The device tree format used here (=base for the discussions on embedded-hypervisor) is the following. - A node "hypervisor" to show the general availability of some hypervisor data - flags for features like the example "feature,pv-magicpage" setting 1 = available, everything else = unavailable - Some features might need to pass more data and can use an entry in the device tree like the example of "data,pv-magicpage-size" I hope that eventually this guest patch series (that is modifying the boot process and adding e.g. new ppc fixmaps could go upstream (when discussed and agreed somewhen) via linuxppc-dev, while the kvm host part will go via kvm (Avi Kivity). [patches in series] [PATCH 1/4] kvmppc: read device tree hypervisor node infrastructure [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part [PATCH 3/4] kvmppc: magic page paravirtualization - guest part [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization --- [diffstat] arch/powerpc/kernel/kvm.c| 51 ++ b/arch/powerpc/kernel/Makefile |2 + b/arch/powerpc/kernel/kvm.c | 30 + b/arch/powerpc/kernel/setup_32.c |3 + b/arch/powerpc/platforms/44x/Kconfig |7 b/include/asm-powerpc/fixmap.h | 10 + b/include/asm-powerpc/hw_irq.h | 12 +++ b/include/asm-powerpc/kvm_para.h | 43 +++-- b/mm/page_alloc.c|1 include/asm-powerpc/kvm_para.h | 59 +++ 10 files changed, 214 insertions(+), 4 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
From: Christian Ehrhardt <[EMAIL PROTECTED]>
Dependent on the already existing CONFIG_KVM_GUEST config option this patch
changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping
instructions. Maybe we should split the kvm guest otpimizations in two parts
one for the overhead free optimizations and on for the rest that might add
some complexity for non virtualized execution (like this one).
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
---
[diffstat]
hw_irq.h | 12
1 file changed, 12 insertions(+)
[diff]
diff --git a/include/asm-powerpc/hw_irq.h b/include/asm-powerpc/hw_irq.h
--- a/include/asm-powerpc/hw_irq.h
+++ b/include/asm-powerpc/hw_irq.h
@@ -72,7 +72,11 @@
static inline void local_irq_disable(void)
{
#ifdef CONFIG_BOOKE
+#ifdef CONFIG_KVM_GUEST
+ __asm__ __volatile__("wrtee %0": : "r"(0) :"memory");
+#else
__asm__ __volatile__("wrteei 0": : :"memory");
+#endif
#else
unsigned long msr;
__asm__ __volatile__("": : :"memory");
@@ -84,7 +88,11 @@
static inline void local_irq_enable(void)
{
#ifdef CONFIG_BOOKE
+#ifdef CONFIG_KVM_GUEST
+ __asm__ __volatile__("wrtee %0": : "r"(MSR_EE) :"memory");
+#else
__asm__ __volatile__("wrteei 1": : :"memory");
+#endif
#else
unsigned long msr;
__asm__ __volatile__("": : :"memory");
@@ -99,7 +107,11 @@
msr = mfmsr();
*flags = msr;
#ifdef CONFIG_BOOKE
+#ifdef CONFIG_KVM_GUEST
+ __asm__ __volatile__("wrtee %0": : "r"(0) :"memory");
+#else
__asm__ __volatile__("wrteei 0": : :"memory");
+#endif
#else
SET_MSR_EE(msr & ~MSR_EE);
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] kvmppc: add hypercall infrastructure - guest part
From: Christian Ehrhardt <[EMAIL PROTECTED]>
This adds the guest portion of the hypercall infrastructure, basically an
illegal instruction with a defined layout.
See http://kvm.qumranet.com/kvmwiki/PowerPC_Hypercall_ABI for more detail
on the hypercall ABI for powerpc.
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
---
[diffstat]
kvm_para.h | 33 +
1 file changed, 33 insertions(+)
[diff]
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -25,6 +25,8 @@
#ifdef __KERNEL__
#include
+
+#define KVM_HYPERCALL_BIN 0x03ff
static struct kvmppc_para_features {
char *dtcell;
@@ -69,6 +71,37 @@
void kvm_guest_init(void);
+static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
+{
+ register unsigned long hcall asm ("r0") = nr;
+ register unsigned long arg1 asm ("r3") = p1;
+ register long ret asm ("r11");
+
+ asm volatile(".long %1"
+ : "=r"(ret)
+ : "i"(KVM_HYPERCALL_BIN), "r"(hcall), "r"(arg1)
+ : "r4", "r5", "r6", "r7", "r8",
+ "r9", "r10", "r12", "cc");
+ return ret;
+}
+
+static inline long kvm_hypercall2(unsigned int nr,
+ unsigned long p1, unsigned long p2)
+{
+ register unsigned long hcall asm ("r0") = nr;
+ register unsigned long arg1 asm ("r3") = p1;
+ register unsigned long arg2 asm ("r4") = p2;
+ register long ret asm ("r11");
+
+ asm volatile(".long %1"
+ : "=r"(ret)
+ : "i"(KVM_HYPERCALL_BIN), "r"(hcall),
+ "r"(arg1), "r"(arg2)
+ : "r5", "r6", "r7", "r8",
+ "r9", "r10", "r12", "cc");
+ return ret;
+}
+
#endif /* __KERNEL__ */
#endif /* __POWERPC_KVM_PARA_H__ */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
8347 PCI IDE with Promise 20275 problems
Hi,
We have a board closely based on the A&M asp8347 with the addition of a
promise technologies 20275 ATA controller.
Starting with the ASP dts file I have added the following:
pci0: [EMAIL PROTECTED] {
cell-index = <1>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x11 */
0x8800 0x0 0x0 0x1 &ipic 19 0x8
0x8800 0x0 0x0 0x2 &ipic 19 0x8
0x8800 0x0 0x0 0x3 &ipic 19 0x8
0x8800 0x0 0x0 0x4 &ipic 19 0x8>;
interrupt-parent = <&ipic>;
interrupts = <0x42 0x8>;
bus-range = <0 0>;
ranges = <0x0200 0x0 0xc000 0xc000 0x0 0x1000
0x4200 0x0 0xb000 0xb000 0x0 0x0010
0x0100 0x0 0x 0xb800 0x0 0x0010>;
clock-frequency = <>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0xff008500 0x100>;
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
I have based the numbers around what I found in our original 2.6.20 ppc
port which works fine.
The following is from the ppc tree platform specific header for our board:
--
#define _IRQ1 MPC83xx_IRQ_EXT3
#define _IRQ2 MPC83xx_IRQ_EXT4
#define PCI_IRQ_INFO() \
static char pci_irq_table[][4] =\
/* \
* PCI IDSEL/INTPIN->INTLINE \
* A B C D \
*/ \
{ \
{ _IRQ1, _IRQ1, _IRQ1, _IRQ1 }, /* IDSEL 11 = IDE disk
*/ \
{ 0, 0, 0, 0 }, /* IDSEL 12
*/ \
{ _IRQ2, _IRQ2, _IRQ2, _IRQ2 }, /* IDSEL 13 = USB controller
*/ \
}; \
\
const long min_idsel = 11, max_idsel = 13, irqs_per_slot = 4;
#define EXT_IRQ_SENSES()\
u8 senses[8] = {\
0,/* EXT 0 */ \
0,/* EXT 1 */ \
0,/* EXT 2 */ \
IRQ_SENSE_LEVEL,/* EXT 3 = PCI.11 */\
IRQ_SENSE_LEVEL,/* EXT 4 = PCI.13 */\
IRQ_SENSE_LEVEL,/* EXT 5 = JCB */ \
0,/* EXT 6 */ \
0,/* EXT 7 */ \
};
#endif
// Note: these need to match how RedBoot has set up the hardware.
// In particular, the PCILAWRn/PCILBAWRn registers (PCI address window)
#define MPC83xx_PCI1_LOWER_IO0x
#define MPC83xx_PCI1_UPPER_IO0x000F
#define MPC83xx_PCI1_IO_BASE0xB800
#define MPC83xx_PCI1_IO_SIZE0x0010
#define MPC83xx_PCI1_LOWER_MEM0xC000
#define MPC83xx_PCI1_UPPER_MEM0xCFFF
#define MPC83xx_PCI1_MEM_OFFSET0x
--
The driver we are using is pata_pdc2027x. Everything seems to work OK,
except that every time we read from the hardware, we get all f's.
Specifically, pdc_detect_pll_input_clock() fails, since the clock
frequency appears to be 0Hz.
On boot I get the following:
Found MPC83xx PCI host bridge at 0xff008500. Firmware bus
number: 0->0
PCI host bridge /[EMAIL PROTECTED] (primary) ranges:
MEM 0xc000..0xcfff -> 0xc000
MEM 0xb000..0xb00f -> 0xb000 Prefetch
IO 0xb800..0xb80f -> 0x
Top of RAM: 0x800, Total RAM: 0x800
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x -> 0x8000
Normal 0x8000 -> 0x8000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x -> 0x8000
On node 0 totalpages: 32768
free_area_init_node: node 0, pgdat c032f8cc, node_mem_map c040c000
DMA zone: 32512 pages, LIFO batch:7
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: root=/dev/nfs
nfsroot=192.168.111.41:/tftpboot/powerpc_q2_
and on trying to mount a CF card I get this:
Mapping pci region - start: c810, length: 16384
pata_pdc2027x :00:0b.0: PLL input clock 0 kHz
pata_pdc2027x: Invalid PLL input clock 0kHz, give up!
scsi0 : pata_pdc2027x
scsi1 : pata_pdc2027x
ata1: PATA max UDMA/133 mmio [EMAIL PROTECTED] cmd 0xc81017c0 irq 16
ata2: PATA max UDMA/133 mmio [EMAIL PROTECTED] cmd 0xc81015c0 irq 16
pata_pdc2027x: 40-conductor cable detected on port 0
pata_pdc2027x: 40-conductor cable detec
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Mathieu Desnoyers wrote: Can you check if, at some point during the system execution (starting from boot), 0xdd5b1d58 is an address where a module is loaded ? (the module can be later unloaded, what I wonder is if this address would appear to have had a loaded+unloaded module). Actually, could you try to compile your kernel without "MODULE_UNLOAD" ? Mathieu No modules... ~ # uname -a Linux 2.6.27-rc2 #6 Tue Aug 19 12:33:34 IDT 2008 ppc unknown ~ # gunzip /proc/config.gz -c | grep UNLOAD # CONFIG_MODULE_UNLOAD is not set ~ # gunzip /proc/config.gz -c | grep FTRACE CONFIG_HAVE_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_FTRACE=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FTRACE_SELFTEST=y CONFIG_FTRACE_STARTUP_TEST=y ~ # gunzip /proc/config.gz -c | grep MARKERS CONFIG_MARKERS=y ~ # lsmod Module Size Used by ~ # while [ 1 ] ; do find / > /dev/null ; echo . ; done . Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: NIP: c00bb724 LR: c00bb724 CTR: REGS: d8b59c50 TRAP: 0700 Not tainted (2.6.27-rc2) MSR: 00029000 CR: 24082282 XER: 2000 TASK = dbc68de0[1712] 'find' THREAD: d8b58000 GPR00: d8b59d00 dbc68de0 dd801180 d8b59d68 d8b59d58 dd8019db 100234ec GPR08: c080 00019330 d8b59d20 24000288 100ad874 100936f8 1008a1d0 GPR16: 10083f80 d8b59e2c d8b59d68 fff4 c038 d8b59d60 d8b59d58 dd802084 GPR24: ddc69500 dd802018 d8b59d68 c038 dd801180 d8b59d68 d8b59d00 NIP [c00bb724] d_lookup+0x40/0x90 LR [c00bb724] d_lookup+0x40/0x90 Call Trace: [d8b59d00] [d8b59d58] 0xd8b59d58 (unreliable) [d8b59d20] [c00ae7c8] do_lookup+0xe8/0x220 [d8b59d50] [c00b0684] __link_path_walk+0x5a4/0xd54 [d8b59dc0] [c00b0e8c] path_walk+0x58/0xe0 [d8b59df0] [c00b0ffc] do_path_lookup+0x78/0x13c [d8b59e20] [c00b1cf8] user_path_at+0x64/0xac [d8b59e90] [c00a8c98] vfs_lstat_fd+0x34/0x74 [d8b59ec0] [c00a8d6c] vfs_lstat+0x30/0x48 [d8b59ed0] [c00a8db4] sys_lstat64+0x30/0x5c [d8b59f40] [c0010554] ret_from_syscall+0x0/0x3c Instruction dump: 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0 73c1 7f83e378 7fa4eb78 4082002f <> 2f83 409e0030 801b32a0 ---[ end trace 7766edd310cd3442 ]--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
At Tue, 19 Aug 2008 08:15:05 +0200 (CEST),
Johannes Berg wrote:
>
> roel kluin wrote:
> > untested, is it correct?
>
> not a clue, do you know how long ago that was? :)
> does the driver check endianness anywhere?
AFAIK snd-aoa supports only bit-endian formats (at least in
sound/aoa/soundbus/i2sbus-pcm.c), so this addition makes little
sense.
Better to drop the duplicated words there.
thanks,
Takashi
> > duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
> >
> > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> > ---
> > diff --git a/sound/aoa/codecs/snd-aoa-codec-tas.c
> > b/sound/aoa/codecs/snd-aoa-codec-tas.c
> > index 7a16a33..c922505 100644
> > --- a/sound/aoa/codecs/snd-aoa-codec-tas.c
> > +++ b/sound/aoa/codecs/snd-aoa-codec-tas.c
> > @@ -654,15 +654,15 @@ static struct snd_kcontrol_new bass_control = {
> > static struct transfer_info tas_transfers[] = {
> > {
> > /* input */
> > - .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
> > - SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
> > + .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
> > + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE,
> > .rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
> > SNDRV_PCM_RATE_48000,
> > .transfer_in = 1,
> > },
> > {
> > /* output */
> > - .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
> > - SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
> > + .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
> > + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE,
> > .rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
> > SNDRV_PCM_RATE_48000,
> > .transfer_in = 0,
> > },
> >
> >
>
> ___
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
On Monday 18 August 2008, Anton Vorontsov wrote: > On Mon, Aug 18, 2008 at 04:44:36PM +0200, Laurent Pinchart wrote: > > On Monday 18 August 2008, Anton Vorontsov wrote: > > > On Mon, Aug 18, 2008 at 03:58:46PM +0200, Laurent Pinchart wrote: > > > [...] > > > > > Not exactly. But you can do this way, if you need to preserve > > > > > a direction. What I did is a bit different though. > > > > > > > > > > qe_gpio_set_dedicated() actually just restores a mode that > > > > > firmware had set up, including direction (since direction could > > > > > be a part of dedicated configuration). > > > > > > > > > > That is, upon GPIO controller registration, we save all registers, > > > > > then driver can set up a pin to a GPIO mode via standard API, and > > > > > then it can _revert_ a pin to a dedicated function via > > > > > qe_gpio_set_dedicated() call. Dedicated function is specified by > > > > > the firmware (or board file), we're just restoring it. > > > > > > > > The semantic of the set_dedicated() operation needs to be clearly > > > > defined then. > > > > > > It is. We set up a dedicated function that firmware (or board file) > > > has configured. > > > > A comment in the source would help. > > > > > > I can live with this behaviour, but it might not be > > > > acceptable for everybody. > > > > > > For example? > > > > > > > Your patch requires the firmware to set a pin in dedicated mode at > > > > bootup in order to be used later in dedicated mode. > > > > > > Yes. On a PowerPC this is always true: firmware should set up PIO > > > config. Linux' board file could fixup the firmware though. > > > > That's not what I meant. What if the hardware requires to pin to be > > configured in GPIO mode with a fixed value until the SOC-specific > > driver that will drive the GPIO is loaded ? That's not possible > > with your API. > > Yes, this isn't possible with this API. Because you can do this > with standard GPIO API! ;-) > > Just call gpio_direction_*() in the board file, before probing the > hardware. You'd have to do that after the GPIO drivers saved the pin registers. > > Until a SOC peripheral is initialized by its associated Linux driver, > > the behaviour of a GPIO pin in dedicated mode will be undefined. > > Huh?! Then all current software is simply broken: we're setting pinmux > config _prior_ to controller initialization. Undefined behaviour doesn't mean broken behaviour :-) Signals coming from SOC peripherals are mostly undefined until the peripheral is initialized. For most hardware that doesn't matter much, but it might in some cases. For instance the state of the RTS signal on a serial port probably doesn't matter before we start serial communication, but some boards might require that RTS is deasserted before the controller is initialized. We can just ignore the issue for now and wait until it bites us. > > The firmware/board code will probably want to set the pin as a GPIO > > output with a fixed value until the driver initializes the hardware. > > Probably? Do you have any such hardware? Nope. I was referring to the hardware such as in the above example. > > > Another option would be to add some argument to the set_dedicated > > > call, thus the software could specify arbitrary dedicated > > > function (thus no need to save/restore anything). But this would > > > be SOC-model specific, thus no driver can use this argument anyway. > > > > Drivers that require dedicated mode are SOC-specific anyway. > > I didn't say "SOC-specific". I said "SOC-model specific", which > means that the driver would be not portable even across QE chips > (i.e. MPC8323 vs. MPC8360, you can assume that the "CLK12" function > is having same PAR/ODR/DAT/DIR bits). If I'm not mistaken, the PAR bit is used to select between GPIO and dedicated mode by definition. It should be safe to assume that setting a GPIO in dedicated mode requires the PAR bit to be set. But as I stated above, we can ignore that for now until a hardware use case comes up. > > > > If, for some > > > > reason (driver not loaded, ...), no GPIO user shows up for that > > > > pin, it will stay configured in dedicated mode. > > > > > > Yes. > > > > > > > It might be better to set the PAR bit unconditionally in > > > > > > Why it might be better? > > > > Because, as explained a few lines down, the board initialization code > > will be able to configure a pin in a known state (PAR not set) at boot > > time until a driver requests the pin to be switched to dedicated mode. > > You can do this as I described above. But prior to this, yes, you have > to configure the pins and let Linux save these values. There is no other > way to pass this information, unfortunately. Ok. I started implementing CPM2 dedicated mode support to be used in the CPM UART driver for RTS/CTS flow control, and soon realized there was a show stopper. The CPM UART driver is mostly CPM1/CPM2 agnostic. I can't use a function such as cpm2_gpio32_set_dedicate
Re: [MPC7448] machdep_calls
So I will write .setup_arch of machine_call structure. When is ppc_md.setup_arch() called ? 2008/8/19, Benjamin Herrenschmidt <[EMAIL PROTECTED]>: > > On Tue, 2008-08-19 at 09:00 +0200, Sébastien Chrétien wrote: > > I have no screen that's why I have to use UART. I followed the CPM > > model in head_32.S : > > #ifdef CONFIG_PPC_EARLY_DEBUG_CPM > > setup_cpm_bat: > > lisr8, 0xf000 > > orir8, r8,0x002a > > mtsprSPRN_DBAT1L, r8 > > > > lisr11, 0xf000 > > orir11, r11, (BL_1M << 2) | 2 > > mtsprSPRN_DBAT1U, r11 > > > > blr > > #endif > > > The "EARLY DEBUG" stuff is a pile of hacks to help with bringup, > it's definitely not a long term solution to your problems. > > You may also want to look at Grant Likely's work on doing proper > early ioremap using BATs. > > > > With this code I can use udbg. > > > > According to you, what is the best way ? > > > The above is fine for early debug console. But that's definitely > not the only kind of thing you may want to put in your setup_arch()... > Look at what others do. > > Ben. > > > > 2008/8/18, Benjamin Herrenschmidt <[EMAIL PROTECTED]>: > > On Mon, 2008-08-18 at 16:17 +0200, Sébastien Chrétien wrote: > > > The mpc7448hpc2 uses a tsi108-bridge. My board uses an IP on > > a FPGA.. > > > I read the code of mpc7448_hpc2.c. > > > It uses a ioremap in order to iniatilize the tsi108 > > registers. But I > > > have already initialized MMU with my registers in HEAD_32.S. > > Do I need > > > to use ioremap in setup_arch() ? > > > > > > Why did you hack head_32.S ? You shouldn't do that... This is > > common > > code, not platform code. > > > > Ben. > > > > > > > > > > > > > > 2008/8/18, Michael Ellerman <[EMAIL PROTECTED]>: > > > On Mon, 2008-08-18 at 13:35 +0200, Sébastien > > Chrétien wrote: > > > > Can somebody explain me the aim of the > > > function "setup_arch" in the > > > > machine_call structure ? > > > > > > > > > Is this MPC7448 anything like an mpc7448hpc2 ? > > > > > > If so maybe you should start by looking at the code > > for it in: > > > > > > arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c > > > > > > Even if it's not related, that will give you some > > idea of what > > > the > > > callbacks are for. > > > > > > 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 > > > > > > > > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Corrections please ...
On Monday 18 August 2008, Kevin Diggs wrote:
> Subject: Corrections please ...
The subject should be the one line change log, e.g.
[PATCH] add kerneldoc comments for completion.h
Also, cc the maintainer of the code. If you can't tell
from the MAINTAINERS file, look for the most common
name when doing 'git log path/to/file.c'. In this case,
there does not seem to be an actual maintainer, but I
would expect Willy and Ingo to be interested in the code.
Read Documentation/SubmittingPatches.
> Could I get any needed corrections on this. Especially on the "???"
>
The introductory text should explain why the patch is needed.
If you have more comments, put them behind the changelog text,
under a '---' line.
> [EMAIL PROTECTED] linux-2.6.26]$ diff -U3
> include/linux/completion.{h.orig,h}|more
> --- include/linux/completion.h.orig 2008-08-13 00:56:52.0 -0700
> +++ include/linux/completion.h 2008-08-18 13:00:23.0 -0700
Patches should be in -p1 format. Best use a tool like quilt, git or
mercurial to generate the patch instead of doing it by hand.
> @@ -10,6 +10,16 @@
>
> #include
>
> +/**
> + * struct completion - structure used to maintain state for a "completion"
> + * @done: counting variable used to signal completion
> + * @wait: internal wait queue head; used for locking and synchronization
> + *
> + * This is the structure used to maintain the state for a "completion". See
> + * also: complete(), wait_for_completion() (and friends _timeout,
> + * _interruptible, _interruptible_timeout, and _killable),
> init_completion(),
> + * and macros DECLARE_COMPLETION() and INIT_COMPLETION().
> + */
Line wrapping is broken, you need the right settings for sending unmodified
emails from your mail client.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: remove include of linux/of_device.h from asm/of_device.h
Now that we have removed all inclusions of asm/of_device.h, this compatability include can be removed. Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- arch/powerpc/include/asm/of_device.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) This depends on my previous patch "powerpc/drivers: use linux/of_device.h instead of asm/of_device.h". diff --git a/arch/powerpc/include/asm/of_device.h b/arch/powerpc/include/asm/of_device.h index 3c12399..a64debf 100644 --- a/arch/powerpc/include/asm/of_device.h +++ b/arch/powerpc/include/asm/of_device.h @@ -24,8 +24,5 @@ extern struct of_device *of_device_alloc(struct device_node *np, extern int of_device_uevent(struct device *dev, struct kobj_uevent_env *env); -/* This is just here during the transition */ -#include - #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_OF_DEVICE_H */ -- 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 0/5] Relocatable 64-bit kernel using linker PIE support
Paul Mackerras wrote: Mohan Kumar M writes: Attaching the .config Hmmm, your config works for me on a POWER6 partition here, whether I netboot the zImage.pseries or boot it with yaboot. I wonder if your toolchain is an older version. What is the output from ld --version and gcc --version? # ld --version GNU ld version 2.16.91.0.5 20051219 (SUSE Linux) # gcc --version gcc (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux) If the problem is related to toolchain version, which one you recommend to test? Also, could you send me off-list your compiled vmlinux? You can download the zipped vmlinux at http://mohankumar.m.googlepages.com/vmlinux.gz Regards, Mohan. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
On Tue, 2008-08-19 at 09:00 +0200, Sébastien Chrétien wrote: > I have no screen that's why I have to use UART. I followed the CPM > model in head_32.S : > #ifdef CONFIG_PPC_EARLY_DEBUG_CPM > setup_cpm_bat: > lisr8, 0xf000 > orir8, r8,0x002a > mtsprSPRN_DBAT1L, r8 > > lisr11, 0xf000 > orir11, r11, (BL_1M << 2) | 2 > mtsprSPRN_DBAT1U, r11 > > blr > #endif The "EARLY DEBUG" stuff is a pile of hacks to help with bringup, it's definitely not a long term solution to your problems. You may also want to look at Grant Likely's work on doing proper early ioremap using BATs. > With this code I can use udbg. > > According to you, what is the best way ? The above is fine for early debug console. But that's definitely not the only kind of thing you may want to put in your setup_arch()... Look at what others do. Ben. > 2008/8/18, Benjamin Herrenschmidt <[EMAIL PROTECTED]>: > On Mon, 2008-08-18 at 16:17 +0200, Sébastien Chrétien wrote: > > The mpc7448hpc2 uses a tsi108-bridge. My board uses an IP on > a FPGA.. > > I read the code of mpc7448_hpc2.c. > > It uses a ioremap in order to iniatilize the tsi108 > registers. But I > > have already initialized MMU with my registers in HEAD_32.S. > Do I need > > to use ioremap in setup_arch() ? > > > Why did you hack head_32.S ? You shouldn't do that... This is > common > code, not platform code. > > Ben. > > > > > > > > > 2008/8/18, Michael Ellerman <[EMAIL PROTECTED]>: > > On Mon, 2008-08-18 at 13:35 +0200, Sébastien > Chrétien wrote: > > > Can somebody explain me the aim of the > > function "setup_arch" in the > > > machine_call structure ? > > > > > > Is this MPC7448 anything like an mpc7448hpc2 ? > > > > If so maybe you should start by looking at the code > for it in: > > > > arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c > > > > Even if it's not related, that will give you some > idea of what > > the > > callbacks are for. > > > > 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 > > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
I have no screen that's why I have to use UART. I followed the CPM model in head_32.S : #ifdef CONFIG_PPC_EARLY_DEBUG_CPM setup_cpm_bat: lisr8, 0xf000 orir8, r8,0x002a mtsprSPRN_DBAT1L, r8 lisr11, 0xf000 orir11, r11, (BL_1M << 2) | 2 mtsprSPRN_DBAT1U, r11 blr #endif With this code I can use udbg. According to you, what is the best way ? 2008/8/18, Benjamin Herrenschmidt <[EMAIL PROTECTED]>: > > On Mon, 2008-08-18 at 16:17 +0200, Sébastien Chrétien wrote: > > The mpc7448hpc2 uses a tsi108-bridge. My board uses an IP on a FPGA.. > > I read the code of mpc7448_hpc2.c. > > It uses a ioremap in order to iniatilize the tsi108 registers. But I > > have already initialized MMU with my registers in HEAD_32.S. Do I need > > to use ioremap in setup_arch() ? > > > Why did you hack head_32.S ? You shouldn't do that... This is common > code, not platform code. > > Ben. > > > > > > > > > 2008/8/18, Michael Ellerman <[EMAIL PROTECTED]>: > > On Mon, 2008-08-18 at 13:35 +0200, Sébastien Chrétien wrote: > > > Can somebody explain me the aim of the > > function "setup_arch" in the > > > machine_call structure ? > > > > > > Is this MPC7448 anything like an mpc7448hpc2 ? > > > > If so maybe you should start by looking at the code for it in: > > > > arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c > > > > Even if it's not related, that will give you some idea of what > > the > > callbacks are for. > > > > 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 > > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
