* Re: Running Linux 2.6.16 and Xorg 7.0 on iMac G5 rev C (iSight)
From: Étienne Bersac @ 2006-03-22 16:05 UTC (permalink / raw)
To: Étienne Bersac; +Cc: debian-powerpc, ubuntu-devel, Linuxppc-dev
In-Reply-To: <500AF45B-8341-44E2-8D83-0B803D7A77EC@laposte.net>
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
Hello,
An howto is available at https://wiki.ubuntu.com/iMacG5revC . Thanks
for contributing.
Étienne.
[-- Attachment #2: Type: text/html, Size: 551 bytes --]
^ permalink raw reply
* Re: software-triggered reset of MPC8541
From: Kumar Gala @ 2006-03-22 15:05 UTC (permalink / raw)
To: Dan Wilson; +Cc: linuxppc-embedded
In-Reply-To: <200603220628100675.0019366F@smtp.dslextreme.com>
On Mar 22, 2006, at 8:28 AM, Dan Wilson wrote:
> My apologies for asking a question in this mailing list that is
> somewhat off-topic, but this is the best list I know of for such a
> question:
>
> We are trying to implement a software function to reset an 8541.
> The ELDK 4.0 kernel includes an abort() function that does this by
> setting the appropriate bits in DBCR0. In our tests, this
> unfailingly reboots the unit. A colleague has put an identical
> function into a non-linux-based application on which he is working,
> and finds that most of the time the unit reboots as expected, but
> sometimes it just hangs.
>
> My question is: does the linux kernel do anything special to
> prepare the processor environment for this reboot prior to calling
> abort()? The only thing I could find was a call to
> local_irq_disable(), which does:
> static inline void local_irq_disable(void)
The problem is there is no good way of actually resetting the full
8541 from software without additional logic on whatever system you
have. The abort() is a poor mans way which is only actually
resetting the E500 core. The rest of the system logic is left in
whatever state it was before.
What you really need is to determine if there is some way to effect
and board logic you may have that handles the HRESET_REQ signal.
> {
> #ifdef CONFIG_BOOKE
> __asm__ __volatile__("wrteei 0": : :"memory");
> #else
> unsigned long msr;
> __asm__ __volatile__("": : :"memory");
> msr = mfmsr();
> SET_MSR_EE(msr & ~MSR_EE);
> #endif
> }
>
> As the 8541 is an E500 core, I believe it is the #ifdef
> CONFIG_BOOKE code that is being executed. The wrteei 0 instruction
> is clear enough. What does the rest of that line do (i.e., the
> repeated colons and the memory command)? I haven't been able to
> find a memory command in the ppc instruction set documents that I
> have?
The "memory" reference is more about GCC's assembler syntax than
anything PPC specific. Take a look at the GCC does for inline
assembly to find out more.
- kumar
^ permalink raw reply
* software-triggered reset of MPC8541
From: Dan Wilson @ 2006-03-22 14:28 UTC (permalink / raw)
To: linuxppc-embedded
My apologies for asking a question in this mailing list that is somewhat=
off-topic, but this is the best list I know of for such a question:
We are trying to implement a software function to reset an 8541. The ELDK=
4.0 kernel includes an abort() function that does this by setting the=
appropriate bits in DBCR0. In our tests, this unfailingly reboots the=
unit. A colleague has put an identical function into a non-linux-based=
application on which he is working, and finds that most of the time the=
unit reboots as expected, but sometimes it just hangs.
My question is: does the linux kernel do anything special to prepare the=
processor environment for this reboot prior to calling abort()? The only=
thing I could find was a call to local_irq_disable(), which does:
static inline void local_irq_disable(void)
{
#ifdef CONFIG_BOOKE
__asm__ __volatile__("wrteei 0": : :"memory");
#else
unsigned long msr;
__asm__ __volatile__("": : :"memory");
msr =3D mfmsr();
SET_MSR_EE(msr & ~MSR_EE);
#endif
}
As the 8541 is an E500 core, I believe it is the #ifdef CONFIG_BOOKE code=
that is being executed. The wrteei 0 instruction is clear enough. What=
does the rest of that line do (i.e., the repeated colons and the memory=
command)? I haven't been able to find a memory command in the ppc=
instruction set documents that I have?
Thanks in advance for any help anyone can give to help us understand this=
code sequence better!
Best regards,
Dan.
^ permalink raw reply
* Re: Running Linux 2.6.16 and Xorg 7.0 on iMac G5 rev C (iSight)
From: Étienne Bersac @ 2006-03-22 14:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev, debian-powerpc, ubuntu-devel
In-Reply-To: <1142992999.12137.69.camel@localhost.localdomain>
Hello,
>> - Get Ben's kernel at http://bersace03.free.fr/pub/iMac%20G5/
>> vmlinux.bz2 (mirror of http://gate.crashing.org/~benh/vmlinux.bz2).
>> bunzip2 it at /.
>
> Don't do that ! :)
I uploaded a .deb for 2.6.16 at http://bersace03.free.fr/pub/Linux/=20
iMac%20G5 . We may extract vmlinux from it and copy it to Macintosh =20
Volume, but that's untested.
I really need feedback on it. I'll write an howto at wiki.ubuntu.com.
=C9tienne.=
^ permalink raw reply
* Re: [PATCH] possible scheduler deadlock in 2.6.16
From: Nick Piggin @ 2006-03-22 11:09 UTC (permalink / raw)
To: Anton Blanchard; +Cc: akpm, linuxppc-dev, mingo, linux-kernel
In-Reply-To: <20060322104143.GC30422@krispykreme>
Anton Blanchard wrote:
> One way to solve this is to always take runqueues in cpu id order. To do
> this we add a cpu variable to the runqueue and check it in the
> double runqueue locking functions.
>
> Thoughts?
>
You're right. I can't think of a better fix, although we've been trying
to avoid adding cpu to the runqueue structure.
I was going to suggest moving more work into wake_sleeping_dependent
instead, but cores with 4 and more threads now make that less desirable
I suppose.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [PATCH] possible scheduler deadlock in 2.6.16
From: Anton Blanchard @ 2006-03-22 12:17 UTC (permalink / raw)
To: Nick Piggin; +Cc: akpm, linuxppc-dev, mingo, linux-kernel
In-Reply-To: <4421307F.8020300@yahoo.com.au>
Hi Nick,
> You're right. I can't think of a better fix, although we've been trying
> to avoid adding cpu to the runqueue structure.
>
> I was going to suggest moving more work into wake_sleeping_dependent
> instead, but cores with 4 and more threads now make that less desirable
> I suppose.
My thoughts too. I wasnt sure if davem is planning to use the sibling
code for his niagara work, but locking us down to 2 siblings sounds like
a bad idea.
Anton
^ permalink raw reply
* [PATCH] possible scheduler deadlock in 2.6.16
From: Anton Blanchard @ 2006-03-22 10:41 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, linuxppc-dev, mingo
Hi,
We have noticed lockups during boot when stress testing kexec on ppc64.
Two cpus would deadlock in scheduler code trying to grab already taken
spinlocks.
The double_rq_lock code uses the address of the runqueue to order the
taking of multiple locks. This address is a per cpu variable:
if (rq1 < rq2) {
spin_lock(&rq1->lock);
spin_lock(&rq2->lock);
} else {
spin_lock(&rq2->lock);
spin_lock(&rq1->lock);
}
On the other hand, the code in wake_sleeping_dependent uses the cpu id
order to grab locks:
for_each_cpu_mask(i, sibling_map)
spin_lock(&cpu_rq(i)->lock);
This means we rely on the address of per cpu data increasing as cpu ids
increase. While this will be true for the generic percpu implementation
it may not be true for arch specific implementations.
One way to solve this is to always take runqueues in cpu id order. To do
this we add a cpu variable to the runqueue and check it in the
double runqueue locking functions.
Thoughts?
Anton
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/kernel/sched.c
===================================================================
--- build.orig/kernel/sched.c 2006-03-22 18:46:53.000000000 +1100
+++ build/kernel/sched.c 2006-03-22 20:44:20.000000000 +1100
@@ -237,6 +237,7 @@ struct runqueue {
task_t *migration_thread;
struct list_head migration_queue;
+ int cpu;
#endif
#ifdef CONFIG_SCHEDSTATS
@@ -1660,6 +1661,9 @@ unsigned long nr_iowait(void)
/*
* double_rq_lock - safely lock two runqueues
*
+ * We must take them in cpu order to match code in
+ * dependent_sleeper and wake_dependent_sleeper.
+ *
* Note this does not disable interrupts like task_rq_lock,
* you need to do so manually before calling.
*/
@@ -1671,7 +1675,7 @@ static void double_rq_lock(runqueue_t *r
spin_lock(&rq1->lock);
__acquire(rq2->lock); /* Fake it out ;) */
} else {
- if (rq1 < rq2) {
+ if (rq1->cpu < rq2->cpu) {
spin_lock(&rq1->lock);
spin_lock(&rq2->lock);
} else {
@@ -1707,7 +1711,7 @@ static void double_lock_balance(runqueue
__acquires(this_rq->lock)
{
if (unlikely(!spin_trylock(&busiest->lock))) {
- if (busiest < this_rq) {
+ if (busiest->cpu < this_rq->cpu) {
spin_unlock(&this_rq->lock);
spin_lock(&busiest->lock);
spin_lock(&this_rq->lock);
@@ -6035,6 +6039,7 @@ void __init sched_init(void)
rq->push_cpu = 0;
rq->migration_thread = NULL;
INIT_LIST_HEAD(&rq->migration_queue);
+ rq->cpu = i;
#endif
atomic_set(&rq->nr_iowait, 0);
^ permalink raw reply
* new sound driver
From: Johannes Berg @ 2006-03-22 9:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alastair Poole
[-- Attachment #1: Type: text/plain, Size: 4478 bytes --]
Hi,
After considering the code a while I decided that snd-powermac needs to
be rewritten. Ok, kidding, I didn't need to look at the source for
long :)
So I started to rewrite snd-powermac as snd-aoa, which I currently keep
in a git tree at http://johannes.sipsolutions.net/snd-aoa.git/
I will need a bit of help, so this email is intended to solicit that,
and to get some input on what everyone else thinks about what I've been
doing in that code.
Let me start with a brief layout. To those I've talked about this
before: please read again -- I significantly changed what I'm doing.
Since Ben says that he wants to be able to handle really old stuff with
the new driver too, I first created a virtual 'soundbus'. This is in the
module 'soundbus', and doesn't yet have any functionality in itself but
providing the driver model bus object.
I then created an i2sbus module that grabs all i2s devices from the
macio bus, enumerates their children (i2s-a, i2s-b etc) and adds them to
the soundbus.
Obviously, we'll need to add more bus backends there.
Now enter snd-aoa: snd-aoa has a rather generic architecture where the
core just initialises plugin code for different ways to find sound codec
chips. Currently, only one way is implemented -- that is going off the
layout-id property. This part (snd-aoa-fabric-layout.c) is a soundbus
driver and attaches to all soundbus nodes that have a 'sound' child with
a 'layout-id' property that it knows about. The list is encoded in
snd-aoa-layouts.c.
Plan is to make the fabrics and the codecs into modules too, but this
isn't done at the moment. Shouldn't be too hard, and should probably be
done before writing any more fabrics or codecs.
Anyway, back to what happens. Now the fabric module detects a layout-id
that it can handle, so it then goes to instantiate the codecs. Right now
I only have an onyx codec there. It tries to attach to the i2c control
interface (using two methods, but for that refer to the code). Then the
codec creates the alsa mixer devices that it can handle, using some alsa
helper code (snd-aoa-alsa) that manages the alsa card object.
That's about it. It can mute/unmute and control the left/right volume,
so it might work if you use both this and snd-powermac...
I had planned to actually get sound output working last night, but that
didn't turn out since I ended up rewriting all the lower levels.
So let me just say what the immediate plan is:
Firstly, the soundbus objects need to be able to handle data
transmission. What I'm not too sure about is how the API should look
like. I'm thinking that since all objects there are actually sound
objects (well, there's the modem too, but it can get an alsa interface
too), the soundbus objects actually get to create the alsa pcm
interfaces, somehow helped by the codecs to select the valid rates and
formats. Or the codecs create the alsa pcm streams, but refer to
soundbus object functions for handling the actual data transfer. I'd
like to push as much of the interface into the soundbus object as
possible. At this point also the question of how to program the dbdma
engine best comes up. I really don't know, because I don't quite
understand the alsa pcm api.
In any case, I'm thinking of putting dbdma register stuff into the
soundbus module and adding dbdma data to struct soundbus_dev.
Actually, this isn't quite possible. On the newer machines where you
have two codecs on the same i2s bus, we need to have the layout fabric
create the one pcm stream and have it ask the codecs what it should
advertise. Then it needs to advertise the lowest common denominator of
the multiple codecs... (Or can alsa handle pcms that change their
supported rates/formats?) Then it refers to the soundbus functions for
actual data transmission.
Another thing that needs to be done is teach the layout-id fabric module
how to handle all the dozens of platform functions and publish those to
alsa that make sense to be set by the user (like line out select etc.).
Then also register the interrupt ones and handle them appropriately. The
codecs will need to be notified on changes/interrupts though, since in
some cases things need to be switched around there too. This is just a
matter of inventing the right way to find all of the functions...
Whee. I was going to write more but for one it is already long enough,
and I also forgot what I wanted to write :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* please pull powerpc.git
From: Paul Mackerras @ 2006-03-22 5:28 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
to get the PowerPC updates that have been queued up to go into
2.6.17.
Thanks,
Paul.
Adrian Cox:
ppc: Fix platform_notify functions marked __init
Andy Fleming:
powerpc: Add PCI support for 8540 ADS to powerpc tree
Becky Bruce:
powerpc: Updated Initial MPC8540 ADS port with OF Flat Dev
powerpc: Fix Kernel FP unavail exception for BookE
powerpc: mpc85xx_ads.c include file cleanup
powerpc: rename mpc85xx.c to misc.c
powerpc: lindent 85xx platform code
powerpc/ppc: Add missing isyncs in head_fsl_booke.S
Christoph Hellwig:
powerpc: add for_each_node_by_foo helpers
spidernet: select FW_LOADER
David Gibson:
powerpc: Fixup for STRICT_MM_TYPECHECKS
powerpc: Better pmd_bad() and pud_bad() checks
Domen Puncer:
powerpc: Remove arch/ppc/syslib/ppc4xx_pm.c
Eric Sesterhenn:
kzalloc() conversion in arch/ppc
Geoff Levand:
powerpc: Add missing vmlinux.bin target
Grant C. Likely:
powerpc: Move xparameters.h into xilinx virtex device specific path
powerpc: Make Virtex-II Pro support generic for all Virtex devices
powerpc: Migrate Xilinx Vertex support from the OCP bus to the platfom bus.
powerpc: Migrate ML300 reference design to the platform bus
powerpc: Add ML300 defconfig
powerpc: Add Virtex-4 FX to cpu table
powerpc: Add xparameters file for Xilinx ML403 reference design
powerpc: Add support for Xilinx ML403 reference design
powerpc: Add ML403 defconfig
Grant Likely:
Fix compile error for ML300/403
Horst Kronstorfer:
ppc32: Fix BCSR_SIZE for MPC834x SYS
Jon Mason:
powerpc: trivial: modify comments to refer to new location of files
Kumar Gala:
powerpc: Add CONFIG_DEFAULT_UIMAGE to build a uImage by default for a board
powerpc: cleaned up fsl_soc.c
powerpc: Add platform support for MPC834x USB controllers
powerpc: Cleanup MPC83xx platform support
powerpc: Lindent platforms/83xx
powerpc: Fix mpc83xx restart bug
Marcelo Tosatti:
powerpc: generalize PPC44x_PIN_SIZE
Michael Ellerman:
powerpc: Always panic if lmb_alloc() fails
powerpc: Move LMB_ALLOC_ANYWHERE out of lmb.h
powerpc: Put parameter names in lmb.h prototypes
powerpc: Clean up pSeries firmware feature initialisation
powerpc: Move pSeries firmware feature setup into platforms/pseries
powerpc: Fix bug in bug fix for bug in lmb_alloc()
powerpc: Unconfuse htab_bolt_mapping() callers
powerpc: Remove unused iommu_off logic from pSeries_init_early()
powerpc: trivial: Cleanup whitespace in cputable.h
powerpc: Replace platform_is_lpar() with a firmware feature
powerpc: iseries: mf related cleanups
powerpc: iseries: Remove pointless iSeries_(restart|power_off|halt)
powerpc: iseries: Make more stuff static in platforms/iseries/mf.c
powerpc: Add strne2a() to convert a string from EBCDIC to ASCII
powerpc: iseries: Add /system-id, /model and /compatible
powerpc: iseries: Add bootargs to /chosen
powerpc: Remove calculation of io hole
Nathan Lynch:
powerpc numa: fix boot_cpuid always assigned to node 0
powerpc numa: Minor debugging code changes
powerpc numa: Minor cpu hotplug-related cleanups
powerpc numa: Get rid of "numa domain" terminology
powerpc numa: Consolidate handling of Power4 special case
powerpc numa: Support sparse online node map
powerpc numa: Consolidate assignment of cpus to nodes
Nick Piggin:
powerpc: newline for ISYNC_ON_SMP
powerpc: native atomic_add_unless
Olaf Hering:
powerpc: cleanup pmac_newworld variable usage
powerpc: remove check for ELF offset in powerpc bootimage
powerpc: add a raw dump command to xmon
Paul Mackerras:
powerpc: Implement accurate task and CPU time accounting
powerpc: Export variables used in conversions to/from cputime_t
Stephen Rothwell:
powerpc: update mailing list addresses
Vitaly Bordug:
ppc32 8xx: Added setbitsXX/clrbitsXX macro for read-modify-write operations
PPC32 8xx: support for the physmapped flash on m8xx
ppc32: MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet
ppc32: Make platform devices being able to assign functions
Documentation/powerpc/eeh-pci-error-recovery.txt | 15
Documentation/powerpc/hvcs.txt | 4
MAINTAINERS | 4
arch/powerpc/Kconfig | 38 +
arch/powerpc/Makefile | 2
arch/powerpc/boot/install.sh | 2
arch/powerpc/boot/main.c | 4
arch/powerpc/configs/mpc8540_ads_defconfig | 721 +++++++++++++++++++
arch/powerpc/kernel/asm-offsets.c | 3
arch/powerpc/kernel/cputable.c | 12
arch/powerpc/kernel/entry_64.S | 11
arch/powerpc/kernel/firmware.c | 25 -
arch/powerpc/kernel/head_44x.S | 2
arch/powerpc/kernel/head_64.S | 11
arch/powerpc/kernel/head_8xx.S | 2
arch/powerpc/kernel/head_booke.h | 363 ++++++++++
arch/powerpc/kernel/head_fsl_booke.S | 6
arch/powerpc/kernel/iomap.c | 2
arch/powerpc/kernel/iommu.c | 1
arch/powerpc/kernel/irq.c | 32 +
arch/powerpc/kernel/kprobes.c | 1
arch/powerpc/kernel/pci_iommu.c | 1
arch/powerpc/kernel/ppc_ksyms.c | 1
arch/powerpc/kernel/process.c | 9
arch/powerpc/kernel/prom.c | 4
arch/powerpc/kernel/ptrace-common.h | 2
arch/powerpc/kernel/rtas-proc.c | 1
arch/powerpc/kernel/rtas_pci.c | 2
arch/powerpc/kernel/setup_64.c | 2
arch/powerpc/kernel/signal_64.c | 2
arch/powerpc/kernel/smp.c | 4
arch/powerpc/kernel/time.c | 241 ++++++-
arch/powerpc/kernel/vdso.c | 2
arch/powerpc/lib/copypage_64.S | 2
arch/powerpc/lib/copyuser_64.S | 2
arch/powerpc/lib/e2a.c | 14
arch/powerpc/lib/memcpy_64.S | 2
arch/powerpc/lib/rheap.c | 2
arch/powerpc/mm/fault.c | 2
arch/powerpc/mm/hash_low_32.S | 2
arch/powerpc/mm/hash_utils_64.c | 32 -
arch/powerpc/mm/init_64.c | 48 -
arch/powerpc/mm/lmb.c | 16
arch/powerpc/mm/mem.c | 1
arch/powerpc/mm/mmap.c | 2
arch/powerpc/mm/numa.c | 160 ++--
arch/powerpc/mm/slb_low.S | 2
arch/powerpc/mm/stab.c | 4
arch/powerpc/mm/tlb_64.c | 2
arch/powerpc/oprofile/op_model_power4.c | 3
arch/powerpc/platforms/83xx/Makefile | 4
arch/powerpc/platforms/83xx/misc.c | 55 +
arch/powerpc/platforms/83xx/mpc834x_sys.c | 89 --
arch/powerpc/platforms/83xx/mpc834x_sys.h | 2
arch/powerpc/platforms/83xx/mpc83xx.h | 5
arch/powerpc/platforms/83xx/pci.c | 21 -
arch/powerpc/platforms/85xx/Kconfig | 74 --
arch/powerpc/platforms/85xx/Makefile | 6
arch/powerpc/platforms/85xx/misc.c | 31 +
arch/powerpc/platforms/85xx/mpc8540_ads.h | 36 +
arch/powerpc/platforms/85xx/mpc85xx.h | 18
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 244 +++++++
arch/powerpc/platforms/85xx/pci.c | 96 +++
arch/powerpc/platforms/Makefile | 2
arch/powerpc/platforms/chrp/pegasos_eth.c | 2
arch/powerpc/platforms/chrp/setup.c | 2
arch/powerpc/platforms/chrp/time.c | 2
arch/powerpc/platforms/iseries/mf.c | 112 ++-
arch/powerpc/platforms/iseries/setup.c | 72 +-
arch/powerpc/platforms/maple/time.c | 2
arch/powerpc/platforms/powermac/cpufreq_32.c | 2
arch/powerpc/platforms/powermac/feature.c | 2
arch/powerpc/platforms/powermac/nvram.c | 2
arch/powerpc/platforms/powermac/setup.c | 8
arch/powerpc/platforms/pseries/Makefile | 3
arch/powerpc/platforms/pseries/firmware.c | 103 +++
arch/powerpc/platforms/pseries/firmware.h | 17
arch/powerpc/platforms/pseries/hvCall.S | 2
arch/powerpc/platforms/pseries/iommu.c | 4
arch/powerpc/platforms/pseries/pci.c | 2
arch/powerpc/platforms/pseries/setup.c | 67 --
arch/powerpc/platforms/pseries/smp.c | 2
arch/powerpc/platforms/pseries/xics.c | 3
arch/powerpc/sysdev/dart_iommu.c | 2
arch/powerpc/sysdev/dcr.S | 2
arch/powerpc/sysdev/fsl_soc.c | 292 ++++++--
arch/powerpc/sysdev/ipic.h | 2
arch/powerpc/xmon/xmon.c | 30 +
arch/ppc/4xx_io/serial_sicc.c | 5
arch/ppc/8xx_io/commproc.c | 6
arch/ppc/Kconfig | 47 +
arch/ppc/Kconfig.debug | 2
arch/ppc/amiga/amiints.c | 2
arch/ppc/amiga/bootinfo.c | 2
arch/ppc/amiga/cia.c | 2
arch/ppc/amiga/config.c | 2
arch/ppc/amiga/ints.c | 2
arch/ppc/boot/Makefile | 3
arch/ppc/boot/common/Makefile | 3
arch/ppc/boot/common/bootinfo.c | 2
arch/ppc/boot/common/misc-common.c | 2
arch/ppc/boot/common/ns16550.c | 3
arch/ppc/boot/common/serial_stub.c | 2
arch/ppc/boot/common/util.S | 2
arch/ppc/boot/include/mpc10x.h | 2
arch/ppc/boot/simple/Makefile | 1
arch/ppc/boot/simple/cpc700_memory.c | 2
arch/ppc/boot/simple/embed_config.c | 7
arch/ppc/boot/simple/head.S | 9
arch/ppc/boot/simple/misc-chestnut.c | 2
arch/ppc/boot/simple/misc-cpci690.c | 2
arch/ppc/boot/simple/misc-ev64260.c | 2
arch/ppc/boot/simple/misc-ev64360.c | 1
arch/ppc/boot/simple/misc-katana.c | 2
arch/ppc/boot/simple/misc-mv64x60.c | 2
arch/ppc/boot/simple/misc-prep.c | 2
arch/ppc/boot/simple/misc-radstone_ppc7d.c | 2
arch/ppc/boot/simple/misc-spruce.c | 2
arch/ppc/boot/simple/misc.c | 2
arch/ppc/boot/simple/mpc10x_memory.c | 2
arch/ppc/boot/simple/mpc52xx_tty.c | 2
arch/ppc/boot/simple/mv64x60_tty.c | 2
arch/ppc/boot/simple/openbios.c | 2
arch/ppc/boot/simple/relocate.S | 2
arch/ppc/boot/utils/mkbugboot.c | 2
arch/ppc/configs/ml300_defconfig | 739 ++++++++++++++++++++
arch/ppc/configs/ml403_defconfig | 740 ++++++++++++++++++++
arch/ppc/kernel/head_44x.S | 2
arch/ppc/kernel/head_8xx.S | 2
arch/ppc/kernel/head_fsl_booke.S | 6
arch/ppc/kernel/smp-tbsync.c | 3
arch/ppc/kernel/traps.c | 2
arch/ppc/lib/rheap.c | 2
arch/ppc/math-emu/math.c | 2
arch/ppc/mm/44x_mmu.c | 4
arch/ppc/mm/fault.c | 2
arch/ppc/mm/hashtable.S | 2
arch/ppc/platforms/4xx/Kconfig | 23 -
arch/ppc/platforms/4xx/Makefile | 4
arch/ppc/platforms/4xx/bamboo.c | 2
arch/ppc/platforms/4xx/bamboo.h | 2
arch/ppc/platforms/4xx/bubinga.h | 2
arch/ppc/platforms/4xx/cpci405.c | 2
arch/ppc/platforms/4xx/ebony.c | 2
arch/ppc/platforms/4xx/ebony.h | 2
arch/ppc/platforms/4xx/ep405.c | 2
arch/ppc/platforms/4xx/ep405.h | 2
arch/ppc/platforms/4xx/ibm405ep.c | 2
arch/ppc/platforms/4xx/ibm405ep.h | 2
arch/ppc/platforms/4xx/ibm405gp.h | 2
arch/ppc/platforms/4xx/ibm405gpr.c | 2
arch/ppc/platforms/4xx/ibm405gpr.h | 2
arch/ppc/platforms/4xx/ibm440ep.c | 2
arch/ppc/platforms/4xx/ibm440ep.h | 2
arch/ppc/platforms/4xx/ibm440gp.c | 2
arch/ppc/platforms/4xx/ibm440gp.h | 2
arch/ppc/platforms/4xx/ibm440gx.c | 2
arch/ppc/platforms/4xx/ibm440gx.h | 2
arch/ppc/platforms/4xx/ibm440sp.c | 2
arch/ppc/platforms/4xx/ibm440sp.h | 2
arch/ppc/platforms/4xx/ibmnp405h.c | 2
arch/ppc/platforms/4xx/ibmnp405h.h | 2
arch/ppc/platforms/4xx/ibmstb4.c | 2
arch/ppc/platforms/4xx/ibmstb4.h | 2
arch/ppc/platforms/4xx/ibmstbx25.c | 2
arch/ppc/platforms/4xx/ibmstbx25.h | 2
arch/ppc/platforms/4xx/luan.c | 2
arch/ppc/platforms/4xx/luan.h | 2
arch/ppc/platforms/4xx/ocotea.c | 2
arch/ppc/platforms/4xx/ocotea.h | 2
arch/ppc/platforms/4xx/ppc440spe.c | 2
arch/ppc/platforms/4xx/ppc440spe.h | 2
arch/ppc/platforms/4xx/redwood5.c | 2
arch/ppc/platforms/4xx/redwood5.h | 2
arch/ppc/platforms/4xx/redwood6.c | 2
arch/ppc/platforms/4xx/redwood6.h | 2
arch/ppc/platforms/4xx/sycamore.c | 2
arch/ppc/platforms/4xx/sycamore.h | 2
arch/ppc/platforms/4xx/virtex-ii_pro.c | 60 --
arch/ppc/platforms/4xx/virtex-ii_pro.h | 99 ---
arch/ppc/platforms/4xx/virtex.c | 56 ++
arch/ppc/platforms/4xx/virtex.h | 35 +
arch/ppc/platforms/4xx/walnut.c | 2
arch/ppc/platforms/4xx/walnut.h | 2
arch/ppc/platforms/4xx/xilinx_ml300.c | 76 +-
arch/ppc/platforms/4xx/xilinx_ml300.h | 6
arch/ppc/platforms/4xx/xilinx_ml403.c | 177 +++++
arch/ppc/platforms/4xx/xilinx_ml403.h | 49 +
arch/ppc/platforms/4xx/xparameters/xparameters.h | 37 +
.../platforms/4xx/xparameters/xparameters_ml403.h | 243 ++++++++
arch/ppc/platforms/4xx/yucca.c | 2
arch/ppc/platforms/4xx/yucca.h | 2
arch/ppc/platforms/83xx/mpc834x_sys.c | 2
arch/ppc/platforms/83xx/mpc834x_sys.h | 4
arch/ppc/platforms/85xx/mpc8540_ads.c | 2
arch/ppc/platforms/85xx/mpc8540_ads.h | 2
arch/ppc/platforms/85xx/mpc8555_cds.h | 2
arch/ppc/platforms/85xx/mpc8560_ads.c | 2
arch/ppc/platforms/85xx/mpc8560_ads.h | 2
arch/ppc/platforms/85xx/mpc85xx_ads_common.c | 2
arch/ppc/platforms/85xx/mpc85xx_ads_common.h | 2
arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 2
arch/ppc/platforms/85xx/mpc85xx_cds_common.h | 2
arch/ppc/platforms/85xx/sbc8560.c | 2
arch/ppc/platforms/85xx/sbc8560.h | 2
arch/ppc/platforms/85xx/sbc85xx.c | 2
arch/ppc/platforms/85xx/sbc85xx.h | 2
arch/ppc/platforms/85xx/stx_gp3.c | 2
arch/ppc/platforms/85xx/stx_gp3.h | 2
arch/ppc/platforms/85xx/tqm85xx.c | 2
arch/ppc/platforms/85xx/tqm85xx.h | 2
arch/ppc/platforms/Makefile | 3
arch/ppc/platforms/apus_setup.c | 2
arch/ppc/platforms/chestnut.c | 2
arch/ppc/platforms/chestnut.h | 2
arch/ppc/platforms/chrp_pegasos_eth.c | 2
arch/ppc/platforms/chrp_setup.c | 2
arch/ppc/platforms/chrp_time.c | 2
arch/ppc/platforms/cpci690.c | 4
arch/ppc/platforms/cpci690.h | 2
arch/ppc/platforms/ev64260.c | 4
arch/ppc/platforms/ev64260.h | 2
arch/ppc/platforms/ev64360.c | 4
arch/ppc/platforms/ev64360.h | 2
arch/ppc/platforms/fads.h | 2
arch/ppc/platforms/gemini.h | 3
arch/ppc/platforms/gemini_prom.S | 2
arch/ppc/platforms/gemini_setup.c | 2
arch/ppc/platforms/hdpu.c | 5
arch/ppc/platforms/hdpu.h | 2
arch/ppc/platforms/katana.c | 7
arch/ppc/platforms/katana.h | 2
arch/ppc/platforms/lite5200.c | 2
arch/ppc/platforms/lite5200.h | 2
arch/ppc/platforms/lopec.c | 2
arch/ppc/platforms/mpc8272ads_setup.c | 236 ++++++
arch/ppc/platforms/mpc866ads_setup.c | 273 +++++++
arch/ppc/platforms/mpc885ads_setup.c | 389 +++++++++++
arch/ppc/platforms/mvme5100.c | 2
arch/ppc/platforms/pal4.h | 2
arch/ppc/platforms/pal4_pci.c | 2
arch/ppc/platforms/pal4_serial.h | 2
arch/ppc/platforms/pal4_setup.c | 2
arch/ppc/platforms/powerpmc250.c | 2
arch/ppc/platforms/pplus.c | 2
arch/ppc/platforms/pplus.h | 2
arch/ppc/platforms/pq2ads.c | 2
arch/ppc/platforms/pq2ads.h | 4
arch/ppc/platforms/pq2ads_pd.h | 114 +++
arch/ppc/platforms/prep_setup.c | 2
arch/ppc/platforms/prpmc750.c | 2
arch/ppc/platforms/prpmc800.c | 2
arch/ppc/platforms/radstone_ppc7d.c | 7
arch/ppc/platforms/radstone_ppc7d.h | 2
arch/ppc/platforms/sandpoint.c | 2
arch/ppc/platforms/sandpoint.h | 2
arch/ppc/platforms/sbc82xx.c | 2
arch/ppc/platforms/spruce.c | 2
arch/ppc/platforms/tqm8260_setup.c | 2
arch/ppc/syslib/Makefile | 4
arch/ppc/syslib/cpc700.h | 2
arch/ppc/syslib/cpc700_pic.c | 2
arch/ppc/syslib/cpc710.h | 2
arch/ppc/syslib/gen550.h | 2
arch/ppc/syslib/gen550_dbg.c | 2
arch/ppc/syslib/gen550_kgdb.c | 2
arch/ppc/syslib/gt64260_pic.c | 2
arch/ppc/syslib/harrier.c | 2
arch/ppc/syslib/hawk_common.c | 2
arch/ppc/syslib/ibm440gp_common.c | 2
arch/ppc/syslib/ibm440gp_common.h | 2
arch/ppc/syslib/ibm440gx_common.c | 2
arch/ppc/syslib/ibm440gx_common.h | 2
arch/ppc/syslib/ibm440sp_common.c | 2
arch/ppc/syslib/ibm440sp_common.h | 2
arch/ppc/syslib/ibm44x_common.c | 2
arch/ppc/syslib/ibm44x_common.h | 2
arch/ppc/syslib/m8260_pci_erratum9.c | 2
arch/ppc/syslib/m8260_setup.c | 2
arch/ppc/syslib/m8xx_setup.c | 65 ++
arch/ppc/syslib/m8xx_wdt.c | 3
arch/ppc/syslib/mpc10x_common.c | 2
arch/ppc/syslib/mpc52xx_devices.c | 2
arch/ppc/syslib/mpc52xx_pci.c | 2
arch/ppc/syslib/mpc52xx_pci.h | 2
arch/ppc/syslib/mpc52xx_pic.c | 2
arch/ppc/syslib/mpc52xx_setup.c | 2
arch/ppc/syslib/mpc52xx_sys.c | 2
arch/ppc/syslib/mpc83xx_devices.c | 2
arch/ppc/syslib/mpc83xx_sys.c | 2
arch/ppc/syslib/mpc85xx_devices.c | 2
arch/ppc/syslib/mpc85xx_sys.c | 2
arch/ppc/syslib/mpc8xx_devices.c | 2
arch/ppc/syslib/mpc8xx_sys.c | 2
arch/ppc/syslib/mv64360_pic.c | 2
arch/ppc/syslib/mv64x60.c | 2
arch/ppc/syslib/mv64x60_dbg.c | 2
arch/ppc/syslib/mv64x60_win.c | 2
arch/ppc/syslib/ocp.c | 3
arch/ppc/syslib/open_pic.c | 2
arch/ppc/syslib/open_pic2.c | 2
arch/ppc/syslib/open_pic_defs.h | 2
arch/ppc/syslib/pci_auto.c | 2
arch/ppc/syslib/ppc4xx_dma.c | 2
arch/ppc/syslib/ppc4xx_pic.c | 2
arch/ppc/syslib/ppc4xx_pm.c | 47 -
arch/ppc/syslib/ppc4xx_sgdma.c | 2
arch/ppc/syslib/ppc83xx_setup.c | 2
arch/ppc/syslib/ppc83xx_setup.h | 2
arch/ppc/syslib/ppc85xx_common.c | 2
arch/ppc/syslib/ppc85xx_common.h | 2
arch/ppc/syslib/ppc85xx_setup.c | 2
arch/ppc/syslib/ppc85xx_setup.h | 2
arch/ppc/syslib/ppc_sys.c | 179 +++++
arch/ppc/syslib/pq2_devices.c | 2
arch/ppc/syslib/pq2_sys.c | 2
arch/ppc/syslib/prep_nvram.c | 2
arch/ppc/syslib/todc_time.c | 2
arch/ppc/syslib/xilinx_pic.c | 4
drivers/char/hvcs.c | 9
drivers/net/Kconfig | 1
include/asm-powerpc/atomic.h | 38 +
include/asm-powerpc/cputable.h | 38 +
include/asm-powerpc/cputime.h | 202 +++++
include/asm-powerpc/firmware.h | 16
include/asm-powerpc/irq.h | 6
include/asm-powerpc/iseries/mf.h | 7
include/asm-powerpc/lmb.h | 19 -
include/asm-powerpc/mmu.h | 1
include/asm-powerpc/paca.h | 7
include/asm-powerpc/pgtable-4k.h | 11
include/asm-powerpc/pgtable.h | 9
include/asm-powerpc/ppc_asm.h | 42 +
include/asm-powerpc/processor.h | 1
include/asm-powerpc/prom.h | 6
include/asm-powerpc/rwsem.h | 2
include/asm-powerpc/synch.h | 2
include/asm-powerpc/system.h | 6
include/asm-powerpc/time.h | 15
include/asm-ppc/harrier.h | 2
include/asm-ppc/ibm44x.h | 2
include/asm-ppc/ibm4xx.h | 4
include/asm-ppc/io.h | 7
include/asm-ppc/mpc10x.h | 3
include/asm-ppc/mpc52xx.h | 1
include/asm-ppc/mpc8260.h | 1
include/asm-ppc/mpc83xx.h | 1
include/asm-ppc/mpc85xx.h | 1
include/asm-ppc/mpc8xx.h | 3
include/asm-ppc/pgtable.h | 6
include/asm-ppc/ppc_sys.h | 34 +
include/asm-ppc/time.h | 5
include/asm-ppc/todc.h | 2
include/asm-ppc/xparameters.h | 18
kernel/auditsc.c | 2
lib/extable.c | 1
356 files changed, 6497 insertions(+), 1452 deletions(-)
create mode 100644 arch/powerpc/configs/mpc8540_ads_defconfig
create mode 100644 arch/powerpc/kernel/head_booke.h
create mode 100644 arch/powerpc/platforms/83xx/misc.c
create mode 100644 arch/powerpc/platforms/85xx/misc.c
create mode 100644 arch/powerpc/platforms/85xx/mpc8540_ads.h
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx.h
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_ads.c
create mode 100644 arch/powerpc/platforms/85xx/pci.c
create mode 100644 arch/powerpc/platforms/pseries/firmware.c
create mode 100644 arch/powerpc/platforms/pseries/firmware.h
create mode 100644 arch/ppc/configs/ml300_defconfig
create mode 100644 arch/ppc/configs/ml403_defconfig
delete mode 100644 arch/ppc/platforms/4xx/virtex-ii_pro.c
delete mode 100644 arch/ppc/platforms/4xx/virtex-ii_pro.h
create mode 100644 arch/ppc/platforms/4xx/virtex.c
create mode 100644 arch/ppc/platforms/4xx/virtex.h
create mode 100644 arch/ppc/platforms/4xx/xilinx_ml403.c
create mode 100644 arch/ppc/platforms/4xx/xilinx_ml403.h
create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters.h
create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_ml403.h
create mode 100644 arch/ppc/platforms/mpc8272ads_setup.c
create mode 100644 arch/ppc/platforms/mpc866ads_setup.c
create mode 100644 arch/ppc/platforms/mpc885ads_setup.c
create mode 100644 arch/ppc/platforms/pq2ads_pd.h
delete mode 100644 arch/ppc/syslib/ppc4xx_pm.c
delete mode 100644 include/asm-ppc/xparameters.h
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL SEC node to documentation
From: Paul Mackerras @ 2006-03-22 4:09 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060321191012.2ef20179.kim.phillips@freescale.com>
Kim Phillips writes:
> ok, here's the replacement replacement patch with the above fixes:
Unfortunately your mailer wrecked the whitespace and it doesn't
apply. Please resend with a better mailer.
Thanks,
Paul.
^ permalink raw reply
* Re: Running Linux 2.6.16 and Xorg 7.0 on iMac G5 rev C (iSight)
From: Benjamin Herrenschmidt @ 2006-03-22 2:03 UTC (permalink / raw)
To: Étienne Bersac; +Cc: Linuxppc-dev, debian-powerpc, ubuntu-devel
In-Reply-To: <82FEFC77-5EDB-4349-B935-AD422913F3F7@laposte.net>
> - Get Ben's kernel at http://bersace03.free.fr/pub/iMac%20G5/
> vmlinux.bz2 (mirror of http://gate.crashing.org/~benh/vmlinux.bz2).
> bunzip2 it at /.
Don't do that ! :)
There is no such thing as benh's kernels :) that's long gone. In fact, I
just removed the above one from the site... it was just a build to help
you. 2.6.16 should work on this machine, if you need a pre-build version
of it, try to get somebody on this list or post yourself one somewhere
but don't spread the idea that there is still such a thing as "benh's
kernel" :)
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL SEC node to documentation
From: Kim Phillips @ 2006-03-22 1:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3C6218C3-3FC0-437E-A798-3AD6FEB69713@kernel.crashing.org>
On Tue, 21 Mar 2006 12:21:47 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
> Drop the part about Most modern... in five years when someone reads
> this it will not be modern anymore.
>
[snip]
>
> ditto about modern.
>
[snip]
>
> Would this be a bit more clear, if you explicitly stated that the
> DESC_TYPE value directly corresponds to the bit encoding, like you
> did for EU_SEL0.
>
[snip]
ok, here's the replacement replacement patch with the above fixes:
Documentation: Added FSL SOC SEC node definition
Updated the documentation to include the definition of the SEC device
node format for Freescale SOC devices.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
commit e1e1b8f7d958d7f25a0085ec529a3ebbd6dc1fa5
tree 2e2b12fe07b6d367da4c5609971178838c9321a2
parent 6b0efd3e3b07afc9fc7222066b0b37ecd1d31e44
author Kim Phillips <kim.phillips@freescale.com> Tue, 21 Mar 2006 16:43:16 -0600
committer Kim Phillips <kim.phillips@freescale.com> Tue, 21 Mar 2006 16:43:16 -0600
Documentation/powerpc/booting-without-of.txt | 72 ++++++++++++++++++++++++++
1 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index d02c649..d6626b6 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1365,6 +1365,78 @@ platforms are moved over to use the flat
};
+ g) Freescale SOC SEC Security Engines
+
+ Required properties:
+
+ - device_type : Should be "crypto"
+ - model : Model of the device. Should be "SEC1" or "SEC2"
+ - compatible : Should be "talitos"
+ - reg : Offset and length of the register set for the device
+ - interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+ - num-channels : An integer representing the number of channels
+ available.
+ - channel-fifo-len : An integer representing the number of
+ descriptor pointers each channel fetch fifo can hold.
+ - exec-units-mask : The bitmask representing what execution units
+ (EUs) are available. It's a single 32 bit cell. EU information
+ should be encoded following the SEC's Descriptor Header Dword
+ EU_SEL0 field documentation, i.e. as follows:
+
+ bit 0 = reserved - should be 0
+ bit 1 = set if SEC has the ARC4 EU (AFEU)
+ bit 2 = set if SEC has the DES/3DES EU (DEU)
+ bit 3 = set if SEC has the message digest EU (MDEU)
+ bit 4 = set if SEC has the random number generator EU (RNG)
+ bit 5 = set if SEC has the public key EU (PKEU)
+ bit 6 = set if SEC has the AES EU (AESU)
+ bit 7 = set if SEC has the Kasumi EU (KEU)
+
+ bits 8 through 31 are reserved for future SEC EUs.
+
+ - descriptor-types-mask : The bitmask representing what descriptors
+ are available. It's a single 32 bit cell. Descriptor type
+ information should be encoded following the SEC's Descriptor
+ Header Dword DESC_TYPE field documentation, i.e. as follows:
+
+ bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type
+ bit 1 = set if SEC supports the ipsec_esp descriptor type
+ bit 2 = set if SEC supports the common_nonsnoop desc. type
+ bit 3 = set if SEC supports the 802.11i AES ccmp desc. type
+ bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type
+ bit 5 = set if SEC supports the srtp descriptor type
+ bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type
+ bit 7 = set if SEC supports the pkeu_assemble descriptor type
+ bit 8 = set if SEC supports the aesu_key_expand_output desc.type
+ bit 9 = set if SEC supports the pkeu_ptmul descriptor type
+ bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type
+ bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type
+
+ ..and so on and so forth.
+
+ Example:
+
+ /* MPC8548E */
+ crypto@30000 {
+ device_type = "crypto";
+ model = "SEC2";
+ compatible = "talitos";
+ reg = <30000 10000>;
+ interrupts = <1d 3>;
+ interrupt-parent = <40000>;
+ num-channels = <4>;
+ channel-fifo-len = <24>;
+ exec-units-mask = <000000fe>;
+ descriptor-types-mask = <073f1127>;
+ };
+
+
More devices will be defined as this spec matures.
^ permalink raw reply related
* Re: [PATCH 4/11] powerpc: Replace platform_is_lpar() with a firmware feature
From: Michael Ellerman @ 2006-03-22 0:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, paulus
In-Reply-To: <20060322113508.08b07cb4.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On Wed, 22 Mar 2006 11:35, Stephen Rothwell wrote:
> On Tue, 21 Mar 2006 20:45:59 +1100 Michael Ellerman <michael@ellerman.id.au>
wrote:
> > It has been decreed that platform numbers are evil, so as a step in that
> > direction, replace platform_is_lpar() with a FW_FEATURE_LPAR bit.
> >
> > Currently FW_FEATURE_LPAR really means i/pSeries LPAR, in the future we
> > might have to clean that up if we need to be more specific about what
> > LPAR actually means. But that's another patch ...
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>
> Just wondering if you considered just #defining platform_is_lpar() to be
> firmware_has_feature(FW_FEATURE_LPAR) ...
Thought about it, but decided it was ugly, and obscures what's really
happening, ie. LPAR-ness is just a FW_FEATURE bit.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 5/11] powerpc: iseries: mf related cleanups
From: Stephen Rothwell @ 2006-03-22 0:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060321094632.ADC4467B6B@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
Hi Michael,
Just some small nits ...
On Tue, 21 Mar 2006 20:46:02 +1100 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> +static int mf_initialized = 0;
We don't generally put the "= 0".
> + mf_initialized = 1;
> + mb();
Do we really need the mb(). If so, a comment saying why would be good.
(Yes, I know that you are just moving code.)
Otherwise looks good.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 4/11] powerpc: Replace platform_is_lpar() with a firmware feature
From: Stephen Rothwell @ 2006-03-22 0:35 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060321094630.E7AD067B21@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
On Tue, 21 Mar 2006 20:45:59 +1100 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> It has been decreed that platform numbers are evil, so as a step in that
> direction, replace platform_is_lpar() with a FW_FEATURE_LPAR bit.
>
> Currently FW_FEATURE_LPAR really means i/pSeries LPAR, in the future we might
> have to clean that up if we need to be more specific about what LPAR actually
> means. But that's another patch ...
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Just wondering if you considered just #defining platform_is_lpar() to be
firmware_has_feature(FW_FEATURE_LPAR) ...
Otherwise looks good.
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] powerpc: update mailing list addresses
From: Stephen Rothwell @ 2006-03-22 0:26 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <96AB6792-D07B-4E5D-B43F-5D2D233B1131@kernel.crashing.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
Documentation/powerpc/hvcs.txt | 4 ++--
MAINTAINERS | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
0e626f91110ad84ae04809aec8a9458c6bdf3c64
diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt
index dca75cb..1e38166 100644
--- a/Documentation/powerpc/hvcs.txt
+++ b/Documentation/powerpc/hvcs.txt
@@ -558,9 +558,9 @@ partitions.
The proper channel for reporting bugs is either through the Linux OS
distribution company that provided your OS or by posting issues to the
-ppc64 development mailing list at:
+PowerPC development mailing list at:
-linuxppc64-dev@lists.linuxppc.org
+linuxppc-dev@ozlabs.org
This request is to provide a documented and searchable public exchange
of the problems and solutions surrounding this driver for the benefit of
diff --git a/MAINTAINERS b/MAINTAINERS
index 8db5c33..d8878ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -534,7 +534,7 @@ S: Supported
BROADBAND PROCESSOR ARCHITECTURE
P: Arnd Bergmann
M: arnd@arndb.de
-L: linuxppc64-dev@ozlabs.org
+L: linuxppc-dev@ozlabs.org
W: http://linuxppc64.org
S: Supported
@@ -1626,7 +1626,7 @@ P: Anton Blanchard
M: anton@samba.org
M: anton@au.ibm.com
W: http://linuxppc64.org
-L: linuxppc64-dev@ozlabs.org
+L: linuxppc-dev@ozlabs.org
S: Supported
LINUX SECURITY MODULE (LSM) FRAMEWORK
--
1.2.4
^ permalink raw reply related
* Re: [RFC/PATCH] powerpc: Make BUG_ON & WARN_ON play nice with compile-time optimisations
From: Stephen Rothwell @ 2006-03-22 0:16 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060321055203.EF12167A39@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
On Tue, 21 Mar 2006 16:51:29 +1100 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> Although we could do this. It relys on firmware_has_feature() being a macro,
> but perhaps that's ok. This isn't exactly ideal, as it encourages us to use
> macros where we could otherwise use static inlines, but perhaps it's ok.
In this case the macros are small and the overall effect looks good.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Running Linux 2.6.16 and Xorg 7.0 on iMac G5 rev C (iSight)
From: Étienne Bersac @ 2006-03-22 0:11 UTC (permalink / raw)
To: Linuxppc-dev, debian-powerpc, ubuntu-devel
Hello,
With the great help of Benjamin Herrenschmidt, i reach to run linux =20
and Xorg on an iMac G5 rev C 20" (the iSight line) with an Ati Radeon =20=
X600 XT Pro (RV380). Make your backup ! You should verify each file i =20=
ship with this howto. Conf files are available at http://=20
bersace03.free.fr/pub/Linux/iMac%20G5/.
You need at least a 2.6.15-rc1 kernel, a Mac OS X installation and an =20=
install cd. (I use an ubuntu one). I advice you to make a place for =20
linux before installation.
- Get Ben's kernel at http://bersace03.free.fr/pub/iMac%20G5/=20
vmlinux.bz2 (mirror of http://gate.crashing.org/~benh/vmlinux.bz2). =20
bunzip2 it at /.
- Copy install/yaboot and initrd.gz from the installer to /. Rename =20=
initrd.gz to initrd-cd.gz. Copy yaboot.conf from the website to /. I =20
assume you will install linux in /dev/sda5, if this is not the case, =20
edit yaboot.conf
- Insert your cd. It's time to reboot !
- Type Option+Command+O+F at boot time. This should open the OF =20
terminal.
- Type "boot hd:X,yaboot" where X is the number of the Mac OS X =20
volume (often 3). Remember this each time you have to use yaboot =20
while we have not run "ybin".
- Choose the "cd" label at yaboot prompt. First questions should =20
arrives such as language, country, etc. Then the installation should =20
go on.
- Reboot at the end of the installation, using yaboot from OF prompt.
- Choose the "rescue" label to boot. Copy the installed initrd.gz =20
to your Macintosh Volume, using an usb key/hd/whatever you want. Copy =20=
this initrd.gz as /initrd-hd.gz at root of your Macintosh Volume. =20
Here you may have to change the /yaboot.conf to reflect the =20
installation (especially the root=3D/dev/sda5 option). This might be =20
possible to run ybin here, but i'm not sure.
- Disable the display manager (e.g. update-rc.d -f gdm remove).
- Now it's time to boot the installed system, still using ben's =20
kernel. Choose the "hd" label at yaboot prompt. Once your system is =20
booted, configure network (network-manager work fine), install build-=20
essential and other good stuffs like kernel-package and fakeroot. Get =20=
the source ! 2.6.16 is fine. use g5_defconfig as .config and compile =20
the kernel.
- Modify /etc/yaboot.conf, add an entry for your kernel and set it =20
as default (of course), add macosx option, etc.. When you are sure, =20
run ybin. Now you don't need OF prompt anymore.
- You may want to restart, but we can continue.
Next step is xorg. You need a special branch of the ati driver for =20
xorg. Thanks to the new modular Xorg :)
- Install automake-1.7, x11proto-*, xserver-xorg-dev, xlibs-dev and =20=
other stuff you may need to compile this. ./configure will help you. =20
The CVSROOT is :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg . I =20
install stuff with --prefix=3D/usr.
- Checkout and install util/macros.
- Use ati-1-0-branch branch of the ati driver ( http://=20
webcvs.freedesktop.org/xorg/driver/xf86-video-ati/?=20
only_with_tag=3Dati-1-0-branch ). Checkout and install it.
- Use the xorg.conf available at http://bersace03.free.fr/pub/Linux/=20=
iMac%20G5/xorg.conf . I own an iMac G5 20", so if you have the 17" =20
one, you must use the result of 'parse-edid $(find /proc/device-tree -=20=
name EDID)' as Screen Section, and use the resolution from xresprobe =20=
radeon in the PanelSize option of the Device Section. You should =20
check xorg.conf and track error.
- Pray and run your display manager (e.g. invocke-rc.d gdm start). =20
If you are lucky, you will see the charming waiting cursor and then =20
the dm prompt. Eur=EAka !!
- If it work, enable your diplays manager with z.B. dpkg-=20
reconfigure gdm.
OR
- If you get a blank screen, try to play with radeon(4) options in =20
xorg.conf. Send feedbacks. Blank screen seems to mean that you won't =20
see anything while you do not reboot the box. This is where ssh is =20
usefull.
This is the end of this howto.
I had had some difficulties to write this howto because i did the two =20=
step with several weeks and a lot of failures between them . So i =20
might have forgottent some important points. Please send feedbacks.
I really want to thank Benjamin Herrenschmidt who helps me several =20
times and does great work to support those computers. Merci Benjamin !
=C9tienne.
^ permalink raw reply
* Re: [PATCH 7/7] powerpc numa: Consolidate assignment of cpus to nodes
From: Michael Ellerman @ 2006-03-21 23:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Lynch
In-Reply-To: <1142983379.28864.9.camel@pants.austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]
On Wed, 22 Mar 2006 10:22, Nathan Lynch wrote:
> On Wed, 2006-03-22 at 10:09 +1100, Michael Ellerman wrote:
> > On Wed, 22 Mar 2006 06:16, Nathan Lynch wrote:
> > > On Tue, 2006-03-21 at 10:38 -0800, Dave Hansen wrote:
> > > > By the way, what do the "l" and "h" in front of "cpu" mean anyway?
> > >
> > > "logical" and "hot"? I dunno, just seemed to be the convention in
> > > other cpu notifiers at the time the code was written.
> >
> > Ouch, that's unfortunate. In the powerpc code hcpu _usually_ means hard
> > cpu number, as opposed to logical (lcpu).
>
> Grep begs to differ:
>
> $ grep -rw hcpu arch/powerpc include/asm-powerpc
> arch/powerpc/kernel/sysfs.c: unsigned long
> action, void *hcpu) arch/powerpc/kernel/sysfs.c: unsigned int cpu =
> (unsigned int)(long)hcpu; arch/powerpc/mm/numa.c: void
> *hcpu)
> arch/powerpc/mm/numa.c: unsigned long lcpu = (unsigned long)hcpu;
You're right, it's actually a mixture of pcpu, hw_cpuid, hardid etc. So there
should be no confusion by using hcpu for "hot" cpu.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] powerpc numa: Consolidate assignment of cpus to nodes
From: Nathan Lynch @ 2006-03-21 23:22 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <200603221009.19523.michael@ellerman.id.au>
On Wed, 2006-03-22 at 10:09 +1100, Michael Ellerman wrote:
> On Wed, 22 Mar 2006 06:16, Nathan Lynch wrote:
> > On Tue, 2006-03-21 at 10:38 -0800, Dave Hansen wrote:
> > > By the way, what do the "l" and "h" in front of "cpu" mean anyway?
> >
> > "logical" and "hot"? I dunno, just seemed to be the convention in other
> > cpu notifiers at the time the code was written.
>
> Ouch, that's unfortunate. In the powerpc code hcpu _usually_ means hard cpu
> number, as opposed to logical (lcpu).
Grep begs to differ:
$ grep -rw hcpu arch/powerpc include/asm-powerpc
arch/powerpc/kernel/sysfs.c: unsigned long action, void *hcpu)
arch/powerpc/kernel/sysfs.c: unsigned int cpu = (unsigned int)(long)hcpu;
arch/powerpc/mm/numa.c: void *hcpu)
arch/powerpc/mm/numa.c: unsigned long lcpu = (unsigned long)hcpu;
^ permalink raw reply
* Re: [PATCH 8/11] powerpc: Add strne2a() to convert a string from EBCDIC to ASCII
From: Michael Ellerman @ 2006-03-21 23:25 UTC (permalink / raw)
To: Olof Johansson; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20060321184358.GB5248@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]
On Wed, 22 Mar 2006 05:43, Olof Johansson wrote:
> On Tue, Mar 21, 2006 at 07:32:39PM +0100, Andreas Schwab wrote:
> > Olof Johansson <olof@lixom.net> writes:
> > > Why iterate over the string twice? Why not do
> > > for (..; i < n && src[n]; ...)
> >
> > ITYM i < n && src[i].
>
> Doh, right.
That's why :)
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] powerpc numa: Consolidate assignment of cpus to nodes
From: Michael Ellerman @ 2006-03-21 23:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Lynch
In-Reply-To: <1142968571.27114.28.camel@pants.austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
On Wed, 22 Mar 2006 06:16, Nathan Lynch wrote:
> On Tue, 2006-03-21 at 10:38 -0800, Dave Hansen wrote:
> > By the way, what do the "l" and "h" in front of "cpu" mean anyway?
>
> "logical" and "hot"? I dunno, just seemed to be the convention in other
> cpu notifiers at the time the code was written.
Ouch, that's unfortunate. In the powerpc code hcpu _usually_ means hard cpu
number, as opposed to logical (lcpu). In this case though it looks like hcpu
holds the logical cpu number, which is a bit icky. That might be worth
fixing.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Emulating button 3 on 2 button ADB mice.
From: Nick Vetter @ 2006-03-21 21:56 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
Dear Sir: do you have a patch for this kensington orbit trackball mouse that
I can use with Debian? If so I will post it in the pmac-Linux-nubus-users
group at the Glist site in source forge.
I would also like to use it for my old powerbook 1400c which is running
debian sarge.
Thanks
Nick
_______________________________________
NOTICE OF CONFIDENTIALITY: The information contained in this e-mail is intended only for the use of the individual or entity to which it is addressed and it may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient of this e-mail message, you are hereby notified that any disclosure, dissemination or copying of this communication is strictly prohibited. If you received this communication in error, please notify and delete the original message. Thank you for your cooperation.
[-- Attachment #2: Type: text/html, Size: 1921 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] msi abstractions and support for altix
From: David S. Miller @ 2006-03-21 21:53 UTC (permalink / raw)
To: maule
Cc: tony.luck, linux-ia64, gregkh, linux-kernel, j-nomura,
linuxppc64-dev, linux-pci
In-Reply-To: <20060321143444.9913.48372.11324@lnx-maule.americas.sgi.com>
From: Mark Maule <maule@sgi.com>
Date: Tue, 21 Mar 2006 08:34:44 -0600 (CST)
> Mark
>
> 1/3 msi-ops.patch
> Add an msi_arch_init() hook which can be used to perform platform
> specific setup prior to msi use.
>
> Define a set of msi ops to implement the platform-specific tasks:
>
> setup - set up plumbing to get a vector directed at a default
> cpu, and return the corresponding MSI bus address and data.
> teardown - inverse of msi_setup
> target - retarget a vector to a given cpu
>
> Define the routine msi_register() called from msi_arch_init()
> to set the desired ops.
>
> Move a bunch of apic-specific code out of the msi core .h/.c and
> into a new msi-apic.c file.
Mark, thanks for doing this work. The better abstracted out the
so-called generic MSI support code is, the better. Several platforms
will benefit from this, such as PPC and Sparc64, both of which
cannot take advantage of MSI support in their PCI controllers because
of how x86 centric the current MSI support layer is.
Thanks again.
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL SEC node to documentation
From: Paul Nasrat @ 2006-03-21 21:23 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1142969335.395.6.camel@basalt>
On Tue, 2006-03-21 at 13:28 -0600, Hollis Blanchard wrote:
> On Tue, 2006-03-21 at 12:25 -0600, Kumar Gala wrote:
> > On Mar 20, 2006, at 8:14 PM, Hollis Blanchard wrote:
> > > Have you consulted with any other vendors regarding these
> > > properties? I know
> > > there is no IEEE1275 binding for these sorts of devices, but we can
> > > at least
> > > attempt to standardize it (even in the absence of the Open Firmware
> > > Working
> > > Group)...
> >
> > Beyond the device_type, I'm not sure if there is much more one could
> > standardize one. The other fields that Kim spec'd are either generic
> > OF fields (reg, interrupts, etc.) or specific to the Freescale devices.
>
> The device_type and compatible properties are exactly what I'm talking
> about.
The Working Group lists still exist but are pretty dead. I agree we
really want to ensure that both OF based and dtc based new hardware is
consistent. I'm not sure how we want to do this, but we can document in
Documentation and then use eg SLOF to mock out the OF interfaces and
create proposals and kick some life into the OF working group.
Paul
^ 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