* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Will Schmidt @ 2007-11-28 0:15 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071120012815.GB7969@austin.ibm.com>
(resending with the proper "from" addr this time).
I'm seeing some funky behavior on power5/power6 partitions with this
patch. A "/sbin/reboot" is now behaving much more like a
"/sbin/halt".
Anybody else seeing this, or is it time for me to call an exorcist for
my boxes?
-Will
On Mon, 2007-11-19 at 19:28 -0600, Linas Vepstas wrote:
> The rtas_os_term() routine was being called at the wrong time.
> The actual rtas call "os-term" will not ever return, and so
> calling it from the panic notifier is too early. Instead,
> call it from the machine_reset() call.
>
> The patch splits the rtas_os_term() routine into two: one
> part to capture the kernel panic message, invoked during
> the panic notifier, and another part that is invoked during
> machine_reset().
>
> Prior to this patch, the os-term call was never being made,
> because panic_timeout was always non-zero. Calling os-term
> helps keep the hypervisor happy! We have to keep the hypervisor
> happy to avoid service, dump and error reporting problems.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
> One could make a strong argument to move all of this code
> from kernel/rtas.c to platforms/pseries/setup.c I did not
> do this, just so as to make the changes minimal.
>
> arch/powerpc/kernel/rtas.c | 12 ++++++------
> arch/powerpc/platforms/pseries/setup.c | 3 ++-
> include/asm-powerpc/rtas.h | 3 ++-
> 3 files changed, 10 insertions(+), 8 deletions(-)
>
> Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/arch/powerpc/kernel/rtas.c 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c 2007-11-19 19:01:10.000000000 -0600
> @@ -631,18 +631,18 @@ void rtas_halt(void)
> /* Must be in the RMO region, so we place it here */
> static char rtas_os_term_buf[2048];
>
> -void rtas_os_term(char *str)
> +void rtas_panic_msg(char *str)
> {
> - int status;
> + snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
> +}
>
> - if (panic_timeout)
> - return;
> +void rtas_os_term(void)
> +{
> + int status;
>
> if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term"))
> return;
>
> - snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
> -
> do {
> status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
> __pa(rtas_os_term_buf));
> Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/arch/powerpc/platforms/pseries/setup.c 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c 2007-11-19 19:01:10.000000000 -0600
> @@ -507,7 +507,8 @@ define_machine(pseries) {
> .restart = rtas_restart,
> .power_off = pSeries_power_off,
> .halt = rtas_halt,
> - .panic = rtas_os_term,
> + .panic = rtas_panic_msg,
> + .machine_shutdown = rtas_os_term,
> .get_boot_time = rtas_get_boot_time,
> .get_rtc_time = rtas_get_rtc_time,
> .set_rtc_time = rtas_set_rtc_time,
> Index: linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/include/asm-powerpc/rtas.h 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h 2007-11-19 19:01:10.000000000 -0600
> @@ -164,7 +164,8 @@ extern int rtas_call(int token, int, int
> extern void rtas_restart(char *cmd);
> extern void rtas_power_off(void);
> extern void rtas_halt(void);
> -extern void rtas_os_term(char *str);
> +extern void rtas_panic_msg(char *str);
> +extern void rtas_os_term(void);
> extern int rtas_get_sensor(int sensor, int index, int *state);
> extern int rtas_get_power_level(int powerdomain, int *level);
> extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] [POWERPC] kernel_execve is identical in 32 and 64 bit
From: Stephen Rothwell @ 2007-11-28 0:13 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
so concolidate it into misc.S.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/misc.S | 8 ++++++++
arch/powerpc/kernel/misc_32.S | 7 -------
arch/powerpc/kernel/misc_64.S | 7 -------
3 files changed, 8 insertions(+), 14 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 330c9dc..74ce0c7 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -14,6 +14,7 @@
* 2 of the License, or (at your option) any later version.
*/
#include <asm/ppc_asm.h>
+#include <asm/unistd.h>
.text
@@ -43,3 +44,10 @@ _GLOBAL(add_reloc_offset)
add r3,r3,r5
mtlr r0
blr
+
+_GLOBAL(kernel_execve)
+ li r0,__NR_execve
+ sc
+ bnslr
+ neg r3,r3
+ blr
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 8b642ab..ea11378 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -793,13 +793,6 @@ _GLOBAL(kernel_thread)
addi r1,r1,16
blr
-_GLOBAL(kernel_execve)
- li r0,__NR_execve
- sc
- bnslr
- neg r3,r3
- blr
-
/*
* This routine is just here to keep GCC happy - sigh...
*/
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index bbb3ba5..a3c491e 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -518,13 +518,6 @@ _GLOBAL(giveup_altivec)
#endif /* CONFIG_ALTIVEC */
-_GLOBAL(kernel_execve)
- li r0,__NR_execve
- sc
- bnslr
- neg r3,r3
- blr
-
/* kexec_wait(phys_cpu)
*
* wait for the flag to change, indicating this kernel is going away but
--
1.5.3.6
^ permalink raw reply related
* Re: Xilinx devicetrees
From: John Williams @ 2007-11-27 23:55 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: Michal Simek, linuxppc-embedded
In-Reply-To: <20071125181506.EE2041BA004F@mail141-cpk.bigfish.com>
Hi folks,
Stephen Neuendorffer wrote:
> > Binding it to a kernel, is a non-starter for us.
>
> I agree that this is not the best way of leveraging the power of device
> trees. The point is that by using a device tree, you haven't lost
> anything you can do currently. In the future we might have one kernel
> which supports all versions of all our IP, along with all flavors of
> microblaze and powerpc... You would only ever need to recompile this
> kernel as a final optimization, if at all.
I strongly support the OF / device tree work being done, from its own
perspective and also as a path to MicroBlaze/PPC unification, however
there is one critical difference that I have not seen adequately
addressed yet.
MicroBlaze is a highly configurable CPU in terms of its instruction set,
features and so on. To make use of this, it is essential that each
kernel image be compiled to match the CPU configuration. While a
generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc)
would run on any CPU, performance would be abysmal.
In my view it's not acceptable to present these as options for the user
to select at kernel config time. With N yes/no parameters, there is 1
correct configuration, and 2^N-1 incorrect ones. The odds of the user
falling upon a configuration that at worst fails to boot, or at best is
not optimally matched to the hardware, are high.
This same issue also applies to C libraries and apps - they must be
compiled with prior knowledge of the CPU. This is why our
microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is almost 400meg!
Wrapping every mul, div, shift etc in a function call is clearly not
feasible. Things like the msrset/msrclr ops have a modest but
measurable impact on kernel code size and performance - it's just not
reasonable to add any level of indirection in there.
I have thought about dynamic (boot-time) code re-writing as one
possibility here, but it very quickly gets nasty. All of the
"optimised" opcodes (MUL/DIV/Shift etc) are smaller than their emulated
counterparts, so in principle we could re-write the text segment with
the optimised opcode, then NOP pad, but that's still inefficient. As
soon as we start talking about dynamic code relocation, re-writing
relative offsets in loops, ... yuck.. We'd be putting half of mb-ld
into the arch early boot code (or bootloader...)
The opposite approach, to build with all instructions enabled and
install exception handlers to deal with the fixups, is also pretty awful.
I find myself asking the question - for what use cases does the current
static approach used in MicroBlaze (with the PetaLinux BSP /
Kconfig.auto) *not* work?
One compromise approach might be to have a script in
arch/microblaze/scripts, called by the arch Makefile, that cracks open
the DT at build time and extracts appropriate cpu flags.
Finally, what is the LKML position on DT files going into the kernel
source tree?
Regards,
John
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Dale Farnsworth @ 2007-11-27 23:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <751B3227-484E-45BE-B233-D4A8CAC2F3FD@kernel.crashing.org>
On Tue, Nov 27, 2007 at 10:26:59AM -0600, Kumar Gala wrote:
> On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote:
> >I wrote:
> >>Kumar Gala wrote:
> >>>>>Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or
> >>>>>when
> >>>>>calling 'reboot' in the shell, it just hangs. Using the same dts
> >>>>>and
> >>>>>resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
> >>>>>someone who does should be able to confirm whether the issue
> >>>>>exists
> >>>>>or
> >>>>>not by just attempting to reboot via bash.
> >>>
> >>>Can someone do a git-bisect and find the patch that breaks things?
> >>
> >>I'll see if I can reproduce it on my 8548cds. If so, I'll then git-
> >>bisect.
> >
> >I tried this with the current powerpc.git tree on my mpc8548cds, and
> >the reboot command works for me. The system rebooted just fine.
>
> I'm wondering if there is an issue rebooting if we are in an oops.
I still can't reproduce it. Current powerpc.git reboots OK after an
oops on my 8548cds. As long as I make it to "Rebooting in 180 seconds..",
it resets 3 minutes later. It may be hw-dependent as well as
sw-dependent.
-Dale
^ permalink raw reply
* Re: [PATCH] sys_indirect kernel implementation for PowerPC
From: Arnd Bergmann @ 2007-11-27 22:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071121144245.e8abf9e8.sfr@canb.auug.org.au>
On Wednesday 21 November 2007, Stephen Rothwell wrote:
> > +++ b/include/asm-powerpc/systbl.h
> > @@ -313,3 +313,4 @@ COMPAT_SYS_SPU(timerfd)
> > =A0SYSCALL_SPU(eventfd)
> > =A0COMPAT_SYS_SPU(sync_file_range2)
> > =A0COMPAT_SYS(fallocate)
> > +COMPAT_SYS(indirect)
>=20
> Do the SPUs want this?
Excellent question. Sorry for being late in my reply here. The calls
that are marked non-spu capable are those that are harmful when run
on the SPU, e.g. because they modify the signal mask -- the SPU cannot
receive signals itself.
sys_indirect is potentially very useful on the SPU, but we can't allow
it if it gives you access to all other syscalls. If we want to use it
on the SPU at some point, we may have to provide an alternative
implementation that walks the spu_syscall_table instead.
OTOH, if sys_indirect is mostly useful for the eventual addition of
syslets, we can leave it out, because syslets don't make sense if
you have no multithreading capability.
Arnd <><
^ permalink raw reply
* Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-27 10:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]
Hi,
I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error".
I am not sure if I missed out something.
I would really appreciate it if somebody could help me on this.
I have posted the source code below, as well as the complete message.
Many thanks!
SOURCE CODE:
----------------------------------------------------------------------
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
MODULE_LICENSE("GPL");
#define BCSR_BASE 0xC0002000
#define BCSR0 0
#define BCSR1 1
#define BCSR2 2
#define USER_LED 0x2
#define SIZE_TO_MAP 10
#define LED_ON 0
uint __iomem *bcsrbase = NULL;
static int __init initFunction(void) {
uint tmp;
printk("<1> Calling init function.\n");
printk("<1> bcsrbase value %p...\n",bcsrbase);
printk("<1> Remapping %x...\n",BCSR_BASE);
/*map*/
bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
printk("<1> bcsrbase new value %p...\n",bcsrbase);
/*read value*/
/*based on PPC440EPx document, BCSR0 is BoardID*/
tmp = in_be32(bcsrbase + BCSR0 /* BCSR0 */);
printk("<1> BCSR0 %x...\n",tmp);
/*try to output something*/
//out_be32(bcsrbase , /*LED_ON*/);
return 0;
}
static void __exit cleanupFunction(void) {
printk("<1> Calling cleanup function.\n");
/*unmap*/
iounmap(bcsrbase);
}
module_init(initFunction);
module_exit(cleanupFunction);
----------------------------------------------------------------------
ERROR MESSAGE:
----------------------------------------------------------------------
/mnt/flash_fs/var/ftp # insmod bcsr.ko
Calling init function.
bcsrbase value 00000000...
Remapping c0002000...
bcsrbase new value d50fe000...
Machine check in kernel mode.
Data Read PLB Error
OPB to PLB3: BSTAT= 0x00000000
PLB3 to PLB4: BEAR=0xffffffffffff7fff BESR0=0x00000000 BESR1=0x00000000
PLB4 to PLB3: BEAR=0xfd7fffffffffffff BESR0=0x00000000 BESR1=0x00000000
PLB3 to OPB: BEAR=0xffffffff BESR0=0x00000000 BESR1=0x00000000
PLB3 arbiter: BEAR=0xbfffffef ACR=0x90000000 BESR=0x00000000
PLB4 to OPB1: BEAR=0x0000000efffbfffb BESR0=0x00000000 BESR1=0x00000000
PLB40 Arbiter: BEAR=0x00000000c0002000 ACR=0xde000000 BESR0=0x0f000000
PLB41 Arbiter: BEAR=0xfffffffffffffffa ACR=0xdf000000 BESR0=0x00000000
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: D50FC07C LR: D50FC070 CTR: 00000000
REGS: c02bcf50 TRAP: 0202 Not tainted (2.6.21-rc4)
MSR: 00029000 <EE,ME> CR: 24004022 XER: 00000000
TASK = c05fe490[115] 'insmod' THREAD: cdc6c000
GPR00: D50FC070 CDC6DE80 C05FE490 00000023 0A00C100 00000001 00000000 00000031
GPR08: 00000000 D50FE000 000017E4 C0290000 04004022 1016F458 00000000 00000000
GPR16: 00000000 00000000 00000030 00000030 00000124 D51132BC 00000000 C0035E2C
GPR24: 00000022 D5108000 00000022 D50F7500 CF68A21C D50F0000 CF68A000 C0279CEC
NIP [D50FC07C] initFunction+0x7c/0x128 [bcsr]
LR [D50FC070] initFunction+0x70/0x128 [bcsr]
Call Trace:
[CDC6DE80] [D50FC070] initFunction+0x70/0x128 [bcsr] (unreliable)
[CDC6DEA0] [C003731C] sys_init_module+0xe4/0x1458
[CDC6DF40] [C0001AC4] ret_from_syscall+0x0/0x3c
Instruction dump:
60842000 38600000 48000065 7c601b78 3c60d50f 7c040378 386370e8 901d76a0
4800003d 813d76a0 7c0004ac 80890000 <0c040000> 4c00012c 3c60d50f 38637108
Bus error
----------------------------------------------------------------------
---------------------------------
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.
[-- Attachment #2: Type: text/html, Size: 4726 bytes --]
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Arnd Bergmann @ 2007-11-27 22:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Jan Kratochvil, Roland McGrath
In-Reply-To: <20071126220224.GA5606@host0.dyn.jankratochvil.net>
On Monday 26 November 2007, Jan Kratochvil wrote:
> Hi,
>=20
> this testcase:
> =A0=A0=A0=A0=A0=A0=A0=A0http://people.redhat.com/jkratoch/dabr-lost.c
>=20
> reproduces a PPC DABR kernel bug. =A0The variable `variable' should not g=
et
> modified as the thread modifying it should be caught by its DABR:
>=20
> $ ./dabr-lost
> TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30914: hitting the variable
> TID 30915: hitting the variable
> TID 30916: hitting the variable
> variable found =3D 30916, caught TID =3D 30914
> TID 30916: DABR 0x10012a77
> Variable got modified by a thread which has DABR still set!
>=20
This sounds like a bug recently reported by Uli Weigand. BenH
said he'd take a look, but it probably fell under the table.
The problem found by Uli is that on certain processors (Cell/B.E.
in his case), the DABRX register needs to be set in order for
the DABR to take effect.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
From: Arnd Bergmann @ 2007-11-27 22:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide
In-Reply-To: <20071127153900.GA14183@localhost.localdomain>
On Tuesday 27 November 2007, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: Debugging with gdbserver slow
From: khollan @ 2007-11-27 21:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13865715.post@talk.nabble.com>
Fixed. It turns out it was because I'm using VMWare to run Linux on my
windows computer. I booted up Linux natively and it stepped through code
very fast even in multi threaded apps.
--
View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13980499
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Arnd Bergmann @ 2007-11-27 21:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, linux-ide
In-Reply-To: <20071127212222.GB10829@lixom.net>
On Tuesday 27 November 2007, Olof Johansson wrote:
> On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
> > This driver nicely wraps around pata_platform library functions,
> > and provides OF platform bus bindings to the PATA devices.
>=20
> > +static struct of_device_id pata_of_platform_match[] =3D {
> > +=A0=A0=A0=A0=A0{ .compatible =3D "pata-platform", },
> > +};
>=20
> "pata-platform" really means nothing outside of linux. A more
> generic label would be useful.
Maybe the name of the standards it supports? Could be
"ata-4", "ata-5" and the like, or the exact transfer mode, like
"pata-udma-5", "pata-pio-3", "sata-150", etc.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Olof Johansson @ 2007-11-27 21:22 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127153908.GB14183@localhost.localdomain>
On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
> This driver nicely wraps around pata_platform library functions,
> and provides OF platform bus bindings to the PATA devices.
> +static struct of_device_id pata_of_platform_match[] = {
> + { .compatible = "pata-platform", },
> +};
"pata-platform" really means nothing outside of linux. A more
generic label would be useful.
-Olof
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Kumar Gala @ 2007-11-27 21:18 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C3C79.5060908@ru.mvista.com>
On Nov 27, 2007, at 9:49 AM, Sergei Shtylyov wrote:
> Hello.
>
> Anton Vorontsov wrote:
>
>> This patch adds localbus and pata nodes to use CF IDE interface
>> on MPC8349E-mITX boards.
>
>> Patch also adds code to probe localbus.
>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
>> arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
>> 2 files changed, 33 insertions(+), 1 deletions(-)
>
>> diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/=20=
>> boot/dts/mpc8349emitx.dts
>> index 5072f6d..7a97068 100644
>> --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
>> +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
>> @@ -249,6 +249,21 @@
>> device_type =3D "pci";
>> };
>>
>> + localbus@e0005000 {
>> + #address-cells =3D <2>;
>> + #size-cells =3D <1>;
>> + compatible =3D "fsl,mpc8349emitx-localbus",
>
> Board compatible bus?
>
>> + "fsl,mpc8349e-localbus",
>> + "fsl,pq2pro-localbus";
>> + reg =3D <e0005000 d8>;
>> + ranges =3D <3 0 f0000000 210>;
>>
>> -
>> + pata@3,0 {
>> + compatible =3D "fsl,mpc8349emitx-pata", =
"pata-platform";
>> + reg =3D <3 0 10 3 20c 4>;
>> + ioport-shift =3D <1>;
>
> Bleh... that shift again. And this is surely not a good name for a
> property (where's I/O ports in your case?) -- why not call it "reg-=20
> shift"
> (well, I'd call it "reg-size" or "reg-stride" myself :-)?
I'm coming into this late, but if ioport-shift applies to reg (which I =20=
think it does) it should really be called "reg-shift". The ePAPR is =20
using that property name:
Specifies in bytes how far the discrete device registers are separated =20=
from each other. The
individual register location is calculated by using following formula: =20=
=93registers address=94 <<
reg-shift. If unspecified the default value is 0.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 19:50 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C5CD2.7080208@ru.mvista.com>
On Tue, Nov 27, 2007 at 09:07:14PM +0300, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
> >>>>>2. "ioport" because shift^Wstride ;-) applies only to the io range
> >>>>>(yes, it's obvious, but worth open-wording, no?).
>
> >>>> Contrarywise, to memory range.
>
> >>>By io range I meant "I/O base", in contrast to "CTL base".
>
> >>>There is no need to apply shifting for CTL. That's why ioport-*
> >>>appeared in the first place.
>
> >> So, a matter of wrong terminology then. The thing that you meant by
> >> "I/O" is actually called "command block".
>
> > Yes. And IO is the second name.
>
> I'd say the first place in drivers/ide belongs to the historic name
> "taskfile". The "command block" which is as ATA standard calls it, is hardly used.
>
> > It's used widespread in the drivers/ide/.
>
> Don't remember seeing it.
Oops, thinko -- not drivers/ide/, but include/linux/ide.h.
Grep for io_addr.
> > Now you understand why I'm so reluctant to hanging up different
> > labels on the single thing? ;-)
>
> :-)
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: SPI driver for spi_mpc83xx
From: Ben Warren @ 2007-11-27 19:33 UTC (permalink / raw)
To: fabio777; +Cc: linuxppc-embedded
In-Reply-To: <474C6920.3030109@gmail.com>
Fabio,
Note: I've changed the e-mail subject back to the original. In the
future, please ensure that it remains intact.
fabio777 wrote:
> Thanks Ben,
>
> Here it is
>
> static struct fsl_spi_platform_data k_platform_data = {
> .initial_spmode = 0,
> .bus_num = 1,
Probably should be bus_num = 0
> .max_chipselect = 1,
> /* board specific information */
> .activate_cs = k_cs_activate,
> .deactivate_cs = k_cs_deactivate,
> .sysclk = 266,
> };
>
> static struct spi_board_info spi_board_info[] __initdata = { {
> .modalias = "kplus",
> .platform_data = &k_platform_data,
> .max_speed_hz = 120000,
> .bus_num = 1,
Again, bus_num probably should be 0
> .chip_select = 0,
> },
> };
>
>
> struct platform_device k_plus = {
> .name = "kplus",
name should be "mpc83xx_spi". At initialization, the SPI controller
driver searches the registered platform devices (models of board
hardware) for a match. Without a match, it gives up.
> .id = 1,
> .dev = {
> .platform_data = &k_platform_data,
> },
> };
>
> platform_device_register(&k_plus);
>
Do you add the SPI controller's resources (base address and IRQ?) You'll
need to in order for this to work. On my board, I use
'platform_device_register_simple()', passing the name and the two
resources, then call 'platform_add_data()', passing in the platform data
structure.
> spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
>
Good
> and then calls spi_register_driver(&k_driver);
I don't think this last call is needed.
>
> I can't get the into the *probe functions.
> Thanks
>
regards,
Ben
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 39, Issue 48
From: fabio777 @ 2007-11-27 18:59 UTC (permalink / raw)
To: linuxppc-embedded, bwarren
In-Reply-To: <mailman.3149.1196114204.3099.linuxppc-embedded@ozlabs.org>
Thanks Ben,
Here it is
static struct fsl_spi_platform_data k_platform_data = {
.initial_spmode = 0,
.bus_num = 1,
.max_chipselect = 1,
/* board specific information */
.activate_cs = k_cs_activate,
.deactivate_cs = k_cs_deactivate,
.sysclk = 266,
};
static struct spi_board_info spi_board_info[] __initdata = { {
.modalias = "kplus",
.platform_data = &k_platform_data,
.max_speed_hz = 120000,
.bus_num = 1,
.chip_select = 0,
},
};
struct platform_device k_plus = {
.name = "kplus",
.id = 1,
.dev = {
.platform_data = &k_platform_data,
},
};
platform_device_register(&k_plus);
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
and then calls spi_register_driver(&k_driver);
I can't get the into the *probe functions.
Thanks
>
> fabio777 wrote:
>
>> Has anyone been using this driver ?
>>
>>
> I use it, on ARCH=powerpc, though.
>
>> For legacy reasons I need to keep the ppc=arch however I haven't found
>> out how to get this driver probed at start-up even basing my init on
>> Lublock.
>>
>>
>>
> The driver's expecting a platform device with name "mpc83xx_spi" to be
> registered in board init code. If you post your init code I may be able
> to help.
>
> regards,
> Ben
>
>
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 18:07 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127174826.GA15980@localhost.localdomain>
Anton Vorontsov wrote:
>>>>>2. "ioport" because shift^Wstride ;-) applies only to the io range
>>>>>(yes, it's obvious, but worth open-wording, no?).
>>>> Contrarywise, to memory range.
>>>By io range I meant "I/O base", in contrast to "CTL base".
>>>There is no need to apply shifting for CTL. That's why ioport-*
>>>appeared in the first place.
>> So, a matter of wrong terminology then. The thing that you meant by
>> "I/O" is actually called "command block".
> Yes. And IO is the second name.
I'd say the first place in drivers/ide belongs to the historic name
"taskfile". The "command block" which is as ATA standard calls it, is hardly used.
> It's used widespread in the drivers/ide/.
Don't remember seeing it.
> Now you understand why I'm so reluctant to hanging up different
> labels on the single thing? ;-)
:-)
MBR, Sergei
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Kumar Gala @ 2007-11-27 16:26 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20071127145424.8925.qmail@farnsworth.org>
On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote:
> I wrote:
>> Kumar Gala wrote:
>>>>> Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or
>>>>> when
>>>>> calling 'reboot' in the shell, it just hangs. Using the same dts
>>>>> and
>>>>> resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
>>>>> someone who does should be able to confirm whether the issue
>>>>> exists
>>>>> or
>>>>> not by just attempting to reboot via bash.
>>>
>>> Can someone do a git-bisect and find the patch that breaks things?
>>
>> I'll see if I can reproduce it on my 8548cds. If so, I'll then git-
>> bisect.
>
> I tried this with the current powerpc.git tree on my mpc8548cds, and
> the reboot command works for me. The system rebooted just fine.
I'm wondering if there is an issue rebooting if we are in an oops.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 17:48 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C5513.6010801@ru.mvista.com>
On Tue, Nov 27, 2007 at 08:34:11PM +0300, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
> >>>2. "ioport" because shift^Wstride ;-) applies only to the io range
> >>> (yes, it's obvious, but worth open-wording, no?).
>
> >> Contrarywise, to memory range.
>
> >By io range I meant "I/O base", in contrast to "CTL base".
>
> >There is no need to apply shifting for CTL. That's why ioport-*
> >appeared in the first place.
>
> So, a matter of wrong terminology then. The thing that you meant by
> "I/O" is actually called "command block".
Yes. And IO is the second name. It's used widespread in the
drivers/ide/.
Now you understand why I'm so reluctant to hanging up different
labels on the single thing? ;-)
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 17:34 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127173456.GA15693@localhost.localdomain>
Anton Vorontsov wrote:
>>>2. "ioport" because shift^Wstride ;-) applies only to the io range
>>> (yes, it's obvious, but worth open-wording, no?).
>> Contrarywise, to memory range.
> By io range I meant "I/O base", in contrast to "CTL base".
> There is no need to apply shifting for CTL. That's why ioport-*
> appeared in the first place.
So, a matter of wrong terminology then. The thing that you meant by "I/O"
is actually called "command block".
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 17:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C49D5.2000206@ru.mvista.com>
[ Had cut too much in the previous reply ]
On Tue, Nov 27, 2007 at 07:46:13PM +0300, Sergei Shtylyov wrote:
[...]
> >2. "ioport" because shift^Wstride ;-) applies only to the io range
> > (yes, it's obvious, but worth open-wording, no?).
>
> Contrarywise, to memory range.
By io range I meant "I/O base", in contrast to "CTL base".
There is no need to apply shifting for CTL. That's why ioport-*
appeared in the first place.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 17:25 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127172758.GA15429@localhost.localdomain>
Anton Vorontsov wrote:
>> All I want is that "ioport-*" be renamed.
> I give up.
Don't. :-)
> The final name is..? I can think out wrong one, so you'd better
> convoy me on that way. ;-) reg-shift sounds okay?
Yes.
> Thanks,
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 17:27 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C49D5.2000206@ru.mvista.com>
On Tue, Nov 27, 2007 at 07:46:13PM +0300, Sergei Shtylyov wrote:
[...]
> >>>+ ioport-shift = <1>;
>
> >> Bleh... that shift again. And this is surely not a good name for a
> >>property (where's I/O ports in your case?) -- why not call it "reg-shift"
> >>(well, I'd call it "reg-size" or "reg-stride" myself :-)?
>
> >1. "shift" because pata_platform using that name. I don't see any
> > reason to contrive indirections. ioport-shift is what the whole
> > Linux kernel using nowadays, and ioport-shift dts property
> > anyway Linux-specific.
>
> It's just a bad name. There's not even I/O ports in this case (and
> moreover, the *real* I/O mapped device would always have a shift of 0, I
> bet -- larger strides are for memory mapped devices).
>
> > I'm just following todays' conventions.
>
> > If you feel really bad about that, I think better to fix that in
> > the source of the badness -- pata_platform. It's easy, I can do
>
> I only feel really bad about the "ioport" part, I can live with "shift"
> part. :-)
>
> > that. Would you ack patch that converts whole pata_platform and
> > users? Would Paul ack it?
>
> I don't understand -- why the property name should duplicate
> pata_platform field name? :-O
Because:
> >1. [...] I don't see any reason to contrive indirections.
That is, different names for single thing is worse than single
bogus name.
> Not really -- "size" just seems better, aesthetically. :-)
reg-size will look confusing. Is it ata registers' size? No,
can't be. So, what is it? It's stride/shift because of bus, on
which ata resides.
> >And btw, I can get rid of ioport-shift at all. And do fixups in
> >the pata_of_platform driver via .compatible matching. But I don't
> >want: it feels bad to list every needs-to-fixup board in the common
> >driver. It also feels not so great creating something like
> >pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
>
> I didn't propose neither of that. :-)
Yup, that was "by the way"...
> All I want is that "ioport-*" be renamed.
I give up.
The final name is..? I can think out wrong one, so you'd better
convoy me on that way. ;-) reg-shift sounds okay? Or reg-stride
better? No size, please.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 16:46 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127164101.GA14790@localhost.localdomain>
Anton Vorontsov wrote:
>>>This patch adds localbus and pata nodes to use CF IDE interface
>>>on MPC8349E-mITX boards.
>>>Patch also adds code to probe localbus.
>>>Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>>---
>>>arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
>>>arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
>>>2 files changed, 33 insertions(+), 1 deletions(-)
>>>diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>b/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>index 5072f6d..7a97068 100644
>>>--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>@@ -249,6 +249,21 @@
>>> device_type = "pci";
>>> };
>>>
>>>+ localbus@e0005000 {
>>>+ #address-cells = <2>;
>>>+ #size-cells = <1>;
>>>+ compatible = "fsl,mpc8349emitx-localbus",
>>
>> Board compatible bus?
> This is what Documentation/powerpc/booting-without-of.txt suggests
> for localbuses. I'm following.
Hm...
>>>+ "fsl,mpc8349e-localbus",
>>>+ "fsl,pq2pro-localbus";
>>>+ reg = <e0005000 d8>;
>>>+ ranges = <3 0 f0000000 210>;
>>>
>>>-
>>>+ pata@3,0 {
>>>+ compatible = "fsl,mpc8349emitx-pata",
>>>"pata-platform";
>>>+ reg = <3 0 10 3 20c 4>;
>>>+ ioport-shift = <1>;
>> Bleh... that shift again. And this is surely not a good name for a
>>property (where's I/O ports in your case?) -- why not call it "reg-shift"
>>(well, I'd call it "reg-size" or "reg-stride" myself :-)?
> 1. "shift" because pata_platform using that name. I don't see any
> reason to contrive indirections. ioport-shift is what the whole
> Linux kernel using nowadays, and ioport-shift dts property
> anyway Linux-specific.
It's just a bad name. There's not even I/O ports in this case (and
moreover, the *real* I/O mapped device would always have a shift of 0, I bet
-- larger strides are for memory mapped devices).
> I'm just following todays' conventions.
> If you feel really bad about that, I think better to fix that in
> the source of the badness -- pata_platform. It's easy, I can do
I only feel really bad about the "ioport" part, I can live with "shift"
part. :-)
> that. Would you ack patch that converts whole pata_platform and
> users? Would Paul ack it?
I don't understand -- why the property name should duplicate pata_platform
field name? :-O
> Still, is there any hardware that needs not power of 2 stride?
Not really -- "size" just seems better, aesthetically. :-)
> 2. "ioport" because shift^Wstride ;-) applies only to the io range
> (yes, it's obvious, but worth open-wording, no?).
Contrarywise, to memory range.
> And btw, I can get rid of ioport-shift at all. And do fixups in
> the pata_of_platform driver via .compatible matching. But I don't
> want: it feels bad to list every needs-to-fixup board in the common
> driver. It also feels not so great creating something like
> pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
I didn't propose neither of that. :-)
All I want is that "ioport-*" be renamed.
> Thanks,
MBR, Sergei
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: Scott Wood @ 2007-11-27 17:02 UTC (permalink / raw)
To: vijay baskar; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <474B9CC0.2000803@gdatech.co.in>
vijay baskar wrote:
> The kernel maps the last 1 GB of the virtual address space one to one
> to the physical memory.
No, it maps 768MB of RAM in this manner.
> This is called the kernel space. After the one
> to one mapping is done for the available physical memory, the
> remaining virtual addresses are used for vmalloc and ioremap.
And highmem mappings.
> The kernel also allows hardcoded mapping
> of IO regions into its virtual address space through the
> io_block_mapping interface.
Not in current arch/powerpc kernels.
> Many boards use the block IO mapping to
> map the CCSRBAR/IMMR into the kernel address space, such that the
> physical address and the virutal address is the same. Virtual
> addresses beyond these hardcoded mappings cannot be used by
> vmalloc/ioremap.
And this is why.
> Now as more and more memory is added to the system the addresses
> available for vmalloc and ioremap gets reduced, and memory allocations
> start to fail, due to the lack of availability of virtual addresses.
How so? The size of lowmem is constant once you reach the threshold, as
is the size of the highmem mapping area.
What *does* start to fail eventually, if you have a *lot* of highmem, is
that you run out of lowmem for pagetables and such.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 16:41 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C3C79.5060908@ru.mvista.com>
On Tue, Nov 27, 2007 at 06:49:13PM +0300, Sergei Shtylyov wrote:
> Hello.
Hi Sergei,
> Anton Vorontsov wrote:
>
> >This patch adds localbus and pata nodes to use CF IDE interface
> >on MPC8349E-mITX boards.
>
> >Patch also adds code to probe localbus.
>
> >Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >---
> > arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
> > arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
> > 2 files changed, 33 insertions(+), 1 deletions(-)
>
> >diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
> >b/arch/powerpc/boot/dts/mpc8349emitx.dts
> >index 5072f6d..7a97068 100644
> >--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> >+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> >@@ -249,6 +249,21 @@
> > device_type = "pci";
> > };
> >
> >+ localbus@e0005000 {
> >+ #address-cells = <2>;
> >+ #size-cells = <1>;
> >+ compatible = "fsl,mpc8349emitx-localbus",
>
> Board compatible bus?
This is what Documentation/powerpc/booting-without-of.txt suggests
for localbuses. I'm following.
> >+ "fsl,mpc8349e-localbus",
> >+ "fsl,pq2pro-localbus";
> >+ reg = <e0005000 d8>;
> >+ ranges = <3 0 f0000000 210>;
> >
> >-
> >+ pata@3,0 {
> >+ compatible = "fsl,mpc8349emitx-pata",
> >"pata-platform";
> >+ reg = <3 0 10 3 20c 4>;
> >+ ioport-shift = <1>;
>
> Bleh... that shift again. And this is surely not a good name for a
> property (where's I/O ports in your case?) -- why not call it "reg-shift"
> (well, I'd call it "reg-size" or "reg-stride" myself :-)?
1. "shift" because pata_platform using that name. I don't see any
reason to contrive indirections. ioport-shift is what the whole
Linux kernel using nowadays, and ioport-shift dts property
anyway Linux-specific.
I'm just following todays' conventions.
If you feel really bad about that, I think better to fix that in
the source of the badness -- pata_platform. It's easy, I can do
that. Would you ack patch that converts whole pata_platform and
users? Would Paul ack it?
Still, is there any hardware that needs not power of 2 stride?
2. "ioport" because shift^Wstride ;-) applies only to the io range
(yes, it's obvious, but worth open-wording, no?).
And btw, I can get rid of ioport-shift at all. And do fixups in
the pata_of_platform driver via .compatible matching. But I don't
want: it feels bad to list every needs-to-fixup board in the common
driver. It also feels not so great creating something like
pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox