* [PATCH] powerpc: mpc85xx_ads.c include file cleanup
From: Becky Bruce @ 2006-02-08 3:22 UTC (permalink / raw)
To: linuxppc-dev
Cut-and-paste from the old platform code in arch/ppc resulted in
arch/powerpc/platforms/85xx/mpc85xx_ads.c having way too many
header files included. Clean this up.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit f0a2dc035ebf50418e699f789f5c7523092ff553
tree 0e10e705722dbdb52db310d39c1de3b5ff0c4374
parent f692600853b404c2b863bd75fbf41bcc90040002
author Becky Bruce <becky.bruce@freescale.com> Tue, 07 Feb 2006 20:53:21 -0600
committer Becky Bruce <becky.bruce@freescale.com> Tue, 07 Feb 2006 20:53:21 -0600
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 21 ---------------------
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 41191e9..9e8a91b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -14,38 +14,17 @@
#include <linux/config.h>
#include <linux/stddef.h>
#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/errno.h>
-#include <linux/reboot.h>
#include <linux/pci.h>
#include <linux/kdev_t.h>
-#include <linux/major.h>
-#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
-#include <linux/serial.h>
-#include <linux/tty.h> /* for linux/serial_core.h */
-#include <linux/serial_core.h>
-#include <linux/initrd.h>
-#include <linux/module.h>
-#include <linux/fsl_devices.h>
-#include <linux/serial_core.h>
-#include <linux/serial_8250.h>
#include <asm/system.h>
-#include <asm/pgtable.h>
-#include <asm/page.h>
-#include <asm/atomic.h>
#include <asm/time.h>
-#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
#include <asm/mpc85xx.h>
-#include <asm/irq.h>
-#include <asm/immap_85xx.h>
#include <asm/prom.h>
#include <asm/mpic.h>
#include <mm/mmu_decl.h>
^ permalink raw reply related
* [PATCH 23/29] bogus extern in low_i2c.c
From: Al Viro @ 2006-02-08 3:19 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
Date: 1138796714 -0500
extern in function definition is an odd thing..
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
arch/powerpc/platforms/powermac/low_i2c.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
1d0bd717c86949e97a11855482b4a118029c10a9
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
index 535c802..87eb6bb 100644
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -1052,8 +1052,7 @@ struct pmac_i2c_bus *pmac_i2c_adapter_to
}
EXPORT_SYMBOL_GPL(pmac_i2c_adapter_to_bus);
-extern int pmac_i2c_match_adapter(struct device_node *dev,
- struct i2c_adapter *adapter)
+int pmac_i2c_match_adapter(struct device_node *dev, struct i2c_adapter *adapter)
{
struct pmac_i2c_bus *bus = pmac_i2c_find_bus(dev);
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 22/29] eeh_driver NULL noise removal
From: Al Viro @ 2006-02-08 3:19 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
Date: 1138796604 -0500
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
arch/powerpc/platforms/pseries/eeh_driver.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
d04e4e115bd9df2b748cb30abd610f3c0eb1e303
diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c b/arch/powerpc/platforms/pseries/eeh_driver.c
index 6373372..e3cbba4 100644
--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -333,7 +333,7 @@ void handle_eeh_events (struct eeh_event
rc = eeh_reset_device(frozen_pdn, NULL);
if (rc)
goto hard_fail;
- pci_walk_bus(frozen_bus, eeh_report_reset, 0);
+ pci_walk_bus(frozen_bus, eeh_report_reset, NULL);
}
/* If all devices reported they can proceed, the re-enable PIO */
@@ -342,11 +342,11 @@ void handle_eeh_events (struct eeh_event
rc = eeh_reset_device(frozen_pdn, NULL);
if (rc)
goto hard_fail;
- pci_walk_bus(frozen_bus, eeh_report_reset, 0);
+ pci_walk_bus(frozen_bus, eeh_report_reset, NULL);
}
/* Tell all device drivers that they can resume operations */
- pci_walk_bus(frozen_bus, eeh_report_resume, 0);
+ pci_walk_bus(frozen_bus, eeh_report_resume, NULL);
return;
@@ -367,7 +367,7 @@ hard_fail:
eeh_slot_error_detail(frozen_pdn, 2 /* Permanent Error */);
/* Notify all devices that they're about to go down. */
- pci_walk_bus(frozen_bus, eeh_report_failure, 0);
+ pci_walk_bus(frozen_bus, eeh_report_failure, NULL);
/* Shut down the device drivers for good. */
pcibios_remove_pci_devices(frozen_bus);
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 07/29] ppc: last_task_.... is defined only on non-SMP
From: Al Viro @ 2006-02-08 3:18 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
Date: 1137641660 -0500
... so it should be exported only on non-SMP.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
arch/ppc/kernel/ppc_ksyms.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
3ba9d91208a71947b69d52e3ca2142306457d816
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index 3a6e4bc..15bd9b4 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -186,11 +186,15 @@ EXPORT_SYMBOL(flush_tlb_kernel_range);
EXPORT_SYMBOL(flush_tlb_page);
EXPORT_SYMBOL(_tlbie);
#ifdef CONFIG_ALTIVEC
+#ifndef CONFIG_SMP
EXPORT_SYMBOL(last_task_used_altivec);
+#endif
EXPORT_SYMBOL(giveup_altivec);
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_SPE
+#ifndef CONFIG_SMP
EXPORT_SYMBOL(last_task_used_spe);
+#endif
EXPORT_SYMBOL(giveup_spe);
#endif /* CONFIG_SPE */
#ifdef CONFIG_SMP
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 05/29] fix breakage in ocp.c
From: Al Viro @ 2006-02-08 3:18 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
Date: 1137627616 -0500
it's ocp_device_...., not ocp_driver_....
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
arch/ppc/syslib/ocp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
83ec98be051b277635bc7379b863b25f6dbe54ce
diff --git a/arch/ppc/syslib/ocp.c b/arch/ppc/syslib/ocp.c
index ab34b1d..2fe28de 100644
--- a/arch/ppc/syslib/ocp.c
+++ b/arch/ppc/syslib/ocp.c
@@ -189,8 +189,8 @@ ocp_device_resume(struct device *dev)
struct bus_type ocp_bus_type = {
.name = "ocp",
.match = ocp_device_match,
- .probe = ocp_driver_probe,
- .remove = ocp_driver_remove,
+ .probe = ocp_device_probe,
+ .remove = ocp_device_remove,
.suspend = ocp_device_suspend,
.resume = ocp_device_resume,
};
--
0.99.9.GIT
^ permalink raw reply related
* How can I install uuid library?
From: Jongmin Yoon @ 2006-02-08 1:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi, I'm newbie in this field...
Now, I'm porting some file systems to ppc core.
I met the messages "FATAL ERROR: could not find a valid UUID header. Install
the Universally Unique Identifiers development package."
I use crosstool and linux-2.6.14, how can I install that library?
Regards,
^ permalink raw reply
* Membership stats (Was: Re: merge these lists?)
From: Stephen Rothwell @ 2006-02-08 0:07 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20060208110150.5d9d1936.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On Wed, 8 Feb 2006 11:01:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Yes, "a sysadmin" could do that. However, those that are
> subscribed with different addresses on each list will end
> up subscribed twice and those who have changed their preferences on
> the abondoned list will have fix them as well.
Just for interest:
members of linuxppc-dev 473
members of linuxppc64-dev 264
common 98
But, as I said, "common" above does not count those who have different
addresses subscribed to each list.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: merge these lists?
From: Stephen Rothwell @ 2006-02-08 0:01 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20060207164305.GI24916@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
On Tue, 7 Feb 2006 10:43:05 -0600 linas@austin.ibm.com (Linas Vepstas) wrote:
>
> 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?
Yes, "a sysadmin" could do that. However, those that are
subscribed with different addresses on each list will end
up subscribed twice and those who have changed their preferences on
the abondoned list will have fix them as well.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Artesyn Processor PMC 'Host Bridge' has no IRQ assigned?
From: David Hawkins @ 2006-02-07 23:03 UTC (permalink / raw)
To: Travis B. Sawyer; +Cc: linuxppc-embedded
In-Reply-To: <43E92584.1000007@sandburst.com>
Hi Travis,
> 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.
Yeah, thats pretty much the 'way of PCI', so I was surprized
not to see the IRQ line assigned from the x86 host-side.
> 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).
Oh, perhaps the comment was that you had used the board then :)
> I'd have to check the u-boot source for PrPMC support, as I
> haven't run u-boot on it.
No sweat, if I want to put U-Boot on it, then I'll just have to
port it :) Since the Artesyn bootloader can tftp etc, I'll
figure out first how to get Linux booted.
I just booted up the second board, and it did not get
an IRQ either. I'll dig into the CPC700 manual, its likely
a boot-time enable.
Thanks for the feedback!
Dave
^ permalink raw reply
* Re: MPC875 using SCC4 together with both FECs
From: Pantelis Antoniou @ 2006-02-07 23:01 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <2b580ad2e66bb31541226d5353babedb@embeddedalley.com>
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
On 2/7/06, Dan Malek <dan@embeddedalley.com> wrote:
>
>
> On Feb 7, 2006, at 5:24 PM, dibacco@@inwind..it wrote:
>
> > 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 of FEC0).
>
> That's a correct observation, you can't do it. I don't remember
> and don't have documentation handy, but would it work in
> RMII mode? Otherwise, you will have to step up to the MPC870.
>
>
> -- Dan
IIRC it can in RMII mode...
Don't hold me on that however, no manual and no time to look.
Pantelis
[-- Attachment #2: Type: text/html, Size: 1000 bytes --]
^ permalink raw reply
* Re: MPC875 using SCC4 together with both FECs
From: Dan Malek @ 2006-02-07 22:59 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUC8X2$BBAE28486C091C5CAA95431276FDABE5@libero.it>
On Feb 7, 2006, at 5:24 PM, dibacco@@inwind..it wrote:
> 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 of FEC0).
That's a correct observation, you can't do it. I don't remember
and don't have documentation handy, but would it work in
RMII mode? Otherwise, you will have to step up to the MPC870.
-- Dan
^ permalink raw reply
* 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
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