[PATCH] generic clk API implementation for MIPS

[PATCH] generic clk API implementation for MIPS

[Atsushi Nemoto]

The clock framework (clk_get(), etc.) would be useful to provide some
clock values to platform devices or so.

This MIPS implementation is derived (and stripped) from the SH
implementation.

Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
 arch/mips/lib/Makefile   |    2 +-
 arch/mips/lib/clock.c    |  189 ++++++++++++++++++++++++++++++++++++++++++++++
 include/asm-mips/clock.h |   39 ++++++++++
 3 files changed, 229 insertions(+), 1 deletions(-)

diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index a960c05..ecea595 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -3,7 +3,7 @@
 #
 
 lib-y	+= csum_partial.o memcpy.o memcpy-inatomic.o memset.o strlen_user.o \
-	   strncpy_user.o strnlen_user.o uncached.o
+	   strncpy_user.o strnlen_user.o uncached.o clock.o
 
 obj-y			+= iomap.o
 obj-$(CONFIG_PCI)	+= iomap-pci.o
diff --git a/arch/mips/lib/clock.c b/arch/mips/lib/clock.c
new file mode 100644
index 0000000..059294d
--- /dev/null
+++ b/arch/mips/lib/clock.c
@@ -0,0 +1,189 @@
+/*
+ * arch/mips/lib/clock.c - MIPS clock framework
+ *
+ * This clock framework is derived from the SH version by:
+ *
+ *  Copyright (C) 2005, 2006  Paul Mundt
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/list.h>
+#include <linux/kref.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <asm/clock.h>
+
+static LIST_HEAD(clock_list);
+static DEFINE_SPINLOCK(clock_lock);
+static DEFINE_MUTEX(clock_list_lock);
+
+static int __clk_enable(struct clk *clk)
+{
+	/*
+	 * See if this is the first time we're enabling the clock, some
+	 * clocks that are always enabled still require "special"
+	 * initialization. This is especially true if the clock mode
+	 * changes and the clock needs to hunt for the proper set of
+	 * divisors to use before it can effectively recalc.
+	 */
+	if (unlikely(atomic_read(&clk->kref.refcount) == 1))
+		if (clk->ops && clk->ops->init)
+			clk->ops->init(clk);
+
+	if (clk->flags & CLK_ALWAYS_ENABLED)
+		return 0;
+
+	if (likely(clk->ops && clk->ops->enable))
+		clk->ops->enable(clk);
+
+	kref_get(&clk->kref);
+	return 0;
+}
+
+int clk_enable(struct clk *clk)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&clock_lock, flags);
+	ret = __clk_enable(clk);
+	spin_unlock_irqrestore(&clock_lock, flags);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(clk_enable);
+
+static void clk_kref_release(struct kref *kref)
+{
+	/* Nothing to do */
+}
+
+static void __clk_disable(struct clk *clk)
+{
+	if (clk->flags & CLK_ALWAYS_ENABLED)
+		return;
+
+	kref_put(&clk->kref, clk_kref_release);
+}
+
+void clk_disable(struct clk *clk)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&clock_lock, flags);
+	__clk_disable(clk);
+	spin_unlock_irqrestore(&clock_lock, flags);
+}
+EXPORT_SYMBOL_GPL(clk_disable);
+
+int clk_register(struct clk *clk)
+{
+	mutex_lock(&clock_list_lock);
+
+	list_add(&clk->node, &clock_list);
+	kref_init(&clk->kref);
+
+	mutex_unlock(&clock_list_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(clk_register);
+
+void clk_unregister(struct clk *clk)
+{
+	mutex_lock(&clock_list_lock);
+	list_del(&clk->node);
+	mutex_unlock(&clock_list_lock);
+}
+EXPORT_SYMBOL_GPL(clk_unregister);
+
+unsigned long clk_get_rate(struct clk *clk)
+{
+	return clk->rate;
+}
+EXPORT_SYMBOL_GPL(clk_get_rate);
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+	int ret = -EOPNOTSUPP;
+
+	if (likely(clk->ops && clk->ops->set_rate)) {
+		unsigned long flags;
+
+		spin_lock_irqsave(&clock_lock, flags);
+		ret = clk->ops->set_rate(clk, rate);
+		spin_unlock_irqrestore(&clock_lock, flags);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(clk_set_rate);
+
+/*
+ * Returns a clock. Note that we first try to use device id on the bus
+ * and clock name. If this fails, we try to use clock name only.
+ */
+struct clk *clk_get(struct device *dev, const char *id)
+{
+	struct clk *p, *clk = ERR_PTR(-ENOENT);
+	int idno;
+
+	if (dev == NULL || dev->bus != &platform_bus_type)
+		idno = -1;
+	else
+		idno = to_platform_device(dev)->id;
+
+	mutex_lock(&clock_list_lock);
+	list_for_each_entry(p, &clock_list, node) {
+		if (p->id == idno &&
+		    strcmp(id, p->name) == 0 && try_module_get(p->owner)) {
+			clk = p;
+			goto found;
+		}
+	}
+
+	list_for_each_entry(p, &clock_list, node) {
+		if (strcmp(id, p->name) == 0 && try_module_get(p->owner)) {
+			clk = p;
+			break;
+		}
+	}
+
+found:
+	mutex_unlock(&clock_list_lock);
+
+	return clk;
+}
+EXPORT_SYMBOL_GPL(clk_get);
+
+void clk_put(struct clk *clk)
+{
+	if (clk && !IS_ERR(clk))
+		module_put(clk->owner);
+}
+EXPORT_SYMBOL_GPL(clk_put);
+
+long clk_round_rate(struct clk *clk, unsigned long rate)
+{
+	return rate;
+}
+EXPORT_SYMBOL_GPL(clk_round_rate);
+
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+	clk->parent = parent;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(clk_set_parent);
+
+struct clk *clk_get_parent(struct clk *clk)
+{
+	return clk->parent ?: ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(clk_get_parent);
diff --git a/include/asm-mips/clock.h b/include/asm-mips/clock.h
new file mode 100644
index 0000000..6170f31
--- /dev/null
+++ b/include/asm-mips/clock.h
@@ -0,0 +1,39 @@
+#ifndef __ASM_MIPS_CLOCK_H
+#define __ASM_MIPS_CLOCK_H
+
+/* generic clk API implementation --- derived from include/asm-sh/clock.h */
+
+#include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/clk.h>
+
+struct clk;
+
+struct clk_ops {
+	void (*init)(struct clk *clk);
+	void (*enable)(struct clk *clk);
+	void (*disable)(struct clk *clk);
+	int (*set_rate)(struct clk *clk, unsigned long rate);
+};
+
+struct clk {
+	struct list_head	node;
+	const char		*name;
+	int			id;
+	struct module		*owner;
+
+	struct clk		*parent;
+	struct clk_ops		*ops;
+
+	struct kref		kref;
+
+	unsigned long		rate;
+	unsigned long		flags;
+};
+
+#define CLK_ALWAYS_ENABLED	(1 << 0)
+
+int clk_register(struct clk *);
+void clk_unregister(struct clk *);
+
+#endif /* __ASM_MIPS_CLOCK_H */

Re: [PATCH] generic clk API implementation for MIPS

[Franck Bui-Huu]

Hi Atsushi,

On 6/25/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> The clock framework (clk_get(), etc.) would be useful to provide some
> clock values to platform devices or so.
>

yes it can be usefull.

> This MIPS implementation is derived (and stripped) from the SH
> implementation.
>

Did you consider Atmel implementation which is even more stripped ?

The main difference seems that your version has module support. I'm
not sure how usefull it is though.

Thanks
-- 
               Franck

Re: [PATCH] generic clk API implementation for MIPS

[Atsushi Nemoto]

On Tue, 26 Jun 2007 11:37:31 +0200, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> Did you consider Atmel implementation which is even more stripped ?

Well, it seems simpler, but I suppose clk_register() is very useful ;)

> The main difference seems that your version has module support. I'm
> not sure how usefull it is though.

Indeed.  Revised.


Subject: [PATCH] generic clk API implementation for MIPS

The clock framework (clk_get(), etc.) would be useful to provide some
clock values to platform devices or so.

This MIPS implementation is derived (and stripped) from the SH
implementation.

Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
 arch/mips/lib/Makefile   |    2 +-
 arch/mips/lib/clock.c    |  185 ++++++++++++++++++++++++++++++++++++++++++++++
 include/asm-mips/clock.h |   38 ++++++++++
 3 files changed, 224 insertions(+), 1 deletions(-)

diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index a960c05..ecea595 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -3,7 +3,7 @@
 #
 
 lib-y	+= csum_partial.o memcpy.o memcpy-inatomic.o memset.o strlen_user.o \
-	   strncpy_user.o strnlen_user.o uncached.o
+	   strncpy_user.o strnlen_user.o uncached.o clock.o
 
 obj-y			+= iomap.o
 obj-$(CONFIG_PCI)	+= iomap-pci.o
diff --git a/arch/mips/lib/clock.c b/arch/mips/lib/clock.c
new file mode 100644
index 0000000..2bfd0b4
--- /dev/null
+++ b/arch/mips/lib/clock.c
@@ -0,0 +1,185 @@
+/*
+ * arch/mips/lib/clock.c - MIPS clock framework
+ *
+ * This clock framework is derived from the SH version by:
+ *
+ *  Copyright (C) 2005, 2006  Paul Mundt
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/mutex.h>
+#include <linux/list.h>
+#include <linux/kref.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <asm/clock.h>
+
+static LIST_HEAD(clock_list);
+static DEFINE_SPINLOCK(clock_lock);
+static DEFINE_MUTEX(clock_list_lock);
+
+static int __clk_enable(struct clk *clk)
+{
+	/*
+	 * See if this is the first time we're enabling the clock, some
+	 * clocks that are always enabled still require "special"
+	 * initialization. This is especially true if the clock mode
+	 * changes and the clock needs to hunt for the proper set of
+	 * divisors to use before it can effectively recalc.
+	 */
+	if (unlikely(atomic_read(&clk->kref.refcount) == 1))
+		if (clk->ops && clk->ops->init)
+			clk->ops->init(clk);
+
+	if (clk->flags & CLK_ALWAYS_ENABLED)
+		return 0;
+
+	if (likely(clk->ops && clk->ops->enable))
+		clk->ops->enable(clk);
+
+	kref_get(&clk->kref);
+	return 0;
+}
+
+int clk_enable(struct clk *clk)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&clock_lock, flags);
+	ret = __clk_enable(clk);
+	spin_unlock_irqrestore(&clock_lock, flags);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(clk_enable);
+
+static void clk_kref_release(struct kref *kref)
+{
+	/* Nothing to do */
+}
+
+static void __clk_disable(struct clk *clk)
+{
+	if (clk->flags & CLK_ALWAYS_ENABLED)
+		return;
+
+	kref_put(&clk->kref, clk_kref_release);
+}
+
+void clk_disable(struct clk *clk)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&clock_lock, flags);
+	__clk_disable(clk);
+	spin_unlock_irqrestore(&clock_lock, flags);
+}
+EXPORT_SYMBOL_GPL(clk_disable);
+
+int clk_register(struct clk *clk)
+{
+	mutex_lock(&clock_list_lock);
+
+	list_add(&clk->node, &clock_list);
+	kref_init(&clk->kref);
+
+	mutex_unlock(&clock_list_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(clk_register);
+
+void clk_unregister(struct clk *clk)
+{
+	mutex_lock(&clock_list_lock);
+	list_del(&clk->node);
+	mutex_unlock(&clock_list_lock);
+}
+EXPORT_SYMBOL_GPL(clk_unregister);
+
+unsigned long clk_get_rate(struct clk *clk)
+{
+	return clk->rate;
+}
+EXPORT_SYMBOL_GPL(clk_get_rate);
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+	int ret = -EOPNOTSUPP;
+
+	if (likely(clk->ops && clk->ops->set_rate)) {
+		unsigned long flags;
+
+		spin_lock_irqsave(&clock_lock, flags);
+		ret = clk->ops->set_rate(clk, rate);
+		spin_unlock_irqrestore(&clock_lock, flags);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(clk_set_rate);
+
+/*
+ * Returns a clock. Note that we first try to use device id on the bus
+ * and clock name. If this fails, we try to use clock name only.
+ */
+struct clk *clk_get(struct device *dev, const char *id)
+{
+	struct clk *p, *clk = ERR_PTR(-ENOENT);
+	int idno;
+
+	if (dev == NULL || dev->bus != &platform_bus_type)
+		idno = -1;
+	else
+		idno = to_platform_device(dev)->id;
+
+	mutex_lock(&clock_list_lock);
+	list_for_each_entry(p, &clock_list, node) {
+		if (p->id == idno && strcmp(id, p->name) == 0) {
+			clk = p;
+			goto found;
+		}
+	}
+
+	list_for_each_entry(p, &clock_list, node) {
+		if (strcmp(id, p->name) == 0) {
+			clk = p;
+			break;
+		}
+	}
+
+found:
+	mutex_unlock(&clock_list_lock);
+
+	return clk;
+}
+EXPORT_SYMBOL_GPL(clk_get);
+
+void clk_put(struct clk *clk)
+{
+}
+EXPORT_SYMBOL_GPL(clk_put);
+
+long clk_round_rate(struct clk *clk, unsigned long rate)
+{
+	return rate;
+}
+EXPORT_SYMBOL_GPL(clk_round_rate);
+
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+	clk->parent = parent;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(clk_set_parent);
+
+struct clk *clk_get_parent(struct clk *clk)
+{
+	return clk->parent ?: ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(clk_get_parent);
diff --git a/include/asm-mips/clock.h b/include/asm-mips/clock.h
new file mode 100644
index 0000000..1c1429b
--- /dev/null
+++ b/include/asm-mips/clock.h
@@ -0,0 +1,38 @@
+#ifndef __ASM_MIPS_CLOCK_H
+#define __ASM_MIPS_CLOCK_H
+
+/* generic clk API implementation --- derived from include/asm-sh/clock.h */
+
+#include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/clk.h>
+
+struct clk;
+
+struct clk_ops {
+	void (*init)(struct clk *clk);
+	void (*enable)(struct clk *clk);
+	void (*disable)(struct clk *clk);
+	int (*set_rate)(struct clk *clk, unsigned long rate);
+};
+
+struct clk {
+	struct list_head	node;
+	const char		*name;
+	int			id;
+
+	struct clk		*parent;
+	struct clk_ops		*ops;
+
+	struct kref		kref;
+
+	unsigned long		rate;
+	unsigned long		flags;
+};
+
+#define CLK_ALWAYS_ENABLED	(1 << 0)
+
+int clk_register(struct clk *);
+void clk_unregister(struct clk *);
+
+#endif /* __ASM_MIPS_CLOCK_H */

Re: [PATCH] generic clk API implementation for MIPS

[Franck Bui-Huu]

Atsushi Nemoto wrote:
>
> Well, it seems simpler, but I suppose clk_register() is very useful ;)
>

Thinking about it, it seems to me that a clock is very static. I can't
think of a use case that would need to register a new clock after the
kernel has booted. Do you have a use case in mind ? cpu hotplug
perhaps ?

I'm a bit worry because if we go that way, we must be sure that
clk_register() can be called very early in the boot process. For
example, when using early printk thing...

> +static void clk_kref_release(struct kref *kref)
> +{
> +	/* Nothing to do */
> +}
> +
> +static void __clk_disable(struct clk *clk)
> +{
> +	if (clk->flags & CLK_ALWAYS_ENABLED)
> +		return;
> +
> +	kref_put(&clk->kref, clk_kref_release);
> +}
> +
> +void clk_disable(struct clk *clk)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&clock_lock, flags);
> +	__clk_disable(clk);
> +	spin_unlock_irqrestore(&clock_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(clk_disable);

It seems that you stripped too much here: where clk->disable() method
is called ?

> +struct clk;
> +
> +struct clk_ops {
> +	void (*init)(struct clk *clk);
> +	void (*enable)(struct clk *clk);
> +	void (*disable)(struct clk *clk);
> +	int (*set_rate)(struct clk *clk, unsigned long rate);
> +};
> +
> +struct clk {
> +	struct list_head	node;
> +	const char		*name;
> +	int			id;
> +
> +	struct clk		*parent;

Is this field used by board code ?
---
                Franck

Re: [PATCH] generic clk API implementation for MIPS

[Atsushi Nemoto]

On Tue, 26 Jun 2007 17:20:43 +0200, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> > Well, it seems simpler, but I suppose clk_register() is very useful ;)
> 
> Thinking about it, it seems to me that a clock is very static. I can't
> think of a use case that would need to register a new clock after the
> kernel has booted. Do you have a use case in mind ? cpu hotplug
> perhaps ?
> 
> I'm a bit worry because if we go that way, we must be sure that
> clk_register() can be called very early in the boot process. For
> example, when using early printk thing...

I just think having centralized clock_list[] array might cause
maintainance issue.  Calling clk_register() in your platform's
arch_initcall (or so) seems enough for me.

I don't think we should limit clk_register() usage to only boot stage.

> > +EXPORT_SYMBOL_GPL(clk_disable);
> 
> It seems that you stripped too much here: where clk->disable() method
> is called ?

Oh, you are right.  I will fix it.

> > +struct clk {
> > +	struct list_head	node;
> > +	const char		*name;
> > +	int			id;
> > +
> > +	struct clk		*parent;
> 
> Is this field used by board code ?

I do not know.  I just implemented API in include/linux/clk.h which
contains clk_get_parent(), etc.


Take 3.

Subject: [PATCH] generic clk API implementation for MIPS

The clock framework (clk_get(), etc.) would be useful to provide some
clock values to platform devices or so.

This MIPS implementation is derived (and stripped) from the SH
implementation.

Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index a960c05..ecea595 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -3,7 +3,7 @@
 #
 
 lib-y	+= csum_partial.o memcpy.o memcpy-inatomic.o memset.o strlen_user.o \
-	   strncpy_user.o strnlen_user.o uncached.o
+	   strncpy_user.o strnlen_user.o uncached.o clock.o
 
 obj-y			+= iomap.o
 obj-$(CONFIG_PCI)	+= iomap-pci.o
diff --git a/arch/mips/lib/clock.c b/arch/mips/lib/clock.c
new file mode 100644
index 0000000..50b4ad9
--- /dev/null
+++ b/arch/mips/lib/clock.c
@@ -0,0 +1,185 @@
+/*
+ * arch/mips/lib/clock.c - MIPS clock framework
+ *
+ * This clock framework is derived from the SH version by:
+ *
+ *  Copyright (C) 2005, 2006  Paul Mundt
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/mutex.h>
+#include <linux/list.h>
+#include <linux/kref.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <asm/clock.h>
+
+static LIST_HEAD(clock_list);
+static DEFINE_SPINLOCK(clock_lock);
+static DEFINE_MUTEX(clock_list_lock);
+
+static int __clk_enable(struct clk *clk)
+{
+	/*
+	 * See if this is the first time we're enabling the clock, some
+	 * clocks that are always enabled still require "special"
+	 * initialization. This is especially true if the clock mode
+	 * changes and the clock needs to hunt for the proper set of
+	 * divisors to use before it can effectively recalc.
+	 */
+	if (unlikely(atomic_read(&clk->kref.refcount) == 1))
+		if (clk->ops && clk->ops->init)
+			clk->ops->init(clk);
+
+	kref_get(&clk->kref);
+
+	if (likely(clk->ops && clk->ops->enable))
+		clk->ops->enable(clk);
+
+	return 0;
+}
+
+int clk_enable(struct clk *clk)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&clock_lock, flags);
+	ret = __clk_enable(clk);
+	spin_unlock_irqrestore(&clock_lock, flags);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(clk_enable);
+
+static void clk_kref_release(struct kref *kref)
+{
+	/* Nothing to do */
+}
+
+static void __clk_disable(struct clk *clk)
+{
+	int count = kref_put(&clk->kref, clk_kref_release);
+
+	if (!count) {	/* count reaches zero, disable the clock */
+		if (likely(clk->ops && clk->ops->disable))
+			clk->ops->disable(clk);
+	}
+}
+
+void clk_disable(struct clk *clk)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&clock_lock, flags);
+	__clk_disable(clk);
+	spin_unlock_irqrestore(&clock_lock, flags);
+}
+EXPORT_SYMBOL_GPL(clk_disable);
+
+int clk_register(struct clk *clk)
+{
+	mutex_lock(&clock_list_lock);
+
+	list_add(&clk->node, &clock_list);
+	kref_init(&clk->kref);
+
+	mutex_unlock(&clock_list_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(clk_register);
+
+void clk_unregister(struct clk *clk)
+{
+	mutex_lock(&clock_list_lock);
+	list_del(&clk->node);
+	mutex_unlock(&clock_list_lock);
+}
+EXPORT_SYMBOL_GPL(clk_unregister);
+
+unsigned long clk_get_rate(struct clk *clk)
+{
+	return clk->rate;
+}
+EXPORT_SYMBOL_GPL(clk_get_rate);
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+	int ret = -EOPNOTSUPP;
+
+	if (likely(clk->ops && clk->ops->set_rate)) {
+		unsigned long flags;
+
+		spin_lock_irqsave(&clock_lock, flags);
+		ret = clk->ops->set_rate(clk, rate);
+		spin_unlock_irqrestore(&clock_lock, flags);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(clk_set_rate);
+
+/*
+ * Returns a clock. Note that we first try to use device id on the bus
+ * and clock name. If this fails, we try to use clock name only.
+ */
+struct clk *clk_get(struct device *dev, const char *id)
+{
+	struct clk *p, *clk = ERR_PTR(-ENOENT);
+	int idno;
+
+	if (dev == NULL || dev->bus != &platform_bus_type)
+		idno = -1;
+	else
+		idno = to_platform_device(dev)->id;
+
+	mutex_lock(&clock_list_lock);
+	list_for_each_entry(p, &clock_list, node) {
+		if (p->id == idno && strcmp(id, p->name) == 0) {
+			clk = p;
+			goto found;
+		}
+	}
+
+	list_for_each_entry(p, &clock_list, node) {
+		if (strcmp(id, p->name) == 0) {
+			clk = p;
+			break;
+		}
+	}
+
+found:
+	mutex_unlock(&clock_list_lock);
+
+	return clk;
+}
+EXPORT_SYMBOL_GPL(clk_get);
+
+void clk_put(struct clk *clk)
+{
+}
+EXPORT_SYMBOL_GPL(clk_put);
+
+long clk_round_rate(struct clk *clk, unsigned long rate)
+{
+	return rate;
+}
+EXPORT_SYMBOL_GPL(clk_round_rate);
+
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+	clk->parent = parent;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(clk_set_parent);
+
+struct clk *clk_get_parent(struct clk *clk)
+{
+	return clk->parent ?: ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(clk_get_parent);
diff --git a/include/asm-mips/clock.h b/include/asm-mips/clock.h
new file mode 100644
index 0000000..d2b3b92
--- /dev/null
+++ b/include/asm-mips/clock.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_MIPS_CLOCK_H
+#define __ASM_MIPS_CLOCK_H
+
+/* generic clk API implementation --- derived from include/asm-sh/clock.h */
+
+#include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/clk.h>
+
+struct clk;
+
+struct clk_ops {
+	void (*init)(struct clk *clk);
+	void (*enable)(struct clk *clk);
+	void (*disable)(struct clk *clk);
+	int (*set_rate)(struct clk *clk, unsigned long rate);
+};
+
+struct clk {
+	struct list_head	node;
+	const char		*name;
+	int			id;
+
+	struct clk		*parent;
+	struct clk_ops		*ops;
+
+	struct kref		kref;
+
+	unsigned long		rate;
+};
+
+int clk_register(struct clk *);
+void clk_unregister(struct clk *);
+
+#endif /* __ASM_MIPS_CLOCK_H */

Re: [PATCH] generic clk API implementation for MIPS

[Franck Bui-Huu]

On 6/26/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> I just think having centralized clock_list[] array might cause
> maintainance issue.  Calling clk_register() in your platform's
> arch_initcall (or so) seems enough for me.

It seems that clock configuration highly depends on the board, not the
arch. For example, a board can have only static clocks which won't be
unregistered later. In that case most of code provided by the patch is
useless.

So maybe the best thing is to let each board implements their own
generic clock API (exactly like the generic GPIO API you did
recently). Or make a default implementation (your patch) and allow
others boards to make their own implementation.

What do you think ?
-- 
               Franck

Re: [PATCH] generic clk API implementation for MIPS

[Atsushi Nemoto]

On Tue, 26 Jun 2007 22:02:53 +0200, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> It seems that clock configuration highly depends on the board, not the
> arch. For example, a board can have only static clocks which won't be
> unregistered later. In that case most of code provided by the patch is
> useless.
> 
> So maybe the best thing is to let each board implements their own
> generic clock API (exactly like the generic GPIO API you did
> recently). Or make a default implementation (your patch) and allow
> others boards to make their own implementation.

Hmm... I had thought the default implementation would be useful, but
now I change my mind ;)  What people expected on its implementation
would vary too much.

Now I think leaving all implementation to platform code is better.
I'll send rbtx4938 implementation (minimum one just for SPI driver)
soon.

Ralf, please do not apply or queue this patch :)

---
Atsushi Nemoto

Re: [PATCH] generic clk API implementation for MIPS

[Christoph Hellwig]

On Wed, Jun 27, 2007 at 01:33:12AM +0900, Atsushi Nemoto wrote:
> This MIPS implementation is derived (and stripped) from the SH
> implementation.

Why is this not in architecture-independent code?

Re: [PATCH] generic clk API implementation for MIPS

[Atsushi Nemoto]

On Wed, 27 Jun 2007 17:39:32 +0200, Christoph Hellwig <hch@lst.de> wrote:
> > This MIPS implementation is derived (and stripped) from the SH
> > implementation.
> 
> Why is this not in architecture-independent code?

Yes, this is architecture independent.  If we could have consensus on
a generic (or least common) implementation, we can put it outside arch
directory.

But I gave up for now ;) I will leave all implementation for platform
code.

---
Atsushi Nemoto

Re: [PATCH] generic clk API implementation for MIPS

[Christoph Hellwig]

On Thu, Jun 28, 2007 at 11:22:23AM +0900, Atsushi Nemoto wrote:
> On Wed, 27 Jun 2007 17:39:32 +0200, Christoph Hellwig <hch@lst.de> wrote:
> > > This MIPS implementation is derived (and stripped) from the SH
> > > implementation.
> > 
> > Why is this not in architecture-independent code?
> 
> Yes, this is architecture independent.  If we could have consensus on
> a generic (or least common) implementation, we can put it outside arch
> directory.
> 
> But I gave up for now ;) I will leave all implementation for platform
> code.

I really dislike duplicating thing over architectures.  If you copy code
from another architecture the first though should be 'could and should
this be generic ?'.  So please try to get this lifted to common code
instead of duplicating it.

> 
> ---
> Atsushi Nemoto
---end quoted text---

Re: [PATCH] generic clk API implementation for MIPS

[Atsushi Nemoto]

On Thu, 28 Jun 2007 10:37:25 +0200, Christoph Hellwig <hch@lst.de> wrote:
> > But I gave up for now ;) I will leave all implementation for platform
> > code.
> 
> I really dislike duplicating thing over architectures.  If you copy code
> from another architecture the first though should be 'could and should
> this be generic ?'.  So please try to get this lifted to common code
> instead of duplicating it.

OK, I see.  But now I think the best thing we can provide as generic
is only "no clocks" implementation.

Do you think it is worth to put into lib/ directory?

struct clk *__weak clk_get(struct device *dev, const char *id)
{
	return ERR_PTR(-ENOENT);
}
EXPORT_SYMBOL(clk_get);

int __weak clk_enable(struct clk *clk)
{
	return 0;
}
EXPORT_SYMBOL(clk_enable);

void __weak clk_disable(struct clk *clk)
{
}
EXPORT_SYMBOL(clk_disable);

unsigned long __weak clk_get_rate(struct clk *clk)
{
	return 0;
}
EXPORT_SYMBOL(clk_get_rate);

void __weak clk_put(struct clk *clk)
{
}
EXPORT_SYMBOL(clk_put);


This might conflict with some current implementations which export
these APIs as EXPORT_SYMBOL_GPL...

---
Atsushi Nemoto

gdbserver

[Ratin Rahman (mratin)]

Anybody had luck with compiling gdbserver for mipsel? I am using x86
based machine running Fedora 2.6.11 kernel, the target device is IDT 434
running Mipsel 2.6.10 kernel. The gcc crosscompiler is mipsel-linux-gcc
and version 3.2.3.

I did a ./configure --host=mipsel-linux-gnu --target=mipsel-linux-gnu
followed by a make. Make failed with the messages: 

/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:33: syntax error
before numeric constant
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:49: syntax error
before numeric constant
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:61: syntax error
before numeric constant
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:94: syntax error
before numeric constant
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:112: syntax error
before numeric constant
linux-low.c: In function `kill_lwp':
linux-low.c:760: warning: unused variable `tkill_failed'
make: *** [linux-low.o] Error 1
[root@Clearnet gdbserver]# nano
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h
[root@Clearnet gdbserver]# nano
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h


The content of ptrace.h has the enums declared as 

/* Type of the REQUEST argument to `ptrace.'  */
enum __ptrace_request
{
  /* Indicate that the process making this request should be traced.
     All signals received by this process can be intercepted by its
     parent, and its parent can use the other `ptrace' requests.  */
  PTRACE_TRACEME = 0,
<==================================line 33
#define PT_TRACE_ME PTRACE_TRACEME

  /* Return the word in the process's text space at address ADDR.  */
  PTRACE_PEEKTEXT = 1,
#define PT_READ_I PTRACE_PEEKTEXT


..which looks pretty normal to me , anybod yhave any clue? 
Thanks,


Ratin 

gdbserver

[Ratin Rahman (mratin)]

Anybody had luck with compiling gdbserver for mipsel? I am using x86
based machine running Fedora 2.6.11 kernel, the target device is IDT 434
running Mipsel 2.6.10 kernel. The gcc crosscompiler is mipsel-linux-gcc
and version 3.2.3.

I did a ./configure --host=mipsel-linux-gnu --target=mipsel-linux-gnu
followed by a make. Make failed with the messages: 

/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:33: syntax error
before numeric constant
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:49: syntax error
before numeric constant
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:61: syntax error
before numeric constant
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:94: syntax error
before numeric constant
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:112: syntax error
before numeric constant
linux-low.c: In function `kill_lwp':
linux-low.c:760: warning: unused variable `tkill_failed'
make: *** [linux-low.o] Error 1
[root@Clearnet gdbserver]# nano
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h
[root@Clearnet gdbserver]# nano
/opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h


The content of ptrace.h has the enums declared as 

/* Type of the REQUEST argument to `ptrace.'  */
enum __ptrace_request
{
  /* Indicate that the process making this request should be traced.
     All signals received by this process can be intercepted by its
     parent, and its parent can use the other `ptrace' requests.  */
  PTRACE_TRACEME = 0,
<==================================line 33
#define PT_TRACE_ME PTRACE_TRACEME

  /* Return the word in the process's text space at address ADDR.  */
  PTRACE_PEEKTEXT = 1,
#define PT_READ_I PTRACE_PEEKTEXT


..which looks pretty normal to me , anybod yhave any clue? 
Thanks,


Ratin 

Re: gdbserver

[David Daney]

Ratin Rahman (mratin) wrote:
> Anybody had luck with compiling gdbserver for mipsel? I am using x86
> based machine running Fedora 2.6.11 kernel, the target device is IDT 434
> running Mipsel 2.6.10 kernel. The gcc crosscompiler is mipsel-linux-gcc
> and version 3.2.3.
> 
> I did a ./configure --host=mipsel-linux-gnu --target=mipsel-linux-gnu
> followed by a make. Make failed with the messages: 
> 
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:33: syntax error
> before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:49: syntax error
> before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:61: syntax error
> before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:94: syntax error
> before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:112: syntax error
> before numeric constant
> linux-low.c: In function `kill_lwp':
> linux-low.c:760: warning: unused variable `tkill_failed'
> make: *** [linux-low.o] Error 1
> [root@Clearnet gdbserver]# nano
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h
> [root@Clearnet gdbserver]# nano
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h
> 
> 
> The content of ptrace.h has the enums declared as 
> 
> /* Type of the REQUEST argument to `ptrace.'  */
> enum __ptrace_request
> {
>   /* Indicate that the process making this request should be traced.
>      All signals received by this process can be intercepted by its
>      parent, and its parent can use the other `ptrace' requests.  */
>   PTRACE_TRACEME = 0,
> <==================================line 33
> #define PT_TRACE_ME PTRACE_TRACEME
> 
>   /* Return the word in the process's text space at address ADDR.  */
>   PTRACE_PEEKTEXT = 1,
> #define PT_READ_I PTRACE_PEEKTEXT
> 
> 
> ..which looks pretty normal to me , anybod yhave any clue? 
> Thanks,
> 

Perhaps your toolchain is broken, or perhaps you need to configure 
differently.

With my glibc-2.3.3/gcc-3.4.3 toolchain I do:
../gdb-6.6/configure  --target=mipsel-linux --host=mipsel-linux 
--build=i686-pc-linux-gnu

Then make and voila! gdb, gdbserver et al. are built.

David Danay

RE: gdbserver

[Ratin Rahman (mratin)]

 
It might be the fact that I am trying to compile gdbsever from the
latest version of gdb with older toolchain. I need an upgraded gcc and
glibc but they are also failing to build. Not sure what order I should
compile them ..

Ratin


-----Original Message-----
From: David Daney [mailto:ddaney@avtrex.com] 
Sent: Thursday, June 28, 2007 2:41 PM
To: Ratin Rahman (mratin)
Cc: linux-mips@linux-mips.org
Subject: Re: gdbserver

Ratin Rahman (mratin) wrote:
> Anybody had luck with compiling gdbserver for mipsel? I am using x86 
> based machine running Fedora 2.6.11 kernel, the target device is IDT 
> 434 running Mipsel 2.6.10 kernel. The gcc crosscompiler is 
> mipsel-linux-gcc and version 3.2.3.
> 
> I did a ./configure --host=mipsel-linux-gnu --target=mipsel-linux-gnu 
> followed by a make. Make failed with the messages:
> 
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:33: syntax 
> error before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:49: syntax 
> error before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:61: syntax 
> error before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:94: syntax 
> error before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:112: syntax 
> error before numeric constant
> linux-low.c: In function `kill_lwp':
> linux-low.c:760: warning: unused variable `tkill_failed'
> make: *** [linux-low.o] Error 1
> [root@Clearnet gdbserver]# nano
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h
> [root@Clearnet gdbserver]# nano
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h
> 
> 
> The content of ptrace.h has the enums declared as
> 
> /* Type of the REQUEST argument to `ptrace.'  */ enum __ptrace_request

> {
>   /* Indicate that the process making this request should be traced.
>      All signals received by this process can be intercepted by its
>      parent, and its parent can use the other `ptrace' requests.  */
>   PTRACE_TRACEME = 0,
> <==================================line 33 #define PT_TRACE_ME 
> PTRACE_TRACEME
> 
>   /* Return the word in the process's text space at address ADDR.  */
>   PTRACE_PEEKTEXT = 1,
> #define PT_READ_I PTRACE_PEEKTEXT
> 
> 
> ..which looks pretty normal to me , anybod yhave any clue? 
> Thanks,
> 

Perhaps your toolchain is broken, or perhaps you need to configure
differently.

With my glibc-2.3.3/gcc-3.4.3 toolchain I do:
../gdb-6.6/configure  --target=mipsel-linux --host=mipsel-linux
--build=i686-pc-linux-gnu

Then make and voila! gdb, gdbserver et al. are built.

David Danay

RE: gdbserver

[Ratin Rahman (mratin)]

 
It might be the fact that I am trying to compile gdbsever from the
latest version of gdb with older toolchain. I need an upgraded gcc and
glibc but they are also failing to build. Not sure what order I should
compile them ..

Ratin


-----Original Message-----
From: David Daney [mailto:ddaney@avtrex.com] 
Sent: Thursday, June 28, 2007 2:41 PM
To: Ratin Rahman (mratin)
Cc: linux-mips@linux-mips.org
Subject: Re: gdbserver

Ratin Rahman (mratin) wrote:
> Anybody had luck with compiling gdbserver for mipsel? I am using x86 
> based machine running Fedora 2.6.11 kernel, the target device is IDT 
> 434 running Mipsel 2.6.10 kernel. The gcc crosscompiler is 
> mipsel-linux-gcc and version 3.2.3.
> 
> I did a ./configure --host=mipsel-linux-gnu --target=mipsel-linux-gnu 
> followed by a make. Make failed with the messages:
> 
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:33: syntax 
> error before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:49: syntax 
> error before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:61: syntax 
> error before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:94: syntax 
> error before numeric constant
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h:112: syntax 
> error before numeric constant
> linux-low.c: In function `kill_lwp':
> linux-low.c:760: warning: unused variable `tkill_failed'
> make: *** [linux-low.o] Error 1
> [root@Clearnet gdbserver]# nano
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h
> [root@Clearnet gdbserver]# nano
> /opt/mipseltools/mipsel-linux/sys-include/sys/ptrace.h
> 
> 
> The content of ptrace.h has the enums declared as
> 
> /* Type of the REQUEST argument to `ptrace.'  */ enum __ptrace_request

> {
>   /* Indicate that the process making this request should be traced.
>      All signals received by this process can be intercepted by its
>      parent, and its parent can use the other `ptrace' requests.  */
>   PTRACE_TRACEME = 0,
> <==================================line 33 #define PT_TRACE_ME 
> PTRACE_TRACEME
> 
>   /* Return the word in the process's text space at address ADDR.  */
>   PTRACE_PEEKTEXT = 1,
> #define PT_READ_I PTRACE_PEEKTEXT
> 
> 
> ..which looks pretty normal to me , anybod yhave any clue? 
> Thanks,
> 

Perhaps your toolchain is broken, or perhaps you need to configure
differently.

With my glibc-2.3.3/gcc-3.4.3 toolchain I do:
../gdb-6.6/configure  --target=mipsel-linux --host=mipsel-linux
--build=i686-pc-linux-gnu

Then make and voila! gdb, gdbserver et al. are built.

David Danay

upgrading glibc for mipsel

[Ratin Rahman (mratin)]

[-- Attachment #1: Type: text/plain, Size: 3552 bytes --]

In an effort to build gdbserver, I am trying to upgrade my glibc and gcc cross compile tools. I am  having 
problem while bulding glibc-2.3.3, mipsel compiler version 3.2.3 and current glibc ver
is 2.2.5. 
 
I exported all current cross tools and cross compiler with export. 
 
configured with the options:
../glibc-2.3.3/configure --prefix=/opt/crosstool --build=i686-pc-linux-gnu --host=mipsel-linux --with-binutils=/opt/mipseltools/bin/ --enable-add-ons=linuxthreads
 
did a make and after make went thru for 5 mins or so, it threw this error message: 
I get the following error:
 
 -Wl,-d -Wl,--whole-archive /workspace/ratin/make_glibc/libc_pic.a
/opt/mipseltools/bin/mipsel-linux-gcc -mabi=32   -shared -Wl,-O1 \
  -nostdlib -nostartfiles \
   -Wl,-dynamic-linker=/opt/crosstool/lib/ld.so.1  \
  -Wl,--verbose 2>&1 | \
  sed > /workspace/ratin/make_glibc/shlib.ldsT \
      -e '/^=========/,/^=========/!d;/^=========/d' \
      -e 's/^.*\.hash[  ]*:.*$/  .note.ABI-tag : { *(.note.ABI-tag) } &/' \
      -e 's/^.*\*(\.dynbss).*$/& \
         PROVIDE(__start___libc_freeres_ptrs = .); \
         *(__libc_freeres_ptrs) \
         PROVIDE(__stop___libc_freeres_ptrs = .);/'
mv -f /workspace/ratin/make_glibc/shlib.ldsT /workspace/ratin/make_glibc/shlib.lds
/opt/mipseltools/bin/mipsel-linux-gcc -mabi=32   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,-dynamic-linker=/opt/crosstool/lib/ld.so.1  -B/workspace/ratin/make_glibc/csu/  -Wl,--version-script=/workspace/ratin/make_glibc/libc.map -Wl,-soname=libc.so.6  -nostdlib -nostartfiles -e __libc_main -L/workspace/ratin/make_glibc -L/workspace/ratin/make_glibc/math -L/workspace/ratin/make_glibc/elf -L/workspace/ratin/make_glibc/dlfcn -L/workspace/ratin/make_glibc/nss -L/workspace/ratin/make_glibc/nis -L/workspace/ratin/make_glibc/rt -L/workspace/ratin/make_glibc/resolv -L/workspace/ratin/make_glibc/crypt -L/workspace/ratin/make_glibc/linuxthreads -Wl,-rpath-link=/workspace/ratin/make_glibc:/workspace/ratin/make_glibc/math:/workspace/ratin/make_glibc/elf:/workspace/ratin/make_glibc/dlfcn:/workspace/ratin/make_glibc/nss:/workspace/ratin/make_glibc/nis:/workspace/ratin/make_glibc/rt:/workspace/ratin/make_glibc/resolv:/workspace/ratin/make_glibc/crypt:/workspace/ratin/make_glibc/linuxthreads -o /workspace/ratin/make_glibc/libc.so -T /workspace/ratin/make_glibc/shlib.lds /workspace/ratin/make_glibc/csu/abi-note.o /workspace/ratin/make_glibc/elf/soinit.os /workspace/ratin/make_glibc/libc_pic.os /workspace/ratin/make_glibc/elf/sofini.os /workspace/ratin/make_glibc/elf/interp.os /workspace/ratin/make_glibc/elf/ld.so -lgcc -lgcc_eh
/workspace/ratin/make_glibc/libc_pic.os: In function `__register_atfork':
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d088): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d0b4): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d0e0): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d148): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d164): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d214): more undefined references to `__fork_block' follow
collect2: ld returned 1 exit status
make[1]: *** [/workspace/ratin/make_glibc/libc.so] Error 1
make[1]: Leaving directory `/workspace/ratin/glibc-2.3.3'
make: *** [all] Error 2

 
 
 
I will appreciate any help if you could provide..
Thanks
 
Ratin

[-- Attachment #2: Type: text/html, Size: 5037 bytes --]

upgrading glibc for mipsel

[Ratin Rahman (mratin)]

[-- Attachment #1: Type: text/plain, Size: 3552 bytes --]

In an effort to build gdbserver, I am trying to upgrade my glibc and gcc cross compile tools. I am  having 
problem while bulding glibc-2.3.3, mipsel compiler version 3.2.3 and current glibc ver
is 2.2.5. 
 
I exported all current cross tools and cross compiler with export. 
 
configured with the options:
../glibc-2.3.3/configure --prefix=/opt/crosstool --build=i686-pc-linux-gnu --host=mipsel-linux --with-binutils=/opt/mipseltools/bin/ --enable-add-ons=linuxthreads
 
did a make and after make went thru for 5 mins or so, it threw this error message: 
I get the following error:
 
 -Wl,-d -Wl,--whole-archive /workspace/ratin/make_glibc/libc_pic.a
/opt/mipseltools/bin/mipsel-linux-gcc -mabi=32   -shared -Wl,-O1 \
  -nostdlib -nostartfiles \
   -Wl,-dynamic-linker=/opt/crosstool/lib/ld.so.1  \
  -Wl,--verbose 2>&1 | \
  sed > /workspace/ratin/make_glibc/shlib.ldsT \
      -e '/^=========/,/^=========/!d;/^=========/d' \
      -e 's/^.*\.hash[  ]*:.*$/  .note.ABI-tag : { *(.note.ABI-tag) } &/' \
      -e 's/^.*\*(\.dynbss).*$/& \
         PROVIDE(__start___libc_freeres_ptrs = .); \
         *(__libc_freeres_ptrs) \
         PROVIDE(__stop___libc_freeres_ptrs = .);/'
mv -f /workspace/ratin/make_glibc/shlib.ldsT /workspace/ratin/make_glibc/shlib.lds
/opt/mipseltools/bin/mipsel-linux-gcc -mabi=32   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,-dynamic-linker=/opt/crosstool/lib/ld.so.1  -B/workspace/ratin/make_glibc/csu/  -Wl,--version-script=/workspace/ratin/make_glibc/libc.map -Wl,-soname=libc.so.6  -nostdlib -nostartfiles -e __libc_main -L/workspace/ratin/make_glibc -L/workspace/ratin/make_glibc/math -L/workspace/ratin/make_glibc/elf -L/workspace/ratin/make_glibc/dlfcn -L/workspace/ratin/make_glibc/nss -L/workspace/ratin/make_glibc/nis -L/workspace/ratin/make_glibc/rt -L/workspace/ratin/make_glibc/resolv -L/workspace/ratin/make_glibc/crypt -L/workspace/ratin/make_glibc/linuxthreads -Wl,-rpath-link=/workspace/ratin/make_glibc:/workspace/ratin/make_glibc/math:/workspace/ratin/make_glibc/elf:/workspace/ratin/make_glibc/dlfcn:/workspace/ratin/make_glibc/nss:/workspace/ratin/make_glibc/nis:/workspace/ratin/make_glibc/rt:/workspace/ratin/make_glibc/resolv:/workspace/ratin/make_glibc/crypt:/workspace/ratin/make_glibc/linuxthreads -o /workspace/ratin/make_glibc/libc.so -T /workspace/ratin/make_glibc/shlib.lds /workspace/ratin/make_glibc/csu/abi-note.o /workspace/ratin/make_glibc/elf/soinit.os /workspace/ratin/make_glibc/libc_pic.os /workspace/ratin/make_glibc/elf/sofini.os /workspace/ratin/make_glibc/elf/interp.os /workspace/ratin/make_glibc/elf/ld.so -lgcc -lgcc_eh
/workspace/ratin/make_glibc/libc_pic.os: In function `__register_atfork':
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d088): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d0b4): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d0e0): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d148): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d164): undefined reference to `__fork_block'
/workspace/ratin/make_glibc/libc_pic.os(.text+0x10d214): more undefined references to `__fork_block' follow
collect2: ld returned 1 exit status
make[1]: *** [/workspace/ratin/make_glibc/libc.so] Error 1
make[1]: Leaving directory `/workspace/ratin/glibc-2.3.3'
make: *** [all] Error 2

 
 
 
I will appreciate any help if you could provide..
Thanks
 
Ratin

[-- Attachment #2: Type: text/html, Size: 5037 bytes --]

Re: upgrading glibc for mipsel

[David Daney]

Ratin Rahman (mratin) wrote:
> In an effort to build gdbserver, I am trying to upgrade my glibc and 
> gcc cross compile tools. I am  having
> problem while bulding glibc-2.3.3, mipsel compiler version 3.2.3 and 
> current glibc ver
> is 2.2.5.
>  

Stock glibc-2.3.3 will not work on mipsel-linux.  I posted the patch I 
use few years ago to this list.  You could try with that patch.  Or look 
at the cross-tool project.  Some people have had success using it to 
build toolchains.

David Daney

Re: upgrading glibc for mipsel

[Jason Talley]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

I used crosstool to build gcc3.4.5 w/ glibc 2.3.6, linux-headers 2.6.12, and
linuxthreads 2.3.6

We've been using this for a couple of months and haven't run across any
major issues.
Good luck.

On 6/28/07, David Daney <ddaney@avtrex.com> wrote:
>
> Ratin Rahman (mratin) wrote:
> > In an effort to build gdbserver, I am trying to upgrade my glibc and
> > gcc cross compile tools. I am  having
> > problem while bulding glibc-2.3.3, mipsel compiler version 3.2.3 and
> > current glibc ver
> > is 2.2.5.
> >
>
> Stock glibc-2.3.3 will not work on mipsel-linux.  I posted the patch I
> use few years ago to this list.  You could try with that patch.  Or look
> at the cross-tool project.  Some people have had success using it to
> build toolchains.
>
> David Daney
>
>

[-- Attachment #2: Type: text/html, Size: 1144 bytes --]

gdbserver

[Lanny DeVaney]

I've looked back through the archives and find some references to 
problems configuring and/or building gdbserver for mips-linux.

I'm attempting to build gdb/gdbserver with --target=mips-linux as well, 
using gdb-5.1.1.  Have the earlier issues (they looked to be 1-2 years 
old) been resolved or am I still looking at a "manual build" process? 
 I'm getting lots of errors with the build, although the configure seems 
to go OK.  x86 host, linux-mips target.

Thanks for any help you can provide,
Lanny DeVaney
Red Hat, Inc.

Re: gdbserver

[Johannes Stezenbach]

On Tue, Mar 12, 2002 at 01:22:08PM -0600, Lanny DeVaney wrote:
> I've looked back through the archives and find some references to 
> problems configuring and/or building gdbserver for mips-linux.
> 
> I'm attempting to build gdb/gdbserver with --target=mips-linux as well, 
> using gdb-5.1.1.  Have the earlier issues (they looked to be 1-2 years 
> old) been resolved or am I still looking at a "manual build" process? 
> I'm getting lots of errors with the build, although the configure seems 
> to go OK.  x86 host, linux-mips target.

I tried the gdb+dejagnu-20020305 snapshot recently and
both gdb and gdbserver built without problems. IIRC
gdbserver was still broken in gdb-5.1.1.
I haven't used the newly built gdbserver yet, though.

Regards,
Johannes

Re: gdbserver

[Lanny DeVaney]

Thanks.  I used the 20020311 snapshot and it built like a champ.

Thanks,
Lanny DeVaney
Red Hat, Inc.

Johannes Stezenbach wrote:

>On Tue, Mar 12, 2002 at 01:22:08PM -0600, Lanny DeVaney wrote:
>
>>I've looked back through the archives and find some references to 
>>problems configuring and/or building gdbserver for mips-linux.
>>
>>I'm attempting to build gdb/gdbserver with --target=mips-linux as well, 
>>using gdb-5.1.1.  Have the earlier issues (they looked to be 1-2 years 
>>old) been resolved or am I still looking at a "manual build" process? 
>>I'm getting lots of errors with the build, although the configure seems 
>>to go OK.  x86 host, linux-mips target.
>>
>
>I tried the gdb+dejagnu-20020305 snapshot recently and
>both gdb and gdbserver built without problems. IIRC
>gdbserver was still broken in gdb-5.1.1.
>I haven't used the newly built gdbserver yet, though.
>
>Regards,
>Johannes
>

Re: gdbserver

[Daniel Jacobowitz]

On Tue, Mar 12, 2002 at 01:22:08PM -0600, Lanny DeVaney wrote:
> I've looked back through the archives and find some references to 
> problems configuring and/or building gdbserver for mips-linux.
> 
> I'm attempting to build gdb/gdbserver with --target=mips-linux as well, 
> using gdb-5.1.1.  Have the earlier issues (they looked to be 1-2 years 
> old) been resolved or am I still looking at a "manual build" process? 
> I'm getting lots of errors with the build, although the configure seems 
> to go OK.  x86 host, linux-mips target.
> 
> Thanks for any help you can provide,

As Johannes said, use the current CVS snapshot.  MIPS/Linux support for
gdbserver was only contributed about a month ago.  I'd appreciate bug
reports if it does not work for you, especially as I only tested
little-endian.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver

[Lanny DeVaney]

OK, I'll keep up with it.  I'm doing big-endian.

Lanny DeVaney
Red Hat, Inc.


Daniel Jacobowitz wrote:

>On Tue, Mar 12, 2002 at 01:22:08PM -0600, Lanny DeVaney wrote:
>
>>I've looked back through the archives and find some references to 
>>problems configuring and/or building gdbserver for mips-linux.
>>
>>I'm attempting to build gdb/gdbserver with --target=mips-linux as well, 
>>using gdb-5.1.1.  Have the earlier issues (they looked to be 1-2 years 
>>old) been resolved or am I still looking at a "manual build" process? 
>>I'm getting lots of errors with the build, although the configure seems 
>>to go OK.  x86 host, linux-mips target.
>>
>>Thanks for any help you can provide,
>>
>
>As Johannes said, use the current CVS snapshot.  MIPS/Linux support for
>gdbserver was only contributed about a month ago.  I'd appreciate bug
>reports if it does not work for you, especially as I only tested
>little-endian.
>

gdbserver

[Kristberg Karlsson]

Hello out there.
I've heard about a program for remote debugging called gdbserver.
Does anyone know how to get hold of it.

Agust Karlsson
Pallas Informatik A/S
Allerod Stationsvej 2D
DK-3450 Allerod
DENMARK



Sent með Frípósti frá Vísir.is

gdbserver

[dony]

Hello,

       Now I want to use gdbserver to debug my test app.
      Running "gdbserver :6666 ./mytest" on the target (Powerpc 860)
show a message:
                    Process ./mytest created :pid=8
      But I don't know how to run gdb on the host (X86). The README
doesn't seem to explain
clearly . It says first running "gdb mytest" on the host and then
"target remote mytarget:6666".
But I don't understand something about "gdb mytest" . At this time
should I run a x86 "gdb" or something like "powerpc-linux-gdb"? And the
"mytest"? Is it compiled with x86 gcc or cross-compiled with
"powerpc-linux-gcc"? Really I am very confused at this point:-((
       Do you have any experience to share with me about how to build
and run gdbserver?
Or do you have any other debug tools which can be used in embedded-linux
environment?
        The README for gdbserver is written by Stu Grossman and Fred
Fish.
        Does someone know their email address?
Thank you very much:-)
dony


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdbserver

[Jesper Skov]

>>>>> "dony" == dony  <dony.he@huawei.com.cn> writes:

dony> Hello,

dony>        Now I want to use gdbserver to debug my test app.
dony> Running "gdbserver :6666 ./mytest" on the target (Powerpc 860)
dony> show a message: Process ./mytest created :pid=8 But I don't know
dony> how to run gdb on the host (X86). The README doesn't seem to
dony> explain clearly . It says first running "gdb mytest" on the host
dony> and then "target remote mytarget:6666".  But I don't understand
dony> something about "gdb mytest" . At this time should I run a x86
dony> "gdb" or something like "powerpc-linux-gdb"? And the "mytest"?


mytest is the same executable you run on the target. gdb you run on
the host would be powerpc-linux-gdb (i.e., cross-debugger), thus:

target:> gdbserver :6666 ./mytest

host:> powerpc-linux-gdb mytest
[...]
(gdb) target remote mytarget:6666




dony> Is it compiled with x86 gcc or cross-compiled with
dony> "powerpc-linux-gcc"? Really I am very confused at this point:-((

mytest is compiled with powerpc-linux-gcc.

dony> Do you have any experience to share with me about how to build
dony> and run gdbserver?  Or do you have any other debug tools which
dony> can be used in embedded-linux environment?  The README for
dony> gdbserver is written by Stu Grossman and Fred Fish.  Does
dony> someone know their email address?  Thank you very much:-) dony

Yes I know their email addresses. But you don't want to hassle them
with this. Trust me :)

Jesper

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdbserver

[dony]

Jesper Skov wrote:

> >>>>> "dony" == dony  <dony.he@huawei.com.cn> writes:
>
> dony> Hello,
>
> dony>        Now I want to use gdbserver to debug my test app.
> dony> Running "gdbserver :6666 ./mytest" on the target (Powerpc 860)
> dony> show a message: Process ./mytest created :pid=8 But I don't know
> dony> how to run gdb on the host (X86). The README doesn't seem to
> dony> explain clearly . It says first running "gdb mytest" on the host
> dony> and then "target remote mytarget:6666".  But I don't understand
> dony> something about "gdb mytest" . At this time should I run a x86
> dony> "gdb" or something like "powerpc-linux-gdb"? And the "mytest"?
>
> mytest is the same executable you run on the target. gdb you run on
> the host would be powerpc-linux-gdb (i.e., cross-debugger), thus:
>
> target:> gdbserver :6666 ./mytest
>
> host:> powerpc-linux-gdb mytest
> [...]
> (gdb) target remote mytarget:6666
>
> dony> Is it compiled with x86 gcc or cross-compiled with
> dony> "powerpc-linux-gcc"? Really I am very confused at this point:-((
>
> mytest is compiled with powerpc-linux-gcc.

"powerpc-linux-gdb" is compiled with gcc or powerpc-linux-gcc?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdbserver

[Jesper Skov]

>>>>> "dony" == dony  <dony.he@huawei.com.cn> writes:

dony> Jesper Skov wrote:

>> >>>>> "dony" == dony <dony.he@huawei.com.cn> writes:
>>
dony> Hello,
>>
dony> Now I want to use gdbserver to debug my test app.  Running
dony> "gdbserver :6666 ./mytest" on the target (Powerpc 860) show a
dony> message: Process ./mytest created :pid=8 But I don't know how to
dony> run gdb on the host (X86). The README doesn't seem to explain
dony> clearly . It says first running "gdb mytest" on the host and
dony> then "target remote mytarget:6666".  But I don't understand
dony> something about "gdb mytest" . At this time should I run a x86
dony> "gdb" or something like "powerpc-linux-gdb"? And the "mytest"?
>>  mytest is the same executable you run on the target. gdb you run
>> on the host would be powerpc-linux-gdb (i.e., cross-debugger),
>> thus:
>>
>> target:> gdbserver :6666 ./mytest
>>
>> host:> powerpc-linux-gdb mytest [...]  (gdb) target remote
>> mytarget:6666
>>
dony> Is it compiled with x86 gcc or cross-compiled with
dony> "powerpc-linux-gcc"? Really I am very confused at this point:-((
>>  mytest is compiled with powerpc-linux-gcc.

dony> "powerpc-linux-gdb" is compiled with gcc or powerpc-linux-gcc?

gcc. You should look at one of the FAQ/HOWTO/READMEs/Home pages on the
sucject of embedded development. I think there was posted a small
howto on compiling the components a few days back. Check the archive.


One question: you are using an x86 host, right? If you use a PPC host,
you can just use the preinstalled GDB/GCC when building/debugging the
target binary.


dony>How do you build you powerpc-linux-gdb?
dony>I copy a gdb-4.17.tar.gz from LinuxPPC R4 CD.
dony>When I untar and decompress it, I type the following  under gdb-4.17/gdb
dony>directory:
dony>
dony>	./configure --target=powerpc-linux
dony>	make
dony>
dony>	It fails to compile and say:
dony> make:*** No rule to make target `../bfd/bfd.h`, needed by `blockframe.o`.Stop.
dony>
dony>Yes, there is not bfd.h under gdb-4.17/bfd directory.
dony>Do you know why?
dony>Thank you very much.


I don't know why. It's an old debugger. I think we keep a more recent
version / CVS tree on sourceware.cygnus.com. It may work better. The
howto I mentioned before included links to the archives used, as far
as I remember.

Jesper

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdbserver

[kd]

Hi,

No I did not solve this. I put it on hold for a while since I can still
able to do development on my i386 system.
But soon I  will have to tackle this again since I will have to start
running the firmware on the final target.
Actually I think I might just insert more memory and run the whole gdb on
the target hardware.....

K.D.



dony wrote:


How do you solve all the above problems?
Thank you very much.
dony


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

gdbserver

[kd]

Hi,

I am trying to get gdbserver to run on my mpc823 board. (The precompiled
gdbserver is not working for me, it does not seem to get argc and argv
correctly into main() and always terminates with "usage info".

Using the vanilla gdb-4.18 is of no use, since it has not support for ppc.
Using the gdbserver source that Dan posted here a few weeks back results in
the
the following undefined symbols,
PTRACE_POKEUSR
PTRACE_PEEKUSR
KERNEL_U_ADDR
when compiling low-linux.c
If I define these symbols to 6, 3 and 0 respectively, everything compiles
fine, but the linker fails with the error,
undefined referenve to REGISTER_U_ADDR in function register_addr.

These are defined (for some of the other targets) in directory gdb/config/.
Any idea what is missing?

K.D.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdbserver

[Jim Lewis]

kd@flaga.is wrote:

> Hi,
>
> I am trying to get gdbserver to run on my mpc823 board. (The precompiled
> gdbserver is not working for me, it does not seem to get argc and argv
> correctly into main() and always terminates with "usage info".
>
> Using the vanilla gdb-4.18 is of no use, since it has not support for ppc.
> Using the gdbserver source that Dan posted here a few weeks back results in
> the
> the following undefined symbols,
> PTRACE_POKEUSR

I ran into build problems as well. Apparently, ptrace.h must have changed. The
macros are now called
PTRACE_POKEUSER
PTRACE_PEEKUSER

In my build, KERNEL_U_ADDR is defined in xm.h, which is a link:
xm.h -> ./../config/powerpc/xm-linux.h
#define KERNEL_U_ADDR 0x0


I built gdbserver in a 4.17 tree from the SRC RPM on the LinuxPPC CD.
xm-linux.h in 4.18 does not have that definition.


>
> PTRACE_PEEKUSR
> KERNEL_U_ADDR
> when compiling low-linux.c
> If I define these symbols to 6, 3 and 0 respectively, everything compiles
> fine, but the linker fails with the error,
> undefined referenve to REGISTER_U_ADDR in function register_addr.
>
> These are defined (for some of the other targets) in directory gdb/config/.
> Any idea what is missing?
>
> K.D.

--
Jim Lewis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdbserver

[dony]

kd@flaga.is wrote:

> Hi,
>
> I am trying to get gdbserver to run on my mpc823 board. (The precompiled
> gdbserver is not working for me, it does not seem to get argc and argv
> correctly into main() and always terminates with "usage info".
>
> Using the vanilla gdb-4.18 is of no use, since it has not support for ppc.
> Using the gdbserver source that Dan posted here a few weeks back results in
> the
> the following undefined symbols,
> PTRACE_POKEUSR
> PTRACE_PEEKUSR
> KERNEL_U_ADDR
> when compiling low-linux.c

Now I have the same problem. Have you solved it? I downloaded gdbserver.tar.gz
form Dan's web site and put it in the gdb-4.17 's tree
(gdb-4.17/gdb/gdbserver)which are copied from the SRC RPM on the LinuxPPC CD.

If I enter this directory , then type "make", an error occurs:
    make:***No rule to make target '../config/powerpc/linux.mt',needed by
Makefile.Stop
Yes, ../config/powerpc doesn't have file "linux.mt".I don't how to modify
Makefile.

Also I find that there are three symbol link files nm.h , tm.h and xm.h which
are pointed to nm-linux.h , tm-linux.h, and xm-linux.h in ../config/powerpc
respectively. But nm-linux.h and tm.linux.h don't exist , only xm-linux.h
exists in ../config/powerpc.
How do you solve all the above problems?
Thank you very much.
dony


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/