* Re: [PATCH] missing refcounting of of_find_node_by_name users
From: Olaf Hering @ 2006-02-07 10:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17384.31565.896220.384684@cargo.ozlabs.ibm.com>
On Tue, Feb 07, Paul Mackeras wrote:
> This one isn't necessary, since np is NULL by the time we get out of
> the loop. Same applies to the other places in this file that this
> patch affects.
Ok.
> > Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
> > ===================================================================
> > --- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/pci.c
> > +++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
> > @@ -695,6 +695,7 @@ static void __init fixup_nec_usb2(void)
> > nec->intrs[0].line);
> > }
> > }
> > + of_put_node(nec);
>
> Once again, nec is NULL by the time we get here. And of_put_node
> doesn't exist. :( Did you compile-test this?
Only with a pegasos only config, which doesnt cover these files.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: merge these lists?
From: Christoph Hellwig @ 2006-02-07 10:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17384.5875.790692.127762@cargo.ozlabs.ibm.com>
On Tue, Feb 07, 2006 at 02:41:39PM +1100, Paul Mackerras wrote:
> A lot of messages seem to get cross-posted to both linuxppc-dev and
> linuxppc64-dev these days, since we are all working in the one tree.
> Rather than having to cross-post, I propose that we create a single
> powerpc-dev@ozlabs.org list to replace linuxppc-dev and
> linuxppc64-dev. (The linuxppc-embedded list would continue as at
> present.)
Why not just kill linuxppc64-dev and leave linuxppc-dev? Probably not
worth to remove the well-known and widely used address just for the
sake of it.
^ permalink raw reply
* Re: [PATCH] missing refcounting of of_find_node_by_name users
From: Paul Mackerras @ 2006-02-07 10:49 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060204122013.GA20324@suse.de>
Olaf Hering writes:
> drop the refcount of the node returned from of_find_node_by_name
[snip]
> --- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/feature.c
> +++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/feature.c
> @@ -2772,6 +2772,7 @@ set_initial_features(void)
> g5_gmac_enable(np, 0, 1);
> np = of_find_node_by_name(np, "ethernet");
> }
> + of_node_put(np);
This one isn't necessary, since np is NULL by the time we get out of
the loop. Same applies to the other places in this file that this
patch affects.
> Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
> ===================================================================
> --- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/pci.c
> +++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
> @@ -695,6 +695,7 @@ static void __init fixup_nec_usb2(void)
> nec->intrs[0].line);
> }
> }
> + of_put_node(nec);
Once again, nec is NULL by the time we get here. And of_put_node
doesn't exist. :( Did you compile-test this?
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Kernel FP unavail exception for BookE
From: Paul Mackerras @ 2006-02-07 10:30 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, galak
In-Reply-To: <Pine.LNX.4.61.0601311746250.18350@cde-tx32-ldt329.sps.mot.com>
Becky Bruce writes:
> powerpc: Correct BookE FP unavailable exception
...
> diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
Ummm... which tree has head_booke.h?
Paul.
^ permalink raw reply
* RE: Floating point math in kernel interrupt -- am I doing thisright?(repost)
From: Josu Onandia @ 2006-02-07 9:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
In the RTAI scheduler there are routines (save_fpenv, restore_fpenv) =
that are very similar to your functions. I'd suggest to look in more =
detail if there are any subtle difference.
I think also that Sylvain can be right about the stack, so it could be a =
good idea to place saved_fpr in static storage, not in the stack.
My 2 cents
Josu
-----Mensaje original-----
De: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org]En nombre de Joyeau Sylvain
Enviado el: martes, 07 de febrero de 2006 8:20
Para: Jeremy Friesner
CC: linuxppc-embedded@ozlabs.org
Asunto: RE: Floating point math in kernel interrupt -- am I doing
thisright?(repost)
Jeremy,
What about kernel stack overflow ?
You mention that the occurrence of the crash is proportional to the =
amount of embraced code, which generally use more stack space too... but =
you aren't very accurate about the call context of your DoMix() =
function: it can be called depth enough to tickle the interrupted thread =
control block and issue indirect spurious behavior is userland.
Hope this help.
--
sj
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Jeremy =
Friesner
> Sent: lundi 6 f=E9vrier 2006 17:55
> To: Dan Malek
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Floating point math in kernel interrupt -- am I doing =
this right?(repost)
>=20
> >
> > On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
> >
> > > .... and the mixing is done inside an
> > > interrupt routine that runs 6000 times per second, and calculates =
8
> > > samples
> > > per interrupt.
> >
> > Bad news. No Floating Point allowed in the kernel.
>=20
> I'm aware of that rule, and also why -- because the Linux kernel =
doesn't want to have to save and restore the state of the
> floating point registers on every context switch. I'm also aware that =
it is nonetheless possible to use floating point in
> the kernel if you are careful to manually save and restore the proper =
state yourself, and that in fact floating point is
> sometimes used in the kernel as a means of doing 64-bit writes, as =
mentioned here:
>=20
> http://www.tldp.org/LDP/cpg/html/x295.html
>=20
> So it seems to me that it is possible to do floating point in the =
kernel, if you are careful to save and restore the proper
> context/state before and afterwards. But if it isn't, can you explain =
to me why it can't be made to work?
>=20
> > > In order to do the necessary floating point math, without =
corrupting
> > > the state
> > > of any other processes that might be using the FPU, the interrupt
> > > routine
> > > first saves the state of the FPU registers to the stack, then does =
the
> > > math,
> > > then restores FPU registers again, before returning.
> >
> > Not on 82xx. All floating point is done in hardware.
>=20
> Right; it is the hardware registers' state that I am saving to the =
stack, and then restoring afterwards.
>=20
> > > So my question is, is there some minor detail that my
> > > FPU-state-save/restore
> > > code is missing, that would cause these sort of symptoms?
> >
> > Just get all of this out of the kernel. If you used the standard =
ALSA
> > drivers and framework, lots of mixing features are available to you.
> > If you need some custom mixing, just write a plug-in to do it.
> > Your data rates are so low they don't justify making any hacks
> > like this.
>=20
> I suppose that is an option, but I'd rather understand why my hack =
isn't working before I give up and redesign my
> application, which is already working the way I want it to, 99.9999% =
of the time.
>=20
> Jeremy
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Floating point math in kernel interrupt -- am I doing this right?(repost)
From: Joyeau Sylvain @ 2006-02-07 7:20 UTC (permalink / raw)
To: Jeremy Friesner; +Cc: linuxppc-embedded
Jeremy,
What about kernel stack overflow ?
You mention that the occurrence of the crash is proportional to the =
amount of embraced code, which generally use more stack space too... but =
you aren't very accurate about the call context of your DoMix() =
function: it can be called depth enough to tickle the interrupted thread =
control block and issue indirect spurious behavior is userland.
Hope this help.
--
sj
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Jeremy =
Friesner
> Sent: lundi 6 f=E9vrier 2006 17:55
> To: Dan Malek
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Floating point math in kernel interrupt -- am I doing =
this right?(repost)
>=20
> >
> > On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
> >
> > > .... and the mixing is done inside an
> > > interrupt routine that runs 6000 times per second, and calculates =
8
> > > samples
> > > per interrupt.
> >
> > Bad news. No Floating Point allowed in the kernel.
>=20
> I'm aware of that rule, and also why -- because the Linux kernel =
doesn't want to have to save and restore the state of the
> floating point registers on every context switch. I'm also aware that =
it is nonetheless possible to use floating point in
> the kernel if you are careful to manually save and restore the proper =
state yourself, and that in fact floating point is
> sometimes used in the kernel as a means of doing 64-bit writes, as =
mentioned here:
>=20
> http://www.tldp.org/LDP/cpg/html/x295.html
>=20
> So it seems to me that it is possible to do floating point in the =
kernel, if you are careful to save and restore the proper
> context/state before and afterwards. But if it isn't, can you explain =
to me why it can't be made to work?
>=20
> > > In order to do the necessary floating point math, without =
corrupting
> > > the state
> > > of any other processes that might be using the FPU, the interrupt
> > > routine
> > > first saves the state of the FPU registers to the stack, then does =
the
> > > math,
> > > then restores FPU registers again, before returning.
> >
> > Not on 82xx. All floating point is done in hardware.
>=20
> Right; it is the hardware registers' state that I am saving to the =
stack, and then restoring afterwards.
>=20
> > > So my question is, is there some minor detail that my
> > > FPU-state-save/restore
> > > code is missing, that would cause these sort of symptoms?
> >
> > Just get all of this out of the kernel. If you used the standard =
ALSA
> > drivers and framework, lots of mixing features are available to you.
> > If you need some custom mixing, just write a plug-in to do it.
> > Your data rates are so low they don't justify making any hacks
> > like this.
>=20
> I suppose that is an option, but I'd rather understand why my hack =
isn't working before I give up and redesign my
> application, which is already working the way I want it to, 99.9999% =
of the time.
>=20
> Jeremy
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: merge these lists?
From: Michael Ellerman @ 2006-02-07 4:29 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev
In-Reply-To: <20060207041243.GC7626@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]
On Tue, 7 Feb 2006 15:12, Olof Johansson wrote:
> On Tue, Feb 07, 2006 at 02:45:45PM +1100, Jeremy Kerr wrote:
> > Paul,
> >
> > > If we do this, we would set up the new list with the union of the
> > > subscribers of the old lists, and make emails sent to linuxppc-dev
> > > and linuxppc64-dev go to the new list, so it should be painless.
> > >
> > > Thoughts? Comments? Objections?
> >
> > How about the patchwork lists? Should I look at merging those too?
>
> I get a feeling that our maintainers might not be using them much any
> more (most patches since August of last year are still "New"), but I
> find it convenient to search for a patch that you know has gone by but
> can't find in your list mbox.
>
> I would appreciate either a merge, or a new archive started for the new
> list. It's useful.
And while Jk has nothing else to do .. I'd like to be able to managed my own
patches, ie. set them as obsolete etc etc.
Oh and yeah I think we should merge the lists :D
cheers
--
Michael Ellerman
IBM OzLabs
email: michael:ellerman.id.au
inmsg: mpe:jabber.org
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: merge these lists?
From: Olof Johansson @ 2006-02-07 4:12 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <200602071445.45805.jk@ozlabs.org>
On Tue, Feb 07, 2006 at 02:45:45PM +1100, Jeremy Kerr wrote:
> Paul,
>
> > If we do this, we would set up the new list with the union of the
> > subscribers of the old lists, and make emails sent to linuxppc-dev
> > and linuxppc64-dev go to the new list, so it should be painless.
> >
> > Thoughts? Comments? Objections?
>
> How about the patchwork lists? Should I look at merging those too?
I get a feeling that our maintainers might not be using them much any
more (most patches since August of last year are still "New"), but I
find it convenient to search for a patch that you know has gone by but
can't find in your list mbox.
I would appreciate either a merge, or a new archive started for the new
list. It's useful.
-Olof
^ permalink raw reply
* Re: merge these lists?
From: Jeremy Kerr @ 2006-02-07 3:45 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev
In-Reply-To: <17384.5875.790692.127762@cargo.ozlabs.ibm.com>
Paul,
> If we do this, we would set up the new list with the union of the
> subscribers of the old lists, and make emails sent to linuxppc-dev
> and linuxppc64-dev go to the new list, so it should be painless.
>
> Thoughts? Comments? Objections?
How about the patchwork lists? Should I look at merging those too?
Jeremy
^ permalink raw reply
* merge these lists?
From: Paul Mackerras @ 2006-02-07 3:41 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
A lot of messages seem to get cross-posted to both linuxppc-dev and
linuxppc64-dev these days, since we are all working in the one tree.
Rather than having to cross-post, I propose that we create a single
powerpc-dev@ozlabs.org list to replace linuxppc-dev and
linuxppc64-dev. (The linuxppc-embedded list would continue as at
present.)
If we do this, we would set up the new list with the union of the
subscribers of the old lists, and make emails sent to linuxppc-dev and
linuxppc64-dev go to the new list, so it should be painless.
Thoughts? Comments? Objections?
Paul.
^ permalink raw reply
* Common Flash Interface v1.4 and MTD support in Linux-2.4.4 kernel
From: David Antliff @ 2006-02-07 3:33 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Just to be clear, this email is related to work that I do for a
commercial enterprise, however I am writing on behalf of myself.
I am working on an MPC852 embedded platform based on the Denx
Linux-2.4.4 port.
We have an existing device with a fixed-flash (AMD-type) conforming to
CFI (Common Flash Interface) version 1.2. Linux-2.4.4 supports this
device when used by the Memory Tech Device Driver (MTD). This device has
a single region ('plane'?) or at least constant geometry across the
device. MTD in 2.4.4 has no problems dividing this up into a bunch of
block devices (partitions for read-only filesystems).
A newer version has a different flash chip - an Intel P30 flash with
multiple regions - it has two types of geometries as it is configured
for 'boot' operation. It also conforms to CFI version 1.4. Unfortunately
the Linux-2.4.4 MTD driver rejects this as unsupported based on CFI
version and hard-coding it in "kinda" works - the partition devices are
readable but the driver complains bitterly about non-alignment with
erase blocks. I suspect the driver is picking up parameters from the
first region (which covers the first set of blocks) and trying to use
this across the device. One thing I don't understand yet - as the first
region uses block sizes that are an integer division of those in the
second region I'm not sure why the boundaries don't align when I am
using the 2nd-region block size to define the partition boundaries.
What I am looking for is some advice please - what do you think is the
best course of action in this situation?
There will be others but so far I am considering:
1. back-port the CFI code from a newer 2.4 kernel to support CFI v1.4.
- does anybody know the state of MTD in later versions? What would be a
good version to source from?
2. integrate code found here and try and understand how it works:
http://lists.infradead.org/pipermail/linux-mtd/2001-November/003645.html
3. unfortunately upgrading the entire kernel is not an option at this
stage, unless absolutely necessary.
What would you suggest? Yes, I am happy for a 'quick fix' but if there
isn't one or it's too risky I am willing to invest the time in doing it
right.
Thank you,
David Antliff
Stratex Networks Ltd.
New Zealand
^ permalink raw reply
* List etiquette
From: David Antliff @ 2006-02-07 2:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
Hello,
I'm a new subscriber to this list and looking to ask a specific question
shortly. However I would like to bring two things up based on this page:
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
1. The list rules and posting guidelines URLs are out of service:
- http://lists.linuxppc.org/rules.html
- http://lists.linuxppc.org/guidelines.html
2. There is a recommendation to look for answers to questions in the
list archives. There does not seem to be any way to search these, except
with Google site: syntax. Am I missing something here?
Regards,
David
[-- Attachment #2: Type: text/html, Size: 1207 bytes --]
^ permalink raw reply
* [PATCH] powerpc: wire up the *at system calls
From: Stephen Rothwell @ 2006-02-06 23:59 UTC (permalink / raw)
To: paulus; +Cc: Andrew Morton, LKML, ppc-dev, Linus, ppc64-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/systbl.S | 13 +++++++++++++
include/asm-powerpc/unistd.h | 15 ++++++++++++++-
2 files changed, 27 insertions(+), 1 deletions(-)
This depend on the patch that creates all the compat wrappers.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
d02d8208813d8cae2c814a85734a1a31fed2f3ac
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 007b15e..fe16d9c 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -323,3 +323,16 @@ SYSCALL(spu_run)
SYSCALL(spu_create)
COMPAT_SYS(pselect6)
COMPAT_SYS(ppoll)
+COMPAT_SYS(openat)
+COMPAT_SYS(mkdirat)
+COMPAT_SYS(mknodat)
+COMPAT_SYS(fchownat)
+COMPAT_SYS(futimesat)
+COMPAT_SYS(newfstatat)
+COMPAT_SYS(unlinkat)
+COMPAT_SYS(renameat)
+COMPAT_SYS(linkat)
+COMPAT_SYS(symlinkat)
+COMPAT_SYS(readlinkat)
+COMPAT_SYS(fchmodat)
+COMPAT_SYS(faccessat)
diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
index a40cdff..d05b85e 100644
--- a/include/asm-powerpc/unistd.h
+++ b/include/asm-powerpc/unistd.h
@@ -300,8 +300,21 @@
#define __NR_spu_create 279
#define __NR_pselect6 280
#define __NR_ppoll 281
+#define __NR_openat 282
+#define __NR_mkdirat 283
+#define __NR_mknodat 284
+#define __NR_fchownat 285
+#define __NR_futimesat 286
+#define __NR_newfstatat 287
+#define __NR_unlinkat 288
+#define __NR_renameat 289
+#define __NR_linkat 290
+#define __NR_symlinkat 291
+#define __NR_readlinkat 292
+#define __NR_fchmodat 293
+#define __NR_faccessat 294
-#define __NR_syscalls 282
+#define __NR_syscalls 295
#ifdef __KERNEL__
#define __NR__exit __NR_exit
--
1.1.5
^ permalink raw reply related
* [PATCH] documentation: add bus-frequency property to SOC node
From: Becky Bruce @ 2006-02-06 20:26 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
Updated SOC node definition in documentation to include bus-frequency
property. Also extended mdio example to match specification.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <galak@gate.crashing.org>
---
commit 3441bf59c7e1dc3823f9be57838a2536c78f6f8f
tree 2901a0e19418f1fe904ff0d041c630b3af048961
parent 66c490c9b00c52cd0f1e088ad689c9148e46f49e
author Becky Bruce <becky.bruce@freescale.com> Thu, 02 Feb 2006 15:41:11 -0600
committer Becky Bruce <becky.bruce@freescale.com> Thu, 02 Feb 2006 15:41:11 -0600
Documentation/powerpc/booting-without-of.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 1284498..54e5f9b 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -880,6 +880,10 @@ address which can extend beyond that lim
- device_type : Should be "soc"
- ranges : Should be defined as specified in 1) to describe the
translation of SOC addresses for memory mapped SOC registers.
+ - bus-frequency: Contains the bus frequency for the SOC node.
+ Typically, the value of this field is filled in by the boot
+ loader.
+
Recommended properties:
@@ -919,6 +923,7 @@ SOC.
device_type = "soc";
ranges = <00000000 e0000000 00100000>
reg = <e0000000 00003000>;
+ bus-frequency = <0>;
}
@@ -1170,6 +1175,8 @@ platforms are moved over to use the flat
mdio@24520 {
reg = <24520 20>;
+ device_type = "mdio";
+ compatible = "gianfar";
ethernet-phy@0 {
......
@@ -1317,6 +1324,7 @@ not necessary as they are usually the sa
device_type = "soc";
ranges = <00000000 e0000000 00100000>
reg = <e0000000 00003000>;
+ bus-frequency = <0>;
mdio@24520 {
reg = <24520 20>;
^ permalink raw reply related
* Re: Yosemite/440EP PLB4 vs PLB3 DMA to PCI issue
From: David Hawkins @ 2006-02-06 19:09 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602061931.25370.sr@denx.de>
Hi Stefan,
> I never used DMA on 440EP/GP till now so I just noticed the two different
> PLB's and their DMA controllers. Never seen this on any 4xx PPC so far. I
> suspect that the PLB4 is integrated mainly because of the USB interface.
That sounds about right. In my app I won't be using USB, and since the
PLB4 DMA controller has larger DMA buffers, I thought it might have an
edge over the PLB3 controller.
> What version of the user manual are you referring to? Could you please give
> the pages for the current manual (Revision 1.18).
Oh, sorry, I was looking at the version 1.14 manual. I've just
downloaded the 1.18 manual. Whoa! The 1.14 manual has 1696 pages,
whereas the 1.18 manual has only 794 - I hope that means things
have got simpler ;)
(nope, looks like the 440 core just got moved into another document)
Anyways, here are the v1.18 page references;
v1.18 p365-6 has the PLB-to-PCI Transaction Handling section
showing the cases where MRL and MRM will be used.
v1.18 p407 has the PCI Memory to SDRAM DMA transfer section
with comments and forward references to the timing
diagram pages.
>>(I hope you had a nice vacation Stefan!)
>
> Thanks. Very nice. One week of sunshine in the snow. :-)
I hope that means you got some nice snowboarding or skiing!
We have a fun mountain just up the road;
http://www.mammothmountain.com/
Feel free to come and visit if you are in California anytime!
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP PLB4 vs PLB3 DMA to PCI issue
From: Stefan Roese @ 2006-02-06 18:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43E68E85.3080100@ovro.caltech.edu>
Hi David,
I never used DMA on 440EP/GP till now so I just noticed the two different
PLB's and their DMA controllers. Never seen this on any 4xx PPC so far. I
suspect that the PLB4 is integrated mainly because of the USB interface.
On Monday 06 February 2006 00:47, David Hawkins wrote:
> I took a look at the 440EP user manual, and I haven't been
> able to explain the PLB4 DMA controller observations.
>
> Here's what I've got so far;
>
> p595: PLB-to-PCI transaction handling
> Shows the two situations where the PCI bridge will
> generate memory-read-line (MRL) and memory-read-multiple (MRM)
What version of the user manual are you referring to? Could you please give
the pages for the current manual (Revision 1.18).
<snip>
> (I hope you had a nice vacation Stefan!)
Thanks. Very nice. One week of sunshine in the snow. :-)
Ciao,
Stefan
^ permalink raw reply
* Re: Floating point math in kernel interrupt -- am I doing this right? (repost)
From: Jeremy Friesner @ 2006-02-06 16:55 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <3c13d56389dfcf9f45ca87167295e933@embeddedalley.com>
>
> On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
>
> > .... and the mixing is done inside an
> > interrupt routine that runs 6000 times per second, and calculates 8
> > samples
> > per interrupt.
>
> Bad news. No Floating Point allowed in the kernel.
I'm aware of that rule, and also why -- because the Linux kernel doesn't want to have to save and restore the state of the floating point registers on every context switch. I'm also aware that it is nonetheless possible to use floating point in the kernel if you are careful to manually save and restore the proper state yourself, and that in fact floating point is sometimes used in the kernel as a means of doing 64-bit writes, as mentioned here:
http://www.tldp.org/LDP/cpg/html/x295.html
So it seems to me that it is possible to do floating point in the kernel, if you are careful to save and restore the proper context/state before and afterwards. But if it isn't, can you explain to me why it can't be made to work=3F
> > In order to do the necessary floating point math, without corrupting
> > the state
> > of any other processes that might be using the FPU, the interrupt
> > routine
> > first saves the state of the FPU registers to the stack, then does the
> > math,
> > then restores FPU registers again, before returning.
>
> Not on 82xx. All floating point is done in hardware.
Right; it is the hardware registers' state that I am saving to the stack, and then restoring afterwards.
> > So my question is, is there some minor detail that my
> > FPU-state-save/restore
> > code is missing, that would cause these sort of symptoms=3F
>
> Just get all of this out of the kernel. If you used the standard ALSA
> drivers and framework, lots of mixing features are available to you.
> If you need some custom mixing, just write a plug-in to do it.
> Your data rates are so low they don't justify making any hacks
> like this.
I suppose that is an option, but I'd rather understand why my hack isn't working before I give up and redesign my application, which is already working the way I want it to, 99.9999% of the time.
Jeremy
^ permalink raw reply
* Re: mv-linux: Problem to implement custom driver interrupt handling
From: Andrei Konovalov @ 2006-02-06 15:14 UTC (permalink / raw)
To: Eckart Göhler; +Cc: linuxppc-embedded
In-Reply-To: <43E74FB2.6010603@ifen.com>
Hi,
In the Linux driver you should not access the interrupt controller directly.
The relevant XIntc_* calls are done by arch/ppc/syslib/xilinx_pic.c code.
E.g. the particular interrupt is unmasked when one calls request_irq().
Few more comments below.
Thanks,
Andrei
Eckart Göhler wrote:
> Hi,
>
> We try to run montavista Linux pro 3.1 on an ml300 like embedded system
> on an Virtex V2-Pro system. The system works fine with UART, Xilinx enet
> driver (booting with Das U-Boot).
> Now we try to implement some custom GPIO driver that must be triggered
> from outside interrupts. Polling for data works fine but the handler for
> HW-timer interrupts does behaves strange.
>
> The relevant Linux driver part that requests the interrupt and starts
> the timer look like below.
>
> Installing such a driver works but
> - No report of driver interrupt called is sent
> - installing the driver results in a system that almost gets stuck and
> has poor response (~sec) till the driver is rmmodded.
>
> Checking the implementation with native Xilinx example timer application
> works fine, provided the Xilinx exception handling is implemented.
>
> Its not clear for me whether on ppc environment something specific must
> be done for custom interrupts, though implementation of
> xilinx_enet/xilinx_uartlite does not hint for something specific.
>
>
> sincerely
>
> eckart goehler
>
>
> -----------------------------------------------------------------(snip)
>
> // driver snippet that reacts on timer interrupts:
>
> // timer\interrupt base addresses, modified by ioremap:
> unsigned long timer_base, interrupt_base;
>
>
> /* interrupt handler: */
> static
> void drv_interrupt_handler(int irq, void *dev_id, struct pt_regs *regs)
> {
> printk(KERN_INFO DEVICE_NAME "interrupt occurred\n");
Most probably you should clear the interrupt source here.
Otherwise you could get back into the interrupt handler as
soon as you return from it due to the interrupt request still
being active.
> }
>
>
>
> static int __init drv_init_module(void)
> {
>
> interrupt_base = (unsigned long)
> ioremap(XPAR_INTC_BASEADDR,XPAR_INTC_HIGHADDR-XPAR_INTC_BASEADDR);
> timer_base = (unsigned long)
> ioremap(XPAR_TIMER_BASEADDR,XPAR_TIMER_HIGHADDR-XPAR_TIMER_BASEADDR);
>
> // install interrupt handler:
> if (request_irq(DRV_IRQ, commdrv_interrupt_handler,
> 0, DEVICE_NAME, NULL)
> )
You call request_irq() (i.e. unmask this interrupt) too early.
Configure the timer first.
> {
> printk(KERN_INFO DEVICE_NAME ": can¢t get assigned irq %i\n",
> COMM_IRQ
> );
> }
> else { /* enable interrupt */
>
> printk(KERN_INFO DEVICE_NAME ": interrupt installed\n");
>
> /* Start the interrupt controller */
> XIntc_mMasterEnable(interrupt_base);
- must not be used in the driver
> // here: enable timer interrupt:
> /* Set the number of cycles the timer counts before interrupting */
> XTmrCtr_mSetLoadReg(timer_base, 0, TIMER_VALUE * 80000000l);
>
>
> printk(KERN_INFO DEVICE_NAME ": clear timer\n");
>
> /* Reset the timers, and clear interrupts */
> XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_INT_OCCURED_MASK
> | XTC_CSR_LOAD_MASK );
>
> printk(KERN_INFO DEVICE_NAME ": enable interrupt\n");
>
> /* Enable timer interrupts in the interrupt controller */
>
> XIntc_mEnableIntr(interrupt_base, DRV_IRQ_MASK);
- must not be used in the driver. Unmasking the interrupt is done inside request_irq().
> //printk(KERN_INFO DEVICE_NAME ": start timer\n");
> /* Start the timers */
> XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_ENABLE_TMR_MASK
> | XTC_CSR_ENABLE_INT_MASK
> | XTC_CSR_AUTO_RELOAD_MASK |
> XTC_CSR_DOWN_COUNT_MASK);
>
> }
> }
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* mv-linux: Problem to implement custom driver interrupt handling
From: Eckart Göhler @ 2006-02-06 13:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
We try to run montavista Linux pro 3.1 on an ml300 like embedded system
on an Virtex V2-Pro system. The system works fine with UART, Xilinx enet
driver (booting with Das U-Boot).
Now we try to implement some custom GPIO driver that must be triggered
from outside interrupts. Polling for data works fine but the handler for
HW-timer interrupts does behaves strange.
The relevant Linux driver part that requests the interrupt and starts
the timer look like below.
Installing such a driver works but
- No report of driver interrupt called is sent
- installing the driver results in a system that almost gets stuck and
has poor response (~sec) till the driver is rmmodded.
Checking the implementation with native Xilinx example timer application
works fine, provided the Xilinx exception handling is implemented.
Its not clear for me whether on ppc environment something specific must
be done for custom interrupts, though implementation of
xilinx_enet/xilinx_uartlite does not hint for something specific.
sincerely
eckart goehler
-----------------------------------------------------------------(snip)
// driver snippet that reacts on timer interrupts:
// timer\interrupt base addresses, modified by ioremap:
unsigned long timer_base, interrupt_base;
/* interrupt handler: */
static
void drv_interrupt_handler(int irq, void *dev_id, struct pt_regs *regs)
{
printk(KERN_INFO DEVICE_NAME "interrupt occurred\n");
}
static int __init drv_init_module(void)
{
interrupt_base = (unsigned long)
ioremap(XPAR_INTC_BASEADDR,XPAR_INTC_HIGHADDR-XPAR_INTC_BASEADDR);
timer_base = (unsigned long)
ioremap(XPAR_TIMER_BASEADDR,XPAR_TIMER_HIGHADDR-XPAR_TIMER_BASEADDR);
// install interrupt handler:
if (request_irq(DRV_IRQ, commdrv_interrupt_handler,
0, DEVICE_NAME, NULL)
)
{
printk(KERN_INFO DEVICE_NAME ": can¢t get assigned irq %i\n",
COMM_IRQ
);
}
else { /* enable interrupt */
printk(KERN_INFO DEVICE_NAME ": interrupt installed\n");
/* Start the interrupt controller */
XIntc_mMasterEnable(interrupt_base);
// here: enable timer interrupt:
/* Set the number of cycles the timer counts before interrupting */
XTmrCtr_mSetLoadReg(timer_base, 0, TIMER_VALUE * 80000000l);
printk(KERN_INFO DEVICE_NAME ": clear timer\n");
/* Reset the timers, and clear interrupts */
XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_INT_OCCURED_MASK
| XTC_CSR_LOAD_MASK );
printk(KERN_INFO DEVICE_NAME ": enable interrupt\n");
/* Enable timer interrupts in the interrupt controller */
XIntc_mEnableIntr(interrupt_base, DRV_IRQ_MASK);
//printk(KERN_INFO DEVICE_NAME ": start timer\n");
/* Start the timers */
XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_ENABLE_TMR_MASK
| XTC_CSR_ENABLE_INT_MASK
| XTC_CSR_AUTO_RELOAD_MASK |
XTC_CSR_DOWN_COUNT_MASK);
}
}
^ permalink raw reply
* RE: Floating point math in kernel interrupt -- am I doing this right?(repost)
From: Fillod Stephane @ 2006-02-06 12:57 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Jeremy Friesner
Dan Malek wrote:
>> So my question is, is there some minor detail that my=20
>> FPU-state-save/restore
>> code is missing, that would cause these sort of symptoms?
>
>Just get all of this out of the kernel. If you used the standard ALSA
>drivers and framework, lots of mixing features are available to you.
>If you need some custom mixing, just write a plug-in to do it.
>Your data rates are so low they don't justify making any hacks
>like this.
.. or if you *do* need hard-realtime feedback, you may consider
using Xenomai[1] (formerly known as RTAI/Fusion) instead of=20
a hack of the interrupt handler. Thanks to this nice project,=20
FPU on PQ2 works fine in kernel-land, and if need be, it will=20
let you move to user-land seamlessly while keeping the constraints.
Feel free to join the xenomai-help mailing list to get more help=20
on specific questions. Disclaimer: I'm not affiliated with Xenomai,
I am just a happy user :-)
[1] http://xenomai.org
Regards,
--=20
Stephane
^ permalink raw reply
* Re: Floating point math in kernel interrupt -- am I doing this right? (repost)
From: Dan Malek @ 2006-02-06 12:27 UTC (permalink / raw)
To: Jeremy Friesner; +Cc: linuxppc-embedded
In-Reply-To: <200602051829.47824.jaf@lcsaudio.com>
On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
> .... and the mixing is done inside an
> interrupt routine that runs 6000 times per second, and calculates 8
> samples
> per interrupt.
Bad news. No Floating Point allowed in the kernel.
> In order to do the necessary floating point math, without corrupting
> the state
> of any other processes that might be using the FPU, the interrupt
> routine
> first saves the state of the FPU registers to the stack, then does the
> math,
> then restores FPU registers again, before returning.
Not on 82xx. All floating point is done in hardware.
> .... The oops
> looks like this:
These aren't helpful without some supporting information, like
symbols, or learn to use ksymoops.
> So my question is, is there some minor detail that my
> FPU-state-save/restore
> code is missing, that would cause these sort of symptoms?
Just get all of this out of the kernel. If you used the standard ALSA
drivers and framework, lots of mixing features are available to you.
If you need some custom mixing, just write a plug-in to do it.
Your data rates are so low they don't justify making any hacks
like this.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH] make powerbook_sleep_grackle static
From: Olaf Hering @ 2006-02-06 12:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Andrew Morton, linuxppc-dev
powerbook_sleep_grackle is only called inside via-pmu,
from pmu_ioctl()
Signed-off-by: Olaf Hering <olh@suse.de>
---
drivers/macintosh/via-pmu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6.15/drivers/macintosh/via-pmu.c
===================================================================
--- linux-2.6.15.orig/drivers/macintosh/via-pmu.c
+++ linux-2.6.15/drivers/macintosh/via-pmu.c
@@ -2200,8 +2200,7 @@ pmac_wakeup_devices(void)
#define GRACKLE_NAP (1<<4)
#define GRACKLE_SLEEP (1<<3)
-int
-powerbook_sleep_grackle(void)
+static int powerbook_sleep_grackle(void)
{
unsigned long save_l2cr;
unsigned short pmcr1;
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [patch 14/44] generic hweight{64,32,16,8}()
From: Akinobu Mita @ 2006-02-06 11:52 UTC (permalink / raw)
To: Gabriel Paubert
Cc: linux-mips, linux-m68k, linux-ia64, Ian Molton, Balbir Singh,
Andi Kleen, David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-dev,
Linus Torvalds, Ivan Kokshaysky, linux, Richard Henderson,
Chris Zankel, dev-etrax, ultralinux, linux-kernel,
linuxsh-shmedia-dev, linux390, Russell King, parisc-linux
In-Reply-To: <20060202012637.GA25093@iram.es>
On Thu, Feb 02, 2006 at 02:26:38AM +0100, Gabriel Paubert wrote:
>
> The first step can be implemented slightly better:
>
> unsigned int res = w-((w>>1)&0x55555555);
>
Yes. I've got many advices about hweight speedup.
static unsigned int hweight32(unsigned int w)
{
unsigned int res = w - ((w >> 1) & 0x55555555);
res = (res & 0x33333333) + ((res >> 2) & 0x33333333);
res = (res + (res >> 4)) & 0x0F0F0F0F;
res = res + (res >> 8);
return (res + (res >> 16)) & 0x000000FF;
}
static unsigned int hweight16(unsigned int w)
{
unsigned int res = w - ((w >> 1) & 0x5555);
res = (res & 0x3333) + ((res >> 2) & 0x3333);
res = (res + (res >> 4)) & 0x0F0F;
return (res + (res >> 8)) & 0x00FF;
}
static unsigned int hweight8(unsigned int w)
{
unsigned int res = w - ((w >> 1) & 0x55);
res = (res & 0x33) + ((res >> 2) & 0x33);
return (res + (res >> 4)) & 0x0F;
}
static unsigned long hweight64(__u64 w)
{
#if BITS_PER_LONG < 64
return hweight32((unsigned int)(w >> 32)) +
hweight32((unsigned int)w);
#else
__u64 res = w - ((w >> 1) & 0x5555555555555555ul);
res = (res & 0x3333333333333333ul) + ((res >> 2) & 0x3333333333333333ul);
res = (res + (res >> 4)) & 0x0F0F0F0F0F0F0F0Ful;
res = res + (res >> 8);
res = res + (res >> 16);
return (res + (res >> 32)) & 0x00000000000000FFul;
#endif
}
^ permalink raw reply
* Re: Floating point math in kernel interrupt -- am I doing this right?
From: Roger Larsson @ 2006-02-06 8:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200602051140.51759.jaf@lcsaudio.com>
On s=F6ndag 05 februari 2006 20.40, Jeremy Friesner wrote:
> If I disable the saving and restoring of the FPU registers=20
> entirely, they don't seem to occur at all (at least within the bounds of =
my
> testing so far -- 15+ hours).
Is this with full mix?
Then I would really suspect the save/restore code.
Saving and restoring floating point state can be very tricky.
Do try to find an example in the manual (or possibly in the kernel itself -=
=20
context switch code)
Until this works reliably there is no point in looking for other error=20
sources. You could also try to add code inside the save-resore that destro=
ys=20
all of the floating point registers to be able to spot errors.
/RogerL
^ permalink raw reply
* Floating point math in kernel interrupt -- am I doing this right? (repost)
From: Jeremy Friesner @ 2006-02-06 2:29 UTC (permalink / raw)
To: linuxppc-embedded
(Sorry if this is dupe, my first posting didn't seem to make it through)
Hi all,
Can someone who is well-versed in PowerPC kernel issues give me some advice?
First, a bit of background: I'm working on an audio mixing/playback engine
that runs on an embedded PowerPC chip (82xx) using the 2.4.23 kernel. The
audio output format is 48kHz floating point, and the mixing is done inside an
interrupt routine that runs 6000 times per second, and calculates 8 samples
per interrupt.
In order to do the necessary floating point math, without corrupting the state
of any other processes that might be using the FPU, the interrupt routine
first saves the state of the FPU registers to the stack, then does the math,
then restores FPU registers again, before returning.
In general this seems to work fine, i.e. I get the audio output I expect and
user processes aren't effected. However, I've noticed that every so often I
will get a kernel oops and my userland application will crash. The oops
looks like this:
<4>Oops: kernel access of bad area, sig: 11
<4>NIP: C001D408 XER: 20000000 LR: C001D3E0 SP: C6091E30 REGS: c6091d80 TRAP:
0300 Not tainted
<4>MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
<4>DAR: 3FE8228D, DSISR: 20000000
<4>TASK = c6090000[118] 'wtrxd' Last syscall: 178
<4>last math c6054000 last altivec 00000000
<4>GPR00: 0000001F C6091E30 C6090000 00000020 C6090398 C6055DE8 C017AB4C
00000000
<4>GPR08: 408CC599 3FE8228D 0000001F 00000000 84022884 10510E98 105800BC
308259E8
<4>GPR16: 1057302C 1058006C 00000000 00000000 00009032 06091F40 00000000
C0005DE8
<4>GPR24: C0005B40 00000020 00008000 00000000 C6091F50 C6091F20 C6091E78
00000020
<4>Call backtrace:
<4>00000400 C0009AB8 C0009CC0 C0009060 C0005B9C 0FC1BBA4 0FEF51D0
<4>0FEF6F58 0FEF3C3C 10366F34 10365C64 103572A0 103895D8 0FEF37EC
<4>0FCCDE2C
The frequency of the 'oops' occurrences appears to be proportional to the
amount of code that is present in the FPU-enabled section of the interrupt
routine. If I enable all of the mixing code, they appear every 10-20
minutes. If I disable all of the mixing code except the saving and restoring
of the FPU registers, they only occur about once every 6-12 hours. If I
disable the saving and restoring of the FPU registers entirely, they don't
seem to occur at all (at least within the bounds of my testing so far -- 15+
hours).
So my question is, is there some minor detail that my FPU-state-save/restore
code is missing, that would cause these sort of symptoms? I just enough
about kernel/assembly/PowerPC issues to be dangerous, so I thought maybe
there was something obvious that I am missing. The relevant code is shown
below.
Many thanks for any help or hints you can provide,
Jeremy Friesner
--------------- begin code snippet ----------------------
[... in interrupt routine...]
uint32 saved_msr;
uint32 saved_fpr[32*2]; // temp storage space for the current floating
point registers
/* Set up floating point enabled mode -- NO FLOATING POINT OPS ALLOWED
ABOVE THIS POINT! */
{
// Save existing MSR
uint32 msr;
__asm__ __volatile__ ("mfmsr %0" : "=r" (msr) : );
saved_msr = msr;
// Enable floating point
msr |= MSR_FP;
msr &= ~(MSR_FE0 | MSR_FE1);
__asm__ __volatile__ ("mtmsr %0\n\tisync" : : "r" (msr));
/* Save the floating point registers that the mix code uses, so that we
won't screw up the user process */
#define SAVE_FPR(x) {uint32 * saveTo = &saved_fpr[x*2]; __asm__ __volatile__
("stfd " #x ", 0(%0)\n" : : "b" (saveTo));}
SAVE_FPR(0); SAVE_FPR(1); SAVE_FPR(2); SAVE_FPR(3); SAVE_FPR(4);
SAVE_FPR(5); SAVE_FPR(6); SAVE_FPR(7); SAVE_FPR(8); SAVE_FPR(9);
SAVE_FPR(10); SAVE_FPR(11); SAVE_FPR(12); SAVE_FPR(13);
/* Note that I only save/restore the first 13 FP registers, since gcc's
generated code doesn't use the other ones anyway(!) */
}
[... the actual mixing routine is called here. I compile the mix function
in a separate file, without the -msoft-float flag ...]
[... but note that I get crashes even if I comment out the call to the
mixing routine, which suggests the problem is somewhere else...]
DoMixing();
/* Exit floating point enabled mode -- NO FLOATING POINT OPS ALLOWED BELOW
THIS POINT! */
{
/* Restore the FP registers back to their original state */
#define RESTORE_FPR(x) {uint32 * restoreFrom = &saved_fpr[x*2]; __asm__
__volatile__ ("lfd " #x ", 0(%0)\n" : : "b" (restoreFrom));}
RESTORE_FPR(0); RESTORE_FPR(1); RESTORE_FPR(2); RESTORE_FPR(3);
RESTORE_FPR(4);
RESTORE_FPR(5); RESTORE_FPR(6); RESTORE_FPR(7); RESTORE_FPR(8);
RESTORE_FPR(9);
RESTORE_FPR(10); RESTORE_FPR(11); RESTORE_FPR(12); RESTORE_FPR(13);
/* Restore MSR */
__asm__ __volatile__ ("mtmsr %0\n" "isync" : : "r" (saved_msr));
}
^ 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