* RE: atomic operations in user space
From: Brent Cook @ 2006-08-29 12:36 UTC (permalink / raw)
To: Li Yang-r58472, Esben Nielsen, Liu Dave-r63238
Cc: Xupei Liang, linuxppc-embedded
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC7A3@zch01exm20.fsl.freescale.net>
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+bcook=3Dbpointsys.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+bcook=3Dbpointsys.com@ozlabs.o
rg] On Behalf Of Li Yang-r58472
> Sent: Tuesday, August 29, 2006 5:53 AM
> To: Esben Nielsen; Liu Dave-r63238
> Cc: Xupei Liang; linuxppc-embedded@ozlabs.org
> Subject: RE: atomic operations in user space
>=20
> > It is available for PowerPC, but not in POWER and POWER2
> instructionsets
> > according to=20
> http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
> > It is the same in the ARM world: Atomic instructions was=20
> introduced in
> > ARMv6 I believe. Older ARM processors don't have them.
>=20
> Yes, I do know there are lwarx and stwrx instructions. But=20
> there is only one reservation per CPU and reservation can be=20
> re-established with no difference.
> So there are possibilities reservation is broken and reserved=20
> again in one atomic block.
>=20
> Task A Task B
> lwarx
> ......
> lwarx
> stwrx
>=20
> .....
> .....
> lwarx
> stwrx
> .....
> stwrx
>=20
> The addresses of above operations are the same.
>=20
> In this case Thread A thinks that it is atomic as it holds=20
> the same reservation, but it is actually broken. Such=20
> control flow can't be prevented in user space.
>=20
This is exactly how it is supposed to work! That's why there is a loop
in the atomic increment - you check if you still had the reservation
after the transaction by checking the result from the stwcx, and if not,
retry. This works perfectly well no matter if it is from userspace or
the kernel - it is a CPU function. It even works between CPUs on some
later PowerPCs - I've had it working perfectly from userspace on a dual
7448 setup.
PowerPC atomic instructions are not atomic in the sense that they _lock_
anything. The only thing these instructions give you is a way to see if
another thread used the instructions while your thread was using them,
and if you see a conflict, you retry until your code finishes
uninterrupted. This makes it fine for short transactions, like atomic
increment. You probably would not want to use these instructions for
protecting longer transactions of more than a few instructions.
If you look at how, for instance, futexes work in Linux, they rely on
being able to do atomic increment and decrement from _userspace_.
Read this article to understand how it works:
http://www-128.ibm.com/developerworks/library/pa-atom/
- Brent
^ permalink raw reply
* Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
From: Michael Ellerman @ 2006-08-29 12:58 UTC (permalink / raw)
To: Santiago Leon; +Cc: linuxppc64-dev, jgarzik, anton, netdev
In-Reply-To: <4452724D.7050800@us.ibm.com>
On 4/29/06, Santiago Leon <santil@us.ibm.com> wrote:
> Michael Ellerman wrote:
> > Any chance of getting it into to 2.6.17 ...
2.6.19 perhaps?
cheers
^ permalink raw reply
* Re: Linux v2.6.18-rc5
From: Nathan Lynch @ 2006-08-29 13:06 UTC (permalink / raw)
To: Olaf Hering
Cc: linuxppc-dev, Linus Torvalds, Paul Mackerras,
Linux Kernel Mailing List
In-Reply-To: <20060829115537.GA24256@aepfle.de>
Hi Olaf-
Olaf Hering wrote:
> On Sun, Aug 27, Linus Torvalds wrote:
>
> > Pls test it out, and please remind all the appropriate people about any
> > regressions you find (including any found earlier if they haven't been
> > addressed yet).
>
> > Nathan Lynch:
> > [POWERPC] Fix gettimeofday inaccuracies
>
> Tested on B&W G3, iBook1 and a G4/466.
> This patch causes deadlocks on ppc32, but not on ppc64. Have to verify
> it on a vanilla kernel, but I'm sure there are no funky patches in
> openSuSE.
>
> https://bugzilla.novell.com/show_bug.cgi?id=202146
Sorry about that, does this (a partial revert of the change) fix it
for you?
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 18e59e4..fe9b1d9 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -655,7 +655,6 @@ void timer_interrupt(struct pt_regs * re
int next_dec;
int cpu = smp_processor_id();
unsigned long ticks;
- u64 tb_next_jiffy;
#ifdef CONFIG_PPC32
if (atomic_read(&ppc_n_lost_interrupts) != 0)
@@ -697,14 +696,11 @@ void timer_interrupt(struct pt_regs * re
continue;
write_seqlock(&xtime_lock);
- tb_next_jiffy = tb_last_jiffy + tb_ticks_per_jiffy;
- if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
- tb_last_jiffy = tb_next_jiffy;
- tb_last_stamp = per_cpu(last_jiffy, cpu);
- do_timer(regs);
- timer_recalc_offset(tb_last_jiffy);
- timer_check_rtc();
- }
+ tb_last_jiffy += tb_ticks_per_jiffy;
+ tb_last_stamp = per_cpu(last_jiffy, cpu);
+ do_timer(regs);
+ timer_recalc_offset(tb_last_jiffy);
+ timer_check_rtc();
write_sequnlock(&xtime_lock);
}
^ permalink raw reply related
* RE: atomic operations in user space
From: Li Yang @ 2006-08-29 13:37 UTC (permalink / raw)
To: linuxppc-embedded
> This is exactly how it is supposed to work! That's why there is a loop
> in the atomic increment - you check if you still had the reservation
> after the transaction by checking the result from the stwcx, and if not,
> retry.
I surely know all the theories you mentioned clearly. But please do
look at the case I gave. Correct me if I missed anything. Thanks
All the lwarx and stwcx operate on the same address.
> Task A Task B
> lwarx
// Get RESERVATION
> ......
> lwarx
> stwcx
// RESERVATION cleared
>
> .....
> .....
> lwarx
// Get RESERVATION again
> stwcx
//Note here: RESERVATION is valid, address is the same.
So the result is commited, no retry for task A
> .....
> stwcx
//RESERVATION is cleared, retry atomic op for task B
Please be noted that reservation is only identified by reservation bit
and address operated on. So different lwarx's on the same address,
may be considered as the same reservation.
^ permalink raw reply
* Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
From: Gerhard Pircher @ 2006-08-29 15:07 UTC (permalink / raw)
To: Marcus Comstedt, linuxppc-dev
In-Reply-To: <yf9bqq6p305.fsf@omoikane.mc.pp.se>
Hi Marcus,
I guess this message should also be forwarded to linux-usb-devel@lists.sourceforge.net. I hope the developers there can make some comments.
Gerhard
-------- Original-Nachricht --------
Datum: Sun, 27 Aug 2006 18:17:14 +0200
Von: Marcus Comstedt <marcus@mc.pp.se>
An: linuxppc-dev@ozlabs.org
Betreff: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
>
> Hello.
>
> I'm running 2.6.16.27 on an AmigaOneXE, which is a G4 based board
> which has a northbridge (ArticiaS) which does not support cache
> coherency. Because of this, CONFIG_NOT_COHERENT_CACHE is set.
>
> The problem I've been having is that the EHCI USB2 host driver causes
> a kernel oops (see attachment) immediately on bootup.
>
> First, let me outline why this oops happens:
>
> 1) The EHCI driver uses a structure called "echi_qh", which contains
> both data to be accessed by the USB hardware through DMA, and
> private housekeeping data.
> 2) Since part of the structure is for DMA, instances of the structre
> are allocated with dma_pool_alloc().
> 3) Pages allocated with dma_pool_alloc() are cache-inhibited on this
> system, due to the lack of cache coherency support.
> 4) The private data in this structure included a struct kref, which in
> turn contains an atomic_t.
> 5) Incrementing and decrementing an atom_t, and thereby a kref, is
> done with lwarx/stwcx.
> 6) lwarx on a cache-inhibited address is not allowed on G4 (generates
> a DSI).
>
> Now, the problem is deciding in which of these steps the actual error
> lies, since none of these facts (apart from #6) is set in stone. In
> my opinion though, it makes sense to simply say that atomic_t:s (and
> therefore kref:s) are not supported in DMA memory. This would place
> the error in the EHCI driver, with two possible solutions:
>
> A) Rewrite qh_get() and qh_put() to use something else than
> kref_get()/kref_put(). Simply using non-atomic increment and
> decrement made the Oops go away, but as I don't know the design
> decision behind using a struct kref, I can't say that atomicity
> isn't needed, so such a simple fix might lead to race conditions.
>
> B) Break struct ehci_qh into two parts, one allcated with
> dma_pool_alloc() and one allocated with kmalloc(), where the fields
> accessed by the hardware is put into the former, and the driver
> private data (which includes the kref) in the latter. Safe and no
> major performance hit (just one level of indirection added in some
> places, and using cache-enabled memory for the internal data might
> actually improve performance), but the change touches a rather
> large amount of lines (patch attached).
>
> C) Basically the same as B, but only the kref (and a pointer back to
> the rest of the data, so that qh_destroy can find it) is moved to
> the kmalloced part. This means only ehci_qh_alloc(), qh_get() and
> qh_put() need to be changed, so the changeset is much smaller. I
> don't have a patch ready for this, but I can make one on request.
>
> A completely different approach would be
>
> D) Make the DSI exception handler emulate lwarx on cache-inhibited
> pages.
>
> This seems like a more complex fix though, and I'm sure the
> performance would be pretty lousy (although only NOT_COHERENT_CACHE
> systems would be affected of course).
>
> So, what do you guys think? Which is the best way to rectify the
> situation? (Apart from changing to a better northbrige, which I don't
> see happening, realistically. :-/ )
>
>
> // Marcus
>
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [PATCH] corrected PCI interrupt sense values to level low in mpc8349emds.dts
From: Sergei Shtylyov @ 2006-08-29 15:27 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060828174910.236bf042.kim.phillips@freescale.com>
Hello.
Kim Phillips wrote:
> Corrected PCI interrupt sense values to level low in mpc8349emds.dts, per Leo's recommendation.
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> applies on top of "[PATCH 4/4] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts"
> arch/powerpc/boot/dts/mpc8349emds.dts | 112 +++++++++++++++++----------------
> 1 files changed, 56 insertions(+), 56 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8349emds.dts b/arch/powerpc/boot/dts/mpc8349emds.dts
> index 7e4508b..0643db9 100644
> --- a/arch/powerpc/boot/dts/mpc8349emds.dts
> +++ b/arch/powerpc/boot/dts/mpc8349emds.dts
> @@ -178,46 +178,46 @@
> interrupt-map = <
>
> /* IDSEL 0x11 */
> - 8800 0 0 1 700 14 0
> - 8800 0 0 2 700 15 0
> - 8800 0 0 3 700 16 0
> - 8800 0 0 4 700 17 0
> + 8800 0 0 1 700 14 2
> + 8800 0 0 2 700 15 2
> + 8800 0 0 3 700 16 2
> + 8800 0 0 4 700 17 2
Since when 2 means level low? 2 is level high, 1 is level low.
WBR, Sergei
^ permalink raw reply
* Re: [QUESTION] Enable coherency for all pages on 83xx to fix PCI data corruption
From: Kumar Gala @ 2006-08-29 15:28 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-dev
In-Reply-To: <995B09A8299C2C44B59866F6391D263511B9EA@zch01exm21.fsl.freescale.net>
On Aug 28, 2006, at 9:04 PM, Liu Dave-r63238 wrote:
>> This was to address PCI5 if I remember correctly.
>>
>> - kumar
>>
>> On Aug 28, 2006, at 2:49 AM, Liu Dave-r63238 wrote:
>>
>>> All,
>>>
>>> I want to know which PCI errata is solved by this patch and if this
>>> patch did test on real hardware.
>>>
>>> I know this patch turn on the 'M' bit -memory coherency.
>>> But I don't believe this can solved the "PCI read multi-line"
>>> errata.
>>>
>>> -DAve
> <snip>
>
> I also don't believe this patch can solve the PCI5 errata, The PCI5
> description:
>
> When external PCI devices try to read from the memory which is defined
> as
> prefetchable and where the transaction is more than one cache line,
> there
> may be data corruption.
Randy may remember but this fixed an issue related that he was seeing
with an e100 or e1000 and it was the solution provided by the
Freescale Apps team in Austin.
- kumar
^ permalink raw reply
* Re: [PATCH] corrected PCI interrupt sense values to level low in mpc8349emds.dts
From: Sergei Shtylyov @ 2006-08-29 15:35 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <44F45CDD.5060206@ru.mvista.com>
Hello, I wrote:
>> Corrected PCI interrupt sense values to level low in mpc8349emds.dts,
>> per Leo's recommendation.
>> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>> ---
>> applies on top of "[PATCH 4/4] Add MPC8349E MDS device tree source
>> file to arch/powerpc/boot/dts"
>> arch/powerpc/boot/dts/mpc8349emds.dts | 112
>> +++++++++++++++++----------------
>> 1 files changed, 56 insertions(+), 56 deletions(-)
>>
>> diff --git a/arch/powerpc/boot/dts/mpc8349emds.dts
>> b/arch/powerpc/boot/dts/mpc8349emds.dts
>> index 7e4508b..0643db9 100644
>> --- a/arch/powerpc/boot/dts/mpc8349emds.dts
>> +++ b/arch/powerpc/boot/dts/mpc8349emds.dts
>> @@ -178,46 +178,46 @@
>> interrupt-map = <
>>
>> /* IDSEL 0x11 */
>> - 8800 0 0 1 700 14 0
>> - 8800 0 0 2 700 15 0
>> - 8800 0 0 3 700 16 0
>> - 8800 0 0 4 700 17 0
>> + 8800 0 0 1 700 14 2
>> + 8800 0 0 2 700 15 2
>> + 8800 0 0 3 700 16 2
>> + 8800 0 0 4 700 17 2
> Since when 2 means level low? 2 is level high, 1 is level low.
Ah, this board uses IPIC, not OpenPIC. Anyway, this contradicts your own
comment to the "ipic" device node stating that 8 is the right value for level low.
WBR, Sergei
^ permalink raw reply
* Re: Linux v2.6.18-rc5
From: Yves-Alexis Perez @ 2006-08-29 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060829130629.GW11309@localdomain>
On Tue, 2006-08-29 at 08:06 -0500, Nathan Lynch wrote:
> Sorry about that, does this (a partial revert of the change) fix it
> for you?
I tried 2.6.18-rc5 on my powerbook g4 (5,6) and indeed I had lots of
deadlocks, it was quite unusable. I've tried this patch and it seems to
fix the problem. (up for half an our without problems, I guess)
--
Yves-Alexis
^ permalink raw reply
* Re: Linux v2.6.18-rc5
From: Olaf Hering @ 2006-08-29 15:52 UTC (permalink / raw)
To: Nathan Lynch
Cc: linuxppc-dev, Linus Torvalds, Paul Mackerras,
Linux Kernel Mailing List
In-Reply-To: <20060829130629.GW11309@localdomain>
On Tue, Aug 29, Nathan Lynch wrote:
> Hi Olaf-
>
> Olaf Hering wrote:
> > On Sun, Aug 27, Linus Torvalds wrote:
> >
> > > Pls test it out, and please remind all the appropriate people about any
> > > regressions you find (including any found earlier if they haven't been
> > > addressed yet).
> >
> > > Nathan Lynch:
> > > [POWERPC] Fix gettimeofday inaccuracies
> >
> > Tested on B&W G3, iBook1 and a G4/466.
> > This patch causes deadlocks on ppc32, but not on ppc64. Have to verify
> > it on a vanilla kernel, but I'm sure there are no funky patches in
> > openSuSE.
> >
> > https://bugzilla.novell.com/show_bug.cgi?id=202146
>
> Sorry about that, does this (a partial revert of the change) fix it
> for you?
Yes, it works ok with this change.
^ permalink raw reply
* RE: atomic operations in user space
From: Esben Nielsen @ 2006-08-29 16:05 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-embedded
In-Reply-To: <a0bc9bf80608290637q165d1f54x2d80e771671c894f@mail.gmail.com>
On Tue, 29 Aug 2006, Li Yang wrote:
>> This is exactly how it is supposed to work! That's why there is a loop
>> in the atomic increment - you check if you still had the reservation
>> after the transaction by checking the result from the stwcx, and if not,
>> retry.
>
> I surely know all the theories you mentioned clearly. But please do
> look at the case I gave. Correct me if I missed anything. Thanks
>
> All the lwarx and stwcx operate on the same address.
>
>> Task A Task B
>> lwarx
> // Get RESERVATION
>> ......
>> lwarx
>> stwcx
>
> // RESERVATION cleared
>>
>> .....
>> .....
>> lwarx
>
> // Get RESERVATION again
Now we do a task switch involving atomic operations, and thus an
reservation on another address.
>> stwcx
>
> //Note here: RESERVATION is valid, address is the same.
> So the result is commited, no retry for task A
>
>> .....
>> stwcx
> //RESERVATION is cleared, retry atomic op for task B
>
> Please be noted that reservation is only identified by reservation bit
> and address operated on. So different lwarx's on the same address,
> may be considered as the same reservation.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Ralf Baechle @ 2006-08-29 16:17 UTC (permalink / raw)
To: linux-ia64, linux-mips, linuxppc-embedded, paulkf, takata,
linux-kernel
In-Reply-To: <20060828085244.GA13544@flint.arm.linux.org.uk>
On Mon, Aug 28, 2006 at 09:52:44AM +0100, Russell King wrote:
> asm/serial.h is supposed to contain the definitions for the architecture
> specific 8250 ports for the 8250 driver. It may also define BASE_BAUD,
> but this is the base baud for the architecture specific ports _only_.
>
> Therefore, nothing other than the 8250 driver should be including this
> header file. In order to move towards this goal, here is a patch which
> removes some of the more obvious incorrect includes of the file.
>
> MIPS and PPC has rather a lot of stuff in asm/serial.h, some of it looks
> related to non-8250 ports. Hence, it's not trivial to conclude that
> these includes are indeed unnecessary, so can mips and ppc people please
> test this patch carefully.
The MIPS bits were just unused leftovers from the days when the arch
code did did register serials & consoles. So for the MIPS bits:
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* Re: atomic operations in user space
From: Li Yang @ 2006-08-29 17:00 UTC (permalink / raw)
To: Esben Nielsen; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0608291804260.22067@frodo.shire>
On 8/30/06, Esben Nielsen <nielsen.esben@gogglemail.com> wrote:
>
>
> On Tue, 29 Aug 2006, Li Yang wrote:
>
> >> This is exactly how it is supposed to work! That's why there is a loop
> >> in the atomic increment - you check if you still had the reservation
> >> after the transaction by checking the result from the stwcx, and if not,
> >> retry.
> >
> > I surely know all the theories you mentioned clearly. But please do
> > look at the case I gave. Correct me if I missed anything. Thanks
> >
> > All the lwarx and stwcx operate on the same address.
> >
> >> Task A Task B
> >> lwarx
> > // Get RESERVATION
> >> ......
> >> lwarx
> >> stwcx
> >
> > // RESERVATION cleared
> >>
> >> .....
> >> .....
> >> lwarx
> >
> > // Get RESERVATION again
>
> Now we do a task switch involving atomic operations, and thus an
> reservation on another address.
>
This makes sense for me.
^ permalink raw reply
* undefined reference to pci_io_base
From: Geoff Levand @ 2006-08-29 17:34 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to understand the intended design of the inb()
and outb() macros in asm-powerpc/io.h. They are causing
me some grief when I set CONFIG_PCI=n:
drivers/built-in.o: undefined reference to `pci_io_base'
This is coming from drivers/char/mem.c, which is always
built in, and is referencing pci_io_base through inb()
and outb().
Anyway, it seems asm-powerpc/io.h has two sets of io macros,
one set for iSeries, and one generic set for everything else.
The problem arises because the generic macros just use the eeh
macros in eeh.h, which in turn, directly use pci_io_base.
I can think of three solutions to this that work for me, but
I'm not sure which, if any, would be the most proper. One
would be to just have this in io.h:
#if defined(CONFI_PCI)
extern unsigned long pci_io_base;
#else
#define pci_io_base 0
#endif
Another would be to have this in some file that is always built
in, like setup-common.c:
#if !defined(CONFI_PCI)
unsigned long pci_io_base;
EXPORT_SYMBOL(pci_io_base);
#endif
A third would be to have another set of io macros in io.h that
are used when CONFIG_PCI=n.
Comments welcome.
-Geoff
^ permalink raw reply
* Re: MPC85xx u-boot definition
From: Becky Bruce @ 2006-08-29 20:01 UTC (permalink / raw)
To: enorm; +Cc: linuxppc-embedded
In-Reply-To: <017001c6cb0e$1b81f440$a309a8c0@SZD823>
On Aug 28, 2006, at 8:54 PM, enorm wrote:
> Hi,
> Some naive questions about u-boot for MPC85xx, the definition of
> some macro in ppc_asm.tmpl. Can anyone there explain them to me
> please?
> 1) In GET_GOT(x) what does " lwz r0,0b-1b(r14) ;" do? what does
> "0b-1b" stands for, or the meaning of the syntax? why move the content
> of the memory pointing by LR?
0b and 1b refer to the labels 0: and 1:. The "b" means find the
first instance of that label backward from the reference point.
> #define GET_GOT \
> bl 1f ; \
> .text 2 ; \
> 0: .long .LCTOC1-1f ; \
> .text ; \
> 1: mflr r14 ; \
> lwz r0,0b-1b(r14) ; \
> add r14,r0,r14 ;
One thing to note when looking at this code that might be confusing:
The .text 2 directive says that the code after it should be put in
subsection "2" of the .text section. The default is 0 if this is not
specified. When you build, this code is no longer sequential -
the .text 2 stuff will end up somewhere in the executable *after* the
normal .text.
To illustrate, here's what you get if you compile just this code and
dump it (I just #defined .LCTOC1 to be 0x1000 so it would compile):
00000000 <.text>:
0: 48 00 00 05 bl 0x4
4: 7d c8 02 a6 mflr r14 << label 1: points here
8: 80 0e 00 0c lwz r0,12(r14)
c: 7d c0 72 14 add r14,r0,r14
10: 00 00 10 0c .long 0x100c << label 0: points here
And what it does, line by line:
bl 0x4 /* LR now contains actual address we're running at */
mflr r14 /* copy LR into r14 so we can use it */
lwz r0,12(r14) /* Get the linker-generated value .LCTOC1-1f */
add r14,r0,r14 /* Correct that value for where we're really
running */
The whole point here is to be somewhat position-independent - we're
calculating where things are rather than using the linker-generated
values because we don't necessarily want to assume we're loaded and
running at the link address.
>
> 2) In START_GOT, any special meaning for the value 32768?
> >> .LCTOC1=.+32768
So, I don't have the code for this, but if I had to guess..... That
value is equivalent to 0x8000 hex. The GOT is usually accessed using
a symbol that's in the middle of the GOT so you can use positive and
negative indexes from that point to access data in the GOT. The max
size of an immediate value in ppc asm is 16 bits. So this is the
halfway point that gives you maximum access with a 16-bit immediate.
> 3) Syntax for GOT_ENTRY(NAME) and GOT(NAME), like . - .LCTOC1
> (line 57) and .text 2 (line 50)
> could not find then in the GNU douments (ld, as, gcc, glibc etc).
Most everything you need is in the gas manual at http://www.gnu.org/
software/binutils/manual/gas-2.9.1/html_mono/as.html. and in the C
preprocessor documentation at http://gcc.gnu.org/onlinedocs/
gcc-2.95.3/cpp.html#SEC_Top. If you're really interested in
understanding this stuff, you should probably also dig up and read
the PowerPC Processor ABI Supplement document as well.
Cheers,
B
^ permalink raw reply
* LinuxThreads && MontaVista Pro 3.1
From: Eric Nuckols @ 2006-08-29 20:13 UTC (permalink / raw)
To: linuxppc-embedded
LinuxThreads && MontaVista Pro 3.1
our setup:
HW:
PrPMC800 MCP7410 board
SW:
MontaVista Pro 3.1
host - i686
target ppc_74xx-
kernel: 2.4.20_mvl31
glibc 2.3.2
LinuxThreads 0.10
GCC 3.3.1
After all the research, it seems the problem is LinuxThreads just has all
sorts of bugs between mishandling signals and deadlocking.
I'm dealing with a tight schedule and lots of code that works great until a
LinuxThreads threadmanager barfs.
I'm in one of those classic positions where I inherited a lot of code that
assumed pthreads worked as described, but have found otherwise.
There's no time or budget to rewrite the entire project to circumvent
threading.
I've built a newer cross-compiler using NPTL, and when compiling with it
(statically of course), I have the __libc_fork assertion problem due to some
botched syscalls.
Likewise, I can't easily modify my kernel for that workaround, because I
will continue to have to use the precompiled userland binaries in my system
that rely on the old glibc libs with LinuxThreads,
compiled in. When it comes to the userland apps that MontaVista supplies,
they don't provide the source and configuration for all the packages (at
least not with the CDs I have), and even if they did, I would probably
require more time than I have to get them all built as needed.
So, my questions to the helpful people on this list are:
1. Does anybody know if MontaVista has fixed these issues in their newer
releases/patches of Pro 3.1 or Pro 4.0? in other words,
would I be spending the company's money wisely to go back to MontaVista
for upgrades and service?
2. If the answer to #1 is NO, has anybody else out there come across this
same type of issue and found a decent solution?
// as for workarounds, I've blocked basically all signals in all threads,
created separate threads to wait on blocked signals, removed all the
pthread_mutex_lock()
calls, and when I debug, I find that ususally I'm deadlocked in some form of
timed_wait() or some other pthread related lockable/blockable call deep
inside another system call
such as syslog for example.
Thanks,
Eric Nuckols
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Linas Vepstas @ 2006-08-29 20:28 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <44F47ABE.7080602@am.sony.com>
On Tue, Aug 29, 2006 at 10:34:54AM -0700, Geoff Levand wrote:
> I'm trying to understand the intended design of the inb()
> and outb() macros in asm-powerpc/io.h. They are causing
> me some grief when I set CONFIG_PCI=n:
>
> drivers/built-in.o: undefined reference to `pci_io_base'
>
> This is coming from drivers/char/mem.c, which is always
> built in, and is referencing pci_io_base through inb()
> and outb().
>
> Anyway, it seems asm-powerpc/io.h has two sets of io macros,
> one set for iSeries, and one generic set for everything else.
> The problem arises because the generic macros just use the eeh
> macros in eeh.h, which in turn, directly use pci_io_base.
>
> I can think of three solutions to this that work for me, but
> I'm not sure which, if any, would be the most proper. One
> would be to just have this in io.h:
>
> #if defined(CONFI_PCI)
> extern unsigned long pci_io_base;
> #else
> #define pci_io_base 0
> #endif
This makes the most sense to me; it compiles to something nice.
> Another would be to have this in some file that is always built
> in, like setup-common.c:
>
> #if !defined(CONFI_PCI)
> unsigned long pci_io_base;
> EXPORT_SYMBOL(pci_io_base);
> #endif
This compiles to something ugly and pointless ...
> A third would be to have another set of io macros in io.h that
> are used when CONFIG_PCI=n.
I'm not sure that yet-another set of macros improves readabily.
Those macros are already fairly byzantine in thier inter-connections.
--linas
^ permalink raw reply
* Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
From: Marcus Comstedt @ 2006-08-29 21:04 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20060829150759.269420@gmx.net>
"Gerhard Pircher" <gerhard_pircher@gmx.net> writes:
> Hi Marcus,
>
> I guess this message should also be forwarded to linux-usb-devel@lists.sourceforge.net. I hope the developers there can make some comments.
>
> Gerhard
Well, I figured the first thing to do would be to reach a consensus
here on whether or not atomic_t:s in DMA memory should be ruled as
unallowed. Judging from the massive silence, there doesn't seem to be
any strong opinions either way though...
// Marcus
^ permalink raw reply
* Help for building linux 2.6.15
From: wei.li4 @ 2006-08-29 21:11 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am working on ELDK 4.0 package with my evaluation board: A&M MPC875,
after configuration for my board, and do 'make zImage', I got the
following errors:
CC arch/ppc/syslib/m8xx_setup.o
arch/ppc/syslib/m8xx_setup.c:56: error: 'bd_t' undeclared here (not in
a function)
arch/ppc/syslib/m8xx_setup.c:62: error: parse error before '*' token
arch/ppc/syslib/m8xx_setup.c:62: warning: function declaration isn't a
prototype
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_calibrate_decr':
arch/ppc/syslib/m8xx_setup.c:144: error: 'binfo' undeclared (first use
in this function)
arch/ppc/syslib/m8xx_setup.c:144: error: (Each undeclared identifier is
reported only once
arch/ppc/syslib/m8xx_setup.c:144: error: for each function it appears in.)
arch/ppc/syslib/m8xx_setup.c:144: error: parse error before ')' token
arch/ppc/syslib/m8xx_setup.c:148: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_set_rtc_time':
arch/ppc/syslib/m8xx_setup.c:216: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_get_rtc_time':
arch/ppc/syslib/m8xx_setup.c:226: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_restart':
arch/ppc/syslib/m8xx_setup.c:235: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_show_percpuinfo':
arch/ppc/syslib/m8xx_setup.c:262: error: 'bp' undeclared (first use in
this function)
arch/ppc/syslib/m8xx_setup.c:264: error: parse error before ')' token
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_find_end_of_memory':
arch/ppc/syslib/m8xx_setup.c:327: error: 'binfo' undeclared (first use
in this function)
arch/ppc/syslib/m8xx_setup.c:328: warning: ISO C90 forbids mixed
declarations and code
arch/ppc/syslib/m8xx_setup.c:330: error: parse error before ')' token
arch/ppc/syslib/m8xx_setup.c:328: warning: unused variable '__res'
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_map_io':
arch/ppc/syslib/m8xx_setup.c:344: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c:344: error: 'IMAP_SIZE' undeclared (first
use in this function)
make[1]: *** [arch/ppc/syslib/m8xx_setup.o] Error 1
Can anyone help me? Thanks.
^ permalink raw reply
* Re: powerpc virq: new routine virq_to_hw
From: Benjamin Herrenschmidt @ 2006-08-29 22:36 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <44F305AA.5020101@am.sony.com>
On Mon, 2006-08-28 at 08:03 -0700, Geoff Levand wrote:
> Benjamin Herrenschmidt wrote:
> > I'd much prefer:
> >
> > static inline irq_hw_number_t virq_to_hw (unsigned int virq)
> > {
> > return irq_map[virq].hwirq;
> > }
>
> Here is an updated version.
>
> -Geoff
>
>
> This adds an accessor routine virq_to_hw() to the
> virq routines which hides the implementation details
> of the virq to hwirq map.
>
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Index: cell--common--4/include/asm-powerpc/irq.h
> ===================================================================
> --- cell--common--4.orig/include/asm-powerpc/irq.h
> +++ cell--common--4/include/asm-powerpc/irq.h
> @@ -136,6 +136,10 @@
>
> extern struct irq_map_entry irq_map[NR_IRQS];
>
> +static inline irq_hw_number_t virq_to_hw(unsigned int virq)
> +{
> + return irq_map[virq].hwirq;
> +}
>
> /**
> * irq_alloc_host - Allocate a new irq_host data structure
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Benjamin Herrenschmidt @ 2006-08-29 22:38 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20060829202831.GB27372@austin.ibm.com>
> > #if defined(CONFI_PCI)
> > extern unsigned long pci_io_base;
> > #else
> > #define pci_io_base 0
> > #endif
>
> This makes the most sense to me; it compiles to something nice.
Agreed.
Ben.
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Paul Mackerras @ 2006-08-29 22:42 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <44F47ABE.7080602@am.sony.com>
Geoff Levand writes:
> I'm trying to understand the intended design of the inb()
> and outb() macros in asm-powerpc/io.h. They are causing
> me some grief when I set CONFIG_PCI=n:
>
> drivers/built-in.o: undefined reference to `pci_io_base'
>
> This is coming from drivers/char/mem.c, which is always
> built in, and is referencing pci_io_base through inb()
> and outb().
Hmmm. inb and outb are designed for accessing PCI I/O space. I guess
we could turn them into BUG() when CONFIG_PCI=n.
Paul.
^ permalink raw reply
* [PATCH] powerpc: Fix MPIC sense codes in doc
From: Benjamin Herrenschmidt @ 2006-08-29 22:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The booting-without-of.txt had incorrect definition for the sense codes
for an OpenPIC controller
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/Documentation/powerpc/booting-without-of.txt
===================================================================
--- linux-work.orig/Documentation/powerpc/booting-without-of.txt 2006-08-30 08:51:19.000000000 +1000
+++ linux-work/Documentation/powerpc/booting-without-of.txt 2006-08-30 08:56:17.000000000 +1000
@@ -1136,10 +1136,10 @@
Devices connected to openPIC-compatible controllers should encode
sense and polarity as follows:
- 0 = high to low edge sensitive type enabled
+ 0 = low to high edge sensitive type enabled
1 = active low level sensitive type enabled
- 2 = low to high edge sensitive type enabled
- 3 = active high level sensitive type enabled
+ 2 = active high level sensitive type enabled
+ 3 = high to low edge sensitive type enabled
ISA PIC interrupt controllers should adhere to the ISA PIC
encodings listed below:
^ permalink raw reply
* libnuma interleaving oddness
From: Nishanth Aravamudan @ 2006-08-29 23:02 UTC (permalink / raw)
To: lameter, ak; +Cc: linux-mm, lnxninja, linuxppc-dev
Hi,
While trying to add NUMA-awareness to libhugetlbfs' morecore
functionality (hugepage-backed malloc), I ran into an issue on a
ppc64-box with 8 memory nodes, running SLES10. I am using two functions
from libnuma: numa_available() and numa_interleave_memory(). When I ask
numa_interleave_memory() to interleave over all nodes (numa_all_nodes is
the nodemask from libnuma), it exhausts node 0, then moves to node 1,
then node 2, etc, until the allocations are satisfied. If I custom
generate a nodemask, such that bits 1 through 7 are set, but bit 0 is
not, then I get proper interleaving, where the first hugepage is on node
1, the second is on node 2, etc. Similarly, if I set bits 0 through 6 in
a custom nodemask, interleaving works across the requested 7 nodes. But
it has yet to work across all 8.
I don't know if this is a libnuma bug (I extracted out the code from
libnuma, it looked sane; and even reimplemented it in libhugetlbfs for
testing purposes, but got the same results) or a NUMA kernel bug (mbind
is some hairy code...) or a ppc64 bug or maybe not a bug at all.
Regardless, I'm getting somewhat inconsistent behavior. I can provide
more debugging output, or whatever is requested, but I wasn't sure what
to include. I'm hoping someone has heard of or seen something similar?
The test application I'm using makes some mallopt calls then justs
mallocs large chunks in a loop (4096 * 100 bytes). libhugetlbfs is
LD_PRELOAD'd so that we can override malloc.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* [PATCH 4/4] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts
From: Kim Phillips @ 2006-08-29 23:13 UTC (permalink / raw)
To: linuxppc-dev
Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
Amended version of "[PATCH 4/4] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts": PCI senses are now correctly corrected to 8 (level low).
arch/powerpc/boot/dts/mpc8349emds.dts | 328 +++++++++++++++++++++++++++++++++
1 files changed, 328 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emds.dts b/arch/powerpc/boot/dts/mpc8349emds.dts
new file mode 100644
index 0000000..12f5dbf
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8349emds.dts
@@ -0,0 +1,328 @@
+/*
+ * MPC8349E MDS Device Tree Source
+ *
+ * Copyright 2005, 2006 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/ {
+ model = "MPC8349EMDS";
+ compatible = "MPC834xMDS";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #cpus = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8349@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // from bootloader
+ bus-frequency = <0>; // from bootloader
+ clock-frequency = <0>; // from bootloader
+ 32-bit;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 10000000>; // 256MB at 0
+ };
+
+ soc8349@e0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <0 e0000000 00100000>;
+ reg = <e0000000 00000200>;
+ bus-frequency = <0>;
+
+ wdt@200 {
+ device_type = "watchdog";
+ compatible = "mpc83xx_wdt";
+ reg = <200 100>;
+ };
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <e 8>;
+ interrupt-parent = <700>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3100 100>;
+ interrupts = <f 8>;
+ interrupt-parent = <700>;
+ dfsrr;
+ };
+
+ spi@7000 {
+ device_type = "spi";
+ compatible = "mpc83xx_spi";
+ reg = <7000 1000>;
+ interrupts = <10 8>;
+ interrupt-parent = <700>;
+ mode = <0>;
+ };
+
+ /* phy type (ULPI or SERIAL) are only types supportted for MPH */
+ /* port = 0 or 1 */
+ usb@22000 {
+ device_type = "usb";
+ compatible = "fsl-usb2-mph";
+ reg = <22000 1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <700>;
+ interrupts = <27 2>;
+ phy_type = "ulpi";
+ port1;
+ };
+ /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
+ usb@23000 {
+ device_type = "usb";
+ compatible = "fsl-usb2-dr";
+ reg = <23000 1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <700>;
+ interrupts = <26 2>;
+ phy_type = "ulpi";
+ };
+
+ mdio@24520 {
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ linux,phandle = <24520>;
+ ethernet-phy@0 {
+ linux,phandle = <2452000>;
+ interrupt-parent = <700>;
+ interrupts = <11 2>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@1 {
+ linux,phandle = <2452001>;
+ interrupt-parent = <700>;
+ interrupts = <12 2>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ address = [ 00 00 00 00 00 00 ];
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <20 8 21 8 22 8>;
+ interrupt-parent = <700>;
+ phy-handle = <2452000>;
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ address = [ 00 00 00 00 00 00 ];
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <23 8 24 8 25 8>;
+ interrupt-parent = <700>;
+ phy-handle = <2452001>;
+ };
+
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>;
+ interrupts = <9 8>;
+ interrupt-parent = <700>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>;
+ interrupts = <a 8>;
+ interrupt-parent = <700>;
+ };
+
+ pci@8500 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x11 */
+ 8800 0 0 1 700 14 8
+ 8800 0 0 2 700 15 8
+ 8800 0 0 3 700 16 8
+ 8800 0 0 4 700 17 8
+
+ /* IDSEL 0x12 */
+ 9000 0 0 1 700 16 8
+ 9000 0 0 2 700 17 8
+ 9000 0 0 3 700 14 8
+ 9000 0 0 4 700 15 8
+
+ /* IDSEL 0x13 */
+ 9800 0 0 1 700 17 8
+ 9800 0 0 2 700 14 8
+ 9800 0 0 3 700 15 8
+ 9800 0 0 4 700 16 8
+
+ /* IDSEL 0x15 */
+ a800 0 0 1 700 14 8
+ a800 0 0 2 700 15 8
+ a800 0 0 3 700 16 8
+ a800 0 0 4 700 17 8
+
+ /* IDSEL 0x16 */
+ b000 0 0 1 700 17 8
+ b000 0 0 2 700 14 8
+ b000 0 0 3 700 15 8
+ b000 0 0 4 700 16 8
+
+ /* IDSEL 0x17 */
+ b800 0 0 1 700 16 8
+ b800 0 0 2 700 17 8
+ b800 0 0 3 700 14 8
+ b800 0 0 4 700 15 8
+
+ /* IDSEL 0x18 */
+ b000 0 0 1 700 15 8
+ b000 0 0 2 700 16 8
+ b000 0 0 3 700 17 8
+ b000 0 0 4 700 14 8>;
+ interrupt-parent = <700>;
+ interrupts = <42 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 a0000000 a0000000 0 10000000
+ 42000000 0 80000000 80000000 0 10000000
+ 01000000 0 00000000 e2000000 0 00100000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8500 100>;
+ compatible = "83xx";
+ device_type = "pci";
+ };
+
+ pci@8600 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x11 */
+ 8800 0 0 1 700 14 8
+ 8800 0 0 2 700 15 8
+ 8800 0 0 3 700 16 8
+ 8800 0 0 4 700 17 8
+
+ /* IDSEL 0x12 */
+ 9000 0 0 1 700 16 8
+ 9000 0 0 2 700 17 8
+ 9000 0 0 3 700 14 8
+ 9000 0 0 4 700 15 8
+
+ /* IDSEL 0x13 */
+ 9800 0 0 1 700 17 8
+ 9800 0 0 2 700 14 8
+ 9800 0 0 3 700 15 8
+ 9800 0 0 4 700 16 8
+
+ /* IDSEL 0x15 */
+ a800 0 0 1 700 14 8
+ a800 0 0 2 700 15 8
+ a800 0 0 3 700 16 8
+ a800 0 0 4 700 17 8
+
+ /* IDSEL 0x16 */
+ b000 0 0 1 700 17 8
+ b000 0 0 2 700 14 8
+ b000 0 0 3 700 15 8
+ b000 0 0 4 700 16 8
+
+ /* IDSEL 0x17 */
+ b800 0 0 1 700 16 8
+ b800 0 0 2 700 17 8
+ b800 0 0 3 700 14 8
+ b800 0 0 4 700 15 8
+
+ /* IDSEL 0x18 */
+ b000 0 0 1 700 15 8
+ b000 0 0 2 700 16 8
+ b000 0 0 3 700 17 8
+ b000 0 0 4 700 14 8>;
+ interrupt-parent = <700>;
+ interrupts = <42 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 b0000000 b0000000 0 10000000
+ 42000000 0 90000000 90000000 0 10000000
+ 01000000 0 00000000 e2100000 0 00100000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8600 100>;
+ compatible = "83xx";
+ device_type = "pci";
+ };
+
+ /* May need to remove if on a part without crypto engine */
+ crypto@30000 {
+ device_type = "crypto";
+ model = "SEC2";
+ compatible = "talitos";
+ reg = <30000 10000>;
+ interrupts = <b 8>;
+ interrupt-parent = <700>;
+ num-channels = <4>;
+ channel-fifo-len = <18>;
+ exec-units-mask = <0000007e>;
+ /* desc mask is for rev2.0,
+ * we need runtime fixup for >2.0 */
+ descriptor-types-mask = <01010ebf>;
+ };
+
+ /* IPIC
+ * interrupts cell = <intr #, sense>
+ * sense values match linux IORESOURCE_IRQ_* defines:
+ * sense == 8: Level, low assertion
+ * sense == 2: Edge, high-to-low change
+ */
+ pic@700 {
+ linux,phandle = <700>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <700 100>;
+ built-in;
+ device_type = "ipic";
+ };
+ };
+};
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox