LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] of_gpio: implement of_get_gpio_flags()
From: Anton Vorontsov @ 2008-07-25 16:48 UTC (permalink / raw)
  To: Trent Piepho; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0807231551230.26456@t2.domain.actdsltmp>

This function is alike to the of_get_gpio(), but accepts new argument:
flags. Now the of_get_gpio() call is a wrapper around of_get_gpio_flags().

This new function will be used by the drivers that need to retrive GPIO
information, such as active-low flag.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---

On Wed, Jul 23, 2008 at 04:42:24PM -0700, Trent Piepho wrote:
> On Wed, 23 Jul 2008, Anton Vorontsov wrote:
> > On Mon, Jul 21, 2008 at 02:12:20PM -0700, Trent Piepho wrote:
> >> On Mon, 21 Jul 2008, Anton Vorontsov wrote:
> >>> On Sat, Jul 19, 2008 at 02:08:01PM -0700, Trent Piepho wrote:
> >>>> It doesn't look like you have any way to unset the active low flag.  What if
> >>>> I unload the leds-gpio driver (or another gpio user) and then try to use the
> >>>> gpio with something else?  The active low flag is stuck on!
> >>>
> >>> Why would you want to unset the flags? It is specified in the device
> >>> tree, and can't be changed. Specifying different flags for the same GPIO
> >>> would be an error (plus, Linux forbids shared gpios, so you simply can't
> >>> specify one gpio for several devices).
> >>
> >> You can't use the same gpio for two different things at the same time, but you
> >> can load a driver, unload it, and then load another.
> >
> > Hm.. yeah, this might happen. Now I tend to think that transparent
> > active-low handling wasn't that good idea after all. So, something like
> > of_gpio_is_active_low(device_node, gpioidx) should be implemented
> > instead. This function will parse the gpio's = <> flags. Please speak up
> > if you have any better ideas though.
> 
> The flags could be provided via of_get_gpio.  E.g., something like
> of_get_gpio(...., u32 *flags), and if flags is non-NULL the gpio flags are
> left there.  of_get_gpio already has the flags and some other of_get_*
> functions return multiple things like this.

Good idea, thanks. This patch implements of_get_gpio_flags() in addition
to of_get_gpio() (since we don't want to break existing users).

The name seems a bit unfortunate though, because one could read the
function as it gets gpio flags only (though, we might implement
this instead, but this way average driver will end up with parsing
gpios = <> twice).

of_get_gpio_wflags() would be better. Or maybe leave it as is, since
it is documented anyway. ;-)

> Or just have an active low property for the led:
>  	led.active_low = !!of_get_property(np, "active-low", NULL);
> 
> Pretty simple, just one line of code.  At least if one looks just at
> leds-gpio, that's obviously the simplest way.  Is active low a property of
> the led or a property of the gpio?  I guess one could argue either way.

As I said previously, I'm not against this as a temporary solution.
Because we can always deprecate the active-low property later, in a
backward compatible way.

See http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055202.html

So, assuming that the of_get_gpio_flags() will appear only in 2.6.28,
I'm fine with explicit active-low property for now.

> It seems like putting one line of code leds-gpio driver is better than
> putting much more complex code into the gpio controller driver.  And each
> gpio controller has to have that code too.
> 
> Now you could say that each gpio user needing to support inverting gpios is
> a lot of code too,
[...]

Quite the reverse, actually. ;-) I tend to agree. With this patch
every gpio controller will able to parse flags, w/o single line
added. So this approach is obviously better.

Plus, with transparent active-low handling, most drivers will end up
with checking active-low twice, because most drivers are doing if
(active_low) already.

Thanks.

 drivers/of/gpio.c       |   35 ++++++++++++++++++++++++++++-------
 include/linux/of_gpio.h |   38 ++++++++++++++++++++++++++++++++++----
 2 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 1c9cab8..5be67dd 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -19,14 +19,16 @@
 #include <asm/prom.h>
 
 /**
- * of_get_gpio - Get a GPIO number from the device tree to use with GPIO API
+ * of_get_gpio - Get a GPIO number and flags to use with GPIO API
  * @np:		device node to get GPIO from
  * @index:	index of the GPIO
+ * @flags:	a flags pointer to fill in
  *
  * Returns GPIO number to use with Linux generic GPIO API, or one of the errno
- * value on the error condition.
+ * value on the error condition. This function also will fill in the flags.
  */
-int of_get_gpio(struct device_node *np, int index)
+int of_get_gpio_flags(struct device_node *np, int index,
+		      enum of_gpio_flags *flags)
 {
 	int ret = -EINVAL;
 	struct device_node *gc;
@@ -102,7 +104,11 @@ int of_get_gpio(struct device_node *np, int index)
 		goto err0;
 	}
 
-	ret = of_gc->xlate(of_gc, np, gpio_spec);
+	/* .xlate might decide to not fill in the flags, so clear it here */
+	if (flags)
+		*flags = 0;
+
+	ret = of_gc->xlate(of_gc, np, gpio_spec, flags);
 	if (ret < 0)
 		goto err1;
 
@@ -113,26 +119,41 @@ err0:
 	pr_debug("%s exited with status %d\n", __func__, ret);
 	return ret;
 }
-EXPORT_SYMBOL(of_get_gpio);
+EXPORT_SYMBOL(of_get_gpio_flags);
 
 /**
- * of_gpio_simple_xlate - translate gpio_spec to the GPIO number
+ * of_gpio_simple_xlate - translate gpio_spec to the GPIO number and flags
  * @of_gc:	pointer to the of_gpio_chip structure
  * @np:		device node of the GPIO chip
  * @gpio_spec:	gpio specifier as found in the device tree
+ * @flags:	a flags pointer to fill in
  *
  * This is simple translation function, suitable for the most 1:1 mapped
  * gpio chips. This function performs only one sanity check: whether gpio
  * is less than ngpios (that is specified in the gpio_chip).
  */
 int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
-			 const void *gpio_spec)
+			 const void *gpio_spec, enum of_gpio_flags *flags)
 {
 	const u32 *gpio = gpio_spec;
 
+	/*
+	 * We're discouraging gpio_cells < 2, since this way you'll have to
+	 * write your own xlate function, which will retrive the GPIO number
+	 * and its flags from a single gpio cell. This is possible, but not
+	 * recommended.
+	 */
+	if (of_gc->gpio_cells < 2) {
+		WARN_ON(1);
+		return -EINVAL;
+	}
+
 	if (*gpio > of_gc->gc.ngpio)
 		return -EINVAL;
 
+	if (flags)
+		*flags = gpio[1];
+
 	return *gpio;
 }
 EXPORT_SYMBOL(of_gpio_simple_xlate);
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index 67db101..8dc9bcb 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -14,19 +14,32 @@
 #ifndef __LINUX_OF_GPIO_H
 #define __LINUX_OF_GPIO_H
 
+#include <linux/compiler.h>
+#include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/gpio.h>
 
+struct device_node;
+
 #ifdef CONFIG_OF_GPIO
 
 /*
+ * This is Linux-specific flags. By default controllers' and Linux' mapping
+ * match, but GPIO controllers are free to translate their own flags to
+ * Linux-specific in their .xlate callback. Though, 1:1 mapping is recommended.
+ */
+enum of_gpio_flags {
+	OF_GPIO_ACTIVE_LOW = 0x1,
+};
+
+/*
  * Generic OF GPIO chip
  */
 struct of_gpio_chip {
 	struct gpio_chip gc;
 	int gpio_cells;
 	int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
-		     const void *gpio_spec);
+		     const void *gpio_spec, enum of_gpio_flags *flags);
 };
 
 static inline struct of_gpio_chip *to_of_gpio_chip(struct gpio_chip *gc)
@@ -50,20 +63,37 @@ static inline struct of_mm_gpio_chip *to_of_mm_gpio_chip(struct gpio_chip *gc)
 	return container_of(of_gc, struct of_mm_gpio_chip, of_gc);
 }
 
-extern int of_get_gpio(struct device_node *np, int index);
+extern int of_get_gpio_flags(struct device_node *np, int index,
+			     enum of_gpio_flags *flags);
+
 extern int of_mm_gpiochip_add(struct device_node *np,
 			      struct of_mm_gpio_chip *mm_gc);
 extern int of_gpio_simple_xlate(struct of_gpio_chip *of_gc,
 				struct device_node *np,
-				const void *gpio_spec);
+				const void *gpio_spec,
+				enum of_gpio_flags *flags);
 #else
 
 /* Drivers may not strictly depend on the GPIO support, so let them link. */
-static inline int of_get_gpio(struct device_node *np, int index)
+static inline int of_get_gpio_flags(struct device_node *np, int index,
+				    enum of_gpio_flags *flags)
 {
 	return -ENOSYS;
 }
 
 #endif /* CONFIG_OF_GPIO */
 
+/**
+ * of_get_gpio - Get a GPIO number to use with GPIO API
+ * @np:		device node to get GPIO from
+ * @index:	index of the GPIO
+ *
+ * Returns GPIO number to use with Linux generic GPIO API, or one of the errno
+ * value on the error condition.
+ */
+static inline int of_get_gpio(struct device_node *np, int index)
+{
+	return of_get_gpio_flags(np, index, NULL);
+}
+
 #endif /* __LINUX_OF_GPIO_H */
-- 
1.5.5.4

^ permalink raw reply related

* Re: [PATCH v3 1/4] of: adapt of_find_i2c_driver() to be usable by SPI also
From: Grant Likely @ 2008-07-25 16:21 UTC (permalink / raw)
  To: Jon Smirl; +Cc: spi-devel-general, akpm, dbrownell, linux-kernel, linuxppc-dev
In-Reply-To: <9e4733910807250840n48c6ae79l27af4f320b5b1df1@mail.gmail.com>

On Fri, Jul 25, 2008 at 11:40 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 7/25/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>>  + * At the moment, a single table is used for all bus types because it is
>>  + * assumed that the data size is small and that the compatible values
>>  + * should already be distinct enough to differentiate between SPI, I2C
>>  + * and other devices.
>
> Maybe add a section recommending to update the alias list in the linux
> device driver before adding entries here? This table should be a last
> resort. I'm not even sure this table should exist, what would be a
> case where we would need to make an entry here instead of fixing the
> device driver by adding an alias name?

In principle I agree.  However, this patch is simply porting the i2c
specific code to something that can be used by both SPI and I2C.  I
don't want to rework the actual mechanism in this particular patch.  I
can submit an additional patch to change this along with reworking
some of the behavior that needs to be improved.

>>  + * First method is to lookup the compatible value in of_modalias_table.
>>  + * Second is to look for a "linux,<modalias>" entry in the compatible list
>>  + * and used that for modalias.  Third is to strip off the manufacturer
>>  + * prefix from the first compatible entry and use the remainder as modalias
>
> I also think this is a problem. Embedding the name of Linux device
> drivers into device firmware makes it almost impossible to rename the
> device driver.  Again, what is a case where generic part numbers can't
> be listed in the alias section of the linux device driver?
>
> Even eeprom was just fixed to take generic part numbers (at24).

Again, I agree, but this change is very much a stop gap measure to get
things working in a sane way without having to create bad device tree
bindings (device tree bindings are hard to change, code is not).  I've
been considering posting a patch to remove this clause from the
functions, but that needs to be reviewed separately from this change.

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Timur Tabi @ 2008-07-25 16:19 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Scott Wood, Linuxppc-dev
In-Reply-To: <4889EFFE.2070201@grandegger.com>

Wolfgang Grandegger wrote:

> I know but we still need an algorithm for MPC52xx and MPC82xx as well.

That's true, but I still think hard-coding values of DFSR and FDR in the device
tree is not a good way to do this.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* Re: [PATCH v3 1/4] of: adapt of_find_i2c_driver() to be usable by SPI also
From: Jon Smirl @ 2008-07-25 15:40 UTC (permalink / raw)
  To: Grant Likely
  Cc: spi-devel-general, akpm, dbrownell, linux-kernel, linuxppc-dev
In-Reply-To: <20080725073311.8485.16226.stgit@trillian.secretlab.ca>

On 7/25/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
>  SPI has a similar problem as I2C in that it needs to determine an
>  appropriate modalias value for each device node.  This patch adapts
>  the of_i2c of_find_i2c_driver() function to be usable by of_spi also.
>
>  Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>  ---
>
>   drivers/of/base.c   |   88 +++++++++++++++++++++++++++++++++++++++++++++++++++
>   drivers/of/of_i2c.c |   64 ++-----------------------------------
>   include/linux/of.h  |    1 +
>   3 files changed, 92 insertions(+), 61 deletions(-)
>
>  diff --git a/drivers/of/base.c b/drivers/of/base.c
>  index 23ffb7c..ad8ac1a 100644
>  --- a/drivers/of/base.c
>  +++ b/drivers/of/base.c
>  @@ -385,3 +385,91 @@ struct device_node *of_find_matching_node(struct device_node *from,
>         return np;
>   }
>   EXPORT_SYMBOL(of_find_matching_node);
>  +
>  +/**
>  + * of_modalias_table: Table of explicit compatible ==> modalias mappings
>  + *
>  + * This table allows particulare compatible property values to be mapped
>  + * to modalias strings.  This is useful for busses which do not directly
>  + * understand the OF device tree but are populated based on data contained
>  + * within the device tree.  SPI and I2C are the two current users of this
>  + * table.
>  + *
>  + * In most cases, devices do not need to be listed in this table because
>  + * the modalias value can be derived directly from the compatible table.
>  + * However, if for any reason a value cannot be derived, then this table
>  + * provides a method to override the implicit derivation.
>  + *
>  + * At the moment, a single table is used for all bus types because it is
>  + * assumed that the data size is small and that the compatible values
>  + * should already be distinct enough to differentiate between SPI, I2C
>  + * and other devices.

Maybe add a section recommending to update the alias list in the linux
device driver before adding entries here? This table should be a last
resort. I'm not even sure this table should exist, what would be a
case where we would need to make an entry here instead of fixing the
device driver by adding an alias name?

The list of alias part numbers really belong in the devices drivers,
not some global table that has to always be kept in memory.

>  + */
>  +struct of_modalias_table {
>  +       char *of_device;
>  +       char *modalias;
>  +};
>  +static struct of_modalias_table of_modalias_table[] = {
>  +       /* Empty for now; add entries as needed */
>  +};
>  +
>  +/**
>  + * of_modalias_node - Lookup appropriate modalias for a device node
>  + * @node:      pointer to a device tree node
>  + * @modalias:  Pointer to buffer that modalias value will be copied into
>  + * @len:       Length of modalias value
>  + *
>  + * Based on the value of the compatible property, this routine will determine
>  + * an appropriate modalias value for a particular device tree node.  Three
>  + * separate methods are used to derive a modalias value.
>  + *
>  + * First method is to lookup the compatible value in of_modalias_table.
>  + * Second is to look for a "linux,<modalias>" entry in the compatible list
>  + * and used that for modalias.  Third is to strip off the manufacturer
>  + * prefix from the first compatible entry and use the remainder as modalias

I also think this is a problem. Embedding the name of Linux device
drivers into device firmware makes it almost impossible to rename the
device driver.  Again, what is a case where generic part numbers can't
be listed in the alias section of the linux device driver?

Even eeprom was just fixed to take generic part numbers (at24).

>  + *
>  + * This routine returns 0 on success
>  + */
>  +int of_modalias_node(struct device_node *node, char *modalias, int len)
>  +{
>  +       int i, cplen;
>  +       const char *compatible;
>  +       const char *p;
>  +
>  +       /* 1. search for exception list entry */
>  +       for (i = 0; i < ARRAY_SIZE(of_modalias_table); i++) {
>  +               compatible = of_modalias_table[i].of_device;
>  +               if (!of_device_is_compatible(node, compatible))
>  +                       continue;
>  +               strlcpy(modalias, of_modalias_table[i].modalias, len);
>  +               return 0;
>  +       }
>  +
>  +       compatible = of_get_property(node, "compatible", &cplen);
>  +       if (!compatible)
>  +               return -ENODEV;
>  +
>  +       /* 2. search for linux,<modalias> entry */
>  +       p = compatible;
>  +       while (cplen > 0) {
>  +               if (!strncmp(p, "linux,", 6)) {
>  +                       p += 6;
>  +                       strlcpy(modalias, p, len);
>  +                       return 0;
>  +               }
>  +
>  +               i = strlen(p) + 1;
>  +               p += i;
>  +               cplen -= i;
>  +       }
>  +
>  +       /* 3. take first compatible entry and strip manufacturer */
>  +       p = strchr(compatible, ',');
>  +       if (!p)
>  +               return -ENODEV;
>  +       p++;
>  +       strlcpy(modalias, p, len);
>  +       return 0;
>  +}
>  +EXPORT_SYMBOL_GPL(of_modalias_node);
>  +
>  diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
>  index 344e1b0..6a98dc8 100644
>  --- a/drivers/of/of_i2c.c
>  +++ b/drivers/of/of_i2c.c
>  @@ -16,62 +16,6 @@
>   #include <linux/of_i2c.h>
>   #include <linux/module.h>
>
>  -struct i2c_driver_device {
>  -       char    *of_device;
>  -       char    *i2c_type;
>  -};
>  -
>  -static struct i2c_driver_device i2c_devices[] = {
>  -};
>  -
>  -static int of_find_i2c_driver(struct device_node *node,
>  -                             struct i2c_board_info *info)
>  -{
>  -       int i, cplen;
>  -       const char *compatible;
>  -       const char *p;
>  -
>  -       /* 1. search for exception list entry */
>  -       for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
>  -               if (!of_device_is_compatible(node, i2c_devices[i].of_device))
>  -                       continue;
>  -               if (strlcpy(info->type, i2c_devices[i].i2c_type,
>  -                           I2C_NAME_SIZE) >= I2C_NAME_SIZE)
>  -                       return -ENOMEM;
>  -
>  -               return 0;
>  -       }
>  -
>  -       compatible = of_get_property(node, "compatible", &cplen);
>  -       if (!compatible)
>  -               return -ENODEV;
>  -
>  -       /* 2. search for linux,<i2c-type> entry */
>  -       p = compatible;
>  -       while (cplen > 0) {
>  -               if (!strncmp(p, "linux,", 6)) {
>  -                       p += 6;
>  -                       if (strlcpy(info->type, p,
>  -                                   I2C_NAME_SIZE) >= I2C_NAME_SIZE)
>  -                               return -ENOMEM;
>  -                       return 0;
>  -               }
>  -
>  -               i = strlen(p) + 1;
>  -               p += i;
>  -               cplen -= i;
>  -       }
>  -
>  -       /* 3. take fist compatible entry and strip manufacturer */
>  -       p = strchr(compatible, ',');
>  -       if (!p)
>  -               return -ENODEV;
>  -       p++;
>  -       if (strlcpy(info->type, p, I2C_NAME_SIZE) >= I2C_NAME_SIZE)
>  -               return -ENOMEM;
>  -       return 0;
>  -}
>  -
>   void of_register_i2c_devices(struct i2c_adapter *adap,
>                              struct device_node *adap_node)
>   {
>  @@ -83,6 +27,9 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
>                 const u32 *addr;
>                 int len;
>
>  +               if (of_modalias_node(node, info.type, sizeof(info.type)) < 0)
>  +                       continue;
>  +
>                 addr = of_get_property(node, "reg", &len);
>                 if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
>                         printk(KERN_ERR
>  @@ -92,11 +39,6 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
>
>                 info.irq = irq_of_parse_and_map(node, 0);
>
>  -               if (of_find_i2c_driver(node, &info) < 0) {
>  -                       irq_dispose_mapping(info.irq);
>  -                       continue;
>  -               }
>  -
>                 info.addr = *addr;
>
>                 request_module(info.type);
>  diff --git a/include/linux/of.h b/include/linux/of.h
>  index 59a61bd..79886ad 100644
>  --- a/include/linux/of.h
>  +++ b/include/linux/of.h
>  @@ -70,5 +70,6 @@ extern int of_n_addr_cells(struct device_node *np);
>   extern int of_n_size_cells(struct device_node *np);
>   extern const struct of_device_id *of_match_node(
>         const struct of_device_id *matches, const struct device_node *node);
>  +extern int of_modalias_node(struct device_node *node, char *modalias, int len);
>
>   #endif /* _LINUX_OF_H */
>
>
>  --
>  To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [PATCH] powerpc: 85xx: add proper OF bus ids for the TQM85xx
From: Wolfgang Grandegger @ 2008-07-25 15:37 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: Linuxppc-dev
In-Reply-To: <4889F180.80203@freescale.com>

Jon Loeliger wrote:
> Wolfgang Grandegger wrote:
> 
>> Ah, I see. For the TQM8548 adding the following compatible line:
>>
>>         soc8548@e0000000 {
>>         ...
>>         compatible = "fsl,mpc8548-immr", "simple-bus";
>>
> 
> 
> Hmmmm..... While you are there, I think you should drop
> the "8548" part of "soc8548" to get just "soc@e0000000".

Well, right. I'm going to check the tqm8548.dts file more carefully.

Wolfgang.

^ permalink raw reply

* Re: [RFC] 4xx hardware watchpoint support
From: Kumar Gala @ 2008-07-25 15:22 UTC (permalink / raw)
  To: luisgpm; +Cc: ppc-dev, Christoph Hellwig, Paul Mackerras
In-Reply-To: <1216829442.5727.97.camel@gargoyle>


On Jul 23, 2008, at 11:10 AM, Luis Machado wrote:

> On Wed, 2008-07-23 at 11:53 -0400, Josh Boyer wrote:
>> Shouldn't this (and other places) be:
>>
>> #if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
>>
>> if you are going to exclude 40x for now?  Otherwise this is still
>> enabled on 405 and setting the wrong register.
>>
>> josh
>
> Yes, sorry. I wasn't aware of this specific define value. It makes
> things easier to support 405's later.
>
> Like so?
>
> This addresses Christoph's comments as well.
>
>
> Signed-off-by: Luis Machado <luisgpm@br.ibm.com>
>
> Index: linux-2.6.26/arch/powerpc/kernel/entry_32.S
> ===================================================================
> --- linux-2.6.26.orig/arch/powerpc/kernel/entry_32.S	2008-07-23  
> 07:44:57.000000000 -0700
> +++ linux-2.6.26/arch/powerpc/kernel/entry_32.S	2008-07-23  
> 07:50:31.000000000 -0700
> @@ -148,7 +148,7 @@
> 	/* Check to see if the dbcr0 register is set up to debug.  Use the
> 	   internal debug mode bit to do this. */
> 	lwz	r12,THREAD_DBCR0(r12)
> -	andis.	r12,r12,DBCR0_IDM@h
> +	andis.	r12,r12,(DBCR0_IDM  | DBSR_DAC1R | DBSR_DAC1W)@h

why the change here?  Is IDM not always on in this case for 44x?
>
> 	beq+	3f
> 	/* From user and task is ptraced - load up global dbcr0 */
> 	li	r12,-1			/* clear all pending debug events */
> @@ -292,7 +292,7 @@
> 	/* If the process has its own DBCR0 value, load it up.  The internal
> 	   debug mode bit tells us that dbcr0 should be loaded. */
> 	lwz	r0,THREAD+THREAD_DBCR0(r2)
> -	andis.	r10,r0,DBCR0_IDM@h
> +	andis.	r10,r0,(DBCR0_IDM  | DBSR_DAC1R | DBSR_DAC1W)@h
> 	bnel-	load_dbcr0
> #endif
> #ifdef CONFIG_44x
> @@ -720,7 +720,7 @@
> 	/* Check whether this process has its own DBCR0 value.  The internal
> 	   debug mode bit tells us that dbcr0 should be loaded. */
> 	lwz	r0,THREAD+THREAD_DBCR0(r2)
> -	andis.	r10,r0,DBCR0_IDM@h
> +	andis.	r10,r0,(DBCR0_IDM  | DBSR_DAC1R | DBSR_DAC1W)@h
> 	bnel-	load_dbcr0
> #endif
>
> Index: linux-2.6.26/arch/powerpc/kernel/process.c
> ===================================================================
> --- linux-2.6.26.orig/arch/powerpc/kernel/process.c	2008-07-23  
> 07:44:57.000000000 -0700
> +++ linux-2.6.26/arch/powerpc/kernel/process.c	2008-07-23  
> 07:50:31.000000000 -0700
> @@ -47,6 +47,8 @@
> #ifdef CONFIG_PPC64
> #include <asm/firmware.h>
> #endif
> +#include <linux/kprobes.h>
> +#include <linux/kdebug.h>
>
> extern unsigned long _get_SP(void);
>
> @@ -239,6 +241,35 @@
> }
> #endif /* CONFIG_SMP */
>
> +void do_dabr(struct pt_regs *regs, unsigned long address,
> +		    unsigned long error_code)
> +{
> +	siginfo_t info;
> +
> +	if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
> +			11, SIGSEGV) == NOTIFY_STOP)
> +		return;
> +
> +	if (debugger_dabr_match(regs))
> +		return;
> +
> +	/* Clear the DAC and struct entries.  One shot trigger */
> +#if (defined(CONFIG_44x) || defined(CONFIG_BOOKE))

this is redundant.  CONFIG_BOOKE is sufficient.

>
> +	mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R | DBSR_DAC1W
> +							| DBCR0_IDM));
> +#endif
> +
> +	/* Clear the DABR */
> +	set_dabr(0);
> +
> +	/* Deliver the signal to userspace */
> +	info.si_signo = SIGTRAP;
> +	info.si_errno = 0;
> +	info.si_code = TRAP_HWBKPT;
> +	info.si_addr = (void __user *)address;
> +	force_sig_info(SIGTRAP, &info, current);
> +}
> +
> static DEFINE_PER_CPU(unsigned long, current_dabr);
>
> int set_dabr(unsigned long dabr)
> @@ -254,6 +285,11 @@
> #if defined(CONFIG_PPC64) || defined(CONFIG_6xx)
> 	mtspr(SPRN_DABR, dabr);
> #endif
> +
> +#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)

ditto.

>
> +	mtspr(SPRN_DAC1, dabr);
> +#endif
> +
> 	return 0;
> }
>
> @@ -337,6 +373,12 @@
> 	if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
> 		set_dabr(new->thread.dabr);
>
> +#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
> +	/* If new thread DAC (HW breakpoint) is the same then leave it */
> +	if (new->thread.dabr)
> +		set_dabr(new->thread.dabr);
> +#endif
> +
> 	new_thread = &new->thread;
> 	old_thread = &current->thread;
>
> @@ -525,6 +567,10 @@
> 	if (current->thread.dabr) {
> 		current->thread.dabr = 0;
> 		set_dabr(0);
> +
> +#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
> +		current->thread.dbcr0 &= ~(DBSR_DAC1R | DBSR_DAC1W);
> +#endif
> 	}
> }
>
> Index: linux-2.6.26/arch/powerpc/kernel/ptrace.c
> ===================================================================
> --- linux-2.6.26.orig/arch/powerpc/kernel/ptrace.c	2008-07-23  
> 07:44:57.000000000 -0700
> +++ linux-2.6.26/arch/powerpc/kernel/ptrace.c	2008-07-23  
> 07:53:45.000000000 -0700
> @@ -703,7 +703,7 @@
>
> 	if (regs != NULL) {
> #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> -		task->thread.dbcr0 = DBCR0_IDM | DBCR0_IC;
> +		task->thread.dbcr0 |= DBCR0_IDM | DBCR0_IC;
> 		regs->msr |= MSR_DE;
> #else
> 		regs->msr |= MSR_SE;
> @@ -716,9 +716,16 @@
> {
> 	struct pt_regs *regs = task->thread.regs;
>
> +
> +#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
> +	/* If DAC then do not single step, skip */
> +	if (task->thread.dabr)
> +		return;
> +#endif
> +
> 	if (regs != NULL) {
> #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> -		task->thread.dbcr0 = 0;
> +		task->thread.dbcr0 &= ~(DBCR0_IC | DBCR0_IDM);
> 		regs->msr &= ~MSR_DE;
> #else
> 		regs->msr &= ~MSR_SE;
> @@ -727,22 +734,75 @@
> 	clear_tsk_thread_flag(task, TIF_SINGLESTEP);
> }
>
> -static int ptrace_set_debugreg(struct task_struct *task, unsigned  
> long addr,
> +int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
> 			       unsigned long data)
> {
> -	/* We only support one DABR and no IABRS at the moment */
> +	/* For ppc64 we support one DABR and no IABR's at the moment  
> (ppc64).
> +	 *  For embedded processors we support one DAC and no IAC's at the
> +	 *  moment.
> +	 */
> 	if (addr > 0)
> 		return -EINVAL;
>
> -	/* The bottom 3 bits are flags */

fix the comment, don't remove it.

>
> 	if ((data & ~0x7UL) >= TASK_SIZE)
> 		return -EIO;
>
> -	/* Ensure translation is on */
> +#ifdef CONFIG_PPC64

make this ifndef CONFIG_BOOKE, its not PPC64 specific.

>
> +
> +	/* For processors using DABR (i.e. 970), the bottom 3 bits are  
> flags.
> +	 *  It was assumed, on previous implementations, that 3 bits were
> +	 *  passed together with the data address, fitting the design of the
> +	 *  DABR register, as follows:
> +	 *
> +	 *  bit 0: Read flag
> +	 *  bit 1: Write flag
> +	 *  bit 2: Breakpoint translation
> +	 *
> +	 *  Thus, we use them here as so.
> +	 */
> +
> +	/* Ensure breakpoint translation bit is set */
> 	if (data && !(data & DABR_TRANSLATION))
> 		return -EIO;
>
> +	/* Move contents to the DABR register */
> 	task->thread.dabr = data;
> +
> +#endif
> +#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)

see comment above.
>
> +
> +	/* As described above, it was assumed 3 bits were passed with the  
> data
> +	 *  address, but we will assume only the mode bits will be passed
> +	 *  as to not cause alignment restrictions for DAC-based processors.
> +	 */
> +
> +	/* DAC's hold the whole address without any mode flags */
> +	task->thread.dabr = data & ~0x3UL;
> +
> +	if (task->thread.dabr == 0) {
> +		task->thread.dbcr0 &= ~(DBSR_DAC1R | DBSR_DAC1W | DBCR0_IDM);
> +		task->thread.regs->msr &= ~MSR_DE;
> +		return 0;
> +	}
> +
> +	/* Read or Write bits must be set */
> +
> +	if (!(data & 0x3UL))
> +		return -EINVAL;
> +
> +	/* Set the Internal Debugging flag (IDM bit 1) for the DBCR0
> +	   register */
> +	task->thread.dbcr0 = DBCR0_IDM;
> +
> +	/* Check for write and read flags and set DBCR0
> +	   accordingly */
> +	if (data & 0x1UL)
> +		task->thread.dbcr0 |= DBSR_DAC1R;
> +	if (data & 0x2UL)
> +		task->thread.dbcr0 |= DBSR_DAC1W;
> +
> +	task->thread.regs->msr |= MSR_DE;
> +#endif
> 	return 0;
> }
>
> Index: linux-2.6.26/arch/powerpc/kernel/signal.c
> ===================================================================
> --- linux-2.6.26.orig/arch/powerpc/kernel/signal.c	2008-07-23  
> 07:44:57.000000000 -0700
> +++ linux-2.6.26/arch/powerpc/kernel/signal.c	2008-07-23  
> 07:50:31.000000000 -0700
> @@ -145,8 +145,12 @@
> 	 * user space. The DABR will have been cleared if it
> 	 * triggered inside the kernel.
> 	 */
> -	if (current->thread.dabr)
> +	if (current->thread.dabr) {
> 		set_dabr(current->thread.dabr);
> +#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)

see comment above
>
> +		mtspr(SPRN_DBCR0, current->thread.dbcr0);
> +#endif
> +	}
>
> 	if (is32) {
>         	if (ka.sa.sa_flags & SA_SIGINFO)
> Index: linux-2.6.26/arch/powerpc/kernel/traps.c
> ===================================================================
> --- linux-2.6.26.orig/arch/powerpc/kernel/traps.c	2008-07-23  
> 07:44:57.000000000 -0700
> +++ linux-2.6.26/arch/powerpc/kernel/traps.c	2008-07-23  
> 07:50:31.000000000 -0700
> @@ -1067,6 +1067,22 @@
> 		}
>
> 		_exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
> +	} else if (debug_status & (DBSR_DAC1R | DBSR_DAC1W)) {
> +		regs->msr &= ~MSR_DE;
> +
> +		if (user_mode(regs)) {
> +			current->thread.dbcr0 &= ~(DBSR_DAC1R | DBSR_DAC1W |
> +								DBCR0_IDM);
> +		} else {
> +			/* Disable DAC interupts */
> +			mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R |
> +						DBSR_DAC1W | DBCR0_IDM));
> +
> +			/* Clear the DAC event */
> +			mtspr(SPRN_DBSR, (DBSR_DAC1R | DBSR_DAC1W));
> +		}
> +		/* Setup and send the trap to the handler */
> +		do_dabr(regs, mfspr(SPRN_DAC1), debug_status);
> 	}
> }
> #endif /* CONFIG_4xx || CONFIG_BOOKE */
> Index: linux-2.6.26/arch/powerpc/mm/fault.c
> ===================================================================
> --- linux-2.6.26.orig/arch/powerpc/mm/fault.c	2008-07-23  
> 07:44:57.000000000 -0700
> +++ linux-2.6.26/arch/powerpc/mm/fault.c	2008-07-23  
> 07:50:31.000000000 -0700
> @@ -100,31 +100,6 @@
> 	return 0;
> }
>
> -#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
> -static void do_dabr(struct pt_regs *regs, unsigned long address,
> -		    unsigned long error_code)
> -{
> -	siginfo_t info;
> -
> -	if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
> -			11, SIGSEGV) == NOTIFY_STOP)
> -		return;
> -
> -	if (debugger_dabr_match(regs))
> -		return;
> -
> -	/* Clear the DABR */
> -	set_dabr(0);
> -
> -	/* Deliver the signal to userspace */
> -	info.si_signo = SIGTRAP;
> -	info.si_errno = 0;
> -	info.si_code = TRAP_HWBKPT;
> -	info.si_addr = (void __user *)address;
> -	force_sig_info(SIGTRAP, &info, current);
> -}
> -#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
> -
> /*
>  * For 600- and 800-family processors, the error_code parameter is  
> DSISR
>  * for a data fault, SRR1 for an instruction fault. For 400-family  
> processors
> Index: linux-2.6.26/include/asm-powerpc/system.h
> ===================================================================
> --- linux-2.6.26.orig/include/asm-powerpc/system.h	2008-07-23  
> 07:44:57.000000000 -0700
> +++ linux-2.6.26/include/asm-powerpc/system.h	2008-07-23  
> 07:50:31.000000000 -0700
> @@ -110,6 +110,8 @@
> #endif
>
> extern int set_dabr(unsigned long dabr);
> +extern void do_dabr(struct pt_regs *regs, unsigned long address,
> +		    unsigned long error_code);
> extern void print_backtrace(unsigned long *);
> extern void show_regs(struct pt_regs * regs);
> extern void flush_instruction_cache(void);
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Wolfgang Grandegger @ 2008-07-25 15:34 UTC (permalink / raw)
  To: Grant Likely; +Cc: Scott Wood, Linuxppc-dev
In-Reply-To: <fa686aa40807250612g34b5167dtbe70c810f30a5d32@mail.gmail.com>

Grant Likely wrote:
> On Fri, Jul 25, 2008 at 5:04 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Jochen Friedrich wrote:
>>> Hi Wolfgang,
>>>
>>>> The I2C driver for the MPC currently uses a fixed speed hard-coded into
>>>> the driver. This patch adds the FDT properties "fdr" and "dfsrr" for the
>>>> corresponding I2C registers to make the speed configurable via FDT, e.g.:
>>>>
>>>>    i2c@3100 {
>>>>        compatible = "fsl-i2c";
>>>>        reg = <0x3100 0x100>;
>>>>        interrupts = <43 2>;
>>>>        interrupt-parent = <&mpic>;
>>>>        dfsrr = <0x20>;
>>>>        fdr = <0x03>;
>>>>    };
>>>
>>> Would it be possible to use the standard property "clock-frequency" for
>>> this
>>> and calculate the register settings in the driver?
> 
> Yes, please use something like clock-frequency or current-speed and do
> the calculation.
> 
>> Almost everything is possible in software, just for what price ;-). U-Boot
>> has some code in drivers/i2c/fsl_i2c.c to determine reasonable fdr and dfsrr
>> values for the MPC83/5/6xx boards. For the MPC82xx and MPC85xx it's even
>> more sophisticated.
>>
>> I was also thinking to just overtake the U-Boot settings if fdt and dfsrr is
>> not defined for the I2C node (instead of the debatable default values).
> 
> This is a perfectly valid option.  Personally, I'd prefer it encoded
> in the device tree, but if it looks like a valid speed has already
> been programmed in then I'm cool with the driver just preserving that.
>  If it turns out to causes problems the we can always change the code
> to be more conservative later.

How should the Linux driver decide if the registers have been already 
set by the boot-loader? The reset-values might be good as well. 
Therefore, if "clock-frequency" is not specified, the driver may simply 
not touch the fdr and dfsr registers (overtaking the values from the 
boot-loader).

What do you think.

Wolfgang.

^ permalink raw reply

* Re: [PATCH] powerpc: 85xx: add proper OF bus ids for the TQM85xx
From: Jon Loeliger @ 2008-07-25 15:30 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Linuxppc-dev
In-Reply-To: <4889EE4C.9040705@grandegger.com>

Wolfgang Grandegger wrote:

> Ah, I see. For the TQM8548 adding the following compatible line:
> 
>         soc8548@e0000000 {
>         ...
>         compatible = "fsl,mpc8548-immr", "simple-bus";
> 


Hmmmm..... While you are there, I think you should drop
the "8548" part of "soc8548" to get just "soc@e0000000".

Thanks,
jdl

^ permalink raw reply

* Re: [RFC] 4xx hardware watchpoint support
From: Kumar Gala @ 2008-07-25 15:23 UTC (permalink / raw)
  To: benh; +Cc: ppc-dev, Paul Mackerras, Christoph Hellwig
In-Reply-To: <1216958433.11188.70.camel@pasglop>


On Jul 24, 2008, at 11:00 PM, Benjamin Herrenschmidt wrote:

> On Wed, 2008-07-23 at 13:10 -0300, Luis Machado wrote:
>> On Wed, 2008-07-23 at 11:53 -0400, Josh Boyer wrote:
>>> Shouldn't this (and other places) be:
>>>
>>> #if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
>>>
>>> if you are going to exclude 40x for now?  Otherwise this is still
>>> enabled on 405 and setting the wrong register.
>>>
>>> josh
>>
>> Yes, sorry. I wasn't aware of this specific define value. It makes
>> things easier to support 405's later.
>>
>> Like so?
>
> Please, next time, when you re-send a patch like that, re-include
> the full subject and patch description. You can add then blurbs after
> the --- line if you want to add things that won't make it to git.
>
> I'll deal with that specific one for now.

Ben,  I want to make sure this works on FSL Book-E before it gets into  
tree and I need to think about what SMP issues it might have.

I talked to Josh about this at OLS and if you are ok I can deal with  
acceptance of this patch via my tree.

- k

^ permalink raw reply

* Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Wolfgang Grandegger @ 2008-07-25 15:23 UTC (permalink / raw)
  To: Timur Tabi; +Cc: Scott Wood, Linuxppc-dev
In-Reply-To: <ed82fe3e0807250721n115d28c7ha1f641c9175c473d@mail.gmail.com>

Timur Tabi wrote:
> On Fri, Jul 25, 2008 at 8:12 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> 
>> Yes, please use something like clock-frequency or current-speed and do
>> the calculation.
> 
> Ditto.  I already wrote the code that does that for U-Boot, so all you
> need to do is port it.

I know but we still need an algorithm for MPC52xx and MPC82xx as well.

> Although I'm curious, if U-Boot already programs the speed, why does
> the driver program it again?

Maybe because it's not obvious for the driver if the registers have 
already been configured by the boot-loader.

Wolfgang.

^ permalink raw reply

* Re: [PATCH] powerpc: 85xx: add proper OF bus ids for the TQM85xx
From: Wolfgang Grandegger @ 2008-07-25 15:16 UTC (permalink / raw)
  To: Grant Likely; +Cc: Linuxppc-dev
In-Reply-To: <fa686aa40807250620r1ab574basd07ecce6be2bc238@mail.gmail.com>

Grant Likely wrote:
> On Fri, Jul 25, 2008 at 3:44 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Since recent modifications to the MPC I2C code, the MPC I2C buses are not
>> found any more. This patch fixes the problem by adding proper OF
>> bus ids.
>>
>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>> ---
>> arch/powerpc/platforms/85xx/tqm85xx.c |    6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> Index: linux-2.6-galak/arch/powerpc/platforms/85xx/tqm85xx.c
>> ===================================================================
>> --- linux-2.6-galak.orig/arch/powerpc/platforms/85xx/tqm85xx.c
>> +++ linux-2.6-galak/arch/powerpc/platforms/85xx/tqm85xx.c
>> @@ -156,15 +156,15 @@ static void tqm85xx_show_cpuinfo(struct }
>>
>> static struct of_device_id __initdata of_bus_ids[] = {
>> +       { .type = "soc", },
>> +       { .compatible = "soc", },
>>        { .compatible = "simple-bus", },
> 
> Ugh, i assume this is to support older .dts files that don't have
> simple-bus in their compatible property?  Please put them at the end
> of the list and put a comment ahead of them stating that they are
> legacy support.  You should also state in the comment which boards or
> dts files these entries provide support for.

Ah, I see. For the TQM8548 adding the following compatible line:

         soc8548@e0000000 {
		...
		compatible = "fsl,mpc8548-immr", "simple-bus"; 


solved my issues. All other DTS files for the TQM85xx modules have this 
line. It got lost somehow for the TQM8548. Thanks for pointing me to the 
real problem. Forget this patch, I will send a new one fixing the DTS file.

Wolfgang.

^ permalink raw reply

* Re: [git pull] Please pull from powerpc.git merge branch
From: Kumar Gala @ 2008-07-25 15:07 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <1216973590.11188.99.camel@pasglop>


On Jul 25, 2008, at 3:13 AM, Benjamin Herrenschmidt wrote:

>
> Benjamin Herrenschmidt (1):
>      Move update_mmu_cache() declaration from tlbflush.h to pgtable.h

I'm guessing this was pretty trivial, but please post patches to the  
list even if you've committed them to your tree.

- k

^ permalink raw reply

* Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Jon Smirl @ 2008-07-25 15:04 UTC (permalink / raw)
  To: Timur Tabi, Wolfgang Grandegger; +Cc: Scott Wood, Linuxppc-dev
In-Reply-To: <ed82fe3e0807250721n115d28c7ha1f641c9175c473d@mail.gmail.com>

On 7/25/08, Timur Tabi <timur@freescale.com> wrote:
> On Fri, Jul 25, 2008 at 8:12 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>
>  > Yes, please use something like clock-frequency or current-speed and do
>  > the calculation.
>
> Ditto.  I already wrote the code that does that for U-Boot, so all you
>  need to do is port it.

I calculate the register values in the i2s driver. There is the issue
of requesting a frequency the hardware can't make exactly (Freescale -
more FractionalN dividers please!).

	if (dir == SND_SOC_CLOCK_OUT) {
		psc_i2s->sysclk = freq;
		if (clk_id == MPC52xx_CLK_CELLSLAVE) {
			psc_i2s->sicr |= MPC52xx_PSC_SICR_CELLSLAVE | MPC52xx_PSC_SICR_GENCLK;
		} else { /* MPC52xx_CLK_INTERNAL */
			psc_i2s->sicr &= ~MPC52xx_PSC_SICR_CELLSLAVE;
			psc_i2s->sicr |= MPC52xx_PSC_SICR_GENCLK;

			clkdiv = ppc_proc_freq / freq;
			err = ppc_proc_freq % freq;
			if (err > freq / 2)
				clkdiv++;

			dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(clkdiv %d freq error=%ldHz)\n",
					clkdiv, (ppc_proc_freq / clkdiv - freq));
				
			return mpc52xx_set_psc_clkdiv(psc_i2s->dai.id + 1, clkdiv);
		}
	}

	if (psc_i2s->sysclk) {
		framesync = bits * 2;
		bitclk = (psc_i2s->sysclk) / (params_rate(params) * framesync);
		
		/* bitclk field is byte swapped due to mpc5200/b compatibility */
		value = ((framesync - 1) << 24) |
			(((bitclk - 1) & 0xFF) << 16) | ((bitclk - 1) & 0xFF00);
		
		dev_dbg(psc_i2s->dev, "%s(substream=%p) rate=%i sysclk=%i"
			" framesync=%i bitclk=%i reg=%X\n",
			__FUNCTION__, substream, params_rate(params), psc_i2s->sysclk,
			framesync, bitclk, value);
		
		out_be32(&psc_i2s->psc_regs->ccr, value);
		out_8(&psc_i2s->psc_regs->ctur, bits - 1);
	}

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [PATCH v3 0/4 REPOST] OF infrastructure for SPI devices
From: Jon Smirl @ 2008-07-25 14:46 UTC (permalink / raw)
  To: Grant Likely
  Cc: spi-devel-general, akpm, dbrownell, linux-kernel, linuxppc-dev
In-Reply-To: <20080725072549.8485.90723.stgit@trillian.secretlab.ca>

On 7/25/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> I don't know what to do with these patches.  I'd really like to see them
>  in .27, and now that akpm has cleared his queue, the prerequisite patch
>  has been merged so they are ready to go in.  However, even though there
>  has been favourable reception on the SPI and linuxppc lists for these
>  changes I don't have any acks from anybody yet.

I have compatible hardware but it has an MMC card socket hooked up. I
haven't figured out yet how to get this driver hooked to the MMC
subsystem and make the file system on the card work.  (I've been
working on ALSA).

I believe I need this:
http://lkml.org/lkml/2008/6/5/209

Then I need to get everything hooked together. Point me in the right
direction and I can help with testing.


>
>  David, can you please reply on if you are okay with these patches
>  getting merged?  If so, do you want me to merge them via my tree, or
>  do you want to pick them up?
>
>  Thanks,
>  g.
>
>  --
>  Grant Likely, B.Sc. P.Eng.
>  Secret Lab Technologies Ltd.
>
> --
>  To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Timur Tabi @ 2008-07-25 14:21 UTC (permalink / raw)
  To: Grant Likely; +Cc: Scott Wood, Linuxppc-dev
In-Reply-To: <fa686aa40807250612g34b5167dtbe70c810f30a5d32@mail.gmail.com>

On Fri, Jul 25, 2008 at 8:12 AM, Grant Likely <grant.likely@secretlab.ca> wrote:

> Yes, please use something like clock-frequency or current-speed and do
> the calculation.

Ditto.  I already wrote the code that does that for U-Boot, so all you
need to do is port it.

Although I'm curious, if U-Boot already programs the speed, why does
the driver program it again?

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* Re: [PATCH / RFC] net: don't grab a mutex within a timer context in gianfar
From: Nate Case @ 2008-07-25 14:16 UTC (permalink / raw)
  To: Sebastian Siewior
  Cc: netdev, linuxppc-dev, Vitaly Bordug, Li Yang, Jeff Garzik
In-Reply-To: <20080723200337.GA5122@Chamillionaire.breakpoint.cc>

On Wed, 2008-07-23 at 22:03 +0200, Sebastian Siewior wrote:
> I moved it into a workqueue, this is what tg3 does.
> I would convert the other three drivers unless $dude suggests a better
> method or somebody else takes care....
> 
>  drivers/net/gianfar.c |   22 ++++++++++++++++++----
>  drivers/net/gianfar.h |    2 ++
>  2 files changed, 20 insertions(+), 4 deletions(-)

This looks good to me.

-- 
Nate Case <ncase@xes-inc.com>

^ permalink raw reply

* Re: [PATCH] powerpc: 85xx: add proper OF bus ids for the TQM85xx
From: Grant Likely @ 2008-07-25 13:20 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Linuxppc-dev
In-Reply-To: <48898470.80109@grandegger.com>

On Fri, Jul 25, 2008 at 3:44 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Since recent modifications to the MPC I2C code, the MPC I2C buses are not
> found any more. This patch fixes the problem by adding proper OF
> bus ids.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
> arch/powerpc/platforms/85xx/tqm85xx.c |    6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-2.6-galak/arch/powerpc/platforms/85xx/tqm85xx.c
> ===================================================================
> --- linux-2.6-galak.orig/arch/powerpc/platforms/85xx/tqm85xx.c
> +++ linux-2.6-galak/arch/powerpc/platforms/85xx/tqm85xx.c
> @@ -156,15 +156,15 @@ static void tqm85xx_show_cpuinfo(struct }
>
> static struct of_device_id __initdata of_bus_ids[] = {
> +       { .type = "soc", },
> +       { .compatible = "soc", },
>        { .compatible = "simple-bus", },

Ugh, i assume this is to support older .dts files that don't have
simple-bus in their compatible property?  Please put them at the end
of the list and put a comment ahead of them stating that they are
legacy support.  You should also state in the comment which boards or
dts files these entries provide support for.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Grant Likely @ 2008-07-25 13:12 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Scott Wood, Linuxppc-dev
In-Reply-To: <48899736.8020400@grandegger.com>

On Fri, Jul 25, 2008 at 5:04 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Jochen Friedrich wrote:
>>
>> Hi Wolfgang,
>>
>>> The I2C driver for the MPC currently uses a fixed speed hard-coded into
>>> the driver. This patch adds the FDT properties "fdr" and "dfsrr" for the
>>> corresponding I2C registers to make the speed configurable via FDT, e.g.:
>>>
>>>    i2c@3100 {
>>>        compatible = "fsl-i2c";
>>>        reg = <0x3100 0x100>;
>>>        interrupts = <43 2>;
>>>        interrupt-parent = <&mpic>;
>>>        dfsrr = <0x20>;
>>>        fdr = <0x03>;
>>>    };
>>
>>
>> Would it be possible to use the standard property "clock-frequency" for
>> this
>> and calculate the register settings in the driver?

Yes, please use something like clock-frequency or current-speed and do
the calculation.

> Almost everything is possible in software, just for what price ;-). U-Boot
> has some code in drivers/i2c/fsl_i2c.c to determine reasonable fdr and dfsrr
> values for the MPC83/5/6xx boards. For the MPC82xx and MPC85xx it's even
> more sophisticated.
>
> I was also thinking to just overtake the U-Boot settings if fdt and dfsrr is
> not defined for the I2C node (instead of the debatable default values).

This is a perfectly valid option.  Personally, I'd prefer it encoded
in the device tree, but if it looks like a valid speed has already
been programmed in then I'm cool with the driver just preserving that.
 If it turns out to causes problems the we can always change the code
to be more conservative later.

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [spi-devel-general] [spi][mpc52xx][PATCH] Fix mpc52xx_psc_spi master driver
From: Grant Likely @ 2008-07-25 13:06 UTC (permalink / raw)
  To: Luotao Fu; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20080725114341.GB6415@pengutronix.de>

On Fri, Jul 25, 2008 at 7:43 AM, Luotao Fu <l.fu@pengutronix.de> wrote:
> Hi,
>
> this is a fix for full duplex transfer mode on the mpc52xx_psc_spi driver.
> Details see the patch header. Tested on a mpc5200b board.
>
> Cheers
> Luotao fu

Looks pretty good to me.  I'll pick this up.

For future patches, please send patches inline and not as attachments.
 Attachments mess up the workflow because I cannot comment on the
patch by just hitting 'reply' and it doesn't work with git-am.

g.
-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: lockdep badness
From: Sebastien Dugue @ 2008-07-25 12:59 UTC (permalink / raw)
  To: Nathan Lynch; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080724192300.GE9594@localdomain>


  Hi,

On Thu, 24 Jul 2008 14:23:00 -0500 Nathan Lynch <ntl@pobox.com> wrote:

> I'm seeing warnings from the lockdep code itself in recent kernels on
> a Power6 blade (v2.6.26 and benh's -next branch).
> 
> Something to do with powerpc's "lazy" interrupt-disabling, perhaps?
> 
> A couple of stack traces below, the first is from benh's tree, the
> second is from 2.6.26.  The lockdep self-tests all pass at boot.
> 
> RTAS daemon started
> RTAS: event: 295, Type: Dump Notification Event, Severity: 2
> ------------[ cut here ]------------
> Badness at kernel/lockdep.c:2719

<snip>

  I'm observing nearly the same thing (minus the ipr related badness) here with
Ben's powerpc.git (master) on a JS22 blade:

Freeing initrd memory: 2676k freed
RTAS daemon started
RTAS: event: 94, Type: Platform Information Event, Severity: 1
------------[ cut here ]------------
Badness at kernel/lockdep.c:2079
NIP: c0000000000846dc LR: c0000000000846c0 CTR: 0000000000000000
REGS: c0000001e353f9c0 TRAP: 0700   Not tainted  (2.6.26)
MSR: 8000000000029032 <EE,ME,IR,DR>  CR: 24000042  XER: 20000010
TASK = c0000000efa58640[115] 'rtasd' THREAD: c0000001e353c000 CPU: 3
GPR00: 0000000000000000 c0000001e353fc40 c0000000004efe50 0000000000000001 
GPR04: 0000000000000001 c00000000003cc94 0000000000000001 636820202d203230 
GPR08: 3465303000000000 c0000000009627a8 c0000000efa58e88 0000000000000001 
GPR12: 3465303038200d0a c000000000525900 c000000000395ba0 4000000000c00000 
GPR16: c0000000003943c8 0000000000000000 000000000029d000 000000000101c920 
GPR20: 0000000000000000 0000000000000001 0000000000000744 0000000000000001 
GPR24: c000000000538cf0 c0000001e3e74000 c00000000041b48c c0000000004c0060 
GPR28: c0000000000847a4 c0000000efa58640 c0000000004b18d0 c0000001e353fc40 
NIP [c0000000000846dc] .trace_hardirqs_on_caller+0xc4/0x170
LR [c0000000000846c0] .trace_hardirqs_on_caller+0xa8/0x170
Call Trace:
[c0000001e353fcd0] [c0000000000847a4] .trace_hardirqs_on+0x1c/0x30
[c0000001e353fd50] [c0000000002df554] ._spin_unlock_irqrestore+0x68/0xb8
[c0000001e353fde0] [c00000000003cc94] .pSeries_log_error+0x3a4/0x400
[c0000001e353fef0] [c00000000003cf28] .rtasd+0x98/0x100
[c0000001e353ff90] [c0000000000295f8] .kernel_thread+0x4c/0x68
Instruction dump:
901d07ec 880d01ca 2fa00000 41be002c 481300a1 60000000 2fa30000 419e00a0 
e93e80f8 80090000 2f800000 409e0090 <0fe00000> 48000088 e92d01a0 8009082c 
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 15071
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)

 ...


  Sebastien.

^ permalink raw reply

* [spi][mpc52xx][PATCH] Fix mpc52xx_psc_spi master driver
From: Luotao Fu @ 2008-07-25 11:43 UTC (permalink / raw)
  To: spi-devel-general, linuxppc-dev


[-- Attachment #1.1: Type: text/plain, Size: 334 bytes --]

Hi,

this is a fix for full duplex transfer mode on the mpc52xx_psc_spi driver.
Details see the patch header. Tested on a mpc5200b board.

Cheers
Luotao fu
-- 
   Dipl.-Ing. Luotao Fu | Phone: +49-5121-206917-3
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de


[-- Attachment #1.2: mpc52xx_psc_spi_fix_block_send.diff --]
[-- Type: text/x-diff, Size: 1946 bytes --]

From: Luotao Fu <l.fu@pengutronix.de>
Subject: fix block transfer on mpc52xx psc spi

  The block transfer routine in the mpc52xx psc spi driver misinterpret the
  datasheet. According to the processor datasheet the chipselect is held as
  long as the EOF is not written. Theoretically block of any sizes can be
  transferd in this way. The old routine however writes an EOF after every
  word, which has the size of size_of_word. This makes the transfer slow.
  Also fixed some duplicate code.

Signed-off-by: Luotao Fu <l.fu@pengutronix.de>

---
 drivers/spi/mpc52xx_psc_spi.c |   22 +++++++---------------
 1 file changed, 7 insertions(+), 15 deletions(-)

Index: drivers/spi/mpc52xx_psc_spi.c
===================================================================
--- a/drivers/spi/mpc52xx_psc_spi.c.orig
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -146,7 +146,6 @@ static int mpc52xx_psc_spi_transfer_rxtx
 	unsigned rfalarm;
 	unsigned send_at_once = MPC52xx_PSC_BUFSIZE;
 	unsigned recv_at_once;
-	unsigned bpw = mps->bits_per_word / 8;
 
 	if (!t->tx_buf && !t->rx_buf && t->len)
 		return -EINVAL;
@@ -162,22 +161,15 @@ static int mpc52xx_psc_spi_transfer_rxtx
 		}
 
 		dev_dbg(&spi->dev, "send %d bytes...\n", send_at_once);
-		if (tx_buf) {
-			for (; send_at_once; sb++, send_at_once--) {
-				/* set EOF flag */
-				if (mps->bits_per_word
-						&& (sb + 1) % bpw == 0)
-					out_8(&psc->ircr2, 0x01);
+		for (; send_at_once; sb++, send_at_once--) {
+			/* set EOF flag before the last word is sent */
+			if (send_at_once == 1)
+				out_8(&psc->ircr2, 0x01);
+
+			if (tx_buf)
 				out_8(&psc->mpc52xx_psc_buffer_8, tx_buf[sb]);
-			}
-		} else {
-			for (; send_at_once; sb++, send_at_once--) {
-				/* set EOF flag */
-				if (mps->bits_per_word
-						&& ((sb + 1) % bpw) == 0)
-					out_8(&psc->ircr2, 0x01);
+			else
 				out_8(&psc->mpc52xx_psc_buffer_8, 0);
-			}
 		}
 
 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* RE: Xilinx Linux 2.6 for XPS LL_TEMAC and LL_FIFO problem
From: Mirek23 @ 2008-07-25 11:22 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20080724132453.C8F1010F0077@mail56-dub.bigfish.com>


Hi John and Mike,

Thank you for your reply. We have modified out FPGA design and now we have
LL_TEMAC with LL_DMA component connected instead of the LL_FIFO. Before
building linux kernel we have tried to build the u-boot (downloaded from the
xilinx-git tree).

It was relatively easy to build u-boot which has the ll_temac with ll_dma
support.

next we have tried to run u-boot on our ppc (virtex-4 FX12). All went fine
till the moment to establish the communication with the network.

I put some debug messages to the xilinx ll_dma and ll_temac drivers and we
have found that u-boot hangs 
during dma initialisation:

more specifically in the function calls :
       XLlDma_Initialize(XLlDma * InstancePtr, u32 BaseAddress) 
               XLlDma_Reset(XLlDma * InstancePtr) 
                         XLlDma_mBdRingSnapShotCurrBd(TxRingPtr);

Do you have any idea what could be wrong with dma initialization?

Best Regards

Mirek

 

-- 
View this message in context: http://www.nabble.com/Compile-time-error%2C-compiling-Xilinx-Linux-2.6-for-XPS-LLTEMAC-tp16065692p18649823.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Re: DTS configuration of external interrupts on 8347
From: Wang Jian @ 2008-07-25 10:15 UTC (permalink / raw)
  To: richw; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <48889A5B.5030200@btconnect.com>

Richard Whitlock wrote:
> Sean MacLennan wrote:
>> On Wed, 23 Jul 2008 15:58:38 +0100
>> "Richard Whitlock" <richard.whitlo@btconnect.com> wrote:
>>
>>  
>>> I have a small problem with a port of linux 2.6.26 to a custom board.
>>> Our board is almost identical to the Analogue & Micro asp 8347 board,
>>> so I'm using Kumar Gala's excellent fsl tree (thank you Kumar) as it 
>>> already has a defconfig for the asp.
>>> Thanks also to Bryan O'Donoghue for pointing us in the direction of
>>> the asp port in the first place.
>>>
>>> The problem we have is I am unable to request an external interrupt.
>>> We have an FPGA which has an interrupt line - HW IRQ_0, so thats
>>> linux IRQ 48. I have added the following to the dts file:
>>>
>>> fpgaKFAF@0xF8000000 {
>>>                 interrupts = <48 8>;
>>>                 interrupt-parent = <&ipic>;
>>> }
>>>
>>> but whenever I call request_irq() it returns -ENOSYS.
>>>
>>> The driver loads fine, and the open function does very little - a
>>> call to ioremap() - which works, and a call to request_irq() which
>>> does not. Is there anything else I have to do to configure this
>>> interrupt?
>>>     
>>
>> I don't think you have enough information in the dts. We do the same
>> thing on the warp (you can look at the warp.dts):
>>
>> fpga@2,0 {
>>     compatible = "pika,fpga";
>>     reg = <0x00000002 0x00000000 0x00001000>;
>>     interrupts = <0x18 0x8>;
>>     interrupt-parent = <&UIC0>;
>> };
>>
>> You need the compatible, maybe "kfaf,fpga", and I believe the reg entry
>> although you could try without it.
>>
>> You then can use:
>>
>>     of_find_compatible_node
>>     irq_of_parse_and_map
>>     request_irq
>>
>> platforms/44x/warp.c shows an example using the ad7414. Just change the
>> ad7414 string to your compatible string.
>>
>> Cheers,
>>    Sean
>>
>>
>>
>>   
> Sean,
> 
> Thanks for that - our original code had no call to irq_of_parse_and_map().
> We've put that in, as well as a call to of_find_compatible_node(), and 
> now everything works fine. We have also modified our dts file along the 
> lines you suggested.
> Cheers,
> 

The docs on OF/DTS are very poor in this specific area. For starters, 
it's naturally assumed that after linking the drivers in and adding 
device nodes to device tree source file, all is done. But that is NOT 
enough, espeicially for non-bus device drivers. Sometime, you must add 
init code to search device tree nodes you are interested, add device 
objects for them.

I see a bunch of patches on dts documentation are pending for 2.6.27. 
Wish this area will be improved.

^ permalink raw reply

* Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Wolfgang Grandegger @ 2008-07-25  9:04 UTC (permalink / raw)
  To: Jochen Friedrich; +Cc: Scott Wood, Linuxppc-dev
In-Reply-To: <4889942C.4040800@scram.de>

Jochen Friedrich wrote:
> Hi Wolfgang,
> 
>> The I2C driver for the MPC currently uses a fixed speed hard-coded into
>> the driver. This patch adds the FDT properties "fdr" and "dfsrr" for the
>> corresponding I2C registers to make the speed configurable via FDT, 
>> e.g.:
>>
>>     i2c@3100 {
>>         compatible = "fsl-i2c";
>>         reg = <0x3100 0x100>;
>>         interrupts = <43 2>;
>>         interrupt-parent = <&mpic>;
>>         dfsrr = <0x20>;
>>         fdr = <0x03>;
>>     };
> 
> 
> Would it be possible to use the standard property "clock-frequency" for this
> and calculate the register settings in the driver?

Almost everything is possible in software, just for what price ;-). 
U-Boot has some code in drivers/i2c/fsl_i2c.c to determine reasonable 
fdr and dfsrr values for the MPC83/5/6xx boards. For the MPC82xx and 
MPC85xx it's even more sophisticated.

I was also thinking to just overtake the U-Boot settings if fdt and 
dfsrr is not defined for the I2C node (instead of the debatable default 
values).

Wolfgang.

^ permalink raw reply

* Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Jochen Friedrich @ 2008-07-25  8:51 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Scott Wood, Linuxppc-dev
In-Reply-To: <488982B5.4070102@grandegger.com>

Hi Wolfgang,

> The I2C driver for the MPC currently uses a fixed speed hard-coded into
> the driver. This patch adds the FDT properties "fdr" and "dfsrr" for the
> corresponding I2C registers to make the speed configurable via FDT, 
> e.g.:
> 
>     i2c@3100 {
>         compatible = "fsl-i2c";
>         reg = <0x3100 0x100>;
>         interrupts = <43 2>;
>         interrupt-parent = <&mpic>;
>         dfsrr = <0x20>;
>         fdr = <0x03>;
>     };


Would it be possible to use the standard property "clock-frequency" for this
and calculate the register settings in the driver?

Thanks,
Jochen

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox