* 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
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Chris Simmonds @ 2010-01-25 8:27 UTC (permalink / raw)
To: Johnny Hung
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: <cb9ecdfa1001242009x30eabcd3gbd0bb1d8a931199e@mail.gmail.com>
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 /etc jffs2 defaults
> 0 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
>
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 version of /etc. Any files open in the old /etc -
e.g. /etc/inittab - will continue to be open, but any new files opened
in /etc will use the read/write version in jffs2. You can also do some
interesting things with symbolic links... This technique works. I have
used it in several projects.
--
Chris Simmonds 2net Limited
chris@2net.co.uk http://www.2net.co.uk/
^ permalink raw reply
* [PATCH 3/3] powerpc: doc/dts-bindings: update doc of FSL I2C bindings
From: Wolfgang Grandegger @ 2010-01-25 8:27 UTC (permalink / raw)
To: Linux-i2c; +Cc: Devicetree-discuss, Linuxppc-dev, Wolfgang Grandegger
In-Reply-To: <1264408029-5290-3-git-send-email-wg@grandegger.com>
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.
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
^ permalink raw reply related
* [PATCH 2/3] i2c-mpc: add support for the MPC512x processors from Freescale
From: Wolfgang Grandegger @ 2010-01-25 8:27 UTC (permalink / raw)
To: Linux-i2c; +Cc: Devicetree-discuss, Linuxppc-dev, Wolfgang Grandegger
In-Reply-To: <1264408029-5290-2-git-send-email-wg@grandegger.com>
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.
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) {
+ 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;
+ 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
^ permalink raw reply related
* [PATCH 1/3] i2c-mpc: use __devinit[data] for initialization functions and data
From: Wolfgang Grandegger @ 2010-01-25 8:27 UTC (permalink / raw)
To: Linux-i2c; +Cc: Devicetree-discuss, Linuxppc-dev, Wolfgang Grandegger
In-Reply-To: <1264408029-5290-1-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@denx.de>
"__devinit[data]" has not yet been used for all initialization functions
and data. To avoid truncating lines, the struct mpc_i2c_match_data has
been renamed to mpc_i2c_data, which is even the better name.
Signed-off-by: Wolfgang Grandegger <wg@denx.de>
---
drivers/i2c/busses/i2c-mpc.c | 99 +++++++++++++++++++----------------------
1 files changed, 46 insertions(+), 53 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index f627001..2cb864e 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -66,7 +66,7 @@ struct mpc_i2c_divider {
u16 fdr; /* including dfsrr */
};
-struct mpc_i2c_match_data {
+struct mpc_i2c_data {
void (*setclock)(struct device_node *node,
struct mpc_i2c *i2c,
u32 clock, u32 prescaler);
@@ -165,7 +165,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
}
#ifdef CONFIG_PPC_MPC52xx
-static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
+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},
{36, 0x26}, {40, 0x27}, {44, 0x04}, {48, 0x28},
@@ -186,7 +186,8 @@ static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{10240, 0x9d}, {12288, 0x9e}, {15360, 0x9f}
};
-int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
+static int __devinit mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock,
+ int prescaler)
{
const struct mpc_i2c_divider *div = NULL;
unsigned int pvr = mfspr(SPRN_PVR);
@@ -215,9 +216,9 @@ int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
return div ? (int)div->fdr : -EINVAL;
}
-static void mpc_i2c_setclock_52xx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
int ret, fdr;
@@ -230,15 +231,15 @@ static void mpc_i2c_setclock_52xx(struct device_node *node,
dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
}
#else /* !CONFIG_PPC_MPC52xx */
-static void mpc_i2c_setclock_52xx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
}
#endif /* CONFIG_PPC_MPC52xx*/
#ifdef CONFIG_FSL_SOC
-static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
+static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
{160, 0x0120}, {192, 0x0121}, {224, 0x0122}, {256, 0x0123},
{288, 0x0100}, {320, 0x0101}, {352, 0x0601}, {384, 0x0102},
{416, 0x0602}, {448, 0x0126}, {480, 0x0103}, {512, 0x0127},
@@ -258,7 +259,7 @@ static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
{49152, 0x011e}, {61440, 0x011f}
};
-u32 mpc_i2c_get_sec_cfg_8xxx(void)
+static u32 __devinit mpc_i2c_get_sec_cfg_8xxx(void)
{
struct device_node *node = NULL;
u32 __iomem *reg;
@@ -287,7 +288,8 @@ u32 mpc_i2c_get_sec_cfg_8xxx(void)
return val;
}
-int mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock, u32 prescaler)
+static int __devinit mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock,
+ u32 prescaler)
{
const struct mpc_i2c_divider *div = NULL;
u32 divider;
@@ -320,9 +322,9 @@ int mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock, u32 prescaler)
return div ? (int)div->fdr : -EINVAL;
}
-static void mpc_i2c_setclock_8xxx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
int ret, fdr;
@@ -338,9 +340,9 @@ static void mpc_i2c_setclock_8xxx(struct device_node *node,
}
#else /* !CONFIG_FSL_SOC */
-static void mpc_i2c_setclock_8xxx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
}
#endif /* CONFIG_FSL_SOC */
@@ -529,8 +531,8 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
clock = *prop;
if (match->data) {
- struct mpc_i2c_match_data *data =
- (struct mpc_i2c_match_data *)match->data;
+ struct mpc_i2c_data *data =
+ (struct mpc_i2c_data *)match->data;
data->setclock(op->node, i2c, clock, data->prescaler);
} else {
/* Backwards compatibility */
@@ -582,44 +584,35 @@ static int __devexit fsl_i2c_remove(struct of_device *op)
return 0;
};
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_52xx = {
+ .setclock = mpc_i2c_setclock_52xx,
+};
+
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_8313 = {
+ .setclock = mpc_i2c_setclock_8xxx,
+};
+
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_8543 = {
+ .setclock = mpc_i2c_setclock_8xxx,
+ .prescaler = 2,
+};
+
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_8544 = {
+ .setclock = mpc_i2c_setclock_8xxx,
+ .prescaler = 3,
+};
+
static const struct of_device_id mpc_i2c_of_match[] = {
- {.compatible = "mpc5200-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_52xx,
- },
- },
- {.compatible = "fsl,mpc5200b-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_52xx,
- },
- },
- {.compatible = "fsl,mpc5200-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_52xx,
- },
- },
- {.compatible = "fsl,mpc8313-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_8xxx,
- },
- },
- {.compatible = "fsl,mpc8543-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_8xxx,
- .prescaler = 2,
- },
- },
- {.compatible = "fsl,mpc8544-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_8xxx,
- .prescaler = 3,
- },
+ {.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,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, },
/* Backward compatibility */
- },
{.compatible = "fsl-i2c", },
{},
};
-
MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
--
1.6.2.5
^ permalink raw reply related
* [PATCH 0/3] i2c-mpc: add support for the Freescale MPC512x and other fixes
From: Wolfgang Grandegger @ 2010-01-25 8:27 UTC (permalink / raw)
To: Linux-i2c; +Cc: Devicetree-discuss, Linuxppc-dev
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
Wolfgang
Wolfgang Grandegger (3):
i2c-mpc: use __devinit[data] for initialization functions and data
i2c-mpc: add support for the MPC512x processors from Freescale
powerpc: doc/dts-bindings: update doc of FSL I2C bindings
Documentation/powerpc/dts-bindings/fsl/i2c.txt | 10 +-
drivers/i2c/busses/Kconfig | 9 +-
drivers/i2c/busses/i2c-mpc.c | 185 +++++++++++++++---------
3 files changed, 126 insertions(+), 78 deletions(-)
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Joakim Tjernlund @ 2010-01-25 8:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, Andrew Morton, David Woodhouse
In-Reply-To: <1263459431.724.352.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2010/01/14 09:57:11:
>
>
> > Seen it now as it is in Linus tree:
> >
> > 1) IMHO it would have been nicer to use #ifdef __KERNEL__
> > instead of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > as then arches that don't define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > at all will never use the new optimization or was that what you intended?
>
> No, that was on purpose. If an arch doesn't have efficient unaligned
> accesses, then they should not use the optimization since it will result
> in a lot of unaligned accesses :-) In which case they are better off
> falling back to the old byte-by-byte method.
>
> The advantage also of doing it this way is that x86 will benefit from
> the optimisation at boot time since it does include autoconf.h in its
> boot wrapper (and deals with unaligned accesses just fine at any time)
> though something tells me that it won't make much of a difference in
> performances on any recent x86 (it might on some of the newer low power
> embedded ones, I don't know for sure).
>
> > 2) You really should add an comment in the Makefile about not using
> > autoconf.h/-D__KERNEL__
>
> That's true :-)
So I fixed the new inflate to be endian independent and now
all arches can use the optimized version. Here goes:
>From 4e769486e2520e34f532a2d4bf13ab13f05e3e76 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Sun, 24 Jan 2010 11:12:56 +0100
Subject: [PATCH] zlib: Make new optimized inflate endian independent
Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the
new optimized inflate only available on arch's that
define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This
fixes it by defining our own endian independent versions
of unaligned access.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
lib/zlib_inflate/inffast.c | 70 +++++++++++++++++++-------------------------
1 files changed, 30 insertions(+), 40 deletions(-)
diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
index 215447c..5de16f4 100644
--- a/lib/zlib_inflate/inffast.c
+++ b/lib/zlib_inflate/inffast.c
@@ -8,21 +8,6 @@
#include "inflate.h"
#include "inffast.h"
-/* Only do the unaligned "Faster" variant when
- * CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set
- *
- * On powerpc, it won't be as we don't include autoconf.h
- * automatically for the boot wrapper, which is intended as
- * we run in an environment where we may not be able to deal
- * with (even rare) alignment faults. In addition, we do not
- * define __KERNEL__ for arch/powerpc/boot unlike x86
- */
-
-#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
-#include <asm/unaligned.h>
-#include <asm/byteorder.h>
-#endif
-
#ifndef ASMINF
/* Allow machine dependent optimization for post-increment or pre-increment.
@@ -36,14 +21,31 @@
- Pentium III (Anderson)
- M68060 (Nikl)
*/
+union uu {
+ unsigned short us;
+ unsigned char b[2];
+};
+
+/* Endian independed version */
+static inline unsigned short
+get_unaligned16(const unsigned short *p)
+{
+ union uu mm;
+ unsigned char *b = (unsigned char *)p;
+
+ mm.b[0] = b[0];
+ mm.b[1] = b[1];
+ return mm.us;
+}
+
#ifdef POSTINC
# define OFF 0
# define PUP(a) *(a)++
-# define UP_UNALIGNED(a) get_unaligned((a)++)
+# define UP_UNALIGNED(a) get_unaligned16((a)++)
#else
# define OFF 1
# define PUP(a) *++(a)
-# define UP_UNALIGNED(a) get_unaligned(++(a))
+# define UP_UNALIGNED(a) get_unaligned16(++(a))
#endif
/*
@@ -256,7 +258,6 @@ void inflate_fast(z_streamp strm, unsigned start)
}
}
else {
-#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
unsigned short *sout;
unsigned long loops;
@@ -274,7 +275,11 @@ void inflate_fast(z_streamp strm, unsigned start)
sfrom = (unsigned short *)(from - OFF);
loops = len >> 1;
do
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+ PUP(sout) = PUP(sfrom);
+#else
PUP(sout) = UP_UNALIGNED(sfrom);
+#endif
while (--loops);
out = (unsigned char *)sout + OFF;
from = (unsigned char *)sfrom + OFF;
@@ -282,14 +287,13 @@ void inflate_fast(z_streamp strm, unsigned start)
unsigned short pat16;
pat16 = *(sout-2+2*OFF);
- if (dist == 1)
-#if defined(__BIG_ENDIAN)
- pat16 = (pat16 & 0xff) | ((pat16 & 0xff) << 8);
-#elif defined(__LITTLE_ENDIAN)
- pat16 = (pat16 & 0xff00) | ((pat16 & 0xff00) >> 8);
-#else
-#error __BIG_ENDIAN nor __LITTLE_ENDIAN is defined
-#endif
+ if (dist == 1) {
+ union uu mm;
+ /* copy one char pattern to both bytes */
+ mm.us = pat16;
+ mm.b[0] = mm.b[1];
+ pat16 = mm.us;
+ }
loops = len >> 1;
do
PUP(sout) = pat16;
@@ -298,20 +302,6 @@ void inflate_fast(z_streamp strm, unsigned start)
}
if (len & 1)
PUP(out) = PUP(from);
-#else /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
- from = out - dist; /* copy direct from output */
- do { /* minimum length is three */
- PUP(out) = PUP(from);
- PUP(out) = PUP(from);
- PUP(out) = PUP(from);
- len -= 3;
- } while (len > 2);
- if (len) {
- PUP(out) = PUP(from);
- if (len > 1)
- PUP(out) = PUP(from);
- }
-#endif /* !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
}
}
else if ((op & 64) == 0) { /* 2nd level distance code */
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH/RFC 2/2] 5200: improve i2c bus error recovery
From: Wolfgang Grandegger @ 2010-01-25 7:55 UTC (permalink / raw)
To: Albrecht Dreß
Cc: Linux PPC Development, Devicetree Discussions,
Ben Dooks (embedded platforms)
In-Reply-To: <1264191502.2224.2@antares>
Albrecht Dreß wrote:
> Make the I2C adapter timeout configurable through a Device Tree property
> which gives the timeout in microseconds.
My understanding is that software properties should not be defined via
the device tree. I think a sysfs entry is more appropriate.
Wolfgang.
^ permalink raw reply
* Re: [PATCH/RFC 1/2] 5200: improve i2c bus error recovery
From: Ben Dooks @ 2010-01-25 4:06 UTC (permalink / raw)
To: Albrecht Dreß
Cc: Linux PPC Development, Devicetree Discussions,
Ben Dooks (embedded platforms)
In-Reply-To: <1264191475.2224.1@antares>
On Fri, Jan 22, 2010 at 09:17:55PM +0100, Albrecht Dreß wrote:
> Improve the recovery of the MPC5200B's I2C bus from errors like bus
> hangs.
This is very sparse comapred to the large comment below the --- line,
maybe some more description should be living up here.
Is thios a candidate for an -rc or should it be left to merge window?
> Signed-off-by: Albrecht Dreß <albrecht.dress@arcor.de>
>
> ---
>
> This patch introduces several improvements to the MPC5200B's I2C driver
> as to improve the recovery from error conditions I encountered when
> testing a custom board with several I2C devices attached (eeprom, io
> expander, rtc, sensors). The error conditions included cases where the
> bus if logic of one slave apparently went south, blocking the bus
> completely.
>
> My fixes include:
> 1. make the bus timeout configurable in fsl_i2c_probe(); the default of
> one second is *way* too long for my use case;
> 2. if a timeout condition occurs in mpc_xfer(), mpc_i2c_fixup() the bus
> if *any* of the CF, BB and RXAK flags in the MSR is 1. I actually
> saw different combinations with hangs, not only all three set;
> 3. improve the fixup procedure by calculating the timing needed from the
> real (configured) bus clock, calculated in mpc_i2c_setclock_52xx().
> Furthermore, I issue 9 instead of one cycle, as I experienced cases
> where the single one is not enough (found this tip in a forum). As a
> side effect, the new scheme needs only 81us @375kHz bus clock instead
> of 150us. I recorded waveforms for 18.4kHz, 85.9kHz and 375kHz, all
> looking fine, which I can provide if anyone is interested.
>
> Open questions:
> - is the approach correct at all, in particular the interpretation of
> the flags (#2)?
> - could this code also be used on non-5200 processors?
>
> --- linux-2.6.32-orig/drivers/i2c/busses/i2c-mpc.c 2009-12-03 04:51:21.000000000 +0100
> +++ linux-2.6.32/drivers/i2c/busses/i2c-mpc.c 2010-01-22 16:05:13.000000000 +0100
> @@ -59,6 +59,7 @@ struct mpc_i2c {
> wait_queue_head_t queue;
> struct i2c_adapter adap;
> int irq;
> + u32 real_clk;
> };
>
> struct mpc_i2c_divider {
> @@ -97,16 +98,32 @@ static irqreturn_t mpc_i2c_isr(int irq,
> */
> static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> {
> - writeccr(i2c, 0);
> - udelay(30);
> - writeccr(i2c, CCR_MEN);
> - udelay(30);
> - writeccr(i2c, CCR_MSTA | CCR_MTX);
> - udelay(30);
> - writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> - udelay(30);
> - writeccr(i2c, CCR_MEN);
> - udelay(30);
> + if (i2c->real_clk == 0) {
> + writeccr(i2c, 0);
> + udelay(30);
> + writeccr(i2c, CCR_MEN);
> + udelay(30);
> + writeccr(i2c, CCR_MSTA | CCR_MTX);
> + udelay(30);
> + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> + udelay(30);
> + writeccr(i2c, CCR_MEN);
> + udelay(30);
> + } else {
> + int k;
> + u32 delay_val = 1000000 / i2c->real_clk + 1;
> +
> + if (delay_val < 2)
> + delay_val = 2;
> +
> + for (k = 9; k; k--) {
> + writeccr(i2c, 0);
> + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> + udelay(delay_val);
> + writeccr(i2c, CCR_MEN);
> + udelay(delay_val << 1);
> + }
> + }
> }
>
> static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> @@ -186,15 +203,18 @@ static const struct mpc_i2c_divider mpc_
> {10240, 0x9d}, {12288, 0x9e}, {15360, 0x9f}
> };
>
> -int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
> +int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler,
> + u32 *real_clk)
> {
> const struct mpc_i2c_divider *div = NULL;
> unsigned int pvr = mfspr(SPRN_PVR);
> u32 divider;
> int i;
>
> - if (!clock)
> + if (!clock) {
> + *real_clk = 0;
> return -EINVAL;
> + }
>
> /* Determine divider value */
> divider = mpc5xxx_get_bus_frequency(node) / clock;
> @@ -212,7 +232,8 @@ int mpc_i2c_get_fdr_52xx(struct device_n
> break;
> }
>
> - return div ? (int)div->fdr : -EINVAL;
> + *real_clk = mpc5xxx_get_bus_frequency(node) / div->divider;
> + return (int)div->fdr;
> }
>
> static void mpc_i2c_setclock_52xx(struct device_node *node,
> @@ -221,13 +242,14 @@ static void mpc_i2c_setclock_52xx(struct
> {
> int ret, fdr;
>
> - ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler);
> + ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler, &i2c->real_clk);
> fdr = (ret >= 0) ? ret : 0x3f; /* backward compatibility */
>
> writeb(fdr & 0xff, i2c->base + MPC_I2C_FDR);
>
> if (ret >= 0)
> - dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
> + dev_info(i2c->dev, "clock %u Hz (fdr=%d)\n", i2c->real_clk,
> + fdr);
> }
> #else /* !CONFIG_PPC_MPC52xx */
> static void mpc_i2c_setclock_52xx(struct device_node *node,
> @@ -446,10 +468,14 @@ static int mpc_xfer(struct i2c_adapter *
> return -EINTR;
> }
> if (time_after(jiffies, orig_jiffies + HZ)) {
> + u8 status = readb(i2c->base + MPC_I2C_SR);
> +
> dev_dbg(i2c->dev, "timeout\n");
> - if (readb(i2c->base + MPC_I2C_SR) ==
> - (CSR_MCF | CSR_MBB | CSR_RXAK))
> + if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) != 0) {
> + writeb(status & ~CSR_MAL,
> + i2c->base + MPC_I2C_SR);
> mpc_i2c_fixup(i2c);
> + }
> return -EIO;
> }
> schedule();
> @@ -540,6 +566,14 @@ static int __devinit fsl_i2c_probe(struc
> }
> }
>
> + prop = of_get_property(op->node, "timeout", &plen);
> + if (prop && plen == sizeof(u32)) {
> + mpc_ops.timeout = *prop * HZ / 1000000;
> + if (mpc_ops.timeout < 5)
> + mpc_ops.timeout = 5;
> + }
> + dev_info(i2c->dev, "timeout %u us\n", mpc_ops.timeout * 1000000 / HZ);
> +
> dev_set_drvdata(&op->dev, i2c);
>
> i2c->adap = mpc_ops;
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Johnny Hung @ 2010-01-25 4:09 UTC (permalink / raw)
To: Marco Stornelli
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, kernelnewbies,
linux-mtd@lists.infradead.org, Matthias Kaehlcke,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2ea1731b1001220014v59ea7767m6e1a8547d41c6afb@mail.gmail.com>
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 /etc jffs2 defaults
0 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
> Simply, you can mount each mount point with the fstab file and a
> script, same approach of every linux distribution, nothing more. Even
> in the pc world you can mount your /home on a partition with ext3,
> /var in a partition with ext4, and so on. A very simple approach to
> setup the system, it is to start with NFS for example with "whole" fs,
> copy what you need in the right place, setup the start-up script and
> reboot.
>
> Marco
>
^ permalink raw reply
* Re: [RFC,PATCH 3/7 v2] arm/versatile: use generic struct clk
From: Jeremy Kerr @ 2010-01-25 0:35 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <20100112162539.GH27771@n2100.arm.linux.org.uk>
Hi Russell,
> This doesn't make any sense. What are you trying to do here?
>
> The get/put operations go together as one logical set - that's why you
> get both if you're using clkdev, and why you're asked to implement both
> __clk_get() and __clk_put() in arch code to do whatever's necessary
> with the clock.
I'm assuming that clk_put will be specific to the implementation; fixed clocks
probably won't need to do anything, but others may need a refcount, etc.
We don't have a struct clk to use clk_get on, so it remains a non-clock-
specific function.
We'll probably need the symmetry for some cases though, I think that a
__clk_get(struct clk *) member of clk_operations would work for this, to be
called by clk_get.
Cheers,
Jeremy
^ permalink raw reply
* Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
From: Benjamin Herrenschmidt @ 2010-01-24 20:32 UTC (permalink / raw)
To: prasad; +Cc: linuxppc-dev, David Gibson, shaggy, Frederic Weisbecker
In-Reply-To: <20100124191830.GB14075@in.ibm.com>
On Mon, 2010-01-25 at 00:48 +0530, K.Prasad wrote:
>
> Some of the benefits of using these generic interfaces include:
> - Interoperability with other users of debug register (such as
> parallel
> kernel requests) i.e. non-exclusive use of debug registers.
> - Enables debugging/tracing tools such as perf-events and ftrace to
> make
> use of debug registers.
> - Re-use of common code available in kernel (kernel/hw_breakpoint.c).
>
> Let me know what you think.
This might have changed but last I looked the "generic" breakpoint
interface was still too x86-centric and wasn't capable of expressing
some of the features of the BookE debug register set such as the data
value compare, the ranged breakpoints, etc...
I'd rather have this more dedicated and more complete interface merged
for gdb's sake, and in a second step look at unifying.
I believe that the generic breakpoint infrastructure should not be the
mid-layer. IE. It cannot be made in any clean shape of form, to express
all of the subtle features that a given architecture or platform can
support and as such would always be inferior to a dedicated one.
I can see the interest in exposing some kind of generic API that
implements a common subset of breakpoint or watchpoint facilities to
generic code such as the event tracer. This could be layered on top of
an arch specific mechanism
But having the generic mechanism at the core for everybody is another
attempt of "make everybody look like x86" which I believe in this case
is sub optimal.
Again, I might have missed some evolutions of the latest versions of
your infrastructure that would make it good enough to fully bridge the
gap with our requirements, and I'll let Shaggy decide here what he wants
to do. But I will not block his current patches neither if he thinks
that they are good enough as is.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
From: K.Prasad @ 2010-01-24 19:18 UTC (permalink / raw)
To: shaggy, linuxppc-dev
Cc: Frederic Weisbecker, Benjamin Herrenschmidt, David Gibson
>From shaggy at linux.vnet.ibm.com Tue Jan 19 08:57:04 2010
From: shaggy at linux.vnet.ibm.com (Dave Kleikamp)
Date: Mon, 18 Jan 2010 14:57:04 -0700
Subject: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through
extended ptrace interface
Message-ID: <20100118215704.15684.60646.sendpatchset@norville.austin.ibm.com>
> These patches implement an extention to the ptrace interface proposed by
> Thiago Bauermann and the the PowerPC gdb team.
(Using the plain text from mail archive..mail may not be in the usual
mail-reply format...kindly bear).
Hi,
First of all, thanks for bringing this patch that puts the debug
registers in BookE to good use! I learnt about this patch submission
only recently...please see some of my concerns as under.
Given that there now exists generic kernel interfaces to use
hw-breakpoints - register_user_hw_breakpoint() and
unregister_hw_breakpoint() (available in mainline since 2.6.33-rc1), it
would be prudent to use them for the ptrace requests (that are made in
arch_ptrace()).
This would mean that some of the arch-specific debug register code that
read/write from/to the debug registers of Book-E may have to be in a
form that closely resembles arch/<x86><power>/kernel/hw_breakpoint.c
A patch that enables arch-specific code for PPC64 is already submitted
(linuxppc-dev ref: 20100121084640.GA3252@in.ibm.com). This converts
ptrace requests for PTRACE_<GET><SET>_DEBUGREG flags to use the
above-mentioned interfaces for PPC64.
If you intend to re-write this patch to use the generic hw-breakpoint
interfaces (which I strongly recommend you to do, for the reasons mentioned
below), I would be more than glad to help you port them.
Some of the benefits of using these generic interfaces include:
- Interoperability with other users of debug register (such as parallel
kernel requests) i.e. non-exclusive use of debug registers.
- Enables debugging/tracing tools such as perf-events and ftrace to make
use of debug registers.
- Re-use of common code available in kernel (kernel/hw_breakpoint.c).
Let me know what you think.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver
From: Wolfgang Denk @ 2010-01-24 16:41 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Arnd Bergmann, dzu, netdev, linuxppc-dev, agust, linuxppc-dev,
David Miller, kosmo
In-Reply-To: <4B5C5BDF.6020001@grandegger.com>
Dear Wolfgang & Arnd,
In message <4B5C5BDF.6020001@grandegger.com> you wrote:
>
> Arnd Bergmann wrote:
...
> > Is there any chance of building a kernel that runs on both mpc8xx and
> > mpc5121? AFAIK, the 5121 is built on a 6xx core which is fundamentally
> > incompatible with 8xx due to different memory management etc.
It is my understanding as well that you cannot have a single image
that boots both on 8xx and on 6xx cores. The focus was more on things
like supporting MPC5200 and MPC512x with the same image.
> > Since this makes it all a compile-time decision, it should be solvable
> > with a very small number of carefully placed #ifdef in the header files
> > an no runtime detection at all.
> >
> > Obviously this approach would not work for drivers that want to be portable
> > across different register layouts on otherwise compatible platforms.
>
> You are probably right and your proposal would likely result in more
> transparent (less ugly) code. There has been some discussion about
> unifying FEC drivers when the patches (with the same subject) have been
> submitted for the first time in May last year, but it was not about 512x
> and 8xx, IIRC.
You can re-read this discussion here:
http://patchwork.ozlabs.org/patch/26927/
ee especiall Grant's note of 2009-05-21 15:36:11: "If it looks too
ugly, then just fork the driver."
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Immortality consists largely of boredom.
-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver
From: Wolfgang Grandegger @ 2010-01-24 14:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: wd, dzu, netdev, linuxppc-dev, agust, linuxppc-dev, David Miller,
kosmo
In-Reply-To: <201001231023.14372.arnd@arndb.de>
Arnd Bergmann wrote:
> On Thursday 21 January 2010, Wolfgang Grandegger wrote:
>> The major problem that Anatolij tries to solve are the different
>> register layouts of the supported SOCs, MPC52xx and MPC8xx. They use the
>> same registers but at different offsets. Therefore we cannot handle
>> this with a single "fec_t" struct to allow building a single kernel
>> image. Instead it's handled by filling a table with register addresses:
>>
>> if (of_device_is_compatible(ofdev->node, "fsl,mpc5121-fec")) {
>> fep->fec.fec_id = FS_ENET_MPC5121_FEC;
>> fec_reg_mpc5121(ievent);
>> fec_reg_mpc5121(imask);
>> ...
>> } else {
>> fec_reg_mpc8xx(ievent);
>> fec_reg_mpc8xx(imask);
>> ...
>> }
>>
>> Do you see a more clever solution to this problem? Nevertheless, the
>> code could be improved by using "offsetof", I think.
>
> Is there any chance of building a kernel that runs on both mpc8xx and
> mpc5121? AFAIK, the 5121 is built on a 6xx core which is fundamentally
> incompatible with 8xx due to different memory management etc.
>
> Since this makes it all a compile-time decision, it should be solvable
> with a very small number of carefully placed #ifdef in the header files
> an no runtime detection at all.
>
> Obviously this approach would not work for drivers that want to be portable
> across different register layouts on otherwise compatible platforms.
You are probably right and your proposal would likely result in more
transparent (less ugly) code. There has been some discussion about
unifying FEC drivers when the patches (with the same subject) have been
submitted for the first time in May last year, but it was not about 512x
and 8xx, IIRC.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Benjamin Herrenschmidt @ 2010-01-24 3:00 UTC (permalink / raw)
To: Joel Schopp
Cc: Michael Neuling, Peter Zijlstra, ego, linux-kernel, Ingo Molnar,
linuxppc-dev
In-Reply-To: <4B577F1A.9060907@austin.ibm.com>
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.
Cheers,
Ben.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver
From: Arnd Bergmann @ 2010-01-23 9:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: wd, dzu, netdev, linuxppc-dev, agust, David Miller, kosmo
In-Reply-To: <4B5871F2.9090005@grandegger.com>
On Thursday 21 January 2010, Wolfgang Grandegger wrote:
> The major problem that Anatolij tries to solve are the different
> register layouts of the supported SOCs, MPC52xx and MPC8xx. They use the
> same registers but at different offsets. Therefore we cannot handle
> this with a single "fec_t" struct to allow building a single kernel
> image. Instead it's handled by filling a table with register addresses:
>
> if (of_device_is_compatible(ofdev->node, "fsl,mpc5121-fec")) {
> fep->fec.fec_id = FS_ENET_MPC5121_FEC;
> fec_reg_mpc5121(ievent);
> fec_reg_mpc5121(imask);
> ...
> } else {
> fec_reg_mpc8xx(ievent);
> fec_reg_mpc8xx(imask);
> ...
> }
>
> Do you see a more clever solution to this problem? Nevertheless, the
> code could be improved by using "offsetof", I think.
Is there any chance of building a kernel that runs on both mpc8xx and
mpc5121? AFAIK, the 5121 is built on a 6xx core which is fundamentally
incompatible with 8xx due to different memory management etc.
Since this makes it all a compile-time decision, it should be solvable
with a very small number of carefully placed #ifdef in the header files
an no runtime detection at all.
Obviously this approach would not work for drivers that want to be portable
across different register layouts on otherwise compatible platforms.
Arnd
^ permalink raw reply
* FHCI fails to build in 2.6.33-rc5
From: Josh Boyer @ 2010-01-23 13:53 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
When trying to build the Fedora devel kernel, I get the build error
below. The *_frame_Q members of the fhci endpoint structure are
indeed declared as 'struct kfifo' and not pointers to such. The
NULL checks in the fhci_ep0_free function seem odd when you take
that into account.
Thoughts on a fix? If it's not fixed soon, I'll have to disable
it in the .config.
josh
In file included from drivers/usb/host/fhci-hcd.c:33:
drivers/usb/host/fhci.h: In function 'cq_get':
drivers/usb/host/fhci.h:520: warning: ignoring return value of 'kfifo_out', declared with attribute warn_unused_result
In file included from drivers/usb/host/fhci-hub.c:28:
drivers/usb/host/fhci.h: In function 'cq_get':
drivers/usb/host/fhci.h:520: warning: ignoring return value of 'kfifo_out', declared with attribute warn_unused_result
In file included from drivers/usb/host/fhci-q.c:25:
drivers/usb/host/fhci.h: In function 'cq_get':
drivers/usb/host/fhci.h:520: warning: ignoring return value of 'kfifo_out', declared with attribute warn_unused_result
In file included from drivers/usb/host/fhci-mem.c:24:
drivers/usb/host/fhci.h: In function 'cq_get':
drivers/usb/host/fhci.h:520: warning: ignoring return value of 'kfifo_out', declared with attribute warn_unused_result
In file included from drivers/usb/host/fhci-tds.c:25:
drivers/usb/host/fhci.h: In function 'cq_get':
drivers/usb/host/fhci.h:520: warning: ignoring return value of 'kfifo_out', declared with attribute warn_unused_result
drivers/usb/host/fhci-tds.c: In function 'fhci_ep0_free':
drivers/usb/host/fhci-tds.c:108: error: used struct type value where scalar is required
drivers/usb/host/fhci-tds.c:118: error: used struct type value where scalar is required
drivers/usb/host/fhci-tds.c:128: error: used struct type value where scalar is required
make[3]: *** [drivers/usb/host/fhci-tds.o] Error 1
make[2]: *** [drivers/usb/host] Error 2
make[1]: *** [drivers/usb] Error 2
^ permalink raw reply
* [PATCH/RFC 1/2] 5200: improve i2c bus error recovery
From: Albrecht Dreß @ 2010-01-22 20:17 UTC (permalink / raw)
To: Linux PPC Development, Devicetree Discussions,
Ben Dooks (embedded platforms)
Improve the recovery of the MPC5200B's I2C bus from errors like bus
hangs.
Signed-off-by: Albrecht Dre=DF <albrecht.dress@arcor.de>
---
This patch introduces several improvements to the MPC5200B's I2C driver
as to improve the recovery from error conditions I encountered when
testing a custom board with several I2C devices attached (eeprom, io
expander, rtc, sensors). The error conditions included cases where the
bus if logic of one slave apparently went south, blocking the bus
completely.
My fixes include:
1. make the bus timeout configurable in fsl_i2c_probe(); the default of
one second is *way* too long for my use case;
2. if a timeout condition occurs in mpc_xfer(), mpc_i2c_fixup() the bus
if *any* of the CF, BB and RXAK flags in the MSR is 1. I actually
saw different combinations with hangs, not only all three set;
3. improve the fixup procedure by calculating the timing needed from the
real (configured) bus clock, calculated in mpc_i2c_setclock_52xx().
Furthermore, I issue 9 instead of one cycle, as I experienced cases
where the single one is not enough (found this tip in a forum). As a
side effect, the new scheme needs only 81us @375kHz bus clock instead
of 150us. I recorded waveforms for 18.4kHz, 85.9kHz and 375kHz, all
looking fine, which I can provide if anyone is interested.
Open questions:
- is the approach correct at all, in particular the interpretation of
the flags (#2)?
- could this code also be used on non-5200 processors?
--- linux-2.6.32-orig/drivers/i2c/busses/i2c-mpc.c 2009-12-03 04:51:21.0000=
00000 +0100
+++ linux-2.6.32/drivers/i2c/busses/i2c-mpc.c 2010-01-22 16:05:13.000000000=
+0100
@@ -59,6 +59,7 @@ struct mpc_i2c {
wait_queue_head_t queue;
struct i2c_adapter adap;
int irq;
+ u32 real_clk;
};
=20
struct mpc_i2c_divider {
@@ -97,16 +98,32 @@ static irqreturn_t mpc_i2c_isr(int irq,=20
*/
static void mpc_i2c_fixup(struct mpc_i2c *i2c)
{
- writeccr(i2c, 0);
- udelay(30);
- writeccr(i2c, CCR_MEN);
- udelay(30);
- writeccr(i2c, CCR_MSTA | CCR_MTX);
- udelay(30);
- writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
- udelay(30);
- writeccr(i2c, CCR_MEN);
- udelay(30);
+ if (i2c->real_clk =3D=3D 0) {
+ writeccr(i2c, 0);
+ udelay(30);
+ writeccr(i2c, CCR_MEN);
+ udelay(30);
+ writeccr(i2c, CCR_MSTA | CCR_MTX);
+ udelay(30);
+ writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
+ udelay(30);
+ writeccr(i2c, CCR_MEN);
+ udelay(30);
+ } else {
+ int k;
+ u32 delay_val =3D 1000000 / i2c->real_clk + 1;
+
+ if (delay_val < 2)
+ delay_val =3D 2;
+
+ for (k =3D 9; k; k--) {
+ writeccr(i2c, 0);
+ writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
+ udelay(delay_val);
+ writeccr(i2c, CCR_MEN);
+ udelay(delay_val << 1);
+ }
+ }
}
=20
static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
@@ -186,15 +203,18 @@ static const struct mpc_i2c_divider mpc_
{10240, 0x9d}, {12288, 0x9e}, {15360, 0x9f}
};
=20
-int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescale=
r)
+int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescale=
r,
+ u32 *real_clk)
{
const struct mpc_i2c_divider *div =3D NULL;
unsigned int pvr =3D mfspr(SPRN_PVR);
u32 divider;
int i;
=20
- if (!clock)
+ if (!clock) {
+ *real_clk =3D 0;
return -EINVAL;
+ }
=20
/* Determine divider value */
divider =3D mpc5xxx_get_bus_frequency(node) / clock;
@@ -212,7 +232,8 @@ int mpc_i2c_get_fdr_52xx(struct device_n
break;
}
=20
- return div ? (int)div->fdr : -EINVAL;
+ *real_clk =3D mpc5xxx_get_bus_frequency(node) / div->divider;
+ return (int)div->fdr;
}
=20
static void mpc_i2c_setclock_52xx(struct device_node *node,
@@ -221,13 +242,14 @@ static void mpc_i2c_setclock_52xx(struct
{
int ret, fdr;
=20
- ret =3D mpc_i2c_get_fdr_52xx(node, clock, prescaler);
+ ret =3D mpc_i2c_get_fdr_52xx(node, clock, prescaler, &i2c->real_clk);
fdr =3D (ret >=3D 0) ? ret : 0x3f; /* backward compatibility */
=20
writeb(fdr & 0xff, i2c->base + MPC_I2C_FDR);
=20
if (ret >=3D 0)
- dev_info(i2c->dev, "clock %d Hz (fdr=3D%d)\n", clock, fdr);
+ dev_info(i2c->dev, "clock %u Hz (fdr=3D%d)\n", i2c->real_clk,
+ fdr);
}
#else /* !CONFIG_PPC_MPC52xx */
static void mpc_i2c_setclock_52xx(struct device_node *node,
@@ -446,10 +468,14 @@ static int mpc_xfer(struct i2c_adapter *
return -EINTR;
}
if (time_after(jiffies, orig_jiffies + HZ)) {
+ u8 status =3D readb(i2c->base + MPC_I2C_SR);
+
dev_dbg(i2c->dev, "timeout\n");
- if (readb(i2c->base + MPC_I2C_SR) =3D=3D
- (CSR_MCF | CSR_MBB | CSR_RXAK))
+ if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) !=3D 0) {
+ writeb(status & ~CSR_MAL,
+ i2c->base + MPC_I2C_SR);
mpc_i2c_fixup(i2c);
+ }
return -EIO;
}
schedule();
@@ -540,6 +566,14 @@ static int __devinit fsl_i2c_probe(struc
}
}
=20
+ prop =3D of_get_property(op->node, "timeout", &plen);
+ if (prop && plen =3D=3D sizeof(u32)) {
+ mpc_ops.timeout =3D *prop * HZ / 1000000;
+ if (mpc_ops.timeout < 5)
+ mpc_ops.timeout =3D 5;
+ }
+ dev_info(i2c->dev, "timeout %u us\n", mpc_ops.timeout * 1000000 / HZ);
+
dev_set_drvdata(&op->dev, i2c);
=20
i2c->adap =3D mpc_ops;
^ permalink raw reply
* [PATCH/RFC 2/2] 5200: improve i2c bus error recovery
From: Albrecht Dreß @ 2010-01-22 20:18 UTC (permalink / raw)
To: Linux PPC Development, Devicetree Discussions,
Ben Dooks (embedded platforms)
Make the I2C adapter timeout configurable through a Device Tree property
which gives the timeout in microseconds.
Signed-off-by: Albrecht Dre=DF <albrecht.dress@arcor.de>
---
--- linux-2.6.32-orig/Documentation/powerpc/dts-bindings/fsl/i2c.txt 2009-1=
2-03 04:51:21.000000000 +0100
+++ linux-2.6.32/Documentation/powerpc/dts-bindings/fsl/i2c.txt 2010-01-22 =
16:04:56.000000000 +0100
@@ -21,6 +21,7 @@
- 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.
+ - timeout : I2C timeout in microseconds.
=20
Examples :
=20
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Albrecht Dreß @ 2010-01-22 20:11 UTC (permalink / raw)
To: Roman Fietze, linuxppc-dev
In-Reply-To: <200912161237.09796.roman.fietze@telemotive.de>
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
Hi Roman:
Am 16.12.09 12:37 schrieb(en) Roman Fietze:
> The board is using the MPC5200B on a board derived from the old lite5200, but with the fixes for the MPC5200B. All tests are run using an ST940813AM hard drive with an ext2 and an ext3 of 10GB each, default mkfs options. The OS is Debian 4.0. The
> network connection is between a fast Athlon XP2 6400 and the target, using 100MBit/s wiring and a 100MBit/s switch.
Are there any "final" conclusions from your tests?
I am using a board derived from the Lite5200b, running u-boot 2009.03 and a recent stock kernel, where I performed tests concurrently reading and writing data to and from
- two compactflash cards with vfat file systems attached to the ata bus;
- a nfs3 network drive, connected via a 100MBit line, on a Xeon serve;
- a signal processor attached to the localbus, using bestcomm and the fifo for the bulk transfer.
I did not observe any issues, but your statements are making me really nervous...
Thanks,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 04/11] i2c-mpc: Add MPC5121 I2C bus support
From: Wolfgang Grandegger @ 2010-01-22 12:15 UTC (permalink / raw)
To: Grant Likely
Cc: Piotr Ziecik, dzu, linuxppc-dev, linux-i2c, Anatolij Gustschin,
wd
In-Reply-To: <fa686aa41001210912r5fd2a5a4g8a072e0c41ee4107@mail.gmail.com>
Grant Likely wrote:
> On Tue, Jan 19, 2010 at 1:24 PM, Anatolij Gustschin <agust@denx.de> wrote:
>> From: Piotr Ziecik <kosmo@semihalf.com>
>>
>> - Update Kconfig for i2c-mpc driver.
>> - Enable I2C interrupts on MPC5121.
>>
>> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
>> index f627001..84eeb25 100644
>> --- a/drivers/i2c/busses/i2c-mpc.c
>> +++ b/drivers/i2c/busses/i2c-mpc.c
>> @@ -540,6 +540,29 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
>> }
>> }
>>
>> + if (of_device_is_compatible(op->node, "fsl,mpc5121-i2c")) {
>
> Rather than doing stuff like this with explicit compatible checks in
> the probe hook, consider using the .data pointer in the of match
> table.
Yes, and it does also not use the clock setting code of the MPC5200,
which should work for the MPC512x as well. I already have a patch in my
pipeline, which I will roll out after some more testing.
Wolfgang.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver
From: Wolfgang Grandegger @ 2010-01-22 9:35 UTC (permalink / raw)
To: David Miller; +Cc: wd, dzu, netdev, linuxppc-dev, agust, kosmo
In-Reply-To: <20100121.180311.228791894.davem@davemloft.net>
David Miller wrote:
> From: Wolfgang Grandegger <wg@grandegger.com>
> Date: Thu, 21 Jan 2010 16:25:38 +0100
>
>> Do you see a more clever solution to this problem?
>
> See how we handle this in the ESP scsi driver. We have a set of
> defines for the register offsets, and a set of methods a chip driver
> implements for register accesses.
>
> If the offsets differ, the register access method can translate the
> generic register offsets into whatever layout their implementation
> actually uses.
I think you speak about:
void (*esp_write8)(struct esp *esp, u8 val, unsigned long reg);
u8 (*esp_read8)(struct esp *esp, unsigned long reg);
But still we need to translate the *generic* offset (reg) into the real
offset, which requires a lookup/table to get it. For me this seems not
really more efficient and less transparent as it bends the offsets.
Wolfgang.
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Marco Stornelli @ 2010-01-22 8:14 UTC (permalink / raw)
To: Johnny Hung
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, kernelnewbies,
linux-mtd@lists.infradead.org, Matthias Kaehlcke,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <cb9ecdfa1001211907u37415485tf3e1d2c443a506f7@mail.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?
>
Simply, you can mount each mount point with the fstab file and a
script, same approach of every linux distribution, nothing more. Even
in the pc world you can mount your /home on a partition with ext3,
/var in a partition with ext4, and so on. A very simple approach to
setup the system, it is to start with NFS for example with "whole" fs,
copy what you need in the right place, setup the start-up script and
reboot.
Marco
^ permalink raw reply
* Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
From: K.Prasad @ 2010-01-22 7:14 UTC (permalink / raw)
To: Roland McGrath
Cc: Michael Neuling, Benjamin Herrenschmidt, Frederic Weisbecker,
David Gibson, linuxppc-dev, Alan Stern, paulus
In-Reply-To: <20100119100335.3EB621DE@magilla.sf.frob.com>
On Tue, Jan 19, 2010 at 02:03:35AM -0800, Roland McGrath wrote:
> > It is also not clear to me if disabling pre-emption for the user-space
> > (albeit for a very tiny time-window) is incorrect and if their side-effects
> > are known. If otherwise, I think we should choose to operate in pre-empt
> > safe mode and avoid all costs associated when done without it.
>
> I never really gave much consideration to returning to user mode with
> preemption disabled. It would not really have occurred to me that was
> even possible. I can't say it seems to me like it could ever be a very
> good idea. I find it hard even to start listing the cans of worms that
> might be opened by that. Perhaps the powerpc maintainers have a clearer
> picture of it than I do.
>
> What does it mean when there is something that prevents it from returning
> to user mode? i.e., TIF_SIGPENDING or TIF_NEED_RESCHED, or whatever. It
> could do a lot in the kernel before it gets back to user mode. What if in
> there somewhere it blocks voluntarily?
>
> Similarly, what does it mean if you get to user mode but the single-stepped
> instruction is a load/store that gets a page fault? What if it blocks in
> the page fault handler?
>
> For that matter, what about a page fault for the kernel-mode case?
>
> Perhaps I'm imagining gremlins where there aren't any, but I just cannot
> really get my head around this "disable preemption while running some
> unknown instruction that normally runs with preemption enabled" thing--let
> alone "disable preemption while returning to user mode".
>
>
> Thanks,
> Roland
I posted a patch which re-enables pre-emption after a hw-breakpoint is
processed (linuxppc-dev ref: 20100121084640.GA3252@in.ibm.com). It does
lead to clumsiness (due to the new variables to track states, prior
breakpoints, etc.) but with the reasons you pointed out, it is much
better than having uncertain/incorrect code.
Thanks for your comments.
-- K.Prasad
^ 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