* Re: [PATCH 2/3] i2c-mpc: add support for the MPC512x processors from Freescale
From: Wolfgang Grandegger @ 2010-01-25 18:33 UTC (permalink / raw)
To: Wolfram Sang
Cc: Devicetree-discuss, Linuxppc-dev, Linux-i2c, Wolfgang Grandegger
In-Reply-To: <20100125151509.GD5257@pengutronix.de>
Wolfram Sang wrote:
>>>>
>>>> -static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
>>>> - struct mpc_i2c *i2c,
>>>> - u32 clock, u32 prescaler)
>>>> +static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
>>>> + struct mpc_i2c *i2c,
>>>> + u32 clock, u32 prescaler)
>>>> {
>>>> int ret, fdr;
>>>>
>>>> + if (clock == -1) {
>>> Could we use 0 for 'no_clock'? This would make the above statement simply
>> "0" is already used to maintain backward compatibility setting a safe
>> divider.
>
> Ah, now I see:
>
> 'clock == -1' means 'preserve clocks' (and is checked here in mpc_i2c_setup_52xx())
Yes, this is now necessary because "setup" does not just do clock settings.
> 'clock == 0' means 'safe divider' (and is checked in mpc_i2c_get_fdr_52xx())
This is for compatibility with old DTS files and last time it was tricky
to get that right and therefore...
> This is not a beauty ;)
>
> What about adding a flags variable to the setup-functions?
.. I hesitate to make bigger changes to the code flow, which the
introduction of a flags variable would required. Also it seems to be
overkill to me. I will have a closer look, though. At a minimum I will
replace "-1" with "MPC_I2C_PRESERVE_CLOCK".
Wolfgang.
^ permalink raw reply
* [PATCH 4/4] powerpc/mcu_mpc8349emitx: Remove OF GPIO handling stuff
From: Anton Vorontsov @ 2010-01-25 18:11 UTC (permalink / raw)
To: Grant Likely, David Brownell
Cc: Bill Gatliff, Dmitry Eremin-Solenikov, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <20100125180957.GA5380@oksana.dev.rtsoft.ru>
With the new OF GPIO infrastructure it's much easier to handle I2C
GPIO controllers, i.e. now drivers don't have to deal with the
OF-specific bits.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 68 +++++-------------------
1 files changed, 14 insertions(+), 54 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index 73c7e6b..5525175 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -18,8 +18,6 @@
#include <linux/mutex.h>
#include <linux/i2c.h>
#include <linux/gpio.h>
-#include <linux/of.h>
-#include <linux/of_gpio.h>
#include <asm/prom.h>
#include <asm/machdep.h>
@@ -36,7 +34,7 @@ struct mcu {
struct mutex lock;
struct device_node *np;
struct i2c_client *client;
- struct of_gpio_chip of_gc;
+ struct gpio_chip gc;
u8 reg_ctrl;
};
@@ -55,8 +53,7 @@ static void mcu_power_off(void)
static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
{
- struct of_gpio_chip *of_gc = to_of_gpio_chip(gc);
- struct mcu *mcu = container_of(of_gc, struct mcu, of_gc);
+ struct mcu *mcu = container_of(gc, struct mcu, gc);
u8 bit = 1 << (4 + gpio);
mutex_lock(&mcu->lock);
@@ -75,53 +72,6 @@ static int mcu_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
return 0;
}
-static int mcu_gpiochip_add(struct mcu *mcu)
-{
- struct device_node *np;
- struct of_gpio_chip *of_gc = &mcu->of_gc;
- struct gpio_chip *gc = &of_gc->gc;
- int ret;
-
- np = of_find_compatible_node(NULL, NULL, "fsl,mcu-mpc8349emitx");
- if (!np)
- return -ENODEV;
-
- gc->owner = THIS_MODULE;
- gc->label = np->full_name;
- gc->can_sleep = 1;
- gc->ngpio = MCU_NUM_GPIO;
- gc->base = -1;
- gc->set = mcu_gpio_set;
- gc->direction_output = mcu_gpio_dir_out;
- of_gc->chip = gc;
- of_gc->gpio_cells = 2;
- of_gc->xlate = of_gpio_simple_xlate;
-
- np->data = of_gc;
- mcu->np = np;
-
- /*
- * We don't want to lose the node, its ->data and ->full_name...
- * So, if succeeded, we don't put the node here.
- */
- ret = gpiochip_add(gc);
- if (ret)
- of_node_put(np);
- return ret;
-}
-
-static int mcu_gpiochip_remove(struct mcu *mcu)
-{
- int ret;
-
- ret = gpiochip_remove(&mcu->of_gc.gc);
- if (ret)
- return ret;
- of_node_put(mcu->np);
-
- return 0;
-}
-
static int __devinit mcu_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -141,7 +91,16 @@ static int __devinit mcu_probe(struct i2c_client *client,
goto err;
mcu->reg_ctrl = ret;
- ret = mcu_gpiochip_add(mcu);
+ mcu->gc.dev = &client->dev;
+ mcu->gc.owner = THIS_MODULE;
+ mcu->gc.label = dev_name(&client->dev);
+ mcu->gc.can_sleep = 1;
+ mcu->gc.ngpio = MCU_NUM_GPIO;
+ mcu->gc.base = -1;
+ mcu->gc.set = mcu_gpio_set;
+ mcu->gc.direction_output = mcu_gpio_dir_out;
+
+ ret = gpiochip_add(&mcu->gc);
if (ret)
goto err;
@@ -168,9 +127,10 @@ static int __devexit mcu_remove(struct i2c_client *client)
glob_mcu = NULL;
}
- ret = mcu_gpiochip_remove(mcu);
+ ret = gpiochip_remove(&mcu->gc);
if (ret)
return ret;
+
i2c_set_clientdata(client, NULL);
kfree(mcu);
return 0;
--
1.6.5.7
^ permalink raw reply related
* [PATCH 3/4] of/gpio: Implement GPIOLIB notifier hooks
From: Anton Vorontsov @ 2010-01-25 18:11 UTC (permalink / raw)
To: Grant Likely, David Brownell
Cc: Bill Gatliff, Dmitry Eremin-Solenikov, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <20100125180957.GA5380@oksana.dev.rtsoft.ru>
This patch implements GPIOLIB notifier hooks, and thus makes device-enabled
GPIO chips (i.e. the ones that have gpio_chip->dev specified) automatically
attached to the OpenFirmware subsystem. Which means that now we can handle
I2C and SPI GPIO chips almost* transparently.
* "Almost" because some chips still require platform data, and for these
chips OF-glue is still needed, though with this support the glue will
be much smaller.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/of/Kconfig | 1 +
drivers/of/gpio.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 101 insertions(+), 0 deletions(-)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index d2fa27c..de9f987 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -5,6 +5,7 @@ config OF_DEVICE
config OF_GPIO
def_bool y
depends on OF && (PPC_OF || MICROBLAZE) && GPIOLIB
+ select GPIOLIB_NOTIFIER
help
OpenFirmware GPIO accessors
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 12c4af0..9d8df77 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -13,6 +13,7 @@
#include <linux/kernel.h>
#include <linux/errno.h>
+#include <linux/notifier.h>
#include <linux/io.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
@@ -236,3 +237,102 @@ err0:
return ret;
}
EXPORT_SYMBOL(of_mm_gpiochip_add);
+
+/**
+ * of_gpiochip_register_simple - Register a chip with the OF GPIO subsystem
+ * @chip pointer to a GPIO chip
+ * @np: device node to register the GPIO chip with
+ *
+ * This function registers a GPIO chip with the OF infrastructure. It is
+ * assumed that the chip was previsously allocated and added to a generic
+ * GPIOLIB framework (using gpiochip_add() function).
+ *
+ * The `simple' name means that the chip is using simple two-cells scheme for
+ * the gpio-specifier.
+ */
+static int of_gpiochip_register_simple(struct gpio_chip *chip,
+ struct device_node *np)
+{
+ struct of_gpio_chip *of_gc;
+
+ if (np->data) {
+ WARN_ON(1);
+ return -EBUSY;
+ }
+
+ of_gc = kzalloc(sizeof(*of_gc), GFP_KERNEL);
+ if (!of_gc)
+ return -ENOMEM;
+
+ of_gc->gpio_cells = 2;
+ of_gc->xlate = of_gpio_simple_xlate;
+ of_gc->chip = chip;
+ np->data = of_gc;
+ of_node_get(np);
+
+ return 0;
+}
+EXPORT_SYMBOL(of_gpiochip_register_simple);
+
+/**
+ * of_gpiochip_unregister - Unregister a GPIO chip
+ * @chip pointer to a GPIO chip
+ * @np: device node for which the GPIO chip was previously registered
+ *
+ * This function unregisters a GPIO chip that was previsously registered
+ * with of_gpiochip_register*().
+ */
+static int of_gpiochip_unregister(struct gpio_chip *chip,
+ struct device_node *np)
+{
+ struct of_gpio_chip *of_gc = np->data;
+
+ if (!of_gc || of_gc->chip != chip) {
+ WARN_ON(1);
+ return -EINVAL;
+ }
+
+ np->data = NULL;
+ kfree(of_gc);
+ of_node_put(np);
+
+ return 0;
+}
+
+static int of_gpio_notify(struct notifier_block *nb, unsigned long msg,
+ void *chip)
+{
+ struct gpio_chip *gc = chip;
+ struct device_node *np;
+ int ret = 0;
+
+ if (!gc->dev)
+ return NOTIFY_DONE;
+
+ np = dev_archdata_get_node(&gc->dev->archdata);
+ if (!np)
+ return NOTIFY_DONE;
+
+ switch (msg) {
+ case GPIO_NOTIFY_CHIP_ADDED:
+ ret = of_gpiochip_register_simple(gc, np);
+ break;
+ case GPIO_NOTIFY_CHIP_REMOVE:
+ ret = of_gpiochip_unregister(gc, np);
+ break;
+ default:
+ break;
+ }
+
+ return ret ? notifier_from_errno(ret) : NOTIFY_OK;
+}
+
+static struct notifier_block of_gpio_nb = {
+ .notifier_call = of_gpio_notify,
+};
+
+static int __init of_gpio_notifier_init(void)
+{
+ return blocking_notifier_chain_register(&gpio_notifier, &of_gpio_nb);
+}
+arch_initcall(of_gpio_notifier_init);
--
1.6.5.7
^ permalink raw reply related
* [PATCH 2/4] of/gpio: Add support for two-stage registration for the of_gpio_chips
From: Anton Vorontsov @ 2010-01-25 18:11 UTC (permalink / raw)
To: Grant Likely, David Brownell
Cc: Bill Gatliff, Dmitry Eremin-Solenikov, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <20100125180957.GA5380@oksana.dev.rtsoft.ru>
With this patch there are two ways to register OF GPIO controllers:
1. Allocating the of_gpio_chip structure and passing the
&of_gc->gc pointer to the gpiochip_add. (Can use container_of
to convert the gpio_chip to the of_gpio_chip.)
2. Allocating and registering the gpio_chip structure separately
from the of_gpio_chip. (Since two allocations are separate,
container_of won't work.)
As time goes by we'll kill the first option.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 1 +
drivers/of/gpio.c | 23 +++++++++++++++++++++--
include/linux/of_gpio.h | 3 ++-
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index 82a9bcb..73c7e6b 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -93,6 +93,7 @@ static int mcu_gpiochip_add(struct mcu *mcu)
gc->base = -1;
gc->set = mcu_gpio_set;
gc->direction_output = mcu_gpio_dir_out;
+ of_gc->chip = gc;
of_gc->gpio_cells = 2;
of_gc->xlate = of_gpio_simple_xlate;
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 6eea601..12c4af0 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -70,7 +70,7 @@ int of_get_gpio_flags(struct device_node *np, int index,
if (ret < 0)
goto err1;
- ret += of_gc->gc.base;
+ ret += of_gc->chip->base;
err1:
of_node_put(gc);
err0:
@@ -140,7 +140,7 @@ int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
return -EINVAL;
}
- if (*gpio > of_gc->gc.ngpio)
+ if (*gpio > of_gc->chip->ngpio)
return -EINVAL;
if (flags)
@@ -178,6 +178,25 @@ int of_mm_gpiochip_add(struct device_node *np,
struct of_gpio_chip *of_gc = &mm_gc->of_gc;
struct gpio_chip *gc = &of_gc->gc;
+ /*
+ * Currently there are two ways to register OF GPIO controllers:
+ *
+ * 1. Allocating the of_gpio_chip structure and passing the
+ * &of_gc->gc pointer to the gpiochip_add. (Can use container_of
+ * to convert the gpio_chip to the of_gpio_chip.)
+ *
+ * 2. Allocating and registering the gpio_chip structure separately
+ * from the of_gpio_chip. (Since two allocations are separate,
+ * container_of won't work.)
+ *
+ * As time goes by we'll kill the first option. For now just check
+ * if it's the new-style registration or the old-style.
+ */
+ if (!of_gc->chip)
+ of_gc->chip = gc;
+ else
+ gc = of_gc->chip;
+
gc->label = kstrdup(np->full_name, GFP_KERNEL);
if (!gc->label)
goto err0;
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index fc2472c..c74cb37 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -36,7 +36,8 @@ enum of_gpio_flags {
* Generic OF GPIO chip
*/
struct of_gpio_chip {
- struct gpio_chip gc;
+ struct gpio_chip gc; /* legacy, don't use for a new code */
+ struct gpio_chip *chip;
int gpio_cells;
int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
const void *gpio_spec, enum of_gpio_flags *flags);
--
1.6.5.7
^ permalink raw reply related
* [PATCH 1/4] gpiolib: Introduce chip addition/removal notifier
From: Anton Vorontsov @ 2010-01-25 18:11 UTC (permalink / raw)
To: Grant Likely, David Brownell
Cc: Bill Gatliff, Dmitry Eremin-Solenikov, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <20100125180957.GA5380@oksana.dev.rtsoft.ru>
Some platforms (e.g. OpenFirmware) want to know when a particular chip
added or removed, so that the platforms could add their specifics for
non-platform devices, like I2C or SPI GPIO chips.
This patch implements the notifier for chip addition and removal events.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/gpio/Kconfig | 7 +++++++
drivers/gpio/gpiolib.c | 28 ++++++++++++++++++++++++++++
include/asm-generic/gpio.h | 8 ++++++++
3 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 1f1d88a..511b29f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -63,6 +63,13 @@ config GPIO_SYSFS
Kernel drivers may also request that a particular GPIO be
exported to userspace; this can be useful when debugging.
+config GPIOLIB_NOTIFIER
+ bool
+ help
+ This symbol is selected by subsystems that need to handle GPIO
+ chips addition and removal. E.g., this is used for the
+ OpenFirmware bindings.
+
# put expanders in the right section, in alphabetical order
comment "Memory mapped GPIO expanders:"
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 350842a..9496b78 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -9,6 +9,7 @@
#include <linux/seq_file.h>
#include <linux/gpio.h>
#include <linux/idr.h>
+#include <linux/notifier.h>
/* Optional implementation infrastructure for GPIO interfaces.
@@ -82,6 +83,25 @@ static inline void desc_set_label(struct gpio_desc *d, const char *label)
#endif
}
+#ifdef CONFIG_GPIOLIB_NOTIFIER
+BLOCKING_NOTIFIER_HEAD(gpio_notifier);
+EXPORT_SYMBOL_GPL(gpio_notifier);
+
+static int gpio_call_chain(struct gpio_chip *chip, enum gpio_notify_msg msg)
+{
+ int ret;
+
+ ret = blocking_notifier_call_chain(&gpio_notifier, msg, chip);
+
+ return notifier_to_errno(ret);
+}
+#else
+static int gpio_call_chain(struct gpio_chip *chip, enum gpio_notify_msg msg)
+{
+ return notifier_to_errno(NOTIFY_OK);
+}
+#endif /* CONFIG_GPIOLIB_NOTIFIER */
+
/* Warn when drivers omit gpio_request() calls -- legal but ill-advised
* when setting direction, and otherwise illegal. Until board setup code
* and drivers use explicit requests everywhere (which won't happen when
@@ -1103,6 +1123,9 @@ fail:
pr_err("gpiochip_add: gpios %d..%d (%s) not registered\n",
chip->base, chip->base + chip->ngpio - 1,
chip->label ? : "generic");
+ else
+ gpio_call_chain(chip, GPIO_NOTIFY_CHIP_ADDED);
+
return status;
}
EXPORT_SYMBOL_GPL(gpiochip_add);
@@ -1119,6 +1142,11 @@ int gpiochip_remove(struct gpio_chip *chip)
int status = 0;
unsigned id;
+ /* Ask external subsystems to release the chip. */
+ status = gpio_call_chain(chip, GPIO_NOTIFY_CHIP_REMOVE);
+ if (status)
+ return status;
+
spin_lock_irqsave(&gpio_lock, flags);
for (id = chip->base; id < chip->base + chip->ngpio; id++) {
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 485eeb6..84faae4 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -4,6 +4,7 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/errno.h>
+#include <linux/notifier.h>
#ifdef CONFIG_GPIOLIB
@@ -208,4 +209,11 @@ static inline void gpio_unexport(unsigned gpio)
}
#endif /* CONFIG_GPIO_SYSFS */
+enum gpio_notify_msg {
+ GPIO_NOTIFY_CHIP_ADDED = 0,
+ GPIO_NOTIFY_CHIP_REMOVE = 1,
+};
+
+extern struct blocking_notifier_head gpio_notifier;
+
#endif /* _ASM_GENERIC_GPIO_H */
--
1.6.5.7
^ permalink raw reply related
* [PATCH 0/4] OF GPIO integration for I2C/SPI GPIO chips
From: Anton Vorontsov @ 2010-01-25 18:09 UTC (permalink / raw)
To: Grant Likely, David Brownell
Cc: Bill Gatliff, Dmitry Eremin-Solenikov, linux-kernel, linuxppc-dev,
Andrew Morton
Hi all,
Currently it's a burden to make I2C or SPI GPIO chips work with the
OF GPIO infrastructure. I've posted several approaches to solve the
issue before, and others have tried too. Here is another try.
This patch set is used to make things much easier, and completely
seamless for GPIO chips that don't need any platform data (e.g.
mcu_mpc8349emitx) or that have OF bindings already (e.g. pca953x).
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Joel Schopp @ 2010-01-25 17:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Neuling, Peter Zijlstra, ego, linux-kernel, Ingo Molnar,
linuxppc-dev
In-Reply-To: <1264302028.3601.36.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2010-01-20 at 16:09 -0600, Joel Schopp wrote:
>
>> I can turn that into a conditional branch (case statement) with a shift
>> for the common 1,2,4 cases which should cover all procs available today
>> falling back to a divide for any theoretical future processors that do
>> other numbers of threads.
>>
>
> Look at the cputhreads.h implementation ... Today we only support
> power-of-two numbers of threads.
>
I've run 3 threads using cpu hotplug to offline 1 of the 4. It's
certainly a stupid idea, but there you go.
^ permalink raw reply
* NAND (UPM) / NOR Flash(GPCM) existence MPC832x any issue
From: nanda @ 2010-01-25 17:36 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev, avorontsov
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
Thanks for the information.
Based on your input, I could successfully update the dts file and gpio controller configuration. I verified from the GPIO chip intialized and added properly. But, still Iam getting the message as
"No NAND device found!!!".
In our system we have two flash NOR connected thru GPCM and NAND device(STM Flash is NAND512W3A2C) connected using UPM.
NAND Flash starting address: fb000000(64 MB size)
NOR Flash starting address: fa000000 (16 MB size)
MPC8321E processor's port C, PIN 15 connected to the R/B PIN of NAND Flash.
Below are the dts file changes in mpc832x_rdb.dts
DTS File changes:
----------------------------
qe_pio_c: gpio-controller@1430 {
#gpio-cells = ;
compatible = "fsl,mpc8360-qe-pario-bank",
"fsl,mpc8323-qe-pario-bank";
reg = ;
gpio-controller;
};
};
localbus@e0005000 {
#address-cells = ;
#size-cells = ;
compatible = "fsl,elbc","fsl-pq2pro-localbus","simple-bus" ;
reg = ;
interrupts = ;
interrupt-parent = < &pic >;
nand@fb000000 {
compatible = "fsl,upm-nand";
reg = ; /*64MB*/
fsl,upm-addr-offset = ;
fsl,upm-cmd-offset = ;
gpios = ;
flash {
compatible = "stm,nand512-a";
};
};
nor@fa000000 {
device_type = "rom";
compatible = "direct-mapped";
reg = ; /*16MB*/
probe-type = "CFI";
bank-width = ;
u-boot@0 {
label = "U-Boot";
reg = ; /* 512K */
read-only;
};
fw@80000 {
label = "UCC QE Firmware";
reg = ; /* 256K */
read-only;
};
dtb@c0000 {
label = "DTB";
reg = ; /* 256K */
read-only;
};
kernel@100000 {
label = "Kernel";
reg = ; /* 4M */
read-only;
};
fs@500000 {
label = "Root File System";
reg = ; /* 8M */
};
user@d00000 {
label = "User";
label = "User";
reg = ; /* 3M */
};
};
};
Please let me know if I missed out anything.
Regards,
Nanda
[-- Attachment #2: Type: text/html, Size: 2890 bytes --]
^ permalink raw reply
* Re: Large physical address support on e500 platform
From: Kumar Gala @ 2010-01-25 17:25 UTC (permalink / raw)
To: Aaron Pace; +Cc: linuxppc-dev
In-Reply-To: <bc81dc641001250906o18ba8e9cofbb02421ae046f65@mail.gmail.com>
On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote:
>>=20
>> Is a simple "hello world" module sufficient to show the issue? I'll =
look into it this week.
>>=20
>> - k
>=20
> It wasn't in my situation, unfortunately. To duplicate this, I had
> one relatively large kernel module, and then one simple 'hello world'
> module that did nothing more than call an exported function from the
> first module as part of its init.
Ok, if there is a module or something you can post that reproduces the =
issue that would be extremely helpful.
- k=
^ permalink raw reply
* Re: [PATCH 1/4] edac: Remove unused mpc85xx debug code
From: Peter Tyser @ 2010-01-25 17:20 UTC (permalink / raw)
To: bluesmoke-devel; +Cc: linuxppc-dev, djiang
In-Reply-To: <1258677749-15968-1-git-send-email-ptyser@xes-inc.com>
On Thu, 2009-11-19 at 18:42 -0600, Peter Tyser wrote:
> Some unused, unsupported debug code existed in the mpc85xx EDAC driver
> that resulted in a build failure when CONFIG_EDAC_DEBUG was defined:
>
> drivers/edac/mpc85xx_edac.c: In function 'mpc85xx_mc_err_probe':
> drivers/edac/mpc85xx_edac.c:1031: error: implicit declaration of function 'edac_mc_register_mcidev_debug'
> drivers/edac/mpc85xx_edac.c:1031: error: 'debug_attr' undeclared (first use in this function)
> drivers/edac/mpc85xx_edac.c:1031: error: (Each undeclared identifier is reported only once
> drivers/edac/mpc85xx_edac.c:1031: error: for each function it appears in.)
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
<snip>
Any chance some of these will be picked up for 2.6.33?
I added Kumar on CC as I'm not sure if these should go through the EDAC
or PPC tree.
1/4 fixes a build error when CONFIG_EDAC_DEBUG is defined and is pretty
trivial.
2/4 fixes a regression which results in ECC detection not working.
3/4 and 4/4 are "improvements", but don't necessarily need to go into
2.6.33.
Best,
Peter
^ permalink raw reply
* Re: Large physical address support on e500 platform
From: Aaron Pace @ 2010-01-25 17:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C8218436-3EA1-46F0-8E7E-4699AA06005B@kernel.crashing.org>
>
> Is a simple "hello world" module sufficient to show the issue? =A0I'll lo=
ok into it this week.
>
> - k
It wasn't in my situation, unfortunately. To duplicate this, I had
one relatively large kernel module, and then one simple 'hello world'
module that did nothing more than call an exported function from the
first module as part of its init.
-Aaron
^ permalink raw reply
* Re: [PATCH 08/11] powerpc/mpc5121: add USB host support
From: Anatolij Gustschin @ 2010-01-25 17:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-usb, wd, dzu
In-Reply-To: <fa686aa41001210943i3739f693uecf0c05ef0a81c1@mail.gmail.com>
On Thu, 21 Jan 2010 10:43:34 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> > diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt b/Documenta=
tion/powerpc/dts-bindings/fsl/usb.txt
> > index b001524..9050154 100644
> > --- a/Documentation/powerpc/dts-bindings/fsl/usb.txt
> > +++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt
> > @@ -33,6 +33,14 @@ Recommended properties :
> > =C2=A0- interrupt-parent : the phandle for the interrupt controller that
> > =C2=A0 =C2=A0services interrupts for this device.
> >
> > +Optional properties :
>=20
> > + - big-endian-regs : boolean; if defined, indicates the USB host
> > + =C2=A0 controller registers format is big endian.
>=20
> Rather than testing for this explicitly, add fsl,mpc5121-usb2-dr to
> the match table and use the .data pointer for setting device specific
> quirks.
There is no match table. fsl_usb_of_init() is an arch_initcall and
tests other properties using the same approach.
> > + - invert-drvvbus : boolean; for MPC5121 only. Indicates the port
> > + =C2=A0 power polarity of internal PHY signal DRVVBUS is inverted.
> > + - invert-pwr-fault : boolean; for MPC5121 only. Indicates the
> > + =C2=A0 PWR_FAULT signal polarity is inverted.
>=20
> These are also characteristics of the chip, not the board, right? If
> so then these also can be determined implicitly by the compatible
> value.
No, these are characteristics of the board. The internal USB PHY doesn't
provide supply voltage. Some boards use MIC2025 switches which require acti=
ve
high DRVVBUS and active low PWR_FAULT. Some boards could use MIC2026 or
MAX1838 which require other polarities.
> Finally, these are all freescale specific properties. If you still
> need them, then prefix the property names with 'fsl,'
OK.
> > ...
> > +
> > +config USB_FSL_BIG_ENDIAN_MMIO
> > + =C2=A0 =C2=A0 =C2=A0 bool
>=20
> What's this for?
This is currently unused (will be used later), I will remove it for now.
> > ...
> > @@ -77,14 +77,13 @@ static int usb_hcd_fsl_probe(const struct hc_driver=
*driver,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -ENODEV;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> > - =C2=A0 =C2=A0 =C2=A0 res =3D platform_get_resource(pdev, IORESOURCE_I=
RQ, 0);
> > - =C2=A0 =C2=A0 =C2=A0 if (!res) {
> > + =C2=A0 =C2=A0 =C2=A0 irq =3D platform_get_irq(pdev, 0);
> > + =C2=A0 =C2=A0 =C2=A0 if (irq < 0) {
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_err(&pdev->d=
ev,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0"Found HC with no IRQ. Check %s setup!\n",
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0dev_name(&pdev->dev));
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -ENODEV;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > - =C2=A0 =C2=A0 =C2=A0 irq =3D res->start;
>=20
> Put this hunk in a separate patch.
OK.
> > ...
> > + =C2=A0 =C2=A0 =C2=A0 if (pdata->have_sysif_regs) {
> > =C2=A0#ifdef CONFIG_PPC_85xx
> > - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_PRICTRL, 0x00000=
008);
> > - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_AGECNTTHRSH, 0x0=
0000080);
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + =
FSL_SOC_USB_PRICTRL, 0x00000008);
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + =
FSL_SOC_USB_AGECNTTHRSH, 0x00000080);
> > =C2=A0#else
> > - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_PRICTRL, 0x00000=
00c);
> > - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_AGECNTTHRSH, 0x0=
0000040);
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + =
FSL_SOC_USB_PRICTRL, 0x0000000c);
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + =
FSL_SOC_USB_AGECNTTHRSH, 0x00000040);
> > =C2=A0#endif
> > - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_SICTRL, 0x000000=
01);
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + =
FSL_SOC_USB_SICTRL, 0x00000001);
> > + =C2=A0 =C2=A0 =C2=A0 }
> > =C2=A0}
>=20
> Unrelated whitespace changes. Put in separate patch.
OK.
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem
From: Kumar Gala @ 2010-01-25 16:55 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, Nate Case
In-Reply-To: <1261176637-23912-1-git-send-email-ptyser@xes-inc.com>
On Dec 18, 2009, at 4:50 PM, Peter Tyser wrote:
> Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
> the "cpu-release-addr" device tree property to contain the physical RAM
> location that secondary cores were spinning at. Previously, the
> "cpu-release-addr" property contained a value referencing the boot page
> translation address range of 0xfffffxxx, which then indirectly accessed
> RAM.
>
> The "cpu-release-addr" is currently ioremapped and the secondary cores
> kicked. However, due to the recent change in "cpu-release-addr", it
> sometimes points to a memory location in low memory that cannot be
> ioremapped. For example on a P2020-based board with 512MB of RAM the
> following error occurs on bootup:
>
> <...>
> mpic: requesting IPIs ...
> __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
> Unable to handle kernel paging request for data at address 0x00000014
> Faulting instruction address: 0xc05df9b0
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=2 P2020 RDB
> Modules linked in:
> <... eventual kernel panic>
>
> Adding logic to conditionally ioremap or access memory directly resolves
> the issue.
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
> Reported-by: Dipen Dudhat <B09055@freescale.com>
> Tested-by: Dipen Dudhat <B09055@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 21 +++++++++++++++++++--
> 1 files changed, 19 insertions(+), 2 deletions(-)
applied to merge for 2.6.33
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix oops during MSI driver probe on MPC85xxMDS boards
From: Kumar Gala @ 2010-01-25 16:54 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20091215225809.GA32140@oksana.dev.rtsoft.ru>
On Dec 15, 2009, at 4:58 PM, Anton Vorontsov wrote:
> MPC85xx chips report the wrong value in feature reporting register,
> and that causes the following oops:
>
> Unable to handle kernel paging request for data at address 0x00000c00
> Faulting instruction address: 0xc0019294
> Oops: Kernel access of bad area, sig: 11 [#1]
> MPC8569 MDS
> Modules linked in:
> [...]
> NIP [c0019294] mpic_set_irq_type+0x2f0/0x368
> LR [c0019124] mpic_set_irq_type+0x180/0x368
> Call Trace:
> [ef851d60] [c0019124] mpic_set_irq_type+0x180/0x368 (unreliable)
> [ef851d90] [c007958c] __irq_set_trigger+0x44/0xd4
> [ef851db0] [c007b550] set_irq_type+0x40/0x7c
> [ef851dc0] [c0004a60] irq_create_of_mapping+0xb4/0x114
> [ef851df0] [c0004af0] irq_of_parse_and_map+0x30/0x40
> [ef851e20] [c0405678] fsl_of_msi_probe+0x1a0/0x328
> [ef851e60] [c02e6438] of_platform_device_probe+0x5c/0x84
> [...]
>
> This is because mpic_alloc() assigns wrong values to
> mpic->isu_{size,shift,mask}, and things eventually break when
> _mpic_irq_read() is trying to use them.
>
> This patch fixes the issue by enabling MPIC_BROKEN_FRR_NIRQS quirk.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
applied to merge for 2.6.33
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem
From: Kumar Gala @ 2010-01-25 16:50 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, Nate Case
In-Reply-To: <1264112935.31570.361.camel@localhost.localdomain>
On Jan 21, 2010, at 4:28 PM, Peter Tyser wrote:
> On Fri, 2009-12-18 at 16:50 -0600, Peter Tyser wrote:
>> Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
>> the "cpu-release-addr" device tree property to contain the physical RAM
>> location that secondary cores were spinning at. Previously, the
>> "cpu-release-addr" property contained a value referencing the boot page
>> translation address range of 0xfffffxxx, which then indirectly accessed
>> RAM.
>>
>> The "cpu-release-addr" is currently ioremapped and the secondary cores
>> kicked. However, due to the recent change in "cpu-release-addr", it
>> sometimes points to a memory location in low memory that cannot be
>> ioremapped. For example on a P2020-based board with 512MB of RAM the
>> following error occurs on bootup:
>>
>> <...>
>> mpic: requesting IPIs ...
>> __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
>> Unable to handle kernel paging request for data at address 0x00000014
>> Faulting instruction address: 0xc05df9b0
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=2 P2020 RDB
>> Modules linked in:
>> <... eventual kernel panic>
>>
>> Adding logic to conditionally ioremap or access memory directly resolves
>> the issue.
>>
>> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
>> Signed-off-by: Nate Case <ncase@xes-inc.com>
>> Reported-by: Dipen Dudhat <B09055@freescale.com>
>> Tested-by: Dipen Dudhat <B09055@freescale.com>
>
> Any chance this going to be picked up for 2.6.33? The issue is
> currently going to bite anyone using an MP-capable 85xx system that
> doesn't use highmem.
This just got lost in my queue. Will apply and send up for .33
- k
^ permalink raw reply
* Re: Large physical address support on e500 platform
From: Kumar Gala @ 2010-01-25 16:46 UTC (permalink / raw)
To: Aaron Pace; +Cc: linuxppc-dev
In-Reply-To: <bc81dc641001212227w429b0f33hab1e541e69a11bf7@mail.gmail.com>
On Jan 22, 2010, at 12:27 AM, Aaron Pace wrote:
>>>=20
>>> Its possible that we've broken module/vmalloc support with
>>> "Large physical addressing".? Its not something I've
>>> tried in a while.? What kernel/git SHA are you using.
>>>=20
>=20
>> I'm just pulling in from the main kernel tree git.
>> My current version is 2.6.33-rc4-00193-gd1e4922-dirty,
>> but it had not changed since 2.6.33-rc2
>>=20
>> I started from 2.6.32, but I don't remember if I had a large PA
>> support enabled there.
>=20
> Just to second this issue, the following commit is what broke this:
>=20
> [76acc2c1a7a9a8c2cae7e9cf8d0a8b374a48aa94]
>=20
> I didn't have time to delve into the whys & hows, but this commit
> caused the same issue on an 8572 platform.
> Reverting this one change allows everything (including 36-bit memory
> access) to work correctly, as before.
Is a simple "hello world" module sufficient to show the issue? I'll =
look into it this week.
- k=
^ permalink raw reply
* Re: [PATCH 06/11] mtd: Add MPC5121 NAND Flash Controller driver
From: Anatolij Gustschin @ 2010-01-25 15:56 UTC (permalink / raw)
To: Wolfram Sang; +Cc: wd, dzu, linuxppc-dev, linux-mtd, Piotr Ziecik
In-Reply-To: <20100120104915.GB5041@pengutronix.de>
Hi Wolfram,
Wolfram Sang <w.sang@pengutronix.de> wrote:
> Please include a logfile with changes since the last version. This really
> helps.
Ok.
> > +static int __init mpc5121_nfc_probe(struct of_device *op,
> > + const struct of_device_id *match)
>
> [...]
>
> > +{
> > + /* Support external chip-select logic on ADS5121 board */
> > + rootnode = of_find_node_by_path("/");
> > + if (of_device_is_compatible(rootnode, "fsl,mpc5121ads")) {
> > + retval = ads5121_chipselect_init(mtd);
> > + if (retval) {
> > + dev_err(dev, "Chipselect init error!\n");
> > + of_node_put(rootnode);
> > + return retval;
> > + }
> > +
> > + chip->select_chip = ads5121_select_chip;
> > + }
> > + of_node_put(rootnode);
>
> If we have to live with the platform-stuff being in the driver, maybe a table
> having the compatible-string and an init-function pointer per entry will make
> it scale better with the number of boards?
Maybe something like in the patch below can be accepted?
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index 2980eb1..6807e72 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -127,6 +127,10 @@ struct mpc5121_nfc_prv {
struct device *dev;
};
+struct mpc5121_nfc_match_data {
+ int (*init)(struct mtd_info *);
+};
+
static void mpc5121_nfc_done(struct mtd_info *mtd);
#ifdef CONFIG_MTD_PARTITIONS
@@ -279,6 +283,26 @@ static void mpc5121_nfc_select_chip(struct mtd_info *mtd, int chip)
nfc_set(mtd, NFC_CONFIG1, NFC_CE);
}
+/* Control chips select signal on ADS5121 board */
+static void ads5121_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct nand_chip *nand = mtd->priv;
+ struct mpc5121_nfc_prv *prv = nand->priv;
+ u8 v;
+
+ /* CPLD Register 9 controls NAND /CE Lines */
+ v = in_8(prv->csreg + 9);
+ v |= 0x0F;
+
+ if (chip >= 0) {
+ mpc5121_nfc_select_chip(mtd, 0);
+ v &= ~(1 << chip);
+ } else
+ mpc5121_nfc_select_chip(mtd, -1);
+
+ out_8(prv->csreg + 9, v);
+}
+
/* Init external chip select logic on ADS5121 board */
static int ads5121_chipselect_init(struct mtd_info *mtd)
{
@@ -293,33 +317,13 @@ static int ads5121_chipselect_init(struct mtd_info *mtd)
if (!prv->csreg)
return -ENOMEM;
- /* CPLD Register 9 controls NAND /CE Lines */
- prv->csreg += 9;
+ chip->select_chip = ads5121_select_chip;
return 0;
}
return -EINVAL;
}
-/* Control chips select signal on ADS5121 board */
-static void ads5121_select_chip(struct mtd_info *mtd, int chip)
-{
- struct nand_chip *nand = mtd->priv;
- struct mpc5121_nfc_prv *prv = nand->priv;
- u8 v;
-
- v = in_8(prv->csreg);
- v |= 0x0F;
-
- if (chip >= 0) {
- mpc5121_nfc_select_chip(mtd, 0);
- v &= ~(1 << chip);
- } else
- mpc5121_nfc_select_chip(mtd, -1);
-
- out_8(prv->csreg, v);
-}
-
/* Read NAND Ready/Busy signal */
static int mpc5121_nfc_dev_ready(struct mtd_info *mtd)
{
@@ -649,7 +653,7 @@ static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd)
static int __init mpc5121_nfc_probe(struct of_device *op,
const struct of_device_id *match)
{
- struct device_node *rootnode, *dn = op->node;
+ struct device_node *dn = op->node;
struct device *dev = &op->dev;
struct mpc5121_nfc_prv *prv;
struct resource res;
@@ -663,6 +667,7 @@ static int __init mpc5121_nfc_probe(struct of_device *op,
int resettime = 0;
int retval = 0;
int rev, len;
+ struct mpc5121_nfc_match_data *data = match->data;
/*
* Check SoC revision. This driver supports only NFC
@@ -738,19 +743,13 @@ static int __init mpc5121_nfc_probe(struct of_device *op,
chip->options = NAND_NO_AUTOINCR | NAND_USE_FLASH_BBT;
chip->ecc.mode = NAND_ECC_SOFT;
- /* Support external chip-select logic on ADS5121 board */
- rootnode = of_find_node_by_path("/");
- if (of_device_is_compatible(rootnode, "fsl,mpc5121ads")) {
- retval = ads5121_chipselect_init(mtd);
+ if (data && data->init) {
+ retval = data->init(mtd);
if (retval) {
dev_err(dev, "Chipselect init error!\n");
- of_node_put(rootnode);
- return retval;
+ goto error;
}
-
- chip->select_chip = ads5121_select_chip;
}
- of_node_put(rootnode);
/* Enable NFC clock */
prv->clk = clk_get(dev, "nfc_clk");
@@ -884,6 +883,11 @@ static int __exit mpc5121_nfc_remove(struct of_device *op)
static struct of_device_id mpc5121_nfc_match[] = {
{ .compatible = "fsl,mpc5121-nfc", },
+ { .compatible = "fsl,mpc5121ads-nfc",
+ .data = &(struct mpc5121_nfc_match_data) {
+ .init = ads5121_chipselect_init,
+ },
+ },
{},
};
^ permalink raw reply related
* Re: [PATCH 2/3] i2c-mpc: add support for the MPC512x processors from Freescale
From: Wolfram Sang @ 2010-01-25 15:15 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Devicetree-discuss, Linuxppc-dev, Linux-i2c, Wolfgang Grandegger
In-Reply-To: <4B5D894C.4090001@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
> >>
> >> -static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
> >> - struct mpc_i2c *i2c,
> >> - u32 clock, u32 prescaler)
> >> +static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
> >> + struct mpc_i2c *i2c,
> >> + u32 clock, u32 prescaler)
> >> {
> >> int ret, fdr;
> >>
> >> + if (clock == -1) {
> >
> > Could we use 0 for 'no_clock'? This would make the above statement simply
>
> "0" is already used to maintain backward compatibility setting a safe
> divider.
Ah, now I see:
'clock == -1' means 'preserve clocks' (and is checked here in mpc_i2c_setup_52xx())
'clock == 0' means 'safe divider' (and is checked in mpc_i2c_get_fdr_52xx())
This is not a beauty ;)
What about adding a flags variable to the setup-functions?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [RFC PATCH] PCI-E broken on PPC (regression)
From: Breno Leitao @ 2010-01-25 13:42 UTC (permalink / raw)
To: Linux PCI, linuxppc-dev; +Cc: Jay Vosburgh, Ron Mercer, kaneshige.kenji
Hello,
I found that qlge is broken on PPC, and it got broken after commit
06a1cbafb253c4c60d6a54a994887f5fbceabcc0. It happens because dev->pcie
is not set on PPC, because the function set_pcie_port_type(), who sets
dev->pcie, is not being called on PPC PCI code.
So, I have two ideas to fix it, the first one is to call
set_pcie_port_type() on pci_device_add() instead of pci_setup_device().
Since that PPC device flow calls pci_device_add(), it fixes the problem
without duplicating the caller for this function.
OTOH, it's also possible to add set_pcie_port_type() on pci.h and call
it inside the PPC PCI files, specifically on of_create_pci_dev().
I tested both ideas and they work perfect, so I'd like to figure out
which one is the most correct one. Both patches are attached here.
Thanks,
Breno
----- First idea -----
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 98ffb2d..328c3ab 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -746,7 +746,6 @@ int pci_setup_device(struct pci_dev *dev)
dev->hdr_type = hdr_type & 0x7f;
dev->multifunction = !!(hdr_type & 0x80);
dev->error_state = pci_channel_io_normal;
- set_pcie_port_type(dev);
set_pci_aer_firmware_first(dev);
list_for_each_entry(slot, &dev->bus->slots, list)
@@ -1052,6 +1051,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
/* Initialize various capabilities */
pci_init_capabilities(dev);
+ set_pcie_port_type(dev);
/*
* Add the device to our list of discovered devices
* and the bus list for fixup functions, etc.
----- Second idea -----
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 7311fdf..f8820e8 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -160,6 +160,7 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
dev->error_state = pci_channel_io_normal;
dev->dma_mask = 0xffffffff;
+ set_pcie_port_type(dev);
if (!strcmp(type, "pci") || !strcmp(type, "pciex")) {
/* a PCI-PCI bridge */
dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 98ffb2d..f787eea 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -681,7 +681,7 @@ static void pci_read_irq(struct pci_dev *dev)
dev->irq = irq;
}
-static void set_pcie_port_type(struct pci_dev *pdev)
+void set_pcie_port_type(struct pci_dev *pdev)
{
int pos;
u16 reg16;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 174e539..765095b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1269,6 +1269,7 @@ int pcibios_add_platform_entries(struct pci_dev *dev);
void pcibios_disable_device(struct pci_dev *dev);
int pcibios_set_pcie_reset_state(struct pci_dev *dev,
enum pcie_reset_state state);
+extern void set_pcie_port_type(struct pci_dev *pdev);
#ifdef CONFIG_PCI_MMCONFIG
extern void __init pci_mmcfg_early_init(void);
^ permalink raw reply related
* Re: [PATCH 2/3] i2c-mpc: add support for the MPC512x processors from Freescale
From: Wolfgang Grandegger @ 2010-01-25 12:06 UTC (permalink / raw)
To: Wolfram Sang
Cc: Devicetree-discuss, Linuxppc-dev, Linux-i2c, Wolfgang Grandegger
In-Reply-To: <20100125115211.GA5257@pengutronix.de>
Hi Wolfram,
Wolfram Sang wrote:
> Hi Wolfgang,
>
> On Mon, Jan 25, 2010 at 09:27:08AM +0100, Wolfgang Grandegger wrote:
>> From: Wolfgang Grandegger <wg@denx.de>
>>
>> The "setclock" initialization functions have been renamed to "setup"
>> because I2C interrupts must be enabled for the MPC512x. This requires
>> to handle "fsl,preserve-clocking" in a slighly different way. Also,
>> the old settings are now reported calling dev_dbg(). For the MPC512x
>> the clock setup function of the MPC52xx can be re-used.
>>
>> Signed-off-by: Wolfgang Grandegger <wg@denx.de>
>> ---
>> drivers/i2c/busses/Kconfig | 9 ++--
>> drivers/i2c/busses/i2c-mpc.c | 122 ++++++++++++++++++++++++++++++------------
>> 2 files changed, 93 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index 5f318ce..f481f30 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -418,13 +418,14 @@ config I2C_IXP2000
>> instead.
>>
>> config I2C_MPC
>> - tristate "MPC107/824x/85xx/52xx/86xx"
>> + tristate "MPC107/824x/85xx/512x/52xx/86xx"
>> depends on PPC32
>> help
>> If you say yes to this option, support will be included for the
>> - built-in I2C interface on the MPC107/Tsi107/MPC8240/MPC8245 and
>> - MPC85xx/MPC8641 family processors. The driver may also work on 52xx
>> - family processors, though interrupts are known not to work.
>> + built-in I2C interface on the MPC107/Tsi107/MPC8240/MPC8245,
>> + MPC85xx/MPC8641 and MPC512x family processors. The driver may
>> + also work on 52xx family processors, though interrupts are known
>> + not to work.
>
> Opinion poll: Can we remove the "may work" sentence while we are here? It has
> worked fine for years. BTW, which interrupts are meant here (from I2C slaves?
> interrupts of the controller?)?
I first wanted to remove this sentence but as I was not sure what it's
exact meaning... Anyway, it's confusing and I would remove it.
>> This driver can also be built as a module. If so, the module
>> will be called i2c-mpc.
>> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
>> index 2cb864e..70c3e5d 100644
>> --- a/drivers/i2c/busses/i2c-mpc.c
>> +++ b/drivers/i2c/busses/i2c-mpc.c
>> @@ -67,9 +67,8 @@ struct mpc_i2c_divider {
>> };
>>
>> struct mpc_i2c_data {
>> - void (*setclock)(struct device_node *node,
>> - struct mpc_i2c *i2c,
>> - u32 clock, u32 prescaler);
>> + void (*setup)(struct device_node *node, struct mpc_i2c *i2c,
>> + u32 clock, u32 prescaler);
>> u32 prescaler;
>> };
>>
>> @@ -164,7 +163,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
>> return 0;
>> }
>>
>> -#ifdef CONFIG_PPC_MPC52xx
>> +#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
>> static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
>> {20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
>> {28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
>> @@ -216,12 +215,18 @@ static int __devinit mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock,
>> return div ? (int)div->fdr : -EINVAL;
>> }
>>
>> -static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
>> - struct mpc_i2c *i2c,
>> - u32 clock, u32 prescaler)
>> +static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
>> + struct mpc_i2c *i2c,
>> + u32 clock, u32 prescaler)
>> {
>> int ret, fdr;
>>
>> + if (clock == -1) {
>
> Could we use 0 for 'no_clock'? This would make the above statement simply
"0" is already used to maintain backward compatibility setting a safe
divider.
> if (!clock)
>
> and saves us using -1 with a u32.
>
>> + dev_dbg(i2c->dev, "using fdr %d\n",
>> + readb(i2c->base + MPC_I2C_FDR));
>> + return; /* preserve clocking */
>> + }
>> +
>> ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler);
>> fdr = (ret >= 0) ? ret : 0x3f; /* backward compatibility */
>>
>> @@ -230,13 +235,50 @@ static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
>> if (ret >= 0)
>> dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
>> }
>> -#else /* !CONFIG_PPC_MPC52xx */
>> -static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
>> - struct mpc_i2c *i2c,
>> - u32 clock, u32 prescaler)
>> +#else /* !(CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x) */
>> +static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
>> + struct mpc_i2c *i2c,
>> + u32 clock, u32 prescaler)
>> +{
>> +}
>> +#endif /* CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x */
>> +
>> +#ifdef CONFIG_PPC_MPC512x
>> +static void __devinit mpc_i2c_setup_512x(struct device_node *node,
>> + struct mpc_i2c *i2c,
>> + u32 clock, u32 prescaler)
>> +{
>> + struct device_node *node_ctrl;
>> + void __iomem *ctrl;
>> + const u32 *pval;
>> + u32 idx;
>> +
>> + /* Enable I2C interrupts for mpc5121 */
>> + node_ctrl = of_find_compatible_node(NULL, NULL,
>> + "fsl,mpc5121-i2c-ctrl");
>> + if (node_ctrl) {
>> + ctrl = of_iomap(node_ctrl, 0);
>> + if (ctrl) {
>> +
>> + /* Interrupt enable bits for i2c-0/1/2: bit 24/26/28 */
>> + pval = of_get_property(node, "reg", NULL);
>> + idx = (*pval & 0xff) / 0x20;
>> + setbits32(ctrl, 1 << (24 + idx * 2));
>> + iounmap(ctrl);
>> + }
>> + of_node_put(node_ctrl);
>> + }
>> +
>> + /* The clock setup for the 52xx works also fine for the 512x */
>> + mpc_i2c_setup_52xx(node, i2c, clock, prescaler);
>> +}
>> +#else /* CONFIG_PPC_MPC512x */
>> +static void __devinit mpc_i2c_setup_512x(struct device_node *node,
>> + struct mpc_i2c *i2c,
>> + u32 clock, u32 prescaler)
>> {
>> }
>> -#endif /* CONFIG_PPC_MPC52xx*/
>> +#endif /* CONFIG_PPC_MPC512x */
>>
>> #ifdef CONFIG_FSL_SOC
>> static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
>> @@ -322,12 +364,19 @@ static int __devinit mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock,
>> return div ? (int)div->fdr : -EINVAL;
>> }
>>
>> -static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
>> - struct mpc_i2c *i2c,
>> - u32 clock, u32 prescaler)
>> +static void __devinit mpc_i2c_setup_8xxx(struct device_node *node,
>> + struct mpc_i2c *i2c,
>> + u32 clock, u32 prescaler)
>> {
>> int ret, fdr;
>>
>> + if (clock == -1) {
>> + dev_dbg(i2c->dev, "using dfsrr %d, fdr %d\n",
>> + readb(i2c->base + MPC_I2C_DFSRR),
>> + readb(i2c->base + MPC_I2C_FDR));
>> + return; /* preserve clocking */
>> + }
>> +
>> ret = mpc_i2c_get_fdr_8xxx(node, clock, prescaler);
>> fdr = (ret >= 0) ? ret : 0x1031; /* backward compatibility */
>>
>> @@ -340,9 +389,9 @@ static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
>> }
>>
>> #else /* !CONFIG_FSL_SOC */
>> -static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
>> - struct mpc_i2c *i2c,
>> - u32 clock, u32 prescaler)
>> +static void __devinit mpc_i2c_setup_8xxx(struct device_node *node,
>> + struct mpc_i2c *i2c,
>> + u32 clock, u32 prescaler)
>> {
>> }
>> #endif /* CONFIG_FSL_SOC */
>> @@ -525,21 +574,21 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
>> }
>> }
>>
>> - if (!of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
>> + if (of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
>> + clock = -1;
>> + } else {
>> prop = of_get_property(op->node, "clock-frequency", &plen);
>> if (prop && plen == sizeof(u32))
>> clock = *prop;
>> + }
>>
>> - if (match->data) {
>> - struct mpc_i2c_data *data =
>> - (struct mpc_i2c_data *)match->data;
>> - data->setclock(op->node, i2c, clock, data->prescaler);
>> - } else {
>> - /* Backwards compatibility */
>> - if (of_get_property(op->node, "dfsrr", NULL))
>> - mpc_i2c_setclock_8xxx(op->node, i2c,
>> - clock, 0);
>> - }
>> + if (match->data) {
>> + struct mpc_i2c_data *data = (struct mpc_i2c_data *)match->data;
>
> The cast should not be necessary.
Right.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 0/3] i2c-mpc: add support for the Freescale MPC512x and other fixes
From: Wolfram Sang @ 2010-01-25 12:02 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Devicetree-discuss, Linuxppc-dev, Linux-i2c
In-Reply-To: <1264408029-5290-1-git-send-email-wg@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
On Mon, Jan 25, 2010 at 09:27:06AM +0100, Wolfgang Grandegger wrote:
> This patch series adds support for the MPC512x from Freescale to the
> i2c-mpc driver. At that occasion, issues with __devinit[data] have
> been fixed and the doc of the FSL I2C dts bindings updated. It has
> been tested on a MPC5121ADS, TQM5200 and TQM8560 board
Nice :) BTW, is there a git-tree meanwhile for your or Anatolij's
MPC5121-development?
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: doc/dts-bindings: update doc of FSL I2C bindings
From: Wolfgang Grandegger @ 2010-01-25 11:58 UTC (permalink / raw)
To: Wolfram Sang
Cc: Devicetree-discuss, Linuxppc-dev, Linux-i2c, Wolfgang Grandegger
In-Reply-To: <20100125115654.GB5257@pengutronix.de>
Wolfram Sang wrote:
> On Mon, Jan 25, 2010 at 09:27:09AM +0100, Wolfgang Grandegger wrote:
>> From: Wolfgang Grandegger <wg@denx.de>
>>
>> This patch adds the MPC5121 to the list of supported devices,
>> enhances the doc of the "clock-frequency" property and removes
>> the obsolete "cell-index" property from the example nodes.
>
> I think "fsl,mpc5121-i2c-ctrl" needs to be documented here, too?
Yep,
Wolfgang.
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: doc/dts-bindings: update doc of FSL I2C bindings
From: Wolfram Sang @ 2010-01-25 11:56 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Devicetree-discuss, Linuxppc-dev, Linux-i2c, Wolfgang Grandegger
In-Reply-To: <1264408029-5290-4-git-send-email-wg@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 2854 bytes --]
On Mon, Jan 25, 2010 at 09:27:09AM +0100, Wolfgang Grandegger wrote:
> From: Wolfgang Grandegger <wg@denx.de>
>
> This patch adds the MPC5121 to the list of supported devices,
> enhances the doc of the "clock-frequency" property and removes
> the obsolete "cell-index" property from the example nodes.
I think "fsl,mpc5121-i2c-ctrl" needs to be documented here, too?
>
> Signed-off-by: Wolfgang Grandegger <wg@denx.de>
> ---
> Documentation/powerpc/dts-bindings/fsl/i2c.txt | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/i2c.txt b/Documentation/powerpc/dts-bindings/fsl/i2c.txt
> index b6d2e21..2af8a05 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/i2c.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/i2c.txt
> @@ -9,8 +9,8 @@ Recommended properties :
>
> - compatible : compatibility list with 2 entries, the first should
> be "fsl,CHIP-i2c" where CHIP is the name of a compatible processor,
> - e.g. mpc8313, mpc8543, mpc8544, mpc5200 or mpc5200b. The second one
> - should be "fsl-i2c".
> + e.g. mpc8313, mpc8543, mpc8544, mpc5121, mpc5200 or mpc5200b. The
> + second one should be "fsl-i2c".
> - interrupts : <a b> where a is the interrupt number and b is a
> field that represents an encoding of the sense and level
> information for the interrupt. This should be encoded based on
> @@ -20,7 +20,9 @@ Recommended properties :
> services interrupts for this device.
> - fsl,preserve-clocking : boolean; if defined, the clock settings
> from the bootloader are preserved (not touched).
> - - clock-frequency : desired I2C bus clock frequency in Hz.
> + - clock-frequency : desired I2C bus clock frequency in Hz. If this
> + property and "fsl,preserve-clocking" is not defined, a safe fixed
> + clock divider value is used (resulting in a small clock frequency).
>
> Examples :
>
> @@ -28,7 +30,6 @@ Examples :
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
> - cell-index = <0>;
> reg = <0x3d00 0x40>;
> interrupts = <2 15 0>;
> interrupt-parent = <&mpc5200_pic>;
> @@ -38,7 +39,6 @@ Examples :
> i2c@3100 {
> #address-cells = <1>;
> #size-cells = <0>;
> - cell-index = <1>;
> compatible = "fsl,mpc8544-i2c", "fsl-i2c";
> reg = <0x3100 0x100>;
> interrupts = <43 2>;
> --
> 1.6.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] i2c-mpc: add support for the MPC512x processors from Freescale
From: Wolfram Sang @ 2010-01-25 11:52 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Devicetree-discuss, Linuxppc-dev, Linux-i2c, Wolfgang Grandegger
In-Reply-To: <1264408029-5290-3-git-send-email-wg@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 10200 bytes --]
Hi Wolfgang,
On Mon, Jan 25, 2010 at 09:27:08AM +0100, Wolfgang Grandegger wrote:
> From: Wolfgang Grandegger <wg@denx.de>
>
> The "setclock" initialization functions have been renamed to "setup"
> because I2C interrupts must be enabled for the MPC512x. This requires
> to handle "fsl,preserve-clocking" in a slighly different way. Also,
> the old settings are now reported calling dev_dbg(). For the MPC512x
> the clock setup function of the MPC52xx can be re-used.
>
> Signed-off-by: Wolfgang Grandegger <wg@denx.de>
> ---
> drivers/i2c/busses/Kconfig | 9 ++--
> drivers/i2c/busses/i2c-mpc.c | 122 ++++++++++++++++++++++++++++++------------
> 2 files changed, 93 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 5f318ce..f481f30 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -418,13 +418,14 @@ config I2C_IXP2000
> instead.
>
> config I2C_MPC
> - tristate "MPC107/824x/85xx/52xx/86xx"
> + tristate "MPC107/824x/85xx/512x/52xx/86xx"
> depends on PPC32
> help
> If you say yes to this option, support will be included for the
> - built-in I2C interface on the MPC107/Tsi107/MPC8240/MPC8245 and
> - MPC85xx/MPC8641 family processors. The driver may also work on 52xx
> - family processors, though interrupts are known not to work.
> + built-in I2C interface on the MPC107/Tsi107/MPC8240/MPC8245,
> + MPC85xx/MPC8641 and MPC512x family processors. The driver may
> + also work on 52xx family processors, though interrupts are known
> + not to work.
Opinion poll: Can we remove the "may work" sentence while we are here? It has
worked fine for years. BTW, which interrupts are meant here (from I2C slaves?
interrupts of the controller?)?
>
> This driver can also be built as a module. If so, the module
> will be called i2c-mpc.
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index 2cb864e..70c3e5d 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -67,9 +67,8 @@ struct mpc_i2c_divider {
> };
>
> struct mpc_i2c_data {
> - void (*setclock)(struct device_node *node,
> - struct mpc_i2c *i2c,
> - u32 clock, u32 prescaler);
> + void (*setup)(struct device_node *node, struct mpc_i2c *i2c,
> + u32 clock, u32 prescaler);
> u32 prescaler;
> };
>
> @@ -164,7 +163,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> return 0;
> }
>
> -#ifdef CONFIG_PPC_MPC52xx
> +#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
> static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
> {20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
> {28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
> @@ -216,12 +215,18 @@ static int __devinit mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock,
> return div ? (int)div->fdr : -EINVAL;
> }
>
> -static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
> - struct mpc_i2c *i2c,
> - u32 clock, u32 prescaler)
> +static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
> + struct mpc_i2c *i2c,
> + u32 clock, u32 prescaler)
> {
> int ret, fdr;
>
> + if (clock == -1) {
Could we use 0 for 'no_clock'? This would make the above statement simply
if (!clock)
and saves us using -1 with a u32.
> + dev_dbg(i2c->dev, "using fdr %d\n",
> + readb(i2c->base + MPC_I2C_FDR));
> + return; /* preserve clocking */
> + }
> +
> ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler);
> fdr = (ret >= 0) ? ret : 0x3f; /* backward compatibility */
>
> @@ -230,13 +235,50 @@ static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
> if (ret >= 0)
> dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
> }
> -#else /* !CONFIG_PPC_MPC52xx */
> -static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
> - struct mpc_i2c *i2c,
> - u32 clock, u32 prescaler)
> +#else /* !(CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x) */
> +static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
> + struct mpc_i2c *i2c,
> + u32 clock, u32 prescaler)
> +{
> +}
> +#endif /* CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x */
> +
> +#ifdef CONFIG_PPC_MPC512x
> +static void __devinit mpc_i2c_setup_512x(struct device_node *node,
> + struct mpc_i2c *i2c,
> + u32 clock, u32 prescaler)
> +{
> + struct device_node *node_ctrl;
> + void __iomem *ctrl;
> + const u32 *pval;
> + u32 idx;
> +
> + /* Enable I2C interrupts for mpc5121 */
> + node_ctrl = of_find_compatible_node(NULL, NULL,
> + "fsl,mpc5121-i2c-ctrl");
> + if (node_ctrl) {
> + ctrl = of_iomap(node_ctrl, 0);
> + if (ctrl) {
> +
> + /* Interrupt enable bits for i2c-0/1/2: bit 24/26/28 */
> + pval = of_get_property(node, "reg", NULL);
> + idx = (*pval & 0xff) / 0x20;
> + setbits32(ctrl, 1 << (24 + idx * 2));
> + iounmap(ctrl);
> + }
> + of_node_put(node_ctrl);
> + }
> +
> + /* The clock setup for the 52xx works also fine for the 512x */
> + mpc_i2c_setup_52xx(node, i2c, clock, prescaler);
> +}
> +#else /* CONFIG_PPC_MPC512x */
> +static void __devinit mpc_i2c_setup_512x(struct device_node *node,
> + struct mpc_i2c *i2c,
> + u32 clock, u32 prescaler)
> {
> }
> -#endif /* CONFIG_PPC_MPC52xx*/
> +#endif /* CONFIG_PPC_MPC512x */
>
> #ifdef CONFIG_FSL_SOC
> static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
> @@ -322,12 +364,19 @@ static int __devinit mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock,
> return div ? (int)div->fdr : -EINVAL;
> }
>
> -static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
> - struct mpc_i2c *i2c,
> - u32 clock, u32 prescaler)
> +static void __devinit mpc_i2c_setup_8xxx(struct device_node *node,
> + struct mpc_i2c *i2c,
> + u32 clock, u32 prescaler)
> {
> int ret, fdr;
>
> + if (clock == -1) {
> + dev_dbg(i2c->dev, "using dfsrr %d, fdr %d\n",
> + readb(i2c->base + MPC_I2C_DFSRR),
> + readb(i2c->base + MPC_I2C_FDR));
> + return; /* preserve clocking */
> + }
> +
> ret = mpc_i2c_get_fdr_8xxx(node, clock, prescaler);
> fdr = (ret >= 0) ? ret : 0x1031; /* backward compatibility */
>
> @@ -340,9 +389,9 @@ static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
> }
>
> #else /* !CONFIG_FSL_SOC */
> -static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
> - struct mpc_i2c *i2c,
> - u32 clock, u32 prescaler)
> +static void __devinit mpc_i2c_setup_8xxx(struct device_node *node,
> + struct mpc_i2c *i2c,
> + u32 clock, u32 prescaler)
> {
> }
> #endif /* CONFIG_FSL_SOC */
> @@ -525,21 +574,21 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
> }
> }
>
> - if (!of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
> + if (of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
> + clock = -1;
> + } else {
> prop = of_get_property(op->node, "clock-frequency", &plen);
> if (prop && plen == sizeof(u32))
> clock = *prop;
> + }
>
> - if (match->data) {
> - struct mpc_i2c_data *data =
> - (struct mpc_i2c_data *)match->data;
> - data->setclock(op->node, i2c, clock, data->prescaler);
> - } else {
> - /* Backwards compatibility */
> - if (of_get_property(op->node, "dfsrr", NULL))
> - mpc_i2c_setclock_8xxx(op->node, i2c,
> - clock, 0);
> - }
> + if (match->data) {
> + struct mpc_i2c_data *data = (struct mpc_i2c_data *)match->data;
The cast should not be necessary.
> + data->setup(op->node, i2c, clock, data->prescaler);
> + } else {
> + /* Backwards compatibility */
> + if (of_get_property(op->node, "dfsrr", NULL))
> + mpc_i2c_setup_8xxx(op->node, i2c, clock, 0);
> }
>
> dev_set_drvdata(&op->dev, i2c);
> @@ -585,20 +634,24 @@ static int __devexit fsl_i2c_remove(struct of_device *op)
> };
>
> static struct mpc_i2c_data __devinitdata mpc_i2c_data_52xx = {
> - .setclock = mpc_i2c_setclock_52xx,
> + .setup = mpc_i2c_setup_52xx,
> +};
> +
> +static struct mpc_i2c_data __devinitdata mpc_i2c_data_512x = {
> + .setup = mpc_i2c_setup_512x,
> };
>
> static struct mpc_i2c_data __devinitdata mpc_i2c_data_8313 = {
> - .setclock = mpc_i2c_setclock_8xxx,
> + .setup = mpc_i2c_setup_8xxx,
> };
>
> static struct mpc_i2c_data __devinitdata mpc_i2c_data_8543 = {
> - .setclock = mpc_i2c_setclock_8xxx,
> + .setup = mpc_i2c_setup_8xxx,
> .prescaler = 2,
> };
>
> static struct mpc_i2c_data __devinitdata mpc_i2c_data_8544 = {
> - .setclock = mpc_i2c_setclock_8xxx,
> + .setup = mpc_i2c_setup_8xxx,
> .prescaler = 3,
> };
>
> @@ -606,6 +659,7 @@ static const struct of_device_id mpc_i2c_of_match[] = {
> {.compatible = "mpc5200-i2c", .data = &mpc_i2c_data_52xx, },
> {.compatible = "fsl,mpc5200b-i2c", .data = &mpc_i2c_data_52xx, },
> {.compatible = "fsl,mpc5200-i2c", .data = &mpc_i2c_data_52xx, },
> + {.compatible = "fsl,mpc5121-i2c", .data = &mpc_i2c_data_512x, },
> {.compatible = "fsl,mpc8313-i2c", .data = &mpc_i2c_data_8313, },
> {.compatible = "fsl,mpc8543-i2c", .data = &mpc_i2c_data_8543, },
> {.compatible = "fsl,mpc8544-i2c", .data = &mpc_i2c_data_8544, },
> @@ -648,5 +702,5 @@ module_exit(fsl_i2c_exit);
>
> MODULE_AUTHOR("Adrian Cox <adrian@humboldt.co.uk>");
> MODULE_DESCRIPTION("I2C-Bus adapter for MPC107 bridge and "
> - "MPC824x/85xx/52xx processors");
> + "MPC824x/85xx/512x/52xx processors");
> MODULE_LICENSE("GPL");
> --
> 1.6.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Johnny Hung @ 2010-01-25 8:43 UTC (permalink / raw)
To: chris
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, Marco Stornelli,
kernelnewbies, linux-mtd@lists.infradead.org, Matthias Kaehlcke,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4B5D560E.2020901@2net.co.uk>
2010/1/25 Chris Simmonds <chris@2net.co.uk>:
> Johnny Hung wrote:
>>
>> 2010/1/22 Marco Stornelli <marco.stornelli@gmail.com>:
>>>
>>> 2010/1/22 Johnny Hung <johnny.hacking@gmail.com>:
>>>>
>>>> 2010/1/20 Marco Stornelli <marco.stornelli@gmail.com>:
>>>>>
>>>>> 2010/1/20 Johnny Hung <johnny.hacking@gmail.com>:
>>>>>>
>>>>>> 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
>>>>>>>
>>>>>>> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>>>>>>>
>>>>>> I consider to use ramdisk as rootfs because worry about wrong
>>>>>> operation in rootfs (is use jffs2 rootfs) and it will cause system
>>>>>> boot up failed.
>>>>>> Another query, does the syslogd/klogd log files also store in jffs2
>>>>>> rootfs? Write to jffs2 frequently will reduce flash life cycle.
>>>>>>
>>>>>> BRs, H. Johnny
>>>>>>>
>>>>>>> --
>>>>
>>>> It seems there are a lot of file-systems I have to study :P. The same
>>>> question is
>>>> how to split my rootfs? Re-mount /etc, /var to another file-sysyem mtd
>>>> part when
>>>> system boot up?
>>>>
>> Yes, I know. So if I want set etc directoyr to /dev/mtd5 not in rootfs
>> /, I need to add "/dev/mtdblock5 =A0/etc =A0 =A0 =A0 =A0jffs2 =A0 defaul=
ts
>> 0 =A0 =A0 =A0 0" in /etc/fstab file but rootfs doesn't contain /etc
>> directory because /etc directoyr is store in /dev/mtdblock5.
>> Do you know what I mean? The kernel execute /sbin/init after mount
>> rootfs and /sbin/init is link to busybox, busybox will read
>> /etc/inittab file to initial. The problem is coming, how busybox to
>> read /etc in rootfs before mount /dev/mtdblock5 to /etc? There is no
>> program to mount /dev/mtdblock5 to /etc before busybox init execute.
>>
>> I think I must mistake some concept, please give me a hint.
>> Thank you
>> BRs, H. Johnny
>>
>
I got it. The rootfs contains at least /etc directory, /etc/inittab,
/etc/fstab. Bysybox will read /etc/fstab to mount etc to rootfs's etc
from other partition. Okay, it's reasonable. Another query, how to do
it in many Linux dist as Macro mentioned, use initramfs ? I am sure I
can arrange / to /dev/hda1 and /etc to /dev/hda2.
Thank you so much
BRs, H. Johnny
> You have two /etc directories: one in the the read-only root file system =
and
> one in the jffs2 fs. In the root fs you have /etc/fstab, /etc/inittab and
> any scripts it may call. The init program will mount /dev/mtdblock5 over =
the
> top of the /etc that is in the rootfs, so giving you the read/write versi=
on
> of /etc. Any files open in the old /etc - e.g. /etc/inittab - will contin=
ue
> to be open, but any new files opened in /etc will use the read/write vers=
ion
> in jffs2. You can also do some interesting things with symbolic links...
> This technique works. I have used it in several projects.
>
> --
> Chris Simmonds =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2net Limited
> chris@2net.co.uk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.2net.co.uk/
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox