* Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: Peter Korsgaard @ 2008-04-02 9:51 UTC (permalink / raw)
To: John Linn; +Cc: git, linuxppc-embedded
In-Reply-To: <20080401234142.41B13191804A@mail111-sin.bigfish.com>
>>>>> "John" == John Linn <John.Linn@xilinx.com> writes:
John> I pushed PowerPC 440 support to the Xilinx Git server with
John> support for ppc arch and with powerpc arch support coming in
John> the near future.
Neat, but why have you added arch/ppc support? It's supposed to go
away pretty much by the time the hardware gets in the hand of
developers.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Ishizaki Kou @ 2008-04-02 10:52 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1206652101.10388.28.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > As you said, if read/write/in/out functions take device parameter,
> > taking I/O function pointers into the dev_archdata structure should be
> > the best solution. But they don't take device parameter, and they must
> > search I/O function pointers with address parameter. I think it's
> > better they search pointers from bus bridges, because access mothod
> > for a device on its parent bus bridge, not device itself.
>
> What I meant is that if the pointers are in dev_archdata, we can
> populate with a different set of pointers for PCI vs. PCI-E.
I'm afraid I misunderstood your opinion.
My concern is how to find a device by address when I/O function
pointers are in dev_archdata.
You must select the appropriate device with an address, because all
I/O functions, read/write/in/out don't have device parameter. If the
address is in MMIO space, you can set 'token' to the address to select
the device. But in IO space, you can't set 'token' to the I/O port
address. Thefore you must scan all devices to select the device.
Do you have any better solution?
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-04-02 11:00 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080402.195215.-1300526901.kouish@swc.toshiba.co.jp>
On Wed, 2008-04-02 at 19:52 +0900, Ishizaki Kou wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > As you said, if read/write/in/out functions take device parameter,
> > > taking I/O function pointers into the dev_archdata structure should be
> > > the best solution. But they don't take device parameter, and they must
> > > search I/O function pointers with address parameter. I think it's
> > > better they search pointers from bus bridges, because access mothod
> > > for a device on its parent bus bridge, not device itself.
> >
> > What I meant is that if the pointers are in dev_archdata, we can
> > populate with a different set of pointers for PCI vs. PCI-E.
>
> I'm afraid I misunderstood your opinion.
>
> My concern is how to find a device by address when I/O function
> pointers are in dev_archdata.
>
> You must select the appropriate device with an address, because all
> I/O functions, read/write/in/out don't have device parameter. If the
> address is in MMIO space, you can set 'token' to the address to select
> the device. But in IO space, you can't set 'token' to the I/O port
> address. Thefore you must scan all devices to select the device.
>
> Do you have any better solution?
No, you are right. The EEH code has a way to go back to the device but
it has significant overhead. Let's stick to your current approach.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
From: Benjamin Herrenschmidt @ 2008-04-02 11:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1207129830.10910.25.camel@johannes.berg>
On Wed, 2008-04-02 at 11:50 +0200, Johannes Berg wrote:
> > This serie of patches adds lockdep support for 64 bits
> > powerpc. Dale's patch for 32 bits still need me to review
> > and test it which I'll try to do asap.
>
> Yay. I'll give it another try later today.
Haven't tested this version on G5 yet btw :-) (though I had a previous
one working internally). I tested on POWER6 pSeries and old iSeries
(spent a while fixing the later).
I'll run more tests tomorrow hopefully and add a few patch fixing
some of the issues that lockdep already starting showing.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] RTAS - adapt procfs interface
From: Jens Osterkamp @ 2008-04-02 11:33 UTC (permalink / raw)
To: Nathan Lynch; +Cc: maxim, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <20080401163504.GP7137@localdomain>
On Tuesday 01 April 2008, Nathan Lynch wrote:
> Jens Osterkamp wrote:
> >
> > Handling of the proc_dir_entry->count has being changed in 2.6.24-rc5.
>
> Do you know which commit caused the change?
Yes, we bisected it to the following commit :
commit 5a622f2d0f86b316b07b55a4866ecb5518dd1cf7
Author: Alexey Dobriyan <adobriyan@sw.ru>
Date: Tue Dec 4 23:45:28 2007 -0800
proc: fix proc_dir_entry refcounting
Creating PDEs with refcount 0 and "deleted" flag has problems (see below).
Switch to usual scheme:
* PDE is created with refcount 1
* every de_get does +1
* every de_put() and remove_proc_entry() do -1
* once refcount reaches 0, PDE is freed.
This elegantly fixes at least two following races (both observed) without
introducing new locks, without abusing old locks, without spreading
lock_kernel():
[...]
Gruß,
Jens
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Re: [PATCH] RTAS - adapt procfs interface
From: Jens Osterkamp @ 2008-04-02 11:34 UTC (permalink / raw)
To: Nathan Lynch; +Cc: maxim, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <20080401200404.GS7137@localdomain>
On Tuesday 01 April 2008, Nathan Lynch wrote:
> Nathan Lynch wrote:
> >
> > One could argue that the real problem is using the proc_dir_entry's
> > reference count to enforce exclusive open.
>
>
> I think this is better... the way these files are used is lame, but
> this should preserve the existing behavior. I haven't yet tested
> this, can you?
I did and it works for me...
>
>
> diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
> index f227659..00bc308 100644
> --- a/arch/powerpc/kernel/rtas_flash.c
> +++ b/arch/powerpc/kernel/rtas_flash.c
> @@ -139,7 +139,7 @@ struct rtas_validate_flash_t
> unsigned int update_results; /* Update results token */
> };
>
> -static DEFINE_SPINLOCK(flash_file_open_lock);
> +static atomic_t open_count = ATOMIC_INIT(0);
> static struct proc_dir_entry *firmware_flash_pde;
> static struct proc_dir_entry *firmware_update_pde;
> static struct proc_dir_entry *validate_pde;
> @@ -216,7 +216,7 @@ static int rtas_flash_release(struct inode *inode, struct file *file)
> uf->flist = NULL;
> }
>
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
> return 0;
> }
>
> @@ -352,26 +352,17 @@ static ssize_t rtas_flash_write(struct file *file, const char __user *buffer,
>
> static int rtas_excl_open(struct inode *inode, struct file *file)
> {
> - struct proc_dir_entry *dp = PDE(inode);
> -
> - /* Enforce exclusive open with use count of PDE */
> - spin_lock(&flash_file_open_lock);
> - if (atomic_read(&dp->count) > 1) {
> - spin_unlock(&flash_file_open_lock);
> + if (atomic_inc_return(&open_count) > 1) {
> + atomic_dec(&open_count);
> return -EBUSY;
> }
>
> - atomic_inc(&dp->count);
> - spin_unlock(&flash_file_open_lock);
> -
> return 0;
> }
>
> static int rtas_excl_release(struct inode *inode, struct file *file)
> {
> - struct proc_dir_entry *dp = PDE(inode);
> -
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
>
> return 0;
> }
> @@ -580,7 +571,7 @@ static int validate_flash_release(struct inode *inode, struct file *file)
> }
>
> /* The matching atomic_inc was in rtas_excl_open() */
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
>
> return 0;
> }
>
Gruß,
Jens
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Re: Please pull from 'for-2.6.25' branch
From: Paul Mackerras @ 2008-04-02 11:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev list, Linus Torvalds
In-Reply-To: <D9513606-E9BC-4D20-BB2E-7CCD3D9CEDAA@kernel.crashing.org>
Kumar Gala writes:
> Paul, any comments on sending this onto linus. I was hoping to avoid
> 2.6.25 coming up not support the proper device bindings for DMA and
> SATA.
I've pulled it and I'll send it on later (or Linus can pull it
directly if he wants). There is the iSeries fix from Ben H plus two
other patches (one from Bartlomiej Sieka and one from Nathan Lynch)
where I'm waiting for proper patch descriptions and/or signed-off-by
lines. I was hoping to get those tomorrow and send the lot on to
Linus.
Paul.
^ permalink raw reply
* Re: [PATCH] RTAS - adapt procfs interface
From: Paul Mackerras @ 2008-04-02 11:48 UTC (permalink / raw)
To: Nathan Lynch; +Cc: maxim, cbe-oss-dev, linuxppc-dev
In-Reply-To: <20080401200404.GS7137@localdomain>
Nathan Lynch writes:
> I think this is better... the way these files are used is lame, but
> this should preserve the existing behavior. I haven't yet tested
> this, can you?
Looks OK -- can I have a proper patch description and a signed-off-by
line for this please?
Paul.
^ permalink raw reply
* Quick patch for ucc_geth, add copybreak and move TX processing to soft IRQ
From: Joakim Tjernlund @ 2008-04-02 11:48 UTC (permalink / raw)
To: 'linuxppc-dev Development', Netdev
This is a quick hack to make ucc_geth handle a
ping -f -l 10 gracefully. Without it, the CPU will lockup during the ping flood.
I don't have time ATM to clean it up, but if anyone wants to he is welcome :)
Commenst on the geleral approach is wanted though, why do I need to move TX
processing to soft IRQ to make the system response under heavy load?
Kernel 2.6.23
Jocke
---
drivers/net/ucc_geth.c | 85 +++++++++++++++++++++++++++++++++--------------
1 files changed, 59 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 038ec75..b74b298 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -73,6 +73,11 @@ static struct {
module_param_named(debug, debug.msg_enable, int, 0);
MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 0xffff=all)");
+#define COPYBREAK_DEFAULT 256
+static unsigned int copybreak __read_mostly = COPYBREAK_DEFAULT;
+MODULE_PARM_DESC(copybreak,
+ "Maximum size of packet that is copied to a new buffer on receive");
+
static struct ucc_geth_info ugeth_primary_info = {
.uf_info = {
.bd_mem_part = MEM_PART_MURAM,
@@ -3380,14 +3385,12 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
#ifdef CONFIG_UGETH_TX_ON_DEMAND
struct ucc_fast_private *uccf;
#endif
- u8 *bd; /* BD pointer */
+ u8 *bd, *bd_ptr; /* BD pointer */
u32 bd_status;
u8 txQ = 0;
ugeth_vdbg("%s: IN", __FUNCTION__);
- spin_lock_irq(&ugeth->lock);
-
ugeth->stats.tx_bytes += skb->len;
/* Start from the next BD that should be filled */
@@ -3401,16 +3404,18 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
(ugeth->skb_curtx[txQ] +
1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
- /* set up the buffer descriptor */
- out_be32(&((struct qe_bd *)bd)->buf,
- dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE));
+ bd_ptr = dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE);
/* printk(KERN_DEBUG"skb->data is 0x%x\n",skb->data); */
bd_status = (bd_status & T_W) | T_R | T_I | T_L | skb->len;
+ spin_lock_irq(&ugeth->lock);
+ /* set up the buffer descriptor */
+ out_be32(&((struct qe_bd *)bd)->buf, bd_ptr);
/* set bd status and length */
out_be32((u32 *)bd, bd_status);
+ spin_unlock_irq(&ugeth->lock);
dev->trans_start = jiffies;
@@ -3427,8 +3432,6 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
netif_stop_queue(dev);
}
- ugeth->txBd[txQ] = bd;
-
if (ugeth->p_scheduler) {
ugeth->cpucount[txQ]++;
/* Indicate to QE that there are more Tx bds ready for
@@ -3442,7 +3445,7 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
uccf = ugeth->uccf;
out_be16(uccf->p_utodr, UCC_FAST_TOD);
#endif
- spin_unlock_irq(&ugeth->lock);
+ ugeth->txBd[txQ] = bd;
return 0;
}
@@ -3454,6 +3457,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
u16 length, howmany = 0;
u32 bd_status;
u8 *bdBuffer;
+ struct sk_buff *new_skb;
ugeth_vdbg("%s: IN", __FUNCTION__);
@@ -3467,6 +3471,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
bdBuffer = (u8 *) in_be32(&((struct qe_bd *)bd)->buf);
length = (u16) ((bd_status & BD_LENGTH_MASK) - 4);
skb = ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]];
+ new_skb = NULL;
/* determine whether buffer is first, last, first and last
(single buffer frame) or middle (not first and not last) */
@@ -3484,6 +3489,21 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
} else {
ugeth->stats.rx_packets++;
howmany++;
+ if (length < copybreak) {
+ new_skb =
+ netdev_alloc_skb(ugeth->dev, length + NET_IP_ALIGN);
+ if (new_skb) {
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ skb_copy_to_linear_data_offset(new_skb,
+ -NET_IP_ALIGN,
+ (skb->data -
+ NET_IP_ALIGN),
+ (length +
+ NET_IP_ALIGN));
+ skb = new_skb;
+ out_be32((u32 *)bd, (R_E | R_I | (in_be32((u32 *)bd) & R_W)));
+ }
+ }
/* Prep the skb for the packet */
skb_put(skb, length);
@@ -3502,16 +3522,17 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
ugeth->dev->last_rx = jiffies;
- skb = get_new_skb(ugeth, bd);
- if (!skb) {
- if (netif_msg_rx_err(ugeth))
- ugeth_warn("%s: No Rx Data Buffer", __FUNCTION__);
- ugeth->stats.rx_dropped++;
- break;
- }
-
- ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = skb;
+ if (!new_skb) {
+ skb = get_new_skb(ugeth, bd);
+ if (!skb) {
+ if (netif_msg_rx_err(ugeth))
+ ugeth_warn("%s: No Rx Data Buffer", __FUNCTION__);
+ ugeth->stats.rx_dropped++;
+ break;
+ }
+ ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = skb;
+ }
/* update to point at the next skb */
ugeth->skb_currx[rxQ] =
(ugeth->skb_currx[rxQ] +
@@ -3535,6 +3556,7 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
struct ucc_geth_private *ugeth = netdev_priv(dev);
u8 *bd; /* BD pointer */
u32 bd_status;
+ int howmany = 0;
bd = ugeth->confBd[txQ];
bd_status = in_be32((u32 *)bd);
@@ -3547,12 +3569,17 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
if ((bd == ugeth->txBd[txQ]) && (netif_queue_stopped(dev) == 0))
break;
-
+ howmany++;
ugeth->stats.tx_packets++;
/* Free the sk buffer associated with this TxBD */
+#ifdef CONFIG_UGETH_NAPI
+ dev_kfree_skb(ugeth->
+ tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]);
+#else
dev_kfree_skb_irq(ugeth->
tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]);
+#endif
ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]] = NULL;
ugeth->skb_dirtytx[txQ] =
(ugeth->skb_dirtytx[txQ] +
@@ -3570,7 +3597,7 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
bd_status = in_be32((u32 *)bd);
}
ugeth->confBd[txQ] = bd;
- return 0;
+ return howmany;
}
#ifdef CONFIG_UGETH_NAPI
@@ -3596,6 +3623,12 @@ static int ucc_geth_poll(struct net_device *dev, int *budget)
howmany += ucc_geth_rx(ugeth, i, rx_work_limit);
}
+ spin_lock(&ugeth->lock);
+ for (i = 0; i < ug_info->numQueuesTx; i++) {
+ ucc_geth_tx(dev, i);
+ }
+ spin_unlock(&ugeth->lock);
+
dev->quota -= howmany;
rx_work_limit -= howmany;
*budget -= howmany;
@@ -3604,7 +3637,7 @@ static int ucc_geth_poll(struct net_device *dev, int *budget)
netif_rx_complete(dev);
uccf = ugeth->uccf;
uccm = in_be32(uccf->p_uccm);
- uccm |= UCCE_RX_EVENTS;
+ uccm |= UCCE_RX_EVENTS | UCCE_TX_EVENTS;
out_be32(uccf->p_uccm, uccm);
}
@@ -3641,10 +3674,10 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
out_be32(uccf->p_ucce, ucce);
/* check for receive events that require processing */
- if (ucce & UCCE_RX_EVENTS) {
+ if (ucce & (UCCE_RX_EVENTS | UCCE_TX_EVENTS)) {
#ifdef CONFIG_UGETH_NAPI
if (netif_rx_schedule_prep(dev)) {
- uccm &= ~UCCE_RX_EVENTS;
+ uccm &= ~(UCCE_RX_EVENTS | UCCE_TX_EVENTS);
out_be32(uccf->p_uccm, uccm);
__netif_rx_schedule(dev);
}
@@ -3658,7 +3691,7 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
}
#endif /* CONFIG_UGETH_NAPI */
}
-
+#ifndef CONFIG_UGETH_NAPI
/* Tx event processing */
if (ucce & UCCE_TX_EVENTS) {
spin_lock(&ugeth->lock);
@@ -3671,7 +3704,7 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
}
spin_unlock(&ugeth->lock);
}
-
+#endif
/* Errors and other events */
if (ucce & UCCE_OTHER) {
if (ucce & UCCE_BSY) {
@@ -3959,7 +3992,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
dev->watchdog_timeo = TX_TIMEOUT;
#ifdef CONFIG_UGETH_NAPI
dev->poll = ucc_geth_poll;
- dev->weight = UCC_GETH_DEV_WEIGHT;
+ dev->weight = UCC_GETH_DEV_WEIGHT*2;
#endif /* CONFIG_UGETH_NAPI */
dev->stop = ucc_geth_close;
dev->get_stats = ucc_geth_get_stats;
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Geert Uytterhoeven @ 2008-04-02 11:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <451ABD36-3763-4AF0-B24B-AF043393A72C@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1929 bytes --]
On Tue, 1 Apr 2008, Kumar Gala wrote:
> On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
> >Kumar Gala writes:
> > >Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in
> > >places that before would have caused recursive includes.
> > >
> > >For example to use phys_addr_t in <asm/page.h> we would have included
> > ><asm/mmu.h> which would have possibly included <asm/mmu-hash64.h> which
> > >includes <asm/page.h>. Wheeee recursive include.
> >
> >In general this looks fine. I wonder if you should use u64 rather
> >than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit machines
> >(which is itself somewhat counterintuitive) we will actually use
> >unsigned long on 64-bit machines, so it matters less than I originally
> >thought, but it would be worth explaining that in a comment and/or the
> >commit message.
>
> We could change it to be:
>
> /* Physical address used by some IO functions */
> #if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
> typedef u64 phys_addr_t;
> #else
> typedef u32 phys_addr_t;
> #endif
>
> This seems a bit more self documenting which is always nice (and I can add a
> comment in the commit message about CONFIG_PHYS_64BIT only making sense on
> ppc32).
If it's counterintuitive that CONFIG_PHYS_64BIT=n on 64-bit machines, why
not set it to =y in Kconfig?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* RE: [PATCH] Add Fixed PHY support for ucc_geth
From: Joakim Tjernlund @ 2008-04-02 12:15 UTC (permalink / raw)
To: Li Yang; +Cc: Netdev, Jeff Garzik, Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <989B956029373F45A0B8AF029708189001D1954D@zch01exm26.fsl.freescale.net>
On Fri, 2008-03-21 at 16:51 +0800, Li Yang wrote:
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
> > Sent: Tuesday, March 18, 2008 5:47 PM
> > To: Netdev; Li Yang; Linuxppc-Embedded@Ozlabs.Org
> > Cc: Joakim Tjernlund
> > Subject: [PATCH] Add Fixed PHY support for ucc_geth
> >
> > The new Fixed PHY method, fixed-link property, isn't
> > impl. for ucc_geth which makes fixed PHYs non functional.
> > Add support for the new method to restore the Fixed PHY
> > functionality.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> Signed-off-by: Li Yang <leoli@freescale.com>
>
> ---
> Ps: This patch depends on the patch "ucc_geth: use correct thread number
> for 10/100Mbps link" to apply, which hasn't made to Linus' tree for now
> but has already been in Jeff and David's trees.
What happened to this patch? It is not in Linus tree.
Jocke
^ permalink raw reply
* Re: [PATCH 2/4] [POWERPC] lockdep stacktrace support
From: Stephen Rothwell @ 2008-04-02 12:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20080402075254.24539DDEDD@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]
On Wed, 02 Apr 2008 18:52:10 +1100 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
>
> +++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02 16:46:07.000000000 +1100
> @@ -0,0 +1,52 @@
> +
Copyight and license statement needed.
> +#include <linux/sched.h>
> +#include <linux/stacktrace.h>
You should include <asm/ptrace.h> for STACK_FRAME_OVERHEAD and struct pt_regs.
> +#ifdef CONFIG_PPC64
> +#define MIN_STACK_FRAME 112 /* same as STACK_FRAME_OVERHEAD, in fact */
So use STACK_FRAME_OVERHEAD?
> +#define FRAME_LR_SAVE 2
> +#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288)
^^^^^^^^^^^^^^^^^^^^
Its used here already ...
> +#define REGS_MARKER 0x7265677368657265ul
Maybe we need to put REGS_MARKER into a header file as it already appears
in two assembly files and two C files.
--
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: [PATCH 1/4] [POWERPC] Initialize paca->current earlier
From: Stephen Rothwell @ 2008-04-02 12:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20080402075253.8726ADDEDD@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Wed, 02 Apr 2008 18:52:09 +1100 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
>
> This changes it so that all PACAs are statically initialized with
> __current pointing to the init task. For non-0 CPUs, this is fixed
> up before use.
You might want to see how this impacts on Tony Breed's 1024 way patches.
--
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: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Kumar Gala @ 2008-04-02 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0804021352580.20994@vixen.sonytel.be>
On Apr 2, 2008, at 6:53 AM, Geert Uytterhoeven wrote:
> On Tue, 1 Apr 2008, Kumar Gala wrote:
>> On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
>>> Kumar Gala writes:
>>>> Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can
>>>> use it in
>>>> places that before would have caused recursive includes.
>>>>
>>>> For example to use phys_addr_t in <asm/page.h> we would have
>>>> included
>>>> <asm/mmu.h> which would have possibly included <asm/mmu-hash64.h>
>>>> which
>>>> includes <asm/page.h>. Wheeee recursive include.
>>>
>>> In general this looks fine. I wonder if you should use u64 rather
>>> than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit
>>> machines
>>> (which is itself somewhat counterintuitive) we will actually use
>>> unsigned long on 64-bit machines, so it matters less than I
>>> originally
>>> thought, but it would be worth explaining that in a comment and/or
>>> the
>>> commit message.
>>
>> We could change it to be:
>>
>> /* Physical address used by some IO functions */
>> #if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
>> typedef u64 phys_addr_t;
>> #else
>> typedef u32 phys_addr_t;
>> #endif
>>
>> This seems a bit more self documenting which is always nice (and I
>> can add a
>> comment in the commit message about CONFIG_PHYS_64BIT only making
>> sense on
>> ppc32).
>
> If it's counterintuitive that CONFIG_PHYS_64BIT=n on 64-bit
> machines, why
> not set it to =y in Kconfig?
Its not that it =n, its that its not available. The Kconfig looks like:
config PHYS_64BIT
bool 'Large physical address support' if E500
depends on 44x || E500
select RESOURCES_64BIT
default y if 44x
We could set it to y on PPC64 as there is no harm there, but Paul
would need to say he wants that done.
- k
^ permalink raw reply
* Re: Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-04-02 13:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev list, Linus Torvalds
In-Reply-To: <18419.29305.168659.363143@cargo.ozlabs.ibm.com>
On Apr 2, 2008, at 6:48 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Paul, any comments on sending this onto linus. I was hoping to avoid
>> 2.6.25 coming up not support the proper device bindings for DMA and
>> SATA.
>
> I've pulled it and I'll send it on later (or Linus can pull it
> directly if he wants). There is the iSeries fix from Ben H plus two
> other patches (one from Bartlomiej Sieka and one from Nathan Lynch)
> where I'm waiting for proper patch descriptions and/or signed-off-by
> lines. I was hoping to get those tomorrow and send the lot on to
> Linus.
Ok, just wasn't sure what the status was. A day or two is fine.
- k
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Kumar Gala @ 2008-04-02 13:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18418.55835.338209.611273@cargo.ozlabs.ibm.com>
On Apr 1, 2008, at 7:58 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Hmm, need to think about that. But my initial reaction is two fold.
>> One I don't think this information would be around and two don't we
>> already have this problem with a kdump kernel?
>
> I'm just concerned that we have two things that have to match up - the
> compiled-in physical address that the kernel assumes it is running at,
> and the physical address where it is actually loaded. While those two
> things were both always 0 for embedded processors, there wasn't a
> problem, but now we can have a situation where a kernel binary has to
> be loaded at some nonzero address to work correctly, but there is no
> way to work out what that address is for an existing vmlinux binary.
> Or have I missed something?
Nope, that sums up the situation pretty well.
> For a kdump kernel, at least for 64-bit, the physical address has to
> be 32MB. There is no other choice, so there is no possibility of
> confusion.
But how do you know a vmlinux image is for kdump or not?
> For 85xx, would it be possible to have the kernel figure out what
> physical address it has been loaded at, and use that as the base
> address, rather than having the base address set at compile time?
Yes, that is what CONFIG_RELOCATABLE is all about.
> That would solve my objection since it would mean that there would no
> longer be two things that had to be kept in sync. You could pass any
> value to wrapper/mkimage (subject to constraints such as it has to be
> a multiple of 256M) and it would work. That value could even come
> from a config option in the case where wrapper is invoked as part of
> the kernel build, but that config option shouldn't affect anything at
> all in the vmlinux.
Ok, but I still think the issues exists when we config PHYSICAL_START
to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys
address the PHDR, but I'm not sure how to get the linker to do that.
- k
^ permalink raw reply
* Re: psc and spi
From: S. Fricke @ 2008-04-02 13:06 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801150651s213a745dwa4d595de5a9d191b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]
Hello,
> On 1/15/08, S. Fricke <silvio.fricke@googlemail.com> wrote:
> > Hello friends,
> >
> > I have on the psc3 the spi-interface of a fpga connected.
> >
> > psc3-0 - MOSI
> > psc3-1 - MISO
> > psc3-2 - CLK
> > psc3-3 - SlaveSelect
> > psc3-4 - CS-FPGA
> > psc3-5 - CS Another device
> > psc3-6 - SPI-SEL0
> > psc3-7 - SPI-SEL1
> > psc3-8/9 - Not connected
> >
> > Can I use the mpc52xx_psc_spi-driver? And if yes, how I have to use this
> > driver? Or must I write a own spi-master/slave thing? Can anyone point me
> > to a good start-position?
>
> Yes, you should be able to use the mpc52xx_psc_spi driver. You'' need
> to add the activate_cs and deactivate_cs hooks in your platform code
> to activate your SPI CS lines. You'll also need to set port_config to
> have the PSC3 pins in "CODEC3" mode.
OK, I defined a "fsl_spi_platform_data" for my "activate_cs" and
"deactivate_cs". This structure I have insert in a "spi_board_info" with
all other mandatory Informations.
When I load "mpc52xx_psc_spi", then I get a "mpc52xx-psc-spi f0002400.spi:
probe called without platform data, no (de)activate_cs function will be
called"
What is wrong in my setup or did I have forget something?
static void activate_cs(u8 cs, u8 polarity) {/* ... */ }
static void deactivate_cs(u8 cs, u8 polarity) {/* ...*/}
static struct fsl_spi_platform_data my_spi_p_data = {
.bus_num = 0x2400,
.max_chipselect = 3,
.activate_cs = activate_cs,
.deactivate_cs = deactivate_cs,
};
static struct spi_board_info my_spi_boardinfo = {
.bus_num = 0x2400,
.chip_select = 0,
.max_speed_hz = 1000,
.modalias = "my-spi-device",
.platform_data = &my_spi_p_data,
};
static int __init ipek01_spi_init(void) {
int ret;
return fsl_spi_init(&my_spi_boardinfo, 1, activate_cs, deactivate_cs);
}
device_initcall(ipek01_spi_init);
best regards,
Silvio Fricke
--
-- S. Fricke ------------------------------------ silvio.fricke@gmail.com --
Diplom-Informatiker (FH) TEL: (+49)8330-911278
Linux-Entwicklung JABBER: silvio@conversation.port1024.net
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
From: Johannes Berg @ 2008-04-02 13:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1207134128.10388.254.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
> Haven't tested this version on G5 yet btw :-) (though I had a previous
> one working internally). I tested on POWER6 pSeries and old iSeries
> (spent a while fixing the later).
>
> I'll run more tests tomorrow hopefully and add a few patch fixing
> some of the issues that lockdep already starting showing.
Works fine, and on my box I don't see lockdep showing issues.
Thanks for picking this up from me and rewriting it :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2 v5] Add DIU platform code for MPC8610HPCD
From: York Sun @ 2008-04-02 13:27 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, a.p.zijlstra, linux-kernel, linuxppc-dev,
scottwood, timur
In-Reply-To: <20080401140029.be918d87.akpm@linux-foundation.org>
On Tue, 2008-04-01 at 14:00 -0700, Andrew Morton wrote:
> On Mon, 31 Mar 2008 11:23:25 -0500
> York Sun <yorksun@freescale.com> wrote:
>
> > Add platform code to support Freescale DIU. The platform code includes
> > framebuffer memory allocation, pixel format, monitor port, etc.
> >
> > Signed-off-by: York Sun <yorksun@freescale.com>
> > Signed-off-by: Timur Tabi <timur@freescale.com>
> > ---
> > This patch addes platform support for Freescale DIU driver, targeting 2.6.26 kernel.
> >
> > arch/powerpc/configs/mpc8610_hpcd_defconfig | 198 +++++++++++++++++++++++----
> > arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 190 ++++++++++++++++++++++++--
> > arch/powerpc/sysdev/fsl_soc.c | 41 ++++++
> > arch/powerpc/sysdev/fsl_soc.h | 23 +++
> > 4 files changed, 413 insertions(+), 39 deletions(-)
>
> The defconfig change gets almost 100% rejects and probably isn't
> appropriate here and isn't very important. I dropped that part of the
> patch.
>
It's OK.
York
^ permalink raw reply
* ARCH=ppc vs powerpc
From: Guillaume Dargaud @ 2008-04-02 14:13 UTC (permalink / raw)
To: linuxppc-dev
Anyone care to comment on that:
$ make ARCH=ppc linux26-menuconfig
[ -f
/home/guinevere/buildroot/project_build_ppc/genepy/linux-2.6.24/.config ] |
| cp local/genepy/linux-2.6.24.config
/home/guinevere/buildroot/project_build_pp
c/genepy/linux-2.6.24/.config
/usr/bin/make -j1 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=powerpc
[...]
Why does ARCH change ?!?
[...]
.config:132:warning: trying to assign nonexistent symbol XILINX_ML405
[...]
$ find -name Kconfig -exec grep -H XILINX_ML405 {} \;
./toolchain_build_powerpc/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
./project_build_ppc/genepy/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
./toolchain_build_ppc/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
Well, it's no surprise that it won't find them if it looks in the powerpc
branch...
The question is why ?
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc
From: Johannes Berg @ 2008-04-02 14:15 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20080201195040.GA8950@farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Fri, 2008-02-01 at 12:50 -0700, Dale Farnsworth wrote:
> This adds the low level irq tracing hooks for 32-bit powerpc.
> This patch applies on top of Benjamin Herrenschmidt's patch that
> provides similar support for 64-bit powerpc. See
> <http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044361.html>
>
> It seems to work on my prpmc2800 board with a ppc7447.
At first it appears to work on my powerbook (with Ben's latest version
of the 64-bit patch), but then it seems to cause random corruption, I've
had a crash in the ext3 code and one in console_callback(), both of
which I cannot otherwise explain.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* printk time confusion?
From: Johannes Berg @ 2008-04-02 14:23 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Arnd Bergmann, Benjamin Herrenschmidt
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
Hi,
Not sure whether the lockdep patches or something else is causing this
as I haven't checked w/o the patches yet, but I seem to be having some
confusion of printk timestamps:
[...]
[ 176.440255] iwl4965: No space for Tx
[...]
[ 147.983705] ioctl32(gnome-terminal:6361): Unknown cmd fd(25) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/2
[...]
[ 173.589209] BUG kmalloc-2048: Poison overwritten
[...]
[ 208.385226] ioctl32(gnome-terminal:6498): Unknown cmd fd(29) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/6
[...]
[ 139.026724] ioctl32(gnome-terminal:6521): Unknown cmd fd(30) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe8) on /dev/pts/7
[...]
[ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
[...]
[ 218.918388] tg3: eth0: Link is down.
[...]
Yes, these entries really were printed in that order. Btw, what's with
the unknown ioctls?
Kernel version is 2.6.25-rc8-wl-04519-g6648ff7-dirty where -wl/-dirty
refers to wireless patches and the lockdep patches and otherwise it's
just -rc8.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [RESEND3 PATCH] [POWERPC] mpc5200: Amalgamated DTS fixes and updates
From: Bartlomiej Sieka @ 2008-04-02 14:26 UTC (permalink / raw)
To: linuxppc-dev
DTS updates that fix booting problems:
- change to ethernet reg property
- addition of mdio and phy nodes
- removal of pci node (Motion-Pro board)
Other DTS updates:
- update i2c device tree nodes
- add lpb bus node and flash device (without partitions defined)
- add rtc i2c nodes
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
Changes since previous submission:
- added patch description
- added a space between "phy0:" and "ethernet-phy" per David Gibson's
suggestion.
arch/powerpc/boot/dts/cm5200.dts | 37 ++++++++++++++++++++-
arch/powerpc/boot/dts/motionpro.dts | 63 +++++++++++++++++++----------------
arch/powerpc/boot/dts/tqm5200.dts | 42 +++++++++++++++++++++++
3 files changed, 112 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..c6ca631 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -212,13 +212,30 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
@@ -231,4 +248,22 @@
reg = <8000 4000>;
};
};
+
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 fc000000 2000000>;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 2000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..2b0dde0 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -148,7 +148,6 @@
interrupt-parent = <&mpc5200_pic>;
};
-
spi@f00 {
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
reg = <f00 20>;
@@ -209,10 +208,25 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0: ethernet-phy@2 {
+ device_type = "ethernet-phy";
+ reg = <2>;
+ };
};
ata@3a00 {
@@ -223,11 +237,19 @@
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
+
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "dallas,ds1339";
+ reg = <68>;
+ };
};
sram@8000 {
@@ -240,7 +262,8 @@
compatible = "fsl,lpb";
#address-cells = <2>;
#size-cells = <1>;
- ranges = <1 0 50000000 00010000
+ ranges = <0 0 ff000000 01000000
+ 1 0 50000000 00010000
2 0 50010000 00010000
3 0 50020000 00010000>;
@@ -271,31 +294,15 @@
compatible = "promess,pro_module_dio";
reg = <3 800 2>;
};
- };
- pci@f0000d00 {
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
- reg = <f0000d00 100>;
- interrupt-map-mask = <f800 0 0 7>;
- interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
- c000 0 0 2 &mpc5200_pic 1 1 3
- c000 0 0 3 &mpc5200_pic 1 2 3
- c000 0 0 4 &mpc5200_pic 1 3 3
-
- c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
- c800 0 0 2 &mpc5200_pic 1 2 3
- c800 0 0 3 &mpc5200_pic 1 3 3
- c800 0 0 4 &mpc5200_pic 0 0 3>;
- clock-frequency = <0>; // From boot loader
- interrupts = <2 8 0 2 9 0 2 a 0>;
- interrupt-parent = <&mpc5200_pic>;
- bus-range = <0 0>;
- ranges = <42000000 0 80000000 80000000 0 20000000
- 02000000 0 a0000000 a0000000 0 10000000
- 01000000 0 00000000 b0000000 0 01000000>;
+ // 16-bit flash device at LocalPlus Bus CS0
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 01000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
index c86464f..65bcea6 100644
--- a/arch/powerpc/boot/dts/tqm5200.dts
+++ b/arch/powerpc/boot/dts/tqm5200.dts
@@ -127,10 +127,25 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
};
ata@3a00 {
@@ -141,11 +156,19 @@
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
+
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "dallas,ds1307";
+ reg = <68>;
+ };
};
sram@8000 {
@@ -154,6 +177,23 @@
};
};
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 fc000000 02000000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 02000000>;
+ bank-width = <4>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
+ };
+
pci@f0000d00 {
#interrupt-cells = <1>;
#size-cells = <2>;
^ permalink raw reply related
* Re: Please pull powerpc.git merge branch
From: Bartlomiej Sieka @ 2008-04-02 14:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18418.49494.457893.866627@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Bartlomiej Sieka writes:
>
>> What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't
>> see it in the merge branch of your repository, and it would be nice to
>> get it upstream as it fixes boot problems on some MPC5200-based boards.
>
> It needs a proper stand-alone commit message and an acked-by from
> Grant. The commit message should explain why you are making the
> changes you are making rather than just saying "the bulk of this patch
> is taken from http://...".
Paul,
Just re-sent the patch, please see
http://patchwork.ozlabs.org/linuxppc/patch?id=17678; hopefully
everything is OK now.
(Note that I've dropped torvalds@linux-foundation.org,
akpm@linux-foundation.org and linux-kernel@vger.kernel.org from the CC:)
Regards,
Bartlomiej
^ permalink raw reply
* [PATCH] powerpc: Fix CPM2 SCC1 clock initialization.
From: Laurent Pinchart @ 2008-04-02 14:46 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
A missing break statement in a switch caused cpm2_clk_setup() to initialize
SCC2 instead of SCC1. This patch fixes the bug.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
arch/powerpc/sysdev/cpm2.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 57ed1a4..7478e81 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -246,6 +246,7 @@ int cpm2_clk_setup(enum cpm_clk_target target, int clock, int mode)
case CPM_CLK_SCC1:
reg = &im_cpmux->cmx_scr;
shift = 24;
+ break;
case CPM_CLK_SCC2:
reg = &im_cpmux->cmx_scr;
shift = 16;
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox