* Re: [PATCH 03/12] powerpc: Rework runlatch code
From: Benjamin Herrenschmidt @ 2012-04-05 22:12 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2vcldamh2.fsf@igel.home>
On Thu, 2012-04-05 at 23:38 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > This moves the inlines into system.h and changes the runlatch
> > code to use the thread local flags (non-atomic) rather than
> > the TIF flags (atomic) to keep track of the latch state.
> >
> > The code to turn it back on in an asynchronous interrupt is
> > now simplified and partially inlined.
>
> This breaks the X server in that it no longer receives SIGIO signals.
Interesting. I have not observed that on my machine here, however I have
seen on my dual G5 (and not on the quad) some occasional loss of
interrupts for seconds which might be related.
Have you verified that you can "fix" it with reverting just the above
patch ? I would have more easily blamed the rest of my series than this
specific one... Anyways, I'll have a closer look but it might have to
wait for tuesday.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Andreas Schwab @ 2012-04-05 22:10 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120404154020.40C513E09D5@localhost>
Grant Likely <grant.likely@secretlab.ca> writes:
> Can you attach console output logs for each of configs above and also
> with NR_IRQS=128? That might give me some clues as to which specific
> code is causing the issues.
It really looks like the issue starts when irq_expand_nr_irqs is called
the first time to make nr_irqs bigger than NR_IRQS.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 03/12] powerpc: Rework runlatch code
From: Andreas Schwab @ 2012-04-05 21:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1330680922-6894-4-git-send-email-benh__48089.0872575857$1330681158$gmane$org@kernel.crashing.org>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> This moves the inlines into system.h and changes the runlatch
> code to use the thread local flags (non-atomic) rather than
> the TIF flags (atomic) to keep track of the latch state.
>
> The code to turn it back on in an asynchronous interrupt is
> now simplified and partially inlined.
This breaks the X server in that it no longer receives SIGIO signals.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Wolfgang Denk @ 2012-04-05 17:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, robert.karl.berger, Frank Svendsbøe
In-Reply-To: <20120405100228.9ca940aa4739e81540bb2a6f@canb.auug.org.au>
Dear Stephen Rothwell,
In message <20120405100228.9ca940aa4739e81540bb2a6f@canb.auug.org.au> you wrote:
>
> > ELDK 4.2 is based on gcc version 4.2.2 / binutils version 2.17.50.0.12
> > 20070128. This is obviously to old for this code. I do not see an
> > actual problem with that - nobody can expect that we support old tol
> > chain versions forever.
>
> The requirements are documented in Documentation/Changes where we say we
> need gcc 3.2 and binutils 2.12. Not that that is very relevant to this
> discussion. ;-)
Indeed. I doubt you can build any working PPC kernel with these old
tools.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Consistency requires you to be as ignorant today as you were a year
ago." - Bernard Berenson
^ permalink raw reply
* [PATCH 3/4 v2] powerpc: Better scheduling of CR save code in system call path
From: Anton Blanchard @ 2012-04-05 13:44 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120405142557.398f14d2@kryten>
At the moment system call entry looks like:
crclr so
...
mfcr r9
...
std r9,_CCR(r1)
commit bd19c8994a82 ([POWERPC] system call micro optimisation) put
some space between the crclr and mfcr in order to avoid a stall.
There is still a stall seen between the mfcr and std. We can avoid
the crclr by doing it in a GPR with rlwinm which gives us more room
to better schedule the sequence.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
v2:
Milton pointed out that rlwinm copies the low 32bits into the top
32bits and this might confuse ptracers. We tossed around a few ideas
but his suggestion of using rldimi sounds good to me.
Index: linux-build/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/entry_64.S 2012-04-05 14:03:05.123678148 +1000
+++ linux-build/arch/powerpc/kernel/entry_64.S 2012-04-05 23:38:09.182681076 +1000
@@ -63,15 +63,9 @@ system_call_common:
std r0,GPR0(r1)
std r10,GPR1(r1)
ACCOUNT_CPU_USER_ENTRY(r10, r11)
- /*
- * This "crclr so" clears CR0.SO, which is the error indication on
- * return from this system call. There must be no cmp instruction
- * between it and the "mfcr r9" below, otherwise if XER.SO is set,
- * CR0.SO will get set, causing all system calls to appear to fail.
- */
- crclr so
std r2,GPR2(r1)
std r3,GPR3(r1)
+ mfcr r2
std r4,GPR4(r1)
std r5,GPR5(r1)
std r6,GPR6(r1)
@@ -84,15 +78,19 @@ system_call_common:
std r11,GPR12(r1)
std r11,_XER(r1)
std r9,GPR13(r1)
- mfcr r9
mflr r10
+ /*
+ * This clears CR0.SO (bit 28), which is the error indication on
+ * return from this system call.
+ */
+ rldimi r2,r11,28,(63-28)
li r11,0xc01
- std r9,_CCR(r1)
std r10,_LINK(r1)
std r11,_TRAP(r1)
mfctr r10
std r10,_CTR(r1)
std r3,ORIG_GPR3(r1)
+ std r2,_CCR(r1)
ld r2,PACATOC(r13)
addi r9,r1,STACK_FRAME_OVERHEAD
ld r11,exception_marker@toc(r2)
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Andreas Schwab @ 2012-04-05 12:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1333401070.30734.55.camel__46349.1482347765$1333401169$gmane$org@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Hrm, odd.. I'll dbl check today that I didn't b0rk something in my test
> (like loading the wrong kernel :-) I'll also try with your config.
Do you have anything that triggers loading the sound drivers? That's
exactly the point where the irq problems start.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Andreas Schwab @ 2012-04-05 10:51 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120404154020.40C513E09D5@localhost>
Grant Likely <grant.likely@secretlab.ca> writes:
> I bet it is NR_IRQS related. You have SPARSE_IRQ enabled, which means
> the maximum number of irq_descs is IRQ_BITMAP_BITS (NR_IRQS + 8192).
The actual definition uses NR_IRQS + 8196. Guess that's a typo. (Does
it really make sense to add NR_IRQS here?)
> diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
> index cf417e51..9edf499 100644
> --- a/arch/powerpc/include/asm/irq.h
> +++ b/arch/powerpc/include/asm/irq.h
> @@ -20,7 +20,7 @@
>
> /* Define a way to iterate across irqs. */
> #define for_each_irq(i) \
> - for ((i) = 0; (i) < NR_IRQS; ++(i))
> + for ((i) = 0; (i) < nr_irqs; ++(i))
There are exactly two uses of for_each_irq, one is related to cpu
hotplug, the other to kexec, so that cannot make any difference.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH 4/4] powerpc: No need to preserve count register across system call
From: Anton Blanchard @ 2012-04-05 4:26 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120405142327.6038bbb4@kryten>
The count register is volatile so we don't need to preserve it.
Store zero to the entry in the exception frame.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/entry_64.S 2012-03-22 22:47:15.023504471 +1100
+++ linux-build/arch/powerpc/kernel/entry_64.S 2012-03-22 22:47:17.899556262 +1100
@@ -77,6 +77,7 @@ system_call_common:
std r11,GPR11(r1)
std r11,GPR12(r1)
std r11,_XER(r1)
+ std r11,_CTR(r1)
std r9,GPR13(r1)
mflr r10
li r11,0xc01
@@ -87,8 +88,6 @@ system_call_common:
rlwinm r2,r2,0,4,2
std r10,_LINK(r1)
std r11,_TRAP(r1)
- mfctr r10
- std r10,_CTR(r1)
std r3,ORIG_GPR3(r1)
std r2,_CCR(r1)
ld r2,PACATOC(r13)
^ permalink raw reply
* [PATCH 3/4] powerpc: Better scheduling of CR save code in system call path
From: Anton Blanchard @ 2012-04-05 4:25 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120405142327.6038bbb4@kryten>
At the moment system call entry looks like:
crclr so
...
mfcr r9
...
std r9,_CCR(r1)
commit bd19c8994a82 ([POWERPC] system call micro optimisation) put
some space between the crclr and mfcr in order to avoid a stall.
There is still a stall seen between the mfcr and std. We can avoid
the crclr by doing it in a GPR with rlwinm which gives us more room
to better schedule the sequence.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/entry_64.S 2012-03-22 22:47:08.379384827 +1100
+++ linux-build/arch/powerpc/kernel/entry_64.S 2012-03-22 22:47:15.023504471 +1100
@@ -63,15 +63,9 @@ system_call_common:
std r0,GPR0(r1)
std r10,GPR1(r1)
ACCOUNT_CPU_USER_ENTRY(r10, r11)
- /*
- * This "crclr so" clears CR0.SO, which is the error indication on
- * return from this system call. There must be no cmp instruction
- * between it and the "mfcr r9" below, otherwise if XER.SO is set,
- * CR0.SO will get set, causing all system calls to appear to fail.
- */
- crclr so
std r2,GPR2(r1)
std r3,GPR3(r1)
+ mfcr r2
std r4,GPR4(r1)
std r5,GPR5(r1)
std r6,GPR6(r1)
@@ -84,15 +78,19 @@ system_call_common:
std r11,GPR12(r1)
std r11,_XER(r1)
std r9,GPR13(r1)
- mfcr r9
mflr r10
li r11,0xc01
- std r9,_CCR(r1)
+ /*
+ * This clears CR0.SO, which is the error indication on return
+ * from this system call.
+ */
+ rlwinm r2,r2,0,4,2
std r10,_LINK(r1)
std r11,_TRAP(r1)
mfctr r10
std r10,_CTR(r1)
std r3,ORIG_GPR3(r1)
+ std r2,_CCR(r1)
ld r2,PACATOC(r13)
addi r9,r1,STACK_FRAME_OVERHEAD
ld r11,exception_marker@toc(r2)
^ permalink raw reply
* [PATCH 2/4] powerpc: No need to save XER in a system call
From: Anton Blanchard @ 2012-04-05 4:24 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120405142327.6038bbb4@kryten>
The XER is a volatile register so there is no need to save and restore
it over a system call - zero it out in the exception stack frame
instead.
This should fix a 5 cycle stall of the mfxer/std seen on POWER7.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/entry_64.S 2012-03-22 22:47:04.479314599 +1100
+++ linux-build/arch/powerpc/kernel/entry_64.S 2012-03-22 22:47:08.379384827 +1100
@@ -82,6 +82,7 @@ system_call_common:
std r11,GPR10(r1)
std r11,GPR11(r1)
std r11,GPR12(r1)
+ std r11,_XER(r1)
std r9,GPR13(r1)
mfcr r9
mflr r10
@@ -89,9 +90,7 @@ system_call_common:
std r9,_CCR(r1)
std r10,_LINK(r1)
std r11,_TRAP(r1)
- mfxer r9
mfctr r10
- std r9,_XER(r1)
std r10,_CTR(r1)
std r3,ORIG_GPR3(r1)
ld r2,PACATOC(r13)
^ permalink raw reply
* [PATCH 1/4] powerpc: Hide some system call labels from profile tools
From: Anton Blanchard @ 2012-04-05 4:23 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev
syscall_dotrace_cont and syscall_error_cont tend to complicate perf
output so make them local.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/entry_64.S 2012-03-22 22:41:21.209137690 +1100
+++ linux-build/arch/powerpc/kernel/entry_64.S 2012-03-22 22:47:04.479314599 +1100
@@ -154,7 +154,7 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLP
ld r10,TI_FLAGS(r11)
andi. r11,r10,_TIF_SYSCALL_T_OR_A
bne- syscall_dotrace
-syscall_dotrace_cont:
+.Lsyscall_dotrace_cont:
cmpldi 0,r0,NR_syscalls
bge- syscall_enosys
@@ -211,7 +211,7 @@ syscall_exit:
cmpld r3,r11
ld r5,_CCR(r1)
bge- syscall_error
-syscall_error_cont:
+.Lsyscall_error_cont:
ld r7,_NIP(r1)
BEGIN_FTR_SECTION
stdcx. r0,0,r1 /* to clear the reservation */
@@ -246,7 +246,7 @@ syscall_error:
oris r5,r5,0x1000 /* Set SO bit in CR */
neg r3,r3
std r5,_CCR(r1)
- b syscall_error_cont
+ b .Lsyscall_error_cont
/* Traced system call support */
syscall_dotrace:
@@ -268,7 +268,7 @@ syscall_dotrace:
addi r9,r1,STACK_FRAME_OVERHEAD
clrrdi r10,r1,THREAD_SHIFT
ld r10,TI_FLAGS(r10)
- b syscall_dotrace_cont
+ b .Lsyscall_dotrace_cont
syscall_enosys:
li r3,-ENOSYS
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: Geoff Levand @ 2012-04-05 3:44 UTC (permalink / raw)
To: Tony Breeds
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
LinuxPPC-dev
In-Reply-To: <20120403005558.GA9194@thor.bakeyournoodle.com>
On Tue, 2012-04-03 at 10:55 +1000, Tony Breeds wrote:
> Currently we build all board files regardless of the final zImage
> target. This is sub-optimal (in terms on compilation) and leads to
> problems in one platform needlessly causing failures for other
> platforms.
>
> Use the Kconfig variables to selectively construct this board files to
> build.
>
> +ifeq ($(CONFIG_PPC_PS3),y)
> +src-plat += ps3-head.S ps3-hvcall.S ps3.c
> +endif
PS3 part looks good.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Stephen Rothwell @ 2012-04-05 0:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, robert.karl.berger, Frank Svendsbøe
In-Reply-To: <20120404192101.2A558200243@gemini.denx.de>
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
On Wed, 04 Apr 2012 21:21:01 +0200 Wolfgang Denk <wd@denx.de> wrote:
>
> The kernel README says nothing about binutils requirements, the only
> tool related statement is "Make sure you have at least gcc 3.2
> available." Actually I doubt if gcc 3.2 wouldbuild a working kernel
> image.
>
> ELDK 4.2 is based on gcc version 4.2.2 / binutils version 2.17.50.0.12
> 20070128. This is obviously to old for this code. I do not see an
> actual problem with that - nobody can expect that we support old tol
> chain versions forever.
The requirements are documented in Documentation/Changes where we say we
need gcc 3.2 and binutils 2.12. Not that that is very relevant to this
discussion. ;-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH 3/4] powerpc/mpic: Move internal interrupt source vector allocation to a separate function.
From: Benjamin Herrenschmidt @ 2012-04-04 23:29 UTC (permalink / raw)
To: Sethi Varun-B16395; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D0B77F9@039-SN2MPN1-013.039d.mgd.msft.net>
On Wed, 2012-04-04 at 19:09 +0000, Sethi Varun-B16395 wrote:
> > I think that is more due to how you added the MPIC error interrupts
> and
> > issues w/that code. If you are treating the MPIC error interrupts
> as a
> > cascade than they should have a distinct linux IRQ space from the
> > standard MPIC interrupts. This is how the MSIs work (as an
> example).
> In case of error interrupts we are depending on the mpic_host_maps
> for mapping and interrupt specifier translations. There is no separate
> initialization as in case of MSIs. That's the reason I am treating
> error interrupts as mpic internal interrupt sources.
It makes sense to have an allocator for MPIC vectors but it should be a
single allocator shared with the MSI code.
Cheers,
Ben.
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Wolfgang Denk @ 2012-04-04 19:21 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, robert.karl.berger, Frank Svendsbøe
In-Reply-To: <CA+5PVA6jQgme0sS=i8yYX6b_R5179+BtWPh7QXCGNfoLTCt46A@mail.gmail.com>
Dear Josh,
In message <CA+5PVA6jQgme0sS=i8yYX6b_R5179+BtWPh7QXCGNfoLTCt46A@mail.gmail.com> you wrote:
>
> > The kernel shouldn't have tried to build that instruction on 8xx, though
> > I suppose if it's in arch/powerpc/boot, we are a bit too eager at
> > building everything including what's not relevant, we might to be a bit
> > more careful at excluding 4xx stuff on a 8xx kernel.
>
> It's still a binutils issue. Sounds like the toolchain being used to
> build the 8xx kernel is specifically built for 8xx. A generally built
> binutils should have worked fine (assuming it was new enough), since
> we pass -mcpu=405.
The problem is the "assuming it was new enough" part.
The kernel README says nothing about binutils requirements, the only
tool related statement is "Make sure you have at least gcc 3.2
available." Actually I doubt if gcc 3.2 wouldbuild a working kernel
image.
ELDK 4.2 is based on gcc version 4.2.2 / binutils version 2.17.50.0.12
20070128. This is obviously to old for this code. I do not see an
actual problem with that - nobody can expect that we support old tol
chain versions forever.
But then, I think if we make assumptions about tool versions, we
should add appropriate tests and issue helpful error messages. Here,
we should issue an error "binutils versions x.y.z or later needed" or
similar.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have made mistakes, but have never made the mistake of claiming I
never made one. - James G. Bennet
^ permalink raw reply
* RE: [PATCH 3/4] powerpc/mpic: Move internal interrupt source vector allocation to a separate function.
From: Sethi Varun-B16395 @ 2012-04-04 19:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BA2352CD-6C54-4D33-86DB-F55DBDBA6E5F@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Tuesday, March 27, 2012 7:32 PM
> To: Sethi Varun-B16395
> Cc: Linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 3/4] powerpc/mpic: Move internal interrupt source
> vector allocation to a separate function.
>=20
>=20
> On Mar 27, 2012, at 8:52 AM, Sethi Varun-B16395 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Tuesday, March 27, 2012 6:55 PM
> >> To: Sethi Varun-B16395
> >> Cc: Linuxppc-dev@lists.ozlabs.org
> >> Subject: Re: [PATCH 3/4] powerpc/mpic: Move internal interrupt source
> >> vector allocation to a separate function.
> >>
> >>
> >> On Mar 27, 2012, at 7:16 AM, Varun Sethi wrote:
> >>
> >>> Allocate vector numbers for MPIC internal interrupt sources (IPIs
> >>> and
> >>> Timers) in a separate function.
> >>>
> >>
> >> Explain why you are making this change.
> >
> >
> > [Sethi Varun-B16395] With the current code it becomes fairly difficult
> > to add new internal interrupt sources. In my case I had to add 32
> > additional interrupt sources corresponding to the MPIC error
> > interrupts. It's more convenient doing the internal interrupt source
> allocation using a loop.
>=20
> I think that is more due to how you added the MPIC error interrupts and
> issues w/that code. If you are treating the MPIC error interrupts as a
> cascade than they should have a distinct linux IRQ space from the
> standard MPIC interrupts. This is how the MSIs work (as an example).
In case of error interrupts we are depending on the mpic_host_maps
for mapping and interrupt specifier translations. There is no separate
initialization as in case of MSIs. That's the reason I am treating
error interrupts as mpic internal interrupt sources.
-Varun
^ permalink raw reply
* Re: 3.4.0-rc1: No init found
From: Christian Kujau @ 2012-04-04 16:45 UTC (permalink / raw)
To: Suzuki K. Poulose; +Cc: linuxppc-dev, LKML
In-Reply-To: <4F7C4058.6090405@in.ibm.com>
On Wed, 4 Apr 2012 at 18:06, Suzuki K. Poulose wrote:
> > INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
> > wrapper(0x400000)
> > INFO: Fixing the link_address of wrapper to (0x700000)
> > Building modules, stage 2.
> > MODPOST 24 modules
> > ------------
> >
> > I started to see these messages in January (around Linux 3.2.0), but never
> > investigated what it was since the produced kernels continued to boot just
> > fine.
>
> The above change was added by me. The message is printed when the 'wrapper'
> script finds that decompressed kernel overlaps the 'bootstrap code' which does
> the decompression. So it shifts the 'address' of the bootstrap code to the
> next higher MB. As such it is harmless.
OK, good to know that it's harmless. Thanks for the explanation.
Christian.
--
BOFH excuse #256:
You need to install an RTFM interface.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Grant Likely @ 2012-04-04 15:40 UTC (permalink / raw)
To: Andreas Schwab
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <m2y5qdow0v.fsf@igel.home>
On Tue, 03 Apr 2012 14:11:12 +0200, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Grant Likely <grant.likely@secretlab.ca> writes:
>
> > Can you dump out /debug/powerpc/virq_mapping from both before and
> > after the irq_map patch is applied?
>
> before:
> virq hwirq chip name chip data host name
> 16 0x00000 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 21 0x00001 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 24 0x00002 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 25 0x00019 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 26 0x0001a MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 27 0x0001b MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 28 0x0001c MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 29 0x0003d MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 30 0x0001e MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 31 0x0003c MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 39 0x00027 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 40 0x00028 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 41 0x00029 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 42 0x0002a MPIC 2 0xc00000017a011000 /u3@0,f8000000/mpic@f8040000
> 47 0x0002f MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 59 0x000fb MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 60 0x000fc MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 61 0x000fd MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 62 0x000fe MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 63 0x0003f MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
>
> after:
> virq hwirq chip name chip data host name
> 16 0x00000 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 21 0x00001 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 24 0x00002 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 25 0x00019 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 26 0x0001a MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 27 0x0001b MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 28 0x0001c MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 30 0x0001e MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 39 0x00027 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 40 0x00028 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 41 0x00029 MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 42 0x0002a MPIC 2 0xc00000017a011000 /u3@0,f8000000/mpic@f8040000
> 47 0x0002f MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 59 0x000fb MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 60 0x000fc MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 61 0x000fd MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 62 0x000fe MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 63 0x0003f MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 64 0x0003d MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
> 65 0x0003c MPIC 1 0xc00000017a010000 /ht@0,f2000000/pci@1/mac-io@7/mpic@40000
>
> But I have NR_IRQS=64. Bounds checking missing? Irqs 64/65 are related
> to the sound chip (headphone-detect and line-out-detect).
I bet it is NR_IRQS related. You have SPARSE_IRQ enabled, which means
the maximum number of irq_descs is IRQ_BITMAP_BITS (NR_IRQS + 8192).
The old powerpc code was strictly limited to NR_IRQS, but the new code
uses irq_alloc_descs() which isn't. Yet I can see places in the
powerpc code that depends specifically on the value of NR_IRQS. The
for_each_irq() macro for instance. I think all the users there can be
switched to using for_each_irq_desc().
Can you attach console output logs for each of configs above and also
with NR_IRQS=128? That might give me some clues as to which specific
code is causing the issues. Also, as a quick test, try changing
for_each_irq_desc() to use "nr_irqs" instead of "NR_IRQS". nr_irqs is
kept up to date with the real maximum number of irqs allocated in the
system:
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index cf417e51..9edf499 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -20,7 +20,7 @@
/* Define a way to iterate across irqs. */
#define for_each_irq(i) \
- for ((i) = 0; (i) < NR_IRQS; ++(i))
+ for ((i) = 0; (i) < nr_irqs; ++(i))
extern atomic_t ppc_n_lost_interrupts;
g.
>
> When reconfiguring with NR_IRQS=128 interrupts are working again, but I
> still see a lot of spurious interrupts, and the X server is still broken
> (no input works, but I still don't know whether that is an unrelated
> bug).
>
> This is a sample of /proc/interrupts from 3.3 (with NR_IRQS=64):
> CPU0 CPU1
> 16: 2039 6070 MPIC 1 Level sata_svw
> 21: 0 0 MPIC 1 Edge i2sbus: i2s-a (tx)
> 22: 12 20 MPIC 1 Level
> 23: 14 18 MPIC 1 Level
> 24: 0 0 MPIC 1 Edge i2sbus: i2s-a (rx)
> 25: 3 0 MPIC 1 Level VIA-PMU
> 26: 16 62 MPIC 1 Level keywest i2c
> 27: 0 1 MPIC 1 Level ohci_hcd:usb2
> 28: 0 1 MPIC 1 Level ohci_hcd:usb3
> 29: 0 0 MPIC 1 Edge headphone-detect
> 30: 0 0 MPIC 1 Level i2sbus: i2s-a (control)
> 31: 0 0 MPIC 1 Edge line-output-detect
> 39: 22 64 MPIC 1 Level pata-pci-macio
> 40: 0 2 MPIC 1 Level firewire_ohci
> 41: 52 147 MPIC 1 Level eth0
> 42: 1732 5053 MPIC 2 Level keywest i2c
> 47: 0 0 MPIC 1 Level GPIO1 ADB
> 59: 0 0 MPIC 1 Edge ipi call function
> 60: 2064 1940 MPIC 1 Edge ipi reschedule
> 61: 3406 945 MPIC 1 Edge ipi call function single
> 62: 0 0 MPIC 1 Edge ipi debugger
> 63: 39 91 MPIC 1 Level ehci_hcd:usb1, ohci_hcd:usb4, ohci_hcd:usb5
> LOC: 3503 3719 Local timer interrupts
> SPU: 2 0 Spurious interrupts
> CNT: 0 0 Performance monitoring interrupts
> MCE: 0 0 Machine check exceptions
>
> This is a sample of /proc/interrupts from 3.4-rc1 (with NR_IRQS=128):
> CPU0 CPU1
> 16: 2603 7596 MPIC 1 Level sata_svw
> 21: 1 0 MPIC 1 Edge i2sbus: i2s-a (tx)
> 22: 13 19 MPIC 1 Level
> 23: 8 24 MPIC 1 Level
> 24: 0 1 MPIC 1 Edge i2sbus: i2s-a (rx)
> 25: 2 1 MPIC 1 Level VIA-PMU
> 26: 21 57 MPIC 1 Level keywest i2c
> 27: 0 1 MPIC 1 Level ohci_hcd:usb2
> 28: 0 1 MPIC 1 Level ohci_hcd:usb3
> 30: 0 0 MPIC 1 Level i2sbus: i2s-a (control)
> 39: 39 131 MPIC 1 Level pata-pci-macio
> 40: 2 2 MPIC 1 Level firewire_ohci
> 41: 93 268 MPIC 1 Level eth0
> 42: 8569 24140 MPIC 2 Level keywest i2c
> 47: 0 0 MPIC 1 Level GPIO1 ADB
> 60: 1 0 MPIC 1 Edge line-output-detect
> 61: 1 0 MPIC 1 Edge headphone-detect
> 63: 153 502 MPIC 1 Level ehci_hcd:usb1, ohci_hcd:usb4, ohci_hcd:usb5
> 123: 0 0 MPIC 1 Edge ipi call function
> 124: 1978 2349 MPIC 1 Edge ipi reschedule
> 125: 2356 1816 MPIC 1 Edge ipi call function single
> 126: 0 0 MPIC 1 Edge ipi debugger
> LOC: 4417 7985 Local timer interrupts
> SPU: 9586 25811 Spurious interrupts
> CNT: 0 0 Performance monitoring interrupts
> MCE: 0 0 Machine check exceptions
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
^ permalink raw reply related
* Re: [alsa-devel] [PATCH] powerpc: select PPC_CLOCK unconditionally for FSL_SOC
From: Shawn Guo @ 2012-04-04 15:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: alsa-devel, linuxppc-dev, Timur Tabi
In-Reply-To: <9F34EEF5-830B-4115-8BB0-DE9FF794BDB9@kernel.crashing.org>
On 4 April 2012 23:00, Kumar Gala <galak@kernel.crashing.org> wrote:
...
> What timeframe are you looking for this to go in? 3.4 or 3.5?
>
3.5
Thanks,
Shawn
^ permalink raw reply
* Re: [PATCH] powerpc: select PPC_CLOCK unconditionally for FSL_SOC
From: Kumar Gala @ 2012-04-04 15:00 UTC (permalink / raw)
To: Shawn Guo; +Cc: alsa-devel, linuxppc-dev, Timur Tabi
In-Reply-To: <20120404133246.GA25168@S2101-09.ap.freescale.net>
On Apr 4, 2012, at 8:32 AM, Shawn Guo wrote:
> Kumar,
>
> Gentle ping ...
>
> Regards,
> Shawn
Was on a bit of travel to nowhere, but that's a different story.
What timeframe are you looking for this to go in? 3.4 or 3.5?
- k
>
> On Fri, Mar 30, 2012 at 01:38:56PM +0800, Shawn Guo wrote:
>> Freescale PowerPC SoCs share a number of IP blocks with Freescale
>> ARM/IMX SoCs, FlexCAN, SSI, FEC, eSDHC, USB, etc. There are some
>> effort consolidating those drivers to make them work for both
>> architectures.
>>
>> One outstanding difference between two architectures is ARM/IMX will
>> turn off module clocks during platform initialization for power saving
>> and expects drivers manage clocks using clk API, while PowerPC
>> mostly does not do that, and thus does not always build in clk API.
>>
>> Listing all those driver Kconfig options in "select PPC_CLOCK if" seems
>> not scalable for long term maintenance, and could easily introduce
>> Kconfig recursive dependency. This patch chooses to select PPC_CLOCK
>> unconditionally for FSL_SOC to always build clk API for PowerPC in.
>>
>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>> ---
>> arch/powerpc/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index feab3ba..63fa7fb 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -661,7 +661,7 @@ config SBUS
>> config FSL_SOC
>> bool
>> select HAVE_CAN_FLEXCAN if NET && CAN
>> - select PPC_CLOCK if CAN_FLEXCAN
>> + select PPC_CLOCK
>>
>> config FSL_PCI
>> bool
>> --
>> 1.7.5.4
>>
^ permalink raw reply
* Re: [PATCH] powerpc: select PPC_CLOCK unconditionally for FSL_SOC
From: Shawn Guo @ 2012-04-04 13:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: alsa-devel, linuxppc-dev, Timur Tabi
In-Reply-To: <1333085936-8977-1-git-send-email-shawn.guo@linaro.org>
Kumar,
Gentle ping ...
Regards,
Shawn
On Fri, Mar 30, 2012 at 01:38:56PM +0800, Shawn Guo wrote:
> Freescale PowerPC SoCs share a number of IP blocks with Freescale
> ARM/IMX SoCs, FlexCAN, SSI, FEC, eSDHC, USB, etc. There are some
> effort consolidating those drivers to make them work for both
> architectures.
>
> One outstanding difference between two architectures is ARM/IMX will
> turn off module clocks during platform initialization for power saving
> and expects drivers manage clocks using clk API, while PowerPC
> mostly does not do that, and thus does not always build in clk API.
>
> Listing all those driver Kconfig options in "select PPC_CLOCK if" seems
> not scalable for long term maintenance, and could easily introduce
> Kconfig recursive dependency. This patch chooses to select PPC_CLOCK
> unconditionally for FSL_SOC to always build clk API for PowerPC in.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> arch/powerpc/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index feab3ba..63fa7fb 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -661,7 +661,7 @@ config SBUS
> config FSL_SOC
> bool
> select HAVE_CAN_FLEXCAN if NET && CAN
> - select PPC_CLOCK if CAN_FLEXCAN
> + select PPC_CLOCK
>
> config FSL_PCI
> bool
> --
> 1.7.5.4
>
^ permalink raw reply
* Re: [RFC] powerpc/fsl-pci: Document the "fsl, has-isa" property for Freescale PCI
From: Kumar Gala @ 2012-04-04 13:08 UTC (permalink / raw)
To: Jia Hongtao; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <1333263396-23932-1-git-send-email-B38951@freescale.com>
On Apr 1, 2012, at 1:56 AM, Jia Hongtao wrote:
> If PCI is primary bus we should set isa_io/mem_base when parsing PCI =
bridge
> resources from device tree. The previous way to check the primary bus =
based
> on a hard-coded address named primary_phb_addr. Now we add a property =
named
> "fsl,has-isa" into device tree. In kernel we use this property to find =
out
> the bus is primary or not. This way is more flexible.
>=20
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/pci.txt | 36 =
++++++++++++++++++++
> 1 files changed, 36 insertions(+), 0 deletions(-)
> create mode 100644 =
Documentation/devicetree/bindings/powerpc/fsl/pci.txt
This isn't freescale specific, its linux specific. If anything the =
property should be linux,has-isa.
But in general I dont think this is a good idea. In truth one could =
search the device tree for:
device_type =3D "isa";
to try and set this dynamically.
- k
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Andreas Schwab @ 2012-04-04 12:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, linux-kernel, Rob Herring, Milton Miller,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1333489422.3040.11.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Do you see a relevant difference in the X log ?
Nothing at all.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: 3.4.0-rc1: No init found
From: Suzuki K. Poulose @ 2012-04-04 12:36 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML, Al Viro
In-Reply-To: <alpine.DEB.2.01.1204030953320.4930@trent.utfs.org>
On 04/03/2012 10:48 PM, Christian Kujau wrote:
> On Tue, 3 Apr 2012 at 18:08, Benjamin Herrenschmidt wrote:
>> I have observed this randomly on the G5 ... sometimes, if I try again,
>> it works... it's very very odd. There is some kind of race maybe with
>> async startup ? Or a problem with the vfs path walking ? It's certainly
>> not easily reproducable for me, it goes away from one boot to the next.
>
> It's 100% reproducible for me. This PowerBook G4 (1.25Ghz) is not the
> fastes though, maybe a race triggers more easily here...?
>
>>> PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
>>> right now (which is still installed via "yaboot" and present in
>>> /boot), because of this:
>>> http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
>>> Booting into Debian's "squeeze" kernel (2.6.32) which resides in
>>> the same /boot directory succeeds.
>>
>> Hrm, did it used to boot ?
>
> I'm using the "backup" kernel only when the new one has an issue, so I
> have not tested it for a while, but it used to work, for sure.
>
>> Can you do printenv in OF and tell me what
>> your load-base, real-base, virt-base etc... are ?
>
> load-base is 0x800000, real-base and virt-base is set to "-1", please see
> http://nerdbynature.de/bits/3.4.0-rc1/init/printenv-1.JPG
>
> Not sure if this is related, but at the end of each kernel compilation,
> the following messages are printed:
>
> ------------
> SYSMAP System.map
> SYSMAP .tmp_System.map
> WRAP arch/powerpc/boot/zImage.pmac
> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> WRAP arch/powerpc/boot/zImage.coff
> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x500000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> WRAP arch/powerpc/boot/zImage.miboot
> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> Building modules, stage 2.
> MODPOST 24 modules
> ------------
>
> I started to see these messages in January (around Linux 3.2.0), but never
> investigated what it was since the produced kernels continued to boot just
> fine.
The above change was added by me. The message is printed when the
'wrapper' script finds that decompressed kernel overlaps the 'bootstrap
code' which does the decompression. So it shifts the 'address' of the
bootstrap code to the next higher MB. As such it is harmless.
Thanks
Suzuki
^ permalink raw reply
* [PATCH 1/1] dts:bluestone: Add support 2 SATA ports
From: Thang Q. Nguyen @ 2012-04-04 8:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Vinh Nguyen Huu Tuong,
Josh Boyer
Cc: linux-kernel, linuxppc-dev, Thang Q. Nguyen
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
Adding 2 SATA nodes on Bluestone device tree file.
Signed-off-by: Thang Q. Nguyen <tqnguyen@apm.com>
---
arch/powerpc/boot/dts/bluestone.dts | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index cfa23bf..803fda6 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -155,6 +155,27 @@
/*RXDE*/ 0x5 0x4>;
};
+ /* SATA DWC devices */
+ SATA0: sata@bffd1000 {
+ compatible = "amcc,sata-apm821xx";
+ reg = <4 0xbffd1000 0x800 /* SATA0 */
+ 4 0xbffd0800 0x400>; /* AHBDMA */
+ dma-channel=<0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <26 4 /* SATA0 */
+ 25 4>; /* AHBDMA */
+ };
+
+ SATA1: sata@bffd1800 {
+ compatible = "amcc,sata-apm821xx";
+ reg = <4 0xbffd1800 0x800 /* SATA1 */
+ 4 0xbffd0800 0x400>; /* AHBDMA */
+ dma-channel=<1>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <27 4 /* SATA1 */
+ 25 4>; /* AHBDMA */
+ };
+
POB0: opb {
compatible = "ibm,opb";
#address-cells = <1>;
--
1.7.3.4
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries.
It is to be used solely for the purpose of furthering the parties' business relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.
^ 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