Re: [PATCH] powerpc TLF_RESTORE_SIGMASK
> Thanks. That can't go in until some generic changes have gone in
> first, right? So are you going to push the lot in one go via Andrew,
> or should I wait until the generic part is upstream and then push the
> powerpc bit?
>From what I can see, the related patches are in -mm now, but the powerpc
patch is not. Linus already said he approved of the patches, so I hope
they can be merged in real soon. That will simplify the juggling for arch
patches. That said, there is really no hurry for this change for powerpc;
it's a small optimization.
> Oh, and could you please also fix the occurrence of
> TIF_RESTORE_SIGMASK in arch/ppc/kernel/entry.S when this stuff goes
> in?
Oh, I didn't realize that file was in use (or existed).
Third time's the charm (or is this the fifth time?).
Thanks,
Roland
---
[PATCH] powerpc TLF_RESTORE_SIGMASK
Replace TIF_RESTORE_SIGMASK with TLF_RESTORE_SIGMASK and define
our own set_restore_sigmask() function. This saves the costly
SMP-safe set_bit operation, which we do not need for the sigmask
flag since TIF_SIGPENDING always has to be set too.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/entry_32.S|4 ++--
arch/powerpc/kernel/signal.c | 12 ++--
arch/powerpc/kernel/signal_32.c |2 +-
arch/ppc/kernel/entry.S |4 ++--
include/asm-powerpc/thread_info.h | 17 +
5 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 84c8686..7e2ecf0 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -667,7 +667,7 @@ user_exc_return:/* r10 contains MSR_KERNEL here
*/
/* Check current_thread_info()->flags */
rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
lwz r9,TI_FLAGS(r9)
- andi. r0,r9,(_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK|_TIF_NEED_RESCHED)
+ andi. r0,r9,_TIF_USER_WORK_MASK
bne do_work
restore_user:
@@ -924,7 +924,7 @@ recheck:
lwz r9,TI_FLAGS(r9)
andi. r0,r9,_TIF_NEED_RESCHED
bne-do_resched
- andi. r0,r9,_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK
+ andi. r0,r9,_TIF_USER_WORK_MASK
beq restore_user
do_user_signal:/* r10 contains MSR_KERNEL here */
ori r10,r10,MSR_EE
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index a65a44f..ad55488 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -120,7 +120,7 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
int ret;
int is32 = is_32bit_task();
- if (test_thread_flag(TIF_RESTORE_SIGMASK))
+ if (current_thread_info()->local_flags & _TLF_RESTORE_SIGMASK)
oldset = ¤t->saved_sigmask;
else if (!oldset)
oldset = ¤t->blocked;
@@ -131,9 +131,10 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
check_syscall_restart(regs, &ka, signr > 0);
if (signr <= 0) {
+ struct thread_info *ti = current_thread_info();
/* No signal to deliver -- put the saved sigmask back */
- if (test_thread_flag(TIF_RESTORE_SIGMASK)) {
- clear_thread_flag(TIF_RESTORE_SIGMASK);
+ if (ti->local_flags & _TLF_RESTORE_SIGMASK) {
+ ti->local_flags &= ~_TLF_RESTORE_SIGMASK;
sigprocmask(SIG_SETMASK, ¤t->saved_sigmask, NULL);
}
return 0; /* no signals delivered */
@@ -169,10 +170,9 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
/*
* A signal was successfully delivered; the saved sigmask is in
-* its frame, and we can clear the TIF_RESTORE_SIGMASK flag.
+* its frame, and we can clear the TLF_RESTORE_SIGMASK flag.
*/
- if (test_thread_flag(TIF_RESTORE_SIGMASK))
- clear_thread_flag(TIF_RESTORE_SIGMASK);
+ current_thread_info()->local_flags &= ~_TLF_RESTORE_SIGMASK;
}
return ret;
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index ad69434..4ae16d1 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -243,7 +243,7 @@ long sys_sigsuspend(old_sigset_t mask)
current->state = TASK_INTERRUPTIBLE;
schedule();
- set_thread_flag(TIF_RESTORE_SIGMASK);
+ set_restore_sigmask();
return -ERESTARTNOHAND;
}
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
index 5f3a5d0..fcd830a 100644
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -647,7 +647,7 @@ user_exc_return:/* r10 contains MSR_KERNEL here
*/
/* Check current_thread_info()->flags */
rlwinm r9,r1,0,0,18
lwz r9,TI_FLAGS(r9)
- andi. r0,r9,(_TIF_SIGPEN
Re: cpu_clock confusion
On Thu, Apr 24, 2008 at 11:27:37AM +0200, Johannes Berg wrote: > On Thu, 2008-04-24 at 02:24 -0700, David Miller wrote: > > From: Johannes Berg <[EMAIL PROTECTED]> > > Date: Thu, 24 Apr 2008 11:21:52 +0200 > > > > > Hmm. Why is that whole cpu_clock stuff in place anyway? powerpc has > > > perfectly synchronised time across processors with dirt cheap access to > > > it as well, so why build all this code that only messes it up on top of > > > it? > > > > Same on sparc64. These changes add more bugs than they fix. > > I tend to think all this clock business should be done local to those > arches that aren't capable of providing cheap, useful synchronised and > accurate clocks themselves. Or be a lib that they can link in if needed. > As it stands, it seems to me that it all just penalises those > architectures that have decent clocks. 100% agreed. Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] i2c: Convert most new-style drivers to use module aliasing
Based on earlier work by Jon Smirl and Jochen Friedrich.
Update most new-style i2c drivers to use standard module aliasing
instead of the old driver_name/type driver matching scheme. I've
left the video drivers apart (except for SoC camera drivers) as
they're a bit more diffcult to deal with, they'll have their own
patch later.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Cc: Jon Smirl <[EMAIL PROTECTED]>
Cc: Jochen Friedrich <[EMAIL PROTECTED]>
Cc: Kay Sievers <[EMAIL PROTECTED]>
---
arch/arm/mach-at91/board-csb337.c |3 -
arch/arm/mach-at91/board-dk.c |3 -
arch/arm/mach-at91/board-eb9200.c |3 -
arch/arm/mach-iop32x/em7210.c |3 -
arch/arm/mach-iop32x/glantank.c |4 -
arch/arm/mach-iop32x/n2100.c |4 -
arch/arm/mach-ixp4xx/dsmg600-setup.c |2
arch/arm/mach-ixp4xx/nas100d-setup.c |2
arch/arm/mach-ixp4xx/nslu2-setup.c|2
arch/arm/mach-omap1/board-h2.c|2
arch/arm/mach-omap1/board-h3.c|3 -
arch/arm/mach-omap1/board-osk.c |1
arch/arm/mach-orion5x/db88f5281-setup.c |4 -
arch/arm/mach-orion5x/dns323-setup.c |7 --
arch/arm/mach-orion5x/kurobox_pro-setup.c |4 -
arch/arm/mach-orion5x/rd88f5182-setup.c |4 -
arch/arm/mach-orion5x/ts209-setup.c |3 -
arch/arm/mach-pxa/pcm990-baseboard.c |5 -
arch/blackfin/mach-bf533/boards/stamp.c |3 -
arch/blackfin/mach-bf537/boards/stamp.c |3 -
arch/blackfin/mach-bf548/boards/ezkit.c |2
arch/powerpc/sysdev/fsl_soc.c | 27 --
arch/sh/boards/renesas/migor/setup.c |3 -
arch/sh/boards/renesas/r7780rp/setup.c|3 -
drivers/gpio/pca953x.c| 23 +---
drivers/gpio/pcf857x.c| 33 +++-
drivers/hwmon/f75375s.c | 23
drivers/i2c/busses/i2c-taos-evm.c |3 -
drivers/i2c/chips/ds1682.c|7 ++
drivers/i2c/chips/menelaus.c |7 ++
drivers/i2c/chips/tps65010.c | 29 --
drivers/i2c/chips/tsl2550.c |7 ++
drivers/media/video/mt9m001.c |7 ++
drivers/media/video/mt9v022.c |7 ++
drivers/rtc/rtc-ds1307.c | 63 +--
drivers/rtc/rtc-ds1374.c |7 ++
drivers/rtc/rtc-m41t80.c | 78 +++--
drivers/rtc/rtc-rs5c372.c | 24
drivers/rtc/rtc-s35390a.c |7 ++
include/linux/i2c.h | 12 ++--
40 files changed, 190 insertions(+), 247 deletions(-)
--- linux-2.6.26-rc0.orig/arch/arm/mach-at91/board-csb337.c 2008-04-27
22:07:12.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-at91/board-csb337.c 2008-04-27
22:09:48.0 +0200
@@ -79,8 +79,7 @@ static struct at91_udc_data __initdata c
static struct i2c_board_info __initdata csb337_i2c_devices[] = {
{
- I2C_BOARD_INFO("rtc-ds1307", 0x68),
- .type = "ds1307",
+ I2C_BOARD_INFO("ds1307", 0x68),
},
};
--- linux-2.6.26-rc0.orig/arch/arm/mach-at91/board-dk.c 2008-04-27
22:04:59.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-at91/board-dk.c 2008-04-27
22:09:48.0 +0200
@@ -132,8 +132,7 @@ static struct i2c_board_info __initdata
I2C_BOARD_INFO("x9429", 0x28),
},
{
- I2C_BOARD_INFO("at24c", 0x50),
- .type = "24c1024",
+ I2C_BOARD_INFO("24c1024", 0x50),
}
};
--- linux-2.6.26-rc0.orig/arch/arm/mach-at91/board-eb9200.c 2008-04-27
22:04:59.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-at91/board-eb9200.c 2008-04-27
22:09:48.0 +0200
@@ -93,8 +93,7 @@ static struct at91_mmc_data __initdata e
static struct i2c_board_info __initdata eb9200_i2c_devices[] = {
{
- I2C_BOARD_INFO("at24c", 0x50),
- .type = "24c512",
+ I2C_BOARD_INFO("24c512", 0x50),
},
};
--- linux-2.6.26-rc0.orig/arch/arm/mach-iop32x/em7210.c 2008-04-27
22:04:59.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-iop32x/em7210.c 2008-04-27
22:09:48.0 +0200
@@ -50,8 +50,7 @@ static struct sys_timer em7210_timer = {
*/
static struct i2c_board_info __initdata em7210_i2c_devices[] = {
{
- I2C_BOARD_INFO("rtc-rs5c372", 0x32),
- .type = "rs5c372a",
+ I2C_BOARD_INFO("rs5c372a", 0x32),
},
};
--- linux-2.6.26-rc0.orig/arch/arm/mach-iop32x/glantank.c 2008-04-27
22:04:59.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-iop32x/glantank.c2008-04-27
22:09:48.0 +0200
@@ -176,12 +176,10 @@ static struct f75375s_platform_data glan
static struct i2c_board_info __initdata glantank_i2c_devices[] = {
{
- I
[PATCH 1/2] i2c: Add support for device alias names
Based on earlier work by Jon Smirl and Jochen Friedrich.
This patch allows new-style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this
point, the old i2c driver binding scheme (driver_name/type) is still
supported.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Cc: Jochen Friedrich <[EMAIL PROTECTED]>
Cc: Jon Smirl <[EMAIL PROTECTED]>
Cc: Kay Sievers <[EMAIL PROTECTED]>
---
One thing I am still not happy with is that the aliases created have a
trailing "*":
$ /sbin/modinfo lm90
filename: /lib/modules/2.6.25-git11/kernel/drivers/hwmon/lm90.ko
author: Jean Delvare <[EMAIL PROTECTED]>
description:LM90/ADM1032 driver
license:GPL
vermagic: 2.6.25-git11 mod_unload
depends:hwmon
alias: i2c:lm90*
alias: i2c:adm1032*
alias: i2c:lm99*
alias: i2c:lm86*
alias: i2c:max6657*
alias: i2c:adt7461*
alias: i2c:max6680*
$
This would cause trouble if one I2C chip name matches the beginning of
another I2C chip name and both chips are supported by different
drivers. This has yet to be seen, but still, I'd like to see this
problem fixed quickly.
Documentation/i2c/writing-clients |3 +
drivers/gpio/pca953x.c |3 +
drivers/gpio/pcf857x.c |3 +
drivers/hwmon/f75375s.c|8 ++--
drivers/i2c/chips/ds1682.c |3 +
drivers/i2c/chips/menelaus.c |3 +
drivers/i2c/chips/tps65010.c |3 +
drivers/i2c/chips/tsl2550.c|3 +
drivers/i2c/i2c-core.c | 51 +++-
drivers/media/video/cs5345.c |3 +
drivers/media/video/cs53l32a.c |3 +
drivers/media/video/cx25840/cx25840-core.c |3 +
drivers/media/video/m52790.c |3 +
drivers/media/video/msp3400-driver.c |2 -
drivers/media/video/mt9m001.c |3 +
drivers/media/video/mt9v022.c |3 +
drivers/media/video/saa7115.c |3 +
drivers/media/video/saa7127.c |3 +
drivers/media/video/saa717x.c |3 +
drivers/media/video/tcm825x.c |3 +
drivers/media/video/tlv320aic23b.c |3 +
drivers/media/video/tuner-core.c |3 +
drivers/media/video/tvaudio.c |2 -
drivers/media/video/upd64031a.c|3 +
drivers/media/video/upd64083.c |3 +
drivers/media/video/v4l2-common.c |5 +-
drivers/media/video/vp27smpx.c |3 +
drivers/media/video/wm8739.c |3 +
drivers/media/video/wm8775.c |3 +
drivers/rtc/rtc-ds1307.c |3 +
drivers/rtc/rtc-ds1374.c |3 +
drivers/rtc/rtc-m41t80.c |3 +
drivers/rtc/rtc-rs5c372.c |3 +
drivers/rtc/rtc-s35390a.c |3 +
include/linux/i2c.h|5 +-
include/linux/mod_devicetable.h| 11 ++
include/media/v4l2-common.h|4 +-
include/media/v4l2-i2c-drv-legacy.h|2 -
include/media/v4l2-i2c-drv.h |2 -
scripts/mod/file2alias.c | 13 +++
40 files changed, 141 insertions(+), 51 deletions(-)
--- linux-2.6.26-rc0.orig/Documentation/i2c/writing-clients 2008-04-27
22:05:00.0 +0200
+++ linux-2.6.26-rc0/Documentation/i2c/writing-clients 2008-04-27
22:09:29.0 +0200
@@ -164,7 +164,8 @@ I2C device drivers using this binding mo
kind of driver in Linux: they provide a probe() method to bind to
those devices, and a remove() method to unbind.
- static int foo_probe(struct i2c_client *client);
+ static int foo_probe(struct i2c_client *client,
+const struct i2c_device_id *id);
static int foo_remove(struct i2c_client *client);
Remember that the i2c_driver does not create those client handles. The
--- linux-2.6.26-rc0.orig/drivers/gpio/pca953x.c2008-04-27
22:05:00.0 +0200
+++ linux-2.6.26-rc0/drivers/gpio/pca953x.c 2008-04-27 22:09:29.0
+0200
@@ -191,7 +191,8 @@ static void pca953x_setup_gpio(struct pc
gc->label = chip->client->name;
}
-static int __devinit pca953x_probe(struct i2c_client *client)
+static int __devinit pca953x_probe(struct i2c_client *client,
+ const struct i2c_device_id *did)
{
struct pca953x_platform_data *pdata;
struct pca953x_chip *chip;
--- linux-2.6.26-rc0.orig/drivers/gpio/pcf857x.c2008-04-27
22:05:00.0 +0200
+++ linux-2.6.26-rc0/drivers/gpio/pcf857x.c 2008-04-27 22:09:29.0
+0200
@@ -142,7 +142,8 @@ static void pcf857x_set16(struct gpio_ch
/*-*/
-sta
[PATCH 0/2] i2c: Add support for device alias names
Hi all, This is an updated, minimal patchset to add support for device alias names to the i2c subsystem. It is based on earlier work by Jon Smirl, Jochen Friedrich and myself. For 2.6.26-rc1 I'll only attempt to push the first two patches: the one adding the support for alias names and the one converting the drivers to make use of it. I've even excluded most of the video drivers from this patch, as they are a bit more difficult to deal with and I don't want to break them for rc1. This will come later, together with the patch removing the old device/driver matching scheme. I've fixed a number of bugs since the previous iteration, and added a few missing chunks as well. I hope I caught all the pieces this time but that's hard to tell given that much of the changes are in arch code I can't even build. So I would like everyone interested in these two patches getting in 2.6.26-rc1 to give them good testing on as many systems as possible, and report to me, ideally by the end of the day. Sorry for the short notice, but I did my best with the little spare time I had. Note that there are RTC patches pending for upstream merge, which will conflict with my patches. Andrew Morton should push them to Linus today, so that I can rebase my patches before I send them to Linus (tomorrow). The current versions of the patches apply on top of 2.6.26-git11. Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] i2c: Add support for device alias names
On 4/28/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Based on earlier work by Jon Smirl and Jochen Friedrich.
>
> This patch allows new-style i2c chip drivers to have alias names using
> the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this
> point, the old i2c driver binding scheme (driver_name/type) is still
> supported.
>
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
> Cc: Jochen Friedrich <[EMAIL PROTECTED]>
> Cc: Jon Smirl <[EMAIL PROTECTED]>
> Cc: Kay Sievers <[EMAIL PROTECTED]>
> ---
> One thing I am still not happy with is that the aliases created have a
> trailing "*":
>
> $ /sbin/modinfo lm90
> filename: /lib/modules/2.6.25-git11/kernel/drivers/hwmon/lm90.ko
> author: Jean Delvare <[EMAIL PROTECTED]>
> description:LM90/ADM1032 driver
> license:GPL
> vermagic: 2.6.25-git11 mod_unload
> depends:hwmon
> alias: i2c:lm90*
> alias: i2c:adm1032*
> alias: i2c:lm99*
> alias: i2c:lm86*
> alias: i2c:max6657*
> alias: i2c:adt7461*
> alias: i2c:max6680*
> $
>
> This would cause trouble if one I2C chip name matches the beginning of
> another I2C chip name and both chips are supported by different
> drivers. This has yet to be seen, but still, I'd like to see this
> problem fixed quickly.
Trailing wildcard is always added by file2alias.c:
if (do_entry(mod->name, symval+i, alias)) {
/* Always end in a wildcard, for future extension */
if (alias[strlen(alias)-1] != '*')
strcat(alias, "*");
Can't the match order be controlled in the makefile? For example if
you had lm905* and lm90*, put lm905* into into the makefile first
which will cause it to appear in the alias file first. But that would
still cause problems if only lm90 was built and you had a lm905
device.
Alternatively you could change the code to append something like a
period to the name string.
sprintf(alias, I2C_MODULE_PREFIX "%s.", id->name);
I was using macros to alter the name strings to move the PowerPC names
into their own namespace.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add fast little-endian switch system call
Please see Michael Kerrisk on userspace ABI updates. A nice little manpage for this gimmick would be helpful, and maybe help other platforms that want one aswell to implement the same API. On Mon, Apr 28, 2008 at 01:52:31PM +1000, Paul Mackerras wrote: > This adds a system call on 64-bit platforms for switching between > little-endian and big-endian modes that is much faster than doing a > prctl call. This system call is handled as a special case right at > the start of the system call entry code, and because it is a special > case, it uses a system call number which is out of the range of > normal system calls, namely 0x1ebe. > > Measurements with lmbench on a 4.2GHz POWER6 showed no measurable > change in the speed of normal system calls with this patch. > > Switching endianness with this new system call takes around 60ns on a > 4.2GHz POWER6, compared with around 300ns to switch endian mode with a > prctl. This can provide a significant performance advantage for > emulators for little-endian architectures that want to switch between > big-endian and little-endian mode frequently, e.g. because they are > generating instructions sequences on the fly and they want to run > those sequences in little-endian mode. > > Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> > --- > > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S > index 215973a..2eb49a7 100644 > --- a/arch/powerpc/kernel/head_64.S > +++ b/arch/powerpc/kernel/head_64.S > @@ -239,6 +239,10 @@ instruction_access_slb_pSeries: > .globl system_call_pSeries > system_call_pSeries: > HMT_MEDIUM > +BEGIN_FTR_SECTION > + cmpdi r0,0x1ebe > + beq-1f > +END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE) Am I missing something here or does this add a branch for every normal syscall? > mr r9,r13 > mfmsr r10 > mfspr r13,SPRN_SPRG3 > @@ -253,6 +257,13 @@ system_call_pSeries: > rfid > b . /* prevent speculative execution */ > > +/* Fast LE/BE switch system call */ > +1: mfspr r12,SPRN_SRR1 > + xorir12,r12,MSR_LE > + mtspr SPRN_SRR1,r12 > + rfid/* return to userspace */ > + b . > + > STD_EXCEPTION_PSERIES(0xd00, single_step) > STD_EXCEPTION_PSERIES(0xe00, trap_0e) > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ---end quoted text--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] i2c: Add support for device alias names
On Mon, 2008-04-28 at 11:39 +0200, Jean Delvare wrote: > Based on earlier work by Jon Smirl and Jochen Friedrich. > > This patch allows new-style i2c chip drivers to have alias names using > the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this > point, the old i2c driver binding scheme (driver_name/type) is still > supported. > > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> > Cc: Jochen Friedrich <[EMAIL PROTECTED]> > Cc: Jon Smirl <[EMAIL PROTECTED]> > Cc: Kay Sievers <[EMAIL PROTECTED]> > --- > One thing I am still not happy with is that the aliases created have a > trailing "*": > > $ /sbin/modinfo lm90 > filename: /lib/modules/2.6.25-git11/kernel/drivers/hwmon/lm90.ko > author: Jean Delvare <[EMAIL PROTECTED]> > description:LM90/ADM1032 driver > license:GPL > vermagic: 2.6.25-git11 mod_unload > depends:hwmon > alias: i2c:lm90* > alias: i2c:adm1032* > alias: i2c:lm99* > alias: i2c:lm86* > alias: i2c:max6657* > alias: i2c:adt7461* > alias: i2c:max6680* > $ > > This would cause trouble if one I2C chip name matches the beginning of > another I2C chip name and both chips are supported by different > drivers. This has yet to be seen, but still, I'd like to see this > problem fixed quickly. Right, the trailing "*" is not nice. We should terminate the string, so the trailing "*" will not match longer strings. The usual thing is to add a ":" to the end, which would then show up as alias: i2c:max6680:* See DMI and ACPI: alias dmi:*:svnFUJITSU:pnLifeBook*:pvr*:rvnFUJITSU:* apanel alias acpi*:ASIM:* atlas_btns If i2c device modaliases could ever contain multiple strings, it should be: alias: i2c*:max6680:* to match the module, regardless of the order of the strings in the modalias: Thanks, Kay ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: filenames with spaces in /sys?
On Sun, Apr 27, 2008 at 08:35:51PM +0200, Christian Kujau wrote: > I was a bit puzzled today when I came across > /sys/devices/platform/pmu-battery.0/power_supply/PMU battery 0/power > and thought to myself: why are there spaces in "PMU battery 0"? Why not? > Wouldn't ../pmu-battery.0/power_supply/PMU_battery_0/power be feasible too? Feasible, yes, but uglier, and as you point out, changing it now would risk breaking userspace for little gain. > I find it rather annoying to special case the spaces whenever to look > for something in /sys, when I'm so used not to when doing the same > find/grep/xargs stuff in /usr/src/linux. If userspace tools make it awkward to deal with filenames with spaces, let's fix the userspace tools. /sys is certainly not the only place they'll be found, and waging war against them is a battle best left for a couple decades ago. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC, PATCH 0/7] Power management patches from Scott Wood plus MPC8241 Linkstation
Hi all as replies to this email I'm going to post a respin of the last version from December 2007 of Scott's patches plus my patch for Linkstation standby. Scott, I upgraded your patches, please, verify, that they still function. I added my Sof's as I'm now forwarding them, I believe, this is correct. I tried to preserve original CC lists. Knowing how important power management on ARM systems is I'm a bit confused about why this is not the case on _embedded_ powerpc. Thanks Guennadi --- Guennadi Liakhovetski ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/7] pm: Add TLF_SLEEPING hack to delay interrupt delivery when waking from sleep.
The e300 core (and probably most other 6xx chips) can only come out of sleep mode with an interrupt. However, interrupts are logically disabled by the power management layer. This hack extends the existing doze/nap hack to also suppress the running of the interrupt handler when in sleep mode. Signed-off-by: Scott Wood <[EMAIL PROTECTED]> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> --- arch/powerpc/kernel/entry_32.S|6 ++-- arch/powerpc/kernel/idle_6xx.S| 41 - include/asm-powerpc/thread_info.h |2 + 3 files changed, 45 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 69a91bd..4099a6f 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -138,8 +138,8 @@ transfer_to_handler: #ifdef CONFIG_6xx tophys(r9,r9) /* check local flags */ lwz r12,TI_LOCAL_FLAGS(r9) - mtcrf 0x01,r12 - bt- 31-TLF_NAPPING,4f + andi. r8, r12, _TLF_NAPPING | _TLF_SLEEPING + bne-4f #endif /* CONFIG_6xx */ .globl transfer_to_handler_cont transfer_to_handler_cont: @@ -154,7 +154,7 @@ transfer_to_handler_cont: RFI /* jump to handler, enable MMU */ #ifdef CONFIG_6xx -4: rlwinm r12,r12,0,~_TLF_NAPPING +4: rlwinm r12,r12,0,~(_TLF_NAPPING | _TLF_SLEEPING) stw r12,TI_LOCAL_FLAGS(r9) b power_save_6xx_restore #endif diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S index 01bcd52..341f474 100644 --- a/arch/powerpc/kernel/idle_6xx.S +++ b/arch/powerpc/kernel/idle_6xx.S @@ -147,16 +147,30 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) isync b 1b +#ifdef CONFIG_SUSPEND +ret_from_sleep: + .long ret_from_except + .long ret_from_except +#endif + /* * Return from NAP/DOZE mode, restore some CPU specific registers, * we are called with DR/IR still off and r2 containing physical * address of current. R11 points to the exception frame (physical - * address). We have to preserve r10. + * address). r8 contains _TLF_NAPPING or _TLF_SLEEPING. We have to + * preserve r10. */ _GLOBAL(power_save_6xx_restore) lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */ +#ifdef CONFIG_SUSPEND + andi. r12, r8, _TLF_SLEEPING +#endif stw r9,_NIP(r11)/* make it do a blr */ +#ifdef CONFIG_SUSPEND + bne-sleep_6xx_restore +#endif + #ifdef CONFIG_SMP mfspr r12,SPRN_SPRG3 lwz r11,TI_CPU(r12) /* get cpu number * 4 */ @@ -185,6 +199,31 @@ BEGIN_FTR_SECTION END_FTR_SECTION_IFSET(CPU_FTR_DUAL_PLL_750FX) b transfer_to_handler_cont +#ifdef CONFIG_SUSPEND +sleep_6xx_restore: + /* +* SLEEP mode is invoked through the PM subsystem, which means +* that interrupts should be disabled. However, the hardware +* requires them to be enabled to wake up. To prevent the +* interrupt from being visible to Linux, return immediately +* rather than run the interrupt handler. +*/ + lis r9, [EMAIL PROTECTED] + ori r9, r9, [EMAIL PROTECTED] + tophys(r9, r9) + mtlrr9 + + /* +* Disable interrupts, so that the interrupt doesn't happen +* again until the PM code sets MSR[EE]. +*/ + lwz r9, _MSR(r11) + rlwinm r9, r9, 0, ~MSR_EE + stw r9, _MSR(r11) + + b transfer_to_handler_cont +#endif + .data _GLOBAL(nap_save_msscr0) diff --git a/include/asm-powerpc/thread_info.h b/include/asm-powerpc/thread_info.h index 40d5f98..f7cb48b 100644 --- a/include/asm-powerpc/thread_info.h +++ b/include/asm-powerpc/thread_info.h @@ -151,8 +151,10 @@ static inline struct thread_info *current_thread_info(void) /* Bits in local_flags */ /* Don't move TLF_NAPPING without adjusting the code in entry_32.S */ #define TLF_NAPPING0 /* idle thread enabled NAP mode */ +#define TLF_SLEEPING 1 /* suspend code enabled SLEEP mode */ #define _TLF_NAPPING (1 << TLF_NAPPING) +#define _TLF_SLEEPING (1 << TLF_SLEEPING) #endif /* __KERNEL__ */ -- 1.5.3.7 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/7] Add 6xx-style HID0_SLEEP support.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/6xx-suspend.S | 52 + arch/powerpc/sysdev/Makefile |4 +++ include/asm-powerpc/mpc6xx.h |6 3 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/sysdev/6xx-suspend.S create mode 100644 include/asm-powerpc/mpc6xx.h diff --git a/arch/powerpc/sysdev/6xx-suspend.S b/arch/powerpc/sysdev/6xx-suspend.S new file mode 100644 index 000..21cda08 --- /dev/null +++ b/arch/powerpc/sysdev/6xx-suspend.S @@ -0,0 +1,52 @@ +/* + * Enter and leave sleep state on chips with 6xx-style HID0 + * power management bits, which don't leave sleep state via reset. + * + * Author: Scott Wood <[EMAIL PROTECTED]> + * + * Copyright (c) 2006-2007 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include +#include +#include +#include + +_GLOBAL(mpc6xx_enter_standby) + mflrr4 + + mfspr r5, SPRN_HID0 + rlwinm r5, r5, 0, ~(HID0_DOZE | HID0_NAP) + orisr5, r5, [EMAIL PROTECTED] + mtspr SPRN_HID0, r5 + isync + + lis r5, [EMAIL PROTECTED] + ori r5, r5, [EMAIL PROTECTED] + mtlrr5 + + rlwinm r5, r1, 0, 0, 31-THREAD_SHIFT + lwz r6, TI_LOCAL_FLAGS(r5) + ori r6, r6, _TLF_SLEEPING + stw r6, TI_LOCAL_FLAGS(r5) + + mfmsr r5 + ori r5, r5, MSR_EE + orisr5, r5, [EMAIL PROTECTED] + sync + mtmsr r5 + isync + +1: b 1b + +ret_from_standby: + mfspr r5, SPRN_HID0 + rlwinm r5, r5, 0, ~HID0_SLEEP + mtspr SPRN_HID0, r5 + + mtlrr4 + blr diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile index 99a77d7..df2b885 100644 --- a/arch/powerpc/sysdev/Makefile +++ b/arch/powerpc/sysdev/Makefile @@ -37,3 +37,7 @@ obj-$(CONFIG_PPC_DCR) += dcr.o obj-$(CONFIG_8xx) += mpc8xx_pic.o cpm1.o obj-$(CONFIG_UCODE_PATCH) += micropatch.o endif + +ifeq ($(CONFIG_SUSPEND),y) +obj-$(CONFIG_6xx) += 6xx-suspend.o +endif diff --git a/include/asm-powerpc/mpc6xx.h b/include/asm-powerpc/mpc6xx.h new file mode 100644 index 000..effc229 --- /dev/null +++ b/include/asm-powerpc/mpc6xx.h @@ -0,0 +1,6 @@ +#ifndef __ASM_POWERPC_MPC6xx_H +#define __ASM_POWERPC_MPC6xx_H + +void mpc6xx_enter_standby(void); + +#endif -- 1.5.3.7 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/7] mpc83xx: Power Management support
Basic PM support for 83xx. Standby is implemented as sleep. Suspend-to-RAM is implemented as "deep sleep" (with the processor turned off) on 831x. Signed-off-by: Scott Wood <[EMAIL PROTECTED]> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> --- The enabling of i-cache at the end of the suspend code somehow fell off of the code that was sent out in the previous patch (it still works when booting high, which is what I tested, but not booting low). The rest of the patchset stays the same. arch/powerpc/platforms/83xx/Kconfig |5 + arch/powerpc/platforms/83xx/Makefile |1 + arch/powerpc/platforms/83xx/suspend-asm.S | 539 + arch/powerpc/platforms/83xx/suspend.c | 423 ++ arch/powerpc/sysdev/fsl_soc.c | 33 ++ arch/powerpc/sysdev/fsl_soc.h | 10 + arch/powerpc/sysdev/ipic.c| 71 include/asm-powerpc/reg.h |4 + include/linux/fsl_devices.h | 24 ++ 9 files changed, 1110 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/platforms/83xx/suspend-asm.S create mode 100644 arch/powerpc/platforms/83xx/suspend.c diff -u a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -192,7 +192,7 @@ config ARCH_HIBERNATION_POSSIBLE config ARCH_SUSPEND_POSSIBLE def_bool y - depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 + depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx config PPC_DCR_NATIVE bool diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig index ec305f1..901dbaf 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -6,6 +6,11 @@ menuconfig MPC83xx if MPC83xx +config PPC_83xx_SUSPEND + bool + default y + depends on SUSPEND + config MPC831x_RDB bool "Freescale MPC831x RDB" select DEFAULT_UIMAGE diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile index 5a98f88..944369e 100644 --- a/arch/powerpc/platforms/83xx/Makefile +++ b/arch/powerpc/platforms/83xx/Makefile @@ -3,6 +3,7 @@ # obj-y := misc.o usb.o obj-$(CONFIG_PCI) += pci.o +obj-$(CONFIG_SUSPEND) += suspend.o suspend-asm.o obj-$(CONFIG_MPC831x_RDB) += mpc831x_rdb.o obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o obj-$(CONFIG_MPC834x_MDS) += mpc834x_mds.o diff --git a/arch/powerpc/platforms/83xx/suspend-asm.S b/arch/powerpc/platforms/83xx/suspend-asm.S new file mode 100644 index 000..03e29a2 --- /dev/null +++ b/arch/powerpc/platforms/83xx/suspend-asm.S @@ -0,0 +1,539 @@ +/* + * Enter and leave sleep state on MPC83xx + * + * Author: Scott Wood <[EMAIL PROTECTED]> + * + * Copyright (c) 2006 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include +#include +#include +#include + +#define SS_MEMSAVE 0x00 +#define SS_HID 0x08 /* 3 HIDs */ +#define SS_IABR0x14 /* 2 IABRs */ +#define SS_IBCR0x1c +#define SS_DABR0x20 /* 2 DABRs */ +#define SS_DBCR0x28 +#define SS_SP 0x2c +#define SS_SR 0x30 /* 16 segment registers */ +#define SS_CURRENT 0x70 +#define SS_MSR 0x74 +#define SS_SDR10x78 +#define SS_LR 0x7c +#define SS_SPRG0x80 /* 4 SPRGs */ +#define SS_DBAT0x90 /* 8 DBATs */ +#define SS_IBAT0xd0 /* 8 IBATs */ +#define SS_TB 0x110 +#define SS_CR 0x118 +#define SS_GPREG 0x11c /* r12-r31 */ +#define STATE_SAVE_SIZE 0x16c + + .section .data + .align 5 + +mpc83xx_sleep_save_area: + .space STATE_SAVE_SIZE +immrbase: + .long 0 + + .section .text + .align 5 + + /* r3 = physical address of IMMR */ +_GLOBAL(mpc83xx_enter_deep_sleep) + /* Re-use the state saving/restoring code in +* arch/powerpc/kernel/swsusp_32.S, but have +* it call us instead of swsusp_save. +*/ + + lis r4, [EMAIL PROTECTED] + stw r3, [EMAIL PROTECTED](r4) + + /* The first 2 words of memory are used to communicate with the +* bootloader, to tell it how to resume. +* +* The first word is the magic number 0xf5153ae5, and the second +* is the pointer to mpc83xx_deep_resume. +* +* The original content of these two words is saved in the state +* save area. +*/ + + lis r3, [EMAIL PROTECTED] + ori r3, r3, [EMAIL PROTECTED] + + lis r4, [EMAIL PROTECTED] + lwz r5, 0(r4) + lwz r6, 4(r4) + + stw r5, SS_MEMSAVE+0(r3) + stw r6, SS_
[PATCH 4/7] mpc83xx: timer driver for PM wakeup
This is a driver for the mpc83xx's GTM4 timer. It's functionality
is limited to providing a wakeup source for suspend-to-RAM.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/83xx/Kconfig |9 +
arch/powerpc/platforms/83xx/Makefile |1 +
arch/powerpc/platforms/83xx/timer.c | 299 ++
3 files changed, 309 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/83xx/timer.c
diff --git a/arch/powerpc/platforms/83xx/Kconfig
b/arch/powerpc/platforms/83xx/Kconfig
index 901dbaf..800f547 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -80,6 +80,15 @@ config PPC_83xx_SUSPEND
This option enables support for the Wind River SBC834x board.
endif
+
+config MPC83xx_GTM
+ tristate "83xx General-Purpose Timers for PM wakeup"
+ help
+ This enables a driver for the GTM4 timer, to be used
+ as a wakeup source for suspend-to-RAM. To arm the
+ timer, write the number of seconds until expiration
+ to the "timeout" file in the device's sysfs directory.
+ To disarm, write 0 to the "timeout" file.
# used for usb
config PPC_MPC831x
diff --git a/arch/powerpc/platforms/83xx/Makefile
b/arch/powerpc/platforms/83xx/Makefile
index 944369e..bcc1003 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -4,6 +4,7 @@
obj-y := misc.o usb.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_SUSPEND) += suspend.o suspend-asm.o
+obj-$(CONFIG_MPC83xx_GTM) += timer.o
obj-$(CONFIG_MPC831x_RDB) += mpc831x_rdb.o
obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o
obj-$(CONFIG_MPC834x_MDS) += mpc834x_mds.o
diff --git a/arch/powerpc/platforms/83xx/timer.c
b/arch/powerpc/platforms/83xx/timer.c
new file mode 100644
index 000..7fc6048
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/timer.c
@@ -0,0 +1,300 @@
+/*
+ * MPC83xx Global Timer4 support
+ *
+ * This driver is currently specific to timer 4 in 16-bit mode,
+ * as that is all that can be used as a wakeup source for deep sleep
+ * on the MPC8313.
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define MDR_ICLK_DIV16 0x0004
+
+struct gtm_regs {
+ u8cfr1; /* Timer1/2 Configuration */
+ #define CFR1_PCAS 0x80 /* Pair Cascade mode */
+ #define CFR1_BCM 0x40 /* Backward compatible mode */
+ #define CFR1_STP2 0x20 /* Stop timer */
+ #define CFR1_RST2 0x10 /* Reset timer */
+ #define CFR1_GM2 0x08 /* Gate mode for pin 2 */
+ #define CFR1_GM1 0x04 /* Gate mode for pin 1 */
+ #define CFR1_STP1 0x02 /* Stop timer */
+ #define CFR1_RST1 0x01 /* Reset timer */
+ #define CFR1_RES ~(CFR1_PCAS | CFR1_STP2 | CFR1_RST2 | CFR1_GM2 |\
+ CFR1_GM1 | CFR1_STP1 | CFR1_RST1)
+
+ u8res0[3];
+ u8cfr2; /* Timer3/4 Configuration */
+ #define CFR2_PCAS 0x80 /* Pair Cascade mode */
+ #define CFR2_SCAS 0x40 /* Super Cascade mode */
+ #define CFR2_STP4 0x20 /* Stop timer */
+ #define CFR2_RST4 0x10 /* Reset timer */
+ #define CFR2_GM4 0x08 /* Gate mode for pin 4 */
+ #define CFR2_GM3 0x04 /* Gate mode for pin 3 */
+ #define CFR2_STP3 0x02 /* Stop timer */
+ #define CFR2_RST3 0x01 /* Reset timer */
+
+ u8res1[11];
+ u16 mdr1; /* Timer1 Mode Register */
+ #define MDR_SPS 0xff00 /* Secondary Prescaler value (256) */
+ #define MDR_CE 0x00c0 /* Capture edge and enable interrupt */
+ #define MDR_OM 0x0020 /* Output mode */
+ #define MDR_ORI 0x0010 /* Output reference interrupt enable */
+ #define MDR_FRR 0x0008 /* Free run/restart */
+ #define MDR_ICLK 0x0006 /* Input clock source for the timer */
+ #define MDR_GE 0x0001 /* Gate enable */
+
+ u16 mdr2; /* Timer2 Mode Register */
+ u16 rfr1; /* Timer1 Reference Register */
+ u16 rfr2; /* Timer2 Reference Register */
+ u16 cpr1; /* Timer1 Capture Register */
+ u16 cpr2; /* Timer2 Capture Register */
+ u16 cnr1; /* Timer1 Counter Register */
+ u16 cnr2; /* Timer2 Counter Register */
+ u16 mdr3; /* Timer3 Mode Register */
+ u16 mdr4; /* Timer4 Mode Register */
+ u16 rfr3; /* Timer3 Reference Register */
+ u16 rfr4; /* Timer4 Reference Register */
+ u16 cpr3; /* Timer3 Capture Register */
+ u16 cpr4; /* Timer4 C
[PATCH 5/7] gianfar: Add flags for magic packet and MDIO.
The magic packet flag indicates that the hardware has this
capability. The MDIO flag indicates that this device's
registers contain active MDIO registers, and thus this
device should not be put to sleep.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c |7 +++
include/linux/fsl_devices.h |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index d5fd916..032b8e8 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -324,6 +324,9 @@ static int __init gfar_of_init(void)
else
gfar_data.interface = PHY_INTERFACE_MODE_MII;
+ if (of_get_property(np, "fsl,magic-packet", NULL))
+ gfar_data.device_flags |=
FSL_GIANFAR_DEV_HAS_MAGIC_PACKET;
+
ph = of_get_property(np, "phy-handle", NULL);
if (ph == NULL) {
u32 *fixed_link;
@@ -345,6 +348,10 @@ static int __init gfar_of_init(void)
snprintf(gfar_data.bus_id, MII_BUS_ID_SIZE, "%x",
res.start);
+ if (res.start >= gfar_dev->resource[0].start &&
+ res.start < gfar_dev->resource[0].end)
+ gfar_data.device_flags |=
FSL_GIANFAR_DEV_HAS_MDIO;
+
of_node_put(phy);
of_node_put(mdio);
}
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 5cec939..81fcc67 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -87,6 +87,8 @@ struct gianfar_mdio_data {
#define FSL_GIANFAR_DEV_HAS_VLAN 0x0020
#define FSL_GIANFAR_DEV_HAS_EXTENDED_HASH 0x0040
#define FSL_GIANFAR_DEV_HAS_PADDING0x0080
+#define FSL_GIANFAR_DEV_HAS_MAGIC_PACKET 0x0100
+#define FSL_GIANFAR_DEV_HAS_MDIO 0x0200
/* Flags in gianfar_platform_data */
#define FSL_GIANFAR_BRD_HAS_PHY_INTR 0x0001 /* set or use a timer */
--
1.5.3.7
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/7] gianfar: Magic Packet and suspend/resume support.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
This patch has already been acked by Jeff Garzik:
>From [EMAIL PROTECTED] Fri Dec 14 20:28:38 2007
Date: Fri, 14 Dec 2007 15:24:29 -0500
From: Jeff Garzik <[EMAIL PROTECTED]>
To: Scott Wood <[EMAIL PROTECTED]>
Cc: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PATCH 8/8] gianfar: Magic Packet and suspend/resume support.
Scott Wood wrote:
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
> ---
> Jeff, can you ack this to go through Paul's tree
> (assuming nothing wrong with it)?
>
> drivers/net/gianfar.c | 137
> -
> drivers/net/gianfar.h | 13 +++-
> drivers/net/gianfar_ethtool.c | 41 -
> 3 files changed, 185 insertions(+), 6 deletions(-)
ACK
drivers/net/gianfar.c | 137 -
drivers/net/gianfar.h | 13 +++-
drivers/net/gianfar_ethtool.c | 41 -
3 files changed, 185 insertions(+), 6 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 0431e9e..2c1b8d5 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -142,6 +142,7 @@ int gfar_clean_rx_ring(struct net_device *dev, int
rx_work_limit);
static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb, int
length);
static void gfar_vlan_rx_register(struct net_device *netdev,
struct vlan_group *grp);
+static void gfar_halt_nodisable(struct net_device *dev);
void gfar_halt(struct net_device *dev);
void gfar_start(struct net_device *dev);
static void gfar_clear_exact_match(struct net_device *dev);
@@ -216,6 +217,7 @@ static int gfar_probe(struct platform_device *pdev)
spin_lock_init(&priv->txlock);
spin_lock_init(&priv->rxlock);
+ spin_lock_init(&priv->bflock);
platform_set_drvdata(pdev, dev);
@@ -393,6 +395,122 @@ static int gfar_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int gfar_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+ struct gfar_private *priv = netdev_priv(dev);
+ unsigned long flags;
+ u32 tempval;
+
+ int magic_packet = priv->wol_en &&
+ (priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
+
+ netif_device_detach(dev);
+
+ if (netif_running(dev)) {
+ spin_lock_irqsave(&priv->txlock, flags);
+ spin_lock(&priv->rxlock);
+
+ gfar_halt_nodisable(dev);
+
+ /* Disable Tx, and Rx if wake-on-LAN is disabled. */
+ tempval = gfar_read(&priv->regs->maccfg1);
+
+ tempval &= ~MACCFG1_TX_EN;
+
+ if (!magic_packet)
+ tempval &= ~MACCFG1_RX_EN;
+
+ gfar_write(&priv->regs->maccfg1, tempval);
+
+ spin_unlock(&priv->rxlock);
+ spin_unlock_irqrestore(&priv->txlock, flags);
+
+#ifdef CONFIG_GFAR_NAPI
+ napi_disable(&priv->napi);
+#endif
+
+ if (magic_packet) {
+ /* Enable interrupt on Magic Packet */
+ gfar_write(&priv->regs->imask, IMASK_MAG);
+
+ /* Enable Magic Packet mode */
+ tempval = gfar_read(&priv->regs->maccfg2);
+ tempval |= MACCFG2_MPEN;
+ gfar_write(&priv->regs->maccfg2, tempval);
+ } else {
+ phy_stop(priv->phydev);
+ }
+ }
+
+ if (!magic_packet || !netif_running(dev)) {
+ /* The device with the MDIO in its register block must
+* not be put to sleep if any other network devices
+* using the same MDIO are active. Ideally, some sort
+* of reference counting could be done, but for now
+* just don't put the MDIO-containing dev to sleep
+* at all.
+*/
+ if (!(priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_MDIO)) {
+ fsl_sleep_device(&priv->einfo->sleep);
+ priv->suspended = 1;
+ }
+ }
+
+ return 0;
+}
+
+static int gfar_resume(struct platform_device *pdev)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+ struct gfar_private *priv = netdev_priv(dev);
+ unsigned long flags;
+ u32 tempval;
+ int magic_packet = priv->wol_en &&
+ (priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
+
+ if (priv->suspended) {
+ fsl_wake_device(&priv->einfo->sleep);
+ priv->suspended = 0;
+ }
+
+ if (!netif_running(dev)) {
+ netif_device_attach(dev);
+ return 0;
+ }
+
+ if (!magic_packe
[PATCH 7/7] linkstation: implement standby
Implement suspend/resume for "mpc10x" compatible fsl host PCI controllers,
use it for linkstation standby. This is version 3, updated to the current
powerpc git tree. Depends as before on TLF_SLEEPING and HID0_SLEEP patches
from Scott Wood.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 20f45a8..693da18 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -192,7 +192,7 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
- depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx
+ depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx ||
MPC10X_BRIDGE
config PPC_DCR_NATIVE
bool
diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c
b/arch/powerpc/platforms/embedded6xx/linkstation.c
index eb5d74e..3bab51f 100644
--- a/arch/powerpc/platforms/embedded6xx/linkstation.c
+++ b/arch/powerpc/platforms/embedded6xx/linkstation.c
@@ -197,3 +197,54 @@ define_machine(linkstation){
.halt = linkstation_halt,
.calibrate_decr = generic_calibrate_decr,
};
+
+#ifdef CONFIG_PM_SLEEP
+
+#include
+#include
+#include
+#include
+
+static int ls_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+static int ls_pm_enter(suspend_state_t state)
+{
+ u64 tb;
+
+ /* Get timebase */
+ tb = get_tb();
+
+ /* put CPU to sleep, re-enabling interrupts */
+ mpc6xx_enter_standby();
+
+ local_irq_disable();
+
+ set_tb(tb >> 32, tb & 0xul);
+
+ return 0;
+}
+
+static struct platform_suspend_ops ls_pm_ops = {
+ .valid = ls_pm_valid,
+ .enter = ls_pm_enter,
+};
+
+static int __init ls_pm_init(void)
+{
+ if (!machine_is(linkstation))
+ return -ENODEV;
+
+ suspend_set_ops(&ls_pm_ops);
+ return 0;
+}
+
+device_initcall(ls_pm_init);
+#endif
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 72fb35b..4df3230 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -6,3 +6,6 @@ config PPC4xx_PCI_EXPRESS
bool
depends on PCI && 4xx
default n
+
+config MPC10X_PM
+ def_bool FSL_SOC && PCI && PM_SLEEP
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 2cc5052..0b90cc8 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -48,3 +48,5 @@ endif
ifeq ($(CONFIG_SUSPEND),y)
obj-$(CONFIG_6xx) += 6xx-suspend.o
endif
+
+obj-$(CONFIG_MPC10X_PM)+= mpc10x_pm.o
diff -u /dev/null b/arch/powerpc/sysdev/mpc10x_pm.c
new file mode 100644
index 000..6bd773b
--- /dev/null 2008-04-28 10:35:13.531006534 +0200
+++ b/arch/powerpc/sysdev/mpc10x_pm.c 2008-04-25 21:18:19.0 +0200
@@ -0,0 +1,73 @@
+/*
+ * Power-management driver for MPC8241 host-PCI controller
+ *
+ * Copyright (C) 2007 G. Liakhovetski ([EMAIL PROTECTED])
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of
+ * any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#defineMPC10X_LP_REF_EN(1<<12)
+#defineMPC10X_PM (1<<7)
+#define MPC10X_DOZE(1<<5)
+#defineMPC10X_NAP (1<<4)
+#defineMPC10X_SLEEP(1<<3)
+
+static int __devinit mpc10x_pm_probe(struct pci_dev *pdev,
+const struct pci_device_id *id)
+{
+ return 0;
+}
+
+static int mpc10x_pm_suspend_late(struct pci_dev *dev, pm_message_t state)
+{
+ u16 pmcr1;
+
+ pci_read_config_word(dev, 0x70, &pmcr1);
+ pmcr1 &= ~(MPC10X_DOZE | MPC10X_NAP);
+ pmcr1 |= MPC10X_PM | MPC10X_SLEEP | MPC10X_LP_REF_EN;
+ pci_write_config_word(dev, 0x70, pmcr1);
+
+ return 0;
+}
+
+static int mpc10x_pm_resume_early(struct pci_dev *dev)
+{
+ u16 pmcr1;
+
+ pci_read_config_word(dev, 0x70, &pmcr1);
+ pmcr1 &= ~(MPC10X_PM | MPC10X_DOZE | MPC10X_SLEEP | MPC10X_NAP |
MPC10X_LP_REF_EN);
+ pci_write_config_word(dev, 0x70, pmcr1);
+
+ return 0;
+}
+
+static struct pci_device_id mpc10x_pm_pci_tbl[] = {
+ { PCI_VENDOR_ID_MOTOROLA, PCI_DEVICE_ID_MOTOROLA_MPC8241,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(pci, mpc10x_pm_pci_tbl);
+
+static struct pci_driver mpc10x_pm_driver = {
+ .name = "mpc10x-pm",
+ .id_table = mpc10x_pm_pci_tbl,
+ .resume_early = mpc10x_pm_resume_early,
+ .suspend_late = mpc10x_pm_suspend_late,
+ .probe = mpc10x_pm_probe,
+};
+
+static int __init mpc10x_pm_init(void)
+{
+ return pci_register_driver(&mpc10x_pm_driver);
Re: [PATCH 1/2] i2c: Add support for device alias names
Hi Kay, On Mon, 28 Apr 2008 17:07:25 +0200, Kay Sievers wrote: > On Mon, 2008-04-28 at 11:39 +0200, Jean Delvare wrote: > > One thing I am still not happy with is that the aliases created have a > > trailing "*": > > > > $ /sbin/modinfo lm90 > > filename: /lib/modules/2.6.25-git11/kernel/drivers/hwmon/lm90.ko > > author: Jean Delvare <[EMAIL PROTECTED]> > > description:LM90/ADM1032 driver > > license:GPL > > vermagic: 2.6.25-git11 mod_unload > > depends:hwmon > > alias: i2c:lm90* > > alias: i2c:adm1032* > > alias: i2c:lm99* > > alias: i2c:lm86* > > alias: i2c:max6657* > > alias: i2c:adt7461* > > alias: i2c:max6680* > > $ > > > > This would cause trouble if one I2C chip name matches the beginning of > > another I2C chip name and both chips are supported by different > > drivers. This has yet to be seen, but still, I'd like to see this > > problem fixed quickly. > > Right, the trailing "*" is not nice. > > We should terminate the string, so the trailing "*" will not match > longer strings. The usual thing is to add a ":" to the end, which would > then show up as > alias: i2c:max6680:* > > See DMI and ACPI: > alias dmi:*:svnFUJITSU:pnLifeBook*:pvr*:rvnFUJITSU:* apanel > alias acpi*:ASIM:* atlas_btns I didn't know about these cases, thanks for the hint. > > If i2c device modaliases could ever contain multiple strings, it should > be: > alias: i2c*:max6680:* > to match the module, regardless of the order of the strings in the > modalias: Why would i2c device modaliases ever contain multiple strings? A device can't have multiple names, can it? Adding a ":" at the end of the i2c device names solves the problem I was mentioning, sure, but why don't we simply remove the trailing "*", instead of trying to work around it? A trailing "*" simply makes no sense for aliases which are simple device names. This is not only i2c devices, but also platform devices, acpi, dmi, pnp... Looking at the various device types handled by file2alias.c, it seems that most of them don't need the trailing "*", and many of them have the problem I was mentioning. Can't we just stop handle_moddevtable() from adding a tailing "*" automatically, and just let the device types which need it, add it on their own? Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
suggestions on handling additional exception levels on ppc32
I'm looking at fixing an issue parts that have multiple exception levels (e300, 40x, booke). One of the issues is the transfer_to_handler patch in entry_32.S doesn't use the proper save/restore registers to transfer to C code. The following bit of code is what I'm having issues with: .globl transfer_to_handler_cont transfer_to_handler_cont: 3: mflrr9 lwz r11,0(r9) /* virtual address of handler */ lwz r9,4(r9)/* where to go when done */ mtspr SPRN_SRR0,r11 mtspr SPRN_SRR1,r10 mtlrr9 SYNC RFI /* jump to handler, enable MMU */ A few possibilities: * introduce an additional function pointer as part of EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit, dbg, mcheck) * use the traps field low order bits to determine normal, crit, dbg, mcheck at run time. * duplicate the code paths for each exception level suggestions? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] i2c: Add support for device alias names
Hi Jon,
On Mon, 28 Apr 2008 10:43:35 -0400, Jon Smirl wrote:
> On 4/28/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > One thing I am still not happy with is that the aliases created have a
> > trailing "*":
> >
> > $ /sbin/modinfo lm90
> > filename: /lib/modules/2.6.25-git11/kernel/drivers/hwmon/lm90.ko
> > author: Jean Delvare <[EMAIL PROTECTED]>
> > description:LM90/ADM1032 driver
> > license:GPL
> > vermagic: 2.6.25-git11 mod_unload
> > depends:hwmon
> > alias: i2c:lm90*
> > alias: i2c:adm1032*
> > alias: i2c:lm99*
> > alias: i2c:lm86*
> > alias: i2c:max6657*
> > alias: i2c:adt7461*
> > alias: i2c:max6680*
> > $
> >
> > This would cause trouble if one I2C chip name matches the beginning of
> > another I2C chip name and both chips are supported by different
> > drivers. This has yet to be seen, but still, I'd like to see this
> > problem fixed quickly.
>
>
> Trailing wildcard is always added by file2alias.c:
>
> if (do_entry(mod->name, symval+i, alias)) {
> /* Always end in a wildcard, for future extension */
> if (alias[strlen(alias)-1] != '*')
> strcat(alias, "*");
>
>
> Can't the match order be controlled in the makefile? For example if
> you had lm905* and lm90*, put lm905* into into the makefile first
> which will cause it to appear in the alias file first. But that would
> still cause problems if only lm90 was built and you had a lm905
> device.
That's too trickly and fragile - I'd rather make sure that wrong
matches just can't happen.
>
> Alternatively you could change the code to append something like a
> period to the name string.
>
> sprintf(alias, I2C_MODULE_PREFIX "%s.", id->name);
Similar to what Kay proposed. It works and we'll do that if we have to,
but if we can just get rid of the "*" I'd rather do that.
>
> I was using macros to alter the name strings to move the PowerPC names
> into their own namespace.
>
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/7] linkstation: implement standby
On Mon, Apr 28, 2008 at 05:40:19PM +0200, Guennadi Liakhovetski wrote:
> +static int ls_pm_enter(suspend_state_t state)
> +{
> + u64 tb;
> +
> + /* Get timebase */
> + tb = get_tb();
> +
> + /* put CPU to sleep, re-enabling interrupts */
> + mpc6xx_enter_standby();
> +
> + local_irq_disable();
Interrupts should not be enabled when you come out of
mpc6xx_enter_standby(); see the TLF_SLEEPING patch.
> +#define MPC10X_LP_REF_EN(1<<12)
> +#define MPC10X_PM (1<<7)
> +#define MPC10X_DOZE (1<<5)
> +#define MPC10X_NAP (1<<4)
> +#define MPC10X_SLEEP(1<<3)
Mismatched whitespace (MPC10X_DOZE has a space before it; the others have
tabs).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: suggestions on handling additional exception levels on ppc32
On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote: > A few possibilities: > * introduce an additional function pointer as part of > EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit, > dbg, mcheck) > * use the traps field low order bits to determine normal, crit, dbg, > mcheck at run time. > * duplicate the code paths for each exception level > > suggestions? You could temporarily disable all asynchronous exceptions, and use the registers of the highest-priority exception type. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add fast little-endian switch system call
On Mon, Apr 28, 2008 at 4:43 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > Please see Michael Kerrisk on userspace ABI updates. A nice little > manpage for this gimmick would be helpful, and maybe help other > platforms that want one aswell to implement the same API. Thanks Chrsitoph. I'm not on any of these lists at the moment. Paul -- is this syscall defintely going in? Could you write a short description for userland programmers? I'll do the grotty *roff stuff. > On Mon, Apr 28, 2008 at 01:52:31PM +1000, Paul Mackerras wrote: > > This adds a system call on 64-bit platforms for switching between > > little-endian and big-endian modes that is much faster than doing a > > prctl call. This system call is handled as a special case right at > > the start of the system call entry code, and because it is a special > > case, it uses a system call number which is out of the range of > > normal system calls, namely 0x1ebe. > > > > Measurements with lmbench on a 4.2GHz POWER6 showed no measurable > > change in the speed of normal system calls with this patch. > > > > Switching endianness with this new system call takes around 60ns on a > > 4.2GHz POWER6, compared with around 300ns to switch endian mode with a > > prctl. This can provide a significant performance advantage for > > emulators for little-endian architectures that want to switch between > > big-endian and little-endian mode frequently, e.g. because they are > > generating instructions sequences on the fly and they want to run > > those sequences in little-endian mode. > > > > Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> > > --- > > > > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S > > index 215973a..2eb49a7 100644 > > --- a/arch/powerpc/kernel/head_64.S > > +++ b/arch/powerpc/kernel/head_64.S > > @@ -239,6 +239,10 @@ instruction_access_slb_pSeries: > > .globl system_call_pSeries > > system_call_pSeries: > > HMT_MEDIUM > > +BEGIN_FTR_SECTION > > + cmpdi r0,0x1ebe > > + beq-1f > > +END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE) > > Am I missing something here or does this add a branch for every normal > syscall? > > > mr r9,r13 > > mfmsr r10 > > mfspr r13,SPRN_SPRG3 > > @@ -253,6 +257,13 @@ system_call_pSeries: > > rfid > > b . /* prevent speculative execution */ > > > > +/* Fast LE/BE switch system call */ > > +1: mfspr r12,SPRN_SRR1 > > + xorir12,r12,MSR_LE > > + mtspr SPRN_SRR1,r12 > > + rfid/* return to userspace */ > > + b . > > + > > STD_EXCEPTION_PSERIES(0xd00, single_step) > > STD_EXCEPTION_PSERIES(0xe00, trap_0e) > > > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-dev > ---end quoted text--- > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 0/2] i2c: Add support for device alias names
Hello Jean, I tested on this hardware MPC8260 (powerpc) + PCF8575 (io expander) + LM84 (sensor) + RS5C372 (rtc) + X24645 (eeprom) the following software 2.6.25-git11 + your 2 patches + Patches 5-7 from Jochen's series (for the CPM2-bus-driver) The rtc and the eeprom were assigend through of-tree. The expander and the sensor were assigned via the old-binding method using force-parameters. It builds fine, except for two warnings of redefinitions in Jochen's patches. (I think they need a few updates anyhow). The output in modules.alias and /sys make sense. I2C works flawlessly for all devices. Please let me know, if you need to more information. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] i2c: Add support for device alias names
On Mon, 2008-04-28 at 17:40 +0200, Jean Delvare wrote: > On Mon, 28 Apr 2008 17:07:25 +0200, Kay Sievers wrote: > > On Mon, 2008-04-28 at 11:39 +0200, Jean Delvare wrote: > > > One thing I am still not happy with is that the aliases created have a > > > trailing "*": > > > > > > $ /sbin/modinfo lm90 > > > filename: /lib/modules/2.6.25-git11/kernel/drivers/hwmon/lm90.ko > > > author: Jean Delvare <[EMAIL PROTECTED]> > > > description:LM90/ADM1032 driver > > > license:GPL > > > vermagic: 2.6.25-git11 mod_unload > > > depends:hwmon > > > alias: i2c:lm90* > > > alias: i2c:adm1032* > > > alias: i2c:lm99* > > > alias: i2c:lm86* > > > alias: i2c:max6657* > > > alias: i2c:adt7461* > > > alias: i2c:max6680* > > > $ > > > > > > This would cause trouble if one I2C chip name matches the beginning of > > > another I2C chip name and both chips are supported by different > > > drivers. This has yet to be seen, but still, I'd like to see this > > > problem fixed quickly. > > > > Right, the trailing "*" is not nice. > > > > We should terminate the string, so the trailing "*" will not match > > longer strings. The usual thing is to add a ":" to the end, which would > > then show up as > > alias: i2c:max6680:* > > > > See DMI and ACPI: > > alias dmi:*:svnFUJITSU:pnLifeBook*:pvr*:rvnFUJITSU:* apanel > > alias acpi*:ASIM:* atlas_btns > > I didn't know about these cases, thanks for the hint. > > > > > If i2c device modaliases could ever contain multiple strings, it should > > be: > > alias: i2c*:max6680:* > > to match the module, regardless of the order of the strings in the > > modalias: > > Why would i2c device modaliases ever contain multiple strings? A device > can't have multiple names, can it? Like ACPI/PNP devices, which can have several compat id's, which means that a single device can have "multiple names": $ cat /sys/bus/pnp/devices/00:09/id IBM0057 PNP0f13 > Adding a ":" at the end of the i2c device names solves the problem I > was mentioning, sure, but why don't we simply remove the trailing "*", > instead of trying to work around it? A trailing "*" simply makes no > sense for aliases which are simple device names. Sure, if there is only one single string, it's not useful. > This is not only i2c > devices, but also platform devices, acpi, dmi, pnp... ACPI, DMI, PNP (PNP does not do modalias) needs to be able to match only one string in a given list, so the trailing "*" is needed. > Looking at the > various device types handled by file2alias.c, it seems that most of > them don't need the trailing "*", and many of them have the problem I > was mentioning. > > Can't we just stop handle_moddevtable() from adding a tailing "*" > automatically, and just let the device types which need it, add it on > their own? For a lot subsystems it's fine to have it appended, as there is a defined list of identifiers, which must appear in the same order, and new identifiers are appended to the end. So the "*" still matches modules with possibly extended modalias strings. We would also need to review all buses which export modalias, if they need the "*" or not, and add them by hand, if needed. I guess, it's easier to introduce an additional parameter to file2alias::do_table() and suppress the trailing "*" for i2c? Thanks, Kay ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/2] [MTD] Add support for RAM & ROMmappings in the physmap_of MTD driver.
Laurent Pinchart wrote: > Last thing I heard was that the device tree should not encode > a device's > expected usage, so memory nodes should not have any > compatible property that > would automatically associated them to an MTD driver. I've > been adviced to > add platform-specific code to instantiate a platform device manually > (possibly checking if the required memory node is present in > the device > tree). This arguably makes sense, but adds more > platform-specific code. So... What good it the device tree at all then, if intended usage should not be encoded in there. Most other devices has an intended usage encoded. Examples would be the FCC's on a Freescale PQ2 chip, where they are encoded as ethernet controllers. (Thsy could be used as high-speed HDLC controllers, ATM controllers and other usages), the SCC ports (as serial, they can be used for syncronous serial and HDLC) That would also mean if usage would change, the kernel image (and possiby u-boot) whould have to change, instead of just fixing the device tree. Argh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
IB/ehca: handle negative return value from ibmebus_request_irq() properly in ehca_create_eq()
Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_eq.c | 35 -
1 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_eq.c
b/drivers/infiniband/hw/ehca/ehca_eq.c
index b4ac617..49660df 100644
--- a/drivers/infiniband/hw/ehca/ehca_eq.c
+++ b/drivers/infiniband/hw/ehca/ehca_eq.c
@@ -54,7 +54,8 @@ int ehca_create_eq(struct ehca_shca *shca,
struct ehca_eq *eq,
const enum ehca_eq_type type, const u32 length)
{
- u64 ret;
+ int ret;
+ u64 h_ret;
u32 nr_pages;
u32 i;
void *vpage;
@@ -73,15 +74,15 @@ int ehca_create_eq(struct ehca_shca *shca,
return -EINVAL;
}
- ret = hipz_h_alloc_resource_eq(shca->ipz_hca_handle,
- &eq->pf,
- type,
- length,
- &eq->ipz_eq_handle,
- &eq->length,
- &nr_pages, &eq->ist);
+ h_ret = hipz_h_alloc_resource_eq(shca->ipz_hca_handle,
+&eq->pf,
+type,
+length,
+&eq->ipz_eq_handle,
+&eq->length,
+&nr_pages, &eq->ist);
- if (ret != H_SUCCESS) {
+ if (h_ret != H_SUCCESS) {
ehca_err(ib_dev, "Can't allocate EQ/NEQ. eq=%p", eq);
return -EINVAL;
}
@@ -97,24 +98,22 @@ int ehca_create_eq(struct ehca_shca *shca,
u64 rpage;
vpage = ipz_qpageit_get_inc(&eq->ipz_queue);
- if (!vpage) {
- ret = H_RESOURCE;
+ if (!vpage)
goto create_eq_exit2;
- }
rpage = virt_to_abs(vpage);
- ret = hipz_h_register_rpage_eq(shca->ipz_hca_handle,
- eq->ipz_eq_handle,
- &eq->pf,
- 0, 0, rpage, 1);
+ h_ret = hipz_h_register_rpage_eq(shca->ipz_hca_handle,
+eq->ipz_eq_handle,
+&eq->pf,
+0, 0, rpage, 1);
if (i == (nr_pages - 1)) {
/* last page */
vpage = ipz_qpageit_get_inc(&eq->ipz_queue);
- if (ret != H_SUCCESS || vpage)
+ if (h_ret != H_SUCCESS || vpage)
goto create_eq_exit2;
} else {
- if (ret != H_PAGE_REGISTERED || !vpage)
+ if (h_ret != H_PAGE_REGISTERED || !vpage)
goto create_eq_exit2;
}
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: suggestions on handling additional exception levels on ppc32
On Apr 28, 2008, at 10:59 AM, Scott Wood wrote: On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote: A few possibilities: * introduce an additional function pointer as part of EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit, dbg, mcheck) * use the traps field low order bits to determine normal, crit, dbg, mcheck at run time. * duplicate the code paths for each exception level suggestions? You could temporarily disable all asynchronous exceptions, and use the registers of the highest-priority exception type. That doesn't work. We have NMIs or will have them in the future. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: suggestions on handling additional exception levels on ppc32
On Mon, Apr 28, 2008 at 11:58:58AM -0500, Kumar Gala wrote: > > On Apr 28, 2008, at 10:59 AM, Scott Wood wrote: > >On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote: > >>A few possibilities: > >>* introduce an additional function pointer as part of > >>EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit, > >>dbg, mcheck) > >>* use the traps field low order bits to determine normal, crit, dbg, > >>mcheck at run time. > >>* duplicate the code paths for each exception level > >> > >>suggestions? > > > >You could temporarily disable all asynchronous exceptions, and use the > >registers of the highest-priority exception type. > > That doesn't work. We have NMIs or will have them in the future. Truly non-maskable? Ick. You could have a separate code path just for the exception type that NMIs use, I guess, if there's a clear highest-priority among the remaining interrupt types. What sort of exceptions are they? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Sun, 27 Apr 2008 22:47:43 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> If your LEDs are attached to gpio pins, then you should use the
> current draft led->gpio bindings as shown in the above patch. Then,
> let your platform code extract whatever data it needs from the device
> tree to set up the LEDs.
I added the following to the dts:
[EMAIL PROTECTED] {
compatible = "linux,gpio-led";
linux,name = "green";
gpios = <&GPIO1 31>;
};
[EMAIL PROTECTED] {
compatible = "linux,gpio-led";
linux,name = "red";
gpios = <&GPIO1 30>;
};
I then map the gpio base as follows (I removed the if checks just to
make things short and sweet):
np = of_find_compatible_node(NULL, NULL, "linux,gpio-led");
gpios = of_get_property(np, "gpios", &lenp);
of_node_put(np);
np = of_find_node_by_phandle(gpios[0]);
gpio_base = of_iomap(np, 0);
of_node_put(np);
Comments?
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] sysdev,mv64x60: MV64x60 device bus
Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
For each mv64360 entry in the OpenFirmware database, add the
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
I did not modify the PRPMC2800 dts file to use that feature because
I cannot test it on that board. I will soon submit a patch to add
support for a board that makes use of this feature. If someone want
to use that feature to register the PRPMC2800 flash you just need
to move the NOR flash declaration in a subcategory whose device_type
field is set to "devicectrl".
arch/powerpc/sysdev/mv64x60_dev.c | 10 ++
1 files changed, 10 insertions(+)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index 41af122..f335fd5 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -25,6 +26,11 @@
* PowerPC of_platform_bus_type. They support platform_bus_type instead.
*/
+static struct of_device_id of_mv64x60_devices[] = {
+ { .type = "devicectrl", },
+ {}
+};
+
/*
* Create MPSC platform devices
*/
@@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void)
of_node_put(np);
}
+ /* Now add every node that is on the device bus (type is devicectrl */
+ for_each_compatible_node(np, NULL, "marvell,mv64360")
+ of_platform_bus_probe(np, of_mv64x60_devices, NULL);
+
return 0;
}
arch_initcall(mv64x60_device_setup);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, Apr 28, 2008 at 11:10 AM, Sean MacLennan
<[EMAIL PROTECTED]> wrote:
> On Sun, 27 Apr 2008 22:47:43 -0600
>
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
>
> > If your LEDs are attached to gpio pins, then you should use the
> > current draft led->gpio bindings as shown in the above patch. Then,
> > let your platform code extract whatever data it needs from the device
> > tree to set up the LEDs.
>
> I added the following to the dts:
>
> [EMAIL PROTECTED] {
> compatible = "linux,gpio-led";
> linux,name = "green";
> gpios = <&GPIO1 31>;
> };
>
> [EMAIL PROTECTED] {
> compatible = "linux,gpio-led";
> linux,name = "red";
> gpios = <&GPIO1 30>;
> };
This looks appropriate. You'll need to make sure that the values in
the linux,name property meet the Linux LED naming guidelines. I think
this is covered in Documentation/leds-class.c. You can also as
Richard Purdie; the LED subsystem maintainer.
> I then map the gpio base as follows (I removed the if checks just to
> make things short and sweet):
>
> np = of_find_compatible_node(NULL, NULL, "linux,gpio-led");
>
> gpios = of_get_property(np, "gpios", &lenp);
> of_node_put(np);
>
> np = of_find_node_by_phandle(gpios[0]);
>
>
> gpio_base = of_iomap(np, 0);
> of_node_put(np);
This isn't ideal, but it will do to start. However, if other devices
want to use the same GPIO block, then you'll probably have problems
with race conditions. Eventually, you'll want to use the common GPIO
infrastructure and remove the custom code.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, 28 Apr 2008 11:44:19 -0600 "Grant Likely" <[EMAIL PROTECTED]> wrote: > This looks appropriate. You'll need to make sure that the values in > the linux,name property meet the Linux LED naming guidelines. I think > this is covered in Documentation/leds-class.c. You can also as > Richard Purdie; the LED subsystem maintainer. The leds name is "devicename:colour:function" where you are allowed to leave sections blank. So I only filled in the colour ;) I also notice that it is colour, not color. I am hoping that this code is only for 2.6.26 and that we will switch to the gpio-leds driver for 2.6.27. I don't want to keep supporting yet another driver outside of the mainline kernel. Let's face it, I'm lazy :D Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: suggestions on handling additional exception levels on ppc32
On Apr 28, 2008, at 12:04 PM, Scott Wood wrote: On Mon, Apr 28, 2008 at 11:58:58AM -0500, Kumar Gala wrote: On Apr 28, 2008, at 10:59 AM, Scott Wood wrote: On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote: A few possibilities: * introduce an additional function pointer as part of EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit, dbg, mcheck) * use the traps field low order bits to determine normal, crit, dbg, mcheck at run time. * duplicate the code paths for each exception level suggestions? You could temporarily disable all asynchronous exceptions, and use the registers of the highest-priority exception type. That doesn't work. We have NMIs or will have them in the future. Truly non-maskable? Ick. You could have a separate code path just for the exception type that NMIs use, I guess, if there's a clear highest-priority among the remaining interrupt types. What sort of exceptions are they? The NMIs are machine check only so a separate path for them isn't a terrible idea. However, disabling all other interrupts seems worse than adding a function pointer. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sysdev,mv64x60: MV64x60 device bus
On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote: > Follow up of my email of 4/16/2008 titled "MV64x60 device bus". > For each mv64360 entry in the OpenFirmware database, add the > registration of an of_bus to take care of devices connected to > the MV64x60 asynchronous devices controller. I'd like to see your dts file to see exactly how you're using it. The only problem I see now is that you have introduced a new device type, "devicectrl". New device types are frowned upon. It's better to match based on the compatible field. Maybe use "marvell,mv64306-devctrl" or similar. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD: fix partition scan control logic in physmap_ofand fsl_elbc_nand
On Fri, Apr 25, 2008 at 07:09:59PM +0800, Li Yang wrote: > The error can also be soft error like a typo in the cmdline or device > tree. I could be better to try other ways to see if we can find a sane > partition table than just to fail. If cmdline partition information exists, typo or not, then obviously there was intent for the cmdline to be used. It's better to let the user know there's a problem than silently fall back to some other, likely wrong partition information. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] mpc83xx: timer driver for PM wakeup
On Mon, Apr 28, 2008 at 05:39:32PM +0200, Guennadi Liakhovetski wrote: > This is a driver for the mpc83xx's GTM4 timer. It's functionality > is limited to providing a wakeup source for suspend-to-RAM. This driver should be redone as a client of Anton's more general GTM driver. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
Ok, here is another version of the patch with Stephen Rothwell's and
Grant Likely's suggestions.
Cheers,
Sean
PIKA Warp: Update platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Full DTM support including critical temperature.
* Added POST information.
* Removed LED function, moved to new LED driver.
* Moved ad7414 to new style I2C initialization.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/boot/cuboot-warp.c b/arch/powerpc/boot/cuboot-warp.c
index eb108a8..2178021 100644
--- a/arch/powerpc/boot/cuboot-warp.c
+++ b/arch/powerpc/boot/cuboot-warp.c
@@ -10,6 +10,7 @@
#include "ops.h"
#include "4xx.h"
#include "cuboot.h"
+#include "stdio.h"
#define TARGET_4xx
#define TARGET_44x
@@ -17,14 +18,54 @@
static bd_t bd;
-static void warp_fixups(void)
+static void warp_fixup_one_nor(u32 from, u32 to)
{
- unsigned long sysclk = 6600;
+ void *devp;
+ char name[50];
+ u32 v[2];
+
+ sprintf(name, "/plb/opb/ebc/[EMAIL PROTECTED],0/[EMAIL PROTECTED]",
from);
+
+ devp = finddevice(name);
+ if (!devp)
+ return;
+
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[0] = to;
+ setprop(devp, "reg", v, sizeof(v));
+
+ printf("NOR 64M fixup %x -> %x\r\n", from, to);
+ }
+}
+
- ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
+static void warp_fixups(void)
+{
+ ibm440ep_fixup_clocks(6600, 11059200, 5000);
ibm4xx_sdram_fixup_memsize();
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+
+ /* Fixup for 64M flash on Rev A boards. */
+ if (bd.bi_flashsize == 0x400) {
+ void *devp;
+ u32 v[3];
+
+ devp = finddevice("/plb/opb/ebc/[EMAIL PROTECTED],0");
+ if (!devp)
+ return;
+
+ /* Fixup the size */
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[2] = bd.bi_flashsize;
+ setprop(devp, "reg", v, sizeof(v));
+ }
+
+ /* Fixup parition offsets */
+ warp_fixup_one_nor(0x30, 0x3f0);
+ warp_fixup_one_nor(0x34, 0x3f4);
+ warp_fixup_one_nor(0x38, 0x3f8);
+ }
}
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index b04a52e..d124497 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -132,40 +132,33 @@
[EMAIL PROTECTED],0 {
compatible = "pika,fpga";
- reg = <2 0 2200>;
+ reg = <2 0 1000>;
interrupts = <18 8>;
interrupt-parent = <&UIC0>;
};
+ [EMAIL PROTECTED],4000 {
+ compatible = "pika,fpga-sd";
+ reg = <2 4000 A00>;
+ };
+
[EMAIL PROTECTED],0 {
- compatible = "amd,s29gl512n",
"cfi-flash";
+ compatible = "amd,s29gl032a",
"cfi-flash";
bank-width = <2>;
- reg = <0 0 400>;
+ reg = <0 0 40>;
#address-cells = <1>;
#size-cells = <1>;
- [EMAIL PROTECTED] {
- label = "kernel";
- reg = <0 18>;
- };
- [EMAIL PROTECTED] {
- label = "root";
- reg = <18 348>;
- };
- [EMAIL PROTECTED] {
- label = "user";
- reg = <360 90>;
- };
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
label = "fpga";
- reg = <3f0 4>;
+ reg = <30 4>;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTE
Re: [PATCH] sysdev,mv64x60: MV64x60 device bus
On Mon, 2008-04-28 at 11:09 -0700, Dale Farnsworth wrote:
> On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote:
> > Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
> > For each mv64360 entry in the OpenFirmware database, add the
> > registration of an of_bus to take care of devices connected to
> > the MV64x60 asynchronous devices controller.
>
> I'd like to see your dts file to see exactly how you're using it.
Here it is, I removed everything that is not related to the subject:
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <1>;
model = "C2K";
compatible = "GEFanuc,C2K";
coherency-off;
<...>
[EMAIL PROTECTED] { /* Marvell Discovery */
#address-cells = <1>;
#size-cells = <1>;
model = "mv64460";
compatible = "marvell,mv64360";
<...>
/* Devices attached to the device controller */
devicebus {
device_type = "devicectrl";
#address-cells = <1>;
#size-cells = <1>;
nor_flash {
compatible = "cfi-flash";
reg = <0xf800 0x800>; /* 128MB */
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
[EMAIL PROTECTED] {
label = "boot";
reg = <0x 0x0008>;
};
[EMAIL PROTECTED] {
label = "kernel";
reg = <0x0008 0x0040>;
};
[EMAIL PROTECTED] {
label = "initrd";
reg = <0x0048 0x00B8>;
};
[EMAIL PROTECTED] {
label = "rootfs";
reg = <0x0100 0x0680>;
};
[EMAIL PROTECTED] {
label = "recovery";
reg = <0x0780 0x0080>;
read-only;
};
};
};
};
<...>
};
>
> The only problem I see now is that you have introduced a new device
> type, "devicectrl". New device types are frowned upon. It's better
> to match based on the compatible field. Maybe use
> "marvell,mv64306-devctrl" or similar.
>
Do you mean having the DTS file look like this:
<...>
devicebus {
compatible = "marvell,mv64306-devctrl";
#address-cells = <1>;
#size-cells = <1>;
nor_flash {
compatible = "cfi-flash";
reg = <0xf800 0x800>;
<...>
};
};
Remi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sysdev,mv64x60: MV64x60 device bus
On Mon, Apr 28, 2008 at 12:22:36PM -0700, Remi Machet wrote:
> On Mon, 2008-04-28 at 11:09 -0700, Dale Farnsworth wrote:
> > On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote:
> > > Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
> > > For each mv64360 entry in the OpenFirmware database, add the
> > > registration of an of_bus to take care of devices connected to
> > > the MV64x60 asynchronous devices controller.
> >
> > I'd like to see your dts file to see exactly how you're using it.
> Here it is, I removed everything that is not related to the subject:
>
> /dts-v1/;
>
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> model = "C2K";
> compatible = "GEFanuc,C2K";
> coherency-off;
>
> <...>
>
> [EMAIL PROTECTED] { /* Marvell Discovery */
> #address-cells = <1>;
> #size-cells = <1>;
> model = "mv64460";
> compatible = "marvell,mv64360";
>
> <...>
>
> /* Devices attached to the device controller */
> devicebus {
> device_type = "devicectrl";
> #address-cells = <1>;
> #size-cells = <1>;
> nor_flash {
> compatible = "cfi-flash";
> reg = <0xf800 0x800>; /* 128MB */
> bank-width = <4>;
> device-width = <1>;
> #address-cells = <1>;
> #size-cells = <1>;
> [EMAIL PROTECTED] {
> label = "boot";
> reg = <0x 0x0008>;
> };
> [EMAIL PROTECTED] {
> label = "kernel";
> reg = <0x0008 0x0040>;
> };
> [EMAIL PROTECTED] {
> label = "initrd";
> reg = <0x0048 0x00B8>;
> };
> [EMAIL PROTECTED] {
> label = "rootfs";
> reg = <0x0100 0x0680>;
> };
> [EMAIL PROTECTED] {
> label = "recovery";
> reg = <0x0780 0x0080>;
> read-only;
> };
> };
> };
> };
> <...>
> };
Thanks.
> > The only problem I see now is that you have introduced a new device
> > type, "devicectrl". New device types are frowned upon. It's better
> > to match based on the compatible field. Maybe use
> > "marvell,mv64306-devctrl" or similar.
> >
> Do you mean having the DTS file look like this:
Yes, exactly.
-Dale
> <...>
> devicebus {
> compatible = "marvell,mv64306-devctrl";
> #address-cells = <1>;
> #size-cells = <1>;
> nor_flash {
> compatible = "cfi-flash";
> reg = <0xf800 0x800>;
> <...>
> };
> };
>
> Remi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.25: pmac_newworld undefined
On Mon, Apr 28, 2008 at 02:20:44PM +1000, Tony Breeds wrote: > On Sun, Apr 27, 2008 at 08:03:46PM +0200, Christian Kujau wrote: > > Hi, > > > > the build failure reported[0] by Kamalesh back in 01/2008 is still > > present in today's 2.6.25-git with CONFIG_NVRAM=m (instead of =y): > > > > Building modules, stage 2. > > MODPOST 72 modules > > ERROR: "pmac_newworld" [arch/powerpc/platforms/powermac/nvram.ko] undefined! > > ERROR: "__alloc_bootmem" [arch/powerpc/platforms/powermac/nvram.ko] > > undefined! > > make[1]: *** [__modpost] Error 1 > > Yeah that isn't really surprising. Essentially > arch/powerpc/platforms/powermac/nvram.c must be builtin (not modular) > but CONFIG_NVRAM is tristate, and your .config has CONFIG_NVRAM=m. > > We can probably "fix" this by adding another config config symbol and > "selecting" that from CONFIG_NVRAM. Then using this new symbol in > arch/powerpc/platforms/powermac/* > > so I think with we need is: > config NVRAM > bool "..." if PPC32 > tristate "..." if !PPC32 > ... > ... > > Sam is there some way to achieve that or should we just create an > secondary symbol? In the Makefile you could just do a: obj-$(CONFIG_NVRAM:m=y) += nvram.o Then you would force nvram to be build-in. That looks simpler than messing with Kconfig in this case. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, Apr 28, 2008 at 12:53 PM, Sean MacLennan
<[EMAIL PROTECTED]> wrote:
> Ok, here is another version of the patch with Stephen Rothwell's and
> Grant Likely's suggestions.
>
> Cheers,
> Sean
A few more comments below.
Also, it might help to split up the .dts and code changes into 2
separate patches. That way the .dts can be picked up even if the
actual platform code still needs some revisions.
Finally, since this is a 4xx board port, you need to cc: Josh Boyer on
these patches.
> diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
> index b04a52e..d124497 100644
> --- a/arch/powerpc/boot/dts/warp.dts
> +++ b/arch/powerpc/boot/dts/warp.dts
> @@ -186,6 +179,16 @@
> reg = ;
> interrupt-parent = <&UIC0>;
> interrupts = <2 4>;
> + index = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + [EMAIL PROTECTED] {
> + compatible = "adi,ad7414";
> + reg = <4a>;
> + interrupts = <19 8>;
> + interrupt-parent = <&UIC0>;
> + };
> };
>
> GPIO0: [EMAIL PROTECTED] {
> @@ -196,8 +199,22 @@
> GPIO1: [EMAIL PROTECTED] {
> compatible = "ibm,gpio-440ep";
> reg = ;
> +
> + };
You need to add the gpio-controller and #gpio-cells properties to the
GPIO nodes for the LED's gpios property to work correctly. Search for
"2) gpio-controller nodes" in
Documentation/powerpc/booting-without-of.txt for details. #gpio-cells
should probably be '2' for this gpio controller; 1 cell for the gpio
pin and 1 cell for flags.
> +
> + [EMAIL PROTECTED] {
>
> + compatible = "linux,gpio-led";
> + linux,name = "green";
> + gpios = <&GPIO1 31>;
> + };
> +
> + [EMAIL PROTECTED] {
> + compatible = "linux,gpio-led";
> + linux,name = "red";
> + gpios = <&GPIO1 30>;
> };
These should not be children of the soc node (they are not part of the
SoC internal bus). However, I think it would be perfectly valid to
make them children of the gpio node since they don't have any
connections to other device on the platform.
>
> +
> ZMII0: [EMAIL PROTECTED] {
> compatible = "ibm,zmii-440ep",
> "ibm,zmii-440gp", "ibm,zmii";
> reg = ;
>
> diff --git a/arch/powerpc/platforms/44x/warp-nand.c
> b/arch/powerpc/platforms/44x/warp-nand.c
> index 9150318..d293c70 100644
>
> --- a/arch/powerpc/platforms/44x/warp-nand.c
> +++ b/arch/powerpc/platforms/44x/warp-nand.c
> @@ -11,8 +11,10 @@
> #include
> #include
> #include
> +#include
>
>
> #include
>
> +
> #ifdef CONFIG_MTD_NAND_NDFC
>
> #define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
> @@ -35,13 +37,23 @@ static struct mtd_partition nand_parts[] = {
> {
> .name = "root",
> .offset = 0x020,
> - .size = 0x340
> + .size = 0x3E0
> + },
> + {
> + .name = "persistent",
> + .offset = 0x400,
> + .size = 0x400
> },
> {
> - .name = "user",
> - .offset = 0x360,
> - .size = 0x0A0
> + .name = "persistent1",
> + .offset = 0x800,
> + .size = 0x400
> },
> + {
> + .name = "persistent2",
> + .offset = 0xC00,
> + .size = 0x400
> + }
> };
Why is this information in the dts *and* the platform file? I haven't
been following the flash partition map binding conventions, but having
it in both places looks wrong
oh, wait... the one in the dts is for NOR and this one is for NAND,
right? And we don't have a binding yet for NAND partitions yet,
correct?
>
> struct ndfc_controller_settings warp_ndfc_settings = {
> @@ -67,19 +79,15 @@ static struct platform_device warp_ndfc_device = {
> .resource = &warp_ndfc,
> };
>
> -static struct nand_ecclayout nand_oob_16 = {
> - .eccbytes = 3,
> - .eccpos = { 0, 1, 2, 3, 6, 7 },
> - .oobfree = { {.offset = 8, .length = 16} }
> -};
> -
> +/* Do NOT set the ecclayout: let it default so it is cor
Re: pci_proc_init: proc_dir_entry '00' already registered
Olaf Hering wrote: > On Sun, Feb 10, Alexey Dobriyan wrote: > > > On Sun, Feb 10, 2008 at 11:07:57AM +0100, Olaf Hering wrote: > > > Current Linus tree gives this new warning during bootup: > > > > > > +proc_dir_entry '00' already registered > > > +Call Trace: > > > +[c0007b0dfba0] [c000e4b0] .show_stack+0x70/0x1bc > > > (unreliable) > > > +[c0007b0dfc50] [c00f2714] .proc_register+0x130/0x210 > > > +[c0007b0dfd00] [c00f299c] .proc_mkdir_mode+0x40/0x70 > > > +[c0007b0dfd80] [c0276ed8] > > > .pci_proc_attach_device+0xac/0x144 > > > +[c0007b0dfe20] [c05bdb3c] .pci_proc_init+0x74/0xac > > > +[c0007b0dfea0] [c05a27ac] .kernel_init+0x1d0/0x394 > > > +[c0007b0dff90] [c001e258] .kernel_thread+0x4c/0x68 > > > > Can you insert dump_stack() when '00' is registered, not just second > > time? > > Its pci_bus_add_device(). Full dmesg attached: It can't be. "proc_initialized" is 0 at that point, so no new files in /proc . Must be something PCI domains related: if pci_proc_domain() returns 0 for some reason, busses will be different, but name the same -- '00'. The reason there is no second warning is that you don't have anything on 0001:0a . > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b113800 - > :00:0b.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b113000 - > :0a:00.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b149800 - > 0001:00:00.0 > proc_dir_entry '00' already registered > Call Trace: > [c0007b0dfb60] [c000f4ec] .show_stack+0x5c/0x1f0 (unreliable) > [c0007b0dfc10] [c0112e40] .proc_register+0x190/0x250 > [c0007b0dfcd0] [c0113130] .proc_mkdir_mode+0x40/0x80 > [c0007b0dfd50] [c02c7548] .pci_proc_attach_device+0x158/0x190 > [c0007b0dfe00] [c065c3f8] .pci_proc_init+0xb8/0x100 > [c0007b0dfe90] [c063c8a8] .kernel_init+0x1d8/0x420 > [c0007b0dff90] [c0021dac] .kernel_thread+0x4c/0x68 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b149000 - > 0001:00:01.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a4800 - > 0001:00:02.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a4000 - > 0001:00:03.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a5800 - > 0001:00:04.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a5000 - > 0001:00:05.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a6800 - > 0001:00:06.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a6000 - > 0001:00:07.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a7800 - > 0001:00:08.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a7000 - > 0001:00:09.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a9800 - > 0001:05:04.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1a9000 - > 0001:05:04.1 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1ab800 - > 0001:01:07.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1ab000 - > 0001:01:0b.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1ac800 - > 0001:01:0b.1 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1ac000 - > 0001:01:0b.2 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1ae800 - > 0001:03:0c.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1ae000 - > 0001:03:0d.0 > pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c0007b1af800 - > 0001:03:0e.0 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 0/2] i2c: Add support for device alias names
Hi Wolfram, > I tested on this hardware > > MPC8260 (powerpc) + PCF8575 (io expander) + LM84 (sensor) > + RS5C372 (rtc) + X24645 (eeprom) It's also OK on dbox2 hardware: MPC823 (powerpc) + saa7127 (patch needed to add id_table) + dbox frontprocessor (8051 controller with i2c interface). Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
On Fri, Apr 25, 2008 at 02:57:24PM +0200, Guennadi Liakhovetski wrote: > is there any specific reason, why out of these 7 patches only the first > one made it into the mainline? AFAICS, there has been only one comment, > suggesting to replace printk with dev_err on two occasions in one of > the patches... A while ago Paul said on IRC he'd prefer to do the TLF_SLEEPING hack more like the soft IRQ disabling that 64-bit uses. I haven't yet had a chance to look into it, so the patch collects dust, despite the current implementation of TLF_SLEEPING working just fine. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [MTD] Add support for RAM & ROMmappings in the physmap_of MTD driver.
On Mon, Apr 28, 2008 at 11:26:15AM -0500, Rune Torgersen wrote: > Examples would be the FCC's on a Freescale PQ2 chip, where they are > encoded as ethernet controllers. (Thsy could be used as high-speed HDLC > controllers, ATM controllers and other usages), the SCC ports (as > serial, they can be used for syncronous serial and HDLC) But that choice is made by board-level hardware, not purely by software. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.25-git12 sysfs panic
Hi Greg, Ran into this sysfs oops while booting 2.6.25-git12. ipr issue ? Thanks, Badari ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007) ipr :d0:01.0: Found IOA with IRQ: 119 ipr :d0:01.0: Starting IOA initialization sequence. ipr :d0:01.0: Adapter firmware version: 020A005E ipr :d0:01.0: IOA initialized. scsi0 : IBM 570B Storage Adapter sysfs: duplicate filename 'state' can not be created [ cut here ] Badness at fs/sysfs/dir.c:425 NIP: c013b668 LR: c013b664 CTR: 8013f270 REGS: c000700db240 TRAP: 0700 Not tainted (2.6.25-git12) MSR: 80029032 CR: 22002024 XER: 0006 TASK = c000700d7980[1] 'swapper' THREAD: c000700d8000 CPU: 0 GPR00: c013b664 c000700db4c0 c0792970 0038 GPR04: 0001 0001 0001 GPR08: c07bd60c c06c2c58 3ac3 c07bd608 GPR12: 4000 c07b3300 GPR16: d8008008 c06b40d0 c0006e07a708 GPR20: c0006e07a650 c0006e07a000 c000703241a8 c00070324000 GPR24: c00070324070 c00070324000 c0006e07a3b0 c0006e07a170 GPR28: c000700db5c0 c07115c0 c0006e07e370 NIP [c013b668] .sysfs_add_one+0x50/0xec LR [c013b664] .sysfs_add_one+0x4c/0xec Call Trace: [c000700db4c0] [c013b664] .sysfs_add_one+0x4c/0xec (unreliable) [c000700db550] [c013ade4] .sysfs_add_file_mode+0x70/0xe0 [c000700db600] [c038b408] .device_create_file+0x20/0x3c [c000700db680] [c03e2a50] .scsi_sysfs_add_host+0x54/0xc4 [c000700db710] [c03d72b0] .scsi_add_host+0x1d4/0x264 [c000700db7b0] [c0537ef8] 0xc0537ef8 [c000700db920] [c033b9a4] .pci_device_probe+0x100/0x170 [c000700db9e0] [c038e67c] .driver_probe_device+0x118/0x1f8 [c000700dba70] [c038e7c4] .__driver_attach+0x68/0xac [c000700dbb00] [c038db3c] .bus_for_each_dev+0x80/0xd0 [c000700dbbb0] [c038e3c8] .driver_attach+0x28/0x40 [c000700dbc30] [c038d058] .bus_add_driver+0xf4/0x2dc [c000700dbce0] [c038ea54] .driver_register+0x90/0x170 [c000700dbd80] [c033bd4c] .__pci_register_driver+0x5c/0xcc [c000700dbe10] [c06675cc] .ipr_init+0x38/0x50 [c000700dbe90] [c0639414] .kernel_init+0x21c/0x3f8 [c000700dbf90] [c0023f84] .kernel_thread+0x4c/0x68 Instruction dump: f821ff71 6000 6000 e863 e8840018 4bfffdc1 2fa3 41be0020 e89f0018 e87e8020 4bf1d2f5 6000 <0fe0> 3860ffef 4878 e93d ipr: probe of :d0:01.0 failed with error -17 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] make help: Show defconfig subdirs
On Sun, Apr 06, 2008 at 10:16:07PM +0200, Segher Boessenkool wrote: > PowerPC will start moving board defconfigs into subarch-specific > subdirs soon. "make help" currently does not look in subdirs to > find the defconfigs to show. This is partially a good thing, > since there are way too many defconfigs for one list. > > This patch makes the main "make help" display something like > > help-40x - Show 40x-specific targets > help-44x - Show 44x-specific targets > help-boards - Show all of the above > > and wires up stuff so those new help-* commands actually work. > > Cc: Josh Boyer <[EMAIL PROTECTED]> > Cc: Sam Ravnborg <[EMAIL PROTECTED]> > Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]> Thanks, applied. Fixed it up to show x86 defconfig files too. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.25-git12 sysfs panic
On Mon, Apr 28, 2008 at 01:36:10PM -0700, Badari Pulavarty wrote: > Hi Greg, > > Ran into this sysfs oops while booting 2.6.25-git12. It's not an "oops" but a WARN_ON(1); > ipr issue ? Stupid driver issue, yes: > ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007) > ipr :d0:01.0: Found IOA with IRQ: 119 > ipr :d0:01.0: Starting IOA initialization sequence. > ipr :d0:01.0: Adapter firmware version: 020A005E > ipr :d0:01.0: IOA initialized. > scsi0 : IBM 570B Storage Adapter > sysfs: duplicate filename 'state' can not be created Looks like someone messed up, not the sysfs core's fault here :) thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, 2008-04-28 at 13:59 -0400, Sean MacLennan wrote: > On Mon, 28 Apr 2008 11:44:19 -0600 > "Grant Likely" <[EMAIL PROTECTED]> wrote: > > > This looks appropriate. You'll need to make sure that the values in > > the linux,name property meet the Linux LED naming guidelines. I think > > this is covered in Documentation/leds-class.c. You can also as > > Richard Purdie; the LED subsystem maintainer. > > The leds name is "devicename:colour:function" where you are allowed to > leave sections blank. So I only filled in the colour ;) You can leave sections blank but it pays to leave the separator in so use ":red:" or ":red", not "red". > I also notice that it is colour, not color. ;-) Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code tosupportRev B boards
On Mon, 28 Apr 2008 21:44:05 +0100 "Richard Purdie" <[EMAIL PROTECTED]> wrote: > You can leave sections blank but it pays to leave the separator in so > use ":red:" or ":red", not "red". Ok, :red: and :green: it is. What would be the advantage of pika:red: or warp:red:? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, 28 Apr 2008 13:56:11 -0600 "Grant Likely" <[EMAIL PROTECTED]> wrote: > > You need to add the gpio-controller and #gpio-cells properties to the > GPIO nodes for the LED's gpios property to work correctly. Search for > "2) gpio-controller nodes" in > Documentation/powerpc/booting-without-of.txt for details. #gpio-cells > should probably be '2' for this gpio controller; 1 cell for the gpio > pin and 1 cell for flags. I believe these gpio nodes predate that text, but I added the fields anyway. > > These should not be children of the soc node (they are not part of the > SoC internal bus). However, I think it would be perfectly valid to > make them children of the gpio node since they don't have any > connections to other device on the platform. I put them in gpio. That was where I put them initialy. > Why is this information in the dts *and* the platform file? I haven't > been following the flash partition map binding conventions, but having > it in both places looks wrong > > oh, wait... the one in the dts is for NOR and this one is for NAND, > right? And we don't have a binding yet for NAND partitions yet, > correct? Correct. Josh originally asked me to split out the warp-nand.c file so that once the NAND is in the dts, we can just delete the file. NAND is much more complicated that NOR to configure. > When exporting symbols for platform code you should avoid polluting > the global Linux namespace and prefix the functions with your platform > name. I was hoping dtm was good enough. I prefixed them with the company name. We are expecting to have a "family" of Asterisk appliances and I am trying to make educated guesses as to what will be family wide (prefixed with pika) and what will be warp specific. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code tosupportRev B boards
On Mon, 2008-04-28 at 17:24 -0400, Sean MacLennan wrote: > On Mon, 28 Apr 2008 21:44:05 +0100 > "Richard Purdie" <[EMAIL PROTECTED]> wrote: > > > You can leave sections blank but it pays to leave the separator in so > > use ":red:" or ":red", not "red". > > Ok, :red: and :green: it is. > > What would be the advantage of pika:red: or warp:red:? It makes it more obvious which driver is involved which can be useful when reading bug reports and helps identify things in cases where LEDs may be plugged in, e.g. USB. Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, Apr 28, 2008 at 05:37:38PM -0400, Sean MacLennan wrote: > > Why is this information in the dts *and* the platform file? I haven't > > been following the flash partition map binding conventions, but having > > it in both places looks wrong > > > > oh, wait... the one in the dts is for NOR and this one is for NAND, > > right? And we don't have a binding yet for NAND partitions yet, > > correct? > > Correct. Why can't the existing partition binding be used with NAND? It's what we do with Freescale FCM NAND. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, 28 Apr 2008 16:54:24 -0500 Scott Wood <[EMAIL PROTECTED]> wrote: > Why can't the existing partition binding be used with NAND? It's > what we do with Freescale FCM NAND. I guess I could put the partitions in the dts. But I would have to read them and dynamically create an array to pass to the ndfc driver. It seems simpler to just statically initialize the array. Once the ndfc is modified to use the dts, I will switch to that method. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, Apr 28, 2008 at 3:37 PM, Sean MacLennan <[EMAIL PROTECTED]> wrote: > On Mon, 28 Apr 2008 13:56:11 -0600 > > "Grant Likely" <[EMAIL PROTECTED]> wrote: > > > > > > You need to add the gpio-controller and #gpio-cells properties to the > > GPIO nodes for the LED's gpios property to work correctly. Search for > > "2) gpio-controller nodes" in > > Documentation/powerpc/booting-without-of.txt for details. #gpio-cells > > should probably be '2' for this gpio controller; 1 cell for the gpio > > pin and 1 cell for flags. > > I believe these gpio nodes predate that text, but I added the fields > anyway. > > > > > > These should not be children of the soc node (they are not part of the > > SoC internal bus). However, I think it would be perfectly valid to > > make them children of the gpio node since they don't have any > > connections to other device on the platform. > > I put them in gpio. That was where I put them initialy. > > > > Why is this information in the dts *and* the platform file? I haven't > > been following the flash partition map binding conventions, but having > > it in both places looks wrong > > > > oh, wait... the one in the dts is for NOR and this one is for NAND, > > right? And we don't have a binding yet for NAND partitions yet, > > correct? > > Correct. Josh originally asked me to split out the warp-nand.c file so > that once the NAND is in the dts, we can just delete the file. NAND is > much more complicated that NOR to configure. > > > > When exporting symbols for platform code you should avoid polluting > > the global Linux namespace and prefix the functions with your platform > > name. > > I was hoping dtm was good enough. I prefixed them with the company name. > We are expecting to have a "family" of Asterisk appliances and I am > trying to make educated guesses as to what will be family wide > (prefixed with pika) and what will be warp specific. Its just kernel code; it can be changed easily at later date. When the company has *2* boards supported mainline in the kernel, then make it generic. :-P My experience is that educated guesses in this context are almost always wrong (ie. the API won't be what you think it should be now). Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IB/ehca: handle negative return value from ibmebus_request_irq() properly in ehca_create_eq()
thanks, applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Change the default link address for pSeries zImage kernels.
On Fri, Apr 25, 2008 at 04:12:50PM +1000, Benjamin Herrenschmidt wrote: > Considering how bad OF can be on some machines, I'd like this to be > boot-tested on a wider range of machines. Also, it might depend on the > OF real-base setting as well... > > At least, we should be able to test at ozlabs on cell blades, POWER4 > bare metal (ie "SMP mode"), POWER5 and POWER5+. Hmm okay it fails on POWER4, I'll see what can be done there. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] sysdev,mv64x60: MV64x60 device bus
Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
For each mv64360 entry in the OpenFirmware database, add the
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
arch/powerpc/sysdev/mv64x60_dev.c | 10 ++
1 files changed, 10 insertions(+)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index 41af122..c3e28c4 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -25,6 +26,11 @@
* PowerPC of_platform_bus_type. They support platform_bus_type instead.
*/
+static struct of_device_id of_mv64x60_devices[] = {
+ { .compatible = "marvell,mv64306-devctrl", },
+ {}
+};
+
/*
* Create MPSC platform devices
*/
@@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void)
of_node_put(np);
}
+ /* Now add every node that is on the device bus (type is devicectrl */
+ for_each_compatible_node(np, NULL, "marvell,mv64360")
+ of_platform_bus_probe(np, of_mv64x60_devices, NULL);
+
return 0;
}
arch_initcall(mv64x60_device_setup);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Allow builing of pmac32 when CONFIG_NVRAM=m
Kamalesh Babulal ([EMAIL PROTECTED]) reports that CONFIG_NVRAM=m is valid in terms of Kconfig but fails to build with: Building modules, stage 2. MODPOST 1401 modules ERROR: "pmac_newworld" [arch/powerpc/platforms/powermac/nvram.ko] undefined! ERROR: "__alloc_bootmem" [arch/powerpc/platforms/powermac/nvram.ko] undefined! make[1]: *** [__modpost] Error The arch/powerpc/platforms/powermac/nvram.c code really needs to be builtin, but as it's compilation is dependant on a generic Kconfig symbol we force nvram.c to be builtin if CONFIG_NVRAM is 'y' or 'm' Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- arch/powerpc/platforms/powermac/Makefile |5 - arch/powerpc/platforms/powermac/setup.c |3 ++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile index 78093d7..4d72c8f 100644 --- a/arch/powerpc/platforms/powermac/Makefile +++ b/arch/powerpc/platforms/powermac/Makefile @@ -6,7 +6,10 @@ obj-y += pic.o setup.o time.o feature.o pci.o \ obj-$(CONFIG_PMAC_BACKLIGHT) += backlight.o obj-$(CONFIG_CPU_FREQ_PMAC)+= cpufreq_32.o obj-$(CONFIG_CPU_FREQ_PMAC64) += cpufreq_64.o -obj-$(CONFIG_NVRAM)+= nvram.o +# CONFIG_NVRAM is an arch. independant tristate symbol, for pmac32 we really +# need this to be a bool. Cheat here and pretend CONFIG_NVRAM=m is really +# CONFIG_NVRAM=y +obj-$(CONFIG_NVRAM:m=y)+= nvram.o # ppc64 pmac doesn't define CONFIG_NVRAM but needs nvram stuff obj-$(CONFIG_PPC64)+= nvram.o obj-$(CONFIG_PPC32)+= bootx_init.o diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c index bf44c54..00bd016 100644 --- a/arch/powerpc/platforms/powermac/setup.c +++ b/arch/powerpc/platforms/powermac/setup.c @@ -337,7 +337,8 @@ static void __init pmac_setup_arch(void) find_via_pmu(); smu_init(); -#if defined(CONFIG_NVRAM) || defined(CONFIG_PPC64) +#if defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE) || \ +defined(CONFIG_PPC64) pmac_nvram_init(); #endif -- 1.5.5.1 Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH 1/2][POWERPC] PIKA Warp: Update platform code to supportRev B boards
Ok, I think I have everybodys changes in. I will split out the DTS into
a separate patch. The changelog is in this one.
Cheers,
Sean
PIKA Warp: Update platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Full DTM support including critical temperature.
* Added POST information.
* Removed LED function, moved to new LED driver.
* Moved ad7414 to new style I2C initialization.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/boot/cuboot-warp.c b/arch/powerpc/boot/cuboot-warp.c
index eb108a8..2178021 100644
--- a/arch/powerpc/boot/cuboot-warp.c
+++ b/arch/powerpc/boot/cuboot-warp.c
@@ -10,6 +10,7 @@
#include "ops.h"
#include "4xx.h"
#include "cuboot.h"
+#include "stdio.h"
#define TARGET_4xx
#define TARGET_44x
@@ -17,14 +18,54 @@
static bd_t bd;
-static void warp_fixups(void)
+static void warp_fixup_one_nor(u32 from, u32 to)
{
- unsigned long sysclk = 6600;
+ void *devp;
+ char name[50];
+ u32 v[2];
+
+ sprintf(name, "/plb/opb/ebc/[EMAIL PROTECTED],0/[EMAIL PROTECTED]",
from);
+
+ devp = finddevice(name);
+ if (!devp)
+ return;
+
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[0] = to;
+ setprop(devp, "reg", v, sizeof(v));
+
+ printf("NOR 64M fixup %x -> %x\r\n", from, to);
+ }
+}
+
- ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
+static void warp_fixups(void)
+{
+ ibm440ep_fixup_clocks(6600, 11059200, 5000);
ibm4xx_sdram_fixup_memsize();
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+
+ /* Fixup for 64M flash on Rev A boards. */
+ if (bd.bi_flashsize == 0x400) {
+ void *devp;
+ u32 v[3];
+
+ devp = finddevice("/plb/opb/ebc/[EMAIL PROTECTED],0");
+ if (!devp)
+ return;
+
+ /* Fixup the size */
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[2] = bd.bi_flashsize;
+ setprop(devp, "reg", v, sizeof(v));
+ }
+
+ /* Fixup parition offsets */
+ warp_fixup_one_nor(0x30, 0x3f0);
+ warp_fixup_one_nor(0x34, 0x3f4);
+ warp_fixup_one_nor(0x38, 0x3f8);
+ }
}
diff --git a/arch/powerpc/platforms/44x/warp-nand.c
b/arch/powerpc/platforms/44x/warp-nand.c
index 9150318..d293c70 100644
--- a/arch/powerpc/platforms/44x/warp-nand.c
+++ b/arch/powerpc/platforms/44x/warp-nand.c
@@ -11,8 +11,10 @@
#include
#include
#include
+#include
#include
+
#ifdef CONFIG_MTD_NAND_NDFC
#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
@@ -35,13 +37,23 @@ static struct mtd_partition nand_parts[] = {
{
.name = "root",
.offset = 0x020,
- .size = 0x340
+ .size = 0x3E0
+ },
+ {
+ .name = "persistent",
+ .offset = 0x400,
+ .size = 0x400
},
{
- .name = "user",
- .offset = 0x360,
- .size = 0x0A0
+ .name = "persistent1",
+ .offset = 0x800,
+ .size = 0x400
},
+ {
+ .name = "persistent2",
+ .offset = 0xC00,
+ .size = 0x400
+ }
};
struct ndfc_controller_settings warp_ndfc_settings = {
@@ -67,19 +79,15 @@ static struct platform_device warp_ndfc_device = {
.resource = &warp_ndfc,
};
-static struct nand_ecclayout nand_oob_16 = {
- .eccbytes = 3,
- .eccpos = { 0, 1, 2, 3, 6, 7 },
- .oobfree = { {.offset = 8, .length = 16} }
-};
-
+/* Do NOT set the ecclayout: let it default so it is correct for both
+ * 64M and 256M flash chips.
+ */
static struct platform_nand_chip warp_nand_chip0 = {
.nr_chips = 1,
.chip_offset = CS_NAND_0,
.nr_partitions = ARRAY_SIZE(nand_parts),
.partitions = nand_parts,
- .chip_delay = 50,
- .ecclayout = &nand_oob_16,
+ .chip_delay = 20,
.priv = &warp_chip0_settings,
};
@@ -96,6 +104,23 @@ static struct platform_device warp_nand_device = {
static int warp_setup_nand_flash(void)
{
+ struct device_node *np;
+
+ /* Try to detect a rev A based on NOR size. */
+ np = of_find_compatible_node(NULL, NULL, "cfi-flash");
+ if (np) {
+ struct property *pp;
+
+ pp = of_find_property(np, "reg", NULL);
+ if (pp && (pp->length == 12)) {
+ u32 *v = pp->value;
+ if (v[2] == 0x400)
+ /* Rev A = 64M NAND */
+ warp_nand_c
Re: [RESEND][PATCH 2/2][POWERPC] PIKA Warp: Update platform code to supportRev B boards
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index b04a52e..3e95e99 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -132,40 +132,33 @@
[EMAIL PROTECTED],0 {
compatible = "pika,fpga";
- reg = <2 0 2200>;
+ reg = <2 0 1000>;
interrupts = <18 8>;
interrupt-parent = <&UIC0>;
};
+ [EMAIL PROTECTED],4000 {
+ compatible = "pika,fpga-sd";
+ reg = <2 4000 A00>;
+ };
+
[EMAIL PROTECTED],0 {
- compatible = "amd,s29gl512n",
"cfi-flash";
+ compatible = "amd,s29gl032a",
"cfi-flash";
bank-width = <2>;
- reg = <0 0 400>;
+ reg = <0 0 40>;
#address-cells = <1>;
#size-cells = <1>;
- [EMAIL PROTECTED] {
- label = "kernel";
- reg = <0 18>;
- };
- [EMAIL PROTECTED] {
- label = "root";
- reg = <18 348>;
- };
- [EMAIL PROTECTED] {
- label = "user";
- reg = <360 90>;
- };
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
label = "fpga";
- reg = <3f0 4>;
+ reg = <30 4>;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
label = "env";
- reg = <3f4 4>;
+ reg = <34 4>;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
label = "u-boot";
- reg = <3f8 8>;
+ reg = <38 8>;
};
};
};
@@ -186,18 +179,45 @@
reg = ;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
+ index = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ [EMAIL PROTECTED] {
+ compatible = "adi,ad7414";
+ reg = <4a>;
+ interrupts = <19 8>;
+ interrupt-parent = <&UIC0>;
+ };
};
GPIO0: [EMAIL PROTECTED] {
compatible = "ibm,gpio-440ep";
reg = ;
+ #gpio-cells = <2>;
+ gpio-controller;
};
GPIO1: [EMAIL PROTECTED] {
compatible = "ibm,gpio-440ep";
reg = ;
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ [EMAIL PROTECTED] {
+ compatible = "linux,gpio-led";
+ linux,name = ":green:";
+ gpios = <&GPIO1 31>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "linux,gpio-led";
+ linux,name = ":red:";
+ gp
Re: [PATCH] sysdev,mv64x60: MV64x60 device bus
Hi Remi,
On Mon, 28 Apr 2008 10:12:09 -0700 Remi Machet <[EMAIL PROTECTED]> wrote:
>
> +static struct of_device_id of_mv64x60_devices[] = {
__initdata, please.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpAmX071fC3E.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH 2/2][POWERPC] PIKA Warp: Update platform code to supportRev B boards
On Mon, Apr 28, 2008 at 7:50 PM, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
> index b04a52e..3e95e99 100644
You still need to have *some* kind of change log and a signed-off-by
line in this patch. :-)
There is one minor change that needs to be added below; otherwise:
Acked-by: Grant Likely <[EMAIL PROTECTED]>
(You can add my acked-by line to the next version of this patch if
you're only changing the thing I comment on).
Josh, when he respins it I think the dts changes are ready to be picked up.
> @@ -186,18 +179,45 @@
> GPIO1: [EMAIL PROTECTED] {
> compatible = "ibm,gpio-440ep";
> reg = ;
> + #gpio-cells = <2>;
> + gpio-controller;
> +
> + [EMAIL PROTECTED] {
>
> + compatible = "linux,gpio-led";
> + linux,name = ":green:";
> + gpios = <&GPIO1 31>;
Since #gpio-cells is '2'; the gpios property needs to reflect that.
It should be:
gpios = <&GPIO1 31 0>;
The second cell the GPIO controller would use for flags (inverted,
open-drain, etc).
> + };
> +
> + [EMAIL PROTECTED] {
> + compatible = "linux,gpio-led";
> + linux,name = ":red:";
> + gpios = <&GPIO1 30>;
ditto
> + };
>
>
> };
>
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add fast little-endian switch system call
Christoph Hellwig writes: > Am I missing something here or does this add a branch for every normal > syscall? It does, but the impact is so small as to be unmeasurable with lmbench, even on the null syscall measurement. The overhead of the easily-predicted not-taken branch is completely swamped by the amount of time that the sc and rfid instructions take. I had it under a config option at one point but then decided not to bother with that when I couldn't measure any difference. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH 2/2][POWERPC] PIKA Warp: Update platform code to supportRev B boards
PIKA Warp: Update DTS to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Added led entries.
* Added fpga-sd entry.
* Added ad7414 entry.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index b04a52e..c086501 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -132,40 +132,33 @@
[EMAIL PROTECTED],0 {
compatible = "pika,fpga";
- reg = <2 0 2200>;
+ reg = <2 0 1000>;
interrupts = <18 8>;
interrupt-parent = <&UIC0>;
};
+ [EMAIL PROTECTED],4000 {
+ compatible = "pika,fpga-sd";
+ reg = <2 4000 A00>;
+ };
+
[EMAIL PROTECTED],0 {
- compatible = "amd,s29gl512n",
"cfi-flash";
+ compatible = "amd,s29gl032a",
"cfi-flash";
bank-width = <2>;
- reg = <0 0 400>;
+ reg = <0 0 40>;
#address-cells = <1>;
#size-cells = <1>;
- [EMAIL PROTECTED] {
- label = "kernel";
- reg = <0 18>;
- };
- [EMAIL PROTECTED] {
- label = "root";
- reg = <18 348>;
- };
- [EMAIL PROTECTED] {
- label = "user";
- reg = <360 90>;
- };
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
label = "fpga";
- reg = <3f0 4>;
+ reg = <30 4>;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
label = "env";
- reg = <3f4 4>;
+ reg = <34 4>;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
label = "u-boot";
- reg = <3f8 8>;
+ reg = <38 8>;
};
};
};
@@ -186,18 +179,45 @@
reg = ;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
+ index = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ [EMAIL PROTECTED] {
+ compatible = "adi,ad7414";
+ reg = <4a>;
+ interrupts = <19 8>;
+ interrupt-parent = <&UIC0>;
+ };
};
GPIO0: [EMAIL PROTECTED] {
compatible = "ibm,gpio-440ep";
reg = ;
+ #gpio-cells = <2>;
+ gpio-controller;
};
GPIO1: [EMAIL PROTECTED] {
compatible = "ibm,gpio-440ep";
reg = ;
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ [EMAIL PROTECTED] {
+ compatible = "linux,gpio-led";
+ linux,name = ":green:";
+ gpios = <&GPIO1 31 0>;
+
Re: [RESEND][PATCH 1/2][POWERPC] PIKA Warp: Update platform code to supportRev B boards
A change to the dts to get gpios correct broke the led code.
PIKA Warp: Update platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Full DTM support including critical temperature.
* Added POST information.
* Removed LED function, moved to new LED driver.
* Moved ad7414 to new style I2C initialization.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/boot/cuboot-warp.c b/arch/powerpc/boot/cuboot-warp.c
index eb108a8..2178021 100644
--- a/arch/powerpc/boot/cuboot-warp.c
+++ b/arch/powerpc/boot/cuboot-warp.c
@@ -10,6 +10,7 @@
#include "ops.h"
#include "4xx.h"
#include "cuboot.h"
+#include "stdio.h"
#define TARGET_4xx
#define TARGET_44x
@@ -17,14 +18,54 @@
static bd_t bd;
-static void warp_fixups(void)
+static void warp_fixup_one_nor(u32 from, u32 to)
{
- unsigned long sysclk = 6600;
+ void *devp;
+ char name[50];
+ u32 v[2];
+
+ sprintf(name, "/plb/opb/ebc/[EMAIL PROTECTED],0/[EMAIL PROTECTED]",
from);
+
+ devp = finddevice(name);
+ if (!devp)
+ return;
+
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[0] = to;
+ setprop(devp, "reg", v, sizeof(v));
+
+ printf("NOR 64M fixup %x -> %x\r\n", from, to);
+ }
+}
+
- ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
+static void warp_fixups(void)
+{
+ ibm440ep_fixup_clocks(6600, 11059200, 5000);
ibm4xx_sdram_fixup_memsize();
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+
+ /* Fixup for 64M flash on Rev A boards. */
+ if (bd.bi_flashsize == 0x400) {
+ void *devp;
+ u32 v[3];
+
+ devp = finddevice("/plb/opb/ebc/[EMAIL PROTECTED],0");
+ if (!devp)
+ return;
+
+ /* Fixup the size */
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[2] = bd.bi_flashsize;
+ setprop(devp, "reg", v, sizeof(v));
+ }
+
+ /* Fixup parition offsets */
+ warp_fixup_one_nor(0x30, 0x3f0);
+ warp_fixup_one_nor(0x34, 0x3f4);
+ warp_fixup_one_nor(0x38, 0x3f8);
+ }
}
diff --git a/arch/powerpc/platforms/44x/warp-nand.c
b/arch/powerpc/platforms/44x/warp-nand.c
index 9150318..d293c70 100644
--- a/arch/powerpc/platforms/44x/warp-nand.c
+++ b/arch/powerpc/platforms/44x/warp-nand.c
@@ -11,8 +11,10 @@
#include
#include
#include
+#include
#include
+
#ifdef CONFIG_MTD_NAND_NDFC
#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
@@ -35,13 +37,23 @@ static struct mtd_partition nand_parts[] = {
{
.name = "root",
.offset = 0x020,
- .size = 0x340
+ .size = 0x3E0
+ },
+ {
+ .name = "persistent",
+ .offset = 0x400,
+ .size = 0x400
},
{
- .name = "user",
- .offset = 0x360,
- .size = 0x0A0
+ .name = "persistent1",
+ .offset = 0x800,
+ .size = 0x400
},
+ {
+ .name = "persistent2",
+ .offset = 0xC00,
+ .size = 0x400
+ }
};
struct ndfc_controller_settings warp_ndfc_settings = {
@@ -67,19 +79,15 @@ static struct platform_device warp_ndfc_device = {
.resource = &warp_ndfc,
};
-static struct nand_ecclayout nand_oob_16 = {
- .eccbytes = 3,
- .eccpos = { 0, 1, 2, 3, 6, 7 },
- .oobfree = { {.offset = 8, .length = 16} }
-};
-
+/* Do NOT set the ecclayout: let it default so it is correct for both
+ * 64M and 256M flash chips.
+ */
static struct platform_nand_chip warp_nand_chip0 = {
.nr_chips = 1,
.chip_offset = CS_NAND_0,
.nr_partitions = ARRAY_SIZE(nand_parts),
.partitions = nand_parts,
- .chip_delay = 50,
- .ecclayout = &nand_oob_16,
+ .chip_delay = 20,
.priv = &warp_chip0_settings,
};
@@ -96,6 +104,23 @@ static struct platform_device warp_nand_device = {
static int warp_setup_nand_flash(void)
{
+ struct device_node *np;
+
+ /* Try to detect a rev A based on NOR size. */
+ np = of_find_compatible_node(NULL, NULL, "cfi-flash");
+ if (np) {
+ struct property *pp;
+
+ pp = of_find_property(np, "reg", NULL);
+ if (pp && (pp->length == 12)) {
+ u32 *v = pp->value;
+ if (v[2] == 0x400)
+ /* Rev A = 64M NAND */
+ warp_nand_chip0.nr_partitions = 2;
+ }
+ of_node_put(np);
RE: [PATCH v2] MSI driver for Freescale 83xx/85xx/86xx cpu
> -Original Message-
> From: Gala Kumar
> Sent: Tuesday, April 22, 2008 9:38 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH v2] MSI driver for Freescale 83xx/85xx/86xx cpu
>
> > diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
> > Makefile index 6d386d0..e60a238 100644
> > --- a/arch/powerpc/sysdev/Makefile
> > +++ b/arch/powerpc/sysdev/Makefile
> > @@ -4,6 +4,7 @@ endif
> >
> > mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o
> > mpic_pasemi_msi.o
> > obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
> > +obj-$(CONFIG_FSL_PCI) += fsl_msi.o
>
> can we do something like:
> fsl_pci-$(CONFIG_MSI) += fsl_msi.o
> obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl_pci-y)
>
> > obj-$(CONFIG_PPC_MPC106)+= grackle.o
> > obj-$(CONFIG_PPC_DCR_NATIVE)+= dcr-low.o
OK, Thanks
>
> > +static int fsl_msi_init_allocator(struct fsl_msi *msi_data) {
> > + int rc, size;
> > +
> > + size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(long);
>
> should this be long or u32?
>
> > +
> > + msi_data->fsl_msi_bitmap = kzalloc(size, GFP_KERNEL);
> > +
> > + if (msi_data->fsl_msi_bitmap == NULL) {
> > + pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
> > + __func__);
> > + return -ENOMEM;
> > + }
> > +
> > + rc = fsl_msi_free_dt_hwirqs(msi_data);
> > + if (rc)
> > + goto out_free;
> > +
> > + return 0;
> > +out_free:
> > + kfree(msi_data->fsl_msi_bitmap);
> > +
> > + msi_data->fsl_msi_bitmap = NULL;
> > + return rc;
> > +
> > +}
> > +
> > +static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int
> > type)
> > +{
> > + if (type == PCI_CAP_ID_MSIX)
> > + pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
> > +
> > + return 0;
> > +}
> > +
> > +static void fsl_teardown_msi_irqs(struct pci_dev *pdev) {
> > + struct msi_desc *entry;
> > + struct fsl_msi *msi_data = fsl_msi;
> > +
> > + list_for_each_entry(entry, &pdev->msi_list, list) {
> > + if (entry->irq == NO_IRQ)
> > + continue;
> > + set_irq_msi(entry->irq, NULL);
> > + fsl_msi_free_hwirqs(msi_data,
> virq_to_hw(entry->irq), 1);
> > + irq_dispose_mapping(entry->irq);
> > + }
> > +
> > + return;
> > +}
> > +
> > +static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
> > + struct msi_msg *msg)
> > +{
> > + struct fsl_msi *msi_data = fsl_msi;
> > +
> > + msg->address_lo = msi_data->msi_addr_lo;
> > + msg->address_hi = msi_data->msi_addr_hi;
> > + msg->data = hwirq;
> > +
> > + pr_debug("%s: allocated srs: %d, ibs: %d\n",
> > + __func__, hwirq / INT_PER_MSIR, hwirq % INT_PER_MSIR); }
> > +
> > +static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int
> > type)
> > +{
> > + irq_hw_number_t hwirq;
> > + int rc;
> > + unsigned int virq;
> > + struct msi_desc *entry;
> > + struct msi_msg msg;
> > + struct fsl_msi *msi_data = fsl_msi;
> > +
> > + list_for_each_entry(entry, &pdev->msi_list, list) {
> > + hwirq = fsl_msi_alloc_hwirqs(msi_data, 1);
> > + if (hwirq < 0) {
> > + rc = hwirq;
> > + pr_debug("%s: fail allocating msi interrupt\n",
> > + __func__);
> > + goto out_free;
> > + }
> > +
> > + virq = irq_create_mapping(msi_data->irqhost, hwirq);
> > +
> > + if (virq == NO_IRQ) {
> > + pr_debug("%s: fail mapping hwirq 0x%lx\n",
> > + __func__, hwirq);
> > + fsl_msi_free_hwirqs(msi_data, hwirq, 1);
> > + rc = -ENOSPC;
> > + goto out_free;
> > + }
> > + set_irq_msi(virq, entry);
> > +
> > + fsl_compose_msi_msg(pdev, hwirq, &msg);
> > + write_msi_msg(virq, &msg);
> > + }
> > + return 0;
> > +
> > +out_free:
> > + return rc;
> > +}
> > +
> > +void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc) {
> > + unsigned int cascade_irq;
> > + struct fsl_msi *msi_data = fsl_msi;
> > + int msir_index = -1;
> > + u32 msir_value = 0;
> > + u32 intr_index;
> > + u32 have_shift = 0;
> > +
> > + spin_lock(&desc->lock);
> > + if ((msi_data->feature & FSL_PIC_IP_MASK) == FSL_PIC_IP_IPIC) {
> > + if (desc->chip->mask_ack)
> > + desc->chip->mask_ack(irq);
> > + else {
> > + desc->chip->mask(irq);
> > + desc->chip->ack(irq);
> > + }
> > + }
> > +
> > + if (unlikely(desc->status & IRQ_INPROGRESS))
> > + goto unlock;
> > +
> > + msir_index = (int)(desc->handler_data);
> > +
> > + if (msir_index >= NR_MSIR)
> > + cascade_irq = NO_IRQ;
> > +
> > + desc->status |= IRQ_INPROGRESS;
> > + switch (fsl_msi->feature & FSL_PIC_IP_MASK)
Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
Scott Wood writes: > On Fri, Apr 25, 2008 at 02:57:24PM +0200, Guennadi Liakhovetski wrote: > > is there any specific reason, why out of these 7 patches only the first > > one made it into the mainline? AFAICS, there has been only one comment, > > suggesting to replace printk with dev_err on two occasions in one of > > the patches... > > A while ago Paul said on IRC he'd prefer to do the TLF_SLEEPING hack more > like the soft IRQ disabling that 64-bit uses. I haven't yet had a chance > to look into it, so the patch collects dust, despite the current > implementation of TLF_SLEEPING working just fine. I have taken a closer look at the TLF_SLEEPING patch and crystallized my thoughts about it a bit: 1. Too many ifdefs - it's only a few instructions extra, so if we're going to have the TLF_SLEEPING stuff we might as well have it unconditionally. 2. It seems convoluted to me to go through transfer_to_handler_cont and ret_from_except when we could just get out directly through fast_exception_return, given that we are not calling a handler. The only thing to watch out for there is that r7 and r8 haven't been modified (or have been restored if they have). 3. The style in all the assembly code is not to have spaces after commas separating instruction operands. The untested patch below is what I was thinking of. If you'd like to try it out, I'd be interested to hear how it goes. Paul. diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 84c8686..162500f 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -146,6 +146,7 @@ transfer_to_handler: lwz r12,TI_LOCAL_FLAGS(r9) mtcrf 0x01,r12 bt- 31-TLF_NAPPING,4f + bt- 31-TLF_SLEEPING,7f #endif /* CONFIG_6xx */ .globl transfer_to_handler_cont transfer_to_handler_cont: @@ -163,6 +164,13 @@ transfer_to_handler_cont: 4: rlwinm r12,r12,0,~_TLF_NAPPING stw r12,TI_LOCAL_FLAGS(r9) b power_save_6xx_restore + +7: rlwinm r12,r12,0,~TLF_SLEEPING + stw r12,TI_LOCAL_FLAGS(r9) + lwz r9,_MSR(r11)/* if sleeping, clear MSR.EE */ + rlwinm r9,r9,0,~MSR_EE + lwz r12,_LINK(r11) /* and return to address in LR */ + b fast_exception_return #endif /* diff --git a/include/asm-powerpc/thread_info.h b/include/asm-powerpc/thread_info.h index d030f5c..1cd8c8f 100644 --- a/include/asm-powerpc/thread_info.h +++ b/include/asm-powerpc/thread_info.h @@ -147,8 +147,10 @@ static inline struct thread_info *current_thread_info(void) /* Bits in local_flags */ /* Don't move TLF_NAPPING without adjusting the code in entry_32.S */ #define TLF_NAPPING0 /* idle thread enabled NAP mode */ +#define TLF_SLEEPING 1 /* suspend code enabled SLEEP mode */ #define _TLF_NAPPING (1 << TLF_NAPPING) +#define _TLF_SLEEPING (1 << TLF_SLEEPING) #endif /* __KERNEL__ */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
I wrote: > +7: rlwinm r12,r12,0,~TLF_SLEEPING That should be rlwinm r12,r12,0,~_TLF_SLEEPING (with the leading underscore), of course. Thanks to Stephen Rothwell for pointing that out. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH 1/2][POWERPC] PIKA Warp: Update platform code to supportRev B boards
It doesn't help that both of these patches have the same subject line, nor that it starts with "Re:". :( Also, I find the statement "A change to the dts to get gpios correct broke the led code" a bit opaque. It doesn't tell me in what way it was broken or what this patch does to correct, or even what the change was in enough detail that I could find the change in the git repository. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Add struct iommu_table argument to iommu_map_sg()
Make iommu_map_sg take a struct iommu_table. It did so before commit
740c3ce66700640a6e6136ff679b067e92125794 (iommu sg merging: ppc: make
iommu respect the segment size limits).
This stops the function looking in the archdata.dma_data for the iommu
table because in the future it will be called with a device that has
no table there.
This also has the nice side effect of making iommu_map_sg() match the
other map functions.
Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/dma_64.c |2 +-
arch/powerpc/kernel/iommu.c |7 +++
include/asm-powerpc/iommu.h |6 +++---
3 files changed, 7 insertions(+), 8 deletions(-)
Index: upstream/arch/powerpc/kernel/dma_64.c
===
--- upstream.orig/arch/powerpc/kernel/dma_64.c
+++ upstream/arch/powerpc/kernel/dma_64.c
@@ -68,7 +68,7 @@ static void dma_iommu_unmap_single(struc
static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction)
{
- return iommu_map_sg(dev, sglist, nelems,
+ return iommu_map_sg(dev, dev->archdata.dma_data, sglist, nelems,
device_to_mask(dev), direction);
}
Index: upstream/arch/powerpc/kernel/iommu.c
===
--- upstream.orig/arch/powerpc/kernel/iommu.c
+++ upstream/arch/powerpc/kernel/iommu.c
@@ -267,11 +267,10 @@ static void iommu_free(struct iommu_tabl
spin_unlock_irqrestore(&(tbl->it_lock), flags);
}
-int iommu_map_sg(struct device *dev, struct scatterlist *sglist,
-int nelems, unsigned long mask,
-enum dma_data_direction direction)
+int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
+struct scatterlist *sglist, int nelems,
+unsigned long mask, enum dma_data_direction direction)
{
- struct iommu_table *tbl = dev->archdata.dma_data;
dma_addr_t dma_next = 0, dma_addr;
unsigned long flags;
struct scatterlist *s, *outs, *segstart;
Index: upstream/include/asm-powerpc/iommu.h
===
--- upstream.orig/include/asm-powerpc/iommu.h
+++ upstream/include/asm-powerpc/iommu.h
@@ -79,9 +79,9 @@ extern void iommu_free_table(struct iomm
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
-extern int iommu_map_sg(struct device *dev, struct scatterlist *sglist,
- int nelems, unsigned long mask,
- enum dma_data_direction direction);
+extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
+ struct scatterlist *sglist, int nelems,
+ unsigned long mask, enum dma_data_direction direction);
extern void iommu_unmap_sg(struct iommu_table *tbl, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] windfarm: add PowerMac 12,1 support
From: Etienne Bersac <[EMAIL PROTECTED]>
Implement a new driver named windfarm_pm121 which drive fans on PowerMac
12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
windfarm_pm81 driver from Benjamin Herrenschmidt.
Signed-off-by: Etienne Bersac <[EMAIL PROTECTED]>
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
Initial patch by Etienne, fixes by David, but they couldn't be
bothered making that a single patch for merging so here it is.
(Etienne, the accent on your name didn't survive the process sorry)
arch/powerpc/configs/g5_defconfig |1
drivers/macintosh/Kconfig |8
drivers/macintosh/Makefile |5
drivers/macintosh/windfarm_lm75_sensor.c|6
drivers/macintosh/windfarm_max6690_sensor.c | 20
drivers/macintosh/windfarm_pm121.c | 1040
drivers/macintosh/windfarm_smu_controls.c |4
7 files changed, 1078 insertions(+), 6 deletions(-)
--- linux-work.orig/arch/powerpc/configs/g5_defconfig 2008-04-22
10:15:29.0 +1000
+++ linux-work/arch/powerpc/configs/g5_defconfig2008-04-29
15:32:50.0 +1000
@@ -696,6 +696,7 @@ CONFIG_WINDFARM=y
CONFIG_WINDFARM_PM81=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
+CONFIG_WINDFARM_PM121=y
# CONFIG_PMAC_RACKMETER is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
Index: linux-work/drivers/macintosh/Kconfig
===
--- linux-work.orig/drivers/macintosh/Kconfig 2008-03-03 11:58:43.0
+1100
+++ linux-work/drivers/macintosh/Kconfig2008-04-29 15:32:50.0
+1000
@@ -234,6 +234,14 @@ config WINDFARM_PM112
which are the recent dual and quad G5 machines using the
970MP dual-core processor.
+config WINDFARM_PM121
+ tristate "Support for thermal management on PowerMac12,1"
+ depends on WINDFARM && I2C && PMAC_SMU
+ select I2C_POWERMAC
+ help
+ This driver provides thermal control for the PowerMac12,1
+ which is the iMac G5 (iSight)
+
config ANSLCD
tristate "Support for ANS LCD display"
depends on ADB_CUDA && PPC_PMAC
Index: linux-work/drivers/macintosh/Makefile
===
--- linux-work.orig/drivers/macintosh/Makefile 2007-09-28 11:42:07.0
+1000
+++ linux-work/drivers/macintosh/Makefile 2008-04-29 15:32:50.0
+1000
@@ -42,4 +42,9 @@ obj-$(CONFIG_WINDFARM_PM112) += windfarm
windfarm_smu_sensors.o \
windfarm_max6690_sensor.o \
windfarm_lm75_sensor.o windfarm_pid.o
+obj-$(CONFIG_WINDFARM_PM121) += windfarm_pm121.o windfarm_smu_sat.o \
+ windfarm_smu_controls.o \
+ windfarm_smu_sensors.o \
+ windfarm_max6690_sensor.o \
+ windfarm_lm75_sensor.o windfarm_pid.o
obj-$(CONFIG_PMAC_RACKMETER) += rack-meter.o
Index: linux-work/drivers/macintosh/windfarm_lm75_sensor.c
===
--- linux-work.orig/drivers/macintosh/windfarm_lm75_sensor.c2007-09-28
11:42:07.0 +1000
+++ linux-work/drivers/macintosh/windfarm_lm75_sensor.c 2008-04-29
15:32:50.0 +1000
@@ -127,6 +127,12 @@ static struct wf_lm75_sensor *wf_lm75_cr
*/
if (!strcmp(loc, "Hard drive") || !strcmp(loc, "DRIVE BAY"))
lm->sens.name = "hd-temp";
+ else if (!strcmp(loc, "Incoming Air Temp"))
+ lm->sens.name = "incoming-air-temp";
+ else if (!strcmp(loc, "ODD Temp"))
+ lm->sens.name = "optical-drive-temp";
+ else if (!strcmp(loc, "HD Temp"))
+ lm->sens.name = "hard-drive-temp";
else
goto fail;
Index: linux-work/drivers/macintosh/windfarm_max6690_sensor.c
===
--- linux-work.orig/drivers/macintosh/windfarm_max6690_sensor.c 2007-09-28
11:42:07.0 +1000
+++ linux-work/drivers/macintosh/windfarm_max6690_sensor.c 2008-04-29
15:32:50.0 +1000
@@ -77,18 +77,28 @@ static struct wf_sensor_ops wf_max6690_o
.owner = THIS_MODULE,
};
-static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr)
+static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr,
+ const char *loc)
{
struct wf_6690_sensor *max;
- char *name = "backside-temp";
+ char *name;
max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
if (max == NULL) {
printk(KERN_ERR "windfarm: Couldn't create MAX6690 sensor %s: "
- "no memory\n", name);
+
Re: [RESEND][PATCH 1/2][POWERPC] PIKA Warp: Update platform code tosupportRev B boards
On Tue, 29 Apr 2008 15:08:29 +1000 "Paul Mackerras" <[EMAIL PROTECTED]> wrote: > It doesn't help that both of these patches have the same subject line, > nor that it starts with "Re:". :( Sorry about that. I just split up the two patches, but the same subject does apply to both. The code currently in the mainline kernel is for a Rev A. Since there are no Rev As outside of PIKA, that is not very useful. These patches bring the platform code up to Rev B standards (while still maintaining Rev A support). So the subject is correct for both. > Also, I find the statement "A change to the dts to get gpios correct > broke the led code" a bit opaque. It doesn't tell me in what way it > was broken or what this patch does to correct, or even what the change > was in enough detail that I could find the change in the git > repository. You won't find it. One of the problems is that I am basically adding patches to patches to patches, but since none of them are in a mainline git, they all just keep showing up as one big patch. That comment was meant as a quick note to explain why the platform patch changed from the previous platform patch. Short of diffing the patches, you can't easily see how they changed. After the Warp is released (sometime in May), the hardware churn should end and I can submit patches one at a time rather than one massive patch. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
Use a resource_size_t instead of unsigned long since some arch's are
capable of having ioremap deal with addresses greater than the size of a
unsigned long.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
include/linux/io.h |4 ++--
lib/devres.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index e3b2dda..831f57c 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,9 +58,9 @@ static inline void devm_ioport_unmap(struct device *dev, void
__iomem *addr)
}
#endif
-void __iomem * devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
-void __iomem * devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
diff --git a/lib/devres.c b/lib/devres.c
index edc27a5..26c87c4 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -20,7 +20,7 @@ static int devm_ioremap_match(struct device *dev, void *res,
void *match_data)
*
* Managed ioremap(). Map is automatically unmapped on driver detach.
*/
-void __iomem *devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size)
{
void __iomem **ptr, *addr;
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(devm_ioremap);
* Managed ioremap_nocache(). Map is automatically unmapped on driver
* detach.
*/
-void __iomem *devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size)
{
void __iomem **ptr, *addr;
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
build failure on efika
My test builds for efika currently fail with this message: FATAL: drivers/serial/mpc52xx_uart: struct of_device_id is not terminated with a NULL entry! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [sub-make] Error 2 Could you do a little patch to add the NULL entry please? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
Kumar Gala wrote: Use a resource_size_t instead of unsigned long since some arch's are capable of having ioremap deal with addresses greater than the size of a unsigned long. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
Tejun Heo wrote: Kumar Gala wrote: Use a resource_size_t instead of unsigned long since some arch's are capable of having ioremap deal with addresses greater than the size of a unsigned long. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> Fine with me, too. I think devres changes should go via GregKH (device core) or Jesse (PCI) rather than my libata tree, unless there are obvious dependencies... Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
