* Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
From: Wolfram Sang @ 2011-03-10 8:54 UTC (permalink / raw)
To: Jain Priyanka-B32167
Cc: a.zummo@towertech.it, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, rtc-linux@googlegroups.com,
p_gortmaker@yahoo.com
In-Reply-To: <470DB7CE2CD0944E9436E7ADEFC02FE313B1C2@039-SN1MPN1-003.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
Hi Priyanka,
> Though register-set looks identical but features were different.
Can you tell what exactly is different?
> And also manufacturer is different.
That does not matter. If you look at ds_type, there are already
different manufacturers. They will be correctly distinguished by
i2c_device_id. The name of the driver itself is, well, just a name.
> But still it might be possible that we can reuse ds1307.c with some
> modification.
I agree. The driver already supports some variants. Adding one more
should not hurt. See 97f902b7be4dd6ba03c6aa8d3400783ed687ebd1 for an
example which added ds3231 support.
> But if I look at the drivers present in drivers/rtc folder. Most of
> them looks similar but still there are different drivers for different
> chips.
Yes, it probably could be cleaned up if somebody had the time/hardware.
> Please suggest which way is more preferred: modifying existing
> drivers(of different manufacturer) or writing new driver.
Ususally avoiding code duplication is good, it reduces maintenance
burden. However, if adding the support turns out to make the original
code unreadable or hard to follow, a new driver might be justified. This
is why it is important to understand the differences of the chip as a
first step. (I have the feeling, that modifying is the way to go here,
though).
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
From: Jain Priyanka-B32167 @ 2011-03-10 11:06 UTC (permalink / raw)
To: Wolfram Sang
Cc: a.zummo@towertech.it, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, rtc-linux@googlegroups.com,
p_gortmaker@yahoo.com
In-Reply-To: <20110310085414.GA4460@pengutronix.de>
Hi Wolfram,=20
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> Sent: Thursday, March 10, 2011 2:24 PM
> To: Jain Priyanka-B32167
> Cc: rtc-linux@googlegroups.com; linuxppc-dev@lists.ozlabs.org;
> a.zummo@towertech.it; p_gortmaker@yahoo.com; akpm@linux-foundation.org
> Subject: Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
>=20
> Hi Priyanka,
>=20
> > Though register-set looks identical but features were different.
>=20
> Can you tell what exactly is different?
I will check both the devices data sheets again in detail and will get back=
on this.
>=20
> > And also manufacturer is different.
>=20
> That does not matter. If you look at ds_type, there are already different
> manufacturers. They will be correctly distinguished by i2c_device_id. The
> name of the driver itself is, well, just a name.
>=20
> > But still it might be possible that we can reuse ds1307.c with some
> > modification.
>=20
> I agree. The driver already supports some variants. Adding one more
> should not hurt. See 97f902b7be4dd6ba03c6aa8d3400783ed687ebd1 for an
> example which added ds3231 support.
>=20
> > But if I look at the drivers present in drivers/rtc folder. Most of
> > them looks similar but still there are different drivers for different
> > chips.
>=20
> Yes, it probably could be cleaned up if somebody had the time/hardware.
>=20
> > Please suggest which way is more preferred: modifying existing
> > drivers(of different manufacturer) or writing new driver.
>=20
> Ususally avoiding code duplication is good, it reduces maintenance
> burden. However, if adding the support turns out to make the original
> code unreadable or hard to follow, a new driver might be justified. This
> is why it is important to understand the differences of the chip as a
> first step. (I have the feeling, that modifying is the way to go here,
> though).
>=20
I will explore possibility of using ds1307 driver for this.
Thanks
Priyanka
^ permalink raw reply
* [PATCH] ppc, 82xx: rename and update mgcoge board support
From: Holger Brunck @ 2011-03-10 11:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Heiko Schocher, Holger Brunck
The mgcoge board from keymile is now base for some other
similar boards. Therefore the board specific name mgcoge
was renamed to a generic name km82xx. Additionally some
enhancements were made:
- rework partition table in dts file
- add cpm2_pio_c gpio controller in dts file
- update defconfig
- add pin description for SCC1
- add pin description and configuration for USB
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Acked-by: Heiko Schocher <hs@denx.de>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Kumar Gala <galak@kernel.crashing.org>
CC: Heiko Schocher <hs@denx.de>
---
arch/powerpc/boot/dts/mgcoge.dts | 47 ++++++++-------
arch/powerpc/configs/mgcoge_defconfig | 9 +---
arch/powerpc/platforms/82xx/Makefile | 2 +-
arch/powerpc/platforms/82xx/{mgcoge.c => km82xx.c} | 62 ++++++++++++++------
4 files changed, 72 insertions(+), 48 deletions(-)
rename arch/powerpc/platforms/82xx/{mgcoge.c => km82xx.c} (69%)
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
index 0ce9664..1360d2f 100644
--- a/arch/powerpc/boot/dts/mgcoge.dts
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -13,7 +13,7 @@
/dts-v1/;
/ {
model = "MGCOGE";
- compatible = "keymile,mgcoge";
+ compatible = "keymile,km82xx";
#address-cells = <1>;
#size-cells = <1>;
@@ -48,8 +48,10 @@
reg = <0xf0010100 0x40>;
ranges = <0 0 0xfe000000 0x00400000
- 5 0 0x50000000 0x20000000
- >; /* Filled in by U-Boot */
+ 1 0 0x30000000 0x00010000
+ 2 0 0x40000000 0x00010000
+ 5 0 0x50000000 0x04000000
+ >;
flash@0,0 {
compatible = "cfi-flash";
@@ -60,36 +62,32 @@
device-width = <1>;
partition@0 {
label = "u-boot";
- reg = <0 0x40000>;
+ reg = <0x00000 0xC0000>;
};
- partition@40000 {
+ partition@1 {
label = "env";
- reg = <0x40000 0x20000>;
+ reg = <0xC0000 0x20000>;
};
- partition@60000 {
- label = "kernel";
- reg = <0x60000 0x220000>;
+ partition@2 {
+ label = "envred";
+ reg = <0xE0000 0x20000>;
};
- partition@280000 {
- label = "dtb";
- reg = <0x280000 0x20000>;
+ partition@3 {
+ label = "free";
+ reg = <0x100000 0x300000>;
};
};
flash@5,0 {
compatible = "cfi-flash";
- reg = <5 0x0 0x2000000>;
+ reg = <5 0x00000000 0x02000000
+ 5 0x02000000 0x02000000>;
#address-cells = <1>;
#size-cells = <1>;
bank-width = <2>;
- device-width = <2>;
- partition@0 {
- label = "ramdisk";
- reg = <0 0x7a0000>;
- };
- partition@7a0000 {
- label = "user";
- reg = <0x7a0000 0x1860000>;
+ partition@app { /* 64 MBytes */
+ label = "ubi0";
+ reg = <0x00000000 0x04000000>;
};
};
};
@@ -217,6 +215,13 @@
};
};
+ cpm2_pio_c: gpio-controller@10d40 {
+ #gpio-cells = <2>;
+ compatible = "fsl,cpm2-pario-bank";
+ reg = <0x10d40 0x14>;
+ gpio-controller;
+ };
+
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
diff --git a/arch/powerpc/configs/mgcoge_defconfig b/arch/powerpc/configs/mgcoge_defconfig
index 39518e9..6cb588a 100644
--- a/arch/powerpc/configs/mgcoge_defconfig
+++ b/arch/powerpc/configs/mgcoge_defconfig
@@ -1,4 +1,5 @@
CONFIG_SYSVIPC=y
+CONFIG_SPARSE_IRQ=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
@@ -10,7 +11,6 @@ CONFIG_SLAB=y
CONFIG_PPC_82xx=y
CONFIG_MGCOGE=y
CONFIG_BINFMT_MISC=y
-CONFIG_SPARSE_IRQ=y
# CONFIG_SECCOMP is not set
CONFIG_NET=y
CONFIG_PACKET=y
@@ -30,7 +30,6 @@ CONFIG_MTD=y
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_CFI=y
@@ -43,7 +42,6 @@ CONFIG_MTD_PHYSMAP_OF=y
CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
-# CONFIG_MISC_DEVICES is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_FIXED_PHY=y
@@ -67,7 +65,6 @@ CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
# CONFIG_EXT3_FS_XATTR is not set
-CONFIG_INOTIFY=y
CONFIG_AUTOFS4_FS=y
CONFIG_PROC_KCORE=y
CONFIG_TMPFS=y
@@ -88,13 +85,9 @@ CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_BDI_SWITCH=y
-CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_PCBC=y
-CONFIG_CRYPTO_MD5=y
-CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
diff --git a/arch/powerpc/platforms/82xx/Makefile b/arch/powerpc/platforms/82xx/Makefile
index d982793..455fe21 100644
--- a/arch/powerpc/platforms/82xx/Makefile
+++ b/arch/powerpc/platforms/82xx/Makefile
@@ -6,4 +6,4 @@ obj-$(CONFIG_CPM2) += pq2.o
obj-$(CONFIG_PQ2_ADS_PCI_PIC) += pq2ads-pci-pic.o
obj-$(CONFIG_PQ2FADS) += pq2fads.o
obj-$(CONFIG_EP8248E) += ep8248e.o
-obj-$(CONFIG_MGCOGE) += mgcoge.o
+obj-$(CONFIG_MGCOGE) += km82xx.o
diff --git a/arch/powerpc/platforms/82xx/mgcoge.c b/arch/powerpc/platforms/82xx/km82xx.c
similarity index 69%
rename from arch/powerpc/platforms/82xx/mgcoge.c
rename to arch/powerpc/platforms/82xx/km82xx.c
index 7a5de9e..428c5e0 100644
--- a/arch/powerpc/platforms/82xx/mgcoge.c
+++ b/arch/powerpc/platforms/82xx/km82xx.c
@@ -1,6 +1,6 @@
/*
- * Keymile mgcoge support
- * Copyright 2008 DENX Software Engineering GmbH
+ * Keymile km82xx support
+ * Copyright 2008-2011 DENX Software Engineering GmbH
* Author: Heiko Schocher <hs@denx.de>
*
* based on code from:
@@ -31,9 +31,10 @@
#include "pq2.h"
-static void __init mgcoge_pic_init(void)
+static void __init km82xx_pic_init(void)
{
- struct device_node *np = of_find_compatible_node(NULL, NULL, "fsl,pq2-pic");
+ struct device_node *np = of_find_compatible_node(NULL, NULL,
+ "fsl,pq2-pic");
if (!np) {
printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
return;
@@ -47,12 +48,18 @@ struct cpm_pin {
int port, pin, flags;
};
-static __initdata struct cpm_pin mgcoge_pins[] = {
+static __initdata struct cpm_pin km82xx_pins[] = {
/* SMC2 */
{0, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{0, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ /* SCC1 */
+ {2, 21, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 31, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
+
/* SCC4 */
{2, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
@@ -107,30 +114,49 @@ static __initdata struct cpm_pin mgcoge_pins[] = {
{3, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
{3, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
#endif
+
+ /* USB */
+ {0, 10, CPM_PIN_OUTPUT | CPM_PIN_GPIO}, /* FULL_SPEED */
+ {0, 11, CPM_PIN_OUTPUT | CPM_PIN_GPIO}, /*/SLAVE */
+ {2, 10, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, /* RXN */
+ {2, 11, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, /* RXP */
+ {2, 20, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY}, /* /OE */
+ {2, 27, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, /* RXCLK */
+ {3, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY}, /* TXP */
+ {3, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY}, /* TXN */
+ {3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, /* RXD */
};
static void __init init_ioports(void)
{
int i;
- for (i = 0; i < ARRAY_SIZE(mgcoge_pins); i++) {
- const struct cpm_pin *pin = &mgcoge_pins[i];
+ for (i = 0; i < ARRAY_SIZE(km82xx_pins); i++) {
+ const struct cpm_pin *pin = &km82xx_pins[i];
cpm2_set_pin(pin->port, pin->pin, pin->flags);
}
cpm2_smc_clk_setup(CPM_CLK_SMC2, CPM_BRG8);
+ cpm2_clk_setup(CPM_CLK_SCC1, CPM_CLK11, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_SCC1, CPM_CLK11, CPM_CLK_TX);
+ cpm2_clk_setup(CPM_CLK_SCC3, CPM_CLK5, CPM_CLK_RTX);
cpm2_clk_setup(CPM_CLK_SCC4, CPM_CLK7, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_SCC4, CPM_CLK8, CPM_CLK_TX);
cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK9, CPM_CLK_TX);
cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK13, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK14, CPM_CLK_TX);
+
+ /* Force USB FULL SPEED bit to '1' */
+ setbits32(&cpm2_immr->im_ioport.iop_pdata, 1 << (31 - 10));
+ /* clear USB_SLAVE */
+ clrbits32(&cpm2_immr->im_ioport.iop_pdata, 1 << (31 - 11));
}
-static void __init mgcoge_setup_arch(void)
+static void __init km82xx_setup_arch(void)
{
if (ppc_md.progress)
- ppc_md.progress("mgcoge_setup_arch()", 0);
+ ppc_md.progress("km82xx_setup_arch()", 0);
cpm2_reset();
@@ -142,7 +168,7 @@ static void __init mgcoge_setup_arch(void)
init_ioports();
if (ppc_md.progress)
- ppc_md.progress("mgcoge_setup_arch(), finish", 0);
+ ppc_md.progress("km82xx_setup_arch(), finish", 0);
}
static __initdata struct of_device_id of_bus_ids[] = {
@@ -156,23 +182,23 @@ static int __init declare_of_platform_devices(void)
return 0;
}
-machine_device_initcall(mgcoge, declare_of_platform_devices);
+machine_device_initcall(km82xx, declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
*/
-static int __init mgcoge_probe(void)
+static int __init km82xx_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- return of_flat_dt_is_compatible(root, "keymile,mgcoge");
+ return of_flat_dt_is_compatible(root, "keymile,km82xx");
}
-define_machine(mgcoge)
+define_machine(km82xx)
{
- .name = "Keymile MGCOGE",
- .probe = mgcoge_probe,
- .setup_arch = mgcoge_setup_arch,
- .init_IRQ = mgcoge_pic_init,
+ .name = "Keymile km82xx",
+ .probe = km82xx_probe,
+ .setup_arch = km82xx_setup_arch,
+ .init_IRQ = km82xx_pic_init,
.get_irq = cpm2_get_irq,
.calibrate_decr = generic_calibrate_decr,
.restart = pq2_restart,
--
1.7.0.5
^ permalink raw reply related
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-10 14:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299675674.2308.2924.camel@twins>
On Wed, 2011-03-09 at 14:01 +0100, Peter Zijlstra wrote:
> On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > No, the domain stuff is good, we allocate new domains and have a
> > synchronize_sched() between us installing the new ones and freeing the
> > old ones.=20
>=20
> Gah, if only..
OK, so for hotplug and cpusets it works because they change the doms_cur
set, when the old and the new set don't match it destroys the current
sched_domain/sched_group sets for the relevant cpus and then calls
synchronize_sched() to wait for any current activity to go away.
Only then does it rebuild stuff for the new set, reusing the static
allocated sched_domain and sched_group data.
Now, supposedly when your new and old domain set is the same it should
be a nop, unless arch_update_cpu_topology() returns true in which case
it will do a full destroy and rebuild.
So I'm not quite sure what power does to make it go bang..
Anyway, I'm now rewriting the sched_domain creation stuff because I've
utterly had it with that code..
Also, still waiting to hear from the Power7 folks on how often they
think to rebuild the topology and how they think that makes sense,
afaict Power7 does have actual NUMA nodes unlike s390, so I'm still not
seeing how that's going to work properly at all.
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
From: Andi Kleen @ 2011-03-10 16:00 UTC (permalink / raw)
To: Stephen Wilson
Cc: linux-s390, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, Michel Lespinasse, linuxppc-dev, Andrew Morton
In-Reply-To: <1299630721-4337-1-git-send-email-wilsons@start.ca>
On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote:
>
> Morally, the question of whether an address lies in a gate vma should be asked
> with respect to an mm, not a particular task.
>
> Practically, dropping the dependency on task_struct will help make current and
> future operations on mm's more flexible and convenient. In particular, it
> allows some code paths to avoid the need to hold task_lock.
>
> The only architecture this change impacts in any significant way is x86_64.
> The principle change on that architecture is to mirror TIF_IA32 via
> a new flag in mm_context_t.
The problem is -- you're adding a likely cache miss on mm_struct for
every 32bit compat syscall now, even if they don't need mm_struct
currently (and a lot of them do not) Unless there's a very good
justification to make up for this performance issue elsewhere
(including numbers) this seems like a bad idea.
> This is the first of a two part series that implements safe writes to
> /proc/pid/mem. I will be posting the second series to lkml shortly. These
Making every syscall slower for /proc/pid/mem doesn't seem like a good
tradeoff to me. Please solve this in some other way.
-Andi
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II
From: Andi Kleen @ 2011-03-10 16:38 UTC (permalink / raw)
To: Stephen Wilson
Cc: linux-s390, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, Michel Lespinasse, linuxppc-dev, Andrew Morton
In-Reply-To: <20110310160032.GA20504@alboin.amr.corp.intel.com>
On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote:
> On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote:
> >
> > Morally, the question of whether an address lies in a gate vma should be asked
> > with respect to an mm, not a particular task.
> >
> > Practically, dropping the dependency on task_struct will help make current and
> > future operations on mm's more flexible and convenient. In particular, it
> > allows some code paths to avoid the need to hold task_lock.
> >
> > The only architecture this change impacts in any significant way is x86_64.
> > The principle change on that architecture is to mirror TIF_IA32 via
> > a new flag in mm_context_t.
>
> The problem is -- you're adding a likely cache miss on mm_struct for
> every 32bit compat syscall now, even if they don't need mm_struct
> currently (and a lot of them do not) Unless there's a very good
> justification to make up for this performance issue elsewhere
> (including numbers) this seems like a bad idea.
Hmm I see you're only setting it on exec time actually on rereading
the patches. I thought you were changing TS_COMPAT which is in
the syscall path.
Never mind. I have no problems with doing such a change on exec
time.
-Andi
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
From: Stephen Wilson @ 2011-03-10 16:40 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-s390, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, Michel Lespinasse, linuxppc-dev, Andrew Morton
In-Reply-To: <20110310160032.GA20504@alboin.amr.corp.intel.com>
On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote:
> On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote:
> >
> > Morally, the question of whether an address lies in a gate vma should be asked
> > with respect to an mm, not a particular task.
> >
> > Practically, dropping the dependency on task_struct will help make current and
> > future operations on mm's more flexible and convenient. In particular, it
> > allows some code paths to avoid the need to hold task_lock.
> >
> > The only architecture this change impacts in any significant way is x86_64.
> > The principle change on that architecture is to mirror TIF_IA32 via
> > a new flag in mm_context_t.
>
> The problem is -- you're adding a likely cache miss on mm_struct for
> every 32bit compat syscall now, even if they don't need mm_struct
> currently (and a lot of them do not) Unless there's a very good
> justification to make up for this performance issue elsewhere
> (including numbers) this seems like a bad idea.
I do not think this will result in cache misses on the scale you
suggest. I am simply mirroring the *state* of the TIF_IA32 flag in
mm_struct, not testing/accessing it in the same way.
The only place where this flag is accessed (outside the exec() syscall
path) is in x86/mm/init_64.c, get_gate_vma(), which in turn is needed
by a few, relatively heavy weight, page locking/pinning routines on the
mm side (get_user_pages, for example). Patches 3 and 4 in the series
show the extent of the change.
Or am I missing something?
> > /proc/pid/mem. I will be posting the second series to lkml shortly. These
>
> Making every syscall slower for /proc/pid/mem doesn't seem like a good
> tradeoff to me. Please solve this in some other way.
>
> -Andi
--
steve
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II
From: Stephen Wilson @ 2011-03-10 16:54 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-s390, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, Michel Lespinasse, linuxppc-dev, Andrew Morton
In-Reply-To: <20110310163809.GA20675@alboin.amr.corp.intel.com>
On Thu, Mar 10, 2011 at 08:38:09AM -0800, Andi Kleen wrote:
> On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote:
> > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote:
> > > The only architecture this change impacts in any significant way is x86_64.
> > > The principle change on that architecture is to mirror TIF_IA32 via
> > > a new flag in mm_context_t.
> >
> > The problem is -- you're adding a likely cache miss on mm_struct for
> > every 32bit compat syscall now, even if they don't need mm_struct
> > currently (and a lot of them do not) Unless there's a very good
> > justification to make up for this performance issue elsewhere
> > (including numbers) this seems like a bad idea.
>
> Hmm I see you're only setting it on exec time actually on rereading
> the patches. I thought you were changing TS_COMPAT which is in
> the syscall path.
>
> Never mind. I have no problems with doing such a change on exec
> time.
OK. Great! Does this mean I have your ACK'ed by or reviewed by?
Thanks for taking a look!
--
steve
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II
From: Andi Kleen @ 2011-03-10 17:03 UTC (permalink / raw)
To: Stephen Wilson
Cc: linux-s390, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, Michel Lespinasse, linuxppc-dev, Andrew Morton
In-Reply-To: <20110310165414.GA6431@fibrous.localdomain>
On Thu, Mar 10, 2011 at 11:54:14AM -0500, Stephen Wilson wrote:
>
> On Thu, Mar 10, 2011 at 08:38:09AM -0800, Andi Kleen wrote:
> > On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote:
> > > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote:
> > > > The only architecture this change impacts in any significant way is x86_64.
> > > > The principle change on that architecture is to mirror TIF_IA32 via
> > > > a new flag in mm_context_t.
> > >
> > > The problem is -- you're adding a likely cache miss on mm_struct for
> > > every 32bit compat syscall now, even if they don't need mm_struct
> > > currently (and a lot of them do not) Unless there's a very good
> > > justification to make up for this performance issue elsewhere
> > > (including numbers) this seems like a bad idea.
> >
> > Hmm I see you're only setting it on exec time actually on rereading
> > the patches. I thought you were changing TS_COMPAT which is in
> > the syscall path.
> >
> > Never mind. I have no problems with doing such a change on exec
> > time.
>
> OK. Great! Does this mean I have your ACK'ed by or reviewed by?
I didn't read it all, but the first two patches looked ok.
-Andi
^ permalink raw reply
* Re: [PATCH v4 2/2] powerpc: make MPIC honor the "pic-no-reset" device tree property
From: Meador Inge @ 2011-03-10 17:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <1299036140.8833.818.camel@pasglop>
On 03/01/2011 09:22 PM, Benjamin Herrenschmidt wrote:
>
>> diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
>> index e000cce..7e1be12 100644
>> --- a/arch/powerpc/include/asm/mpic.h
>> +++ b/arch/powerpc/include/asm/mpic.h
>> @@ -325,6 +325,8 @@ struct mpic
>> #ifdef CONFIG_PM
>> struct mpic_irq_save *save_data;
>> #endif
>> +
>> + int cpu;
>> };
>
> Why ? The MPIC isn't specifically associated with a CPU and whatever we
> pick as default during boot isn't relevant later on, so I don't see why
> we should have global permanent state here.
I agree. I shouldn't have cached that. We should probably introduce a
helper function to get the cpuid, though. The:
unsigned int cpu = 0;
if (mpic->flags & MPIC_PRIMARY)
cpu = hard_smp_processor_id();
code is scattered in three places: '_mpic_cpu_write', '_mpic_cpu_read',
and 'mpic_init'.
>> /* Check if we have one of those nice broken MPICs with a flipped endian on
>> @@ -622,6 +631,14 @@ static unsigned int mpic_is_ipi(struct mpic *mpic, unsigned int irq)
>> return (src>= mpic->ipi_vecs[0]&& src<= mpic->ipi_vecs[3]);
>> }
>>
>> +/* Determine if the linux irq is a timer interrupt */
>> +static unsigned int mpic_is_timer_interrupt(struct mpic *mpic, unsigned int irq)
>> +{
>> + unsigned int src = mpic_irq_to_hw(irq);
>> +
>> + return (src>= mpic->timer_vecs[0]&& src<= mpic->timer_vecs[3]);
>> +}
>> +
>>
>> /* Convert a cpu mask from logical to physical cpu numbers. */
>> static inline u32 mpic_physmask(u32 cpumask)
>> @@ -967,6 +984,15 @@ static int mpic_host_map(struct irq_host *h, unsigned int virq,
>> if (hw>= mpic->irq_count)
>> return -EINVAL;
>>
>> + /* If the MPIC was reset, then all vectors have already been
>> + * initialized. Otherwise, the appropriate vector needs to be
>> + * initialized here to ensure that only used sources are setup with
>> + * a vector.
>> + */
>> + if (mpic->flags& MPIC_NO_RESET)
>> + if (!(mpic_is_ipi(mpic, hw) || mpic_is_timer_interrupt(mpic, hw)))
>> + mpic_init_vector(mpic, hw);
>> +
>
> The above isn't useful. Of those two registers you want to initialize,
> afaik, one (the destination) will be initialized by the core calling
> into set_affinity when the interrupt is requested, and the other one is
AFAIK, we can't rely on 'set_affinity' always being called. I don't
think it is called at all when !defined(CONFIG_SMP) and if it was, then
that would be an error:
/* include/linux/irq.h */
#else /* CONFIG_SMP */
static inline int irq_set_affinity(unsigned int irq,
const struct cpumask *m)
{
return -EINVAL;
}
> partially initialized in set_type, I'd say just modify set_type to
> initialize the source as well, and problem solved, no ?
The priority has to be initialized as well. They could both be done in
'mpic_set_irq_type', but that seems like a weird place since it has
nothing to do with actually setting the type.
Since we already have 'mpic_irq_set_priority' and 'mpic_set_vector',
perhaps a better option is to add 'mpic_set_destination' and put the
following in 'mpic_host_map' (using the cpuid helper function suggested
above):
/* Lazy source init when MPIC_NO_RESET */
if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
mpic_set_vector(virq, hw);
mpic_set_destination(virq, mpic_cpuid(mpic));
mpic_irq_set_priority(virq, 8);
}
It is more overhead, but it reads well. Thoughts?
> Or is there a chance that the interrupt was left unmasked ?
There shouldn't be. The original idea was that either the boot program
would leave it masked or one of the AMP OSes would boot without
'pic-no-reset', which would mask everything. Most likely the boot program.
> I think it would be kosher to mask it in set_type unconditionally, I don't think it's ever supposed
> to be called for an enabled interrupt.
I will look into that.
Thanks,
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II
From: H. Peter Anvin @ 2011-03-10 17:22 UTC (permalink / raw)
To: Stephen Wilson, Andi Kleen
Cc: linux-s390, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, Martin Schwidefsky, linux390, Thomas Gleixner,
Michel Lespinasse, linuxppc-dev, Andrew Morton
In-Reply-To: <20110310165414.GA6431@fibrous.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
Sorry... I confused them too. It's TS_COMPAT which is problematic.
--
Sent from my mobile phone. Please pardon any lack of formatting.
Stephen Wilson <wilsons@start.ca> wrote:
On Thu, Mar 10, 2011 at 08:38:09AM -0800, Andi Kleen wrote: > On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > The only architecture this change impacts in any significant way is x86_64. > > > The principle change on that architecture is to mirror TIF_IA32 via > > > a new flag in mm_context_t. > > > > The problem is -- you're adding a likely cache miss on mm_struct for > > every 32bit compat syscall now, even if they don't need mm_struct > > currently (and a lot of them do not) Unless there's a very good > > justification to make up for this performance issue elsewhere > > (including numbers) this seems like a bad idea. > > Hmm I see you're only setting it on exec time actually on rereading > the patches. I thought you were changing TS_COMPAT which is in > the syscall path. > > Never mind. I have no problems with doing such a change on exec > time. OK. Great! Does this mean I have your ACK'e!
d by or
reviewed by? Thanks for taking a look! -- steve
[-- Attachment #2: Type: text/html, Size: 1633 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
From: H. Peter Anvin @ 2011-03-10 17:15 UTC (permalink / raw)
To: Stephen Wilson, Andi Kleen
Cc: linux-s390, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, Martin Schwidefsky, linux390, Thomas Gleixner,
Michel Lespinasse, linuxppc-dev, Andrew Morton
In-Reply-To: <20110310164022.GA6242@fibrous.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]
TIF_IA32 is set during the execution of a 32-bit system call - so touched on each compat system call. Is this the actual flag you want? A 32-bit address space flag is different from TIF_IA32.
--
Sent from my mobile phone. Please pardon any lack of formatting.
Stephen Wilson <wilsons@start.ca> wrote:
On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > > Morally, the question of whether an address lies in a gate vma should be asked > > with respect to an mm, not a particular task. > > > > Practically, dropping the dependency on task_struct will help make current and > > future operations on mm's more flexible and convenient. In particular, it > > allows some code paths to avoid the need to hold task_lock. > > > > The only architecture this change impacts in any significant way is x86_64. > > The principle change on that architecture is to mirror TIF_IA32 via > > a new flag in mm_context_t. > > The problem is -- you're adding a likely cache miss on mm_struct for > every 32bit compat syscall now, even if they don't need mm_struct > currently (and a lot of them do not) Unless there's a very good > justification to make up for this performance issue elsewhere > (including numbers) this seems like !
a bad
idea. I do not think this will result in cache misses on the scale you suggest. I am simply mirroring the *state* of the TIF_IA32 flag in mm_struct, not testing/accessing it in the same way. The only place where this flag is accessed (outside the exec() syscall path) is in x86/mm/init_64.c, get_gate_vma(), which in turn is needed by a few, relatively heavy weight, page locking/pinning routines on the mm side (get_user_pages, for example). Patches 3 and 4 in the series show the extent of the change. Or am I missing something? > > /proc/pid/mem. I will be posting the second series to lkml shortly. These > > Making every syscall slower for /proc/pid/mem doesn't seem like a good > tradeoff to me. Please solve this in some other way. > > -Andi -- steve
[-- Attachment #2: Type: text/html, Size: 2484 bytes --]
^ permalink raw reply
* Re: fsl_udc_core not initializing properly?
From: Matthew L. Creech @ 2011-03-10 18:46 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikvPOak6mamoeBrDBS5j_M3KuPmQi6DR5Ng6vki@mail.gmail.com>
On Sat, Feb 19, 2011 at 1:01 PM, Matthew L. Creech <mlcreech@gmail.com> wro=
te:
>
> Yes, it's there. =A0Here's the DTS entry in case anything else sticks out=
:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usb@23000 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl-usb2-d=
r";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x23000 0x1000>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-parent =3D <&ipi=
c>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <38 0x8>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phy_type =3D "utmi_wide";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dr_mode =3D "peripheral";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sleep =3D <&pmc 0x00300000=
>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
Hi Anatolij,
I tracked the problem down to a change made in September, which
happens to be yours:
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcomm=
itdiff;h=3D126512e3f274802ca65ebeca8660237f0361ad48
When I roll this back, everything works fine again.
First of all, I noticed that fsl-mph-dr-of.c isn't even compiling for
me (even though I have the option enabled in my .config), because it's
been placed in "usb/host/", and I'm only using device/gadget-mode USB.
I edited the top-level Makefile to just force it into "usb/host/", and
that makes sure that your driver gets built (and it's probed just fine
at runtime). But that still didn't solve the problem - as before,
fsl_udc_probe() is never being called.
Did you test this change in device mode? I'm wondering if there's
something different about my configuration that prevents it from
working. My config is uploaded here if it helps:
http://mcreech.com/work/linux.config
Thanks!
--=20
Matthew L. Creech
^ permalink raw reply
* Re: [PATCH v4 2/2] powerpc: make MPIC honor the "pic-no-reset" device tree property
From: Benjamin Herrenschmidt @ 2011-03-10 22:11 UTC (permalink / raw)
To: Meador Inge; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <4D790901.9000701@mentor.com>
On Thu, 2011-03-10 at 11:23 -0600, Meador Inge wrote:
> I agree. I shouldn't have cached that. We should probably introduce a
> helper function to get the cpuid, though. The:
>
> unsigned int cpu = 0;
>
> if (mpic->flags & MPIC_PRIMARY)
> cpu = hard_smp_processor_id();
>
> code is scattered in three places: '_mpic_cpu_write', '_mpic_cpu_read',
> and 'mpic_init'.
Right, but that code must act on the current CPU, not a cached per-MPIC
variant. Doing a helper to factor the above 2 lines is fine if you wish
to do so but then make it a separate patch.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v4 2/2] powerpc: make MPIC honor the "pic-no-reset" device tree property
From: Benjamin Herrenschmidt @ 2011-03-10 22:13 UTC (permalink / raw)
To: Meador Inge; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <4D790901.9000701@mentor.com>
On Thu, 2011-03-10 at 11:23 -0600, Meador Inge wrote:
> AFAIK, we can't rely on 'set_affinity' always being called. I don't
> think it is called at all when !defined(CONFIG_SMP) and if it was,
> then that would be an error:
>
> /* include/linux/irq.h */
>
> #else /* CONFIG_SMP */
>
> static inline int irq_set_affinity(unsigned int irq,
> const struct cpumask *m)
> {
> return -EINVAL;
> }
You are right. We do need to set a sane default then.
> > partially initialized in set_type, I'd say just modify set_type to
> > initialize the source as well, and problem solved, no ?
>
> The priority has to be initialized as well. They could both be done
> in
> 'mpic_set_irq_type', but that seems like a weird place since it has
> nothing to do with actually setting the type.
>
> Since we already have 'mpic_irq_set_priority' and 'mpic_set_vector',
> perhaps a better option is to add 'mpic_set_destination' and put the
> following in 'mpic_host_map' (using the cpuid helper function
> suggested
> above):
>
> /* Lazy source init when MPIC_NO_RESET */
> if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
> mpic_set_vector(virq, hw);
> mpic_set_destination(virq, mpic_cpuid(mpic));
> mpic_irq_set_priority(virq, 8);
> }
>
> It is more overhead, but it reads well. Thoughts?
No objection.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
From: Kushwaha Prabhakar-B32579 @ 2011-03-11 3:12 UTC (permalink / raw)
To: jgarzik@pobox.com
Cc: meet2prabhu@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-ide@vger.kernel.org
In-Reply-To: <1299472170-3580-1-git-send-email-prabhakar@freescale.com>
Hi Jeff,
I am not finding any comments on this.
Could you please ACK this patch so that it can be applied in external list.=
=20
--Prabhakar
> -----Original Message-----
> From: Kushwaha Prabhakar-B32579
> Sent: Monday, March 07, 2011 10:00 AM
> To: linux-ide@vger.kernel.org
> Cc: jgarzik@pobox.com; meet2prabhu@gmail.com; linuxppc-
> dev@lists.ozlabs.org; Kushwaha Prabhakar-B32579
> Subject: [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
>=20
> RX_WATER_MARK sets the number of locations in Rx FIFO that can be used
> before the transport layer instructs the link layer to transmit HOLDS.
> Note that it can take some time for the HOLDs to get to the other end,
> and that in the interim there must be enough room in the FIFO to absorb
> all data that could arrive.
>=20
> Update the new recommended value to 16.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> (branch master)
>=20
> This patch is already gone through review of linuxppc-dev mail list.
> Making CC linuxppc-dev@lists.ozlabs.org
>=20
> drivers/ata/sata_fsl.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>=20
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
> 895771c..29d2f29 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -186,6 +186,11 @@ enum {
> COMMANDSTAT =3D 0x20,
> };
>=20
> +/* TRANSCFG (transport-layer) configuration control */ enum {
> + TRANSCFG_RX_WATER_MARK =3D (1 << 4),
> +};
> +
> /* PHY (link-layer) configuration control */ enum {
> PHY_BIST_ENABLE =3D 0x01,
> @@ -1305,6 +1310,7 @@ static int sata_fsl_probe(struct platform_device
> *ofdev,
> struct sata_fsl_host_priv *host_priv =3D NULL;
> int irq;
> struct ata_host *host;
> + u32 temp;
>=20
> struct ata_port_info pi =3D sata_fsl_port_info[0];
> const struct ata_port_info *ppi[] =3D { &pi, NULL }; @@ -1319,6
> +1325,12 @@ static int sata_fsl_probe(struct platform_device *ofdev,
> ssr_base =3D hcr_base + 0x100;
> csr_base =3D hcr_base + 0x140;
>=20
> + if (!of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc8315-
> sata")) {
> + temp =3D ioread32(csr_base + TRANSCFG);
> + temp =3D temp & 0xffffffe0;
> + iowrite32(temp | TRANSCFG_RX_WATER_MARK, csr_base +
> TRANSCFG);
> + }
> +
> DPRINTK("@reset i/o =3D 0x%x\n", ioread32(csr_base + TRANSCFG));
> DPRINTK("sizeof(cmd_desc) =3D %d\n", sizeof(struct command_desc));
> DPRINTK("sizeof(#define cmd_desc) =3D %d\n", SATA_FSL_CMD_DESC_SIZE);
> --
> 1.7.3
^ permalink raw reply
* [PATCH] ppc, 83xx: rename and update kmeter1
From: Holger Brunck @ 2011-03-11 7:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Heiko Schocher, Holger Brunck
Beside the MPC 8360 based board kmeter1 other km83xx boards
from keymile will follow. Therefore the board specific naming
kmeter1 for functions and files were replaced with km83xx.
Additionally some updates were made:
- update defconfig for 2.6.38
- rework flash partitioning in dts file
- add gpio controller for qe_pio_c in dts
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Acked-by: Heiko Schocher <hs@denx.de>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Kumar Gala <galak@kernel.crashing.org>
CC: Heiko Schocher <hs@denx.de>
---
arch/powerpc/boot/dts/kmeter1.dts | 69 +++++++++++---------
arch/powerpc/configs/83xx/kmeter1_defconfig | 7 +--
arch/powerpc/platforms/83xx/Makefile | 2 +-
.../powerpc/platforms/83xx/{kmeter1.c => km83xx.c} | 46 +++++++++----
4 files changed, 71 insertions(+), 53 deletions(-)
rename arch/powerpc/platforms/83xx/{kmeter1.c => km83xx.c} (80%)
diff --git a/arch/powerpc/boot/dts/kmeter1.dts b/arch/powerpc/boot/dts/kmeter1.dts
index d8b5d12..d16bae1 100644
--- a/arch/powerpc/boot/dts/kmeter1.dts
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -1,7 +1,7 @@
/*
* Keymile KMETER1 Device Tree Source
*
- * 2008 DENX Software Engineering GmbH
+ * 2008-2011 DENX Software Engineering GmbH
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -70,11 +70,11 @@
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
- compatible = "fsl-i2c";
+ compatible = "fsl,mpc8313-i2c","fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 0x8>;
interrupt-parent = <&ipic>;
- dfsrr;
+ clock-frequency = <400000>;
};
serial0: serial@4500 {
@@ -137,6 +137,13 @@
compatible = "fsl,mpc8360-par_io";
num-ports = <7>;
+ qe_pio_c: gpio-controller@30 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+ "fsl,mpc8323-qe-pario-bank";
+ reg = <0x1430 0x18>;
+ gpio-controller;
+ };
pio_ucc1: ucc_pin@0 {
reg = <0>;
@@ -472,7 +479,17 @@
#address-cells = <0>;
#interrupt-cells = <1>;
reg = <0x80 0x80>;
- interrupts = <32 8 33 8>;
+ big-endian;
+ interrupts = <
+ 32 0x8
+ 33 0x8
+ 34 0x8
+ 35 0x8
+ 40 0x8
+ 41 0x8
+ 42 0x8
+ 43 0x8
+ >;
interrupt-parent = <&ipic>;
};
};
@@ -484,43 +501,31 @@
compatible = "fsl,mpc8360-localbus", "fsl,pq2pro-localbus",
"simple-bus";
reg = <0xe0005000 0xd8>;
- ranges = <0 0 0xf0000000 0x04000000>; /* Filled in by U-Boot */
+ ranges = <0 0 0xf0000000 0x04000000 /* LB 0 */
+ 1 0 0xe8000000 0x01000000 /* LB 1 */
+ 3 0 0xa0000000 0x10000000>; /* LB 3 */
- flash@f0000000,0 {
+ flash@0,0 {
compatible = "cfi-flash";
- /*
- * The Intel P30 chip has 2 non-identical chips on
- * one die, so we need to define 2 separate regions
- * that are scanned by physmap_of independantly.
- */
- reg = <0 0x00000000 0x02000000
- 0 0x02000000 0x02000000>; /* Filled in by U-Boot */
- bank-width = <2>;
+ reg = <0 0 0x04000000>;
#address-cells = <1>;
#size-cells = <1>;
- partition@0 {
+ bank-width = <2>;
+ partition@0 { /* 768KB */
label = "u-boot";
- reg = <0 0x40000>;
+ reg = <0 0xC0000>;
};
- partition@40000 {
+ partition@c0000 { /* 128KB */
label = "env";
- reg = <0x40000 0x40000>;
- };
- partition@80000 {
- label = "dtb";
- reg = <0x80000 0x20000>;
- };
- partition@a0000 {
- label = "kernel";
- reg = <0xa0000 0x300000>;
+ reg = <0xC0000 0x20000>;
};
- partition@3a0000 {
- label = "ramdisk";
- reg = <0x3a0000 0x800000>;
+ partition@e0000 { /* 128KB */
+ label = "envred";
+ reg = <0xE0000 0x20000>;
};
- partition@ba0000 {
- label = "user";
- reg = <0xba0000 0x3460000>;
+ partition@100000 { /* 64512KB */
+ label = "ubi0";
+ reg = <0x100000 0x3F00000>;
};
};
};
diff --git a/arch/powerpc/configs/83xx/kmeter1_defconfig b/arch/powerpc/configs/83xx/kmeter1_defconfig
index 7a7b731..07e1bba 100644
--- a/arch/powerpc/configs/83xx/kmeter1_defconfig
+++ b/arch/powerpc/configs/83xx/kmeter1_defconfig
@@ -2,6 +2,7 @@ CONFIG_EXPERIMENTAL=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_SPARSE_IRQ=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_EXPERT=y
# CONFIG_HOTPLUG is not set
@@ -18,7 +19,6 @@ CONFIG_KMETER1=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
-CONFIG_SPARSE_IRQ=y
# CONFIG_SECCOMP is not set
CONFIG_NET=y
CONFIG_PACKET=y
@@ -37,7 +37,6 @@ CONFIG_MTD=y
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
@@ -49,13 +48,12 @@ CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_GLUEBI=y
CONFIG_MTD_UBI_DEBUG=y
CONFIG_PROC_DEVICETREE=y
-# CONFIG_MISC_DEVICES is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_TUN=y
+CONFIG_MII=y
CONFIG_MARVELL_PHY=y
CONFIG_NET_ETHERNET=y
-CONFIG_MII=y
CONFIG_UCC_GETH=y
# CONFIG_NETDEV_10000 is not set
CONFIG_WAN=y
@@ -77,7 +75,6 @@ CONFIG_I2C_MPC=y
# CONFIG_USB_SUPPORT is not set
CONFIG_UIO=y
# CONFIG_DNOTIFY is not set
-CONFIG_INOTIFY=y
CONFIG_TMPFS=y
CONFIG_JFFS2_FS=y
CONFIG_NFS_FS=y
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 6e8bbbb..ed95bfc 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -16,4 +16,4 @@ obj-$(CONFIG_MPC837x_MDS) += mpc837x_mds.o
obj-$(CONFIG_SBC834x) += sbc834x.o
obj-$(CONFIG_MPC837x_RDB) += mpc837x_rdb.o
obj-$(CONFIG_ASP834x) += asp834x.o
-obj-$(CONFIG_KMETER1) += kmeter1.o
+obj-$(CONFIG_KMETER1) += km83xx.o
diff --git a/arch/powerpc/platforms/83xx/kmeter1.c b/arch/powerpc/platforms/83xx/km83xx.c
similarity index 80%
rename from arch/powerpc/platforms/83xx/kmeter1.c
rename to arch/powerpc/platforms/83xx/km83xx.c
index 903acfd..a2b9b9e 100644
--- a/arch/powerpc/platforms/83xx/kmeter1.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2008 DENX Software Engineering GmbH
+ * Copyright 2008-2011 DENX Software Engineering GmbH
* Author: Heiko Schocher <hs@denx.de>
*
* Description:
@@ -49,12 +49,12 @@
* Setup the architecture
*
*/
-static void __init kmeter1_setup_arch(void)
+static void __init mpc83xx_km_setup_arch(void)
{
struct device_node *np;
if (ppc_md.progress)
- ppc_md.progress("kmeter1_setup_arch()", 0);
+ ppc_md.progress("kmpbec83xx_setup_arch()", 0);
#ifdef CONFIG_PCI
for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
@@ -69,6 +69,9 @@ static void __init kmeter1_setup_arch(void)
par_io_init(np);
of_node_put(np);
+ for_each_node_by_name(np, "spi")
+ par_io_of_config(np);
+
for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
par_io_of_config(np);
}
@@ -119,7 +122,7 @@ static void __init kmeter1_setup_arch(void)
#endif /* CONFIG_QUICC_ENGINE */
}
-static struct of_device_id kmeter_ids[] = {
+static struct of_device_id kmpbec83xx_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .compatible = "simple-bus", },
@@ -131,13 +134,13 @@ static struct of_device_id kmeter_ids[] = {
static int __init kmeter_declare_of_platform_devices(void)
{
/* Publish the QE devices */
- of_platform_bus_probe(NULL, kmeter_ids, NULL);
+ of_platform_bus_probe(NULL, kmpbec83xx_ids, NULL);
return 0;
}
-machine_device_initcall(kmeter1, kmeter_declare_of_platform_devices);
+machine_device_initcall(mpc83xx_km, kmeter_declare_of_platform_devices);
-static void __init kmeter1_init_IRQ(void)
+static void __init mpc83xx_km_init_IRQ(void)
{
struct device_node *np;
@@ -168,21 +171,34 @@ static void __init kmeter1_init_IRQ(void)
#endif /* CONFIG_QUICC_ENGINE */
}
+/* list of the supported boards */
+static char *board[] __initdata = {
+ "Keymile,KMETER1",
+ "Keymile,kmpbec8321",
+ NULL
+};
+
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
-static int __init kmeter1_probe(void)
+static int __init mpc83xx_km_probe(void)
{
- unsigned long root = of_get_flat_dt_root();
+ unsigned long node = of_get_flat_dt_root();
+ int i = 0;
- return of_flat_dt_is_compatible(root, "keymile,KMETER1");
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(node, board[i]))
+ break;
+ i++;
+ }
+ return (board[i] != NULL);
}
-define_machine(kmeter1) {
- .name = "KMETER1",
- .probe = kmeter1_probe,
- .setup_arch = kmeter1_setup_arch,
- .init_IRQ = kmeter1_init_IRQ,
+define_machine(mpc83xx_km) {
+ .name = "mpc83xx-km-platform",
+ .probe = mpc83xx_km_probe,
+ .setup_arch = mpc83xx_km_setup_arch,
+ .init_IRQ = mpc83xx_km_init_IRQ,
.get_irq = ipic_get_irq,
.restart = mpc83xx_restart,
.time_init = mpc83xx_time_init,
--
1.7.0.5
^ permalink raw reply related
* Re: fsl_udc_core not initializing properly?
From: Anatolij Gustschin @ 2011-03-11 13:27 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=B4O7u3S3qsa_zfDKWp33hXw3Yp5j6szRXDgfJ@mail.gmail.com>
On Thu, 10 Mar 2011 13:46:29 -0500
"Matthew L. Creech" <mlcreech@gmail.com> wrote:
> On Sat, Feb 19, 2011 at 1:01 PM, Matthew L. Creech <mlcreech@gmail.com> w=
rote:
> >
> > Yes, it's there. =C2=A0Here's the DTS entry in case anything else stick=
s out:
> >
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0usb@23000 {
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0compatible =3D "fsl-usb2-dr";
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0reg =3D <0x23000 0x1000>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0#address-cells =3D <1>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0#size-cells =3D <0>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0interrupt-parent =3D <&ipic>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0interrupts =3D <38 0x8>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0phy_type =3D "utmi_wide";
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0dr_mode =3D "peripheral";
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0sleep =3D <&pmc 0x00300000>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};
> >
>=20
> Hi Anatolij,
Hi Matthew,
> I tracked the problem down to a change made in September, which
> happens to be yours:
>=20
> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dco=
mmitdiff;h=3D126512e3f274802ca65ebeca8660237f0361ad48
>=20
> When I roll this back, everything works fine again.
>=20
> First of all, I noticed that fsl-mph-dr-of.c isn't even compiling for
> me (even though I have the option enabled in my .config), because it's
> been placed in "usb/host/", and I'm only using device/gadget-mode USB.
>=20
> I edited the top-level Makefile to just force it into "usb/host/", and
> that makes sure that your driver gets built (and it's probed just fine
> at runtime). But that still didn't solve the problem - as before,
> fsl_udc_probe() is never being called.
Thanks for reporting this bug.
> Did you test this change in device mode? I'm wondering if there's
> something different about my configuration that prevents it from
> working. My config is uploaded here if it helps:
>=20
> http://mcreech.com/work/linux.config
I did test in device mode with additional Patches for USB Device/OTG
support for MPC5121e, these patches still need rework to be acceptable in
mainline. Thanks for your config, I'll look at the issue this weekend
and will report the result.
Anatolij
^ permalink raw reply
* ongoing mesh saga ...
From: kevin diggs @ 2011-03-11 18:04 UTC (permalink / raw)
To: linuxppc-dev
Hi,
While trying to figure out why the MESH SCSI controller will not work
with the 4.3.5 compiler but will work when compiled with 4.1.2, I
noticed some ... unfortunate behavior from the 4.3.5 compiler. Before
I try to see if I can fix it (i.e. the compiler), it would be nice to
see if the "issue" still exists.
Is there any chance someone with a compiler newer than 4.3.5 would be
willing to get me -S output from a mesh compile (preferably not a
module unless it does not make any difference) for 2.6.36. Using:
head -1 <top>/drivers/scsi/.mesh.o.cmd
you can get a command line which can then be edited to get a script to
do a -S compile (watch out for the '\#' in KBUILD_STR(s)).
Thanks!
kevin
^ permalink raw reply
* Re: ongoing mesh saga ...
From: Segher Boessenkool @ 2011-03-11 20:25 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinfxdckX=sYk5fX4vRhnmJNTHnytWkUW0w_HMj4@mail.gmail.com>
> Is there any chance someone with a compiler newer than 4.3.5 would be
> willing to get me -S output from a mesh compile (preferably not a
> module unless it does not make any difference) for 2.6.36. Using:
>
> head -1 <top>/drivers/scsi/.mesh.o.cmd
>
> you can get a command line which can then be edited to get a script to
> do a -S compile (watch out for the '\#' in KBUILD_STR(s)).
make drivers/scsi/mesh.s
File sent separately, I doubt the list wants to see it.
Segher
^ permalink raw reply
* Re: ongoing mesh saga ...
From: kevin diggs @ 2011-03-12 1:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <56564.94.211.195.167.1299875156.squirrel@gate.crashing.org>
Hi,
On Fri, Mar 11, 2011 at 2:25 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> make drivers/scsi/mesh.s
>
??? I thought I have tried this in the past and it did not work? The
make <path>/<file>.s thing?
Thanks for the tip!
kevin
^ permalink raw reply
* Re: ongoing mesh saga ...
From: Segher Boessenkool @ 2011-03-12 1:39 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinzpvV3Y7FXTPo8yPrE69CA1C1ejBMqC+O5o9zZ@mail.gmail.com>
>> make drivers/scsi/mesh.s
>>
> ??? I thought I have tried this in the past and it did not work? The
> make <path>/<file>.s thing?
>
> Thanks for the tip!
You need to have the driver in your kernel config, or things will
go weird.
Segher
^ permalink raw reply
* Re: ongoing mesh saga ...
From: kevin diggs @ 2011-03-12 1:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <56927.94.211.195.167.1299893950.squirrel@gate.crashing.org>
Hi,
Good to know. I just tried this on an x86 laptop. It was NOT happy!
And, obviously, I am not using a mesh SCSI controller on my Toshiba
A75.
And thanks again for your time!
kevin
On Fri, Mar 11, 2011 at 7:39 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>>> make drivers/scsi/mesh.s
>>>
>> ??? I thought I have tried this in the past and it did not work? The
>> make <path>/<file>.s thing?
>>
>> Thanks for the tip!
>
> You need to have the driver in your kernel config, or things will
> go weird.
>
>
> Segher
>
^ permalink raw reply
* Anybody with a PowerBook3,3 or PowerBook3,4 ?
From: Benjamin Herrenschmidt @ 2011-03-12 5:11 UTC (permalink / raw)
To: linuxppc-dev
If anybody is around with one of these machines, any chance they
can send me a tarball of /proc/device-tree ?
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: fsl_udc_core not initializing properly?
From: Anatolij Gustschin @ 2011-03-12 8:00 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=B4O7u3S3qsa_zfDKWp33hXw3Yp5j6szRXDgfJ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]
Hi Matthew,
On Thu, 10 Mar 2011 13:46:29 -0500
"Matthew L. Creech" <mlcreech@gmail.com> wrote:
...
> I tracked the problem down to a change made in September, which
> happens to be yours:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=126512e3f274802ca65ebeca8660237f0361ad48
>
> When I roll this back, everything works fine again.
>
> First of all, I noticed that fsl-mph-dr-of.c isn't even compiling for
> me (even though I have the option enabled in my .config), because it's
> been placed in "usb/host/", and I'm only using device/gadget-mode USB.
>
> I edited the top-level Makefile to just force it into "usb/host/", and
> that makes sure that your driver gets built (and it's probed just fine
> at runtime). But that still didn't solve the problem - as before,
> fsl_udc_probe() is never being called.
>
> Did you test this change in device mode? I'm wondering if there's
> something different about my configuration that prevents it from
> working. My config is uploaded here if it helps:
>
> http://mcreech.com/work/linux.config
Can you please apply the attached patch, then build with your
linux.config and send me the kernel boot log? It will help to
fix the issue.
Thanks,
Anatolij
[-- Attachment #2: usb-mph-dr-cfg.diff --]
[-- Type: text/x-patch, Size: 1269 bytes --]
diff --git a/drivers/Makefile b/drivers/Makefile
index f3ebb30..bf1ad90 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_UWB) += uwb/
obj-$(CONFIG_USB_OTG_UTILS) += usb/otg/
obj-$(CONFIG_USB) += usb/
obj-$(CONFIG_USB_MUSB_HDRC) += usb/musb/
+obj-$(CONFIG_USB_FSL_MPH_DR_OF) += usb/host/
obj-$(CONFIG_PCI) += usb/
obj-$(CONFIG_USB_GADGET) += usb/gadget/
obj-$(CONFIG_SERIO) += input/serio/
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index 4c55eda..a3ba374 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2240,6 +2240,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev)
unsigned int i;
u32 dccparams;
+ printk("%s\n", __func__);
if (strcmp(pdev->name, driver_name)) {
VDBG("Wrong device");
return -ENODEV;
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 574b99e..b8b3070 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -130,6 +130,7 @@ static int __devinit fsl_usb2_mph_dr_of_probe(struct platform_device *ofdev)
static unsigned int idx;
int i;
+ printk("%s\n", __func__);
if (!of_device_is_available(np))
return -ENODEV;
^ permalink raw reply related
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