* kexec: proc/device-tree/chosen/linux,kernel-end: No such file or directory
From: Geert Uytterhoeven @ 2009-03-31 16:25 UTC (permalink / raw)
To: Linux/PPC Development
With today's kernel, I can no longer kexec any kernel on PS3:
| /proc/device-tree/chosen/linux,kernel-end: No such file or directory
| Could not get memory layout
Today's bad version: 15f7176eb1cccec0a332541285ee752b935c1c85
Yesterday's good version: 0d34fb8e93ceba7b6dad0062dbb4a0813bacd75b
Before I start bisecting (tomorrow or the day thereafter), anyone with an idea?
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre 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/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: Patch: Fix fec_mpc52xx driver to use net_device_ops
From: Grant Likely @ 2009-03-31 16:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linuxppc-dev, Henk Stegeman, David Miller, netdev
In-Reply-To: <20090331074806.432a882a@nehalam>
On Tue, Mar 31, 2009 at 8:48 AM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Tue, 31 Mar 2009 12:44:15 +0200
> Henk Stegeman <henk.stegeman@gmail.com> wrote:
>
>> Fix fec_mpc52xx driver to use net_device_ops and to be careful not to
>> dereference phy_device if a phy has not yet been connected.
>>
>> Signed-off-by: Henk Stegeman <henk.stegeman@gmail.com>
Hi Henk,
I hadn't heard from you for a while about the signed-off-by line, but
I really needed to get those changes queued because the 2.6.30 merge
window is open now, and some of my patches depend on it. I ended up
rewriting your patch from scratch, testing it and posting it last
night.
I would really like to stick with the rewritten version since it is a
little tighter, and it is the one I've got tested. However, now that
I've heard from you, I'm happy to change the patch author credit to
you. You should look on the list for the patches I sent out last
night (labeled [PATCH 02/14] and [PATCH 03/14]) and reply to each of
them with an "Acked-by:" line if they look good to you.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Patch: Fix fec_mpc52xx driver to use net_device_ops
From: Grant Likely @ 2009-03-31 16:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linuxppc-dev, Henk Stegeman, netdev
In-Reply-To: <20090331074806.432a882a@nehalam>
On Tue, Mar 31, 2009 at 8:48 AM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Tue, 31 Mar 2009 12:44:15 +0200
>> +static const struct net_device_ops mpc52xx_fec_netdev_ops =3D {
>> + =A0 =A0 =A0 .ndo_open =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D mpc52xx_fec_open=
,
>> + =A0 =A0 =A0 .ndo_stop =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D mpc52xx_fec_clos=
e,
>> + =A0 =A0 =A0 .ndo_start_xmit =A0 =A0 =A0 =A0 =3D mpc52xx_fec_hard_start=
_xmit,
>> + =A0 =A0 =A0 .ndo_tx_timeout =A0 =A0 =A0 =A0 =3D mpc52xx_fec_tx_timeout=
,
>> + =A0 =A0 =A0 .ndo_get_stats =A0 =A0 =A0 =A0 =A0=3D mpc52xx_fec_get_stat=
s,
>> + =A0 =A0 =A0 .ndo_set_multicast_list =3D mpc52xx_fec_set_multicast_list=
,
>> + =A0 =A0 =A0 .ndo_validate_addr =A0 =A0 =A0=3D eth_validate_addr,
>> + =A0 =A0 =A0 .ndo_set_mac_address =A0 =A0=3D mpc52xx_fec_set_mac_addres=
s,
>> + =A0 =A0 =A0 .ndo_do_ioctl =A0 =A0 =A0 =A0 =A0 =3D mpc52xx_fec_ioctl,
>>
> What about change_mtu? Don't you want:
> =A0 =A0 =A0 =A0 =A0.ndo_change_mtu =A0 =A0 =A0 =A0 =3D eth_change_mtu,
Yes, you're right. fixed.
Thanks,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] fsl_pq_mdio: Revive UCC MDIO support
From: Anton Vorontsov @ 2009-03-31 18:33 UTC (permalink / raw)
To: David Miller
Cc: netdev, Li Yang, Andy Fleming, Joakim Tjernlund, linuxppc-dev
commit 1577ecef766650a57fceb171acee2b13cbfaf1d3 ("netdev: Merge UCC
and gianfar MDIO bus drivers") introduced a regression so that UCC
MDIO buses no longer work.
This is because fsl_pq_mdio driver wrongly masks all non-TBI PHYs
for !fsl,gianfar-mdio buses, while it should do that only for
fsl,gianfar-tbi buses.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/fsl_pq_mdio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index b3079a5..d9e1ecf 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -387,7 +387,7 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
* The TBIPHY-only buses will find PHYs at every address,
* so we mask them all but the TBI
*/
- if (!of_device_is_compatible(np, "fsl,gianfar-mdio"))
+ if (of_device_is_compatible(np, "fsl,gianfar-tbi"))
new_bus->phy_mask = ~(1 << tbiaddr);
err = mdiobus_register(new_bus);
--
1.5.6.5
^ permalink raw reply related
* Problem with module_init?
From: Sean MacLennan @ 2009-03-31 18:37 UTC (permalink / raw)
To: linuxppc-dev
With the latest from Linus' tree, I get the following oops:
Oops: Kernel access of bad area, sig: 11 [#1]
Warp
Modules linked in: simple(+)
NIP: d14b8000 LR: c0001420 CTR: 00000000
REGS: cf2a1df0 TRAP: 0400 Not tainted (2.6.29-pika)
MSR: 00029000 <EE,ME,CE> CR: 24000022 XER: 00000000
TASK = cf896100[1673] 'insmod' THREAD: cf2a0000
GPR00: 00000000 cf2a1ea0 cf896100 d14b8000 00000001 d14b5360 ffffffff
00000000 GPR08: c03312fc c03312fc c0546018 c0546018 24000022 100872cc
0ffa7d00 007fff99 GPR16: 00400450 00800000 007fff00 0ffa7cec 00000000
ffffffff 00000000 1008323c GPR24: 10083254 00000000 c0330000 c0310000
c03110a4 d14b8000 cf2a0000 d14b5360 NIP [d14b8000] simple_init+0x0/0x8
[simple] LR [c0001420] do_one_initcall+0x34/0x1a0
Call Trace:
[cf2a1f20] [c0045e18] sys_init_module+0xb0/0x1b8
[cf2a1f40] [c000dbbc] ret_from_syscall+0x0/0x3c
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX <38600000> 4e800020 XXXXXXXX
XXXXXXXX ---[ end trace 9ac3b092cfc75a75 ]---
This is the entire driver:
#include <linux/module.h>
static int __init simple_init(void)
{
return 0;
}
module_init(simple_init);
static void __exit simple_exit(void)
{
}
module_exit(simple_exit);
MODULE_DESCRIPTION("simple driver");
MODULE_LICENSE("GPL");
Has something changed for module?
Cheers,
Sean
^ permalink raw reply
* [PATCH] ucc_geth: Pass proper device to DMA routines, otherwise oops happens
From: Anton Vorontsov @ 2009-03-31 18:58 UTC (permalink / raw)
To: David Miller
Cc: netdev, Li Yang, Andy Fleming, Joakim Tjernlund, linuxppc-dev
The driver should pass a device that actually specifies internal DMA
ops, but currently it passes netdev's device, which is wrong and that
causes following oops:
Kernel BUG at c01c4df8 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
[...]
NIP [c01c4df8] get_new_skb+0x7c/0xf8
LR [c01c4da4] get_new_skb+0x28/0xf8
Call Trace:
[ef82be00] [c01c4da4] get_new_skb+0x28/0xf8 (unreliable)
[ef82be20] [c01c4eb8] rx_bd_buffer_set+0x44/0x98
[ef82be40] [c01c62bc] ucc_geth_startup+0x11b0/0x147c
[ef82be80] [c01c6674] ucc_geth_open+0xec/0x2a4
[ef82bea0] [c02288a4] dev_open+0xc0/0x11c
[...]
Fix this by passing of_device's device that specifies DMA ops in its
archdata.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 21 +++++++++++----------
drivers/net/ucc_geth.h | 3 ++-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 933fcfb..3ed402c 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -223,10 +223,10 @@ static struct sk_buff *get_new_skb(struct ucc_geth_private *ugeth,
(((unsigned)skb->data) & (UCC_GETH_RX_DATA_BUF_ALIGNMENT -
1)));
- skb->dev = ugeth->dev;
+ skb->dev = ugeth->ndev;
out_be32(&((struct qe_bd __iomem *)bd)->buf,
- dma_map_single(&ugeth->dev->dev,
+ dma_map_single(ugeth->dev,
skb->data,
ugeth->ug_info->uf_info.max_rx_buf_length +
UCC_GETH_RX_DATA_BUF_ALIGNMENT,
@@ -1872,7 +1872,7 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
continue;
for (j = 0; j < ugeth->ug_info->bdRingLenTx[i]; j++) {
if (ugeth->tx_skbuff[i][j]) {
- dma_unmap_single(&ugeth->dev->dev,
+ dma_unmap_single(ugeth->dev,
in_be32(&((struct qe_bd __iomem *)bd)->buf),
(in_be32((u32 __iomem *)bd) &
BD_LENGTH_MASK),
@@ -1900,7 +1900,7 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
bd = ugeth->p_rx_bd_ring[i];
for (j = 0; j < ugeth->ug_info->bdRingLenRx[i]; j++) {
if (ugeth->rx_skbuff[i][j]) {
- dma_unmap_single(&ugeth->dev->dev,
+ dma_unmap_single(ugeth->dev,
in_be32(&((struct qe_bd __iomem *)bd)->buf),
ugeth->ug_info->
uf_info.max_rx_buf_length +
@@ -3071,7 +3071,7 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* set up the buffer descriptor */
out_be32(&((struct qe_bd __iomem *)bd)->buf,
- dma_map_single(&ugeth->dev->dev, skb->data,
+ dma_map_single(ugeth->dev, skb->data,
skb->len, DMA_TO_DEVICE));
/* printk(KERN_DEBUG"skb->data is 0x%x\n",skb->data); */
@@ -3127,7 +3127,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
ugeth_vdbg("%s: IN", __func__);
- dev = ugeth->dev;
+ dev = ugeth->ndev;
/* collect received buffers */
bd = ugeth->rxBd[rxQ];
@@ -3161,7 +3161,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
skb_put(skb, length);
/* Tell the skb what kind of packet this is */
- skb->protocol = eth_type_trans(skb, ugeth->dev);
+ skb->protocol = eth_type_trans(skb, ugeth->ndev);
dev->stats.rx_bytes += length;
/* Send the packet up the stack */
@@ -3432,7 +3432,7 @@ static int ucc_geth_close(struct net_device *dev)
ucc_geth_stop(ugeth);
- free_irq(ugeth->ug_info->uf_info.irq, ugeth->dev);
+ free_irq(ugeth->ug_info->uf_info.irq, ugeth->ndev);
netif_stop_queue(dev);
@@ -3446,7 +3446,7 @@ static void ucc_geth_timeout_work(struct work_struct *work)
struct net_device *dev;
ugeth = container_of(work, struct ucc_geth_private, timeout_work);
- dev = ugeth->dev;
+ dev = ugeth->ndev;
ugeth_vdbg("%s: IN", __func__);
@@ -3756,7 +3756,8 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
memcpy(dev->dev_addr, mac_addr, 6);
ugeth->ug_info = ug_info;
- ugeth->dev = dev;
+ ugeth->dev = device;
+ ugeth->ndev = dev;
ugeth->node = np;
return 0;
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index e3a25e6..a6f5d0b 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1129,7 +1129,8 @@ struct ucc_geth_info {
struct ucc_geth_private {
struct ucc_geth_info *ug_info;
struct ucc_fast_private *uccf;
- struct net_device *dev;
+ struct device *dev;
+ struct net_device *ndev;
struct napi_struct napi;
struct work_struct timeout_work;
struct ucc_geth __iomem *ug_regs;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] net/fec_mpc52xx: fix BUG on missing dma_ops
From: Becky Bruce @ 2009-03-31 18:58 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, galak, David Miller, linuxppc-dev
In-Reply-To: <20090331022428.26151.55232.stgit@localhost.localdomain>
On Mar 30, 2009, at 9:25 PM, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> The driver triggers a BUG_ON() when allocating DMA buffers if the
> arch/powerpc dma_ops from the of_platform device are not copied
> into net_device structure.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Becky, does this look better to you?
Reviewed-by: Becky Bruce <beckyb@kernel.crashing.org>
I think this is OK now, and Kumar agrees....
Thanks!
B
>
>
> g.
>
> drivers/net/fec_mpc52xx.c | 19 ++++++++++++-------
> 1 files changed, 12 insertions(+), 7 deletions(-)
>
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index 049b0a7..f99463f 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -129,7 +129,8 @@ static void mpc52xx_fec_free_rx_buffers(struct
> net_device *dev, struct bcom_task
> struct sk_buff *skb;
>
> skb = bcom_retrieve_buffer(s, NULL, (struct bcom_bd **)&bd);
> - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
> + dma_unmap_single(dev->dev.parent, bd->skb_pa, skb->len,
> + DMA_FROM_DEVICE);
> kfree_skb(skb);
> }
> }
> @@ -150,7 +151,7 @@ static int mpc52xx_fec_alloc_rx_buffers(struct
> net_device *dev, struct bcom_task
> bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
>
> bd->status = FEC_RX_BUFFER_SIZE;
> - bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> + bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> bcom_submit_next_buffer(rxtsk, skb);
> @@ -388,7 +389,8 @@ static int mpc52xx_fec_hard_start_xmit(struct
> sk_buff *skb, struct net_device *d
> bcom_prepare_next_buffer(priv->tx_dmatsk);
>
> bd->status = skb->len | BCOM_FEC_TX_BD_TFD | BCOM_FEC_TX_BD_TC;
> - bd->skb_pa = dma_map_single(&dev->dev, skb->data, skb->len,
> DMA_TO_DEVICE);
> + bd->skb_pa = dma_map_single(dev->dev.parent, skb->data, skb->len,
> + DMA_TO_DEVICE);
>
> bcom_submit_next_buffer(priv->tx_dmatsk, skb);
>
> @@ -430,7 +432,8 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int
> irq, void *dev_id)
> struct bcom_fec_bd *bd;
> skb = bcom_retrieve_buffer(priv->tx_dmatsk, NULL,
> (struct bcom_bd **)&bd);
> - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_TO_DEVICE);
> + dma_unmap_single(dev->dev.parent, bd->skb_pa, skb->len,
> + DMA_TO_DEVICE);
>
> dev_kfree_skb_irq(skb);
> }
> @@ -455,7 +458,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
>
> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> (struct bcom_bd **)&bd);
> - dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len,
> DMA_FROM_DEVICE);
> + dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
> + DMA_FROM_DEVICE);
>
> /* Test for errors in received frame */
> if (status & BCOM_FEC_RX_BD_ERRORS) {
> @@ -464,7 +468,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
> bcom_prepare_next_buffer(priv->rx_dmatsk);
>
> bd->status = FEC_RX_BUFFER_SIZE;
> - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> + bd->skb_pa = dma_map_single(dev->dev.parent,
> + rskb->data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
> @@ -499,7 +504,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
> bcom_prepare_next_buffer(priv->rx_dmatsk);
>
> bd->status = FEC_RX_BUFFER_SIZE;
> - bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> + bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> bcom_submit_next_buffer(priv->rx_dmatsk, skb);
^ permalink raw reply
* Re: [PATCH v4 1/4] NAND: FSL-UPM: add multi chip support
From: Anton Vorontsov @ 2009-03-31 19:05 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <20090330100554.947307803@denx.de>
On Mon, Mar 30, 2009 at 12:02:42PM +0200, Wolfgang Grandegger wrote:
> This patch adds support for multi-chip NAND devices to the FSL-UPM
> driver. This requires support for multiple GPIOs for the RNB pins.
> The NAND chips are selected through address lines defined by the
> FDT property "fsl,upm-addr-line-cs-offsets".
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
^ permalink raw reply
* Re: [PATCH v4 2/4] NAND: FSL-UPM: Add wait flags to support board/chip specific delays
From: Anton Vorontsov @ 2009-03-31 19:05 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <20090330100555.111388782@denx.de>
On Mon, Mar 30, 2009 at 12:02:43PM +0200, Wolfgang Grandegger wrote:
> The NAND flash on the TQM8548_BE modules requires a short delay after
> running the UPM pattern. The TQM8548_BE requires a further short delay
> after writing out a buffer. Normally the R/B pin should be checked, but
> it's not connected on the TQM8548_BE. The existing driver uses similar
> fixed delay points. To manage these extra delays in a more general way,
> I introduced the "fsl,ump-wait-flags" property allowing the board-
> specific driver to specify various types of extra delay.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
^ permalink raw reply
* Re: [PATCH v4 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Anton Vorontsov @ 2009-03-31 19:06 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <20090330100555.282048633@denx.de>
On Mon, Mar 30, 2009 at 12:02:44PM +0200, Wolfgang Grandegger wrote:
> This patch adds documentation for the new NAND FSL UPM bindings for:
>
> NAND: FSL-UPM: add multi chip support
> NAND: FSL-UPM: Add wait flags to support board/chip specific delays
>
> It also documents the old binding for "chip-delay".
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
^ permalink raw reply
* Re: [PATCH] net/fec_mpc52xx: fix BUG on missing dma_ops
From: Grant Likely @ 2009-03-31 19:10 UTC (permalink / raw)
To: Becky Bruce; +Cc: netdev, galak, David Miller, linuxppc-dev
In-Reply-To: <0947433F-BDDA-48D8-A59C-BCF321EE465C@kernel.crashing.org>
Thanks Becky.
g.
2009/3/31 Becky Bruce <beckyb@kernel.crashing.org>:
>
> On Mar 30, 2009, at 9:25 PM, Grant Likely wrote:
>
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> The driver triggers a BUG_ON() when allocating DMA buffers if the
>> arch/powerpc dma_ops from the of_platform device are not copied
>> into net_device structure.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> Becky, does this look better to you?
>
> Reviewed-by: Becky Bruce <beckyb@kernel.crashing.org>
>
> I think this is OK now, and Kumar agrees....
>
> Thanks!
> B
>
>>
>>
>> g.
>>
>> drivers/net/fec_mpc52xx.c | =A0 19 ++++++++++++-------
>> 1 files changed, 12 insertions(+), 7 deletions(-)
>>
>>
>> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
>> index 049b0a7..f99463f 100644
>> --- a/drivers/net/fec_mpc52xx.c
>> +++ b/drivers/net/fec_mpc52xx.c
>> @@ -129,7 +129,8 @@ static void mpc52xx_fec_free_rx_buffers(struct
>> net_device *dev, struct bcom_task
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct sk_buff *skb;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0skb =3D bcom_retrieve_buffer(s, NULL, (st=
ruct bcom_bd
>> **)&bd);
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&dev->dev, bd->skb_pa, sk=
b->len,
>> DMA_FROM_DEVICE);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(dev->dev.parent, bd->skb_=
pa, skb->len,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DMA_FRO=
M_DEVICE);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kfree_skb(skb);
>> =A0 =A0 =A0 =A0}
>> }
>> @@ -150,7 +151,7 @@ static int mpc52xx_fec_alloc_rx_buffers(struct
>> net_device *dev, struct bcom_task
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bd =3D (struct bcom_fec_bd *)bcom_prepare=
_next_buffer(rxtsk);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bd->status =3D FEC_RX_BUFFER_SIZE;
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(&dev->dev, s=
kb->data,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(dev->dev.par=
ent, skb->data,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FEC_RX_BU=
FFER_SIZE, DMA_FROM_DEVICE);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_submit_next_buffer(rxtsk, skb);
>> @@ -388,7 +389,8 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buf=
f
>> *skb, struct net_device *d
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_prepare_next_buffer(priv->tx_dmatsk)=
;
>>
>> =A0 =A0 =A0 =A0bd->status =3D skb->len | BCOM_FEC_TX_BD_TFD | BCOM_FEC_T=
X_BD_TC;
>> - =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(&dev->dev, skb->data, skb->l=
en,
>> DMA_TO_DEVICE);
>> + =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(dev->dev.parent, skb->data, =
skb->len,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DM=
A_TO_DEVICE);
>>
>> =A0 =A0 =A0 =A0bcom_submit_next_buffer(priv->tx_dmatsk, skb);
>>
>> @@ -430,7 +432,8 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq,
>> void *dev_id)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct bcom_fec_bd *bd;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0skb =3D bcom_retrieve_buffer(priv->tx_dma=
tsk, NULL,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(struct b=
com_bd **)&bd);
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&dev->dev, bd->skb_pa, sk=
b->len,
>> DMA_TO_DEVICE);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(dev->dev.parent, bd->skb_=
pa, skb->len,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DMA_TO_=
DEVICE);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_kfree_skb_irq(skb);
>> =A0 =A0 =A0 =A0}
>> @@ -455,7 +458,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq,
>> void *dev_id)
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rskb =3D bcom_retrieve_buffer(priv->rx_dm=
atsk, &status,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(struct b=
com_bd **)&bd);
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&dev->dev, bd->skb_pa, rs=
kb->len,
>> DMA_FROM_DEVICE);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(dev->dev.parent, bd->skb_=
pa, rskb->len,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DMA_FRO=
M_DEVICE);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Test for errors in received frame */
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (status & BCOM_FEC_RX_BD_ERRORS) {
>> @@ -464,7 +468,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq,
>> void *dev_id)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_prep=
are_next_buffer(priv->rx_dmatsk);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bd->status =3D FEC_RX_BUF=
FER_SIZE;
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_sin=
gle(&dev->dev, rskb->data,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_sin=
gle(dev->dev.parent,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 rskb->data,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0FEC_RX_BUFFER_SIZE,
>> DMA_FROM_DEVICE);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_submit_next_buffer(p=
riv->rx_dmatsk, rskb);
>> @@ -499,7 +504,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq,
>> void *dev_id)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_prepare_next_buffer(=
priv->rx_dmatsk);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bd->status =3D FEC_RX_BUFFER_SIZE;
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(&dev->dev, s=
kb->data,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(dev->dev.par=
ent, skb->data,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FEC_RX_BU=
FFER_SIZE, DMA_FROM_DEVICE);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_submit_next_buffer(priv->rx_dmatsk, =
skb);
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* MPC83xx console
From: Matthew L. Creech @ 2009-03-31 19:15 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm trying to get Linux booting on a custom board based on the MPC8313
ERDB, but there's no output after the console is transferred. I get
the following:
Using MPC831x RDB machine description
Linux version 2.6.29 (mlcreech@lap) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-50
) ) #2 PREEMPT Tue Mar 31 14:54:27 EDT 2009
console [udbg0] enabled
... (normal boot output) ...
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
If I boot with "console=udbg0,115200", then it gets much further along
before printing "turn off boot console udbg0". So presumably the
kernel is booting beyond this point, but my console isn't printing any
output. I traced from that last line back up the call stack to the
end of drivers/serial/8250.c:serial8250_init(), and everything seems
okay (it returns 0, and pritnk() still works fine at that point). I'm
not sure where to go from there to figure out where the problem lies.
Could someone point me in the right direction, or suggest what might
cause a console problem like this?
Thanks!
--
Matthew L. Creech
^ permalink raw reply
* Re: [PATCH 3/8] powerpc/85xx: Add support for the "socrates" board (MPC8544).
From: Wolfgang Grandegger @ 2009-03-31 19:20 UTC (permalink / raw)
To: Grant Likely
Cc: Sergei Poselenov, devicetree-discuss, Ilya Yanok, Dmitry Rakhchev,
linuxppc-dev, Anatolij Gustschin
In-Reply-To: <fa686aa40903310857w57b9d020i71d56f33ede4e875@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> On Tue, Mar 31, 2009 at 6:37 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Supported are Ethernet, serial console, I2C, I2C-based RTC and
>> temperature sensors, NOR and NAND flash, PCI, USB, CAN and Lime
>> display controller.
>>
>> The multiplexing of FPGA interrupts onto PowerPC interrupt lines is
>> supported through our own fpga_pic interrupt controller driver.
>>
>> For example the SJA1000 controller is level low sensitive connected to
>> fpga_pic line 2 and is routed to the second (of three) irq lines to
>> the CPU:
>>
>> can@3,100 {
>> compatible = "philips,sja1000";
>> reg = <3 0x100 0x80>;
>> interrupts = <2 2>;
>> interrupts = <2 8 1>; // number, type, routing
>> interrupt-parent = <&fpga_pic>;
>> };
>>
>> Signed-off-by: Sergei Poselenov <sposelenov@emcraft.com>
>> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> Signed-off-by: Dmitry Rakhchev <rda@emcraft.com>
>> ---
>> arch/powerpc/boot/dts/socrates.dts | 338 +++++
>> arch/powerpc/configs/85xx/socrates_defconfig | 1410 ++++++++++++++++++++++++
>
> I always ask this question: Do you really need a board specific
> defconfig file? We are multiplatform now.
>
>> arch/powerpc/platforms/85xx/Kconfig | 6
>> arch/powerpc/platforms/85xx/Makefile | 1
>> arch/powerpc/platforms/85xx/socrates.c | 133 ++
>> arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 327 +++++
>> arch/powerpc/platforms/85xx/socrates_fpga_pic.h | 16
>
> socrates_fpga_pic is only ever going to be used by socrates.c. I'd
> roll the two socrates.c files into one and eliminate the header file.
>
>> Index: linux-2.6/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-2.6/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
> [...]
>> +struct socrates_fpga_irq_info {
>> + unsigned int irq_line;
>> + int type;
>> +};
>> +
>> +/*
>> + * Interrupt routing and type table
>> + *
>> + * IRQ_TYPE_NONE means the interrupt type is configurable,
>> + * otherwise it's fixed to the specified value.
>> + */
>> +static struct socrates_fpga_irq_info fpga_irqs[SOCRATES_FPGA_NUM_IRQS] = {
>> + [0] = {0, IRQ_TYPE_NONE},
>> + [1] = {0, IRQ_TYPE_LEVEL_HIGH},
>> + [2] = {0, IRQ_TYPE_LEVEL_LOW},
>> + [3] = {0, IRQ_TYPE_NONE},
>> + [4] = {0, IRQ_TYPE_NONE},
>> + [5] = {0, IRQ_TYPE_NONE},
>> + [6] = {0, IRQ_TYPE_NONE},
>> + [7] = {0, IRQ_TYPE_NONE},
>> + [8] = {0, IRQ_TYPE_LEVEL_HIGH},
>> +};
>
> It is good practice to use named elements in initializers: {.type =
> IRQ_TYPE_LEVEL_HIGH},
>
> Static variables are initialized to zero. Everything that is 0 can be
> dropped from this initializer (lines 0 and 3-7, and the irq_line
> field).
Right, missed that.
This is one of the patches I sent accidentally. I think Kumar already
applied it to his tree.
Sorry for the noise.
Wolfgang.
^ permalink raw reply
* [PATCH v2] powerpc: i2c-mpc: preserve I2C clocking
From: Wolfgang Grandegger @ 2009-03-31 20:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
The i2c node property "fsl,preserve-clocking" allows to overtake the
clock settings from the boot loader avoiding the hard-coded settings.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
Documentation/powerpc/dts-bindings/fsl/i2c.txt | 2 ++
drivers/i2c/busses/i2c-mpc.c | 20 +++++++++++---------
2 files changed, 13 insertions(+), 9 deletions(-)
Index: linux-2.6/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- linux-2.6.orig/drivers/i2c/busses/i2c-mpc.c 2009-03-31 13:25:08.000000000 +0200
+++ linux-2.6/drivers/i2c/busses/i2c-mpc.c 2009-03-31 21:29:21.615721143 +0200
@@ -323,13 +323,6 @@
if (!i2c)
return -ENOMEM;
- if (of_get_property(op->node, "dfsrr", NULL))
- i2c->flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- if (of_device_is_compatible(op->node, "fsl,mpc5200-i2c") ||
- of_device_is_compatible(op->node, "mpc5200-i2c"))
- i2c->flags |= FSL_I2C_DEV_CLOCK_5200;
-
init_waitqueue_head(&i2c->queue);
i2c->base = of_iomap(op->node, 0);
@@ -348,8 +341,17 @@
goto fail_request;
}
}
-
- mpc_i2c_setclock(i2c);
+
+ if (!of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
+ if (of_get_property(op->node, "dfsrr", NULL))
+ i2c->flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
+
+ if (of_device_is_compatible(op->node, "fsl,mpc5200-i2c") ||
+ of_device_is_compatible(op->node, "mpc5200-i2c"))
+ i2c->flags |= FSL_I2C_DEV_CLOCK_5200;
+
+ mpc_i2c_setclock(i2c);
+ }
dev_set_drvdata(&op->dev, i2c);
Index: linux-2.6/Documentation/powerpc/dts-bindings/fsl/i2c.txt
===================================================================
--- linux-2.6.orig/Documentation/powerpc/dts-bindings/fsl/i2c.txt 2009-03-17 10:28:07.000000000 +0100
+++ linux-2.6/Documentation/powerpc/dts-bindings/fsl/i2c.txt 2009-03-31 21:35:51.527901532 +0200
@@ -20,6 +20,8 @@
a digital filter sampling rate register
- fsl5200-clocking : boolean; if defined, indicated that this device
uses the FSL 5200 clocking mechanism.
+ - fsl,preserve-clocking : boolean; if defined, the clock settings
+ from the bootloader are preserved (not touched).
Example :
i2c@3000 {
^ permalink raw reply
* Re: 8641D with linux 2.6.29 did'n show second cpu
From: Becky Bruce @ 2009-03-31 20:04 UTC (permalink / raw)
To: Eduard Fuchs; +Cc: linuxppc-dev
In-Reply-To: <200903311706.55478.edfuchs@uni-kassel.de>
On Mar 31, 2009, at 10:06 AM, Eduard Fuchs wrote:
> Hi,
>
> Am Dienstag 31 M=E4rz 2009 15:20:21 schrieb Kumar Gala:
>> On Mar 31, 2009, at 5:15 AM, Eduard Fuchs wrote:
>>> Hi,
>>>
>>> I'm testing the evaluation board from freescale (MPC8641DHPCN) with
>>> the latest
>>> linux kernel (2.6.29) and the second core seems disabled. CONFIG_SPM
>>> is
>>> enabled but the /proc/cpuinfo shows only one cpu. With original
>>> 2.6.27 kernel
>>> both cpu cores appears in /proc/cpuinfo.
>>>
>>> Has anyone an idea how can i enable the second core?
>>
>> Are you using u-boot? I can't remember if you need a newer u-boot to
>> deal with changes in how we bring up the second core.
>
> Yes. My u-boot version is 2009.03. Are there some additional config =20=
> keys for
> SMP support in u-boot?
Hrm, I am able to reproduce this here - the second processor is =20
reported as stuck and once we're booted, I only see one CPU online. =20
Let me poke around and see if I can figure out what's going on here.
Cheers,
Becky
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: i2c-mpc: preserve I2C clocking
From: Wolfgang Grandegger @ 2009-03-31 20:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c
In-Reply-To: <fa686aa40903310844j11a85fb6w3558923e12670ba9@mail.gmail.com>
Grant Likely wrote:
> 2009/3/31 Wolfram Sang <w.sang@pengutronix.de>:
>>>>> -
>>>>> - mpc_i2c_setclock(i2c);
>>>>> +
>>>>> + if (set_clock)
>>>>> + mpc_i2c_setclock(i2c);
>>>> Can't we drop 'set_clock' with something like this here?
>>>>
>>>> + if (!of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
>>>> +
>>>> + if (of_get_property(op->node, "dfsrr", NULL))
>>>> + i2c->flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
>>>> +
>>>> + if (of_device_is_compatible(op->node, "fsl,mpc5200-i2c") ||
>>>> + of_device_is_compatible(op->node, "mpc5200-i2c"))
>>>> + i2c->flags |= FSL_I2C_DEV_CLOCK_5200;
>>>> +
>>>> + mpc_i2c_setclock(i2c);
>>>> + }
>>> No, because the I2C registers are not yet mapped.
>> Sorry, I used misleading words :) With 'here' I meant 'at this
>> position', i.e. insert my above block where mpc_i2c_setclock was used
>> anyway.
>
> I agree. The extra flag makes the flow more complex. The code block
> should be moved down.
OK, I just resent the patch standalone also including documentation. I
think it can go in immediately without waiting for the full clock
setting patch.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v2] powerpc: i2c-mpc: preserve I2C clocking
From: Grant Likely @ 2009-03-31 20:24 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <49D2767E.4080607@grandegger.com>
On Tue, Mar 31, 2009 at 2:01 PM, Wolfgang Grandegger <wg@grandegger.com> wr=
ote:
> The i2c node property "fsl,preserve-clocking" allows to overtake the
> clock settings from the boot loader avoiding the hard-coded settings.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0Documentation/powerpc/dts-bindings/fsl/i2c.txt | =A0 =A02 ++
> =A0drivers/i2c/busses/i2c-mpc.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0=
20 +++++++++++---------
> =A02 files changed, 13 insertions(+), 9 deletions(-)
>
> Index: linux-2.6/drivers/i2c/busses/i2c-mpc.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-2.6.orig/drivers/i2c/busses/i2c-mpc.c 2009-03-31 13:25:08.00000=
0000 +0200
> +++ linux-2.6/drivers/i2c/busses/i2c-mpc.c =A0 =A0 =A02009-03-31 21:29:21=
.615721143 +0200
> @@ -323,13 +323,6 @@
> =A0 =A0 =A0 =A0if (!i2c)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENOMEM;
>
> - =A0 =A0 =A0 if (of_get_property(op->node, "dfsrr", NULL))
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 i2c->flags |=3D FSL_I2C_DEV_SEPARATE_DFSRR;
> -
> - =A0 =A0 =A0 if (of_device_is_compatible(op->node, "fsl,mpc5200-i2c") ||
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_device_is_compatible(op-=
>node, "mpc5200-i2c"))
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 i2c->flags |=3D FSL_I2C_DEV_CLOCK_5200;
> -
> =A0 =A0 =A0 =A0init_waitqueue_head(&i2c->queue);
>
> =A0 =A0 =A0 =A0i2c->base =3D of_iomap(op->node, 0);
> @@ -348,8 +341,17 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail_request;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0}
> -
> - =A0 =A0 =A0 mpc_i2c_setclock(i2c);
> +
> + =A0 =A0 =A0 if (!of_get_property(op->node, "fsl,preserve-clocking", NUL=
L)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (of_get_property(op->node, "dfsrr", NULL=
))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i2c->flags |=3D FSL_I2C_DEV=
_SEPARATE_DFSRR;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (of_device_is_compatible(op->node, "fsl,=
mpc5200-i2c") ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_device_is_compatible(op->node, "=
mpc5200-i2c"))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i2c->flags |=3D FSL_I2C_DEV=
_CLOCK_5200;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc_i2c_setclock(i2c);
> + =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0dev_set_drvdata(&op->dev, i2c);
>
> Index: linux-2.6/Documentation/powerpc/dts-bindings/fsl/i2c.txt
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-2.6.orig/Documentation/powerpc/dts-bindings/fsl/i2c.txt =A0 =A0=
=A0 2009-03-17 10:28:07.000000000 +0100
> +++ linux-2.6/Documentation/powerpc/dts-bindings/fsl/i2c.txt =A0 =A02009-=
03-31 21:35:51.527901532 +0200
> @@ -20,6 +20,8 @@
> =A0 =A0a digital filter sampling rate register
> =A0- fsl5200-clocking : boolean; if defined, indicated that this device
> =A0 =A0uses the FSL 5200 clocking mechanism.
> + - fsl,preserve-clocking : boolean; if defined, the clock settings
> + =A0 from the bootloader are preserved (not touched).
>
> =A0Example :
> =A0 =A0 =A0 =A0i2c@3000 {
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [PATCH 4/6] powerpc: Add mmc-spi-slot bindings
From: Yann Pelletier @ 2009-03-31 20:36 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Original post:
Anton Vorontsov avorontsov at ru.mvista.com
Sat Jan 24 06:50:37 EST 2009
Sorry if this looks crappy, it's paste from web archive since I was not on =
the list at that time.
I've applied this patch set [1 to 6] to enable SPI device to be listed in t=
he device tree instead of platform kernel file.
It is working fine but ...
> The bindings describes a case where MMC/SD/SDIO slot directly connected
> to a SPI bus. Such setups are widely used on embedded PowerPC boards.
>
> The patch also adds the mmc-spi-slot entry to the OpenFirmware modalias
> table.
>
> Signed-off-by: Anton Vorontsov <avorontsov at ru.mvista.com>
> ---
> .../powerpc/dts-bindings/mmc-spi-slot.txt | 23
> ++++++++++++++++++++
> drivers/of/base.c | 1 +
> 2 files changed, 24 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/mmc-spi-slot.txt
>
> diff --git a/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt=20
> b/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt
> new file mode 100644
> index 0000000..c39ac28
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt
> @@ -0,0 +1,23 @@
> +MMC/SD/SDIO slot directly connected to a SPI bus
> +
> +Required properties:
> +- compatible : should be "mmc-spi-slot".
> +- reg : should specify SPI address (chip-select number).
> +- spi-max-frequency : maximum frequency for this device (Hz).
> +- voltage-ranges : two cells are required, first cell specifies minimum
> + slot voltage (mV), second cell specifies maximum slot voltage (mV).
> + Several ranges could be specified.
> +- gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO,
> + Write-Protect GPIO.
> +
> +Example:
> +
> + mmc-slot at 0 {
> + compatible =3D "fsl,mpc8323rdb-mmc-slot",
> + "mmc-spi-slot";
> + reg =3D <0>;
> + gpios =3D <&qe_pio_d 14 1
> + &qe_pio_d 15 0>;
> + voltage-ranges =3D <3300 3300>;
> + spi-max-frequency =3D <50000000>;
> + };
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index cd17092..41c5dfd 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -446,6 +446,7 @@ struct of_modalias_table {
> };
> static struct of_modalias_table of_modalias_table[] =3D {
> { "fsl,mcu-mpc8349emitx", "mcu-mpc8349emitx" },
> + { "mmc-spi-slot", "mmc_spi" },
Here I had to add=20
{ "gs2970", "gs2970" },
{ "spidev", "spidev" },
> };
To make my device get probed. Otherwise I receive error
spi_master spi32766: cannot find modalias for /soc8313@e0000000/spi@7000/gs=
2970@0=20
spi_master spi32766: cannot find modalias for /soc8313@e0000000/spi@7000/sp=
idev@4
I wonder if those modalias are absolutely required. I would prefer not to =
add platform specific stuff to the kernel as this was my motivation to appl=
y the patch. Would there be a way to get around this ?
Also, from patch 3/6 in the same patch set
+static int __devinit of_mpc83xx_spi_probe(struct of_device *ofdev,
+ const struct of_device_id *ofid)
.....
+ /* SPI controller is either clocked from QE or SoC clock. */
+ pdata->sysclk =3D get_brgfreq();
+ if (pdata->sysclk =3D=3D -1) {
+ pdata->sysclk =3D fsl_get_sys_freq();
+ if (pdata->sysclk =3D=3D -1) {
+ ret =3D -ENODEV;
+ goto err_clk;
+ }
+ }
get_brgfreq() in not defined in my system as I do not use QUICK_ENGINE
Thanks for support.
^ permalink raw reply
* MPC83xx console : no output after handover
From: Matthew L. Creech @ 2009-03-31 20:30 UTC (permalink / raw)
To: linuxppc-dev
(Sorry if this is a dupe, but I think my first attempt was filtered out)
Hi,
I'm trying to get Linux booting on a custom board based on the MPC8313
ERDB, but there's no output after the console is transferred. I get
the following:
Using MPC831x RDB machine description
Linux version 2.6.29 (mlcreech@lap) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-50
) ) #2 PREEMPT Tue Mar 31 14:54:27 EDT 2009
console [udbg0] enabled
... (normal boot output) ...
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
If I boot with "console=udbg0,115200", then it gets much further along
before printing "turn off boot console udbg0". So presumably the
kernel is booting beyond this point, but my console isn't printing any
output. I traced from that last line back up the call stack to the
end of drivers/serial/8250.c:serial8250_init(), and everything seems
okay (it returns 0, and pritnk() still works fine at that point). I'm
not sure where to go from there to figure out where the problem lies.
Could someone point me in the right direction, or suggest what might
cause a console problem like this?
Thanks!
--
Matthew L. Creech
^ permalink raw reply
* Re: Build error
From: Segher Boessenkool @ 2009-03-31 20:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1238455136.17330.12.camel@pasglop>
>>>> ERROR: "fsl_pq_mdio_bus_name" [drivers/net/gianfar_driver.ko]
>>>> undefined!
>>>>
>>>> I'll ask Linus to pull anyway though.
>>>>
>>>> Cheers,
>>>> Ben.
>>>
>>> I believe this is fixed in net-next (and possible linus has already
>>> pulled that in.)
>>
>> FWIW, I can't reproduce the issue neither in benh/powerpc.git `next'
>> branch nor in `merge' branch...
>
> Ah .. .weird :-)
I had this happen a few days ago already, on Linus' tree. I also told
you about it (on IRC), but you were too busy or something :-)
A simple ppc6xx_defconfig is enough to reproduce, fwiw.
Here's the patch I used, sorry if my mailer wraps it, it's a one-liner,
you can handle it I'm sure :-)
Segher
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Author: Segher Boessenkool <segher@kernel.crashing.org>
Date: Fri Mar 27 21:10:59 2009 +0100
powerpc: EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index b3079a5..a108332 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -204,6 +204,7 @@ void fsl_pq_mdio_bus_name(char *name, struct
device_node *np
snprintf(name, MII_BUS_ID_SIZE, "%s@%llx", np->name,
(unsigned long long)taddr);
}
+EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name);
/* Scan the bus in reverse, looking for an empty spot */
static int fsl_pq_mdio_find_free(struct mii_bus *new_bus)
^ permalink raw reply related
* Re: MPC83xx console : no output after handover
From: Gary Thomas @ 2009-03-31 20:45 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <5ee96a840903311330y36ed97bet92319da8d118086@mail.gmail.com>
Matthew L. Creech wrote:
> (Sorry if this is a dupe, but I think my first attempt was filtered out)
Nope, it made it.
> Hi,
>
> I'm trying to get Linux booting on a custom board based on the MPC8313
> ERDB, but there's no output after the console is transferred. I get
> the following:
>
> Using MPC831x RDB machine description
> Linux version 2.6.29 (mlcreech@lap) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-50
> ) ) #2 PREEMPT Tue Mar 31 14:54:27 EDT 2009
> console [udbg0] enabled
>
> ... (normal boot output) ...
>
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
>
> If I boot with "console=udbg0,115200", then it gets much further along
> before printing "turn off boot console udbg0". So presumably the
> kernel is booting beyond this point, but my console isn't printing any
> output. I traced from that last line back up the call stack to the
> end of drivers/serial/8250.c:serial8250_init(), and everything seems
> okay (it returns 0, and pritnk() still works fine at that point). I'm
> not sure where to go from there to figure out where the problem lies.
> Could someone point me in the right direction, or suggest what might
> cause a console problem like this?
What does your command line (boot args) when it fails? It should
probably have something like "console=ttyS0,115200" in it.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Build error
From: Grant Likely @ 2009-03-31 20:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, David Miller
In-Reply-To: <1238455136.17330.12.camel@pasglop>
On Mon, Mar 30, 2009 at 5:18 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2009-03-30 at 17:59 +0400, Anton Vorontsov wrote:
>> On Mon, Mar 30, 2009 at 08:51:38AM -0500, Kumar Gala wrote:
>> >
>> > On Mar 29, 2009, at 10:25 PM, Benjamin Herrenschmidt wrote:
>> >
>> >> My next branch (after merging from you):
>> >>
>> >> ERROR: "fsl_pq_mdio_bus_name" [drivers/net/gianfar_driver.ko]
>> >> undefined!
>> >>
>> >> I'll ask Linus to pull anyway though.
>> >>
>> >> Cheers,
>> >> Ben.
>> >
>> > I believe this is fixed in net-next (and possible linus has already
>> > pulled that in.)
>>
>> FWIW, I can't reproduce the issue neither in benh/powerpc.git `next'
>> branch nor in `merge' branch...
>
> Ah .. .weird :-)
>
> Oh well, I'll see if it still happens after I pull back from Linus (who
> merged all our stuff) and if it does, I'll send you my .config.
It is triggered when the driver is built as a module. I'm going to
post the fix right now.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Build error
From: Grant Likely @ 2009-03-31 20:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: David Miller, linuxppc-dev list
In-Reply-To: <38D8651E-1AB6-4358-AD1F-408E3DB8F4E9@kernel.crashing.org>
On Tue, Mar 31, 2009 at 2:41 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>>>>> ERROR: "fsl_pq_mdio_bus_name" [drivers/net/gianfar_driver.ko]
>>>>> undefined!
>>>>>
>>>> I believe this is fixed in net-next (and possible linus has already
>>>> pulled that in.)
>>>
>>> FWIW, I can't reproduce the issue neither in benh/powerpc.git `next'
>>> branch nor in `merge' branch...
>>
>> Ah .. .weird :-)
>
> I had this happen a few days ago already, on Linus' tree. =A0I also told
> you about it (on IRC), but you were too busy or something :-)
>
> A simple ppc6xx_defconfig is enough to reproduce, fwiw.
>
> Here's the patch I used, sorry if my mailer wraps it, it's a one-liner,
> you can handle it I'm sure :-)
>
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Heh, you beat me to it Segher.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
g.
>
>
> Author: Segher Boessenkool <segher@kernel.crashing.org>
> Date: =A0 Fri Mar 27 21:10:59 2009 +0100
>
> =A0 =A0powerpc: EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name)
>
> diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
> index b3079a5..a108332 100644
> --- a/drivers/net/fsl_pq_mdio.c
> +++ b/drivers/net/fsl_pq_mdio.c
> @@ -204,6 +204,7 @@ void fsl_pq_mdio_bus_name(char *name, struct device_n=
ode
> *np
> =A0 =A0 =A0 =A0snprintf(name, MII_BUS_ID_SIZE, "%s@%llx", np->name,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(unsigned long long)taddr);
> =A0}
> +EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name);
>
> =A0/* Scan the bus in reverse, looking for an empty spot */
> =A0static int fsl_pq_mdio_find_free(struct mii_bus *new_bus)
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Build error
From: Anton Vorontsov @ 2009-03-31 20:57 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <38D8651E-1AB6-4358-AD1F-408E3DB8F4E9@kernel.crashing.org>
On Tue, Mar 31, 2009 at 10:41:38PM +0200, Segher Boessenkool wrote:
>>>>> ERROR: "fsl_pq_mdio_bus_name" [drivers/net/gianfar_driver.ko]
>>>>> undefined!
>>>>>
>>>>> I'll ask Linus to pull anyway though.
>>>>>
>>>>> Cheers,
>>>>> Ben.
>>>>
>>>> I believe this is fixed in net-next (and possible linus has already
>>>> pulled that in.)
>>>
>>> FWIW, I can't reproduce the issue neither in benh/powerpc.git `next'
>>> branch nor in `merge' branch...
>>
>> Ah .. .weird :-)
>
> I had this happen a few days ago already, on Linus' tree. I also told
> you about it (on IRC), but you were too busy or something :-)
>
> A simple ppc6xx_defconfig is enough to reproduce, fwiw.
>
> Here's the patch I used, sorry if my mailer wraps it, it's a one-liner,
> you can handle it I'm sure :-)
Ah, the modular build. Yeah, I didn't try it, but should have... :-(
Thanks!
> Segher
>
>
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
>
>
> Author: Segher Boessenkool <segher@kernel.crashing.org>
> Date: Fri Mar 27 21:10:59 2009 +0100
>
> powerpc: EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name)
>
> diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
> index b3079a5..a108332 100644
> --- a/drivers/net/fsl_pq_mdio.c
> +++ b/drivers/net/fsl_pq_mdio.c
> @@ -204,6 +204,7 @@ void fsl_pq_mdio_bus_name(char *name, struct
> device_node *np
> snprintf(name, MII_BUS_ID_SIZE, "%s@%llx", np->name,
> (unsigned long long)taddr);
> }
> +EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name);
>
> /* Scan the bus in reverse, looking for an empty spot */
> static int fsl_pq_mdio_find_free(struct mii_bus *new_bus)
>
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: Interrupts on GPIO
From: Yann Pelletier @ 2009-03-31 20:59 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <mailman.3884.1238431353.26545.linuxppc-dev@ozlabs.org>
> Message: 7
> Date: Mon, 30 Mar 2009 10:32:17 -0600
> From: Grant Likely <grant.likely@secretlab.ca>
> Subject: > To: Yann Pelletier <ypelletier@haivision.com>
> Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
> Message-ID:
> <fa686aa40903300932p2c92110g2907bb7bf80d44d@mail.gmail.com>
> Content-Type: text/plain; charset=3DISO-8859-1
>=20
> On Mon, Mar 30, 2009 at 9:57 AM, Yann Pelletier
> <ypelletier@haivision.com> wrote:
> >
> > Hi,
> > I'd like to add supports for interrupts handling from GPIO controller.
> ?Some of these interrupts are from I2C devices and some others are from
> SPI devices.
> >
> > What is the best approach to enable interrupts handling for those
> devices through GPIO.
>=20
> Modify the GPIO driver to also be a cascaded IRQ driver (see
> http://patchwork.ozlabs.org/patch/21914/ for an example).
>=20
I've looked at the patch but I wonder if this would be applicable to the MP=
C8313. If my understanding is good, in the MPC52xx you have 8 gpio only in=
terrupts and 8 gpio/gpt. With the MPC8313, each GPIO can act as an interru=
pt but they are all muxed to only 1 interrupt in the IPIC. So I'm concern =
about making the GPIO controller act as an interrupt controller.
> > Also,
> >
> > # cat /proc/interrupts
> > ? ? ? ? ? CPU0
> > ?16: ? ? ? ? 60 ? IPIC ? Level ? ? serial
> > ?17: ? ? ? ? ?0 ? IPIC ? Level ? ? fpga
> > ?18: ? ? ? ? ?4 ? IPIC ? Level ? ? mpc83xx_spi
> > ?21: ? ? ? ? ?0 ? IPIC ? Level ? ? i2c-mpc
> > ?22: ? ? ? ? ?7 ? IPIC ? Level ? ? i2c-mpc
> >
> > According to my platform device tree, serial irq should be on int9, SPI
> on int16 and i2c on int14,15. ?This causes me some problems as I need
> int18 to map to external IRQ2.
>=20
> These numbers are *Linux internal* virtual irq numbers. They have no
> relation to the physical IRQ number for each interrupt controller.
> Just make sure your Device Tree maps the IRQs correctly and you'll be
> okay.
>=20
This is good now, thanks
> g.
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>=20
>=20
^ 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