* Re: IBM_EMAC_PHY_RX_CLK_FIX depends on non-existing option 440GR
From: Eugene Surovegin @ 2006-02-07 22:57 UTC (permalink / raw)
To: Adrian Bunk
Cc: linuxppc-dev, netdev, linux-kernel, Jean-Luc Leger,
linuxppc-embedded
In-Reply-To: <20060207221449.GB3524@stusta.de>
On Tue, Feb 07, 2006 at 11:14:49PM +0100, Adrian Bunk wrote:
> 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?
Not yet merged platform.
--
Eugene
^ permalink raw reply
* Re: Artesyn Processor PMC 'Host Bridge' has no IRQ assigned?
From: Travis B. Sawyer @ 2006-02-07 22:56 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43E91ED1.2090400@ovro.caltech.edu>
David Hawkins wrote:
> What appears strange to me is that there is no IRQ assigned.
>
Ouch.
> I haven't used PrPMC boards before, so perhaps this
> is normal.
>
> Travis, you mentioned you'd used this board before. Do you
> recall if this 'feature' is configurable, i.e., can I enable
> an interrupt. I'll also take a look in the IBM CPC700 bridge
> data sheet and see if I can see anything in there.
>
It's been a couple of years since I've had to mess with the ArtPrPMC board.
There is, IIRC, there is a doorbell register in the CPC700, but I don't
have the spec
handy. My last use of the prpmc was with vxworks and shared memory
messaging
using a doorbell.
> I checked the mode of the PMC board using the monitor program.
> It says its in non-Monarch mode, so it is correctly configuring
> itself as a PCI peripheral.
>
> My objective for the board is to put U-Boot on it (Travis mentioned
> the Artesyn board is supported), boot Linux, and then write
> drivers for communicating over PCI to an x86 host (much as
> I plan to do with the 440EP processor).
>
Umm... I recall stating the XPEDITE1000 from X-ES was supported by u-boot
(I'll have to submit another patch to Wolfgang as they(XES) changed some
stuff wrt
flash write protect, I've also moved the env from the cramped i2c eeprom
(bad) to
the intel flash).
I'd have to check the u-boot source for PrPMC support, as I haven't run
u-boot on it.
Best Regards, and good luck!
-travis
^ permalink raw reply
* Re: Common Flash Interface v1.4 and MTD support in Linux-2.4.4 kernel
From: David Antliff @ 2006-02-07 22:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060207210421.57015352659@atlas.denx.de>
On Tue, 2006-02-07 at 22:04 +0100, Wolfgang Denk wrote:
> 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.
Josh & Wolfgang, I appreciate your replies - thank you.
FYI, we have decided to investigate writing a simple block device driver
for this device to get our development back on track with an eventual
goal of upgrading the kernel when time and resources permit.
MTD is not crucial to our project, it just made a previous task easier
and this current one harder! :)
Thanks again,
David Antliff
^ permalink raw reply
* Artesyn Processor PMC 'Host Bridge' has no IRQ assigned?
From: David Hawkins @ 2006-02-07 22:27 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Travis B. Sawyer
In-Reply-To: <43C7DD1D.20804@ovro.caltech.edu>
Hi all,
I mentioned a few weeks back that I had found some
Artesyn PrPMC boards on eBay for about $50 ea.
I purchased a couple of the boards, I have booted
one on a PMC site on a x86 compact PCI host CPU board.
From the x86 host, if I perform lspci on the
board, its recognized as a 'Host Bridge';
# lspci -s 02:03.0 -vv
02:03.0 Host bridge: Artesyn Communication Products PM/PPC (rev 01)
Subsystem: Unknown device 00f9:1014
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Region 1: Memory at f4000000 (32-bit, prefetchable) [size=64M]
Region 2: Memory at f0700000 (32-bit, prefetchable) [size=4K]
What appears strange to me is that there is no IRQ assigned.
How then would one write a driver on the PMC board that
could interrupt the x86 Host CPU??
I haven't used PrPMC boards before, so perhaps this
is normal.
Travis, you mentioned you'd used this board before. Do you
recall if this 'feature' is configurable, i.e., can I enable
an interrupt. I'll also take a look in the IBM CPC700 bridge
data sheet and see if I can see anything in there.
I checked the mode of the PMC board using the monitor program.
It says its in non-Monarch mode, so it is correctly configuring
itself as a PCI peripheral.
My objective for the board is to put U-Boot on it (Travis mentioned
the Artesyn board is supported), boot Linux, and then write
drivers for communicating over PCI to an x86 host (much as
I plan to do with the 440EP processor).
Anyway, comments welcome!
Dave
^ permalink raw reply
* 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
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