* MPC875 using SCC4 together with both FECs
From: dibacco @ 2006-02-07 22:24 UTC (permalink / raw)
To: linuxppc-embedded
Someone knows if, in MPC875, SCC4 can be used together with the two FECs?=
I saw that RXD4(input SCC4) shares the same GPIO with MII-TXD0 (output o=
f FEC0).
Thank you,
Antonio.
^ permalink raw reply
* IBM_EMAC_PHY_RX_CLK_FIX depends on non-existing option 440GR
From: Adrian Bunk @ 2006-02-07 22:14 UTC (permalink / raw)
To: ebs; +Cc: linuxppc-dev, netdev, linux-kernel, Jean-Luc Leger,
linuxppc-embedded
Jean-Luc Leger <reiga@dspnet.fr.eu.org> reported the following:
from drivers/net/Kconfig:
config IBM_EMAC_PHY_RX_CLK_FIX
bool "PHY Rx clock workaround"
depends on IBM_EMAC && (405EP || 440GX || 440EP || 440GR)
-> maybe this is 440GP ?
The non-existing CONFIG_440GR is also present in the driver itself.
Is this a typo or a not yet merged platform?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Lost patches in powerpc.git
From: Paul Mackerras @ 2006-02-07 22:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <1651B3F8-87C2-4A6E-8D66-BF24B3AB83D9@kernel.crashing.org>
Kumar Gala writes:
> It appears in your last merge of patches into powerpc.git you lost
> some patches.
Yes, my mistake, I'll fix it.
Paul.
^ permalink raw reply
* Re: Common Flash Interface v1.4 and MTD support in Linux-2.4.4 kernel
From: Wolfgang Denk @ 2006-02-07 21:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: David Antliff, linuxppc-embedded
In-Reply-To: <1139309578.32218.7.camel@yoda.jdub.homelinux.org>
In message <1139309578.32218.7.camel@yoda.jdub.homelinux.org> you wrote:
>
> > 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.
>
> 'quick fix' is to pull the changes from cfi_cmdset_0001.c in MTD CVS
> back into your kernel. But I'm not sure how quick that will be given
> that your kernel is very very old.
It's not quick at all, and the ancient 2.4.4 MTD code has other
problems at all. Swithing to a newer kernel version is very likely
less trouble.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with a
different reality system.
^ permalink raw reply
* [PATCH] powerpc: Add FSL USB node to documentation
From: Becky Bruce @ 2006-02-07 19:44 UTC (permalink / raw)
To: linuxppc-dev
Documentation: Added FSL SOC USB node definition
Updated the documentation to include the definition of the USB device
node format for Freescale SOC devices.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 22970a5d9a7dd57512442e5f33c7fce708911bf9
tree 4bb85465dd12ecaf0213a985bd94e6c5546fb5d2
parent 3441bf59c7e1dc3823f9be57838a2536c78f6f8f
author Becky Bruce <becky.bruce@freescale.com> Mon, 06 Feb 2006 14:19:07 -0600
committer Becky Bruce <becky.bruce@freescale.com> Mon, 06 Feb 2006 14:19:07 -0600
Documentation/powerpc/booting-without-of.txt | 60 ++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 54e5f9b..81a0507 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -44,7 +44,6 @@
compiler and the textural representation of
the tree that can be "compiled" by dtc.
-
November 21, 2005: Rev 0.5
- Additions/generalizations for 32-bit
- Changed to reflect the new arch/powerpc
@@ -1307,6 +1306,65 @@ platforms are moved over to use the flat
};
+ f) Freescale SOC USB controllers
+
+ The device node for a USB controller that is part of a Freescale
+ SOC is as described in the document "Open Firmware Recommended
+ Practice : Universal Serial Bus" with the following modifications
+ and additions :
+
+ Required properties :
+ - compatible : Should be "fsl-usb2-mph" for multi port host usb
+ controllers, or "fsl-usb2-dr" for dual role usb controllers
+ - phy_type : For multi port host usb controllers, should be one of
+ "ulpi", or "serial". For dual role usb controllers, should be
+ one of "ulpi", "utmi", "utmi_wide", or "serial".
+ - reg : Offset and length of the register set for the device
+ - port0 : boolean; if defined, indicates port0 is connected for
+ fsl-usb2-mph compatible controllers. Either this property or
+ "port1" (or both) must be defined for "fsl-usb2-mph" compatible
+ controllers.
+ - port1 : boolean; if defined, indicates port1 is connected for
+ fsl-usb2-mph compatible controllers. Either this property or
+ "port0" (or both) must be defined for "fsl-usb2-mph" compatible
+ controllers.
+
+ Recommended properties :
+ - interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+
+ Example multi port host usb controller device node :
+ usb@22000 {
+ device_type = "usb";
+ compatible = "fsl-usb2-mph";
+ reg = <22000 1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <700>;
+ interrupts = <27 1>;
+ phy_type = "ulpi";
+ port0;
+ port1;
+ };
+
+ Example dual role usb controller device node :
+ usb@23000 {
+ device_type = "usb";
+ compatible = "fsl-usb2-dr";
+ reg = <23000 1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <700>;
+ interrupts = <26 1>;
+ phy = "ulpi";
+ };
+
+
More devices will be defined as this spec matures.
^ permalink raw reply related
* Voyager Video support color depths?
From: Russell McGuire @ 2006-02-07 19:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.294.1139321937.857.linuxppc-embedded@ozlabs.org>
Everyone,
I had a question about the various video support that has been tested with
the 2.4.25 DENX Kernel.
To date I have had pretty good luck with by making sure I have compiled the
kernel with the Voyager.h file set at 32 BPP mode.
For speed optimization I wanted to cut it back to 16 BPP mode, however I
couldn't hardly get it to boot the machine after I did this change by
changing '#define SCREEN_BPP 16'. Most attempts the kernel would lock up
before a login prompt was available. When I tried SCREEN_BPP at 8 then it
booted fine, however QT/Embedded had terrible colors.
I was wondering if I should be looking for the trouble in some other code,
or perhaps hardware, or if this is a known bug in the SM501 / Voyager
driver, or perhaps the linux frame buffer driver.
Thanks all,
-Russ
^ permalink raw reply
* Re: merge these lists?
From: Linas Vepstas @ 2006-02-07 16:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <B21A08E2-3D64-45B8-8319-872B1C1D31BC@kernel.crashing.org>
On Tue, Feb 07, 2006 at 08:35:23AM -0600, Kumar Gala was heard to remark:
>
> I agree. Let's just kill linuxppc64-dev and direct people at
> linuxppc-dev.
Can a sysadmin merge the subscription lists?
I didn't even know that there was a linuxppc-dev list;
I thought the merge of these two lists occured a year ago,
when it was moved to ozlabs :-/
--linas
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Kernel FP unavail exception for BookE
From: Becky Bruce @ 2006-02-07 16:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, galak
In-Reply-To: <0298A03B-4A0D-48CE-B941-EB3D0CEA9606@kernel.crashing.org>
On Feb 7, 2006, at 8:28 AM, Kumar Gala wrote:
>
> On Feb 7, 2006, at 4:30 AM, Paul Mackerras wrote:
>
>> 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?
>
> powerpc.git should have it. If not this is an issue that should be
> fixed.
>
> Becky, is this change also needed for arch/ppc? If so can you
> fixup arch/ppc/kernel/head_booke.h and provide patch that
> duplicates head_booke.h in arch/powerpc/kernel if its not there.
No change needed there - it was correct in arch/ppc, just not in arch/
powerpc. The 8540 patch was based on a slightly older copy of the
file that didn't have this change and we didn't catch the problem in
testing because the FPU isn't enabled for 8540. I discovered this
later.
The 8540 flat tree support patch added this file to arch/powerpc/
kernel. As you pointed out in a different mail, this patch has
disappeared from the tree recently.
-B
^ permalink raw reply
* Lost patches in powerpc.git
From: Kumar Gala @ 2006-02-07 15:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
Paul,
It appears in your last merge of patches into powerpc.git you lost
some patches. This is my best attempt at listing out the patches you
lost:
[PATCH] PPC32 8xx: support for the physmapped flash on m8xx
[PATCH] powerpc: generalize PPC44x_PIN_SIZE
[PATCH] powerpc: Add CONFIG_DEFAULT_UIMAGE to build a uImage by
default for a board
[PATCH] ppc32 8xx: Added setbitsXX/clrbitsXX macro for read-
modify-write operations
[PATCH] powerpc: Updated Initial MPC8540 ADS port with OF Flat Dev
- kumar
^ permalink raw reply
* Re: merge these lists?
From: Kumar Gala @ 2006-02-07 14:36 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <200602071445.45805.jk@ozlabs.org>
On Feb 6, 2006, at 9:45 PM, 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?
Hmm, how about a merged patchwork starting after 2.6.16?
- kumar
^ permalink raw reply
* Re: merge these lists?
From: Kumar Gala @ 2006-02-07 14:35 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20060207105643.GA22234@lst.de>
On Feb 7, 2006, at 4:56 AM, Christoph Hellwig wrote:
> 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.
I agree. Let's just kill linuxppc64-dev and direct people at
linuxppc-dev.
- kumar
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-07 14:33 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <43E8ACB3.6030401@compulab.co.il>
> The driver development is stalled and I don't know when I'll be able to
> continue working on it.
Bad news, but I do understand. Please inform me when you will resume working
on the driver, so that I can inform you of the progress I will have made (if
any).
> >What are the major performance issues ?
>
> One of the issues in this driver is redunduncy between qe end ep
> structures and as a consequence a lot of uneeded code that make cross
> updates.
> I didn't run profiling, so I can't tell better.
Ok.
> >I noticed that the driver uses the MPC82xx packet level interface.
> >Why don't you use the transaction level interface ?
>
> The original driver I've started with used packet level. I thought on
> switching to transaction level, but I hadn't time for it because of
> other projects pressure.
Do you think it would be worth it, or are there any issue which you are aware
of that would make it difficult/impractical/impossible/useless ?
> >That might explain why some devices don't even respond to the first
> > request. I noticed that, on my EP8248 board, the controller only sends
> > 990 SOF packets per second (or rather 990 SOF interrupts are generated).
> > I might have a time base problem somewhere, as I computed the number of
> > interrupts per second with a simple
> >
> >cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 &&
> >cat /proc/driver/m8xxhci_privateh > sof.2
>
> I'm not sure such measurements are correct, since you sleep not exatly
> 300 seconds. I haven't measured how many SOF interrupts I get, but I
> think you maybe right.
> It may happen that during transmit or recieve the interrupts are off and
> SOF packets are not sent.
My bad, this was caused by the boot loader passing 66000000Hz instead of
66666666Hz to Linux as the bus frequency. This is fixed now, and I get 1000
SOF interrupts per second.
> >Do you have the same problem ? I'll see if I can get my hands on a USB
> >protocol analyzer.
>
> Good luck, I'll try to help but unfotunately I'm very much busy with
> other projects now.
Thanks for your help already.
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Kernel FP unavail exception for BookE
From: Kumar Gala @ 2006-02-07 14:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, galak
In-Reply-To: <17384.30426.76075.491857@cargo.ozlabs.ibm.com>
On Feb 7, 2006, at 4:30 AM, Paul Mackerras wrote:
> 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?
powerpc.git should have it. If not this is an issue that should be
fixed.
Becky, is this change also needed for arch/ppc? If so can you fixup
arch/ppc/kernel/head_booke.h and provide patch that duplicates
head_booke.h in arch/powerpc/kernel if its not there.
- k
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Mike Rapoport @ 2006-02-07 14:20 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200602071414.28551.laurent.pinchart@tbox.biz>
Laurent Pinchart wrote:
>How is the driver development going ? You're not using the sourceforge CVS/SVN
>repository, is there another one somewhere (maybe a git tree) ? Are you
>actively working on performance issues, or is the development currently
>stalled ?
>
>
The driver development is stalled and I don't know when I'll be able to
continue working on it.
>What are the major performance issues ?
>
>
One of the issues in this driver is redunduncy between qe end ep
structures and as a consequence a lot of uneeded code that make cross
updates.
I didn't run profiling, so I can't tell better.
>I noticed that the driver uses the MPC82xx packet level interface.
>Why don't you use the transaction level interface ?
>
>
The original driver I've started with used packet level. I thought on
switching to transaction level, but I hadn't time for it because of
other projects pressure.
>
>
>>Another thing that may cause problems is how storage devices treat SOF
>>packets, but I'm not USB expert enough to be sure about that.
>>
>>
>
>That might explain why some devices don't even respond to the first request. I
>noticed that, on my EP8248 board, the controller only sends 990 SOF packets
>per second (or rather 990 SOF interrupts are generated). I might have a time
>base problem somewhere, as I computed the number of interrupts per second
>with a simple
>
>cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 &&
>cat /proc/driver/m8xxhci_privateh > sof.2
>
>
>
I'm not sure such measurements are correct, since you sleep not exatly
300 seconds. I haven't measured how many SOF interrupts I get, but I
think you maybe right.
It may happen that during transmit or recieve the interrupts are off and
SOF packets are not sent.
>Do you have the same problem ? I'll see if I can get my hands on a USB
>protocol analyzer.
>
>
Good luck, I'll try to help but unfotunately I'm very much busy with
other projects now.
>Laurent Pinchart
>
>
>
>
>
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-07 13:14 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <43E5BAE8.9000507@compulab.co.il>
> >When I connect a USB 2.0 Mass Storage device, initialization fails when
> > trying to fetch the string descriptors. Here's what USBMon produces (I
> > decoded the USB transactions with the device).
>
> [snip]
>
> I had similar problems with mass storage devices (disk-on-key). I've
> tried to find out what was causing them but I hadn't much success with it.
> I think that problem might be in driver performance because it is very
> far from optimal.
How is the driver development going ? You're not using the sourceforge CVS/SVN
repository, is there another one somewhere (maybe a git tree) ? Are you
actively working on performance issues, or is the development currently
stalled ? What are the major performance issues ? I noticed that the driver
uses the MPC82xx packet level interface. Why don't you use the transaction
level interface ?
> Another thing that may cause problems is how storage devices treat SOF
> packets, but I'm not USB expert enough to be sure about that.
That might explain why some devices don't even respond to the first request. I
noticed that, on my EP8248 board, the controller only sends 990 SOF packets
per second (or rather 990 SOF interrupts are generated). I might have a time
base problem somewhere, as I computed the number of interrupts per second
with a simple
cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 &&
cat /proc/driver/m8xxhci_privateh > sof.2
Do you have the same problem ? I'll see if I can get my hands on a USB
protocol analyzer.
Laurent Pinchart
^ permalink raw reply
* Re: Common Flash Interface v1.4 and MTD support in Linux-2.4.4 kernel
From: Josh Boyer @ 2006-02-07 10:52 UTC (permalink / raw)
To: David Antliff; +Cc: linuxppc-embedded
In-Reply-To: <1139283195.26357.50.camel@theoden.middle_earth>
On Tue, 2006-02-07 at 16:33 +1300, David Antliff wrote:
>
>
> I am working on an MPC852 embedded platform based on the Denx
> Linux-2.4.4 port.
To note, 2.4.4 is ancient. And this whole question would be better
asked on the MTD mailing list.
>
> 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).
Yep.
>
> 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.
P30 support was just recently added to the 2.6 kernel.
>
>
> 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?
There is no support for CFI 1.4 in any 2.4 kernel. You'd have to
backport from 2.6
>
> 2. integrate code found here and try and understand how it works:
> http://lists.infradead.org/pipermail/linux-mtd/2001-November/003645.html
That won't solve all of your problems.
>
>
> 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.
'quick fix' is to pull the changes from cfi_cmdset_0001.c in MTD CVS
back into your kernel. But I'm not sure how quick that will be given
that your kernel is very very old.
josh
^ permalink raw reply
* 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
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